This bug was fixed in the package systemd - 204-5ubuntu20.20

---------------
systemd (204-5ubuntu20.20) trusty-proposed; urgency=medium

  * Build systemd binary package.
    Drop installation of /etc/* aside from systemd's own config files. This
    avoids a package conflict with systemd-services and we don't want to
    support the full feature set anyway. (LP: #1616422)
  * Disable SysV init support.
    This just gets in the way when running systemd as a "deputy init".
  * systemd: Add Conflicts: to systemd-shim
  * Create/use private D-Bus socket also for systemd --system.
    Without this we cannot use systemctl as root or when D-Bus is not running.
  * Do not read units from /lib/systemd/system, but from /lib/systemd/upstart/
    In Ubuntu 14.04 there are a lot of packages which ship a systemd system 
unit,
    but almost all of these must not run for running systemd's service manager 
as a
    "deputy" init alongside upstart. We do need some of them though, so read 
units
    from /lib/systemd/upstart.
    Only install the system units that we actually need for a deputy init 
(journal
    and all targets).
  * Add Breaks: to init-system-helpers that does not yet have a disabled
    deb-systemd-invoke, to complete the previous change.
  * Add upstart job for deputy systemd init.
    We also need to clean up /run/systemd/system after stop, so that things 
which
    check if systemd is running don't get confused.
  * Add dummy D-Bus units.
    These are built in for exposing systemd itself onto the system bus.
  * Drop LSB init hook.
    We must not redirect SysV init scripts to systemd when running as deputy 
init.
  * Stop systemd deputy upstart job on dist-upgrades.
    Also drop the removal guard as we do want to be able to remove the systemd
    package while it's only running the deputy init.
  * Update Vcs-Git: for new trusty git branch.

 -- Martin Pitt <martin.p...@ubuntu.com>  Thu, 10 Nov 2016 15:14:54
+0100

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1616422

Title:
  [trusty SRU/FFE] Add systemd binary package for snapd

Status in init-system-helpers package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in init-system-helpers source package in Trusty:
  Fix Released
Status in systemd source package in Trusty:
  Fix Released

Bug description:
  Rationale: For backporting snapd to 14.04 LTS, we need to provide
  systemd's service manager (not just logind and auxiliary services like
  logind or timesyncd). upstart will continue to do the actual booting,
  and systemd will act as a "deputy init" which by default does not ship
  with/start any services by itself. We will only support this on server
  (at the first iteration at least), not on desktops.

  Regression potential: This is a new binary package in universe, so
  existing systems are unaffected (provided that we ensure that the
  other binary packages do not change and there are no code changes that
  affect processes other than the "deputy pid 1" service manager). So
  for plain upgrades the regression potential is very low. However,
  there is a medium potential for breakage when actually installing the
  new systemd package, as it might interfere with upstart jobs or other
  running processes, cause boot/shutdown hangs, etc.

  For init-system-helpers, the regression potential is near-zero: We
  never had (and never will) systemd as pid 1 in trusty, so deb-systemd-
  invoke was previously never called. It does get called now if you
  install Ubuntu packages that ship a systemd unit, so we need to make
  that a no-op to retain the current behaviour.

  Test plan:
   1. Dist-upgrade a trusty installation to the proposed versions. Ensure this 
does not pull in "systemd", and that booting, shutdown, desktop startup, 
suspend on lid close, resume, logout, and user switching all still work.

   2. Install the "systemd" binary package (this will replace/remove
  systemd-shim). Verify that you can talk to the service manager with
  "sudo systemctl status". Check that booting and shutdown continues to
  work without (significant) delays.

   3. Ensure that "sudo journalctl" works and that "sudo systemctl
  status systemd-journald" is running and has a few lines of log at the
  end (unlike what you get when you run systemctl as user).

   4. Install a package that ships a systemd .service file, such as
  "haveged". Ensure that the service file is ignored, "pgrep -af
  haveged" should only have *one* process and "systemctl status haveged"
  should not be running (it should not exist, or not be enabled and be
  inactive). [This part also needs the updated init-system-helpers].

     The only services that are running are expected to be systemd-
  journald.service and systemd-journald.socket.

   5. Ensure that the standard targets are active, as that is where
  third-party/snap services hook into:

      systemctl status sysinit.target multi-user.target default.target

   6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and
  ensure you can install a snap, and its services start after installing
  the snap and after rebooting.

   7. Run "sudo apt-get install --reinstall systemd" to ensure that
  upgrades to newer systemd trusty versions work. The running systemd
  should *not* be restarted as that would disrupt snapd and its services
  (verify that the pid in "initctl status systemd" is the same before
  and after the upgrade).

   8. Run "sudo apt install -y colord && sudo apt purge -y colord". This
  should succeed.

   9. Dist-upgrade to 16.04 to ensure that there are no file conflicts,
  dependency issues, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1616422/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to