[pkg-boost-devel] Bug#719484: Bug#719484: boost1.54: FTBFS: assertion fail in bjam, possibly invalid/unportable alignment assumptions

[Dimitri John Ledkov]

On 24 July 2015 at 21:08, Eduard Bloch <edi at gmx.de> wrote:
> On Mon, 12 Aug 2013 10:52:39 +0000 Thorsten Glaser <tg at mirbsd.de> wrote:
>> Source: boost1.54
>> Version: 1.54.0-2
>> Severity: important
>> Justification: fails to build from source (but built successfully in the past)
>>
>> Hi,
>>
>> Iâ  ve not yet had time to look at this, but my guess is
>> that bjam assumes natural alignment / struct padding,
>> which is not portable â   implicit alignment assumptions
>> should be made explicit, usually by adding padding
>> members to structs, if they are to be relied upon.
>>
>> Full build log attached.
>
> Can we please have this bug fixed ASAP? I can confirm that Thorsten's
> patch solves the bjam issue on m68k, and the g++ ICE should also have
> been fixed more than a year ago.
>

The reason why it's not fixed, is because it would be rather pointless.
As boost1.54 is in unstable only and should be removed, as we have
migrated to 1.55 a while back.

Furthermore boost1.58 is now being staged in experimental for next transition.

Does this affect boost1.58, if so, are you submitting it upstream? All
other arch patches we carried overtime e.g. for powerpc64 / arm64 did
come as cherrypicks from upstream e.g. master.

> So why did this not have been added so far? *wondering*
>
> And while we are at it, please mind
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793404 . Some parts of
> your debian/rules do smell and should be subject to improval.
>

Reading that bug report comments I disagree. Our debian rules are
compliant. Imho dpkg-buildpackage should set all the arch/version/etc
variables for us becuase it knows them and they really shouldn't
change throughout all the build.

I see there is work to solve this in dh side.

If you have a patch which would:
* add a cache target
* cache target would calculate all the variables and store them in a
cache file (e.g. debian/vars.cache or some such)
* all subsequent invocation source that file with cache target becoming a no-op

I'd be happy to take it.

Your message reads very aggressive to me, thus I am not motivated to
check if 4 major upstream releases old non-upstream patches apply
against svn trunk for boost1.58 package. But I am willing to file
boost1.54 removal request.

-- 
Regards,

Dimitri.