Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter
Hi, Thanks for the report but wow, that's way too many topics. baptx (2024-04-27): > The following issue is based on the discussion I created on > https://forums.debian.net/viewtopic.php?t=159027 where you can find > attached the content of /var/log/installer/syslog which was generated > on a virtual machine with virt-manager when installing > debian-live-12.5.0-amd64-lxqt.iso with the firmware=never parameter > (the problem was also present on my real computer when I tested with a > previous version debian-live-12.0.0-amd64-lxqt.iso). I also attached > the result of the vrms command after using firmware=never parameter. vrms is irrelevant. > To compare, you can also find attached another installer syslog > without using firmware=never parameter, which also contains the line > "hw-detect: skipping check-missing-firmware as requested by the > caller" and looks like a bug. No, it's not. See check on CHECK_MISSING_FIRMWARE in hw-detect. > The firmware=never parameter did not work at all when using the LXQt > ISO file (maybe the problem also happens on ISO files with other > desktop environments), the non-free firmware packages were installed. That would be a bug in debian-live then, not in debian-installer. Cc-ing accordingly. > And with the LXQt ISO file, the graphical expert install as well as > the text expert install did not ask me if I want the non-free firmware > packages, they were installed automatically. > I noticed the firmware=never parameter only worked with the netinst > ISO file. Well, that's been added for use by debian-installer. What debian-live does or doesn't do with it is outside our control. > For the automatic detection of needed non-free firmware packages, it > only worked with the netinst ISO file as well (the LXQt ISO file > installed all non-free firmware packages). But even with netinst ISO > file, it seems it is only guessing the non-free firmware packages > needed since several were not needed to make my laptop work correctly > (firmware-realtek, firmware-sof-signed) when installed on my real > computer instead of a virtual machine. The lookup is based on what devices are seen during the installation process. If the relevant kernel modules list firmware files, we try to match them to firmware packages, and queue their installation. Unless firmware=never was used of course. That doesn't mean they are absolutely required for those devices to work. There is just no way to know for sure. > It would also be useful to have the firmware=never parameter added in > a menu in the normal graphical installation (for people who don't want > the complexity of the expert installation), since it is more > convenient to have it in a menu and also avoids mistakes when typing > firmware=never (I accidentally typed firmzare due to my AZERTY > keyboard and the QWERTY input). Menu maintenance (esp. across architectures, BIOS vs. UEFI, etc.) is a huge mess already, it might happen but I'm not holding my breath here. > It would be a good idea to warn the user if the entered parameter / > value does not exist, to avoid unwanted results like installing > non-free firmware. There's no absolute list to check against, so that cannot be done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Making trixie debootstrap-able again?
Cyril Brulebois (2024-04-26): > Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting > because I'm really not sure this would be the right course of action, more > details below) a new binNMU of coreutils within testing would be > sufficient to make trixie debootstrap-able again, I built a modified > repository, and try debootstrap against it, only to find more problems: > - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone. > - iproute2 depends on libtirpc3, which is gone. > > I guess the reason is similar, the former I tracked down to the same block > of hints as before: > > # 2024-04-23; done 2024-04-25 > # help some t64 packages migrate > […] > force-hint readline/8.2-4 > > The latter I tracked down to thisone: > > # 2024-04-23; done 2024-04-26 > # get t64 unstuck > urgent libtirpc/1.3.4+ds-1.3 > force-hint libtirpc/1.3.4+ds-1.3 > > Again, I have absolutely no clue regarding the best course of action at > this point. I can't even perform clean builds to check what a binNMU in > testing would look like, as I can't debootstrap a clean environment (and > therefore only tested rebuilds in an existing, devel-oriented, unclean > trixie chroot). Looks like I forgot to mention the final results: with the modified repository stuffed with (unclean) rebuilds of coreutils, iproute2, and util-linux, I'm able to debootstrap trixie again. (I've hacked a repository together from scratch, based on the failed debootstrap's apt cache, adding rebuilt packages, and injecting new dependencies manually; I could redo that cleanly by forking trixie's current Packages instead, but I'm not sure it's really worth the efforts, esp. given rebuilt packages are “tainted” anyway.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Making trixie debootstrap-able again?
Hi, I'm not sure how we reached this situation but there are a bunch of packages in trixie that are not in a suitable state. To reproduce, a simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient. Note: I've limited my exploration to amd64, which kept me busy already… An obvious first problem is coreutils, which picked a Pre-Depends on libssl3 (not the t64 one), which… disappeared from testing between the 2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at Packages.gz for amd64 via snapshot.debian.org). The coreutils binNMU is hardly new, as it appeared via unstable in January, and was already in testing by April 1st (I didn't check earlier than that). Therefore I'm quite baffled to see libssl3 happily disappear from testing while we still have stuff that Pre-Depends on it?! Checking britney, I suppose this is a result of the following hint: # 2024-04-23; done 2024-04-25 # help some t64 packages migrate […] force-hint openssl/3.2.1-3 Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting because I'm really not sure this would be the right course of action, more details below) a new binNMU of coreutils within testing would be sufficient to make trixie debootstrap-able again, I built a modified repository, and try debootstrap against it, only to find more problems: - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone. - iproute2 depends on libtirpc3, which is gone. I guess the reason is similar, the former I tracked down to the same block of hints as before: # 2024-04-23; done 2024-04-25 # help some t64 packages migrate […] force-hint readline/8.2-4 The latter I tracked down to thisone: # 2024-04-23; done 2024-04-26 # get t64 unstuck urgent libtirpc/1.3.4+ds-1.3 force-hint libtirpc/1.3.4+ds-1.3 Again, I have absolutely no clue regarding the best course of action at this point. I can't even perform clean builds to check what a binNMU in testing would look like, as I can't debootstrap a clean environment (and therefore only tested rebuilds in an existing, devel-oriented, unclean trixie chroot). Seeing how some packages, e.g. coreutils, have DEP-17 changes staged in unstable (since 1.5+ month), I'm definitely not advocating for pushing them into testing as a quick or easy fix for those issues. I'm not sure whether you're keeping track of things that break when force-hinting but if you were aware of the resulting breakages already, some kind of heads-up would have been nice… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: udhcpc search domain
Hi Frédéric, Frédéric Guyot (2024-04-26): > That's great, thank you for your fast response/fix. > Just need to update netcfg now. Should I create a new post on the mailing > list ? The “request something on a list and that works out” is more of an exception than the rule. To ensure proper tracking, a bug report is always a better idea. You could propose a patch attached to the bug report, and/or file a merge request: https://salsa.debian.org/installer-team/netcfg/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: debian-installer/netcfg: Netplan support feedback
Hi Lukas, Lukas Märdian (2024-04-25): > Turns out d-i was unable to finish the installation, due to > installability issues of packages in the target system, especially > systemd-sysv vs libssl3 in this case. The archive is still very much > in flux and this is probably also why we still see d-i daily build > failures [0] (but its looking much better already!) and Salsa-CI > failures for d-i [1]. What I've reported a while back, and what I ended up fixing last week were all udeb relationship issues making it impossible to build d-i or to run it (I don't have the details but I'm pretty sure all runtime issues would already show up at build time anyway, and yes that explains a lot of red on the d-i daily build graphs). And yeah, at the moment we end up with a debootstrap problem when installing trixie, since libssl3 is gone from trixie (except on 32-bit arms) while coreutils still Pre-Depends on it. That's one blocker I've just confirmed again, but didn't look for possible others. I haven't followed recent progress on the 64-bit time_t front, maybe rebuilding packages within testing might help get rid of such issues, that might make some other things harder… Seeing how the package in unstable has DEP-17 changes on top, I'm not sure I want to get involved in the intersection of two gigantic transitions I'm not knowledgeable about. :/ Installing unstable is more likely to succeed though (as at least a plain debootstrap sid works, as opposed to a plain debootstrap trixie). Thanks for the write-up, I'll check it when time permits. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Marco d'Itri (2024-04-26): > On Apr 26, Michael Tokarev wrote: > > > So, should I disable module utils in busybox-udeb now? > I think so. I haven't gotten any requests / seen any reasons to keep it; so, yes, please feel free to remove it whenever is convenient for you. > > Is kmod udeb ready and used in d-i already, or does it need some > > prep first? > AFAIK it works. Absolutely, that's been working since the small xz-utils tweak (the udeb addition, not the backdoor thing). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1069099: binNMUs to fix mtdev-using udebs
Cyril Brulebois (2024-04-16): > Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) > on all archs, provided that doesn't interfere with the whole 64-bit time_t > transition: > - libinput10 That ought to read: - libinput Sorry about that. > - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069099: binNMUs to fix mtdev-using udebs
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-boot@lists.debian.org Hi, mtdev regressed a while back, leading a few udebs to become uninstallable (initially one[1], now two). 1. https://bugs.debian.org/1066071 No response in 1+ month, the package wasn't ready to migrate anyway since it was waiting on dpkg but also regressing on 32-bit arms; I've uploaded an NMU yesterday, built everywhere. I also verified that rebuilding the following two packages gives appropriate dependencies for their udebs. Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) on all archs, provided that doesn't interfere with the whole 64-bit time_t transition: - libinput10 - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1069020: release.debian.org: binNMUs to fix libpng-using udebs
Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-boot@lists.debian.org Hi, libpng1.6 regressed a while back, leading a few key udebs to become uninstallable[1]. That was fixed rather quickly[2] but binNMUs haven't happened yet. We haven't heard back from people driving the 64-bit time_t transition either, it's been a while, so I'm contacting you to see if you could arrange some binNMUs, without disrupting their work. 1. https://bugs.debian.org/1066069 2. https://tracker.debian.org/news/1515481/accepted-libpng16-1643-4-source-into-unstable/ Please consider binNMU-ing the following source package against libpng-dev (>= 1.6.43-4): - cairo - gdk-pixbuf - freetype [armel] That's based on udeb installability checks[3], and I only verified on amd64 that both cairo and gdk-pixbuf get appropriate dependencies for their udebs when rebuilt. 3. https://d-i.debian.org/dose/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Re: Bug#1066071: mtdev: broken shlibs, leading to uninstallable udebs
Hi, Cyril Brulebois (2024-03-12): > Your NMU broke this package's shlibs. > > Before: > > libmtdev 1 libmtdev1 > udeb: libmtdev 1 libmtdev1-udeb > > After: > > libmtdev 1 libmtdev1t64 > > At the moment, at least the following package is broken: > > The following packages have unmet dependencies: > libinput10-udeb : Depends: libmtdev1t64 but it is not installable No response in 1+ month, the package isn't ready to migrate anyway since it's waiting on dpkg but also regressing on 32-bit arms. Source debdiff attached for the NMU, which I've verified to generate appropriate shlibs, leading a rebuilt src:libinput10 to have appropriate dependencies as far as libinput10-udeb is concerned. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru mtdev-1.1.6/debian/changelog mtdev-1.1.6/debian/changelog --- mtdev-1.1.6/debian/changelog 2024-02-28 21:51:50.0 +0100 +++ mtdev-1.1.6/debian/changelog 2024-04-15 09:51:44.0 +0200 @@ -1,3 +1,12 @@ +mtdev (1.1.6-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix shlibs entry for the udeb: set DEB_DH_MAKESHLIBS_ARGS_libmtdev1t64 +instead of setting DEB_DH_MAKESHLIBS_ARGS_libmtdev1, to match the + rename of the library (Closes: #1066071). + + -- Cyril Brulebois Mon, 15 Apr 2024 09:51:44 +0200 + mtdev (1.1.6-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru mtdev-1.1.6/debian/rules mtdev-1.1.6/debian/rules --- mtdev-1.1.6/debian/rules 2020-05-24 06:38:08.0 +0200 +++ mtdev-1.1.6/debian/rules 2024-04-15 09:50:23.0 +0200 @@ -9,7 +9,7 @@ distribution := $(shell lsb_release -is) LDFLAGS += -Wl,-z,defs -Wl,--as-needed -DEB_DH_MAKESHLIBS_ARGS_libmtdev1 = --add-udeb=libmtdev1-udeb +DEB_DH_MAKESHLIBS_ARGS_libmtdev1t64 = --add-udeb=libmtdev1-udeb DEB_INSTALL_MANPAGES_mtdev-tools = debian/mtdev-test.1 signature.asc Description: PGP signature
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
Re: Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Hi, Marco d'Itri (2024-04-09): > Yes. Nowadays kmod has many more features related to compressed modules > and verification of signatures. > Can we agree that kmod should provide these programs for d-i? > Or can the d-i maintainers just tell us what they want? I meant to come back to this after experimenting, then things happened… I picked kmod at the time because it worked, and because busybox didn't work, which I summed up in: https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145 (plus follow-up commit, woopsie https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07 ) I'm fine with sticking to kmod regarding module support in d-i. I'm not sure we should keep support in two different modules, so dropping it from busybox would work for me. Others might have different views on this, though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068197: debian-installer: accesses the internet during build
[ Switching from ML to bug. ] Hi Jonathan, Jonathan Carter (2024-04-01): > On 2024/04/01 18:55, Aurelien Jarno wrote: > > debian-installer attemps network access during build, although only to > > the mirrors listed in /etc/apt/sources.list and in a secure way. This is > > forbidden by Policy 4.9: > > > >For packages in the main archive, required targets must not attempt > >network access, except, via the loopback interface, to services on the > >build host that have been started by the build. > > > > In addition this brings constraints to the build daemons infrastructure. > > As far as I know, this doesn't happen until after d-i asked the question "Do > you want to use a network mirror?" and the user answered "Yes", in which > case I think that would count as informed consent. This isn't about d-i runtime, this is about src:debian-installer's *build* requiring network access, which is a very well known problem (even though there are no obvious solutions, at least that I'm aware of), and that's now getting in the way of changes being considered regarding the buildd network. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Re-planning for 12.6
Hi, Adam D. Barratt (2024-04-01): > As we had to postpone 12.6, let's look at alternative dates. I should be able to make anything work. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)
Hi, Cyril Brulebois (2024-03-21): > I'm a bit conflicted about what to do here. At the moment, libaio1-udeb > is the only udeb with t64 (at least according to the output of > `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies > would be sufficient (and might happen at some point anyway). > > For the sake of consistency, I think I'm tempted to suggest a revert of > the udeb part (it wasn't renamed so there's a contents vs. package name > mismatch anyway). Checking libaio's changelog (last mail got sent a little too fast, sorry) is enlightening: this library required special attention and wasn't just about getting rebuilt with a different package name. https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/ Guillem is absolutely right regarding avoiding the roundtrip to NEW and d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd) would have been welcome. It'd be nice if the Debian LVM Team (hello waldi) could pick it up from here and see whether requesting a binNMU is what makes most sense here, or if there other plans on the t64 front. A local, cowbuilder-powered rebuild of unstable's lvm2 results in udebs referencing libaio.so.1t64 as expected (i.e. libaio1t64's shlibs). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#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
dose4udebs is back
[ bdrung and vorlon cc'd for information; DSA bcc'd for <3 ] Hi, dose4udebs was uncronned a while back, even if git doesn't show a specific reason for it (lots of live changes hadn't been committed when bubulle removed himself): https://salsa.debian.org/installer-team/d-i/-/commit/3d25abea44bb9122ee404394f6e84d67aa874b31 The last update happened: Mon Sep 3 01:52:02 UTC 2018. Until that point we had access to a full Debian mirror on dillon (behind d-i.d.o), which meant we could access all indices directly. I requested a while back whether those indices could be made available again to avoid having to maintain a partial sync myself (as the d-i user), and DSA agreed to make it happen (thanks!). This means /srv/mirrors/debian is still a broken symlink (to /auto.dsa/debian) but we have access to /srv/mirrors/ftp.debian.org/ftp/ instead now. This means dose4udebs is back: https://salsa.debian.org/installer-team/d-i/-/commit/44263866b787f349fe88710f550387dc1f6c3de4 and it seems to be quite needed nowadays… Also, thanks to Samuel for the heads-up while filing #1064974 against alsa-lib, the comment about other packages being possibly affected was spot on. Those following debian-boot@ might have noticed other bug reports: - #1066069 for libpng1.6 (udeb only) - #1066071 for mtdev (udeb only) - #1066073 for wireless-tools (udeb only, QA-maintained, fixed) - #1066074 for ntfs-3g (deb and udeb) Graphs are available at the usual place, and I'm notified about changes between runs: https://d-i.debian.org/dose/ That should help us stay on top of changes affecting udeb installability, shortening the feedback loop for people doing the actual work of patching many packages. (Some packages were uploaded 10+ days ago.) 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-boot@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-boot@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-boot@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-boot@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-boot@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#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
Re: What to do with d-i on armel?
Bastian Blank (2024-03-04): > On Sun, Mar 03, 2024 at 09:01:06PM +0100, Cyril Brulebois wrote: > > Maybe have it marked Not-For-Us on armel, also requesting the binary to > > be dropped there? And maybe poke the ftp team to have installer-armel/ > > cleaned up? (The “disabling daily builds” part being trivial.) > > i would remove the d-i package itself (don't we already set the > supported architectures?) No, at least not in debian/control, that's why I'm asking. I would love to avoid having to maintain a list of architectures… > Cleanup installer-armel. ACK. > Remove armel specific udeb sources (I doubt we hve any). Doesn't ring a bell. > I would not try to remove udebs itself but just continue to build them. Sure, nothing to gain there. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: What to do with d-i on armel?
Bastian Blank (2024-01-07): > With Linux 6.6 we dropped the Marvell specific kernel image, as it > was not known to work on any of the available devices. We still have > another armel kernel left, the one of the Raspberry Pi 0 and 1, which > uses an ARMv6 CPU. > > This also removed all the udebs from armel, which makes many d-i > components not longer have fullfiled dependencies and the release stuff > of course acting up. > > Do we have any armel subarch that can be installed via d-i? Unless we get something to support in d-i, I'm wondering how to proceed with dropping support for armel. Unsupported things tend to move to ports while still being supported by porters, so we don't have much to do there besides go with the flow. That'd be the first time (that I can think of) that we have an FTBFS-ing d-i for an architecture that's in unstable. Maybe have it marked Not-For-Us on armel, also requesting the binary to be dropped there? And maybe poke the ftp team to have installer-armel/ cleaned up? (The “disabling daily builds” part being trivial.) I see no time pressure here, we have a big transition going on, so it doesn't seem particularly fitting to try and get a d-i release out any day soon. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
mips64el daily builds (hopefully) back
Hi, For some reason, PATH wasn't set in the d-i user's crontab, missing /usr/local/bin for dd-schroot-cmd. (Dates back all the way to December when the eller → eberlin switch happened…) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: debian-installer/netcfg: Netplan support feedback
Hi Lukas, Lukas Märdian (2024-02-19): > I've been working on a merge-request for debian-installer/netcfg, > which adds support for Netplan to debian-installer. > > If and only if the `netplan-generator` package is detected to be > installed in the target system, netcfg will write corresponding > Netplan configuration to /target/etc/netplan/. Otherwise, it will > stick to writing the traditional ifupdown or NetworkManager > configuration. > > Some discussions happened already on the MR since DebConf23, but I'd > appreciate any additional feedback to the road to getting this merged! > > https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 From an earlier look, I think I'd go for an explicit no-op (and comment) in a netplan case, instead of just having the comment in a different case; but that's really just cosmetic. I'll try and get around to testing this soon-ish, then merge and upload if that goes fine. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: tasksel_3.74_source.changes ACCEPTED into unstable
Hi, Debian FTP Masters (2024-01-27): > [ Arnaud Rebillout ] > * Fix task ordering, and make 'apt install' more deterministic. That's probably a good idea but seeing how standard that's always been at the very bottom suddenly pops up at the very top, I think it would have warranted a slightly more verbose changelog entry… (See also the length of some commit messages and the “subtleties” mentioned there, one being about standard specifically…) Besides, I'm very much not sure it's a good idea to have standard be listed first. I'd expect people to want to turn desktop environment on/off, and be accustomed to have that first. Do we really want to break finger memory? Being able to disable standard to save a little space has never looked like a bad idea to me, but having that be the first entry on that list feels very weird. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.6
Jonathan Wiltshire (2024-02-12): > 12.6 should be around 10th April, so please indicate availability for: > > 6 April > 13 April > 20 April Any of those should work. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Uploading linux (6.6.15-1)
Salvatore Bonaccorso (2024-02-02): > One thing is still unresolved, thus additonally to the explicit CC to > kibi, as well including debian-boot. We have the armel d-i situation > not yet resolved, debian-boot folks, do you have any imput on the > situation from the thread in > https://lists.debian.org/debian-release/2024/01/msg00089.html ? > My gut feeling from what was discussed is that nobody will ever use > the d-i on armel. I'm not sure how much time armel will stick around (for existing systems), but it looks to me that d-i/armel is no longer relevant. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: debian-installer | salsa-ci: if version-skewed, use the currently available ABI version (!41)
Philip Hands (2024-01-26): > Philip Hands writes: > > > How about using '++'? > > After a little more thought I concluded that '+~' is marginally better, > so here's that alternative, just in case anyone agrees with me: > > > https://salsa.debian.org/philh/debian-installer/-/commit/f5044026b07d8dbf938394193708b33ea811ae2e Both solutions (and others in the same vein) sound specific enough that they shouldn't affect stable releases so feel free to pick whatever you like best. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: debian-installer | salsa-ci: if version-skewed, use the currently available ABI version (!41)
Hi, Philip Hands (@philh) (2024-01-24): > Merge request !41 was merged > Merge request URL: > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/41 > Project:Branches: philh/debian-installer:salsa-abi-fixup to > installer-team/debian-installer:master > Author: Philip Hands Commit 931269d99b1595725f41474e3ae00a78c9d274ae breaks builds for stable branches, which are DATE+debXuY. Example on bookworm: DATE gets set to 20230607 instead of 20230607+deb12u4. Of course that's going to be a problem for trixie onwards, but I'd rather get that sorted out now, and not on the way to the first point release, which is usually quite busy already. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: salsa CI
Samuel Thibault (2024-01-23): > The CI on salsa doesn't manage to build the debian-installer package > because the signed linux 6.6.13 package is not available yet. Perhaps we > should turn these build-deps: > > linux-image-6.6.13-amd64 [amd64], > linux-image-6.6.13-arm64 [arm64], > linux-image-6.6.13-686 [i386], > linux-image-6.6.13-686-pae [i386], > > into > > linux-image-6.6.13-amd64 [amd64] | linux-image-6.6.13-amd64-unsigned > [amd64], > linux-image-6.6.13-arm64 [arm64] | linux-image-6.6.13-arm64-unsigned > [arm64], > linux-image-6.6.13-686 [i386] | linux-image-6.6.13-686-unsigned [i386], > linux-image-6.6.13-686-pae [i386] | linux-image-6.6.13-686-pae-unsigned > [i386], > > ? udebs are built from the linux-signed-* packages, so that doesn't help at all. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: debian-installer FTBFS due to usrmerge
John Paul Adrian Glaubitz (2024-01-12): > I just ran into a new FTBFS with d-i which seems to be related to usrmerge: > > sort -u < ./tmp/cdrom/built-using.txt > ./tmp/cdrom/built-using.txt.new && \ > mv ./tmp/cdrom/built-using.txt.new ./tmp/cdrom/built-using.txt > sort -n < ./tmp/cdrom/diskusage.txt > ./tmp/cdrom/diskusage.txt.new && \ > mv ./tmp/cdrom/diskusage.txt.new ./tmp/cdrom/diskusage.txt > grep-dctrl -nsPackage,Version,Architecture '' > ./tmp/cdrom/tree/var/lib/dpkg/status | \ > perl -nle '$p = $_; $v = <>; chomp $v; $a = <>; chomp $a; <>; print > "$p $v $a"' | \ > sort > ./tmp/cdrom/udeb.list > merge-usr "./tmp/cdrom/tree" > error: merge target 'usr//sbin/depmod' is a symlink > > Has anyone seen this yet? On this list: https://lists.debian.org/debian-boot/2024/01/msg00046.html and #1060134. I haven't made up my mind yet. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
d-i ftbfs in merge-usr, on depmod
Hi Helmut, d-i daily builds now FTBFS everywhere due to the merge-usr step, with the following error: merge-usr "./tmp/cdrom/tree" error: merge target 'usr//sbin/depmod' is a symlink It would be nice if you could investigate and suggest what fix(es) would be best here. I suppose it could be some fallout from the kmod upload which included some changes of yours, hence the ping. https://tracker.debian.org/news/1491892/accepted-kmod-31-1-source-into-unstable/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Shutdown of servers at AQL (mips*el porterbox and buildds)
Hi, Aurelien Jarno (2023-12-28): > On 2023-11-23 07:11, Aurelien Jarno wrote: > > Our hosting agreement with AQL has ended. As a result we need to unrack > > the servers that were hosted there. We are working on relocating them or > > setting up new servers elsewhere. > > > > The list of affected services are: > > - eller.d.o (mips*el porterbox) > > eberlin.d.o has been setup as a mips*el porterbox to replace eller.d.o. d-i daily builds just set up there, and dillon's configuration updated accordingly. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.5/11.9
Steve McIntyre (2023-12-26): > Any of those *should* be OK for me. Ditto. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 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
Re: 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
Re: Immediate fallouts from the big linux changes, and actions
Bastian Blank (2023-12-24): > On Sun, Dec 24, 2023 at 08:38:57AM +0100, Cyril Brulebois wrote: > > - kernel-image-* packages are now shipping /boot/vmlinuz-* (or > > /boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz > > (respectively /boot/vmlinux). > > This was even dependent on architecture. A lot of secondary > architectures already had various suffixes. Looking at kernel-image-* 6.5.13-1 for release archs, I'm only seeing mips64el (-6.5.0-5-5kc-malta, -6.5.0-5-loongson-3, -6.5.0-5-mips64r2el suffixes), and its build targets didn't hit the codepath I had to patch for the general case. Anyway, since you're not reacting with “oops, we didn't mean to”, I'm going to count this as a deliberate change. > > - Modules are compressed now, so the drm workaround needed an updated to > > cope with the extra .xz suffix: > > > > https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea > > This now hardcodes .xz. And I'm not really sure what this does and why > this can't be fixed in the kernel packages. Because that's a workaround for a problem that's not in the kernel and that remains to be fully investigated. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Immediate fallouts from the big linux changes, and actions
Cyril Brulebois (2023-12-24): > Feel free to reply to this thread if you spot other fallouts. Another FYI: one thing that I spotted early on (before realizing module support was entirely broken), when I first diffed the list of files available in the initramfs, building against testing's or unstable's linux udebs: a bunch of virtio modules disappeared. Comparing 6.5.0-5-amd64 and 6.6.8-amd64: usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_balloon.ko usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_dma_buf.ko usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_input.ko -usr/lib/modules/$ABI/kernel/drivers/virtio/virtio.ko usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_mmio.ko -usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_pci.ko -usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_pci_legacy_dev.ko -usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_pci_modern_dev.ko -usr/lib/modules/$ABI/kernel/drivers/virtio/virtio_ring.ko A cursory look in linux.git didn't yield an obvious answer: git diff debian/6.5.13-1..debian/6.6.8-1 -- debian/installer/ Indeed, that's mostly about kernel-versions's getting dropped, fuse going away, some Depends field being updated, and some i2c-hid-* now getting excluded in one place, and added conditionally in another one… Searching for information about fuse and virtio, I finally noticed this entry, which probably explains both fuse's “going away” and ditto for some (but not all) virtio modules: * Set CONFIG_VIRTIO_FS and its dependencies to builtin, to allow building images that boot directly to rootfs (skipping the initrd) as it changes: -CONFIG_VIRTIO_PCI=m +CONFIG_VIRTIO_PCI=y -CONFIG_FUSE_FS=m +CONFIG_FUSE_FS=y -CONFIG_VIRTIO_FS=m +CONFIG_VIRTIO_FS=y I thought I'd mention the answer by mail since I brought up the topic earlier (even if only on IRC). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Immediate fallouts from the big linux changes, and actions
Hi, This is mostly for information: linux went through a lot of big changes, initially staged in experimental, and uploaded to unstable as of linux 6.6.8-1. These impacted the installer in different ways. This is a summary of the obvious impacts, there might be some others down the line (just by glancing at hw-detect's massaging of module list by stripping the .ko suffix). - kernel-image-* packages are now shipping /boot/vmlinuz-* (or /boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz (respectively /boot/vmlinux). I didn't dive into all the changes but I'm not sure whether that was on purpose or a side effect of the big changes. In any case, on the short term, since the build system was relying on a single file there, that should be moved out of the way, I decided to unversion those files to restore the old names. If kernel maintainers decide to go back to unversioned files, two reverts should be enough: https://salsa.debian.org/installer-team/debian-installer/-/commit/c17360e632b6f133d4b43a47461944b6203ed730 https://salsa.debian.org/installer-team/debian-installer/-/commit/865c66e497d8e809872bad04aa2269d2a9f889c8 - Modules are compressed now, so the drm workaround needed an updated to cope with the extra .xz suffix: https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea - I'm skipping two commits regarding the new way the ABI is written down, that's in line with what was announced initially. - YIL: If you don't see anything move in the graphical installer (no keyboard, no mouse), if your video is garbled, and if you can't load a NIC module in the text installer, you might have a totally broken support for kernel modules in your installer. This required adjusting src:xz-utils to get a liblzma udeb and src:kmod to enable xz support in its udebs; “thankfully” the former is NMU-maintained, plus the ftp team speed-reviewed it from NEW; thankfully Marco ACK'd my NMU-ing kmod so that we unbreak things ASAP. Everything should be sorted out in unstable. Plus an extra commit to be extra careful between the kmod upload and the cronned daily builds (which were going to start before the 01:52Z dinstall): https://tracker.debian.org/news/1489255/accepted-xz-utils-545-02-source-amd64-all-into-unstable/ https://tracker.debian.org/news/1489268/accepted-xz-utils-545-03-source-into-unstable/ https://salsa.debian.org/md/kmod/-/merge_requests/13 https://tracker.debian.org/news/1489283/accepted-kmod-3020230601-21-source-into-unstable/ https://salsa.debian.org/installer-team/debian-installer/-/commit/c65bdb8128bc68cb566b302feb46267e5c177eb4 - Finally, the armel build fails because it can't find its kernel. The marvell flavour seems to have been dropped entirely (at least that's how I read the linux changelog for 6.6.3-1~exp1: https://tracker.debian.org/news/1482751/accepted-linux-663-1exp1-source-into-experimental/ I didn't investigate the last point and I'd appreciate it if porters could double check that we really want to drop marvell at this point, and maybe submit (or commit) patches to drop it from the installer: https://salsa.debian.org/installer-team/debian-installer Various netboot and netboot-gtk checks on amd64 seem very positive after those changes, but I haven't built a netinst image and checked on actual hardware with the combination of Secure Boot + firmware packages + reloading of kernel modules. The latter should primarily work by using module *names* and firmware *paths* as seen in kernel logs, so having different module *paths* shouldn't make a difference, but that's just my gut feeling based on my recollection (so nobody should trust me on this), and seeing how \.ko$ stripping appears in some other files, I cannot be certain until it's been actually tested. Feel free to reply to this thread if you spot other fallouts. Of course, as usual, the best way to report installer bugs is to file them against the relevant component, X-Debbugs-Cc-ing this list; but leaving an explicit reference in this thread wouldn't hurt. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#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#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
Re: Shipping the mini.iso files with the installer-images package?
Hi Wouter, Wouter Verhelst (2023-12-10): > I just created > https://salsa.debian.org/installer-team/debian-installer-netboot-images/-/merge_requests/3, > which removes the "grep -v mini.iso" from the "get-images.sh" script. > The idea being that it can be useful to have a mini.iso available > locally in case you want to install a VM with libvirt. While it's > possible to PXE boot a VM and install that way, this involves some > infrastructure that needs to be set up, and pointing to a .iso file that > exists locally seems easier. > > I usually have a netboot mini.iso file in my home directory for that > purpose, but it needs to be kept up to date with every point release, > and that's a bit of an annoyance. I think it would be easier to just > have it in the debian-installer-netboot-images package. Do you have stats before/after? Looks like it could easily double or triple the size of each binary package? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: bookworm mini.iso outdated?
Dick Visser (2023-12-08): > All images I download are sha1sum > c29dca30d20cbc0deadc6eec22e8ff3c2e9c0bf4 But are you actually using that image? > To be sure we're talking about the same thing, can you post the actual URL > of the image with sha1sum 8b8a7e8b1fc127e8704a63e54a93e84b985ccd4a? kibi@tokyo:~$ curl -s http://deb.debian.org/debian/dists/bookworm/main/installer-amd64/20230607/images/netboot/mini.iso -o - | sha1sum 8b8a7e8b1fc127e8704a63e54a93e84b985ccd4a - kibi@tokyo:~$ curl -s http://deb.debian.org/debian/dists/bookworm/main/installer-amd64/20230607+deb12u2/images/netboot/mini.iso -o - | sha1sum c29dca30d20cbc0deadc6eec22e8ff3c2e9c0bf4 - kibi@tokyo:~$ curl -s http://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso -o - | sha1sum c29dca30d20cbc0deadc6eec22e8ff3c2e9c0bf4 - I'm seeing the same on ftp.debian.org and ftp.fr.debian.org and whatever is happening is clearly not a problem on the mirror side… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: bookworm mini.iso outdated?
Hi, Dick Visser (2023-12-08): > I've been using the "mini.iso" for installing debian onto VMware VMs and > that has worked fine for years. This week I wanted to use that method to > install Bookworm, but I now get: > > No kernel modules were found. This probably is due to a mismatch between > the kernel used by this version of the installer and the kernel version > available in the archive. I can't reproduce that. > The image I got is > http://ftp.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso > > The sha1sum of the image I downloaded is > c29dca30d20cbc0deadc6eec22e8ff3c2e9c0bf4. I tried other mirrors and they're > all the same. Seeing the same shasum here, but definitely not having the problem you're mentioning. Are you sure you're actually using *that* image? > There appears to be only 20230607 and 20230607+deb12u2 both they both point > to the same (outdated) iso. I don't see any newer mini.iso images... The former is the version that shipped with 12.0; it's *not* the same as the latter, which is symlinked as 'current'. The former has the following sha1sum: 8b8a7e8b1fc127e8704a63e54a93e84b985ccd4a and does exhibit the problem you're mentioning (and it's normal for older images to behave that way). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#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
Re: [rt.debian.org #9382] Upgrade dillon to bullseye
Hi Adam, Adam D. Barratt via RT (2023-11-18): > I'd like to look at upgrading dillon to bullseye in the > not-too-distant future. Sure thing. > The d-i.debian.org metapackage fails to install on bullseye, because > it depends on ko.tex-base, which no longer exists in bullseye. The > removal notice suggests that its replacement is texlive-lang-korean, > which the metapackage already depends on for a few years now, so > hopefully dropping ko.tex-base shouldn't be an issue. That was an installation-guide dependency, removed in 2017, first released in 20180603: https://salsa.debian.org/installer-team/installation-guide/-/commit/3aa082a832ed636874995bf9e7bd25d0910c3365 Some more cleanup might be possible in there, but if you can build a package that's installable again right away, let's do that. > Do you see any issues with the upgrade from a d-i perspective? Are > there any particularly good times to do the upgrade, or that you'd > prefer to avoid? I'm less used to keeping an eye on the l10n machinery than Holger does, so you might want to wait for an explicit ACK there, but the rest I can probably check and fix/adjust as needed once the upgrade happens. No particular constraints on my side, thanks for asking. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
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
Re: 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
Re: 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
Re: usr-merge in debian-installer
Hi team, hi Helmut, Steve McIntyre (2023-11-16): > On Thu, Nov 16, 2023 at 06:06:00PM +0100, John Paul Adrian Glaubitz wrote: > >I just built updated installation images for Debian Ports and noticed that > >the > >generated /init script tried to start "start-udev" from > >/lib/debian-installer/ > >instead of /usr/lib/debian-installer which naturally fails. > > > >I could figure out so far where the path names for tools in the /init script > >are set. > > > >Does anyone have any idea where to look? > > I've just merged > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/39 > from Helmut (thanks!) which should in theory do everything we need. Yes, many thanks to Helmut for the awesome that's made a lot of things move into a seemingly much better situation. That you take care about doing things in phases, trying very hard not to knowingly disrupt anything is *very much* appreciated. As I said previously, I wish I would have been more available to let things through quicker, but previous events within Debian, and other commitments outside, didn't make that possible. Steve merged that earlier today, I poked the porterboxes (except amdahl which I couldn't reach) so that daily builds have a chance to come back up before the next scheduled run. Local building and local testing look good. Thanks again! 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#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
Re: 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-boot@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
Re: 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
Re: 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
Re: 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
Re: Planning for 12.3
Jonathan Wiltshire (2023-10-07): > How about: > 4th December (better for cadence) > 11th December (more likely suitable in practice) The later the better. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: reiserfsprogs udebs
Felix Zielcke (2023-09-20): > thanks for your replies. > I just uploaded reiserfsprogs-3.6.27-7 which removes them. > > Does this need an unblock from release team since it affects udebs? Only ftpmaster removals as usual when dropping binaries. Your package will still be on a list of packages producing udebs until I remove it, and even then, it's only affected when udeb-producing packages are frozen (usually a few hours or days when a release is underway). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: reiserfsprogs udebs
Felix Zielcke (2023-09-19): > Am 18.09.2023 22:23, schrieb Pascal Hambourg: > > On 18/09/2023 at 19:20, Cyril Brulebois wrote: > > > > > > I would think so, yes. If that's not too much of a hassle, maybe > > > wait a > > > few days in case someone can think of a clever case where keeping them > > > would make sense; but seeing it unsupported upstream, with the partman > > > part removed already, I can't see why that would be the case… > > > > Rescue mode ? > > But then it still would make sense, to at least remove the > mkreiserfsprogs-udeb > The reiserfsprogs-udeb which contains fsck maybe could be kept. While it can do that as well (to some extent), the installer's primary focus isn't to rescue systems but to install new ones; there are better tools for that anyway. Since the plan for mainline is to eventually drop support for ReiserFS, I don't think we should actively keep support for it “just in case someone needs to rescue a system”. If some user really wants to use d-i for that, we have a very wide range of versions available. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: reiserfsprogs udebs
Felix Zielcke (2023-09-18): > I just found out that partman-reiserfs has been removed in 2013 > already. So I assume it's safe to upload a new version of > reiserfsprogs without them? I would think so, yes. If that's not too much of a hassle, maybe wait a few days in case someone can think of a clever case where keeping them would make sense; but seeing it unsupported upstream, with the partman part removed already, I can't see why that would be the case… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: reiserfsprogs udebs
Hallo Felix, Felix Zielcke (2023-09-18): > reiserfsprogs still provide 2 udebs: reiserfsprogs-udeb and > mkreiserfs-udeb. > > > > ReiserFS has been now deprecated in linux upstream and is scheduled to > be removed in 2025 [1] > And there's now a patch and discussion[2] on going to have it removed > fro m the defconfig profile. > > Are they actually still used in debian-installer or can they be > removed? Nobody should be creating now a reiserfs on a fresh new Debian > installation. > > Regards, > Felix > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb103a51640e > [2] https://lore.kernel.org/all/20230910232640.113938-1-pe...@n8pjl.ca/ Thanks for reaching out. They're probably good to go away. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: cleanup of debian installer news
Thomas Lange (2023-09-06): > I guess the search engine will need a replacement by another tool. > That means a lot of work but currently noone is working on that. That's unfortunately a frequent situation. That still doesn't justify removing useful information. > IMO the target group of our web pages are mainly end users, which are > not interested in this detailed technical infos at all. I disagree. That part is specifically under the *devel/* namespace. > "it's frequent to go back" may only apply to some developers of the > installer. I've never looked backed at all and news or changes from > that long ago does not seem worth keeping. Your absence of need doesn't cancel our actual need. Which by the way might be for our sake or for users'… > And we will still have these news/announcements on the > debian-devel-announce mailing list. That's much more cumbersome to wade through than looking into a central place. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: cleanup of debian installer news
Hi, Thomas Lange (2023-09-05): > I'm part of Debian's web team and I like to remove old outdated > content. > > The reason is that we have too may web pages (more that 63.000 wml > files) and our search engine is not able to present search results > order by date. That looks the search engine needs fixing then. > Currently I'm search for very old contents and I stumbled upon > https://www.debian.org/devel/debian-installer/News/ > which lists all news from the past back to 2003. > > IMO News become irrelevant very fast, so keeping them on our web pages > does not make sense. What do you think about removing all past years > and only listing the news that are relevant to the current stable and > testing release. So we would not list debian installer news by year, > but just provide a list link to the news relevant for bookworm for e.g. > > What is your oppinion about this cleanup? I'm not convinced at all; it's frequent to go back and look when this or that change was introduced, and actively removing useful information due to technical limitations in a search engine doesn't seem convincing at all. > BTW, I'm on my way to DebConf. Will anyone from the installer team > also come to Kochi? I'm not. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Daily d-i images for i386 not being built?
Steve McIntyre (2023-09-05): > >BTW: mipsel CD (netinst) images are no longer being built apparently? > >Can they be removed as well? > > Yes. > > >The netboot images for mipsel seem to stay, as it is for i386? > > No, mipsel is going away totally. We'll be killing it completely from > trixie, archive-wide. Both points just addressed: To salsa.debian.org:webmaster-team/webwml.git 2583d3aa00b..e8f735936de HEAD -> master If you look at the mipsel directory you'll only see old daily builds, and they'll get pruned eventually. I'll adjust tooling and/or dillon when I get a chance. Thanks. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#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
Re: Daily d-i images for i386 not being built?
Holger Wansing (2023-08-30): > So you mean a changing like attached... I'm so sorry, I had assumed the other image section was built using a loop on devel image list, that's why I thought we'd need an addition there. Since that's using an hardcoded list of download links, no need to change that, and the single change required is adjusting devel and trixie images list? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Daily d-i images for i386 not being built?
Holger Wansing (2023-08-28): > There's already a mechanism for filtering archs here, so I'm not > sure, if inventing another method in parallel is an improvement. That's really apples and oranges: - s390x is here and is here to stay (I have no opinions regarding the current exclusion/implementation though — in passing, s390 is long gone even if it still appears…); - i386 is in a weird state where it's going to be in the archive, with d-i builds, without debian-cd builds. It really does make sense to me to have both archs treated separately. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Daily d-i images for i386 not being built?
Holger Wansing (2023-08-28): > Cyril Brulebois wrote (Sun, 27 Aug 2023 21:42:54 +0200): > > Holger Wansing (2023-08-27): > > > So no more netinst images, > > > > And any other sections about CD, DVD, etc. must go. > > > > > but the "Other images" section will stay (netboot images, hd-media > > > ...)? > > > > Right, only that one stays. > > I have prepared a patch with this changings. > > @kibi: > Since this file has > "# This file should only be updated by a D-I release manager." > at its top: > do you want to commit it or do a proofreading? Thanks for the proposal, but I'm not sure this is the best way to do it. I think editing i386 out of english/template/debian/installer.wml (devel and trixie lists), and adding it manually in the netboot section would be better? (Naturally it'll show up before or after the list, but that's really an unimportant cosmetic issue that could be fixed by having an extra sort-arches macro if one feels strongly about it.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Daily d-i images for i386 not being built?
Holger Wansing (2023-08-27): > So no more netinst images, And any other sections about CD, DVD, etc. must go. > but the "Other images" section will stay (netboot images, hd-media > ...)? Right, only that one stays. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Daily d-i images for i386 not being built?
Holger Wansing (2023-08-27): > Am 27. August 2023 10:12:09 MESZ schrieb Holger Wansing > : > >Hi, > > > >Am 27. August 2023 08:48:20 MESZ schrieb Holger Wansing > >: > >Ah, sorry. > >By accident I found a bug against release-notes, which documents that > >i386 d-i images will be dropped for trixie. > ><https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036358> > > > >So, sorry for the noise. > > > >OTOH I would then remove the i386 link from > ><https://www.debian.org/devel/debian-installer/index.en.html> > >now? > > I searched for a confirmation, that this was dropped from debian-cd, > but found nothing. > > Should I just remove the link nevertheless? d-i daily builds will keep i386, so don't drop that link. Links to debian-cd locations can go away. The lack of symmetry might require tweaking some wml logic/definitions. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
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
Re: Moving debootstrap to fully team maintained (drop Uploaders field)
Hi Luca, (1-month lag explained by heavy post-release burnout, which I'm fighting hard(er) today to make sure Helmut can make progress.) Luca Boccassi (2023-07-18): > So, I want to propose to move the package to exclusively team > maintained, drop the Uploaders field, leave only the Maintainer field > with the current team as-is, and ask anybody who wants to help maintain > it to join the installer-team on Salsa and just send changes as MRs, > help review/merge them, and do normal uploads, without marking them as > NMU nor feeling the need to treat them as NMUs - no need to contact > uploaders to ask permissions, delayed uploads, or anything like that. As others have already pointed out: team uploads are just fine, anyone (listed or not in Uploaders) can upload, and we're happy to add people to the team on Salsa. I suspect some people in Debian still expect to retain full “ownership” on “their” packages, but it really looks to me the project in general moved to a less territorial approach a number of years ago. As for d-i packages and debootstrap in particular, see my digression in #1049898 (https://bugs.debian.org/1049898#15). Also and again: thanks for your work on debootstrap since last year. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant 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#1042813: debian-installer: use ntp-server obtained via dhcp
Hi, IOhannes m zmölnig (2023-08-01): > one thing that has been bothering me for ages is the use of hardcoded > NTP-servers in the installer. > > Since NTP can obviously easily be abused for DDoS reflection attacks, > many ISPs block the use of arbitrary NTP-servers, and instead provide an > internal NTP server, which is typically announced via DHCP (in > environments that use DHCP for setting up networking). > > Of course my university ids among these "ISPs", which means that for the > last decade all of my Debian installations that i did on premises > stalled (for a while) when the installer tries to get the network time > (for which i think it queries *.debian.pool.ntp.org, but i haven't > actually checked). A quick look suggests 0.debian.pool.ntp.org. > it would be nice if the installer would *prefer* any NTP servers > announced via DHCP (and use the debian.pool as a fallback). It appears clock-setup could use netcfg/dhcp_ntp_servers… but netcfg seems to have stopped setting it when stateless DHCPv6 support was merged (fac74c749661da41ef4b89b89c9fd76dd42e7bc6). The 1.90 release is dated 2012 so that'd be consistent with the decade you mentioned. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#849400: debian-installer: LUKS on rootfs and boot
Jinesh Choksi (2023-07-29): > - cryptsetup luksFormat --type luks1 /dev/sda2 As mentioned in various other places, first we need to teach GRUB about argon2i(d), then we can think about enabling cryptodisk support. Also, we need a plan for the GRUB-to-Linux handover. Ugly PoC for the first part in the following branch, but the plan is to try and update libgcrypt instead. https://salsa.debian.org/kibi/grub/-/commits/luks2-argon2-v0 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1042070: installation-reports: on apt-get update; apt-get upgrade; errors appear about firmware /lib/firmware/amdgpu/ip_discovery.bin
Hi, rauf.hammad (2023-07-25): > On doing apt-get update; apt-get upgrade; warnings about missing firmware > /lib/firmware/amdgpu/* appeared. Those are really not a problem. > Excrept from console messages during: apt install <>; is given > below: > raspi-firmware: missing /boot/firmware, did you forget to mount it? > run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with > return code 1 > dpkg: error processing package initramfs-tools (--configure): > installed initramfs-tools package post-installation script subprocess > returned error exit status 1 > Errors were encountered while processing: > linux-image-6.1.0-10-amd64 > linux-image-amd64 > initramfs-tools > E: Sub-process /usr/bin/dpkg returned an error code (1) > root@peace-homes:~# The raspi-firmware thing is a grave problem instead (fixed in the 12.1 live images: raspi-firmware is no longer installed by mistake): - delete z50 hooks; - then purge the raspi-firmware package. Something like this should help: rm /etc/initramfs/post-update.d/z50-raspi-firmware rm /etc/kernel/postrm.d/z50-raspi-firmware rm /etc/kernel/postinst.d/z50-raspi-firmware dpkg -P raspi-firmware Afterwards, you should be able to configure other packages with: dpkg --configure -a And the package manager (apt, apt-get, etc.) should be happier 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#684128: src:debian-installer: allow use of binary units in disk partitioner
Control: notfound -1 226 Control: close -1 225 Hi, Thorsten Glaser (2023-07-25): > why is this bug still unfixed? https://www.debian.org/devel/debian-installer/News/2023/20230516.en.html documents a fix for #913431, which is a duplicate of this bug report. Closing this one accordingly. > In bookworm d-i, entering 512 MiB seems to be using something > entirely different, and 512 Mi gives an error “invalid size”. “Something entirely different” compared to what? The second syntax is indeed invalid. > This still makes d-i unsuitable for most partitioning. Feel free to use a different tool. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1041168: Installation of GRUB failed
Christof B. (2023-07-15): > Probably this is a duplicate. > Are there any (nightly) d-i images available to test these patches, > because otherwise (i. e. building d-i myself) this is over my head. Not yet. Speaking only for myself, I'm still in dire need of rest after the whole Bookworm release marathon over the last few months, and I haven't been able to dive into those patches just yet. They're on my list of things to look into on the short term though, including considering them for some point release. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1041168: Installation of GRUB failed
Hallo Christof, Christof B. (2023-07-15): > Boot method: USB stick (written with usbimager), UEFI > Image version: > https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso > Date: 2023-07-15 > > Machine: Dell Optiplex 9020 SFF > Partitions: see attached files hardware-summary and partman > > Base System Installation Checklist: > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > Initial boot: [O] > Detect network card:[O] > Configure network: [O] > Detect media: [O] > Load installer modules: [O] > Clock/timezone setup: [O] > User/password setup:[O] > Detect hard drives: [O] > Partition hard drives: [O] > Install base system:[O] > Install tasks: [O] > Install boot loader:[E] > Overall install:[E] > > Comments/Problems: > > I did a pretty minimal installation with the base system but no graphical > environmend. I used the "Guided - use entire disk and set up encrypted LVM" > partitioning scheme. Then I chose the harddisk sdb instead of USB stick sda. > Installing GRUB (more precisely: configuring shim-signed:amd64) failed > with a message complaining that GRUB could not be installed on dummy > (execution of "grub install dummy" failed). Thanks for sharing all those logs in advance. syslog has: Jul 15 11:00:47 grub-installer: grub-install: error: cannot copy `/usr/lib/shim/shimx64.efi.signed' to `/boot/efi/EFI/debian/shimx64.efi': No space left on device. And the ESP is close to 500M, so ENOSPC is very surprising. Any chance you could check what's inside/what filled 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#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
Hi Michael, Cyril Brulebois (2023-06-28): > Control: reassign -1 busybox-udeb 1:1.36.1-3 […] > With a local build, confirmed -3 is buggy, and that reverting only > busybox-udeb to -1 is sufficient to restore syslog support in the > installer. > > Reassigning there; the GRUB thing can be filed separately once we have > actual information via syslog. A fix would be appreciated, we've got reports piling up about things we have no logs for. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1040712: installation-reports Debian 12
Salut Jacques, Jacques Rubin (2023-07-09): > # > Comments/Problems: Problems with package installation (alien, gdm3, > default-jre, etc...). Example of installing alien with the command line: $ > sudo apt-get install alien . Problem with the linux-image-6.1.0-10-amd64 > package when the installed package is linux-image-6.1.0-9-amd64. > # > Parameter setting for linux-image-6.1.0-10-amd64 (6.1.37-1) ... > /etc/kernel/postinst.d/initramfs-tools: > update-initramfs: Generating /boot/initrd.img-6.1.0-10-amd64 > I: The initramfs will attempt to resume from /dev/sda3 > I: (UUID=eafc18cf-23e3-43e6-8bce-6784d60e3a92) > I: Set the RESUME variable to override this. > raspi-firmware: missing /boot/firmware, did you forget to mount it? > run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with > return code 1 > run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 > dpkg: erreur de traitement du paquet linux-image-6.1.0-10-amd64 > (--configure) : > le sous-processus paquet linux-image-6.1.0-10-amd64 script > post-installation installé a renvoyé un état de sortie d'erreur 1 I suppose this is an installation done from the live image? In that case that's a known bug that will be fixed for 12.1 (to be released in 2 weeks). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#987503:
Richard Hartmann (2023-07-09): > As such, the current behavior is a breaking change for laptop users and > leaves them with a broken system; when they realize why hibernation does > not work they need to reinstall the system or reformat by hand with all > the data moving that entails. > > The fact that we're stuck with this for a whole stable release cycle > makes things even worse. I read your message as if that was some kind of recent regression. For the avoidance of doubt, the relevant partman-auto code is present in buster, bullseye, and bookworm. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bookworm Installer and Hibernate
Putting the list back in the loop, and quoting in full. Rainer Dorsch (2023-07-09): > Am Sonntag, 9. Juli 2023, 16:55:49 CEST schrieben Sie: > > Rainer Dorsch (2023-07-09): > > > Many thanks for the quick and very helpful response. I also followed > > > up there, indeed it is sad that not even a simple workaround to > > > mitigate the problem made it into bookworm :-/ > > > > Don't allocate the whole space at the LVM step, then expand the swap > > using some of that free space? → Simple workaround. > You can do that, if you realize that the recommended setup for beginners > does not produce a reasonable partition scheme and if you are expert > enough to understand that swap partition size and hibernate are > connected. 100% of the beginners I know, would probably not be able to > make that connection. There's no definitive answer as to what “the recommended setup for beginners” would be. > What for most of them probably would work, is a question if they want to > use hibernate or if they install for a laptop/desktop or a server. > Probably desktop/laptop should be default since the admin of a Debian > server is probably not a beginner anymore either. But this would give an > easy option for him. Maybe, but that's totally orthogonal to the point I was making. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bookworm Installer and Hibernate
Rainer Dorsch (2023-07-09): > Many thanks for the quick and very helpful response. I also followed > up there, indeed it is sad that not even a simple workaround to > mitigate the problem made it into bookworm :-/ Don't allocate the whole space at the LVM step, then expand the swap using some of that free space? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm
Pascal Hambourg (2023-07-04): > On 04/07/2023 at 03:24, Cyril Brulebois wrote: > > It's fine to have an EFI partition inside a RAID array. One “just” needs > > to pass --no-nvram and to register it manually. That's not something > > that's achievable via d-i at the moment though (unless recent changes in > > grub-installer, near the end of the bookworm release cycle) made it > > possible indirectly. > > Any pointer to these recent changes ? kibi@tokyo:~/debian-installer/packages/grub-installer (master=)$ git log -p -Gno-nvram → 0007c1296f202fff8e84640d4e1737502690ca46 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm
Samuel Thibault (2023-07-04): > As pointed out in #1040266, when using guided partitioning inside a > raid, partman-auto creates an EFI partition there, and then grub-install > fails because it can't register it. This error could also happen if a > user creates by hand an EFI partition inside the raid by mistake. Just > like partman-efi warns when no EFI partition is defined, it should also > warn when an EFI partition is defined inside a raid or lvm (thus > actually unreachable from EFI). It's fine to have an EFI partition inside a RAID array. One “just” needs to pass --no-nvram and to register it manually. That's not something that's achievable via d-i at the moment though (unless recent changes in grub-installer, near the end of the bookworm release cycle) made it possible indirectly. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
