Mailing List Archive

patches uploaded on hyperreal
I have completed uploading a new set of patches for 0.8.12
which includes newly-made patches for things that did not
make it through the last round.

I have made them all in the same format, including the two that RobH
already uploaded, -- they start with header lines identifying the
patch, what it affects, and what it requires, followed by a patch
created by `diff -c file.c.orig file.c`. I have stuck with RobH's
naming scheme for now. I have tested all the patches to be sure that
they apply cleanly.

NOTE: 09_no_bsd_conf.0.8.12.patch must be applied *after*
02_NeXT_fixes.0.8.12.patch (these two conflicted in the 0.8.11
versions, and 09 had to be re-created by hand).

Two of the files are not yet patches -- only action items.

Since Monday is a holiday in the States, I'm not sure what the timing
should be on the next release. My guess is that anybody working on
the code this weekend should apply all the patches and test them out,
and that we should plan on a public release Tuesday night. That also
means a vote deadline of Tuesday 4pm EDT, which I am hoping is enough
time for people in the UK.

Here are the headers for what is in

http://www.hyperreal.com/httpd/patches/for_Apache_0.8.12/


==> 01_lock_fname.0.8.12.patch <==
From: Konstantin Olchanski <olchansk@a2.phy.bnl.gov>
Subject: A 22 character string is being written into a 19 character array
Changelog:
A string of length 22 was being strcpy'ed into "lock_fname"
defined to hold only 19 bytes "lock_fname" is enlarged.
Affects: http_main.c

==> 02_NeXT_fixes.0.8.12.patch <==
From: Brian Pinkerton <bp@webcrawler.com>, RobH
Subject: cleanup compiles on NeXT as well as fix a bug
Changelog:
NeXT compile warning cleanups, and bug fix to stop NeXT from
hitting a tight loop around accept() when apache parent is killed.
Affects: conf.h, http_main.c

==> 03_utsname_svr4.0.8.12.patch <==
From: Tobias Weingartner <weingart@austin.BrandonU.CA>
Subject: Use utsname on SVR4 (SYSV) boxes
Changelog:
Get rid of using gethostname() on SVR4 (SYSV) boxes,
and use utsname() instead.
Affects: conf.h, util.c

==> 04_util_cleanup.0.8.12.patch <==
From: "Aram W. Mirzadeh" <awm@qosina.com>
Subject: util cleanup
Changelog:
In util.c there are two (void *) missing... they're just to avoid compiler
warnings, nothing dramatic.
Affects: util.c

==> 05_nego_cleanup.0.8.12.patch <==
From: Tobias Weingartner <weingart@austin.BrandonU.CA>
Subject: Cosmetic change, so that gcc -Wall does not complain anymore.
Affects: mod_negotiation.c

==> 06_ignore_index.0.8.12.patch <==
From: Jarkko Torppa <torppa@walrus.megabaud.fi>
Subject: Directory indices fail to work, either IgnoreIndex as distributed
is totally wrong or the code is wrong.
Affects: mod_dir.c

==> 07_interrupt_accept.0.8.12.patch <==
From: "Aram W. Mirzadeh" <awm@qosina.com>,
"Michael Davon" <Davon@Web-Depot.Com>
Subject: Linux patch to interrupt sleeping accepts
Affects: http_main.c

==> 08_LynxOS_new_gmtoff <==
From: swatt@Lynx.COM (Steven Watt -- KD6GGD)
Subject: LynxOS configuration additions
NOTE: This is not yet a patch

==> 09_no_bsd_conf.0.8.12.patch <==
From: Randy Terbush, Paul Richards
Subject: Fix problems with compiling under BSD 1.0
Requires: 02_NeXT_fixes.0.8.12.patch
Affects: conf.h, util.c, mod_include.c

==> 10_dynamic_load.0.8.12.patch <==
From: Roylston Shufflebotham
Subject: Fix dynamic loading
Affects: http_config.c, httpd.h, mod_dld.c

