December 2010 - Arch-general - lists.archlinux.org

[arch-general] PulseAudio in [testing]
by Jan Steffens 13 Dec '10

13 Dec '10

I've put PulseAudio into [testing] some time ago, but received no feedback on this. This either means it works well, or nobody uses it. So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.

27 69

[arch-general] [signoff] kernel 2.6.36.2-1
by Tobias Powalowski 13 Dec '10

13 Dec '10

Hi guys, please signoff 2.6.36 series for both arches, Please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

[arch-general] [dbscripts] What's needed to support overriding arch in split packages?
by Evangelos Foutras 13 Dec '10

13 Dec '10

makepkg and devtools are already capable of building split packages with different architectures. A particular case of interest is foo-data split packages which usually are much bigger than their arch-dependent counterparts. Currently, a separate PKGBUILD is required to convert these data packages to be arch-independent, which complicates maintenance needlessly. I had a look at the db-update and db-function scripts, but the code is hard to follow for someone new to it. Therefore, I'd like to ask for opinions from people who've worked on them and have a general knowledge of how they work and how this could be implemented. My idea is to make a special case for arch-dependent PKGBUILDs, to allow for arch=('any') split packages, without necessarily parsing the package_foo-data function. What do you think?

1 0

[arch-general] [signoff] lvm2/device-mapper 2.02.78-1
by Eric Bélanger 13 Dec '10

13 Dec '10

Hi, lvm2/device-mapper 2.02.78-1 are in testing. Please test and signoff. Signoffs from users are welcome. - Minor upstream update. ChangeLog below. Version 2.02.78 - 6th December 2010 =================================== Abort if segment tag allocation fails in pool format _add_stripe_seg. Abort in _mirrored_transient_status if referenced log/image LV is not active. Add backtraces for dev_set() and dev_close_immediate() errors in set_lv(). Log any unlink() error in clvmd remove_lockfile(). Log any pipe write() or close() errors in clvmd child_init_signal(). Detect if orphan vginfo was lost from cache before _lvmcache_update_vgname(). Do a full rescan if some device is missing in lvm1 format read_pvs_in_vg. Add missing check that dm_pool_create succeeded in write_config_node(). Use dm_snprintf in clvmd-command.c to ensure an overlong buffer is truncated. Don't write to buffer if its reallocation failed in clvmd do_command(). Switch from float to fixed point percentage handling. Avoid misleading missing PV warnings in vgextend --restoremissing. Fix memory leak when VG allocation policy in metadata is invalid. Ignore unrecognised allocation policy found in metadata instead of aborting. Factor out tag printing into _out_tags and avoid leaking string buffer. Remove some unused variables & assignments. Add missing vg_release calls in _vg_read_by_vgid. Fix debug logging of derived flag LCK_CACHE in clvmd. Fix test for no system_dir in _init_backup(). Disallow lvconvert ops that both allocate & free supplied PEs in a single cmd. Fix liblvm seg_size to give bytes not sectors. Add functions to look up LV/PV by name/uuid to liblvm. Free cmd_context if fallback to LVM1 fails in lvm2_main(). Free device name buffer in dmsetup parse_loop_device_name() error paths. Close format lib if init_format_fn fails in _init_formats(). Don't leave /proc/mounts open after dmeventd snapshot event processing. Fix out-of-scope arg_vgnames use in process_each_lv(). Remove incorrect dm_task_destroy(NULL) from _node_clear_table() error path. Add missing closedir in _rm_blks after removing stray LVM1 VG files. Suppress 'No PV label' message when removing several PVs without mdas. Fix default /etc/lvm permissions to be 0755. (2.02.66) Version 1.02.59 - 6th December 2010 =================================== Add backtraces to _process_mapper_dir and _create_and_load_v4 error paths. Remove superfluous checks for NULL before calling dm_free.

1 0

[arch-general] Bizarre grub drive number switch from (hd1, 5) to (hd2, 5) but no hd2 defined???
by David C. Rankin 13 Dec '10

13 Dec '10

