Bug#778554: unblock: systemd/215-12
niels at thykier.net
Mon Feb 23 21:38:31 GMT 2015
Control: tags -1 = d-i
On 2015-02-16 17:16, Martin Pitt wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org at packages.debian.org
> Usertags: unblock
> systemd 215-12 hit unstable three days ago with some RC/important/safe
> So far there have been no regression reports. At the time of this
> writing there are now no RC bugs left \o/
> I attach the full debdiff between 215-11 and -12, but as usual I also
> link to the individual commits on anonscm. Unfortunately the latter
> are a bit noisy, as the implementation of the fixes was discussed
> several times and changed a bit.
> Note that there are zero changes for udev and hence the udebs (for
Sorry, this one fell through on my end. It is ok from my PoV, CC'ing
KiBi for a d-i ack (out of principle). Quoting you in full for KiBi's
> Annotated changelog:
> | systemd (215-12) unstable; urgency=medium
> | [ Martin Pitt ]
> | * debian/udev.README.Debian: Trim the parts which are obsolete, wrong, or
> | described in manpages. Only keep the Debian specific bits.
> | (Part of #776546)
> | * Actually install udev's README.Debian when building for Debian.
> | (Closes: #776546)
> Documentation cleanup. Note that this was requested/pre-approved by Niels.
> | * Only start logind if dbus is installed. This fixes the noisy startup
> | failure in environments without dbus such as LXC containers or servers.
> | (part of #772700)
> | * Add getty-static.service unit which starts getty at .service on tty 2 to 6 if
> | dbus is not installed, and hence logind cannot auto-start them on demand.
> | (Closes: #772700)
> (cleanup of the previous two commits)
> RC bug (with 3 duplicates). This restores VT functionality on systems
> without dbus (i. e. mainly servers) as it is under sysvinit, and
> quiesces logind failures there.
> | * Add unit-config autopkgtest to check systemd unit/sysv init enabling and
> | disabling via systemctl. This avoids bugs like #777613 (did not affect
> | unstable).
> I used this to verify that 215 was not affected. I'd like to keep this
> in master, just to have it available for post-release bug
> | * cgroup: Don't trim cgroup trees created by someone else, just the ones
> | that systemd itself created. This avoids cleaning up empty cgroups from
> | e.g. LXC. (Closes: #777601)
> (followup fix due to git pilot error on my side, sorry)
> RC bug. This looks fairly intrusive (not at all in patch size, that's
> just a two-liner; but in effect), but as long as there is more than
> just systemd writing to /sys/fs/cgroups this errs on the safe side:
> now systemd will never cleanup empty cgroups that it didn't create by
> itself (realized_mask); before it cleaned up all controllers which
> are supported by the kernel (cgroup_supported).
> | * boot-and-services autopkgtest: Add CgroupsTest to check cgroup
> | creation/cleanup behaviour. This reproduces #777601 and verifies the fix
> | for it.
> tests == ♥ :-)
> | * rules: Fix by-path of mmc RPMB partitions and don't blkid them. Avoids
> | kernel buffer I/O errors and timeouts. (LP: #1333140)
> This is https://launchpad.net/bugs/1333140 . Not quite RC, but a
> trivial patch which just blacklists mmcblk*-rpmb devices from getting
> touched by udev rules; they are rather mimosic and can't really opened
> or detected with blkid and other tools.
> | * Document systemctl --failed option. (Closes: #767267)
> Documentation (manpage) only, and an useful option.
> | [ Michael Biebl ]
> | * core: Don't fail to run services in --user instances if $HOME is missing.
> | (Closes: #759320)
> Not release critical, but causes annoyingly long delays during
> shutdown, and quite a simple fix.
> | [ Didier Roche ]
> | * default-display-manager-generator: Avoid unnecessary /dev/null symlink and
> | warning if there is no display-manager.service unit.
> This fixes a corner case to avoid a useless warning, and this is a
> simple patch. This whole logic is tested by
> debian/tests/display-managers which which covers all scenarios we ran
> into so far, and it's still passing fine.
> Thanks for considering! Please let me know if you have any doubt or
> While you are at it, would you mind having a look at #755722? I'd be
> interested in your opinion whether for jessie we should (1) ignore the
> problem, (2) apply the sysv behaviour compatible hwclock.service, or
> (3) boldly go and enable timesyncd.
> unblock systemd/215-12
More information about the Pkg-systemd-maintainers