On 22.02.2019 11:14, Yann Ylavic wrote:
> On Fri, Feb 22, 2019 at 10:46 AM wrote:
>> The Buildbot has detected a new failure on builder apr-x64-macosx-trunk
>> while building . Full details are available at:
>> https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/189
> Hmm, something
The Buildbot has detected a new failure on builder apr-x64-macosx-trunk while
building . Full details are available at:
https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/189
Buildbot URL: https://ci.apache.org/
Buildslave for this Build: svn-x64-macosx-dgvrs
Build Reason: The
On Fri, Feb 22, 2019 at 9:33 AM Branko Čibej wrote:
> Even if that tool did work this way 16 years ago, this was the wrong way
> to solve the "problem". It's not APR's job to support such tools (except
> for pool debugging modes); it's the downstream application's.
On Fri, Feb 22, 2019 at 9:52
On Thu, Feb 21, 2019 at 07:11:35PM +0100, Yann Ylavic wrote:
> Hi,
>
> can we stop preventing APR users (e.g. httpd) from using SIGUSR2
> because of the way a tool worked 16 years ago (and probably doesn't
> anymore)? No sarcasm here, just a question...
>
> IOW, may I:
+1 definitely, it's a bit
On 21.02.2019 19:11, Yann Ylavic wrote:
> Hi,
>
> can we stop preventing APR users (e.g. httpd) from using SIGUSR2
> because of the way a tool worked 16 years ago (and probably doesn't
> anymore)? No sarcasm here, just a question...
>
> IOW, may I:
> Index: srclib/apr/threadproc/unix/signals.c
>
