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

[Eduard Bloch]

Hallo,
* Dimitri John Ledkov [Sat, Jul 25 2015, 02:40:26PM]:
> 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.

Right now there is no Boost version in Stable or Unstable without this
bug. IMHO this point is valid enough.

> As boost1.54 is in unstable only and should be removed, as we have
> migrated to 1.55 a while back.

And you could have asked for feedback/repro of 1.55 on m68k to be sure
about that. But sitting FTBFS issues out is rarely a good idea.

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

I tried boost1.58 and it seems to work beyond that point where the bug
appeared. And we got a report of successfull boost 1.58 on the 68k
mailing list. Therefore, yeah... consider adding a pending tag to this
BR.

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

Well, did anyone here tell the submitter to report it upstream? I don't
see anything. Did anyone from boost maintainers did so? I don't think
so. Therefore, I wouldn't expect upstream fixes.

IMHO everyone is waiting for something, looks like a deadlock in
communication here.

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

Compliance was not the issue. You could use $(shell sleep 1000 && do
something) and it'd still be compliant... more or less.

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

And how would it hurt to simply use := assignments in your debian/rules?
This would cut the bootstrap time significantly.

> Your message reads very aggressive to me, thus I am not motivated to

Maybe I was slightly pissed seing this kind of FTBFS issue handling.

> check if 4 major upstream releases old non-upstream patches apply

Or, as said, you could have requested feedback for the last upstream
version in Unstable.

> against svn trunk for boost1.58 package. But I am willing to file
> boost1.54 removal request.

IMHO: feel free, 1.54 and 1.55 are equally buggy in this respect.

Regadrs,
Eduard.