[poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)

:13 William A Rowe Jr wrote: > AFAICT the very last 'nit' is our bad habit of using the deprecated > readdir_r()/readdir64_t() functions in modern gcc. Comparing ./configure > and make reminds me I had a kludge to finish in my working 1.7 tree. See > https://www.gnu.org/software/libc/m

Re: Showstoppers to 1.7.0?

by recent BSD/OSX fixes would be very much appreciated. On Wed, Feb 27, 2019, 17:06 William A Rowe Jr wrote: > With several new features added to the 1.7 branch, the fixes to the > Netware locking we had deferred, and the proposed correction of > SIGUSR2, I'm wondering what we see as

Re: svn commit: r1856064 - in /apr/apr/branches/1.7.x: ./ configure.in

=$apr_save_CFLAGS +$3], [CFLAGS=$apr_save_CFLAGS +$4]) ]) dnl On Fri, Mar 22, 2019 at 11:49 AM Yann Ylavic wrote: > On Fri, Mar 22, 2019 at 4:28 PM William A Rowe Jr > wrote: > > +checking whether int64_t and int use fmt %d... checking whether int64_t > and long use fmt %ld... yes > >

Re: svn commit: r1856064 - in /apr/apr/branches/1.7.x: ./ configure.in

) don't evaluate as you might expect them to. On Fri, Mar 22, 2019 at 11:49 AM Yann Ylavic wrote: > On Fri, Mar 22, 2019 at 4:28 PM William A Rowe Jr > wrote: > > +checking whether int64_t and int use fmt %d... checking whether int64_t > and long use fmt %ld... yes > >

Re: Verifying printf() formatting of types

On Fri, Mar 22, 2019 at 7:23 AM Stefan Sperling wrote: > > INT64_C() returns a 'LL'-suffixed constant on OpenBSD, and int64_t > is indeed a 'long long': > *That's* what I've been missing, thanks! BSD is wrong. It should have been using the "fastest" shortest-int that represented 64-bits, but

Re: svn commit: r1856042 - in /apr/apr/trunk: build/apr_common.m4 configure.in include/apr.h.in

On Fri, Mar 22, 2019 at 6:58 AM wrote: > Author: ylavic > Date: Fri Mar 22 11:52:22 2019 > New Revision: 1856042 > > URL: http://svn.apache.org/viewvc?rev=1856042=rev > Log: > Use stdint types and inttypes formats when both available. > > Which should be the case on modern platforms, no change

Re: Showstoppers to 1.7.0?

On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr wrote: > With several new features added to the 1.7 branch, the fixes to the > Netware locking we had deferred, and the proposed correction of > SIGUSR2, I'm wondering what we see as remaining obstacles. > > Do we want to do som

Re: Verifying printf() formatting of types

On Tue, Mar 19, 2019 at 6:35 PM Stefan Sperling wrote: > On Tue, Mar 19, 2019 at 02:09:51PM -0500, William A Rowe Jr wrote: > > I find no errors in our APR_TIME -> APR_INT64 determination, and > > made no such changes. > > > > But I note httpd 2.4.x commit r182

Re: Showstoppers to 1.7.0?

On Tue, Mar 19, 2019 at 1:51 PM Jim Jagielski wrote: > Under OSX/macOS, whether off_t and/or size_t are long long or long > depends on compile time and the actual platform being compiled for. > To have a universal *.h file, you need those checks for __LP64__ > that are determined during the

Re: Verifying printf() formatting of types

On Tue, Mar 19, 2019 at 5:18 AM Stefan Sperling wrote: > I don't believe your diff attempts to address this, but I am stilling > seeing a problem with APR_TIME_T_FMT when compiling httpd: > > proxy_util.c:3179: warning: format '%ld' expects type 'long int', but > argument 9 has type 'long long

Re: Showstoppers to 1.7.0?

On Tue, Mar 19, 2019 at 12:58 PM Jim Jagielski wrote: > > Hi Bill, can you let me know what issues you saw? Last I checked, the > Darwin stuff in configure.in and apr.h.in hasn't been touched, nor an > issue, > in ages, except for the recent DARWIN pre-defined cpp macro hiccup. > Hi Jim - see

