date:20200206

All autopkgtests for the newly accepted systemd (242-7ubuntu3.7) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

remctl/3.15-1build2 (armhf)
systemd-bootchart/unknown (armhf)
netplan.io/0.98-0ubuntu1 (amd64)
systemd/242-7ubuntu3.7 (ppc64el, s390x)
sks/unknown (armhf)
munin/2.0.49-3ubuntu1 (i386)


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/eoan/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1846232

Title:
  networkd pads interface MTU by 4 bytes for vlan even when told not to

Status in curtin:
  Invalid
Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  vlan interface has wrong mtu, which may cause lost packets due to
  incorrect mtu

  [test case]

  configure a system using the netplan cfg similar to comment 2.

  alternately, networkd config can be used, similar to:

  ubuntu@lp1846232-e:/run/systemd/network$ grep . *
  10-netplan-ens3.2667.netdev:[NetDev]
  10-netplan-ens3.2667.netdev:Name=ens3.2667
  10-netplan-ens3.2667.netdev:MTUBytes=1500
  10-netplan-ens3.2667.netdev:Kind=vlan
  10-netplan-ens3.2667.netdev:[VLAN]
  10-netplan-ens3.2667.netdev:Id=2667
  10-netplan-ens3.2667.network:[Match]
  10-netplan-ens3.2667.network:Name=ens3.2667
  10-netplan-ens3.2667.network:[Network]
  10-netplan-ens3.2667.network:LinkLocalAddressing=ipv6
  10-netplan-ens3.2667.network:Address=1.2.3.4/32
  10-netplan-ens3.2667.network:ConfigureWithoutCarrier=yes
  10-netplan-ens3.link:[Match]
  10-netplan-ens3.link:OriginalName=ens3
  10-netplan-ens3.link:[Link]
  10-netplan-ens3.link:WakeOnLan=off
  10-netplan-ens3.link:MTUBytes=1500
  10-netplan-ens3.network:[Match]
  10-netplan-ens3.network:Name=ens3
  10-netplan-ens3.network:[Network]
  10-netplan-ens3.network:LinkLocalAddressing=ipv6
  10-netplan-ens3.network:VLAN=ens3.2667

  The reboot and check the mtus:

  ubuntu@lp1846232-e:~$ ip l show ens3
  2: ens3:  mtu 1504 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
  link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff
  ubuntu@lp1846232-e:~$ ip l show ens3.2667
  3: ens3.2667@ens3:  mtu 1500 qdisc noqueue 
state UP mode DEFAULT group default qlen 1000
  link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff

  The base interface should have a mtu of only 1500.

  [regression potential]

  As this corrects/adjusts the mtu of the interface, regressions would
  likely involve interface(s) being assigned incorrect mtu values, which
  then would lead to dropped packets and/or lowered network performance.

  [scope]

  this is needed only for Eoan.

  disco and earlier don't have the patch that introduces this problem,
  commit 4b151b71320bbee1549afcbad5554a40d90d63b4

  focal already has the patches that fix this, commit
  f6fcc1c2a41eae749467de58453174296b635a69 (and the commit before it)

  see comment 4 for more details

  [other info]

  original description:

  ---

  From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-
  amd64/916/console:

  ==
  FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan)
  --
  Traceback (most recent call last):
    File 
"/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py",
 line 311, in test_ip_output
  routes)
    File 
"/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py",
 line 337, in check_interface
  int(ipcfg[key]))
  AssertionError: 1500 != 1504
   >> begin captured stdout << -
  parsed ip_a dict:
  interface0:
  broadcast: 10.245.175.255
  group: default
  inet4:
  -   address: 10.245.168.16
  prefixlen: '21'
  scope: global
  valid_lft: forever
  inet6:
  -   address: fec0::d6be:d9ff:fea8:4913
  prefixlen: '64'
  scope: site
  valid_lft: 86256sec
  -   address: fe80::d6be:d9ff:fea8:4913
  prefixlen: '64'
  scope: link
  valid_lft: forever
  interface: interface0
  loopback: false
  lower_up: false
  mac_address: d4:be:d9:a8:49:13
  mtu: '1500'
  multicast: false
  qdisc: fq_codel
  qlen: '1000'
  running: false
  state: UP
  up: false
  interface1:
  broadcast: 10.245.188.255

[Touch-packages] [Bug 1847816] Autopkgtest regression report (systemd/242-7ubuntu3.7)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.7) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

remctl/3.15-1build2 (armhf)
systemd-bootchart/unknown (armhf)
netplan.io/0.98-0ubuntu1 (amd64)
systemd/242-7ubuntu3.7 (ppc64el, s390x)
sks/unknown (armhf)
munin/2.0.49-3ubuntu1 (i386)


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/eoan/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1847816

Title:
  storage autopkgtest always fails with linux-{kvm,azure,etc} kernels
  that don't include scsi_debug module

Status in autopkgtest-cloud:
  New
Status in linux-kvm package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in linux-kvm source package in Xenial:
  New
Status in systemd source package in Xenial:
  In Progress
Status in linux-kvm source package in Bionic:
  New
Status in systemd source package in Bionic:
  Fix Committed
Status in linux-kvm source package in Disco:
  New
Status in systemd source package in Disco:
  Won't Fix
Status in linux-kvm source package in Eoan:
  New
Status in systemd source package in Eoan:
  Fix Committed
Status in linux-kvm source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Released

Bug description:
  Note: this bug touches on multiple packages:
  - autopkgtest-cloud: merge request open to install 'modules-extra' package
  - systemd: update autopkgtest to skip test if scsi_debug module isn't 
available (SRU template below is for this change)
  - linux-kvm: has CONFIG_SCSI_DEBUG unset, but would be good to have 
scsi_debug module built for this kernel

  [SRU template for systemd]

  [impact]

  the 'storage' autopkgtest requires the 'scsi_debug' module, and if it
  can't load it (and it's not built-in), the test fails.  On some custom
  kernels, this module is included in the new 'linux-modules-extra-*'
  deb which isn't installed by default, so the test always fails when
  doing a reverse-dep autopkgtest using such a kernel's meta pkg.

  Additionally, some custom kernels, like linux-kvm, have SCSI_DEBUG
  disabled entirely; for those kernels, it will never be possible to
  load the scsi_debug module and the test should be skipped.

  [test case]

  run the 'storage' autopkgtest with a custom kernel that doesn't
  provide the scsi_debug module in the standard linux-modules deb, or
  check the autopkgtest.u.c history, for example:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20191209_150835_237a5@/log.gz

  [regression potential]

  as this modifies one of the autopkgtest --setup-commands, a regression
  would most likely cause immediate test failure due to failing to
  install the proper linux-* debs.

  For the systemd 'storage' test change, this only skips the test if the
  scsi_debug module can't be loaded (and isn't already present, i.e.
  loaded or built-in).  Any regression potential from that is low, but
  likely would involve incorrect test skips and/or missing valid
  problems due to skipping the test.

  [scope]

  systemd in all releases needs to have its 'storage' test updated

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopkgtest-cloud/+bug/1847816/+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 1671951] Autopkgtest regression report (systemd/242-7ubuntu3.7)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.7) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

remctl/3.15-1build2 (armhf)
systemd-bootchart/unknown (armhf)
netplan.io/0.98-0ubuntu1 (amd64)
systemd/242-7ubuntu3.7 (ppc64el, s390x)
sks/unknown (armhf)
munin/2.0.49-3ubuntu1 (i386)


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/eoan/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1671951

Title:
  networkd should allow configuring IPV6 MTU

Status in systemd:
  Unknown
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix
Status in cloud-init source package in Eoan:
  New
Status in netplan.io source package in Eoan:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in cloud-init source package in Focal:
  Confirmed
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source,

[Touch-packages] [Bug 1845909] Autopkgtest regression report (systemd/242-7ubuntu3.7)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.7) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

remctl/3.15-1build2 (armhf)
systemd-bootchart/unknown (armhf)
netplan.io/0.98-0ubuntu1 (amd64)
systemd/242-7ubuntu3.7 (ppc64el, s390x)
sks/unknown (armhf)
munin/2.0.49-3ubuntu1 (i386)


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/eoan/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1845909

Title:
  [SRU] IPv6 link local address is assigned even when
  LinkLocalAddressing=no|ipv4

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

Bug description:
  [impact]

  in some situations when a networkd interface is configured with
  LinkLocalAddressing=no, networkd still assigns a link-local address to
  it

  [test case]

  see comment 3.

  note I was only able to reproduce this at boot time; if the vlan
  interface is removed (i.e. 'sudo ip l del pppoe') and then networkd
  restarted, the pppoe interface is created and does not have a link-
  local address.  This is due to this bug being triggered by timing, as
  a vlan interface is raised by the kernel when its parent interface is
  raised, in this case by networkd itself.

  [regression potential]

  this changes how ipv6ll addresses are managed and dropped, as well as
  changing when foreign addresses are dropped (later in config process).
  Any regressions would likely be around incorrectly setting ipv6ll
  addresses, or complete failure to complete interface configuration.

  [scope]

  this is fixed upstream by:
  https://github.com/systemd/systemd/pull/13927

  and also requires the upstream PR referenced in the original description:
  upstream patch: https://github.com/systemd/systemd/pull/13565

  this is required for focal (uploaded already), eoan, and bionic.  It
  may be required for xenial.

  [other info]

  Note, the original description below is incorrect, the issue/patch it
  references is not enough to fix this issue.

  original description:

  --

  upstream issue: https://github.com/systemd/systemd/issues/12886
  upstream patch: https://github.com/systemd/systemd/pull/13565

  The upstream fix will be available in systemd 244.
  Backport please. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1845909/+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 1762391] Autopkgtest regression report (systemd/242-7ubuntu3.7)

All autopkgtests for the newly accepted systemd (242-7ubuntu3.7) for eoan have 
finished running.
The following regressions have been reported in tests triggered by the package:

remctl/3.15-1build2 (armhf)
systemd-bootchart/unknown (armhf)
netplan.io/0.98-0ubuntu1 (amd64)
systemd/242-7ubuntu3.7 (ppc64el, s390x)
sks/unknown (armhf)
munin/2.0.49-3ubuntu1 (i386)


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/eoan/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1762391

Title:
  pam_group.so is not evaluated by gnome-terminal

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

Bug description:
  [Impact]

  pam_setcred call was missing in systemd making its implementation of the PAM 
protocol incomplete. It could manifest in different ways, but one particularly 
problematic for enterprise environments was the fact that
  processes were never getting group membership they were expected to get via 
pam_group module.

  [Test Case]

   * Add a /etc/security/group.conf entry, e.g.
     *;*;*;Al-2400;dialout,users
   * Add pam_group to your PAM stack, e.g. /etc/pam.d/common-auth
   * Login to the system and launch gnome-terminal (it will be launched via 
gnome-terminal-server launched by systemd --user + dbus).

  Expected result:
  Logged in user is a member of 'dialout' and 'users' groups.

  Actual result:
  no group membership gained from pam_group.

  [Regression Potential]

   * It introduces a new PAM warning message in some scenarios (e.g. for
  systemd DynamicUser=1 units) for users that can't authenticate
  (pam_setcred fails in such case).

   * In certain systems user group membership may be extended by
  pam_group.

  [Other Info]
  Original bug description:

  We are using Ubuntu in a university network with lots of ldap users.
  To automatically map ldap users/groups to local groups we are using
  pam_group.so. This has worked for years.

  With the upgrade from Xenial to Bionic /etc/security/group.conf is not
  evaluated anymore by gnome-terminal as it runs as systemd --user.
  Xterm, ssh, su, and tty* however do work as expected. Only the default
  gnome-terminal behaves different.

  According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243
  and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this
  might not be a bug, but a feature.

  Nevertheless this behavior is very unexpected when upgrading from
  Xenial to Bionic and therefore should at least added to the changelog.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-terminal 3.28.0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu4
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  9 13:17:52 2018
  InstallationDate: Installed on 2018-03-29 (11 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1762391/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-06 Thread Alkis Georgopoulos

Gunnar, so if a MATE user doesn't have the langpack installed, he shouldn't 
have a translated session?
Why do we want to fix this only for Live CDs?

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  New

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861556] Re: g-ir-scanner doesn't work (so can't build gnome packages any more)

2020-02-06 Thread Bug Watch Updater

** Changed in: gobject-introspection (Debian)
   Status: New => Fix Released

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

Title:
  g-ir-scanner doesn't work (so can't build gnome packages any more)

Status in gobject-introspection package in Ubuntu:
  Fix Released
Status in python3-defaults package in Ubuntu:
  Invalid
Status in gobject-introspection package in Debian:
  Fix Released

Bug description:
  Running g-ir-scanner doesn't work anymore after a recent upgrade with
  a fully up to date focal:

  Traceback (most recent call last):
File "/usr/bin/g-ir-scanner", line 99, in 
  from giscanner.scannermain import scanner_main
File 
"/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/scannermain.py", 
line 35, in 
  from giscanner.ast import Include, Namespace
File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/ast.py", 
line 29, in 
  from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF
File 
"/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/sourcescanner.py", 
line 33, in 
  from giscanner._giscanner import SourceScanner as CSourceScanner
  ModuleNotFoundError: No module named 'giscanner._giscanner'

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gobject-introspection 1.62.0-4ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
  Uname: Linux 5.4.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb  1 07:04:11 2020
  InstallationDate: Installed on 2019-08-13 (171 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190712)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gobject-introspection
  UpgradeStatus: Upgraded to focal on 2019-11-04 (89 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gobject-introspection/+bug/1861556/+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 1762391] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1762391

Title:
  pam_group.so is not evaluated by gnome-terminal

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

Bug description:
  [Impact]

  pam_setcred call was missing in systemd making its implementation of the PAM 
protocol incomplete. It could manifest in different ways, but one particularly 
problematic for enterprise environments was the fact that
  processes were never getting group membership they were expected to get via 
pam_group module.

  [Test Case]

   * Add a /etc/security/group.conf entry, e.g.
     *;*;*;Al-2400;dialout,users
   * Add pam_group to your PAM stack, e.g. /etc/pam.d/common-auth
   * Login to the system and launch gnome-terminal (it will be launched via 
gnome-terminal-server launched by systemd --user + dbus).

  Expected result:
  Logged in user is a member of 'dialout' and 'users' groups.

  Actual result:
  no group membership gained from pam_group.

  [Regression Potential]

   * It introduces a new PAM warning message in some scenarios (e.g. for
  systemd DynamicUser=1 units) for users that can't authenticate
  (pam_setcred fails in such case).

   * In certain systems user group membership may be extended by
  pam_group.

  [Other Info]
  Original bug description:

  We are using Ubuntu in a university network with lots of ldap users.
  To automatically map ldap users/groups to local groups we are using
  pam_group.so. This has worked for years.

  With the upgrade from Xenial to Bionic /etc/security/group.conf is not
  evaluated anymore by gnome-terminal as it runs as systemd --user.
  Xterm, ssh, su, and tty* however do work as expected. Only the default
  gnome-terminal behaves different.

  According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243
  and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this
  might not be a bug, but a feature.

  Nevertheless this behavior is very unexpected when upgrading from
  Xenial to Bionic and therefore should at least added to the changelog.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-terminal 3.28.0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu4
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  9 13:17:52 2018
  InstallationDate: Installed on 2018-03-29 (11 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1762391/+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 1831459] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1831459

Title:
  'storage' test needs to wait for systemd-cryptsetup to be active
  before stopping it

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

Bug description:
  [impact]

  test case fails because it does not wait for the service to become
  active before stopping it, resulting in failure to rmmod the
  scsi_debug module because it's still in use.

  [test case]

  check 'storage' test results for systemd in 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]

  low; test case fix only.

  [other info]

  detected and reported by @cascardo in bug 1814373 comment 4 and 5, but
  separate (non-test) systemd bugfix uploaded for that bug so opening
  this bug to track fixing the test case.

  larger fixes/improvements to 'storage' testcase in bug 1829347, but
  those rejected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831459/+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 1849261] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1849261

Title:
  Update systemd for ubuntu 18.04 with fix for interaction between
  OnFailure= and Restart=

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Won't Fix
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  services configured with both OnFailure= and Restart= directives will
  both start the failure service(s), as well as restarting itself.  The
  documentation (and later versions) indicate that OnFailure= services
  will only be started once the service actually does stop (due to
  failure) once its restart limit has been exceeded.

  [test case]

  create service files as:

  ubuntu@lp1849261-b:/etc/systemd/system$ cat test.service
  [Unit]
  OnFailure=failure.service

  [Service]
  ExecStart=/bin/sh -c '/bin/sleep 10; /bin/false'
  Restart=always

  ubuntu@lp1849261-b:/etc/systemd/system$ cat failure.service
  [Service]
  ExecStart=/bin/true

  perform daemon-reload, and then start test service:

  ubuntu@lp1849261-b:/etc/systemd/system$ sudo systemctl daemon-reload
  ubuntu@lp1849261-b:/etc/systemd/system$ sudo systemctl start test

  wait for a while for the test service to exit - at least 10 seconds,
  as that's what we configured in the service, although I have waited
  longer in this example.  Then check the journal for both test and
  failure services:

  ubuntu@lp1849261-b:/etc/systemd/system$ journalctl -b -u test
  -- Logs begin at Fri 2019-12-13 00:52:50 UTC, end at Fri 2019-12-13 01:18:34 
UTC. --
  Dec 13 01:17:43 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 1.
  Dec 13 01:17:53 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:17:53 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:04 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:04 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 2.
  Dec 13 01:18:04 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:18:04 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 3.
  Dec 13 01:18:14 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:18:14 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:24 lp1849261-b systemd[1]:

[Touch-packages] [Bug 1860548] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1860548

Title:
  systemd crashes when logging long message

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

Bug description:
  [Impact]

  Systemd crashes when logging very long messages. This regression was 
introduced with
  upstream commit d054f0a4d451 [1] due to xsprintf.
  Commits e68eedbbdc98 [2] and 574432f889ce [3] replace some uses of xsprintf 
with
  snprintf and fix it.

  [Test Case]

  # systemd-run --scope apt-get -q -y -o DPkg::Options::=--force-confold
  -o DPkg::Options::=--force-confdef --allow-unauthenticated install acl
  adduser amd64-microcode apt base-files base-passwd bash bash-
  completion bind9-host binfmt-support binutils-common binutils-x86-64
  -linux-gnu bsdmainutils bsdutils busybox-initramfs busybox-static
  bzip2 ca-certificates console-setup console-setup-linux coreutils cpio
  cpp cpp-7 crda cron curl dash dbus dctrl-tools debconf debconf-i18n
  debianutils dictionaries-common diffutils dirmngr distro-info-data
  dmeventd dmsetup dnsmasq-base dnsutils dpkg e2fslibs e2fsprogs ed
  eject fakeroot fdisk file findutils friendly-recovery gawk gcc-7-base
  gcc-8-base gettext-base gir1.2-glib-2.0 gnupg gnupg-l10n gnupg-utils
  gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv grep
  groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname
  info init init-system-helpers initramfs-tools initramfs-tools-bin
  initramfs-tools-core install-info intel-microcode iproute2 iptables
  iputils-ping iputils-tracepath irqbalance isc-dhcp-client isc-dhcp-
  common iso-codes iw keyboard-configuration keyutils klibc-utils kmod
  krb5-locales krb5-user language-pack-en language-pack-en-base
  language-pack-gnome-en language-pack-gnome-en-base less
  libaccountsservice0 libacl1 libapparmor1 libargon2-0 libasan4
  libasn1-8-heimdal libassuan0 libatm1 libatomic1 libattr1 libaudit-
  common libaudit1  libbinutils libblkid1 libbsd0 libbz2-1.0 libc-bin
  libc-dev-bin libc6 libc6-dev libcap-ng0 libcap2 libcap2-bin libcc1-0
  libcilkrts5 libcom-err2 libcryptsetup12 libcurl3-gnutls libcurl4
  libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper-event1.02.1
  libdevmapper1.02.1 libdpkg-perl libdrm-common libdrm2 libdumbnet1
  libedit2 libelf1 libestr0 libevent-2.1-6 libexpat1 libexpat1-dev
  libext2fs2 libfakeroot libfastjson4 libfdisk1 libffi6 libfreetype6
  libfribidi0 libfuse2 libgc1c2 libgcc-7-dev libgcc1 libgcrypt20
  libgdbm-compat4 libgeoip1 libgirepository-1.0-1 libglib2.0-0
  libglib2.0-data libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2
  libgssapi-krb5-2 libgssapi3-heimdal libgssrpc4 libhcrypto4-heimdal
  libheimbase1-heimdal libheimntlm0-heimdal libhogweed4
  libhx509-5-heimdal libitm1 libjs-jquery libjs-sphinxdoc libjs-
  underscore libk5crypto3 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-9
  libkeyutils1 libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0
  libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0
  liblz4-1 liblzma5 libmagic-mgc libmagic1 libmnl0 libmount1 libmpc3
  libmpdec2 libmpfr6 libmpx2 libmspack0 libncurses5 libncursesw5
  libnetfilter-conntrack3 libnettle6 libnewt0.52 libnfnetlink0
  libnfsidmap2 libnghttp2-14  libnl-3-200 libnl-genl-3-200 libnorm1
  libnpth0 libnss-systemd libnuma1 libp11-kit0 libpam-cap libpam-krb5
  libpam-modules libpam-modules-bin libpam-runtime libpam-systemd
  libpam0g libparted2 libpcap0.8 libpci3 libpcre3 libpgm-5.2-0
  libpipeline1 libplymouth4 libpng16-16 libpolkit-gobject-1-0 libpopt0
  libpsl5 libpython-all-dev libpython-dev libpython-stdlib libpython2.7
  libpython2.7-dev libpython2.7-minimal

  # tail -f /var/log/syslog
  ...
  Jan 22 12:50:33 bionic-kernel systemd[1]: Assertion 'xsprintf: buf[] must be 
big enough' failed at ../src/core/job.c:803, function job_log_status_message(). 
Aborting.

  Broadcast message from systemd-journald@bionic-kernel (Wed 2020-01-22
  12:50:33 UTC):

  systemd[1]: Caught , dumped core as

[Touch-packages] [Bug 1671951] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1671951

Title:
  networkd should allow configuring IPV6 MTU

Status in systemd:
  Unknown
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix
Status in cloud-init source package in Eoan:
  New
Status in netplan.io source package in Eoan:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in cloud-init source package in Focal:
  Confirmed
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as

[Touch-packages] [Bug 1845909] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1845909

Title:
  [SRU] IPv6 link local address is assigned even when
  LinkLocalAddressing=no|ipv4

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

Bug description:
  [impact]

  in some situations when a networkd interface is configured with
  LinkLocalAddressing=no, networkd still assigns a link-local address to
  it

  [test case]

  see comment 3.

  note I was only able to reproduce this at boot time; if the vlan
  interface is removed (i.e. 'sudo ip l del pppoe') and then networkd
  restarted, the pppoe interface is created and does not have a link-
  local address.  This is due to this bug being triggered by timing, as
  a vlan interface is raised by the kernel when its parent interface is
  raised, in this case by networkd itself.

  [regression potential]

  this changes how ipv6ll addresses are managed and dropped, as well as
  changing when foreign addresses are dropped (later in config process).
  Any regressions would likely be around incorrectly setting ipv6ll
  addresses, or complete failure to complete interface configuration.

  [scope]

  this is fixed upstream by:
  https://github.com/systemd/systemd/pull/13927

  and also requires the upstream PR referenced in the original description:
  upstream patch: https://github.com/systemd/systemd/pull/13565

  this is required for focal (uploaded already), eoan, and bionic.  It
  may be required for xenial.

  [other info]

  Note, the original description below is incorrect, the issue/patch it
  references is not enough to fix this issue.

  original description:

  --

  upstream issue: https://github.com/systemd/systemd/issues/12886
  upstream patch: https://github.com/systemd/systemd/pull/13565

  The upstream fix will be available in systemd 244.
  Backport please. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1845909/+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] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 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:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Won't Fix

