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

[arch-dev-public] Flyspray cleanup
by Aaron Griffin 29 Feb '08

29 Feb '08

Hey guys, I moved a few users around in the global groups on flyspray. Roman and thayer are now in the "Developers" group, and I removed some of the straggling devs still listed there. If anyone has any other things to clean up, let me know. Danke, Aaron

3 6

[arch-dev-public] [signoff] attr 2.4.41-1 and acl 2.2.47-1
by Thomas Bächler 29 Feb '08

29 Feb '08

Version bums for attr and acl, please sign off.

4 4

[arch-dev-public] FHS manpages (was: [signoff] iptables 1.4.0-1)
by Dan McGee 28 Feb '08

28 Feb '08

On Thu, Feb 28, 2008 at 1:54 PM, Eric Belanger <belanger(a)astro.umontreal.ca> wrote: > > On Thu, 28 Feb 2008, Thomas Bächler wrote: > > > Roman Kyrylych schrieb: > >> 2008/2/26, Dan McGee <dpmcgee(a)gmail.com>: > >>> On Tue, Feb 26, 2008 at 9:04 AM, Thomas Bächler <thomas(a)archlinux.org> wrote: > >>> > In addition to a version bump, I changed the simple_firewall.rules file > >>> > to a more generic and correct configuration. > >>> > > >>> > Please sign off. > >>> > >>> > >>> Seems to be OK here. Signoff i686. > >> > >> same here. > >> > > > > anyone for x86_64? > > > > > > Man pages are not FSH compliant. No signoff from me. Do we have a namcap check for this yet? If not, the 'usr/man' part could be removed from directoryname.py and at least that check would then point out files in non-standard dirs. -Dan

4 4

[arch-dev-public] [signoff] grub 0.97-11
by Thomas Bächler 28 Feb '08

28 Feb '08

Sorry for dropping off the radar lately, I am not sure what happened myself, but I have been away from all Arch work for two weeks. I corrected my grub -10 package and fixed the bugs mentioned by Andy. Please sign off.

4 3

[arch-dev-public] [signoff] kernel26 2.6.24.3-1
by Thomas Bächler 28 Feb '08

28 Feb '08

Bumped to the .3 kernel, tested on both architectures, please sign off.

3 2

[arch-dev-public] [signoff] libarchive 2.4.12
by Dan McGee 27 Feb '08

27 Feb '08

Minor version bump. If pacman/makepkg still work OK and bsdtar can extract archives, we're good to go. Can someone build x86_64 for me? Aaron's machine is down. -Dan

5 5

[arch-dev-public] Module blacklisting
by Aaron Griffin 26 Feb '08

26 Feb '08

Ok, guys - honest question. Because udev is being a big pain in the ass with the way we do module blacklisting, we might want to reevaluate it. Right now we support blacklisting of modules in rc.conf, in addition to a kernel param disablemodules=x,y,z Udev autoloading is controlled by MOD_AUTOLOAD and the load_modules kernel param. We *can* use modprobe based blacklisting here, but we lose the above items. blacklisting will be controlled only by /etc/modprobe.conf (and modprobe.d/*) and we lose the ability to shut it off via rc.conf. What do we gain? Speed and simplicity. No extraneous scripts to handle this stuff, and all that jazz. This is how fast this script was when I originally wrote it: http://img.phraktured.net/other/udev_modules_boot.png Now it apparently takes 3 times as long due to all the added blacklisting cruft What do we lose? Robustness. See below for an explanation of the blacklist changes On Fri, Feb 22, 2008 at 3:47 PM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Fri, Feb 22, 2008 at 3:29 PM, Michal Soltys <soltys(a)ziu.info> wrote: > > modprobe supports blacklisting itself in modprobe.conf (to be precise - it > > blacklists all aliases for specified modules, which is exactly what's needed > > here). You can use raw modprobe and probably speed up things nicely, without > > any extra scripts. > > modprobe's blacklisting is terrible. It is meant to be used with > conflicting aliases. Here's the actual usecase: > > module foo contains an alias "blah" > module bar contains an alias "blah" > > If I modprobe blah, it doesn't know which to do. So, blacklisting > "bar" tells modprobe ONLY to ignore the aliases exposed by bar. I can > still modprobe bar by a non-alias name, and I can still load bar as a > dependent module. > > So, the way we handle it, is such that blacklisting "bar" makes it so > that no other module that depends on bar can load it without you > saying so. This is the main benefit. Want to shut off sound? blacklist > "snd" or "soundcore"

7 13

[arch-dev-public] [signoff] fakeroot 1.9.3-1
by Andreas Radke 26 Feb '08

26 Feb '08

a minor update. in testing for both arches. http://packages.debian.org/changelogs/pool/main/f/fakeroot/fakeroot_1.9.3/c… fakeroot (1.9.3) unstable; urgency=medium * configure.ac: patch from Ralf Wildenhues to not override $SHELL late in configure.ac, by means of undocumented Autoconf interface _AS_DETECT_REQUIRED to require $(...) command replacement. closes: #447022. -Andy

4 5

[arch-dev-public] Interesting post-install messages (jack-audio-connection-kit and ardour)
by Jason Chu 25 Feb '08

25 Feb '08

I updated my machine and saw these two post-install messages back to back: ( 1/40) upgrading jack-audio-connection-kit [#####################################################################################] 100% --> It is recommended to use qjackctl as a controlling frontend for the --> audio server. The extended rights for realtime capabilities can be --> granted based on groups or a per user base in --> /etc/security/limits.conf --> The audio server comes with a daemon script that runs it as root. --> Configuration happens in /etc/conf.d/jack-audio-connection-kit and is --> documented there. --> NOTE: Running jack as root to enable realtime capabilities isn't --> needed any longer. ( 2/40) upgrading ardour [#####################################################################################] 100% --> You need to have jack running before you start ardour. There are two ways --> to have ardour and jack running: --> - as root with realtime capabilities --> - as oridinary user without realtime capabilities --> You have to make sure, that ardour and jack run as the same user - mixing --> up fails. --> RUNNING AS ROOT IS ALWAYS A RISK FOR THE SECURITY! --> Also consider to use qjackctl to control jack. Note, that also qjackctl --> has to run as the same user as ardour. Don't forget to check out --> qjackctl's patchbay and read the docs from http://ardour.org ! So which one is it? Do I have to run jack and ardour as root or can I not? I'm pretty sure the jack message is more recent than the ardour one, so running jack non-root will work fine with ardour and still have realtime capabilities. Maybe we need to update the ardour post-install message. I just had a little laugh reading them both. Jason

1 0

[arch-dev-public] [signoff] e2fsprogs 1.40.5-2 and grub 0.97-10
by Thomas Bächler 25 Feb '08

25 Feb '08

The request for e2fsprogs was there before, but not as a top-level post, so I am re-posting it: e2fsprogs 1.40.5-2: - Changed default inode_size in /etc/mke2fs.conf from 256 back to 128. This fixes backwards-compatibility with everything older. New behaviour can still be achieved using the -I 128 command to mke2fs or by editing mke2fs.conf grub 0.97-10 - Added previously posted patch to support bigger inode size - Removed the long obsolete /usr/share/grub -> /usr/lib/grub symlink Please sign off on both. I tested grub on x86_64 with my old inode size 128. To sign off, please copy the necessary files from /usr/lib/grub/i386-pc to /boot/grub and reinstall grub into the MBR (anything less is insufficient). Could someone also test with inode size 256?

4 5