Mailing List Archive

The following patch was entered as:
06_bsd_next_cleanup.0.8.13.patch

I'll put it in patches directory.


At 09:52 AM 9/12/95 -0500, you wrote:
>
>I have followed up the help request on Usenet with the following
>patch.
>
>
>*** http_config.c.orig Tue Sep 12 09:30:23 1995
>--- http_config.c Tue Sep 12 09:32:33 1995
>***************
>*** 84,91 ****
>--- 84,93 ----
> #include "http_conf_globals.h" /* Sigh... */
>
> #ifdef BSD
>+ #ifndef NEXT
> #include <sys/resource.h>
> #endif
>+ #endif
>
> /****************************************************************
> *
>***************
>*** 627,632 ****
>--- 629,635 ----
> server_rec *s = (server_rec *)pcalloc (p, sizeof (server_rec));
>
> #ifdef BSD
>+ #ifndef NEXT
> struct rlimit limits;
>
> getrlimit ( RLIMIT_NOFILE, &limits );
>***************
>*** 635,640 ****
>--- 638,644 ----
> if ( setrlimit ( RLIMIT_NOFILE, &limits ) < 0 )
> fprintf (stderr, "Cannot exceed hard limit for open files");
> }
>+ #endif
> #endif
>
> s->port = 0;
>
>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

Randy's patch has

#ifdef BSD
#ifndef NEXT
...
#endif
#endif

Wouldn't it be simpler to just do

#ifdef RLIMIT_NOFILE
...
#endif

thereby testing directly for the availability of the feature in question
(which is, IMHO, preferable to guessing where possible)?

rst

>
> The following patch was entered as:
> 06_bsd_next_cleanup.0.8.13.patch
>
> I'll put it in patches directory.
>

Thanks Aram.

Be aware that I intended that patch as a *quick fix* to get
the NeXT compile working. Until I can get access to a NeXT,
I guess this will need to stay hacked.

Anyone know if ulimit() can control maxopen files on NeXT?

> Randy's patch has
>
> #ifdef BSD
> #ifndef NEXT
> ...
> #endif
> #endif
>
> Wouldn't it be simpler to just do
>
> #ifdef RLIMIT_NOFILE
> ...
> #endif
>
> thereby testing directly for the availability of the feature in question
> (which is, IMHO, preferable to guessing where possible)?
>
> rst

Perfect... Why didn't I think of that?

:-)

If the patch is still unchanged after I catch up with this mail
directory.... I'll up a new one.

<snip>
> > >
> > >As I understand the new patch naming convention, changed patches
> > >should retain the same patch number and increment the alpha ID
> > >to indicate the latest version. If that is not the case, I am
> > >sure that someone will set me straight... :-)
> >
> > Ahhh! Okay... what are we using to give a patch for a patch then?
> > a new patch number?
> >
> > For example, 1a, 1b are both patches for 16_0.8.12. Should I have
> > made then 1, and 2?
>
> I believe that is correct. It would probably be less confusing to
> the voters to re-roll a patch that replaces previous patches for
> the same issue and using the alpha character to identifie it as a
> replacement.

Now I'm confused. Are 1a and 1b two separate patches, or two versions of
the same patch (I think the latter is what the names mean)?

And, to repeat an earlier question, if a patch requires other patches,
should it include all the patches it requires (i.e. diff -C3
against the original code), or should it patch the patches (i.e. diff -C3
against the original code+the required patches)?

While we're on the subject of patch naming/voting, what happens if two
alternates for the same patch get the same number of +1 votes?

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk (preferred)
A.L. Digital Ltd, benl@fear.demon.co.uk (backup)
London, England.

[.Note for the paranoid: "fear" as in "Fear and Loathing
in Las Vegas", "demon" as in Demon Internet Services, a
commercial Internet access provider.]

At 04:48 PM 9/13/95 +0100, you wrote:
>
>Now I'm confused. Are 1a and 1b two separate patches, or two versions of
>the same patch (I think the latter is what the names mean)?

Sorry, what I did was create 1a, and 1b which are BOTH needed to fix
a compiling error on Linux that appeared with patch 16_0.8.12. BOTH
patches are needed, they're two seperate files. I should have just named
it '1' and put both diffs in the same file.

>
>And, to repeat an earlier question, if a patch requires other patches,
>should it include all the patches it requires (i.e. diff -C3
>against the original code), or should it patch the patches (i.e. diff -C3
>against the original code+the required patches)?

From the last round-about I belive if a patch if for a patch it goes against
the next release not this one. So if you want to create a patch for my
patch it would go against the 0.8.14 source code.

>
>While we're on the subject of patch naming/voting, what happens if two
>alternates for the same patch get the same number of +1 votes?
>

Ahh... I think I know what you mean, but I don't have an answer.

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

> > And, to repeat an earlier question, if a patch requires other patches,
> > should it include all the patches it requires (i.e. diff -C3
> > against the original code), or should it patch the patches (i.e. diff -C3
> > against the original code+the required patches)?
>
> Ieee.. I think it would be difficult to require each person to
> stay in sync with another's work. I think that it is really up
> to the release engineer to make an attempt to work out the
> conflicts. If you are aware of a dependency before submittal,
> that would be nice to know.

What I do with my patches if they conflict with an earlier patch,
is to upload 2 versions. That way it doesn't matter if the earlier patch
gets accepted or not.


rob

>
> At 04:48 PM 9/13/95 +0100, you wrote:
> >
> >Now I'm confused. Are 1a and 1b two separate patches, or two versions of
> >the same patch (I think the latter is what the names mean)?
>
> Sorry, what I did was create 1a, and 1b which are BOTH needed to fix
> a compiling error on Linux that appeared with patch 16_0.8.12. BOTH
> patches are needed, they're two seperate files. I should have just named
> it '1' and put both diffs in the same file.
>
> >
> >And, to repeat an earlier question, if a patch requires other patches,
> >should it include all the patches it requires (i.e. diff -C3
> >against the original code), or should it patch the patches (i.e. diff -C3
> >against the original code+the required patches)?
>
> From the last round-about I belive if a patch if for a patch it goes against
> the next release not this one. So if you want to create a patch for my
> patch it would go against the 0.8.14 source code.

If that's the case, why is there a Requires: field in the patch header?

>
> >
> >While we're on the subject of patch naming/voting, what happens if two
> >alternates for the same patch get the same number of +1 votes?
> >
>
> Ahh... I think I know what you mean, but I don't have an answer.

Let's hope it doesn't happen then ;->

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk (preferred)
A.L. Digital Ltd, benl@fear.demon.co.uk (backup)
London, England.

[.Note for the paranoid: "fear" as in "Fear and Loathing
in Las Vegas", "demon" as in Demon Internet Services, a
commercial Internet access provider.]