Bug description:
  [impact]

  if networkd is configured with a static address, and the address has
  already been assigned by dhcp (so that it has finite valid_lft),
  networkd will not change the valid_lft to 'forever' during startup,
  which leaves networkd thinking the address is static (meaning,
  networkd will not attempt to renew the dhcp lease) but the address
  valid_lft counting down.

  Once the valid_lft expires, the kernel will remove the address from
  the interface, breaking the system's networking.

  [test case]

  configure a system with networkd similar to:

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  restart systemd-networkd, and ens3 should get a DHCP address, e.g.:

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2295sec preferred_lft 2295sec

  then, edit the networkd config to use a static address, e.g.:

  [Match]
  Name=ens3

  [Network]
  Address=192.168.122.147/24
  Gateway=192.168.122.1
  DNS=192.168.122.1
  Domains=vm

  make sure to use the exact same address that was provided by dhcp.

  Then, without rebooting, just restart networkd and check the address
  lft:

  $ sudo systemctl restart systemd-networkd

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2992sec preferred_lft 2992sec

  the address should have 'forever' valid_lft, but it doesn't.

  [regression potential]

  this changes the details of how networkd updates static addresses
  during startup, so any regression would occur at networkd startup when
  using static addresses.

  [scope]

  this is needed only in Bionic and Disco.

  this is fixed by upstream:
  https://github.com/systemd/systemd/pull/11460/commits
  specifically commit a47a6daebe0af26c07d8d423225eb4add110793c
  which is included in Eoan and later.

  In Xenial using networkd, testing shows this problem does not occur,
  because this older version of networkd removes the 'foreign' dhcp
  address before re-assigning it as a static address.

  [other info]

  original 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/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   :

[Touch-packages] [Bug 1836695] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 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:
  Fix Committed
Status in systemd source package in Disco:
  Won't Fix
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 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

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1836695/+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 1847816] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1847816

Title:
  storage autopkgtest always fails with linux-{kvm,azure,etc} kernels
  that don't include scsi_debug module

Status in autopkgtest-cloud:
  New
Status in linux-kvm package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in linux-kvm source package in Xenial:
  New
Status in systemd source package in Xenial:
  In Progress
Status in linux-kvm source package in Bionic:
  New
Status in systemd source package in Bionic:
  Fix Committed
Status in linux-kvm source package in Disco:
  New
Status in systemd source package in Disco:
  Won't Fix
Status in linux-kvm source package in Eoan:
  New
Status in systemd source package in Eoan:
  Fix Committed
Status in linux-kvm source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Released

Bug description:
  Note: this bug touches on multiple packages:
  - autopkgtest-cloud: merge request open to install 'modules-extra' package
  - systemd: update autopkgtest to skip test if scsi_debug module isn't 
available (SRU template below is for this change)
  - linux-kvm: has CONFIG_SCSI_DEBUG unset, but would be good to have 
scsi_debug module built for this kernel

  [SRU template for systemd]

  [impact]

  the 'storage' autopkgtest requires the 'scsi_debug' module, and if it
  can't load it (and it's not built-in), the test fails.  On some custom
  kernels, this module is included in the new 'linux-modules-extra-*'
  deb which isn't installed by default, so the test always fails when
  doing a reverse-dep autopkgtest using such a kernel's meta pkg.

  Additionally, some custom kernels, like linux-kvm, have SCSI_DEBUG
  disabled entirely; for those kernels, it will never be possible to
  load the scsi_debug module and the test should be skipped.

  [test case]

  run the 'storage' autopkgtest with a custom kernel that doesn't
  provide the scsi_debug module in the standard linux-modules deb, or
  check the autopkgtest.u.c history, for example:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20191209_150835_237a5@/log.gz

  [regression potential]

  as this modifies one of the autopkgtest --setup-commands, a regression
  would most likely cause immediate test failure due to failing to
  install the proper linux-* debs.

  For the systemd 'storage' test change, this only skips the test if the
  scsi_debug module can't be loaded (and isn't already present, i.e.
  loaded or built-in).  Any regression potential from that is low, but
  likely would involve incorrect test skips and/or missing valid
  problems due to skipping the test.

  [scope]

  systemd in all releases needs to have its 'storage' test updated

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopkgtest-cloud/+bug/1847816/+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 1859862] Autopkgtest regression report (systemd/237-3ubuntu10.39)

All autopkgtests for the newly accepted systemd (237-3ubuntu10.39) for bionic 
have finished running.
The following regressions have been reported in tests triggered by the package:

php7.2/7.2.24-0ubuntu0.18.04.2 (armhf)
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
systemd/237-3ubuntu10.39 (i386)
netplan.io/0.98-0ubuntu1~18.04.1 (i386, amd64)


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/bionic/update_excuses.html#systemd

[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1859862

Title:
  networkd doesn't re-enable ipv6 unless mtu is set

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

Bug description:
  [impact]

  if the 'disable_ipv6' procfs setting is disabled, and networkd is
  configured with ipv6 networking, networkd will not enable ipv6 via the
  procfs setting unless the interface mtu is also set to a custom value,
  that doesn't match the current interface mtu.

  [test case]

  create networkd config similar to:

  [Match]
  MACAddress=52:54:00:0c:09:77
  Name=ens3

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=2001:db8::100/64

  manually disable ipv6 for the interface:

  ubuntu@lp1859862-b:~$ echo 1 | sudo tee 
/proc/sys/net/ipv6/conf/ens3/disable_ipv6
  1

  the interface should not contain any ipv6 addresses:

  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$

  restart networkd; it should enable ipv6 as ipv6 addresses are
  configured, but it does not:

  ubuntu@lp1859862-b:~$ sudo systemctl restart systemd-networkd
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$

  Note that with the mtu set, it will successfully re-enable ipv6;
  modify the networkd config to set the mtu by adding this:

  [Link]
  MTUBytes=1400

  verify ipv6 is still disabled and has no addresses, then restart and
  check again:

  ubuntu@lp1859862-b:~$ cat /proc/sys/net/ipv6/conf/ens3/disable_ipv6
  1
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$ sudo systemctl restart systemd-networkd
  ubuntu@lp1859862-b:~$ cat /proc/sys/net/ipv6/conf/ens3/disable_ipv6
  0
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  2: ens3:  mtu 1400 state UP qlen 1000
  inet6 2001:db8::100/64 scope global
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe0c:977/64 scope link
     valid_lft forever preferred_lft forever

  That should be the behavior even if MTUBytes is not set.

  [regression potential]

  as this adjusts when the procfs 'disable_ipv6' setting is changed, the
  regression potential could cause failure to properly set/create ipv6
  addresses, or to leave ipv6 disabled entirely.

  [scope]

  This is needed in Bionic and Eoan.

  the commit to fix this is 482efedc081b0c4bf2e77a3dee6b979d9c9a5765
  which is included starting in v243, so it is included already in
  Focal.

  Ignoring Disco, as it is EOL next week.

  This problem was introduced by commit
  44b598a1c9d11c23420a5ef45ff11bcb0ed195eb, which was included starting
  in v239, but also backported to Bionic in bug 1850704.

  [other info]

  for Eoan, this bug has always existed since release, but for Bionic,
  this is a regression introduced by bug 1850704.  However, manual
  disabling of ipv6 is very unusual, so this bug is unlikely to have an
  impact to many systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1859862/+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 1862290] Re: Xorg restarts when locked

Thank you for taking the time to report this bug and helping to make
Ubuntu better. It sounds like some part of the system has crashed. To
help us find the cause of the crash please follow these steps:

1. Look in /var/crash for crash files and if found run:
ubuntu-bug YOURFILE.crash
Then tell us the ID of the newly-created bug.

2. If step 1 failed then look at https://errors.ubuntu.com/user/ID where
ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine.
Do you find any links to recent problems on that page? If so then please
send the links to us.

3. If step 2 also failed then apply the workaround from bug 994921,
reboot, reproduce the crash, and retry step 1.

Please take care to avoid attaching .crash files to bugs as we are
unable to process them as file attachments. It would also be a security
risk for yourself.


** Package changed: xorg (Ubuntu) => xorg-server (Ubuntu)

** Changed in: xorg-server (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/1862290

Title:
  Xorg restarts when locked

Status in xorg-server package in Ubuntu:
  Incomplete

Bug description:
  My laptop is currently running Xubuntu 18.04.3. Whenever I lock or
  suspend my laptop, Xorg crashes and restarts, frequently bringing down
  whatever applications are running within it.

  Here's my light-locker --debug, just in case that helps:

  [gs_debug_init] gs-debug.c:106 (20:13:53): Debugging enabled
  [main] light-locker.c:142 (20:13:53):  initializing light-locker 1.8.0
  [main] light-locker.c:164 (20:13:53):  Platform:
  gtk:3
  systemd:yes
  ConsoleKit: yes
  UPower: yes
  [main] light-locker.c:196 (20:13:53):  Features:
  lock-after-screensaver: yes
  late-locking:   yes
  lock-on-suspend:yes
  lock-on-lid:yes
  settings backend:   GSETTINGS
  [main] light-locker.c:198 (20:13:53):  lock after screensaver 0
  [main] light-locker.c:199 (20:13:53):  late locking 0
  [main] light-locker.c:200 (20:13:53):  lock on suspend 0
  [main] light-locker.c:201 (20:13:53):  lock on lid 0
  [main] light-locker.c:202 (20:13:53):  idle hint 0
  [init_session_id] gs-listener-dbus.c:2193 (20:13:53):  Got session-id: 
/org/freedesktop/login1/session/c2
  [init_session_id] gs-listener-dbus.c:2198 (20:13:53):  Got sd-session-id: c2
  [init_seat_path] gs-listener-dbus.c:2279 (20:13:53):   Got seat: 
/org/freedesktop/DisplayManager/Seat0

  ** (light-locker:25569): WARNING **: 20:13:53.499: screensaver already
  running in this session

  And here's my /etc/systemd/logind.conf:

  [Login]
  #NAutoVTs=6
  #ReserveVT=6
  #KillUserProcesses=no
  #KillOnlyUsers=
  #KillExcludeUsers=root
  #InhibitDelayMaxSec=5
  #HandlePowerKey=poweroff
  #HandleSuspendKey=suspend
  #HandleHibernateKey=hibernate
  HandleLidSwitch=ignore
  HandleLidSwitchDocked=ignore
  #PowerKeyIgnoreInhibited=no
  #SuspendKeyIgnoreInhibited=no
  #HibernateKeyIgnoreInhibited=no
  #LidSwitchIgnoreInhibited=yes
  #HoldoffTimeoutSec=30s
  #IdleAction=ignore
  #IdleActionSec=30min
  #RuntimeDirectorySize=10%
  #RemoveIPC=yes
  #InhibitorsMax=8192
  #SessionsMax=8192
  #UserTasksMax=33%

  Additional info:

  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04

  xorg:
Installed: 1:7.7+19ubuntu7.1
Candidate: 1:7.7+19ubuntu7.1
Version table:
   *** 1:7.7+19ubuntu7.1 500
  500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:7.7+19ubuntu7 500
  500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.3.0-28.30~18.04.1-generic 5.3.13
  Uname: Linux 5.3.0-28-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: 
'/proc/driver/nvidia/gpus/:01:00.0'
  .proc.driver.nvidia.registry: Binary: ""
  .proc.driver.nvidia.suspend: suspend hibernate resume
  .proc.driver.nvidia.suspend_depth: default modeset uvm
  .proc.driver.nvidia.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  435.21  Sun Aug 25 08:17:57 
CDT 2019
   GCC version:  gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CompositorRunning: None
  Date: Thu Feb  6 20:03:07 2020
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  DkmsStatus:
   nvidia, 435.21, 4.15.0-76-generic, x86_64: installed
   nvidia, 435.21, 5.0.0-37-generic, x86_64: installed
   nvidia, 435.21, 5.3.0-26-generic, x86_64: installed
   nvidia, 435.21, 5.3.0-28-generic, x86_64: installed
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) 
(prog-if 00 [VGA controller])

[Touch-packages] [Bug 1862281] Re: Repeatable hang within 5 minutes using stress-ng + sleep + usb mouse

Thank you for taking the time to report this bug and helping to make
Ubuntu better. It sounds like some part of the system has crashed. To
help us find the cause of the crash please follow these steps:

1. Look in /var/crash for crash files and if found run:
ubuntu-bug YOURFILE.crash
Then tell us the ID of the newly-created bug.

2. If step 1 failed then look at https://errors.ubuntu.com/user/ID where
ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine.
Do you find any links to recent problems on that page? If so then please
send the links to us.

3. If step 2 also failed then apply the workaround from bug 994921,
reboot, reproduce the crash, and retry step 1.

Please take care to avoid attaching .crash files to bugs as we are
unable to process them as file attachments. It would also be a security
risk for yourself.

** Package changed: xorg (Ubuntu) => ubuntu

** Changed in: 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/1862281

Title:
  Repeatable hang within 5 minutes using stress-ng + sleep + usb mouse

Status in Ubuntu:
  Incomplete

Bug description:
  If I run a thermal transition test script (30 seconds stress-ng, 30
  seconds sleep, in a loop) and move a local USB mouse, Kubuntu reliably
  crashes, usually in the first couple of runs and almost 100% of the
  time by run 6.

  This appears to be hardware-linked, but not due to a specific piece of
  bad hardware: I have swapped literally every piece of hardware in the
  system.

  It shows up (while running the script at the end):
  - On both an MSI B450 Gaming plus max and MSI MPG X570 Gaming plus mainboard.
  - On both an AMD Ryzen 5 3600 and 3600X CPU.
  - With one or two sticks of RAM. I've tested both sticks individually, in 
more than one mainboard slot.
  - Regardless of whether the mainboard is in/attached to a case.
  - Regardless of whether there is an m.2 SSD installed or I'm running off a 
live Kubuntu 19.10 USB stick with no hard disk attached.
  - Regardless of which of two mice I use (an old Logitech one, or a GTX 133 
Gaming mouse).
  - Regardless of whether I'm using a Corsair VS650 or Corsair AX850 PSU.
  - Regardless of whether I'm using an AMD RX 5700 XT or using an Nvidia 
Gigabyte GeForce RTX 2700 Super (with open source drivers in both cases).
  - Regardless of whether I'm using KDE or XFCE.
  - Regardless of whether I'm using the default KDE DM or switch to GDM3 and 
set WaylandEnable=false.
  - Regardless of whether I use the default 5.3.0-29-generic kernel or 
5.4.17-050417-generic.
  - Regardless of whether I go directly into the graphical environment or start 
in runlevel 3 and then manually run startx.
  - Regardless of whether it's on the rising or falling edge of the 
stress-script's temperature changes.
  - Regardless of bios version on the X570 mainboard (the one it shipped with, 
or the newest one released in January 2020).
  - Regardless of whether XMP is on or off in the bios.
  - Regardless of whether I use the default or set global c-state to "control = 
disabled" in the bios.
  - Regardless of whether I add processor.max_cstate=5 idle=halt in grub.
  - Regardless of whether or not speakers are plugged in.
  - Regardless of whether I'm using a USB port that is directly on the 
motherboard or is on the front of the case.
  - Regardless of which monitor it is attached to.

  It doesn't show up:
  - On an old i7-4771 machine I have, also running Kubuntu 19.10, while running 
the test script.
  - When I use a mouse remotely with ssh -Y [ip of the machine I am reporting 
this from] xeyes, while running the test script.
  - When I do non-mouse USB input, ie via a USB keyboard or USB wifi dongle, 
including under saturated network load, while running the test script.
  - During stress tests of the GPU, CPU, etc. Tools like memtest, mprime, 
Unigine Superposition, repeated kernel compiles, etc run stably overnight.
  - When the system is entirely idle aside from mouse movement.
  - When I start in runlevel 3 and run the same test script, using the mouse 
with gpm.
  - Running the same test script without mouse movement: this was stable 
overnight, then crashed within a couple of minutes of moving the mouse.

  It shows up with load other than the stress-ng+sleep script too, but
  much less reliably - I'm writing this bug report on the relevant
  machine, with firefox open. Crashes occur at least once a week under
  these conditions, but not frequently.

  Crashes occur with sensor-reported CPU temperatures of 32 to 41
  degrees Celsius. Nothing is overheating, and the system is stable at
  much higher temperatures under sustained stress tests.

  The symptoms of the crash: the display stops updating and the system
  does not respond to any further input, including via the network or
  magic sysrq key. There is nothing related to it in

[Touch-packages] [Bug 1862290] [NEW] Xorg restarts when locked

2020-02-06 Thread David Colborne

Public bug reported:

My laptop is currently running Xubuntu 18.04.3. Whenever I lock or
suspend my laptop, Xorg crashes and restarts, frequently bringing down
whatever applications are running within it.

Here's my light-locker --debug, just in case that helps:

[gs_debug_init] gs-debug.c:106 (20:13:53):   Debugging enabled
[main] light-locker.c:142 (20:13:53):initializing light-locker 1.8.0
[main] light-locker.c:164 (20:13:53):Platform:
gtk:3
systemd:yes
ConsoleKit: yes
UPower: yes
[main] light-locker.c:196 (20:13:53):Features:
lock-after-screensaver: yes
late-locking:   yes
lock-on-suspend:yes
lock-on-lid:yes
settings backend:   GSETTINGS
[main] light-locker.c:198 (20:13:53):lock after screensaver 0
[main] light-locker.c:199 (20:13:53):late locking 0
[main] light-locker.c:200 (20:13:53):lock on suspend 0
[main] light-locker.c:201 (20:13:53):lock on lid 0
[main] light-locker.c:202 (20:13:53):idle hint 0
[init_session_id] gs-listener-dbus.c:2193 (20:13:53):Got session-id: 
/org/freedesktop/login1/session/c2
[init_session_id] gs-listener-dbus.c:2198 (20:13:53):Got sd-session-id: c2
[init_seat_path] gs-listener-dbus.c:2279 (20:13:53): Got seat: 
/org/freedesktop/DisplayManager/Seat0

** (light-locker:25569): WARNING **: 20:13:53.499: screensaver already
running in this session

And here's my /etc/systemd/logind.conf:

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
#UserTasksMax=33%

Additional info:

Description:Ubuntu 18.04.3 LTS
Release:18.04

xorg:
  Installed: 1:7.7+19ubuntu7.1
  Candidate: 1:7.7+19ubuntu7.1
  Version table:
 *** 1:7.7+19ubuntu7.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
100 /var/lib/dpkg/status
 1:7.7+19ubuntu7 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.3.0-28.30~18.04.1-generic 5.3.13
Uname: Linux 5.3.0-28-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
.proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: 
'/proc/driver/nvidia/gpus/:01:00.0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.suspend: suspend hibernate resume
.proc.driver.nvidia.suspend_depth: default modeset uvm
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module  435.21  Sun Aug 25 08:17:57 
CDT 2019
 GCC version:  gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
CompositorRunning: None
Date: Thu Feb  6 20:03:07 2020
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
DkmsStatus:
 nvidia, 435.21, 4.15.0-76-generic, x86_64: installed
 nvidia, 435.21, 5.0.0-37-generic, x86_64: installed
 nvidia, 435.21, 5.3.0-26-generic, x86_64: installed
 nvidia, 435.21, 5.3.0-28-generic, x86_64: installed
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 
00 [VGA controller])
   Subsystem: Hewlett-Packard Company Skylake GT2 [HD Graphics 520] [103c:80e5]
   Subsystem: Hewlett-Packard Company GM107M [GeForce GTX 950M] [103c:80e5]
InstallationDate: Installed on 2019-04-11 (301 days ago)
InstallationMedia: Xubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 138a:0050 Validity Sensors, Inc. Swipe Fingerprint 
Sensor
 Bus 001 Device 003: ID 8087:0a2a Intel Corp. 
 Bus 001 Device 002: ID 04f2:b50c Chicony Electronics Co., Ltd 
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: HP HP ENVY Notebook
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-28-generic 
root=/dev/mapper/xubuntu--vg-root ro quiet splash vt.handoff=1
SourcePackage: xorg
Symptom: display
Title: Xorg crash
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/27/2018
dmi.bios.vendor: Insyde
dmi.bios.version: F.50
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 80E5
dmi.board.vendor: HP
dmi.board.version: 87.77
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias:

[Touch-packages] [Bug 1862281] Re: Repeatable hang within 5 minutes using stress-ng + sleep + usb mouse

2020-02-06 Thread Ubuntu Foundations Team Bug Bot

