- Arch-general - lists.archlinux.org

[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

[arch-general] [signoff] udev-164-3
by Tobias Powalowski 11 Dec '10

11 Dec '10

Hi guys, - fixed libusb-compat depend Seems I forgot to add it to the depend line. Please signoff both arches to fix this missing depend. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-general] Setuptools broken?
by Norbert Zeh 10 Dec '10

10 Dec '10

Hi folks, With the python upgrade from 2.7 to 3.1, I ran into the following snag. gitosis from AUR depends on python and setuptools. Now, python = python3.1 now and setuptools installs in the python2.7 library tree. This was easy enough to fix, by simply replacing python with python2 in the gitosis PKGBUILD. However, I would expect that python2 will disappear completely somewhere down the road. What then? Moreover, being a purist, I would like to avoid having two python versions installed on my machine. So what's the deal with python3.1 and setuptools? Is the procedure for installing python packages different under 3.1 than under the old 2.x series, and there simply are no setuptools any more? If that's the case, I guess it's the responsibility of package maintainers to migrate to the setup used in python3.1. If setuptools is still what is needed in python3.1, shouldn't there now be two packages setuptools and setuptools2 that install in the library trees of python3.1 and python2.7, respectively? (I'm happy to file a bug report if this is indeed a bug.) Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

33 64

[arch-general] State of the Repositories
by keenerd 09 Dec '10

09 Dec '10

If you have not played with Expac yet, you should! It is a brilliant program. Here is a small example of it in action. Feel free to tease me for the overuse of pipes. > find /var/abs -name 'PKGBUILD' | wc -l 3976 > grep -rc '|| return 1$' /var/abs | cut -d ':' -f 2 | awk '{s+=$1} END {print s}' 5929 > find /var/abs -name 'PKGBUILD' | xargs -n 1 -I '{}' grep -l '|| return 1$' '{}' | cut -d '/' -f 5 | sort > return_one > wc -l return_one 1923 return_one Half of the repo is littered with '|| return 1'. We've been assured it will be phased out as packages are updated. Sometimes this happens, sometimes not. Makepkg was fixed in 0.3.4, released on 2010-06-16. What packages have been updated since then? > expac -S -t '%F' '%b %n' $(pacman -Ssq) | sort > releases > awk '/2010-06-16/,EOF' < releases | cut -d ' ' -f 2 > updated > wc -l updated 3276 updated This is really depressing. Out of 3973 packages, 3276 have been updated in the last six months. No matter how you draw the Venn diagram, there is a large set of packages in the middle that must both contain '|| return 1' and have been recently updated. So which packages are they? > comm -12 return_one updated > lazy_packages > wc -l lazy_packages 590 lazy_packages Let's make a graph to show how bad it continues to be. > expac -S -t '%Y-%m' '%b' $(cat return_one) | sort | uniq -c | sed 's/^ *//' > return_one_releases http://kmkeen.com/tmp/return-one-releases.png If packages were actually cleaned up when updated, the red line would be flat on zero. Instead, 50-100 packages with 'return 1' are released every month. (And yes, the oldest surviving package is almost three years old. Happy birthday perl-passwd-md5, if you make it another month.) And finally > expac -S "%p" $(cat lazy_packages) | sort | uniq -Kyle http://kmkeen.com

4 3