[Touch-packages] [Bug 1853894] Re: Strange Hang with old SWT Apps

2019-11-25 Thread eitch
I have also tried to see if this issue arises on PopOS, which it does in
the versions after the last LTS. The current PopOS LTS does not have the
issue.

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

Title:
  Strange Hang with old SWT Apps

Status in gtk+2.0 package in Ubuntu:
  New

Bug description:
  I have a weird issue where an old app of mine which is written in
  Eclipse RCP using SWT. It is an older Eclipse 3.x version.

  I am running uptodate Ubuntu 19.10, on Ubuntu 18.4 LTS everything
  works fine.

  When i start the app after compiling it using the latest Eclipse
  edition, then when i start the app, first i needed to install
  libgtk2.0-0. Which i found out using ldd.

  The app then doesn't start for quite a while. I can't see any errors
  ore warnings anywhere. Maybe someone can point me in the right area?

  Anyhow, searching the web i did find a solution: Either i start the
  app as root, or using the following command:

  dbus-launch --exit-with-session java -jar MyApp.jar

  But both are not very helpful as i can't start the app like this from
  Eclipse to allow for debugging and modifying. And starting as root
  isn't optimal either.

  Has anyone got any idea on how i can fix this, or is this perhaps some
  kind of bug?

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: libgtk2.0-0 2.24.32-4ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Nov 25 20:34:58 2019
  InstallationDate: Installed on 2019-11-25 (0 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: gtk+2.0
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1853894/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
** Tags added: update-excuse

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853956] [NEW] 34 wireguard peers result in invalid peer configuration

2019-11-25 Thread Joshua Sjoding
Public bug reported:

ubuntu server 18.04.3 LTS
systemd 237-3ubuntu10.31
wireguard 0.0.20191012-wg1~bionic from PPA.

We're using systemd-networkd to configure wireguard via wireguard.netdev
and wireguard.network files in /etc/systemd/network/. All endpoints have
IPv4 addresses.

When we include 34, 35, or 36 [WireGuardPeer] entries in the netdev file
some peers are configured incorrectly. The affected peers seem to be
related to the total number of peers (counting from 0 here):

33 peers: No issue
34 peers: Peer 1 and 2 fail
35 peers: Peer 2 and 3 fail
36 peers: Peer 3 and 4 fail
37 peers: No issue

In all cases peer 0 is functional. For an affected pair of peers A and
B, peer A ends up with the allowed IP address range of peer B. Peer B
ends up with no allowed IP addresses. This can be seen in the output of
wg. The connections to both peers fail because of incorrect address
range assignments.

We first encountered this issue in a production environment when we
moved from 33 to 34 unique peers on each server. The issue was
reproduced on 3 different physical servers with similar configuration by
adding and removing peer 34.

The [WireGuardPeer] entries do not need to be unique to reproduce the
issue. In my testing I used 6 distinct peers and then used 28 or more
identical copies of a 7th peer. The results were the same.

In January 2019 a bug was reported that was also related to the number of 
wireguard peers, but the description seems sufficiently different from our case 
that I felt I should file a distinct bug report. Here's a link to that report 
in case I'm wrong about that:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811149

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


** Tags: networkd systemd-networkd wireguard

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

Title:
  34 wireguard peers result in invalid peer configuration

Status in systemd package in Ubuntu:
  New

Bug description:
  ubuntu server 18.04.3 LTS
  systemd 237-3ubuntu10.31
  wireguard 0.0.20191012-wg1~bionic from PPA.

  We're using systemd-networkd to configure wireguard via
  wireguard.netdev and wireguard.network files in /etc/systemd/network/.
  All endpoints have IPv4 addresses.

  When we include 34, 35, or 36 [WireGuardPeer] entries in the netdev
  file some peers are configured incorrectly. The affected peers seem to
  be related to the total number of peers (counting from 0 here):

  33 peers: No issue
  34 peers: Peer 1 and 2 fail
  35 peers: Peer 2 and 3 fail
  36 peers: Peer 3 and 4 fail
  37 peers: No issue

  In all cases peer 0 is functional. For an affected pair of peers A and
  B, peer A ends up with the allowed IP address range of peer B. Peer B
  ends up with no allowed IP addresses. This can be seen in the output
  of wg. The connections to both peers fail because of incorrect address
  range assignments.

  We first encountered this issue in a production environment when we
  moved from 33 to 34 unique peers on each server. The issue was
  reproduced on 3 different physical servers with similar configuration
  by adding and removing peer 34.

  The [WireGuardPeer] entries do not need to be unique to reproduce the
  issue. In my testing I used 6 distinct peers and then used 28 or more
  identical copies of a 7th peer. The results were the same.

  In January 2019 a bug was reported that was also related to the number of 
wireguard peers, but the description seems sufficiently different from our case 
that I felt I should file a distinct bug report. Here's a link to that report 
in case I'm wrong about that:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811149

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853956/+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 1814355] Re: snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression)

2019-11-25 Thread Mathew Hodson
** Changed in: snapd (Ubuntu Cosmic)
   Status: New => Won't Fix

** Changed in: initramfs-tools (Ubuntu Cosmic)
   Status: New => Won't Fix

** Changed in: systemd (Ubuntu Cosmic)
   Status: New => 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/1814355

Title:
  snapd remove /usr/local/bin from the PATH for all systemd unit (bionic
  SRU regression)

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in snapd source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in initramfs-tools source package in Cosmic:
  Won't Fix
Status in snapd source package in Cosmic:
  Won't Fix
Status in systemd source package in Cosmic:
  Won't Fix

Bug description:
  [Impact]

   * Initramfs exports PATH to init, which is different than the
  expected stock / compiled one, which results in slightly different
  runtime behaviour of init, if it has environment generators as well.

  [Test Case]

   * Disable snapd env generator & disable initrd-less boot (if enabled)
     sudo chmod -x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator
     set empty GRUB_FORCE_PARTUUID= and update-grub

   * Reboot cosmic system with an initramfs
     $ journalctl -b -k | grep initramfs
     (verify that initramfs was unpacked)

   * Check the path used by systemd, ie.:
     systemd-run /usr/bin/env
     journalctl -b -e | grep PATH

     It should contain /usr/local

   * Enable any env generator for example & reboot:
 /usr/lib/systemd/system-environment-generators/xnox.sh
 #!/bin/sh
 echo XNOX=ROCKS

   * Verify path used by systemd

     It should still contain /usr/local

  Repeat again with the new initramfs-tools.

  
  [Regression Potential]

   * We are hardcoding, the same path, yet again, in one more place. However, 
we are setting it to a well-known value (see https://wiki.ubuntu.com/PATH
   ) as it is universally expected and regressed when booted (a) with initrd 
AND (b) with broken path exported by initrd AND (c) with an env-generator.

  [Other Info]

   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  ===

  Big regression in 2.37.1+18.04 compare to version 2.34.2

  all these paths  /usr/local/sbin &  /usr/local/bin are not anymore in
  the path of all systemd process .

  So we can not start a daemon that use /usr/local/bin

  reinstalling package 2.34.2 fix the problem

  in 2.34.2 :

  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  in 2.37.1+18.04 :

  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/sbin:/usr/sbin:/bin:/usr/bin:/snap/bin

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1814355/+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 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

2019-11-25 Thread Mathew Hodson
** Changed in: snapd (Ubuntu Xenial)
   Status: Invalid => 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/1771858

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in snapd source package in Xenial:
  Won't Fix
Status in systemd source package in Xenial:
  Fix Released
Status in snapd source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Released
Status in snapd source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

   * When a generator started to be provided by systemd, it was
  recognized that $PATH is not correctly set, nonetheless, due to an
  environment bug that systemd generators run in.

  [Testcase]

  # make snapd-env-generator executable if it is not
  $ sudo chmod +x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator

  # reboot, then test the effect of the fix
  $ systemd-run /usr/bin/env
  $ journalctl -e | grep PATH

  Output should contain /snap/bin

  Output should contain a complete and a valid PATH, i.e.
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" 
or similar.

  [Regression Potential]

   * snapd generator was already fixed separately to cause no harm, when
  running under a broken systemd. With the corrected environment,
  generators will now run with a correct PATH out of the box. A slight
  change of PATH will be observed by all generators, when running in
  containers/initramfs-less boots. However most generators will not be
  affected as they typically do not execute external binaries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

2019-11-25 Thread Mathew Hodson
** No longer affects: python3-defaults (Ubuntu Eoan)

** No longer affects: python3-defaults (Ubuntu Disco)

** No longer affects: python3-defaults (Ubuntu Bionic)

** No longer affects: python3-defaults (Ubuntu)

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-stdlib-extensions source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Released

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-stdlib-extensions/+bug/1835738/+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 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

2019-11-25 Thread Dan Streetman
ubuntu@lp1796501-b:~$ cat /etc/systemd/network/10-ens3.network 
[Match]
Name=ens3

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6
DNS=8.8.8.8
DNSSEC=yes

[DHCP]
UseDNS=no


ubuntu@lp1796501-b:~$ systemd-resolve --status ens3
Link 2 (ens3)
  Current Scopes: DNS
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: yes
DNSSEC supported: yes
 DNS Servers: 8.8.8.8
  DNS Domain: vm

ubuntu@lp1796501-b:~$ dpkg -l systemd|grep ii
ii  systemd237-3ubuntu10.31 amd64system and service manager
ubuntu@lp1796501-b:~$ host test.asdf
Host test.asdf not found: 2(SERVFAIL)


ubuntu@lp1796501-b:~$ dpkg -l systemd|grep ii
ii  systemd237-3ubuntu10.33 amd64system and service manager
ubuntu@lp1796501-b:~$ host test.asdf
Host test.asdf not found: 3(NXDOMAIN)


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

** Tags removed: sts-sponsor-ddstreet

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

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [impact]

  an NXDOMAIN response from a dns server when systemd-resolved is
  configured as DNSSEC=yes breaks dns resolution as it downgrades from
  DNSSEC.

  [test case]

  see comment 9

  [regression potential]

  as with the original patch that introduced this problem, this has the
  potential to break dns resolution.

  [other info]

  original description:

  
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1724919] Re: Bluetooth headphones only use A2DP when connected manually

2019-11-25 Thread Yorick
Same problem here. bluez 5.50, pulseaudio 13.0. Sony WH-1000XM3.

Fiddling with the buttons on the headset makes it show up as a HCI
device, after which it can be switched to A2DP.

@Daniel van Vugt: could you reopen this and reassign it to either bluez
or pulseaudio? At the very last it has nothing to do with alsa. I spoke
with the pulseaudio maintainer, who thinks it's likely a bluez issue.

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

Title:
  Bluetooth headphones only use A2DP when connected manually

Status in alsa-driver package in Ubuntu:
  Won't Fix

Bug description:
  Issue with Sony MDR-1ABT Bluetooth headphones:
  Once paired, the headphones will be connected automatically whenever they are 
switched on. However when connected this way, only the HSP/HFP profile will 
work and trying to change to A2DP in sound settings does nothing.
  If the headphones are then manually disconnected and reconnected from 
Bluetooth settings, they will initially use HSP/HFP but then selecting A2DP in 
sound settings will successfully make them use A2DP.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  neil   1443 F pulseaudio
   /dev/snd/pcmC0D0c:   neil   1443 F...m pulseaudio
   /dev/snd/controlC0:  neil   1443 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 19 19:12:59 2017
  InstallationDate: Installed on 2017-10-19 (0 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: MDR-1ABT
  Symptom_Type: None of the above
  Title: [MDR-1ABT, playback] Playback problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/06/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F5
  dmi.board.asset.tag: Default string
  dmi.board.name: Z270N-WIFI-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF5:bd07/06/2017:svnGigabyteTechnologyCo.,Ltd.:pnZ270N-WIFI:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnZ270N-WIFI-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: Z270N-WIFI
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1724919/+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 1852754] Re: networkd does not complete interface configuration if Link MTUBytes is set

2019-11-25 Thread Dan Streetman
ubuntu@lp1850704-b:~$ cat /etc/systemd/network/10-ens3.network 
[Match]
Name=ens3

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6

[Link]
MTUBytes=

ubuntu@lp1850704-b:~$ dpkg -l systemd|grep ii
ii  systemd237-3ubuntu10.33 amd64system and service manager
ubuntu@lp1850704-b:~$ sudo systemctl restart systemd-networkd
ubuntu@lp1850704-b:~$ ip a show dev ens3
2: ens3:  mtu  qdisc fq_codel state UP 
group default qlen 1000
link/ether 52:54:00:86:c7:44 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.197/24 brd 192.168.122.255 scope global dynamic ens3
   valid_lft 3596sec preferred_lft 3596sec
inet6 fe80::5054:ff:fe86:c744/64 scope link 
   valid_lft forever preferred_lft forever

ubuntu@lp1850704-b:~$ networkctl | grep ens3
  2 ens3 ether  routableconfigured


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

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

Title:
  networkd does not complete interface configuration if Link MTUBytes is
  set

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [impact]

  interfaces configured with .network file [Link] section specifying
  MTUBytes will not be successfully brought up.

  [test case]

  configure interface e.g.

  Name=ens3

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6

  [Link]
  MTUBytes=1550

  start/restart networkd, the interface will never reach 'routable'
  stage and will not get an IPv4 address.

  [regression potential]

  any regressions would likely occur during networkd
  configuration/startup/restart, and would likely cause failure to
  successfully setup the interface.

  [other info]

  this is a regression-proposed caused by incomplete backport for bug
  1850704

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1852754/+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 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial

2019-11-25 Thread Dan Streetman
root@lp1805183-b:~# dpkg -l systemd|grep ii
ii  systemd237-3ubuntu10.33 amd64system and service manager
root@lp1805183-b:~# journalctl -b -u systemd-resolved | grep Started
Nov 26 03:04:30 lp1805183-b systemd[1]: Started Network Name Resolution.
root@lp1805183-b:~# dhclient ens8
cmp: EOF on /tmp/tmp.yJwQabpfMe which is empty
root@lp1805183-b:~# sleep 300 ; journalctl -b -u systemd-resolved | grep Started
Nov 26 03:04:30 lp1805183-b systemd[1]: Started Network Name Resolution.
Nov 26 03:06:06 lp1805183-b systemd[1]: Started Network Name Resolution.


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

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

Title:
  systemd-resolved constantly restarts on Bionic upgraded from Xenial

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  Log noise due to needless restart of resolved on lease expiry, maybe loss of 
cached state?
  Application that require Name Resolution may fail while the service is being 
unnecessarily restarted

  [Test case]
  (1) Append make_resolv_conf to the end of the file, so it gets executed
  (2) Execute the file with bash -x and different settings and ensure there are 
no restarts if the settings are the same, and that there are if settings 
change; for example:

  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => no restart
  sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => should restart
  sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => no restart
  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => should restart

  [Regression potential]
  The change only restarts resolved when the settings change. If there's a bug 
in the logic, resolved might not be restarted when it should be. Also, since 
there will be less restarts of resolved, it will run longer, so if there are 
memory leaks they will become more apparent.

  [other info]

  this fix was included in the initial release of systemd for eoan, but
  the fix required the additional change in bug 1849608.  Both the
  original patch plus that change (to avoid using bash-specific &>) are
  included in the b/d patch for this bug.

  [Original bug report]
  If a cloud server is upgraded from Xenial to Bionic, the dhclient system 
remains in place and any DHCP lease refreshes cause a needless restart of the 
system-resolved daemon

  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on 
ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d)
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 
10.226.209.105
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors:
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 
49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 
10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 
'srv-qvjhx'.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting 
resolvconf-pull-resolved.service...
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal 
in 1466 seconds.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Started 
resolvconf-pull-resolved.service.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ubuntu-release-upgrader-core 1:16.04.25
  ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160
  Uname: Linux 4.4.0-139-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CrashDB: ubuntu
  Date: Mon Nov 26 16:17:52 2018
  PackageArchitecture: all
  SourcePackage: 

[Touch-packages] [Bug 1850704] Re: networkd doesn't set MTUBytes if interface is already up

2019-11-25 Thread Dan Streetman
ubuntu@lp1850704-b:~$ cat /etc/systemd/network/10-ens3.network 
[Match]
Name=ens3

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6

[Link]
MTUBytes=

ubuntu@lp1850704-b:~$ dpkg -l systemd|grep ii
ii  systemd237-3ubuntu10.33 amd64system and service manager
ubuntu@lp1850704-b:~$ ip l show ens3
2: ens3:  mtu  qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:86:c7:44 brd ff:ff:ff:ff:ff:ff
ubuntu@lp1850704-b:~$ sudo ip l set mtu 1500 dev ens3
ubuntu@lp1850704-b:~$ ip l show ens3
2: ens3:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:86:c7:44 brd ff:ff:ff:ff:ff:ff
ubuntu@lp1850704-b:~$ sudo systemctl restart systemd-networkd
ubuntu@lp1850704-b:~$ ip l show ens3
2: ens3:  mtu  qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:86:c7:44 brd ff:ff:ff:ff:ff:ff


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

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

Title:
  networkd doesn't set MTUBytes if interface is already up

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [impact]

  if a networkd .network file specifies a [Link] section with
  MTUBytes=XXX set, networkd will only apply that mtu if the interface
  is down when networkd starts; if the interface is already up, the mtu
  won't be applied.

  [test case]

  on a bionic system, create a .network file like:

  [Match]
  Name=ens8

  [Link]
  MTUBytes=

  then, reboot.  The interface should be set correctly with that mtu:

  $ ip l show ens8
  3: ens8:  mtu  qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
  link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff

  
  now, manually change the interface back to 1500 mtu, and restart networkd, 
then recheck the mtu:

  $ ip l show ens8
  3: ens8:  mtu  qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
  link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff
  $ sudo ip l set mtu 1500 dev ens8
  $ ip l show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
  link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff
  $ sudo systemctl restart systemd-networkd
  $ ip l show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
  link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff

  [regression potential]

  low, but any regression would likely involve failure to correctly set
  the configured mtu.

  this is needed only in bionic, it's fixed in disco and later already.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1850704/+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 1853935] [NEW] systemd-mount doesn't support lazyunmount / forceunmount

2019-11-25 Thread Dimitri John Ledkov
Public bug reported:

systemd-mount doesn't support lazyunmount / forceunmount

yet it should

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


** Tags: core20

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

Title:
  systemd-mount doesn't support lazyunmount / forceunmount

Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-mount doesn't support lazyunmount / forceunmount

  yet it should

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853935/+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 869017] Re: Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)

2019-11-25 Thread Doug Smythies
Ever since the default changed to never blanking the screen, and after I
whined in comment #18 above, I have been running this in
/etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT=" consoleblank=300 "

always save a copy of grub first, and do "sudo update-grub afterwards",
then re-boot.

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

Title:
  Ubuntu server enables screenblanking, concealing crashdumps (DPMS is
  not used)

Status in kbd package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in kbd source package in Zesty:
  Invalid
Status in linux source package in Zesty:
  Fix Released
Status in kbd package in Debian:
  Fix Released

Bug description:
  James Rice of Jump Networks noticed that there is a screen-blanker
  enabled on Ubuntu Server.

  James notes that this blanking is not enabling DPMS power saving
  (thereby negating any power-saving benefit), and is simply turning the
  screen content blank.   This means that the crash output is invisible
  which is unhelpful on a server (virtual or otherwise).

  Ideally the screen should (at a minimum) be turned on and unblanked at
  the point of an OOPs/crash being printed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017/+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 1781428] Re: please enable snap mediation support

2019-11-25 Thread Jamie Strandboge
Installing 1:8.0-0ubuntu3.11 from xenial-proposed, the test plan and
James' addition for mediation is preserved across snapd restart all
works as expected. Marking as verification done.

** Description changed:

  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.
  
  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all connected
  clients (snaps or not), record by classic snaps (see bug 1787324) and
  record by strict mode snaps if either the pulseaudio or new-in-
  snapd-2.41 audio-record interfaces were connected. With this change,
  snapd is in a position to migrate snaps to the new audio-playback and
  audio-record interfaces and properly mediate audio recording (see
  https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-
  deprecation/13418).
  
  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not, whether
  the pulseaudio or audio-record interfaces are connected. Adjusting
  pulseaudio in the manner does not require coordination with any release
  of snapd. It does need a newer version of snapd-glib, which was recently
  updated to 1.49 in the last SRU.
  
  [Test Case]
  
  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy
  
  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes
  
  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes
  
  $ paplay /tmp/out.wav && echo "yes"
  yes
  
  For confined, non-snap applications:
  $ sudo apt-get install evince
  
  $ aa-exec -p /usr/bin/evince -- paplay /usr/share/sounds/alsa/Noise.wav
  && echo yes
  
  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes
  
  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes
  
  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic
  
  $ snap run --shell test-snapd-classic-confinement
  
  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)
  
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes
  
  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes
  
  $ paplay /tmp/out.wav && echo "yes"
  yes
+ 
+ $ exit # out of snap run --shell
  
  For strict snaps with pulseaudio:
  $ sudo snap install test-snapd-pulseaudio --edge
  
  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -
  
  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...
  
  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/
  
  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes
  
  (note, the xcb_connection_has_error() message is due to the x11
  interface not being connecting which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)
  
  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes # should pass
  ...
  ^Cyes
  
  $ test-snapd-pulseaudio.play /tmp/out.wav && echo yes
  ...
  yes
  
  For strict snaps with audio-playback/audio-record:
  $ sudo snap refresh core --candidate # make sure have 2.41. 'install' on 16.04
  $ sudo snap install test-snapd-audio-record --edge
  
  $ snap connections test-snapd-audio-record  # record not connected
  Interface   PlugSlot Notes
  audio-playback  test-snapd-audio-record:audio-playback  :audio-playback  -
  audio-recordtest-snapd-audio-record:audio-record--
  
  $ test-snapd-audio-record.play --help  # ensure SNAP dirs are created
  ...
  
  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-audio-
  record/common/
  
  $ 

