[Touch-packages] [Bug 1838227] Re: Bluetooth "Connection switch" snaps back by itself until after many tries

2019-09-27 Thread Launchpad Bug Tracker
[Expired for bluez (Ubuntu) because there has been no activity for 60
days.]

** Changed in: bluez (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  Bluetooth "Connection switch" snaps back by itself until after many
  tries

Status in bluez package in Ubuntu:
  Expired

Bug description:
  Attempting to slide the "Connection" switch in the gui to connect a
  bluetooth device fails initially -- the switch moves but "snaps back"
  by itself immediately.   Clicking on the switch flashes the "busy"
  indicator momentarily, but the switch does not move.   After a while,
  connecting succeeds.

  I don't know if the mouse input is not recognized until the "Nth"
  attempt, or else the connection was in-progress all along but the gui
  was not tracking that correctly.

  Please watch the attached video (use vlc).

  NOTE: This system is running a non-standard kernel 5.2 in order to
  circumvent other problems (see bug 1838180).

  Again, see the video; there is something wrong with how the GUI
  communicates with the kernel.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: bluez 5.50-0ubuntu2
  Uname: Linux 5.2.0-050200-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Jul 28 22:46:28 2019
  InstallationDate: Installed on 2019-02-06 (173 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  InterestingModules: bluetooth
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: innotek GmbH VirtualBox
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.2.0-050200-generic 
root=UUID=75234048-11af-4901-9f89-2c32581f5dd3 ro quiet splash
  SourcePackage: bluez
  UpgradeStatus: Upgraded to disco on 2019-06-27 (31 days ago)
  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
  hciconfig:
   
  rfkill:
   
  syslog:
   Jul 28 22:42:11 V-M-Ubuntu-Experimental NetworkManager[828]:   
[1564378931.7693] Loaded device plugin: NMBluezManager 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.16.0/libnm-device-plugin-bluetooth.so)
   Jul 28 22:42:22 V-M-Ubuntu-Experimental systemd[1]: Condition check resulted 
in Bluetooth service being skipped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1838227/+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 1845758] [NEW] Mouse and Touchpad part of Settings when selected keeps flashing

2019-09-27 Thread tomasz kotula
Public bug reported:

Selecting Mouse and Touchpad from Settings results in a display flashing
- seems like between two alternate outputs(?). Changing the window size
or maximising it fixes the issue.

Description:Ubuntu Eoan Ermine (development branch)
Release:19.10

PS. This is my first bug - so apologise if some info is missing etc.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: xorg 1:7.7+19ubuntu12
ProcVersionSignature: Ubuntu 5.3.0-12.13-generic 5.3.0
Uname: Linux 5.3.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu7
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sat Sep 28 15:58:02 2019
DistUpgraded: Fresh install
DistroCodename: eoan
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display 
[8086:0f31] (rev 0c) (prog-if 00 [VGA controller])
   Subsystem: Acer Incorporated [ALI] Atom Processor Z36xxx/Z37xxx Series 
Graphics & Display [1025:0845]
InstallationDate: Installed on 2019-09-28 (0 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20190926.1)
MachineType: Acer E1-510
ProcEnviron:
 LANGUAGE=en_NZ:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_NZ.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-12-generic 
root=UUID=769f232f-476d-440c-9092-7a12ecc631b9 ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/13/2015
dmi.bios.vendor: Acer
dmi.bios.version: V2.14
dmi.board.name: E1-510
dmi.board.vendor: Acer
dmi.board.version: V2.14
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnAcer:bvrV2.14:bd11/13/2015:svnAcer:pnE1-510:pvrV2.14:rvnAcer:rnE1-510:rvrV2.14:cvnAcer:ct10:cvrChassisVersion:
dmi.product.family: Bay Trail-M System
dmi.product.name: E1-510
dmi.product.sku: E1-510_0845_V2.14
dmi.product.version: V2.14
dmi.sys.vendor: Acer
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.99-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.1.6-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20190820-0ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1
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

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


** Tags: amd64 apport-bug corruption eoan ubuntu

** Attachment added: "Screenshot from 2019-09-28 15-59-03.png"
   
https://bugs.launchpad.net/bugs/1845758/+attachment/5292069/+files/Screenshot%20from%202019-09-28%2015-59-03.png

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

Title:
  Mouse and Touchpad part of Settings when selected keeps flashing

Status in xorg package in Ubuntu:
  New

Bug description:
  Selecting Mouse and Touchpad from Settings results in a display
  flashing - seems like between two alternate outputs(?). Changing the
  window size or maximising it fixes the issue.

  Description:  Ubuntu Eoan Ermine (development branch)
  Release:  19.10

  PS. This is my first bug - so apologise if some info is missing etc.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-12.13-generic 5.3.0
  Uname: Linux 5.3.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Sep 28 15:58:02 2019
  DistUpgraded: Fresh install
  DistroCodename: eoan
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display 
[8086:0f31] (rev 0c) (prog-if 00 [VGA controller])
 Subsystem: Acer Incorporated [ALI] Atom Processor Z36xxx/Z37xxx Series 
Graphics & Display [1025:0845]
  InstallationDate: Installed on 2019-09-28 (0 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20190926.1)
  MachineType: Acer E1-510
  ProcEnviron:
   LANGUAGE=en_NZ:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_NZ.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-12-generic 
root=UUID=769f232f-476d-440c-9092-7a12ecc631b9 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/13/2015
  dmi.bios.vendor: Acer
  dmi.bios.version: V2.14
  dmi.board.name: E1-510
  dmi.board.vendo

[Touch-packages] [Bug 1840995] Autopkgtest regression report (apt/1.8.4)

2019-09-27 Thread Ubuntu SRU Bot
All autopkgtests for the newly accepted apt (1.8.4) for disco have finished 
running.
The following regressions have been reported in tests triggered by the package:

reprotest/0.7.8 (s390x)
gcc-snapshot/unknown (armhf)
apt/1.8.4 (amd64, armhf, s390x, ppc64el, arm64, i386)
autopkgtest/5.10ubuntu1 (amd64, i386)
gcc-7/7.4.0-8ubuntu1 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#apt

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  check_stamp() function of apt.systemd.daily should not assume interval
  is a number

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Disco:
  Fix Committed

Bug description:
  [Impact]
  Warning messages when using suffixes in intervals such as d for day

  /usr/lib/apt/apt.systemd.daily: 87: [: Illegal number: 20h

  [Test case]
  Create 99local in apt.conf.d with
  APT::Periodic::Update-Package-Lists "1d";
  and run /usr/lib/apt/apt.systemd.daily - make sure no warning appears.

  [Regression potential]
  The fix replaces -eq 0 checks with = 0 checks which might have different 
behavior in case -eq also accepts some values as equal to 0 that are not 
literally 0 and that now no longer match. But then you'd have to do stuff like 
set the interval to "+0", and it seems unrealistic people do that.

  [Original bug report]
  In the second half of the function there is

  # Calculate the interval in seconds depending on the unit specified
  if [ "${interval%s}" != "$interval" ] ; then
  interval="${interval%s}"
  elif [ "${interval%m}" != "$interval" ] ; then
  interval="${interval%m}"
  interval=$((interval*60))
  elif [ "${interval%h}" != "$interval" ] ; then
  interval="${interval%h}"
  interval=$((interval*60*60))
  else
  interval="${interval%d}"
  interval=$((interval*60*60*24))
  fi

  so, a variable might hold something like "1d", "100m", etc.

  Yet in the first there is a condition

  if [ "$interval" -eq 0 ]; then
  debug_echo "check_stamp: interval=0"
  # treat as no time has passed
  return 1
  fi

  which treats the value as a number and leads to

  /usr/lib/apt/apt.systemd.daily: 87: [: Illegal number: 20h

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1840995/+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 1844634] Autopkgtest regression report (apt/1.8.4)

2019-09-27 Thread Ubuntu SRU Bot
All autopkgtests for the newly accepted apt (1.8.4) for disco have finished 
running.
The following regressions have been reported in tests triggered by the package:

reprotest/0.7.8 (s390x)
gcc-snapshot/unknown (armhf)
apt/1.8.4 (amd64, armhf, s390x, ppc64el, arm64, i386)
autopkgtest/5.10ubuntu1 (amd64, i386)
gcc-7/7.4.0-8ubuntu1 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#apt

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  Removals keep removing dependencies if removal of a package fails

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Disco:
  Fix Committed
Status in apt package in Debian:
  Fix Released

Bug description:
  [Impact]

  Assuming packages A and B, with A depending on B. A has a failing
  prerm script.

  Expected behavior:
  - A fails to be removed, A and B stay unchanged
  Actual behavior:
  - A fails to be removed
  - B is still removed

  This might crash their system (e.g. if A is systemd and B is
  libsystemd0).

  [Test case]
  See Impact. An automated version of the test case 
(test-apt-get-remove-depends) is included and run on autopkgtest.

  [Regression potential]
  We now abort earlier in removal failures, that might be harder to recover 
from or not, nobody really knows.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1844634/+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-09-27 Thread dat
Steve in comment #9 I left a patch against the repo that iirc was
working fine on my machines. Maybe it can be helpful. 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/1805183

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

Status in systemd package in Ubuntu:
  Triaged
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Confirmed

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.

  [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: 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-09-27 Thread Steve Langasek
This was also pointed out specifically in comment #8.

I'm reopening the trunk task on this bug as well since the bug is still
there in eoan.

** Changed in: systemd (Ubuntu)
   Status: Fix Released => 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/1805183

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

Status in systemd package in Ubuntu:
  Triaged
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Confirmed

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.

  [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: 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] Proposed package upload rejected

2019-09-27 Thread Steve Langasek
An upload of systemd to bionic-proposed has been rejected from the
upload queue for the following reason: "wrong use of bashisms in shell
script, does not work as intended".

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

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

Status in systemd package in Ubuntu:
  Triaged
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Confirmed

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.

  [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: 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-09-27 Thread Steve Langasek
+  md5sum $statedir/isc-dhcp-v4-$interface.conf $statedir
/isc-dhcp-v6-$interface.conf &> $oldstate


"&>" is a bashism.  /sbin/dhclient-script uses /bin/sh as its interpreter.  
This does not work as intended.

$ dash
$ echo foo &> output
foo
$ cat output
[1] + Done   echo foo
$ ^D
$

-- 
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:
  Triaged
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Confirmed

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.

  [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: 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 1840995] Re: check_stamp() function of apt.systemd.daily should not assume interval is a number

2019-09-27 Thread Steve Langasek
Hello Ivan, or anyone else affected,

Accepted apt into disco-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/apt/1.8.4 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-disco to verification-done-disco. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-disco. 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: apt (Ubuntu Disco)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-disco

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

Title:
  check_stamp() function of apt.systemd.daily should not assume interval
  is a number

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Disco:
  Fix Committed

Bug description:
  [Impact]
  Warning messages when using suffixes in intervals such as d for day

  /usr/lib/apt/apt.systemd.daily: 87: [: Illegal number: 20h

  [Test case]
  Create 99local in apt.conf.d with
  APT::Periodic::Update-Package-Lists "1d";
  and run /usr/lib/apt/apt.systemd.daily - make sure no warning appears.

  [Regression potential]
  The fix replaces -eq 0 checks with = 0 checks which might have different 
behavior in case -eq also accepts some values as equal to 0 that are not 
literally 0 and that now no longer match. But then you'd have to do stuff like 
set the interval to "+0", and it seems unrealistic people do that.

  [Original bug report]
  In the second half of the function there is

  # Calculate the interval in seconds depending on the unit specified
  if [ "${interval%s}" != "$interval" ] ; then
  interval="${interval%s}"
  elif [ "${interval%m}" != "$interval" ] ; then
  interval="${interval%m}"
  interval=$((interval*60))
  elif [ "${interval%h}" != "$interval" ] ; then
  interval="${interval%h}"
  interval=$((interval*60*60))
  else
  interval="${interval%d}"
  interval=$((interval*60*60*24))
  fi

  so, a variable might hold something like "1d", "100m", etc.

  Yet in the first there is a condition

  if [ "$interval" -eq 0 ]; then
  debug_echo "check_stamp: interval=0"
  # treat as no time has passed
  return 1
  fi

  which treats the value as a number and leads to

  /usr/lib/apt/apt.systemd.daily: 87: [: Illegal number: 20h

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1840995/+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 1844634] Re: Removals keep removing dependencies if removal of a package fails

2019-09-27 Thread Steve Langasek
Hello Julian, or anyone else affected,

Accepted apt into disco-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/apt/1.8.4 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-disco to verification-done-disco. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-disco. 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: apt (Ubuntu Disco)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-disco

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

Title:
  Removals keep removing dependencies if removal of a package fails

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Disco:
  Fix Committed
Status in apt package in Debian:
  Fix Released

Bug description:
  [Impact]

  Assuming packages A and B, with A depending on B. A has a failing
  prerm script.

  Expected behavior:
  - A fails to be removed, A and B stay unchanged
  Actual behavior:
  - A fails to be removed
  - B is still removed

  This might crash their system (e.g. if A is systemd and B is
  libsystemd0).

  [Test case]
  See Impact. An automated version of the test case 
(test-apt-get-remove-depends) is included and run on autopkgtest.

  [Regression potential]
  We now abort earlier in removal failures, that might be harder to recover 
from or not, nobody really knows.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1844634/+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 1845729] Re: problem to print and to scan

2019-09-27 Thread Chris Guiver
Thank you for taking the time to report this bug and helping to make
Ubuntu better. Unfortunately, we cannot work on this bug because your
description didn't include enough information. You may find it helpful
to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at
http://wiki.ubuntu.com/DebuggingProcedures.

At a minimum, we need:
1. The specific steps or actions you took that caused you to encounter the 
problem.
2. The behavior you expected.
3. The behavior you actually encountered (in as much detail as possible).

If you were using software to scan something, what was the software?,
was it an image? text? did you save it and try and print with the same
software? or other software?  The steps you followed were not provided.

Thanks!

** Changed in: xorg (Ubuntu)
   Status: New => Incomplete

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

Title:
  problem to print and to scan

Status in xorg package in Ubuntu:
  Incomplete

Bug description:
  ubuntu 18.04

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-64.73-generic 4.15.18
  Uname: Linux 4.15.0-64-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Fri Sep 27 22:56:38 2019
  DistUpgraded: 2019-09-25 11:35:24,956 DEBUG icon theme changed, re-reading
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] 
(rev 02) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company 82Q35 Express Integrated Graphics 
Controller [103c:2819]
  InstallationDate: Installed on 2019-09-24 (2 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-64-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2019-09-25 (2 days ago)
  dmi.bios.date: 02/26/2009
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: 786F1 v01.28
  dmi.board.name: 0AACh
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvr786F1v01.28:bd02/26/2009:svnHewlett-Packard:pn:pvr:rvnHewlett-Packard:rn0AACh:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53307F
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
  version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.2
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.2
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
  xserver.bootTime: Wed Sep 25 10:33:44 2019
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.outputs:
   product id   24852 
   vendor IVM
  xserver.version: 2:1.18.4-0ubuntu0.8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1845729/+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 1726068] Re: debconf socket closes if aptdaemon/PK client exits

2019-09-27 Thread Steve Langasek
I don't think this test case is well formed, it doesn't describe how to
install the packages with the named backends and it doesn't mention
needing to kill the frontend or when to kill it.

** Changed in: packagekit (Ubuntu Disco)
   Status: In Progress => Incomplete

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

Title:
  debconf socket closes if aptdaemon/PK client exits

Status in apper package in Ubuntu:
  New
Status in aptdaemon package in Ubuntu:
  Fix Released
Status in packagekit package in Ubuntu:
  Fix Released
Status in software-properties package in Ubuntu:
  Invalid
Status in apper source package in Bionic:
  New
Status in aptdaemon source package in Bionic:
  New
Status in packagekit source package in Bionic:
  New
Status in apper source package in Disco:
  New
Status in aptdaemon source package in Disco:
  New
Status in packagekit source package in Disco:
  Incomplete

Bug description:
  [Impact]
  Closing an application using PackageKit or aptdaemon to install packages 
kills the debconf endpoint (because it's a subprocess that's cleaned up), 
causing debconf to use defaults which might lead to wrong results, or even 
cause installations to fail.

  [Solution]
  The solution is to move the end point into a socket-activated systemd unit, 
so that it is independent of the graphical frontend that started the 
transaction. The other advantage is that this offers us restart if the end 
point crashes.

  [Test case]
  1. Install opera deb using packagekit, ensure service is activated
  2. Install opera deb using aptdaemon, ensure service is activated

  Alternatively, you might use another deb that has debconf prompts.

  [Regression potential]
  Systems that do not yet use systemd will fall back to the old method, so 
should not regress.

  Otherwise, if there are bugs, they'd affect the ability to show
  debconf prompts, and behavior would revert to using the defaults.

  There might be some uncertainty if you restart your desktop while the
  helper is running and it does not pick up the new X/Wayland display
  until it restarts (it should fail to connect and restart). Given that
  the helper times out, this should not be an issue in practice, as
  you'd have to logout, login, and start a new install within 60
  seconds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apper/+bug/1726068/+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 1845729] [NEW] problem to print and to scan

2019-09-27 Thread Christian Huyghe
Public bug reported:

ubuntu 18.04

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 4.15.0-64.73-generic 4.15.18
Uname: Linux 4.15.0-64-generic x86_64
.tmp.unity_support_test.0:
 
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
Date: Fri Sep 27 22:56:38 2019
DistUpgraded: 2019-09-25 11:35:24,956 DEBUG icon theme changed, re-reading
DistroCodename: bionic
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] 
(rev 02) (prog-if 00 [VGA controller])
   Subsystem: Hewlett-Packard Company 82Q35 Express Integrated Graphics 