Re: Showstoppers to 1.7.0?

Hi Greg, On Tue, Mar 12, 2019 at 6:42 PM Gregg Smith wrote: > I finally got time to give this 1.7.0 a try and utterly failed :) > > r1839494 fixed a problem run into on VC when r1816608 added support for > IPv6 link-local address scope/zone mapping. r1839494 requires NT6. > > Our apr.hw is

Incomplete r1667900 -

APR has a number of apr.h templates for non-./configure platforms. It looks like the introduction of timedlocks overlooks these, this needs to be fixed before 1.7.0 is tagged. Yann, would you like to fix? Index: include/apr.hnw ===

Re: APR thread_mutex_cleanup on windows mishandles being called twice

On Tue, Mar 19, 2019 at 12:12 PM William A Rowe Jr wrote: > >>> >>> The proper reset value wouldn't be NULL but INVALID_HANDLE_VALUE, which >>> is defined like: >>> >>> >>> >>> #define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR

Re: APR thread_mutex_cleanup on windows mishandles being called twice

On Tue, Mar 19, 2019 at 12:10 PM William A Rowe Jr wrote: > On Tue, Mar 19, 2019 at 11:41 AM Michael Schlenker < > michael.schlen...@contact-software.com> wrote: > >> *Von:* William A Rowe Jr [mailto:wr...@rowe-clan.net] >> *Gesendet:* Dienstag, 19. März 2019 16:36

Re: APR thread_mutex_cleanup on windows mishandles being called twice

On Tue, Mar 19, 2019 at 11:41 AM Michael Schlenker < michael.schlen...@contact-software.com> wrote: > *Von:* William A Rowe Jr [mailto:wr...@rowe-clan.net] > *Gesendet:* Dienstag, 19. März 2019 16:36 > *An:* Michael Schlenker > *Cc:* Stefan Sperling ; dev@apr.apache.org &g

Re: APR thread_mutex_cleanup on windows mishandles being called twice

On Tue, Mar 19, 2019 at 10:01 AM Michael Schlenker < michael.schlen...@contact-software.com> wrote: > > > -Ursprüngliche Nachricht- > > Von: Stefan Sperling [mailto:s...@stsp.name] > > Gesendet: Dienstag, 19. März 2019 15:35 > > An: Michael Schlenker > > Cc: dev@apr.apache.org > >

Re: Verifying printf() formatting of types

On Mon, Mar 18, 2019 at 5:09 PM William A Rowe Jr wrote: > > please test the attached, it works for me on Fedora, but need to verify at > least BSD, Solaris, etc. mingw remains special-case so it shouldn't be > affected. This should force off_t_fmt to "ldd" in the

Verifying printf() formatting of types

Hi folks, please test the attached, it works for me on Fedora, but need to verify at least BSD, Solaris, etc. mingw remains special-case so it shouldn't be affected. This should force off_t_fmt to "ldd" in the cases Stefan observed. Notably, it might not do the right thing with respect to

Re: Wrong definition of APR_OFF_T_FMT in apr.h

On Fri, Mar 15, 2019 at 7:04 PM Jim Jagielski wrote: > macOS is not truly BSD... it's mach and so while there are a lot of > similarities, one cannot equate the 2... this just may be one of those > areas where macOS/Mach != BSD > That's true.The point I raised is that without DARWIN defines,

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 3:02 PM Yann Ylavic wrote: > On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr > wrote: > > > > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic > wrote: > >> > >> Possibly to resolve APR__T_FMT on system with > >> [std]

Re: Wrong definition of APR_OFF_T_FMT in apr.h

Jim, Stefan, wuzhouhui... On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski wrote: > > FWIW, I have apr-1.6 here and cannot confirm the below. When compiling w/ httpd, DARWIN_10 is defined as required. > > > On Mar 3, 2019, at 9:26 AM, wuzhouhui wrote: > > > > ~/Downloads/apr-1.6.5$ gcc -I./include

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 3:02 PM Yann Ylavic wrote: > On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr > wrote: > > > > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic > wrote: > >> > >> Possibly to resolve APR__T_FMT on system with > >> [std]

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic wrote: > Possibly to resolve APR__T_FMT on system with > [std]int[types].h, we could bind to the standard (C99?) format > PR[dxo..]N, especially since we configure the format based off > $ac_cv_sizeof_, so something like: > #define APR__T_FMT

