[Touch-packages] [Bug 310999]

[Inyiltvv]

Online hotel reservation in Ghasedak 24 is really easy. For doing this,
it is just enough to enter the name of your intended city or hotel as
well as date of arrival and departure in the system and search your
intended accommodation. Then you can filter your list according to
address, cost, hotel class and even available tags in the hotel file and
choose your intended hotel as soon as possible.

https://ghasedak24.com/hotel

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

Title:
  comodo seen issuing certificates unwisely

Status in NSS:
  Fix Released
Status in ca-certificates package in Ubuntu:
  Invalid
Status in nss package in Ubuntu:
  Won't Fix
Status in ca-certificates source package in Dapper:
  Invalid
Status in nss source package in Dapper:
  Won't Fix
Status in ca-certificates source package in Gutsy:
  Invalid
Status in nss source package in Gutsy:
  Won't Fix
Status in ca-certificates source package in Hardy:
  Invalid
Status in nss source package in Hardy:
  Won't Fix
Status in ca-certificates source package in Intrepid:
  Invalid
Status in nss source package in Intrepid:
  Won't Fix
Status in ca-certificates source package in Jaunty:
  Invalid
Status in nss source package in Jaunty:
  Won't Fix

Bug description:
  http://blog.startcom.org/?p=145

  Comodo, or one of its resellers, has been observed selling
  certificates without serious domain control checks or other
  verification.  There should be some consideration for removing the
  impacted CA certificate from ca-certificates and other related
  packages in the near future, considering the possibility of other fake
  certificates.

  I wish the site above had more details, but obviously a 'how to get
  your own cert like this' is just asking for trouble.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nss/+bug/310999/+subscriptions

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

[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

[Utkarsh Gupta]

** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to do
  could be really different from what the outcome turns out to be (because
  of this bug).
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  The SRU would split the variables into respective names, thereby making
  sure that what /etc/default/isc-dhcp-serve sets, is available in the
  respective service file.
  
  [Test Plan]
  
- To reproduce, simply install isc-dhcp-server via apt.
- Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable.
+ To reproduce this bug, simply do the following:
+ 
+ $ lxc launch ubuntu-daily:focal isc-dhcp-lp1894172-focal
+ 
+ $ lxc shell isc-dhcp-lp1894172-focal
+ 
+ # apt update && apt install isc-dhcp-server -y
+ 
+ # grep "INTERFACES" /etc/default/isc-dhcp-server 
+ INTERFACESv4=""
+ INTERFACESv6=""
+ 
+ grep "INTERFACES" /lib/systemd/system/isc-dhcp-server.service
+ exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
+ 
+ # grep "INTERFACES" /lib/systemd/system/isc-dhcp-server6.service
+ exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid 
-cf $CONFIG_FILE $INTERFACES'
+ 
+ 
+ With this, it is clearly visible that even though 
/lib/systemd/system/isc-dhcp-server{,6}.service file uses $INTERFACES variable 
but the /etc/default/isc-dhcp-server defines 2 different variables, 
INTERFACESv4 and INTERFACESv6.
  
  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.
  
  To ensure smooth upgrade of this package, we'd check if the user hasn't
  manually set a INTERFACESv{4,6} variable to workaround this bug. If they
  have, then we simply check and make sure, we use the correct variable.
  
  [Where problems could occur]
  
  The problem could occur if the user has manually set some different
  workaround for this bug and so the usual upgrade could break some of
  their old configuration(s).

** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to do
  could be really different from what the outcome turns out to be (because
  of this bug).
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  

[Touch-packages] [Bug 1917204] Re: VGA stuck at 1024x768 (no EDID detected)

[Daniel van Vugt]

Is this a recent regression (caused by updates) or has it always been
stuck at low resolution?

** Summary changed:

- high Resolution is not getting 
+ VGA stuck at 1024x768 (no EDID detected)

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

** Package changed: linux (Ubuntu) => linux-signed-hwe-5.8 (Ubuntu)

** Summary changed:

- VGA stuck at 1024x768 (no EDID detected)
+ [i915] VGA stuck at 1024x768 (no EDID detected)

** Changed in: linux-signed-hwe-5.8 (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/1917204

Title:
  [i915] VGA stuck at 1024x768 (no EDID detected)

Status in linux-signed-hwe-5.8 package in Ubuntu:
  Incomplete

Bug description:
  I'm not getting my Monitor supporting resolution

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Feb 28 14:40:41 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller 
[8086:0152] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Elitegroup Computer Systems Xeon E3-1200 v2/3rd Gen Core 
processor Graphics Controller [1019:7df5]
  InstallationDate: Installed on 2021-01-20 (38 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  MachineType: ECS H61H2-MV
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-44-generic 
root=UUID=671d72b0-98f0-468f-a72f-910d30b2051a ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/13/2014
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: H61H2-MV
  dmi.board.vendor: ECS
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: ECS
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd08/13/2014:br4.6:svnECS:pnH61H2-MV:pvr1.0:rvnECS:rnH61H2-MV:rvr1.0:cvnECS:ct3:cvr1.0:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: H61H2-MV
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 1.0
  dmi.sys.vendor: ECS
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.8/+bug/1917204/+subscriptions

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

[Touch-packages] [Bug 1890448] Re: hwdb: Add EliteBook to use micmute hotkey

[Kai-Heng Feng]

Same as #6, enable -proposed and dist-upgrade, now the system can map
the atkbd event to micmute hotkey.

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

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

Title:
  hwdb: Add EliteBook to use micmute hotkey

Status in HWE Next:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP EliteBooks don't work.

  [Fix]
  Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.

  [Regression Potential]
  The hwdb originally only matches a few EliteBook, and fix changes that to 
match all EliteBook models. So if there's an EliteBook that uses the scancode 
for other purpose, there will be a regression.
  However, the risk is rather slim because HP is confident that all EliteBooks 
use the same scancode for mic mute hotkey.

  [scope]

  this is needed for f and earlier.

  this is fixed upstream by commit b6eb208b29ae which is included
  starting in v246, so g and later are already fixed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+subscriptions

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

[Touch-packages] [Bug 1915279] Re: about

[Daniel van Vugt]

Can you please attach a screenshot or photo of the problem?

** Package changed: xorg (Ubuntu) => chromium-browser (Ubuntu)

** Changed in: chromium-browser (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/1915279

Title:
  about

Status in chromium-browser package in Ubuntu:
  Incomplete

Bug description:
  all chromium server have heavy issue in render

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.8.0-43.49~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-43-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 10 20:16:29 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Intel Corporation 4 Series Chipset Integrated Graphics Controller 
[8086:2e12] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Dell 4 Series Chipset Integrated Graphics Controller [1028:027f]
 Subsystem: Dell 4 Series Chipset Integrated Graphics Controller [1028:027f]
  InstallationDate: Installed on 2021-02-04 (6 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  MachineType: Dell Inc. OptiPlex 760
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-43-generic 
root=UUID=136e728b-139d-400a-b333-620a8490dd1d ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/06/2013
  dmi.bios.release: 16.0
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A16
  dmi.board.name: 0M858N
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 6
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA16:bd08/06/2013:br16.0:svnDellInc.:pnOptiPlex760:pvr:rvnDellInc.:rn0M858N:rvrA01:cvnDellInc.:ct6:cvr:
  dmi.product.name: OptiPlex 760
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1915279/+subscriptions

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

[Touch-packages] [Bug 1319494] Re: Ubuntu installation image should come with mdadm

[Yuan-Chen Cheng]

** Also affects: oem-priority
   Importance: Undecided
   Status: New

** Changed in: oem-priority
   Status: New => Fix Released

** Changed in: oem-priority
   Importance: Undecided => High

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

Title:
  Ubuntu installation image should come with mdadm

Status in OEM Priority Project:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released

Bug description:
  It would be great if the Ubuntu installation image came with mdadm. If
  was unlucky enough to be Internetless while installing Ubuntu, I
  wouldn't be able to install to or create a RAID array. I know that
  Ubuntu has lessened its restrictions on installation image size, and
  since mdadm's installed size is 1.2MB, I think it should be included.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: ubiquity 2.18.7
  ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  CasperVersion: 1.340
  Date: Wed May 14 17:27:51 2014
  ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
  InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper 
initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity
  InterpreterPath: /usr/bin/python3.4
  LiveMediaBuild: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ubiquity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1319494/+subscriptions

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

[Touch-packages] [Bug 1793472] Re: [wishlist] Add mdadm into desktop by default

[john liptrot]

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

** This bug has been marked a duplicate of bug 1319494
   Ubuntu installation image should come with mdadm

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

Title:
  [wishlist] Add mdadm into desktop by default

Status in OEM Priority Project:
  New
Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  Consider the situation that we have OEM systems with software raid
  devices and the desktop image will be installed on them as primary
  storage. Another work is to patch casper to support md (Please refer
  bug #1793444).

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1793472/+subscriptions

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

[Touch-packages] [Bug 1918328] Re: kernel emits error "Bad value for 'hidepid'" with new systemd on old kernel

[Bug Watch Updater]

** Changed in: systemd
   Status: Unknown => Fix Released

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

Title:
  kernel emits error "Bad value for 'hidepid'" with new systemd on old
  kernel

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

Bug description:
  When using a newer systemd (>=247) and older kernel (<5.8), systemd
  attempts to mount /proc using a value for the 'hidepid' parameter that
  the older kernel doesn't understand, which causes the kernel to emit a
  warning message like:

  [4083297.870684] proc: Bad value for 'hidepid'

  This is harmless, as systemd falls back to the 'old' mount method,
  however the logged error message can be confusing.

  Since there is no ubuntu release where the newer systemd might be
  directly used with a kernel older than 5.8, this can only reasonably
  happen in a container on a older ubuntu release. For example, on a
  focal release with the 5.4 kernel, a hirsute container can be created,
  and when it starts up the host dmesg will log the kernel error
  messages shown above.

  Note that if using a lxd container, as there is a bug where lxd
  prevents mounting any fs (which mostly breaks systemd), you must set
  the 'security.nesting' parameter for the lxd container, e.g.:

  $ lxc launch ubuntu-daily:hirsute test-h
  $ lxc set config test-h security.nesting true

  
  Note that this hasn't been fixed upstream, and as it's purely cosmetic, it's 
possible it won't get fixed upstream.

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

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

[Touch-packages] [Bug 1917625] Re: OpenSSL TLS 1.1 handshake fails internal error

[Brian Murray]

** Tags added: focal rls-ff-incoming

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

Title:
  OpenSSL TLS 1.1 handshake fails internal error

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  OpenSSL's SSL_do_handshake() method fails with
  TLSV1_ALERT_INTERNAL_ERROR when client side has TLS 1.0 to 1.2 enabled
  but server side has only TLS 1.0 and 1.1 enabled. The issue breaks
  Python's test suite for test_ssl. It looks like the problem is caused
  by an Ubuntu downstream patch. Vanilla OpenSSL, Debian, and Fedora are
  not affected.

  A simple reproducer is:

  import ssl
  import socket
  from test.test_ssl import testing_context, ThreadedEchoServer, HOST

  client_context, server_context, hostname = testing_context()
  # client 1.0 to 1.2, server 1.0 to 1.1
  client_context.minimum_version = ssl.TLSVersion.TLSv1
  client_context.maximum_version = ssl.TLSVersion.TLSv1_2
  server_context.minimum_version = ssl.TLSVersion.TLSv1
  server_context.maximum_version = ssl.TLSVersion.TLSv1_1

  with ThreadedEchoServer(context=server_context) as server:
  with client_context.wrap_socket(socket.socket(),
  server_hostname=hostname) as s:
  s.connect((HOST, server.port))
  assert s.version() == 'TLSv1.1'

  
  On Ubuntu 20.04 the code fails with:
  Traceback (most recent call last):
File "/internalerror.py", line 15, in 
  s.connect((HOST, server.port))
File "/usr/lib/python3.8/ssl.py", line 1342, in connect
  self._real_connect(addr, False)
File "/usr/lib/python3.8/ssl.py", line 1333, in _real_connect
  self.do_handshake()
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
  self._sslobj.do_handshake()
  ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error 
(_ssl.c:1123)

  On Debian testing and Fedora 33 the same test passes with out:
   server:  new connection from ('127.0.0.1', 52346)
   server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
   server: selected protocol is now None

  You can find Dockerfiles with reproducers at https://github.com/tiran
  /distro-truststore/tree/main/tests/ubuntu-1899878

  Also see:
  * https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
  * https://bugs.python.org/issue43382
  * https://bugs.python.org/issue41561

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

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

[Touch-packages] [Bug 1918328] Re: kernel emits error "Bad value for 'hidepid'" with new systemd on old kernel

[Dan Streetman]

marking wishlist as 1) it's still not fixed upstream, and 2) it's purely
cosmetic.

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

Title:
  kernel emits error "Bad value for 'hidepid'" with new systemd on old
  kernel

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

Bug description:
  When using a newer systemd (>=247) and older kernel (<5.8), systemd
  attempts to mount /proc using a value for the 'hidepid' parameter that
  the older kernel doesn't understand, which causes the kernel to emit a
  warning message like:

  [4083297.870684] proc: Bad value for 'hidepid'

  This is harmless, as systemd falls back to the 'old' mount method,
  however the logged error message can be confusing.

  Since there is no ubuntu release where the newer systemd might be
  directly used with a kernel older than 5.8, this can only reasonably
  happen in a container on a older ubuntu release. For example, on a
  focal release with the 5.4 kernel, a hirsute container can be created,
  and when it starts up the host dmesg will log the kernel error
  messages shown above.

  Note that if using a lxd container, as there is a bug where lxd
  prevents mounting any fs (which mostly breaks systemd), you must set
  the 'security.nesting' parameter for the lxd container, e.g.:

  $ lxc launch ubuntu-daily:hirsute test-h
  $ lxc set config test-h security.nesting true

  
  Note that this hasn't been fixed upstream, and as it's purely cosmetic, it's 
possible it won't get fixed upstream.

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

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

[Touch-packages] [Bug 1918328] [NEW] kernel emits error "Bad value for 'hidepid'" with new systemd on old kernel

[Dan Streetman]

Public bug reported:

When using a newer systemd (>=247) and older kernel (<5.8), systemd
attempts to mount /proc using a value for the 'hidepid' parameter that
the older kernel doesn't understand, which causes the kernel to emit a
warning message like:

[4083297.870684] proc: Bad value for 'hidepid'

This is harmless, as systemd falls back to the 'old' mount method,
however the logged error message can be confusing.

Since there is no ubuntu release where the newer systemd might be
directly used with a kernel older than 5.8, this can only reasonably
happen in a container on a older ubuntu release. For example, on a focal
release with the 5.4 kernel, a hirsute container can be created, and
when it starts up the host dmesg will log the kernel error messages
shown above.

Note that if using a lxd container, as there is a bug where lxd prevents
mounting any fs (which mostly breaks systemd), you must set the
'security.nesting' parameter for the lxd container, e.g.:

$ lxc launch ubuntu-daily:hirsute test-h
$ lxc set config test-h security.nesting true


Note that this hasn't been fixed upstream, and as it's purely cosmetic, it's 
possible it won't get fixed upstream.

** Affects: systemd
 Importance: Unknown
 Status: Unknown

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

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

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

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

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

Title:
  kernel emits error "Bad value for 'hidepid'" with new systemd on old
  kernel

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

Bug description:
  When using a newer systemd (>=247) and older kernel (<5.8), systemd
  attempts to mount /proc using a value for the 'hidepid' parameter that
  the older kernel doesn't understand, which causes the kernel to emit a
  warning message like:

  [4083297.870684] proc: Bad value for 'hidepid'

  This is harmless, as systemd falls back to the 'old' mount method,
  however the logged error message can be confusing.

  Since there is no ubuntu release where the newer systemd might be
  directly used with a kernel older than 5.8, this can only reasonably
  happen in a container on a older ubuntu release. For example, on a
  focal release with the 5.4 kernel, a hirsute container can be created,
  and when it starts up the host dmesg will log the kernel error
  messages shown above.

  Note that if using a lxd container, as there is a bug where lxd
  prevents mounting any fs (which mostly breaks systemd), you must set
  the 'security.nesting' parameter for the lxd container, e.g.:

  $ lxc launch ubuntu-daily:hirsute test-h
  $ lxc set config test-h security.nesting true

  
  Note that this hasn't been fixed upstream, and as it's purely cosmetic, it's 
possible it won't get fixed upstream.

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

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

[Touch-packages] [Bug 1915966] Re: Please merge initramfs-tools 0.139 from Debian unstable

[Dimitri John Ledkov]

** Changed in: initramfs-tools (Ubuntu)
   Status: New => 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/1915966

Title:
  Please merge initramfs-tools 0.139 from Debian unstable

Status in initramfs-tools package in Ubuntu:
  Fix Committed

Bug description:
  Please merge initramfs-tools 0.139 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  shortly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1915966/+subscriptions

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

[Touch-packages] [Bug 1915966] Re: Please merge initramfs-tools 0.139 from Debian unstable

[Dimitri John Ledkov]

> git range-diff old/debian..logical/0.137ubuntu12
new/debian..merge/0.139ubuntu1

i see this and i have no clue what i am looking at!

i guess i need to go and learn how to read range-diffs!

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

Title:
  Please merge initramfs-tools 0.139 from Debian unstable

Status in initramfs-tools package in Ubuntu:
  Fix Committed

Bug description:
  Please merge initramfs-tools 0.139 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  shortly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1915966/+subscriptions

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

[Touch-packages] [Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04

[Kurt Roeckx]

There are 3 things that can possibly returned by such a function:
1) The value that's set as minimum/maximum
2) The minimum and maximum version that's supported by the library, not 
depending on settings
3) The minimum and maximum version that's supported by the library, depending 
on current settings

The function now does 1), and you seem to want 3). And I'm not sure it's
a good idea to change the function, I would prefer a new function.

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

Title:
  Python's test_ssl fails starting from Ubuntu 20.04

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Please take a look at https://bugs.python.org/issue41561. Developers
  who work on Python think that the issue is due to a change in Ubuntu
  20.04 that is best described by
  https://bugs.python.org/issue41561#msg378089:

  "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did
  somebody report the bug with Debian/Ubuntu maintainers of OpenSSL
  already? Fedora also configures OpenSSL with minimum protocol version
  of TLS 1.2. The distribution does it in a slightly different way that
  makes the restriction discoverable and that is compatible with
  Python's test suite."

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

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

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Dimitri John Ledkov]