** Package changed: ubuntu => xorg (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/1862281

Title:
  Repeatable hang within 5 minutes using stress-ng + sleep + usb mouse

Status in Ubuntu:
  Incomplete

Bug description:
  If I run a thermal transition test script (30 seconds stress-ng, 30
  seconds sleep, in a loop) and move a local USB mouse, Kubuntu reliably
  crashes, usually in the first couple of runs and almost 100% of the
  time by run 6.

  This appears to be hardware-linked, but not due to a specific piece of
  bad hardware: I have swapped literally every piece of hardware in the
  system.

  It shows up (while running the script at the end):
  - On both an MSI B450 Gaming plus max and MSI MPG X570 Gaming plus mainboard.
  - On both an AMD Ryzen 5 3600 and 3600X CPU.
  - With one or two sticks of RAM. I've tested both sticks individually, in 
more than one mainboard slot.
  - Regardless of whether the mainboard is in/attached to a case.
  - Regardless of whether there is an m.2 SSD installed or I'm running off a 
live Kubuntu 19.10 USB stick with no hard disk attached.
  - Regardless of which of two mice I use (an old Logitech one, or a GTX 133 
Gaming mouse).
  - Regardless of whether I'm using a Corsair VS650 or Corsair AX850 PSU.
  - Regardless of whether I'm using an AMD RX 5700 XT or using an Nvidia 
Gigabyte GeForce RTX 2700 Super (with open source drivers in both cases).
  - Regardless of whether I'm using KDE or XFCE.
  - Regardless of whether I'm using the default KDE DM or switch to GDM3 and 
set WaylandEnable=false.
  - Regardless of whether I use the default 5.3.0-29-generic kernel or 
5.4.17-050417-generic.
  - Regardless of whether I go directly into the graphical environment or start 
in runlevel 3 and then manually run startx.
  - Regardless of whether it's on the rising or falling edge of the 
stress-script's temperature changes.
  - Regardless of bios version on the X570 mainboard (the one it shipped with, 
or the newest one released in January 2020).
  - Regardless of whether XMP is on or off in the bios.
  - Regardless of whether I use the default or set global c-state to "control = 
disabled" in the bios.
  - Regardless of whether I add processor.max_cstate=5 idle=halt in grub.
  - Regardless of whether or not speakers are plugged in.
  - Regardless of whether I'm using a USB port that is directly on the 
motherboard or is on the front of the case.
  - Regardless of which monitor it is attached to.

  It doesn't show up:
  - On an old i7-4771 machine I have, also running Kubuntu 19.10, while running 
the test script.
  - When I use a mouse remotely with ssh -Y [ip of the machine I am reporting 
this from] xeyes, while running the test script.
  - When I do non-mouse USB input, ie via a USB keyboard or USB wifi dongle, 
including under saturated network load, while running the test script.
  - During stress tests of the GPU, CPU, etc. Tools like memtest, mprime, 
Unigine Superposition, repeated kernel compiles, etc run stably overnight.
  - When the system is entirely idle aside from mouse movement.
  - When I start in runlevel 3 and run the same test script, using the mouse 
with gpm.
  - Running the same test script without mouse movement: this was stable 
overnight, then crashed within a couple of minutes of moving the mouse.

  It shows up with load other than the stress-ng+sleep script too, but
  much less reliably - I'm writing this bug report on the relevant
  machine, with firefox open. Crashes occur at least once a week under
  these conditions, but not frequently.

  Crashes occur with sensor-reported CPU temperatures of 32 to 41
  degrees Celsius. Nothing is overheating, and the system is stable at
  much higher temperatures under sustained stress tests.

  The symptoms of the crash: the display stops updating and the system
  does not respond to any further input, including via the network or
  magic sysrq key. There is nothing related to it in syslog or
  journalctl, including when I'm running journalctl -f at the time of
  the crash.

  The test script:
  #!/bin/bash
  for x in {1..1}
  do
  echo "Run $x at `date`"
  stress-ng --cpu 12 --cpu-method all --verify -t 30s --metrics-brief
  sleep 30
  done

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  Uname: Linux 5.4.17-050417-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Fri Feb  7 00:02:22 2020
  DistUpgraded: Fresh install
  DistroCodename: eoan
  DistroVariant: ubuntu
  GraphicsCard:
   NVIDIA Corporation Device [10de:1e84] (rev a1) (prog-if 00 [VGA controller])
     Subsystem: Gigabyte Technology Co., Ltd Device [1458:4008]
  InstallationDate: Installed on 2020-01-30 (7

[Touch-packages] [Bug 1862281] [NEW] Repeatable hang within 5 minutes using stress-ng + sleep + usb mouse

You have been subscribed to a public bug:

If I run a thermal transition test script (30 seconds stress-ng, 30
seconds sleep, in a loop) and move a local USB mouse, Kubuntu reliably
crashes, usually in the first couple of runs and almost 100% of the time
by run 6.

This appears to be hardware-linked, but not due to a specific piece of
bad hardware: I have swapped literally every piece of hardware in the
system.

It shows up (while running the script at the end):
- On both an MSI B450 Gaming plus max and MSI MPG X570 Gaming plus mainboard.
- On both an AMD Ryzen 5 3600 and 3600X CPU.
- With one or two sticks of RAM. I've tested both sticks individually, in more 
than one mainboard slot.
- Regardless of whether the mainboard is in/attached to a case.
- Regardless of whether there is an m.2 SSD installed or I'm running off a live 
Kubuntu 19.10 USB stick with no hard disk attached.
- Regardless of which of two mice I use (an old Logitech one, or a GTX 133 
Gaming mouse).
- Regardless of whether I'm using a Corsair VS650 or Corsair AX850 PSU.
- Regardless of whether I'm using an AMD RX 5700 XT or using an Nvidia Gigabyte 
GeForce RTX 2700 Super (with open source drivers in both cases).
- Regardless of whether I'm using KDE or XFCE.
- Regardless of whether I'm using the default KDE DM or switch to GDM3 and set 
WaylandEnable=false.
- Regardless of whether I use the default 5.3.0-29-generic kernel or 
5.4.17-050417-generic.
- Regardless of whether I go directly into the graphical environment or start 
in runlevel 3 and then manually run startx.
- Regardless of whether it's on the rising or falling edge of the 
stress-script's temperature changes.
- Regardless of bios version on the X570 mainboard (the one it shipped with, or 
the newest one released in January 2020).
- Regardless of whether XMP is on or off in the bios.
- Regardless of whether I use the default or set global c-state to "control = 
disabled" in the bios.
- Regardless of whether I add processor.max_cstate=5 idle=halt in grub.
- Regardless of whether or not speakers are plugged in.
- Regardless of whether I'm using a USB port that is directly on the 
motherboard or is on the front of the case.
- Regardless of which monitor it is attached to.

It doesn't show up:
- On an old i7-4771 machine I have, also running Kubuntu 19.10, while running 
the test script.
- When I use a mouse remotely with ssh -Y [ip of the machine I am reporting 
this from] xeyes, while running the test script.
- When I do non-mouse USB input, ie via a USB keyboard or USB wifi dongle, 
including under saturated network load, while running the test script.
- During stress tests of the GPU, CPU, etc. Tools like memtest, mprime, Unigine 
Superposition, repeated kernel compiles, etc run stably overnight.
- When the system is entirely idle aside from mouse movement.
- When I start in runlevel 3 and run the same test script, using the mouse with 
gpm.
- Running the same test script without mouse movement: this was stable 
overnight, then crashed within a couple of minutes of moving the mouse.

It shows up with load other than the stress-ng+sleep script too, but
much less reliably - I'm writing this bug report on the relevant
machine, with firefox open. Crashes occur at least once a week under
these conditions, but not frequently.

Crashes occur with sensor-reported CPU temperatures of 32 to 41 degrees
Celsius. Nothing is overheating, and the system is stable at much higher
temperatures under sustained stress tests.

The symptoms of the crash: the display stops updating and the system
does not respond to any further input, including via the network or
magic sysrq key. There is nothing related to it in syslog or journalctl,
including when I'm running journalctl -f at the time of the crash.

The test script:
#!/bin/bash
for x in {1..1}
do
echo "Run $x at `date`"
stress-ng --cpu 12 --cpu-method all --verify -t 30s --metrics-brief
sleep 30
done

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: xorg 1:7.7+19ubuntu12
Uname: Linux 5.4.17-050417-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: KDE
Date: Fri Feb  7 00:02:22 2020
DistUpgraded: Fresh install
DistroCodename: eoan
DistroVariant: ubuntu
GraphicsCard:
 NVIDIA Corporation Device [10de:1e84] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Gigabyte Technology Co., Ltd Device [1458:4008]
InstallationDate: Installed on 2020-01-30 (7 days ago)
InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
MachineType: Micro-Star International Co., Ltd. MS-7C37
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.17-050417-generic 
root=UUID=1a1a3bcc-cc59-4982-a1f5-f721ef6fe937 ro quiet splash 
acpi_enforce_resources=lax vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/08/2020
dmi.bios.vendor:

[Touch-packages] [Bug 1742941] Comment bridged from LTC Bugzilla

2020-02-06 Thread bugproxy

--- Comment From danie...@au1.ibm.com 2020-02-06 22:14 EDT---
Where we are up to is there is a small amount of progress in the zlib-devel 
(https://zlib.net/mailman/listinfo/zlib-devel_madler.net) however nothing 
explicit on or off list about merging arch specific patches (from any 
architecture vendor).

At the request of the community and other vendors, we have added explicit crc32 
tests to the zlib and these have been pushed to that upstream PR.
https://github.com/madler/zlib/pull/335

Since the patch on this bug report, the code has been changed from ASM
to C (to increase the portability ), conformed closer to an upstream
style as far a location and interfaces, and improved the test suite as
mentioned.

The zlib1g-dev package in focal (https://packages.ubuntu.com/focal
/zlib1g-dev)  still uses configure && make which the upstream PR patches
correctly (notably I haven't patched CMakefiles as of today). Building
`make crc32_test && ./crc32_test` as a test can be done quickly in the
package build process to validate the accuracy.

We hope this prudence and validation in the upstream PR
https://github.com/madler/zlib/pull/335 can be accepted for the
ubuntu-20.04 LTS release of the zlib package while we continue to work
with upstream on maintenance.

Thanks for your consideration.

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

Title:
  zlib: improve  crc32 performance on P8

Status in The Ubuntu-power-systems project:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete

Bug description:
  Calculate the checksum of data that is 16 byte aligned and a multiple
  of  16 bytes.

  The first step is to reduce it to 1024 bits. We do this in 8 parallel
   chunks in order to mask the latency of the vpmsum instructions. If we
   have more than 32 kB of data to checksum we repeat this step multiple
   times, passing in the previous 1024 bits.

   The next step is to reduce the 1024 bits to 64 bits. This step adds
   32 bits of 0s to the end - this matches what a CRC does. We just
   calculate constants that land the data in this 32 bits.

   We then use fixed point Barrett reduction to compute a mod n over GF(2)
   for n = CRC using POWER8 instructions. We use x = 32.

   http://en.wikipedia.org/wiki/Barrett_reduction

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1742941/+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 1840725] Re: Microphone not working in Ubuntu 18.04.3 LTS on new hp-spectre-x360-convertible-15 laptop

2020-02-06 Thread Cheyenne Aberle

I have the same issue on my HP Envy 15 x360.  Internal microphone isn't
detected, but headset microphone is when it's plugged in.

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

Title:
  Microphone not working in Ubuntu 18.04.3 LTS on new hp-
  spectre-x360-convertible-15 laptop

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Internal Microphone does not work in Ubuntu 18.04.3 LTS in a new hp-
  spectre-x360-convertible-15 laptop. The microphone works perfectly on
  Windows 10 (present in Dual boot mode).

  Initially, Internal Microphone was not even detected but installing
  alsa-tools-gui and overriding pin 0x12 to the Internal Microphone
  fixed that issue. [Pin 0x13 does not work and causes static in a
  headphone if it is plugged in.]

  Microphone is not able to pick up any sound. I changed levels/settings in 
alsamixer, pavucontrol without any success:
  In alsamixer: Experimented with levels ranging from very low to very high for 
Internal Mic, Capture, etc.
  In pavucontrol: Set the Internal Mic as a fallback device, unlocked the 
channels for the mic, experimented with reducing the level for one of the 
channels (reduced right mic level to Silence while keeping the left mic level 
normal/high and vice versa).

  alsa-info:
  http://alsa-project.org/db/?f=cf6d3ccc6372f955da7d99df07afbcb31d5a6c7f

  arecord -l
   List of CAPTURE Hardware Devices 
  card 0: PCH [HDA Intel PCH], device 0: ALC285 Analog [ALC285 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1840725/+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 1859107] Re: problems

Please be careful to only report one issue per bug report.

I can see in your kernel logs what you mention in the first issue.

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

Title:
  problems

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  1 / when ubuntu start disorder at the begining many command writen
  everywhere on screen then its writen again with order

  2/ all my documents and all my tools impossible to open files blocked
  archives blocked

  3/ disc runing doing many noise

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44
  Uname: Linux 4.4.0-66-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Fri Jan 10 02:22:50 2020
  DistUpgraded: 2016-08-01 11:52:39,263 ERROR got error from PostInstallScript 
./xorg_fix_proprietary.py (L'exécution du processus fils « 
./xorg_fix_proprietary.py » a échoué (Aucun fichier ou dossier de ce type))
  DistroCodename: xenial
  DistroVariant: ubuntu
  DpkgLog:
   
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] RS482/RS485 [Radeon Xpress 1100/1150] 
[1002:5974] (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company DC5750 Microtower [103c:280a]
 Subsystem: Hewlett-Packard Company RS480 [Radeon Xpress 1150] (Secondary) 
[103c:280b]
  MachineType: Hewlett-Packard HP Compaq dc5750 Microtower
  ProcEnviron:
   PATH=(custom, no user)
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-66-generic 
root=UUID=5c6c0f08-be2e-4bbf-8e22-05238972f64e ro drm.debug=0xe plymouth:debug 
nopat vesafb.invalid=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to xenial on 2016-08-01 (1256 days ago)
  dmi.bios.date: 01/25/2007
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: 786E3 v02.10
  dmi.board.name: 0A64h
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: CZC72544ZW
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvr786E3v02.10:bd01/25/2007:svnHewlett-Packard:pnHPCompaqdc5750Microtower:pvr:rvnHewlett-Packard:rn0A64h:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.name: HP Compaq dc5750 Microtower
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz N/A
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 12.0.6-0ubuntu0.16.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2
  xserver.bootTime: Mon Aug  1 02:46:56 2016
  xserver.configfile: default
  xserver.devices:
   inputPower Button KEYBOARD, id 6
   inputPower Button KEYBOARD, id 7
   inputAT Translated Set 2 keyboard KEYBOARD, id 8
   inputImPS/2 Generic Wheel Mouse MOUSE, id 9
   inputHP WMI hotkeys   KEYBOARD, id 10
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.15.1-0ubuntu2.7
  xserver.video_driver: radeon

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1859107/+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 1859107] Re: problems

It appears all those radeon kernel messages are because you asked for
them in your kernel command line:

  drm.debug=0xe plymouth:debug nopat vesafb.invalid=1

Please remove those kernel parameters and then tell us what if any
problems persist after that.

** Package changed: xorg (Ubuntu) => linux (Ubuntu)

** Changed in: linux (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/1859107

Title:
  problems

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  1 / when ubuntu start disorder at the begining many command writen
  everywhere on screen then its writen again with order

  2/ all my documents and all my tools impossible to open files blocked
  archives blocked

  3/ disc runing doing many noise

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44
  Uname: Linux 4.4.0-66-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Fri Jan 10 02:22:50 2020
  DistUpgraded: 2016-08-01 11:52:39,263 ERROR got error from PostInstallScript 
./xorg_fix_proprietary.py (L'exécution du processus fils « 
./xorg_fix_proprietary.py » a échoué (Aucun fichier ou dossier de ce type))
  DistroCodename: xenial
  DistroVariant: ubuntu
  DpkgLog:
   
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] RS482/RS485 [Radeon Xpress 1100/1150] 
[1002:5974] (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company DC5750 Microtower [103c:280a]
 Subsystem: Hewlett-Packard Company RS480 [Radeon Xpress 1150] (Secondary) 
[103c:280b]
  MachineType: Hewlett-Packard HP Compaq dc5750 Microtower
  ProcEnviron:
   PATH=(custom, no user)
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-66-generic 
root=UUID=5c6c0f08-be2e-4bbf-8e22-05238972f64e ro drm.debug=0xe plymouth:debug 
nopat vesafb.invalid=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to xenial on 2016-08-01 (1256 days ago)
  dmi.bios.date: 01/25/2007
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: 786E3 v02.10
  dmi.board.name: 0A64h
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: CZC72544ZW
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvr786E3v02.10:bd01/25/2007:svnHewlett-Packard:pnHPCompaqdc5750Microtower:pvr:rvnHewlett-Packard:rn0A64h:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.name: HP Compaq dc5750 Microtower
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz N/A
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 12.0.6-0ubuntu0.16.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2
  xserver.bootTime: Mon Aug  1 02:46:56 2016
  xserver.configfile: default
  xserver.devices:
   inputPower Button KEYBOARD, id 6
   inputPower Button KEYBOARD, id 7
   inputAT Translated Set 2 keyboard KEYBOARD, id 8
   inputImPS/2 Generic Wheel Mouse MOUSE, id 9
   inputHP WMI hotkeys   KEYBOARD, id 10
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.15.1-0ubuntu2.7
  xserver.video_driver: radeon

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1859107/+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 1857766] Re: interrupts internet connection

*** This bug is a duplicate of bug 1858280 ***
https://bugs.launchpad.net/bugs/1858280

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).
Thanks!


** Package changed: xorg (Ubuntu) => ubuntu

** Changed in: ubuntu
   Status: New => Incomplete

** This bug has been marked a duplicate of bug 1858280
   Firefox reports "cannot connect to internet" message

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

Title:
  interrupts internet connection

Status in Ubuntu:
  Incomplete

Bug description:
  mimics failed network connection, works randomly, sometimes 1st power
  up and search engine enabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Sat Dec 28 11:20:23 2019
  DistUpgraded: 2018-12-25 11:16:26,692 DEBUG icon theme changed, re-reading
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] RV610 [Radeon HD 2400 PRO] 
[1002:94c3] (prog-if 00 [VGA controller])
 Subsystem: Dell Radeon HD 2400 Pro [1028:0302]
  InstallationDate: Installed on 2016-08-03 (1242 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: Dell Inc. Dell XPS420
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-72-generic 
root=UUID=e737e1ac-8869-44b7-a03f-477223f8 ro drm.debug=0xe plymouth:debug
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2018-12-25 (368 days ago)
  dmi.bios.date: 03/27/2008
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A04
  dmi.board.name: 0TP406
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA04:bd03/27/2008:svnDellInc.:pnDellXPS420:pvr:rvnDellInc.:rn0TP406:rvr:cvnDellInc.:ct7:cvr:
  dmi.product.name: Dell XPS420
  dmi.sys.vendor: Dell Inc.
  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.3
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.3
  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: Tue Dec 25 08:33:58 2018
  xserver.configfile: default
  xserver.devices:
   inputPower Button KEYBOARD, id 6
   inputPower Button KEYBOARD, id 7
   inputLogitech Logitech USB Speaker KEYBOARD, id 8
   inputLogitech USB-PS/2 Optical Mouse MOUSE, id 9
   inputDell Dell USB Keyboard KEYBOARD, id 10
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.18.4-0ubuntu0.8
  xserver.video_driver: radeon

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1857766/+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 1862225] Re: the laptop freeze

Thank you for taking the time to report this bug and helping to make
Ubuntu better. It sounds like some part of the system has crashed. To
help us find the cause of the crash please follow these steps:

1. Look in /var/crash for crash files and if found run:
ubuntu-bug YOURFILE.crash
Then tell us the ID of the newly-created bug.

2. If step 1 failed then look at https://errors.ubuntu.com/user/ID where
ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine.
Do you find any links to recent problems on that page? If so then please
send the links to us.

3. If step 2 also failed then apply the workaround from bug 994921,
reboot, reproduce the crash, and retry step 1.

Please take care to avoid attaching .crash files to bugs as we are
unable to process them as file attachments. It would also be a security
risk for yourself.


** Package changed: xorg (Ubuntu) => xorg-server (Ubuntu)

** Changed in: xorg-server (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/1862225

Title:
  the laptop freeze

Status in xorg-server package in Ubuntu:
  Incomplete

Bug description:
  the laptop freeze

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.3.0-28.30~18.04.1-generic 5.3.13
  Uname: Linux 5.3.0-28-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Thu Feb  6 10:50:10 2020
  DistUpgraded: 2020-01-15 21:02:05,550 DEBUG icon theme changed, re-reading
  DistroCodename: bionic
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 390.116, 5.3.0-28-generic, x86_64: installed
  GraphicsCard:
   Intel Corporation Device [8086:3ea0] (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device [17aa:2286]
  InstallationDate: Installed on 2020-01-16 (21 days ago)
  InstallationMedia: Ubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 
(20190227)
  MachineType: LENOVO 20Q0002EUS
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-28-generic 
root=UUID=125967d5-379e-4de9-aa68-c6208d80892a ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2020-01-16 (21 days ago)
  dmi.bios.date: 01/03/2020
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N2JET84W (1.62 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20Q0002EUS
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN2JET84W(1.62):bd01/03/2020:svnLENOVO:pn20Q0002EUS:pvrThinkPadX390:rvnLENOVO:rn20Q0002EUS:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad X390
  dmi.product.name: 20Q0002EUS
  dmi.product.sku: LENOVO_MT_20Q0_BU_Think_FM_ThinkPad X390
  dmi.product.version: ThinkPad X390
  dmi.sys.vendor: LENOVO
  version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
  version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.2
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.2
  version.xserver-xorg-core: xserver-xorg-core N/A
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A
  xserver.bootTime: Wed Jan 15 20:25:03 2020
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.19.6-1ubuntu4.1~16.04.2
  xserver.video_driver: modeset

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1862225/+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 1858280] Re: Firefox reports "cannot connect to internet" message

** Summary changed:

- Software mimics internet disconnect problem on startup
+ Firefox reports "cannot connect to internet" message

** Package changed: xorg (Ubuntu) => firefox (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/1858280

Title:
  Firefox reports "cannot connect to internet" message

Status in firefox package in Ubuntu:
  New

Bug description:
  Upon initial start-up, when opening Firefox browser, a  "cannot
  connect to internet message" is displayed on-screen. It suggest to
  check wiring, but wiring is fine but I checked it still. I run the
  diagnostics and go to submit trouble report and the bug clears out.
  The diagnostics do a list of program files that I have submitted
  numerous times alreadyToday the disconnect happened on 2nd startup
  after computer was shut down for a bit. I always use Firefox browser,
  and never had problems before these incidents. I am always able to
  recover after diagnostics are run. Is there a bug clearing program
  that I can run to clear out this nuisance problem??  Thank you for
  your time, J. Chosta

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Sat Jan  4 10:33:13 2020
  DistUpgraded: 2018-12-25 11:16:26,692 DEBUG icon theme changed, re-reading
  DistroCodename: bionic
  DistroVariant: ubuntu
  DpkgLog:
   
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] RV610 [Radeon HD 2400 PRO] 
[1002:94c3] (prog-if 00 [VGA controller])
 Subsystem: Dell Radeon HD 2400 Pro [1028:0302]
  InstallationDate: Installed on 2016-08-03 (1249 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: Dell Inc. Dell XPS420
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-72-generic 
root=UUID=e737e1ac-8869-44b7-a03f-477223f8 ro drm.debug=0xe plymouth:debug
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2018-12-25 (374 days ago)
  dmi.bios.date: 03/27/2008
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A04
  dmi.board.name: 0TP406
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA04:bd03/27/2008:svnDellInc.:pnDellXPS420:pvr:rvnDellInc.:rn0TP406:rvr:cvnDellInc.:ct7:cvr:
  dmi.product.name: Dell XPS420
  dmi.sys.vendor: Dell Inc.
  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.3
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.3
  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: Tue Dec 25 08:33:58 2018
  xserver.configfile: default
  xserver.devices:
   inputPower Button KEYBOARD, id 6
   inputPower Button KEYBOARD, id 7
   inputLogitech Logitech USB Speaker KEYBOARD, id 8
   inputLogitech USB-PS/2 Optical Mouse MOUSE, id 9
   inputDell Dell USB Keyboard KEYBOARD, id 10
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.18.4-0ubuntu0.8
  xserver.video_driver: radeon

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1858280/+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 1861757] Re: Missing libgcc_s.so.1 decrypting partition on boot

2020-02-06 Thread Bug Watch Updater

** Changed in: initramfs-tools (Debian)
   Status: Unknown => Fix Committed

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

Title:
  Missing libgcc_s.so.1 decrypting partition on boot

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Debian:
  Fix Committed

Bug description:
  On focal with -proposed repo enabled. Updated all packages and
  rebooted. Upon entering the LUKS passphrase for disk decryption I get
  the following message, and cannot boot:

"libgcc_s.so.1 must be installed for pthread_cancel to work"

  Booting with the previous kernel works.

  Found this question with an identical issue:
  https://askubuntu.com/questions/1190687/ubuntu-19-10-missing-lib-gcc-
  so-1-after-kernel-update, which points to "/usr/share/initramfs-
  tools/hooks/cryptroot" being unable to find that lib. It was looking
  in "/lib/x86_64-linux-gnu/", but libgcc_s.so.1 is not there, but at
  "/usr/lib/" and "/usr/lib/x86_64-linux-gnu/". Temporarily fixed by
  copying the file to "/lib/x86_64-linux-gnu/" and regenerating the
  initramdisk.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libgcc1 1:10-20200202-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-13.16-generic 5.4.16
  Uname: Linux 5.4.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Feb  4 00:05:48 2020
  InstallationDate: Installed on 2019-09-23 (133 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190917)
  SourcePackage: gcc-10
  UpgradeStatus: Upgraded to focal on 2020-01-24 (10 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757/+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 1860606] Re: TypeError: _fetch_archives() missing 1 required positional argument: 'allow_unauthenticated'

This bug was fixed in the package python-apt - 1.9.5

---
python-apt (1.9.5) experimental; urgency=medium

  [ Marc Deslauriers ]
  * SECURITY REGRESSION: crash with ubuntu-release-upgrader (LP: #1860606)
- apt/cache.py: make allow_unauthenticated argument to
  fetch_archives() optional.

  [ Julian Andres Klode ]
  * Really bump aptdaemon break (to 1.1.1+bzr982-0ubuntu31)

 -- Julian Andres Klode   Thu, 23 Jan 2020 10:55:46
+0100

** Changed in: python-apt (Ubuntu Focal)
   Status: Confirmed => Fix Released

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

Title:
  TypeError: _fetch_archives() missing 1 required positional argument:
  'allow_unauthenticated'

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Released
Status in python-apt source package in Bionic:
  Fix Released
Status in python-apt source package in Disco:
  Fix Released
Status in python-apt source package in Eoan:
  Fix Released
Status in python-apt source package in Focal:
  Fix Released

Bug description:
  I was upgrading my workstation from 19.04 to 19.10 and following that
  to 20.04. In each case I used do-release-upgrade (without and with -d
  respectively). The 20.04 upgrade failed as the tool crashed on invalid
  function signature:

  Original exception was:
  Traceback (most recent call last):
File "/tmp/ubuntu-release-upgrader-f_816ncr/focal", line 8, in 
  sys.exit(main())
File 
"/tmp/ubuntu-release-upgrader-f_816ncr/DistUpgrade/DistUpgradeMain.py", line 
238, in main
  if app.run():
File 
"/tmp/ubuntu-release-upgrader-f_816ncr/DistUpgrade/DistUpgradeController.py", 
line 2082, in run
  return self.fullUpgrade()
File 
"/tmp/ubuntu-release-upgrader-f_816ncr/DistUpgrade/DistUpgradeController.py", 
line 1998, in fullUpgrade
  if not self.doDistUpgradeFetching():
File 
"/tmp/ubuntu-release-upgrader-f_816ncr/DistUpgrade/DistUpgradeController.py", 
line 1233, in doDistUpgradeFetching
  self.cache._fetch_archives(self.fetcher, pm)
  TypeError: _fetch_archives() missing 1 required positional argument: 
'allow_unauthenticated'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1860606/+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 1862267] [NEW] sqlite3 3.31.1-1 is broken on s390x

Public bug reported:

sqlite3 3.31.1-1 is broken on s390x


for example building orthanc against  3.30.1-1ubuntu1 is successful without any 
errors,

whilst upgrading sqlite3 to 3.31.1-1 and reruning the orthanc testsuite
without rebuilding results in segfaults.

please remove 3.31.1-1 sqlite3 from the archive until it is fixed on
s390x.

** Affects: sqlite3 (Ubuntu)
 Importance: Undecided
 Status: Confirmed


** Tags: block-proposed s390x

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

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

Title:
  sqlite3 3.31.1-1 is broken on s390x

Status in sqlite3 package in Ubuntu:
  Confirmed

Bug description:
  sqlite3 3.31.1-1 is broken on s390x

  
  for example building orthanc against  3.30.1-1ubuntu1 is successful without 
any errors,

  whilst upgrading sqlite3 to 3.31.1-1 and reruning the orthanc
  testsuite without rebuilding results in segfaults.

  please remove 3.31.1-1 sqlite3 from the archive until it is fixed on
  s390x.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1862267/+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 1857051] Re: Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)

