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

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 24 Sep '12

24 Sep '12

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 1 new package in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 6 fully signed off packages * 18 packages missing signoffs * 0 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 (1 total) == * hwids-20120922-1 (any) == Incomplete signoffs for [core] (8 total) == * hwids-20120922-1 (any) 0/2 signoffs * libarchive-3.0.4-2 (i686) 1/2 signoffs * mkinitcpio-busybox-1.20.2-1 (i686) 1/2 signoffs * nfsidmap-0.25-1 (i686) 1/2 signoffs * rp-pppoe-3.11-1 (i686) 0/2 signoffs * mkinitcpio-busybox-1.20.2-1 (x86_64) 1/2 signoffs * rp-pppoe-3.11-1 (x86_64) 0/2 signoffs * systemd-191-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (10 total) == * 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 * polkit-0.107-2 (i686) 0/2 signoffs * postgresql-9.2.0-1 (i686) 0/2 signoffs * postgresql-old-upgrade-9.1.5-1 (i686) 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 * polkit-0.107-2 (x86_64) 1/2 signoffs == Completed signoffs (6 total) == * patch-2.7-1 (i686) * libarchive-3.0.4-2 (x86_64) * nfsidmap-0.25-1 (x86_64) * patch-2.7-1 (x86_64) * postgresql-9.2.0-1 (x86_64) * postgresql-old-upgrade-9.1.5-1 (x86_64) == Top five in signoffs in last 24 hours == 1. ttopper - 3 signoffs 2. allan - 3 signoffs

1 0

[arch-dev-public] removed btrfs-progs from [testing]
by Dave Reisner 23 Sep '12

23 Sep '12

tl;dr: If you've installed btrfs-progs from testing (0.19.20120904-5), please downgrade to the version in core. If you regenerated your initramfs while this testing package was installed, please regenerate your initramfs after downgrading. Tom, My multi-device btrfs VM doesn't boot with this package. You've removed our own 70-btrfs.rules which calls btrfs device scan. Despite what Kay thinks, the builtin he wrote doesn't do the same thing, and leaves devices unassembled. Regardless, the initcpio hook wasn't modified to include the new rule and just errors out on the missing 70-btrfs.rules. I'm a little wary of making this change so soon when systemd in testing is already completely borked on i686 (which means that even if this package worked, it could still break boot for i686). For now, I've nuked the package in testing for both i686 and x86_64. d

2 1

[arch-dev-public] Moving sbt to [extra]
by Andrea Scarpino 23 Sep '12

23 Sep '12