[Touch-packages] [Bug 1781428] Re: please enable snap mediation support

2019-11-25 Thread Jamie Strandboge
Installing 1:11.1-1ubuntu7.5 from bionic-proposed, the test plan and
James' addition for mediation is preserved across snapd restart all
works as expected. Marking as verification done.

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

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

Title:
  please enable snap mediation support

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Fix Committed
Status in pulseaudio source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.

  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all
  connected clients (snaps or not), record by classic snaps (see bug
  1787324) and record by strict mode snaps if either the pulseaudio or
  new-in-snapd-2.41 audio-record interfaces were connected. With this
  change, snapd is in a position to migrate snaps to the new audio-
  playback and audio-record interfaces and properly mediate audio
  recording (see https://forum.snapcraft.io/t/upcoming-pulseaudio-
  interface-deprecation/13418).

  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not,
  whether the pulseaudio or audio-record interfaces are connected.
  Adjusting pulseaudio in the manner does not require coordination with
  any release of snapd. It does need a newer version of snapd-glib,
  which was recently updated to 1.49 in the last SRU.

  [Test Case]

  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy

  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For confined, non-snap applications:
  $ sudo apt-get install evince

  $ aa-exec -p /usr/bin/evince -- paplay
  /usr/share/sounds/alsa/Noise.wav && echo yes

  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes

  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes

  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic

  $ snap run --shell test-snapd-classic-confinement

  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)

  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  $ exit # out of snap run --shell

  For strict snaps with pulseaudio:
  $ sudo snap install test-snapd-pulseaudio --edge

  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -

  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...

  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/

  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes

  (note, the xcb_connection_has_error() message is due to the x11
  interface not being connecting which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)

  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes # should pass
  ...
  ^Cyes

  $ test-snapd-pulseaudio.play /tmp/out.wav && echo yes
  ...
  yes

  For strict snaps with audio-playback/audio-record:
  $ sudo snap refresh core --candidate # make sure have 2.41. 'install' on 16.04
  $ sudo snap install test-snapd-audio-record --edge

  $ snap connections test-snapd-audio-record  # record not connected
  

[Touch-packages] [Bug 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

2019-11-25 Thread Steve Langasek
For Ubuntu 20.04, resolvconf will not be allowed to manage
/etc/resolv.conf, this will always be managed via systemd-resolved.  So
while you're right that this is a bug in the hook, it will not be a
priority to fix since the code will be rewritten and replaced.

> Alongside this, systemd's often-buggy resolver can be disabled.

The vast majority of Ubuntu users are using systemd-resolved without
incident or complaint.  If you know of specific problems with it, we can
best help you (and all other Ubuntu users) if you give us bug reports
for those problems.

** Tags removed: rls-ff-incoming
** Tags added: rls-ff-notfixing

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

Title:
  systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

Status in systemd package in Ubuntu:
  Triaged
Status in systemd source package in Focal:
  Triaged

Bug description:
  The functionality exists to allow users to revert to the traditional ifupdown 
  package for network configuration. Alongside this, systemd's often-buggy 
  resolver can be disabled. However, there's a logic error in the systemd-
  supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
  from populating /etc/resolv.conf properly when systemd-resolved is disabled. 
  The issue is here:

  if [ -x /lib/systemd/systemd-resolved ] ; then

  Instead of checking to see if the systemd-resolved service is enabled or 
  active, which would be the correct behaviour, this checks for the existence of
  a binary, assuming that if it exists it's supposed to be used.

  I've not tested this in the absence of resolvconf, but if systemd-resolved 
  isn't enabled, it's difficult to imagine this code wanting to run. I've 
tested 
  this with resolvconf and ifupdown driving dhclient, and it corrects the 
  behaviour that was broken with the introduction of systemd-resolved.

  I'm attaching a patch, and am also including it here for easy access:

  *** resolved.broken 2019-11-19 15:01:28.785588838 +
  --- resolved2019-11-19 15:08:06.519430073 +
  ***
  *** 14,20 
#   (D) = master script downs interface
#   (-) = master script does nothing with this

  ! if [ -x /lib/systemd/systemd-resolved ] ; then
# For safety, first undefine the nasty default make_resolv_conf()
make_resolv_conf() { : ; }
case "$reason" in
  --- 14,21 
#   (D) = master script downs interface
#   (-) = master script does nothing with this

  ! systemctl is-active systemd-resolved > /dev/null 2>&1
  ! if [ $? -eq 0 ]; then
# For safety, first undefine the nasty default make_resolv_conf()
make_resolv_conf() { : ; }
case "$reason" in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+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 1781428] Re: please enable snap mediation support

2019-11-25 Thread Jamie Strandboge
** Description changed:

  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.
  
  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all connected
  clients (snaps or not), record by classic snaps (see bug 1787324) and
  record by strict mode snaps if either the pulseaudio or new-in-
  snapd-2.41 audio-record interfaces were connected. With this change,
  snapd is in a position to migrate snaps to the new audio-playback and
  audio-record interfaces and properly mediate audio recording (see
  https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-
  deprecation/13418).
  
  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not, whether
  the pulseaudio or audio-record interfaces are connected. Adjusting
  pulseaudio in the manner does not require coordination with any release
  of snapd. It does need a newer version of snapd-glib, which was recently
  updated to 1.49 in the last SRU.
  
  [Test Case]
  
  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy
  
  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes
  
  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes
  
  $ paplay /tmp/out.wav && echo "yes"
  yes
  
  For confined, non-snap applications:
  $ sudo apt-get install evince
  
  $ aa-exec -p /usr/bin/evince -- paplay /usr/share/sounds/alsa/Noise.wav
  && echo yes
  
  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes
  
  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes
  
  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic
  
  $ snap run --shell test-snapd-classic-confinement
  
  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)
  
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes
  
  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes
  
  $ paplay /tmp/out.wav && echo "yes"
  yes
  
  For strict snaps with pulseaudio:
- $ sudo snap install --dangerous ./test-snapd-pulseaudio_1_amd64.snap
+ $ sudo snap install test-snapd-pulseaudio --edge
  
  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -
  
  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...
  
  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/
  
  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes
  
  (note, the xcb_connection_has_error() message is due to the x11
  interface not being connecting which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)
  
  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes # should pass
  ...
  ^Cyes
  
  $ test-snapd-pulseaudio.play /tmp/out.wav && echo yes
  ...
  yes
  
  For strict snaps with audio-playback/audio-record:
  $ sudo snap refresh core --candidate # make sure have 2.41. 'install' on 16.04
- $ sudo snap install --dangerous ./test-snapd-audio-record_1_amd64.snap
+ $ sudo snap install test-snapd-audio-record --edge
  
  $ snap connections test-snapd-audio-record  # record not connected
  Interface   PlugSlot Notes
  audio-playback  test-snapd-audio-record:audio-playback  :audio-playback  -
  audio-recordtest-snapd-audio-record:audio-record--
  
  $ test-snapd-audio-record.play --help  # ensure SNAP dirs are created
  ...
  
  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-audio-
  record/common/
  
  $ test-snapd-audio-record.play 
/var/snap/test-snapd-audio-record/common/Noise.wav && echo yes
  

[Touch-packages] [Bug 1853762] Re: Headphones stop working until pairing again

2019-11-25 Thread Guillaume Michaud
** Attachment added: "user-1000.journal"
   
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1853762/+attachment/5307828/+files/user-1000.journal

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

Title:
  Headphones stop working until pairing again

Status in bluez package in Ubuntu:
  New

Bug description:
  I'm using Marshall MID ANC headphones with Ubuntu 19.10.
  Every now and then, I won't be able to use them without re-pairing first 
(like today - see logs).
  After re-pairing, everything works again for a while : I can switch off and 
on the headphones, reboot... Until it breaks again.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Nov 24 19:13:40 2019
  InstallationDate: Installed on 2018-07-28 (483 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  InterestingModules: rfcomm bnep btusb bluetooth
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 8087:0a2b Intel Corp. 
   Bus 001 Device 002: ID 0bda:58d2 Realtek Semiconductor Corp. USB2.0 HD UVC 
WebCam
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: ASUSTeK COMPUTER INC. UX410UAK
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-23-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: bluez
  UpgradeStatus: Upgraded to eoan on 2019-10-18 (37 days ago)
  dmi.bios.date: 11/08/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX410UAK.308
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX410UAK
  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.:bvrUX410UAK.308:bd11/08/2017:svnASUSTeKCOMPUTERINC.:pnUX410UAK:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX410UAK:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: UX
  dmi.product.name: UX410UAK
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.
  hciconfig:
   hci0:Type: Primary  Bus: USB
BD Address: 14:AB:C5:7E:41:26  ACL MTU: 1021:4  SCO MTU: 96:6
UP RUNNING 
RX bytes:319948 acl:71 sco:0 events:45583 errors:0
TX bytes:37324973 acl:43061 sco:0 commands:2478 errors:0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1853762/+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 1853762] Re: Headphones stop working until pairing again

2019-11-25 Thread Guillaume Michaud
** Attachment added: "system.journal"
   
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1853762/+attachment/5307827/+files/system.journal

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

Title:
  Headphones stop working until pairing again

Status in bluez package in Ubuntu:
  New

Bug description:
  I'm using Marshall MID ANC headphones with Ubuntu 19.10.
  Every now and then, I won't be able to use them without re-pairing first 
(like today - see logs).
  After re-pairing, everything works again for a while : I can switch off and 
on the headphones, reboot... Until it breaks again.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Nov 24 19:13:40 2019
  InstallationDate: Installed on 2018-07-28 (483 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  InterestingModules: rfcomm bnep btusb bluetooth
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 8087:0a2b Intel Corp. 
   Bus 001 Device 002: ID 0bda:58d2 Realtek Semiconductor Corp. USB2.0 HD UVC 
WebCam
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: ASUSTeK COMPUTER INC. UX410UAK
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-23-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: bluez
  UpgradeStatus: Upgraded to eoan on 2019-10-18 (37 days ago)
  dmi.bios.date: 11/08/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX410UAK.308
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX410UAK
  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.:bvrUX410UAK.308:bd11/08/2017:svnASUSTeKCOMPUTERINC.:pnUX410UAK:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX410UAK:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: UX
  dmi.product.name: UX410UAK
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.
  hciconfig:
   hci0:Type: Primary  Bus: USB
BD Address: 14:AB:C5:7E:41:26  ACL MTU: 1021:4  SCO MTU: 96:6
UP RUNNING 
RX bytes:319948 acl:71 sco:0 events:45583 errors:0
TX bytes:37324973 acl:43061 sco:0 commands:2478 errors:0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1853762/+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 1853762] Re: Headphones stop working until pairing again

2019-11-25 Thread Guillaume Michaud
I'm adding system.journal and user-1000.journal to this bug report.
Today (November 25th) at :
- 20:47 : I switched the headphones on... which didn't connect
- 20:48 : I tried to connect manually using UI (but the switch/toggle 
immediately came back to "off")
- 20:49-50 : I used bluetoothctl, which worked
- 20:51 : I used bluetootctl to disconnect the headphones, and tried to connect 
them back with UI (which didn't work)

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

Title:
  Headphones stop working until pairing again

Status in bluez package in Ubuntu:
  New

Bug description:
  I'm using Marshall MID ANC headphones with Ubuntu 19.10.
  Every now and then, I won't be able to use them without re-pairing first 
(like today - see logs).
  After re-pairing, everything works again for a while : I can switch off and 
on the headphones, reboot... Until it breaks again.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Nov 24 19:13:40 2019
  InstallationDate: Installed on 2018-07-28 (483 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  InterestingModules: rfcomm bnep btusb bluetooth
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 8087:0a2b Intel Corp. 
   Bus 001 Device 002: ID 0bda:58d2 Realtek Semiconductor Corp. USB2.0 HD UVC 
WebCam
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: ASUSTeK COMPUTER INC. UX410UAK
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-23-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: bluez
  UpgradeStatus: Upgraded to eoan on 2019-10-18 (37 days ago)
  dmi.bios.date: 11/08/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX410UAK.308
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX410UAK
  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.:bvrUX410UAK.308:bd11/08/2017:svnASUSTeKCOMPUTERINC.:pnUX410UAK:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX410UAK:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: UX
  dmi.product.name: UX410UAK
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.
  hciconfig:
   hci0:Type: Primary  Bus: USB
BD Address: 14:AB:C5:7E:41:26  ACL MTU: 1021:4  SCO MTU: 96:6
UP RUNNING 
RX bytes:319948 acl:71 sco:0 events:45583 errors:0
TX bytes:37324973 acl:43061 sco:0 commands:2478 errors:0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1853762/+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 1676547] Re: No network connectivity (NIC unmanaged) after upgrade

2019-11-25 Thread Doug B
Ubuntu Server 18.04.3 fresh install.
Ethernet Unmanaged in Network Manager.
SOLVED. FIXED, etc. 
-
I created file /etc/netplan/01-network-manager-all.yaml

Within I entered:
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
--
I edited /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Within I ensured it only say:

network: {config: disabled}
---
I edit /etc/netplan/01-network-manager-all.yaml (If you don't nave then create)
within it I entered:
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

rebooted
-

Wooho, It works!
Thanks

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

Title:
  No network connectivity (NIC unmanaged) after upgrade

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Yakkety:
  Fix Released
Status in network-manager source package in Zesty:
  Fix Released

Bug description:
  Impact
  --
  When upgrading from Xenial (with all updates installed) to Yakkety/Zesty you 
will boot to a system without networking - sad!

  Test Case
  -
  1) Boot a xenial desktop system
  2) Ensure network-manager version 1.2.6-0ubuntu0.16.04.1 from -updates is 
installed
  3) Upgrade to yakkety or zesty
  3.5) Enable -proposed and download the new version of n-m "apt-get download 
network-manager"
  4) Reboot
  5) Observe you have no network

  If you install the version of network-manager from yakkety-proposed
  and then reboot you should have a network connection.

  1) Boot a xenial desktop system.
  2) ensure network-manager version 1.2.6-0ubuntu0.16.04.1 from -updates is 
installed.
  3) Install nplan, configure to set up static network on an ethernet device 
using nplan.
  4) Upgrade to yakkety or zesty
  5) Reboot
  6) Observe that your system is still being managed by networkd rather than 
NetworkManager.

  Regression Potential
  

  Any failure to manage ethernet or wireless devices after upgrade, or
  issues with the use of netplan in conjunction with NetworkManager
  should be investigated as potential regressions. For example, if after
  upgrading, ethernet devices are no longer managed, or if devices that
  should be explicitly ignored by NetworkManager due to existing user
  configuration are now managed, these would indicate a possible
  regression caused by this update.

  Original Description
  

  nplan was installed during the upgrade process but I had no network
  connectivity after upgrading. Apparently, no package wanted to manage
  my ethernet connection.

  ProblemType: BugDistroRelease: Ubuntu 16.10
  Package: ubuntu-release-upgrader-core 1:16.10.10
  ProcVersionSignature: Ubuntu 4.8.0-41.44-generic 4.8.17
  Uname: Linux 4.8.0-41-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.3-0ubuntu8.2
  Architecture: amd64
  CrashDB: ubuntu
  CurrentDesktop: Unity
  Date: Mon Mar 27 11:34:04 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2013-01-16 (1531 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130116)
  PackageArchitecture: allSourcePackage: ubuntu-release-upgrader
  Symptom: ubuntu-release-upgrader
  UpgradeStatus: Upgraded to yakkety on 2017-03-17 (10 days ago)
  VarLogDistupgradeTermlog:

  modified.conffile..etc.update-manager.meta-release: [modified]
  mtime.conffile..etc.update-manager.meta-release: 2013-10-08T06:39:09.818913

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1676547/+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 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package mesa - 19.2.4-1ubuntu1

---
mesa (19.2.4-1ubuntu1) focal; urgency=medium

  * Merge from Debian.
  * revert-set-full-thread-affinity.diff: Dropped, qemu is fixed now in
