[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 6 new packages in last 24 hours * 2 known bad packages * 0 packages not accepting signoffs * 7 fully signed off packages * 26 packages missing signoffs * 2 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) == * bash-4.3-1 (i686) * lvm2-2.02.105-2 (i686) * readline-6.3-1 (i686) * bash-4.3-1 (x86_64) * lvm2-2.02.105-2 (x86_64) * readline-6.3-1 (x86_64) == Incomplete signoffs for [core] (11 total) == * efibootmgr-0.6.1.29.gf4e29e4-1 (i686) 0/1 signoffs * efivar-0.7-2 (i686) 0/1 signoffs * grub-1:2.02.beta2-2 (i686) 0/1 signoffs * lvm2-2.02.105-2 (i686) 0/1 signoffs * ppp-2.4.6-2 (i686) 0/1 signoffs * wpa_supplicant-2.1-3 (i686) 0/1 signoffs * efibootmgr-0.6.1.29.gf4e29e4-1 (x86_64) 1/2 signoffs * efivar-0.7-2 (x86_64) 1/2 signoffs * grub-1:2.02.beta2-2 (x86_64) 0/2 signoffs * lvm2-2.02.105-2 (x86_64) 0/2 signoffs * ppp-2.4.6-2 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (15 total) == * libreoffice-i18n-4.2.1-2 (any) 0/2 signoffs * banshee-2.6.2-3 (i686) 0/1 signoffs * kdebase-workspace-4.11.6-3 (i686) 0/1 signoffs * libreoffice-4.2.1-1 (i686) 0/1 signoffs * mjpegtools-2.1.0-1 (i686) 0/1 signoffs * pulseaudio-4.99.4-1 (i686) 0/1 signoffs * webkitgtk-2.2.5-2 (i686) 0/1 signoffs * wpa_supplicant_gui-2.1-1 (i686) 0/1 signoffs * banshee-2.6.2-3 (x86_64) 0/2 signoffs * kdebase-workspace-4.11.6-3 (x86_64) 0/2 signoffs * libreoffice-4.2.1-1 (x86_64) 0/2 signoffs * mjpegtools-2.1.0-1 (x86_64) 0/2 signoffs * pulseaudio-4.99.4-1 (x86_64) 0/2 signoffs * webkitgtk-2.2.5-2 (x86_64) 0/2 signoffs * wpa_supplicant_gui-2.1-1 (x86_64) 0/2 signoffs == Completed signoffs (7 total) == * bash-4.3-1 (i686) * readline-6.3-1 (i686) * systemd-210-1 (i686) * bash-4.3-1 (x86_64) * readline-6.3-1 (x86_64) * systemd-210-1 (x86_64) * wpa_supplicant-2.1-3 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * libtirpc-0.2.4-1 (i686), since 2013-12-28 * libtirpc-0.2.4-1 (x86_64), since 2013-12-28 == Top five in signoffs in last 24 hours == 1. bisson - 4 signoffs 2. dreisner - 2 signoffs 3. djgera - 2 signoffs 4. thomas - 1 signoffs
Re: [arch-dev-public] Upgrading Apache to 2.4
Am 26.02.2014 19:10, schrieb Anatol Pomozov: Hi On Wed, Feb 26, 2014 at 10:01 AM, Alexander Rødseth rods...@gmail.com wrote: One suggestion is creating the Apache 2.4 PKGBUILD first, then talk to Jan de Groot. If he should not be interested in the endeavor, talk to another dev. Good news is that I work with Jan and other devs on pushing Apache 2.4 to repos. In general they are very positive about this move. PKGBUILD is ready and once db5 todo is done I'll create Apache2.4 todo to rebuild the deps. So hopefully we'll see official apache 2.4 package in [extra] some time soon. Stay tuned. I did push a rebuild PHP into [staging]. I had to add a hack to keep the non-ZTS build that can only be used with the prefork MPM. For some reason PHP devs thought it would be a good idea to base a PHP compile time option on the stat of an Apache runtime config. Some day we might just drop mod_php; I cant think of any sane usage of this SAPI. Am I correct that Apache can now use FastCGI without third-party modules? Anyway, I suggest in the end we should post an announcement on the front page. IMHO that install message is not really needed then, but that might be debatable. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upgrading Apache to 2.4
Pierre Schmitz schreef op 27.02.2014 13:04: I did push a rebuild PHP into [staging]. I had to add a hack to keep the non-ZTS build that can only be used with the prefork MPM. For some reason PHP devs thought it would be a good idea to base a PHP compile time option on the stat of an Apache runtime config. Some day we might just drop mod_php; I cant think of any sane usage of this SAPI. Am I correct that Apache can now use FastCGI without third-party modules? Anyway, I suggest in the end we should post an announcement on the front page. IMHO that install message is not really needed then, but that might be debatable. FastCGI is possible with mod_proxy_fcgid and mod_fcgid, but this has some side-effects: - mod_fcgid can't connect to php-fpm - mod_proxy_fcgid doesn't pass DOCUMENT_ROOT to php-fpm, so you would have to setup weird rules or multiple php-fpm pools for every vhost Since mod_fastcgi still works with some patching there's not a big issue at this moment. I don't see real need for mod_php either, when I initially tested Apache 2.4 it was giving weird issues. I replaced the mod_php setups with mod_fastcgi + php-fpm a while ago. Though fastcgi adds some extra overhead, the event MPM brings much more advantages that makes it worth switching. IMHO mod_php with ZTS is not a good alternative, it adds additional overhead and you're still not sure that 3rd party libraries won't screw thread safety.
Re: [arch-dev-public] Upgrading Apache to 2.4
Hi On Sun, Feb 23, 2014 at 4:43 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Hi, One of my TU application proposals was updating apache package to 2.4. The 2.4 branch exists for 2 years, actively developed and is recommended by upstream. Taking into account that many distros moved to 2.4 already I do not expect serious problems with moving Arch to 2.4. I would like to look at this issue. In addition to version bump I wan to cleanup the PKGBUILD file e.g. itk is an apache module now and we do not need to apply a huge pile of patches to apache sources - it can be a separate package 'mod_itk'. So how can I update the apache package? I do not have access to [extra] so I see 2 ways to resolve the issue: 1) Move apache and its dependencies from [extra] to [community]. I update apache and rebuild mod_* packages. 2) I create apache24 and mod_itk modules and after some testing devs will move it to [extra], replace content of 'apache' and rebuild dependencies. What is the preferred solution? Here is my experience with updating Apache dependencies. I see that some popular third-party modules either have no development for years or do not want to update Apache2.4 at all. Following dependencies have no compilation problems with Apache2.4: mod_fcgid,mod_dnssd,mod_wsgi and recompilation was easy. There are few other mods in arch repos that took a while for me to figure out what to do: mod_fastcgi: The last release was made in 2007. The official version does not compile with Apache2.4. There are third-party patches that make it work. Both Debian and Gentoo use this version https://github.com/ByteInternet/libapache-mod-fastcgi mod_perl: 2 years back the developers said they work on Apache2.4 support but there no any official version with this work yet. Debian uses unreleased branch http://svn.apache.org/repos/asf/perl/modperl/branches/httpd24/ mod_mono: Another ancient mod that does not compile with Apache2.4. They have some development in their official repo https://github.com/mono/mod_mono but it is not released. The whole situation with popular third-party Apache modules that do not want to migrate to 2-years old release makes me a little bit depressed.
Re: [arch-dev-public] nvidia 331.49
On Wed, Feb 26, 2014 at 09:47:46AM +0100, Sven-Hendrik Haase wrote: On February 26, 2014 9:31:03 AM CET, Ionut Biru ib...@archlinux.org wrote: hello, i'm a bit busy this days. it's kinda a minor update but it would be nice to have this bug resolved as well: https://bugs.archlinux.org/task/38604 On Tue, Feb 25, 2014 at 8:30 PM, Pierre Schmitz pie...@archlinux.de wrote: Am 25.02.2014 18:26, schrieb Ike Devolder: Hi all, Is there a special reason we are not updating to the latest nvidia drivers ? problems building the kernel drivers or something ? I'm just asking, did not yet build the drivers myself, just have an updated pkgbuild for the utils already. Looks like a minor update to me. I think Ionut was busy lately. So I would say if the updated driver works fine and is not explicitly marked as BETA, just go ahead and push an update. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com Will handle this a little later today. Thanks for the update -- Ike pgp2KquhPcu5d.pgp Description: PGP signature