Controller [103c:2819]
InstallationDate: Installed on 2019-09-24 (2 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-64-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
SourcePackage: xorg
UpgradeStatus: Upgraded to bionic on 2019-09-25 (2 days ago)
dmi.bios.date: 02/26/2009
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 786F1 v01.28
dmi.board.name: 0AACh
dmi.board.vendor: Hewlett-Packard
dmi.chassis.type: 6
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: 
dmi:bvnHewlett-Packard:bvr786F1v01.28:bd02/26/2009:svnHewlett-Packard:pn:pvr:rvnHewlett-Packard:rn0AACh:rvr:cvnHewlett-Packard:ct6:cvr:
dmi.product.family: 103C_53307F
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.2
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
xserver.bootTime: Wed Sep 25 10:33:44 2019
xserver.configfile: default
xserver.errors:
 
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id   24852 
 vendor IVM
xserver.version: 2:1.18.4-0ubuntu0.8

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


** Tags: amd64 apport-bug bionic ubuntu

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

Title:
  problem to print and to scan

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu 18.04

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-64.73-generic 4.15.18
  Uname: Linux 4.15.0-64-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Fri Sep 27 22:56:38 2019
  DistUpgraded: 2019-09-25 11:35:24,956 DEBUG icon theme changed, re-reading
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] 
(rev 02) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company 82Q35 Express Integrated Graphics 
Controller [103c:2819]
  InstallationDate: Installed on 2019-09-24 (2 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-64-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2019-09-25 (2 days ago)
  dmi.bios.date: 02/26/2009
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: 786F1 v01.28
  dmi.board.name: 0AACh
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvr786F1v01.28:bd02/26/2009:svnHewlett-Packard:pn:pvr:rvnHewlett-Packard:rn0AACh:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53307F
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
  version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.2
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.2
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouvea

[Touch-packages] [Bug 1818243] Re: systemd-logind takes 25s to stop when rebooting

2019-09-27 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/1818243

Title:
  systemd-logind takes 25s to stop when rebooting

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Cosmic:
  Confirmed

Bug description:
  During reboot:

  Mar 01 14:15:52 P8lpar5 systemd[1]: Stopping Login Service...
  [...]
  Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Failed to abandon session 
scope, ignoring: Connection timed out
  Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Session 5 logged out. Waiting 
for processes to exit.
  Mar 01 14:16:17 P8lpar5 dbus-daemon[2855]: [system] Failed to activate 
service 'org.freedesktop.systemd1': timed out (service_start_timeout=
  25000ms)
  Mar 01 14:16:17 P8lpar5 systemd[1]: Stopped Login Service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818243/+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 1818243] Re: systemd-logind takes 25s to stop when rebooting

2019-09-27 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/1818243

Title:
  systemd-logind takes 25s to stop when rebooting

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Cosmic:
  Confirmed

Bug description:
  During reboot:

  Mar 01 14:15:52 P8lpar5 systemd[1]: Stopping Login Service...
  [...]
  Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Failed to abandon session 
scope, ignoring: Connection timed out
  Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Session 5 logged out. Waiting 
for processes to exit.
  Mar 01 14:16:17 P8lpar5 dbus-daemon[2855]: [system] Failed to activate 
service 'org.freedesktop.systemd1': timed out (service_start_timeout=
  25000ms)
  Mar 01 14:16:17 P8lpar5 systemd[1]: Stopped Login Service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818243/+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 1637800] Re: add a motd script for news

2019-09-27 Thread Andreas Hasenack
I'm addressing this in a new upload.

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

Title:
  add a motd script for news

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed

Bug description:
  Add a new update-motd script for printing news and/or important
  notices.

  == SRU ==

  [IMPACT]
  We should add important security messages or other news to the MOTD.

  [TEST CASE]
  Login to the system and ensure that the "news" section of the motd is 
displayed.  Note that you might need to force trigger an update by running 
'sudo update-motd'.

  [REGRESSION POTENTIAL]
  No reasonable regression potential.  The script simply prints 2 lines of text 
to the MOTD.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1637800/+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 1832672] Re: systemd-resolve not ignoring comments in /etc/hosts

2019-09-27 Thread Dan Streetman
** Also affects: systemd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

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

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

** Bug watch added: github.com/systemd/systemd/issues #10779
   https://github.com/systemd/systemd/issues/10779

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/10779
   Importance: Unknown
   Status: Unknown

** Tags added: next-ddstreet systemd

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

Title:
  systemd-resolve not ignoring comments in /etc/hosts

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04

  $ LANG=C apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.22
Candidate: 237-3ubuntu10.22
Version table:
   *** 237-3ubuntu10.22 500
  500 http://ch.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10.19 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   237-3ubuntu10 500
  500 http://ch.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  500 http://mirrors.kernel.org/ubuntu bionic/main amd64 Packages

  
  $ head -1 /etc/hosts
  127.0.2.1 foo # bar

  $ /usr/bin/systemd-resolve -4 bar

  expected
  --
  bar: resolve call failed: 'bar' not found

  What happened instead
  -
  bar: 127.0.2.1


  HOSTS(5)  
  > Text from a "#" character until the end of the line is a comment, and is 
ignored.

  This is fixed in upstream:
  https://github.com/systemd/systemd/issues/10779
  
https://github.com/systemd/systemd/commit/bd0052777981044cf54a1e9d6e3acb1c3d813656

  Please backport to current LTS version.
  I accidentally connected to wrong systems because of this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1832672/+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 1831468] Re: 'upstream' tests fail, usually TEST-18, TEST-19, TEST-25, and/or TEST-27

2019-09-27 Thread Dan Streetman
** Changed in: systemd (Ubuntu)
   Status: In Progress => 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/1831468

Title:
  'upstream' tests fail, usually TEST-18, TEST-19, TEST-25, and/or
  TEST-27

Status in systemd package in Ubuntu:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Won't Fix

Bug description:
  [impact]

  some tests in the 'upstream' test suite fail on disco for ppc64el, e.g.:
  FAILED TESTS:  test/TEST-18-FAILUREACTION test/TEST-19-DELEGATE 
test/TEST-25-IMPORT test/TEST-27-STDOUTFILE

  [test case]

  check autopkgtest logs, e.g.:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/ppc64el/s/systemd/20190601_160043_a5281@/log.gz

  [regression potential]

  TBD

  [other info]

  this appears to fail only on ppc64el on disco and eoan, not cosmic or
  earlier or any other archs, but that is only from checking a few logs
  from other releases/archs, and without any investigation into the
  problem yet, so could be incorrect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831468/+subscriptions

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


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

2019-09-27 Thread Dan Streetman
@evvers I think Ubuntu CI is at least mostly stable, for now, and
hopefully we can get the tests un-blacklisted soon, but since we're
doing all that work in github and debian bugs, I don't think we need to
keep this bug open, so I'll close it; let me know if you're prefer to
keep it open.

** Changed in: systemd (Ubuntu)
   Status: Confirmed => 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/1829829

Title:
  Ubuntu CI has been flaky for a week

Status in systemd package in Ubuntu:
  Won't Fix

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

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

[Touch-packages] [Bug 1827753] Re: udev package doesn't mark as a configuration file fbdev-blacklist.conf

2019-09-27 Thread Dan Streetman
@rbalint, I think @chaitrex has a point in this bug that /lib/modprobe.d
/fbdev-blacklist.conf isn't end-user editable without being overwritten
by udev package update.

Additionally, the Ubuntu (but not Debian) kmod package ships
/etc/modprobe.d/blacklist-framebuffer.conf which contains almost all the
drivers in fbdev-blacklist.conf; maybe we should remove fbdev-
blacklist.conf from the Ubuntu systemd package?  It might be worth
seeing if Debian is interested in removing it also, or at least moving
it to /etc/modprobe.d so it becomes a config file.  what do you think?

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

Title:
  udev package doesn't mark as a configuration file fbdev-blacklist.conf

Status in systemd package in Ubuntu:
  New

Bug description:
  System information
  

  $ lsb_release -rd
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04

  $ apt-cache policy udev
  udev:
    Installed: 237-3ubuntu10.21
    Candidate: 237-3ubuntu10.21
    Version table:
   *** 237-3ubuntu10.21 500
  500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10.19 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   237-3ubuntu10 500
  500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

   Problem
  =

  The `udev` package includes `/lib/modprobe.d/fbdev-blacklist.conf`, a
  configuration file blacklisting several kernel modules. It's not
  listed as a configuration file in the package, though:

  $ cat /var/lib/dpkg/info/udev.conffiles
  /etc/init.d/udev
  /etc/udev/udev.conf

  This means that, if I want to go ahead and use the `sisfb` kernel
  module, for example, I unblacklist it in the two files it's
  blacklisted in. However, any updated version of `udev` that's
  installed will throw away my changes to `/lib/modprobe.d/fbdev-
  blacklist.conf` by simply overwriting the file and again blacklist the
  kernel module, which doesn't work well when the system is being used
  by someone very new to computers.

  I can't avoid that by simply telling APT to leave configuration files
  alone because the `.conf` file here technically isn't a configuration
  file. Also, `chattr +i /lib/modprobe.d/fbdev-blacklist.conf` causes
  APT to require someone with technical knowledge to take extra effort
  to repair things when the end user agrees to an install in the weekly
  GUI reminder of new software.

   Request
  =

  Please mark `/lib/modprobe.d/fbdev-blacklist.conf` as a configuration
  file in `udev`.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: udev 237-3ubuntu10.21
  ProcVersionSignature: Ubuntu 4.15.0-47.50-generic 4.15.18
  Uname: Linux 4.15.0-47-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  CurrentDesktop: XFCE
  CustomUdevRuleFiles: 70-snap.core.rules 70-snap.cnctsun.rules 
70-snap.cncra2yr.rules 70-snap.cncra.rules 60-vboxdrv.rules
  Date: Sat May  4 21:51:42 2019
  InstallationDate: Installed on 2018-12-27 (128 days ago)
  InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 020: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-47-generic 
root=/dev/mapper/xubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/27/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.10.0
  dmi.board.name: 0839Y6
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.10.0:bd09/27/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0839Y6:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1827753/+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 1827753] Re: udev package doesn't mark as a configuration file fbdev-blacklist.conf

2019-09-27 Thread Dan Streetman
@chaitrex, while it's not an acutal fix, modprobe does filter out
duplicate named files in the modprobe.d search list, and /lib/modprobe.d
is at the end of the list; so if you simply copy /lib/modprobe.d/fbdev-
blacklist.conf to /etc/modprobe.d/fbdev-blacklist.conf, then you can
edit the file in /etc/modprobe.d and the contents of the file in
/lib/modprobe.d will be ignored by any calls to modprobe.  Upgrading the
udev package will also not touch the /etc/modprobe.d/fbdev-
blacklist.conf file since it did not place it there.

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

Title:
  udev package doesn't mark as a configuration file fbdev-blacklist.conf

Status in systemd package in Ubuntu:
  New

Bug description:
  System information
  

  $ lsb_release -rd
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04

  $ apt-cache policy udev
  udev:
    Installed: 237-3ubuntu10.21
    Candidate: 237-3ubuntu10.21
    Version table:
   *** 237-3ubuntu10.21 500
  500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10.19 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   237-3ubuntu10 500
  500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

   Problem
  =

  The `udev` package includes `/lib/modprobe.d/fbdev-blacklist.conf`, a
  configuration file blacklisting several kernel modules. It's not
  listed as a configuration file in the package, though:

  $ cat /var/lib/dpkg/info/udev.conffiles
  /etc/init.d/udev
  /etc/udev/udev.conf

  This means that, if I want to go ahead and use the `sisfb` kernel
  module, for example, I unblacklist it in the two files it's
  blacklisted in. However, any updated version of `udev` that's
  installed will throw away my changes to `/lib/modprobe.d/fbdev-
  blacklist.conf` by simply overwriting the file and again blacklist the
  kernel module, which doesn't work well when the system is being used
  by someone very new to computers.

  I can't avoid that by simply telling APT to leave configuration files
  alone because the `.conf` file here technically isn't a configuration
  file. Also, `chattr +i /lib/modprobe.d/fbdev-blacklist.conf` causes
  APT to require someone with technical knowledge to take extra effort
  to repair things when the end user agrees to an install in the weekly
  GUI reminder of new software.

   Request
  =

  Please mark `/lib/modprobe.d/fbdev-blacklist.conf` as a configuration
  file in `udev`.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: udev 237-3ubuntu10.21
  ProcVersionSignature: Ubuntu 4.15.0-47.50-generic 4.15.18
  Uname: Linux 4.15.0-47-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  CurrentDesktop: XFCE
  CustomUdevRuleFiles: 70-snap.core.rules 70-snap.cnctsun.rules 
70-snap.cncra2yr.rules 70-snap.cncra.rules 60-vboxdrv.rules
  Date: Sat May  4 21:51:42 2019
  InstallationDate: Installed on 2018-12-27 (128 days ago)
  InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 020: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. XPS 13 9360
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-47-generic 
root=/dev/mapper/xubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/27/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.10.0
  dmi.board.name: 0839Y6
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.10.0:bd09/27/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0839Y6:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9360
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1827753/+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 1637800] Re: add a motd script for news

2019-09-27 Thread Andreas Hasenack
+ [ -d /run/systemd/system ]
+ systemctl --system daemon-reload
+ deb-systemd-invoke start motd-news.service
motd-news.service is a disabled or a static unit, not starting it.
+ [ -d /run/systemd/system ]
+ systemctl --system daemon-reload
+ deb-systemd-invoke start motd-news.timer
motd-news.timer is a disabled or a static unit, not starting it.

The xenial package is not using debhelper, and the manual entries in
postinst do not enable it, just try to start it.

This is the bit that dh_systemd_enable adds to postinst in bionic, for example:
# Automatically added by dh_systemd_enable/11.1.6ubuntu2
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask 'motd-news.timer' >/dev/null || true

# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'motd-news.timer'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'motd-news.timer' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need 
to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'motd-news.timer' >/dev/null || 
true
fi
fi

And then come the deb-systemd-invoke start bits that were added manually
to the xenial package.

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

Title:
  add a motd script for news

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed

Bug description:
  Add a new update-motd script for printing news and/or important
  notices.

  == SRU ==

  [IMPACT]
  We should add important security messages or other news to the MOTD.

  [TEST CASE]
  Login to the system and ensure that the "news" section of the motd is 
displayed.  Note that you might need to force trigger an update by running 
'sudo update-motd'.

  [REGRESSION POTENTIAL]
  No reasonable regression potential.  The script simply prints 2 lines of text 
to the MOTD.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1637800/+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 1838208] Re: Wifi stops responding sporadically on lenovo-yoga-720-15ikb

2019-09-27 Thread Asif Youssuff
This stopped happening at some point in the last week or so.

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

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

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

Title:
  Wifi stops responding sporadically on lenovo-yoga-720-15ikb

Status in linux package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released

Bug description:
  I can make this happen by trying to upload a large file using Firefox
  Nightly to https://send.firefox.com/ Within a few seconds (like 10-15)
  my wifi stops responding.

  Restarting network manager via service network-manager restart
  temporarily resolves the issue.

  This issue began appearing a week or so ago -- almost definitely not a
  month ago; my wifi used to be fine previously.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: network-manager 1.18.0-1ubuntu5
  ProcVersionSignature: Ubuntu 5.2.0-8.9-generic 5.2.0
  Uname: Linux 5.2.0-8-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Jul 28 14:59:13 2019
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2018-10-31 (270 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  IpRoute:
   default via 192.168.69.1 dev wlp1s0 proto dhcp metric 600 
   169.254.0.0/16 dev wlp1s0 scope link metric 1000 
   192.168.69.0/24 dev wlp1s0 proto kernel scope link src 192.168.69.45 metric 
600
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to eoan on 2018-11-02 (268 days ago)
  nmcli-dev:
   DEVICE  TYPE  STATE IP4-CONNECTIVITY  IP6-CONNECTIVITY  
DBUS-PATH  CONNECTION   CON-UUID
  CON-PATH   
   wlp1s0  wifi  connected full  limited   
/org/freedesktop/NetworkManager/Devices/2  dd-wrt-vap-5g 1  
21dd3ba5-f26c-434a-8a95-a87ddd1eb8d5  
/org/freedesktop/NetworkManager/ActiveConnection/1 
   p2p-dev-wlp1s0  wifi-p2p  disconnected  none  none  
/org/freedesktop/NetworkManager/Devices/3  --   --  
  -- 
   lo  loopback  unmanaged unknown   unknown   
/org/freedesktop/NetworkManager/Devices/1  --   --  
  --
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.18.0   connected  started  full  enabled enabled  
enabled  enabled  enabled
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  asif   1938 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 19.10
  InstallationDate: Installed on 2018-10-31 (276 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 13d3:5621 IMC Networks EasyCamera
   Bus 001 Device 003: ID 06cb:0081 Synaptics, Inc. 
   Bus 001 Device 002: ID 8087:0a2b Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: LENOVO 80X7
  NonfreeKernelModules: wl
  Package: linux (not installed)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.2.0-8-generic 
root=UUID=6c974fe8-3286-438d-9acd-d422be92ad9f ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 5.2.0-8.9-generic 5.2.0
  RelatedPackageVersions:
   linux-restricted-modules-5.2.0-8-generic N/A
   linux-backports-modules-5.2.0-8-generic  N/A
   linux-firmware   1.181
  Tags:  eoan wayland-session
  Uname: Linux 5.2.0-8-generic x86_64
  UpgradeStatus: Upgraded to eoan on 2018-11-02 (273 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 07/19/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 4MCN33WW(V2.05)
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chass

[Touch-packages] [Bug 1783994] Re: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc

2019-09-27 Thread Bug Watch Updater
** Changed in: systemd
   Status: Unknown => 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/1783994

Title:
  systemd spams log with "Failed to dissect: Input/output error" on
  systems with mmc

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  If a device has an mmc installed, systemd-gpt-auto-generator will fail 
because of "special partition" (rpmb, boot) and record a log message: 
  systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error
  This issue was discussed here:  https://github.com/systemd/systemd/issues/5806
  and a fix is proposed for new systemd versions. Please include in bionic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1783994/+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 1840946] Re: [FFe] include cloud-id in user-agent string

2019-09-27 Thread Andreas Hasenack
** Also affects: base-files (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: base-files (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Disco)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Disco)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Bionic)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Description changed:

  I'm preemptively filing this bug in case this isn't uploaded before the
  feature freeze.
  
  We would like to include a cloud_id/$name parameter to the user-agent
  string that is sent to https://motd.ubuntu.com. This will allow the
  server part of motd.ubuntu.com to serve cloud-specific content if one is
  available.
  
  There is an MP for this already at
  https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git
  /base-files/+merge/371370
- 
- That MP is also fixing a bug where curl would not return a failure if
- the server status is not 200.

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

Title:
  [FFe] include cloud-id in user-agent string

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Disco:
  In Progress

Bug description:
  I'm preemptively filing this bug in case this isn't uploaded before
  the feature freeze.

  We would like to include a cloud_id/$name parameter to the user-agent
  string that is sent to https://motd.ubuntu.com. This will allow the
  server part of motd.ubuntu.com to serve cloud-specific content if one
  is available.

  There is an MP for this already at
  https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git
  /base-files/+merge/371370

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1840946/+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 1800836] Re: systemd-networkd doesn't process IPv6 RA properly

2019-09-27 Thread Dan Streetman
> For me it looks like the issue is fixed in this pull request: 
> https://github.com/systemd/systemd/pull/3242

that's included in Bionic already.

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

Title:
  systemd-networkd doesn't process IPv6 RA properly

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  The gateways/firewalls in our DC are highly available and when there
  is a failover their IPv6 VIP (fe80::1) moves from the master to the
  backup one.

  We found that only our Bionic VMs behind those gateways had issues
  after a failover. Those Bionic VMs were all running systemd-networkd
  (from netplan) and before the failover they had:

  $ ip -6 route
  ...
  default via fe80::1 dev eth0 proto ra metric 1024 pref medium

  But after a failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1

  And after another failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1
  nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1

  
  This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as 
their default gateway even when this gateway is unavailable:

  $ ip -6 route get ::
  :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src 
fe80::a800:ff:fe51:8c37 metric 1024 pref medium

  
  We concluded it was a systemd-networkd bug after checking that the following 
combinations were NOT affected:

  1) Xenial+4.4 kernel
  2) Xenial+4.15 kernel
  3) Bionic+ifupdown

  
  Additional information:

  $ apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.3
Candidate: 237-3ubuntu10.3
Version table:
   *** 237-3ubuntu10.3 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  Uname: Linux 4.15.0-38-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  Date: Wed Oct 31 08:47:28 2018
  Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb'
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 
vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: Ubuntu-1.8.2-1ubuntu1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-xenial
  dmi.modalias: 
dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-xenial
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836/+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 1800836] Re: systemd-networkd doesn't process IPv6 RA properly

2019-09-27 Thread Dan Streetman
@sdeziel can you provide more specific simplified steps to reproduce
this?  Like, specific networkd (or netplan) config file(s), and steps to
reproduce?

** Changed in: systemd (Ubuntu)
   Status: Confirmed => 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/1800836

Title:
  systemd-networkd doesn't process IPv6 RA properly

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  The gateways/firewalls in our DC are highly available and when there
  is a failover their IPv6 VIP (fe80::1) moves from the master to the
  backup one.

  We found that only our Bionic VMs behind those gateways had issues
  after a failover. Those Bionic VMs were all running systemd-networkd
  (from netplan) and before the failover they had:

  $ ip -6 route
  ...
  default via fe80::1 dev eth0 proto ra metric 1024 pref medium

  But after a failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1

  And after another failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1
  nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1

  
  This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as 
their default gateway even when this gateway is unavailable:

  $ ip -6 route get ::
  :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src 
fe80::a800:ff:fe51:8c37 metric 1024 pref medium

  
  We concluded it was a systemd-networkd bug after checking that the following 
combinations were NOT affected:

  1) Xenial+4.4 kernel
  2) Xenial+4.15 kernel
  3) Bionic+ifupdown

  
  Additional information:

  $ apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.3
Candidate: 237-3ubuntu10.3
Version table:
   *** 237-3ubuntu10.3 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  Uname: Linux 4.15.0-38-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  Date: Wed Oct 31 08:47:28 2018
  Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb'
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 
vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: Ubuntu-1.8.2-1ubuntu1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-xenial
  dmi.modalias: 
dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-xenial
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836/+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 1840946] Re: [FFe] include cloud-id in user-agent string

2019-09-27 Thread Andreas Hasenack
** Also affects: base-files (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

Title:
  [FFe] include cloud-id in user-agent string

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Disco:
  In Progress

Bug description:
  I'm preemptively filing this bug in case this isn't uploaded before
  the feature freeze.

  We would like to include a cloud_id/$name parameter to the user-agent
  string that is sent to https://motd.ubuntu.com. This will allow the
  server part of motd.ubuntu.com to serve cloud-specific content if one
  is available.

  There is an MP for this already at
  https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git
  /base-files/+merge/371370

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1840946/+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 1783994] Re: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc

2019-09-27 Thread Dan Streetman
>From a quick read of the upstream bug, it seems like this requires commits:
7be1420f44465a96d098a33c12c5a61dcefb14aa
a3a3b6131eb2c44b3b94df973e6edd2e4c8d2095
cde942f61bf231ea4a0d50780cdb4e744458daeb

The first 2 are in Bionic already, so as @marvin24 states in comment 1
only the 3rd should be needed.

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

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

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

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

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Tags added: next-ddstreet systemd

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

Title:
  systemd spams log with "Failed to dissect: Input/output error" on
  systems with mmc

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  If a device has an mmc installed, systemd-gpt-auto-generator will fail 
because of "special partition" (rpmb, boot) and record a log message: 
  systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error
  This issue was discussed here:  https://github.com/systemd/systemd/issues/5806
  and a fix is proposed for new systemd versions. Please include in bionic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1783994/+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 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-27 Thread Balint Reczey
** Changed in: systemd (Ubuntu)
   Status: Confirmed => 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/1843755

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= which may be used to also trigger a unit when the
    system clock is changed or the local timezone is
    modified. systemd-run has been updated to make these options easily
    accessible from the command line for tran

[Touch-packages] [Bug 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

2019-09-27 Thread Balint Reczey
Thanks all! I'm uploading it to Eoan first, then schedule for SRU to
Disco.

Eoan package is tested in ppa:ci-train-ppa-service/3797 .

-- 
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:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in qemu source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed

Bug 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 1783994] Re: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc

2019-09-27 Thread Dan Streetman
** Bug watch added: github.com/systemd/systemd/issues #5806
   https://github.com/systemd/systemd/issues/5806

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/5806
   Importance: Unknown
   Status: Unknown

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

Title:
  systemd spams log with "Failed to dissect: Input/output error" on
  systems with mmc

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  If a device has an mmc installed, systemd-gpt-auto-generator will fail 
because of "special partition" (rpmb, boot) and record a log message: 
  systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error
  This issue was discussed here:  https://github.com/systemd/systemd/issues/5806
  and a fix is proposed for new systemd versions. Please include in bionic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1783994/+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 1759014] Re: Netplan has no way to control DHCP client

2019-09-27 Thread Dan Streetman
>From reading the comments, I believe the only systemd issue was fixed in
bug 1804478, so I marked this as fix released for systemd.  If that's
incorrect and there is still a systemd problem, please feel free to
reopen and comment, or open new bug.

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

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

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

** Changed in: systemd (Ubuntu Disco)
   Status: Confirmed => 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/1759014

Title:
  Netplan has no way to control DHCP client

Status in netplan:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in netplan.io source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]
  DHCP configurations where custom settings (routes, nameservers, etc.) need to 
be applied.

  [Test case]
  1) Configure netplan for the particulars of the network by configuring an 