Hi devs, I've to work with sbt for a while and I guess it deserve a place in our repos. So, I'm going to move it to [extra] (if this is an issue, I'm ok with [community] too). Any objection? -- Andrea

1 1

[arch-dev-public] Future mesa-9.0 and related packages
by Laurent Carlier 23 Sep '12

23 Sep '12

Mesa 9.0 will be soon available. I manage for some month a repo with mesa built from git, in a splitted way like our extra packages (1). Package sources are of course available (2) and are changing regularly because of a move from a static built system to an autotools driven built system. This move drives me to apply some "workaround" to avoid liking breakage because of the way our splitting packages are working; i prefer that way to do instead of patching the Makefiles. I'm currently applying similar workaround with gambas3 packages, with much success, and it avoid the maintainance of patches. My packages are providing more or less experimental features like r600-llvm- compiler (that should be disabled) or vdpau (afaik only working for mpeg1/2). A new gfx driver is also available, for Southern Island class AMD GPU (radeonsi). The related ddx driver, xf86-video-ati will provide 2D accelerated draw and the glamor library (using shaders to accelerate drawing). I've tried glamor with my card (HD6870), there is some graphics glitches and limitations (you can't play at least flash video fullscreen) but it seem pretty stable and can be easily disabled at run time (it's disabled by default). libglu (GLU) is missing from mesa and is now maintain as a separate project. So to build libglu you need libgl/gl.h as a dependencies. I've not found an easy way to integrate libglu like in mesa-8.* releases. Keeping libglu as a dependency of mesa avoid the breakage of all our packages depending on it. In a second time, it could give us the opportunity to simplify the dependencies from packages that are depending on libgl and libglu (no need to keep mesa as depends, only as makedepends). Perhaps i'm forgetting other things. Comments ? (1) http://pkgbuild.com/~lcarlier/mesa-git (2) http://pkgbuild.com/~lcarlier/mesa-git/sources

2 1

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 23 Sep '12

23 Sep '12

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 6 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 12 fully signed off packages * 27 packages missing signoffs * 4 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 (6 total) == * mlocate-0.26-1 (i686) * mlocate-0.26-1 (x86_64) * libffado-2.1.0-2 (i686) * transmission-2.61-4 (i686) * libffado-2.1.0-2 (x86_64) * transmission-2.61-4 (x86_64) == Incomplete signoffs for [core] (11 total) == * btrfs-progs-0.19.20120904-4 (i686) 0/2 signoffs * libarchive-3.0.4-2 (i686) 1/2 signoffs * mkinitcpio-busybox-1.20.2-1 (i686) 0/2 signoffs * mlocate-0.26-1 (i686) 1/2 signoffs * nfsidmap-0.25-1 (i686) 1/2 signoffs * rp-pppoe-3.11-1 (i686) 0/2 signoffs * btrfs-progs-0.19.20120904-4 (x86_64) 1/2 signoffs * mkinitcpio-busybox-1.20.2-1 (x86_64) 0/2 signoffs * mlocate-0.26-1 (x86_64) 1/2 signoffs * rp-pppoe-3.11-1 (x86_64) 0/2 signoffs * systemd-191-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (16 total) == * 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-2 (i686) 0/2 signoffs * polkit-0.107-2 (i686) 0/2 signoffs * postgresql-9.2.0-1 (i686) 0/2 signoffs * postgresql-old-upgrade-9.1.5-1 (i686) 0/2 signoffs * transmission-2.61-4 (i686) 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-2 (x86_64) 0/2 signoffs * polkit-0.107-2 (x86_64) 1/2 signoffs * postgresql-9.2.0-1 (x86_64) 1/2 signoffs * postgresql-old-upgrade-9.1.5-1 (x86_64) 1/2 signoffs * transmission-2.61-4 (x86_64) 0/2 signoffs == Completed signoffs (12 total) == * coreutils-8.19-1 (i686) * patch-2.7-1 (i686) * procps-ng-3.3.3-6 (i686) * sysvinit-2.88-8 (i686) * util-linux-2.22-6 (i686) * coreutils-8.19-1 (x86_64) * libarchive-3.0.4-2 (x86_64) * nfsidmap-0.25-1 (x86_64) * patch-2.7-1 (x86_64) * procps-ng-3.3.3-6 (x86_64) * sysvinit-2.88-8 (x86_64) * util-linux-2.22-6 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * sysvinit-2.88-8 (i686), since 2012-09-04 * sysvinit-2.88-8 (x86_64), since 2012-09-04 * coreutils-8.19-1 (i686), since 2012-09-05 * coreutils-8.19-1 (x86_64), since 2012-09-05 == Top five in signoffs in last 24 hours == 1. stephane - 4 signoffs 2. bisson - 2 signoffs 3. stativ - 1 signoffs

1 0

[arch-dev-public] Transitioning between incompatible language versions
by Allan McRae 23 Sep '12

23 Sep '12

Hi, The recent lua-5.2 thread and also python-3 have highlighted the need for us to really have a policy for how we deal with providing two different versions of a language interpreter in the repos. This is particularly important when there is a period of time where we want to supply the newer version of the language, but much software has not transitioned to it yet so we must provide an old version too. Note I while i am specifically considering programming languages here, this could apply to libraries as well where we are force to provide an old version for some time. There are two options that I see (assuming that us being Arch Linux always want the newest version in the repos...) 1) The "foo" package is the newest version of the language and the legacy version gets the version attached to it - i.e. "foo1". Libraries for the language "foo" would be called "foo-libname" and "foo1-libname" 2) Both packages have a version attached to their name. "foo2" and "foo1". Libraries for the language would be called "foo2-libname" and "foo1-libname" Choosing which version: #1 is best if we expect all software to be updated to the new version and the legacy version to be soon removed (e.g. for lua?). #2 is best if we think we will continue to support both versions for an extended period of time (e.g. python2/3). Does that sound a reasonable policy? It would be up to the maintainer to decide whether to use naming scheme #1 or #2 based on expectations of the language's future. Comments? I'd like to get this sorted quickly so we can get the python and lua rebuilds done. Allan

4 3

[arch-dev-public] [RFC] Python 3.3.0 and PEP 394
by Stéphane Gaudreault 23 Sep '12

23 Sep '12