Guys, I have managed to get myself in a number of messes over the years, but usually when I figure out what went wrong, I understand why. Here, I'm at a complete loss. I was going to preserve my existing kernel through update and I described in an earlier email. (I'm still on kernel26-2.6.36.1) So I created a custom initramfs and preserved the module tree and added the entries to grub menu.lst. This box has always booted arch on (hd1,5) a device mapper array. (hd0) is another device mapper array with an old suse install on it. However, after I made may changes and went to reboot to test the custom initramfs, I got a grub 13 error for an invalid executable?? So I booted with the Arch 2010.05 install disk and chrooted my existing install and looked at grub. When I did my grub > find /boot/grub/stage1, grub reported stage1 on (hd0,4) (hd2,4) WTF? I don't have an hd2 and what the heck happened to hd1?? [01:42 archangel:/boot/grub] # cat device.map (hd0) /dev/mapper/nvidia_fdaacfde (hd1) /dev/mapper/nvidia_baaccaja (fd0) /dev/fd0 So I decided to give booting to hd2 a try. So I reconfigured the suse menu.lst file to call (hd2,5) to boot Arch, and I redid the Arch menu.lst to point everything at (hd2,5) instead of (hd1,5) and rebooted. To my shock and surprise - it booted just fine with all the drive number flipped from 1->2. This makes no sense whatsoever to me. How does my device.map still correctly define my (hd0) and (hd1) arrays, but grub spontaneously require booting to /dev/mapper/nvidia_baaccaja on (hd2). Damndist thing I've ever seen. It goes without saying, but I am at a complete loss as to 'what happened' and 'why it happened'. I can't even think of any way it 'could have happened'. All I did was run mkinitcpio twice to create the custom initramfs that I would use to preserve the existing kernel when I updated by running: mkinitcpio -k 2.6.36-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr.img mkinitcpio -k 2.6.36-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr-fallback.img \ -S autodetect And when I rebooted, I ended up in this mess. So what say the experts. Does anybody see a way running mkinitcpio as I did above could cause the grub root to change from hd1 to hd2? I don't see how it could happen. If that isn't the culprit, does anybody have any other ideas on how this could have happened? Thanks for any insight you can give. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

1 1

[arch-general] Fluxbox broken when launched via qingy
by David Rosenstrauch 13 Dec '10

13 Dec '10

Not sure what happened, but fluxbox seems to be broken when launched via qingy. This used to work fine, and I haven't changed anything in my fb or qingy setups that could account for this. I'm able to launch other WM's via qingy, and am also able to launch FB via other desktop managers (e.g., slim) so it's something unique to this combination that's causing the problem. More details here: https://bbs.archlinux.org/viewtopic.php?pid=863357 Anyone else seeing this and/or have ideas on how to fix? TIA, DR

2 5

Re: [arch-general] [arch-dev-public] glibc and minimum kernel version
by Tom Gundersen 12 Dec '10

12 Dec '10

On Sun, Dec 12, 2010 at 6:38 AM, Stéphane Gaudreault <stephane(a)archlinux.org> wrote: > I think that udev >= 145-1 requires a minimum kernel version of 2.6.24.5[1], > so building glibc for anything older may not make sense. udev >= 147 requires a minimum kernel version of 2.6.27. Cheers, -t

1 0

[arch-general] VirtualBox_bin 3.12 - slow system freeze on i686, OK on x86_64
by David C. Rankin 12 Dec '10

12 Dec '10

Guys, just a heads up for those that use virtualbox_bin from AUR: I experienced a system freeze problem on a dell P4 box with VirtualBox-3.2.12 causing the machine to slowly freeze, become unresponsive, then hardlock. WinXP (guest) starts fine, but then it will freeze, followed by the kde taskbar, and then a minute or two later, the mouse and keyboard freeze and the box is locked. (hard reset required) I went through this lockup process twice to make sure. Downgrading to VirtualBox-3.2.10 solved the problem for me. Prior to updating the i686 box, I did another VirtualBox-3.2.12 upgrade on a x86_64 box (XP guest as well), and all is working well. So it looks like it may be some issue or memory leak that is killing the i686 package. I (and others) have dropped notes with the AUR package. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 2

Re: [arch-general] [arch-dev-public] glibc and minimum kernel version
by Matthew Monaco 11 Dec '10

11 Dec '10

On 12/11/2010 10:49 AM, Allan McRae wrote: > Hi, > > I am in the progress of updating the toolchain and thought it time to review > what our minimum required kernel version is for glibc. > > For those that do not know, assuming a newer kernel allows glibc to have less > workarounds compiled in. So it may be advantagous to have a more recent version > as the minimum required. This comes at the obvious cost of not having support > for older kernels so a tradeoff is needed... When we discussed this 18 months > ago, it was decided 2.6.18 was appropraite then, but much has changed since. > > I am going to suggest that we follow the oldest longterm support kernel. That > would now be the 2.6.27.x series, which has been around for over two years. > > That might be being overly bold, so feel free to point out how much such an > update would break... and suggest an alternative minimum. > > Allan > The workarounds obviously make maintainence a little more difficult, but is there a performance hit too? Could a glibc and glibc-legacy/glibc-compat type of thing be a viable solution? Then the question would be what kernel defines the line between the two glibc packages (probably -lts would be good).

1 0

[arch-general] perl 5.12.2 anytime soon? or just going to wait for 5.12.3 or 5.14.1
by Caleb Cushing 11 Dec '10

11 Dec '10

perl 5.12.2 came out at the end of august... I'm just wondering if we'll be getting it... 5.12.3 should come out... I'd rather never see a stable 5.14.0 because 5.14.1 should follow a month later... and given the current speed of updated perls in arch... -- Caleb Cushing http://xenoterracide.com

1 1