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
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Cyril Brulebois (2024-04-10): > Of course, since there are companion changes afterwards, it cannot be > simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream). > > > I'd appreciate if someone could carry the ball through the appropriate > channels upstream. And of course I only spotted minutes after sending the previous mail that v6.1.85 got published while I was busy bisecting. It's also affected by this bug. For the sake of completeness: except for the initial report, all tests were performed with the “SATA disk in a VM” setup described in my first follow-up. 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)
Cyril Brulebois (2024-04-10): > Of course, since there are companion changes afterwards, it cannot be > simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream). > > > I'd appreciate if someone could carry the ball through the appropriate > channels upstream. And of course I only spotted minutes after sending the previous mail that v6.1.85 got published while I was busy bisecting. It's also affected by this bug. For the sake of completeness: except for the initial report, all tests were performed with the “SATA disk in a VM” setup described in my first follow-up. 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)
Cyril Brulebois (2024-04-10):
> Intermediate results based on upstream stable releases: v6.1.80 is good,
> v6.1.81 is bad. Still ~200 commits to bisect.
Final results:
kibi@genova:~/hack/linux.git ((cf33e6ca12d81...)|BISECTING)$ git bisect bad
cf33e6ca12d814e1be2263cb76960d0019d7fb94 is the first bad commit
commit cf33e6ca12d814e1be2263cb76960d0019d7fb94
Author: Mike Christie
Date: Thu Dec 29 13:01:40 2022 -0600
scsi: core: Add struct for args to execution functions
[ Upstream commit d0949565811f0896c1c7e781ab2ad99d34273fdf ]
Move the SCSI execution functions to use a struct for passing in
optional
args. This commit adds the new struct, temporarily converts
scsi_execute()
and scsi_execute_req() ands a new helper, scsi_execute_cmd(), which
takes
the scsi_exec_args struct.
There should be no change in behavior. We no longer allow users to pass
in
any request->rq_flags value, but they were only passing in RQF_PM which
we
do support by allowing users to pass in the BLK_MQ_REQ flags used by
blk_mq_alloc_request().
Subsequent commits will convert scsi_execute() and scsi_execute_req()
users
to the new helpers then remove scsi_execute() and scsi_execute_req().
Signed-off-by: Mike Christie
Reviewed-by: Bart Van Assche
Reviewed-by: Christoph Hellwig
Reviewed-by: John Garry
Signed-off-by: Martin K. Petersen
Stable-dep-of: 321da3dc1f3c ("scsi: sd: usb_storage: uas: Access media
prior to querying device properties")
Signed-off-by: Sasha Levin
drivers/scsi/scsi_lib.c| 52
++
include/scsi/scsi_device.h | 51
-
2 files changed, 62 insertions(+), 41 deletions(-)
That's one of the 3 commits suggested by Diederik, good hunch.
I know hindsight is always 100% but “There should be no change in
behavior.”… :D
Of course, since there are companion changes afterwards, it cannot be
simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).
I'd appreciate if someone could carry the ball through the appropriate
channels upstream.
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)
Cyril Brulebois (2024-04-10):
> Intermediate results based on upstream stable releases: v6.1.80 is good,
> v6.1.81 is bad. Still ~200 commits to bisect.
Final results:
kibi@genova:~/hack/linux.git ((cf33e6ca12d81...)|BISECTING)$ git bisect bad
cf33e6ca12d814e1be2263cb76960d0019d7fb94 is the first bad commit
commit cf33e6ca12d814e1be2263cb76960d0019d7fb94
Author: Mike Christie
Date: Thu Dec 29 13:01:40 2022 -0600
scsi: core: Add struct for args to execution functions
[ Upstream commit d0949565811f0896c1c7e781ab2ad99d34273fdf ]
Move the SCSI execution functions to use a struct for passing in
optional
args. This commit adds the new struct, temporarily converts
scsi_execute()
and scsi_execute_req() ands a new helper, scsi_execute_cmd(), which
takes
the scsi_exec_args struct.
There should be no change in behavior. We no longer allow users to pass
in
any request->rq_flags value, but they were only passing in RQF_PM which
we
do support by allowing users to pass in the BLK_MQ_REQ flags used by
blk_mq_alloc_request().
Subsequent commits will convert scsi_execute() and scsi_execute_req()
users
to the new helpers then remove scsi_execute() and scsi_execute_req().
Signed-off-by: Mike Christie
Reviewed-by: Bart Van Assche
Reviewed-by: Christoph Hellwig
Reviewed-by: John Garry
Signed-off-by: Martin K. Petersen
Stable-dep-of: 321da3dc1f3c ("scsi: sd: usb_storage: uas: Access media
prior to querying device properties")
Signed-off-by: Sasha Levin
drivers/scsi/scsi_lib.c| 52
++
include/scsi/scsi_device.h | 51
-
2 files changed, 62 insertions(+), 41 deletions(-)
That's one of the 3 commits suggested by Diederik, good hunch.
I know hindsight is always 100% but “There should be no change in
behavior.”… :D
Of course, since there are companion changes afterwards, it cannot be
simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).
I'd appreciate if someone could carry the ball through the appropriate
channels upstream.
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)
Cyril Brulebois (2024-04-10): > v6.1.84 with stable's .config & bindeb-pkg still does; next up for me: > confirming good/bad and bisecting. Intermediate results based on upstream stable releases: v6.1.80 is good, v6.1.81 is bad. Still ~200 commits to bisect. 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)
Cyril Brulebois (2024-04-10): > v6.1.84 with stable's .config & bindeb-pkg still does; next up for me: > confirming good/bad and bisecting. Intermediate results based on upstream stable releases: v6.1.80 is good, v6.1.81 is bad. Still ~200 commits to bisect. 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. v6.1.84 with stable's .config & bindeb-pkg still does; next up for me: confirming good/bad and bisecting. 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. v6.1.84 with stable's .config & bindeb-pkg still does; next up for me: confirming good/bad and bisecting. 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)
Cyril Brulebois (2024-04-10):
> Salvatore Bonaccorso (2024-04-10):
> > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > Does the problem go away if you revert the following commits on top of
> > > -19?
> > >
> > > db6338f45971b4285ea368432a84033690eaf53c
> > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH
> > > handler
> > >
> > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > scsi: core: Move scsi_host_busy() out of host lock if it is for
> > > per-command
> > >
> > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > scsi: core: Add struct for args to execution functions
>
> Preparing that test right now, thanks Diederik.
This doesn't build, but I didn't try very hard:
/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function
‘sd_read_block_zero’:
/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error:
implicit declaration of function ‘scsi_execute_cmd’; did you mean
‘scsi_execute_req’? [-Werror=implicit-function-declaration]
> > Or if that does not find the culprit, would you be able to bisect the
> > upstrema changes beweeen 6.1.76 and 6.1.82?
I think I'll try and pinpoint when that regression came up, then figure
out what to try to get rid of it. Also testing v6.1.84 while I'm at it.
> > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to
> > > standby")
Reverting that one got me a successful build but that didn't help.
I'll need to find some more time to switch from throwing a patch into
the packaging repository to bindeb-pkg'ing from the mainline repository,
and to automate testing as much as possible. I'm familiar with the
exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
required in the amd64 case.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Cyril Brulebois (2024-04-10):
> Salvatore Bonaccorso (2024-04-10):
> > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > Does the problem go away if you revert the following commits on top of
> > > -19?
> > >
> > > db6338f45971b4285ea368432a84033690eaf53c
> > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH
> > > handler
> > >
> > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > scsi: core: Move scsi_host_busy() out of host lock if it is for
> > > per-command
> > >
> > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > scsi: core: Add struct for args to execution functions
>
> Preparing that test right now, thanks Diederik.
This doesn't build, but I didn't try very hard:
/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function
‘sd_read_block_zero’:
/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error:
implicit declaration of function ‘scsi_execute_cmd’; did you mean
‘scsi_execute_req’? [-Werror=implicit-function-declaration]
> > Or if that does not find the culprit, would you be able to bisect the
> > upstrema changes beweeen 6.1.76 and 6.1.82?
I think I'll try and pinpoint when that regression came up, then figure
out what to try to get rid of it. Also testing v6.1.84 while I'm at it.
> > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to
> > > standby")
Reverting that one got me a successful build but that didn't help.
I'll need to find some more time to switch from throwing a patch into
the packaging repository to bindeb-pkg'ing from the mainline repository,
and to automate testing as much as possible. I'm familiar with the
exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
required in the amd64 case.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Hi Salvatore,
Salvatore Bonaccorso (2024-04-10):
> On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > Hi Cyril,
> >
> > On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> > > Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> > > leads to losing some SMART information, at least as queried by munin (in
> > > Debian 12) when it comes to sensors.
> >
> > Does the problem go away if you revert the following commits on top of -19?
> >
> > db6338f45971b4285ea368432a84033690eaf53c
> > scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
> >
> > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
> >
> > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > scsi: core: Add struct for args to execution functions
Preparing that test right now, thanks Diederik.
> Or if that does not find the culprit, would you be able to bisect the
> upstrema changes beweeen 6.1.76 and 6.1.82?
>
> There would be for instance the following ata related change:
>
> 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to
> standby")
>
> If you can test it with other kernels, does the same happens on
> 6.7.7-1 and 6.7.9-2?
I'm not really keen on playing kernel ping-pong on this particular
machine (which is important in my infrastructure), but I've verified
that adding a SATA disk to an existing VM running Debian 12 on a
QEMU/libvirt Debian 12 host gives me similar results with -18 and -19
kernels (some data in the former case, no data at all in the latter
one).
I think I'd rather stay with 6.1.y kernels if at all possible, to avoid
having to figure out other changes that might be possibly required to
cope with newer kernels.
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)
Hi Salvatore,
Salvatore Bonaccorso (2024-04-10):
> On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > Hi Cyril,
> >
> > On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> > > Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> > > leads to losing some SMART information, at least as queried by munin (in
> > > Debian 12) when it comes to sensors.
> >
> > Does the problem go away if you revert the following commits on top of -19?
> >
> > db6338f45971b4285ea368432a84033690eaf53c
> > scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
> >
> > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
> >
> > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > scsi: core: Add struct for args to execution functions
Preparing that test right now, thanks Diederik.
> Or if that does not find the culprit, would you be able to bisect the
> upstrema changes beweeen 6.1.76 and 6.1.82?
>
> There would be for instance the following ata related change:
>
> 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to
> standby")
>
> If you can test it with other kernels, does the same happens on
> 6.7.7-1 and 6.7.9-2?
I'm not really keen on playing kernel ping-pong on this particular
machine (which is important in my infrastructure), but I've verified
that adding a SATA disk to an existing VM running Debian 12 on a
QEMU/libvirt Debian 12 host gives me similar results with -18 and -19
kernels (some data in the former case, no data at all in the latter
one).
I think I'd rather stay with 6.1.y kernels if at all possible, to avoid
having to figure out other changes that might be possibly required to
cope with newer kernels.
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
Hi, Marco d'Itri (2024-04-09): > Yes. Nowadays kmod has many more features related to compressed modules > and verification of signatures. > Can we agree that kmod should provide these programs for d-i? > Or can the d-i maintainers just tell us what they want? I meant to come back to this after experimenting, then things happened… I picked kmod at the time because it worked, and because busybox didn't work, which I summed up in: https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145 (plus follow-up commit, woopsie https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07 ) I'm fine with sticking to kmod regarding module support in d-i. I'm not sure we should keep support in two different modules, so dropping it from busybox would work for me. Others might have different views on this, though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Hi, Marco d'Itri (2024-04-09): > Yes. Nowadays kmod has many more features related to compressed modules > and verification of signatures. > Can we agree that kmod should provide these programs for d-i? > Or can the d-i maintainers just tell us what they want? I meant to come back to this after experimenting, then things happened… I picked kmod at the time because it worked, and because busybox didn't work, which I summed up in: https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145 (plus follow-up commit, woopsie https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07 ) I'm fine with sticking to kmod regarding module support in d-i. I'm not sure we should keep support in two different modules, so dropping it from busybox would work for me. Others might have different views on this, though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Hi, Marco d'Itri (2024-04-09): > Yes. Nowadays kmod has many more features related to compressed modules > and verification of signatures. > Can we agree that kmod should provide these programs for d-i? > Or can the d-i maintainers just tell us what they want? I meant to come back to this after experimenting, then things happened… I picked kmod at the time because it worked, and because busybox didn't work, which I summed up in: https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145 (plus follow-up commit, woopsie https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07 ) I'm fine with sticking to kmod regarding module support in d-i. I'm not sure we should keep support in two different modules, so dropping it from busybox would work for me. Others might have different views on this, though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Package: src:linux Version: 6.1.82-1 Severity: normal Hi, Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64 leads to losing some SMART information, at least as queried by munin (in Debian 12) when it comes to sensors. I'm getting the following results on the 2 pairs of disks in this machine: - 2×ST4000VN008-2DR1 (sda, sdb) - 2×ST8000VN004-2M21 (sdc, sdd) root@anchorage:~# /usr/sbin/smartctl -A --nocheck=standby -d ata /dev/sda smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-19-amd64] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org Device is in SLEEP mode, exit(2) For some reason, the “S.M.A.R.T values” graphs is still OK, while the “HDD temperature” graph (using the aforementioned command) isn't anymore. The “Device is in SLEEP mode” status getting reported is obviously a lie, since all disks are in use (one pair does system stuff, the other pair does media stuff). Rebooting a couple of time with this version gives consistent negative results. Rebooting into linux-image-6.1.0-18-amd64 gives data back. The trace that appears below seems to happen exactly once per boot (and not even once per disk). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant -- Package-specific info: ** Version: Linux version 6.1.0-19-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.82-1 (2024-03-28) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-19-amd64 root=/dev/mapper/data-root ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 23.726790] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 23.763253] EXT4-fs (dm-13): mounted filesystem with ordered data mode. Quota mode: none. [ 23.764773] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input5 [ 23.765529] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input6 [ 23.765566] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card0/input7 [ 23.765595] input: HDA Intel PCH Line Out as /devices/pci:00/:00:1b.0/sound/card0/input8 [ 23.765626] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input9 [ 23.785394] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 [ 23.786295] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 23.786473] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10 [ 23.798653] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.801990] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [ 23.823066] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.825531] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.916595] XFS (dm-4): Deprecated V4 format (crc=0) will not be supported after September 2030. [ 23.920456] EXT4-fs (dm-14): mounted filesystem with ordered data mode. Quota mode: none. [ 23.941160] XFS (dm-4): Mounting V4 Filesystem [ 24.076883] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Quota mode: none. [ 24.152240] XFS (dm-4): Ending clean mount [ 24.152258] xfs filesystem being mounted at /data/media supports timestamps until 2038 (0x7fff) [ 24.160691] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota mode: none. [ 24.177491] intel_rapl_common: Found RAPL domain package [ 24.177494] intel_rapl_common: Found RAPL domain core [ 24.177495] intel_rapl_common: Found RAPL domain uncore [ 24.177496] intel_rapl_common: Found RAPL domain dram [ 24.177500] intel_rapl_common: RAPL package-0 domain package locked by BIOS [ 24.177505] intel_rapl_common: RAPL package-0 domain dram locked by BIOS [ 24.415347] audit: type=1400 audit(1712616841.356:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=867 comm="apparmor_parser" [ 24.415751] audit: type=1400 audit(1712616841.356:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=868 comm="apparmor_parser" [ 24.415755] audit: type=1400 audit(1712616841.356:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=868 comm="apparmor_parser" [ 24.430914] audit: type=1400 audit(1712616841.372:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=870 comm="apparmor_parser" [ 24.430919] audit: type=1400 audit(1712616841.372:6): apparmor="ST
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Package: src:linux Version: 6.1.82-1 Severity: normal Hi, Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64 leads to losing some SMART information, at least as queried by munin (in Debian 12) when it comes to sensors. I'm getting the following results on the 2 pairs of disks in this machine: - 2×ST4000VN008-2DR1 (sda, sdb) - 2×ST8000VN004-2M21 (sdc, sdd) root@anchorage:~# /usr/sbin/smartctl -A --nocheck=standby -d ata /dev/sda smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-19-amd64] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org Device is in SLEEP mode, exit(2) For some reason, the “S.M.A.R.T values” graphs is still OK, while the “HDD temperature” graph (using the aforementioned command) isn't anymore. The “Device is in SLEEP mode” status getting reported is obviously a lie, since all disks are in use (one pair does system stuff, the other pair does media stuff). Rebooting a couple of time with this version gives consistent negative results. Rebooting into linux-image-6.1.0-18-amd64 gives data back. The trace that appears below seems to happen exactly once per boot (and not even once per disk). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant -- Package-specific info: ** Version: Linux version 6.1.0-19-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.82-1 (2024-03-28) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-19-amd64 root=/dev/mapper/data-root ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 23.726790] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 23.763253] EXT4-fs (dm-13): mounted filesystem with ordered data mode. Quota mode: none. [ 23.764773] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input5 [ 23.765529] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input6 [ 23.765566] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card0/input7 [ 23.765595] input: HDA Intel PCH Line Out as /devices/pci:00/:00:1b.0/sound/card0/input8 [ 23.765626] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input9 [ 23.785394] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 [ 23.786295] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 23.786473] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10 [ 23.798653] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.801990] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [ 23.823066] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.825531] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.916595] XFS (dm-4): Deprecated V4 format (crc=0) will not be supported after September 2030. [ 23.920456] EXT4-fs (dm-14): mounted filesystem with ordered data mode. Quota mode: none. [ 23.941160] XFS (dm-4): Mounting V4 Filesystem [ 24.076883] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Quota mode: none. [ 24.152240] XFS (dm-4): Ending clean mount [ 24.152258] xfs filesystem being mounted at /data/media supports timestamps until 2038 (0x7fff) [ 24.160691] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota mode: none. [ 24.177491] intel_rapl_common: Found RAPL domain package [ 24.177494] intel_rapl_common: Found RAPL domain core [ 24.177495] intel_rapl_common: Found RAPL domain uncore [ 24.177496] intel_rapl_common: Found RAPL domain dram [ 24.177500] intel_rapl_common: RAPL package-0 domain package locked by BIOS [ 24.177505] intel_rapl_common: RAPL package-0 domain dram locked by BIOS [ 24.415347] audit: type=1400 audit(1712616841.356:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=867 comm="apparmor_parser" [ 24.415751] audit: type=1400 audit(1712616841.356:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=868 comm="apparmor_parser" [ 24.415755] audit: type=1400 audit(1712616841.356:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=868 comm="apparmor_parser" [ 24.430914] audit: type=1400 audit(1712616841.372:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=870 comm="apparmor_parser" [ 24.430919] audit: type=1400 audit(1712616841.372:6): apparmor="ST
Bug#1068197: debian-installer: accesses the internet during build
[ Switching from ML to bug. ] Hi Jonathan, Jonathan Carter (2024-04-01): > On 2024/04/01 18:55, Aurelien Jarno wrote: > > debian-installer attemps network access during build, although only to > > the mirrors listed in /etc/apt/sources.list and in a secure way. This is > > forbidden by Policy 4.9: > > > >For packages in the main archive, required targets must not attempt > >network access, except, via the loopback interface, to services on the > >build host that have been started by the build. > > > > In addition this brings constraints to the build daemons infrastructure. > > As far as I know, this doesn't happen until after d-i asked the question "Do > you want to use a network mirror?" and the user answered "Yes", in which > case I think that would count as informed consent. This isn't about d-i runtime, this is about src:debian-installer's *build* requiring network access, which is a very well known problem (even though there are no obvious solutions, at least that I'm aware of), and that's now getting in the way of changes being considered regarding the buildd network. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068197: debian-installer: accesses the internet during build
[ Switching from ML to bug. ] Hi Jonathan, Jonathan Carter (2024-04-01): > On 2024/04/01 18:55, Aurelien Jarno wrote: > > debian-installer attemps network access during build, although only to > > the mirrors listed in /etc/apt/sources.list and in a secure way. This is > > forbidden by Policy 4.9: > > > >For packages in the main archive, required targets must not attempt > >network access, except, via the loopback interface, to services on the > >build host that have been started by the build. > > > > In addition this brings constraints to the build daemons infrastructure. > > As far as I know, this doesn't happen until after d-i asked the question "Do > you want to use a network mirror?" and the user answered "Yes", in which > case I think that would count as informed consent. This isn't about d-i runtime, this is about src:debian-installer's *build* requiring network access, which is a very well known problem (even though there are no obvious solutions, at least that I'm aware of), and that's now getting in the way of changes being considered regarding the buildd network. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068197: debian-installer: accesses the internet during build
[ Switching from ML to bug. ] Hi Jonathan, Jonathan Carter (2024-04-01): > On 2024/04/01 18:55, Aurelien Jarno wrote: > > debian-installer attemps network access during build, although only to > > the mirrors listed in /etc/apt/sources.list and in a secure way. This is > > forbidden by Policy 4.9: > > > >For packages in the main archive, required targets must not attempt > >network access, except, via the loopback interface, to services on the > >build host that have been started by the build. > > > > In addition this brings constraints to the build daemons infrastructure. > > As far as I know, this doesn't happen until after d-i asked the question "Do > you want to use a network mirror?" and the user answered "Yes", in which > case I think that would count as informed consent. This isn't about d-i runtime, this is about src:debian-installer's *build* requiring network access, which is a very well known problem (even though there are no obvious solutions, at least that I'm aware of), and that's now getting in the way of changes being considered regarding the buildd network. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Re-planning for 12.6
Hi, Adam D. Barratt (2024-04-01): > As we had to postpone 12.6, let's look at alternative dates. I should be able to make anything work. 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, Adam D. Barratt (2024-04-01): > As we had to postpone 12.6, let's look at alternative dates. I should be able to make anything work. 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, Adam D. Barratt (2024-04-01): > As we had to postpone 12.6, let's look at alternative dates. I should be able to make anything work. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: xz backdoor
Sirius (2024-03-30): > I have seen discussion about shifting away from the whole auto(re)conf > tooling to CMake or Meson with there being a reasonable drawback to > CMake. Is that something being discussed within Debian as well? Talking about alternatives to autotools: https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da8a2bbb81307644efdb58db2c422d9ba7 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1066479: opendnssec: FTBFS: ../../common/scheduler/task.c:137:25: error: implicit declaration of function ‘clamp’ [-Werror=implicit-function-declaration]
Control: tag -1 patch pending Lucas Nussbaum (2024-03-13): > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration > > Relevant part (hopefully): > > ../../common/scheduler/task.c: In function ‘task_perform’: > > ../../common/scheduler/task.c:137:25: error: implicit declaration of > > function ‘clamp’ [-Werror=implicit-function-declaration] > > 137 | task->backoff = clamp(task->backoff * 2, 60, > > ODS_SE_MAX_BACKOFF); > > | ^ > > cc1: some warnings being treated as errors > > make[4]: *** [Makefile:601: scheduler/task.o] Error 1 I thought there would be several things but apparently that's just the one. A quick look upstream shows there are more PRs and more fixups needed for even newer compilers, but I'm limiting my patch to the bare minimum. Since that's been open for 10+ days, and since reverse dependencies could get kicked out of testing, I'm uploading an NMU right now so that I don't forget, but to DELAYED/2 so there's some room to do things differently if desired. I'm happy to reschedule/cancel if needed. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ diff -Nru opendnssec-2.1.13/debian/changelog opendnssec-2.1.13/debian/changelog --- opendnssec-2.1.13/debian/changelog 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/changelog 2024-03-26 14:27:44.0 +0100 @@ -1,3 +1,11 @@ +opendnssec (1:2.1.13-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS due to missing utilities.h include for the clamp declaration +(Closes: #1066479): 0018-fix-missing-include.patch + + -- Cyril Brulebois Tue, 26 Mar 2024 14:27:44 +0100 + opendnssec (1:2.1.13-1) unstable; urgency=medium * New upstream version 2.1.13 diff -Nru opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch --- opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 1970-01-01 01:00:00.0 +0100 +++ opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 2024-03-26 14:23:18.0 +0100 @@ -0,0 +1,10 @@ +--- a/common/scheduler/task.c b/common/scheduler/task.c +@@ -41,6 +41,7 @@ + #include "file.h" + #include "util.h" + #include "log.h" ++#include "utilities.h" + + static const char* task_str = "task"; + static pthread_mutex_t worklock = PTHREAD_MUTEX_INITIALIZER; diff -Nru opendnssec-2.1.13/debian/patches/series opendnssec-2.1.13/debian/patches/series --- opendnssec-2.1.13/debian/patches/series 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/patches/series 2024-03-26 14:27:32.0 +0100 @@ -8,3 +8,4 @@ 0015-remove-strptime-build-warning.patch 0016-m4-acx_libxml2.m4-use-pkg-config-instead-of-xml2-con.patch 0017-mysql8_my_bool.patch +0018-fix-missing-include.patch signature.asc Description: PGP signature
Bug#1066479: opendnssec: FTBFS: ../../common/scheduler/task.c:137:25: error: implicit declaration of function ‘clamp’ [-Werror=implicit-function-declaration]
Control: tag -1 patch pending Lucas Nussbaum (2024-03-13): > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration > > Relevant part (hopefully): > > ../../common/scheduler/task.c: In function ‘task_perform’: > > ../../common/scheduler/task.c:137:25: error: implicit declaration of > > function ‘clamp’ [-Werror=implicit-function-declaration] > > 137 | task->backoff = clamp(task->backoff * 2, 60, > > ODS_SE_MAX_BACKOFF); > > | ^ > > cc1: some warnings being treated as errors > > make[4]: *** [Makefile:601: scheduler/task.o] Error 1 I thought there would be several things but apparently that's just the one. A quick look upstream shows there are more PRs and more fixups needed for even newer compilers, but I'm limiting my patch to the bare minimum. Since that's been open for 10+ days, and since reverse dependencies could get kicked out of testing, I'm uploading an NMU right now so that I don't forget, but to DELAYED/2 so there's some room to do things differently if desired. I'm happy to reschedule/cancel if needed. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ diff -Nru opendnssec-2.1.13/debian/changelog opendnssec-2.1.13/debian/changelog --- opendnssec-2.1.13/debian/changelog 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/changelog 2024-03-26 14:27:44.0 +0100 @@ -1,3 +1,11 @@ +opendnssec (1:2.1.13-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS due to missing utilities.h include for the clamp declaration +(Closes: #1066479): 0018-fix-missing-include.patch + + -- Cyril Brulebois Tue, 26 Mar 2024 14:27:44 +0100 + opendnssec (1:2.1.13-1) unstable; urgency=medium * New upstream version 2.1.13 diff -Nru opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch --- opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 1970-01-01 01:00:00.0 +0100 +++ opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 2024-03-26 14:23:18.0 +0100 @@ -0,0 +1,10 @@ +--- a/common/scheduler/task.c b/common/scheduler/task.c +@@ -41,6 +41,7 @@ + #include "file.h" + #include "util.h" + #include "log.h" ++#include "utilities.h" + + static const char* task_str = "task"; + static pthread_mutex_t worklock = PTHREAD_MUTEX_INITIALIZER; diff -Nru opendnssec-2.1.13/debian/patches/series opendnssec-2.1.13/debian/patches/series --- opendnssec-2.1.13/debian/patches/series 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/patches/series 2024-03-26 14:27:32.0 +0100 @@ -8,3 +8,4 @@ 0015-remove-strptime-build-warning.patch 0016-m4-acx_libxml2.m4-use-pkg-config-instead-of-xml2-con.patch 0017-mysql8_my_bool.patch +0018-fix-missing-include.patch signature.asc Description: PGP signature
Bug#1066778: golang-github-containerd-go-runc: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/containerd/go-runc returned exit code 1
Shengjing Zhu (2024-03-14): > On Wed, Mar 13, 2024 at 11:05 PM Lucas Nussbaum wrote: > > > console_test.go:42: mkdir /tmp/foo: not a directory > > > --- FAIL: TestTempConsoleWithXdgRuntimeDir (0.00s) > > I wonder if your chroot doesn't have the /tmp directory? Writing to hardcoded paths under /tmp has never been a good idea in the first place. Alright, this is a test suite but we're not usually trying to write outside the build directory. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1066778: golang-github-containerd-go-runc: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/containerd/go-runc returned exit code 1
Shengjing Zhu (2024-03-14): > On Wed, Mar 13, 2024 at 11:05 PM Lucas Nussbaum wrote: > > > console_test.go:42: mkdir /tmp/foo: not a directory > > > --- FAIL: TestTempConsoleWithXdgRuntimeDir (0.00s) > > I wonder if your chroot doesn't have the /tmp directory? Writing to hardcoded paths under /tmp has never been a good idea in the first place. Alright, this is a test suite but we're not usually trying to write outside the build directory. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#851541: Bug#902668: Draft for rewrite of https://www.debian.org/CD/verify
Hi, Tassia Camoes Araujo (2024-03-25): > I've reviewed the proposed patch, and I think it should be applied as > soon as possible. > > It seems Laura was waiting for a final review before applying this patch > (long overdue!), which IMHO would bring much more clarity to the image > verification process (usually, a big struggle to new users). > > We should make a decision about the long key IDs request (points 1 and 2 > from #851541), and once those changes go online, I think both bugs could > be closed (#902668 and #851541). > > Thanks for all who have invested energy to clarify this process, and I > hope we can benefit from your work very soon! > > Cheers, > > Tassia. Cc += debian-cd@ for information. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#851541: Bug#902668: Draft for rewrite of https://www.debian.org/CD/verify
Hi, Tassia Camoes Araujo (2024-03-25): > I've reviewed the proposed patch, and I think it should be applied as > soon as possible. > > It seems Laura was waiting for a final review before applying this patch > (long overdue!), which IMHO would bring much more clarity to the image > verification process (usually, a big struggle to new users). > > We should make a decision about the long key IDs request (points 1 and 2 > from #851541), and once those changes go online, I think both bugs could > be closed (#902668 and #851541). > > Thanks for all who have invested energy to clarify this process, and I > hope we can benefit from your work very soon! > > Cheers, > > Tassia. Cc += debian-cd@ for information. 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#902668: Draft for rewrite of https://www.debian.org/CD/verify
Hi, Tassia Camoes Araujo (2024-03-25): > I've reviewed the proposed patch, and I think it should be applied as > soon as possible. > > It seems Laura was waiting for a final review before applying this patch > (long overdue!), which IMHO would bring much more clarity to the image > verification process (usually, a big struggle to new users). > > We should make a decision about the long key IDs request (points 1 and 2 > from #851541), and once those changes go online, I think both bugs could > be closed (#902668 and #851541). > > Thanks for all who have invested energy to clarify this process, and I > hope we can benefit from your work very soon! > > Cheers, > > Tassia. Cc += debian-cd@ for information. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: problems with amd64 testing images
Hi, Jogi Hofmüller (2024-03-24): > I just failed to install debian testing using the latest > debian-testing-amd64-netinst.iso. for amd64 this has two problems: > > 1) it misses at least libaio.so so pvcreate does not run and I cannot set up > the disk as planned > 2) it is more than 2 weeks old (2024-03-09) and there are no newer images > for amd64 Some pointers: - https://lists.debian.org/debian-devel-announce/2024/02/msg5.html - https://lists.debian.org/debian-cd/2024/03/msg00013.html > Please CC when replying since I am not on the list Done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