appropriate dhcp{4,6}-override stanza:

  network:
version: 2
ethernets:
  engreen:
dhcp4: true
dhcp4-overrides:
  use-dns: false
  use-routes: false
  route-metric: 

  Additionally, if so required, add a custom DNS / routes to the
  configuration. e.g.

nameservers:
  search: [lab, kitchen]
  addresses: [8.8.8.8]

  (See https://netplan.io/reference#dhcp-overrides for the available
  options)

  2) Run 'netplan apply' or reboot to have the configuration applied.
  3) Validate that the routes / DNS are properly ignored and/or replaced by the 
defined values.

  [Regression potential]
  Minimal; this adds new values to the configuration generated for networkd or 
NetworkManager. Existing configurations will remain unchanged, but new 
configurations using the dhcp{4,6}-overrides fields will benefit from 
additional flexibility.

  
  ---

  
  Currently DHCP appears to be an all or nothing boolean, which is insufficient 
for many network configurations.

  Ideally all of the DHCP configuration options supported by systemd would also 
be supported in netplan:
  
https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BDHCP%5D%20Section%20Options

  As an example, consider the following netplan configuration:

  network:
    version: 2
    renderer: networkd
    ethernets:
  enp0s3:
    dhcp4: yes
    nameservers: [8.8.8.8,8.8.4.4]

  After running netplan apply I check the nameservers with systemd-
  resolve --status and it shows:

  DNS Servers: 8.8.8.8
   8.8.4.4
   192.168.1.1

  Here, "192.168.1.1" was provided by my DHCP server.  On this
  particular node, I only want the manually configured DNS servers, but
  netplan has no way to indicate this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1759014/+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 1833025] Re: bcache partition within fstab prevents from booting

2019-09-27 Thread Bug Watch Updater
** Changed in: systemd
   Status: Unknown => 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/1833025

Title:
  bcache partition within fstab prevents from booting

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Disco:
  In Progress

Bug description:
  Almost every boot attempt drops to initramfs prompt, requiring me to
  type echo /dev/sdb >/sys/fs/bcache/register. Logs showing that attempt
  to register caching device via udev rules was made, but failed with
  code == 1.

  Looks like an regression were introduced in upstream (systemd 240)
  which breaks the order of udev commands.

  Here is an upstream bug https://github.com/systemd/systemd/issues/11368
  And here is a patch for this issue 
https://github.com/systemd/systemd/pull/11891
  Can you, please merge this patch to disco branch?

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1833025/+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 1833046] Re: 18.04 timesyncd stop working after rack controller installed

2019-09-27 Thread Bug Watch Updater
** Changed in: systemd
   Status: Unknown => 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/1833046

Title:
  18.04 timesyncd stop working after rack controller installed

Status in MAAS:
  Invalid
Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  This is an upstream bug from systemd, see details here:

  https://github.com/systemd/systemd/issues/7883

  But it's directly triggered by install maas -> avahi-daemon enabled ->
  nsswitch.conf changed.

  `timedatectl status` will always return "System clock synchronized:
  no" on rack controller host.

  systemd-timesyncd will exit immediately after start, strace
  /lib/systemd/systemd-timesyncd give me the following error:

  ```
  writev(2, [{iov_base="Cannot resolve user name systemd"..., iov_len=58}, 
{iov_base="\n", iov_len=1}], 2Cannot resolve user name systemd-timesync: No 
such process
  ) = 59
  exit_group(1)   = ?
  +++ exited with 1 +++
  ```

  I'm not sure if maas can provide some workaround on this by default,
  right now I fix it by:

  sudo useradd -r systemd-timesync

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1833046/+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 1845689] [NEW] Bluetooth loops when pairing Connecting MPOW T5 headset

2019-09-27 Thread Johnny Ooi
Public bug reported:

I am running ubuntu Disco, recently upgraded from Beaver.

Now when I pair my MPOW T5 bluetooth earbuds, they will pair, connect,
then Bluetooth on the machine will restart. This is visible by the
Bluetooth applet showing Bluetooth being switched off then on again.
This will happen a few times, then bluetooth will lock up, rendering it
and the settings applet frozen. Requiring a restart to fix.

It is like something in Bluetooth subsystem is crashing out when pairing
with the T5

I used to use this MPOW T5 with ubuntu Beaver without issue and am
tempted just to roll back to my image from then But here's hoping
someone can help identify why this is happening.

I am also using this on my Disco installation on my Pixelbook (which was
a clean install, not an upgrade), so maybe that's something worth
noting.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.0.0-29.31-generic 5.0.21
Uname: Linux 5.0.0-29-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC1:  johnny 2201 F pulseaudio
 /dev/snd/controlC0:  johnny 2201 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Fri Sep 27 17:34:49 2019
InstallationDate: Installed on 2018-12-31 (269 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Title: Bluetooth sound card not detected
UpgradeStatus: Upgraded to disco on 2019-09-21 (6 days ago)
dmi.bios.date: 04/08/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.5
dmi.board.asset.tag: Tag 12345
dmi.board.name: W35xSS_370SS
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: Notebook
dmi.chassis.version: N/A
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/08/2014:svnNotebook:pnW35xSS_370SS:pvrNotApplicable:rvnNotebook:rnW35xSS_370SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: W35xSS_370SS
dmi.product.sku: Not Applicable
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook

** Affects: alsa-driver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco

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

Title:
  Bluetooth loops when pairing Connecting MPOW T5 headset

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  I am running ubuntu Disco, recently upgraded from Beaver.

  Now when I pair my MPOW T5 bluetooth earbuds, they will pair, connect,
  then Bluetooth on the machine will restart. This is visible by the
  Bluetooth applet showing Bluetooth being switched off then on again.
  This will happen a few times, then bluetooth will lock up, rendering
  it and the settings applet frozen. Requiring a restart to fix.

  It is like something in Bluetooth subsystem is crashing out when
  pairing with the T5

  I used to use this MPOW T5 with ubuntu Beaver without issue and am
  tempted just to roll back to my image from then But here's hoping
  someone can help identify why this is happening.

  I am also using this on my Disco installation on my Pixelbook (which
  was a clean install, not an upgrade), so maybe that's something worth
  noting.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.0.0-29.31-generic 5.0.21
  Uname: Linux 5.0.0-29-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  johnny 2201 F pulseaudio
   /dev/snd/controlC0:  johnny 2201 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 27 17:34:49 2019
  InstallationDate: Installed on 2018-12-31 (269 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Title: Bluetooth sound card not detected
  UpgradeStatus: Upgraded to disco on 2019-09-21 (6 days ago)
  dmi.bios.date: 04/08/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: W35xSS_370SS
  dmi.board.vendor: Notebook
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/08/2014:svnNotebook:pnW35xSS_370SS:pvrNotApplicable:rvnNotebook:rnW35xSS_370SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
  dmi.product.family: Not Applicable
  dmi.prod

[Touch-packages] [Bug 1833025] Re: bcache partition within fstab prevents from booting

2019-09-27 Thread Dan Streetman
The commits that cause this aren't in Bionic, and the commits that fix
this are already in Eoan; so the fix is only needed in Disco.

** Bug watch added: github.com/systemd/systemd/issues #11368
   https://github.com/systemd/systemd/issues/11368

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/11368
   Importance: Unknown
   Status: Unknown

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

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

** Changed in: systemd (Ubuntu Disco)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

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

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

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

Title:
  bcache partition within fstab prevents from booting

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Disco:
  In Progress

Bug description:
  Almost every boot attempt drops to initramfs prompt, requiring me to
  type echo /dev/sdb >/sys/fs/bcache/register. Logs showing that attempt
  to register caching device via udev rules was made, but failed with
  code == 1.

  Looks like an regression were introduced in upstream (systemd 240)
  which breaks the order of udev commands.

  Here is an upstream bug https://github.com/systemd/systemd/issues/11368
  And here is a patch for this issue 
https://github.com/systemd/systemd/pull/11891
  Can you, please merge this patch to disco branch?

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1833025/+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 1833046] Re: 18.04 timesyncd stop working after rack controller installed

2019-09-27 Thread Dan Streetman
@hyuwang the commit that fixes this appears to be:
https://github.com/systemd/systemd/pull/7884/commits/444c1915f94d7109b5fd97277b049ed17289848d

and that's already contained in systemd in Bionic (and later).  Are you
having this problem on Xenial?

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

** Bug watch added: github.com/systemd/systemd/issues #7883
   https://github.com/systemd/systemd/issues/7883

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/7883
   Importance: Unknown
   Status: Unknown

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

Title:
  18.04 timesyncd stop working after rack controller installed

Status in MAAS:
  Invalid
Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  This is an upstream bug from systemd, see details here:

  https://github.com/systemd/systemd/issues/7883

  But it's directly triggered by install maas -> avahi-daemon enabled ->
  nsswitch.conf changed.

  `timedatectl status` will always return "System clock synchronized:
  no" on rack controller host.

  systemd-timesyncd will exit immediately after start, strace
  /lib/systemd/systemd-timesyncd give me the following error:

  ```
  writev(2, [{iov_base="Cannot resolve user name systemd"..., iov_len=58}, 
{iov_base="\n", iov_len=1}], 2Cannot resolve user name systemd-timesync: No 
such process
  ) = 59
  exit_group(1)   = ?
  +++ exited with 1 +++
  ```

  I'm not sure if maas can provide some workaround on this by default,
  right now I fix it by:

  sudo useradd -r systemd-timesync

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1833046/+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 1837914] Re: restart systemd-jounald fails

2019-09-27 Thread Bug Watch Updater
** Changed in: systemd
   Status: Unknown => 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/1837914

Title:
  restart systemd-jounald fails

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

Bug description:
  While restarting systemd-jounald, the following error message occurs:

  systemd-journald[28007]: Assertion 'f' failed at ../src/journal
  /journal-file.c:143, function journal_file_close(). Aborting.

  release: Ubuntu 16.04.5 LTS
  systemd version: 229-4ubuntu21.22

  This issue is reported at
  https://github.com/systemd/systemd/issues/12400 and solved at
  https://github.com/systemd/systemd/pull/12679

  Please cherry-pick this fix to the ubuntu16.04 package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1837914/+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 1833193] Re: systemd-networkd fails to apply static IPv4 when the static IP is the same as previously configured by DHCP

2019-09-27 Thread Dan Streetman
Can you paste an example networkd config file, and repro instructions,
that reproduces this problem?

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

Title:
  systemd-networkd fails to apply static IPv4 when the static IP is the
  same as previously configured by DHCP

Status in systemd package in Ubuntu:
  New

Bug description:
  In bionic, running systemd 237-3ubuntu10.22 and netplan.io
  0.97-0ubuntu1~18.04.1, systemd-networkd fails to configure an
  interface with a static IPv4 address if the statically confiugred
  address is the same as the interface already has gotten from DHCP.

  This will cause the interface to loose its IP address when the DHCP
  lease exires, even though you've told netplan to configure it as
  static.

  I expect systemd-networkd to actually configure an IP address as
  static, regardless of what address the interface has before from DHCP.

  # lsb_release  -rd
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04

  # apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.22

  # apt-cache policy netplan.io
  netplan.io:
Installed: 0.97-0ubuntu1~18.04.1

  A paste of systemd-networkd's debug log when I run "netplan apply" and
  the interface already has the static IP configured from DHCP.

  It seems like upon a restart, systemd-networkd will allways add
  whatever IP config it had before the service stopped, and then apply
  changes (if any). Since my new config has the same IP as it already
  had, it does nothing even though the new config has static
  configuration.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1833193/+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 1836695] Re: Netplan ignores static routes when using DHCP

2019-09-27 Thread Dan Streetman
@pedersen-larserik, @zagarin, can either of you could test your netplan
config on 19.10 (Eoan) to verify things work for you there?

** Description changed:

+ [impact]
+ 
+ a systemd-networkd configuration that uses ipv4 dhcp but ignores the
+ dhcp-provided route, and instead sets up a static route, and also does
+ not include a static ipv4 address, fails to actually create the static
+ route.
+ 
+ This is due to networkd attempting to set up the static route before the
+ dhcp ipv4 address is assigned, and the kernel does not allow creation of
+ the route before setting up corresponding ipv4 address.
+ 
+ this results in a network that does have the dhcp-provided ipv4 address,
+ but is missing both its dhcp-provided route (because networkd is
+ configured to ignore it) and the static route (because networkd was not
+ able to create it).
+ 
+ [test case]
+ 
+ (remove or unconfigure netplan, so it will not conflict with this manual
+ networkd configuration)
+ 
+ create a networkd config file, e.g.:
+ 
+ $ cat /etc/systemd/network/10-eth0.network 
+ [Match]
+ Name=eth0
+ 
+ [Network]
+ DHCP=ipv4
+ 
+ [Route]
+ Destination=10.0.0.0/8
+ Gateway=10.202.51.1
+ 
+ [DHCP]
+ UseRoutes=false
+ 
+ 
+ then *reboot* the system, and check that the static route was not applied:
+ 
+ $ ip r
+ 10.202.51.0/24 dev eth0 proto kernel scope link src 10.202.51.254 
+ 
+ 
+ note that because networkd does not remove ipv4 addresses that it manages 
(including dhcpv4 addresses), restarting networkd after the initial boot
+ will correctly create the static route, e.g.:
+ 
+ ubuntu@lp1836695-b:~$ ip r
+ 10.202.51.0/24 dev eth0 proto kernel scope link src 10.202.51.254 
+ ubuntu@lp1836695-b:~$ sudo systemctl restart systemd-networkd
+ ubuntu@lp1836695-b:~$ ip r
+ 10.0.0.0/8 via 10.202.51.1 dev eth0 proto static 
+ 10.202.51.0/24 dev eth0 proto kernel scope link src 10.202.51.254 
+ 
+ [regression potential]
+ 
+ adjusting how networkd works always carries the risk of breaking
+ networking.
+ 
+ TBD detailed regression potential after analyzing fix.
+ 
+ [other info]
+ 
+ original description:
+ 
+ --
+ 
+ 
  Consider the following setup:
  
  network:
-   version: 2
-   renderer: networkd
-   ethernets:
- ens4:
-   dhcp-identifier: mac
-   dhcp4: yes
-   dhcp4-overrides:
- use-dns: no
- use-ntp: no
- send-hostname: no
- use-hostname: no
- use-routes: no
-   routes:
-   - to: 10.0.0.0/8
- via: 10.50.0.1
-   optional: true
+   version: 2
+   renderer: networkd
+   ethernets:
+ ens4:
+   dhcp-identifier: mac
+   dhcp4: yes
+   dhcp4-overrides:
+ use-dns: no
+ use-ntp: no
+ send-hostname: no
+ use-hostname: no
+ use-routes: no
+   routes:
+   - to: 10.0.0.0/8
+ via: 10.50.0.1
+   optional: true
  
  Thus I only need to get the IP address by DHCP, then add some static
  routes. This setup doesn't work. Apparently `routes` keyword only works
  when using static addresses.