The nat fiddles are not visible inside the container network namespace.
Thus I am wondering if there is an odd interaction between namespace,
nftables based iptables vs legacy iptables. I.e. whilst the host is
configured using legacy iptables, maybe the lxd guests must be using
legacy iptables too.

I'll experiment to see if forcing to simply only use iptables-legacy
inside the lxd guest is good enough for now. Despite the hosts getting
upgraded to bionic. Cause it's only groovy that started to use nftables
based iptables.

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in launchpad-buildd:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Launchpad Bug Tracker]

** Merge proposal linked:
   
https://code.launchpad.net/~xnox/livecd-rootfs/+git/livecd-rootfs/+merge/399383

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in launchpad-buildd:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1913423] Re: getgrouplist is not thread safe with libnss_systemd

[Dan Streetman]

also verified on bionic no assertion failure with the -proposed systemd

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

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

Title:
  getgrouplist is not thread safe with libnss_systemd

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

Bug description:
  [impact]

  programs calling getgrouplist() may crash as it is not thread-safe

  [test case]

  see upstream bug description for sample c program to reproduce:
  https://github.com/systemd/systemd/issues/17007#issue-698123284

  [regression potential]

  any regression would likely occur when creating a hashmap in systemd,
  or when any multi-threaded programs concurrently create (and use) the
  hashmap

  [scope]

  this is needed for f and b

  this is fixed upstream by commit
  ae0b700a856c0ae460d271bb50dccfaae84dbcab, already included in g/h (per
  comment 1).

  [original description]

  This upstream issue (https://github.com/systemd/systemd/issues/17007)
  is affecting the latest version of systemd in Ubuntu Focal. It has
  been fixed upstream with
  https://github.com/systemd/systemd/pull/17033. Can we have this
  patched for Focal please as it causes Mesos to randomly segfault on
  start.

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

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

[Touch-packages] [Bug 1902553] Re: TEST-03 sometimes fails during autopkgtests

[Dan Streetman]

TEST-03 passed in autopkgtest run, so marking as verified.

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

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

Title:
  TEST-03 sometimes fails during autopkgtests

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

Bug description:
  [impact]

  during autopkgtest runs, sometimes TEST-03 fails when running under
  qemu.

  [test case]

  check autopkgtest results, e.g.:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/s/systemd/20201009_025713_c1956@/log.gz

  [regression potential]

  any regression would likely result in a failure to detect some other
  regression that is otherwise tested by this test case.

  [scope]

  this is needed only for bionic.

  upstream, this is fixed by disabling TEST-03 (and TEST-16) running
  under qemu, as their timing is very tight, in commit
  3edc0c590d3a9212267d0a7cf56e95efa7f61039, which is included first in
  v239, so this is fixed already in focal and later.

  technically, this also is needed for xenial, however since that
  release is reaching ESM status early next year, and this is only an
  autopkgtest fix, i have no plans to update xenial.

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

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

[Touch-packages] [Bug 1913423] Re: getgrouplist is not thread safe with libnss_systemd

[Dan Streetman]

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

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

Title:
  getgrouplist is not thread safe with libnss_systemd

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

Bug description:
  [impact]

  programs calling getgrouplist() may crash as it is not thread-safe

  [test case]

  see upstream bug description for sample c program to reproduce:
  https://github.com/systemd/systemd/issues/17007#issue-698123284

  [regression potential]

  any regression would likely occur when creating a hashmap in systemd,
  or when any multi-threaded programs concurrently create (and use) the
  hashmap

  [scope]

  this is needed for f and b

  this is fixed upstream by commit
  ae0b700a856c0ae460d271bb50dccfaae84dbcab, already included in g/h (per
  comment 1).

  [original description]

  This upstream issue (https://github.com/systemd/systemd/issues/17007)
  is affecting the latest version of systemd in Ubuntu Focal. It has
  been fixed upstream with
  https://github.com/systemd/systemd/pull/17033. Can we have this
  patched for Focal please as it causes Mesos to randomly segfault on
  start.

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

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

[Touch-packages] [Bug 1883447] Re: nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers

[Dan Streetman]

root@test:~/f# dpkg -l|grep systemd-container
ii  systemd-container  237-3ubuntu10.44armhf
systemd container/nspawn tools
root@test:~/f# systemd-nspawn
Spawning container f on /root/f.
Press ^] three times within 1s to kill container.
root@f:~# python3
Fatal Python error: pyinit_main: can't initialize time
Python runtime state: core initialized
PermissionError: [Errno 1] Operation not permitted

Current thread 0xf7aea310 (most recent call first):



root@test:~/f# dpkg -l|grep systemd-container
ii  systemd-container  237-3ubuntu10.45armhf
systemd container/nspawn tools
root@test:~/f# systemd-nspawn
Spawning container f on /root/f.
Press ^] three times within 1s to kill container.
root@f:~# python3
Python 3.8.5 (default, Jan 27 2021, 15:41:15) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 


** Description changed:

  [impact]
  
  nspawn fails on armhf
  
  [test case]
  
- setup a bionic armhf system, and get a focal img/filesystem to use with
- systemd-nspawn, e.g.
+ setup a bionic armhf system (note that if lxd is used to setup armhf
+ container under arm64 system, the armhf container must have
+ 'security.nesting' set to true) and get a focal img/filesystem to use
+ with systemd-nspawn, e.g.
  
  $ wget 
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-armhf-root.tar.xz
  $ mkdir f
  $ cd f
  $ tar xvf ../focal-server-cloudimg-armhf-root.tar.xz
  
  install systemd-container, and start nspawn; then test anything that
  uses the time, e.g. just run python:
  
  $ systemd-nspawn
  Spawning container f on /root/f.
  Press ^] three times within 1s to kill container.
  root@f:~# python3
  Fatal Python error: pyinit_main: can't initialize time
  Python runtime state: core initialized
  PermissionError: [Errno 1] Operation not permitted
  
  Current thread 0xf7bbd310 (most recent call first):
  
  
  [regression potential]
  
  any regression would likely break nspawn creation or operation of
  containers, particularly on armhf, but possibly on other archs
  
  [scope]
  
  this is needed only in bionic.
  
  this is fixed upstream by commit
  6ca677106992321326427c89a40e1c9673a499b2 which was included first in
  v244, so this is fixed already in focal and later.
  
  [original description]
  
  Recent Linux kernels introduced a number of new syscalls ending in
  _time64 to fix Y2038 problem; it appears recent glibc, including the
  version in focal, test for the existence of these. systemd-nspawn in
  bionic (237-3ubuntu10.38) doesn't know about these so blocks them by
  default. It seems however glibc isn't expecting an EPERM, causing
  numerous programs to fail.
  
  In particular, running do-release-upgrade to focal in an nspawn
  container hosted on bionic will break as soon as the new libc has been
  unpacked.
  
  Solution (tested here) is to cherrypick upstream commit
  
https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2
  
  A newer libseccomp is also needed but this is already being worked on,
  see bug #1876055.
  
  It's a pretty trivial fix one the new libseccomp lands, and there is
  precedent for SRU-ing for a similar issue in bug #1840640.
  
  https://patchwork.kernel.org/patch/10756415/ is apparently the upstream
  kernel patch, which should give a clearer idea of which architectures
  are likely to be affected - I noticed it on armhf.

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

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

Title:
  nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to
  focal in containers

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

Bug description:
  [impact]

  nspawn fails on armhf

  [test case]

  setup a bionic armhf system (note that if lxd is used to setup armhf
  container under arm64 system, the armhf container must have
  'security.nesting' set to true) and get a focal img/filesystem to use
  with systemd-nspawn, e.g.

  $ wget 
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-armhf-root.tar.xz
  $ mkdir f
  $ cd f
  $ tar xvf ../focal-server-cloudimg-armhf-root.tar.xz

  install systemd-container, and start nspawn; then test anything that
  uses the time, e.g. just run python:

  $ systemd-nspawn
  Spawning container f on /root/f.
  Press ^] three times within 1s to kill container.
  root@f:~# python3
  Fatal Python error: pyinit_main: can't initialize time
  Python runtime state: core initialized
  PermissionError: [Errno 1] Operation not permitted

  Current thread 0xf7bbd310 (most recent call first):
  

  

[Touch-packages] [Bug 1890448] Re: hwdb: Add EliteBook to use micmute hotkey

[Dan Streetman]

@kaihengfeng can you verify this for 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/1890448

Title:
  hwdb: Add EliteBook to use micmute hotkey

Status in HWE Next:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP EliteBooks don't work.

  [Fix]
  Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.

  [Regression Potential]
  The hwdb originally only matches a few EliteBook, and fix changes that to 
match all EliteBook models. So if there's an EliteBook that uses the scancode 
for other purpose, there will be a regression.
  However, the risk is rather slim because HP is confident that all EliteBooks 
use the same scancode for mic mute hotkey.

  [scope]

  this is needed for f and earlier.

  this is fixed upstream by commit b6eb208b29ae which is included
  starting in v246, so g and later are already fixed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+subscriptions

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

[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

[Utkarsh Gupta]

** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
- CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
- if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
- [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
- chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
- chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
- exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
+ CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
+ if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
+ [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
+ chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
+ chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
+ exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
+ 
+ This causes the service to listen on all interfaces, which is what the
+ user might not want. In case the user wants to use *only* IPv6 and not
+ IPv4, this could maybe lead to problems as what the user intended to do
+ and what the outcome turns out because of this bug could be really
+ different.
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  The SRU would split the variables into respective names, thereby making
  sure that what /etc/default/isc-dhcp-serve sets, is available in the
  respective service file.
  
- 
  [Test Plan]
  
  To reproduce, simply install isc-dhcp-server via apt.
- Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable. 
+ Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable.
  
  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.
  
  To ensure smooth upgrade of this package, we'd check if the user hasn't
  manually set a INTERFACESv{4,6} variable to workaround this bug. If they
  have, then we simply check and make sure, we use the correct variable.
  
- 
  [Where problems could occur]
  
  The problem could occur if the user has manually set some different
  workaround this bug and so the usual upgrade could break some of their
  old configuration.

** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to do
- and what the outcome turns out because of this bug could be really
- different.
+ could be really different from what the outcome turns out to be (because
+ of this bug).
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  The SRU would split the variables into 

[Touch-packages] [Bug 1880258] Re: Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise

[Dan Streetman]

root@lp1880258-b:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.44 amd64system and service manager
root@lp1880258-b:~# host jifaslrjfiudrlj.com
Host jifaslrjfiudrlj.com not found: 3(NXDOMAIN)
root@lp1880258-b:~# journalctl -b -u systemd-resolved | grep NXDOMAIN
Mar 09 18:15:29 lp1880258-b systemd-resolved[786]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.
Mar 09 18:25:51 lp1880258-b systemd-resolved[786]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.


(upgrade/reboot)

root@lp1880258-b:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.45 amd64system and service manager
root@lp1880258-b:~# host jifaslrjfiudrlj.com
Host jifaslrjfiudrlj.com not found: 3(NXDOMAIN)
root@lp1880258-b:~# journalctl -b -u systemd-resolved | grep NXDOMAIN
root@lp1880258-b:~# 


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

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

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

Title:
  Add trailing dot to make connectivity-check.ubuntu.com. absolute and
  reduce NXDOMAIN warning noise

Status in network-manager package in Ubuntu:
  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 Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in network-manager source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  systemd-resolved emits a disturbingly large amount of NXDOMAIN log
  messages that do not actually indicate any real problem

  [test case]

  see original description, or look at any log from any recent Ubuntu
  system, or search google for endless complaints about NXDOMAIN
  messages logged by Ubuntu

  [regression potential]

  any regression would likely be isolated to systemd-resolved handling
  of a NXDOMAIN response from its upstream nameserver, including
  possibly failing to resolve a hostname or delays in resolving
  hostnames

  [scope]

  this is needed for all releases; the patch is not upstream, but
  carried by Ubuntu

  [original description]

  I normally don't like this, but it's a one-character change so it's
  easier to start with the solution:

  diff -u -r1.1 /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  --- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  +++ /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  @@ -1,2 +1,2 @@
   [connectivity]
  -uri=http://connectivity-check.ubuntu.com/
  +uri=http://connectivity-check.ubuntu.com./

  Making this name absolute instead of relative avoids spurious
  resolutions of "connectivity-check.ubuntu.com.your_domain." This
  removes a fair amount of NXDOMAIN error noise in journalctl.

  Observing the issue and the fix requires 3 terminals:

  1. tcpdump -i any 'port domain'
  2. journalctl --boot -u systemd-resolved -f

  3. nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe the NXDOMAIN noise over a couple few minutes

  Now make the hostname absolute with the trailing dot above and run:
     systemctl reload NetworkManager
  Wait 1 min for things to stabilize. Test again:

  nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe non-zero but significantly reduced NXDOMAIN noise over a couple 
few minutes

  Originally reported at https://askubuntu.com/a/1242611/117217

  Plenty of people annoyed by NXDOMAIN warnings, just Google it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1880258/+subscriptions

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

[Touch-packages] [Bug 1880258] Re: Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise

[Dan Streetman]

root@lp1880258-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.4 amd64system and service manager
root@lp1880258-f:~# host gfjrisldfjrfj.com
Host gfjrisldfjrfj.com not found: 3(NXDOMAIN)
root@lp1880258-f:~# journalctl -b -u systemd-resolved | grep NXDOMAIN
Mar 09 18:15:29 lp1880258-f systemd-resolved[624]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.
Mar 09 18:24:39 lp1880258-f systemd-resolved[624]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.
Mar 09 18:24:49 lp1880258-f systemd-resolved[624]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.


(upgrade and reboot)

root@lp1880258-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.5 amd64system and service manager
root@lp1880258-f:~# host gfjrisldfjrfj.com
Host gfjrisldfjrfj.com not found: 3(NXDOMAIN)
root@lp1880258-f:~# journalctl -b -u systemd-resolved | grep NXDOMAIN
root@lp1880258-f:~#

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

Title:
  Add trailing dot to make connectivity-check.ubuntu.com. absolute and
  reduce NXDOMAIN warning noise

Status in network-manager package in Ubuntu:
  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 Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in network-manager source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  systemd-resolved emits a disturbingly large amount of NXDOMAIN log
  messages that do not actually indicate any real problem

  [test case]

  see original description, or look at any log from any recent Ubuntu
  system, or search google for endless complaints about NXDOMAIN
  messages logged by Ubuntu

  [regression potential]

  any regression would likely be isolated to systemd-resolved handling
  of a NXDOMAIN response from its upstream nameserver, including
  possibly failing to resolve a hostname or delays in resolving
  hostnames

  [scope]

  this is needed for all releases; the patch is not upstream, but
  carried by Ubuntu

  [original description]

  I normally don't like this, but it's a one-character change so it's
  easier to start with the solution:

  diff -u -r1.1 /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  --- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  +++ /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  @@ -1,2 +1,2 @@
   [connectivity]
  -uri=http://connectivity-check.ubuntu.com/
  +uri=http://connectivity-check.ubuntu.com./

  Making this name absolute instead of relative avoids spurious
  resolutions of "connectivity-check.ubuntu.com.your_domain." This
  removes a fair amount of NXDOMAIN error noise in journalctl.

  Observing the issue and the fix requires 3 terminals:

  1. tcpdump -i any 'port domain'
  2. journalctl --boot -u systemd-resolved -f

  3. nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe the NXDOMAIN noise over a couple few minutes

  Now make the hostname absolute with the trailing dot above and run:
     systemctl reload NetworkManager
  Wait 1 min for things to stabilize. Test again:

  nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe non-zero but significantly reduced NXDOMAIN noise over a couple 
few minutes

  Originally reported at https://askubuntu.com/a/1242611/117217

  Plenty of people annoyed by NXDOMAIN warnings, just Google it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1880258/+subscriptions

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

[Touch-packages] [Bug 1880258] Re: Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise

[Dan Streetman]

fixed in hirsute with:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=299002546ec2d62e7f0dd7d614ba958fc9df83c2

at version 247.3-1ubuntu4

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

Title:
  Add trailing dot to make connectivity-check.ubuntu.com. absolute and
  reduce NXDOMAIN warning noise

Status in network-manager package in Ubuntu:
  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 Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in network-manager source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  systemd-resolved emits a disturbingly large amount of NXDOMAIN log
  messages that do not actually indicate any real problem

  [test case]

  see original description, or look at any log from any recent Ubuntu
  system, or search google for endless complaints about NXDOMAIN
  messages logged by Ubuntu

  [regression potential]

  any regression would likely be isolated to systemd-resolved handling
  of a NXDOMAIN response from its upstream nameserver, including
  possibly failing to resolve a hostname or delays in resolving
  hostnames

  [scope]

  this is needed for all releases; the patch is not upstream, but
  carried by Ubuntu

  [original description]

  I normally don't like this, but it's a one-character change so it's
  easier to start with the solution:

  diff -u -r1.1 /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  --- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  +++ /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  @@ -1,2 +1,2 @@
   [connectivity]
  -uri=http://connectivity-check.ubuntu.com/
  +uri=http://connectivity-check.ubuntu.com./

  Making this name absolute instead of relative avoids spurious
  resolutions of "connectivity-check.ubuntu.com.your_domain." This
  removes a fair amount of NXDOMAIN error noise in journalctl.

  Observing the issue and the fix requires 3 terminals:

  1. tcpdump -i any 'port domain'
  2. journalctl --boot -u systemd-resolved -f

  3. nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe the NXDOMAIN noise over a couple few minutes

  Now make the hostname absolute with the trailing dot above and run:
     systemctl reload NetworkManager
  Wait 1 min for things to stabilize. Test again:

  nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe non-zero but significantly reduced NXDOMAIN noise over a couple 
few minutes

  Originally reported at https://askubuntu.com/a/1242611/117217

  Plenty of people annoyed by NXDOMAIN warnings, just Google it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1880258/+subscriptions

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

[Touch-packages] [Bug 1685754] Re: 'systemd --user' unduly forces umask=0022

[Dan Streetman]

(commands below run from graphical window)


ubuntu@lp1685754-b:~$ dpkg -l systemd |grep systemd
ii  systemd237-3ubuntu10.44 amd64system and service manager
ubuntu@lp1685754-b:~$ grep umask /etc/passwd
ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash
ubuntu@lp1685754-b:~$ umask
0022


ubuntu@lp1685754-b:~$ dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.45 amd64system and service manager
ubuntu@lp1685754-b:~$ grep umask /etc/passwd
ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash
ubuntu@lp1685754-b:~$ umask
0007


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

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

Title:
  'systemd --user' unduly forces umask=0022

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

Bug description:
  [impact]

  pam_umask, from /etc/passwd, is not honored in systemd --user
  instances

  [test case]

  on a desktop system, edit /etc/passwd to change the test user entry
  (e.g. the 'ubuntu' user) to include 'umask=007' in the GECOS field
  (5th field). For example change:

  ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash

  to:

  ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash

  You may need to reboot for your X session to pick up the change.

  Then, from the graphical desktop, open a terminal and run:

  $ gnome-terminal -e sh

  in the opened terminal, run:

  $ umask

  the number shown should be 0007, as set in the passwd file

  [regression potential]

  any regression would likely result in an incorrect umask for the user
  whose passwd entry is modified.

  [scope]

  this is needed only for b

  this is fixed in systemd upstream by commit
  5e37d1930b41b24c077ce37c6db0e36c745106c7 which was first included in
  v246, so this is fixed in g and later. This commit was also picked up
  by Debian and included in the v245 release for focal, so this is fixed
  in focal already.

  [original description]

  In order to set the default umask of my users to 027 or 007, I
  followed the instructions provided in 'man pam_umask' :

  In the 'gecos' field of '/etc/passwd', I have inserted 'umask=027' or
  'umask=007' (for myself).

  Then, MOST graphical applications systematically run with the correct
  umask.

  In particular, when I press Alt-F2, run 'xterm sh' and type 'umask',
  it systematically displays 0007.

  But when I press Alt-F2, run 'gnome-terminal -e sh' and type 'umask',
  it systematically displays 0022.

  That is BAD, and is a security issue.

  Workaround :  Inside the newly created '/etc/profile.d/umask.sh', and in each 
'~/.bashrc', add following content :
  UMASK="$(grep  -o  "^$USER:.*,umask=0[0-7]*"  /etc/passwd)"
  if  [ "$UMASK" ];  then
    umask  "${UMASK#$USER:*,umask=}"
  fi

  In fact, 'gnome-terminal' MUST NOT force umask=022, but keep umask
  unchanged.

  Thank you in advance for a quick correction.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: gnome-terminal 3.20.2-1ubuntu8
  ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
  Uname: Linux 4.10.0-19-generic x86_64
  ApportVersion: 2.20.4-0ubuntu4
  Architecture: amd64
  CurrentDesktop: X-Cinnamon
  Date: Mon Apr 24 08:36:58 2017
  InstallationDate: Installed on 2017-03-28 (26 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Beta amd64 (20170321)
  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/1685754/+subscriptions

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

[Touch-packages] [Bug 1880258] Re: Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise

[Dan Streetman]

with -release version of systemd:

root@lp1880258-g:~# host afhjisrfljsdirfj.com
Host afhjisrfljsdirfj.com not found: 3(NXDOMAIN)

root@lp1880258-g:~# journalctl -b -u systemd-resolved --no-pager
...
Mar 09 18:07:46 lp1880258-g systemd-resolved[624]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.
Mar 09 18:09:11 lp1880258-g systemd-resolved[624]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.
Mar 09 18:09:14 lp1880258-g systemd-resolved[624]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.



root@lp1880258-g:~# dpkg -l systemd|grep systemd
ii  systemd246.6-1ubuntu1.2 amd64system and service manager
root@lp1880258-g:~# host afhjisrfljsdirfj.com
Host afhjisrfljsdirfj.com not found: 3(NXDOMAIN)
root@lp1880258-g:~# host afhjisrfljsdirfj.com
Host afhjisrfljsdirfj.com not found: 3(NXDOMAIN)
root@lp1880258-g:~# host afhjisrfljsdirfj.com
Host afhjisrfljsdirfj.com not found: 3(NXDOMAIN)
root@lp1880258-g:~# journalctl -b -u systemd-resolved --no-pager | grep NXDOMAIN
root@lp1880258-g:~# 



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

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

Title:
  Add trailing dot to make connectivity-check.ubuntu.com. absolute and
  reduce NXDOMAIN warning noise

Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in network-manager source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  systemd-resolved emits a disturbingly large amount of NXDOMAIN log
  messages that do not actually indicate any real problem

  [test case]

  see original description, or look at any log from any recent Ubuntu
  system, or search google for endless complaints about NXDOMAIN
  messages logged by Ubuntu

  [regression potential]

  any regression would likely be isolated to systemd-resolved handling
  of a NXDOMAIN response from its upstream nameserver, including
  possibly failing to resolve a hostname or delays in resolving
  hostnames

  [scope]

  this is needed for all releases; the patch is not upstream, but
  carried by Ubuntu

  [original description]

  I normally don't like this, but it's a one-character change so it's
  easier to start with the solution:

  diff -u -r1.1 /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  --- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  +++ /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  @@ -1,2 +1,2 @@
   [connectivity]
  -uri=http://connectivity-check.ubuntu.com/
  +uri=http://connectivity-check.ubuntu.com./

  Making this name absolute instead of relative avoids spurious
  resolutions of "connectivity-check.ubuntu.com.your_domain." This
  removes a fair amount of NXDOMAIN error noise in journalctl.

  Observing the issue and the fix requires 3 terminals:

  1. tcpdump -i any 'port domain'
  2. journalctl --boot -u systemd-resolved -f

  3. nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe the NXDOMAIN noise over a couple few minutes

  Now make the hostname absolute with the trailing dot above and run:
     systemctl reload NetworkManager
  Wait 1 min for things to stabilize. Test again:

  nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe non-zero but significantly reduced NXDOMAIN noise over a couple 
few minutes

  Originally reported at https://askubuntu.com/a/1242611/117217

  Plenty of people annoyed by NXDOMAIN warnings, just Google it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1880258/+subscriptions

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

[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Dan Streetman]

> Would using PPA from comment 19 be as limited as PPA from comment 8
> (systemd only, without messing with other packages)?

It's only systemd and debhelper version 13, but I understand if you
don't want to install on your system, as the build from that ppa is
completely untested (it's just a daily build of upstream systemd code).
I would not recommend installing it on a system that you aren't ok with
breaking.

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

Title:
  systemd-resolve crashes fairly often (and reports various assertions)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  systemd-resolved crashes

  [test case]

  see original description; I can't reproduce so I'm relying on the
  reporter(s) to test/verify.

  [regression potential]

  any regression would likely occur while processing sd_event objects,
  which are used throughout systemd code; this could result in crashes
  in almost any part of systemd code. However a more likely regression
  would be leaks of sd_event objects due to failure to release the final
  ref for an object.

  [scope]

  This is needed for f/g/h

  This might be fixed by upstream commit
  f814c871e65df8552a055dd887bc94b074037833; if so, that commit isn't
  included in any systemd release yet, and so is needed in h and
  earlier.

  [other info]

  I believe this is caused by a freed sd_event object that is then
  processed and calls the on_query_timeout callback with invalid state,
  leading to failed assertion, which causes resolved to crash; that's
  what analysis of the crash dump appears to indicate. This may be fixed
  by the upstream commit referenced in [scope], which takes additional
  refs during function calls. However I haven't reproduced this myself,
  so I'm only guessing as to the cause and solution at this point.

  I'm unsure why this would not occur in bionic, but per comment 5 it
  seems it doesn't happen in that release.

  [original description]

  (Tested on regularly updated Ubuntu 20.04, currently i use systemd
  245.4-4ubuntu3.2)

  I observe fairly lot of segfaults of systemd-resolve. Frequency vary
  but … see below.

  I have no clue what is the reason. Specific feature of my machine is
  that apart from normal cable connection (to OpenWRT router) I use
  OpenVPN for business network (and this submits specific nameserver for
  myorg.local domain).

  ~
  $ LC_ALL=C dmesg -T --level=info | grep systemd-resolve
  [Sun Nov 29 11:47:37 2020] systemd-resolve[1629307]: segfault at 190eed7bdc6 
ip 7fd98f771dc9 sp 7ffc2352a100 error 4 in 
libsystemd-shared-245.so[7fd98f74c000+16e000]
  [Sun Nov 29 11:57:27 2020] systemd-resolve[1629787]: segfault at 1f ip 
55ab7b0cb686 sp 7fff78ce4bd0 error 4 in 
systemd-resolved[55ab7b0a4000+3e000]
  [Sun Nov 29 12:07:37 2020] systemd-resolve[1630481]: segfault at 191 ip 
55ca69fed91c sp 7ffc4d757dc0 error 6 in 
systemd-resolved[55ca69fc2000+3e000]
  [Sun Nov 29 13:12:26 2020] systemd-resolve[1638829]: segfault at 19224162371 
ip 7fc1bc9b9dc9 sp 7ffc21378170 error 4 in 
libsystemd-shared-245.so[7fc1bc994000+16e000]
  [Sun Nov 29 13:32:57 2020] systemd-resolve[1639886]: segfault at 1926d8126d3 
ip 7f7ed17e9dc9 sp 7ffda2cea0b0 error 4 in 
libsystemd-shared-245.so[7f7ed17c4000+16e000]
  [Sun Nov 29 13:42:37 2020] systemd-resolve[1640246]: segfault at 61 ip 
558d992e2686 sp 7fff08906af0 error 4 in 
systemd-resolved[558d992bb000+3e000]
  [Sun Nov 29 15:42:26 2020] systemd-resolve[1645397]: segfault at 1943c92afc7 
ip 7fd4c1721dc9 sp 7fff25259ce0 error 4 in 
libsystemd-shared-245.so[7fd4c16fc000+16e000]
  [Sun Nov 29 16:02:36 2020] systemd-resolve[1646052]: segfault at 1947ecb3726 
ip 7f1008549dc9 sp 7fff44a6db70 error 4 in 
libsystemd-shared-245.so[7f1008524000+16e000]
  [Sun Nov 29 17:42:35 2020] systemd-resolve[1649403]: segfault at 71 ip 
55a37fe5a686 sp 7ffd9a160440 error 4 in 
systemd-resolved[55a37fe33000+3e000]
  [Sun Nov 29 17:52:35 2020] systemd-resolve[1649759]: segfault at 558d292947d0 
ip 558d292947d0 sp 7ffec7ab3bf8 error 15
  [Sun Nov 29 19:17:55 2020] systemd-resolve[1652349]: segfault at 558995b77cf0 
ip 558995b77cf0 sp 7ffe545ae4a8 error 15
  [Sun Nov 29 19:32:35 2020] systemd-resolve[1652640]: segfault at 19773c20194 
ip 7f66bb529dc9 sp 7fffd7066fc0 error 4 in 
libsystemd-shared-245.so[7f66bb504000+16e000]
  [Sun Nov 29 20:03:54 2020] systemd-resolve[1653715]: segfault at 197e3aee918 
ip 7fdc40b51dc9 sp 7ffde484fbf0 error 4 in 
libsystemd-shared-245.so[7fdc40b2c000+16e000]
  [Sun Nov 29 20:22:24 2020] systemd-resolve[1654540]: segfault at 19820a05297 
ip 

[Touch-packages] [Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04

[Christian Heimes]

Actually, I don't want to enable TLS 1.0 and 1.1 when these versions are
disabled by crypto policy or openssl.cnf. It's totally ok that these
versions are disabled and don't work any more! I just need a reliable
way to *detect* that the versions are disabled at runtime.

The feature detection logic boils down to this pseudo code:

min_version = SSL_CTX_get_min_proto_version(ctx)
if not defined(TLS1_VERSION) or defined(OPENSSL_NO_TLS1):
return False
elif min_version == 0 or min_version >= TLS1_VERSION:
return True
else:
return False

On Debian, SSL_CTX_get_min_proto_version() returns TLS1_2_VERSION and
Python considers TLS 1.0 and 1.1 as disabled by system policy. All test
cases for TLS 1.0 and TLS 1.1 are skipped.

Ubuntu has TLS1_VERSION defined, OPENSSL_NO_TLS1 not defined, and
SSL_CTX_get_min_proto_version() returns 0. So Python assumes that TLS
1.0 is compiled in, supported, and enabled. But it's actually disabled
and tests are failing.

I completely agree with your comment 13: 0 is not a good return value.
Could you modify Ubuntu's patch so that
SSL_CTX_get_min_proto_version(ctx) returns TLS1_2_VERSION and
SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION) returns an error? This
would fix Python's problem.

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

Title:
  Python's test_ssl fails starting from Ubuntu 20.04

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Please take a look at https://bugs.python.org/issue41561. Developers
  who work on Python think that the issue is due to a change in Ubuntu
  20.04 that is best described by
  https://bugs.python.org/issue41561#msg378089:

  "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did
  somebody report the bug with Debian/Ubuntu maintainers of OpenSSL
  already? Fedora also configures OpenSSL with minimum protocol version
  of TLS 1.2. The distribution does it in a slightly different way that
  makes the restriction discoverable and that is compatible with
  Python's test suite."

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

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

[Touch-packages] [Bug 1884024] Re: lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4

[Ian]

** Tags added: sru-20210222

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

Title:
  lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Committed

Bug description:
  Issue found on with 5.4.0-1016.16~18.04.1-oracle on both
  VM.Standard2.1 and VM.Standard2.16

  Test failed with:
   FAIL: lxc-tests: lxc-test-device-add-remove (1s)
   ---
   Adding /dev/network_latency to the container (device_add_remove_test) 
failed...

  This issue can be found on oracle : 5.4.0-1011.11~18.04.1 on
  VM.Standard2.16 but passed on VM.Standard2.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1884024/+subscriptions

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

[Touch-packages] [Bug 1318635] Re: qtbase failed to build on arm64 on utopic

[Matthias Klose]

utopic is EOL, closing the issue

** Changed in: gcc-defaults (Ubuntu)
   Status: Confirmed => Invalid

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

Title:
  qtbase failed to build on arm64 on utopic

Status in gcc-defaults package in Ubuntu:
  Invalid
Status in qtbase-opensource-src package in Ubuntu:
  Fix Released

Bug description:
  The latest qtbase upload:
  
https://launchpad.net/ubuntu/utopic/+source/qtbase-opensource-src/5.2.1+dfsg-1ubuntu16

  failed to build on arm64:
  ---
  gcc -c -include .pch/Qt5Core -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-O2 -fvisibility=hidden -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV 
-DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT 
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT 
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS 
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DELF_INTERPRETER=\"/lib/ld-linux-aarch64.so.1\" -DQT_USE_ICU 
-DPCRE_HAVE_CONFIG_H -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-DQT_NO_DEBUG -I../../mkspecs/linux-g++ -I. -I../../include 
-I../../include/QtCore -I../../include/QtCore/5.2.1 
-I../../include/QtCore/5.2.1/QtCore -Iglobal -I../3rdparty/pcre 
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 
-I../3rdparty/sha3 -I.moc -o .obj/pcre16_jit_compile.o 
../3rdparty/pcre/pcre16_jit_compile.c
  gcc: internal compiler error: Segmentation fault (program cc1)
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  Makefile:19974: recipe for target '.obj/pcre16_fullinfo.o' failed
  ---

  The previous build on utopic was fine, and a trusty build with the
  same patch as ubuntu16 built ok.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1318635/+subscriptions

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

[Touch-packages] [Bug 1403758] Re: Unity8 shows black screen with Qt 5.4.0

[Matthias Klose]

the binutils issues is fixed upstream. closing the binutils task.

** Changed in: binutils (Ubuntu)
   Status: Incomplete => Fix Released

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

Title:
  Unity8 shows black screen with Qt 5.4.0

Status in binutils:
  Unknown
Status in binutils package in Ubuntu:
  Fix Released
Status in gcc-defaults package in Ubuntu:
  Incomplete
Status in qtbase-opensource-src package in Ubuntu:
  Fix Released
Status in ubuntu-ui-toolkit package in Ubuntu:
  Invalid
Status in unity8 package in Ubuntu:
  Fix Released

Bug description:
  With bug #1403511 taken care of in Qt, apps do not anymore crash with
  Qt 5.4 and device does not anymore go into reboot loop. However,
  nothing is visible on the screen.

  It seems unity8, unity8-dash etc are all running. unity8.log attached

  Relevant upstream links referring GCC5 as the reason to require -fPIC:
  
http://code.qt.io/cgit/qt/qtbase.git/commit/?id=36d6eb721e7d5997ade75e289d4088dc48678d0d
  
http://code.qt.io/cgit/qt/qtbase.git/commit/?id=3eca75de67b3fd2c890715b30c7899cebc096fe9

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1403758/+subscriptions

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

[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

[Launchpad Bug Tracker]

** Merge proposal linked:
   
https://code.launchpad.net/~utkarsh/ubuntu/+source/isc-dhcp/+git/isc-dhcp/+merge/399363

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Confirmed
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  When checking isc-dhcp-server unit file it was seen that isc-dhcp-
  server is being started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so
  long.

  The SRU would split the variables into respective names, thereby
  making sure that what /etc/default/isc-dhcp-serve sets, is available
  in the respective service file.

  
  [Test Plan]

  To reproduce, simply install isc-dhcp-server via apt.
  Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable. 

  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.

  To ensure smooth upgrade of this package, we'd check if the user
  hasn't manually set a INTERFACESv{4,6} variable to workaround this
  bug. If they have, then we simply check and make sure, we use the
  correct variable.

  
  [Where problems could occur]

  The problem could occur if the user has manually set some different
  workaround this bug and so the usual upgrade could break some of their
  old configuration.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1894172/+subscriptions

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

[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

[Utkarsh Gupta]

** Description changed:

- When checking isc-dhcp-server unit file I saw isc-dhcp-server is being
- started by:
+ [Impact]
+ 
+ When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
+ is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
- This has only been working because cmdline sets -4 and subnet
- declaration in dhcpd.conf file makes dhcp-server to bind to the correct
- interfaces, as it looks like.
+ The previous upload(er) forgot to mention (and split) the INTERFACES
+ variable to v4 and v6 and as a result, it has been this way for so long.
+ 
+ The SRU would split the variables into respective names, thereby making
+ sure that what /etc/default/isc-dhcp-serve sets, is available in the
+ respective service file.
+ 
+ 
+ [Test Plan]
+ 
+ To reproduce, simply install isc-dhcp-server via apt.
+ Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable. 
+ 
+ After the SRU is performed, the respective services files should use
+ INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.
+ 
+ To ensure smooth upgrade of this package, we'd check if the user hasn't
+ manually set a INTERFACESv{4,6} variable to workaround this bug. If they
+ have, then we simply check and make sure, we use the correct variable.
+ 
+ 
+ [Where problems could occur]
+ 
+ The problem could occur if the user has manually set some different
+ workaround this bug and so the usual upgrade could break some of their
+ old configuration.

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Confirmed
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  When checking isc-dhcp-server unit file it was seen that isc-dhcp-
  server is being started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so
  long.

  The SRU would split the variables into respective names, thereby
  making sure that what /etc/default/isc-dhcp-serve sets, is available
  in the respective service file.

  
  [Test Plan]

  To reproduce, simply install isc-dhcp-server via apt.
  Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable. 

  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.

  To ensure smooth upgrade of this package, we'd check if the user
  hasn't manually set a 

[Touch-packages] [Bug 1914279] Re: linux from security may force reboots without complete dkms modules

[Andy Whitcroft]

To minimise effort reviewing all of those packages for -security safety,
we should simply rebuild all of them in the kernel security team PPA and
publish them all to -updates/-security.

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

Title:
  linux from security may force reboots without complete dkms modules

Status in apt package in Ubuntu:
  Invalid
Status in dkms package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Triaged
Status in linux-meta package in Ubuntu:
  Triaged
Status in unattended-upgrades package in Ubuntu:
  Invalid
Status in update-manager package in Ubuntu:
  Invalid

Bug description:
  Whilst discussing

  https://discourse.ubuntu.com/t/improvements-for-hardware-support-in-
  ubuntu-desktop-installation-media/20606

  We have noticed a reference to somebody not having working backport-
  iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8
  switch.

  However, kernel meta switch was pushed to security pocket, but the
  dkms modules are all in -updates only.

  This may result in people automatically installing the new kernel with
  unatanded upgrades; dkms modules failing to build; and a reboot
  required flag left on disk.

  At this point launching update manager will not offer to install dkms
  modules from updates, and will guide the users to reboot. which
  will then cause them to boot the new kernel without the dkms modules
  that might be providing networking for them.

  Should dkms modules SRUs always getting published into -security
  pocket, as well as the -updates pocket?

  Should linux maintainer scripts prevent touching reboot required flag
  if any dkms modules fail to build?

  Should apt / unattanded-upgrades / update-manager always update dkms
  modules with kernels?

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

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

[Touch-packages] [Bug 1914279] Re: linux from security may force reboots without complete dkms modules

[Andy Whitcroft]

I think I agree with @sbeattie, that the rule should be to always
promote dkms package changes which correct for build issues in the
kernel to -security on the presumption that the kernel will soon need it
as it moves to -security.

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

Title:
  linux from security may force reboots without complete dkms modules

Status in apt package in Ubuntu:
  Invalid
Status in dkms package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Triaged
Status in linux-meta package in Ubuntu:
  Triaged
Status in unattended-upgrades package in Ubuntu:
  Invalid
Status in update-manager package in Ubuntu:
  Invalid

Bug description:
  Whilst discussing

  https://discourse.ubuntu.com/t/improvements-for-hardware-support-in-
  ubuntu-desktop-installation-media/20606

  We have noticed a reference to somebody not having working backport-
  iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8
  switch.

  However, kernel meta switch was pushed to security pocket, but the
  dkms modules are all in -updates only.

  This may result in people automatically installing the new kernel with
  unatanded upgrades; dkms modules failing to build; and a reboot
  required flag left on disk.

  At this point launching update manager will not offer to install dkms
  modules from updates, and will guide the users to reboot. which
  will then cause them to boot the new kernel without the dkms modules
  that might be providing networking for them.

  Should dkms modules SRUs always getting published into -security
  pocket, as well as the -updates pocket?

  Should linux maintainer scripts prevent touching reboot required flag
  if any dkms modules fail to build?

  Should apt / unattanded-upgrades / update-manager always update dkms
  modules with kernels?

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

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

[Touch-packages] [Bug 1918186] ThreadStacktrace.txt

[Apport retracing service]

** Attachment added: "ThreadStacktrace.txt"
   
https://bugs.launchpad.net/bugs/1918186/+attachment/5475143/+files/ThreadStacktrace.txt

** Tags added: apport-failed-retrace

** Tags removed: need-amd64-retrace

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

Title:
  tracker-store crashed with signal 5 in g_printerr()

Status in tracker package in Ubuntu:
  New

Bug description:
  Just happened, didn't really do anything.

  ProblemType: Crash
  DistroRelease: Ubuntu 21.04
  Package: tracker 2.3.6-2
  ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11
  Uname: Linux 5.10.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu59
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Mar  8 14:50:14 2021
  ExecutablePath: /usr/libexec/tracker-store
  InstallationDate: Installed on 2021-02-28 (8 days ago)
  InstallationMedia: ubuntucinnamonremix "@BASECODENAME" (20210227)
  ProcCmdline: /usr/libexec/tracker-store
  RebootRequiredPkgs: evolution-data-server
  Signal: 5
  SourcePackage: tracker
  StacktraceTop:
   g_printerr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
   () at /lib/x86_64-linux-gnu/libsqlite3.so.0
   ()
   ()
   ()
  Title: tracker-store crashed with signal 5 in g_printerr()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sudo
  separator:

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

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

[Touch-packages] [Bug 1899088] Re: Python.h library referencing problem

[Matthias Klose]

this is correct behavior. The headers are searched in
/usr/include/python3.8


** Package changed: gcc-defaults (Ubuntu) => python3-defaults (Ubuntu)

** Changed in: python3-defaults (Ubuntu)
   Status: New => Invalid

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

Title:
  Python.h library referencing problem

Status in python3-defaults package in Ubuntu:
  Invalid

Bug description:
  In the file /usrinclude/python3.8/cpython/pystate.h, on line 9, it is
  trying to reference the initconfig file but is using the path
  "cpython/initconfig" even though initconfig is in the same directory
  as pystate.h and gcc thinks that it means another directory called
  cpython inside the cpython directory. Please change pystate.h so that
  it references the correct path, modified it on my machine:

  previous: #include "cpython/initconfig.h"
  new: #include /*cpython/*/"initconfig.h"

  please change from previous to new

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: gcc 4:7.4.0-1ubuntu2.3
  ProcVersionSignature: Ubuntu 5.4.0-48.52~18.04.1-generic 5.4.60
  Uname: Linux 5.4.0-48-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.17
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct  8 17:50:12 2020
  InstallationDate: Installed on 2020-03-31 (191 days ago)
  InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 
(20200203.1)
  SourcePackage: gcc-defaults
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1899088/+subscriptions

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

[Touch-packages] [Bug 1918186] StacktraceSource.txt

[Apport retracing service]

** Attachment added: "StacktraceSource.txt"
   
https://bugs.launchpad.net/bugs/1918186/+attachment/5475142/+files/StacktraceSource.txt

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

Title:
  tracker-store crashed with signal 5 in g_printerr()

Status in tracker package in Ubuntu:
  New

Bug description:
  Just happened, didn't really do anything.

  ProblemType: Crash
  DistroRelease: Ubuntu 21.04
  Package: tracker 2.3.6-2
  ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11
  Uname: Linux 5.10.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu59
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Mar  8 14:50:14 2021
  ExecutablePath: /usr/libexec/tracker-store
  InstallationDate: Installed on 2021-02-28 (8 days ago)
  InstallationMedia: ubuntucinnamonremix "@BASECODENAME" (20210227)
  ProcCmdline: /usr/libexec/tracker-store
  RebootRequiredPkgs: evolution-data-server
  Signal: 5
  SourcePackage: tracker
  StacktraceTop:
   g_printerr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
   () at /lib/x86_64-linux-gnu/libsqlite3.so.0
   ()
   ()
   ()
  Title: tracker-store crashed with signal 5 in g_printerr()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sudo
  separator:

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

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

[Touch-packages] [Bug 1918186] Stacktrace.txt

[Apport retracing service]

** Attachment added: "Stacktrace.txt"
   
https://bugs.launchpad.net/bugs/1918186/+attachment/5475141/+files/Stacktrace.txt

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

Title:
  tracker-store crashed with signal 5 in g_printerr()

Status in tracker package in Ubuntu:
  New

Bug description:
  Just happened, didn't really do anything.

  ProblemType: Crash
  DistroRelease: Ubuntu 21.04
  Package: tracker 2.3.6-2
  ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11
  Uname: Linux 5.10.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu59
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Mar  8 14:50:14 2021
  ExecutablePath: /usr/libexec/tracker-store
  InstallationDate: Installed on 2021-02-28 (8 days ago)
  InstallationMedia: ubuntucinnamonremix "@BASECODENAME" (20210227)
  ProcCmdline: /usr/libexec/tracker-store
  RebootRequiredPkgs: evolution-data-server
  Signal: 5
  SourcePackage: tracker
  StacktraceTop:
   g_printerr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
   () at /lib/x86_64-linux-gnu/libsqlite3.so.0
   ()
   ()
   ()
  Title: tracker-store crashed with signal 5 in g_printerr()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sudo
  separator:

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

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

[Touch-packages] [Bug 1918186] tracker-store crashed with signal 5 in g_printerr()

[Apport retracing service]

StacktraceTop:
 g_printerr (format=0x7f13295419c0 "\001") at ../../../glib/gmessages.c:3369
 sqlite3MemMalloc (nByte=693369344) at sqlite3.c:23772
 ?? ()
 ?? ()
 ?? ()

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

Title:
  tracker-store crashed with signal 5 in g_printerr()

Status in tracker package in Ubuntu:
  New

Bug description:
  Just happened, didn't really do anything.

  ProblemType: Crash
  DistroRelease: Ubuntu 21.04
  Package: tracker 2.3.6-2
  ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11
  Uname: Linux 5.10.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu59
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Mar  8 14:50:14 2021
  ExecutablePath: /usr/libexec/tracker-store
  InstallationDate: Installed on 2021-02-28 (8 days ago)
  InstallationMedia: ubuntucinnamonremix "@BASECODENAME" (20210227)
  ProcCmdline: /usr/libexec/tracker-store
  RebootRequiredPkgs: evolution-data-server
  Signal: 5
  SourcePackage: tracker
  StacktraceTop:
   g_printerr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
   () at /lib/x86_64-linux-gnu/libsqlite3.so.0
   ()
   ()
   ()
  Title: tracker-store crashed with signal 5 in g_printerr()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sudo
  separator:

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

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

[Touch-packages] [Bug 1899088] [NEW] Python.h library referencing problem

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

In the file /usrinclude/python3.8/cpython/pystate.h, on line 9, it is
trying to reference the initconfig file but is using the path
"cpython/initconfig" even though initconfig is in the same directory as
pystate.h and gcc thinks that it means another directory called cpython
inside the cpython directory. Please change pystate.h so that it
references the correct path, modified it on my machine:

previous: #include "cpython/initconfig.h"
new: #include /*cpython/*/"initconfig.h"

please change from previous to new

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gcc 4:7.4.0-1ubuntu2.3
ProcVersionSignature: Ubuntu 5.4.0-48.52~18.04.1-generic 5.4.60
Uname: Linux 5.4.0-48-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.17
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct  8 17:50:12 2020
InstallationDate: Installed on 2020-03-31 (191 days ago)
InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 
(20200203.1)
SourcePackage: gcc-defaults
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: python3-defaults (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic
-- 
Python.h library referencing problem
https://bugs.launchpad.net/bugs/1899088
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to python3-defaults 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 1880258] Re: Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise

[Sebastien Bacher]

** No longer affects: network-manager (Ubuntu Groovy)

** No longer affects: network-manager (Ubuntu Focal)

** No longer affects: network-manager (Ubuntu 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/1880258

Title:
  Add trailing dot to make connectivity-check.ubuntu.com. absolute and
  reduce NXDOMAIN warning noise

Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in network-manager source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  systemd-resolved emits a disturbingly large amount of NXDOMAIN log
  messages that do not actually indicate any real problem

  [test case]

  see original description, or look at any log from any recent Ubuntu
  system, or search google for endless complaints about NXDOMAIN
  messages logged by Ubuntu

  [regression potential]

  any regression would likely be isolated to systemd-resolved handling
  of a NXDOMAIN response from its upstream nameserver, including
  possibly failing to resolve a hostname or delays in resolving
  hostnames

  [scope]

  this is needed for all releases; the patch is not upstream, but
  carried by Ubuntu

  [original description]

  I normally don't like this, but it's a one-character change so it's
  easier to start with the solution:

  diff -u -r1.1 /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  --- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  +++ /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  @@ -1,2 +1,2 @@
   [connectivity]
  -uri=http://connectivity-check.ubuntu.com/
  +uri=http://connectivity-check.ubuntu.com./

  Making this name absolute instead of relative avoids spurious
  resolutions of "connectivity-check.ubuntu.com.your_domain." This
  removes a fair amount of NXDOMAIN error noise in journalctl.

  Observing the issue and the fix requires 3 terminals:

  1. tcpdump -i any 'port domain'
  2. journalctl --boot -u systemd-resolved -f

  3. nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe the NXDOMAIN noise over a couple few minutes

  Now make the hostname absolute with the trailing dot above and run:
     systemctl reload NetworkManager
  Wait 1 min for things to stabilize. Test again:

  nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
   => observe non-zero but significantly reduced NXDOMAIN noise over a couple 
few minutes

  Originally reported at https://askubuntu.com/a/1242611/117217

  Plenty of people annoyed by NXDOMAIN warnings, just Google it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1880258/+subscriptions

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

[Touch-packages] [Bug 1918256] Re: cups wrong default driver on Epson SX420W in ubuntu-mate 20.04

[Daniel Manrique]

** Project changed: canonical-identity-provider => cups (Ubuntu)

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

Title:
  cups wrong default driver on Epson SX420W in ubuntu-mate 20.04

Status in cups package in Ubuntu:
  New

Bug description:
  Problem:
Wrong driver gets installed by default called "Epson-Stylus-SX420". 
  Symptoms:
Driver prints images incorrectly though text is ok(b/w) or fails(color 
mode).
CMY color displacement by a row or two rows depending on color(colors 
printed
sequentially instead of correct position)
  Wrong Driver: STP01724.PPD
  Wrong Driver Version: 5.3.3

  Corrections to get proper printing:

  epson-inkjet-printer-escpr/now 1.7.5-1lsb3.2 amd64

Now install printer and it is reported as "EPSON-Epson-Stylus-SX420W".
  Driver: ESCPR.PPD
  Driver Version: 1.1

  
  $ lsusb
  ..
  Bus 001 Device 002: ID 04b8:0864 Seiko Epson Corp. ME OFFICE 560W Series
  ..
  $ lsusb -v
  Bus 001 Device 002: ID 04b8:0864 Seiko Epson Corp. ME OFFICE 560W Series
  Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB   2.00
bDeviceClass0 
bDeviceSubClass 0 
bDeviceProtocol 0 
bMaxPacketSize064
idVendor   0x04b8 Seiko Epson Corp.
idProduct  0x0864 ME OFFICE 560W Series
bcdDevice1.00
iManufacturer   1 EPSON
iProduct2 EPSON Epson Stylus SX420W Series
iSerial 3 4D4343503032353032
bNumConfigurations  1
Configuration Descriptor:
  bLength 9
  bDescriptorType 2
  wTotalLength   0x004e
  bNumInterfaces  3
  bConfigurationValue 1
  iConfiguration  4 USB2.0 MFP(Hi-Speed)
  bmAttributes 0xc0
Self Powered
  MaxPower2mA
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass   255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface  5 EPSON Scanner
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x01  EP 1 OUT
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0200  1x 512 bytes
  bInterval   0
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x82  EP 2 IN
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0200  1x 512 bytes
  bInterval   0
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass 7 Printer
bInterfaceSubClass  1 Printer
bInterfaceProtocol  2 Bidirectional
iInterface  6 USB2.0 Printer
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x04  EP 4 OUT
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0200  1x 512 bytes
  bInterval   0
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x85  EP 5 IN
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0200  1x 512 bytes
  bInterval   0
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber2
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass  6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface  7 USB2.0 Mass Storage
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x07  EP 7 OUT
  bmAttributes2
Transfer TypeBulk

[Touch-packages] [Bug 1918256] [NEW] cups wrong default driver on Epson SX420W in ubuntu-mate 20.04

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Problem:
  Wrong driver gets installed by default called "Epson-Stylus-SX420". 
Symptoms:
  Driver prints images incorrectly though text is ok(b/w) or fails(color mode).
  CMY color displacement by a row or two rows depending on color(colors printed
  sequentially instead of correct position)
Wrong Driver: STP01724.PPD
Wrong Driver Version: 5.3.3

Corrections to get proper printing:

epson-inkjet-printer-escpr/now 1.7.5-1lsb3.2 amd64

  Now install printer and it is reported as "EPSON-Epson-Stylus-SX420W".
Driver: ESCPR.PPD
Driver Version: 1.1


$ lsusb
..
Bus 001 Device 002: ID 04b8:0864 Seiko Epson Corp. ME OFFICE 560W Series
..
$ lsusb -v
Bus 001 Device 002: ID 04b8:0864 Seiko Epson Corp. ME OFFICE 560W Series
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x04b8 Seiko Epson Corp.
  idProduct  0x0864 ME OFFICE 560W Series
  bcdDevice1.00
  iManufacturer   1 EPSON
  iProduct2 EPSON Epson Stylus SX420W Series
  iSerial 3 4D4343503032353032
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x004e
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  4 USB2.0 MFP(Hi-Speed)
bmAttributes 0xc0
  Self Powered
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  5 EPSON Scanner
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 7 Printer
  bInterfaceSubClass  1 Printer
  bInterfaceProtocol  2 Bidirectional
  iInterface  6 USB2.0 Printer
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04  EP 4 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  7 USB2.0 Mass Storage
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07  EP 7 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88  EP 8 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Colin Watson]

We do some slightly fiddly stuff in launchpad-buildd to set up a bridge
- see the `iptables` and `start_bridge` methods in
https://git.launchpad.net/launchpad-
buildd/tree/lpbuildd/target/lxd.py#n233.  Might this be relevant?

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in launchpad-buildd:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Dimitri John Ledkov]

i think either -L or -S "made everything work".

Note that there is no iptables installs in the lxd container, and we
install iptables on the fly.

nftables are not installed either, because that's not in main.

So when lxd container started, nothing did "restore" of any default
chains I don't think. But also have no idea if any are needed, or if I
can tune any debugging in the kernel to notice if iptables are poked in
some odd ways inside the network namespace that we are in.

Also note all the extra setup that launchpad-buildd does:
https://git.launchpad.net/launchpad-buildd/tree/lpbuildd/target/lxd.py

in terms of creating lxd profile, and doing stuff to the bridge with
iptables.

I wonder if I must always use legacy iptables, if that's what used on
the host to configure the bridge of the lxd container one is in.

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in launchpad-buildd:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1913763] Re: hyperv: unable to distinguish PTP devices

[Gauthier Jolly]

Thanks for this.

@rbalint or @ddstreet, do you plan to also backport this to Xenial?

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

Title:
  hyperv: unable to distinguish PTP devices

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

Bug description:
  [impact]

  the /dev/ptp0 device for a hyperv instance may not be the correct,
  hyperv-provided, ptp device.

  [test case]

  on some hyperv instance types, particularly those that might contain
  passthrough network card(s) that also provide ptp, the first ptp
  device may not be the correct one to use for ptp, e.g. there may be
  multiple ones:

  $ ls /dev/ptp*
  /dev/ptp0 /dev/ptp1
  $ cat /sys/class/ptp/ptp0/clock_name
  hyperv
  $ cat /sys/class/ptp/ptp1/clock_name
  mlx5_p2p

  the order can change across boots, so a consistent way of addressing
  the hyperv-provided one is needed

  [regression potential]

  any regression would involve failure to properly create the ptp
  symlink, or other failure while udev is processing newly detected ptp
  device(s)

  [scope]

  this is needed in all releases

  this was fixed upstream with the commit
  32e868f058da8b90add00b2958c516241c532b70 which is not yet included in
  any release

  [original description]

  Hyperv provides a PTP device. On system with multiple PTP devices,
  services like Chrony don't have a way to know which one is which.

  We would like to have a udev rule to create a symlink to the hyperv
  clock. This way, services could be configured to always use this clock
  no matter if it is ptp0, ptp1, etc..

  For example:

  ```
  SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
  ```

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

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

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Colin Watson]

** Project changed: launchpad => launchpad-buildd

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in launchpad-buildd:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1904082] Re: apport's log collecting leaks MAC addresses maybe helping WiFi attacks?

[Marc Deslauriers]

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

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

Title:
  apport's log collecting leaks MAC addresses maybe helping WiFi
  attacks?

Status in apport package in Ubuntu:
  Confirmed

Bug description:
  Some people configure their Internet WiFi modems such that
  only certain devices, defined by their MAC addresses, can
  (try to?) connect.  I am aware this is VERY WEAK "security"
  since MAC addresses are easily spoofed.

  It occurs to me that the logs collected by apport-cli(1)
  and friends, when reporting a bug, contain the system's
  MAC addresses.  Those logs are normally publicly readable
  by anyone browsing Launchpad.  That means villains could
  reap (collect) MAC addresses to spoof and try to obtain an
  unintended WiFi connection.  (Isn't necessarily easy since
  the attacker would have(?) to be within range of the modem
  to try?)

  I am NOT saying this has happened — I have no idea.

  I just wanted to bring this hypothetical(?) problem/attack
  to your attention.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apport 2.20.11-0ubuntu27.12
  ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
  Uname: Linux 5.4.0-53-generic x86_64
  ApportLog:
   
  ApportVersion: 2.20.11-0ubuntu27.12
  Architecture: amd64
  CasperMD5CheckResult: skip
  CrashReports:
   664:1000:125:0:2020-11-13 03:00:18.498740147 +0100:2020-11-13 
03:00:18.498740147 +0100:/var/crash/_usr_bin_kglobalaccel5.1000.upload
   600:118:125:37:2020-11-13 03:00:19.490721528 +0100:2020-11-13 
03:00:19.490721528 +0100:/var/crash/_usr_bin_kglobalaccel5.1000.uploaded
   640:1000:125:798567:2020-11-13 03:00:16.626756668 +0100:2020-11-13 
03:00:17.626756668 +0100:/var/crash/_usr_bin_kglobalaccel5.1000.crash
  Date: Fri Nov 13 03:03:36 2020
  InstallationDate: Installed on 2020-10-19 (24 days ago)
  InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1915906] Re: Ensure SRP BN_mod_exp follows the constant time path

[Marc Deslauriers]

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

** Changed in: openssl (Ubuntu)
   Importance: Undecided => Wishlist

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

Title:
  Ensure SRP BN_mod_exp follows the constant time path

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  Hello,

  I'd like to point out that there are two fixes missing from the
  upstream, is there any chance to get them incorporated?

  https://github.com/openssl/openssl/pull/13888
  https://github.com/openssl/openssl/pull/13889

  There was no CVE assigned, it was fixed between 1.1.1i and 1.1.1j.

  Best regards

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

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

[Touch-packages] [Bug 1915279] Re: about

[Marc Deslauriers]

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  about

Status in xorg package in Ubuntu:
  New

Bug description:
  all chromium server have heavy issue in render

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.8.0-43.49~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-43-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Feb 10 20:16:29 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Intel Corporation 4 Series Chipset Integrated Graphics Controller 
[8086:2e12] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Dell 4 Series Chipset Integrated Graphics Controller [1028:027f]
 Subsystem: Dell 4 Series Chipset Integrated Graphics Controller [1028:027f]
  InstallationDate: Installed on 2021-02-04 (6 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  MachineType: Dell Inc. OptiPlex 760
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-43-generic 
root=UUID=136e728b-139d-400a-b333-620a8490dd1d ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/06/2013
  dmi.bios.release: 16.0
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A16
  dmi.board.name: 0M858N
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 6
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA16:bd08/06/2013:br16.0:svnDellInc.:pnOptiPlex760:pvr:rvnDellInc.:rn0M858N:rvrA01:cvnDellInc.:ct6:cvr:
  dmi.product.name: OptiPlex 760
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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

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

[Touch-packages] [Bug 1915913] Re: OpenSSL Multiple Denial of Service Vulnerabilities

[Marc Deslauriers]

Updated for this issue have been released:

https://ubuntu.com/security/notices/USN-4738-1

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

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

Title:
  OpenSSL Multiple Denial of Service Vulnerabilities

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Multiple vulnerabilities have been reported in OpenSSL, which can be
  exploited by malicious people to cause a DoS (Denial of Service).

  1

  An error related to the "X509_issuer_and_serial_hash()" function
  (crypto/x509/x509_cmp.c) can be exploited to trigger a NULL pointer
  dereference and subsequently cause a crash.

  2

  An integer overflow error related to CipherUpdate calls can be
  exploited to cause a crash.

  The vulnerabilities are reported in versions prior to 1.1.1j and prior
  to 1.0.2y.

  Affected Software

  The following software is affected by the described vulnerability.
  Please check the vendor links below to see if exactly your version is
  affected.

  OpenSSL 1.x

  Solution

  Update to version 1.1.1j or 1.0.2y.

  References

  1. https://www.openssl.org/news/secadv/20210216.txt 

  2. 
https://github.com/openssl/openssl/commit/8130d654d1de922ea224fa18ee3bc7262edc39c0
 

  3. 
https://github.com/openssl/openssl/commit/c9fb704cf3af5524eb8e79961e31b60eee8c3c47
 


  
  Please provide an update.

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

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

[Touch-packages] [Bug 1917225] Re: [MS-14Y1, Realtek ALC269VB, Black Headphone Out, Right] Background noise or low volume

[Marc Deslauriers]

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  [MS-14Y1, Realtek ALC269VB, Black Headphone Out, Right] Background
  noise or low volume

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  sound has become cut at once and the quality become low or the os
  become hanged and then low quality bug happen. two or three times per
  day.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.8.0-45.51~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-45-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  asal   2994 F pulseaudio
asal   6769 F alsamixer
   /dev/snd/pcmC0D0c:   asal   2994 F...m pulseaudio
   /dev/snd/pcmC0D0p:   asal   2994 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Feb 28 19:23:17 2021
  InstallationDate: Installed on 2020-09-16 (164 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Headphone Out, Right
  Symptom_Type: High background noise, or volume is too low
  Title: [MS-14Y1, Realtek ALC269VB, Black Headphone Out, Right] Background 
noise or low volume
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/09/2011
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: E14Y1IMS.209
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: MS-14Y1
  dmi.board.vendor: Micro-Star INT'L CO., LTD.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: Micro-Star INT'L CO., LTD.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrE14Y1IMS.209:bd09/09/2011:br4.6:svnMicro-StarINT'LCO.,LTD.:pnMS-14Y1:pvr1.0:rvnMicro-StarINT'LCO.,LTD.:rnMS-14Y1:rvr1.0:cvnMicro-StarINT'LCO.,LTD.:ct9:cvr1.0:
  dmi.product.family: PEGA Family
  dmi.product.name: MS-14Y1
  dmi.product.sku: 0
  dmi.product.version: 1.0
  dmi.sys.vendor: Micro-Star INT'L CO., LTD.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1917225/+subscriptions

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

[Touch-packages] [Bug 1917204] Re: high Resolution is not getting

[Marc Deslauriers]

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  high Resolution is not getting

Status in xorg package in Ubuntu:
  New

Bug description:
  I'm not getting my Monitor supporting resolution

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Feb 28 14:40:41 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller 
[8086:0152] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Elitegroup Computer Systems Xeon E3-1200 v2/3rd Gen Core 
processor Graphics Controller [1019:7df5]
  InstallationDate: Installed on 2021-01-20 (38 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  MachineType: ECS H61H2-MV
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-44-generic 
root=UUID=671d72b0-98f0-468f-a72f-910d30b2051a ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/13/2014
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: H61H2-MV
  dmi.board.vendor: ECS
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: ECS
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd08/13/2014:br4.6:svnECS:pnH61H2-MV:pvr1.0:rvnECS:rnH61H2-MV:rvr1.0:cvnECS:ct3:cvr1.0:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: H61H2-MV
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 1.0
  dmi.sys.vendor: ECS
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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

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

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Alex Murray]

Good point re google.com - I just repeated the above test but replacing
www.google.com with http://neverssl.com and verified it worked as
expected so it doesn't look like http->https redirect affected the
results.

Hmmm perhaps there is something else at play compared to when testing
locally vs on launchpad - with your original test-case, does using
`iptables -L -t nat` behave any differently than `iptables -S -t nat` in
terms of working around this? Perhaps there is something in the existing
iptables setup on launchpad that is not present in our local testing
which may be needed to reproduce this?

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in Launchpad itself:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1523100] Re: Alsa not detecting internal microphone [ALC255] (Realtek)

[Julien Saggiotto]

Same problem here, with a Acer Swift 314-42. 
Hdajackretask does not work for me. 
:/

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

Title:
  Alsa not detecting internal microphone [ALC255] (Realtek)

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  I've just installed Ubuntu 16.04 alongside Windows 10 on a 64bit Acer
  Aspire VN7-792G and noticed, that the internal microphone doesn't
  work. The computer has been released a couple of months ago and it's
  Intel Skylake -based with a Sunrise Point -based motherboard.

  INFO: The problem exists in Ubuntu 15.10 too, only microphone jack
  detected. Currently using Ubuntu 16.04 for proper hardware support.

  Alsa reports the audio device to be:

  Card: HDA Intel PCH
  Chip: Intel Skylake HDMI

  The speakers are working fine, but both alsamixer and pavucontrol
  (Pulseaudio Volume Control) raport the unplugged external microphone
  connector as the only sound input.

  I have tried many of the alsa model configurations (options snd-hda-
  intel model=something) without success, alsa finds only the microphone
  jack, which works fine when I plug an external microphone in it.

  Here's some info:

  lspci | grep -I audio:

  00:1f.3 Multimedia audio controller: Intel Corporation Sunrise Point-H
  HD Audio (rev 31)

  cat /proc/asound/cards:

  0 [PCH]: HDA-Intel - HDA Intel PCH
  HDA Intel PCH at 0x8432 irq 128

  And a clip from dmesg | grep snd:

  [3.019164] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
  [3.047505] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC255: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
  [3.047508] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
  [3.047510] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
  [3.047511] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
  [3.047512] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0
  [3.047512] snd_hda_codec_realtek hdaudioC0D0:inputs:
  [3.047514] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x1a

  One problem is that I can't find any model options (options snd-hda-
  intel model=something) or other parameters for the card's model
  (ALC255), I suppose this issue is relatively new.

  /Dennis
  --- 
  ApportVersion: 2.19.2-0ubuntu6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  dennis 1180 F pulseaudio
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 16.04
  InstallationDate: Installed on 2015-11-11 (23 days ago)
  InstallationMedia: Ubuntu-GNOME 16.04 LTS "Xenial Xerus" - Alpha amd64 
(20151110)
  Package: alsa-driver (not installed)
  ProcVersionSignature: Ubuntu 4.2.0-19.23-generic 4.2.6
  Tags:  xenial
  Uname: Linux 4.2.0-19-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm bumblebee cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 09/25/2015
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: V1.02
  dmi.board.asset.tag: No Asset Tag
  dmi.board.name: Aspire VN7-792G
  dmi.board.vendor: Acer
  dmi.board.version: V1.02
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: V1.02
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.02:bd09/25/2015:svnAcer:pnAspireVN7-792G:pvrV1.02:rvnAcer:rnAspireVN7-792G:rvrV1.02:cvnAcer:ct10:cvrV1.02:
  dmi.product.name: Aspire VN7-792G
  dmi.product.version: V1.02
  dmi.sys.vendor: Acer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1523100/+subscriptions

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

[Touch-packages] [Bug 1917887] Re: Network Manager OpenVPN nested connections fail to setup routes correctly

[Riccardo Battistini]

I agree that is a problem with Network Manager, maybe also affects
different vpn besides OpenVPN; this same problem is present in CentOS 7
and 8.

Which config do you need?

I tried to draw the network scheme to help understanding my setup.

Regards
Riccardo

** Attachment added: "Network Scheme"
   
https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1917887/+attachment/5475052/+files/Network%20Manager%20OpenVPN%20nested%20connections%20fail%20to%20setup%20routes%20correctly%20-%20bug%201917887%20-%201.jpg

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

Title:
  Network Manager OpenVPN nested connections fail to setup routes
  correctly

Status in network-manager package in Ubuntu:
  Incomplete
Status in openvpn package in Ubuntu:
  Incomplete

Bug description:
  Setup:
  Host lan: 192.168.0.238/24
  Host Default gw: 192.168.0.1

  ip route:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 

  
  Primary OpenVPN (check "Use this connection only for resources on its 
network"):
  server ip: public a.b.c.d
  OpenVPN Tunnel: 192.168.1.0/24
  routes pushed: 192.168.100.0/24

  First VPN works OK:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 

  
  Secondary OpenVPN  (check "Use this connection only for resources on its 
network"):
  server ip: private 192.168.100.10 
  OpenVPN Tunnel: 192.168.20.0/24
  routes pushed: 192.168.200.0/24

  Second VPN Connect OK, routing table is wrong:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  192.168.200.0/24 via 192.168.20.1 dev tun1 
  192.168.20.0/24 dev tun1 proto kernel scope link src 192.168.20.59 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 
  192.168.100.10 via 192.168.0.1 dev eno1 proto static metric 100 <- this is 
wrong, the openVPN#2 Gateway is not on the local lan

  Correct routing table using "sudo /usr/sbin/openvpn
  /path/to/config.openvpn" (same a Network Manager)

  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  192.168.200.0/24 via 192.168.20.1 dev tun1 
  192.168.20.0/24 dev tun1 proto kernel scope link src 192.168.20.59 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 

  It seems that Network Manager add a wrong additional route not added
  by the openvpn bin:

  192.168.100.10 via 192.168.0.1 dev eno1 proto static metric 100

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openvpn 2.4.7-1ubuntu2
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar  5 12:44:39 2021
  InstallationDate: Installed on 2021-02-19 (13 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=it_IT.UTF-8
   SHELL=/bin/bash
  SourcePackage: openvpn
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1917887/+subscriptions

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

[Touch-packages] [Bug 1916705] Re: glib2.0 >=2.67.3 breaks include from an extern C context

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

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

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

Title:
  glib2.0 >=2.67.3 breaks include from an extern C context

Status in glib2.0 package in Ubuntu:
  Fix Released
Status in open-vm-tools package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in ukui-control-center package in Ubuntu:
  Triaged
Status in wireshark package in Ubuntu:
  Confirmed

Bug description:
  qemu now breaks in Hirsute (it didn't 23h ago)
  Broken:
  
https://launchpadlibrarian.net/524654684/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-6ubuntu1_BUILDING.txt.gz

  Good before:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4471/+packages

  Error:

  ../../disas/arm-a64.cc
  In file included from /usr/include/glib-2.0/glib/gmacros.h:241,
   from 
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9,
   from /usr/include/glib-2.0/glib/gtypes.h:32,
   from /usr/include/glib-2.0/glib/galloca.h:32,
   from /usr/include/glib-2.0/glib.h:30,
   from /<>/qemu-5.2+dfsg/include/glib-compat.h:32,
   from /<>/qemu-5.2+dfsg/include/qemu/osdep.h:126,
   from ../../disas/arm-a64.cc:21:
  /usr/include/c++/10/type_traits:56:3: error: template with C linkage
     56 |   template
    |   ^~~~
  ../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
     20 | extern "C" {
    | ^~

  Also in disas/nanomips.cpp, ...

  And indeed disas/arm-a64.cc has:
   20 extern "C" {
   21 #include "qemu/osdep.h"
   22 #include "disas/dis-asm.h"
   23 }

  Through the chain of headers as reported above this gets to the templates
  in /usr/include/c++/10/type_traits which fails due to that.

  So C++ constructs within a C scope which is this bug.

  Upstream qemu has not recently changed yet for this.
  The code is the same since 2016 via commit e78490c44: "disas/arm-a64.cc:
  Include osdep.h first" by Peter Maydell.

  But what was different before to break it now?
  To find that I was comparing Hirsute vs Hirsute-proposed ...

  It is indeed failing in -proposed but working in hirsute-release.

  10.2.1-20ubuntu1 : bad

  repro in broken build:
  $ cd /root/qemu-5.2+dfsg/b/qemu
  $ c++ -Ilibcommon.fa.p -I. -I../.. -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/pixman-1 -I/usr/include/virgl -I/usr/include/libpng16 
-I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 
-I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr 
-I/usr/include/PCSC -I/usr/include/slirp -fdiagnostics-color=auto -pipe -Wall 
-Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O2 -g -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef 
-Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -g -O2 
-ffile-prefix-map=/root/qemu-5.2+dfsg=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wtype-limits 
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body 
-Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs 
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -isystem 
/root/qemu-5.2+dfsg/linux-headers -isystem linux-headers -iquote 
/root/qemu-5.2+dfsg/tcg/i386 -iquote . -iquote /root/qemu-5.2+dfsg -iquote 
/root/qemu-5.2+dfsg/accel/tcg -iquote /root/qemu-5.2+dfsg/include -iquote 
/root/qemu-5.2+dfsg/disas/libvixl -pthread -fPIE -DSTRUCT_IOVEC_DEFINED 
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR -MD -MQ 
libcommon.fa.p/disas_nanomips.cpp.o -MF libcommon.fa.p/disas_nanomips.cpp.o.d 
-o libcommon.fa.p/disas_nanomips.cpp.o -c ../../disas/nanomips.cpp

  With that I have a test env...

  Doko asked me to test
  
https://launchpad.net/ubuntu/+source/gcc-10/10.2.1-19ubuntu1/+build/20995220/+files/g++-10_10.2.1-19ubuntu1_amd64.deb
  That fails as well, but also good as well as bad case have 10.10.2.1-20ubuntu1
  It must be something else.

  The difference were ~340 packages I was upgrading them to spot what broke it.
  I eventually found glib 2.66 -> 2.67 to break it.

  libglib2.0-0/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
  libglib2.0-bin/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
  libglib2.0-data/hirsute-proposed 2.67.4-1 all [upgradable from: 2.66.4-1]
  libglib2.0-dev-bin/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
  libglib2.0-dev/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]

  Old:
  /*

[Touch-packages] [Bug 1916705] Re: glib2.0 >=2.67.3 breaks include from an extern C context

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: open-vm-tools (Ubuntu)
   Status: New => Confirmed

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

Title:
  glib2.0 >=2.67.3 breaks include from an extern C context

Status in glib2.0 package in Ubuntu:
  Fix Released
Status in open-vm-tools package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in ukui-control-center package in Ubuntu:
  Triaged
Status in wireshark package in Ubuntu:
  Confirmed

Bug description:
  qemu now breaks in Hirsute (it didn't 23h ago)
  Broken:
  
https://launchpadlibrarian.net/524654684/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-6ubuntu1_BUILDING.txt.gz

  Good before:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4471/+packages

  Error:

  ../../disas/arm-a64.cc
  In file included from /usr/include/glib-2.0/glib/gmacros.h:241,
   from 
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9,
   from /usr/include/glib-2.0/glib/gtypes.h:32,
   from /usr/include/glib-2.0/glib/galloca.h:32,
   from /usr/include/glib-2.0/glib.h:30,
   from /<>/qemu-5.2+dfsg/include/glib-compat.h:32,
   from /<>/qemu-5.2+dfsg/include/qemu/osdep.h:126,
   from ../../disas/arm-a64.cc:21:
  /usr/include/c++/10/type_traits:56:3: error: template with C linkage
     56 |   template
    |   ^~~~
  ../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
     20 | extern "C" {
    | ^~

  Also in disas/nanomips.cpp, ...

  And indeed disas/arm-a64.cc has:
   20 extern "C" {
   21 #include "qemu/osdep.h"
   22 #include "disas/dis-asm.h"
   23 }

  Through the chain of headers as reported above this gets to the templates
  in /usr/include/c++/10/type_traits which fails due to that.

  So C++ constructs within a C scope which is this bug.

  Upstream qemu has not recently changed yet for this.
  The code is the same since 2016 via commit e78490c44: "disas/arm-a64.cc:
  Include osdep.h first" by Peter Maydell.

  But what was different before to break it now?
  To find that I was comparing Hirsute vs Hirsute-proposed ...

  It is indeed failing in -proposed but working in hirsute-release.

  10.2.1-20ubuntu1 : bad

  repro in broken build:
  $ cd /root/qemu-5.2+dfsg/b/qemu
  $ c++ -Ilibcommon.fa.p -I. -I../.. -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/pixman-1 -I/usr/include/virgl -I/usr/include/libpng16 
-I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 
-I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr 
-I/usr/include/PCSC -I/usr/include/slirp -fdiagnostics-color=auto -pipe -Wall 
-Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O2 -g -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef 
-Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -g -O2 
-ffile-prefix-map=/root/qemu-5.2+dfsg=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wtype-limits 
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body 
-Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs 
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -isystem 
/root/qemu-5.2+dfsg/linux-headers -isystem linux-headers -iquote 
/root/qemu-5.2+dfsg/tcg/i386 -iquote . -iquote /root/qemu-5.2+dfsg -iquote 
/root/qemu-5.2+dfsg/accel/tcg -iquote /root/qemu-5.2+dfsg/include -iquote 
/root/qemu-5.2+dfsg/disas/libvixl -pthread -fPIE -DSTRUCT_IOVEC_DEFINED 
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR -MD -MQ 
libcommon.fa.p/disas_nanomips.cpp.o -MF libcommon.fa.p/disas_nanomips.cpp.o.d 
-o libcommon.fa.p/disas_nanomips.cpp.o -c ../../disas/nanomips.cpp

  With that I have a test env...

  Doko asked me to test
  
https://launchpad.net/ubuntu/+source/gcc-10/10.2.1-19ubuntu1/+build/20995220/+files/g++-10_10.2.1-19ubuntu1_amd64.deb
  That fails as well, but also good as well as bad case have 10.10.2.1-20ubuntu1
  It must be something else.

  The difference were ~340 packages I was upgrading them to spot what broke it.
  I eventually found glib 2.66 -> 2.67 to break it.

  libglib2.0-0/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
  libglib2.0-bin/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
  libglib2.0-data/hirsute-proposed 2.67.4-1 all [upgradable from: 2.66.4-1]
  libglib2.0-dev-bin/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
  libglib2.0-dev/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]

  Old:
 

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Dimitri John Ledkov]

However I do not think that google.com is a good test, as it will try to
redirect to https, no? and magic proxy only does things with http. We
are failing to reach http ftpmaster.internal.

I am now trying to rewrite bits of magic-proxy to use more of urllib and
surface more HTTP and IO errors. Maybe it will tell us something more.

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in Launchpad itself:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1917920] Re: magic-proxy broke with iptables 1.8.7-1ubuntu2

[Dimitri John Ledkov]

@alex

Thanks for trying this. And yes, we have been unable to reproduce this
outside of launchpad.

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

Title:
  magic-proxy broke with iptables 1.8.7-1ubuntu2

Status in Launchpad itself:
  New
Status in iptables package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in lxd package in Ubuntu:
  New

Bug description:
  when iptables got upgraded from 1.8.5-3ubuntu4 to 1.8.7-1ubuntu2 magic
  proxy stopped working in livecd-rootfs.

  It does very simple thing:

  iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  daemon -j REDIRECT --to 8080

  inside hirsute lxd container, with quite high privileges, in a bionic
  VM, running 4.15 kernel.

  With 1.8.5 above worked fine, with 1.8.7 somehow there was no outbound
  connectivity the very first http networking command after the above
  call would just hang indefinitely.

  However, if one does this instead:

  iptables -vv -t nat -S
  iptables-legacy -vv -t nat -S
  iptables -vv -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner daemon 
-j REDIRECT --to 8080

  somehow magically everything starts to work fine.

  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1917920/+subscriptions

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

[Touch-packages] [Bug 1913423] Re: getgrouplist is not thread safe with libnss_systemd

[Daniel Sung]

I have tested the updated systemd package in focal-proposed and that
does indeed fix this bug.

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

Title:
  getgrouplist is not thread safe with libnss_systemd

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

Bug description:
  [impact]

  programs calling getgrouplist() may crash as it is not thread-safe

  [test case]

  see upstream bug description for sample c program to reproduce:
  https://github.com/systemd/systemd/issues/17007#issue-698123284

  [regression potential]

  any regression would likely occur when creating a hashmap in systemd,
  or when any multi-threaded programs concurrently create (and use) the
  hashmap

  [scope]

  this is needed for f and b

  this is fixed upstream by commit
  ae0b700a856c0ae460d271bb50dccfaae84dbcab, already included in g/h (per
  comment 1).

  [original description]

  This upstream issue (https://github.com/systemd/systemd/issues/17007)
  is affecting the latest version of systemd in Ubuntu Focal. It has
  been fixed upstream with
  https://github.com/systemd/systemd/pull/17033. Can we have this
  patched for Focal please as it causes Mesos to randomly segfault on
  start.

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

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

[Touch-packages] [Bug 1916705] Re: glib2.0 >=2.67.3 breaks include from an extern C context

[Andreas Schultz]

for wireshark the problem can be worked around with this:

diff -up wireshark-3.4.3/debian/rules.orig wireshark-3.4.3/debian/rules
--- wireshark-3.4.3/debian/rules.orig   2021-03-09 10:09:58.184967210 +0100
+++ wireshark-3.4.3/debian/rules2021-03-09 09:58:39.497405512 +0100
@@ -31,7 +31,8 @@ override_dh_auto_configure-indep:
 
 override_dh_auto_configure-arch:
echo "#define VCSVERSION \"$(GIT_VERSION)\"" > version.h
-   dh_auto_configure
+   dh_auto_configure -- 
-DCMAKE_CXX_FLAGS="-DGLIB_VERSION_MIN_REQUIRED=0x024200" \
+
-DCMAKE_C_FLAGS="-DGLIB_VERSION_MIN_REQUIRED=0x024200"
 
 override_dh_auto_build-arch:
# regenerate ASN.1 dissectors

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

Title:
  glib2.0 >=2.67.3 breaks include from an extern C context

Status in glib2.0 package in Ubuntu:
  Fix Released
Status in open-vm-tools package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in ukui-control-center package in Ubuntu:
  Triaged
Status in wireshark package in Ubuntu:
  Confirmed

Bug description:
  qemu now breaks in Hirsute (it didn't 23h ago)
  Broken:
  
https://launchpadlibrarian.net/524654684/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-6ubuntu1_BUILDING.txt.gz

  Good before:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4471/+packages

  Error:

  ../../disas/arm-a64.cc
  In file included from /usr/include/glib-2.0/glib/gmacros.h:241,
   from 
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9,
   from /usr/include/glib-2.0/glib/gtypes.h:32,
   from /usr/include/glib-2.0/glib/galloca.h:32,
   from /usr/include/glib-2.0/glib.h:30,
   from /<>/qemu-5.2+dfsg/include/glib-compat.h:32,
   from /<>/qemu-5.2+dfsg/include/qemu/osdep.h:126,
   from ../../disas/arm-a64.cc:21:
  /usr/include/c++/10/type_traits:56:3: error: template with C linkage
     56 |   template
    |   ^~~~
  ../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
     20 | extern "C" {
    | ^~

  Also in disas/nanomips.cpp, ...

  And indeed disas/arm-a64.cc has:
   20 extern "C" {
   21 #include "qemu/osdep.h"
   22 #include "disas/dis-asm.h"
   23 }

  Through the chain of headers as reported above this gets to the templates
  in /usr/include/c++/10/type_traits which fails due to that.

  So C++ constructs within a C scope which is this bug.

  Upstream qemu has not recently changed yet for this.
  The code is the same since 2016 via commit e78490c44: "disas/arm-a64.cc:
  Include osdep.h first" by Peter Maydell.

  But what was different before to break it now?
  To find that I was comparing Hirsute vs Hirsute-proposed ...

  It is indeed failing in -proposed but working in hirsute-release.

  10.2.1-20ubuntu1 : bad

  repro in broken build:
  $ cd /root/qemu-5.2+dfsg/b/qemu
  $ c++ -Ilibcommon.fa.p -I. -I../.. -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/pixman-1 -I/usr/include/virgl -I/usr/include/libpng16 
-I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 
-I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr 
-I/usr/include/PCSC -I/usr/include/slirp -fdiagnostics-color=auto -pipe -Wall 
-Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O2 -g -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef 
-Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -g -O2 
-ffile-prefix-map=/root/qemu-5.2+dfsg=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wtype-limits 
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body 
-Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs 
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -isystem 
/root/qemu-5.2+dfsg/linux-headers -isystem linux-headers -iquote 
/root/qemu-5.2+dfsg/tcg/i386 -iquote . -iquote /root/qemu-5.2+dfsg -iquote 
/root/qemu-5.2+dfsg/accel/tcg -iquote /root/qemu-5.2+dfsg/include -iquote 
/root/qemu-5.2+dfsg/disas/libvixl -pthread -fPIE -DSTRUCT_IOVEC_DEFINED 
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR -MD -MQ 
libcommon.fa.p/disas_nanomips.cpp.o -MF libcommon.fa.p/disas_nanomips.cpp.o.d 
-o libcommon.fa.p/disas_nanomips.cpp.o -c ../../disas/nanomips.cpp

  With that I have a test env...

  Doko asked me to test
  
https://launchpad.net/ubuntu/+source/gcc-10/10.2.1-19ubuntu1/+build/20995220/+files/g++-10_10.2.1-19ubuntu1_amd64.deb
  That fails as well, but also good as well as bad case have 

[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Mekk]

I use my computer for work and need reasonably stable environment. So
no, sorry. I am OK with installing newer systemd, testing it, and maybe
downgrading in case of (new) problems, but I can't upgrade whole distro
just now.

Would using PPA from comment 19 be as limited as PPA from comment 8
(systemd only, without messing with other packages)?

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

Title:
  systemd-resolve crashes fairly often (and reports various assertions)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  systemd-resolved crashes

  [test case]

  see original description; I can't reproduce so I'm relying on the
  reporter(s) to test/verify.

  [regression potential]

  any regression would likely occur while processing sd_event objects,
  which are used throughout systemd code; this could result in crashes
  in almost any part of systemd code. However a more likely regression
  would be leaks of sd_event objects due to failure to release the final
  ref for an object.

  [scope]

  This is needed for f/g/h

  This might be fixed by upstream commit
  f814c871e65df8552a055dd887bc94b074037833; if so, that commit isn't
  included in any systemd release yet, and so is needed in h and
  earlier.

  [other info]

  I believe this is caused by a freed sd_event object that is then
  processed and calls the on_query_timeout callback with invalid state,
  leading to failed assertion, which causes resolved to crash; that's
  what analysis of the crash dump appears to indicate. This may be fixed
  by the upstream commit referenced in [scope], which takes additional
  refs during function calls. However I haven't reproduced this myself,
  so I'm only guessing as to the cause and solution at this point.

  I'm unsure why this would not occur in bionic, but per comment 5 it
  seems it doesn't happen in that release.

  [original description]

  (Tested on regularly updated Ubuntu 20.04, currently i use systemd
  245.4-4ubuntu3.2)

  I observe fairly lot of segfaults of systemd-resolve. Frequency vary
  but … see below.

  I have no clue what is the reason. Specific feature of my machine is
  that apart from normal cable connection (to OpenWRT router) I use
  OpenVPN for business network (and this submits specific nameserver for
  myorg.local domain).

  ~
  $ LC_ALL=C dmesg -T --level=info | grep systemd-resolve
  [Sun Nov 29 11:47:37 2020] systemd-resolve[1629307]: segfault at 190eed7bdc6 
ip 7fd98f771dc9 sp 7ffc2352a100 error 4 in 
libsystemd-shared-245.so[7fd98f74c000+16e000]
  [Sun Nov 29 11:57:27 2020] systemd-resolve[1629787]: segfault at 1f ip 
55ab7b0cb686 sp 7fff78ce4bd0 error 4 in 
systemd-resolved[55ab7b0a4000+3e000]
  [Sun Nov 29 12:07:37 2020] systemd-resolve[1630481]: segfault at 191 ip 
55ca69fed91c sp 7ffc4d757dc0 error 6 in 
systemd-resolved[55ca69fc2000+3e000]
  [Sun Nov 29 13:12:26 2020] systemd-resolve[1638829]: segfault at 19224162371 
ip 7fc1bc9b9dc9 sp 7ffc21378170 error 4 in 
libsystemd-shared-245.so[7fc1bc994000+16e000]
  [Sun Nov 29 13:32:57 2020] systemd-resolve[1639886]: segfault at 1926d8126d3 
ip 7f7ed17e9dc9 sp 7ffda2cea0b0 error 4 in 
libsystemd-shared-245.so[7f7ed17c4000+16e000]
  [Sun Nov 29 13:42:37 2020] systemd-resolve[1640246]: segfault at 61 ip 
558d992e2686 sp 7fff08906af0 error 4 in 
systemd-resolved[558d992bb000+3e000]
  [Sun Nov 29 15:42:26 2020] systemd-resolve[1645397]: segfault at 1943c92afc7 
ip 7fd4c1721dc9 sp 7fff25259ce0 error 4 in 
libsystemd-shared-245.so[7fd4c16fc000+16e000]
  [Sun Nov 29 16:02:36 2020] systemd-resolve[1646052]: segfault at 1947ecb3726 
ip 7f1008549dc9 sp 7fff44a6db70 error 4 in 
libsystemd-shared-245.so[7f1008524000+16e000]
  [Sun Nov 29 17:42:35 2020] systemd-resolve[1649403]: segfault at 71 ip 
55a37fe5a686 sp 7ffd9a160440 error 4 in 
systemd-resolved[55a37fe33000+3e000]
  [Sun Nov 29 17:52:35 2020] systemd-resolve[1649759]: segfault at 558d292947d0 
ip 558d292947d0 sp 7ffec7ab3bf8 error 15
  [Sun Nov 29 19:17:55 2020] systemd-resolve[1652349]: segfault at 558995b77cf0 
ip 558995b77cf0 sp 7ffe545ae4a8 error 15
  [Sun Nov 29 19:32:35 2020] systemd-resolve[1652640]: segfault at 19773c20194 
ip 7f66bb529dc9 sp 7fffd7066fc0 error 4 in 
libsystemd-shared-245.so[7f66bb504000+16e000]
  [Sun Nov 29 20:03:54 2020] systemd-resolve[1653715]: segfault at 197e3aee918 
ip 7fdc40b51dc9 sp 7ffde484fbf0 error 4 in 
libsystemd-shared-245.so[7fdc40b2c000+16e000]
  [Sun Nov 29 20:22:24 2020] systemd-resolve[1654540]: segfault at 19820a05297 
ip 7f6a92839dc9 sp 7ffe4ba00440 error 4 in