Bug#666822: Apache 2.4 upload date scheduled for May 30; mod_perl needs work

[Niko Tyni]

On Fri, May 24, 2013 at 10:09:33PM +0200, gregor herrmann wrote:
> On Fri, 24 May 2013 22:28:34 +0300, Niko Tyni wrote:

> > If somebody could look at merging the upstream SVN httpd24 branch with
> > the 2.0.8 release, that would be great. We're going to need at least
> > the Perl 5.18 fixes next.
> 
> ... I just merged the 2_0_8 tag into the httpd24 branch and tarred it up.
> 
> (Some suffix after 2.0.8+httpd24 might make sense nevertheless.)
> 
> svn merge didn't complain, so that sould be ok, I guess.
> (This should also make the 270_*hash* patch obsolete; at least it
> doesn't apply anymore.)

Nice it was that easy. For some reason I thought 'svn merge' wouldn't
work at all without write access to the upstream repo. Luckily SVN isn't
_that_ centralized :)

On Fri, May 24, 2013 at 11:33:22PM +0300, Damyan Ivanov wrote:

> I started in the other direction -- from the current 2.0.8 package, 
> picking commits from upstream's httpd24 branch, until the build 
> succeeded. The result is a series of patches, with which the 
> compilation seems to succeed. I couldn't make the tests really start 
> to run.

Thank you both!

I'm not quite sure which approach is better. Just doing an 'svn merge'
and a fake upstream tarball is less work for us, but Damyan's way makes
it clearer what code we're distributing.

Maybe go ahead with separate patches for now? At least as long as that
scales.  We could still switch to a fake upstream merged tarball later
if it feels necessary.

Hm, mental note: we should definitely credit Jan Kaluza in our changelog
as the one who ported the upstream code to Apache 2.4.

> Perhaps a less naive approach would be to really merge the http24 
> upstream branch, for example by importing every revision as a quilt 
> patch (28 in total, if my git-svn copy is right).

It's even more work but yes, I think I'd prefer having all the httpd24
commits in rather than just the 'obligatory ones'.

I just pushed a ntyni/httpd24 branch to the git repo. I think it should
be rebased onto whichever solution we choose for the upstream merge.
If somebody can look at that, please do. I expect not to have much time
for this today.

I haven't really tested the resulting packages other than installing
them. The dependencies look good to me.

> There is an incompatibility with the wheezy version that we need to 
> address somehow. "remote_ip" and "remote_port" request methods are 
> renamed to "client_ip" and "client_port". Perhaps small wrappers 
> providing the old methods for jessie? Another approach would be to 
> just document the change in NEWS.Debian.

Seems like a minor detail right now :) Perhaps just file a bug
and discuss the best solution upstream ? Or is this clearly breaking
something?
-- 
Niko