Re: Strange FTBFS on s390
Johannes Rohr <j.rohr@gmx.de> writes:
> Am Thu, 12 Feb 2004 05:30:11 +0100 schrieb Goswin von Brederlow:
>
> > Johannes Rohr <j.rohr@gmx.de> writes:
> >
> >> Hello everybody,
> >>
> >> sorry for bothering the general newsgroup. I already asked my question
> >> on the s390 and gtk-gnome lists but got no response.
> >>
> >> nautilus-media, part of the GNOME core desktop, is currently blocked
> >> from testing because of this FTBFS on s390:
> >>
> >> http://buildd.debian.org/fetch.php?&pkg=nautilus-media&ver=0.3.3.1-4&arch=s390&stamp=1076051222&file=log&as=raw
> >>
> >> What happened is that apt failed to properly unpack and configure the
> >> build-depends: It tried to configure libeel2-2 before having configured
> >> libeel2-data. dpkg complained about this loudly and returend an error.
> >>
> >> This happened on s390 _only_. On all other arches the package built just
> >> fine.
> >>
> >> Can someone explain this? Is apt or dpkg probably misconfigured on s390?
> >> What can I do about this?
> >>
> >> Thanks a lot for any hint!
> >>
> >> Johannes
> >
> > Policy 7.2 says the following:
> >
> > ----------------------------------------------------------------------
>
> [...]
>
> > Your circular depends is unsolvable. They can't be both configured before
> > the other.
> >
> > In case of such a circular depends I would say that the order in which
> > those packages are configured is undetermined. _You_ have to make sure
> > either way works.
> >
> >
> > But why does libeel2-data depend on libeel2 at all? It only has a preinst
> > script that doesn't (and can't) depend on libeel2 and contains a bunch of
> > locale files that are just data.
> >
> > You might want to drop the Depends and add a copyright / licence /
> > changelog to libeel2-data.
>
> Thanks I'll consider filing a bug against libeel2-data. But anyway, if
> this was the cause of the FTBFS, why does is happen on one arch only?
Bad luck. Just the right (or wrong) circumstances coming together that
make apt do it the "wrong" way around. It is probably like the
automake timestamp skew bugs. If you happen to run patch just at the
right time the timestamps will be of different seconds and the build
breaks (But since m68k is so slow its far more likely to happen
there).
MfG
Goswin
Reply to: