[Graham please use plain text emails or at least fix your MUA so that
one does not need to re-quote/format your messages when replying in
plain text]
On Wed, Apr 24, 2024 at 7:51 PM Graham Leggett wrote:
>
> On 24 Apr 2024, at 14:03, Yann Ylavic wrote:
>>
>> Here in apr_b
On Wed, Apr 24, 2024 at 3:03 PM Yann Ylavic wrote:
>
> APR_DECLARE(int) apr_buffer_cmp(const apr_buffer_t *src,
> const apr_buffer_t *dst)
> {
> apr_size_t slen, dlen;
>
> if (!src) {
> return dst ? 1 : 0;
> }
>
On Mon, Apr 22, 2024 at 2:46 PM wrote:
>
> --- apr/apr/trunk/buffer/apr_buffer.c (original)
> +++ apr/apr/trunk/buffer/apr_buffer.c Mon Apr 22 12:46:37 2024
> @@ -28,7 +28,7 @@
> #include "apr_strings.h"
> #include "apr_private.h"
>
> -#define APR_BUFFER_MAX APR_SIZE_MAX/2
> +#define
On Tue, Apr 16, 2024 at 10:54 PM wrote:
>
> --- apr/apr/trunk/buffer/apr_buffer.c (added)
> +++ apr/apr/trunk/buffer/apr_buffer.c Tue Apr 16 20:54:51 2024
> @@ -0,0 +1,408 @@
> +
> +APR_DECLARE(apr_buffer_t *) apr_buffer_mem_make(apr_pool_t *pool,
> +
On Thu, Apr 18, 2024 at 3:58 PM Graham Leggett wrote:
>
> On 18 Apr 2024, at 13:15, Yann Ylavic wrote:
>
>> But let me plead again for a much simpler ->size of type apr_size_t,
>> checked against APR_BUFFER_MAX=APR_SIZE_MAX/2 wherever an apr_buffer_t
>> is i
On Thu, Apr 18, 2024 at 4:41 PM Yann Ylavic wrote:
>
> could be:
> APR_DECLARE(apr_status_t) apr_buffer_str_set(apr_buffer_t *buf,
> char *str, apr_size_t len)
> {
> if (len == APR_BUFFER_STRING) {
> len =
On Thu, Apr 18, 2024 at 3:58 PM Graham Leggett wrote:
>
> On 18 Apr 2024, at 13:15, Yann Ylavic wrote:
>
>> Indeed at least APR_BUFFER_MAX and buf->size of should be of the same
>> signedness.
>
>
> APR_BUFFER_MAX represents the size limit visible outside the AP
On Thu, Apr 18, 2024 at 1:16 PM Ruediger Pluem wrote:
>
> On 4/18/24 12:37 AM, minf...@apache.org wrote:
> > Author: minfrin
> > Date: Wed Apr 17 22:37:07 2024
> > New Revision: 1917082
> >
> > URL: http://svn.apache.org/viewvc?rev=1917082=rev
> > Log:
> > apr_buffer: Add explicit casts on all
On Wed, Apr 17, 2024 at 9:36 AM Graham Leggett via dev
wrote:
>
> On 17 Apr 2024, at 08:12, Ruediger Pluem wrote:
>
> >> I need some advice on handling Windows 32 bit. apr_int64_t for size is too
> >> big, and tests are failing.
> >>
> >> Technically apr_ssize_t is the right size, but the
On Mon, Mar 18, 2024 at 2:11 PM Joe Orton wrote:
>
> On Fri, Mar 15, 2024 at 10:26:27AM -, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Fri Mar 15 10:26:27 2024
> > New Revision: 1916332
> >
> > URL: http://svn.apache.org/viewvc?rev=1916332=rev
> > Log:
> > testescape: missing ';' in
On Mon, Mar 18, 2024 at 10:00 AM Ruediger Pluem wrote:
>
> On 3/15/24 2:35 PM, yla...@apache.org wrote:
> >
> > -#if defined(offsetof) && !defined(__cplusplus)
> > +#if defined(__has_builtin) && __has_builtin(__builtin_offsetof)
>
> This causes an
>
> ./include/apr_general.h:109:45: error:
dev@ team,
I'm wondering if we could/should remove APR_POOL_DEBUG specifics in
apr-util 1.6.x and 1.7.x, otherwise it's not possible run
non-pool-debug apr-util with pool-debug apr.
Fortunately the only dependency on APR_POOL_DEBUG for apr-util seems
to be the apr_bucket code below.
On Thu, Feb
On Thu, Feb 1, 2024 at 2:38 PM Simon Walter wrote:
>
> I had partial success with '--enable-pool-debug=yes' and
> '--enable-pool-debug=verbose'. Then I ran into something else regarding
> apr-util. I see there are pre-processor conditions based on APR_POOL_DEBUG.
Yes, you need to both apr and
On Wed, Jan 31, 2024 at 7:44 PM Simon Walter wrote:
>
> My question about how to debuging should be done. abort() is called on
> apr_initialize():
>
> Program received signal SIGABRT, Aborted.
Does the attached patch fix the issue with apr_initialize()?
Regards;
Yann.
Index:
On Thu, Feb 1, 2024 at 1:56 PM Yann Ylavic wrote:
>
> On Wed, Jan 31, 2024 at 7:44 PM Simon Walter wrote:
> >
> > Should I use '--enable-pool-debug=yes' or '--enable-pool-debug=verbose'?
>
> I'd suggest using simple --enable-pool-debug[=yes] and ASan (Address
>
On Wed, Jan 31, 2024 at 7:44 PM Simon Walter wrote:
>
> Should I use '--enable-pool-debug=yes' or '--enable-pool-debug=verbose'?
I'd suggest using simple --enable-pool-debug[=yes] and ASan (Address
Sanitizer, i.e. "-fsanitize=address -fno-sanitize-recover=address" in
$CFLAGS).
Regards,
Yann.
On Mon, Oct 16, 2023 at 11:41 AM Rainer Jung wrote:
>
> This problem is in 1.7.x and 1.8.x. I did not check apr trunk.
Looks like apr_private_common.h does not exist in trunk (anymore?).
>
> Unfortunately I have no idea how to make autoheader to use
>
> #include "arch/apr_private_common.h"
>
>
On Fri, Sep 29, 2023 at 3:39 PM wrote:
>
> Author: jorton
> Date: Fri Sep 29 13:39:11 2023
> New Revision: 1912607
[]
> --- apr/apr/trunk/dbm/apr_dbm_lmdb.c (added)
> +++ apr/apr/trunk/dbm/apr_dbm_lmdb.c Fri Sep 29 13:39:11 2023
[]
> +static apr_status_t vt_lmdb_open(apr_dbm_t **pdb, const char
On Thu, Apr 13, 2023 at 1:08 PM Yann Ylavic wrote:
>
> On Thu, Apr 13, 2023 at 1:02 PM Eric Covener wrote:
> >
> > New for this release we are only toggling it on the release tag (sic),
> > similar to httpd release process.
>
> Maybe a bump (to 1.7.5 here) is miss
On Thu, Apr 13, 2023 at 4:25 AM Eric Covener wrote:
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball apr-1.7.4-rc1 as 1.7.4:
[X] +1: It's not just good, it's good enough!
All tests pass on Debian 11 and 12, sums/sigs/version/dirname OK.
Thanks Eric for
On Thu, Apr 13, 2023 at 1:02 PM Eric Covener wrote:
>
> New for this release we are only toggling it on the release tag (sic),
> similar to httpd release process.
Maybe a bump (to 1.7.5 here) is missing in 1.7.x after tagging now?
Currently apr_version.h is still at 1.7.4-dev it seems.
On Thu, Apr 13, 2023 at 12:16 PM SteffenAL wrote:
>
> it's me. I build from svn, and there is :
>
> #define APR_IS_DEV_VERSION
Yeah, this is restored immediately after tagging to not let a branch
in a "release" state.
You could checkout tags/apr-1.7.4-rc1 rather than branches/1.7.x for
testing,
On Thu, Apr 13, 2023 at 12:15 PM Evgeny Kotkov
wrote:
>
> Yann Ylavic writes:
>
> > Do we want to include r1909117 in 1.7.4 (to call abort() instead of
> > assert() in apr_base64 when NDEBUG)?
> > Sorry for the lateness, but should there be an -rc2 (or in any case..)
On Thu, Apr 13, 2023 at 10:47 AM Evgeny Kotkov via dev
wrote:
>
> Eric Covener writes:
>
> > I will RM but it might be a bit piecemeal between now and the weekend.
> > At the mercy of a lot of inflexible $bigco stuff.
> >
> > Hoping to improve a little this time by porting more of icings
On Thu, Apr 13, 2023 at 9:38 AM SteffenAL wrote:
>
> It is identified as 1.7.4-dev
>
> In apr_version.h dev version is defined.
I don't see this in the release candidate tarballs (.gz or .bz2),
apr_version.h contains:
/* #undef APR_IS_DEV_VERSION */
so it should not include the "-dev" suffix in
On Wed, Mar 29, 2023 at 1:04 PM Evgeny Kotkov via dev
wrote:
>
> Yann Ylavic writes:
>
> > +#undef NDEBUG /* always abort() on assert()ion failure */
> > +#include
>
> Sorry for being late to the party, but I think there are a few problems with
> the "#u
Hi Rainer;
On Mon, Mar 27, 2023 at 2:02 PM Rainer Jung wrote:
>
> Am 18.03.23 um 17:33 schrieb yla...@apache.org:
> >
> > @@ -113,15 +112,13 @@ AC_DEFUN([APU_CHECK_CRYPTO_OPENSSL], [
> > AC_MSG_NOTICE(checking for openssl in $withval)
> > AC_CHECK_HEADERS(openssl/x509.h,
On Mon, Mar 27, 2023 at 10:18 AM Ruediger Pluem wrote:
>
> 1.7.3-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.3
[X] +1 looks great!
Tested on Debian 11 and 12.
All good with:
apr_lock_method=USE_PROC_PTHREAD_SERIALIZE
--enable-nonportable-atomics=yes
On Fri, Mar 24, 2023 at 3:56 PM Ruediger Pluem wrote:
>
> Is someone opposed if I put an APR 1.7.x release for vote on the beginning of
> next week?
> It would be my first APR release, but I think I should be able to do it with
> the instructions in release.sh (thanks Eric).
> Otherwise I will
On Tue, Mar 21, 2023 at 2:24 PM Yann Ylavic wrote:
>
> Is there something I can #ifdef (or check at configure/run time) for
> SLELS11 or the kernel? This would document in the test that a minimal
> timeout is usually expected, but on this platform/kernel. Or I'll use
> 190ms for
Hi Rainer;
On Mon, Mar 20, 2023 at 10:31 PM Rainer Jung wrote:
>
> Am 17.03.23 um 15:11 schrieb Yann Ylavic:
> >
> > Hm OK, these commits were meant to address that precisely..
> > It looks like SLES has some special epoll_wait() implementation that
> > can return
On Fri, Mar 17, 2023 at 9:23 AM Ruediger Pluem wrote:
>
> On 3/16/23 1:43 PM, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Thu Mar 16 12:43:17 2023
> > New Revision: 1908433
> >
> > URL: http://svn.apache.org/viewvc?rev=1908433=rev
> > Log:
> > apr_crypto_openssl: Compatibility with
On Thu, Mar 16, 2023 at 5:53 PM Ruediger Pluem wrote:
>
> On 3/16/23 1:43 PM, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Thu Mar 16 12:43:17 2023
> > New Revision: 1908433
> >
> > URL: http://svn.apache.org/viewvc?rev=1908433=rev
> > Log:
> > apr_crypto_openssl: Compatibility with
On Fri, Mar 17, 2023 at 2:30 PM Rainer Jung wrote:
>
> Am 17.03.23 um 14:12 schrieb Yann Ylavic:
> > On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung
> > wrote:
> >>
> >> But: testpoll fails:
> >>
> >> testpoll: Line 897: apr_polls
On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung wrote:
>
> But: testpoll fails:
>
> testpoll: Line 897: apr_pollset_poll() didn't sleep
>
> Unfortunately I don't know when it started. Any idea, what I should
> investigate?
>
> All this is on SLES11, haven't tried the recent APR trunk
On Thu, Mar 16, 2023 at 2:53 PM Ivan Zhakov wrote:
>
> I have very little knowledge about autoconf stuff. The autoconf part was
> suggest by Yann in [1]
>
> Yann: do you have any ideas why it does not work?
Does r1908438 fix it for you Rainer?
Regards;
Yann.
Hi Stefan;
On Sun, Feb 5, 2023 at 9:44 PM Stefan Fritsch wrote:
>
>
> On powerpc we got a segfault:
[]
> Fixed in http://svn.apache.org/viewvc?view=revision=1907442 .
[]
>
> On armel, we got a link error:
>
> /usr/bin/ld: ../.libs/libapr-1.so: undefined reference to
> `__atomic_fetch_sub_8'
>
On Tue, Jan 31, 2023 at 10:23 PM Eric Covener wrote:
>
> I hosed 1.7.1/1.6.2 and the archives have -rcX in them at the top
> level. I would like to call for an expedited vote to replace them
> with version bumps. I will proceed once we get 3 binding +1.
>
> I have re-tagged because I think the
Argh, this vote was actually meant for apr-util-1.6.2-rc2 :/
Nevermind, my +1 for apr-util-1.6.2-rc3 on the other thread anyway.
On Wed, Jan 25, 2023 at 4:10 PM Yann Ylavic wrote:
>
> On Fri, Jan 20, 2023 at 1:44 AM Eric Covener wrote:
> >
> > 1.7.1-rc1 is here:
> >
&g
On Fri, Jan 27, 2023 at 2:42 PM Eric Covener wrote:
>
> 1.6.2-rc3 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-util-1.6.2
[X] +1 looks great
Debian 11 & 12. Did not test the new mariadb bits specifically.
Thanks Eric.
Regards;
Yann.
On Fri, Jan 20, 2023 at 1:44 AM Eric Covener wrote:
>
> 1.7.1-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1
[X] +1 looks great!
Testing on Debian 11 and 12+ (bookwork/sid) using apr-1.7.1(-rc2).
No test failure, checksum/signature ok.
Thanks Eric!
On Fri, Jan 20, 2023 at 1:44 AM Eric Covener wrote:
>
> For the release of apr-1.7.1
[X] +1 looks great!
apr-1.7.1-rc2 tested on Debian 11 and 12+ (bookwork/sid).
All good with:
apr_lock_method=USE_PROC_PTHREAD_SERIALIZE
--enable-nonportable-atomics=yes
--enable-posix-shm
Thanks a lot
On Mon, Jul 25, 2022 at 12:43 PM Ruediger Pluem wrote:
>
>
>
> On 6/23/22 8:49 PM, Ruediger Pluem wrote:
> >
> >
> > On 6/23/22 5:12 PM, yla...@apache.org wrote:
> >> Author: ylavic
> >> Date: Thu Jun 23 15:12:47 2022
> >> New Revision: 1902206
> >
> >
> >> @@ -275,16 +284,17 @@ APR_DECLARE(int)
On Tue, Jul 12, 2022 at 12:46 PM Ivan Zhakov wrote:
>
> On Wed, 29 Jun 2022 at 01:28, Yann Ylavic wrote:
> >
> > On Tue, Jun 28, 2022 at 6:08 PM Ivan Zhakov wrote:
> > > >
> > > I meant a memory leak for native threads. For example, with an MPM
&g
On Fri, Jul 1, 2022 at 1:35 PM Evgeny Kotkov
wrote:
>
> Yann Ylavic writes:
>
> > Why would buffered reads always be full reads (i.e. until the given
> > size of EOF)?
> >
> > For apr_file_read() I don't think this is expected, users might want
> > r
On Fri, Jul 1, 2022 at 11:14 AM Ivan Zhakov wrote:
>
> On Fri, 1 Jul 2022 at 01:10, Yann Ylavic wrote:
> >
> > On Fri, Jul 1, 2022 at 12:00 AM Yann Ylavic wrote:
> > >
> > > On Thu, Jun 30, 2022 at 7:28 PM wrote:
> > > >
> > > > Aut
On Fri, Jul 1, 2022 at 12:00 AM Yann Ylavic wrote:
>
> On Thu, Jun 30, 2022 at 7:28 PM wrote:
> >
> > Author: ivan
> > Date: Thu Jun 30 17:28:50 2022
> > New Revision: 1902378
> >
> > URL: http://svn.apache.org/viewvc?rev=1902378=rev
> > Lo
On Thu, Jun 30, 2022 at 7:28 PM wrote:
>
> Author: ivan
> Date: Thu Jun 30 17:28:50 2022
> New Revision: 1902378
>
> URL: http://svn.apache.org/viewvc?rev=1902378=rev
> Log:
> On 1.8.x branch: Merge r1806299, r1806301, r1806308, r1806610:
> *) apr_file_write: Optimize large writes to buffered
On Thu, Jun 30, 2022 at 6:19 PM wrote:
>
> Author: ivan
> Date: Thu Jun 30 16:18:51 2022
> New Revision: 1902375
>
> URL: http://svn.apache.org/viewvc?rev=1902375=rev
> Log:
> On 1.8.x branch: Merge r1785072, r1788930 from trunk:
> *) apr_file_gets: Optimize for buffered files on Windows.
>
On Wed, Jun 29, 2022 at 4:49 PM William A Rowe Jr wrote:
>
> The eventual change still is present for apr
> 1.8 adopters.
>
> Thoughts? ylavic are you willing to revert?
It seems that no one is using apr_mmap_create() with an offset != 0 or
the bug would have been reported (PR 65158 proved to be
On Wed, Jun 29, 2022 at 6:09 PM Yann Ylavic wrote:
>
> By making such impracticable policies for revision changes (semver
> sense), we are going to simply not fix anything but trivial changes
> without bumping minor, and no one would/should care about the old
> (though still &quo
On Wed, Jun 29, 2022 at 4:47 PM William A Rowe Jr wrote:
>
> This change does introduce an API change, and a somewhat possibly dangerous
> structure size alteration, and seems to be out of bounds for apr 1.7.x branch.
AFAICT, this change only touches internal/opaque structures..
Are you talking
On Wed, Jun 29, 2022 at 4:41 PM William A Rowe Jr wrote:
>
> This is the first commit which appeared to break APR in such a way
> that code compiled
> against apr 1.7.1 would be unable to run against apr 1.7.0 binaries.
I think it has been reverted already by http://svn.apache.org/r1902022
On Tue, Jun 28, 2022 at 6:08 PM Ivan Zhakov wrote:
>
> On Tue, 28 Jun 2022 at 00:24, Yann Ylavic wrote:
> >
> > Hi Ivan,
> >
> > On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov wrote:
> > >
> > > For the longer version, let me first outline a few pro
On Tue, Jun 28, 2022 at 9:24 PM Eric Covener wrote:
>
> Ran out of time but I added a crude check to the branch in 1902326.
Argh, I missed your message (which showed up after I sent mine..).
Well, two solutions are better than none :)
On Tue, Jun 28, 2022 at 8:06 PM Ivan Zhakov wrote:
>
> On Tue, 28 Jun 2022 at 14:45, Yann Ylavic wrote:
> >
> > On Tue, Jun 28, 2022 at 1:13 AM wrote:
> > >
> > > Author: ivan
> > > Date: Mon Jun 27 23:13:52 2022
> > > New Revision: 190
On Tue, Jun 28, 2022 at 1:53 PM Ivan Zhakov wrote:
>
> On Tue, 28 Jun 2022 at 14:08, wrote:
> >
> > Author: ylavic
> > Date: Tue Jun 28 11:08:32 2022
> > New Revision: 1902312
> >
> > URL: http://svn.apache.org/viewvc?rev=1902312=rev
> > Log:
> > apr_socket_sendv: WIN32: Limit the number of
On Tue, Jun 28, 2022 at 1:13 AM wrote:
>
> Author: ivan
> Date: Mon Jun 27 23:13:52 2022
> New Revision: 1902297
>
> URL: http://svn.apache.org/viewvc?rev=1902297=rev
> Log:
> On 'thread-name' branch: Add apr_thread_name_get() and apr_thread_name_set()
> API to get/set thread name.
>
[]
> ---
Hi Ivan,
On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov wrote:
>
> For the longer version, let me first outline a few problems with the current
> apr_thread_current() API:
>
> 1) apr_thread_current_create() leaks the memory allocated in alloc_thread()
> after the thread exits.
Hm, alloc_thread()
On Mon, Jun 27, 2022 at 8:35 PM Ivan Zhakov wrote:
>
> On Mon, 27 Jun 2022 at 21:14, Yann Ylavic wrote:
>>
>> On Mon, Jun 27, 2022 at 8:08 PM Ivan Zhakov wrote:
>> >
>> > On Mon, 27 Jun 2022 at 21:01, wrote:
>> >>
>> >> +#ifdef W
On Mon, Jun 27, 2022 at 8:08 PM Ivan Zhakov wrote:
>
> On Mon, 27 Jun 2022 at 21:01, wrote:
>>
>> +#ifdef WIN32
>> +typedef apr_status_t (__stdcall *encdec_fn)(char*, const char*,
>> apr_ssize_t, int, apr_size_t*);
>> +#else
>> +typedef apr_status_t (*encdec_fn)(char*, const char*, apr_ssize_t,
On Mon, Jun 27, 2022 at 6:14 PM Yann Ylavic wrote:
>
> On Mon, Jun 27, 2022 at 5:26 PM wrote:
> >
> > Author: ylavic
> > Date: Mon Jun 27 15:26:09 2022
> > New Revision: 1902281
> >
> > URL: http://svn.apache.org/viewvc?rev=1902281=rev
> > Log:
On Mon, Jun 27, 2022 at 5:26 PM wrote:
>
> Author: ylavic
> Date: Mon Jun 27 15:26:09 2022
> New Revision: 1902281
>
> URL: http://svn.apache.org/viewvc?rev=1902281=rev
> Log:
> encoding: Better check inputs of apr_{encode,decode}_* functions.
This commit seems to cause a segfault on Windows
On Sat, Jun 25, 2022 at 6:34 PM Christophe JAILLET
wrote:
>
> Le 24/06/2022 à 11:06, yla...@apache.org a écrit :
> >
> > --- apr/apr/branches/1.8.x/test/testlock.c (original)
> > +++ apr/apr/branches/1.8.x/test/testlock.c Fri Jun 24 09:06:05 2022
> > @@ -111,6 +111,7 @@ static void
Daniel proposed in [1] that we introduce apr_atomic_casptr2() to
resolve the defect in the apr_atomic_casptr() API.
Namely the correct:
1. APR_DECLARE(void*) apr_atomic_casptr(void *volatile *mem, ...);
Versus the broken:
2. APR_DECLARE(void*) apr_atomic_casptr(volatile void **mem, ...);
The
On Wed, Jun 22, 2022 at 2:26 PM Ivan Zhakov via dev wrote:
>
> Suggestions and improvements are welcome.
I don't see any warning left in trunk and 1.8.x, possibly we'd have a
Windows /Werror build (or whatever appropriate msvc toggle is) to
better check the ones that would be introduced?
On Fri, Jun 24, 2022 at 11:56 AM Yann Ylavic wrote:
>
> On Thu, Jun 23, 2022 at 8:50 PM Ruediger Pluem wrote:
> >
> > On 6/23/22 5:12 PM, yla...@apache.org wrote:
> > >
> > > +/* Above APR_BASE64_ENCODE_MAX length the encoding can't fit in
On Thu, Jun 23, 2022 at 8:50 PM Ruediger Pluem wrote:
>
> On 6/23/22 5:12 PM, yla...@apache.org wrote:
> >
> > +/* Above APR_BASE64_ENCODE_MAX length the encoding can't fit in an int >=
> > 0 */
> > +#define APR_BASE64_ENCODE_MAX 1610612733
> > +
> > +/* Above APR_BASE64_DECODE_MAX length the
On Thu, Jun 23, 2022 at 5:57 PM Ruediger Pluem wrote:
>
> On 6/23/22 1:43 PM, yla...@apache.org wrote:
> >
> > --- apr/apr/trunk/json/apr_json_decode.c (original)
> > +++ apr/apr/trunk/json/apr_json_decode.c Thu Jun 23 11:43:05 2022
> > @@ -353,7 +353,7 @@ static apr_status_t apr_json_decode_arra
On Thu, Jun 23, 2022 at 1:55 AM Eric Covener wrote:
>
> On Wed, Jun 22, 2022 at 7:53 PM Yann Ylavic wrote:
> >
> > On Thu, Jun 23, 2022 at 1:14 AM Eric Covener wrote:
> > >
> > > On Wed, Jun 22, 2022 at 10:30 AM Yann Ylavic wrote:
> > > >
> &g
On Thu, Jun 23, 2022 at 1:14 AM Eric Covener wrote:
>
> On Wed, Jun 22, 2022 at 10:30 AM Yann Ylavic wrote:
> >
> > On Wed, Jun 22, 2022 at 2:26 PM Ivan Zhakov via dev
> > wrote:
> > >
> > > As far I understand Apache Infra recommends to migrate Contin
On Wed, Jun 22, 2022 at 5:57 PM Ivan Zhakov wrote:
>
> On Wed, 22 Jun 2022 at 17:29, Yann Ylavic wrote:
>
>>
>> PS: now the macos guys have some work
>> (https://github.com/apache/apr/runs/7004338300?check_suite_focus=true)
>> :)
>
>
> Also testr
On Wed, Jun 22, 2022 at 2:26 PM Ivan Zhakov via dev wrote:
>
> As far I understand Apache Infra recommends to migrate Continuous Integration
> builds from Travis to GitHub Actions.
>
> I've added initial configuration for GitHub Actions for APR project:
>
On Wed, Jun 22, 2022 at 12:35 AM Ivan Zhakov wrote:
>
> I see two runs for every commit, but one is for Windows and another is for
> Linux. Do I miss something?
No, brain fart all along on my side..
Regards;
Yann.
On Tue, Jun 21, 2022 at 6:21 PM Ivan Zhakov wrote:
>
> On Tue, 21 Jun 2022 at 19:16, Yann Ylavic wrote:
>>
>> On Tue, Jun 21, 2022 at 5:58 PM Ivan Zhakov wrote:
>> >
>> > On Tue, 21 Jun 2022 at 18:33, Yann Ylavic wrote:
>> >>
>> >> Hi
On Tue, Jun 21, 2022 at 5:58 PM Ivan Zhakov wrote:
>
> On Tue, 21 Jun 2022 at 18:33, Yann Ylavic wrote:
>>
>> Hi Ivan,
>>
>> I'm responding randomly to one of your ci commits, first to say
>> thanks, really nice and valuable work!
>>
>> I have a
Hi Ivan,
I'm responding randomly to one of your ci commits, first to say
thanks, really nice and valuable work!
I have a question too :) Sorry if it's premature, but I'm also
wondering why we don't see the outputs of the jobs in the github UI,
for instance in [1] for both succeeding and failing
On Mon, Jun 20, 2022 at 11:57 PM wrote:
>
> Author: ivan
> Date: Mon Jun 20 21:57:13 2022
> New Revision: 1902120
>
> URL: http://svn.apache.org/viewvc?rev=1902120=rev
>
[]
> --- apr/apr/branches/1.8.x/test/testfile.c (original)
> +++ apr/apr/branches/1.8.x/test/testfile.c Mon Jun 20 21:57:13
Hi,
On Mon, Mar 28, 2022 at 2:50 PM Ramapandi Muniyasamy -X (ramapmun -
WIPRO LIMITED at Cisco) wrote:
>
> I am getting a crash when I am newly migrating to openssl 1.1.1l with version
> 2.4.39
You need to re-build httpd with the new openssl (./configure
--with-openssl=/path/to/openssl 1.1.1l
On Tue, Feb 8, 2022 at 7:56 PM Evgeny Kotkov
wrote:
>
> Yann Ylavic writes:
>
> > +APR_DECLARE(apr_status_t) apr_thread_current_create(apr_thread_t **current,
> > +a
On Thu, Jan 20, 2022 at 4:37 PM Yann Ylavic wrote:
>
> On Thu, Jan 20, 2022 at 3:56 PM William A Rowe Jr wrote:
> >
> > On Thu, Jan 20, 2022 at 8:50 AM Eric Covener wrote:
> > >
> > > > Code that will compile on 1.7.1 release
> > > > s
On Thu, Jan 20, 2022 at 3:56 PM William A Rowe Jr wrote:
>
> On Thu, Jan 20, 2022 at 8:50 AM Eric Covener wrote:
> >
> > > Code that will compile on 1.7.1 release
> > > still won't compile on 1.7.0, unless I misunderstand something.
> >
> > Is it a requirement in this direction?
> >
On Thu, Jan 13, 2022 at 7:04 PM Ivan Zhakov wrote:
>
> On Fri, 7 Jan 2022 at 17:33, Yann Ylavic wrote:
> >
> > I think that most if not all of the changes to 1.7.x since 1.7.0 are
> > fixes for bugs that were there before 1.7 already, not regressions
> > i
On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr wrote:
>
> A quick review of nm against libapr-1.so between 1.7.0 and 1.7.x
> indicates that 1.7.1
> isn't releasable as-is. Any hints?
>
> +T apr_pool_find
> +T apr_pool_join
> +T apr_pool_lock
> +T apr_pool_num_bytes
These should have
On Fri, Jan 14, 2022 at 4:20 PM Ivan Zhakov wrote:
>
> 1. Revert this change from 1.7.x
Done in r1897222.
Regards;
Yann.
On Wed, Jan 19, 2022 at 5:42 PM wrote:
>
> Author: ivan
> Date: Wed Jan 19 16:41:59 2022
> New Revision: 1897208
>
> URL: http://svn.apache.org/viewvc?rev=1897208=rev
> Log:
> On 'win32-pollset-wakeup-no-file-socket-emulation' branch:
>
> Windows: For the pollset wakeup, use apr_socket_t directly
On Thu, Dec 2, 2021 at 10:21 PM wrote:
>
> Author: mturk
> Date: Thu Dec 2 21:21:18 2021
> New Revision: 1895508
>
> URL: http://svn.apache.org/viewvc?rev=1895508=rev
> Log:
> Stage 3 in dismantling _WIN32_WCE ... cleanup code
>
[]
> Modified: apr/apr/trunk/threadproc/win32/thread.c
> URL:
>
On Tue, Jan 18, 2022 at 2:08 AM Yann Ylavic wrote:
>
> On Tue, Nov 30, 2021 at 11:46 PM Mladen Turk wrote:
> >
> > According to Wikipedia NetWare was discontinued in 2009
> > and OS/2 in 2001, so if anyone can explain why we have
> > those in trunk/apr-2 (that will
On Tue, Nov 30, 2021 at 11:46 PM Mladen Turk wrote:
>
> According to Wikipedia NetWare was discontinued in 2009
> and OS/2 in 2001, so if anyone can explain why we have
> those in trunk/apr-2 (that will be hopefully released one day).
What about BeOS? We have some specifics for that too.
On Sat, Jan 15, 2022 at 2:00 AM William A Rowe Jr wrote:
>
> On Fri, Jan 14, 2022 at 5:07 AM Yann Ylavic wrote:
> >
> > On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr wrote:
> > >
> > > A quick review of nm against libapr-1.so between 1.7.0 and 1.7.x
&g
On Fri, Jan 14, 2022 at 4:40 PM Yann Ylavic wrote:
>
> On Fri, Jan 14, 2022 at 4:20 PM Ivan Zhakov wrote:
> >
> > 1. Revert this change from 1.7.x
> > 2. Release 1.7.1
> > 3. Rework this code on trunk without changing the apr_file_t's behavior
>
On Fri, Jan 14, 2022 at 4:20 PM Ivan Zhakov wrote:
>
> 1. Revert this change from 1.7.x
> 2. Release 1.7.1
> 3. Rework this code on trunk without changing the apr_file_t's behavior
> 4. Backport it to 1.7.x/1.8.x
>
> And if this plan makes sense, I am ready to proceed with steps (1), (3) and
>
Hi Ivan;
On Thu, Jan 13, 2022 at 7:04 PM Ivan Zhakov wrote:
>
> On Fri, 7 Jan 2022 at 17:33, Yann Ylavic wrote:
> >
> > I was missing backport of r1895178, does r1896808 compile now?
> > (Sorry, no Windows at hand..).
> Yes, it builds now. Thanks!
Great, thanks fo
[plus [1] and [2] links..]
On Fri, Jan 14, 2022 at 12:06 PM Yann Ylavic wrote:
>
> On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr wrote:
> >
> > A quick review of nm against libapr-1.so between 1.7.0 and 1.7.x
> > indicates that 1.7.1
> > isn't releasabl
On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr wrote:
>
> A quick review of nm against libapr-1.so between 1.7.0 and 1.7.x
> indicates that 1.7.1
> isn't releasable as-is. Any hints?
>
> +T apr_pool_find
> +T apr_pool_join
> +T apr_pool_lock
> +T apr_pool_num_bytes
Those come from r1863234
On Thu, Dec 23, 2021 at 7:37 AM William A Rowe Jr wrote:
>
> On Fri, Dec 17, 2021 at 10:09 AM Yann Ylavic wrote:
> >
> > On Fri, Sep 3, 2021 at 3:44 AM William A Rowe Jr
> > wrote:
> > >
> > > But I'd be happier co-RM'ing this with a newer committe
On Fri, Jan 7, 2022 at 3:58 PM Ruediger Pluem wrote:
>
> On 1/7/22 3:02 PM, Yann Ylavic wrote:
> >
> > Should we be consistent here then, and always use the passed in reqpool?
> > I.e. something like the below (on the current code):
>
> Maybe a good idea.
r1896812.
Thanks;
Yann.
Hi Ivan,
On Fri, Jan 7, 2022 at 2:50 PM Ivan Zhakov wrote:
>
> This change does not compile on Windows in APR 1.7.x:
> [[[
> file_io\win32\readwrite.c(325): error C2065: 'file': undeclared identifier
> file_io\win32\readwrite.c(325): error C2223: left of '->filehand' must
> point to struct/union
On Fri, Sep 10, 2021 at 5:49 PM Yann Ylavic wrote:
>
> On Fri, Sep 10, 2021 at 4:44 PM Ruediger Pluem wrote:
> >
> > On 9/10/21 4:04 PM, Yann Ylavic wrote:
> > > Index: buckets/apr_buckets_file.c
> > > =
Hi Bill,
On Fri, Sep 3, 2021 at 3:44 AM William A Rowe Jr wrote:
>
> I'm willing to RM APR and APR-util 1.7 releases.
Any news on this?
>
> But I'd be happier co-RM'ing this with a newer committer/PMC
> participant who wants to learn the ropes. Any volunteers?
\o_ thanks for helping! Anytime
1 - 100 of 418 matches
Mail list logo