eoan and up. (LP: #1815889)

 -- Timo Aaltonen   Wed, 20 Nov 2019 20:17:00 +0200

** Changed in: mesa (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  qemu-system-x86_64 crashed with signal 31 in
  __pthread_setaffinity_new()

Status in Mesa:
  Won't Fix
Status in QEMU:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Invalid
Status in mesa source package in Disco:
  Fix Released
Status in mesa source package in Eoan:
  Won't Fix
Status in qemu source package in Eoan:
  Fix Released

Bug description:
  Unable to launch Default Fedora 29 images in gnome-boxes

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
  Uname: Linux 4.19.0-12-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  Date: Thu Feb 14 11:00:45 2019
  ExecutablePath: /usr/bin/qemu-system-x86_64
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: Dell Inc. Precision T3610
  ProcEnviron: PATH=(custom, user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic 
root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1
  Signal: 31
  SourcePackage: qemu
  StacktraceTop:
   __pthread_setaffinity_new (th=, cpusetsize=128, 
cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   start_thread (arg=) at pthread_create.c:486
   clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  Title: qemu-system-x86_64 crashed with signal 31 in 
__pthread_setaffinity_new()
  UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video
  dmi.bios.date: 11/14/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A18
  dmi.board.name: 09M8Y8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr:
  dmi.product.name: Precision T3610
  dmi.product.sku: 05D2
  dmi.product.version: 00
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815889/+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 1853894] [NEW] Strange Hang with old SWT Apps

2019-11-25 Thread eitch
Public bug reported:

I have a weird issue where an old app of mine which is written in
Eclipse RCP using SWT. It is an older Eclipse 3.x version.

I am running uptodate Ubuntu 19.10, on Ubuntu 18.4 LTS everything works
fine.

When i start the app after compiling it using the latest Eclipse
edition, then when i start the app, first i needed to install
libgtk2.0-0. Which i found out using ldd.

The app then doesn't start for quite a while. I can't see any errors
ore warnings anywhere. Maybe someone can point me in the right area?

Anyhow, searching the web i did find a solution: Either i start the
app as root, or using the following command:

dbus-launch --exit-with-session java -jar MyApp.jar

But both are not very helpful as i can't start the app like this from
Eclipse to allow for debugging and modifying. And starting as root
isn't optimal either.

Has anyone got any idea on how i can fix this, or is this perhaps some
kind of bug?

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: libgtk2.0-0 2.24.32-4ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
Uname: Linux 5.3.0-23-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Nov 25 20:34:58 2019
InstallationDate: Installed on 2019-11-25 (0 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
SourcePackage: gtk+2.0
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gtk+2.0 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug eoan

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

Title:
  Strange Hang with old SWT Apps

Status in gtk+2.0 package in Ubuntu:
  New

Bug description:
  I have a weird issue where an old app of mine which is written in
  Eclipse RCP using SWT. It is an older Eclipse 3.x version.

  I am running uptodate Ubuntu 19.10, on Ubuntu 18.4 LTS everything
  works fine.

  When i start the app after compiling it using the latest Eclipse
  edition, then when i start the app, first i needed to install
  libgtk2.0-0. Which i found out using ldd.

  The app then doesn't start for quite a while. I can't see any errors
  ore warnings anywhere. Maybe someone can point me in the right area?

  Anyhow, searching the web i did find a solution: Either i start the
  app as root, or using the following command:

  dbus-launch --exit-with-session java -jar MyApp.jar

  But both are not very helpful as i can't start the app like this from
  Eclipse to allow for debugging and modifying. And starting as root
  isn't optimal either.

  Has anyone got any idea on how i can fix this, or is this perhaps some
  kind of bug?

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: libgtk2.0-0 2.24.32-4ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Nov 25 20:34:58 2019
  InstallationDate: Installed on 2019-11-25 (0 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: gtk+2.0
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1853894/+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 1853895] [NEW] Entries in sudoers files that include * do not behave like shell globs

2019-11-25 Thread ed
Public bug reported:

When mistakenly used in the argument list it can expand to protected
content, such as /etc/shadow. Most users do not expect this.

The following example will permit 'username' to read /etc/shadow as the
* character accepts any character and spaces.

  username ALL=(ALL) /bin/cat /var/log/messages*

The patch adds the following style of argument matching that can
restrict the sudoers arguments to regex, thus allowing for additional
common logrotate suffixes.

  username ALL = (ALL) /bin/cat m{/var/log/messages(\.[0-9]+|-[0-9]+)?$}

This improves the security stance of sudoers entries through tight regex
matches which most administrators are familiar with.

Changes are in , viewable as


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

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

Title:
  Entries in sudoers files that include * do not behave like shell globs

Status in sudo package in Ubuntu:
  New

Bug description:
  When mistakenly used in the argument list it can expand to protected
  content, such as /etc/shadow. Most users do not expect this.

  The following example will permit 'username' to read /etc/shadow as
  the * character accepts any character and spaces.

username ALL=(ALL) /bin/cat /var/log/messages*

  The patch adds the following style of argument matching that can
  restrict the sudoers arguments to regex, thus allowing for additional
  common logrotate suffixes.

username ALL = (ALL) /bin/cat
  m{/var/log/messages(\.[0-9]+|-[0-9]+)?$}

  This improves the security stance of sudoers entries through tight
  regex matches which most administrators are familiar with.

  Changes are in , viewable as
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1853895/+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 1638842] Re: network-manager does not manage ethernet and bluetooth interfaces when Ubuntu 16.10 is installed using chroot/netboot method

2019-11-25 Thread Doug B
*** This bug is a duplicate of bug 1676547 ***
https://bugs.launchpad.net/bugs/1676547

I tried all these suggestion, no joy.
Why won't dev fix? Please  at least tell us what we're doing wrong. I may have 
to install Desktop version because KVM/QEMU isn't playing nice with seeing the 
network connection. Now  what, reinstall every server manually that I use on my 
hosts so those KVMs work. I was hoping to avoid using VBox.

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

Title:
  network-manager does not manage ethernet and bluetooth interfaces when
  Ubuntu 16.10 is installed using chroot/netboot method

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

Bug description:
  Hello,

  I installed Ubuntu 16.10 using a chroot. I use network-manager to
  manage connections. My system is up-to-date (so I use network-manager
  1.2.4-0ubuntu1).

  Wifi works perfectly but I cannot connect to wired networks and using
  my phone's Bluetooth connection. Corresponding devices are said to be
  unmanaged by network-manager. nmcli dev outputs:

  DEVICETYPE  STATE CONNECTION 
  enp1s0ethernet  unmanaged -- 
  wlp2s0wifi  disconnected  --
  6C:9B:02:2C:EE:2C btunmanaged -- 
  hfp/org/bluez/hci0/dev_6C_9B_02_2C_EE_2C  gsm   unmanaged -- 
  loloopback  unmanaged -- 

  The following command has no effect:
  sudo nmcli dev set enp1s0 managed yes

  I can connect to a wired connection by doing:
  ifconfig enp1s0 up
  dhclient enp1s0

  There is nothing in the file /etc/network/interfaces.

  Everything works perfectly if I downgrade network-manager to this
  version: network-manager_1.2.2-0ubuntu0.16.04.3_amd64.deb
  (http://packages.ubuntu.com/xenial-updates/amd64/network-
  manager/download). I had to install libreadline6 and downgrade nplan
  to meet dependencies.

  I don't know what to join to this bug report so please ask in case
  anything is needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638842/+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 1853879] Re: Dell E310dw: Default driver doesn't work, driverless fails on sides=two-sided-long-edge

2019-11-25 Thread Akkana Peck
Just verified that 2-sided portrait (long edge) printing does indeed
work on this printer in 19.04, so this is a regression. I'm not sure
which of the three drivers it's using. Let me know if you want me to
attach any files from 19.04.

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

Title:
  Dell E310dw: Default driver doesn't work, driverless fails on sides
  =two-sided-long-edge

Status in cups package in Ubuntu:
  New

Bug description:
  Dell E310dw printer which worked well on 19.04 has problems in 19.10:

  First, I went through the CUPS web interface to add the printer. The
  interface gave me a choice of two entries with the same name plus one
  with "driverless" added. I chose the first entry (not driverless) and
  completed adding the printer. On the Printers page, the Dell was now
  listed. When I tried "Print Test Page", I got many pages each
  containing a single line of symbols.

  I deleted the printer in the web interface, intending to start again and 
choose the second option. But after I did Delete Printer, CUPS took me back to 
the Printers page which now listed:
  Dell_Printer_E310dw@DELL316BAA.local  Dell Printer E310dw, 
driverless, cups-filters 1.25.11

  So I clicked on that printer and tried Print Test Page, which worked.
  So then I tried a duplex print (which is really what I need this
  morning):

   lp -o sides=two-sided-long-edge -o collate=true -d
  Dell_Printer_E310dw@DELL316BAA.local filename.pdf

  It printed the PDF 2-sided, but with the sides flipped around the
  short edge, as if it was a landscape print. I tried the same command
  with sides=two-sided-short-edge and it flipped the same way. So sides
  is handling duplex but ignoring which edge is supposed to be used, and
  defaulting to landscape which I'd guess is less commonly what people
  want.

  This is all using what's built into Ubuntu. I haven't yet downloaded
  any extra drivers from Dell's site since Ubuntu claims to have a
  driver for the printer, and I'm pretty sure it was working in 19.04 (I
  may still have a working 19.04 to check that, if it would help).

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: cups 2.2.12-2ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  Date: Mon Nov 25 09:58:21 2019
  InstallationDate: Installed on 2019-10-10 (45 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20190926.1)
  Lpstat:
   device for Brother_HL-3170CDW_series: 
dnssd://Brother%20HL-3170CDW%20series._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-3c2af4251dee
   device for Dell_Printer_E310dw@DELL316BAA.local: 
implicitclass://Dell_Printer_E310dw%40DELL316BAA.local/
  MachineType: LENOVO 20QDCTO1WW
  Papersize: letter
  PpdFiles:
   Error: command ['fgrep', '-H', '*NickName', 
'/etc/cups/ppd/dell_printer_e31...@dell316baa.local.ppd', 
'/etc/cups/ppd/Brother_HL-3170CDW_series.ppd'] failed with exit code 2: grep: 
/etc/cups/ppd/dell_printer_e31...@dell316baa.local.ppd: Permission denied
   grep: /etc/cups/ppd/Brother_HL-3170CDW_series.ppd: Permission denied
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-23-generic 
root=UUID=a5868be6-8495-47af-a190-9af5fdc9b419 ro
  SourcePackage: cups
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/04/2019
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N2HET30W (1.13 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20QDCTO1WW
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40700 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN2HET30W(1.13):bd07/04/2019:svnLENOVO:pn20QDCTO1WW:pvrThinkPadX1Carbon7th:rvnLENOVO:rn20QDCTO1WW:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad X1 Carbon 7th
  dmi.product.name: 20QDCTO1WW
  dmi.product.sku: LENOVO_MT_20QD_BU_Think_FM_ThinkPad X1 Carbon 7th
  dmi.product.version: ThinkPad X1 Carbon 7th
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1853879/+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 1846787] Re: systemd-logind leaves leftover sessions and scope files

2019-11-25 Thread Brian Murray
Balint could you have a look this patch as a substiture for Dimitri?
Thanks!

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

Title:
  systemd-logind leaves leftover sessions and scope files

Status in dbus package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Xenial:
  In Progress
Status in systemd source package in Xenial:
  Incomplete

Bug description:
  [Impact]
  Scope file leakage can cause SSH delays and reduce performance in systemd

  [Description]
  The current systemd-logind version present in Xenial can leave abandoned SSH
  sessions and scope files in cases where the host sees a lot of concurrent SSH
  connections. These leftover sessions can slow down systemd performance
  greatly, and can have an impact on sshd handling a great number of concurrent
  connections.

  To fix this issue, patches are needed in both dbus and systemd. These improve 
the
  performance of the communication between dbus and systemd, so that they can
  handle a better volume of events (e.g. SSH logins). All of those patches are
  already present from Bionic onwards, so we only need those fixes for Xenial.

  == Systemd ==
  Upstream patches:
  - core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification 
(d8fdc62037b5)

  $ git describe --contains d8fdc62037b5
  v230~71^2~2

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.22 | xenial-updates  | source, ... <
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.29 | bionic-security | source, ...
   systemd | 237-3ubuntu10.29 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...

  == DBus ==
  Upstream patches:
  - Only read one message at a time if there are fds pending (892f084eeda0)
  - bus: Fix timeout restarts  (529600397bca)
  - DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)

  $ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
  dbus-1.11.10~44
  dbus-1.11.10~45
  dbus-1.11.16~2

  $ rmadison dbus
   dbus | 1.10.6-1ubuntu3| xenial   | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-security  | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-updates   | source, ... <
   dbus | 1.12.2-1ubuntu1| bionic   | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-security  | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-updates   | source, ...

  [Test Case]
  1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
  multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 & done

  2) Check for leaked sessions in /run/systemd/system/:
  multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
  ...

  [Regression Potential]
  As the patches change the communication socket between dbus and systemd, 
possible regressions could cause systemd to not be notified of dbus events and 
vice-versa. We could see units not getting started properly, and communication 
between 

[Touch-packages] [Bug 1853861] Please test proposed package

2019-11-25 Thread Łukasz Zemczak
Hello Balint, or anyone else affected,

Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.7~16.04.5 in a few hours, and then
in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  [SRU] Unattended-upgrades silently does not apply updates when
  MinimalSteps is disabled and there are autoremovable kernels

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Released
Status in unattended-upgrades source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
   * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
   * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.

  [Test Case]

   * Install kernel-related packages, mark them as automatically installed to 
make them auto-removable ones.
   * Downgrade a few packages to a version lower than what is present in the 
security pocket.
   * Set Unattended-Upgrade::MinimalSteps to "false":
 # echo 'Unattended-Upgrade::MinimalSteps "false";' > 
/etc/apt/apt.conf.d/51unattended-upgrades-oneshot

   * Run u-u:
 # unattended-upgrade --verbose --debug

   * Observe fixed versions removing the kernel packages properly and
  also upgrading packages.

  [Regression Potential]

   * The changes introduce marking packages to install/upgrade and clearing the 
cache more often. The added operations slow down u-u, but clearing the cache 
adds a few 100 milliseconds on typical hardware and marking upgradable packages 
is also in the same range.
   * Functional regressions are unlikely due to those changes since the fixes 
are present in 19.04 and later releases and the extensive autopkgtest also 
covers when upgrades are performed in minimal steps.

  [Other Info]

   * While this bug has a security impact by holding back installation of 
security updates I don't recommend releasing the fix via the security pocket 
because this bug occurs only when the local configuration file of u-u is 
changed and u-u does not hold back upgrades with UCF-managed config file 
conflicts.
See: https://github.com/mvo5/unattended-upgrades/issues/168

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1853861/+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 1853861] Re: [SRU] Unattended-upgrades silently does not apply updates when MinimalSteps is disabled and there are autoremovable kernels

2019-11-25 Thread Łukasz Zemczak
Hello Balint, or anyone else affected,

Accepted unattended-upgrades into bionic-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.13 in a few hours, and then in the
-proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Bionic)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-bionic

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Status: New => Fix Committed

** Tags added: verification-needed-xenial

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

Title:
  [SRU] Unattended-upgrades silently does not apply updates when
  MinimalSteps is disabled and there are autoremovable kernels

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Released
Status in unattended-upgrades source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
   * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
   * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.

  [Test Case]

   * Install kernel-related packages, mark them as automatically installed to 
make them auto-removable ones.
   * Downgrade a few packages to a version lower than what is present in the 
security pocket.
   * Set Unattended-Upgrade::MinimalSteps to "false":
 # echo 'Unattended-Upgrade::MinimalSteps "false";' > 
/etc/apt/apt.conf.d/51unattended-upgrades-oneshot

   * Run u-u:
 # unattended-upgrade --verbose --debug

   * Observe fixed versions removing the kernel packages properly and
  also upgrading packages.

  [Regression Potential]

   * The changes introduce marking packages to install/upgrade and clearing the 
cache more often. The added operations slow down u-u, but clearing the cache 
adds a few 100 milliseconds on typical hardware and marking upgradable packages 
is also in the same range.
   * Functional regressions are unlikely due to those changes since the fixes 
are present in 19.04 and later releases and the extensive autopkgtest also 
covers when upgrades are performed in minimal steps.

  [Other Info]

   * While this bug has a security impact by holding back installation of 
security updates I don't recommend releasing the fix via the security pocket 
because this bug occurs only when the local configuration file of u-u is 
changed and u-u does not hold back upgrades with UCF-managed config file 
conflicts.
See: https://github.com/mvo5/unattended-upgrades/issues/168

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1853861/+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 1788048] Re: systemd journald failed unmounting var

2019-11-25 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu Disco)
   Status: New => Confirmed

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

Title:
  systemd journald failed unmounting var

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Cosmic:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  [impact]

  on a system with /var and/or /var/log mounted separately from /,
  shutdown can't unmount /var (or /var/log) cleanly because systemd-
  journald is using it.

  [test case]

  install a system with /var mounted separately from /

  shutdown, and notice:

  [FAILED] Failed unmounting /var.

  [regression potential]

  TBD

  [other info]

  original description:

  --

  When the system is shut down or restarted the systemd-journal does not
  disassemble the disks correctly.

  On this thread https://unix.stackexchange.com/questions/378678/why-
  do-i-get-the-error-failed-unmounting-var-during-shutdown

  I checked what editing /etc/systemd/journald.conf
  to change the Storage = line to Storage = volatile the problem is solved, but 
some of the logs on the shutdown are lost.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Mon Aug 20 18:15:07 2018
  ExecutablePath: /lib/systemd/systemd-journald
  InstallationDate: Installed on 2018-08-20 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
   Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: innotek GmbH VirtualBox
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-32-generic 
root=UUID=65cb761b-4881-4031-9113-e6bb6a1437b4 ro
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/01/2006
  dmi.bios.vendor: innotek GmbH
  dmi.bios.version: VirtualBox
  dmi.board.name: VirtualBox
  dmi.board.vendor: Oracle Corporation
  dmi.board.version: 1.2
  dmi.chassis.type: 1
  dmi.chassis.vendor: Oracle Corporation
  dmi.modalias: 
dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
  dmi.product.family: Virtual Machine
  dmi.product.name: VirtualBox
  dmi.product.version: 1.2
  dmi.sys.vendor: innotek GmbH
  mtime.conffile..etc.systemd.journald.conf: 2018-08-20T18:00:58.586165

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1788048/+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 1788048] Re: systemd journald failed unmounting var

2019-11-25 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

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

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

Title:
  systemd journald failed unmounting var

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Cosmic:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  [impact]

  on a system with /var and/or /var/log mounted separately from /,
  shutdown can't unmount /var (or /var/log) cleanly because systemd-
  journald is using it.

  [test case]

  install a system with /var mounted separately from /

  shutdown, and notice:

  [FAILED] Failed unmounting /var.

  [regression potential]

  TBD

  [other info]

  original description:

  --

  When the system is shut down or restarted the systemd-journal does not
  disassemble the disks correctly.

  On this thread https://unix.stackexchange.com/questions/378678/why-
  do-i-get-the-error-failed-unmounting-var-during-shutdown

  I checked what editing /etc/systemd/journald.conf
  to change the Storage = line to Storage = volatile the problem is solved, but 
some of the logs on the shutdown are lost.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Mon Aug 20 18:15:07 2018
  ExecutablePath: /lib/systemd/systemd-journald
  InstallationDate: Installed on 2018-08-20 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
   Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: innotek GmbH VirtualBox
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-32-generic 
root=UUID=65cb761b-4881-4031-9113-e6bb6a1437b4 ro
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/01/2006
  dmi.bios.vendor: innotek GmbH
  dmi.bios.version: VirtualBox
  dmi.board.name: VirtualBox
  dmi.board.vendor: Oracle Corporation
  dmi.board.version: 1.2
  dmi.chassis.type: 1
  dmi.chassis.vendor: Oracle Corporation
  dmi.modalias: 
dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
  dmi.product.family: Virtual Machine
  dmi.product.name: VirtualBox
  dmi.product.version: 1.2
  dmi.sys.vendor: innotek GmbH
  mtime.conffile..etc.systemd.journald.conf: 2018-08-20T18:00:58.586165

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1788048/+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 1846787] Re: systemd-logind leaves leftover sessions and scope files

2019-11-25 Thread Steve Langasek
Marking incomplete based on the fact that Robie has asked for additional
review.

** Changed in: systemd (Ubuntu Xenial)
   Status: In Progress => 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/1846787

Title:
  systemd-logind leaves leftover sessions and scope files

Status in dbus package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Xenial:
  In Progress
Status in systemd source package in Xenial:
  Incomplete

Bug description:
  [Impact]
  Scope file leakage can cause SSH delays and reduce performance in systemd

  [Description]
  The current systemd-logind version present in Xenial can leave abandoned SSH
  sessions and scope files in cases where the host sees a lot of concurrent SSH
  connections. These leftover sessions can slow down systemd performance
  greatly, and can have an impact on sshd handling a great number of concurrent
  connections.

  To fix this issue, patches are needed in both dbus and systemd. These improve 
the
  performance of the communication between dbus and systemd, so that they can
  handle a better volume of events (e.g. SSH logins). All of those patches are
  already present from Bionic onwards, so we only need those fixes for Xenial.

  == Systemd ==
  Upstream patches:
  - core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification 
(d8fdc62037b5)

  $ git describe --contains d8fdc62037b5
  v230~71^2~2

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.22 | xenial-updates  | source, ... <
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.29 | bionic-security | source, ...
   systemd | 237-3ubuntu10.29 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...

  == DBus ==
  Upstream patches:
  - Only read one message at a time if there are fds pending (892f084eeda0)
  - bus: Fix timeout restarts  (529600397bca)
  - DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)

  $ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
  dbus-1.11.10~44
  dbus-1.11.10~45
  dbus-1.11.16~2

  $ rmadison dbus
   dbus | 1.10.6-1ubuntu3| xenial   | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-security  | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-updates   | source, ... <
   dbus | 1.12.2-1ubuntu1| bionic   | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-security  | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-updates   | source, ...

  [Test Case]
  1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
  multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 & done

  2) Check for leaked sessions in /run/systemd/system/:
  multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
  ...

  [Regression Potential]
  As the patches change the communication socket between dbus and systemd, 
possible regressions could cause systemd to not be notified of dbus events and 

[Touch-packages] [Bug 1788048] Re: systemd journald failed unmounting var

2019-11-25 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu Cosmic)
   Status: New => Confirmed

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

Title:
  systemd journald failed unmounting var

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Cosmic:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  [impact]

  on a system with /var and/or /var/log mounted separately from /,
  shutdown can't unmount /var (or /var/log) cleanly because systemd-
  journald is using it.

  [test case]

  install a system with /var mounted separately from /

  shutdown, and notice:

  [FAILED] Failed unmounting /var.

  [regression potential]

  TBD

  [other info]

  original description:

  --

  When the system is shut down or restarted the systemd-journal does not
  disassemble the disks correctly.

  On this thread https://unix.stackexchange.com/questions/378678/why-
  do-i-get-the-error-failed-unmounting-var-during-shutdown

  I checked what editing /etc/systemd/journald.conf
  to change the Storage = line to Storage = volatile the problem is solved, but 
some of the logs on the shutdown are lost.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Mon Aug 20 18:15:07 2018
  ExecutablePath: /lib/systemd/systemd-journald
  InstallationDate: Installed on 2018-08-20 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
   Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: innotek GmbH VirtualBox
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-32-generic 
root=UUID=65cb761b-4881-4031-9113-e6bb6a1437b4 ro
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/01/2006
  dmi.bios.vendor: innotek GmbH
  dmi.bios.version: VirtualBox
  dmi.board.name: VirtualBox
  dmi.board.vendor: Oracle Corporation
  dmi.board.version: 1.2
  dmi.chassis.type: 1
  dmi.chassis.vendor: Oracle Corporation
  dmi.modalias: 
dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
  dmi.product.family: Virtual Machine
  dmi.product.name: VirtualBox
  dmi.product.version: 1.2
  dmi.sys.vendor: innotek GmbH
  mtime.conffile..etc.systemd.journald.conf: 2018-08-20T18:00:58.586165

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1788048/+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 1853879] [NEW] Dell E310dw: Default driver doesn't work, driverless fails on sides=two-sided-long-edge

2019-11-25 Thread Akkana Peck
Public bug reported:

Dell E310dw printer which worked well on 19.04 has problems in 19.10:

First, I went through the CUPS web interface to add the printer. The
interface gave me a choice of two entries with the same name plus one
with "driverless" added. I chose the first entry (not driverless) and
completed adding the printer. On the Printers page, the Dell was now
listed. When I tried "Print Test Page", I got many pages each containing
a single line of symbols.

I deleted the printer in the web interface, intending to start again and choose 
the second option. But after I did Delete Printer, CUPS took me back to the 
Printers page which now listed:
Dell_Printer_E310dw@DELL316BAA.localDell Printer E310dw, 
driverless, cups-filters 1.25.11

So I clicked on that printer and tried Print Test Page, which worked. So
then I tried a duplex print (which is really what I need this morning):

 lp -o sides=two-sided-long-edge -o collate=true -d
Dell_Printer_E310dw@DELL316BAA.local filename.pdf

It printed the PDF 2-sided, but with the sides flipped around the short
edge, as if it was a landscape print. I tried the same command with
sides=two-sided-short-edge and it flipped the same way. So sides is
handling duplex but ignoring which edge is supposed to be used, and
defaulting to landscape which I'd guess is less commonly what people
want.

This is all using what's built into Ubuntu. I haven't yet downloaded any
extra drivers from Dell's site since Ubuntu claims to have a driver for
the printer, and I'm pretty sure it was working in 19.04 (I may still
have a working 19.04 to check that, if it would help).

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: cups 2.2.12-2ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
Uname: Linux 5.3.0-23-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
Date: Mon Nov 25 09:58:21 2019
InstallationDate: Installed on 2019-10-10 (45 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20190926.1)
Lpstat:
 device for Brother_HL-3170CDW_series: 
dnssd://Brother%20HL-3170CDW%20series._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-3c2af4251dee
 device for Dell_Printer_E310dw@DELL316BAA.local: 
