March 2006 - crux-devel - lists.crux.nu

[clc-devel] crux 2.2-test2 out
by Johannes Winkelmann 04 Apr '06

04 Apr '06

Hi there, Matt just uploaded -test2 which adds new version of glib, atk and gtk. If you have ports which depend on those you might want to update (updating through ports should work just fine). In addition, this ISO contains a text version of the wikified handbook, available from http://crux.nu/Main/Handbook2-2 Get it from http://crux.nu/files/releases/pre-releases/ Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net

3 3

[clc-devel] Early CRUXCon this year: LinuxTag 2006
by Johannes Winkelmann 31 Mar '06

31 Mar '06

Hi, Even though CRUXCon is traditionally in autumn, I'd like to suggest a much earlier date: LinuxTag in Wiesbaden, from 3rd to 6th May. It's kinda short, however it seems to be a good fit (shortly after the 2.2 release (crossing fingers)) and a nice opportunity to talk about the future. I'm therefore wondering: who could make it to germany in ~40 days (exact date to be determined)? http://www.linuxtag.org/2006/en/ Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net

2 1

[clc-devel] KDE documentation
by Nick Steeves 29 Mar '06

29 Mar '06

Hi, Some users in crux@ have expressed the opinion that /usr/share/doc/HTML/en rooted documentation should not be removed, because it breaks every single KDE application's handbook. I also feel that KDE documentation is easily as useful as the mutt "?" handbook. Can I allow their installation for CRUX-2.2? Cheers, Nick

2 1

[clc-devel] crux 2.2-test1 out & announced
by Johannes Winkelmann 28 Mar '06

28 Mar '06

Hi, We just announced crux 2.2-test1 to crux@, which means that everyone should now start testing his ports in a 2.2-like environment. Only security related changes should go into 2.1 from now on. If no serious issues are reported, we'd like to release 2.2 final on Monday, april 10. Users were asked to file bug reports in flyspray, so please check it from time to time. They were also told that we're working on it, so should expect some delays before issues are addressed or to put it in a different way, no one expects a perfectly working 2.2 (opt-)tree before 2.2-final is out. Looking forward to a great 2.2 release! Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net

1 0

[clc-devel] New wiki at crux.nu, handbook for 2.2
by Juergen Daubert 25 Mar '06

25 Mar '06

Hi all, as you maybe have already noticed, Simone installed a pmwiki setup on crux.nu, I'm very confident that we found our final wiki ;-) Together with Johannes I transfered the content of the CRUX 2.1 handbook to a wiki page [1], which looks quite nice IMHO. All the other wiki pages should be in place as well, if you miss something please drop a note. Well, left over is the update of [1] for CRUX 2.2. Feel free to add or modify the corresponding sections. Volunteers wanted ! best regards Juergen [1] http://crux.nu/Main/Handbook2-2 -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux

1 0

[clc-devel] 2.2-test1 test ISO @ http://crux.nu/~jw/2.2/
by Johannes Winkelmann 25 Mar '06

25 Mar '06

Hey, As you certainly realized we have a little delay, but as our direct competitors [1,2]. However, here's a test ISO for 2.2-test1, with a working setup. The post-setup stuff I added is non-functional, i.e. it will just print "Usage: /usr/bin/post-setup <root>" in the very end. You can run "/usr/bin/post-setup /mnt" (or whatever rootfs you've chosen to see what it would do; it's still just echos, no real actions are performed on your live system. I'll upload a functional ISO later today, or tomorrow at the latest. I've so far tested: - install in qemu - update 2.2 -> 2.2 I'm about to test: - update 2.1 -> 2.2, doing manually what post-setup tells me it would do. This ISO has 2.6.16 which seems to cause data corruptions on some laptops, so please _don't_ use this on a productive system. Other than that, any kind of testing is appreciated; if possible, I'd like to announce this beginning next week (i.e. 2.2-test1), and see how the testing goes; april 1st is probably a bit early to release, but as I said earlier we can announce it then anyway, in a bundle with duke nukem forever (quote from #crux) :-). Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net

4 9

[clc-devel] Setup for 2.2
by Johannes Winkelmann 21 Mar '06

21 Mar '06

Hi there, In order to allow a smooth upgrade to 2.2, we need some extensions to setup. That's mainly three things: - installing udev and friends - renaming pkgconfig to pkg-config - and removing devfsd there are probably more of each kind, but those are the general use cases. I made a patch (currently untested) which allows the above. It's meant to get the discussion going. If we settle for a different solution I'm perfectly fine with that. Here's the patch: http://jw.tks6.net/files/crux/setup-upgrade-config.diff It basically allows to ship an additional file which defines packages to be injected, packages to be removed, and packages to be renamed. My test file looks like this: ------- [http://jw.tks6.net/files/crux/setup-2.2.conf] # update from 2.0/2.1 to 2.2 UPGRADE_INJECT="udev pciutils libusb" UPGRADE_REMOVE="devfsd" UPGRADE_RENAME="pkgconfig:pkg-config x11:xorg" ------- The x11 renaming is just a test case, obviously. Currently, the script checks for the existence of /etc/setup.conf, and sources it if it's there. The upgrade cleanup is ran after the regular update procedure, and prints some information to stdout, telling the user what it just did. A couple of notes: - I couldn't test this yet, I'll do it later today when I get home; my goal is that you can update from a clean 2.1 install directly to 2.2, assuming that you use a proper kernel. - We should probably have that for 2.2-test1, since otherwise manual interaction is needed when updating from 2.1 (even if it's already udev enabled); this unfortunately means that we have to delay it - I'm not sure if it's ever nice to remove packages; maybe we should rather tell the user to remove them manually, so he/she can backup configuration files if that's wanted If someone has the time to check my patch and comment, that would be great, since as I said before I think we should have that on 2.2-test1. Additionally, here's a trivial patch to not search for contrib ports on the ISO anymore: http://jw.tks6.net/files/crux/setup-no-contrib.diff If there are no objections, I'll commit that this evening. Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net

1 1

[clc-devel] [PROPOSAL] Wiki-Handbook
by Daniel Mueller 20 Mar '06

20 Mar '06

Hmm, what do you think? http://crux.nu/wikka.php?wakka=Handbook bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A

6 11

[clc-devel] [PROPOSAL] info & manpages
by Daniel Mueller 19 Mar '06

19 Mar '06

Hi there, I really start to miss the "info" pages. Okay, the "pager" (info(1)) isn't that great. But nowadays a lot of GNU programs have only a rudimentary/limited manpage supplied. The additional/interesting stuff was summarized in an info document. To give an example: 'grub'. The manpage is of no relevance. In fact you get more information if you just type '/sbin/grub --help' Grub's manpage explains its lack of information as follows: SEE ALSO The full documentation for grub is maintained as a Texinfo manual. If the info and grub programs are properly installed at your site, the command info grub should give you access to the complete manual. What do you guys think? Can we dare to add info pages? :-) bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A

5 4

[clc-devel] [PROPOSAL] Formalize the release process
by Simone Rota 19 Mar '06

19 Mar '06

Hi, A couple of days ago I had a brief discussion with Johannes regarding the 2.2 release, he suggested to post this as a proposal so we can abuse the new proposal process :) What I'd really like to see now that Per's gone for gold is a more defined release plan (also for future versions); I'm talking about formalizing a bit what happens when a new release is on the way. In our case that could be: 1. Someone builds devtest isos. These are for testing ISO ports only and get the core system into a consistent state. During this period: - The trunk only contains the ports that are on the ISO - the previous version port tree get all the updates and continues to work as usual. (I think the devtest phase is generally the longest one) 2. Once we're satisfied with the most recent devtest, we release a RC. The RC has a n-days lifespan (say 14). During these days: - maintainers will test and update their ports for the RC - only security fixes goes into the prev. release port tree - no changes are made to the core/opt ports included in the ISO to favour consistency. 3. If there are no reported problems the RC becomes the final release (otherways another RC is published). After the release: - port updates are generally applied only to the newly released port tree - we should keep a period in which we backport security fixes to the old port tree (we may as well have a dedicated volunteer / contributor) I'm not trying to be pedantic or to debianize CRUX, it's only that I think this would really help us optimize our limited workforce and help both developers and users make the switch to a new release. What do you think about it? -- Simone Rota Bergamo, Italy - http://www.varlock.com

2 1