Re: Remaining breakage on apr-1.7.x branch

On Tue, Sep 13, 2022 at 12:21 PM Ivan Zhakov wrote: > > Btw I've recently backported several fixes to 1.7.x branch: > [[[ > *) Fix attempt to free invalid memory on exit when apr_app is used > on Windows. [Ivan Zhakov] > *) Fix double free on exit when apr_app is used on Windows. [Ivan

Re: Remaining breakage on apr-1.7.x branch

different syntaxes to get there. Any final thoughts before we simply release 1.7 branch as-is? Bill On Wed, Sep 7, 2022 at 11:06 AM Eric Covener wrote: > > On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr > wrote: > > > > Hello friends and collaborators, > > &

Re: Remaining breakage on apr-1.7.x branch

The links below didn't resolve as I expected them to, pay specific attention to include/apr_ring.h delta between 1.7.0 tag and 1.7.x branch. I'll continue to try to coax github to make an appropriate representation by following a link. On Thu, Jul 28, 2022 at 11:58 AM William A Rowe Jr

Remaining breakage on apr-1.7.x branch

Hello friends and collaborators, I'm still rather certain this change is ABI and API contract-breaking on the apr-1.7.x branch, which holds the project hostage for providing a well-understood security fix on the legacy branch. Such things can't persist, our individual maintenance branches must

Re: svn commit: r1895528 - /apr/apr/trunk/CMakeLists.txt

Hi Mladen, you tweaked this, and failed to update build/find_apr.m4, so this broke CMake builds of httpd against APR. httpd simply borrows what apr provides, so it isn't on that project. Are you able to update the find macro appropriately so it functions to discover the true path of apr, or

Re: svn commit: r1896510 - in /apr/apr/branches/1.7.x: ./ file_io/win32/ include/arch/unix/ include/arch/win32/ network_io/os2/ poll/os2/ poll/unix/

The answer to your question is whether a consumer who built against apr<1.7.0 is going to blow up, whether they borrowed "private" API's or not. If they were exported, it's effectively public. Or, whether a consumer built against 1.7.1 would blow up against 1.7.0 - if that's true, we need to

Re: svn commit: r1897209 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

Do we agree you can't change the API, whether it is ABI compatible or not? Or was there a follow-up commit I missed? On Mon, Jan 24, 2022 at 11:20 AM William A Rowe Jr wrote: > > On Thu, Jan 20, 2022 at 9:38 AM Yann Ylavic wrote: > > > > On Thu, Jan 20, 2022 at 3:56 PM

Re: svn commit: r1897222 - in /apr/apr/branches/1.7.x: ./ file_io/win32/ include/arch/unix/ include/arch/win32/ network_io/os2/ poll/os2/ poll/unix/

This might be the most concerning break between apr 1.7.0 and 1.7.1, and hope it was also evaluated for suitability for 1.8.0, because that must remain binary compatible. The fact that these are all prefaced apr_XXX and not apr__XXX doesn't give me a lot of reassurance that someone isn't

Re: svn commit: r1897210 - in /apr/apr/branches/1.7.x: ./ memory/unix/apr_pools.c threadproc/beos/thread.c threadproc/netware/thread.c threadproc/os2/thread.c threadproc/unix/thread.c threadproc/win32

I presume this is covered under our prior conversation about adding API's to a subrevision, and is resolved? On Wed, Jan 19, 2022 at 11:06 AM wrote: > > Author: ylavic > Date: Wed Jan 19 17:06:36 2022 > New Revision: 1897210 > > URL: http://svn.apache.org/viewvc?rev=1897210=rev > Log: >

Re: svn commit: r1896748 - in /apr/apr/branches/1.7.x: ./ include/apr_ring.h

This commit especially troubles me, w.r.t. semver rules for 1.7.0 -> 1.7.1, since it actually changes the behavior for the rest of 1.x, and compatibility with previous 1.x releases. If we know that this code executes correctly compiled under 1.7.1/1.8.0 against a 1.7.0 libapr.so, then it's fine.

Re: svn commit: r1890230 - in /apr/apr/branches/1.7.x: CHANGES include/arch/win32/apr_arch_misc.h misc/win32/misc.c network_io/win32/sockets.c

This is another "breaking" change. However, whatever enum values are used, it should always be as a comparison operator, and this is an internal value. It would prove unreliable if someone looked for Windows 10+ and looked against apr-1.7.0.dll, but that just means a feature available isn't

Re: svn commit: r1884103 - in /apr/apr/branches/1.7.x: ./ include/arch/beos/ include/arch/netware/ include/arch/unix/ include/arch/win32/ memory/unix/ threadproc/beos/ threadproc/netware/ threadproc/o

Hopefully we aren't waiting any longer for 1.8.0 than 1.7.1, so that shouldn't be a real risk On Thu, Jun 30, 2022 at 7:02 AM Yann Ylavic wrote: > > On Wed, Jun 29, 2022 at 6:09 PM Yann Ylavic wrote: > > > > By making such impracticable policies for revision changes (semver > > sense), we are

Re: svn commit: r1887497 - in /apr/apr/branches/1.7.x: ./ CHANGES mmap/unix/mmap.c test/data/mmap_large_datafile.txt test/testfnmatch.c test/testmmap.c

dn't shock anyone who doesn't explicitly ask for -lapr against libapr.so.1.7 On Thu, Jun 30, 2022 at 7:39 AM Yann Ylavic wrote: > > On Wed, Jun 29, 2022 at 4:49 PM William A Rowe Jr wrote: > > > > The eventual change still is present for apr > > 1.8 adopters. > &

Re: svn commit: r1887497 - in /apr/apr/branches/1.7.x: ./ CHANGES mmap/unix/mmap.c test/data/mmap_large_datafile.txt test/testfnmatch.c test/testmmap.c

This change does introduce an API change, and a somewhat possibly dangerous structure size alteration, and seems to be out of bounds for apr 1.7.x branch, as identified in the commit message. Anyone using a build crossing runtimes between apr 1.7.0 and 1.7.1 may experience unintended

Re: svn commit: r1884103 - in /apr/apr/branches/1.7.x: ./ include/arch/beos/ include/arch/netware/ include/arch/unix/ include/arch/win32/ memory/unix/ threadproc/beos/ threadproc/netware/ threadproc/o

This change does introduce an API change, and a somewhat possibly dangerous structure size alteration, and seems to be out of bounds for apr 1.7.x branch. Anyone using a build crossing runtimes between apr 1.7.0 and 1.7.1 may experience unintended side-effects. The eventual change still is

Re: svn commit: r1863234 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

This is the first commit which appeared to break APR in such a way that code compiled against apr 1.7.1 would be unable to run against apr 1.7.0 binaries. Thoughts, rjung? Are you willing to revert? This would persist on apr 1.8.x for those interested in this new feature. On Wed, Jul 17, 2019 at

Re: Build errors in branches/1.8.x on Windows

Not sure what you have going on here. A too-old flavor of the Windows SDK, or a bad choice of the minimum SDK version? It seems the HAVE_IF_INDEXTONAME is set in the include/arch/win32/apr_private.h, which is included by include/arch/win32/apr_arch_misc.h, which then does this; #if

Re: Need APR and APR-Util signing keys

https://downloads.apache.org/apr/KEYS On Wed, Feb 2, 2022 at 4:37 PM Becky Flarity wrote: > > Looking for GPG public signature keys for APR and APR-Util. (See below) > > Don’t see them on https://people.apache.org/keys/committer. > > Where is a trusted source for obtaining these keys? > > gpg

Re: svn commit: r1897209 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

On Thu, Jan 20, 2022 at 9:38 AM Yann Ylavic wrote: > > On Thu, Jan 20, 2022 at 3:56 PM William A Rowe Jr wrote: > > > > On Thu, Jan 20, 2022 at 8:50 AM Eric Covener wrote: > > > > > > > Code that will compile on 1.7.1 release > > > > s

Re: svn commit: r1895508 - in /apr/apr/trunk: dso/win32/ file_io/win32/ locks/win32/ misc/unix/ misc/win32/ network_io/unix/ network_io/win32/ passwd/ shmem/win32/ threadproc/win32/ time/win32/ user/w

On Thu, Jan 20, 2022 at 12:49 PM Ivan Zhakov wrote: > > On Thu, 20 Jan 2022 at 00:43, William A Rowe Jr wrote: >> >> On Wed, Jan 19, 2022 at 11:31 AM Yann Ylavic wrote: >> > >> > I'm a bit surprised that _WIN32_WCE used CreateThread() while more >> >

Re: svn commit: r1897209 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

On Thu, Jan 20, 2022 at 12:32 PM William A Rowe Jr wrote: > > On Thu, Jan 20, 2022 at 9:44 AM Yann Ylavic wrote: > > > > My bad, re-reading the thread the proposal was a compat apu_ -> apr_ > > layer in APR *util* 1.7.x, yet since apr-util 1.7.0 is released > >

Re: svn commit: r1897209 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

On Thu, Jan 20, 2022 at 9:44 AM Yann Ylavic wrote: > > > My bad, re-reading the thread the proposal was a compat apu_ -> apr_ > layer in APR *util* 1.7.x, yet since apr-util 1.7.0 is released > already it would be the same kind of compat issue. No worries. The larger question is about whether to

Re: svn commit: r1897209 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

On Thu, Jan 20, 2022 at 8:50 AM Eric Covener wrote: > > > Code that will compile on 1.7.1 release > > still won't compile on 1.7.0, unless I misunderstand something. > > Is it a requirement in this direction? > https://apr.apache.org/versioning.html says "later versions" That's why I raise the

