Control: tag -1 patch Hi,
(Again, please keep debian-boot@ in copy.) Raphael Hertzog <hert...@debian.org> (2017-08-19): > > I've only quickly glanced at the contents of both packages, and > > debdiff mentions no obvious issues (file lists are the same). > > I believe this is precisely the problem. The new udev-udeb should > include a new file: > diff --git a/debian/udev-udeb.install b/debian/udev-udeb.install > index 6a8e2108f..6758fef06 100644 > --- a/debian/udev-udeb.install > +++ b/debian/udev-udeb.install > @@ -5,6 +5,7 @@ lib/udev/ata_id > lib/udev/scsi_id > lib/udev/cdrom_id > lib/udev/rules.d/50-udev-default.rules > +lib/udev/rules.d/60-input-id.rules > lib/udev/rules.d/60-cdrom_id.rules > lib/udev/rules.d/60-persistent-input.rules > lib/udev/rules.d/60-persistent-storage.rules > > I won't have the time to test this now but I believe it's the problem. That's absolutely correct. I've started by copying the file manually into the netboot-gtk mini.iso, and confirmed the fix. To be extra sure, I've rebuilt a systemd package with your change, and used the new udev udebs for a clean build, and that works as well. A timely fix would be appreciated, the breakage(s) in the graphical installer prevented us from releasing debian-installer over the past few weeks, and it would be great not to wait too long before we're able to do so, esp. with linux 4.12.6-1 having reached testing lately. Thinking about this, I'll check with debian-release@ and I might just freeze all udeb-producing packages right away. Winter has come. > It would be nice to have a fixed udev soon. Thank you Cyril for the > investigation! > > I wonder if it would be possible to have autopkgtest tests covering > udev-udeb... I'm still new to the whole autopkgtest thing, but from where I stand, the fact d-i is broken has been known for quite a while; the core issue is that nobody investigated this before I found some time. An easy way to be more proactive on the systemd side would be to make sure that new (and/or deleted) files in the udev and libudev1 binaries are detected by maintainers (esp. since udev.install uses wildcards for rules files, while udev-udeb.rules uses a static list), so that the update can be propagated to the udebs if relevant. I'm fine with setting up a check through a cron job on d-i.debian.org so as to avoid putting the burden on systemd maintainers. The feedback loop might take a few hours/days after an upload with such a change, but that would make it obvious that something “important” changed, and would speed up understanding such regressions. KiBi.
signature.asc
Description: Digital signature