This bug was fixed in the package unattended-upgrades - 1.17

---
unattended-upgrades (1.17) unstable; urgency=medium

  [ Amit Gurdasani ]
  * Check that a candidate is available before checking the version has changed.
  * Add test case to check upgrade calculation behavior for a package with no
candidate.

  [ Balint Reczey ]
  * Fix help about --no-minimal-upgrade-steps (Closes: #946379)
  * data/50unattended-upgrades.Ubuntu: add new ESM repositories (LP: #1857051)

 -- Balint Reczey   Thu, 23 Jan 2020 16:20:04 +0100

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

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

Title:
  Please add ${distro_id}ESM:${distro_codename}-infra-security  and
  ${distro_id}ESMApps:${distro_codename}-apps-security to allowed
  origins (on Ubuntu)

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

Bug description:
  [Impact]

   * Changes to the ESM repo naming and the introduction of the new esm-infra 
and esm-apps suites require an update to unattended-upgrades to ensure the 
security pockets are used.
   * This change will ensure users are actually receiving updates, where as 
today they will not without making manual changes.

  [Test Case]

   * 1) Bionic and Xenial ESM-Apps/ESM-infra with Ubuntu Pro
   * 2) Trusty ESM

  [Regression Potential]

   * This change is ensuring users actually receive security updates when using 
ESM. Therefore, 1) users of ESM-apps on Ubuntu Pro and 2) ESM-infra on Trusty 
will be the only users affected.
   * The possible issue would be if/when users receive actual security updates 
that then regress or cause issues to the system.

  [Other Info]
   
  Previous description:

  ESM -infra-security and -apps-security will need to
  participate in unattended upgrades.

  Currently /etc/apt/apt.conf.d/50unattended-upgrades provides:
  Unattended-Upgrade::Allowed-Origins {
  "${distro_id}ESM:${distro_codename}";
  }

  Given that there have been ESM apt pocket renames over the last few
  months, the above ESM allowed-origin should not apply anymore and can
  be dropped or replaced.

  See RT #C122697 and #C121067 for the pocket/suite renames related to
  ESM

  What is needed after the ESM apt pocket/suite renames:

  Support for unattended upgrades for ESM for Infrastructure customers:

  Unattended-Upgrade::Allowed-Origins {
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
  };

  === Confirmed proper origin on an attached Trusty instance with ESM-
  infra enabled:

   500 https://esm.ubuntu.com/ubuntu/ trusty-infra-security/main amd64 Packages
   release 
v=14.04,o=UbuntuESM,a=trusty-infra-security,n=trusty,l=UbuntuESM,c=main

  === Confirmed proper origins on Bionic for enabled ESM-infra and ESM-apps on 
an AWS Ubuntu PRO instance:
   500 https://esm.ubuntu.com/infra/ubuntu bionic-infra-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESM,a=bionic-infra-security,n=bionic,l=UbuntuESM,c=main,b=amd64

   500 https://esm.ubuntu.com/apps/ubuntu bionic-apps-security/main amd64 
Packages
   release 
v=18.04,o=UbuntuESMApps,a=bionic-apps-security,n=bionic,l=UbuntuESMApps,c=main,b=amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051/+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 1762391] Re: pam_group.so is not evaluated by gnome-terminal

Hello mtemp, or anyone else affected,

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

** Tags removed: verification-failed verification-failed-eoan
** Tags added: verification-needed verification-needed-eoan

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

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

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

Title:
  pam_group.so is not evaluated by gnome-terminal

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

Bug description:
  [Impact]

  pam_setcred call was missing in systemd making its implementation of the PAM 
protocol incomplete. It could manifest in different ways, but one particularly 
problematic for enterprise environments was the fact that
  processes were never getting group membership they were expected to get via 
pam_group module.

  [Test Case]

   * Add a /etc/security/group.conf entry, e.g.
     *;*;*;Al-2400;dialout,users
   * Add pam_group to your PAM stack, e.g. /etc/pam.d/common-auth
   * Login to the system and launch gnome-terminal (it will be launched via 
gnome-terminal-server launched by systemd --user + dbus).

  Expected result:
  Logged in user is a member of 'dialout' and 'users' groups.

  Actual result:
  no group membership gained from pam_group.

  [Regression Potential]

   * It introduces a new PAM warning message in some scenarios (e.g. for
  systemd DynamicUser=1 units) for users that can't authenticate
  (pam_setcred fails in such case).

   * In certain systems user group membership may be extended by
  pam_group.

  [Other Info]
  Original bug description:

  We are using Ubuntu in a university network with lots of ldap users.
  To automatically map ldap users/groups to local groups we are using
  pam_group.so. This has worked for years.

  With the upgrade from Xenial to Bionic /etc/security/group.conf is not
  evaluated anymore by gnome-terminal as it runs as systemd --user.
  Xterm, ssh, su, and tty* however do work as expected. Only the default
  gnome-terminal behaves different.

  According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243
  and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this
  might not be a bug, but a feature.

  Nevertheless this behavior is very unexpected when upgrading from
  Xenial to Bionic and therefore should at least added to the changelog.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-terminal 3.28.0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu4
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  9 13:17:52 2018
  InstallationDate: Installed on 2018-03-29 (11 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1762391/+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 1762391] Please test proposed package

Hello mtemp, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

Title:
  pam_group.so is not evaluated by gnome-terminal

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

Bug description:
  [Impact]

  pam_setcred call was missing in systemd making its implementation of the PAM 
protocol incomplete. It could manifest in different ways, but one particularly 
problematic for enterprise environments was the fact that
  processes were never getting group membership they were expected to get via 
pam_group module.

  [Test Case]

   * Add a /etc/security/group.conf entry, e.g.
     *;*;*;Al-2400;dialout,users
   * Add pam_group to your PAM stack, e.g. /etc/pam.d/common-auth
   * Login to the system and launch gnome-terminal (it will be launched via 
gnome-terminal-server launched by systemd --user + dbus).

  Expected result:
  Logged in user is a member of 'dialout' and 'users' groups.

  Actual result:
  no group membership gained from pam_group.

  [Regression Potential]

   * It introduces a new PAM warning message in some scenarios (e.g. for
  systemd DynamicUser=1 units) for users that can't authenticate
  (pam_setcred fails in such case).

   * In certain systems user group membership may be extended by
  pam_group.

  [Other Info]
  Original bug description:

  We are using Ubuntu in a university network with lots of ldap users.
  To automatically map ldap users/groups to local groups we are using
  pam_group.so. This has worked for years.

  With the upgrade from Xenial to Bionic /etc/security/group.conf is not
  evaluated anymore by gnome-terminal as it runs as systemd --user.
  Xterm, ssh, su, and tty* however do work as expected. Only the default
  gnome-terminal behaves different.

  According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243
  and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this
  might not be a bug, but a feature.

  Nevertheless this behavior is very unexpected when upgrading from
  Xenial to Bionic and therefore should at least added to the changelog.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-terminal 3.28.0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu4
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  9 13:17:52 2018
  InstallationDate: Installed on 2018-03-29 (11 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1762391/+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 1831459] Re: 'storage' test needs to wait for systemd-cryptsetup to be active before stopping it

Hello Dan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

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

Title:
  'storage' test needs to wait for systemd-cryptsetup to be active
  before stopping it

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

Bug description:
  [impact]

  test case fails because it does not wait for the service to become
  active before stopping it, resulting in failure to rmmod the
  scsi_debug module because it's still in use.

  [test case]

  check 'storage' test results for systemd in 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]

  low; test case fix only.

  [other info]

  detected and reported by @cascardo in bug 1814373 comment 4 and 5, but
  separate (non-test) systemd bugfix uploaded for that bug so opening
  this bug to track fixing the test case.

  larger fixes/improvements to 'storage' testcase in bug 1829347, but
  those rejected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831459/+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 1847816] Please test proposed package

Hello Dan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

Title:
  storage autopkgtest always fails with linux-{kvm,azure,etc} kernels
  that don't include scsi_debug module

Status in autopkgtest-cloud:
  New
Status in linux-kvm package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in linux-kvm source package in Xenial:
  New
Status in systemd source package in Xenial:
  In Progress
Status in linux-kvm source package in Bionic:
  New
Status in systemd source package in Bionic:
  Fix Committed
Status in linux-kvm source package in Disco:
  New
Status in systemd source package in Disco:
  Won't Fix
Status in linux-kvm source package in Eoan:
  New
Status in systemd source package in Eoan:
  Fix Committed
Status in linux-kvm source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Released

Bug description:
  Note: this bug touches on multiple packages:
  - autopkgtest-cloud: merge request open to install 'modules-extra' package
  - systemd: update autopkgtest to skip test if scsi_debug module isn't 
available (SRU template below is for this change)
  - linux-kvm: has CONFIG_SCSI_DEBUG unset, but would be good to have 
scsi_debug module built for this kernel

  [SRU template for systemd]

  [impact]

  the 'storage' autopkgtest requires the 'scsi_debug' module, and if it
  can't load it (and it's not built-in), the test fails.  On some custom
  kernels, this module is included in the new 'linux-modules-extra-*'
  deb which isn't installed by default, so the test always fails when
  doing a reverse-dep autopkgtest using such a kernel's meta pkg.

  Additionally, some custom kernels, like linux-kvm, have SCSI_DEBUG
  disabled entirely; for those kernels, it will never be possible to
  load the scsi_debug module and the test should be skipped.

  [test case]

  run the 'storage' autopkgtest with a custom kernel that doesn't
  provide the scsi_debug module in the standard linux-modules deb, or
  check the autopkgtest.u.c history, for example:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20191209_150835_237a5@/log.gz

  [regression potential]

  as this modifies one of the autopkgtest --setup-commands, a regression
  would most likely cause immediate test failure due to failing to
  install the proper linux-* debs.

  For the systemd 'storage' test change, this only skips the test if the
  scsi_debug module can't be loaded (and isn't already present, i.e.
  loaded or built-in).  Any regression potential from that is low, but
  likely would involve incorrect test skips and/or missing valid
  problems due to skipping the test.

  [scope]

  systemd in all releases needs to have its 'storage' test updated

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopkgtest-cloud/+bug/1847816/+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 1847816] Re: storage autopkgtest always fails with linux-{kvm, azure, etc} kernels that don't include scsi_debug module

Hello Dan, or anyone else affected,

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

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

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

Title:
  storage autopkgtest always fails with linux-{kvm,azure,etc} kernels
  that don't include scsi_debug module

Status in autopkgtest-cloud:
  New
Status in linux-kvm package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in linux-kvm source package in Xenial:
  New
Status in systemd source package in Xenial:
  In Progress
Status in linux-kvm source package in Bionic:
  New
Status in systemd source package in Bionic:
  Fix Committed
Status in linux-kvm source package in Disco:
  New
Status in systemd source package in Disco:
  Won't Fix
Status in linux-kvm source package in Eoan:
  New
Status in systemd source package in Eoan:
  Fix Committed
Status in linux-kvm source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Released

Bug description:
  Note: this bug touches on multiple packages:
  - autopkgtest-cloud: merge request open to install 'modules-extra' package
  - systemd: update autopkgtest to skip test if scsi_debug module isn't 
available (SRU template below is for this change)
  - linux-kvm: has CONFIG_SCSI_DEBUG unset, but would be good to have 
scsi_debug module built for this kernel

  [SRU template for systemd]

  [impact]

  the 'storage' autopkgtest requires the 'scsi_debug' module, and if it
  can't load it (and it's not built-in), the test fails.  On some custom
  kernels, this module is included in the new 'linux-modules-extra-*'
  deb which isn't installed by default, so the test always fails when
  doing a reverse-dep autopkgtest using such a kernel's meta pkg.

  Additionally, some custom kernels, like linux-kvm, have SCSI_DEBUG
  disabled entirely; for those kernels, it will never be possible to
  load the scsi_debug module and the test should be skipped.

  [test case]

  run the 'storage' autopkgtest with a custom kernel that doesn't
  provide the scsi_debug module in the standard linux-modules deb, or
  check the autopkgtest.u.c history, for example:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20191209_150835_237a5@/log.gz

  [regression potential]

  as this modifies one of the autopkgtest --setup-commands, a regression
  would most likely cause immediate test failure due to failing to
  install the proper linux-* debs.

  For the systemd 'storage' test change, this only skips the test if the
  scsi_debug module can't be loaded (and isn't already present, i.e.
  loaded or built-in).  Any regression potential from that is low, but
  likely would involve incorrect test skips and/or missing valid
  problems due to skipping the test.

  [scope]

  systemd in all releases needs to have its 'storage' test updated

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopkgtest-cloud/+bug/1847816/+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 1860548] Re: systemd crashes when logging long message

Hello Ioanna, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

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

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

Title:
  systemd crashes when logging long message

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

Bug description:
  [Impact]

  Systemd crashes when logging very long messages. This regression was 
introduced with
  upstream commit d054f0a4d451 [1] due to xsprintf.
  Commits e68eedbbdc98 [2] and 574432f889ce [3] replace some uses of xsprintf 
with
  snprintf and fix it.

  [Test Case]

  # systemd-run --scope apt-get -q -y -o DPkg::Options::=--force-confold
  -o DPkg::Options::=--force-confdef --allow-unauthenticated install acl
  adduser amd64-microcode apt base-files base-passwd bash bash-
  completion bind9-host binfmt-support binutils-common binutils-x86-64
  -linux-gnu bsdmainutils bsdutils busybox-initramfs busybox-static
  bzip2 ca-certificates console-setup console-setup-linux coreutils cpio
  cpp cpp-7 crda cron curl dash dbus dctrl-tools debconf debconf-i18n
  debianutils dictionaries-common diffutils dirmngr distro-info-data
  dmeventd dmsetup dnsmasq-base dnsutils dpkg e2fslibs e2fsprogs ed
  eject fakeroot fdisk file findutils friendly-recovery gawk gcc-7-base
  gcc-8-base gettext-base gir1.2-glib-2.0 gnupg gnupg-l10n gnupg-utils
  gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv grep
  groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname
  info init init-system-helpers initramfs-tools initramfs-tools-bin
  initramfs-tools-core install-info intel-microcode iproute2 iptables
  iputils-ping iputils-tracepath irqbalance isc-dhcp-client isc-dhcp-
  common iso-codes iw keyboard-configuration keyutils klibc-utils kmod
  krb5-locales krb5-user language-pack-en language-pack-en-base
  language-pack-gnome-en language-pack-gnome-en-base less
  libaccountsservice0 libacl1 libapparmor1 libargon2-0 libasan4
  libasn1-8-heimdal libassuan0 libatm1 libatomic1 libattr1 libaudit-
  common libaudit1  libbinutils libblkid1 libbsd0 libbz2-1.0 libc-bin
  libc-dev-bin libc6 libc6-dev libcap-ng0 libcap2 libcap2-bin libcc1-0
  libcilkrts5 libcom-err2 libcryptsetup12 libcurl3-gnutls libcurl4
  libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper-event1.02.1
  libdevmapper1.02.1 libdpkg-perl libdrm-common libdrm2 libdumbnet1
  libedit2 libelf1 libestr0 libevent-2.1-6 libexpat1 libexpat1-dev
  libext2fs2 libfakeroot libfastjson4 libfdisk1 libffi6 libfreetype6
  libfribidi0 libfuse2 libgc1c2 libgcc-7-dev libgcc1 libgcrypt20
  libgdbm-compat4 libgeoip1 libgirepository-1.0-1 libglib2.0-0
  libglib2.0-data libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2
  libgssapi-krb5-2 libgssapi3-heimdal libgssrpc4 libhcrypto4-heimdal
  libheimbase1-heimdal libheimntlm0-heimdal libhogweed4
  libhx509-5-heimdal libitm1 libjs-jquery libjs-sphinxdoc libjs-
  underscore libk5crypto3 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-9
  libkeyutils1 libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0
  libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0
  liblz4-1 liblzma5 libmagic-mgc libmagic1 libmnl0 libmount1 libmpc3
  libmpdec2 libmpfr6 libmpx2 libmspack0 libncurses5 libncursesw5
  libnetfilter-conntrack3 libnettle6 libnewt0.52 libnfnetlink0
  libnfsidmap2 libnghttp2-14  libnl-3-200 libnl-genl-3-200 libnorm1
  libnpth0 libnss-systemd

[Touch-packages] [Bug 1845909] Re: [SRU] IPv6 link local address is assigned even when LinkLocalAddressing=no|ipv4

Hello Zhang, or anyone else affected,

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

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

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

Title:
  [SRU] IPv6 link local address is assigned even when
  LinkLocalAddressing=no|ipv4

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

Bug description:
  [impact]

  in some situations when a networkd interface is configured with
  LinkLocalAddressing=no, networkd still assigns a link-local address to
  it

  [test case]

  see comment 3.

  note I was only able to reproduce this at boot time; if the vlan
  interface is removed (i.e. 'sudo ip l del pppoe') and then networkd
  restarted, the pppoe interface is created and does not have a link-
  local address.  This is due to this bug being triggered by timing, as
  a vlan interface is raised by the kernel when its parent interface is
  raised, in this case by networkd itself.

  [regression potential]

  this changes how ipv6ll addresses are managed and dropped, as well as
  changing when foreign addresses are dropped (later in config process).
  Any regressions would likely be around incorrectly setting ipv6ll
  addresses, or complete failure to complete interface configuration.

  [scope]

  this is fixed upstream by:
  https://github.com/systemd/systemd/pull/13927

  and also requires the upstream PR referenced in the original description:
  upstream patch: https://github.com/systemd/systemd/pull/13565

  this is required for focal (uploaded already), eoan, and bionic.  It
  may be required for xenial.

  [other info]

  Note, the original description below is incorrect, the issue/patch it
  references is not enough to fix this issue.

  original description:

  --

  upstream issue: https://github.com/systemd/systemd/issues/12886
  upstream patch: https://github.com/systemd/systemd/pull/13565

  The upstream fix will be available in systemd 244.
  Backport please. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1845909/+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 1671951] Re: networkd should allow configuring IPV6 MTU

Hello Ryan, or anyone else affected,

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

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

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

Title:
  networkd should allow configuring IPV6 MTU

Status in systemd:
  Unknown
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix
Status in cloud-init source package in Eoan:
  New
Status in netplan.io source package in Eoan:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in cloud-init source package in Focal:
  Confirmed
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu

[Touch-packages] [Bug 1833193] Re: systemd-networkd fails to apply static IPv4 when the static IP is the same as previously configured by DHCP

Hello Lars, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

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

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

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

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

Bug description:
  [impact]

  if networkd is configured with a static address, and the address has
  already been assigned by dhcp (so that it has finite valid_lft),
  networkd will not change the valid_lft to 'forever' during startup,
  which leaves networkd thinking the address is static (meaning,
  networkd will not attempt to renew the dhcp lease) but the address
  valid_lft counting down.

  Once the valid_lft expires, the kernel will remove the address from
  the interface, breaking the system's networking.

  [test case]

  configure a system with networkd similar to:

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  restart systemd-networkd, and ens3 should get a DHCP address, e.g.:

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2295sec preferred_lft 2295sec

  then, edit the networkd config to use a static address, e.g.:

  [Match]
  Name=ens3

  [Network]
  Address=192.168.122.147/24
  Gateway=192.168.122.1
  DNS=192.168.122.1
  Domains=vm

  make sure to use the exact same address that was provided by dhcp.

  Then, without rebooting, just restart networkd and check the address
  lft:

  $ sudo systemctl restart systemd-networkd

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2992sec preferred_lft 2992sec

  the address should have 'forever' valid_lft, but it doesn't.

  [regression potential]

  this changes the details of how networkd updates static addresses
  during startup, so any regression would occur at networkd startup when
  using static addresses.

  [scope]

  this is needed only in Bionic and Disco.

  this is fixed by upstream:
  https://github.com/systemd/systemd/pull/11460/commits
  specifically commit a47a6daebe0af26c07d8d423225eb4add110793c
  which is included in Eoan and later.

  In Xenial using networkd, testing shows this problem does not occur,
  because this older version of networkd removes the 'foreign' dhcp
  address before re-assigning it as a static address.

  [other info]

  original 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

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

Hello Zhang, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

Title:
  [SRU] IPv6 link local address is assigned even when
  LinkLocalAddressing=no|ipv4

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

Bug description:
  [impact]

  in some situations when a networkd interface is configured with
  LinkLocalAddressing=no, networkd still assigns a link-local address to
  it

  [test case]

  see comment 3.

  note I was only able to reproduce this at boot time; if the vlan
  interface is removed (i.e. 'sudo ip l del pppoe') and then networkd
  restarted, the pppoe interface is created and does not have a link-
  local address.  This is due to this bug being triggered by timing, as
  a vlan interface is raised by the kernel when its parent interface is
  raised, in this case by networkd itself.

  [regression potential]

  this changes how ipv6ll addresses are managed and dropped, as well as
  changing when foreign addresses are dropped (later in config process).
  Any regressions would likely be around incorrectly setting ipv6ll
  addresses, or complete failure to complete interface configuration.

  [scope]

  this is fixed upstream by:
  https://github.com/systemd/systemd/pull/13927

  and also requires the upstream PR referenced in the original description:
  upstream patch: https://github.com/systemd/systemd/pull/13565

  this is required for focal (uploaded already), eoan, and bionic.  It
  may be required for xenial.

  [other info]

  Note, the original description below is incorrect, the issue/patch it
  references is not enough to fix this issue.

  original description:

  --

  upstream issue: https://github.com/systemd/systemd/issues/12886
  upstream patch: https://github.com/systemd/systemd/pull/13565

  The upstream fix will be available in systemd 244.
  Backport please. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1845909/+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 1671951] Please test proposed package

Hello Ryan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

Title:
  networkd should allow configuring IPV6 MTU

Status in systemd:
  Unknown
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix
Status in cloud-init source package in Eoan:
  New
Status in netplan.io source package in Eoan:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed
Status in cloud-init source package in Focal:
  Confirmed
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.

[Touch-packages] [Bug 1836695] Re: systemd fails to setup static routes at boot when using DHCP

Hello Alexey, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/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:
  Fix Committed
Status in systemd source package in Disco:
  Won't Fix
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 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

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1836695/+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 1849261] Re: Update systemd for ubuntu 18.04 with fix for interaction between OnFailure= and Restart=

Hello bugproxy, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

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

Title:
  Update systemd for ubuntu 18.04 with fix for interaction between
  OnFailure= and Restart=

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Won't Fix
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  services configured with both OnFailure= and Restart= directives will
  both start the failure service(s), as well as restarting itself.  The
  documentation (and later versions) indicate that OnFailure= services
  will only be started once the service actually does stop (due to
  failure) once its restart limit has been exceeded.

  [test case]

  create service files as:

  ubuntu@lp1849261-b:/etc/systemd/system$ cat test.service
  [Unit]
  OnFailure=failure.service

  [Service]
  ExecStart=/bin/sh -c '/bin/sleep 10; /bin/false'
  Restart=always

  ubuntu@lp1849261-b:/etc/systemd/system$ cat failure.service
  [Service]
  ExecStart=/bin/true

  perform daemon-reload, and then start test service:

  ubuntu@lp1849261-b:/etc/systemd/system$ sudo systemctl daemon-reload
  ubuntu@lp1849261-b:/etc/systemd/system$ sudo systemctl start test

  wait for a while for the test service to exit - at least 10 seconds,
  as that's what we configured in the service, although I have waited
  longer in this example.  Then check the journal for both test and
  failure services:

  ubuntu@lp1849261-b:/etc/systemd/system$ journalctl -b -u test
  -- Logs begin at Fri 2019-12-13 00:52:50 UTC, end at Fri 2019-12-13 01:18:34 
