Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr
Chris Hofstaedtler (2024-05-30): > Yes, having migrated enough packages I (we) believe this is safe. > > Please land this in trixie before the transition freeze. Please let me get the security fixes out of the way and I'll look into those issues afterwards. Feel free to ping back in a week or two if that hasn't happened by then (I don't control answer delays from either security or release teams). Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1072501: ITP: systemd-boot-installer -- Install systemd-boot on a hard disk
Hi, Luca Boccassi (2024-06-03): > Package: wnpp > Severity: wishlist > Owner: Luca Boccassi > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: systemd-boot-installer > Version : 0.1 > Upstream Author : Luca Boccassi > * URL : > https://salsa.debian.org/installer-team/systemd-boot-installer > * License : GPL-2.0-or-later > Programming Lang: shell > Description : debian-installer component to install systemd-boot > as the bootloader Could we have some kind of heads-up via X-D-Cc to debian-boot@ for such things, please? Discovering we have a new package under our namespace via a “Processing” mail from ftpmaster is awkward. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
Luca Boccassi (2024-05-27): > I'll upload a D-I fix that adds x-initrd.attach to crypttab by default > shortly. Yes you can ignore the "unknown option" message, as the > Debian-specific initramfs-tools scripts do not know about it, but > that's fine, it's for the shutdown path anyway. And the finalize > messages can also be ignored. Having a cryptsetup warning about an unknown option on the very first line seen by users after the bootloader step doesn't feel appropriate at all to me. Telling users to just ignore it neither. For the record, on a fresh install, that means: cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'x-initrd.attach' Please unlock disk sda5_crypt: _ Looping in the cryptsetup team. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
Hoi, Roland Clobus (2024-05-25): > Source: hw-detect > Version: 1.160 > Severity: normal > Tags: patch d-i Just to confirm, which linux version was this tested against? > I have an USB wireless adapter that uses the r8712u kernel module and > that requires firmware from non-free-firmware. > > When I run the Debian installer, the missing firmware file is > correctly identified and installed by 'check-missing-firmware.sh'. > However, the kernel module is mis-identified as 'usb'. As you found out, having 'usb' is rather widespread, hence the existence of the function you patched. What seems weird to my (not at all expert in the kernel area) eyes is the unbound thing that led you to introduce that special case. I see that's a module from staging, maybe it's not behaving like it should? At least differently from other modules… I spotted 1422b526fba994cf05fd288a152106563b875fce that fixed a race condition regarding firmware loading (fix available in v6.6-rc1 and v6.1.52), maybe there are other similar issues? > When I disconnect the adapter and reconnect it, the installer is able > to use the adapter properly. > > Attached is a patch that allows the module to be identified correctly. > If desired, I can send the patch instead as a merge request on Salsa. > > However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not sufficient > to enable the adapter, it still needs a physical reconnect. > In the attached screenshot from the installer (sid) the result of the patch > is shown. Also in the QEMU environment, I need to disconnect and reconnect > the USB device from the host. > > I tried several options, but could not get them to work: bind/unbind [1] > authorized, usbreset [2] > Do you know a solution (apart from a physical reconnect)? I'd suggest a search in upstream bugzilla and mailing lists. I'm adding the kernel maintainers in copy, in case they have better ideas. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071873: debian-installer: FTBFS: unsatisfiable build-dependencies
Control: tag -1 patch Santiago Vila (2024-05-25): > Package: src:debian-installer > Version: 20230607+deb12u5 > Severity: serious > Tags: ftbfs master is fine. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1
Hi Colin, Colin Watson (2024-05-21): > I've just fixed this in unstable, but it would be helpful to have it > in place for installs of bookworm too. ACK on principle; you'll want a dch -r though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Cyril Brulebois (2024-05-17): > I was tempted to open a second bug on crowdsec-firewall-bouncer, > referencing this one, and to upload both packages to unstable (this one > with the upstream patch, the other one with a bumped build-dep to make > sure it cannot be rebuilt against the broken package; there are a lot of > binNMUs flying around already). Then to submit p-u requests to get the > same updates into bookworm. But does that issue warrant a DSA? The crowdsec-firewall-bouncer bug is #1071248. The only other reverse dependency is opensnitch (maintainers Cc'd) but it doesn't seem to use the AddSet() function (in any versions/suites). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071248: crowdsec-firewall-bouncer: blocks wrong IPv4 and IPv6 addresses on LE systems (reversed byte order)
Package: crowdsec-firewall-bouncer Version: 0.0.25-3 Severity: grave Tags: patch security Justification: renders package unusable X-Debbugs-Cc: Debian Security Team , debian.pack...@crowdsec.net Hi, This is the bouncer side of #1071247: golang-github-google-nftables up to version 0.1.0-3 ships a broken AddSet() function, which results in IPv4 and IPv6 addresses to be in reverse byte order at the nftables level on LE systems (i.e. all release architectures but s930x). This issue was confirmed to go away on LE systems once the bouncer gets rebuilt against a fixed golang-github-google-nftables-dev package, and not to regress on BE systems. Grave looks warranted as the package doesn't fulfill its purposes (blocking suspicious addresses), giving a false sense of security… while also blocking potentially harmless addresses. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Control: found -1 0.1.0-3 Control: notfound -1 0.1.0-4 Cyril Brulebois (2024-05-17): > Package: golang-github-google-nftables-dev > Version: 0.1.0-4 > I also verified that applying the golang-github-google-nftables patch > and rebuilding crowdsec-firewall-bouncer against it fixes the problem > on LE systems, and doesn't regress on BE systems. Sorry for the version discrepancy; reportbug warned me but I lost track while thinking about a possible DSA, etc. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Package: golang-github-google-nftables-dev Version: 0.1.0-4 Severity: serious Tags: upstream security patch Justification: broken feature, security implications X-Debbugs-Cc: Debian Security Team , debian.pack...@crowdsec.net Hi, I was contacted by CrowdSec upstream about a bug report filed against the firewall bouncer, which is in charge of applying rules at the firewall level based on decisions passed on by the crowdsec engine: https://github.com/crowdsecurity/cs-firewall-bouncer/issues/368 I've been able to verify that despite correct IPv4 and IPv6 addresses getting logged by the bouncer (e.g. at debug level), all of them get added in reverse byte order at the nftables level. :( Upstream bug: https://github.com/google/nftables/issues/225 Upstream fix: https://github.com/google/nftables/pull/226 I confirmed that affects LE systems (e.g. amd64), both in stable and in unstable (same versions, modulo binNMUs). That doesn't affect BE systems (i.e. s390x, verified via debvm). I also verified that applying the golang-github-google-nftables patch and rebuilding crowdsec-firewall-bouncer against it fixes the problem on LE systems, and doesn't regress on BE systems. Security team, I've added the security tag (and you to Cc) because the consequence is that admins who installed crowdsec-firewall-bouncer have been thinking they were applying restrictions gathered by crowdsec, while they've actually been (1) not blocking offending addresses and (2) blocking possibly harmless ones. I was tempted to open a second bug on crowdsec-firewall-bouncer, referencing this one, and to upload both packages to unstable (this one with the upstream patch, the other one with a bumped build-dep to make sure it cannot be rebuilt against the broken package; there are a lot of binNMUs flying around already). Then to submit p-u requests to get the same updates into bookworm. But does that issue warrant a DSA? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#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
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
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#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#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#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#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#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#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#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)
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): > 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)
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#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-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#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#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#1060915: golang-entgo-ent: Flaky tests due to relying on default result ordering
Hi Paul, Paul Mars (2024-01-16): > Here is a patch to fix the issue. Sorry, I didn't spot this bug report right away (its metadata got adjusted along the way). Thanks for the bug report and the patch, on their way to unstable! Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
Hi, Aurelien Jarno (2024-03-13): > The date of the next point release is slowly approaching, could you > please have a look at this? Sorry, lost track of that one. Feel free to upload. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1066074: ntfs-3g: broken shlibs (deb and udeb)
Source: ntfs-3g
Version: 1:2022.10.3-1.1
Severity: serious
Tags: d-i
Justification: broken shlibs
X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung
Hi,
Here's what debian/libntfs-3g89t64/DEBIAN/shlibs looks like after
a build:
libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 libntfs-3g89
That doesn't match binaries shipped by the source package.
See debian/rules:
SONAME = $(shell objdump -p debian/tmp/lib/*/libntfs-3g.so.*.* | awk -Fso.
'/SONAME/ { print $$2 }')
[…]
override_dh_makeshlibs:
dh_makeshlibs --add-udeb=ntfs-3g-udeb -Vlibntfs-3g$(SONAME)
In the previous version we had:
libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 ntfs-3g-udeb
Adding 't64' at the end of the dh_makeshlibs line quoted above gives:
libntfs-3g 89 libntfs-3g89t64
udeb: libntfs-3g 89 ntfs-3g-udeb
which certainly looks much better. I haven't performed any rebuild test
for the reverse dependencies of the library, nor runtime tests on the
d-i side (other packages are broken right now). The Depends field of
the udeb looks correct now though:
-Depends: libc6-udeb (>= 2.37), libntfs-3g89, fuse3-udeb
+Depends: libc6-udeb (>= 2.37), fuse3-udeb
I'll leave it up to the 64-bit time_t transition drivers to choose how
to address this issue (add t64 on the SONAME line, or just in the
dh_makeshlibs override, or something else), and to track down packages
that might have been rebuilt against the broken library.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Bug#1066073: wireless-tools: nmudiff for the 30~pre9-16.2 upload
Source: wireless-tools Version: 30~pre9-16.2 Severity: normal Tags: d-i patch X-Debbugs-Cc: Steve Langasek , debian-b...@lists.debian.org Hi, The previous upload broke udeb support, pointing to a non-existing udeb in the shlibs file. This made wireless-tools-udeb uninstallable. Seeing how this package is QA-maintained, I decided to just upload a fix without filing a bug report separately. I've verified the Depends field of the wireless-tools-udeb package looks fine; I didn't try and perform any runtime tests (other packages are broken right now). The source debdiff is attached. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru wireless-tools-30~pre9/debian/changelog wireless-tools-30~pre9/debian/changelog --- wireless-tools-30~pre9/debian/changelog 2024-02-29 03:02:19.0 +0100 +++ wireless-tools-30~pre9/debian/changelog 2024-03-12 01:42:45.0 +0100 @@ -1,3 +1,11 @@ +wireless-tools (30~pre9-16.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix shlibs entry for the udeb: it isn't getting renamed for the 64-bit +time_t transition. This makes wireless-tools-udeb installable again. + + -- Cyril Brulebois Tue, 12 Mar 2024 01:42:45 +0100 + wireless-tools (30~pre9-16.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru wireless-tools-30~pre9/debian/libiw30t64.shlibs wireless-tools-30~pre9/debian/libiw30t64.shlibs --- wireless-tools-30~pre9/debian/libiw30t64.shlibs 2024-02-29 03:01:29.0 +0100 +++ wireless-tools-30~pre9/debian/libiw30t64.shlibs 2024-03-12 01:42:42.0 +0100 @@ -1,2 +1,2 @@ libiw 30 libiw30t64 (>= 30~pre1) -udeb: libiw 30 libiw30t64-udeb (>= 30~pre1) +udeb: libiw 30 libiw30-udeb (>= 30~pre1)
Bug#1066071: mtdev: broken shlibs, leading to uninstallable udebs
Source: mtdev Version: 1.1.6-1.1 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung Hi, Your NMU broke this package's shlibs. Before: libmtdev 1 libmtdev1 udeb: libmtdev 1 libmtdev1-udeb After: libmtdev 1 libmtdev1t64 At the moment, at least the following package is broken: The following packages have unmet dependencies: libinput10-udeb : Depends: libmtdev1t64 but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1066070: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable
Source: libpng1.6 Version: 1.6.43-3 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org Hi, Your debian/rules includes this: override_dh_makeshlibs: dh_makeshlibs --add-udeb=libpng16-16-udeb -a and that's indeed the package that's listed in debian/control. However, debian/libpng16-16t64.shlibs has it wrong: libpng16 16 libpng16-16t64 (>= 1.6.2) udeb: libpng16 16 libpng16-udeb (>= 1.6.2) At this point, that breaks at least: The following packages have unmet dependencies: libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1066069: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable
Source: libpng1.6 Version: 1.6.43-3 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org Hi, Your debian/rules includes this: override_dh_makeshlibs: dh_makeshlibs --add-udeb=libpng16-16-udeb -a and that's indeed the package that's listed in debian/control. However, debian/libpng16-16t64.shlibs has it wrong: libpng16 16 libpng16-16t64 (>= 1.6.2) udeb: libpng16 16 libpng16-udeb (>= 1.6.2) At this point, that breaks at least: The following packages have unmet dependencies: libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Santiago Vila (2024-03-06): > I looked at the build log and found the problem: The package has a missing > build-depends on passwd, which is no longer build-essential in trixie/sid. Alright, that's the kind of thing I had in mind initially but I'm pretty sure one of the attempt to reproduce started with a brand new build chroot… Oh well. > I am a member of Debian Go (joined to do QA stuff). > Would it help if I fix this myself by doing a "Team Upload"? Thanks for the offer, but I do have another related FTBFS on my plate (even if it was misfiled in the first place), so I'll probably lump up both uploads together. :) Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Cyril Brulebois (2024-02-15): > Is that problem still current? I cannot reproduce it with a brand new > sid environment, freshly created via either `pbuilder --create` or > `sbuild-createchroot`. For the record, I did receive a proposal to get access to such a system back then (thanks!), but I couldn't get to it just yet. Not sure about this though, received today (2024-03-06) for 3 packages: crowdsec 1.4.6-6 is marked for autoremoval from testing on 2024-03-05 Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Philip Hands (2024-03-05): > Cool, in that case I'll fix those two things and then use the result > for the MR[1], and if the openQA test runs look OK, will merge that. Only skimmed over it, but that looks sensible, thanks all. Is it worth getting d-l-english involved in a final review before getting that translated? Contrary to a lot of not-so-critical l10n material, that particular screen is crucial, and I'd hate it if we wasted translator efforts due to a missed typo or obvious improvement. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Hi, Cyril Brulebois (2024-01-17): > Santiago Vila (2023-12-05): > > […] > > Thanks for the report. The relevant part didn't appear in the excerpt > so I'm quoting the full build log below: > > > === RUN TestOneShot/permission_denied > > file_test.go:234: > > Error Trace: > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:25 > > > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/file/file_test.go:234 > > Error: An error is expected but got nil. > > Test: TestOneShot/permission_denied > > === RUN TestOneShot/ignored_directory > > === RUN TestOneShot/glob_syntax_error > > === RUN TestOneShot/no_matching_files > > === RUN TestOneShot/test.log > > === RUN TestOneShot/test.log.gz > > === RUN TestOneShot/unexpected_end_of_gzip_stream > > === RUN TestOneShot/deleted_file > > --- FAIL: TestOneShot (0.00s) > > --- FAIL: TestOneShot/permission_denied (0.00s) > > --- PASS: TestOneShot/ignored_directory (0.00s) > > --- PASS: TestOneShot/glob_syntax_error (0.00s) > > --- PASS: TestOneShot/no_matching_files (0.00s) > > --- PASS: TestOneShot/test.log (0.00s) > > --- PASS: TestOneShot/test.log.gz (0.00s) > > --- PASS: TestOneShot/unexpected_end_of_gzip_stream (0.00s) > > --- PASS: TestOneShot/deleted_file (0.00s) Is that problem still current? I cannot reproduce it with a brand new sid environment, freshly created via either `pbuilder --create` or `sbuild-createchroot`. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Hi Santiago, Santiago Vila (2023-12-05): > […] Thanks for the report. The relevant part didn't appear in the excerpt so I'm quoting the full build log below: > === RUN TestOneShot/permission_denied > file_test.go:234: > Error Trace: > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:25 > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/file/file_test.go:234 > Error: An error is expected but got nil. > Test: TestOneShot/permission_denied > === RUN TestOneShot/ignored_directory > === RUN TestOneShot/glob_syntax_error > === RUN TestOneShot/no_matching_files > === RUN TestOneShot/test.log > === RUN TestOneShot/test.log.gz > === RUN TestOneShot/unexpected_end_of_gzip_stream > === RUN TestOneShot/deleted_file > --- FAIL: TestOneShot (0.00s) > --- FAIL: TestOneShot/permission_denied (0.00s) > --- PASS: TestOneShot/ignored_directory (0.00s) > --- PASS: TestOneShot/glob_syntax_error (0.00s) > --- PASS: TestOneShot/no_matching_files (0.00s) > --- PASS: TestOneShot/test.log (0.00s) > --- PASS: TestOneShot/test.log.gz (0.00s) > --- PASS: TestOneShot/unexpected_end_of_gzip_stream (0.00s) > --- PASS: TestOneShot/deleted_file (0.00s) I'll investigate shortly. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Julian Andres Klode (2023-12-25): > We picked the previous XFS patch for extent parsing but did not pick > this one because it had not been merged at that point yet, the fix > only got merged two weeks or so ago, and we didn't want to take chances > and pick it ahead of time as it's security critical code (filesystem > parsing is where all the security bugs live!). > > The release was supposed to be out 2 weeks ago but got pushed back > another week to last week's release, sadly. Thanks for all the details, and sorry if it appeared I was chasing you down; I just stumbled upon this again while re-testing various things, and was merely wondering whether things were. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Julian Andres Klode (2023-12-25): > The final grub 2.12 that includes the fix should hit unstable in the > middle of January. As you might be aware many are busy with family > stuff and holiday celebrations right now. Sure. I wasn't aware an upstream release was in the pipes, only that patches have existed and been confirmed OK for close to 2 months. > As always though it stands to reason that this is a change that should > (have been) reverted in xfsprogs first until a grub that understands > it has been released in a stable point release such that you can use a > stable grub to inspect an XFS filesystem created by a trixie xfsprogs. The more we tick boxes in the compatibility matrix, the happier, yes. > It seems the bug has been wrongly reassigned instead of being cloned > and reassigned, so I'm cloning it back to xfsprogs. Right, this would have been easier to track if debian-boot@ had been put (and kept) in the loop all along. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Hi,
Anthony Iliopoulos (2023-10-30):
> On Mon, Oct 30, 2023 at 04:19:32PM +0100, Philip Hands wrote:
> > Anthony Iliopoulos writes:
> >
> > > On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
> > ...
> > >> error: invalid XFS directory entry.
> > ...
> > > This issue exists independently of the large extent counter, and it is
> > > related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> > > fuzzing the XFS filesystem"). That's actually the issue described in
> > > #1051543.
> >
> > Ah, yes -- good point.
> >
> > > There's a proposed fix at [1], and it works as expected with that patch
> > > applied.
> > ...
> > > [1]
> > > https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
> >
> > I can confirm that having applied both patches:
> >
> > https://salsa.debian.org/philh/grub2/-/pipelines/596346
> >
> > it now succeeds at both installing grub, and then booting the system:
> >
> > https://openqa.debian.net/tests/200503#details
>
> Thanks for confirming, perhaps then you can add your tested-by in the
> respective patches upstream.
>
> BTW, another handy way to test if this works is via grub-mount.
Any chance we could have an updated grub2 package to fix this?
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr
Hi, Chris Hofstaedtler (2023-12-19): > If you can reasonably expect that the package in question will not > change name, or split out or move the systemd unit files in any > other way, than strictly from /lib to /usr/lib, then this is safe to > do now. That's very safe to assume, yes. If that's enough to guarantee that I won't actually be generating another problem down the line, I'm happy to implement this change. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
Carsten Schoenert (2023-12-15): > thank you very much for pointing me! > > I did play around a bit and was adding and testing the mentioned approach. > > https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e > > With these small modifications I can currently use the d-i on my X1 G11 > without further issues. A small exception, as the firmware-iwlwifi/testing > can't provide the required firmware files right now they need to get > provided on an additional inserted media. Great, thanks. Do you actual need to modprobe $module at that point? I thought the block right after that should modprobe -r/modprobe iwlwifi on its own? (But it wasn't sufficient before you starting unloading iwlmvm.) > I did also same small s/space/tab modifications with no code changes > afterwards in check-missing firmware.sh so the indentations are now unified > to use tabs again and fixing also a small typo. > > https://salsa.debian.org/tijuca/hw-detect/-/commit/2a3c045a72b4f31fc818b7f639daf5c08b7e2e5a > > If you are fine I can raise a MR for easy pulling in. Otherwise feel free to > comment on my changes. I know mixed stuff isn't too nice, and unifying might be appealing, but that makes cherry-picking stuff harder, so I tend to only unify things when I'm actually changing code… Others might feel differently. Well spotted, for the typo. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
Pascal Hambourg (2023-12-13):
> Wouldn't it be more generic to check /sys/module/${module}/holders
> like is done for mhi ?
I was suggesting a quick and dirty way to get away with this, to see if
it helps, answering the question regarding where in the code one might
want to try something.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
Carsten Schoenert (2023-12-13): > The "trick" is to unload the iwlmvm module instead and load afterwards > the module iwlwifi again. See the very bottom of check-missing-firmware.sh (hw-detect repository), the loop over $modules. You could try intercepting $module = iwlwifi, and adding a modprobe -r theotherone beforehand. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr
Hi, Chris Hofstaedtler (2023-12-08): > On Fri, Sep 08, 2023 at 11:25:24AM +0200, Helmut Grohne wrote: > > Are you fine with uploading this change at this early > > stage of the transition? > > Can we help you out in any way to get the systemd units moved? It's > not so "early stage" anymore and the systemd units can certainly > move now. I haven't been able to keep up with the state of this transition (having been busy with other topics that have been a blocker for it). If it's safe to move things around, I can handle that. At least that particular subject line from last week didn't seem encouraging: Subject: Pause /usr-merge moves See https://lists.debian.org/20231201210412.ga1344...@subdivi.de Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1056933: [Pkg-raspi-maintainers] Bug#1056933: raspi-firmware: CMA=0 not working as intended
Thorsten Glaser (2023-11-27): > It’s not. The file documents: > > # To disable CMA allocation entirely, f.e. for a headless setup, set > # CMA=0 Well, that's still the intent behind the commit that introduced support for that. And since that went into a stable release, I don't see how we could safely move away from CMA=0 means no cma= settings at all. > But CMA=0 in the file leads to no cma=0 on the kernel command line, > which makes the kernel use the default CMA allocation of 64 MiB. > > >Sounds like you want CMA=0M then? > > Perhaps, I just threw it here for now: > > $ cat /etc/default/raspi-extra-cmdline > TZ=:Europe/Berlin nofb nomodeset cma=0 If you don't want to verify a proposed solution to the needs you expressed, I suppose this bug report can be closed? -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1056933: [Pkg-raspi-maintainers] Bug#1056933: raspi-firmware: CMA=0 not working as intended
Thorsten Glaser (2023-11-26): > Package: raspi-firmware > Version: 1.20230405+ds-2 > > When I set CMA=0 the cma=… argument in cmdline.txt is omitted. This is consistent with the documentation in that file. > However, when I manually add cma=0 to cmdline.txt I get this instead: > > [0.00] Memory: 479104K/507904K available (8192K kernel code, 990K > rwdata > , 2024K rodata, 1024K init, 252K bss, 28800K reserved, 0K cma-reserved) Sounds like you want CMA=0M then? Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055107: crowdsec fails its autopkgtests on armel
Control: severity -1 important Cyril Brulebois (2023-10-31): > Nilesh Patra (2023-10-31): > > Since this means it is a flaky test and a recurring problem, would it > > make sense to skip those tests to save some cycles for debci? > > I didn't say I was certain, quite the opposite. > > > I had triggered it - we will see if it fixes itself. > > Looking at https://ci.debian.net/packages/c/crowdsec/testing/armel/ > it succeeded, 4 times in a row, within 2 minutes… Downgrading severity as this isn't actually blocking any packages. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1056697: 12.2 Installation Report, Complete Failure of Network
David Hillman (2023-11-25): > Thanks Cyril. This system is running Debian 12, so there is no > /var/log/syslog. As I mentioned in the original report, I found nothing > apparently related in the Journal. I'm confused. You filed an installation report regarding a failure to recognize network cards. I'm therefore assuming you're having issues with the installation process, and requesting /var/log/syslog, which is definitely where the installer logs what's going on. You also marked the overall install with E = Error… It'd make sense to clarify whether the problem affects the installer, and/or the installed system. Anyway, a copy of installer logs is available under /var/log/installer/ in the installed system. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1056697: 12.2 Installation Report, Complete Failure of Network
Lennart Sorensen (2023-11-25): > I suspect you are missing the firmware file for the network port. I think > this one: > > firmware-misc-nonfree: /lib/firmware/tigon/tg3.bin > > The installer probably does not include that. The netinst *definitely* does ship that package: https://cdimage.debian.org/cdimage/release/current/amd64/list-cd/debian-12.2.0-amd64-netinst.list.gz Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1056697: 12.2 Installation Report, Complete Failure of Network
Hi David, David Hillman (2023-11-24): > Thanks Holger. I could do that, but that would completely defeat the > purpose. I installed Debian 12 on this machine as a test, to confirm that > everything necessary works, before installing it on a dozen or so other > similar machines. > > And clearly, the opposite is the case, and it isn't ready for use yet, at > least, not on server hardware. I have D12 running on a laptop, and a few > virtual machines, and it doesn't suffer this problem, but I will apparently > have to stay with Ubuntu for a while on the servers. Extracting /var/log/syslog would be useful to understand what's going on there. A very quick search suggests this card might be supported by the tg3 module (drivers/net/ethernet/broadcom/tg3.c), which is definitely shipped in the installer. So maybe it's something that needs tweaking or fixing on the firmware side (e.g. “modprobe dance”), or a missing auxiliary bus (e.g. mhi) to make the card visible. Hard to tell without any logs. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
Scott Talbert (2023-11-16): > > Scott Talbert (2023-11-13): > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: binnmu > > > X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org > > > Control: affects -1 + src:libalien-wxwidgets-perl > > > > > > nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild > > > for wxwidgets3.2 (3.2.4+dfsg-1)" > > > > This looks like a redux of #1054146, with libwx-perl also needing a > > binNMU (after the libalien-wxwidgets-perl one)? > > Yeah, I did at least file both at the same time this round though :) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055908 I was trying to suggest filing both in the same request, to have them scheduled in one go. In any case, actually binNMUing both packages would be nice, as we've been lacking d-i daily builds for some days already. (I could probably try and do that myself but “above all, do no harm”.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1056169: bookworm-pu: package di-netboot-assistant/0.78~deb12u1
Hi Andreas, And thanks for keeping an eye on netboot-assistant. Andreas B. Mundt (2023-11-18): > +di-netboot-assistant (0.78~deb12u1) bookworm; urgency=medium > + > + * Fixes for bookworm live iso image inclusion. > + * Update/add/fix preseed examples. Thanks to Holger Wansing. > + > + -- Andreas B. Mundt Sun, 18 Jun 2023 09:11:47 +0200 > + > di-netboot-assistant (0.76) unstable; urgency=medium The versioning seems a little weird. Usually: - either one cherry-picks stuff on top of the stable package, and uses 0.76+deb12u1; - or one ships a rebuild of the testing/unstable into stable, and uses 0.78~deb12u1 (adding a changelog entry on top of unstable's, similarly to what would be done for backports). Glancing very briefly at the patch and the git tree, it seems like you're doing the latter but versioning it like the former. I'll let others comment as to whether that's some nitpicking that should be ignored, or something they'd like to see adjusted. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1056104: libreoffice: please enable ENABLE_WASM_STRIP_PINGUSER
Source: libreoffice Version: 1:7.0.4-4+deb11u7 Severity: normal Hi, LibreOffice features a prompt that pops up every now and then, asking users to get involved or to donate. I'm not sure asking repeatedly is reasonable, and it seems like ENABLE_WASM_STRIP_PINGUSER would be appropriate to turn that off. Implementation details can be found in SfxViewFrame::Notify(). Thanks for considering. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
Hi, Scott Talbert (2023-11-13): > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org > Control: affects -1 + src:libalien-wxwidgets-perl > > nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for > wxwidgets3.2 (3.2.4+dfsg-1)" This looks like a redux of #1054146, with libwx-perl also needing a binNMU (after the libalien-wxwidgets-perl one)? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1056018: partman-base: parted_devices hangs with process in D state during Debian installer Detect Disks step
Control: severity -1 important Hi, Olivier F. R. Dierick (2023-11-16): > Justification: breaks the whole system Not being able to install doesn't “break the whole system”. This is a showstopper in the installation process in your case indeed, but that's not what this severity is for. > Updating from Debian 8 to Debian 12 from an USB stick. Maybe check the image was correctly written on your USB stick? A number of weird issues like that one are linked to hardware faults or similar issues. >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Ineffective: Tried disconnecting external disks & USB storage HUB, and > switching SATA setting from AHCI to IDE in BIOS. > Also tried expert mode & text mode. > >* What was the outcome of this action? > > Debian Installer is stuck on Detect Disks. > Switching to a console and running ps shows that a parted_devices > process is in D state. Anything in dmesg or /var/log/syslog? It might be interesting to see what happens with 12.0 images (in case something interesting happened in the kernel, but such a hard failure seems rather strange), and maybe try your luck with some Debian Live image? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1037478: ca-certificates-java: Loop in the execution of the trigger
Hi, Matthias Klose (2023-07-12): > Version: 20230710 > > Fixed now. Thanks for the bugfix. This is a serious issue that still affects at least bookworm (I didn't check bullseye): applying the update published as DSA-5548-1 makes dpkg error out. Cc-ing the security team accordingly. On a bookworm system (freshly deployed and without any weird things done package-wise) that had openjdk-17-jre-headless installed, upgrading it to the version that's available in bullseye-security triggered the dpkg trigger loop. Thankfully that's easily recoverable (e.g. by running `dpkg --configure -a`, even if there might be better ways to do so), but that's still something I believe shouldn't be happening on stable systems with just the matching stable-security suite enabled. This issue is trivially reproducible there by switching back and forth between bookworm's version and bookworm-security's. Setting some debug level in dpkg, I'm getting the attached log for one of those runs. apt-get install -o dpkg::options::=-D7 openjdk-17-jre-headless/bookworm apt-get install -o dpkg::options::=-D7 openjdk-17-jre-headless/bookworm-security → ca-certificates-java-full-debug.txt At the time of writing, that means switching between 17.0.8+7-1~deb12u1 and 17.0.9+9-1~deb12u1. Checking whether this was possibly a problem with that particular system, I tried reproducing the issue with openjdk-17-jre-headless in a bookworm chroot, but I wasn't successful. Installing openjdk-17-jre makes it possible to reproduce the issue though. Shell script to reproduce (adjust DST=/tmp/bookworm if needed): → repro-1037478.sh I'm attaching the log for the failed upgrade, again with dpkg debug: → repro-1037478.log I've verified in both cases (real baremetal system and repro chroot) that installing ca-certificates-java 20230710 beforehand indeed makes the problem disappear. Since this release is a fixup for the previous release which was mainly aimed at fixing this particular issue, I suppose it would make sense to investigate whether something like 20230710~deb12u1 would be appropriate for bookworm-proposed-updates? (And maybe bullseye-proposed-updates, but again, I didn't check the bullseye part.) Thanks for considering. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ root@baremetal:~# apt-get install -o dpkg::options::=-D7 openjdk-17-jre-headless/bookworm-security … Selected version '17.0.9+9-1~deb12u1' for 'openjdk-17-jre-headless' … The following packages will be upgraded: openjdk-17-jre-headless 1 upgraded, 0 newly installed, 0 to remove and 284 not upgraded. Need to get 0 B/43.7 MB of archives. After this operation, 487 kB disk space will be freed. (Reading database ... 30411 files and directories currently installed.) Preparing to unpack .../openjdk-17-jre-headless_17.0.9+9-1~deb12u1_amd64.deb ... D02: trigproc_activate_packageprocessing pkg=openjdk-17-jre-headless:amd64 D02: post_script_tasks - ensure_diversions D02: post_script_tasks - trig_incorporate Unpacking openjdk-17-jre-headless:amd64 (17.0.9+9-1~deb12u1) over (17.0.8+7-1~deb12u1) ... D02: post_script_tasks - ensure_diversions D02: post_script_tasks - trig_incorporate D01: trigproc_run_deferred Setting up openjdk-17-jre-headless:amd64 (17.0.9+9-1~deb12u1) ... D02: trigproc_activate_packageprocessing pkg=openjdk-17-jre-headless:amd64 Installing new version of config file /etc/java-17-openjdk/security/public_suffix_list.dat ... D02: post_postinst_tasks - trig_incorporate D01: trigproc_run_deferred D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: trigproc ca-certificates-java:all D01: check_triggers_cycle pnow=ca-certificates-java:all D02: check_triggers_cycle pnow=ca-certificates-java:all first D01: trigproc ca-certificates-java:all D01: check_triggers_cycle pnow=ca-certificates-java:all D02: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java D02: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=/usr/lib/jvm D04: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=/usr/lib/jvm haretrig=/usr/lib/jvm D02: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java D04: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java haretrig=/usr/lib/jvm D04: tortoise_in_hare pnow=ca-certificates-java tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java haretr
Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
ilf (2023-11-15): > reopen 1055901 > found 1055901 1:1.20231024+ds-1+rpt2 > > This seems to hit everyone with a Rasperry Pi who upgraded > Debian/Raspian from bullseye to bookworm. If a Raspbian package doesn't work on Raspbian systems, is the Debian bug tracking system really the best place? Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
Hi, Hilmar Preusse (2023-11-13): > Package: raspi-firmware > Version: 1:1.20231024+ds-1+rpt1 > Severity: serious > Justification: Policy 6.4 > > Hello, > > the package fails to install on my system. I simply assumes that > /boot/firmware is a > mount point and fails if this is not the case. If /boot/firmware is expected > to be a > mount point the installer should have created it. The system was once > installed as > bullseye and later upgraded to bookworm. What exactly is your system? What is that rpt suffix? > Versions of packages raspi-firmware suggests: > ii bluez-firmware 1.2-9+rpt2 > ii firmware-brcm80211 1:20230210-5+rpt1 > ii firmware-misc-nonfree 1:20230210-5+rpt1 Here too. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055806: installation-reports: Installer doesn't recognize laptop's SSD, but calamares does
Hi Pascal, Please use reply-all… Pascal Hambourg (2023-11-11): > On 11/11/2023 à 21:43, Jessie wrote: > > > > However, when detecting disks, the only disk available for install > > was the usb drive I had the installer on - it did not detect the > > 256gb UFS SSD. > > It looks like UFS (Universal Flash Storage, not Unix filesystem) kernel > modules are not included in d-i initrd or udebs. Hi Jessie, and thanks for reporting. See <https://bugs.debian.org/1053937#15>, which I have yet to forward to kernel maintainers. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054437: golang-ariga-atlas: website is build with Docusaurus not packaged for debian
Hi Bastien, Bastien Roucariès (2023-10-23): > Source: golang-ariga-atlas > Version: 0.7.2-2 > Severity: serious > Tags: ftbfs > Justification: FTBFS This doesn't make any sense. > Control: block -1 by 1054426 > > Dear Maintainer, > > The documentation is build with docusaurus. > > See website directory > https://sources.debian.org/src/golang-ariga-atlas/0.7.2-2/doc/website/ > > You should repack or package docusaurus and rebuild You're filing a serious bug report claiming this is about a failure to build from source, then mention repacking, without describing any actual issues. Please be more considerate when filing serious bug reports. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054438: golang-entgo-ent: website is build with Docusaurus not packaged for debian
Bastien Roucariès (2023-10-23): > Source: golang-entgo-ent > Version: 0.11.3-4 > Severity: serious > Tags: ftbfs > Justification: FTBFS > Control: block -1 by 1054426 > > Dear Maintainer, > > The documentation is build with docusaurus. > > See website directory > https://sources.debian.org/data/main/g/golang-entgo-ent/0.11.3-4/doc/website > > You should repack or package docusaurus and rebuild That's bug report number 3 without any details… -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055269: udd: bugs.cgi does not show bugs for source packages in non-free-firmware
Lucas Nussbaum (2023-11-03): > UDD uses several independant "importers". The constraint you quoted is > in the "blends" importer (maintained by Andreas Tille, cced). ACK, I spotted a number of things that were blends-related, didn't realize that particular schema was too. > The reason why UDD thinks that #1055136 does not affect unstable, is > because the BTS thinks it does not affect unstable. If you look at the > version graph for the bug, you see that the BTS only knows about the > version in oldstable, not about the versions in stable/testing/unstable. > The same happens for other packages in non-free-firmware (see #1038610 > for example). https://github.com/dondelelcaro/debbugs/issues/2 then. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1055269: udd: bugs.cgi does not show bugs for source packages in non-free-firmware
Andreas Beckmann (2023-11-03):
> The list of RC bugs in sid
> https://udd.debian.org/bugs.cgi?release=sid=ign=7=7=1=id=desc=html#results
> does not contain e.g. #1055136 filed against src:nvidia-graphics-drivers
> which is in non-free-firmware, but it lists the clones of this bug that
> are assigned to various old driver series
> src:nvidia-graphics-drivers-{tesla,legacy}-* that are still in non-free
> (not in non-free-firmware).
>
> Interestingly the RC bug list for bullseye
> https://udd.debian.org/bugs.cgi?release=bullseye=ign=7=7=1=id=desc=html#results
> does list the bug. src:nvidia-graphics-drivers/bullseye is in non-free.
Indeed, udd doesn't seem to know about non-free-firmware at all, e.g.:
CONSTRAINT check_component CHECK ((component = ANY (ARRAY['main'::text,
'contrib'::text, 'non-free'::text])))
Things like udd/ftpnew_gatherer.py could almost work by accident since
that's using .startswith() (but then assigning "non-free" as value, so
that probably doesn't work anyway).
I'm afraid I'm not learning udd's codebase and configuration today.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#932491: python3-apt: segfault reading from lzma stream
Cyril Brulebois (2023-11-02):
> Today I had a few more minutes to spend on this, so here's a little
> debugging session. My main system is still bullseye, but the same tests
> in a bookworm chroots fail the same way.
“But maybe it's a bug in the lzma library?” one might ask.
Adding a bzip2 test between gzip and lzma leads to the following, again
on both bullseye and bookworm (after creating a Test.bz2/Packages.bz2
from one of the other files):
With bug-932491-aa.py (bug-932491-a.py + bzip2):
$ ./bug-932491-aa.py Test
gz == bz: True
gz == xz: True
gz: section 1 size: 29
gz: section 1 keys: ['Package', 'Desc']
gz: section 2 size: 47
gz: section 2 keys: ['Package', 'Desc']
Traceback (most recent call last):
File "/home/kibi/tmp/./bug-932491-c.py", line 37, in
tf_bz.step()
apt_pkg.Error: E:Unable to parse package file (1)
$ ./bug-932491-aa.py Packages
gz == bz: True
gz == xz: True
gz: section 1 size: 1281
gz: section 1 keys: ['Package', 'Version', 'Installed-Size', 'Maintainer',
'Architecture', 'Depends', 'Pre-Depends', 'Description', 'Homepage',
'Description-md5', 'Tag', 'Section', 'Priority', 'Filename', 'Size', 'MD5sum',
'SHA256']
gz: section 2 size: 585
gz: section 2 keys: ['Package', 'Version', 'Installed-Size', 'Maintainer',
'Architecture', 'Pre-Depends', 'Suggests', 'Description', 'Homepage',
'Description-md5', 'Tag', 'Section', 'Priority', 'Filename', 'Size', 'MD5sum',
'SHA256']
bz: section 1 size: 1410
Segmentation fault
With bug-932491-bb.py (bug-932491-b.py + bzip2):
$ ./bug-932491-bb.py Test
gz packages: 2
Traceback (most recent call last):
File "/home/kibi/tmp/./bug-932491-bb.py", line 26, in
for stanza in tf_bz:
apt_pkg.Error: E:Unable to parse package file (1)
$ ./bug-932491-bb.py Packages
gz packages: 50771
Traceback (most recent call last):
File "/home/kibi/tmp/./bug-932491-bb.py", line 27, in
bz_packages.append(stanza['Package'])
~~^^^
KeyError: 'Package'
It looks like we might be getting chunks of different sizes depending on
the underlying file objects, and some buffering/seeking code is buggy on
the apt_pkg side?
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
#!/usr/bin/python3
"""
Test case for #932491, version a+bz2
"""
import bz2
import gzip
import lzma
import sys
import apt_pkg
root = sys.argv[1]
# Check data decompression works fine:
with gzip.open(f'{root}.gz') as gz:
gz_text = gz.read()
with bz2.open(f'{root}.bz2') as bz:
bz_text = bz.read()
with lzma.open(f'{root}.xz') as xz:
xz_text = xz.read()
print(f'gz == bz: {gz_text == bz_text}')
print(f'gz == xz: {gz_text == xz_text}')
# Perform 2 manual steps with gz:
with gzip.open(f'{root}.gz') as gz:
tf_gz = apt_pkg.TagFile(gz)
tf_gz.step()
print(f'gz: section 1 size: {tf_gz.section.bytes()}')
print(f'gz: section 1 keys: {tf_gz.section.keys()}')
tf_gz.step()
print(f'gz: section 2 size: {tf_gz.section.bytes()}')
print(f'gz: section 2 keys: {tf_gz.section.keys()}')
# Perform 2 manual steps with bz:
with bz2.open(f'{root}.bz2') as bz:
tf_bz = apt_pkg.TagFile(bz)
tf_bz.step()
print(f'bz: section 1 size: {tf_bz.section.bytes()}')
print(f'bz: section 1 keys: {tf_bz.section.keys()}')
tf_bz.step()
print(f'bz: section 2 size: {tf_bz.section.bytes()}')
print(f'bz: section 2 keys: {tf_bz.section.keys()}')
# Perform 2 manual steps with xz:
with lzma.open(f'{root}.xz') as xz:
tf_xz = apt_pkg.TagFile(xz)
tf_xz.step()
print(f'xz: section 1 size: {tf_xz.section.bytes()}')
print(f'xz: section 1 keys: {tf_xz.section.keys()}')
tf_xz.step()
print(f'xz: section 2 size: {tf_xz.section.bytes()}')
print(f'xz: section 2 keys: {tf_xz.section.keys()}')
#!/usr/bin/python3
"""
Test case for #932491: version b+bz2
"""
import bz2
import gzip
import lzma
import sys
import apt_pkg
root = sys.argv[1]
# Start a loop:
gz_packages = []
with gzip.open(f'{root}.gz') as gz:
tf_gz = apt_pkg.TagFile(gz)
for stanza in tf_gz:
gz_packages.append(stanza['Package'])
print(f'gz packages: {len(gz_packages)}')
# Start a loop:
bz_packages = []
with bz2.open(f'{root}.bz2') as bz:
tf_bz = apt_pkg.TagFile(bz)
for stanza in tf_bz:
bz_packages.append(stanza['Package'])
print(f'bz packages: {len(bz_packages)}')
# Start a loop:
xz_packages = []
with lzma.open(f'{root}.xz') as xz:
tf_xz = apt_pkg.TagFile(xz)
for stanza in tf_xz:
print('.', end='')
xz_packages.append(stanza['Package'])
print()
print(f'xz packages: {len(xz_packages)}')
signature.asc
Description: PGP signature
Bug#932491: python3-apt: segfault reading from lzma stream
Control: severity -1 important
Hi,
David Bremner (2019-07-19):
> The following script segfaults if python3-apt is installed, but
> completes if not. Replacing lzma.open with open (and replacing
> Sources.xz with Sources) also makes the segfault go away. It seems to
> be the same with python3-apt 1.8.4. I didn't check the python2 version
> because lzma is (afaik) python3 only.
>
> #!/usr/bin/python3
> from debian.deb822 import Sources
> import lzma
>
> with lzma.open('Sources.xz', mode='rb') as f:
> for src in Sources.iter_paragraphs(f):
> package_name = src.get('Package')
> version = src.get('Version')
This isn't my first attempt at dealing with .xz files using python3-apt,
and I've never managed to get something to work without resorting to
temporary, uncompressed files…
Initial code was:
import gzip
with gzip.open('Packages.gz') as f:
tf = apt_pkg.TagFile(f)
for stanza in tf:
do_something_with(stanza)
which should be replaceable with the following given the documentation
of all relevant modules:
import lzma
with lzma.open('Packages.xz') as f:
tf = apt_pkg.TagFile(f)
for stanza in tf:
do_something_with(stanza)
Using lzma.LZMAFile(), toying with text vs. binary mode, encoding, bytes
flag, etc. didn't help…
Today I had a few more minutes to spend on this, so here's a little
debugging session. My main system is still bullseye, but the same tests
in a bookworm chroots fail the same way.
Depending on the input data, I'm seeing various expressions of the same
bug, some include a SIGSEGV, some don't.
Here's some sample data:
# Real files, SIGSEGV (archived suite == those files won't
# change over time, other indices would do just fine):
wget
http://archive.debian.org/debian/dists/stretch/main/binary-amd64/Packages.gz
wget
http://archive.debian.org/debian/dists/stretch/main/binary-amd64/Packages.xz
# Smaller stanzas, different errors
printf "Key1: Short1\nKey2: Short2\n\nKey3: SlightlyLonger1\nKey4:
SlightlyLonger2\n\n" > Test
gzip -k -f Test
xz -k -f Test
Trying to understand why the lzma case was failing, I tried digging into
apt_pkg.TagFile's internal data, leading to the bug-932491-a.py test
case you'll find attached.
Running it against the Test{.gz,.xz} pair gives:
$ ./bug-932491-a.py Test
gz == xz: True
gz: section 1 size: 26
gz: section 1 keys: ['Key1', 'Key2']
gz: section 2 size: 44
gz: section 2 keys: ['Key3', 'Key4']
Traceback (most recent call last):
File "/path/to/bug-932491-a.py", line 33, in
tf_xz.step()
apt_pkg.Error: E:Unable to parse package file (1)
Running it against the Packages{.gz,.xz} pair gives:
$ ./bug-932491-a.py Packages
gz == xz: True
gz: section 1 size: 1281
gz: section 1 keys: ['Package', 'Version', 'Installed-Size', 'Maintainer',
'Architecture', 'Depends', 'Pre-Depends', 'Description', 'Homepage',
'Description-md5', 'Tag', 'Section', 'Priority', 'Filename', 'Size', 'MD5sum',
'SHA256']
gz: section 2 size: 585
gz: section 2 keys: ['Package', 'Version', 'Installed-Size', 'Maintainer',
'Architecture', 'Pre-Depends', 'Suggests', 'Description', 'Homepage',
'Description-md5', 'Tag', 'Section', 'Priority', 'Filename', 'Size', 'MD5sum',
'SHA256']
xz: section 1 size: 163530
Segmentation fault
See how crazy the size of the first section is…
The stacktrace can be huge, and this should be easily reproducible so
I'm not attaching anything else, but here's where things explode:
Program received signal SIGSEGV, Segmentation fault.
TagSecKeys (Self=,
Args=Args@entry=()) at python/tag.cc:284
284 Py_DECREF(Obj);
(gdb) l
279 const char *End = Start;
280 for (; End < Stop && *End != ':'; End++);
281
282 PyObject *Obj;
283 PyList_Append(List,Obj =
PyString_FromStringAndSize(Start,End-Start));
284 Py_DECREF(Obj);
285}
286return List;
287 }
288
(gdb) p List
$1 = []
(gdb) p Obj
$2 = 0x0
I was mentioning different expressions… Let's see what happens with the
approach I was starting from, using a for loop on the TagFile object,
against the Packages{.gz,.xz} pair again. The bug-932491-b.py test case
implements a demo using gzip then lzma, printing a dot for each
iteration, showing that the lzma problem shows up on the very first
iteration:
$ ./bin/bug-932491-b.py Packages
gz packages: 50771
.Traceback (most recent call last):
File "/path/to/bug-932491-b.py", line 27, in
xz_packages.append(stanza['Package'])
~~^^^
KeyError: 'Package'
Since we're only getting xz files for some suites already, it would be
best if they would be manageable through python3-apt…
Cheers,
--
Cyril Brulebois (k...@de
Bug#1055107: crowdsec fails its autopkgtests on armel
Nilesh Patra (2023-10-31): > Since this means it is a flaky test and a recurring problem, would it > make sense to skip those tests to save some cycles for debci? I didn't say I was certain, quite the opposite. > I had triggered it - we will see if it fixes itself. Looking at https://ci.debian.net/packages/c/crowdsec/testing/armel/ it succeeded, 4 times in a row, within 2 minutes… Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055107: crowdsec fails its autopkgtests on armel
Hi, Nilesh Patra (2023-10-31): > On Tue, 31 Oct 2023 20:13:23 +0530 Nilesh Patra wrote: > Full log at: > https://ci.debian.net/data/autopkgtest/testing/armel/c/crowdsec/39385596/log.gz > > > This is currently blocking golang-github-gin-gonic-gin to testing which > > fixes a bunch of RC bugs (of same kind). I think we've had this issue showing up in a few cases (on other archs though), but I wasn't able to replicate it, possibly timing issues or something similar. I'd suggest a retry if that wasn't attempted already. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055084: [Pkg-raspi-maintainers] Bug#1055084: raspi-firmware: Raspberry Pi 4 fails to boot 6.1.0-13-arm64 reliably (detects /dev/mmcblk0 instead of mmcblk1)
Hi Lucas, Lucas Nussbaum (2023-10-31): > After upgrading my RPI4 to bookworm, it no longer boots reliably. > Sometimes the SD card gets detected as mmcblk0, sometimes as mmcblk1, > causing the initramfs to fail to find the root filesystem. > > Going back to the bullseye kernel (5.10.0-26-arm64) makes it boot > reliably, detecting the SD card as mmcblk1. Using label-based booting makes this issue go away: https://salsa.debian.org/raspi-team/image-specs/-/commit/f89f71560d2ca1bd60d97dbb26b89782657d56ae Before this commit, the first few boots would happen with a label-based booting, but that would go away as soon as the raspi-firmware hook would run, leaving you to get either mmcblk0 or mmcblk1 at boot-up. I only observed that on the Pi 4 family (Pi 4 and Compute Module 4), and I'm not sure this is directly linked to the Linux version. (I've had a lot of back and forth due to heavy debugging so I don't recall coming to a conclusion for that one except “use labels, always”.) Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055016: override: tasksel-data:admin/optional
Daniel Lewart (2023-10-29): > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: override > X-Debbugs-Cc: task...@packages.debian.org, debian-b...@lists.debian.org, > 855...@bugs.debian.org, 954...@bugs.debian.org > Control: affects -1 + src:tasksel > > FTP Team, > > #855151 - tasksel: should not be Priority: important > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855151 > > #954090 - override: tasksel:admin/optional > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954090 > > However, tasksel is still installed by default because of the following: > $ apt-cache show tasksel-data | grep -E '^(Package|Depends|Priority)' > Package: tasksel-data > Depends: tasksel (= 3.73) > Priority: important > > Please change tasksel-data from: > admin/important > to: > admin/optional It's probably safe since pkgsel's postinst features: if db_get pkgsel/run_tasksel && [ "$RET" = true ]; then log "starting tasksel" db_progress INFO pkgsel/progress/tasksel apt-install tasksel # ensure tasksel is installed Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
Luca Boccassi (2023-10-28): > If you still have some time to spare by any chance, I think this will > be needed soon: > > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/39 > > If everything goes according to plans, next week there will be udev > v255-rc1, which I will upload to unstable to get more coverage before > the release - and it will no longer support legacy paths/layouts, which > I think will affect the daily d-i builds. Yes, that's the next topic on my list, as shared with Helmut a couple weeks ago and confirmed earlier today. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2
Simon McVittie (2023-10-28): > I believe dpkg-source defaults to the equivalent of `dpkg-source -I` > for 3.0 (native) format packages, which ignores some files that would > normally appear in git, notably .gitignore. > > I normally use > DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I.*.sw? -I.sw? -I.git" which > disables the default `-I` and instead excludes .git but not .gitignore, > making the uploaded source package exactly equivalent to what's in git > (and as a result, more dgit-friendly). Alright, that explains it then. > If you would prefer any subsequent uploads of d-i-related components > to always exclude the .gitignore, I'll try to remember that for the > future. Until 3.0 (git) was used everywhere, it was very customary to have some differences in successive uploads, depending on who was uploading, and whether -i/-I was used; it's not a huge deal, and only means a little noise when reviewing diffs. Whatever is fine with SRMs is fine with me. (It just happened to surprise me a little when I compared a local source build with what was uploaded and is available on coccia, since I built from my local repo as usual instead of thinking about downloading your source packages from the get-go.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
Cyril Brulebois (2023-10-15): > Simon McVittie (2023-10-15): > > I have attempted to test the proposed version in d-i. I am not an > > expert on d-i, but I hope what I have done here is approximately > > correct: > […] > > I hope this is helpful information. > > That's decent testing, yes, thanks. > > The pu/opu review on my side should be happening in a couple of days > anyway. Test results look good to me too, feel free to go ahead. (With the same unimportant proviso about debian/.gitignore) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2
Hi, Simon McVittie (2023-08-31): > [ Reason ] > The same changes proposed for bookworm in #1050868, but for bullseye. > Because official buildds that build trixie/sid are not yet all running > bookworm, we'll need this change in bullseye too. > > I also included the changes that Luca previously proposed on this bug, > which are backports from bookworm's debootstrap: > > - no longer including usrmerge and its dependencies in the installed > system if usr-is-merged would be sufficient, saving ~ 50MB on a minbase > image and effectively fixing a regression caused by making > usrmerge|usr-is-merged transitively Essential in bookworm (#1025657) > - enabling merged-/usr on Hurd > > These are technically a behaviour change for bullseye, but we're making > a larger behaviour change here already, and it aligns the behaviour > with what we have in bookworm. We could revert those if required, but > they're really small changes and seem desirable to me: in particular, > they make the whole merged-/usr code path into the same tested code > that's in trixie and proposed for bookworm. Test results look good to me too, feel free to go ahead. Compared to what I get from a `dpkg-buildpackage -S` run locally (using the bullseye branch at tag debian/1.0.123+deb11u2), the source package available on coccia adds the debian/.gitignore file; this is merely intriguing and not something that should block processing this upload, possibly linked to dgit's having been used at some point? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1040138: changelog-file-missing-explicit-entry needs exception for bookworm
Marc Haber (2023-10-09): > On Mon, Oct 09, 2023 at 02:06:58AM +0200, Cyril Brulebois wrote: > > That exception only hides the root of the bug, which includes (at > > least) a messed up version sorting. > > What is the recommended way to get rid of this? Re-sorting > changelog entries? Adding an override? On the lintian user side: Ignoring silly results works for me. On the lintian developer side: Fixing whatever produces the weird and of course incorrect ordering that's then expected and complained about. > > Adding another exception for bookworm will only lead to more > > whack-a-mole down the line (see #1051140). > > I don't see the connection here. Adding an exception hides the bug. Then it's going to appear again when the next suite is around the corner, until an exception is added again, etc. That doesn't seem like a good idea to me. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054444: golang-github-facebook-ent: website is build with Docusaurus not packaged for debian
Hi Bastien, Bastien Roucariès (2023-10-23): > Source: golang-github-facebook-ent > Version: 0.5.4-3 > Severity: serious > Tags: ftbfs > Justification: FTBFS > Control: block -1 by 1054426 > > Dear Maintainer, > > The documentation is build with docusaurus. > > See website directory > https://sources.debian.org/src/golang-github-facebook-ent/0.5.4-3/doc/website/ > > You should repack or package docusaurus and rebuild Please describe the actual problem you're seeing. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2
Scott Talbert (2023-10-18): > Indeed, libwx-perl has to be binMNU'd next. Was waiting for the s390x build > of libalien-wxwidgets-perl, but went ahead and submitted the binNMU request > for libwx-perl anyway so we can get other arches fixed. It would make sense to mention both packages from the get-go, we have dep-waits to ensure one finishes before the other one starts? > PS, what on the d-i uses libwx-perl? The unifont-bin build-dep pulls it. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2
Scott Talbert (2023-10-17): > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org > Control: affects -1 + src:libalien-wxwidgets-perl > > nmu libalien-wxwidgets-perl_0.69+dfsg-6+b2 . ANY . unstable . -m "Rebuild > against libwxgtk3.2-dev 3.2.3+dfsg-1" While libalien-wxwidgets-perl shows up on the auto-upperlimit-libwxgtk3.2-dev tracker, libwx-perl doesn't and this binNMU broke libwx-perl's installability, also breaking d-i builds. Package: libalien-wxwidgets-perl Provides: wxperl-gtk-3-2-3-uni-gcc-3-4 Package: libwx-perl Depends: […], wxperl-gtk-3-2-2-uni-gcc-3-4, […] Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1053937: debian-installer: installer does not detect internal UFS-drive
Hi Patrick, and thanks for your report. Patrick Rudin (2023-10-14): > I have a Microsoft Surface Go 4 Tablet, which has an internal 256 GB > UFS-Drive. > Debian Live works fine, but its not possible to install Debian: When I get to > partitioning, the installer does not see the drive (the ubuntu installer does) > and only shows my installer-stick. > > I guess the installer would need the ufshci-module to recognize the internal > UFS-Flash. Looking around, it seems “ufshci-module” is a best guess name for what the industry calls UFSHCI, and seems to be shipped as ufshcd-core.ko (ufs/core) and ufshcd-pci.ko (ufs/host). Those are likely to be sufficient as the only dependency is between them (no extra modules should be needed), and I can load both of them in a test VM. But we've already seen that sometimes another seemingly unrelated module might be needed (I did spot a softdep on a governor, so I'm not sure about the runtime when such a device is present). I've built a test netboot-gtk installation image; contrary to a full netinst ISO, there's no firmware in there, but I thought it might be good enough for you to test and report whether the storage appears, without going through the whole installation process. https://people.debian.org/~kibi/bug-1053937/ Your follow-up about Live was very nice as well. Hopefully that fits your immediate needs and lets you install Debian without waiting on a fix in debian-installer; a full netinst ISO could be arranged otherwise. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
Hi, Simon McVittie (2023-10-15): > I have attempted to test the proposed version in d-i. I am not an > expert on d-i, but I hope what I have done here is approximately > correct: […] > I hope this is helpful information. That's decent testing, yes, thanks. The pu/opu review on my side should be happening in a couple of days anyway. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1040138: changelog-file-missing-explicit-entry needs exception for bookworm
Marc Haber (2023-07-01): > this is the bookworm edition of #1001651 which got fixed by adding an > exception, judging from the changelog entry of lintian 2.115.0. That exception only hides the root of the bug, which includes (at least) a messed up version sorting. Adding another exception for bookworm will only lead to more whack-a-mole down the line (see #1051140). > This issue happens again when preparing a successive upload to bookworm. > I have aide 0.18.3-1, 0.18.3-1+deb12u1 and 0.18.3-1+deb12u2, the deb12u2 > gets this lintian tag. > > See https://salsa.debian.org/debian/aide/-/blob/bookworm/debian/changelog Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1051140: Bug #1051140: lintian in bookworm does not know about bookworm-backports
Control: retitle -1 lintian in bookworm does not know about any bookworm* suites Lee Garrett (2023-09-03): > Indeed, however the bug is about fixing it in stable. Yes please; adjusting the title to reflect the fact it's not limited to the backports suite for bookworm. For example: E: package-goes-here changes: bad-distribution-in-changes-file bookworm It would be great if lintian could get distribution names once they're announced. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1021341: autopkgtest-build-qemu: add dependency on zerofree
Control: retitle -1 vmdb2: missing dependency on zerofree Control: found -1 0.27+really.0.26-1 Control: severity -1 serious Cc += Emanuele, Christian. Michael Tokarev (2023-09-17): > Please do not add dependency on zerofree. > > Instead, pleas DROP zerofree usage entirely in todays world. > > It gave me multiple headaches already. > > First I tried to experiment with autopkgtest (which uses vmdb2) > on a tmpfs. It all went fine until vmdb2 decided to helpfully > zerofree the image, - which expanded it to whole RAM and immediately > caused an OOM. I had to clean up from this for quite some time. > > Another case is an SSD which gets filled with zeros, having to > allocate else unused blocks in the image file. > > And yet another - on a regular rotating HDD, it has to turn a > sparse file into complete file, - in a typical autopkgtest-build-qemu > use case this means writing 25Gb of data, it is insanely slow. > > If anything, one can use fstrim to achieve the desired result. > > Thanks! Please file a separate bug report instead of hijacking that one. Bumping severity to serious because getting autopkgtest-build-qemu to work is much harder than it should be (as evidenced by recurring conversations on #debian-devel at least), and getting avoidable errors doesn't help. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1051884: bullseye-pu: package openssl/1.1.1w-0~deb11u1
Adam D. Barratt (2023-10-02): > Unfortunately, the version format change from -0+deb11uX to -0~deb11uX > has broken the installer. > > The udebs end up with dependencies of the form ">= 1.1.1w", which > 1.1.1w-0~deb11u1 doesn't fulfil. Assuming I'm not missing anything, > could we have an upload that uses the -0+ style of versioning ASAP, > please? Trying to understand the reasons behind the versioning scheme switch, it seems the debian/bullseye branch is still at 1.1.1v-0~deb11u1 (without a tag). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1051884: bullseye-pu: package openssl/1.1.1w-0~deb11u1
Hi, Sebastian Andrzej Siewior (2023-09-13): > Package: release.debian.org > Control: affects -1 + src:openssl > User: release.debian@packages.debian.org > Usertags: pu > Tags: bullseye > Severity: normal > > OpenSSL upstream released 1.1.1w which the last stable update to the > 1.1.1 series because it is EOL since last Monday. > The update is fairly small and contains a few fixes for memory leaks. > The mentioned CVE affects only Windows. The updated libssl1.1-udeb cannot be installed: $ dpkg --info binary-libssl1.1-udeb/libssl1.1-udeb_1.1.1w-0~deb11u1_amd64.udeb | grep Depends Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1w) versus: libcrypto1.1-udeb | 1.1.1w-0~deb11u1 | oldstable-proposed-updates | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x which leads to: The following packages have unmet dependencies: libssl1.1-udeb : Depends: libcrypto1.1-udeb (>= 1.1.1w) but 1.1.1w-0~deb11u1 is to be installed Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
Hi, Hoping that a short answer is better than no answer… I'll expand later. Luca Boccassi (2023-09-23): > Release Team, we are aware that you requested an explicit review from > D-I for this and #1025708, however there are no available reviewers, > so it appears we are deadlocked. Would you please consider waiving > this requirement to break the deadlock? That's not reasonable, no. > Philip Hands has confirmed on Salsa that the change has been tested > with OpenQA and everything still works: > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/105#note_429838 Even without Philip's clarification regarding what has been tested and what hasn't, that machinery clearly doesn't test what happens with a release d-i build. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1051120: debian-installer: can't use YubiKey for secure drive encryption passphrase because enter clears form
Hi, Jonathan Kamens (2023-09-02): > The Debian installer, however, *erases the contents of the first > passphrase field* when the YubiKey sends the Enter. I'm assuming the main problem is that Enter moves to the next screen, you would have to send passphrase + instead of passphrase + to have a desired effect in the graphical installer. Try the text-based installer instead, password and passphrase confirmations happen on two separate screens? > TLDR The Enter key should not clear the passphrase field that has > already been entered. I realize this makes your life harder, but I don't think it would be reasonable to change what Enter does at this point. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
