Thank you, autopkgtests are looking good now! I agree the s390x failure seems flaky. The package LGTM mostly, now. I've added 3 small TODOs (see below), which I'd like you to have a look at before we upload and a bunch of "FUTURE WORK", which we should track somewhere for future investigations in our mission to reduce the delta. > > d/control: > > + systemd-sysv package => do we really need "Depends: systemd" if we have > the pre-depends already? (well.. there's a versioned dependency..) > > Please see https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/c > ommit/?id=d1ecf0c372f5212129c85ae60fddf26b2271a1fe. ACK. Sorry for me not digging deep enough on some of my earlier comments (it was all a bit rushed) and thanks for providing the relevant links to git commits! === TODO === d/systemd-resolved.postinst: + Should we adapt to DPKG_ROOT now? (see 5664be0) d/t/tests-in-lxd: + Please add a comment about not testing in privileged LXD containers anymore + reference to bug #1950787 (especially @stgraber's comment) – I'm fine with only staging this for the next upload if we want to get the current version uploaded now. + How can we make sure systems still at least boot OK inside a privileged LXD container? IMO we should be adding a simple smoke test for privileged containers. === FUTURE WORK === (see some additional new comments for future work at the very bottom) > > d/rules: > > + do we have any reference for that "CET on ubuntu amd64" enablement > compiler issue/fix? we should add it to the comment > > I am not sure, the commit does not explain much: > https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c > c42a377e7e8c372124bcf43d9f4fb9c169f4292. I feel like we should be creating a JIRA card about that, to investigate the situation in the future, would you mind creating such card? For now we'll keep the packaging as-is. > > d/systemd.prerm: > > + I don't think we support removing systemd at all... so I wonder why this > file was dropped? Couldn't we just keep it, to reduce delta? > > Please see https://git.launchpad.net/~ubuntu-core- > dev/ubuntu/+source/systemd/commit/?id=0244c4d56556317f14eecc2f51871969ef02ba7b > and bug 1758438. Thanks for providing the context (bug #1758438)! I feel like this is a workaround and we should rather try to get the chroot usecase properly fixed. Ideally in cooperation with Debian, as it might affect them as well. But let's but that burden on future-us (should we create a card about it, too? Maybe some "systemd technical-debt" card with a bunch of subtasks?). We'll keep packaging as-is for now. > > d/t/control: > > + boot-and-services: the "gdm3 [amd64]" dependency looks suspicious, why do > we need to diverge from Debian here? > > Please see https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/c > ommit/?id=97cb13685dfb353045c449ec5d6d1df60f661079. It does not contain a lot > of information or an LP, but I don't feel very strongly about removing that > delta. We should be striving to reduce delta whenever possible, so this is something for future investigation ("systemd technical-debt" card), too. Keeping it as-is for now. > > d/t/systemd-fsckd: > > + what's wrong with this test after all?? We're basically skipping/ignoring > it, still we have a huge delta on it. This should probably be investigated in > the future and we should drop the delta if we don't actually use it. > > As far as why it's always skipped, it's because: > > autopkgtest [11:22:51]: test systemd-fsckd: [----------------------- > SKIP: root file system is being checked by initramfs already > autopkgtest [11:22:52]: test systemd-fsckd: -----------------------] > > If it's always skipped in effect, maybe we can just drop the test entirely > (and suggest that Debian does the same). ACK. Would you mind starting such discussion with the Debian maintainers (or carding that task for the future)? d/p/test-increase-QEMU_MEM-for-some-tests.patch: + Is this something to be sent Debian's way (or carded)? d/t/0001-Revert-tests-add-test-case-for-UMask-BindPaths-combi.patch: + Investigate if we can drop another privileged containers quirk, now that we're not testing/supporting it anymore (bug #1959013)