Re: Adding systemd-boot support in debian-installer
On Mon, 3 Jun 2024 at 20:07, John Paul Adrian Glaubitz wrote: > > Hello, > > On Mon, 2024-06-03 at 03:46 +0200, Cyril Brulebois wrote: > > ACK on the .mrconfig part, but I think this misses an addition to > > packages/po/packages_list (to be confirmed with Holger Wansing). Might > > be best to get rid of the fuzzy parts still mentioning nobootloader > > beforehand though. Just something that needs taken care of at some > > point. > > Hmm? Did we get rid of supporting the installation of systems without > a bootloader? I found this very handy when installing on systems that > don't support standard bootloaders or when installing inside QEMU and > then booting kernel and initrd from the command line. > > Is there anything broken in nobootloader? No, they were referring to some copypasta in the new package - I started by copying the nobootloader sources because I'm lazy AF, but forgot to sed s/nobootloader/systemd-boot-installer/ one PO file.
Re: Adding systemd-boot support in debian-installer
On Mon, 3 Jun 2024 at 16:11, Holger Wansing wrote: > > Hi, > > Am 3. Juni 2024 11:23:57 MESZ schrieb Luca Boccassi : > >On Mon, 3 Jun 2024 at 02:47, Cyril Brulebois wrote: > >> Luca Boccassi (2024-06-03): > >> > >> > https://salsa.debian.org/installer-team/d-i/-/merge_requests/17 > >> > >> TIL: builscript. > >> > >> ACK on the .mrconfig part, but I think this misses an addition to > >> packages/po/packages_list (to be confirmed with Holger Wansing). Might > >> be best to get rid of the fuzzy parts still mentioning nobootloader > >> beforehand though. Just something that needs taken care of at some > >> point. > > > >Ah missed that packages_list - fixed in the latest push > > As kibi mentioned, the left-overs from nobootloader should be cleaned up in > the templates file, so > s/nobootloader/systemd-boot-installer/ Whoops, forgot to fixup that file, thanks > and according to > <https://d-i.debian.org/doc/i18n-guide/ch01s04.html#sublevels> > I would prefer the new message to be sublevel 3, so > s/# :sl1:/# :sl3:/ > > before pushing this one. > > Otherwise fine I think Sounds good, will push to main shortly and upload as soon as the package has cleared NEW. Thanks for the reviews.
Re: Adding systemd-boot support in debian-installer
On Mon, 3 Jun 2024 at 02:47, Cyril Brulebois wrote: > > Hi, > > Luca Boccassi (2024-06-03): > > I've created a udeb that adds an expert menu item to allow choosing > > systemd-boot (in the NEW queue): > > > > https://salsa.debian.org/installer-team/systemd-boot-installer > > The `Architecture: all` in control vs the 64-bit EFI logic in the script > seems odd at first glance. Looking at other *-installer, they tend to > have a restricted arch list in most cases. > > I have no strong feelings either way, just something that caught my eye > when I first looked into the repository. Given it's only shipping a script I thought it was supposed to be 'all', and also it would avoid the need to conditionalize dependencies. I can change it if needed, just let me know. > > A couple of PRs for minimal support: > > > > https://salsa.debian.org/installer-team/debian-installer-utils/-/merge_requests/12 > > OK, spotted the todo in the script when I spotted the upload; a > versioned dependency will do the trick once the d-i-utils part is > reviewed/merged/uploaded. > > > https://salsa.debian.org/installer-team/d-i/-/merge_requests/17 > > TIL: builscript. > > ACK on the .mrconfig part, but I think this misses an addition to > packages/po/packages_list (to be confirmed with Holger Wansing). Might > be best to get rid of the fuzzy parts still mentioning nobootloader > beforehand though. Just something that needs taken care of at some > point. Ah missed that packages_list - fixed in the latest push > > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/46 > > > > It does not show up in non-expert mode, which is fine for now, > > especially as secure boot signing is not yet available. > > > > After it's been in the testing image like this for a while, and after > > we have secure boot integration finished up, would it be ok to show a > > question in the non-expert install too? GRUB would still be the > > default of course, the question would select it by default, and allow > > to switch to sd-boot if chosen. Where would be the best place to add > > this? > > I have close to no knowledge about the details around menu items at the > moment. Looking at the good old GRUB vs. LILO duo, I see they had > different numbers (7400 for GRUB, 7500 for LILO), not sure whether we > should have the same numbers for grub-installer and for > systemd-boot-installer. Yeah I just copied it without giving it much thought, if it needs to be changed let me know what is the right number and I'll fix it. > I'm also not sure whether we should offer a choice between those two > different booting methods in the course of a normal (non-expert) > install. > > > Finally, I'm Cc-ing GRUB people to let them know. Sure we can leave it as-is until there's at least some request to have it, expert mode is fine for now.
Re: Bug#1072501: ITP: systemd-boot-installer -- Install systemd-boot on a hard disk
On Mon, 3 Jun 2024 at 02:22, Cyril Brulebois wrote: > > Hi, > > Luca Boccassi (2024-06-03): > > Package: wnpp > > Severity: wishlist > > Owner: Luca Boccassi > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: systemd-boot-installer > > Version : 0.1 > > Upstream Author : Luca Boccassi > > * URL : > > https://salsa.debian.org/installer-team/systemd-boot-installer > > * License : GPL-2.0-or-later > > Programming Lang: shell > > Description : debian-installer component to install systemd-boot > > as the bootloader > > Could we have some kind of heads-up via X-D-Cc to debian-boot@ for such > things, please? Discovering we have a new package under our namespace > via a “Processing” mail from ftpmaster is awkward. Sorry, since it needs to go through NEW I uploaded at the same time as I sent this: https://lists.debian.org/debian-boot/2024/06/msg00013.html so I thought it would be enough heads-up.
Adding systemd-boot support in debian-installer
Hi, I've created a udeb that adds an expert menu item to allow choosing systemd-boot (in the NEW queue): https://salsa.debian.org/installer-team/systemd-boot-installer A couple of PRs for minimal support: https://salsa.debian.org/installer-team/debian-installer-utils/-/merge_requests/12 https://salsa.debian.org/installer-team/d-i/-/merge_requests/17 https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/46 It does not show up in non-expert mode, which is fine for now, especially as secure boot signing is not yet available. After it's been in the testing image like this for a while, and after we have secure boot integration finished up, would it be ok to show a question in the non-expert install too? GRUB would still be the default of course, the question would select it by default, and allow to switch to sd-boot if chosen. Where would be the best place to add this? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
On Sun, 2 Jun 2024 at 20:04, Cyril Brulebois wrote: > > Luca Boccassi (2024-05-27): > > I'll upload a D-I fix that adds x-initrd.attach to crypttab by default > > shortly. Yes you can ignore the "unknown option" message, as the > > Debian-specific initramfs-tools scripts do not know about it, but > > that's fine, it's for the shutdown path anyway. And the finalize > > messages can also be ignored. > > Having a cryptsetup warning about an unknown option on the very first > line seen by users after the bootloader step doesn't feel appropriate > at all to me. Telling users to just ignore it neither. > > For the record, on a fresh install, that means: > > cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'x-initrd.attach' > Please unlock disk sda5_crypt: _ > > Looping in the cryptsetup team. See #1072058
Bug#1072092: piuparts: switch default tmpdir to /var/tmp/
Control: affects -1 - piuparts debos vmdb2 Control: reassign -1 piuparts On Tue, 28 May 2024 13:14:00 +0200 Helmut Grohne wrote: > Control: reassign -1 debootstrap > Control: affects -1 + piuparts debos vmdb2 > > On Tue, May 28, 2024 at 12:08:37PM +0100, Luca Boccassi wrote: > > When piuparts runs debootstrap, it is pointed to the default -- tmpdir, > > which absent any configuration or env var is /tmp/, which is now (since > > systemd 256~rc3-3) a tmpfs, which as it is expected it is mounted with > > noudev for security reasons, but debootstrap doesn't like that as it > > wants to create fresh node files. > > This is a problem in debootstrap. debootstrap should refrain from > creating device nodes when doing so is not possible. Most consumers of > debootstrap bind mount /dev already. Reassigning. Feel free to work on that if you like, but it is unrelated > > Please make piuparts --tmpdir default to /var/tmp if nothing is set, to > > avoid this issue. > > Please don't as that would make reduce piuparts performance to crap. Currently /tmp is on the same filesystem as /var/tmp, so there are zero performance differences. It's just a default, you can change it as you see fit if you have some special local setup. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
On Fri, 30 Sep 2022 23:34:46 -0300 ng wrote: > Now, I think is worth mentioning that: > > Adding 'x-initrd.attach' to the device holding root at /etc/crypttab, > does in fact solve systemd-cryptsetup@vda5_crypt.service failing. But, > on reboots and shutdowns I still get 'Failed to finalize DM devices, > ignoring'. I wonder if it can be ignored. Using dracut doesn't change > this behavior. > > And on my other machine, I get at boot: "cryptsetup: WARNING: > vda5_crypt: ignoring unknown option 'x-initrd.attach.". Even though the > option does work as expected, this I suppose because I'm using > initramfs-tools/busybox this time? I still haven't tried with dracut > since the warning seems a false positive. I'll upload a D-I fix that adds x-initrd.attach to crypttab by default shortly. Yes you can ignore the "unknown option" message, as the Debian-specific initramfs-tools scripts do not know about it, but that's fine, it's for the shutdown path anyway. And the finalize messages can also be ignored. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required
On Tue, 7 May 2024 at 00:18, Cyril Brulebois wrote: > > Luca Boccassi (2024-05-06): > > Pending at: > > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8 > > I'm not sure how often we change template types, but I suppose this > particular instance (error → boolean) makes sense and isn't problematic. > > Please mention “GRUB” (instead of “grub”) for consistency with upstream > and the rest of d-i though. (I know this is very minor but better catch > that early to avoid another l10n round later on.) Sure, fixed, thanks
Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required
Control: tags -1 patch On Sun, 08 Oct 2023 17:57:01 -0400 Nicholas D Steeves wrote: > Jonathan Hettwer writes: > > > Package: partman-crypto > > Version: 121 > > Severity: normal > > Tags: d-i > > X-Debbugs-Cc: j24...@gmail.com > > > > Dear Maintainer, > > > > The `crypto_check_mountpoints` script prevents you from setting up an > > encrypted root filesystem without an additional unencrypted /boot > > filesystem. > > While this may be a requirement for e.g. grub2, it is not > > necessarily required when not using grub2 but using UKIs to build EFI > > executables that can directly mount the encrypted root filesystem. > > While UKIs aren't currently supported, I would still expect partman-crypto > > to let me partition an encrypted root filesystem without separate /boot > > filesystem, at least after having ignored the warnings or in combination > > with the `nobootloader` udeb. > > Quick note: systemd-boot works with kernel images + initramfs, without > UKI. After the systemd-boot menu, the user is prompted for the master > LUKS password, as usual, and I use the derived key script to then > unlocks a couple LUKS volumes. No LVM, no /boot. It seems to work > well, but yeah, it's not possible to do this with fresh install (I > manually migrated an old installation to new hardware). Pending at: https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8 Test iso built by CI can be found here: https://salsa.debian.org/bluca/partman-crypto/-/jobs/5694502/artifacts/browse/debian/output/ Any help testing would be welcome -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
Control: tags -1 pending On Thu, 11 Jan 2024 19:55:18 + Luca Boccassi wrote: > On Thu, 11 Jan 2024 at 14:22, Holger Levsen wrote: > > > > On Thu, Jan 11, 2024 at 11:56:28AM +, Luca Boccassi wrote: > > [...] > > > How about if I changed the Description from: > > > Self-encrypting disk (opal with LUKS2) > > > to something like: > > > Firmware-backed self-encrypting disk (vendor-implemented OPAL with > > > LUKS2) > > > Would that suffice? If not, do you have an alternative wording in mind? > > > > sounds much better (and sufficient, for all the reasons you mentioned) > > to me, thanks! > > Thank you for the feedback, MR on Salsa is updated as described. Now that cryptsetup 2.7.0 is in testing, I'll team upload later tonight -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069787: debootstrap: autopkgtest fails since t64 migration
On Wed, 24 Apr 2024 19:16:51 +0100 Mark Hindley wrote: > Package: debootstrap > Version: 1.0.134 > Severity: important > Tags: patch > > > Dear Maintainer, > > The debian/tests/debian-testing autopkgtest has been broken on 64bit archs by > the t64 transition in trixie. Specifically the test includes gnupg as an > additional package. Gnupg depends on gpg-agent which depends on > libnpth0. However, in trixie, libnpth0 is now provided by libnpth0t64 which > debootstrap doesn't handle. > > I suggest changing the test to include gpgv which avoids the t64 transition > whilst providing similar functional coverage. > > Patch attached. Please send a merge request on Salsa -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
On Mon, 15 Jan 2024 at 12:28, Holger Levsen wrote: > > On Mon, Jan 15, 2024 at 10:46:14AM +, Luca Boccassi wrote: > > > huh, if there's a bug in the firmware to accidently store the encryption > > > key on the drive in plaintext, it doesn't cost anything extra. > > Sure, and if there's a bug in your CPU to accidentally reveal all > > kernel secrets to any unprivileged userspace process via sidechannels > > it doesn't cost anything extra either. Doesn't really mean much though > > for this case. > > it's an unneeded additional attack vector. That depends on the threat model. It's not for mine, and most others too. > > We aren't though - and the category includes me too of course. Nobody > > is going to spend $100 million dollars to hardware-backdoor my > > computer > > yes, because several dozens are available much cheaper already. [citation needed]
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
On Mon, 15 Jan 2024 at 10:22, Holger Levsen wrote: > > On Sun, Jan 14, 2024 at 08:37:30PM +, Luca Boccassi wrote: > > Most definitely wrong. If your threat model is "hardware vendor will > > spend hundreds of millions of dollars to get at me" then your cpu > > vendor, memory controller vendor, etc etc can do that too, so you > > better not use this nor any other type of hardware acceleration, ever. > > huh, if there's a bug in the firmware to accidently store the encryption > key on the drive in plaintext, it doesn't cost anything extra. Sure, and if there's a bug in your CPU to accidentally reveal all kernel secrets to any unprivileged userspace process via sidechannels it doesn't cost anything extra either. Doesn't really mean much though for this case. > > The good news is, if you are writing on a Debian bug tracker then you > > are not even remotely interesting enough for any hardware manufacturer > > to spend even a tiny fraction of that, so it's all good. > > huh. the Snowden papers explicitly showed that sysadmins and developers > are being targeted, to go after "the real targets". > > I originally didn't want to comment on this bug further, as I am ok > with the current wording but saying that people contributing to Debian > are "not even remotely interesting" is just wrong. > > (And the other framing about contributors with maybe minor contributions > is also rather wrong, but for other reasons.) We aren't though - and the category includes me too of course. Nobody is going to spend $100 million dollars to hardware-backdoor my computer, as I am not a Prime Minister or a billion-dollar-corp CEO. It's just not a realistic threat model for me. In the average user's threat model there are things several orders of magnitude more important to worry about, like "is my browser up to date" and "is this email legitimate or phishing". And if for some absurd reason some Prime Minister somewhere is really installing Debian - good news! They can just use the defaults, problem solved. In the meanwhile, I pay for fast hardware acceleration and I would like to use fast hardware acceleration, and I'm pretty sure that's also true for many others.
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
On Sun, 14 Jan 2024 at 19:30, Pascal Hambourg wrote: > > On 11/01/2024 at 12:56, Luca Boccassi wrote: > > > > Yes it is a firmware feature, so it depends on the hardware, and in all > > drives I know of that will be the case, yes. From that point of view, > > to me it doesn't seem that far away from dm-crypt using the CPU's AES- > > NI to actually encrypt/decrypt data, or anything else implemented in > > hardware/firmware that the installer now supports out of the box with > > non-free-firmware being enabled by default. If I am trusting Intel to > > handle my data in their wifi firmware, and in their CPU microcode, and > > memory controllers, and whatever else is on my hardware, it seems > > strange to start worrying once the line is crossed into the NVME > > firmware... > > Correct me if I'm wrong, but aren't CPUs and wifi controllers > pass-through devices which do not persistently store encryption keys or > data and whose encrypted output can be inspected to check if they are > doing the right thing so that you do not have to blindly trust them ? > > Self-encrypted drives persistently store encryption keys and data. Can > their encrypted output reliably be inspected ? Can they be trusted if > the manufacturer implemented some hidden mechanism allowing to recover > the data when customers lost their password (like BIOS manufacturers do) > which will be leaked sooner or later ? Most definitely wrong. If your threat model is "hardware vendor will spend hundreds of millions of dollars to get at me" then your cpu vendor, memory controller vendor, etc etc can do that too, so you better not use this nor any other type of hardware acceleration, ever. The good news is, if you are writing on a Debian bug tracker then you are not even remotely interesting enough for any hardware manufacturer to spend even a tiny fraction of that, so it's all good.
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
On Thu, 11 Jan 2024 at 14:22, Holger Levsen wrote: > > On Thu, Jan 11, 2024 at 11:56:28AM +, Luca Boccassi wrote: > [...] > > How about if I changed the Description from: > > Self-encrypting disk (opal with LUKS2) > > to something like: > > Firmware-backed self-encrypting disk (vendor-implemented OPAL with > > LUKS2) > > Would that suffice? If not, do you have an alternative wording in mind? > > sounds much better (and sufficient, for all the reasons you mentioned) > to me, thanks! Thank you for the feedback, MR on Salsa is updated as described.
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
On Thu, 11 Jan 2024 08:46:53 + Holger Levsen wrote: > On Thu, Jan 11, 2024 at 01:47:59AM +0000, Luca Boccassi wrote: > > cryptsetup 2.7.0, currently in experimental, added support for self > > encrypting drives using the OPAL functionality as the encryption layer > > (managed by the kernel, not by the TCG utilities), both in standalone > [...] > > I have added support for these new options in partman-crypto, MR on > > Salsa is open: > > > > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/7 > > > > The new options are shown only in the manual partitioning mode, and > > only if the kernel, cryptsetup and the device all support this > > functionality, otherwise they are hidden. A factory reset option for > > the disk is also exposed. A small utility to call the required ioctl to > > check for support on a given disk is added too. > > doesnt OPAL functionality rely on the implementation on the hdd/sdd > and thus on non-free software? If so, I'd suggest to warn that it's > impossible to review the security of this. Yes it is a firmware feature, so it depends on the hardware, and in all drives I know of that will be the case, yes. From that point of view, to me it doesn't seem that far away from dm-crypt using the CPU's AES- NI to actually encrypt/decrypt data, or anything else implemented in hardware/firmware that the installer now supports out of the box with non-free-firmware being enabled by default. If I am trusting Intel to handle my data in their wifi firmware, and in their CPU microcode, and memory controllers, and whatever else is on my hardware, it seems strange to start worrying once the line is crossed into the NVME firmware... > also see https://wiki.archlinux.org/title/Self-encrypting_drives#Disadvantages The first point is true, however I'm pretty sure it's irrelevant for the threat model of the vast majority of people. If the threat model does include such expensive and sophisticated attacks, then the nested mode can be used, so there's a double layer of dm-crypt + firmware- backed encryption. That's the most visible option of the two in the installer. Or just dm-crypt of course - that's still the default in both 'guided' and 'manual' mode. The second point is no longer true, as there is native kernel support, and the kernel holds the key just like it does for dm-crypt. It affected older setups that didn't use the kernel interface, but only the TCG userspace utilities that talked directly to the drive via the NVME protocol. The third point is true for any hardware, including CPUs and their microcodes, so it seems to me it doesn't add anything new. > I'm not against adding this functionality per se, I just think it should > come with really big warning labels. How about if I changed the Description from: Self-encrypting disk (opal with LUKS2) to something like: Firmware-backed self-encrypting disk (vendor-implemented OPAL with LUKS2) Would that suffice? If not, do you have an alternative wording in mind? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
Source: partman-crypto Tags: patch Dear Maintainer(s), cryptsetup 2.7.0, currently in experimental, added support for self encrypting drives using the OPAL functionality as the encryption layer (managed by the kernel, not by the TCG utilities), both in standalone mode and with a nested dm-crypt layer. Key management is done using LUKS2, just like with dm-crypt, so that all existing functionality works out of the box (tokens, passphrases, keyfiles, etc). A standard LUKS2 header is used, which sits unencrypted on the disk as with dm- crypt, and the nested range is then encrypted using OPAL's functionality. I have added support for these new options in partman-crypto, MR on Salsa is open: https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/7 The new options are shown only in the manual partitioning mode, and only if the kernel, cryptsetup and the device all support this functionality, otherwise they are hidden. A factory reset option for the disk is also exposed. A small utility to call the required ioctl to check for support on a given disk is added too. I have tested this with a Kingston drive and it seems to work as expected. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1039142: busybox: ships sysv-init script without systemd unit
On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev wrote: > Control: tag -1 + help > > On Sun, 25 Jun 2023 23:20:24 +0100 bl...@debian.org wrote: > > Package: busybox > > Severity: important > > User: bl...@debian.org > > Usertags: missing-systemd-service > > > > Dear Maintainer(s), > > > > busybox has been flagged by Lintian as shipping a sysv-init script > > without a corresponding systemd unit file. The default init system in > > Debian is systemd, and so far this worked because a transitional > > sysv-init-to-unit generator was shipped by systemd. This is in the > > process of being deprecated and will be removed by the time Trixie > > ships, so the remaining packages that ship init scripts without > > systemd units will stop working. > > > > There are various advantages to using native units, for example the > > legacy generator cannot tell the different between a oneshot service > > and a long running daemon. Also, sanboxing and security features > > become available for services. For more information, consult the > > systemd documentation: > > https://www.freedesktop.org/software/systemd/man/systemd.unit.html > > > > You can find the Lintian warning here: > > > > https://lintian.debian.org/sources/busybox > > This site can't be found. But it's ok. Yeah things around Lintian publishing have changed since these bugs have been filed > So in current state, only udhcpd lacks systemd file. So I tried to > provide one. The initscript for udhcpd checks for UDHCPD_ENABLED=yes/no > in /etc/default/udhcpd and does nothing if it is not enabled, which > is the default. Since there's no way in systemd to check for that > (well, there is, with ExecConditional, but it ugly at best), I thought > to ship udhcpd.service not enabled by default. Except it doesn't > work. > > With just dh_installsystemd --no-enable, it is still started. > With dh_installsystemd --no-enable --no-start, it is started > as well, - apparently because initscript is started. Also, > with --no-enable --no-start, it is not restarted on upgrades > if enabled locally. > > After doing several iterations, I decided to abandon this attempt, - > it just does not work, and I've no time to fight with the tools. > > If someone has a working recipe for all this madness, please > share a patch for d/rules. > > Tagging with "help" for now. Could you please share a branch or a patch with your attempt? What you tried should work, but it's hard to say without looking at the implementation in details. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1055066: usrmerge: Cannot update to version 38 on sbuild
Control: fixed -1 1.0.133 Control: fixed -1 1.0.128+nmu2+deb12u1 Control: fixed -1 1.0.123+deb11u2 Control: close -1 On Tue, 31 Oct 2023 at 08:02, John Paul Adrian Glaubitz wrote: > > Hello! > > I am not sure whether this issue has been fixed. > > We're seeing this issue on buildds and porterboxes on Debian Ports, > regenerating the chroots fails: > > dpkg: warning: ignoring pre-dependency problem! > Preparing to unpack .../tar_1.34+dfsg-1.2_ppc64.deb ... > Unpacking tar (1.34+dfsg-1.2) ... > Selecting previously unselected package usr-is-merged. > Preparing to unpack .../usr-is-merged_38_all.deb ... > > > ** > * > * The usr-is-merged package cannot be installed because this system does > * not have a merged /usr. > * > * Please install the usrmerge package to convert this system to merged-/usr. > * > * For more information please read https://wiki.debian.org/UsrMerge. > * > ** > > > dpkg: error processing archive > /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): > new usr-is-merged package pre-installation script subprocess returned error > exit status 1 > Selecting previously unselected package util-linux. > dpkg: regarding .../util-linux_2.39.2-5_ppc64.deb containing util-linux, > pre-dependency problem: > util-linux pre-depends on libblkid1 (>= 2.37.2) > libblkid1:ppc64 is unpacked, but has never been configured. > > Could it be that debootstrap needs to be switched to enabled usrmerge by > default? The buildds have already been updated with a new config ~3 weeks ago: https://lists.debian.org/debian-devel/2023/10/msg00019.html https://lists.debian.org/debian-devel/2023/10/msg00024.html Are the ports buildds managed differently? If so, they either need that change, or to take debootstrap from proposed-updates where the defaults have been switched. There is nothing actionable in debootstrap, as the relevant changes have already been made and uploaded (pending the next stable release to make it out of p-u).
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
On Wed, 18 Oct 2023 at 18:36, Johannes Schauer Marin Rodrigues wrote: > > Hi Luca, > > Quoting Luca Boccassi (2023-10-18 19:17:40) > > On Wed, 18 Oct 2023 at 18:04, Johannes Schauer Marin Rodrigues > > wrote: > > > > > > Hi, > > > > > > Quoting Santiago Vila (2023-10-12 17:56:04) > > > > Johannes has asked the RMs in this thread: > > > > > > > > https://lists.debian.org/debian-release/2023/10/msg00425.html > > > > > > > > if they are ready to consider the bugs as RC. I believe it would be > > > > better > > > > if we can make the bugs "factually" RC by uploading the fixed > > > > debootstrap first. > > > > > > I do not have a strong opinion on what should happen first but in that > > > thread, > > > Holger and Sam also support the idea to first upload debootstrap. > > > > We can do an upload, but note that it won't have any effect on package > > builds, given the buildds use stable/oldstable - and this is not > > material for p-u, given the effect. Of course it will affect local > > builds, in case they are done via debootstrap, from testing/unstable > > users. > > Yes, I'm aware of that. But I think having this in unstable/testing already > will help because several maintainers replied to the bugs saying they are > unable to reproduce it. Having debootstrap with this change in > unstable/testing > will make this a) much easier and b) convince people that they need to include > this change or otherwise their package will really FTBFS on the buildds with > the trixie release. > > And this should probably go without saying but just to make sure: if this > change causes any weird bugs, please message me so that I can supply a fix. Thanks - I'll merge and do an upload over the weekend then
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
On Wed, 18 Oct 2023 at 18:04, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Santiago Vila (2023-10-12 17:56:04) > > Johannes has asked the RMs in this thread: > > > > https://lists.debian.org/debian-release/2023/10/msg00425.html > > > > if they are ready to consider the bugs as RC. I believe it would be better > > if we can make the bugs "factually" RC by uploading the fixed debootstrap > > first. > > I do not have a strong opinion on what should happen first but in that thread, > Holger and Sam also support the idea to first upload debootstrap. We can do an upload, but note that it won't have any effect on package builds, given the buildds use stable/oldstable - and this is not material for p-u, given the effect. Of course it will affect local builds, in case they are done via debootstrap, from testing/unstable users.
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
On Fri, 29 Sept 2023 at 00:42, Johannes Schauer Marin Rodrigues wrote: > > Hi Julien, > > thank you for your quick reply! > > Quoting Julien Cristau (2023-09-28 17:49:51) > > I guess more than mixing two different things I disagree that that is > > debootstrap's responsibility, and so I disagree that that is a valid bug. > > In > > my view it's more important for debootstrap to reliably be able to create > > chroots than some sort of philosophical purity about what is included in > > said > > chroot. Package priorities are how the archive tells debootstrap which > > packages to install, and so since I don't see your (A) as a bug, I'm saying > > if there's a bug it's (B) and belongs with the archive. > > I agree that debootstrap's reliability to create chroots is supremely > important. But do you see a bug with my change that makes it unreliable? It > changes what the chroot includes yes, but it does so in a reliable way unless > I > missed something? Given the list of affected packages is short (and it's all about tzdata IIRC), how about we wait until that list is down to zero (and if you have time, maybe you could help with that?), and then merge this change? That way we don't add instability, and fix the issue at the same time.
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
On Sat, 23 Sept 2023 at 19:13, Johannes Schauer Marin Rodrigues wrote: > > Hi all, > > On Sun, 25 Jun 2017 06:01:13 +0200 Johannes Schauer wrote: > > Quoting Cyril Brulebois (2017-06-24 20:23:25) > > > Julien Cristau (2016-09-12): > > > > This is a transient situation because some Essential packages' > > > > dependencies changed. I'd consider this a bug in the archive, not in > > > > debootstrap. > > > Any reasons to keep this bug report open then? Seen no objections, so I'm > > > tempted to close it. > > > > But... the buildd variant still explicitly (and not only implicitly through > > dependencies of essential:yes packages) installs Priority:required packages, > > no? > > as we are at the beginning of the trixie development cycle, I have opened a > merge request against debootstrap which avoids installing priority:required > packages with the buildd variant: > > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/106#note_430035 > > I've put Ansgar and Julien in CC as they were opposed to this change. > > I'm putting Luca and Guillem in CC who wrote in favour of this change also in > policy bug #1029831. > > Santiago is in CC as the driver of the mass bug filing for source packages > that > fail to build in a chroot environment with just Essential:yes and > build-essential installed. > > According to the last MBF from December 2022 and January 2023, there are 13 > source packages that would FTBFS after this change because they are missing an > explicit build dependency on tzdata or mount. > > As part of the thread starting at > 9b40f6f2-4942-acfc-2f9c-4668f05d9...@debian.org a number of arguments were > made > for and against this change. I still believe that the arguments for this > change > weigh stronger than those against it and thus I filed that merge request > above. > > Luca, as the debootstrap maintainer, what are your thoughts? Sounds fine by me if people are ok with it, impact is minimal and fix is very simple and sounds correct from a conceptual point of view.
Re: Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
On Sat, 23 Sept 2023 at 14:29, Simon McVittie wrote: > > On Wed, 30 Aug 2023 at 16:27:12 +0100, Simon McVittie wrote: > > [ Reason ] > > Part of the transition to merged-/usr, and more specifically, allowing > > us to stop shipping files in trixie whose physical path on disk does > > not match their path in the dpkg database due to directory aliasing. > > > > This change needs to be in bookworm (and bullseye, and maybe buster) > > before that process can continue, because official buildds run debootstrap > > from stable (or older). > > > > I also took the opportunity to backport changes that make the autopkgtests > > pass. > > > > [ Impact ] > > If not accepted, trixie will continue to be stuck in a > > mostly-but-not-entirely merged-/usr limbo, with the moratorium from #1035831 > > remaining in place. > > I'm aware that we're getting close to the deadline for 12.2 and 11.8, > so I've uploaded the proposed version to bookworm-proposed-updates for > easier testing and review. Luca: the proposed version and a signed tag > are available from my fork on salsa (I am not able to push to the d-i > repository for debootstrap). I uploaded with dgit, so the git tree and > the .dsc have been verified to be identical. > > If this version is not accepted for whatever reason, then I think we > should treat version 1.0.128+nmu2+deb12u1 as having been used, and skip > ahead to 1.0.128+nmu2+deb12u2 for any subsequent bookworm update. > (And if there is a problem with having this version in bookworm-pu for > whatever reason, I'm happy to upload a +deb12u2 that is identical to > 1.0.128+nmu2 except for the changelog.) Thank you, pushed both branches. 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? 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 Thanks!
Re: Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
On Tue, 05 Sep 2023 20:34:02 +0100 Luca Boccassi wrote: > On Tue, 5 Sep 2023 17:33:27 +0100 Jonathan Wiltshire > wrote: > > Control: tag -1 moreinfo > > > > On Tue, Sep 05, 2023 at 10:30:09AM +0100, Luca Boccassi wrote: > > > On Wed, 30 Aug 2023 16:27:12 +0100 Simon McVittie > > > wrote: > > > > Part of the transition to merged-/usr, and more specifically, > > > allowing > > > > us to stop shipping files in trixie whose physical path on disk > does > > > > not match their path in the dpkg database due to directory > aliasing. > > > > > > > > This change needs to be in bookworm (and bullseye, and maybe > buster) > > > > before that process can continue, because official buildds run > > > debootstrap > > > > from stable (or older). > > > > > > > > I also took the opportunity to backport changes that make the > > > autopkgtests > > > > pass. > > > > > > I think it would be nice to let this bake in proposed-updates for a > > > while before 12.2 is released, just to be extra-extra-safe. Any > chance > > > for a quick review so we can upload it? > > > > It will need a d-i ack as a pre-requisite. > > Thanks Jonathan - d-i team, would it be possible for a quick review of > this and #1025708 please? This was tested with d-i as such: > > > Philip Hands built a d-i mini.iso with the proposed version, and it > seems to have installed GNOME successfully under openQA. Hi, The clock for 12.2 is ticking fast. Is there any way I can help in order to make progress? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
On Tue, 5 Sep 2023 17:33:27 +0100 Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > On Tue, Sep 05, 2023 at 10:30:09AM +0100, Luca Boccassi wrote: > > On Wed, 30 Aug 2023 16:27:12 +0100 Simon McVittie > > wrote: > > > Part of the transition to merged-/usr, and more specifically, > > allowing > > > us to stop shipping files in trixie whose physical path on disk does > > > not match their path in the dpkg database due to directory aliasing. > > > > > > This change needs to be in bookworm (and bullseye, and maybe buster) > > > before that process can continue, because official buildds run > > debootstrap > > > from stable (or older). > > > > > > I also took the opportunity to backport changes that make the > > autopkgtests > > > pass. > > > > I think it would be nice to let this bake in proposed-updates for a > > while before 12.2 is released, just to be extra-extra-safe. Any chance > > for a quick review so we can upload it? > > It will need a d-i ack as a pre-requisite. Thanks Jonathan - d-i team, would it be possible for a quick review of this and #1025708 please? This was tested with d-i as such: > Philip Hands built a d-i mini.iso with the proposed version, and it seems to have installed GNOME successfully under openQA. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Moving debootstrap to fully team maintained (drop Uploaders field)
On Wed, 16 Aug 2023 at 17:14, Cyril Brulebois wrote: > > 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. Ok, I've added myself to uploaders as suggested here and in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049898#15 https://lists.debian.org/debian-boot/2023/07/msg00147.html I'll keep doing reviews of MRs and do minor cleanups and maintenance where I can. Kind regards, Luca Boccassi
Re: Re: Moving debootstrap to fully team maintained (drop Uploaders field)
> > It's great that it works for you and for some teams, but it doesn't > > work for me and for others. For me, if someone else is listed in > > Uploaders, then it's their property and I'm not touching it unless > > absolutely necessary. > > Look, you have an interpretation of Uploaders that is wildly > different > from how others in the Project perceive it, and IMO in outright > conflict > with the Policy. That is not a sound basis for the change you > propose. > > Regardless, why not solve the problem by simply by adding yourself to > Uploaders, as others have suggested? Or ask one of the current > Uploaders > to do it, if that is more agreeable to you? That doesn't solve the problem, given I explicitly do _not_ want to claim ownership of the package for myself. Just provide occasional contributions given it's under-mantained at the moment. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Re: Moving debootstrap to fully team maintained (drop Uploaders field)
> > I am aware of that, that's not the point I'm trying to make. The > point > > is that having anyone explicitly named assigns ownership and is a > > barrier for others to contribute. > > FWIW, I never understood it that way, at all. > > In the context of a team, "Uploaders" just lets me know about people > who > consider themselves to be among the people regularly working on this > package, so a good contact point. > > But if Maintainers is a team, and I'm in that team, I'm free to > upload, > whether in Uploaders or not. > > And if I'm a frequent uploader, I add myself to Uploaders. > > A good example is the Debian Python Team, where the policy [1] > explicitly states that "[anyone in the Team] can commit to the Git > repository and upload as needed". It's great that it works for you and for some teams, but it doesn't work for me and for others. For me, if someone else is listed in Uploaders, then it's their property and I'm not touching it unless absolutely necessary. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Re: Moving debootstrap to fully team maintained (drop Uploaders field)
On Wed, 19 Jul 2023 at 01:18, Charles Plessy wrote: > > Le Wed, Jul 19, 2023 at 12:00:20AM +0100, Luca Boccassi a écrit : > > > > Because the intention is not to claim the package for myself (far from > > it! I already maintain too many...), but to open it up for uploads to > > anybody who is part of the Salsa team (or wants to join it), removing > > any barriers. > > Hi Luca, > > `dch --team` is your friend :) https://wiki.debian.org/TeamUpload I am aware of that, that's not the point I'm trying to make. The point is that having anyone explicitly named assigns ownership and is a barrier for others to contribute. > There must be at least one personal email address in either Maintainer > or Uploader > (https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer), > so if the current Uploaders agree, replacing them would be a service to > the team, not a claim of ownership! Is that a technical reason? IE, would dak or other tools refuse it if not? It would seem strange, given it can't possibly know what's "personal" and what's a team. Policy is just policy and can be changed if it's not adequate anymore. Kind regards, Luca Boccassi
Re: Re: Moving debootstrap to fully team maintained (drop Uploaders field)
> > Thoughts? > > why don't you just add yourself and Dimitri to Uploaders: and be > done? :) Because the intention is not to claim the package for myself (far from it! I already maintain too many...), but to open it up for uploads to anybody who is part of the Salsa team (or wants to join it), removing any barriers. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Moving debootstrap to fully team maintained (drop Uploaders field)
Hello installer team, Let me start by prefacing that this is not about criticizing individuals, who I all thank for their past work, but merely find the best way to maintain debootstrap. Debootstrap is a bit under-maintained in the past few years, it seems to me. debootstrap's d/control lists the Maintainer as the "Debian Install System Team" - that is great. There are also 3 Uploaders listed: Colin Watson, Steve McIntyre and Hideki Yamane. The last contribution and upload by Colin were in 2021 and 2015, respectively, by Steve was it was 2016 and 2017, and Hideki and 2021 and 2020. Again, not a critique, just data! You have to go back to 2021 to find an upload by somebody other than myself or Dimitri. Still, I've marked all those uploads as NMUs, because that's how they feel, given there are other uploaders listed. 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. Again, I really can't stress this enough - dropping the Uploaders is not because I think the uploaders have done anything wrong, or as punishment, or anything else, but simply and solely to remove all barriers stopping or hindering anybody else from doing team maintenance. Thoughts? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sun, 16 Jul 2023 12:54:35 +0100 Simon McVittie wrote: > On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote: > > In the meanwhile, I'll immediately revert the sabotage. > > Both of you, please don't turn this into an NMU war in the archive: > that doesn't benefit anyone. I would have preferred it if Adam had not > immediately uploaded a 0-day revert, but preserving the status quo from > bookworm is not the worst state to be in while we discuss this. > > If Adam's concerns about this change are valid, then we should address > them, either by doing something different in debootstrap or by reporting > bugs against affected packages. > > If Adam's concerns about this change turn out to be unfounded, then we > should reinstate my change (as NMU'd by Luca) in a calm and considered > way, and all we will have lost is a few days of progress and a few bytes > of changelog. I have already reverted the hostile and unwarranted NMU before you replied. And that is the right thing to do: the correct procedure when there is a suspicion that a change breaks something is not to do a 0- day revert without telling anybody, it's to file a bug _AND_ CC the involved people, and wait until there is an answer, while providing evidence of the actual issue. As you already correctly noted, there is zero evidence of any issue presented in this bug, and the stated 'reason' is wrong anyway: debootstrap from unstable/testing is NOT used to build packages for unstable/testing. This would have been trivial to find out for the reporter. So as with normal procedure, the change will stand where it is, and if there is evidence of any actual issues it can be revisited later. Blocking other people's progress with work that has the consensus of both the project and the CTTE and force them to spend days or weeks or months proving negatives is not an acceptable procedure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sat, 15 Jul 2023 18:27:24 +0200 Adam Borowski wrote: > Package: debootstrap > Version: 1.0.128+nmu3 > Severity: grave > > bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the > aliased-dirs scheme. While it's currently the default scheme for non-buildd > systems, it is both not supported by dpkg (with no solution in sight), but > is also likely to produce packages that are explicitely forbidden by a > recent CTTE ruling that disallows moving files between directories aliased > by the current usrmerge scheme. > > Quoting the still unsolving issues is pointless (you can read about them > in massive threads in a number of places) as bluca seems to be ignoring > them completely. > > But, what matters here is the CTTE ruling in #1035831 -- for the time > being, > packages must not move files between locations affected by the > aliasing. If there is somebody who's ignoring things, that would be yourself, given this change has been not only been explicitly requested, but even provided _BY_ the CTTE, as you would have easily found out if you actually went and checked: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93 http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-07-11-17.58.log.html Debian Community Team, Adam is once again sabotaging the CTTE's work with hostile NMUs, could you please intervene? Thank you. In the meanwhile, I'll immediately revert the sabotage. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Mon, 10 Jul 2023 17:14:48 +0100 Steve McIntyre
wrote:
> Hi, and thanks for your bug report!
>
> On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote:
> >Package: installation-reports
> >Severity: serious
> >Tags: d-i
> >Justification: https://wiki.debian.org/MachineId
> >
>
> ...
>
> >After installation was finished and the system has been restarted
the
> >files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not
linked
> >in any way (no soft or hardlink) and the ID inside the files differ
> >from each other.
>
> I've confirmed this bug just now, doing a clean installation from the
> 12.0.0 amd64 netinst.
As a wild guess, maybe the split of src:dbus into multiple packages
affected the order in which the postinsts run, and now systemd's runs
first and creates /etc/machine-id, and then dbus-daemon's runs and
creates /var/lib/dbus/machine-id.
There is a tmpfiles.d shipped by dbus-daemon that creates
/var/lib/dbus/machine-id as a symlink to /etc/machine-id if it exists,
but this snippet runs _after_ the dbus-uuidgen so effectively it is
always a no-op on package install:
$ cat /var/lib/dpkg/info/dbus-daemon.postinst
#!/bin/sh
set -e
if [ "$1" = configure ]; then
# This is idempotent, so it's OK to do every time. The system bus' init
# script does this anyway, but you also have to do this before a session
# bus will work on non-systemd systems, so we do this here for the
# benefit of people starting a temporary session bus in a chroot.
mkdir -p "${DPKG_ROOT:-/}var/lib/dbus"
dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id"
fi
# Automatically added by dh_installtmpfiles/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -x "$(command -v systemd-tmpfiles)" ]; then
systemd-tmpfiles ${DPKG_ROOT:+--root="$DPKG_ROOT"} --create
dbus.conf >/dev/null || true
fi
fi
# End automatically added section
It seems to me a safe way to fix this and do the right thing is to swap
the #DEBHELPER# token and the manual dbus-uuidgen block in dbus-
daemon's postinst. Then on systemd systems the tmpfiles will win and on
other systems dbus-uuidgen will do its job.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1030850: Please stop creating /etc/timezone
On Wed, 08 Feb 2023 13:03:35 +0100 Michael Biebl wrote: > Source: tzsetup > Version: 1:0.118 > Severity: normal > X-Debbugs-Cc: 822...@bugs.debian.org > > Hi, > > regarding the latest changes in tzdata, which stopped creating > /etc/timezone [1], it was recommended that tzsetup should be updated > accordingly [2]. As requested by Benjamin, created bugs against packages that appear to rely on /etc/timezone (ie, they mention /etc/timezone but not /etc/localtime as found on codesearch): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038833 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038834 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038835 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038836 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038837 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038838 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038839 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038840 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038841 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038842 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038843 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038844 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038845 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038846 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038847 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038848 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038849 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038850 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038851 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038852 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
s > > [1] https://tracker.debian.org/pkg/netplan.io > [2] > https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/ Yeah I think it would be nice to do some experiments there, at least starting with networkd and eventually considering netplan as an additional step on top - thanks for volunteering :-P Ultimately it seems to me that the defaults should be driven by tasklets rather than priority - ie, make ifupdown and dhcpd-base optional, have ifupdown depend on dhcpd-base so that if a user wants to use that stack they can just pull in ifupdown and it works as expected, and have the desktop task pull in NetworkManager. Then we can decide what the default stack for servers should be after some experimenting. Kind regards, Luca Boccassi
Bug#1038157: debootstrap: W: Failure while unpacking required packages. This will be attempted
Control: severity -1 minor Control: fixed -1 1.0.127+nmu1 On Fri, 16 Jun 2023 09:44:39 +0200 Jean-Marc LACROIX wrote: > ansible@hn-asusgl752-400:~$ df |grep dns-400 > /dev/mapper/vg_vn_dns_400-lv_rootfs 117331 >6 108438 1% /var/lib/lxc/vn-dns-400/rootfs > /dev/mapper/vg_vn_dns_400-lv_usr 675672 >8 626352 1% /var/lib/lxc/vn-dns-400/rootfs/usr > /dev/mapper/vg_vn_dns_400-lv_var 105431 >5 97399 1% /var/lib/lxc/vn-dns-400/rootfs/var > /dev/mapper/vg_vn_dns_400-lv_tmp 137161 >2 126838 1% /var/lib/lxc/vn-dns-400/rootfs/tmp > /dev/mapper/vg_vn_dns_400-lv_home117331 >2 108442 1% /var/lib/lxc/vn-dns-400/rootfs/home > /dev/mapper/vg_vn_dns_400-lv_var_log 192699 >2 178361 1% /var/lib/lxc/vn-dns-400/rootfs/var/log > /dev/mapper/vg_vn_dns_400-lv_var_lib 125250 >3 115786 1% /var/lib/lxc/vn-dns-400/rootfs/var/lib > /dev/mapper/vg_vn_dns_400-lv_var_cache 469458 >2 440580 1% /var/lib/lxc/vn-dns-400/rootfs/var/cache > /dev/mapper/vg_vn_dns_400-lv_var_lib_apt 920648 >8 856540 1% /var/lib/lxc/vn-dns-400/rootfs/var/lib/apt This is a strange setup, why is the rootfs under a different volume than /usr? That's not really supported. Anyway, this should be fixed in a newer version, try installing debootstrap from bullseye-backports. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later
On Thu, 23 Feb 2023 at 22:53, Santiago Vila wrote: > > El 23/2/23 a las 22:26, Luca Boccassi escribió: > > On Thu, 23 Feb 2023 at 20:50, Santiago Vila wrote: > >> The buildds already did the switch several months ago. > > > > Wait, what? Specific changes were made to debootstrap in order to > > allow the buildd machines to stay un-merged, as the CTTE wanted, > > Can you elaborate on that? What you say sounds as something that > could be said two years ago before the release of bullseye, i.e. > newly installed systems have usr-merge by default but we keep > building packages on not usr-merged chroots. > > > When did the switch happen, and how? > > I believe it was sometime in 2022-11, but I can't tell for sure. I believe it > happened because I sometimes monitor debian-bugs-rc and at some point bugs > about packages which FTBFS on usr-merged systems became serious. > > Sorry not to be more precise. I hope somebody who knows better can answer. > > ( In case it's confirmed that the buildds are already using usr-merge for > bookworm > and sid, would you agree that the debootstrap program in bookworm should do > the > same by default? ) Please see: https://lists.debian.org/debian-ctte/2022/09/msg5.html
Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later
On Thu, 23 Feb 2023 at 20:50, Santiago Vila wrote: > > El 23/2/23 a las 21:38, Luca Boccassi escribió: > > It's too soon for this. I think the right time will be the first point > > release of Bookworm - at that point we can get the buildds to switch > > too. But the release should be built in the current default as per > > CTTE's instructions. > > The buildds already did the switch several months ago. Wait, what? Specific changes were made to debootstrap in order to allow the buildd machines to stay un-merged, as the CTTE wanted, until after bookworm's release. When did the switch happen, and how?
Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later
On Thu, 23 Feb 2023 20:00:42 +0100 Santiago Vila wrote: > Package: debootstrap > Version: 1.0.128+nmu2 > Severity: important > Tags: patch > > Dear maintainer: > > Because Debian has decided that bookworm will have > usr-merge by default even for building packages, > I would expect usr-merge to be enabled by default > in all cases, including when using the buildd profile. > > Currently, such thing does not happen. > > I think the attached patch would fix this > (but I've not tested it). > > A better approach would be to select --usr-merge > in the buildd profile when appropriate (i.e. bookworm > and above). (How feasible would this be?) > > I am aware that the proposed patch (but not the "better approach") > may force some people to do some things differently. > > However, let's compare the two scenarios: > > A) If the patch is applied, then once that bookworm becomes stable: > > - Those who want to build packages for stable the official way > do not have to do anything special. I think this is the category > of users that should be better supported. > > - Those still running bullseye who want to build packages for > bullseye (using debootstrap from bullseye) do not have to do > anything special. > > - Only people who want to build packages for bullseye from > bookworm would have to add --no-usr-merge by hand, and only > when using the buildd profile. I think this is a special case > and having to add an option by hand for such special case would > not be a big deal. > > B) If the patch is not applied, then once that bookworm becomes stable: > > - Those who want to build packages for stable the official way > should add --usr-merge by hand when calling debootstrap. > > This option is *undocumented* in "debootstrap --help" (!). > > Also, failure to add the --usr-merge option may result in packages > being misbuilt, or even failing to build at all. And this would > happen when building packages from stable to be installed in a > stable system. > > - Those still running bullseye who want to build packages for > bullseye (using debootstrap from bullseye) do not have to do > anything special. > > - Those who want to build packages for bullseye from bookworm > would not have to do anything special. It's too soon for this. I think the right time will be the first point release of Bookworm - at that point we can get the buildds to switch too. But the release should be built in the current default as per CTTE's instructions. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Moving firmware packages from non-free to non-free-firmware
On Tue, 17 Jan 2023 at 20:49, Cyril Brulebois wrote: > > Hi folks, > > First off: sorry I haven't been able to work on this sooner. For some > context, you can check the notes for the meeting I had with Steve > after the GR result was published: > https://lists.debian.org/debian-boot/2022/10/msg00044.html > > This mail is about moving packages from non-free to non-free-firmware, > which will make it possible to install firmware packages (and configure > apt to keep them up-to-date) from non-free-firmware without enabling > non-free as a whole. > > For this first round, I've checked on amd64/unstable which packages > ship files under /lib/firmware, then excluded some of them, and worked > on the rest. (I'll need to check other archs for possible arch-specific > firmware packages, but I must confess our current thinking is making > the random joe/jane user experience on x86 systems as easy as possible, > then care about less obvious targets later.) > > So far I've excluded: > - libfishcamp1 and libsbig4 since those are library packages that >also happen to ship some hexdumps; I don't think they would qualify >for non-free-firmware (maybe if the hexdumps would be split out in >their own packages, but I'm not sure that's worth it). > - firmware-nvidia-gsp, firmware-nvidia-tesla-gsp, and >nvidia-tesla-470-kernel-support, from nvidia-graphics-drivers* >source packages; it's been a while since my X days, but I don't >think firmware packages would be useful on their own, one would >need to install/build X drivers from non-free as well? > > (but maintainers are in copy anyway, just in case I missed something.) > > The remaining source packages: > - amd64-microcode > - atmel-firmware > - bluez-firmware > - dahdi-firmware > - firmware-ast > - firmware-nonfree > - firmware-sof > - intel-microcode > - rtl8723bt-firmware > - zd1211-firmware > > I've filed merge requests on Salsa for 8 of them, and bug reports for > the remaining 2 (hosted on an external cgit for one, no VCS for the > other). > > I'd be happy for maintainers to tell me whether the merge requests are > sufficient, or whether they'd like bug reports filed as well. I'm happy > to take care of uploading and pushing commits/tags to the repository if > that helps getting packages quicker (in which case, just make sure to > grant “kibi” push access). > > I also plan on getting in touch with ftpmaster to get the whole lot > reviewed in a timely manner, and overrides adjusted. > > Please let us know if you have any questions. > > Thanks for your help! > > > Merge requests: > - amd64-microcode: >https://salsa.debian.org/hmh/amd64-microcode/-/merge_requests/3 > - atmel-firmware: > > https://salsa.debian.org/rfinnie/atmel-firmware-pkg-debian/-/merge_requests/1 > - bluez-firmware: >https://salsa.debian.org/bluetooth-team/bluez-firmware/-/merge_requests/3 > - dahdi-firmware: >https://salsa.debian.org/pkg-voip-team/dahdi-firmware/-/merge_requests/2 > - firmware-nonfree: >https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/48 > - firmware-sof: >https://salsa.debian.org/mpearson/firmware-sof/-/merge_requests/6 > - intel-microcode: >https://salsa.debian.org/hmh/intel-microcode/-/merge_requests/2 > - zd1211-firmware: >https://salsa.debian.org/debian/zd1211-firmware/-/merge_requests/1 > > Bug reports: > - firmware-ast: >https://bugs.debian.org/1029110 > - rtl8723bt-firmware >https://bugs.debian.org/1029111 > > > Cheers, Hi, I think the open source nvidia kernel drivers need firmware-nvidia-gsp/firmware-nvidia-tesla-gsp. Also I think there are efforts in progress to use the nvidia firmwares with nouveau: https://lwn.net/Articles/910343/ I don't know if these are good enough reasons to include those for now - it would certainly not benefit end users at this stage, and mostly be for the benefit of developers and tinkerers. In case a future kernel version's nouveau can use the gsp though, being able to use it from bookworm-backports would be nice I think. Kind regards, Luca Boccassi
Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-boot@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
An improvement to reduce the number of dependencies pulled down by the
usr-merged debootstrapped image has been available in unstable,
bookworm and bullseye-backports for a while. I'd like to make this
improvement available in bullseye as well, as it saves ~50MB on a
minbase image. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025657
I have tested this locally and seems to work as expected.
Debdiff attached. It also enables usrmerge on hurd.
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.123+deb11u1/debian/changelog debootstrap-1.0.123+deb11u2/debian/changelog
--- debootstrap-1.0.123+deb11u1/debian/changelog 2022-07-28 12:04:03.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/changelog 2022-12-07 15:31:02.0 +
@@ -1,3 +1,19 @@
+debootstrap (1.0.123+deb11u2) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Samuel Thibault ]
+ * Enable usrmerge on hurd-i386 too
+
+ [ Ansgar ]
+ * debootstrap: optionally exclude specific dependencies
+ * debian-common: exclude usrmerge when installing usr-is-merged
+
+ [ Tianon Gravi ]
+ * Apply "EXCLUDE_DEPENDENCY" during "resolve_deps" (Closes: #1025657)
+
+ -- Luca Boccassi Wed, 07 Dec 2022 15:31:02 +
+
debootstrap (1.0.123+deb11u1) bullseye; urgency=medium
* Non-maintainer upload.
diff -Nru debootstrap-1.0.123+deb11u1/debootstrap debootstrap-1.0.123+deb11u2/debootstrap
--- debootstrap-1.0.123+deb11u1/debootstrap 2022-07-28 11:55:11.0 +0100
+++ debootstrap-1.0.123+deb11u2/debootstrap 2022-12-07 15:30:03.0 +
@@ -41,6 +41,7 @@
UNPACK_TARBALL=""
ADDITIONAL=""
EXCLUDE=""
+EXCLUDE_DEPENDENCY=""
VERBOSE=""
CERTIFICATE=""
CHECKCERTIF=""
diff -Nru debootstrap-1.0.123+deb11u1/functions debootstrap-1.0.123+deb11u2/functions
--- debootstrap-1.0.123+deb11u1/functions 2022-07-28 11:55:40.0 +0100
+++ debootstrap-1.0.123+deb11u2/functions 2022-12-07 15:30:03.0 +
@@ -1361,7 +1361,6 @@
local link_dir
case $ARCH in
- hurd-*) return 0 ;;
amd64) link_dir="lib32 lib64 libx32" ;;
i386) link_dir="lib64 libx32" ;;
mips|mipsel)
@@ -1555,6 +1554,9 @@
NEWPKGS="$NEWPKGS $("$PKGDETAILS" GETDEPS "$pkgdest" $PKGS)"
done
done
+ if [ -n "${EXCLUDE_DEPENDENCY:-}" ]; then
+ NEWPKGS="$(without "$NEWPKGS" "$EXCLUDE_DEPENDENCY")"
+ fi
PKGS=$(echo "$PKGS $NEWPKGS" | tr ' ' '\n' | sort | uniq)
local REALPKGS=""
for s in $SUITE $EXTRA_SUITES; do
diff -Nru debootstrap-1.0.123+deb11u1/scripts/debian-common debootstrap-1.0.123+deb11u2/scripts/debian-common
--- debootstrap-1.0.123+deb11u1/scripts/debian-common 2022-07-28 11:55:40.0 +0100
+++ debootstrap-1.0.123+deb11u2/scripts/debian-common 2022-12-07 15:30:03.0 +
@@ -52,6 +52,7 @@
;;
*)
required="$required usr-is-merged"
+ EXCLUDE_DEPENDENCY="$EXCLUDE_DEPENDENCY usrmerge"
;;
esac
}
signature.asc
Description: This is a digitally signed message part
Re: debootstrap_1.0.128+nmu1 uploaded to DELAYED/1 (was: Re: debootstrap_1.0.128_source.changes ACCEPTED into unstable)
Looks like there's another issue, the new autopkgtest hardcoded 'amd64' for the download so it fails on other architectures. I've NMU'ed to DELAYED/1 with a fix that I've tested on i386: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/84 On Mon, 17 Oct 2022 at 12:14, Dimitri John Ledkov wrote: > > Ack, will look into it > > On Mon, 17 Oct 2022, 10:50 Luca Boccassi, wrote: >> >> Hi, >> >> I have uploaded debootstrap_1.0.128+nmu1 to DELAYED/1, as 1.0.128 added >> a new autopkgtest that fails in Debian because we still don't have >> /usr/sbin in the default PATH (I guess it wasn't noticed in Ubuntu >> because that's not an issue there). >> The autopkgtest failure was holding back migration to testing. >> >> MR: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/82 >> >> -- >> Kind regards, >> Luca Boccassi
debootstrap_1.0.128+nmu1 uploaded to DELAYED/1 (was: Re: debootstrap_1.0.128_source.changes ACCEPTED into unstable)
Hi, I have uploaded debootstrap_1.0.128+nmu1 to DELAYED/1, as 1.0.128 added a new autopkgtest that fails in Debian because we still don't have /usr/sbin in the default PATH (I guess it wasn't noticed in Ubuntu because that's not an issue there). The autopkgtest failure was holding back migration to testing. MR: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/82 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: debootstrap/1.0.127+nmu1 uploaded to DELAYED/2
On Sat, 2022-09-24 at 14:25 +0100, Luca Boccassi wrote: > Hi, > > I've just NMU'ed debootstrap/1.0.127+nmu1 to DELAYED/2, to include two > fixes for merged-usr: enabling it on hurd-i386 [0], and avoiding to > install both usr-is-merged and usrmerge in sid/bookworm chroots (this > was reviewed and acked by henrich) [1]. This allows avoiding the extra > dependencies of usrmerge from being installed. > > If there are any concerns please let me know and I'll cancel it. > > Thanks! > > [0] > https://salsa.debian.org/installer-team/debootstrap/-/commit/77ee0943351d59a169ef1b8428184d23d9cc90f9 > [1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/76 This version has migrated to testing, no bug reports were raised, so going to upload to bullseye-backports tomorrow. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
debootstrap/1.0.127+nmu1 uploaded to DELAYED/2
Hi, I've just NMU'ed debootstrap/1.0.127+nmu1 to DELAYED/2, to include two fixes for merged-usr: enabling it on hurd-i386 [0], and avoiding to install both usr-is-merged and usrmerge in sid/bookworm chroots (this was reviewed and acked by henrich) [1]. This allows avoiding the extra dependencies of usrmerge from being installed. If there are any concerns please let me know and I'll cancel it. Thanks! [0] https://salsa.debian.org/installer-team/debootstrap/-/commit/77ee0943351d59a169ef1b8428184d23d9cc90f9 [1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/76 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1020426: usrmerge fails configure: Can't locate autodie.pm in @INC [...] at /usr/lib/usrmerge/convert-etc-shells line 13
Control: tags -1 pending On Wed, 2022-09-21 at 16:47 +0200, Thomas Deutschmann wrote: > Package: usrmerge > Version: 30 > Severity: important > > Dear Maintainer, > > I was trying to install Debian bookworm using > firmware-testing-amd64-netinst.iso from 2022-09-21 14:22 > (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/daily-builds/sid_d-i/current/amd64/iso-cd/). > > However, debootstrap failed: > > > Sep 21 14:20:16 debootstrap: /usr/sbin/debootstrap --components=main > > --debian-installer --resolve-deps --no-check-gpg bookworm /target > > file:///cdrom/ > > Sep 21 14:20:21 debootstrap: dpkg: warning: parsing file > > '/var/lib/dpkg/status' near line 5 package 'dpkg': > > Sep 21 14:20:21 debootstrap: missing 'Description' field > > Sep 21 14:20:21 debootstrap: dpkg: warning: parsing file > > '/var/lib/dpkg/status' near line 5 package 'dpkg': > > Sep 21 14:20:21 debootstrap: missing 'Architecture' field > > Sep 21 14:20:21 debootstrap: Selecting previously unselected package > > base-passwd. > > Sep 21 14:20:21 debootstrap: (Reading database ... 0 files and directories > > currently installed.) > > Sep 21 14:20:21 debootstrap: Preparing to unpack > > .../base-passwd_3.6.0_amd64.deb ... > > Sep 21 14:20:21 debootstrap: Unpacking base-passwd (3.6.0) ... > > Sep 21 14:20:21 debootstrap: Setting up base-passwd (3.6.0) ... > > Sep 21 14:20:21 debootstrap: dpkg: base-passwd: dependency problems, but > > configuring anyway as you requested: > > Sep 21 14:20:21 debootstrap: base-passwd depends on libc6 (>= 2.34); > > however: > > Sep 21 14:20:21 debootstrap: Package libc6 is not installed. > > Sep 21 14:20:21 debootstrap: base-passwd depends on libdebconfclient0 (>= > > 0.145); however: > > Sep 21 14:20:21 debootstrap: Package libdebconfclient0 is not installed. > > Sep 21 14:20:21 debootstrap: base-passwd depends on libselinux1 (>= 3.1~); > > however: > > Sep 21 14:20:21 debootstrap: Package libselinux1 is not installed. > > Sep 21 14:20:21 debootstrap: > > Sep 21 14:20:21 debootstrap: dpkg: warning: parsing file > > '/var/lib/dpkg/status' near line 24 package 'dpkg': > > Sep 21 14:20:21 debootstrap: missing 'Description' field > > Sep 21 14:20:21 debootstrap: dpkg: warning: parsing file > > '/var/lib/dpkg/status' near line 24 package 'dpkg': > > Sep 21 14:20:21 debootstrap: missing 'Architecture' field > > Sep 21 14:20:21 debootstrap: Selecting previously unselected package > > base-files. > > Sep 21 14:20:21 debootstrap: dpkg: regarding .../base-files_12.2_amd64.deb > > containing base-files, pre-dependency problem: > > Sep 21 14:20:21 debootstrap: base-files pre-depends on awk > > Sep 21 14:20:21 debootstrap: awk is not installed. > > Sep 21 14:20:21 debootstrap: > > Sep 21 14:20:21 debootstrap: dpkg: warning: ignoring pre-dependency problem! > > Sep 21 14:20:21 debootstrap: (Reading database ... 41 files and directories > > currently installed.) > > Sep 21 14:20:21 debootstrap: Preparing to unpack > > .../base-files_12.2_amd64.deb ... > > Sep 21 14:20:21 debootstrap: Unpacking base-files (12.2) ... > > Sep 21 14:20:22 debootstrap: Setting up base-files (12.2) ... > > Sep 21 14:20:22 debootstrap: dpkg: base-files: dependency problems, but > > configuring anyway as you requested: > > Sep 21 14:20:22 debootstrap: base-files depends on awk; however: > > Sep 21 14:20:22 debootstrap: Package awk is not installed. > > Sep 21 14:20:22 debootstrap: > > Sep 21 14:20:22 debootstrap: dpkg: warning: parsing file > > '/var/lib/dpkg/status' near line 51 package 'dpkg': > > Sep 21 14:20:22 debootstrap: missing 'Description' field > > Sep 21 14:20:22 debootstrap: dpkg: warning: parsing file > > '/var/lib/dpkg/status' near line 51 package 'dpkg': > > Sep 21 14:20:22 debootstrap: missing 'Architecture' field > > Sep 21 14:20:22 debootstrap: dpkg: regarding > > .../archives/dpkg_1.21.9_amd64.deb containing dpkg, pre-dependency problem: > > Sep 21 14:20:22 debootstrap: dpkg pre-depends on libbz2-1.0 > > Sep 21 14:20:22 debootstrap: libbz2-1.0 is not installed. > > Sep 21 14:20:22 debootstrap: > > Sep 21 14:20:22 debootstrap: dpkg: warning: ignoring pre-dependency problem! > > Sep 21 14:20:22 debootstrap: dpkg: regarding > > .../archives/dpkg_1.21.9_amd64.deb containing dpkg, pre-dependency problem: > > Sep 21 14:20:22 debootstrap: dpkg pre-depends on libc6 (>= 2.33) > > Sep 21 14:20:22 debootstrap: libc6 is not installed. > > Sep 21 14:20:22 debootstrap: > > Sep 21 14:20:22 debootstrap: dpkg: warning: ignoring pre-dependency problem! > > Sep 21 14:20:22 debootstrap: dpkg: regarding > > .../archives/dpkg_1.21.9_amd64.deb containing dpkg, pre-dependency problem: > > Sep 21 14:20:22 debootstrap: dpkg pre-depends on liblzma5 (>= 5.2.2) > > Sep 21 14:20:22 debootstrap: liblzma5 is not installed. > > Sep 21 14:20:22 debootstrap: > > Sep 21 14:20:22 debootstrap: dpkg: warning: ignoring pre-dependency problem! > > Sep 21 14:20:22
Bug#926699: Transition to usrmerge has started
Control: tags -1 patch
On Mon, 2022-09-19 at 13:35 +0200, Andreas Beckmann wrote:
> On 19/09/2022 12.07, Marco d'Itri wrote:
> > The main issue can only be fixed in the libc packages (which would
> > be
> > wonderful, because then we could stop creating the biarch links and
> > directories on all systems).
>
> on amd64:
>
> # apt-file search -x '^/lib32' | cut -d: -f1 | sort -u
> lib32ncurses6
> lib32ncursesw6
> lib32readline8
> lib32tinfo6
> libc6-i386
>
> # apt-file search -x '^/libx32' | cut -d: -f1 | sort -u
> libc6-x32
>
> # apt-file search -x '^/lib64' | cut -d: -f1 | sort -u
> libc6
>
> # apt-cache show lib32ncurses6 lib32ncursesw6 lib32readline8
> lib32tinfo6
> > grep -E 'Package|Depends'
> Package: lib32ncurses6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32ncursesw6
> Depends: lib32tinfo6 (= 6.3+20220423-2), libc6-i386 (>= 2.7)
> Package: lib32readline8
> Depends: readline-common, lib32tinfo6 (>= 6), libc6-i386 (>= 2.33)
> Package: lib32tinfo6
> Depends: libc6-i386 (>= 2.33)
>
> Just brainstorming:
> If we declare libc6-i386 as the "owner" of /lib32, lib32* as "users"
> of
> /lib32 and add libc6-i386.preinst that
> * handles the creation of /lib32 if missing, either as directory or
> symlink, depending of the state of /lib
> * errors out (or converts) if /lib32 is a directory but /lib is a
> symlink
> and then have all "users" of /lib32 Pre-Depends: libc6-i386 (>= xxx)
> (might need a debhelper patch to populate ${misc:Pre-Depends})
> and lintian check for such a pre-depends ...
> (I'm not sure if a plain Depends is sufficient to ensure
> libc6-i386.preinst gets run in all cases before some lib32* gets
> unpacked ...)
> Same for /libx32, except that there are no users that might need
> updating.
>
> How likely is it that a user of /lib32 gets unpacked during the early
> bootstrapping phase? If that is not going to happen, the symlink
> creation for /libxx could be deferred to the installation of
> libc6-{i386,x32} and no "unowned" /libxx symlinks would be lingering
> around after boostrapping.
>
> On i386 we have
>
> # apt-file search -x ^/lib64 | cut -d: -f1 | sort -u
> lib64gcc-s1
> lib64ncurses6
> lib64ncursesw6
> lib64readline8
> lib64tinfo6
> libc6-amd64
>
> # apt-file search -x ^/libx32 | cut -d: -f1 | sort -u
> libc6-x32
>
> (and no /lib32)
>
> Didn't check other architectures.
>
> Interesting could also be the installation of libc6:amd64 on a i386
> system as that will create /lib64 ... yes, that will leave you with a
> /lib64 directory if no symlink pre-exists.
This MR implements the suggestion from Marco from earlier in this
thread [0]:
https://salsa.debian.org/glibc-team/glibc/-/merge_requests/11
Tested with libc6-i386, seems to do the expected thing. We can remove
it then after everything has moved to install only to /usr, hopefully
in Trixie.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699#77
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#926699: Transition to usrmerge has started
Control: tags -1 -moreinfo
On Mon, 2022-09-19 at 11:23 +0100, Luca Boccassi wrote:
> Control: tags -1 moreinfo
>
> On Mon, 2022-09-19 at 11:29 +0200, Andreas Beckmann wrote:
> > Shouldn't that fail in such a broken environment?
> >
> > # apt-get install --reinstall usr-is-merged
> > Reading package lists... Done
> > Building dependency tree... Done
> > Reading state information... Done
> > 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not
> > upgraded.
> > Need to get 0 B/4732 B of archives.
> > After this operation, 0 B of additional disk space will be used.
> > debconf: unable to initialize frontend: Dialog
> > debconf: (No usable dialog-like program is installed, so the dialog
> > based frontend cannot be used. at
> > /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 1.)
> > debconf: falling back to frontend: Readline
> > (Reading database ... 15056 files and directories currently
> > installed.)
> > Preparing to unpack .../usr-is-merged_30+nmu1_all.deb ...
> > Unpacking usr-is-merged (30+nmu1) over (30+nmu1) ...
> > Setting up usr-is-merged (30+nmu1) ...
> > # ls -lad /lib{,32,64,x32}
> > lrwxrwxrwx 1 root root 7 Sep 19 00:35 /lib -> usr/lib
> > drwxr-xr-x 2 root root 440 Sep 19 08:59 /lib32
> > lrwxrwxrwx 1 root root 9 Sep 19 00:35 /lib64 -> usr/lib64
> > lrwxrwxrwx 1 root root 10 Sep 19 00:35 /libx32 -> usr/libx32
>
> It should, but I cannot reproduce this? Can you share the exact steps
> you used to create the chroot?
>
> # ls -lad /lib{,32,64,x32}
> lrwxrwxrwx 1 root root 7 Sep 19 10:20 /lib -> usr/lib
> drwxr-xr-x 2 root root 4096 Sep 19 10:20 /lib32
> lrwxrwxrwx 1 root root 9 Sep 19 10:20 /lib64 -> usr/lib64
> lrwxrwxrwx 1 root root 10 Sep 19 10:20 /libx32 -> usr/libx32
> # sh -x usrmerge/debian/usr-is-merged.preinst install
> + fail_if_unmerged
> + is_merged
> + directories=/bin /sbin /lib
> + [ -e /bin ]
> + readlink -f /bin
> + [ /usr/bin = /usr/bin ]
> + [ -e /sbin ]
> + readlink -f /sbin
> + [ /usr/sbin = /usr/sbin ]
> + [ -e /lib ]
> + readlink -f /lib
> + [ /usr/lib = /usr/lib ]
> + arch_directories=/lib64 /lib32 /libo32 /libx32
> + [ -e /lib64 ]
> + readlink -f /lib64
> + [ -e /lib32 ]
> + readlink -f /lib32
> + return 1
> + [ -e /etc/unsupported-skip-usrmerge-conversion ]
> + cat
>
>
> *
> *
> *
> * The usr-is-merged package cannot be installed because this system
> does
> * not have a merged /usr.
> *
> * Please install the usrmerge package to convert this system to
> merged-/usr.
> *
> * For more information please read https://wiki.debian.org/UsrMerge.
> *
> *****
> *
>
>
> + exit 1
Never mind, the issue is that on 'apt install --reinstall' it's an
upgrade flow, not an install flow, and in the preinst we run the check
only for install. I think we should run it for upgrade too, so I'll
open an MR to do that.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#926699: Transition to usrmerge has started
Control: tags -1 moreinfo
On Mon, 2022-09-19 at 11:29 +0200, Andreas Beckmann wrote:
> Shouldn't that fail in such a broken environment?
>
> # apt-get install --reinstall usr-is-merged
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not
> upgraded.
> Need to get 0 B/4732 B of archives.
> After this operation, 0 B of additional disk space will be used.
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is installed, so the dialog
> based frontend cannot be used. at
> /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 1.)
> debconf: falling back to frontend: Readline
> (Reading database ... 15056 files and directories currently
> installed.)
> Preparing to unpack .../usr-is-merged_30+nmu1_all.deb ...
> Unpacking usr-is-merged (30+nmu1) over (30+nmu1) ...
> Setting up usr-is-merged (30+nmu1) ...
> # ls -lad /lib{,32,64,x32}
> lrwxrwxrwx 1 root root 7 Sep 19 00:35 /lib -> usr/lib
> drwxr-xr-x 2 root root 440 Sep 19 08:59 /lib32
> lrwxrwxrwx 1 root root 9 Sep 19 00:35 /lib64 -> usr/lib64
> lrwxrwxrwx 1 root root 10 Sep 19 00:35 /libx32 -> usr/libx32
It should, but I cannot reproduce this? Can you share the exact steps
you used to create the chroot?
# ls -lad /lib{,32,64,x32}
lrwxrwxrwx 1 root root7 Sep 19 10:20 /lib -> usr/lib
drwxr-xr-x 2 root root 4096 Sep 19 10:20 /lib32
lrwxrwxrwx 1 root root9 Sep 19 10:20 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Sep 19 10:20 /libx32 -> usr/libx32
# sh -x usrmerge/debian/usr-is-merged.preinst install
+ fail_if_unmerged
+ is_merged
+ directories=/bin /sbin /lib
+ [ -e /bin ]
+ readlink -f /bin
+ [ /usr/bin = /usr/bin ]
+ [ -e /sbin ]
+ readlink -f /sbin
+ [ /usr/sbin = /usr/sbin ]
+ [ -e /lib ]
+ readlink -f /lib
+ [ /usr/lib = /usr/lib ]
+ arch_directories=/lib64 /lib32 /libo32 /libx32
+ [ -e /lib64 ]
+ readlink -f /lib64
+ [ -e /lib32 ]
+ readlink -f /lib32
+ return 1
+ [ -e /etc/unsupported-skip-usrmerge-conversion ]
+ cat
**
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
******
+ exit 1
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1016169: buster-pu: package debootstrap/1.0.114+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-boot@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
While preparing for the usrmerge transition as per [0], we have done
some work on debootstrap [1] to ensure that, as per CTTE decision,
buildd machines (and CI machines) can remain unmerged-usr.
The new version of debootstrap with these changes is in unstable,
testing and stable-backports.
While talking with the buildd team, it was noted that some buildd
machines are still running oldstable, and there is no hard deadline for
the upgrade to stable. This means stable-backports is not enough to
ensure we can begin the transition, and blocking it on the buildd full
upgrades (which is difficult and time consuming) would put unduly
pressure on the DSA team and risk long delays, as the Bookworm freeze
approaches.
A selected backport of the changes for stable-proposed-updates and
oldstable-proposed-updates seems like a safe approach that removes the
buildd team/DSA from the critical path, and the buildd team/DSA would
prefer to go down that route.
The backport was tested by creating a sid chroot with local packages
that pull in usrmerge|usr-is-merged, and veryfing that with --no-
merged-usr and/or --variant buildd the chroot is still unmerged-usr as
expected.
Debdiff attached.
[0] https://lists.debian.org/debian-ctte/2022/07/msg00019.html
[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/71
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.114/debian/changelog debootstrap-1.0.114+deb10u1/debian/changelog
--- debootstrap-1.0.114/debian/changelog 2019-01-09 13:00:04.0 +
+++ debootstrap-1.0.114+deb10u1/debian/changelog 2022-07-28 12:18:59.0 +0100
@@ -1,3 +1,12 @@
+debootstrap (1.0.114+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * setup_merged_usr: create skip flag when merged-usr is disabled on
+bookworm+
+ * Add usr-is-merged to the required set on testing/unstable
+
+ -- Luca Boccassi Thu, 28 Jul 2022 12:18:59 +0100
+
debootstrap (1.0.114) unstable; urgency=medium
* Revert changes from 1.0.113 (closes: #918722)
diff -Nru debootstrap-1.0.114/functions debootstrap-1.0.114+deb10u1/functions
--- debootstrap-1.0.114/functions 2019-01-09 12:59:11.0 +
+++ debootstrap-1.0.114+deb10u1/functions 2022-07-28 12:16:24.0 +0100
@@ -1323,7 +1323,23 @@
MERGED_USR="no"
fi
- if [ "$MERGED_USR" = "no" ]; then return 0; fi
+ if [ "$MERGED_USR" = "no" ]; then
+ # With the usrmerge becoming pseudo-essential we need to use this flag
+ # to ensure that even if it gets installed the buildd is not converted
+ # when debootstrap needs to create an unmerged-usr installation.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ mkdir -p "$TARGET/etc"
+ echo "this system will not be supported in the future" > "$TARGET/etc/unsupported-skip-usrmerge-conversion"
+ if ! doing_variant buildd; then
+ warning SANITYCHECK "Upgrading non-merged-/usr environments post-bookworm is unsupported. Only do this for CI/QA infrastructure that will be re-bootstrapped rather than upgraded."
+ fi
+ ;;
+ esac
+ return 0;
+ fi
local link_dir
case $ARCH in
diff -Nru debootstrap-1.0.114/scripts/debian-common debootstrap-1.0.114+deb10u1/scripts/debian-common
--- debootstrap-1.0.114/scripts/debian-common 2018-11-20 18:55:53.0 +
+++ debootstrap-1.0.114+deb10u1/scripts/debian-common 2022-07-28 12:16:24.0 +0100
@@ -32,6 +32,20 @@
base="$base apt-transport-https ca-certificates"
;;
esac
+
+ # On suites >= bookworm, either we set up a merged-/usr system
+ # via setup_merged_usr, or we deliberately avoided that migration
+ # by creating the flag file. This means there's no need for the
+ # live migration 'usrmerge' package and its extra dependencies:
+ # we can install the empty 'usr-is-merged' metapackage to indicate
+ # that the transition has been done.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ required="$required usr-is-merged"
+ ;;
+ esac
}
first_stage_install () {
signature.asc
Description: This is a digitally signed message part
Bug#1016168: bullseye-pu: package debootstrap/1.0.123+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-boot@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
While preparing for the usrmerge transition as per [0], we have done
some work on debootstrap [1] to ensure that, as per CTTE decision,
buildd machines (and CI machines) can remain unmerged-usr.
The new version of debootstrap with these changes is in unstable,
testing and stable-backports.
While talking with the buildd team, it was noted that some buildd
machines are still running oldstable, and there is no hard deadline for
the upgrade to stable. This means stable-backports is not enough to
ensure we can begin the transition, and blocking it on the buildd full
upgrades (which is difficult and time consuming) would put unduly
pressure on the DSA team and risk long delays, as the Bookworm freeze
approaches.
A selected backport of the changes for stable-proposed-updates and
oldstable-proposed-updates seems like a safe approach that removes the
buildd team/DSA from the critical path, and the buildd team/DSA would
prefer to go down that route.
The backport was tested by creating a sid chroot with local packages
that pull in usrmerge|usr-is-merged, and veryfing that with --no-
merged-usr and/or --variant buildd the chroot is still unmerged-usr as
expected.
Debdiff attached.
[0] https://lists.debian.org/debian-ctte/2022/07/msg00019.html
[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/71
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.123/debian/changelog debootstrap-1.0.123+deb11u1/debian/changelog
--- debootstrap-1.0.123/debian/changelog 2020-03-14 01:07:20.0 +
+++ debootstrap-1.0.123+deb11u1/debian/changelog 2022-07-28 12:04:03.0 +0100
@@ -1,3 +1,12 @@
+debootstrap (1.0.123+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * setup_merged_usr: create skip flag when merged-usr is disabled on
+bookworm+
+ * Add usr-is-merged to the required set on testing/unstable
+
+ -- Luca Boccassi Thu, 28 Jul 2022 12:04:03 +0100
+
debootstrap (1.0.123) unstable; urgency=medium
* Reinstate safeguard removed in 1.0.121, which is absolutely needed
diff -Nru debootstrap-1.0.123/functions debootstrap-1.0.123+deb11u1/functions
--- debootstrap-1.0.123/functions 2020-03-14 00:53:38.0 +
+++ debootstrap-1.0.123+deb11u1/functions 2022-07-28 11:55:40.0 +0100
@@ -1341,7 +1341,23 @@
MERGED_USR="no"
fi
- if [ "$MERGED_USR" = "no" ]; then return 0; fi
+ if [ "$MERGED_USR" = "no" ]; then
+ # With the usrmerge becoming pseudo-essential we need to use this flag
+ # to ensure that even if it gets installed the buildd is not converted
+ # when debootstrap needs to create an unmerged-usr installation.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ mkdir -p "$TARGET/etc"
+ echo "this system will not be supported in the future" > "$TARGET/etc/unsupported-skip-usrmerge-conversion"
+ if ! doing_variant buildd; then
+ warning SANITYCHECK "Upgrading non-merged-/usr environments post-bookworm is unsupported. Only do this for CI/QA infrastructure that will be re-bootstrapped rather than upgraded."
+ fi
+ ;;
+ esac
+ return 0;
+ fi
local link_dir
case $ARCH in
diff -Nru debootstrap-1.0.123/scripts/debian-common debootstrap-1.0.123+deb11u1/scripts/debian-common
--- debootstrap-1.0.123/scripts/debian-common 2020-03-13 02:04:21.0 +
+++ debootstrap-1.0.123+deb11u1/scripts/debian-common 2022-07-28 11:55:40.0 +0100
@@ -40,6 +40,20 @@
esac
;;
esac
+
+ # On suites >= bookworm, either we set up a merged-/usr system
+ # via setup_merged_usr, or we deliberately avoided that migration
+ # by creating the flag file. This means there's no need for the
+ # live migration 'usrmerge' package and its extra dependencies:
+ # we can install the empty 'usr-is-merged' metapackage to indicate
+ # that the transition has been done.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ required="$required usr-is-merged"
+ ;;
+ esac
}
first_stage_install () {
signature.asc
Description: This is a digitally signed message part
Re: partman, growlight, discoverable partitions, and fun
On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote: > > > On Sep 27, 2021, at 2:25 PM, Luca Boccassi wrote: > > > > Even if that interpretation would work as an excuse to never do > > anything, and I'm not really sure it does, this specification has been > > published in 2014 [0] so even by Debian standard it's old stuff. > > That’s not what I said so. You’re trying to dismiss my opinion as completely > invalid now by trying to frame it such that I am against progress. I am not. You dismissed it because it's "new technology": > Not for me, though. Debian has always followed the philosophy to be a > universal > operating system, which also meant that we can't (immediately) use all the new > technologies and features that other distributions or upstream projects > develop. I simply pointed out that it's a 7 years old spec that saw an entire LTS Debian version (8, we are now at 11) being released and EOL'ed since the time it was published. If this is too new to consider, then so are all Debian releases newer than Wheezy. > > It's > > older than Debian Jessie, which was EOL'd last year. If libparted can't > > keep up with 7 years old stuff that in the meantime was implemented in > > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019, > > and so on, then to me it sounds like a tool in maintenance mode: > > perfectly fine and adequate for existing tools and programs, but not > > quite the best choice for new tools developed from scratch. > > Whether a tool that was developed new from scratch is automatically better is > not a given. The burden of proof is on the person trying to introduce the new > software, not on the people maintaining the current set of software. > > And claiming that parted is in pure maintenance mode is not true either. It > has a paid developer working on the project and is receiving updates and > improvements. > > Whether growlight is better and more suitable for Debian needs to be > technically proven, not just by arguing that it’s the newer project. > > Adrian Of course. But jumping in and saying "you should use X instead of Y", you can't pretend that nobody asks questions such as "ok, but does libX support this very much related and relevant 7 years old specification that other comparable tools support", no matter how awkward it is for libX. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: partman, growlight, discoverable partitions, and fun
On Mon, 2021-09-27 at 13:06 +0200, John Paul Adrian Glaubitz wrote: > Hello! > > On 9/27/21 12:46, Luca Boccassi wrote: > > > Also, since parted is maintained by RedHat, I would expect that this > > > feature > > > would land in parted soon as well. > > > > > If the question is "why does X not use libparted", "does not support > > discoverable parts spec" is a good enough answer for me. > > Not for me, though. Debian has always followed the philosophy to be a > universal > operating system, which also meant that we can't (immediately) use all the new > technologies and features that other distributions or upstream projects > develop. > > For example, we don't use systemd-homed or systemd-firstboot either. That > doesn't > mean Debian is per se worse off. It just means Debian tries to cater > different use > cases and follows different concepts. > > It's different for distributions like Fedora or openSUSE which focus on a very > limited set of targets and use cases. That's why they can quickly adopt to all > the new features and technologies that upstream projects like systemd develop. > > I'm not saying that one philosophy is better than the other. I'm just saying > that > Debian is not like these other distributions. > > Adrian Even if that interpretation would work as an excuse to never do anything, and I'm not really sure it does, this specification has been published in 2014 [0] so even by Debian standard it's old stuff. It's older than Debian Jessie, which was EOL'd last year. If libparted can't keep up with 7 years old stuff that in the meantime was implemented in util-linux's (which is a truly universal tool) in 2014, gdisk in 2019, and so on, then to me it sounds like a tool in maintenance mode: perfectly fine and adequate for existing tools and programs, but not quite the best choice for new tools developed from scratch. -- Kind regards, Luca Boccassi [0] https://cgit.freedesktop.org/wiki/www/log/Specifications/DiscoverablePartitionsSpec.mdwn signature.asc Description: This is a digitally signed message part
Re: partman, growlight, discoverable partitions, and fun
On Sun, 2021-09-26 at 12:45 +0200, John Paul Adrian Glaubitz wrote: > Hello! > > On 9/26/21 12:40, Luca Boccassi wrote: > > Does libparted support the discoverable partitions spec? > > I'm not sure, this thread is the first time I have heard about discoverable > partitions. I have read up first what the motivations for these are and > how useful they would be for Debian. > > Also, since parted is maintained by RedHat, I would expect that this feature > would land in parted soon as well. > > Adrian If the question is "why does X not use libparted", "does not support discoverable parts spec" is a good enough answer for me. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: partman, growlight, discoverable partitions, and fun
On Sun, 26 Sept 2021 at 10:05, John Paul Adrian Glaubitz wrote: > > Hello Nick! > > On 9/26/21 00:49, Nick Black wrote: > > It supports MBR, GPT, and APM: > > > > https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 > > > > (sorry for the gmail-style top posting; i can't find your mail in my mbox > > for whatever reason) > > > > Any other partition schemes ought be trivial to add; they've not been added > > yet > > simply because I don't have means with which to test them. > > So, you are not using libparted then? > > > Looking at the "partition types" section of the Linux configuration, I see: > > Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris > > x86, Unixware, > > Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. > > > > Looking at the disk-label code from partman, I see: > > gpt, msdos, amiga, atari, mac, sun > > > > So the only ones covered by partman and not covered by growlight would be: > > amiga, atari, sun, > > and mac (if mac is not the same as APM). I don't see any difficulty in > > adding these four, so long > > as there's someone with an Amiga or ATARI who'd be willing to test them > > out. If there are no such > > people, is it that important? > > Yes, it is important as we're supporting these architectures in Debian Ports > and I invested quite some time to get Atari partition support added [1], > for example. > > I think it makes little sense to not use libparted as it already supports > all common and less common partition types and reimplementing everything > that libparted makes little sense to me. > > Adrian Does libparted support the discoverable partitions spec? Kind Regards, Luca Boccassi
Re: Install fwupd on a default installation
On Wed, 2018-12-26 at 21:32 +, Steve McIntyre wrote: > On Wed, Dec 26, 2018 at 10:27:35PM +0100, Cyril Brulebois wrote: > > Steve McIntyre (2018-12-26): > > > > Philipp Kern (2018-12-26): > > > > > I'm not sure, though, if there is some philosophical > > > > > objection here in > > > > > that fwupd downloads non-free blobs and/or that Debian does > > > > > not actually > > > > > ship the blobs themselves. > > > > > > > > FWIW both parts seem unacceptable to me, esp. in a default > > > > installation. > > > > > > They're not all necessarily non-free, but it's a useful service > > > for > > > people to make safe firmware updates easy. > > > > How do we know those blobs are safe, and that they won't change all > > of a > > sudden if they aren't hosted on Debian infrastructure? > > We *don't* directly, but they blobs are signed and placed online by > the vendors. LVFS (the online backend) is a good Free > Software-friendly service. > > This is a major step forwards from the old Windows-only ot "boot a > DOS > floppy" style of firmware updates. To add my 2c to that, we also don't know that the firmware that is installed on the machine at the factory is secure - but we know it's outdated, and we know that security-related new versions are common enough to be worth worrying about. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Q: What's the relationship between Secure Boot and debootstrap?
On Tue, 2018-07-31 at 17:11 +0100, Steve McIntyre wrote: > On Tue, Jul 31, 2018 at 10:52:00PM +0800, Ben Hutchings wrote: > > On Tue, 2018-07-31 at 21:17 +0800, Hideki Yamane wrote: > > > Hi, > > > > > > During "Report from the Debian EFI team about the support of > > > Secure > > > Boot on Debian" session, you said that maybe we should touch > > > debootstrap, > > > but I'm not sure what should we do for it. > > > > > > Could you explain your thought for it, please? > > > > I didn't understand that remark either. > > > > Perhaps it was meant to refer to other tools using debootstrap, > > like > > vmdb2, that also install a boot loader. > > That kind of thing, yes. Should have been clearer. Debootstrap itself > doesn't install a kernel or bootloader, which were the packages I was > thinking about. I might have shared this before and apologies if so - but just in case it can be useful, here's how we implemented this in live-build to create a secure-boot compatible live bootable image: https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L149 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#881626: busybox: enable telnetd
On Mon, 13 Nov 2017 17:16:26 + Luca Boccassi <bl...@debian.org> wrote: > Package: busybox > Version: 1.27.2-1 > Severity: wishlist > Tags: patch > > Dear Maintainers, > > Please consider enabling telnetd in the busybox package. A tiny and > trivial patch to set the config is attached inline. A rebuild with that > change seems to work fine. > > As much as I wish it wasn't the case, telnet is still widely used, > especially in the ISP/telco world. Telcos networking engineers expect > to be able to telnet into boxes in their network even today. > > Having telnetd available without having to rebuild busybox would be > extremely handy when using Debian (or derivatives) in small boxes (eg: > arm64) inside a telecommunication provider's network. > > Thanks! > > -- > Kind regards, > Luca Boccassi > > > From b9a2c82b4120a698b6350c7550f5286008892f2c Mon Sep 17 00:00:00 2001 > From: Luca Boccassi <bl...@debian.org> > Date: Mon, 13 Nov 2017 17:05:12 + > Subject: [PATCH] Enable telnetd > > --- > debian/config/pkg/deb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/debian/config/pkg/deb b/debian/config/pkg/deb > index 290205d99..73428dc5b 100644 > --- a/debian/config/pkg/deb > +++ b/debian/config/pkg/deb > @@ -903,8 +903,8 @@ CONFIG_TELNET=y > CONFIG_FEATURE_TELNET_TTYPE=y > CONFIG_FEATURE_TELNET_AUTOLOGIN=y > CONFIG_FEATURE_TELNET_WIDTH=y > -# CONFIG_TELNETD is not set > -# CONFIG_FEATURE_TELNETD_STANDALONE is not set > +CONFIG_TELNETD=y > +CONFIG_FEATURE_TELNETD_STANDALONE=y > # CONFIG_FEATURE_TELNETD_INETD_WAIT is not set > CONFIG_TFTP=y > # CONFIG_TFTPD is not set > -- > 2.11.0 Dear Maintainers, Any chance this patch could be looked at? It would really help those of us in the networking world using Debian, and would make no difference for anybody else as there's no service/init script to start the daemon automatically. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#881626: busybox: enable telnetd
On Tue, 2017-11-14 at 14:30 -0500, Lennart Sorensen wrote: > On Tue, Nov 14, 2017 at 06:59:41PM +, Holger Levsen wrote: > > you are aware that this would only cause (these) people to switch > > away > > from Debian, but not from telnet? > > I honestly believe they just haven't tried. As long as you indulge > them, > they will keep training new people with bad habits. It won't go away > until you make it go away. Sometimes you really do have to tell > people no. Sorry, but that's just not the case. Honestly, I tried, may others have too, it's just not going to happen - either Debian provides it, or they'll go somewhere else (or ask for the services to be based on a different distro and so on). > > also, I miss your removal requests for the telnetd and ftpd and > > (countless) other packages. > > > > to the original poster: what's wrong with installing telnetd? its > > only > > 103kb in size... Well for small systems for starters - most tools provided by busybox are "just a few kb in size", but we still use it. More importantly in my case, busybox telnetd is really standalone and can do inetd work by itself, which is not the case for the standard telnetd. So it's not just a matter of footprint, but lack of feature too. > Well at least in a separate package you don't accidentally get it > just > by installing busybox. Even if you install it, it won't do anything unless you enable it via an init script or by starting it manually. So there's no chance of using it by mistake. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#881626: busybox: enable telnetd
On Tue, 2017-11-14 at 13:35 -0500, Lennart Sorensen wrote: > On Mon, Nov 13, 2017 at 05:16:26PM +0000, Luca Boccassi wrote: > > Package: busybox > > Version: 1.27.2-1 > > Severity: wishlist > > Tags: patch > > > > Dear Maintainers, > > > > Please consider enabling telnetd in the busybox package. A tiny and > > trivial patch to set the config is attached inline. A rebuild with > > that > > change seems to work fine. > > > > As much as I wish it wasn't the case, telnet is still widely used, > > especially in the ISP/telco world. Telcos networking engineers > > expect > > to be able to telnet into boxes in their network even today. > > > > Having telnetd available without having to rebuild busybox would be > > extremely handy when using Debian (or derivatives) in small boxes > > (eg: > > arm64) inside a telecommunication provider's network. > > Anything that makes it more work for you and hence gives more > incentive > for you to get the clueless people that want to keep using telnet to > change is a good thing. Allowing telnet access ought to be made as > difficult as possible. > > People have been saying to not use telnet for about 20 years now. > They better have learned by now. Again, I wish it could work like that. Sadly, it doesn't. More work for me just means more work for me, nothing else. The people that want telnet will keep using telnet, if not from Debian from a downstream fork or from a different distro or worse from a proprietary vendor. It's not that they haven't learned - it's just that they don't care. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#881626: busybox: enable telnetd
On Tue, 2017-11-14 at 13:50 +0100, Wouter Verhelst wrote: > On Mon, Nov 13, 2017 at 05:16:26PM +0000, Luca Boccassi wrote: > > Package: busybox > > Version: 1.27.2-1 > > Severity: wishlist > > Tags: patch > > > > Dear Maintainers, > > > > Please consider enabling telnetd in the busybox package. A tiny and > > trivial patch to set the config is attached inline. A rebuild with > > that > > change seems to work fine. > > > > As much as I wish it wasn't the case, telnet is still widely used, > > especially in the ISP/telco world. Telcos networking engineers > > expect > > to be able to telnet into boxes in their network even today. > > As much as I don't mind doing weird things in support of weird use > cases, in this particular case I think that would be sending out the > wrong message. We shouldn't do that, IMO, but rather encourage people > to > switch to SSH instead of telnet. > > It might make sense to add some documentation that explains why > telnet > isn't supported, however. I wish that could happen, I swear. Having to support it is just... "fun". :-( We tried. Everybody knows it's bad, insecure, generally horrible and all that. But at the very least until all the network operators trained by a certain network hardware vendor will retire demand for telnet is not going away, sadly. I wish I could do anything to change that. > As an aside, can you tell which telco's we are talking about? Right now it's an North American provider with a three characters name ;-) But I've yet to find one telco that doesn't demand telnet, unfortunately. They are not alone in that. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#881626: busybox: enable telnetd
Package: busybox Version: 1.27.2-1 Severity: wishlist Tags: patch Dear Maintainers, Please consider enabling telnetd in the busybox package. A tiny and trivial patch to set the config is attached inline. A rebuild with that change seems to work fine. As much as I wish it wasn't the case, telnet is still widely used, especially in the ISP/telco world. Telcos networking engineers expect to be able to telnet into boxes in their network even today. Having telnetd available without having to rebuild busybox would be extremely handy when using Debian (or derivatives) in small boxes (eg: arm64) inside a telecommunication provider's network. Thanks! -- Kind regards, Luca Boccassi From b9a2c82b4120a698b6350c7550f5286008892f2c Mon Sep 17 00:00:00 2001 From: Luca Boccassi <bl...@debian.org> Date: Mon, 13 Nov 2017 17:05:12 + Subject: [PATCH] Enable telnetd --- debian/config/pkg/deb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/config/pkg/deb b/debian/config/pkg/deb index 290205d99..73428dc5b 100644 --- a/debian/config/pkg/deb +++ b/debian/config/pkg/deb @@ -903,8 +903,8 @@ CONFIG_TELNET=y CONFIG_FEATURE_TELNET_TTYPE=y CONFIG_FEATURE_TELNET_AUTOLOGIN=y CONFIG_FEATURE_TELNET_WIDTH=y -# CONFIG_TELNETD is not set -# CONFIG_FEATURE_TELNETD_STANDALONE is not set +CONFIG_TELNETD=y +CONFIG_FEATURE_TELNETD_STANDALONE=y # CONFIG_FEATURE_TELNETD_INETD_WAIT is not set CONFIG_TFTP=y # CONFIG_TFTPD is not set -- 2.11.0 signature.asc Description: This is a digitally signed message part
Bug#866328: user-setup: allow to preseed the user shell
On Wed, 2017-06-28 at 23:20 +0200, Cyril Brulebois wrote: > Hi Luca, > > Luca Boccassi <luca.bocca...@gmail.com> (2017-06-28): > > It would be useful to allow preseeding the user shell. > > > > The use case we have at work is building live Debian images and > > shipping them to users, where we need to have something other than > > bash as the live user shell. > > > > This could be achieved with hacky posthook scripts that sed > > /etc/passwd, but it just feels wrong :-) > > > > Attached is a very small and simple patch to add a passwd/user- > > shell > > configurable option, modeled after passwd/user-uid. > > I'm still undecided as to whether this patch is needed/useful in d-i, > but anyway: Hi, At work we build a downstream of Debian, Vyatta, and it would be quite useful for us. There might be more crazy folks like us out there who might like it too :-) > > # Allow preseeding the groups to which the first created user is > > added > > Template: passwd/user-default-groups > > Type: string > > diff --git a/user-setup-apply b/user-setup-apply > > index f24ece2..9dfcf55 100755 > > --- a/user-setup-apply > > +++ b/user-setup-apply > > @@ -109,6 +109,16 @@ if [ "$RET" = true ] && ! is_system_user; then > > UIDOPT= > > fi > > > > + if db_get passwd/user-shell && [ "$RET" ]; then > > + if [ -x $ROOT/usr/sbin/adduser ]; then > > + SHELLOPT="--shell $RET" > > + else > > + SHELLOPT="-s $RET" > > + fi > > + else > > + SHELLOPT= > > + fi > > + > > This distinction doesn't seem needed? I see this in useradd's manpage > from jessie to sid: > -s, --shell SHELL Yes I noticed the same, but that was true for --uid as well, so I followed the same convention. New version inlined without that if-else. Thanks for the feedback! Kind regards, Luca Boccassi From 84e6049f8e41f15da2e3b91f1184e89e8cd429b7 Mon Sep 17 00:00:00 2001 From: Luca Boccassi <luca.bocca...@gmail.com> Date: Wed, 28 Jun 2017 19:21:10 +0100 Subject: [PATCH] Add passwd/user-shell to allow preseeding the shell In some cases it is useful to be able to configure the user shell via the installer. Add a new optional db_get passwd/user-shell and pass it to adduser/useradd --shell/-s if it is set. --- debian/user-setup-udeb.templates | 5 + user-setup-apply | 10 -- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates index 45e16b4..64731de 100644 --- a/debian/user-setup-udeb.templates +++ b/debian/user-setup-udeb.templates @@ -16,6 +16,11 @@ Template: passwd/user-uid Type: string Description: for internal use only +# Allow preseeding the shell configured for the first created user +Template: passwd/user-shell +Type: string +Description: for internal use only + # Allow preseeding the groups to which the first created user is added Template: passwd/user-default-groups Type: string diff --git a/user-setup-apply b/user-setup-apply index f24ece2..9a6a913 100755 --- a/user-setup-apply +++ b/user-setup-apply @@ -109,6 +109,12 @@ if [ "$RET" = true ] && ! is_system_user; then UIDOPT= fi + if db_get passwd/user-shell && [ "$RET" ]; then + SHELLOPT="--shell $RET" + else + SHELLOPT= + fi + # Add the user to the database, using adduser in noninteractive # mode. db_get passwd/username @@ -121,9 +127,9 @@ if [ "$RET" = true ] && ! is_system_user; then fi if [ -x $ROOT/usr/sbin/adduser ]; then - $log $chroot $ROOT adduser --disabled-password --gecos "$RET" $UIDOPT "$USER" >/dev/null || true + $log $chroot $ROOT adduser --disabled-password --gecos "$RET" $UIDOPT $SHELLOPT "$USER" >/dev/null || true else - $log $chroot $ROOT useradd -c "$RET" -m "$USER" $UIDOPT >/dev/null || true + $log $chroot $ROOT useradd -c "$RET" -m "$USER" $UIDOPT $SHELLOPT >/dev/null || true fi # Clear the user password from the database. -- 2.11.0 signature.asc Description: This is a digitally signed message part
Bug#866328: user-setup: allow to preseed the user shell
Package: user-setup Tags: patch Severity: wishlist Dear Maintainer, It would be useful to allow preseeding the user shell. The use case we have at work is building live Debian images and shipping them to users, where we need to have something other than bash as the live user shell. This could be achieved with hacky posthook scripts that sed /etc/passwd, but it just feels wrong :-) Attached is a very small and simple patch to add a passwd/user-shell configurable option, modeled after passwd/user-uid. Thank you! Kind regards, Luca Boccassi From 80480267a470793b77c336fa49c24a864e647bea Mon Sep 17 00:00:00 2001 From: Luca Boccassi <luca.bocca...@gmail.com> Date: Wed, 28 Jun 2017 19:21:10 +0100 Subject: [PATCH] Add passwd/user-shell to preseed the user shell In some cases it is useful to be able to configure the user shell via the installer. Especially when building live-images to deliver to users. Add a new optional db_get passwd/user-shell and pass it to adduser/useradd --shell/-s if it is set. --- debian/user-setup-udeb.templates | 5 + user-setup-apply | 14 -- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates index 45e16b4..64731de 100644 --- a/debian/user-setup-udeb.templates +++ b/debian/user-setup-udeb.templates @@ -16,6 +16,11 @@ Template: passwd/user-uid Type: string Description: for internal use only +# Allow preseeding the shell configured for the first created user +Template: passwd/user-shell +Type: string +Description: for internal use only + # Allow preseeding the groups to which the first created user is added Template: passwd/user-default-groups Type: string diff --git a/user-setup-apply b/user-setup-apply index f24ece2..9dfcf55 100755 --- a/user-setup-apply +++ b/user-setup-apply @@ -109,6 +109,16 @@ if [ "$RET" = true ] && ! is_system_user; then UIDOPT= fi + if db_get passwd/user-shell && [ "$RET" ]; then + if [ -x $ROOT/usr/sbin/adduser ]; then + SHELLOPT="--shell $RET" + else + SHELLOPT="-s $RET" + fi + else + SHELLOPT= + fi + # Add the user to the database, using adduser in noninteractive # mode. db_get passwd/username @@ -121,9 +131,9 @@ if [ "$RET" = true ] && ! is_system_user; then fi if [ -x $ROOT/usr/sbin/adduser ]; then - $log $chroot $ROOT adduser --disabled-password --gecos "$RET" $UIDOPT "$USER" >/dev/null || true + $log $chroot $ROOT adduser --disabled-password --gecos "$RET" $UIDOPT $SHELLOPT "$USER" >/dev/null || true else - $log $chroot $ROOT useradd -c "$RET" -m "$USER" $UIDOPT >/dev/null || true + $log $chroot $ROOT useradd -c "$RET" -m "$USER" $UIDOPT $SHELLOPT >/dev/null || true fi # Clear the user password from the database. -- 2.11.0 signature.asc Description: This is a digitally signed message part