** Summary changed:

- Netplan ignores static routes when using DHCP
+ systemd fails to setup static routes at boot when using DHCP

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

** Also affects: systemd (Ubuntu Eoan)
   Importance: High
   Status: New

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

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

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

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

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

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

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

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

** Changed in: systemd (Ubuntu Disco)
 Assignee: (unassigned) => Dan Streetman (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/1836695

Title:
  systemd fails to setup static routes at boot when using DHCP

Status in netplan:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
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]

  a systemd-networkd configuration that uses ipv4 dhcp but ignores the
  dhcp-provided route, and instead sets up a static route, and also does
  not include a static ipv4 address, fails to actually create the static
  route.

  This is due to networkd attempting to set up the static route before
  the dhcp ipv4 address is assigned, and the kernel does not allow
  creation of the route before setting up corr

[Touch-packages] [Bug 1837227] Re: Random mount units sometimes fail, while file system is correctly mounted

2019-09-27 Thread Bug Watch Updater
** Changed in: systemd
   Status: Unknown => 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/1837227

Title:
  Random mount units sometimes fail, while file system is correctly
  mounted

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

Bug description:
  In Ubuntu 18.04 at least, we sometimes get a random server in
  emergency mode with a failed mount unit (ext4 file system), while the
  corresponding file system is in fact correctly mounted. It happens
  roughly once every 1000 reboots.

  It seems to be related with this bug :
  https://github.com/systemd/systemd/issues/10872

  Is it possible to apply the fix
  
(https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21)
  in Ubuntu 18.04 ?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1837227/+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 1838329] Re: Cryptswap periodically fails to mount at boot due to missing a udev notification

2019-09-27 Thread Bug Watch Updater
** Changed in: systemd
   Status: Unknown => 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/1838329

Title:
  Cryptswap periodically fails to mount at boot due to missing a udev
  notification

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

Bug description:
  On some systems, cryptsetup-based encrypted swap partitions cause
  systemd to get stuck at boot. This is a timing-sensitive Heisenbug, so
  the rate of occurrence varies from one system to another. Some
  hardware will not experience the issue at all, others will only
  occasionally experience the issue, and then there are the unlucky who
  are unable to boot at all, no matter how many times they restart.

  The workaround is for the cryptsetup-generator to generate cryptswap
  service entries that call `udevadm trigger` after `mkswap`. This will
  ensure that the udev event is triggered, so that systemd is notified
  that the encrypt swap partition is ready to activate. This patch has
  already been submitted upstream to systemd, but it was not accepted
  because it is a workaround for the side effect of systemd not seeing
  the udev event upon creating the swap partition.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1838329/+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 1838329] Re: Cryptswap periodically fails to mount at boot due to missing a udev notification

2019-09-27 Thread Michael Aaron Murphy
However, it's unknown when the issue is going to be fixed. So for now
I'm carrying it in Pop!_OS 18.04, 19.04, and 19.10 at the moment.

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

Title:
  Cryptswap periodically fails to mount at boot due to missing a udev
  notification

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  On some systems, cryptsetup-based encrypted swap partitions cause
  systemd to get stuck at boot. This is a timing-sensitive Heisenbug, so
  the rate of occurrence varies from one system to another. Some
  hardware will not experience the issue at all, others will only
  occasionally experience the issue, and then there are the unlucky who
  are unable to boot at all, no matter how many times they restart.

  The workaround is for the cryptsetup-generator to generate cryptswap
  service entries that call `udevadm trigger` after `mkswap`. This will
  ensure that the udev event is triggered, so that systemd is notified
  that the encrypt swap partition is ready to activate. This patch has
  already been submitted upstream to systemd, but it was not accepted
  because it is a workaround for the side effect of systemd not seeing
  the udev event upon creating the swap partition.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1838329/+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 1837227] Re: Random mount units sometimes fail, while file system is correctly mounted

2019-09-27 Thread Dan Streetman
Hello,

from reading the upstream bug, it's unclear if the systemd commit
actually did fix this; it seems like a kernel and/or util-linux patch is
needed.

>From your description, it sounds like you're not able to reliably reproduce 
>this (only randomly), right?  Have you tried the upstream reproducer?  It 
>would help a lot if we had a reliable way to reproduce and verify this.
https://github.com/systemd/systemd/issues/10872#issuecomment-523399087

** Bug watch added: github.com/systemd/systemd/issues #10872
   https://github.com/systemd/systemd/issues/10872

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/10872
   Importance: Unknown
   Status: Unknown

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

Title:
  Random mount units sometimes fail, while file system is correctly
  mounted

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  In Ubuntu 18.04 at least, we sometimes get a random server in
  emergency mode with a failed mount unit (ext4 file system), while the
  corresponding file system is in fact correctly mounted. It happens
  roughly once every 1000 reboots.

  It seems to be related with this bug :
  https://github.com/systemd/systemd/issues/10872

  Is it possible to apply the fix
  
(https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21)
  in Ubuntu 18.04 ?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1837227/+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 1837914] Re: restart systemd-jounald fails

2019-09-27 Thread Dan Streetman
I tried on Xenial as well but can't reproduce it.

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

Title:
  restart systemd-jounald fails

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  While restarting systemd-jounald, the following error message occurs:

  systemd-journald[28007]: Assertion 'f' failed at ../src/journal
  /journal-file.c:143, function journal_file_close(). Aborting.

  release: Ubuntu 16.04.5 LTS
  systemd version: 229-4ubuntu21.22

  This issue is reported at
  https://github.com/systemd/systemd/issues/12400 and solved at
  https://github.com/systemd/systemd/pull/12679

  Please cherry-pick this fix to the ubuntu16.04 package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1837914/+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 1837914] Re: restart systemd-jounald fails

2019-09-27 Thread Dan Streetman
While I do see the bug and upstream fix, it would help the SRU process
to know how to easily reproduce this.  I tried the upstream instructions
of editing journald.conf to set Storage=auto as well as removing the
journald dir before restarting, but I can't reproduce this, at least not
using Bionic.  Do you see this only on Xenial?  What are your steps to
reproduce it?

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

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

Title:
  restart systemd-jounald fails

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  While restarting systemd-jounald, the following error message occurs:

  systemd-journald[28007]: Assertion 'f' failed at ../src/journal
  /journal-file.c:143, function journal_file_close(). Aborting.

  release: Ubuntu 16.04.5 LTS
  systemd version: 229-4ubuntu21.22

  This issue is reported at
  https://github.com/systemd/systemd/issues/12400 and solved at
  https://github.com/systemd/systemd/pull/12679

  Please cherry-pick this fix to the ubuntu16.04 package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1837914/+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 1837914] Re: restart systemd-jounald fails

2019-09-27 Thread Dan Streetman
** Bug watch added: github.com/systemd/systemd/issues #12400
   https://github.com/systemd/systemd/issues/12400

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/12400
   Importance: Unknown
   Status: Unknown

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

Title:
  restart systemd-jounald fails

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  While restarting systemd-jounald, the following error message occurs:

  systemd-journald[28007]: Assertion 'f' failed at ../src/journal
  /journal-file.c:143, function journal_file_close(). Aborting.

  release: Ubuntu 16.04.5 LTS
  systemd version: 229-4ubuntu21.22

  This issue is reported at
  https://github.com/systemd/systemd/issues/12400 and solved at
  https://github.com/systemd/systemd/pull/12679

  Please cherry-pick this fix to the ubuntu16.04 package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1837914/+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 1845627] Re: Network Manager doesn't deal with one time passwords for vpn connections

2019-09-27 Thread Hadmut Danisch
Network-Manager just sabotaged my VPN connection.

It used the (expired one-time-)password it stored in the keyring several
times again to try to login, until the server blocked the account due to
too many login failures.

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

Title:
  Network Manager doesn't deal with one time passwords for vpn
  connections

Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi,

  when configuring a VPN connection (openvpn) with the Network-Manager
  applet (LXDE) even when leaving the password empty Network Manager
  insists on putting the password into the keyring and to reuse it, even
  if this does not make sense and causes an error message on the server
  side, if it's a one-time-password (state of the art).

  NM needs a One-Time-Password-Option.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1845627/+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 1838329] Re: Cryptswap periodically fails to mount at boot due to missing a udev notification

2019-09-27 Thread Dan Streetman
Looks like this still needs to be worked out upstream.

** Bug watch added: github.com/systemd/systemd/issues #10179
   https://github.com/systemd/systemd/issues/10179

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/10179
   Importance: Unknown
   Status: Unknown

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

Title:
  Cryptswap periodically fails to mount at boot due to missing a udev
  notification

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  On some systems, cryptsetup-based encrypted swap partitions cause
  systemd to get stuck at boot. This is a timing-sensitive Heisenbug, so
  the rate of occurrence varies from one system to another. Some
  hardware will not experience the issue at all, others will only
  occasionally experience the issue, and then there are the unlucky who
  are unable to boot at all, no matter how many times they restart.

  The workaround is for the cryptsetup-generator to generate cryptswap
  service entries that call `udevadm trigger` after `mkswap`. This will
  ensure that the udev event is triggered, so that systemd is notified
  that the encrypt swap partition is ready to activate. This patch has
  already been submitted upstream to systemd, but it was not accepted
  because it is a workaround for the side effect of systemd not seeing
  the udev event upon creating the swap partition.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1838329/+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 1844868] Re: cloud-images should not contain plymouth

2019-09-27 Thread Robert C Jennings
Dimitri, I thought we looked into plymouth and it was doing additional
setup during boot that caused us to leave it in the image.  I wish I
could recall what all that way.  Anyhow, if that has changed we'd be
open to it.  Can you make the description a lot more descriptive and
discuss 'why' we want to remove it and the priority?  Thank you.

** Changed in: cloud-images
   Status: New => Incomplete

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

Title:
  cloud-images should not contain plymouth

Status in cloud-images:
  Incomplete
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  cloud-images should not contain plymouth

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1844868/+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 1822118] Re: Kernel Panic while rebooting cloud instance

2019-09-27 Thread Colin Ian King
And for Standard_D2s_v3

IP addr Mac AddrKernel  Reboots
104.42.252.54   00:0d:3a:32:df:92   5.0.0-1020-azure500
104.42.150.26   00:0d:3a:31:1b:50   5.0.0-1020-azure500
104.42.147.144  00:0d:3a:32:d8:2f   5.0.0-1020-azure500
40.112.129.232  00:0d:3a:32:d5:7c   5.0.0-1020-azure500
40.112.134.251  00:0d:3a:32:d9:2d   5.0.0-1020-azure500
13.64.195.2100:0d:3a:5a:7b:51   5.0.0-1020-azure500
40.83.214.204   00:0d:3a:36:47:98   5.0.0-1020-azure500
13.64.195.2700:0d:3a:5a:7f:05   5.0.0-1020-azure500
13.64.195.3100:0d:3a:5a:78:55   5.0.0-1020-azure500
13.64.195.6900:0d:3a:5a:7c:72   5.0.0-1020-azure500
104.42.51.2300:0d:3a:37:47:0a   5.0.0-1020-azure500
13.64.233.120   00:0d:3a:37:46:ab   5.0.0-1020-azure500
13.64.233.216   00:0d:3a:37:49:fb   5.0.0-1020-azure500
13.64.239.157   00:0d:3a:37:43:cf   5.0.0-1020-azure16   [hang]
52.160.87.177   00:0d:3a:35:fc:b1   5.0.0-1020-azure500

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

Title:
  Kernel Panic while rebooting cloud instance

Status in linux-azure package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  Description:   In the event a particular Azure cloud instance is
  rebooted it's possible that it may never recover and the instance will
  break indefinitely.

  In My case, it was a kernel panic. See specifics below..

  
  Series: Disco
  Instance Size: Basic_A3
  Region: (Default) US-WEST-2
  Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux

  
  I had a simple script to reboot an instance (X) amount of times, I chose 50, 
so the machine would power cycle by issuing a "reboot" from the terminal prompt 
just as a user would.   Once the machine came up, it captured dmesg and other 
bits then rebooted again until it reached 50. 

  After the 4th attempt, my script timed out, I took a look at the
  instance console log and the following displayed on the console.

  
  [  OK  ] Reached target Reboot.
  /shutdown: error while loading shared libra[   89.498980] Kernel panic - not 