implicitclass://Dell_Printer_E310dw%40DELL316BAA.local/
MachineType: LENOVO 20QDCTO1WW
Papersize: letter
PpdFiles:
 Error: command ['fgrep', '-H', '*NickName', 
'/etc/cups/ppd/dell_printer_e31...@dell316baa.local.ppd', 
'/etc/cups/ppd/Brother_HL-3170CDW_series.ppd'] failed with exit code 2: grep: 
/etc/cups/ppd/dell_printer_e31...@dell316baa.local.ppd: Permission denied
 grep: /etc/cups/ppd/Brother_HL-3170CDW_series.ppd: Permission denied
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-23-generic 
root=UUID=a5868be6-8495-47af-a190-9af5fdc9b419 ro
SourcePackage: cups
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/04/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N2HET30W (1.13 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20QDCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40700 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: 
dmi:bvnLENOVO:bvrN2HET30W(1.13):bd07/04/2019:svnLENOVO:pn20QDCTO1WW:pvrThinkPadX1Carbon7th:rvnLENOVO:rn20QDCTO1WW:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad X1 Carbon 7th
dmi.product.name: 20QDCTO1WW
dmi.product.sku: LENOVO_MT_20QD_BU_Think_FM_ThinkPad X1 Carbon 7th
dmi.product.version: ThinkPad X1 Carbon 7th
dmi.sys.vendor: LENOVO

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


** Tags: amd64 apport-bug eoan

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

Title:
  Dell E310dw: Default driver doesn't work, driverless fails on sides
  =two-sided-long-edge

Status in cups package in Ubuntu:
  New

Bug description:
  Dell E310dw printer which worked well on 19.04 has problems in 19.10:

  First, I went through the CUPS web interface to add the printer. The
  interface gave me a choice of two entries with the same name plus one
  with "driverless" added. I chose the first entry (not driverless) and
  completed adding the printer. On the Printers page, the Dell was now
  listed. When I tried "Print Test Page", I got many pages each
  containing a single line of symbols.

  I deleted the printer in the web interface, intending to start again and 
choose the second option. But after I did Delete Printer, CUPS took me back to 
the Printers page which now listed:
  Dell_Printer_E310dw@DELL316BAA.local  Dell Printer E310dw, 
driverless, cups-filters 1.25.11

  So I clicked on that printer and tried Print Test Page, which worked.
  So then I tried a duplex print (which is really what I need this
  morning):

   lp -o 

[Touch-packages] [Bug 1788048] Re: systemd journald failed unmounting var

2019-11-25 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

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

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

Title:
  systemd journald failed unmounting var

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Cosmic:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  [impact]

  on a system with /var and/or /var/log mounted separately from /,
  shutdown can't unmount /var (or /var/log) cleanly because systemd-
  journald is using it.

  [test case]

  install a system with /var mounted separately from /

  shutdown, and notice:

  [FAILED] Failed unmounting /var.

  [regression potential]

  TBD

  [other info]

  original description:

  --

  When the system is shut down or restarted the systemd-journal does not
  disassemble the disks correctly.

  On this thread https://unix.stackexchange.com/questions/378678/why-
  do-i-get-the-error-failed-unmounting-var-during-shutdown

  I checked what editing /etc/systemd/journald.conf
  to change the Storage = line to Storage = volatile the problem is solved, but 
some of the logs on the shutdown are lost.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Mon Aug 20 18:15:07 2018
  ExecutablePath: /lib/systemd/systemd-journald
  InstallationDate: Installed on 2018-08-20 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
   Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: innotek GmbH VirtualBox
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-32-generic 
root=UUID=65cb761b-4881-4031-9113-e6bb6a1437b4 ro
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/01/2006
  dmi.bios.vendor: innotek GmbH
  dmi.bios.version: VirtualBox
  dmi.board.name: VirtualBox
  dmi.board.vendor: Oracle Corporation
  dmi.board.version: 1.2
  dmi.chassis.type: 1
  dmi.chassis.vendor: Oracle Corporation
  dmi.modalias: 
dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
  dmi.product.family: Virtual Machine
  dmi.product.name: VirtualBox
  dmi.product.version: 1.2
  dmi.sys.vendor: innotek GmbH
  mtime.conffile..etc.systemd.journald.conf: 2018-08-20T18:00:58.586165

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1788048/+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 1788048] Re: systemd journald failed unmounting var

2019-11-25 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu Eoan)
   Status: New => Confirmed

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

Title:
  systemd journald failed unmounting var

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Cosmic:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  [impact]

  on a system with /var and/or /var/log mounted separately from /,
  shutdown can't unmount /var (or /var/log) cleanly because systemd-
  journald is using it.

  [test case]

  install a system with /var mounted separately from /

  shutdown, and notice:

  [FAILED] Failed unmounting /var.

  [regression potential]

  TBD

  [other info]

  original description:

  --

  When the system is shut down or restarted the systemd-journal does not
  disassemble the disks correctly.

  On this thread https://unix.stackexchange.com/questions/378678/why-
  do-i-get-the-error-failed-unmounting-var-during-shutdown

  I checked what editing /etc/systemd/journald.conf
  to change the Storage = line to Storage = volatile the problem is solved, but 
some of the logs on the shutdown are lost.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Mon Aug 20 18:15:07 2018
  ExecutablePath: /lib/systemd/systemd-journald
  InstallationDate: Installed on 2018-08-20 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
   Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: innotek GmbH VirtualBox
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-32-generic 
root=UUID=65cb761b-4881-4031-9113-e6bb6a1437b4 ro
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/01/2006
  dmi.bios.vendor: innotek GmbH
  dmi.bios.version: VirtualBox
  dmi.board.name: VirtualBox
  dmi.board.vendor: Oracle Corporation
  dmi.board.version: 1.2
  dmi.chassis.type: 1
  dmi.chassis.vendor: Oracle Corporation
  dmi.modalias: 
dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
  dmi.product.family: Virtual Machine
  dmi.product.name: VirtualBox
  dmi.product.version: 1.2
  dmi.sys.vendor: innotek GmbH
  mtime.conffile..etc.systemd.journald.conf: 2018-08-20T18:00:58.586165

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1788048/+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 1853880] [NEW] package libxcb-present0:i386 1.11.1-1ubuntu1 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting con

2019-11-25 Thread Sundeep
Public bug reported:

Installation failed during upgradation

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: libxcb-present0:i386 1.11.1-1ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-96.143-generic 3.13.11-ckt39
Uname: Linux 3.13.0-96-generic x86_64
.tmp.unity_support_test.0:
 
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
BootLog:
 
CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
Date: Mon Nov 25 22:39:15 2019
DistUpgraded: 2017-03-19 23:16:17,380 WARNING no activity on terminal for 300 
seconds (Preparing to configure libapt-inst2.0 (amd64))
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-oneiric-amd64-2016-1
DistroCodename: xenial
DistroVariant: ubuntu
DuplicateSignature: package:libxcb-present0:i386:1.11.1-1ubuntu1:package is in 
a very bad inconsistent state; you should  reinstall it before attempting 
configuration
ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
GraphicsCard:
 Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 
09) (prog-if 00 [VGA controller])
   Subsystem: Dell 3rd Gen Core processor Graphics Controller [1028:0569]
InstallationDate: Installed on 2012-07-20 (2683 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric" - Build amd64 LIVE Binary 
2016-18:24
MachineType: Dell Inc. Inspiron 5520
PackageArchitecture: i386
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-96-generic 
root=UUID=c6f93b82-e3c9-42f0-9e0c-05438c56139b ro quiet splash vt.handoff=7
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1.6
 apt  1.2.32
SourcePackage: libxcb
Title: package libxcb-present0:i386 1.11.1-1ubuntu1 failed to install/upgrade: 
package is in a very bad inconsistent state; you should  reinstall it before 
attempting configuration
UpgradeStatus: Upgraded to xenial on 2017-03-19 (980 days ago)
dmi.bios.date: 05/17/2012
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: 0Y0X1K
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A07
dmi.modalias: 
dmi:bvnDellInc.:bvrA07:bd05/17/2012:svnDellInc.:pnInspiron5520:pvrA07:rvnDellInc.:rn0Y0X1K:rvrA00:cvnDellInc.:ct8:cvrA07:
dmi.product.name: Inspiron 5520
dmi.product.version: A07
dmi.sys.vendor: Dell Inc.
version.compiz: compiz 1:0.9.12.3+16.04.20180221-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.3-0ubuntu0.6
version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2
xserver.bootTime: Mon Nov 25 22:03:45 2019
xserver.configfile: default
xserver.errors:
 
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 826 
 vendor LGD
xserver.version: 2:1.18.4-0ubuntu0.8

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


** Tags: apport-package compiz-0.9 i386 ubuntu xenial

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

Title:
  package libxcb-present0:i386 1.11.1-1ubuntu1 failed to
  install/upgrade: package is in a very bad inconsistent state; you
  should  reinstall it before attempting configuration

Status in libxcb package in Ubuntu:
  New

Bug description:
  Installation failed during upgradation

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: libxcb-present0:i386 1.11.1-1ubuntu1
  ProcVersionSignature: Ubuntu 3.13.0-96.143-generic 3.13.11-ckt39
  Uname: Linux 3.13.0-96-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  BootLog:
   
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  Date: Mon Nov 25 22:39:15 2019
  DistUpgraded: 2017-03-19 23:16:17,380 WARNING no activity on terminal for 300 
seconds (Preparing to configure libapt-inst2.0 (amd64))
  DistributionChannelDescriptor:
   # This is a distribution channel descriptor
   # For more information see 

[Touch-packages] [Bug 1853880] Re: package libxcb-present0:i386 1.11.1-1ubuntu1 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting confi

2019-11-25 Thread Apport retracing service
** Tags removed: need-duplicate-check

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

Title:
  package libxcb-present0:i386 1.11.1-1ubuntu1 failed to
  install/upgrade: package is in a very bad inconsistent state; you
  should  reinstall it before attempting configuration

Status in libxcb package in Ubuntu:
  New

Bug description:
  Installation failed during upgradation

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: libxcb-present0:i386 1.11.1-1ubuntu1
  ProcVersionSignature: Ubuntu 3.13.0-96.143-generic 3.13.11-ckt39
  Uname: Linux 3.13.0-96-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.14.1-0ubuntu3.21
  Architecture: amd64
  BootLog:
   
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  Date: Mon Nov 25 22:39:15 2019
  DistUpgraded: 2017-03-19 23:16:17,380 WARNING no activity on terminal for 300 
seconds (Preparing to configure libapt-inst2.0 (amd64))
  DistributionChannelDescriptor:
   # This is a distribution channel descriptor
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-oneiric-amd64-2016-1
  DistroCodename: xenial
  DistroVariant: ubuntu
  DuplicateSignature: package:libxcb-present0:i386:1.11.1-1ubuntu1:package is 
in a very bad inconsistent state; you should  reinstall it before attempting 
configuration
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  GraphicsCard:
   Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] 
(rev 09) (prog-if 00 [VGA controller])
 Subsystem: Dell 3rd Gen Core processor Graphics Controller [1028:0569]
  InstallationDate: Installed on 2012-07-20 (2683 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric" - Build amd64 LIVE Binary 
2016-18:24
  MachineType: Dell Inc. Inspiron 5520
  PackageArchitecture: i386
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-96-generic 
root=UUID=c6f93b82-e3c9-42f0-9e0c-05438c56139b ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32
  SourcePackage: libxcb
  Title: package libxcb-present0:i386 1.11.1-1ubuntu1 failed to 
install/upgrade: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  UpgradeStatus: Upgraded to xenial on 2017-03-19 (980 days ago)
  dmi.bios.date: 05/17/2012
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A07
  dmi.board.name: 0Y0X1K
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A07
  dmi.modalias: 
dmi:bvnDellInc.:bvrA07:bd05/17/2012:svnDellInc.:pnInspiron5520:pvrA07:rvnDellInc.:rn0Y0X1K:rvrA00:cvnDellInc.:ct8:cvrA07:
  dmi.product.name: Inspiron 5520
  dmi.product.version: A07
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz 1:0.9.12.3+16.04.20180221-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.3-0ubuntu0.6
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.8
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2
  xserver.bootTime: Mon Nov 25 22:03:45 2019
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.outputs:
   product id 826 
   vendor LGD
  xserver.version: 2:1.18.4-0ubuntu0.8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/1853880/+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 1853374] Re: pulseaudio disables GP107GL output every so often

2019-11-25 Thread Ian
If I log out the first user, the second user suddenly has sound.

And it didn't do this on Friday, when the same programs were running
before the user switch.

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

Title:
  pulseaudio disables GP107GL output every so often

Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  Since upgrading to 19.10, the sound output on this PC stops.

  Looking at the volume control's 'sound settings', the GP107GL High
  Definition Audio Controller (digital stereo HMDI 2 output) is
  disabled.

  Doing

  pluseaudio -k

  restores it.

  Possibly relevant from syslog:

  Nov 18 07:48:51 example kernel: [42392.063211] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 07:51:04 example kernel: [42524.900935] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 2
  Nov 18 08:05:23 example kernel: [43383.465647] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 09:34:08 example kernel: [48708.806452] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 4
  Nov 18 13:32:46 example kernel: [63026.605375] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 13:34:13 example kernel: [63114.281953] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 13:34:40 example kernel: [63141.350110] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1853374/+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 1853374] Re: pulseaudio disables GP107GL output every so often

2019-11-25 Thread Ian
Yes, it seems to be a 'multiple users logged in' thing.

Use the sound in one user, then - at some seemingly random point that's
NOT while something is actually playing - discover that the sound system
is disabled. It's possible that both users have it not working, or one
to work and one not to.

Attached is the logs for a second - not using the GP107GL chipset - PC
where it's just happened. Sound was working fine in one user (and still
is) and disabled in the second.

They logged in at about 16:30...

** Attachment added: "logs"
   
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1853374/+attachment/5307739/+files/logs

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

Title:
  pulseaudio disables GP107GL output every so often

Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  Since upgrading to 19.10, the sound output on this PC stops.

  Looking at the volume control's 'sound settings', the GP107GL High
  Definition Audio Controller (digital stereo HMDI 2 output) is
  disabled.

  Doing

  pluseaudio -k

  restores it.

  Possibly relevant from syslog:

  Nov 18 07:48:51 example kernel: [42392.063211] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 07:51:04 example kernel: [42524.900935] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 2
  Nov 18 08:05:23 example kernel: [43383.465647] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 09:34:08 example kernel: [48708.806452] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 4
  Nov 18 13:32:46 example kernel: [63026.605375] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 13:34:13 example kernel: [63114.281953] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 3
  Nov 18 13:34:40 example kernel: [63141.350110] snd_hda_codec_hdmi 
hdaudioC0D0: HDMI: invalid ELD data byte 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1853374/+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 1832787] Re: fontconfig 2.12 in 18.04 causes firefox to freeze when launching chrome

2019-11-25 Thread Olivier Duclos
Any chance fontconfig 2.13 could be backported to bionic? This is a
seriously annoying issue.

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

Title:
  fontconfig 2.12 in 18.04 causes firefox to freeze when launching
  chrome

Status in fontconfig package in Ubuntu:
  Confirmed

Bug description:
  fontconfig version: 2.12.6-0ubuntu2

  Related:

  https://askubuntu.com/questions/1076412/firefox-freezing-with-100-cpu-
  usage-for-30-seconds-when-launching-chromium

  https://bugzilla.mozilla.org/show_bug.cgi?id=1495900

  https://bugzilla.mozilla.org/show_bug.cgi?id=1411338

  
  Steps to reproduce:

  1) Launch firefox, open a few tabs

  2) Launch chrome

  3) Go back to firefox, and notice it starts being very slow, switching
  tabs do nothing (the content area remains blank).

  4) Backport fontconfig 2.13 from cosmic to bionic

  5) Try to reproduce 1-3, be happy because it is now working fine!

  
  I backported 2.13.0-5ubuntu3 from cosmic to bionic, if that helps. I don't 
have the right setup right now to do a bisect from upstream or from debian 
patches sadly.

  ~ lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04
  Codename: bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1832787/+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 1783881] Re: ltp-syscalls: msgstress03 fails because systemd limits number of processes

2019-11-25 Thread Sean Feole
** Changed in: ubuntu-kernel-tests
   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/1783881

Title:
  ltp-syscalls: msgstress03 fails because systemd limits number of
  processes

Status in ubuntu-kernel-tests:
  Triaged
Status in linux package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in linux source package in Cosmic:
  Incomplete

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 1853861] Re: [SRU] Unattended-upgrades silently does not apply updates when MinimalSteps is disabled and there are autoremovable kernels

2019-11-25 Thread Balint Reczey
** Also affects: unattended-upgrades (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Changed in: unattended-upgrades (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: unattended-upgrades (Ubuntu Disco)
   Status: New => Fix Released

** Changed in: unattended-upgrades (Ubuntu Eoan)
   Status: New => Fix Released

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

Title:
  [SRU] Unattended-upgrades silently does not apply updates when
  MinimalSteps is disabled and there are autoremovable kernels

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New
Status in unattended-upgrades source package in Disco:
  Fix Released
Status in unattended-upgrades source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
   * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
   * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.

  [Test Case]

   * Install kernel-related packages, mark them as automatically installed to 
make them auto-removable ones.
   * Downgrade a few packages to a version lower than what is present in the 
security pocket.
   * Set Unattended-Upgrade::MinimalSteps to "false":
 # echo 'Unattended-Upgrade::MinimalSteps "false";' > 
/etc/apt/apt.conf.d/51unattended-upgrades-oneshot

   * Run u-u:
 # unattended-upgrade --verbose --debug

   * Observe fixed versions removing the kernel packages properly and
  also upgrading packages.

  [Regression Potential]

   * The changes introduce marking packages to install/upgrade and clearing the 
cache more often. The added operations slow down u-u, but clearing the cache 
adds a few 100 milliseconds on typical hardware and marking upgradable packages 
is also in the same range.
   * Functional regressions are unlikely due to those changes since the fixes 
are present in 19.04 and later releases and the extensive autopkgtest also 
covers when upgrades are performed in minimal steps.

  [Other Info]

   * While this bug has a security impact by holding back installation of 
security updates I don't recommend releasing the fix via the security pocket 
because this bug occurs only when the local configuration file of u-u is 
changed and u-u does not hold back upgrades with UCF-managed config file 
conflicts.
See: https://github.com/mvo5/unattended-upgrades/issues/168

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1853861/+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 1853861] Re: [SRU] Unattended-upgrades silently does not apply updates when MinimalSteps is disabled and there are autoremovable kernels

2019-11-25 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: unattended-upgrades (Ubuntu)
   Status: New => Confirmed

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

Title:
  [SRU] Unattended-upgrades silently does not apply updates when
  MinimalSteps is disabled and there are autoremovable kernels

Status in unattended-upgrades package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

   * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
   * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
   * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.

  [Test Case]

   * Install kernel-related packages, mark them as automatically installed to 
make them auto-removable ones.
   * Downgrade a few packages to a version lower than what is present in the 
security pocket.
   * Set Unattended-Upgrade::MinimalSteps to "false":
 # echo 'Unattended-Upgrade::MinimalSteps "false";' > 
/etc/apt/apt.conf.d/51unattended-upgrades-oneshot

   * Run u-u:
 # unattended-upgrade --verbose --debug

   * Observe fixed versions removing the kernel packages properly and
  also upgrading packages.

  [Regression Potential]

   * The changes introduce marking packages to install/upgrade and clearing the 
cache more often. The added operations slow down u-u, but clearing the cache 
adds a few 100 milliseconds on typical hardware and marking upgradable packages 
is also in the same range.
   * Functional regressions are unlikely due to those changes since the fixes 
are present in 19.04 and later releases and the extensive autopkgtest also 
covers when upgrades are performed in minimal steps.

  [Other Info]

   * While this bug has a security impact by holding back installation of 
security updates I don't recommend releasing the fix via the security pocket 
because this bug occurs only when the local configuration file of u-u is 
changed and u-u does not hold back upgrades with UCF-managed config file 
conflicts.
See: https://github.com/mvo5/unattended-upgrades/issues/168

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1853861/+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 1853861] Re: [SRU] Unattended-upgrades silently does not apply updates when MinimalSteps is disabled and there are autoremovable kernels

2019-11-25 Thread Balint Reczey
** Information type changed from Public to Public Security

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

Title:
  [SRU] Unattended-upgrades silently does not apply updates when
  MinimalSteps is disabled and there are autoremovable kernels

Status in unattended-upgrades package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

   * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
   * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
   * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.

  [Test Case]

   * Install kernel-related packages, mark them as automatically installed to 
make them auto-removable ones.
   * Downgrade a few packages to a version lower than what is present in the 
security pocket.
   * Set Unattended-Upgrade::MinimalSteps to "false":
 # echo 'Unattended-Upgrade::MinimalSteps "false";' > 
/etc/apt/apt.conf.d/51unattended-upgrades-oneshot

   * Run u-u:
 # unattended-upgrade --verbose --debug

   * Observe fixed versions removing the kernel packages properly and
  also upgrading packages.

  [Regression Potential]

   * The changes introduce marking packages to install/upgrade and clearing the 
cache more often. The added operations slow down u-u, but clearing the cache 
adds a few 100 milliseconds on typical hardware and marking upgradable packages 
is also in the same range.
   * Functional regressions are unlikely due to those changes since the fixes 
are present in 19.04 and later releases and the extensive autopkgtest also 
covers when upgrades are performed in minimal steps.

  [Other Info]

   * While this bug has a security impact by holding back installation of 
security updates I don't recommend releasing the fix via the security pocket 
because this bug occurs only when the local configuration file of u-u is 
changed and u-u does not hold back upgrades with UCF-managed config file 
conflicts.
See: https://github.com/mvo5/unattended-upgrades/issues/168

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1853861/+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 1853861] Re: [SRU] Unattended-upgrades does not apply updates when MinimalSteps is disabled and there are autoremovable kernels

2019-11-25 Thread Balint Reczey
** Description changed:

  [Impact]
  
-  * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
-  * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
-  * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.
+  * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
+  * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
+  * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.
  
  [Test Case]
  
+  * Install kernel-related packages, mark them as automatically installed to 
make them auto-removable ones.
+  * Downgrade a few packages to a version lower than what is present in the 
security pocket.
+  * Set Unattended-Upgrade::MinimalSteps to "false":
+# echo 'Unattended-Upgrade::MinimalSteps "false";' > 
/etc/apt/apt.conf.d/51unattended-upgrades-oneshot
+ 
+  * Run u-u:
+# unattended-upgrade --verbose --debug
+ 
+  * Observe fixed versions removing the kernel packages properly and also
+ upgrading packages.
+ 
  [Regression Potential]
  
+  * The changes introduce marking packages to install/upgrade and clearing the 
cache more often. The added operations slow down u-u, but clearing the cache 
adds a few 100 milliseconds on typical hardware and marking upgradable packages 
is also in the same range.
+  * Functional regressions are unlikely due to those changes since the fixes 
are present in 19.04 and later releases and the extensive autopkgtest also 
covers when upgrades are performed in minimal steps.
+ 
  [Other Info]
+ 
+  * While this bug has a security impact by holding back installation of 
security updates I don't recommend releasing the fix via the security pocket 
because this bug occurs only when the local configuration file of u-u is 
changed and u-u does not hold back upgrades with UCF-managed config file 
conflicts.
+   See: https://github.com/mvo5/unattended-upgrades/issues/168

