[Debian-med-packaging] Bug#907819: jellyfish: Does not build on paths containing "-L"

Adrian Bunk bunk at debian.org
Sun Sep 2 23:00:15 BST 2018


Control: severity -1 important

On Sun, Sep 02, 2018 at 10:36:28PM +0200, Santiago Vila wrote:
>...
> On Sun, Sep 02, 2018 at 09:43:28PM +0300, Adrian Bunk wrote:
>...
> > https://people.debian.org/~sanvila/build-logs/jellyfish/jellyfish_2.2.8-3_amd64-20180902T150417Z
> > 
> > ...
> > I: NOTICE: Log filtering will replace 'build/jellyfish-La3pVw/jellyfish-2.2.8' with '<<PKGBUILDDIR>>'
> > ...
> > x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,relro -Wl,-z,now -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-amd64-3.7/jellyfish_wrap.o -L/build/jellyfisha3pVw/jellyfish-2.2.8/debian/tmp//usr/lib/x86_64-linux-gnu -Wl,--enable-new-dtags,-R/<<PKGBUILDDIR>>/debian/tmp/usr/lib/x86_64-linux-gnu -ljellyfish-2.0 -lpthread -o /<<PKGBUILDDIR>>/.pybuild/cpython3_3.7_dna-jellyfish/build/_dna_jellyfish.cpython-37m-x86_64-linux-gnu.so
> > /usr/bin/ld: cannot find -ljellyfish-2.0
> > 
> > 
> > Something (libtool?) removes the "-L" from the "jellyfish-La3pVw",
> 
> Good catch! Yes, that's what it seems to happen!
> 
> 
> However, this can happen in any official buildd the same way it happened to me.
> 
> In every build log there are three different messages about log filtering,
> like this:
> 
> I: NOTICE: Log filtering will replace 'var/run/schroot/mount/sid-53306582-5e1d-46e9-87b2-1e8840f72cfe' with '<<CHROOT>>'
> 
> [...]
> 
> I: NOTICE: Log filtering will replace 'build/jellyfish-La3pVw/jellyfish-2.2.8' with '<<PKGBUILDDIR>>'
> I: NOTICE: Log filtering will replace 'build/jellyfish-La3pVw' with '<<BUILDDIR>>'
> 
> 
> The first one is a UUID (alphanumeric) and by design it's clear that
> it will never contain "-L".
> 
> But the last two are chosen by sbuild randomly, using "mktemp -d" and
> the algorithm followed by sbuild to construct this random path does not
> seem to be different from buildd to the packaged version of sbuild I'm
> using.
> 
> So not only there may be a "-L" in a path in the official buildds,
> but it mathematically will (provided you try enough times).
> 
> So yes, this package FTBFS randomly in the official buildds too.

No, it cannot.

The buildds use a UUID, which cannot contain L.

I was lucky that you provided build logs this time, bugs without any 
logs are basically "minor moreinfo" since there is nothing that can
be done about such bugs.

Please double-check whether in other bugs you reported the buildpath 
contained strings like -l or -L or -I or similar that cannot happen
on the buildds, and that might have caused such build failures noone 
can reproduce.

And in any case, please ensure that all your bugs have a full
build log attached or linked (reproducible is fine).

> We could of course change the algorithm used by sbuild to construct
> this random path, but really, packages are supposed to be buildable
> in any path, and definitely on paths containing "-L".

jellyfish doesn't do anything here that strikes me as wrong,
my first suspects for the root cause would be libtool or automake.

> Thanks.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



More information about the Debian-med-packaging mailing list