Re: RFC: APR 2.0 modularization
> On 20 Apr 2024, at 11:38, Ivan Zhakov wrote: > > Hi, > > In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good thing. Um, apr-util was a separate library, but not really a separate project. The separation may have been a little OTT, but merging them runs into "ain't broke, don't fix", with likely confusion arising from the change to a familiar status-quo. But that's just a view from about 20 years too late. > I would suggest separating APR in different libraries, while keeping them in > one project/source tree. > > Something like that: > - apr-2 > - apr-dbd-2 > - apr-dbm-2 > - apr-xlate-2 (?) > - apr-crypto-2 > - apr-xml-2 > - apr-ldap-2 > - apr-memcache-2 > - apr-redis-2 Works in principle, though packagers and users should probably have an apr-everything option alongside those. The question is, is it worth it for such a marginal change? Have you looked in to the practicalities and verified no major stumbling blocks, bearing in mind that developer effort tends to be thin on the ground? -- Nick Kew
Re: apr_dbm and concurrency
> On 9 Nov 2023, at 16:15, Greg Stein wrote: > > Personally, I'd deprecate apr_dbm entirely, and direct all clients towards > sqlite. > > The DBMs were intended for simple key/value stores 20 years ago. We have much > better tech now. Sqlite does K/V so much better, *and* it handles > processes/threads. I really don't see a reason for DBM nowadays. > > Who can justify using (say:) ldbm over sqlite? Legacy apps? I first used ndbm more than 30 years ago. Software from that era is still in use, and might crop up in someone's work today. I *think* I even wrote about the apr_dbm concurrency issue long ago, in an era when non-thread-safe libraries were being adopted willy-nilly and to point it out was to be labelled a stick-in-the-mud enemy of progress. +1 to deprecting apr_dbm, provided we explain exactly why (so users are clear whether or not it matters to their use cases). The alternative would be smart locking code within apr_dbm, and I doubt that anyone wants to put that effort in. Applications can still use a dbm of their choice without the APR layer. -- Nick Kew
Re: Bindings for Python or Ruby? And APR docco?
de > On 3 Jul 2023, at 22:08, Mads Toftum wrote: > > On Mon, Jul 03, 2023 at 01:20:14PM -0500, Greg Stein wrote: >> While I would doubt there is a book about APR itself, I would bet any book >> that talks about writing a module for Apache has extensive coverage of APR >> (if such a book exists; dunno). There is no docco besides the headers and >> the code itself. >> > There's a 30 page chapter on APR in Nick Kew's The Apache Modules Book. Thanks for the mention, but I doubt that would tell RoUS anything he doesn't already know! Bindings for scripting languages get mentioned only in passing in the book, and the detail goes no deeper than "mod_foo has foo bindings for HTTPD API and APR so you can do much the same things in foo as in C". I don't think APR would make much of a book on its own. Sure, you could expand on what I wrote, but only up to a point, so you'd want some context for it. Scripting might make just such a context if you can make a case that APR adds value to existing scripting language libraries other than in a specific context like HTTPD. -- Nick Kew
Re: Dropping Netware code from Windows apr/trunk
> On 7 Dec 2021, at 13:50, Mladen Turk wrote: > > There are still bunch of Netware code > polluting win32 code in apr/trunk. > > Since the Netware itself is discontinued for > quit some time, I wonder the effective purpose > of that code inside apr. > > I propose to remove all that > #ifdef NETWARE from file_io/win32 and others, > since IMHO those are totally unusable. If you can do that cleanly then great! Should we draw a clean line under released branches, so anything later than 1.7.x drops Netware, regardless of whether it's a 1.8 or a 2.0? -- Nick Kew
Re: Subversion reports status fault on substituted drive
> 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 release, > I'd like the chance to fix that quirk of the Win32 API and populate the stat > struct with something resembling correct info about the root mounts. Is the issue here that we have something that simply won't map onto Windows expectations, so there is no solution that will work for Johan without re-introducting PR#47630? If so, perhaps what we need is an additional argument that'll switch between the two behaviours (ignored on non-windows), and to deprecate the existing problematic API. I'm reluctant to jump in here myself 'cos it's been many years since I had access to a Windows machine, let alone a dev environment. But it's simple enough, I guess I could hack up a "looks OK" patch to do that in the absence of any alternative proposal? BTW, please don't Cc: me replies to this thread. I get it on the APR dev list, and I don't need a second copy! -- Nick Kew
Re: Time for new APR APR-Util
Apologies to Noel: I just sent this to him without the list. Duh! > On 23 Nov 2020, at 02:32, noel.but...@ausics.net wrote: > > Given the only way to get apr* to build and play nice with latest mariadb 10 > series is by using SVN, perhaps it might be time for new release? > > Just putting it out there ;) Hmm, which particular svn fixes are they that make it work for you? Mariadb speaks to me of the dbd layer, which is apr-util. I hadn't realised we had something mission-critical unreleased in 1.x! -- Nick Kew
Re: [Bug 64813] I am trying to access internert but it keeps crashing
On Tue, 13 Oct 2020 20:45:18 +0100 Mark Thomas wrote: > > Anyone from infra@ watch our bugzilla? > > Monitoring a project's issues for spam is a project responsibility. If > you see any, let infra know and one of the volunteers will take care > of removing it. Thanks. I see the offending page seems to have gone, so presumably either the Cc: to infra@ or someone else did the job! -- Nick Kew
Re: [Bug 64813] I am trying to access internert but it keeps crashing
> On 13 Oct 2020, at 19:48, bugzi...@apache.org wrote: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=64813 > > Eric Covener changed: > > What|Removed |Added > > Status|NEW |RESOLVED > OS||All > Resolution|--- |INVALID That was actual spam with a link. Marking invalid isn't enough: one link there is likely to be a magnet for more. Anyone from infra@ watch our bugzilla? -- Nick Kew
Re: svn commit: r1854603 - in /apr/apr-util/branches/1.7.x: build/apu-conf.m4 build/xml.m4 configure.in include/apu.h.in include/apu.hw include/apu.hwc xml/NWGNUmakefile xml/apr_xml.c xml/apr_xml_expa
> On 25 Jul 2020, at 10:10, Graham Leggett wrote: > > On 24 Jul 2020, at 17:03, Nick Kew wrote: > >>> Another ping on this one - the apr-util 1.7 build is still broken. >> >> Whoops! I'd completely forgotten that. >> >> Thanks for the partial patch. Do you want to commit it? > > I’ve just committed http://svn.apache.org/viewvc?rev=1880286=rev and > http://svn.apache.org/viewvc?rev=1880287=rev - it Works For Me(TM) on > MacOS and CentOS8, can you give it a try? Thanks. All works cleanly for me on both my platforms (Debian and MacOSX/homebrew) with either XML parser option. I note that it's building both apr_xml_expat.o and apr_xml_libxml2.o, but that the one not selected is empty. Are we bothered by that? An alternative would be to #include the expat and libxml2 source files into apr_xml.c, with the existing #ifdefs to select which gets used. -- Nick Kew
Re: svn commit: r1854603 - in /apr/apr-util/branches/1.7.x: build/apu-conf.m4 build/xml.m4 configure.in include/apu.h.in include/apu.hw include/apu.hwc xml/NWGNUmakefile xml/apr_xml.c xml/apr_xml_expa
On Fri, 24 Jul 2020 14:11:10 +0200 Graham Leggett wrote: > On 06 Aug 2019, at 15:55, Rainer Jung wrote: > > > Just a reminder, that APR-UTIL 1.7.x still doesn't compile due to > > the wrong handling of INCLUDES. > > Another ping on this one - the apr-util 1.7 build is still broken. Whoops! I'd completely forgotten that. Thanks for the partial patch. Do you want to commit it? -- Nick Kew
Re: Subversion reports status fault on substituted drive
> On 9 Apr 2020, at 12:19, Nick Kew wrote: > > >> On 9 Apr 2020, at 11:07, Johan Corveleyn wrote: >> >> [ cc -= dev@subversion.a.o ] >> >> Hi APR devs, >> >> 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), > > That fixed a bug PR#47630 that had been extensively discussed in > bugzilla and shows as having 22 watchers - that's a lot of interest! Posting from another address to investigate possible harvesting of this list for spam. After my last post I got an automated message that looked closely related to the svn subject! -- Nick Kew
Re: Subversion reports status fault on substituted drive
> On 9 Apr 2020, at 11:07, Johan Corveleyn wrote: > > [ cc -= dev@subversion.a.o ] > > Hi APR devs, > > 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), That fixed a bug PR#47630 that had been extensively discussed in bugzilla and shows as having 22 watchers - that's a lot of interest! Does that discussion not throw any light on your issue? For example, Michael Schlenker's comments there refer to that bug affecting SVN. -- Nick Kew
Re: Broken link in apr/trunk/include/apr_dbd.h
> On 19 Mar 2020, at 19:54, Mike Rumph wrote: > > Attention to Nick. > > While trying to get background on the thread "DBD, rows and memory pools", I > noticed that the include file apr_dbd.h has a broken link: > > /* Overview of what this is and does: > * http://www.apache.org/~niq/dbd.html > */ Hmm, I doubt that ever existed. s/www/people/ and the page is still there, but looks like something that hasn't been updated since copying from webthing. Do you think there's anything in http://people.apache.org/~niq/dbd.html worth maintaining that isn't in the regular docs? -- Nick Kew
Re: DBD, rows and memory pools
On Sat, 14 Mar 2020 19:58:11 + Steven Fosdick wrote: > On Sat, 14 Mar 2020 at 02:34, Nick Kew wrote: > > Isn't your most obvious fix simply to allocate your row > > from your choice of pool before the first get_row? > > That wouldn't work. Here's the start of the dbd_oracle_get_row > function in the apr_dbd_oracle driver: OK, fairy nuff. Probably my fault. apr_dbd started life as complementary to HTTPD's mod_dbd, and your millions-of-rows usage wasn't really a consideration. > Is there guidance or a standard for driver writers > elsewhere? No. Apart from our own needs, we just have occasional feedback from users like yourself. Just thinking aloud here, I wonder if an apr_dbd_row_alloc API would meet your needs? I haven't thought through how it would be implemented, and it also raises the question of whether allocator APIs for other apr_dbd structs might be in order. -- Nick Kew
Re: DBD, rows and memory pools
> On 14 Mar 2020, at 02:23, Nick Kew wrote: > > [chop] Damn, shouldn't be posting while down with a lurgy. Isn't your most obvious fix simply to allocate your row from your choice of pool before the first get_row? Or am I still missing something? -- Nick Kew
Re: DBD, rows and memory pools
> On 14 Mar 2020, at 01:18, Steven Fosdick wrote:
>while (!apr_dbd_get_row(drv, rpool, res, , -1)) {
>for (int c = 0; c < cols; c++) {
>const char *name = apr_dbd_get_name(drv, res, c);
>const char *value = apr_dbd_get_entry(drv, row, c);
>printf("%s=%s\n", name, value);
>}
>apr_pool_clear(rpool);
>putchar('\n');
>}
Clearing the pool within a loop using it? Yes, that would segfault!
> I can obviously resolve this by initialising row to NULL each time:
Indeed. Or if you're dealing with millions of rows, you might consider
a hybrid approach: clear and reset to NULL every $count rows?
> It seems to me that if there is some data to be retained between
> fetching one row and the next it should really be allocated from the
> memory pool given to apr_dbd_select, not the one given to
> apr_dbd_get_row. What do you think?
Indeed, I wonder if you're the first to try that particular pool usage?
It's your choice of pools. Are you suggesting apr_dbd_get_row should
take two pool arguments, or that apr_dbd_results_t should remember
its pool and allocate rows out of it? Mightn't that itself become a nasty
gotcha for programmers, and risk blowing up existing programs?
--
Nick Kew
Re: Proposal: apr-tools project
> On 25 Jul 2019, at 12:22, Graham Leggett wrote: > > Hi all, > > I propose the creation of, in addition to apr and apr-util, the apr-tools > project. > > apr-tools would contain a series of command line tools that correspond with > many of the capabilities of the apr library. Such tools might include: Would that be purely in C, or could it be a mix, perhaps including scripting languages? > - escape: A tool that can escape and unescape data based on the apr_escape.h > API. > - encode: A tool that can encode/decode based on the apr_encode API. > - dbd: A tool that can perform database queries through the apr_dbd > astraction, etc. First thought: harmless, but how useful is it? Do you have evidence of a userbase who are insufficiently served by existing tools in a similar space? Or, I guess, how did you come to it? Is it that you have a use for it somewhere in your own work, and think your use likely to generalise to others? > First question is thoughts? Bonkers? Good idea? Persuade me the potential reward is worth the effort, and I'll go with the Good Idea. > Second question is structure. Part of APR? Alongside APR? Either within APR or your external effort: IMHO it would be excessively bureaucratic to put it within the ASF but separate from APR. -- Nick Kew
Re: The case for apr-util-2.0
> On 6 Jun 2019, at 06:07, Mladen Turk wrote: > > I remember the days when apr was operating system abstraction layer, > and apr-util was the bunch of platform independent code where one > could eventually decide which key/value dbm (beside provided sdbm) > and bundled subset of expat. And then there was apr-iconv You said it yourself. Dependencies already in apr-dbm! > When asking why can't we put some of the cool apr-util stuff > like buckets, date, queue, etc ... to apr, there was a strong > dislike "because that's not OS abstraction stuff" An "insider" view. For the outside world, the apr/apu split achieved very little beyond mild confusion. The whole package is, after all, still pretty small in the global scheme of things. Having said that, reversing the split from where we are now could just be more confusion. Ho, hum. > Anyhow, back then apr-util could be still build without any external > dependencies (apr_xlate should have always be a part of apr-iconv, but no one > listened) Um, in the same sense it still can. ldap and dbd are just as optional as dbm! > Then, at some point of time, apr-util introduced modules and > become wrapper around third party libraries. > Suddenly it got bloated to extremes. It become a dump spot for > whatever database, crypto library ... whatever wrapper. Yes, it has modules. We even introduced dynamic loading of the apr_dbd_foo modules, though perhaps that was somewhat half-baked. > OTOH, Apache Httpd uses for its core modules stuff like libcurl > that has its own OS abstraction layer. > > IMO, all that third party library wrappers should not be part of > apr. Anything from apr-util can go to apr (as it should in the first place), > but all those dbm, db, odbc, ldap or whatever providers should go as > separate apr projects. I think you're arguing for fully-baked apr modules, yesno? > Basically for 2.0 we should have > apr/apr (the real stuff) > apr/apr-my-fancy-dbm-module1 > apr/apr-my-fancy-dbm-module2 > apr/apr-my-fancy-crypto-library > apr/apr-iconv :D > > > Since I already know, none of that will be accepted, please > don't bother to convince me that I miss the point. OK ;) Can't speak for others, but I'm neither accepting nor rejecting that. I believe our downstream packagers already serve apr as modules: e.g. https://packages.debian.org/search?keywords=libaprutil1 shows apr-dbd-foo and apr-ldap separated out. If you're proposing to extend that to other dependencies and even apr_iconv, I doubt anyone will object. And if you want to open it, like httpd, to third-party modules, that would indeed look rather interesting. Though I doubt there would be so many takers as with something more visible like httpd! -- Nick Kew
Re: [Announce] Apache Portable Runtime APR 1.7.0 Released
> 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 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 version 1.2.2 of the >APR iconv library (APR-iconv) remain current. Thanks, Bill. Just a quick note. Some of the announcement (expat, MySQL and FreeTDS) relate not to this APR, but to APR-UTIL updates which are not part of this release. I know you're keen to get an APR-UTIL update released reasonably soon, and I promise to tackle at least the XML issues I've been working on when I get back home - which I anticipate being second half of next week. We also have some further MySQL updates from an external contributor, which I hope to find time to review in time for APR-UTIL 1.7. -- Nick Kew
Re: [vote] Release apr-1.7.0 ?
On Mon, 1 Apr 2019 13:01:55 -0500 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 +1. Works for me. Debian (currently my only dev platform). Thanks, Bill. -- Nick Kew
Re: svn commit: r1854603 - in /apr/apr-util/branches/1.7.x: build/apu-conf.m4 build/xml.m4 configure.in include/apu.h.in include/apu.hw include/apu.hwc xml/NWGNUmakefile xml/apr_xml.c xml/apr_xml_expa
> On 27 Mar 2019, at 17:55, Rainer Jung wrote: > > This breaks 1.7 apu compilation using non-system expat for me. The expat > detection sets INCLUDES but during compilation INCLUDES isn't used anywhere, > so expat.h can't be found. OK, I need to return to that. Thanks for the reminder! Does trunk compile for you in the same circumstances? This is supposed to be a backport! -- Nick Kew
Re: Showstoppers to 1.7.0?
On Fri, 1 Mar 2019 12:04:34 -0600 William A Rowe Jr wrote: > My question was entirely limited to apr, I hadn't yet considered > pushing for an apr-util release. Hehe. It occurred to me to ask that, but only after my reply yesterday night. :) > Perhaps resolving apr 1.7 this month (what I've raised), plus > targeting about a month from now to move forward with apr-util 1.7 > would be helpful to nudge some of these efforts along? Indeed - thanks for taking the initiative (again)! A bugzilla trawl would be good. I'll see if I can find a round tuit down the back of the sofa. -- Nick Kew
Re: Showstoppers to 1.7.0?
> On 27 Feb 2019, at 23: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 remaining obstacles. Did I backport the xml build option for libxml2? If not, that's a round tuit I need to get before 1.7. Will take a look tomorrow. -- Nick Kew
Re: possible segfault in poll/unix/epoll.c
> On 30 Nov 2018, at 08:42, Christian Töpp > wrote: > > Hi, i have found that in function > > static apr_status_t impl_pollset_remove(apr_pollset_t *pollset, >const apr_pollfd_t *descriptor) > > neither pollset nor descriptor are checked for NULL-pointers. i have > seen some segfaults on my dev-machine according to this function. APR doesn't generally offer strong guarantees on pointer checking. Do you have a traceback of what's passing it null pointers? -- Nick Kew
Re: Issue while accessing memory
> Please help me to solve this. It looks as if your pool could be in charge of memory that something else already freed. Possible causes of that lie outside the scope of what you posted. And probably outside the scope of APR. -- Nick Kew
Fwd: Making proxy "busy" atomic and implement a busy limit
Apologies to Jim. Sent this to him, meant for the dev list of course. >> On 17 Sep 2018, at 14:18, Jim Jagielski wrote: >> >> FYI: Both clang and GCC support both __sync and __atomic which support 64bit >> ints. We could add that functionality to APR... > > We could indeed. > > But does that not potentially leave a nasty gotcha? Where a developer uses > it and expects > atomic operations, and their application is subsequently built on a platform > that > doesn't support those qualifiers. > > With the obvious fallback it breaks silently. With a more > sophisticated/heavyweight > fallback, we should consider whether it's maintainable or likely to fall into > disrepair. > > I wouldn't want to stop you, but it needs some thought. > > -- > Nick Kew
Re: [VOTE] apr-1.6.5 release
On Mon, 10 Sep 2018 16:22:32 -0500 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 (Debian). It's possible but unlikely I'll get to test elsewhere in the time available. But it certainly won't be platforms of real interest in this release. Thanks for doing the RM job! -- Nick Kew
Re: Backports to consider for 1.6.4?
> Pull request #5 https://github.com/apache/apr/pull/5/files > corresponds to https://bz.apache.org/bugzilla/show_bug.cgi?id=61985 > Yann and I are neutral on dodging (fd == -1), what do others think? > This would be a trivial one-line fix if we adopt it. > > Are there any committers with an opinion after reviewing the PR comments? Yann comments on the Linux manpage's comments on negative fd. I just looked on MacOS, and the (BSD) page is silent on the subject. I guess there's no such thing as an authoritative reference? In the absence of such, I'd be reluctant to change this in 1.6, but open to something for 1.7. I may comment on the bugzilla report. -- Nick Kew
Re: 1.6 release?
> 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?
> 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?
> 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: Release schedule of APR-1.6.4?
> On 29 Aug 2018, at 09:25, Eric . wrote: > > Hi all, > > May I have an idea approximately when APR-1.6.4 will be released? > Thank you very much. If you read this list, you know exactly the same as all of us. Are you running on Solaris and looking for that poll patch, or do you have some other interest? -- Nick Kew
Re: svn commit: r1836519 - /apr/apr/trunk/strings/apr_strings.c
> On 25 Aug 2018, at 14:55, Rainer Jung wrote: > > Should this be changed or reverted? The discussion seems to have stalled. Damn, did something half-baked get committed? > And what about backport for 1.7.x and 1.6.x? IMHO not for 1.6: keep changes really minimal. 1.7 would make sense. -- Nick Kew
Re: 1.6 release?
> 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: svn commit: r1817889 - in /apr/apr/branches/1.7.x: ./ test/testipsub.c test/testlock.c
> On 25 Aug 2018, at 14:05, Rainer Jung wrote: > > Should we backport this to 1.6.x? At least it would apply cleanly. > > Am 12.12.2017 um 09:07 schrieb jor...@apache.org: >> Author: jorton >> Date: Tue Dec 12 08:07:33 2017 >> New Revision: 1817889 I'm fine either way. In the unlikely event that it blows up, it's the tests, not someone's production system. -- Nick Kew
Re: Backporting reslist changes?
> On 25 Aug 2018, at 15:03, Rainer Jung wrote: > > I dont't remember the outcome of the discussions, but are any of the > following three reslist changes reasonable for 1.6 backport? IMHO No. If it ain't broke, don't fix it in 1.6. Changes that call for non-trivial or production testing belong in 1.7, along with the crypto updates and possibly the json from amongst what's been happening on trunk. -- Nick Kew
Re: svn commit: r1838963 - /apr/apr/branches/1.6.x/poll/unix/port.c
> On 25 Aug 2018, at 00:39, Yann Ylavic wrote:
>
> On Fri, Aug 24, 2018 at 11:13 PM wrote:
>>
>> -if ((*num = j)) { /* any event besides wakeup pipe? */
>> +if (nres > 0) { /* any event besides wakeup pipe? */
>> +*num = nres;
>> rv = APR_SUCCESS;
>
> Shouldn't we set *num = 0 still?
It already is (at the top). But yes, that could be further rationalised.
I basically fixed what caused me to take twice as long as it should
have done to review it (though obviously the ugliness was older
than your fix I was reviewing).
> Btw, this commit probably needs to go to trunk too.
Agreed. And 1.7. Will do - unless you get there first.
--
Nick Kew
Re: 1.6 release?
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: [RFC] apr_array_find()
> On 27 Apr 2018, at 03:37, Jim Riggs <jim...@riggs.me> wrote:
>
> I am working on some httpd changes/features/ideas and have multiple needs to
> find items in an array. In httpd, we currently have these:
>
> AP_DECLARE(int) ap_array_str_index(const apr_array_header_t *array,
> const char *s,
> int start);
>
> AP_DECLARE(int) ap_array_str_contains(const apr_array_header_t *array,
> const char *s);
Both of which could - perhaps should - really be APR functions!
That is, with one reservation, that applies to both those and your proposal.
This is (inevitably) linear search. If we provide search within APR, we could
be misleading developers into using it for very big arrays, where they should
be avoiding linear search.
I think I’ve been through that thought process myself:
1. I need a searchable set structure.
2. Hmm. Why do I need to reinvent the obvious wheel of apr_array_find()???
3. Oh I see, it’s linear search.
4. How scalable do I want my array to be?
5. Damn. Better use hash instead.
In the absence of step 2, I’d probably never have reached steps 3-5.
> In my use cases, the search may often be strings, but not always, so I
> thought that maybe APR could/should provide something more generic. The above
> functions could then be rewritten to use this new function. Here are my
> thoughts:
>
> 1. The search item (needle) can be anything rather than just a string as
> above.
> 2. The caller provides a callback that compares the values to needle in the
> same way strcmp()/strcasecmp() do. That is, 0 means "equal". In fact,
> strcmp()/strcasecmp() can -- and probably often will -- be used as the
> callback for strings.
There’s a bit of a mismatch between that and the “can be anything”.
The latter would call for a size parameter that could be passed to memcmp,
as well as of course strncmp/strncasecmp.
> 3. A start (input) and index (output) parameter can be used to iterate and
> find all occurrences.
> What do others think? Is there value in this, or is it just me?
I’ve had occasion to search an array, though I don’t think I’ve needed anything
more
generic than the HTTPD functions you name above.
> +typedef int (apr_array_find_comparison_callback_fn_t)(const void *x, const
> void *y);
Minor quibble: the name seems quite tortuously overdescriptive!
> + for (i = start; (i < arr->nelts) && comp(needle, *(void **)(arr->elts +
> (arr->elt_size * i))); i++) {
> +/* empty */
> + }
Why not make that much more readable and put the substance inside the loop?
for (i …) {
if (!comp(…)) {
set *index;
set return value;
break;
}
}
—
Nick Kew
Re: svn commit: r1828369 - in /apr/apr/trunk: include/apr_reslist.h util-misc/apr_reslist.c
> On 13 Apr 2018, at 21:46, Yann Ylavic <ylavic@gmail.com> wrote: > > On Fri, Apr 13, 2018 at 7:30 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: >> I'm still unclear why you believe we need APR to purge the elts when the >> user chooses to flip the fifo/lifo switch. That seems very wrong to me, the >> consumer can do so if that is what they desire. > > To be clear (with myself): > > /* What we have */ > APU_DECLARE(apr_status_t) apr_reslist_acquire(apr_reslist_t *reslist, > void **resource); > /* What we want */ > #define apr_reslist_acquire_lifo apr_reslist_acquire > APU_DECLARE(apr_status_t) apr_reslist_acquire_fifo(apr_reslist_t *reslist, > void **resource); You have a plan to implement that with the existing structs? How does it work if an application mixes the two forms of acquire randomly, as seems likely if (for example) a reslist is shared between applications/components of differing provenances? I’d be reluctant to see a significant performance hit. I’m also thinking, with fifo the reslist might tend to grow bigger, as more elements are re-used well within the timeout and thus never be deleted to reduce the size. Isn’t that an argument for making reslist an either/or thing with policy determined once and for all when it’s created? — Nick Kew
Re: Licensing claims (fnmatch)
On Wed, 2018-02-21 at 11:30 -0600, William A Rowe Jr wrote: > then all further patches to apr_fnmatch.c would still be licensed in > BSD terms and consumable upstream, provided the PMC is agreeable; > > 5. Major modifications/additions to third-party should be dealt with > on a case-by-case basis by the PMC. > > This would make the synchronization of POSIX [:class:] and other bug > fixes and extensions to apr_fnmatch much simpler. > > Would this be acceptable to APR PMC? As far as I'm concerned, that's fine provided we have no objections from any significant contributors. A quick look at svn suggests that's basically yourself, with some early commits from Ryan. I don't think Ryan is active here any more, so perhaps he should be pinged as a matter of courtesy? Or is his name there a mere technicality, perhaps a legacy of an initial code drop into svn? -- Nick Kew
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
> On 18 Oct 2017, at 15:58, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Please cast your votes on the following candidate packages; > > Release apr-1.6.3 > [ ] +1 looks good > [ ] +/-0 since > [ ] -1 because +1 > > Release apr-util-1.6.1 > [ ] +1 looks good > [ ] +/-0 since > [ ] -1 because +1 > Release apr-iconv-1.2.2 > [ ] +1 looks good > [ ] +/-0 since > [ ] -1 because +0 Will revisit if this one stalls due solely to lack of votes. Thanks for driving the release! — Nick Kew
Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases
On Wed, 18 Oct 2017 09:58:59 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > Please cast your votes on the following candidate packages; > > Release apr-1.6.3 > [ ] +1 looks good > [ ] +/-0 since > [ ] -1 because All good on Linux. Pending testing on Mac and static review of changes before my +1. Will complete review tomorrow. > Release apr-util-1.6.1 > [ ] +1 looks good > [ ] +/-0 since > [ ] -1 because As above. > Release apr-iconv-1.2.2 > [ ] +1 looks good > [ ] +/-0 since > [ ] -1 because Wow! I don't think I've ever built or looked at apr-iconv before. Builds successfully on Linux, but since the issues you've dealt with concern Windows, I'm not able to review them. -- Nick Kew
Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)
On Wed, 27 Sep 2017 15:15:29 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > I don't believe we can do libxml2 until the release of 1.7.0, the > supporting logic that Nick committed is sitting in trunk/2.0 - It's > not on my agenda today, but after 1.6.1/1.6.3, sure. > Indeed, I realised it was only in trunk while we were in the 1.6 release push. I think we had enough delays in that, without the risks of another fairly substantial backport! I guess now 1.7 makes a good target for it. It's on my agenda, insofar as I have one these days. -- Nick Kew
Re: Tagging apr 1.6.1 -util 1.6.3?
On Fri, 2017-09-22 at 12:18 -0500, William A Rowe Jr wrote: > We seem to have collected a number of good patches, and Jim's > expressed his hope to roll httpd-2.4.28 today. > > I'd like to see us issue a corresponding release on the same time > scale, if we could tag and roll sometime between today and tomorrow > the votes would roughly conclude and releases would be announced > pretty concurrently. +1 - provided Yann's sdbm patch is committed. -- Nick Kew
Re: Talking json
On Tue, 2017-09-05 at 08:34 -0400, Jim Jagielski wrote: > > Maybe this is a good choice > > > > https://github.com/moriyoshi/apr-json > > > > I always thought this would be a good addition for APR 2.0 > at least... Earlier would be even better :) Indeed it would. But while noone here is actively hacking it, a third-party github repo is IMHO a perfectly good alternative. Are you suggesting we reach out to moriyoshi? Does anyone know him? Even whether he speaks English? -- Nick Kew
Re: Life cycle questions
On Mon, 2017-07-31 at 09:23 -0500, Ben Harper wrote: > Thanks for the timely replies. Would it be safe to say that there will > be no breaking changes till a 2.x version? At the simple level of the API, yes. It should continue to serve as a drop-in replacement for earlier versions. Build options changed from 1.5 to 1.6 and may change again. So you might update your build. -- Nick Kew
Re: Life cycle questions
On Fri, 2017-07-28 at 15:02 -0500, Ben Harper wrote: > Greetings, > > I have some questions regarding the life cycle of the different versions > of apr and apr-util that the 'Version Numbers' page did not fully > answer. Different projects handle life cycle differently. Some only > support the latest version, while others support several versions > concurrently. Is only 1.6 support or will 1.5 still get updates? The distinction is less important than with some projects. 1.5 is unlikely to get updates now unless hit by some serious security issue. But 1.6 is really just an incremental update on 1.5: the main reason for the version bump is how it deals with third-party dependencies: expat is unbundled, and more up-to-date versions of some other libraries are supported. > The project I work with (ius.io) currently packages apr 1.5 and apr-util > 1.5 so we can package httpd. We are trying to determine if we need to > upgrade these packages. The latest httpd packages APR 1.6: it resolves some issues for them. Including security issue cve-2012-0876 for users who use the bundled expat. Ultimately if you don't upgrade, you may find your users clamouring for more up-to-date versions of libraries like mysql and openssl than will build (cleanly, out-of-the-box) with 1.5. -- Nick Kew
Re: Bugs in apr_file_trunc
On Fri, 2017-06-30 at 11:44 -0400, Jim Jagielski wrote: > Thx... it's a shame that either (1) these bugs aren't reported > to the APR dev team to fix or (2) that they are, but that the > dev team isn't aware or following up. Well, there may or may not be some report deep in the archives or in bugzilla. On the other hand, there is quite a lot of overlap between the SVN and APR dev communities, including committership. I wonder if there's confusion like a fix that's trunk-only? -- Nick Kew
Re: Adding LibreOffice as project using APR
On Sat, 17 Jun 2017 22:44:29 +0200 (CEST) Sophia Schroeder <lo-mailingli...@sophia-s.de> wrote: > Hello, Apologies for the time taken to reply. I just edited the source for our page, and will go live shortly. > I am volunteering in the Open Source Project LibreOffice > and want to have added it to the list of projects using APR. > > Our project URL is: https://www.libreoffice.org Thanks for the heads-up. A project as big and important to yours is a feather in our cap at APR! Very happy to add you to our roster. At a glance, I see you use APR through Serf. Do you also use APR directly somewhere I didn't notice it? -- Nick Kew
Re: svn commit: r20203 - /dev/apr/Announcement1.x.txt
On Mon, 2017-06-26 at 19:41 -0500, William A Rowe Jr wrote: > Yes, I did that file arrives from apu, not apr, but I believe(?) We > fixed both? We have patches for both, but it's a sequencing thing. The APR patch was applied for 1.6.1 (past tense). APU 1.6.1 remains future tense. -- Nick Kew
Re: svn commit: r20203 - /dev/apr/Announcement1.x.txt
On Mon, 2017-06-26 at 17:53 -0500, William A Rowe Jr wrote: > Nick, I went ahead and took the static text of previous announcements > and worked in all of your advisories as our persistent Announcement > draft during the 1.6 phase; I hope you don't mind. Why should I mind? You found a page that needed updating, you updated it. Great - thanks. > https://dist.apache.org/repos/dist/dev/apr/ > > Edits welcome. Will cast an eye over it sometime when it's daytime ... > > +- Build files find_apr.m4, find_apu.m4 and apr_common.m4 are now > > + exported for the benefit of packagers. >From memory, haven't you magicked up an extra .m4 there? -- Nick Kew
Apache Portable Runtime and Utilities 1.6 released
The Apache Software Foundation and the Apache Portable Runtime Project are proud to announce the General Availability of version 1.6 of the Apache Portable Runtime libraries. Now available from https://apr.apache.org/ are: * The Apache Portable Runtime (APR) version 1.6.2 * The APR Utilities library (APR-UTIL or APU) version 1.6.0 Users of earlier versions are recommended to upgrade both libraries, although it is also possible to upgrade them individually. The Apache Portable Runtime libraries provide cross-platform APIs that relieve developers of the need to deal with platform differences. They serve as a Write-Once-Run-Anywhere layer for programs written in C (or with C linkage) such as Apache's HTTPD (web server) and Subversion (revision control system). They also offer programmers facilities usually associated with higher-level languages, such as memory and resource management. PRINCIPAL CHANGES IN VERSION 1.6 Please see the CHANGES files for details of programming changes. Although APIs have been been introduced, this release is fully compatible at both source and binary level with programs developed using earlier APR-1.x/APR-UTIL-1.x versions. Externally visible changes that affect build and/or installation are: APR-1.6.2 - Build files find_apr.m4 and apr_common.m4 are now exported for the benefit of packagers. APR-UTIL-1.6.0 There are a number of updates to how APR-UTIL deals with external dependencies: - XML: - Expat sources are no longer bundled, this is now an external dependency. You must install expat on your system to use APR-UTIL (expat is installed as standard on most systems). If you are building APR-UTIL, you may need to obtain expat 2.2 or later from https://libexpat.github.io/ or depending on your system's packaging policies, install their expat-dev or expat-devel package. Note that 2.2 addressed some security vulnerabilities of earlier libexpat project releases. - CRYPTO: - OpenSSL support is updated to support OpenSSL version 1.1. - Apple's CommonCrypto is supported for Mac and IOS platforms. - DATABASE: - MySQL support has been updated as advised by the MySQL developers. MySQL versions older than 5.5 should not be used. Or if you do use an old MySQL version, you will need to hack the build to use the thread-safe libmysqlclient_r version of the library. - FreeTDS partial and incomplete support has been dropped. Users of MSSQL and SYBASE databases are recommended to use the ODBC driver instead. -- The Apache Portable Runtime Project
Release Notes
Bill has just pinged me on IRC, and suggested I should draw everyone's attention to it, in case folks have missed it. I wrote a brief RELEASE_NOTES at the time I rolled the 1.6.1 tarball. It's in svn at /dev/dist/ along with the tarballs we've just voted to release. Review and improvement welcome. -- Nick Kew
Re: splitting [VOTE] thread of APR-UTIL 1.6.0
On Mon, 12 Jun 2017 02:07:25 -0400 Dennis Clarke <dcla...@blastwave.org> wrote: > Mind if I push this over a strict C99 test on a POSIX compliant > system? Please do! Here's hoping that whatever problems you may identify are not regressions or other showstoppers! > ps: yes any reasonable person that wants access to Oracle cloud > systems will be helped here. There are concerns. I'm wondering how far we can go towards automating the kind of build/test you're doing. If (for the sake of argument) the project were to generate weekly tarballs ready-to-go with configure/make, perhaps that would help users of minority systems to set up automated testing? -- Nick Kew
Re: splitting [VOTE] thread of APR-UTIL 1.6.0
On Fri, 9 Jun 2017 08:04:56 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > We've voted on this package a number of times, it probably > does have the votes if we search through these original two > vote threads, but just to be clear I'll spin a new thread, and > we can attempt to unwind previously cast vote tallies to > call this specific release already baked. Looking like third time lucky. Or perhaps it's your magic touch. I've just been going through some of the site docs making basic updates for the new releases. So should be ready to go with those when the new releases become officially current. -- Nick Kew
Re: [VOTE] Release APR-UTIL 1.6.0
On Fri, 9 Jun 2017 08:07:17 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > As I mention in parent post, this is a distinct thread for any > final votes and to tally vote count of apr-util 1.6.0 release. > Usual http://apr.apache.org/dev/dist/ path for candidates. Thanks! Folks, can we please vote on this even if we encounter more problems with APR-1.6.2? This is kind-of more urgent than APR, in that it delivers to our users a bunch of necessary updates in supporting our dependencies (expat, openssl, mysql, etc). > +/- votes please > [ ] Release apr-util 1.6.0 +1 -- Nick Kew
Re: [VOTE] Release APR-1.6.1 and APR-UTIL 1.6.0
On Wed, 2017-06-07 at 19:00 -0400, Dennis Clarke wrote: > On 06/07/2017 06:20 PM, William A Rowe Jr wrote: > > https://github.com/apache/apr/tree/1.6.x?files=1 is our GitHub mirror of > > the 1.6 branch. > > > > Note you need to run ./buildconf - this requires libtool, autoconf and > > python. > > python? really? I need python to run buildconf? > > uggg ... that is a major wall to climb right there on some older > systems. Certainly ye POSIX Solaris world. > > > I'll see what I can do. You could take the latest tarball (1.6.1) and apply an svn diff from that to the current branches/1.6.x. Changes are minimal. That way, you can dispense with buildconf and go straight to the configure script. -- Nick Kew
Re: [VOTE] Release APR-1.6.1 and APR-UTIL 1.6.0
On Tue, 6 Jun 2017 17:16:23 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Thu, Jun 1, 2017 at 4:11 PM, William A Rowe Jr > <wr...@rowe-clan.net> wrote: > > On Wed, May 31, 2017 at 5:24 PM, William A Rowe Jr > > <wr...@rowe-clan.net> wrote: > >> Greg and others... (Netware, Win32, OS2, BEOS), please have a look > >> at the attached patch, which should apply to the 1.6.1 candidate. > > > > Committed, review on Netware, OS2 and BEOS would still be > > appreciated, either the candidate+patch or simply fetch 1.6.x > > branch. > > Yann's, Gregg's and my cursory reviews are looking better. Perhaps > time to try for 1.6.2? If you are able, Nick, that would be great, I > can find time late tomorrow to do so if you don't have free cycles. > > Sounds like httpd is itching to roll 2.4.26 so taking one more stab > at this now would be a good thing IMO. Sorry, we seem to be missing each other on IRC. Feel free to go ahead if you're itching to go. If you don't, Friday is my most likely time for a shot at it - after a night spent listening to the b* election. -- Nick Kew
[VOTE] Release APR-1.6.1 and APR-UTIL 1.6.0
I've uploaded release candidates APR-1.6.1 alongside the existing APR-UTIL-1.6.0. These bring the benefit of a number of updates to our users. Please test and VOTE on releasing these as our best available versions. [+1 / 0 / -1] Release apr-1.6.1 [+1 / 0 / -1] Release apr-util-1.6.0 Herewith my own +1 to both. -- Nick Kew
Re: Target 1.6.1?
On Tue, 2017-05-30 at 13:43 -0700, Jacob Champion wrote: > On 05/30/2017 08:06 AM, Nick Kew wrote: > > It's looking fine since Bill's surgical work last week. > > > > I'm minded to T apr-1.6.1 tomorrow, and put it up > > along with apr-util-1.6.0 for vote as Release Candidates. > > Any last thoughts on exporting more build artifacts [1] before 1.6 is baked? No, I hadn't considered those. This is an exercise in trying to release an updated bundle of what we've got, not introducing new things. > [1] > https://lists.apache.org/thread.html/d29d239e62bd4f76391e1011624988b57ace1d93493a1a22f823e968@%3Cdev.apr.apache.org%3E Hmm, so you've been pushing that for a while. Sorry I've missed it so far. I'll try and take a look. There may be a case for another release relatively soon if I don't get my head around it for 1.6.1. -- Nick Kew
Target 1.6.1?
It's looking fine since Bill's surgical work last week. I'm minded to T apr-1.6.1 tomorrow, and put it up along with apr-util-1.6.0 for vote as Release Candidates. Any objections? -- Nick Kew
Re: [VOTE] Release _timedlock API in 1.6.x?
On Fri, 2017-05-19 at 14:22 -0500, William A Rowe Jr wrote: > On Fri, May 19, 2017 at 2:21 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > [-0] Release current svn _timedlock API implementation in 1.6 > > My own vote, I suspect it has enjoyed 2/3 of the scrutiny needed > to be called the "best available release" and should be ready to > release soon, but not as soon as 1.6.1 tag is needed. I see you've done the deed. Thanks. Do you want to follow up by rolling the RC? I can do it, but I'm laid up with a 'lurgy, so it may be a day or two before I'm fit for any such thing. -- Nick Kew
Re: [VOTE] Release _timedlock API in 1.6.x?
On Mon, 22 May 2017 09:56:54 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > On May 19, 2017 2:21 PM, "William A Rowe Jr" <wr...@rowe-clan.net> > wrote: > > [ ] Release current svn _timedlock API implementation in 1.6 > > This seems to be the only questionable item remaining, and > this vote (and an enhancement may be vetoed, AIUI) is very > distinct from the poll on experimental features. > > Please vote, thanks. > > > I was hoping for more responses In case you're not counting my response on the other thread, I'm for backing out timedlock. We might treat experimental features on a case-by-case basis, but we shouldn't release something fully known to break. -- Nick Kew
Re: Backing out timedlock? (Was [POLL] Re: Et resurrexit tertia die.)
On Fri, 19 May 2017 13:28:02 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > No, it's dirt simple stupid to svn merge to revert each relevant Fair point. Let's do it, then make a 1.6.1 to twin with the existing APU tarball as RC. -- Nick Kew
Re: [POLL] (Was Re: Et resurrexit tertia die.)
On Fri, 19 May 2017 09:15:59 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > That sounds like a super headache, It's that already. Stripping out timedlock code for alien platforms is a huge risk that something as simple as a typo breaks it all. -- Nick Kew
Re: [POLL] (Was Re: Et resurrexit tertia die.)
On Fri, 2017-05-19 at 00:14 -0500, William A Rowe Jr wrote: > On Mon, Apr 10, 2017 at 4:40 AM, Nick Kew <n...@apache.org> wrote: > > I think we've done most of 1.6.0, modulo a couple of questionmarks. > > > > Potentially open issues are (in no particular order): > > 1. Mark timedlocks experimental > > The underlying question which we haven't resolved, and which our > discussion didn't draw out enough opinions/voices, boils down to this > simple question... Thanks for resurrecting this. I thought I'd shut up on the subject while some folks were likely doing ApacheCon. In this instance, we're using "experimental" as a euphemism for known-to-be-unready. As such, we shouldn't be encouraging anyone to use it with a current release, and should probably turn it off as a build option. No need to remove it entirely: code that is #ifdef'd out with HAVE_TIMEDLOCK will only be seen by those who dig deep enough to find it. There's another issue here: the non-unix platforms all have it. If we take it out from Unix altogether, we need to remove it from them too. Else we're taking the P from APR! Which brings me to ... > [ ] Release 1.x may include experimental features, disabled by default > [ ] Release 1.x may include experimental features, enabled by default > [ *] Releases don't include experimental features Refined to: [ ] Releases don't include too-experimental features, but MAY include code for them #ifdef'd out. [ ] Strip out the offending code altogether for release. -- Nick Kew
Re: 1.6.0 release candidates
On Wed, 10 May 2017 14:05:51 +0100 Nick Kew <n...@apache.org> wrote: > But if you got through "configure" without it checking for expat, > you would seem to have found a bug. Whoops! That should have read one or the other of expat and libxml2, since those are now alternatives. But it seems that didn't get backported from 2.0/trunk. I don't think that's a showstopper, but a bad omission. -- Nick Kew
Re: 1.6.0 release candidates
On Wed, 10 May 2017 11:33:13 + Dennis Clarke <dcla...@blastwave.org> wrote: > So that seems to be gone from apr-1.6.0 and I hope expat-2.2.0 solves > the issue. Yep, that's (due to be) part of the release notes. But if you got through "configure" without it checking for expat, you would seem to have found a bug. Thanks for test-driving. -- Nick Kew
Re: 1.6.0 release candidates
On Tue, 18 Apr 2017 13:36:36 +0200 Steffen <i...@apachelounge.com> wrote: > > Build Win32 with current httpd-2.4.26-dev, used not nick's files but > exported today 1.6.1-dev > > Used the IDE build (.dsw and dsp). > > Building fine. Great, thanks. > New warnings: > > > locks\win32\proc_mutex.c(170): warning C4244: 'initializing': > conversion from 'apr_interval_time_t' to 'DWORD', possible loss of > data That looks straightforward. An explicit cast to DWORD would presumably silence the compiler. Any problems with that? -- Nick Kew
Re: 1.6.0 release candidates
On Sun, 7 May 2017 03:01:55 + Dennis Clarke <dcla...@blastwave.org> wrote: > On 05/07/2017 12:54 AM, William A Rowe Jr wrote: > > So my blocking concern is that APR has never shipped an unready, > > disabled by default feature. I don't mind not ready for prime time > > but we traditionally called such things alpha or beta releases. I > > am not worried about a specific platform, but about the wide range > > of unreviewed architectures. > > I do mind shipping not ready for production prime time. Even a feature labelled as "unready, do not use unless you're prepared to hack it"? > Where is this 1.6.0 tarball such that I may give it a careful build on > my Solaris servers ? > > I don't see it at http://archive.apache.org/dist/apr/ http://apr.apache.org/dev/dist/ Note: I just re-rolled those, cleaned up as per comments in this thread. The contents (code and build) are unchanged. apr-1.6.0 has known problems and won't be released: we're looking to a 1.6.1. apr-util-1.6.0 is, as far as we know, good to release, but waiting on an updated apr-1.6 candidate. > I have very stable apache builds running in production and am certain > we can wring out what ever issue that may be in there with a pass > through the Oracle dev tools and strict c99 compiler. At the very > least I generally have debug builds wherein I can single step through > the resultant binaries if an issue does appear. Excellent, thanks! -- Nick Kew
Re: 1.6.0 release candidates
On Sat, 6 May 2017 22:49:50 -0700 Gregg Smith <g...@gknw.net> wrote: > The one difference I see between 1.5 and 1.6 is testpipe of 1.6 Platform? > Failed TestsTotal FailFailed % > === > testpipe9 1 11.11% > > testpipe: |Line 161: expected <0>, but saw <22> > FAILED 1 of 9 That's apr_file_pipe_timeout_set returning 22, which is presumably a system error. Unix and netware may return an errno from fcntl, and some beos (#if BEOS_BONE) might also return one from ioctl. Windows and OS2 have no error returns in that range, as far as I can tell. So what is errno 22 on your platform? Here it's EINVAL, unless some race condition has caught our scary use of errno. -- Nick Kew
Re: 1.6.0 release candidates
On Sat, 29 Apr 2017 12:23:52 +0100 Nick Kew <n...@apache.org> wrote: > > Failed TestsTotal FailFailed % > > === > > testdso 9 8 88.89% > > testprocmutex 6 3 50.00% > > testsock 16 2 12.50% > This is quite a lot to digest. Would it be fair to > assume that anything outside those failed tests is > unlikely to be an actual regression from 1.5.x? We're currently blocking on these. It would be good to unblock! I'm mostly concerned right now about whether any of those failures indicates a regression. I've worked through a diff against 1.5.2 (r1676021) and looked for changes to any of those modules that might conceivably be the cause of a regression. Here's what I find: 1. TESTDSO No changes whatsoever in code related to DSO 2. TESTSOCK: r1733452, r1733595. network_io/unix/sockopt.c: include/apr_network_io.h test/testsock.c Adds a case APR_SO_FREEBIND. This looks unlikely to be a regression candidate Is the new FREEBIND test one of the failures? Any clue about the other? 3. TESTPROCMUTEX locks/unix/proc_mutex.c locks/unix/global_mutex.c locks/unix/thread_cond.c include/apr_proc_mutex.h include/arch/unix/apr_arch_proc_mutex.h Extensive changes with (some) consequences already discussed. Any errors due to timedlock should be discounted: we'll add a release note about "don't use unless prepared to work on it". Are there any errors without timedlocks? BTW, we could use reports from Windows, Netware and Beos on what works for you. -- Nick Kew
Re: 1.6.0 release candidates
On Fri, 2017-04-28 at 11:35 -0500, William A Rowe Jr wrote: > ./configure --enable-timedlocks > > Right off the bat we find new rpm hokum in our configure; Where does the rpm_share come from? Isn't tar a complete red herring? And grep -R doesn't find init_baselib either. > make test is a bit of a mess, here are just the stderr observations; OK, actual errors are presumably the place to look for what might be actual regressions. In summary: > Failed TestsTotal FailFailed % > === > testdso 9 8 88.89% > testprocmutex 6 3 50.00% > testsock 16 2 12.50% > The less-than-straightforward build is due to crazy AIX > quirks convincing their xlc/ccs toolchains to emit anything > that is 64 bit on a 64 bit build box; You've evidently worked around it. Is that a fix you can apply in our build (from trunk or otherwise), or is it better left as a release note? > Failed TestsTotal FailFailed % > === > testdso 9 8 88.89% > testprocmutex 6 3 50.00% > testsock 16 2 12.50% So no change there. Good. > The obvious question, what is new since 1.5.2? New tests, > for one, new misbehavior as well; the prior results from > a recent product build with APR 1.5.2; This is quite a lot to digest. Would it be fair to assume that anything outside those failed tests is unlikely to be an actual regression from 1.5.x? -- Nick Kew
Re: 1.6.0 release candidates
On Wed, 2017-04-26 at 02:09 -0500, William A Rowe Jr wrote: > On Thu, Apr 20, 2017 at 12:36 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks > > good, > > at least, passes all tests, sysv sem timed locks discovered. Hopefully > > able to test in the next day or few. > > > With access restored, neither attempt is interesting/successful without > hints. I'll apply my usual platform-specific tweaks in the morning and > see if I get any more positive results, but am starting from a minimalist > approach rather than my seal-clubbing old-school angle on odd platforms. A minimalist approach is Good. But when you say minimalist, do you mean minimalist efforts as in "this should work out-of-the-box" or minimalist efforts as in a README.platform? Are we likely looking at more code commits? -- Nick Kew
Re: 1.6.0 release candidates
> On 20 Apr 2017, at 18:36, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks good, > at least, passes all tests, sysv sem timed locks discovered. Hopefully > able to test > in the next day or few. Do your platforms look good to go? Any more issues we should tackle? — Nick Kew
Re: 1.6.0 release candidates
> On 17 Apr 2017, at 13:01, Rainer Jung <rainer.j...@kippdata.de> wrote: > > c) Failure to compile apr on Solaris 8 > d) Hang during APR make check on Solaris 10 (testprocmutex) Rainer, are these issues now fixed for you, with Yann’s fixes to the source and my making timedlocks a config option now marked experimental? — Nick Kew
Re: 1.6.0 release candidates
On Wed, 2017-04-19 at 13:43 -0500, William A Rowe Jr wrote: > With patches now accounted for I can pre-test and report back today on > AIX, HPUX and propose a fix to silence the win32 32 -> 16 bit warnings > (after division is done.) Excellent. I look forward to your findings. > But my inclination is to defer this new feature to a later 1.7+2.0 > release. Shipping a feature that devs would expect to need when it may > be largely unavailable seems a disservice to our end users and these > devs. I'd be fine with that. Or with the intermediate solution of switching from a --disable to a --enable option so it's disabled by default but minimal change to enable in 1.6.later. Anyone else have strong views? -- Nick Kew
Re: 1.6.0 release candidates
On Tue, 18 Apr 2017 00:16:37 +0200 Yann Ylavic <ylavic@gmail.com> wrote: > > Unfortunately I was not (yet) able to find out, whether there's a > > patch for Bug 6738798 available on Solaris 10, or whether we would > > break Solaris 10. > > Maybe we need to "#define APR_USE_PROC_PTHREAD_MUTEX_COND 0" for > Solaris 10, and fall back to the generic implementation (spinning > sleep)... I've just (r1791932) made timedlocks a config option on unix-family. Defaults to on, but any users getting bitten by it can now use --disable-timedlocks and the timedlock function return APR_ENOTIMPL (as per earlier discussion, after being bitten by Mac but before Solaris versions joined the awkward squad). Given that two mainstream platforms have bitten us on this in the pre-release cycle, it would seem very high risk now to release without such a workaround. We can request that anyone who finds themselves having to use it report back to us! -- Nick Kew
Re: 1.6.0 release candidates
On Mon, 2017-04-17 at 17:06 +0100, Nick Kew wrote: >And I need to do some more digging > around that bogus PGP key! OK, this follows a subject that's been raised @apache before: https://mail-search.apache.org/members/private-arch/members/201606.mbox/%3c1464999260.7490.275.ca...@mimir.webthing.com%3E following which apache's own pages were fixed to stop using 32-bit key IDs. Underlying story is at https://evil32.com/ . I think I shall also blog this story and add my own thoughts. -- Nick Kew
Re: 1.6.0 release candidates
On Mon, 2017-04-17 at 14:01 +0200, Rainer Jung wrote: Thanks for the comments. > my test results: most important is failure to compile on Solaris 8 and a > hang during make test on Solaris 10, as well as your key seeming to be > revoked. See below. > > 1) Formal observations > == > > - MD5 and SHA1 missing Indeed. Do you think those should be encouraged, as they don't actually give any more security than a simple checksum? > - zip archives not named "win32-src.zip" as previously > - CHANGES-APR-1.6 and CHANGES-APR-UTIL-1.6 missing > - HEADER.html and README.html missing > - Announcement1.6.txt and Announcement1.6.html missing AFAICS those don't feature in the tarballs? I looked at the 1.5.latest of APR/APU and I don't see them. > - Key B87F79A9 missing from KEYS file Good point. Since ASF now auto-generates per-project keys files daily, why maintain a separate KEYS file? > - Key B87F79A9 is listed as "revoked: 2016-08-16" in key server I saw that key after uploading the tarballs! That key has a wrong creation date and wrong fingerprint: it's an imposter who created a clash (I recollect discussing that, though I only just found out that a fake with my name on it was "out there")! My real key is in http://people.apache.org/keys/group/apr.asc and http://people.apache.org/keys/committer/ (along with my old 1024-bit key, which I can also use if this is creating confusion). > - ".svn" directory included, that's unusual > - STATUS file included, that's unusual It's a fair cop, guv! > - Unix build files configure, *.spec, build-outputs.mk, build/*.sh, >build/l*.m4 (libtool m4 files) and the copies of the apr build/*.m4 >in apu are included in zip (that's new, but IMHO OK) Ah, right. Yep, that's probably not such a good idea. Do we in fact still need those in the Unix tarballs? Are there platforms out there with the toolchain for configure/make but not for buildconf? > - no more bundled expat: we need to note that in the release notes Agreed, that was certainly on the agenda for the announcement. > 2) Compile and run > == > > a) New apr configure options > b) Changes in apr-util configure options Useful for release notes :) > c) Failure to compile apr on Solaris 8 > -- Damn. That looks like a showstopper for release. But shouldn't be too hard, since you've tracked down the cause. > which indeed doesn't look like a good lvalue. Indeedie. > d) Hang during APR make check on Solaris 10 (testprocmutex) > --- > > pthread_mutex_timedlock() hangs when the > current thread already has > locked the mutex. Hmmm, OK. We knew the timedlock stuff had potential to blow up. I guess that points back to the plan of making it a config option. I'm out this evening, but will hopefully find time tomorrow to revisit these problems. And I need to do some more digging around that bogus PGP key! -- Nick Kew
1.6.0 release candidates
Today I have tagged both APR and APR-UTIL 1.6.0 and rolled tarballs of release candidates in the full choice of formats provided for 1.5.latest on our pages. Please download and test, from http://people.apache.org/~niq/apr/ -- Nick Kew
Re: Et resurrexit tertia die.
On Sat, 15 Apr 2017 07:11:10 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > 1.6 shouldn't wait, if you want to dive in Nick, go for it :) apr-1.6.0 tagged. Matching aprutil and tarballs to follow, hopefully this evening. Bring this thing up to date! -- Nick Kew
Re: Et resurrexit tertia die.
On Mon, 2017-04-10 at 10:40 +0100, Nick Kew wrote: > I think we've done most of 1.6.0, modulo a couple of questionmarks. > I'm thinking it would be good to roll an actual release in time > for the resurrection :) Contemplating tagging tomorrow or Saturday. Anyone wanting more time, please shout. Looking at the distributed packages, I see there's a separate Windows source bundle of 1.5. Is that just the same thing with CRLF line ends when unpacked, or is there some other difference? -- Nick Kew
Re: svn commit: r1790911 - in /apr/apr-util/branches/1.6.x: aprutil.dep aprutil.mak libaprutil.mak
On Tue, 2017-04-11 at 19:15 -0500, William A Rowe Jr wrote: > >>> remove dbd_freetds from .mak/dep > >> > >> I don't use it, but know it compiled at one time. What's the backstory > >> to this depreciation? > > > > http://svn.apache.org/r1789903 > > Thanks! See also http://mail-archives.apache.org/mod_mbox/apr-dev/201303.mbox/% 3C85CEA574-FF5E-4CCF-8676-731B59D8527D%40apache.org%3E (and search further if interested). Oh, and thanks Gregg. I thought I had grepped for all stray instances that didn't quite match the trunk action! -- Nick Kew
Re: buildbot success in on apr-x64-macosx-1.6.x
On Tue, 11 Apr 2017 20:03:34 +0200 Branko Čibej <br...@apache.org> wrote: > > APR trunk and 1.6.x on Ubunu and OSX > > APR-Util 1.6.x on Ubuntu > > And now also APR-Util 1.6.x on OSX. Also trunk? Is there a complete list of available platforms you're working through? -- Nick Kew
Et resurrexit tertia die.
I think we've done most of 1.6.0, modulo a couple of questionmarks. I'm thinking it would be good to roll an actual release in time for the resurrection :) Potentially open issues are (in no particular order): 1. Mark timedlocks experimental 2. Revisit default mutex methods 3. apr_file_copy perms fix 4. Backport object perms patch I've changed my mind on (1), and am happy to leave things as-is with recent patches. If they don't get out there, we won't get the feedback, as witness the fact we only noticed there was a problem when I test-drove on Mac. Regarding (2), I'm inclined to leave as-is. Tinker in trunk! Regarding (3), a fix is good but not a showstopper. (4) is the harder one. I've read through it and all looks fine, but it's too big to nod through comfortably, and I haven't attempted to devise a test case. My inclination is to leave it for now. Questions: - is there a (5) I've overlooked? - anyone want to shoot me down on (1) to (4)? - anyone want to shoot me down on rolling by Easter? - anyone want to claim the roll, or shall I? -- Nick Kew
Re: svn commit: r1790490 - in /apr/apr/branches/1.6.x: ./ include/ include/arch/unix/ locks/beos/ locks/netware/ locks/os2/ locks/unix/ locks/win32/ test/
On Fri, 2017-04-07 at 16:31 +0200, Yann Ylavic wrote:
> > Or are apr_{thread,proc,global}_mutex_timedlock() new to APR 1.6 and are
> > not part of 1.5.x and before?
>
> Yes that's the case (new to 1.6, not in 1.5), so no possible
> regression but for the braves running 1.6.x :)
For what it's worth, I went through the same thought process before
reading this thread. I found it harder/more confusing than it should
have been to verify that there was no such API in 1.5.
It would be great if viewvc could offer a branch-to-branch comparison!
--
Nick Kew
Re: 1.6 release timetable
On Fri, 17 Mar 2017 23:31:34 + Nick Kew <n...@apache.org> 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: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
On Wed, 5 Apr 2017 10:53:30 -0500 William A Rowe Jr <wr...@rowe-clan.net> wrote: > >> Howbout a --with-experimental-timedlocks config option ? > > > > +1 > > > > although anyone toggling an -experimental flag is expected > > to understand their resulting apr breaks binary compatibility. > > Or... do we stub them in all as APR_ENOTIMPL if the experimental > flag is not given? Sounds like a plan. Keep API/ABI compatible either way, get the new code some exposure, but only among users who ticked the disclaimer! -- Nick Kew
Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c
On Wed, 2017-04-05 at 08:11 -0500, William A Rowe Jr wrote: > > Maybe we should reconsider the whole idea of timedlocks?? > > Without throwing them out wholesale, in the interest of other 1.6.0 > enhancements, is it reasonable to keep developing this on 2.0-dev > trunk, and back it out entirely from 1.6.x branch for now? Howbout a --with-experimental-timedlocks config option ? > (Not sure > if forking 1.7.x from 1.6.x and then backing out from 1.6.x is the > simplest way to make that happen, but guessing it is.) Please, no 1.7 until 1.6-release is out of the door! We can then decide whether a 1.7 is needed, or whether the future can be 2.0 and bugfixes. -- Nick Kew
Re: By the way ...
On Wed, 2017-04-05 at 12:07 +0200, Branko Čibej wrote: > I don't find "the rest" of these log messages "more obvious" at all. Can > we please have log messages that are at least marginally descriptive of > the changes in the code, so that I don't have to run 'svn log --diff' to > understand what is going on. +1. When you're poring through years of history to try and understand why something is the way it is, log messages really matter! -- Nick Kew
Re: Default Linux mutex method
On Tue, 2017-04-04 at 10:07 +0200, Stefan Sperling wrote: > For APR 1.5.2 on OpenBSD 6.0 we have this: > (chop) Thanks. Every little helps. Looks identical to what we've seen on Linux and MacOSX platforms. Have platforms converged, or has our build rusted away? It would be interesting to see reports from more diverse platforms, including non-x86-based. Is anyone thinking of tinkering with this on a timescale for 1.6.0? If so, please make it a config option and default to existing options, on ain't-broke-don't-fix principles. -- Nick Kew
Re: svn commit: r1788334 - in /apr/apr/trunk: CHANGES include/apr_allocator.h memory/unix/apr_pools.c
On Mon, 2017-03-27 at 16:55 +0300, Ivan Zhakov wrote: > > + > > +/** > > + * Return the aligned (round up) size that an allocator would use for > > + * the given size. > > + * @param size The size to align > > + * @return The aligned size (or zero on apr_size_t overflow) > > + */ > > +APR_DECLARE(apr_size_t) apr_allocator_align(apr_size_t size); > What is the purpose of this API? Currently caller may use > apr_memnode_t.endp to find actually allocated memory size. > > Anyway I think it maybe worth to add apr_allocator_t argument to > apr_allocator_align() function even currently allocation alignment is > the same for all allocators. +1. If this is going anywhere as an API, it seems like a no-brainer. -- Nick Kew
Re: No timed lock on MacOS
>> Any insights? > > Hmm, doesn't MacOS have at least one of: > - sem_timedwait (posix) > - semtimedop (IPC SysV) > - pthread_mutex_timedlock (pthread) > ? sem_timedwait and semtimedop are not there. Config.log is clear on the subject, and googling seems to confirm it. For pthreads, APR_HAS_PROC_PTHREAD_SERIALIZE is 0 . This appears to be caused specifically by the test for pthread_mutex_timedlock failing. > What are your APR_USE_*_SERIALIZE? $ grep _SERIALIZE include/apr.h #define APR_USE_FLOCK_SERIALIZE 0 #define APR_USE_SYSVSEM_SERIALIZE 1 #define APR_USE_POSIXSEM_SERIALIZE0 #define APR_USE_FCNTL_SERIALIZE 0 #define APR_USE_PROC_PTHREAD_SERIALIZE0 #define APR_USE_PTHREAD_SERIALIZE 1 #define APR_HAS_FLOCK_SERIALIZE 1 #define APR_HAS_SYSVSEM_SERIALIZE 1 #define APR_HAS_POSIXSEM_SERIALIZE1 #define APR_HAS_FCNTL_SERIALIZE 1 #define APR_HAS_PROC_PTHREAD_SERIALIZE0 all of which is consistent with what’s happening. Googling hasn’t found any hint that any of those are available: just the occasional developer asking about them and getting no reply. I did find a suggested emulation, but I didn’t much like it. My inclination now is just to fix the test not to treat NOTIMPL as a fail. Looks like that’s r1733684 needs a bit of revision. — Nick Kew
fdatasync on mac
fdatasync on Mac is a mess. What I’ve been hacking at is described in https://bugs.freedesktop.org/show_bug.cgi?id=74873 where they face the same issue. My inclination is to steer clear of this mess. We can disable fdatasync on mac with a simple patch: $ svn diff Index: configure.in === --- configure.in(revision 1789687) +++ configure.in(working copy) @@ -573,6 +573,11 @@ OSDIR="unix" eolstr="\\n" ;; + *darwin* ) + ac_cv_func_fdatasync="no" # Mac OS X wrongly reports it has fdatasync() + OSDIR="unix" + eolstr="\\n" + ;; *) OSDIR="unix" eolstr="\\n” Comments? Objections? — Nick Kew
No timed lock on MacOS
Just (finally) got the toolchain up on the new macbook[1], so I’m testing there. Getting a failure in testprocmutex: there is no timedlock. ./testall -v testprocmutex testprocmutex : \default_timedlock() not implemented,-flock_timedlock() not implemented,|sysvsem_timedlock() not implemented,\posix_timedlock() not implemented,-fcntl_timedlock() not implemented,-Line 133: create the mutex default_timed not implemented,|Line 138: Default timed not implemented FAILED 1 of 6 Failed TestsTotal FailFailed % === testprocmutex 6 1 16.67% Any insights? — Nick Kew
Re: apr_file_copy with APR_FILE_SOURCE_PERMS not copying permissions if destination already exists
> On 30 Mar 2017, at 15:59, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > I'd suggest we treat it as a bug, change the behavior accordingly in 1.6.0, > and @bug the API to indicate the old vs new behavior. Thoughts? On reflection, +1 to all that. — Nick Kew
Re: Default Linux mutex method
> On 31 Mar 2017, at 03:21, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > So almost two decades later, this is still odd. Is this a reference to some technical discussion on the subject you recollect? Have you verified that all APR_USE_*_SERIALIZE are mutually exclusive, or could it be that we use both in different contexts, perhaps for a valid reason? > apr.h:#define APR_USE_SHMEM_MMAP_TMP 0 > apr.h:#define APR_USE_SHMEM_MMAP_SHM 0 > apr.h:#define APR_USE_SHMEM_MMAP_ZERO0 > apr.h:#define APR_USE_SHMEM_SHMGET_ANON 0 > apr.h:#define APR_USE_SHMEM_SHMGET 1 > apr.h:#define APR_USE_SHMEM_MMAP_ANON1 > apr.h:#define APR_USE_SHMEM_BEOS 0 > apr.h:#define APR_USE_FLOCK_SERIALIZE 0 > apr.h:#define APR_USE_SYSVSEM_SERIALIZE 1 > apr.h:#define APR_USE_POSIXSEM_SERIALIZE0 > apr.h:#define APR_USE_FCNTL_SERIALIZE 0 > apr.h:#define APR_USE_PROC_PTHREAD_SERIALIZE0 > apr.h:#define APR_USE_PTHREAD_SERIALIZE 1 I’ve just (finally) got the toolchain to build & test this on MacOS, and I’ve got identical APR_USE results there. Perhaps our build logic really isn’t doing anything very smart at all? > SYSVSEM > PTHREAD in the code logic, so we are still using > sysv semaphores with all their defects over the choice of pthread > mutexes where both are supported on Linux. Probably applies more widely than just Linux. But might a general fix risk breaking some minority Unix platform or cross-compile? > Do we want to fix this in the 1.6.0 release? How confident are you of not breaking anything with a fix? — Nick Kew
Re: apr_file_copy with APR_FILE_SOURCE_PERMS not copying permissions if destination already exists
On Thu, 2017-03-30 at 09:59 -0500, William A Rowe Jr wrote: > > Is this the expected behaviour? should documentation warn that if the > > destination already exists, then permissions will not be copied even with > > that flag? > > Since we make no statement either way I wouldn't call this 'expected'. > > The linux behavior of cp -p differs from the APR 1.5.x and earlier behavior. Is Linux in any sense definitive? Is there any standard with unix roots (or even from the Windows world)? Does the flag mirror anything from stdio & friends ? -- Nick Kew
