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
Bug#1050523: dh-make-golang: fails to determine dependencies
Hi, Daniel Swarbrick (2023-08-25): > On 25.08.23 19:40, Mathias Gibbens wrote: > >Something has changed in sid's golang environment since August 4 > > which is causing dh-make-golang to fail to determine a package's > > dependencies and generate a correct d/control. For example, this worked > > fine on August 4 but now fails: > > It's probably also worth noting that dh-make-golang is now FTBFS (#1043070) > due to golang.org/x/tools/go/vcs having been deprecated and removed from > golang-golang-x-tools-dev as of version 0.11.0. I had an unstable schroot lagging behind. Upgrading the following packages didn't change dh-make-golang's output regarding dependencies: $ sudo apt-get install golang-golang-x-tools-dev […] The following additional packages will be installed: golang-golang-x-mod-dev golang-golang-x-tools The following packages will be upgraded: golang-golang-x-mod-dev golang-golang-x-tools golang-golang-x-tools-dev But this did: $ sudo apt-get install golang […] The following additional packages will be installed: golang-1.21 golang-1.21-doc golang-1.21-go golang-1.21-src golang-any golang-doc golang-go golang-src The following NEW packages will be installed: golang golang-1.21 golang-1.21-doc golang-1.21-go golang-1.21-src The following packages will be upgraded: golang-any golang-doc golang-go golang-src 4 upgraded, 5 newly installed, 0 to remove and 355 not upgraded. Given the error messages it looks like there are only two paths considered each time, one within the build tree, the other one being under /usr/lib/go-1.21; and since many packages (a very superficial search suggests 2048) ship stuff under /usr/share/gocode/src, that can't work? Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1050675: www.debian.org: French bookworm d-i web page jumped the shark
Package: www.debian.org Severity: important Tags: l10n X-Debbugs-Cc: debian-l10n-fre...@lists.debian.org Hi, https://www.debian.org/releases/bookworm/debian-installer/index.fr.html has an interesting view about the state of the Debian releases, claiming Debian 12 has been overthrown by Debian 13, and recommending to install Trixie instead. Other translations look good to me, so I don't think this is a general problem with a macro, but something really bad at the individual translation level. I haven't investigated the wml source though; French team in copy. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1050343: [Pkg-puppet-devel] Bug#1050343: puppetserver: confusing state of systemd units after upgrading from puppet-master
Thomas Goirand (2023-08-24): > Not only Java, but Clojure too (which uses the JVM). It was kind of a > nightmare to package, if you didn't know: dozens of weirdo clojure, > java and Ruby dependencies to package (I suppose you saw the > dependency chain when installing?). I fixed a number of Clojure packages to get puppetdb back into buster right before the relevant stage of the freeze, so believe me: I had some front row seat (and still remember bits of it, like leiningen). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050340: [Pkg-puppet-devel] Bug#1050340: puppetserver: incompatibility with system hiera-eyaml
Antoine Beaupré (2023-08-23): > Oh i meant the upstream version, the package in Debian is obviously out > of date here. :) Sure, I meant I would have tried (package relationship permitting) a newer package if there was one available. > Same here, I was just curious if you thought the manual gem update fixed > this because it's a new upstream or just because "some gem thing". “Yes.” ;p Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050340: [Pkg-puppet-devel] Bug#1050340: puppetserver: incompatibility with system hiera-eyaml
Antoine Beaupré (2023-08-23): > Do you think this is a version problem, in other words would it be > sufficient to upgrade the hiera-eyaml package to 3.4.0? That thought crossed my mind, but seeing the same version everywhere in rmadison's output, I considered I would stop there. Gut feelings: - maybe there's a version mismatch; - maybe there's some search path problem (e.g. only/mostly looking into some vendorized libraries, but then it really should have vendorized that particular one). I'm happy to test a newer version once you have a tentative package. I'm not sure I can reasonably commit to trying and preparing the update myself. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050337: [Pkg-puppet-devel] Bug#1050337: puppetserver: missing Recommends on puppet-module-puppetlabs-mailalias-core
Hello, Antoine Beaupré (2023-08-23): > There's a ton of modules like this, cron is another we had to install by > hand here. It seems like a good idea to add them to Recommends! > > Here's the deprecation notice: > > https://www.puppet.com/docs/puppet/6/release_notes_puppet#new_features_puppet_x-0-0-select-moved-modules-types > > And that's the actual module list: > > https://www.puppet.com/docs/puppet/6/type#supported-type-modules-in-puppet-agent > > It seems like `cron` and `mailalias` are supported differently and cron > actually *should* have shipped with the agent. But that's kinf of a > cosmetic distinction, maybe it could be the difference between > Recommends and Suggests in our case? I would also "recommend" (no pun > intended) to *not* include any sort of dependency against the > "Deprecated types" (e.g. Nagios). What do you think? I have absolutely no idea where to draw the line. It just kind of baffled me to see such a basic feature dropped entirely. Maybe others would have the same feeling towards Nagios stuff as I have for mailalias? > In our case (for cron), we decided to move away from the module > altogether, towards systemd timers: > > https://gitlab.torproject.org/tpo/tpa/team/-/issues/41303 Regarding some things getting shipped via the agent, that was spotted by Evgeni as well, but I'm not diving into the “let's learn more about the (current) architecture of puppet to see what happens” rabbit hole. Yes, that means not knowing what's supposed to happen with an old puppet agent that (presumably) doesn't know about those things vs. a new puppet whose core dropped support for them… But I don't think I'll lose sleep over that. ;) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1050343: puppetserver: confusing state of systemd units after upgrading from puppet-master
Package: puppetserver Version: 7.9.5-2 Severity: important Hi, After a bullseye to bookworm upgrade, my system was left in a weird state; since that's a rather old system, which went through a lot of upgrades, I've checked that I could reproduce the following in a fresh bullseye VM, installing puppet-master, then dist-upgrading to bookworm: that's indeed the case. Initially (on bullseye), we have a proper puppet-master systemd unit. After the upgrade, there's still one, but that's using the LSB generator, possibly because puppet-master is still installed, and its (unchanged) /etc/init.d/puppet-master script is picked up by systemd and its systemd-sysv-generator. That unit of course fails as it tries to run `puppet master` and that subcommand is gone. Workaround: systemctl disable --now puppet-master systemctl reset-failed puppet-master Meanwhile, a puppetserver.service unit has been deployed, with `systemctl status` reporting it disabled even though the preset is enabled. Workaround: systemctl enable --now puppetservice I was really surprised by the startup time, until I discovered the server is now Java-based, hence 30 seconds to start. The increase in memory footprint is also very noticeable. I might follow up here with a configuration tweak in case it's useful to other users migrating from the good old built-in server that nobody was supposed to run but that worked so well for a number of use cases… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1050340: puppetserver: incompatibility with system hiera-eyaml
Package: puppetserver
Version: 7.9.5-2
Severity: important
Hi,
I totally lost hiera eyaml support while upgrading from bullseye to
bookworm. Neither the old hiera configuration file or the new one
worked. Given the upstream upgrade path, I totally understand that
there's little puppet packagers can do to ease the pain…
https://www.puppet.com/docs/puppet/7/hiera_migrate#hiera_migrate
Just in case it helps others, here's what I ended up using, which
lets me use nodes/*.eyaml files:
,---[ /etc/puppet/hiera.yaml ]---
| ---
| # Hiera 5 Global configuration file
|
| version: 5
|
| defaults:
| data_hash: yaml_data
| datadir: code/hiera
|
| hierarchy:
| - name: "Per-node data"
| paths:
| - "nodes/%{trusted.certname}.yaml"
| - "common.yaml"
|
| - name: "Per-node data (encrypted)"
| path: "nodes/%{trusted.certname}.eyaml"
| lookup_key: eyaml_lookup_key
| options:
| pkcs7_private_key: /var/lib/puppet/keys/private_key.pkcs7.pem
| pkcs7_public_key: /var/lib/puppet/keys/public_key.pkcs7.pem
`---
But now I'm facing a bigger issue, which is that any use of hiera
triggers this error, and dozens of log lines:
Lookup using eyaml lookup_key function is only supported when the
hiera_eyaml library is present
I'm attaching a log excerpt with a trace.
Since I didn't want to keep a broken puppet {master,server} for too
long, I bit the bullet and tried installing the gem, which worked around
the immediate problem:
puppetserver gem install hiera-eyaml
But it'd be great if that problem could be debugged and a proper
solution found, only using Debian packages… This is a rather small
setup, changes don't happen very often, there's nothing really
mission-critical, so I can happily assist debugging/running tests
if instructed.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
2023-08-19T19:10:39.064+02:00 ERROR [qtp614050581-42] [puppetserver] Puppet
Evaluation Error: Error while evaluating a Function Call, Function Load Error
for function 'eyaml_lookup_key': Lookup using eyaml lookup_key function is only
supported when the hiera_eyaml library is present (file:
/etc/puppet/code/environments/production/manifests/site.pp, line: 114, column:
5) on node redacted.example.org
/usr/lib/ruby/vendor_ruby/puppet/functions.rb:193:in `create_function'
/usr/lib/ruby/vendor_ruby/puppet/functions/eyaml_lookup_key.rb:7:in `create'
org/jruby/RubyKernel.java:1091:in `eval'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/ruby_function_instantiator.rb:22:in
`create'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/module_loaders.rb:284:in
`instantiate'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/module_loaders.rb:277:in `find'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:173:in
`internal_load'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:43:in `block in
load_typed'
/usr/lib/ruby/vendor_ruby/puppet/concurrent/lock.rb:10:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/loader.rb:153:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:41:in `load_typed'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:165:in
`internal_load'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:43:in `block in
load_typed'
/usr/lib/ruby/vendor_ruby/puppet/concurrent/lock.rb:10:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/loader.rb:153:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:41:in `load_typed'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:165:in
`internal_load'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:43:in `block in
load_typed'
/usr/lib/ruby/vendor_ruby/puppet/concurrent/lock.rb:10:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/loader.rb:153:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:41:in `load_typed'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:165:in
`internal_load'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:43:in `block in
load_typed'
/usr/lib/ruby/vendor_ruby/puppet/concurrent/lock.rb:10:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/loader.rb:153:in `synchronize'
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:41:in `load_typed'
/usr/lib/ruby/vendor_ruby/puppet/pops/lookup/function_provider.rb:91:in
`load_function'
/usr/lib/ruby/vendor_ruby/puppet/pops/lookup/function_provider.rb:79:in
`function'
/usr/lib/ruby/vendor_ruby/puppet/pops/lookup/function_provider.rb:37:in
`create_function_context'
/usr/lib/ruby/vendor_ruby/puppet/pops/lookup/function_provider.rb:33:in
`function_context'
/usr/lib/ruby/vendor_ruby/puppet/pops/lookup/lookup_key_function_provider.rb:48:in
`lookup_key'
/usr/lib/ruby/vendor_ruby/puppet/pops/lookup/lookup_key_function_provider
Bug#1050338: puppetserver: missing Recommends on puppet-module-puppetlabs-mailalias-core
Package: puppetserver
Version: 7.9.5-2
Severity: important
Hi,
One of the problems that showed up while upgrading my puppet
{master,server} from bullseye to bookworm was losing support for the
mailalias resource. Some basic research led to discovering it's been
split away from the core and moved to a module. One `puppet module
install` call later, that problem went away.
Evgeni Golov kindly pointed out that we have a package for that module,
and given the list of Recommends in puppetserver, it looks like it
could and should have been there, so possibly just an oversight and not
a deliberate decision?
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Bug#1050337: puppetserver: missing Recommends on puppet-module-puppetlabs-mailalias-core
Package: puppetserver
Version: 7.9.5-2
Severity: important
Hi,
One of the problems that showed up while upgrading my puppet
{master,server} from bullseye to bookworm was losing support for the
mailalias resource. Some basic research led to discovering it's been
split away from the core and moved to a module. One `puppet module
install` later, that problem went away.
Evgeni Golov kindly pointed out that we have a package for that module,
and given the list of Recommends in puppetserver, it looks like it
could and should have been there, so possibly just an oversight and not
a deliberate decision?
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Bug#1050336: libnet-xmpp-perl: unable to StartTLS, without any feedback
Package: libnet-xmpp-perl
Version: 1.05-1.1
Severity: serious
Justification: cannot perform basic authentication
Hi,
I have a few scripts around that use Net::XMPP to send notifications
when this or that happens, and all of them broke after upgrading from
bullseye to bookworm. This is definitely not related to changes on the
server side (which I control and didn't change), and other existing
hosts still on bullseye still work fine.
The error manifests itself like this:
AuthIQAuth requires a resource arguement at /local/wrapper.pm line 42.
Tracking it down, it appears AuthSend uses AuthSASL on bullseye (OK)
and AuthIQAuth on bookworm (KO). The latter is the fallback:
,---[ Net/XMPP/Protocol.pm ]---
| sub AuthSend
| {
[…]
| if($self->{STREAM}->GetStreamFeature($self->GetStreamID(),"xmpp-sasl"))
| {
| return $self->AuthSASL(%args);
| }
| return $self->AuthIQAuth(%args);
| }
`---
The GetStreamID isn't happy because it tries to pick the ID part of the
SESSION, which is missing.
Diving into the connection implementation, I managed to confirm that the
connection is established at first, giving me a $self->{SESSION} set,
but that goes away later on:
,---[ Net/XMPP/Connection.pm ]---
| sub Connect
| {
| if ($self->{SESSION})
| {
| $self->{DEBUG}->Log1("Connect: connection made");
|
| my $weak = $self;
| weaken $weak;
| $self->{STREAM}->SetCallBacks(node=>sub{ $weak->CallBack(@_) });
| $self->{CONNECTED} = 1;
| $self->{RECONNECTING} = 0;
|
| if (exists($self->{SESSION}->{version}) &&
| ($self->{SESSION}->{version} ne ""))
| {
| my $tls = $self->GetStreamFeature("xmpp-tls");
| if (defined($tls) && $self->{SERVER}->{tls})
| {
| $self->{SESSION} =
| $self->{STREAM}->StartTLS(
| $self->{SESSION}->{id},
| $self->{SERVER}->{timeout},
| );
Here be dragons.
| }
| elsif (defined($tls) && ($tls eq "required"))
| {
| $self->SetErrorCode("The server requires us to use TLS, but
you did not specify that\nTLS was an option.");
| return;
| }
| }
|
| return 1;
| }
| else
| {
| $self->SetErrorCode($self->{STREAM}->GetErrorCode());
| return;
| }
`---
I also confirmed (yay for print-debugging) that the xmpp-tls branch is
entered, the StartTLS() fails for some reason (or at least returns
nothing at all), and $self->{SESSION} gets reset. The rest explodes.
There are only minor differences between the package in bullseye and
bookworm (mostly packaging metadata), so it looks to me something
external (undetermined at the moment) triggered this problem during
the upgrade. I thought I'd file my findings then think a little more
about a game plan.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Bug#1050316: apt-setup: Unable to use local repo when installing older release
Hi Stephen, Stephen Gelman (2023-08-22): > I understand that the current release is the main priority of d-i but > given the fix seems to be low risk it would be appreciated if it could > be fixed in stable! Thanks for filing as suggested on IRC. Given the conditions (oldstable as anticipated, but also: local repository), I'd tend to agree with the “normal” severity, which doesn't quite match the usual requirements for stable uploads… We tend to have some leeway with the release team but I wouldn't want to abuse it. Current gut feeling (after a minute or two only), would be that it wouldn't deserve an upload on its own, but if there was some other bugfixes we could probably lump it up in there. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1049902: [Pkg-raspi-maintainers] Bug#1049902: bookworm-pu: package raspi-firmware/20220830+ds-1+deb12u1
Hi Gunnar, Gunnar Wolf (2023-08-16): > [ Risks ] > The code is very simple. Cassandra being my middle name, I'd advocate for more caution: The code change is relatively simple, but raspi-firmware hooks are not trivial… > The only risk I can think of is that the bug might still impact users > of non-Raspberry ARM systems. However, the likelihood of having it > installed is minor (due to the available hardware being different). Live images as of 12.0.0 installed all firmware packages, including that one, so that likelihood is *definitely not minor*. > [ Changes ] > Postinst will now check whether the architecture is ARM*, and exit > otherwise without doing the firmware install dance. > > [ Other info ] > A more proper fix would be to create a separate package with the wireless > Broadcom firmware. I have requested for the kernel team (maintainers of > firmware-brcm80211) to do so, but have got no positive response. I'd call that an orthogonal topic. In the extra checks department, I'd suggest making sure that once raspi-firmware is installed on say an amd64 machine, upgrading it to the proposed version makes it possible to upgrade a kernel (which has been the major pain point up to now) and also to… remove raspi-firmware. As far as I can remember from user horror stories, they couldn't even remove the package, and had to manually remove hooks under /etc before being able to finally remove the package. Pinch of salt, don't trust my memory. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1049898: debootstrap: change /usr-merge implementation to merge after unpack
Hallo Helmut, Digression alert: some context around debootstrap in particular and d-i packages in general. Helmut Grohne (2023-08-16): > we've had quite some discussion about various aspects of finalizing the > /usr-merge in the past half year. […] > I hope we don't get anymore disagreement with this and would like to > proceed with merging and uploading the change. Simon intends to backport > this change and > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93 > to bookworm and bullseye via SPU. Getting that latter change into > bullseye is a prerequisite for converting buildd chroots to a merged > layout, which is a prerequisite for lifting the moratorium. In order to > avoid going through SPU multiple times, we'd like to do both changes at > once. > > More background is available in the DEP17 draft. I've put up a rendered > version at https://subdivi.de/~helmut/dep17.html. In there, P8 is the > item concerned with debootstrap and M19 is the mitigation I am proposing > in this bug. > > Is there any prerequisite you see missing before we can merge and upload > this change? Any aspect to be analyzed? Any situation to be tested? Any > conceptual aspect I am missing? > > In the absence of a response, I intend to move forward with a delayed > NMU in accordance with devref, but I strongly appreciate more eyeballs > as this change is not without risks. Ever since the --[no-]merged-usr options were introduced, and the default flipped a couple of times, I've deliberately stayed away from that topic. Especially since what to do really needed to be decided at the project level (that's not just a d-i topic). That was reinforced once bluca started implementing changes with a TC hat, and that explains the series of NMUs until now. I'm happy that people want to upload debootstrap; I have no strong feelings as to whether bluca or you should keep them as NMU. NMUs made sense to me initially, as it was making it clear to everyone that we have TC-decided-then-implemented changes. Since later contributions started including unrelated changes, those uploads really could have been team uploads, with or without uploaders adding themselves to the Uploaders field. The only thing I expect from people uploading d-i packages is being considerate in what they're changing, and not forgetting (when it comes to udebs) that most of our packages' end goal is getting used within the context of the installer; and to follow up if needed. (src:debian-installer is a little more special than other packages, but that's the general idea.) We've also been pretty liberal with adding people to the team so that they can push stuff in branches (master or otherwise); all that's needed in the end is someone taking responsibility for the actual upload to the archive. Later in the release cycle, we appreciate some coordination but my having a hand on the release hints and being able to ACK/NACK stuff in unstable for testing (while a temporary freeze is in place for udeb-producing packages) makes the upload coordination a nice-to-have yet non-essential topic. As you might have guessed, this digression wasn't for nothing: I don't consider myself knowledgeable enough about the merged-/usr situation, and I'm fine with trusting you folks. Problems have been brainstormed, plans have been elaborated, and you're willing to implement them. As long as you're happy with following up if needed, I'm happy to have you NMU debootstrap, team-upload it, or just upload it (adding yourself to Uploaders or not, at your discretion). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1044866: [Pkg-raspi-maintainers] Bug#1044866: gpiozero: Fails to build source after successful build
Lucas Nussbaum (2023-08-13): > > dpkg-source -b . > > dpkg-source: info: using source format '3.0 (quilt)' > > dpkg-source: info: building gpiozero using existing > > ./gpiozero_1.6.2.orig.tar.gz > > dpkg-source: info: local changes detected, the modified files are: > > gpiozero-1.6.2/gpiozero.egg-info/PKG-INFO > > gpiozero-1.6.2/gpiozero.egg-info/SOURCES.txt > > gpiozero-1.6.2/gpiozero.egg-info/entry_points.txt > > gpiozero-1.6.2/gpiozero.egg-info/requires.txt > > dpkg-source: error: aborting due to unexpected upstream changes, see > > /tmp/gpiozero_1.6.2-1.diff.tixV0P > > dpkg-source: info: Hint: make sure the version in debian/changelog matches > > the unpacked source tree > > dpkg-source: info: you can integrate the local changes with dpkg-source > > --commit > > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2 > > > > E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage > > --sanitize-env -us -uc -rfakeroot -S' failed to run. The python tooling really ought to do the right thing when it comes to the egg-info directory. -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
