Re: Help needed to test Windows builds in Travis

2020-04-28 Thread Luca Toscano
Hi Mario,

I didn't had the time to do much, so please feel free to take ownership of
the work to do. I am looking forward to see this done properly :)

If I can help please let me know!

Luca

Il mar 28 apr 2020, 21:24 Mario Brandt  ha scritto:

> Hi Luca,
> did you start somewhere yet?
>
> Mario
>
> On Sat, 30 Nov 2019 at 14:56, Luca Toscano  wrote:
> >
> > Hi Mario,
> >
> > will take this as starting point, but since I have zero experience in
> > building anything on Windows it might take a bit to translate
> > everything into a meaningful Travis config. Hope to have something to
> > share during the next days :)
> >
> > Luca
> >
> > Il giorno ven 29 nov 2019 alle ore 05:37 Mario Brandt
> >  ha scritto:
> > >
> > > Hi Luca,
> > >
> > > the cmake post on AL has a batch script, so I think that will do the
> > > job pretty well. https://www.apachelounge.com/viewtopic.php?t=6462
> > >
> > > For a command line build without cmake maybe Gregg or Steffen can help
> > > out more than I can.
> > >
> > > Mario
> > >
> > > On Thu, 28 Nov 2019 at 07:51, Luca Toscano 
> wrote:
> > > >
> > > > Hi Mario,
> > > >
> > > > first of all apologies for the late reply to you, Michal and William,
> > > > I wanted to work on it during the past days but got busy at work. I
> > > > have read some docs but didn't try anything, if you have any
> > > > prototype/suggestion/etc.. I'll be happy to follow up!
> > > >
> > > > Luca
> > > >
> > > > Il giorno mer 27 nov 2019 alle ore 23:48 Mario Brandt
> > > >  ha scritto:
> > > > >
> > > > > Hi Luca,
> > > > > is there any progress on this?
> > > > >
> > > > > Cheers
> > > > > Mario
> > > > >
> > > > > Luca Toscano  schrieb am Do., 7. Nov.
> 2019, 22:56:
> > > > >>
> > > > >> Hi everybody,
> > > > >>
> > > > >> if you build httpd for Windows can you give us a list of commands
> and
> > > > >> steps that you usually do? I am not familiar enough with the
> platform
> > > > >> and [1] is still a bit cryptic to me :)
> > > > >> The end goal is to add the build steps to our Travis config, to
> run
> > > > >> them every time that a commit happens.
> > > > >>
> > > > >> Thanks in advance!
> > > > >>
> > > > >> Luca
> > > > >>
> > > > >> [1] https://httpd.apache.org/docs/2.4/platform/win_compiling.html
>


Re: Help needed to test Windows builds in Travis

2020-04-28 Thread Mario Brandt
Hi Luca,
did you start somewhere yet?

Mario

On Sat, 30 Nov 2019 at 14:56, Luca Toscano  wrote:
>
> Hi Mario,
>
> will take this as starting point, but since I have zero experience in
> building anything on Windows it might take a bit to translate
> everything into a meaningful Travis config. Hope to have something to
> share during the next days :)
>
> Luca
>
> Il giorno ven 29 nov 2019 alle ore 05:37 Mario Brandt
>  ha scritto:
> >
> > Hi Luca,
> >
> > the cmake post on AL has a batch script, so I think that will do the
> > job pretty well. https://www.apachelounge.com/viewtopic.php?t=6462
> >
> > For a command line build without cmake maybe Gregg or Steffen can help
> > out more than I can.
> >
> > Mario
> >
> > On Thu, 28 Nov 2019 at 07:51, Luca Toscano  wrote:
> > >
> > > Hi Mario,
> > >
> > > first of all apologies for the late reply to you, Michal and William,
> > > I wanted to work on it during the past days but got busy at work. I
> > > have read some docs but didn't try anything, if you have any
> > > prototype/suggestion/etc.. I'll be happy to follow up!
> > >
> > > Luca
> > >
> > > Il giorno mer 27 nov 2019 alle ore 23:48 Mario Brandt
> > >  ha scritto:
> > > >
> > > > Hi Luca,
> > > > is there any progress on this?
> > > >
> > > > Cheers
> > > > Mario
> > > >
> > > > Luca Toscano  schrieb am Do., 7. Nov. 2019, 
> > > > 22:56:
> > > >>
> > > >> Hi everybody,
> > > >>
> > > >> if you build httpd for Windows can you give us a list of commands and
> > > >> steps that you usually do? I am not familiar enough with the platform
> > > >> and [1] is still a bit cryptic to me :)
> > > >> The end goal is to add the build steps to our Travis config, to run
> > > >> them every time that a commit happens.
> > > >>
> > > >> Thanks in advance!
> > > >>
> > > >> Luca
> > > >>
> > > >> [1] https://httpd.apache.org/docs/2.4/platform/win_compiling.html


Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

2020-04-28 Thread Ruediger Pluem