Python 3.3.0 should be released around September 22. I would like to take this opportunity to implement some of the recommendations of the PEP 394 [1]. This PEP was mostly done in reaction to what Arch did to the /usr/bin/python symlink (in summary, most python devs are against the move to python3 as a default at this time). In short: python2 should refer to some version of Python 2.x python3 should refer to some version of Python 3.x python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions This means that we should never have a reference to '#!/usr/bin/python' in any of our packages. All those reference should be changed to /usr/bin/python2 to refer to Python 2.x and /usr/bin/python3 for Python 3.x. The idea here is that a system without any python symlink should work without problem. Maybe namcap could be used to detect wrong shebang ? Another possibility, suggested by Allan, would be to go even further and use /usr/bin/python3.3 and /usr/bin/python2.7 for all shebangs. Then /usr/bin/python can point to any version and /usr/bin/python2 and /usr/bin/python3 can point to any pyhton2.x and python3.x respectively. These numbers in the shebangs will be changed when python bump is version number as we need to rebuild almost everything anyway. Any opinions ? Cheers, Stéphane [1] http://www.python.org/dev/peps/pep-0394/

8 20

[arch-dev-public] Googley additions for [extra]
by Dave Reisner 22 Sep '12

22 Sep '12

Hey all, I'm going to be working on cleaning up some PKGBUILDs from the AUR for addition to [extra], namely: gperftools snappy leveldb I'd also eventually like to add the python bindings for leveldb, as well as some other popular python modules, but I'm going to hold off until we do the rebuilds for python 3.3 as the modules I have in mind have py3k support. Cheers, Dave

1 0

[arch-dev-public] Fwd: [arch-general] testing/systemd 191-1 failed to boot
by Allan McRae 22 Sep '12

22 Sep '12

FYI, many people are reporting this on i686. -------- Original Message -------- Subject: [arch-general] testing/systemd 191-1 failed to boot Date: Sat, 22 Sep 2012 15:09:02 +0900 From: Zhengyu Xu <xzy3186(a)gmail.com> Reply-To: General Discussion about Arch Linux <arch-general(a)archlinux.org> To: General Discussion about Arch Linux <arch-general(a)archlinux.org> Dear all, After updating systemd to 191-1 in testing repo, I had following messages during booting and the process was stuck (crashed). [ 10.539416] systemd[1]: segfault at 7d ip b75a97b7 sp bfb0ece8 error 4 in libc-2.16.so[b752a000+1a4000] [ 10.539700] systemd[1]: Caught <SEGV>, core dump failed. Downgrade to 189-4 can solve this problem. I want to know if this is a personal problem or a general bug affecting others as well. Best regards, Z.

2 2

Re: [arch-dev-public] [arch-general] testing/systemd 191-1 failed to boot
by Thomas Bächler 22 Sep '12

22 Sep '12

Am 22.09.2012 10:07, schrieb Heiko Baums: > Am Sat, 22 Sep 2012 15:09:02 +0900 > schrieb Zhengyu Xu <xzy3186(a)gmail.com>: > >> After updating systemd to 191-1 in testing repo, I had following >> messages during booting and the process was stuck (crashed). >> >> [ 10.539416] systemd[1]: segfault at 7d ip b75a97b7 sp bfb0ece8 >> error 4 in libc-2.16.so[b752a000+1a4000] >> [ 10.539700] systemd[1]: Caught <SEGV>, core dump failed. >> >> Downgrade to 189-4 can solve this problem. I want to know if this >> is a personal problem or a general bug affecting others as well. > > Why am I not surprised? > > Yes, binary init system is so much better than a script based init > system. And Poetterix is so damn good, so advanced, such an evolution > and so much better than the common and over 40 years well tested > sysvinit. > > Come on systemd fanboys, here you have the first example. There's more > to come. I'll get my popcorn. After the recent outbreaks, we have been discussing banning people from arch-general. At the time, the people we talked about had calmed down and everything went back to normal, so there was no point in going forward with it. However, your name just made top of the list. If I see you interrupting one more technical discussion with trolls and flames, you will be banned indefinitely without further notice. I will not see another one week flamewar on this list. You are a grown man (at least you look like one), so you should know that this kind of post adds nothing to the discussion, but starts yet another flamewar. Start acting like a grown man and keep it to yourself, unless you have something to say that's worth saying. I am completely against banning people, but at this point, it is either banning people or shutting down this list entirely.

1 0