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

[arch-dev-public] [signoff] groff 1.20.1-4 (1 for each arch)
by Paul Mattal 09 Mar '10

09 Mar '10

This is a bugfix for our site.tmac file. Nothing else is changed. Previously, if you ran: $ zcat /usr/share/man/man1/groff.1.gz | groff -man -Tps > foo.ps this you'd get an initial blank page in your output, and a warning: grops:<standard input>:6: X command without `ps:' tag ignored This was due to errant whitespace in our site.tmac file, as pointed out in: http://bugs.archlinux.org/task/15479 Please sign off by testing a few manpages and, if you really want to go all out, test the commandline above and see the improved result. - P

3 2

Re: [arch-dev-public] [arch-general] Moving to pkg.tar.xz officially?
by Giovanni Scafora 09 Mar '10

09 Mar '10

Il 09/03/2010 11:23, Allan McRae ha scritto: > Why... namcap in testing works fine. Well, what about moving testing/namcap to extra? -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

1 0

[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