UTC. --
  Dec 13 01:17:43 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 1.
  Dec 13 01:17:53 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:17:53 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:04 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:04 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 2.
  Dec 13 01:18:04 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:18:04 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 3.

[Touch-packages] [Bug 1859862] Re: networkd doesn't re-enable ipv6 unless mtu is set

Hello Dan, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.39 in a few
hours, and then in the -proposed repository.

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

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

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

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

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

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

Title:
  networkd doesn't re-enable ipv6 unless mtu is set

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

Bug description:
  [impact]

  if the 'disable_ipv6' procfs setting is disabled, and networkd is
  configured with ipv6 networking, networkd will not enable ipv6 via the
  procfs setting unless the interface mtu is also set to a custom value,
  that doesn't match the current interface mtu.

  [test case]

  create networkd config similar to:

  [Match]
  MACAddress=52:54:00:0c:09:77
  Name=ens3

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=2001:db8::100/64

  manually disable ipv6 for the interface:

  ubuntu@lp1859862-b:~$ echo 1 | sudo tee 
/proc/sys/net/ipv6/conf/ens3/disable_ipv6
  1

  the interface should not contain any ipv6 addresses:

  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$

  restart networkd; it should enable ipv6 as ipv6 addresses are
  configured, but it does not:

  ubuntu@lp1859862-b:~$ sudo systemctl restart systemd-networkd
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$

  Note that with the mtu set, it will successfully re-enable ipv6;
  modify the networkd config to set the mtu by adding this:

  [Link]
  MTUBytes=1400

  verify ipv6 is still disabled and has no addresses, then restart and
  check again:

  ubuntu@lp1859862-b:~$ cat /proc/sys/net/ipv6/conf/ens3/disable_ipv6
  1
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$ sudo systemctl restart systemd-networkd
  ubuntu@lp1859862-b:~$ cat /proc/sys/net/ipv6/conf/ens3/disable_ipv6
  0
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  2: ens3:  mtu 1400 state UP qlen 1000
  inet6 2001:db8::100/64 scope global
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe0c:977/64 scope link
     valid_lft forever preferred_lft forever

  That should be the behavior even if MTUBytes is not set.

  [regression potential]

  as this adjusts when the procfs 'disable_ipv6' setting is changed, the
  regression potential could cause failure to properly set/create ipv6
  addresses, or to leave ipv6 disabled entirely.

  [scope]

  This is needed in Bionic and Eoan.

  the commit to fix this is 482efedc081b0c4bf2e77a3dee6b979d9c9a5765
  which is included starting in v243, so it is included already in
  Focal.

  Ignoring Disco, as it is EOL next week.

  This problem was introduced by commit
  44b598a1c9d11c23420a5ef45ff11bcb0ed195eb, which was included starting
  in v239, but also backported to Bionic in bug 1850704.

  [other info]

  for Eoan, this bug has always existed since release, but for Bionic,
  this is a regression introduced by bug 1850704.  However, manual
  disabling of ipv6 is very unusual, so this bug is unlikely to have an
  impact to many systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1859862/+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 1861440] Re: [upstream regression] wget does not honor dot-prefixed domains in no_proxy env variable

2020-02-06 Thread Shawn K. O'Shea

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

** Also affects: wget (CentOS) via
   https://bugzilla.redhat.com/show_bug.cgi?id=1763702
   Importance: Unknown
   Status: Unknown

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

Title:
  [upstream regression] wget does not honor dot-prefixed domains in
  no_proxy env variable

Status in wget package in Ubuntu:
  New
Status in wget package in CentOS:
  Unknown

Bug description:
  Traditionally (AFAIK for at least the last decade), tools that support
  the no_proxy environment variable support specifying an entire
  subdomain by prefixing it with a "dot". For example, to exclude any
  website under example.com from using the proxy, you would set no_proxy
  to .example.com (export no_proxy=.example.com).

  A regression in wget 1.19 changed this behavior to expect non-prefixed
  domains (example.com vs .example.com). This regression was ultimately
  fixed and released with the 1.20 release of wget. bionic includes the
  regressed behavior version of wget.

  The regression was apparently introduced in wget 1.19.3. This bug
  should not effect other Ubuntu releases (xenial contains 1.17.1 and
  both disco and eoan contain 1.20.x versions that have the upstream
  fix).

  For more details, see references below and my additional comments on
  the RHEL8 bug filed for this issue (RH bug 1763702 linked below).

  What happens:
  no_proxy=.example.com in bionic sends requests to the proxy server for URLs 
like http://www.example.com/ despite requesting proxy exception via no_proxy.

  What should happen:
  Request should bypass the proxy and go directly to the web server. (works in 
xenial, disco and eoan as expected).

  System/software information:
  $ lsb_release -rd
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04
  $ apt-cache policy wget
  wget:
Installed: 1.19.4-1ubuntu2.2
Candidate: 1.19.4-1ubuntu2.2
Version table:
   *** 1.19.4-1ubuntu2.2 500
  500 http://div6mirrors.llan.ll.mit.edu:80/ubuntu bionic-updates/main 
amd64 Packages
  500 http://div6mirrors.llan.ll.mit.edu:80/ubuntu bionic-security/main 
amd64 Packages
  100 /var/lib/dpkg/status
   1.19.4-1ubuntu2 500
  500 http://div6mirrors.llan.ll.mit.edu:80/ubuntu bionic/main amd64 
Packages

  References:
  * Upstream wget bug report: 
GNU Wget - Bugs: bug #53622 wget no_proxy leading dot on (sub)domains not 
working contradicting man page
https://savannah.gnu.org/bugs/?53622

  * Upstream commit reference that introduces the regression

http://git.savannah.gnu.org/cgit/wget.git/commit/?id=fd85ac9cc623847e9d94d9f9241ab34e2c146cbf

  * Upstream commit reference that introduces the fix

http://git.savannah.gnu.org/cgit/wget.git/commit/?id=fd85ac9cc623847e9d94d9f9241ab34e2c146cbf

  * Expected behavior of no_proxy as documented in the GNU Emacs manual:
  https://www.gnu.org/software/emacs/manual/html_node/url/Proxies.html

  * Red Hat Bugzilla entry for this issue (Reported against RHEL8.1)
Bug 1763702 - wget is ignoring no_proxy environment variable 
https://bugzilla.redhat.com/show_bug.cgi?id=1763702

  * Red Hat Bugzilla entry tracking the (now released) errata package for 
RHEL8.1
Bug 1772821 - wget is ignoring no_proxy environment variable [rhel-8.1.0.z] 
https://bugzilla.redhat.com/show_bug.cgi?id=1772821

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1861440/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-06 Thread Gunnar Hjalmarsson

Idea from https://askubuntu.com/q/442055

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  New

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1846232] Please test proposed package

Hello Dan, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.7
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-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

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

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

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

Title:
  networkd pads interface MTU by 4 bytes for vlan even when told not to

Status in curtin:
  Invalid
Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Eoan:
  Fix Committed

Bug description:
  [impact]

  vlan interface has wrong mtu, which may cause lost packets due to
  incorrect mtu

  [test case]

  configure a system using the netplan cfg similar to comment 2.

  alternately, networkd config can be used, similar to:

  ubuntu@lp1846232-e:/run/systemd/network$ grep . *
  10-netplan-ens3.2667.netdev:[NetDev]
  10-netplan-ens3.2667.netdev:Name=ens3.2667
  10-netplan-ens3.2667.netdev:MTUBytes=1500
  10-netplan-ens3.2667.netdev:Kind=vlan
  10-netplan-ens3.2667.netdev:[VLAN]
  10-netplan-ens3.2667.netdev:Id=2667
  10-netplan-ens3.2667.network:[Match]
  10-netplan-ens3.2667.network:Name=ens3.2667
  10-netplan-ens3.2667.network:[Network]
  10-netplan-ens3.2667.network:LinkLocalAddressing=ipv6
  10-netplan-ens3.2667.network:Address=1.2.3.4/32
  10-netplan-ens3.2667.network:ConfigureWithoutCarrier=yes
  10-netplan-ens3.link:[Match]
  10-netplan-ens3.link:OriginalName=ens3
  10-netplan-ens3.link:[Link]
  10-netplan-ens3.link:WakeOnLan=off
  10-netplan-ens3.link:MTUBytes=1500
  10-netplan-ens3.network:[Match]
  10-netplan-ens3.network:Name=ens3
  10-netplan-ens3.network:[Network]
  10-netplan-ens3.network:LinkLocalAddressing=ipv6
  10-netplan-ens3.network:VLAN=ens3.2667

  The reboot and check the mtus:

  ubuntu@lp1846232-e:~$ ip l show ens3
  2: ens3:  mtu 1504 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
  link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff
  ubuntu@lp1846232-e:~$ ip l show ens3.2667
  3: ens3.2667@ens3:  mtu 1500 qdisc noqueue 
state UP mode DEFAULT group default qlen 1000
  link/ether 52:54:00:12:99:1b brd ff:ff:ff:ff:ff:ff

  The base interface should have a mtu of only 1500.

  [regression potential]

  As this corrects/adjusts the mtu of the interface, regressions would
  likely involve interface(s) being assigned incorrect mtu values, which
  then would lead to dropped packets and/or lowered network performance.

  [scope]

  this is needed only for Eoan.

  disco and earlier don't have the patch that introduces this problem,
  commit 4b151b71320bbee1549afcbad5554a40d90d63b4

  focal already has the patches that fix this, commit
  f6fcc1c2a41eae749467de58453174296b635a69 (and the commit before it)

  see comment 4 for more details

  [other info]

  original description:

  ---

  From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-
  amd64/916/console:

  ==
  FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan)
  --
  Traceback (most recent call last):
    File 
"/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py",
 line 311, in test_ip_output
  routes)
    File 
"/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py",
 line 337, in check_interface
  int(ipcfg[key]))
  AssertionError: 1500 != 1504
   >> begin captured stdout << -
  parsed ip_a dict:
  interface0:
  broadcast: 10.245.175.255
  group: default
  inet4:
  -   address: 10.245.168.16
  prefixlen: '21'
  scope: global
  valid_lft: forever
  inet6:
  -   address: fec0::d6be:d9ff:fea8:4913

[Touch-packages] [Bug 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-06 Thread Gunnar Hjalmarsson

Yeah, I tend to think that the fix should be made in lightdm. My idea is
to modify the patch, so LANGUAGE is set only if this conditional is
satisfied:

if (system ("df | grep ^/cow >/dev/null") != 0)

That way LANGUAGE should not be set in a live session AFAIU.

@Sebastien: Do you think this is a proper way to test for a live
session?

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  New

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 710412] Re: Does Not Display Graphics in PDF Files (needs to build with openjpeg)

This bug was fixed in the package poppler - 0.80.0-0ubuntu5

---
poppler (0.80.0-0ubuntu5) focal; urgency=medium

  * debian/control, debian/rules:
- enabled the libopenjpg backend now that the MIR got approved
  (lp: #710412)

 -- Sebastien Bacher   Thu, 06 Feb 2020 13:05:01
+0100

** Changed in: poppler (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  Does Not Display Graphics in PDF Files (needs to build with openjpeg)

Status in Poppler:
  Invalid
Status in poppler package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: evince

  When viewing a pdf file with the default document viewer the pages are
  slow to render and will NOT display pictures at all. While the words
  display fine, any place in the document that should contain a picture,
  is just rendered as a blank white space.

  I installed Adobe's acrobat Reader and it displays the pages faster
  and all pictures are displayed correctly as well.

  Using 
  Ubuntu 10.10
  Evince version 2.32.0-0ubuntu1.1

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: evince 2.32.0-0ubuntu1.1
  ProcVersionSignature: Ubuntu 2.6.35-25.44-generic 2.6.35.10
  Uname: Linux 2.6.35-25-generic i686
  Architecture: i386
  Date: Sun Jan 30 20:00:35 2011
  ExecutablePath: /usr/bin/evince
  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
  KernLog:
   
  ProcEnviron:
   SHELL=/bin/bash
   LANG=en_US.UTF-8
  SourcePackage: evince

To manage notifications about this bug go to:
https://bugs.launchpad.net/poppler/+bug/710412/+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 1862232] [NEW] Long hostname causes networking setup to fail

2020-02-06 Thread Daniel

Public bug reported:

1) ubuntu version
# lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04

2) package version
# apt-cache policy systemd
systemd:
  Installed: 237-3ubuntu10.31
  Candidate: 237-3ubuntu10.31
  Version table:
 *** 237-3ubuntu10.31 500
500 http://mirrors.digitalocean.com/ubuntu bionic-updates/main amd64 
Packag
es
100 /var/lib/dpkg/status
 237-3ubuntu10.29 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages 
 237-3ubuntu10 500
500 http://mirrors.digitalocean.com/ubuntu bionic/main amd64 Packages   
  


3) I expect the network to come online correctly regardless of how long the 
hostname is. This is what happens with both 14.0 and 19.0 (I tested the same 
behavior with both of them).

4) the external network interface fails to be configured and is stuck in
a (pending) state as reported by networkctl status -a

setting the hostname:

# hostnamectl set-hostname
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf

after rebooting the machine, it no longer has network access.

# journalctl
Feb 06 19:29:41 
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf systemd[1]: 
Starting Wait for Network to be Configured...
Feb 06 19:29:41 
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf 
systemd-networkd[605]: eth0: Link state is up-to-date
Feb 06 19:29:41 
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf 
systemd-networkd[605]: eth0: found matching network 
'/run/systemd/network/10-netplan-eth0.network'
Feb 06 19:29:41 
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf 
systemd-networkd[605]: sd-netlink: callback failed: Invalid argument
Feb 06 19:29:41 
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf 
systemd-networkd[605]: lo: Link state is up-to-date

# networkctl status -a:
● 1: lo
   Link File: /lib/systemd/network/99-default.link
Network File: n/a
Type: loopback
   State: carrier (unmanaged)
 Address: 127.0.0.1
  ::1

● 2: eth0
   Link File: /run/systemd/network/10-netplan-eth0.link
Network File: /run/systemd/network/10-netplan-eth0.network
Type: ether
   State: off (pending)
Path: pci-:00:03.0
  Driver: virtio_net
  Vendor: Red Hat, Inc.
   Model: Virtio network device
  HW Address: ae:4d:91:1c:e8:86
 DNS: 67.207.67.3
  67.207.67.2

and to bring up the network correctly, set the hostname to something
shorter

# hostnamectl set-hostname asdf
# systemctl restart systemd-networkd
# networkctl status -a
● 1: lo
   Link File: /lib/systemd/network/99-default.link
Network File: n/a
Type: loopback
   State: carrier (unmanaged)
 Address: 127.0.0.1
  ::1

● 2: eth0
   Link File: /run/systemd/network/10-netplan-eth0.link
Network File: /run/systemd/network/10-netplan-eth0.network
Type: ether
   State: routable (configured)
Path: pci-:00:03.0
  Driver: virtio_net
  Vendor: Red Hat, Inc.
   Model: Virtio network device
  HW Address: ae:4d:91:1c:e8:86
 Address: 10.17.0.5
  157.245.210.250
  fe80::ac4d:91ff:fe1c:e886
 Gateway: 157.245.208.1 (ICANN, IANA Department)
 DNS: 67.207.67.3
  67.207.67.2

** 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/1862232

Title:
  Long hostname causes networking setup to fail

Status in systemd package in Ubuntu:
  New

Bug description:
  1) ubuntu version
  # lsb_release -rd
  Description:Ubuntu 18.04.3 LTS
  Release:18.04

  2) package version
  # apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.31
Candidate: 237-3ubuntu10.31
Version table:
   *** 237-3ubuntu10.31 500
  500 http://mirrors.digitalocean.com/ubuntu bionic-updates/main amd64 
Packag
  es
  100 /var/lib/dpkg/status
   237-3ubuntu10.29 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages 
   237-3ubuntu10 500
  500 http://mirrors.digitalocean.com/ubuntu bionic/main amd64 Packages 


  
  3) I expect the network to come online correctly regardless of how long the 
hostname is. This is what happens with both 14.0 and 19.0 (I tested the same 
behavior with both of them).

  4) the external network interface fails to be configured and is stuck
  in a (pending) state as reported by networkctl status -a

  setting the hostname:

  # hostnamectl set-hostname
  asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf

  after rebooting the machine, it no longer has network

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-06 Thread Pat Viafore

Adding in a passing version of journalctl

** Attachment added: "passing_journalctl_output.txt"
   
https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5326024/+files/passing_journalctl_output.txt

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user

2020-02-06 Thread Bryce Harrington

So, the trivial fix is to simply append 203e9b92fe3623aeba277ee44297f7dd
to openssh-server.ucf-md5sum, as Marc had suggested above.

I can proceed with that as the fix.

---

But this suggests a few direct questions/thoughts:

0.  Does the installer use the openssh-server.ucf-md5sum from the new
package, or the previously installed one?  If the latter, then the
md5sum will need added via SRU.

1.  Where in the process did the md5sum get out of sync?  I'm not
spotting conf changes from the CVE patches by our security team, so
looks like this got to us via debian?

2.  Our merge review processes need to account for conf file changes
with ucf packages.  Although, in this case openssh presumably got sync'd
so Ubuntu-side process changes would not have caught it.