Re: svn commit: r1897209 - in /apr/apr/branches/1.7.x: ./ include/apr_pools.h memory/unix/apr_pools.c

I agree this ticks the ABI compatibility box. I doesn't check the API compatibility box, IMO. Code that will compile on 1.7.1 release still won't compile on 1.7.0, unless I misunderstand something. I'd really like us to start on the 1.7 releases today, but I'd have to vote against this

Re: svn commit: r1895508 - in /apr/apr/trunk: dso/win32/ file_io/win32/ locks/win32/ misc/unix/ misc/win32/ network_io/unix/ network_io/win32/ passwd/ shmem/win32/ threadproc/win32/ time/win32/ user/w

On Wed, Jan 19, 2022 at 11:31 AM Yann Ylavic wrote: > > I'm a bit surprised that _WIN32_WCE used CreateThread() while more > recent ones use _beginthreadex(), shouldn't it be the opposite? > CreateThread() aligns more with the usual/modern naming convention on > Windows.. Ignore naming

Re: apr/trunk netware and os2

And RS2000? On Mon, Jan 17, 2022 at 7:15 PM Yann Ylavic wrote: > > On Tue, Jan 18, 2022 at 2:08 AM Yann Ylavic wrote: > > > > On Tue, Nov 30, 2021 at 11:46 PM Mladen Turk wrote: > > > > > > According to Wikipedia NetWare was discontinued in 2009 > > > and OS/2 in 2001, so if anyone can explain

Re: Get rid of APU api in favor of APR for apr/turk

On Sun, Jan 16, 2022 at 11:08 PM Greg Stein wrote: > > On Sun, Jan 16, 2022 at 11:02 PM William A Rowe Jr > wrote: >> >> People will need to change their code to apr-2.x. But in the interim, >> apr-util 1.7.0 >> aught to have a compat layer to let authors adopt

Re: Get rid of APU api in favor of APR for apr/turk

On Sun, Jan 16, 2022 at 10:46 PM Greg Stein wrote: > > On Sun, Jan 16, 2022 at 3:38 PM William A Rowe Jr wrote: >> >> On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk wrote: >> > On 08/12/2021 08:33, Ruediger Pluem wrote: >> > > I assumed this as a trunk/2.

Re: apr/trunk Minimum version is Windows 10!?

On Wed, Dec 1, 2021 at 2:55 PM Mladen Turk wrote: > > My proposal is to use 0x0603 (aka windows 8.1, windows server 2012r2) > Those are still supported until 2023 -1. Again, that simply limits us to never pick up "modern" tcp/ip symbol names from windows sdk headers. It doesn't prevent us from

Re: svn commit: r1895541 - /apr/apr/trunk/CMakeLists.txt

On Fri, Dec 3, 2021 at 5:39 AM Mladen Turk wrote: > > On 03/12/2021 12:35, Yann Ylavic wrote: > > After all those CMakeLists changes, is building with cmake now > > dedicated to Windows or does/can it work on *nixes too? > > I never tried building with cmake so far on *nix, so just wondering.. >

Re: Adding support for Windows/arm64

Mladen, Sounds awesome, I think although some people do build from .mak or .dep files, cmake is the project's entire solution. I'm happy to help and review your work, if you are looking for feedback, and it should be landed on apr 1.8 as well as trunk if you can do that. Cheers, Bill On Tue,

Re: Get rid of APU api in favor of APR for apr/turk

On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk wrote: > > On 08/12/2021 08:33, Ruediger Pluem wrote: > > I assumed this as a trunk/2.0 only proposal. Is my assumption wrong? > > > > Yes, trunk only. > Just a simple copy/paste leftover cleanup, mostly for internals Within that scope, yes, make it

Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/

On Sat, Jan 15, 2022 at 4:37 AM Yann Ylavic wrote: > > On Sat, Jan 15, 2022 at 2:00 AM William A Rowe Jr wrote: > > > At this point I question the relevance of releasing 1.7.1 at all, I > think most people will be interested in 1.8.0 and I'd advise distros > to upg

Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/

On Fri, Jan 14, 2022 at 5:07 AM Yann Ylavic wrote: > > On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr wrote: > > > > A quick review of nm against libapr-1.so between 1.7.0 and 1.7.x > > indicates that 1.7.1 > > isn't releasable as-is. Any hints? > > >

Re: Possible apr 1.7.1 showstopper from httpd test framework

