svn commit: r370388 - in head: devel/e2fsprogs-libss misc/e2fsprogs-libblkid misc/e2fsprogs-libuuid sysutils/e2fsprogs sysutils/e2fsprogs/files

[Matthias Andree]

Am 07.10.2014 um 22:08 schrieb Bryan Drewery:
> On 10/7/2014 2:15 PM, Matthias Andree wrote:
>> Author: mandree
>> Date: Tue Oct  7 19:15:52 2014
>> New Revision: 370388
>> URL: https://svnweb.freebsd.org/changeset/ports/370388
>> QAT: https://qat.redports.org/buildarchive/r370388/
>>
>> Log:
>>   Update to new upstream release 1.42.12.
>>   Changelog:	http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42.12
>>   
>>   Reset PORTREVISION on slaves.
>>   Remove @dirrm* from master's + slaves' pkg-plist.
>>   Remove patches overcome by upstream events.
>>   Ignore PORTSCOUT - it can't figure out the directory structure.
>>   No longer run self-test in parallel - exhausts redports directory.
>>   
>>   Mark BROKEN on 11-CURRENT - causes miscompilation (bogus numbers in
>>   output, SIGSEGV/SIGBUS):
>>     https://redports.org/~mandree/20141007190638-31576-251231/e2fsprogs-1.42.12.log
>>     https://redports.org/~mandree/20141007185700-4151-251228/e2fsprogs-1.42.12.log
> 
> It says a lot about ports that we can't update something without
> breaking it on a release where it was working fine before.

I am not sure I got what you're trying to convey.  You may be
overestimating the scope of the issue, given the findings after the commit.

I do not consider 11-CURRENT a reference, nor is 11 a "RELEASE".

That aside, the port itself has a subtle but nasty and stubborn
use-after-free issue that does not show in uninstrumented self-tests,
and reverting the failure-inducing commit (URL/Id below) does not cure
in my testing.

Long story:

It turns out that the memory poisoning that 11 inflicts on its
user-space unveiled a regression between 1.42.10 and 1.42.11 that I
bisected identifying
<http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?h=maint&id=47fee2ef6a23ae06f680336ffde57caa64604a4c>
as the first faulty upstream commit, details on the hunt were reported
on the -toolchain and -current lists.

I believed 1.42.12 safe because only 11 was failing and I wasn't aware
that the malloc.conf "Junk" feature is enabled on 11, and committed the
upgrade.

Short-term action:

I want to avoid a rollback entailing PORTEPOCH bump.

I've marked e2fsprogs (only the master port) BROKEN everywhere for now
(r370411), reported the thing upstream (antoine@ was in cc:), and I have
given upstream a few days to come up with a fix.

Failing that, we'll bump PORTEPOCH to 1 and roll back to 1.42.10.
(1.42.11 also has the bug).  Note that this needs a bit of attention
because we have three slave ports, devel/e2fsprogs-libss,
misc/e2fsprogs-libblkid, misc/e2fsprogs-libuuid.