3.  There have been other reports of similar misbehavior with wrongly
detected conf file changes (Robie's LP #1747464 mentioned above may be
one, there's likely others).  Is ucf also being used in these cases, and
are those problems likewise caused by missing md5sums in their packages?

4.  Is this failure mode something that can be caught in autopkgtests?
If so, then per-package checks seem warranted to prevent this in the
future.

5.  Even better than #3 would be a distro-wide CI check for all packages
using ucf, to ensure all distro-default installed conf files (from all
pockets) have their conf file md5sums registered.


In addition, some broader scoped / philosophical / "dumb" questions:

1.  Are md5sums the best way to identify config file changes?  E.g. if
the change is just a timestamp and commented out line (such as in this
case) that shouldn't count as a "change".  What about like filtering out
commented lines, and checksumming that?

2.  Why are commented out lines included in distro-provided conf files?
Is it just for documentation, in which case those would be better kept
elsewhere and just referenced?  (Yes, this is more a debian/upstream
policy question which we probably don't have say on...)

3.  Is upgrade the right time to be prompting users about config file
changes, even if they have legitimate local config changes?  With cloud
instances, unattended-upgrades, etc. it's not so safe to assume a human
is babysitting the dist-upgrade, and breakages during dist-upgrades can
be pretty catastrophic for users.  It's also a frequently seen pattern
in our own bug triaging workloads.  Are there any other ways to solve
this need?

(Yes, much of the above is better fodder for blogs, and no need to
discuss it in depth here...)

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

Title:
  upgrade from fresh bionic to focal needlessly prompts user

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts
  for how to handle a change to /etc/ssh/sshd_config

  To reproduce the issue:

  lxc launch ubuntu:18.04 u18
  lxc exec u18 -- bash
  # within container
  do-release-upgrade -d
  # select restart services when prompted

  Eventually you'll be prompted to accept changes to
  /etc/ssh/sshd_config or not because of "local changes".

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.1p1-5
  ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18
  Uname: Linux 4.15.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  Date: Fri Jan 31 03:37:55 2020
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: openssh
  UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472/+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 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user

2020-02-06 Thread Bryce Harrington

Marc's comment #3 seems plausible:

stirling:~/ubuntu/Openssh$  lxc exec u18 -- bash
root@u18:~# md5sum /etc/ssh/sshd_config 
203e9b92fe3623aeba277ee44297f7dd  /etc/ssh/sshd_config
root@u18:~# grep -c 203e9b92fe3623aeba277ee44297f7dd 
/usr/share/openssh/sshd_config.md5sum
0
root@u18:~# 

Looking at sshd_config on a fresh installed 18.04 lxc and a fresh 20.04,
the sshd_config files do indeed differ by exactly the diff shown during
upgrade (and provided in comment #2).

The md5sum checking was introduced in Debian on Dec 2016 with openssh
(1:7.4p1-1)

  * Start handling /etc/ssh/sshd_config using ucf.  The immediate motivation
for this is to deal with deprecations of options related to protocol 1,
but something like this has been needed for a long time (closes:
#419574, #848089):
- sshd_config is now a slightly-patched version of upstream's, and only
  contains non-default settings (closes: #147201).
- I've included as many historical md5sums of default versions of
  sshd_config as I could reconstruct from version control, but I'm sure
  I've missed some.
- Explicitly synchronise the debconf database with the current
  configuration file state in openssh-server.config, to ensure that the
  PermitRootLogin setting is properly preserved.
- UsePrivilegeSeparation now defaults to the stronger "sandbox" rather
  than "yes", per upstream.

It's implemented in openssh-server.postinst:

...
... sed statements to customize $new_config from upstream for debian
...
mkdir -p /etc/ssh
ucf --three-way --debconf-ok \
--sum-file /usr/share/openssh/sshd_config.md5sum \
"$new_config" /etc/ssh/sshd_config
ucfr openssh-server /etc/ssh/sshd_config

AFAICT the /usr/share/openssh/sshd_config.md5sum is identical on freshly
lxc'd 18.04 and 20.04.

Running the ucf command on a focal lxc container with the 18.04 and
20.04 sshd_config files captured from fresh lxc installs reproduces the
same debconf prompt about the changed config, and then issues this
output:

stirling:~/ubuntu/Openssh/fix-apt-misprompt$ sudo ucf --no-action --three-way 
--debconf-ok --sum-file /usr/share/openssh/sshd_config.md5sum 
./sshd_config.20.04 ./sshd_config.18.04 
[sudo] password for bryce: 
Replacing config file 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 with new version
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04.ucf-old
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04
cp -pf /var/lib/ucf/hashfile.6 /var/lib/ucf/hashfile.7
cp -pf /var/lib/ucf/hashfile.5 /var/lib/ucf/hashfile.6
cp -pf /var/lib/ucf/hashfile.4 /var/lib/ucf/hashfile.5
cp -pf /var/lib/ucf/hashfile.3 /var/lib/ucf/hashfile.4
cp -pf /var/lib/ucf/hashfile.2 /var/lib/ucf/hashfile.3
cp -pf /var/lib/ucf/hashfile.1 /var/lib/ucf/hashfile.2
cp -pf /var/lib/ucf/hashfile.0 /var/lib/ucf/hashfile.1
cp -pf /var/lib/ucf/hashfile /var/lib/ucf/hashfile.0
(egrep -v 
"[[:space:]]\/home\/bryce\/ubuntu\/Openssh\/fix\-apt\-misprompt\/sshd_config\.18\.04$"
 "/var/lib/ucf/hashfile"
 md5sum "/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04" | sed 
"s|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04|";
 
) | sort > "/var/lib/ucf/hashfile"
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 
/var/lib/ucf/cache/:home:bryce:ubuntu:Openssh:fix-apt-misprompt:sshd_config.18.04


If I append the bionic sshd_config md5sum to the list and then check against 
that, no prompt is displayed, with the following output:

$ (cat /usr/share/openssh/sshd_config.md5sum; sudo md5sum sshd_config.18.04  | 
cut -d' ' -f1) > /tmp/sshd_config.md5sum
$ sudo ucf --no-action --three-way --debconf-ok --sum-file 
/tmp/sshd_config.md5sum ./sshd_config.20.04 ./sshd_config.18.04 
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04
cp -pf /var/lib/ucf/hashfile.6 /var/lib/ucf/hashfile.7
cp -pf /var/lib/ucf/hashfile.5 /var/lib/ucf/hashfile.6
cp -pf /var/lib/ucf/hashfile.4 /var/lib/ucf/hashfile.5
cp -pf /var/lib/ucf/hashfile.3 /var/lib/ucf/hashfile.4
cp -pf /var/lib/ucf/hashfile.2 /var/lib/ucf/hashfile.3
cp -pf /var/lib/ucf/hashfile.1 /var/lib/ucf/hashfile.2
cp -pf /var/lib/ucf/hashfile.0 /var/lib/ucf/hashfile.1
cp -pf /var/lib/ucf/hashfile /var/lib/ucf/hashfile.0
(egrep -v 
"[[:space:]]\/home\/bryce\/ubuntu\/Openssh\/fix\-apt\-misprompt\/sshd_config\.18\.04$"
 "/var/lib/ucf/hashfile"
 md5sum "/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04" | sed 
"s|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04|";
 
) | sort > "/var/lib/ucf/hashfile"
cp -pf

[Touch-packages] [Bug 1862225] [NEW] the laptop freeze

2020-02-06 Thread Betros Abraha

Public bug reported:

the laptop freeze

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.3.0-28.30~18.04.1-generic 5.3.13
Uname: Linux 5.3.0-28-generic x86_64
.tmp.unity_support_test.0:
 
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
Date: Thu Feb  6 10:50:10 2020
DistUpgraded: 2020-01-15 21:02:05,550 DEBUG icon theme changed, re-reading
DistroCodename: bionic
DistroVariant: ubuntu
DkmsStatus: nvidia, 390.116, 5.3.0-28-generic, x86_64: installed
GraphicsCard:
 Intel Corporation Device [8086:3ea0] (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:2286]
InstallationDate: Installed on 2020-01-16 (21 days ago)
InstallationMedia: Ubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 (20190227)
MachineType: LENOVO 20Q0002EUS
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-28-generic 
root=UUID=125967d5-379e-4de9-aa68-c6208d80892a ro quiet splash vt.handoff=1
SourcePackage: xorg
UpgradeStatus: Upgraded to bionic on 2020-01-16 (21 days ago)
dmi.bios.date: 01/03/2020
dmi.bios.vendor: LENOVO
dmi.bios.version: N2JET84W (1.62 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20Q0002EUS
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: 
dmi:bvnLENOVO:bvrN2JET84W(1.62):bd01/03/2020:svnLENOVO:pn20Q0002EUS:pvrThinkPadX390:rvnLENOVO:rn20Q0002EUS:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad X390
dmi.product.name: 20Q0002EUS
dmi.product.sku: LENOVO_MT_20Q0_BU_Think_FM_ThinkPad X390
dmi.product.version: ThinkPad X390
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2
version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.2
version.xserver-xorg-core: xserver-xorg-core N/A
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A
xserver.bootTime: Wed Jan 15 20:25:03 2020
xserver.configfile: default
xserver.errors:
 
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.19.6-1ubuntu4.1~16.04.2
xserver.video_driver: modeset

** 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/1862225

Title:
  the laptop freeze

Status in xorg package in Ubuntu:
  New

Bug description:
  the laptop freeze

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.3.0-28.30~18.04.1-generic 5.3.13
  Uname: Linux 5.3.0-28-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Thu Feb  6 10:50:10 2020
  DistUpgraded: 2020-01-15 21:02:05,550 DEBUG icon theme changed, re-reading
  DistroCodename: bionic
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 390.116, 5.3.0-28-generic, x86_64: installed
  GraphicsCard:
   Intel Corporation Device [8086:3ea0] (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device [17aa:2286]
  InstallationDate: Installed on 2020-01-16 (21 days ago)
  InstallationMedia: Ubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 
(20190227)
  MachineType: LENOVO 20Q0002EUS
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-28-generic 
root=UUID=125967d5-379e-4de9-aa68-c6208d80892a ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2020-01-16 (21 days ago)
  dmi.bios.date: 01/03/2020
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N2JET84W (1.62 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20Q0002EUS
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN2JET84W(1.62):bd01/03/2020:svnLENOVO:pn20Q0002EUS:pvrThinkPadX390:rvnLENOVO:rn20Q0002EUS:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad X390
  dmi.product.name: 20Q0002EUS
  dmi.product.sku: LENOVO_MT_20Q0_BU_Think_FM_ThinkPad X390
  dmi.product.version: ThinkPad X390
  dmi.sys.vendor: LENOVO
  version.compiz: compiz

[Touch-packages] [Bug 1862218] Re: slow printing canon 18.04

2020-02-06 Thread Andris

CUPS+Gutenprint v5.2.13 - printing gets slow at first page (DOCX)
Canon MP490 series Ver.3.90 - DOCX prints fine, printings gets slow at 3rd PDF 
page

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

Title:
  slow printing canon 18.04

Status in cups package in Ubuntu:
  New

Bug description:
  Canon MP490 printer prints really slow
  Prints about 70% page at normal speed and then prints 1 line every ~20 
seconds. (Printing head makes one cycle). Even cancel button on printer takes 
~20 seconds. If i disconnect USB cable it cancels at normal speed. If i 
disconnect USB cable while printing printer instantly rolls out unfinished page.

  No such problem on Zorin OS Lite (based on Ubuntu 18.04), Windows 7.
  My other samsung printer doesn't have this problem using the same USB cable 
on same Ubuntu 18.04 installation. Didn't have this bug on 16.04.
  Using CUPS+Gutenprint v5.2.13 or Canon MP490 series Ver.3.90

  Printing on linux with this canon printer was always slow. Default
  speed before bug was 1 page per minute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1862218/+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 1862216] Re: Unclear AppStream message in `update` output

2020-02-06 Thread Paul White

*** This bug is a duplicate of bug 1861631 ***
https://bugs.launchpad.net/bugs/1861631

** This bug has been marked a duplicate of bug 1861631
   "The AppStream system cache was updated, but some components were ignored. 
Refer to the verbose log for more information."

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

Title:
  Unclear AppStream message in `update` output

Status in apt package in Ubuntu:
  New

Bug description:
  When I run `apt update`, I see an AppStream message in the output:

  $ sudo apt update
  
  Fetched 42.5 MB in 15s (2,842 kB/s)   


  The AppStream system cache was updated, but some components were ignored. 
Refer to the verbose log for more information.
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  23 packages can be upgraded. Run 'apt list --upgradable' to see them.

  Even as an Ubuntu developer, I don't know what that means, so I would
  imagine most of our users won't either.  What effect will this have on
  me?  Is it something I should worry about?  Should I be looking at the
  verbose log whenever I see this message?  Where is the verbose log?

  I think this message could serve to see some improvement, to make it
  clearer to users what has happened and what their expected actions
  are.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apt 1.9.8
  ProcVersionSignature: Ubuntu 5.4.0-13.16-generic 5.4.16
  Uname: Linux 5.4.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CurrentDesktop: i3
  Date: Thu Feb  6 12:28:19 2020
  InstallationDate: Installed on 2019-05-07 (275 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: apt
  UpgradeStatus: Upgraded to focal on 2019-11-15 (82 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1862216/+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 1862218] Re: slow printing canon 18.04

2020-02-06 Thread Paul White

** Package changed: ubuntu => cups (Ubuntu)

** Tags added: bionic

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

Title:
  slow printing canon 18.04

Status in cups package in Ubuntu:
  New

Bug description:
  Canon MP490 printer prints really slow
  Prints about 70% page at normal speed and then prints 1 line every ~20 
seconds. (Printing head makes one cycle). Even cancel button on printer takes 
~20 seconds. If i disconnect USB cable it cancels at normal speed. If i 
disconnect USB cable while printing printer instantly rolls out unfinished page.

  No such problem on Zorin OS Lite (based on Ubuntu 18.04), Windows 7.
  My other samsung printer doesn't have this problem using the same USB cable 
on same Ubuntu 18.04 installation. Didn't have this bug on 16.04.
  Using CUPS+Gutenprint v5.2.13 or Canon MP490 series Ver.3.90

  Printing on linux with this canon printer was always slow. Default
  speed before bug was 1 page per minute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1862218/+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 1861446] Re: on focal 'ubuntu-bug linux' doesn't automatically collect kernel artifacts

2020-02-06 Thread Brian Murray

As xnox suggested this morning the issue at hand is a missing symlink.
After adding one:

sudo ln -s /usr/share/apport/package-hooks/source_linux.py
/usr/share/apport/package-hooks/source_linux-signed-5.4.py

apport gathered the correct information.

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

Title:
  on focal 'ubuntu-bug linux' doesn't automatically collect kernel
  artifacts

Status in apport package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in apport source package in Focal:
  New
Status in linux source package in Focal:
  Confirmed

Bug description:
  Hello, on focal I ran 'ubuntu-bug linux' to report a kernel issue. The
  issue was filed against linux-signed-5.4 (Ubuntu) rather than linux
  (Ubuntu), and none of the logs usually included with kernel bug
  reports were included.

  After the bug was changed from linux-signed-5.4 to linux, I was
  prompted to run apport-collect by the kernel team's triagebot and that
  worked successfully:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861359/+activity

  My guess is that apport needs to be updated to understand a change in
  kernel packaging.

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apport 2.20.11-0ubuntu16
  ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
  Uname: Linux 5.4.0-12-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportLog:
   
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CrashReports:
   640:1000:1000:40192:2020-01-30 03:32:41.717296496 +:2020-01-30 
03:32:41.717296496 +:/var/crash/_usr_bin_apport-bug.1000.crash
   600:0:0:467987:2020-01-24 20:40:35.855434497 +:2020-01-24 
20:40:35.819434494 +:/var/crash/zfsutils-linux.0.crash
   640:0:0:386063:2020-01-24 20:42:09.391725398 +:2020-01-24 
20:42:08.887728256 +:/var/crash/_usr_sbin_zfs.0.crash
  Date: Thu Jan 30 18:44:47 2020
  PackageArchitecture: all
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: Upgraded to focal on 2020-01-24 (5 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1861446/+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 1862218] [NEW] slow printing canon 18.04

You have been subscribed to a public bug:

Canon MP490 printer prints really slow
Prints about 70% page at normal speed and then prints 1 line every ~20 seconds. 
(Printing head makes one cycle). Even cancel button on printer takes ~20 
seconds. If i disconnect USB cable it cancels at normal speed. If i disconnect 
USB cable while printing printer instantly rolls out unfinished page.

No such problem on Zorin OS Lite (based on Ubuntu 18.04), Windows 7.
My other samsung printer doesn't have this problem using the same USB cable on 
same Ubuntu 18.04 installation. Didn't have this bug on 16.04.
Using CUPS+Gutenprint v5.2.13 or Canon MP490 series Ver.3.90

Printing on linux with this canon printer was always slow. Default speed
before bug was 1 page per minute.

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


** Tags: canon printer slow
-- 
slow printing canon 18.04
https://bugs.launchpad.net/bugs/1862218
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to cups in Ubuntu.

-- 
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 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user

2020-02-06 Thread Robie Basak

Is this related to bug 1747464 perhaps?

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

Title:
  upgrade from fresh bionic to focal needlessly prompts user

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts
  for how to handle a change to /etc/ssh/sshd_config

  To reproduce the issue:

  lxc launch ubuntu:18.04 u18
  lxc exec u18 -- bash
  # within container
  do-release-upgrade -d
  # select restart services when prompted

  Eventually you'll be prompted to accept changes to
  /etc/ssh/sshd_config or not because of "local changes".

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.1p1-5
  ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18
  Uname: Linux 4.15.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  Date: Fri Jan 31 03:37:55 2020
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: openssh
  UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472/+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 1607845] Re: List of versioned kernels is not right for Ubuntu

This bug was fixed in the package apt - 1.9.9

---
apt (1.9.9) experimental; urgency=medium

  * Widen regular expressions for versioned kernel packages (LP: #1607845)
  * Implement short patterns (patterns starting with ~)

 -- Julian Andres Klode   Tue, 04 Feb 2020 17:42:21
+0100

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

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

Title:
  List of versioned kernels is not right for Ubuntu

Status in apt package in Ubuntu:
  Fix Released
Status in unattended-upgrades package in Ubuntu:
  New

Bug description:
  The following command outputs the list:
  $ apt-config dump --no-empty --format '%v%n' 'APT::VersionedKernelPackages'
  linux-image
  linux-headers
  linux-image-extra
  linux-signed-image
  kfreebsd-image
  kfreebsd-headers
  gnumach-image
  .*-modules
  .*-kernel
  linux-backports-modules-.*
  linux-tools

  but the list does not 'contain linux-.*-tools' and 'linux-goldfish-
  headers', which are versioned kernel packages as well, if I have
  understood correctly.

  On the other hand are these values appropriate for Ubuntu?
  kfreebsd-image
  kfreebsd-headers
  gnumach-image
  .*-modules
  .*-kernel

  Same thing for Ubuntu 14.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apt 1.2.12~ubuntu16.04.1
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  Uname: Linux 4.4.0-31-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Fri Jul 29 18:55:50 2016
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-11-21 (250 days ago)
  InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
  SourcePackage: apt
  UpgradeStatus: Upgraded to xenial on 2016-06-24 (35 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1607845/+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 1861451] Re: apport's cloud-init-specific handling tracebacks on minimal cloud images

2020-02-06 Thread Brian Murray

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

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

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

Title:
  apport's cloud-init-specific handling tracebacks on minimal cloud
  images

Status in apport package in Ubuntu:
  New
Status in apport source package in Focal:
  New

Bug description:
  Steps to reproduce:

  1) Install multipass.
  2) `multipass launch 
http://cloud-images.ubuntu.com/minimal/daily/bionic/current/bionic-minimal-cloudimg-amd64.img
 -n reproducer`
  3) `multipass shell reproducer`
  4) `ubuntu-bug cloud-init`

  Expected behaviour:

  Usual bug reporting flow (though, currently, I would really expect to
  see just the issue reported in bug 1861450).

  Actual behaviour:

  ERROR: hook /usr/share/apport/package-hooks/cloud-init.py crashed:
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in 
_run_hook
  symb['add_info'](report, ui)
File "/usr/share/apport/package-hooks/cloud-init.py", line 6, in add_info
  return cloudinit_add_info(report, ui)
File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 123, in 
add_info
  attach_cloud_init_logs(report, ui)
File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 57, in 
attach_cloud_init_logs
  'cloud-init-output.log.txt': 'cat /var/log/cloud-init-output.log'})
File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 444, in 
attach_root_command_outputs
  sp = subprocess.Popen(_root_command_prefix() + [wrapper_path, 
script_path])
File "/usr/lib/python3.6/subprocess.py", line 729, in __init__
  restore_signals, start_new_session)
File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
  raise child_exception_type(errno_num, err_msg, err_filename)
  FileNotFoundError: [Errno 2] No such file or directory: 'pkexec': 'pkexec'

  (As alluded to above, this also demonstrates bug 1861450 after the
  traceback is emitted.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1861451/+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 1861446] Re: on focal 'ubuntu-bug linux' doesn't automatically collect kernel artifacts

2020-02-06 Thread Brian Murray

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

** Also affects: linux (Ubuntu Focal)
   Importance: Undecided
   Status: Confirmed

** Tags removed: rls-ff-incoming

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

Title:
  on focal 'ubuntu-bug linux' doesn't automatically collect kernel
  artifacts

Status in apport package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in apport source package in Focal:
  New
Status in linux source package in Focal:
  Confirmed

Bug description:
  Hello, on focal I ran 'ubuntu-bug linux' to report a kernel issue. The
  issue was filed against linux-signed-5.4 (Ubuntu) rather than linux
  (Ubuntu), and none of the logs usually included with kernel bug
  reports were included.

  After the bug was changed from linux-signed-5.4 to linux, I was
  prompted to run apport-collect by the kernel team's triagebot and that
  worked successfully:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861359/+activity

  My guess is that apport needs to be updated to understand a change in
  kernel packaging.

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apport 2.20.11-0ubuntu16
  ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
  Uname: Linux 5.4.0-12-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportLog:
   
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CrashReports:
   640:1000:1000:40192:2020-01-30 03:32:41.717296496 +:2020-01-30 
03:32:41.717296496 +:/var/crash/_usr_bin_apport-bug.1000.crash
   600:0:0:467987:2020-01-24 20:40:35.855434497 +:2020-01-24 
20:40:35.819434494 +:/var/crash/zfsutils-linux.0.crash
   640:0:0:386063:2020-01-24 20:42:09.391725398 +:2020-01-24 
20:42:08.887728256 +:/var/crash/_usr_sbin_zfs.0.crash
  Date: Thu Jan 30 18:44:47 2020
  PackageArchitecture: all
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: Upgraded to focal on 2020-01-24 (5 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1861446/+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 1862216] [NEW] Unclear AppStream message in `update` output

2020-02-06 Thread Dan Watkins

Public bug reported:

When I run `apt update`, I see an AppStream message in the output:

$ sudo apt update

Fetched 42.5 MB in 15s (2,842 kB/s) 

  
The AppStream system cache was updated, but some components were ignored. Refer 
to the verbose log for more information.
Reading package lists... Done
Building dependency tree   
Reading state information... Done
23 packages can be upgraded. Run 'apt list --upgradable' to see them.

Even as an Ubuntu developer, I don't know what that means, so I would
imagine most of our users won't either.  What effect will this have on
me?  Is it something I should worry about?  Should I be looking at the
verbose log whenever I see this message?  Where is the verbose log?

I think this message could serve to see some improvement, to make it
clearer to users what has happened and what their expected actions are.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: apt 1.9.8
ProcVersionSignature: Ubuntu 5.4.0-13.16-generic 5.4.16
Uname: Linux 5.4.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
CurrentDesktop: i3
Date: Thu Feb  6 12:28:19 2020
InstallationDate: Installed on 2019-05-07 (275 days ago)
InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
SourcePackage: apt
UpgradeStatus: Upgraded to focal on 2019-11-15 (82 days ago)

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


** Tags: amd64 apport-bug focal

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

Title:
  Unclear AppStream message in `update` output

Status in apt package in Ubuntu:
  New

Bug description:
  When I run `apt update`, I see an AppStream message in the output:

  $ sudo apt update
  
  Fetched 42.5 MB in 15s (2,842 kB/s)   


  The AppStream system cache was updated, but some components were ignored. 
Refer to the verbose log for more information.
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  23 packages can be upgraded. Run 'apt list --upgradable' to see them.

  Even as an Ubuntu developer, I don't know what that means, so I would
  imagine most of our users won't either.  What effect will this have on
  me?  Is it something I should worry about?  Should I be looking at the
  verbose log whenever I see this message?  Where is the verbose log?

  I think this message could serve to see some improvement, to make it
  clearer to users what has happened and what their expected actions
  are.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apt 1.9.8
  ProcVersionSignature: Ubuntu 5.4.0-13.16-generic 5.4.16
  Uname: Linux 5.4.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CurrentDesktop: i3
  Date: Thu Feb  6 12:28:19 2020
  InstallationDate: Installed on 2019-05-07 (275 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: apt
  UpgradeStatus: Upgraded to focal on 2019-11-15 (82 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1862216/+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 1834875] Re: cloud-init growpart race with udev

2020-02-06 Thread Ryan Harper

Cloud-init service starts and will run growpart, etc

Feb 06 00:37:26 ubuntu systemd[1]: Starting Initial cloud-init job 
(pre-networking)...
Feb 06 00:37:37 test-xrdpdnvfctsofyygmzan systemd[1]: Starting Initial 
cloud-init job (metadata service crawler)...

Something has modified sdb1 (growpart/sgdisk) so we see a change event, and 
removal of symlink
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[265]: sdb1: Device 
(SEQNUM=3353, ACTION=change) is queued
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: sdb1: Updating 
old name, '/dev/disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea' no 
longer belonging to 
'/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/--8899--/host0/target0:0:0/0:0:0:0/block/sdb/sdb1'
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: read: 
off=2244476928 len=26214
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: sdb1: No 
reference left, removing 
'/dev/disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea'

cc_growpart attempts to check if the block device has been resized and fails
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan cloud-init[570]: 2020-02-06 
00:37:42,658 - util.py[WARNING]: Running module growpart () failed

cloud-init now runs resizefs on sdb1
Feb 06 00:37:43 test-xrdpdnvfctsofyygmzan kernel: EXT4-fs (sdb1): resizing 
filesystem from 548091 to 7836155 blocks
Feb 06 00:37:44 test-xrdpdnvfctsofyygmzan kernel: EXT4-fs (sdb1): resized 
filesystem to 7836155

Almost a minute later, something triggers a rescan and we see the link
return (looks like walinuxagent poking)

Feb 06 00:38:14 test-xrdpdnvfctsofyygmzan systemd-udevd[1482]: sdb1: 
/usr/lib/udev/rules.d/60-persistent-storage.rules:106 LINK 
'disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea'
Feb 06 00:38:14 test-xrdpdnvfctsofyygmzan systemd-udevd[1482]: sdb1: Creating 
symlink '/dev/disk/by-partuuid/5e01dd62-6f50-4cd7-8f62-30bb372b58ea' to 
'../../sdb1'

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1862044] Re: packet loss, extra latency and lower bandwidth on bionic

2020-02-06 Thread Pauloone

This second graph shows during the same run the number of packets per
second this time.

YOu can see that Xenial is sending less packets per second than bionic.

Also this is the output of tc -s qdisc for the second bionic node:

qdisc fq_codel 0: dev enp3s0 root refcnt 2 limit 10240p flows 1024 quantum 1514 
target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 254067572631 bytes 675644785 pkt (dropped 1732, overlimits 0 requeues 
627) 
 backlog 0b 0p requeues 627

As you can see packet drop is reported, an only that test as been run
this this machine as been created.

this is the same output for the Xenial node:

qdisc pfifo_fast 0: dev enp3s0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 
1 1 1 1 1 1 1
 Sent 326734300816 bytes 22299 pkt (dropped 0, overlimits 0 requeues 
558309) 

as you can see no packet drop, but we this machine exist since way
longer time.



** Attachment added: "packets trhoughput"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1862044/+attachment/5325973/+files/packets%20throughput.png

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

Title:
  packet loss, extra latency and lower bandwidth on bionic

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  We are investigating migrating our servers from Xenial to Bionic.
  We are seeing significant network differences between the 2 LTS versions.
  Using the same hardware an machines connected to a single swith on the same 
network, we see:
  10% less packets throuput on bionic in comparision to Xenial when running 
uperf.
  Also "tc -s qdisc" report packets been dropped on Bionic but not Xenial.
  The command iperf -c  -u -d -p 20 timeout on Bionic and not on Xenial, 
and if you reduce the value of p, you will see more packet drops on Bionic.

  We tryied to upgrade the xenial kernel to the same version than
  bionic. We did not see any improvement.

  All the tests are performed with 4 identical physical machines
  connected to the same physical switch. With one bionic machine, one
  Xenial machine and 2 extra Xenial machine that act as iperf/uperf
  clients.

  All 4 nodes are configured as ntp peers with each others. Under load,
  the bionic machine see siginificant jitter improvement with the 3
  others machines. We don't see that with the Xenial hosts.

  I doesn't seems to be an hardware compatibility issue as we see
  significant network performance loss in our datacenter on fully
  different hardware.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: iperf 2.0.10+dfsg1-1ubuntu0.18.04.2
  ProcVersionSignature: Ubuntu 4.15.0-76.86-lowlatency 4.15.18
  Uname: Linux 4.15.0-76-lowlatency x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  Date: Wed Feb 5 17:14:25 2020
  Dependencies:
   gcc-8-base 8.3.0-6ubuntu1~18.04.1
   libc6 2.27-3ubuntu1
   libgcc1 1:8.3.0-6ubuntu1~18.04.1
   libstdc++6 8.3.0-6ubuntu1~18.04.1
  InstallationDate: Installed on 2020-01-29 (7 days ago)
  InstallationMedia: Ubuntu-Server 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: iperf
  UpgradeStatus: No upgrade log present (probably fresh install)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.29
  ProcVersionSignature: Ubuntu 4.15.0-76.86-lowlatency 4.15.18
  Uname: Linux 4.15.0-76-lowlatency x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  Date: Wed Feb  5 17:29:53 2020
  ExecutablePath: /lib/systemd/systemd
  InstallationDate: Installed on 2020-01-29 (7 days ago)
  InstallationMedia: Ubuntu-Server 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  MachineType: Dell Inc. XPS 8700
  ProcEnviron:
   TERM=linux
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-76-lowlatency 
root=UUID=400563c9-8749-47b7-8abb-1efdb57bc589 ro
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/16/2013
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A01
  dmi.board.name: 0KWVT8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA01:bd05/16/2013:svnDellInc.:pnXPS8700:pvr:rvnDellInc.:rn0KWVT8:rvrA00:cvnDellInc.:ct3:cvr:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: XPS 8700
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1862044/+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 1862044] Re: packet loss, extra latency and lower bandwidth on bionic

2020-02-06 Thread Pauloone

SO here attached are 2 differents graphs that illustrate the problem.

So I ran uperf 1000 time on bionic and Xenial.