On Fri, Jan 14, 2022 at 5:44 AM Joe Orton wrote: > > On Fri, Jan 14, 2022 at 11:37:35AM +0100, Ruediger Pluem wrote: > > > > On 1/14/22 6:47 AM, William A Rowe Jr wrote: > > > In addition to a broken release of brotli (where enc/dec don't specify > > >

Re: svn commit: r1896724 - /apr/apr/trunk/file_io/win32/filestat.c

Reviewing, and writing tests. Thanks for your analysis! On Wed, Jan 5, 2022 at 11:45 AM wrote: > > Author: ivan > Date: Wed Jan 5 17:45:33 2022 > New Revision: 1896724 > > URL: http://svn.apache.org/viewvc?rev=1896724=rev > Log: > Win32: Minor optimization of apr_stat() and apr_file_info_get().

Re: Minimum msvc version to compile apr/trunk on Windows

On Thu, Dec 2, 2021 at 1:33 PM Mladen Turk wrote: > > On 02/12/2021 13:21, Ivan Zhakov wrote: > > On Wed, 1 Dec 2021 at 21:26, Mladen Turk > > wrote: > > > > So no uuidof used in recent Windows SDK. > > > > Btw Visual Studio 2008 support ended April 10, 2018 [1]. > >

Re: Minimum msvc version to compile apr/trunk on Windows

On Fri, Dec 10, 2021 at 8:47 AM Ivan Zhakov wrote: > > On Thu, 2 Dec 2021 at 22:33, Mladen Turk wrote: >> >> Issues with API beyond Windows SDK 7.1.A >> (Latest one supporting Windows 7.1sp1) >> >> It just means apr-2 won't be able to run on anything below Windows 10. >> There a lots of code you

Re: svn commit: r1896510 - in /apr/apr/branches/1.7.x: ./ file_io/win32/ include/arch/unix/ include/arch/win32/ network_io/os2/ poll/os2/ poll/unix/

On Thu, Jan 13, 2022 at 2:37 PM Ruediger Pluem wrote: > > On 1/13/22 7:04 PM, Ivan Zhakov wrote: > > > > On Fri, 7 Jan 2022 at 17:33, Yann Ylavic wrote: > >> > >> On Fri, Jan 7, 2022 at 2:50 PM Ivan Zhakov wrote: > >>> > >>> I also have a high-level objection against backporting this change to

Possible apr 1.7.1 showstopper from httpd test framework

In addition to a broken release of brotli (where enc/dec don't specify -lbrotlicommon, even on trunk, for openssl and other consumers to ferret out that binding), and lots of fun changes to build flags in curl 7.81 minor release (who does that?) there appears to be one test failure with date

Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/

A quick review of nm against libapr-1.so between 1.7.0 and 1.7.x indicates that 1.7.1 isn't releasable as-is. Any hints? +T apr_pool_find +T apr_pool_join +T apr_pool_lock +T apr_pool_num_bytes +T apr__pool_unmanage Preserving whatever has changed on 1.8.x branch for ABI breaking changes. On

Backport svn log style request

We have traditionally described a commit even when performing a backport. I'd traditionally cut and pasted the actual log entries and then compressed them some to ignore the trivial stuff that doesn't particularly apply to the combined patch. Then decorated with the usual; Authored by:

Re: apr/trunk netware and os2

On Tue, Nov 30, 2021 at 4:47 PM Mladen Turk wrote: > > BTW did anyone was able to compile trunk on netware or os2 > There are bunch of those NWGNUmakefiles and netware subdirs My +1 to drop both from trunk. > According to Wikipedia NetWare was discontinued in 2009 > and OS/2 in 2001, so if

Re: svn:ignore a few more paths to help TortoiseSVN's build system

While I'm a cmake user, there's no reason not to exclude these directories, they are clearly not in our hierarchy. On Wed, Jul 21, 2021 at 8:07 AM Eric Covener wrote: > > Seems reasonable to me even on the release branches, will let it stew > a bit here. > > On Wed, Jul 21, 2021 at 8:18 AM

Re: apr-util-1.7.0 initial release, or 1.6.x incremental release (or both)?

ieb Yann Ylavic: > > On Fri, Sep 17, 2021 at 9:53 PM William A Rowe Jr > > wrote: > >> > >> We have much activity on apr-util-1.7.0 but no release actions for > >> some time now. > >> There are very minor changes to 1.6.x branch. > >> > &

apr-util-1.7.0 initial release, or 1.6.x incremental release (or both)?

We have much activity on apr-util-1.7.0 but no release actions for some time now. There are very minor changes to 1.6.x branch. Do we want to release 1.7.0, or only a 1.6.x bump? Or do we want to do both? Are we ready and are the API changes considered? All observations and feedback on apr-util

Re: APR trunk testcrypto crash with OpenSSL 1.0.2

Did we determine this does not affect apr-util-1.7.x nor apr-util-1.6.x branches?

Re: CVE-2021-35940: Apache Portable Runtime (APR): Regression of CVE-2017-12613

Note the fix referenced below will be picked up in APR 1.7.1 On Mon, Aug 23, 2021 at 5:25 AM Joe Orton wrote: > > Description: > > An out-of-bounds array read in the apr_time_exp*() functions was fixed > in the Apache Portable Runtime 1.6.3 release (CVE-2017-12613). The fix > for this issue was

Re: APR 1.7.1 release?

On Fri, Sep 10, 2021 at 3:34 AM Ruediger Pluem wrote: > > On 9/10/21 10:28 AM, Steffen Land wrote: > > Please be sure that the following two are included in 1.7.1 : > > > > PR 63491 regression in 1.7, see > > https://www.apachelounge.com/viewtopic.php?p=39558 > > r1882155 brought this already to

Re: APR 1.7.1 release?

, and further solve the apr 1.6.0 original and 1.7.1 release quirks with mount symlinks. Bill On Thu, Sep 2, 2021 at 8:44 PM William A Rowe Jr wrote: > > I'm willing to RM APR and APR-util 1.7 releases. > > Would propose we set a date out 2 weeks, anything lingering needs > to be finalized

Re: APR 1.7.1 release?

I'm willing to RM APR and APR-util 1.7 releases. Would propose we set a date out 2 weeks, anything lingering needs to be finalized with the usual oversight no later than the 8th, and we tag on the 14th, announce on the 15th when the mirrors have caught up. That gives enough days for committers to

Re: Subversion reports status fault on substituted drive

Corveleyn wrote: > On Fri, Nov 27, 2020 at 10:30 AM Johan Corveleyn > wrote: > > > > On Fri, Nov 27, 2020 at 2:26 AM William A Rowe Jr > wrote: > > > > > > On Thu, Nov 26, 2020 at 3:35 PM Nick Kew wrote: > > >> > > >>

Re: Subversion reports status fault on substituted drive

On Thu, Nov 26, 2020 at 3:35 PM Nick Kew wrote: > > > On 24 Nov 2020, at 18:51, William A Rowe Jr wrote: > > > > Yes, I'm on it. 1.6.x and prior somewhat works. 1.7.0 does not, asking > > for apr_stat of a root drive. Seeing the request yesterday for a new > re

Re: Subversion reports status fault on substituted drive

. That's particularly important to the subversion developers. On Tue, Nov 24, 2020 at 4:37 AM Johan Corveleyn wrote: > On Fri, Jun 12, 2020 at 3:13 PM Johan Corveleyn wrote: > > > > On Sun, May 17, 2020 at 12:22 AM William A Rowe Jr > wrote: > > > > > > This in

Re: svn commit: r1881476 - /apr/apr/trunk/include/arch/win32/apr_arch_utf8.h

On Tue, Sep 8, 2020 at 4:11 AM Ivan Zhakov wrote: > On Sat, 5 Sep 2020 at 08:15, wrote: > >> Author: wrowe >> Date: Sat Sep 5 05:15:52 2020 >> New Revision: 1881476 >> >> URL: http://svn.apache.org/viewvc?rev=1881476=rev >> /** >> + * @deprecated @see apr_conv_utf8_to_utf16 >> + */ >>

Re: Subversion reports status fault on substituted drive

of detail! Bill On Thu, Apr 23, 2020 at 7:00 PM Johan Corveleyn wrote: > On Wed, Apr 15, 2020 at 4:48 PM Johan Corveleyn wrote: > > > > On Wed, Apr 15, 2020 at 3:51 PM William A Rowe Jr > wrote: > > > > > > Interesting. > > > > > > Not being

Re: apr-2 ... cleanup

On Wed, May 13, 2020, 15:08 Gregg Smith wrote: > > #1, I think this may be your opinion but not so much mine. No, .mak/defs > are not in trunk but they never have been and they have been added at > fork to currently all the 1.0 series. And unless I'm mistaken, 1.7 was > not that long ago. >

Re: apr-2 ... cleanup

I guess I'm very confused. All modern flavors of Visual Studio *ship* cmake and ninja. The CMake config lets us toggle options, things that static build files can't do well. CMake will emit nmake, or ninja, or vcproj/sln. And as noted elsethread, it should be able to build for Linux as easily as

Re: apr-2 ... cleanup

On Wed, May 13, 2020 at 3:41 AM Mladen Turk wrote: > Hi, > > Related mostly to Windows port > > 1. Remove all those .dsp, .dsw .mak files from APR trunk > None of them works for years. > Replace all that with cmake > 2. Remove all _WIN32_WCE, APR_NOT_IN_WCE > Just a bunch of code for

Re: Subversion reports status fault on substituted drive

On Fri, May 8, 2020 at 4:50 AM Johan Corveleyn wrote: > On Fri, Apr 24, 2020 at 1:59 AM Johan Corveleyn wrote: > > > > On Wed, Apr 15, 2020 at 4:48 PM Johan Corveleyn > wrote: > > > > > > On Wed, Apr 15, 2020 at 3:51 PM William A Rowe Jr

Re: Subversion reports status fault on substituted drive

ote: > > > > On Fri, Apr 10, 2020 at 3:45 PM William A Rowe Jr > wrote: > > > On Thu, Apr 9, 2020 at 2:48 PM Johan Corveleyn > wrote: > > >> On Thu, Apr 9, 2020 at 6:31 PM William A Rowe Jr > wrote: > > >> > > > >> > Tha

Re: Subversion reports status fault on substituted drive

On Thu, Apr 9, 2020 at 2:48 PM Johan Corveleyn wrote: > On Thu, Apr 9, 2020 at 6:31 PM William A Rowe Jr > wrote: > > > > That's very likely, and this can be researched further to dig up exactly > how > > subst is handled. (As you mention, it hasn't been comm

Re: Subversion reports status fault on substituted drive

to dig deeper today, but just wanted to leave an update that something interesting is going to have to happen here to delve into the "root device" vs a simple "root directory".. On Thu, Apr 9, 2020 at 11:31 AM William A Rowe Jr wrote: > On Thu, Apr 9, 2020 at 8:01 AM

Re: Subversion reports status fault on substituted drive

On Thu, Apr 9, 2020 at 8:01 AM Johan Corveleyn wrote: > On Thu, Apr 9, 2020 at 1:20 PM Nick Kew wrote: > > > > > > The below report about a problem with Subversion working on 'subst'ed > > > drives (Windows), seemed to be related to a change in APR 1.7.0 > > > (https://svn.apache.org/r1855950),

Re: svn commit: r1872893 - /apr/apr/trunk/file_io/win32/filestat.c

So this is an open question... Is this backportable as a bug fix? Both are errors as the reference to a specific file, but only one condition represents a fatal error for a grep operation. Should we wait for 1.8 or is this worth 'adjusting' in 1.7.1 asap? I already have conflicting thoughts so

Re: svn commit: r1871082 - in /apr/apr/trunk: include/arch/win32/apr_arch_misc.h misc/win32/misc.c misc/win32/start.c

Awesome :) Thanks! On Mon, Dec 9, 2019, 04:22 wrote: > Author: ivan > Date: Mon Dec 9 10:22:08 2019 > New Revision: 1871082 > > URL: http://svn.apache.org/viewvc?rev=1871082=rev > Log: > win32: Try to avoid loading shell32.dll whenever possible: > 1. shell32.dll has about 19 dependencies. >

Re: svn commit: r1868502 - /apr/apr/trunk/atomic/win32/apr_atomic64.c

On Fri, Nov 1, 2019 at 1:45 AM Ivan Zhakov wrote: > On Wed, 30 Oct 2019 at 13:18, Yann Ylavic wrote: > > > > On Wed, Oct 30, 2019 at 4:37 AM William A Rowe Jr > wrote: > > > > > > On Wed, Oct 16, 2019 at 5:11 AM wrote: > > >> > >

Re: svn commit: r1868502 - /apr/apr/trunk/atomic/win32/apr_atomic64.c

On Wed, Oct 16, 2019 at 5:11 AM wrote: > Author: ivan > Date: Wed Oct 16 10:10:59 2019 > New Revision: 1868502 > > URL: http://svn.apache.org/viewvc?rev=1868502=rev > Log: > * atomic/win32/apr_atomic64.c > (apr_atomic_read64): Use direct memory read when compiled for x86_x64, > since >

Re: apr_stat() sometimes returning APR_INCOMPLETE (70008) on Windows 10

Looking at the Apache Perl dev@ traffic, this is obviously popping up more and more often. It is no longer just a virus scanner issue, but a restriction to some common WinNT security models in terms of inspecting file permissions. While modules should just be asking for APR_FSTAT_MIN scope most

Re: Proposal: apr-tools project

On Thu, Jul 25, 2019 at 8:26 AM Graham Leggett wrote: > On 25 Jul 2019, at 14:26, Nick Kew wrote: > > > Would that be purely in C, or could it be a mix, perhaps including > scripting languages? > > Purely in C. > > Exposing APR to other languages through something like swig also sounds >

Resolutions to APR_POOL_DEBUGging headaches?

I'm sorry I haven't had the summertime cycles to dig into this, but am wondering on the cusp of an httpd 2.4.40, we've learned a bunch about possible apr pool and especially debug traps that meta What code remains to be considered for inclusion in an apr 1.7.1? What is apr 1.8 waiting for, if we

Re: apr_pool_join() and APR_POOL_DEBUG

On Tue, Jul 16, 2019, 23:54 Rainer Jung wrote: > Am 17.07.2019 um 01:30 schrieb Branko Čibej: > > On 16.07.2019 23:18, Rainer Jung wrote: > >> I had some need for using APR_POOL_DEBUG today and ran into a > >> situation where pool lifetimes needed a hint using apr_pool_join(). > >> That is all

Re: apr_stat() sometimes returning APR_INCOMPLETE (70008) on Windows 10

On Tue, Jul 16, 2019 at 8:10 AM Steve Hay wrote: > I'm in the process of preparing a new mod_perl release and have run > into a few test failures on Windows 10 which are caused by apr_stat() > sometimes returning APR_INCOMPLETE (70008). > > I'm only getting this on Windows 10. If I run the same

Re: The case for apr-util-2.0

On Thu, Jun 6, 2019 at 4:15 AM Graham Leggett wrote: > On 06 Jun 2019, at 10:38, Branko Čibej wrote: > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 18.04.2 LTS > Release: 18.04 > Codename: bionic > $ apt-cache search aprutil > libaprutil1 -

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

On Tue, Jun 11, 2019 at 5:38 PM William A Rowe Jr wrote: > On Tue, Jun 11, 2019 at 1:44 PM Branko Čibej wrote: > >> We either reserve about 2x buffers for file name transliteration in heap >> per thread, or we use the thread stack. As long as we trust that our utf-8 >>

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

On Tue, Jun 11, 2019 at 1:44 PM Branko Čibej wrote: > We either reserve about 2x buffers for file name transliteration in heap > per thread, or we use the thread stack. As long as we trust that our utf-8 > to ucs-2 logic is rock solid and the allocations and limits are correctly > coded, this

Re: svn commit: r1860980 - /apr/apr/trunk/build/crypto.m4

I'm totally confused, these libs have been installed across three paths? If not, isn't that an autoconf task to link to the one and only one preferred target on rebuilds, in spite of later package adds? On Mon, Jun 10, 2019 at 3:47 PM wrote: > Author: minfrin > Date: Mon Jun 10 20:47:36 2019

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

On Tue, Jun 11, 2019 at 9:14 AM William A Rowe Jr wrote: > On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote: > >> On 07.06.2019 21:58, William A Rowe Jr wrote: >> > I think the optimal way is to allocate a pair of apr thread-specific >> > wchar buffers in

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote: > On 07.06.2019 21:58, William A Rowe Jr wrote: > > I think the optimal way is to allocate a pair of apr thread-specific > > wchar buffers in each thread's pool on startup, and use those > > exclusively per-thread for w

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

I think the optimal way is to allocate a pair of apr thread-specific wchar buffers in each thread's pool on startup, and use those exclusively per-thread for wchar translations. We could be looking at 64k/thread exclusively for name translation, but it doesn't seem unreasonable. The alternative

Website refresh

I've updated the mail-archive links, and updated all that I could to prefer https://. There are still likely dead https:// links that I didn't review at all. A second pair of eyes through the current contents of https://apr.apache.org/ would be helpful.

[results] [vote] Win32 Decision Point

paths in these coming weeks. On Wed, Apr 24, 2019 at 2:31 PM William A Rowe Jr wrote: > Some 17 years later we are at a crossroads, because the win32 code > is somewhat illegible and harder to maintain due to the ANSI-vs-UTF8, > Win9x-vs-NT code paths. > > NT won. The only remaining

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows)

On Tue, May 21, 2019 at 2:32 PM Ivan Zhakov wrote: > > > > More specifically, I would like to: > > > > 1. Use native Slim Reader/Writer (SRW) locks [1] for apr_rwlock. > > > >Windows SRW locks are extremely performant (100x times) and also the > >current APR implementation has known bugs

Re: svn commit: r1859658 - /apr/site/trunk/doap.rdf

On Tue, May 21, 2019 at 11:01 AM wrote: > Author: wrowe > Date: Tue May 21 16:00:46 2019 > New Revision: 1859658 > > URL: http://svn.apache.org/viewvc?rev=1859658=rev > Log: > s/http:/https:/ - note that usefulinc.com is not so useful, cert CN > mismatch > > --- apr/site/trunk/doap.rdf

Re: unsubscribe

I trust you remembered to email bugs-unsubscribe@apr.a.o, and this is all fixed? On Thu, May 2, 2019 at 12:27 PM Ryan Bloom wrote: > > Ryan Bloom > rbl...@gmail.com >

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows)

