Re: adacontrol ftbfs on sparc64 and ppc64?

[Matthias Klose <doko@ubuntu.com>]

On 21.05.2016 10:36, Nicolas Boulenguez wrote:
> On Thu, May 19, 2016 at 01:13:34PM +0200, Matthias Klose wrote:
> > https://buildd.debian.org/status/package.php?p=adacontrol
> > https://launchpad.net/ubuntu/+source/adacontrol/1.17r3.1-3/+build/9746246
> > Any idea what is causing these issues?
>
> Hello.
>
> Gprbuild and other packages have been affected by similar issues.
> https://buildd.debian.org/status/logs.php?pkg=gprbuild&ver=2015-5
> As you can see in the two ppc64el logs, a new attempt with
> XMLAda/4.5.2015-7 instead of -6 automagically fixes the problem.
>
> I am reluctant to ask for manual intervention of the wanna-build team,
> as the issue may disappear by itself, and I am not sure that it would
> be sufficient. I am unable to test because there is no sparc64
> porterbox and the apt cache is out of date on the ppc64 porterbox.
>
> I do not fully understand the problem, but here is my guess.
>
> As ALI files refer to each other recursively, a problem in XMLAda may
> explain a message about libasis-dev when building adacontrol.  In
> XMLAda, sources modified after last debian/changelog entry, by
> debian/patches for example, are forced to the changelog date in order
> to ensure that ALI files contain deterministic
> timestamps. Unfortunately, when preparing 4.5.2015-6, I have
> reconstructed the upstream tarball from a VCS, making all sources more
> recent than debian/changelog.  XMLAda/4.5.2015-7 happens to fix the
> problem simply because its debian/changelog is more recent.

so for the ppc64el build on Ubuntu I had to re-upload asis, and that failed too, 
had to re-upload libgnatcoll.

If the timestamp is derived from the changelog, then it probably doesn't make 
sense to ask buildd admins, but just do a no-change upload of the offending 
package? At least that seemed to help here.

Matthias