the bit throughput graph show the percentiles distribution of the bits/seconds 
calculated by uperf. YOu will see 2 bionic run on 2 separate machine.
You will see that Xenial as around 20% more bandwith than bionic.


** Attachment added: "bit throughput"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1862044/+attachment/5325961/+files/bits%20throughput.png

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

Title:
  packet loss, extra latency and lower bandwidth on bionic

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  We are investigating migrating our servers from Xenial to Bionic.
  We are seeing significant network differences between the 2 LTS versions.
  Using the same hardware an machines connected to a single swith on the same 
network, we see:
  10% less packets throuput on bionic in comparision to Xenial when running 
uperf.
  Also "tc -s qdisc" report packets been dropped on Bionic but not Xenial.
  The command iperf -c  -u -d -p 20 timeout on Bionic and not on Xenial, 
and if you reduce the value of p, you will see more packet drops on Bionic.

  We tryied to upgrade the xenial kernel to the same version than
  bionic. We did not see any improvement.

  All the tests are performed with 4 identical physical machines
  connected to the same physical switch. With one bionic machine, one
  Xenial machine and 2 extra Xenial machine that act as iperf/uperf
  clients.

  All 4 nodes are configured as ntp peers with each others. Under load,
  the bionic machine see siginificant jitter improvement with the 3
  others machines. We don't see that with the Xenial hosts.

  I doesn't seems to be an hardware compatibility issue as we see
  significant network performance loss in our datacenter on fully
  different hardware.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: iperf 2.0.10+dfsg1-1ubuntu0.18.04.2
  ProcVersionSignature: Ubuntu 4.15.0-76.86-lowlatency 4.15.18
  Uname: Linux 4.15.0-76-lowlatency x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  Date: Wed Feb 5 17:14:25 2020
  Dependencies:
   gcc-8-base 8.3.0-6ubuntu1~18.04.1
   libc6 2.27-3ubuntu1
   libgcc1 1:8.3.0-6ubuntu1~18.04.1
   libstdc++6 8.3.0-6ubuntu1~18.04.1
  InstallationDate: Installed on 2020-01-29 (7 days ago)
  InstallationMedia: Ubuntu-Server 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: iperf
  UpgradeStatus: No upgrade log present (probably fresh install)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.29
  ProcVersionSignature: Ubuntu 4.15.0-76.86-lowlatency 4.15.18
  Uname: Linux 4.15.0-76-lowlatency x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  Date: Wed Feb  5 17:29:53 2020
  ExecutablePath: /lib/systemd/systemd
  InstallationDate: Installed on 2020-01-29 (7 days ago)
  InstallationMedia: Ubuntu-Server 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  MachineType: Dell Inc. XPS 8700
  ProcEnviron:
   TERM=linux
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-76-lowlatency 
root=UUID=400563c9-8749-47b7-8abb-1efdb57bc589 ro
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/16/2013
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A01
  dmi.board.name: 0KWVT8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA01:bd05/16/2013:svnDellInc.:pnXPS8700:pvr:rvnDellInc.:rn0KWVT8:rvrA00:cvnDellInc.:ct3:cvr:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: XPS 8700
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1862044/+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 1671951] Re: networkd should allow configuring IPV6 MTU

This SRU needs to be reuploaded, due to security update that trumped
this in progress SRU.

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

Title:
  networkd should allow configuring IPV6 MTU

Status in systemd:
  Unknown
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix
Status in cloud-init source package in Eoan:
  New
Status in netplan.io source package in Eoan:
  Fix Released
Status in systemd source package in Eoan:
  In Progress
Status in cloud-init source package in Focal:
  Confirmed
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

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

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

[Touch-packages] [Bug 1762391] Re: pam_group.so is not evaluated by gnome-terminal

This SRU needs to be reuploaded, due to security update that trumped
this in progress SRU.

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

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

** Tags removed: verification-done verification-done-bionic 
verification-done-eoan
** Tags added: verification-failed verification-failed-bionic 
verification-failed-eoan

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

Title:
  pam_group.so is not evaluated by gnome-terminal

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Won't Fix
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 Eoan:
  In Progress
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]

  pam_setcred call was missing in systemd making its implementation of the PAM 
protocol incomplete. It could manifest in different ways, but one particularly 
problematic for enterprise environments was the fact that
  processes were never getting group membership they were expected to get via 
pam_group module.

  [Test Case]

   * Add a /etc/security/group.conf entry, e.g.
     *;*;*;Al-2400;dialout,users
   * Add pam_group to your PAM stack, e.g. /etc/pam.d/common-auth
   * Login to the system and launch gnome-terminal (it will be launched via 
gnome-terminal-server launched by systemd --user + dbus).

  Expected result:
  Logged in user is a member of 'dialout' and 'users' groups.

  Actual result:
  no group membership gained from pam_group.

  [Regression Potential]

   * It introduces a new PAM warning message in some scenarios (e.g. for
  systemd DynamicUser=1 units) for users that can't authenticate
  (pam_setcred fails in such case).

   * In certain systems user group membership may be extended by
  pam_group.

  [Other Info]
  Original bug description:

  We are using Ubuntu in a university network with lots of ldap users.
  To automatically map ldap users/groups to local groups we are using
  pam_group.so. This has worked for years.

  With the upgrade from Xenial to Bionic /etc/security/group.conf is not
  evaluated anymore by gnome-terminal as it runs as systemd --user.
  Xterm, ssh, su, and tty* however do work as expected. Only the default
  gnome-terminal behaves different.

  According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243
  and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this
  might not be a bug, but a feature.

  Nevertheless this behavior is very unexpected when upgrading from
  Xenial to Bionic and therefore should at least added to the changelog.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gnome-terminal 3.28.0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
  Uname: Linux 4.15.0-10-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu4
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr  9 13:17:52 2018
  InstallationDate: Installed on 2018-03-29 (11 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1762391/+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: systemd fails to setup static routes at boot when using DHCP

** Changed in: systemd (Ubuntu Bionic)
   Status: Fix Committed => 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/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:
  Won't Fix
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 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

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1836695/+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 1671951] Re: networkd should allow configuring IPV6 MTU

This SRU needs to be reuploaded, due to security update that trumped
this in progress SRU.

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

Title:
  networkd should allow configuring IPV6 MTU

Status in systemd:
  Unknown
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix
Status in cloud-init source package in Eoan:
  New
Status in netplan.io source package in Eoan:
  Fix Released
Status in systemd source package in Eoan:
  In Progress
Status in cloud-init source package in Focal:
  Confirmed
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

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

-- 
Mailing list:

[Touch-packages] [Bug 1849261] Re: Update systemd for ubuntu 18.04 with fix for interaction between OnFailure= and Restart=

This SRU needs to be reuploaded, due to security update that trumped
this in progress SRU.

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

Title:
  Update systemd for ubuntu 18.04 with fix for interaction between
  OnFailure= and Restart=

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Won't Fix
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  services configured with both OnFailure= and Restart= directives will
  both start the failure service(s), as well as restarting itself.  The
  documentation (and later versions) indicate that OnFailure= services
  will only be started once the service actually does stop (due to
  failure) once its restart limit has been exceeded.

  [test case]

  create service files as:

  ubuntu@lp1849261-b:/etc/systemd/system$ cat test.service
  [Unit]
  OnFailure=failure.service

  [Service]
  ExecStart=/bin/sh -c '/bin/sleep 10; /bin/false'
  Restart=always

  ubuntu@lp1849261-b:/etc/systemd/system$ cat failure.service
  [Service]
  ExecStart=/bin/true

  perform daemon-reload, and then start test service:

  ubuntu@lp1849261-b:/etc/systemd/system$ sudo systemctl daemon-reload
  ubuntu@lp1849261-b:/etc/systemd/system$ sudo systemctl start test

  wait for a while for the test service to exit - at least 10 seconds,
  as that's what we configured in the service, although I have waited
  longer in this example.  Then check the journal for both test and
  failure services:

  ubuntu@lp1849261-b:/etc/systemd/system$ journalctl -b -u test
  -- Logs begin at Fri 2019-12-13 00:52:50 UTC, end at Fri 2019-12-13 01:18:34 
UTC. --
  Dec 13 01:17:43 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:17:53 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 1.
  Dec 13 01:17:53 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:17:53 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:03 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:04 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:04 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 2.
  Dec 13 01:18:04 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:18:04 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:14 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 3.
  Dec 13 01:18:14 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:18:14 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Service hold-off time 
over, scheduling restart.
  Dec 13 01:18:24 lp1849261-b systemd[1]: test.service: Scheduled restart job, 
restart counter is at 4.
  Dec 13 01:18:24 lp1849261-b systemd[1]: Stopped test.service.
  Dec 13 01:18:24 lp1849261-b systemd[1]: Started test.service.
  Dec 13 01:18:34 lp1849261-b systemd[1]: test.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 13 01:18:34 lp1849261-b systemd[1]: test.service: Failed with result 
'exit-code'.
  Dec 13 01:18:34 lp1849261-b systemd[1]: test.service: Triggering OnFailure= 
dependencies.
  Dec 13 01:18:34 lp1849261-b systemd[1]: test.service: Service hold-off time

[Touch-packages] [Bug 1845909] Re: [SRU] IPv6 link local address is assigned even when LinkLocalAddressing=no|ipv4

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

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

Title:
  [SRU] IPv6 link local address is assigned even when
  LinkLocalAddressing=no|ipv4

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  In Progress
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  in some situations when a networkd interface is configured with
  LinkLocalAddressing=no, networkd still assigns a link-local address to
  it

  [test case]

  see comment 3.

  note I was only able to reproduce this at boot time; if the vlan
  interface is removed (i.e. 'sudo ip l del pppoe') and then networkd
  restarted, the pppoe interface is created and does not have a link-
  local address.  This is due to this bug being triggered by timing, as
  a vlan interface is raised by the kernel when its parent interface is
  raised, in this case by networkd itself.

  [regression potential]

  this changes how ipv6ll addresses are managed and dropped, as well as
  changing when foreign addresses are dropped (later in config process).
  Any regressions would likely be around incorrectly setting ipv6ll
  addresses, or complete failure to complete interface configuration.

  [scope]

  this is fixed upstream by:
  https://github.com/systemd/systemd/pull/13927

  and also requires the upstream PR referenced in the original description:
  upstream patch: https://github.com/systemd/systemd/pull/13565

  this is required for focal (uploaded already), eoan, and bionic.  It
  may be required for xenial.

  [other info]

  Note, the original description below is incorrect, the issue/patch it
  references is not enough to fix this issue.

  original description:

  --

  upstream issue: https://github.com/systemd/systemd/issues/12886
  upstream patch: https://github.com/systemd/systemd/pull/13565

  The upstream fix will be available in systemd 244.
  Backport please. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1845909/+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 1847816] Re: storage autopkgtest always fails with linux-{kvm, azure, etc} kernels that don't include scsi_debug module

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

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

Title:
  storage autopkgtest always fails with linux-{kvm,azure,etc} kernels
  that don't include scsi_debug module

Status in autopkgtest-cloud:
  New
Status in linux-kvm package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in linux-kvm source package in Xenial:
  New
Status in systemd source package in Xenial:
  In Progress
Status in linux-kvm source package in Bionic:
  New
Status in systemd source package in Bionic:
  In Progress
Status in linux-kvm source package in Disco:
  New
Status in systemd source package in Disco:
  Won't Fix
Status in linux-kvm source package in Eoan:
  New
Status in systemd source package in Eoan:
  In Progress
Status in linux-kvm source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Released

Bug description:
  Note: this bug touches on multiple packages:
  - autopkgtest-cloud: merge request open to install 'modules-extra' package
  - systemd: update autopkgtest to skip test if scsi_debug module isn't 
available (SRU template below is for this change)
  - linux-kvm: has CONFIG_SCSI_DEBUG unset, but would be good to have 
scsi_debug module built for this kernel

  [SRU template for systemd]

  [impact]

  the 'storage' autopkgtest requires the 'scsi_debug' module, and if it
  can't load it (and it's not built-in), the test fails.  On some custom
  kernels, this module is included in the new 'linux-modules-extra-*'
  deb which isn't installed by default, so the test always fails when
  doing a reverse-dep autopkgtest using such a kernel's meta pkg.

  Additionally, some custom kernels, like linux-kvm, have SCSI_DEBUG
  disabled entirely; for those kernels, it will never be possible to
  load the scsi_debug module and the test should be skipped.

  [test case]

  run the 'storage' autopkgtest with a custom kernel that doesn't
  provide the scsi_debug module in the standard linux-modules deb, or
  check the autopkgtest.u.c history, for example:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20191209_150835_237a5@/log.gz

  [regression potential]

  as this modifies one of the autopkgtest --setup-commands, a regression
  would most likely cause immediate test failure due to failing to
  install the proper linux-* debs.

  For the systemd 'storage' test change, this only skips the test if the
  scsi_debug module can't be loaded (and isn't already present, i.e.
  loaded or built-in).  Any regression potential from that is low, but
  likely would involve incorrect test skips and/or missing valid
  problems due to skipping the test.

  [scope]

  systemd in all releases needs to have its 'storage' test updated

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopkgtest-cloud/+bug/1847816/+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 1859862] Re: networkd doesn't re-enable ipv6 unless mtu is set

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

Title:
  networkd doesn't re-enable ipv6 unless mtu is set

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [impact]

  if the 'disable_ipv6' procfs setting is disabled, and networkd is
  configured with ipv6 networking, networkd will not enable ipv6 via the
  procfs setting unless the interface mtu is also set to a custom value,
  that doesn't match the current interface mtu.

  [test case]

  create networkd config similar to:

  [Match]
  MACAddress=52:54:00:0c:09:77
  Name=ens3

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=2001:db8::100/64

  manually disable ipv6 for the interface:

  ubuntu@lp1859862-b:~$ echo 1 | sudo tee 
/proc/sys/net/ipv6/conf/ens3/disable_ipv6
  1

  the interface should not contain any ipv6 addresses:

  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$

  restart networkd; it should enable ipv6 as ipv6 addresses are
  configured, but it does not:

  ubuntu@lp1859862-b:~$ sudo systemctl restart systemd-networkd
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$

  Note that with the mtu set, it will successfully re-enable ipv6;
  modify the networkd config to set the mtu by adding this:

  [Link]
  MTUBytes=1400

  verify ipv6 is still disabled and has no addresses, then restart and
  check again:

  ubuntu@lp1859862-b:~$ cat /proc/sys/net/ipv6/conf/ens3/disable_ipv6
  1
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  ubuntu@lp1859862-b:~$ sudo systemctl restart systemd-networkd
  ubuntu@lp1859862-b:~$ cat /proc/sys/net/ipv6/conf/ens3/disable_ipv6
  0
  ubuntu@lp1859862-b:~$ ip -6 a show ens3
  2: ens3:  mtu 1400 state UP qlen 1000
  inet6 2001:db8::100/64 scope global
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe0c:977/64 scope link
     valid_lft forever preferred_lft forever

  That should be the behavior even if MTUBytes is not set.

  [regression potential]

  as this adjusts when the procfs 'disable_ipv6' setting is changed, the
  regression potential could cause failure to properly set/create ipv6
  addresses, or to leave ipv6 disabled entirely.

  [scope]

  This is needed in Bionic and Eoan.

  the commit to fix this is 482efedc081b0c4bf2e77a3dee6b979d9c9a5765
  which is included starting in v243, so it is included already in
  Focal.

  Ignoring Disco, as it is EOL next week.

  This problem was introduced by commit
  44b598a1c9d11c23420a5ef45ff11bcb0ed195eb, which was included starting
  in v239, but also backported to Bionic in bug 1850704.

  [other info]

  for Eoan, this bug has always existed since release, but for Bionic,
  this is a regression introduced by bug 1850704.  However, manual
  disabling of ipv6 is very unusual, so this bug is unlikely to have an
  impact to many systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1859862/+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 1831459] Re: 'storage' test needs to wait for systemd-cryptsetup to be active before stopping it

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

Title:
  'storage' test needs to wait for systemd-cryptsetup to be active
  before stopping it

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
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:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  test case fails because it does not wait for the service to become
  active before stopping it, resulting in failure to rmmod the
  scsi_debug module because it's still in use.

  [test case]

  check 'storage' test results for systemd in 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]

  low; test case fix only.

  [other info]

  detected and reported by @cascardo in bug 1814373 comment 4 and 5, but
  separate (non-test) systemd bugfix uploaded for that bug so opening
  this bug to track fixing the test case.

  larger fixes/improvements to 'storage' testcase in bug 1829347, but
  those rejected.

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

This SRU needs to be reuploaded, due to security update that trumped
this in progress SRU.

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

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

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

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

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  Won't Fix

Bug description:
  [impact]

  if networkd is configured with a static address, and the address has
  already been assigned by dhcp (so that it has finite valid_lft),
  networkd will not change the valid_lft to 'forever' during startup,
  which leaves networkd thinking the address is static (meaning,
  networkd will not attempt to renew the dhcp lease) but the address
  valid_lft counting down.

  Once the valid_lft expires, the kernel will remove the address from
  the interface, breaking the system's networking.

  [test case]

  configure a system with networkd similar to:

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  restart systemd-networkd, and ens3 should get a DHCP address, e.g.:

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2295sec preferred_lft 2295sec

  then, edit the networkd config to use a static address, e.g.:

  [Match]
  Name=ens3

  [Network]
  Address=192.168.122.147/24
  Gateway=192.168.122.1
  DNS=192.168.122.1
  Domains=vm

  make sure to use the exact same address that was provided by dhcp.

  Then, without rebooting, just restart networkd and check the address
  lft:

  $ sudo systemctl restart systemd-networkd

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2992sec preferred_lft 2992sec

  the address should have 'forever' valid_lft, but it doesn't.

  [regression potential]

  this changes the details of how networkd updates static addresses
  during startup, so any regression would occur at networkd startup when
  using static addresses.

  [scope]

  this is needed only in Bionic and Disco.

  this is fixed by upstream:
  https://github.com/systemd/systemd/pull/11460/commits
  specifically commit a47a6daebe0af26c07d8d423225eb4add110793c
  which is included in Eoan and later.

  In Xenial using networkd, testing shows this problem does not occur,
  because this older version of networkd removes the 'foreign' dhcp
  address before re-assigning it as a static address.

  [other info]

  original 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/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 1860548] Re: systemd crashes when logging long message

This SRU needs to be reuploaded, due to security update that trumped
this in progress SRU.

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

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

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

Title:
  systemd crashes when logging long message

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

Bug description:
  [Impact]

  Systemd crashes when logging very long messages. This regression was 
introduced with
  upstream commit d054f0a4d451 [1] due to xsprintf.
  Commits e68eedbbdc98 [2] and 574432f889ce [3] replace some uses of xsprintf 
with
  snprintf and fix it.

  [Test Case]

  # systemd-run --scope apt-get -q -y -o DPkg::Options::=--force-confold
  -o DPkg::Options::=--force-confdef --allow-unauthenticated install acl
  adduser amd64-microcode apt base-files base-passwd bash bash-
  completion bind9-host binfmt-support binutils-common binutils-x86-64
  -linux-gnu bsdmainutils bsdutils busybox-initramfs busybox-static
  bzip2 ca-certificates console-setup console-setup-linux coreutils cpio
  cpp cpp-7 crda cron curl dash dbus dctrl-tools debconf debconf-i18n
  debianutils dictionaries-common diffutils dirmngr distro-info-data
  dmeventd dmsetup dnsmasq-base dnsutils dpkg e2fslibs e2fsprogs ed
  eject fakeroot fdisk file findutils friendly-recovery gawk gcc-7-base
  gcc-8-base gettext-base gir1.2-glib-2.0 gnupg gnupg-l10n gnupg-utils
  gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv grep
  groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname
  info init init-system-helpers initramfs-tools initramfs-tools-bin
  initramfs-tools-core install-info intel-microcode iproute2 iptables
  iputils-ping iputils-tracepath irqbalance isc-dhcp-client isc-dhcp-
  common iso-codes iw keyboard-configuration keyutils klibc-utils kmod
  krb5-locales krb5-user language-pack-en language-pack-en-base
  language-pack-gnome-en language-pack-gnome-en-base less
  libaccountsservice0 libacl1 libapparmor1 libargon2-0 libasan4
  libasn1-8-heimdal libassuan0 libatm1 libatomic1 libattr1 libaudit-
  common libaudit1  libbinutils libblkid1 libbsd0 libbz2-1.0 libc-bin
  libc-dev-bin libc6 libc6-dev libcap-ng0 libcap2 libcap2-bin libcc1-0
  libcilkrts5 libcom-err2 libcryptsetup12 libcurl3-gnutls libcurl4
  libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper-event1.02.1
  libdevmapper1.02.1 libdpkg-perl libdrm-common libdrm2 libdumbnet1
  libedit2 libelf1 libestr0 libevent-2.1-6 libexpat1 libexpat1-dev
  libext2fs2 libfakeroot libfastjson4 libfdisk1 libffi6 libfreetype6
  libfribidi0 libfuse2 libgc1c2 libgcc-7-dev libgcc1 libgcrypt20
  libgdbm-compat4 libgeoip1 libgirepository-1.0-1 libglib2.0-0
  libglib2.0-data libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2
  libgssapi-krb5-2 libgssapi3-heimdal libgssrpc4 libhcrypto4-heimdal
  libheimbase1-heimdal libheimntlm0-heimdal libhogweed4
  libhx509-5-heimdal libitm1 libjs-jquery libjs-sphinxdoc libjs-
  underscore libk5crypto3 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-9
  libkeyutils1 libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0
  libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0
  liblz4-1 liblzma5 libmagic-mgc libmagic1 libmnl0 libmount1 libmpc3
  libmpdec2 libmpfr6 libmpx2 libmspack0 libncurses5 libncursesw5
  libnetfilter-conntrack3 libnettle6 libnewt0.52 libnfnetlink0
  libnfsidmap2 libnghttp2-14  libnl-3-200 libnl-genl-3-200 libnorm1
  libnpth0 libnss-systemd libnuma1 libp11-kit0 libpam-cap libpam-krb5
  libpam-modules libpam-modules-bin libpam-runtime libpam-systemd
  libpam0g libparted2 libpcap0.8 libpci3 libpcre3 libpgm-5.2-0
  libpipeline1 libplymouth4 libpng16-16 libpolkit-gobject-1-0 libpopt0
  libpsl5 libpython-all-dev libpython-dev libpython-stdlib libpython2.7
  libpython2.7-dev libpython2.7-minimal

  # tail -f /var/log/syslog
  ...
  Jan 22 12:50:33 bionic-kernel systemd[1]: Assertion 'xsprintf: buf[] must be 
big enough' failed at ../src/core/job.c:803, function job_log_status_message(). 
Aborting.

  Broadcast message from systemd-journald@bionic-kernel (Wed 2020-01-22
  12:50:33 UTC):

  systemd[1]: Caught , dumped core as pid 14620.

  Broadcast message from systemd-journald@bionic-kernel (Wed 2020-01-22
  12:50:33 UTC):

  systemd[1]: Freezing execution.

  Jan 22 12:50:33 bionic-kernel systemd[1]: Caught , dumped core as pid 
14620.
  Jan 22 12:50:33 bionic-kernel systemd[1]: Freezing execution.

  [Regression Potential]

  The patches replace xsprintf with snprintf and the regression
  potential is small.

  Any regression would likely involve

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-06 Thread Pat Viafore

I'm attaching the output of a failing build

** Attachment added: "failing_journalctl_output.txt"
   
https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5325941/+files/failing_journalctl_output.txt

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1856703] Re: Return only PAM_IGNORE or error from pam_motd

2020-02-06 Thread Francis Ginther

** Tags added: id-5d78fc6cca6d1b77a77952cc

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

Title:
   Return only PAM_IGNORE or error from pam_motd

Status in pam package in Ubuntu:
  Fix Released
Status in pam source package in Eoan:
  Fix Committed

Bug description:
  
  https://github.com/linux-pam/linux-pam/pull/157

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

2020-02-06 Thread Dan Streetman

> What's interesting though, is that a fresh install of bionic came with
a newer version (systemd=237-3ubuntu10.38) - which has the bug. This
test effectively ended up in a downgrade.

yes, a security release for systemd overrode the version with this fix
in -proposed, so I have to rebase these patches and re-upload.  These
things sometimes happen, unfortunately.

