Bug#1071248: marked as pending in crowdsec-firewall-bouncer
Control: tag -1 pending Hello, Bug #1071248 in crowdsec-firewall-bouncer reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/crowdsec-firewall-bouncer/-/commit/4940f9dedffc9935cdc2efaba53138342554b056 Require golang-github-google-nftables-dev 0.1.0-4~ (#1071248, #1071247). Set minimal version for the golang-github-google-nftables-dev build dependency to ensure a working AddSet() function, i.e. no longer reversing byte order for IPv4 and IPv6 addresses at the nftables level on little-endian architectures (Closes: #1071248, See: #1071247). (this message was generated automatically) -- Greetings https://bugs.debian.org/1071248
Bug#1071247: marked as pending in golang-github-google-nftables
Control: tag -1 pending Hello, Bug #1071247 in golang-github-google-nftables reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-google-nftables/-/commit/621d27cede93c04961cc1d77c409b2eddbdc3bf8 Backport upstream fix regarding byte order (#1071247, #1071248). Backport upstream fix for the AddSet() function that's been reversing byte order on all little-endian architectures (Closes: #1071247), breaking crowdsec-firewall-bouncer (See: #1071248). (this message was generated automatically) -- Greetings https://bugs.debian.org/1071247
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Cyril Brulebois (2024-05-17): > I was tempted to open a second bug on crowdsec-firewall-bouncer, > referencing this one, and to upload both packages to unstable (this one > with the upstream patch, the other one with a bumped build-dep to make > sure it cannot be rebuilt against the broken package; there are a lot of > binNMUs flying around already). Then to submit p-u requests to get the > same updates into bookworm. But does that issue warrant a DSA? The crowdsec-firewall-bouncer bug is #1071248. The only other reverse dependency is opensnitch (maintainers Cc'd) but it doesn't seem to use the AddSet() function (in any versions/suites). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071248: crowdsec-firewall-bouncer: blocks wrong IPv4 and IPv6 addresses on LE systems (reversed byte order)
Package: crowdsec-firewall-bouncer Version: 0.0.25-3 Severity: grave Tags: patch security Justification: renders package unusable X-Debbugs-Cc: Debian Security Team , debian.pack...@crowdsec.net Hi, This is the bouncer side of #1071247: golang-github-google-nftables up to version 0.1.0-3 ships a broken AddSet() function, which results in IPv4 and IPv6 addresses to be in reverse byte order at the nftables level on LE systems (i.e. all release architectures but s930x). This issue was confirmed to go away on LE systems once the bouncer gets rebuilt against a fixed golang-github-google-nftables-dev package, and not to regress on BE systems. Grave looks warranted as the package doesn't fulfill its purposes (blocking suspicious addresses), giving a false sense of security… while also blocking potentially harmless addresses. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Control: found -1 0.1.0-3 Control: notfound -1 0.1.0-4 Cyril Brulebois (2024-05-17): > Package: golang-github-google-nftables-dev > Version: 0.1.0-4 > I also verified that applying the golang-github-google-nftables patch > and rebuilding crowdsec-firewall-bouncer against it fixes the problem > on LE systems, and doesn't regress on BE systems. Sorry for the version discrepancy; reportbug warned me but I lost track while thinking about a possible DSA, etc. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Package: golang-github-google-nftables-dev Version: 0.1.0-4 Severity: serious Tags: upstream security patch Justification: broken feature, security implications X-Debbugs-Cc: Debian Security Team , debian.pack...@crowdsec.net Hi, I was contacted by CrowdSec upstream about a bug report filed against the firewall bouncer, which is in charge of applying rules at the firewall level based on decisions passed on by the crowdsec engine: https://github.com/crowdsecurity/cs-firewall-bouncer/issues/368 I've been able to verify that despite correct IPv4 and IPv6 addresses getting logged by the bouncer (e.g. at debug level), all of them get added in reverse byte order at the nftables level. :( Upstream bug: https://github.com/google/nftables/issues/225 Upstream fix: https://github.com/google/nftables/pull/226 I confirmed that affects LE systems (e.g. amd64), both in stable and in unstable (same versions, modulo binNMUs). That doesn't affect BE systems (i.e. s390x, verified via debvm). I also verified that applying the golang-github-google-nftables patch and rebuilding crowdsec-firewall-bouncer against it fixes the problem on LE systems, and doesn't regress on BE systems. Security team, I've added the security tag (and you to Cc) because the consequence is that admins who installed crowdsec-firewall-bouncer have been thinking they were applying restrictions gathered by crowdsec, while they've actually been (1) not blocking offending addresses and (2) blocking possibly harmless ones. I was tempted to open a second bug on crowdsec-firewall-bouncer, referencing this one, and to upload both packages to unstable (this one with the upstream patch, the other one with a bumped build-dep to make sure it cannot be rebuilt against the broken package; there are a lot of binNMUs flying around already). Then to submit p-u requests to get the same updates into bookworm. But does that issue warrant a DSA? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1068755: docker.io: FTBFS: failing tests
Hi Santiago, And thanks for the report. Santiago Vila (2024-04-10): > Package: src:docker.io > Version: 20.10.25+dfsg1-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: > > === FAIL: distribution/xfer > TestMaxDownloadAttempts/max-attempts=5,_fail_at_6th_attempt (0.88s) > time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (2/5): > simulating download attempt 2/2" > time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (1/5): > simulating download attempt 1/6" > download_test.go:425: assertion failed: expected error "simulating > download attempt 5/6", got "simulating download attempt 6/6" > time="2024-04-10T10:28:42Z" level=info msg="Download failed, retrying (5/5): > simulating download attempt 5/5" > > === FAIL: distribution/xfer TestMaxDownloadAttempts (0.00s) That FTBFS is easily reproducible via cowbuilder (sid, amd64), and also within an unclean, up-to-date devel schroot (still sid, amd64). I'm adding Tianon to the loop explicitly since I'm definitely no Docker (or Go) expert, in case some time can be spared to look into this problem. Otherwise I'll try and come up with something. Thanks for considering! Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Marco d'Itri (2024-04-26): > On Apr 26, Michael Tokarev wrote: > > > So, should I disable module utils in busybox-udeb now? > I think so. I haven't gotten any requests / seen any reasons to keep it; so, yes, please feel free to remove it whenever is convenient for you. > > Is kmod udeb ready and used in d-i already, or does it need some > > prep first? > AFAIK it works. Absolutely, that's been working since the small xz-utils tweak (the udeb addition, not the backdoor thing). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1066071: mtdev: broken shlibs, leading to uninstallable udebs
Hi, Cyril Brulebois (2024-03-12): > Your NMU broke this package's shlibs. > > Before: > > libmtdev 1 libmtdev1 > udeb: libmtdev 1 libmtdev1-udeb > > After: > > libmtdev 1 libmtdev1t64 > > At the moment, at least the following package is broken: > > The following packages have unmet dependencies: > libinput10-udeb : Depends: libmtdev1t64 but it is not installable No response in 1+ month, the package isn't ready to migrate anyway since it's waiting on dpkg but also regressing on 32-bit arms. Source debdiff attached for the NMU, which I've verified to generate appropriate shlibs, leading a rebuilt src:libinput10 to have appropriate dependencies as far as libinput10-udeb is concerned. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru mtdev-1.1.6/debian/changelog mtdev-1.1.6/debian/changelog --- mtdev-1.1.6/debian/changelog 2024-02-28 21:51:50.0 +0100 +++ mtdev-1.1.6/debian/changelog 2024-04-15 09:51:44.0 +0200 @@ -1,3 +1,12 @@ +mtdev (1.1.6-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix shlibs entry for the udeb: set DEB_DH_MAKESHLIBS_ARGS_libmtdev1t64 +instead of setting DEB_DH_MAKESHLIBS_ARGS_libmtdev1, to match the + rename of the library (Closes: #1066071). + + -- Cyril Brulebois Mon, 15 Apr 2024 09:51:44 +0200 + mtdev (1.1.6-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru mtdev-1.1.6/debian/rules mtdev-1.1.6/debian/rules --- mtdev-1.1.6/debian/rules 2020-05-24 06:38:08.0 +0200 +++ mtdev-1.1.6/debian/rules 2024-04-15 09:50:23.0 +0200 @@ -9,7 +9,7 @@ distribution := $(shell lsb_release -is) LDFLAGS += -Wl,-z,defs -Wl,--as-needed -DEB_DH_MAKESHLIBS_ARGS_libmtdev1 = --add-udeb=libmtdev1-udeb +DEB_DH_MAKESHLIBS_ARGS_libmtdev1t64 = --add-udeb=libmtdev1-udeb DEB_INSTALL_MANPAGES_mtdev-tools = debian/mtdev-test.1 signature.asc Description: PGP signature
Bug#1066479: closed by Debian FTP Masters (reply to Cyril Brulebois ) (Bug#1066479: fixed in opendnssec 1:2.1.13-1.1)
Debian Bug Tracking System (2024-03-28): > opendnssec (1:2.1.13-1.1) unstable; urgency=medium > . >* Non-maintainer upload. >* Fix FTBFS due to missing utilities.h include for the clamp declaration > (Closes: #1066479): 0018-fix-missing-include.patch This hasn't reached testing yet because of various transitions. Pinging this bug report to avoid having packages removed from testing, including reverse dependencies, as dpkg itself hasn't migrated either. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Hi, Marco d'Itri (2024-04-09): > Yes. Nowadays kmod has many more features related to compressed modules > and verification of signatures. > Can we agree that kmod should provide these programs for d-i? > Or can the d-i maintainers just tell us what they want? I meant to come back to this after experimenting, then things happened… I picked kmod at the time because it worked, and because busybox didn't work, which I summed up in: https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145 (plus follow-up commit, woopsie https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07 ) I'm fine with sticking to kmod regarding module support in d-i. I'm not sure we should keep support in two different modules, so dropping it from busybox would work for me. Others might have different views on this, though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068197: debian-installer: accesses the internet during build
[ Switching from ML to bug. ] Hi Jonathan, Jonathan Carter (2024-04-01): > On 2024/04/01 18:55, Aurelien Jarno wrote: > > debian-installer attemps network access during build, although only to > > the mirrors listed in /etc/apt/sources.list and in a secure way. This is > > forbidden by Policy 4.9: > > > >For packages in the main archive, required targets must not attempt > >network access, except, via the loopback interface, to services on the > >build host that have been started by the build. > > > > In addition this brings constraints to the build daemons infrastructure. > > As far as I know, this doesn't happen until after d-i asked the question "Do > you want to use a network mirror?" and the user answered "Yes", in which > case I think that would count as informed consent. This isn't about d-i runtime, this is about src:debian-installer's *build* requiring network access, which is a very well known problem (even though there are no obvious solutions, at least that I'm aware of), and that's now getting in the way of changes being considered regarding the buildd network. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1066479: opendnssec: FTBFS: ../../common/scheduler/task.c:137:25: error: implicit declaration of function ‘clamp’ [-Werror=implicit-function-declaration]
Control: tag -1 patch pending Lucas Nussbaum (2024-03-13): > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration > > Relevant part (hopefully): > > ../../common/scheduler/task.c: In function ‘task_perform’: > > ../../common/scheduler/task.c:137:25: error: implicit declaration of > > function ‘clamp’ [-Werror=implicit-function-declaration] > > 137 | task->backoff = clamp(task->backoff * 2, 60, > > ODS_SE_MAX_BACKOFF); > > | ^ > > cc1: some warnings being treated as errors > > make[4]: *** [Makefile:601: scheduler/task.o] Error 1 I thought there would be several things but apparently that's just the one. A quick look upstream shows there are more PRs and more fixups needed for even newer compilers, but I'm limiting my patch to the bare minimum. Since that's been open for 10+ days, and since reverse dependencies could get kicked out of testing, I'm uploading an NMU right now so that I don't forget, but to DELAYED/2 so there's some room to do things differently if desired. I'm happy to reschedule/cancel if needed. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ diff -Nru opendnssec-2.1.13/debian/changelog opendnssec-2.1.13/debian/changelog --- opendnssec-2.1.13/debian/changelog 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/changelog 2024-03-26 14:27:44.0 +0100 @@ -1,3 +1,11 @@ +opendnssec (1:2.1.13-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS due to missing utilities.h include for the clamp declaration +(Closes: #1066479): 0018-fix-missing-include.patch + + -- Cyril Brulebois Tue, 26 Mar 2024 14:27:44 +0100 + opendnssec (1:2.1.13-1) unstable; urgency=medium * New upstream version 2.1.13 diff -Nru opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch --- opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 1970-01-01 01:00:00.0 +0100 +++ opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 2024-03-26 14:23:18.0 +0100 @@ -0,0 +1,10 @@ +--- a/common/scheduler/task.c b/common/scheduler/task.c +@@ -41,6 +41,7 @@ + #include "file.h" + #include "util.h" + #include "log.h" ++#include "utilities.h" + + static const char* task_str = "task"; + static pthread_mutex_t worklock = PTHREAD_MUTEX_INITIALIZER; diff -Nru opendnssec-2.1.13/debian/patches/series opendnssec-2.1.13/debian/patches/series --- opendnssec-2.1.13/debian/patches/series 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/patches/series 2024-03-26 14:27:32.0 +0100 @@ -8,3 +8,4 @@ 0015-remove-strptime-build-warning.patch 0016-m4-acx_libxml2.m4-use-pkg-config-instead-of-xml2-con.patch 0017-mysql8_my_bool.patch +0018-fix-missing-include.patch signature.asc Description: PGP signature
Bug#1066778: golang-github-containerd-go-runc: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/containerd/go-runc returned exit code 1
Shengjing Zhu (2024-03-14): > On Wed, Mar 13, 2024 at 11:05 PM Lucas Nussbaum wrote: > > > console_test.go:42: mkdir /tmp/foo: not a directory > > > --- FAIL: TestTempConsoleWithXdgRuntimeDir (0.00s) > > I wonder if your chroot doesn't have the /tmp directory? Writing to hardcoded paths under /tmp has never been a good idea in the first place. Alright, this is a test suite but we're not usually trying to write outside the build directory. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: marked as pending in crowdsec
Control: tag -1 pending Hello, Bug #1057549 in crowdsec reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/crowdsec/-/commit/b2beee2140e7cdb9d4732c4e48a568fce70248ee Fix missing build-dependency on passwd (Closes: #1057549). Thanks to Santiago Vila for the bug report and the analysis. (this message was generated automatically) -- Greetings https://bugs.debian.org/1057549
Bug#1060915: golang-entgo-ent: Flaky tests due to relying on default result ordering
Hi Paul, Paul Mars (2024-01-16): > Here is a patch to fix the issue. Sorry, I didn't spot this bug report right away (its metadata got adjusted along the way). Thanks for the bug report and the patch, on their way to unstable! Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1066074: ntfs-3g: broken shlibs (deb and udeb)
Source: ntfs-3g
Version: 1:2022.10.3-1.1
Severity: serious
Tags: d-i
Justification: broken shlibs
X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung
Hi,
Here's what debian/libntfs-3g89t64/DEBIAN/shlibs looks like after
a build:
libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 libntfs-3g89
That doesn't match binaries shipped by the source package.
See debian/rules:
SONAME = $(shell objdump -p debian/tmp/lib/*/libntfs-3g.so.*.* | awk -Fso.
'/SONAME/ { print $$2 }')
[…]
override_dh_makeshlibs:
dh_makeshlibs --add-udeb=ntfs-3g-udeb -Vlibntfs-3g$(SONAME)
In the previous version we had:
libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 ntfs-3g-udeb
Adding 't64' at the end of the dh_makeshlibs line quoted above gives:
libntfs-3g 89 libntfs-3g89t64
udeb: libntfs-3g 89 ntfs-3g-udeb
which certainly looks much better. I haven't performed any rebuild test
for the reverse dependencies of the library, nor runtime tests on the
d-i side (other packages are broken right now). The Depends field of
the udeb looks correct now though:
-Depends: libc6-udeb (>= 2.37), libntfs-3g89, fuse3-udeb
+Depends: libc6-udeb (>= 2.37), fuse3-udeb
I'll leave it up to the 64-bit time_t transition drivers to choose how
to address this issue (add t64 on the SONAME line, or just in the
dh_makeshlibs override, or something else), and to track down packages
that might have been rebuilt against the broken library.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Bug#1066071: mtdev: broken shlibs, leading to uninstallable udebs
Source: mtdev Version: 1.1.6-1.1 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung Hi, Your NMU broke this package's shlibs. Before: libmtdev 1 libmtdev1 udeb: libmtdev 1 libmtdev1-udeb After: libmtdev 1 libmtdev1t64 At the moment, at least the following package is broken: The following packages have unmet dependencies: libinput10-udeb : Depends: libmtdev1t64 but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1066070: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable
Source: libpng1.6 Version: 1.6.43-3 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org Hi, Your debian/rules includes this: override_dh_makeshlibs: dh_makeshlibs --add-udeb=libpng16-16-udeb -a and that's indeed the package that's listed in debian/control. However, debian/libpng16-16t64.shlibs has it wrong: libpng16 16 libpng16-16t64 (>= 1.6.2) udeb: libpng16 16 libpng16-udeb (>= 1.6.2) At this point, that breaks at least: The following packages have unmet dependencies: libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1066069: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable
Source: libpng1.6 Version: 1.6.43-3 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org Hi, Your debian/rules includes this: override_dh_makeshlibs: dh_makeshlibs --add-udeb=libpng16-16-udeb -a and that's indeed the package that's listed in debian/control. However, debian/libpng16-16t64.shlibs has it wrong: libpng16 16 libpng16-16t64 (>= 1.6.2) udeb: libpng16 16 libpng16-udeb (>= 1.6.2) At this point, that breaks at least: The following packages have unmet dependencies: libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Santiago Vila (2024-03-06): > I looked at the build log and found the problem: The package has a missing > build-depends on passwd, which is no longer build-essential in trixie/sid. Alright, that's the kind of thing I had in mind initially but I'm pretty sure one of the attempt to reproduce started with a brand new build chroot… Oh well. > I am a member of Debian Go (joined to do QA stuff). > Would it help if I fix this myself by doing a "Team Upload"? Thanks for the offer, but I do have another related FTBFS on my plate (even if it was misfiled in the first place), so I'll probably lump up both uploads together. :) Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Cyril Brulebois (2024-02-15): > Is that problem still current? I cannot reproduce it with a brand new > sid environment, freshly created via either `pbuilder --create` or > `sbuild-createchroot`. For the record, I did receive a proposal to get access to such a system back then (thanks!), but I couldn't get to it just yet. Not sure about this though, received today (2024-03-06) for 3 packages: crowdsec 1.4.6-6 is marked for autoremoval from testing on 2024-03-05 Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Hi, Cyril Brulebois (2024-01-17): > Santiago Vila (2023-12-05): > > […] > > Thanks for the report. The relevant part didn't appear in the excerpt > so I'm quoting the full build log below: > > > === RUN TestOneShot/permission_denied > > file_test.go:234: > > Error Trace: > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:25 > > > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/file/file_test.go:234 > > Error: An error is expected but got nil. > > Test: TestOneShot/permission_denied > > === RUN TestOneShot/ignored_directory > > === RUN TestOneShot/glob_syntax_error > > === RUN TestOneShot/no_matching_files > > === RUN TestOneShot/test.log > > === RUN TestOneShot/test.log.gz > > === RUN TestOneShot/unexpected_end_of_gzip_stream > > === RUN TestOneShot/deleted_file > > --- FAIL: TestOneShot (0.00s) > > --- FAIL: TestOneShot/permission_denied (0.00s) > > --- PASS: TestOneShot/ignored_directory (0.00s) > > --- PASS: TestOneShot/glob_syntax_error (0.00s) > > --- PASS: TestOneShot/no_matching_files (0.00s) > > --- PASS: TestOneShot/test.log (0.00s) > > --- PASS: TestOneShot/test.log.gz (0.00s) > > --- PASS: TestOneShot/unexpected_end_of_gzip_stream (0.00s) > > --- PASS: TestOneShot/deleted_file (0.00s) Is that problem still current? I cannot reproduce it with a brand new sid environment, freshly created via either `pbuilder --create` or `sbuild-createchroot`. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Hi Santiago, Santiago Vila (2023-12-05): > […] Thanks for the report. The relevant part didn't appear in the excerpt so I'm quoting the full build log below: > === RUN TestOneShot/permission_denied > file_test.go:234: > Error Trace: > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:25 > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/file/file_test.go:234 > Error: An error is expected but got nil. > Test: TestOneShot/permission_denied > === RUN TestOneShot/ignored_directory > === RUN TestOneShot/glob_syntax_error > === RUN TestOneShot/no_matching_files > === RUN TestOneShot/test.log > === RUN TestOneShot/test.log.gz > === RUN TestOneShot/unexpected_end_of_gzip_stream > === RUN TestOneShot/deleted_file > --- FAIL: TestOneShot (0.00s) > --- FAIL: TestOneShot/permission_denied (0.00s) > --- PASS: TestOneShot/ignored_directory (0.00s) > --- PASS: TestOneShot/glob_syntax_error (0.00s) > --- PASS: TestOneShot/no_matching_files (0.00s) > --- PASS: TestOneShot/test.log (0.00s) > --- PASS: TestOneShot/test.log.gz (0.00s) > --- PASS: TestOneShot/unexpected_end_of_gzip_stream (0.00s) > --- PASS: TestOneShot/deleted_file (0.00s) I'll investigate shortly. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Julian Andres Klode (2023-12-25): > We picked the previous XFS patch for extent parsing but did not pick > this one because it had not been merged at that point yet, the fix > only got merged two weeks or so ago, and we didn't want to take chances > and pick it ahead of time as it's security critical code (filesystem > parsing is where all the security bugs live!). > > The release was supposed to be out 2 weeks ago but got pushed back > another week to last week's release, sadly. Thanks for all the details, and sorry if it appeared I was chasing you down; I just stumbled upon this again while re-testing various things, and was merely wondering whether things were. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Julian Andres Klode (2023-12-25): > The final grub 2.12 that includes the fix should hit unstable in the > middle of January. As you might be aware many are busy with family > stuff and holiday celebrations right now. Sure. I wasn't aware an upstream release was in the pipes, only that patches have existed and been confirmed OK for close to 2 months. > As always though it stands to reason that this is a change that should > (have been) reverted in xfsprogs first until a grub that understands > it has been released in a stable point release such that you can use a > stable grub to inspect an XFS filesystem created by a trixie xfsprogs. The more we tick boxes in the compatibility matrix, the happier, yes. > It seems the bug has been wrongly reassigned instead of being cloned > and reassigned, so I'm cloning it back to xfsprogs. Right, this would have been easier to track if debian-boot@ had been put (and kept) in the loop all along. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Hi,
Anthony Iliopoulos (2023-10-30):
> On Mon, Oct 30, 2023 at 04:19:32PM +0100, Philip Hands wrote:
> > Anthony Iliopoulos writes:
> >
> > > On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
> > ...
> > >> error: invalid XFS directory entry.
> > ...
> > > This issue exists independently of the large extent counter, and it is
> > > related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> > > fuzzing the XFS filesystem"). That's actually the issue described in
> > > #1051543.
> >
> > Ah, yes -- good point.
> >
> > > There's a proposed fix at [1], and it works as expected with that patch
> > > applied.
> > ...
> > > [1]
> > > https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
> >
> > I can confirm that having applied both patches:
> >
> > https://salsa.debian.org/philh/grub2/-/pipelines/596346
> >
> > it now succeeds at both installing grub, and then booting the system:
> >
> > https://openqa.debian.net/tests/200503#details
>
> Thanks for confirming, perhaps then you can add your tested-by in the
> respective patches upstream.
>
> BTW, another handy way to test if this works is via grub-mount.
Any chance we could have an updated grub2 package to fix this?
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1055107: crowdsec fails its autopkgtests on armel
Control: severity -1 important Cyril Brulebois (2023-10-31): > Nilesh Patra (2023-10-31): > > Since this means it is a flaky test and a recurring problem, would it > > make sense to skip those tests to save some cycles for debci? > > I didn't say I was certain, quite the opposite. > > > I had triggered it - we will see if it fixes itself. > > Looking at https://ci.debian.net/packages/c/crowdsec/testing/armel/ > it succeeded, 4 times in a row, within 2 minutes… Downgrading severity as this isn't actually blocking any packages. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1056018: partman-base: parted_devices hangs with process in D state during Debian installer Detect Disks step
Control: severity -1 important Hi, Olivier F. R. Dierick (2023-11-16): > Justification: breaks the whole system Not being able to install doesn't “break the whole system”. This is a showstopper in the installation process in your case indeed, but that's not what this severity is for. > Updating from Debian 8 to Debian 12 from an USB stick. Maybe check the image was correctly written on your USB stick? A number of weird issues like that one are linked to hardware faults or similar issues. >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Ineffective: Tried disconnecting external disks & USB storage HUB, and > switching SATA setting from AHCI to IDE in BIOS. > Also tried expert mode & text mode. > >* What was the outcome of this action? > > Debian Installer is stuck on Detect Disks. > Switching to a console and running ps shows that a parted_devices > process is in D state. Anything in dmesg or /var/log/syslog? It might be interesting to see what happens with 12.0 images (in case something interesting happened in the kernel, but such a hard failure seems rather strange), and maybe try your luck with some Debian Live image? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1037478: ca-certificates-java: Loop in the execution of the trigger
Hi, Matthias Klose (2023-07-12): > Version: 20230710 > > Fixed now. Thanks for the bugfix. This is a serious issue that still affects at least bookworm (I didn't check bullseye): applying the update published as DSA-5548-1 makes dpkg error out. Cc-ing the security team accordingly. On a bookworm system (freshly deployed and without any weird things done package-wise) that had openjdk-17-jre-headless installed, upgrading it to the version that's available in bullseye-security triggered the dpkg trigger loop. Thankfully that's easily recoverable (e.g. by running `dpkg --configure -a`, even if there might be better ways to do so), but that's still something I believe shouldn't be happening on stable systems with just the matching stable-security suite enabled. This issue is trivially reproducible there by switching back and forth between bookworm's version and bookworm-security's. Setting some debug level in dpkg, I'm getting the attached log for one of those runs. apt-get install -o dpkg::options::=-D7 openjdk-17-jre-headless/bookworm apt-get install -o dpkg::options::=-D7 openjdk-17-jre-headless/bookworm-security → ca-certificates-java-full-debug.txt At the time of writing, that means switching between 17.0.8+7-1~deb12u1 and 17.0.9+9-1~deb12u1. Checking whether this was possibly a problem with that particular system, I tried reproducing the issue with openjdk-17-jre-headless in a bookworm chroot, but I wasn't successful. Installing openjdk-17-jre makes it possible to reproduce the issue though. Shell script to reproduce (adjust DST=/tmp/bookworm if needed): → repro-1037478.sh I'm attaching the log for the failed upgrade, again with dpkg debug: → repro-1037478.log I've verified in both cases (real baremetal system and repro chroot) that installing ca-certificates-java 20230710 beforehand indeed makes the problem disappear. Since this release is a fixup for the previous release which was mainly aimed at fixing this particular issue, I suppose it would make sense to investigate whether something like 20230710~deb12u1 would be appropriate for bookworm-proposed-updates? (And maybe bullseye-proposed-updates, but again, I didn't check the bullseye part.) Thanks for considering. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ root@baremetal:~# apt-get install -o dpkg::options::=-D7 openjdk-17-jre-headless/bookworm-security … Selected version '17.0.9+9-1~deb12u1' for 'openjdk-17-jre-headless' … The following packages will be upgraded: openjdk-17-jre-headless 1 upgraded, 0 newly installed, 0 to remove and 284 not upgraded. Need to get 0 B/43.7 MB of archives. After this operation, 487 kB disk space will be freed. (Reading database ... 30411 files and directories currently installed.) Preparing to unpack .../openjdk-17-jre-headless_17.0.9+9-1~deb12u1_amd64.deb ... D02: trigproc_activate_packageprocessing pkg=openjdk-17-jre-headless:amd64 D02: post_script_tasks - ensure_diversions D02: post_script_tasks - trig_incorporate Unpacking openjdk-17-jre-headless:amd64 (17.0.9+9-1~deb12u1) over (17.0.8+7-1~deb12u1) ... D02: post_script_tasks - ensure_diversions D02: post_script_tasks - trig_incorporate D01: trigproc_run_deferred Setting up openjdk-17-jre-headless:amd64 (17.0.9+9-1~deb12u1) ... D02: trigproc_activate_packageprocessing pkg=openjdk-17-jre-headless:amd64 Installing new version of config file /etc/java-17-openjdk/security/public_suffix_list.dat ... D02: post_postinst_tasks - trig_incorporate D01: trigproc_run_deferred D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: check_triggers_cycle pnow=ca-certificates-java:all D02: check_triggers_cycle pnow=ca-certificates-java:all first D01: trigproc ca-certificates-java:all D01: check_triggers_cycle pnow=ca-certificates-java:all D02: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java D02: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=/usr/lib/jvm D04: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=/usr/lib/jvm haretrig=/usr/lib/jvm D02: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java D04: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java haretrig=/usr/lib/jvm D04: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java haretr
Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
ilf (2023-11-15): > reopen 1055901 > found 1055901 1:1.20231024+ds-1+rpt2 > > This seems to hit everyone with a Rasperry Pi who upgraded > Debian/Raspian from bullseye to bookworm. If a Raspbian package doesn't work on Raspbian systems, is the Debian bug tracking system really the best place? Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
Hi, Hilmar Preusse (2023-11-13): > Package: raspi-firmware > Version: 1:1.20231024+ds-1+rpt1 > Severity: serious > Justification: Policy 6.4 > > Hello, > > the package fails to install on my system. I simply assumes that > /boot/firmware is a > mount point and fails if this is not the case. If /boot/firmware is expected > to be a > mount point the installer should have created it. The system was once > installed as > bullseye and later upgraded to bookworm. What exactly is your system? What is that rpt suffix? > Versions of packages raspi-firmware suggests: > ii bluez-firmware 1.2-9+rpt2 > ii firmware-brcm80211 1:20230210-5+rpt1 > ii firmware-misc-nonfree 1:20230210-5+rpt1 Here too. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054437: golang-ariga-atlas: website is build with Docusaurus not packaged for debian
Hi Bastien, Bastien Roucariès (2023-10-23): > Source: golang-ariga-atlas > Version: 0.7.2-2 > Severity: serious > Tags: ftbfs > Justification: FTBFS This doesn't make any sense. > Control: block -1 by 1054426 > > Dear Maintainer, > > The documentation is build with docusaurus. > > See website directory > https://sources.debian.org/src/golang-ariga-atlas/0.7.2-2/doc/website/ > > You should repack or package docusaurus and rebuild You're filing a serious bug report claiming this is about a failure to build from source, then mention repacking, without describing any actual issues. Please be more considerate when filing serious bug reports. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054438: golang-entgo-ent: website is build with Docusaurus not packaged for debian
Bastien Roucariès (2023-10-23): > Source: golang-entgo-ent > Version: 0.11.3-4 > Severity: serious > Tags: ftbfs > Justification: FTBFS > Control: block -1 by 1054426 > > Dear Maintainer, > > The documentation is build with docusaurus. > > See website directory > https://sources.debian.org/data/main/g/golang-entgo-ent/0.11.3-4/doc/website > > You should repack or package docusaurus and rebuild That's bug report number 3 without any details… -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055107: crowdsec fails its autopkgtests on armel
Nilesh Patra (2023-10-31): > Since this means it is a flaky test and a recurring problem, would it > make sense to skip those tests to save some cycles for debci? I didn't say I was certain, quite the opposite. > I had triggered it - we will see if it fixes itself. Looking at https://ci.debian.net/packages/c/crowdsec/testing/armel/ it succeeded, 4 times in a row, within 2 minutes… Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055107: crowdsec fails its autopkgtests on armel
Hi, Nilesh Patra (2023-10-31): > On Tue, 31 Oct 2023 20:13:23 +0530 Nilesh Patra wrote: > Full log at: > https://ci.debian.net/data/autopkgtest/testing/armel/c/crowdsec/39385596/log.gz > > > This is currently blocking golang-github-gin-gonic-gin to testing which > > fixes a bunch of RC bugs (of same kind). I think we've had this issue showing up in a few cases (on other archs though), but I wasn't able to replicate it, possibly timing issues or something similar. I'd suggest a retry if that wasn't attempted already. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054444: golang-github-facebook-ent: website is build with Docusaurus not packaged for debian
Hi Bastien, Bastien Roucariès (2023-10-23): > Source: golang-github-facebook-ent > Version: 0.5.4-3 > Severity: serious > Tags: ftbfs > Justification: FTBFS > Control: block -1 by 1054426 > > Dear Maintainer, > > The documentation is build with docusaurus. > > See website directory > https://sources.debian.org/src/golang-github-facebook-ent/0.5.4-3/doc/website/ > > You should repack or package docusaurus and rebuild Please describe the actual problem you're seeing. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1050523: dh-make-golang: fails to determine dependencies
Hi, Daniel Swarbrick (2023-08-25): > On 25.08.23 19:40, Mathias Gibbens wrote: > >Something has changed in sid's golang environment since August 4 > > which is causing dh-make-golang to fail to determine a package's > > dependencies and generate a correct d/control. For example, this worked > > fine on August 4 but now fails: > > It's probably also worth noting that dh-make-golang is now FTBFS (#1043070) > due to golang.org/x/tools/go/vcs having been deprecated and removed from > golang-golang-x-tools-dev as of version 0.11.0. I had an unstable schroot lagging behind. Upgrading the following packages didn't change dh-make-golang's output regarding dependencies: $ sudo apt-get install golang-golang-x-tools-dev […] The following additional packages will be installed: golang-golang-x-mod-dev golang-golang-x-tools The following packages will be upgraded: golang-golang-x-mod-dev golang-golang-x-tools golang-golang-x-tools-dev But this did: $ sudo apt-get install golang […] The following additional packages will be installed: golang-1.21 golang-1.21-doc golang-1.21-go golang-1.21-src golang-any golang-doc golang-go golang-src The following NEW packages will be installed: golang golang-1.21 golang-1.21-doc golang-1.21-go golang-1.21-src The following packages will be upgraded: golang-any golang-doc golang-go golang-src 4 upgraded, 5 newly installed, 0 to remove and 355 not upgraded. Given the error messages it looks like there are only two paths considered each time, one within the build tree, the other one being under /usr/lib/go-1.21; and since many packages (a very superficial search suggests 2048) ship stuff under /usr/share/gocode/src, that can't work? Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1050336: libnet-xmpp-perl: unable to StartTLS, without any feedback
Package: libnet-xmpp-perl
Version: 1.05-1.1
Severity: serious
Justification: cannot perform basic authentication
Hi,
I have a few scripts around that use Net::XMPP to send notifications
when this or that happens, and all of them broke after upgrading from
bullseye to bookworm. This is definitely not related to changes on the
server side (which I control and didn't change), and other existing
hosts still on bullseye still work fine.
The error manifests itself like this:
AuthIQAuth requires a resource arguement at /local/wrapper.pm line 42.
Tracking it down, it appears AuthSend uses AuthSASL on bullseye (OK)
and AuthIQAuth on bookworm (KO). The latter is the fallback:
,---[ Net/XMPP/Protocol.pm ]---
| sub AuthSend
| {
[…]
| if($self->{STREAM}->GetStreamFeature($self->GetStreamID(),"xmpp-sasl"))
| {
| return $self->AuthSASL(%args);
| }
| return $self->AuthIQAuth(%args);
| }
`---
The GetStreamID isn't happy because it tries to pick the ID part of the
SESSION, which is missing.
Diving into the connection implementation, I managed to confirm that the
connection is established at first, giving me a $self->{SESSION} set,
but that goes away later on:
,---[ Net/XMPP/Connection.pm ]---
| sub Connect
| {
| if ($self->{SESSION})
| {
| $self->{DEBUG}->Log1("Connect: connection made");
|
| my $weak = $self;
| weaken $weak;
| $self->{STREAM}->SetCallBacks(node=>sub{ $weak->CallBack(@_) });
| $self->{CONNECTED} = 1;
| $self->{RECONNECTING} = 0;
|
| if (exists($self->{SESSION}->{version}) &&
| ($self->{SESSION}->{version} ne ""))
| {
| my $tls = $self->GetStreamFeature("xmpp-tls");
| if (defined($tls) && $self->{SERVER}->{tls})
| {
| $self->{SESSION} =
| $self->{STREAM}->StartTLS(
| $self->{SESSION}->{id},
| $self->{SERVER}->{timeout},
| );
Here be dragons.
| }
| elsif (defined($tls) && ($tls eq "required"))
| {
| $self->SetErrorCode("The server requires us to use TLS, but
you did not specify that\nTLS was an option.");
| return;
| }
| }
|
| return 1;
| }
| else
| {
| $self->SetErrorCode($self->{STREAM}->GetErrorCode());
| return;
| }
`---
I also confirmed (yay for print-debugging) that the xmpp-tls branch is
entered, the StartTLS() fails for some reason (or at least returns
nothing at all), and $self->{SESSION} gets reset. The rest explodes.
There are only minor differences between the package in bullseye and
bookworm (mostly packaging metadata), so it looks to me something
external (undetermined at the moment) triggered this problem during
the upgrade. I thought I'd file my findings then think a little more
about a game plan.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Bug#1040976: crowdsec: only looks at traditional log files
Package: crowdsec Version: 1.4.6-4 Severity: serious Justification: maintainer/upstream's judgement Hi, One critical thing that was missed during the bookworm release cycle is that crowdsec's default configuration only checks traditional log files. In particular: /var/log/auth.log to detect failed SSH logins. That was fine in Debian 11, but with rsyslog's Priority being lowered from important to optional in Debian 12, the traditional log files are no longer produced and we're lacking detection. :/ There are two things to consider here to provide a fix: - We could try and enable the journalctl datasource selectively, but since we're shipping the default config file marked conffiles, that is likely to trigger prompting users during upgrades, so that doesn't look too appealing. If we *don't* do that though, crowdsec's current version would fail to initialize the journalctl datasource if journald isn't available, and would error out. - So the current plan is to apply two changes: one updating the default config file, and one adjusting crowdsec's behaviour when it comes to unavailable datasources: logging and continuing instead of failing. Upstream has: - https://github.com/crowdsecurity/crowdsec/pull/2316 to update the config file. - https://github.com/crowdsecurity/crowdsec/commit/a910b7becad1e06cb460949ab448d3172eb5679f to make sure the engine doesn't fail with an unavailable datasource. The second one comes with a slight behavorial change: crowdsec now errors out if there's no valid datasources. That seems way better than running with a broken config though. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
Hi Michael, Cyril Brulebois (2023-06-28): > Control: reassign -1 busybox-udeb 1:1.36.1-3 […] > With a local build, confirmed -3 is buggy, and that reverting only > busybox-udeb to -1 is sufficient to restore syslog support in the > installer. > > Reassigning there; the GRUB thing can be filed separately once we have > actual information via syslog. A fix would be appreciated, we've got reports piling up about things we have no logs for. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#852964: golang-github-hashicorp-yamux: FTBFS randomly (failing tests)
Hi, Paul Gevers (2023-06-22): > I'm seeing flaky tests on ci.debian.net too [1]. Because the > unstable-to-testing migration software now blocks on regressions in testing, > flaky tests, i.e. tests that flip between passing and failing without > changes to the list of installed packages, are causing people unrelated to > your package to spend time on these tests. Therefor the Release Team > considers the issue of serious severity. > > Paul > > [1] https://ci.debian.net/packages/g/golang-github-hashicorp-yamux/ I've encountered this a few times already but got told on #debci that there were no problems at all… Right now, that page only lists 0.0+git20190923.df201c7-1 for release architectures in unstable (0.0+git20210316.a95892c-2 for riscv64 only) while that upload happened 20+ days ago. Clicking a random arch (amd64) gives me a huge list of tests for that version, the last one having run on 2023-06-05. This makes no sense to me. This also means that the two archs where the failures seem to happen (armel and armhf) have logs for failed tests with an obsolete version. That doesn't quite help. Migration to testing happened 2023-06-17, and yet the testing column has a mix of both versions. This makes no sense to me either. At least, there, we have logs for failed tests for the most recent version… At the moment, I have only been able to produce a single occurrence of a different problem: === RUN TestGoAway session_test.go:536: err: 2023/07/03 02:33:15 [WARN] yamux: frame for missing stream: Vsn:0 Type:1 Flags:1 StreamID:1 Length:0 2023/07/03 02:33:15 [ERR] yamux: Failed to write header: io: read/write on closed pipe --- FAIL: TestGoAway (0.00s) Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1040048: debian-installer-utils: FTBFS: "vt102-di", line 3, terminal 'vt102': /sbuild-nonexistent/.terminfo: permission denied (errno 2)
Hi Sven, Sven Joachim (2023-07-01): > See the attached patch for a fix which works with both old and new > ncurses-base versions. Uploaded, thanks! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1040048: marked as pending in debian-installer-utils
Control: tag -1 pending Hello, Bug #1040048 in debian-installer-utils reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/installer-team/debian-installer-utils/-/commit/18d772d172963506e42442c8d5e1f546be41913a Write the vt102-di terminfo entry to /usr/share/terminfo This is the location where the all the other terminfo files are since with ncurses-base 6.4+20230603. Also create the directory in advance, because tic does not create multiple levels of directories and would fail if an older ncurses-base version is installed at build time. Closes: #1040048 (this message was generated automatically) -- Greetings https://bugs.debian.org/1040048
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
Control: reassign -1 busybox-udeb 1:1.36.1-3 Cyril Brulebois (2023-06-28): > busybox seems to me like the most likely suspect here. deb-reversion'ing > bookworm's version as a version that's newer than the one in unstable, > stashing its binaries under build/localudebs and building say a > netboot(-gtk) image should be a quick way to test that hypothesis. With a local build, confirmed -3 is buggy, and that reverting only busybox-udeb to -1 is sufficient to restore syslog support in the installer. Reassigning there; the GRUB thing can be filed separately once we have actual information via syslog. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
Roland Clobus (2023-06-28): > My findings so far: > * The command line arguments of syslogd and klogd (both from Busybox) have not > changed between Bookworm and Trixie. > * At the moment of the failure, the /var/log folder contains only 3 files [3]: > syslog (a single line, stating that syslog was started from Busybox [4]), > partman and Xorg.0.log > * When running `logger`, an entry should have been created in /var/log/syslog, > but that doesn't happen. The netinst image from Bookworm works correctly. > * Possibly relevant packages that have been updated: busybox, libc, linux- > image, bsdutils busybox seems to me like the most likely suspect here. deb-reversion'ing bookworm's version as a version that's newer than the one in unstable, stashing its binaries under build/localudebs and building say a netboot(-gtk) image should be a quick way to test that hypothesis. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue
Control: severity -1 normal tomas k (2023-06-08): > Package: debian-installer > Severity: critical > Tags: d-i > Justification: breaks the whole system Hardly. You're starting from a system that requires GRUB to be installed for some reason. d-i isn't breaking anything at all. > I'm on a different system than the problem one. For years I have had > to boot knoppix and run a chroot to change a password I've forgotten init=/bin/sh works for that. > Most recently, I just wanted to install grub from the Debian install > DVD, nothing else, but once again, with separate usr, no root shell. > So I tried to go through the install and just skip to install grub, > but it wouldn't allow it, because previous steps were skipped. ThAT > FIASCO cost me 4 hours, about the same amount of time it would take > to fix the rescue system. If rescue doesn't mount all the things automatically, you realize you can drop to a shell in the installer's context and mount any missing bit? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Control: tag -1 patch pending Cyril Brulebois (2023-05-27): > For the record, those archives end up being published in locations like > the following, and I definitely expected those to match the firmware > packages getting shipped into the images, not be some kind of snapshot of > what's in unstable at the time the release is built! > > https://cdimage.debian.org/cdimage/firmware/bookworm/bookworm_di_rc3/ > > We should definitely clarify the situation, and get to the bottom of that > double firmware build. > > From the log lines quoted above, if both bookworm and sid builds end up > shipping files in the same destination directory, the last build wins and > overrides the first one entirely? I'm considering the following change for the upcoming (pseudo) RC 5 release: https://salsa.debian.org/images-team/setup/-/commit/9a77631 This means nothing changes for weekly builds, which are detected as being built with DEBVERSION set to “testing” (please note that I didn't investigate what happens to firmware directories in this case). Meanwhile, actual releases get that sid job skipped (since the release specific config file, e.g. CONF.sh.bookworm_di_rc4, sets DEBVERSION to “bookworm-DI-rc4” instead of sticking to the default “testing” value). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1036959: rasdaemon: invalid Maintainer field
Control: tag -1 patch pending Mattia Rizzolo (2023-05-30): > v0.6.8-1 of this package has this in d/control: > > Maintainer: Russell Coker , Taihsiang Ho > > > This is against Policy as there should only be one entity in this field. > > > Also, as you noticed, this confused DDPO (actually carnivore) a lot... On the release team side, we're not exactly sure what could break, or how badly, if we were to try and publish Bookworm with this package… Therefore, I've just uploaded an NMU, splitting the Maintainer field into Maintainer + Uploaders, picking developers in order. Source debdiff attached. By the way, the declared VCS isn't up-to-date, and lacks tags for recent uploads (last tag is debian/0.6.6-2, testing and unstable have 0.6.8-1 instead). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru rasdaemon-0.6.8/debian/changelog rasdaemon-0.6.8/debian/changelog --- rasdaemon-0.6.8/debian/changelog 2023-02-06 08:24:59.0 +0100 +++ rasdaemon-0.6.8/debian/changelog 2023-06-02 22:12:50.0 +0200 @@ -1,3 +1,13 @@ +rasdaemon (0.6.8-1.1) unstable; urgency=medium + + * Non-maintainer upload, on the behalf of the release team, making sure +we don't discover breakages when preparing the Bookworm release. + * Fix too-many-contacts lintian error: the Maintainer field is not +multi-valued, so keep the first developer in Maintainer and move the +second one to Uploaders (Closes: #1036959). + + -- Cyril Brulebois Fri, 02 Jun 2023 22:12:50 +0200 + rasdaemon (0.6.8-1) unstable; urgency=medium * Remove the patch in the upstream diff -Nru rasdaemon-0.6.8/debian/control rasdaemon-0.6.8/debian/control --- rasdaemon-0.6.8/debian/control 2022-06-09 20:01:05.0 +0200 +++ rasdaemon-0.6.8/debian/control 2023-06-02 22:09:32.0 +0200 @@ -1,7 +1,8 @@ Source: rasdaemon Section: admin Priority: optional -Maintainer: Russell Coker , Taihsiang Ho +Maintainer: Russell Coker +Uploaders: Taihsiang Ho Build-Depends: debhelper (>= 12), quilt, libsqlite3-dev, libgettextpo-dev, autoconf, dh-exec Standards-Version: 4.5.0 signature.asc Description: PGP signature
Bug#651280: don't allocate all available disk space in standard LVM partioning scheme
Control: severity -1 wishlist James Addison (2023-05-31): > After the changes made to address bug #924301 (mountpoints for ext[n] > filesystems that have insufficient free blocks are not automatically > checked for faults), I think that this bug could be considered more > serious. How do you figure? > The disk space required for e2scrub[1] snapshots is 256MiB and the > default allocation for LVM (encrypted or unecrypted) in the bookworm > RC4 installer is 100% (same as originally reported here in Y2011). That's the default setting. Users who want to use e2scrub can tweak it. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory
Control: clone -1 -2 Control: reassign -2 crowdsec-firewall-bouncer 0.0.25-2 Control: retitle -2 crowdsec-firewall-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory Andreas Beckmann (2023-05-31): > You just got lucky in the configuration order: > first crowdsec, thereafter crowdsec-firewall-bouncer > > This heavily depends on apt's serialization of the dependency > dag ... installation of some unrelated packaged might > influence the outcome. Alright, thanks! Since this shouldn't be about luck, and since I'm seeing this on a freshly-deployed VM, cloning accordingly. I've just discussed plans with upstream, implementation and tests to follow. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory
Andreas Beckmann (2023-05-30): > crowdsec-firewall-bouncer passed the test That I don't really understand. > crowdsec-custom-bouncer always failed in sid (and testing) with > --install-recommends, crowdsec-firewall-bouncer always succeeded > > The difference caused by --install-recommends is > > * crowdsec (which crowdsec-custom-bouncer Recommends) gets installed > * but crowdsec-custom-bouncer gets configured first, i.e. after crowdsec got > unpacked but before crowdsec could create the configuration file > /etc/crowdsec/config.yaml > * crowdsec-custom-bouncer.postinst only checks for cscli which is available > after unpacacking Sure, I got that part, and we're also seeing it now with a simple `apt-get install $bouncer` in a fresh VM, so this is a real issue I'd like to fix ASAP. My question is why that wouldn't show up for crowdsec-firewall-bouncer as well since the logic is essentially the same! (It does a little firewall detection, and there's basically a s/custom/firewall/ for a few filenames, but the cscli part is exactly the same. And they both only have crowdsec listed in Recommends.) Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory
Hallo Andreas, Cyril Brulebois (2023-05-27): > Andreas Beckmann (2023-05-04): > > during a test with piuparts I noticed your package failed to install. > > As per definition of the release team this makes the package too buggy > > for a release, thus the severity. > > For some reason, I didn't receive this bug report or the autoremoval > notification. > > I've just confirmed that requesting the bouncer's installation, in a > freshly-installed bookworm VM, leads to the same issue. That's something > that definitely worked when the bouncer was first introduced, I'm not > exactly sure why that's no longer the case; I'd be happy to have some > time to gather my thoughts, and upstream's, regarding this issue. Alright, with RC 4 out of the way, I'm looking at this issue again, and it seems the “sibling package” crowdsec-firewall-bouncer is affected by the exact same issue (not surprisingly). I'm curious as to whether it showed up in those piuparts tests, if you have bug reports yet to be filed, or something else. I might just file a report myself later on, I have to find a solution anyway, and it should be applicable to both packages… but it'd be better to have a report filed anyway, for documentation purposes. When that happens, I'm expecting it to be OK to use the same tags as this bug report… but I've kept Paul in copy to make sure. Also, thanks for your QA work in general. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Package: debian-cd Severity: serious Hi, During a previous release, I spotted we had two firmware builds, but let the topic go once I was reassured that was to be expected. For RC 4: 1/43: Starting firmware_bookworm build at 2023-05-27:09:03:53 […] 9/43: Starting firmware_sid build at 2023-05-27:09:04:01 […] firmware_bookworm finished successfully (started at 2023-05-27:09:03:53, ended at 2023-05-27:09:06:31, took 0h02m38s) […] firmware_sid finished successfully (started at 2023-05-27:09:04:01, ended at 2023-05-27:09:07:07, took 0h03m06s) Now, waiting to see if someone would join the testing efforts, I diffed firmware lists between rc3 and rc4, and spotted those differences: -./firmware-sof-signed_2.2.4-1_all.deb -./intel-microcode_3.20230214.1_amd64.deb -./intel-microcode_3.20230214.1_i386.deb +./firmware-sof-signed_2.2.5-1_all.deb +./intel-microcode_3.20230512.1_amd64.deb +./intel-microcode_3.20230512.1_i386.deb The intel-microcode bits are OK: intel-microcode | 3.20230512.1 | testing/non-free-firmware | source, amd64, i386 intel-microcode | 3.20230512.1 | unstable/non-free-firmware | source, amd64, i386 The firmware-sof-signed, not so much: firmware-sof-signed | 2.2.4-1 | testing/non-free-firmware | all firmware-sof-signed | 2.2.5-1 | unstable/non-free-firmware | all It's a relatively new upload, and it's of course blocked at the moment: [2023-05-15] Accepted firmware-sof 2.2.5-1 (all source) into unstable (Mark Pearson) (signed by: Vincent Bernat) For the record, those archives end up being published in locations like the following, and I definitely expected those to match the firmware packages getting shipped into the images, not be some kind of snapshot of what's in unstable at the time the release is built! https://cdimage.debian.org/cdimage/firmware/bookworm/bookworm_di_rc3/ We should definitely clarify the situation, and get to the bottom of that double firmware build. From the log lines quoted above, if both bookworm and sid builds end up shipping files in the same destination directory, the last build wins and overrides the first one entirely? See also the “rsync noise” that seemed somewhat OK to ignore. Not sure whether that's directly related though… ISTR it was probably about some timestamp discrepancy due to the underlying filesystem. For RC 4: file has vanished: "/home/debian-cd/publish/.bookworm_di_rc4/firmware/firmware.zip" rsync: stat "/dsa/cdimage/.incoming/.bookworm_di_rc4/firmware/.firmware.tar.gz.VQGfUC" failed: No such file or directory (2) rsync: rename "/dsa/cdimage/.incoming/.bookworm_di_rc4/firmware/.firmware.tar.gz.VQGfUC" -> "firmware.tar.gz": No such file or directory (2) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory
Hi, Andreas Beckmann (2023-05-04): > during a test with piuparts I noticed your package failed to install. > As per definition of the release team this makes the package too buggy > for a release, thus the severity. For some reason, I didn't receive this bug report or the autoremoval notification. I've just confirmed that requesting the bouncer's installation, in a freshly-installed bookworm VM, leads to the same issue. That's something that definitely worked when the bouncer was first introduced, I'm not exactly sure why that's no longer the case; I'd be happy to have some time to gather my thoughts, and upstream's, regarding this issue. At this point, I'd like to formally request a bookworm-ignore tag. Cc-ing Paul who initially contacted me about this. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state
[ Reordering slightly ] Cyril Brulebois (2023-05-02): > Paul Seelig (2023-05-02): > > Attached installation logs should be sufficiently verbose about what > > actually happened underneath. > > Either it was forgotten or dropped by the BTS; please use reply-all, > and attach it compressed (to avoid hitting size limits on either the > BTS side or on the debian-boot ML side). For reference: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035360#10 - https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1035360;filename=installer-logs.tar.xz;msg=10 > > Apparently, the required cryptsetup-initramfs packages were removed > > from the system during the last instalation stages, rendering the > > resulting system unbootable. That's not quite what happened. Instead, the cryptsetup-initramfs wasn't available to start with: Apr 30 16:11:44 in-target: Package cryptsetup-initramfs is not available, but is referred to by another package. Apr 30 16:11:44 in-target: E: Package 'cryptsetup-initramfs' has no installation candidate Later on, cryptsetup got removed along with a bunch of live packages. Presumably, if cryptsetup-initramfs had been successfully installed, it would have kept cryptsetup around. Again, I'm not familiar with the live environment, it'd be great if some with some knowledge about the way it operates and/or the way it's built could comment on this. Adding debian-live@ for now, but might be debian-cd@ territory… Very wild guess: Could cryptsetup-initramfs be missing from live-setup? https://salsa.debian.org/images-team/live-setup.git Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state
Hi Paul, and thanks for the report. Paul Seelig (2023-05-02): > using the xfce4 based RC2 live ISO image[1], on a Thinkpad T480 (16GB > RAM/256GB NVME/INTEL GRAPHICS ONLY) installation of Debian in an luks > encrypted LVM was performed. > > Apparently, the required cryptsetup-initramfs packages were removed > from the system during the last instalation stages, rendering the > resulting system unbootable. Oh wow, that looks bad. Unfortunately I'm mostly familiar with the regular d-i installer, not so much with the live counterpart. > Manual intervention was required to fix the issue from a live rescue > system, something a novice user will never be able to accomplish. Can't agree with you more. (Even with a developer hat, the first time one gets confronted with a LUKS system that cannot be unlocked leaves traces… Still remembering that initramfs bug I encountered around 2010, as if it were yesterday…) FWIW: While I'm not sure about live images (and I won't check right now), regular d-i offers a rescue mode which automates the painful detecting and unlocking steps when it comes to LUKS stuff, so you don't have to know about cryptsetup luksOpen and friends to get a shell into the installed system. > The same issue was already note with the prior RC1 variant of this > bookworm live ISO. It can be reliably reproduced. Helpful data point, thanks. > Attached installation logs should be sufficiently verbose about what > actually happened underneath. Either it was forgotten or dropped by the BTS; please use reply-all, and attach it compressed (to avoid hitting size limits on either the BTS side or on the debian-boot ML side). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1034228: zcfan: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi, Michel Alexandre Salim (2023-04-28): > Apologies for the delay, but I've uploaded a -2 that works around > dh_installsystemd not recognizing files in /usr/lib/systemd by moving it > to /lib/systemd, invoking dh_installsystemd, and moving it back to > /usr/lib/systemd > > Let me know if that is acceptable - otherwise the changes in -1+b1 looks > fine too. I'll let Laurent comment on this, as the person who came up with the plan and the bug reports: I was merely giving a hand to limit the amount of RC bugs at this very late stage of the release cycle, by providing patches. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1034229: wsdd2: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Matteo F. Vescovi (2023-04-26): > LGTM. Please, go ahead with a DELAYED/0. > Thanks for taking care of the issue for me. My pleasure! Rescheduled. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#999811: HAVEGED is obsolete starting from linux kernel 5.6
Control: severity -1 important Matt Taggart (2023-04-25): > As reported in #999811 the haveged package is obsolete starting in > linux 5.6 and newer, as the kernel adopted a similar algorithm and > also stopped blocking /dev/random reads. > > I am upgrading severity to serious because I believe this is release > critical for bookworm. No, thanks. > There may still be reasons to keep haveged in Debian, I do not know. > (do all archs have these >5.6 features? is it still needed in > addition?) https://bugs.debian.org/1034361#12 1+ month into the hard freeze isn't when you suddenly want to remove a dependency of the installer. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1034214: tcmu-runner: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: tag -1 patch pending
Andreas Henriksson (2023-04-12):
> A better solution would derive the path from systemd.pc, eg.
> pkg-config --variable=systemdsystemunitdir systemd
>
> (Note: this needs pkg-config and systemd in build-deps)
Not during the hard freeze.
Minimal source debdiff attached, along with the resulting binary debdiff
for the tcmu-runner package.
Maintainer: I'm uploading to DELAYED/5, it can be either rescheduled to
DELAYED/0 if you're happy with the changes right now, or be superseded
by an upload of yours if that happens before the delay is over.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru tcmu-1.5.4/debian/changelog tcmu-1.5.4/debian/changelog
--- tcmu-1.5.4/debian/changelog 2022-07-23 21:53:15.0 +
+++ tcmu-1.5.4/debian/changelog 2023-04-25 17:51:40.0 +
@@ -1,3 +1,11 @@
+tcmu (1.5.4-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Ship systemd unit under /lib/systemd/system so that it can get picked
+up by dh_installsystemd. Closes: #1034214
+
+ -- Cyril Brulebois Tue, 25 Apr 2023 17:51:40 +
+
tcmu (1.5.4-4) unstable; urgency=medium
* QA upload.
diff -Nru tcmu-1.5.4/debian/tcmu-runner.install tcmu-1.5.4/debian/tcmu-runner.install
--- tcmu-1.5.4/debian/tcmu-runner.install 2022-07-23 21:53:15.0 +
+++ tcmu-1.5.4/debian/tcmu-runner.install 2023-04-25 17:51:39.0 +
@@ -1,5 +1,5 @@
debian/tmp/etc
-debian/tmp/usr/lib/systemd/system/tcmu-runner.service
+debian/tmp/usr/lib/systemd/system/tcmu-runner.service /lib/systemd/system
debian/tmp/usr/lib/*/tcmu-runner
debian/tmp/usr/bin
debian/tmp/usr/share
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/lib/systemd/system/tcmu-runner.service
Files in first .deb but not in second
-
-rw-r--r-- root/root /lib/systemd/system/tcmu-runner.service
No differences were encountered between the conffiles files
Control files: lines which differ (wdiff format)
Installed-Size: [-326-] {+324+}
Version: [-1.5.4-4.1-] {+1.5.4-4+}
Postinst files: lines which differ (wdiff format)
-
[-# Automatically added by dh_installsystemd/13.11.4-]
[-if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then-]
[- # The following line should be removed in trixie or trixie+1-]
[- deb-systemd-helper unmask 'tcmu-runner.service' >/dev/null || true-]
[--]
[- # was-enabled defaults to true, so new installations run enable.-]
[- if deb-systemd-helper --quiet was-enabled 'tcmu-runner.service'; then-]
[- # Enables the unit on first installation, creates new-]
[- # symlinks on upgrades if the unit file has changed.-]
[- deb-systemd-helper enable 'tcmu-runner.service' >/dev/null ||
true-]
[- else-]
[- # Update the statefile to add new symlinks (if any), which need
to be-]
[- # cleaned up on purge. Also remove old symlinks.-]
[- deb-systemd-helper update-state 'tcmu-runner.service'
>/dev/null || true-]
[- fi-]
[-fi-]
[-# End automatically added section-]
[-# Automatically added by dh_installsystemd/13.11.4-]
[-if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then-]
[- if [ -d /run/systemd/system ]; then-]
[- systemctl --system daemon-reload >/dev/null || true-]
[- if [ -n "$2" ]; then-]
[- _dh_action=restart-]
[- else-]
[- _dh_action=start-]
[- fi-]
[- deb-systemd-invoke $_dh_action 'tcmu-runner.service' >/dev/null
|| true-]
[- fi-]
[-fi-]
[-# End automatically added section-]
Postrm files: lines which differ (wdiff format)
---
[-# Automatically added by dh_installsystemd/13.11.4-]
[-if [ "$1" = remove ] && [ -d /run/systemd/system ] ; then-]
[- systemctl --system daemon-reload >/dev/null || true-]
[-fi-]
[-# End automatically added section-]
[-# Automatically added by dh_installsystemd/13.11.4-]
[-if [ "$1" = "purge" ]; then-]
[- if [ -x "/usr/bin/deb-systemd-helper" ]; then-]
[- deb-systemd-helper purge 'tcmu-runner.service' >/dev/null ||
true-]
[- fi-]
[-fi-]
[-# End automatically added
Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Andreas Henriksson (2023-04-12):
> I forgot to mention that since this is a template unit (@.service)
> maybe the severity should not be RC.
> As far as I know debhelper will not enable any instance of a template
> unit by default anyway, so the consequences that bigon warned about
> probably doesn't apply here?
Right, moving the file doesn't change anything in the binary package.
Verified with the attached patch.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru drkonqi-5.27.2/debian/changelog drkonqi-5.27.2/debian/changelog
--- drkonqi-5.27.2/debian/changelog 2023-02-28 13:58:47.0 +
+++ drkonqi-5.27.2/debian/changelog 2023-04-25 17:43:05.0 +
@@ -1,3 +1,11 @@
+drkonqi (5.27.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Ship systemd unit under /lib/systemd/system so that it can get picked
+up by dh_installsystemd (Closes: #1034215).
+
+ -- Cyril Brulebois Tue, 25 Apr 2023 17:43:05 +
+
drkonqi (5.27.2-1) unstable; urgency=medium
[ Aurélien COUDERC ]
diff -Nru drkonqi-5.27.2/debian/patches/0001-fix-systemd-unit-directory.patch drkonqi-5.27.2/debian/patches/0001-fix-systemd-unit-directory.patch
--- drkonqi-5.27.2/debian/patches/0001-fix-systemd-unit-directory.patch 1970-01-01 00:00:00.0 +
+++ drkonqi-5.27.2/debian/patches/0001-fix-systemd-unit-directory.patch 2023-04-25 17:42:41.0 +
@@ -0,0 +1,15 @@
+From: Cyril Brulebois
+Date: Tue, 25 Apr 2023 17:38:42 +
+Subject: Adjust systemd unit location
+Bug-Debian: https://bugs.debian.org/1034215
+--- a/src/coredump/processor/CMakeLists.txt
b/src/coredump/processor/CMakeLists.txt
+@@ -11,7 +11,7 @@ configure_file(
+ )
+ install(
+ FILES ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
+-DESTINATION ${KDE_INSTALL_SYSTEMDUNITDIR}/system
++DESTINATION /lib/systemd/system
+ )
+
+ # https://github.com/systemd/systemd/issues/19437
diff -Nru drkonqi-5.27.2/debian/patches/series drkonqi-5.27.2/debian/patches/series
--- drkonqi-5.27.2/debian/patches/series 1970-01-01 00:00:00.0 +
+++ drkonqi-5.27.2/debian/patches/series 2023-04-25 17:42:41.0 +
@@ -0,0 +1 @@
+0001-fix-systemd-unit-directory.patch
signature.asc
Description: PGP signature
Bug#1034216: boinc-client: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Cyril Brulebois (2023-04-25): > Minimal source debdiff attached. > > The resulting binary debdiff is attached as well (limited to boinc-client). Hmmm. I forgot to check packages in bullseye; that one is weird. Seen on https://packages.debian.org/search?lang=en=bullseye=any=path=contents=boinc-client.service You have searched for paths that end with boinc-client.service in suite bullseye, all sections, and all architectures. Found 2 results. FilePackages /lib/systemd/system/boinc-client.serviceboinc-client [mips] /usr/lib/systemd/system/boinc-client.serviceboinc-client [not mips] ISTR moving files is considered unsafe in this situation? > Maintainer: I'm uploading to DELAYED/5, it can be either rescheduled to > DELAYED/0 if you're happy with the changes right now, or be superseded > by an upload of yours if that happens before the delay is over. It's still there for the time being, but I'll need an answer to the above question soon. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1034216: boinc-client: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: tag -1 patch pending
Hi,
bi...@debian.org (2023-04-11):
> This is not supported by the version of dh_installsystemd/debhelper currently
> in unstable and bookworm (See: #1031695). That means that currently your
> service might not be enabled at boot and/or started as expected.
>
> With the freeze currently in effect, debhelper will not be fixed for bookworm.
>
> As a result, could you please move these files to /lib/systemd/system instead
> so they are properly detected by debhelper?
> As soon as debhelper is supporting (not until bookworm+1 aka Trixie) you will
> be able to move them back to the newer location.
Minimal source debdiff attached.
The resulting binary debdiff is attached as well (limited to boinc-client).
Maintainer: I'm uploading to DELAYED/5, it can be either rescheduled to
DELAYED/0 if you're happy with the changes right now, or be superseded
by an upload of yours if that happens before the delay is over.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru boinc-7.20.5+dfsg/debian/boinc-client.install boinc-7.20.5+dfsg/debian/boinc-client.install
--- boinc-7.20.5+dfsg/debian/boinc-client.install 2022-01-26 16:42:50.0 +0100
+++ boinc-7.20.5+dfsg/debian/boinc-client.install 2023-04-25 18:56:54.0 +0200
@@ -8,4 +8,4 @@
usr/bin/boinccmd
usr/bin/switcherusr/lib/boinc-client
usr/share/locale/*/LC_MESSAGES/BOINC-Client.mo
-usr/lib/systemd/system
+usr/lib/systemd/system/*lib/systemd/system/
diff -Nru boinc-7.20.5+dfsg/debian/changelog boinc-7.20.5+dfsg/debian/changelog
--- boinc-7.20.5+dfsg/debian/changelog 2022-12-02 16:00:35.0 +0100
+++ boinc-7.20.5+dfsg/debian/changelog 2023-04-25 18:59:54.0 +0200
@@ -1,3 +1,11 @@
+boinc (7.20.5+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Ship systemd unit under /lib/systemd/system so that it can get picked
+up by dh_installsystemd (Closes: #1034216)
+
+ -- Cyril Brulebois Tue, 25 Apr 2023 16:59:54 +
+
boinc (7.20.5+dfsg-1) unstable; urgency=medium
* New upstream version 7.20.5+dfsg
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /lib/systemd/system/boinc-client.service
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/lib/systemd/system/boinc-client.service
-rw-r--r-- root/root /usr/share/doc/boinc-client/changelog.Debian.amd64.gz
No differences were encountered between the conffiles files
Control files: lines which differ (wdiff format)
Depends: debconf (>= 0.5) | debconf-2.0, python3:any, libboinc7 (=
[-7.20.5+dfsg-1+b2),-] {+7.20.5+dfsg-1.1),+} libc6 (>= 2.34), libcurl4 (>=
7.16.2), libgcc-s1 (>= 3.3.1), libstdc++6 (>= 11), libx11-6, libxss1, zlib1g
(>= 1:1.1.4), adduser, ca-certificates, lsb-base (>= 3.0-6)
Source: boinc [-(7.20.5+dfsg-1)-]
Version: [-7.20.5+dfsg-1+b2-] {+7.20.5+dfsg-1.1+}
Postinst files: lines which differ (wdiff format)
-
# Automatically added by [-dh_installinit/13.11.3-] {+dh_installinit/13.11.4+}
{+fi+}
{+fi+}
{+# End automatically added section+}
{+# Automatically added by dh_installsystemd/13.11.4+}
{+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then+}
{+ # The following line should be removed in trixie or trixie+1+}
{+ deb-systemd-helper unmask 'boinc-client.service' >/dev/null || true+}
{++}
{+ # was-enabled defaults to true, so new installations run enable.+}
{+ if deb-systemd-helper --quiet was-enabled 'boinc-client.service'; then+}
{+ # Enables the unit on first installation, creates new+}
{+ # symlinks on upgrades if the unit file has changed.+}
{+ deb-systemd-helper enable 'boinc-client.service' >/dev/null ||
true+}
{+ else+}
{+ # Update the statefile to add new symlinks (if any), which need
to be+}
{+ # cleaned up on purge. Also remove old symlinks.+}
{+ deb-systemd-helper update-state 'boinc-client.service'
>/dev/null || true+}
{+ fi+}
{+fi+}
{+# End automatically added section+}
{+# Automatically added by dh_installsystemd/13.11.4+}
{+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then+}
{+ if [ -d /run/systemd/system ]; then+}
{+ systemctl --system daemon-reload
Bug#1034224: pvpgn: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi Laurent, bi...@debian.org (2023-04-11): > This is not supported by the version of dh_installsystemd/debhelper currently > in unstable and bookworm (See: #1031695). That means that currently your > service might not be enabled at boot and/or started as expected. > > With the freeze currently in effect, debhelper will not be fixed for bookworm. > > As a result, could you please move these files to /lib/systemd/system instead > so they are properly detected by debhelper? > As soon as debhelper is supporting (not until bookworm+1 aka Trixie) you will > be able to move them back to the newer location. This package requires no changes to get the file moved into the right location, and the relevant lines in maintainer scripts. Will you request a binNMU for it? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1034228: zcfan: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Cyril Brulebois (2023-04-25): > Maintainer: I'm uploading to DELAYED/5, it can be either rescheduled to > DELAYED/0 if you're happy with the changes right now, or be superseded > by an upload of yours if that happens before the delay is over. Sorry, I've used `dch -i` instead of `dch -n` so it's not obvious this is an NMU. Fixed source debdiff attached, and that's what I've just uploaded to DELAYED/5. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru zcfan-1.2.1/debian/changelog zcfan-1.2.1/debian/changelog --- zcfan-1.2.1/debian/changelog 2022-08-12 21:27:28.0 + +++ zcfan-1.2.1/debian/changelog 2023-04-25 16:01:08.0 + @@ -1,3 +1,11 @@ +zcfan (1.2.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Ship systemd unit under /lib/systemd/system so that it can get picked +up by dh_installsystemd. (Closes: #1034228) + + -- Cyril Brulebois Tue, 25 Apr 2023 16:01:08 + + zcfan (1.2.1-1) unstable; urgency=low * Initial release. (Closes: #1016908) diff -Nru zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff --- zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff 1970-01-01 00:00:00.0 + +++ zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff 2023-04-25 15:59:48.0 + @@ -0,0 +1,15 @@ +Description: Ship systemd unit where dh_installsystemd can find it. +Author: Cyril Brulebois +Forwarded: not-needed +Last-Update: 2023-04-24 +--- a/Makefile b/Makefile +@@ -41,7 +41,7 @@ clang-tidy: + install: all + mkdir -p $(DESTDIR)$(bindir)/ + $(INSTALL) -pt $(DESTDIR)$(bindir)/ $(EXECUTABLES) +- $(INSTALL) -Dp -m 644 zcfan.service $(DESTDIR)$(prefix)/lib/systemd/system/zcfan.service ++ $(INSTALL) -Dp -m 644 zcfan.service $(DESTDIR)/lib/systemd/system/zcfan.service + $(INSTALL) -Dp -m 644 zcfan.1 $(DESTDIR)$(mandir)/man1/zcfan.1 + + clean: diff -Nru zcfan-1.2.1/debian/patches/series zcfan-1.2.1/debian/patches/series --- zcfan-1.2.1/debian/patches/series 2022-08-12 21:15:44.0 + +++ zcfan-1.2.1/debian/patches/series 2023-04-25 15:57:28.0 + @@ -1 +1,2 @@ add-cppflags.diff +fix-systemd-unit-location.diff signature.asc Description: PGP signature
Bug#1034228: zcfan: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: tag -1 patch pending
Andreas Henriksson (2023-04-11):
> The culprit seems to be the wrong path hardcoded at:
> https://sources.debian.org/src/zcfan/1.2.1-1/Makefile/#L44
>
> Preferably you would find out this path by querying systemd.pc for it,
> ie. pkg-config --variable=systemdsystemunitdir systemd
>
> (Note: You'll also need to build-dep on pkg-config and systemd, for
> systemd.pc)
Let's… not do that during the hard freeze.
With the attached patch, the resulting binary debdiff looks like this:
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /lib/systemd/system/zcfan.service
-rwxr-xr-x root/root DEBIAN/postinst
-rwxr-xr-x root/root DEBIAN/postrm
-rwxr-xr-x root/root DEBIAN/prerm
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/lib/systemd/system/zcfan.service
(*) -rw-r--r-- root/root /usr/share/doc/zcfan/changelog.Debian.amd64.gz
Control files: lines which differ (wdiff format)
Installed-Size: [-36-] {+39+}
(*) [-Source: zcfan (1.2.1-1)-]
Version: [-1.2.1-1+b1-] {+1.2.1-2+}
There's a bit of extra noise in there, due to the fact we're comparing a
binNMU against a normal upload, I've prefixed relevant lines with an
asterisk.
Maintainer: I'm uploading to DELAYED/5, it can be either rescheduled to
DELAYED/0 if you're happy with the changes right now, or be superseded
by an upload of yours if that happens before the delay is over.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru zcfan-1.2.1/debian/changelog zcfan-1.2.1/debian/changelog
--- zcfan-1.2.1/debian/changelog 2022-08-12 21:27:28.0 +
+++ zcfan-1.2.1/debian/changelog 2023-04-25 16:01:08.0 +
@@ -1,3 +1,10 @@
+zcfan (1.2.1-2) unstable; urgency=medium
+
+ * Ship systemd unit under /lib/systemd/system so that it can get picked
+up by dh_installsystemd. (Closes: #1034228)
+
+ -- Cyril Brulebois Tue, 25 Apr 2023 16:01:08 +
+
zcfan (1.2.1-1) unstable; urgency=low
* Initial release. (Closes: #1016908)
diff -Nru zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff
--- zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff 1970-01-01 00:00:00.0 +
+++ zcfan-1.2.1/debian/patches/fix-systemd-unit-location.diff 2023-04-25 15:59:48.0 +
@@ -0,0 +1,15 @@
+Description: Ship systemd unit where dh_installsystemd can find it.
+Author: Cyril Brulebois
+Forwarded: not-needed
+Last-Update: 2023-04-24
+--- a/Makefile
b/Makefile
+@@ -41,7 +41,7 @@ clang-tidy:
+ install: all
+ mkdir -p $(DESTDIR)$(bindir)/
+ $(INSTALL) -pt $(DESTDIR)$(bindir)/ $(EXECUTABLES)
+- $(INSTALL) -Dp -m 644 zcfan.service $(DESTDIR)$(prefix)/lib/systemd/system/zcfan.service
++ $(INSTALL) -Dp -m 644 zcfan.service $(DESTDIR)/lib/systemd/system/zcfan.service
+ $(INSTALL) -Dp -m 644 zcfan.1 $(DESTDIR)$(mandir)/man1/zcfan.1
+
+ clean:
diff -Nru zcfan-1.2.1/debian/patches/series zcfan-1.2.1/debian/patches/series
--- zcfan-1.2.1/debian/patches/series 2022-08-12 21:15:44.0 +
+++ zcfan-1.2.1/debian/patches/series 2023-04-25 15:57:28.0 +
@@ -1 +1,2 @@
add-cppflags.diff
+fix-systemd-unit-location.diff
signature.asc
Description: PGP signature
Bug#1034229: wsdd2: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: tag -1 patch pending Hi, Andreas Henriksson (2023-04-11): > The culprit seems to be the hard-coded path at: > https://sources.debian.org/src/wsdd2/1.8.7%2Bdfsg-1/Makefile/#L31 > > As this path will change again in the future, please consider > finding out the path from the proper source via: > pkg-config --variable=systemdsystemunitdir systemd > > (Note: you'll need to build-dep on pkg-config and systemd, for > systemd.pc) Or just patch it out now, and drop the patch later, as we're in hard freeze. Building with the attached patch leads to the following changes on the binary side, as expected: Files in second .deb but not in first - -rw-r--r-- root/root /lib/systemd/system/wsdd2.service -rwxr-xr-x root/root DEBIAN/postinst -rwxr-xr-x root/root DEBIAN/postrm -rwxr-xr-x root/root DEBIAN/prerm Files in first .deb but not in second - -rw-r--r-- root/root /usr/lib/systemd/system/wsdd2.service Maintainer: I'm uploading to DELAYED/5, it can be either rescheduled to DELAYED/0 if you're happy with the changes right now, or be superseded by an upload of yours if that happens before the delay is over. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru wsdd2-1.8.7+dfsg/debian/changelog wsdd2-1.8.7+dfsg/debian/changelog --- wsdd2-1.8.7+dfsg/debian/changelog 2022-07-13 21:24:12.0 + +++ wsdd2-1.8.7+dfsg/debian/changelog 2023-04-25 15:40:11.0 + @@ -1,3 +1,11 @@ +wsdd2 (1.8.7+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Ship systemd unit under /lib/systemd/system so that it can get picked +up by dh_installsystemd (Closes: #1034229) + + -- Cyril Brulebois Tue, 25 Apr 2023 15:40:11 + + wsdd2 (1.8.7+dfsg-1) unstable; urgency=medium * New upstream release diff -Nru wsdd2-1.8.7+dfsg/debian/patches/0002-Fix-systemd-unit-directory.patch wsdd2-1.8.7+dfsg/debian/patches/0002-Fix-systemd-unit-directory.patch --- wsdd2-1.8.7+dfsg/debian/patches/0002-Fix-systemd-unit-directory.patch 1970-01-01 00:00:00.0 + +++ wsdd2-1.8.7+dfsg/debian/patches/0002-Fix-systemd-unit-directory.patch 2023-04-25 15:39:54.00000 +0000 @@ -0,0 +1,22 @@ +From: Cyril Brulebois +Date: Tue, 25 Apr 2023 15:37:40 + +Subject: Fix systemd unit directory +Forwarded: not-needed +Bug-Debian: https://bugs.debian.org/1034229 + +For Bookworm, dh_installsystemd only looks at /lib/systemd/system (and +doesn't look at /usr/lib/systemd/system). + +--- a/Makefile b/Makefile +@@ -28,8 +28,8 @@ install: wsdd2 + install wsdd2 $(DESTDIR)$(SBINDIR) + install -d $(DESTDIR)$(MANDIR)/man8 + install -m 0644 wsdd2.8 $(DESTDIR)$(MANDIR)/man8 +- install -d $(DESTDIR)$(LIBDIR)/systemd/system +- install -m 0644 wsdd2.service $(DESTDIR)$(LIBDIR)/systemd/system ++ install -d $(DESTDIR)/lib/systemd/system ++ install -m 0644 wsdd2.service $(DESTDIR)/lib/systemd/system + + clean: + rm -f wsdd2 nl_debug $(OBJFILES) diff -Nru wsdd2-1.8.7+dfsg/debian/patches/series wsdd2-1.8.7+dfsg/debian/patches/series --- wsdd2-1.8.7+dfsg/debian/patches/series 2021-10-23 18:58:25.0 + +++ wsdd2-1.8.7+dfsg/debian/patches/series 2023-04-25 15:36:45.0 + @@ -1 +1,2 @@ 0001-Additional_parameters_in_unit_file.patch +0002-Fix-systemd-unit-directory.patch signature.asc Description: PGP signature
Bug#1034235: ceph-iscsi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: tag -1 patch pending
bi...@debian.org (2023-04-11):
> It seems that your package ceph-iscsi is shipping files (.service, .socket or
> .timer) in /usr/lib/systemd/system.
>
> This is not supported by the version of dh_installsystemd/debhelper currently
> in unstable and bookworm (See: #1031695). That means that currently your
> service might not be enabled at boot and/or started as expected.
Source and binary debdiffs attached. Since that's an orphaned package,
an upload will follow.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru ceph-iscsi-3.5/debian/ceph-iscsi.install ceph-iscsi-3.5/debian/ceph-iscsi.install
--- ceph-iscsi-3.5/debian/ceph-iscsi.install 2021-09-24 12:45:45.0 +
+++ ceph-iscsi-3.5/debian/ceph-iscsi.install 2023-04-25 15:25:07.0 +
@@ -1 +1 @@
-usr/lib/systemd/system/*.service
+usr/lib/systemd/system/*.service /lib/systemd/system
diff -Nru ceph-iscsi-3.5/debian/changelog ceph-iscsi-3.5/debian/changelog
--- ceph-iscsi-3.5/debian/changelog 2021-09-24 12:45:45.0 +
+++ ceph-iscsi-3.5/debian/changelog 2023-04-25 15:26:14.0 +
@@ -1,3 +1,11 @@
+ceph-iscsi (3.5-3) unstable; urgency=medium
+
+ * QA upload.
+ * Ship systemd units under /lib/systemd/system so that they can get
+picked up by dh_installsystemd (Closes: #1034235).
+
+ -- Cyril Brulebois Tue, 25 Apr 2023 15:26:14 +
+
ceph-iscsi (3.5-2) unstable; urgency=medium
* QA upload.
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rw-r--r-- root/root /lib/systemd/system/rbd-target-api.service
-rw-r--r-- root/root /lib/systemd/system/rbd-target-gw.service
Files in first .changes but not in second
-
-rw-r--r-- root/root /usr/lib/systemd/system/rbd-target-api.service
-rw-r--r-- root/root /usr/lib/systemd/system/rbd-target-gw.service
No differences were encountered between the conffiles files
Control files: lines which differ (wdiff format)
Installed-Size: [-557-] {+562+}
Version: [-3.5-2-] {+3.5-2.1+}
Postinst files: lines which differ (wdiff format)
-
{+# Automatically added by dh_installsystemd/13.11.4+}
{+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then+}
{+ # The following line should be removed in trixie or trixie+1+}
{+ deb-systemd-helper unmask 'rbd-target-api.service' >/dev/null || true+}
{++}
{+ # was-enabled defaults to true, so new installations run enable.+}
{+ if deb-systemd-helper --quiet was-enabled 'rbd-target-api.service';
then+}
{+ # Enables the unit on first installation, creates new+}
{+ # symlinks on upgrades if the unit file has changed.+}
{+ deb-systemd-helper enable 'rbd-target-api.service' >/dev/null
|| true+}
{+ else+}
{+ # Update the statefile to add new symlinks (if any), which need
to be+}
{+ # cleaned up on purge. Also remove old symlinks.+}
{+ deb-systemd-helper update-state 'rbd-target-api.service'
>/dev/null || true+}
{+ fi+}
{+fi+}
{+# End automatically added section+}
{+# Automatically added by dh_installsystemd/13.11.4+}
{+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then+}
{+ # The following line should be removed in trixie or trixie+1+}
{+ deb-systemd-helper unmask 'rbd-target-gw.service' >/dev/null || true+}
{++}
{+ # was-enabled defaults to true, so new installations run enable.+}
{+ if deb-systemd-helper --quiet was-enabled 'rbd-target-gw.service';
then+}
{+ # Enables the unit on first installation, creates new+}
{+ # symlinks on upgrades if the unit file has changed.+}
{+ deb-systemd-helper enable 'rbd-target-gw.service' >/dev/null ||
true+}
{+ else+}
{+ # Update the statefile to add new symlinks (if any), which need
to be+}
{+ # cleaned up on purge. Also remove old symlinks.+}
{+ deb-systemd-helper update-state 'rbd-target-gw.service'
>/dev/null || true+}
{+ fi+}
{+fi+}
{+# End automatically added section+}
{+# Automatically added by dh_installsystemd/13.11.4+}
{+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remov
Bug#1034240: pass-extension-tomb: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi Laurent, bi...@debian.org (2023-04-11): > It seems that your package pass-extension-tomb is shipping files > (.service, .socket or .timer) in /usr/lib/systemd/system. That's pass-close@.service > As a result, could you please move these files to /lib/systemd/system > instead so they are properly detected by debhelper? Once the attached patch is applied, there are absolutely no changes in the resulting binary package besides the moved package (no extra code in maintainer scripts). To be on the safe side, I've tried overriding dh_installsystemd to list the unit directly, and that doesn't change anything. What do you think should happen here? Close this as not-a-bug? Or upload anyway, so that we have all packages aligned, shipping units under /lib rather than /usr/lib? I don't have any opinion on this at the moment. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru pass-tomb-1.3/debian/changelog pass-tomb-1.3/debian/changelog --- pass-tomb-1.3/debian/changelog 2022-01-19 06:49:30.0 + +++ pass-tomb-1.3/debian/changelog 2023-04-25 15:04:51.0 + @@ -1,3 +1,11 @@ +pass-tomb (1.3-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Ship pass-close@.service under /lib/systemd/system so that it can +be considered by dh_installsystemd (Closes: #1034240). + + -- Cyril Brulebois Tue, 25 Apr 2023 15:04:51 + + pass-tomb (1.3-2) unstable; urgency=medium * Change path from /lib to /usr (Closes: #1003996). diff -Nru pass-tomb-1.3/debian/rules pass-tomb-1.3/debian/rules --- pass-tomb-1.3/debian/rules 2022-01-19 06:49:30.0 + +++ pass-tomb-1.3/debian/rules 2023-04-25 15:04:51.0 + @@ -5,3 +5,5 @@ override_dh_auto_install: dh_auto_install -- PREFIX=/usr BASHCOMPDIR=/usr/share/bash-completion/completions + mkdir -p debian/pass-extension-tomb/lib/systemd/system + mv debian/pass-extension-tomb/usr/lib/systemd/system/pass-close@.service debian/pass-extension-tomb/lib/systemd/system/pass-close@.service signature.asc Description: PGP signature
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: tag -1 patch
Sam Hartman (2023-04-11):
> control: tags -1 wontfix
serious & wontfix make for a strange combination…
> >>>>> "bigon" == bigon writes:
>
> bigon> It seems that your package libpam-modules-bin is shipping
> bigon> files (.service, .socket or .timer) in
> bigon> /usr/lib/systemd/system.
>
> I think we're talking about pam_namespace.service.
> I don't think dh_installsystemd has anything to do for that file because
> it has no Install section.
> What harm is caused by pam_namespace.service being in /usr/lib/systemd?
To expand on Lauren't answer, you're currently lacking these:
- postinst:
#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action 'pam_namespace.service'
>/dev/null || true
fi
fi
# End automatically added section
- postrm:
#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.11.4
if [ "$1" = remove ] && [ -d /run/systemd/system ] ; then
systemctl --system daemon-reload >/dev/null || true
fi
# End automatically added section
- prerm:
#!/bin/sh
set -e
# Automatically added by dh_installsystemd/13.11.4
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system
] ; then
deb-systemd-invoke stop 'pam_namespace.service' >/dev/null || true
fi
# End automatically added section
FWIW it's just a matter of changing the last line of
debian/libpam-modules-bin.install to:
usr/lib/systemd/system/pam_namespace.service /lib/systemd/system/
Patch attached.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
--- pam-1.5.2/debian/changelog 2023-01-03 20:15:23.0 +
+++ pam-1.5.2/debian/changelog 2023-04-25 14:51:19.0 +
@@ -1,3 +1,10 @@
+pam (1.5.2-7) UNRELEASED; urgency=medium
+
+ * Fix install directory for pam_namespace.service so that it gets
+picked up by dh_installsystemd, Closes: #1034234
+
+ -- Cyril Brulebois Tue, 25 Apr 2023 16:51:19 +0200
+
pam (1.5.2-6) unstable; urgency=medium
* Update debian/copyright, Thanks Bastian Germann, Closes: #460232
--- pam-1.5.2/debian/libpam-modules-bin.install 2023-01-03 20:15:23.0 +
+++ pam-1.5.2/debian/libpam-modules-bin.install 2023-04-25 14:41:36.0 +
@@ -6,4 +6,4 @@
sbin/pam_timestamp_check usr/sbin
sbin/faillock usr/sbin
modules/pam_faillock/faillock.8 usr/share/man/man8
-usr/lib/systemd/system/pam_namespace.service
+usr/lib/systemd/system/pam_namespace.service /lib/systemd/system/
signature.asc
Description: PGP signature
Bug#1034361: haveged: autopkgtest fails on bookworm kernel: service fails to start
Paul Gevers (2023-04-13): > The release team has announced [1] that failing autopkgtest on amd64 and > arm64 are considered RC in testing. [Release Team member hat on] Because > we're currently in the hard freeze for bookworm, I have marked this bug as > bookworm-ignore, however, I have a strong suspicion that it points out that > the package is broken. Targeted fixes are still welcome. The daemon starts just fine in d-i. The daemon starts just fine from the service unit on baremetal. I'd like extreme caution to be used before considering removing this package. After the 5.4 announce, trying to drop it from the installer didn't go quite well[1]. Maybe that's indeed better after 5.6, but I really don't want to investigate dropping it from the installer for Bookworm. 1. https://lists.debian.org/debian-boot/2020/03/msg00182.html and replies. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1034389: installation-reports: bookworm cannot install base system
Control: severity -1 important Control: tag -1 - d-i Hi Steve, Steve Witt (2023-04-13): > Tried installing in both expert mode, and normal mode. After > partitioning the disks went to the 'Install the base system' step. It > failed with the text: Cannot install base system. The installer cannot > figure out how to install the base system. If found no installable > image, and no valid mirror was configured. We'll need more details… > Please make sure that any installation logs that you think would > be useful are attached to this report. Please compress large > files using gzip. Please attach /var/log/syslog (compressed) from the installer environment. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1033913: partman-auto-lvm: Broken "Guided - use entire disk and set up LVM" in UEFI mode
Package: partman-auto-lvm Version: 87 Severity: serious Justification: Maintainer says so TL;DR: Answering “Yes” to the “Force UEFI installation?” makes sure the installer pulls the right bootloader packages, despite misreading the situation. I've discovered this while testing D-I Bookworm RC 1 but also confirmed it already existed in D-I Bookworm Alpha 2, and I'm therefore filing it against the version found in the previous release (and deciding not to block the Bookworm RC 1 release on it). For baremetal tests on laptops requiring various firmware packages, I've been using guided partitioning since forever, with one of these: - Guided - use entire disk - Guided - use entire disk and set up encrypted LVM The former is used most of the time since it's slightly faster (fewer prompts), while the latter is only used once in a while, to make sure a “real” laptop-oriented install works fine (since every laptop should be encrypted in my opinion). Since I had just tested “Guided - use entire disk” in a virtual machine, I decided to pick this instead when switching to the first laptop (Asus Vivobook S14/S15 but that's very likely not a factor): - Guided - use entire disk and set up LVM And… *WOW!* The first surprise is this prompt: Force UEFI installation? This machine's firmware has started the installer in UEFI mode but it looks like there may be existing operating systems already installed using "BIOS compatibility mode". If you continue to install Debian in UEFI mode, it might be difficult to reboot the machine into any BIOS-mode operating systems later. If you wish to install in UEFI mode and don't care about keeping the ability to boot one of the existing systems, you have the option to force that here. If you wish to keep the option to boot an existing operating system, you should choose NOT to force UEFI installation here. which defaults to No. That's very surprising since the only operating system prior to the installation was a Debian system, which was getting entirely erased (due to using the full disk), and was installed in UEFI mode anyway. I went for the default choice, since we expect the installer to make smart suggestions, and unsuspecting users shouldn't have to know better. That means we end up with installing grub-pc instead of grub-efi-amd64 and shim, being prompted where to install GRUB, and of course when it's time to reboot, the UEFI firmware rightfully refuses to boot anything since there's absolutely no signature whatsoever, which isn't a great idea under Secure Boot: Secure Boot Violation Invalid signature detected. Check Secure Boot Policy in Setup. Some additional info: - As mentioned in TL;DR, this can be worked around by answering Yes to “Force UEFI installation?”. - It doesn't seem to be dependent on possible traces of an existing system prior to the installation: Debian installed on the entire disk or with encrypted LVM on the entire disk doesn't seem to make a difference. Starting with a wiped disk (writing ~ 2 GB worth of zeros at the beginning of the disk) doesn't make a difference either. - It very much looks like the intermediary states are slightly different when setting up LVM and when setting up encrypted LVM, and the LVM case case leads to some confusion in partman-efi's /lib/partman/init.d/50efi (which logs to /var/log/partman rather than to /var/log/syslog): “Found 0 ESPs, 3 non-ESPs”. - I'm filing this issue against partman-auto-lvm though, for discoverability purposes. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI
Control: severity -1 normal Hi Dima, Dima Kogan (2023-03-29): > Hi. I just installed a bookworm candidate. This worked OK through > partitioning and reboot, but I cannot boot into the system. For the avoidance of doubt: which one? Alpha 1 or Alpha 2. Also, which image did you use? > This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA. You have not given a single detail about that machine. > I'm installing from a USB drive. To make this work, I had to turn off > secure-boot and UEFI in the BIOS. Why did you need that in the first place? How did you put the installation image onto that USB drive? > I believe that the result of this is the Debian partitioner defaulted > to an MBR partition, not a GPT partition. > > The BIOS of this laptop only allows booting from the PCIe SSD in UEFI > mode (so I need to change the BIOS setting before even trying). But > even after that, the machine doesn't let me boot off that disk. Some > searching tells me this is because GPT partitions are required for > UEFI booting, but Debian made an MBR partition. In a nutshell, BIOS means MBR, UEFI means GPT. (This is a very gross oversimplification though.) I'm not sure why the firmware would allow running an installer in BIOS mode and not boot off from the installed system… in BIOS mode too. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1005886: debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"
Control: severity -1 important James Addison (2023-03-22): > Followup-For: Bug #1005886 > X-Debbugs-Cc: powe...@gmail.com > Control: reassign -1 cdimage.debian.org > Control: retitle -1 cdimage.debian.org: bookworm net-install CD hangs on > "Detecting Network Hardware" > > Sorry (both to you Tony, and also the Debian CD team) for confusion and > wasting > time - I mistakenly reassigned this previously. I've checked the list of > bug-tracking pseudo-packages[1] and I do think that cdimage.debian.org is the > correct package for this bug to be assigned to. Hi Tony, Please attach /var/log/syslog (compressed). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1000225: RFC: Fixing golang-github-tidwall-gjson's RC bugginess for bookworm
Hi, As usual, with my crowdsec maintainer hat, I'm interested in keeping it in testing, and the next problem is golang-github-tidwall-gjson's autoremoval due to its security bugs (cc'd). Currently, we have a 1.6.7 version, those bugs are supposed to be fixed in 1.9.x, and upstream is at 1.14.4… This library is about parsing JSON, is basically one big go file (along with another one for the tests), and I'm not exactly sure what the best way to go would be. Since that's about parsing things, I suppose it wouldn't be trivial to backport the security fixes from 1.9.2 and 1.9.3 without understanding how parsing works, and why it was buggy in 1.6.7. Shipping the latest 1.9.x would probably be safer. But then, if we're going to have a bump in upstream releases, maybe considering the latest would make most sense? We would get those fixes, possible other ones, and that would minimize the delta whenever other security fixes come up? The reverse dependencies are quite limited: 1. according to dak: Checking reverse dependencies... # Broken Depends: golang-github-appleboy-gin-jwt: golang-github-appleboy-gin-jwt-dev golang-github-tidwall-buntdb: golang-github-tidwall-buntdb-dev golang-github-tidwall-grect: golang-github-tidwall-grect-dev # Broken Build-Depends: g10k: golang-github-tidwall-gjson-dev golang-github-appleboy-gin-jwt: golang-github-tidwall-gjson-dev golang-github-tidwall-buntdb: golang-github-tidwall-gjson-dev golang-github-tidwall-grect: golang-github-tidwall-gjson-dev wuzz: golang-github-tidwall-gjson-dev (crowdsec appears in the picture via golang-github-appleboy-gin-jwt) 2. according to ratt, a straightforward update to 1.14.4 would seem rather reasonable: (unstable-amd64-crowdsec)kibi@genova:~/work/clients/crowdsec/git/salsa$ ratt -dist sid -sbuild_dist sid golang-github-tidwall-gjson_1.14.4-1_amd64.changes 2023/03/04 22:57:32 Loading changes file "golang-github-tidwall-gjson_1.14.4-1_amd64.changes" 2023/03/04 22:57:32 - 1 binary packages: golang-github-tidwall-gjson-dev 2023/03/04 22:57:32 Corresponding .debs (will be injected when building): 2023/03/04 22:57:32 golang-github-tidwall-gjson-dev_1.14.4-1_all.deb 2023/03/04 22:57:32 Figuring out reverse build dependencies using dose-ceve(1). This might take a while 2023/03/04 22:57:51 Building package 1 of 10: crowdsec-firewall-bouncer 2023/03/04 22:58:54 Building package 2 of 10: garagemq 2023/03/04 22:59:59 Building package 3 of 10: crowdsec 2023/03/04 23:02:04 Building package 4 of 10: wuzz 2023/03/04 23:02:41 Building package 5 of 10: golang-github-tidwall-buntdb 2023/03/04 23:03:16 Building package 6 of 10: golang-github-tidwall-grect 2023/03/04 23:03:46 Building package 7 of 10: g10k 2023/03/04 23:04:21 Building package 8 of 10: crowdsec-custom-bouncer 2023/03/04 23:05:21 Building package 9 of 10: golang-github-appleboy-gin-jwt 2023/03/04 23:06:01 Building package 10 of 10: golang-github-crowdsecurity-go-cs-bouncer 2023/03/04 23:06:56 Build results: 2023/03/04 23:06:56 PASSED: crowdsec 2023/03/04 23:06:56 PASSED: wuzz 2023/03/04 23:06:56 PASSED: golang-github-tidwall-buntdb 2023/03/04 23:06:56 PASSED: golang-github-tidwall-grect 2023/03/04 23:06:56 PASSED: golang-github-crowdsecurity-go-cs-bouncer 2023/03/04 23:06:56 PASSED: crowdsec-firewall-bouncer 2023/03/04 23:06:56 PASSED: garagemq 2023/03/04 23:06:56 PASSED: g10k 2023/03/04 23:06:56 PASSED: crowdsec-custom-bouncer 2023/03/04 23:06:56 PASSED: golang-github-appleboy-gin-jwt My initial plan would be to upload this 1.14.4-1 to experimental, leaving space (version-wise) in unstable in case someone pushes for an 1.6.7 update, or something 1.9.x-based. I think (but I'm not sure) uploading to experimental would trigger autopkgtest in reverse dependencies, which should tell us more about possible fallouts from this update (as ratt running locally only tests builds on amd64). If that's indeed the case, this would mean being a little more reassured regarding proposing this update for unstable, then have it considered for testing? In any case, I think filing an unblock request before any upload to unstable would make sense, asking for pre-approval for whatever we end up considering as the target for bookworm. TL;DR, current plan: 1. upload 1.14.4-1 to experimental; 2. watch for fallouts; 3. decide what to consider for unstable and put the release team in the loop. And of course, I'm happy to sign up to deal with any side effects that might appear in the 10 reverse dependencies listed above… Comments, yay, nay, alternative takes, etc. are welcome! Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1031923: d-i.debian.org: testing (bookworm): Unable to boot due to unsupported FEATURE_C12 in e2fsck
Hi, Cesar Enrique Garcia Dabo (2023-02-27): > Thank you for the answer. Good to know that it is a known issue and is being > taken care of. > > Regarding why I took that image. I just followed the official Debian > webpages: > > https://www.debian.org/CD/http-ftp/index.en.html Many thanks for the follow-up… > From there I clicked on "Official CD/DVD images of the "testing" > distribution (/regenerated weekly/) > <https://cdimage.debian.org/cdimage/weekly-builds/>" > > https://cdimage.debian.org/cdimage/weekly-builds/ -> amd64 -> iso-cd -> > https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso > > So from my perspective I wasn't using a "random" image, but rather an > official one, as the web pages indicate. … now I understand what you went through. Unfortunately, I wasn't aware of those instructions, and that looks utterly buggy. How can we claim to publish “official images” that are snapshots, built using debian-installer daily builds, that can be broken by random packages in unstable, and left unfixed for weeks?! We already have specific instructions on the d-i page[1] regarding *actual* official releases (as soon as testing gets an Alpha 1), plus snapshots. My first instinct would be to entirely scrap testing-related things from the page you started from[2], and just redirect to [1] instead. 1. https://www.debian.org/devel/debian-installer/ 2. https://www.debian.org/CD/http-ftp/ That link should be updated too… http://debian-cd.debian.net/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1027551: golang-github-hashicorp-go-plugin: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/hashicorp/go-plugin github.com/hashicorp/go-plugin/internal/p
Hi, Shengjing Zhu (2023-01-01): > This failure in golang-github-hashicorp-go-plugin seems to be caused > by flaky tests. Could you try again? At least it succeeds on my > computer currently. If it fails too frequently, I probably need to > disable them. This is a very elusive issue, and I've only managed to produce it once in several dozens, then hundreds of attempts… (and all that only in a VM). Seeing how some other tests have been disabled already, I don't think it's unreasonable to call this one flakky as well, and to get it out of the way. I've just done so in the -4 upload. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1031935: firmware-ath9k-htc: missing hardware identifiers in dep-11 metadata
Package: firmware-ath9k-htc Version: 1.4.0-108-gd856466+dfsg1-1.2 Severity: serious Justification: regression in hardware support X-Debbugs-Cc: b...@debian.org, debian-ker...@lists.debian.org, debian-b...@lists.debian.org Hi, Here's another thing that was totally overlooked while forcing the switch from firmware-atheros to firmware-ath9k-htc in an uncoordinated manner: the dep-11 metadata are (1) hardcoded in the firmware-ath9k-htc package, and (2) out-of-date. This means we're actively losing support for hardware by switching from the non-free package to the one in main! Right now, the following entries are missing: - AirTies AR9271 - Altai WA1011N-GU Those date back to v4.12-rc1 (2017) and v4.16-rc1 (2018) respectively: - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16ff1fb0e32f76a5d285a6f23b82d21aa52813c6 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e12d654ba068df06c5e4c8322d7dcced41e48ee Surely checking feature parity should have been the very first step? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1031923: d-i.debian.org: testing (bookworm): Unable to boot due to unsupported FEATURE_C12 in e2fsck
Hi, Andrew, please use reply-all, to reply to the bug and to the bug submitter. A list-only reply doesn't quite help… Andrew M.A. Cater (2023-02-25): > > I have installed Debian testing (bookworm) from one of the latest ISO images > > (https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing- > > amd64-netinst.iso from 2023-02-21) and after an apparently succesfull > > installation the system cannot be booted. Enrique, thanks for the report. We've published an official release one week ago. I'm not sure why you're not using that instead of a random weekly build. > This is a known issue - try using the Alpha 2 installer in which this > issue is not present. > > The e2fsprogs mismatch with grub is likely to be fixed by reverting > problematic versions. No, the problem here is that e2fsck is from testing, while the filesystem has been created by mke2fs from unstable, and the former doesn't know about a new feature turned on by the latter. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031904: firmware-ath9k-htc: insufficient coordination around moving files between packages
Package: firmware-ath9k-htc Version: 1.4.0-108-gd856466+dfsg1-1.2 Severity: grave Tags: d-i X-Debbugs-Cc: b...@debian.org, debian-b...@lists.debian.org, debian-ker...@lists.debian.org Hi, While there have been some efforts around moving files between packages, that's still insufficient coordination: files haven't removed from the existing firmware-atheros package yet[1]! That means that any further upload of firmware-atheros will be (relationship-wise) co-installable with firmware-ath9k-htc (because its version will be higher than the one in Replaces/Breaks), while that's actually not the case! 1. https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/54?commit_id=48af82f195e4ad5736d753b375442996915e244a#note_384526 Such move should have been handled by (1) making sure the existing package drops files, and then (2) declaring Replaces/Breaks against all versions strictly lower than this version. Given modalias information, both firmware packages would be pulled at the same time during installation, breaking dpkg in the target system. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck
Simon McVittie (2023-02-24): > If I understand the situation correctly, that means the regression here is > indeed caused by the mke2fs in e2fsprogs/unstable defaulting to creating > a filesystem that cannot be fsck'd by the e2fsck in e2fsprogs/testing, > because orphan_file is a "compat" feature which can be ignored without > error by older kernels and other filesystem consumers like grub, but > due to the nature of a fsck tool, e2fsck is unwilling to tolerate "compat" > features that it doesn't understand? Just to be clear: mke2fs from e2fsprogs-udeb/unstable (the “installer is based on Debian unstable” part) creating a file system that fsck from e2fsprogs/testing (the “install Debian testing” part) doesn't understand. (e2fsprogs/unstable as a binary package wasn't involved in your scenario.) > If that's the case, then I think because of the way our d-i/debian-cd > daily and weekly builds are done, filesystem maintainers need to make > sure that their filesystem-creation tools don't enable a new feature > by default until that feature is (at least minimally) supported by the > corresponding fsck tool *in testing*, and immediately enabling a new > feature as soon as the fsck tool in unstable supports it is too soon. That would seem sensible to me. > In that case this report should probably be reassigned to e2fsprogs, > as a request to stop enabling orphan_file by default until at least the > time that e2fsprogs (>= 1.47.0) has reached testing (but perhaps lower > risk to delay enabling it by default until post-bookworm). The immediate issue should go away for Bookworm anyway: https://bugs.debian.org/1031325#202 And once the feature is turned off, the package might migrate, and everything should be all set for when the feature is turned on again. But feel free to reassign this bug report to keep track of it, there's nothing to be done on the debian-boot/debian-cd side. > Cyril, sorry if I've been saying "d-i" too often here: I don't know > which bits of this are a d-i responsibility and which are a debian-cd > responsibility. That's fine, debian-cd has been Steve mostly, even if I've been getting more involved over the last two release cycles; bugs reports generate the same “bug ownership” feeling when they pop up in either side. Both debian-installer and debian-cd (as in debian-cd.git and setup.git) are inherently intertwined anyway. (Except when I'm utterly confused by a longstanding documentation vs. reality mismatch) I tend to have a vague idea of what's going on in both areas to figure things out… > I reported this to installation-reports because I didn't know which > component was causing this, only that an installation that I thought > was intended to be a supported use-case had failed. Everything you did was very fine. I just didn't realize we were actually publishing images where we ship known bugs… :( Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck
Hi Simon, Cyril Brulebois (2023-02-19): > Simon McVittie (2023-02-19): > > Are d-i alphas and weekly builds built differently? Is it perhaps the > > case that alphas are built from testing udebs, while weeklies are built > > from unstable udebs? > > Let's quote <https://www.debian.org/devel/debian-installer/index.en>: > - Or install the current weekly snapshot of Debian testing which uses >the same version of the installer as the last release: >> Current weekly snapshots > - If you prefer to use the latest and greatest, either to help us test >a future release of the installer or because of hardware problems or >other issues, try one of these daily built images which contain the >latest available version of installer components. >> Current daily snapshots > > We're in the first case: > https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/ > > > I don't know how to list the versions of the installed udebs and > > mke2fs doesn't seem to have a --version option > > You can check /var/lib/dpkg/status (or look at the MANIFEST.udebs file > in the d-i tree if you know where udebs came from). > > Here, e2fsprogs-udeb is at 1.47.0-1, which explains the problem. But the > installer is clearly not “the same versions of the installer as the last > release” since it features linux 6.1.8-1… > > Cc-ing debian-cd@ for input; quoting the rest of your reply in full. Having focussed my attention on d-i releases for so many years whenever debian-cd was involved, it appears I totally missed a big change that happened before I drew short straw for “who's doing d-i now?”, and that was never documented on the website, so we've been lying for 12 years… Weekly build setup change: https://salsa.debian.org/images-team/setup/-/commit/6dcb58e3259036b56925ef277010ce85037b7abd Tentative fix in: https://salsa.debian.org/webmaster-team/webwml/-/commit/a22870164df5007ae4f4e356dfe54983be0f1e9e Already visible on: https://www.debian.org/devel/debian-installer/index.en Sorry for the confusion… and thanks for insisting after my initial and too hasty “it's a known bug, everything's fine” half-assessment… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck
Simon McVittie (2023-02-19): > Are d-i alphas and weekly builds built differently? Is it perhaps the > case that alphas are built from testing udebs, while weeklies are built > from unstable udebs? Let's quote <https://www.debian.org/devel/debian-installer/index.en>: - Or install the current weekly snapshot of Debian testing which uses the same version of the installer as the last release: > Current weekly snapshots - If you prefer to use the latest and greatest, either to help us test a future release of the installer or because of hardware problems or other issues, try one of these daily built images which contain the latest available version of installer components. > Current daily snapshots We're in the first case: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/ > I don't know how to list the versions of the installed udebs and > mke2fs doesn't seem to have a --version option You can check /var/lib/dpkg/status (or look at the MANIFEST.udebs file in the d-i tree if you know where udebs came from). Here, e2fsprogs-udeb is at 1.47.0-1, which explains the problem. But the installer is clearly not “the same versions of the installer as the last release” since it features linux 6.1.8-1… Cc-ing debian-cd@ for input; quoting the rest of your reply in full. > I had expected that weekly builds are expected to be able to install > testing. If that expectation is correct, then that means weekly builds > need to be built from udebs that will create a filesystem that is > considered acceptable by testing user-space (and bootloaders and kernels, > but this bug report is about user-space). > > > Closing this bug report as it's not a practical issue with the version > > just released, and since it shouldn't be an issue with later releases > > given grub2 in testing should cope just fine. > > Note that my bug report is not about whether grub2 in testing copes > with the filesystem created by d-i: when I installed from the 2023-02-09 > weekly build, grub successfully loaded my kernel and initramfs, so that > part at least seems fine. The issue I was having is that the *initramfs* > from the testing system I installed did not cope. > > If I'm right about weeklies being built from unstable udebs, then I > think this will continue to be a problem *for weekly builds* until either: > a version of e2fsprogs that can fsck filesystems with metadata_csum_seed > and orphan_file migrates to testing; or e2fsprogs stops enabling those > features on at least the filesystems created in d-i (optionally all new > filesystems, but this particular bug report is about d-i only). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031534: firmware-linux-nonfree: Package removed from sid and bookworm
Gregor Riepl (2023-02-17): > > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#non-free-split > > Oh, I just saw that this page mentions that apt should have shown a > notice to previous users of firmware-linux-nonfree, but I never saw > this notice. Note the “If you were”. > How exactly was this implemented, and what could be the reason why I > didn't see it? This is WIP: https://salsa.debian.org/apt-team/apt/-/merge_requests/282 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031431: debian-installer-netboot-images: FTBFS: Building 20220917, but bookworm has 20230207, failing the build
Lucas Nussbaum (2023-02-17): > OK, I remembered about skipping debian-installer, but wasn't sure about > debian-installer-netboot-images Thanks and sorry for being a pain, I know we're the usual ugly duckling in the project… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an ISO install.
Control: tag -1 - d-i Control: severity -1 normal Hi, Steve Roggenkamp (2023-02-15): > Package: installation-reports > Severity: serious > Tags: d-i > Justification: Policy 3.7, 10.1 > X-Debbugs-Cc: roggenka...@acm.org > > (Please provide enough information to help the Debian > maintainers evaluate the report efficiently - e.g., by filling > in the sections below.) > > Boot method: via a Docker build > Image version: bullseye-slim current If you're using a Docker build, you're definitely not using the installer, so removing the d-i flag. Furthermore, I'm pretty sure Docker images are meant to be lightweight, and you aren't normally supposed to log in and inspect processes inside such images, so I can perfectly understand why people responsible for it didn't include procps. Lowering severity and cc-ing accordingly. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031197: firmware-ath9k-htc: Conflict with firmware-atheros < 20230210-1
Control: notfound -1 1.4.0-108-gd856466+dfsg1-1 Control: found -1 1.4.0-108-gd856466+dfsg1-1.1 Cyril Brulebois (2023-02-13): > Tianyu Chen (2023-02-13): > > Package: firmware-ath9k-htc > > Version: 1.4.0-108-gd856466+dfsg1-1 > > Severity: normal > > X-Debbugs-Cc: billchenchina2...@gmail.com > > Thanks for reporting, I was about to do that for you after seeing your > report on IRC. :) I missed the version skew in the original bug report, fixing. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
Theodore Ts'o (2023-02-10): > But that problem has already been solved by cloning the bug back to > e2fpsrogs (#1030939) which will prevent e2fsprogs from transitioning > to testing, no? So what's the problem. I never said there was a problem with the current state of things (indeed, that's one of the two soltions I described as being equally fine with me). Instead, I've explained why your suggested “solution” wouldn't help, with some context since you seemed unconvinced by previous answers from others. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
Theodore Ts'o (2023-02-09): > On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote: > > That is not going to help, because IIUC grub-install is run from the > > target system that you are installing, and there is no > > grub2-common-udeb. > > Right, but if the conflict in e2fsprogs-udeb prevents the installer > from pulling in an overly new version of e2fsprogs-udeb, that woul be > sufficient, no? As Sven rightfully pointed out, there are two different environments: - installer, with anna and udebs (but that would be the same with apt and debs); - target. There are no connections between both environments, so you can't have package relationships in a cross-environment manner. The installer uses whatever was available at build-time, or for components that aren't built-in, whatever is available on the installation image, or on the mirror. There's no “pulling in an overly new version” that can be avoided. There's *one* version in the suite, that's the one that's getting used, there's no alternative. TL;DR: Some Conflicts, even if that were possible (which it is not) wouldn't achieve anything (except probably not offering any ext* option at the partioning step — not a huge win). > The reason why I really don't want to add the conflicts with e2fsprogs > 1.47 is because for people who are using sid, there is aboslutely > nothing wrong with installing e2fsprogs 1.47. It's only if they use > the installer that sucks in e2fsprogs that there's a problem --- it's > not an inherent conflict with grub per se. If it were, then we > shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream > is painfully slow in putting out releases --- and that's not > reasonable. *sigh* @ the heavy finger pointing in various parts of your mail. > Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to > remove the default use of the csum-seed feature but is it worth > it? Hopefully the new version of grub2 will come out soon, at which > point I would then need to revert the hacked mke2fs.conf --- and your > dup'ing this bug should prevent the installer from picking up > e2fsprogs 1.47 until the new version of grub gets released. Right now what I'm most concerned with is getting grub2 fixed in unstable, candidate for migration into testing. Until that happens, e2fsprogs must be kept out of testing, so that the installer cannot get a too-new e2fsprogs with a too-old grub2. Whether we introduce a relationship between both packages making britney wait on grub2's being ready to allow e2fsprogs to migrate alongside it, or we keep an RC bug on e2fsprogs to keep it out of testing until grub2 gets fixed and migrated into testing… doesn't matter much to me. I'll word it differently because I'd like to avoid more mails on this thread: The installer pulls components for the target system from a single distribution, there's no set of existing packages that can be kept around (as that would be the case for existing systems using testing or unstable), so we need packages in the distribution being installed to be consistent. Right now: unstable is broken; testing isn't. [ snip stuff about grub design ] > Holding back file system development because grub2 uptsream is super > slow doesn't seem like a reasonable way forward, so I really don't > want to set this precedent. The Bookworm freeze has started, we need to be able to install stuff, so we need a solution for the grub2/e2fsprogs situation *now*. I really don't care about “setting a precedent”. [ snip brainstorming ] Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize
Package: e2fsprogs Version: 1.47.0-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: debian-b...@lists.debian.org, gr...@packages.debian.org (Please keep debian-b...@lists.debian.org and gr...@packages.debian.org in the loop.) Hi, Spotted via debian-installer tests: grub-install fails with “unknown filesystem” when trying to run a simple `grub-install /dev/sda` with an all-default installation. While there might be something wrong about e2fsprogs-udeb specifically, possibly only affecting the installer context, I'm not sure what that means for existing systems, hence the severity. The “e2fsprogs gets a new upstream release and new flags” hypothesis was confirmed by building d-i with e2fsprogs-udeb_1.46.6-1_amd64.udeb rebranded as 1.48, which made the problem disappear. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1030007: installation-guide: must document non-free-firmware support
Source: installation-guide Severity: serious Tags: patch Justification: RoM Hi, A draft adding support for non-free-firmware can be found at: https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/23 Reviews there are welcome. I do not plan on spending much more time on this topic. I'd be happy if people could just take over, improve the wording, etc. I'm also fine with answering any questions one might have about those changes, or the proposed documentation updates. Note: I decided *against* adding anything about the firmware cpio archive, because the existing page is about preparing a removable medium. It seems like an “advanced user” use case anyway, so we can probably add a note on the relevant wiki page[1] and let people further refresh it from there. 1. https://wiki.debian.org/DebianInstaller/NetbootFirmware Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1029814: ixp4xx-microcode: no longer useful, ixp4xx support dropped in 2014
Package: ixp4xx-microcode Severity: serious Justification: obsolete X-Debbugs-Cc: debian-b...@lists.debian.org Hi, [Please include debian-boot@ in your replies.] For context, here's my initial list of packages that seemed interesting enough to move from non-free to non-free-firmware: https://lists.debian.org/debian-boot/2023/01/msg00150.html This was a quick, initial search, on amd64 only, so I hadn't seen this armel-only package yet; but I'm going through an extensive search this time! :) Anyway, ixp4xx support was dropped from the Debian Linux kernel a long time ago (and from the installer later, once we noticed): ,--- | linux (3.17-1~exp1) experimental; urgency=medium | | * New upstream release: http://kernelnewbies.org/Linux_3.17 | | * armel: Drop ixp4xx image. | * topconfig: Reenable renamed IP_NF_NAT. (closes #762458) | * udeb: refix renamed i2c-core. | | -- maximilian attems Tue, 14 Oct 2014 23:01:39 +0200 `--- So I'm not sure it makes sense to keep this package in the archive. If there are still valid reasons to keep it, that's fine: just close this bug report, and move your package from non-free to non-free-firmware, so that users have a single place to configure to find all firmware packages (release notes etc. are being worked on). Thanks for your time! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart
Hi Oleg, Oleg A. Arkhangelsky (2023-01-26): > After some digging I think that there is more elegant way to stop > ifup@*.service when stopping (or restarting) networking.serivce, we just > need to add PartOf to /lib/systemd/system/ifup@.service: > > [Unit] > ... > PartOf=networking.service > > And this ExecStart to /lib/systemd/system/networking.service, to make > networking.service restart workable for "allow-hotplug" interfaces (as > per your suggestion): > > [Service] > ... > ExecStart=/usr/bin/udevadm trigger --action=add --subsystem-match=net > ... > > This changes should be on top of *.service files, before any Bug#1029352 > modifications, of course. > > Seems like more clearer way, than to use /bin/sh invocation and flag file > for the non-first run condition check. > > Any pitfalls for this approach? Just to clarify: I was mostly interested in getting the initial regression fixed, as it was in the way of finally fixing wireless support (via /e/n/i rather than NM) in the installer. I tried to keep the proposed enhancement while making sure the regression wouldn't come back, hence the “convoluted” approach. I'm happy if you folks keep digging into this to find a better solution by tweaking systemd units. I'll just mention that the freeze is underway, that a simple enhancement (making restart work) totally broke a much more important use case (keeping start working), and someone probably needs to weigh pros (getting things better, in a clean way) versus cons (not a lot of time to discover and track down possible side effects, be them positive or negative). If things break for the installer again: (in a deep voice) I'll be back! ;) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart
Hi Oleg, Oleg A. Arkhangelsky (2023-01-23): > I tried this *.deb (Pascal approach). It doesn't change behaviour > introduced after this patch [1]. Yes, restart for "allow-hotplug" > interfaces work but I got the same system boot lag in Jeff configuration. Right, I mostly tested that an available “allow-hotplug” and an available “auto” interfaces in my VM work fine when I tested Pascal's approach, I didn't try to disable any of them in my hypervisor. > Cyril's latest solution seems to work. I just added "-" to /bin/sh to > deal with cases when we have a device that is really hotplug and > absent: […] Right, thanks for implementing and testing the part: as I mentioned, I wasn't sure what to do about possible errors, and didn't investigate; your approach seems reasonable given hotpluggable interfaces may or may not be present. > I got fast boot (as without bad patch) and working restart. One minute > long blocking during `systemctl restart networking` when DHCP is not > respoding (as in Jeff config) is expected. > > Thanks to all! Thanks to both Jeff and you for your tests! I do note that taking precautions, maintaining the status quo for working use cases, while addressing other use cases… is sometimes not that bad; even if that seems “needlessly convoluted”! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1029352: netcfg: broken ifupdown support for wireless interfaces
Control: tag -1 pending Cyril Brulebois (2023-01-21): > I've pushed three commits in the pu/ifupdown+wireless branch: > > https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless Updated branch: https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless-v2 > Commit links: > 1. > https://salsa.debian.org/installer-team/netcfg/-/commit/9494d7ec02b32538db842d88c105db1ab2a6201b > 2. > https://salsa.debian.org/installer-team/netcfg/-/commit/247056dbb22e6eacbea6348c5c9a6951eab948bd > 3. > https://salsa.debian.org/installer-team/netcfg/-/commit/5ca665c6c26346e3c9c37c2df6366e8e5d718238 Updated commits, with changelog entries this time (no code change): 1. https://salsa.debian.org/installer-team/netcfg/-/commit/aa62245f2960363f8b16f1f30d666936cc88bc83 2. https://salsa.debian.org/installer-team/netcfg/-/commit/815cdfccaa5567fdf53594d47545d97c235de68e Please note the third commit got moved to another branch: https://salsa.debian.org/installer-team/netcfg/-/tree/pu/disable-hotplug-detection https://salsa.debian.org/installer-team/netcfg/-/commit/9000be355b5e35134958c2655ec35bc75ba1b7e7 I suppose we can postpone wondering what to do about hotplug support (netcfg currently believes everything is hotpluggable…) to a later time (after bookworkm) given the broken “allow-hotplug” support at boot-up (third issue) was an ifupdown regression in the end: #1022843. My current plan includes more work on hw-detect; I'll upload netcfg with commits from the ifupdown+wireless-v2 branch once I'm done (probably in a few hours). Feedback regarding the netcfg commits is still very much welcome (even after the upload, we can still tweak things before the release). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart
Hi Santiago, Santiago Ruano Rincón (2023-01-23): > Thanks everybody for the inputs. I've applied Paul's solution, and the > generated .deb can be downloaded from here: > > https://salsa.debian.org/debian/ifupdown/-/jobs/3841392/artifacts/raw/debian/output/ifupdown_0.8.41~1.gbp3a6fae+salsaci+20230123+42_amd64.deb > > Would it be possible for you (Oleg, Paul, Jeff, kibi et al.) to give it > a try? (Reading your mail with s/Paul/Pascal/g in mind.) Tests yesterday seem to indicate successful results, but again I've only tested a few combinations in a VM (to keep the feedback loop short). From the installer team point of view, I'd welcome a swift upload with this patch, possibly with urgency=high so that the fix reaches testing soon. This will another blocker out of the way for the next D-I release! Thanks! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart
Cyril Brulebois (2023-01-22): > The configuration found below manages to: > - let my allow-hotplug slow-to-appear wireless interface come up at >boot-up, via the udev integration; > - allow me to stop and start networking, losing then regaining all >relevant configs (main connection is wireless, with WPA, with DHCP, >and SLAAC via RAs, without /e/n/i conf for SLAAC, see #1029352); > - allow me to restart networking, [same as previous entry]. > > This is just an example of something that seems to be working fine > enough during my very limited testing, there might be cleaner ways to do > this, better names to choose (I picked a neutral “environment” but my > first thought was an explicit “maybe-redo-hotplug”), etc.: > > [Service] > Type=oneshot > EnvironmentFile=-/etc/default/networking > EnvironmentFile=-/run/network/environment > ExecStart=/sbin/ifup -a --read-environment $ALLOW_HOTPLUG > ExecStop=/sbin/ifdown -a --read-environment --exclude=lo > ExecStopPost=/bin/sh -c "echo ALLOW_HOTPLUG=--allow=hotplug > > /run/network/environment" > RemainAfterExit=true > TimeoutStartSec=5min > > Changes (compared to the original ifupdown service unit): > - an extra /run/network/environment is read if present, no errors >otherwise; of course it doesn't exist during boot-up, since >/run is brand new and nothing else is creating it; > - ExecStopPost populates that file with ALLOW_HOTPLUG=--allow=hotplug >after each “stop” (possibly part of a “restart”) is done; > - ExecStart gets an extra $ALLOW_HOTPLUG parameter, that's either >an empty string (at boot-up) or --allow=hotplug (after boot-up). Of course I'm not familiar with the ifup interface so I fudged it. Now, with an extra ens3 declared as auto, the following seems to work fine for boot-up, stop and start, and restart: [Service] Type=oneshot EnvironmentFile=-/etc/default/networking ExecStart=/sbin/ifup -a --read-environment ExecStart=/bin/sh -c 'if [ -f /run/network/restart-hotplug ]; then /sbin/ifup -a --read-environment --allow=hotplug; fi' ExecStop=/sbin/ifdown -a --read-environment --exclude=lo ExecStopPost=/usr/bin/touch /run/network/restart-hotplug RemainAfterExit=true TimeoutStartSec=5min I have no opinions on how to best handle possible errors regarding the hotplug interfaces; but again, that's secondary compared to fixing the “start” use case. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart
Control: reopen 1022843 Control: found 1022843 0.8.40 Control: severity 1022843 serious Hi, Cyril Brulebois (2023-01-22): > d-i believes that everything should be allow-hotplug, and we end up > using that everywhere. I'm wondering whether to just use auto everywhere > instead, since the hotplug detection is busted. > > More details in: > https://bugs.debian.org/1029352 > > (which is mainly about wireless interfaces but ends up in the third > issue about other kinds of interfaces as well.) I've done some testing, and I think the patch is making matters worse: - networking.service can start very early, at which point interfaces might not be ready yet, firmware loaded, etc. - with the extra ExecStart, forcing allow-hotplug entries, and ignoring failures, I strongly suspect (but didn't triple-check) that we end up with interfaces getting considered up even if they aren't, which interfers with the udev integration (the /lib/udev/ifupdown-hotplug script no longer works: the interface is supposed to be up already!). It looks to me that this patch should be reverted for bookworm, as it aims to make “restart” work, but it breaks simple “start”. It seems systemd supports an ExecReload directive, but no matching ExecRestart, so I think we end up with restart forcingly calling ExecStop then ExecStart (plus relevant Pre/Post if any). I have no idea about ifupdown's architecture, but it looks to me that it might make sense to have some way of knowing whether that's the first time the unit is started, if which case stick to the working, existing logic. And if it's not, add --allow=hotplug. I don't think we can use systemd unit's NRestarts since it counts restarts triggered via Restart=always and friends, so maintaining a flag file instead might work? The configuration found below manages to: - let my allow-hotplug slow-to-appear wireless interface come up at boot-up, via the udev integration; - allow me to stop and start networking, losing then regaining all relevant configs (main connection is wireless, with WPA, with DHCP, and SLAAC via RAs, without /e/n/i conf for SLAAC, see #1029352); - allow me to restart networking, [same as previous entry]. This is just an example of something that seems to be working fine enough during my very limited testing, there might be cleaner ways to do this, better names to choose (I picked a neutral “environment” but my first thought was an explicit “maybe-redo-hotplug”), etc.: [Service] Type=oneshot EnvironmentFile=-/etc/default/networking EnvironmentFile=-/run/network/environment ExecStart=/sbin/ifup -a --read-environment $ALLOW_HOTPLUG ExecStop=/sbin/ifdown -a --read-environment --exclude=lo ExecStopPost=/bin/sh -c "echo ALLOW_HOTPLUG=--allow=hotplug > /run/network/environment" RemainAfterExit=true TimeoutStartSec=5min Changes (compared to the original ifupdown service unit): - an extra /run/network/environment is read if present, no errors otherwise; of course it doesn't exist during boot-up, since /run is brand new and nothing else is creating it; - ExecStopPost populates that file with ALLOW_HOTPLUG=--allow=hotplug after each “stop” (possibly part of a “restart”) is done; - ExecStart gets an extra $ALLOW_HOTPLUG parameter, that's either an empty string (at boot-up) or --allow=hotplug (after boot-up). If people want to discuss this further, please feel free to, but I'd welcome a quick revert of the initial patch for #1022843: unbreaking “start” seems much more important than fixing a longstanding shortage in “restart”. But I'm sure Oleg can help us figure out whether this proposed change makes sense (maybe also testing on bullseye), so that we can fix the regression and the original issue by keeping track of this single bug report. Otherwise, I can file a different bug report about the regression specifically. Reopening and bumping severity on #1022843 for the time being. This might mean considering the third issue listed in #1029352 as a non-issue, at least for bookworm: we could keep listing (apparently) all interfaces as “allow-hotplug”. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
