Bug#1072984: bookworm-pu: package crowdsec-firewall-bouncer/0.0.25-4~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: crowdsec-firewall-boun...@packages.debian.org Control: affects -1 + src:crowdsec-firewall-bouncer Hi, [ Reason ] I'd like to fix the #1071247/#1071248 pair in bookworm, which results in crowdsec-firewall-bouncer's being broken on little-endian architectures (addresses are getting logged just fine, but they're not passed over correctly to the firewall layer). I've checked with the security team, this doesn't warrant a DSA. This is the daemon part (crowdsec-firewall-bouncer). [ Impact ] If the fix doesn't make it into stable, crowdsec-firewall-bouncer remains broken on little-endian architectures. [ Tests ] Same checks as for unstable when I uploaded the fixes there: - amd64 (LE, baremetal) before: KO - amd64 (LE, baremetal) after: OK - s390x (BE, debvm) before: OK - s390x (BE, debvm) after: OK [ Risks ] Except for a possible regression on s390x (which isn't the case, see previous section), it cannot be worse than it currently is. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable Additionally, that reached testing. [ Changes ] Since there were already binNMUs for this package in p-u, with different versions, I decided to err on the side of caution, and to propose a new revision with a versioned build-dep on golang-github-google-nftables's binary package; alternatively this package could be binNMU'd within p-u once golang-github-google-nftables is available in p-u. [ Other info ] Previous bug report is the golang-github-google-nftables part. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/changelog crowdsec-firewall-bouncer-0.0.25/debian/changelog --- crowdsec-firewall-bouncer-0.0.25/debian/changelog 2023-05-31 18:57:41.0 +0200 +++ crowdsec-firewall-bouncer-0.0.25/debian/changelog 2024-06-11 10:20:58.0 +0200 @@ -1,3 +1,18 @@ +crowdsec-firewall-bouncer (0.0.25-4~deb12u1) bookworm; urgency=medium + + * Rebuild for bookworm. + + -- Cyril Brulebois Tue, 11 Jun 2024 10:20:58 +0200 + +crowdsec-firewall-bouncer (0.0.25-4) unstable; urgency=high + + * 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). + + -- Cyril Brulebois Tue, 21 May 2024 10:15:36 +0200 + crowdsec-firewall-bouncer (0.0.25-3) unstable; urgency=medium * Fix failure to install if crowdsec is unpacked but not configured diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/control crowdsec-firewall-bouncer-0.0.25/debian/control --- crowdsec-firewall-bouncer-0.0.25/debian/control 2023-03-21 01:03:29.0 +0100 +++ crowdsec-firewall-bouncer-0.0.25/debian/control 2024-05-21 09:53:53.0 +0200 @@ -10,7 +10,7 @@ golang-github-coreos-go-systemd-dev, golang-github-crowdsecurity-crowdsec-dev, golang-github-crowdsecurity-go-cs-bouncer-dev, - golang-github-google-nftables-dev, + golang-github-google-nftables-dev (>= 0.1.0-4~), golang-golang-x-sys-dev, golang-gopkg-natefinch-lumberjack.v2-dev, golang-gopkg-tomb.v2-dev,
Bug#1072983: bookworm-pu: package golang-github-google-nftables/0.1.0-4~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-google-nftab...@packages.debian.org
Control: affects -1 + src:golang-github-google-nftables
Hi,
[ Reason ]
I'd like to fix the #1071247/#1071248 pair in bookworm, which results in
crowdsec-firewall-bouncer's being broken on little-endian architectures
(addresses are getting logged just fine, but they're not passed over
correctly to the firewall layer).
I've checked with the security team, this doesn't warrant a DSA.
This is the library part (golang-github-google-nftables).
[ Impact ]
If the fix doesn't make it into stable, crowdsec-firewall-bouncer
remains broken on little-endian architectures.
[ Tests ]
Same checks as for unstable when I uploaded the fixes there:
- amd64 (LE, baremetal) before: KO
- amd64 (LE, baremetal) after: OK
- s390x (BE, debvm) before: OK
- s390x (BE, debvm) after: OK
[ Risks ]
Except for a possible regression on s390x (which isn't the case, see
previous section), it cannot be worse than it currently is.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
Additionally, that reached testing.
[ Changes ]
The fix is a direct backport from upstream, which adds byte order
information to the function used by crowdsec-firewall-bouncer
(AddSet).
[ Other info ]
Next bug report is the crowdsec-firewall-bouncer part.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru golang-github-google-nftables-0.1.0/debian/changelog
golang-github-google-nftables-0.1.0/debian/changelog
--- golang-github-google-nftables-0.1.0/debian/changelog2022-12-12
05:07:14.0 +0100
+++ golang-github-google-nftables-0.1.0/debian/changelog2024-06-11
10:22:28.0 +0200
@@ -1,3 +1,18 @@
+golang-github-google-nftables (0.1.0-4~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm.
+
+ -- Cyril Brulebois Tue, 11 Jun 2024 10:22:28 +0200
+
+golang-github-google-nftables (0.1.0-4) unstable; urgency=high
+
+ * 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):
+ - 0002-Implement-set-KeyByteOrder-226.patch
+
+ -- Cyril Brulebois Tue, 21 May 2024 09:42:17 +0200
+
golang-github-google-nftables (0.1.0-3) unstable; urgency=medium
* Backport fix from upstream to fix the test suite on 32-bit archs (the
diff -Nru
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
---
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
1970-01-01 01:00:00.0 +0100
+++
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
2024-05-15 13:08:54.0 +0200
@@ -0,0 +1,42 @@
+From d746ecb0e494e7200180c3886fde9664d9100729 Mon Sep 17 00:00:00 2001
+From: turekt <32360115+tur...@users.noreply.github.com>
+Date: Thu, 18 May 2023 18:05:49 +0200
+Subject: [PATCH] Implement set KeyByteOrder (#226)
+
+Fixes https://github.com/google/nftables/issues/225
+Introduced KeyByteOrder in sets which fills UDATA with endianess information
+---
+ set.go | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/set.go b/set.go
+index 1ef8e89..b1f63e8 100644
+--- a/set.go
b/set.go
+@@ -261,6 +261,9 @@ type Set struct {
+ Timeout time.Duration
+ KeyType SetDatatype
+ DataType SetDatatype
++ // Either host (binaryutil.NativeEndian) or big (binaryutil.BigEndian)
endian as per
++ //
https://git.netfilter.org/nftables/tree/include/datatype.h?id=d486c9e626405e829221b82d738005b26d8a#n109
++ KeyByteOrder binaryutil.ByteOrder
+ }
+
+ // SetElement represents a data point within a set.
+@@ -560,11 +563,11 @@ func (cc *Conn) AddSet(s *Set, vals []SetElement) error {
+ // Marshal concat size description as set description
+ tableInfo = append(tableInfo, netlink.Attribute{Type:
unix.NLA_F_NESTED | unix.NFTA_SET_DESC, Data: concatBytes})
+ }
+- if s.Anonymous || s.Constant || s.Interval {
++ if s.Anonymous || s.Constant || s.Interval || s.KeyByteOrder ==
binaryutil.BigEndian {
+ tableInfo = append(tableInfo,
+ // Semantically useless - kept for binary compatability
with nft
+ netlink.Attribute{Type: unix.NFTA_SET_USERDATA, Data:
[]byte("\x00\x04\x02\x00\x00\x00")})
+- } else if !s.IsMap {
++ } else if s.KeyByteOrder == binaryutil.NativeEndian {
+
Bug#1072984: bookworm-pu: package crowdsec-firewall-bouncer/0.0.25-4~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: crowdsec-firewall-boun...@packages.debian.org Control: affects -1 + src:crowdsec-firewall-bouncer Hi, [ Reason ] I'd like to fix the #1071247/#1071248 pair in bookworm, which results in crowdsec-firewall-bouncer's being broken on little-endian architectures (addresses are getting logged just fine, but they're not passed over correctly to the firewall layer). I've checked with the security team, this doesn't warrant a DSA. This is the daemon part (crowdsec-firewall-bouncer). [ Impact ] If the fix doesn't make it into stable, crowdsec-firewall-bouncer remains broken on little-endian architectures. [ Tests ] Same checks as for unstable when I uploaded the fixes there: - amd64 (LE, baremetal) before: KO - amd64 (LE, baremetal) after: OK - s390x (BE, debvm) before: OK - s390x (BE, debvm) after: OK [ Risks ] Except for a possible regression on s390x (which isn't the case, see previous section), it cannot be worse than it currently is. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable Additionally, that reached testing. [ Changes ] Since there were already binNMUs for this package in p-u, with different versions, I decided to err on the side of caution, and to propose a new revision with a versioned build-dep on golang-github-google-nftables's binary package; alternatively this package could be binNMU'd within p-u once golang-github-google-nftables is available in p-u. [ Other info ] Previous bug report is the golang-github-google-nftables part. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/changelog crowdsec-firewall-bouncer-0.0.25/debian/changelog --- crowdsec-firewall-bouncer-0.0.25/debian/changelog 2023-05-31 18:57:41.0 +0200 +++ crowdsec-firewall-bouncer-0.0.25/debian/changelog 2024-06-11 10:20:58.0 +0200 @@ -1,3 +1,18 @@ +crowdsec-firewall-bouncer (0.0.25-4~deb12u1) bookworm; urgency=medium + + * Rebuild for bookworm. + + -- Cyril Brulebois Tue, 11 Jun 2024 10:20:58 +0200 + +crowdsec-firewall-bouncer (0.0.25-4) unstable; urgency=high + + * 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). + + -- Cyril Brulebois Tue, 21 May 2024 10:15:36 +0200 + crowdsec-firewall-bouncer (0.0.25-3) unstable; urgency=medium * Fix failure to install if crowdsec is unpacked but not configured diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/control crowdsec-firewall-bouncer-0.0.25/debian/control --- crowdsec-firewall-bouncer-0.0.25/debian/control 2023-03-21 01:03:29.0 +0100 +++ crowdsec-firewall-bouncer-0.0.25/debian/control 2024-05-21 09:53:53.0 +0200 @@ -10,7 +10,7 @@ golang-github-coreos-go-systemd-dev, golang-github-crowdsecurity-crowdsec-dev, golang-github-crowdsecurity-go-cs-bouncer-dev, - golang-github-google-nftables-dev, + golang-github-google-nftables-dev (>= 0.1.0-4~), golang-golang-x-sys-dev, golang-gopkg-natefinch-lumberjack.v2-dev, golang-gopkg-tomb.v2-dev,
Bug#1072983: bookworm-pu: package golang-github-google-nftables/0.1.0-4~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-google-nftab...@packages.debian.org
Control: affects -1 + src:golang-github-google-nftables
Hi,
[ Reason ]
I'd like to fix the #1071247/#1071248 pair in bookworm, which results in
crowdsec-firewall-bouncer's being broken on little-endian architectures
(addresses are getting logged just fine, but they're not passed over
correctly to the firewall layer).
I've checked with the security team, this doesn't warrant a DSA.
This is the library part (golang-github-google-nftables).
[ Impact ]
If the fix doesn't make it into stable, crowdsec-firewall-bouncer
remains broken on little-endian architectures.
[ Tests ]
Same checks as for unstable when I uploaded the fixes there:
- amd64 (LE, baremetal) before: KO
- amd64 (LE, baremetal) after: OK
- s390x (BE, debvm) before: OK
- s390x (BE, debvm) after: OK
[ Risks ]
Except for a possible regression on s390x (which isn't the case, see
previous section), it cannot be worse than it currently is.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
Additionally, that reached testing.
[ Changes ]
The fix is a direct backport from upstream, which adds byte order
information to the function used by crowdsec-firewall-bouncer
(AddSet).
[ Other info ]
Next bug report is the crowdsec-firewall-bouncer part.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru golang-github-google-nftables-0.1.0/debian/changelog
golang-github-google-nftables-0.1.0/debian/changelog
--- golang-github-google-nftables-0.1.0/debian/changelog2022-12-12
05:07:14.0 +0100
+++ golang-github-google-nftables-0.1.0/debian/changelog2024-06-11
10:22:28.0 +0200
@@ -1,3 +1,18 @@
+golang-github-google-nftables (0.1.0-4~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm.
+
+ -- Cyril Brulebois Tue, 11 Jun 2024 10:22:28 +0200
+
+golang-github-google-nftables (0.1.0-4) unstable; urgency=high
+
+ * 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):
+ - 0002-Implement-set-KeyByteOrder-226.patch
+
+ -- Cyril Brulebois Tue, 21 May 2024 09:42:17 +0200
+
golang-github-google-nftables (0.1.0-3) unstable; urgency=medium
* Backport fix from upstream to fix the test suite on 32-bit archs (the
diff -Nru
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
---
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
1970-01-01 01:00:00.0 +0100
+++
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
2024-05-15 13:08:54.0 +0200
@@ -0,0 +1,42 @@
+From d746ecb0e494e7200180c3886fde9664d9100729 Mon Sep 17 00:00:00 2001
+From: turekt <32360115+tur...@users.noreply.github.com>
+Date: Thu, 18 May 2023 18:05:49 +0200
+Subject: [PATCH] Implement set KeyByteOrder (#226)
+
+Fixes https://github.com/google/nftables/issues/225
+Introduced KeyByteOrder in sets which fills UDATA with endianess information
+---
+ set.go | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/set.go b/set.go
+index 1ef8e89..b1f63e8 100644
+--- a/set.go
b/set.go
+@@ -261,6 +261,9 @@ type Set struct {
+ Timeout time.Duration
+ KeyType SetDatatype
+ DataType SetDatatype
++ // Either host (binaryutil.NativeEndian) or big (binaryutil.BigEndian)
endian as per
++ //
https://git.netfilter.org/nftables/tree/include/datatype.h?id=d486c9e626405e829221b82d738005b26d8a#n109
++ KeyByteOrder binaryutil.ByteOrder
+ }
+
+ // SetElement represents a data point within a set.
+@@ -560,11 +563,11 @@ func (cc *Conn) AddSet(s *Set, vals []SetElement) error {
+ // Marshal concat size description as set description
+ tableInfo = append(tableInfo, netlink.Attribute{Type:
unix.NLA_F_NESTED | unix.NFTA_SET_DESC, Data: concatBytes})
+ }
+- if s.Anonymous || s.Constant || s.Interval {
++ if s.Anonymous || s.Constant || s.Interval || s.KeyByteOrder ==
binaryutil.BigEndian {
+ tableInfo = append(tableInfo,
+ // Semantically useless - kept for binary compatability
with nft
+ netlink.Attribute{Type: unix.NFTA_SET_USERDATA, Data:
[]byte("\x00\x04\x02\x00\x00\x00")})
+- } else if !s.IsMap {
++ } else if s.KeyByteOrder == binaryutil.NativeEndian {
+
Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr
Chris Hofstaedtler (2024-05-30): > Yes, having migrated enough packages I (we) believe this is safe. > > Please land this in trixie before the transition freeze. Please let me get the security fixes out of the way and I'll look into those issues afterwards. Feel free to ping back in a week or two if that hasn't happened by then (I don't control answer delays from either security or release teams). Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Re: Adding systemd-boot support in debian-installer
Hi, Luca Boccassi (2024-06-03): > I've created a udeb that adds an expert menu item to allow choosing > systemd-boot (in the NEW queue): > > https://salsa.debian.org/installer-team/systemd-boot-installer The `Architecture: all` in control vs the 64-bit EFI logic in the script seems odd at first glance. Looking at other *-installer, they tend to have a restricted arch list in most cases. I have no strong feelings either way, just something that caught my eye when I first looked into the repository. > A couple of PRs for minimal support: > > https://salsa.debian.org/installer-team/debian-installer-utils/-/merge_requests/12 OK, spotted the todo in the script when I spotted the upload; a versioned dependency will do the trick once the d-i-utils part is reviewed/merged/uploaded. > https://salsa.debian.org/installer-team/d-i/-/merge_requests/17 TIL: builscript. ACK on the .mrconfig part, but I think this misses an addition to packages/po/packages_list (to be confirmed with Holger Wansing). Might be best to get rid of the fuzzy parts still mentioning nobootloader beforehand though. Just something that needs taken care of at some point. > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/46 > > It does not show up in non-expert mode, which is fine for now, > especially as secure boot signing is not yet available. > > After it's been in the testing image like this for a while, and after > we have secure boot integration finished up, would it be ok to show a > question in the non-expert install too? GRUB would still be the > default of course, the question would select it by default, and allow > to switch to sd-boot if chosen. Where would be the best place to add > this? I have close to no knowledge about the details around menu items at the moment. Looking at the good old GRUB vs. LILO duo, I see they had different numbers (7400 for GRUB, 7500 for LILO), not sure whether we should have the same numbers for grub-installer and for systemd-boot-installer. I'm also not sure whether we should offer a choice between those two different booting methods in the course of a normal (non-expert) install. Finally, I'm Cc-ing GRUB people to let them know. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1072501: ITP: systemd-boot-installer -- Install systemd-boot on a hard disk
Hi, Luca Boccassi (2024-06-03): > Package: wnpp > Severity: wishlist > Owner: Luca Boccassi > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: systemd-boot-installer > Version : 0.1 > Upstream Author : Luca Boccassi > * URL : > https://salsa.debian.org/installer-team/systemd-boot-installer > * License : GPL-2.0-or-later > Programming Lang: shell > Description : debian-installer component to install systemd-boot > as the bootloader Could we have some kind of heads-up via X-D-Cc to debian-boot@ for such things, please? Discovering we have a new package under our namespace via a “Processing” mail from ftpmaster is awkward. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1072501: ITP: systemd-boot-installer -- Install systemd-boot on a hard disk
Hi, Luca Boccassi (2024-06-03): > Package: wnpp > Severity: wishlist > Owner: Luca Boccassi > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: systemd-boot-installer > Version : 0.1 > Upstream Author : Luca Boccassi > * URL : > https://salsa.debian.org/installer-team/systemd-boot-installer > * License : GPL-2.0-or-later > Programming Lang: shell > Description : debian-installer component to install systemd-boot > as the bootloader Could we have some kind of heads-up via X-D-Cc to debian-boot@ for such things, please? Discovering we have a new package under our namespace via a “Processing” mail from ftpmaster is awkward. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1072501: ITP: systemd-boot-installer -- Install systemd-boot on a hard disk
Hi, Luca Boccassi (2024-06-03): > Package: wnpp > Severity: wishlist > Owner: Luca Boccassi > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: systemd-boot-installer > Version : 0.1 > Upstream Author : Luca Boccassi > * URL : > https://salsa.debian.org/installer-team/systemd-boot-installer > * License : GPL-2.0-or-later > Programming Lang: shell > Description : debian-installer component to install systemd-boot > as the bootloader Could we have some kind of heads-up via X-D-Cc to debian-boot@ for such things, please? Discovering we have a new package under our namespace via a “Processing” mail from ftpmaster is awkward. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
Luca Boccassi (2024-05-27): > I'll upload a D-I fix that adds x-initrd.attach to crypttab by default > shortly. Yes you can ignore the "unknown option" message, as the > Debian-specific initramfs-tools scripts do not know about it, but > that's fine, it's for the shutdown path anyway. And the finalize > messages can also be ignored. Having a cryptsetup warning about an unknown option on the very first line seen by users after the bootloader step doesn't feel appropriate at all to me. Telling users to just ignore it neither. For the record, on a fresh install, that means: cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'x-initrd.attach' Please unlock disk sda5_crypt: _ Looping in the cryptsetup team. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
Luca Boccassi (2024-05-27): > I'll upload a D-I fix that adds x-initrd.attach to crypttab by default > shortly. Yes you can ignore the "unknown option" message, as the > Debian-specific initramfs-tools scripts do not know about it, but > that's fine, it's for the shutdown path anyway. And the finalize > messages can also be ignored. Having a cryptsetup warning about an unknown option on the very first line seen by users after the bootloader step doesn't feel appropriate at all to me. Telling users to just ignore it neither. For the record, on a fresh install, that means: cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'x-initrd.attach' Please unlock disk sda5_crypt: _ Looping in the cryptsetup team. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Contacting Debian Boot team
Hi, No problems regarding the extensive reply, glad you liked it. I'm trimming all parts that didn't look like they needed a follow-up to keep this brief… Andreas Tille (2024-05-31): > sorry for my late reply - I was basically offline the last couple > of days. No need to be sorry. > However, my question was rather whether you know some valid reasons > why derivatives are exchanging the install method - maybe that > question should be better asked on Debian-Boot (if so feel free to > ignore this question). I was rather wondering about the motivation > for the usage of Ubiquity or Calamares (or others?). I might be naive > but from my perspective installing is something that just needs to > work and having a lot of ways to make this working is somehow burning > developer time. So what according to your insight is motivating > derivatives to solve a problem in a different way that is IMHO solved > by Debian. You seem to be asking the wrong person. I don't know about downstream's motivation, the various alternatives/competitors, etc., and I wouldn't have time to investigate if I wanted to (and I'm not saying that's the case). > Sure there is an arm64 image and I started with copying this to some > USB stick. But that hardware did not booted from an USB device but > only from eprom that had to be flashed via SD card. Its not your > fault definitely but was frustrating for me not beeing able to simply > run the Debian installer. I understand the frustration (“welcome to the ARM world…”) but (1) the initial statements were a very wrong conclusion from your findings and (2) even with hardware that's supposed to be supported by free software we might need time to spot, fix, or workaround bugs (hardware, software, firmware, doc, etc.) or integrate new features to support new boards. That's not specific to d-i, that's just how IT works. > It was not really a claim but a question based on my experience with a > single piece of hardware. I was hoping for some ideas how we could > motivate hardware vendors to deliver hardware that can be easily > booted by simply plugging in some USB device featuring the installer > images we provide on our web page. UEFI/arm64 is a thing. Whether HW vendors actually implement/enable UEFI is another matter entirely (see early EEPROM versions on e.g. Pi 4). > Just keep in mind my offer to contact me in private if needed. That's appreciated, thanks. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.6/11.10
Steve McIntyre (2024-05-27): > On Mon, May 27, 2024 at 01:07:17PM +0100, Jonathan Wiltshire wrote: > > Please indicate availability for: > > > > Saturday 15th June > > Saturday 22nd June > > Saturday 29th June > > Any of those are feasible for me. Ditto. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.6/11.10
Steve McIntyre (2024-05-27): > On Mon, May 27, 2024 at 01:07:17PM +0100, Jonathan Wiltshire wrote: > > Please indicate availability for: > > > > Saturday 15th June > > Saturday 22nd June > > Saturday 29th June > > Any of those are feasible for me. Ditto. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.6/11.10
Steve McIntyre (2024-05-27): > On Mon, May 27, 2024 at 01:07:17PM +0100, Jonathan Wiltshire wrote: > > Please indicate availability for: > > > > Saturday 15th June > > Saturday 22nd June > > Saturday 29th June > > Any of those are feasible for me. Ditto. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071873: marked as pending in debian-installer
Control: tag -1 pending Hello, Bug #1071873 in debian-installer 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/-/commit/c2757c7b0e5a4f14a33531d2cca33f5963142c6b Bump Linux kernel ABI to 6.8.11 (Closes: #1071873). (this message was generated automatically) -- Greetings https://bugs.debian.org/1071873
Re: Contacting Debian Boot team
empty). I'm not sure why you have the impression the installer only work on Intel… See the architectures for which we provide images, the installer is expected to work on all of them. Of course there could still be specific problems for this or that model of a given architecture. But that means filing a bug with details, then see what it can be done. arm* are special as they can be booted in many different ways, like a specific bootloader (Raspberry), u-boot (maybe a vendored copy), and/or flash-kernel (details depend on the board, revision, configuration, etc.), and possibly others. Last I heard about Pinebook, some patches were missing in the upstream (and Debian's kernel) to work at full speed, but the claim above is overly broad and totally false. > - Can I do anything for you? Not at this time. Tschüs! -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
Hoi, Roland Clobus (2024-05-25): > Source: hw-detect > Version: 1.160 > Severity: normal > Tags: patch d-i Just to confirm, which linux version was this tested against? > I have an USB wireless adapter that uses the r8712u kernel module and > that requires firmware from non-free-firmware. > > When I run the Debian installer, the missing firmware file is > correctly identified and installed by 'check-missing-firmware.sh'. > However, the kernel module is mis-identified as 'usb'. As you found out, having 'usb' is rather widespread, hence the existence of the function you patched. What seems weird to my (not at all expert in the kernel area) eyes is the unbound thing that led you to introduce that special case. I see that's a module from staging, maybe it's not behaving like it should? At least differently from other modules… I spotted 1422b526fba994cf05fd288a152106563b875fce that fixed a race condition regarding firmware loading (fix available in v6.6-rc1 and v6.1.52), maybe there are other similar issues? > When I disconnect the adapter and reconnect it, the installer is able > to use the adapter properly. > > Attached is a patch that allows the module to be identified correctly. > If desired, I can send the patch instead as a merge request on Salsa. > > However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not sufficient > to enable the adapter, it still needs a physical reconnect. > In the attached screenshot from the installer (sid) the result of the patch > is shown. Also in the QEMU environment, I need to disconnect and reconnect > the USB device from the host. > > I tried several options, but could not get them to work: bind/unbind [1] > authorized, usbreset [2] > Do you know a solution (apart from a physical reconnect)? I'd suggest a search in upstream bugzilla and mailing lists. I'm adding the kernel maintainers in copy, in case they have better ideas. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
Hoi, Roland Clobus (2024-05-25): > Source: hw-detect > Version: 1.160 > Severity: normal > Tags: patch d-i Just to confirm, which linux version was this tested against? > I have an USB wireless adapter that uses the r8712u kernel module and > that requires firmware from non-free-firmware. > > When I run the Debian installer, the missing firmware file is > correctly identified and installed by 'check-missing-firmware.sh'. > However, the kernel module is mis-identified as 'usb'. As you found out, having 'usb' is rather widespread, hence the existence of the function you patched. What seems weird to my (not at all expert in the kernel area) eyes is the unbound thing that led you to introduce that special case. I see that's a module from staging, maybe it's not behaving like it should? At least differently from other modules… I spotted 1422b526fba994cf05fd288a152106563b875fce that fixed a race condition regarding firmware loading (fix available in v6.6-rc1 and v6.1.52), maybe there are other similar issues? > When I disconnect the adapter and reconnect it, the installer is able > to use the adapter properly. > > Attached is a patch that allows the module to be identified correctly. > If desired, I can send the patch instead as a merge request on Salsa. > > However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not sufficient > to enable the adapter, it still needs a physical reconnect. > In the attached screenshot from the installer (sid) the result of the patch > is shown. Also in the QEMU environment, I need to disconnect and reconnect > the USB device from the host. > > I tried several options, but could not get them to work: bind/unbind [1] > authorized, usbreset [2] > Do you know a solution (apart from a physical reconnect)? I'd suggest a search in upstream bugzilla and mailing lists. I'm adding the kernel maintainers in copy, in case they have better ideas. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
Hoi, Roland Clobus (2024-05-25): > Source: hw-detect > Version: 1.160 > Severity: normal > Tags: patch d-i Just to confirm, which linux version was this tested against? > I have an USB wireless adapter that uses the r8712u kernel module and > that requires firmware from non-free-firmware. > > When I run the Debian installer, the missing firmware file is > correctly identified and installed by 'check-missing-firmware.sh'. > However, the kernel module is mis-identified as 'usb'. As you found out, having 'usb' is rather widespread, hence the existence of the function you patched. What seems weird to my (not at all expert in the kernel area) eyes is the unbound thing that led you to introduce that special case. I see that's a module from staging, maybe it's not behaving like it should? At least differently from other modules… I spotted 1422b526fba994cf05fd288a152106563b875fce that fixed a race condition regarding firmware loading (fix available in v6.6-rc1 and v6.1.52), maybe there are other similar issues? > When I disconnect the adapter and reconnect it, the installer is able > to use the adapter properly. > > Attached is a patch that allows the module to be identified correctly. > If desired, I can send the patch instead as a merge request on Salsa. > > However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not sufficient > to enable the adapter, it still needs a physical reconnect. > In the attached screenshot from the installer (sid) the result of the patch > is shown. Also in the QEMU environment, I need to disconnect and reconnect > the USB device from the host. > > I tried several options, but could not get them to work: bind/unbind [1] > authorized, usbreset [2] > Do you know a solution (apart from a physical reconnect)? I'd suggest a search in upstream bugzilla and mailing lists. I'm adding the kernel maintainers in copy, in case they have better ideas. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071873: debian-installer: FTBFS: unsatisfiable build-dependencies
Control: tag -1 patch Santiago Vila (2024-05-25): > Package: src:debian-installer > Version: 20230607+deb12u5 > Severity: serious > Tags: ftbfs master is fine. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071873: debian-installer: FTBFS: unsatisfiable build-dependencies
Control: tag -1 patch Santiago Vila (2024-05-25): > Package: src:debian-installer > Version: 20230607+deb12u5 > Severity: serious > Tags: ftbfs master is fine. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071873: debian-installer: FTBFS: unsatisfiable build-dependencies
Control: tag -1 patch Santiago Vila (2024-05-25): > Package: src:debian-installer > Version: 20230607+deb12u5 > Severity: serious > Tags: ftbfs master is fine. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
Hi, (debian-boot@, currently missing daily builds are the results of the #1071547/#1071548 pair.) Scott Talbert (2023-11-19): > On Sat, 18 Nov 2023, Cyril Brulebois wrote: > > I was trying to suggest filing both in the same request, to have > > them scheduled in one go. > > I tried to figure out how to do that with reportbug, but I did not see > an obvious way to do it. For the future, how do I do that? > Hand-written bug report? I'd suggest preparing the first one as usual, then editing the Subject, pseudo-headers (X-Debbugs-Cc:, Control: affects), and body to include information about the second one. Unless you get different instructions from the release team, that is. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Are follow-up steps for Lomiri desktop required?
Mike Gabriel (2024-05-22): > The plan is indeed to propose Lomiri as possible selection for a > desktop environment in D-I. > > Unfortunately, I don't know what steps are required to get Lomiri in. > Neither do I know who has a say in this, where it gets decided what > gets included as installer option in D-I and what not. In d-i, pkgsel starts tasksel, so if that's available in tasksel… > The Lomiri Operating Environment packaging for Debian is currently seeing > quite a boot because we have found a sponsor that finance the related work. Good one! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Re-planning for 12.6
Hi, Jonathan Wiltshire (2024-04-21): > Too late now in any case. SRMs will regroup and decide whether we push > for one in May or just wait for June anyway. June is 10 days away. Do we have any kind of tentative schedule? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Re-planning for 12.6
Hi, Jonathan Wiltshire (2024-04-21): > Too late now in any case. SRMs will regroup and decide whether we push > for one in May or just wait for June anyway. June is 10 days away. Do we have any kind of tentative schedule? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Re-planning for 12.6
Hi, Jonathan Wiltshire (2024-04-21): > Too late now in any case. SRMs will regroup and decide whether we push > for one in May or just wait for June anyway. June is 10 days away. Do we have any kind of tentative schedule? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1
Hi Colin, Colin Watson (2024-05-21): > I've just fixed this in unstable, but it would be helpful to have it > in place for installs of bookworm too. ACK on principle; you'll want a dch -r 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#1071574: bookworm-pu: package netcfg/1.187+deb12u1
Hi Colin, Colin Watson (2024-05-21): > I've just fixed this in unstable, but it would be helpful to have it > in place for installs of bookworm too. ACK on principle; you'll want a dch -r 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#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#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#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
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#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
Holger Wansing: Advocate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 For nm.debian.org, at 2024-05-14: I fully support Holger Wansing 's request to become a Debian Developer, uploading. I have worked with Holger Wansing on the Debian Installer (d-i) for many years and I consider him as having sufficient technical competence. Not only is Holger fluent with l10n topics (he's been the corner/rosetta stone for l10n coordination for a long while), he's been uploading a ton of d-i packages to include translation updates, fix i18n/l10n issues, and merge some other fixes or improvements, via DM permissions. Having looked at many of those uploads (after the fact, while preparing d-i releases and release announcements), I don't recall any serious problems with those uploads, and I trust Holger to perform unsupervised uploads of any packages he's comfortable patching/uploading on his own. I also know Holger isn't shy about asking for help/review when needed, which is also an excellent quality in my book. In addition to recognizing his technical excellence, that'd also remove the requirement for a sponsor and DM administrativia for NEW packages. I have personally worked with Holger Wansing (key 496AC6E814424B348508352959F187CA156EB076) for many years, and I know Holger Wansing can be trusted to be a full member of Debian, and have unsupervised, unrestricted upload rights, right now. If it weren't for the infrequent reminders due to DM ACLs, I would have totally forgotten about the current “non-uploading” part. Please make Holger a regular DD ASAP, thanks! :) -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmZC288ACgkQ/5FK8MKz VSBB7Q//VXSEb0uHrBXIYCc7RJkjDDYjiZj6luH8NscXblCtesvjyrn4RXUJduFE aMVoxr8HjXaQdlv9EstJrHlUzuquXj3qramWhuAdDb4r64aHfrAEIH3+vKpPlcS3 faWjuOqVC42eQb2s4U5bxqe4FmTy49KvFxt1DyfGrn+wpRG5ztF9Ly7Yxx+G5f68 mDwwHIZdbetuMSTr+nu1RTHI6sBlA2r4iF941oyVAlkqSZevPh5qU5+vKVwilxhV Ky2CcB966GZzBP5hw+TNKGaiNY/zZNyFQ16PeX2G24hDHwab4yJHp7uHbS/zEYGc 3wU9rvslODhKD2KbltnURFwULDiChnO62QNGMQ+o3WRObgMnYzmr3Ay2pQXBxMWU fOD9vDJTR+AMr4grlAulswkxLexgS32I0vguGGVeivAWFd4uA+BQaT7v6Wy+7iuZ /IgCZuEvMC78lZPagiSaDpvN76EbznZ0i8Ru5/YYCEXV07d+X76UDVcIHQ+UaG7u 0GPMka48YJ+52x0BEGSprdUd6WIdKekzORQT2e/MAuTCyiZzcSgGk2mOqCZ+bCda g12XYRkxDVrhlvK7PsaywibFY3piVaa2T2Uf/ojEUHFMoCReGgc+rxeGu4+gk8se IsDHpkvxcuf1JaSpDcjE9imutbHR3ouPbozKNUl7TUS1ni+WhyY= =4udk -END PGP SIGNATURE- Cyril Brulebois (via nm.debian.org) For details and to comment, visit https://nm.debian.org/process/1292/ -- https://nm.debian.org/process/1292/
Re: Next attempt to add Blends to Debian installer
Hallo wieder, TL;DR = blendsel looks uploadable, even if that mail looks long and full of nitpicks, that's all they are: minor things. A bunch of them being in passing comments about tasksel itself. ;) Holger Wansing (2024-05-09): > - I adapted tasksel, to become an installer for Debian pure blends. The > new package is blendsel, see https://salsa.debian.org/holgerw/blendsel/ Now moved under installer-team's namespace. Keeping the whole git history of tasksel without its tag is probably fine, in case anyone needs to dig up why this thing is done that way, but I'm not sure we should keep tasksel entries in debian/changelog; I would probably only keep the blendsel entry, adding a reference to the version of tasksel it was forked off from. Unless some others feel strongly we should keep the whole tasksel history in debian/changelog? I've fixed a few minor things for the rename. It looks to me the README could probably be stripped down to mention blendsel's being a fork of tasksel, and pointing at tasksel's README for more information. Less duplication would be best (and I'm not sure how current the contents are anyway). Ditto for tasks/README. I think you know best how to adjust README.translators :) I'm happy to upload it as-is (modulo debian/changelog), but I suspect it'd make sense to adjust tasks/ before doing so? Happy either way. > - I prepared a change in pkgsel, to call blendsel depending on the > descision, if Debian pure blends are wanted or not. > See https://salsa.debian.org/holgerw/pkgsel/ That I didn't check yet, my focus is on the current blocker (as far as the DM vs. DD limitation is concerned). > Anyway, I think I have it running so far, the blendsel dialog appears > and shows the items to select; I'm attaching a screenshot showing the > current state (please note, that the dialog shows three desktop environments > as placeholder for now; the tasksel - and therefore blendsel as well - > logic does not allow to have packages|tasks|blends listed that don't > have the corresponding task-* packages in the archive). Understood, but please let me know if it makes sense to have them in the 0.1 upload, or if you'd like to introduce them in 0.2 once 0.1 has been accepted. > The template should be rephrased, I would ask for review on > debian-l10n-english when the time comes, but I guess there is still > time for that... You should talk to our beloved l10n coordinator! And yeah, lintian/bookworm reports some things we don't normally do: W: blendsel: using-first-person-in-templates blendsel/tasks [templates:16] Seriously though, I'm not familiar with the semantics behind /first vs. /tasks in tasksel. Do we want/need the same semantics in blendsel? I think we should have lintian-overrides for the main package, just like tasksel, at least for those (again, only running lintian/bookworm): E: blendsel: no-debconf-config W: blendsel: debconf-is-not-a-registry [usr/lib/blendsel/blendsel-debconf:3] Finally, this should probably go away from both packages, I don't even remember having managed that package: Conflicts: base-config (<< 2.32) (And indeed, that was 20 years ago.) Bonus points: maybe clean up tasksel's debian/source/lintian-overrides? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Next attempt to add Blends to Debian installer
Hallo wieder, TL;DR = blendsel looks uploadable, even if that mail looks long and full of nitpicks, that's all they are: minor things. A bunch of them being in passing comments about tasksel itself. ;) Holger Wansing (2024-05-09): > - I adapted tasksel, to become an installer for Debian pure blends. The > new package is blendsel, see https://salsa.debian.org/holgerw/blendsel/ Now moved under installer-team's namespace. Keeping the whole git history of tasksel without its tag is probably fine, in case anyone needs to dig up why this thing is done that way, but I'm not sure we should keep tasksel entries in debian/changelog; I would probably only keep the blendsel entry, adding a reference to the version of tasksel it was forked off from. Unless some others feel strongly we should keep the whole tasksel history in debian/changelog? I've fixed a few minor things for the rename. It looks to me the README could probably be stripped down to mention blendsel's being a fork of tasksel, and pointing at tasksel's README for more information. Less duplication would be best (and I'm not sure how current the contents are anyway). Ditto for tasks/README. I think you know best how to adjust README.translators :) I'm happy to upload it as-is (modulo debian/changelog), but I suspect it'd make sense to adjust tasks/ before doing so? Happy either way. > - I prepared a change in pkgsel, to call blendsel depending on the > descision, if Debian pure blends are wanted or not. > See https://salsa.debian.org/holgerw/pkgsel/ That I didn't check yet, my focus is on the current blocker (as far as the DM vs. DD limitation is concerned). > Anyway, I think I have it running so far, the blendsel dialog appears > and shows the items to select; I'm attaching a screenshot showing the > current state (please note, that the dialog shows three desktop environments > as placeholder for now; the tasksel - and therefore blendsel as well - > logic does not allow to have packages|tasks|blends listed that don't > have the corresponding task-* packages in the archive). Understood, but please let me know if it makes sense to have them in the 0.1 upload, or if you'd like to introduce them in 0.2 once 0.1 has been accepted. > The template should be rephrased, I would ask for review on > debian-l10n-english when the time comes, but I guess there is still > time for that... You should talk to our beloved l10n coordinator! And yeah, lintian/bookworm reports some things we don't normally do: W: blendsel: using-first-person-in-templates blendsel/tasks [templates:16] Seriously though, I'm not familiar with the semantics behind /first vs. /tasks in tasksel. Do we want/need the same semantics in blendsel? I think we should have lintian-overrides for the main package, just like tasksel, at least for those (again, only running lintian/bookworm): E: blendsel: no-debconf-config W: blendsel: debconf-is-not-a-registry [usr/lib/blendsel/blendsel-debconf:3] Finally, this should probably go away from both packages, I don't even remember having managed that package: Conflicts: base-config (<< 2.32) (And indeed, that was 20 years ago.) Bonus points: maybe clean up tasksel's debian/source/lintian-overrides? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: DD application (Re: Next attempt to add Blends to Debian installer)
Hi, Holger Wansing (2024-05-10): > I know you repeatedly suggested this. Especially every time I ask for > more packages to get dm permissions for :-)) Just in case that's not clear: I'm not trying to get rid of you as if you were a burden (which you're clearly not), I'm suggesting you get recognized as an uploading DD (which you certainly qualify for already!). > My problem with this: am I really capable of being a DD? You might > remember that I am not a programmer, I have no real skills in this > direction. I can do some scripting, gained by self-learning, but that > does not make a programmer of me IMO ;-) You certainly don't need to be any kind of programmer (professional or self-taught) to be a DD. Given a package that you'd like to upload, are you able to look around in its source code, spot issues or things you want to improve, to come up with a patch that you'd be confident to upload? That's what matters. That's already happening for the packages you're DM-allowed to upload. When facing an issue or question, do you pick a random solution, hope for the best, upload, and watch the fireworks? Or do you ask others, gather feedback, and come up with a solution that has high chances to work? Definitely the latter, and that's what matters. Being knowledgeable about packages you're uploading (be it via a sponsor, a DM approval for this package or because you're a DD) is important. But that doesn't mean you need to understand and know its codebase by heart. Being reasonably sure that the changes to be uploaded are improving the situation as a whole, minimizing risks on the rest of the ecosystem (other packages in general, not breaking the installer in this specific case) is really what seems to be most important to me. You're definitely acquainted with the a bunch of things in the installer ecosystem, you're also knowledgeable about l10n topics, and you're definitely an excellent team player. As far as I'm concerned, the only bug is that your key is not in the right keyring! :) > So I am unsure if I can successfully go the apply-for-DD path... > I fear I lack some basic knowledge for this. > Don't want to waste my and the application manager's time and effort > for something, that does not lead to anything at the end. I suppose you already went through questions/checks around the Social Contract, Debian Free Software Guidelines, Debian Machine Usage Policies, etc. during the non-uploading DD application, so I'm not putting any focus on those (important nonetheless!) topics. I'd imagine the main difference between both types of application to be around… package manangement/uploads. And you definitely know how to upload packages already, as evidenced by: https://qa.debian.org/developer.php?login=Wansing Please let me know if I can do anything to help you get set up as a DD. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1070877: debian-installer: xfsprogs not available in the installer, but xfs fs type available, mkfs fails
Hi Witold, And thanks for your report. Witold Baryluk (2024-05-11): > Which is weird, because xfsprogs-udev is there. > > No issues with btrfs, ext2-4, fat, jfs. They are available by default. This is #1070795. Such bug reports would ideally be filed with: X-Debbugs-Cc: debian-boot@lists.debian.org Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1070877: debian-installer: xfsprogs not available in the installer, but xfs fs type available, mkfs fails
Hi Witold, And thanks for your report. Witold Baryluk (2024-05-11): > Which is weird, because xfsprogs-udev is there. > > No issues with btrfs, ext2-4, fat, jfs. They are available by default. This is #1070795. Such bug reports would ideally be filed with: X-Debbugs-Cc: debian-b...@lists.debian.org Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Next attempt to add Blends to Debian installer
Holger Wansing (2024-05-10): > Now blendsel being moved to installer-team, would you mind giving me > dm permissions, so I can upload? Thanks I seem to recall that only works for existing packages? May I suggest to think about turning your DD account into a non-non-uploading one? :) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Next attempt to add Blends to Debian installer
Hallo Holger, Holger Wansing (2024-05-09): > Holger Wansing wrote (Tue, 13 Feb 2024 23:43:35 +0100): > > could we just "copy tasksel with its UI and infrastructure" into a > > new package (I name it 'blends-di-tasks' here), which has all the > > blends listed, and add one entry to tasksel with a name like "Debian > > Pure Blends" or similar? > > > > If one then selects "Debian Pure Blends" in the good all known > > tasksel, the blends-di-tasks package would be installed on /target, > > and later a new dialog would appear, listing all the blends, where > > the user could select which one to install. (If the "Debian Pure > > Blends" entry stays unchecked, as would be the default value, > > everything stays as is: the new dialog would not appear, no > > difference to previous releases.) > > > > Would that be a possible solution for all involved parties? That approach looks very fine to me, thanks. > So, how to proceed now? > To make progress, the new blendsel needs to get into the archive I guess, > otherwise testing and providing test images will not work IMO. > > Would the installer-team be ok with taking blendsel under its umbrella, > as tasksel is, to get it uploaded? Looks good to me. I totally understand how testing can be difficult until packages reach the archive, feel free to “upload early, upload often”. It looks like the 64-bit time_t transition is getting better (at least from afar) but I don't have any immediate plans for a release at the moment, so it's perfectly fine to have glitches/temporary regressions following the introduction of this feature/new packages along the way. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Next attempt to add Blends to Debian installer
Hallo Holger, Holger Wansing (2024-05-09): > Holger Wansing wrote (Tue, 13 Feb 2024 23:43:35 +0100): > > could we just "copy tasksel with its UI and infrastructure" into a > > new package (I name it 'blends-di-tasks' here), which has all the > > blends listed, and add one entry to tasksel with a name like "Debian > > Pure Blends" or similar? > > > > If one then selects "Debian Pure Blends" in the good all known > > tasksel, the blends-di-tasks package would be installed on /target, > > and later a new dialog would appear, listing all the blends, where > > the user could select which one to install. (If the "Debian Pure > > Blends" entry stays unchecked, as would be the default value, > > everything stays as is: the new dialog would not appear, no > > difference to previous releases.) > > > > Would that be a possible solution for all involved parties? That approach looks very fine to me, thanks. > So, how to proceed now? > To make progress, the new blendsel needs to get into the archive I guess, > otherwise testing and providing test images will not work IMO. > > Would the installer-team be ok with taking blendsel under its umbrella, > as tasksel is, to get it uploaded? Looks good to me. I totally understand how testing can be difficult until packages reach the archive, feel free to “upload early, upload often”. It looks like the 64-bit time_t transition is getting better (at least from afar) but I don't have any immediate plans for a release at the moment, so it's perfectly fine to have glitches/temporary regressions following the introduction of this feature/new packages along the way. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1070767: bug report install partman-crypto
Hi, Edson Wolf (2024-05-08): > The package partman-crypto which apparently expects libgcc_s.so.1 to be an > installed library in the installer but lacks dependency to ensure that. It doesn't need to, debian-installer's build/Makefile ensures it's there. > Specifically, it does depend on libc6-udeb rather than libc6 with the > significant difference that it lacks the dependency on libgcc_s.so.1. The > partman-crypto developer(s) need to decide how to handle that. > ralph.ronnquist > > Attached images I'm not seeing anything related to libgcc_s.so.1 in those images. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1070767: bug report install partman-crypto
Hi, Edson Wolf (2024-05-08): > The package partman-crypto which apparently expects libgcc_s.so.1 to be an > installed library in the installer but lacks dependency to ensure that. It doesn't need to, debian-installer's build/Makefile ensures it's there. > Specifically, it does depend on libc6-udeb rather than libc6 with the > significant difference that it lacks the dependency on libgcc_s.so.1. The > partman-crypto developer(s) need to decide how to handle that. > ralph.ronnquist > > Attached images I'm not seeing anything related to libgcc_s.so.1 in those images. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Hi Simon, Simon McVittie (2024-05-07): > Looking at the d-i Packages.gz for amd64, the only other source > package that has picked up the bad libpng16-16t64-udeb dependency > seems to be matchbox-keyboard, which needs a sourceful upload to fix an > implicit-declarations FTBFS anyway, therefore isn't useful to binNMU. Yeah, I forgot to mention it when I worked on making d-i buildable and runnable again, then decided it didn't matter as it's not used (TTBOMK) at the moment. > After that: do the release/installer teams consider udeb dependencies > on non-udeb packages, by udebs that d-i does not currently need or use, > to be a RC issue or merely a nice-to-have? If udebs are actually used, I call that an RC bug and try to get it fixed swiftly (sometimes NMUing right away when time is of the essence). Otherwise I usually let those fly (without even filing bug reports). See: https://d-i.debian.org/dose/ Some backstory: https://lists.debian.org/debian-boot/2024/03/msg00102.html Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Hi Simon, Simon McVittie (2024-05-07): > Looking at the d-i Packages.gz for amd64, the only other source > package that has picked up the bad libpng16-16t64-udeb dependency > seems to be matchbox-keyboard, which needs a sourceful upload to fix an > implicit-declarations FTBFS anyway, therefore isn't useful to binNMU. Yeah, I forgot to mention it when I worked on making d-i buildable and runnable again, then decided it didn't matter as it's not used (TTBOMK) at the moment. > After that: do the release/installer teams consider udeb dependencies > on non-udeb packages, by udebs that d-i does not currently need or use, > to be a RC issue or merely a nice-to-have? If udebs are actually used, I call that an RC bug and try to get it fixed swiftly (sometimes NMUing right away when time is of the essence). Otherwise I usually let those fly (without even filing bug reports). See: https://d-i.debian.org/dose/ Some backstory: https://lists.debian.org/debian-boot/2024/03/msg00102.html Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Hi Simon, Simon McVittie (2024-05-07): > Looking at the d-i Packages.gz for amd64, the only other source > package that has picked up the bad libpng16-16t64-udeb dependency > seems to be matchbox-keyboard, which needs a sourceful upload to fix an > implicit-declarations FTBFS anyway, therefore isn't useful to binNMU. Yeah, I forgot to mention it when I worked on making d-i buildable and runnable again, then decided it didn't matter as it's not used (TTBOMK) at the moment. > After that: do the release/installer teams consider udeb dependencies > on non-udeb packages, by udebs that d-i does not currently need or use, > to be a RC issue or merely a nice-to-have? If udebs are actually used, I call that an RC bug and try to get it fixed swiftly (sometimes NMUing right away when time is of the essence). Otherwise I usually let those fly (without even filing bug reports). See: https://d-i.debian.org/dose/ Some backstory: https://lists.debian.org/debian-boot/2024/03/msg00102.html Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
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#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#1053678: partman-crypto: Requires separate /boot partition, even if not required
Luca Boccassi (2024-05-06): > Pending at: > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8 I'm not sure how often we change template types, but I suppose this particular instance (error → boolean) makes sense and isn't problematic. Please mention “GRUB” (instead of “grub”) for consistency with upstream and the rest of d-i though. (I know this is very minor but better catch that early to avoid another l10n round later on.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required
Luca Boccassi (2024-05-06): > Pending at: > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8 I'm not sure how often we change template types, but I suppose this particular instance (error → boolean) makes sense and isn't problematic. Please mention “GRUB” (instead of “grub”) for consistency with upstream and the rest of d-i though. (I know this is very minor but better catch that early to avoid another l10n round later on.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1016957: remove kbd-chooser from the archive?
Paul Gevers (2024-05-04): > If you're sure it's not used, I can work around udd and have it at least > removed from testing. I think a bug retitle (or separate bug) would have > been better. The current bug isn't RC. If it's certain that package isn't used/useful anymore, the correct thing to do is to have it removed from the archive, via unstable, sync'd into testing. I don't see what a removal from testing only would achieve, esp. for trumped-up reasons. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1016957: remove kbd-chooser from the archive?
Paul Gevers (2024-05-04): > If you're sure it's not used, I can work around udd and have it at least > removed from testing. I think a bug retitle (or separate bug) would have > been better. The current bug isn't RC. If it's certain that package isn't used/useful anymore, the correct thing to do is to have it removed from the archive, via unstable, sync'd into testing. I don't see what a removal from testing only would achieve, esp. for trumped-up reasons. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Making trixie debootstrap-able again?
Hi, Cyril Brulebois (2024-04-26): > I'm not sure how we reached this situation but there are a bunch of > packages in trixie that are not in a suitable state. To reproduce, a > simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient. That works again, presumably following the configuration changes in britney made it complete again, finally migrating stuff. > Note: I've limited my exploration to amd64, which kept me busy > already… That proviso is still true. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Making trixie debootstrap-able again?
Hi, Cyril Brulebois (2024-04-26): > I'm not sure how we reached this situation but there are a bunch of > packages in trixie that are not in a suitable state. To reproduce, a > simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient. That works again, presumably following the configuration changes in britney made it complete again, finally migrating stuff. > Note: I've limited my exploration to amd64, which kept me busy > already… That proviso is still true. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Package "usr-is-merged" is reported as missing in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) during installation with live-installer/enable=false
Hello, And thanks for the report. Cc += debian-live@ Computer Enthusiastic (2024-05-01): > The "Normal" [0] Debian Installer included in Debian Live ISO 12.5 > (debian-live-12.5.0-amd64-lxqt.iso) fails the installation of the base > system when started with the following preseed parameters: > > live-installer/enable=false firmware=never > > The Debian installer stops deboostrap with the following error > > Could not find these debs: usr-is-merged > > The installation of the base system is not completed even if the > base-install step is repeated. > > The syslog contains: > > [..] > May 1 17:17:12 main-menu[440]: INFO: Menu item 'bootstrap-base' selected > May 1 17:17:13 debootstrap: /usr/sbin/debootstrap --components=main > --debian-installer --resolve-deps --no-check-gpg bookworm /target > file:///cdrom/ > May 1 17:18:26 base-installer: error: exiting on error > base-installer/debootstrap-failed > May 1 17:19:22 main-menu[440]: WARNING **: Configuring 'bootstrap-base' > failed with error code 1 > May 1 17:19:22 main-menu[440]: WARNING **: Menu item 'bootstrap-base' > failed. > [..] > > The package "usr-is-merged" > (https://packages.debian.org/bookworm/usr-is-merged) is missing in > /cdrom/pool/main/u : > > ls -l /cdrom/pool/main/u/ > dr-xr-xr-x1 root root 2048 Feb 10 11:07 ucf > dr-xr-xr-x1 root root 2048 Feb 10 11:07 usrmerge > > Which package should I report to the bug tracking system ? > > Let me know if I can help. > > Thanks. > > -- > [0] > https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-installer.en.html > Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Package "usr-is-merged" is reported as missing in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) during installation with live-installer/enable=false
Hello, And thanks for the report. Cc += debian-live@ Computer Enthusiastic (2024-05-01): > The "Normal" [0] Debian Installer included in Debian Live ISO 12.5 > (debian-live-12.5.0-amd64-lxqt.iso) fails the installation of the base > system when started with the following preseed parameters: > > live-installer/enable=false firmware=never > > The Debian installer stops deboostrap with the following error > > Could not find these debs: usr-is-merged > > The installation of the base system is not completed even if the > base-install step is repeated. > > The syslog contains: > > [..] > May 1 17:17:12 main-menu[440]: INFO: Menu item 'bootstrap-base' selected > May 1 17:17:13 debootstrap: /usr/sbin/debootstrap --components=main > --debian-installer --resolve-deps --no-check-gpg bookworm /target > file:///cdrom/ > May 1 17:18:26 base-installer: error: exiting on error > base-installer/debootstrap-failed > May 1 17:19:22 main-menu[440]: WARNING **: Configuring 'bootstrap-base' > failed with error code 1 > May 1 17:19:22 main-menu[440]: WARNING **: Menu item 'bootstrap-base' > failed. > [..] > > The package "usr-is-merged" > (https://packages.debian.org/bookworm/usr-is-merged) is missing in > /cdrom/pool/main/u : > > ls -l /cdrom/pool/main/u/ > dr-xr-xr-x1 root root 2048 Feb 10 11:07 ucf > dr-xr-xr-x1 root root 2048 Feb 10 11:07 usrmerge > > Which package should I report to the bug tracking system ? > > Let me know if I can help. > > Thanks. > > -- > [0] > https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-installer.en.html > Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter
Hi, Thanks for the report but wow, that's way too many topics. baptx (2024-04-27): > The following issue is based on the discussion I created on > https://forums.debian.net/viewtopic.php?t=159027 where you can find > attached the content of /var/log/installer/syslog which was generated > on a virtual machine with virt-manager when installing > debian-live-12.5.0-amd64-lxqt.iso with the firmware=never parameter > (the problem was also present on my real computer when I tested with a > previous version debian-live-12.0.0-amd64-lxqt.iso). I also attached > the result of the vrms command after using firmware=never parameter. vrms is irrelevant. > To compare, you can also find attached another installer syslog > without using firmware=never parameter, which also contains the line > "hw-detect: skipping check-missing-firmware as requested by the > caller" and looks like a bug. No, it's not. See check on CHECK_MISSING_FIRMWARE in hw-detect. > The firmware=never parameter did not work at all when using the LXQt > ISO file (maybe the problem also happens on ISO files with other > desktop environments), the non-free firmware packages were installed. That would be a bug in debian-live then, not in debian-installer. Cc-ing accordingly. > And with the LXQt ISO file, the graphical expert install as well as > the text expert install did not ask me if I want the non-free firmware > packages, they were installed automatically. > I noticed the firmware=never parameter only worked with the netinst > ISO file. Well, that's been added for use by debian-installer. What debian-live does or doesn't do with it is outside our control. > For the automatic detection of needed non-free firmware packages, it > only worked with the netinst ISO file as well (the LXQt ISO file > installed all non-free firmware packages). But even with netinst ISO > file, it seems it is only guessing the non-free firmware packages > needed since several were not needed to make my laptop work correctly > (firmware-realtek, firmware-sof-signed) when installed on my real > computer instead of a virtual machine. The lookup is based on what devices are seen during the installation process. If the relevant kernel modules list firmware files, we try to match them to firmware packages, and queue their installation. Unless firmware=never was used of course. That doesn't mean they are absolutely required for those devices to work. There is just no way to know for sure. > It would also be useful to have the firmware=never parameter added in > a menu in the normal graphical installation (for people who don't want > the complexity of the expert installation), since it is more > convenient to have it in a menu and also avoids mistakes when typing > firmware=never (I accidentally typed firmzare due to my AZERTY > keyboard and the QWERTY input). Menu maintenance (esp. across architectures, BIOS vs. UEFI, etc.) is a huge mess already, it might happen but I'm not holding my breath here. > It would be a good idea to warn the user if the entered parameter / > value does not exist, to avoid unwanted results like installing > non-free firmware. There's no absolute list to check against, so that cannot be done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter
Hi, Thanks for the report but wow, that's way too many topics. baptx (2024-04-27): > The following issue is based on the discussion I created on > https://forums.debian.net/viewtopic.php?t=159027 where you can find > attached the content of /var/log/installer/syslog which was generated > on a virtual machine with virt-manager when installing > debian-live-12.5.0-amd64-lxqt.iso with the firmware=never parameter > (the problem was also present on my real computer when I tested with a > previous version debian-live-12.0.0-amd64-lxqt.iso). I also attached > the result of the vrms command after using firmware=never parameter. vrms is irrelevant. > To compare, you can also find attached another installer syslog > without using firmware=never parameter, which also contains the line > "hw-detect: skipping check-missing-firmware as requested by the > caller" and looks like a bug. No, it's not. See check on CHECK_MISSING_FIRMWARE in hw-detect. > The firmware=never parameter did not work at all when using the LXQt > ISO file (maybe the problem also happens on ISO files with other > desktop environments), the non-free firmware packages were installed. That would be a bug in debian-live then, not in debian-installer. Cc-ing accordingly. > And with the LXQt ISO file, the graphical expert install as well as > the text expert install did not ask me if I want the non-free firmware > packages, they were installed automatically. > I noticed the firmware=never parameter only worked with the netinst > ISO file. Well, that's been added for use by debian-installer. What debian-live does or doesn't do with it is outside our control. > For the automatic detection of needed non-free firmware packages, it > only worked with the netinst ISO file as well (the LXQt ISO file > installed all non-free firmware packages). But even with netinst ISO > file, it seems it is only guessing the non-free firmware packages > needed since several were not needed to make my laptop work correctly > (firmware-realtek, firmware-sof-signed) when installed on my real > computer instead of a virtual machine. The lookup is based on what devices are seen during the installation process. If the relevant kernel modules list firmware files, we try to match them to firmware packages, and queue their installation. Unless firmware=never was used of course. That doesn't mean they are absolutely required for those devices to work. There is just no way to know for sure. > It would also be useful to have the firmware=never parameter added in > a menu in the normal graphical installation (for people who don't want > the complexity of the expert installation), since it is more > convenient to have it in a menu and also avoids mistakes when typing > firmware=never (I accidentally typed firmzare due to my AZERTY > keyboard and the QWERTY input). Menu maintenance (esp. across architectures, BIOS vs. UEFI, etc.) is a huge mess already, it might happen but I'm not holding my breath here. > It would be a good idea to warn the user if the entered parameter / > value does not exist, to avoid unwanted results like installing > non-free firmware. There's no absolute list to check against, so that cannot be done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter
Hi, Thanks for the report but wow, that's way too many topics. baptx (2024-04-27): > The following issue is based on the discussion I created on > https://forums.debian.net/viewtopic.php?t=159027 where you can find > attached the content of /var/log/installer/syslog which was generated > on a virtual machine with virt-manager when installing > debian-live-12.5.0-amd64-lxqt.iso with the firmware=never parameter > (the problem was also present on my real computer when I tested with a > previous version debian-live-12.0.0-amd64-lxqt.iso). I also attached > the result of the vrms command after using firmware=never parameter. vrms is irrelevant. > To compare, you can also find attached another installer syslog > without using firmware=never parameter, which also contains the line > "hw-detect: skipping check-missing-firmware as requested by the > caller" and looks like a bug. No, it's not. See check on CHECK_MISSING_FIRMWARE in hw-detect. > The firmware=never parameter did not work at all when using the LXQt > ISO file (maybe the problem also happens on ISO files with other > desktop environments), the non-free firmware packages were installed. That would be a bug in debian-live then, not in debian-installer. Cc-ing accordingly. > And with the LXQt ISO file, the graphical expert install as well as > the text expert install did not ask me if I want the non-free firmware > packages, they were installed automatically. > I noticed the firmware=never parameter only worked with the netinst > ISO file. Well, that's been added for use by debian-installer. What debian-live does or doesn't do with it is outside our control. > For the automatic detection of needed non-free firmware packages, it > only worked with the netinst ISO file as well (the LXQt ISO file > installed all non-free firmware packages). But even with netinst ISO > file, it seems it is only guessing the non-free firmware packages > needed since several were not needed to make my laptop work correctly > (firmware-realtek, firmware-sof-signed) when installed on my real > computer instead of a virtual machine. The lookup is based on what devices are seen during the installation process. If the relevant kernel modules list firmware files, we try to match them to firmware packages, and queue their installation. Unless firmware=never was used of course. That doesn't mean they are absolutely required for those devices to work. There is just no way to know for sure. > It would also be useful to have the firmware=never parameter added in > a menu in the normal graphical installation (for people who don't want > the complexity of the expert installation), since it is more > convenient to have it in a menu and also avoids mistakes when typing > firmware=never (I accidentally typed firmzare due to my AZERTY > keyboard and the QWERTY input). Menu maintenance (esp. across architectures, BIOS vs. UEFI, etc.) is a huge mess already, it might happen but I'm not holding my breath here. > It would be a good idea to warn the user if the entered parameter / > value does not exist, to avoid unwanted results like installing > non-free firmware. There's no absolute list to check against, so that cannot be done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Making trixie debootstrap-able again?
Cyril Brulebois (2024-04-26): > Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting > because I'm really not sure this would be the right course of action, more > details below) a new binNMU of coreutils within testing would be > sufficient to make trixie debootstrap-able again, I built a modified > repository, and try debootstrap against it, only to find more problems: > - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone. > - iproute2 depends on libtirpc3, which is gone. > > I guess the reason is similar, the former I tracked down to the same block > of hints as before: > > # 2024-04-23; done 2024-04-25 > # help some t64 packages migrate > […] > force-hint readline/8.2-4 > > The latter I tracked down to thisone: > > # 2024-04-23; done 2024-04-26 > # get t64 unstuck > urgent libtirpc/1.3.4+ds-1.3 > force-hint libtirpc/1.3.4+ds-1.3 > > Again, I have absolutely no clue regarding the best course of action at > this point. I can't even perform clean builds to check what a binNMU in > testing would look like, as I can't debootstrap a clean environment (and > therefore only tested rebuilds in an existing, devel-oriented, unclean > trixie chroot). Looks like I forgot to mention the final results: with the modified repository stuffed with (unclean) rebuilds of coreutils, iproute2, and util-linux, I'm able to debootstrap trixie again. (I've hacked a repository together from scratch, based on the failed debootstrap's apt cache, adding rebuilt packages, and injecting new dependencies manually; I could redo that cleanly by forking trixie's current Packages instead, but I'm not sure it's really worth the efforts, esp. given rebuilt packages are “tainted” anyway.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Making trixie debootstrap-able again?
Cyril Brulebois (2024-04-26): > Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting > because I'm really not sure this would be the right course of action, more > details below) a new binNMU of coreutils within testing would be > sufficient to make trixie debootstrap-able again, I built a modified > repository, and try debootstrap against it, only to find more problems: > - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone. > - iproute2 depends on libtirpc3, which is gone. > > I guess the reason is similar, the former I tracked down to the same block > of hints as before: > > # 2024-04-23; done 2024-04-25 > # help some t64 packages migrate > […] > force-hint readline/8.2-4 > > The latter I tracked down to thisone: > > # 2024-04-23; done 2024-04-26 > # get t64 unstuck > urgent libtirpc/1.3.4+ds-1.3 > force-hint libtirpc/1.3.4+ds-1.3 > > Again, I have absolutely no clue regarding the best course of action at > this point. I can't even perform clean builds to check what a binNMU in > testing would look like, as I can't debootstrap a clean environment (and > therefore only tested rebuilds in an existing, devel-oriented, unclean > trixie chroot). Looks like I forgot to mention the final results: with the modified repository stuffed with (unclean) rebuilds of coreutils, iproute2, and util-linux, I'm able to debootstrap trixie again. (I've hacked a repository together from scratch, based on the failed debootstrap's apt cache, adding rebuilt packages, and injecting new dependencies manually; I could redo that cleanly by forking trixie's current Packages instead, but I'm not sure it's really worth the efforts, esp. given rebuilt packages are “tainted” anyway.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Making trixie debootstrap-able again?
Hi, I'm not sure how we reached this situation but there are a bunch of packages in trixie that are not in a suitable state. To reproduce, a simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient. Note: I've limited my exploration to amd64, which kept me busy already… An obvious first problem is coreutils, which picked a Pre-Depends on libssl3 (not the t64 one), which… disappeared from testing between the 2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at Packages.gz for amd64 via snapshot.debian.org). The coreutils binNMU is hardly new, as it appeared via unstable in January, and was already in testing by April 1st (I didn't check earlier than that). Therefore I'm quite baffled to see libssl3 happily disappear from testing while we still have stuff that Pre-Depends on it?! Checking britney, I suppose this is a result of the following hint: # 2024-04-23; done 2024-04-25 # help some t64 packages migrate […] force-hint openssl/3.2.1-3 Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting because I'm really not sure this would be the right course of action, more details below) a new binNMU of coreutils within testing would be sufficient to make trixie debootstrap-able again, I built a modified repository, and try debootstrap against it, only to find more problems: - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone. - iproute2 depends on libtirpc3, which is gone. I guess the reason is similar, the former I tracked down to the same block of hints as before: # 2024-04-23; done 2024-04-25 # help some t64 packages migrate […] force-hint readline/8.2-4 The latter I tracked down to thisone: # 2024-04-23; done 2024-04-26 # get t64 unstuck urgent libtirpc/1.3.4+ds-1.3 force-hint libtirpc/1.3.4+ds-1.3 Again, I have absolutely no clue regarding the best course of action at this point. I can't even perform clean builds to check what a binNMU in testing would look like, as I can't debootstrap a clean environment (and therefore only tested rebuilds in an existing, devel-oriented, unclean trixie chroot). Seeing how some packages, e.g. coreutils, have DEP-17 changes staged in unstable (since 1.5+ month), I'm definitely not advocating for pushing them into testing as a quick or easy fix for those issues. I'm not sure whether you're keeping track of things that break when force-hinting but if you were aware of the resulting breakages already, some kind of heads-up would have been nice… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Making trixie debootstrap-able again?
Hi, I'm not sure how we reached this situation but there are a bunch of packages in trixie that are not in a suitable state. To reproduce, a simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient. Note: I've limited my exploration to amd64, which kept me busy already… An obvious first problem is coreutils, which picked a Pre-Depends on libssl3 (not the t64 one), which… disappeared from testing between the 2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at Packages.gz for amd64 via snapshot.debian.org). The coreutils binNMU is hardly new, as it appeared via unstable in January, and was already in testing by April 1st (I didn't check earlier than that). Therefore I'm quite baffled to see libssl3 happily disappear from testing while we still have stuff that Pre-Depends on it?! Checking britney, I suppose this is a result of the following hint: # 2024-04-23; done 2024-04-25 # help some t64 packages migrate […] force-hint openssl/3.2.1-3 Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting because I'm really not sure this would be the right course of action, more details below) a new binNMU of coreutils within testing would be sufficient to make trixie debootstrap-able again, I built a modified repository, and try debootstrap against it, only to find more problems: - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone. - iproute2 depends on libtirpc3, which is gone. I guess the reason is similar, the former I tracked down to the same block of hints as before: # 2024-04-23; done 2024-04-25 # help some t64 packages migrate […] force-hint readline/8.2-4 The latter I tracked down to thisone: # 2024-04-23; done 2024-04-26 # get t64 unstuck urgent libtirpc/1.3.4+ds-1.3 force-hint libtirpc/1.3.4+ds-1.3 Again, I have absolutely no clue regarding the best course of action at this point. I can't even perform clean builds to check what a binNMU in testing would look like, as I can't debootstrap a clean environment (and therefore only tested rebuilds in an existing, devel-oriented, unclean trixie chroot). Seeing how some packages, e.g. coreutils, have DEP-17 changes staged in unstable (since 1.5+ month), I'm definitely not advocating for pushing them into testing as a quick or easy fix for those issues. I'm not sure whether you're keeping track of things that break when force-hinting but if you were aware of the resulting breakages already, some kind of heads-up would have been nice… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: udhcpc search domain
Hi Frédéric, Frédéric Guyot (2024-04-26): > That's great, thank you for your fast response/fix. > Just need to update netcfg now. Should I create a new post on the mailing > list ? The “request something on a list and that works out” is more of an exception than the rule. To ensure proper tracking, a bug report is always a better idea. You could propose a patch attached to the bug report, and/or file a merge request: https://salsa.debian.org/installer-team/netcfg/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: debian-installer/netcfg: Netplan support feedback
Hi Lukas, Lukas Märdian (2024-04-25): > Turns out d-i was unable to finish the installation, due to > installability issues of packages in the target system, especially > systemd-sysv vs libssl3 in this case. The archive is still very much > in flux and this is probably also why we still see d-i daily build > failures [0] (but its looking much better already!) and Salsa-CI > failures for d-i [1]. What I've reported a while back, and what I ended up fixing last week were all udeb relationship issues making it impossible to build d-i or to run it (I don't have the details but I'm pretty sure all runtime issues would already show up at build time anyway, and yes that explains a lot of red on the d-i daily build graphs). And yeah, at the moment we end up with a debootstrap problem when installing trixie, since libssl3 is gone from trixie (except on 32-bit arms) while coreutils still Pre-Depends on it. That's one blocker I've just confirmed again, but didn't look for possible others. I haven't followed recent progress on the 64-bit time_t front, maybe rebuilding packages within testing might help get rid of such issues, that might make some other things harder… Seeing how the package in unstable has DEP-17 changes on top, I'm not sure I want to get involved in the intersection of two gigantic transitions I'm not knowledgeable about. :/ Installing unstable is more likely to succeed though (as at least a plain debootstrap sid works, as opposed to a plain debootstrap trixie). Thanks for the write-up, I'll check it when time permits. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant 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#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
Re: 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
Diederik de Haas: Advocate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 For nm.debian.org, at 2024-04-24: I support Diederik de Haas 's request to become a Debian Developer, uploading. I have worked with Diederik de Haas on Raspberry Pi support and some kernel and firmware patches/MRs during the last few years and I've been more than satisfied with the level of expertise and teamwork. Sufficiently so to have wondered a few times why Diederik wasn't a DD yet, and why there was no DD application on the NM front! I have personally worked with Diederik de Haas (key F5B143C162CC869A2E2EB32FD76E5BCE787EDB6E) for several years, and I know Diederik de Haas can be trusted to be a full member of Debian, and have unsupervised, unrestricted upload rights, right now. Cheers, Cyril. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmYpJegACgkQ/5FK8MKz VSCYuBAAs+EyWcxi9XP81v4A16jn1Nwl4L9Jz9eo2oPVU7DX+aiEBNxvhd5Re/2o 9CGYhWpG3OZOx0CyV9hwYPBKLcdz5urlFhy328LD9Z/3b7lTmQP4UOhAIhFQ6EQn hZen3EsqEcsaDw7MlugVvOIoHQHoqpUsN9X5C578d62arl2je5joGACtDArlZNzW KmInn7xb/ogZcub0R4JsOvfcymCduOCKq9WddVYcYWTpgZQUvjOBm5EuyLymc3ro aslOFkz2vWfuSBxNGm8d8Hoj2YBH5zPpEvW8MrhvsU7/B78cgZXky0Yzh5EQ9W/A va/nkGhx/Jvx7KvpKI/OHcJMEHZ5E9YZX82VWgzEbtwqSUNVRgbqotGnaQn+35Tq PyDWBejNxJpQ5mDjrnO6bVrbvjp61wJH1RdrQwuSu1N5v780KDbTuBQH8u4T+OQX MasAreb+S56Ln9PtA070klApw/72Qm+dhgB69UiVaQFEwae7HfCg9XT6+K6qrCPi /uitjAo1T3ctnsP2+5b+fKiP+RXCbOUFLK7b9+rlQ0u9ue+WrKg4j/BilWqq3w0A BA4WK7wvUfSwvlbkLEE3H8BHq46uiLUHO3yWMjlRbbYj6QhK9/P9nBO3bAolKW/i 8JsUXmc+/mq6NSrQGM7lPwWNZ/JIm+LEyF+wkN2aoCixbQkBUzM= =Lslx -END PGP SIGNATURE- Cyril Brulebois (via nm.debian.org) For details and to comment, visit https://nm.debian.org/process/1281/ -- https://nm.debian.org/process/1281/
Bug#1069099: binNMUs to fix mtdev-using udebs
Cyril Brulebois (2024-04-16): > Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) > on all archs, provided that doesn't interfere with the whole 64-bit time_t > transition: > - libinput10 That ought to read: - libinput Sorry about that. > - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069099: binNMUs to fix mtdev-using udebs
Cyril Brulebois (2024-04-16): > Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) > on all archs, provided that doesn't interfere with the whole 64-bit time_t > transition: > - libinput10 That ought to read: - libinput Sorry about that. > - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1069099: binNMUs to fix mtdev-using udebs
Cyril Brulebois (2024-04-16): > Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) > on all archs, provided that doesn't interfere with the whole 64-bit time_t > transition: > - libinput10 That ought to read: - libinput Sorry about that. > - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069099: binNMUs to fix mtdev-using udebs
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-b...@lists.debian.org Hi, mtdev regressed a while back, leading a few udebs to become uninstallable (initially one[1], now two). 1. https://bugs.debian.org/1066071 No response in 1+ month, the package wasn't ready to migrate anyway since it was waiting on dpkg but also regressing on 32-bit arms; I've uploaded an NMU yesterday, built everywhere. I also verified that rebuilding the following two packages gives appropriate dependencies for their udebs. Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) on all archs, provided that doesn't interfere with the whole 64-bit time_t transition: - libinput10 - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1069099: binNMUs to fix mtdev-using udebs
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-boot@lists.debian.org Hi, mtdev regressed a while back, leading a few udebs to become uninstallable (initially one[1], now two). 1. https://bugs.debian.org/1066071 No response in 1+ month, the package wasn't ready to migrate anyway since it was waiting on dpkg but also regressing on 32-bit arms; I've uploaded an NMU yesterday, built everywhere. I also verified that rebuilding the following two packages gives appropriate dependencies for their udebs. Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) on all archs, provided that doesn't interfere with the whole 64-bit time_t transition: - libinput10 - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1069099: binNMUs to fix mtdev-using udebs
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-b...@lists.debian.org Hi, mtdev regressed a while back, leading a few udebs to become uninstallable (initially one[1], now two). 1. https://bugs.debian.org/1066071 No response in 1+ month, the package wasn't ready to migrate anyway since it was waiting on dpkg but also regressing on 32-bit arms; I've uploaded an NMU yesterday, built everywhere. I also verified that rebuilding the following two packages gives appropriate dependencies for their udebs. Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) on all archs, provided that doesn't interfere with the whole 64-bit time_t transition: - libinput10 - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Re: debina-backports missing packages
Hi, Varghese Paul (2024-04-15): > I am encountering an issue with the Buster-backports repository. It seems > that the repository does not have a Release file, which is preventing > package management tools from retrieving updates or installing new packages > from this source. https://lists.debian.org/debian-devel-announce/2024/03/msg3.html http://archive.debian.org/debian/dists/buster-backports/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069020: release.debian.org: binNMUs to fix libpng-using udebs
Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-boot@lists.debian.org Hi, libpng1.6 regressed a while back, leading a few key udebs to become uninstallable[1]. That was fixed rather quickly[2] but binNMUs haven't happened yet. We haven't heard back from people driving the 64-bit time_t transition either, it's been a while, so I'm contacting you to see if you could arrange some binNMUs, without disrupting their work. 1. https://bugs.debian.org/1066069 2. https://tracker.debian.org/news/1515481/accepted-libpng16-1643-4-source-into-unstable/ Please consider binNMU-ing the following source package against libpng-dev (>= 1.6.43-4): - cairo - gdk-pixbuf - freetype [armel] That's based on udeb installability checks[3], and I only verified on amd64 that both cairo and gdk-pixbuf get appropriate dependencies for their udebs when rebuilt. 3. https://d-i.debian.org/dose/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1069020: release.debian.org: binNMUs to fix libpng-using udebs
Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-b...@lists.debian.org Hi, libpng1.6 regressed a while back, leading a few key udebs to become uninstallable[1]. That was fixed rather quickly[2] but binNMUs haven't happened yet. We haven't heard back from people driving the 64-bit time_t transition either, it's been a while, so I'm contacting you to see if you could arrange some binNMUs, without disrupting their work. 1. https://bugs.debian.org/1066069 2. https://tracker.debian.org/news/1515481/accepted-libpng16-1643-4-source-into-unstable/ Please consider binNMU-ing the following source package against libpng-dev (>= 1.6.43-4): - cairo - gdk-pixbuf - freetype [armel] That's based on udeb installability checks[3], and I only verified on amd64 that both cairo and gdk-pixbuf get appropriate dependencies for their udebs when rebuilt. 3. https://d-i.debian.org/dose/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1069020: release.debian.org: binNMUs to fix libpng-using udebs
Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-b...@lists.debian.org Hi, libpng1.6 regressed a while back, leading a few key udebs to become uninstallable[1]. That was fixed rather quickly[2] but binNMUs haven't happened yet. We haven't heard back from people driving the 64-bit time_t transition either, it's been a while, so I'm contacting you to see if you could arrange some binNMUs, without disrupting their work. 1. https://bugs.debian.org/1066069 2. https://tracker.debian.org/news/1515481/accepted-libpng16-1643-4-source-into-unstable/ Please consider binNMU-ing the following source package against libpng-dev (>= 1.6.43-4): - cairo - gdk-pixbuf - freetype [armel] That's based on udeb installability checks[3], and I only verified on amd64 that both cairo and gdk-pixbuf get appropriate dependencies for their udebs when rebuilt. 3. https://d-i.debian.org/dose/ 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
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#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
Re: 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
Re: Progress on t64 transition -> building the installer in sid
Philip Hands (2024-04-15): > On the other hand, it's taken over a month so far. Rather than living in > hope for another month, I thought it might be worth removing this as a > blocker (I've had to tell a couple of people that they'll need to wait > before they can do their salsa-CI tests :-/ ) I'm not suggesting living in hope, I'm suggesting to get the ball rolling. The commit lists #1066070, which was a duplicate (because -ECOFFEE) of #1066069, which got fixed rather quickly. So what we would need are rebuilds of the reverse dependencies (which I haven't checked right now would be sufficient to get them fixed), which one could request on the release team side. Regarding #1066071, that needs a fix in the package first. Looking at tracker, it's not migrating any time soon as far as I can see (due to regressions on 32-bit arms), and I'm not sure how fixing the udeb would interfere there. So one could start with an upload. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Progress on t64 transition -> building the installer in sid
Philip Hands (2024-04-14): > I realised that there might be a way to kludge around the current D-I > build failures, so I gave it a try and it seems to work: > > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45 > > That creates dummy udebs with the missing names, where each depends upon > the matching udeb that actually exists. Dropping them into localudebs. > > That's enough to get D-I to build in salsa pipelines, such that one gets > a mini-ISO to test. > > It may be enough to get D-I and debian-cd back to the point where we can > produce daily images etc. but I'm not completely sure about that bit > (perhaps the use of localudebs is enough to make debian-cd grumpy?) > > Anyway, it's currently broken anyway, so perhaps it's worth giving it a > go, and then reverting the commit once the proper fixes become > available. > > What do you think? I'd rather see actual progress in getting packages fixed. So far I haven't been chasing because I thought people would be busy rebuilding the world, in the right order, and patching things along, but I had hoped to get *some* kind of feedback after filing those bug reports and putting people driving changes in the loop. 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: 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#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#1068898: Reinstate OpenRD netboot images for bookworm
Hi Martin, (Replying as much as braindumping to avoid rediscovering this next time around.) Martin Michlmayr (2024-04-13): > I'm sorry to be that guy who shows up every few years to waste > everyone's time... but... I was updating my Kirkwood pages for > bookworm and noticed that the OpenRD images are gone. > > Now you may remember that we had the same situation for bullseye > (#934072) and Cyril kindly restored the netboot images: > https://salsa.debian.org/installer-team/debian-installer/-/commit/3ef30be60ab128f53a0cd16e6c1e91a3123988b4 > > I guess this change never got committed to master/main because > bullseye was going to be the last release for armel. Well, Rick explicitly said he was happy with bullseye or bookworm, so one of them got implemented… > But armel is still in bookworm and Rick confirmed he's running > bookworm on his OpenRD, so I see no reason why d-i wouldn't work if > we apply the same patch to the bookworm d-i. > > Honestly, I'm not sure if it's worth it as Rick is probably the one > Debian on OpenRD left, but since bookworm will probably be the last > release of armel (or not?) it would be nice if the installer was > working on OpenRD. > > Cyril or Vagrant, can you easily apply the patch above and generate a > test image for Rick? I don't mind doing that again, but what's the game plan here? If systems are already installed and working fine, then d-i is irrelevant. For any new systems people might want to deploy, installing bullseye then upgrading to bookworm already works? We don't have anything to support for armel at the moment (as far as master and testing/unstable are concerned), hence the current “let it die altogether” plan from a d-i perspective: https://lists.debian.org/debian-boot/2024/03/msg00016.html I'm not sure we should be encouraging new installations of 32-bit hardware at this stage (look at what's happening for i386…). I don't remember seeing a decision regarding armel's being a release arch for trixie, but kernel support is gone already (same thread): https://lists.debian.org/debian-arm/2024/01/msg8.html So OpenRD has no future in trixie as far as I understand. At least that would mean not having to do that again again, if we were to enable OpenRD images again for bookworm. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Hi Martin, (Replying as much as braindumping to avoid rediscovering this next time around.) Martin Michlmayr (2024-04-13): > I'm sorry to be that guy who shows up every few years to waste > everyone's time... but... I was updating my Kirkwood pages for > bookworm and noticed that the OpenRD images are gone. > > Now you may remember that we had the same situation for bullseye > (#934072) and Cyril kindly restored the netboot images: > https://salsa.debian.org/installer-team/debian-installer/-/commit/3ef30be60ab128f53a0cd16e6c1e91a3123988b4 > > I guess this change never got committed to master/main because > bullseye was going to be the last release for armel. Well, Rick explicitly said he was happy with bullseye or bookworm, so one of them got implemented… > But armel is still in bookworm and Rick confirmed he's running > bookworm on his OpenRD, so I see no reason why d-i wouldn't work if > we apply the same patch to the bookworm d-i. > > Honestly, I'm not sure if it's worth it as Rick is probably the one > Debian on OpenRD left, but since bookworm will probably be the last > release of armel (or not?) it would be nice if the installer was > working on OpenRD. > > Cyril or Vagrant, can you easily apply the patch above and generate a > test image for Rick? I don't mind doing that again, but what's the game plan here? If systems are already installed and working fine, then d-i is irrelevant. For any new systems people might want to deploy, installing bullseye then upgrading to bookworm already works? We don't have anything to support for armel at the moment (as far as master and testing/unstable are concerned), hence the current “let it die altogether” plan from a d-i perspective: https://lists.debian.org/debian-boot/2024/03/msg00016.html I'm not sure we should be encouraging new installations of 32-bit hardware at this stage (look at what's happening for i386…). I don't remember seeing a decision regarding armel's being a release arch for trixie, but kernel support is gone already (same thread): https://lists.debian.org/debian-arm/2024/01/msg8.html So OpenRD has no future in trixie as far as I understand. At least that would mean not having to do that again again, if we were to enable OpenRD images again for bookworm. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Salvatore Bonaccorso (2024-04-10): > 6.7.9-2 in unstable does not exibit the issue. Besides some reverts, the key fix seems to be 321da3dc1f3c92a12e3c5da934090d2992a8814c in master (v6.8-rc6~14^2~5), which was backported as d97e1c3602240bd35c48ef9aa978e0c47a511d03 (v6.7.7~167), so that seems rather consistent with your findings. Just got notified that the two reverts + cherry-pick reached the stable queue for 6.1, so I'd expect this to be fixed upstream by the time v6.1.86 is released. https://lore.kernel.org/linux-scsi/20240411044021.xejk54iznz3cd...@mraw.org/ https://lore.kernel.org/linux-scsi/2024041155-croon-dried-f649@gregkh/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Salvatore Bonaccorso (2024-04-10): > 6.7.9-2 in unstable does not exibit the issue. Besides some reverts, the key fix seems to be 321da3dc1f3c92a12e3c5da934090d2992a8814c in master (v6.8-rc6~14^2~5), which was backported as d97e1c3602240bd35c48ef9aa978e0c47a511d03 (v6.7.7~167), so that seems rather consistent with your findings. Just got notified that the two reverts + cherry-pick reached the stable queue for 6.1, so I'd expect this to be fixed upstream by the time v6.1.86 is released. https://lore.kernel.org/linux-scsi/20240411044021.xejk54iznz3cd...@mraw.org/ https://lore.kernel.org/linux-scsi/2024041155-croon-dried-f649@gregkh/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Control: forwarded -1 https://lore.kernel.org/stable/20240410193207.qnb75osxuk4ov...@mraw.org/ Salvatore Bonaccorso (2024-04-10): > Yes, if you prefer to not do the forwarding upstream (stable list, CC > to involved people + regression list), then I can try to take care of > it. Obviously the former would be great, as you are the finder and > have done all the work. Thanks for nudging me into walking those extra few meters. Let's see how that goes… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Control: forwarded -1 https://lore.kernel.org/stable/20240410193207.qnb75osxuk4ov...@mraw.org/ Salvatore Bonaccorso (2024-04-10): > Yes, if you prefer to not do the forwarding upstream (stable list, CC > to involved people + regression list), then I can try to take care of > it. Obviously the former would be great, as you are the finder and > have done all the work. Thanks for nudging me into walking those extra few meters. Let's see how that goes… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
