[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-28 Thread Martin Pitt
> I am in contact with Christian now, and hope to sort this out soon.

Sorry -- I meant Christian Kellner, bolt's upstream, not you :-)

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  In Progress
Status in umockdev package in Ubuntu:
  Invalid
Status in umockdev package in Debian:
  Unknown

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 17082)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 17083)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = -1
  (gdb) n
  186   g_warning ("could not create %s", bus);
  (gdb) n

  ** (/usr/libexec/installed-tests/bolt/test-power:17078): WARNING **:
  15:11:06.614: could not create /tmp/umockdev.TK2VA1/sys/bus

  Thread 1 "test-power" received signal SIGTRAP, Trace/breakpoint trap.

  
  

[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-28 Thread Martin Pitt
Christian, as I write above I believe this really needs to be fixed in
bolt's tests. The umockdev change was a bug fix which bolt's tests
(incorrectly) worked around. So I hope you don't mind that I flipped the
affected package around? I am in contact with Christian now, and hope to
sort this out soon.

** Changed in: bolt (Ubuntu)
   Status: Invalid => In Progress

** Changed in: umockdev (Ubuntu)
   Status: In Progress => Invalid

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  In Progress
Status in umockdev package in Ubuntu:
  Invalid
Status in umockdev package in Debian:
  Unknown

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 17082)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 17083)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
  (gdb) n
  185 if (r < 0)
 

