[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 27 packages missing signoffs * 8 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (2 total) == * iputils-20101006-6 (i686) * iputils-20101006-6 (x86_64) == Incomplete signoffs for [core] (11 total) == * netcfg-2.8.11-1 (any) 1/2 signoffs * dbus-core-1.6.8-1 (i686) 1/2 signoffs * hdparm-9.42-1 (i686) 0/2 signoffs * iputils-20101006-6 (i686) 0/2 signoffs * libusbx-1.0.14-1 (i686) 1/2 signoffs * run-parts-4.3.4-1 (i686) 1/2 signoffs * dbus-core-1.6.8-1 (x86_64) 1/2 signoffs * hdparm-9.42-1 (x86_64) 0/2 signoffs * iputils-20101006-6 (x86_64) 0/2 signoffs * libusbx-1.0.14-1 (x86_64) 0/2 signoffs * run-parts-4.3.4-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (16 total) == * dbus-1.6.8-1 (i686) 0/2 signoffs * jack-0.121.3-7 (i686) 0/2 signoffs * kdevelop-4.3.90-1 (i686) 0/2 signoffs * kdevelop-php-1.3.90-1 (i686) 0/2 signoffs * kdevplatform-1.3.90-1 (i686) 0/2 signoffs * libffado-2.1.0-3 (i686) 0/2 signoffs * polkit-0.107-2 (i686) 0/2 signoffs * xf86-video-intel-2.20.9-1 (i686) 0/2 signoffs * dbus-1.6.8-1 (x86_64) 1/2 signoffs * jack-0.121.3-7 (x86_64) 0/2 signoffs * kdevelop-4.3.90-1 (x86_64) 0/2 signoffs * kdevelop-php-1.3.90-1 (x86_64) 0/2 signoffs * kdevplatform-1.3.90-1 (x86_64) 0/2 signoffs * libffado-2.1.0-3 (x86_64) 0/2 signoffs * polkit-0.107-2 (x86_64) 1/2 signoffs * xf86-video-intel-2.20.9-1 (x86_64) 0/2 signoffs == All packages in [testing] for more than 14 days (8 total) == * kdevelop-4.3.90-1 (i686), since 2012-09-10 * kdevelop-php-1.3.90-1 (i686), since 2012-09-10 * kdevelop-4.3.90-1 (x86_64), since 2012-09-10 * kdevelop-php-1.3.90-1 (x86_64), since 2012-09-10 * kdevplatform-1.3.90-1 (i686), since 2012-09-10 * kdevplatform-1.3.90-1 (x86_64), since 2012-09-10 * polkit-0.107-2 (i686), since 2012-09-16 * polkit-0.107-2 (x86_64), since 2012-09-16 == Top five in signoffs in last 24 hours ==
Re: [arch-dev-public] Request to drop some [extra] orphans to [community]
On Tue, Oct 02, 2012 at 09:24:19AM +1000, Gaetan Bisson wrote: Moving aspell would break the repo hierarchy (enchant, kdelibs3, etc.); that is not possible. The only orphan language packs in [extra] are: aspell-en aspell-es aspell-hu aspell-nl aspell-pt aspell-ru I'm thinking we should probably keep aspell-en alongside aspell; anyhow, I'll just go ahead and adopt it. Let me know which others (if not all) you want me to move. OK that's fine, I think it would only make sense for me to update other languages if I was maintaining aspell-en at least. If you think these other languages are in desperate need for a maintainer I'll take them, but otherwise I'll leave them for someone who actually speaks that language and uses the package. -- Jonathan Steel pgpijAz7AAPRj.pgp Description: PGP signature
[arch-dev-public] [RFC] btrfs multi-device support in pre-3.6 kernels
Hi guys, With systemd-193 and linux-3.6 we will finally have reliable support for btrfs multi-device filesystems (assembling them used to be racy). However, the added udev rules that makes this work do not work at all on pre-3.6 kernels. We could keep the old (racey) rules in the btrfs package to deal with this situation. However, that means scanning all btrfs devices twice on boot for everyone on post-3.6 kernels. As I expect the number of people using multi-device btrfs (which is still experimental) with an linux-lts kernel to be limited, I'm not too keen on optimizing for this case. I propose we either just drop the old btrfs rules and tell users of linux-lts+btrfs multi-device to upgrade to linux, or we add the rules to the linux-lts package. Any thoughts? Cheers, Tom
Re: [arch-dev-public] [RFC] btrfs multi-device support in pre-3.6 kernels
On Wed, Oct 3, 2012 at 1:30 AM, Tom Gundersen t...@jklm.no wrote: Hi guys, With systemd-193 and linux-3.6 we will finally have reliable support for btrfs multi-device filesystems (assembling them used to be racy). However, the added udev rules that makes this work do not work at all on pre-3.6 kernels. We could keep the old (racey) rules in the btrfs package to deal with this situation. However, that means scanning all btrfs devices twice on boot for everyone on post-3.6 kernels. As I expect the number of people using multi-device btrfs (which is still experimental) with an linux-lts kernel to be limited, I'm not too keen on optimizing for this case. I propose we either just drop the old btrfs rules and tell users of linux-lts+btrfs multi-device to upgrade to linux, or we add the rules to the linux-lts package. Any thoughts? Cheers, Tom That's fine, in my opinion. People running Btrfs shouldn't be using an LTS kernel anyway.
Re: [arch-dev-public] [RFC] btrfs multi-device support in pre-3.6 kernels
On Wed, Oct 3, 2012 at 1:37 AM, Jan Steffens jan.steff...@gmail.com wrote: On Wed, Oct 3, 2012 at 1:30 AM, Tom Gundersen t...@jklm.no wrote: Any thoughts? That's fine, in my opinion. People running Btrfs shouldn't be using an LTS kernel anyway. Same opinion but can you think about updating btrfs-prog? Kernel 3.6 add support for subvolumes quota and needs updated version of userspace tools. Cheers -- Sébastien Seblu Luttringer https://www.seblu.net GPG: 0x2072D77A
Re: [arch-dev-public] [RFC] btrfs multi-device support in pre-3.6 kernels
Am 03.10.2012 01:30, schrieb Tom Gundersen: Hi guys, With systemd-193 and linux-3.6 we will finally have reliable support for btrfs multi-device filesystems (assembling them used to be racy). However, the added udev rules that makes this work do not work at all on pre-3.6 kernels. We could keep the old (racey) rules in the btrfs package to deal with this situation. However, that means scanning all btrfs devices twice on boot for everyone on post-3.6 kernels. As I expect the number of people using multi-device btrfs (which is still experimental) with an linux-lts kernel to be limited, I'm not too keen on optimizing for this case. I propose we either just drop the old btrfs rules and tell users of linux-lts+btrfs multi-device to upgrade to linux, or we add the rules to the linux-lts package. Any thoughts? Cheers, Tom Just drop the support for it, LTS is too outdated for btrfs anyway. -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
[arch-dev-public] [signoff] linux-3.5.5-1
Hi guys, please signoff 3.5.5 series for both arches. package is not in testing, please grab it from here: http://dev.archlinux.org/~tpowa/linux/ This will move to [core] directly, because 3.6.0 is in [testing]. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
