On Sat, Apr 8, 2017 at 12:52 AM, Nick Kew wrote:
> On Fri, 17 Mar 2017 23:31:34 +
> Nick Kew wrote:
>
> 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
On Fri, 17 Mar 2017 23:31:34 +
Nick Kew 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 per
* Yann Ylavic:
>> It's been a bit of a struggle to get this right.
>
> I think the confusion comes from the term "directory stream", which
> people (at least me :p ) may read as underlying directory (i.e.
> filesystem's), though it's the term used to talk about the DIR* in the
> whole man page...
On Sat, Mar 25, 2017 at 1:34 PM, Florian Weimer wrote:
> * Yann Ylavic:
>> "In the current POSIX.1 specification (POSIX.1-2008),
>> readdir() is not required to be thread-safe. However, in modern
>> implementations (including the glibc implementation), concurrent calls
>> to readdir() tha
* Yann Ylavic:
> [Resend to the whole list, sorry Florian for private message]
>
> On Sat, Mar 25, 2017 at 1:20 PM, Yann Ylavic wrote:
>>
>> Right, modern readdir()s seem to be thread-safe but with regard to
>> different directories only, at least Linux' man page states:
>> "In the curren
[Resend to the whole list, sorry Florian for private message]
On Sat, Mar 25, 2017 at 1:20 PM, Yann Ylavic wrote:
>
> Right, modern readdir()s seem to be thread-safe but with regard to
> different directories only, at least Linux' man page states:
> "In the current POSIX.1 specification (
* Yann Ylavic:
>> readdir is thread-safe. There used to be this idea that fdopendir
>> could be implemented like this:
>>
>> DIR *
>> fdopendir (int fd)
>> {
>> return (DIR *) fd;
>> }
>>
>> And readdir would use a static buffer for the directory entry (like
>> gethostbyname) instead of somethi
On Sat, Mar 25, 2017 at 12:53 PM, Florian Weimer wrote:
> * Yann Ylavic:
>
>> On Fri, Mar 24, 2017 at 7:35 PM, William A Rowe Jr
>> wrote:
>>>
>>> I haven't built 1.x branch against openssl 110 yet,
>>
>> I did with 1.6.x (on latest Debian's libbsl-1.1) with no issue.
>>
>>> so here's some Unix (
* Yann Ylavic:
> On Fri, Mar 24, 2017 at 7:35 PM, William A Rowe Jr
> wrote:
>>
>> I haven't built 1.x branch against openssl 110 yet,
>
> I did with 1.6.x (on latest Debian's libbsl-1.1) with no issue.
>
>> so here's some Unix (latest Fedora) feedback;
>>
>> ../../apr-1.6/file_io/unix/dir.c: In
On Fri, Mar 24, 2017 at 7:35 PM, William A Rowe Jr wrote:
>
> I haven't built 1.x branch against openssl 110 yet,
I did with 1.6.x (on latest Debian's libbsl-1.1) with no issue.
> so here's some Unix (latest Fedora) feedback;
>
> ../../apr-1.6/file_io/unix/dir.c: In function ‘apr_dir_read’:
> ..
On Thu, Mar 23, 2017 at 1:01 PM, Nick Kew wrote:
> On Thu, 2017-03-23 at 10:13 -0700, Gregg Smith wrote:
>
>> My retro build changes and Jan's revised patch have been commited.
>> Windows should be good to go.
>
> Brilliant, thanks both.
+1
> I'll take the activity on this issue as an indication
On Thu, 2017-03-23 at 10:13 -0700, Gregg Smith wrote:
> My retro build changes and Jan's revised patch have been commited.
> Windows should be good to go.
Brilliant, thanks both.
I'll take the activity on this issue as an indication that
Windows was already *otherwise* good. Unless we hear to
t
On 3/22/2017 8:30 AM, Nick Kew wrote:
Gregg, any thoughts on a timeframe for commit? Obviously
nice-to-have,
though I'm also thinking if we have to release without a fix, we
can
at least use Jan's latest post in a release note.
--
Nick Kew
My retro b
begin 644 diffCMakeLists-jan.patch
M26YD97@Z($--86ME3&ES=',N='AT#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M#0HM+2T@0TUA:V5,:7-T'0)*')E=FES:6]N(#$W.#'0)*'=O2D-"D!`("TR,S@L-R`K,C,X
M+#<@0$`-"B!3150H:6YS=&%L;%]T87)G971S("1[:6YS=&%L;%]T87)G971S
M?2!
Gregg Smith in gmane.comp.apache.apr.devel (Wed, 22 Mar 2017 10:20:54
-0700):
>I got a patch for cmake from Jan (attached) which ended up off list due
>to the way "reply" works on this list.
The patch added -DAPR_DECLARE_EXPORT=1 -DAPU_DECLARE_EXPORT=1 twice to
apr_crypto_openssl. New patch attac
On 3/22/2017 8:30 AM, Nick Kew wrote:
[sorry, reposting by cut&paste from this morning when mail was broken]
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:
> I've been hacking on the .mak and .win files.
> Had to add a
[sorry, reposting by cut&paste from this morning when mail was broken]
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:
On Sun, 2017-03-19 at 20:44 -0700, Gregg Smith wrote:
> I've been hacking on the .mak and .win files.
> Had to add a -ossl1 to apr/build/cvtdsp.pl fo
[sorry, reposting by cut&paste from this morning when mail was broken]
On Mon, 2017-03-20 at 03:20 +0100, Jan Ehrhardt wrote:
> Jan Ehrhardt in gmane.comp.apache.apr.devel (Sun, 19 Mar 2017
20:21:47 +0100):
> >>So, the answer to the question "does it work for you?" seems
to be No.
Arg, this list bites me again. Sorry for the double Jan.
On 3/19/2017 11:44 AM, Jan Ehrhardt wrote:
Nick Kew in gmane.comp.apache.apr.devel (Sat, 18 Mar 2017 07:57:37
+):
On Sat, 2017-03-18 at 08:28 +0100, Jan Ehrhardt wrote:
Will this 1.6 release contain support of OpenSSL 1.1.x or is th
Jan Ehrhardt in gmane.comp.apache.apr.devel (Mon, 20 Mar 2017 03:20:36 +0100):
>. compile apr-util, with the CMake args on 1 line:
snip
>call msbuild APR.sln /p:Configuration=RelWithDebInfo /p:Platform=x64
Copy-paste eror. For apr-util this has to be
call msbuild APR-Util.sln /p:Configuration=RelW
Jan Ehrhardt in gmane.comp.apache.apr.devel (Sun, 19 Mar 2017 20:21:47 +0100):
>>So, the answer to the question "does it work for you?" seems to be No.
>
>Or Yes, if CMake works. I will try that later.
CMake almost works. I had the following dirs
- apr
- apr
- apr-util
- xml
- openssl
F
Jan Ehrhardt in gmane.comp.apache.apr.devel (Sun, 19 Mar 2017 19:44:01
+0100):
>The 2 Windows related files in apr/apr-util/crypto still use the pre-1.1
>OpenSSL lib files, libeay32.lib and ssleay32.lib:
>http://svn.apache.org/viewvc/apr/apr-util/branches/1.6.x/crypto/apr_crypto_openssl.dsp?view=ma
Nick Kew in gmane.comp.apache.apr.devel (Sat, 18 Mar 2017 07:57:37
+):
>On Sat, 2017-03-18 at 08:28 +0100, Jan Ehrhardt wrote:
>
>> Will this 1.6 release contain support of OpenSSL 1.1.x or is that part
>> of a future release?
>
>Good question. I see no bugzilla entry for it. A quick search
>
On Sat, 2017-03-18 at 08:28 +0100, Jan Ehrhardt wrote:
> Nick Kew in gmane.comp.apache.apr.devel (Fri, 17 Mar 2017 23:31:34
> +):
> >We have a backlog of mostly-minor fixes to 1.x unreleased.
> >I think we're all agreed that the best way to deal with them
> >is to roll a 1.6 release.
>
> Will
Nick Kew in gmane.comp.apache.apr.devel (Fri, 17 Mar 2017 23:31:34
+):
>We have a backlog of mostly-minor fixes to 1.x unreleased.
>I think we're all agreed that the best way to deal with them
>is to roll a 1.6 release.
Will this 1.6 release contain support of OpenSSL 1.1.x or is that part
of
We have a backlog of mostly-minor fixes to 1.x unreleased.
I think we're all agreed that the best way to deal with them
is to roll a 1.6 release.
At the start of December, Bill suggested a 1.6 release in
three days. That started a thread which never led to an
actual release.
I'd like to resurrec
26 matches
Mail list logo