Re: http://svn.apache.org/r1850745

To take this discussion all the way back to APR project's potential concerns... On Wed, Mar 13, 2019 at 8:03 AM Jim Jagielski wrote: > > > On Mar 13, 2019, at 8:56 AM, Nick Kew wrote: > > > >> On 13 Mar 2019, at 12:43, Jim Jagielski wrote: > >> > >> Is there anyone else building 2.4 on macOS

Re: Significant warning of a real issue on initial ./configure ?

in our macros, blame them on libtool. I've silenced the debugging emit from our mkdir.sh, so that's 4 lines of noise removed from a clean vpath build. On Wed, Mar 13, 2019 at 12:16 PM Yann Ylavic wrote: > On Wed, Mar 13, 2019 at 6:10 PM William A Rowe Jr > wrote: > > > > On

Re: Significant warning of a real issue on initial ./configure ?

On Wed, Mar 13, 2019 at 11:58 AM Yann Ylavic wrote: > On Wed, Mar 13, 2019 at 5:20 PM William A Rowe Jr > wrote: > > > > I think this comes from; > > > > AC_LIBTOOL_WIN32_DLL > > AC_PROG_LIBTOOL > > # get libtool's setting of shlibpath_var >

Re: Significant warning of a real issue on initial ./configure ?

_YOUR_SHLIBPATH_VAR fi The assignment of shlibpath_var within an eval isn't promoted into the current env table, right? This code following AC_PROG_LIBTOOL appears to be a no--op unless I'm missing something obvious. On Wed, Mar 13, 2019 at 11:04 AM William A Rowe Jr wrote: >

Significant warning of a real issue on initial ./configure ?

First pass; rm: cannot remove 'conftest*': No such file or directory rm: cannot remove 'conftest*': No such file or directory grep: /home/wrowe/dev/build/apr2-ossl111/libtool: No such file or directory We cause that last step in configure.in of apr. During a first ./configure in a vpath build,

Re: Showstoppers to 1.7.0?

ut changing that default in apr.hw from > 0x0501 to 0x0601 or 0x0600 at minimum? > > I do not remember if a PMC vote was required when we went from 400 to > 500 to 501. > > Cheers, > > Gregg > > > > On 2/27/2019 3:06 PM, William A Rowe Jr wrote: >

Re: Showstoppers to 1.7.0?

On Tue, Mar 12, 2019 at 1:59 PM William A Rowe Jr wrote: > > One obvious flaw I had missed in my earlier list, the problem with > maintainer mode strictness and our APR_OFF_T_FMT warnings. > > I think the patch is as simple as prioritizing int over long... which > would be the

Re: Showstoppers to 1.7.0?

On Fri, Mar 8, 2019 at 2:19 PM William A Rowe Jr wrote: > > I'd like to give this question a few more days, and finally lock down > our 1.7.0 candidate sometime later next week. > One obvious flaw I had missed in my earlier list, the problem with maintainer mode strictness and our A

Re: Showstoppers to 1.7.0?

On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr wrote: > With several new features added to the 1.7 branch, the fixes to the > Netware locking we had deferred, and the proposed correction of > SIGUSR2, I'm wondering what we see as remaining obstacles. > These two appear to be i

Re: svn commit: r1854123 - in /apr/apr/trunk: CHANGES threadproc/unix/signals.c

Hi Yann, did you want to backport this to 1.7.0 branch? Do we want to identify the delta and old pre-1.7 behavior in the doxygen of this function? On Fri, Feb 22, 2019 at 3:21 AM wrote: > Author: ylavic > Date: Fri Feb 22 09:21:19 2019 > New Revision: 1854123 > > URL:

Re: Showstoppers to 1.7.0?

On Fri, Mar 1, 2019 at 5:01 AM Yann Ylavic wrote: > On Thu, Feb 28, 2019 at 12:06 AM William A Rowe Jr > wrote: > > > > Any other concerns ahead of 1.7.0? > > There are some backports I need to revert, the dynamic linking (as > opposed to dynamic loading) of apr_crypt

