buildbot success in on apr-x64-macosx-trunk

2018-08-30 Thread buildbot
The Buildbot has detected a restored build on builder apr-x64-macosx-trunk 
while building . Full details are available at:
https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/157

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: svn-x64-macosx-dgvrs

Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered 
this build
Build Source Stamp: [branch apr/apr/trunk] 1839701
Blamelist: wrowe

Build succeeded!

Sincerely,
 -The Buildbot





Re: Backports to consider for 1.6.4?

2018-08-30 Thread William A Rowe Jr
On Wed, Aug 29, 2018 at 10:30 PM, William A Rowe Jr 
wrote:

> First;
> Pull request #5 https://github.com/apache/apr/pull/5/files
> corresponds to https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
> Yann and I are neutral on dodging (fd == -1), what do others think?
> This would be a trivial one-line fix if we adopt it.
>

 Are there any committers with an opinion after reviewing the PR comments?


Re: Backports to consider for 1.6.4?

2018-08-30 Thread William A Rowe Jr
On Wed, Aug 29, 2018 at 10:40 PM, William A Rowe Jr 
wrote:

> On Wed, Aug 29, 2018 at 10:30 PM, William A Rowe Jr 
> wrote:
>
>>
>> Second;
>> Are we comfortable adding a dependency on autoconf-archive?
>> This macro below dates back to 2010. If we are not, I can
>> revert this.
>>
>
> And note I'll need to tweak the buildcheck.sh if we choose to keep
> the dependency, it already triggers a failure on our trunk/1.7 build
> machines which will need the autoconf-archive package installed.
> I can have this reverted from trunk/1.7 first thing tomorrow if the
> consensus is negative.
>

I can put this to rest, I'm not advocating for this solution. For whatever
reason, CC_FOR_BUILD was not successfully resolved by the version
of the macro on my machine (Fedora 27) in a vpath build scenario,
which suggests the macro is too unstable for general purpose use.

Reverted.


Re: 1.6 release?

2018-08-30 Thread William A Rowe Jr
This was my workaround for 1.6.x, more eyeballs and feedback welcome.


On Thu, Aug 30, 2018 at 12:23 AM, William A Rowe Jr 
wrote:
>
> Nick, please note your error in line 58 here is still not cured;
>
>
http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/time/win32/time.c?view=annotate
>
> This was buried in pull req 13, where it became a fatal bug to that
compiler.
>
> On Wed, Aug 29, 2018, 05:06 Nick Kew  wrote:
>>
>>
>> > On 27 Aug 2018, at 04:18, William A Rowe Jr 
wrote:
>> >
>> > Let's take a few more days on this. We are getting more and more good
suggestions as git merge requests to girhub.com/apache/app that are worth a
look.
>>
>> What do you envisage doing with those days?
>>
>> The motivation for a release is to fix one problem, and without risk of
>> introducing any new problem:
>>
>> > There are a lot of reports of PR62644 from solaris users of httpd, can
>> > anyone RM?
>>
>> Reviewing activity since 1.6.last, I see nothing else whose risk/reward
profile
>> cries out for a backport, unless it be some of the Windows stuff I'm in
no
>> position to judge.  Are you right now reviewing that?
>>
>> I also looked at your github link.  Among those I checked out I don't
see anything
>> there that should be dealt with in a hurry (i.e. now) rather than at
leisure in the
>> context of a minor-bugfix-release.
>>
>> --
>> Nick Kew
Index: time/win32/time.c
===
--- time/win32/time.c	(revision 1814503)
+++ time/win32/time.c	(working copy)
@@ -54,9 +54,6 @@
 static const int dayoffset[12] =
 {0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334};
 
-if (tm->wMonth < 1 || tm->wMonth > 12)
-return APR_EBADDATE;
-
 /* Note; the caller is responsible for filling in detailed tm_usec,
  * tm_gmtoff and tm_isdst data when applicable.
  */
@@ -111,6 +108,7 @@
 FileTimeToSystemTime(, );
 /* The Platform SDK documents that SYSTEMTIME/FILETIME are
  * generally UTC, so no timezone info needed
+ * The time value makes a roundtrip, st cannot be invalid below.
  */
 SystemTimeToAprExpTime(result, );
 result->tm_usec = (apr_int32_t) (input % APR_USEC_PER_SEC);
@@ -127,6 +125,7 @@
 FileTimeToSystemTime(, );
 /* The Platform SDK documents that SYSTEMTIME/FILETIME are
  * generally UTC, so we will simply note the offs used.
+ * The time value makes a roundtrip, st cannot be invalid below.
  */
 SystemTimeToAprExpTime(result, );
 result->tm_usec = (apr_int32_t) (input % APR_USEC_PER_SEC);
@@ -158,6 +157,7 @@
  * because FileTimeToLocalFileFime is documented that the
  * resulting time local file time would have DST relative
  * to the *present* date, not the date converted.
+ * The time value makes a roundtrip, localst cannot be invalid below.
  */
 SystemTimeToTzSpecificLocalTime(tz, , );
 SystemTimeToAprExpTime(result, );
@@ -187,6 +187,7 @@
 TIME_ZONE_INFORMATION tz;
 	/* XXX: This code is simply *wrong*.  The time converted will always
  * map to the *now current* status of daylight savings time.
+ * The time value makes a roundtrip, st cannot be invalid below.
  */
 
 FileTimeToLocalFileTime(, );
@@ -298,6 +299,9 @@
 /* The Platform SDK documents that SYSTEMTIME/FILETIME are
  * generally UTC, so no timezone info needed
  */
+if (tm->wMonth < 1 || tm->wMonth > 12)
+return APR_EBADDATE;
+
 SystemTimeToAprExpTime(aprtime, *ostime);
 return APR_SUCCESS;
 }