- Arch-dev-public - lists.archlinux.org

[arch-dev-public] Automating creation of i686 chroots on x86_64 systems with mkarchroot.
by Daniel J Griffiths (Ghost1227) 09 Mar '10

09 Mar '10

I've always thought the method of modifying your local mirrorlist, running mkarchroot, then reverting the changes to be more tedious than necessary for creation of i686 chroots on x86_64. My recent work with setting up a dedicated build server gave me plenty of time and an excuse to actually do something about it. As such, I've put together a little patch that allows specification of creation of an i686 chroot at runtime. When set, this flag will automatically modify your local mirrorlist, create the requested i686 chroot, then revert the changes to the mirrorlist file. I don't know if others would find this useful or not, but I figured it wouldn't hurt to post it.

5 14

[arch-dev-public] Install files in [core]
by Allan McRae 08 Mar '10

08 Mar '10

Hi, With adding install files to deal with info pages to packages in [core], there are a number of packages with install files that will cause errors if bash is not installed before them (pacman uses /bin/sh from the system it is installing to). An incomplete list: binutils diffutils ed filesystem (also needs coreutils for chmod) findutils gcc-libs (fixed in git) gdbm gettext gmp gpm How do we handle this? Add "sh" to dependencies? Not have post_install for these packages (it is only info page installs...)? I did the later for gcc-libs where it makes sense but other cases are not so clear cut. Allan

3 7

[arch-dev-public] kernel headers in a separate package
by James Rayner 08 Mar '10

08 Mar '10

Apparently it's taken me 2 months to notice this because I've been building my own kernel, but I'll ask anyway... The kernel headers required to build kernel modules have been put in a separate package "kernel26-headers". We don't separate dev headers for anything else - why is this different? Second, linux-api-headers used to be called "kernel-headers" and now there's easily 100 posts on the forum that say "the headers don't need to match the kernel" - which are all now completely incorrect. Thoughts?

3 2

[arch-dev-public] xorg-server expertise
by Paul Mattal 07 Mar '10

07 Mar '10

I'm trying to build xorg-server from git, in order to bisect some bad behavior. It appears the tarball releases and what's in git aren't the same, though. Right out of the gate, I get: configure.ac:42: error: must install xorg-macros 1.2 or later before running autoconf/autogen configure.ac:42: the top level autom4te: /usr/bin/m4 failed with exit status: 1 ==> ERROR: Build Failed. Aborting... Is there any straightforward way to easily build packages from bisect-identified revisions so that I can properly test? - P

2 1

[arch-dev-public] [signoff] dbus-core 1.2.20
by Jan de Groot 07 Mar '10

07 Mar '10

This update skips a release and updates from 1.2.16 to 1.2.20 + one git commit. To see the upstream changes, take a look at http://cgit.freedesktop.org/dbus/dbus/log/?h=dbus-1.2 starting from the 1.2.16 tag. Local changes: - remove from base group - fix user/group removal in post_remove/pre_remove - add patch from post-1.2.20 git to monitor service directories

3 2

[arch-dev-public] Fixing groupadd
by Allan McRae 07 Mar '10

07 Mar '10

Hi, At the moment, groupadd always creates system groups with GID=99. (http://bugs.archlinux.org/task/16092) We can fix this by adding something quite standard like: SYS_UID_MIN = 100 SYS_GID_MIN = 100 SYS_UID_MAX = 999 SYS_GID_MAX = 999 in /etc/login.defs But this will lead to possible issues with packages using fixed GID >= 100. e.g. I could create a bunch system groups and then install a package who has predetermined that an already used group ID is for it. There are two possible solutions: 1) Set SYS_{U,G}ID_MIN to (e.g.) 500 and have all packages use numbers below 500. 2) Have the packages create a group without a specified ID. Anything requiring a fixed group ID at compile time (e.g. mailman) must use a number < 100. I am in favour of #2 (slightly) as it seems the better solution, but #1 would only require shadow to be fixed and no rebuilds for other packages (the number of rebuilds for #2 would be very small). Opinions? Allan

4 9

[arch-dev-public] [signoff] mlocate-0.22.3-1
by Allan McRae 07 Mar '10

07 Mar '10

Upstream update - appears to be only additional man page translations. Signoff both, Allan

3 2

[arch-dev-public] Fwd: nvidia oops
by Aaron Griffin 07 Mar '10

07 Mar '10

Just forwarding this on. Is this important enough to post a news item about? Or should we just force-downgrade the affected drivers? ---------- Forwarded message ---------- From: Casey J. Peter <caseyjp1(a)gmail.com> Date: Sat, Mar 6, 2010 at 7:07 PM Subject: nvidia oops To: aaron(a)archlinux.org http://www.phoronix.com/scan.php?page=news_item&px=ODA0MA Might want to put something up on the main page to warn people. Its not effecting everyone, but the word is 3d gaming is the biggest part of this mess.

3 2

[arch-dev-public] Changed GNUstep directory in new windowmaker package
by Daniel Isenmann 07 Mar '10

07 Mar '10

Hi, today I have released a new release of the windowmaker package. The important change is the GNUstep directory. I have changed this to /usr/lib/GNUstep. It was requested as a bug report (http://bugs.archlinux.org/task/15301) and it’s now equal to Debian’s GNUstep directory location. That means, you have to change the directory for the WPrefs.App which has now the new location. All other things should be run without problems. If you have older GNUstep applications, you have to recompile them with the new location if they way located in the old GNUstep directory. -Daniel

1 0

[arch-dev-public] Automatic LVM assembly - call for testers
by Thomas Bächler 06 Mar '10

06 Mar '10

Traditionally, LVM is assembled by running "vgchange -ay" manually. That has several problems, especially if one of the physical volumes is missing when the VG was supposed to be assembled. This has been experienced by people who use LVM on USB storage for their root device. I came up with a way of assembling LVM automatically through udev: A udev rule combined with a short shell script waits until all required physical volumes have been detected, then assembles the volume group in the background. This also works when adding a removable device to the system at any time. I'm asking anyone with LVM and a bit of spare time to test this. I'm especially interested in results from people who have a volume group on more than one hard drive. This is how it works: Get the package from: http://dev.archlinux.org/~thomas/lvm_autoassemble/ If you want to use this for detection of your boot device: Replace the "lvm2" hook with the "lvm_autoassemble" hook in mkinitcpio.conf and recreate the initramfs (make sure to keep a copy of the working one, as always). Possible side-effects: There may be some trouble when dealing with removable devices that contain LVM physical volumes: The volume groups are automatically activated, but have to be deactivated manually before removing the drive. Furthermore, when you remove a device and add it again later, the mechanism that detects whether all PVs have been found might fail and "vgchange -ay" may be run too often. Another side-effect is that I didn't add --ignoremonitoring to the script, so dmeventd may be started in initramfs (for mirror or snapshot volumes), which may not be desired. Any feedback is welcome.

2 1