-- 
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:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Won't Fix

Bug description:
  [impact]

  if networkd is configured with a static address, and the address has
  already been assigned by dhcp (so that it has finite valid_lft),
  networkd will not change the valid_lft to 'forever' during startup,
  which leaves networkd thinking the address is static (meaning,
  networkd will not attempt to renew the dhcp lease) but the address
  valid_lft counting down.

  Once the valid_lft expires, the kernel will remove the address from
  the interface, breaking the system's networking.

  [test case]

  configure a system with networkd similar to:

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  restart systemd-networkd, and ens3 should get a DHCP address, e.g.:

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2295sec preferred_lft 2295sec

  then, edit the networkd config to use a static address, e.g.:

  [Match]
  Name=ens3

  [Network]
  Address=192.168.122.147/24
  Gateway=192.168.122.1
  DNS=192.168.122.1
  Domains=vm

  make sure to use the exact same address that was provided by dhcp.

  Then, without rebooting, just restart networkd and check the address
  lft:

  $ sudo systemctl restart systemd-networkd

  $ ip -4 a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 192.168.122.147/24 brd 192.168.122.255 scope global dynamic ens3
     valid_lft 2992sec preferred_lft 2992sec

  the address should have 'forever' valid_lft, but it doesn't.

  [regression potential]

  this changes the details of how networkd updates static addresses
  during startup, so any regression would occur at networkd startup when
  using static addresses.

  [scope]

  this is needed only in Bionic and Disco.

  this is fixed by upstream:
  https://github.com/systemd/systemd/pull/11460/commits
  specifically commit a47a6daebe0af26c07d8d423225eb4add110793c
  which is included in Eoan and later.

  In Xenial using networkd, testing shows this problem does not occur,
  because this older version of networkd removes the 'foreign' dhcp
  address before re-assigning it as a static address.

  [other info]

  original 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/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 1859308] Re: software-properties-gtk erroneously reports that Intel Wireless-AC 9260 device is not working

The label is confusing but the status is mostly coming from ubuntu-
drivers. Alberto do you have an idea what's going on there?

$ ubuntu-drivers device
states 
manual_install: True
driver : backport-iwlwifi-dkms - distro free

$ ubuntu-drivers install
No drivers found for installation

(from similar situation with Wi-Fi 6 AX200 on an XPS13)

Is that expected?

** Changed in: software-properties (Ubuntu)
   Importance: Undecided => High

** Changed in: software-properties (Ubuntu)
   Status: New => Confirmed

** Changed in: software-properties (Ubuntu)
   Importance: High => Low

** Tags added: champagne desktop-lts-wishlist

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

Title:
  software-properties-gtk erroneously reports that Intel Wireless-AC
  9260 device is not working

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  On Ubuntu 20.04 (development branch), as of today, Additional Drivers
  (software-properties-gtk 0.98.6) reports that the device "Intel
  Corporation: Wireless-AC 9260" is not working, and suggests using a
  manually installed driver (cf. screenshot).

  However the device is working correctly:

    * lsmod | grep iwlwifi, lspci -v, lshw, dmesg | grep iwlwifi all show
  that its driver iwlwifi is in use
    * ls /lib/firmware/*9260* show that the appropriate firmware files
  are present

  And I am indeed writing this bug report connected to an ac (5 GHz)
  wifi network, where I can verify a ~130-160 Mbps download speed, so
  software-properties-gtk shouldn't report the device as not working and
  suggest manually installing a driver. Not sure why it says so?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: software-properties-gtk 0.98.6
  ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
  Uname: Linux 5.4.0-9-generic x86_64
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Jan 12 00:53:43 2020
  ExecutablePath: /usr/bin/software-properties-gtk
  InstallationDate: Installed on 2019-12-29 (13 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191226)
  InterpreterPath: /usr/bin/python3.7
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.7, Python 3.7.6, python3-minimal, 
3.7.5-1ubuntu1
  PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.17-1
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1859308/+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 1860504] Re: software-properties-gtk fails to launch via "Additional Drivers" or via terminal

** Changed in: software-properties (Ubuntu)
   Status: Incomplete => New

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

Title:
  software-properties-gtk fails to launch via "Additional Drivers" or
  via terminal

Status in software-properties package in Ubuntu:
  New

Bug description:
  Issue present since reinstall of Ubuntu. Originally thought similar to
  (https://askubuntu.com/questions/789966/software-updates-crashes-and-
  will-not-open) but solutions did not work, even though terminal output
  (https://pastebin.com/FpD1MFC3) is highly similar.

  I have tested using a new user and the issue remains.

  1)
  Description:  Ubuntu 19.10
  Release:  19.10
  Linux version 5.3.0-26-generic (buildd@lgw01-amd64-013) (gcc version 9.2.1 
20191008 (Ubuntu 9.2.1-9ubuntu2))
  2)
  software-properties-gtk:
    Installed: 0.98.5
    Candidate: 0.98.5
    Version table:
   *** 0.98.5 500
  500 http://gb.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  500 http://gb.archive.ubuntu.com/ubuntu eoan/main i386 Packages
  100 /var/lib/dpkg/status
  3)
  Additional Drivers utility should launch when executing command 
"software-properties-gtk" with or without root.
  4)
  Long error fight between dbus and python3.

  A note on attempted solutions. Reinstalling dbus/dbus-x11 and
  following the noted askubuntu thread did not help.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: software-properties-gtk 0.98.5
  ProcVersionSignature: Ubuntu 5.3.0-26.28-generic 5.3.13
  Uname: Linux 5.3.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jan 22 03:48:12 2020
  InstallationDate: Installed on 2020-01-14 (8 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PackageArchitecture: all
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1860504/+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 1860335] Re: Additional Drivers tab claims i8260 wifi card is not working

*** This bug is a duplicate of bug 1859308 ***
https://bugs.launchpad.net/bugs/1859308

** This bug has been marked a duplicate of bug 1859308
   software-properties-gtk erroneously reports that Intel Wireless-AC 9260 
device is not working

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

Title:
  Additional Drivers tab claims i8260 wifi card is not working

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  Recently upgraded to Focal, and despite having a stable, working wifi
  connection I see that the "Additional Drivers" tab of the GTK
  application shows that my wifi card is not working. Note there is only
  a single adapter in my laptop.

  From dmesg:

  [7.237957] iwlwifi :04:00.0: Detected Intel(R) Dual Band
  Wireless AC 8260, REV=0x208

  From lspci:
  04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: software-properties-gtk 0.98.6
  ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
  Uname: Linux 5.4.0-9-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jan 20 15:20:11 2020
  InstallationDate: Installed on 2016-11-01 (1175 days ago)
  InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  PackageArchitecture: all
  SourcePackage: software-properties
  UpgradeStatus: Upgraded to focal on 2020-01-20 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1860335/+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 1859562] Re: Polari doesn't join any chatroom. 'Join' button stays greyed-out (disabled)

2020-02-06 Thread Sergio Schvezov

Confirming this is now fixed

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

Title:
  Polari doesn't join any chatroom. 'Join' button stays greyed-out
  (disabled)

Status in telepathy-mission-control-5 package in Ubuntu:
  Fix Released

Bug description:
  I'm trying to use Polari IRC app on Ubuntu 20.04 (in virtualbox). I'm
  not able to join any chatroom because the 'Join' button stays greyed
  out when a chatroom is selected. This is same for any server/chatroom
  I could check. Screenshot attached.

  If I run polari from terminal, I get following error.

  svinoba@focal:~$ polari

  (polari:21203): Gjs-WARNING **: 16:31:29.656: JS ERROR: TelepathyGLib.Error: 
  _onRowActivated/<@resource:///org/gnome/Polari/js/connections.js:216:27
  main@resource:///org/gnome/Polari/js/main.js:63:12
  run@resource:///org/gnome/gjs/modules/package.js:222:12
  start@resource:///org/gnome/gjs/modules/package.js:206:5
  @:1:1

  However, if I search for telepathy and glib combination, I get
  following.

  gir1.2-telepathyglib-0.12/focal,now 0.24.1-2 amd64 [installed,automatic]
GLib Telepathy connection manager library (GObject-Introspection)

  libtelepathy-glib0/focal,now 0.24.1-2 amd64 [installed,automatic]
Telepathy framework - GLib library

  Polari works fine on Ubuntu 18.04, Debian Sid and Arch. Haven't tried
  in Ubuntu 19.10, although the package version in 19.10 seems same as
  20.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: polari 3.34.0-1
  ProcVersionSignature: Ubuntu 5.0.0-37.40~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-37-generic x86_64
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jan 14 09:48:34 2020
  InstallationDate: Installed on 2019-08-14 (152 days ago)
  InstallationMedia: Ubuntu-MATE 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  SourcePackage: polari
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control-5/+bug/1859562/+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 1861880] Re: lxc-attach command does not return error exit code if the command is failed

2020-02-06 Thread Bug Watch Updater

** Changed in: lxc (Debian)
   Status: Unknown => Fix Released

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

Title:
  lxc-attach command does not return error exit code if the command is
  failed

Status in lxc package in Ubuntu:
  New
Status in lxc package in Debian:
  Fix Released

Bug description:
  lxc-attach command does not return error exit code if the command is
  failed on Ubuntu Focal :

  root@scribe:~# lxc-start --version
  3.0.4
  root@scribe:~# lxc-attach --logpriority=DEBUG --name=addc -- exit
  lxc-attach: addc: attach.c: lxc_attach_run_command: 1489 No such file or 
directory - Failed to exec "exit" 
  root@scribe:~# echo $?
  0

  The problem is fixed upstream : https://github.com/lxc/lxc/issues/3104
  and by Debian : https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=934983

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: lxc-utils 3.0.4-0ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
  Uname: Linux 5.4.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  Date: Tue Feb  4 16:01:30 2020
  InstallationDate: Installed on 2020-01-10 (25 days ago)
  InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 
(20200105)
  SourcePackage: lxc
  UpgradeStatus: No upgrade log present (probably fresh install)
  defaults.conf:
   lxc.net.0.type = veth
   lxc.net.0.link = lxcbr0
   lxc.net.0.flags = up
   lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx
  lxc-net.default:
   USE_LXC_BRIDGE="true"
   LXC_BRIDGE="br0"
   LXC_ADDR="192.0.2.1"
   LXC_NETMASK="255.255.255.0"
   LXC_NETWORK="192.0.2.0/24"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1861880/+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 1862162] [NEW] Badly working video mode on the greeter

2020-02-06 Thread Jarno Suni

Public bug reported:

In the video mode there are moving stripes on the screen and monitor
turns off occasionally. (Maybe this is bad behaving monitor, an old
Samsung TV) It got good after I run

xrandr --output HDMI-1 --auto

(and similar for each other video output) in /usr/local/bin/monitor-
config.sh and I put

display-setup-script=/usr/local/bin/monitor-config.sh

in lightdm configuration.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: lightdm 1.30.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-29.31-generic 5.3.13
Uname: Linux 5.3.0-29-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: XFCE
Date: Thu Feb  6 13:35:12 2020
InstallationDate: Installed on 2019-12-05 (62 days ago)
InstallationMedia: Xubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
LightdmConfig:
 [Seat:*]
 display-setup-script=/usr/local/bin/monitor-config.sh
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-bug eoan

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

Title:
  Badly working video mode on the greeter

Status in lightdm package in Ubuntu:
  New

Bug description:
  In the video mode there are moving stripes on the screen and monitor
  turns off occasionally. (Maybe this is bad behaving monitor, an old
  Samsung TV) It got good after I run

  xrandr --output HDMI-1 --auto

  (and similar for each other video output) in /usr/local/bin/monitor-
  config.sh and I put

  display-setup-script=/usr/local/bin/monitor-config.sh

  in lightdm configuration.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: lightdm 1.30.0-0ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-29.31-generic 5.3.13
  Uname: Linux 5.3.0-29-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Thu Feb  6 13:35:12 2020
  InstallationDate: Installed on 2019-12-05 (62 days ago)
  InstallationMedia: Xubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  LightdmConfig:
   [Seat:*]
   display-setup-script=/usr/local/bin/monitor-config.sh
  SourcePackage: lightdm
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1862162/+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 1862044] Re: packet loss, extra latency and lower bandwidth on bionic

2020-02-06 Thread Pauloone

Reproducing step:
Take 3 machines, connect them on the same network through a single switch (to
limits network bandwith/latency effects)
run uperf on 3 of them, 2 slave and one master.

I am using the following uperf script:

if you put n big enough (50 in my case seems a good value) on the same hardware
you will have significant throughput differences between Bionic and Xenial.
On hundred runs, I see an avergae throuhput 719,8 Mbits/s in and 719,9 Mbits/s
out on xenial and 608,2 Mbits/s in and 608,3 Mbits/s out on Bionic. That
represent 20% network performance on bionic.

Also if I run sudo tc -s qdisc or netstat, we see packets been dropped
on Bionic but not Xenial.

I ran that test because we see network performance issue (TCP
timeouts/packet drop) when validating our application on bionic in our
datacenter, which is using a completly different hardware.

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

Title:
packet loss, extra latency and lower bandwidth on bionic

Status in systemd package in Ubuntu:
Incomplete

Bug description:
We are investigating migrating our servers from Xenial to Bionic.
We are seeing significant network differences between the 2 LTS versions.
Using the same hardware an machines connected to a single swith on the same
network, we see:
10% less packets throuput on bionic in comparision to Xenial when running
uperf.
Also "tc -s qdisc" report packets been dropped on Bionic but not Xenial.
The command iperf -c -u -d -p 20 timeout on Bionic and not on Xenial,
and if you reduce the value of p, you will see more packet drops on Bionic.

We tryied to upgrade the xenial kernel to the same version than
bionic. We did not see any improvement.

All the tests are performed with 4 identical physical machines
connected to the same physical switch. With one bionic machine, one
Xenial machine and 2 extra Xenial machine that act as iperf/uperf
clients.

All 4 nodes are configured as ntp peers with each others. Under load,
the bionic machine see siginificant jitter improvement with the 3
others machines. We don't see that with the Xenial hosts.

I doesn't seems to be an hardware compatibility issue as we see
significant network performance loss in our datacenter on fully
different hardware.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: iperf 2.0.10+dfsg1-1ubuntu0.18.04.2
ProcVersionSignature: Ubuntu 4.15.0-76.86-lowlatency 4.15.18
Uname: Linux 4.15.0-76-lowlatency x86_64
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
Date: Wed Feb 5 17:14:25 2020
Dependencies:
gcc-8-base 8.3.0-6ubuntu1~18.04.1
libc6 2.27-3ubuntu1
libgcc1 1:8.3.0-6ubuntu1~18.04.1
libstdc++6 8.3.0-6ubuntu1~18.04.1
InstallationDate: Installed on 2020-01-29 (7 days ago)
InstallationMedia: Ubuntu-Server 18.04.3 LTS "Bionic Beaver" - Release amd64
(20190805)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: iperf
UpgradeStatus: No upgrade log present (probably fresh install)

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu10.29
ProcVersionSignature: Ubuntu 4.15.0-76.86-lowlatency 4.15.18
Uname: Linux 4.15.0-76-lowlatency x86_64
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
Date: Wed Feb 5 17:29:53 2020
ExecutablePath: /lib/systemd/systemd
InstallationDate: Installed on 2020-01-29 (7 days ago)
InstallationMedia: Ubuntu-Server 18.04.3 LTS "Bionic Beaver" - Release amd64
(20190805)
MachineType: Dell Inc. XPS 8700
ProcEnviron:
TERM=linux
PATH=(custom, no user)
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-76-lowlatency
root=UUID=400563c9-8749-47b7-8abb-1efdb57bc589 ro
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/16/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A01
dmi.board.name: 0KWVT8
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias:
dmi:bvnDellInc.:bvrA01:bd05/16/2013:svnDellInc.:pnXPS8700:pvr:rvnDellInc.:rn0KWVT8:rvrA00:cvnDellInc.:ct3:cvr:

[Touch-packages] [Bug 1862157] Re: dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles

2020-02-06 Thread Thomas Schweikle

Simplest thing would be:

tftp-root

sets the tftp-root directory: /data/tftp -> /
or: /var/lib/tftpboot -> /

Whatever is done is relative to this. tftp-root is then NEVER
prepended to any file given for tftp retrival.

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

Title:
  dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  dnsmasq does in all cases prepend "tftp_root" to tftp-files.

  tftp-root=/data/tftp
  dhcp-boot=grub/i386-pc/core.0

  now have some config files for different subnets:
  dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
  dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
  dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de

  Now booting clients within subnet 172.18.1.0/24 will boot grub with:
  /data/tftp/grub/i386-pc/core.0

  Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
  /data/tftp/pxelinux.0

  And in subnet 172.18.7.0/24 clients will boot with:
  /data/tftp/var/lib/tftpboot/pxelinux.0

  and return a "File not found" error.

  I'd expected:
  172.18.1: grub/i386-pc/core.0   (file found within /data/tftp -- 
without exposing path)
  172.18.2: pxelinux.0(file found within /data/tftp -- 
without exposing path)
  172.18.3: /pxelinux.0   (file found within /)
  172.18.7: /var/lib/tftpboot/pxelinux.0  (file found within 
/var/lib/tftpboot/pxelinux.0)

  or even better: some way to set tftp-root for every subnet-config and
  having only relative paths to access files regardless of giving
  absolute or relative paths.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18
  Uname: Linux 4.15.0-87-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.10
  Architecture: amd64
  Date: Thu Feb  6 11:43:07 2020
  InstallationDate: Installed on 2014-01-31 (2197 days ago)
  InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 
(20131016)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago)
  mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595
  mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1862157/+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 1859562] Re: Polari doesn't join any chatroom. 'Join' button stays greyed-out (disabled)

The issue should be fixed with this update

https://launchpad.net/ubuntu/+source/telepathy-mission-
control-5/1:5.16.5-1ubuntu1

Closing but feel free to reopen if it doesn't work for you

** Package changed: polari (Ubuntu) => telepathy-mission-control-5
(Ubuntu)

** Changed in: telepathy-mission-control-5 (Ubuntu)
   Importance: Undecided => Low

** Changed in: telepathy-mission-control-5 (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  Polari doesn't join any chatroom. 'Join' button stays greyed-out
  (disabled)

Status in telepathy-mission-control-5 package in Ubuntu:
  Fix Released

Bug description:
  I'm trying to use Polari IRC app on Ubuntu 20.04 (in virtualbox). I'm
  not able to join any chatroom because the 'Join' button stays greyed
  out when a chatroom is selected. This is same for any server/chatroom
  I could check. Screenshot attached.

  If I run polari from terminal, I get following error.

  svinoba@focal:~$ polari

  (polari:21203): Gjs-WARNING **: 16:31:29.656: JS ERROR: TelepathyGLib.Error: 
  _onRowActivated/<@resource:///org/gnome/Polari/js/connections.js:216:27
  main@resource:///org/gnome/Polari/js/main.js:63:12
  run@resource:///org/gnome/gjs/modules/package.js:222:12
  start@resource:///org/gnome/gjs/modules/package.js:206:5
  @:1:1

  However, if I search for telepathy and glib combination, I get
  following.

  gir1.2-telepathyglib-0.12/focal,now 0.24.1-2 amd64 [installed,automatic]
GLib Telepathy connection manager library (GObject-Introspection)

  libtelepathy-glib0/focal,now 0.24.1-2 amd64 [installed,automatic]
Telepathy framework - GLib library

  Polari works fine on Ubuntu 18.04, Debian Sid and Arch. Haven't tried
  in Ubuntu 19.10, although the package version in 19.10 seems same as
  20.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: polari 3.34.0-1
  ProcVersionSignature: Ubuntu 5.0.0-37.40~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-37-generic x86_64
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jan 14 09:48:34 2020
  InstallationDate: Installed on 2019-08-14 (152 days ago)
  InstallationMedia: Ubuntu-MATE 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  SourcePackage: polari
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control-5/+bug/1859562/+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 1661447] Re: Arbitrary code execution in centos template

2020-02-06 Thread Gianni Tedesco

Great, thanks again for all the hard work!

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

Title:
  Arbitrary code execution in centos template

Status in lxc package in Ubuntu:
  Fix Released

Bug description:
  All the RPM's which get installed in an lxc-centos container are
  downloaded insecurely over http and then installed with yum
  --nogpgcheck. A man in the middle attacker, web proxy admin, or
  whoever can use this to install arbitrary code in to the container
  which will then get executed as root.

  The GPG keys should probably be shipped as part of the package where
  they are covered by the root of trust for the host distro. Or at the
  very least, https should be used to fetch the RPMs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1661447/+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 1757600] Re: RM: Please port your package away from Qt 4

autopilot-touch is now green in NBS, after that autopilot-qt can be
removed from Ubuntu Archive.

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

Title:
  RM: Please port your package away from Qt 4

Status in autopilot-qt package in Ubuntu:
  Triaged

Bug description:
  Currently Qt 4 has been dead upstream and we are starting to have
  problems maintaining it, like for example in the OpenSSL 1.1 support
  case.

  Following in the footsteps of Debian[1], all packages directly or
  indirectly depending on qt4-x11 (like this one) must either get ported
  to Qt 5 and uploaded to the development release or get removed (by
  means of demotion to -proposed or removal of the package) before the
  19.04 release. If it is possible to port your package by the 18.10
  release, please do so.

  If you have any questions about porting or this transition, please ask
  in #ubuntu-qt (preferred) or directly ping me

  [1] https://wiki.debian.org/Qt4Removal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autopilot-qt/+bug/1757600/+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 1862157] [NEW] dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles

2020-02-06 Thread Thomas Schweikle

Public bug reported:

dnsmasq does in all cases prepend "tftp_root" to tftp-files.

tftp-root=/data/tftp
dhcp-boot=grub/i386-pc/core.0

now have some config files for different subnets:
dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de

Now booting clients within subnet 172.18.1.0/24 will boot grub with:
/data/tftp/grub/i386-pc/core.0

Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
/data/tftp/pxelinux.0

And in subnet 172.18.7.0/24 clients will boot with:
/data/tftp/var/lib/tftpboot/pxelinux.0

and return a "File not found" error.

I'd expected:
172.18.1: grub/i386-pc/core.0   (file found within /data/tftp -- 
without exposing path)
172.18.2: pxelinux.0(file found within /data/tftp -- 
without exposing path)
172.18.3: /pxelinux.0   (file found within /)
172.18.7: /var/lib/tftpboot/pxelinux.0  (file found within 
/var/lib/tftpboot/pxelinux.0)

or even better: some way to set tftp-root for every subnet-config and
having only relative paths to access files regardless of giving absolute
or relative paths.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18
Uname: Linux 4.15.0-87-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.10
Architecture: amd64
Date: Thu Feb  6 11:43:07 2020
InstallationDate: Installed on 2014-01-31 (2197 days ago)
InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 
(20131016)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago)
mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595
mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353

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


** Tags: amd64 apport-bug bionic

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

Title:
  dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  dnsmasq does in all cases prepend "tftp_root" to tftp-files.

  tftp-root=/data/tftp
  dhcp-boot=grub/i386-pc/core.0

  now have some config files for different subnets:
  dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
  dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
  dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de

  Now booting clients within subnet 172.18.1.0/24 will boot grub with:
  /data/tftp/grub/i386-pc/core.0

  Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
  /data/tftp/pxelinux.0

  And in subnet 172.18.7.0/24 clients will boot with:
  /data/tftp/var/lib/tftpboot/pxelinux.0

  and return a "File not found" error.

  I'd expected:
  172.18.1: grub/i386-pc/core.0   (file found within /data/tftp -- 
without exposing path)
  172.18.2: pxelinux.0(file found within /data/tftp -- 
without exposing path)
  172.18.3: /pxelinux.0   (file found within /)
  172.18.7: /var/lib/tftpboot/pxelinux.0  (file found within 
/var/lib/tftpboot/pxelinux.0)

  or even better: some way to set tftp-root for every subnet-config and
  having only relative paths to access files regardless of giving
  absolute or relative paths.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18
  Uname: Linux 4.15.0-87-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.10
  Architecture: amd64
  Date: Thu Feb  6 11:43:07 2020
  InstallationDate: Installed on 2014-01-31 (2197 days ago)
  InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 
(20131016)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago)
  mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595
  mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1862157/+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 1859562] [NEW] Polari doesn't join any chatroom. 'Join' button stays greyed-out (disabled)