** Summary changed:

- [SRU] Unattended-upgrades does not apply updates when MinimalSteps is 
disabled and there are autoremovable kernels
+ [SRU] Unattended-upgrades silently does not apply updates when MinimalSteps 
is disabled and there are autoremovable kernels

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

Title:
  [SRU] Unattended-upgrades silently does not apply updates when
  MinimalSteps is disabled and there are autoremovable kernels

Status in unattended-upgrades package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

   * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
   * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
   * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.

  [Test Case]

   * Install kernel-related packages, mark them as automatically installed to 
make them auto-removable ones.
   * Downgrade a few packages to a version lower than what is present in the 
security pocket.
   * Set Unattended-Upgrade::MinimalSteps to "false":
 # echo 'Unattended-Upgrade::MinimalSteps "false";' > 
/etc/apt/apt.conf.d/51unattended-upgrades-oneshot

   * Run u-u:
 # unattended-upgrade --verbose --debug

   * Observe fixed versions removing the kernel packages properly and
  also upgrading packages.

  [Regression Potential]

   * The changes introduce marking packages to install/upgrade and clearing the 
cache more often. The added operations slow down u-u, but clearing the cache 
adds a few 100 milliseconds on typical hardware and marking upgradable packages 
is also in the same range.
   * Functional regressions are unlikely due to those changes since the fixes 
are present in 19.04 and later releases and the extensive autopkgtest also 
covers when upgrades are performed in minimal steps.

  [Other Info]

   * While this bug has a security impact by holding back installation of 
security updates I don't recommend releasing the fix via the security pocket 
because this 

[Touch-packages] [Bug 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
Ok, confirmed the patch debian/patches/test-expect-mmap-to-fail-in-
seccomp-test-on-s390-and-s390.patch has to be taken out to make it work
on s390x.

And most likely the same needs to happen for x86-32bit - there we don't have a 
patch.
But this most likely also needs to be switched to no more work to block due to 
changes in libseccomp. That change then could be discussed upstream to identify 
the reasons in libseccomp causing this.

Maybe until then rbalint can report why this patch was added and if
there was a discussion associated.

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853861] [NEW] [SRU] Unattended-upgrades does not apply updates when MinimalSteps is disabled and there are autoremovable kernels

2019-11-25 Thread Balint Reczey
Public bug reported:

[Impact]

 * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
 * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
 * The fix is clearing the cache between operations and marking packages before 
installing them in one shot.

[Test Case]

[Regression Potential]

[Other Info]

** Affects: unattended-upgrades (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  [SRU] Unattended-upgrades does not apply updates when MinimalSteps is
  disabled and there are autoremovable kernels

Status in unattended-upgrades package in Ubuntu:
  New

Bug description:
  [Impact]

   * When autoremovable kernel packages are present on the system, there are 
updates to apply and Unattended-Upgrade::MinimalSteps is set to "false", the 
autoremovable kernel packages are not removed and the updates are not applied.
   * The root cause is u-u not cleaning the dirty cache between operations and 
also relying on having a cache with packages marked to be installed when 
applying updates in one shot.
   * The fix is clearing the cache between operations and marking packages 
before installing them in one shot.

  [Test Case]

  [Regression Potential]

  [Other Info]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1853861/+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 1852855] Re: package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10

2019-11-25 Thread Balint Reczey
What is the output of:

sudo apt-get -f install

?


** Changed in: unattended-upgrades (Ubuntu)
   Status: New => Incomplete

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

Title:
  package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.4 failed to
  install/upgrade: subprocess installed post-installation script
  returned error exit status 10

Status in unattended-upgrades package in Ubuntu:
  Incomplete

Bug description:
  got error while dpkg command

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: unattended-upgrades 1.1ubuntu1.18.04.7~16.04.4
  ProcVersionSignature: Ubuntu 4.4.0-166.195-generic 4.4.194
  Uname: Linux 4.4.0-166-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.21
  Architecture: amd64
  Date: Sat Nov 16 19:41:53 2019
  DistributionChannelDescriptor:
   # This is a distribution channel descriptor
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-xenial-amd64-20160624-2
  DuplicateSignature:
   package:unattended-upgrades:1.1ubuntu1.18.04.7~16.04.4
   Setting up unattended-upgrades (1.1ubuntu1.18.04.7~16.04.4) ...
   dpkg: error processing package unattended-upgrades (--configure):
subprocess installed post-installation script returned error exit status 10
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 10
  InstallationDate: Installed on 2019-03-04 (257 days ago)
  InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 
20160624-10:47
  PackageArchitecture: all
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32
  SourcePackage: unattended-upgrades
  Title: package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.4 failed to 
install/upgrade: subprocess installed post-installation script returned error 
exit status 10
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1852855/+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 1851225] Re: package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

2019-11-25 Thread Balint Reczey
*** This bug is a duplicate of bug 500175 ***
https://bugs.launchpad.net/bugs/500175

** This bug has been marked a duplicate of bug 500175
   Canceling an installation in Software Center crashes debconf with "Use of 
uninitialized value $reply in scalar chomp at 
/usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"

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

Title:
  package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.3 failed to
  install/upgrade: subprocess installed post-installation script
  returned error exit status 1

Status in unattended-upgrades package in Ubuntu:
  New

Bug description:
  During installation of upgrade to version 16.04

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: unattended-upgrades 1.1ubuntu1.18.04.7~16.04.3
  ProcVersionSignature: Ubuntu 4.4.0-166.195-generic 4.4.194
  Uname: Linux 4.4.0-166-generic i686
  .var.log.apt.history.log:
   
  ApportVersion: 2.20.1-0ubuntu2.20
  Architecture: i386
  Date: Mon Nov  4 11:03:07 2019
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationDate: Installed on 2013-12-05 (2159 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424)
  PackageArchitecture: all
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32
  SourcePackage: unattended-upgrades
  Title: package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.3 failed to 
install/upgrade: subprocess installed post-installation script returned error 
exit status 1
  UpgradeStatus: Upgraded to xenial on 2019-11-04 (0 days ago)
  mtime.conffile..etc.apt.apt.conf.d.50unattended-upgrades: 2019-04-30T12:03:15

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1851225/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
Adding [1] might be worth in general - this is the patch for the arm
related discussion which seems applied upstream.

[1]:
https://github.com/systemd/systemd/commit/4df8fe8415eaf4abd5b93c3447452547c6ea9e5f

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853739] Re: normal usage then all apps stopped and UI dropped to desktop

2019-11-25 Thread pleabargain
Thanks for the clarification.

On Mon, Nov 25, 2019 at 11:36 AM Sebastien Bacher 
wrote:

> Looks like the xserver hit an error
> BUG: triggered 'if (axnum >= dev->valuator->numAxes)'
> BUG: ../../Xi/exevents.c:2103 in InitValuatorAxisStruct()
>
> ** Summary changed:
>
> - normal usage then all apps stopped and UI dropped to desktop
> + BUG: triggered 'if (axnum >= dev->valuator->numAxes)'
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1853739
>
> Title:
>   BUG: triggered 'if (axnum >= dev->valuator->numAxes)'
>
> Status in xorg package in Ubuntu:
>   New
>
> Bug description:
>   UI stopped responding
>   ctrl +alt +f3 to htop
>   1 of the cpus at 100%
>
>   I see whoopsie is at 100%
>   then another app
>
>   ctrl +alt +f2
>   back to desktop
>
>   no apps are running
>   terminal
>   apport-bug xorg
>
>   I know running apport-bug xorg from terminal will FAIL
>
>   ubuntu 19.1 is crashing 5X per week at minimum!
>
>   ProblemType: Bug
>   DistroRelease: Ubuntu 19.10
>   Package: xorg 1:7.7+19ubuntu12
>   ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
>   Uname: Linux 5.3.0-23-generic x86_64
>   .tmp.unity_support_test.0:
>
>   ApportVersion: 2.20.11-0ubuntu8.2
>   Architecture: amd64
>   CompizPlugins: No value set for
> `/apps/compiz-1/general/screen0/options/active_plugins'
>   CompositorRunning: None
>   CurrentDesktop: ubuntu:GNOME
>   Date: Sun Nov 24 12:13:45 2019
>   DistUpgraded: 2019-10-23 09:33:56,809 ERROR got error from
> PostInstallScript ./xorg_fix_proprietary.py (g-exec-error-quark: Failed to
> execute child process “./xorg_fix_proprietary.py” (No such file or
> directory) (8))
>   DistroCodename: eoan
>   DistroVariant: ubuntu
>   ExtraDebuggingInterest: Yes, if not too technical
>   GraphicsCard:
>Intel Corporation 2nd Generation Core Processor Family Integrated
> Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller])
>  Subsystem: ASUSTeK Computer Inc. 2nd Generation Core Processor Family
> Integrated Graphics Controller [1043:84ca]
>   InstallationDate: Installed on 2015-08-23 (1553 days ago)
>   InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64
> (20150805)
>   MachineType: System manufacturer System Product Name
>   ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-23-generic
> root=UUID=155c3c3c-daa6-414c-ac3d-0f8c492592c0 ro quiet splash vt.handoff=7
>   SourcePackage: xorg
>   UpgradeStatus: Upgraded to eoan on 2019-10-23 (32 days ago)
>   dmi.bios.date: 07/21/2014
>   dmi.bios.vendor: American Megatrends Inc.
>   dmi.bios.version: 2501
>   dmi.board.asset.tag: To be filled by O.E.M.
>   dmi.board.name: P8Z77-V LX
>   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.:bvr2501:bd07/21/2014:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP8Z77-VLX:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
>   dmi.product.family: To be filled by O.E.M.
>   dmi.product.name: System Product Name
>   dmi.product.sku: SKU
>   dmi.product.version: System Version
>   dmi.sys.vendor: System manufacturer
>   version.compiz: compiz 1:0.9.14.0+19.10.20190918-0ubuntu1
>   version.libdrm2: libdrm2 2.4.99-1ubuntu1
>   version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1
>   version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.1-1ubuntu1
>   version.xserver-xorg-core: xserver-xorg-core
> 2:1.20.5+git20191008-0ubuntu1
>   version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-1
>   version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1
>   version.xserver-xorg-video-intel: xserver-xorg-video-intel
> 2:2.99.917+git20190815-1
>   version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1
>   xserver.bootTime: Mon Aug 20 17:24:57 2018
>   xserver.configfile: default
>   xserver.logfile: /var/log/Xorg.0.log
>   xserver.outputs:
>
>   xserver.version: 2:1.18.4-0ubuntu0.7
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1853739/+subscriptions
>

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

Title:
  BUG: triggered 'if (axnum >= dev->valuator->numAxes)'

Status in xorg package in Ubuntu:
  New

Bug description:
  UI stopped responding
  ctrl +alt +f3 to htop
  1 of the cpus at 100%

  I see whoopsie is at 100%
  then another app

  ctrl +alt +f2 
  back to desktop

  no apps are running
  terminal
  apport-bug xorg

  I know running apport-bug xorg from terminal will FAIL

  ubuntu 19.1 is crashing 5X per week at minimum!

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12

[Touch-packages] [Bug 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
I'm currently checking if I can build locally for quick turnaround times
of tests or if I need full LP builds every time ...

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
Uh there is something related as Ubuntu Delta:

From: Balint Reczey 
Date: Tue, 22 Oct 2019 17:10:17 +0200
Subject: test: expect mmap to fail in seccomp test on s390 and s390x

(cherry picked from commit a81f7aad9a5ddeebbce002e2da36e1dd84f51b36)
---
 src/test/test-seccomp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/test/test-seccomp.c b/src/test/test-seccomp.c
index a906070..9881768 100644
--- a/src/test/test-seccomp.c
+++ b/src/test/test-seccomp.c
@@ -489,7 +489,7 @@ static void test_memory_deny_write_execute_mmap(void) {
 assert_se(seccomp_memory_deny_write_execute() >= 0);
 
 p = mmap(NULL, page_size(), PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
-#if defined(__x86_64__) || defined(__i386__) || defined(__powerpc64__) || 
defined(__arm__) || defined(__aarch64__)
+#if defined(__x86_64__) || defined(__i386__) || defined(__powerpc64__) || 
defined(__arm__) || defined(__aarch64__) || defined(__s390__) || 
defined(__s390x__)
 assert_se(p == MAP_FAILED);
 assert_se(errno == EPERM);
 #else /* unknown architectures */


Maybe that isn't true anymore?
In any case it could explain why upstream might not see/discuss about it.
But then OTOH remember that 32bit seems to be affected the same way

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
in GDB with follow-fork-mode child I can check which call is actually
failing in the child:

It is this one:
p = mmap(NULL, page_size(), PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, 
-1,0);
assert_se(p == MAP_FAILED);

It expects a fail (due to seccomp block) but does not get that.

Take it with a grain of salt, that is the packaged binary with -Ox
optimizations.

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1845046] Re: Bluetooth headphones/speaker default to low quality headset mode and fails to switch to A2DP when selected

2019-11-25 Thread Daniel Boros
I have the same issue with PL BackBeat PRO in 19.10

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

Title:
  Bluetooth headphones/speaker default to low quality headset mode and
  fails to switch to A2DP when selected

Status in gnome-control-center package in Ubuntu:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  Whenever I turn on my headphones theyll connect to my computer but im
  able to hear the input audio from my microphone and low quality output
  audio. I have to disconnect the headphones in the bluetooth devices
  and reconnect for it to fix the problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: pulseaudio 1:11.1-1ubuntu7.2
  ProcVersionSignature: Ubuntu 5.0.0-29.31~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-29-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  litleck1398 F pulseaudio
   /dev/snd/controlC0:  litleck1398 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep 23 17:07:59 2019
  InstallationDate: Installed on 2019-09-22 (0 days ago)
  InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: pulseaudio
  Symptom: audio
  Symptom_Card: WH-1000XM3
  Symptom_Type: High background noise, or volume is too low
  Title: [WH-1000XM3, playback] Background noise or low volume
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/12/2019
  dmi.bios.vendor: Alienware
  dmi.bios.version: 1.0.19
  dmi.board.name: 01NYPT
  dmi.board.vendor: Alienware
  dmi.board.version: A00
  dmi.chassis.type: 3
  dmi.chassis.vendor: Alienware
  dmi.chassis.version: Not Specified
  dmi.modalias: 
dmi:bvnAlienware:bvr1.0.19:bd02/12/2019:svnAlienware:pnAlienwareAuroraR5:pvr1.0.19:rvnAlienware:rn01NYPT:rvrA00:cvnAlienware:ct3:cvrNotSpecified:
  dmi.product.family: Alienware
  dmi.product.name: Alienware Aurora R5
  dmi.product.sku: 0729
  dmi.product.version: 1.0.19
  dmi.sys.vendor: Alienware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1845046/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x03fffdd2b232 in __GI_abort () at abort.c:79
#2  0x03fffdb03a64 in log_assert_failed_realm () from 
/lib/systemd/libsystemd-shared-243.so
#3  0x02aa746e in test_memory_deny_write_execute_mmap () at 
../src/test/test-seccomp.c:507
#4  0x02aa2a48 in main (argc=, argv=) at 
../src/test/test-seccomp.c:987

The test is:
static void test_memory_deny_write_execute_mmap(void) {
...
if (pid == 0) {
void *p;

p = mmap(NULL, page_size(), PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
assert_se(p != MAP_FAILED);
assert_se(munmap(p, page_size()) >= 0);

p = mmap(NULL, page_size(), PROT_WRITE|PROT_READ, 
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
assert_se(p != MAP_FAILED);
assert_se(munmap(p, page_size()) >= 0);

assert_se(seccomp_memory_deny_write_execute() >= 0);

p = mmap(NULL, page_size(), PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
#if defined(__x86_64__) || defined(__i386__) || defined(__powerpc64__) || 
defined(__arm__) || defined(__aarch64__) || defined(__s390__) || 
defined(__s390x__)
assert_se(p == MAP_FAILED);
assert_se(errno == EPERM);
#else /* unknown architectures */
assert_se(p != MAP_FAILED);
assert_se(munmap(p, page_size()) >= 0);
#endif

p = mmap(NULL, page_size(), PROT_WRITE|PROT_READ, 
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
assert_se(p != MAP_FAILED);
assert_se(munmap(p, page_size()) >= 0);

_exit(EXIT_SUCCESS);
}

assert_se(wait_for_terminate_and_check("memoryseccomp-mmap",
pid, WAIT_LOG) == EXIT_SUCCESS);

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
x86 32bit is rather similar:
/* test_memory_deny_write_execute_mmap */
Operating on architecture: x86
Failed to add shmat() rule for architecture x86, skipping: Invalid argument
Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
memoryseccomp-mmap terminated by signal ABRT.
Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) == 
EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
FAIL: test-seccomp (code: 134)

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
Seems to be recreatable with
$ sudo /usr/lib/systemd/tests/test-seccomp

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
Isolated to the breaking test:
old: https://paste.ubuntu.com/p/n7BDf3Npwp/
bad: https://paste.ubuntu.com/p/5y5G4GrJYf/

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1853852] [NEW] hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

2019-11-25 Thread Christian Ehrhardt 
Public bug reported:

Hi,
I'm mostly reporting this if to one of the people watching systemd more closely 
this is in any form a known issue or if there are any hints.

I recently merged libseccomp 2.4.2 and after a few initial cleanups that worked 
well.
But on propsoed-migration I hit systemd test issues.

I have read about issues with arm NR_open defines - I had the same in
chrony - but that is fixed in libseccomp and that isn't failing in
systemd.

i386 and s390x (only those) have failing tests
- http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
- http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

Example:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

Failnig subtests are:
root-unittests   FAIL non-zero exit status 134
upstream FAIL non-zero exit status 1

And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
== test-seccomp ===
...
/* test_memory_deny_write_execute_mmap */
Operating on architecture: s390
Failed to add shmat() rule for architecture s390, skipping: Invalid argument
Operating on architecture: s390x
Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
memoryseccomp-mmap terminated by signal ABRT.
Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) == 
EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
FAIL: test-seccomp (code: 134)

But when installing source of systemd and the new libseccomp in a Focal
VM with proposed enabled it works just fine. Actually I just found that
it does have a good RC but breaks so maybe it is debuggable after all.

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

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

** Also affects: libseccomp (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more 
closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that 
worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests   FAIL non-zero exit status 134
  upstream FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: 
http://paste.ubuntu.com/p/N7q9PX3hFN/
  == test-seccomp ===
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function 
test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) 
== EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function 
test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+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 1835738] Update Released

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for python3.6 has
completed successfully and the package is now being 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 python3-defaults in
Ubuntu.
https://bugs.launchpad.net/bugs/1835738

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Released

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package python3.6 - 3.6.9-1~18.04

---
python3.6 (3.6.9-1~18.04) bionic-proposed; urgency=medium

  * SRU: LP: #1835738, backport 3.6.9 to 18.04.
  * Python 3.6.9 release.
  * Remove patches applied upstream:
- CVE-2018-20852.patch
- CVE-2019-5010.patch
- CVE-2019-9636.patch
- CVE-2019-9740.patch
- CVE-2019-9948.patch
- CVE-2019-10160-1.patch
- CVE-2019-10160-2.patch
  * Enable the lto build on arm64.

 -- Matthias Klose   Thu, 07 Nov 2019 11:44:02 +0100

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Released

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package python3.7 - 3.7.5-2~19.10

---
python3.7 (3.7.5-2~19.10) eoan-proposed; urgency=medium

  * SRU: LP: #1835738, backport 3.7.5 to 19.10.

 -- Matthias Klose   Wed, 20 Nov 2019 10:21:52 +0100

** Changed in: python3.7 (Ubuntu Eoan)
   Status: Fix Committed => Fix Released

** Changed in: python3.7 (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Released

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package python3.7 - 3.7.5-2~18.04

---
python3.7 (3.7.5-2~18.04) bionic-proposed; urgency=medium

  * SRU: LP: #1835738, backport 3.7.5 to 18.04.

python3.7 (3.7.5-2) unstable; urgency=medium

  * python3.7-dev: Depend on zlib1g-dev, needed to link as an
embedded interpreter.

python3.7 (3.7.5-1) unstable; urgency=medium

  * Python 3.7.5 release.

python3.7 (3.7.5~rc1-2) unstable; urgency=medium

  * Apply proposed patch for issue 38368. LP: #1847036. Closes: #941650.

python3.7 (3.7.5~rc1-1) unstable; urgency=medium

  * Python 3.7.5 release candidate 1.
  * Bump standards version.

python3.7 (3.7.4-4) unstable; urgency=medium

  * Update to 20190904 from the 3.7 branch.

python3.7 (3.7.4-3) unstable; urgency=medium

  * Enable pgo/lto builds on arm64. Closes: #934812.
  * Don't propagate lto flags to the _sysconfigdata module. Closes: #934771.
  * d/patches/issue35998.diff: Disable TLS1.3 in the client on all platforms
rather than just reducing the payload size (Michael Hudson-Doyle).
  * Annote build dependencies used for tests. Closes: #928513.

python3.7 (3.7.4-2) unstable; urgency=medium

  * Bump the platform name for KFreeBSD.

python3.7 (3.7.4-1) unstable; urgency=medium

  * Python 3.7.4 release.

python3.7 (3.7.4~rc2-2) unstable; urgency=medium

  * Bump standards version.

python3.7 (3.7.4~rc2-1) experimental; urgency=medium

  * Python 3.7.4 release candidate 2.

python3.7 (3.7.4~rc1-1) experimental; urgency=medium

  * Python 3.7.4 release candidate 1.

 -- Matthias Klose   Thu, 07 Nov 2019 11:50:52 +0100

** Changed in: python3.6 (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-20852

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-10160

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-5010

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-9636

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-9740

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-9948

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Released

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1835738] Re: SRU: Update Python interpreter to 3.6.9 and 3.7.5

2019-11-25 Thread Łukasz Zemczak
Thanks! I have hinted virtualbox and will no proceed with releasing
those to -updates.

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

Title:
  SRU: Update Python interpreter to 3.6.9 and 3.7.5

Status in python3-defaults package in Ubuntu:
  New
Status in python3-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-stdlib-extensions source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python3-defaults source package in Disco:
  New
Status in python3-stdlib-extensions source package in Disco:
  Fix Released
Status in python3.7 source package in Disco:
  New
Status in python3-defaults source package in Eoan:
  New
Status in python3-stdlib-extensions source package in Eoan:
  Fix Released
Status in python3.7 source package in Eoan:
  Fix Released

Bug description:
  Update Python interpreter to 3.6.9 and 3.7.5.  As done with earlier
  subminor upstream releases (LP: #1822993).

  SRU: update Python 3.7 to the 3.7.5 release, update Python 3.6 to the
  3.6.9 release.

  python3-stdlib-extensions also updates the modules to the 3.6.9
  release for Python 3.6.

  Acceptance Criteria: The package builds, and the test suite doesn't
  show regressions. The test suite passes in the autopkg tests. The new
  packages don't cause regressions in a test rebuild of the main
  component.

  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191018-release-tst-bionic.html

  The test rebuilds are finished, and don't show any regressions for the
  main component.

  Regression Potential: Python 3.7 isn't used by default, so we don't have many 
default users.
  Regression Potential: Python 3.6 could see some regressions, although we are 
trying to minimize the risk by doing the test rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+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 1853825] Re: ^W ^G ^X fails to redisplay the text being edited

2019-11-25 Thread Ubuntu Foundations Team Bug Bot
The attachment "fix display bug after invoking ^G help" seems to be a
patch.  If it isn't, please remove the "patch" flag from the attachment,
remove the "patch" tag, and if you are a member of the ~ubuntu-
reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

** Tags added: patch

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

Title:
  ^W ^G ^X fails to redisplay the text being edited

Status in nano package in Ubuntu:
  New

Bug description:
  There is a silly display bug in nano-4.3
  (https://savannah.gnu.org/bugs/?57295): when opening some file (for
  example, 'nano README') and typing the sequence Ctrl+W Ctrl+G Ctrl+X,
  the Search help text stays on the screen whereas the text of the
  README file should be redisplayed.  Attached upstream patch fixes
  this.  Please apply to Eoan.

  (It could be applied to Focal too, but nano-4.6 will be out within a
  week, so it's probably not worth the effort.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1853825/+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 1840640] Re: sync_file_range fails in nspawn containers on arm, ppc

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1840640

Title:
  sync_file_range fails in nspawn containers on arm, ppc

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [impact]

  calling the glibc function sync_file_range() on a armhf nspawn
  container fails.

  [test case]

  see sample C program from original description below.  compile and run
  that inside a nspawn container on armhf and it will fail.

  nspawn instructions:
  sudo apt install debootstrap systemd-container
  sudo -i
  debootstrap --arch=armhf bionic ~/bionic-tree/
  systemd-nspawn -D ~/bionic-tree/

  [regression potential]

  this only adjusts nspawn to allow the sync_file_range2 syscall which
  is used on armhf, so the regression potential is very low.  any
  possible regressions would likely be when calling sync_file_range().

  [other info]

  original description:
  ---

  ARM has two sync_file_range syscalls, sync_file_range and
  sync_file_range2. The former is apparently not used, and glibc calls
  the latter whenever a userspace program calls sync_file_range. I'm
  guessing systemd-nspawn doesn't know this, because the follow code
  consistently fails in an nspawn container on ARM:

  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 

  void main()
  {
  int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
  int r=sync_file_range(f, 0, 0, 0);
  if (r)
  perror("sync_file_range");
  close(f);
  }

  This seems to be causing problems specifically for borg(backup) and
  postgres:

  https://github.com/borgbackup/borg/issues/4710
  
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93

  The solution should be to cherrypick
  https://github.com/systemd/systemd/pull/13352, I am currently waiting
  for systemd to rebuild on a slow ARM box. Any chance of an SRU?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd-container 237-3ubuntu10.24
  Uname: Linux 4.14.66+ armv7l
  NonfreeKernelModules: extcon_usb_gpio
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: armhf
  Date: Mon Aug 19 11:10:48 2019
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1843381

Title:
  Dell system takes a long time to connect network with external dock

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Invalid

Bug description:
  [impact]

  On Dell system with BIOS-based "MAC passthrough", there can be
  multiple USB nics with identical MAC addresses.  Since the udev rules
  in Debian and Ubuntu assign interface names for USB nics by mac
  address (because that is the only consistent identifier for USB nics;
  their path can change based on which USB port they are connected to),
  it's impossible to name two interfaces with the same name.  As Ubuntu
  also carries a patch to retry renaming of any interface when the first
  renaming fails, this causes a 90 second delay before being able to the
  "MAC passthrough" nic after connecting it.

  [test case]

  On a system with this "MAC passthrough" enabled and required devices,
  boot the system and then connect to the dock or connect the second USB
  nic with identical MAC.  It will not be usable for 90 seconds as its
  renames takes that long to timeout.

  [regression potential]

  the change here is very limited to only Dell systems with the specific
  USB vendor/product ID affected by this, and additionally the change
  only sets a ENV flag in the udev rule, which is later used by udevd to
  skip the rename-retries for 90 seconds.  So, the regression potential
  for anyone else without a system affected by this "MAC passthrough"
  should be very low, and any regression potential for those with this
  "MAC passthrough" should still be low, as this only skips the rename-
  retry that we know will never succeed.

  However, the regression potential is likely limited to failure to
  properly name a USB nic, or other bugs during the udev processing of
  new USB nics.

  [other info]

  original description:
  ---

  
  This is a bug reopen from
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700
  The original one caused systemd regressed.
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651

  This issue needs an alternative solution.
  

  Dell has a feature called MAC addrss passthrough[1] that would force usb 
ethernet adapters to be assigned with a predefined MAC address stored in BIOS 
or so. This feature has been landed to mainline kernel in driver r8152[2]. So 
whenever a r8152 managed device is plugged into Dell devices with MAC addrss 
passthrough enabled, this driver will set NIC MAC to a predefined one.

  And some Dell devices have already one built-in r8152 NIC port. On
  these devices, when a second r8152 NIC is plugged in, a Debian
  originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev
  built-in command `net_id` to give a persistent name, and that will be
  based on MAC address. However, since the system has already
  initialized the built-in r8152 NIC with that name, renaming the second
  interface with this name will always fail.

  While Debian still carries a patch called "Revert-udev-network-device-
  renaming-immediately-give.patch"[4] that tries to keep support of
  already deprecated "75-persistent-net-generator.rules" based interface
  renaming mechanism, this patch also propagated into Ubuntu[5]. This
  patch will retry renaming with a 90 seconds timeout when the error
  code is -EEXIST, so the uevent processing will always be blocked in
  the last ifrename step in the victim system.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules 
lib/udev/rules.d/50-udev-default.rules 
lib/udev/rules.d/73-special-net-names.rules 
lib/udev/rules.d/73-usb-net-by-mac.rules]
  ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18
  Uname: Linux 4.15.0-1043-oem x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules
  Date: Wed Jul 24 15:30:59 2019
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 

[Touch-packages] [Bug 1845337] Update Released

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1845337

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in qemu source package in Disco:
  Invalid
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [impact]

  due to a recent change to allow armhf tests to run lxd containers,
  autopkgtest for systemd on disco fails consistently.

  [test case]

  see test results, linked in original description below.

  [regression potential]

  very low, autopkgtest fix only.

  [other info]

  original description:
  ---

  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1805183

Title:
  systemd-resolved constantly restarts on Bionic upgraded from Xenial

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  Log noise due to needless restart of resolved on lease expiry, maybe loss of 
cached state?
  Application that require Name Resolution may fail while the service is being 
unnecessarily restarted

  [Test case]
  (1) Append make_resolv_conf to the end of the file, so it gets executed
  (2) Execute the file with bash -x and different settings and ensure there are 
no restarts if the settings are the same, and that there are if settings 
change; for example:

  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => no restart
  sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => should restart
  sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => no restart
  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => should restart

  [Regression potential]
  The change only restarts resolved when the settings change. If there's a bug 
in the logic, resolved might not be restarted when it should be. Also, since 
there will be less restarts of resolved, it will run longer, so if there are 
memory leaks they will become more apparent.

  [other info]

  this fix was included in the initial release of systemd for eoan, but
  the fix required the additional change in bug 1849608.  Both the
  original patch plus that change (to avoid using bash-specific &>) are
  included in the b/d patch for this bug.

  [Original bug report]
  If a cloud server is upgraded from Xenial to Bionic, the dhclient system 
remains in place and any DHCP lease refreshes cause a needless restart of the 
system-resolved daemon

  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on 
ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d)
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 
10.226.209.105
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors:
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 
49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 

[Touch-packages] [Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1796501

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [impact]

  an NXDOMAIN response from a dns server when systemd-resolved is
  configured as DNSSEC=yes breaks dns resolution as it downgrades from
  DNSSEC.

  [test case]

  see comment 9

  [regression potential]

  as with the original patch that introduced this problem, this has the
  potential to break dns resolution.

  [other info]

  original description:

  
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

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

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1805183

Title:
  systemd-resolved constantly restarts on Bionic upgraded from Xenial

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  Log noise due to needless restart of resolved on lease expiry, maybe loss of 
cached state?
  Application that require Name Resolution may fail while the service is being 
unnecessarily restarted

  [Test case]
  (1) Append make_resolv_conf to the end of the file, so it gets executed
  (2) Execute the file with bash -x and different settings and ensure there are 
no restarts if the settings are the same, and that there are if settings 
change; for example:

  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => no restart
  sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => should restart
  sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => no restart
  sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash 
-x debian/extra/dhclient-enter-resolved-hook
  => should restart

  [Regression potential]
  The change only restarts resolved when the settings change. If there's a bug 
in the logic, resolved might not be restarted when it should be. Also, since 
there will be less restarts of resolved, it will run longer, so if there are 
memory leaks they will become more apparent.

  [other info]

  this fix was included in the initial release of systemd for eoan, but
  the fix required the additional change in bug 1849608.  Both the
  original patch plus that change (to avoid using bash-specific &>) are
  included in the b/d patch for this bug.

  [Original bug report]
  If a cloud server is upgraded from Xenial to Bionic, the dhclient system 
remains in place and any DHCP lease refreshes cause a needless restart of the 
system-resolved daemon

  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on 
ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d)
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 
10.226.209.105
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors:
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 
49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 
10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 
'srv-qvjhx'.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting 
resolvconf-pull-resolved.service...
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal 
in 1466 seconds.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Started 
resolvconf-pull-resolved.service.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ubuntu-release-upgrader-core 1:16.04.25
  ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160
  Uname: Linux 4.4.0-139-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CrashDB: ubuntu
  Date: Mon Nov 26 16:17:52 2018
  PackageArchitecture: all
  SourcePackage: ubuntu-release-upgrader
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1849733] Re: resolved incorrectly limits TCP reply to edns0 payload

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1849733

Title:
  resolved incorrectly limits TCP reply to edns0 payload

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its
  payload limit to 1200.  When the response is larger than 1200,
  resolved will limit the response and set the truncate flag.  This
  causes getaddrinfo() to switch to TCP and request again, but glibc
  incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit.
  Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC
  it applies only to UDP, but resolved does not and again marks the
  response as truncated.  This prevents getaddrinfo() from being able to
  resolve any records with a response over 1200 bytes.

  [test case]

  use ping or telnet, which use getaddrinfo(), to lookup an A record
  with a lot of results, like toomany100.ddstreet.org

  $ telnet toomany100.ddstreet.org
  telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure 
in name resolution

  [regression potential]

  any regression would likely result in failure to correctly lookup a
  hostname or to provide the correct response to a local client.

  [other info]

  note that on Bionic, this also requires backporting TCP pipelining
  support in the stub resolver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+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 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1845337

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in qemu source package in Disco:
  Invalid
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [impact]

  due to a recent change to allow armhf tests to run lxd containers,
  autopkgtest for systemd on disco fails consistently.

  [test case]

  see test results, linked in original description below.

  [regression potential]

  very low, autopkgtest fix only.

  [other info]

  original description:
  ---

  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1847527] Re: Backport systemd-journal-remote fix PR #11953

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1847527

Title:
  Backport systemd-journal-remote fix PR #11953

Status in openstack-ansible:
  New
Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  upstream commit 7fdb237f5473cb8fc2129e57e8a0039526dcb4fd broke remote journal 
upload, because it added a check to verify the Content-Length header, but the 
upload may use Transfer-Encoding of 'chunked' which does
  not specify Content-Length.

  [test case]

  setup 2 systems, A and B.  Install systemd-journal-remote on both.

  On A:

  $ sudo systemctl edit systemd-journal-remote.service

  in the editor, add:

  [Service]
  ExecStart=
  ExecStart=/lib/systemd/systemd-journal-remote --listen-http=-3 
--output=/var/log/journal/remote/

  
  Then enable/start the socket:

  $ sudo systemctl enable systemd-journal-remote.socket
  $ sudo systemctl start systemd-journal-remote.socket

  Optionally, start the service and verify it is running (not required,
  since the socket will start the service):

  $ sudo systemctl start systemd-journal-remote.service
  $ sudo systemctl status systemd-journal-remote.service | grep Active
 Active: active (running) since Thu 2019-11-14 20:08:48 UTC; 7min ago

  
  On B:

  Edit the file /etc/systemd/journal-upload.conf:

  [Upload]
  URL=http://192.168.122.184:19532

  
  Replacing the IP address with the actual ip addr of node A.  Then 
enable/start the service:

  $ sudo systemctl enable systemd-journal-upload.service
  $ sudo systemctl start systemd-journal-upload.service

  Check for failure:

  ubuntu@lp1847527-d:~$ journalctl -b -u systemd-journal-upload.service 
  -- Logs begin at Thu 2019-11-14 16:34:08 UTC, end at Thu 2019-11-14 20:19:34 
UTC. --
  Nov 14 20:19:03 lp1847527-d systemd[1]: Started Journal Remote Upload Service.
  Nov 14 20:19:03 lp1847527-d systemd-journal-upload[721]: Upload to 
http://192.168.122.184:19532/upload failed with code 411: gth Required
  Nov 14 20:19:03 lp1847527-d systemd[1]: systemd-journal-upload.service: Main 
process exited, code=exited, status=1/FAILURE
  Nov 14 20:19:03 lp1847527-d systemd[1]: systemd-journal-upload.service: 
Failed with result 'exit-code'.

  
  [regression potential]

  this limits the Transfer-Encoding to only be either unspecified, or
  'chunked'.  Any other value will fail.  However, journal-upload.c does
  not ever use any other Transfer-Encoding than 'chunked', and this fix
  comes from upstream and has not changed since applied there.

  Any regression would likely result in the failure to upload a remote
  journal.

  [other info]

  the commit that caused this is not included in Bionic, and the commit
  to fix this is already in Eoan; this is needed only in Disco.

  original description:
  --

  I'm requesting that systemd 240 receive the fix in upstream PR 11953
  found here https://github.com/systemd/systemd/pull/11953

  This fixes remote journal shipping using systemd components. I believe

[Touch-packages] [Bug 1796501] Update Released

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1796501

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [impact]

  an NXDOMAIN response from a dns server when systemd-resolved is
  configured as DNSSEC=yes breaks dns resolution as it downgrades from
  DNSSEC.

  [test case]

  see comment 9

  [regression potential]

  as with the original patch that introduced this problem, this has the
  potential to break dns resolution.

  [other info]

  original description:

  
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

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

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1840640

Title:
  sync_file_range fails in nspawn containers on arm, ppc

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [impact]

  calling the glibc function sync_file_range() on a armhf nspawn
  container fails.

  [test case]

  see sample C program from original description below.  compile and run
  that inside a nspawn container on armhf and it will fail.

  nspawn instructions:
  sudo apt install debootstrap systemd-container
  sudo -i
  debootstrap --arch=armhf bionic ~/bionic-tree/
  systemd-nspawn -D ~/bionic-tree/

  [regression potential]

  this only adjusts nspawn to allow the sync_file_range2 syscall which
  is used on armhf, so the regression potential is very low.  any
  possible regressions would likely be when calling sync_file_range().

  [other info]

  original description:
  ---

  ARM has two sync_file_range syscalls, sync_file_range and
  sync_file_range2. The former is apparently not used, and glibc calls
  the latter whenever a userspace program calls sync_file_range. I'm
  guessing systemd-nspawn doesn't know this, because the follow code
  consistently fails in an nspawn container on ARM:

  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 

  void main()
  {
  int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
  int r=sync_file_range(f, 0, 0, 0);
  if (r)
  perror("sync_file_range");
  close(f);
  }

  This seems to be causing problems specifically for borg(backup) and
  postgres:

  https://github.com/borgbackup/borg/issues/4710
  
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93

  The solution should be to cherrypick
  https://github.com/systemd/systemd/pull/13352, I am currently waiting
  for systemd to rebuild on a slow ARM box. Any chance of an SRU?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd-container 237-3ubuntu10.24
  Uname: Linux 4.14.66+ armv7l
  NonfreeKernelModules: extcon_usb_gpio
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: armhf
  Date: Mon Aug 19 11:10:48 2019
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640/+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 1843381] Re: Dell system takes a long time to connect network with external dock

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1843381

Title:
  Dell system takes a long time to connect network with external dock

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Invalid

Bug description:
  [impact]

  On Dell system with BIOS-based "MAC passthrough", there can be
  multiple USB nics with identical MAC addresses.  Since the udev rules
  in Debian and Ubuntu assign interface names for USB nics by mac
  address (because that is the only consistent identifier for USB nics;
  their path can change based on which USB port they are connected to),
  it's impossible to name two interfaces with the same name.  As Ubuntu
  also carries a patch to retry renaming of any interface when the first
  renaming fails, this causes a 90 second delay before being able to the
  "MAC passthrough" nic after connecting it.

  [test case]

  On a system with this "MAC passthrough" enabled and required devices,
  boot the system and then connect to the dock or connect the second USB
  nic with identical MAC.  It will not be usable for 90 seconds as its
  renames takes that long to timeout.

  [regression potential]

  the change here is very limited to only Dell systems with the specific
  USB vendor/product ID affected by this, and additionally the change
  only sets a ENV flag in the udev rule, which is later used by udevd to
  skip the rename-retries for 90 seconds.  So, the regression potential
  for anyone else without a system affected by this "MAC passthrough"
  should be very low, and any regression potential for those with this
  "MAC passthrough" should still be low, as this only skips the rename-
  retry that we know will never succeed.

  However, the regression potential is likely limited to failure to
  properly name a USB nic, or other bugs during the udev processing of
  new USB nics.

  [other info]

  original description:
  ---

  
  This is a bug reopen from
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700
  The original one caused systemd regressed.
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651

  This issue needs an alternative solution.
  

  Dell has a feature called MAC addrss passthrough[1] that would force usb 
ethernet adapters to be assigned with a predefined MAC address stored in BIOS 
or so. This feature has been landed to mainline kernel in driver r8152[2]. So 
whenever a r8152 managed device is plugged into Dell devices with MAC addrss 
passthrough enabled, this driver will set NIC MAC to a predefined one.

  And some Dell devices have already one built-in r8152 NIC port. On
  these devices, when a second r8152 NIC is plugged in, a Debian
  originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev
  built-in command `net_id` to give a persistent name, and that will be
  based on MAC address. However, since the system has already
  initialized the built-in r8152 NIC with that name, 

[Touch-packages] [Bug 1847815] Update Released

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1847815

Title:
  storage autopkgtest is flaky

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  Invalid
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  the systemd autopkgtest 'storage' is flaky.

  [test case]

  look at the autopkgtest test log and see some of them are failures due
  to failing 'storage' test; on re-running the test is passes.

  [regression potential]

  only an autopkgtest fix; very low if any.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847815/+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 1849658] Re: resolved fallback to TCP fails for truncated UDP replies

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1849658

Title:
  resolved fallback to TCP fails for truncated UDP replies

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  for DNS UDP replies larger than 512 bytes, fallback to TCP is used.
  For example 'host toomany.ddstreet.org'.

  Due to a bug in resolved in refcounting DNS stream types, the refcount
  underflows for type 0 streams (which resolved uses to talk to upstream
  nameservers), resulting in resolved being unable to fallback to TCP to
  handle truncated UDP replies.

  [test case]

  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
  ;; Truncated, retrying in TCP mode.

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;toomany.ddstreet.org.IN  A

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Thu Oct 24 11:40:29 UTC 2019
  ;; MSG SIZE  rcvd: 678

  ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches
  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  [regression potential]

  very low, as this only properly sets the stream type in the DnsStream
  object; any regression would be a failure to be able to use TCP for
  DNS requests or replies.

  [other info]

  https://github.com/systemd/systemd/pull/13838

  The commit adding stream types is not present in x/b, so this is
  needed only for disco and later.

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

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1847527

Title:
  Backport systemd-journal-remote fix PR #11953

Status in openstack-ansible:
  New
Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  upstream commit 7fdb237f5473cb8fc2129e57e8a0039526dcb4fd broke remote journal 
upload, because it added a check to verify the Content-Length header, but the 
upload may use Transfer-Encoding of 'chunked' which does
  not specify Content-Length.

  [test case]

  setup 2 systems, A and B.  Install systemd-journal-remote on both.

  On A:

  $ sudo systemctl edit systemd-journal-remote.service

  in the editor, add:

  [Service]
  ExecStart=
  ExecStart=/lib/systemd/systemd-journal-remote --listen-http=-3 
--output=/var/log/journal/remote/

  
  Then enable/start the socket:

  $ sudo systemctl enable systemd-journal-remote.socket
  $ sudo systemctl start systemd-journal-remote.socket

  Optionally, start the service and verify it is running (not required,
  since the socket will start the service):

  $ sudo systemctl start systemd-journal-remote.service
  $ sudo systemctl status systemd-journal-remote.service | grep Active
 Active: active (running) since Thu 2019-11-14 20:08:48 UTC; 7min ago

  
  On B:

  Edit the file /etc/systemd/journal-upload.conf:

  [Upload]
  URL=http://192.168.122.184:19532

  
  Replacing the IP address with the actual ip addr of node A.  Then 
enable/start the service:

  $ sudo systemctl enable systemd-journal-upload.service
  $ sudo systemctl start systemd-journal-upload.service

  Check for failure:

  ubuntu@lp1847527-d:~$ journalctl -b -u systemd-journal-upload.service 
  -- Logs begin at Thu 2019-11-14 16:34:08 UTC, end at Thu 2019-11-14 20:19:34 
UTC. --
  Nov 14 20:19:03 lp1847527-d systemd[1]: Started Journal Remote Upload Service.
  Nov 14 20:19:03 lp1847527-d systemd-journal-upload[721]: Upload to 
http://192.168.122.184:19532/upload failed with code 411: gth Required
  Nov 14 20:19:03 lp1847527-d systemd[1]: systemd-journal-upload.service: Main 
process exited, code=exited, status=1/FAILURE
  Nov 14 20:19:03 lp1847527-d systemd[1]: systemd-journal-upload.service: 
Failed with result 'exit-code'.

  
  [regression potential]

  this limits the Transfer-Encoding to only be either unspecified, or
  'chunked'.  Any other value will fail.  However, journal-upload.c does
  not ever use any other Transfer-Encoding than 'chunked', and this fix
  comes from upstream and has not changed since applied there.

  Any regression would likely result in the failure to upload a remote
  journal.

  [other info]

  the commit that caused this is not included in Bionic, and the commit
  to fix this is already in Eoan; this is needed only in Disco.

  original description:
  --

  I'm requesting that systemd 240 receive the fix in upstream PR 11953
  found here https://github.com/systemd/systemd/pull/11953

  This fixes remote journal shipping using systemd components. I believe
  only Disco (19.04) is impacted by this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1847527/+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 1847815] Re: storage autopkgtest is flaky

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 240-6ubuntu5.8

---
systemd (240-6ubuntu5.8) disco; urgency=medium

  [ Victor Tapia ]
  * d/p/resolved_disable-connection-downgrade-when-DNSSEC-yes.patch
Fix regression introduced by
resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch when
DNSSEC=yes (LP: #1796501)

  [ Dan Streetman ]
  * d/p/lp1840640-shared-seccomp-add-sync_file_range2.patch:
allow sync_file_range2 in nspawn container (LP: #1840640)
  * d/p/lp1847527-journal-remote-do-not-request-Content-Length-if-Tran.patch:
do not request Content-Length if Transfer-Encoding is chunked
(LP: #1847527)
  * d/t/storage: fix flaky test
(LP: #1847815)
  * d/p/lp1843381-dell_passthrough_skip_rename_retry.patch,
debian/extra/rules/73-usb-net-by-mac.rules:
fix rename delay for systems using "Dell MAC passthrough"
(LP: #1843381)
  * 
d/p/lp1849733/0001-resolved-if-we-can-t-append-EDNS-OPT-RR-then-indicat.patch,
d/p/lp1849733/0002-resolved-don-t-let-EDNS0-OPT-dgram-size-affect-TCP.patch:
ignore EDNS0 payload limit when responding over TCP (LP: #1849733)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook:
- only restart resolved if dhclient conf changed (LP: #1805183)

  [ Balint Reczey ]
  * d/p/test-execute-Filter-dev-.lxc-in-exec-dynamicuser-statedir.patch:
fix test breakage due to running in nested lxd container
(LP: #1845337)

 -- Dan Streetman   Fri, 04 Oct 2019 09:06:58
-0400

** Changed in: systemd (Ubuntu Disco)
   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/1847815

Title:
  storage autopkgtest is flaky

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  Invalid
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  the systemd autopkgtest 'storage' is flaky.

  [test case]

  look at the autopkgtest test log and see some of them are failures due
  to failing 'storage' test; on re-running the test is passes.

  [regression potential]

  only an autopkgtest fix; very low if any.

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

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1849733

Title:
  resolved incorrectly limits TCP reply to edns0 payload

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its
  payload limit to 1200.  When the response is larger than 1200,
  resolved will limit the response and set the truncate flag.  This
  causes getaddrinfo() to switch to TCP and request again, but glibc
  incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit.
  Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC
  it applies only to UDP, but resolved does not and again marks the
  response as truncated.  This prevents getaddrinfo() from being able to
  resolve any records with a response over 1200 bytes.

  [test case]

  use ping or telnet, which use getaddrinfo(), to lookup an A record
  with a lot of results, like toomany100.ddstreet.org

  $ telnet toomany100.ddstreet.org
  telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure 
in name resolution

  [regression potential]

  any regression would likely result in failure to correctly lookup a
  hostname or to provide the correct response to a local client.

  [other info]

  note that on Bionic, this also requires backporting TCP pipelining
  support in the stub resolver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+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 1853828] [NEW] [OptiPlex 3050, Realtek ALC3234, Black Headphone Out, Front] No sound at all

2019-11-25 Thread Tadeu Oliveira
Public bug reported:

As soon as I've booted my ubuntu 19.10, I've plugged my headphones and
got some clicking sound, but then there was no sound at all afterwards.

The device shows on Settings > Output and it's detected by alsamixer
also.

The headphone works normally on my phone.

This is the first time I've booted ubuntu since I've updated it (not
considering when you have to do so for the installing process). Sound
worked normally back then.

Only sound I hear is the clicking sound whenever I plug it in and off.

Headphone is at maximum gain on alsamixer.

HW info shows at title.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
Uname: Linux 5.3.0-23-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC0:  tadeu  1556 F pulseaudio
  tadeu  5159 F alsamixer
 /dev/snd/pcmC0D0p:   tadeu  1556 F...m pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Mon Nov 25 07:51:05 2019
InstallationDate: Installed on 2019-03-27 (242 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed
Symptom_Card: Built-in Audio - HDA Intel PCH
Symptom_DevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC0:  tadeu  1556 F pulseaudio
  tadeu  5159 F alsamixer
 /dev/snd/pcmC0D0p:   tadeu  1556 F...m pulseaudio
Symptom_Jack: Black Headphone Out, Front
Symptom_Type: No sound at all
Title: [OptiPlex 3050, Realtek ALC3234, Black Headphone Out, Front] No sound at 
all
UpgradeStatus: Upgraded to eoan on 2019-11-22 (3 days ago)
dmi.bios.date: 08/09/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.10.2
dmi.board.name: 0JP3NX
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias: 
dmi:bvnDellInc.:bvr1.10.2:bd08/09/2018:svnDellInc.:pnOptiPlex3050:pvr:rvnDellInc.:rn0JP3NX:rvrA01:cvnDellInc.:ct3:cvr:
dmi.product.family: OptiPlex
dmi.product.name: OptiPlex 3050
dmi.product.sku: 07A3
dmi.sys.vendor: Dell Inc.

** Affects: alsa-driver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug eoan

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

Title:
  [OptiPlex 3050, Realtek ALC3234, Black Headphone Out, Front] No sound
  at all

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  As soon as I've booted my ubuntu 19.10, I've plugged my headphones and
  got some clicking sound, but then there was no sound at all
  afterwards.

  The device shows on Settings > Output and it's detected by alsamixer
  also.

  The headphone works normally on my phone.

  This is the first time I've booted ubuntu since I've updated it (not
  considering when you have to do so for the installing process). Sound
  worked normally back then.

  Only sound I hear is the clicking sound whenever I plug it in and off.

  Headphone is at maximum gain on alsamixer.

  HW info shows at title.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  tadeu  1556 F pulseaudio
tadeu  5159 F alsamixer
   /dev/snd/pcmC0D0p:   tadeu  1556 F...m pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Nov 25 07:51:05 2019
  InstallationDate: Installed on 2019-03-27 (242 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  tadeu  1556 F pulseaudio
tadeu  5159 F alsamixer
   /dev/snd/pcmC0D0p:   tadeu  1556 F...m pulseaudio
  Symptom_Jack: Black Headphone Out, Front
  Symptom_Type: No sound at all
  Title: [OptiPlex 3050, Realtek ALC3234, Black Headphone Out, Front] No sound 
at all
  UpgradeStatus: Upgraded to eoan on 2019-11-22 (3 days ago)
  dmi.bios.date: 08/09/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.10.2
  dmi.board.name: 0JP3NX
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 

[Touch-packages] [Bug 1853825] [NEW] ^W ^G ^X fails to redisplay the text being edited

2019-11-25 Thread Benno Schulenberg
Public bug reported:

There is a silly display bug in nano-4.3
(https://savannah.gnu.org/bugs/?57295): when opening some file (for
example, 'nano README') and typing the sequence Ctrl+W Ctrl+G Ctrl+X,
the Search help text stays on the screen whereas the text of the README
file should be redisplayed.  Attached upstream patch fixes this.  Please
apply to Eoan.

(It could be applied to Focal too, but nano-4.6 will be out within a
week, so it's probably not worth the effort.)

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


** Tags: eoan

** Patch added: "fix display bug after invoking ^G help"
   
https://bugs.launchpad.net/bugs/1853825/+attachment/5307655/+files/0001-display-do-refresh-the-edit-window-when-exiting-from.patch

** Tags added: eoan

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

Title:
  ^W ^G ^X fails to redisplay the text being edited

Status in nano package in Ubuntu:
  New

Bug description:
  There is a silly display bug in nano-4.3
  (https://savannah.gnu.org/bugs/?57295): when opening some file (for
  example, 'nano README') and typing the sequence Ctrl+W Ctrl+G Ctrl+X,
  the Search help text stays on the screen whereas the text of the
  README file should be redisplayed.  Attached upstream patch fixes
  this.  Please apply to Eoan.

  (It could be applied to Focal too, but nano-4.6 will be out within a
  week, so it's probably not worth the effort.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1853825/+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 1815101] Update Released

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1815101

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in Keepalived Charm:
  New
Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Won't Fix
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in keepalived source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in keepalived source package in Eoan:
  In Progress
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  - ALL related HA software has a small problem if interfaces are being
  managed by systemd-networkd: nic restarts/reconfigs are always going
  to wipe all interfaces aliases when HA software is not expecting it to
  (no coordination between them.

  - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
  smarter in this case because it has a service monitor that will
  restart the virtual IP resource, in affected node & nic, before
  considering a real failure, but other HA service might consider a real
  failure when it is not.

  [test case]

  - comment #14 is a full test case: to have 3 node pacemaker, in that
  example, and cause a networkd service restart: it will trigger a
  failure for the virtual IP resource monitor.

  - other example is given in the original description for keepalived.
  both suffer from the same issue (and other HA softwares as well).

  [regression potential]

  - this backports KeepConfiguration parameter, which adds some
  significant complexity to networkd's configuration and behavior, which
  could lead to regressions in correctly configuring the network at
  networkd start, or incorrectly maintaining configuration at networkd
  restart, or losing network state at networkd stop.

  - Any regressions are most likely to occur during networkd start,
  restart, or stop, and most likely to involve missing or incorrect ip
  address(es).

  - the change is based in upstream patches adding the exact feature we
  needed to fix this issue & it will be integrated with a netplan change
  to add the needed stanza to systemd nic configuration file
  (KeepConfiguration=)

  [other info]

  original description:
  ---

  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth2:
  addresses:
    - 12.13.14.18/29
    - 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
     

[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 242-7ubuntu3.2

---
systemd (242-7ubuntu3.2) eoan; urgency=medium

  [ Dan Streetman ]
  * d/extra/dhclient-enter-resolved-hook:
- Replace use of bash-only &> with > and 2> (LP: #1849608)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook: cleanup temp $newstate file

  [ Rafael David Tinoco ]
  * Add support to KeepConfiguration= fixing behaviour for HA (LP: #1815101)
- d/p/lp1815101-01-networkd-add-support-to-keep-configuration.patch
- d/p/lp1815101-02-networkd-stop-clients-when-networkd-shuts-down.patch
- d/p/lp1815101-03-network-add-KeepConfiguration-dhcp-on-stop.patch
- 
d/p/lp1815101-04-network-make-KeepConfiguration-static-drop-DHCP-addr.patch
- d/p/lp1815101-05-man-add-documentation-about-KeepConfiguration.patch

systemd (242-7ubuntu3.1) eoan; urgency=medium

  [ Balint Reczey ]
  * Fix shutdown and related actions from the login screen (LP: #1847896)
File: 
debian/patches/logind-consider-greeter-sessions-suitable-as-display-sess.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b407dfd8c9dc81594553c27467c35b38d74c
  * debian/gbp.conf: Set debian-branch to ubuntu-eoan
File: debian/gbp.conf

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f399ce2cf4701a2dbb4b3505d2dd17a210d62f5c

  [ Dan Streetman ]
  * Fix bogus routes after DHCP lease change (LP: #1831787)
Files:
- 
debian/patches/lp1831787/0001-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch
- 
debian/patches/lp1831787/0002-network-set-preferred-source-in-removing-route-entry.patch
- 
debian/patches/lp1831787/0003-network-lower-log-level-about-critical-connection.patch
- 
debian/patches/lp1831787/0004-network-reset-Link-dhcp4_configured-flag-earlier.patch
- 
debian/patches/lp1831787/0005-network-split-dhcp_lease_lost-into-small-pieces.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ced3f5c2f619083f7beb164d94d4ccfe5fe8
  * Set src address for dhcp 'classless' routes (LP: #1835581)
File: 
debian/patches/lp1835581-src-network-networkd-dhcp4.c-set-prefsrc-for-classle.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6a7ef370fb1335548448920be4ae6176b67044a8
  * Allows cache=no-negative option to be set, ignoring negative answers to
be cached (LP: #1668771)
File: 
debian/patches/lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=27def26f5b1d1b8ba314c4a925fc1b7c43837f86

 -- Dan Streetman   Fri, 01 Nov 2019 16:33:08
-0400

** Changed in: systemd (Ubuntu Eoan)
   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/1815101

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in Keepalived Charm:
  New
Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Won't Fix
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in keepalived source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in keepalived source package in Eoan:
  In Progress
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  - ALL related HA software has a small problem if interfaces are being
  managed by systemd-networkd: nic restarts/reconfigs are always going
  to wipe all interfaces aliases when HA software is not expecting it to
  (no coordination between them.

  - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
  smarter in this case because it has a service monitor that will
  restart the virtual IP resource, in affected node & nic, before
  considering a real failure, but other HA service might consider a real
  failure when it is not.

  [test case]

  - comment #14 is a full test case: to have 3 node pacemaker, in that
  example, and cause a networkd service restart: it will trigger a
  failure for the virtual IP resource monitor.

  - other example is given in the original description for keepalived.
  both suffer from the same issue (and other HA softwares as well).

  [regression potential]

  - this backports KeepConfiguration parameter, which adds some
  significant complexity to networkd's configuration and behavior, which
  could lead to regressions in correctly configuring the network at
  networkd start, or incorrectly maintaining 

[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 242-7ubuntu3.2

---
systemd (242-7ubuntu3.2) eoan; urgency=medium

  [ Dan Streetman ]
  * d/extra/dhclient-enter-resolved-hook:
- Replace use of bash-only &> with > and 2> (LP: #1849608)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook: cleanup temp $newstate file

  [ Rafael David Tinoco ]
  * Add support to KeepConfiguration= fixing behaviour for HA (LP: #1815101)
- d/p/lp1815101-01-networkd-add-support-to-keep-configuration.patch
- d/p/lp1815101-02-networkd-stop-clients-when-networkd-shuts-down.patch
- d/p/lp1815101-03-network-add-KeepConfiguration-dhcp-on-stop.patch
- 
d/p/lp1815101-04-network-make-KeepConfiguration-static-drop-DHCP-addr.patch
- d/p/lp1815101-05-man-add-documentation-about-KeepConfiguration.patch

systemd (242-7ubuntu3.1) eoan; urgency=medium

  [ Balint Reczey ]
  * Fix shutdown and related actions from the login screen (LP: #1847896)
File: 
debian/patches/logind-consider-greeter-sessions-suitable-as-display-sess.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b407dfd8c9dc81594553c27467c35b38d74c
  * debian/gbp.conf: Set debian-branch to ubuntu-eoan
File: debian/gbp.conf

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f399ce2cf4701a2dbb4b3505d2dd17a210d62f5c

  [ Dan Streetman ]
  * Fix bogus routes after DHCP lease change (LP: #1831787)
Files:
- 
debian/patches/lp1831787/0001-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch
- 
debian/patches/lp1831787/0002-network-set-preferred-source-in-removing-route-entry.patch
- 
debian/patches/lp1831787/0003-network-lower-log-level-about-critical-connection.patch
- 
debian/patches/lp1831787/0004-network-reset-Link-dhcp4_configured-flag-earlier.patch
- 
debian/patches/lp1831787/0005-network-split-dhcp_lease_lost-into-small-pieces.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ced3f5c2f619083f7beb164d94d4ccfe5fe8
  * Set src address for dhcp 'classless' routes (LP: #1835581)
File: 
debian/patches/lp1835581-src-network-networkd-dhcp4.c-set-prefsrc-for-classle.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6a7ef370fb1335548448920be4ae6176b67044a8
  * Allows cache=no-negative option to be set, ignoring negative answers to
be cached (LP: #1668771)
File: 
debian/patches/lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=27def26f5b1d1b8ba314c4a925fc1b7c43837f86

 -- Dan Streetman   Fri, 01 Nov 2019 16:33:08
-0400

** Changed in: systemd (Ubuntu Eoan)
   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/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.montemar.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 

[Touch-packages] [Bug 1831787] Re: Bogus routes after DHCP lease change

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 242-7ubuntu3.2

---
systemd (242-7ubuntu3.2) eoan; urgency=medium

  [ Dan Streetman ]
  * d/extra/dhclient-enter-resolved-hook:
- Replace use of bash-only &> with > and 2> (LP: #1849608)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook: cleanup temp $newstate file

  [ Rafael David Tinoco ]
  * Add support to KeepConfiguration= fixing behaviour for HA (LP: #1815101)
- d/p/lp1815101-01-networkd-add-support-to-keep-configuration.patch
- d/p/lp1815101-02-networkd-stop-clients-when-networkd-shuts-down.patch
- d/p/lp1815101-03-network-add-KeepConfiguration-dhcp-on-stop.patch
- 
d/p/lp1815101-04-network-make-KeepConfiguration-static-drop-DHCP-addr.patch
- d/p/lp1815101-05-man-add-documentation-about-KeepConfiguration.patch

systemd (242-7ubuntu3.1) eoan; urgency=medium

  [ Balint Reczey ]
  * Fix shutdown and related actions from the login screen (LP: #1847896)
File: 
debian/patches/logind-consider-greeter-sessions-suitable-as-display-sess.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b407dfd8c9dc81594553c27467c35b38d74c
  * debian/gbp.conf: Set debian-branch to ubuntu-eoan
File: debian/gbp.conf

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f399ce2cf4701a2dbb4b3505d2dd17a210d62f5c

  [ Dan Streetman ]
  * Fix bogus routes after DHCP lease change (LP: #1831787)
Files:
- 
debian/patches/lp1831787/0001-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch
- 
debian/patches/lp1831787/0002-network-set-preferred-source-in-removing-route-entry.patch
- 
debian/patches/lp1831787/0003-network-lower-log-level-about-critical-connection.patch
- 
debian/patches/lp1831787/0004-network-reset-Link-dhcp4_configured-flag-earlier.patch
- 
debian/patches/lp1831787/0005-network-split-dhcp_lease_lost-into-small-pieces.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ced3f5c2f619083f7beb164d94d4ccfe5fe8
  * Set src address for dhcp 'classless' routes (LP: #1835581)
File: 
debian/patches/lp1835581-src-network-networkd-dhcp4.c-set-prefsrc-for-classle.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6a7ef370fb1335548448920be4ae6176b67044a8
  * Allows cache=no-negative option to be set, ignoring negative answers to
be cached (LP: #1668771)
File: 
debian/patches/lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=27def26f5b1d1b8ba314c4a925fc1b7c43837f86

 -- Dan Streetman   Fri, 01 Nov 2019 16:33:08
-0400

** Changed in: systemd (Ubuntu Eoan)
   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/1831787

Title:
  Bogus routes after DHCP lease change

Status in netplan:
  Invalid
Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  networkd does not remove old route(s) after DHCP address change

  [test case]

  on a system using networkd, that is connected to a network where you
  can control the addresses that the DHCP server provides, setup system
  with networkd to get address via DHCP, e.g.

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  
  (re)start networkd or reboot, so the system gets an ipv4 DHCP address, and 
corresponding route to the gateway.

  
  Then on the dhcp server, change the subnet to a different subnet.  On the 
client, once its renews its DHCP address, the server will provide a new address 
in the new subnet, and the client will add a new default route to the new 
gateway address.  However, the old default route to the old gateway address 
isn't removed.

  Note this also happens without changing the entire subnet, but is more
  subtle as shown in the original description.

  [regression potential]

  this affects how networkd handles routes, so has the potential to
  leave a system with partial or incorrect networking, or no networking
  at all.  Any regression would most likely occur during networkd
  (re)start or during renewal of a DHCP lease, or when an interface is
  brought up.

  [other info]

  original description:
  ---

  
  Netplan config:

  network:
    version: 2
    renderer: networkd
    ethernets:
  eno4:
    dhcp4: no
  eno1np0:
    dhcp4: no
    addresses:
  - 172.16.0.2/24
    bridges:
  br0:
    dhcp4: yes
    interfaces:
  - eno4

  On initial 

[Touch-packages] [Bug 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 242-7ubuntu3.2

---
systemd (242-7ubuntu3.2) eoan; urgency=medium

  [ Dan Streetman ]
  * d/extra/dhclient-enter-resolved-hook:
- Replace use of bash-only &> with > and 2> (LP: #1849608)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook: cleanup temp $newstate file

  [ Rafael David Tinoco ]
  * Add support to KeepConfiguration= fixing behaviour for HA (LP: #1815101)
- d/p/lp1815101-01-networkd-add-support-to-keep-configuration.patch
- d/p/lp1815101-02-networkd-stop-clients-when-networkd-shuts-down.patch
- d/p/lp1815101-03-network-add-KeepConfiguration-dhcp-on-stop.patch
- 
d/p/lp1815101-04-network-make-KeepConfiguration-static-drop-DHCP-addr.patch
- d/p/lp1815101-05-man-add-documentation-about-KeepConfiguration.patch

systemd (242-7ubuntu3.1) eoan; urgency=medium

  [ Balint Reczey ]
  * Fix shutdown and related actions from the login screen (LP: #1847896)
File: 
debian/patches/logind-consider-greeter-sessions-suitable-as-display-sess.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b407dfd8c9dc81594553c27467c35b38d74c
  * debian/gbp.conf: Set debian-branch to ubuntu-eoan
File: debian/gbp.conf

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f399ce2cf4701a2dbb4b3505d2dd17a210d62f5c

  [ Dan Streetman ]
  * Fix bogus routes after DHCP lease change (LP: #1831787)
Files:
- 
debian/patches/lp1831787/0001-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch
- 
debian/patches/lp1831787/0002-network-set-preferred-source-in-removing-route-entry.patch
- 
debian/patches/lp1831787/0003-network-lower-log-level-about-critical-connection.patch
- 
debian/patches/lp1831787/0004-network-reset-Link-dhcp4_configured-flag-earlier.patch
- 
debian/patches/lp1831787/0005-network-split-dhcp_lease_lost-into-small-pieces.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ced3f5c2f619083f7beb164d94d4ccfe5fe8
  * Set src address for dhcp 'classless' routes (LP: #1835581)
File: 
debian/patches/lp1835581-src-network-networkd-dhcp4.c-set-prefsrc-for-classle.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6a7ef370fb1335548448920be4ae6176b67044a8
  * Allows cache=no-negative option to be set, ignoring negative answers to
be cached (LP: #1668771)
File: 
debian/patches/lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=27def26f5b1d1b8ba314c4a925fc1b7c43837f86

 -- Dan Streetman   Fri, 01 Nov 2019 16:33:08
-0400

** Changed in: systemd (Ubuntu Eoan)
   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/1835581

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
   

[Touch-packages] [Bug 1847896] Update Released

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1847896

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

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

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1831787

Title:
  Bogus routes after DHCP lease change

Status in netplan:
  Invalid
Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  networkd does not remove old route(s) after DHCP address change

  [test case]

  on a system using networkd, that is connected to a network where you
  can control the addresses that the DHCP server provides, setup system
  with networkd to get address via DHCP, e.g.

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  
  (re)start networkd or reboot, so the system gets an ipv4 DHCP address, and 
corresponding route to the gateway.

  
  Then on the dhcp server, change the subnet to a different subnet.  On the 
client, once its renews its DHCP address, the server will provide a new address 
in the new subnet, and the client will add a new default route to the new 
gateway address.  However, the old default route to the old gateway address 
isn't removed.

  Note this also happens without changing the entire subnet, but is more
  subtle as shown in the original description.

  [regression potential]

  this affects how networkd handles routes, so has the potential to
  leave a system with partial or incorrect networking, or no networking
  at all.  Any regression would most likely occur during networkd
  (re)start or during renewal of a DHCP lease, or when an interface is
  brought up.

  [other info]

  original description:
  ---

  
  Netplan config:

  network:
    version: 2
    renderer: networkd
    ethernets:
  eno4:
    dhcp4: no
  eno1np0:
    dhcp4: no
    addresses:
  - 172.16.0.2/24
    bridges:
  br0:
    dhcp4: yes
    interfaces:
  - eno4

  On initial boot, machine got 10.0.15.109 IP address:

  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured
  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 
10.0.15.109/23 via 10.0.15.253

  At one point, DHCP server reserver this IP address and client
  eventually picked up new IP address:

  May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address
  10.0.15.128/23 via 10.0.15.253

  This resulted in IP addresses:

  # ip -o a
  1: loinet 127.0.0.1/8 scope host lo\   valid_lft forever 
preferred_lft forever
  1: loinet6 ::1/128 scope host \   valid_lft forever preferred_lft 
forever
  2: eno1np0inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\   
valid_lft forever preferred_lft forever
  2: eno1np0inet6 fe80::b226:28ff:fe53:56be/64 scope link \   valid_lft 
forever preferred_lft forever
  6: br0inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\   
valid_lft 503sec preferred_lft 503sec
  6: br0inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \   valid_lft 
forever preferred_lft forever

  So far, everything is fine. But, the routes on the machine are bogus:

  # ip r
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100
  10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100
  172.16.0.0/24 dev eno1np0 proto kernel scope link src 172.16.0.2

  routes with src 10.0.15.109 should have been removed when lease was
  renewed. I'm not sure if this is a bug in netplan or systemd. This is
  18.04, systemd 37-3ubuntu10.21, netplan 0.40.1~18.04.4.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1831787/+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 1849608] Update Released

2019-11-25 Thread Łukasz Zemczak
*** This bug is a duplicate of bug 1805183 ***
https://bugs.launchpad.net/bugs/1805183

The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1849608

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  dhclient fails to notify resolved about DNS servers due to bash-
  specific redirect inside 'resolved' hook script

  [test case]

  see original description below

  [regression potential]

  any regression would likely cause resolved not to be aware of
  dhclient-provided dns servers

  [other info]

  This is needed only in Eoan and later; X/B/D do not have the bash-
  specific redirect '&>' in their hook file.

  The change that originally added the &> to eoan is also being applied
  to b/d in bug 1805183, but with this fix added also.

  original description:
  ---

  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
    DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
    DNSOverTLS setting: no
    DNSSEC setting: no
  DNSSEC supported: no
  ==

  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849608/+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 1847896] Re: Unable to shutdown or restart from log-in screen

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 242-7ubuntu3.2

---
systemd (242-7ubuntu3.2) eoan; urgency=medium

  [ Dan Streetman ]
  * d/extra/dhclient-enter-resolved-hook:
- Replace use of bash-only &> with > and 2> (LP: #1849608)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook: cleanup temp $newstate file

  [ Rafael David Tinoco ]
  * Add support to KeepConfiguration= fixing behaviour for HA (LP: #1815101)
- d/p/lp1815101-01-networkd-add-support-to-keep-configuration.patch
- d/p/lp1815101-02-networkd-stop-clients-when-networkd-shuts-down.patch
- d/p/lp1815101-03-network-add-KeepConfiguration-dhcp-on-stop.patch
- 
d/p/lp1815101-04-network-make-KeepConfiguration-static-drop-DHCP-addr.patch
- d/p/lp1815101-05-man-add-documentation-about-KeepConfiguration.patch

systemd (242-7ubuntu3.1) eoan; urgency=medium

  [ Balint Reczey ]
  * Fix shutdown and related actions from the login screen (LP: #1847896)
File: 
debian/patches/logind-consider-greeter-sessions-suitable-as-display-sess.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b407dfd8c9dc81594553c27467c35b38d74c
  * debian/gbp.conf: Set debian-branch to ubuntu-eoan
File: debian/gbp.conf

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f399ce2cf4701a2dbb4b3505d2dd17a210d62f5c

  [ Dan Streetman ]
  * Fix bogus routes after DHCP lease change (LP: #1831787)
Files:
- 
debian/patches/lp1831787/0001-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch
- 
debian/patches/lp1831787/0002-network-set-preferred-source-in-removing-route-entry.patch
- 
debian/patches/lp1831787/0003-network-lower-log-level-about-critical-connection.patch
- 
debian/patches/lp1831787/0004-network-reset-Link-dhcp4_configured-flag-earlier.patch
- 
debian/patches/lp1831787/0005-network-split-dhcp_lease_lost-into-small-pieces.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ced3f5c2f619083f7beb164d94d4ccfe5fe8
  * Set src address for dhcp 'classless' routes (LP: #1835581)
File: 
debian/patches/lp1835581-src-network-networkd-dhcp4.c-set-prefsrc-for-classle.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6a7ef370fb1335548448920be4ae6176b67044a8
  * Allows cache=no-negative option to be set, ignoring negative answers to
be cached (LP: #1668771)
File: 
debian/patches/lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=27def26f5b1d1b8ba314c4a925fc1b7c43837f86

 -- Dan Streetman   Fri, 01 Nov 2019 16:33:08
-0400

** Changed in: systemd (Ubuntu Eoan)
   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/1847896

Title:
  Unable to shutdown or restart from log-in screen

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Shutdown and restart options don't work from the login screen, when
  the user is not logged in.

  [Test Case]

   * Start the system and don't log in, or log out in case the system is set up 
with autologin.
   * Restart, then shut down the system using the option in the upper right 
corner of the login screen.
   * Observe both operations working.

  [Regression Potential]

   * The fix is treating treating the greeter as user display sessions
  by cherry-picking upstream's change released in v243. The fix itself
  is very small, but there may be non-obvious security implications.

  [Original Bug Text]

  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1849658] Re: resolved fallback to TCP fails for truncated UDP replies

2019-11-25 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 242-7ubuntu3.2

---
systemd (242-7ubuntu3.2) eoan; urgency=medium

  [ Dan Streetman ]
  * d/extra/dhclient-enter-resolved-hook:
- Replace use of bash-only &> with > and 2> (LP: #1849608)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook: cleanup temp $newstate file

  [ Rafael David Tinoco ]
  * Add support to KeepConfiguration= fixing behaviour for HA (LP: #1815101)
- d/p/lp1815101-01-networkd-add-support-to-keep-configuration.patch
- d/p/lp1815101-02-networkd-stop-clients-when-networkd-shuts-down.patch
- d/p/lp1815101-03-network-add-KeepConfiguration-dhcp-on-stop.patch
- 
d/p/lp1815101-04-network-make-KeepConfiguration-static-drop-DHCP-addr.patch
- d/p/lp1815101-05-man-add-documentation-about-KeepConfiguration.patch

systemd (242-7ubuntu3.1) eoan; urgency=medium

  [ Balint Reczey ]
  * Fix shutdown and related actions from the login screen (LP: #1847896)
File: 
debian/patches/logind-consider-greeter-sessions-suitable-as-display-sess.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b407dfd8c9dc81594553c27467c35b38d74c
  * debian/gbp.conf: Set debian-branch to ubuntu-eoan
File: debian/gbp.conf

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f399ce2cf4701a2dbb4b3505d2dd17a210d62f5c

  [ Dan Streetman ]
  * Fix bogus routes after DHCP lease change (LP: #1831787)
Files:
- 
debian/patches/lp1831787/0001-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch
- 
debian/patches/lp1831787/0002-network-set-preferred-source-in-removing-route-entry.patch
- 
debian/patches/lp1831787/0003-network-lower-log-level-about-critical-connection.patch
- 
debian/patches/lp1831787/0004-network-reset-Link-dhcp4_configured-flag-earlier.patch
- 
debian/patches/lp1831787/0005-network-split-dhcp_lease_lost-into-small-pieces.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ced3f5c2f619083f7beb164d94d4ccfe5fe8
  * Set src address for dhcp 'classless' routes (LP: #1835581)
File: 
debian/patches/lp1835581-src-network-networkd-dhcp4.c-set-prefsrc-for-classle.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6a7ef370fb1335548448920be4ae6176b67044a8
  * Allows cache=no-negative option to be set, ignoring negative answers to
be cached (LP: #1668771)
File: 
debian/patches/lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=27def26f5b1d1b8ba314c4a925fc1b7c43837f86

 -- Dan Streetman   Fri, 01 Nov 2019 16:33:08
-0400

** Changed in: systemd (Ubuntu Eoan)
   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/1849658

Title:
  resolved fallback to TCP fails for truncated UDP replies

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  for DNS UDP replies larger than 512 bytes, fallback to TCP is used.
  For example 'host toomany.ddstreet.org'.

  Due to a bug in resolved in refcounting DNS stream types, the refcount
  underflows for type 0 streams (which resolved uses to talk to upstream
  nameservers), resulting in resolved being unable to fallback to TCP to
  handle truncated UDP replies.

  [test case]

  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
  ;; Truncated, retrying in TCP mode.

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;toomany.ddstreet.org.IN  A

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Thu Oct 24 11:40:29 UTC 2019
  ;; MSG SIZE  rcvd: 678

  ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches
  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  [regression potential]

  very low, as this only properly sets the stream type in the DnsStream
  object; any regression would be a failure to be able to use TCP for
  DNS requests or replies.

  [other info]

  https://github.com/systemd/systemd/pull/13838

  

[Touch-packages] [Bug 1849658] Update Released

2019-11-25 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being 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/1849658

Title:
  resolved fallback to TCP fails for truncated UDP replies

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  for DNS UDP replies larger than 512 bytes, fallback to TCP is used.
  For example 'host toomany.ddstreet.org'.

  Due to a bug in resolved in refcounting DNS stream types, the refcount
  underflows for type 0 streams (which resolved uses to talk to upstream
  nameservers), resulting in resolved being unable to fallback to TCP to
  handle truncated UDP replies.

  [test case]

  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
  ;; Truncated, retrying in TCP mode.

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;toomany.ddstreet.org.IN  A

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Thu Oct 24 11:40:29 UTC 2019
  ;; MSG SIZE  rcvd: 678

  ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches
  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org

  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  [regression potential]

  very low, as this only properly sets the stream type in the DnsStream
  object; any regression would be a failure to be able to use TCP for
  DNS requests or replies.

  [other info]

  https://github.com/systemd/systemd/pull/13838

  The commit adding stream types is not present in x/b, so this is
  needed only for disco and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+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 1849608] Re: systemd resolv should separate the output of stdout and stderr

2019-11-25 Thread Launchpad Bug Tracker
*** This bug is a duplicate of bug 1805183 ***
https://bugs.launchpad.net/bugs/1805183

This bug was fixed in the package systemd - 242-7ubuntu3.2

---
systemd (242-7ubuntu3.2) eoan; urgency=medium

  [ Dan Streetman ]
  * d/extra/dhclient-enter-resolved-hook:
- Replace use of bash-only &> with > and 2> (LP: #1849608)
  * d/p/lp1849658-resolved-set-stream-type-during-DnsStream-creation.patch:
- Fix bug in refcounting TCP stream types (LP: #1849658)
  * d/extra/dhclient-enter-resolved-hook: cleanup temp $newstate file

  [ Rafael David Tinoco ]
  * Add support to KeepConfiguration= fixing behaviour for HA (LP: #1815101)
- d/p/lp1815101-01-networkd-add-support-to-keep-configuration.patch
- d/p/lp1815101-02-networkd-stop-clients-when-networkd-shuts-down.patch
- d/p/lp1815101-03-network-add-KeepConfiguration-dhcp-on-stop.patch
- 
d/p/lp1815101-04-network-make-KeepConfiguration-static-drop-DHCP-addr.patch
- d/p/lp1815101-05-man-add-documentation-about-KeepConfiguration.patch

systemd (242-7ubuntu3.1) eoan; urgency=medium

  [ Balint Reczey ]
  * Fix shutdown and related actions from the login screen (LP: #1847896)
File: 
debian/patches/logind-consider-greeter-sessions-suitable-as-display-sess.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b407dfd8c9dc81594553c27467c35b38d74c
  * debian/gbp.conf: Set debian-branch to ubuntu-eoan
File: debian/gbp.conf

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f399ce2cf4701a2dbb4b3505d2dd17a210d62f5c

  [ Dan Streetman ]
  * Fix bogus routes after DHCP lease change (LP: #1831787)
Files:
- 
debian/patches/lp1831787/0001-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch
- 
debian/patches/lp1831787/0002-network-set-preferred-source-in-removing-route-entry.patch
- 
debian/patches/lp1831787/0003-network-lower-log-level-about-critical-connection.patch
- 
debian/patches/lp1831787/0004-network-reset-Link-dhcp4_configured-flag-earlier.patch
- 
debian/patches/lp1831787/0005-network-split-dhcp_lease_lost-into-small-pieces.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ced3f5c2f619083f7beb164d94d4ccfe5fe8
  * Set src address for dhcp 'classless' routes (LP: #1835581)
File: 
debian/patches/lp1835581-src-network-networkd-dhcp4.c-set-prefsrc-for-classle.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6a7ef370fb1335548448920be4ae6176b67044a8
  * Allows cache=no-negative option to be set, ignoring negative answers to
be cached (LP: #1668771)
File: 
debian/patches/lp1668771-resolved-switch-cache-option-to-a-tri-state-option-s.patch

https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=27def26f5b1d1b8ba314c4a925fc1b7c43837f86

 -- Dan Streetman   Fri, 01 Nov 2019 16:33:08
-0400

** Changed in: systemd (Ubuntu Eoan)
   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/1849608

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  dhclient fails to notify resolved about DNS servers due to bash-
  specific redirect inside 'resolved' hook script

  [test case]

  see original description below

  [regression potential]

  any regression would likely cause resolved not to be aware of
  dhclient-provided dns servers

  [other info]

  This is needed only in Eoan and later; X/B/D do not have the bash-
  specific redirect '&>' in their hook file.

  The change that originally added the &> to eoan is also being applied
  to b/d in bug 1805183, but with this fix added also.

  original description:
  ---

  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 

[Touch-packages] [Bug 869017] Re: Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)

2019-11-25 Thread Robie Basak
Here's the change that was made: https://git.launchpad.net/~ubuntu-
kernel/ubuntu/+source/linux/+git/zesty/commit/?id=a87ae50beda8c46c543b39e19070549cf355eb65

It's just the default of the consoleblank= kernel parameter. You can
override it by specifying that parameter to the kernel at boot time (eg.
via /etc/default/grub)

If someone could test and document exact steps to do this override in
this bug please, that'd be useful to users and I'd appreciate it.

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

Title:
  Ubuntu server enables screenblanking, concealing crashdumps (DPMS is
  not used)

Status in kbd package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in kbd source package in Zesty:
  Invalid
Status in linux source package in Zesty:
  Fix Released
Status in kbd package in Debian:
  Fix Released

Bug description:
  James Rice of Jump Networks noticed that there is a screen-blanker
  enabled on Ubuntu Server.

  James notes that this blanking is not enabling DPMS power saving
  (thereby negating any power-saving benefit), and is simply turning the
  screen content blank.   This means that the crash output is invisible
  which is unhelpful on a server (virtual or otherwise).

  Ideally the screen should (at a minimum) be turned on and unblanked at
  the point of an OOPs/crash being printed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017/+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 1844853] Re: IBus no longer works in Qt applications after upgrade

2019-11-25 Thread Gunnar Hjalmarsson
** Changed in: glib2.0 (Ubuntu Focal)
   Status: Fix Committed => Fix Released

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

Title:
  IBus no longer works in Qt applications after upgrade

Status in GLib:
  Fix Released
Status in ibus:
  Fix Released
Status in glib2.0 package in Ubuntu:
  Fix Released
Status in ibus package in Ubuntu:
  Fix Released
Status in glib2.0 source package in Xenial:
  Fix Committed
Status in glib2.0 source package in Bionic:
  Fix Committed
Status in glib2.0 source package in Disco:
  Fix Committed
Status in glib2.0 source package in Eoan:
  Fix Committed
Status in glib2.0 source package in Focal:
  Fix Released
Status in ibus source package in Focal:
  Fix Released
Status in glib2.0 package in Debian:
  Fix Released

Bug description:
  [Impact]

  IBus was broken for Qt applications as a regression due to the fix of
  CVE-2019-14822. As a result the IBus patch was disabled temporarily,
  which fixed IBus from a usability POV.

  The real fix has been made in glib2.0, and the updates in -proposed
  will allow the IBus patch to be re-enabled.

  [Test Case]

   * On a standard Ubuntu {eoan,disco,bionic,xenial} installation
     - Upgrade the glib2.0 packages from
   {eoan,disco,bionic,xenial}-proposed
     - Upgrade the ibus packages from
   https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
     - Install some IBus input method, e.g. ibus-libpinyin
     - Install some Qt application, e.g. Kate

  * Relogin (maybe reboot)

  * Add the input method to the input sources

  * Open the Qt app and try to input something using the IBus IM

  => Find that the transliteration works as expected

  [Regression Potential]

  The applicable patches origin from glib upstream:
  https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
  Consequently the changes have been reviewed by the glib maintainer, but also 
tested by the IBus maintainer, by me (gunnarhj), and - of course - the author 
Simon McVittie. The changes have been in Debian unstable since 2019-10-30.

  [Original description]

  Kubuntu Release 18.04.3 LTS

  Expected behavior:
  ibus continues working as before after applying security update 
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.

  Observed behavior:
  ibus is not usable anymore in Qt applications.

  After updating ibus and the related packages ibus-gtk, ibus-gtk3, 
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to 
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using 
shift-space no longer changes the selected input method and even when i switch 
to the mozc input method in a gtk application, i can not use it in any Qt 
applications.
  When starting qtconfig in a terminal, I also get the following message:

  Bus::open: Connect ibus failed!
  IBusInputContext::createInputContext: no connection to ibus-daemon

  This bug was not present in version 1.5.17-3ubuntu5 and I also
  confirmed that downgrading the packages to version 1.5.17-3ubuntu4
  restores ibus functionality in Qt applications.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ibus 1.5.17-3ubuntu5.1
  ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-30-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sat Sep 21 07:58:56 2019
  InstallationDate: Installed on 2019-06-28 (84 days ago)
  InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: ibus
  UpgradeStatus: No upgrade log present (probably fresh install)

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


  1   2   >