syncing: Attempted to kill init! exitcode=0x7f00
  [   89.498980]
  [   89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure 
#13-Ubuntu
  [   89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090007  06/02/2017
  [   89.508026] Call Trace:
  [   89.508026]  dump_stack+0x63/0x8a
  [   89.508026]  panic+0xe7/0x247
  [   89.508026]  do_exit.cold.23+0x26/0x75
  [   89.508026]  do_group_exit+0x43/0xb0
  [   89.508026]  __x64_sys_exit_group+0x18/0x20
  [   89.508026]  do_syscall_64+0x5a/0x110
  [   89.508026]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [   89.508026] RIP: 0033:0x7f7bf0154d86
  [   89.508026] Code: Bad RIP value.
  [   89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 
00e7
  [   89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 
7f7bf0154d86
  [   89.508026] RDX: 007f RSI: 003c RDI: 
007f
  [   89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: 

  [   89.508026] R10: 7ffd6be6974c R11: 0206 R12: 
0018
  [   89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: 

  [   89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation 
range: 0x8000-0xbfff)
  [   89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  [   89.508026]  ]---

  
  this only occurred once in my testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1822118] Re: Kernel Panic while rebooting cloud instance

2019-09-27 Thread Colin Ian King
@Joseph, so I can reproduce this hang/crash issue across a variety of
instances. I can't get any info back on a console, so debugging this is
not easy.

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

Title:
  Kernel Panic while rebooting cloud instance

Status in linux-azure package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  Description:   In the event a particular Azure cloud instance is
  rebooted it's possible that it may never recover and the instance will
  break indefinitely.

  In My case, it was a kernel panic. See specifics below..

  
  Series: Disco
  Instance Size: Basic_A3
  Region: (Default) US-WEST-2
  Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux

  
  I had a simple script to reboot an instance (X) amount of times, I chose 50, 
so the machine would power cycle by issuing a "reboot" from the terminal prompt 
just as a user would.   Once the machine came up, it captured dmesg and other 
bits then rebooted again until it reached 50. 

  After the 4th attempt, my script timed out, I took a look at the
  instance console log and the following displayed on the console.

  
  [  OK  ] Reached target Reboot.
  /shutdown: error while loading shared libra[   89.498980] Kernel panic - not 
syncing: Attempted to kill init! exitcode=0x7f00
  [   89.498980]
  [   89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure 
#13-Ubuntu
  [   89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090007  06/02/2017
  [   89.508026] Call Trace:
  [   89.508026]  dump_stack+0x63/0x8a
  [   89.508026]  panic+0xe7/0x247
  [   89.508026]  do_exit.cold.23+0x26/0x75
  [   89.508026]  do_group_exit+0x43/0xb0
  [   89.508026]  __x64_sys_exit_group+0x18/0x20
  [   89.508026]  do_syscall_64+0x5a/0x110
  [   89.508026]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [   89.508026] RIP: 0033:0x7f7bf0154d86
  [   89.508026] Code: Bad RIP value.
  [   89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 
00e7
  [   89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 
7f7bf0154d86
  [   89.508026] RDX: 007f RSI: 003c RDI: 
007f
  [   89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: 

  [   89.508026] R10: 7ffd6be6974c R11: 0206 R12: 
0018
  [   89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: 

  [   89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation 
range: 0x8000-0xbfff)
  [   89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  [   89.508026]  ]---

  
  this only occurred once in my testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1845317] Re: Add new pci-id's for CML-S, ICL

2019-09-27 Thread Seth Forshee
** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Committed

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

Title:
  Add new pci-id's for CML-S, ICL

Status in libdrm package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Committed
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New
Status in libdrm source package in Bionic:
  New
Status in linux source package in Bionic:
  Won't Fix
Status in linux-oem-osp1 source package in Bionic:
  New
Status in mesa source package in Bionic:
  New

Bug description:
  [Impact]
  Comet Lake (CML) is basically same gen9 GPU as Sky Lake (SKL) (as is KBL, 
CFL, WHL). There are new CML-S desktop cpu's on the way, and they add three new 
pci-id's that need to be added across the stack in order to use the GPU 
properly.

  There's also one ICL pci-id which was added recently (not in 5.3).

  [Test case]
  The proper way to test is to have an actual machine and boot it up with the 
updated stack, but since these are just pci-id's with no regression potential 
on older hw, it should be fine to just accept them.

  [Regression potential]
  None, just adds new pci-id's to allow the new GPUs to load the proper drivers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1845317/+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 1845652] [NEW] rsync sends everything, not just changes

2019-09-27 Thread peterzay
Public bug reported:

Repeated runs of rsync from PC to USB key send everything, not just the
changes.

This is reproducible.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: rsync 3.1.3-6
ProcVersionSignature: Ubuntu 5.0.0-29.31-generic 5.0.21
Uname: Linux 5.0.0-29-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Sep 27 09:18:19 2019
InstallationDate: Installed on 2019-06-10 (109 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: rsync
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-bug disco

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

Title:
  rsync sends everything, not just changes

Status in rsync package in Ubuntu:
  New

Bug description:
  Repeated runs of rsync from PC to USB key send everything, not just
  the changes.

  This is reproducible.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: rsync 3.1.3-6
  ProcVersionSignature: Ubuntu 5.0.0-29.31-generic 5.0.21
  Uname: Linux 5.0.0-29-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 27 09:18:19 2019
  InstallationDate: Installed on 2019-06-10 (109 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1845652/+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 1843768] Re: [FFe] Ubiquity with zfs install option

2019-09-27 Thread Matthew Paul Thomas
That is much better, thank you. The spacing issue is still there, but
that is the least important.

(It’s also unfortunate that checkbox captions aren’t disabled when the
labels are, but that’s outside the scope of adding ZFS.)

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

Title:
  [FFe] Ubiquity with zfs install option

Status in ubiquity package in Ubuntu:
  New
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  Part of the 19.10 feature announcement is zfs experimental support in
  the installer (https://ubuntu.com/blog/enhancing-our-zfs-support-on-
  ubuntu-19-10-an-introduction). We modified ubiquity to present an
  “EXPERIMENTAL” (with warning) ZSYS install option. This option is only
  visible is zfsutils-linux is installed on the system. So, it won't be
  available for derivatives that use ubiquity but do not seed zfsutils-
  linux.

  Update as of 20/09/2019: the plan is to not seed zsys (security review
  will take a while), but to only seed zfsutils-linux. People can then
  opt-in to zsys which should be available by default next cycle.

  This option takes an entire disk and have a fix set of dataset
  installed. There is no support but we need this to make an official
  install option for the next LTS.

  The patch has been created to be as minimal as possible. Partman does
  a full disk partitioning, and then the script zsys-setup the first
  non-ESP partition and replaces with zfs pools.

  4 partitions are created:
  1. if GPT partitioning: ESP partition. This one is done by partman directly.
  2. bpool (for boot), pool with older zfs compatible version to be readable by 
grub)
  3. rpool (for / and userdataset)
  4. /boot/grub (ext4) to contain a single grub (NOTE: this could be later on 
moved to the ESP)

  Additionaly if a swap file has been created by ubiquity, it is
  recreated as a ZFS volume. If the script fails to execute, the final
  installation is an ext4 installation on entire disk.

  Note that the implementation is slightly different from the
  specification due to a difficult cohabitation with partman in the
  custom partitioning page.

  Please find attached the MP on ubiquity as well as the package build
  log.

  https://launchpadlibrarian.net/442036321/buildlog_ubuntu-eoan-
  amd64.ubiquity_19.10.10~ppa1_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1843768/+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 1843768] Re: [FFe] Ubiquity with zfs install option

2019-09-27 Thread Jean-Baptiste Lallement
New version based on your comments.

** Attachment added: "guided_partitioning_with_zfs_2.png"
   
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1843768/+attachment/5291767/+files/guided_partitioning_with_zfs_2.png

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

Title:
  [FFe] Ubiquity with zfs install option

Status in ubiquity package in Ubuntu:
  New
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  Part of the 19.10 feature announcement is zfs experimental support in
  the installer (https://ubuntu.com/blog/enhancing-our-zfs-support-on-
  ubuntu-19-10-an-introduction). We modified ubiquity to present an
  “EXPERIMENTAL” (with warning) ZSYS install option. This option is only
  visible is zfsutils-linux is installed on the system. So, it won't be
  available for derivatives that use ubiquity but do not seed zfsutils-
  linux.

  Update as of 20/09/2019: the plan is to not seed zsys (security review
  will take a while), but to only seed zfsutils-linux. People can then
  opt-in to zsys which should be available by default next cycle.

  This option takes an entire disk and have a fix set of dataset
  installed. There is no support but we need this to make an official
  install option for the next LTS.

  The patch has been created to be as minimal as possible. Partman does
  a full disk partitioning, and then the script zsys-setup the first
  non-ESP partition and replaces with zfs pools.

  4 partitions are created:
  1. if GPT partitioning: ESP partition. This one is done by partman directly.
  2. bpool (for boot), pool with older zfs compatible version to be readable by 
grub)
  3. rpool (for / and userdataset)
  4. /boot/grub (ext4) to contain a single grub (NOTE: this could be later on 
moved to the ESP)

  Additionaly if a swap file has been created by ubiquity, it is
  recreated as a ZFS volume. If the script fails to execute, the final
  installation is an ext4 installation on entire disk.

  Note that the implementation is slightly different from the
  specification due to a difficult cohabitation with partman in the
  custom partitioning page.

  Please find attached the MP on ubiquity as well as the package build
  log.

  https://launchpadlibrarian.net/442036321/buildlog_ubuntu-eoan-
  amd64.ubiquity_19.10.10~ppa1_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1843768/+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 1845645] Re: Emacs logs AT-SPI warnings to console on startup

2019-09-27 Thread Tuure Laurinolli
Apparently this is solved by running /usr/lib/at-spi2-core/at-
spi2-registryd. Normally it seems to be launched by gdm, but my session
is not started through gdm.

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

Title:
  Emacs logs AT-SPI warnings to console on startup

Status in at-spi2-atk package in Ubuntu:
  New

Bug description:
  When starting up certain (GTK?) applications from console in a custom
  X session, such as emacs or ubuntu-bug, there is a lot of log output
  like:

  
  """
  ** (emacs:4437): WARNING **: 15:05:10.026: AT-SPI: Could not obtain desktop 
path or name
  """

  or

  """
  ** (apport-gtk:175957): WARNING **: 15:16:16.747: AT-SPI: Could not obtain 
desktop path or name
  """


  The issue seems to be related to at-spi2-atk, or at least that's where
  the code that prints the error is:


  In register_reply in bridge.c:
    if (reply)
  {
    gchar *app_name, *obj_path;

    if (strcmp (dbus_message_get_signature (reply), "(so)") != 0)
  {
    g_warning ("AT-SPI: Could not obtain desktop path or name\n");
  }

  
  Which seems to be triggered by an attempt to register the application to ATK:
  static gboolean
  register_application (SpiBridge * app)
  {
    DBusMessage *message;
    DBusMessageIter iter;
    DBusPendingCall *pending;

    g_free (app->desktop_name);
    g_free (app->desktop_path);

    /* These will be overridden when we get a reply, but in practice these
   defaults should always be correct */
    app->desktop_name = g_strdup (ATSPI_DBUS_NAME_REGISTRY);
    app->desktop_path = g_strdup (ATSPI_DBUS_PATH_ROOT);

    message = dbus_message_new_method_call (SPI_DBUS_NAME_REGISTRY,
    ATSPI_DBUS_PATH_ROOT,
    ATSPI_DBUS_INTERFACE_SOCKET,
    "Embed");

    dbus_message_iter_init_append (message, &iter);
    spi_object_append_reference (&iter, app->root);

  if (!dbus_connection_send_with_reply (app->bus, message, &pending, -1)
  || !pending)
  {
  if (pending)
    dbus_pending_call_unref (pending);

  dbus_message_unref (message);
  return FALSE;
  }

  dbus_pending_call_set_notify (pending, register_reply, app, NULL);


  
  It seems to be caused by nobody being available at the ATSPI_DBUS_PATH_ROOT 
to handle the message. I have not yet been able to figure out what *should* be 
handling the message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/at-spi2-atk/+bug/1845645/+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 1845317] Re: Add new pci-id's for CML-S, ICL

2019-09-27 Thread Launchpad Bug Tracker
This bug was fixed in the package libdrm - 2.4.99-1ubuntu1

---
libdrm (2.4.99-1ubuntu1) eoan; urgency=medium

  * intel-sync-pciids.diff: Sync pci-ids with the kernel. (LP: #1845317)

 -- Timo Aaltonen   Wed, 25 Sep 2019 15:21:09 +0300

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

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

Title:
  Add new pci-id's for CML-S, ICL

Status in libdrm package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New
Status in libdrm source package in Bionic:
  New
Status in linux source package in Bionic:
  Won't Fix
Status in linux-oem-osp1 source package in Bionic:
  New
Status in mesa source package in Bionic:
  New

Bug description:
  [Impact]
  Comet Lake (CML) is basically same gen9 GPU as Sky Lake (SKL) (as is KBL, 
CFL, WHL). There are new CML-S desktop cpu's on the way, and they add three new 
pci-id's that need to be added across the stack in order to use the GPU 
properly.

  There's also one ICL pci-id which was added recently (not in 5.3).

  [Test case]
  The proper way to test is to have an actual machine and boot it up with the 
updated stack, but since these are just pci-id's with no regression potential 
on older hw, it should be fine to just accept them.

  [Regression potential]
  None, just adds new pci-id's to allow the new GPUs to load the proper drivers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1845317/+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 1845645] Re: Emacs logs AT-SPI warnings to console on startup

2019-09-27 Thread Tuure Laurinolli
** Description changed:

  When starting up certain (GTK?) applications from console in a custom X
  session, such as emacs or ubuntu-bug, there is a lot of log output like:
+ 
  
  """
  ** (emacs:4437): WARNING **: 15:05:10.026: AT-SPI: Could not obtain desktop 
path or name
  """
  
  or
  
  """
  ** (apport-gtk:175957): WARNING **: 15:16:16.747: AT-SPI: Could not obtain 
desktop path or name
  """
  
+ 
  The issue seems to be related to at-spi2-atk, or at least that's where
  the code that prints the error is:
  
+ 
  In register_reply in bridge.c:
-   if (reply)
- {
-   gchar *app_name, *obj_path;
+   if (reply)
+ {
+   gchar *app_name, *obj_path;
  
-   if (strcmp (dbus_message_get_signature (reply), "(so)") != 0)
- {
-   g_warning ("AT-SPI: Could not obtain desktop path or name\n");
- }
+   if (strcmp (dbus_message_get_signature (reply), "(so)") != 0)
+ {
+   g_warning ("AT-SPI: Could not obtain desktop path or name\n");
+ }
+ 
  
  Which seems to be triggered by an attempt to register the application to ATK:
  static gboolean
  register_application (SpiBridge * app)
  {
-   DBusMessage *message;
-   DBusMessageIter iter;
-   DBusPendingCall *pending;
+   DBusMessage *message;
+   DBusMessageIter iter;
+   DBusPendingCall *pending;
  
-   g_free (app->desktop_name);
-   g_free (app->desktop_path);
+   g_free (app->desktop_name);
+   g_free (app->desktop_path);
  
-   /* These will be overridden when we get a reply, but in practice these
-  defaults should always be correct */
-   app->desktop_name = g_strdup (ATSPI_DBUS_NAME_REGISTRY);
-   app->desktop_path = g_strdup (ATSPI_DBUS_PATH_ROOT);
+   /* These will be overridden when we get a reply, but in practice these
+  defaults should always be correct */
+   app->desktop_name = g_strdup (ATSPI_DBUS_NAME_REGISTRY);
+   app->desktop_path = g_strdup (ATSPI_DBUS_PATH_ROOT);
  
-   message = dbus_message_new_method_call (SPI_DBUS_NAME_REGISTRY,
-   ATSPI_DBUS_PATH_ROOT,
-   ATSPI_DBUS_INTERFACE_SOCKET,
-   "Embed");
+   message = dbus_message_new_method_call (SPI_DBUS_NAME_REGISTRY,
+   ATSPI_DBUS_PATH_ROOT,
+   ATSPI_DBUS_INTERFACE_SOCKET,
+   "Embed");
  
-   dbus_message_iter_init_append (message, &iter);
-   spi_object_append_reference (&iter, app->root);
-   
- if (!dbus_connection_send_with_reply (app->bus, message, &pending, -1)
- || !pending)
- {
- if (pending)
-   dbus_pending_call_unref (pending);
+   dbus_message_iter_init_append (message, &iter);
+   spi_object_append_reference (&iter, app->root);
  
- dbus_message_unref (message);
- return FALSE;
- }
+ if (!dbus_connection_send_with_reply (app->bus, message, &pending, -1)
+ || !pending)
+ {
+ if (pending)
+   dbus_pending_call_unref (pending);
  
- dbus_pending_call_set_notify (pending, register_reply, app, NULL);
+ dbus_message_unref (message);
+ return FALSE;
+ }
+ 
+ dbus_pending_call_set_notify (pending, register_reply, app, NULL);
+ 
  
  
  It seems to be caused by nobody being available at the ATSPI_DBUS_PATH_ROOT 
to handle the message. I have not yet been able to figure out what *should* be 
handling the message.

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

Title:
  Emacs logs AT-SPI warnings to console on startup

Status in at-spi2-atk package in Ubuntu:
  New

Bug description:
  When starting up certain (GTK?) applications from console in a custom
  X session, such as emacs or ubuntu-bug, there is a lot of log output
  like:

  
  """
  ** (emacs:4437): WARNING **: 15:05:10.026: AT-SPI: Could not obtain desktop 
path or name
  """

  or

  """
  ** (apport-gtk:175957): WARNING **: 15:16:16.747: AT-SPI: Could not obtain 
desktop path or name
  """


  The issue seems to be related to at-spi2-atk, or at least that's where
  the code that prints the error is:


  In register_reply in bridge.c:
    if (reply)
  {
    gchar *app_name, *obj_path;

    if (strcmp (dbus_message_get_signature (reply), "(so)") != 0)
  {
    g_warning ("AT-SPI: Could not obtain desktop path or name\n");
  }

  
  Which seems to be triggered by an attempt to register the application to ATK:
  static gboolean
  register_application (SpiBridge * app)
  {
    DBusMessage *message;
    DBusMessageIter iter;
    DBusPendingCall *pending;

    g_free (app->desktop_name);
    g_free (app->desktop_path);

    /* These will be overridden when we get a reply, but in practice these
   defaults should always be correct

[Touch-packages] [Bug 1845645] [NEW] Emacs logs AT-SPI warnings to console on startup

2019-09-27 Thread Tuure Laurinolli
Public bug reported:

When starting up certain (GTK?) applications from console in a custom X
session, such as emacs or ubuntu-bug, there is a lot of log output like:

"""
** (emacs:4437): WARNING **: 15:05:10.026: AT-SPI: Could not obtain desktop 
path or name
"""

or

"""
** (apport-gtk:175957): WARNING **: 15:16:16.747: AT-SPI: Could not obtain 
desktop path or name
"""

The issue seems to be related to at-spi2-atk, or at least that's where
the code that prints the error is:

In register_reply in bridge.c:
  if (reply)
{
  gchar *app_name, *obj_path;

  if (strcmp (dbus_message_get_signature (reply), "(so)") != 0)
{
  g_warning ("AT-SPI: Could not obtain desktop path or name\n");
}

Which seems to be triggered by an attempt to register the application to ATK:
static gboolean
register_application (SpiBridge * app)
{
  DBusMessage *message;
  DBusMessageIter iter;
  DBusPendingCall *pending;

  g_free (app->desktop_name);
  g_free (app->desktop_path);

  /* These will be overridden when we get a reply, but in practice these
 defaults should always be correct */
  app->desktop_name = g_strdup (ATSPI_DBUS_NAME_REGISTRY);
  app->desktop_path = g_strdup (ATSPI_DBUS_PATH_ROOT);

  message = dbus_message_new_method_call (SPI_DBUS_NAME_REGISTRY,
  ATSPI_DBUS_PATH_ROOT,
  ATSPI_DBUS_INTERFACE_SOCKET,
  "Embed");

  dbus_message_iter_init_append (message, &iter);
  spi_object_append_reference (&iter, app->root);
  
if (!dbus_connection_send_with_reply (app->bus, message, &pending, -1)
|| !pending)
{
if (pending)
  dbus_pending_call_unref (pending);

dbus_message_unref (message);
return FALSE;
}

dbus_pending_call_set_notify (pending, register_reply, app, NULL);


It seems to be caused by nobody being available at the ATSPI_DBUS_PATH_ROOT to 
handle the message. I have not yet been able to figure out what *should* be 
handling the message.

** Affects: at-spi2-atk (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Emacs logs AT-SPI warnings to console on startup

Status in at-spi2-atk package in Ubuntu:
  New

Bug description:
  When starting up certain (GTK?) applications from console in a custom
  X session, such as emacs or ubuntu-bug, there is a lot of log output
  like:

  """
  ** (emacs:4437): WARNING **: 15:05:10.026: AT-SPI: Could not obtain desktop 
path or name
  """

  or

  """
  ** (apport-gtk:175957): WARNING **: 15:16:16.747: AT-SPI: Could not obtain 
desktop path or name
  """

  The issue seems to be related to at-spi2-atk, or at least that's where
  the code that prints the error is:

  In register_reply in bridge.c:
if (reply)
  {
gchar *app_name, *obj_path;

if (strcmp (dbus_message_get_signature (reply), "(so)") != 0)
  {
g_warning ("AT-SPI: Could not obtain desktop path or name\n");
  }

  Which seems to be triggered by an attempt to register the application to ATK:
  static gboolean
  register_application (SpiBridge * app)
  {
DBusMessage *message;
DBusMessageIter iter;
DBusPendingCall *pending;

g_free (app->desktop_name);
g_free (app->desktop_path);

/* These will be overridden when we get a reply, but in practice these
   defaults should always be correct */
app->desktop_name = g_strdup (ATSPI_DBUS_NAME_REGISTRY);
app->desktop_path = g_strdup (ATSPI_DBUS_PATH_ROOT);

message = dbus_message_new_method_call (SPI_DBUS_NAME_REGISTRY,
ATSPI_DBUS_PATH_ROOT,
ATSPI_DBUS_INTERFACE_SOCKET,
"Embed");

dbus_message_iter_init_append (message, &iter);
spi_object_append_reference (&iter, app->root);

  if (!dbus_connection_send_with_reply (app->bus, message, &pending, -1)
  || !pending)
  {
  if (pending)
dbus_pending_call_unref (pending);

  dbus_message_unref (message);
  return FALSE;
  }

  dbus_pending_call_set_notify (pending, register_reply, app, NULL);

  
  It seems to be caused by nobody being available at the ATSPI_DBUS_PATH_ROOT 
to handle the message. I have not yet been able to figure out what *should* be 
handling the message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/at-spi2-atk/+bug/1845645/+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 1845637] [NEW] Drop setting fs.protected_regular and fs.protected_fifos from sysctl defaults shipped by systemd

2019-09-27 Thread Balint Reczey
Public bug reported:

Those settings are typically set by the kernel in Ubuntu.

** Affects: systemd (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/1845637

Title:
  Drop setting fs.protected_regular and fs.protected_fifos from sysctl
  defaults shipped by systemd

Status in systemd package in Ubuntu:
  New

Bug description:
  Those settings are typically set by the kernel in Ubuntu.

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

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in qemu source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed

Bug 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 1843381] Re: Dell system takes a long time to connect network with external dock

2019-09-27 Thread Dan Streetman
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579984

http://patchwork.ozlabs.org/patch/631759/
"Just resubmit it and I'll apply it, I'm so tired of hearing about this..."

lol I'm relieved to see dmiller and others upstream had exactly the same
concerns as me :)

If he decided wasn't bad enough to reject it's good enough for me,
although it is still a really bad design.

I think the 73-usb-net-by-mac.rules needs to be changed to account for
this weird situation, let's see what Debian thinks.

-- 
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:
  New

Bug 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 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90
  InstallationDate: Installed on 2019-07-03 (20 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  MachineType: Dell Inc. Latitude 7424 Rugged Extreme
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed 
root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet 
splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M 
vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/27/2019
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.5.0
  dmi.board.name: 0Y7FK3
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X03
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 7424 Rugged Extreme
  dmi.sys.vendor: Dell Inc.

  [1]: 
https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en
  [2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c
  [3]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules
  [4]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch
  [5]: 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch?h=ubuntu-bionic

To manage notifications about this bug go to:
ht

[Touch-packages] [Bug 1845201] Re: systemd root-unittests autopkgtest is failing on armhf

2019-09-27 Thread Balint Reczey
*** This bug is a duplicate of bug 1845337 ***
https://bugs.launchpad.net/bugs/1845337

** This bug has been marked a duplicate of bug 1845337
   Disco autopkgtest @ armhf fails root-unittests -> test-execute -> 
exec-dynamicuser-statedir.service

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

Title:
  systemd root-unittests autopkgtest is failing on armhf

Status in systemd package in Ubuntu:
  New

Bug description:
  This is a regression with 242, to be fixed soon.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1845201/+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-09-27 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: qemu (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/1845337

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in qemu source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed

Bug 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 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

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

** Changed in: qemu (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/1845337

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in qemu source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed

Bug 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 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

2019-09-27 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/1845337

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in qemu source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed

Bug 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 1759836] Re: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez

2019-09-27 Thread Dan Streetman
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco

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

Title:
  systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez

Status in linux:
  Confirmed
Status in The Ubuntu Power Consumption Project:
  New
Status in bluez package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in bluez source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  Invalid
Status in bluez source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Invalid
Status in systemd source package in Disco:
  Invalid
Status in bluez source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Invalid
Status in systemd source package in Eoan:
  Invalid
Status in bluez package in Debian:
  New

Bug description:
  [impact]

  on specific Dell systems, with a specific usb bluetooth device built-
  in, the udev rule 'hid2hci' provided by the 'bluez' package causes an
  endless loop of uevents resulting from 'bind' or 'unbind' kernel
  uevents.  These new events were added to the kernel after the
  'hid2hci' udev rule was written.

  [test case]

  the specific Dell system is required to be able to reproduce this, or
  at least the specific usb bluetooth hardware included in that system.

  Reproducing this is reportedly easy, for example comment 75 indicates
  it happens on every boot.

  When this happens, any process monitor (e.g. ps, top, etc) will show
  the 'udevd' process using 100% of a cpu, and 'udevadm monitor' should
  show repeated 'bind' and 'unbind' events as mentioned in comment 39.

  [regression potential]

  as this alters what kernel uevents the 'hid2hci' udev rule processes,
  regressions would involve the affected usb bluetooth device failing to
  be set up, or otherwise not processing the uevents correctly.

  [other info]

  this is not fixed yet upstream, as of my last check, but has been
  submitted upstream as mentioned in comment 95.

  
  original description:

  --

  
  The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not 
noticing any difference in my computer.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu6
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.9-0ubuntu2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Mar 29 08:52:54 2018
  InstallationDate: Installed on 2018-03-05 (23 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304)
  MachineType: Dell Inc. Inspiron N5010
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic 
root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1
  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: 01/25/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A12
  dmi.board.name: 08R0GW
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A12
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A12
  dmi.modalias: 
dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12:
  dmi.product.name: Inspiron N5010
  dmi.product.version: A12
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel/+bug/1759836/+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 1843768] Re: [FFe] Ubiquity with zfs install option

2019-09-27 Thread Matthew Paul Thomas
Unfortunately this layout is highly misleading.

It’s misleading for the “Encrypt” and “Use LVM” checkboxes to be aligned
with the radio buttons above it. That suggests that they are independent
of the radio buttons. And it suggests that the radio button group has
finished. Neither is the case. This can be fixed by indenting those two
options so that they are aligned with the label of the “Replace Windows
with Ubuntu” option that they depend on.

Less importantly, it’s misleading to have *more* space between “Replace
Windows with Ubuntu” and the two options that actually depend on it,
than between it and the “Install Ubuntu alongside Windows” option that
it’s exclusive with. The simplest fix is for the spacing to be the same.

Finally, it’s misleading for any options to come after “Something else”.
The word “else” refers to things that come before it. So “Something
else” should always be the last option.

Fixing those three problems would have a bonus benefit that neither of
the separators would be needed any more.

If it’s also possible to change the wording at this late stage, please
stop using the phrase “the new installation” three times. Delete both
occurrences of “with the new installation”.

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

Title:
  [FFe] Ubiquity with zfs install option

Status in ubiquity package in Ubuntu:
  New
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  Part of the 19.10 feature announcement is zfs experimental support in
  the installer (https://ubuntu.com/blog/enhancing-our-zfs-support-on-
  ubuntu-19-10-an-introduction). We modified ubiquity to present an
  “EXPERIMENTAL” (with warning) ZSYS install option. This option is only
  visible is zfsutils-linux is installed on the system. So, it won't be
  available for derivatives that use ubiquity but do not seed zfsutils-
  linux.

  Update as of 20/09/2019: the plan is to not seed zsys (security review
  will take a while), but to only seed zfsutils-linux. People can then
  opt-in to zsys which should be available by default next cycle.

  This option takes an entire disk and have a fix set of dataset
  installed. There is no support but we need this to make an official
  install option for the next LTS.

  The patch has been created to be as minimal as possible. Partman does
  a full disk partitioning, and then the script zsys-setup the first
  non-ESP partition and replaces with zfs pools.

  4 partitions are created:
  1. if GPT partitioning: ESP partition. This one is done by partman directly.
  2. bpool (for boot), pool with older zfs compatible version to be readable by 
grub)
  3. rpool (for / and userdataset)
  4. /boot/grub (ext4) to contain a single grub (NOTE: this could be later on 
moved to the ESP)

  Additionaly if a swap file has been created by ubiquity, it is
  recreated as a ZFS volume. If the script fails to execute, the final
  installation is an ext4 installation on entire disk.

  Note that the implementation is slightly different from the
  specification due to a difficult cohabitation with partman in the
  custom partitioning page.

  Please find attached the MP on ubiquity as well as the package build
  log.

  https://launchpadlibrarian.net/442036321/buildlog_ubuntu-eoan-
  amd64.ubiquity_19.10.10~ppa1_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1843768/+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 1843768] Re: [FFe] Ubiquity with zfs install option

2019-09-27 Thread Jean-Baptiste Lallement
This screenshot shows the guided partitioning page with the experimental
feature clearly separated from other options and labelled 'experimental'
with a warning.

This is only for 19.10. The new proposed design also changes the LVM and
encryption options to a new dialog and hence cannot be implemented so
late in the cycle.

** Attachment removed: "2019-09-12_17-36.png"
   
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1843768/+attachment/5288360/+files/2019-09-12_17-36.png

** Attachment added: "guided_partitioning_with_zfs.png"
   
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1843768/+attachment/5291743/+files/guided_partitioning_with_zfs.png

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

Title:
  [FFe] Ubiquity with zfs install option

Status in ubiquity package in Ubuntu:
  New
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  Part of the 19.10 feature announcement is zfs experimental support in
  the installer (https://ubuntu.com/blog/enhancing-our-zfs-support-on-
  ubuntu-19-10-an-introduction). We modified ubiquity to present an
  “EXPERIMENTAL” (with warning) ZSYS install option. This option is only
  visible is zfsutils-linux is installed on the system. So, it won't be
  available for derivatives that use ubiquity but do not seed zfsutils-
  linux.

  Update as of 20/09/2019: the plan is to not seed zsys (security review
  will take a while), but to only seed zfsutils-linux. People can then
  opt-in to zsys which should be available by default next cycle.

  This option takes an entire disk and have a fix set of dataset
  installed. There is no support but we need this to make an official
  install option for the next LTS.

  The patch has been created to be as minimal as possible. Partman does
  a full disk partitioning, and then the script zsys-setup the first
  non-ESP partition and replaces with zfs pools.

  4 partitions are created:
  1. if GPT partitioning: ESP partition. This one is done by partman directly.
  2. bpool (for boot), pool with older zfs compatible version to be readable by 
grub)
  3. rpool (for / and userdataset)
  4. /boot/grub (ext4) to contain a single grub (NOTE: this could be later on 
moved to the ESP)

  Additionaly if a swap file has been created by ubiquity, it is
  recreated as a ZFS volume. If the script fails to execute, the final
  installation is an ext4 installation on entire disk.

  Note that the implementation is slightly different from the
  specification due to a difficult cohabitation with partman in the
  custom partitioning page.

  Please find attached the MP on ubiquity as well as the package build
  log.

  https://launchpadlibrarian.net/442036321/buildlog_ubuntu-eoan-
  amd64.ubiquity_19.10.10~ppa1_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1843768/+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 1843812] Re: apt info "please use the '-a' switch"

2019-09-27 Thread Julian Andres Klode
** Changed in: apt (Ubuntu)
   Status: Triaged => In Progress

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

Title:
  apt info "please use the '-a' switch"

Status in apt package in Ubuntu:
  In Progress

Bug description:
  When getting info about a package, I see a notice asking me to "Please
  use the '-a' switch", but the apt program does not accept an '-a'
  switch.

  Steps to reproduce:
  $ apt info docker.io
  ...
  N: There is 1 additional record. Please use the '-a' switch to see it
  $ apt -a info docker.io
  $ apt info -a docker.io
  $ apt info docker.io -a

  Expected outcome:
  same output as `apt info docker.io` but with the 1 additional record.

  Seen outcome:
  E: Command line option 'a' [from -a] is not understood in combination with 
the other options.

  Also seen:
  `apt info $pkg` gives the same output as `apt show $pkg` including the Notice 
message, but where `apt info -a $pkg` fails, `apt show -a $pkg` succeeds.

  Workaround:
  Use `apt show -a $pkg` instead.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: apt 1.8.1
  ProcVersionSignature: Ubuntu 5.0.0-23.24-generic 5.0.15
  Uname: Linux 5.0.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Thu Sep 12 14:16:09 2019
  InstallationDate: Installed on 2018-10-30 (316 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: apt
  UpgradeStatus: Upgraded to disco on 2019-04-18 (147 days ago)
  modified.conffile..etc.logrotate.d.apport: [modified]
  modified.conffile..etc.logrotate.d.apt: [modified]
  mtime.conffile..etc.logrotate.d.apport: 2018-12-13T12:13:33.355709
  mtime.conffile..etc.logrotate.d.apt: 2018-12-13T12:13:41.355709

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1843812/+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 1845627] [NEW] Network Manager doesn't deal with one time passwords for vpn connections

2019-09-27 Thread Hadmut Danisch
Public bug reported:

Hi,

when configuring a VPN connection (openvpn) with the Network-Manager
applet (LXDE) even when leaving the password empty Network Manager
insists on putting the password into the keyring and to reuse it, even
if this does not make sense and causes an error message on the server
side, if it's a one-time-password (state of the art).

NM needs a One-Time-Password-Option.

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

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

Title:
  Network Manager doesn't deal with one time passwords for vpn
  connections

Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi,

  when configuring a VPN connection (openvpn) with the Network-Manager
  applet (LXDE) even when leaving the password empty Network Manager
  insists on putting the password into the keyring and to reuse it, even
  if this does not make sense and causes an error message on the server
  side, if it's a one-time-password (state of the art).

  NM needs a One-Time-Password-Option.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1845627/+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 1830146] Re: Checkbox detect an extra webcam "video1"

2019-09-27 Thread Betty Lin
Found one new case that got the same error for video 1 with latptop -
201903-26914

** Attachment added: "udevadm.txt"
   
https://bugs.launchpad.net/checkbox-support/+bug/1830146/+attachment/5291731/+files/udevadm.txt

** Changed in: checkbox-support
   Status: Fix Committed => 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/1830146

Title:
  Checkbox detect an extra webcam "video1"

Status in Checkbox Support Library:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  Summary: System only have 1 webcam (video0) but checkbox detect an
  extra webcam "video1"

  
  -

  system-product-name: Latitude 5501
  GPU: 00:02.0 VGA compatible controller: Intel Corporation Device 3e9b (rev 02)
  CPU: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz (12x)
  bios-version: 1.0.0
  system-manufacturer: Dell Inc.
  Image: somerville-bionic-amd64-iso-hybrid-20180608-47

To manage notifications about this bug go to:
https://bugs.launchpad.net/checkbox-support/+bug/1830146/+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-09-27 Thread Christian Ehrhardt 
Until resolved I added a commit to the MP [1] masking current bad systemd tests 
in Disco.
That would unblock everyone until this is hopefully resolved in the next upload.

[1]: https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-fix-
systemd-ppc-hint-that-never-works/+merge/373200

-- 
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:
  New
Status in systemd package in Ubuntu:
  New
Status in qemu source package in Disco:
  New
Status in systemd source package in Disco:
  New

Bug 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 1822118] Re: Kernel Panic while rebooting cloud instance

2019-09-27 Thread Colin Ian King
Get more failures with Standard_B1ms

IP addr Mac AddrKernel  Reboots
52.160.101.11   00:0d:3a:5b:a0:7c   5.0.0-1020-azure10
137.135.51.101  00:0d:3a:31:20:fc   5.0.0-1020-azure500
137.135.50.133  00:0d:3a:31:27:0f   5.0.0-1020-azure396 [hang]
137.135.51.198  00:0d:3a:31:28:d7   5.0.0-1020-azure500
137.135.49.89   00:0d:3a:31:22:c1   5.0.0-1020-azure500
137.135.48.14   00:0d:3a:33:05:7d   5.0.0-1020-azure500
104.40.5.23 00:0d:3a:32:e7:27   5.0.0-1020-azure228 [hang]
13.93.223.213   00:0d:3a:32:e8:59   5.0.0-1020-azure500
104.40.0.15100:0d:3a:31:32:09   5.0.0-1020-azure500
40.118.128.130  00:0d:3a:32:f5:71   5.0.0-1020-azure500
23.101.200.119  00:0d:3a:36:c5:94   5.0.0-1020-azure500
104.40.8.52 00:0d:3a:33:07:6e   5.0.0-1020-azure500
104.40.19.222   00:0d:3a:33:01:0d   5.0.0-1020-azure500
104.42.135.72   00:0d:3a:3b:e9:15   5.0.0-1020-azure500
104.40.22.205   00:0d:3a:33:0d:d8   5.0.0-1020-azure500

104.40.7.22 00:0d:3a:37:85:ff   5.0.0-1020-azure500
13.88.17.94 00:0d:3a:5a:54:c6   5.0.0-1020-azure500
104.40.8.19600:0d:3a:59:56:f3   5.0.0-1020-azure500
13.88.21.12500:0d:3a:5a:50:00   5.0.0-1020-azure500
13.88.23.13900:0d:3a:5a:55:c3   5.0.0-1020-azure500
23.99.81.18800:0d:3a:5a:52:0f   5.0.0-1020-azure500
13.88.20.13200:0d:3a:5a:55:f1   5.0.0-1020-azure500
13.88.20.12600:0d:3a:5a:58:65   5.0.0-1020-azure500
13.88.20.23700:0d:3a:5a:55:42   5.0.0-1020-azure500
13.88.17.35 00:0d:3a:5a:57:5f   5.0.0-1020-azure500
13.91.54.22500:0d:3a:5a:57:5a   5.0.0-1020-azure500
13.88.21.57 00:0d:3a:5a:52:ce   5.0.0-1020-azure500
13.88.21.67 00:0d:3a:5a:5b:b7   5.0.0-1020-azure500
13.88.18.46 00:0d:3a:5a:5d:02   5.0.0-1020-azure229 [hang]
13.88.16.22200:0d:3a:37:80:d1   5.0.0-1020-azure500

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

Title:
  Kernel Panic while rebooting cloud instance

Status in linux-azure package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  Description:   In the event a particular Azure cloud instance is
  rebooted it's possible that it may never recover and the instance will
  break indefinitely.

  In My case, it was a kernel panic. See specifics below..

  
  Series: Disco
  Instance Size: Basic_A3
  Region: (Default) US-WEST-2
  Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux

  
  I had a simple script to reboot an instance (X) amount of times, I chose 50, 
so the machine would power cycle by issuing a "reboot" from the terminal prompt 
just as a user would.   Once the machine came up, it captured dmesg and other 
bits then rebooted again until it reached 50. 

  After the 4th attempt, my script timed out, I took a look at the
  instance console log and the following displayed on the console.

  
  [  OK  ] Reached target Reboot.
  /shutdown: error while loading shared libra[   89.498980] Kernel panic - not 
syncing: Attempted to kill init! exitcode=0x7f00
  [   89.498980]
  [   89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure 
#13-Ubuntu
  [   89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090007  06/02/2017
  [   89.508026] Call Trace:
  [   89.508026]  dump_stack+0x63/0x8a
  [   89.508026]  panic+0xe7/0x247
  [   89.508026]  do_exit.cold.23+0x26/0x75
  [   89.508026]  do_group_exit+0x43/0xb0
  [   89.508026]  __x64_sys_exit_group+0x18/0x20
  [   89.508026]  do_syscall_64+0x5a/0x110
  [   89.508026]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [   89.508026] RIP: 0033:0x7f7bf0154d86
  [   89.508026] Code: Bad RIP value.
  [   89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 
00e7
  [   89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 
7f7bf0154d86
  [   89.508026] RDX: 007f RSI: 003c RDI: 
007f
  [   89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: 

  [   89.508026] R10: 7ffd6be6974c R11: 0206 R12: 
0018
  [   89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: 

  [   89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation 
range: 0x8000-0xbfff)
  [   89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  [   89.508026]  ]---

  
  this only occurred once in my testing.

To manage notifications about this bug 

[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez

2019-09-27 Thread Tristan Hill
Works for me with 5.50-0ubuntu2.1 on an old dell.

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

Title:
  systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez

Status in linux:
  Confirmed
Status in The Ubuntu Power Consumption Project:
  New
Status in bluez package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in bluez source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  Invalid
Status in bluez source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Invalid
Status in systemd source package in Disco:
  Invalid
Status in bluez source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Invalid
Status in systemd source package in Eoan:
  Invalid
Status in bluez package in Debian:
  New

Bug description:
  [impact]

  on specific Dell systems, with a specific usb bluetooth device built-
  in, the udev rule 'hid2hci' provided by the 'bluez' package causes an
  endless loop of uevents resulting from 'bind' or 'unbind' kernel
  uevents.  These new events were added to the kernel after the
  'hid2hci' udev rule was written.

  [test case]

  the specific Dell system is required to be able to reproduce this, or
  at least the specific usb bluetooth hardware included in that system.

  Reproducing this is reportedly easy, for example comment 75 indicates
  it happens on every boot.

  When this happens, any process monitor (e.g. ps, top, etc) will show
  the 'udevd' process using 100% of a cpu, and 'udevadm monitor' should
  show repeated 'bind' and 'unbind' events as mentioned in comment 39.

  [regression potential]

  as this alters what kernel uevents the 'hid2hci' udev rule processes,
  regressions would involve the affected usb bluetooth device failing to
  be set up, or otherwise not processing the uevents correctly.

  [other info]

  this is not fixed yet upstream, as of my last check, but has been
  submitted upstream as mentioned in comment 95.

  
  original description:

  --

  
  The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not 
noticing any difference in my computer.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu6
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.9-0ubuntu2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Mar 29 08:52:54 2018
  InstallationDate: Installed on 2018-03-05 (23 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304)
  MachineType: Dell Inc. Inspiron N5010
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic 
root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1
  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: 01/25/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A12
  dmi.board.name: 08R0GW
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A12
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A12
  dmi.modalias: 
dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12:
  dmi.product.name: Inspiron N5010
  dmi.product.version: A12
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel/+bug/1759836/+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 1760818] Re: gedit and gnome-calculator transparency/graphics corruption issue when GTK_IM_MODULE=xim is set

2019-09-27 Thread Pei-Cheng Huang
I installed Lubuntu 18.04 LTS on VirtualBox, and I met similar issue.
The text messages on gajim chat window were messy. GTK didn't seem to
refresh the window and kept previous text overlapped on the window.

I found a discussion (in Chinese) here, they found an workaround
solution - changing desktop theme:

https://www.ubuntu-
tw.org/modules/newbb/viewtopic.php?topic_id=108158&forum=2&post_id=360960

My input method was changed to gcin. Other than that, LXDE related
settings were unchanged after Lubuntu installation.

After using lxappearance to change theme to "Industrial", the symptom
disappeared.

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

Title:
  gedit and gnome-calculator transparency/graphics corruption issue when
  GTK_IM_MODULE=xim is set

Status in gtk+3.0 package in Ubuntu:
  Confirmed
Status in im-config package in Ubuntu:
  Confirmed

Bug description:
  In a "Ubuntu" (Xorg) session on 18.04 gedit and gnome-calculator
  suffer from a graphics issue where parts of their windows hold parts
  of wallpaper or other windows' contents as background.

  See attached screenshot.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: light-themes 16.10+18.04.20180328-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Apr  3 09:12:31 2018
  PackageArchitecture: all
  SourcePackage: ubuntu-themes
  UpgradeStatus: Upgraded to bionic on 2018-02-07 (54 days ago)

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