Showstoppers to 1.7.0?

With several new features added to the 1.7 branch, the fixes to the Netware locking we had deferred, and the proposed correction of SIGUSR2, I'm wondering what we see as remaining obstacles. I'd like to proceed with addressing the symlink vs. "other" reparse tag questions raised for Windows, and

Re: Allow SIGUSR2 with apr_signal_thread()

On Fri, Feb 22, 2019 at 3:08 AM Yann Ylavic wrote: > On Fri, Feb 22, 2019 at 9:33 AM Branko Čibej wrote: > > Even if that tool did work this way 16 years ago, this was the wrong way > > to solve the "problem". It's not APR's job to support such tools (except > > for pool debugging modes); it's

Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD

On Thu, Jan 17, 2019 at 2:18 PM Stefan Sperling wrote: > > I would appreciate if someone could commit my configure.in patch > which adds overrides for OpenBSD specifically. That would fix my > immediate problem. And perhaps a better fix could be devised later? > I'd prefer we not glue around

Re: pool debugging and httpd HTTP/2

On Mon, Jan 14, 2019 at 12:56 PM Stefan Sperling wrote: > On Mon, Jan 14, 2019 at 11:38:55AM -0600, William A Rowe Jr wrote: > > On Mon, Jan 14, 2019 at 8:42 AM Stefan Sperling wrote: > > > > > > FYI, the reason APR pool debugging is enabled in production on Open

Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD

On Wed, Jan 9, 2019 at 3:26 PM Branko Čibej wrote: > > On Wed, Jan 9, 2019 at 9:38 AM Stefan Sperling wrote: > > > >> APR's configure script logic results in inconsistent type and format > >> string definitions on OpenBSD. apr_off_t is defined as 'long long' > >> but APR_OFF_T_FMT is defined as

Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD

On Wed, Jan 9, 2019 at 9:38 AM Stefan Sperling wrote: > APR's configure script logic results in inconsistent type and format > string definitions on OpenBSD. apr_off_t is defined as 'long long' > but APR_OFF_T_FMT is defined as "ld". > > This results in obvious build failures e.g. if httpd is

Re: Was this a bug in APR from 2008?

On Fri, Nov 30, 2018 at 10:18 AM Eric Covener wrote: > On Fri, Nov 30, 2018 at 11:00 AM William A Rowe Jr > wrote: > > > > The comment here makes no sense (unix, not windows). But the patch > itself seems reasonable. There is a performance hit, but nothing compared > to

Re: Was this a bug in APR from 2008?

The comment here makes no sense (unix, not windows). But the patch itself seems reasonable. There is a performance hit, but nothing compared to the call into stat/lstat. Other's opinions? --- ./srclib/apr/file_io/unix/filestat.c2007-10-17 00:36:49.0 -0300 +++

Re: Hashes for apr downloads

On Tue, Sep 18, 2018 at 8:21 AM Ruediger Pluem wrote: > > On 09/18/2018 02:52 PM, William A Rowe Jr wrote: > > Note that in moderation of annou...@apache.org annou...@apache.org>, I received the following response; > > > >> MD5 and SHA1 hashes have been deprec

Hashes for apr downloads

Note that in moderation of annou...@apache.org, I received the following response; > MD5 and SHA1 hashes have been deprecated for some time on download pages (*) > > Please update the download page(s) to remove these. > > (*) http://www.apache.org/dev/release-distribution#sigs-and-sums Are we

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

On Mon, Sep 17, 2018 at 10:52 AM Jim Jagielski wrote: > Would like to also propose for apr-1.7... > > *Subject: **svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp > atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c > include/apr_atomic.h

Apache Portable Runtime APR 1.6.5 Released

Apache Portable Runtime APR 1.6.5 Released The Apache Software Foundation and the Apache Portable Runtime Project are proud to announce the General Availability of version 1.6.5 of the Apache Portable Runtime library (APR). Version 1.6.1 of the APR Utility library (APR-util) and

[Results] [VOTE] apr-1.6.5 release

On Mon, Sep 10, 2018 at 4:22 PM William A Rowe Jr wrote: > Please cast your votes on the following release candidate > found at http://apr.apache.org/dev/dist/ (note release.sh > is generating sha256+sha512, all in coreutils format.) > > Release apr-1.6.5 > [ ]

