Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On Thu, 9 Apr 2020 16:35:13 +0200 Sebastian Andrzej Siewior wrote: > I suggested already something in [0]. Back then we were hoping for some > feedback from the debhelper team. > Now I was just asking if Jonathan is handling this and/or if we could > also bump to current upstream version while at it. > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945961#10 As Dimitri pointed out we have also been affected by this but in Ubuntu - we found it out recently when doing archive rebuilds on Focal. The proposed fix in #10 does workaround the issue and it is not necessary to change the build-arch rules as Dimitri suggested. I do wonder if this is in fact a regression in debhelper. I tracked it down to debhelper 12.4 to 12.5 and while I haven't been able to pinpoint exactly what particular change there is causing it I believe it is in how double colon rules are being interpreted. It seems the debhelper changes somehow fail to detect the build-arch rules. Unless someone knows enough perl to dig into debhelper changes between 12.4 and 12.5 and check if that is in fact a regression, I would suggest to simply apply the proposed change in comment #10. Thanks for your help =) Tiago Daitx
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On 2020-04-09 14:32:07 [+0100], Dimitri John Ledkov wrote: > Here is the debdiff that makes everything work for me. > > It smells like a subtle breakage in detecting/parsing makefile > targets, or like make regression. > > It is still odd, i.e. there is build target, then binary target, which > then via dependencies calls binary-arch & binary-all. So not sure if > the results are correct or not. I suggested already something in [0]. Back then we were hoping for some feedback from the debhelper team. Now I was just asking if Jonathan is handling this and/or if we could also bump to current upstream version while at it. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945961#10 Sebastian
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On Sat, 4 Apr 2020 22:07:52 +0200 Sebastian Andrzej Siewior wrote: > On 2019-12-03 20:18:20 [-0800], Jonathan Nieder wrote: > > Hi, > Hi, > > > Let's track down the cause first, before pursuing workarounds. > > Nothing happened here so far and I almost forgot about it. xz 5.2.5 has > been released in the meantime. Do you want me to help you out in anyway? > I could add the fix I suggested and prepare the new release. > Here is the debdiff that makes everything work for me. It smells like a subtle breakage in detecting/parsing makefile targets, or like make regression. It is still odd, i.e. there is build target, then binary target, which then via dependencies calls binary-arch & binary-all. So not sure if the results are correct or not. diff -Nru xz-utils-5.2.4/debian/changelog xz-utils-5.2.4/debian/changelog --- xz-utils-5.2.4/debian/changelog 2019-01-28 01:09:34.0 + +++ xz-utils-5.2.4/debian/changelog 2020-04-09 14:13:56.0 +0100 @@ -1,3 +1,10 @@ +xz-utils (5.2.4-1.1) unreleased; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS due to odd targets in debian/rules. Closes: #945961 + + -- Dimitri John Ledkov Thu, 09 Apr 2020 14:13:56 +0100 + xz-utils (5.2.4-1) unstable; urgency=low * New upstream release. Closes: #851615. diff -Nru xz-utils-5.2.4/debian/rules xz-utils-5.2.4/debian/rules --- xz-utils-5.2.4/debian/rules 2019-01-28 01:07:43.0 + +++ xz-utils-5.2.4/debian/rules 2020-04-09 14:11:01.0 +0100 @@ -1,10 +1,10 @@ #!/usr/bin/make -f -build clean install binary-arch binary-indep binary: +%: +dh $@ --parallel $(opt_no_act) # Runs tests, too, if and only if nocheck is unset (see below). -build-arch:: build-plain build-static build-small +build-arch: build-plain build-static build-small build-indep: debian/normal-build/Makefile cd debian/normal-build && doxygen Doxyfile @@ -133,9 +133,9 @@ endif ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) -build-arch:: debian/test-plain-stamp -build-arch:: debian/test-static-stamp -build-arch:: debian/test-xzdec-stamp +build-arch: debian/test-plain-stamp +build-arch: debian/test-static-stamp +build-arch: debian/test-xzdec-stamp endif # Build a tarball with the latest upstream version.
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On 2019-12-03 20:18:20 [-0800], Jonathan Nieder wrote: > Hi, Hi, > Let's track down the cause first, before pursuing workarounds. Nothing happened here so far and I almost forgot about it. xz 5.2.5 has been released in the meantime. Do you want me to help you out in anyway? I could add the fix I suggested and prepare the new release. > Thanks much, > Jonathan Sebastian
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
Noticed that I can successfully build arch:all OR arch:any, but not arch:all AND arch:any when building with sbuild. Fails, building both arch:all and arch:any in one pass (which I think is the default for pbuilder?): sbuild -d UNRELEASED -c sid --no-source --arch-any --arch-all xz-utils_5.2.4-1.dsc Succeeds, building arch:all only: sbuild -d UNRELEASED -c sid --no-source --no-arch-any --arch-all xz-utils_5.2.4-1.dsc Succeeds, building arch:any only: sbuild -d UNRELEASED -c sid --no-source --arch-any --no-arch-all xz-utils_5.2.4-1.dsc That would explain why it works on the buildd's but not with pbuilder or with the reproducible builds infrastructure (which also uses pbuilder with a all+any build, usually). At some point, it would be nice to systematically test these types of issues as part of the reproducible builds infrastructure, but that is probably a ways off... live well, vagrant signature.asc Description: PGP signature
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
Sebastian Andrzej Siewior dixit:
>| build clean install binary-arch binary-indep binary:
AFAIK, dh7-style does not know an “install” target at all,
but build-{arch,indep} are missing in that list.
bye,
//mirabilos
--
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
Hi, Sebastian Andrzej Siewior wrote: > I don't know what changed but I think it is debhelper. We have now: > > |(sid)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act > | debian/rules install > | dh_installdeb > | dh_gencontrol > | dh_md5sums > | dh_builddeb > > and that "debian/rules build" gets inlined we skip to install. This was > once > > |(buster)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act > | debian/rules install > | debian/rules binary-arch > | debian/rules binary-indep > > The install rule used to expand to other targets, to build the package > but not anymore. Good sleuthing. If someone has time to bisect to find the problematic debhelper change, that would be helpful. I can easily believe there is an intentional change involved, but I don't think this is intentional when trying to build an existing package without bumping the compat version. Thus: [...] > xz has this line in its rule file: > > | #!/usr/bin/make -f > | > | build clean install binary-arch binary-indep binary: > | +dh $@ --parallel $(opt_no_act) > > and if I replace it with > | #!/usr/bin/make -f > | > | %: > | dh $@ --parallel $(opt_no_act) > > then it builds again. > > Should the rules be adjusted for xz? Let's track down the cause first, before pursuing workarounds. Thanks much, Jonathan
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On 2019-12-01 11:35:08 [-0800], Daniel Schepler wrote: > ... > debian/rules build > dh build --parallel >dh_update_autotools_config -O--parallel >dh_auto_configure -O--parallel >dh_auto_build -O--parallel >dh_auto_test -O--parallel > fakeroot debian/rules binary > dh binary --parallel >debian/rules install > make[1]: Entering directory '/build/xz-utils-5.2.4' > dh install --parallel >debian/rules build > make[2]: Entering directory '/build/xz-utils-5.2.4' > dh build --parallel > make[2]: Leaving directory '/build/xz-utils-5.2.4' >dh_testroot -O--parallel >dh_prep -O--parallel >debian/rules override_dh_auto_install > make[2]: Entering directory '/build/xz-utils-5.2.4' > dh_auto_install --builddirectory debian/xzdec-build > dh_auto_install --builddirectory debian/normal-build > dh_auto_install --builddirectory debian/static-build I don't know what changed but I think it is debhelper. We have now: |(sid)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act | debian/rules install | dh_installdeb | dh_gencontrol | dh_md5sums | dh_builddeb and that "debian/rules build" gets inlined we skip to install. This was once |(buster)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act | debian/rules install | debian/rules binary-arch | debian/rules binary-indep The install rule used to expand to other targets, to build the package but not anymore. If I use sid and downgrade to debhelper 12.5.3 then it still expands the same way. Buhhh. According to the overview in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xz-utils.html it FTBFS in bullseye on AMD64 but succeeds on ARM64. The build on ARM64 is from "2019-08-20 11:36:00 UTC" while the ADM64 is from "at 2019-11-26 05:14:00 UTC" so something might not migrated yet. Anyway. xz has this line in its rule file: | #!/usr/bin/make -f | | build clean install binary-arch binary-indep binary: | +dh $@ --parallel $(opt_no_act) and if I replace it with | #!/usr/bin/make -f | | %: | dh $@ --parallel $(opt_no_act) then it builds again. Should the rules be adjusted for xz? Sebastian
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
Source: xz-utils Version: 5.2.4-1 Severity: serious >From my pbuilder build log: ... debian/rules build dh build --parallel dh_update_autotools_config -O--parallel dh_auto_configure -O--parallel dh_auto_build -O--parallel dh_auto_test -O--parallel fakeroot debian/rules binary dh binary --parallel debian/rules install make[1]: Entering directory '/build/xz-utils-5.2.4' dh install --parallel debian/rules build make[2]: Entering directory '/build/xz-utils-5.2.4' dh build --parallel make[2]: Leaving directory '/build/xz-utils-5.2.4' dh_testroot -O--parallel dh_prep -O--parallel debian/rules override_dh_auto_install make[2]: Entering directory '/build/xz-utils-5.2.4' dh_auto_install --builddirectory debian/xzdec-build dh_auto_install --builddirectory debian/normal-build dh_auto_install --builddirectory debian/static-build set -e; arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH); \ install -d debian/tmp/lib/$arch; \ mv debian/tmp/usr/lib/$arch/liblzma.so.* debian/tmp/lib/$arch/; \ dso=$(basename $(readlink debian/tmp/usr/lib/$arch/liblzma.so)); \ ln -s -f /lib/$arch/$dso debian/tmp/usr/lib/$arch/liblzma.so mv: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*': No such file or directory make[2]: *** [debian/rules:34: override_dh_auto_install] Error 1 make[2]: Leaving directory '/build/xz-utils-5.2.4' make[1]: *** [debian/rules:4: install] Error 2 make[1]: Leaving directory '/build/xz-utils-5.2.4' make: *** [debian/rules:4: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 -- Daniel Schepler
