You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <ch...@force-elite.com> on 2008/05/30 00:34:21 UTC
Re: PR42829
Stefan Fritsch wrote:
> On Thursday 29 May 2008, Jim Jagielski wrote:
>>> for 2.2.9, it would be nice to fix the epoll issue PR 42829,
>>> IMHO. The patch in the bug report works, even if it may not be
>>> the perfect solution.
>> From what I can see, there is no real patch available or fully
>> tested enough to warrant anything for 2.2.9 right now.
>
>
> https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has been in
> Debian testing and unstable for about 6 months without problems. It
> is not an elegant solution but it works. Considering that is is not
> clear how an elegant solution would look like, including this patch
> might make sense.
Please don't put these kind of patches into the debian apache packages,
especially ones that don't exist in trunk.
(Things that are committed to turnk, and just are awaiting backport, I'm
less concerned about, but this patch is a behavior change at the core of
the MPMs.)
-Paul
Re: PR42829
Posted by Joe Orton <jo...@redhat.com>.
On Thu, May 29, 2008 at 03:34:21PM -0700, Paul Querna wrote:
> Stefan Fritsch wrote:
>> https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has been in
>> Debian testing and unstable for about 6 months without problems. It is not
>> an elegant solution but it works. Considering that is is not clear how an
>> elegant solution would look like, including this patch might make sense.
>
> Please don't put these kind of patches into the debian apache packages,
> especially ones that don't exist in trunk.
Why not, is this some kind of distros-can't-be-trusted-to-run-patch
reaction after the Debian OpenSSL PRNG incident? Blah.
1) we-the-committers failed to do anything useful about this bug
2) Stefan has a patch
3) having more test data from people running that patch is useful
If you don't want people *patching* the *Apache source code* (god
forbid!), then we need to go pick another license.
joe
Re: PR42829
Posted by Paul Querna <ch...@force-elite.com>.
Stefan Fritsch wrote:
> My mail in January already mentioned that the patch is in Debian, but
> I guess now after the openssl debacle people are more sensitive. If
> you think it would help, I could go through our patches and post a
> list of the non-Debian specific ones here.
I think that would be helpful and a good thing,
Thanks,
-Paul
Re: PR42829
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Friday 30 May 2008, Nick Kew wrote:
> I don't think I share your implied view about how grave this is.
I guess this is the main (or only?) problem with this patch/bug. I got
quite a few people complaining about it and therefore I wanted to fix
it.
> I respect your opinion, but when maintaining your own patches,
> please consider also the problems discussed in my article at
> http://www.regdeveloper.co.uk/2006/11/04/apache_packages_support_va
>cuum/ (which goes to the heart of why Debian may get a pretty
> hostile reception amongst some Apache folks).
Yes, this is definitely a problem, but not easy to fix. I hope I will
find some time soon to try to improve the situation. In any case the
problem is less about patches but more about the configuration and
the additional scripts we ship with apache. For example the
configuration is split into many small files because this makes
upgrades easier because of the way dpkg handles config files.
> > To take it to the extreme, a fork being called 'Apache' isn't
> > acceptable either. Please work with us here, even though it's a
> > very low barrier for you to put patches in your package, much
> > lower than to get it applied upstream (here).
Fixing bugs is not forking. We don't include many patches that are not
either bug fixes or related to build or file system layout issues.
For example we don't add features or change the behaviour (unless the
component comes in a separate package that is clearly marked as
non-standard, like the mpm-itk). And for the bug fixes, these are
usually from branches/2.2.x or from the Apache bugzilla.
> To be fair, I think Stefan _is_ working with us: he's put his patch
> in bugzilla, and (now, though not originally) he's raised it on
> the list.
I raised the issue in January
(http://marc.info/?l=apache-httpd-dev&m=119945416529706&w=2) and
there was some discussion with Joe Orton, but no conclusion about
what would be the proper fix. But since I had a fix that worked for
me, I didn't see any reason to revert the patch.
My mail in January already mentioned that the patch is in Debian, but
I guess now after the openssl debacle people are more sensitive. If
you think it would help, I could go through our patches and post a
list of the non-Debian specific ones here.
Cheers,
Stefan
Re: PR42829
Posted by Jess Holle <je...@ptc.com>.
Eric Covener wrote:
> On Fri, May 30, 2008 at 9:07 AM, Jess Holle <je...@ptc.com> wrote
>> util_ldap*.c: still changing '#if APR_HAS_SHARED_MEMORY' to '#if 0' as last
>> we checked the shared memory stuff was still unstable with the worker MPM --
>> at least on Solaris and AIX
>>
> This may be addressed by two changes that made it into 2.2.8, you may
> want to revisit (latter was diagnosed on aix w/ worker)
>
> *) mod_ldap: Give callers a reference to data copied into the request
> pool instead of references directly into the cache
> PR 43786 [Eric Covener]
>
> *) mod_ldap: Stop passing a reference to pconf around for
> (limited) use during request processing, avoiding possible
> memory corruption and crashes. [Eric Covener]
>
Thanks for the heads up. I'm not sure if we retested in 2.2.8.
--
Jess Holle
Re: PR42829
Posted by Eric Covener <co...@gmail.com>.
On Fri, May 30, 2008 at 9:07 AM, Jess Holle <je...@ptc.com> wrote:
> util_ldap*.c: still changing '#if APR_HAS_SHARED_MEMORY' to '#if 0' as last
> we checked the shared memory stuff was still unstable with the worker MPM --
> at least on Solaris and AIX
This may be addressed by two changes that made it into 2.2.8, you may
want to revisit (latter was diagnosed on aix w/ worker)
*) mod_ldap: Give callers a reference to data copied into the request
pool instead of references directly into the cache
PR 43786 [Eric Covener]
*) mod_ldap: Stop passing a reference to pconf around for
(limited) use during request processing, avoiding possible
memory corruption and crashes. [Eric Covener]
--
Eric Covener
covener@gmail.com
Re: PR42829
Posted by Jess Holle <je...@ptc.com>.
Nick Kew wrote:
> As for maintaining local patches, he's not the only one doing that,
> and our license clearly allows it. Licenses that restrict such
> things seem to be widely disliked: c.f. DJB/qmail.
>
We've made a concerted effort to supply all patches back, yet we always
find that we maintain a few local patches. We don't want to, but there
are various bits that we just never successfully pushed back for one
reason or another, e.g.:
* mod_authn_alias.dep/.dsp/.mak: changes for building on Windows
o Not sure why [as I'm no longer doing these builds myself]
could be to allow us to build with an older MS studio
* mod_deflate.c: added support for a response header which will
allow responses (e.g. from Tomcat) to dynamically opt out of
compression
o code was suggested on the Apache lists, but uninteresting to
Apache trunk apparently
* util_ldap*.c: still changing '#if APR_HAS_SHARED_MEMORY' to '#if
0' as last we checked the shared memory stuff was still unstable
with the worker MPM -- at least on Solaris and AIX
--
Jess Holle
Re: PR42829
Posted by Nick Kew <ni...@webthing.com>.
On Fri, 30 May 2008 08:29:32 +0200
"Sander Striker" <st...@apache.org> wrote:
> > Bugs as grave as this one are not acceptable in Debian packages for
> > extended periods of time. The bug report has been open for over 1
> > year, I have attached my patch on 2007-11-16. It is marked as
> > critical since 2008-01-16. If you don't want such patches in the
> > Debian package, you need to fix such bugs faster (and comment on
> > patches in bugzilla faster). Of course I understand that this is
> > difficult because there are never enough people to fix bugs (we have
> > the same problem).
I don't think I share your implied view about how grave this is.
I respect your opinion, but when maintaining your own patches,
please consider also the problems discussed in my article at
http://www.regdeveloper.co.uk/2006/11/04/apache_packages_support_vacuum/
(which goes to the heart of why Debian may get a pretty hostile
reception amongst some Apache folks).
> To take it to the extreme, a fork being called 'Apache' isn't
> acceptable either. Please work with us here, even though it's a very
> low barrier for you to put patches in your package, much lower than to
> get it applied upstream (here).
To be fair, I think Stefan _is_ working with us: he's put his patch
in bugzilla, and (now, though not originally) he's raised it on
the list.
As for maintaining local patches, he's not the only one doing that,
and our license clearly allows it. Licenses that restrict such
things seem to be widely disliked: c.f. DJB/qmail.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: PR42829
Posted by Sander Striker <st...@apache.org>.
On Fri, May 30, 2008 at 8:03 AM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Friday 30 May 2008, Paul Querna wrote:
>> > https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has
>> > been in Debian testing and unstable for about 6 months without
>> > problems. It is not an elegant solution but it works. Considering
>> > that is is not clear how an elegant solution would look like,
>> > including this patch might make sense.
>>
>> Please don't put these kind of patches into the debian apache
>> packages, especially ones that don't exist in trunk.
>>
>> (Things that are committed to turnk, and just are awaiting
>> backport, I'm less concerned about, but this patch is a behavior
>> change at the core of the MPMs.)
>
> Bugs as grave as this one are not acceptable in Debian packages for
> extended periods of time. The bug report has been open for over 1
> year, I have attached my patch on 2007-11-16. It is marked as
> critical since 2008-01-16. If you don't want such patches in the
> Debian package, you need to fix such bugs faster (and comment on
> patches in bugzilla faster). Of course I understand that this is
> difficult because there are never enough people to fix bugs (we have
> the same problem).
To take it to the extreme, a fork being called 'Apache' isn't
acceptable either. Please work with us here, even though it's a very
low barrier for you to put patches in your package, much lower than to
get it applied upstream (here).
> I admit that I should have followed up on the discussion in February,
> but I was quite busy and then forgot about it.
Cheers,
Sander
Re: PR42829
Posted by Paul Querna <ch...@force-elite.com>.
Stefan Fritsch wrote:
> Bugs as grave as this one are not acceptable in Debian packages for
> extended periods of time.
Then change your default webserver to lighttpd.
I'm sure its bug free.
HTH.
-Paul
Re: PR42829
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Friday 30 May 2008, Paul Querna wrote:
> > https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has
> > been in Debian testing and unstable for about 6 months without
> > problems. It is not an elegant solution but it works. Considering
> > that is is not clear how an elegant solution would look like,
> > including this patch might make sense.
>
> Please don't put these kind of patches into the debian apache
> packages, especially ones that don't exist in trunk.
>
> (Things that are committed to turnk, and just are awaiting
> backport, I'm less concerned about, but this patch is a behavior
> change at the core of the MPMs.)
Bugs as grave as this one are not acceptable in Debian packages for
extended periods of time. The bug report has been open for over 1
year, I have attached my patch on 2007-11-16. It is marked as
critical since 2008-01-16. If you don't want such patches in the
Debian package, you need to fix such bugs faster (and comment on
patches in bugzilla faster). Of course I understand that this is
difficult because there are never enough people to fix bugs (we have
the same problem).
I admit that I should have followed up on the discussion in February,
but I was quite busy and then forgot about it.
Cheers,
Stefan