apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: 1.6.0 release candidates
Date Mon, 17 Apr 2017 16:42:14 GMT
Hi Nick,

Am 17.04.2017 um 18:06 schrieb Nick Kew:
> 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?

I thought those are not for security but to easily detect transfer 
errors. Only the pgp signature is for security. The hashes still seem to 
be frequently provided.

>> - 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.

Right, those files will not be part of the artefacts but exist in the 
download directory, e.g.:

https://dist.apache.org/repos/dist/release/apr/

or

http://archive.apache.org/dist/apr/

>> - Key B87F79A9 missing from KEYS file
>
> Good point.  Since ASF now auto-generates per-project keys files
> daily, why maintain a separate KEYS file?

Didn't know about that feature. Can it also be used to check historic 
signatures, e.g. of old releases? At least we would have to rephrase

http://apr.apache.org/download.cgi

the KEYS file is mentioned there.

>> - 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).

Thanks for correcting this.

>> - ".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?

I always thought about deleting the build/l*.m4 files coming from 
libtool while running buildconf at the end of buildconf. I think they 
are not needed for building and if you rerun buildoncf they will again 
get copied from the libtool installation.

IMHO we should stick to configure/make as the normal build procedure and 
not demand people to run buildconf. Users who build should not have a 
need to care about libtool and auto tools installations. So I'd keep the 
files generated by buildconf for the Unix tarballs (except for the 
build/l*.m4 files as mentioned above).

>> - 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.

Yes I think that one should get fixed.

>> 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'll try to dig some more info whether the problem can be fixed by an OS 
patch for Solaris 10. At least it shows the potential for problems.

I'm a bit undecided on the config option, because that means we'll have 
builds with subtle API differences. Most of the other APR config options 
are not a good comparison for a consistent decision.

> 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!

Thanks!

Rainer

Mime
View raw message