Re: Bug#644588: gle-graphics: FTBFS(kfreebsd): Message: /usr/lib/libgle-graphics-4.2.2.so: cannot open shared object file: No such file or directory
On Fri, Oct 07, 2011 at 11:33:33PM +0200, Christoph Egger wrote:
> Hi!
>
> "Christian T. Steigies" <cts@debian.org> writes:
> > Hi,
> > On Fri, Oct 07, 2011 at 12:08:59PM +0200, Christian T. Steigies wrote:
> >> On Fri, Oct 07, 2011 at 10:22:32AM +0200, Christoph Egger wrote:
> >> > Package: src:gle-graphics
> >> > Version: 4.2.2-5
> >> > Severity: serious
> >> > Tags: sid wheezy
> >> > Justification: fails to build from source (but built successfully in the past)
> >> >
> >> > Hi!
> >> >
> >> > Your package failed to build on the kfreebsd-* buildds:
> >>
> >> I do not understand why it fails now, since it has built before. As you can
> >> see, the previous binNMU has also failed, while the one before was
> >> successful:
> >>
> >> https://buildd.debian.org/status/logs.php?pkg=gle-graphics&arch=kfreebsd-amd64
> >>
> >> The problem seems to be that during the build process the binary, that has
> >> just been built, is run a few times. It needs a library that has just been
> >> built and it should use the library from the build directory, since it is
> >> not installed on the system. In 4.2.2-4+b1 and -4, the library was found,
> >> in 4.2.2-4+b2 and -5, the library is not found. What has changed in kfreebsd
> >> in the meantime, and how do I circumvent it?
> >
> > I have successfully built 4.2.2-4 (which failed in the last binNMU) and
> > 4.2.2-5 in an unstable chroot on asdfasdf.debian.net, the kfreebsd-amd64
> > porterbox. On io.debian.net, the kfreebsd-i386 porterbox, the build does not
> > complete as there is no gs installed in the unstable chroot, but the
> > executable works where it has failed on your machine:
>
> I've done some test-builds on my local box. It's permanently building
Any news on this? Your bug report is blocking the package from moving to
testing:
http://qa.debian.org/excuses.php?package=gle-graphics
> fine unless I'm doing parallel build which fails in a different way:
>
> > cp -p manip.hlp ../../build/manip.hlp
> > g++ -DHAVE_CONFIG_H -DGLEVN="\"4.2.2\"" -pthread -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpng12 cell.o cmd.o eval.o filemenu.o fn.o general.o keyword.o manip.o mjl.o polish.o sub.o token.o var.o unix_extra.o unixinkey.o varargs.o unixscr.o ../gle/cutils.static.o ../gle/file_io.static.o -o ../../build/bin/manip -lncurses -ltinfo -lm
> > make[2]: Leaving directory `/var/tmp/gle-graphics-4.2.2/src/manip'
> > /usr/bin/make -C src/gui -f MakefileAC
> > make[2]: Entering directory `/var/tmp/gle-graphics-4.2.2/src/gui'
> > /usr/bin/qmake-qt4
> > /usr/bin/make
> > make[3]: Entering directory `/var/tmp/gle-graphics-4.2.2/src/gui'
> > make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
> > make[3]: *** No targets specified and no makefile found. Stop.
> > make[3]: Leaving directory `/var/tmp/gle-graphics-4.2.2/src/gui'
> > make[2]: *** [domake] Error 2
> > make[2]: *** Waiting for unfinished jobs....
I am not sure what a "parallel build" is, but it seems to be something that
is not done on buildds.
> I'll reshedule the build to see what happens. If it still fails
> hopefully someone from -bsd can help you further.
So to summarize, both you and I can build the package on kfreebsd machines
(debian porter boxes and your box), but the buildds fail to build since
4.2.2-4+b2, whereas 4.2.2-4+b1 and 4.2.2-4 have built successfully. Note
that in a binNMU the source code has not been changed. From this I conclude
that the bug is not in the source, but only on the buildds, especially
since other kfreebsd machines build the package fine, without any source
changes. Since nobody from -bsd seems to be able to help, I suggest to
reassign the bug to bsd (what would be the pseudo package for that?) or
reduce the severity from serious to something reasonable, normal or minor.
Christian
Reply to: