Re: 1.6 release?

2018-09-05 Thread William A Rowe Jr
On Mon, Sep 3, 2018 at 7:40 AM, Ivan Zhakov  wrote:

> On 25 August 2018 at 16:14, Rainer Jung  wrote:
> >
> > There's a list of changes done by Ivan Zhakov starting with 1785072 in
> early
> > 2017 to improve Win32 file I/O performance. Maybe Ivan can tell, whether
> > they can and should be backported to 1.7 (and 1.6?).
> >
> In my opinion, r1785072 should not be backported to 1.7 and 1.6, as it
> is not bug fix. As far I remember these win32 file I/O performance
> changes are quite dependend on each other and some refactorings made
> on trunk. I think it's not good idea to backport them one-by-one.
> Better way to release APR trunk at some point, instead of backporting
> non big fix changes.


The issue is that you slipped one bugfix into the optimization changeset,
and this was addressed by jfclere in a different manner since 1.6.3.

I've reverted to the conditions expressed in trunk and current readwrite.c
which you introduced in your patch to buffer.c (both in file_io/win32).

With that change, I'm aware of no other bug fixes we are blocking on,
so I'll proceed this afternoon with the tag and roll of apr 1.6.4, unless
someone raises a red flag in the next hour or two.


Re: 1.6 release?

2018-09-03 Thread Ivan Zhakov
On 25 August 2018 at 16:14, Rainer Jung  wrote:
> Am 24.08.2018 um 23:41 schrieb Nick Kew:
>>
>> On Fri, 24 Aug 2018 09:16:54 -0400
>> Eric Covener  wrote:
>>
>>> Starting a new thread as potential RM's may be filtering bugzilla
>>> emails.
>>>
>>> There are a lot of reports of PR62644 from solaris users of httpd, can
>>> anyone RM?
>>
>>
>> You've spurred me into reviewing changes in svn since last release.
>> There seems to be not much to see other than the fix for the
>> solaris poll problem.
>>
>> There's quite a bit more in trunk (some of it annoyingly
>> not labelled in commit messages).  I've gone briefly through
>> that and see no obvious backports.  Anyone else?
>
>
> There's a list of changes done by Ivan Zhakov starting with 1785072 in early
> 2017 to improve Win32 file I/O performance. Maybe Ivan can tell, whether
> they can and should be backported to 1.7 (and 1.6?).
>
In my opinion, r1785072 should not be backported to 1.7 and 1.6, as it
is not bug fix. As far I remember these win32 file I/O performance
changes are quite dependend on each other and some refactorings made
on trunk. I think it's not good idea to backport them one-by-one.
Better way to release APR trunk at some point, instead of backporting
non big fix changes.

-- 
Ivan Zhakov


Re: 1.6 release?

2018-09-02 Thread William A Rowe Jr
(Again, for the list.)

Pressing pause, thanks for the heads up.

AFAIK this is the last of open(?) issues. I'll dig deeper into this
Monday... If anyone in EU has hints scribbled down somewhere please share.

Thanks for (re-)raising!

On Sun, Sep 2, 2018, 03:43 Rainer Jung  wrote:

> I think the following, especially the part about 1834513 is still
> unhandled.
>
> Regards,
>
> Rainer
>
> Am 25.08.2018 um 15:22 schrieb Rainer Jung:
> > Am 24.08.2018 um 23:41 schrieb Nick Kew:
> >> On Fri, 24 Aug 2018 09:16:54 -0400
> >> Eric Covener  wrote:
> >>
> >>> Starting a new thread as potential RM's may be filtering bugzilla
> >>> emails.
> >>>
> >>> There are a lot of reports of PR62644 from solaris users of httpd, can
> >>> anyone RM?
> >>
> >> You've spurred me into reviewing changes in svn since last release.
> >> There seems to be not much to see other than the fix for the
> >> solaris poll problem.
> >>
> >> There's quite a bit more in trunk (some of it annoyingly
> >> not labelled in commit messages).  I've gone briefly through
> >> that and see no obvious backports.  Anyone else?
> >
> > Some inconsistencies between trunk / 1.7 and 1.6 seen by looking at
> > file_io/win32/buffer.c but the original commits also touch other files:
> >
> > % diff -u apr/apr/trunk/file_io/win32/buffer.c
> > apr/apr/branches/1.6.x/file_io/win32/buffer.c
> > --- apr/apr/trunk/file_io/win32/buffer.c2018-08-25
> > 15:05:20.124591000 +
> > +++ apr/apr/branches/1.6.x/file_io/win32/buffer.c   2018-07-28
> > 15:35:43.382858000 +
> > @@ -23,7 +23,7 @@
> >   {
> >   apr_status_t rv;
> >
> > -if (file->flags & APR_FOPEN_XTHREAD) {
> > +if (file->mutex) {
> >   apr_thread_mutex_lock(file->mutex);
> >   }
> >
> > @@ -31,7 +31,7 @@
> >   /* Flush the existing buffer */
> >   rv = apr_file_flush(file);
> >   if (rv != APR_SUCCESS) {
> > -if (file->flags & APR_FOPEN_XTHREAD) {
> > +if (file->mutex) {
> >   apr_thread_mutex_unlock(file->mutex);
> >   }
> >   return rv;
> > @@ -52,7 +52,7 @@
> >   file->buffered = 0;
> >   }
> >
> > -if (file->flags & APR_FOPEN_XTHREAD) {
> > +if (file->mutex) {
> >   apr_thread_mutex_unlock(file->mutex);
> >   }
> >
> > Introduced by r1808457 and 1829962. The first one also touches
> > file_io/win32/open.c and file_io/win32/readwrite.c in similar ways.
> >
> > Then:
> >
> > % diff -u apr/apr/branches/1.6.x/file_io/win32/buffer.c
> > apr/apr/branches/1.7.x/file_io/win32/buffer.c
> > --- apr/apr/branches/1.6.x/file_io/win32/buffer.c   2018-07-28
> > 15:35:43.382858000 +
> > +++ apr/apr/branches/1.7.x/file_io/win32/buffer.c   2017-09-25
> > 20:18:21.0 +
> > @@ -23,17 +23,13 @@
> >   {
> >   apr_status_t rv;
> >
> > -if (file->mutex) {
> > -apr_thread_mutex_lock(file->mutex);
> > -}
> > +apr_thread_mutex_lock(file->mutex);
> >
> >   if(file->buffered) {
> >   /* Flush the existing buffer */
> >   rv = apr_file_flush(file);
> >   if (rv != APR_SUCCESS) {
> > -if (file->mutex) {
> > -apr_thread_mutex_unlock(file->mutex);
> > -}
> > +apr_thread_mutex_unlock(file->mutex);
> >   return rv;
> >   }
> >   }
> > @@ -52,9 +48,7 @@
> >   file->buffered = 0;
> >   }
> >
> > -if (file->mutex) {
> > -apr_thread_mutex_unlock(file->mutex);
> > -}
> > +apr_thread_mutex_unlock(file->mutex);
> >
> >   return APR_SUCCESS;
> >   }
> >
> >
> > I think that's due to some unfinished work by Jean-Frederic. See related
> > but probably unfinished discussions on r1834513.
> >
> > Regards,
> >
> > Rainer
>


Re: 1.6 release?

2018-09-02 Thread Rainer Jung

I think the following, especially the part about 1834513 is still unhandled.

Regards,

Rainer

Am 25.08.2018 um 15:22 schrieb Rainer Jung:

Am 24.08.2018 um 23:41 schrieb Nick Kew:

On Fri, 24 Aug 2018 09:16:54 -0400
Eric Covener  wrote:


Starting a new thread as potential RM's may be filtering bugzilla
emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?


You've spurred me into reviewing changes in svn since last release.
There seems to be not much to see other than the fix for the
solaris poll problem.

There's quite a bit more in trunk (some of it annoyingly
not labelled in commit messages).  I've gone briefly through
that and see no obvious backports.  Anyone else?


Some inconsistencies between trunk / 1.7 and 1.6 seen by looking at 
file_io/win32/buffer.c but the original commits also touch other files:


% diff -u apr/apr/trunk/file_io/win32/buffer.c 
apr/apr/branches/1.6.x/file_io/win32/buffer.c
--- apr/apr/trunk/file_io/win32/buffer.c    2018-08-25 
15:05:20.124591000 +
+++ apr/apr/branches/1.6.x/file_io/win32/buffer.c   2018-07-28 
15:35:43.382858000 +

@@ -23,7 +23,7 @@
  {
  apr_status_t rv;

-    if (file->flags & APR_FOPEN_XTHREAD) {
+    if (file->mutex) {
  apr_thread_mutex_lock(file->mutex);
  }

@@ -31,7 +31,7 @@
  /* Flush the existing buffer */
  rv = apr_file_flush(file);
  if (rv != APR_SUCCESS) {
-    if (file->flags & APR_FOPEN_XTHREAD) {
+    if (file->mutex) {
  apr_thread_mutex_unlock(file->mutex);
  }
  return rv;
@@ -52,7 +52,7 @@
  file->buffered = 0;
  }

-    if (file->flags & APR_FOPEN_XTHREAD) {
+    if (file->mutex) {
  apr_thread_mutex_unlock(file->mutex);
  }

Introduced by r1808457 and 1829962. The first one also touches 
file_io/win32/open.c and file_io/win32/readwrite.c in similar ways.


Then:

% diff -u apr/apr/branches/1.6.x/file_io/win32/buffer.c 
apr/apr/branches/1.7.x/file_io/win32/buffer.c
--- apr/apr/branches/1.6.x/file_io/win32/buffer.c   2018-07-28 
15:35:43.382858000 +
+++ apr/apr/branches/1.7.x/file_io/win32/buffer.c   2017-09-25 
20:18:21.0 +

@@ -23,17 +23,13 @@
  {
  apr_status_t rv;

-    if (file->mutex) {
-    apr_thread_mutex_lock(file->mutex);
-    }
+    apr_thread_mutex_lock(file->mutex);

  if(file->buffered) {
  /* Flush the existing buffer */
  rv = apr_file_flush(file);
  if (rv != APR_SUCCESS) {
-    if (file->mutex) {
-    apr_thread_mutex_unlock(file->mutex);
-    }
+    apr_thread_mutex_unlock(file->mutex);
  return rv;
  }
  }
@@ -52,9 +48,7 @@
  file->buffered = 0;
  }

-    if (file->mutex) {
-    apr_thread_mutex_unlock(file->mutex);
-    }
+    apr_thread_mutex_unlock(file->mutex);

  return APR_SUCCESS;
  }


I think that's due to some unfinished work by Jean-Frederic. See related 
but probably unfinished discussions on r1834513.


Regards,

Rainer


Re: 1.6 release?

2018-09-01 Thread William A Rowe Jr
On Fri, Aug 24, 2018 at 8:16 AM, Eric Covener  wrote:

> Starting a new thread as potential RM's may be filtering bugzilla emails.
>
> There are a lot of reports of PR62644 from solaris users of httpd, can
> anyone RM?
>

Since I added the grit in the gears of this release, I'm happy to roll and
submit a tarball for review tomorrow, unless someone else wants the
experience.

Sunday tarball gives us all day Mon, Tues (US holiday/workday) wrapping up
on Wed on the 72 hour clock. There aren't so many changes that this should
be difficult to review.


Re: 1.6 release?

2018-08-31 Thread Nick Kew


> On 30 Aug 2018, at 07:20, William A Rowe Jr  wrote:
> 
> This was my workaround for 1.6.x, more eyeballs and feedback welcome.

Looks fine to me.

I've dug deep in memory for that change: it was down to protecting a caller
who had fed bad inputs to apr_time_exp_get.  The broken change was
additional to the fix, as it appeared to be another case of the same thing.

Reviewing your fix, it does what that should've done and gets it right.
At least for callers who take any notice of returned errors!

-- 
Nick Kew


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;
 }


Re: 1.6 release?

2018-08-29 Thread Nick Kew


> On 29 Aug 2018, at 16:08, William Kimball Jr.  
> wrote:
> 
> Speaking of suggestions, may I please suggest closing a glaring security hole 
> in apr_dbd_mysql, per https://bz.apache.org/bugzilla/show_bug.cgi?id=62342? I 
> have provided diffs for 1.5 -- because my organization uses RHEL 7, which 
> uses APR 1.5 -- and 2.0 -- because someone on this list instructed me to do 
> so.  I'm happy to do the same for 1.6.

Thanks, that looks as if it makes sense.

Currently we're looking at an APR-1.6 release ASAP.  Not APR-UTIL, which is 
where
an apr_dbd patch applies, so this isn't of immediate concern.  But yes, it 
looks like
something we should patch for future releases.

-- 
Nick Kew

Re: 1.6 release?

2018-08-29 Thread William Kimball Jr.
Speaking of suggestions, may I please suggest closing a glaring security 
hole in apr_dbd_mysql, per 
https://bz.apache.org/bugzilla/show_bug.cgi?id=62342? I have provided 
diffs for 1.5 -- because my organization uses RHEL 7, which uses APR 1.5 
-- and 2.0 -- because someone on this list instructed me to do so.  I'm 
happy to do the same for 1.6.


We've been using this patch in production -- where every 
server-to-server connection must be encrypted -- for several months and 
it's working very well for us.



On 8/26/2018 10:18 PM, 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.


On Fri, Aug 24, 2018, 08:17 Eric Covener > wrote:


Starting a new thread as potential RM's may be filtering bugzilla
emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?

-- 
Eric Covener

cove...@gmail.com 


--
This message has been scanned for viruses and
dangerous content by *MailScanner* , and is
believed to be clean. 



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: 1.6 release?

2018-08-29 Thread Nick Kew


> 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

Re: 1.6 release?

2018-08-26 Thread William A Rowe Jr
For our consideration...

https://github.com/apache/apr/pulls

On Sun, Aug 26, 2018, 22: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.
>
> On Fri, Aug 24, 2018, 08:17 Eric Covener  wrote:
>
>> Starting a new thread as potential RM's may be filtering bugzilla emails.
>>
>> There are a lot of reports of PR62644 from solaris users of httpd, can
>> anyone RM?
>>
>> --
>> Eric Covener
>> cove...@gmail.com
>>
>


Re: 1.6 release?

2018-08-26 Thread William A Rowe Jr
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.

On Fri, Aug 24, 2018, 08:17 Eric Covener  wrote:

> Starting a new thread as potential RM's may be filtering bugzilla emails.
>
> There are a lot of reports of PR62644 from solaris users of httpd, can
> anyone RM?
>
> --
> Eric Covener
> cove...@gmail.com
>


Re: 1.6 release?

2018-08-25 Thread Nick Kew


> On 25 Aug 2018, at 14:14, Rainer Jung  wrote:
> 
> 
> There's a list of changes done by Ivan Zhakov starting with 1785072 in early 
> 2017 to improve Win32 file I/O performance. Maybe Ivan can tell, whether they 
> can and should be backported to 1.7 (and 1.6?).

My thought would be 1.7 probably yes, 1.6 probably no - on the grounds that i 
can't say
with any confidence that it's safe from any regression.  One for the Windows 
folks?

-- 
Nick Kew

Re: 1.6 release?

2018-08-25 Thread Rainer Jung

Am 24.08.2018 um 23:41 schrieb Nick Kew:

On Fri, 24 Aug 2018 09:16:54 -0400
Eric Covener  wrote:


Starting a new thread as potential RM's may be filtering bugzilla
emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?


You've spurred me into reviewing changes in svn since last release.
There seems to be not much to see other than the fix for the
solaris poll problem.

There's quite a bit more in trunk (some of it annoyingly
not labelled in commit messages).  I've gone briefly through
that and see no obvious backports.  Anyone else?


Some inconsistencies between trunk / 1.7 and 1.6 seen by looking at 
file_io/win32/buffer.c but the original commits also touch other files:


% diff -u apr/apr/trunk/file_io/win32/buffer.c 
apr/apr/branches/1.6.x/file_io/win32/buffer.c
--- apr/apr/trunk/file_io/win32/buffer.c2018-08-25 
15:05:20.124591000 +
+++ apr/apr/branches/1.6.x/file_io/win32/buffer.c   2018-07-28 
15:35:43.382858000 +

@@ -23,7 +23,7 @@
 {
 apr_status_t rv;

-if (file->flags & APR_FOPEN_XTHREAD) {
+if (file->mutex) {
 apr_thread_mutex_lock(file->mutex);
 }

@@ -31,7 +31,7 @@
 /* Flush the existing buffer */
 rv = apr_file_flush(file);
 if (rv != APR_SUCCESS) {
-if (file->flags & APR_FOPEN_XTHREAD) {
+if (file->mutex) {
 apr_thread_mutex_unlock(file->mutex);
 }
 return rv;
@@ -52,7 +52,7 @@
 file->buffered = 0;
 }

-if (file->flags & APR_FOPEN_XTHREAD) {
+if (file->mutex) {
 apr_thread_mutex_unlock(file->mutex);
 }

Introduced by r1808457 and 1829962. The first one also touches 
file_io/win32/open.c and file_io/win32/readwrite.c in similar ways.


Then:

% diff -u apr/apr/branches/1.6.x/file_io/win32/buffer.c 
apr/apr/branches/1.7.x/file_io/win32/buffer.c
--- apr/apr/branches/1.6.x/file_io/win32/buffer.c   2018-07-28 
15:35:43.382858000 +
+++ apr/apr/branches/1.7.x/file_io/win32/buffer.c   2017-09-25 
20:18:21.0 +

@@ -23,17 +23,13 @@
 {
 apr_status_t rv;

-if (file->mutex) {
-apr_thread_mutex_lock(file->mutex);
-}
+apr_thread_mutex_lock(file->mutex);

 if(file->buffered) {
 /* Flush the existing buffer */
 rv = apr_file_flush(file);
 if (rv != APR_SUCCESS) {
-if (file->mutex) {
-apr_thread_mutex_unlock(file->mutex);
-}
+apr_thread_mutex_unlock(file->mutex);
 return rv;
 }
 }
@@ -52,9 +48,7 @@
 file->buffered = 0;
 }

-if (file->mutex) {
-apr_thread_mutex_unlock(file->mutex);
-}
+apr_thread_mutex_unlock(file->mutex);

 return APR_SUCCESS;
 }


I think that's due to some unfinished work by Jean-Frederic. See related 
but probably unfinished discussions on r1834513.


Regards,

Rainer


Re: 1.6 release?

2018-08-25 Thread Rainer Jung

Am 24.08.2018 um 23:41 schrieb Nick Kew:

On Fri, 24 Aug 2018 09:16:54 -0400
Eric Covener  wrote:


Starting a new thread as potential RM's may be filtering bugzilla
emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?


You've spurred me into reviewing changes in svn since last release.
There seems to be not much to see other than the fix for the
solaris poll problem.

There's quite a bit more in trunk (some of it annoyingly
not labelled in commit messages).  I've gone briefly through
that and see no obvious backports.  Anyone else?


There's a list of changes done by Ivan Zhakov starting with 1785072 in 
early 2017 to improve Win32 file I/O performance. Maybe Ivan can tell, 
whether they can and should be backported to 1.7 (and 1.6?).


Regards,

Rainer



Re: 1.6 release?

2018-08-24 Thread Yann Ylavic
On Fri, Aug 24, 2018 at 11:42 PM Nick Kew  wrote:
>
> On Fri, 24 Aug 2018 09:16:54 -0400
> Eric Covener  wrote:
>
> > Starting a new thread as potential RM's may be filtering bugzilla
> > emails.
> >
> > There are a lot of reports of PR62644 from solaris users of httpd, can
> > anyone RM?
>
> You've spurred me into reviewing changes in svn since last release.
> There seems to be not much to see other than the fix for the
> solaris poll problem.

AFAICT, since 1.6.3 there are:
- r1819938 (solaris pollset/port wakeup) plus follow up r1838963,
- r1823146 (use after free with APR_POOL_DEBUG),
- r1825312 (error handling in gdbm),
- r1828284 (configure: fix detection of net/if.h on openbsd),
- r1828361 (uint32_t => size_t in apr_pools),
- r1834558 (tll=0 handling in reslists),
- r1834513 (check for mutex != NULL in apr_file_buffer_set).

>
> There's quite a bit more in trunk (some of it annoyingly
> not labelled in commit messages).  I've gone briefly through
> that and see no obvious backports.  Anyone else?

The other/latest changes in trunk seem to be targeted for 1.7.x, so I
think we are good for 1.6.x => 1.6.4.

Regards,
Yann.


Re: 1.6 release?

2018-08-24 Thread Nick Kew
On Fri, 24 Aug 2018 09:16:54 -0400
Eric Covener  wrote:

> Starting a new thread as potential RM's may be filtering bugzilla
> emails.
> 
> There are a lot of reports of PR62644 from solaris users of httpd, can
> anyone RM?

You've spurred me into reviewing changes in svn since last release.
There seems to be not much to see other than the fix for the
solaris poll problem.

There's quite a bit more in trunk (some of it annoyingly
not labelled in commit messages).  I've gone briefly through
that and see no obvious backports.  Anyone else?

-- 
Nick Kew


Re: 1.6 release?

2018-08-24 Thread Dennis Clarke

On 08/24/2018 12:48 PM, Eric Covener wrote:

On Fri, Aug 24, 2018 at 12:37 PM Dennis Clarke  wrote:


On 08/24/2018 09:16 AM, Eric Covener wrote:

Starting a new thread as potential RM's may be filtering bugzilla emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?



I am running a few versions of httpd on solaris and have not seen any
issues.  Is there a bug report somewhere ?


https://bz.apache.org/bugzilla/show_bug.cgi?id=62644



Both 61786 and 62644 are marked RESOLVED one way or another. Regardless,
seems to be on Solaris x86/Intel/AMD gear and I have not seen that in a
dogs age.  Could spin it up merely to look.

Dennis


Re: 1.6 release?

2018-08-24 Thread Jim Jagielski
If no one volunteers, I will.

> On Aug 24, 2018, at 9:16 AM, Eric Covener  wrote:
> 
> Starting a new thread as potential RM's may be filtering bugzilla emails.
> 
> There are a lot of reports of PR62644 from solaris users of httpd, can
> anyone RM?
> 
> -- 
> Eric Covener
> cove...@gmail.com



Re: 1.6 release?

2018-08-24 Thread Eric Covener
On Fri, Aug 24, 2018 at 12:37 PM Dennis Clarke  wrote:
>
> On 08/24/2018 09:16 AM, Eric Covener wrote:
> > Starting a new thread as potential RM's may be filtering bugzilla emails.
> >
> > There are a lot of reports of PR62644 from solaris users of httpd, can
> > anyone RM?
> >
>
> I am running a few versions of httpd on solaris and have not seen any
> issues.  Is there a bug report somewhere ?

https://bz.apache.org/bugzilla/show_bug.cgi?id=62644


Re: 1.6 release?

2018-08-24 Thread Dennis Clarke

On 08/24/2018 09:16 AM, Eric Covener wrote:

Starting a new thread as potential RM's may be filtering bugzilla emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?



I am running a few versions of httpd on solaris and have not seen any 
issues.  Is there a bug report somewhere ?


Dennis


Re: 1.6 release timetable

2017-04-07 Thread Yann Ylavic
On Sat, Apr 8, 2017 at 12:52 AM, Nick Kew  wrote:
> On Fri, 17 Mar 2017 23:31:34 +
> Nick Kew  wrote:
>
> One thing catches my eye.  In STATUS, a proposal added by
> Jim in 2013 of, but with no votes to it:
>
> * Add object perms set macros and implement them for shm and mutex
>   Trunk patch:
>   http://svn.apache.org/viewvc?view=revision=741862
>   http://svn.apache.org/viewvc?view=revision=741869 1.5.x
>   patch:
>   http://people.apache.org/~jim/patches/apr-1.5-permset.patch +1:
>
> That's quite a big patch.  The commits referenced are from Mladen.
> Do either of you (or anyone) want to take up cudgels on this, or
> are we content to leave it as-is (in 2.0 but not 1.x)?

++1 to add it to 1.6, will have a look and test it.


Regards,
Yann.


Re: 1.6 release timetable

2017-04-07 Thread Nick Kew
On Fri, 17 Mar 2017 23:31:34 +
Nick Kew  wrote:

> [chop]

We're looking nearly ready: I have just one more thing to
do (apart from re-testing on Mac with the latest fixes).

One thing catches my eye.  In STATUS, a proposal added by
Jim in 2013 of, but with no votes to it:

* Add object perms set macros and implement them for shm and mutex
  Trunk patch:
  http://svn.apache.org/viewvc?view=revision=741862
  http://svn.apache.org/viewvc?view=revision=741869 1.5.x
  patch:
  http://people.apache.org/~jim/patches/apr-1.5-permset.patch +1:

That's quite a big patch.  The commits referenced are from Mladen.
Do either of you (or anyone) want to take up cudgels on this, or
are we content to leave it as-is (in 2.0 but not 1.x)?

-- 
Nick Kew


Re: 1.6 release timetable

2017-03-25 Thread Florian Weimer
* Yann Ylavic:

>> It's been a bit of a struggle to get this right.
>
> I think the confusion comes from the term "directory stream", which
> people (at least me :p ) may read as underlying directory (i.e.
> filesystem's), though it's the term used to talk about the DIR* in the
> whole man page...

> I now realize that there is no real thread-safety issue, it indeed
> shouldn't happen to call readdir() concurrently on the same DIR, IMHO
> the doc should say that it's simply undefined behaviour (actually I
> thought it was the case with readdir_r too, so the readdir_r part is
> the misleading one I think).

Thanks for this feedback.

>> I think the Solaris manual also does not mark readdir as thread-safe,
>> implicitly suggesting to use readdir_r in multi-threaded programs.
>> But this suggestion isn't helpful on Solaris, either.
>
> So Solaris' readdir() does not return static data either.

Right.

> Any idea of which system keeps doing this?

No one who monitors the Austin Groups tracker for POSIX issues does
it, otherwise they would have spoken out against the readdir_r
deprecation.


Re: 1.6 release timetable

2017-03-25 Thread Yann Ylavic
On Sat, Mar 25, 2017 at 1:34 PM, Florian Weimer  wrote:
> * Yann Ylavic:
>> "In the current POSIX.1 specification (POSIX.1-2008),
>> readdir() is not required to be thread-safe.  However, in modern
>> implementations (including the glibc implementation), concurrent calls
>> to readdir() that specify different directory streams are thread-safe.
>> In cases where multiple threads must read from the same directory
>> stream, using readdir() with external synchronization is still
>> preferable to the use of the  deprecated readdir_r(3) function.  It is
>> expected that a future version of POSIX.1 will require that readdir()
>> be thread-safe when concurrently employed on different directory
>> streams."
>
> It's been a bit of a struggle to get this right.

I think the confusion comes from the term "directory stream", which
people (at least me :p ) may read as underlying directory (i.e.
filesystem's), though it's the term used to talk about the DIR* in the
whole man page...

> People are really
> concerned about the case where multiple threads read from the same
> directory stream.  But how often does that happen in practice?

I now realize that there is no real thread-safety issue, it indeed
shouldn't happen to call readdir() concurrently on the same DIR, IMHO
the doc should say that it's simply undefined behaviour (actually I
thought it was the case with readdir_r too, so the readdir_r part is
the misleading one I think).

>>
>> Are you thinking of the above editorial?
>
> I meant this part:
>
>   Preliminary: | MT-Unsafe race:dirstream | AS-Unsafe lock | AC-Unsafe
> lock | See POSIX Safety Concepts.
>
> 
>
> “MT-Unsafe race:dirstream” doesn't make much sense because we don't
> have this as a category for memcpy because for some reason, it is
> “obvious” for memcpy that it's only thread-safe if it is called for
> completely separate arguments.

OK, got it now, thanks!

>
> I think the Solaris manual also does not mark readdir as thread-safe,
> implicitly suggesting to use readdir_r in multi-threaded programs.
> But this suggestion isn't helpful on Solaris, either.

So Solaris' readdir() does not return static data either.
Any idea of which system keeps doing this?


Re: 1.6 release timetable

2017-03-25 Thread Florian Weimer
* Yann Ylavic:

> [Resend to the whole list, sorry Florian for private message]
>
> On Sat, Mar 25, 2017 at 1:20 PM, Yann Ylavic  wrote:
>>
>> Right, modern readdir()s seem to be thread-safe but with regard to
>> different directories only, at least Linux' man page states:
>> "In the current POSIX.1 specification (POSIX.1-2008),
>> readdir() is not required to be thread-safe.  However, in modern
>> implementations (including the glibc implementation), concurrent calls
>> to readdir() that specify different directory streams are thread-safe.
>> In cases where multiple threads must read from the same directory
>> stream, using readdir() with external synchronization is still
>> preferable to the use of the  deprecated readdir_r(3) function.  It is
>> expected that a future version of POSIX.1 will require that readdir()
>> be thread-safe when concurrently employed on different directory
>> streams."
>
> Maybe we could simply forward this requirement (external
> synchronization) in the definition/usage of apr_dir_read()...

That's reasonable, but it's counterproductive to document that.  Most
programmers will assume that they have to perform special locking for
this function, which isn't true.  There really isn't anything special
about readdir and apr_dir_read.  It's mostly an accident that readdir
was labeled as thread-unsafe, which led to this mess, so please do not
repeat this for apr_dir_read.


Re: 1.6 release timetable

2017-03-25 Thread Yann Ylavic
[Resend to the whole list, sorry Florian for private message]

On Sat, Mar 25, 2017 at 1:20 PM, Yann Ylavic  wrote:
>
> Right, modern readdir()s seem to be thread-safe but with regard to
> different directories only, at least Linux' man page states:
> "In the current POSIX.1 specification (POSIX.1-2008),
> readdir() is not required to be thread-safe.  However, in modern
> implementations (including the glibc implementation), concurrent calls
> to readdir() that specify different directory streams are thread-safe.
> In cases where multiple threads must read from the same directory
> stream, using readdir() with external synchronization is still
> preferable to the use of the  deprecated readdir_r(3) function.  It is
> expected that a future version of POSIX.1 will require that readdir()
> be thread-safe when concurrently employed on different directory
> streams."

Maybe we could simply forward this requirement (external
synchronization) in the definition/usage of apr_dir_read()...


Re: 1.6 release timetable

2017-03-25 Thread Florian Weimer
* Yann Ylavic:

>> readdir is thread-safe.  There used to be this idea that fdopendir
>> could be implemented like this:
>>
>> DIR *
>> fdopendir (int fd)
>> {
>>   return (DIR *) fd;
>> }
>>
>> And readdir would use a static buffer for the directory entry (like
>> gethostbyname) instead of something which is allocated as part of the
>> opaque the DIR * object (similar to a FILE *).  Such systems may
>> indeed have existed at one point, but I doubt that you can compile APR
>> on them.  It's unlikely that these systems will support readdir_r
>> because it is much to recent an interface.
>
> Right, modern readdir()s seem to be thread-safe but with regard to
> different directories only, at least Linux' man page states:
> "In the current POSIX.1 specification (POSIX.1-2008),
> readdir() is not required to be thread-safe.  However, in modern
> implementations (including the glibc implementation), concurrent calls
> to readdir() that specify different directory streams are thread-safe.
> In cases where multiple threads must read from the same directory
> stream, using readdir() with external synchronization is still
> preferable to the use of the  deprecated readdir_r(3) function.  It is
> expected that a future version of POSIX.1 will require that readdir()
> be thread-safe when concurrently employed on different directory
> streams."

It's been a bit of a struggle to get this right.  People are really
concerned about the case where multiple threads read from the same
directory stream.  But how often does that happen in practice?

>> For systems which use a buffer embedded in the DIR * object (and I'm
>> not aware of any which don't), readdir is as thread-safe as memcpy,
>> although some manual pages claim it is not.  This is very likely an
>> editorial mistake because thread safety guarantees for functions which
>> operate on separate objects are still an evolving concept.
>
> Are you thinking of the above editorial?

I meant this part:

  Preliminary: | MT-Unsafe race:dirstream | AS-Unsafe lock | AC-Unsafe
lock | See POSIX Safety Concepts.



“MT-Unsafe race:dirstream” doesn't make much sense because we don't
have this as a category for memcpy because for some reason, it is
“obvious” for memcpy that it's only thread-safe if it is called for
completely separate arguments.

I think the Solaris manual also does not mark readdir as thread-safe,
implicitly suggesting to use readdir_r in multi-threaded programs.
But this suggestion isn't helpful on Solaris, either.

>> Just stop using readdir_r.  I know that many people are invested in
>> that interface for various reasons, but sometimes, you just have to
>> delete pointless code and get on with it.
>
> I'm not sure we can use readdir() blindy though, what if multiple
> threads use it on the same dir?

Then the current implementation is already broken because apr_dir_read
does not perform any locking: The call to readdir_r can write to the
d_name buffer, and the reads of the d_name in apr_dir_read constitute
a data race.

If you mean “the same directory on the file system”: What counts is
the same DIR * object.  If two objects iterate through the same
directory, this does not matter because each DIR * object is required
to keep its own iteration position.


Re: 1.6 release timetable

2017-03-25 Thread Yann Ylavic
On Sat, Mar 25, 2017 at 12:53 PM, Florian Weimer  wrote:
> * Yann Ylavic:
>
>> On Fri, Mar 24, 2017 at 7:35 PM, William A Rowe Jr
>>  wrote:
>>>
>>> I haven't built 1.x branch against openssl 110 yet,
>>
>> I did with 1.6.x (on latest Debian's libbsl-1.1) with no issue.
>>
>>> so here's some Unix (latest Fedora) feedback;
>>>
>>> ../../apr-1.6/file_io/unix/dir.c: In function ‘apr_dir_read’:
>>> ../../apr-1.6/file_io/unix/dir.c:162:5: warning: ‘readdir_r’ is
>>> deprecated [-Wdeprecated-declarations]
>>>  ret = readdir_r(thedir->dirstruct, thedir->entry, );
>>>  ^~~
>>> In file included from
>>> /home/wrowe/dev/apr-1.6/include/arch/unix/apr_arch_file_io.h:50:0,
>>>  from ../../apr-1.6/file_io/unix/dir.c:17:
>>> /usr/include/dirent.h:183:12: note: declared here
>>>  extern int readdir_r (DIR *__restrict __dirp,
>>> ^
>>
>> Same here, but this is really a weird situation where readdir_r() is
>> deprecated and "googling" advises are either to use readdir() with a
>> lock (because it's not thread-safe...),
>
> readdir is thread-safe.  There used to be this idea that fdopendir
> could be implemented like this:
>
> DIR *
> fdopendir (int fd)
> {
>   return (DIR *) fd;
> }
>
> And readdir would use a static buffer for the directory entry (like
> gethostbyname) instead of something which is allocated as part of the
> opaque the DIR * object (similar to a FILE *).  Such systems may
> indeed have existed at one point, but I doubt that you can compile APR
> on them.  It's unlikely that these systems will support readdir_r
> because it is much to recent an interface.

Right, modern readdir()s seem to be thread-safe but with regard to
different directories only, at least Linux' man page states:
"In the current POSIX.1 specification (POSIX.1-2008),
readdir() is not required to be thread-safe.  However, in modern
implementations (including the glibc implementation), concurrent calls
to readdir() that specify different directory streams are thread-safe.
In cases where multiple threads must read from the same directory
stream, using readdir() with external synchronization is still
preferable to the use of the  deprecated readdir_r(3) function.  It is
expected that a future version of POSIX.1 will require that readdir()
be thread-safe when concurrently employed on different directory
streams."

>
> For systems which use a buffer embedded in the DIR * object (and I'm
> not aware of any which don't), readdir is as thread-safe as memcpy,
> although some manual pages claim it is not.  This is very likely an
> editorial mistake because thread safety guarantees for functions which
> operate on separate objects are still an evolving concept.

Are you thinking of the above editorial?

>
>> or to still use readdir_r()
>> but malloc the passed in entry (with an overly complicated/hardly
>> portable thing to compute its size) so to avoid the defect (albeit not
>> the warning!) because of which readdir_r() is deprecated.
>
> It doesn't avoid all defects.  On most systems, computing the correct
> size of the readdir_r buffer is close to impossible (because of races
> which are very difficult to eliminate, or lack of correct name length
> information from the operating system), and readdir_r cannot check
> that the buffer is large enough because it is not passed the
> allocation size.

Agreed, if there were a solution with readdir_r() I guess the libc
would have implemented it...

>
> There is at least one implementation of readdir_r which will return
> ENAMETOOLONG if names are longer than NAME_MAX characters, while
> readdir will return such names, so using readdir_r will result in
> non-listable directories.
>
> Just stop using readdir_r.  I know that many people are invested in
> that interface for various reasons, but sometimes, you just have to
> delete pointless code and get on with it.

I'm not sure we can use readdir() blindy though, what if multiple
threads use it on the same dir?


Re: 1.6 release timetable

2017-03-25 Thread Florian Weimer
* Yann Ylavic:

> On Fri, Mar 24, 2017 at 7:35 PM, William A Rowe Jr
>  wrote:
>>
>> I haven't built 1.x branch against openssl 110 yet,
>
> I did with 1.6.x (on latest Debian's libbsl-1.1) with no issue.
>
>> so here's some Unix (latest Fedora) feedback;
>>
>> ../../apr-1.6/file_io/unix/dir.c: In function ‘apr_dir_read’:
>> ../../apr-1.6/file_io/unix/dir.c:162:5: warning: ‘readdir_r’ is
>> deprecated [-Wdeprecated-declarations]
>>  ret = readdir_r(thedir->dirstruct, thedir->entry, );
>>  ^~~
>> In file included from
>> /home/wrowe/dev/apr-1.6/include/arch/unix/apr_arch_file_io.h:50:0,
>>  from ../../apr-1.6/file_io/unix/dir.c:17:
>> /usr/include/dirent.h:183:12: note: declared here
>>  extern int readdir_r (DIR *__restrict __dirp,
>> ^
>
> Same here, but this is really a weird situation where readdir_r() is
> deprecated and "googling" advises are either to use readdir() with a
> lock (because it's not thread-safe...),

readdir is thread-safe.  There used to be this idea that fdopendir
could be implemented like this:

DIR *
fdopendir (int fd)
{
  return (DIR *) fd;
}

And readdir would use a static buffer for the directory entry (like
gethostbyname) instead of something which is allocated as part of the
opaque the DIR * object (similar to a FILE *).  Such systems may
indeed have existed at one point, but I doubt that you can compile APR
on them.  It's unlikely that these systems will support readdir_r
because it is much to recent an interface.

For systems which use a buffer embedded in the DIR * object (and I'm
not aware of any which don't), readdir is as thread-safe as memcpy,
although some manual pages claim it is not.  This is very likely an
editorial mistake because thread safety guarantees for functions which
operate on separate objects are still an evolving concept.

> or to still use readdir_r()
> but malloc the passed in entry (with an overly complicated/hardly
> portable thing to compute its size) so to avoid the defect (albeit not
> the warning!) because of which readdir_r() is deprecated.

It doesn't avoid all defects.  On most systems, computing the correct
size of the readdir_r buffer is close to impossible (because of races
which are very difficult to eliminate, or lack of correct name length
information from the operating system), and readdir_r cannot check
that the buffer is large enough because it is not passed the
allocation size.

There is at least one implementation of readdir_r which will return
ENAMETOOLONG if names are longer than NAME_MAX characters, while
readdir will return such names, so using readdir_r will result in
non-listable directories.

Just stop using readdir_r.  I know that many people are invested in
that interface for various reasons, but sometimes, you just have to
delete pointless code and get on with it.


Re: 1.6 release timetable

2017-03-25 Thread Yann Ylavic
On Fri, Mar 24, 2017 at 7:35 PM, William A Rowe Jr  wrote:
>
> I haven't built 1.x branch against openssl 110 yet,

I did with 1.6.x (on latest Debian's libbsl-1.1) with no issue.

> so here's some Unix (latest Fedora) feedback;
>
> ../../apr-1.6/file_io/unix/dir.c: In function ‘apr_dir_read’:
> ../../apr-1.6/file_io/unix/dir.c:162:5: warning: ‘readdir_r’ is
> deprecated [-Wdeprecated-declarations]
>  ret = readdir_r(thedir->dirstruct, thedir->entry, );
>  ^~~
> In file included from
> /home/wrowe/dev/apr-1.6/include/arch/unix/apr_arch_file_io.h:50:0,
>  from ../../apr-1.6/file_io/unix/dir.c:17:
> /usr/include/dirent.h:183:12: note: declared here
>  extern int readdir_r (DIR *__restrict __dirp,
> ^

Same here, but this is really a weird situation where readdir_r() is
deprecated and "googling" advises are either to use readdir() with a
lock (because it's not thread-safe...), or to still use readdir_r()
but malloc the passed in entry (with an overly complicated/hardly
portable thing to compute its size) so to avoid the defect (albeit not
the warning!) because of which readdir_r() is deprecated.

No good solution is short (AIUI)...


Re: 1.6 release timetable

2017-03-24 Thread William A Rowe Jr
On Thu, Mar 23, 2017 at 1:01 PM, Nick Kew  wrote:
> On Thu, 2017-03-23 at 10:13 -0700, Gregg Smith wrote:
>
>> My retro build changes and Jan's revised patch have been commited.
>> Windows should be good to go.
>
> Brilliant, thanks both.

+1

> I'll take the activity on this issue as an indication that
> Windows was already *otherwise* good.  Unless we hear to
> the contrary!

I'll have more before month end, but no availability in the next few days
to review Windows. I haven't built 1.x branch against openssl 110 yet,
so here's some Unix (latest Fedora) feedback;

../../apr-1.6/file_io/unix/dir.c: In function ‘apr_dir_read’:
../../apr-1.6/file_io/unix/dir.c:162:5: warning: ‘readdir_r’ is
deprecated [-Wdeprecated-declarations]
 ret = readdir_r(thedir->dirstruct, thedir->entry, );
 ^~~
In file included from
/home/wrowe/dev/apr-1.6/include/arch/unix/apr_arch_file_io.h:50:0,
 from ../../apr-1.6/file_io/unix/dir.c:17:
/usr/include/dirent.h:183:12: note: declared here
 extern int readdir_r (DIR *__restrict __dirp,
^

../../apr-util-1.6/dbm/apr_dbm_ndbm.c: In function ‘vt_ndbm_open’:
../../apr-util-1.6/dbm/apr_dbm_ndbm.c:100:25: warning: passing
argument 1 of ‘dbm_open’ discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
 file = dbm_open(pathname, dbmode, apr_posix_perms2mode(perm));
 ^~~~
In file included from ../../apr-util-1.6/dbm/apr_dbm_ndbm.c:29:0:
/usr/include/ndbm.h:55:14: note: expected ‘char *’ but argument is of
type ‘const char *’
 extern DBM  *dbm_open (char *file, int flags, int mode);
  ^~~~

And normal gummed up private vs public autogunk side-effects;

In file included from /usr/include/mysql/my_config.h:14:0,
 from /usr/include/mysql/my_global.h:75,
 from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:38:
/usr/include/mysql/my_config-x86_64.h:649:0: warning: "PACKAGE_NAME" redefined
 #define PACKAGE_NAME "MySQL Server"

In file included from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:22:0:
/home/wrowe/dev/build/aprutil16-ossl110/include/private/apu_config.h:175:0:
note: this is the location of the previous definition
 #define PACKAGE_NAME ""

In file included from /usr/include/mysql/my_config.h:14:0,
 from /usr/include/mysql/my_global.h:75,
 from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:38:
/usr/include/mysql/my_config-x86_64.h:650:0: warning: "PACKAGE_STRING" redefined
 #define PACKAGE_STRING "MySQL Server 10.1.21"

In file included from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:22:0:
/home/wrowe/dev/build/aprutil16-ossl110/include/private/apu_config.h:178:0:
note: this is the location of the previous definition
 #define PACKAGE_STRING ""

In file included from /usr/include/mysql/my_config.h:14:0,
 from /usr/include/mysql/my_global.h:75,
 from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:38:
/usr/include/mysql/my_config-x86_64.h:651:0: warning:
"PACKAGE_TARNAME" redefined
 #define PACKAGE_TARNAME "mysql"

In file included from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:22:0:
/home/wrowe/dev/build/aprutil16-ossl110/include/private/apu_config.h:181:0:
note: this is the location of the previous definition
 #define PACKAGE_TARNAME ""

In file included from /usr/include/mysql/my_config.h:14:0,
 from /usr/include/mysql/my_global.h:75,
 from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:38:
/usr/include/mysql/my_config-x86_64.h:652:0: warning:
"PACKAGE_VERSION" redefined
 #define PACKAGE_VERSION "10.1.21"

In file included from ../../apr-util-1.6/dbd/apr_dbd_mysql.c:22:0:
/home/wrowe/dev/build/aprutil16-ossl110/include/private/apu_config.h:187:0:
note: this is the location of the previous definition
 #define PACKAGE_VERSION ""


Re: 1.6 release timetable

2017-03-23 Thread Nick Kew
On Thu, 2017-03-23 at 10:13 -0700, Gregg Smith wrote:

> My retro build changes and Jan's revised patch have been commited.
> Windows should be good to go.

Brilliant, thanks both.

I'll take the activity on this issue as an indication that
Windows was already *otherwise* good.  Unless we hear to
the contrary!

-- 
Nick Kew




Re: 1.6 release timetable

2017-03-23 Thread Gregg Smith


On 3/22/2017 8:30 AM, Nick Kew wrote:


Gregg, any thoughts on a timeframe for commit?  Obviously
nice-to-have,
though I'm also thinking if we have to release without a fix, we
can
at least use Jan's latest post in a release note.

--
Nick Kew



My retro build changes and Jan's revised patch have been commited.
Windows should be good to go.


Re: 1.6 release timetable - diffCMakeLists-jan.patch (1/1)

2017-03-23 Thread Jan Ehrhardt

begin 644 diffCMakeLists-jan.patch
M26YD97@Z($--86ME3=',N='AT#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M#0HM+2T@0TUA:V5,:7-T'0)*')E=FES:6]N(#$W.#2D-"D!`("TR,S@L-R`K,C,X
M+#<@0$`-"B!3150H:6YS=&%L;%]T87)G971S("1[:6YS=&%L;%]T87)G971S
M?2!L:6)A<')U=+3$I"B!3150H:6YS=&%L;%]B:6Y?<&1B("1[:6YS=&%L
M;%]B:6Y?<&1B?2`D>U!23TI%0U1?0DE.05)97T1)4GTO;!R=71I;"TQ
M+G!D8BD*(%1!4D=%5%],24Y+7TQ)0E)!4DE%4RAL:6)A<')U=+3$@)'M!
M4%)?3$E"4D%22453?2`D>UA-3$Q)0E],24)205))15-]*0HM4T547U1!4D=%
M5%]04D]015)42453*%P7!T;U]O
M<&5N7!T;U]O<&5N

Re: 1.6 release timetable - diffCMakeLists-jan.patch (0/1)

2017-03-23 Thread Jan Ehrhardt
Gregg Smith in gmane.comp.apache.apr.devel (Wed, 22 Mar 2017 10:20:54
-0700):
>I got a patch for cmake from Jan (attached) which ended up off list due 
>to the way "reply" works on this list.

The patch added -DAPR_DECLARE_EXPORT=1 -DAPU_DECLARE_EXPORT=1 twice to
apr_crypto_openssl. New patch attached.
-- 
Jan



Re: 1.6 release timetable

2017-03-22 Thread Gregg Smith

On 3/22/2017 8:30 AM, Nick Kew wrote:

[sorry, reposting by cut from this morning when mail was broken]
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:

> I've been hacking on the .mak and .win files.
> Had to add a -ossl1 to apr/build/cvtdsp.pl for the dsp file,
no other
> way around it that I have been able to figure out.
>
> I have apu building at the command line, with either openssl
1.0.2 or
> 1.1.0. IIRC 1.0.2 is a LTS version and is going to be around
for awhile
> still.
>
> Have comitted nothing at this point as I want to test a IDE
build. Not
> that we have ever been able to build the crypto modules from
the IDE
> without modifying the build manually/scripted.

Gregg, any thoughts on a timeframe for commit?  Obviously
nice-to-have,
though I'm also thinking if we have to release without a fix, we
can
at least use Jan's latest post in a release note.

--
Nick Kew



I'll try to get the retro build stuff committed before bed tonight, 
tomorrow latest.


I got a patch for cmake from Jan (attached) which ended up off list due 
to the way "reply" works on this list.



Gregg
Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 1787649)
+++ CMakeLists.txt  (working copy)
@@ -238,7 +238,7 @@
 SET(install_targets ${install_targets} libaprutil-1)
 SET(install_bin_pdb ${install_bin_pdb} ${PROJECT_BINARY_DIR}/libaprutil-1.pdb)
 TARGET_LINK_LIBRARIES(libaprutil-1 ${APR_LIBRARIES} ${XMLLIB_LIBRARIES})
-SET_TARGET_PROPERTIES(libaprutil-1 PROPERTIES COMPILE_DEFINITIONS 
"APU_DECLARE_EXPORT;XML_STATIC;WINNT")
+SET_TARGET_PROPERTIES(libaprutil-1 PROPERTIES COMPILE_DEFINITIONS 
"APU_DECLARE_EXPORT;APR_DECLARE_EXPORT;XML_STATIC;WINNT")
 
 ADD_LIBRARY(aprutil-1 STATIC ${APR_SOURCES} ${APR_PUBLIC_HEADERS_GENERATED})
 SET(install_targets ${install_targets} aprutil-1)
@@ -254,7 +254,7 @@
   SET(install_bin_pdb ${install_bin_pdb} 
${PROJECT_BINARY_DIR}/apr_crypto_openssl-1.pdb)
   SET_TARGET_PROPERTIES(apr_crypto_openssl-1 PROPERTIES INCLUDE_DIRECTORIES 
"${APR_INCLUDE_DIRECTORIES};${OPENSSL_INCLUDE_DIR}")
   SET_TARGET_PROPERTIES(apr_crypto_openssl-1 PROPERTIES COMPILE_DEFINITIONS 
"WINNT")
-  SET_TARGET_PROPERTIES(apr_crypto_openssl-1 PROPERTIES COMPILE_FLAGS 
"-DDLL_NAME=apr_crypto_openssl")
+  SET_TARGET_PROPERTIES(apr_crypto_openssl-1 PROPERTIES COMPILE_FLAGS 
"-DAPR_DECLARE_EXPORT=1 -DAPU_DECLARE_EXPORT=1 -DAPR_DECLARE_EXPORT=1 
-DAPU_DECLARE_EXPORT=1 -DDLL_NAME=apr_crypto_openssl")
   TARGET_LINK_LIBRARIES(apr_crypto_openssl-1 libaprutil-1 ${APR_LIBRARIES} 
${OPENSSL_LIBRARIES})
 ENDIF()
 
@@ -265,8 +265,8 @@
   SET(dbd_drivers ${dbd_drivers} odbc)
   TARGET_LINK_LIBRARIES(apr_dbd_odbc-1 libaprutil-1 ${APR_LIBRARIES} odbc32 
odbccp32)
   SET_PROPERTY(TARGET apr_dbd_odbc-1 APPEND PROPERTY LINK_FLAGS 
/export:apr_dbd_odbc_driver)
-  SET_TARGET_PROPERTIES(apr_dbd_odbc-1 PROPERTIES COMPILE_DEFINITIONS 
"APU_HAVE_ODBC;HAVE_SQL_H;APU_DECLARE_EXPORT;APU_DSO_MODULE_BUILD;WINNT")
-  SET_TARGET_PROPERTIES(apr_dbd_odbc-1 PROPERTIES COMPILE_FLAGS 
"-DDLL_NAME=apr_dbd_odbc")
+  SET_TARGET_PROPERTIES(apr_dbd_odbc-1 PROPERTIES COMPILE_DEFINITIONS 
"APU_HAVE_ODBC;HAVE_SQL_H;APU_DECLARE_EXPORT;APR_DECLARE_EXPORT;APU_DSO_MODULE_BUILD;WINNT")
+  SET_TARGET_PROPERTIES(apr_dbd_odbc-1 PROPERTIES COMPILE_FLAGS 
"-DAPR_DECLARE_EXPORT=1 -DAPU_DECLARE_EXPORT=1 -DDLL_NAME=apr_dbd_odbc")
 ENDIF()
 
 IF(APR_HAS_LDAP)
@@ -276,7 +276,7 @@
   SET(install_bin_pdb ${install_bin_pdb} ${PROJECT_BINARY_DIR}/apr_ldap-1.pdb)
   TARGET_LINK_LIBRARIES(apr_ldap-1 libaprutil-1 ${APR_LIBRARIES} 
${LDAP_LIBRARIES})
   SET_TARGET_PROPERTIES(apr_ldap-1 PROPERTIES COMPILE_DEFINITIONS "WINNT")
-  SET_TARGET_PROPERTIES(apr_ldap-1 PROPERTIES COMPILE_FLAGS 
"-DDLL_NAME=apr_ldap")
+  SET_TARGET_PROPERTIES(apr_ldap-1 PROPERTIES COMPILE_FLAGS 
"-DAPR_DECLARE_EXPORT=1 -DAPU_DECLARE_EXPORT=1 -DDLL_NAME=apr_ldap")
   SET(apr_ldap_libraries apr_ldap-1)
 ELSE()
   SET(apr_ldap_libraries)


Re: 1.6 release timetable

2017-03-22 Thread Nick Kew
[sorry, reposting by cut from this morning when mail was broken]
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:

> I've been hacking on the .mak and .win files.
> Had to add a -ossl1 to apr/build/cvtdsp.pl for the dsp file,
no other 
> way around it that I have been able to figure out.
> 
> I have apu building at the command line, with either openssl
1.0.2 or 
> 1.1.0. IIRC 1.0.2 is a LTS version and is going to be around
for awhile 
> still.
> 
> Have comitted nothing at this point as I want to test a IDE
build. Not 
> that we have ever been able to build the crypto modules from
the IDE 
> without modifying the build manually/scripted.

Gregg, any thoughts on a timeframe for commit?  Obviously
nice-to-have,
though I'm also thinking if we have to release without a fix, we
can
at least use Jan's latest post in a release note.

-- 
Nick Kew



Re: 1.6 release timetable

2017-03-22 Thread Nick Kew
[sorry, reposting by cut from this morning when mail was broken]
On Mon, 2017-03-20 at 03:20 +0100, Jan Ehrhardt wrote:

> Jan Ehrhardt in gmane.comp.apache.apr.devel (Sun, 19 Mar 2017
20:21:47 +0100):
> >>So, the answer to the question "does it work for you?" seems
to be No.

I guess that means the platform doesn't benefit from a toolchain
anything like the *X configuration scripts that work flexibly
with whatever is available?

(Sorry, it's about 15 years since I touched any Windows
platform,
beyond trivial rescue when someone insists I'm the computer
man).

> 
> CMake almost works. I had the following dirs

> Steps for compiling the VC14 x64 libs and dll's:

Thanks for the very clear description.  I guess that will make a
release note if we have to release without anything better.

> I did not run any tests, but it is a start.

crypto appears to be a gap in the tests, anyway!

-- 
Nick Kew



Re: 1.6 release timetable

2017-03-19 Thread Gregg Smith

Arg, this list bites me again. Sorry for the double Jan.

On 3/19/2017 11:44 AM, Jan Ehrhardt wrote:

Nick Kew in gmane.comp.apache.apr.devel (Sat, 18 Mar 2017 07:57:37
+):

On Sat, 2017-03-18 at 08:28 +0100, Jan Ehrhardt wrote:


Will this 1.6 release contain support of OpenSSL 1.1.x or is that part
of a future release?


Good question.  I see no bugzilla entry for it.  A quick search
on this list reveals just two messages, dated 29/3/16.
Are you asking whether the changes Rainer refers to in
http://mail-archives.apache.org/mod_mbox/apr-dev/201603.mbox/%3C56FA52EC.8050301%40kippdata.de%3E
are in it?  If so, your own feedback to Rainer's "does it
work for you?" question would be great?


The 2 Windows related files in apr/apr-util/crypto still use the pre-1.1
OpenSSL lib files, libeay32.lib and ssleay32.lib:
http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/crypto/apr_crypto_openssl.dsp?view=markup#l121
http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/crypto/apr_crypto_openssl.mak?view=markup#l108

So, the answer to the question "does it work for you?" seems to be No.



I've been hacking on the .mak and .win files.
Had to add a -ossl1 to apr/build/cvtdsp.pl for the dsp file, no other 
way around it that I have been able to figure out.


I have apu building at the command line, with either openssl 1.0.2 or 
1.1.0. IIRC 1.0.2 is a LTS version and is going to be around for awhile 
still.


Have comitted nothing at this point as I want to test a IDE build. Not 
that we have ever been able to build the crypto modules from the IDE 
without modifying the build manually/scripted.




Re: 1.6 release timetable

2017-03-19 Thread Jan Ehrhardt
Jan Ehrhardt in gmane.comp.apache.apr.devel (Mon, 20 Mar 2017 03:20:36 +0100):
>. compile apr-util, with the CMake args on 1 line:
snip
>call msbuild APR.sln /p:Configuration=RelWithDebInfo /p:Platform=x64
Copy-paste eror. For apr-util this has to be

call msbuild APR-Util.sln /p:Configuration=RelWithDebInfo /p:Platform=x64
-- 
Jan



Re: 1.6 release timetable

2017-03-19 Thread Jan Ehrhardt
Jan Ehrhardt in gmane.comp.apache.apr.devel (Sun, 19 Mar 2017 20:21:47 +0100):
>>So, the answer to the question "does it work for you?" seems to be No.
>
>Or Yes, if CMake works. I will try that later.

CMake almost works. I had the following dirs
- apr
  - apr
  - apr-util
- xml
  - openssl

For apr and apr-util I used the 1.6.x branches:
http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/
http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/

Steps for compiling the VC14 x64 libs and dll's:
. compile OpenSSL (version 1.1.0e).
. copy the XML headers to \apr\apr-util\include
. install \apr\apr\include\apr.h manually (cf apr 1.4/OpenSSL 1.0.2)
. compile apr, with the CMake args on 1 line:

set INCLUDE=\apr\openssl\include;%INCLUDE%
set LIB=\apr\openssl\;%LIB%
set PATH=\apr\openssl\apps;%PATH%
cd \apr\apr
if exist \apr\apr\vc14.x64 rd \apr\apr\vc14.x64
md \apr\apr\vc14.x64
cd \apr\apr\vc14.x64
cmake -G "Visual Studio 14 2015 Win64" -D CMAKE_BUILD_TYPE=RelWithDebInfo \
-D APR_BUILD_TESTAPR=1 -D CMAKE_INSTALL_PREFIX=\apr\install \
-D INSTALL_PDB=OFF .. 
pause
call msbuild APR.sln /p:Configuration=RelWithDebInfo /p:Platform=x64
call msbuild INSTALL.vcxproj /p:Configuration=RelWithDebInfo /p:Platform=x64

. compile apr-util, with the CMake args on 1 line:

set INCLUDE=\apr\openssl\include;%INCLUDE%
set LIB=\apr\openssl\;%LIB%
set PATH=\apr\openssl\apps;%PATH%
cd \apr\apr-util
if exist \apr\apr-util\vc14.x64 rd \apr\apr-util\vc14.x64
md \apr\apr-util\vc14.x64
cd \apr\apr-util\vc14.x64
cmake -G "Visual Studio 14 2015 Win64" \
-D OPENSSL_ROOT_DIR=\apr\openssl -D 
OPENSSL_INCLUDE_DIR=\apr\openssl\include \
-D APR_INCLUDE_DIR=\apr\apr\include -D 
APR_LIBRARIES=\apr\apr\vc14.x64\RelWithDebInfo\libapr-1.lib \
-D APU_HAVE_CRYPTO=1 -D APR_BUILD_TESTAPR=1 -D 
CMAKE_INSTALL_PREFIX=\apr\install -D INSTALL_PDB=OFF ..
pause
perl -pi.bak -e 
"s/;APU_DECLARE_EXPORT;/;APR_DECLARE_EXPORT;APU_DECLARE_EXPORT;/gi" 
libaprutil-1.vcxproj
for %%f in (*.vcxproj) do perl -pi.bak -e 
"s/;DLL_NAME=/;APR_DECLARE_EXPORT;APU_DECLARE_EXPORT;DLL_NAME=/gi" %%f
call msbuild APR.sln /p:Configuration=RelWithDebInfo /p:Platform=x64
call msbuild INSTALL.vcxproj /p:Configuration=RelWithDebInfo /p:Platform=x64

The two perl replacements are need to avoid errors that dllimport
is not allowed. They can be patched into the apr-util CMakeLists.txt

Result (zipped from \apr\install):
https://phpdev.toolsforresearch.com/apr-1.6.x.zip

I did not run any tests, but it is a start.
-- 
Jan



Re: 1.6 release timetable

2017-03-19 Thread Jan Ehrhardt
Jan Ehrhardt in gmane.comp.apache.apr.devel (Sun, 19 Mar 2017 19:44:01
+0100):
>The 2 Windows related files in apr/apr-util/crypto still use the pre-1.1
>OpenSSL lib files, libeay32.lib and ssleay32.lib:
>http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/crypto/apr_crypto_openssl.dsp?view=markup#l121
>http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/crypto/apr_crypto_openssl.mak?view=markup#l108
>
>So, the answer to the question "does it work for you?" seems to be No.

Or Yes, if CMake works. I will try that later.
-- 
Jan



Re: 1.6 release timetable

2017-03-19 Thread Jan Ehrhardt
Nick Kew in gmane.comp.apache.apr.devel (Sat, 18 Mar 2017 07:57:37
+):
>On Sat, 2017-03-18 at 08:28 +0100, Jan Ehrhardt wrote:
>
>> Will this 1.6 release contain support of OpenSSL 1.1.x or is that part
>> of a future release?
>
>Good question.  I see no bugzilla entry for it.  A quick search
>on this list reveals just two messages, dated 29/3/16.
>Are you asking whether the changes Rainer refers to in
>http://mail-archives.apache.org/mod_mbox/apr-dev/201603.mbox/%3C56FA52EC.8050301%40kippdata.de%3E
>are in it?  If so, your own feedback to Rainer's "does it
>work for you?" question would be great?

The 2 Windows related files in apr/apr-util/crypto still use the pre-1.1
OpenSSL lib files, libeay32.lib and ssleay32.lib:
http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/crypto/apr_crypto_openssl.dsp?view=markup#l121
http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/crypto/apr_crypto_openssl.mak?view=markup#l108

So, the answer to the question "does it work for you?" seems to be No.
-- 
Jan



Re: 1.6 release timetable

2017-03-18 Thread Nick Kew
On Sat, 2017-03-18 at 08:28 +0100, Jan Ehrhardt wrote:
> Nick Kew in gmane.comp.apache.apr.devel (Fri, 17 Mar 2017 23:31:34
> +):
> >We have a backlog of mostly-minor fixes to 1.x unreleased.
> >I think we're all agreed that the best way to deal with them
> >is to roll a 1.6 release.
> 
> Will this 1.6 release contain support of OpenSSL 1.1.x or is that part
> of a future release?

Good question.  I see no bugzilla entry for it.  A quick search
on this list reveals just two messages, dated 29/3/16.
Are you asking whether the changes Rainer refers to in
http://mail-archives.apache.org/mod_mbox/apr-dev/201603.mbox/%
3C56FA52EC.8050301%40kippdata.de%3E
are in it?  If so, your own feedback to Rainer's "does it
work for you?" question would be great?

-- 
Nick Kew



Re: 1.6 release timetable

2017-03-18 Thread Jan Ehrhardt
Nick Kew in gmane.comp.apache.apr.devel (Fri, 17 Mar 2017 23:31:34
+):
>We have a backlog of mostly-minor fixes to 1.x unreleased.
>I think we're all agreed that the best way to deal with them
>is to roll a 1.6 release.

Will this 1.6 release contain support of OpenSSL 1.1.x or is that part
of a future release?
-- 
Jan