[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-28 Thread Martin Pitt
Thanks Christian -- Indeed I noticed that, and set
https://gitlab.freedesktop.org/bolt/bolt/-/merge_requests/246 the day
after to fix this. Unfortunately I didn't get a reaction yet, and
Christian also didn't respond on IRC yet. I'll do some more prodding.

** Changed in: bolt (Ubuntu)
   Status: New => In Progress

** Changed in: bolt (Ubuntu)
 Assignee: (unassigned) => Martin Pitt (pitti)

** Changed in: umockdev (Ubuntu)
   Status: New => In Progress

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  Invalid
Status in umockdev package in Ubuntu:
  In Progress

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 17082)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 17083)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (

[Touch-packages] [Bug 1934995] Re: Broken on ppc64el (toolchain bug?)

2021-07-25 Thread Martin Pitt
Indeed the open(2) manpage is misleading in that regard. The actual
definition in fcntl.h is like this:

extern int open (const char *__file, int __oflag, ...) __nonnull
((1));

(with a few variants, but they all use varargs). So I did the same in
umockdev for full header compatibility.

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

Title:
  Broken on ppc64el (toolchain bug?)

Status in umockdev package in Ubuntu:
  New

Bug description:
  umockdev appears to be broken on ppc64el in impish. Running it on one
  of Mir's umockdev-using tests results in:

  (impish-ppc64el)root@juju-deb017-porterbox-1:/build/mir-Xn1VqE/umockdev# 
umockdev-run ../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests
  MIR_CLIENT_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/client-modules/
  MIR_SERVER_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/server-modules/
  LD_LIBRARY_PATH=../mir-2.4.1/build-ppc64el/bin/../lib
  exec=../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests.bin
  *** stack smashing detected ***: terminated
  umockdev-run: unable to propagate signal 6 to child 15833: No such process

  (You can also see this in the Mir 2.4.1-0ubuntu1 build log:
  https://launchpadlibrarian.net/546972958/buildlog_ubuntu-impish-
  ppc64el.mir_2.4.1-0ubuntu1_BUILDING.txt.gz )

  Installing umockdev 0.15.4-1 and libumockdev0 0.15.4-1 from hirsute
  results in those tests passing.

  Strangely, rebuilding umockdev 0.15.4-1 in a hirsute sbuild
  environment results in packages that do *not* pass those tests,
  suggesting a toolchain change might be responsible.

  Unfortunately, I've tried rebuilding umockdev with gcc-9, gcc-11, and
  vala 0.48.12-1 in Impish and none of these appear to work.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: umockdev 0.16.1-1
  ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-generic 5.11.21
  Uname: Linux 5.11.0-20-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 16:04:15 2021
  InstallationDate: Installed on 2021-06-26 (11 days ago)
  InstallationMedia: Ubuntu 21.10.0 2021.05.28 amd64 "bcachefs" (20210622)
  SourcePackage: umockdev
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1934995/+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


[Touch-packages] [Bug 1934995] Re: Broken on ppc64el (toolchain bug?)

2021-07-08 Thread Martin Pitt
Dang, we already found a ppc64el SIGBUS issue in 0.16.0, which got fixed
in https://github.com/martinpitt/umockdev/commit/277c80243a . But this
is reported against 0.16.1 already.

There is a tiny chance that
https://github.com/martinpitt/umockdev/commit/264cabbb will magically
fix this, but otherwise this needs some investigation. I.e. not known
upstream yet.

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

Title:
  Broken on ppc64el (toolchain bug?)

Status in umockdev package in Ubuntu:
  New

Bug description:
  umockdev appears to be broken on ppc64el in impish. Running it on one
  of Mir's umockdev-using tests results in:

  (impish-ppc64el)root@juju-deb017-porterbox-1:/build/mir-Xn1VqE/umockdev# 
umockdev-run ../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests
  MIR_CLIENT_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/client-modules/
  MIR_SERVER_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/server-modules/
  LD_LIBRARY_PATH=../mir-2.4.1/build-ppc64el/bin/../lib
  exec=../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests.bin
  *** stack smashing detected ***: terminated
  umockdev-run: unable to propagate signal 6 to child 15833: No such process

  (You can also see this in the Mir 2.4.1-0ubuntu1 build log:
  https://launchpadlibrarian.net/546972958/buildlog_ubuntu-impish-
  ppc64el.mir_2.4.1-0ubuntu1_BUILDING.txt.gz )

  Installing umockdev 0.15.4-1 and libumockdev0 0.15.4-1 from hirsute
  results in those tests passing.

  Strangely, rebuilding umockdev 0.15.4-1 in a hirsute sbuild
  environment results in packages that do *not* pass those tests,
  suggesting a toolchain change might be responsible.

  Unfortunately, I've tried rebuilding umockdev with gcc-9, gcc-11, and
  vala 0.48.12-1 in Impish and none of these appear to work.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: umockdev 0.16.1-1
  ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-generic 5.11.21
  Uname: Linux 5.11.0-20-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  8 16:04:15 2021
  InstallationDate: Installed on 2021-06-26 (11 days ago)
  InstallationMedia: Ubuntu 21.10.0 2021.05.28 amd64 "bcachefs" (20210622)
  SourcePackage: umockdev
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1934995/+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


[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-02-26 Thread Martin Pitt
I've been scratching my head over this regression [1] for a while now,
in the context of running a hirsute container on a 20.04 host (in
particular, a GitHub workflow machine) In my case, the symptom is that
after upgrading glibc, `which` is broken; that of course also uses
faccessat(), similar to test -x.

I tried all sorts of the "usual" workarounds, as seccomp has been giving
trouble for a while now [2]. But this failure is robust against fuse-
overlayfs vs. vfs (inefficient full copies of the file system), root vs.
user podman, podman vs. docker, and, relevant for this bug, it *also
happens* with --security-opt=seccomp=unconfined and/org --privileged,
both of which should disable seccomp.

Hence I believe this bug can't at least only be in libseccomp.


[1] 
https://github.com/martinpitt/umockdev/runs/1984769591?check_suite_focus=true#step:3:1019
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1900021

** Bug watch added: Red Hat Bugzilla #1900021
   https://bugzilla.redhat.com/show_bug.cgi?id=1900021

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

Title:
  test -x fails inside shell scripts in containers

Status in glibc package in Ubuntu:
  Triaged
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in glibc source package in Hirsute:
  Triaged
Status in libseccomp source package in Hirsute:
  Fix Committed

Bug description:
  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of
  them is required for this operation

  The simple Dockerfile to reproduce the error - "docker build -t foo ."

  FROM amd64/ubuntu:hirsute
  MAINTAINER Florian Lohoff 

  USER root

  RUN apt-get update \
   && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \
    && curl https://syncthing.net/release-key.txt | apt-key add -

  Breaking it down it this seems to be an issue that there is new
  functionality in apt/apt-key e.g. security hardening that docker
  prohibits in its containers. Running this manually works only in an
  --privileged container.

  So adding keys in unpriviledged container or possibly kubernetes will
  not work anymore.

  Flo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+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


[Touch-packages] [Bug 1831467] Re: test-umockdev tests flaky on armhf (and sometimes other archs)

2020-07-29 Thread Martin Pitt
https://salsa.debian.org/debian/umockdev/-/commit/87b476aee2 should
hopefully help. I uploaded 0.14.2 to Debian unstable now, it should
auto-sync into Groovy soon. Thanks  Dan for tackling this!

** Changed in: umockdev (Ubuntu Groovy)
   Status: In Progress => Fix Committed

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

Title:
  test-umockdev tests flaky on armhf (and sometimes other archs)

Status in umockdev package in Ubuntu:
  Fix Committed
Status in umockdev source package in Xenial:
  In Progress
Status in umockdev source package in Bionic:
  In Progress
Status in umockdev source package in Focal:
  In Progress
Status in umockdev source package in Groovy:
  Fix Committed

Bug description:
  [impact]

  these tests fail intermittently, due to various timing issues, as well
  as an actual code bug in how data fuzz is calculated.

  it looks like the failures are mostly on armhf, but do happen less
  often on other archs.

  [test case]

  check the previous autopkgtest logs, e.g.
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/armhf/u/umockdev/20190601_015323_8f795@/log.gz

  [regression potential]

  any regression would likely result in incorrectly failing/passing 
autopkgtests, or in a incorrect pass or incorrect fail of the ScriptRunner
  to verify the data's level of fuzz.

  [scope]

  as the tests are flaky on armhf all the way back to trusty, this is
  needed for all releases.

  [other info]

  Fixed upstream in PR https://github.com/martinpitt/umockdev/pull/103

  Most of the changes are test case fixes, but there is one fix to
  source code to fix the ScriptRunning function that validates the level
  of fuzz in data, so this is not *only* a testcase fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1831467/+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


[Touch-packages] [Bug 1837233] Re: [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
Nevermind then, this is working well enough for a stable release.

** Changed in: network-manager (Ubuntu Bionic)
   Status: New => Won't Fix

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Won't Fix

Bug description:
  I have a system connection like this:

  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266

  [ethernet]
  mac-address-blacklist=

  [ipv4]
  dns-search=
  method=shared

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -

  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.

  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium

  (There, the file is called eth2.nmconnection, but same difference)

  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium

  Restarting NetworkManager does not help, nor does rebooting.

  DistroRelease: Ubuntu 18.04
  Package: 1.10.6-2ubuntu1.1
  Architecture: amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1837233/+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


[Touch-packages] [Bug 1837233] Re: [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
I confirm that using a valid IP works better:

In the config:

route1=fe80:2::/60,fe80::99,42

# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
fe80:2::/60 via fe80::99 proto static metric 42 pref medium

It's still missing the route to fe80:2:: itself, though.

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Won't Fix

Bug description:
  I have a system connection like this:

  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266

  [ethernet]
  mac-address-blacklist=

  [ipv4]
  dns-search=
  method=shared

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -

  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.

  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium

  (There, the file is called eth2.nmconnection, but same difference)

  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium

  Restarting NetworkManager does not help, nor does rebooting.

  DistroRelease: Ubuntu 18.04
  Package: 1.10.6-2ubuntu1.1
  Architecture: amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1837233/+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


[Touch-packages] [Bug 1837233] Re: [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
The journal says why:

NetworkManager[1295]:   [1563552648.1667] platform: route-sync: failure 
to add IPv6 route: 1:2::/60 via 1:2::3 dev 6 metric 42 mss 0 rt-src user: No 
route to host (113)
NetworkManager[1295]:   [1563552648.1672] device (eth2): failed to apply 
manual IPv6 configuration

Apparently later versions ignore non-reachable hosts and set the route
anyway?


** Description changed:

  I have a system connection like this:
  
  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266
  
  [ethernet]
  mac-address-blacklist=
  
  [ipv4]
  dns-search=
  method=shared
  
  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -
  
  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.
  
  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium
  
  (There, the file is called eth2.nmconnection, but same difference)
  
  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101
  
  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium
  
  Restarting NetworkManager does not help, nor does rebooting.
+ 
+ DistroRelease: Ubuntu 18.04
+ Package: 1.10.6-2ubuntu1.1
+ Architecture: amd64

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Won't Fix

Bug description:
  I have a system connection like this:

  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266

  [ethernet]
  mac-address-blacklist=

  [ipv4]
  dns-search=
  method=shared

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -

  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.

  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
  # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium

  (There, the file is called eth2.nmconnection, but same difference)

  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:

  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref 

[Touch-packages] [Bug 1837233] [NEW] [bionic] Manual IPv6 routes are not set

2019-07-19 Thread Martin Pitt
Public bug reported:

I have a system connection like this:

-- /etc/NetworkManager/system-connections/eth2  ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266

[ethernet]
mac-address-blacklist=

[ipv4]
dns-search=
method=shared

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -

In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus,  I'm just using this to test cockpit's
web UI.

On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:

# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 }
IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
# ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium

(There, the file is called eth2.nmconnection, but same difference)

On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:

# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 }
IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101

# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium

Restarting NetworkManager does not help, nor does rebooting.

DistroRelease: Ubuntu 18.04
Package: 1.10.6-2ubuntu1.1
Architecture: amd64

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: network-manager (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Also affects: network-manager (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: network-manager (Ubuntu)
   Status: New => Fix Released

** Description changed:

  I have a system connection like this:
  
  -- /etc/NetworkManager/system-connections/eth2  ---
  [connection]
  id=eth2
  uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
  type=ethernet
  gateway-ping-timeout=12
  interface-name=eth2
  permissions=
  timestamp=1563551266
  
  [ethernet]
  mac-address-blacklist=
  
  [ipv4]
  dns-search=
  method=shared
  
  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  ignore-auto-routes=true
  method=auto
  route1=1:2::/60,1:2::3,42
  -- 8< -
  
  In particular, the last line (route1=) which sets a manual IPv6 route.
  Of course this is rather bogus,  I'm just using this to test cockpit's
  web UI.
  
  On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 101
  IP6.ROUTE[2]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[3]:   dst = 1:2::3/128, nh = ::, mt = 42
  IP6.ROUTE[4]:   dst = 1:2::/60, nh = 1:2::3, mt = 42
  [...]
-  ip -6 route show dev eth2
+ # ip -6 route show dev eth2
  1:2::3 proto static metric 42 pref medium
  1:2::/60 via 1:2::3 proto static metric 42 pref medium
  fe80::/64 proto kernel metric 101 pref medium
  
  (There, the file is called eth2.nmconnection, but same difference)
  
  On Ubuntu 18.04 however, the route manual is ignored, and only the
  automatic link-local one exists:
  
  # nmcli c show eth2
  ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 
}
  IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, 
table=255
  IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256
  IP6.ROUTE[3]:   dst = fe80::/64, nh = ::, mt = 101
  
  # ip -6 route show dev eth2
  fe80::/64 proto kernel metric 101 pref medium
  fe80::/64 proto kernel metric 256 pref medium
  
  Restarting NetworkManager does not help, nor does rebooting.

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

Title:
  [bionic] Manual IPv6 routes are not set

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  New

Bug description:
  I have a 

[Touch-packages] [Bug 1831296] Re: __main__.SeccompTest is failing on Ubuntu CI

2019-06-25 Thread Martin Pitt
Thanks Dan! I landed your PR, so it should apply to the next upstream CI
run.

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
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/1831296

Title:
  __main__.SeccompTest is failing on Ubuntu CI

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  Since https://github.com/systemd/systemd/pull/12430 was merged and
  libsecomp was updated the test has been failing on Ubuntu CI:
  https://github.com/systemd/systemd/issues/12709. By analogy with
  
https://github.com/systemd/systemd/pull/12430/commits/c3ab2c389ee60d92fb8d7fe779ae9c4e3c092e4c,
  the test should look for either "killed" or "dumped".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831296/+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


[Touch-packages] [Bug 1829829] Re: Ubuntu CI has been flaky for a week

2019-05-21 Thread Martin Pitt
Indeed the downstream tests fail like this as well:
http://autopkgtest.ubuntu.com/packages/systemd/eoan/amd64

-- 
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/1829829

Title:
  Ubuntu CI has been flaky for a week

Status in systemd package in Ubuntu:
  New

Bug description:
  It was originally reported in 
https://github.com/systemd/systemd/pull/12583#issuecomment-492949206 5 days 
ago. To judge from the logs VMs can't be rebooted there:
  ```
  Ubuntu 18.04.2 LTS autopkgtest ttyS0

  autopkgtest login:
  ---
  --- nova show 91e76a78-d05c-412a-b383-55a26010ae69 
(adt-bionic-amd64-systemd-upstream-20190516-051604) --
  
+--++
  | Property | Value
  |
  
+--++
  | OS-DCF:diskConfig| MANUAL   
  |
  | OS-EXT-AZ:availability_zone  | nova 
  |
  | OS-EXT-SRV-ATTR:host | euler
  |
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | euler.lcy01.scalingstack 
  |
  | OS-EXT-SRV-ATTR:instance_name| instance-003d216a
  |
  | OS-EXT-STS:power_state   | 1
  |
  | OS-EXT-STS:task_state| -
  |
  | OS-EXT-STS:vm_state  | active   
  |
  | OS-SRV-USG:launched_at   | 2019-05-16T07:00:42.00   
  |
  | OS-SRV-USG:terminated_at | -
  |
  | accessIPv4   |  
  |
  | accessIPv6   |  
  |
  | config_drive |  
  |
  | created  | 2019-05-16T07:00:33Z 
  |
  | flavor   | autopkgtest 
(f878e70e-9991-46e0-ba02-8ea159a71656) |
  | hostId   | 
1722c5f2face86c3fc9f338ae96835924721512372342f664e6941bd
   |
  | id   | 91e76a78-d05c-412a-b383-55a26010ae69 
  |
  | image| 
adt/ubuntu-bionic-amd64-server-20190516.img 
(d00bf12c-467e-433f-a4f5-15720f13bff1) |
  | key_name | 
testbed-juju-prod-ues-proposed-migration-machine-11 
   |
  | metadata | {}   
  |
  | name | 
adt-bionic-amd64-systemd-upstream-20190516-051604   
   |
  | net_ues_proposed_migration network   | 10.42.40.13  
  |
  | os-extended-volumes:volumes_attached | []   
  |
  | progress | 0
  |
  | security_groups  | autopkgtest@lcy01-27.secgroup
  |
  | status   | ACTIVE   
  |
  | tenant_id| afaef86b96dd4828a1ed5ee395ea1421 
  |
  | updated  | 2019-05-16T07:00:42Z 
  |
  | user_id  | 8524250971084851b3792a68fbc398dd 
  |
  

[Touch-packages] [Bug 1819589] Re: Ubuntu CI is broken

2019-03-12 Thread Martin Pitt
That worked.

** Changed in: systemd (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
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/1819589

Title:
  Ubuntu CI is broken

Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  Since 
https://salsa.debian.org/systemd-team/systemd/commit/8d810fda9a640a932d6e7b32afd958fe75e36f5b
 was merged Ubuntu CI has been failing with
  ```
  Investigating (0) udev:amd64 < 237-3ubuntu10.13 -> 241-608-gfd541a5f08-0 @ii 
pumU Ib >
  Broken udev:amd64 Depends on dpkg:amd64 < 1.19.0.5ubuntu2.1 @ii mK > (>= 
1.19.3)
  Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   udev : Depends: dpkg (>= 1.19.3) but 1.19.0.5ubuntu2.1 is to be installed
  W: --force-yes is deprecated, use one of the options starting with --allow 
instead.
  E: Unable to correct problems, you have held broken packages.
  blame: https://salsa.debian.org/systemd-team/systemd.git
  badpkg: installation of basic binaries failed, exit code 100
  autopkgtest [18:37:50]: ERROR: erroneous package: installation of basic 
binaries failed, exit code 100
  Exit request sent.^M
  Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from 
image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 
2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)...
  Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from 
image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 
2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)...
  ```

  It's also being discussed in
  https://github.com/systemd/systemd/pull/11963.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819589/+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


[Touch-packages] [Bug 1819589] Re: Ubuntu CI is broken

2019-03-12 Thread Martin Pitt
Should be fixed with https://salsa.debian.org/systemd-
team/systemd/commit/bd89a706b18796074d50bcf2a0cbd29de56ac542 . I'll
close this once the retried PRs go green.

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Martin Pitt (pitti)

** Changed in: systemd (Ubuntu)
   Status: New => Fix Committed

** Changed in: systemd (Ubuntu)
   Importance: Undecided => High

-- 
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/1819589

Title:
  Ubuntu CI is broken

Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  Since 
https://salsa.debian.org/systemd-team/systemd/commit/8d810fda9a640a932d6e7b32afd958fe75e36f5b
 was merged Ubuntu CI has been failing with
  ```
  Investigating (0) udev:amd64 < 237-3ubuntu10.13 -> 241-608-gfd541a5f08-0 @ii 
pumU Ib >
  Broken udev:amd64 Depends on dpkg:amd64 < 1.19.0.5ubuntu2.1 @ii mK > (>= 
1.19.3)
  Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   udev : Depends: dpkg (>= 1.19.3) but 1.19.0.5ubuntu2.1 is to be installed
  W: --force-yes is deprecated, use one of the options starting with --allow 
instead.
  E: Unable to correct problems, you have held broken packages.
  blame: https://salsa.debian.org/systemd-team/systemd.git
  badpkg: installation of basic binaries failed, exit code 100
  autopkgtest [18:37:50]: ERROR: erroneous package: installation of basic 
binaries failed, exit code 100
  Exit request sent.^M
  Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from 
image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 
2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)...
  Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from 
image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 
2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)...
  ```

  It's also being discussed in
  https://github.com/systemd/systemd/pull/11963.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819589/+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


[Touch-packages] [Bug 1817344] Re: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results

2019-02-24 Thread Martin Pitt
Thanks Iain! I'll keep an eye on this.

-- 
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/1817344

Title:
  Ubuntu CI that runs tests via autopkgtest for systemd on GitHub
  reports the wrong results

Status in Auto Package Testing:
  Fix Released
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure this is the right place to report this, but apparently
  it's the best way to reach out to Dimitri John Ledkov
  (https://github.com/xnox) and Iain Lane (https://github.com/iainlane),
  who I believe at least know who maintains Ubuntu CI there.

  I'm copying the following verbatim from
  https://github.com/systemd/systemd/pull/11531#issuecomment-464731263
  (where we are kind of discussing the issue):

  > The two PRs you referenced to fail in the `make check` unit tests
  (test-path).

  That's correct that test-path failed but it failed in
  https://github.com/systemd/systemd/pull/11685 while Ubuntu CI reported
  it in https://github.com/systemd/systemd/pull/11686 (that is, in
  https://github.com/systemd/systemd/pull/11686 in the logs for some
  reason UPSTREAM_PULL_REQUEST is 11685 instead of 11686 and something
  like that has happened often lately).

  In
  https://github.com/systemd/systemd/pull/11743#issuecomment-464637797,
  the issue is that Ubuntu CI showed the results for the first version
  of the PR (where there was a bug) and it didn't run the tests against
  the latest version. But in that case it's hard to tell because there
  is no way to figure out what exactly Ubuntu CI tested. That's why I
  asked @xnox to add `git describe` to https://salsa.debian.org/systemd-
  team/systemd/blob/master/debian/extra/checkout-upstream so that by
  looking at UPSTREAM_PULL_REQUEST and the output of `git describe` it
  would be possible to find out what Ubuntu CI reports.

To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/1817344/+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


[Touch-packages] [Bug 1817344] Re: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results

2019-02-24 Thread Martin Pitt
Another example: https://github.com/systemd/systemd/pull/11802 refers to
the correct amd64 log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
/autopkgtest-bionic-upstream-systemd-ci-systemd-ci/bionic/amd64/s
/systemd-upstream/20190222_161608_7fe1f@/log.gz .

But https://github.com/systemd/systemd/pull/11804 refers to the exact
same log. It is also the only result for 11804:
https://api.github.com/repos/systemd/systemd/statuses/b427959d65ba0edff385146d38825bb169458554

-- 
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/1817344

Title:
  Ubuntu CI that runs tests via autopkgtest for systemd on GitHub
  reports the wrong results

Status in autopkgtest-cloud:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure this is the right place to report this, but apparently
  it's the best way to reach out to Dimitri John Ledkov
  (https://github.com/xnox) and Iain Lane (https://github.com/iainlane),
  who I believe at least know who maintains Ubuntu CI there.

  I'm copying the following verbatim from
  https://github.com/systemd/systemd/pull/11531#issuecomment-464731263
  (where we are kind of discussing the issue):

  > The two PRs you referenced to fail in the `make check` unit tests
  (test-path).

  That's correct that test-path failed but it failed in
  https://github.com/systemd/systemd/pull/11685 while Ubuntu CI reported
  it in https://github.com/systemd/systemd/pull/11686 (that is, in
  https://github.com/systemd/systemd/pull/11686 in the logs for some
  reason UPSTREAM_PULL_REQUEST is 11685 instead of 11686 and something
  like that has happened often lately).

  In
  https://github.com/systemd/systemd/pull/11743#issuecomment-464637797,
  the issue is that Ubuntu CI showed the results for the first version
  of the PR (where there was a bug) and it didn't run the tests against
  the latest version. But in that case it's hard to tell because there
  is no way to figure out what exactly Ubuntu CI tested. That's why I
  asked @xnox to add `git describe` to https://salsa.debian.org/systemd-
  team/systemd/blob/master/debian/extra/checkout-upstream so that by
  looking at UPSTREAM_PULL_REQUEST and the output of `git describe` it
  would be possible to find out what Ubuntu CI reports.

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopkgtest-cloud/+bug/1817344/+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


[Touch-packages] [Bug 1817344] Re: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results

2019-02-24 Thread Martin Pitt
It seems to me that the logs are internally consistent, i. e. the
mentioned UPSTREAM_PULL_REQUEST in the log does match the test results.
But they get sent to the wrong PR, i. e. to the wrong statuses API.

E. g.
https://api.github.com/repos/systemd/systemd/commits/99894b867f1293f56d181d62f5015c5a0a8adbda/status
was triggered by https://github.com/systemd/systemd/pull/11682 but the
referenced logs are for  PR #11767. This caused the landing of a
regression (that the tests would have noticed).

** Package changed: autopkgtest (Ubuntu) => autopkgtest-cloud

-- 
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/1817344

Title:
  Ubuntu CI that runs tests via autopkgtest for systemd on GitHub
  reports the wrong results

Status in autopkgtest-cloud:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure this is the right place to report this, but apparently
  it's the best way to reach out to Dimitri John Ledkov
  (https://github.com/xnox) and Iain Lane (https://github.com/iainlane),
  who I believe at least know who maintains Ubuntu CI there.

  I'm copying the following verbatim from
  https://github.com/systemd/systemd/pull/11531#issuecomment-464731263
  (where we are kind of discussing the issue):

  > The two PRs you referenced to fail in the `make check` unit tests
  (test-path).

  That's correct that test-path failed but it failed in
  https://github.com/systemd/systemd/pull/11685 while Ubuntu CI reported
  it in https://github.com/systemd/systemd/pull/11686 (that is, in
  https://github.com/systemd/systemd/pull/11686 in the logs for some
  reason UPSTREAM_PULL_REQUEST is 11685 instead of 11686 and something
  like that has happened often lately).

  In
  https://github.com/systemd/systemd/pull/11743#issuecomment-464637797,
  the issue is that Ubuntu CI showed the results for the first version
  of the PR (where there was a bug) and it didn't run the tests against
  the latest version. But in that case it's hard to tell because there
  is no way to figure out what exactly Ubuntu CI tested. That's why I
  asked @xnox to add `git describe` to https://salsa.debian.org/systemd-
  team/systemd/blob/master/debian/extra/checkout-upstream so that by
  looking at UPSTREAM_PULL_REQUEST and the output of `git describe` it
  would be possible to find out what Ubuntu CI reports.

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopkgtest-cloud/+bug/1817344/+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


[Touch-packages] [Bug 1787396] Re: ss crashes when using --no-header

2018-11-30 Thread Martin Pitt
I confirm this on Ubuntu 18.04 (bionic) with 4.15.0-2ubuntu1. It is
fixed in 18.10 (cosmic) with  4.18.0-1ubuntu2.

** Also affects: iproute2 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: iproute2 (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: iproute2 (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  ss crashes when using --no-header

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Confirmed

Bug description:
  Steps to reproduce:

  1) Listen on port 8989:
  $ nc -l 8989 &

  2) Check that ss can list this listener:
  $ ss --no-header -nto state listening 'sport = 8989'
  010.0.0.0:8989  0.0.0.0:*

  3) Ask ss to list listeners on a port where nothing listens
  $ kill %1 # stops nc
  $ ss --no-header -nto state listening 'sport = 8989'
  Segmentation fault (core dumped)

  In the above, removing "--no-header" avoids the segfault.

  
  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy iproute2
  iproute2:
Installed: 4.15.0-2ubuntu1
Candidate: 4.15.0-2ubuntu1
Version table:
   *** 4.15.0-2ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: iproute2 4.15.0-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 16 08:17:52 2018
  InstallationDate: Installed on 2018-07-15 (32 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  SourcePackage: iproute2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1787396/+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


[Touch-packages] [Bug 1750654] [NEW] "lxc-create -B best" fails on non-btrfs/zfs system

2018-02-20 Thread Martin Pitt
Public bug reported:

As per documentation, the `-B best` option should automatically select
the best backingstore, falling back all the way to dir.

But apparently it doesn't, at least not in artful's 2.1.0-0ubuntu1:

$ sudo lxc-create -B best --name=autopkgtest-xenial -t ubuntu -- -r xenial
lxc-create: autopkgtest-xenial: storage/btrfs.c: btrfs_create: 860 
Inappropriate ioctl for device - Failed to create btrfs subvolume 
"/var/lib/lxc/autopkgtest-xenial/rootfs"
lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_create: 758 Failed to create 
zfs dataset "zfs:lxc/autopkgtest-xenial": lxc-create: autopkgtest-xenial: 
utils.c: run_command: 2326 failed to exec command
lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_mount: 256 No such file or 
directory - Failed to mount "lxc/autopkgtest-xenial" on 
"/usr/lib/x86_64-linux-gnu/lxc"
lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1294 
Failed to mount rootfs
lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1473 
container creation template for autopkgtest-xenial failed
lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_destroy: 613 Failed to 
detect zfs dataset "lxc/autopkgtest-xenial": lxc-create: autopkgtest-xenial:
lxc-create: autopkgtest-xenial: lxccontainer.c: container_destroy: 2653 Error 
destroying rootfs for autopkgtest-xenial
lxc-create: autopkgtest-xenial: tools/lxc_create.c: main: 326 Error creating 
container autopkgtest-xenial

Moreover, it creates cruft which is hard to clean up again:

$ sudo lxc-ls -f
NAME   STATE   AUTOSTART GROUPS IPV4 IPV6 
autopkgtest-xenial STOPPED 0 -  --

$ sudo lxc-destroy -n autopkgtest-xenial
lxc-destroy: autopkgtest-xenial: storage/zfs.c: zfs_destroy: 613 Failed to 
detect zfs dataset "lxc/autopkgtest-xenial": lxc-destroy: autopkgtest-xenial: 
utils.c: run_command: 2326 failed to exec command
lxc-destroy: autopkgtest-xenial: lxccontainer.c: container_destroy: 2653 Error 
destroying rootfs for autopkgtest-xenial
Destroying autopkgtest-xenial failed

$ sudo ls -lR /var/lib/lxc/autopkgtest-xenial
/var/lib/lxc/autopkgtest-xenial:
total 8
-rw-r--r-- 1 root root  149 Feb 20 20:41 config
drwxr-xr-x 2 root root 4096 Feb 20 20:41 rootfs

/var/lib/lxc/autopkgtest-xenial/rootfs:
total 0

This can only be cleaned up with `sudo rm -r`.

autopkgtest-build-lxc uses this option to get performant containers out
of the box. Arguably `-B best` is a sort of "unbreak my containers"
option and should always implicitly be used, but is there something else
that I should do here?

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: lxc 2.1.0-0ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
Uname: Linux 4.13.0-32-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
Date: Tue Feb 20 20:38:55 2018
JournalErrors:
 Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000'] 
failed with exit code 1: Hint: You are currently not seeing messages from other 
users and the system.
   Users in the 'systemd-journal' group can see all messages. Pass -q to
   turn off this notice.
 No journal files were opened due to insufficient permissions.
PackageArchitecture: all
SourcePackage: lxc
UpgradeStatus: No upgrade log present (probably fresh install)
defaults.conf:
 lxc.net.0.type = veth
 lxc.net.0.link = lxcbr0
 lxc.net.0.flags = up
 lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx
lxcsyslog:

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apparmor apport-bug artful

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

Title:
  "lxc-create -B best" fails on non-btrfs/zfs system

Status in lxc package in Ubuntu:
  New

Bug description:
  As per documentation, the `-B best` option should automatically select
  the best backingstore, falling back all the way to dir.

  But apparently it doesn't, at least not in artful's 2.1.0-0ubuntu1:

  $ sudo lxc-create -B best --name=autopkgtest-xenial -t ubuntu -- -r xenial
  lxc-create: autopkgtest-xenial: storage/btrfs.c: btrfs_create: 860 
Inappropriate ioctl for device - Failed to create btrfs subvolume 
"/var/lib/lxc/autopkgtest-xenial/rootfs"
  lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_create: 758 Failed to 
create zfs dataset "zfs:lxc/autopkgtest-xenial": lxc-create: 
autopkgtest-xenial: utils.c: run_command: 2326 failed to exec command
  lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_mount: 256 No such file or 
directory - Failed to mount "lxc/autopkgtest-xenial" on 
"/usr/lib/x86_64-linux-gnu/lxc"
  lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1294 
Failed to mount rootfs
  lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1473 
container creation template for autopkgtest-xenial failed
  lxc-create: autopkgtest-xenial: 

[Touch-packages] [Bug 1707898] Re: systemd translations are not synced with upstream

2018-02-19 Thread Martin Pitt
Thanks Gunnar, nice work! I cherry-picked the patches in
https://salsa.debian.org/systemd-team/systemd/commit/87f54958bc24 . The
debian/ changes were already in Debian master.

** Changed in: systemd (Ubuntu)
   Status: In Progress => Fix Committed

-- 
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/1707898

Title:
  systemd translations are not synced with upstream

Status in systemd:
  Fix Released
Status in Ubuntu Translations:
  New
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  Translations for systemd are outdated because they do not seem to be
  synced with the upstream ones.

  For example the Czech one:
  Launchpad: 
https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate
 - 0% translated
  Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% 
translated

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1707898/+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


[Touch-packages] [Bug 1707898] Re: systemd translations are not synced with upstream

2018-02-15 Thread Martin Pitt
I confirmed that the current "ninja -C build-deb/ systemd-pot" command
also builds a complete .pot file with policykit-1 installed
(unsurprisingly, as this also just calls gettext). So that part is fine.

What is really bad however, is to build-depend against policykit-1:

The following NEW packages will be installed:
  cgmanager dbus libcgmanager0 libnih-dbus1 libnih1 libpam-systemd 
libpolkit-backend-1-0 libprocps6 policykit-1 procps systemd
  systemd-shim

This is an awful lot to pull into a buildd schroot, in particular it
makes systemd build-depend on itself. I'd really like to avoid that.

Are the files /usr/share/gettext/its/polkit.{its,loc} only being used at
build time, or does polkit need these at runtime for dynamic gettext
translations? My gut feeling is that it's the former, and then it would
make sense to move these two into libpolkit-gobject-1-dev instead.
systemd already build-depends on that, thus it will automatically pick
these up.

-- 
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/1707898

Title:
  systemd translations are not synced with upstream

Status in systemd:
  New
Status in Ubuntu Translations:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Translations for systemd are outdated because they do not seem to be
  synced with the upstream ones.

  For example the Czech one:
  Launchpad: 
https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate
 - 0% translated
  Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% 
translated

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1707898/+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


[Touch-packages] [Bug 1707898] Re: systemd translations are not synced with upstream

2018-02-15 Thread Martin Pitt
Thanks Gunnar for tracking this down! Adding a policykit-1 build
dependency requires some thought, as that also build-depends on systemd
[1], thus this is circular. Also, there was a lot of effort with making
systemd bootstrappable without excessive dependencies. But I think it's
fine to add this as a [!stage1] b-dep.

[1] https://anonscm.debian.org/cgit/pkg-
utopia/policykit.git/tree/debian/control

-- 
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/1707898

Title:
  systemd translations are not synced with upstream

Status in systemd:
  New
Status in Ubuntu Translations:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Translations for systemd are outdated because they do not seem to be
  synced with the upstream ones.

  For example the Czech one:
  Launchpad: 
https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate
 - 0% translated
  Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% 
translated

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1707898/+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


[Touch-packages] [Bug 1707898] Re: systemd translations are not synced with upstream

2018-02-14 Thread Martin Pitt
@Gunnar: This patch does not actually work:

❱❱❱ xgettext -f "po/POTFILES.in" -o "build-deb/po/systemd.pot" --join-existing
xgettext: warning: file 'src/core/org.freedesktop.systemd1.policy.in.in' 
extension 'policy' is unknown; will try C
xgettext: warning: file 'src/hostname/org.freedesktop.hostname1.policy.in' 
extension 'policy' is unknown; will try C
xgettext: warning: file 'src/import/org.freedesktop.import1.policy.in' 
extension 'policy' is unknown; will try C
xgettext: warning: file 'src/locale/org.freedesktop.locale1.policy.in' 
extension 'policy' is unknown; will try C
xgettext: warning: file 'src/login/org.freedesktop.login1.policy.in' extension 
'policy' is unknown; will try C
xgettext: warning: file 'src/machine/org.freedesktop.machine1.policy.in' 
extension 'policy' is unknown; will try C
xgettext: warning: file 'src/timedate/org.freedesktop.timedate1.policy.in' 
extension 'policy' is unknown; will try C

And systemd.pot is unchanged.

I now committed https://salsa.debian.org/systemd-
team/systemd/commit/09c6423728319 to simplify the .pot generation, but
it has the exact same issue.

-- 
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/1707898

Title:
  systemd translations are not synced with upstream

Status in systemd:
  New
Status in Ubuntu Translations:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Translations for systemd are outdated because they do not seem to be
  synced with the upstream ones.

  For example the Czech one:
  Launchpad: 
https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate
 - 0% translated
  Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% 
translated

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1707898/+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


[Touch-packages] [Bug 1707898] Re: systemd translations are not synced with upstream

2018-02-12 Thread Martin Pitt
I committed the first hunk to Debian, this makes sense:
https://salsa.debian.org/systemd-team/systemd/commit/18d8c2df133b8af

The second is too hackish for a permanent downstream delta, IMHO: This
should rather be fixed upstream, as upstream polkit (as well as Debian's
and Ubuntu's older versions) have proper runtime gettext support.

-- 
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/1707898

Title:
  systemd translations are not synced with upstream

Status in Ubuntu Translations:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Translations for systemd are outdated because they do not seem to be
  synced with the upstream ones.

  For example the Czech one:
  Launchpad: 
https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate
 - 0% translated
  Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% 
translated

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-translations/+bug/1707898/+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


[Touch-packages] [Bug 1727202] Re: [17.10 regression] AppArmor ntp denial: Failed name lookup - disconnected path

2018-01-04 Thread Martin Pitt
The most plausible explanation for enumerating /usr/local/bin/ is that
ntpd has some hooks.d/ mechanism which gets called after syncing the
time, and that runs a shell in between. So IMHO this should be allowed.

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

Title:
  [17.10 regression] AppArmor ntp denial: Failed name lookup -
  disconnected path

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Invalid
Status in ntp source package in Zesty:
  Invalid
Status in ntp source package in Artful:
  Fix Released
Status in ntp source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * NTP has new isolation features which makes it trigger apparmor issues.
   * Those apparmor issues not only clutter the log and make other things
     less readable, they also prevent ntp from reporting its actual
     messages.
   * Fix is opening the apparmor profile to follow ntp through the
     disconnect by the isolation feature.

  [Test Case]

   * This is hard to trigger, but then also not. Which means it is not
     entirely sorted out when it triggers and when not, but the following
     does trigger it in tests of Pitti and also mine (while at the same time
     sometimes it does not - mabye I had other guests or kvm instead of lxd)

   * First install ntp in Artful (or above unless fixed)
     * Install ntp and check demsg for denies
     * Once an issue triggers instead of the error in syslog you'll see the
   apparmor Deny like:
     apparmor="DENIED" operation="sendmsg" info="Failed name lookup -
     disconnected path" error=-13 profile="/usr/sbin/ntpd"
     name="run/systemd/journal/dev-log" pid=5600 comm="ntpd"
     requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  [Regression Potential]

   * We are slightly opening up the apparmor profile which is far lower risk
     than adding more constraints. So safe from that POV.

   * OTOH one could think this might be a security issue, but in fact this
     isn't a new suggestion if you take a look at [1] with an ack by Seth of
     the Security Team.

  [Other Info]

   * n/a

  [1]: https://lists.ubuntu.com/archives/apparmor/2015-May/007858.html

  

  Merely installing and starting ntp.service in Ubuntu 17.10 now causes
  this AppArmor violation:

  audit: type=1400 audit(1508915894.215:25): apparmor="DENIED"
  operation="sendmsg" info="Failed name lookup - disconnected path"
  error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log"
  pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  (many times). This hasn't happened in earlier Ubuntu releases yet.

  This was spotted by Cockpit's integration tests, as our "ubuntu-
  stable" image now moved to 17.10 after its release.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ntp 1:4.2.8p10+dfsg-5ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  Date: Wed Oct 25 03:19:34 2017
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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


[Touch-packages] [Bug 1741227] Re: apparmor denial to several paths to binaries

2018-01-04 Thread Martin Pitt
The most plausible explanation for enumerating /usr/local/bin/ is that
ntpd has some hooks.d/ mechanism which gets called after syncing the
time, and that runs a shell in between. So IMHO this should be allowed.

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

Title:
  apparmor denial to several paths to binaries

Status in ntp package in Ubuntu:
  Confirmed

Bug description:
  Issue shows up (non fatal) as:
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/sbin/" pid=23933 comm="ntpd" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/bin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0

  Since non crit this is mostyl about many of us being curious why it
  actually does do it :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1741227/+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


[Touch-packages] [Bug 1727202] Re: [17.10 regression] AppArmor ntp denial: Failed name lookup - disconnected path

2018-01-03 Thread Martin Pitt
I locally ran Cockpit tests on our current Ubuntu 17.10 image and re-
confirm that I got the "disconnected path" error. I then upgraded the
ntp package to artful-proposed, and *that* violation is now gone. As
others already saw, I now get a test failure on

   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd"
name="/usr/local/sbin/" pid=5938 comm="ntpd" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0

But this is not a regression from this update, and unrelated. So this
SRU is good from my POV. Thanks!

** Tags removed: verification-needed-artful
** Tags added: verification-done-artful

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

Title:
  [17.10 regression] AppArmor ntp denial: Failed name lookup -
  disconnected path

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Invalid
Status in ntp source package in Zesty:
  Invalid
Status in ntp source package in Artful:
  Fix Committed
Status in ntp source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * NTP has new isolation features which makes it trigger apparmor issues.
   * Those apparmor issues not only clutter the log and make other things
     less readable, they also prevent ntp from reporting its actual
     messages.
   * Fix is opening the apparmor profile to follow ntp through the
     disconnect by the isolation feature.

  [Test Case]

   * This is hard to trigger, but then also not. Which means it is not
     entirely sorted out when it triggers and when not, but the following
     does trigger it in tests of Pitti and also mine (while at the same time
     sometimes it does not - mabye I had other guests or kvm instead of lxd)

   * First install ntp in Artful (or above unless fixed)
     * Install ntp and check demsg for denies
     * Once an issue triggers instead of the error in syslog you'll see the
   apparmor Deny like:
     apparmor="DENIED" operation="sendmsg" info="Failed name lookup -
     disconnected path" error=-13 profile="/usr/sbin/ntpd"
     name="run/systemd/journal/dev-log" pid=5600 comm="ntpd"
     requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  [Regression Potential]

   * We are slightly opening up the apparmor profile which is far lower risk
     than adding more constraints. So safe from that POV.

   * OTOH one could think this might be a security issue, but in fact this
     isn't a new suggestion if you take a look at [1] with an ack by Seth of
     the Security Team.

  [Other Info]

   * n/a

  [1]: https://lists.ubuntu.com/archives/apparmor/2015-May/007858.html

  

  Merely installing and starting ntp.service in Ubuntu 17.10 now causes
  this AppArmor violation:

  audit: type=1400 audit(1508915894.215:25): apparmor="DENIED"
  operation="sendmsg" info="Failed name lookup - disconnected path"
  error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log"
  pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  (many times). This hasn't happened in earlier Ubuntu releases yet.

  This was spotted by Cockpit's integration tests, as our "ubuntu-
  stable" image now moved to 17.10 after its release.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ntp 1:4.2.8p10+dfsg-5ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  Date: Wed Oct 25 03:19:34 2017
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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


[Touch-packages] [Bug 1727202] Re: [17.10 regression] AppArmor denial: Failed name lookup - disconnected path

2017-12-15 Thread Martin Pitt
Thanks Christian! Indeed this is rather hard to reproduce locally, but
that PR seems to address this. I'll let you know if it doesn't after it
lands.

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

Title:
  [17.10 regression] AppArmor denial: Failed name lookup - disconnected
  path

Status in ntp package in Ubuntu:
  Triaged
Status in ntp source package in Artful:
  New
Status in ntp source package in Bionic:
  Triaged

Bug description:
  Merely installing and starting ntp.service in Ubuntu 17.10 now causes
  this AppArmor violation:

  audit: type=1400 audit(1508915894.215:25): apparmor="DENIED"
  operation="sendmsg" info="Failed name lookup - disconnected path"
  error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log"
  pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  
  (many times). This hasn't happened in earlier Ubuntu releases yet.

  This was spotted by Cockpit's integration tests, as our "ubuntu-
  stable" image now moved to 17.10 after its release.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ntp 1:4.2.8p10+dfsg-5ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  Date: Wed Oct 25 03:19:34 2017
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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


[Touch-packages] [Bug 1153671] Re: Port to python3-launchpadlib

2017-11-30 Thread Martin Pitt
Once you do this, these fallbacks should be cleaned up:

http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L30
http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L137

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

Title:
  Port to python3-launchpadlib

Status in apport package in Ubuntu:
  Triaged

Bug description:
  Apport-cli depends on python3-launchpadlib for some actions, but it is
  not installable (currently). For example,

  apport-cli -u 542452
  ERROR: The launchpadlib Python module is not installed. This functionality is 
not available.

  The current candidates for installation on raring only include python-
  launchpadlib (which is python2 based).  I believe this bug is
  relevant:

  https://bugs.launchpad.net/launchpadlib/+bug/1060734

  I'm  filing this against apport in the event raring is shipped without
  a python3-launchpadlib package. I would recommend updating the error
  to make what is needing to be installed more clear. IE,

  ERROR: The launchpadlib Python3 module is not installed
  (python3-launchpadlib). This functionality is not available.

  Also consider adding the library as a suggested dependency.  In
  addition, should the package not land, further steps may be required.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1153671/+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


[Touch-packages] [Bug 1725348] Re: Systemd - Bypassing MemoryDenyWriteExecution policy

2017-11-14 Thread Martin Pitt
Patches backported into Debian packaging git:
https://anonscm.debian.org/cgit/pkg-
systemd/systemd.git/commit/?id=9bba5469f2b95ea9

-- 
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/1725348

Title:
  Systemd - Bypassing MemoryDenyWriteExecution policy

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Xenial:
  New
Status in systemd source package in Zesty:
  New
Status in systemd source package in Artful:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  Hello,

  We would like to report to you a vulnerability about systemd which
  allows to bypass the MemoryDenyWriteExecution policy on Linux 4.9+.

  The vulnerability is described in the attached PDF file.

  
  Sincerely, 
  Thomas IMBERT

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1725348/+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


[Touch-packages] [Bug 1727202] [NEW] [17.10 regression] AppArmor denial: Failed name lookup - disconnected path

2017-10-25 Thread Martin Pitt
Public bug reported:

Merely installing and starting ntp.service in Ubuntu 17.10 now causes
this AppArmor violation:

audit: type=1400 audit(1508915894.215:25): apparmor="DENIED"
operation="sendmsg" info="Failed name lookup - disconnected path"
error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log"
pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0


(many times). This hasn't happened in earlier Ubuntu releases yet.

This was spotted by Cockpit's integration tests, as our "ubuntu-stable"
image now moved to 17.10 after its release.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: ntp 1:4.2.8p10+dfsg-5ubuntu3
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3
Architecture: amd64
Date: Wed Oct 25 03:19:34 2017
SourcePackage: ntp
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: ntp (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apparmor apport-bug artful regression-release

** Tags added: regression-release

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

Title:
  [17.10 regression] AppArmor denial: Failed name lookup - disconnected
  path

Status in ntp package in Ubuntu:
  New

Bug description:
  Merely installing and starting ntp.service in Ubuntu 17.10 now causes
  this AppArmor violation:

  audit: type=1400 audit(1508915894.215:25): apparmor="DENIED"
  operation="sendmsg" info="Failed name lookup - disconnected path"
  error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log"
  pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  
  (many times). This hasn't happened in earlier Ubuntu releases yet.

  This was spotted by Cockpit's integration tests, as our "ubuntu-
  stable" image now moved to 17.10 after its release.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ntp 1:4.2.8p10+dfsg-5ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  Date: Wed Oct 25 03:19:34 2017
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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


[Touch-packages] [Bug 1574706] Re: Disabling the welcome wizard doesn’t dismiss it

2017-09-24 Thread Martin Pitt
With the demise of the Ubuntu phone (rest in peace, *tear*) this is
obsolete now.

** Changed in: autopkgtest (Ubuntu)
   Status: Incomplete => Won't Fix

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

Title:
  Disabling the welcome wizard doesn’t dismiss it

Status in autopkgtest package in Ubuntu:
  Won't Fix
Status in phablet-tools package in Ubuntu:
  New
Status in unity8 package in Ubuntu:
  New

Bug description:
  The autopkgtest helper script that sets up a phone for running
  autopilot tests
  (https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/ssh-
  setup/adb) disables the welcome wizard and edges intro.

  To disable the welcome wizard, it issues the following command:

  phablet-config welcome-wizard --disable

  Which under the covers creates the following file on the device:
  ~/.config/ubuntu-system-settings/wizard-has-run.

  Unity8 doesn’t seem to have any logic to discard the currently running
  wizard when that file is created (maybe on purpose?).

  This results in the phone under test still displaying the welcome
  wizard when control is handed off to the app’s autopkgtests, so
  autopilot tests will most likely fail because the app being launched
  is displayed under the wizard.

  I’m not sure whether not dismissing the wizard when the "wizard-has-
  run" file is being created is intentional. If it is, then the
  autopkgtest helper script needs additional logic to restart unity8 and
  unlock the screen.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1574706/+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


[Touch-packages] [Bug 1716034] Re: Network manager stops managing Ethernet links after upgrade

2017-09-11 Thread Martin Pitt
FTR, I don't want to blame the NetworkManager 1.2.6 SRU to xenial - that
new upstream version now evades the version test in the postinst, but of
course it's still that version test which is at fault. I don't see how
we can use a simple version test to determine the situation that we want
(one-time test after upgrading from 16.04 LTS), I suppose it needs to
move to "$2 is not empty" plus creating a migration stamp file
somewhere.

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

Title:
  Network manager stops managing Ethernet links after upgrade

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  After upgrading Ubuntu, it stopped configuring the word connection on
  my headless computer (super annoying to deal with). In any case, it
  was an issue with NM config change that caused my wired device to
  become unmanaged.

  There are several people discussing this here:
  https://askubuntu.com/questions/882806/ethernet-device-not-managed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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


[Touch-packages] [Bug 1716034] Re: Network manager stops managing Ethernet links after upgrade

2017-09-11 Thread Martin Pitt
I'm sorry, I mean bug 1676547.

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

Title:
  Network manager stops managing Ethernet links after upgrade

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  After upgrading Ubuntu, it stopped configuring the word connection on
  my headless computer (super annoying to deal with). In any case, it
  was an issue with NM config change that caused my wired device to
  become unmanaged.

  There are several people discussing this here:
  https://askubuntu.com/questions/882806/ethernet-device-not-managed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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


[Touch-packages] [Bug 1716034] Re: Network manager stops managing Ethernet links after upgrade

2017-09-11 Thread Martin Pitt
Is that any better with the fix in bug 1690992? That sounds very much
like a duplicate?

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

Title:
  Network manager stops managing Ethernet links after upgrade

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  After upgrading Ubuntu, it stopped configuring the word connection on
  my headless computer (super annoying to deal with). In any case, it
  was an issue with NM config change that caused my wired device to
  become unmanaged.

  There are several people discussing this here:
  https://askubuntu.com/questions/882806/ethernet-device-not-managed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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


[Touch-packages] [Bug 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:

2017-09-04 Thread Martin Pitt
I ran the description's test case and confirm that the crash is now
fixed. Furthermore, other operations like "pkcon refresh", "pkcon get-
updates", "pkcon update", and "pkcon install bash-doc" all worked fine,
as before.

** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done-xenial

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

Title:
  
/usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  Fix Committed

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
packagekit.  This problem was most recently seen with package version 
0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at 
https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker you can request it at 
http://forms.canonical.com/reports/.

  SRU INFORMATION
  ===
   * Impact: PackageKit immediately crashes in GetUpdateDetail()

   * Test case:
     - Be on a system (container, VM, or real iron) with at least one 
upgradeable package. If you don't have one, downgrade tzdata:
    sudo apt-get install tzdata=2016j-0ubuntu0.16.04
     - Run "pkcon get-updates" to see upgradeable packages.
     - Run "pkcon get-update-detail tzdata" (or for a different package).
     - Current PackageKit immediately crashes (message from pkcon and systemctl 
status packagekit), with this fix it should survive and show some data 
(changelog doesn't work though).

   * Regression potential: Update details are currently completely
  broken, so very little to regress there. As for dropping the browser
  plugin package: The current package stopped working long ago with
  current firefox; however, the package from xenial-release will still
  be around. All in all this shouldn't change anything visible.

   * Upstream fix:
  https://github.com/hughsie/PackageKit/commit/18c56fa52 (only the
  acqpkitstatus.cpp bit)

   * Downstream packaging change to drop browser plugin:
  https://anonscm.debian.org/git/pkg-
  packagekit/packagekit.git/commit/?id=b98a978322

  Test packages: http://people.ubuntu.com/~pitti/packagekit-
  updatedetail-crash/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1689820/+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


[Touch-packages] [Bug 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:

2017-08-08 Thread Martin Pitt
** Description changed:

  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
packagekit.  This problem was most recently seen with package version 
0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at 
https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker you can request it at 
http://forms.canonical.com/reports/.
+ 
+ SRU INFORMATION
+ ===
+  * Impact: PackageKit immediately crashes in GetUpdateDetail()..
+ 
+  * Test case:
+- Be on a system (container, VM, or real iron) with at least one 
upgradeable package. If you don't have one, downgrade tzdata:
+   sudo apt-get install tzdata=2016j-0ubuntu0.16.04
+- Run "pkcon get-updates" to see upgradeable packages.
+- Run "pkcon get-update-detail tzdata" (or for a different package).
+- Current PackageKit immediately crashes (message from pkcon and systemctl 
status packagekit), with this fix it should survive and show some data 
(changelog doesn't work though).
+ 
+  * Regression potential: Update details are currently completely broken,
+ so very little to regress there. As for dropping the browser plugin
+ package: The current package stopped working long ago with current
+ firefox; however, the package from xenial-release will still be around.
+ All in all this shouldn't change anything visible.
+ 
+  * Upstream fix: https://github.com/hughsie/PackageKit/commit/18c56fa52
+ (only the acqpkitstatus.cpp bit)
+ 
+  * Downstream packaging change to drop browser plugin:
+ https://anonscm.debian.org/git/pkg-
+ packagekit/packagekit.git/commit/?id=b98a978322

** Description changed:

  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
packagekit.  This problem was most recently seen with package version 
0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at 
https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker you can request it at 
http://forms.canonical.com/reports/.
  
  SRU INFORMATION
  ===
-  * Impact: PackageKit immediately crashes in GetUpdateDetail()..
+  * Impact: PackageKit immediately crashes in GetUpdateDetail()
  
-  * Test case:
-- Be on a system (container, VM, or real iron) with at least one 
upgradeable package. If you don't have one, downgrade tzdata:
-   sudo apt-get install tzdata=2016j-0ubuntu0.16.04
-- Run "pkcon get-updates" to see upgradeable packages.
-- Run "pkcon get-update-detail tzdata" (or for a different package).
-- Current PackageKit immediately crashes (message from pkcon and systemctl 
status packagekit), with this fix it should survive and show some data 
(changelog doesn't work though).
+  * Test case:
+    - Be on a system (container, VM, or real iron) with at least one 
upgradeable package. If you don't have one, downgrade tzdata:
+   sudo apt-get install tzdata=2016j-0ubuntu0.16.04
+    - Run "pkcon get-updates" to see upgradeable packages.
+    - Run "pkcon get-update-detail tzdata" (or for a different package).
+    - Current PackageKit immediately crashes (message from pkcon and systemctl 
status packagekit), with this fix it should survive and show some data 
(changelog doesn't work though).
  
-  * Regression potential: Update details are currently completely broken,
+  * Regression potential: Update details are currently completely broken,
  so very little to regress there. As for dropping the browser plugin
  package: The current package stopped working long ago with current
  firefox; however, the package from xenial-release will still be around.
  All in all this shouldn't change anything visible.
  
-  * Upstream fix: https://github.com/hughsie/PackageKit/commit/18c56fa52
+  * Upstream fix: https://github.com/hughsie/PackageKit/commit/18c56fa52
  (only the acqpkitstatus.cpp bit)
  
-  * Downstream packaging change to drop browser plugin:
+  * Downstream packaging change to drop browser plugin:
  https://anonscm.debian.org/git/pkg-
  packagekit/packagekit.git/commit/?id=b98a978322

** Description changed:

  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
packagekit.  This problem was most recently seen with package version 
0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at 
https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker you can request it at 
http://forms.canonical.com/reports/.
  
  SRU INFORMATION
  ===
   * Impact: PackageKit immediately crashes in 

[Touch-packages] [Bug 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:

2017-08-08 Thread Martin Pitt
I found the fix and backported it to xenial. The SRU is complicated by
the fact that packagekit is currently FTBFS due to recent firefox
dropping NPAPI, thus the browser plugin cannot be built any more. I'll
drop it.

** Changed in: packagekit (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: packagekit (Ubuntu Xenial)
   Status: Confirmed => In Progress

** Changed in: packagekit (Ubuntu Xenial)
 Assignee: (unassigned) => Martin Pitt (pitti)

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

Title:
  
/usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  In Progress

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
packagekit.  This problem was most recently seen with package version 
0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at 
https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker you can request it at 
http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1689820/+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


[Touch-packages] [Bug 1696480] Re: python3-dbusmock / test_no_adapters test fails with bluez 5.45

2017-06-12 Thread Martin Pitt
I released 0.16.8 upstream and uploaded it to Debian unstable, from
where it should autosync into Ubuntu devel soon.

** Changed in: python-dbusmock (Ubuntu)
   Status: Triaged => Fix Committed

** Changed in: python-dbusmock
   Status: Fix Committed => Fix Released

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

Title:
  python3-dbusmock / test_no_adapters test fails with bluez 5.45

Status in python-dbusmock:
  Fix Released
Status in bluez package in Ubuntu:
  Invalid
Status in python-dbusmock package in Ubuntu:
  Fix Committed

Bug description:
  
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bluez
  http://autopkgtest.ubuntu.com/packages/p/python-dbusmock/artful/amd64

  With bluez 5.45 python3-dbusmock tests fail with:

  ==
  FAIL: test_no_adapters (__main__.TestBlueZ5)
  --
  Traceback (most recent call last):
    File "./test_bluez5.py", line 107, in test_no_adapters
  self.assertEqual([l for l in out if 'Waiting to connect' not in l], [])
  AssertionError: Lists differ: ['org.freedesktop.DBus.Mock.MethodCalled', 
'registered', 'unregistered'] != []

  First list contains 3 additional elements.
  First extra element 0:
  'org.freedesktop.DBus.Mock.MethodCalled'

  - ['org.freedesktop.DBus.Mock.MethodCalled', 'registered', 'unregistered']
  + []

  --

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: bluez 5.45-0ubuntu1
  ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
  Uname: Linux 4.10.0-22-generic x86_64
  ApportVersion: 2.20.5-0ubuntu4
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Wed Jun  7 18:01:13 2017
  InstallationDate: Installed on 2013-09-03 (1372 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130902)
  InterestingModules: bnep bluetooth
  MachineType: ASUSTeK COMPUTER INC. UX32VD
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-22-generic.efi.signed 
root=UUID=1004226d-a9db-46c7-bd28-eca0806c12f2 ro pcie_aspm=force 
drm.vblankoffdelay=1 i915.semaphores=1 init=/lib/systemd/systemd-bootchart
  SourcePackage: bluez
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/29/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX32VD.214
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX32VD
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX32VD.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32VD:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32VD:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.name: UX32VD
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.
  hciconfig:

  rfkill:
   0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
  upstart.bluetooth.override: manual

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-dbusmock/+bug/1696480/+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


[Touch-packages] [Bug 1696480] Re: python3-dbusmock / test_no_adapters test fails with bluez 5.45

2017-06-09 Thread Martin Pitt
Thanks Daniel! PR merged upstream. There are a few other test
deprecation warnings/failures I'm looking into before doing a release.

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

Title:
  python3-dbusmock / test_no_adapters test fails with bluez 5.45

Status in python-dbusmock:
  Fix Committed
Status in bluez package in Ubuntu:
  Invalid
Status in python-dbusmock package in Ubuntu:
  Triaged

Bug description:
  
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bluez
  http://autopkgtest.ubuntu.com/packages/p/python-dbusmock/artful/amd64

  With bluez 5.45 python3-dbusmock tests fail with:

  ==
  FAIL: test_no_adapters (__main__.TestBlueZ5)
  --
  Traceback (most recent call last):
    File "./test_bluez5.py", line 107, in test_no_adapters
  self.assertEqual([l for l in out if 'Waiting to connect' not in l], [])
  AssertionError: Lists differ: ['org.freedesktop.DBus.Mock.MethodCalled', 
'registered', 'unregistered'] != []

  First list contains 3 additional elements.
  First extra element 0:
  'org.freedesktop.DBus.Mock.MethodCalled'

  - ['org.freedesktop.DBus.Mock.MethodCalled', 'registered', 'unregistered']
  + []

  --

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: bluez 5.45-0ubuntu1
  ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
  Uname: Linux 4.10.0-22-generic x86_64
  ApportVersion: 2.20.5-0ubuntu4
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Wed Jun  7 18:01:13 2017
  InstallationDate: Installed on 2013-09-03 (1372 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130902)
  InterestingModules: bnep bluetooth
  MachineType: ASUSTeK COMPUTER INC. UX32VD
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-22-generic.efi.signed 
root=UUID=1004226d-a9db-46c7-bd28-eca0806c12f2 ro pcie_aspm=force 
drm.vblankoffdelay=1 i915.semaphores=1 init=/lib/systemd/systemd-bootchart
  SourcePackage: bluez
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/29/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX32VD.214
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX32VD
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX32VD.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32VD:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32VD:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.name: UX32VD
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.
  hciconfig:

  rfkill:
   0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
  upstart.bluetooth.override: manual

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-dbusmock/+bug/1696480/+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


[Touch-packages] [Bug 1694438] Re: [16.04] Cannot download packages whilst offline - when using ifupdown

2017-05-30 Thread Martin Pitt
This also affects PackageKit 1.0.1-2 in Debian Jessie.

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

Title:
  [16.04] Cannot download packages whilst offline - when using ifupdown

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  New

Bug description:
  I am using 16.04 with the main ethernet interface being managed by
  ifupdown, and others by NetworkManager. Apparently PK's
  pk_network_get_network_state() does not properly recognize this and
  thinks it is offline:

  # pkcon update
  Getting updates   [=] 
  [...]
  Fatal error: Cannot download packages whilst offline

  A workaround is to change /etc/NetworkManager/NetworkManager.conf
  [ifupdown] managed= from "false" to "true", then "eth0" appears in
  "nmcli d" and PackageKit is happy.

  In 17.04 this is no problem any more, PackageKit works out of the box
  with the same ifupdown configuration and managed=false. Interestingly,
  "nmcli d" shows

  eth0ethernet  unmanaged  --

  there, while eth0 is entirely absent in 16.04. There doesn't seem to
  be an nmcli command to show what PackageKit looks at; the closest is
  "nmcli g" but in all three cases above that says

  STATE  CONNECTIVITY  WIFI-HW  WIFI WWAN-HW  WWAN
  connected  full  enabled  enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1694438/+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


[Touch-packages] [Bug 1694438] [NEW] [16.04] Cannot download packages whilst offline - when using ifupdown

2017-05-30 Thread Martin Pitt
Public bug reported:

I am using 16.04 with the main ethernet interface being managed by
ifupdown, and others by NetworkManager. Apparently PK's
pk_network_get_network_state() does not properly recognize this and
thinks it is offline:

# pkcon update
Getting updates   [=] 
[...]
Fatal error: Cannot download packages whilst offline

A workaround is to change /etc/NetworkManager/NetworkManager.conf
[ifupdown] managed= from "false" to "true", then "eth0" appears in
"nmcli d" and PackageKit is happy.

In 17.04 this is no problem any more, PackageKit works out of the box
with the same ifupdown configuration and managed=false. Interestingly,
"nmcli d" shows

eth0ethernet  unmanaged  --

there, while eth0 is entirely absent in 16.04. There doesn't seem to be
an nmcli command to show what PackageKit looks at; the closest is "nmcli
g" but in all three cases above that says

STATE  CONNECTIVITY  WIFI-HW  WIFI WWAN-HW  WWAN
connected  full  enabled  enabled  enabled  enabled

** Affects: packagekit (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: packagekit (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Also affects: packagekit (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: packagekit (Ubuntu)
   Status: New => Fix Released

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

Title:
  [16.04] Cannot download packages whilst offline - when using ifupdown

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  New

Bug description:
  I am using 16.04 with the main ethernet interface being managed by
  ifupdown, and others by NetworkManager. Apparently PK's
  pk_network_get_network_state() does not properly recognize this and
  thinks it is offline:

  # pkcon update
  Getting updates   [=] 
  [...]
  Fatal error: Cannot download packages whilst offline

  A workaround is to change /etc/NetworkManager/NetworkManager.conf
  [ifupdown] managed= from "false" to "true", then "eth0" appears in
  "nmcli d" and PackageKit is happy.

  In 17.04 this is no problem any more, PackageKit works out of the box
  with the same ifupdown configuration and managed=false. Interestingly,
  "nmcli d" shows

  eth0ethernet  unmanaged  --

  there, while eth0 is entirely absent in 16.04. There doesn't seem to
  be an nmcli command to show what PackageKit looks at; the closest is
  "nmcli g" but in all three cases above that says

  STATE  CONNECTIVITY  WIFI-HW  WIFI WWAN-HW  WWAN
  connected  full  enabled  enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1694438/+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


[Touch-packages] [Bug 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:

2017-05-10 Thread Martin Pitt
I confirmed that this is fixed in zesty.

** Changed in: packagekit (Ubuntu)
   Status: New => Fix Released

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

Title:
  
/usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  New

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
packagekit.  This problem was most recently seen with package version 
0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at 
https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker you can request it at 
http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1689820/+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


[Touch-packages] [Bug 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:

2017-05-10 Thread Martin Pitt
This is quite simple to reproduce:

$ pkcon get-updates
Getting updates   [=] 
Loading cache [=] 
Querying  [=] 
Finished  [=] 
Bug fix linux-generic-4.4.0.77.83.amd64 (xenial-updates)
Complete Generic Linux kernel and headers
Bug fix linux-headers-generic-4.4.0.77.83.amd64 (xenial-updates)
Generic Linux kernel headers
Bug fix linux-headers-virtual-4.4.0.77.83.amd64 (xenial-updates)
Transitional package.
Bug fix linux-image-generic-4.4.0.77.83.amd64 (xenial-updates)  
Generic Linux kernel image
Bug fix linux-image-virtual-4.4.0.77.83.amd64 (xenial-updates)  
This package will always depend on the latest minimal generic kernel image.
Bug fix linux-virtual-4.4.0.77.83.amd64 (xenial-updates)
Minimal Generic Linux kernel and headers

$ pkcon get-update-detail linux-image-virtual
Resolving [=] 
Getting update details[=] 
Loading cache [=] 
Downloading packages  [ ] (0%)  The daemon 
crashed mid-transaction!

This doesn't seem to be specific to the particular package. If I
downgrade tzdata

$ sudo apt-get install tzdata=2016d-0ubuntu0.16.04

and query that it crashes as well:

$ pkcon get-update-detail tzdata
Downloading packages  [ ] (0%)  The daemon 
crashed mid-transaction!


0x723ad6d5 in AcqPackageKitStatus::updateStatus(pkgAcquire::ItemDesc&, 
int) ()
   from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
(gdb) bt
#0  0x723ad6d5 in 
AcqPackageKitStatus::updateStatus(pkgAcquire::ItemDesc&, int) ()
   from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
#1  0x723ad7d3 in AcqPackageKitStatus::Fail(pkgAcquire::ItemDesc&) ()
   from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
#2  0x71b2bd96 in pkgAcquire::Worker::RunMessages() () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#3  0x71b2d9dc in pkgAcquire::Worker::InFdReady() () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#4  0x71b2f1ba in pkgAcquire::RunFdsSane(fd_set*, fd_set*) () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#5  0x71b32dd2 in pkgAcquire::Run(int) () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#6  0x723b4be1 in downloadChangelog(AptCacheFile&, pkgAcquire&, 
pkgCache::VerIterator, std::__cxx11::basic_string) () from 
/usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
#7  0x723c6888 in AptIntf::emitUpdateDetail(pkgCache::VerIterator 
const&) ()
   from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
#8  0x723c73c5 in AptIntf::emitUpdateDetails(PkgList const&) ()
   from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
#9  0x723cbffd in ?? () from 
/usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
#10 0x5556e419 in ?? ()
#11 0x76c0cbb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x769866ba in start_thread (arg=0x709ec700) at 
pthread_create.c:333
#13 0x766bc82d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) bt full
#0  0x723ad6d5 in 
AcqPackageKitStatus::updateStatus(pkgAcquire::ItemDesc&, int) () from 
/usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
No symbol table info available.
#1  0x723ad7d3 in AcqPackageKitStatus::Fail(pkgAcquire::ItemDesc&) () 
from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so
No symbol table info available.
#2  0x71b2bd96 in pkgAcquire::Worker::RunMessages() () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0


** Also affects: packagekit (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

Title:
  
/usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  New

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
packagekit.  This problem was most recently seen with package version 
0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at 
https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc 
contains more details, including 

[Touch-packages] [Bug 1650827] Re: /usr/lib/dovecot/dovecot-lda: "Failed name lookup - disconnected path"

2017-05-02 Thread Martin Pitt
** Summary changed:

- "Failed name lookup - disconnected path"
+ /usr/lib/dovecot/dovecot-lda: "Failed name lookup - disconnected path"

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

Title:
  /usr/lib/dovecot/dovecot-lda: "Failed name lookup - disconnected path"

Status in AppArmor:
  Fix Committed
Status in AppArmor 2.10 series:
  Fix Committed
Status in AppArmor 2.9 series:
  Fix Committed
Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I'm currently trying to use dovecot in a test scenario, but run into
  the problem of a strange malfunction of apparmor.

  What I do:

  installed packages   dovecot-core   and   dovecot-lmtp
  (and of course apparmor)

  Then I do (as root)

  /usr/lib/dovecot/dovecot-lda -d hadmut 

Re: [Touch-packages] [Bug 103436] Re: sshd not reconfigured by /etc/network

2017-03-20 Thread Martin Pitt
Hey Perry,

Perry E. Metzger [2017-03-20 13:11 -0400]:
> That bug report was a decade ago.

Yeah, I know :-)

> So far as I know, this is still an issue for your users, because sshd
> does not, on its own, change its network address when one changes
> networks. I would not remove this because if you remove it you're
> going to harm anyone who changes addresses frequently.

That's what I've thought, but it am puzzled that I cannot actually produce this
situation (when removing the script). That, and the fact that Fedora or SUSE
don't have this indicate that this was dealt with by something else in the
meantime.

> However, I have not used Ubuntu in many years (this is 2017, the bug
> report was 2007) and I am no longer in a position to help you.

No worries, it was a long shot anyway. Thanks for your fast response!

Martin

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

Title:
  sshd not reconfigured by /etc/network

Status in openssh package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssh-server

  If you have a device that roams a lot (like a laptop), you want
  daemons like sshd to be tweaked/restarted by scripts in /etc/network
  so that they re-open the socket they listen on when the network
  address changes. (Yes, some of us really do want to be able to
  remotely log in to our laptops after we bring them home and they roam
  onto the home WiFi network etc.)

  Right now there is no sshd script in /etc/network/* but it would be
  trivial to create one and add it to the package. For sshd, it would be
  simplest just to restart the daemon.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/103436/+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


[Touch-packages] [Bug 103436] Re: sshd not reconfigured by /etc/network

2017-03-20 Thread Martin Pitt
I filed bug 1674330 about dropping the hack.

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

Title:
  sshd not reconfigured by /etc/network

Status in openssh package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssh-server

  If you have a device that roams a lot (like a laptop), you want
  daemons like sshd to be tweaked/restarted by scripts in /etc/network
  so that they re-open the socket they listen on when the network
  address changes. (Yes, some of us really do want to be able to
  remotely log in to our laptops after we bring them home and they roam
  onto the home WiFi network etc.)

  Right now there is no sshd script in /etc/network/* but it would be
  trivial to create one and add it to the package. For sshd, it would be
  simplest just to restart the daemon.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/103436/+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


[Touch-packages] [Bug 1674330] [NEW] Please consider dropping /etc/network/if-up.d/openssh-server

2017-03-20 Thread Martin Pitt
Public bug reported:

The /etc/network/if-up.d/openssh-server hack was introduced ten years ago [1] 
as a response to bug 
103436. At least from today's perspective this isn't justified:

I can't seem to be able to actually reproduce that issue: I can start a
VM with no network interfaces, remove the above hack, then start sshd,
then bring up an ethernet interface, and I can connect to ssh via
ethernet just fine. Also, e. g. Fedora has no counterpart of this hack,
and these days a lot of people would complain if that would cause
problems, as hotpluggable/roaming network devices are everywhere.

The hack introduces a race: you run into connection errors after
bringing up a new interface as sshd stops listening briefly while being
reloaded. That's the reason why I looked at it, as this regularly
happens in upstream's cockpit integration tests.

Also, /etc/network/if-up.d/ isn't being run when using networkd/netplan,
i. e. in more recent Ubuntnu cloud instances. So far this doesn't seem
to have caused any issues.

I asked the original reporter of bug 103436 for some details, and to
check whether that hack is still necessary. There is actually a proposed
patch upstream [2] to use IP_FREEBIND, which is the modern solution to
listening to all "future" interfaces as well. But at least for the
majority of cases it seems to work fine without that even.

So I wonder if it's time to bury that hack?

[1] https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=ba6b55ed6
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=2512

** Affects: openssh (Ubuntu)
 Importance: Low
 Status: New

** Changed in: openssh (Ubuntu)
   Importance: Undecided => Low

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

Title:
  Please consider dropping /etc/network/if-up.d/openssh-server

Status in openssh package in Ubuntu:
  New

Bug description:
  The /etc/network/if-up.d/openssh-server hack was introduced ten years ago [1] 
as a response to bug 
  103436. At least from today's perspective this isn't justified:

  I can't seem to be able to actually reproduce that issue: I can start
  a VM with no network interfaces, remove the above hack, then start
  sshd, then bring up an ethernet interface, and I can connect to ssh
  via ethernet just fine. Also, e. g. Fedora has no counterpart of this
  hack, and these days a lot of people would complain if that would
  cause problems, as hotpluggable/roaming network devices are
  everywhere.

  The hack introduces a race: you run into connection errors after
  bringing up a new interface as sshd stops listening briefly while
  being reloaded. That's the reason why I looked at it, as this
  regularly happens in upstream's cockpit integration tests.

  Also, /etc/network/if-up.d/ isn't being run when using
  networkd/netplan, i. e. in more recent Ubuntnu cloud instances. So far
  this doesn't seem to have caused any issues.

  I asked the original reporter of bug 103436 for some details, and to
  check whether that hack is still necessary. There is actually a
  proposed patch upstream [2] to use IP_FREEBIND, which is the modern
  solution to listening to all "future" interfaces as well. But at least
  for the majority of cases it seems to work fine without that even.

  So I wonder if it's time to bury that hack?

  [1] https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=ba6b55ed6
  [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2512

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1674330/+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


[Touch-packages] [Bug 103436] Re: sshd not reconfigured by /etc/network

2017-03-20 Thread Martin Pitt
Perry, I just revisited this:

 - /etc/network/if-up.d/openssh-server hack introduces a race (you run
into connection errors after bringing up a new interface as sshd stops
listening briefly while being reloaded).

 - I can't seem to be able to actually reproduce that issue: I can start
a VM with no network interfaces, remove the above hack, then start sshd,
then bring up an ethernet interface, and I can connect to ssh via
ethernet just fine. Also, e. g. Fedora has no counterpart of this hack,
and these days a lot of people would complain if that would cause
problems, as hotpluggable/roaming network devices are everywhere.

 - /etc/network/if-up.d/ isn't being run when using networkd/netplan,
thus in our cloud instances. So far this doesn't seem to have caused any
issues.

So my questions:

  (1) Can you please describe more precisely what exactly you did back
then? Do you have a nonstandard SSH configuration with some
ListenAddresses/AddressFamily restrictions or similar?

  (2) Can you please disable the hack (sudo chmod 0 /etc/network/if-up.d
/openssh-server) and check if your use case works without it?

Thanks!

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

Title:
  sshd not reconfigured by /etc/network

Status in openssh package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssh-server

  If you have a device that roams a lot (like a laptop), you want
  daemons like sshd to be tweaked/restarted by scripts in /etc/network
  so that they re-open the socket they listen on when the network
  address changes. (Yes, some of us really do want to be able to
  remotely log in to our laptops after we bring them home and they roam
  onto the home WiFi network etc.)

  Right now there is no sshd script in /etc/network/* but it would be
  trivial to create one and add it to the package. For sshd, it would be
  simplest just to restart the daemon.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/103436/+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


Re: [Touch-packages] [Bug 1647031] Re:systemd-resolved’s127.0.0.53 server does not follow CNAME records

2017-03-15 Thread Martin Pitt
Blaisorblade [2017-03-15 15:03 -]:
> Another corner case seems to be binaries linked against musl libc, since
> they do not use NSS.

Note that this is generally broken and cannot be supported, regardless of the
DNS resolver. These binaries could also not resolve winbind host names, YP,
LDAP, Active Directory, or sssd users/groups, and anything else which is
handled through nsswitch.

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in Nextcloud:
  Unknown
Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Yakkety:
  Invalid
Status in systemd source package in Yakkety:
  Triaged

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nextcloud-snap/+bug/1647031/+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


[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2017-02-23 Thread Martin Pitt
Yes, there, see "man resolved.conf". But I'd recommend a separate file
to avoid changing the package-provided conffile:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf "[Resolve]\nDNSSEC=no\n" | sudo tee 
/etc/systemd/resolved.conf.d/no-dnssec.conf

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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


[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2017-02-19 Thread Martin Pitt
Note: We keep DNSSEC=allow-downgrade during development to collect
feedback, but switch it off for stable releases (we did so in yakkety
and should do so again in zesty). So if you have some trouble which is
DNSSEC related, it would be good to get a debug output of resolved while
it's failing to report/investigate it. But that should be unrelated to
the CNAME bug here.

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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


[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2017-02-12 Thread Martin Pitt
Fixed upstream:
https://github.com/systemd/systemd/commit/e8d23f92b50a97bb3

** Changed in: systemd (Ubuntu)
   Status: Triaged => Fix Committed

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

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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


[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2017-02-08 Thread Martin Pitt
I cherry-picked the patches into the Debian packaging branch, so that on
next upload zesty can be synced again.

-- 
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/1647485

Title:
  NVMe symlinks broken by devices with spaces in model or serial strings

Status in maas-images:
  Fix Released
Status in systemd:
  New
Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Trusty:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Yakkety:
  Fix Committed
Status in systemd source package in Zesty:
  Fix Committed
Status in systemd package in Debian:
  New

Bug description:
  [Impact]

  After including the patch from bug 1642903, NVMe devices that include spaces 
in their model or serial strings result in incorrect symlinks, e.g. if the 
model string is "XYZ Corp NVMe drive" then instead of creating:
  /dev/disk/by-id/nvme-XYZ Corp NVMe drive_SERIAL -> ../../nvme0n1
  it creates:
  /dev/disk/by-id/nvme-XYZ -> ../../nvme0n1
  /dev/Corp -> nvme0n1
  /dev/NVMe -> nvme0n1
  /dev/drive_SERIAL -> nvme0n1

  This is because of the way udev handles the SYMLINK value strings; by
  default, it does not do any whitespace replacement.  To enable
  whitespace replacement of a symlink value, the rule must also include
  OPTIONS+="string_escape=replace".  This is done for 'md' and 'dm'
  devices in their rules.  However, there are no rules that actually
  want to specify multiple symlinks, and defaulting to not replacing
  whitespace makes no sense; instead, the default should be to replace
  all whitespace in each symlink value, unless the rule explicitly
  specifies OPTIONS+="string_escape=none".

  [Test Case]

  This assumes using udev with the patch from bug 1642903.

  Without this patch, when using a NVMe drive that contains spaces in
  its model and/or serial strings, check the /dev/disk/by-id/ directory.
  It should contain a partially-correct symlink to the NVMe drive, with
  the name up to the first space.  All following space-separated parts
  of the mode/serial string should have symlinks in the /dev/ directory.
  This is the incorrect behavior.

  With this patch, check the /dev/disk/by-id/ directory.  It should
  contain a fully-correct symlink to the NVMe drive, and no part of the
  drive's model/serial number string should be a link in the /dev
  directory.

  An example of the correct/incorrect naming is in the Impact section.

  There should be no other changes to any of the symlinks under /dev
  before and after this patch.  Typical locations for symlinks are
  /dev/, /dev/disk/by-name/, /dev/disk/by-id/, /dev/disk/by-uuid/,
  /dev/disk/by-label/

  [Regression Potential]

  Errors in udev rules can lead to an unbootable or otherwise completely
  broken system if they unintentionally break or clobber existing
  /dev/disks/ symlinks.

  [Other Info]

  This is also tracked with upstream systemd (udev) bug 4833:
  https://github.com/systemd/systemd/issues/4833

  Also note, this can be worked around in individual rules ONLY (i.e.
  not fixed for all rules) by appending OPTIONS+="string_escape=replace"
  to each of the NVMe rules with SYMLINK+="..." assignment, e.g.:

  KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{model}=="?*",
  ENV{ID_SERIAL_SHORT}=="?*",
  ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk
  /by-id/nvme-$env{ID_SERIAL}", OPTIONS+="string_escape=replace"

  Related bugs:
   * bug 1642903: introduce disk/by-id (model_serial) symlinks for NVMe drives
   * bug 1651602: NVMe driver regression for non-smp/1-cpu systems
   * bug 1649635: export nvme drive model/serial strings via sysfs (trusty)

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/1647485/+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


[Touch-packages] [Bug 1649453] Re: systemd starts postfix before resolver

2017-01-03 Thread Martin Pitt
@Scott:
https://git.launchpad.net/postfix/commit/?h=stable/v3.1=1a190cf17cc02
looks rather complicated and also creates an unmanaged config file. Why
not just always add those After= to the .service? If resolved is not
enabled, then After=systemd-resolved is a no-op (it's only ordering, not
a dependency -- that would be Requires= or Wants=).

Also, not sure why you added network-online.target, but if you actually
do want to wait for the network then you also need a corresponding Wants
=network-online.target (see man systemd.special).

** No longer affects: systemd (Ubuntu)

** Tags added: resolved

-- 
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/1649453

Title:
  systemd starts postfix before resolver

Status in postfix package in Ubuntu:
  Fix Committed

Bug description:
  Postfix starts before systemd-resolved.service, resulting in postfix
  reporting that it can't find MX records for outgoing mail, as shown in
  the trace below:

  $ systemd-analyze critical-chain postfix.service systemd-resolved.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  postfix.service +1ms
  └─network.target @5.811s
└─NetworkManager.service @5.690s +91ms
  └─dbus.service @5.627s
└─basic.target @5.597s
  └─sockets.target @5.597s
└─snapd.socket @5.597s +269us
  └─sysinit.target @5.596s
└─systemd-timesyncd.service @5.420s +175ms
  └─systemd-tmpfiles-setup.service @5.408s +8ms
└─local-fs.target @5.390s
  └─zfs-mount.service @3.879s +1.511s
└─zfs-import-cache.service @2.539s +1.303s
  └─systemd-udev-settle.service @256ms +2.252s
└─systemd-udev-trigger.service @208ms +47ms
  └─systemd-udevd-control.socket @148ms
└─-.mount @122ms
  └─system.slice @124ms
└─-.slice @122ms
  systemd-resolved.service +268ms
  └─network.target @5.811s
└─NetworkManager.service @5.690s +91ms
  └─dbus.service @5.627s
└─basic.target @5.597s
  └─sockets.target @5.597s
└─snapd.socket @5.597s +269us
  └─sysinit.target @5.596s
└─systemd-timesyncd.service @5.420s +175ms
  └─systemd-tmpfiles-setup.service @5.408s +8ms
└─local-fs.target @5.390s
  └─zfs-mount.service @3.879s +1.511s
└─zfs-import-cache.service @2.539s +1.303s
  └─systemd-udev-settle.service @256ms +2.252s
└─systemd-udev-trigger.service @208ms +47ms
  └─systemd-udevd-control.socket @148ms
└─-.mount @122ms
  └─system.slice @124ms
└─-.slice @122ms

  The postfix service needs to start after systemd-resolved.service.

  $ lsb_release -rd
  Description:  Ubuntu 16.10
  Release:  16.10

  $ apt-cache policy systemd
  systemd:
Installed: 231-9ubuntu1
Candidate: 231-9ubuntu1
Version table:
   *** 231-9ubuntu1 500
  500 http://mirror.aarnet.edu.au/pub/ubuntu/archive 
yakkety-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   231-9git1 500
  500 http://mirror.aarnet.edu.au/pub/ubuntu/archive yakkety/main amd64 
Packages

  $ apt-cache policy postfix
  postfix:
Installed: 3.1.0-5
Candidate: 3.1.0-5
Version table:
   *** 3.1.0-5 500
  500 http://mirror.aarnet.edu.au/pub/ubuntu/archive yakkety/main amd64 
Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1649453/+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


[Touch-packages] [Bug 1644330] Re: resolved: correctly handle address families with /etc/hosts lookups

2016-12-21 Thread Martin Pitt
The fix landed in master:
https://github.com/systemd/systemd/commit/4050e04b

** Changed in: systemd (Ubuntu)
   Status: In Progress => Fix Committed

** Changed in: systemd (Ubuntu)
Milestone: ubuntu-16.12 => None

-- 
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/1644330

Title:
  resolved: correctly handle address families with /etc/hosts lookups

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  I have an ipv4 entry for a key host on my network listed in
  /etc/hosts, for network recovery purposes.  This host also has ipv6
  connectivity; the ipv6 address is resolvable via DNS, but I do not
  have it in /etc/hosts.  Resolution of hostname should be independent
  for each address family.

  Two days ago (I don't know what changed to trigger this), I stopped
  being able to resolve the ipv6 address for this host.  I traced this
  down to systemd-resolved, returning a lookup failure for the nss
  request, because the ipv6 address is not listed in /etc/hosts.

  Removing resolve from /etc/nsswitch.conf restores the correct
  behavior.

  Removing the ipv4 entry for the host restores the correct behavior.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: systemd 231-9ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1
  Uname: Linux 4.8.0-27-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Nov 23 08:13:33 2016
  InstallationDate: Installed on 2010-09-24 (2252 days ago)
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.1)
  MachineType: LENOVO 2306CTO
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-27-generic.efi.signed 
root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to yakkety on 2016-10-28 (25 days ago)
  dmi.bios.date: 10/25/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 2306CTO
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1644330/+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


Re: [Touch-packages] [Bug 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2016-12-21 Thread Martin Pitt
Till Kamppeter [2016-12-19 16:48 -]:
> Then edit the file /lib/systemd/system/cups.path adding a line
> "PartOf=cups.service" to the [Unit] section, so that the file looks like
> this:
> 
> --
> [Unit]
> Description=CUPS Scheduler
> PartOf=cups.service

I suppose that cups.path is only for booting, i. e. you want to start
cups.service on boot, not again on demand on a running system. Does it ever
happen that cups.service terminates by itself due to inactivity? If not, this
provides a good enough workaround for not stopping cups.path properly in the
maintainer scripts. If yes, this appproach doesn't work.

Note that you probably want to do the same for cups.socket, with the same
reasoning as above.

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

Title:
  package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new
  pre-removal script returned error exit status 1

Status in cups package in Ubuntu:
  Confirmed
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is in xenial-proposed, please block release to -updates
  accordingly :)

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: cups-daemon 2.1.3-4
  ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24
  Uname: Linux 4.4.0-46-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CupsErrorLog:
   
  Date: Fri Nov 18 11:13:15 2016
  ErrorMessage: subprocess new pre-removal script returned error exit status 1
  InstallationDate: Installed on 2016-05-02 (200 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Lpstat: device for mallards-officejet-pro-8600: 
dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461
  MachineType: Dell Inc. XPS 15 9550
  Papersize: a4
  PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed 
root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15
  SourcePackage: cups
  Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/07/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.02.00
  dmi.board.name: 0N7TVV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.name: XPS 15 9550
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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


[Touch-packages] [Bug 1644330] Re: systemd-resolved assumes that /etc/hosts for one address family means it doesn't ask DNS for another

2016-12-20 Thread Martin Pitt
See the summary from https://github.com/systemd/systemd/pull/4808: I
can't convince Lennart about falling back to DNS for IPv6 if hosts has
an IPv4 entry -- if hosts has some answer, it should be considered
authoritative, and we should not mix different sources for the same
query. Often /etc/hosts gets used to blacklist ad/spam domains, and this
behaviour would break that.

However, the more serious case is that if you have some *.example.com in
/etc/hosts and then query the MX, SOA, or other non-address record for
example.com then that query also fails. That's the part that I'll fix
and Lennart agrees with.

** Summary changed:

- systemd-resolved assumes that /etc/hosts for one address family means it 
doesn't ask DNS for another
+ resolved: correctly handle address families with /etc/hosts lookups

-- 
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/1644330

Title:
  resolved: correctly handle address families with /etc/hosts lookups

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  I have an ipv4 entry for a key host on my network listed in
  /etc/hosts, for network recovery purposes.  This host also has ipv6
  connectivity; the ipv6 address is resolvable via DNS, but I do not
  have it in /etc/hosts.  Resolution of hostname should be independent
  for each address family.

  Two days ago (I don't know what changed to trigger this), I stopped
  being able to resolve the ipv6 address for this host.  I traced this
  down to systemd-resolved, returning a lookup failure for the nss
  request, because the ipv6 address is not listed in /etc/hosts.

  Removing resolve from /etc/nsswitch.conf restores the correct
  behavior.

  Removing the ipv4 entry for the host restores the correct behavior.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: systemd 231-9ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1
  Uname: Linux 4.8.0-27-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Nov 23 08:13:33 2016
  InstallationDate: Installed on 2010-09-24 (2252 days ago)
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.1)
  MachineType: LENOVO 2306CTO
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-27-generic.efi.signed 
root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to yakkety on 2016-10-28 (25 days ago)
  dmi.bios.date: 10/25/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 2306CTO
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1644330/+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


[Touch-packages] [Bug 1648806] Re: Arbitrary code execution through crafted CrashDB or Package/Source fields in .crash files

2016-12-18 Thread Martin Pitt
@Benjamin: Argh, I had to uncommit/recommit these three as the CVE
numbers came in at the last minute, and apparently got the commit
messages the wrong way around (meh @ not having rebase in bzr..) I did
some surgery on the branch and the commit messages are correct now.

When I created the fixes I also verified that this was the only eval()
in the entire source, there is none left now.

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

Title:
  Arbitrary code execution through crafted CrashDB or Package/Source
  fields in .crash files

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Precise:
  Fix Released
Status in apport source package in Trusty:
  Fix Released
Status in apport source package in Xenial:
  Fix Released
Status in apport source package in Yakkety:
  Fix Released
Status in apport source package in Zesty:
  Fix Released

Bug description:
  Forwarding private (encrypted) mail from Donncha O'Cearbhaill
  :

  = 8< ==
  Hi Martin,

  I have been auditing the Apport software in my free time and
  unfortunately I have found some serious security issues.

  Untrusted files can be passed to apport-gtk as it is registered as the
  default file handler for "text/x-apport" files. The mime-type includes
  .crash files but also any unknown file type which begins with
  "ProblemType: ". An attacker could social engineer a victim into opening
  a malicious Apport crash file simply by clicking on it.

  In apport/ui.py, Apport is reading the CrashDB field and then it then
  evaluates the field as Python code if it begins with a "{". This is very
  dangerous as it can allow remote attackers to execute arbitrary Python code.

  The vulnerable code was introduce on 2012-08-22 in Apport revision
  2464
  (http://bazaar.launchpad.net/~apport-hackers/apport/trunk/files/2464).
  This code was first included in release 2.6.1. All Ubuntu Desktop
  versions after 12.05 (Precise) include this vulnerable code by default.

  An easy fix would be to parse the value as JSON instead of eval()'ing
  it.

  There is also a path traversal issue where the Package or SourcePackage
  fields are not sanitized before being used to build a path to the
  package specific hook files in the /usr/share/apport/package-hooks/
  directory.

  By setting "Package: ../../../../proc/self/cwd/Downloads/rce-hook.py" a
  remote attacker could exploit this bug to execute Python scripts that
  have be placed in the user's Downloads directory.

  Would you like to apply for a CVE for this issues or should I? I'd like
  to see these issue fixed soon so that Ubuntu users can be kept safe. I'm
  planning to publish a blog post about these issues but I'll wait until
  patched version of Apport are available in the repositories.

  Please let me know if you have any questions.

  Kind Regards,
  Donncha
  = 8< ==

  I just talked to Donna on Jabber, and he plans to disclose that in
  around a week.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1648806/+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


[Touch-packages] [Bug 1648806] Re: Arbitrary code execution through crafted CrashDB or Package/Source fields in .crash files

2016-12-14 Thread Martin Pitt
New upstream release with the fixes:
https://launchpad.net/apport/trunk/2.20.4

Note that Brian committed some changes to trunk in the last 1.5 hours,
so we had some mid-air collection. I force-pushed trunk and will put
back his commits on top.

** Changed in: apport
   Status: In Progress => Fix Released

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

Title:
  Arbitrary code execution through crafted CrashDB or Package/Source
  fields in .crash files

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Committed
Status in apport source package in Precise:
  Fix Released
Status in apport source package in Trusty:
  Fix Released
Status in apport source package in Xenial:
  Fix Released
Status in apport source package in Yakkety:
  New
Status in apport source package in Zesty:
  Fix Committed

Bug description:
  Forwarding private (encrypted) mail from Donncha O'Cearbhaill
  :

  = 8< ==
  Hi Martin,

  I have been auditing the Apport software in my free time and
  unfortunately I have found some serious security issues.

  Untrusted files can be passed to apport-gtk as it is registered as the
  default file handler for "text/x-apport" files. The mime-type includes
  .crash files but also any unknown file type which begins with
  "ProblemType: ". An attacker could social engineer a victim into opening
  a malicious Apport crash file simply by clicking on it.

  In apport/ui.py, Apport is reading the CrashDB field and then it then
  evaluates the field as Python code if it begins with a "{". This is very
  dangerous as it can allow remote attackers to execute arbitrary Python code.

  The vulnerable code was introduce on 2012-08-22 in Apport revision
  2464
  (http://bazaar.launchpad.net/~apport-hackers/apport/trunk/files/2464).
  This code was first included in release 2.6.1. All Ubuntu Desktop
  versions after 12.05 (Precise) include this vulnerable code by default.

  An easy fix would be to parse the value as JSON instead of eval()'ing
  it.

  There is also a path traversal issue where the Package or SourcePackage
  fields are not sanitized before being used to build a path to the
  package specific hook files in the /usr/share/apport/package-hooks/
  directory.

  By setting "Package: ../../../../proc/self/cwd/Downloads/rce-hook.py" a
  remote attacker could exploit this bug to execute Python scripts that
  have be placed in the user's Downloads directory.

  Would you like to apply for a CVE for this issues or should I? I'd like
  to see these issue fixed soon so that Ubuntu users can be kept safe. I'm
  planning to publish a blog post about these issues but I'll wait until
  patched version of Apport are available in the repositories.

  Please let me know if you have any questions.

  Kind Regards,
  Donncha
  = 8< ==

  I just talked to Donna on Jabber, and he plans to disclose that in
  around a week.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1648806/+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


[Touch-packages] [Bug 1519499] Re: Shutdown failure: Assertion 'sd_id128_randomize() >= 0' failed at ../src/core/dbus.c:657, function bus_on_connection(). Aborting.

2016-12-14 Thread Martin Pitt
This is likely fixed in current systemd versions already, but the recent
commit https://github.com/systemd/systemd/commit/ad2706db7cce should fix
the remaining traces of this.

Current systemd package in
https://launchpad.net/~pitti/+archive/ubuntu/systemd contains this
patch, if you want to give it a try on Ubuntu 16.10.

** Changed in: systemd (Ubuntu)
   Status: Confirmed => Fix Committed

-- 
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/1519499

Title:
  Shutdown failure: Assertion 'sd_id128_randomize() >= 0' failed at
  ../src/core/dbus.c:657, function bus_on_connection(). Aborting.

Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  This is a follow-up on this issue here:
  https://github.com/lxc/lxd/issues/1336 I cannot stop a LXD container
  gently and as it seems the issue lies within ubuntu/systemd which does
  not handle SIGPWR correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1519499/+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


[Touch-packages] [Bug 1641328] Re: Ordering of mdns4_minimal and resolve in /etc/nsswitch.conf causes mDNS lookups to fail

2016-12-13 Thread Martin Pitt
** Tags added: resolve

-- 
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/1641328

Title:
  Ordering of mdns4_minimal and resolve in /etc/nsswitch.conf causes
  mDNS lookups to fail

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  (See also libnss-resolve:amd64   231-9ubuntu1 amd64nss module
  to resolve names via systemd-resolved)

  
  # fresh install of yakkety 

  mtearle@liberation:/etc$ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.10
  Release:  16.10
  Codename: yakkety

  # package details

  mtearle@liberation:~$ apt-cache policy libnss-resolve
  libnss-resolve:
Installed: 231-9ubuntu1
Candidate: 231-9ubuntu1
Version table:
   *** 231-9ubuntu1 500
  500 http://mirror.rackspace.com/ubuntu yakkety-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   231-9git1 500
  500 http://mirror.rackspace.com/ubuntu yakkety/main amd64 Packages
  mtearle@liberation:~$ apt-cache policy systemd
  systemd:
Installed: 231-9ubuntu1
Candidate: 231-9ubuntu1
Version table:
   *** 231-9ubuntu1 500
  500 http://mirror.rackspace.com/ubuntu yakkety-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   231-9git1 500
  500 http://mirror.rackspace.com/ubuntu yakkety/main amd64 Packages



  # attempt to ping VM elsewhere on network with mDNS hostname

  mtearle@liberation:/etc$ ping bazzavan.local
  ping: bazzavan.local: Name or service not known

  # can find both ipv4 and ipv6 addresses for the host

  mtearle@liberation:/etc$ avahi-resolve-host-name bazzavan.local
  bazzavan.localfe80::a00:27ff:fea5:3f51

  mtearle@liberation:/etc$ avahi-resolve-host-name -4 bazzavan.local
  bazzavan.local172.16.44.48

  # can ping it

  mtearle@liberation:/etc$ ping -c 1 172.16.44.48
  PING 172.16.44.48 (172.16.44.48) 56(84) bytes of data.
  64 bytes from 172.16.44.48: icmp_seq=1 ttl=64 time=0.265 ms

  --- 172.16.44.48 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.265/0.265/0.265/0.000 ms

  # original ordering

  mtearle@liberation:/etc$ grep hosts /etc/nsswitch.conf 
  hosts:  files resolve [!UNAVAIL=return] mdns4_minimal 
[NOTFOUND=return] dns

  # go away and edit /etc/nsswitch.conf
  # change ordering of resolve and mdns4_minimal

  mtearle@liberation:/etc$ grep hosts /etc/nsswitch.conf 
  hosts:  files mdns4_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] dns

  # check mdns lookups now work, and it now pings

  mtearle@liberation:/etc$ ping -c 1 bazzavan.local
  PING bazzavan.local (172.16.44.48) 56(84) bytes of data.
  64 bytes from 172.16.44.48 (172.16.44.48): icmp_seq=1 ttl=64 time=0.161 ms

  --- bazzavan.local ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.161/0.161/0.161/0.000 ms

  
  # check libnss-resolve is still doing its thing

  mtearle@liberation:/etc$ ping -c 1 localhost.localdomain
  PING localhost.localdomain(localhost (::1%1)) 56 data bytes
  64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.016 ms

  --- localhost.localdomain ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.016/0.016/0.016/0.000 ms

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1641328/+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


Re: [Touch-packages] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-12-13 Thread Martin Pitt
Ryan Harper [2016-12-06 12:54 -]:
> The following change should go against systemd-networkd-wait-
> online.service
> 
> + # Ensure that DNS is working before reaching online target
> + After=systemd-networkd-resolvconf-update.service

For the record, this should be the other way around -- add
Before=systemd-networkd-wait-online.service to
s-n-resolvconf-update.service. The latter is a Debian downstream unit
and thus avoids carrying a patch to an upstream unit that refers to a
downstream one.

-- 
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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in resolvconf source package in Xenial:
  In Progress
Status in systemd source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  New
Status in resolvconf source package in Yakkety:
  In Progress
Status in systemd source package in Yakkety:
  Fix Committed
Status in resolvconf package in Debian:
  New

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and 

[Touch-packages] [Bug 1648068] Re: systemd-resolved.service hangs a long time on shutdown

2016-12-12 Thread Martin Pitt
Unfortunately resolvconf does not have a --no-scripts or similar option
that would disable running the update.d/ hooks. One possible local
workaround is to change /lib/systemd/system/systemd-
resolved.service.d/resolvconf.conf from

  ExecStopPost=+/bin/sh -c '[ ! -e /run/resolvconf/enable-updates ] ||
/sbin/resolvconf -d systemd-resolved'

to

  ExecStopPost+=/bin/rm -f /run/resolvconf/interface/systemd-resolved

or to drop the line completely.

This solves the hang on shutdown, but it does not drop 127.0.0.53 any
more from /etc/resolv.conf if you manually stop systemd-resolved.service
in a running system.

This should actually happen the same way with dnsmasq or any other local
DNS server -- if only that is in resolv.conf, then the Avahi hook script
would run into this timeout on "host" as well, as the local name server
is already gone. Our workaround for that in 16.04 was to never stop
dnsmasq even when NetworkManager.service got stopped (via
KillMode=process). However, when you do stop dnsmasq then you get
similar hangs with trying to do DNS queries.

At the moment, if you stop the local DNS server then there is nothing
that would magically bring back the non-local DNS servers into
resolv.conf (neither in zesty with resolved nor in 16.04 with dnsmasq),
so you would run into timeouts either way. Thus I think just dropping
the ExecStopPost= does not actually make things worse, but it fixes the
hang on shutdown.

-- 
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/1648068

Title:
  systemd-resolved.service hangs a long time on shutdown

Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  On shutdown or "systemctl stop systemd-resolved" you get a long hang:

  ● systemd-resolved.service - Network Name Resolution
 CGroup: /system.slice/systemd-resolved.service
 └─control
   ├─15479 /bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || 
/sbin/resolvconf -d systemd-resolved
   ├─15480 run-parts --arg=-d --arg=systemd-resolved 
/etc/resolvconf/update.d
   ├─15483 run-parts /etc/resolvconf/update-libc.d
   ├─15497 /bin/sh /usr/lib/avahi/avahi-daemon-check-dns.sh
   └─15509 host -t soa local.

  So that resolvconf hook tries to do name resolution which does not
  work any more at that time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1648068/+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


[Touch-packages] [Bug 1648068] Re: systemd-resolved.service hangs a long time on shutdown

2016-12-12 Thread Martin Pitt
https://anonscm.debian.org/cgit/pkg-
systemd/systemd.git/commit/?id=dbda116b2

** Changed in: systemd (Ubuntu)
   Status: Triaged => Fix Committed

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Martin Pitt (pitti)

-- 
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/1648068

Title:
  systemd-resolved.service hangs a long time on shutdown

Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  On shutdown or "systemctl stop systemd-resolved" you get a long hang:

  ● systemd-resolved.service - Network Name Resolution
 CGroup: /system.slice/systemd-resolved.service
 └─control
   ├─15479 /bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || 
/sbin/resolvconf -d systemd-resolved
   ├─15480 run-parts --arg=-d --arg=systemd-resolved 
/etc/resolvconf/update.d
   ├─15483 run-parts /etc/resolvconf/update-libc.d
   ├─15497 /bin/sh /usr/lib/avahi/avahi-daemon-check-dns.sh
   └─15509 host -t soa local.

  So that resolvconf hook tries to do name resolution which does not
  work any more at that time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1648068/+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


[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2016-12-12 Thread Martin Pitt
@Anders: ah, so you removed libnss-resolve, but manually enabled
systemd-resolved.service?

-- 
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/1647031

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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


[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2016-12-11 Thread Martin Pitt
I confirm the fact that "dig @127.0.0.53 wiki.freedesktop.org" only
gives the CNAME response, not the resolution of
"annarchy.freedesktop.org." as well, which is sufficient to confirm the
fix.

But nevertheless, firefox, wget, ping etc. on wiki.freedesktop.org all
work fine, but these use NSS. Google Chrome also works fine (which uses
resolv.conf), so this appears to be more like an implementation detail
than a major user-visible bug to me? Can you confirm this, or am I
missing something?

** Changed in: systemd (Ubuntu)
   Importance: Undecided => Low

** Changed in: systemd (Ubuntu)
   Status: Confirmed => Triaged

-- 
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/1647031

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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


[Touch-packages] [Bug 1517257] Re: apport-retrace should install and use gdb for target release

2016-12-09 Thread Martin Pitt
... and change the original patch to only install gdb into the sandbox
if it matches the host architecture, as otherwise it'd be a waste.

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

Title:
  apport-retrace should install and use gdb for target release

Status in Apport:
  Triaged
Status in apport package in Ubuntu:
  Triaged

Bug description:
  apport-retrace will use the version of gdb installed on the system
  performing the retrace. This can cause issues retracing crash reports
  from releases that have a newer toolchain revision than the system
  performing the retrace. Subsequently, it would be better if apport-
  retrace were to install gdb into the sandbox being used for retracing
  and used that version of gdb for analyzing the core dump.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1517257/+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


[Touch-packages] [Bug 1517257] Re: apport-retrace should install and use gdb for target release

2016-12-09 Thread Martin Pitt
Idea from sprint discussion:

In apport:
 - Don't try to run gdb from the retracing target sandbox

 - Add --gdb-root  argument to apport-retrace that will set PATH,
LD_LIBRARY_PATH, and possibly some env var to specify the gdb plugin dir
to appropriate subdirs of . Calling "gdb" should then prefer
running gdb from that dir.

In the retracer deployment:
 - add --gdb-root on the sandbox with the same release but the host's native 
architecture
 - Ensure that gdb is installed in that

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

Title:
  apport-retrace should install and use gdb for target release

Status in Apport:
  Triaged
Status in apport package in Ubuntu:
  Triaged

Bug description:
  apport-retrace will use the version of gdb installed on the system
  performing the retrace. This can cause issues retracing crash reports
  from releases that have a newer toolchain revision than the system
  performing the retrace. Subsequently, it would be better if apport-
  retrace were to install gdb into the sandbox being used for retracing
  and used that version of gdb for analyzing the core dump.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1517257/+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


[Touch-packages] [Bug 1517257] Re: apport-retrace should install and use gdb for target release

2016-12-09 Thread Martin Pitt
> some env var to specify the gdb plugin dir

That seems to be it:
(gdb) show data-directory 
GDB's data directory is "/usr/share/gdb".

so we can add that to the gdb invocation (gdb_cmd in add_gdb_info()).

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

Title:
  apport-retrace should install and use gdb for target release

Status in Apport:
  Triaged
Status in apport package in Ubuntu:
  Triaged

Bug description:
  apport-retrace will use the version of gdb installed on the system
  performing the retrace. This can cause issues retracing crash reports
  from releases that have a newer toolchain revision than the system
  performing the retrace. Subsequently, it would be better if apport-
  retrace were to install gdb into the sandbox being used for retracing
  and used that version of gdb for analyzing the core dump.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1517257/+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


[Touch-packages] [Bug 1616422] Update Released

2016-12-08 Thread Martin Pitt
The verification of the Stable Release Update for init-system-helpers
has completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
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


[Touch-packages] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-12-08 Thread Martin Pitt
** Also affects: resolvconf (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847440
   Importance: Unknown
   Status: Unknown

-- 
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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in resolvconf package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in resolvconf source package in Xenial:
  In Progress
Status in systemd source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  New
Status in resolvconf source package in Yakkety:
  In Progress
Status in systemd source package in Yakkety:
  Fix Committed
Status in resolvconf package in Debian:
  Unknown

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

  SRU INFORMATION FOR systemd
  ===
  Fix: For xenial it is sufficient to drop systemd-networkd's 

[Touch-packages] [Bug 1618900] Re: [Xenial/0.90] Systemd dependencies issues when used in "Shutdown mode"

2016-12-08 Thread Martin Pitt
Oh, actually not -- that would be for a service which gets *stopped*
during shutdown (i. e. the usual way). If you want to *start* on
shutdown, you need to be Before=network.target.

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

Title:
  [Xenial/0.90] Systemd dependencies issues when used in "Shutdown mode"

Status in unattended-upgrades package in Ubuntu:
  Confirmed

Bug description:
  Using unattended-upgrades 0.90 in "Shutdown mode" on Ubuntu Xenial, we 
encounter the following systemd dependencies issues :
  - The network is often down when unattended-upgrades is running, so packages 
can not be downloaded (can be mitigated by using 
APT::Periodic::Download-Upgradeable-Packages "1";) :
  => ERROR An error occurred: 'Could not resolve host: .fr'
  => ERROR The URI 
'https://.fr:33000/ubuntu-security/pool/main/libi/libidn/libidn11_1.32-3ubuntu1.1_amd64.deb'
 failed to download, aborting
  - Important mountpoints like /boot are unmounted before unattended-upgrades 
is running, so newer kernels can not be installed properly (ramdisk and grub 
configuration can not be generated)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1618900/+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


[Touch-packages] [Bug 1618900] Re: [Xenial/0.90] Systemd dependencies issues when used in "Shutdown mode"

2016-12-08 Thread Martin Pitt
If a unit needs to get stopped before the network gets stopped, you
shold add "After=network.target". (See man systemd.special).

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

Title:
  [Xenial/0.90] Systemd dependencies issues when used in "Shutdown mode"

Status in unattended-upgrades package in Ubuntu:
  Confirmed

Bug description:
  Using unattended-upgrades 0.90 in "Shutdown mode" on Ubuntu Xenial, we 
encounter the following systemd dependencies issues :
  - The network is often down when unattended-upgrades is running, so packages 
can not be downloaded (can be mitigated by using 
APT::Periodic::Download-Upgradeable-Packages "1";) :
  => ERROR An error occurred: 'Could not resolve host: .fr'
  => ERROR The URI 
'https://.fr:33000/ubuntu-security/pool/main/libi/libidn/libidn11_1.32-3ubuntu1.1_amd64.deb'
 failed to download, aborting
  - Important mountpoints like /boot are unmounted before unattended-upgrades 
is running, so newer kernels can not be installed properly (ramdisk and grub 
configuration can not be generated)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1618900/+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


[Touch-packages] [Bug 1648037] Re: Ubuntu 16.10: systemd-resolved does not resolve some domains

2016-12-08 Thread Martin Pitt
Can you please do the following:
  sudo systemctl stop systemd-resolved.service
  sudo script -c 'SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-resolved' 
/tmp/resolved.log

and on another terminal "systemd-resolve buy.ubuntu.com". Then press Control-C 
in the first terminal and attach /tmp/resolved.log
. Thanks!

** Changed in: systemd (Ubuntu)
   Status: New => Incomplete

** Tags added: resolved

-- 
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/1648037

Title:
  Ubuntu 16.10: systemd-resolved does not resolve some domains

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Some domains are not resolved with default systemd-resolved set up on
  Ubuntu 16.10. This set up is querying the DNS server given by DHCP,
  and is my ISP's router.

  Now, checking with `dig` directly against 192.168.1.1 (the router),
  dig complains that "Warning: Message parser reports malformed message
  packet.". And indeed, for the domains that do not resolve, this
  warning is always given by dig, when I query the router.

  It would appear that the router or its upstream is somehow breaking
  the DNS packets/responses and I'll have to figure that one out
  separately.

  The bug here is that systemd-resolved is failing on those while every
  other resolver seems to be working fine with those (supposedly
  malformed) replies. All other devices in the network, phones, windows,
  ubuntu 16.04, etc...  are resolving with those just fine.

  Most notably, I can't resolve  "buy.ubuntu.com". I've captured the
  packet/reply I get from my router, it's attached.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: systemd 231-9ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-30.32-generic 4.8.6
  Uname: Linux 4.8.0-30-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl nvidia_uvm nvidia_drm 
nvidia_modeset nvidia
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Dec  7 11:17:43 2016
  InstallationDate: Installed on 2016-11-28 (8 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  MachineType: ASUS All Series
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-30-generic 
root=UUID=eb750983-a34c-4b58-b5f0-a0cfa1130d1b ro
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/04/2015
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 0504
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: H81M-R
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev X.0x
  dmi.chassis.asset.tag: Asset-1234567890
  dmi.chassis.type: 3
  dmi.chassis.vendor: Chassis Manufacture
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0504:bd06/04/2015:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnH81M-R:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
  dmi.product.name: All Series
  dmi.product.version: System Version
  dmi.sys.vendor: ASUS
  modified.conffile..etc.systemd.resolved.conf: [modified]
  mtime.conffile..etc.systemd.resolved.conf: 2016-12-07T10:46:19.412121

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1648037/+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


[Touch-packages] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-12-08 Thread Martin Pitt
** Changed in: resolvconf (Ubuntu Xenial)
   Status: Triaged => In Progress

** Changed in: resolvconf (Ubuntu Yakkety)
   Status: Triaged => In Progress

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

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in resolvconf package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in resolvconf source package in Xenial:
  In Progress
Status in systemd source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  New
Status in resolvconf source package in Yakkety:
  In Progress
Status in systemd source package in Yakkety:
  Fix Committed

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

  SRU INFORMATION FOR systemd
  ===
  Fix: For xenial it is sufficient to drop systemd-networkd's 
After=dbus.service 

[Touch-packages] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-12-08 Thread Martin Pitt
Reuploaded x/y/z to add missing Wants=network-pre.target.

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

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in resolvconf package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in resolvconf source package in Xenial:
  In Progress
Status in systemd source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  New
Status in resolvconf source package in Yakkety:
  In Progress
Status in systemd source package in Yakkety:
  Fix Committed

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

  SRU INFORMATION FOR systemd
  ===
  Fix: For xenial it is sufficient to drop systemd-networkd's 
After=dbus.service (https://github.com/systemd/systemd/commit/5f004d1e32) and 
(for xenial only) drop the useless 

[Touch-packages] [Bug 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
Ah, so you didn't have resolvconf installed (and therefore also not
ubuntu-minimal), that's a good data point, thank you! This should be
part of this bug -- NM should get along with this better.

Do you see the search domain in "systemd-resolve --status"?

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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


[Touch-packages] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-12-07 Thread Martin Pitt
resolvconf uploaded to zesty and x/y SRU review queues. Please forward
to Debian too.

** Changed in: resolvconf (Ubuntu)
   Status: Triaged => Fix Committed

** Changed in: resolvconf (Ubuntu)
 Assignee: (unassigned) => Ryan Harper (raharper)

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

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in resolvconf package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in resolvconf source package in Xenial:
  Triaged
Status in systemd source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  New
Status in resolvconf source package in Yakkety:
  Triaged
Status in systemd source package in Yakkety:
  Fix Committed

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

  SRU INFORMATION FOR systemd
  ===
  Fix: For xenial it 

[Touch-packages] [Bug 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
What does "systemctl status resolvconf" say? is it not running for you?

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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


[Touch-packages] [Bug 1644330] Re: systemd-resolved assumes that /etc/hosts for one address family means it doesn't ask DNS for another

2016-12-07 Thread Martin Pitt
** Changed in: systemd (Ubuntu)
Milestone: None => ubuntu-16.12

-- 
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/1644330

Title:
  systemd-resolved assumes that /etc/hosts for one address family means
  it doesn't ask DNS for another

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  I have an ipv4 entry for a key host on my network listed in
  /etc/hosts, for network recovery purposes.  This host also has ipv6
  connectivity; the ipv6 address is resolvable via DNS, but I do not
  have it in /etc/hosts.  Resolution of hostname should be independent
  for each address family.

  Two days ago (I don't know what changed to trigger this), I stopped
  being able to resolve the ipv6 address for this host.  I traced this
  down to systemd-resolved, returning a lookup failure for the nss
  request, because the ipv6 address is not listed in /etc/hosts.

  Removing resolve from /etc/nsswitch.conf restores the correct
  behavior.

  Removing the ipv4 entry for the host restores the correct behavior.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: systemd 231-9ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1
  Uname: Linux 4.8.0-27-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Nov 23 08:13:33 2016
  InstallationDate: Installed on 2010-09-24 (2252 days ago)
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 
(20100816.1)
  MachineType: LENOVO 2306CTO
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-27-generic.efi.signed 
root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to yakkety on 2016-10-28 (25 days ago)
  dmi.bios.date: 10/25/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET97WW (2.57 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2306CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 2306CTO
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1644330/+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


[Touch-packages] [Bug 1648068] [NEW] systemd-resolved.service hangs a long time on shutdown

2016-12-07 Thread Martin Pitt
Public bug reported:

On shutdown or "systemctl stop systemd-resolved" you get a long hang:

● systemd-resolved.service - Network Name Resolution
   CGroup: /system.slice/systemd-resolved.service
   └─control
 ├─15479 /bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || 
/sbin/resolvconf -d systemd-resolved
 ├─15480 run-parts --arg=-d --arg=systemd-resolved 
/etc/resolvconf/update.d
 ├─15483 run-parts /etc/resolvconf/update-libc.d
 ├─15497 /bin/sh /usr/lib/avahi/avahi-daemon-check-dns.sh
 └─15509 host -t soa local.

So that resolvconf hook tries to do name resolution which does not work
any more at that time.

** Affects: systemd (Ubuntu)
 Importance: Medium
 Status: Triaged


** Tags: resolved

** Tags added: resolved

** Summary changed:

- systemd-resolved hangs a long time on shutdown
+ systemd-resolved.service hangs a long time on shutdown

** Changed in: systemd (Ubuntu)
   Status: New => Triaged

** Changed in: systemd (Ubuntu)
   Importance: Undecided => Medium

-- 
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/1648068

Title:
  systemd-resolved.service hangs a long time on shutdown

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  On shutdown or "systemctl stop systemd-resolved" you get a long hang:

  ● systemd-resolved.service - Network Name Resolution
 CGroup: /system.slice/systemd-resolved.service
 └─control
   ├─15479 /bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || 
/sbin/resolvconf -d systemd-resolved
   ├─15480 run-parts --arg=-d --arg=systemd-resolved 
/etc/resolvconf/update.d
   ├─15483 run-parts /etc/resolvconf/update-libc.d
   ├─15497 /bin/sh /usr/lib/avahi/avahi-daemon-check-dns.sh
   └─15509 host -t soa local.

  So that resolvconf hook tries to do name resolution which does not
  work any more at that time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1648068/+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


[Touch-packages] [Bug 1647178] Re: systemd-resolved unable to resolve certain subdomains

2016-12-07 Thread Martin Pitt
I can't reproduce this, and Louis said that he can't either and he's
going to investigate this further. He'll follow up.

** Changed in: systemd (Ubuntu)
   Status: New => Incomplete

-- 
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/1647178

Title:
  systemd-resolved unable to resolve certain subdomains

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  After upgrade to systemd-resolved, certain very well known subdomains
  are no longer resolved. Their TLD do resolve correctly. Example given
  with mail.google.com and google.com

  On xenial :
  $ nslookup mail.google.com
  Server: 192.168.1.1
  Address:192.168.1.1#53

  Non-authoritative answer:
  mail.google.com canonical name = googlemail.l.google.com.
  Name:   googlemail.l.google.com
  Address: 216.58.198.197

  $ dig mail.google.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57929
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4000
  ;; QUESTION SECTION:
  ;mail.google.com.   IN  A

  ;; ANSWER SECTION:
  mail.google.com.441512  IN  CNAME   googlemail.l.google.com.
  googlemail.l.google.com. 274IN  A   216.58.198.197

  ;; Query time: 14 msec
  ;; SERVER: 192.168.1.1#53(192.168.1.1)
  ;; WHEN: Sun Dec 04 18:12:43 CET 2016
  ;; MSG SIZE  rcvd: 87

  On Zesty using systemd-resolved :

  # nslookup mail.google.com
  Server: 10.0.3.1
  Address:10.0.3.1#53

  Non-authoritative answer:
  mail.google.com canonical name = googlemail.l.google.com.

  # nslookup google.com
  Server: 10.0.3.1
  Address:10.0.3.1#53

  Non-authoritative answer:
  Name:   google.com
  Address: 216.58.198.206

  # dig mail.google.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10775
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;mail.google.com.   IN  A

  ;; ANSWER SECTION:
  mail.google.com.441414  IN  CNAME   googlemail.l.google.com.

  ;; Query time: 0 msec
  ;; SERVER: 10.0.3.1#53(10.0.3.1)
  ;; WHEN: Sun Dec 04 17:14:21 UTC 2016
  ;; MSG SIZE  rcvd: 81

  # dig google.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25303
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;google.com.IN  A

  ;; ANSWER SECTION:
  google.com. 160 IN  A   216.58.198.206

  ;; Query time: 0 msec
  ;; SERVER: 10.0.3.1#53(10.0.3.1)
  ;; WHEN: Sun Dec 04 17:14:37 UTC 2016
  ;; MSG SIZE  rcvd: 55

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647178/+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


[Touch-packages] [Bug 1449001] Re: systemd-resolved: please do not use Google public DNS by default

2016-12-07 Thread Martin Pitt
** Tags added: resolved

-- 
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/1449001

Title:
  systemd-resolved: please do not use Google public DNS by default

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.)
  in the absence of other configured DNS servers.

  systemd-resolved is not enabled by default in Ubuntu 15.04, but it is
  installed by default and will behave in this way if enabled by the
  user.

  $ cat /etc/systemd/resolved.conf 
  (...)
  # Entries in this file show the compile time defaults.
  (...)
  #FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860:: 2001:4860:4860::8844

  This raises privacy concerns since in the event of accidental
  misconfiguration DNS queries will be sent unencrypted across the
  internet, and potentially also security concerns given systemd-
  resolved does not perform DNSSEC validation and is not particularly
  well hardened against malicious responses e.g. from a MITM
  (http://www.openwall.com/lists/oss-security/2014/11/12/5).

  I believe that it would be better to fail safe if no DNS server is
  configured -- i.e. have DNS lookups fail; it's better that the user is
  aware of their misconfiguration, rather than silently sending their
  queries to Google.  The user can intentionally opt to use Google
  public DNS if they wish.


  Steps to reproduce:
  1. Remove existing DNS configuration (from /etc/network/interfaces, 
/etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*)
  2. Reboot, or otherwise clear relevant state
  3. sudo service systemd-resolved start
  4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf
  5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by 
default), observe that DNS lookups probably still work, and queries are being 
sent to one of Google's servers

  
  Possible workaround/bugfix: ship a resolved.conf which clears the FallbackDNS 
parameter.

  
  This issue has been discussed in the Debian BTS 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658).  My interpretation 
of the Debian package maintainer's position is that a user concerned with the 
privacy implications shouldn't let systemd get into a state where it uses the 
fallback DNS servers (quoting Marco d'Itri: "Short summary: have a resolv.conf 
file or use DHCP").  I would argue that it's safest not to have fallback DNS 
servers configured at all by default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1449001/+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


[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS

2016-12-07 Thread Martin Pitt
** Tags added: resolved

-- 
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/1624317

Title:
  systemd-resolved breaks VPN with split-horizon DNS

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I use a VPN configured with network-manager-openconnect-gnome in which
  a split-horizon DNS setup assigns different addresses to some names
  inside the remote network than the addresses seen for those names from
  outside the remote network.  However, systemd-resolved often decides
  to ignore the VPN’s DNS servers and use the local network’s DNS
  servers to resolve names (whether in the remote domain or not),
  breaking the split-horizon DNS.

  This related bug, reported by Lennart Poettering himself, was closed with the 
current Fedora release at the time reaching EOL:
  https://bugzilla.redhat.com/show_bug.cgi?id=1151544

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1624317/+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


[Touch-packages] [Bug 1624320] Re: systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing entries

2016-12-07 Thread Martin Pitt
As explained, 127.0.0.53 must be in /etc/resolv.conf in order to support
Chromium and other software which does not NSS -- that is the whole
raison d'être for providing a local stub server.

In Yakkety with NetworkManager only the 127.0.1.1 dnsmasq server is in
/etc/resolv.conf, so that isn't affected. In Zesty NM now does not
manager resolv.conf itself any more but just sends the acquired name
servers to resolved.

Thus, is there anything left from the original bug report that still
needs to be addressed?

** Changed in: systemd (Ubuntu)
   Status: Triaged => Incomplete

** Tags added: resolved

-- 
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/1624320

Title:
  systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing
  entries

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  systemd-resolved, or more precisely the hook script
  /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf, causes
  resolvconf to add 127.0.0.53 to the set of nameservers in
  /etc/resolv.conf alongside the other nameservers.  That makes no sense
  because systemd-resolved sets up 127.0.0.53 as a proxy for those other
  nameservers.  The effect is similar to bug 1624071 but for
  applications doing their own DNS lookups.  It breaks any DNSSEC
  validation that systemd-resolved tries to do; applications will
  failover to the other nameservers, bypassing validation failures.  And
  it makes failing queries take twice as long.

  /etc/resolv.conf should have only 127.0.0.53 when systemd-resolved is
  active.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320/+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


[Touch-packages] [Bug 1628778] Re: systemd-resolved: after network reconnection, DNSSEC unsigned zones treated as bogus, stop resolving

2016-12-07 Thread Martin Pitt
** Tags added: dnssec resolved

-- 
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/1628778

Title:
  systemd-resolved: after network reconnection, DNSSEC unsigned zones
  treated as bogus, stop resolving

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  On the MIT network (which runs some ancient version of BIND 9),
  systemd-resolved stops resolving anything that isn’t DNSSEC-signed
  after I disconnect and reconnect the network. Signed zones continue to
  resolve.

  This happens with either DNSSEC=yes or the default DNSSEC=allow-
  downgrade.

  $ systemd-resolve github.com
  github.com: 192.30.253.113

  -- Information acquired via protocol DNS in 15.6ms.
  -- Data is authenticated: no
  $ # (disconnect and reconnect wifi)
  $ systemd-resolve github.com
  github.com: resolve call failed: DNSSEC validation failed: no-signature

  More debug information is available in my upstream report
  (https://github.com/systemd/systemd/issues/4175), which has gotten no
  response in the last week and a half.

  I’m refiling this here because I believe that this regression and
  others (bug 1588230, bug 1624071, bug 1624317, bug 1449001) indicate
  that systemd-resolved is not ready for production, and with final
  freeze just a week away, leaving systemd-resolved enabled for the
  yakkety release would be reckless.  [Edit: Oh, I see that conclusion
  was already reached yesterday.]

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1628778/+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


[Touch-packages] [Bug 289760] Re: [Ibex] language-pack-fr-base - Depends: language-pack-fr but it is not going to be installed

2016-12-07 Thread Martin Pitt
** Tags removed: problem resolved
** Tags added: problem-resolved

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

Title:
  [Ibex] language-pack-fr-base - Depends: language-pack-fr but it is not
  going to be installed

Status in language-pack-fr-base package in Ubuntu:
  New

Bug description:
  Binary package hint: language-pack-fr-base

  Synaptic shows language-pack-fr-base and language-pack-gnome-fr-base
  as available for upgrade, but can't mark them for upgrade:

  language-pack-fr-base:
   Depends: language-pack-fr but it is not going to be installed

  language-pack-gnome-fr-base:
   Depends: language-pack-gnome-fr but it is not going to be installed

  Moreover if you want to uninstall this two packages :
  language-pack-fr-base
  language-pack-gnome-fr-base
  it is impossible to re-install them, so for now my computer is in english,
  hope this bug will be corrected as soon as possible ! Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/language-pack-fr-base/+bug/289760/+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


[Touch-packages] [Bug 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
** Tags added: resolved

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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


[Touch-packages] [Bug 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records

2016-12-07 Thread Martin Pitt
** Tags added: resolved

-- 
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/1647031

Title:
  systemd-resolved’s 127.0.0.53 server does not follow CNAME records

Status in systemd:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  $ systemd-resolve www.freedesktop.org
  www.freedesktop.org: 131.252.210.176
   2610:10:20:722:a800:ff:feda:470f
   (annarchy.freedesktop.org)

  -- Information acquired via protocol DNS in 673.6ms.
  -- Data is authenticated: no
  $ ping www.freedesktop.org
  ping: www.freedesktop.org: Name or service not known
  $ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.

  nameserver 127.0.0.53
  $ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  7146IN  CNAME   annarchy.freedesktop.org.
  $ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
  ;www.freedesktop.org. IN  A
  www.freedesktop.org.  14399   IN  CNAME   annarchy.freedesktop.org.
  annarchy.freedesktop.org. 14399   IN  A   131.252.210.176

  I trust it needn’t be explained why this makes the internet almost
  completely useless in zesty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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


[Touch-packages] [Bug 1641468] Re: systemd-resolve: fallback from resolve causes lookup of local network hosts to fail

2016-12-07 Thread Martin Pitt
** Tags added: resolved

-- 
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/1641468

Title:
  systemd-resolve: fallback from resolve causes lookup of local network
  hosts to fail

Status in systemd package in Ubuntu:
  New

Bug description:
  After upgrading to Ubuntu 16.10 from 16.04, DNS resolution of hosts on
  my local network fails.

  The hosts line in /etc/nsswitch.conf is:
  hosts:  files mdns4_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] dns mdns4

  If I change it to:
  hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4

  I can resolve hosts on my local network. Appending .local to the
  hostname also allows DNS resolution since systemd-resolve returns a
  different error for that case.

  Ex:
  systemd-resolve rt-ac66u
  rt-ac66u: resolve call failed: All attempts to contact name servers or 
networks failed

  systemd-resolve rt-ac66u.local
  rt-ac66u.local: resolve call failed: No appropriate name servers or networks 
for name found

  "dig rt-ac66u" returns the correct ip.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1641468/+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


[Touch-packages] [Bug 1647178] Re: systemd-resolved unable to resolve certain subdomains

2016-12-07 Thread Martin Pitt
** Tags added: resolved

-- 
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/1647178

Title:
  systemd-resolved unable to resolve certain subdomains

Status in systemd package in Ubuntu:
  New

Bug description:
  After upgrade to systemd-resolved, certain very well known subdomains
  are no longer resolved. Their TLD do resolve correctly. Example given
  with mail.google.com and google.com

  On xenial :
  $ nslookup mail.google.com
  Server: 192.168.1.1
  Address:192.168.1.1#53

  Non-authoritative answer:
  mail.google.com canonical name = googlemail.l.google.com.
  Name:   googlemail.l.google.com
  Address: 216.58.198.197

  $ dig mail.google.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57929
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4000
  ;; QUESTION SECTION:
  ;mail.google.com.   IN  A

  ;; ANSWER SECTION:
  mail.google.com.441512  IN  CNAME   googlemail.l.google.com.
  googlemail.l.google.com. 274IN  A   216.58.198.197

  ;; Query time: 14 msec
  ;; SERVER: 192.168.1.1#53(192.168.1.1)
  ;; WHEN: Sun Dec 04 18:12:43 CET 2016
  ;; MSG SIZE  rcvd: 87

  On Zesty using systemd-resolved :

  # nslookup mail.google.com
  Server: 10.0.3.1
  Address:10.0.3.1#53

  Non-authoritative answer:
  mail.google.com canonical name = googlemail.l.google.com.

  # nslookup google.com
  Server: 10.0.3.1
  Address:10.0.3.1#53

  Non-authoritative answer:
  Name:   google.com
  Address: 216.58.198.206

  # dig mail.google.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10775
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;mail.google.com.   IN  A

  ;; ANSWER SECTION:
  mail.google.com.441414  IN  CNAME   googlemail.l.google.com.

  ;; Query time: 0 msec
  ;; SERVER: 10.0.3.1#53(10.0.3.1)
  ;; WHEN: Sun Dec 04 17:14:21 UTC 2016
  ;; MSG SIZE  rcvd: 81

  # dig google.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25303
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;google.com.IN  A

  ;; ANSWER SECTION:
  google.com. 160 IN  A   216.58.198.206

  ;; Query time: 0 msec
  ;; SERVER: 10.0.3.1#53(10.0.3.1)
  ;; WHEN: Sun Dec 04 17:14:37 UTC 2016
  ;; MSG SIZE  rcvd: 55

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647178/+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


[Touch-packages] [Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

2016-12-07 Thread Martin Pitt
This is still being discussed upstream, so let's get to an agreement
there first, land it in upstream master, and then backport the change.
Note that there is not much point with debdiffs, it's easier to cherry-
pick the fix directly into the packaging branches with gbp pq and debian
/git-cherry-pick.

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/4833
   Importance: Unknown
   Status: Unknown

-- 
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/1647485

Title:
  NVMe symlinks broken by devices with spaces in model or serial strings

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  [Impact]

  After including the patch from bug 1642903, NVMe devices that include spaces 
in their model or serial strings result in incorrect symlinks, e.g. if the 
model string is "XYZ Corp NVMe drive" then instead of creating:
  /dev/disk/by-id/nvme-XYZ Corp NVMe drive_SERIAL -> ../../nvme0n1
  it creates:
  /dev/disk/by-id/nvme-XYZ -> ../../nvme0n1
  /dev/Corp -> nvme0n1
  /dev/NVMe -> nvme0n1
  /dev/drive_SERIAL -> nvme0n1

  This is because of the way udev handles the SYMLINK value strings; by
  default, it does not do any whitespace replacement.  To enable
  whitespace replacement of a symlink value, the rule must also include
  OPTIONS+="string_escape=replace".  This is done for 'md' and 'dm'
  devices in their rules.  However, there are no rules that actually
  want to specify multiple symlinks, and defaulting to not replacing
  whitespace makes no sense; instead, the default should be to replace
  all whitespace in each symlink value, unless the rule explicitly
  specifies OPTIONS+="string_escape=none".

  [Test Case]

  This assumes using udev with the patch from bug 1642903.

  Without this patch, when using a NVMe drive that contains spaces in
  its model and/or serial strings, check the /dev/disk/by-id/ directory.
  It should contain a partially-correct symlink to the NVMe drive, with
  the name up to the first space.  All following space-separated parts
  of the mode/serial string should have symlinks in the /dev/ directory.
  This is the incorrect behavior.

  With this patch, check the /dev/disk/by-id/ directory.  It should
  contain a fully-correct symlink to the NVMe drive, and no part of the
  drive's model/serial number string should be a link in the /dev
  directory.

  An example of the correct/incorrect naming is in the Impact section.

  There should be no other changes to any of the symlinks under /dev
  before and after this patch.  Typical locations for symlinks are
  /dev/, /dev/disk/by-name/, /dev/disk/by-id/, /dev/disk/by-uuid/,
  /dev/disk/by-label/

  [Regression Potential]

  Errors in udev rules can lead to an unbootable or otherwise completely
  broken system if they unintentionally break or clobber existing
  /dev/disks/ symlinks.

  [Other Info]

  This is also tracked with upstream systemd (udev) bug 4833:
  https://github.com/systemd/systemd/issues/4833

  Also note, this can be worked around in individual rules ONLY (i.e.
  not fixed for all rules) by appending OPTIONS+="string_escape=replace"
  to each of the NVMe rules with SYMLINK+="..." assignment, e.g.:

  KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{model}=="?*",
  ENV{ID_SERIAL_SHORT}=="?*",
  ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk
  /by-id/nvme-$env{ID_SERIAL}", OPTIONS+="string_escape=replace"

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647485/+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


[Touch-packages] [Bug 1647133] Re: dns=dnsmasq does not work any more

2016-12-07 Thread Martin Pitt
> # Generated by NetworkManager
> nameserver 127.0.1.1

OK, that's definitively unexpected. It looks like NM is still using a
different plugin for managing /etc/resolv.conf and that thinks it's
using the dnsmasq plugin (127.0.1.1) while not actually starting
dnsmasq. That part is understood and what I retitled the bug to.

What is not clear is why your NM uses that configuration despite not
setting it in NetworkManager.conf.

joulu 06 19:05:04 Sabertooth NetworkManager[576]: 
[1481043904.5853] dns-mgr[0x55f3c8285000]: init: dns=systemd-resolved,
rc-manager=symlink, plugin=systemd-resolved

That actually looks expected. Maybe your /etc/resolv.conf is not a
symlink to ../run/resolvconf/resolv.conf but a plain file? If so, please
do

  sudo systemctl stop NetworkManager
  sudo rm /etc/resolv.conf
  sudo ln -s ../run/resolvconf/resolv.conf /etc/resolv.conf
  sudo systemctl start NetworkManager

This hopefully should fix things.

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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


[Touch-packages] [Bug 1636375] Re: systemd-resolved does not allow you to connect using subdomains using search domains which are in /etc/resolv.conf

2016-12-06 Thread Martin Pitt
I'm afraid this is by design and wontfix, see
https://github.com/systemd/systemd/issues/4821#issuecomment-264995354
for details. This isn't something which we reasonably can/should change
downstream, so I suggest to direct discussions to the upstream bug.
Thanks!

** Changed in: systemd (Ubuntu)
   Status: Triaged => Won't Fix

-- 
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/1636375

Title:
  systemd-resolved does not allow you to connect using subdomains using
  search domains which are in /etc/resolv.conf

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  systemd-resolved doesn't seem to allow you to use subdomains when
  connecting to hosts in domains that are part of /etc/resolv.conf

  e.g.

  16:01|scrosby@stewie: ~$ cat /etc/resolv.conf 
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver W.X.Y.Z
  nameserver A.B.C.D
  nameserver 127.0.0.53
  search blah1 blah2 blah3 blah4 blah5

  with systemd-resolved running

  16:05|scrosby@stewie: ~$ ping foo.bar
  ping: foo.bar: Name or service not known

  without systemd-resolved running

  16:05|scrosby@stewie: ~$ ping foo.bar
  PING foo.bar.blah3 (E.F.G.H) 56(84) bytes of data.
  64 bytes from foo.bar.blah3 (E.F.G.H): icmp_seq=1 ttl=52 time=1.68 ms
  64 bytes from foo.bar.blah3 (E.F.G.H): icmp_seq=2 ttl=52 time=1.09 ms

  It does seem like looking up hosts without a . in their name does use
  the search domains in resolv.conf though

  16:05|scrosby@stewie: ~$ ping foo2
  PING foo2.blah3 (I.J.K.L) 56(84) bytes of data.
  64 bytes from foo2.blah3 (I.J.K.L): icmp_seq=1 ttl=52 time=1.34 ms
  64 bytes from foo2.blah3 (I.J.K.L): icmp_seq=2 ttl=52 time=1.29 ms

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: systemd 231-9git1
  ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
  Uname: Linux 4.8.0-26-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  Date: Tue Oct 25 16:13:38 2016
  InstallationDate: Installed on 2016-06-08 (139 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  MachineType: Dell Inc. OptiPlex 990
  ProcEnviron:
   LANGUAGE=en_AU:en
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_AU.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-26-generic 
root=UUID=67011022-ac91-464f-ab8f-c97c6cb5a439 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to yakkety on 2016-10-24 (0 days ago)
  dmi.bios.date: 08/26/2015
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A19
  dmi.board.asset.tag: UOM97917
  dmi.board.name: 0VNP2H
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.asset.tag: UOM97917
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA19:bd08/26/2015:svnDellInc.:pnOptiPlex990:pvr01:rvnDellInc.:rn0VNP2H:rvrA00:cvnDellInc.:ct3:cvr:
  dmi.product.name: OptiPlex 990
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1636375/+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


[Touch-packages] [Bug 1603436] Update Released

2016-12-06 Thread Martin Pitt
The verification of the Stable Release Update for python-cassandra-
driver has completed successfully and the package has now been released
to -updates.  Subsequently, the Ubuntu Stable Release Updates Team is
being unsubscribed and will not receive messages about this bug report.
In the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  Regression in python2.7 SRU breaks python-cassandra

Status in python-cassandra-driver package in Ubuntu:
  Fix Released
Status in python2.7 package in Ubuntu:
  Invalid
Status in python-cassandra-driver source package in Xenial:
  Fix Released
Status in python2.7 source package in Xenial:
  Invalid
Status in python-cassandra-driver source package in Yakkety:
  Fix Released
Status in python2.7 source package in Yakkety:
  Invalid

Bug description:
  "SRU: backport python 2.7.12 to 16.04 LTS" (bug 1591895) has caused a
  regression in (at least) python-cassandra. Any attempt to connect to a
  cluster fails due to:

  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/cassandra/cluster.py", line 1894, in 
_reconnect_internal
  return self._try_connect(host)
File "/usr/lib/python2.7/dist-packages/cassandra/cluster.py", line 1921, in 
_try_connect
  self_weakref = weakref.ref(self, callback=partial(_clear_watcher, 
weakref.proxy(connection)))
  TypeError: ref() does not take keyword arguments

  It would appear that Python 2.7.12 has made the permitted calling
  conventions for weakref.ref() stricter.

  See https://github.com/datastax/python-driver/pull/585 for upstream
  discussion of the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-cassandra-driver/+bug/1603436/+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


[Touch-packages] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-12-06 Thread Martin Pitt
>  Before=networking.service
> +Before=systemd-networkd.service

FTR, this should be generalized to Before=network-pre.target. This is
also applicable to Debian.

** Also affects: resolvconf (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: resolvconf (Ubuntu)
   Status: New => Triaged

** Changed in: resolvconf (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: resolvconf (Ubuntu Yakkety)
   Status: New => Triaged

-- 
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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in resolvconf package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in resolvconf source package in Xenial:
  Triaged
Status in systemd source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  New
Status in resolvconf source package in Yakkety:
  Triaged
Status in systemd source package in Yakkety:
  Fix Committed

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init   

[Touch-packages] [Bug 1647133] Re: dns=dnsmasq does not work any more

2016-12-06 Thread Martin Pitt
OK, thanks. I'm afraid I need the NM log and /etc/resolv.conf with NM
1.4.2-2ubuntu4 without "dns=dnsmasq".

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

Title:
  dns=dnsmasq does not work any more

Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  Network-manager will make my network connection immediately lost after 
updating to the newest version 1.4.2-2ubuntu4.
  However, downgrading to the previous version 1.4.2-2ubuntu3 the network 
connection is back again and fine. If, with this version, I remove the file 
(link) /etc/resolv.conf the network is broken again. Rebooting solves this, as 
network-manager creates a new resolv.conf file.

  The newest version 1.4.2-2ubuntu4 also creates the very same kind of
  file, but no network.

  I have the latest (Gnome-shell DE) updates installed and of course all 
packages that network-manager depends on. But not the ones it only recommends 
or suggests.
  Should I have resolvconf installed? I think not, as isc-dhcp-client only 
suggests it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1647133/+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


[Touch-packages] [Bug 1643084] Update Released

2016-12-06 Thread Martin Pitt
The verification of the Stable Release Update for procps has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  [REGRESSION] kill segfaults w/ single, negative PID

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  Fix Released

Bug description:
  [Impact]
  The kill binary will segfault when called w/ a single, negative PID. This 
breaks a use case where you maybe sending the default signal (SIGTERM) to all 
processes (-1) or all processes in a process group (-

  1   2   3   4   5   6   7   8   9   10   >