On 4/28/20 3:53 PM, Yann Ylavic wrote:
> On Tue, Apr 28, 2020 at 2:26 PM Nick Kew  wrote:
>>
>>> On 28 Apr 2020, at 12:49, Yann Ylavic  wrote:
>>>
>>> That'd help being more reactive there, avoid having multiple places to
>>> follow, avoid tenchnical discussions taking place outside our mailing
>>> lists...
>>>
>>> Probably more a question for infra, but what does the team think?
>>
>> Please, no!
>>
>> We have commits arriving at cvs@httpd (dammit, how long ago was
>> it we moved from cvs to svn?), bugs, and some less-used lists.
>> If you like to see them all in one place, get your procmail (or whatever)
>> to sort it locally into the same folder!
> 
> I think I did not explain myself well, I don't necessarily want github
> activity to arrive the dev@ mailing list, I want it to arrive
> _somewhere_ on one of our mailing lists. An existing one (dev@, bugs@
> ?) or a new gh@httpd.a.o is fine by me.
> 
> I just don't want to login to github to see what happens, though I can
> do that (or follow a link) once I'm aware of a PR or discussion
> happening there. My workflow being to read my emails and mailing lists
> I'm subscribed to..
> 
>>
>> A mailbox full of messages "from" Gitbox and without meaningful
>> subject lines just provokes [select all] --> delete.
> 
> I certainly agree with that, those not interested would not subscribe
> to gh@httpd.a.o for instance.

+1 g...@httpd.apache.org (I declare the naming discussion for the list name 
opened :-)).
This offers an easy opt-in for those who are interested in these updates.

Regards

RĂ¼diger



Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

2020-04-28 Thread Yann Ylavic
On Tue, Apr 28, 2020 at 2:26 PM Nick Kew  wrote:
>
> > On 28 Apr 2020, at 12:49, Yann Ylavic  wrote:
> >
> > That'd help being more reactive there, avoid having multiple places to
> > follow, avoid tenchnical discussions taking place outside our mailing
> > lists...
> >
> > Probably more a question for infra, but what does the team think?
>
> Please, no!
>
> We have commits arriving at cvs@httpd (dammit, how long ago was
> it we moved from cvs to svn?), bugs, and some less-used lists.
> If you like to see them all in one place, get your procmail (or whatever)
> to sort it locally into the same folder!

I think I did not explain myself well, I don't necessarily want github
activity to arrive the dev@ mailing list, I want it to arrive
_somewhere_ on one of our mailing lists. An existing one (dev@, bugs@
?) or a new gh@httpd.a.o is fine by me.

I just don't want to login to github to see what happens, though I can
do that (or follow a link) once I'm aware of a PR or discussion
happening there. My workflow being to read my emails and mailing lists
I'm subscribed to..

>
> A mailbox full of messages "from" Gitbox and without meaningful
> subject lines just provokes [select all] --> delete.

I certainly agree with that, those not interested would not subscribe
to gh@httpd.a.o for instance.


Regards,
Yann.


Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

2020-04-28 Thread Nick Kew



> On 28 Apr 2020, at 12:49, Yann Ylavic  wrote:
> 
> That'd help being more reactive there, avoid having multiple places to
> follow, avoid tenchnical discussions taking place outside our mailing
> lists...
> 
> Probably more a question for infra, but what does the team think?

Please, no!

We have commits arriving at cvs@httpd (dammit, how long ago was
it we moved from cvs to svn?), bugs, and some less-used lists.
If you like to see them all in one place, get your procmail (or whatever)
to sort it locally into the same folder!

A mailbox full of messages "from" Gitbox and without meaningful
subject lines just provokes [select all] --> delete.

-- 
Nick Kew


Can github activity (new PRs, comments) be forwarded to dev@ ?

2020-04-28 Thread Yann Ylavic
That'd help being more reactive there, avoid having multiple places to
follow, avoid tenchnical discussions taking place outside our mailing
lists...

Probably more a question for infra, but what does the team think?


Re: Move FILE buckets on setaside (like/as a morphing bucket)?

2020-04-28 Thread Yann Ylavic
On Mon, Apr 27, 2020 at 6:17 PM Joe Orton  wrote:
>
> On Mon, Apr 27, 2020 at 04:27:56PM +0200, Yann Ylavic wrote:
> > On Mon, Apr 27, 2020 at 4:11 PM Joe Orton  wrote:
> > >
> > > +1 from me for using the term "opaque buckets" as a synonym for
> > > "e->length == (apr_size_t)-1" aka "buckets with indeterminate length".
> >
> > OK thanks, just committed "something" in r1877077 because I keep
> > messing up with my attachments today.
> > Let's discuss from "that" if needed..
>
> That change is definitely better.  Isn't the code still making the
> assumption that FILE is the only possible non-opaque morphing bucket
> type?
>
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_filter.c?revision=1877077&view=markup#l1108
>
> ...and by "non-opaque morphing bucket type" the distinction intended
> here is... "representing a determinate length bucket type which is not
> fully mapped into RAM until you try read()ing it until exhaustion".

I wish you don't want me to find a variable name for this :)

But yes, the code assumes that non-opaque buckets can be passed to
ap_save_brigade() without mapping more than necessary to memory (by
more than necessary I mean e.g. TRANSIENT to HEAP is fine, but
morphing an fd to HEAP isn't). So the assumption is mainly that each
bucket (besides opaque) implements ->setaside() in a "sane" manner.
Are you aware of a non-opaque bucket type for which this is an issue?

Note that there is nothing special about FILE buckets here, it's just
that we know that they don't consume memory until read, so we don't
account for their ->length against memory limits
(flush_max_threshold). We don't do that for other buckets types, so
their ->length do count.

Regards,
Yann.