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}
Description: library f
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
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
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(${cf_func})
+- AC_CACHE_VAL(cf_cv_func_$cf_func,[
+-
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
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
+ #include
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.
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 or linux-libc-dev:armhf or linux-li
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 functionality in /usr/$DEB_HOST_GNU_TYPE. Th
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=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 |
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
Bug#1070125: dmucs FTCBFS: uses the build architecture compiler
Source: dmucs Version: 0.6.1+dfsg-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs dmucs fails to cross build from source, because it uses the build architecture compiler. override_dh_auto_configure now invokes ./configure without passing --host and hence configure uses the wrong compiler. Moreover, the upstream build system fails to forward the detected compiler to the COSMIC subdirectory. I'm attaching a patch to fix both for your convenience. Helmut diff -Nru dmucs-0.6.1+dfsg/debian/changelog dmucs-0.6.1+dfsg/debian/changelog --- dmucs-0.6.1+dfsg/debian/changelog 2024-04-22 02:19:52.0 +0200 +++ dmucs-0.6.1+dfsg/debian/changelog 2024-04-30 13:31:33.0 +0200 @@ -1,3 +1,11 @@ +dmucs (0.6.1+dfsg-2) UNRELEASED; urgency=medium + + * Fix FTCBFS: (Closes: #-1) ++ Pass --host to configure. ++ cross.patch: Forward CC to COSMIC subdir. + + -- Helmut Grohne Tue, 30 Apr 2024 13:31:33 +0200 + dmucs (0.6.1+dfsg-1) unstable; urgency=medium * QA upload. diff -Nru dmucs-0.6.1+dfsg/debian/patches/cross.patch dmucs-0.6.1+dfsg/debian/patches/cross.patch --- dmucs-0.6.1+dfsg/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100 +++ dmucs-0.6.1+dfsg/debian/patches/cross.patch 2024-04-30 13:31:33.0 +0200 @@ -0,0 +1,19 @@ +--- dmucs-0.6.1+dfsg.orig/COSMIC/Makefile dmucs-0.6.1+dfsg/COSMIC/Makefile +@@ -29,7 +29,7 @@ + # One may also start up the PortMaster (Spm -f firewallfilename). + # Please read the documentation on this. + +-CC = cc ++CC ?= cc + + OBJ = Saccept.o Sprintf.o Stest.ooutofmem.o \ + Sclose.o Sprtskt.o Stimeoutwait.o rdcolor.o \ +--- dmucs-0.6.1+dfsg.orig/Makefile.am dmucs-0.6.1+dfsg/Makefile.am +@@ -1,3 +1,5 @@ ++export CC ++ + SUBDIRS = COSMIC + + bin_PROGRAMS = gethost loadavg monitor remhost diff -Nru dmucs-0.6.1+dfsg/debian/patches/series dmucs-0.6.1+dfsg/debian/patches/series --- dmucs-0.6.1+dfsg/debian/patches/series 2024-04-20 05:31:05.0 +0200 +++ dmucs-0.6.1+dfsg/debian/patches/series 2024-04-30 13:31:33.0 +0200 @@ -3,3 +3,4 @@ 03_gcc-7.patch 40_reproducible.patch 50_fix-FTBS-GCC-13.patch +cross.patch diff -Nru dmucs-0.6.1+dfsg/debian/rules dmucs-0.6.1+dfsg/debian/rules --- dmucs-0.6.1+dfsg/debian/rules 2024-04-22 02:09:44.0 +0200 +++ dmucs-0.6.1+dfsg/debian/rules 2024-04-30 13:31:30.0 +0200 @@ -3,11 +3,13 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CFLAGS_MAINT_APPEND = -Wall +include /usr/share/dpkg/architecture.mk + override_dh_auto_install: cp -a remhost addhost override_dh_auto_configure: - ./configure + ./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) override_dh_clean: dh_clean
Bug#1070124: gpm FTBFS: -Werror=implicit-function-declaration makes missing #includes fatal
Source: gpm Version: 1.20.7-11 Severity: important Tags: ftbfs patch User: helm...@debian.org Usertags: rebootstrap We recently made -Werror=implicit-function-declaration the default. Unfortunately src/daemon/old_main.c is missing some crucial #includes and that makes the build fail in some configurations. It notably misses: * for strcmp, strcpy and strerror * for bzero I'm attaching a patch for your convenience. Helmut --- gpm-1.20.7.orig/src/daemon/old_main.c +++ gpm-1.20.7/src/daemon/old_main.c @@ -19,6 +19,8 @@ * / +#include /* str* */ +#include /* bzero */ #include /* UNIX */ #include /* SOCKET*/ #include /* open */
Bug#1070123: attr FTBFS: -Werror=implicit-function-declaration triggers on basefile for missing libgen.h
Source: attr Version: 1:2.5.2-1 Severity: important Tags: ftbfs patch User: helm...@debian.org Usertags: rebootstrap attr may fail to build from source with -Werror=implicit-function-declaration due to using basename without including libgen.h. I'm attaching a patch for your convenience. Helmut --- attr-2.5.2.orig/tools/attr.c +++ attr-2.5.2/tools/attr.c @@ -18,6 +18,7 @@ #include "config.h" +#include #include #include #include
Bug#1070007: sbuild/unshare: writing to /dev/stdout denied
Control: tags -1 + confirmed On Sun, Apr 28, 2024 at 10:59:14PM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Aurelien Jarno (2024-04-28 15:57:29) > > When running sbuild in unshare chroot mode, it is not possible to write to > > /dev/stdout: > > > > | echo test > /dev/stdout > > | sh: 1: cannot create /dev/stdout: Permission denied > > > > This is the reason of the FTBFS of at least clisp and supervisor when using > > the unshare chroot mode of sbuild. Jochen asked me to look into this. Let me write down what I have for the benefit of the next person dumping brain cells into it. I used bookworm's sbuild to reproduce it using the supervisor package and that readily reproduced. I added an execute_before_dh_auto_test with a few diagnostics: | ls -la /dev/stdout | lrwxrwxrwx 1 root root 15 Apr 30 07:36 /dev/stdout -> /proc/self/fd/1 | ls -la /proc/self/fd | total 0 | dr-x-- 2 helmut sbuild 0 Apr 30 07:36 . | dr-xr-xr-x 9 helmut sbuild 0 Apr 30 07:36 .. | lrwx-- 1 helmut sbuild 64 Apr 30 07:36 0 -> /dev/null | l-wx-- 1 helmut sbuild 64 Apr 30 07:36 1 -> pipe:[135566170] | l-wx-- 1 helmut sbuild 64 Apr 30 07:36 2 -> pipe:[135566170] | lr-x-- 1 helmut sbuild 64 Apr 30 07:36 3 -> /proc/123/fd | echo hello > /proc/self/fd/1 | /bin/sh: 1: cannot create /proc/self/fd/1: Permission denied I also added --anything-failed-commands=%SBUILD_SHELL and there things look different. | # ls -la /proc/self/fd/1 | l-wx-- 1 root root 64 Apr 30 07:44 /proc/self/fd/1 -> /dev/tty | # runuser -u helmut bash | $ ls -la /proc/self/fd/1 | l-wx-- 1 helmut sbuild 64 Apr 30 07:48 /proc/self/fd/1 -> /dev/tty Running supervisor's test suite succeeds here. Quite certainly, the cause is connected to that pipe. The pipe in question is connecting the build log to a process that filters the build log and replaces PKGBUILDDIR and stuff. As far as I understand it, the crucial bit is that this process runs outside of the namespace. To confirm this hypothesis, I tried the following override: | override_dh_auto_test: | dh_auto_test | cat In essence, I am placing another process (cat) inside the namespace such that the stdout pipe of the test resides fully inside the namespace and cat is responsible for writing to the pipe outside without going via /proc/self/fd. With this modification, the build works again. > This works in podman. So somehow it's possible to connect /dev/stdout in a way > which preserves its intended functionality. Probably it would be useful to > find > out how podman does this. For what its worth, mmdebstrap itself suffers from > the same problem, so whatever fix is used in sbuild should probably also be > added to mmdebstrap. This does not work in podman https://github.com/containers/podman/issues/16870 nor on docker https://github.com/moby/moby/issues/31243. It sometimes works and that sometimes is when you run it interactively and thus stdout points to a tty device. As soon as it is a that pipe thingy, it fails. This is actually something I researched more deeply a while ago without success. I was trying to open a regular file in the initial namespace, inherit the open file across unshare into a user and mount namespace and then open /proc/self/fd/N. Likewise, I get -EACCES there in the very same way. Some part of permission management prevents this kind of (intentional) leakage of file descriptors, but I cannot tell which or why. The lesson learned seems to be that when you run a container workload, your stdout or stderr should either connect to a tty or to a process that lives inside your namespace (not sure which of them). It also seems possible to change permission of those pipes https://github.com/containers/conmon/pull/112 but I do not understand what it means to do so and whether that technically is a good idea. If you chmod(0666, *STDOUT); right before unsharing in Sbuild/Utility.pm, the supervisor test also passes, but this can also have undesired effects if stdout is connected to a regular file. So we really should check that STDOUT is a pipe before doing so. There is protection in the sense that /proc/self/fd by default is mode 0500. I also note that posix says that fchmod should return -EINVAL when it is performed on a pipe, so doing this very much is a linux-ism (but namespaces already are). To see whether stdout is a pipe, we may fstat it and figure out whether its st_mode has S_IFIFO. In perl, that's: use Fcntl ':mode'; ... if (((stat(*STDOUT))[2] & S_IFMT) == S_IFIFO); Going deeper with research, think this is actually not a namespace problem. https://groups.google.com/g/fa.linux.kernel/c/WVFgFngkJZw indicates a very similar problem with doing setuid. We can emulate this locally and reproduce the failure unshare -U --map-auto -S 0 -G 0 sh -c \ '/sbin/runuser -u daemon -- sh -c ": >/proc/self/fd/1" | cat' noting that the use of unshare here is purely added for the benefit of running the test code unprivileged. You
Bug#1070059: p11-kit FTBFS with gcc-14 due to -Wincompatible-pointer-types having become an error
Control: tags -1 patch upstream fixed-upstream Control: forwarded -1 https://github.com/p11-glue/p11-kit/commit/d49c92c8420db6ee4c88515bdb014f68f4d471d9 On Mon, Apr 29, 2024 at 03:02:07PM +0200, Helmut Grohne wrote: > This will become a hard failure once we swicth to gcc-14. It's already fixed upstream! Helmut
Bug#1070059: p11-kit FTBFS with gcc-14 due to -Wincompatible-pointer-types having become an error
Source: p11-kit
Version: 0.25.3-4
Severity: important
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
p11-kit fails to build from source when built with gcc-14. In gcc-14,
-Wincompatible-pointer-types has become an error. For instance, the
armel build currently says:
| p11-kit/import-object.c: In function ‘add_attrs_pubkey_rsa’:
| p11-kit/import-object.c:223:62: warning: passing argument 3 of
‘p11_asn1_read’ from incompatible pointer type [-Wincompatible-pointer-types]
| 223 | attr_modulus.pValue = p11_asn1_read (asn, "modulus",
_modulus.ulValueLen);
| |
^~~~
| | |
| | long
unsigned int *
| In file included from p11-kit/import-object.c:53:
| ./common/asn1.h:60:62: note: expected ‘size_t *’ {aka ‘unsigned int *’} but
argument is of type ‘long unsigned int *’
|60 | size_t *length);
| | ^~
| p11-kit/import-object.c:229:70: warning: passing argument 3 of
‘p11_asn1_read’ from incompatible pointer type [-Wincompatible-pointer-types]
| 229 | attr_exponent.pValue = p11_asn1_read (asn, "publicExponent",
_exponent.ulValueLen);
| |
^
| | |
| |
long unsigned int *
| ./common/asn1.h:60:62: note: expected ‘size_t *’ {aka ‘unsigned int *’} but
argument is of type ‘long unsigned int *’
|60 | size_t *length);
| | ^~
| p11-kit/import-object.c: In function ‘add_attrs_pubkey_ec’:
| p11-kit/import-object.c:264:78: warning: passing argument 3 of
‘p11_asn1_read’ from incompatible pointer type [-Wincompatible-pointer-types]
| 264 | attr_ec_params.pValue = p11_asn1_read (info,
"algorithm.parameters", _ec_params.ulValueLen);
| |
^~
| |
|
| |
long unsigned int *
| ./common/asn1.h:60:62: note: expected ‘size_t *’ {aka ‘unsigned int *’} but
argument is of type ‘long unsigned int *’
|60 | size_t *length);
| | ^~
This will become a hard failure once we swicth to gcc-14.
Helmut
Bug#1070047: python3-django-pipeline: installs files into aliased locations
Control: tags -1 - patch Hi Alexandre, On Mon, Apr 29, 2024 at 12:35:02PM +0200, Alexandre Detiste wrote: > If I revert the NAME change autodep8 breaks on Salsa Dang. I was looking for what I could have broken and didn't see this. > Is there an easy way to have one name for pybuild and another one for > autodep8 ... ? I ll search. I looked at man pybuild and https://wiki.debian.org/Python/Pybuild and neither was particularly enlightening to me. Possibly setting PYBUILD_NAME=pipeline and PYBUILD_DESTDIR=debian/python3-django-pipeline works? Helmut
Bug#1069890: Resignation & call for votes to elect the Chair
On Fri, Apr 26, 2024 at 02:04:56PM +0100, Sean Whitton wrote: > Package: tech-ctte > > Dear committee members, > > As the membership of the committee has changed, in accordance with > convention I hereby resign as Chair, effective one week from now, and > call for votes to elect the Chair of the Technical Committee. > Per the Debian Constitution, the vote runs until all members have voted, > or until my resignation takes effect. > > I am happy to continue to volunteer for the role, if the committee agrees. > > The ballot: > > ===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 > ABG > CDE > F In this case, I want to give a rationale. While Sean's term ends this year, no one but Sean volunteered to take the chair position yet and I'd rather not volunteer myself. It also is customary to not become a chair quickly after joining the committee. So at this time, continuing with Sean seems like the best option to me though I'd prefer an earlier handover over choosing a chair when Sean's membership expires. I suggest raising another vote around August. Last but not least, I want to thank Sean for having served as chair and taking on the relevant bureaucracy. Helmut signature.asc Description: PGP signature
Bug#1070049: kristall FTCBFS: uses the build architecture qmake
Source: kristall Version: 0.4+dfsg-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs kristall fails to cross build from source, because it runs qmake from a Makefile without taking care to use a host one. I'm attaching a patch that makes the build use a triplet-prefixed qmake when indicated for your convenience. Helmut diff --minimal -Nru kristall-0.4+dfsg/debian/changelog kristall-0.4+dfsg/debian/changelog --- kristall-0.4+dfsg/debian/changelog 2023-06-12 04:10:13.0 +0200 +++ kristall-0.4+dfsg/debian/changelog 2024-04-29 12:13:41.0 +0200 @@ -1,3 +1,10 @@ +kristall (0.4+dfsg-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host architecture qmake. (Closes: #-1) + + -- Helmut Grohne Mon, 29 Apr 2024 12:13:41 +0200 + kristall (0.4+dfsg-2) unstable; urgency=medium * debian/control: update maintainer's email. diff --minimal -Nru kristall-0.4+dfsg/debian/rules kristall-0.4+dfsg/debian/rules --- kristall-0.4+dfsg/debian/rules 2022-12-30 14:32:08.0 +0100 +++ kristall-0.4+dfsg/debian/rules 2024-04-29 12:13:41.0 +0200 @@ -2,6 +2,7 @@ #export DH_VERBOSE = 1 include /usr/share/dpkg/pkg-info.mk +include /usr/share/dpkg/buildtools.mk export PREFIX=/usr export DEB_BUILD_MAINT_OPTIONS = hardening=+all @@ -14,3 +15,9 @@ %: dh $@ + +override_dh_auto_build: + dh_auto_build -- QMAKE_COMMAND='$(QMAKE)' + +override_dh_auto_install: + dh_auto_install -- QMAKE_COMMAND='$(QMAKE)'
Bug#1070050: hpcc FTCBFS: uses mpicc
Source: hpcc Version: 1.5.0-3 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs hpcc fails to cross build from source, because it uses mpicc. mpicc is completely unsupportable during cross builds, because there are no triplet-prefixed variants of mpicc. Instead, common wisdom is to use pkgconf and use it to look up the required compiler and linker flags. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru hpcc-1.5.0/debian/changelog hpcc-1.5.0/debian/changelog --- hpcc-1.5.0/debian/changelog 2022-07-28 22:21:34.0 +0200 +++ hpcc-1.5.0/debian/changelog 2024-04-29 10:39:50.0 +0200 @@ -1,3 +1,10 @@ +hpcc (1.5.0-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use pkgconf instead of mpicc. (Closes: #-1) + + -- Helmut Grohne Mon, 29 Apr 2024 10:39:50 +0200 + hpcc (1.5.0-3) unstable; urgency=medium * Refresh patches using gbp pq import/export diff --minimal -Nru hpcc-1.5.0/debian/control hpcc-1.5.0/debian/control --- hpcc-1.5.0/debian/control 2022-07-28 22:21:34.0 +0200 +++ hpcc-1.5.0/debian/control 2024-04-29 10:39:50.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian Science Maintainers Uploaders: Lucas Nussbaum -Build-Depends: debhelper-compat (= 12), libatlas-base-dev, mpi-default-dev, mpi-default-bin +Build-Depends: debhelper-compat (= 12), libatlas-base-dev, mpi-default-dev, mpi-default-bin, pkgconf Standards-Version: 4.3.0 Homepage: https://hpcchallenge.org/hpcc/ Vcs-Git: https://salsa.debian.org/hpc-team/hpcc.git diff --minimal -Nru hpcc-1.5.0/debian/patches/add-Make.Debian.patch hpcc-1.5.0/debian/patches/add-Make.Debian.patch --- hpcc-1.5.0/debian/patches/add-Make.Debian.patch 2022-07-28 22:21:34.0 +0200 +++ hpcc-1.5.0/debian/patches/add-Make.Debian.patch 2024-04-29 10:39:50.0 +0200 @@ -14,7 +14,7 @@ index 000..d19bbdf --- /dev/null +++ b/hpl/Make.Debian -@@ -0,0 +1,181 @@ +@@ -0,0 +1,185 @@ +# -*- makefile -*- +# +# -- High Performance Computing Linpack Benchmark (HPL) @@ -184,12 +181,16 @@ +# - Compilers / linkers - Optimization flags --- +# -- +# -+CC = mpicc -+CCNOOPT = $(HPL_DEFS) -+CCFLAGS = $(HPL_DEFS) -fomit-frame-pointer -O3 -funroll-loops -W -Wall $(shell dpkg-buildflags --get CFLAGS) ++PKG_CONFIG = pkg-config ++CC = cc ++MPI_CFLAGS = $(shell $(PKG_CONFIG) --cflags mpi) ++MPI_LIBS = $(shell $(PKG_CONFIG) --libs mpi) ++CCNOOPT = $(MPI_CFLAGS) $(HPL_DEFS) ++CCFLAGS = $(MPI_CFLAGS) $(HPL_DEFS) -fomit-frame-pointer -O3 -funroll-loops -W -Wall $(shell dpkg-buildflags --get CFLAGS) +# -+LINKER = mpicc ++LINKER = $(CC) +LINKFLAGS= $(CCFLAGS) $(shell dpkg-buildflags --get LDFLAGS) ++HPL_LIBS += $(MPI_LIBS) +# +ARCHIVER = ar +ARFLAGS = r
Bug#1070048: python3-distutils: empty directory loss /usr/lib/python3.12 due to /usr-move
Package: python3-distutils Version: 3.12.3-1 Severity: important Tags: patch Hi Matthias, python3-distutils installs an empty directory /usr/lib/python3.12. This is prone to loss when removing another package containing /lib/python3.12 such as python3-django-pipeline is being removed. My understanding is that distutils is removed from Python in version 3.12 and thus this empty directory is not required and rather an oversight. I am attaching a patch that removes the empty directory from the package. Helmut diff --minimal -Nru python3-stdlib-extensions-3.12.3/debian/changelog python3-stdlib-extensions-3.12.3/debian/changelog --- python3-stdlib-extensions-3.12.3/debian/changelog 2024-04-12 15:08:54.0 +0200 +++ python3-stdlib-extensions-3.12.3/debian/changelog 2024-04-29 08:37:11.0 +0200 @@ -1,3 +1,11 @@ +python3-stdlib-extensions (3.12.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop empty directory /usr/lib/python3.12 from python3-distutils. +(Closes: #-1) + + -- Helmut Grohne Mon, 29 Apr 2024 08:37:11 +0200 + python3-stdlib-extensions (3.12.3-1) unstable; urgency=medium * Update 3.11 extensions and modules to 3.11.9 release. diff --minimal -Nru python3-stdlib-extensions-3.12.3/debian/rules python3-stdlib-extensions-3.12.3/debian/rules --- python3-stdlib-extensions-3.12.3/debian/rules 2024-03-03 14:41:25.0 +0100 +++ python3-stdlib-extensions-3.12.3/debian/rules 2024-04-29 08:37:09.0 +0200 @@ -209,9 +209,6 @@ cp -r 3.12/Lib/tkinter $(d_tk)/usr/lib/python3.12/. rm -rf $(d_tk)/usr/lib/python3.12/tkinter/test - mkdir -p $(d_dist)/usr/lib/python3.12 - find $(d_dist) -name __pycache__ | xargs -r rm -rf - mkdir -p $(d_2to3)/usr/lib/python3.12 cp -r 3.12/Lib/lib2to3 $(d_2to3)/usr/lib/python3.12/. rm -rf $(d_2to3)/usr/lib/python3.12/lib2to3/tests
Bug#1070047: python3-django-pipeline: installs files into aliased locations
Package: python3-django-pipeline
Version: 3.0.0-1
Severity: serious
Justification: introduces new aliasing
Tags: patch
Control: affects -1 + python3-distutils
User: helm...@debian.org
Usertags: dep17p6
The last upload of python3-django-pipeline moved all of its files from
/usr/lib to /lib. Whils this works somewhat on a /usr-merged
installations, it causes subtle bugs due to dpkg not being prepared with
aliasing. In DEP17, we're resolving this by moving all files out of
aliased locations and python3-django-pipelines has just introduced new.
Hence, I'm filing this at RC severity. I think the move was accidental
and can be fixed by dropping the faulty "mv" command in favour of
setting PYBUILD_NAME to the package name rather than the module name.
I'm attaching a patch for your convenience.
Helmut
diff --minimal -Nru django-pipeline-3.0.0/debian/changelog
django-pipeline-3.0.0/debian/changelog
--- django-pipeline-3.0.0/debian/changelog 2024-04-28 19:35:05.0
+0200
+++ django-pipeline-3.0.0/debian/changelog 2024-04-29 10:17:13.0
+0200
@@ -1,3 +1,10 @@
+django-pipeline (3.0.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not install into /lib. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 29 Apr 2024 10:17:13 +0200
+
django-pipeline (3.0.0-1) unstable; urgency=medium
* Team Upload
diff --minimal -Nru django-pipeline-3.0.0/debian/rules
django-pipeline-3.0.0/debian/rules
--- django-pipeline-3.0.0/debian/rules 2024-04-28 19:35:05.0 +0200
+++ django-pipeline-3.0.0/debian/rules 2024-04-29 10:17:13.0 +0200
@@ -4,7 +4,7 @@
include /usr/share/dpkg/pkg-info.mk
export SETUPTOOLS_SCM_PRETEND_VERSION=${DEB_VERSION_UPSTREAM}
-export PYBUILD_NAME=pipeline
+export PYBUILD_NAME=django-pipeline
export PYBUILD_AFTER_BUILD_python3=PYTHONPATH=. sphinx-build -b html -d
docs/.build/.doctrees -N docs docs/.build/html
# Uncomment this to turn on verbose mode.
@@ -25,6 +25,5 @@
PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version}
/usr/bin/django-admin test --settings=tests.settings" dh_auto_test
execute_after_dh_auto_install:
- mv debian/python3-pipeline/* debian/python3-django-pipeline/
find -type f -name '*.pyc' -delete
find -type d -name __pycache__ -empty -delete
Bug#1070046: edflib: consider expressing the little endian constraint via Build-Depends: architecture-is-little-endian
Source: edflib
Version: 1.25-1
Severity: wishlist
Tags: patch
Hi,
edflib fails to build on big endian architectures. While it fails
quickly, it still requires creating a chroot and it looks like a real
failure. Would you mind lifting this into a build dependency expressing
the constraint? Thus edflib would become permanently bd-uninstallable on
all big endian architectures. I'm attaching a patch for your
convenience.
Helmut
diff --minimal -Nru edflib-1.25/debian/changelog edflib-1.25/debian/changelog
--- edflib-1.25/debian/changelog2024-01-13 16:37:31.0 +0100
+++ edflib-1.25/debian/changelog2024-04-29 12:02:22.0 +0200
@@ -1,3 +1,10 @@
+edflib (1.25-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Express little-endian constraint via Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 29 Apr 2024 12:02:22 +0200
+
edflib (1.25-1) unstable; urgency=medium
* New upstream version 1.25
diff --minimal -Nru edflib-1.25/debian/control edflib-1.25/debian/control
--- edflib-1.25/debian/control 2024-01-13 16:37:31.0 +0100
+++ edflib-1.25/debian/control 2024-04-29 12:02:17.0 +0200
@@ -4,7 +4,8 @@
Étienne Mollier
Section: science
Priority: optional
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: architecture-is-little-endian,
+ debhelper-compat (= 13),
cmake,
d-shlibs
Standards-Version: 4.6.2
diff --minimal -Nru edflib-1.25/debian/rules edflib-1.25/debian/rules
--- edflib-1.25/debian/rules2024-01-13 16:37:31.0 +0100
+++ edflib-1.25/debian/rules2024-04-29 12:02:00.0 +0200
@@ -8,10 +8,6 @@
dh $@ --buildsystem=cmake
override_dh_auto_configure:
-ifeq ($(DEB_HOST_ARCH_ENDIAN),big)
- @ echo "E: edflib doesn't support big endian systems, bailing out!"
- @ exit 1
-endif
dh_auto_configure -- -DEDFLIB_INSTALL_PATH=lib/${DEB_HOST_MULTIARCH}
Bug#1070025: mesaflash FTCBFS: multiple reasons
Source: mesaflash Version: 3.4.6-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs mesaflash fails to cross build from source for multiple reasons. The immediate failure is misdetections due to using the build architecture pkg-config as it is hard coded in the upstream Makefile. Turning it substitutable helps a bit, but only dh_auto_build provides a substitution by default so clean fails unless exporting it for all targets. Beyond that, MESAFLASH_IO detection relies on uname, which will produce wrong results during cross builds, so provide a result for it. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru mesaflash-3.4.6/debian/changelog mesaflash-3.4.6/debian/changelog --- mesaflash-3.4.6/debian/changelog2022-11-05 19:38:09.0 +0100 +++ mesaflash-3.4.6/debian/changelog2024-04-28 21:16:32.0 +0200 @@ -1,3 +1,13 @@ +mesaflash (3.4.6-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ cross.patch: Make pkg-config substitutable. ++ Seed MESAFLASH_IO as the Makefile misdetects it. ++ Export PKG_CONFIG for all targets as clean needs it. + + -- Helmut Grohne Sun, 28 Apr 2024 21:16:32 +0200 + mesaflash (3.4.6-1) unstable; urgency=medium * Add new Mesa boards: 7C81, 7I96S, 7I92T diff --minimal -Nru mesaflash-3.4.6/debian/patches/cross.patch mesaflash-3.4.6/debian/patches/cross.patch --- mesaflash-3.4.6/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100 +++ mesaflash-3.4.6/debian/patches/cross.patch 2024-04-28 21:16:32.0 +0200 @@ -0,0 +1,43 @@ +--- mesaflash-3.4.6.orig/Makefile mesaflash-3.4.6/Makefile +@@ -25,6 +25,7 @@ + RM = rm -f + AR = ar + RANLIB = ranlib ++PKG_CONFIG ?= pkg-config + + OWNERSHIP ?= --owner root --group root + +@@ -46,25 +47,25 @@ + CFLAGS += -std=c99 + + ifeq ($(TARGET),linux) +-$(shell which pkg-config > /dev/null) ++$(shell which $(PKG_CONFIG) > /dev/null) + ifeq ($(.SHELLSTATUS), 1) + $(error "can't find pkg-config") + endif + +-$(shell pkg-config --exists libpci > /dev/null) ++$(shell $(PKG_CONFIG) --exists libpci > /dev/null) + ifeq ($(.SHELLSTATUS), 1) + $(error "pkg-config can't find libpci") + endif + +-$(shell pkg-config --exists libmd > /dev/null) ++$(shell $(PKG_CONFIG) --exists libmd > /dev/null) + ifeq ($(.SHELLSTATUS), 1) + $(error "pkg-config can't find libmd") + endif + +-LIBPCI_CFLAGS := $(shell pkg-config --cflags libpci) +-LIBPCI_LDFLAGS := $(shell pkg-config --libs libpci) +-LIBMD_CFLAGS := $(shell pkg-config --cflags libmd) +-LIBMD_LDFLAGS := $(shell pkg-config --libs libmd) ++LIBPCI_CFLAGS := $(shell $(PKG_CONFIG) --cflags libpci) ++LIBPCI_LDFLAGS := $(shell $(PKG_CONFIG) --libs libpci) ++LIBMD_CFLAGS := $(shell $(PKG_CONFIG) --cflags libmd) ++LIBMD_LDFLAGS := $(shell $(PKG_CONFIG) --libs libmd) + BIN = mesaflash + LDFLAGS = -lm $(LIBPCI_LDFLAGS) $(LIBMD_LDFLAGS) + CFLAGS += -D_GNU_SOURCE $(LIBPCI_CFLAGS) $(LIBMD_CFLAGS) -D_FILE_OFFSET_BITS=64 diff --minimal -Nru mesaflash-3.4.6/debian/patches/series mesaflash-3.4.6/debian/patches/series --- mesaflash-3.4.6/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ mesaflash-3.4.6/debian/patches/series 2024-04-28 21:10:03.0 +0200 @@ -0,0 +1 @@ +cross.patch diff --minimal -Nru mesaflash-3.4.6/debian/rules mesaflash-3.4.6/debian/rules --- mesaflash-3.4.6/debian/rules2022-01-15 20:13:35.0 +0100 +++ mesaflash-3.4.6/debian/rules2024-04-28 21:16:27.0 +0200 @@ -1,6 +1,13 @@ #!/usr/bin/make -f +include /usr/share/dpkg/architecture.mk +DPKG_EXPORT_BUILDTOOLS=1 +include /usr/share/dpkg/buildtools.mk include /usr/share/dpkg/pkg-info.mk +# Makefile uses uname, which is wrong for cross builds. +MESAFLASH_IO:=$(if $(wildcard /usr/include/$(DEB_HOST_MULTIARCH)/asm/io.h),1,0) +export MESAFLASH_IO + %: dh $@
Bug#1056192: slirp4netns: allow reusing an existing tap file descriptor
On Mon, Mar 25, 2024 at 07:53:22AM +0100, Helmut Grohne wrote: > In the mean time, I've sent the patch upstream. I note that upstream released version 1.3.0 including this change. Helmut
Bug#1070026: ifupdown-ng FTCBFS: hard codes the build architecture pkg-config
Source: ifupdown-ng Version: 0.12.1-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs ifupdown-ng fails to cross build from source, because debian/rules hard codes the build architecture pkg-config and thus fails locating libbsd. This happens to be a silent failure and thus manifests in -Werror=implicit-function-declaration. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru ifupdown-ng-0.12.1/debian/changelog ifupdown-ng-0.12.1/debian/changelog --- ifupdown-ng-0.12.1/debian/changelog 2024-03-13 15:56:58.0 +0100 +++ ifupdown-ng-0.12.1/debian/changelog 2024-04-28 13:15:51.0 +0200 @@ -1,3 +1,10 @@ +ifupdown-ng (0.12.1-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #-1) + + -- Helmut Grohne Sun, 28 Apr 2024 13:15:51 +0200 + ifupdown-ng (0.12.1-4) unstable; urgency=medium * Fix FTBFS due to libbsd header location change (Closes: #1066707) diff --minimal -Nru ifupdown-ng-0.12.1/debian/rules ifupdown-ng-0.12.1/debian/rules --- ifupdown-ng-0.12.1/debian/rules 2024-03-13 15:54:18.0 +0100 +++ ifupdown-ng-0.12.1/debian/rules 2024-04-28 13:15:50.0 +0200 @@ -1,13 +1,14 @@ #!/usr/bin/make -f +include /usr/share/dpkg/buildtools.mk SHELL := /bin/bash %: dh $@ MAKE_VARS := \ - LIBBSD_CFLAGS="$(shell pkg-config --cflags libbsd-overlay)" \ - LIBBSD_LIBS="$(shell pkg-config --cflags --libs libbsd-overlay)" + LIBBSD_CFLAGS="$(shell $(PKG_CONFIG) --cflags libbsd-overlay)" \ + LIBBSD_LIBS="$(shell $(PKG_CONFIG) --cflags --libs libbsd-overlay)" override_dh_auto_build: # Compatiblity glue for libbsd (strlcpy 'n friends)
Bug#1069926: laurel: move from dh-sysuser to standard dh_installsysusers
Package: laurel Version: 0.6.1-1 Severity: wishlist Tags: patch Hi, dh-sysusers exists since 7 years and has gained 9 users in that time - laurel 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 --minimal -Nru rust-laurel-0.6.1/debian/changelog rust-laurel-0.6.1/debian/changelog --- rust-laurel-0.6.1/debian/changelog 2024-04-03 17:52:57.0 +0200 +++ rust-laurel-0.6.1/debian/changelog 2024-04-27 10:16:01.0 +0200 @@ -1,3 +1,10 @@ +rust-laurel (0.6.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move from dh-sysuser to standard dh_installsysusers. (Closes: #-1) + + -- Helmut Grohne Sat, 27 Apr 2024 10:16:01 +0200 + rust-laurel (0.6.1-1) unstable; urgency=medium * Team upload. diff --minimal -Nru rust-laurel-0.6.1/debian/control rust-laurel-0.6.1/debian/control --- rust-laurel-0.6.1/debian/control2024-04-03 17:52:57.0 +0200 +++ rust-laurel-0.6.1/debian/control2024-04-27 10:14:59.0 +0200 @@ -1,7 +1,7 @@ Source: rust-laurel Section: admin Priority: optional -Build-Depends: debhelper (>= 12), +Build-Depends: debhelper (>= 13.3), dh-cargo (>= 25), cargo:native, rustc:native (>= 1.56), @@ -36,7 +36,6 @@ librust-tinyvec-1+default-dev, librust-tinyvec-1+serde-dev, librust-toml-0.5+default-dev, - dh-sysuser, pandoc Maintainer: Debian Rust Maintainers Uploaders: diff --minimal -Nru rust-laurel-0.6.1/debian/laurel.sysuser rust-laurel-0.6.1/debian/laurel.sysuser --- rust-laurel-0.6.1/debian/laurel.sysuser 2024-04-03 17:52:57.0 +0200 +++ rust-laurel-0.6.1/debian/laurel.sysuser 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -_laurel home=/var/log/laurel diff --minimal -Nru rust-laurel-0.6.1/debian/laurel.sysusers rust-laurel-0.6.1/debian/laurel.sysusers --- rust-laurel-0.6.1/debian/laurel.sysusers1970-01-01 01:00:00.0 +0100 +++ rust-laurel-0.6.1/debian/laurel.sysusers2024-04-27 10:14:39.0 +0200 @@ -0,0 +1 @@ +u _laurel - "daemon user for laurel"/var/log/laurel /usr/sbin/nologin diff --minimal -Nru rust-laurel-0.6.1/debian/rules rust-laurel-0.6.1/debian/rules --- rust-laurel-0.6.1/debian/rules 2024-04-03 17:52:57.0 +0200 +++ rust-laurel-0.6.1/debian/rules 2024-04-27 10:15:36.0 +0200 @@ -1,6 +1,6 @@ #!/usr/bin/make -f %: - dh $@ --buildsystem cargo --with sysuser + dh $@ --buildsystem cargo override_dh_auto_build: dh_auto_build @@ -18,3 +18,7 @@ dh_install sed -i 's/usr\/local/usr/' debian/laurel/etc/audit/plugins.d/laurel.conf sed -i 's/^read-users/# read-users/' debian/laurel/etc/laurel/config.toml + +# Can be dropped in compat 14: +execute_after_dh_installinit: + dh_installsysusers
Bug#1069925: swupdate: move from dh-sysuser to standard dh_installsysusers
Source: swupdate Version: 2023.12.1+dfsg-1 Severity: wishlist Tags: patch Hi, dh-sysuser is in operation for 7 years now and has gotten 9 users - swupdate 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 --minimal -Nru swupdate-2023.12.1+dfsg/debian/changelog swupdate-2023.12.1+dfsg/debian/changelog --- swupdate-2023.12.1+dfsg/debian/changelog2024-02-13 00:12:48.0 +0100 +++ swupdate-2023.12.1+dfsg/debian/changelog2024-04-27 10:00:05.0 +0200 @@ -1,3 +1,10 @@ +swupdate (2023.12.1+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move from dh-sysuser to standard dh_installsysusers (Closes: #-1) + + -- Helmut Grohne Sat, 27 Apr 2024 10:00:05 +0200 + swupdate (2023.12.1+dfsg-1) unstable; urgency=medium * Enable new options, primarily docker support diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/control swupdate-2023.12.1+dfsg/debian/control --- swupdate-2023.12.1+dfsg/debian/control 2024-02-13 00:10:23.0 +0100 +++ swupdate-2023.12.1+dfsg/debian/control 2024-04-27 09:58:25.0 +0200 @@ -4,10 +4,10 @@ Maintainer: Bastian Germann Uploaders: SZ Lin (林上智) , Nobuhiro Iwamatsu -Build-Depends: debhelper-compat (= 13), - dh-lua:native , +Build-Depends: debhelper (>= 13.3), + debhelper-compat (= 13), + dh-sequence-lua:native , dh-nodejs | dh-nodejs:any, - dh-sysuser, graphviz , liblua5.4-dev , libfdisk-dev, diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/rules swupdate-2023.12.1+dfsg/debian/rules --- swupdate-2023.12.1+dfsg/debian/rules2024-02-13 00:10:23.0 +0100 +++ swupdate-2023.12.1+dfsg/debian/rules2024-04-27 09:59:54.0 +0200 @@ -13,7 +13,6 @@ export LUA_VERSION=5.4 export LUA_MODNAME=lua_swupdate export PKG_NAME=swupdate -export DH_WITH=,lua export HAVE_LUA=y endif @@ -95,6 +94,10 @@ override_dh_auto_install: dh_auto_install -- V=1 +# Can be dropped in compat level 14 +execute_after_dh_installinit: + dh_installsysusers + override_dh_installsystemd: dh_installsystemd --no-start dh_installsystemd --name=swupdate-progress @@ -110,4 +113,4 @@ dh_missing --fail-missing %: - dh $@ --with sysuser$(DH_WITH) + dh $@ diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/swupdate.sysuser swupdate-2023.12.1+dfsg/debian/swupdate.sysuser --- swupdate-2023.12.1+dfsg/debian/swupdate.sysuser 2024-02-13 00:10:23.0 +0100 +++ swupdate-2023.12.1+dfsg/debian/swupdate.sysuser 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -swupdate defaults diff --minimal -Nru swupdate-2023.12.1+dfsg/debian/swupdate.sysusers swupdate-2023.12.1+dfsg/debian/swupdate.sysusers --- swupdate-2023.12.1+dfsg/debian/swupdate.sysusers1970-01-01 01:00:00.0 +0100 +++ swupdate-2023.12.1+dfsg/debian/swupdate.sysusers2024-04-27 09:56:56.0 +0200 @@ -0,0 +1 @@ +u swupdate- "swupdate system user" /nonexistent /usr/sbin/nologin
