Bug#1073922: systemd-{container,cryptsetup,repart}: ineffective Replaces due to /usr-move (DEP17)
Package: systemd-container,systemd-cryptsetup,cryptsetup-repart Version: 256.1-1 Severity: serious Control: affects -1 + systemd User: helm...@debian.org Usertags: dep17p1 Hi, Version 256.1-1 was restructured splitting a number of pieces from the main systemd package into other packages. As far as I can see, the same changes were already present in experimental and I need to investigate why dumat did not flag them there. Let me not go into details of this problem just yet and just install this bug as a temporary migration blocker. I shall have an update within three working days, ideally with a patch. Thanks for your patience. The dumat report is not very human-readable, but available at https://subdivi.de/~helmut/dumat.yaml. Helmut
Bug#1073743: softflowd: move aliased files from / to /usr (DEP17)
Hi Christoph, On Wed, Jun 19, 2024 at 05:26:14PM +0200, Christoph Biedl wrote: > an observation: When comparing the result of a manually adjusted > softflowd (upload pending) and the result of dh-sequence-movetousr, I > noticed a difference in the init script (using a private > re-implementation of debdiff as the original one does not show this for > whatever reason): It is correct that dh-sequence-movetousr does not look into files and merely shuffles them around. > So, the dh-sequence-movetousr helper did not cover this but, quite > frankly, I didn't expect it to do so. Good. > However, in my opinion it is prudent to completely stop referring to > the legacy places. Compatability symlinks are in place, and will be for > a long time. But when I touch the packaging, I'd prefer create a robust > result, not something that just works. The goal you are picturing is not attainable. There is no reasonable way we are going to stop using "#/bin/sh" or "/lib64/ld-linux-x86-64.so.2". Given that these will never go away, you may fully rely on these symlinks. > This might or might not be in the scope of DEP-14, so feel free to > take this as a bug report, as some information, or just anecdotical. I think you mean DEP17. > Personally however, I'd implement at least some rudimentary checks > for the situation of referring to files in the legacy places, and file > reports with a rather low priority - until somebody decides to remove > the compat symlinks in a future Debian release. I believe such effort is not a good use of our time. The reason for moving files around is to avoid a bug class. The reason for referring to files via their physical paths is much less well-motivated. Hence, I recommend not spending time on it, but then I won't stop you either. On a technical level, I see little advantages or disadvantages about using either path. Helmut
Bug#1073750: lightdm: move aliased files from / to /usr (DEP17)
Hi Yves-Alexis, On Wed, Jun 19, 2024 at 10:05:54PM +0200, Yves-Alexis Perez wrote: > the lightdm.service file is installed via debian/lightdm.install. My first > impulse would be to just move that to /usr/lib/systemd/system. do you see any > issue with that? That quite definitely is the long term solution. It has one downside: Backporting to bookworm-backports and earlier will result in a broken package that is not (re)started during package installation and upgrades. Now lightdm is not a package with a long history of backports so this trade-off may well be a good one and a backport also can revert this change (if one remembers to do so). So this mainly is a question of how you want to deal with backports. Helmut
Bug#1073832: firmware-{intel-graphics,intel-misc,marvell-prestera,mediatek,misc-nonfree,nvidia-graphics}: ineffective replaces due to /usr-move (DEP17)
for script, script_contents in scripts.items(): +script_contents.insert(0, "#!/bin/sh\n\nset -e\n") +script_contents.append("#DEBHELPER#\n\nexit 0\n") +open("debian/firmware-%s.%s" % (package, script), "w").write("\n".join(script_contents)) + packages.extend(packages_binary) makefile.add_cmds('binary-indep', ["$(MAKE) -f debian/rules.real binary-indep %s" % makeflags]) diff --minimal -Nru firmware-nonfree-20230625/debian/changelog firmware-nonfree-20230625/debian/changelog --- firmware-nonfree-20230625/debian/changelog 2024-06-18 02:33:12.0 +0200 +++ firmware-nonfree-20230625/debian/changelog 2024-06-19 13:11:28.0 +0200 @@ -1,3 +1,11 @@ +firmware-nonfree (20230625-3~exp2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Mitigate loss of files due to restructuring and /usr-move +(DEP17 P1, Closes: #-1) + + -- Helmut Grohne Wed, 19 Jun 2024 13:11:28 +0200 + firmware-nonfree (20230625-3~exp2) experimental; urgency=medium * qcom-soc: Re-fix lintian override for lib/firmware/qcom/apq8096/modem.mbn diff --minimal -Nru firmware-nonfree-20230625/debian/config/intel-graphics/defines firmware-nonfree-20230625/debian/config/intel-graphics/defines --- firmware-nonfree-20230625/debian/config/intel-graphics/defines 2024-06-18 02:33:12.0 +0200 +++ firmware-nonfree-20230625/debian/config/intel-graphics/defines 2024-06-19 11:29:05.0 +0200 @@ -4,8 +4,7 @@ the Intel Graphics Media Driver aka i915 driver in the Linux kernel. This supports the iGPU found in f.e. Broadwell/Skylake/Broxton and Apollo/Gemini/Kaby/Coffee/Ice/Tiger/etc Lake CPUs. -replaces: firmware-misc-nonfree (<< 20230625-3~) -breaks: firmware-misc-nonfree (<< 20230625-3~) +conflicts: firmware-misc-nonfree (<< 20230625-3~) files: i915/adlp_dmc.bin i915/adlp_dmc_ver2_09.bin @@ -131,6 +130,127 @@ i915/tgl_huc_7.5.0.bin i915/tgl_huc_7.9.3.bin intel/irci_irci_ecr-master_20161208_0213_20170112_1500.bin +usrmovemitigation: + i915/adlp_dmc.bin + i915/adlp_dmc_ver2_09.bin + i915/adlp_dmc_ver2_10.bin + i915/adlp_dmc_ver2_12.bin + i915/adlp_dmc_ver2_14.bin + i915/adlp_dmc_ver2_16.bin + i915/adlp_guc_62.0.3.bin + i915/adlp_guc_69.0.3.bin + i915/adlp_guc_70.1.1.bin + i915/adlp_guc_70.bin + i915/adls_dmc_ver2_01.bin + i915/bxt_dmc_ver1.bin + i915/bxt_dmc_ver1_07.bin + i915/bxt_guc_32.0.3.bin + i915/bxt_guc_33.0.0.bin + i915/bxt_guc_49.0.1.bin + i915/bxt_guc_62.0.0.bin + i915/bxt_guc_69.0.3.bin + i915/bxt_guc_70.1.1.bin + i915/bxt_guc_ver8_7.bin + i915/bxt_guc_ver9_29.bin + i915/bxt_huc_2.0.0.bin + i915/bxt_huc_ver01_07_1398.bin + i915/bxt_huc_ver01_8_2893.bin + i915/cml_guc_33.0.0.bin + i915/cml_guc_49.0.1.bin + i915/cml_guc_62.0.0.bin + i915/cml_guc_69.0.3.bin + i915/cml_guc_70.1.1.bin + i915/cml_huc_4.0.0.bin + i915/cnl_dmc_ver1_07.bin + i915/dg1_dmc_ver2_02.bin + i915/dg1_guc_49.0.1.bin + i915/dg1_guc_62.0.0.bin + i915/dg1_guc_69.0.3.bin + i915/dg1_guc_70.1.1.bin + i915/dg1_guc_70.bin + i915/dg1_huc.bin + i915/dg1_huc_7.7.1.bin + i915/dg1_huc_7.9.3.bin + i915/dg2_dmc_ver2_06.bin + i915/dg2_dmc_ver2_07.bin + i915/dg2_dmc_ver2_08.bin + i915/dg2_guc_70.1.2.bin + i915/dg2_guc_70.4.1.bin + i915/dg2_guc_70.bin + i915/ehl_guc_33.0.4.bin + i915/ehl_guc_49.0.1.bin + i915/ehl_guc_62.0.0.bin + i915/ehl_guc_69.0.3.bin + i915/ehl_guc_70.1.1.bin + i915/ehl_huc_9.0.0.bin + i915/glk_dmc_ver1_04.bin + i915/glk_guc_32.0.3.bin + i915/glk_guc_33.0.0.bin + i915/glk_guc_49.0.1.bin + i915/glk_guc_62.0.0.bin + i915/glk_guc_69.0.3.bin + i915/glk_guc_70.1.1.bin + i915/glk_huc_4.0.0.bin + i915/glk_huc_ver03_01_2893.bin + i915/icl_dmc_ver1_07.bin + i915/icl_dmc_ver1_09.bin + i915/icl_guc_32.0.3.bin + i915/icl_guc_33.0.0.bin + i915/icl_guc_49.0.1.bin + i915/icl_guc_62.0.0.bin + i915/icl_guc_69.0.3.bin + i915/icl_guc_70.1.1.bin + i915/icl_huc_9.0.0.bin + i915/icl_huc_ver8_4_3238.bin + i915/kbl_dmc_ver1.bin + i915/kbl_dmc_ver1_01.bin + i915/kbl_dmc_ver1_04.bin + i915/kbl_guc_32.0.3.bin + i915/kbl_guc_33.0.0.bin + i915/kbl_guc_49.0.1.bin + i915/kbl_guc_62.0.0.bin + i915/kbl_guc_69.0.3.bin + i915/kbl_guc_70.1.1.bin + i915/kbl_guc_ver9_14.bin + i915/kbl_guc_ver9_39.bin + i915/kbl_huc_4.0.0.bin + i915/kbl_huc_ver02_00_1810.bin + i915/mtl_dmc.bin + i915/rkl_dmc_ver2_02.bin + i915/rkl_dmc_ver2_03.bin + i915/skl_dmc_ver1.bin + i915/skl_dmc_ver1_23.bin + i915/skl_dmc_ver1_26.bin + i915/skl_dmc_ver1_27.bin + i915/skl_guc_32.0.3.bin + i915/skl_guc_33.0.0.bin + i915/skl_guc_49.0.1.bin + i915/skl_guc_62.0.0.bin + i915/skl_guc_69.0.3.bin + i915/skl_guc_70.1.1.bin + i915/skl_guc_ver1.bin + i915/skl_guc_ver4.bin + i915/skl_guc_ver6.bin + i915/skl_guc_ver6_1.bin + i915/skl_guc_ver9_33.bin + i915/skl_huc_2.0.0.bin + i915/skl_huc_ver01_07_1398.bin + i915/tgl_dmc_ver2_04.bin + i915/tgl_dmc_ver2_06.bin + i915/tgl_dmc_ver2_08.bin + i915/tgl_dmc_ver2_12.bin + i915/tgl_guc_35.2.0.bin + i915/t
Bug#1073622: Bug#1073608: mksh: move aliased files from / to /usr (DEP17)
Hi Thorsten, On Tue, Jun 18, 2024 at 11:29:34PM +, Thorsten Glaser wrote: > close 1073608 > close 1073622 > thanks > > Helmut Grohne dixit: > > >This package is part of the /usr-move (DEP17) transition, because it > >contains files in aliased locations and should have those files moved to > > No. The files in both packages are in their canonical location. > And if you use a usrmerged system, it does not make any practical > difference anyway. There is a significant difference here. mksh has an undeclared directory vs symlink conflict with base-files about /bin. This is known to cause problems. In principle, what happens with the location is dependent on the unpack order though all practical installations will unpack base-files before mksh. For another dpkg-deb -x mksh.deb / will break a /usr-merged system. At present, most issues are mitigated with maintainer scripts, but we want to drop those mitigations, which is why we require that all packages release aliased locations by trixie. I hope we can agree that there are practical differences and then resume to disagree about their severity. In any case, this was discussed on d-devel extensively and we have wide consensus on this approach. These bug reports will become release critical on August 6th and I will take care of ensuring that trixie does not release with aliasing conflicts even if that amounts to removing offending packages from trixie. If you truly believe that your package has to continue using the aliased paths, please provide an alternative plan for dealing with the problems listed in DEP17. Failing that, we will continue with what was planned. I request that you reopen these bugs even if the solution ends up being a different one than the one I requested, but the status quo is not something we can continue using as is. > For mksh, this is even worse as I regularily backport to before > bookworm so newer version numbers must be able to stay in their > current canonical (i.e. /bin/) location. Thanks for letting us know about your backporting plans. I concur that bookworm and earlier must not move files to /usr as the file move moratorium still is in effect there. If you were only backporting to bookworm, dh-sequence-movetousr would achieve that. For bullseye and earlier, please use a different rune: override_dh_installdeb: ! command -v dh_movetousr >/dev/null || dh_movetousr dh_installdeb This will work on all known releases and do the right thing for backports. Caveats about restructuring changes still apply and I note that we are not monitoring bullseye and earlier about such issues. That seems like a minor issue as these shells are not frequently restructured. Helmut
Bug#1073703: [Pkg-xmpp-devel] Bug#1073703: jabberd2: move aliased files from / to /usr (DEP17)
Control: fixed -1 jabberd2/2.7.0-6 On Tue, Jun 18, 2024 at 01:17:40PM +0200, Simon Josefsson wrote: > Thanks for the report. I take a minimal-effort maintainance approach > for jabberd2, so could you confirm that uploading the package that is in > experimental (which calls dh-sequence-movetousr) to unstable would > resolve this bug? If someone wants to propose how to resolve the bug in > a better way, that would be great but I don't feel up to doing that work > right now. I hope that there won't be any jabberd2 in backports. I confirm. Please go ahead. In any case, the change should just work in bookworm-backports, but not in bullseye-backports-sloppy. Helmut
Bug#1073624: crowdsec-firewall-bouncer: move aliased files from / to /usr (DEP17)
Hi Cyril, On Tue, Jun 18, 2024 at 11:59:27AM +0200, Cyril Brulebois wrote: > I think I've mentioned that on an existing bug report but anyway: preps > for an RC bugfix in testing/unstable + backport to stable are almost > over, and I really want that to get out of the way before considering > merging DEP17 things. Even more so if that complicates backporting. > > That's applicable for all three crowdsec* packages. Thank you. This is fine. The mail is part of a MBF to establish awareness of what needs fixing. It is good to see that you already were aware. If you care about backporting, the good options are using dh_installsystemd and dh-sequence-movetousr as both will just work in backports. You still have a bit of time. We'll be bumping these bugs to rc after DebConf. Helmut
Bug#1052788: python-asyncssh: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 --system=custom "--test-args={interpreter} -m unittest discover -v" returned exit code 13
On Thu, Nov 16, 2023 at 07:50:26PM +, Dale Richards wrote: > Builds fine for me on sid as of 2023-11-16. Build log and diff attached. Fails for me. Here is the relevant part from the log: | == | ERROR: test_connect_timeout_exceeded (tests.test_connection._TestConnection.test_connect_timeout_exceeded) | Test connect timeout exceeded | -- | Traceback (most recent call last): | File "/usr/lib/python3.11/unittest/mock.py", line 1378, in patched | return func(*newargs, **newkeywargs) |^ | File "/<>/tests/util.py", line 81, in async_wrapper | return self.loop.run_until_complete(coro(self, *args, **kwargs)) |^ | File "/usr/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete | return future.result() |^^^ | File "/<>/tests/test_connection.py", line 430, in test_connect_timeout_exceeded | await asyncssh.connect('223.255.255.254', connect_timeout=1) | File "/<>/asyncssh/connection.py", line 7707, in connect | return await asyncio.wait_for( |^^^ | File "/usr/lib/python3.11/asyncio/tasks.py", line 489, in wait_for | return fut.result() | | File "/<>/asyncssh/connection.py", line 430, in _connect | _, session = await loop.create_connection( | ^ | File "/usr/lib/python3.11/asyncio/base_events.py", line 1086, in create_connection | raise exceptions[0] | File "/usr/lib/python3.11/asyncio/base_events.py", line 1070, in create_connection | sock = await self._connect_sock( |^ | File "/usr/lib/python3.11/asyncio/base_events.py", line 974, in _connect_sock | await self.sock_connect(sock, address) | File "/usr/lib/python3.11/asyncio/selector_events.py", line 638, in sock_connect | return await fut |^ | File "/usr/lib/python3.11/asyncio/selector_events.py", line 678, in _sock_connect_cb | raise OSError(err, f'Connect call failed {address}') | OSError: [Errno 101] Connect call failed ('223.255.255.254', 22) | | == | ERROR: test_connect_timeout_exceeded_string (tests.test_connection._TestConnection.test_connect_timeout_exceeded_string) | Test connect timeout exceeded with string value | -- | Traceback (most recent call last): | File "/usr/lib/python3.11/unittest/mock.py", line 1378, in patched | return func(*newargs, **newkeywargs) |^ | File "/<>/tests/util.py", line 81, in async_wrapper | return self.loop.run_until_complete(coro(self, *args, **kwargs)) |^ | File "/usr/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete | return future.result() |^^^ | File "/<>/tests/test_connection.py", line 440, in test_connect_timeout_exceeded_string | await asyncssh.connect('223.255.255.254', connect_timeout='0m1s') | File "/<>/asyncssh/connection.py", line 7707, in connect | return await asyncio.wait_for( |^^^ | File "/usr/lib/python3.11/asyncio/tasks.py", line 489, in wait_for | return fut.result() | | File "/<>/asyncssh/connection.py", line 430, in _connect | _, session = await loop.create_connection( | ^ | File "/usr/lib/python3.11/asyncio/base_events.py", line 1086, in create_connection | raise exceptions[0] | File "/usr/lib/python3.11/asyncio/base_events.py", line 1070, in create_connection | sock = await self._connect_sock( |^ | File "/usr/lib/python3.11/asyncio/base_events.py", line 974, in _connect_sock | await self.sock_connect(sock, address) | File "/usr/lib/python3.11/asyncio/selector_events.py", line 638, in sock_connect | return await fut |^ | File "/usr/lib/python3.11/asyncio/selector_events.py", line 678, in _sock_connect_cb | raise OSError(err, f'Connect call failed {address}') | OSError: [Errno 101] Connect call failed ('223.255.255.254', 22) | | == | ERROR: test_connect_timeout_exceeded_tunnel (tests.test_connection._TestConnection.test_connect_timeout_exceeded_tunnel) | Test connect timeout exceeded | -- | Traceback (most recent call last): | File "/usr/lib/python3.11/unittest/mock.py", line 1378, in patched | return func(*newargs, **newkeywargs)
Bug#1073300: execveat: please explain another reason to return ENOENT
Package: manpages-dev Version: 6.7-2 Severity: normal File: /usr/share/man/man2/execveat.2.gz Tags: patch Hi, I was looking why execveat(..., ..., ..., ..., AT_EMPTY_PATH) was returning -ENOENT for me and figured that the ERRORS section of the manual page would not provide the correct explanation. Lower in the NOTES section, I eventually discovered the cause, but I think it would be useful to have this noted in the ERRORS section directly. Hence, I am proposing a patch to add this reference. Helmut --- manpages-6.8.orig/man/man2/execveat.2 +++ manpages-6.8/man/man2/execveat.2 @@ -140,6 +140,16 @@ flag, with the result that the program file is inaccessible to the launched interpreter. See BUGS. .TP +.B ENOENT +The program identified by +.I dirfd +and +.I pathname +is a dynamically linked executable and the path +.I /dev/fd/N +does not exist. +See NOTES. +.TP .B ENOTDIR .I pathname is relative and
Bug#1073244: ruby-xmlrpc has an undeclared file conflict on /usr/bin/console
Package: ruby-xmlrpc Version: 0.3.3-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + conserver-client ruby-xmlrpc has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/console is contained in the packages * conserver-client * 8.2.6-2 as present in bullseye * 8.2.7-2+b1 as present in bookworm * 8.2.7-2+b3 as present in trixie|unstable * ruby-xmlrpc/0.3.3-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#1073243: libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have an undeclared file conflict
Package: libstdlib-ocaml,libcompiler-libs-ocaml-dev,libstdlib-ocaml-dev Version: 5.2.0-1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libfindlib-ocaml libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/ocaml/compiler-libs/META * /usr/lib/ocaml/ocamldoc/META are contained in the packages * libcompiler-libs-ocaml-dev/5.2.0-1~exp1 as present in experimental * libfindlib-ocaml * 1.8.1-2 as present in bullseye * 1.9.6-1+b1 as present in bookworm * 1.9.6-1+b2 as present in trixie|unstable The files * /usr/lib/ocaml/dynlink/META * /usr/lib/ocaml/threads/META are contained in the packages * libfindlib-ocaml * 1.8.1-2 as present in bullseye * 1.9.6-1+b1 as present in bookworm * 1.9.6-1+b2 as present in trixie|unstable * libstdlib-ocaml-dev/5.2.0-1~exp1 as present in experimental The files * /usr/lib/ocaml/stdlib/META * /usr/lib/ocaml/str/META * /usr/lib/ocaml/unix/META are contained in the packages * libfindlib-ocaml * 1.8.1-2 as present in bullseye * 1.9.6-1+b1 as present in bookworm * 1.9.6-1+b2 as present in trixie|unstable * libstdlib-ocaml/5.2.0-1~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 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#1073169: debootstrap: support working on a nodev filesystem (e.g. /tmp)
Package: debootstrap Version: 1.0.134 Tags: patch X-Debbugs-Cc: jo...@debian.org Control: affects -1 + src:genext2fs Hi, I tried running the genext2fs autopkgtest for the /usr-move bootstrap upload and it failed rather early here while running debootstrap: Cannot install into target '/tmp/...' mounted with noexec or nodev I thought Johannes fixed debootstrap to work without mknod via https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/109, so why would it fail on nodev? When you're root and on a nodev filesystem, mknod still works. What does not work is writing to that device. Hence, the bind mounting code does not come into effect here. That also leads us to a relatively obvious solution: We can simply try writing to the created devices and perform the bind mount dance if it does not. I've prepared a patch for this. Helmut diff --minimal -Nru debootstrap-1.0.134/debian/changelog debootstrap-1.0.134+nmu1/debian/changelog --- debootstrap-1.0.134/debian/changelog2024-01-05 10:17:39.0 +0100 +++ debootstrap-1.0.134+nmu1/debian/changelog 2024-06-13 22:30:06.0 +0200 @@ -1,3 +1,10 @@ +debootstrap (1.0.134+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Support working with a nodev filesystem. (Closes: #-1) + + -- Helmut Grohne Thu, 13 Jun 2024 22:30:06 +0200 + debootstrap (1.0.134) unstable; urgency=medium [ Johannes Schauer Marin Rodrigues ] diff --minimal -Nru debootstrap-1.0.134/functions debootstrap-1.0.134+nmu1/functions --- debootstrap-1.0.134/functions 2024-01-05 10:07:32.0 +0100 +++ debootstrap-1.0.134+nmu1/functions 2024-06-13 14:18:14.0 +0200 @@ -1306,7 +1306,8 @@ touch "$TARGET/dev/console" ;; *) - if ! setup_devices_simple; then + if ! setup_devices_simple || + ! sh -c ': >"$1"' -- "$TARGET/dev/null" 2>/dev/null; then setup_devices_bind fi ;; @@ -1836,13 +1837,10 @@ lxc|lxc-libvirt|mmdebstrap-unshare) ;; *) - if mknod "$1/test-dev-null" c 1 3 2>/dev/null; then - if ! echo test > "$1/test-dev-null"; then - rm -f "$1/test-dev-null" - return 1 - fi - else - # mknod failed. Try if bind-mounting works + if ! mknod "$1/test-dev-null" c 1 3 2>/dev/null || + ! echo test > "$1/test-dev-null"; then + # mknod failed (e.g. user namespace) or writing failed + # (e.g. nodev). Try if bind-mounting works touch "$1/test-dev-null" if ! mount -o bind /dev/null "$1/test-dev-null"; then rm -f "$1/test-dev-null"
Bug#1073059: slapd: move systemd drop-in to /usr (DEP17)
Package: slapd Version: 2.5.17+dfsg-1 Severity: important Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi, we want to move all aliased files to /usr to complete the /usr-move transition (DEP17) and thus eliminate problems arising from aliasing. slapd is involved, because it install a systemd drop-in below /lib. In this case, I recommend simply moving this file to /usr statically. While backporting this change technically violates the file move moratorium in bookworm, doing so is likely harmless, because systemd consider units below /usr and there are even though dh_installsystemd does not look below /usr in bookworm, it also does not generate any maintainer scripts for drop-ins that could go missing, so I think this change is actually safe for bookworm-backports. Helmut diff -Nru openldap-2.5.17+dfsg/debian/changelog openldap-2.5.17+dfsg/debian/changelog --- openldap-2.5.17+dfsg/debian/changelog 2024-04-27 01:09:29.0 +0200 +++ openldap-2.5.17+dfsg/debian/changelog 2024-06-12 15:08:05.0 +0200 @@ -1,3 +1,10 @@ +openldap (2.5.17+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move systemd drop-in to /usr (DEP17). (Closes: #-1) + + -- Helmut Grohne Wed, 12 Jun 2024 15:08:05 +0200 + openldap (2.5.17+dfsg-1) unstable; urgency=medium * New upstream release. diff -Nru openldap-2.5.17+dfsg/debian/slapd.install openldap-2.5.17+dfsg/debian/slapd.install --- openldap-2.5.17+dfsg/debian/slapd.install 2024-04-27 01:09:29.0 +0200 +++ openldap-2.5.17+dfsg/debian/slapd.install 2024-06-12 15:07:59.0 +0200 @@ -3,7 +3,7 @@ usr/lib/*/libslapi-*.so.* debian/ldiftopasswd usr/share/slapd debian/slapd.init.ldif usr/share/slapd -debian/slapd-remain-after-exit.conf lib/systemd/system/slapd.service.d +debian/slapd-remain-after-exit.conf usr/lib/systemd/system/slapd.service.d usr/lib/ldap/back_*.so* usr/lib/ldap/back_*.la
Bug#1060229: fuse,fuse3,ntfs-3g: migrate dpkg-statoverride for UsrMerge?
Control: reassign -1 fuse,ntfs-3g Control: clone -1 -2 Control: reassign -2 src:fuse3 Control: tags -2 + patch Hi Laszlo, On Sun, Jan 07, 2024 at 10:52:52PM +0100, Chris Hofstaedtler wrote: > fuse, fuse3, and ntfs-3g use dpkg-statoverride on aliased paths in > /bin: /bin/fusermount, /bin/fusermount3. > > They do so in their postinst scripts, only checking if a > statoverride exists. If not, they run chmod on some programs. > The postinst does not add a statoverride. > > As you know, these paths need to become canonicalized to /usr/{...}. > When this happens, the old dpkg-statoverride entries stop working. > > Now my question: do you think it is worth migrating any such > dpkg-statoverride automatically? > > If not, how should users/admins who previously created an override > be informed about this problem? Some suggestions might be: > - NEWS.Debian entry > - trixie Release Notes I believe that it is not useful to migrate statoverrides, because in many cases they will be issued by automated tools such as puppet or ansible and one needs to migrate them there. Rather, I propose to temporarily honour both statoverrides in postinst (though dpkg will only honour the matching ones) and add a NEWS entry. We'll also be adding generic release notes asking administrators to review their statoverrides. Patch attached. > I've started working on UsrMerge patches for fuse and fuse3. Those > patches would need to take into account the question above, and also > the file loss problem between fuse and fuse3. File loss problem also handled in the attached by adding the safe diversion+conflicts combo. Helmut diff -Nru fuse3-3.14.0/debian/NEWS fuse3-3.14.0/debian/NEWS --- fuse3-3.14.0/debian/NEWS1970-01-01 01:00:00.0 +0100 +++ fuse3-3.14.0/debian/NEWS2024-06-12 13:37:25.0 +0200 @@ -0,0 +1,9 @@ +fuse3 (3.14.0-5.1) unstable; urgency=medium + + The fuse3 package honours a dpkg-statoverride of /bin/fusermount3 installed + by a system administrator (e.g. to remove the setuid binary installed by + default). The path to this file according to the package manager is + transitioned to /usr/bin/fusermount3. If you installed a statoverride, + please move it to the new path and verify the permissions. + + -- Helmut Grohne Wed, 12 Jun 2024 13:41:27 +0200 diff -Nru fuse3-3.14.0/debian/changelog fuse3-3.14.0/debian/changelog --- fuse3-3.14.0/debian/changelog 2024-01-12 16:46:21.0 +0100 +++ fuse3-3.14.0/debian/changelog 2024-06-12 13:37:25.0 +0200 @@ -1,3 +1,10 @@ +fuse3 (3.14.0-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move aliased files to /usr (DEP17). (Closes: #-1) + + -- Helmut Grohne Wed, 12 Jun 2024 13:37:25 +0200 + fuse3 (3.14.0-5) unstable; urgency=medium * Fix 99-fuse3.rules path (closes: #1060067). diff -Nru fuse3-3.14.0/debian/control fuse3-3.14.0/debian/control --- fuse3-3.14.0/debian/control 2024-01-12 01:21:04.0 +0100 +++ fuse3-3.14.0/debian/control 2024-06-12 13:37:25.0 +0200 @@ -25,7 +25,7 @@ sed (>= 4) Provides: fuse (= ${source:Version}) Breaks: fuse -Replaces: fuse +Conflicts: fuse Description: Filesystem in Userspace (3.x version) Filesystem in Userspace (FUSE) is a simple interface for userspace programs to export a virtual filesystem to the Linux kernel. It also aims to provide a diff -Nru fuse3-3.14.0/debian/fuse3-udeb.install fuse3-3.14.0/debian/fuse3-udeb.install --- fuse3-3.14.0/debian/fuse3-udeb.install 2018-07-21 16:11:44.0 +0200 +++ fuse3-3.14.0/debian/fuse3-udeb.install 2024-06-12 13:32:27.0 +0200 @@ -1,2 +1,2 @@ -usr/bin/fusermount3bin -usr/sbin/mount.fuse3 sbin +usr/bin/fusermount3 +usr/sbin/mount.fuse3 diff -Nru fuse3-3.14.0/debian/fuse3.install fuse3-3.14.0/debian/fuse3.install --- fuse3-3.14.0/debian/fuse3.install 2018-12-25 17:57:44.0 +0100 +++ fuse3-3.14.0/debian/fuse3.install 2024-06-12 13:32:16.0 +0200 @@ -1,3 +1,3 @@ -usr/bin/fusermount3bin -usr/sbin/mount.fuse3 sbin +usr/bin/fusermount3 +usr/sbin/mount.fuse3 etc/fuse.conf diff -Nru fuse3-3.14.0/debian/fuse3.links fuse3-3.14.0/debian/fuse3.links --- fuse3-3.14.0/debian/fuse3.links 2018-12-25 17:57:44.0 +0100 +++ fuse3-3.14.0/debian/fuse3.links 2024-06-12 13:37:25.0 +0200 @@ -1,4 +1,4 @@ -/bin/fusermount3 /bin/fusermount -/sbin/mount.fuse3 /sbin/mount.fuse +/usr/bin/fusermount3 /usr/bin/fusermount +/usr/sbin/mount.fuse3 /usr/sbin/mount.fuse /usr/share/man/man1/fusermount3.1.gz /usr/share/man/man1/fusermount.1.gz /usr/share/man/man8/mount.fuse3.8.gz /usr/share/man/man8/mount.fuse.8.gz diff -Nru fuse3-3.14.0/debian/fuse3.postinst fuse3-3.14.0/debian/fuse3.postinst --- fuse3-3.14.0/debian/fuse3.postinst 2021-06-20 15:45:33.0 +0200 +++ fuse3-3.14.0/debian/fuse3.postinst 2024-06-12 13:37:25.0 +0200 @@ -12,11 +12,21 @@ return
Bug#1064299: console-setup: move files to /usr (DEP17)
On Mon, Feb 19, 2024 at 08:13:29PM +0100, Helmut Grohne wrote: > We want to finalize the /usr-merge transition by moving all aliased > files from / to /usr via DEP17 to avoid negative effects arising from > aliasing. console-setup is involved, because it ships quite a few > aliased files. I'm sending a patch, because it cannot be automatically > converted using dh-sequence-movetousr. I note that the Debian installer > is producing a merged-/usr filesystem since a few months. Also take note > that this patch must not be uploaded to bookworm-backports or earlier as > it would violate the file move moratorium there. I've uploaded a slightly rebased version of the patch to DELAYED/10. Let me know if I should delay any longer. Helmut diff -Nru console-setup-1.227/CHANGES console-setup-1.228/CHANGES --- console-setup-1.227/CHANGES 2024-05-30 10:54:36.0 +0200 +++ console-setup-1.228/CHANGES 2024-02-18 13:51:52.0 +0100 @@ -1,3 +1,10 @@ +console-setup (1.228) unstable; urgency=medium + + * Non-maintainer upload. + * DEP17: Move aliased files to /usr. (Closes: #1064299) + + -- Helmut Grohne Sun, 18 Feb 2024 13:51:52 +0100 + console-setup (1.227) unstable; urgency=medium * Team upload diff -Nru console-setup-1.227/debian/changelog console-setup-1.228/debian/changelog --- console-setup-1.227/debian/changelog2024-05-30 10:54:36.0 +0200 +++ console-setup-1.228/debian/changelog2024-02-18 13:51:52.0 +0100 @@ -1,3 +1,10 @@ +console-setup (1.228) unstable; urgency=medium + + * Non-maintainer upload. + * DEP17: Move aliased files to /usr. (Closes: #1064299) + + -- Helmut Grohne Sun, 18 Feb 2024 13:51:52 +0100 + console-setup (1.227) unstable; urgency=medium * Team upload diff -Nru console-setup-1.227/debian/console-setup-udeb.postinst console-setup-1.228/debian/console-setup-udeb.postinst --- console-setup-1.227/debian/console-setup-udeb.postinst 2018-10-29 22:12:09.0 +0100 +++ console-setup-1.228/debian/console-setup-udeb.postinst 2024-02-18 13:51:52.0 +0100 @@ -80,7 +80,7 @@ fi if \ -[ -d /lib/debian-installer.d ] && keyboard_present +[ -d /usr/lib/debian-installer.d ] && keyboard_present then if [ "$DISPLAY" ] && which setxkbmap >/dev/null; then setxkbmap -option '' -model "$model" "$layout" "$variant" "$options" @@ -96,7 +96,7 @@ fi fi -if ! [ -d /lib/debian-installer.d ]; then +if ! [ -d /usr/lib/debian-installer.d ]; then dpkg-maintscript-helper rm_conffile \ /etc/init.d/keyboard-setup 1.138~ -- "$@" dpkg-maintscript-helper rm_conffile \ diff -Nru console-setup-1.227/debian/console-setup.postrm console-setup-1.228/debian/console-setup.postrm --- console-setup-1.227/debian/console-setup.postrm 2018-10-29 22:12:09.0 +0100 +++ console-setup-1.228/debian/console-setup.postrm 2024-02-18 13:51:52.0 +0100 @@ -7,7 +7,7 @@ fi if [ remove = "$1" -o purge = "$1" ]; then -if [ ! -f /bin/setupcon ]; then +if [ ! -f /usr/bin/setupcon ]; then rm -f /etc/console-setup/cached_* fi fi diff -Nru console-setup-1.227/debian/keyboard-configuration.postinst console-setup-1.228/debian/keyboard-configuration.postinst --- console-setup-1.227/debian/keyboard-configuration.postinst 2018-10-29 22:12:09.0 +0100 +++ console-setup-1.228/debian/keyboard-configuration.postinst 2024-02-18 13:51:52.0 +0100 @@ -80,7 +80,7 @@ fi if \ -[ -d /lib/debian-installer.d ] && keyboard_present +[ -d /usr/lib/debian-installer.d ] && keyboard_present then if [ "$DISPLAY" ] && which setxkbmap >/dev/null; then setxkbmap -option '' -model "$model" "$layout" "$variant" "$options" @@ -96,7 +96,7 @@ fi fi -if ! [ -d /lib/debian-installer.d ]; then +if ! [ -d /usr/lib/debian-installer.d ]; then dpkg-maintscript-helper rm_conffile \ /etc/init.d/keyboard-setup 1.138~ -- "$@" dpkg-maintscript-helper rm_conffile \ diff -Nru console-setup-1.227/debian/rules console-setup-1.228/debian/rules --- console-setup-1.227/debian/rules2024-05-28 18:28:45.0 +0200 +++ console-setup-1.228/debian/rules2024-02-18 13:51:52.0 +0100 @@ -112,11 +112,11 @@ $(MAKE) etcdir=debian/console-setup-linux/etc \ prefix=debian/console-setup-linux/usr install-common-linux dh_install -p console-setup-linux \ - init/90-console-setup.rules lib/udev/rules.d/ + init/90-console-setup.rules usr/lib/udev/rules.d/ dh_install -p console-setup-linux \ - init/keyboard-setup.sh lib/console-setup/ + init/keyboard-setup.sh usr/lib/console-set
Bug#1073057: nghttp2-proxy: move systemd unit to /usr (DEP17)
Package: nghttp2-proxy Version: 1.62.1-1 Severity: important Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi, src:nghttp2 contains a single aliased file, nghttpx.service, in a single binary package, nghttp2-proxy. This file should be moved to /usr to eliminate aliasing-caused bugs from Debian (DEP17). In this case, I propose using dh_installsystemd as it is fully backports-compatible and simplifies the packaging. I'm attaching a patch for your convenience. Helmut diff -Nru nghttp2-1.62.1/debian/changelog nghttp2-1.62.1/debian/changelog --- nghttp2-1.62.1/debian/changelog 2024-05-18 09:28:10.0 +0200 +++ nghttp2-1.62.1/debian/changelog 2024-06-12 14:06:19.0 +0200 @@ -1,3 +1,10 @@ +nghttp2 (1.62.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install systemd unit using dh_installsystemd. (Closes: #-1) + + -- Helmut Grohne Wed, 12 Jun 2024 14:06:19 +0200 + nghttp2 (1.62.1-1) unstable; urgency=medium * New upstream version 1.62.1 diff -Nru nghttp2-1.62.1/debian/nghttp2-proxy.nghttpx.service nghttp2-1.62.1/debian/nghttp2-proxy.nghttpx.service --- nghttp2-1.62.1/debian/nghttp2-proxy.nghttpx.service 1970-01-01 01:00:00.0 +0100 +++ nghttp2-1.62.1/debian/nghttp2-proxy.nghttpx.service 2024-05-18 09:28:10.0 +0200 @@ -0,0 +1,17 @@ +[Unit] +Description=HTTP/2 proxy +Documentation=man:nghttpx +After=network.target + +[Service] +Type=notify +ExecStart=/usr/sbin/nghttpx --conf=/etc/nghttpx/nghttpx.conf +ExecReload=/bin/kill --signal HUP $MAINPID +KillSignal=SIGQUIT +PrivateTmp=yes +ProtectHome=yes +ProtectSystem=full +Restart=always + +[Install] +WantedBy=multi-user.target diff -Nru nghttp2-1.62.1/debian/nghttpx.service nghttp2-1.62.1/debian/nghttpx.service --- nghttp2-1.62.1/debian/nghttpx.service 2024-05-18 09:28:10.0 +0200 +++ nghttp2-1.62.1/debian/nghttpx.service 1970-01-01 01:00:00.0 +0100 @@ -1,17 +0,0 @@ -[Unit] -Description=HTTP/2 proxy -Documentation=man:nghttpx -After=network.target - -[Service] -Type=notify -ExecStart=/usr/sbin/nghttpx --conf=/etc/nghttpx/nghttpx.conf -ExecReload=/bin/kill --signal HUP $MAINPID -KillSignal=SIGQUIT -PrivateTmp=yes -ProtectHome=yes -ProtectSystem=full -Restart=always - -[Install] -WantedBy=multi-user.target diff -Nru nghttp2-1.62.1/debian/rules nghttp2-1.62.1/debian/rules --- nghttp2-1.62.1/debian/rules 2024-05-18 09:28:10.0 +0200 +++ nghttp2-1.62.1/debian/rules 2024-06-12 14:06:00.0 +0200 @@ -55,10 +55,8 @@ # Currently we install our own systemd unit because # the original one is slightly broken -SYSTEMD="debian/nghttp2-proxy/lib/systemd/system" custom_install_systemd: - install -d $(SYSTEMD) - install -p -m644 debian/nghttpx.service $(SYSTEMD)/nghttpx.service + dh_installsystemd -pnghttp2-proxy --name nghttpx %: dh $@
Bug#1073056: stardict: stop using pcre3
Source: stardict Severity: serious Tags: trixie sid Hi, we want to get rid of pcre3 in trixie. As such startdict's libpcre3-dev dependency will become unsatisfiable. Ironically, the replacement is pcre2. Helmut
Bug#1073055: gnome-builder: stop using pcre3
Source: gnome-builder Severity: serious Tags: trixie sid Hi, we're in the process of removing pcre3 from Debian and it shall not be part of trixie. Hence gnome-builder should stop depending on it. Ironically, the new version is pcre2. Helmut
Bug#1073030: kglobalacceld has an undeclared file conflict on /usr/lib/systemd/user/plasma-kglobalaccel.service
Package: kglobalacceld Version: 6.0.90-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libkf5globalaccel-bin kglobalacceld has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/systemd/user/plasma-kglobalaccel.service is contained in the packages * kglobalacceld/6.0.90-1 as present in experimental * libkf5globalaccel-bin * 5.103.0-1 as present in bookworm * 5.115.0-2 as present in trixie|unstable * 5.78.0-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#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
On Tue, Jun 11, 2024 at 03:31:04PM +0100, Simon McVittie wrote: > I don't think that is true. The (single!) change in usrmerge v38 was that > it no longer implements the undocumented opt-out mechanism involving > /etc/unsupported-skip-usrmerge-conversion, therefore any system with > usrmerge (>= 38~) or usr-is-merged (>= 38~) is always going to be > /usr-merged. How could I have missed this! Sorry. > Would the suggested versioned dependency on base-files offer the same? Yes. base-files (>= 13.3~) will directly ship the aliasing links in its data.tar and its preinst will fail if any of these links actually is a real directory (rather than being a symlink or absent both of which mean that after unpack there'll be a symlink). I looked for other cases where there would be a versioned dependency on usr-is-merged and to my surprise dbus was literally the only one. So given that we do not want to duplicate the conflicts into base-files and that dbus actually is the only package wanting to express this, I am now convinced that the originally proposed solution of adding the base-files alternative actually is a good solution for the problem at hand. Helmut
Bug#1073001: buildbot FTBFS: python3-sqlalchemy (<< 1.5) no longer satisfiable
Source: buildbot Version: 3.10.1-2 Severity: serious Tags: ftbfs trixie sid buildbot can no longer be built in unstable as the python3-sqlalchemy package is too new to satisfy buildbot's build dependencies. It likely needs an upload that establishes compatibility with newer sqlalchemy. Helmut
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
Hi Jonas, On Fri, Jun 07, 2024 at 05:00:44PM +0200, Jonas Smedegaard wrote: > dbus depends versioned on usr-is-merged, which is now a transitional > package depending on base-files. > > Please change the dependency to be declared like this: > > Depends: base-files (>= 13.3~) | usr-is-merged (>= 38~) > > That allows dropping the transitional package. I think this request is not reasonable as is. Let's find out what we really want here. The semantics of base-files (>= 13.3~) and usr-is-merged (>= 38~) actually differ and your proposed change weakens the promises. In particular, usr-is-merged declares Conflicts for a fair number of packages to ensure that certain bugs are not present. base-files does not carry these conflicts, so by adding the alternative you are implying that these conflicts would be no longer needed. Then when you do not need the Conflicts, you might as well change the dependency to unversioned usr-is-merged as the only important features (from a client package pov) that usr-is-merged gained with higher versions are those Conflicts. Once you weaken it to the unversioned usr-is-merged, the provides from base-files actually suffices. It does seem reasonable that someone added the version restriction by accident. For dbus, it was added via #1054650, but the bug log does not express why the version restriction was needed. It would also be conceivable to have base-files do versioned provides of usr-is-merged. I considered this and concluded that it was a bad idea, because base-files would have to also carry all those Conflicts then. We want base-files to be upgraded early and those Conflicts would cause it to get upgraded late even though they are only really needed in some cases such as dbus. Hence I intentionally opted for not copying the Conflicts and thus not doing versioned provides. Given the above, it feels right to me that dbus pulls the physical usr-is-merged package whose purpose at this time is forcing other packages off the system. In the event that the Conflicts are not important to dbus, the obvious solution is to drop the version. In this case, waiting for base-files to migrate is not required. In no case is adding a base-files alternative a good thing to do. Helmut
Bug#1064126: libvirt: install NSS modules into /usr
On Sun, Jun 09, 2024 at 05:13:17PM +0200, Andrea Bolognani wrote: > We've been discussing things in fairly vague terms until now, > especially when it comes to timing. Can we get more concrete? How > long do you think I could reasonably spend trying to make the > restructuring happen before it becomes, well, too long, and the > /usr-move just *has* to happen, regardless of progress on that front? The hard deadline from my point of view is the start of the transition freeze. Until then, we'll increasingly poke and if you get too close, you risk using an inferior solution due to time pressure. I imagine that if you get late, you may have to revert part of the restructuring. Traditionally freeze happens on January 12th. So we'll be poking quite hard in December already. Let us avoid such poking for libvirt. Helmut
Bug#1064126: libvirt: install NSS modules into /usr
On Sun, Jun 09, 2024 at 12:37:47PM +0200, Andrea Bolognani wrote: > > So yes, I also recommend moving stuff to /usr as soon as possible and in > > particular without the restructuring changes (as that allows us to > > analyze the move already). > > I'm sorry, but this still doesn't make a whole lot of sense to me. > > If I performed the move today and got a thumbs-up from dumat, that > would only tell me that the change *on its own* is fine. But we also > know for a fact that restructuring the package might introduce file > loss scenarios, so what use is that really? It just provides a false > sense of security. I might agree here. Most of the analysis that dumat does already simulates moves, so uploading your restructuring changes to experimental shows us most of the issues I guess. Roughly speaking the approach we suggest is that you move your files now. Then when you restructure, you upload to experimental and give us time to analyze. Then the analyzer sees precisely how the restructuring changes affect the upgrade (trixie is assumed /usr-moved and experimental /usr-moved and restructured). What the analyzer does not see as well is interaction with other packages until you actually move files as the simulation approach is not entirely complete. Likely, it also works your way, but the later you do it, the less we can promise to fix the fallout in the remaining time. Quite obviously we prefer to be done sooner rather than later and you prefer having more time. It is a balance to strike here. > The time and energy I can dedicate to Debian work is unfortunately > limited. I've been focusing all of it to restructuring the package, > and I've made fairly solid progress so far. It will take a while > longer before it reaches a state where other people can look at it > though. If you anticipate taking more time, a reasonable option can be deferring the restructuring until after trixie when the /usr-move no longer poses issues to your restructuring. Let me point out though that we'll eventually file bugs for all aliased files and will raise them to rc severity and will take care of removing or NMUing packages to ensure that trixie is fully moved. I hope that we can agree that we don't want to release trixie without libvirt. Helmut
Bug#1072732: update-shells: duplicates entries when a package includes both aliased and canonical shells
Control: severity -1 serious Control: affects -1 + mmdebstrap On Fri, Jun 07, 2024 at 10:09:04AM +0200, Helmut Grohne wrote: > My recent bash upload changes it's shells.d snippet to include both > aliased and canonical shells, which is right in principle, but it causes > update-shells to duplicate /usr/bin/bash in /etc/shells. While that's > not breaking anything yet, it's also not nice and kudos to Johannes for > spotting it. > > It also is easy to fix with the attached patch. Would you kindly apply > it? I fear this aspect currently breaks mmdebstrap's autopkgtests, so this is an rc bug somewhere. While it isn't technically rc for debianutils, I hope that the simplest way forward is to just upload debianutils. If you disagree with this assessment, we'll have to adapt mmdebstrap's autopkgtests until this bug is fixed, which also works, but is kinda meh. So I am tentatively raising it to rc severity for debianutils hoping that you agree and let you downgrade in case you disagree. Thanks for considering. I'm also happy to NMU debianutils if you're short on time and agree with me doing it. Helmut
Bug#1072752: libcomedi0t64: contains soname-independent library support files
Package: libcomedi0t64,libcomedi0 Severity: serious Justification: policy 8.2 Debian policy 8.2 requires that library support files installed into the shared library package must be soname-dependent in order to allow coinstallation of multiple sonames. The file /lib/udev/rules.d/90-comedi.rules is considered to be such a support file and its name does not look like it'd automatically change with a new soname. There are two main ways to deal with this requirement. One is renaming the file and including its soname somewhere. Consider though that you may have two conflicting comedi udev rules installed concurrently then. The other is adding a -common package containing this file and having the shared library depend on the -common package. The -common package should not be soname-dependent. In this case, the old library needs to be able to work with comedi udev rules from a newer version (which seems at least plausible). Helmut
Bug#1072733: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/sherlock/__init__.py
Package: sherlock Version: 0.14.4+git20240531.e5ad3c4-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + python3-sherlock sherlock has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/python3/dist-packages/sherlock/__init__.py is contained in the packages * python3-sherlock/0.4.1-2 as present in trixie|unstable * sherlock/0.14.4+git20240531.e5ad3c4-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#1072732: update-shells: duplicates entries when a package includes both aliased and canonical shells
Package: debianutils Version: 5.17 Tags: patch X-Debbugs-Cc: jo...@debian.org User: helm...@debian.org Usertags: dep17 Hi, a longer while ago I added update-shells to debianutils as a way of managing /etc/shells using dpkg triggers. It took us a while to get the interactions with /usr-merge right and it seems we're not done yet. My recent bash upload changes it's shells.d snippet to include both aliased and canonical shells, which is right in principle, but it causes update-shells to duplicate /usr/bin/bash in /etc/shells. While that's not breaking anything yet, it's also not nice and kudos to Johannes for spotting it. It also is easy to fix with the attached patch. Would you kindly apply it? Helmut diff --minimal -Nru debianutils-5.17/debian/changelog debianutils-5.17+nmu1/debian/changelog --- debianutils-5.17/debian/changelog 2024-03-01 20:08:45.0 +0100 +++ debianutils-5.17+nmu1/debian/changelog 2024-06-07 09:50:16.0 +0200 @@ -1,3 +1,11 @@ +debianutils (5.17+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * update-shells: Avoid duplicate lines when package shells contain both +aliased and canonical shells. (Closes: #-1) + + -- Helmut Grohne Fri, 07 Jun 2024 09:50:16 +0200 + debianutils (5.17) unstable; urgency=medium [ Patrick Brünn ] diff --minimal -Nru debianutils-5.17/update-shells debianutils-5.17+nmu1/update-shells --- debianutils-5.17/update-shells 2024-02-28 21:00:25.0 +0100 +++ debianutils-5.17+nmu1/update-shells 2024-06-07 09:48:53.0 +0200 @@ -79,10 +79,12 @@ test -f "$f" || continue while IFS='#' read -r line _; do [ -n "$line" ] || continue - PKG_SHELLS="$PKG_SHELLS$line#" + if ! hashset_contains "$PKG_SHELLS" "$line"; then + PKG_SHELLS="$PKG_SHELLS$line#" + fi realshell=$(dpkg-realpath --root "$ROOT" "$(dirname "$line")")/$(basename "$line") - if [ "$line" != "$realshell" ]; then - PKG_SHELLS="$PKG_SHELLS$realshell#" + if ! hashset_contains "$PKG_SHELLS" "$realshell"; then + PKG_SHELLS="$PKG_SHELLS$realshell#" fi done < "$f" done
Bug#1072730: libfishcamp1t64: ineffective Replaces due to /usr-move (DEP17)
Package: libfishcamp1t64 Version: 1.2+20220607003151-2 Severity: serious Tags: patch User: helm...@debian.org Usertags: dep17p1 Control: clone -1 -2 Control: retitle -2 violates policy 8.2: soname-independent library support files Hi Thorsten, I am sorry to tell you that libfishcamp1t64 slipped through my review. It really is one of the packages that cannot be just moved. I'll review my analysis regarding this after sending this patch. libfishcamp combines three ingredients: * It installed aliased files in bookworm (firmware and udev rules) * It is affected by the time64 transition and thus renames packages. * It installs files that are not soname-dependent into the shared library package violating Debian policy section 8.2. I've cloned a separate bug about this problem. As a result, you are experiencing a DEP17 P1 problem. Roughly speaking, an upgrade could first unpack libfishcamp1t64 thereby installing the firmware and udev files into /usr. In doing so, dpkg overwrites the files from libfishcamp1 without attributing it to Replaces due to the difference in aliasing. Then, when libfishcamp1 is removed, it also removes firmware and udev files for real as they have not been replaced. Once the upgrade is complete, these files go missing. So this is indeed a case where dh-sequence-movetousr does not just work (and maybe it now becomes more clear why we didn't make dh-sequence-movetousr opt-out). There are multiple options to mitigate this with varying level of reliability. A reliable mitigation requires using protective diversions installed for the entire trixie release. This is fairly annoying and causes maintenance costs down the road (removing diversions, later removing diversion removing code). I propose using a less reliable method for this case. fishcamp seems to be a relatively unpopular package, so the number of affected users is expected to be small. When upgrading the Breaks to Conflicts (without having reverse Breaks), we are not aware of any scenario where this mitigation would be unreliable when using apt or aptitude (i.e. you need to install libfishcamp1t64 using dpkg directly in a specific setting to actually experience file loss). In any case, users can detect the loss using dpkg --verify and reinstalling libfishcamp1t64 will reinstate the lost files. Loss of these files would likely not render systems unbootable. Hence, I think this is a relatively low probability, relatively low impact and the more reliable mitigation has significantly higher maintenance cost. Do you agree with this risk assessment? If not, I can provide a more elaborate patch doing a more reliable mitigation. Another alternative to fixing this problem is reverting the t64 transition. I looked for the abi report, but there is none nor is there a bug report from the t64 people. Hence, I looked at the headers and found that none of them use off_t or time_t or other relevant types in structures or types. time_t is used internally, but not exposed. As a result, fishcamp very likely is unaffected by the time64 transition and its rename can be reverted. The revert briefly introduces the reverse DEP17 P1 problem into unstable, but for bookworm -> trixie upgrades, things would work then. If you opt for reverting, you don't have to use Conflicts and you can continue to use dh-sequence-movetousr. I note that the attached patch is not appropriate for bookworm-backports (but neither is the t64 rename). Helmut diff --minimal -Nru libfishcamp-1.2+20220607003151/debian/changelog libfishcamp-1.2+20220607003151/debian/changelog --- libfishcamp-1.2+20220607003151/debian/changelog 2024-06-03 23:30:36.0 +0200 +++ libfishcamp-1.2+20220607003151/debian/changelog 2024-06-07 10:14:24.0 +0200 @@ -1,3 +1,12 @@ +libfishcamp (1.2+20220607003151-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Mitigate /usr-move DEP17 P1 problems. (Closes: #-1) ++ Manually move files instead of using dh-sequence-movetousr. ++ Upgrade Breaks to Conflicts. + + -- Helmut Grohne Fri, 07 Jun 2024 10:14:24 +0200 + libfishcamp (1.2+20220607003151-2) unstable; urgency=medium * upload to unstable diff --minimal -Nru libfishcamp-1.2+20220607003151/debian/control libfishcamp-1.2+20220607003151/debian/control --- libfishcamp-1.2+20220607003151/debian/control 2024-06-03 23:30:36.0 +0200 +++ libfishcamp-1.2+20220607003151/debian/control 2024-06-07 10:14:24.0 +0200 @@ -8,7 +8,6 @@ , libusb-1.0-0-dev , zlib1g-dev , libindi-dev - , dh-sequence-movetousr Standards-Version: 4.7.0 Homepage: https://github.com/indilib/indi-3rdparty Rules-Requires-Root: no @@ -19,7 +18,7 @@ Package: libfishcamp1t64 Provides: ${t64:Provides} Replaces: libfishcamp1 -Breaks: libfishcamp1 (<< ${source:Version}) +Conflicts: libfishcamp1 (<< ${source:Version}) Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Descr
Bug#1072012: libxml-libxml-perl: new upstream release 2.0210, addressing test failures with libxml2 >= 2.11
Hi, I'm chiming in, because this FTBFS puts us in a difficult spot regarding /usr-move. The FTBFS makes bash bd-uninstallable and as long as bash is not built, debootstrap will fail for unstable. This only affects armel, ppc64el and s390x. On Mon, Jun 03, 2024 at 03:22:28PM +0800, Aron Xu wrote: > On Sat, Jun 1, 2024 at 2:26 AM gregor herrmann wrote: > > Also, please don't close _this_ bug in the upload; getting the > > dependency meta-information in order should fix the autopkgtest > > failures, but the core problem most probably will persist: The test > > failures on several architectures which makes the package FTBFS: > > https://buildd.debian.org/status/package.php?p=libxml-libxml-perl > > > > I have removed the Closes from changelog and uploaded libxml2 to > unstable. Let's see how it goes. Looks like your upload didn't fix things. Hence, I dug a little into it. I opted for reproducing on armel. As in all of the buildd failures, t/13dtd.t failed. After a failed build, one may issue: perl -Iblib/lib -Iblib/arch t/13dtd.t Unlike the test suite wrapper, this doesn't fork and thus is instrumentable. I also note that it does not fail reliably, but about 2/3 of the time (sampled 200 times). My gdb-fu wasn't exactly helping: #0 0xf7e66bd0 in free () from /lib/arm-linux-gnueabi/libc.so.6 #1 0xf7b9942c in xmlResetError () from /lib/arm-linux-gnueabi/libxml2.so.2 #2 0xf7b9990c in ?? () from /lib/arm-linux-gnueabi/libxml2.so.2 I also rarely saw SIGABRT instead of SIGSEGV combined with glibc complaining about the pointer passed to free(). With the knowledge that we are facing memory corruption, we may head back to amd64 where we have valgrind: $ valgrind perl -Iblib/lib -Iblib/arch t/13dtd.t ==1303314== Memcheck, a memory error detector ==1303314== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1303314== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==1303314== Command: perl -Iblib/lib -Iblib/arch t/13dtd.t ==1303314== 1..18 ok 1 - Loaded ok 2 - DTD String read ok 3 - XML::LibXML::Dtd successful. ok 4 - DTD String same as new string. ok 5 - ->parse_string ok 6 - ->parse_string 2 ok 7 - parse the article.xml file ok 8 - valid XML file ok 9 - Validates ok 10 - ->parse_string 3 ==1303314== Conditional jump or move depends on uninitialised value(s) ==1303314==at 0x6877FE1: __xmlRaiseError (error.c:492) ==1303314==by 0x68B8913: xmlErrValidNode (valid.c:152) ==1303314==by 0x68B8913: xmlValidateElementContent.constprop.0 (valid.c:5362) ==1303314==by 0x68BFF48: xmlValidateOneElement (valid.c:6057) ==1303314==by 0x68C0892: xmlValidateElement (valid.c:6288) ==1303314==by 0x68C0892: xmlValidateElement (valid.c:6275) ==1303314==by 0x68C0B19: xmlValidateDtd (valid.c:6546) ==1303314==by 0x67EC0A5: XS_XML__LibXML__Document_is_valid (LibXML.xs:4047) ==1303314==by 0x24828F: ??? (in /usr/bin/perl) ==1303314==by 0x23DDC5: Perl_runops_standard (in /usr/bin/perl) ==1303314==by 0x176E5D: perl_run (in /usr/bin/perl) ==1303314==by 0x14C531: main (in /usr/bin/perl) ==1303314== ==1303314== Conditional jump or move depends on uninitialised value(s) ==1303314==at 0x67FA8D9: XS_XML__LibXML__LibError_context_and_column (LibXML.xs:9284) ==1303314==by 0x24828F: ??? (in /usr/bin/perl) ==1303314==by 0x23DDC5: Perl_runops_standard (in /usr/bin/perl) ==1303314==by 0x16DF60: Perl_call_sv (in /usr/bin/perl) ==1303314==by 0x680BB02: LibXML_struct_error_callback (LibXML.xs:223) ==1303314==by 0x6878284: __xmlRaiseError (error.c:631) ==1303314==by 0x68B8913: xmlErrValidNode (valid.c:152) ==1303314==by 0x68B8913: xmlValidateElementContent.constprop.0 (valid.c:5362) ==1303314==by 0x68BFF48: xmlValidateOneElement (valid.c:6057) ==1303314==by 0x68C0892: xmlValidateElement (valid.c:6288) ==1303314==by 0x68C0892: xmlValidateElement (valid.c:6275) ==1303314==by 0x68C0B19: xmlValidateDtd (valid.c:6546) ==1303314==by 0x67EC0A5: XS_XML__LibXML__Document_is_valid (LibXML.xs:4047) ==1303314==by 0x24828F: ??? (in /usr/bin/perl) ==1303314== ok 11 - invalid XML ok 12 - ->validate throws an exception ok 13 - ->validation returns 1 ok 14 - Threw an exception ok 15 - Throw an exception 2 ok 16 - Two child nodes ok 17 - XML::LibXML::Dtd not defined. ok 18 - XML::LibXML::Dtd->new working correctly ==1303314== ==1303314== HEAP SUMMARY: ==1303314== in use at exit: 10,735,630 bytes in 38,953 blocks ==1303314== total heap usage: 117,760 allocs, 78,807 frees, 23,844,404 bytes allocated ==1303314== ==1303314== LEAK SUMMARY: ==1303314==definitely lost: 23,136 bytes in 33 blocks ==1303314==indirectly lost: 59,036 bytes in 34 blocks ==13033
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi Aurelien, Trimmed Cc list for glibc matters. On Wed, Jun 05, 2024 at 11:16:50PM +0200, Aurelien Jarno wrote: > Oops, I was convinced that #1071462 was filled with severity serious. > Nevermind. It migrated anyway. :) > Ok, a simultaneous experimental NMU sounds good. Ok, will do with a bit of delay. > Note however that people often downgrade glibc when they have suspicions > (like in the fakeroot case above), or even the hard way with dpkg once > their system is broken. Therefore we should at least test that case to > see how much breakage to expect, and also to easily spot patterns where > a system went through a glibc downgrade possibly followed by an upgrade. Thanks for the pointer. I tested a downgrade. It seems to work without loosing files, but two protective diversions remain in place. One is issued by libc6 against itself (such that it is immune to its own diversion) and the other is issued on behalf of base-files and properly owned by base-files after upgrading base-files. So the downgrade situation is not exactly the situation before the downgrade, but close enough, it works and after upgrading again it's all as it should be. I think this is fine. Doing final checks then uploading it all. Helmut
Bug#1072521: fakeroot hangs on some commands with faked-sysv using 100% CPU
Control: severity -1 important Hi, On Mon, Jun 03, 2024 at 04:31:39PM +0200, Pierre-Elliott Bécue wrote: > Assigning to fakeroot for now, but not sure it's not something for ftp.d.o (a > binNMU) or libc6. > > Today, after an upgrade, I am not able to build packages with sbuild as > it hanks with this process tree: I suggest that the cause may be something else and we are looking at some red herrings at least. In the mean time, the buildd network is reporting successful builds, Jochen Sprickerhof and I cannot readily reproduce the problem. I'm relatively certain that it doesn't affect everyone at this time and hence downgrading the report. > In parallel, one can find a faked-sysv process eating all a CPU resources. > > peb 225847 100 0.0 2440 648 pts/4R+ 16:25 0:02 \_ > /usr/bin/faked-sysv I think I have a plausible explanation for the CPU consumption. > strace: Process 230857 attached > close(200453) = -1 EBADF (Bad file descriptor) > close(200454) = -1 EBADF (Bad file descriptor) > close(200455) = -1 EBADF (Bad file descriptor) ... > close(200511) = -1 EBADF (Bad file descriptor) > ... and so on What we see here is a loop closing increasing file descriptors. I looked into fakeroot's source code and indeed there is such a loop that may correspond to this trace. https://sources.debian.org/src/fakeroot-ng/0.18-4.1/daemon.cpp/?hl=411#L414 | int fd_limit=getdtablesize(); | for( int i=0; i An hypothesis is that a rebuild against the current sid could solve the issue. > I will try that and report back. This no longer feels plausible to me. I have a few other ones: A. Your machine is relatively slow and closing 1e6 fds (for whatever reason) takes it very long time leaving the impression of hanging. B. Your file descriptor limit is even higher than 1e6 and in that case, the close loop really can take very long. C. You captured part of the close loop (with a higher than usual file descriptor limit), but it is not the cause of the hang. Rather it hangs for other reasons after having closed all those file descriptors. > Feel free to reassign. >From what I can tell, fakeroot would be better served with using close_range(2). That would lower the CPU consumption with a higher resource limit and make the real problem more apparent or disappear. Hope this helps, but I am fairly convinced now that this is not a glibc regression. Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi Aurelien, On Tue, Jun 04, 2024 at 06:58:00PM +0200, Aurelien Jarno wrote: > It would be really great if glibc can migrate before as it fixes an RC > bug. That said there are suspicions that it introduced bug #1072521, so > it might be worth investigating before it gets pushed into testing. > Unfortunately, on my side, I am unable to reproduce the issue. I looked and couldn't spot the RC bug you are referring to. The highest severity one I could spot is the systemd/debianutils/sbuild where telinit kills the build, but that isn't RC. Am I missing something? I also looked at #1072521 and am fairly certain that it is not a glibc regression. For sure, #1072521 is not trivially reproducible. In fact, I am not aware of anyone other than the submitter reproducing it. Beyond that, it is very likely that the submitter uses a non-default file descriptor soft limit (even though raising it does not reproduce the problem). In general, I agree with glibc migrating before doing the synced upload and that's also what Paul asked for. From my side the urgency here is risk management. Doing it later makes it harder for me to provide resources to fix fallout and I'm trying to find a good balance. Given that both util-linux and glibc need to migrate, deferring to Thursday (still leaves time until the Sunday cron) or even Monday looks most reasonable to me. > Please go ahead with a NMU. I wonder about experimental, do we want to > do the changes at the same time, or a bit after? Said otherwise is > moving files from /usr to /lib supported? I don't want to support such moves in any way. Hence, I think the best option would be to simultaneously NMU experimental. dash is affected in the same way. Admittedly, I'm not too worried about experimental upgrades failing. We have a number of packages that move files the wrong way in experimental and it doesn't seem to bother people (nor me). Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote: > Since noble includes these changes and I'd get this done sooner rather > than later, how about moving forward with June 5th after 22:30 UTC (such > that all buildds have regenerated their chroots before the upload)? I got vaguely positive feedback from Paul Gevers on this date. Hence, I plan to upload after the June 5th mirror push and allocate time for handling unexpected fallout. dash, base-files and bash are fully migrated at the time of this writing. glibc migrated -11 and -12 still has 5 autopkgtest regressions. util-linux migrated -6, -7 has a piuparts regression and -8 hopefully gets tested soon. I hope that both migrate before the planned upload and will consult with the release team on whether to bump back or go ahead. I have rebased and retested the patches in https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. Andrew, Aurelien, Chris, Matthias, Santiago: Any objections? You may send me signed uploads (.dsc + source chanages) and I will otherwise move ahead with regular NMUs. If you send signed changes, I recommend encrypting them using my gpg key. Helmut
Bug#1064126: libvirt: install NSS modules into /usr
Hi Andrea, I think Michael and Chris already said most of the relevant things, but Chris asked me to chime in. On Tue, Feb 27, 2024 at 10:53:12PM +0100, Andrea Bolognani wrote: > Note that "at the same time" can mean two things in this context: > > 1) when upgrading from bookworm to trixie; > 2) when upgrading testing/unstable. > > I'm sure that 1) can be handled correctly, but the prospect of > causing file loss for 2) by accident is not particularly appealing > and I'd like to avoid it if at all possible. Your worry is reasonable. However, deferring these changes is going to make it worse as we have less time to handle possible breakage. The way to avoid the 2) scenario is to upload to experimental (with upgrade problems), have dumat detect all the issues, fix them there and only then (once the analyzer is happy) move to unstable. > As I've explained we want to preserve backportability as much as > possible, which pretty much rules out the current patch. At the very > least we'd have to use dh_movetousr instead. I fear that you are between a rock and a hard place here. The time64 and /usr-move transitions very much are not backportable in a sane way. In particular, the existence of a P1 problem (as you suggest there will be) rules out dh_movetousr. It gets even worse though. If you backport, you're supposed to move units back to aliased paths (due to the file move moratorium still being in place for bookworm and due to bookworm's debhelper not adding maintainer scripts or moved units). So when you upgrade from bookworm-backports to trixie (in a distant future), you have a new upgrade path and the trixie package will need even more mitigations. Yes, this is suboptimal. > What I still fail to understand, and please bear with me because the > issue is most likely on my side, is how the fallout from a "bad" file > move would be dealt with. > > Suppose that I made the usr-merge upload today, and the package > restructure upload in a month. At that point, dumat would detect that > file loss could occur, report it and... What then? Ideally, your restructuring upload goes to experimental, so all of experimental users have broken systems then. When dumat reports an issue, I'll investigate the cause and propose a solution (patch) and file an rc bug. That tells you that you're not good to move to unstable as is and gives the two of us time to discuss solutions and the integration into the package. > Have reliable mitigations been developed for all possible file loss > scenarios? Is it guaranteed that such mitigations, when applied, > will protect from file loss not just the people running stable, but > also those running testing and unstable? No. We're enumerating badness here. We're limiting the damage that has already been done. We've looked at lots of problems and tried to identify as many as possible problems and specifically test for known problem categories. False negatives are possible and have happened indeed. But then, what we have makes it fairly unlikely for users to practically experience those problems. The goal definitely is to not have any file loss in bookworm -> trixie nor testing/unstable upgrade scenarios. The guarantee you are looking for does not exist, but we're making a good effort at it and I believe that we have a fairly good track record of actually supporting this transition when problems arise. For instance, the diversions in molly-guard turned out to be way more difficult to mitigate than originally anticipated and while it took quite a bit longer, we now have a working solution. Likewise, when piuparts or the debian-installer was broken, we sent patches rather than disappearing. I fear there is not much more that we can do here than promise supporting you in the event of fallout. > My instincts tell me that it would be much easier to reason about > this if the two transitions happened at the same time rather than > potentially months apart. This is my main concern with applying the > usr-merge changes when we still don't have a clear picture of what > the final state of the package will look like. Interestingly, my instinct (and that of Michael and Chris) tell exactly the opposite story. Many of the /usr-move issues are interaction problems between multiple packages. When we look for problems, we don't look for recent history, but use a static analyzer that precisely pin points where to look. The earlier we move stuff, the more capacity we have for keeping up the support promise. So yes, I also recommend moving stuff to /usr as soon as possible and in particular without the restructuring changes (as that allows us to analyze the move already). What I don't have is a good answer about backports. In the face of P1 problems, backports are difficult to get right. Indeed, doing a backport now and then saying "no more bookworm-backports after /usr-move and restructuring" can be a sensible thing, but you pay with less support from us in the event of fallout. I'm also hap
Bug#1072391: python3-specreduce has an undeclared file conflict
Package: python3-specreduce Version: 1.4.0-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + pipenv python3-google-auth-oauthlib python3-specreduce has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/python3/dist-packages/build/lib/docs/conf.py is contained in the packages * pipenv/2023.12.1+ds-1 as present in trixie|unstable * python3-specreduce/1.4.0-1 as present in unstable The file /usr/lib/python3/dist-packages/docs/conf.py is contained in the packages * python3-google-auth-oauthlib/1.2.0-1 as present in trixie|unstable * python3-specreduce/1.4.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. 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#1072214: python3-proto-plus declares Conflicts: nanopb in violation of Debian policy 10.1
Package: python3-proto-plus Version: 1.23.0-2 Severity: serious Justification: policy 10.1 python3-proto-plus declares a conflict with nanopb. Doing so violates Debian policy section 10.1. More background can be found in #1072073. Helmut
Bug#1072073: python3-proto-plus has an undeclared file conflict on /usr/lib/python3/dist-packages/proto/__init__.py
Control: reassign -1 python3-proto-plus,nanopb Control: affects -1 = On Wed, May 29, 2024 at 08:40:03PM -0400, Yogeswaran Umasankar wrote: > For now, I am planning to declare nanopb in Conflicts for > 'python3-proto-plus' binary. Let me know if it might not be advisable. Doing so violates Debian policy 10.1: Two different packages must not install programs with different functionality but with the same filenames. Arguably, this extends to Python modules. Generally speaking, packages should be coinstallable unless they fundamentally cannot and in this case renaming either is a reasonable solution. I recommend talking to the nanopb maintainer, because what their package does is unusual. The affected module name "proto" is part of the python3-proto package, but the nanopb package isn't even identifying a Python module. It would be plausible to make their module private and hence resolve the conflict. I very much expect a solution of this bug to require changes in nanopb of some form. So this bug likely involves more coordination than originally anticipated. Keep in mind that every mail to this bug resets the testing autoremover and the freeze is not exactly close. Helmut
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi release team, On Wed, Mar 13, 2024 at 10:55:09AM +0100, Helmut Grohne wrote: > I propose April 11th on the condition that all relevant packages > (including cryptsetup and e2fsprogs) have migrated. I'll also check with > Aurelien on feasibility after Easter. Stuff wasn't ready back then and we kept bumping the /usr-move back. I think we need to fix dates soon. During the past months, I reserved time for the essential fallout and I cannot promise that in second-half-June, July and first-half-August. Meanwhile all the relevant stuff has migrated including the glibc upstream release. So we basically have the following options: * Pick a date before June 7th and go ahead soon. * Go for later and I'll handle the fallout best-effort. (i.e. similar t64 fallout) * Pick a date August 12th or later. Since noble includes these changes and I'd get this done sooner rather than later, how about moving forward with June 5th after 22:30 UTC (such that all buildds have regenerated their chroots before the upload)? There also is little to be done from the release team's side beyond installing a block for base-files, bash, dash, glibc, util-linux and then lifting the block once all of them are ready turn that block into a force hint such that they really migrate together. (There is no dependency relation between them ensuring concurrent migration as that would make upgrades more difficult.) Other than the bootstrap matter, we're down to 350 affected packages and dumat is finding one to five issues per week most of which are undeclared file conflicts. As a result of the dumat work, I haven't seen an actual end user report about a /usr-move problem in quite a while. A list of affected packages is at https://subdivi.de/~helmut/usrmove.ddlist (not entirely current). I'll propose a MBF for the remaining no-change sourceful uploads as well as the remaining "Build-Depends: dh-sequence-movetousr" uploads. All other moves already have bugs. I also plan to bump the severity of these bugs to important soon. Do you also agree with bumping these bugs to serious severity once their number goes below 200? Keep in mind that they are all actionable in the sense that one of the following applies: * No-change sourceful upload fixes * An upload adding "Build-Depends: dh-sequence-movetousr" fixes * The attached patch fixes * Rarely maintainer feedback has been requested Chris has already performed a number of NMUs and we'll need to do some more to eventually get us down to 0 aliased packages. A while ago I removed 10 affected source packages that were FTBFSing for two stable releases already. Helmut
Bug#1072160: libmirage FTCBFS: fails running gtk-doc-scan
Source: libmirage Version: 3.2.7-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs libmirage fails to cross build from source, because it fails running the gtk-doc scanner. This is a common problem for cross builds. Fortunately, libmirage has its documentation split out to libmirage-doc, so there isn't actually any need to run the scanner in an arch-only build. Simply skipping it there makes the cross build succeed while not affecting the binary artifacts (according to diffoscope) and it also slightly speeds up the native arch-only build (e.g. on buildds). I'm attaching a patch for your convenience. Helmut diff --minimal -Nru libmirage-3.2.7/debian/changelog libmirage-3.2.7/debian/changelog --- libmirage-3.2.7/debian/changelog2024-05-25 12:55:24.0 +0200 +++ libmirage-3.2.7/debian/changelog2024-05-29 09:41:43.0 +0200 @@ -1,3 +1,10 @@ +libmirage (3.2.7-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Disable gtk-doc on arch-only build. (Closes: #-1) + + -- Helmut Grohne Wed, 29 May 2024 09:41:43 +0200 + libmirage (3.2.7-4) unstable; urgency=medium * debian/appstream/net.sf.cdemu.libmirage.metainfo.xml: diff --minimal -Nru libmirage-3.2.7/debian/rules libmirage-3.2.7/debian/rules --- libmirage-3.2.7/debian/rules2024-02-20 15:57:49.0 +0100 +++ libmirage-3.2.7/debian/rules2024-05-29 09:41:41.0 +0200 @@ -7,7 +7,9 @@ override_dh_auto_configure: - dh_auto_configure -- -DPOST_INSTALL_HOOKS:BOOL=OFF + dh_auto_configure -- \ + -DPOST_INSTALL_HOOKS:BOOL=OFF \ + -DGTKDOC_ENABLED=$(if $(filter libmirage-doc,$(shell dh_listpackages)),ON,OFF) override_dh_makeshlibs: dh_makeshlibs --exclude="libmirage-3.2"
Bug#1072159: rust-pango-sys FTBFS with nocheck build profile: cp: cannot stat '/usr/share/gir-1.0/Pango-1.0.gir': No such file or directory
Source: rust-pango-sys Version: 0.19.5-2 Severity: serious Tags: ftbfs trixie sid rust-pango-sys fails to build from source when enabling the nocheck build profile. A build ends with: |dh_auto_configure -O--buildsystem=cargo | debian cargo wrapper: options, profiles, parallel, lto: ['nocheck', 'parallel=8'] ['nocheck'] ['-j8'] 0 | debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, x86_64-linux-gnu | debian cargo wrapper: linking /usr/share/cargo/registry/* into /<>/debian/cargo_registry/ |debian/rules execute_before_dh_auto_build | make[1]: Entering directory '/<>' | cp /usr/share/gir-1.0/GLib-2.0.gir /<> | cp /usr/share/gir-1.0/GModule-2.0.gir /<> | cp /usr/share/gir-1.0/GObject-2.0.gir /<> | cp /usr/share/gir-1.0/Pango-1.0.gir /<> | cp: cannot stat '/usr/share/gir-1.0/Pango-1.0.gir': No such file or directory | make[1]: *** [debian/rules:12: 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 Please review the annotations in your package. Since trixie, a nocheck build failure is considered release-critical. Helmut
Bug#1072092: piuparts: switch default tmpdir to /var/tmp/
Control: reassign -1 debootstrap Control: affects -1 + piuparts debos vmdb2 On Tue, May 28, 2024 at 12:08:37PM +0100, Luca Boccassi wrote: > When piuparts runs debootstrap, it is pointed to the default --tmpdir, > which absent any configuration or env var is /tmp/, which is now (since > systemd 256~rc3-3) a tmpfs, which as it is expected it is mounted with > noudev for security reasons, but debootstrap doesn't like that as it > wants to create fresh node files. This is a problem in debootstrap. debootstrap should refrain from creating device nodes when doing so is not possible. Most consumers of debootstrap bind mount /dev already. Reassigning. > Please make piuparts --tmpdir default to /var/tmp if nothing is set, to > avoid this issue. Please don't as that would make reduce piuparts performance to crap. Helmut
Bug#1072102: samba-ad-dc: ineffective replaces due to /usr-move (DEP17)
Package: samba-ad-dc Version: 2:4.20.1+dfsg-3 Severity: serious Tags: patch User: helm...@debian.org Usertags: dep17p1 Control: affects -1 + samba Hi, /lib/systemd/system/samba-ad-dc.service is part of the samba package in the following versions: * 2:4.13.13+dfsg-1~deb11u5: bullseye * 2:4.13.13+dfsg-1~deb11u6: bullseye-security|bullseye-proposed-updates * 2:4.17.12+dfsg-0+deb12u1: bookworm|bookworm-security * 2:4.17.12+dfsg-0+deb12u1~bpo11+1: bullseye-backports * 2:4.17.9+dfsg-0+deb12u3: bookworm-updates * 2:4.19.6+dfsg-3~bpo12+1: bookworm-backports /usr/lib/systemd/system/samba-ad-dc.service is now part of samba-ad-dc. Since these actually refer to the same file via different paths (due to /usr-move), we produce a DEP17 P1 problem and the declared Replaces are ineffective leading to file loss in an upgrade scenario (what the file move moratorium meant to prevent). This needs to be mitigated and I am attaching the necessary patch. Helmut diff -Nru samba-4.20.1+dfsg/debian/changelog samba-4.20.1+dfsg/debian/changelog --- samba-4.20.1+dfsg/debian/changelog 2024-05-26 17:48:17.0 +0200 +++ samba-4.20.1+dfsg/debian/changelog 2024-05-28 13:37:34.0 +0200 @@ -1,3 +1,10 @@ +samba (2:4.20.1+dfsg-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Mitigate ineffective replaces due to /usr-move (DEP17 P1). (Closes: #-1) + + -- Helmut Grohne Tue, 28 May 2024 13:37:34 +0200 + samba (2:4.20.1+dfsg-3) unstable; urgency=medium * d/rules: move samba-common install to d/samba-common.install diff -Nru samba-4.20.1+dfsg/debian/control samba-4.20.1+dfsg/debian/control --- samba-4.20.1+dfsg/debian/control2024-05-26 14:33:25.0 +0200 +++ samba-4.20.1+dfsg/debian/control2024-05-28 12:36:04.0 +0200 @@ -203,8 +203,10 @@ Enhances: bind9, ntp Breaks: samba-ad-provision (<< ${source:Upstream-Version}), # files moved from samba & samba-common-bin in 4.20.1-2: - samba (<< 2:4.20.1+dfsg-2~), samba-common-bin (<< 2:4.20.1+dfsg-2~), -Replaces: samba (<< 2:4.20.1+dfsg-2~), samba-common-bin (<< 2:4.20.1+dfsg-2~), + samba-common-bin (<< 2:4.20.1+dfsg-2~), +Replaces: samba-common-bin (<< 2:4.20.1+dfsg-2~), +# Breaks+Replaces upgraded to Conflicts for DEP17 + /usr-move +Conflicts: samba (<< 2:4.20.1+dfsg-2~), Description: Samba control files to run AD Domain Controller Samba is an implementation of the SMB/CIFS protocol for Unix systems, providing support for cross-platform file and printer sharing with diff -Nru samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides --- samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides 1970-01-01 01:00:00.0 +0100 +++ samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides 2024-05-28 13:37:34.0 +0200 @@ -0,0 +1,3 @@ +# begin-remove-after: trixie +diversion-for-unknown-file lib/systemd/system/samba-ad-dc.service [preinst:*] +# end-remove-after diff -Nru samba-4.20.1+dfsg/debian/samba-ad-dc.postinst samba-4.20.1+dfsg/debian/samba-ad-dc.postinst --- samba-4.20.1+dfsg/debian/samba-ad-dc.postinst 1970-01-01 01:00:00.0 +0100 +++ samba-4.20.1+dfsg/debian/samba-ad-dc.postinst 2024-05-28 13:37:30.0 +0200 @@ -0,0 +1,15 @@ +#!/bin/sh + +# begin-remove-after: released:trixie +# protective diversion of files moved from / to /usr, to avoid file loss. +# Only for upgrades. +if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then + dpkg-divert --package #PACKAGE# --no-rename \ + --divert /lib/systemd/system/samba-ad-dc.service.usr-is-merged \ + --remove /lib/systemd/system/samba-ad-dc.service +fi +# end-remove-after + +#DEBHELPER# + +exit 0 diff -Nru samba-4.20.1+dfsg/debian/samba-ad-dc.preinst samba-4.20.1+dfsg/debian/samba-ad-dc.preinst --- samba-4.20.1+dfsg/debian/samba-ad-dc.preinst1970-01-01 01:00:00.0 +0100 +++ samba-4.20.1+dfsg/debian/samba-ad-dc.preinst2024-05-28 13:36:29.0 +0200 @@ -0,0 +1,15 @@ +#!/bin/sh + +# begin-remove-after: released:trixie +# protective diversion of files moved from / to /usr, to avoid file loss. +# Only for upgrades. +if [ "$1" = "upgrade" ] || [ "$1" = "install" ]; then + dpkg-divert --package #PACKAGE# --no-rename \ + --divert /lib/systemd/system/samba-ad-dc.service.usr-is-merged \ + --add /lib/systemd/system/samba-ad-dc.service +fi +# end-remove-after + +#DEBHELPER# + +exit 0
Bug#1072074: 7zip has an undeclared file conflict
Package: 7zip Version: 24.06+dfsg-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + p7zip p7zip-full 7zip has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/bin/7z * /usr/bin/7za are contained in the packages * 7zip/24.06+dfsg-1 as present in unstable * p7zip-full/16.02+dfsg-8 as present in bookworm|bullseye The files * /usr/bin/7zr * /usr/bin/p7zip are contained in the packages * 7zip/24.06+dfsg-1 as present in unstable * p7zip/16.02+dfsg-8 as present in bookworm|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 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#1072073: python3-proto-plus has an undeclared file conflict on /usr/lib/python3/dist-packages/proto/__init__.py
Package: python3-proto-plus Version: 1.23.0-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + nanopb python3-proto-plus has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/python3/dist-packages/proto/__init__.py is contained in the packages * nanopb * 0.4.4-2 as present in bullseye * 0.4.7-2 as present in bookworm * 0.4.8-1 as present in trixie|unstable * python3-proto-plus/1.23.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#1063571: libpcre3: move libraries to /usr (DEP17)
Control: clone -1 -2 Control: retitle -2 pcre3 should not be part of trixie Control: tags -2 trixie sid Control: severity -2 serious Control: block -1 by -2 On Sun, May 26, 2024 at 04:18:38PM +0100, Matthew Vernon wrote: > I really, truly, do not want to be shipping pcre3 in trixie. Cool. I've recorded this in the bts. > There are 33 unfixed packages[0], so I think this is reasonable (if nothing > else, I don't believe any of the remainder are showstoppers). The autoremover will establish the urgency of this matter to the non-key packages. Please NMU the others such that we're done before the transition freeze. Helmut
Bug#1071736: sbuild --chroot-mode=unshare fails when /etc/resolv.conf is a symlink /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Hi Johannes, On Sun, May 26, 2024 at 03:26:56PM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Helmut Grohne (2024-05-24 14:12:38) > > while working with debusine.debian.net, I ran into a rather crazier kind > > of issue with the unshare backend. It seems like debusine.debian.net > > creates a chroot.tar where resolv.conf is a symbolic link: > > > > | lrwxrwxrwx 0/0 0 2024-05-20 17:15 ./etc/resolv.conf -> > > ../run/systemd/resolve/stub-resolv.conf > > > > Notably, /run/systemd/resolve does not exist inside the tar nor does > > sbuild run systemd-resolved nor systemd-tmpfiles for creating this > > location. When building, the unshare backend tries to bind mount > > /etc/resolv.conf: > > > > | --: 13: cannot create /tmp/tmp.sbuild.OQ0pOU6LQg/etc/resolv.conf: > > Directory nonexistent > > https://debusine.debian.net/artifact/427489/hostname_3.23+nmu2_amd64-2024-05-24T10:06:30Z.build > > > > This fails, because mount attempts to dereference the symbolic link and > > finds that an intermediate directory does not exist. As a result, this > > fails and network generally does not work resulting in all sorts of > > badness. > > I'm not sure where you see bind-mounting /etc/resolv.conf being done in the > $network_setup code. If network is enabled, it reads: > > [ -f /etc/resolv.conf ] && cat /etc/resolv.conf > > "$rootdir/etc/resolv.conf" || echo "nameserver 127.0.0.53" > > "$rootdir/etc/resolv.conf"; Mea culpa. I hallucinated that bind mount, but the effect is the same. The shell redirection follows the symbolic link and figures that it cannot create "$rootdir/etc/resolv.conf". The "Directory nonexistent" error message really comes from the dash redirection: https://sources.debian.org/src/dash/0.5.12-8/src/error.c/?hl=225#L225 I think we should unlink /etc/resolv.conf (as it may be a dangling symbolic link) before creating it. Also note that if you were working with a malicious tar archive and /etc/resolv.conf were an absolute symbolic link, you'd be following it in the initial namespace possibly overwriting precious files. I would not classify this as a vulnerability as we expect the chroot tar to be "sane". > in unshare mode, we are always working with an ephemeral chroot. Would there > be > any downside to sbuild just first running "rm -f $rootdir/etc/resolv.conf" and > then re-creating it as a real file in the $network_setup snippet of > _get_exec_argv() in lib/Sbuild/ChrootUnshare.pm? Not at all. Once my bind mount hallucination goes away, that is the obvious solution. Helmut
Bug#1071736: sbuild --chroot-mode=unshare fails when /etc/resolv.conf is a symlink /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Package: sbuild Version: 0.85.8 Hi Johannes and Jochen, while working with debusine.debian.net, I ran into a rather crazier kind of issue with the unshare backend. It seems like debusine.debian.net creates a chroot.tar where resolv.conf is a symbolic link: | lrwxrwxrwx 0/0 0 2024-05-20 17:15 ./etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf Notably, /run/systemd/resolve does not exist inside the tar nor does sbuild run systemd-resolved nor systemd-tmpfiles for creating this location. When building, the unshare backend tries to bind mount /etc/resolv.conf: | --: 13: cannot create /tmp/tmp.sbuild.OQ0pOU6LQg/etc/resolv.conf: Directory nonexistent https://debusine.debian.net/artifact/427489/hostname_3.23+nmu2_amd64-2024-05-24T10:06:30Z.build This fails, because mount attempts to dereference the symbolic link and finds that an intermediate directory does not exist. As a result, this fails and network generally does not work resulting in all sorts of badness. Technically speaking, you can bind mount onto a symbolic link. You just cannot do so using the mount(2) API nor the mount(1) command. Unless you pass MOVE_MOUNT_T_SYMLINKS to move_mount(2), it will not dereference a symlink being pointed at. I'm not sure we want to go this extra mile though. On the debusine side, I think we want to work around this issue in some way to avoid imposing a high version constraint in sbuild. I am reporting it here as it kinda is a bug (up to your judgement) and it helps having the diagnosis written down. Helmut
Bug#1071735: libxmlrpc-util-dev and libxmlrpc-util4 have an undeclared file conflict
Package: libxmlrpc-util4,libxmlrpc-util-dev Version: 1.59.03-2+b1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libxmlrpc-core-c3-dev libxmlrpc-core-c3t64 libxmlrpc-util-dev and libxmlrpc-util4 have an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.a * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so are contained in the packages * libxmlrpc-core-c3-dev * 1.33.14-11 as present in bookworm * 1.33.14-9 as present in bullseye * libxmlrpc-util-dev/1.59.03-2+b1 as present in unstable The files * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.a * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so * /usr/lib/x86_64-linux-gnu/pkgconfig/xmlrpc_util.pc are contained in the packages * libxmlrpc-core-c3-dev/1.59.03-1+b1 as present in trixie * libxmlrpc-util-dev/1.59.03-2+b1 as present in unstable The files * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so.4 * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so.4.59 are contained in the packages * libxmlrpc-core-c3t64/1.59.03-1+b1 as present in trixie * libxmlrpc-util4/1.59.03-2+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 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#1071734: libsingular4m4n0 has an undeclared file conflict
Package: libsingular4m4n0 Version: 1:4.4.0+ds-3 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libsingular4m3n0t64 libsingular4m4n0 has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/x86_64-linux-gnu/libsingular-factory-4.4.0.so * /usr/lib/x86_64-linux-gnu/libsingular-omalloc-4.4.0+ds+0.9.6.so * /usr/lib/x86_64-linux-gnu/libsingular-polys-4.4.0.so * /usr/lib/x86_64-linux-gnu/libsingular-resources-4.4.0.so * /usr/lib/x86_64-linux-gnu/libsingular-Singular-4.4.0.so are contained in the packages * libsingular4m3n0t64/1:4.4.0+ds-1 as present in trixie|unstable * libsingular4m4n0/1:4.4.0+ds-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#1071581: dialog: stop using libtool-bin
Hi Thomas, On Wed, May 22, 2024 at 03:53:43AM -0400, Thomas Dickey wrote: > I don't use autoheader (though it's present in the fork I've maintained for > about the past quarter-century). The configure script generates the complete > dlg_config.h without that crutch. Attempting to bypass that will certainly > lead to unnecessary bug reports. I fear it occurred to me late that I should be using autoconf-dickey instead of the standard autoconf for dialog. Hence my patch makes it work the "wrong" autoconf and thus runs autoheader. I see how that would not be necessary with autoconf-dickey. > Actually it would be AC_FOREACH, which invokes AH_TEMPLATE > > fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999), > and there are other macros which might use those features. Yeah. And if you make dialog work with autoconf-dickey and without autoheader, then all of this becomes moot anyway. Feel free to come up with a different solution as long as we stop relying on /usr/bin/libtool as that's the component that will go away. We now have one working solution and I'm happy if that is sufficient to get the ball rolling for a better solution than mine. Helmut
Bug#1071581: dialog: stop using libtool-bin
Hi Thomas, On Tue, May 21, 2024 at 03:06:00PM -0400, Thomas Dickey wrote: > hmm - there are two sets of changes - I don't see a reason for the > change to the curses function checks. Thank you for reviewing my patch. The curses function check change does have a reason. It can be solved differently in principle. When I ran autoheader, config.hin would lack all the defines that should have come from CF_CURSES_FUNCS while the relevant HAVE_* defines would still show up in config.log after running configure and therefore the resulting dlg_config.h would also lack them. That meant that dialog would perceive a very dysfunctional curses and its shim would fail to compile. Quite clearly, we shouldn't assume a crippled curses and config.hin should contain the relevant templates. As it turns out, autoheader interprets the m4 files and collects the AC_DEFINE and AC_DEFINE_UNQUOTED invocations, well some of them actually. The AC_CHECK_FUNCS would be collected whereas CF_CURSES_FUNCS not, even though both seemed quite similar. The subtle difference is that AC_CHECK_FUNCS uses AS_FOR (a loop that is evaluated using m4) whereas CF_CURSES_FUNCS uses a shell for loop. Thus, autoheader would only see a single, bogus AC_DEFINE_UNQUOTED for all of CF_CURSES_FUNCS and ignore that. Avoiding this shell loop is key here and I went for manually unrolling it, because AS_FOR didn't work out initially and unrolling seemed workable to me. The crucial bit here is that you cannot use shell for control flow here. If you prefer AS_FOR or some other working mechanism, that's fine. Just do something about it to avoid dialog failing to build when we remove libtool-bin from Debian. Helmut
Bug#1071581: dialog: stop using libtool-bin
Source: dialog Version: 1.3-20240307-2 Severity: normal Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability Hi Santiago, we want to remove the package libtool-bin from the archive, because any attempt of using it breaks cross compilation. The dialog package is a bit strange in this regard. It's autoconf stuff attempts to detect whether there is a libtool.m4 and when there isn't attempts to use a pre-configured libtool (the one from libtool-bin). Unfortunately, last time it was autoreconf'ed, that happened without libtool.m4. So basically, making libtool-bin go away here amounts to autoreconfing dialog after libtoolizing it. And that's pretty much what I did in the attached patch. The dialog binary and libdialog.la are bit-identical with this change. Helmut diff -Nru dialog-1.3-20240307/debian/changelog dialog-1.3-20240307/debian/changelog --- dialog-1.3-20240307/debian/changelog2024-04-08 12:40:00.0 +0200 +++ dialog-1.3-20240307/debian/changelog2024-05-20 23:15:03.0 +0200 @@ -1,3 +1,10 @@ +dialog (1.3-20240307-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Stop using libtool-bin by autoreconfing. (Closes: #-1) + + -- Helmut Grohne Mon, 20 May 2024 23:15:03 +0200 + dialog (1.3-20240307-2) unstable; urgency=medium * Fix Breaks and Replaces fields. Closes: #1068634. diff -Nru dialog-1.3-20240307/debian/control dialog-1.3-20240307/debian/control --- dialog-1.3-20240307/debian/control 2024-04-08 11:00:00.0 +0200 +++ dialog-1.3-20240307/debian/control 2024-05-20 23:15:03.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Santiago Vila Standards-Version: 4.6.2 -Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3), libtool-bin +Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3), libtool Homepage: https://invisible-island.net/dialog/dialog.html Rules-Requires-Root: no diff -Nru dialog-1.3-20240307/debian/patches/libtool.patch dialog-1.3-20240307/debian/patches/libtool.patch --- dialog-1.3-20240307/debian/patches/libtool.patch1970-01-01 01:00:00.0 +0100 +++ dialog-1.3-20240307/debian/patches/libtool.patch2024-05-20 23:15:03.0 +0200 @@ -0,0 +1,214 @@ +--- dialog-1.3-20240307.orig/configure.in dialog-1.3-20240307/configure.in +@@ -29,6 +29,7 @@ + dnl --- + AC_PREREQ(2.52.20230114) + AC_INIT(dialog.h) ++AC_CONFIG_MACRO_DIRS([m4]) + AC_CONFIG_HEADER(dlg_config.h:config.hin) + + AC_ARG_PROGRAM +@@ -229,26 +230,24 @@ + mktime \ + ) + +-CF_CURSES_FUNCS(\ +-flushinp \ +-getattrs \ +-getbegx \ +-getbegy \ +-getbegyx \ +-getcurx \ +-getcury \ +-getmaxx \ +-getmaxy \ +-getmaxyx \ +-getparx \ +-getpary \ +-getparyx \ +-use_default_colors \ +-wchgat \ +-wcursyncup \ +-wget_wch \ +-wsyncup \ +-) ++CF_CURSES_FUNC(flushinp) ++CF_CURSES_FUNC(getattrs) ++CF_CURSES_FUNC(getbegx) ++CF_CURSES_FUNC(getbegy) ++CF_CURSES_FUNC(getbegyx) ++CF_CURSES_FUNC(getcurx) ++CF_CURSES_FUNC(getcury) ++CF_CURSES_FUNC(getmaxx) ++CF_CURSES_FUNC(getmaxy) ++CF_CURSES_FUNC(getmaxyx) ++CF_CURSES_FUNC(getparx) ++CF_CURSES_FUNC(getpary) ++CF_CURSES_FUNC(getparyx) ++CF_CURSES_FUNC(use_default_colors) ++CF_CURSES_FUNC(wchgat) ++CF_CURSES_FUNC(wcursyncup) ++CF_CURSES_FUNC(wget_wch) ++CF_CURSES_FUNC(wsyncup) + + CF_CURSES_EXIT + +--- dialog-1.3-20240307.orig/aclocal.m4 dialog-1.3-20240307/aclocal.m4 +@@ -1412,6 +1412,7 @@ + AC_MSG_CHECKING(version of $LIBTOOL) + CF_LIBTOOL_VERSION + AC_MSG_RESULT($cf_cv_libtool_version) ++ ifdef([LT_PACKAGE_VERSION],,[ + if test -n "$cf_cv_libtool_version" + then + cf_check_libtool_version=`$LIBTOOL --version 2>&1 | sed -e '/^$/d' -e 's,[[()]],...,g' -e 's,[[ ]],-,g' -e '2,$d'` +@@ -1425,6 +1426,7 @@ + else + AC_MSG_ERROR(No version found for $LIBTOOL) + fi ++ ]) + else + AC_MSG_ERROR(GNU libtool has not been found) + fi +@@ -1636,50 +1638,45 @@ + dnl when switching to/from a debug-library. + AC_DEFUN([CF_CURSES_EXIT], + [ +-CF_CURSES_FUNCS(\ +-exit_curses \ +-_nc_free_and_exit \ +-) ++CF_CURSES_FUNC(exit_curses) ++CF_CURSES_FUNC(_nc_free_and_exit) + ])dnl + dnl --- +-dnl CF_CURSES_FUNCS version: 20 updated: 2020/12/31 20:19:42 ++dnl CF_CURSES_FUNC version: 20 updated: 2020/12/31 20:19:42 + dnl --- + dnl Curses-functions are a little complicated, since a lot of them are macros. +-AC_DEFUN([CF_CURSES_FUNCS], ++AC_DEFUN([CF_CURSES_FUNC], + [ + AC_REQUIRE([CF_CURSES_CPPFLAGS])dnl + AC_REQUIRE([CF_XOPEN_CURSES]) + AC_REQUIRE([CF_CURSES_TERM_H]) + AC_REQUIRE([CF_CURSES_UNCTRL_H]) +-for cf_func in $1 +-do +- CF_UPPER(cf_tr_func,$cf_func) +- AC_MSG_CHECKING(for ${cf_func}) +- CF_MSG_LOG(${
Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building
Control: tags -1 - pending Control: reassign -1 libglib2.0-dev,sbuild Hi Simon, I'm sorry for the delayed reply. Even though I dumped significant effort into this, things turned out getting more complicated. For one thing, my attempts to fix this on the sbuild side have resulted in tagpending tagging this bug. sbuild's git no longer performs such tagging for feature branches. On Fri, May 17, 2024 at 10:42:11AM +0100, Simon McVittie wrote: > This is happening because upstream GLib 2.80.x has taken over > the lower-level parts of the GObject-Introspection toolchain > from src:gobject-introspection. As a result, providing its full > functionality requires the ability to run host-architecture binaries > (for at least gi-compile-repository, which will eventually replace > gobject-introspection's g-ir-compiler). > > In older versions, src:gobject-introspection would likely have had > the same issue; the only difference is that libglib2.0-dev affects > more packages. > > As a reminder of the design here, g-ir-scanner from in the > gobject-introspection source package examines shared libraries and outputs > GIR XML, which is analogous to C headers: usually, but not always, > architecture-independent. g-ir-compiler or gi-compile-repository takes the > GIR XML and compiles it into architecture-dependent binary typelibs. > The GIR XML is used directly by some language bindings (typically at > compile-time for static languages like Rust and C++), and the typelibs are > used for others (typically at runtime for dynamic languages like Perl and > Paython). > > I had initially hoped that we could wrap the build-architecture > g-ir-compiler/gi-compile-repository to compile GIR XML into typelibs, > but that was broken and caused a RC bug (#1066900), so we cannot do that. Yeah I know. Thanks for writing it down again. Not blaming you. > In principle we could build one copy of gi-compile-repository per (build > architecture, host architecture) pair, like cross-compilers, but that > seems bad from a maintainabiity point of view. Upstream does not support > this use-case (and in general has little interest in cross g-i) so it > would be very easy for it to regress, it would require either GLib or > some other package to know a complete list of all interesting Debian > architectures in the same way that gcc-13-cross does, and running > g-ir-scanner fundamentally requires executing code from the host > architecture *anyway* because that's just how g-i works. > > If the dependency was changed to: > > something-native | qemu-user | qemu-user-static, > python3:any, > > where "something-native" is any package that is either M-A: no or > M-A: allowed (but must not be M-A: foreign, and in practice is required > to be installed from a runnable architecture and not a barbarian > architecture) but is *not* Python, would that solve the problem? I guess that it might solve the immediate problem, but I'm not sure this is a good compromise. We've had the idea of restricting Multi-Arch:foreign packages from satisfying dependencies with host architecture instances since a while and crossqa's scheduler (but not builder) actually enforces this, so I've been looking into also enforcing it on the builder and that might be a better solution. I cannot tell yet. That said, you can find it at: https://salsa.debian.org/debian/sbuild/-/merge_requests/69 I note that my testing of this was not satisfactory. For one thing, it didn't seem to be reliable (and I note that none of the python core stack actually is Multi-Arch:foreign) and it also doesn't make any package cross buildable. When I get past this problem, I run into a new problem where libc6.postinst fails to understand that it is run in a chroot (as it looks too much like a container) and thus systemd-sysv's telinit kills the parent process of apt making sbuild unhappy (#1071462). While I welcome feedback on this issue, it quite definitely is a timesink. > Most of the obvious Essential or Build-Essential packages like base-files > are Multi-Arch: foreign, therefore not suitable for this purpose, but for > example a short-term hack version of this might be to use apt, perl or > perl-base as the something-native - because they are already installed > (and because apt is Important: yes and perl-base is Essential: yes), > hopefully apt will prefer to keep the existing version installed and take > the qemu-user alternative, in preference to attempting to crossgrade them > to a version that does not, in fact, work. I appreciate your effort for a quick solution, but I question whether the cure really is better than the disease. I also note that crossqa.d.n was completely broken for a week by c-t-b being uninstallable, so maybe we are better off acknowledging the problem and finding a solution we can all live with. Knowing the available options does help though. Thank you. > I don't know whether apt might become Multi-Arch: foreign in the future, > though. If it did, that would br
Bug#1071543: automake-1.16: drop unused libtool-bin dependency
Source: automake-1.16 Version: 1:1.16.5-1.3 Severity: normal Tags: patch Please drop the unused libtool-bin build dependency. It was formerly used by tests, but no longer is. I compared both build artifacts and build logs from a build with and without this dependency. I'm attaching a patch for your convenience. Helmut diff -Nru automake-1.16-1.16.5/debian/changelog automake-1.16-1.16.5/debian/changelog --- automake-1.16-1.16.5/debian/changelog 2022-03-18 14:09:08.0 +0100 +++ automake-1.16-1.16.5/debian/changelog 2024-05-20 23:01:28.0 +0200 @@ -1,3 +1,10 @@ +automake-1.16 (1:1.16.5-1.4) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libtool-bin dependency. (Closes: #-1) + + -- Helmut Grohne Mon, 20 May 2024 23:01:28 +0200 + automake-1.16 (1:1.16.5-1.3) unstable; urgency=medium * Non-maintainer upload. diff -Nru automake-1.16-1.16.5/debian/control automake-1.16-1.16.5/debian/control --- automake-1.16-1.16.5/debian/control 2021-10-23 06:35:41.0 +0200 +++ automake-1.16-1.16.5/debian/control 2024-05-20 23:01:28.0 +0200 @@ -9,7 +9,6 @@ help2man, install-info, libtool, - libtool-bin, pkg-config, texinfo, Rules-Requires-Root: no
Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility
Hi Lorenzo, On Fri, Feb 05, 2021 at 10:16:14AM +0100, Lorenzo Puliti wrote: > If dh-sysuser creates problem, then people affected need to report bugs about > that. I've done so. Multiple bugs remain unadressed for extended periods of time. > Following the last GR, the overall state of 'creating system users' in Debian > is getting messy, currently we have > > * systemd-sysusers [systemd package]: >this is destructive on systems with an alternative init system, as > installing >systemd package will likely remove your Desktop Environment (due to > conflict with >elogind). This was one of the reason for the existence of dh-sysuser at > least >at the beginning It also is not something we want in application containers. > * opensysusers: >in Debian only since 2020; i'm doing some QA maintainance on it to allow > it's inclusion >in Bullseye. Supposed to work fine with alternative init systems, possibly > also with >systemd although this setup is not tested (and not sure someone is > interested in this) While it still is in unstable, it's not in trixie and not really maintained. > * dh-sysuser: alternative declarative interface to handle creation and > removal of >users; known to work both with systemd and alternative init systems. >It's part of the runit infrastructure. I contend that it is only declarative on the source package side and becomes procdural in the binary package. It also is confusingly similar and subtly different (.sysuser vs .sysusers) to a more established API. It's not so much the separate implementation that I take issue with here but the separate API where a very similar and more widely used API exists. > * systemd-standalone-sysusers [ future package ] >currently does not exists, not sure when it will, but has been discussed > in TC list >and some other bug too. Will work fine for alternative init systems. >Not sure if it will work on BSD port, wich is relevant for runit This now exists and can be used on non-systemd systems as well as application containers. Meanwhile the BSD port is fully removed. > I don't plan to drop dh-sysuser soon as I may need it for runit future > development. Please reconsider this. While having implementation diversity is something I can relate to, diversity in API without substantial associated benefits is actually causing problems (documented in bugs) and this is what is happening here. > It's declarative and it parses a file in the source. When we say declarative, we also mean the binary package level. > Also (looking at the patch from #981799) I don't see a clear advantage > of systemd-sysusers in simlpifying syntax of rules or other files in the > /debian directory. Honestly, the syntax of sysusers.d makes spin up the manual page every time I need to use it. It won't win a usability contest. It is more about one standard is better than two competing standards. And then the more popular one typically wins as converting fewer packages is cheaper. > One notable difference is that dh-sysuser parses on buildtime while > systemd-sysusers parses on runtime, but for Debian I'm not sure what can > be the advantage of one approach versus the other. I think this is significant if you look into the hermetic-/usr use case. The story there is that you take a /usr filesystem, bolt it onto an empty root filesystem and then have systemd-sysusers + systemd-tmpfiles + systemd-firstboot populate what is needed. This is something dh-sysuser cannot support given its current architecture. > I plan to keep this bug open for the next release cycle so there is time > for people to highlight bug or other problems with this package. That cycle has happened. How about removing it now? Helmut
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#1071526: djbdns: move from dh-sysuser to standard dh_installsysusers
Source: djbdns Version: 1:1.05-15 Severity: wishlist Tags: patch dh-sysusers exists since 7 years and has gained 9 users in that time - djbdns being one of them. Still it has a number of deficiencies such as using useradd instead of the policy-recommended adduser or removing users during package removal against project consensus and is not making progress on addressing them. Meanwhile, a viable alternative with larger adoption exists: sysusers.d. This mechanism is built into debhelper and it no longer requires using systemd as multiple implementations now exist. I therefore think it is time to call dh-sysusers a failed experiment and move on. Do you agree with this reasoning? I'm attaching a patch for your convenience. Since djbdns currently FTBFS #1066632, I also had to fix that and my patch also fixes that. Helmut diff -Nru djbdns-1.05/debian/axfrdns.sysuser djbdns-1.05/debian/axfrdns.sysuser --- djbdns-1.05/debian/axfrdns.sysuser 2021-11-15 01:21:04.0 +0100 +++ djbdns-1.05/debian/axfrdns.sysuser 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -axfrdns defaults diff -Nru djbdns-1.05/debian/axfrdns.sysusers djbdns-1.05/debian/axfrdns.sysusers --- djbdns-1.05/debian/axfrdns.sysusers 1970-01-01 01:00:00.0 +0100 +++ djbdns-1.05/debian/axfrdns.sysusers 2024-05-20 12:16:48.0 +0200 @@ -0,0 +1 @@ +u axfrdns - - /nonexistent diff -Nru djbdns-1.05/debian/changelog djbdns-1.05/debian/changelog --- djbdns-1.05/debian/changelog2021-11-15 01:21:04.0 +0100 +++ djbdns-1.05/debian/changelog2024-05-20 12:16:48.0 +0200 @@ -1,3 +1,11 @@ +djbdns (1:1.05-15.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move from dh-sysuser to standard dh_installsysusers (Closes: #-1) + * Fix FTBFS. (Closes: #1066632) + + -- Helmut Grohne Mon, 20 May 2024 12:16:48 +0200 + djbdns (1:1.05-15) unstable; urgency=medium * Fix the setgid directory FTBFS on kFreeBSD: let the test tool diff -Nru djbdns-1.05/debian/control djbdns-1.05/debian/control --- djbdns-1.05/debian/control 2021-11-15 01:21:04.0 +0100 +++ djbdns-1.05/debian/control 2024-05-20 12:14:59.0 +0200 @@ -6,7 +6,7 @@ po-debconf, debhelper-compat (= 13), dh-runit (>= 2.8.13), - dh-sysuser, + dh-sequence-installsysusers, ionit, python3 , timelimit , diff -Nru djbdns-1.05/debian/dnscache.sysuser djbdns-1.05/debian/dnscache.sysuser --- djbdns-1.05/debian/dnscache.sysuser 2021-11-15 01:21:04.0 +0100 +++ djbdns-1.05/debian/dnscache.sysuser 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -dnscache defaults diff -Nru djbdns-1.05/debian/dnscache.sysusers djbdns-1.05/debian/dnscache.sysusers --- djbdns-1.05/debian/dnscache.sysusers1970-01-01 01:00:00.0 +0100 +++ djbdns-1.05/debian/dnscache.sysusers2024-05-20 12:16:48.0 +0200 @@ -0,0 +1 @@ +u dnscache - - /nonexistent diff -Nru djbdns-1.05/debian/patches/ftbfs-implicit-declaration.patch djbdns-1.05/debian/patches/ftbfs-implicit-declaration.patch --- djbdns-1.05/debian/patches/ftbfs-implicit-declaration.patch 1970-01-01 01:00:00.0 +0100 +++ djbdns-1.05/debian/patches/ftbfs-implicit-declaration.patch 2024-05-20 12:16:48.0 +0200 @@ -0,0 +1,82 @@ +Bug-Debian: https://bugs.debian.org/1066632 +--- djbdns-1.05.orig/seek_set.c djbdns-1.05/seek_set.c +@@ -1,4 +1,5 @@ + #include ++#include + #include "seek.h" + + #define SET 0 /* sigh */ +--- djbdns-1.05.orig/chkshsgr.c djbdns-1.05/chkshsgr.c +@@ -1,3 +1,5 @@ ++#include ++#include + #include "exit.h" + + int main() +--- djbdns-1.05.orig/hier.c djbdns-1.05/hier.c +@@ -1,5 +1,9 @@ + #include "auto_home.h" + ++void h(const char *home, int uid, int gid, int mode); ++void d(char *home, char *subdir, int uid, int gid, int mode); ++void c(const char *home, const char *subdir, char *file, int uid, int gid, int mode); ++ + void hier() + { + /* +--- djbdns-1.05.orig/install.c djbdns-1.05/install.c +@@ -14,7 +14,7 @@ + int fdsourcedir = -1; + + void h(home,uid,gid,mode) +-char *home; ++const char *home; + int uid; + int gid; + int mode; +@@ -52,8 +52,8 @@ + buffer ssout; + + void c(home,subdir,file,uid,gid,mode) +-char *home; +-char *subdir; ++const char *home; ++const char *subdir; + char *file; + int uid; + int gid; +--- djbdns-1.05.orig/utime.c djbdns-1.05/utime.c +@@ -1,5 +1,6 @@ + #include + #include ++#include + #include "scan.h" + #include "exit.h" + +--- djbdns-1.05.orig/dnsq.c djbdns-1.05/dnsq.c +@@ -1,3 +1,4 @@ ++#include + #include "uint16.h" + #include "strerr.h" + #include "buffer.h" +--- djbdns-1.05.orig/dnsqr.c djbdns-1.05/dnsqr.c +@@ -1,3 +1,4 @@ ++#include + #include "uint16.h" + #include "strerr.h" + #include "buffer.h" +--- djbdns-1.05.orig/prot.c djbdns-1.05/prot.c +@@ -1,3 +1,5 @@ ++#include ++#include + #inc
Bug#1071525: laminard: move from dh-sysuser to standard dh_installsysusers
Source: laminar Version: 1.1-1 Severity: wishlist Tags: patch dh-sysusers exists since 7 years and has gained 8 users in that time - laminar being one of them. Still it has a number of deficiencies such as using useradd instead of the policy-recommended adduser or removing users during package removal against project consensus and is not making progress on addressing them. Meanwhile, a viable alternative with larger adoption exists: sysusers.d. This mechanism is built into debhelper and it no longer requires using systemd as multiple implementations now exist. I therefore think it is time to call dh-sysusers a failed experiment and move on. Do you agree with this reasoning? I'm attaching a patch for your convenience. Helmut diff -Nru laminar-1.1/debian/changelog laminar-1.1/debian/changelog --- laminar-1.1/debian/changelog2021-09-30 13:13:31.0 +0200 +++ laminar-1.1/debian/changelog2024-05-20 12:13:19.0 +0200 @@ -1,3 +1,10 @@ +laminar (1.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move from dh-sysuser to standard dh_installsysusers (Closes: #-1) + + -- Helmut Grohne Mon, 20 May 2024 12:13:19 +0200 + laminar (1.1-1) unstable; urgency=medium * New upstream release. diff -Nru laminar-1.1/debian/control laminar-1.1/debian/control --- laminar-1.1/debian/control 2021-09-30 13:13:31.0 +0200 +++ laminar-1.1/debian/control 2024-05-20 12:08:05.0 +0200 @@ -5,13 +5,13 @@ Build-Depends: capnproto (>= 0.7.0~), debhelper-compat (= 13), + dh-sequence-installsysusers, libboost-dev, zlib1g-dev, libcapnp-dev (>= 0.7.0~), rapidjson-dev, bash-completion, cmake, - dh-sysuser, libjs-vue, libjs-chart.js, libjs-ansi-up, diff -Nru laminar-1.1/debian/laminard.sysuser laminar-1.1/debian/laminard.sysuser --- laminar-1.1/debian/laminard.sysuser 2021-09-30 13:13:31.0 +0200 +++ laminar-1.1/debian/laminard.sysuser 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -laminar defaults diff -Nru laminar-1.1/debian/laminard.sysusers laminar-1.1/debian/laminard.sysusers --- laminar-1.1/debian/laminard.sysusers1970-01-01 01:00:00.0 +0100 +++ laminar-1.1/debian/laminard.sysusers2024-05-20 12:13:07.0 +0200 @@ -0,0 +1 @@ +u laminar - - /var/lib/laminar diff -Nru laminar-1.1/debian/rules laminar-1.1/debian/rules --- laminar-1.1/debian/rules2021-09-30 13:13:31.0 +0200 +++ laminar-1.1/debian/rules2024-05-20 12:07:46.0 +0200 @@ -10,4 +10,4 @@ dh_auto_configure -- -DLAMINAR_VERSION=$(DEB_VERSION_UPSTREAM) %: - dh $@ --with sysuser,bash-completion --remove-d + dh $@ --with bash-completion --remove-d
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Hi Chris, On Mon, May 20, 2024 at 01:02:32AM +0200, Chris Hofstaedtler wrote: > "..., when using telinit from systemd-sysv" > > It would seem like a reasonable assumption that systemd-sysv's > telinit uses systemd-specific stuff, like SIGTERM. That also is an interesting angle to it. sbuild didn't ask for systemd-sysv to be installed. It was installed due to Build-Depends of some package. A different package might depend on sysvinit-core where telinit writes to /run/initctl. Other telinit may do different things. Handling all of telinit internals in one pid1 does not seem reasonable to me, so the consequence of this would be that you shouldn't install telinit in a build chroot and we could file bugs about any package doing so. A particular consequence of this would be that you couldn't use libpam-systemd or dbus-user-session in transitive Build-Depends. We'd render a significant number of packages bd-uninstallable. On the other hand, you have exactly the same problems when switching your pid1 implementation (where we urgently advise rebooting to avoid these kind of problems). That said, a sysvinit-core telinit likely wouldn't break a container's tini/dumb-init nor break a systemd running as pid1. Helmut
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Hi Luca, On Sun, May 19, 2024 at 06:04:38PM +0100, Luca Boccassi wrote: > On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne > wrote: > > the init process should handle SIGTERM more like an init system would > handle that > > This seems the obvious answer to me. sbuild is setting up a system such > that its component runs as pid1, so it needs to behave like a pid1. We > know this is special and requires supporting a number of interfaces. If > a program doesn't, then it shouldn't be running as pid1 in a namespace. Die you mean "... so it needs to behave like a systemd"? sysvinit does not document SIGTERM as a supported signal. https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html Neither does runit. https://manpages.debian.org/bookworm/runit/runit.8.en.html#SIGNALS Nor did upstart. https://sources.debian.org/src/upstart/0.6.6-1/init/main.c/#L249 Or dumb-init (forwards all signals to its children). Or tini (forwards all signals to its children). https://github.com/krallin/tini/blob/master/src/tini.c#L525 Or busybox (see busybox init --help). But openrc-init and it then performs a shutdown. https://sources.debian.org/src/openrc/0.54-2/src/openrc-init/openrc-init.c/#L210 As far as my research goes, this handling of SIGTERM is specific to systemd and not a generic assumption of pid1. Helmut
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Package: sbuild,debianutils,libc6,systemd-sysv Severity: important Hello lots of maintainers, I am faced with a very crazy interaction bug. Roughly speaking, when you use sbuild to build a package and your build-depends happen to include systemd-sysv and you happen to install (cross building) or upgrade libc6, installing build-depends reliably fails. Since upgrading libc6 is a thing, I guess that this now affects buildds and is why I file this at important severity. Regenerating buildd chroots, will "heal" buildds, so it is self-recovering there. Without further ado, let's dive into the details. The issue is reproducible using mmdebstrap: mmdebstrap unstable --verbose --architectures amd64,arm64 --variant=apt /dev/null --include=systemd-sysv,libc6:arm64 --essential-hook='ln -sf /bin/false $1/usr/bin/ischroot' This is using a cross build setting, because libc6 is installed early during bootstrap and reproducing the bug takes configuring libc6 after systemd-sysv has been unpacked. So I simply install a foreign libc6 and apt happens to configure it late enough in my tests. So we now look into libc6.postinst. We take the "$1" = "configure" branch. We eventually run into: | # Restart init. Currently handles chroots, systemd and upstart, and | # assumes anything else is going to not fail at behaving like | # sysvinit: | TELINIT=yes | if ischroot 2>/dev/null; then | # Don't bother trying to re-exec init from a chroot: | TELINIT=no I note that mmdebstrap creates a number of namespaces and then externally runs apt. If I understand things correctly, it also runs an external dpkg --root ... without --force-scripts-chrootless. Hence dpkg performs a chroot for every maintainer script and ischroot correctly detects this, so we would be setting TELINIT=no if I were not replacing it in the --essential-hook. In sbuild, the namespace setup is different. apt is entirely run inside the namespace. ischroot compares /proc/1/mountinfo to /proc/self/mountinfo. If both are readable and equal, it concludes that we're not in a chroot. If they differ, it concludes that we are in a chroot. For mmdebstrap, pid 1 happens to be a mmdebstrap process in the initial namespace and the ischroot process sees fewer mounts. Hence it concludes success there. For sbuild, pid 1 is a runuser process already running chrooted. Hence the mountinfo files equal and ischroot concludes that we are not running in a chroot. | elif [ -n "${DPKG_ROOT:-}" ]; then | # Do not re-exec init if we are operating on a chroot from outside: | TELINIT=no In neither case DPKG_ROOT is non-empty. | elif [ -d /run/systemd/system ]; then | # Restart systemd on upgrade, but carefully. | # The restart is wanted because of LP: #1942276 and Bug: #993821 | # The care is needed because of https://bugs.debian.org/753725 | # (if systemd --help fails the system might still be quite broken but | # that seems better than the kernel panic that results if systemd | # cannot reexec itself). | TELINIT=no In neither case /run/systemd/system exists. | if systemd --help >/dev/null 2>/dev/null; then | systemctl daemon-reexec | else | echo "Error: Could not restart systemd, systemd binary not working" >&2 | fi | fi | if [ "$TELINIT" = "yes" ]; then | telinit u 2>/dev/null || true ; sleep 1 | fi And finally we run telinit u when running inside sbuild or faking ischroot in mmdebstrap. Running telinit u doesn't go well. This actually has been a known problem with different symptoms recently. Earlier, cross build nodes would get stuck in libc6.postinst hanging in telinit forever. The reason was that telinit was re-executing itself over and over again attempting to forward to another init system but always returning back to itself. This has been fixed by Luca Boccassi: https://github.com/systemd/systemd/pull/31251 and #1063147 telinit no longer reexecs itself and rather does what it is supposed to do: kill(1, SIGTERM). Sadly this doesn't go well. In case of sbuild, we kill the runuser process. It exits non-zero and sbuild considers this a failure to install Build-Depends. This is bad. So I'm not exactly sure which part is broken here. We might argue that sbuild is setting up a container that looks too much like a container and should have pid 1 outside the chroot area or that the init process should handle SIGTERM more like an init system would handle that. We might argue that ischroot should detect init-less application container environments. We might argue that libc6 should ischroot is not meant for detecting application containers and libc6.postinst asks the wrong question and should be skipping telinit for such environments as well. We might argute that telinit should not kill a pid 1 that isn't systemd. At this time, I am really unsure which of these four packages we consider at fault. Possib
Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building
Package: libglib2.0-dev Version: 2.80.2-1 User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:tkgate X-Debbugs-Cc: debian-cr...@lists.debian.org Hi Simon, you recently added an alternative python3 to the qemu dependency. This is posing a challenge to cross building now, but the devil is in the detail. On a technical level, python3 | qemu expresses what we want. The crossqa service sees this and has special handling for python3. It considers python3.*-minimal to not be installable for the host architecture (as that pratically fails postinst). We're checking dependencies with dose and dose is quite clever in coming up with creative solutions. It has no problems figuring out that qemu is the solution here. Hence, reverse dependencies (tkgate being an example here) are scheduled for building and then apt looks at the dependencies. It sees python3 as the first alternative and is generally happy with installing the host one. Hence, it doesn't look beyond and doesn't consider qemu. The python3:any dependency show up later and the host's python3 happens to satisfy it. Hence apt is happy until python3-minimal:host.postinst fails. Arguably, this is a problem of the builder. Package depedencies cannot tell whether we can install a foreign python or not. That's a question only the builder can answer and David added a fiddle to apt quite a while ago that is called "BarbarianArchitectures" and documented as a list of architectures considered too foreign to satisfy M-A:foreign. Even though python3 isn't actually M-A:foreign, adding this setting immediately makes the build work and you can try that by adding this to your sbuild invocation: --chroot-setup-commands='echo "APT::BarbarianArchitectures {\"arm64\"};" > /etc/apt/apt.conf.d/b.conf' I also tried reordering the python3 dependencies in libglib2.0-dev such that the python3:any comes first, but that did not have any effect. Do we see another way than changing the way that sbuild (and pbuilder) performs cross builds? I note that this bug has a bit of urgency, because affected packages will be marked as bd-uninstallable and that is taken as a sign to stop trying to build the relevant architecture and makes crossqa.d.n stop doing builds until the next mirror push. So this bug breaks QA. 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#1071234: sbuild --chroot-mode=unshare: exposes /sys/kernel; breaks apparmor detection; ftbfs lomiri-thumbnailer and mediascanner2
Package: libsbuild-perl Version: 0.85.8 Tags: ftbfs patch Control: affects -1 + src:mediascanner2 src:lomiri-thumbnailer Hi Johannes and Jochen, Jochen asked me to look into why the affected packages FTBFS when using unshare chroot-mode. I managed to reproduce the failure, run the failing test in isolation, capture an strace, stare at the strace output, codesearch for random strings such as "com.canonical.MediaScanner2.Error.Unauthorized" and following it down to "check_access", "does_client_have_access", "get_client_apparmor_context" and finally "aa_is_enabled". That was a clue to look into AppArmor, so I ran "aa-enabled" on various configurations: * bookworm without apparmor -> Yes * Something with apparmor -> Yes * sbuild --chroot-mode=unshare -> Yes * sbuild --chroot-mode=schroot -> Maybe I think you spot the difference. The tests believe that AppArmor is working when it really is not and thus fail as the AppArmor context does not come back in the expected way. That leaves the question of why AppArmor looks like it was working. It's because /sys/kernel/security/apparmor exists. The https://systemd.io/CONTAINER_INTERFACE/ documents /sys/kernel to be inaccessible. Once you do that (and sbuild makes it really hard to do that), both packages can be built. I'm attaching a patch for your convenience. Helmut diff -Nru sbuild-0.85.8/debian/changelog sbuild-0.85.8+nmu1/debian/changelog --- sbuild-0.85.8/debian/changelog 2024-04-25 14:49:56.0 +0200 +++ sbuild-0.85.8+nmu1/debian/changelog 2024-05-16 23:02:54.0 +0200 @@ -1,3 +1,10 @@ +sbuild (0.85.8+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Do not expose /sys/kernel in the unshare backend. (Closes: #-1) + + -- Helmut Grohne Thu, 16 May 2024 23:02:54 +0200 + sbuild (0.85.8) unstable; urgency=medium [ Aurelien Jarno ] diff -Nru sbuild-0.85.8/lib/Sbuild/ChrootUnshare.pm sbuild-0.85.8+nmu1/lib/Sbuild/ChrootUnshare.pm --- sbuild-0.85.8/lib/Sbuild/ChrootUnshare.pm 2024-04-25 14:49:56.0 +0200 +++ sbuild-0.85.8+nmu1/lib/Sbuild/ChrootUnshare.pm 2024-05-16 22:55:25.0 +0200 @@ -337,6 +337,7 @@ mount -t tmpfs tmpfs \"\$rootdir/dev/shm\"; mkdir -p \"\$rootdir/sys\"; mount -o rbind /sys \"\$rootdir/sys\"; + mount -t tmpfs tmpfs \"\$rootdir/sys/kernel\" -o mode=,size=4k,ro mkdir -p \"\$rootdir/proc\"; mount -t proc proc \"\$rootdir/proc\"; exec /usr/sbin/chroot \"\$rootdir\" $init /sbin/runuser -u \"\$user\" -- sh -c \"cd \\\"\\\$1\\\" && shift && \\\"\\\$@\\\"\" -- \"\$dir\" \"\$@\";
Bug#1069926: laurel: move from dh-sysuser to standard dh_installsysusers
Hi Hilko, On Wed, May 15, 2024 at 03:39:14PM +0200, Hilko Bengen wrote: > Uh, my bad. I agree with your proposed change, I just have a few > questions before uploading: Cool! > Couldn't we just do "dh $@ --buildsystem cargo --with installsysusers" > when building the package? Seems to work fine. I was unaware of the addon. Thanks for improving my patch. I shall remember that for future patches of the same kind. > Am I assuming correctly that systemd-sysusers will leave existing user > entries alone or do we need an upgrade path? Yes. man sysusers.d says that it only creates user when it does not exist. I ran the patch through piuparts (and file a bug for dnsmasq-base as a result of the failure). The upgrade part looked like it works correctly. Helmut
Bug#1071144: qemu-web-desktop: move from dh-sysuser to standard dh_installsysusers
Source: qemu-web-desktop Version: 24.01.19+ds1-4 Severity: wishlist Tags: patch dh-sysuser is in operation for 7 years now and has gotten 8 users - qemu-web-desktop being one of them. In that time, it didn't quite mature and still has a number of deficiencies such as using useradd instead of policy-recommended adduser or removing users on package removal against project consensus for keeping users. I think it is time to call dh-sysuser a failed experiment and move to the standard sysusers.d mechanism used by many more packages. It has multiple implementations now such that it does not force systemd onto installations anymore. Do you agree with my reasoning? I'm attaching a patch for your convenience. Helmut diff -Nru qemu-web-desktop-24.01.19+ds1/debian/changelog qemu-web-desktop-24.01.19+ds1/debian/changelog --- qemu-web-desktop-24.01.19+ds1/debian/changelog 2024-03-26 11:16:58.0 +0100 +++ qemu-web-desktop-24.01.19+ds1/debian/changelog 2024-05-15 07:58:04.0 +0200 @@ -1,3 +1,10 @@ +qemu-web-desktop (24.01.19+ds1-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move from dh-sysuser to standard dh_installsysusers (Closes: #-1) + + -- Helmut Grohne Wed, 15 May 2024 07:58:04 +0200 + qemu-web-desktop (24.01.19+ds1-4) unstable; urgency=medium * Add DARTS to the package description for better findability. diff -Nru qemu-web-desktop-24.01.19+ds1/debian/control qemu-web-desktop-24.01.19+ds1/debian/control --- qemu-web-desktop-24.01.19+ds1/debian/control2024-03-26 11:06:00.0 +0100 +++ qemu-web-desktop-24.01.19+ds1/debian/control2024-05-15 07:51:12.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian Science Maintainers Uploaders: Roland Mas , Emmanuel Farhi , Frédéric-Emmanuel Picca -Build-Depends: debhelper (>= 12), dh-apache2, dh-sysuser, pandoc +Build-Depends: debhelper (>= 13.3), dh-apache2, pandoc Standards-Version: 4.1.2 Vcs-Browser: https://salsa.debian.org/debian/qemu-web-desktop Vcs-Git: https://salsa.debian.org/debian/qemu-web-desktop.git diff -Nru qemu-web-desktop-24.01.19+ds1/debian/rules qemu-web-desktop-24.01.19+ds1/debian/rules --- qemu-web-desktop-24.01.19+ds1/debian/rules 2023-02-15 19:35:32.0 +0100 +++ qemu-web-desktop-24.01.19+ds1/debian/rules 2024-05-15 07:58:01.0 +0200 @@ -10,7 +10,7 @@ %: - dh $@ --with apache2 --with sysuser + dh $@ --with apache2 override_dh_auto_build: mkdir build @@ -21,6 +21,10 @@ override_dh_install: dh_install +# Can be dropped in compat level 14 +execute_after_dh_installinit: + dh_installsysusers + override_dh_clean: rm -rf build dh_clean diff -Nru qemu-web-desktop-24.01.19+ds1/debian/sysuser qemu-web-desktop-24.01.19+ds1/debian/sysuser --- qemu-web-desktop-24.01.19+ds1/debian/sysuser2023-02-15 19:35:32.0 +0100 +++ qemu-web-desktop-24.01.19+ds1/debian/sysuser1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -_qemu-web-desktop home=/var/lib/qemu-web-desktop diff -Nru qemu-web-desktop-24.01.19+ds1/debian/sysusers qemu-web-desktop-24.01.19+ds1/debian/sysusers --- qemu-web-desktop-24.01.19+ds1/debian/sysusers 1970-01-01 01:00:00.0 +0100 +++ qemu-web-desktop-24.01.19+ds1/debian/sysusers 2024-05-15 07:56:22.0 +0200 @@ -0,0 +1 @@ +u _qemu-web-desktop - - /var/lib/qemu-web-desktop
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#1071119: snapd: move files to /usr for DEP17
Package: snapd Version: 2.62-1 Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi, we want to move all aliased files from / to /usr to finalize the /usr-merge transition via DEP17. I'm sending you a patch, because snapd did not convert by itself. This patch must not be backported to bookworm. Otherwise, this should be safe to apply unless you plan to rename or restructure the snapd package. If you do, please upload to experimental first to have QA check your package. Helmut diff -Nru snapd-2.62/debian/changelog snapd-2.62/debian/changelog --- snapd-2.62/debian/changelog 2024-04-17 09:02:58.0 +0200 +++ snapd-2.62/debian/changelog 2024-05-14 10:16:09.0 +0200 @@ -1,3 +1,10 @@ +snapd (2.62-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move files to /usr for DEP17. (Closes: #-1) + + -- Helmut Grohne Tue, 14 May 2024 10:16:09 +0200 + snapd (2.62-1) unstable; urgency=medium [ Ernest Lotter ] diff -Nru snapd-2.62/debian/rules snapd-2.62/debian/rules --- snapd-2.62/debian/rules 2024-04-17 09:02:58.0 +0200 +++ snapd-2.62/debian/rules 2024-05-14 10:16:09.0 +0200 @@ -35,7 +35,7 @@ endif # this is overridden in the ubuntu/14.04 release branch -SYSTEMD_UNITS_DESTDIR="lib/systemd/system/" +SYSTEMD_UNITS_DESTDIR="$(shell pkg-config --variable=systemdsystemunitdir systemd)" # The go tool does not fully support vendoring with gccgo, but we can # work around that by constructing the appropriate -I flag by hand. diff -Nru snapd-2.62/debian/snapd.links snapd-2.62/debian/snapd.links --- snapd-2.62/debian/snapd.links 2024-04-17 09:02:58.0 +0200 +++ snapd-2.62/debian/snapd.links 2024-05-14 10:15:46.0 +0200 @@ -1,4 +1,4 @@ -/usr/lib/snapd/snap-device-helper /lib/udev/snappy-app-dev +/usr/lib/snapd/snap-device-helper /usr/lib/udev/snappy-app-dev # This should be removed once we can rely on debhelper >= 11.5: # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678 /usr/lib/systemd/user/snapd.session-agent.socket /usr/lib/systemd/user/sockets.target.wants/snapd.session-agent.socket
Bug#1070835: update-alternatives: error: alternative path /bin/ed doesn't exist
Control: retitle -1 OBS does not correctly implement the bootstrap protocol Control: reassign -1 src:open-build-service Control: affects -1 + ed Hi, On Fri, May 10, 2024 at 10:48:54AM +0200, Oliver Smith wrote: > in Debian sid, installing ed fails with: > > [49/600] installing ed-1.20.2-2 > update-alternatives: error: alternative path /bin/ed doesn't exist > > It looks like this is related to usr merge, the binary seems to be in > /usr/bin/ed now: https://packages.debian.org/sid/amd64/ed/filelist > > The error happens in an opensuse build server, trying to build a Debian > package that depends on ed. The bootstrap protocol requires that every transitively essential package has been configured at least once before installing other packages. ed is such an other package. Therefore, we may assume that usrmerge or usr-is-merged (which are a dependency of essential init-system-helpers) has been configured at least once. OBS has its own bootstrap strategy that violates this requirement. The bug is to be found there rather than in ed. Helmut
Bug#1071033: fakemachine "Network is unreachable" when run on IPv6-only hosts
Control: forwarded -1 https://github.com/go-debos/fakemachine/issues/207 Created upstream issue. Helmut
Bug#1071033: fakemachine "Network is unreachable" when run on IPv6-only hosts
Source: golang-github-go-debos-fakemachine Version: 0.0.4-1 Tags: patch upstream Control: affects -1 + debos When running debos on an ipv6-only machine, it sets up a virtual machine using fakemachine and tries to access Debian repository. It first tries connecting via IPv6, but notices that the fakemachine does not have any IPv6 addresses nor routes so it proceeds to using IPv4. It sends an IPv4 package and qemu's user network stack tries to send it on the host, but there it notices that the IPv6-only host does not have any IPv4 addresses nor routes and likewise reports that the network is unreachable. As a result, running a fakemachine on an IPv6-only host results in the inability to access network resources. Helmut Description: Make debos work on ipv6-only machines Author: Helmut Grohne Forwarded: no When running debos on an ipv6-only machine, it sets up a virtual machine using fakemachine and tries to access Debian repository. It first tries connecting via IPv6, but notices that the fakemachine does not have any IPv6 addresses nor routes so it proceeds to using IPv4. It sends an IPv4 package and qemu's user network stack tries to send it on the host, but there it notices that the IPv6-only host does not have any IPv4 addresses nor routes and likewise reports that the network is unreachable. As a result, running a fakemachine on an IPv6-only host results in the inability to access network resources. --- golang-github-go-debos-fakemachine-0.0.9.orig/machine.go +++ golang-github-go-debos-fakemachine-0.0.9/machine.go @@ -299,9 +299,8 @@ Type=ether [Network] DHCP=ipv4 -# Disable link-local address to speedup boot -LinkLocalAddressing=no -IPv6AcceptRA=no +LinkLocalAddressing=yes +IPv6AcceptRA=yes ` const networkdLinkTemplate = `
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
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#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#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 func
Bug#983227: coz-profiler: drop unused Build-Depends
Hi Petter, On Thu, May 09, 2024 at 11:07:20AM +0200, Petter Reinholdtsen wrote: > The reason it have these build dependencies, is to make sure the package > only build on architectures where it will actually work, to avoid > earning a release critical bug of providing binaries that do not work. > > I am thus very reluctant to drop build dependencies also needed at > runtime. Your reasoning on this is sound to me. Would you mind adding comments to debian/control documenting this non-obvious aspect such that the next time someone looks for technically unused dependencies they see why they're there? >From my pov, please close this bug when documenting their need. Helmut
Bug#1070762: debos: unhelpful error message "Modules path couldn't be determined"
Package: debos Version: 1.1.1-2.1+b1 Hi, I was trying to use debos and all that it told me was: | Modules path couldn't be determined This is not helpful. After digging into code I eventually figured that when it says "modules" it measn "Linux kernel modules". This is not evident from the context. Moreoever, it eventually became clear that the module it was missing was 9pnet_virtio. If that name had been included in the error message, it would have been immediately obvious to me that the cause was using a -cloud kernel as -cloud kernels lack 9p functionality (see #955232). While debos recommends a non-cloud kernel and the non-cloud kernel even got installed, the additional presence of a -cloud kernel image meant that grub would prefer booting that. I hope this is sufficient reason to improve the error message. Thanks for considering. Helmut
Bug#1070495: Should qbe be Architecture: amd64 arm64 riscv64 ?
Hi, On Mon, May 06, 2024 at 02:51:56PM +0300, Adrian Bunk wrote: > Source: qbe > Version: 1.2-1 > Severity: important > Tags: ftbfs > > https://buildd.debian.org/status/logs.php?pkg=qbe&ver=1.2-1 > > ... >dh_auto_test -a > make -j8 check > make[1]: Entering directory '/<>' > tools/test.sh all > abi1.ssa... /tmp/qbe..s: Assembler > messages: > /tmp/qbe..s:3: Error: unrecognized opcode: `pushq' > /tmp/qbe..s:4: Error: unrecognized opcode: `movq' > /tmp/qbe..s:5: Error: unrecognized opcode: `movq' > /tmp/qbe..s:6: Error: unrecognized opcode: `addq' > /tmp/qbe..s:8: Error: unrecognized opcode: `movb' > /tmp/qbe..s:9: Error: unrecognized opcode: `movq' > ... > 50 of 50 tests failed! > make[1]: *** [Makefile:72: check] Error 50 > > > > This is due to explicit support required for every architecture, > and defaulting to amd64 otherwise: > https://sources.debian.org/src/qbe/1.2-1/Makefile/#L44-L54 > > (The package also builds on m68k/sh4 in ports since these are > building with nocheck.) > > An explicit > Architecture: amd64 arm64 riscv64 > might be a better option for such a package that needs > a backend written for every architecture it supports? You are conflating host architecture and target architecture here. The compiler only targets three architectures at this time, but there is little limitation in host architectures. The test suite fails, because it performs the testing for a target derived from the current host architecture (same conflation). Unlike gcc and like llvm/clang, qbe is a multi-target compiler with runtime selection of target architecture. Hence, the test suite should be repeated for each supported target and for doing so it likely needs to Build-Depends: qemu-user . Helmut
Bug#1070486: nbtscan: autopkgtest not safe to run
Source: nbtscan Version: 1.7.2-2 Tags: patch Hi, I was running the autopkgtest of nbtscan on a dedicated server and the relevant provider captured the scanning and was not happy. Given that the test does not actually evaluate any responses, I think it would not degrade the test in any way if it were scanning the loopback interface instead and thus avoid tripping up paranoid hosters. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru nbtscan-1.7.2/debian/changelog nbtscan-1.7.2/debian/changelog --- nbtscan-1.7.2/debian/changelog 2022-10-29 19:17:25.0 +0200 +++ nbtscan-1.7.2/debian/changelog 2024-05-06 11:28:15.0 +0200 @@ -1,3 +1,10 @@ +nbtscan (1.7.2-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * autopkgtest: Scan loopback rather than the internet. (Closes: #-1) + + -- Helmut Grohne Mon, 06 May 2024 11:28:15 +0200 + nbtscan (1.7.2-2) unstable; urgency=medium * debian/control: bumped Standards-Version to 4.6.1. diff --minimal -Nru nbtscan-1.7.2/debian/tests/control nbtscan-1.7.2/debian/tests/control --- nbtscan-1.7.2/debian/tests/control 2022-10-29 19:17:22.0 +0200 +++ nbtscan-1.7.2/debian/tests/control 2024-05-06 11:28:15.0 +0200 @@ -1,6 +1,6 @@ Test-Command: nbtscan | grep Usage Restrictions: superficial -Test-Command: nbtscan -v 203.0.113.0/24 +Test-Command: nbtscan -v 127.1.0.0/24 -Test-Command: nbtscan -d -b 10 -t 2000 203.0.113.0-220 +Test-Command: nbtscan -d -b 10 -t 2000 127.1.0.0-220
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#1070328: libopenscap-perl misbuilds during cross build: wrong multiarch directory
Source: openscap Version: 1.3.10+dfsg-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs Cross building openscap successfully results in a broken libopenscap-perl. It uses the build architecture multiarch directory. When building a perl extension, you should Build-Depends: perl-xs-dev rather than libperl-dev these days and then you can pass a suitable PERL5LIB supplying the cross configuration. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru openscap-1.3.10+dfsg/debian/changelog openscap-1.3.10+dfsg/debian/changelog --- openscap-1.3.10+dfsg/debian/changelog 2024-04-05 07:40:35.0 +0200 +++ openscap-1.3.10+dfsg/debian/changelog 2024-05-03 08:23:56.0 +0200 @@ -1,3 +1,12 @@ +openscap (1.3.10+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix cross misbuild: (Closes: #-1) ++ Build-Depends: perl-xs-dev for building a perl extension. ++ Supply a cross PERL5LIB. + + -- Helmut Grohne Fri, 03 May 2024 08:23:56 +0200 + openscap (1.3.10+dfsg-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru openscap-1.3.10+dfsg/debian/control openscap-1.3.10+dfsg/debian/control --- openscap-1.3.10+dfsg/debian/control 2024-04-05 07:40:35.0 +0200 +++ openscap-1.3.10+dfsg/debian/control 2024-05-03 08:23:55.0 +0200 @@ -18,7 +18,6 @@ libldap2-dev, libopendbx1-dev, libpcre2-dev, - libperl-dev, libpopt-dev, libpython3-all-dev, librpm-dev, @@ -29,6 +28,7 @@ libxmlsec1-dev, libxslt1-dev, libyaml-dev, + perl-xs-dev, pkgconf, python3-all-dev:native, python3-pytest , diff --minimal -Nru openscap-1.3.10+dfsg/debian/rules openscap-1.3.10+dfsg/debian/rules --- openscap-1.3.10+dfsg/debian/rules 2024-04-05 07:40:35.0 +0200 +++ openscap-1.3.10+dfsg/debian/rules 2024-05-03 08:23:56.0 +0200 @@ -6,6 +6,14 @@ export DEB_BUILD_MAINT_OPTIONS := hardening=+all +include /usr/share/dpkg/architecture.mk + +ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) +PERLVER := $(shell perl -MConfig -e 'print $$Config{version}') +PERL5LIB := /usr/lib/$(DEB_HOST_MULTIARCH)/perl/cross-config-$(PERLVER)$(if $(PERL5LIB),:$(PERL5LIB)) +export PERL5LIB +endif + PYVERS=$(shell py3versions --supported --version) CMAKE_OPTS = \ -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
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#1070326: kexec-tools: move aliased files to /usr for DEP17
Package: kexec-tools Version: 1:2.0.27-1.1 Severity: important Tags: patch Hi, kexec-tools is part of the /usr-move (DEP17) migration due to installing files into /sbin, which is an aliased location. We want to eliminate (bad) aliasing effects by not installing any aliased files anymore. Hence, kexec-tools also needs to move and since it doesn't use dh, it cannot be moved using dh-sequence-movetousr. Therefore, I'm attaching a patch to perform the move manualy. Note that this patch must not be backported to bookworm-backports or earlier. kexec-tools isn't usually backported, so this likely is not a problem. Helmut diff --minimal -Nru kexec-tools-2.0.27/debian/changelog kexec-tools-2.0.27/debian/changelog --- kexec-tools-2.0.27/debian/changelog 2024-04-27 14:49:56.0 +0200 +++ kexec-tools-2.0.27/debian/changelog 2024-05-03 12:35:57.0 +0200 @@ -1,3 +1,10 @@ +kexec-tools (1:2.0.27-1.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move files to /usr for DEP17. (Closes: #-1) + + -- Helmut Grohne Fri, 03 May 2024 12:35:57 +0200 + kexec-tools (1:2.0.27-1.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru kexec-tools-2.0.27/debian/kexec-tools.dirs kexec-tools-2.0.27/debian/kexec-tools.dirs --- kexec-tools-2.0.27/debian/kexec-tools.dirs 2023-08-22 18:53:02.0 +0200 +++ kexec-tools-2.0.27/debian/kexec-tools.dirs 2024-05-03 12:34:38.0 +0200 @@ -1,2 +1,2 @@ -sbin +usr/sbin etc/default/kexec.d diff --minimal -Nru kexec-tools-2.0.27/debian/patches/coldreboot.patch kexec-tools-2.0.27/debian/patches/coldreboot.patch --- kexec-tools-2.0.27/debian/patches/coldreboot.patch 2023-09-17 19:09:53.0 +0200 +++ kexec-tools-2.0.27/debian/patches/coldreboot.patch 2024-05-03 12:35:21.0 +0200 @@ -57,7 +57,7 @@ + +/bin/rm -f $NOKEXECFILE +touch $NOKEXECFILE -+/sbin/reboot $* ++/usr/sbin/reboot $* --- /dev/null +++ b/kexec/coldreboot.8 @@ -0,0 +1,25 @@ diff --minimal -Nru kexec-tools-2.0.27/debian/patches/systemd-support.patch kexec-tools-2.0.27/debian/patches/systemd-support.patch --- kexec-tools-2.0.27/debian/patches/systemd-support.patch 2023-10-04 18:22:02.0 +0200 +++ kexec-tools-2.0.27/debian/patches/systemd-support.patch 2024-05-03 12:35:38.0 +0200 @@ -121,7 +121,7 @@ +} + +load_kernel () { -+ test -x /sbin/kexec || exit 0 ++ test -x /usr/sbin/kexec || exit 0 + test "x`cat /sys/kernel/kexec_loaded`y" = "x1y" && exit 0 + + if [ -f $NOKEXECFILE ] @@ -138,9 +138,9 @@ + echo "Loading new kernel image into memory" + if [ -z "$INITRD" ] + then -+ /sbin/kexec -l "$KERNEL_IMAGE" --append="$REAL_APPEND" ++ /usr/sbin/kexec -l "$KERNEL_IMAGE" --append="$REAL_APPEND" + else -+ /sbin/kexec -l "$KERNEL_IMAGE" --initrd="$INITRD" --append="$REAL_APPEND" ++ /usr/sbin/kexec -l "$KERNEL_IMAGE" --initrd="$INITRD" --append="$REAL_APPEND" + fi + echo "kexec kernel loaded" +} diff --minimal -Nru kexec-tools-2.0.27/debian/rules kexec-tools-2.0.27/debian/rules --- kexec-tools-2.0.27/debian/rules 2023-10-04 19:59:38.0 +0200 +++ kexec-tools-2.0.27/debian/rules 2024-05-03 12:34:51.0 +0200 @@ -27,7 +27,7 @@ dh_testdir dh_update_autotools_config dh_autoreconf - CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/sbin --mandir=/usr/share/man --datadir=/usr/share + CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/usr/sbin --mandir=/usr/share/man --datadir=/usr/share touch configure-stamp build: build-arch build-indep @@ -63,7 +63,7 @@ [ ! -f $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static ] || strip $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static endif - install -D -m 0755 debian/kexec-tools/sbin/kexec debian/kexec-tools-udeb/sbin/kexec + install -D -m 0755 debian/kexec-tools/usr/sbin/kexec debian/kexec-tools-udeb/usr/sbin/kexec binary-indep: build install
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#1070255: midish FTCBFS: builds for the build architecture
Source: midish Version: 1.0.4-1.2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs midish fails to cross build from source, because it builds for the build architecture. It's configure script doesn't take architecture into account and mostly configures paths. Cross tools need to be passed to make just as is done in a traditional make-only project. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru midish-1.0.4/debian/changelog midish-1.0.4/debian/changelog --- midish-1.0.4/debian/changelog 2022-11-03 22:49:04.0 +0100 +++ midish-1.0.4/debian/changelog 2024-05-02 07:37:47.0 +0200 @@ -1,3 +1,10 @@ +midish (1.0.4-1.3) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Thu, 02 May 2024 07:37:47 +0200 + midish (1.0.4-1.2) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru midish-1.0.4/debian/rules midish-1.0.4/debian/rules --- midish-1.0.4/debian/rules 2022-11-03 22:49:04.0 +0100 +++ midish-1.0.4/debian/rules 2024-05-02 07:37:47.0 +0200 @@ -12,7 +12,7 @@ build: build-stamp build-stamp: configure-stamp dh_testdir - $(MAKE) + dh_auto_build --buildsystem=makefile touch build-stamp clean:
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 | make[
Bug#1070253: ddnet FTCBFS: upstream has rather un-Debiann-ish ideas about how cross compilation should work
Source: ddnet Version: 16.4-1.3 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs Hi, ddnet fails to cross build from source. Digging into this I found that ddnet upstream has a very different idea about cross building from Debian. For instance, ddnet stops using any kind of system libraries and expects that you vendor them all into the ddnet source code. Also they immediately opt out of using pkgconf for cross compilation. This is very much not what we do in Debian. I managed to make it cross buildable, but given how ddnet upstream has chosen to implement cross building, I expect that they very much won't like this patch. Possibly, there could be some kind of global switch between that vendoring-world that they want and that "like native" world that Debian's cross build environment is? Do you mind maintaining this patch in the source package? Helmut --- ddnet-16.4.orig/CMakeLists.txt +++ ddnet-16.4/CMakeLists.txt @@ -493,7 +493,7 @@ # be more aggressive with android toolchain set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH NO_CMAKE_SYSTEM_PATH NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH) else() -set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH NO_CMAKE_SYSTEM_PATH) +set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH) endif() else() set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH) @@ -512,11 +512,9 @@ endif() endfunction() -if(NOT CMAKE_CROSSCOMPILING) - # Check for PkgConfig once so all the other `find_package` calls can do it - # quietly. - find_package(PkgConfig) -endif() +# Check for PkgConfig once so all the other `find_package` calls can do it +# quietly. +find_package(PkgConfig) if(TARGET_OS STREQUAL "android") find_package(Android) endif() --- ddnet-16.4.orig/cmake/FindMySQL.cmake +++ ddnet-16.4/cmake/FindMySQL.cmake @@ -1,3 +1,7 @@ +find_package(PkgConfig QUIET) +pkg_check_modules(MYSQLCLIENT mysqlclient) +pkg_check_modules(LIBMARIADB libmariadb) + if(NOT CMAKE_CROSSCOMPILING) find_program(MYSQL_CONFIG NAMES mysql_config mariadb_config @@ -39,13 +43,13 @@ set_extra_dirs_lib(MYSQL mysql) find_library(MYSQL_LIBRARY NAMES "mysqlclient" "mysqlclient_r" "mariadbclient" - HINTS ${MYSQL_CONFIG_LIBRARY_PATH} + HINTS ${MYSQL_CONFIG_LIBRARY_PATH} ${MYSQLCLIENT_LIBRARY_DIRS} ${LIBMARIADB_LIBRARY_DIRS} ${CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH} ) set_extra_dirs_include(MYSQL mysql "${MYSQL_LIBRARY}") find_path(MYSQL_INCLUDEDIR NAMES "mysql.h" - HINTS ${MYSQL_CONFIG_INCLUDE_DIR} + HINTS ${MYSQL_CONFIG_INCLUDE_DIR} ${MYSQLCLIENT_INCLUDE_DIRS} ${LIBMARIADB_INCLUDE_DIRS} ${CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH} )
Bug#1070166: google-compute-engine-oslogin FTCBFS: uses the build architecture compiler
Source: google-compute-engine-oslogin Version: 20240415.00-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs google-compute-engine-oslogin fails to cross build from source, because it uses the build architecture compiler. Looking closer, this happens during dh_auto_install where debhelper does not pass cross tools. Apparently, it performs some of the build steps during dh_auto_install. I tracked this down to not setting the VERSION variable during dh_auto_build. Once setting it, make install doesn't build anything anymore and the cross build succeeds. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru google-compute-engine-oslogin-20240415.00/debian/changelog google-compute-engine-oslogin-20240415.00/debian/changelog --- google-compute-engine-oslogin-20240415.00/debian/changelog 2024-04-22 09:01:53.0 +0200 +++ google-compute-engine-oslogin-20240415.00/debian/changelog 2024-05-01 09:16:48.0 +0200 @@ -1,3 +1,10 @@ +google-compute-engine-oslogin (20240415.00-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Build during dh_auto_build. (Closes: #-1) + + -- Helmut Grohne Wed, 01 May 2024 09:16:48 +0200 + google-compute-engine-oslogin (20240415.00-1) unstable; urgency=medium * New upstream release. (closes: #1041130) diff --minimal -Nru google-compute-engine-oslogin-20240415.00/debian/rules google-compute-engine-oslogin-20240415.00/debian/rules --- google-compute-engine-oslogin-20240415.00/debian/rules 2024-04-22 09:01:53.0 +0200 +++ google-compute-engine-oslogin-20240415.00/debian/rules 2024-05-01 09:16:48.0 +0200 @@ -7,6 +7,10 @@ %: dh $@ +override_dh_auto_build: + dh_auto_build -- \ + VERSION=$(DEB_VERSION_UPSTREAM) + override_dh_auto_install: dh_auto_install -- \ LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
Bug#1070049: closed by Debian FTP Masters (reply to Carlos Henrique Lima Melara ) (Bug#1070049: fixed in kristall 0.4+dfsg-3)
Control: reopen -1 On Mon, Apr 29, 2024 at 07:51:03PM +, Debian Bug Tracking System wrote: > It has been closed by Debian FTP Masters > (reply to Carlos Henrique Lima Melara ). Unfortunately, my patch got mangled during application to the point where it no longer achieves the desired effect. The QMAKE_COMMAND assignment was moved to dh, which causes it to become -O--=QMAKE_COMMAND=... on the relevant dh_auto_* invocations and is being ignored. I'd appreciate if you could correctly apply the patch. Also consider performing a test build (sbuild --host=... or pbuilder --host-arch=...) to see whether your update retains the intended effects. Thank you. Helmut
Bug#1069890: Resignation & call for votes to elect the Chair
On Tue, Apr 30, 2024 at 11:09:26AM +0100, Matthew Vernon wrote: > > ===BEGIN > > > > A: Christoph Berg > > B: Matthew Garrett > > C: Helmut Grohne > > D: Stefano Rivera > > E: Timo Röhling > > F: Craig Small > > G: Matthew Vernon > > H: Sean Whitton > > > > ===END > > I vote H > A = B = C = D = E = G > F > > If no-one else wants to be chair when Sean leaves, I'd be willing to do so. Thanks for volunteering. I prefer having a longer hand-over period over a shorter one. Therefore, I change my earlier vote on this matter to the following assuming that you are also volunteering now already. G > H > AB > CDE > F Helmut signature.asc Description: PGP signature
Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?
On Mon, Apr 15, 2024 at 06:10:16PM +0200, Helmut Grohne wrote: > In any case, I looked into prototyping this suggested move as a patch to > the gcc packaging. I am attaching a proof-of-concept of this, but I'm > not particularly fond of it as it noticeably increases the packaging > complexity. I am adding a lot of "addons" and pull a bit of code from > various debian/rules.d/binary-*.mk to a new > debian/rules.d/binary-forhost.mk such that prefixes that were only used > in a particular file are now spread to multiple. For instance, all > ?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier > and are now spread out to debian/rules.d/binary-forhost.mk. This move is > rooted in the fact that inclusion of debian/rules.d/binary-*.mk is > conditionalized. > > So initially, I am more interested in figuring out whether this is the > right direction and as a secondary question conditional to the answer of > the first, how to improve the patch to make that work. I have added this patch to rebootstrap now and it has generally improved bootstrapping. In particular, gcc-N-for-host is practically coinstallable. I am more and more convinced that this is the right direction. Do you have fundamental objections? Do you see ways to improve the patch? Helmut