September 2008 - crux-devel

[PATCH] util-linux-ng / mount: mtab created multiple times with -a option
by Jonas Kramer 30 Sep '08

30 Sep '08

Ahoy, some of us had the problem that the "mount -a" in /etc/rc printed "warning: couldn't open /etc/mtab: ..." and that afterwards there were lots of root-fs entries in /etc/mtab. I looked into the problem and found that it is a bug in util-linux-ng 2.14.1, in the mount command. I sent a patch to the util-linux-ng mailing list, but I don't know how long it will take until the patch is in upstream and upstream is updated in the CRUX ports, so I just forward the patch to this list. Feel free to patch your own util-linux-ng ;) However, the warning doesn't go away, since /etc/mtab really isn't there (it's deleted in /etc/rc for some reason), but /etc/mtab isn't that messy anymore. Regards, Jonas Kramer ----- Forwarded message from Jonas Kramer <jkramer(a)nex.scrapping.cc> ----- Date: Tue, 30 Sep 2008 22:36:18 +0200 From: Jonas Kramer <jkramer(a)nex.scrapping.cc> Subject: [PATCH] mount: mtab created multiple times with -a option To: kzak(a)redhat.com User-Agent: Mutt/1.5.18 (2008-05-17) Ahoy. Since util-linux-ng 2.14.1, the following problem occurs with mount. When /etc/mtab does not exist and mount is called with -a, for every mount point that is mounted a root-fs record is added to mtab. This is because get_mtab_info() sets the flag mtab_does_not_exist to 1 when it doesn't find /etc/mtab. However, if it actually finds /etc/mtab, the variable is not reset to 0. So on every subsequent call to get_mtab_info() (as it is the case when mounting several mount points with the -a option), mount will think that /etc/mtab does not exist, even if it was created in the meantime by mount itself. Additionally, create_mtab() does open /etc/mtab with "a+" even though it is only called when mount thinks that /etc/mtab does not exist. So for every mount point that is mounted with -a, another root-fs entry is added to /etc/mtab. The attached patch seems to fix that. Regards, Jonas Kramer -- diff --git a/mount/fstab.c b/mount/fstab.c index 895fd2c..eb38822 100644 --- a/mount/fstab.c +++ b/mount/fstab.c @@ -30,13 +30,20 @@ static int var_mtab_is_a_symlink = 0; static void get_mtab_info(void) { - struct stat mtab_stat; - if (!have_mtab_info) { + struct stat mtab_stat; + if (lstat(_PATH_MOUNTED, &mtab_stat)) var_mtab_does_not_exist = 1; - else if (S_ISLNK(mtab_stat.st_mode)) - var_mtab_is_a_symlink = 1; + else { + var_mtab_does_not_exist = 0; + + if (S_ISLNK(mtab_stat.st_mode)) + var_mtab_is_a_symlink = 1; + else + var_mtab_is_a_symlink = 0; + } + have_mtab_info = 1; } } ----- End forwarded message ----- --

1 0

IRC meeting on the 2.5 release tomorrow
by Johannes Winkelmann 29 Sep '08

29 Sep '08