On Wed, May 15, 2019 at 7:39 AM Eric Covener wrote: > > I would like to propose making Windows 7 / Windows Server 2008 R2 the > minimum > > supported Windows version for APR 2.0. > > > > This means that for APR 2.0 we would drop the support for Windows Vista > and > > Windows Server 2008 (not

Re: [vote] Win32 Decision Point

On Thu, Apr 25, 2019 at 2:59 AM Ivan Zhakov wrote: > [X] Please drop 8-bit and focus only on utf-8 resource names on Win32. > > The only problem I see that it would harder to backport fixes to > stable branches. What about release apr 1.8 without ANSI logic? > That isn't possible by my reading

[vote] Win32 Decision Point

Some 17 years later we are at a crossroads, because the win32 code is somewhat illegible and harder to maintain due to the ANSI-vs-UTF8, Win9x-vs-NT code paths. NT won. The only remaining question is how many apr consumers are leveraging ANSI-specific builds for local code page semantics, vs how

Re: apr 1.7.0 configure fails on macOS with Xcode 10.2.1 SDK MacOSX10.14.sdk

Hi Barry, you are looking at the latest consensus code spanning BSD and OS/X in two variants. It would help us if you would share your config.log and entire output of ./configure along with cc -version type data for the applicable compiler. On Wed, Apr 24, 2019 at 1:04 PM Barry Scott wrote:

Re: [Announce] Apache Portable Runtime APR 1.7.0 Released

On Sat, Apr 6, 2019 at 12:33 PM Dennis Clarke wrote: > On 4/6/19 10:47 AM, William A Rowe Jr wrote: > > On Fri, Apr 5, 2019 at 4:03 PM Nick Kew > <mailto:n...@apache.org>> wrote: > > > > > > > On 5 Apr 2019, at 19:53, William A Rowe

Re: [Announce] Apache Portable Runtime APR 1.7.0 Released

On Fri, Apr 5, 2019 at 4:03 PM Nick Kew wrote: > > > On 5 Apr 2019, at 19:53, William A Rowe Jr wrote: > > > >Apache Portable Runtime APR 1.7.0 Released > > > >The Apache Software Foundation and the Apache Portable Runtime > >Project are pro

[Announce] Apache Portable Runtime APR 1.7.0 Released

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

Re: [result] [vote] Release apr-1.7.0 ?

Yes, please consult with Rainer, there are still hours to pull back and rework a 1.7.1 launch. Thanks for the very complete details. Please crosscheck if you are each speaking of opteron or sparc flavors. On Thu, Apr 4, 2019 at 1:32 PM Dennis Clarke wrote: > On 4/4/19 2:10 PM, William A R

[result] [vote] Release apr-1.7.0 ?

ill On Mon, Apr 1, 2019 at 1:01 PM William A Rowe Jr wrote: > Candidate tarballs are at the usual location; > https://apr.apache.org/dev/dist/ > > For the release of apr-1.7.0 > [ ] +1 looks great! > [ ] -1 something is broken > > This vote will conclude April

tarball.sha256 file formatting (Was Re: [VOTE] apr-1.6.4 release?)

On Mon, Sep 10, 2018 at 3:34 PM Rainer Jung wrote: > Am 07.09.2018 um 18:19 schrieb William A Rowe Jr: > > Please cast your votes on the following release candidate > > found at http://apr.apache.org/dev/dist/ > > > > Release apr-1.6.4 > >[ ] +/-1 > >

[vote] Release apr-1.7.0 ?

Candidate tarballs are at the usual location; https://apr.apache.org/dev/dist/ For the release of apr-1.7.0 [ ] +1 looks great! [ ] -1 something is broken This vote will conclude April 4th 2pm EDT, for potential announcement Friday. I could use a hand from Netware folk to explain the

Re: svn commit: r1856274 - in /apr/apr/branches/1.7.x: ./ configure.in file_io/unix/dir.c

I'm happy to do that, and to preserve your dir.c fix. Commit coming up, crossing fingers for a clean Linux maintainer compilation. On Sun, Mar 31, 2019, 11:44 Yann Ylavic wrote: > On Sun, Mar 31, 2019 at 5:29 PM William A Rowe Jr > wrote: > > > > On Sun, Mar 31, 2019,

Re: svn commit: r1856274 - in /apr/apr/branches/1.7.x: ./ configure.in file_io/unix/dir.c

On Tue, Mar 26, 2019 at 3:35 AM wrote: > Author: ylavic > Date: Tue Mar 26 08:35:35 2019 > New Revision: 1856274 > > URL: http://svn.apache.org/viewvc?rev=1856274=rev > Log: > Merge r1789258, r1856189, r1856191, r1856192, r1856196 from trunk: > > > apr_dir_read: Since readdir() is now thread

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

Sounds great, good observations. Absent any other opinions, with that resolved, I'm happy to tag and roll this afternoon to begin the release vote. On Fri, Mar 29, 2019, 04:26 Yann Ylavic wrote: > On Fri, Mar 29, 2019 at 5:01 AM William A Rowe Jr > wrote: > > > > Opinion

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

Yes, that patch is option 2... and I would be alright with that choice. Looking for consensus on which way we resolve this. Opinions? On Thu, Mar 28, 2019, 10:55 Yann Ylavic wrote: > On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr > wrote: > > > > So... What is our

  1   2   3   4   5   6   7   8   9   10   >