==> 11_imap_point.0.8.12.patch <==
From: James Cloos
Subject: adds the "point" directive to the imagemap module,
giving it the same capabilities as the imagemap script.
Affects: mod_imap.c

==> 12_virt_server_name.0.8.12.patch <==
From: rst@ai.mit.edu (Robert S. Thau)
Subject: Causes the names of virtual servers to default to something
like their proper values if not specified.
Affects: http_main.c

==> 13_new_icons <==
From: kevinh@eit.com (Kevin Hughes)
Subject: New color icons are done!
NOTE: This is not yet a patch
Comments:
I just reworked my set of color icons, incorporating
the better colors and a few icons that Andy Polyakov contributed.

=========================================

Because we did not make 0.8.12 public, we now have no way to tell
users what problems are known and fixable, and thus we won't get
any useful user feedback until this round is done. Would those who
vetoed the public release please rescind their vetoes so that I can
link in the appropriate patches?

......Roy
Re: patches uploaded on hyperreal [ In reply to ]
> Because we did not make 0.8.12 public, we now have no way to tell
> users what problems are known and fixable, and thus we won't get
> any useful user feedback until this round is done. Would those who
> vetoed the public release please rescind their vetoes so that I can
> link in the appropriate patches?
>
> ......Roy


Ok, on the understanding that we cleanup
http://www.hyperreal.com/httpd/voting.html

then stick to it.


rob
Re: patches uploaded on hyperreal [ In reply to ]
> Because we did not make 0.8.12 public ......

> ......Roy


FYI, 0.8.12 has been working fine on xxx.lanl.gov and www.cm.cf.ac.uk
for a day or two.
Re: patches uploaded on hyperreal [ In reply to ]
>Ok, on the understanding that we cleanup
> http://www.hyperreal.com/httpd/voting.html
>then stick to it.

Righto. I am about 3/4 through the cleanup process, but you can
see what I've written at

http://www.hyperreal.com/httpd/voting2.html

What do you think?

.....Roy
Re: patches uploaded on hyperreal [ In reply to ]
> >Ok, on the understanding that we cleanup
> > http://www.hyperreal.com/httpd/voting.html
> >then stick to it.
>
> Righto. I am about 3/4 through the cleanup process, but you can
> see what I've written at
>
> http://www.hyperreal.com/httpd/voting2.html
>
> What do you think?

so far so good.
Re: patches uploaded on hyperreal [ In reply to ]
>Roy wrote:
>>Since Monday is a holiday in the States, I'm not sure what the timing
>>should be on the next release. My guess is that anybody working on
>>the code this weekend should apply all the patches and test them out,
>>and that we should plan on a public release Tuesday night. That also
>>means a vote deadline of Tuesday 4pm EDT, which I am hoping is enough
>>time for people in the UK.
>
>So when is the deadline for submitting patches?
>(Your wording sounds as though that has already passed.)

No deadline on patches -- I am trying to follow the format RobH has
provided. Since votes are attached to each patch, late patches are
less likely to obtain the 3 +1 votes, but that is the only restriction.

>A vote deadline of 4pm EDT Tuesday implies a release on Wednesday.

Right, I should have said "building a public release Tuesday night",
since we will want to test it overnight before the public announcement
on Wednesday (assuming it works).

.......Roy
Re: patches uploaded on hyperreal [ In reply to ]
Roy wrote:
>Since Monday is a holiday in the States, I'm not sure what the timing
>should be on the next release. My guess is that anybody working on
>the code this weekend should apply all the patches and test them out,
>and that we should plan on a public release Tuesday night. That also
>means a vote deadline of Tuesday 4pm EDT, which I am hoping is enough
>time for people in the UK.

So when is the deadline for submitting patches?
(Your wording sounds as though that has already passed.)

A vote deadline of 4pm EDT Tuesday implies a release on Wednesday.

David.