On 9/12/2011 5:01 PM, Luke Meyer wrote:
>> From: Noel Butler [mailto:[email protected]]
>> The last thing that needs to be done is make announcement when the mirrors
>> may not have synced, hence Bill's 24 hr mirror clock update time allowance
>> comment, have patience.
>
> I think the mirrors have synced on 2.2.20 long ago. Also is there any reason
> updates to the advisory haven't been announced? E.g. to tell folks not to
> worry about 1.3? Not making any demands here, just a little mystified at what
> to expect from announce@ if not these things.
Well, I had hoped that we could have pushed out the messaging a bit
early, but there are so many moving parts that we wanted to update
at once.
Please note Jeff's appeal for patch review, because I'll be pushing
these to patches/apply_to_... tomorrow at lunchtime, EDT, before we
send out the updated advisory. Catching any last snafus would be good.
--- Begin Message ---
Can anyone formally +1 the 2.2.14 and 2.2.19 patches on this thread
for promotion to apply_to?
I put the 2.0.x patch in 2.0.x/STATUS, as the code needs to be
committed first before being made available as a patch.
--- End Message ---
--- Begin Message ---
On Fri, Sep 9, 2011 at 4:29 AM, Joe Orton <[email protected]> wrote:
> On Thu, Sep 08, 2011 at 05:36:06PM -0400, Jeff Trawick wrote:
>> static apr_status_t base10_strtoff(apr_off_t *offset, const char *buf,
>> char **endptr)
>> {
>> const char *last;
>>
>> *offset = apr_atoi64(buf);
>
> I think this needs to DTRT with a 32-bit off_t.
>
> How about this?
>
> static apr_status_t strtoff(apr_off_t *offset, const char *nptr,
> char **endptr, int base)
> {
> errno = 0;
> if (sizeof(apr_off_t) == 4) {
> *offset = strtol(nptr, endptr, base);
> }
> else {
> *offset = apr_strtoi64(ptr, endptr, base);
> }
> return APR_FROM_OS_ERROR(errno);
> }
works for me
http://people.apache.org/~trawick/draft3-2.0.64-byterange-fixes.txt
Thanks!
--- End Message ---
--- Begin Message ---
On Thu, Sep 8, 2011 at 2:45 PM, Jeff Trawick <[email protected]> wrote:
> On Thu, Sep 8, 2011 at 2:17 PM, William A. Rowe Jr. <[email protected]>
> wrote:
>> On 9/8/2011 11:44 AM, Jeff Trawick wrote:
>>> On Thu, Sep 8, 2011 at 11:16 AM, Jeff Trawick <[email protected]> wrote:
>>>> Here's what I have at present:
>>>> http://people.apache.org/~trawick/2.2.20-byterange-fixes.txt
>>>>
>>>> (compiled-in max ranges, uses same AP_ symbol as 2.2.21 even though
>>>> the compiled-in version isn't the same type of "DEFAULT")
>>>>
>>>
>>> See also http://people.apache.org/~trawick/2.2.19-byterange-fixes.txt for
>>> 2.2.19
>>
>> Lovely! I think this file is far more useful, since anyone who already
>> adopted .20 should be in a good position to adopt .21, while someone
>> sitting back on .15 (or .9, gasp) might have a much bigger headache.
>>
>>> I've tested this latter patch with current framework and a separate
>>> test for numranges>200 with 2.2.14, 2.2.15, and 2.2.19. (2.2.14 needs
>>> r916627, or at least the subset of it for byterange_filter.c, before
>>> applying the patch.)
>>
>> On the 2.0 side, nothings changed since 2.0.55 that should break the patch.
>
> BTW, do any of us have an updated 2.0 patch to reflect the important
> changes since last weekend? If not, I'll need to work on thatin the
> short term.
>
>> On the 2.2 side, we might want to publish an apply_to_2.2.14 and 2.2.19,
>> just given that 2.2.9+ (which the .14 applies to) has only now reached 3
>> years old. I see no real value in working out a <2.2.8 patch /shrug
>
> works for me
>
> I'll get a 2.2.14-no-caveats patch together (i.e., no prepatch of
> r916627 required).
http://people.apache.org/~trawick/2.2.14-byterange-fixes.txt
--- End Message ---