Re: [VOTE] apr-1.6.5 release

On Tue, Sep 11, 2018 at 3:16 PM Dennis Clarke wrote: > > I am not sure if we care about a few items below. On Solaris 10 SPARC it > seems to work with a few minor notes. > > TCP isn't corkable ?? > > testsock : Cannot test if connect completes synchronously ?? The way to answer this

Re: [VOTE] apr-1.6.5 release

On Mon, Sep 10, 2018 at 4:22 PM William A Rowe Jr wrote: > Please cast your votes on the following release candidate > found at http://apr.apache.org/dev/dist/ (note release.sh > is generating sha256+sha512, all in coreutils format.) > > Release apr-1.6.5 > [+1] +/-1 >

[VOTE] apr-1.6.5 release

Please cast your votes on the following release candidate found at http://apr.apache.org/dev/dist/ (note release.sh is generating sha256+sha512, all in coreutils format.) Release apr-1.6.5 [ ] +/-1 This vote will conclude at 5pm EDT Thursday 9/13, for announcement Friday in the event of a

Re: [VOTE] apr-1.6.4 release?

On Fri, Sep 7, 2018 at 11:19 AM William A Rowe Jr wrote: > Please cast your votes on the following release candidate > found at http://apr.apache.org/dev/dist/ > > Release apr-1.6.4 > This candidate is withdrawn from consideration for release. The 1.6.5 candidate follows once fo

Re: [VOTE] apr-1.6.4 release?

Agreed, fix applied. Steffen, if you like, you can recheck the build against https://svn.apache.org/repos/asf/apr/apr/branches/1.6.x/ checkout. On Sat, Sep 8, 2018 at 4:04 AM Rainer Jung wrote: > Correct, r1839769 plus backports are the culprit. Looks like "tm->" must > be replaced by

[VOTE] apr-1.6.4 release?

Please cast your votes on the following release candidate found at http://apr.apache.org/dev/dist/ Release apr-1.6.4 [ ] +/-1 This vote will conclude at 1pm EDT Monday 9/10, for announcement Tuesday in the event of a successful vote.

Re: 1.6 release?

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

Re: 1.6 release?