Hi there, There have been some of preparations for the 2.5 release already (see Tilman's mail), and from what I can see now nothing is stopping us from starting the 2.5 test cycle. To get things going, let's discuss open issues at tomorrow's IRC meeting (20:00 CEST, #crux-devel). If you can't make it, please post your concerns/ideas/requests here on this list. Thanks for your interest, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

1 0

ATN: nvidia and ati ports
by Lucas Hazel 22 Sep '08

22 Sep '08

The new mesa3d port no longer uses libGLcore, so gl-select does not need to handle these files anymore[1]. It is safe for the nvidia and ati ports to own these files. Please update your ports to reflect these changes as soon as possible. [1] http://crux.nu/gitweb/?p=ports/opt.git;a=commit;h=e0beb0566ca8ab771e90f0da9… -- Lucas Hazel <lucas(a)die.net.au>

1 0

[RFC] experimental dmcrypt support
by Thomas Penteker 18 Sep '08

18 Sep '08

Hello, I set up a wiki page for discussing a possible inclusion of dmcrypt support (+ fully encrypted '/') in CRUX. It lives here: http://crux.nu/Wiki/cryptsetup Comments / Criticism / Suggestions welcome! kind regards, Thomas Penteker --

1 0

2.5 preparations
by Tilman Sauerbeck 16 Sep '08

16 Sep '08

Hi, I've branched off core.git for 2.5, and imported a few of Juergen's new and updated ports etc. There's also a wiki page that lists the remaining tasks for 2.5, see http://crux.nu/Wiki/TODO25. That page will probably grow a bit more; it's certainly not the definitive list yet. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

1 0

[RFC] use GNU inetutils for core-ports inetd, netkit-ftp, netkit-telnet
by Juergen Daubert 10 Sep '08

10 Sep '08

Hello, our core-ports inetd, netkit-ftp and netkit-telnet are all based on the very old and unmaintained netkit-* programs and are heavily patched to get more functionality, like IPv6, or even to build with newer compilers. I'd suggest to use the GNU inetutils i[1] for that purpose instead, because they are actively maintained [2] and direct replacements. I think it's easy to decide on this, but I have more problems with the package names, because a netkit-ftp build from inetutils sounds not very sensible to me. I think we have some options here: 1. Keep names as they are 2. Keep inetd, rename netkit-ftp to inetutils-ftp and netkit-telnet to inetutils-telnet 3. Keep inetd, rename netkit-ftp to ftp and netkit-telnet to telnet 4. Rename all to inetutils-{inetd,ftp,telnet} 5. Replace inetd, netkit-ftp and netkit-telnet with one port called inetutils 6. ? I tend to option 5 because it's the easiest way to maintain, the binaries are very slim and we reduce the number of core ports. Even options 3 and 4 are looking more consistent to me as our current situation. Opinions? best regards Juergen [1] http://directory.fsf.org/project/inetutils/ [2] http://news.gmane.org/gmane.comp.gnu.inetutils.bugs http://news.gmane.org/gmane.comp.gnu.inetutils.cvs -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux

7 7

[RFC] toolchain for CRUX 2.5
by Juergen Daubert 08 Sep '08

08 Sep '08

Hi all, as a very first step in direction to a CRUX 2.5 release I've prepared ports that might be possibly used for our tool-chain. For now the ports are available in my personal repo [1], bootstrapped packages can be obtained from [2]. Some notes: * binutils 2.18.50.0.9 Because regular updates from upstream are very occasionally, I thought that using the ones hosted/maintained on kernel.org [3] might be an option for us. The drawback is, that the man-pages are not prebuild, so texinfo is a build requirement. Sure, we can patch binutils and provide a tarball with the man-pages, but I'd prefer to add texinfo to our toolbox because I run into similar problems with other ports as well. * glibc 2.8 with kernel-headers 2.6.26 Tarball created from cvs with -r glibc_2.8-branch which includes one patch after the glibc_2.8 tag [4]. Remember, locales are not generated, see this thread in crux-devel [5]. * gcc 4.3.2 It's the same Tilman has committed to core-x86_64, with some minor adjustments. New dependencies are libgmp and libmpfr, both are available in [1] too. best regards Juergen [1] httpup sync http://jue.li/crux/ports/ jue [2] http://jue.li/crux/tmp [3] http://ftp.kernel.org/pub/linux/devel/binutils/ [4] http://sourceware.org/ml/libc-alpha/2008-04/msg00050.html [5] http://lists.crux.nu/pipermail/crux-devel/2008-July/003681.html -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux

2 2

[RFC] add keymap support to hal
by Lucas Hazel 05 Sep '08

05 Sep '08

I've encountered a footprint mismatch for hal on my system NEW -rwxr-xr-x root/root usr/bin/hal-setup-keymap NEW -rw-r--r-- root/root usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi After some investigation, I have discovered this is due to having gperf installed which hal uses to map all those extra keys for non standard keyboards, that many laptops have for example, that are not supported by X. Is this a feature we want, or should I keep the port completely minimal? -- Lucas Hazel <lucas(a)die.net.au>

2 1