uestion 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
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
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
se 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
d 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
> 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
see the offending page seems to have gone, so
presumably either the Cc: to infra@ or someone else did the job!
--
Nick Kew
re.
Anyone from infra@ watch our bugzilla?
--
Nick Kew
> 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 partia
is still broken.
Whoops! I'd completely forgotten that.
Thanks for the partial patch. Do you want to commit it?
--
Nick Kew
> 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
>>
.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
s:
> * 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 th
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 t
> 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
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
ongside 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
rty 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
rom an external contributor, which I hope to find time to review
in time for APR-UTIL 1.7.
--
Nick Kew
rently my only dev platform).
Thanks, Bill.
--
Nick Kew
or the reminder!
Does trunk compile for you in the same circumstances?
This is supposed to be a backport!
--
Nick Kew
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
ml 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
riptor 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
> 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
ks 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
+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
change this in 1.6, but open to something for 1.7.
I may comment on the bugzilla report.
--
Nick Kew
en 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
h applies, so this isn't of immediate concern. But yes, it
looks like
something we should patch for future releases.
--
Nick Kew
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
r do you have some other interest?
--
Nick Kew
d make sense.
--
Nick Kew
ought 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
ither way. In the unlikely event that it blows up,
it's the tests, not someone's production system.
--
Nick Kew
tion testing belong in 1.7,
along with the crypto updates and possibly the json from amongst
what's been happening on trunk.
--
Nick Kew
ewing).
> Btw, this commit probably needs to go to trunk too.
Agreed. And 1.7. Will do - unless you get there first.
--
Nick Kew
ce 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
that much more readable and put the substance inside the loop?
for (i …) {
if (!comp(…)) {
set *index;
set return value;
break;
}
}
—
Nick Kew
list 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
nt 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
[ ] +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
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
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
ometime 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
d 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
Build options changed from 1.5 to 1.6 and may
change again. So you might update your build.
--
Nick Kew
r 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
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
Do you also
use APR directly somewhere I didn't notice it?
--
Nick Kew
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
d for the benefit of packagers.
>From memory, haven't you magicked up an extra .m4 there?
--
Nick Kew
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
welcome.
--
Nick Kew
gure/make, perhaps that would help users of minority
systems to set up automated testing?
--
Nick Kew
when the new releases become officially current.
--
Nick Kew
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-uti
ll (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
6 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
my own +1 to both.
--
Nick Kew
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 Releas
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
or two before I'm
fit for any such thing.
--
Nick Kew
,
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
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
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
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 orde
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 alter
g for expat,
you would seem to have found a bug.
Thanks for test-driving.
--
Nick Kew
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
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
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
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
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
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
Do your platforms look good to go? Any more issues we should tackle?
—
Nick Kew
ks a config option now marked experimental?
—
Nick Kew
itching 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
karound. We can request that anyone who finds
themselves having to use it report back to us!
--
Nick Kew
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.
t 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
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
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
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, ple
che.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
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
:
- 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
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
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
eir 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
e door!
We can then decide whether a 1.7 is needed, or whether the
future can be 2.0 and bugfixes.
--
Nick Kew
--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
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
o
> 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
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
ac OS X wrongly reports it has fdatasync()
+ OSDIR="unix"
+ eolstr="\\n"
+ ;;
*)
OSDIR="unix"
eolstr="\\n”
Comments? Objections?
—
Nick Kew
%
===
testprocmutex 6 1 16.67%
Any insights?
—
Nick Kew
> 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
x
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
ther 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
1 - 100 of 392 matches
Mail list logo
