date:20191204

[Touch-packages] [Bug 1845046] Re: Bluetooth headphones/speaker default to low quality headset mode and fails to switch to A2DP when selected

2019-12-04 Thread Daniel van Vugt

Regardless of whether bluez or pulseaudio are at fault, this feels like
a recent regression since it's now affecting my Bluetooth speaker
hardware which has been unchanged for several years. And it looks like
18.04 and later received updates to both packages this year.

I guess the most useful thing to do would be to try a fresh 18.04
installation with the oldest packages, verify the bug does not exist and
then figure out which update introduced the bug.

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

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

Status in bluez package in Ubuntu:
  Confirmed
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/bluez/+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 1811149] Re: 23 wireguard peers hang systemd-networkd

2019-12-04 Thread Joshua Sjoding

As near as I can tell the fix for this was never backported from systemd
v241 to bionic. I recently filed a related a bug report here:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853956

My symptoms are a little different (misconfiguration instead of an
infinite loop), but I have a strong suspicion that the underlying cause
is the same.

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

Title:
  23 wireguard peers hang systemd-networkd

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

Bug description:
  I'm running Ubuntu 18.04.1 LTS with systemd=237-3ubuntu10.9.
  Linux kernel version is 4.15.0-32-generic #35-Ubuntu SMP.
  wireguard=0.0.20181218-wg1~bionic from PPA.

  I have a Wireguard-based VPN server that has several peers. As soon as
  number of peers is 22 or lower, everything works okay. As soon as I
  add the 23rd peer, restart of `systemd-networkd` service fails with
  timeout while systemd-networkd hogs CPU.

  Moreover, if I reboot the box while wireguard configuration is
  "broken", systemd-networkd fails to apply network settings on boot and
  the box is no longer accessible over the network.

  Configuration is structured in a following way (keys are fake):

  ==> wg0.netdev
  [NetDev]
  Name=wg0
  Kind=wireguard
  Description=Wireguard VPN server
  [WireGuard]
  ListenPort=4500
  PrivateKey=kNl7tkhCM1Crj8RhUIn8xvwcg+UoOkw26kQjQEtZk1k=
  [WireGuardPeer]
  PublicKey=AfM1AN4IIUe5AVypFg2pcNrQmqOtZQIJLgusbkDYXkI=
  AllowedIPs=fd6f:b446:a2ca:0400:cb6f:b446:a2ca:bd0b/128
  AllowedIPs=fd6f:b446:a2ca:cb6f:b446:a2ca::/96
  # and 22 more [WireGuardPeer] like that

  ==> wg0.network
  Name=wg0
  [Network]
  Address=fd6f:b446:a2ca:0400::1/64
  [Route]
  Destination=fd6f:b446:a2ca:cb6f:b446:a2ca::/96
  # and 22 more [Route] sections like that

  syslog logs are attached both for "good" and "bad" cases, sample of
  strace logs is also attached for "bad" case.

  I'm filling the issue here as the aforementioned systemd version is
  already out of scope of upstream bug tracker per
  https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md
  #filing-issues

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1811149/+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 1854689] Re: BlueZ 5.52 release

2019-12-04 Thread Daniel van Vugt

** Attachment added: "bluez_5.52.orig.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1854689/+attachment/5309950/+files/bluez_5.52.orig.tar.xz

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

Title:
  BlueZ 5.52 release

Status in bluez package in Ubuntu:
  In Progress

Bug description:
  BlueZ 5.52 release:
  http://www.bluez.org/release-of-bluez-5-52/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1854689/+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 1854689] Re: BlueZ 5.52 release

2019-12-04 Thread Daniel van Vugt

** Attachment added: "bluez_5.52-0ubuntu1.debian.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1854689/+attachment/5309951/+files/bluez_5.52-0ubuntu1.debian.tar.xz

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

Title:
  BlueZ 5.52 release

Status in bluez package in Ubuntu:
  In Progress

Bug description:
  BlueZ 5.52 release:
  http://www.bluez.org/release-of-bluez-5-52/

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

2019-12-04 Thread Joshua Sjoding

I think the underlying problem is improper fragmentation of netlink
messages sent to the WireGuard device by systemd v237 in the
set_wireguard_interface function:

https://github.com/systemd/systemd/blob/v237/src/network/netdev/wireguard.c#L107

Appending netlink message data can fail if the message size limit has
been exceeded. This can happen if there are too many peers or ip masks
in the netdev file, and the v237 code doesn't seem to handle this
properly. It's supposed to split the data up into message fragments, but
instead it can end up writing incoherent data to the netlink socket or
end up in an infinite loop.

This issue was fixed in systemd v241 by reworking the code over a few
commits:

https://github.com/systemd/systemd/pull/11418
https://github.com/systemd/systemd/pull/11580 (this fixed issues with the first
PR)

I found some comments (now resolved) on one of the commits illuminating:

https://github.com/systemd/systemd/pull/11418/commits/e1f717d4a02e15ae11a191dd4962b2f4d117678d

Mic92 on 2019-01-15:

> The idea is that netlink's messages are limited in size. If an
interface has many peers, addresses or ip masks then the configuration
might not fit into one message and has to be split across different
messages.

yuwata on 2019-01-15:

> Yeah. I guess there was some bug in the cancellation logic, and it
causes infinite loop with the magic number 23.

The infinite loop with 23 peers yuwata mentions is a reference to Leonid's bug
report from January:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811149

I expect that backporting these fixes from v241 to bionic's systemd v237
branch would resolve both my issue and the issue reported by Leonid.

I realize this is a non-trivial change and there's a regression risk.

--
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 1847967] Re: oem kernel packages treated differently from generic kernel ones

2019-12-04 Thread You-Sheng Yang

Created:
* 
https://code.launchpad.net/~vicamo/ubuntu/bionic/apport/bug-1847967/+merge/376380
* 
https://code.launchpad.net/~vicamo/ubuntu/disco/apport/bug-1847967/+merge/376381
* 
https://code.launchpad.net/~vicamo/ubuntu/eoan/apport/bug-1847967/+merge/374263

** Branch linked: lp:~vicamo/ubuntu/bionic/apport/bug-1847967

** Branch linked: lp:~vicamo/ubuntu/disco/apport/bug-1847967

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

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

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

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

Title:
  oem kernel packages treated differently from generic kernel ones

Status in OEM Priority Project:
  New
Status in apport package in Ubuntu:
  Fix Committed
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Disco:
  In Progress
Status in apport source package in Eoan:
  In Progress
Status in apport source package in Focal:
  Fix Committed

Bug description:
  When `apport-bug linux` was executed on systems with linux-oem, linux-
  oem-osp1 kernels, many details are not included as generic linux
  kernel does. Alsa info, dmesg, lspci, lsusb, DMI, etc. are missing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1847967/+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 1854689] Re: BlueZ 5.52 release

2019-12-04 Thread Daniel van Vugt

** Changed in: bluez (Ubuntu)
   Status: Triaged => In Progress

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

Title:
  BlueZ 5.52 release

Status in bluez package in Ubuntu:
  In Progress

Bug description:
  BlueZ 5.52 release:
  http://www.bluez.org/release-of-bluez-5-52/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1854689/+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 1847967] Re: oem kernel packages treated differently from generic kernel ones

2019-12-04 Thread You-Sheng Yang

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

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

Title:
  oem kernel packages treated differently from generic kernel ones

Status in OEM Priority Project:
  New
Status in apport package in Ubuntu:
  Fix Committed
Status in apport source package in Bionic:
  New
Status in apport source package in Disco:
  New
Status in apport source package in Eoan:
  New
Status in apport source package in Focal:
  Fix Committed

Bug description:
  When `apport-bug linux` was executed on systems with linux-oem, linux-
  oem-osp1 kernels, many details are not included as generic linux
  kernel does. Alsa info, dmesg, lspci, lsusb, DMI, etc. are missing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1847967/+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] Re: 34 wireguard peers result in invalid peer configuration

2019-12-04 Thread Joshua Sjoding

I now believe the dmesg complaint in my last comment to be a separate
issue. A fix for it was backported to systemd v238 in this commit:

https://github.com/systemd/systemd-
stable/commit/7db3fe08c5eb83584f3a3d356876b4acaa797585#diff-
f29d1bfc98e548dc0eb497c3d17cbefa

It was not backported to systemd v237:

https://github.com/systemd/systemd-
stable/commits/v237-stable/src/network/netdev/wireguard.c

-- 
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 1847967] Re: oem kernel packages treated differently from generic kernel ones

2019-12-04 Thread You-Sheng Yang

Yes, it was made before Focal was out, but definitely want it to be SRU-
ed to all series with linux-oem/linux-oem-osp1 kernels.

** Also affects: apport (Ubuntu Focal)
   Importance: Undecided
 Assignee: You-Sheng Yang (vicamo)
   Status: In Progress

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

** Also affects: apport (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: apport (Ubuntu Disco)
   Importance: Undecided
   Status: New

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

Title:
  oem kernel packages treated differently from generic kernel ones

Status in OEM Priority Project:
  New
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Bionic:
  New
Status in apport source package in Disco:
  New
Status in apport source package in Eoan:
  New
Status in apport source package in Focal:
  In Progress

Bug description:
  When `apport-bug linux` was executed on systems with linux-oem, linux-
  oem-osp1 kernels, many details are not included as generic linux
  kernel does. Alsa info, dmesg, lspci, lsusb, DMI, etc. are missing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1847967/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement

2019-12-04 Thread Ryutaroh Matsumoto

This was reported to the upstream https://github.com/lxc/lxc/issues/3198
The purpose of libpam-cgfs is only  chowning some CGroup directories to the 
login user.
When Linux is booted with systemd.unified_cgroup_hierarchy,
/sys/fs/cgroup/user.slice/user-$UID.slice/session-nnn.scope is not chowned to a 
login user.
So libpam-cgfs completely fails to function under cgroup v2.

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

** Bug watch added: LXC bug tracker #3198
   https://github.com/lxc/lxc/issues/3198

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

Title:
  cgroup v2 is not fully supported yet, proceeding with partial
  confinement

Status in docker.io package in Ubuntu:
  New
Status in lxc package in Ubuntu:
  New
Status in lxcfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  In Progress

Bug description:
  Systemd upstream switched the default cgroup hierarchy to unified with
  v243. This change is reverted by the Ubuntu systemd packages, but as
  unified is the way to go per upstream support should be added to all
  relevant Ubuntu packges (and snaps):

  https://github.com/systemd/systemd/blob/v243/NEWS#L56

  * systemd now defaults to the "unified" cgroup hierarchy setup during
build-time, i.e. -Ddefault-hierarchy=unified is now the build-time
default. Previously, -Ddefault-hierarchy=hybrid was the default. 
This
change reflects the fact that cgroupsv2 support has matured
substantially in both systemd and in the kernel, and is clearly the
way forward. Downstream production distributions might want to
continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
their builds as unfortunately the popular container managers have 
not
caught up with the kernel API changes.

  
  Systemd is rebuilt using the new default and is available from the following 
PPA for testing:

  https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh

  The autopkgtest results against other packges are available here:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain

  lxc autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz

  snapd autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz

  
  docker.io autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1850667/+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 1850041] Re: Systemd-analyze blame returns "Bootup is not yet finished"

2019-12-04 Thread Robert Dinse

I am experiencing this also.  If I disable plymouth-quit-wait.service
then boot completes but leaves me in text mode until I type control-
alt-f7.  This worked properly prior to 19.10 upgrade.

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

Title:
  Systemd-analyze blame returns "Bootup is not yet finished"

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Every time I run systemd-analyze blame, I get the message:

  Bootup is not yet finished 
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
  Please try again later.

  This, even if my laptop is on for several hours.

  Running systemctl list-jobs, returns:

  JOB UNIT TYPE  STATE  
1 graphical.target start waiting
   95 systemd-update-utmp-runlevel.service start waiting
   89 system-getty.slice   start waiting
   87 getty.target start waiting
   21 setvtrgb.service start waiting
  112 plymouth-quit-wait.service   start running
   88 getty@tty1.service   start waiting
2 multi-user.targetstart waiting

  Boot time is about 90 seconds, before and after upgrading from 19.04
  to 19.10.

  All applications start and run normally.

  My system is Ubuntu Budgie 19.10, working on a Dell Inspiron Laptop.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 242-7ubuntu3
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Budgie:GNOME
  Date: Sun Oct 27 09:54:26 2019
  MachineType: Dell Inc. Inspiron 3421
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic 
root=UUID=2b7d5523-743f-465d-a24c-fadc4a3aa0f4 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   3 overridden configuration files found.
  UpgradeStatus: Upgraded to eoan on 2019-10-23 (3 days ago)
  dmi.bios.date: 11/30/2012
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A02
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A02
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: Not Specified
  dmi.modalias: 
dmi:bvnDellInc.:bvrA02:bd11/30/2012:svnDellInc.:pnInspiron3421:pvrNotSpecified:rvnDellInc.:rn:rvrA02:cvnDellInc.:ct8:cvrNotSpecified:
  dmi.product.name: Inspiron 3421
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: Not Specified
  dmi.sys.vendor: Dell Inc.

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

2019-12-04 Thread Joshua Sjoding

On two systems with 33 peers I noticed that this shows up in dmesg after
a reboot:

netlink: 'systemd-network': attribute type 5 has an invalid length.

These lines also show up whenever I run `sudo systemctl restart systemd-
networkd` now. They didn't show up before the reboot.

This suggests that there may be issues I haven't noticed yet even with
fewer than 34 peers. In our production environment not all of our peers
are online all the time, so an issue affecting a few of them could go
unnoticed.

-- 
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 1854237] Re: autopkgtests fail after security fixes

2019-12-04 Thread Mathew Hodson

** Branch linked: lp:~mwhudson/ubuntu/focal/apport/lp-1854237

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

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

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

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

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

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

Title:
  autopkgtests fail after security fixes

Status in Apport:
  New
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Xenial:
  New
Status in apport source package in Bionic:
  New
Status in apport source package in Disco:
  New
Status in apport source package in Eoan:
  New

Bug description:
  The following autopkgtests fail after the recent security fixes:

  log:FAIL: test_get_logind_session (__main__.T)
  log:FAIL: test_core_dump_packaged (__main__.T)
  log:FAIL: test_core_dump_unpackaged (__main__.T)
  log:FAIL: test_crash_setuid_drop (__main__.T)
  log:FAIL: test_crash_setuid_keep (__main__.T)
  log:FAIL: test_crash_setuid_nonwritable_cwd (__main__.T)
  log:FAIL: test_lock_symlink (__main__.T)

  test_get_logind_session is a test failing to keep up with an API
  change. test_core_dump_* is failures to remove partly written core
  files. Both of these are easy fixes, I'll have a MP for them soon.

  test_crash_setuid_* are caused by the dropping of privileges when
  accessing the crashing process's /proc. They seem to be testing
  behaviour now explicitly forbidden by the fix to be honest!

  test_lock_symlink fails because the lock file is now always in
  /var/lock/apport/ and not in $APPORT_REPORT_DIR. I guess we could
  update the test, but is it really worth it after the fix?

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1854237/+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 1808476] Re: Please bump libssl1.1 dependency to at least >= 1.1.1, as headers leak constants

2019-12-04 Thread Mathew Hodson

** Tags removed: verification-needed verification-needed-cosmic

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

Title:
  Please bump libssl1.1 dependency to at least >= 1.1.1, as headers leak
  constants

Status in python2.7 package in Ubuntu:
  Fix Released
Status in python2.7 source package in Bionic:
  New
Status in python2.7 source package in Cosmic:
  Fix Released
Status in python2.7 source package in Disco:
  Fix Released

Bug description:
  [Impact]

  $ python -c 'import ssl; print(ssl.OP_NO_TLSv1_3)'

  Prints 0, for python2.7 built against 1.1.0 headers, yet prints
  536870912 when built against 1.1.1 irrespective of the runtime
  libssl1.1 library version.

  This may yield confusion, especially since ssl.OPENSSL_VERSION reports
  runtime libssl version, not the version of the libssl headers. Such
  that, e.g. it looks like ssl module is running against 1.1.1, has
  OP_NO_TLSv1_3 option, yet cannot actually use it to disable TLSv1.3.

  Also vice versa, python2.7 build against 1.1.1 can be installed with
  1.1.0 runtime library, and thus OP_NO_TLSv1_3 might be set, which is
  not understood by the runtime library.

  In libpython2.7-stdlib, please bump libssl1.1 version dep to
  "libssl1.1 (>= 1.1.1)" when building against libssl-dev >= 1.1.1.

  python3.x are not affected, as they started to exploit 1.1.1-only
  symbols/features, and thus already have an automatic dep on >= 1.1.1.

  [Test Case]

  Make sure the libssl1.1 build-dependency of python2.7 is at least
  1.1.1.

  [Regression Potential]

  Potentially none, besides the usual regression potential of new
  rebuilds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1808476/+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 1855133] Re: SRU: update python2.7 to the 2.7.17 release

2019-12-04 Thread Mathew Hodson

** Changed in: python2.7 (Ubuntu)
   Status: New => Fix Released

** Changed in: python-stdlib-extensions (Ubuntu)
   Status: New => Fix Released

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

Title:
  SRU: update python2.7 to the 2.7.17 release

Status in python-stdlib-extensions package in Ubuntu:
  Fix Released
Status in python2.7 package in Ubuntu:
  Fix Released
Status in python-stdlib-extensions source package in Bionic:
  New
Status in python2.7 source package in Bionic:
  New

Bug description:
  This is a proposal to backport the Python 2.7.17 release to bionic.

   - python2.7
   - python-stdlib-extensions
   - python-defaults is not required, but could be used to
 trigger autopkg tests in the -proposed pocket.

  The package builds are prepared in
  https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+packages

  [Impact]
  Provide an upstream release for Python 2.7.

  [Regression Potential]
  There is regression potential, however with a test rebuild of the main 
portion of the archive no regressions were found.

  [Test Case]
  No regressions in the Python test suite, and no regressions in the test
  rebuild of the main component of the archive (all architectures)

  As a test, an archive rebuild for main was performed, and no
  regressions were found with this new package. The archive rebuild also
  contained updated versions of gcc-7, gcc-8, python-stdlib-extensions
  and python2.7. The GCC and Python packages should not infer with each
  other.

  [Validation]
  Analyze the build logs for regressions.
  The OpenStack packaging team is checking OpenStack against the built packages 
in -proposed.

  Summary of the test rebuilds:
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191107-bionic-bionic.html
  
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191107-bionic-gcc7-bionic.html

  The first one is a reference build, the second one the test rebuild
  with the updated components.

  There are no additional regressions except for one Python test, which 
sometimes hangs on the buildds, sometimes passes (test_ttk_guionly). Will
  be disabled in a follow-up upload.

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

87 matches

Mail list logo