[clc-devel] release 2.2
Hi there, I've tried to contact Per for some time, with no success, so it seems to me that we should put out a 2.2 on our own. I'd like to propose the following to go into 2.2: - udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ?? Some notes: - gcc4 will require some patches, however, danm's 64-bit iso has some of them and is using gcc4 - setup can't handle xorg 7.0 just yet - bash 3.1 has serious bugs, and can easily be updated later My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-). There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone. Please comment on a) suggested/missing features b) the timeline c) core/opt separation Thanks for your cooperation, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Johannes Winkelmann [2006-01-09 22:44]:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ??
Sounds fine to me, although I don't know about the status of gcc/glibc/bash.
My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-).
Okay.
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
I agree. Regards, Tilman -- GnuPG key available at http://code-monkey.de/files/tsauerbeck-public-key.asc
On Mon, 2006-01-09 at 22:44 +0100, Johannes Winkelmann wrote:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ??
These all seem fine to me. As I mentioned in IRC I've not used any of these yet but I'll be happy to test them.
- bash 3.1 has serious bugs, and can easily be updated later
What kind of bugs? Serious enough that installing it by default would be a bad idea (tm)?
My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-).
This sounds good to me, and it's easily done. Anyone who wishes to use my modified Makefile and iso tree to make their own test isos is welcome to, as well.
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
I honestly don't care either way. Do you want to keep them on the iso even so? I thought the consensus at cruxcon was that core == iso. If we don't want them on the iso I can understand that but let's be consistent. I probably missed some talk about this in IRC today, I'm sick and slept a lot of the day.
Please comment on a) suggested/missing features
None at this time.
b) the timeline
Seems ok to me. Quality over quantity.
c) core/opt separation
What do you mean by this? Matt (jaeger@freenode/#crux)
Hi, On Mon, Jan 09, 2006 at 22:37:40 -0600, Matt Housh wrote:
On Mon, 2006-01-09 at 22:44 +0100, Johannes Winkelmann wrote: [...]
- bash 3.1 has serious bugs, and can easily be updated later
What kind of bugs? Serious enough that installing it by default would be a bad idea (tm)? Okay, upon further examination the only grave problem seems to be this one: http://lists.gnu.org/archive/html/bug-bash/2005-12/msg00041.html
There's a number of patches against 3.1, available from the official gnu bash download server, including a fix for the bug mentioned above: http://ftp.gnu.org/gnu/bash/bash-3.1-patches/ However, there was not 3.2 or 3.1.1 release to address those; as Simone mentions, it's probably worth updating to it later once there's a bugfix release from the bash crowd.
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
I honestly don't care either way. Do you want to keep them on the iso even so? I thought the consensus at cruxcon was that core == iso. If we don't want them on the iso I can understand that but let's be consistent. We'd include "Per's selection" on the ISO, that is, firefox, gtk, windowmaker etc.
I remember the decision we had regarding "core ports are those that go with the ISO", but I consider it somewhat flawed now: if you look at the ports tree, I don't see any valid argument to declare window maker core but not the other WMs, or gtk but not qt3. Sure, they're on the ISO, but does that matter once you installed the system? If you do a server installation, why should X11 be in the "core" collection? Those questions were what changed my mind (Simone's arguments helped, too;-)). I think we're trading in some comfort for us the creators of the ISO (since we'll have to slightly modify the Makefile to list the packages that are included on the ISO), but get a more meaningful collection name in the ports tree. At the same time, the adjusted Makefile will make it easier to build customized ISO's without rearranging your ports tree. Finally, as discussed in the dependency thread, "core" will imply that you need those ports to get a system which init(8)s fine. Otherwise, we'd be in a "oh you can remove some ports from core, but not all" situation. I hope this makes any sense :-). Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Johannes Winkelmann wrote:
Hi there,
I've tried to contact Per for some time, with no success, so it seems to me that we should put out a 2.2 on our own. I'd like to propose the following to go into 2.2:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ??
if useful, we would reach exactly the same goal with ppc :-D -- Giulivo Navigante http://cruxppc.sunsite.dk
--- Giulivo Navigante <giulivo.navigante@katamail.com> wrote:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9
Yes.
- gcc 4.0.2 ? - bash 3.1 ??
Probably no? It depends how easily we can get core and opt building with gcc4. That is definitely something we would have to test. Jukka, do you still build a massive number of packages just for giggles?
if useful, we would reach exactly the same goal with ppc :-D
Sure, that would be smart - perhaps bring the ports trees a bit closer :) Matt, it seems as tho core will essentially be a slightly trimmed incarnation of what was base. X11/Firefox/gtk and others will move to opt, but still be shipped on the iso. Yes, this is backwards from what was discussed at CRUXCon. But I guess some limitations/problems with that approach were brought up by Simone and others. Johannes can fill you in on irc - he explained it to me yesterday. Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Jay Dolan wrote:
- gcc 4.0.2 ? - bash 3.1 ??
Probably no? It depends how easily we can get core and opt building with gcc4. That is definitely something we would have to test. Jukka, do you still build a massive number of packages just for giggles?
gcc4 introduces autovectorization on powerpc, so it's very important for us -- Giulivo Navigante http://cruxppc.sunsite.dk
On Mon, Jan 09, 2006 at 10:44:25PM +0100, Johannes Winkelmann wrote:
I've tried to contact Per for some time, with no success, so it seems to me that we should put out a 2.2 on our own. I'd like to propose the following to go into 2.2:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ?? Well. I don't know enough about gcc4 and bash 3.1 to decide whether we should put it in the next release or not. I am against gcc4 if you aren't sure that there will be no problems with it.
My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-). I agree.
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone. I also agree here. In the core repository there should be only ports which are needed to get a working Crux.
Regards Viper
On 01/09/06 22:44 Johannes Winkelmann wrote:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ??
I'd stick with bash 3.0 since it's easily upgradable later as you mention. The others are fine for me.
My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-).
Sounds ok. I suggest we create a 2.2 or devel branch in svn so we can start playing with it
Please comment on a) suggested/missing features
I think it's important to put some work on documentation (ie handbook) and website before 2.2 goes live, to re-organize stuff and recover from little annoyances that were due to the new server & structure transition. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Johannes Winkelmann wrote:
Hi there,
I've tried to contact Per for some time, with no success, so it seems to me that we should put out a 2.2 on our own. I'd like to propose the following to go into 2.2:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9
Sounds good to me.
- gcc 4.0.2 ? - bash 3.1 ??
Some notes: - gcc4 will require some patches, however, danm's 64-bit iso has some of them and is using gcc4 - setup can't handle xorg 7.0 just yet - bash 3.1 has serious bugs, and can easily be updated later
I can do a test run on current contrib ports to see how many fail when compiled with gcc 4.0.2. I'm okay with either bash 3.0 or a patched 3.1, but I recommend we stick with X.org 6.9 for now--it's essentially the same code base anyway.
My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-).
I agree.
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
Yes, I think we better keep core to the BASICS (which in my opinion is a text-only environment suitable for setting up gateways etc. and extending for other purposes). Regards, Jukka
On Tue, Jan 10, 2006 at 09:53:36PM +0200, Jukka Heino wrote:
Yes, I think we better keep core to the BASICS (which in my opinion is a text-only environment suitable for setting up gateways etc. and extending for other purposes).
That's exactly how I felt about it but didn't feel like saying it. Since you said it, I need only concur.
Jukka Heino wrote:
Johannes Winkelmann wrote:
[...] - gcc 4.0.2 ? - bash 3.1 ??
Some notes: - gcc4 will require some patches, however, danm's 64-bit iso has some of them and is using gcc4 [...] I can do a test run on current contrib ports to see how many fail when compiled with gcc 4.0.2. I'm okay with either bash 3.0 or a patched 3.1, but I recommend we stick with X.org 6.9 for now--it's essentially the same code base anyway.
as far as i know, upgrading to glibc 2.3.6 makes life with gcc4 much easier... so i'd suggest to upgrade that first (just change version and remove the patch in the port... at least that's what i can remember now), before the test run! anyway if the 2.2 will be based on gcc4 (and that's how i'd like it... if it works...) i think that it has to be built from scratch... but hey, i forgot that the Makefile can bootstrap the new toolchain automagically :)
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
Yes, I think we better keep core to the BASICS (which in my opinion is a text-only environment suitable for setting up gateways etc. and extending for other purposes).
yes i fully agree with you... I mean the user should not be left to chose which of the core ports s/he wants to install... as they should really be the ones s/he can't live without... But having a few extra packages might really come handy to the ones with not-so-fast processor/internet connection (firefox takes 4.5 hours to build on my comp)... But i think the boundary between the ones that are needed in a minimal system and the extra ones should be neat... and all in all those extras are just the 3 we're talking about... :) So i think they should be kept out of the iso... regards, giorgio
On Tue, Jan 10, 2006 at 09:53:36PM +0200, Jukka Heino wrote:
I can do a test run on current contrib ports to see how many fail when compiled with gcc 4.0.2. I'm okay with either bash 3.0 or a patched 3.1, but I recommend we stick with X.org 6.9 for now--it's essentially the same code base anyway.
I can say right now that xine-lib will fail, or not work properly (based on what I read, some months ago). Its 1.1.x branch is for GCC4, while its 1.0.x branch is for GCC3. What I wonder, is if most of ports/opt/ are like this; or if the latest versions do some autoconf check-GCC-version magic; or if we're going to have to pull in patches from the development branch of a particular port--or worse: be forced to use a development version. If an imminent switch won't cause a world of headaches, then I would advocate "let's give it a try, and see how it goes; if it works, then ship it ;-)". On the other hand, isn't the switch to GCC4 a HUGE leap? Shouldn't someone write some kind of migration document? (documentation seems like it has become an issue for some users) Something more substantial then: "after upgrading your system from the CRUX 2.2 iso, and rebooting, type: prt-get update -fr `prt-get listinst`" Out of curiousity, would prt-get rebuild the list alphabetically, or according to listed dependencies? Meh, forgive me for all this talk, when I know I won't be able to to much to help out (school). Nevertheless, I'll take care of xine-lib when the time comes. Cheers, Nick
On Wednesday 11 January 2006 03:41, Nick Steeves wrote:
I can say right now that xine-lib will fail, or not work properly (based on what I read, some months ago). Its 1.1.x branch is for GCC4, while its 1.0.x branch is for GCC3. What I wonder, is if most of ports/opt/ are like this; or if the latest versions do some autoconf check-GCC-version magic; or if we're going to have to pull in patches from the development branch of a particular port--or worse: be forced to use a development version.
That's what I did. xine-lib: 1.1.0 (no problems with KDE, e17 and mplayer so far) http://crux.danm.de/ports/head/contrib64/xine-lib/Pkgfile xine-ui: 0.99.4 http://crux.danm.de/ports/head/contrib64/xine-ui/Pkgfile I had to tweak MPlayer a bit: --disable-gcc-checking (Gentoo made some nice patches for it: http://crux.danm.de/ports/head/compat32/mplayer32/mplayer-1.0_pre7-gcc4.patc... http://crux.danm.de/ports/head/compat32/mplayer32/mplayer-1.0_pre7-gcc4-amd6...) bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Mon, Jan 09, 2006 at 10:44:25PM +0100, Johannes Winkelmann wrote:
Hi there,
I've tried to contact Per for some time, with no success, so it seems to me that we should put out a 2.2 on our own. I'd like to propose the following to go into 2.2:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9
Yes
- gcc 4.0.2 ? - bash 3.1 ??
Probably not. Seems that we are doing this release without Per, so I'd suggest to have stability as the main goal. I prefer to have a release which allows the user the update from the cd without a fresh install. I don't now if this can be done in a sensefull way with gcc4.
Some notes: - gcc4 will require some patches, however, danm's 64-bit iso has some of them and is using gcc4 - setup can't handle xorg 7.0 just yet - bash 3.1 has serious bugs, and can easily be updated later
My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-).
Yep, sounds like a plan
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
Fine with me, but they should be shipped on the cd. Meaning that we will have all core and some opt ports on the cd. If we go in that direction we should discuss what "some" means, I my opinion qt3 is one that should be added. And if we are on cleaning-up core, we should consider about moving the following to opt too: cdrtools, cpio, cvs, cvsup, gdb, linux-identd, pcmcia-cs, ppp, rp-pppoe, traceroute, wireless-tools, windowmaker, wvdial ... more ? and of course all deps of x11/firefox/gtk but zlib and ncurses Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On Wed, Jan 11, 2006 at 08:34:26AM +0100, Juergen Daubert wrote:
And if we are on cleaning-up core, we should consider about moving the following to opt too:
cdrtools, cpio, cvs, cvsup, gdb, linux-identd, pcmcia-cs, ppp, rp-pppoe, traceroute, wireless-tools, windowmaker, wvdial ... more ? and of course all deps of x11/firefox/gtk but zlib and ncurses
IMHO, ppp, rp-ppoe, wireless-tools, and possibly wvdial should remain in core. My rational is that it should be possible to connect to the 'net to grab the ports tree, with only core installed. Personally, the only one I need is wireless-tools. Also, the functionality of wireless-tools is an integral part of the BSDs ifconfig (FreeBSD's at least, though I highly suspect OpenBSD has it too). Cheers, Nick
On Wed, Jan 11, 2006 at 02:41:38AM -0700, Nick Steeves wrote:
On Wed, Jan 11, 2006 at 08:34:26AM +0100, Juergen Daubert wrote:
And if we are on cleaning-up core, we should consider about moving the following to opt too:
cdrtools, cpio, cvs, cvsup, gdb, linux-identd, pcmcia-cs, ppp, rp-pppoe, traceroute, wireless-tools, windowmaker, wvdial ... more ? and of course all deps of x11/firefox/gtk but zlib and ncurses
IMHO, ppp, rp-ppoe, wireless-tools, and possibly wvdial should remain in core. My rational is that it should be possible to connect to the 'net to grab the ports tree, with only core installed. Personally, the only one I need is wireless-tools. Also, the functionality of wireless-tools is an integral part of the BSDs ifconfig (FreeBSD's at least, though I highly suspect OpenBSD has it too).
In that new scenario, first proposed by Simone, core doesn't mean everything on the cd, but everything that's needed for 'base' crux install. The cd will contain all of core + some ports from opt. Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Nick Steeves wrote:
[...] IMHO, ppp, rp-ppoe, wireless-tools, and possibly wvdial should remain in core. My rational is that it should be possible to connect to the 'net to grab the ports tree, with only core installed. Personally, the only one I need is wireless-tools. Also, the functionality of wireless-tools is an integral part of the BSDs ifconfig (FreeBSD's at least, though I highly suspect OpenBSD has it too).
I agree that at least wireless-tools and rp-pppoe are good candidates for core and for the iso... I also think that mdadm and/or lvm2 (as Rxi suggested on the ppc forum) should get into core... maybe they have just been left behind as it looks like Per meant to put something to allow software-raid installation of the root partition (i see mdadm is still in the not-yet-updated Makefile). Cheers, giorgio
Juergen Daubert rote
On Mon, Jan 09, 2006 at 10:44:25PM +0100, Johannes Winkelmann wrote:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9
sounds good, perhaps also including other "major releases" like - OpenSSL 0.9.8a
- gcc 4.0.2 ? - bash 3.1 ??
Probably not. Seems that we are doing this release without Per, so I'd suggest to have stability as the main goal. I prefer to have a release which allows the user the update from the cd without a fresh install. I don't now if this can be done in a sensefull way with gcc4.
are already compiled programs/working systems/libraries affected by upgrading to gcc4? if not, upgrading to gcc4 (and packages from the iso compiled by gcc4) should not be a problem (at least not from the users view) for the release numbering/naming scheme i'd expect that "minor" releases (like 2.2) lead to simple/straight forward updating procedures, whereas major releases (3.0) can imply some kind of "fresh install" when do those who dare to predict see that gcc4 becomes mandatory, even for the (up to now) most common scenario of x86 machines? [snip gcc4/bash details]
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
Fine with me, but they should be shipped on the cd. Meaning that we will have all core and some opt ports on the cd. If we go in that direction we should discuss what "some" means, I my opinion qt3 is one that should be added.
limiting by defined iso size? (is there a magic limit, like tiny CDs?) or functionality? compile time compromise? making a "poll" what should be included? i, for example, use crux only for routers and (internet)servers - but is introducing some kind of preselected packet lists of any use? for ex. core, router, server, desktop ... dejavu, somehow violates KISS
And if we are on cleaning-up core, we should consider about moving the following to opt too:
cdrtools, cpio, cvs, cvsup, gdb, linux-identd, pcmcia-cs, ppp, rp-pppoe, traceroute, wireless-tools, windowmaker, wvdial ... more ?
if "on the iso" is no longer the criteria for "core", we need some new, neat and nice criteria for core. (some "cruxish" critera) - bootimage/lifecd? - "getting online"? (would include ppp, rp-pppoe, wireless again) - common toolbase? - ... personally, i could live with some - "current core, without anything X-related or anything else bloating"
and of course all deps of x11/firefox/gtk but zlib and ncurses
e.g. fontconfig, freetype devfsd (not needed when switched to udev anyway) btw, is the list of programs ready to use when booting from the iso something what should be considered in this early stage? if so, i'd vote for something similiar to jaegers boot cd including sshd and dhcpclient sincerly, martin (irc: cohan)
On Wed, Jan 11, 2006 at 11:36:36AM +0100, Martin Koniczek wrote:
Juergen Daubert rote
On Mon, Jan 09, 2006 at 10:44:25PM +0100, Johannes Winkelmann wrote:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9
sounds good, perhaps also including other "major releases" like - OpenSSL 0.9.8a
- gcc 4.0.2 ? - bash 3.1 ??
Probably not. Seems that we are doing this release without Per, so I'd suggest to have stability as the main goal. I prefer to have a release which allows the user the update from the cd without a fresh install. I don't now if this can be done in a sensefull way with gcc4.
are already compiled programs/working systems/libraries affected by upgrading to gcc4?
Yes, at least all C++ programms, compiled on a CRXU 2.1, the will depend on libstdc++-compat. Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On Wednesday 11 January 2006 08:34, Juergen Daubert wrote:
I don't now if this can be done in a sensefull way with gcc4.
Heh, we could create a new port: opt/gcc3 GCC4 works pretty well here. I wouldn't release CRUX 2.2(?) without it. bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Wed, Jan 11, 2006 at 01:45:51PM +0100, Daniel Mueller wrote:
On Wednesday 11 January 2006 08:34, Juergen Daubert wrote:
I don't now if this can be done in a sensefull way with gcc4.
Heh, we could create a new port:
opt/gcc3
GCC4 works pretty well here. I wouldn't release CRUX 2.2(?) without it.
Nice to hear that. If we don't run into much trouble here, even gcc4 is ok for me. My restraint are primary driven by the fact, that I see enough work to organize the whole process, and under that point of few the time plan suggested by Johannes isn't very relaxed. Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
--- Juergen Daubert <jue@jue.li> wrote:
Nice to hear that. If we don't run into much trouble here, even gcc4 is ok for me. My restraint are primary driven by the fact, that I see enough work to organize the whole process, and under that point of few the time plan suggested by Johannes isn't very relaxed.
Johannes, can you modify your gcc4 port to be a drop-in replacement for gcc3.x? This way, maintainers can start test-building their ports with minimal setup required. Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Johannes Winkelmann wrote:
Hi there, [...] Please comment on a) suggested/missing features
if we want to stay on the bleeding edge... Y not experimental support for reiserfs4??? yep i know it's too much, will need to patch the kernel, and thus it's probably a bad idea... but maybe only on a test iso for developers?? or on Matt's crux-latest??? has anyone tried that??? how much stable is it? sorry if this is somehow off-thread... regards, giorgio
Hi Giorgio, On Wed, Jan 11, 2006 at 12:40:36 +0100, NullPointer wrote:
Johannes Winkelmann wrote:
Hi there, [...] Please comment on a) suggested/missing features
if we want to stay on the bleeding edge... Maybe the PPC team has a different approach here, but CRUX _never_ was about bleeding edge but "latest stable". That's a pretty big difference, and I see no good reason to change that.
Y not experimental support for reiserfs4??? You might want to check out http://linuxgazette.net/122/piszcz.html
Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Hey all (and Johannes)...
Y not experimental support for reiserfs4??? You might want to check out http://linuxgazette.net/122/piszcz.html
Thanks for the link, i've always been curious on the stats on reiserfs4. After reading this, i had no idea how slow and generally crappy that file system is. I know this if off topic, but what are , if there are any, advantages of reirser4? other then it's Hans Reiser's pet project? :-P. -- Jonathan Asghar phone: 512.619.0722
Johannes Winkelmann wrote:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ??
I agree. One word on udev. It depends on hotplug, which is (IIRC) the main reason for the whole debate on "Why does CRUX stick with devfs". So what do you think about the way Arch Linux went? [1],[2] Can this be adopted for CRUX or is hotplug KISS enough nowadays?
My proposal is to do a -pre1 release by the end of january, for devs only, and then release -testX throughout february, and if needed in march too. Release when it's done :-).
I agree once again. Jukka Heino wrote:
Johannes Winkelmann wrote:
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
Yes, I think we better keep core to the BASICS (which in my opinion is a text-only environment suitable for setting up gateways etc. and extending for other purposes).
I totally agree in this point. Regards Till [1] http://www.archlinux.org/blog/2005/11/10/simple-hardware-detection/ [2] http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/initscripts/hwdetect?rev=1... -- http://www.tbmnet.de ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Mon, 9 Jan 2006 22:44:25 +0100 Johannes Winkelmann wrote:
Hi there, Hi. I've tried to contact Per for some time, with no success, so it seems to me that we should put out a 2.2 on our own. I'd like to propose the following to go into 2.2:
- udev enabled kernel/init scripts - ports tree using rsync by default - glibc 2.3.6 - xorg 6.9 - gcc 4.0.2 ? - bash 3.1 ??
I think that 2.2 should be bugfix release,with switch to udev as major change,and to include gcc-4.x and modular X in release after that. Udev will get 'why-Crux-didn't-switch-to-udev-yet' crowd off your back,and since 2.2 will be 'just' an update to rest of the system,it should be less hassle to test and release. With 2.2 as current,you'll have more time to test gcc-4.x,ports from core/opt that don't build with gcc cleanly will more than likely get updated upstream, saving you some work,which is a Good Thing[tm]. Also,modular X,IMHO,needs to stabilize a bit before it gets included,and as you said,setup can't handle it just yet. <snip>
There's one important question we have to answer: do we want to move x11/firefox/gtk back to opt? As mentioned in the previous thread about this, I'd prefer to move them back, and so is Simone.
The point of core,if I understood correctly,is that it should contain ports that are 'a must' if you want functional,although somewhat minimal,system. If that's correct then x11,firefox and gtk should go to opt(x11 would have to get it's own repo when we switch to modular,anyway).
Thanks for your cooperation, Johannes
Just my opinion as a user <g> BTW,anyone knows why are no more logs of #crux at maol.ch? Last one is from week ago. They are a fun to read,I miss 'em... Pedja -- " [...]while trying to perl -d this problem the perl debugger segfaults. :-( "
participants (17)
-
Daniel Mueller -
Giulivo Navigante -
Jay Dolan -
Johannes Winkelmann -
Jonathan Asghar -
Juergen Daubert -
Jukka Heino -
Justin Rebelo -
Martin Koniczek -
Matt Housh -
Nick Steeves -
NullPointer -
Predrag Ivanovic -
Simon Gloßner -
Simone Rota -
Till Biedermann -
Tilman Sauerbeck