On Wed, Feb 26, 2014 at 1:10 PM, Anatol Pomozov <anatol.pomozov@gmail.com>wrote:

Hi

On Wed, Feb 26, 2014 at 10:01 AM, Alexander Rødseth <rodseth@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.

What db5 todo? If you're talking about: https://www.archlinux.org/todo/db-6020/ then you don't need to wait for it as it doesn't use the staging repos. The db-less packages were pushed in the repos as they were done.

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.

Am 06.03.2014 22:48, schrieb Anatol Pomozov:

Hi

On Wed, Feb 26, 2014 at 10:10 AM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:

...

Hi

On Wed, Feb 26, 2014 at 10:01 AM, Alexander Rødseth <rodseth@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.

Apache 2.4 has been moved from [testing] to [extra] and now available for everyone. Please update your setup, follow the migration instructions https://httpd.apache.org/docs/trunk/upgrading.html and report any problems.

Thanks everyone.

I think we should write a short announcement about the Apache update and maybe also mention the possible issues people run into when trying to use mod_php with a threaded mpm. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

Hi On Thu, Feb 27, 2014 at 3:21 PM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:

Hi

On Sun, Feb 23, 2014 at 4:43 PM, Anatol Pomozov <anatol.pomozov@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.

Actually mod_dnssd released in 2009 also does not work with Apache2.4. There is an unreleased change in the repo that we should pull into our package. It means that only minority of third-party modules work with apache2.4 out-of-box :(

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.

Apache2.4 and its modules are in [testing] now. Woo-hoo! Please install and check it. Hopefully everything will be ok, but if it is not - report your findings.