(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

Re: 1.6 release?

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

Re: svn commit: r1839755 - in /apr/apr/trunk: include/apr_json.h json/apr_json.c json/apr_json_decode.c

On Fri, Aug 31, 2018 at 11:20 AM, Rainer Jung wrote: > To clarify: the CI build failures only send a summary email to the dev > list. If you want to see the output, you need to visit the CI build page > (link included in the failure mail) and there clock on the appropriate > "stdio" link. That's

Re: svn commit: r1839755 - in /apr/apr/trunk: include/apr_json.h json/apr_json.c json/apr_json_decode.c

ILD FAILED: failed Test Sincerely, -The Buildbot On Fri, Aug 31, 2018 at 9:17 AM, Eric Covener wrote: > On Fri, Aug 31, 2018 at 10:04 AM Yann Ylavic wrote: > > > > On Fri, Aug 31, 2018 at 3:29 PM William A Rowe Jr > wrote: > > > > > > I presume you are subscrib

Re: svn commit: r1839755 - in /apr/apr/trunk: include/apr_json.h json/apr_json.c json/apr_json_decode.c

I presume you are subscribed to the commits list, which broadcasts our CI results? testjson: FAILED 1 of 7Line 62: expected something other than <{ "Image" : {"Width" : 800 ,"IDs" : [116, 943, 234, 38793],"Title" : "View from 15th Floor","Animated" : false,

Re: Backports to consider for 1.6.4?

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 wou

Re: Backports to consider for 1.6.4?

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 ca

Re: 1.6 release?

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?v

Re: Backports to consider for 1.6.4?

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 k

Backports to consider for 1.6.4?

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. Second; Are we comfortable adding a

Re: 1.6 release?

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. > >

Re: 1.6 release?

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

Init/de-init of aprfoo-1.so providers

Giving this problem some thought... If an aprfoo-1.so provider is linked to the libfoo.so library, and we track the init state and perform it only once, it seems that apr should never try to de-init or unload the .so provider for the lifespan of the process. This should help us avoid some

Re: Reminder and caution

hat is this email about? > > > On Tue, Jul 24, 2018 at 9:43 PM William A Rowe Jr > wrote: > >> *Change Process* >> >> Most changes (bug fixes and minor, commonsense feature adds) do not >> require review. Developers are encouraged to request review for: >

Reminder and caution

*Change Process* Most changes (bug fixes and minor, commonsense feature adds) do not require review. Developers are encouraged to request review for: - Large changes affecting many files - Changes to interfaces - Changes that commit APR to one option out of an exclusive set - Any

Re: svn commit: r1833359 - in /apr/apr/trunk: CHANGES CMakeLists.txt build.conf build/crypto.m4 crypto/apr_crypto.c crypto/apr_crypto_prng.c include/apr.h.in include/apr_crypto.h test/testcrypto.c thr

On Tue, Jul 24, 2018 at 10:12 AM, Joe Orton wrote: > On Tue, Jul 24, 2018 at 02:25:57PM +0200, Yann Ylavic wrote: > > On Tue, Jul 24, 2018 at 11:43 AM, Graham Leggett > wrote: > > > Throughout APR we have a long established convention where > > > “expensive” libraries are bound to APR through

Re: svn commit: r1836519 - /apr/apr/trunk/strings/apr_strings.c

I'm concerned that you've made a specific assumption of 2's compliment int. Nothing in the spec or real world assures us of this. Intel x86 is 2's compliment, but this is a bad assumption. On Mon, Jul 23, 2018, 17:33 Yann Ylavic wrote: > On Tue, Jul 24, 2018 at 12:28 AM, wrote: > > > > @@

Re: Question on Unix Source for APR-util 1.6.1 and APR iconv 1.2.2

On Sat, Jun 30, 2018, 02:58 Rainer Jung wrote: > Am 29.06.2018 um 21:57 schrieb Duttera, Scott A CIV DISA SEL5 (US): > > We are attempting to compile Apache 2.4 on a Unix system here, and got > hit with prereqs by the compiler for the APR libraries. When we downloaded > the Unix Source for the

Re: svn commit: r1834513 - in /apr/apr/branches/1.6.x: STATUS file_io/win32/buffer.c

Any reason this is absent from development branch 1.7.x? I think all such 1.x-only issues should be started there. (Similarly with apr-util.) On Wed, Jun 27, 2018 at 10:21 AM, wrote: > Author: jfclere > Date: Wed Jun 27 15:21:19 2018 > New Revision: 1834513 > > URL:

Re: svn commit: r1833786 - /apr/apr/branches/1.6.x/STATUS

On Wed, Jun 20, 2018 at 1:50 AM, jean-frederic clere wrote: > On 19/06/18 11:02, Yann Ylavic wrote: > > Hi Jean-Frédéric, > > > > On Tue, Jun 19, 2018 at 10:01 AM, wrote: > >> Author: jfclere > >> Date: Tue Jun 19 08:01:45 2018 > >> New Revision: 1833786 > >> > >> URL:

Re: Linking with libapr-1.lib on MS Windows using MSVC 19

On Tue, Jun 19, 2018 at 9:17 AM, Oleg Sivokon wrote: > Hello list! > > Later, in Release directory I discovered libapr-1.lib which, as far as I > understand is analogous to an *.a file (archive), and is used by MSVC to > look up symbol definitions. > Note, it looks them up, but the code exists

Re: [RFC] apr_array_find()

On Sat, Apr 28, 2018 at 5:59 AM, Branko Čibej wrote: > On 27.04.2018 21:23, Greg Stein wrote: > > At one point, we used to use an svn_array_find() or some such. We > > deprecated it. Creating a function to do comparisons, then set up a > > function call... It was just annoying.

Re: [RFC] apr_array_find()

t;. Nobody had the time to submit and champion them. On Fri, Apr 27, 2018, 13:25 Jim Riggs <jim...@riggs.me> wrote: > > On 27 Apr 2018, at 11:50, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > > If we code this abstractly, comparator declaration is not

Re: [RFC] apr_array_find()

On Fri, Apr 27, 2018 at 11:44 AM, Jim Riggs wrote: > > On 27 Apr 2018, at 05:06, Branko Čibej wrote: > > > > On 27.04.2018 11:30, Nick Kew wrote: > >>> In my use cases, the search may often be strings, but not always, so I > thought that maybe APR could/should

Re:: svn commit: r1828369 - in /apr/apr/trunk: include/apr_reslist.h util-misc/apr_reslist.c

On Mon, Apr 16, 2018 at 6:22 AM, Ruediger Pluem wrote: > > On 04/16/2018 12:04 PM, Yann Ylavic wrote: >> On Mon, Apr 16, 2018 at 8:45 AM, Ruediger Pluem wrote: >>> >>> On 04/14/2018 02:32 AM, Yann Ylavic wrote: > > I think there are scenarios where LIFO is

Re: svn commit: r1828369 - in /apr/apr/trunk: include/apr_reslist.h util-misc/apr_reslist.c

On Thu, Apr 12, 2018 at 12:56 PM, Ruediger Pluem wrote: > > > Other options: > > 2. Reverse the order in the ring when apr_reslist_fifo_set is called. > > Of course both options require a lock. Here's an odd idea. What if the *traversal* were reversed based on the lifo bit,

Re: svn commit: r1820079 - in /apr/apr-iconv/trunk: NOTICE include/api_version.h libapriconv.rc

I think we can migrate to the current ASF header file policy, simplifying this a lot in future years. On Thu, Jan 4, 2018 at 6:44 AM, wrote: > Author: rjung > Date: Thu Jan 4 12:44:07 2018 > New Revision: 1820079 > > URL: http://svn.apache.org/viewvc?rev=1820079=rev > Log: >

Re: svn commit: r1828509 - in /apr/apr/trunk: CHANGES file_io/win32/readwrite.c test/testfile.c

Awesome! This looks entirely appropriate for 1.7 and even a 1.6.4 release, since the changes are all "under the hood". On Fri, Apr 6, 2018 at 6:26 AM, wrote: > Author: kotkov > Date: Fri Apr 6 11:26:47 2018 > New Revision: 1828509 > > URL:

Re: svn commit: r1828289 - in /apr/apr/trunk: CHANGES include/apr_reslist.h util-misc/apr_reslist.c

One question here; isn't it more efficient to offer push_resource_fifo() and push_resource_lifo() API's to the user, as opposed to extra conditionals? In theory, the consumer developer knows which ring they want. On Tue, Apr 3, 2018 at 5:00 PM, wrote: > Author: ylavic >

Re: svn commit: r1820755 - /apr/apr/trunk/misc/unix/rand.c

ource available for these platform, > and as Bill said, no API constraints... > > On Tue, Apr 3, 2018 at 9:22 PM, Eric Covener <cove...@gmail.com> wrote: >> I think that's right, the thing it's correcting is trunk-only (I >> checked 1.7 had no grep -ri arc4random_buf) >> >>

Re: svn commit: r1822357 - /apr/apr/trunk/memory/unix/apr_pools.c

Since these elts are runtime/internal-only, this seems like a worthwhile cleanup for 1.7/1.6? No API changes exposed. On Fri, Jan 26, 2018 at 4:00 PM, wrote: > Author: ylavic > Date: Fri Jan 26 22:00:17 2018 > New Revision: 1822357 > > URL:

Re: svn commit: r1820755 - /apr/apr/trunk/misc/unix/rand.c

Eric, Confirming; this is a trunk-only change? I don't see 1.7/1.6 commits. On Wed, Jan 10, 2018 at 8:53 AM, wrote: > Author: covener > Date: Wed Jan 10 14:53:43 2018 > New Revision: 1820755 > > URL: http://svn.apache.org/viewvc?rev=1820755=rev > Log: > fix ifdef for

Re: svn commit: r1827534 - /apr/apr/trunk/configure.in

Yann, Did you mean to hold off on any backport to 1.7/1.6? On Thu, Mar 22, 2018 at 5:46 PM, wrote: > Author: ylavic > Date: Thu Mar 22 22:46:30 2018 > New Revision: 1827534 > > URL: http://svn.apache.org/viewvc?rev=1827534=rev > Log: > configure: fix detection of net/if.h on

Re: apr trunk make test results on LFS

Redirecting this first set of questions to the APR project. Your LFS question is already answered. The apr-2.0 / apr-util 1.6 bug you describe means that apr_crypto_openssl.so and apr_crypto_nss.so modules were not built, or cannot be found in the test path, but were expected to be built. I add

Re: svn commit: r1825219 - /httpd/site/trunk/tools/release.sh

My approach has been to skim the http://www.apache.org/dist/apr/ tree for the version-sorted latest number. Your solution also seems sound. But we should mention to dev@apr that we are counting on these behaviors :) On Sat, Feb 24, 2018 at 5:43 AM, Daniel Ruggeri wrote: >

Re: Licensing claims (fnmatch)

ure this code’s lineage could be traced all the way back to when it > was BSD licensed. I say go ahead for my part. > > Ryan > > On Thu, Feb 22, 2018 at 3:36 AM Nick Kew <n...@apache.org> wrote: >> >> On Wed, 2018-02-21 at 11:30 -0600, William A Rowe Jr wrote: >

Licensing claims (fnmatch)

On Wed, Feb 21, 2018 at 10:27 AM, Stefan Sperling <s...@stsp.name> wrote: > On Tue, Feb 20, 2018 at 03:27:57PM -0600, William A Rowe Jr wrote: >> I ran into the same headache with my complete rewrite of >> the fnmatch.c logic of BSD that we ship in APR, and delivered >

Re: Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)

Is the sapi compiled against libtool etc. from httpd? Or is it using the configure logic shipped with the php package? In any case, asking httpd/apr to conform to the autoconf/libtool packaging of php, which was built using its own flavor of the toolchain seems inconsistent. It seems foolish to

Re: build dependencies of apr-util

On Thu, Dec 21, 2017 at 12:06 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Thu, Dec 21, 2017 at 9:19 AM, LONGO Matthieu > <matthieu.lo...@murex.com> wrote: >> Hello, >> >> I built APR 1.6.3 and APR-util 1.6.1 and noticed dependencies to f

Re: build dependencies of apr-util

On Thu, Dec 21, 2017 at 9:19 AM, LONGO Matthieu wrote: > Hello, > > I built APR 1.6.3 and APR-util 1.6.1 and noticed dependencies to files > located in APR's repository. > > buildconf: l.61 > # Remove some files, then copy them from apr source tree > rm -f

Re: -q64 flag - gets in the way

On Fri, Dec 8, 2017 at 5:49 AM, Branko Čibej <br...@apache.org> wrote: > On 08.12.2017 12:35, Joe Orton wrote: >> On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote: >>> They trust the compiler to do the right things, so there is no special >>> sauc

Re: -q64 flag - gets in the way

to individual distributors to solve as time went on. Good luck! Bill On Wed, Dec 6, 2017 at 8:01 AM, Michael <aixto...@felt.demon.nl> wrote: > On 04/12/2017 03:56, William A Rowe Jr wrote: > > On Dec 3, 2017 15:09, "Michael" <aixto...@felt.demon.nl> wrote: >

Re: -q64 flag - gets in the way

On Dec 3, 2017 15:09, "Michael" <aixto...@felt.demon.nl> wrote: On 17/11/2017 13:48, Michael Felt wrote: > > > On 11/13/2017 7:46 AM, William A Rowe Jr wrote: > >> So, when we prepare source packages, we are using vendor or raw autocruft >> packages...

Re: configure bug - openssl

Agreed. Seems we aren't correctly digging into pkgconfig or similar. On Nov 15, 2017 6:12 PM, "Rainer Jung" wrote: Am 15.11.2017 um 22:02 schrieb Helmut K. C. Tessarek: > On 2017-11-15 03:53, Rainer Jung wrote: > >> Could you please provide the config.log that you get

Re: configure bug - openssl

no sense. You might obtain more help by starting with a description of your OS and installed system packages vis a vie OpenSSL an so on. None of us enjoy guessing games. On Nov 14, 2017 2:42 PM, "Helmut K. C. Tessarek" <tessa...@evermeet.cx> wrote: > On 2017-11-14 10:55, Will

<    1   2   3   4   5   6   7   8   9   10   >