Hi, We've just updated core/make to 3.81, an update which is supposed to fix a number of problems. Since not all changes are backward compatible, projects depending on a particular (miss-)feature of former make releases may break. Chances are you won't see this; we've tested core and opt with it, and hit no problems. I have heard from one single package so far which fails to compile with 3.81 (the u-boot bootloader), however if you experience problems, please contact the upstream developer, or submit a bug in our bug tracking system. Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Fri, 2006-05-26 at 22:37 +0200, Johannes Winkelmann wrote:
We've just updated core/make to 3.81, an update which is supposed to fix a number of problems. Since not all changes are backward compatible, projects depending on a particular (miss-)feature of former make releases may break. Chances are you won't see this; we've tested core and opt with it, and hit no problems.
Nice to see someone step up and keep us up-to-date. Speaking of core updates, gcc 4.1 is no longer a .0 ;) Also, I've been using glibc 2.4 since it was released (shortly before crux 2.2) and have only hit a single problem - details on http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/7195 As for glibc, I'm not to sure what benefits the newer version has, but gcc 4.1 definately have some nice improvements over 4.0.
Seems me is going to make himself a fool once again... On Sat, 27 May 2006 01:17:11 +0200 Mark Rosenstand <mark@borkware.net> wrote:
Also, I've been using glibc 2.4 since it was released (shortly before crux 2.2) and have only hit a single problem - details on http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/7195
As for glibc, I'm not to sure what benefits the newer version has, but gcc 4.1 definately have some nice improvements over 4.0.
Hope, these results was mentioned in context of the future development... Won't it be better to stuck with particular gcc/glibc version during one official crux release life cycle? Are crux users supposed to be 'bleeding-edgers'? As for me, it also would be great too have official releases less frequently, say one in 14-16 months (and updating non-toolchain stuff more frequently). Or in case of more frequent ones to create a guide on (double) toolchain rebuild and troubleshooting for each such release. Note, the system is not only core+opt, so (I think) just doing a usual binary upgrade might brake some staff at some point... The goal is to have long living, so-called 'rock-solid' system with as little as possible downtime, all binaries built within one toolchain and still get latest software updates. Is it a useless dream? However it is up to core developers to decide. I'll rely on Your decision. Sorry for off-topic. -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta Jabber: mike_k@jabber.lafox.net NIC handle: MKK83-UANIC
On Sat, 2006-05-27 at 10:50 +0300, Mikhail Kolesnik wrote:
Seems me is going to make himself a fool once again...
On Sat, 27 May 2006 01:17:11 +0200 Mark Rosenstand <mark@borkware.net> wrote:
Also, I've been using glibc 2.4 since it was released (shortly before crux 2.2) and have only hit a single problem - details on http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/7195
As for glibc, I'm not to sure what benefits the newer version has, but gcc 4.1 definately have some nice improvements over 4.0.
Hope, these results was mentioned in context of the future development...
Won't it be better to stuck with particular gcc/glibc version during one official crux release life cycle?
Yes, I think these updates are 2.3 material.
Are crux users supposed to be 'bleeding-edgers'?
Not according to the handbook, which states "the latest stable packages" - although for critical core components it makes sense to be a bit more conservative, e.g. leave out x.x.0 versions of the C library and compiler. That said, the reason I'm advocating gcc 4.1 is that we're currently using 4.0. Had we still been at 3.4, it wouldn't be as tempting given the 3.x -> 4.x breakage.
As for me, it also would be great too have official releases less frequently, say one in 14-16 months (and updating non-toolchain stuff more frequently).
Or even better: core could be branched, while opt is a moving target. People could then choose to stick to the release version of core (or a security-fixes-only branch of said release) while those wanting to help make the next release top-notch could follow trunk. Both camps would run the latest and greatest opt ports. This is much similar to the FreeBSD 'src' and 'ports' modules. While pushing toolchain updates 14 months into the future would probably make a relatively stable base for the next ... 14 months, it won't reduce the breakage at that point, which in turn means you'll have to do 14 months worth of head scratching.
On Sat, 27 May 2006 11:28:13 +0200 Mark Rosenstand <mark@borkware.net> wrote:
On Sat, 2006-05-27 at 10:50 +0300, Mikhail Kolesnik wrote:
Seems me is going to make himself a fool once again...
On Sat, 27 May 2006 01:17:11 +0200 Mark Rosenstand <mark@borkware.net> wrote:
Are crux users supposed to be 'bleeding-edgers'?
Not according to the handbook, which states "the latest stable packages" - although for critical core components it makes sense to be a bit more conservative, e.g. leave out x.x.0 versions of the C library and compiler.
Handbook can not cover the update frequency & toolchain details... In real world we can't just replace all the system staff with "the latest stable packages".
As for me, it also would be great too have official releases less frequently, say one in 14-16 months (and updating non-toolchain stuff more frequently).
Or even better: core could be branched, while opt is a moving target. People could then choose to stick to the release version of core (or a security-fixes-only branch of said release) while those wanting to help make the next release top-notch could follow trunk.
Both camps would run the latest and greatest opt ports. This is much similar to the FreeBSD 'src' and 'ports' modules.
core != toolchain, and many ports from core might be updated fairly easy. Branching such a small(number of core developers/active testers) distro? Would it be possible?
While pushing toolchain updates 14 months into the future would probably make a relatively stable base for the next ... 14 months, it won't reduce the breakage at that point, which in turn means you'll have to do 14 months worth of head scratching.
"Small pain once a season VS medium pain once a year" question. I prefer the last. After all, the important thing is to prevent such questions being each user's "Personal eXtra Pain (tm)". Let's discuss or at least watch the core developers discussion? -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta Jabber: mike_k@jabber.lafox.net NIC handle: MKK83-UANIC
On Sat, 2006-05-27 at 13:01 +0300, Mikhail Kolesnik wrote:
On Sat, 27 May 2006 11:28:13 +0200 Mark Rosenstand <mark@borkware.net> wrote:
On Sat, 2006-05-27 at 10:50 +0300, Mikhail Kolesnik wrote:
Seems me is going to make himself a fool once again...
On Sat, 27 May 2006 01:17:11 +0200 Mark Rosenstand <mark@borkware.net> wrote:
Are crux users supposed to be 'bleeding-edgers'?
Not according to the handbook, which states "the latest stable packages" - although for critical core components it makes sense to be a bit more conservative, e.g. leave out x.x.0 versions of the C library and compiler.
Handbook can not cover the update frequency & toolchain details... In real world we can't just replace all the system staff with "the latest stable packages".
Works for me (and I consider my world pretty real.)
As for me, it also would be great too have official releases less frequently, say one in 14-16 months (and updating non-toolchain stuff more frequently).
Or even better: core could be branched, while opt is a moving target. People could then choose to stick to the release version of core (or a security-fixes-only branch of said release) while those wanting to help make the next release top-notch could follow trunk.
Both camps would run the latest and greatest opt ports. This is much similar to the FreeBSD 'src' and 'ports' modules.
core != toolchain, and many ports from core might be updated fairly easy.
The toolchain isn't the only thing that causes breakage. Think about the 2.1 -> 2.2 OpenSSL update.
Branching such a small(number of core developers/active testers) distro? Would it be possible?
This is how it works now, except branches are made 1-3 months prior to release and then function as a temporary trunk until the release is made. The change proposed here is actually to /only/ branch core, instead of core + opt, which in my book translates to less work. Sure, it is possible that an opt port tested on release x.y won't work on release x.y-1, but chances are very small because it's source-based.
While pushing toolchain updates 14 months into the future would probably make a relatively stable base for the next ... 14 months, it won't reduce the breakage at that point, which in turn means you'll have to do 14 months worth of head scratching.
"Small pain once a season VS medium pain once a year" question. I prefer the last.
Nobody prevents you from ignoring every second release. But enforcing that upgrade cycle on all users is wrong.
On Sat, May 27, 2006 at 10:50:25AM +0300, Mikhail Kolesnik wrote:
On Sat, 27 May 2006 01:17:11 +0200 Mark Rosenstand <mark@borkware.net> wrote:
Also, I've been using glibc 2.4 since it was released (shortly before crux 2.2) and have only hit a single problem - details on http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/7195
As for glibc, I'm not to sure what benefits the newer version has, but gcc 4.1 definately have some nice improvements over 4.0.
Hope, these results was mentioned in context of the future development...
Won't it be better to stuck with particular gcc/glibc version during one official crux release life cycle?
I prefer not having the mess around with gcc/glibc every time a new release is out for either one. The reason why I started to appreciate CRUX was because the less critical core software was update while the crucial elements remained untouched unless it was completely necessary to do so.
Are crux users supposed to be 'bleeding-edgers'?
Quoting crux.nu that it is targeted at experience users, my reasoning is as follows: 1) the user may update the system as they wish as long as they keep in mind that they will be by themselves if they break something. 2) The official versions of gcc/glibc should otherwise be followed to have a stable system.
The goal is to have long living, so-called 'rock-solid' system with as little as possible downtime, all binaries built within one toolchain and still get latest software updates. Is it a useless dream?
I agree with that statement, and I do not believe it is a useless dream. My 0,02 EUR on the topic, feel free to disagree. ;)
On Sat, 2006-05-27 at 13:36 +0300, Jesse Kokkarinen wrote:
I prefer not having the mess around with gcc/glibc every time a new release is out for either one. The reason why I started to appreciate CRUX was because the less critical core software was update while the crucial elements remained untouched unless it was completely necessary to do so.
Which is why I suggest a trunk and branches. After all, most users (including myself on certain boxen) share your view, but the new versions *do* need testing (and the more testing, the better.)
On Sat, May 27, 2006 at 01:01:20PM +0200, Mark Rosenstand wrote:
Which is why I suggest a trunk and branches. After all, most users (including myself on certain boxen) share your view, but the new versions *do* need testing (and the more testing, the better.)
Now I understand what you meant, however it seems like it would be quite difficult since CRUX is not particularily rich in user resources. You could say CRUX has "outsourced" testing software, and then once results have been either positive or negative, would it be incorporated or left out. It just seems it would turn into a user, non-officially sanctioned project.
Hello, Jesse. On Sat, 27 May 2006 15:29:33 +0300 Jesse Kokkarinen <jesse.kokkarinen@kapsi.fi> wrote:
On Sat, May 27, 2006 at 01:01:20PM +0200, Mark Rosenstand wrote:
Which is why I suggest a trunk and branches. After all, most users (including myself on certain boxen) share your view, but the new versions *do* need testing (and the more testing, the better.)
Now I understand what you meant, however it seems like it would be quite difficult since CRUX is not particularily rich in user resources. You could say CRUX has "outsourced" testing software, and then once results have been either positive or negative, would it be incorporated or left out. It just seems it would turn into a user, non-officially sanctioned project.
That is what I am afraid of. I can't really disagree with Mark, but just can't leave this problem out... -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta Jabber: mike_k@jabber.lafox.net NIC handle: MKK83-UANIC
participants (4)
-
Jesse Kokkarinen -
Johannes Winkelmann -
Mark Rosenstand -
Mikhail Kolesnik