Bug#1066632: djbdns: FTBFS: hier.c:10:3: error: implicit declaration of function ‘h’ [-Werror=implicit-function-declaration]
Control: tags -1 + patch On Wed, Mar 13, 2024 at 12:49:27PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. I prepared a patch for another djbdns problem and in that proces also fixed this FTBFS. You can find the combined patch on #1071526. Helmut
Bug#1071244: dracut-install has an undeclared file conflict on /usr/lib/dracut/dracut-install
Package: dracut-install Version: 060+5-7 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + dracut-core dracut-install has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/dracut/dracut-install is contained in the packages * dracut-core/060+5-1 as present in trixie * dracut-install/060+5-7 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1071243: elfkickers has an undeclared file conflict on /bin/rebind
Package: elfkickers Version: 0+git20240221+ds-2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + websockify elfkickers has an undeclared file conflict. This may result in an unpack error from dpkg. The file /bin/rebind is contained in the packages * elfkickers/0+git20240221+ds-2 as present in unstable * websockify * 0.10.0+dfsg1-4+b1 as present in bookworm * 0.10.0+dfsg1-6 as present in trixie|unstable * 0.9.0+dfsg1-3 as present in bullseye These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1071242: rust-llvm has an undeclared file conflict
Package: rust-llvm Version: 1.71.1+dfsg1-1~exp2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + rustc-mozilla rustc-web rust-llvm has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/bin/rust-clang * /usr/bin/rust-lld * /usr/bin/rust-llvm-dwp * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld64 are contained in the packages * rust-llvm/1.71.1+dfsg1-1~exp2 as present in experimental * rustc-mozilla/1.63.0+dfsg1-2~deb11u1 as present in bullseye * rustc-web/1.70.0+dfsg1-7~deb12u2 as present in bookworm-proposed-updates These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1071241: elfkickers adds new aliased files when we want to get rid of them
Package: elfkickers Version: 0+git20240221+ds-2 Severity: serious Justification: keep out of testing Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi Alex, you may know this /usr-move thingy. We want to stop installing aliased files and your package installs them to /bin via debian/install now. Please change bin/* to bin/* usr/bin to help with the transition. I'm setting severity serious to avoid introducing regressions in trixie. Helmut
Bug#1071142: dnsmasq-base: fails to purge when passwd is not installed
Package: dnsmasq-base Version: 2.90-3 Severity: serious When passwd is not installed, dnsmasq-base fails to purge. | $ mmdebstrap --variant=essential --include=dnsmasq-base --customize-hook='dpkg --root "$1" --remove dnsmasq-base passwd' --customize-hook='dpkg --root "$1" --purge dnsmasq-base' --verbose unstable /dev/null | ... | Purging configuration files for dnsmasq-base (2.90-3) ... | /var/lib/dpkg/info/dnsmasq-base.postrm: 5: userdel: not found | dpkg: error processing package dnsmasq-base (--purge): | installed dnsmasq-base package post-removal script subprocess returned error exit status 127 | Errors were encountered while processing: | dnsmasq-base | ... | $ Arguably, users should not deleted on package removal. Helmut
Bug#1071125: python3-donfig and python3-nabu have an undeclared file conflict on /usr/lib/python3/dist-packages/doc/conf.py
Package: python3-donfig,python3-nabu Version: 0.8.1+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + python3-nabu python3-donfig and python3-nabu have an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/python3/dist-packages/doc/conf.py is contained in the packages * python3-donfig/0.8.1+dfsg-2 as present in trixie|unstable * python3-nabu/2024.1.6-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, I've intentionally snipped much of your reply as I think we two agree on many of the aspects. On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote: > > 1. API expectation of *-$arch-cross packages > > I asked exactly that in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55 I guess the best description is to be found in man dpkg-cross "Conversion process" and even that isn't entirely helpful. > > 4. cross-toolchain-base being bd-uninstallable > > Which directly correlates to undocumented Build-Conflicts in the > package. They neither show up in the changelog or the commit logs. > > >I don't exactly understand why it declares them, but I guess that > >having a different set of kernel headers available in > >/usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build > >and potentially cause misbuilds. cross-toolchain-base builds these > >packages and it also uses them during build of glibc. > > So this reason is now gone. linux-source-* and linux-libc-dev are > similar enough in almost all cases. It's not gone as non-virtual linux-libc-dev-$arch-cross packages are still built from c-t-b. If c-t-b were to stop building them, I'd concur. > > 6. Cross bootstrap cannot tell whether linux-libc-dev supports an > >architecture > > Even in the past it could not. It could try to build the linux package > to see if it gets a working linux-libc-dev. Or have other code to hack > around, like changing the config. In the past, there was no need to tell. It would always build linux-libc-dev. Now that linux-libc-dev works for many but not all architectures, there is a need to tell. > Actually linux-libc-dev-$arch-cross is uncommunicated and uncoordinated > duplication of exactly the same content as linux-libc-dev. It is news to me that it is uncommunicated and uncoordinated, but that very accurately matches the rest of the disagreement. Yes, it is duplication. > 9. linux-libc-dev-*-cross provides incompatible headers to >build-essential > >Both linux-libc-dev and linux-libc-dev-*-cross provide the linux/* >includes that are used by the compiler but of different versions. It >is undefined if those can work with the (always older) asm/* provided >by linux-libc-dev-*-cross. Yes, this is a problem. It kinda is the same problem that we have with libc6-dev vs libc6-dev-$arch-cross and is why libc6-dev declares versioned breaks for libc6-dev-$arch-cross. > > 3. cross-toolchain-base could build a linux-libc-dev-cross package > >that Provides the earlier -$arch-cross packages and contains a > >similar symlink farm to linux-libc-dev. > > This requires coordination of the versions and strict enough > dependencies. So linux-libc-dev-cross would need to come out of the > same source as linux-libc-dev. Technically speaking, a linux-libc-dev-cross package could be built from c-t-b. It would just inherit all the other problems including your problem 9 from the previous approach and only address the space aspect. I listed it more for completeness sake than suggesting we actually go for this. > > 4. cross-toolchain-base could drop its Build-Conflicts. This may cause > >further problems though. > >Patch: https://bugs.debian.org/1067370#17 > > The build will now see multiple architectures of headers. So it needs > to handle this both for native (where build-conflicts can't be used > anyway) and cross the same. I don't understand what you are trying to say here. c-t-b only builds Arch:all packages, so the terms native and cross appear to not apply. Then again we also don't know what "further problems" are. I hope Matthias can shed some light here. > On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote: > > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common > >arch:all m-a:foreign and the symlink farms could be kept in > >linux-libc-dev:any m-a:same retaining the size reduction. > > This would not actually work. linux-libc-dev-common would only contain > known architectures. So the current "change config, build > linux-libc-dev" will not longer work as well. This package would then > depend on a linux-libc-dev-common without the headers for this > architecture. I agree that it is not as simple as I pictured it. I was imagining that a m-a:same linux-libc-dev could simply contain all the architecture-dependent stuff. For many architectures that would practically work initially, but there is no bijective mapping between kernel architecture names and Debian architecture names, so for directories like /usr/lib/linux/uapi/arm is is unclear whether it should be part of linux-libc-dev:armel or linux-libc-dev:armhf or linux-li
Bug#1071010: pcp has an undeclared file conflict on /usr/bin/pmcheck
Package: pcp Version: 6.2.1-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + pmtools pcp has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/pmcheck is contained in the packages * pcp/6.2.1-1 as present in unstable * pmtools * 2.2.0-2 as present in bullseye * 2.2.0-3 as present in bookworm|trixie|unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1071008: libx52pro0: installs udev rules twice to /usr and /
Package: libx52pro0 Version: 0.1.1-3 Severity: serious Justification: policy 10.1 Tags: patch X-Debbugs-Cc: Petter Reinholdtsen Hi, since the last upload, libx52pro0 contains both /lib/udev/rules.d/99-x52pro.rules and /usr/lib/udev/rules.d/99-x52pro.rule. Doing so violates Debian policy section 10.1. The former is installed via the upstream build system combined with dh_install and debian/libx52pro0.install while the latter is installed via debian/*.udev with dh_installudev. Given DEP17, the latter is the desired location. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru x52pro-0.1.1/debian/changelog x52pro-0.1.1/debian/changelog --- x52pro-0.1.1/debian/changelog 2024-05-12 10:39:38.0 +0200 +++ x52pro-0.1.1/debian/changelog 2024-05-12 22:59:37.0 +0200 @@ -1,3 +1,9 @@ +x52pro (0.1.1-4) UNRELEASED; urgency=medium + + * Install udev rules only once. (Closes: #-1) + + -- Helmut Grohne Sun, 12 May 2024 22:59:37 +0200 + x52pro (0.1.1-3) unstable; urgency=medium * QA upload. diff --minimal -Nru x52pro-0.1.1/debian/libx52pro0.install x52pro-0.1.1/debian/libx52pro0.install --- x52pro-0.1.1/debian/libx52pro0.install 2024-05-12 10:14:01.0 +0200 +++ x52pro-0.1.1/debian/libx52pro0.install 2024-05-12 22:59:36.0 +0200 @@ -1,4 +1,3 @@ -lib/udev/rules.d usr/bin/x52output usr/lib/lib*.so.* usr/share/man diff --minimal -Nru x52pro-0.1.1/debian/not-installed x52pro-0.1.1/debian/not-installed --- x52pro-0.1.1/debian/not-installed 1970-01-01 01:00:00.0 +0100 +++ x52pro-0.1.1/debian/not-installed 2024-05-12 22:59:37.0 +0200 @@ -0,0 +1,2 @@ +# Installed via debian/*.udev symbolic link +lib/udev/rules.d
Bug#1071009: libpoppler-cpp0t64 has an undeclared file conflict
Package: libpoppler-cpp0t64 Version: 24.02.0-3 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libpoppler-cpp0v5 libpoppler-cpp0t64 has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0 * /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.11.0 are contained in the packages * libpoppler-cpp0t64/24.02.0-3 as present in unstable * libpoppler-cpp0v5/22.12.0-2+b1 as present in bookworm These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py
Package: sherlock Version: 0.14.3+git20240511.b83f5be-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + pycrc sherlock has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/python3/dist-packages/__init__.py is contained in the packages * pycrc/0.10.0-2 as present in trixie|unstable * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1071006: conky-all, conky-cli and conky-std have an undeclared file conflict
Package: conky-cli,conky-std,conky-all Version: 1.21.0-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + vc-dev conky-all, conky-cli and conky-std have an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/cmake/Vc/AddCompilerFlag.cmake * /usr/lib/cmake/Vc/CheckCCompilerFlag.cmake * /usr/lib/cmake/Vc/CheckCXXCompilerFlag.cmake * /usr/lib/cmake/Vc/FindVc.cmake * /usr/lib/cmake/Vc/OptimizeForArchitecture.cmake * /usr/lib/cmake/Vc/UserWarning.cmake * /usr/lib/cmake/Vc/VcConfig.cmake * /usr/lib/cmake/Vc/VcConfigVersion.cmake * /usr/lib/cmake/Vc/VcMacros.cmake * /usr/lib/cmake/Vc/VcTargets.cmake * /usr/lib/libVc.a are contained in the packages * conky-all/1.21.0-1 as present in unstable * conky-cli/1.21.0-1 as present in unstable * conky-std/1.21.0-1 as present in unstable * vc-dev * 1.4.3-2 as present in bookworm * 1.4.4-1 as present in trixie|unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1071005: rust-llvm has an undeclared file conflict
Package: rust-llvm Version: 1.71.1+dfsg1-1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + rustc rustc-mozilla rustc-web rust-llvm has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/bin/rust-clang * /usr/bin/rust-lld * /usr/bin/rust-llvm-dwp * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld64 are contained in the packages * rust-llvm/1.71.1+dfsg1-1~exp1 as present in experimental * rustc * 1.63.0+dfsg1-2 as present in bookworm * 1.70.0+dfsg2-1 as present in trixie|unstable * rustc-mozilla/1.63.0+dfsg1-2~deb11u1 as present in bullseye * rustc-web/1.70.0+dfsg1-7~deb12u2 as present in bookworm-proposed-updates These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi, In this mail, I'll try to summarize my state of knowledge on this matter while noting that I don't see the full picture. On Fri, Mar 29, 2024 at 11:17:55AM +0100, Bastian Blank wrote: > On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote: > > I was recently working on gcc builds and this disagreement currently > > makes stuff unbuildable. Hence I looked into solutions and/or > > workarounds. > > Care to just share what you actually found? Where is it broken and how > to see this? > > Because this whole thing started with "it is broken, but I won't tell > you where or what or how". Quite clearly, this is not a single problem, but a mesh of problems and in a few cases it is not obvious where to solve them. > > As a result, I implemented the proposed change and am attaching it for > > discussion here. I've implemented it in a way that if there is a sysroot > > linux header installation, it'll be preferred. Do you see any downsides > > of this approach? > > I wonder now. How would that ever work for the native build? Or does > the native build already do those symlinks? Or are native and cross > configured differently? Or is that a weird difference in gcc itself? Native and cross builds work quite differently indeed. So let me first try to collect all relevant problems that I encountered here. I vaguely try to list the more important ones earlier. I have caused some of these problems and don't want to assign any blame but look for solutions. 1. API expectation of *-$arch-cross packages When *-$arch-cross packages were first introduced before multiarch was a thing, there was (and still is) and implicit contract saying that their functionality is to be provided within the /usr/$DEB_HOST_GNU_TYPE hierarchy. In particular, this layout does not interfere with multiarch on a filesystem level and hence *-$arch-cross packages typically are arch:all m-a:foreign. In particular, linux-libc-dev now provides such packages without actually providing those paths violating this implicit contract. 2. Violation of Multi-Arch: foreign linux-libc-dev was changed from an Arch:any + Multi-Arch:same package to an Architecture:all + Multi-Arch:foreign package. It does so by providing the headers for all architectures in a single package via symlink farms. "all" architectures is debatable though. The set of architectures changes rather frequently with new ones being added and old ones being removed. Therefore, linux-libc-dev will often look like it provides linux-libc-dev:$somearch to dependency resolvers while in fact not providing the functionality - thus violating the promise of Multi-Arch: foreign. For example, linux-libc-dev is currently dysfunctional for arc, but next year it'll be a different architecture. Moreover, looking at the metadata of linux-libc-dev initially did not provide means of figuring out which architectures were actually supported and which were not. This has been changed as linux-libc-dev now Provides linux-libc-dev-$arch-cross packages (causing the first problem), but at least giving bootstrappers a means to figure out whether a given linux-libc-dev package is usable to them. 3. linux-libc-dev consumes much space on mirrors and installations linux-libc-dev originally was Arch:any and yet much of its content was the same across architectures albeit in different paths. Thus, the size of the .deb (multiplied by the number of architectures) was quite big and also coinstalling linux-libc-dev would result in duplicate files being extracted to multiple locations increasing the installation size in a multiarch setting. As a result, linux-libc-dev now is Arch:all and we only get to have one package. It grew from about 1.8MB (times 10 architectures) to about 2.2MB and its installed size grew from about 7MB (per architecture) to 10MB (for all architectures). This change caused the second problem. 4. cross-toolchain-base being bd-uninstallable cross-toolchain-base cannot currently be built (FTBFS #1064003 and #1067370) and one of the aspects is that it declares Build-Conflicts with linux-libc-dev-$arch-cross. The recently added Provides on linux-libc-dev satisfy them and thus cause cross-toolchain-base to be bd-uninstallable. I don't exactly understand why it declares them, but I guess that having a different set of kernel headers available in /usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build and potentially cause misbuilds. cross-toolchain-base builds these packages and it also uses them during build of glibc. 5. gcc-V-cross not being buildable The gcc-V-cross package relies on -$arch-cross packages usually built from cross-toolchain-base and expects them to provide their functionality in /usr/$DEB_HOST_GNU_TYPE. Th
Bug#1064003: patch for c-t-b build
Control: tags -1 + patch
Hi Matthias,
I'm attaching a patch for the c-t-b FTBFS. Note that due to the
glibc/2.38 upload c-t-b has become completely uninstallable. Hence, a
timely upload is appreciated. Due to linux-libc-dev currently providing
the -$arch-cross packages, we have to remove the Build-Conflicts or make
rename the Provides on linux-libc-dev. I'm ok with both approaches and
offer dropping the conflict here.
Helmut
diff --minimal -Nru cross-toolchain-base-68/debian/changelog
cross-toolchain-base-68+nmu1/debian/changelog
--- cross-toolchain-base-68/debian/changelog2023-10-31 09:50:26.0
+0100
+++ cross-toolchain-base-68+nmu1/debian/changelog 2024-05-04
09:23:39.0 +0200
@@ -1,3 +1,12 @@
+cross-toolchain-base (68+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Build using linux 6.7. Closes: #1064003, #1067370.
+ * Build using glibc 2.38.
+ * Remove linux-libc-dev-ARCH-cross from GLIBC_BUILD_CONFLICTS.
+
+ -- Helmut Grohne Sat, 04 May 2024 09:23:39 +0200
+
cross-toolchain-base (68) unstable; urgency=medium
* Build using linux 6.5.8. Closes: #1042118.
diff --minimal -Nru cross-toolchain-base-68/debian/control
cross-toolchain-base-68+nmu1/debian/control
--- cross-toolchain-base-68/debian/control 2023-10-31 09:50:26.0
+0100
+++ cross-toolchain-base-68+nmu1/debian/control 2024-05-04 09:23:39.0
+0200
@@ -9,9 +9,9 @@
Build-Depends: binutils-multiarch,
dpkg (>= 1.21.17), rdfind, symlinks, lsb-release,
binutils-source (>= 2.41-6~),
- glibc-source (>= 2.37-3~),
+ glibc-source (>= 2.38),
gcc-12-source (>= 12.3.0-11~), g++-12 (>= 12.3.0-11~),
- linux-source-6.5 (>= 6.5.8), linux-libc-dev (>= 6.5.8),
+ linux-source-6.7 (>= 6.7.0), linux-libc-dev (>= 6.7.0),
autoconf (>= 2.69), autoconf2.69, autogen,
automake, bison (>= 1:2.3), chrpath, debhelper-compat (= 13),
dpkg-dev (>= 1.15.3.1), fakeroot, file, flex,
@@ -27,7 +27,7 @@
libjansson-dev, pkg-config,
Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
binutils-x86-64-linux-gnu [!amd64], binutils-i686-linux-gnu [!i386],
binutils-s390x-linux-gnu [!s390x], binutils-powerpc64le-linux-gnu [!ppc64el],
binutils-aarch64-linux-gnu [!arm64], binutils-arm-linux-gnueabihf [!armhf],
binutils-arm-linux-gnueabi [!armel], binutils-riscv64-linux-gnu [!riscv64],
- libc6-amd64-cross, linux-libc-dev-amd64-cross, libc6-i386-cross,
linux-libc-dev-i386-cross, libc6-s390x-cross, linux-libc-dev-s390x-cross,
libc6-ppc64el-cross, linux-libc-dev-ppc64el-cross, libc6-arm64-cross,
linux-libc-dev-arm64-cross, libc6-armhf-cross, linux-libc-dev-armhf-cross,
libc6-armel-cross, linux-libc-dev-armel-cross, libc6-riscv64-cross,
linux-libc-dev-riscv64-cross,
+ libc6-amd64-cross, libc6-i386-cross, libc6-s390x-cross, libc6-ppc64el-cross,
libc6-arm64-cross, libc6-armhf-cross, libc6-armel-cross, libc6-riscv64-cross,
libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
Package: linux-libc-dev-amd64-cross
diff --minimal -Nru cross-toolchain-base-68/debian/rules
cross-toolchain-base-68+nmu1/debian/rules
--- cross-toolchain-base-68/debian/rules2023-10-31 09:50:26.0
+0100
+++ cross-toolchain-base-68+nmu1/debian/rules 2024-05-04 09:23:39.0
+0200
@@ -61,8 +61,8 @@
CROSS_GNU_TYPE = $(call _gnu_type,${CROSS_ARCH})
CROSS_PKG_GNU_TYPE = $(subst _,-,$(call _gnu_type,${CROSS_ARCH}))
-MIN_VER_GLIBC := 2.37-3~
-MIN_VER_LINUX := 6.5.8
+MIN_VER_GLIBC := 2.38
+MIN_VER_LINUX := 6.7.0
MIN_VER_GCC:= 12.3.0-11~
MIN_VER_BINUTILS := 2.41-6~
VER_GCC_BASE := 12
@@ -110,7 +110,7 @@
# FIXME: No conflict for the host == cross case ...
BINUTILS_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),binutils-$(subst
_,-,$(call _gnu_type,$(a))) [!$(a)]$(,))
-GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,)
linux-libc-dev-$(a)-cross$(,))
+GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,))
# taken from gcc packaging
define unpack_tarball
Bug#1070327: libauparse0t64 fails piuparts: missing postrm for /usr-move mitigation
Source: audit Version: 1:3.1.2-2.1 Severity: serious Justification: fails piuparts, blocks testing migration Tags: patch X-Debbugs-Cc: z...@debian.org Hi, I looked into why audit fails to migrate and noticed that it fails piuparts as it leaves diversions behind after purge. The patch provided by the /usr-move team failed to account for package removal and lacks the postrm bit. I'm attaching a patch that fixes this problem. It also removes the manual interpolation in favour of relying on dh_installdeb's builtin interpolation. I'd appreciate a timely upload, because audit is one of the last missing pieces moving forward with the /usr-move. Would you mind a NMU? Helmut diff --minimal -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog --- audit-3.1.2/debian/changelog2024-02-28 04:02:13.0 +0100 +++ audit-3.1.2/debian/changelog2024-05-03 07:49:46.0 +0200 @@ -1,3 +1,10 @@ +audit (1:3.1.2-2.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix piuparts failure arising from /usr-move mitigation. (Closes: #-1) + + -- Helmut Grohne Fri, 03 May 2024 07:49:46 +0200 + audit (1:3.1.2-2.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.lintian-overrides audit-3.1.2/debian/libauparse0t64.lintian-overrides --- audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-02-28 03:58:37.0 +0100 +++ audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-05-03 07:49:46.0 +0200 @@ -1 +1,2 @@ libauparse0t64: package-name-doesnt-match-sonames libauparse0 +libauparse0t64: remove-of-unknown-diversion lib/* [postrm:*] diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.postrm audit-3.1.2/debian/libauparse0t64.postrm --- audit-3.1.2/debian/libauparse0t64.postrm1970-01-01 01:00:00.0 +0100 +++ audit-3.1.2/debian/libauparse0t64.postrm2024-05-03 07:49:40.0 +0200 @@ -0,0 +1,17 @@ +#!/bin/sh + +set -e + +case $1 in + remove|disappear) + for file in libauparse.so.0 libauparse.so.0.0.0; do + dpkg-divert --package libauparse0t64 --no-rename \ + --remove --divert \ + "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" \ + "/lib/#DEB_HOST_MULTIARCH#/$file" + done + ;; +esac + +#DEBHELPER# + diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst audit-3.1.2/debian/libauparse0t64.preinst --- audit-3.1.2/debian/libauparse0t64.preinst 1970-01-01 01:00:00.0 +0100 +++ audit-3.1.2/debian/libauparse0t64.preinst 2024-05-03 07:49:46.0 +0200 @@ -0,0 +1,17 @@ +#!/bin/sh + +set -e + +case $1 in + install) + for file in libauparse.so.0 libauparse.so.0.0.0; do + dpkg-divert --package libauparse0t64 --no-rename \ + --add --divert \ + "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" \ + "/lib/#DEB_HOST_MULTIARCH#/$file" + done + ;; +esac + +#DEBHELPER# + diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst.in audit-3.1.2/debian/libauparse0t64.preinst.in --- audit-3.1.2/debian/libauparse0t64.preinst.in2024-02-28 04:02:11.0 +0100 +++ audit-3.1.2/debian/libauparse0t64.preinst.in1970-01-01 01:00:00.0 +0100 @@ -1,17 +0,0 @@ -#!/bin/sh - -set -e - -case $1 in - install) - for file in libauparse.so.0 libauparse.so.0.0.0; do - dpkg-divert --package libauparse0t64 --no-rename \ - --divert \ - /lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged \ - /lib/#DEB_HOST_MULTIARCH#/$file - done - ;; -esac - -#DEBHELPER# - diff --minimal -Nru audit-3.1.2/debian/rules audit-3.1.2/debian/rules --- audit-3.1.2/debian/rules2024-02-28 04:02:11.0 +0100 +++ audit-3.1.2/debian/rules2024-05-03 07:47:04.0 +0200 @@ -109,11 +109,6 @@ chgrp adm debian/auditd/var/log/audit chmod -R o-rwx debian/auditd/etc/audit debian/audispd-plugins/etc/audit -override_dh_installdeb: - sed -e"s/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/" \ - debian/libauparse0t64.preinst.in > debian/libauparse0t64.preinst - dh_installdeb - get-orig-source: -uscan --upstream-version 0
Bug#1070256: libcxx-serial FTBFS with the nocheck build profile
Source: libcxx-serial Version: 1.2.1-5 Severity: serious Justification: nocheck ftbfs is rc since trixie Tags: ftbfs trixie sid libcxx-serial fails to build from source when enabling the nocheck build profile. I think the relevant part is: | -- catkin 0.8.10 | -- BUILD_SHARED_LIBS is on | CMake Error at /usr/share/catkin/cmake/test/tests.cmake:21 (message): | () is not available when tests are not enabled. The CMake code should only | use it inside a conditional block which checks that testing is enabled: | | if(CATKIN_ENABLE_TESTING) | | (...) | | endif() | | Call Stack (most recent call first): | tests/CMakeLists.txt:20 (catkin_add_gtest) | | | -- Configuring incomplete, errors occurred! | cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt | ==> CMakeCache.txt <== Helmut
Bug#1070254: ktp-text-ui FTBFS: undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)'
Source: ktp-text-ui Version: 22.12.3-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) ktp-text-ui fails to build from source in unstable on amd64. The relevant log probably is: | [ 76%] Linking CXX executable ktp-text-ui | cd /<>/obj-x86_64-linux-gnu/app && /usr/bin/cmake -E cmake_link_script CMakeFiles/ktp-text-ui.dir/link.txt --verbose=1 | /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -Wl,--enable-new-dtags -Wl,-z,relro "CMakeFiles/ktp-text-ui.dir/ktp-text-ui_autogen/mocs_compilation.cpp.o" "CMakeFiles/ktp-text-ui.dir/main.cpp.o" "CMakeFiles/ktp-text-ui.dir/telepathy-chat-ui.cpp.o" "CMakeFiles/ktp-text-ui.dir/chat-window.cpp.o" "CMakeFiles/ktp-text-ui.dir/chat-tab.cpp.o" "CMakeFiles/ktp-text-ui.dir/emoticon-text-edit-action.cpp.o" "CMakeFiles/ktp-text-ui.dir/emoticon-text-edit-selector.cpp.o" "CMakeFiles/ktp-text-ui.dir/invite-contact-dialog.cpp.o" -o ktp-text-ui -Wl,-rpath,/<>/obj-x86_64-linux-gnu/lib:/<>/obj-x86_64-linux-gnu/image-sharer: /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.15.15 ../lib/libktpchat.so /usr/lib/x86_64-linux-gnu/libKF5PeopleWidgets.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Emoticons.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKTpWidgets.so.22.12.3 /usr/lib/x86_64-linux-gnu/libKTpModels.so.22.12.3.abi1 /usr/lib/x86_64-linux-gnu/libKF5NotifyConfig.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5KCMUtils.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5TextWidgets.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5SonnetUi.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5SonnetCore.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKTpLogger.so.22.12.3.abi1 /usr/lib/x86_64-linux-gnu/libKTpCommonInternals.so.22.12.3.abi1 /usr/lib/x86_64-linux-gnu/libKF5Wallet.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Notifications.so.5.107.0 /usr/lib/x86_64-linux-gnu/libtelepathy-logger-qt.so.0.9.80.0 /usr/lib/x86_64-linux-gnu/libtelepathy-qt5.so.0.0.9.8 /usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5.15.15 /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.15.15 /usr/lib/x86_64-linux-gnu/libQt5WebChannel.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5Positioning.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5QmlModels.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5.15.10 ../image-sharer/libktpimagesharer.so /usr/lib/x86_64-linux-gnu/libKF5KIOWidgets.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5KIOGui.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5JobWidgets.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Service.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Solid.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Completion.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5IconThemes.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5ConfigWidgets.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5ConfigGui.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5ConfigCore.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Codecs.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Auth.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5AuthCore.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5Archive.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5.107.0 /usr/lib/x86_64-linux-gnu/libX11.so /usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.15.10 /usr/lib/x86_64-linux-gnu/libKTpOTR.so.22.12.3 /usr/lib/x86_64-linux-gnu/libtelepathy-qt5.so.0.0.9.8 /usr/lib/x86_64-linux-gnu/libQt5Network.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5Xml.so.5.15.10 -fPIC /usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5People.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5CoreAddons.so.5.107.0 /usr/lib/x86_64-linux-gnu/libKF5I18n.so.5.107.0 /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.10 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10 | /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.15.15: undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)' | collect2: error: ld returned 1 exit status | make[3]: *** [app/CMakeFiles/ktp-text-ui.dir/build.make:220: app/ktp-text-ui] Error 1 | make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' | make[2]: *** [CMakeFiles/Makefile2:1633: app/CMakeFiles/ktp-text-ui.dir/all] Error 2 | make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu' | make[1]: *** [Makefile:149: all] Error 2 |
Bug#1070047: python3-django-pipeline: installs files into aliased locations
Control: tags -1 - patch Hi Alexandre, On Mon, Apr 29, 2024 at 12:35:02PM +0200, Alexandre Detiste wrote: > If I revert the NAME change autodep8 breaks on Salsa Dang. I was looking for what I could have broken and didn't see this. > Is there an easy way to have one name for pybuild and another one for > autodep8 ... ? I ll search. I looked at man pybuild and https://wiki.debian.org/Python/Pybuild and neither was particularly enlightening to me. Possibly setting PYBUILD_NAME=pipeline and PYBUILD_DESTDIR=debian/python3-django-pipeline works? Helmut
Bug#1070047: python3-django-pipeline: installs files into aliased locations
Package: python3-django-pipeline
Version: 3.0.0-1
Severity: serious
Justification: introduces new aliasing
Tags: patch
Control: affects -1 + python3-distutils
User: helm...@debian.org
Usertags: dep17p6
The last upload of python3-django-pipeline moved all of its files from
/usr/lib to /lib. Whils this works somewhat on a /usr-merged
installations, it causes subtle bugs due to dpkg not being prepared with
aliasing. In DEP17, we're resolving this by moving all files out of
aliased locations and python3-django-pipelines has just introduced new.
Hence, I'm filing this at RC severity. I think the move was accidental
and can be fixed by dropping the faulty "mv" command in favour of
setting PYBUILD_NAME to the package name rather than the module name.
I'm attaching a patch for your convenience.
Helmut
diff --minimal -Nru django-pipeline-3.0.0/debian/changelog
django-pipeline-3.0.0/debian/changelog
--- django-pipeline-3.0.0/debian/changelog 2024-04-28 19:35:05.0
+0200
+++ django-pipeline-3.0.0/debian/changelog 2024-04-29 10:17:13.0
+0200
@@ -1,3 +1,10 @@
+django-pipeline (3.0.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not install into /lib. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 29 Apr 2024 10:17:13 +0200
+
django-pipeline (3.0.0-1) unstable; urgency=medium
* Team Upload
diff --minimal -Nru django-pipeline-3.0.0/debian/rules
django-pipeline-3.0.0/debian/rules
--- django-pipeline-3.0.0/debian/rules 2024-04-28 19:35:05.0 +0200
+++ django-pipeline-3.0.0/debian/rules 2024-04-29 10:17:13.0 +0200
@@ -4,7 +4,7 @@
include /usr/share/dpkg/pkg-info.mk
export SETUPTOOLS_SCM_PRETEND_VERSION=${DEB_VERSION_UPSTREAM}
-export PYBUILD_NAME=pipeline
+export PYBUILD_NAME=django-pipeline
export PYBUILD_AFTER_BUILD_python3=PYTHONPATH=. sphinx-build -b html -d
docs/.build/.doctrees -N docs docs/.build/html
# Uncomment this to turn on verbose mode.
@@ -25,6 +25,5 @@
PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version}
/usr/bin/django-admin test --settings=tests.settings" dh_auto_test
execute_after_dh_auto_install:
- mv debian/python3-pipeline/* debian/python3-django-pipeline/
find -type f -name '*.pyc' -delete
find -type d -name __pycache__ -empty -delete
Bug#1069923: util-linux-extra: /usr-move mitigation fails to cover ctrlaltdel
Package: util-linux-extra Version: 2.40-7 Severity: serious Tags: patch Control: affects -1 + util-linux User: helm...@debian.org Usertags: dep17p1 Hi Chris, in my last patch, I trusted your earlier changes too much and failed to notice that it didn't cover ctrlaltdel. I'm attaching a patch to also cover that. Helmut diff --minimal -Nru util-linux-2.40/debian/changelog util-linux-2.40/debian/changelog --- util-linux-2.40/debian/changelog2024-04-26 11:41:02.0 +0200 +++ util-linux-2.40/debian/changelog2024-04-27 08:46:20.0 +0200 @@ -1,3 +1,10 @@ +util-linux (2.40-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Also cover ctrlaltdel in /usr-move mitigation (Closes: #-1). + + -- Helmut Grohne Sat, 27 Apr 2024 08:46:20 +0200 + util-linux (2.40-7) unstable; urgency=medium [ Chris Hofstaedtler ] diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.lintian-overrides util-linux-2.40/debian/util-linux-extra.lintian-overrides --- util-linux-2.40/debian/util-linux-extra.lintian-overrides 2024-04-26 11:41:02.0 +0200 +++ util-linux-2.40/debian/util-linux-extra.lintian-overrides 1970-01-01 01:00:00.0 +0100 @@ -1,2 +0,0 @@ -# DEP17 P1 mitigation -diversion-for-unknown-file sbin/* [preinst:*] diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postrm util-linux-2.40/debian/util-linux-extra.postrm --- util-linux-2.40/debian/util-linux-extra.postrm 2024-04-26 11:41:02.0 +0200 +++ util-linux-2.40/debian/util-linux-extra.postrm 2024-04-27 08:46:12.0 +0200 @@ -3,11 +3,9 @@ set -e if test "$1" = remove || test "$1" = disappear; then - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.minix.usr-is-merged --remove /sbin/mkfs.minix + for f in ctrlaltdel fsck.cramfs fsck.minix mkfs.bfs mkfs.cramfs mkfs.minix; do +dpkg-divert --no-rename --package util-linux-extra --divert "/sbin/$f.usr-is-merged" --remove "/sbin/$f" + done fi #DEBHELPER# diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.preinst util-linux-2.40/debian/util-linux-extra.preinst --- util-linux-2.40/debian/util-linux-extra.preinst 2024-04-26 11:41:02.0 +0200 +++ util-linux-2.40/debian/util-linux-extra.preinst 2024-04-27 08:45:19.0 +0200 @@ -3,11 +3,9 @@ set -e if test "$1" = upgrade || test "$1" = install; then - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.cramfs.usr-is-merged --add /sbin/fsck.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.minix.usr-is-merged --add /sbin/fsck.minix - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.bfs.usr-is-merged --add /sbin/mkfs.bfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.cramfs.usr-is-merged --add /sbin/mkfs.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.minix.usr-is-merged --add /sbin/mkfs.minix + for f in ctrlaltdel fsck.cramfs fsck.minix mkfs.bfs mkfs.cramfs mkfs.minix; do +dpkg-divert --no-rename --package util-linux-extra --divert "/sbin/$f.usr-is-merged" --add "/sbin/$f" + done fi #DEBHELPER#
Bug#1069064: util-linux-extra: insufficient Replaces for util-linux due to /usr-move
Control: tags -1 + patch Hi Chris, On Tue, Apr 16, 2024 at 09:44:13AM +0200, Chris Hofstaedtler wrote: > I think half of 2) exists now, but Conflicts: util-linux will > probably end badly as you note. I'd welcome a patch implementing 3). > > Initially I favored 1), but then u-l will never make progress on > moving the non-essential files. Thanks for pinging me. I observe that util-linux-extra already had mitigations except that preinst and postinst were swapped. Additionally, it did not have Conflicts, which allow for unpacking an aliased util-linux concurrently with a moved util-linux-extra despite the protective diversions being removed. Since we want to avoid the Conflicts, I've extended the protective diversions until postrm. In trixie's postinst we can then remove them for good. Unfortunately, that also means that we cannot use begin-remove-after magic. Helmut diff --minimal -Nru util-linux-2.40/debian/changelog util-linux-2.40/debian/changelog --- util-linux-2.40/debian/changelog2024-04-15 09:51:01.0 +0200 +++ util-linux-2.40/debian/changelog2024-04-26 07:32:56.0 +0200 @@ -1,3 +1,10 @@ +util-linux (2.40-6.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix /usr-move mitigation. (Closes: #1069064) + + -- Helmut Grohne Fri, 26 Apr 2024 07:32:56 +0200 + util-linux (2.40-6) unstable; urgency=medium * Add upstream patches fixing enosys on m68k, sh and dmesg -H output diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.lintian-overrides util-linux-2.40/debian/util-linux-extra.lintian-overrides --- util-linux-2.40/debian/util-linux-extra.lintian-overrides 1970-01-01 01:00:00.0 +0100 +++ util-linux-2.40/debian/util-linux-extra.lintian-overrides 2024-04-26 07:32:56.0 +0200 @@ -0,0 +1,2 @@ +# DEP17 P1 mitigation +diversion-for-unknown-file sbin/* [preinst:*] diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postinst util-linux-2.40/debian/util-linux-extra.postinst --- util-linux-2.40/debian/util-linux-extra.postinst2024-04-15 09:51:01.0 +0200 +++ util-linux-2.40/debian/util-linux-extra.postinst1970-01-01 01:00:00.0 +0100 @@ -1,15 +0,0 @@ -#!/bin/sh - -set -e - -# begin-remove-after: released:trixie -if test "$1" = upgrade || test "$1" = install; then - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.cramfs.usr-is-merged --add /sbin/fsck.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.minix.usr-is-merged --add /sbin/fsck.minix - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.bfs.usr-is-merged --add /sbin/mkfs.bfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.cramfs.usr-is-merged --add /sbin/mkfs.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.minix.usr-is-merged --add /sbin/mkfs.minix -fi -# end-remove-after - -#DEBHELPER# diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postrm util-linux-2.40/debian/util-linux-extra.postrm --- util-linux-2.40/debian/util-linux-extra.postrm 1970-01-01 01:00:00.0 +0100 +++ util-linux-2.40/debian/util-linux-extra.postrm 2024-04-26 07:32:56.0 +0200 @@ -0,0 +1,14 @@ +#!/bin/sh + +set -e + +if test "$1" = remove || test "$1" = disappear; then + dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs + dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix + dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs + dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs + dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.minix.usr-is-merged --remove /sbin/mkfs.minix +fi + +#DEBHELPER# + diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.preinst util-linux-2.40/debian/util-linux-extra.preinst --- util-linux-2.40/debian/util-linux-extra.preinst 2024-04-15 09:51:01.0 +0200 +++ util-linux-2.40/debian/util-linux-extra.preinst 2024-04-26 07:32:56.0 +0200 @@ -2,15 +2,12 @@ set -e -# begin-remove-after: released:trixie -if test "$1" = configure; then - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs - dpkg-divert --no-rename --package util-linux-extra --divert /sbin/mkfs.minix.usr-is
Bug#1069815: wesnoth-1.8-server: new package installs systemd unit in aliased location
Package: wesnoth-1.18-server Version: 1:1.17.26-1 Severity: serious Justification: do not introduce aliased files into Debian Hi, I noticed that wesnoth-1.18-server is a new package and installs a file below /lib, which is an aliased location that we try to empty to complete the /usr-move transition via DEP17. I am filing this bug at RC-severity to stop it from migrating to trixie and hope you agree with this. Please downgrade if you disagree though note that this kind of issue will become an RC-bug for all packages later in the trixie cycle. The simplest fix to this problem is changing SYSTEMD_SERVICE = debian/wesnoth-$(BRANCH_VERSION)-server/lib/systemd/system/wesnoth-$(BRANCH_VERSION)-server.service in debian/rules and move the file to /usr/lib. This is mostly safe for backports, except that bookworm's debhelper will fail to generate necessary maintainer scripts. Please bump your debhelper dependency to 13.11.6 (available in bookworm-backports). Alternatively, adding dh-sequence-movetousr to Build-Depends should also resolve the matter, but for a new package I'd prefer to fix this right from the start. Both solutions are likely applicable to other wesnoth versions as well, though we don't consider those RC-bugs yet. Helmut
Bug#1069687: librust-bitflags-1-dev: fails to co-install
Hi Matthias, On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote: > This is the same situation as in #1040477. This is an issue wrt how we > generate the semvers. I image rust-proc-macro-crate-1 would pose the same > problem. Quoting you from 1040477: Right! > Is the only workaround dropping Ma:same here ? I see very little alternatives. We must choose: * Do not combine M-A:same + Provides: foo + Breaks: foo. * Fix dose/apt/dpkg to agree on what this means. If we were to adapt dose and apt, they's simply arrive at the conclusion that M-A:same would not work here so that really is not what you'd want here. This amounts to fixing dpkg to allow this very combination in the same way that apt and dose allow it. So yeah, changing dpkg could be an option. Ccing dpkg-devel about it. The first alternative means that we must not combine them at the same time. As we very much want M-A:same, we must not have this combination of Provides and Brekas. Keep in mind that they serve slightly different purposes. We have Breaks + Replaces and you can only replace a real package but Provides introduce a virtual package. In effect we're dealing with a package that sometimes is virtual and other times is real. We can choose different names for these uses. The real package could be renamed and also provide the virtual facility. All of them would now provide the virtual one as virtual only and none of them would have the virtual name. The Breaks and Replaces would be updated to match the real name. This may not work for the in-archive situations right now as Breaks and Replaces may still be necessary for upgrades, but it is something that may work in future situations of the same kind. In the mean time, consider that M-A:same presently is a lie. Removing it is better than continuing to lie. It's not like we must have everything in perfect multiarch. Even for cross compilation, we often can get away without M-A:same by only requiring a package for the host architecture. M-A:same is not the goal. It's a tool and way may consider using other tools. Helmut
Bug#1069689: mandos lost mandos.service systemd unit
Source: mandos Version: 1.8.16-1.1 Severity: serious Tags: patch Justification: prevent testing migration after unintentional deletion of systemd unit X-Debbugs-Cc: Bastian Germann User: helm...@debian.org Usertags: dep17p6 The last mandos upload is the first after systemd.pc having moved systemdsystemunitdir from /lib to /usr/lib. mandos' upstream Makefile uses this to see where to install units to, but it also only does that if the relevant directory exists. Now since the new location wasn't created, it ceased installing the unit. We need to create the new location to reinstate the unit. Patch attached. I think the loss of the unit is unintantional and for that reason file this as rc bug. Please adjust if you disagree. This change makes mandos backports-unsafe. I don't expect mandos to be backported. Helmut diff --minimal -Nru mandos-1.8.16/debian/changelog mandos-1.8.16/debian/changelog --- mandos-1.8.16/debian/changelog 2024-04-19 13:08:30.0 +0200 +++ mandos-1.8.16/debian/changelog 2024-04-22 21:13:43.0 +0200 @@ -1,3 +1,10 @@ +mandos (1.8.16-1.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install mandos.service again. (Closes: #-1) + + -- Helmut Grohne Mon, 22 Apr 2024 21:13:43 +0200 + mandos (1.8.16-1.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru mandos-1.8.16/debian/mandos.dirs mandos-1.8.16/debian/mandos.dirs --- mandos-1.8.16/debian/mandos.dirs2019-08-18 21:51:02.0 +0200 +++ mandos-1.8.16/debian/mandos.dirs2024-04-22 21:13:43.0 +0200 @@ -5,6 +5,6 @@ etc/dbus-1/system.d usr/sbin var/lib/mandos -lib/systemd/system usr/lib/tmpfiles.d usr/lib/sysusers.d +usr/lib/systemd/system
Bug#1069688: libsequoia-octopus-librnp has an undeclared file conflict on /usr/lib/thunderbird/librnp.so
Package: libsequoia-octopus-librnp Version: 1.8.1-3 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + thunderbird libsequoia-octopus-librnp has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/thunderbird/librnp.so is contained in the packages * libsequoia-octopus-librnp/1.8.1-3 as present in unstable * thunderbird/1:122.0~b2-1 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1069687: librust-bitflags-1-dev: fails to co-install
Package: librust-bitflags-1-dev Version: 1.3.2-5+b1 Severity: serious Justification: causes an installation failure Hi, Attempting to install librust-bitflags-1-dev for multiple architectures fails, because apt and dpkg disagree about how breaks and provides work. apt thinks that self-breaks can be ignored, but dpkg thinks that since librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it cannot be coinstalled and gives up. You cannot combine such breaks+provides with m-a:same. The simplest workaround here is dropping m-a:same as it cannot be exercised anyway. Helmut
Bug#1069630: libcupsfilters-dev and libcupsfilters2-dev have an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libcupsfilters.a, /usr/lib/x86_64-linux-gnu/libcupsfilters.so and /usr/lib/x86_64-
Package: libcupsfilters2-dev Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libcupsfilters-dev The files * /usr/lib/x86_64-linux-gnu/libcupsfilters.a * /usr/lib/x86_64-linux-gnu/libcupsfilters.so * /usr/lib/x86_64-linux-gnu/pkgconfig/libcupsfilters.pc are contained in the packages * libcupsfilters-dev/1.28.17-4 as present in unstable * libcupsfilters2-dev/2.0.0-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Please figure out which of these packages should properly own the affected files and reassign the bug as appropriate. When doing so, please add the other package to the set of affected packages using "Control: affects -1 + " to avoid the filing of duplicates. The other package should stop installing the files. In case the files are being moved between packages, Breaks and Replaces should be declared. In this case, please refer to policy section 7.6 for details. Another useful resource is https://wiki.debian.org/PackageTransition. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1069299: kodi-visualization-waveform FTBFS on arm*: does not agree on gl vs gles
Source: kodi-visualization-waveform Version: 20.2.1+ds1-1 Severity: serious Tags: ftbfs kodi-visualization-waveform fails to build from source on arm architectures. A build fails like this: | CMake Error at /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message): | Could NOT find OpenGLES (missing: OPENGLES_gl_LIBRARY OPENGLES_INCLUDE_DIR) | Call Stack (most recent call first): | /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE) | FindOpenGLES.cmake:37 (find_package_handle_standard_args) | CMakeLists.txt:41 (find_package) Looking into CMakeLists.txt, one can see that it takes the APP_RENDER_SYSTEM=gles path. I guess this is rooted in kodi recently having changed this for all arm architectures via #1056563. Now kodi-visualization-waveform does not have any dependency on gles libraries but happens to pull gl libraries transitively. As a result the build now fails. I'm not sure whether this is to be fixed in kodi-visualization-waveform or kodi. The end result is that this very package FTBFS. Hence filing here initially, but reassigning may still make sense. Helmut
Bug#1069064: util-linux-extra: insufficient Replaces for util-linux due to /usr-move
Package: util-linux-extra Version: 2.40-6 Severity: serious User: helm...@debian.org Usertags: dep17p1 Control: affects -1 + util-linux Hi Chris, I think I mentioned this on IRC already and you intended to revert, but nothing happened, so lets turn this into a bug for tracking purposes at least. util-linux-extra gained the utils ctrlaltdel, fsck.cramfs, fsck.minix, mkfs.bfs, mkfs.cramfs, and mkfs.minix. In util-linux-extra, these now reside below /usr/sbin while they used to reside in /sbin in util-linux in bookworm and earlier. Hence upgrading from bookworm to sid can cause these files to be lost. I think we have three ways to address this: 1. Revert the move and retry after trixie. I think you favoured this? 2. Upgrade Breaks to Conflicts and issue a temporary protective diversion from u-l-e.preinst to u-l-e.postinst. In theory, apt can first unpack u-l, then unpack u-l-e and then configure both, so there is a safe solution. However, there is a risk that apt could decide to temporarily remove u-l and that would be really bad. 3. Keep Breaks and issue temporary diversions to be removed in forky's u-l-e.postinst. Please let me know your choice and I can do a patch. Helmut
Bug#1069030: subread FTBFS on 32bit architectures: -Werror=implicit-function-declaration
Source: subread Version: 2.0.6+dfsg-2 Severity: serious Tags: ftbfs subread fails to build from source on 32bit architectures: A non-parallel build contains: | i686-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -mtune=generic -msse3 -O3 -fsigned-char -Wall -DMAKE_FOR_EXON -D MAKE_STANDALONE -D SUBREAD_VERSION=\""2.0.6"\" -D_FILE_OFFSET_BITS=64 -fmessage-length=0 -ggdb -Wdate-time -D_FORTIFY_SOURCE=2 -c -o input-files.o input-files.c | input-files.c: In function ‘f_subr_open’: | input-files.c:54:24: error: implicit declaration of function ‘fopen64’; did you mean ‘gzopen64’? [-Werror=implicit-function-declaration] |54 | return fopen64(fname, mode); | |^~~ | |gzopen64 Helmut
Bug#1068808: openmpi-bin has an undeclared file conflict on /usr/bin/pterm
Package: openmpi-bin Version: 5.0.3-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + pterm openmpi-bin has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/pterm is contained in the packages * openmpi-bin/5.0.3-1 as present in experimental * pterm * 0.74-1+deb11u1 as present in bullseye|bullseye-security * 0.78-2+deb12u1 as present in bookworm|bookworm-security * 0.80-1 as present in trixie * 0.80-1+b1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Hi Aurelien,
On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> Thanks for you analysis and your patch. In short your proposal is to
> extend the initial patch from Steve to fully hide the fact that the
> compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
>
> This indeed works and fixes the FTBFS. However it seems that, at least
> for some of the issues, it just hides them. For instance the wrong type
> for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> conformance tests. Quoting utmpx.h/conform.out:
I think this needs a more nuanced look. From the comments in the
conformance test suite, it is evident that it expects to be run without
_FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
exist only exist when these macros are unset. The conformance test suite
has a comment saying that it should be testing the case where
_FILE_OFFSET_BITS is defined, but it currently does not provide
expectations for that case.
Before we can reasonably run the conformance test suite with these
macros set (and really, the test suite should be in control of these
macros), we cannot reasonably use it with them set. Let us now imagine a
future where the conformance test suite has been extended to provide
expectations (which in lots of cases means that *64 symbols disappear
when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:
> | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have
> ‘__suseconds64_t’ {aka ‘long long int’}
> | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> | | ^
> | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with
> type ‘suseconds_t’ {aka ‘long int’}
> | 3 | extern suseconds_t b2_10;
> | |^
> | FAIL: Type of member tv_usec
Indeed, this is not something that can easily be fixed and where
upstream is still debating on what the correct solution should be. It
also is an issue that existed for a long time. If you head over to a
bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
it is not one that is directly related to Debian changing the default.
We merely increased the visibility of this problem that existed earlier
already.
Given that
* the issue is already present in bookworm,
* there are two mutually exclusive solutions and
* upstream is still discussing the best solution
I recommend deferring this aspect.
> And we know it is the reason for the FTBFS of libflorist [2], so should
> we just ignore that issue anyway?
The libflorist issue likely is a consequence. It arises from
gnat_to_gnu_field where GNAT verifies that the value (of type
suseconds_t) to be assigned to a field (tv_usec) has the matching size.
This is directly based on the POSIX expectation and will be fixed with
the glibc issue.
How about filing a separate bug with glibc that tracks this POSIX
divergence and mark the libflorist bug as being blocked by this other
glibc bug? It can be RC or not, but since it affects bookworm, it won't
block testing migration.
Helmut
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Control: tags -1 + patch
Hi Aurelien and Canonical folks,
On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> except i386.
>
> This has been partially fixed in the 2.37-15.1 NMU by adding
> -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:
There are two subtleties about -U_TIME_BITS in a moment.
> | +-+
> | | Encountered regressions that don't match expected failures. |
> | +-+
> | FAIL: conform/ISO/stdio.h/linknamespace
The detail for this failure is:
| [initial] fgetpos64
| [initial] fopen64
| [initial] freopen64
| [initial] fsetpos64
| [initial] tmpfile64
What linknamespace.py wants to tell us here is that it expected
fgetpos64, but no fgetpos64 was declared. It was not declared, because
there is no difference between fgetpos and fgetpos64 after defining
-D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).
The other failures are of very similar kind, but there also is another
kind.
> | FAIL: conform/POSIX/sys/stat.h/conform
The detail for this failure contains:
| /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have
'__time64_t' {aka 'long long int'}
|90 | extern __typeof__ (a2_8.st_atime) b2_8;
| | ^~~~
| /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with type
'__time_t' {aka 'long int'}
|89 | extern __time_t b2_8;
| | ^~~~
Here, it tells us that it expected the st_atime field of struct stat to
have type __time_t (the 32 bit one), but it really has __time64_t.
Looking at the invocation of linknamespace.py you can see:
| python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12'
--flags='-I../include
-I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc
-I../sysdeps/unix/sysv/linux/arm/le -I../sysdeps/unix/sysv/linux/arm
-I../sysdeps/arm/nptl -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
-I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/arm/le/armv7/multiarch -I../sysdeps/arm/armv7/multiarch
-I../sysdeps/arm/le/armv7 -I../sysdeps/arm/armv7 -I../sysdeps/arm/armv6t2
-I../sysdeps/arm/armv6 -I../sysdeps/arm/le -I../sysdeps/arm/include
-I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic
-nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem
/build/reproducible-path/glibc-2.37/debian/include -I..' ...
In particular, what you do not see is -U_TIME_BITS inside --flags.
> Ubuntu has just ignored those failures for now, but I am just afraid
> that if we do the same, nobody will fix them.
Armed with this knowledge, I think we need two changes. For one thing
debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
to revert any possible ABI changing effects. For another, the
conformance tests use independent compiler flags defined in
conform/Makefile. There, a naive patch seems to be:
-conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
+conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include
$(+sysdep-includes) $(sysincludes) -I..
With these two changes, I am able to successfully build glibc on armhf
with the conformance test suite passing.
> In addition it means that upstream glibc does not build anymore by
> default on a 32-bit Debian. Not really a Debian issue, but that is not
> nice either and should probably be fixed.
I think that latter change may be applicable upstream. Running the
conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
is not expected nor supported. This is partially evident from
conform/linknamespace.py in a comment:
| # * Header inclusions should be compiled several times with
| # different options such as -O2, -D_FORTIFY_SOURCE and
| # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
| # from such a compilation; this is not yet implemented.
The conformance test suite clearly wants to manage these macros (and its
effects on symbols) explicitly and does not expect them to be
pre-defined.
Hope this helps
Helmut
Bug#1068610: dico: binary-all FTBFS
Control: tags -1 + patch Hi Adrian, On Mon, Apr 08, 2024 at 02:03:01AM +0300, Adrian Bunk wrote: > Source: dico > Version: 2.11-4 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: Helmut Grohne Thank you for notifying me. Mea culpa. Patch attached. > https://buildd.debian.org/status/logs.php?pkg=dico=all > > ... >debian/rules execute_after_dh_installsystemd > make[1]: Entering directory '/<>' > ln -s dicod.service debian/dicod/`test -e > debian/dicod/lib/systemd/system/dicod.service || echo > usr/`lib/systemd/system/dictd.service > ln: failed to create symbolic link > 'debian/dicod/usr/lib/systemd/system/dictd.service': No such file or directory > make[1]: *** [debian/rules:52: execute_after_dh_installsystemd] Error 1 Helmut diff --minimal -Nru dico-2.11/debian/changelog dico-2.11/debian/changelog --- dico-2.11/debian/changelog 2024-03-01 12:57:59.0 +0100 +++ dico-2.11/debian/changelog 2024-04-08 09:21:47.0 +0200 @@ -1,3 +1,10 @@ +dico (2.11-4.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix indep-only FTBFS arising from #1054187. (Closes: #1068610) + + -- Helmut Grohne Mon, 08 Apr 2024 09:21:47 +0200 + dico (2.11-4.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru dico-2.11/debian/rules dico-2.11/debian/rules --- dico-2.11/debian/rules 2023-11-20 17:26:32.0 +0100 +++ dico-2.11/debian/rules 2024-04-08 09:21:31.0 +0200 @@ -48,5 +48,5 @@ mkdir -p $(TEST_HOME) HOME=$(TEST_HOME) dh_auto_test || cat dicod/tests/testsuite.log -execute_after_dh_installsystemd: +execute_after_dh_installsystemd-arch: ln -s dicod.service debian/dicod/`test -e debian/dicod/lib/systemd/system/dicod.service || echo usr/`lib/systemd/system/dictd.service
Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a
Package: libdialog-dev Version: 1.3-20240307-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + dialog libdialog-dev has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/x86_64-linux-gnu/libdialog.a is contained in the packages * dialog * 1.3-20201126-1 as present in bullseye * 1.3-20230209-1 as present in bookworm * 1.3-20240101-1 as present in trixie * libdialog-dev/1.3-20240307-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1067790: nut: move files to /usr (DEP17) and partially revert time64
Package: libnutclient2t64,libnutscan2t64,libupsclient6t64
Version: 2.8.1-3.1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 + libnutclient2 libnutscan2 libupsclient6
Hi,
a number of packages from src:nut install files in aliased locations. In
order to finalize the /usr-merge, we want to move all of them below /usr
as doing so removes the bad effects arising from aliasing.
Unfortunately, the time64 transition renamed libraries built from nut,
so we are triggering a file loss scenario (DEP17 P1) - exactly the thing
we want to avoid in future by moving them. To complete this transition
in trixie, we have to add a mitigation (protective diversion) and this
is why I am sending a patch.
Said diversion incurs non-trivial maintainer scripts that are best
avoided if possible. Therefore, I reviewed the time64 transition and
concluded that the ABI of libnutscan did not change. I therefore propose
reverting the time64 transition for libnutscan only. The other two
libraries do change ABI and need to be renamed. In reverting libnutscan,
we also eliminate the need to mitigate the file loss. I have set the
severity of this bug to serious to prevent libnutscan2t64 from
transitioning to trixie. The time64 transition should either be reverted
before it transitions to trixie or not at all. If you think that it
should not be reverted, please lower the severity of this bug and I'll
send an updated patch. I note that having fewer library renames makes
the bookworm -> trixie upgrade easier, so reverting (when correct)
generally is a good thing (and it also reduces maintainer script
complexity).
I have tested this patch using piuparts. This happens to fail, because
some fontconfig files below /etc are not properly removed. I believe
this failure is unrelated to my change. I also tested for the particular
file loss scenario specifically.
mmdebstrap trixie /dev/null --variant=apt --include libnutclient-dev
--customize-hook='echo "deb http://deb.debian.org/debian sid main" >
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get
update" --customize-hook="upload libnutclient2t64_2.8.1-3.2_amd64.deb /l.deb"
--customize-hook="upload libnutclient-dev_2.8.1-3.2_amd64.deb /d.deb"
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb;
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"
mmdebstrap trixie /dev/null --variant=apt --include libupsclient-dev
--customize-hook='echo "deb http://deb.debian.org/debian sid main" >
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get
update" --customize-hook="upload libupsclient6t64_2.8.1-3.2_amd64.deb /l.deb"
--customize-hook="upload libupsclient-dev_2.8.1-3.2_amd64.deb /d.deb"
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb;
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"
Last but not least, this patch must not be uploaded to
bookworm-backports or earlier as it would violate the file move
moratorium there. If you plan to backport nut, you must revert both the
time64 transition and this patch.
Helmut
diff -Nru nut-2.8.1/debian/changelog nut-2.8.1/debian/changelog
--- nut-2.8.1/debian/changelog 2024-02-29 02:26:20.0 +0100
+++ nut-2.8.1/debian/changelog 2024-03-26 14:40:41.0 +0100
@@ -1,3 +1,11 @@
+nut (2.8.1-3.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert unnecessary time64 transition for libnutscan.
+ * Move files to /usr. (Closes: #-1)
+
+ -- Helmut Grohne Tue, 26 Mar 2024 14:40:41 +0100
+
nut (2.8.1-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru nut-2.8.1/debian/control nut-2.8.1/debian/control
--- nut-2.8.1/debian/control2024-02-29 02:26:20.0 +0100
+++ nut-2.8.1/debian/control2024-03-26 14:40:41.0 +0100
@@ -203,7 +203,7 @@
Package: libupsclient6t64
Provides: ${t64:Provides}
Replaces: libupsclient6
-Breaks: libupsclient6 (<< ${source:Version})
+Conflicts: libupsclient6 (<< ${source:Version})
Section: libs
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -238,7 +238,7 @@
Package: libnutclient2t64
Provides: ${t64:Provides}
Replaces: libnutclient2
-Breaks: libnutclient2 (<< ${source:Version})
+Conflicts: libnutclient2 (<< ${source:Version})
Section: libs
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -269,10 +269,10 @@
.
This package provides the development files for the new client library.
-Package: libnutscan2t64
-Provides: ${t64:Provides}
-Replaces: libnutscan2
-Breaks: libnutscan2 (<< ${source:Version})
+Package: libnutscan2
+Provides: libnutscan2t64 (= ${binary:Version})
+Replaces: libnutscan2t64
+Breaks: libnutscan2t64 (<< ${source:Version})
Section: libs
Archi
Bug#1067776: openrc: move files to /usr (DEP17) and revert unnecessary time64 transition
Package: openrc,libeinfo1,libeinfo1t64,librc1t64
Version: 0.53-1.1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 librc1
Hi,
I am sending you a patch for moving files to /usr for DEP17, because
doing so requires mitigations due to time64 having renamed libraries. In
particular, I verified that libeinfo did not actually break ABI.
Therefore, I am proposing to revert the time64 transition for libeinfo.
As a consequence of the reversion, we need fewer /usr-move mitigations.
We still need the mitigation for librc though. I have set the severity
of this bug to serious to prevent libeinfo1t64 from migrating to trixie.
It should either be reverted before migration or it should not be
reverted. If you disagree with the reversion, please lower the severity
of this bug and I'll send a patch that extends the mitigation to
libeinfo. That said, fewer library renames make upgrades less painful.
I've tested the patch using piuparts and with a manual test case
precisely triggering the DEP17 P1 file loss scenario:
mmdebstrap trixie /dev/null --variant=apt --include librc-dev
--customize-hook='echo "deb http://deb.debian.org/debian sid main" >
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get
update" --customize-hook="upload librc1t64_0.53-1.2_amd64.deb /l.deb"
--customize-hook="upload librc-dev_0.53-1.2_amd64.deb /d.deb"
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb;
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"
Do note that this patch must not be backported to bookworm-backports or
earlier. If you intend to backport, you must revert both this patch and
the time64 transition for your backport.
I recommend uploading this sooner rather than later, because the
reversion helps people who have not yet upgraded libeinfo to unstable.
Helmut
diff -Nru openrc-0.53/debian/changelog openrc-0.53/debian/changelog
--- openrc-0.53/debian/changelog2024-02-29 13:48:11.0 +0100
+++ openrc-0.53/debian/changelog2024-03-26 15:56:35.0 +0100
@@ -1,3 +1,11 @@
+openrc (0.53-1.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert unnecessary time64 transition for libeinfo
+ * Move files to /usr and mitigate file loss (DEP17) (Closes: #-1).
+
+ -- Helmut Grohne Tue, 26 Mar 2024 15:56:35 +0100
+
openrc (0.53-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru openrc-0.53/debian/control openrc-0.53/debian/control
--- openrc-0.53/debian/control 2024-02-29 13:48:11.0 +0100
+++ openrc-0.53/debian/control 2024-03-26 15:56:35.0 +0100
@@ -47,7 +47,7 @@
Package: librc1t64
Provides: ${t64:Provides}
Replaces: librc1
-Breaks: librc1 (<< ${source:Version})
+Conflicts: librc1 (<< ${source:Version})
Architecture: any
Section: libs
Depends: ${misc:Depends},
@@ -84,10 +84,10 @@
.
This package provides development files for the runtime library.
-Package: libeinfo1t64
-Provides: ${t64:Provides}
-Replaces: libeinfo1
-Breaks: libeinfo1 (<< ${source:Version})
+Package: libeinfo1
+Provides: libeinfo1t64
+Replaces: libeinfo1t64
+Breaks: libeinfo1t64 (<< ${source:Version})
Architecture: any
Section: libs
Depends: ${misc:Depends},
@@ -110,7 +110,7 @@
Package: libeinfo-dev
Architecture: any
Section: libdevel
-Depends: libeinfo1t64 (=${binary:Version}),
+Depends: libeinfo1 (=${binary:Version}),
${misc:Depends},
Multi-Arch: same
Description: dependency based service manager (pretty console display
development)
diff -Nru openrc-0.53/debian/libeinfo-dev.links
openrc-0.53/debian/libeinfo-dev.links
--- openrc-0.53/debian/libeinfo-dev.links 2024-01-22 18:18:38.0
+0100
+++ openrc-0.53/debian/libeinfo-dev.links 2024-03-26 15:56:35.0
+0100
@@ -1,3 +1,3 @@
#! /usr/bin/dh-exec
-lib/${DEB_HOST_MULTIARCH}/libeinfo.so.1
usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so
+usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so.1
usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so
diff -Nru openrc-0.53/debian/libeinfo1.install
openrc-0.53/debian/libeinfo1.install
--- openrc-0.53/debian/libeinfo1.install1970-01-01 01:00:00.0
+0100
+++ openrc-0.53/debian/libeinfo1.install2024-03-26 15:56:35.0
+0100
@@ -0,0 +1 @@
+usr/lib/*/libeinfo.so.*
diff -Nru openrc-0.53/debian/libeinfo1t64.install
openrc-0.53/debian/libeinfo1t64.install
--- openrc-0.53/debian/libeinfo1t64.install 2024-01-22 18:18:38.0
+0100
+++ openrc-0.53/debian/libeinfo1t64.install 1970-01-01 01:00:00.0
+0100
@@ -1 +0,0 @@
-lib/*/libeinfo.so.*
diff -Nru openrc-0.53/debian/libeinfo1t64.lintian-overrides
openrc-0.53/debian/libeinfo1t64.lintian-overrides
--- openrc-0.53/debian/libeinfo1t64.lintian-overrides 2024-02-29
13:48:06.0 +0100
+++ openrc-0.53/debian/libeinfo1t64.lintian-overrides 1970-01-01
Bug#1063664: gcc-13-cross: file conflicts between gnat-13- and gnat-{9,10}-
user debian...@lists.debian.org
usertags 1063664 + fileconflict
reassign 1063664
gnat-13-aarch64-linux-gnu,gnat-13-arm-linux-gnueabihf,gnat-13-i686-linux-gnu,gnat-13-powerpc64le-linux-gnu,gnat-13-riscv64-linux-gnu,gnat-13-s390x-linux-gnu
found 1063664 10.5.0-1cross2
affects 1063664 + gnat-10-aarch64-linux-gnu gnat-10-arm-linux-gnueabihf
gnat-10-i686-linux-gnu gnat-10-powerpc64le-linux-gnu gnat-10-riscv64-linux-gnu
gnat-10-s390x-linux-gnu gnat-11-aarch64-linux-gnu gnat-11-arm-linux-gnueabihf
gnat-11-i686-linux-gnu gnat-11-powerpc64le-linux-gnu gnat-11-riscv64-linux-gnu
gnat-11-s390x-linux-gnu gnat-12-aarch64-linux-gnu gnat-12-arm-linux-gnueabihf
gnat-12-i686-linux-gnu gnat-12-powerpc64le-linux-gnu gnat-12-riscv64-linux-gnu
gnat-12-s390x-linux-gnu gnat-9-aarch64-linux-gnu gnat-9-arm-linux-gnueabihf
gnat-9-i686-linux-gnu gnat-9-powerpc64le-linux-gnu gnat-9-riscv64-linux-gnu
gnat-9-s390x-linux-gnu
tags 1063664 + patch
thanks
On Sat, Feb 10, 2024 at 07:55:09PM +0100, Andreas Beckmann wrote:
> there are undeclared file conflicts between gnat-13- and
> gnat-{9,10}- in sid. (but not between -9- and -10-).
> Maybe it would be sufficient to rebuild the package against gcc-13
> 13.2.0-13 which had some gnat conflict fixes.
I confirm. Usually, the higher gnat version declares Conflicts for the
lower one. Starting with gcc-14, the unversioned link is no longer
provided and gnat is part of gcc-defaults, so this problem will go away
in future. I also verified that src:gcc-13 already issues these
Conflicts and that a no-change upload of gcc-13-cross adds these
Conflicts to the cross toolchain packages. Hence tagging the issue as
patch.
Matthias, would you do that upload?
Helmut
Bug#1041832: #1041832: libsequoia-octopus-librnp: undeclared file conflict with thunderbird
Hi Holger, On Fri, Mar 22, 2024 at 07:36:37PM +, Holger Levsen wrote: > < h01ger> helmut: re: #1041832: i just could not reproduce this bug, see > https://paste.debian.net/1311659/ - though we "didnt change > anything" in sequoia-octopus, so what am i missing? :) > > that paste had basically this content: > > ± dpkg -L libsequoia-octopus-librnp |grep librnp.so > /usr/lib/sequoia/libsequoia_octopus_librnp.so > /usr/lib/thunderbird/librnp.so > ± dpkg -L thunderbird|grep librnp.so > 1 ± You're faced with a relatively early dumat-generated report and I see how the lack of detail makes diagnosing this difficult. Later reports have been improved to include the missing detail. Let me paste the machine-readable report and explain it. libsequoia-octopus-librnp: 1.4.1-1: issues: - bugs: - 1041832 files: - /usr/lib/thunderbird/librnp.so others: thunderbird: 1:115.7.0-1~deb11u1: bullseye 1:115.7.0-1~deb12u1: bookworm 1:115.8.0-1~deb12u1: bookworm-proposed-updates 1:115.9.0-1~deb11u1: bullseye-security 1:115.9.0-1~deb12u1: bookworm-security 1:122.0~b2-1: experimental what: undeclared file conflict source: rust-sequoia-octopus-librnp suites: experimental 1.8.1-1: issues: - bugs: - 1041832 files: - /usr/lib/thunderbird/librnp.so others: thunderbird: 1:115.7.0-1~deb11u1: bullseye 1:115.7.0-1~deb12u1: bookworm 1:115.8.0-1~deb12u1: bookworm-proposed-updates 1:115.9.0-1~deb11u1: bullseye-security 1:115.9.0-1~deb12u1: bookworm-security 1:122.0~b2-1: experimental what: undeclared file conflict source: rust-sequoia-octopus-librnp suites: unstable thunderbird: 1:122.0~b2-1: issues: - bugs: - 1041832 files: - /usr/lib/thunderbird/librnp.so others: libsequoia-octopus-librnp: 1.4.1-1: experimental 1.8.1-1: unstable what: undeclared file conflict suites: experimental Specifically, you need a version of libsequoia-octopus-librnp from unstable or experimental and combine it with a thunderbird version from bullseye, bookworm or experimental. If we disregard experimental and assume that libsequoia-octopus-librnp to trixe, apt could choose to first install libsequoia-octopus-librnp in a bookworm to trixie upgrade before upgrading thunderbird to drop the file. So to reproduce this, I recommend using a bookworm system, install thunderbird, add unstable to apt sources, install libsequoia-octopus-librnp. Helmut
Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian and Matthias, I was recently working on gcc builds and this disagreement currently makes stuff unbuildable. Hence I looked into solutions and/or workarounds. On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote: > > You just said that the search path used during the build of the > > toolchain and the one for everything else are unrelated. So you are > > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > > linux. > > > > The toolchain as installed already finds all headers. So I still don't > > see why we need this in the final system. > > I find this argument fairly convincing and hope Matthias also does. As a result, I implemented the proposed change and am attaching it for discussion here. I've implemented it in a way that if there is a sysroot linux header installation, it'll be preferred. Do you see any downsides of this approach? Helmut linux-libc-dev now provides linux-libc-dev-$arch-cross without actually providing /usr//include. Thus we symlink it to where we need it. See also #1064003. diff --git a/debian/rules2 b/debian/rules2 index 651d14af..6a486ffe 100644 --- a/debian/rules2 +++ b/debian/rules2 @@ -1266,6 +1266,13 @@ endif ln -sf /usr/include/$(DEB_HOST_MULTIARCH)/crypt.h \ $(builddir)/sys-include/crypt.h; \ fi + : # Import headers from Multi-Arch:foreign linux-libc-dev + set -e; for d in asm-generic linux; do \ + if [ -d "/usr/include/$$d" ] && ! [ -d "/usr/$(DEB_TARGET_GNU_TYPE)/include/$$d" ]; then \ + mkdir -p '$(builddir)/sys-include'; \ + ln -sf "/usr/include/$$d" "$(builddir)/sys-include/$$d"; \ + fi; \ + done touch $(configure_stamp)
Bug#1067215: 4 packages from libgdchart-gd2 have an undeclared file conflict
Package: libgdchart-gd2-noxpm-dev,libgdchart-gd2-noxpm,libgdchart-gd2-xpm-dev,libgdchart-gd2-xpm Version: 0.11.5-11 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict 4 packages from libgdchart-gd2 have an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/libgdc.so.0 * /usr/lib/libgdc.so.0.11.5 are contained in the packages * libgdchart-gd2-noxpm * 0.11.5-11 as present in unstable * 0.11.5-10 as present in bookworm|bullseye * 0.11.5-10+b1 as present in trixie * libgdchart-gd2-xpm * 0.11.5-10 as present in bookworm|bullseye * 0.11.5-10+b1 as present in trixie * 0.11.5-11 as present in unstable The files * /usr/lib/libgdc.a * /usr/lib/libgdc.so are contained in the packages * libgdchart-gd2-noxpm-dev * 0.11.5-11 as present in unstable * 0.11.5-10 as present in bookworm|bullseye * 0.11.5-10+b1 as present in trixie * libgdchart-gd2-xpm-dev * 0.11.5-10 as present in bookworm|bullseye * 0.11.5-10+b1 as present in trixie * 0.11.5-11 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1067134: Try to remove i386 packages
On Tue, Mar 19, 2024 at 10:45:44AM +0100, Christian Marillat wrote: > , > | $ dpkg -l | grep libcom-err > | ii libcom-err2t64:amd64 1.47.0-2.3+b1 >amd64common error description library > | ii libcom-err2t64:i3861.47.0-2.3+b1 >i386 common error description library This is the bumpy unstable state that should never migrate to trixie. > upgrading libcom-err2 to 1.47.0-2.4 remove all i386 packages Consider guiding apt by asking it to install both libcom-err2:amd64 and libcom-err2:i386. > , > | $ dpkg -l |grep libcom-err2 > | ii libcom-err2:amd64 1.47.0-2.4 >amd64common error description library > ` > > but now I can reinstall i386 packages again : > > , > | $ dpkg -l |grep libcom-err2 > | ii libcom-err2:amd64 1.47.0-2.4 >amd64common error description library > | ii libcom-err2:i386 1.47.0-2.4 >i386 common error description library > ` I agree that the experience is a little messed up, but this is resolvable with apt and it only affects unstable users. Do you agree with closing this bug with no action? Helmut
Bug#1067134: Try to remove i386 packages
Control: tags -1 + moreinfo Hi Christian, On Tue, Mar 19, 2024 at 10:11:53AM +0100, Christian Marillat wrote: > I'm unable to install comerr-dev under a multiarch amd64/i386 > machine. > > Here is a simple example : > > , > | $ sudo apt-get install comerr-dev > | Reading package lists... Done > | Building dependency tree... Done > | Reading state information... Done > | > | [...] > | > | The following additional packages will be installed: > | libcom-err2 > | Suggested packages: > | doc-base > | The following packages will be REMOVED: > | inetutils-telnet:i386 > | The following NEW packages will be installed: > | comerr-dev libcom-err2 > | 0 upgraded, 2 newly installed, 1 to remove and 0 not upgraded. > ` I fear this is not enough information to diagnose the problem. I'm giving you some context to better understand what we need here. e2fsprogs was identified as one of the packages whose ABI is affected by time64. That analsys did not discriminate between individual shared libraries built from e2fsprogs and hence all libraries including libcom-err2 were bumped. It turned out that libss2 and libcom-err2 really were not affected and libss2t64 and libcom-err2t64 did not transition to trixie. Hence, I reverted the transition for these to ease upgrades knowing that I'd be making upgrades in unstable slightly harder though those are difficult at best. So we need to know which libcom-err2 and libcom-err2t64 packages are installed for which architectures on your system. If there is any libcom-err2t64, please "upgrade" to libcom-err2. Then retry your original apt. I fear this is going to be manual in unstable as there is no sane way to make apt understand that we really don't need libco-err2t64. I expect that upgrades from bookworm and trixie are unaffected by this issue. Unless this expectation is wrong, I suggest that we close this bug as wontfix. Helmut
Bug#1066910: chromium: downloads non-free component libchromescreenai.so without asking
Package: chromium Version: 122.0.6261.128-1 Severity: serious In recent versions, chromium started downloading a file ~/.config/chromium/screen_ai/*/libchromescreenai.so. Evidently, the source of this shared object is not in the chromium source package. I think the chromium package - being in main - should not download a shared object and run it without user confirmation. Helmut
Bug#1066190: mtree-netbsd FTBFS due to -Werror=implicit-function-declaration
Source: mtree-netbsd Version: 20180822-7 Severity: serious Tags: ftbfs As part of the time64 transition, -Werror=implicit-function-declaration was enabled in default build flags. This makes mtree-netbsd fail to build from source. A build ends with: | gcc -DHAVE_CONFIG_H -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -DBSD4_4 -Dst_mtimespec=st_mtim -I. -I. -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c getid.c | getid.c: In function ‘setup_getid’: | getid.c:163:13: error: implicit declaration of function ‘pwcache_groupdb’ [-Werror=implicit-function-declaration] | 163 | if (pwcache_groupdb(gi_setgroupent, gi_endgrent, | | ^~~ | getid.c:165:16: error: implicit declaration of function ‘pwcache_userdb’ [-Werror=implicit-function-declaration] | 165 | || pwcache_userdb(gi_setpassent, gi_endpwent, | |^~ | cc1: some warnings being treated as errors | make[1]: *** [Makefile:30: getid.o] Error 1 | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j1 returned exit code 2 | make: *** [debian/rules:18: build] Error 255 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Helmut
Bug#1066183: mate-equake-applet FTBFS due to -Werror=implicit-function-declaration
Source: mate-equake-applet Version: 1.3.8.2-1.1 Severity: serious Tags: ftbfs Due to the time64 transition -Werror=implicit-function-declaration was turned on by default in unstable. This change makes mate-equake-applet fail to build from source. Relevant snippet: | equake_processdata.c: In function ‘convert_localtime’: | equake_processdata.c:1105:3: error: implicit declaration of function ‘strptime’; did you mean ‘strftime’? [-Werror=implicit-function-declaration] | 1105 | strptime(datetime, "%Y %m %d %H %M %S %z", tp); /* year month day hour minute second */ | | ^~~~ | | strftime Helmut
Bug#1065214: NMU iproute2
Control: tags -1 + pending Hi Luca, this bug causes issues to /usr-move. iproute2 pulls libtirpc3 and nothing pulls libtirpc3t64. Hence, the we still include libtirpc3, which is aliased rather than libtirpc3t64, which is /usr-moved. To fix this, I'd need a binNMU of iproute2, but this bug would cause that binNMU to be broken. Hence, I rather fix this bug. I used reproducible builds to see that iproute2 really only uses tirpc and not nsl. Hence I'm uploading the simple fix of explicitly depending on libtirpc-dev. NMU diff attached. No delay in accordance with DevRef (rc bug older than 7 days with no maintainer activity). Helmut diff -Nru iproute2-6.7.0/debian/changelog iproute2-6.7.0/debian/changelog --- iproute2-6.7.0/debian/changelog 2024-01-22 13:24:29.0 +0100 +++ iproute2-6.7.0/debian/changelog 2024-03-12 09:03:30.0 +0100 @@ -1,3 +1,10 @@ +iproute2 (6.7.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Explicitly depend on libtirpc-dev. (Closes: #1065214) + + -- Helmut Grohne Tue, 12 Mar 2024 09:03:30 +0100 + iproute2 (6.7.0-2) unstable; urgency=medium * Backport fix for 'ss' output diff -Nru iproute2-6.7.0/debian/control iproute2-6.7.0/debian/control --- iproute2-6.7.0/debian/control 2024-01-12 22:09:28.0 +0100 +++ iproute2-6.7.0/debian/control 2024-03-12 09:02:10.0 +0100 @@ -22,6 +22,7 @@ libelf-dev, libmnl-dev, libselinux1-dev, + libtirpc-dev, linux-libc-dev, pkg-config, po-debconf,
Bug#1066078: vigor FTBFS due to -Werror=implicit-function-declaration
Source: vigor
Version: 0.016-31
Severity: serious
Tags: ftbfs
Due to time64 and thus enabling -Werror=implicit-function-declaration,
vigor now fails to build from source:
| ../../build/../cl/cl_screen.c: In function ‘cl_screen’:
| ../../build/../cl/cl_screen.c:112:25: error: implicit declaration of function
‘tputs’; did you mean ‘puts’? [-Werror=implicit-function-declaration]
| 112 | tputs(tgoto(clp->cup,
| | ^
| | puts
| ../../build/../cl/cl_screen.c:112:31: error: implicit declaration of function
‘tgoto’ [-Werror=implicit-function-declaration]
| 112 | tputs(tgoto(clp->cup,
| | ^
| ../../build/../cl/cl_funcs.c: In function ‘cl_attr’:
| ../../build/../cl/cl_funcs.c:125:39: error: implicit declaration of function
‘tputs’; did you mean ‘puts’? [-Werror=implicit-function-declaration]
| 125 | (void)tputs(clp->smcup, 1,
cl_putchar);
| | ^
| | puts
| ../../build/../cl/cl_read.c: In function ‘block_for_read’:
| ../../build/../cl/cl_read.c:137:9: error: implicit declaration of function
‘mega_select’ [-Werror=implicit-function-declaration]
| 137 | mega_select(fd+1, , NULL, NULL, NULL);
| | ^~~
| ../../build/../cl/cl_funcs.c: In function ‘cl_ex_adjust’:
| ../../build/../cl/cl_funcs.c:350:37: error: implicit declaration of function
‘tgoto’; did you mean ‘v_lgoto’? [-Werror=implicit-function-declaration]
| 350 | (void)tputs(tgoto(clp->cup,
| | ^
| | v_lgoto
| ../../build/../cl/cl_funcs.c: In function ‘cl_bell’:
| ../../build/../cl/cl_funcs.c:214:23: warning: ignoring return value of
‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
| 214 | (void)write(STDOUT_FILENO, "\07", 1); /* \a
*/
| | ^~
| ../../build/../cl/cl_bsd.c: In function ‘setupterm’:
| ../../build/../cl/cl_bsd.c:176:22: error: implicit declaration of function
‘tgetent’; did you mean ‘getenv’? [-Werror=implicit-function-declaration]
| 176 | if ((*errp = tgetent(buf, ttype)) > 0) {
| | ^~~
| | getenv
Helmut
Bug#1066057: libhalide17-1-dev has an undeclared file conflict
Package: libhalide17-1-dev Version: 17.0.1-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libhalide17-0-dev libhalide17-1-dev has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-deps.cmake * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-targets-release.cmake * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-targets.cmake * /usr/lib/x86_64-linux-gnu/cmake/Halide17/HalideConfig.cmake * /usr/lib/x86_64-linux-gnu/cmake/Halide17/HalideConfigVersion.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/FindHalide_WebGPU.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/Halide-Interfaces-release.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/Halide-Interfaces.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideGeneratorHelpers.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideHelpersConfig.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideHelpersConfigVersion.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideTargetHelpers.cmake * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/TargetExportScript.cmake * /usr/lib/x86_64-linux-gnu/halide17/adams2019_retrain_cost_model * /usr/lib/x86_64-linux-gnu/halide17/adams2019_weightsdir_to_weightsfile * /usr/lib/x86_64-linux-gnu/halide17/anderson2021_retrain_cost_model * /usr/lib/x86_64-linux-gnu/halide17/anderson2021_weightsdir_to_weightsfile * /usr/lib/x86_64-linux-gnu/halide17/featurization_to_sample * /usr/lib/x86_64-linux-gnu/halide17/get_host_target * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_adams2019.so * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_anderson2021.so * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_li2018.so * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_mullapudi2016.so * /usr/lib/x86_64-linux-gnu/libHalide17.so * /usr/lib/x86_64-linux-gnu/libHalidePyStubs17.a are contained in the packages * libhalide17-0-dev/17.0.0-2 as present in trixie * libhalide17-1-dev/17.0.1-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1066054: spacearyarya FTBFS due to -Werror=implicit-function-declaration
Source: spacearyarya
Version: 1.0.2-8
Severity: serious
Tags: ftbfs
Due to the time64 transition, -Werror=-implicit-function-declaration was
enabled in default build flags and this makes spacearyarya FTBFS: Please
include the time.h header.
| gcc -DPACKAGE_NAME=\"SpaceAryarya-KXL\"
-DPACKAGE_TARNAME=\"spacearyarya-kxl\" -DPACKAGE_VERSION=\"1.0.2\"
-DPACKAGE_STRING=\"SpaceAryarya-KXL\ 1.0.2\"
-DPACKAGE_BUGREPORT=\"m...@kxl.hn.or\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"spacearyarya-kxl\" -DVERSION=\"1.0.2\" -DHAVE_LIBKXL=1
-DHAVE_LIBKXL=1 -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1
-DDATA_PATH=\"/usr/share/games/spacearyarya/data\"
-DBMP_PATH=\"/usr/share/games/spacearyarya/bmp\"
-DWAV_PATH=\"/usr/share/games/spacearyarya/wav\" -DTITLE=\"spacearyarya-kxl\
1.0.2\" -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -c -o main.o main.c
| main.c: In function ‘options’:
| main.c:144:10: error: implicit declaration of function ‘strcmp’
[-Werror=implicit-function-declaration]
| 144 | if (!strcmp(argv[i], "-h") || !strcmp(argv[i], "--help")) {
| | ^~
| main.c:7:1: note: include ‘’ or provide a declaration of ‘strcmp’
| 6 | #include "extern.h"
| +++ |+#include
| 7 |
| main.c: In function ‘main’:
| main.c:179:9: error: implicit declaration of function ‘time’
[-Werror=implicit-function-declaration]
| 179 | srand(time(NULL));
| | ^~~~
| main.c:7:1: note: ‘time’ is defined in header ‘’; did you forget to
‘#include ’?
| 6 | #include "extern.h"
| +++ |+#include
| 7 |
| misc.c: In function ‘ClearAndGameOver’:
| misc.c:107:5: error: implicit declaration of function ‘ScoreRanking’
[-Werror=implicit-function-declaration]
| 107 | ScoreRanking();
| | ^~~~
| ranking.c: In function ‘ReadScore’:
| ranking.c:41:5: warning: ignoring return value of ‘fscanf’ declared with
attribute ‘warn_unused_result’ [-Wunused-result]
|41 | fscanf(fp, "%"SCNu32, &(Root->HiScore));
| | ^~~
| ranking.c:43:7: warning: ignoring return value of ‘fscanf’ declared with
attribute ‘warn_unused_result’ [-Wunused-result]
|43 | fscanf(fp, "%"SCNu32" %"SCNu8" %s",
| | ^~~
|44 | &(Ranking[i]->Score),
| | ~
|45 | &(Ranking[i]->Stage),
| | ~
|46 | Ranking[i]->Name);
| | ~
Helmut
Bug#1066053: sgrep FTBFS due to -Werror=implicit-function-declaration
Source: sgrep
Version: 1.94a-5
Severity: serious
Tags: ftbfs
Due to the time64 transition, default build flags now include
-Werror=implicit-function-declaration. This happens to cause a build
failure for sgrep:
| gcc -DHAVE_CONFIG_H -I. -DDATADIR="\"/usr/share/sgrep\""
-DSYSCONFDIR="\"/etc\"" -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -c -o index_main.o index_main.c
| sysdeps.c: In function ‘check_memory_leaks’:
| sysdeps.c:489:49: warning: format ‘%d’ expects argument of type ‘int’, but
argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
| 489 | "Memory leak: %d blocks having %d bytes total size\n",
| |~^
| | |
| | int
| |%ld
| sysdeps.c:496:32: warning: format ‘%d’ expects argument of type ‘int’, but
argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
| 496 | "\t%s:%d: %d
bytes\n",block->file,block->line,block->size);
| | ~^
~~~
| ||
|
| |int
size_t {aka long unsigned int}
| | %ld
| index_main.c: In function ‘parse_index_options’:
| index_main.c:84:21: error: implicit declaration of function ‘strcmp’
[-Werror=implicit-function-declaration]
|84 | if (strcmp(*argv,"--")==0) return i+1;
| | ^~
| index_main.c:2:1: note: include ‘’ or provide a declaration of
‘strcmp’
| 1 | #include "sgrep.h"
| +++ |+#include
| 2 |
| index_main.c:138:41: warning: macro "__DATE__" might prevent reproducible
builds [-Wdate-time]
| 138 | VERSION,__DATE__);
| | ^~~~
| index_main.c: In function ‘index_main’:
| index_main.c:241:13: error: implicit declaration of function ‘index_query’
[-Werror=implicit-function-declaration]
| 241 | if (index_query(,argc-end_options,argv+end_options)
| | ^~~
| cc1: some warnings being treated as errors
| make[2]: *** [Makefile:488: index_main.o] Error 1
Helmut
Bug#1065696: Fwd: E: unsupported command: poweroff.no-molly-guard
Control: forcemerge 1059691 -1 On Fri, Mar 08, 2024 at 09:37:05PM -0800, Francois Marier wrote: > Hi Helmut, > > This looks like an unexpected edge case from the recent usr-merge changes: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065696 > > It sounds like a system using sysvinit, instead of systemd, which was > recently upgraded using usrmerge. Yes, I think this is a duplicate of #1059691. Could you give feedback on the contained patch? Helmut
Bug#1064852: incus: missing depends on iproute2
On Tue, Mar 05, 2024 at 12:00:15PM +, Mathias Gibbens wrote: > to add iproute2. I would be interested to know more about what > environment Incus is being used in that doesn't have the `ip` command > available. debvm-create --include=incus # This should have created a file named rootfs.ext4. debvm-run > My normal testing setup for Incus is a fresh, minimal expert install > of sid via the netinst iso. During the install of the VM, I only > install the base system and deselect the "standard system utilities" > group. I do use DHCP, which looks like that might be responsible for > pulling in iproute2 for me. If there's a way to create an even more > minimal install, I'd be happy to incorporate that into my testing > routine. Turns out your minimal expert install is not so minimal. debvm tends to give you a smaller but still functional installation. I think adding --variant=important to debvm-create roughly gets you the minimal expert installation, but creating the machine takes slightly longer and uses more disk space of course. Rather than adding debvm on top of your testing, I think adding autopkgtests with isolation-machine should get you more automatic coverage. Possibly such tests need to be explicitly allowed by debci folks and currently are only available on amd64. Helmut
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote: > > Arguably, a cross toolchain build should probably search > > /usr/include/. I went back and forth a bit with Matthias > > about whether we could add this and did not fully understand his > > reasons, but there is one technical reason we want to avoid it for now. > > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > > and these packages can have differing versions. When that happens and we > > search both /usr//include and /usr/include/, we'd > > mix two glibc versions with usually bad results (been there). > > But this is a search path. If a file exists in one, the second one is > not found. So nothing can happen even from version skew. The problem arises in the reverse sense. If a file does not exist in one, it is searched in the second and erroneously may be found. That may make tests pass that should not pass and typically causes a link failure later. While I do not have a concrete example at hand, I have seen this pattern repeatedly and generally favour moving stuff out of /usr/include to avoid this kind of confusion that causes difficult to debug problems. This also motivates #798955 (in addition to the problem with file conflicts). > > The other aspect here is that it is not sufficient to add > > /usr/include/ to the search path as you also need > > /usr/include to get a complete linux kernel headers experience. We > > definitely do not want to add /usr/include, because that is known to > > misguide configure tests performed for the target architecture. > > We are talking about the toolchain itself. What configure tests could > that be? Or is that premature optimization of the gcc build? The one case I really do remember quite well is sanitizers. These should not be enabled in the earlier toolchain stages and failing to disable them tends to cause linker failures. I don't think it matches the concrete situation exactly though. You also make a good case in your followup reporting that gcc-13-cross actually builds. > You just said that the search path used during the build of the > toolchain and the one for everything else are unrelated. So you are > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > linux. > > The toolchain as installed already finds all headers. So I still don't > see why we need this in the final system. I find this argument fairly convincing and hope Matthias also does. Thank you Helmut
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 12:30:09PM +0100, Bastian Blank wrote: > On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > > On 04.03.24 11:29, Bastian Blank wrote: > > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > > > Please be a bit more precise, there are no symlinks in this directory. > > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > > | # find /usr/alpha-linux-gnu/include/ -type l > > > | # > > yes, that is the problem. the cross gcc expects these headers in > > /usr/alpha-linux-gnu/include, not in the header location for the host. > > Please show your problem with a log, my crystal ball is broken. This very much was not obvious to me either. I've now talked to Matthias and believe I can explain the problem. The packaged gcc cross toolchain uses a sysroot during its own build still. As it is implemented now, it searches /usr//include, but not /usr/include/. So quite fundamentally, the Provides that we two agreed do break the build of cross toolchains right now. Arguably, a cross toolchain build should probably search /usr/include/. I went back and forth a bit with Matthias about whether we could add this and did not fully understand his reasons, but there is one technical reason we want to avoid it for now. We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed and these packages can have differing versions. When that happens and we search both /usr//include and /usr/include/, we'd mix two glibc versions with usually bad results (been there). While we might consider adding /usr/include/ to the cross toolchain build search path later, it is not something we can do now and before doing that, we need to better understand Matthias' reasons for keeping these separate as well. The other aspect here is that it is not sufficient to add /usr/include/ to the search path as you also need /usr/include to get a complete linux kernel headers experience. We definitely do not want to add /usr/include, because that is known to misguide configure tests performed for the target architecture. In principle, we could extend the symlink farm in linux-libc-dev to also have a lot of /usr/include//linux -> ../linux symlinks (assuming that no other package ever installs to /usr/include/linux, which is a property violated by aufs-dev and oss4-dev). So at least for now, I am convinced that we will need /usr//include to be provided by the package providing linux-libc-dev-arch-cross. As these are only necessary for building the cross toolchains, we probably don't want these in the main linux-libc-dev package. So how about adding a linux-libc-dev-cross package with yet more symlinks? Then we can move the provides over to the linux-libc-dev-cross package and that way repair the cross toolchain builds. I requested that linux-libc-dev provides these for bootstrapping to know which architectures linux-libc-dev actually supports. I don't need these provides exactly, I just need a mechanism to answer the question "Does linux-libc-dev work for a particular architecture?" from the binary package metadata, so we might just change the Provides there to linux-libc-dev-arch dropping the -cross suffix that traditionally identified packages putting stuff into /usr/. Does that sound reasonable to you? That still leaves the question of which package would have to build that new linux-libc-dev-cross. The two obvious answers are linux and cross-toolchain-base. Do you have a preference here? I hope this all makes more sense now. Helmut
Bug#1065258: 6 packages from starpu-contrib have an undeclared file conflict
Package: libstarpu-contribrm-1.4-1t64,libstarpu-contribfft-1.4-1t64,libstarpu-contribmpi-1.4-3t64,libstarpu-contrib-openmp-llvm-1.4-1t64,libsocl-contrib-1.4-1t64,libstarpu-contrib-1.4-4t64 Version: 1.4.3+dfsg-3 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libsocl-contrib-1.4-1 libstarpu-contrib-1.4-4 libstarpu-contrib-openmp-llvm-1.4-1 libstarpu-contribfft-1.4-1 libstarpu-contribmpi-1.4-3 libstarpu-contribrm-1.4-1 6 packages from starpu-contrib have an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/libsocl-1.4.so.1 * /usr/lib/x86_64-linux-gnu/libsocl-1.4.so.1.0.1 are contained in the packages * libsocl-contrib-1.4-1/1.4.3+dfsg-2 as present in trixie * libsocl-contrib-1.4-1t64/1.4.3+dfsg-3 as present in unstable The files * /usr/lib/x86_64-linux-gnu/libstarpu-1.4.so.4 * /usr/lib/x86_64-linux-gnu/libstarpu-1.4.so.4.0.0 are contained in the packages * libstarpu-contrib-1.4-4/1.4.3+dfsg-2 as present in trixie * libstarpu-contrib-1.4-4t64/1.4.3+dfsg-3 as present in unstable The files * /usr/lib/x86_64-linux-gnu/libstarpu_openmp_llvm-1.4.so.1 * /usr/lib/x86_64-linux-gnu/libstarpu_openmp_llvm-1.4.so.1.0.0 are contained in the packages * libstarpu-contrib-openmp-llvm-1.4-1/1.4.3+dfsg-2 as present in trixie * libstarpu-contrib-openmp-llvm-1.4-1t64/1.4.3+dfsg-3 as present in unstable The files * /usr/lib/x86_64-linux-gnu/libstarpufft-1.4.so.1 * /usr/lib/x86_64-linux-gnu/libstarpufft-1.4.so.1.0.0 are contained in the packages * libstarpu-contribfft-1.4-1/1.4.3+dfsg-2 as present in trixie * libstarpu-contribfft-1.4-1t64/1.4.3+dfsg-3 as present in unstable The files * /usr/lib/x86_64-linux-gnu/libstarpumpi-1.4.so.3 * /usr/lib/x86_64-linux-gnu/libstarpumpi-1.4.so.3.0.0 are contained in the packages * libstarpu-contribmpi-1.4-3/1.4.3+dfsg-2 as present in trixie * libstarpu-contribmpi-1.4-3t64/1.4.3+dfsg-3 as present in unstable The files * /usr/lib/x86_64-linux-gnu/libstarpurm-1.4.so.1 * /usr/lib/x86_64-linux-gnu/libstarpurm-1.4.so.1.0.0 are contained in the packages * libstarpu-contribrm-1.4-1/1.4.3+dfsg-2 as present in trixie * libstarpu-contribrm-1.4-1t64/1.4.3+dfsg-3 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1065146: sysvinit-core: /usr/sbin/halt and others ineffectively diverted (DEP17)
Control: severity -1 important Hi Lorenzo, On Fri, Mar 01, 2024 at 01:18:38PM +0100, Lorenzo wrote: > I'm missing something for sure here, but sysvinit-core has a conflict > with systemd-sysv and both bfh-container and progress-linux-container > depends on systemd-sysv so they already should not be installed at the > same time in a system regardless of the versioned conflicts you are > adding.. ? Thank you for your attention to detail. Your analysis is mostly correct. In particular, the declared dependencies on systemd-sysv make the failure mode very unlikely - hence downgrading the bug. Stil Depends does not impact the unpack phase. In principle, you may have a system with bfh-container on bookworm (thus having systemd-sysv) and then upgrade to trixie while at the same time converting to sysvinit-core (unlikely). When doing that, bfh-container may get into a deconfigured state, systemd-sysv can be removed and sysvinit-core may be unpacked before bfh-container is actually removed. In this scenario, bfh-container.postrm would cause /usr/sbin/halt to vanish. As such, I think we should apply Conflicts here to avoid the underlying situation. Helmut
Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems
On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote: > Well, officially downgrading isn't supported (although it typically works) > *and* losing files is one of the problems of our merged-/usr solution (see > [1]). I *suspect* this might be the cause. We're working hard (well, helmut > is) to protect us and our users from loosing files on upgrades. We don't > protect against downgrades. As much as we like blaming all lost files on the /usr-move, this is not one them. If you are downgrading from to a package that formerly has been replaced, you always have lost files and you always had to reinstall the package. While t64 has quite some interactions with the /usr-move, I am closely monitoring the situation have have been filing multiple bugs per day recently about the relevant peculiarities. I don't think any of the fallout we see here is reasonably attributable to /usr-move. The most recent practical issues I've seen was related to image building tools such as live-build and grml. When it comes to lost files, we're not addressing them based on user reports (as there are practically none), but on rigid analysis preventing users from experiencing them in the first place. Helmut
Bug#1065146: sysvinit-core: /usr/sbin/halt and others ineffectively diverted (DEP17)
Package: sysvinit-core Version: 3.08-7 Severity: serious Tags: patch User: helm...@debian.org Usertags: dep17p3 Control: affects -1 + bfh-container progress-linux-container Hi, thanks for applying my earlier /usr-move patch #1060139. Since authoring it, the mitigations for ineffective diversions have been added to diverters, but one missing piece remains. We must not upgrade sysvinit-core before the diverters have duplicated their diversions or we may cause file loss. To achieve this, sysvinit-core needs to gain two more versioned Conflicts beyond molly-guard to be found in the attached patch. Helmut diff --minimal -Nru sysvinit-3.08/debian/changelog sysvinit-3.08/debian/changelog --- sysvinit-3.08/debian/changelog 2024-02-29 12:22:45.0 +0100 +++ sysvinit-3.08/debian/changelog 2024-03-01 07:53:14.0 +0100 @@ -1,3 +1,11 @@ +sysvinit (3.08-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Update versioned Conflicts to handle DEP17 ineffective diversions for more +diverters. (Closes: #-1) + + -- Helmut Grohne Fri, 01 Mar 2024 07:53:14 +0100 + sysvinit (3.08-7) unstable; urgency=medium [ Johannes Schauer Marin Rodrigues ] diff --minimal -Nru sysvinit-3.08/debian/control sysvinit-3.08/debian/control --- sysvinit-3.08/debian/control2024-02-29 12:22:45.0 +0100 +++ sysvinit-3.08/debian/control2024-03-01 07:53:12.0 +0100 @@ -32,6 +32,8 @@ systemd-sysv, runit-init, molly-guard (<< 0.8.3~), + bfh-container (<< 20211009-24~), + progress-linux-container (<< 20221002-12~), Breaks: manpages-es (<< 4.15.0-9~), manpages-fr (<< 4.15.0-9~),
Bug#1065145: guacd: internal aliasing conflict on guacd.service
Package: guacd Version: 1.3.0-1.2 Severity: serious Tags: patch User: helm...@debian.org Usertags: dep17 X-Debbugs-Cc: vor...@debian.org I changed dh_installsystemd to install systemd units below /usr/lib rather than /lib a while back. Back then, I rebuilt all possibly affected packages and guacd happened to FTBFS. Hence, it was ignored in my analysis. Now the time64 transition fixed the FTBFS and guacd installs both /lib/systemd/system/guacd.service and /usr/lib/systemd/system/guacd.service. Doing so is a policy violation and causes an installation failure on /usr-merged systems: Unpacking guacd (1.3.0-1.2) ... dpkg: error processing archive /tmp/apt-dpkg-install-JKIS2y/25-guacd_1.3.0-1.2_amd64.deb (--unpack): unable to install new version of '/usr/lib/systemd/system/guacd.service': No such file or directory I'm attaching a patch fixing this issue. Helmut diff --minimal -Nru guacamole-server-1.3.0/debian/changelog guacamole-server-1.3.0/debian/changelog --- guacamole-server-1.3.0/debian/changelog 2024-02-29 07:18:24.0 +0100 +++ guacamole-server-1.3.0/debian/changelog 2024-03-01 07:40:03.0 +0100 @@ -1,3 +1,10 @@ +guacamole-server (1.3.0-1.3) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install guacd.service only once. (Closes: #-1) + + -- Helmut Grohne Fri, 01 Mar 2024 07:40:03 +0100 + guacamole-server (1.3.0-1.2) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru guacamole-server-1.3.0/debian/guacd.install guacamole-server-1.3.0/debian/guacd.install --- guacamole-server-1.3.0/debian/guacd.install 2022-02-07 19:02:10.0 +0100 +++ guacamole-server-1.3.0/debian/guacd.install 2024-03-01 07:39:57.0 +0100 @@ -1,4 +1,3 @@ bin/guacctl /usr/bin /usr/sbin/guacd /usr/share/man/man8/guacd.8 -debian/guacd.service /lib/systemd/system/
Bug#1065126: libelk0t64 has an undeclared file conflict
Package: libelk0t64 Version: 3.99.8-5 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libelk0 libelk0t64 has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/libelk-xlib.so.0 * /usr/lib/x86_64-linux-gnu/libelk-xlib.so.0.0.0 * /usr/lib/x86_64-linux-gnu/libelk-xt.so.0 * /usr/lib/x86_64-linux-gnu/libelk-xt.so.0.0.0 * /usr/lib/x86_64-linux-gnu/libelk.so.0 * /usr/lib/x86_64-linux-gnu/libelk.so.0.0.0 are contained in the packages * libelk0/3.99.8-4.2+b1 as present in bookworm|bullseye|trixie|unstable * libelk0t64/3.99.8-5 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1065125: libchipcard8 has an undeclared file conflict
Package: libchipcard6t64 Version: 5.99.1beta-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libchipcard8 X-Debbugs-Cc: Benjamin Drung , vor...@debian.org libchipcard6t64 has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/chiptanusb.so * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/chiptanusb.xml * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/ddvcard.so * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/ddvcard.xml * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/starcoscard.so * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/starcoscard.xml * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/zkacard.so * /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/79/ct/zkacard.xml are contained in the packages * libchipcard6t64/5.1.6-1.1 as present in unstable * libchipcard8/5.99.1beta-1 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. This actually is fallout from the time64 transition. Both libchipcard6 and libchipcard8 declared "Provides: libgwenhywfar79-plugins-ct" and "Conflicts: libgwenhywfar79-plugins-ct". However, libchipcard6t64 has changed this to libgwenhywfar-plugins-ct. The change in virtual facility causes the conflicts to no longer take effect. Hence filing this with libchipcard6t64 rather than libchipcard8. Kind regards Helmut
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
On Thu, Feb 29, 2024 at 08:14:30AM +0100, Helmut Grohne wrote: > Ideally, we'd get a reproducer using > >mmdebstrap SOMERELEASE /dev/null --variant=apt --include=SOMEPACKAGES > --customize-hook='echo SOURCES_LIST_LINE > "$1/etc/apt/sources.list"' > --chrooted-customize-hook="apt-get update" > --chrooted-customize-hook="aptitude dist-upgrade" mmdebstrap trixie /dev/null --variant=apt --include debian-security-support --customize-hook='sed -i -e s/trixie/sid/ "$1/etc/apt/sources.list"' --chrooted-customize-hook="apt-get update && apt-get install debian-security-support libpam0t64" debian-security-support installs a dpkg.cfg.d snipped that configures a post-invoke action which calls out to runuser. I think what it does is policy-compliant. > Technically speaking, I believe this is a Debian policy 3.8 violation. > runuser is essential and removing libpam0g causes runuser to no longer > work. I'm tentatively upgrading severity hoping that we don't get into a > severity pingpong. Julian Andres Klode also thinks that it is likely to > affect apt. Yes, it does affect apt as we can see above. While the consequences are not really fatal in this case, we still have an essential runuser that happens to not work briefly. I believe pam will have to be reverted and implemented as dual ABI instead. And I really expect the same to hold for libtirpc. We just haven't seen the user reports for that yet as it hasn't built. Helmut
Bug#1064298: closed by Debian FTP Masters (reply to Steve Langasek ) (Bug#1064298: fixed in hamlib 4.5.5-3.1~exp2)
Control: reopen -1 Control: found -1 4.5.5-3.1 On Wed, Feb 21, 2024 at 04:54:05AM +, Debian Bug Tracking System wrote: > #1064298: libhamlib4t64: ineffective replaces due to /usr-move > > It has been closed by Debian FTP Masters > (reply to Steve Langasek ). The fix for this bug has gone missing from the 4.5.5-3.1 upload to unstable. Helmut
Bug#1064997: tdfsb: fails to trap errors from ./compile.sh
Source: tdfsb Version: 0.0.10-3 Severity: serious Justification: policy 4.6 tdfsb's compile.sh fails to terminate with an error when one of the invoked build commands fails. This violates Debian policy section 4.6. A relatively simple counter measure would be adding "set -e" to the script. Helmut
Bug#1061984: libboinc-app7t64 and libboinc7t64 have an undeclared file conflict
Control: reopen -1
On Tue, Jan 30, 2024 at 01:37:42PM -0800, Steve Langasek wrote:
> > libboinc-app7t64 and libboinc7t64 have an undeclared file conflict. This
> > may result in an unpack error from dpkg.
>
> Sigh. Thanks for the Cc:.
>
> That's because boinc has an idiosyncratic debian/control.in that we failed
> to patch, and as a result the successful patching of debian/control was
> clobbered.
>
> I'm uploading a follow-up NMU to experimental and attaching an updated patch
> for the complete delta from the version in unstable.
Not sure what happened here exactly. The current libboinc7t64 in
unstable version 7.24.1+dfsg-2.1 has the following it is uploaded
debian/control file (from the dsc):
| Package: libboinc7t64
| Architecture: any
| Section: libs
| Provides: libboinc
| Multi-Arch: same
| Pre-Depends: ${misc:Pre-Depends}
| Breaks: boinc-dev (<< 7.0.28+dfsg-3),
| libboinc (<= 7.0.34+dfsg-1)
| Replaces: boinc-dev (<< 7.0.28+dfsg-3),
| libboinc (<= 7.0.34+dfsg-1)
| Depends: ${misc:Depends}, ${shlibs:Depends}
| Description: libraries of BOINC the client depends on
Notably:
* There is no t64:Provides.
* There is no Replaces: libboinc7.
* There is no Breaks: libboinc7
Hence reopening the bug.
Helmut
Bug#1064852: incus: missing depends on iproute2
Control: tags -1 + moreinfo Hi Mathias, On Tue, Feb 27, 2024 at 01:33:08AM +, Mathias Gibbens wrote: > iproute2 is Priority: important, which according to Policy §2.5 means > that it is generally expected to be present on a Debian system. Do you > have a specific use case where for some reason you don't have iproute2 > installed? While that means iproute2 is installed by default, it still does not mean you can rely on its presence. It is "Essential: yes" that allows you to skip emitting the dependency. Users are entitled to remove important packages and often do so. > I'm initially reluctant to explicitly list iproute2 as a dependency > for Incus unless there's some very compelling reason. I think that it is the failure mode that compells me this to be serious. When iproute2 is missing all the incus commands hang and you spend a long time digging why this thing doesn't work at all. If incus were telling me (on the cli) that iproute2 is missing and offering ways of working without, I'd see things differently. Conversely, what is the maintenance cost of having this dependency? Helmut
Bug#1064852: incus: missing depends on iproute2
Package: incus Version: 0.6-1 Severity: serious Justification: missing dependency After installing incus any "incus *" command (even incus info) just hangs with no indication what's wrong. journalctl -u incus eventually reveals: Feb 26 16:47:45 testvm incusd[685]: Error: exec: "ip": executable file not found in $PATH After installing iproute2, incus starts and incus commands start working. Helmut
Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs
Package: emacs-gtk,emacs-nox,emacs-pgtk,emacs-lucid Version: 1:29.2+1-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + emacs-bin-common 4 packages from emacs have an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/emacsclient.emacs is contained in the packages * emacs-bin-common * 1:27.1+1-3.1+deb11u1 as present in bullseye * 1:27.1+1-3.1+deb11u2 as present in bullseye-security * 1:28.2+1-15 as present in bookworm * 1:29.1+1-5 as present in trixie * 1:29.1+1-5~bpo12+1 as present in bookworm-backports * emacs-gtk/1:29.2+1-1 as present in unstable * emacs-lucid/1:29.2+1-1 as present in unstable * emacs-nox/1:29.2+1-1 as present in unstable * emacs-pgtk/1:29.2+1-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1064665: ukui-media has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/ukui-control-center/libaudio.so
Package: ukui-media Version: 3.1.1.1-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + ukui-control-center ukui-media has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/x86_64-linux-gnu/ukui-control-center/libaudio.so is contained in the packages * ukui-control-center * 3.0.2-2 as present in bullseye * 3.0.5.1-2 as present in bookworm|trixie * ukui-media/3.1.1.1-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1064664: ukui-power-manager has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/ukui-control-center/libpower.so
Package: ukui-power-manager Version: 4.0.0.0-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + ukui-control-center ukui-power-manager has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/x86_64-linux-gnu/ukui-control-center/libpower.so is contained in the packages * ukui-control-center * 3.0.2-2 as present in bullseye * 3.0.5.1-2 as present in bookworm|trixie * ukui-power-manager/4.0.0.0-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1064563: libstd-rust-1.70 has an undeclared file conflict
Package: libstd-rust-1.70 Version: 1.70.0+dfsg1-7 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libstd-rust-web-1.70 libstd-rust-1.70 has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/librustc_driver-fccd0c47598ec70b.so * /usr/lib/x86_64-linux-gnu/libstd-5aee28526a69a514.so * /usr/lib/x86_64-linux-gnu/libtest-ce8cb46549a60304.so are contained in the packages * libstd-rust-1.70/1.70.0+dfsg1-7 as present in trixie|unstable * libstd-rust-web-1.70/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1064564: rustup has an undeclared file conflict
Package: rustup Version: 1.26.0-4 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + rust-mozilla-gdb rust-mozilla-lldb rust-web-clippy rust-web-gdb rust-web-lldb rustfmt-web rustup has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/bin/cargo-clippy * /usr/bin/clippy-driver are contained in the packages * rust-web-clippy/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates * rustup/1.26.0-4 as present in trixie|unstable The files * /usr/bin/cargo-fmt * /usr/bin/rustfmt are contained in the packages * rustfmt-web/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates * rustup/1.26.0-4 as present in trixie|unstable The file /usr/bin/rust-gdb is contained in the packages * rust-mozilla-gdb/1.63.0+dfsg1-2~deb11u1 as present in bullseye * rust-web-gdb/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates * rustup/1.26.0-4 as present in trixie|unstable The file /usr/bin/rust-lldb is contained in the packages * rust-mozilla-lldb/1.63.0+dfsg1-2~deb11u1 as present in bullseye * rust-web-lldb/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates * rustup/1.26.0-4 as present in trixie|unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1064562: 4 packages from rustc-web have an undeclared file conflict
Package: rust-web-gdb,libstd-rust-web-dev-windows,rust-web-src,rust-web-lldb Version: 1.70.0+dfsg1-7~deb12u1 Severity: serious Tags: bookworm User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libstd-rust-mozilla-dev-windows rust-mozilla-gdb rust-mozilla-lldb rust-mozilla-src 4 packages from rustc-web have an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/rustlib/x86_64-pc-windows-gnu/lib/rsbegin.o * /usr/lib/rustlib/x86_64-pc-windows-gnu/lib/rsend.o * /usr/lib/rustlib/x86_64-pc-windows-gnu/lib/self-contained/crt2.o * /usr/lib/rustlib/x86_64-pc-windows-gnu/lib/self-contained/dllcrt2.o are contained in the packages * libstd-rust-mozilla-dev-windows/1.63.0+dfsg1-2~deb11u1 as present in bullseye * libstd-rust-web-dev-windows/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates The files * /usr/bin/rust-gdb * /usr/bin/rust-gdbgui * /usr/lib/rustlib/etc/gdb_load_rust_pretty_printers.py * /usr/lib/rustlib/etc/gdb_lookup.py * /usr/lib/rustlib/etc/gdb_providers.py are contained in the packages * rust-mozilla-gdb/1.63.0+dfsg1-2~deb11u1 as present in bullseye * rust-web-gdb/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates The files * /usr/bin/rust-lldb * /usr/lib/rustlib/etc/lldb_commands * /usr/lib/rustlib/etc/lldb_lookup.py * /usr/lib/rustlib/etc/lldb_providers.py are contained in the packages * rust-mozilla-lldb/1.63.0+dfsg1-2~deb11u1 as present in bullseye * rust-web-lldb/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates The file /usr/lib/rustlib/src/rust is contained in the packages * rust-mozilla-src/1.63.0+dfsg1-2~deb11u1 as present in bullseye * rust-web-src/1.70.0+dfsg1-7~deb12u1 as present in bookworm-proposed-updates These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1053111: please upload DEP17-related patches
user helm...@debian.org severity 1059981 important tags 1059981 + trixie sid severity 1061274 important tags 1061274 + trixie sid severity 1060269 important tags 1060269 + trixie sid patch severity 1060270 important tags 1060270 + trixie sid patch severity 106 important usertags 106 + dep17m2 severity 1059534 important tags 1059534 + trixie sid severity 1059533 important tags 1059533 + trixie sid severity 1059919 important tags 1059919 + trixie sid severity 1060089 important tags 1060089 + trixie sid severity 1055959 important tags 1055959 + trixie sid severity 1060160 important tags 1060160 + trixie sid severity 1060139 important tags 1060139 + trixie sid thanks The number of packages installed by debootstrap containing files in aliased locations has been shrinking since a while. We're now down to 10 packages and I'd like to get them done by mid March to be able to move forward with uploading base-files/bash/dash/glibc/util-linux. Please upload the requested changes or reply to the bugs. In some cases (such as isc-dhcp, libtirpc and pam) these have been fixed in experimental and are expected to land in unstable soon. For others, I intend to upload delayed NMUs in agreement with the developers reference soon. I'm aware that the time64 transition is in progress, but there is little intersection except for libtirpc and pam, both of which will be moved as part of the time64 transition. Please let me know if you have questions or objections to moving forward. Helmut
Bug#1064495: sitecopy FTBFS: incompatible neon version
Source: sitecopy Version: 1:0.16.6-11 Severity: serious Tags: ftbfs sitecopy fails to build from source in unstable. I think the relevant part of the build log is: | checking for neon-config... /usr/bin/neon-config | checking linking against neon... yes | configure: incompatible neon library version 0.33.0: wanted 0.24 25 26 27 28 31 32 | configure: error: could not use external neon library | tail -v -n \+0 config.log Apparently, sitecopy is incompatible with neon >= 0.33. This quite definitely needs a sourceful upload of sitecopy. Helmut
Bug#1064361: libreadline8t64: file loss due to concurrent /usr-move and package rename (DEP17 P1)
Package: libreadline8t64
Version: 8.2-3.1~exp1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1
Control: affects -1 + libreadline8
X-Debbugs-Cc: vor...@debian.org, mwhud...@debian.org, bug-readl...@gnu.org
Hi,
readline upstream: Please skip the next paragraph.
the time64 transition causes a DEP17 P1 problem for the actual shared
libraries contained in libreadline8t64. These were located below /lib in
libreadline8 in bookworm and thus can be lost in an upgrade. I'm
attaching a patch to add protective diversions for this situation. Since
this library is rather close to essential, I'm using the conservative
method of keeping the diversions beyond postinst. In forky, we can
remove the diversions and in forky+1, we can remove the maintainer
scripts introduced here.
Given the proximity of readline to the base system (e.g. fdisk and
python3 depend on it), I also looked into alternatives.
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libreadline-dev/base_to_lfs/compat_report.html
indicates that we are not faced with LFS ABI changes, but
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libreadline-dev/lfs_to_time_t/compat_report.html
indicates that we are faced with history_get_time changing its return
type from 32bit to 64bit. Providing ABI duality here is even easier than
in the case of libselinux and upstream is vaguely active (last commit 3
weeks ago). Also note that this function already handles range errors
and returns 0 in that case. This behaviour could naturally be extended
for 2038. I think providing duality here would reduce the risk of failed
upgrades breaking user systems.
Context:
https://sources.debian.org/src/readline/8.2-3/history.c/?hl=241#L241
Sketch:
// .h
#if time64 changes ABI
typedef time_t time64_t;
typedef int32_t time32_t;
time64_t history_get_time64 (HIST_ENTRY *hist);
time32_t history_get_time (HIST_ENTRY *hist);
#define history_get_time history_get_time64
#else
time_t history_get_time (HIST_ENTRY *hist);
#endif
// .c
time_t
// The earlier #define may change the function name
history_get_time (HIST_ENTRY *hist)
{
// original function unchanged
}
#if time64 changes ABI
#undef history_get_time
time32_t
history_get_time (HIST_ENTRY *hist)
{
time64_t ret64 = history_get_time(hist);
time32_t ret32 = ret64;
if ((time64_t)ret32 != ret64)
return (time32_t)0;
return ret32;
}
#endif
I've directly Cced readline upstream to see whether they're interested.
Helmut
diff --minimal -Nru readline-8.2/debian/changelog readline-8.2/debian/changelog
--- readline-8.2/debian/changelog 2024-02-19 23:47:01.0 +0100
+++ readline-8.2/debian/changelog 2024-02-20 09:18:09.0 +0100
@@ -1,3 +1,11 @@
+readline (8.2-3.1~exp1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * DEP17 P1: Mitigate file loss due to package rename with concurrent
+aliasing change. Closes: #-1.
+
+ -- Helmut Grohne Tue, 20 Feb 2024 09:18:09 +0100
+
readline (8.2-3.1~exp1) experimental; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru readline-8.2/debian/libreadline8t64.postrm.in
readline-8.2/debian/libreadline8t64.postrm.in
--- readline-8.2/debian/libreadline8t64.postrm.in 1970-01-01
01:00:00.0 +0100
+++ readline-8.2/debian/libreadline8t64.postrm.in 2024-02-20
09:17:54.0 +0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+if test "$1" = remove; then
+ # DEP17 P1 mitigation. Remove these diversions via postinst once trixie
is released.
+ for lib in libhistory.so.8 libhistory.so.8.2 libreadline.so.8
libreadline.so.8.2; do
+ dpkg-divert --package libreadline8t64 --no-rename --divert
"/lib/#DEB_HOST_MULTIARCH#/$lib.usr-is-merged" --remove
"/lib/#DEB_HOST_MULTIARCH#/$lib"
+ done
+fi
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru readline-8.2/debian/libreadline8t64.preinst.in
readline-8.2/debian/libreadline8t64.preinst.in
--- readline-8.2/debian/libreadline8t64.preinst.in 1970-01-01
01:00:00.0 +0100
+++ readline-8.2/debian/libreadline8t64.preinst.in 2024-02-20
09:18:03.0 +0100
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+if test "$1" = install -o "$1" = upgrade; then
+ # DEP17 P1 mitigation. Remove these diversions via postinst once trixie
is released.
+ for lib in libhistory.so.8 libhistory.so.8.2 libreadline.so.8
libreadline.so.8.2; do
+ dpkg-divert --package libreadline8t64 --no-rename --divert
"/lib/#DEB_HOST_MULTIARCH#/$lib.usr-is-merged" --add
"/lib/#DEB_HOST_MULTIARCH#/$lib"
+ done
+fi
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru readline-8.2/debian/rules readline-8.2/debian/rules
--- readline-8.2/debian/rules 2024-02-19 23:47:01.0 +0100
+++ readline-8.2/debian/rules 2024-02-20 09:18:09.0 +0100
@@ -154,6 +154,9 @@
touch configure-stamp
+debian/%:d
Bug#1064298: libhamlib4t64: ineffective replaces due to /usr-move
Package: libhamlib4t64 Version: 4.5.5-3.1~exp1 Severity: serious Tags: patch User: helm...@debian.org Usertags: dep17p1 Control: affects -1 + libhamlib4 X-Debbugs-Cc: vor...@debian.org, mwhud...@debian.org libhamlib4t64 introduced Replaces for libhamlib4 to take over its files and in that process it also takes over /usr/lib/udev/rules.d/60-libhamlib4.rules. This file also is in libhamlib4 in an aliased location. Moving a file from / to /usr and between packages causes file loss (DEP17 P1). Hence, I'm extending the existing mitigation for DEP17 P7 (M-A:same shared file loss) to cover the new P1 problem introduced by time64. See my attched patch. The protective diversion will be kept beyond postinst and stay around. Since the earlier diversion in libhamlib4 was removed in postinst, there cannot be any conflict on diversions. I tested the upgrade using piuparts. Helmut diff --minimal -Nru hamlib-4.5.5/debian/changelog hamlib-4.5.5/debian/changelog --- hamlib-4.5.5/debian/changelog 2024-02-17 04:43:05.0 +0100 +++ hamlib-4.5.5/debian/changelog 2024-02-19 19:50:40.0 +0100 @@ -1,3 +1,11 @@ +hamlib (4.5.5-3.1~exp1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Extend DEP17 P7 mitigation (protective diversion for udev rules) to also +cover P1 (package rename). (Closes: #-1) + + -- Helmut Grohne Mon, 19 Feb 2024 19:50:40 +0100 + hamlib (4.5.5-3.1~exp1) experimental; urgency=medium * Non-maintainer upload. diff --minimal -Nru hamlib-4.5.5/debian/libhamlib4t64.lintian-overrides hamlib-4.5.5/debian/libhamlib4t64.lintian-overrides --- hamlib-4.5.5/debian/libhamlib4t64.lintian-overrides 2024-02-17 04:43:05.0 +0100 +++ hamlib-4.5.5/debian/libhamlib4t64.lintian-overrides 2024-02-19 19:50:40.0 +0100 @@ -1,4 +1,4 @@ # protective diversion for upgrades of files moved from / to /usr # see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056692 -libhamlib4t64: diversion-for-unknown-file lib/udev/rules.d/60-libhamlib4t64.rules [preinst:14] +libhamlib4t64: diversion-for-unknown-file lib/udev/rules.d/60-libhamlib4.rules [preinst:*] libhamlib4t64: package-name-doesnt-match-sonames libhamlib4 diff --minimal -Nru hamlib-4.5.5/debian/libhamlib4t64.postinst hamlib-4.5.5/debian/libhamlib4t64.postinst --- hamlib-4.5.5/debian/libhamlib4t64.postinst 2024-02-17 04:43:05.0 +0100 +++ hamlib-4.5.5/debian/libhamlib4t64.postinst 2024-02-19 13:56:14.0 +0100 @@ -7,17 +7,6 @@ rm -f /etc/udev/rules.d/60-libhamlib4.rules -# begin-remove-after: released:forky -# protective diversion of files moved from / to /usr, to avoid file loss. -# Only for upgrades. -if [ "$1" = "configure" ]; then -# At this point, the package will have installed the same file in */usr*. -dpkg-divert --package usr-is-merged --no-rename \ ---divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \ ---remove /lib/udev/rules.d/60-libhamlib4.rules -fi -# end-remove-after - #DEBHELPER# exit 0 diff --minimal -Nru hamlib-4.5.5/debian/libhamlib4t64.postrm hamlib-4.5.5/debian/libhamlib4t64.postrm --- hamlib-4.5.5/debian/libhamlib4t64.postrm2024-02-17 04:43:05.0 +0100 +++ hamlib-4.5.5/debian/libhamlib4t64.postrm2024-02-19 13:56:50.0 +0100 @@ -5,16 +5,13 @@ dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@" -# begin-remove-after: released:forky # protective diversion of files moved from / to /usr, to avoid file loss. # Only for upgrades. if [ "$1" = "remove" ] && [ "$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = "1" ]; then -# Cleanup in case package is removed before upgrade is finished (postinst ran). dpkg-divert --package usr-is-merged --no-rename \ --divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \ --remove /lib/udev/rules.d/60-libhamlib4.rules fi -# end-remove-after #DEBHELPER# diff --minimal -Nru hamlib-4.5.5/debian/libhamlib4t64.preinst hamlib-4.5.5/debian/libhamlib4t64.preinst --- hamlib-4.5.5/debian/libhamlib4t64.preinst 2024-02-17 04:43:05.0 +0100 +++ hamlib-4.5.5/debian/libhamlib4t64.preinst 2024-02-19 13:55:31.0 +0100 @@ -5,15 +5,13 @@ dpkg-maintscript-helper rm_conffile /etc/udev/60-libhamlib4.rules -- "$@" -# begin-remove-after: released:forky # protective diversion of files moved from / to /usr, to avoid file loss. -# Only for upgrades. -if [ "$1" = "upgrade" ]; then +if [ "$1" = upgrade ] || [ "$1" = install ]; then +# The diversion should be removed after trixie is released. dpkg-divert --package usr-is-merged --no-rename \ --divert /lib/udev/rules.d/60-libhamlib4.rules.usr-is-merged \ --add /lib/udev/rules.d/60-libhamlib4.rules fi -# end-remove-after #DEBHELPER#
Bug#1063922: libnfft3-long4 has an undeclared file conflict
Package: libnfft3-long4 Version: 3.5.3-3 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libnfft3-long2 libnfft3-long4 has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/libnfft3l.so.4 * /usr/lib/x86_64-linux-gnu/libnfft3l.so.4.0.3 * /usr/lib/x86_64-linux-gnu/libnfft3l_threads.so.4 * /usr/lib/x86_64-linux-gnu/libnfft3l_threads.so.4.0.3 are contained in the packages * libnfft3-long2/3.5.3-1 as present in unstable * libnfft3-long4/3.5.3-3 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1063924: libnetplan1 has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libnetplan.so.0.0
Package: libnetplan1 Version: 0.107.1-3+exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libnetplan0 X-Debbugs-Cc: Lukas Märdian , vor...@debian.org libnetplan1 has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/x86_64-linux-gnu/libnetplan.so.0.0 is contained in the packages * libnetplan0 * 0.101-4 as present in bullseye * 0.106-2+deb12u1 as present in bookworm * 0.107.1-3 as present in trixie|unstable * libnetplan1/0.107.1-3+exp1 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1063923: node-shapefile has an undeclared file conflict
Package: node-shapefile Version: 0.3.1+~cs14.23.94-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + shapelib node-shapefile has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/bin/dbfcat * /usr/bin/shpcat are contained in the packages * node-shapefile/0.3.1+~cs14.23.94-1 as present in unstable * shapelib * 1.5.0-2 as present in bullseye * 1.5.0-3+b1 as present in bookworm * 1.6.0-1 as present in trixie|unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1063921: gstreamer1.0-plugins-good has an undeclared file conflict
Package: gstreamer1.0-plugins-good Version: 1.23.1-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + gstreamer1.0-plugins-ugly gstreamer1.0-plugins-good has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so * /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so are contained in the packages * gstreamer1.0-plugins-good/1.23.1-1 as present in experimental * gstreamer1.0-plugins-ugly * 1.22.0-2+deb12u1 as present in bookworm|bookworm-security * 1.22.10-1 as present in unstable * 1.22.9-1 as present in trixie These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1063918: geary FTBFS with the nocheck build profile: ../meson.build:226:6: ERROR: Program 'update-desktop-database' not found or not executable
Source: geary Version: 44.1-1 Severity: serious Tags: ftbfs trixie sid geary fails to build from source in unstable when enabling the nocheck build profile. Since trixie, such a failure is considered release-critical. A build ends with: | ../meson.build:226:6: ERROR: Program 'update-desktop-database' not found or not executable | dh_auto_configure: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 -Drevno=Debian/44.1-1 -Dprofile=release returned exit code 1 | make[1]: *** [debian/rules:24: override_dh_auto_configure] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:21: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Consider dropping inappropriate annotations. Helmut
Bug#1063457: nordugrid-arc and arcstat
On Mon, Feb 12, 2024 at 04:08:40PM +, 陈 晟祺 wrote: > As a (tentative) solution, we discussed and decided to move arcstat back to > sbin on the zfs-linux side. That would leave the current situation untouched > until maintainers from both sides form a consensus on how to handle this. While you may move arcstat back to sbin, doing so does not address or fix this bug. The arcstat command is still being provided (albeit in a different place) and hence policy is still being violated. If you want to migrate a zfs-linux upload to testing, you may adjust the found version to clarify that it already affects trixie and also periodically update this bug to prevent the autoremover from taking action. > We will keep working on this and try to ask for more advice from both users > and developers. Yes, please. Helmut
Bug#1063457: nordugrid-arc and arcstat
On Mon, Feb 12, 2024 at 09:13:50AM +0100, Mattias Ellert wrote: > NorduGrid ARC has used the name arcstat since release 1.0. It has been > in Debian since January 2010 (source package nordugrid-arc-nox, later > renamed nordugrid-arc in May 2011). > > The command is part of a set of commands, all using the arc prefix: > arccat arcget arckillarcproxy arcresume arcsync > arcclean arcls arcrename arcrm arctest > arccp arched arcmkdir arcrenew arcstat > arcctl arcinfoarcplugin arcresub arcsub Thank you for providing background. Given that zfs-linux was first uploaded to Debian in 2016, it seems quite clear to me that the command reasonably belongs to nordugrid. Do we all agree to reassign the bug back to zfs-linux and have it release the name? If not, please discuss with debian-de...@lists.debian.org. Given that this issue is quite old and that forky is still quite in progress, I don't see any reason to rush any action right now. Having a civilized discussion and consensus on a long-term solution should be focus from my point of view. Helmut
Bug#1063525: d-spy FTBFS with nocheck profile: ../meson.build:187:6: ERROR: Program 'update-desktop-database' not found or not executable
Source: d-spy Version: 1.8.0-1 Severity: serious Tags: ftbfs trixie sid d-spy fails to build from source when built with the nocheck build profile. Since trixie such a failure is considered release-critical. A build ends with: | ../meson.build:187:6: ERROR: Program 'update-desktop-database' not found or not executable | dh_auto_configure: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 returned exit code 1 | make: *** [debian/rules:8: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Helmut
Bug#958587: lockdown FTBFS due to B-D: dh-systemd
Control: retitle -1 lockdown FTBFS: Build-Depends on deprecated dh-systemd which is no longer available Control: tags -1 + ftbfs This bug has become a FTBFS. Tagging as such. Helmut
Bug#1027889: use of dh_dkms without b-d: dh-dkms is a FTBFS
Control: retitle -1 kpatch FTBFS: please switch to B-D: dh-sequence-dkms (or dh-dkms) Control: tags -1 + ftbfs Using dh_dkms without Build-Depends: dh-dkms makes the package ftbfs: | make[1]: dh_dkms: No such file or directory | make[1]: *** [debian/rules:23: override_dh_install] Error 127 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:11: binary] Error 2 | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Andreas filed the bug at serious severity, but it doesn't yet correctly identify as FTBFS. Helmut
Bug#1063498: rust-glib-sys FTBFS with the nocheck build profile: cp: cannot stat '/usr/share/gir-1.0/GLib-2.0.gir': No such file or directory
Source: rust-glib-sys Version: 0.18.1-2 Severity: serious Tags: ftbfs trixie sid rust-glib-sys fails to build from source in unstable when built with the nocheck build profile. Since trixie, a nocheck failure is considered release-critical. A build ends with: |debian/rules execute_before_dh_auto_build | make[1]: Entering directory '/<>' | cp /usr/share/gir-1.0/GLib-2.0.gir /<> | cp: cannot stat '/usr/share/gir-1.0/GLib-2.0.gir': No such file or directory | make[1]: *** [debian/rules:9: execute_before_dh_auto_build] Error 1 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:4: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Helmut
Bug#1063457: zfsutils-linux abuses Conflicts in violation of policy 10.1
Control: reassign -1 zfsutils-linux,nordugrid-arc-client On Thu, Feb 08, 2024 at 01:49:34PM +, 陈 晟祺 wrote: > We are aware of this. arcstat is NOT a new binary added in recent versions, > but is installed into /usr/sbin for several years and versions. I moved it to > /usr/bin > because it does not actually require specific permission to use. That is a piece of history I was unaware of. Unfortunate. > Is there any suggestion on such situation? Keeping ours in sbin would cause > (the > long-existing) confusion to user if they install both packages and find that > two > different arcstat exist in bin and sbin. Renaming either one would also make > trouble. We have precedent for similar situations in Debian. Probably the most prominent is /usr/bin/node. If no agreement can be found over the name, the typical course of action is to rename both. In the long term, it would be ideal to get both upstreams talk to each other and have them to agree that either of them releases the name. In general, arcstat using update-alternatives is inappropriate, because they are not different implementations of the same functionality. Getting advice from debian-de...@lists.debian.org also seems like a valid approach. We can use feedback to guesstimate the relative uses of the name. As you say that this is not a new issue, but was merely hidden by the sbin vs bin difference, I am reassigning the bug to both packages. Helmut
Bug#1063499: rust-gobject-sys FTBFS with nocheck build profile: cp: cannot stat '/usr/share/gir-1.0/GObject-2.0.gir': No such file or directory
Source: rust-gobject-sys Version: 0.18.0-2 Severity: serious Tags: ftbfs trixie sid rust-gobject-sys fails to build from source in unstable when built with the nocheck build profile. Since trixie, a nocheck build failure is considered release-critical. A build ends with: |debian/rules execute_before_dh_auto_build | make[1]: Entering directory '/<>' | cp /usr/share/gir-1.0/GObject-2.0.gir /<> | cp: cannot stat '/usr/share/gir-1.0/GObject-2.0.gir': No such file or directory | make[1]: *** [debian/rules:8: execute_before_dh_auto_build] Error 1 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:3: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Please review the annotations. Helmut
Bug#1063457: zfsutils-linux abuses Conflicts in violation of policy 10.1
Package: zfsutils-linux Version: 2.2.2-5~exp3 Severity: serious Justification: Debian policy section 10.1 zfsutils-linux declares Conflicts with nordugrid-arc-client, because both provide /usr/bin/arcstat. This conflict is in violation of Debian policy 10.1: | Two different packages must not install programs with different | functionality but with the same filenames. The name arcstat is currently owned by nordugrid-arc-client and cannot be taken over by zfsutils-linux simply by declaring a conflict. Helmut
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Andreas,
On Wed, Feb 07, 2024 at 03:47:37PM +0100, Andreas Metzler wrote:
> Package: libselinux1t64
> Replaces: libselinux1
> Provides: libselinux1 (= 3.5-2.1~exp1)
> Breaks: libselinux1 (<< 3.5-2.1~exp1)
>
> Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
> "libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
> version gets a dep on "libselinux1t64 (>= 3.5)".
The *t64 libraries only break ABI on some architectures. Notably, on all
64bit architectures, i386 and x32, the ABI will not change. On the next
upload after the transition, library dependencies will move to the t64
variants, yes.
> Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
> for real t64-builds? (The ones in experimental are not.) If that is case
> this bug and this way of testing does not make sense.
No, the t64:Provides will remain that way for all architectures that do
not break ABI. In theory, we could have skipped the rename on those
architectures, but having architecture-dependent package names is
annoyingly hard. Hence, we rename them on e.g. amd64 as well even though
nothing changes there.
Hope this explains
Helmut
Bug#1063393: systemd FTBFS with nocheck build profile: ../meson.build:1810:33: ERROR: Feature ukify cannot be enabled: Python >= 3.9 and pefile required
Source: systemd Version: 255.3-1 Severity: serious Tags: ftbfs trixie sid Hi, systemd fails to build from source when built with the nocheck build profile. Since trixie, such a failure is considered release-critical. The notable message probably is: | ../meson.build:1810:33: ERROR: Feature ukify cannot be enabled: Python >= 3.9 and pefile required I guess your python3-pefile dependency should not be tagged and it should probably be annotated :native until it becomes M-A:foreign. Helmut
Bug#1063392: zfsutils-linux has an undeclared file conflict on /usr/bin/arcstat
Package: zfsutils-linux Version: 2.2.2-5~exp2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + nordugrid-arc-client zfsutils-linux has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/arcstat is contained in the packages * nordugrid-arc-client * 6.10.2-1 as present in bullseye * 6.17.0-3 as present in bookworm * 6.18.0-1 as present in trixie|unstable * zfsutils-linux/2.2.2-5~exp2 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Guillem,
On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> Yes, I'm not sure I understand either. This is what symbol versioning
> makes possible, even providing different variants for the same symbol,
> see for example glibc or libbsd.
I think symbol versioning is subtly different and glibc does not use
symbol versioning for e.g. gettimeofday selection. With symbol
versioning, you select a default version at release time and stick to
it. In other words, building against the updated libselinux does not
allow you to use the older 32bit variant of the symbol even if you opt
out of lfs and time64 and you always get the 64bit symbol. What glibc
does is a little more fancy than my simplistic #define in that it uses
asm("name") instead. Still this approach allows for selecting which
symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
me if I am misrepresenting this as my experience with symbol versioning
is fairly limited.
> In any case, if going the bi-ABI path, I think upstream should get
> involved, and the shape of this decided with them. In addition
> the library should also be built with LFS by the upstream build
> system, which it does not currently, to control its ABI.
I agree that involving upstream is a good idea and my understanding is
that someone from Canonical is doing that already, which is why the
schedule was delayed.
My real question here though is what's the downsides of providing two
variants of this symbol (whether with symbol versioning or name
redirection). From my pov, this effectively is your option 3 and what I
sketched is the most stupid implementation of it. My sketch did assume
that libselinux would be built with LFS support everywhere including
i386. Enabling that on the upstream side definitely is even better,
because it gets us to not have a Debian-specific ABI.
> I think there are only three ways to go about this, excluding the t64
> attempt:
Thanks for confirming that I've reported a real problem.
> If you'd like assistance with trying to get a proposal for 3 to
> present upstream I could look into that. But I think they should be
> involved early on to see what they'd like to see and what they might
> outright reject.
>From my naive point of view, this option 3 is the clear winner. Though
it all depends on what upstream says. If upstream cooperates on any
option, that's better still as we avoid ABI deviation.
Going from here, I also looked a bit into whether we could additionally
use an upstream-cooperating approach for other packages central to
Debian to avoid t64 bumps.
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
We cannot symbol-version these in a reasonable way. All we could do is
ask upstream for a real soname bump. We have a slight advantage here: On
little endian (such as armhf), we can extend this to 64bit and 32bit
accesses will continue to work for small values. However, doing this to
m68k would break horribly. I also couldn't find any in-Debian users of
these symbols (super merely vendors pam source), so just bumping it and
accepting breakage (Guillems option 1) might be worth a go?
For libaudit1, I fail to understand why we bump it at all. Both reports
look fine to me:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/base_to_lfs/compat_report.html
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/lfs_to_time_t/compat_report.html
This does not extend to libauparse0 where the report gives a reason, but
libaudit1 is the one that interacts with /usr-move and libauparse0 not,
so can we skip the dance for libaudit1?
For libtirpc, it is only about rpcb_gettime, which returns time via a
time_t* and can indicate success/failure via return. It seems fairly
simple to implement ABI duality here and libtirpc already does symbol
versioning. Maybe we can also approach upstream about this?
For libfuse2, I think the ABI analysis is broken. The base-to-lfs report
supposedly is ok
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/base_to_lfs/compat_report.html
and then going lfs-to-time changes ino_t
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/lfs_to_time_t/compat_report.html
while I would have expected ino_t to change with lfs already. Are we
sure about this? In any case, this is more of an academic question as
adding ABI-duality would be more involved here. Moreover, I don't see
any ACC report for libfuse3-dev. Did that fail to analyze?
libiw30 only has one affected symbol:
iw_print_timeval ( char* buffer, int buflen, struct timeval const* time, struct
timezone const* tz )
Providing ABI duality for this seems doable. Moreover, libiw30 already
has soname 30, so maybe upstream is open to bumping it again? The
resulting library transition is
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote: > Providing two APIs makes me quite uneasy due to having core components > that would behave differently from the rest of the distribution. It > sounds like something that will come back to bite for a long time. Can you elaborate? Keep in mind that for all the 64bit architectures, there is no abi difference as the symbol is only added for those architectures, that currently use a 32bit ino_t. > I checked on codesearch.d.n and there are very few users on this API; > actually, none I think. Per > https://codesearch.debian.net/search?q=matchpathcon_filespec_add=1=1 > - box64 mentions that API but the "code" is commented-out, > - busybox uses it in the "setfiles" applet which isn't built, > - android-platform-external-libselinux has it in headers but also has > its own implementation > > That should hopefully give more freedom although I'm not sure what would > be the preferred route. And here you are arguing that there are no practical users of the added symbol, so with luck, we'd be adding an unused symbol on armhf. With bad luck, we'd have some users and for those users we'd be ABI-incompatible with the rest of the world on armhf. Helmut
Bug#1063323: libiw30t64: file loss due to /usr-move (DEP17)
On Tue, Feb 06, 2024 at 07:42:49AM +0100, Helmut Grohne wrote:
> I'm attaching a patch for your convenience. I consider that libiw30 is
> not as central as other packages and hence propose employing Conflicts
> here. Conflicts allow removing the protective diversion in trixie's
> postinst rather than forky's postinst already.
Steve made me aware that such Conflicts and Breaks should be versioned
as they may otherwise interact with Provides and multiarch. Updated
patch attached.
Helmut
diff --minimal -Nru wireless-tools-30~pre9/debian/changelog
wireless-tools-30~pre9/debian/changelog
--- wireless-tools-30~pre9/debian/changelog 2024-02-04 21:34:45.0
+0100
+++ wireless-tools-30~pre9/debian/changelog 2024-02-06 07:33:48.0
+0100
@@ -1,3 +1,9 @@
+wireless-tools (30~pre9-16.1~exp2) UNRELEASED; urgency=medium
+
+ * Fix /usr-move file loss. (Closes: #-1)
+
+ -- Helmut Grohne Tue, 06 Feb 2024 07:33:48 +0100
+
wireless-tools (30~pre9-16.1~exp1) experimental; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru wireless-tools-30~pre9/debian/clean
wireless-tools-30~pre9/debian/clean
--- wireless-tools-30~pre9/debian/clean 1970-01-01 01:00:00.0 +0100
+++ wireless-tools-30~pre9/debian/clean 2024-02-06 07:33:30.0 +0100
@@ -0,0 +1,2 @@
+debian/libiw30t64.preinst
+debian/libiw30t64.postinst
diff --minimal -Nru wireless-tools-30~pre9/debian/control
wireless-tools-30~pre9/debian/control
--- wireless-tools-30~pre9/debian/control 2024-02-04 21:34:45.0
+0100
+++ wireless-tools-30~pre9/debian/control 2024-02-06 07:31:36.0
+0100
@@ -31,8 +31,7 @@
Package: libiw30t64
Provides: ${t64:Provides}
-Replaces: libiw30
-Breaks: libiw30 (<< ${source:Version})
+Conflicts: libiw30 (<< ${source:Version})
Section: libs
Architecture: linux-any
Multi-Arch: same
diff --minimal -Nru wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides
wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides
--- wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides 2024-02-04
21:34:45.0 +0100
+++ wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides 2024-02-06
07:33:48.0 +0100
@@ -1 +1,5 @@
libiw30t64: package-name-doesnt-match-sonames libiw30
+# begin-remove-after: released:trixie
+# DEP17 protective diversion
+diversion-for-unknown-file lib/x86_64-linux-gnu/libiw.so.30 [preinst:*]
+# end-remove-after
diff --minimal -Nru wireless-tools-30~pre9/debian/libiw30t64.postinst.in
wireless-tools-30~pre9/debian/libiw30t64.postinst.in
--- wireless-tools-30~pre9/debian/libiw30t64.postinst.in1970-01-01
01:00:00.0 +0100
+++ wireless-tools-30~pre9/debian/libiw30t64.postinst.in2024-02-06
07:29:28.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if [ "$1" = configure ]; then
+ dpkg-divert --package libiw30t64 --no-rename --remove --divert
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30.usr-is-merged"
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30"
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru wireless-tools-30~pre9/debian/libiw30t64.preinst.in
wireless-tools-30~pre9/debian/libiw30t64.preinst.in
--- wireless-tools-30~pre9/debian/libiw30t64.preinst.in 1970-01-01
01:00:00.0 +0100
+++ wireless-tools-30~pre9/debian/libiw30t64.preinst.in 2024-02-06
07:29:30.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if [ "$1" = install ]; then
+ dpkg-divert --package libiw30t64 --no-rename --add --divert
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30.usr-is-merged"
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30"
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru wireless-tools-30~pre9/debian/rules
wireless-tools-30~pre9/debian/rules
--- wireless-tools-30~pre9/debian/rules 2023-11-28 01:03:11.0 +0100
+++ wireless-tools-30~pre9/debian/rules 2024-02-06 07:33:39.0 +0100
@@ -19,3 +19,8 @@
override_dh_installudev:
dh_installudev --priority=19
+
+debian/%:debian/%.in
+ sed -e 's/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/g' $< > $@
+
+execute_before_dh_installdeb:debian/libiw30t64.preinst
debian/libiw30t64.postinst
