[arch-general] [signoff] lvm2/device-mapper 2.02.76-1
Hi, lvm2/device-mapper 2.02.76-1 are in testing. Please test and signoff. Signoffs from users are welcome. - Minor upstream update. ChangeLog below. Version 2.02.76 - 8th November 2010 === Clarify error messages when activation fails due to activation filter use. Add pacemaker script VolumeGroup.ocf with configure --enable-ocf. Import make.tmpl into include/ Makefile. Fix handling of online filesystem resize (using new fsadm return code). Add DIAGNOSTICS section to fsadm man page. Modify fsadm to return different status code for check of mounted filesystem. Update VG metadata only once in vgchange when making multiple changes. Allow independent vgchange arguments to be used together. Automatically unmount invalidated snapshots in dmeventd. Suppress some superfluous messages from clang static analysis. Fix a deadlock caused by double close in clvmd. Fix NULL pointer dereference on too-large MDA error path in _vg_read_raw_area. Use static for internal _align_chunk() and _new_chunk() from pool-fast.c. Fix vgchange to process -a, --refresh, --monitor and --poll like lvchange. Add lvm2app functions to query any pv, vg, or lv property / report field. Version 1.02.57 - 8th November 2010 === Fix regex optimiser not to ignore RHS of OR nodes in _find_leftmost_common. Add dmeventd -R to restart dmeventd without losing monitoring state. (1.02.56) Fix memory leak of field_id in _output_field function. Allocate buffer for reporting functions dynamically to support long outputs.
Re: [arch-general] Wireshark 1.4.2 stops capturing packets
On Sun, 2010-11-21 at 16:07 +1000, Allan McRae wrote: On 21/11/10 14:08, mwnn wrote: Hi all, After capturing a random number of packets, the new wireshark-1.4.2 stops capturing packets. Bug reports work best going to the bug tracker and supplying more details. Allan This is an old bug that is hitting us again: https://bugs.archlinux.org/task/19769 Ionut took care of it. This is now fixed on 1.4.2-2. -- Guillaume signature.asc Description: This is a digitally signed message part
[arch-general] [pam/consolekit] Help needed for desktop permission handling
While packaging Xfce 4.7 I had to find a way to allow the desktop user to shutdown/reboot(consolekit), hibernate/suspend(upower),mounte removable devices(udisks). Recent display managers (gdm, kdm and lxdm) can handle their own polkit/consolekit session through pam access. The gnome/xfce4-session packages only have basic access to consolekit and since the consolekit 0.4.2 in testing they can't deal with it anymore. As a workaround I have plans to ship files in xfce4-session as proto files where the admin can add users or groups to allow certain actions: /etc/polkit-1/localauthority/50-local.d/org.freedesktop.upower.pkla and /etc/polkit-1/localauthority/50-local.d/org.freedesktop.consolekit.pkla and maybe one for udisk something like https://aur.archlinux.org/packages.php?ID=42669 . This could also be done each in the consolekit/upower/udisks packages. But all this is crap working around some nasty bugs in our pam pkg not allowing direct access to consolekit. Please have a look at https://bugs.archlinux.org/task/17188 https://bugs.archlinux.org/task/21391 Pam has an update pending (also fixing security related issues) and quiet a lot open bugs: https://bugs.archlinux.org/index.php?string=pamproject=1search_name=type[]=sev[]=pri[]=due[]=reported[]=cat[]=status[]=openpercent[]=opened=dev=closed=duedatefrom=duedateto=changedfrom=changedto=openedfrom=openedto=closedfrom=closedto=do=index So please someone with time and knowledge may have look (Tobias P. doesn't seem to have the time for this). If we can't menage to fix this until the Xfce release I'd like to know what you think could be a good and safe workaround (recommending power/storage groups?). Note: Gentoo seems also running into this pam/consolekit issue. Not sure about Ubuntu and Fedora(that does heavy pam configurations). -Andy
Re: [arch-general] Wireshark 1.4.2 stops capturing packets
On 11/21/2010 05:47 PM, Guillaume ALAUX wrote: On Sun, 2010-11-21 at 16:07 +1000, Allan McRae wrote: On 21/11/10 14:08, mwnn wrote: Hi all, After capturing a random number of packets, the new wireshark-1.4.2 stops capturing packets. Bug reports work best going to the bug tracker and supplying more details. Allan This is an old bug that is hitting us again: https://bugs.archlinux.org/task/19769 Ionut took care of it. This is now fixed on 1.4.2-2. Yes, I talked with Ionut on #archlinux and I tested it on i686 platform. mwnn
Re: [arch-general] [arch-dev-public] [signoff] lvm2/device-mapper 2.02.76-1
On 11/21/10 at 03:14am, Eric Bélanger wrote: Hi, lvm2/device-mapper 2.02.76-1 are in testing. Please test and signoff. Signoffs from users are welcome. - Minor upstream update. ChangeLog below. Version 2.02.76 - 8th November 2010 === Clarify error messages when activation fails due to activation filter use. Add pacemaker script VolumeGroup.ocf with configure --enable-ocf. Import make.tmpl into include/ Makefile. Fix handling of online filesystem resize (using new fsadm return code). Add DIAGNOSTICS section to fsadm man page. Modify fsadm to return different status code for check of mounted filesystem. Update VG metadata only once in vgchange when making multiple changes. Allow independent vgchange arguments to be used together. Automatically unmount invalidated snapshots in dmeventd. Suppress some superfluous messages from clang static analysis. Fix a deadlock caused by double close in clvmd. Fix NULL pointer dereference on too-large MDA error path in _vg_read_raw_area. Use static for internal _align_chunk() and _new_chunk() from pool-fast.c. Fix vgchange to process -a, --refresh, --monitor and --poll like lvchange. Add lvm2app functions to query any pv, vg, or lv property / report field. Version 1.02.57 - 8th November 2010 === Fix regex optimiser not to ignore RHS of OR nodes in _find_leftmost_common. Add dmeventd -R to restart dmeventd without losing monitoring state. (1.02.56) Fix memory leak of field_id in _output_field function. Allocate buffer for reporting functions dynamically to support long outputs. Rebuilt/reboot all seems well; also did a some *minor* manipulation via. vgchange. Signoff x86_64
[arch-general] Acceptable for AIF to copy files?
Hello I want to add extlinux support in AIF. However, unlike grub, where grub-install takes care of everything, extlinux requires /boot/syslinux to be created and some files from /usr/lib/syslinux to be copied to /boot/syslinux. Initially I though that creating a extlinux pkg that would include the needed file in /boot would be a good idea. Needless to say, there is mixed opinion on this. See link for more info: https://bugs.archlinux.org/task/21766 So... Is it acceptable for AIF to create /boot/syslinux and copy files from /usr/lib/syslinux to /boot/syslinux? Do we only want to let pacman and upstream install tools create directories and copy files during the install process? ~pyther
Re: [arch-general] Acceptable for AIF to copy files?
On Sun, 21 Nov 2010 15:06:10 -0500 Matthew Gyurgyik pyt...@pyther.net wrote: Hello I want to add extlinux support in AIF. However, unlike grub, where grub-install takes care of everything, extlinux requires /boot/syslinux to be created and some files from /usr/lib/syslinux to be copied to /boot/syslinux. Initially I though that creating a extlinux pkg that would include the needed file in /boot would be a good idea. Needless to say, there is mixed opinion on this. See link for more info: https://bugs.archlinux.org/task/21766 So... Is it acceptable for AIF to create /boot/syslinux and copy files from /usr/lib/syslinux to /boot/syslinux? Do we only want to let pacman and upstream install tools create directories and copy files during the install process? ~pyther Remember that AIF is basically a bunch of scripts that save you doing manual work during the installation. I have no strong opinion about how exactly those files should be handled, but if it's decided that the user should copy them as part of the configuration process then sure, aif can do it. Because aif does its work on behalf of the user. Feel free to get in touch on the arch-releng mailing list if you have any questions about aif itself (or find me on irc) Dieter
