[Touch-packages] [Bug 1970076] Re: "User process fault: interruption code 0011 ilc:3" on SSH client/server upon Jammy upgrade

2022-04-27 Thread Christian Ehrhardt
Oh I assumed this was running s390x VM on s390x Host.
@Ryan - is this s390x emulation on a non-s390x host?

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

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

Title:
  "User process fault: interruption code 0011 ilc:3" on SSH
  client/server upon Jammy upgrade

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  This s390x VM has been upgraded to Jammy, including the host (qemu-
  system-s390x 1:6.2+dfsg-2ubuntu6).  Now any attempt to use ssh, or any
  incoming sshd attempt immediately results in e.g.:

  ryan@s390x-dev:~$ ssh g...@github.com
  [  433.672800] User process fault: interruption code 0011 ilc:3 in 
libc.so.6[3ffa6c0+1ca000]
  [  433.672946] Failing address: 02aa0b84d000 TEID: 02aa0b84d800
  [  433.672977] Fault in primary space mode while using user ASCE.
  [  433.673030] AS:02bc01c7 R3:087cc007 S:0798a000 
P:0400 
  Segmentation fault (core dumped)

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


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


[Touch-packages] [Bug 1624485] Re: Nettle: Enable AES-NI instructions on amd64.

2022-04-26 Thread Christian Ehrhardt
Indeed (thanks Richard) that is enabled since 3.6-1.

It is unlikely though due to the associated symbol changes (see e.g. the
old changelogs) that this can be provided as an SRU for older releases.
I'm not saying impossible, just unlikely as that evaluation has to be
done and checked in depth for potential side-effects in regard to an
SRU.

** Also affects: nettle (Ubuntu Focal)
   Importance: Undecided
   Status: New

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

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

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

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

** Changed in: nettle (Ubuntu Bionic)
   Importance: Undecided => Low

** Changed in: nettle (Ubuntu Focal)
   Importance: Undecided => Low

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

Title:
  Nettle: Enable AES-NI instructions on amd64.

Status in nettle package in Ubuntu:
  Fix Released
Status in nettle source package in Bionic:
  Confirmed
Status in nettle source package in Focal:
  Confirmed

Bug description:
  The current build of libnettle6 does not have AES-NI enabled. There's
  two configure options for enabling it:

  --enable-x86-aesni: Use AES-NI instructions instead of the standard 
implementation. This will break on systems that don't have AES-NI.
  --enable-fat: Build a "fat" library that has the standard implementation and 
the AES-NI implementation. This allows the library to continue working on older 
systems while providing faster performance on systems that have AES-NI.

  Note that Nettle's AES-NI implementation as of v3.2 is only supported
  on amd64, not i386, so this would only affect the 64-bit package.

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


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


[Touch-packages] [Bug 1970076] Re: "User process fault: interruption code 0011 ilc:3" on SSH client/server upon Jammy upgrade

2022-04-26 Thread Christian Ehrhardt
@Ryan - Before going deeper since I read
"readconf.c:read_config_file_depth" in there. Does the same happen on a
fresh Jammy guest that has all-default config files? Or only to this
particular guest that you have?

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

Title:
  "User process fault: interruption code 0011 ilc:3" on SSH
  client/server upon Jammy upgrade

Status in openssh package in Ubuntu:
  New

Bug description:
  This s390x VM has been upgraded to Jammy, including the host (qemu-
  system-s390x 1:6.2+dfsg-2ubuntu6).  Now any attempt to use ssh, or any
  incoming sshd attempt immediately results in e.g.:

  ryan@s390x-dev:~$ ssh g...@github.com
  [  433.672800] User process fault: interruption code 0011 ilc:3 in 
libc.so.6[3ffa6c0+1ca000]
  [  433.672946] Failing address: 02aa0b84d000 TEID: 02aa0b84d800
  [  433.672977] Fault in primary space mode while using user ASCE.
  [  433.673030] AS:02bc01c7 R3:087cc007 S:0798a000 
P:0400 
  Segmentation fault (core dumped)

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


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


[Touch-packages] [Bug 1970076] Re: "User process fault: interruption code 0011 ilc:3" on SSH client/server upon Jammy upgrade

2022-04-26 Thread Christian Ehrhardt
(gdb) bt
#0  __GI__IO_default_xsputn (n=, data=, 
f=) at libioP.h:947
#1  __GI__IO_default_xsputn (f=0x3ffcbc7c2e8, data=, 
n=2929360903402) at genops.c:370
#2  0x03ffa6c7896c in outstring_func (done=11, length=2929360903402, 
string=0x2aa0b841cea <__func__.3.lto_priv.14> "read_config_file_depth", 
s=0x3ffcbc7c2e8) at ../libio/libioP.h:947
#3  __vfprintf_internal (s=s@entry=0x3ffcbc7c2e8, format=, 
format@entry=0x2aa0b81dea2 "%.48s:%.48s():%d (pid=%ld)", 
ap=ap@entry=0x3ffcbc7c4d0, mode_flags=mode_flags@entry=2)
at vfprintf-internal.c:1517
#4  0x03ffa6c8a024 in __vsnprintf_internal (string=0x3ffcbc7c5c8 
"readconf.c:read_config_file_depth", maxlen=, 
format=0x2aa0b81dea2 "%.48s:%.48s():%d (pid=%ld)", 
args=args@entry=0x3ffcbc7c4d0, mode_flags=mode_flags@entry=2) at 
vsnprintf.c:114
#5  0x03ffa6d2053a in ___snprintf_chk (s=, maxlen=, flag=, slen=, format=) at 
snprintf_chk.c:38
#6  0x02aa0b7d1686 in snprintf (__fmt=0x2aa0b81dea2 "%.48s:%.48s():%d 
(pid=%ld)", __n=128, __s=0x3ffcbc7c5c8 "readconf.c:read_config_file_depth")
at /usr/include/s390x-linux-gnu/bits/stdio2.h:71
#7  sshlogv (file=, func=, line=, 
showfunc=, level=, suffix=0x0, 
fmt=0x2aa0b84162e "Reading configuration data %.200s", args=0x3ffcbc7d3b0) 
at ../../log.c:473
#8  0x02aa0b7d1b88 in sshlog (file=, func=, 
line=, showfunc=, level=SYSLOG_LEVEL_DEBUG1, 
suffix=0x0, 
fmt=0x2aa0b84162e "Reading configuration data %.200s") at ../../log.c:434
#9  0x02aa0b80dbb6 in read_config_file_depth.constprop.0 
(filename=0x2aa0b811b42 "/etc/ssh/ssh_config", pw=0x2aa0d3609d0, 
host=, original_host=, 
flags=, activep=0x3ffcbc7d64c, 
want_final_pass=0x3ffcbc7e7c4, depth=0, options=) at 
../../readconf.c:2326
#10 0x02aa0b793d62 in read_config_file (options=0x2aa0b8518e0 , 
want_final_pass=0x3ffcbc7e7c4, flags=0, original_host=0x2aa0d364bc0 
"github.com", host=, 
pw=0x2aa0d3609d0, filename=0x2aa0b811b42 "/etc/ssh/ssh_config") at 
../../readconf.c:2295
#11 process_config_files (host_name=host_name@entry=0x2aa0d364bc0 "github.com", 
pw=pw@entry=0x2aa0d3609d0, final_pass=final_pass@entry=0, 
want_final_pass=want_final_pass@entry=0x3ffcbc7e7c4)
at ../../ssh.c:569
#12 0x02aa0b78d572 in main (ac=, av=) at 
../../ssh.c:1148

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

Title:
  "User process fault: interruption code 0011 ilc:3" on SSH
  client/server upon Jammy upgrade

Status in openssh package in Ubuntu:
  New

Bug description:
  This s390x VM has been upgraded to Jammy, including the host (qemu-
  system-s390x 1:6.2+dfsg-2ubuntu6).  Now any attempt to use ssh, or any
  incoming sshd attempt immediately results in e.g.:

  ryan@s390x-dev:~$ ssh g...@github.com
  [  433.672800] User process fault: interruption code 0011 ilc:3 in 
libc.so.6[3ffa6c0+1ca000]
  [  433.672946] Failing address: 02aa0b84d000 TEID: 02aa0b84d800
  [  433.672977] Fault in primary space mode while using user ASCE.
  [  433.673030] AS:02bc01c7 R3:087cc007 S:0798a000 
P:0400 
  Segmentation fault (core dumped)

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


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


[Touch-packages] [Bug 1970076] Re: "User process fault: interruption code 0011 ilc:3" on SSH client/server upon Jammy upgrade

2022-04-26 Thread Christian Ehrhardt
Hi,
for comparison on another system I've taken a Host (was impish before upgrade) 
and created guests with Xenial, Bionic, Focal, Jammy.
All worked fine at this stage - ssh login and health of guests/hosts was good.
Then I upgraded the Host to Jammy (as the reporter did).

Example of the simple tests made:
#log into jammy, from there log into focal
ssh -t ubuntu@192.168.122.177 "ssh ubuntu@192.168.122.39"
#log into focal, from there log into jammy
ssh -t ubuntu@192.168.122.39 "ssh ubuntu@192.168.122.177"

=> That was all fine initially (impish)
=> That was all still fine after the upgrade to jammy
=> And it was still fine after restarting the guests (to use the new qemu)

So it can't be reproduced easily, this would need to go into analyzing
the ssh crash dump file that is attached.

@Ryan - if you have any further insight on how/why your config might be
special let us know.

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

Title:
  "User process fault: interruption code 0011 ilc:3" on SSH
  client/server upon Jammy upgrade

Status in openssh package in Ubuntu:
  New

Bug description:
  This s390x VM has been upgraded to Jammy, including the host (qemu-
  system-s390x 1:6.2+dfsg-2ubuntu6).  Now any attempt to use ssh, or any
  incoming sshd attempt immediately results in e.g.:

  ryan@s390x-dev:~$ ssh g...@github.com
  [  433.672800] User process fault: interruption code 0011 ilc:3 in 
libc.so.6[3ffa6c0+1ca000]
  [  433.672946] Failing address: 02aa0b84d000 TEID: 02aa0b84d800
  [  433.672977] Fault in primary space mode while using user ASCE.
  [  433.673030] AS:02bc01c7 R3:087cc007 S:0798a000 
P:0400 
  Segmentation fault (core dumped)

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


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


[Touch-packages] [Bug 1962843] Re: Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-networkd.socket

2022-04-07 Thread Christian Ehrhardt
As with the other case - Since we couldn't get a hold how to fix/debug
this I'm glad to hear that!

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

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

Title:
  Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to
  adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-
  networkd.socket

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Problem:
  Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to  
adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-networkd.socket

  Analysis
  Compared with Ubuntu 21.04 desktop image, there is a difference in 
/usr/lib/systemd/system/systemd-networkd.socket, "shutdown.target" is added to 
Before and Conflicts options.

  Ubuntu 22.04
[Unit]
Description=Network Service Netlink Socket
Documentation=man:systemd-networkd.service(8) man:rtnetlink(7)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
Before=sockets.target shutdown.target
Conflicts=shutdown.target
  Ubuntu 21.04
[Unit]
Description=Network Service Netlink Socket
Documentation=man:systemd-networkd.service(8) man:rtnetlink(7)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
Before=sockets.target

  After removed "shutdown.target" from /usr/lib/systemd/system/systemd-
  networkd.socket in ubuntu 22.04 desktop, this issue did NOT reproduce
  since systemd-networkd.service starts much earlier

  So the root cause of the issue is that adding 'shutdown.target' leads
  systemd-networkd.service starts late which makes customization command
  '/usr/sbin/netplan apply' fail.

  Not sure why adding 'shutdown.target' to file
  /usr/lib/systemd/system/systemd-networkd.socket ?

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-04-06 Thread Christian Ehrhardt
** Tags removed: server-todo

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in PAM:
  New
Status in landscape-client package in Ubuntu:
  Fix Released
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in update-motd package in Ubuntu:
  Invalid
Status in update-notifier package in Ubuntu:
  Fix Released

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-04-06 Thread Christian Ehrhardt
FYI: Filed upstream at https://github.com/linux-pam/linux-pam/issues/452

** Bug watch added: github.com/linux-pam/linux-pam/issues #452
   https://github.com/linux-pam/linux-pam/issues/452

** Also affects: pam via
   https://github.com/linux-pam/linux-pam/issues/452
   Importance: Unknown
   Status: Unknown

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in PAM:
  Unknown
Status in landscape-client package in Ubuntu:
  Fix Released
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in update-motd package in Ubuntu:
  Invalid
Status in update-notifier package in Ubuntu:
  Fix Released

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-04-06 Thread Christian Ehrhardt
Overall the majority of this is now fixed and mitigated with the combination of:
 ubuntu-release-upgrader | 1:22.04.8  | jammy   | source
 landscape-client | 19.12-0ubuntu13| jammy   | source, amd64, 
arm64, armhf, ppc64el, riscv64, s390x
 update-notifier | 3.192.54   | jammy   | source, amd64, arm64, 
armhf, ppc64el, riscv64, s390x

There is still the IMHO valid feature request to pam_motd to not run at
all in non-interactive sessions which I'll need to file upstream.

But already in a system with these updates:
ubuntu@login-jammy:~$ dpkg -l ubuntu-release-upgrader-core landscape-common 
update-notifier-common
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++--===--===
ii  landscape-common 19.12-0ubuntu13 amd64Landscape 
administration system client - Common files
ii  ubuntu-release-upgrader-core 1:22.04.8   all  manage release 
upgrades
ii  update-notifier-common   3.192.54all  Files shared 
between update-notifier and other packages


I now get reasonable results.
Down from 70-80 seconds to ~20-25 => almost down to 1/4 of the time.
At the same time the system is ~16% less busy, so other things running won't 
stall it that much either and vice versa.


What is left looks as in the test sessions.
This now mostly comes down to the fact that logging in for every command will 
in general have overhead to spawn the session. For another gain pam_motd can be 
disabled as shown above, but that does not reduce it to zero overhead - so as 
explained any mutli-command submitting solution should still - even with the 
fix - try to use one login for all of them.

# Overhead  Command
#   ...
#
32.50%  swapper
26.67%  sshd   
 3.53%  dbus-daemon
 3.37%  systemd
 2.36%  run-parts  
 2.02%  systemd-logind 
 1.87%  find   
 1.85%  gdbus  
 1.48%  cat
 1.47%  update-motd-fsc
 1.22%  50-motd-news   
 1.17%  awk
 1.15%  systemd-journal
 1.11%  grep   
 1.10%  bash   
 1.05%  uname  
 0.98%  00-header  
 0.93%  91-release-upgr
 0.92%  97-overlayroot 
 0.81%  90-updates-avai
 0.80%  date   
 0.72%  cut
 0.68%  50-landscape-sy
 0.62%  env
 0.59%  ksoftirqd/0
 0.58%  95-hwe-eol 
 0.53%  stat   
 0.51%  id

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in landscape-client package in Ubuntu:
  Fix Released
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in update-motd package in Ubuntu:
  Invalid
Status in update-notifier package in Ubuntu:
  Fix Released

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does 

[Touch-packages] [Bug 1962843] Re: Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-networkd.socket

2022-03-31 Thread Christian Ehrhardt
Pengpeng/Yuhua - I have internally asked (at the same time I added the tag a 
few days ago)  for someone to look after it.
Nothing happened yet, so I pinged again.

In preparation of this - since most of Ubuntu developers won't have a
vsphere around to reproduce this. Is there any other way to expose this
problem?

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

Title:
  Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to
  adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-
  networkd.socket

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Problem:
  Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to  
adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-networkd.socket

  Analysis
  Compared with Ubuntu 21.04 desktop image, there is a difference in 
/usr/lib/systemd/system/systemd-networkd.socket, "shutdown.target" is added to 
Before and Conflicts options.

  Ubuntu 22.04
[Unit]
Description=Network Service Netlink Socket
Documentation=man:systemd-networkd.service(8) man:rtnetlink(7)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
Before=sockets.target shutdown.target
Conflicts=shutdown.target
  Ubuntu 21.04
[Unit]
Description=Network Service Netlink Socket
Documentation=man:systemd-networkd.service(8) man:rtnetlink(7)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
Before=sockets.target

  After removed "shutdown.target" from /usr/lib/systemd/system/systemd-
  networkd.socket in ubuntu 22.04 desktop, this issue did NOT reproduce
  since systemd-networkd.service starts much earlier

  So the root cause of the issue is that adding 'shutdown.target' leads
  systemd-networkd.service starts late which makes customization command
  '/usr/sbin/netplan apply' fail.

  Not sure why adding 'shutdown.target' to file
  /usr/lib/systemd/system/systemd-networkd.socket ?

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-30 Thread Christian Ehrhardt
I re-installed the former package content, rebooted the system and gave
it some more memory to get rid of any concerns in that regard (from the
perf data).

The diff of the actual content before/after was all reasonable (new
times, different package counts, but otherwise the same)

Consumption wise we have:

# Before fixes
real1m11.731s
us  sy  id  wa  st
71  20   9   0   0

59.16%  landscape-sysin
14.23%  swapper
 6.16%  sshd   
 5.78%  lsb_release
 3.35%  apt-config 
 0.86%  dbus-daemon
 0.80%  systemd
 0.59%  gdbus  
 0.56%  dpkg   
 0.48%  systemd-logind


# After fixes

real0m21.257s
us  sy  id  wa  st
32  34  34   0   0

42.00%  swapper
22.45%  sshd   
 2.94%  dbus-daemon
 2.79%  systemd
 2.08%  gdbus  
 2.07%  grep   
 1.88%  run-parts  
 1.58%  systemd-logind 
 1.46%  find   
 1.23%  bash   
 1.22%  update-motd-fsc
 1.18%  systemd-journal
 1.13%  cat

That is good.
Ready to open MRs for this.

At a very high summary:
- delay cut down by 2/3 of the initial duration
- consumption reduced by 71% (duration) and by 26% (consumption while running).
  This is multiplicative so for the example we have an saving of ~81.27% of cpu 
cycles

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in landscape-client package in Ubuntu:
  In Progress
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  In Progress
Status in update-motd package in Ubuntu:
  Invalid
Status in update-notifier package in Ubuntu:
  In Progress

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1893716/+subscriptions


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-30 Thread Christian Ehrhardt
With the three combined I get down to:

real0m20.900s
us  sy  id  wa  st
32  33  35   0   0

43.88%  swapper
21.48%  sshd   
 3.07%  dbus-daemon
 2.78%  systemd
 2.10%  gdbus  
 1.96%  grep   
 1.80%  run-parts  
 1.68%  systemd-logind 
 1.38%  find   
 1.24%  systemd-journal
 1.23%  bash   
 1.12%  update-motd-fsc
 1.10%  cat
 0.95%  awk
 0.85%  50-motd-news   
 0.76%  uname  
 0.70%  00-header  
 0.69%  91-release-upgr
 0.67%  97-overlayroot 
 0.67%  50-landscape-sy
 0.62%  date   
 0.61%  90-updates-avai
 0.56%  95-hwe-eol 
 0.54%  cut 

None of the remaining big contributions to consumption is from the MOTD
efforts (all <2%).

That is reasonable, nice time gain as well as reduced cpu consumption.

** Changed in: landscape-client (Ubuntu)
   Status: New => In Progress

** Changed in: ubuntu-release-upgrader (Ubuntu)
   Status: New => In Progress

** Changed in: update-notifier (Ubuntu)
   Status: New => In Progress

** Changed in: update-notifier (Ubuntu)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Changed in: ubuntu-release-upgrader (Ubuntu)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Changed in: landscape-client (Ubuntu)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Changed in: landscape-client (Ubuntu)
   Importance: Undecided => Critical

** Changed in: ubuntu-release-upgrader (Ubuntu)
   Importance: Undecided => High

** Changed in: update-notifier (Ubuntu)
   Importance: Undecided => High

** Changed in: update-motd (Ubuntu)
   Importance: High => Medium

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

** Changed in: update-motd (Ubuntu)
   Status: Confirmed => Invalid

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in landscape-client package in Ubuntu:
  In Progress
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  In Progress
Status in update-motd package in Ubuntu:
  Invalid
Status in update-notifier package in Ubuntu:
  In Progress

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1893716/+subscriptions


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-30 Thread Christian Ehrhardt
#3 50-landscape-sysinfo

The landscape part already has a statement about "when it is from" as it
is not re-executed on high load. This is handy as it will also ensure
there is no confusion "from when" this info is if we skip for too
frequent invocations.

Since it has an alternate less useful output I've added checks to
replace this more often and not replace a good output with a bad one.

--- orig/50-landscape-sysinfo   2022-03-30 07:53:04.320551811 +
+++ /etc/update-motd.d/50-landscape-sysinfo 2022-03-30 10:04:00.536053398 
+
@@ -1,17 +1,39 @@
 #!/bin/sh
-# pam_motd does not carry the environment
-[ -f /etc/default/locale ] && . /etc/default/locale
-export LANG
-cores=$(grep -c ^processor /proc/cpuinfo 2>/dev/null)
-[ "$cores" -eq "0" ] && cores=1
-threshold="${cores:-1}.0"
-if [ $(echo "`cut -f1 -d ' ' /proc/loadavg` < $threshold" | bc) -eq 1 ]; then
-echo
-echo -n "  System information as of "
-/bin/date
-echo
-/usr/bin/landscape-sysinfo
-else
-echo
-echo " System information disabled due to load higher than $threshold"
+
+# do try refresh this more than once per minute
+# Due to cpu consumption and login delays (LP: #1893716)
+stamp="/var/lib/landscape/landscape-sysinfo.cache"
+NEED_UPDATE="FALSE"
+find $stamp -newermt 'now-1 minutes' 2> /dev/null | grep -q -m 1 '.' || 
NEED_UPDATE="TRUE"
+# If the last report in cache wasn't useful (load was too high) still wait at 
least 5 seconds
+if grep -q "System information disabled" $stamp 2> /dev/null; then
+find $stamp -newermt 'now-5 seconds' 2> /dev/null | grep -q -m 1 '.' || 
NEED_UPDATE="TRUE"
 fi
+
+if [ "$NEED_UPDATE" = "TRUE" ]; then
+# pam_motd does not carry the environment
+[ -f /etc/default/locale ] && . /etc/default/locale
+export LANG
+cores=$(grep -c ^processor /proc/cpuinfo 2>/dev/null)
+[ "$cores" -eq "0" ] && cores=1
+threshold="${cores:-1}.0"
+if [ $(echo "`cut -f1 -d ' ' /proc/loadavg` < $threshold" | bc) -eq 1 ]; 
then
+   (
+echo
+echo -n "  System information as of "
+/bin/date
+echo
+/usr/bin/landscape-sysinfo
+) > $stamp
+else
+   # do not replace a formerly good result due to load
+   if ! grep -q "System information as of" $stamp 2> /dev/null; then
+   (
+   echo
+   echo " System information disabled due to load higher than 
$threshold"
+   ) > $stamp
+   fi
+fi
+fi
+
+[ ! -r "$stamp" ] || cat "$stamp"

# Info:
It might be worth to note, the optimizations to 95-hwe-eol and 
91-release-upgrade save CPU cycles (which is good and worth on its own), but do 
not improve the delay much.
The optimization to 

P.S. I'll need some minor updates for style and avoiding errors (e.g.
the && exit 0 was working but could be bad)

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in landscape-client package in Ubuntu:
  In Progress
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  In Progress
Status in update-motd package in Ubuntu:
  Invalid
Status in update-notifier package in Ubuntu:
  In Progress

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being 

[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-30 Thread Christian Ehrhardt
#2 95-hwe-eol / update-motd-hwe-eol

Sadly this already does some caching in update-motd-hwe-eol by checking
if the last of these checks is older than an update to the source lists.
But to do so it has already executed the - relatively - rather expensive
apt-config calls.

Since it comes down to checking new sources.lists there is no need to
update this more often than once every few minutes or hours. Could be
even slower without loosing most of its value, but we already achieve
most of what we need with a delay of ~1h.

We started with:
 5.37%  apt-config
Now:
 -- no more present


--- orig/95-hwe-eol 2022-03-30 07:53:18.396529018 +
+++ /etc/update-motd.d/95-hwe-eol   2022-03-30 09:13:16.160985148 +
@@ -1,5 +1,11 @@
 #!/bin/sh
 
+# this stamp is created and updated by 
/usr/lib/update-notifier/update-motd-hwe-eol
+stamp="/var/lib/update-notifier/hwe-eol"
+
+# do not try to refresh this more than once per hour
+find $stamp -newermt 'now-1 hours' 2> /dev/null | grep -m 1 '.' && exit 0
+
 if [ -x /usr/lib/update-notifier/update-motd-hwe-eol ]; then
 exec /usr/lib/update-notifier/update-motd-hwe-eol
 fi


No big need left to reduce the apt-config usage in update-motd-hwe-eol after 
this change.

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in landscape-client package in Ubuntu:
  New
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  New
Status in update-motd package in Ubuntu:
  Confirmed
Status in update-notifier package in Ubuntu:
  New

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1893716/+subscriptions


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-30 Thread Christian Ehrhardt
Collecting snippets:

This one worked, proven by eliminating lsb_release on the consumption
charts.

#1 Caching for 91-release-upgrade:

--- orig/91-release-upgrade 2022-03-30 07:53:26.560515795 +
+++ /etc/update-motd.d/91-release-upgrade   2022-03-30 07:59:05.819971148 
+
@@ -1,7 +1,12 @@
 #!/bin/sh
 
 # if the current release is under development there won't be a new one
-if [ "$(lsb_release -sd | cut -d' ' -f4)" = "(development" ]; then
+[ -r /etc/lsb-release ] && . /etc/lsb-release
+if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
+DISTRIB_DESCRIPTION=$(lsb_release -s -d)
+fi
+
+if [ "$(echo "$DISTRIB_DESCRIPTION" | cut -d' ' -f4)" = "(development" ]; then
 exit 0
 fi

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in landscape-client package in Ubuntu:
  New
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  New
Status in update-motd package in Ubuntu:
  Confirmed
Status in update-notifier package in Ubuntu:
  New

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1893716/+subscriptions


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-29 Thread Christian Ehrhardt
Summarizing the low hanging fruits here:
- Add caching to 50-landscape-sysinfo
- Add caching to  95-hwe-eol
- /usr/lib/update-notifier/update-motd-hwe-eol calls apt-config multiple times.
  consider reducing those calls
- 91-release-upgrade unconditionally calls lsb_release which is expensive.
  Use the same check others use

The rest already uses caching AND/OR is small, fast and simple.

The follow on of making pam_motd truly not do anything on non-
interactive can then be a follow on case and would no more be that
important.

For these fixes three packages need to be touched:
Source: ubuntu-release-upgrader
Source: update-notifier
Source: landscape-client

** Also affects: ubuntu-release-upgrader (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: update-notifier (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: landscape-client (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in landscape-client package in Ubuntu:
  New
Status in pam package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  New
Status in update-motd package in Ubuntu:
  Confirmed
Status in update-notifier package in Ubuntu:
  New

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1893716/+subscriptions


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-29 Thread Christian Ehrhardt
Analysis has spotted 91-release-upgrade as the most likely expensive remainder.
pam_motd enabled, but disabled:
- 50-landscape-sysinfo
- 91-release-upgrade
- 95-hwe-eol disabled

Bionic
real0m18.669s
us sy id wa st
22  23  55   0   0

Focal
real0m23.821s
us sy id wa st
40  39  21   0   0

Jammy
real0m19.616s
us sy id wa st
33  30  37   0   0

This is pretty close to "no-motd" and has no single spike left.
The next ones I found in the list are now low and already use caching.
The improvement for those would be a (slower and more complex) modification to 
pam_motd to detect and skip on non-interactive sessions.

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in pam package in Ubuntu:
  Confirmed
Status in update-motd package in Ubuntu:
  Confirmed

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-29 Thread Christian Ehrhardt
pam_motd enabled, but 50-landscape-sysinfo and 95-hwe-eol disabled

Bionic
real0m25.952s
us sy id wa st
41  22  37   0   0

Focal
real0m30.592s
us sy id wa st
49  33  19   0   0

Jammy
real0m25.395s
us sy id wa st
44  28  29   0   0

That is still quite some overhead (~+60% to no motd) but clearly those
are the two worst contributors.

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in pam package in Ubuntu:
  Confirmed
Status in update-motd package in Ubuntu:
  Confirmed

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-29 Thread Christian Ehrhardt
pam_motd completely disabled in /etc/pam.d/sshd

Bionic
real0m15.540s
us  sy  id  wa  st
18  14  68   0   0

Focal
real0m16.937s
us  sy  id  wa  st
43  40  17   0   0

Jammy
real0m16.260s
us  sy  id  wa  st
36  19  45   0   0

The remaining difference of those is in the noise-range.
Some difference in the cycles consumed though, but not too bad.

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in pam package in Ubuntu:
  Confirmed
Status in update-motd package in Ubuntu:
  Confirmed

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-29 Thread Christian Ehrhardt
Time and CPU consumption (results are rather consistent BTW):

Bionic
real1m11.714s
user0m2.577s
sys 0m0.410s

procs ---memory-- ---swap-- -io 
-system-- cpu -timestamp-
 r  b swpd free buffcache   si   sobibo 
  in   cs  us  sy  17   0   0 2022-03-29 13:13:15
 0  00   22103628312   15698000 0  2124 
4319 1330  67  19  14   0   0 2022-03-29 13:13:20
 1  00   19677228320   15852400 011 
4290 1274  68  19  13   0   0 2022-03-29 13:13:25
...

Focal
real0m44.742s
user0m2.489s
sys 0m0.477s

procs ---memory-- ---swap-- -io 
-system-- cpu -timestamp-
 r  b swpd free buffcache   si   sobibo 
  in   cs  us  sy  id  wa  st UTC
 1  004278418448   26704800 011 
4554 3561  67  24   8   0   0 2022-03-29 13:14:13
 1  003773218456   26910000 012 
4577 3851  65  25  10   0   0 2022-03-29 13:14:18
 1  001840018464   27081200 011 
4554 3547  67  24   9   0   0 2022-03-29 13:14:23


Jammy
real1m8.010s
user0m2.436s
sys 0m0.484s

--procs-- ---memory-- ---swap-- 
-io -system-- cpu -timestamp-
   rb swpd free buffcache   si   sobi   
 bo   in   cs  us  sy  id  wa  st UTC
   0005826417760   25854400 0   
  9 4374 1953  68  20  11   0   0 2022-03-29 13:15:20
   1003284417772   26033200 0   
 16 4352 1851  68  20  11   0   0 2022-03-29 13:15:25
   1004942817784   26226800 0   
 17 4387 1985  67  22  12   0   0 2022-03-29 13:15:30

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in pam package in Ubuntu:
  Confirmed
Status in update-motd package in Ubuntu:
  Confirmed

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-29 Thread Christian Ehrhardt
I wanted to get a better feeling about this before jumping to action.
Therefore I have created three 1G/1vcpu KVM guests Bionic/Focal/Jammy to test 
and compare this on.

I do not need hot-loop analysis or anything down to instructions, so no debug 
symbols needed.
For now I only want to know:
1. how much time a bunch of low effort logins take (we measure only the 
overhead)
2. how much cpu is utilized while doing that
3. how that work is spread across programs (disable them one by one and look at 
data)


The two I see most are:
- /usr/lib/update-notifier/update-motd-hwe-eol
apt-config shell SourceList Dir::Etc::sourcelist
- /etc/update-motd.d/50-landscape-sysinfo
/usr/bin/python3 /usr/bin/landscape-sysinfo

Very non-pro data gathering:

$ cat tracestart.sh
#!/bin/bash
sudo rm perf.data perf.log log.vmstat
nohup vmstat -wt 5 &> log.vmstat &
nohup perf record --event cpu-clock --all-cpus &> perf.log &
sleep 5

$ cat traceend.sh
#!/bin/bash
killall perf
killall vmstat
cat perf.log
cat log.vmstat
#perf report --sort comm --stdio

Most simple load involving those helpers.
for sys in login-bionic login-focal login-jammy; do ssh $sys "sudo 
~/tracestart.sh"; time for i in $(seq 1 100); do ssh $sys "/bin/true"; done; 
ssh $sys "sudo ~/traceend.sh"; done

I'll get those numbers for Bionic/Focal/Jammy and enabling/disabling it
all and/or individual elements.

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in pam package in Ubuntu:
  Confirmed
Status in update-motd package in Ubuntu:
  Confirmed

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2022-03-29 Thread Christian Ehrhardt
I can't test this reliably (as stated in the SRU description), but at
least I can say I haven't seen it in the last 24h :-) I think this is on
@gjolly to try to reproduce it in the mentioned azure test environment.

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

Title:
  dbus timeout-ed during an upgrade, taking services down including gdm

Status in D-Bus:
  Unknown
Status in systemd:
  New
Status in accountsservice package in Ubuntu:
  Invalid
Status in dbus package in Ubuntu:
  Invalid
Status in gnome-shell package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in accountsservice source package in Focal:
  Invalid
Status in dbus source package in Focal:
  Invalid
Status in gnome-shell source package in Focal:
  Invalid
Status in systemd source package in Focal:
  Fix Committed
Status in accountsservice source package in Groovy:
  Invalid
Status in dbus source package in Groovy:
  Invalid
Status in gnome-shell source package in Groovy:
  Invalid
Status in accountsservice source package in Hirsute:
  Invalid
Status in dbus source package in Hirsute:
  Won't Fix
Status in gnome-shell source package in Hirsute:
  Invalid
Status in accountsservice source package in Impish:
  Invalid
Status in dbus source package in Impish:
  Invalid
Status in gnome-shell source package in Impish:
  Invalid
Status in systemd source package in Impish:
  Fix Committed
Status in accountsservice source package in Jammy:
  Invalid
Status in dbus source package in Jammy:
  Invalid
Status in gnome-shell source package in Jammy:
  Invalid
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  [Impact]

   * There's currently a deadlock between PID 1 and dbus-daemon: in some
  cases dbus-daemon will do NSS lookups (which are blocking) at the same
  time PID 1 synchronously blocks on some call to dbus-daemon (e.g. 
`GetConnectionUnixUser` DBus call). Let's break
  that by setting SYSTEMD_NSS_DYNAMIC_BYPASS=1 env var for dbus-daemon,
  which will disable synchronously blocking varlink calls from nss-systemd
  to PID 1.

   * This can lead to delayed boot times

   * It can also lead to dbus-daemon being killed/re-started, taking
  down other services with it, like GDM, killing user sessions on the
  way (e.g. on installing updates)

  [Test Plan]

   * This bug is really hard to reproduce, as can be seen from the
  multi-year long discussion at
  https://github.com/systemd/systemd/issues/15316

   * Canonical's CPC team has the ability to reproduce  this issue (with
  a relatively high probability) in their Azure test environment, due to
  the specific setup they are using

   * So our test plan is to ask CPC (@gjolly) for confirmation if the
  issue is fixed.

  [Where problems could occur]

   * This fix touches the communication between systemd and dbus daemon,
  especially the NSS lookup, so if something is broken the (user-)name
  resolution could be broken.

   * As a workaround dbus-daemon could be replaced by dbus-broker, which
  never showed this issue or the behaviour could be changed back by
  using the `SYSTEMD_NSS_DYNAMIC_BYPASS` env variable, like this:

  #/etc/systemd/system/dbus.service.d/override.conf
  [Service]
  Environment=SYSTEMD_NSS_DYNAMIC_BYPASS=0

  [Other Info]
   
   * Fixed upstream (v251) in https://github.com/systemd/systemd/pull/22552

  
  === Original Description ===


  
  This morning I found my computer on the login screen.
  But not the one of the screen log, no a new one - so something must have 
crashed.

  Logging in again confirmed that all apps were gone and the gnome shell
  was brought down what seems like triggered by a background update o
  accountsservice.

  As always things are not perfectly clear :-/
  The following goes *back* in time through my logs one by one.

  Multiple apps crashed at 06:09, but we will find later that this is a follow 
on issue of the underlying gnome/X/... recycling.
  -rw-r-  1 paelzer  whoopsie 52962868 Apr  8 06:09 
_usr_bin_konversation.1000.crash
  -rw-r-  1 paelzer  whoopsie   986433 Apr  8 06:09 
_usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash

  rdkit was failing fast and giving up (that will be a different bug, it just 
seems broken on my system):
  Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling 
Policy Service.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called 
chroot.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped 
privileges.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited 
resources.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: 
Resource temporarily unavailable
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread.
  

[Touch-packages] [Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

2022-03-28 Thread Christian Ehrhardt
The only current interactivity detection code in pam is part of a
pam.conf -> pam.d conversion tool that won't be useful here.

The pam_motd code emits content via things like try_to_display_fd.
A message is created and then printed via pam_info.
Which is actually pam_prompt which wraps pam_vprompt

This gets the conversation function via
  retval = pam_get_item (pamh, PAM_CONV, );
and on that it then emits the message
  retval = conv->conv (1, , _resp, conv->appdata_ptr);

Either via this PAM_CONV and then attributes of that channel (as it is
what we'd print on) OR via something like  pam_get_item(pamh, PAM_TTY,
); we might get access from pam_motd to something that we can work
out if it is interactive.

I'm busy with other things now (for the rest of today), but I want ton continue 
tomorrow.
I want this at least to get into a clear state that is sure if:
a) this is as important as I think
b) the steps needed from here are clear

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

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

** Changed in: update-motd (Ubuntu)
   Status: Triaged => Confirmed

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

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

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in pam package in Ubuntu:
  Confirmed
Status in update-motd package in Ubuntu:
  Confirmed

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #sessionoptional pam_motd.so  motd=/run/motd.dynamic
  #sessionoptional pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
  # Fall back to using the very slow lsb_release utility
  DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

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


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


[Touch-packages] [Bug 1962843] Re: Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-networkd.socket

2022-03-25 Thread Christian Ehrhardt
** Tags added: rls-jj-incoming

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

Title:
  Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to
  adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-
  networkd.socket

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Problem:
  Guest OS customization fail for ubuntu 22.04 desktop in vsphere due to  
adding 'shutdown.target' in file /usr/lib/systemd/system/systemd-networkd.socket

  Analysis
  Compared with Ubuntu 21.04 desktop image, there is a difference in 
/usr/lib/systemd/system/systemd-networkd.socket, "shutdown.target" is added to 
Before and Conflicts options.

  Ubuntu 22.04
[Unit]
Description=Network Service Netlink Socket
Documentation=man:systemd-networkd.service(8) man:rtnetlink(7)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
Before=sockets.target shutdown.target
Conflicts=shutdown.target
  Ubuntu 21.04
[Unit]
Description=Network Service Netlink Socket
Documentation=man:systemd-networkd.service(8) man:rtnetlink(7)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
Before=sockets.target

  After removed "shutdown.target" from /usr/lib/systemd/system/systemd-
  networkd.socket in ubuntu 22.04 desktop, this issue did NOT reproduce
  since systemd-networkd.service starts much earlier

  So the root cause of the issue is that adding 'shutdown.target' leads
  systemd-networkd.service starts late which makes customization command
  '/usr/sbin/netplan apply' fail.

  Not sure why adding 'shutdown.target' to file
  /usr/lib/systemd/system/systemd-networkd.socket ?

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


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


[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units

2022-03-24 Thread Christian Ehrhardt
This is still present in jammy as 
debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch
If we want to keep this as long as there could be an 18.04 that is like 2028 at 
least.

So AFAIU this bug is actually asking LXD to consider a backport (if
possible) to then drop the revert from systemd (all releases).

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

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

** Also affects: lxd (Ubuntu Focal)
   Importance: Undecided
   Status: New

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

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

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

** Also affects: lxd (Ubuntu Impish)
   Importance: Undecided
   Status: New

** No longer affects: lxd (Ubuntu Focal)

** No longer affects: lxd (Ubuntu Impish)

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

Title:
  systemd ignores RootDirectory option in .service units

Status in lxd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in lxd source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Impish:
  New

Bug description:
  The version of systemd (249.5-2ubuntu4) currently packaged for the
  Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the
  RootDirectory= option in systemd service files. With RootDirectory,
  systemd should start the service after calling chroot() on the
  supplied directory.

  To test/reproduce, create a test service file with the following
  contents:

  
  # /etc/systemd/system/lsb-release.service
  [Unit]
  Description=LSB Release Information

  [Service]
  Type=simple
  RootDirectory=/var/chroot/trusty
  ExecStartPre=/bin/pwd
  ExecStart=/usr/bin/lsb_release -a

  
  You should have a chroot environment in the specified RootDirectory, even 
though you can still deduce if systemd attempted to chroot or not from the 
resulting error message.

  In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in
  the chroot environment. On systems NOT affected by the problem, I get
  the following result when I start this test service. This is what I'd
  expect.

  
  Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information...
  Jan 25 20:40:40 dolly pwd[361]: /
  Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information.
  Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available.
  Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu
  Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS
  Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04
  Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty
  Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded.

  
  On the problematic system, however, I get the following result.

  
  Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information...
  Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information.
  Jan 25 21:21:08 savelog pwd[81114]: /
  Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available.
  Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu
  Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy 
Jellyfish (development branch)
  Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04
  Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy
  Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated 
successfully.

  
  It totally run the service on the host's root filesystem, it didn't care even 
the slightest that a RootDirectory is specified.

  Tested on the following releases / systemd versions:

  Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT
  systemd 237
  +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid

  Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT
  systemd 245 (245.4-4ubuntu3.15)
  +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 
default-hierarchy=hybrid

  Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT
  systemd 248 (248.3-1ubuntu8.2)
  +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL 
+ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP 
-LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD 
-XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

  Ubuntu 22.04 

[Touch-packages] [Bug 1959054] Re: debhelper restarts services marked --no-restart-on-upgrade

2022-03-21 Thread Christian Ehrhardt
See bug 1965758 this also breaks focal-backports - please upload the fix
there as well.

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

Title:
  debhelper restarts services marked --no-restart-on-upgrade

Status in debconf package in Ubuntu:
  Fix Released
Status in debhelper package in Ubuntu:
  Fix Released
Status in docker.io package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released
Status in debconf source package in Jammy:
  Fix Released
Status in debhelper source package in Jammy:
  Fix Released
Status in docker.io source package in Jammy:
  Fix Released
Status in libvirt source package in Jammy:
  Fix Released
Status in debconf package in Debian:
  New
Status in debhelper package in Debian:
  New

Bug description:
  Debian bug #994204 (https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=994204) describes a flaw in debhelper that
  results in the postinst being generated in such a fashion that
  services marked --no-stop-on-upgrade (or its deprecated alias --no-
  restart-on-upgrade), restart anyway.

  Please note: this is nothing to do with the --no-restart-after-upgrade
  flag (which is, somewhat confusingly IMO, unrelated).

  I've confirmed that the flaw appears to be present in the jammy
  version of debhelper (though not impish) and that packages generated
  with it appear to contain the flawed postinst (I first encountered
  this whilst working on the open-iscsi merge), though I haven't yet
  managed to test that the flaw exhibits itself on upgrade (though I'd
  say from the presence of the flaw in the postinst, that it's a
  reasonable inference that it will).

  In dbus (the merge of which I'm currently working on), Debian has
  worked around this but given I've now run into two affected packages
  (open-iscsi and dbus), only one of which has a work-around, I'd much
  rather we got debhelper fixed up and rebuilt affected packages?

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


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


[Touch-packages] [Bug 1712223] Re: open-vm-tools does not work under wayland

2022-03-21 Thread Christian Ehrhardt
Thanks for the ping on this old case Alexander!

Can you confirm that this is what you see on 22.04 with the there recent
2:11.3.5-1ubuntu4 version of open-vm-tools?

I have subscribed John Wolfe who looks after open-vm-tools from VMwares
side and might have more details.

Further I added a bug task for "wayland" so that the Desktop team can
have a look as well.

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

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

Title:
  open-vm-tools does not work under wayland

Status in open-vm-tools package in Ubuntu:
  Confirmed
Status in wayland package in Ubuntu:
  New

Bug description:
  At first I thought this bug was caused with the recent changes in
  open-vm-tools 10.1.10; however, after restoring my VM to the snapshot
  that had 17.04 and re-performing the dist-upgrade with open-vm-tools
  and open-vm-tools-desktop held at 10.1.5 I am experiencing the same
  issue where VMWare Workstation no longer can interact with display
  resolution detection of the host monitor(s). Multiple monitor support
  is also lost in the update process.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: xorg 1:7.7+19ubuntu1
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.6-0ubuntu6
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Aug 21 17:09:59 2017
  DistUpgraded: 2017-08-07 09:05:02,559 DEBUG found components: 
{'artful-updates': {'multiverse', 'restricted', 'universe', 'main'}, 'artful': 
{'multiverse', 'restricted', 'universe', 'main'}, 'artful-security': 
{'multiverse', 'restricted', 'universe', 'main'}}
  DistroCodename: artful
  DistroVariant: ubuntu
  DkmsStatus:
   virtualbox, 5.1.26, 4.10.0-30-generic, x86_64: installed
   virtualbox, 5.1.26, 4.12.0-11-generic, x86_64: installed
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   VMware SVGA II Adapter [15ad:0405] (prog-if 00 [VGA controller])
 Subsystem: VMware SVGA II Adapter [15ad:0405]
  InstallationDate: Installed on 2016-11-30 (264 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: VMware, Inc. VMware Virtual Platform
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.12.0-11-generic 
root=UUID=dd284488-2aa1-430d-a510-0527b909f561 ro find_preseed=/preseed.cfg 
auto noprompt priority=critical locale=en_US quiet
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: Upgraded to artful on 2017-08-07 (14 days ago)
  dmi.bios.date: 07/02/2015
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: 440BX Desktop Reference Platform
  dmi.board.vendor: Intel Corporation
  dmi.board.version: None
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 1
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd07/02/2015:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
  dmi.product.name: VMware Virtual Platform
  dmi.product.version: None
  dmi.sys.vendor: VMware, Inc.
  version.compiz: compiz 1:0.9.13.1+17.10.20170720-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.82-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.0~rc4-0ubuntu3
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.0~rc4-0ubuntu3
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.3-1ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.9.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20170309-0ubuntu1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
  xserver.bootTime: Mon Aug 21 16:27:55 2017
  xserver.configfile: default
  xserver.devices:
   inputPower Button KEYBOARD, id 6
   inputAT Translated Set 2 keyboard KEYBOARD, id 7
   inputVirtualPS/2 VMware VMMouse MOUSE, id 8
   inputVirtualPS/2 VMware VMMouse MOUSE, id 9
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.outputs: Output
Virtual2Virtual3Virtual4Virtual5Virtual6
Virtual7Virtual8
  xserver.version: 2:1.19.3-1ubuntu1.1
  xserver.video_driver: vmware

To manage notifications about this 

[Touch-packages] [Bug 1528921] Re: rsync hangs on select(5, [], [4], [], {60, 0}

2022-03-07 Thread Christian Ehrhardt
There was a bad tag update before, this is verified on Focal as well.
Fixed now ...

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

** Changed in: rsync (Ubuntu Focal)
   Importance: Undecided => Medium

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

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

Title:
  rsync hangs on select(5, [], [4], [], {60, 0}

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Bionic:
  Fix Released
Status in rsync source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  What the user suffering from this bug experiences is that the big
  amount of informative messages related to the copy process with the
  three spawned processes(sender, receiver and generator)  exhaust the
  I/O buffer and the sync gets stuck, either because there are too many
  files to synchronise and/or because too many detail messages (levels
  of verbose mode) have been requested in the output.

  The fix, that comes from upstream and is applied there since version
  3.2.0., increments the size of the receiver's I/O buffer.

  [Test Plan]
  This test plan is for Focal, but it's the same for Bionic.

  0.Preparing the test environment:

  #Preparing the container
  lxc launch images:ubuntu/focal rsync-iobuffer-focal
  lxc shell rsync-iobuffer-focal
  apt update -y
  apt upgrade -y

  #Installing necessary tools
  apt install rsync

  #Get test cases from comments #16 and #19 on this LP bug: As test case
  #16 covers both aspects (a lot of files and upper verbosity) and test
  #19 uses a huge tarball (120 Mb), I'm removing from this SRU the #19
  scenario  (but, please, feel to reach me it if you consider it
  necessary and I'll provide the steps and bad/good scenarios).

  cd /tmp/

  #16
  Paste the contents of https://pastebin.com/raw/ctzJJGwt:

  #!/bin/bash
  mkdir source_dir
  pushd source_dir
  dd if=/dev/zero of=source bs=600K count=1

  for i in `seq 1 11500`;
  do
  cp -v source file_$i;
  done

  rm source

  for i in `seq 1 10`;
  do
   dd if=/dev/zero of=file_large_$i bs=200M count=1
  done

  popd

  echo "Created 11500 files with size 600K and 10 files with size 200M, try the 
following command:"
  echo "rsync -avvvz --delete source_dir target_dir"

  in a new file script_comment16.sh

  chmod +x script_comment16.sh
  ./script_comment16.sh

  1. Bad cases (without and with using strace):

  # Scenario from comment 16
  $ rsync -avvvz --delete source_dir target_dir
  sending incremental file list
  [sender] make_file(source_dir,*,0)
  send_file_list done
  [sender] pushing local filters for /root/source_dir/
  [sender] make_file(source_dir/file_3048,*,2)
  [sender] make_file(source_dir/file_11358,*,2)
  [sender] make_file(source_dir/file_5914,*,2)
  [sender] make_file(source_dir/file_5880,*,2)
  [sender] make_file(source_dir/file_9318,*,2)
  [sender] make_file(source_dir/file_5539,*,2)
  [...]
  sending file_sum
  false_alarms=0 hash_hits=0 matches=0
  sender finished source_dir/file_10807
  send_files(903, source_dir/file_10808)
  send_files mapped source_dir/file_10808 of size 614400
  calling match_sums source_dir/file_10808
  source_dir/file_10808

  It hangs here, where using strace we can see:

  $ strace rsync -avvvz --delete source_dir target_dir
  source_dir/file_11280
  read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 262144) 
= 262144
  read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 262144) 
= 262144
  read(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 90112) = 
90112
  select(6, [5], [4], [5], {tv_sec=60, tv_usec=0}) = 1 (in [5], left 
{tv_sec=59, tv_usec=96})
  read(5, 
"\0\0\0\0\0\0\0\1\0\240\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\240\0\0\0"..., 
1900) = 1900
  select(5, [], [4], [], {tv_sec=60, tv_usec=0}) = 0 (Timeout)
  select(5, [], [4], [], {tv_sec=60, tv_usec=0}) = 0 (Timeout)
  select(5, [], [4], [], {tv_sec=60, tv_usec=0}

  1. Good cases:

  # Scenario from comment 16

  $ rsync -avvvz --delete source_dir target_dir
  sending incremental file list
  [sender] make_file(source_dir,*,0)
  send_file_list done
  [sender] pushing local filters for /tmp/source_dir/
  [sender] make_file(source_dir/file_3052,*,2)
  [sender] make_file(source_dir/file_1766,*,2)
  [sender] make_file(source_dir/file_10466,*,2)
  [sender] make_file(source_dir/file_9375,*,2)
  [sender] make_file(source_dir/file_7260,*,2)
  [sender] make_file(source_dir/file_5554,*,2)
  [sender] make_file(source_dir/file_5523,*,2)
  [sender] make_file(source_dir/file_1685,*,2)
  [sender] make_file(source_dir/file_7217,*,2)
  [sender] make_file(source_dir/file_10411,*,2)
  [...]
  generate_files finished

  sent 9,555,678 bytes  received 3,599,560 bytes  

[Touch-packages] [Bug 1915238] Re: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

2022-03-07 Thread Christian Ehrhardt
Thanks to Scott this is Fixed in version postfix/3.6.3-5

And since the package is in sync this is in Jammy now:
 postfix | 3.6.3-5ubuntu2| jammy  | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x

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

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

Title:
  warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and
  /etc/ssl/certs/ca-certificates.crt differ

Status in ca-certificates package in Ubuntu:
  Invalid
Status in postfix package in Ubuntu:
  Fix Released
Status in postfix package in Debian:
  Fix Released

Bug description:
  Postfix package doesn't utilize update-ca-certificate's hooks
  mechanism. By simply copying certs from /etc/ssl/certs/ca-
  certificates.crt to /var/spool/postfix/etc/ssl/certs/ca-
  certificates.crt, this warning and potential security issues could be
  avoided.

  Something like this would be a start:

  $ cat /etc/ca-certificates/update.d/postfix 
  #!/bin/bash

  if [ -e /var/spool/postfix/etc/ssl/certs/ca-certificates.crt ]; then
  echo "Updating postfix chrooted certs"
  cp /etc/ssl/certs/ca-certificates.crt 
/var/spool/postfix/etc/ssl/certs/ca-certificates.crt
  systemctl reload postfix
  fi

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1915238/+subscriptions


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


[Touch-packages] [Bug 1959054] Re: debhelper restarts services marked --no-restart-on-upgrade

2022-02-28 Thread Christian Ehrhardt
** Changed in: libvirt (Ubuntu Jammy)
   Status: Fix Committed => Fix Released

** Changed in: libvirt (Ubuntu Jammy)
 Assignee: Christian Ehrhardt  (paelzer) => (unassigned)

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

Title:
  debhelper restarts services marked --no-restart-on-upgrade

Status in debconf package in Ubuntu:
  Fix Released
Status in debhelper package in Ubuntu:
  Fix Released
Status in docker.io package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released
Status in debconf source package in Jammy:
  Fix Released
Status in debhelper source package in Jammy:
  Fix Released
Status in docker.io source package in Jammy:
  Fix Released
Status in libvirt source package in Jammy:
  Fix Released
Status in debconf package in Debian:
  New
Status in debhelper package in Debian:
  New

Bug description:
  Debian bug #994204 (https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=994204) describes a flaw in debhelper that
  results in the postinst being generated in such a fashion that
  services marked --no-stop-on-upgrade (or its deprecated alias --no-
  restart-on-upgrade), restart anyway.

  Please note: this is nothing to do with the --no-restart-after-upgrade
  flag (which is, somewhat confusingly IMO, unrelated).

  I've confirmed that the flaw appears to be present in the jammy
  version of debhelper (though not impish) and that packages generated
  with it appear to contain the flawed postinst (I first encountered
  this whilst working on the open-iscsi merge), though I haven't yet
  managed to test that the flaw exhibits itself on upgrade (though I'd
  say from the presence of the flaw in the postinst, that it's a
  reasonable inference that it will).

  In dbus (the merge of which I'm currently working on), Debian has
  worked around this but given I've now run into two affected packages
  (open-iscsi and dbus), only one of which has a work-around, I'd much
  rather we got debhelper fixed up and rebuilt affected packages?

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


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


[Touch-packages] [Bug 1959126] Re: Consider update to 3.68.2

2022-02-23 Thread Christian Ehrhardt
** Tags removed: server-todo
** Tags added: server-next

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

Title:
  Consider update to 3.68.2

Status in nss package in Ubuntu:
  In Progress

Bug description:
  Debian is shipping nss 3.73.1, but that is not an ESR release. Ubuntu
  is on 3.68, which is ESR, but two releases behind: upstream has
  3.68.2.

  Here are upstream's release notes:
  3.68.1: 
https://groups.google.com/a/mozilla.org/g/dev-tech-crypto/c/jFIuiWbCphk
  Changes:
   - Bug 1735028 - check for missing signedData field. 
   - Bug 1737470 - Ensure DER encoded signatures are within size limits.

  3.68.2: 
https://groups.google.com/a/mozilla.org/g/dev-tech-crypto/c/uGRwqw6Ove8
  Change:
 - Bug 966856 - Add SHA-2 support to mozilla::pkix's OCSP implementation

  Our 3.68 package has a patch for CVE-2021-43527. It's unclear if any
  of the above changes is that CVE. The most promising one was bug
  1737470, but the bug is private.

  The request here is to investigate if our patched 3.68 has one or more
  of the fixes in the above point releases, and if it would be worth it
  to go to 3.68.2. I think we should not go to 3.7x.

  Ubuntu has been on 3.68 since impish.

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


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


[Touch-packages] [Bug 1958720] Re: python3-yaml and python3-six are not co-installable with python-is-python2 in jammy

2022-02-16 Thread Christian Ehrhardt
Robie will take a look, but likely not immediately, more like next week.

** Tags removed: server-triage-discuss

** Changed in: six (Ubuntu)
 Assignee: (unassigned) => Robie Basak (racb)

** Changed in: pyyaml (Ubuntu)
 Assignee: (unassigned) => Robie Basak (racb)

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

Title:
  python3-yaml and python3-six are not co-installable with python-is-
  python2 in jammy

Status in pyyaml package in Ubuntu:
  Confirmed
Status in six package in Ubuntu:
  Confirmed

Bug description:
  The packages python3-yaml and python-is-python2 are not co-installable
  in jammy and I believe they should be.  This currently prevents me
  from upgrading one of my machines from focal to jammy.

  Further analysis with the help of Stefano Rivera revealed that what-
  is-python no longer produces a python-is-python2 package and the
  changelog hints at that being intentional.  Jammy still has a python2
  package, though.

  python3-yaml in jammy breaks on python (<2.7.18).  The python-is-
  python2 package in focal is version 2.7.17-4 and in impish it is
  2.7.18-9 and thus will be forcefully removed when going to jammy.

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


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


[Touch-packages] [Bug 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3

2022-02-15 Thread Christian Ehrhardt
Server-Team: As you see in the bug-history we (Server Team) have
ourselves stopped working on this believing it might be too much of a
corner case waiting for it to come back. But that come-back has happened
by even more people reporting to be affected. Therefore - as much as it
initially seems to be just a corner case - as of today I do believe that
there is a real case for this fix and releasing it IMHO seems to be the
right choice.

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

Title:
  SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3

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

Bug description:
  [Impact]

   * The version check in ssh was broken no more following RFC 4253 and
     thereby denying some clients that it shouldn't. 

 https://datatracker.ietf.org/doc/html/rfc4253#section-5.1

   * It is intended for clients reporting SSH-1.99 to be treated as if 
 they were advertising SSH-2.0, but with some backwards compatibility.

   * Upstream fixed that, and this request is to back-port the changes into
 18.04 Bionic.

   * In practice this is affecting clients using the SolarWinds
  monitoring agent. Solarwinds SSH client advertises SSH-1.99 and Ubuntu
  18.04 openssh-server is refusing the connection.

   * This results in the following error in the auth.log, and a failed
  connection from the agent.

  Protocol major versions differ for  port :
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-WeOnlyDo.Net

   * More information from SolarWinds at the link below. They call out
  18.04 as affected and recommend upgrading OpenSSH-server to 7.7 or
  greater.

  https://support.solarwinds.com/SuccessCenter/s/article/SAM-s-Linux-
  Unix-Script-monitor-fails-to-connect-on-a-server-running-
  OpenSSH-7-6?language=en_US

  [Test Case]

   # Prep
   * configure the ssh server to generally work
   # Testcase
   $ wget 
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+attachment/5332797/+files/test_bug_1863930.py
   $ apt install python3-paramiko
   $ python3 test_bug_1863930.py localhost (or whatever your host is)

   Will report "Server is not patched." or "Server is patched.

   * for an extra regression check it might be worth to do some "normal" ssh
     connections as well

  [Regression Potential]

   * The change is very small and reviewable as well as being upstream and
     in all Ubuntu releases >=Cosmic for a while now so it seems safe.
     If anything the kind of regression to expect is that some former
     (wrong) connection denials will then succeed. I can only think of
     that being an issue in test suites but not in the real world.

  [Other Info]

   * n/a

  --

  SSHD closes the connection and logs the error message below when a
  client presents a protoversion of "1.99":

  Protocol major versions differ for X.X.X.X port X:
  SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-XXX

  RFC 4253 only states that clients should treat a server's protoversion
  of "1.99" as equivalent to "2.0"; however, some backward-compatible
  clients send a protoversion of "1.99" and expect the server to treat
  it as "2.0".

  This regression was introduced in openssh-portable 7.6p1 from commit
  97f4d3083; fixes were implemented in commits 9e9c4a7e5 and c9c1bba06.
  I've attached a patch with both of those fixes.

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


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


[Touch-packages] [Bug 1528921] Re: rsync hangs on select(5, [], [4], [], {60, 0}

2022-02-07 Thread Christian Ehrhardt
@Miriam - thanks for the check of this case (FYI we are trying to
recheck many old forgotten bugs). Seems this one is a great candidate
for a fix now since we have a testcase, a fix and interested community.

Given this is open for quite some time there is no need to rush it, but
as time permits it would be great to come up with something to get this
case forward.

I agree that it thereby shall go onto our todo list and we will look for
someone to work on it for a backport-try and a PPA for this.

** Also affects: rsync via
   https://bugzilla.samba.org/show_bug.cgi?id=11166
   Importance: Unknown
   Status: Unknown

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

Title:
  rsync hangs on select(5, [], [4], [], {60, 0}

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Confirmed
Status in rsync source package in Bionic:
  New
Status in rsync source package in Focal:
  New

Bug description:
  In the last few months my home directory backup stopped completing.
  I've been able to reproduce the problem on a single subdirectory
  although I had to add the --debug=all flag to reproduce it on that
  smaller directory.  Specifically, this command never completes:

  rsync --debug=all -avz /tmp/html2 /tmp/rsynctest/

  The html2 directory is a copy of
  gnuradio-3.7.8.1/build/docs/doxygen/html .

  When I strace the command, I see this:
  write(1, "sender finished /tmp/html2/atsc_"..., 58sender finished 
/tmp/html2/atsc__interleaver_8h__incl.md5
  ) = 58
  write(1, "send_files(338, /tmp/html2/atsc_"..., 59send_files(338, 
/tmp/html2/atsc__interleaver_8h__incl.png)
  ) = 59
  open("html2/atsc__interleaver_8h__incl.png", O_RDONLY|O_LARGEFILE) = 3
  fstat64(3, {st_mode=S_IFREG|0664, st_size=264657, ...}) = 0
  write(1, "html2/atsc__interleaver_8h__incl"..., 
37html2/atsc__interleaver_8h__incl.png
  ) = 37
  read(3, 
"\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\n\253\0\0\2\233\10\6\0\0\0h\242\""..., 
262144) = 262144
  select(6, [5], [4], [5], {60, 0})   = 2 (in [5], out [4], left {59, 
96})
  read(5, 
"\0\0\0\0\0\0\0\1\0\240\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\240\0\0\0"..., 95) 
= 95
  write(4, 
"r\311\0\7\177\377\232\237\264\272e\300\300\240\316\264&\314\301\252*\37\256y\225g\373^\315j\370\350"...,
 51574) = 51574
  select(5, [], [4], [], {60, 0}) = 1 (out [4], left {59, 97})
  write(4, 
"\7\320\0\7\177\377\234|\7X\223Y\273\255c\27\25f\306\212\202\214#E\272\212t\1\225A\fU"...,
 53259) = 53259
  select(5, [], [4], [], {60, 0}

  The select command times out over and over.  I get the same behavior
  when trying to back up my entire home directory but I don't need the
  --debug=all flag in that case.


  lsb_release -rd
  Description:Ubuntu 14.04.3 LTS
  Release:14.04

  apt-cache policy rsync
  rsync:
Installed: 3.1.0-2ubuntu0.1
Candidate: 3.1.0-2ubuntu0.1
Version table:
   *** 3.1.0-2ubuntu0.1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main i386 
Packages
  500 http://security.ubuntu.com/ubuntu/ trusty-security/main i386 
Packages
  100 /var/lib/dpkg/status
   3.1.0-2 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main i386 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: rsync 3.1.0-2ubuntu0.1
  ProcVersionSignature: Ubuntu 3.13.0-74.118-generic 3.13.11-ckt30
  Uname: Linux 3.13.0-74-generic i686
  NonfreeKernelModules: nvidia
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: i386
  CurrentDesktop: KDE
  Date: Wed Dec 23 09:44:17 2015
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2010-09-18 (1922 days ago)
  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta i386 (20100901.1)
  SourcePackage: rsync
  UpgradeStatus: Upgraded to trusty on 2014-12-27 (361 days ago)

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


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


[Touch-packages] [Bug 1959101] Re: sync/merge krb5

2022-02-02 Thread Christian Ehrhardt
I struggled as well to use that syncpackage behavior right. The time you
trigger the sync is often too far away from the actual migration to
-release to happen. I happened to find my own way around (Not perfect,
but a suggestion).

I call it with --bug and once it has built (but not yet migrated) I say
"y". This adds the nice changelog style info to the bug. Then I go to
the bug and set it back from "Fix Released" to "Fix Committed" saying
that it is in -proposed but we wait for migration to be fully complete.

It is a useful update/info on the bug, but still needs someone to -
potentially much - later close the bug for real.

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

Title:
  sync/merge krb5

Status in krb5 package in Ubuntu:
  In Progress

Bug description:
  We went ahead of debian because of openssl3:
  krb5 (1.19.2-0ubuntu1) jammy; urgency=medium

[ Sam Hartman ]
* New Upstream version
* Depend on tex-gyre, Closes: #997407

[Simon Chopin]
* d/p/0012-Fix-softpkcs11-build-issues-with-openssl-3.0.patch:
  Cherry-picked from upstream master to fix OpenSSL3 build.
  Closes: #995152, LP: #1945795

   -- Simon Chopin   Tue, 30 Nov 2021
  10:54:17 +0100

  Debian unstable still has 1.18.3-7, but experimental got 1.19.2-1:
  krb5 (1.19.2-1) experimental; urgency=medium

* New Upstream version
* Include patch to work with OpenSSL 3.0, Closes: #995152
* Depend on tex-gyre, Closes: #997407
  
   -- Sam Hartman   Wed, 27 Oct 2021 14:04:42 -0600

  Since we are already at 1.19.2, we might as well merge/sync with
  experimental.

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


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


[Touch-packages] [Bug 1959126] Re: Consider update to 3.68.2

2022-02-02 Thread Christian Ehrhardt
** Changed in: nss (Ubuntu)
 Assignee: (unassigned) => Athos Ribeiro (athos-ribeiro)

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

Title:
  Consider update to 3.68.2

Status in nss package in Ubuntu:
  New

Bug description:
  Debian is shipping nss 3.73.1, but that is not an ESR release. Ubuntu
  is on 3.68, which is ESR, but two releases behind: upstream has
  3.68.2.

  Here are upstream's release notes:
  3.68.1: 
https://groups.google.com/a/mozilla.org/g/dev-tech-crypto/c/jFIuiWbCphk
  Changes:
   - Bug 1735028 - check for missing signedData field. 
   - Bug 1737470 - Ensure DER encoded signatures are within size limits.

  3.68.2: 
https://groups.google.com/a/mozilla.org/g/dev-tech-crypto/c/uGRwqw6Ove8
  Change:
 - Bug 966856 - Add SHA-2 support to mozilla::pkix's OCSP implementation

  Our 3.68 package has a patch for CVE-2021-43527. It's unclear if any
  of the above changes is that CVE. The most promising one was bug
  1737470, but the bug is private.

  The request here is to investigate if our patched 3.68 has one or more
  of the fixes in the above point releases, and if it would be worth it
  to go to 3.68.2. I think we should not go to 3.7x.

  Ubuntu has been on 3.68 since impish.

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


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


[Touch-packages] [Bug 1959325] Re: New binutils causes build failures for many RISC-V packages

2022-01-31 Thread Christian Ehrhardt
I can also confirm that it is good not for libvirt again - Thanks for
the quick fix!

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

Title:
  New binutils causes build failures for many RISC-V packages

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Jammy:
  Fix Released

Bug description:
  binutils 2.37.90.20220126-0ubuntu1 changes the -march flags.
  We see a lot of packages not building in proposed anymore: OpenSBI, 
ktexteditor, ...

  Best regards

  Heinrich

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


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


[Touch-packages] [Bug 1946854] Re: Merge dnsmasq from Debian unstable for 22.04

2022-01-31 Thread Christian Ehrhardt
dnsmasq | 2.86-1.1   | jammy| source
 dnsmasq | 2.86-1.1   | jammy/universe   | all

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

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

Title:
  Merge dnsmasq from Debian unstable for 22.04

Status in dnsmasq package in Ubuntu:
  Fix Released

Bug description:
  Scheduled-For: 23.01
  Upstream: tbd
  Debian:   2.86-1
  Ubuntu:   2.85-1ubuntu2


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  dnsmasq (2.86-1) unstable; urgency=low

 * Fix debian/changelog format error. (closes: #986626)

   -- Simon Kelley   Thu, 08 Apr 2021 22:39:00
  +0100

  dnsmasq (2.85-1) unstable; urgency=low

 * New upstream.
 * Includes fix to CVE-2021-3448.
 * Fix manpage typos. (closes: #986150)

   -- Simon Kelley   Sat, 03 Apr 2021 22:17:23
  +0100

  dnsmasq (2.84-1.2) unstable; urgency=medium

 * Non-maintainer upload.
 * Bump old-version in dpkg-maintscript-helper dir_to_symlink calls to also
   clean up after upgrades to an earlier version in testing.

   -- Andreas Beckmann   Thu, 01 Apr 2021 16:01:51
  +0200

  dnsmasq (2.84-1.1) unstable; urgency=medium

 * Non-maintainer upload.
 * Fix symlink to directory conversion for /usr/share/doc/dnsmasq.
   This is achieved by directly calling dpkg-maintscript-helper in the 
preinst,
   postinst, and postrm scripts, since the package does not use debhelper.
   (Closes: #985282)

   -- Sébastien Villemot   Sun, 28 Mar 2021
  10:55:07 +0200

  dnsmasq (2.84-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Sun, 24 Jan 2021 22:02:01
  +

  dnsmasq (2.83-1) unstable; urgency=high

 * New upstream.
 * Includes fixes to CVE-2020-25681 - CVE-2020-25687 inclusive.

   -- Simon Kelley   Fri, 15 Jan 2021 22:22:41
  +

  dnsmasq (2.82-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Fri, 26 Jun 2020 22:22:41
  +

  dnsmasq (2.81-4) unstable; urgency=low

 * Remove runit support when building for Ubuntu. (closes: #960401)

   -- Simon Kelley   Fri, 26 Jun 2020 21:52:44
  +

  dnsmasq (2.81-3) unstable; urgency=low

 * Fixes to control file for bug 958100

   -- Simon Kelley   Sun, 19 Apr 2020 21:44:12
  +

  dnsmasq (2.81-2) unstable; urgency=low

 * Fix FTBFS on kFreeBSD. (closes: #958100)
  
   -- Simon Kelley   Sat, 18 Apr 2020 18:34:15 +

  dnsmasq (2.81-1) unstable; urgency=low

 * New upstream.
 * Fix nodocs/nodoc confusion in rules. (closes: #922758)
 * Add Vcs-* fields to control. (closes: #922422)
 * Add systemd support for multiple daemon instances. (closes: #914305)
 * Add note explaining that ENABLED is SYSV-init only. (closes: #914755)
 * Replace ash with dash in contrib/reverse-dns. (closes: #920224)
 * Move to libidn2. (closes: #932695)
 * Fix RA problem with two interfaces on same net, but RA service on
   only one of the interfaces. (closes: #949565)
 * Fix breakage of dig +trace. (closes: #942363)
 * Fix build faliure with newer Nettle libraries. (closes: #940985)
 * Support runscript init-system (closes: #929884)
 * Security fix for CVE-2019-14834 (closes: #948373)
  
   -- Simon Kelley   Wed, 8 Apr 2020 17:33:15 +

  dnsmasq (2.80-1) unstable; urgency=low

 * New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
 * Close old bugs, long agp fixed. (closes: #802845) (closes: #754299)
 * Provide usr/lib/tmpfiles.d/dnsmasq.conf. (closes: #872396)
 * Run restorecon on /run/dnsmasq for SE Linux. (closes: #872397)

   -- Simon Kelley   Mon, 17 Sep 2018 23:11:25
  +

  dnsmasq (2.79-1) unstable; urgency=low

 * New upstream. (closes: #888200)
 * Fix trust-anchor regex in init script. (closes: #884347)


  ### Old Ubuntu Delta ###

  dnsmasq (2.85-1ubuntu2) impish; urgency=medium

* Revert: 'src/radv.c: avoid leases to be issued forever when not set'
  (LP 1894619) according to the bug and upstream discussion.

   -- Christian Ehrhardt   Tue, 22 Jun
  2021 07:18:30 +0200

  dnsmasq (2.85-1ubuntu1) impish; urgency=medium

* Merge with Debian unstable. Remaining changes:
  - src/radv.c: avoid leases to be issued forever when not set
(LP 1894619)

   -- Christian Ehrhardt   Wed, 02 Jun
  2021 09:34:26 +0200

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


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

[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-26 Thread Christian Ehrhardt
** Tags removed: server-next

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

Status in dnsmasq package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3

2022-01-25 Thread Christian Ehrhardt
** Changed in: openssh (Ubuntu Bionic)
 Assignee: Christian Ehrhardt  (paelzer) => (unassigned)

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

Title:
  SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Incomplete

Bug description:
  [Impact]

   * The version check in ssh was broken no more following RFC 4253 and
     thereby denying some clients that it shouldn't. 

 https://datatracker.ietf.org/doc/html/rfc4253#section-5.1

   * It is intended for clients reporting SSH-1.99 to be treated as if 
 they were advertising SSH-2.0, but with some backwards compatibility.

   * Upstream fixed that, and this request is to back-port the changes into
 18.04 Bionic.

   * In practice this is affecting clients using the SolarWinds
  monitoring agent. Solarwinds SSH client advertises SSH-1.99 and Ubuntu
  18.04 openssh-server is refusing the connection.

   * This results in the following error in the auth.log, and a failed
  connection from the agent.

  Protocol major versions differ for  port :
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-WeOnlyDo.Net

   * More information from SolarWinds at the link below. They call out
  18.04 as affected and recommend upgrading OpenSSH-server to 7.7 or
  greater.

  https://support.solarwinds.com/SuccessCenter/s/article/SAM-s-Linux-
  Unix-Script-monitor-fails-to-connect-on-a-server-running-
  OpenSSH-7-6?language=en_US

  [Test Case]

   # Prep
   * configure the ssh server to generally work
   # Testcase
   $ wget 
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+attachment/5332797/+files/test_bug_1863930.py
   $ apt install python3-paramiko
   $ python3 test_bug_1863930.py localhost (or whatever your host is)

   Will report "Server is not patched." or "Server is patched.

   * for an extra regression check it might be worth to do some "normal" ssh
     connections as well

  [Regression Potential]

   * The change is very small and reviewable as well as being upstream and
     in all Ubuntu releases >=Cosmic for a while now so it seems safe.
     If anything the kind of regression to expect is that some former
     (wrong) connection denials will then succeed. I can only think of
     that being an issue in test suites but not in the real world.

  [Other Info]

   * n/a

  --

  SSHD closes the connection and logs the error message below when a
  client presents a protoversion of "1.99":

  Protocol major versions differ for X.X.X.X port X:
  SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-XXX

  RFC 4253 only states that clients should treat a server's protoversion
  of "1.99" as equivalent to "2.0"; however, some backward-compatible
  clients send a protoversion of "1.99" and expect the server to treat
  it as "2.0".

  This regression was introduced in openssh-portable 7.6p1 from commit
  97f4d3083; fixes were implemented in commits 9e9c4a7e5 and c9c1bba06.
  I've attached a patch with both of those fixes.

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


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


[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-23 Thread Christian Ehrhardt
For xen itself we know now how to "work around it" which is retry until running 
on one of the new builders. Leaving the bug open as it clearly seems to be a 
real issue.
I also leave the PPA as-is so that you can grab sources from there for 
recreating this binutils issue.

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  Invalid

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 
ip 7fe3681b7f3d sp 7ffcbbf16628 error 4 in 
libc.so.6[7fe368044000+194000]
  Jan 19 07:39:42 Keschdeichel kernel: x86_64-linux-gn[4134584]: segfault at 0 
ip 7f241f455f3d sp 7ffd05c2e7c8 error 4 in 
libc.so.6[7f241f2e2000+194000]
  Jan 19 07:44:57 Keschdeichel 

[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-23 Thread Christian Ehrhardt
Hi Michael,
it seems suspicious as it is the same test that fails.
But the assertion is different.
In the referred Debian bug it is
  AssertionError: b'megasearch.net: 192.168.42.1' not found in
In the Ubuntu fail it is
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.


Also we did show that 2.86-1 worked fine against systemd 249.7-1ubuntu1 without 
a change to dnsmasq.
Finally the new dnsmasq 2.86-1.1 tested against systemd 249.5-2ubuntu4 here
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/s/systemd/20220122_111714_33b38@/log.gz
It still shows the same issue as reported here.

The referenced error OTOH fails in Debian with 247.9-1 which works for
this issue here.

So while indeed very close, I doubt it is the same as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995655
Overall I guess eventually we need both fixes anyway, the one in dnsmasq (sync 
already happened 2.86-1.1 is in j-proposed) and a newer systemd upload.

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

Status in dnsmasq package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-20 Thread Christian Ehrhardt
Being a platform dependent (thereby rather severe, but easy to miss)
crash in binutils I feel it is time to bump priority of this to get it
onto the radar avoiding to ship it that way (potentially breaking more)
in our next LTS.

** Changed in: binutils (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  Invalid

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 
ip 7fe3681b7f3d sp 7ffcbbf16628 error 4 in 
libc.so.6[7fe368044000+194000]
  Jan 19 07:39:42 Keschdeichel kernel: x86_64-linux-gn[4134584]: segfault at 0 
ip 7f241f455f3d sp 7ffd05c2e7c8 error 4 in 
libc.so.6[7f241f2e2000+194000]
  Jan 19 

[Touch-packages] [Bug 1946854] Re: Merge dnsmasq from Debian unstable for 22.04

2022-01-20 Thread Christian Ehrhardt
FYI - blocked by
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1957086 for the
time being

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

Title:
  Merge dnsmasq from Debian unstable for 22.04

Status in dnsmasq package in Ubuntu:
  Fix Committed

Bug description:
  Scheduled-For: 23.01
  Upstream: tbd
  Debian:   2.86-1
  Ubuntu:   2.85-1ubuntu2


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  dnsmasq (2.86-1) unstable; urgency=low

 * Fix debian/changelog format error. (closes: #986626)

   -- Simon Kelley   Thu, 08 Apr 2021 22:39:00
  +0100

  dnsmasq (2.85-1) unstable; urgency=low

 * New upstream.
 * Includes fix to CVE-2021-3448.
 * Fix manpage typos. (closes: #986150)

   -- Simon Kelley   Sat, 03 Apr 2021 22:17:23
  +0100

  dnsmasq (2.84-1.2) unstable; urgency=medium

 * Non-maintainer upload.
 * Bump old-version in dpkg-maintscript-helper dir_to_symlink calls to also
   clean up after upgrades to an earlier version in testing.

   -- Andreas Beckmann   Thu, 01 Apr 2021 16:01:51
  +0200

  dnsmasq (2.84-1.1) unstable; urgency=medium

 * Non-maintainer upload.
 * Fix symlink to directory conversion for /usr/share/doc/dnsmasq.
   This is achieved by directly calling dpkg-maintscript-helper in the 
preinst,
   postinst, and postrm scripts, since the package does not use debhelper.
   (Closes: #985282)

   -- Sébastien Villemot   Sun, 28 Mar 2021
  10:55:07 +0200

  dnsmasq (2.84-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Sun, 24 Jan 2021 22:02:01
  +

  dnsmasq (2.83-1) unstable; urgency=high

 * New upstream.
 * Includes fixes to CVE-2020-25681 - CVE-2020-25687 inclusive.

   -- Simon Kelley   Fri, 15 Jan 2021 22:22:41
  +

  dnsmasq (2.82-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Fri, 26 Jun 2020 22:22:41
  +

  dnsmasq (2.81-4) unstable; urgency=low

 * Remove runit support when building for Ubuntu. (closes: #960401)

   -- Simon Kelley   Fri, 26 Jun 2020 21:52:44
  +

  dnsmasq (2.81-3) unstable; urgency=low

 * Fixes to control file for bug 958100

   -- Simon Kelley   Sun, 19 Apr 2020 21:44:12
  +

  dnsmasq (2.81-2) unstable; urgency=low

 * Fix FTBFS on kFreeBSD. (closes: #958100)
  
   -- Simon Kelley   Sat, 18 Apr 2020 18:34:15 +

  dnsmasq (2.81-1) unstable; urgency=low

 * New upstream.
 * Fix nodocs/nodoc confusion in rules. (closes: #922758)
 * Add Vcs-* fields to control. (closes: #922422)
 * Add systemd support for multiple daemon instances. (closes: #914305)
 * Add note explaining that ENABLED is SYSV-init only. (closes: #914755)
 * Replace ash with dash in contrib/reverse-dns. (closes: #920224)
 * Move to libidn2. (closes: #932695)
 * Fix RA problem with two interfaces on same net, but RA service on
   only one of the interfaces. (closes: #949565)
 * Fix breakage of dig +trace. (closes: #942363)
 * Fix build faliure with newer Nettle libraries. (closes: #940985)
 * Support runscript init-system (closes: #929884)
 * Security fix for CVE-2019-14834 (closes: #948373)
  
   -- Simon Kelley   Wed, 8 Apr 2020 17:33:15 +

  dnsmasq (2.80-1) unstable; urgency=low

 * New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
 * Close old bugs, long agp fixed. (closes: #802845) (closes: #754299)
 * Provide usr/lib/tmpfiles.d/dnsmasq.conf. (closes: #872396)
 * Run restorecon on /run/dnsmasq for SE Linux. (closes: #872397)

   -- Simon Kelley   Mon, 17 Sep 2018 23:11:25
  +

  dnsmasq (2.79-1) unstable; urgency=low

 * New upstream. (closes: #888200)
 * Fix trust-anchor regex in init script. (closes: #884347)


  ### Old Ubuntu Delta ###

  dnsmasq (2.85-1ubuntu2) impish; urgency=medium

* Revert: 'src/radv.c: avoid leases to be issued forever when not set'
  (LP 1894619) according to the bug and upstream discussion.

   -- Christian Ehrhardt   Tue, 22 Jun
  2021 07:18:30 +0200

  dnsmasq (2.85-1ubuntu1) impish; urgency=medium

* Merge with Debian unstable. Remaining changes:
  - src/radv.c: avoid leases to be issued forever when not set
(LP 1894619)

   -- Christian Ehrhardt   Wed, 02 Jun
  2021 09:34:26 +0200

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


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


[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-19 Thread Christian Ehrhardt
This build ran 10:26 -> 10:33 and the crash happened "in between". As i
said in local sbuild those are not fatal but on LP they are. Therefore
attaching the build log ...

** Attachment added: "build log that did not exit fatally, but triggered the 
crash we also see on LP (there fatally)"
   
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1958389/+attachment/774/+files/xen_4.16.0-1~ubuntu1~jammyppa3_amd64-2022-01-18T10%3A26%3A25Z.build

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  Invalid

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 
ip 7fe3681b7f3d sp 7ffcbbf16628 error 4 in 
libc.so.6[7fe368044000+194000]
  Jan 19 07:39:42 

[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-19 Thread Christian Ehrhardt
The build log I attached above shall help to spot the versions needed
for debug symbols to read this crash correctly.

** Attachment added: "Crash file of x86_64-linux-gnu-ld.bfd as seen in local 
sbuild"
   
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1958389/+attachment/775/+files/_usr_bin_x86_64-linux-gnu-ld.bfd.1000.crash

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  Invalid

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 
ip 7fe3681b7f3d sp 7ffcbbf16628 error 4 in 
libc.so.6[7fe368044000+194000]
  Jan 19 07:39:42 Keschdeichel kernel: x86_64-linux-gn[4134584]: segfault at 0 
ip 7f241f455f3d sp 7ffd05c2e7c8 error 4 in 

[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-19 Thread Christian Ehrhardt
Thanks for the hint,
in case anyone needs to do the same - you can see the associated builder right 
when the build starts - then abort it immediately, refresh and rebuild.
That way you get 1 build try <1min, I got

lgw01 018
lgw01 044
lgw01 023
lcy02 001

And the build on the latter I let finish which indeed let it build
successfully.


That also means the crash I got locally is actually relevant to doko or anyone 
else looking for this from binutils POV. Therefore I'll attach mine.


** Changed in: xen (Ubuntu)
   Status: New => Invalid

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  Invalid

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 
ip 

[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-19 Thread Christian Ehrhardt
Thanks Colin, even without debug symbols that still is probably enough
to confirm it is actually the same crash that I see on my laptop.

While I do not see why it is fatal for the build on LP but not on local
sbuild or dpkg-buildpkg in a local VM it means that most likely someone
looking into this from the binutils POV can reproduce it the way I
outlined in my report on most common intel laptops.

In use here I have:
Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz

Maybe you could add what chip the failing lgw01 builders use to try
isolating the affected series?


/me is trying to retry until it ran on an lcy02 builder now ...

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  New

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 

[Touch-packages] [Bug 1951779] Re: tempfile command removed from debianutils

2022-01-19 Thread Christian Ehrhardt
And as comment #8 and #3 outlined the use of it in boost is not a real
problem for build or usage in the distribution, setting that task to
invalid.

** Changed in: boost1.74 (Ubuntu)
   Status: New => Invalid

** Changed in: grub-legacy-ec2 (Ubuntu)
 Assignee: Miriam España Acebal (mirespace) => (unassigned)

** Tags removed: server-todo

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

Title:
  tempfile command removed from debianutils

Status in boost1.74 package in Ubuntu:
  Invalid
Status in bzip2 package in Ubuntu:
  Fix Released
Status in ceph package in Ubuntu:
  Won't Fix
Status in grub-legacy-ec2 package in Ubuntu:
  Fix Released

Bug description:
  Error when do-release-upgrade -d from 20.04.3

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: linux-image-5.13.0-19-generic 5.13.0-19.19
  ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
  Uname: Linux 5.4.0-90-generic x86_64
  ApportVersion: 2.20.11-0ubuntu73
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/controlC0', '/dev/snd/hwC0D2', '/dev/snd/pcmC0D3p', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: unknown
  Date: Mon Nov 22 13:31:36 2021
  ErrorMessage: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited with 
return code 127
  InstallationDate: Installed on 2018-10-01 (1147 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 001 Device 002: ID 8087:07e6 Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
  MachineType: PAIQ EC3-BT19D4L
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-90-generic 
root=UUID=4c36d2b3-c1dd-469f-bfbf-5b7052d669d4 ro ipv6.disable=1 quiet 
reboot=pci ipv6.disable=1
  Python3Details: Error: command ['readlink', '-f', "/usr/bin/which: this 
version of `which' is deprecated; use `command -v' in scripts 
instead.\n/usr/bin/python3"] failed with exit code 1: , Error: [Errno 2] No 
such file or directory: 'Error: command [\'readlink\', \'-f\', "/usr/bin/which: 
this version of `which\' is deprecated; use `command -v\' in scripts 
instead.\\n/usr/bin/python3"] failed with exit code 1: ', python3-minimal, 
3.9.4-1build1
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions: grub-pc 2.04-1ubuntu48
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: grub-legacy-ec2
  Title: package linux-image-5.13.0-19-generic 5.13.0-19.19 failed to 
install/upgrade: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited 
with return code 127
  UpgradeStatus: Upgraded to jammy on 2021-11-22 (0 days ago)
  dmi.bios.date: 02/28/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 5.6.5
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: EC3-BT19D4L
  dmi.board.vendor: PAIQ
  dmi.board.version: A1
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr5.6.5:bd02/28/2017:svnPAIQ:pnEC3-BT19D4L:pvrBIOSNameBT190003BIOSVersionA1BuildDate:rvnPAIQ:rnEC3-BT19D4L:rvrA1:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: EC3-BT19D4L
  dmi.product.sku: 18:19:28
  dmi.product.version: BIOS Name:BT190003 BIOS Version:A1 Build Date:
  dmi.sys.vendor: PAIQ

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/boost1.74/+bug/1951779/+subscriptions


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


[Touch-packages] [Bug 1951779] Re: tempfile command removed from debianutils

2022-01-19 Thread Christian Ehrhardt
Per comment #7 and
 bzip2 | 1.0.8-5| jammy   | source, amd64, arm64, armhf, 
i386, ppc64el, riscv64, s390x

Setting that to fix released.

** Changed in: bzip2 (Ubuntu)
   Status: Won't Fix => Fix Released

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

Title:
  tempfile command removed from debianutils

Status in boost1.74 package in Ubuntu:
  Invalid
Status in bzip2 package in Ubuntu:
  Fix Released
Status in ceph package in Ubuntu:
  Won't Fix
Status in grub-legacy-ec2 package in Ubuntu:
  Fix Released

Bug description:
  Error when do-release-upgrade -d from 20.04.3

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: linux-image-5.13.0-19-generic 5.13.0-19.19
  ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
  Uname: Linux 5.4.0-90-generic x86_64
  ApportVersion: 2.20.11-0ubuntu73
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/controlC0', '/dev/snd/hwC0D2', '/dev/snd/pcmC0D3p', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: unknown
  Date: Mon Nov 22 13:31:36 2021
  ErrorMessage: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited with 
return code 127
  InstallationDate: Installed on 2018-10-01 (1147 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 001 Device 002: ID 8087:07e6 Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
  MachineType: PAIQ EC3-BT19D4L
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-90-generic 
root=UUID=4c36d2b3-c1dd-469f-bfbf-5b7052d669d4 ro ipv6.disable=1 quiet 
reboot=pci ipv6.disable=1
  Python3Details: Error: command ['readlink', '-f', "/usr/bin/which: this 
version of `which' is deprecated; use `command -v' in scripts 
instead.\n/usr/bin/python3"] failed with exit code 1: , Error: [Errno 2] No 
such file or directory: 'Error: command [\'readlink\', \'-f\', "/usr/bin/which: 
this version of `which\' is deprecated; use `command -v\' in scripts 
instead.\\n/usr/bin/python3"] failed with exit code 1: ', python3-minimal, 
3.9.4-1build1
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions: grub-pc 2.04-1ubuntu48
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: grub-legacy-ec2
  Title: package linux-image-5.13.0-19-generic 5.13.0-19.19 failed to 
install/upgrade: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited 
with return code 127
  UpgradeStatus: Upgraded to jammy on 2021-11-22 (0 days ago)
  dmi.bios.date: 02/28/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 5.6.5
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: EC3-BT19D4L
  dmi.board.vendor: PAIQ
  dmi.board.version: A1
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr5.6.5:bd02/28/2017:svnPAIQ:pnEC3-BT19D4L:pvrBIOSNameBT190003BIOSVersionA1BuildDate:rvnPAIQ:rnEC3-BT19D4L:rvrA1:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: EC3-BT19D4L
  dmi.product.sku: 18:19:28
  dmi.product.version: BIOS Name:BT190003 BIOS Version:A1 Build Date:
  dmi.sys.vendor: PAIQ

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/boost1.74/+bug/1951779/+subscriptions


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


[Touch-packages] [Bug 1951779] Re: tempfile command removed from debianutils

2022-01-19 Thread Christian Ehrhardt
** Changed in: grub-legacy-ec2 (Ubuntu)
 Assignee: (unassigned) => Miriam España Acebal (mirespace)

** Changed in: ceph (Ubuntu)
 Assignee: Miriam España Acebal (mirespace) => (unassigned)

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

Title:
  tempfile command removed from debianutils

Status in boost1.74 package in Ubuntu:
  New
Status in bzip2 package in Ubuntu:
  New
Status in ceph package in Ubuntu:
  Won't Fix
Status in grub-legacy-ec2 package in Ubuntu:
  Fix Released

Bug description:
  Error when do-release-upgrade -d from 20.04.3

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: linux-image-5.13.0-19-generic 5.13.0-19.19
  ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
  Uname: Linux 5.4.0-90-generic x86_64
  ApportVersion: 2.20.11-0ubuntu73
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/controlC0', '/dev/snd/hwC0D2', '/dev/snd/pcmC0D3p', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: unknown
  Date: Mon Nov 22 13:31:36 2021
  ErrorMessage: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited with 
return code 127
  InstallationDate: Installed on 2018-10-01 (1147 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 001 Device 002: ID 8087:07e6 Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
  MachineType: PAIQ EC3-BT19D4L
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-90-generic 
root=UUID=4c36d2b3-c1dd-469f-bfbf-5b7052d669d4 ro ipv6.disable=1 quiet 
reboot=pci ipv6.disable=1
  Python3Details: Error: command ['readlink', '-f', "/usr/bin/which: this 
version of `which' is deprecated; use `command -v' in scripts 
instead.\n/usr/bin/python3"] failed with exit code 1: , Error: [Errno 2] No 
such file or directory: 'Error: command [\'readlink\', \'-f\', "/usr/bin/which: 
this version of `which\' is deprecated; use `command -v\' in scripts 
instead.\\n/usr/bin/python3"] failed with exit code 1: ', python3-minimal, 
3.9.4-1build1
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions: grub-pc 2.04-1ubuntu48
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: grub-legacy-ec2
  Title: package linux-image-5.13.0-19-generic 5.13.0-19.19 failed to 
install/upgrade: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited 
with return code 127
  UpgradeStatus: Upgraded to jammy on 2021-11-22 (0 days ago)
  dmi.bios.date: 02/28/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 5.6.5
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: EC3-BT19D4L
  dmi.board.vendor: PAIQ
  dmi.board.version: A1
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr5.6.5:bd02/28/2017:svnPAIQ:pnEC3-BT19D4L:pvrBIOSNameBT190003BIOSVersionA1BuildDate:rvnPAIQ:rnEC3-BT19D4L:rvrA1:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: EC3-BT19D4L
  dmi.product.sku: 18:19:28
  dmi.product.version: BIOS Name:BT190003 BIOS Version:A1 Build Date:
  dmi.sys.vendor: PAIQ

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/boost1.74/+bug/1951779/+subscriptions


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


[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-19 Thread Christian Ehrhardt
Hi Colin,
so far I've seen it only on lgw01, but I didn't mass-submit it yet to try the 
other builders.
Is there a better way than re-building/re-submitting to get onto the lcy02?

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  New

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 
ip 7fe3681b7f3d sp 7ffcbbf16628 error 4 in 
libc.so.6[7fe368044000+194000]
  Jan 19 07:39:42 Keschdeichel kernel: x86_64-linux-gn[4134584]: segfault at 0 
ip 7f241f455f3d sp 7ffd05c2e7c8 error 4 in 
libc.so.6[7f241f2e2000+194000]
  Jan 19 07:44:57 Keschdeichel kernel: x86_64-linux-gn[4171794]: segfault at 0 
ip 7fcbe1f2bf3d sp 7fff62005aa8 error 4 in 

[Touch-packages] [Bug 1958389] Re: Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-19 Thread Christian Ehrhardt
FYI: I've seen some shortening of the reported crashes going on.
For example in journal it was "x86_64-linux-gn" and in the build log it was 
after "x86_64-linux-gnu-ld". The local (non fatal) crash I got eventually was 
in "x86_64-linux-gnu-ld.bfd".

This might or might not be the same crash on LP and locally, but as I
mentioned above one fails critically the other one is ignored.

Could someone run that build manually on LP and/or stop it before
cleanup to gather the crash from there for comparison?

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

Title:
  Jammy builds of xen segfault, but only on launchpad x86 builders

Status in launchpad-buildd:
  New
Status in binutils package in Ubuntu:
  New
Status in xen package in Ubuntu:
  New

Bug description:
  FTBFS in Jammy on LP infra:
  
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
  
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
  Related PPA:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

  Summary:
  - Build reliably fails on LP
  - Build in local sbuild works reliably on my Laptop
  - Build in local VM (sizing like LP builders) works (other crashes but works)
  - Build on AMD server (chip more similar to LP) works reliably

  Failing step:

  On Launchpad build infrastructure it breaks on ld:
  $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=16 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp 
--build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
  Segmentation fault (core dumped

  ---

  Steps to recreate (result depends on platform)

  # you can grab the package from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4760/+packages

  sudo vim /etc/apt/sources.list
  sudo apt update
  sudo apt dist-upgrade -y
  sudo apt build-dep xen
  sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
  sudo mkdir /mnt/build
  sudo chmod go+w /mnt/build
  cd  /mnt/build
  # copy in things from host
  scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
  dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
  cd xen_4.16.0
  dpkg-buildpackage -i -us -uc -b

  ---

  In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

  Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
  Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 
1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 
00  fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
  (gdb) bt
  #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
  #1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
  #5  0x562bdaaae3bf in ?? ()
  #6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
  #7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, 
argc=8, argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
  stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
  #8  0x562bdaaad515 in ?? ()

  ^^ that is a different crash than on th LP builders
  ! And despite those crashes the build does appear to work oO?!

  The same crashes I see on my local sbuild runs, the full set of one build is
  Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 
ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in 
libc.so.6[7f566e74+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 
ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in 
libc.so.6[7fbba2571000+194000]
  Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 
ip 7fe3681b7f3d sp 7ffcbbf16628 error 4 in 

[Touch-packages] [Bug 1958389] [NEW] Jammy builds of xen segfault, but only on launchpad x86 builders

2022-01-19 Thread Christian Ehrhardt
Public bug reported:

FTBFS in Jammy on LP infra:
https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz
https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz
Related PPA:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages

Summary:
- Build reliably fails on LP
- Build in local sbuild works reliably on my Laptop
- Build in local VM (sizing like LP builders) works (other crashes but works)
- Build on AMD server (chip more similar to LP) works reliably

Failing step:

On Launchpad build infrastructure it breaks on ld:
$ x86_64-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0x82d04000 
--stack=0,0 --heap=0,0 --section-alignment=0x20 --file-alignment=0x20 
--major-image-version=4 --minor-image-version=16 --major-os-version=2 
--minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 
--no-insert-timestamp --build-id=sha1 -T efi.lds -N prelink.o  
/<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o 
/<>/xen/.xen.efi.0x82d04000.0 && :
Segmentation fault (core dumped

---

Steps to recreate (result depends on platform)

# you can grab the package from https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4760/+packages

sudo vim /etc/apt/sources.list
sudo apt update
sudo apt dist-upgrade -y
sudo apt build-dep xen
sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts 
apport-retrace
sudo mkdir /mnt/build
sudo chmod go+w /mnt/build
cd  /mnt/build
# copy in things from host
scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc 
xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 
ubuntu@:/mnt/build
dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0
cd xen_4.16.0
dpkg-buildpackage -i -us -uc -b

---

In a jammy VM 4cpu/8G I get some avx2 crashes but the build works:

Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 
7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000]
Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e 
fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 00 
 fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
74  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
#1  0x7fa98d63c2d0 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
#2  0x7fa98d6021e8 in ?? () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
#3  0x7fa98d602509 in coff_write_alien_symbol () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
#4  0x7fa98d6033bd in _bfd_coff_final_link () from 
/lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so
#5  0x562bdaaae3bf in ?? ()
#6  0x7fa98d2e8fd0 in __libc_start_call_main 
(main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, 
argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58
#7  0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, argc=8, 
argv=0x7ffc797f2968, init=, fini=, 
rtld_fini=, 
stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409
#8  0x562bdaaad515 in ?? ()

^^ that is a different crash than on th LP builders
! And despite those crashes the build does appear to work oO?!

The same crashes I see on my local sbuild runs, the full set of one build is
Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 ip 
7f566e8b3f3d sp 7ffde04b75a8 error 4 in libc.so.6[7f566e74+194000]
Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 ip 
7fbba26e4f3d sp 7fffab8a5b68 error 4 in libc.so.6[7fbba2571000+194000]
Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131382]: segfault at 0 ip 
7fe3681b7f3d sp 7ffcbbf16628 error 4 in libc.so.6[7fe368044000+194000]
Jan 19 07:39:42 Keschdeichel kernel: x86_64-linux-gn[4134584]: segfault at 0 ip 
7f241f455f3d sp 7ffd05c2e7c8 error 4 in libc.so.6[7f241f2e2000+194000]
Jan 19 07:44:57 Keschdeichel kernel: x86_64-linux-gn[4171794]: segfault at 0 ip 
7fcbe1f2bf3d sp 7fff62005aa8 error 4 in libc.so.6[7fcbe1db8000+194000]
Jan 19 07:44:57 Keschdeichel kernel: x86_64-linux-gn[4172028]: segfault at 0 ip 
7f601dfa3f3d sp 7ffe67ca2788 error 4 in libc.so.6[7f601de3+194000]
Jan 19 07:44:58 Keschdeichel kernel: x86_64-linux-gn[4172154]: segfault at 0 ip 
7f1bfabb7f3d sp 7ffe5ce9dfb8 error 4 in libc.so.6[7f1bfaa44000+194000]
Jan 19 07:45:05 Keschdeichel kernel: x86_64-linux-gn[4174536]: segfault at 0 ip 
7f0f48986f3d sp 7ffc9e72ea48 error 4 in libc.so.6[7f0f48813000+194000]

I checked, this is not in configure stage where such things sometimes
are intentional.

Running in local VM with reduced cpu features (e.g. no avx2) still 

[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-18 Thread Christian Ehrhardt
I tested the test of 249.5-2ubuntu2 (running autopkgtest against the dsc
file of 249.5-2ubuntu2) vs the binary systemd build in your PPA
(systemd_249.7-1ubuntu1~slyon0) + the dnsmasq from proposed.

And I got:
resolved: domain-restricted DNS servers ... ok

That means:
1. the fix is not in debian/tests of the new systemd version
2. that your new build works to resolve that issue

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

Status in dnsmasq package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-13 Thread Christian Ehrhardt
** Tags added: server-next

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1951779] Re: tempfile command removed from debianutils

2022-01-12 Thread Christian Ehrhardt
** Tags removed: server-next
** Tags added: server-todo

** Tags added: bitesize

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

Title:
  tempfile command removed from debianutils

Status in boost1.74 package in Ubuntu:
  New
Status in bzip2 package in Ubuntu:
  New
Status in ceph package in Ubuntu:
  New
Status in grub-legacy-ec2 package in Ubuntu:
  Triaged

Bug description:
  Error when do-release-upgrade -d from 20.04.3

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: linux-image-5.13.0-19-generic 5.13.0-19.19
  ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
  Uname: Linux 5.4.0-90-generic x86_64
  ApportVersion: 2.20.11-0ubuntu73
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/controlC0', '/dev/snd/hwC0D2', '/dev/snd/pcmC0D3p', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: unknown
  Date: Mon Nov 22 13:31:36 2021
  ErrorMessage: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited with 
return code 127
  InstallationDate: Installed on 2018-10-01 (1147 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 001 Device 002: ID 8087:07e6 Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
  MachineType: PAIQ EC3-BT19D4L
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-90-generic 
root=UUID=4c36d2b3-c1dd-469f-bfbf-5b7052d669d4 ro ipv6.disable=1 quiet 
reboot=pci ipv6.disable=1
  Python3Details: Error: command ['readlink', '-f', "/usr/bin/which: this 
version of `which' is deprecated; use `command -v' in scripts 
instead.\n/usr/bin/python3"] failed with exit code 1: , Error: [Errno 2] No 
such file or directory: 'Error: command [\'readlink\', \'-f\', "/usr/bin/which: 
this version of `which\' is deprecated; use `command -v\' in scripts 
instead.\\n/usr/bin/python3"] failed with exit code 1: ', python3-minimal, 
3.9.4-1build1
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions: grub-pc 2.04-1ubuntu48
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: grub-legacy-ec2
  Title: package linux-image-5.13.0-19-generic 5.13.0-19.19 failed to 
install/upgrade: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited 
with return code 127
  UpgradeStatus: Upgraded to jammy on 2021-11-22 (0 days ago)
  dmi.bios.date: 02/28/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 5.6.5
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: EC3-BT19D4L
  dmi.board.vendor: PAIQ
  dmi.board.version: A1
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr5.6.5:bd02/28/2017:svnPAIQ:pnEC3-BT19D4L:pvrBIOSNameBT190003BIOSVersionA1BuildDate:rvnPAIQ:rnEC3-BT19D4L:rvrA1:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: EC3-BT19D4L
  dmi.product.sku: 18:19:28
  dmi.product.version: BIOS Name:BT190003 BIOS Version:A1 Build Date:
  dmi.sys.vendor: PAIQ

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/boost1.74/+bug/1951779/+subscriptions


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


[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-11 Thread Christian Ehrhardt
As usual once you know what you search for the results are much better.

It turns out that it might be related to one of those reports:
- https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016015.html
- https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016069.html

But even better was the finding that Debian at 249-5-2 was affected by the same.
- https://ci.debian.net/packages/s/systemd/unstable/amd64/
- 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/systemd/16383273/log.gz

That seems to be fixed since systemd 249.6-1 and checking that made me
find

To me there is nothing obvious in regard to this in debian
=> https://salsa.debian.org/systemd-team/systemd/-/commits/debian/master
nor in upstream
=> https://github.com/systemd/systemd-stable/commits/v249.6

But I think this is enough to get the bug reported and maybe eyes more used
to systemd will see the related fix as it seems it must be there somewhere ...

@systemd maintainer (Lukas?) does this ring a bell to you or do you see the 
change that might have fixed this?
Also is there a PPA with a Ubuntu build of >=249.6-1 to check if it resolves 
the issue also in Ubuntu?

** Tags added: update-excuse

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Lukas Märdian (slyon)

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-11 Thread Christian Ehrhardt
# FYI cleanup

# Minimal Reset (e.g. when switching dnsmasq)

killall dnsmasq
rm /tmp/dnsmasq*
dnsmasq --no-daemon --log-queries --log-facility=/tmp/dnsmasq.log 
--conf-file=/dev/null --dhcp-leasefile=/tmp/dnsmasq.leases --bind-interfaces 
--interface=router_eth42 --except-interface=lo 
--dhcp-range=192.168.5.10,192.168.5.200 --address=/#/192.168.42.1 &
dnsmasq --no-daemon --log-queries --log-facility=/tmp/dnsmasq-vpn.log 
--conf-file=/dev/null --dhcp-leasefile=/dev/null --bind-interfaces 
--interface=testvpnrouter --except-interface=lo --address=/math.lab/10.241.3.3 
--address=/cantina.company/10.241.4.4 &
dig @10.241.3.1 -t  math.lab


^^ With this I could confirm that switchign the good case to dnsmasq 2.86 makes
it enter the forwarding loop. Vice versa switching the bad system to dnsmasq
2.85 makes it work (not entering the loop).

# Full cleanup
sudo killall dnsmasq
sudo rm /run/systemd/network/general.network
sudo rm /run/systemd/network/vpn.network
sudo rm /run/systemd/resolved.conf.d/test-enable-dnssec.conf
for i in testvpnrouter testvpnclient test_eth42 router_eth42; do sudo ip link 
dev $i down; done
for i in testvpnrouter testvpnclient test_eth42 router_eth42; do sudo ip link 
del dev $i down; done
sudo systemctl restart systemd-resolved
sudo systemctl restart systemd-networkd

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-11 Thread Christian Ehrhardt
Detailed Logs:

Before the test:
dnsmasq.log is identical
dnsmasq-vpn.log as well, except the version number

Good Case:
ubuntu@autopkgtest:~$ resolvectl query math.lab
math.lab: 10.241.3.3   -- link: testvpnrouter
-- Information acquired via protocol DNS in 20.8ms.
-- Data is authenticated: no; Data was acquired via local or encrypted 
transport: no
-- Data from: network

Bad Case:
ubuntu@autopkgtest:~$ resolvectl query math.lab
math.lab: resolve call failed: Connection timed out

After the test:
- dnsmasq.log is still identical
- dnsmasq-vpn.log is quite different

Entries in Good case:
Jan 11 11:54:18 dnsmasq[7952]: query[A] math.lab from 10.241.3.1
Jan 11 11:54:18 dnsmasq[7952]: config math.lab is 10.241.3.3
Jan 11 11:54:18 dnsmasq[7952]: query[] math.lab from 10.241.3.1
Jan 11 11:54:18 dnsmasq[7952]: config math.lab is NODATA-IPv6

Entries in Bad case:
Jan 11 11:54:16 dnsmasq[8871]: query[A] math.lab from 10.241.3.1
Jan 11 11:54:16 dnsmasq[8871]: config math.lab is 10.241.3.3
Jan 11 11:54:16 dnsmasq[8871]: query[] math.lab from 10.241.3.1
Jan 11 11:54:16 dnsmasq[8871]: forwarded math.lab to 127.0.0.53
Jan 11 11:54:16 dnsmasq[8871]: query[] math.lab from 10.241.3.1
Jan 11 11:54:16 dnsmasq[8871]: forwarded math.lab to 127.0.0.53
... the last two lines repeat until a timeout occurs

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-11 Thread Christian Ehrhardt
Reproducing the case outside the systemd tests

(Commands on Ubuntu 22.04, with root permissions)
jammy-Proposed has dnsmasq 2.86 right now

apt update; apt upgrade -y; apt install dnsmasq-base

systemctl reset-failed systemd-networkd systemd-resolved

mkdir /run/systemd/resolved.conf.d
cat > /run/systemd/resolved.conf.d/test-enable-dnssec.conf << EOF
[Resolve]
DNSSEC=allow-downgrade
LLMNR=no
MulticastDNS=no
DNSOverTLS=no
EOF

ip link add name test_eth42 address de:ad:be:ef:47:11 type veth peer name 
router_eth42
ip a flush dev router_eth42
ip a add 192.168.5.1/24 dev router_eth42
ip link set router_eth42 up

dnsmasq --no-daemon --log-queries --log-facility=/tmp/dnsmasq.log
--conf-file=/dev/null --dhcp-leasefile=/tmp/dnsmasq.leases --bind-
interfaces --interface=router_eth42 --except-interface=lo --dhcp-
range=192.168.5.10,192.168.5.200 --address=/#/192.168.42.1 &

cat > /run/systemd/network/general.network << EOF
[Match]
Name=test_eth42
[Network]
DHCP=ipv4
IPv6AcceptRA=False
DNSSECNegativeTrustAnchors=search.example.com
EOF

ip link add name testvpnclient type veth peer name testvpnrouter
ip a flush dev testvpnrouter
ip a add 10.241.3.1/24 dev testvpnrouter
ip link set testvpnrouter up

dnsmasq --no-daemon --log-queries --log-facility=/tmp/dnsmasq-vpn.log
--conf-file=/dev/null --dhcp-leasefile=/dev/null --bind-interfaces
--interface=testvpnrouter --except-interface=lo
--address=/math.lab/10.241.3.3 --address=/cantina.company/10.241.4.4 &

cat > /run/systemd/network/vpn.network << EOF
[Match]
Name=testvpnclient
[Network]
IPv6AcceptRA=False
Address=10.241.3.2/24
DNS=10.241.3.1
Domains=~company ~lab
DNSSECNegativeTrustAnchors=company la
EOF

systemctl restart systemd-networkd
/usr/lib/systemd/systemd-networkd-wait-online --interface test_eth42 
--interface=testvpnclient --timeout=20
systemctl restart systemd-resolved

# The original test runs "resolvectl query math.lab"
# That would probe everything, do this step by step

#1 ipv4 works and looks pretty much the same result on good/bad case
dig @10.241.3.1 -t A math.lab

root@j-dnsmasq-proposed:~# dig @10.241.3.1 -t A math.lab
dnsmasq: query[A] math.lab from 10.241.3.1
dnsmasq: config math.lab is 10.241.3.3

; <<>> DiG 9.16.15-Ubuntu <<>> @10.241.3.1 -t A math.lab
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11869
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;math.lab.  IN  A

;; ANSWER SECTION:
math.lab.   0   IN  A   10.241.3.3

;; Query time: 0 msec
;; SERVER: 10.241.3.1#53(10.241.3.1)
;; WHEN: Tue Jan 11 13:09:07 UTC 2022
;; MSG SIZE  rcvd: 53

#2 ipv6 fails and gets into a loop
dig @10.241.3.1 -t  math.lab

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-11 Thread Christian Ehrhardt
Result of the repro:


#2 ipv6 fails and gets into a loop
dig @10.241.3.1 -t  math.lab

#2a - Good case (dnsmasq 2.85)
root@j-dnsmasq-release:~# dig @10.241.3.1 -t  math.lab
dnsmasq: query[] math.lab from 10.241.3.1
dnsmasq: config math.lab is NODATA-IPv6

; <<>> DiG 9.16.15-Ubuntu <<>> @10.241.3.1 -t  math.lab
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48650
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;math.lab.  IN  

;; Query time: 0 msec
;; SERVER: 10.241.3.1#53(10.241.3.1)
;; WHEN: Tue Jan 11 13:09:21 UTC 2022
;; MSG SIZE  rcvd: 37


#2b - Bad case (dnsmasq 2.86)

root@j-dnsmasq-proposed:~# dig @10.241.3.1 -t  math.lab
dnsmasq: query[] math.lab from 10.241.3.1
dnsmasq: forwarded math.lab to 127.0.0.53
dnsmasq: query[] math.lab from 10.241.3.1
dnsmasq: forwarded math.lab to 127.0.0.53
dnsmasq: query[] math.lab from 10.241.3.1
...
dnsmasq: Maximum number of concurrent DNS queries reached (max: 150)
dnsmasq: config error is REFUSED
... repeats infinitely


There is no ipv6 answer configured, so it is ok to return an empty/bad answer.

But dnsmasq should not fall into a forwarding loop right?
Or does this test make a hard configuration mistake (always did) that now
in 2.86 exposes an issue, but was always wrong?


The original test command of `resolvectl query math.lab` gets into a "wait
until timeout" with the new behavior.

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1957086] [NEW] Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-11 Thread Christian Ehrhardt
Public bug reported:

Full log (same on all architectures):
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

The test is from systemd:
https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

Tail of the log:
```
ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
resolved: domain-restricted DNS servers
--
Traceback (most recent call last):
  File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 678, 
in test_resolved_domain_restricted_dns
out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
  File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.9/subprocess.py", line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
```


Tagging update-excuse to be shown in excuses

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

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Assignee: Lukas Märdian (slyon)
 Status: New


** Tags: update-excuse

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

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

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


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


[Touch-packages] [Bug 1946854] Re: Merge dnsmasq from Debian unstable for 22.04

2022-01-06 Thread Christian Ehrhardt
https://launchpad.net/ubuntu/+source/dnsmasq/2.86-1.1 built, blocked in
proposed by what looks like test issues not caused by dnsmasq.

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

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

Title:
  Merge dnsmasq from Debian unstable for 22.04

Status in dnsmasq package in Ubuntu:
  Fix Committed

Bug description:
  Scheduled-For: 23.01
  Upstream: tbd
  Debian:   2.86-1
  Ubuntu:   2.85-1ubuntu2


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  dnsmasq (2.86-1) unstable; urgency=low

 * Fix debian/changelog format error. (closes: #986626)

   -- Simon Kelley   Thu, 08 Apr 2021 22:39:00
  +0100

  dnsmasq (2.85-1) unstable; urgency=low

 * New upstream.
 * Includes fix to CVE-2021-3448.
 * Fix manpage typos. (closes: #986150)

   -- Simon Kelley   Sat, 03 Apr 2021 22:17:23
  +0100

  dnsmasq (2.84-1.2) unstable; urgency=medium

 * Non-maintainer upload.
 * Bump old-version in dpkg-maintscript-helper dir_to_symlink calls to also
   clean up after upgrades to an earlier version in testing.

   -- Andreas Beckmann   Thu, 01 Apr 2021 16:01:51
  +0200

  dnsmasq (2.84-1.1) unstable; urgency=medium

 * Non-maintainer upload.
 * Fix symlink to directory conversion for /usr/share/doc/dnsmasq.
   This is achieved by directly calling dpkg-maintscript-helper in the 
preinst,
   postinst, and postrm scripts, since the package does not use debhelper.
   (Closes: #985282)

   -- Sébastien Villemot   Sun, 28 Mar 2021
  10:55:07 +0200

  dnsmasq (2.84-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Sun, 24 Jan 2021 22:02:01
  +

  dnsmasq (2.83-1) unstable; urgency=high

 * New upstream.
 * Includes fixes to CVE-2020-25681 - CVE-2020-25687 inclusive.

   -- Simon Kelley   Fri, 15 Jan 2021 22:22:41
  +

  dnsmasq (2.82-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Fri, 26 Jun 2020 22:22:41
  +

  dnsmasq (2.81-4) unstable; urgency=low

 * Remove runit support when building for Ubuntu. (closes: #960401)

   -- Simon Kelley   Fri, 26 Jun 2020 21:52:44
  +

  dnsmasq (2.81-3) unstable; urgency=low

 * Fixes to control file for bug 958100

   -- Simon Kelley   Sun, 19 Apr 2020 21:44:12
  +

  dnsmasq (2.81-2) unstable; urgency=low

 * Fix FTBFS on kFreeBSD. (closes: #958100)
  
   -- Simon Kelley   Sat, 18 Apr 2020 18:34:15 +

  dnsmasq (2.81-1) unstable; urgency=low

 * New upstream.
 * Fix nodocs/nodoc confusion in rules. (closes: #922758)
 * Add Vcs-* fields to control. (closes: #922422)
 * Add systemd support for multiple daemon instances. (closes: #914305)
 * Add note explaining that ENABLED is SYSV-init only. (closes: #914755)
 * Replace ash with dash in contrib/reverse-dns. (closes: #920224)
 * Move to libidn2. (closes: #932695)
 * Fix RA problem with two interfaces on same net, but RA service on
   only one of the interfaces. (closes: #949565)
 * Fix breakage of dig +trace. (closes: #942363)
 * Fix build faliure with newer Nettle libraries. (closes: #940985)
 * Support runscript init-system (closes: #929884)
 * Security fix for CVE-2019-14834 (closes: #948373)
  
   -- Simon Kelley   Wed, 8 Apr 2020 17:33:15 +

  dnsmasq (2.80-1) unstable; urgency=low

 * New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
 * Close old bugs, long agp fixed. (closes: #802845) (closes: #754299)
 * Provide usr/lib/tmpfiles.d/dnsmasq.conf. (closes: #872396)
 * Run restorecon on /run/dnsmasq for SE Linux. (closes: #872397)

   -- Simon Kelley   Mon, 17 Sep 2018 23:11:25
  +

  dnsmasq (2.79-1) unstable; urgency=low

 * New upstream. (closes: #888200)
 * Fix trust-anchor regex in init script. (closes: #884347)


  ### Old Ubuntu Delta ###

  dnsmasq (2.85-1ubuntu2) impish; urgency=medium

* Revert: 'src/radv.c: avoid leases to be issued forever when not set'
  (LP 1894619) according to the bug and upstream discussion.

   -- Christian Ehrhardt   Tue, 22 Jun
  2021 07:18:30 +0200

  dnsmasq (2.85-1ubuntu1) impish; urgency=medium

* Merge with Debian unstable. Remaining changes:
  - src/radv.c: avoid leases to be issued forever when not set
(LP 1894619)

   -- Christian Ehrhardt   Wed, 02 Jun
  2021 09:34:26 +0200

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


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

[Touch-packages] [Bug 1946854] Re: Merge dnsmasq from Debian unstable for 22.04

2022-01-06 Thread Christian Ehrhardt
This bug was fixed in the package dnsmasq - 2.86-1.1

---
dnsmasq (2.86-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Fix --address=/#/.. which was lost in 2.86. (closes: #995655)

 -- Michael Biebl   Wed, 10 Nov 2021 22:05:45 +0100

dnsmasq (2.86-1) unstable; urgency=low

   * Fix debian/changelog format error. (closes: #986626)

 -- Simon Kelley   Thu, 08 Apr 2021 22:39:00
+0100

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

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

Title:
  Merge dnsmasq from Debian unstable for 22.04

Status in dnsmasq package in Ubuntu:
  Fix Committed

Bug description:
  Scheduled-For: 23.01
  Upstream: tbd
  Debian:   2.86-1
  Ubuntu:   2.85-1ubuntu2


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  dnsmasq (2.86-1) unstable; urgency=low

 * Fix debian/changelog format error. (closes: #986626)

   -- Simon Kelley   Thu, 08 Apr 2021 22:39:00
  +0100

  dnsmasq (2.85-1) unstable; urgency=low

 * New upstream.
 * Includes fix to CVE-2021-3448.
 * Fix manpage typos. (closes: #986150)

   -- Simon Kelley   Sat, 03 Apr 2021 22:17:23
  +0100

  dnsmasq (2.84-1.2) unstable; urgency=medium

 * Non-maintainer upload.
 * Bump old-version in dpkg-maintscript-helper dir_to_symlink calls to also
   clean up after upgrades to an earlier version in testing.

   -- Andreas Beckmann   Thu, 01 Apr 2021 16:01:51
  +0200

  dnsmasq (2.84-1.1) unstable; urgency=medium

 * Non-maintainer upload.
 * Fix symlink to directory conversion for /usr/share/doc/dnsmasq.
   This is achieved by directly calling dpkg-maintscript-helper in the 
preinst,
   postinst, and postrm scripts, since the package does not use debhelper.
   (Closes: #985282)

   -- Sébastien Villemot   Sun, 28 Mar 2021
  10:55:07 +0200

  dnsmasq (2.84-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Sun, 24 Jan 2021 22:02:01
  +

  dnsmasq (2.83-1) unstable; urgency=high

 * New upstream.
 * Includes fixes to CVE-2020-25681 - CVE-2020-25687 inclusive.

   -- Simon Kelley   Fri, 15 Jan 2021 22:22:41
  +

  dnsmasq (2.82-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Fri, 26 Jun 2020 22:22:41
  +

  dnsmasq (2.81-4) unstable; urgency=low

 * Remove runit support when building for Ubuntu. (closes: #960401)

   -- Simon Kelley   Fri, 26 Jun 2020 21:52:44
  +

  dnsmasq (2.81-3) unstable; urgency=low

 * Fixes to control file for bug 958100

   -- Simon Kelley   Sun, 19 Apr 2020 21:44:12
  +

  dnsmasq (2.81-2) unstable; urgency=low

 * Fix FTBFS on kFreeBSD. (closes: #958100)
  
   -- Simon Kelley   Sat, 18 Apr 2020 18:34:15 +

  dnsmasq (2.81-1) unstable; urgency=low

 * New upstream.
 * Fix nodocs/nodoc confusion in rules. (closes: #922758)
 * Add Vcs-* fields to control. (closes: #922422)
 * Add systemd support for multiple daemon instances. (closes: #914305)
 * Add note explaining that ENABLED is SYSV-init only. (closes: #914755)
 * Replace ash with dash in contrib/reverse-dns. (closes: #920224)
 * Move to libidn2. (closes: #932695)
 * Fix RA problem with two interfaces on same net, but RA service on
   only one of the interfaces. (closes: #949565)
 * Fix breakage of dig +trace. (closes: #942363)
 * Fix build faliure with newer Nettle libraries. (closes: #940985)
 * Support runscript init-system (closes: #929884)
 * Security fix for CVE-2019-14834 (closes: #948373)
  
   -- Simon Kelley   Wed, 8 Apr 2020 17:33:15 +

  dnsmasq (2.80-1) unstable; urgency=low

 * New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
 * Close old bugs, long agp fixed. (closes: #802845) (closes: #754299)
 * Provide usr/lib/tmpfiles.d/dnsmasq.conf. (closes: #872396)
 * Run restorecon on /run/dnsmasq for SE Linux. (closes: #872397)

   -- Simon Kelley   Mon, 17 Sep 2018 23:11:25
  +

  dnsmasq (2.79-1) unstable; urgency=low

 * New upstream. (closes: #888200)
 * Fix trust-anchor regex in init script. (closes: #884347)


  ### Old Ubuntu Delta ###

  dnsmasq (2.85-1ubuntu2) impish; urgency=medium

* Revert: 'src/radv.c: avoid leases to be issued forever when not set'
  (LP 1894619) according to the bug and upstream discussion.

   -- Christian Ehrhardt   Tue, 22 Jun
  2021 07:18:30 +0200

  dnsmasq (2.85-1ubuntu1) impish; urgency=medium

* Merge with Debian unstable. Remaining changes:
  - src/radv.c: avoid leases to be issued forever when not set
(LP 1894619)

   -- Christian Ehrhardt   Wed, 02 Jun
  2021 09:34:26 +0200

To manage notifications ab

[Touch-packages] [Bug 1946854] Re: Merge dnsmasq from Debian unstable for 22.04

2022-01-06 Thread Christian Ehrhardt
As you see in 2.85-1ubuntu2 I've reverted the last delta we had.
This is successful so far, on bug report int hat regard.
And since it also followed upstreams guidance on the overall case we will stick 
to that.

There is a new version to sync now 2.86-1.1 which I'll trigger now.


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

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

Title:
  Merge dnsmasq from Debian unstable for 22.04

Status in dnsmasq package in Ubuntu:
  In Progress

Bug description:
  Scheduled-For: 23.01
  Upstream: tbd
  Debian:   2.86-1
  Ubuntu:   2.85-1ubuntu2


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  dnsmasq (2.86-1) unstable; urgency=low

 * Fix debian/changelog format error. (closes: #986626)

   -- Simon Kelley   Thu, 08 Apr 2021 22:39:00
  +0100

  dnsmasq (2.85-1) unstable; urgency=low

 * New upstream.
 * Includes fix to CVE-2021-3448.
 * Fix manpage typos. (closes: #986150)

   -- Simon Kelley   Sat, 03 Apr 2021 22:17:23
  +0100

  dnsmasq (2.84-1.2) unstable; urgency=medium

 * Non-maintainer upload.
 * Bump old-version in dpkg-maintscript-helper dir_to_symlink calls to also
   clean up after upgrades to an earlier version in testing.

   -- Andreas Beckmann   Thu, 01 Apr 2021 16:01:51
  +0200

  dnsmasq (2.84-1.1) unstable; urgency=medium

 * Non-maintainer upload.
 * Fix symlink to directory conversion for /usr/share/doc/dnsmasq.
   This is achieved by directly calling dpkg-maintscript-helper in the 
preinst,
   postinst, and postrm scripts, since the package does not use debhelper.
   (Closes: #985282)

   -- Sébastien Villemot   Sun, 28 Mar 2021
  10:55:07 +0200

  dnsmasq (2.84-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Sun, 24 Jan 2021 22:02:01
  +

  dnsmasq (2.83-1) unstable; urgency=high

 * New upstream.
 * Includes fixes to CVE-2020-25681 - CVE-2020-25687 inclusive.

   -- Simon Kelley   Fri, 15 Jan 2021 22:22:41
  +

  dnsmasq (2.82-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Fri, 26 Jun 2020 22:22:41
  +

  dnsmasq (2.81-4) unstable; urgency=low

 * Remove runit support when building for Ubuntu. (closes: #960401)

   -- Simon Kelley   Fri, 26 Jun 2020 21:52:44
  +

  dnsmasq (2.81-3) unstable; urgency=low

 * Fixes to control file for bug 958100

   -- Simon Kelley   Sun, 19 Apr 2020 21:44:12
  +

  dnsmasq (2.81-2) unstable; urgency=low

 * Fix FTBFS on kFreeBSD. (closes: #958100)
  
   -- Simon Kelley   Sat, 18 Apr 2020 18:34:15 +

  dnsmasq (2.81-1) unstable; urgency=low

 * New upstream.
 * Fix nodocs/nodoc confusion in rules. (closes: #922758)
 * Add Vcs-* fields to control. (closes: #922422)
 * Add systemd support for multiple daemon instances. (closes: #914305)
 * Add note explaining that ENABLED is SYSV-init only. (closes: #914755)
 * Replace ash with dash in contrib/reverse-dns. (closes: #920224)
 * Move to libidn2. (closes: #932695)
 * Fix RA problem with two interfaces on same net, but RA service on
   only one of the interfaces. (closes: #949565)
 * Fix breakage of dig +trace. (closes: #942363)
 * Fix build faliure with newer Nettle libraries. (closes: #940985)
 * Support runscript init-system (closes: #929884)
 * Security fix for CVE-2019-14834 (closes: #948373)
  
   -- Simon Kelley   Wed, 8 Apr 2020 17:33:15 +

  dnsmasq (2.80-1) unstable; urgency=low

 * New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
 * Close old bugs, long agp fixed. (closes: #802845) (closes: #754299)
 * Provide usr/lib/tmpfiles.d/dnsmasq.conf. (closes: #872396)
 * Run restorecon on /run/dnsmasq for SE Linux. (closes: #872397)

   -- Simon Kelley   Mon, 17 Sep 2018 23:11:25
  +

  dnsmasq (2.79-1) unstable; urgency=low

 * New upstream. (closes: #888200)
 * Fix trust-anchor regex in init script. (closes: #884347)


  ### Old Ubuntu Delta ###

  dnsmasq (2.85-1ubuntu2) impish; urgency=medium

* Revert: 'src/radv.c: avoid leases to be issued forever when not set'
  (LP 1894619) according to the bug and upstream discussion.

   -- Christian Ehrhardt   Tue, 22 Jun
  2021 07:18:30 +0200

  dnsmasq (2.85-1ubuntu1) impish; urgency=medium

* Merge with Debian unstable. Remaining changes:
  - src/radv.c: avoid leases to be issued forever when not set
(LP 1894619)

   -- Christian Ehrhardt   Wed, 02 Jun
  2021 09:34:26 +0200

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


-- 
Mailing list: https://launchpad.net/~to

[Touch-packages] [Bug 1943077] Re: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s

2022-01-05 Thread Christian Ehrhardt
We ahve that in Jammy
 snapd | 2.53+21.10ubuntu1   | jammy   | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x

Removing openssl task to not show this outdated update-excuse

** Tags removed: update-excuse

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

Title:
  snapd fails to autopkgtest on mksquashfs, which is looking for
  libgcc_s

Status in snapd:
  Fix Committed
Status in openssh package in Ubuntu:
  New
Status in squashfs-tools package in Ubuntu:
  New

Bug description:
  During current snapd autopkgtest, a failure can be observed:

  https://autopkgtest.ubuntu.com/results/autopkgtest-
  impish/impish/amd64/s/snapd/20210907_175258_5451b@/log.gz

  
  error: cannot pack 
"/home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox":
 mksquashfs call failed: 
  -
  libgcc_s.so.1 must be installed for pthread_cancel to work
  Parallel mksquashfs: Using 1 processor
  Creating 4.0 filesystem on 
/home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox/test-snapd-sandbox_1.0_all.snap,
 block size 131072.
  -
  error: cannot read snap file: "/var/lib/snapd/snaps/.local-install-136125945"
 is not a snap or snapdir

  
  I traced the underlying call to the following:
  "/snap/snapd/current/lib/x86_64-linux-gnu/ld-2.23.so" "--library-path"
  
"/snap/snapd/current/usr/local/lib:/snap/snapd/current/lib/x86_64-linux-gnu:/snap/snapd/current/usr/lib/x86_64-linux-gnu"
  "/snap/snapd/current/usr/bin/mksquashfs" asdf asdf.squashfs

  (the real call has more arguments, this is a simplified version that
  produces the failure)

  To observe this, one can create a VM based a cloud image from
  https://cloud-images.ubuntu.com/impish/current, then run the above command in
  the resulting environment.
  Doing so will test against snapd v2.51.4 (12883).
  Retesting with edge 2.52+git635.gada2d87 (13323) produces an equivalent 
result.

  Running a more bland `/snap/snapd/current/usr/bin/mksquashfs asdf
  asdf.squashfs` without messing with library paths has mksquashfs behaving as
  expected.  Also, getting a v2.51.3 snapd seems to behave itself.  Updating 
from
  2.51.3 -> 2.51.4 also works.

  One can see a passing mksquashfs by taking libgcc_s.so.1 from hirsute
  and placing it in the library path for the above call.

  In the working scenario, it appears that libgcc_s is being obtained
  from outside of /snap (and also libz).  In the failing scenario, this
  external copy of libgcc_s is not being loaded (per gdb info sharedlibrary),
  but libz still is.

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


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


[Touch-packages] [Bug 1955347] Re: rsync works bad with encfs now

2022-01-03 Thread Christian Ehrhardt
I'm marking this incomplete waiting for feedback on the suggested
options or a discussion why this really should be an error to be fixed
in the source (instead of configuration).

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

Title:
  rsync works bad with encfs now

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  Hello,
  I think rsync works bad with encfs now.

  When root uses it, rsync cannot read a directory encrypted with encfs
  by a user. More precisely, it cannot read the mounted directory, the
  virtual one where the user can read the datas.

  Until now there was only a warning like this
  "rsync: readlink_stat("/home/claude/Documents_chiffres") failed:
  Permission denied (13)"
  and the software went on working (only ignoring the content of the mounted 
directory and of course without saving this content)

  But recently there is this more:
  "IO error encountered -- skipping file deletion"
  and because of this "skipping file deletion", the software can't work 
normally. The destination gets bigger more and more because the deleted files 
in the source are not deleted in the destination.

  Thanks for reading me.
  rsync 3.1.3-8ubuntu0.1
  Description:Ubuntu 20.04.3 LTS
  Release:20.04

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


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


[Touch-packages] [Bug 1955347] Re: rsync works bad with encfs now

2022-01-03 Thread Christian Ehrhardt
Hi,
I'm not 100% sure but to me that is a setup and configuration issue with the 
new version being a bit more insisting that it can read/access paths it is 
supposed to back up.

The new behavior can be disabled with --ignore-errors, but I'm tempted
to consider this dangerous as you could have any other I/O error and it
would still delete things.

Did you try to use --exclude=PATTERN and if that matches your use case
--delete-excluded to make the new version behave as you were used from
the older one?

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

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

Title:
  rsync works bad with encfs now

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  Hello,
  I think rsync works bad with encfs now.

  When root uses it, rsync cannot read a directory encrypted with encfs
  by a user. More precisely, it cannot read the mounted directory, the
  virtual one where the user can read the datas.

  Until now there was only a warning like this
  "rsync: readlink_stat("/home/claude/Documents_chiffres") failed:
  Permission denied (13)"
  and the software went on working (only ignoring the content of the mounted 
directory and of course without saving this content)

  But recently there is this more:
  "IO error encountered -- skipping file deletion"
  and because of this "skipping file deletion", the software can't work 
normally. The destination gets bigger more and more because the deleted files 
in the source are not deleted in the destination.

  Thanks for reading me.
  rsync 3.1.3-8ubuntu0.1
  Description:Ubuntu 20.04.3 LTS
  Release:20.04

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


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


[Touch-packages] [Bug 1955985] Re: installation crashes with error "Setting up openssh-client (1:8.7p1-3) ... update-alternatives: and can't be the same"

2022-01-03 Thread Christian Ehrhardt
Indeed fixed in the referred version
https://salsa.debian.org/ssh-team/openssh/-/blob/master/debian/changelog#L4

Debian Bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002803

This is already in jammy-proposed
 openssh-client | 1:8.7p1-4   | jammy-proposed   | amd64, arm64, armhf, 
i386, ppc64el, riscv64, s390x


** Bug watch added: Debian Bug tracker #1002803
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002803

** Also affects: openssh (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002803
   Importance: Unknown
   Status: Unknown

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

Title:
  installation crashes with error "Setting up openssh-client (1:8.7p1-3)
  ... update-alternatives:  and  can't be the same"

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh package in Debian:
  Unknown

Bug description:
  Description:Ubuntu Jammy Jellyfish (development branch)
  Release:22.04
  openssh-client (1:8.7p1-3)
  I expected it to install normally.
  The installation crashed.
  E: Sub-process /usr/bin/dpkg returned an error code (1)

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


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


[Touch-packages] [Bug 1915238] Re: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

2022-01-03 Thread Christian Ehrhardt
Thank you Scott!

As reference, that mentioned change is [1] and not yet part of a Debian
upload to sync/merge.

[1]: https://salsa.debian.org/postfix-team/postfix-
dev/-/commit/01fb7f1b307fb9bbc025d90dd404c9bff89f76ff

** Tags added: server-todo

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

Title:
  warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and
  /etc/ssl/certs/ca-certificates.crt differ

Status in ca-certificates package in Ubuntu:
  Invalid
Status in postfix package in Ubuntu:
  Triaged
Status in postfix package in Debian:
  Fix Committed

Bug description:
  Postfix package doesn't utilize update-ca-certificate's hooks
  mechanism. By simply copying certs from /etc/ssl/certs/ca-
  certificates.crt to /var/spool/postfix/etc/ssl/certs/ca-
  certificates.crt, this warning and potential security issues could be
  avoided.

  Something like this would be a start:

  $ cat /etc/ca-certificates/update.d/postfix 
  #!/bin/bash

  if [ -e /var/spool/postfix/etc/ssl/certs/ca-certificates.crt ]; then
  echo "Updating postfix chrooted certs"
  cp /etc/ssl/certs/ca-certificates.crt 
/var/spool/postfix/etc/ssl/certs/ca-certificates.crt
  systemctl reload postfix
  fi

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1915238/+subscriptions


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


[Touch-packages] [Bug 1548486] Re: Sleep hook in a subdirectory ignored but causes double execution of previous hook

2021-12-08 Thread Christian Ehrhardt
** Tags removed: server-triage-discuss

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

Title:
  Sleep hook in a subdirectory ignored but causes double execution of
  previous hook

Status in pm-utils:
  Won't Fix
Status in pm-utils package in Ubuntu:
  Confirmed

Bug description:
  The set of sleep hooks provided in /usr/lib/pm-utils/sleep.d includes
  one (95packagekit/95packagekit) that is stored in a subdirectory. This
  has two effects:

  1the hook is not run;

  2the previous hook, currently /usr/lib/pm-utils/sleep.d/95led, is
  run for a second time instead.

  Presumably #1 is wrong, and results from an installation fault in
  packagekit,  separately reported as bug 1548480.

  #2 occurs because the function run_hooks() in /usr/lib/pm-utils/pm-
  functions computes a list of to-be-executed hooks that includes
  directories but neither fully validates each such hook as a regular
  file nor handles a set of to-be-executed hooks in a subdirectory.

  At lines 243 on, there is  a code path with no else clause through
  which the $hook from the previous iteration can be accidentally
  reused:

if [ -f "$syshooks/$base" ]; then
hook="$syshooks/$base"
elif [ -f "$phooks/$base" ]; then
hook="$phooks/$base"
fi

  An easy fix is to insert the missing else clause before the fi line so
  that the script skips the subdirectory or other non-regular file and
  carries on with the next correctly specified hook:

if [ -f "$syshooks/$base" ]; then
hook="$syshooks/$base"
elif [ -f "$phooks/$base" ]; then
hook="$phooks/$base"
else 
continue
fi

  Observed in Lubuntu 14.04.3,4 with pm-utils 1.4.1-13ubuntu0.1,2.
  However the relevant pm-utils code dates back to 2008, pm-utils
  upstream version 1.1.0.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: pm-utils 1.4.1-13ubuntu0.2 [modified: usr/lib/pm-utils/pm-functions]
  ProcVersionSignature: Ubuntu 4.2.0-29.34~14.04.1-generic 4.2.8-ckt3
  Uname: Linux 4.2.0-29-generic i686
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: i386
  Date: Mon Feb 22 17:10:53 2016
  InstallationDate: Installed on 2016-02-21 (0 days ago)
  InstallationMedia: Lubuntu 14.04.4 LTS "Trusty Tahr" - Release i386 
(20160217.1)
  PackageArchitecture: all
  SourcePackage: pm-utils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/pm-utils/+bug/1548486/+subscriptions


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


[Touch-packages] [Bug 1548486] Re: Sleep hook in a subdirectory ignored but causes double execution of previous hook

2021-12-02 Thread Christian Ehrhardt
** Tags removed: server-todo
** Tags added: server-triage-discuss

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

Title:
  Sleep hook in a subdirectory ignored but causes double execution of
  previous hook

Status in pm-utils:
  Won't Fix
Status in pm-utils package in Ubuntu:
  Confirmed

Bug description:
  The set of sleep hooks provided in /usr/lib/pm-utils/sleep.d includes
  one (95packagekit/95packagekit) that is stored in a subdirectory. This
  has two effects:

  1the hook is not run;

  2the previous hook, currently /usr/lib/pm-utils/sleep.d/95led, is
  run for a second time instead.

  Presumably #1 is wrong, and results from an installation fault in
  packagekit,  separately reported as bug 1548480.

  #2 occurs because the function run_hooks() in /usr/lib/pm-utils/pm-
  functions computes a list of to-be-executed hooks that includes
  directories but neither fully validates each such hook as a regular
  file nor handles a set of to-be-executed hooks in a subdirectory.

  At lines 243 on, there is  a code path with no else clause through
  which the $hook from the previous iteration can be accidentally
  reused:

if [ -f "$syshooks/$base" ]; then
hook="$syshooks/$base"
elif [ -f "$phooks/$base" ]; then
hook="$phooks/$base"
fi

  An easy fix is to insert the missing else clause before the fi line so
  that the script skips the subdirectory or other non-regular file and
  carries on with the next correctly specified hook:

if [ -f "$syshooks/$base" ]; then
hook="$syshooks/$base"
elif [ -f "$phooks/$base" ]; then
hook="$phooks/$base"
else 
continue
fi

  Observed in Lubuntu 14.04.3,4 with pm-utils 1.4.1-13ubuntu0.1,2.
  However the relevant pm-utils code dates back to 2008, pm-utils
  upstream version 1.1.0.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: pm-utils 1.4.1-13ubuntu0.2 [modified: usr/lib/pm-utils/pm-functions]
  ProcVersionSignature: Ubuntu 4.2.0-29.34~14.04.1-generic 4.2.8-ckt3
  Uname: Linux 4.2.0-29-generic i686
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: i386
  Date: Mon Feb 22 17:10:53 2016
  InstallationDate: Installed on 2016-02-21 (0 days ago)
  InstallationMedia: Lubuntu 14.04.4 LTS "Trusty Tahr" - Release i386 
(20160217.1)
  PackageArchitecture: all
  SourcePackage: pm-utils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/pm-utils/+bug/1548486/+subscriptions


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


[Touch-packages] [Bug 1639452] Re: systemd ExecStartPre test config

2021-11-25 Thread Christian Ehrhardt
** Changed in: dnsmasq (Ubuntu)
 Assignee: Miriam España Acebal (mirespace) => (unassigned)

** Changed in: dnsmasq (Ubuntu Bionic)
 Assignee: Miriam España Acebal (mirespace) => (unassigned)

** Changed in: dnsmasq (Ubuntu Focal)
 Assignee: Miriam España Acebal (mirespace) => (unassigned)

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

Title:
  systemd ExecStartPre test config

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Bionic:
  Opinion
Status in dnsmasq source package in Focal:
  Opinion

Bug description:
  The standard configuration file of dnsmasq is complete commented out.
  The real configuration is saved in /etc/dnsmasq.d, so the test of
  systemd is a fake.

  In the Service Section of /lib/systemd/system/dnsmasq.service the
  ExecStartPre directive should be set to "/usr/sbin/dnsmasq --conf-
  dir=/etc/dnsmasq.d --test"

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


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


[Touch-packages] [Bug 1951779] Re: tempfile command removed from debianutils

2021-11-25 Thread Christian Ehrhardt
We all wanted to have a look, this is what I found:


boost/boost1.74-1.74.0/tools/quickbook/build/warning-check:5:tmpfile=$(tempfile)
That is in jammy's current 1.74.0-13ubuntu1 but only referenced for travis runs 
(of the doc build).
Worth a task to check in detail, but unlikely to need a fix.

ceph/ceph/src/boost/tools/quickbook/build/warning-check:5:tmpfile=$(tempfile)
^^ That is the same as above as embedded source, worth a check if it is used 
indirectly anywhere (unlikely).

get-docker-images/ubuntu-layer/bin/bzexe:123:tmpfile=`tempfile -p gztmp -d 
/tmp` || exit 1
I found it here but it is actually part of src:bzip2
Fixed by
https://salsa.debian.org/debian/bzip2/-/commit/aff0bec9ea82646baf6d9d824022bc6f3cf46514
This is not yet uploaded to Debian and therefore missing in Jammy as well

** Also affects: boost1.74 (Ubuntu)
   Importance: Undecided
   Status: New

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

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

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

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

** Changed in: boost1.74 (Ubuntu)
   Importance: Undecided => Wishlist

** Changed in: grub-legacy-ec2 (Ubuntu)
   Importance: Undecided => Medium

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

Title:
  tempfile command removed from debianutils

Status in boost1.74 package in Ubuntu:
  New
Status in bzip2 package in Ubuntu:
  New
Status in ceph package in Ubuntu:
  New
Status in grub-legacy-ec2 package in Ubuntu:
  Triaged

Bug description:
  Error when do-release-upgrade -d from 20.04.3

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: linux-image-5.13.0-19-generic 5.13.0-19.19
  ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
  Uname: Linux 5.4.0-90-generic x86_64
  ApportVersion: 2.20.11-0ubuntu73
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/controlC0', '/dev/snd/hwC0D2', '/dev/snd/pcmC0D3p', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: unknown
  Date: Mon Nov 22 13:31:36 2021
  ErrorMessage: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited with 
return code 127
  InstallationDate: Installed on 2018-10-01 (1147 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 001 Device 002: ID 8087:07e6 Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
  MachineType: PAIQ EC3-BT19D4L
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-90-generic 
root=UUID=4c36d2b3-c1dd-469f-bfbf-5b7052d669d4 ro ipv6.disable=1 quiet 
reboot=pci ipv6.disable=1
  Python3Details: Error: command ['readlink', '-f', "/usr/bin/which: this 
version of `which' is deprecated; use `command -v' in scripts 
instead.\n/usr/bin/python3"] failed with exit code 1: , Error: [Errno 2] No 
such file or directory: 'Error: command [\'readlink\', \'-f\', "/usr/bin/which: 
this version of `which\' is deprecated; use `command -v\' in scripts 
instead.\\n/usr/bin/python3"] failed with exit code 1: ', python3-minimal, 
3.9.4-1build1
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions: grub-pc 2.04-1ubuntu48
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: grub-legacy-ec2
  Title: package linux-image-5.13.0-19-generic 5.13.0-19.19 failed to 
install/upgrade: run-parts: /etc/kernel/postinst.d/x-grub-legacy-ec2 exited 
with return code 127
  UpgradeStatus: Upgraded to jammy on 2021-11-22 (0 days ago)
  dmi.bios.date: 02/28/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 5.6.5
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: EC3-BT19D4L
  dmi.board.vendor: PAIQ
  dmi.board.version: A1
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr5.6.5:bd02/28/2017:svnPAIQ:pnEC3-BT19D4L:pvrBIOSNameBT190003BIOSVersionA1BuildDate:rvnPAIQ:rnEC3-BT19D4L:rvrA1:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: EC3-BT19D4L
  dmi.product.sku: 18:19:28
  dmi.product.version: BIOS Name:BT190003 BIOS Version:A1 Build Date:
  dmi.sys.vendor: PAIQ

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/boost1.74/+bug/1951779/+subscriptions


-- 
Mailing list: 

[Touch-packages] [Bug 1639452] Re: systemd ExecStartPre test config

2021-11-24 Thread Christian Ehrhardt
** Changed in: dnsmasq (Ubuntu Bionic)
 Assignee: (unassigned) => Miriam España Acebal (mirespace)

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

Title:
  systemd ExecStartPre test config

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Bionic:
  Triaged
Status in dnsmasq source package in Focal:
  Triaged

Bug description:
  The standard configuration file of dnsmasq is complete commented out.
  The real configuration is saved in /etc/dnsmasq.d, so the test of
  systemd is a fake.

  In the Service Section of /lib/systemd/system/dnsmasq.service the
  ExecStartPre directive should be set to "/usr/sbin/dnsmasq --conf-
  dir=/etc/dnsmasq.d --test"

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


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


[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2021-11-17 Thread Christian Ehrhardt
FYI triggered again for me due to unattended upgrades.
The time in the journal when things go down matches the 
unpack/configuee/install phase of
- accountsservice:amd64 0.6.55-0ubuntu12~20.04.5
- libaccountsservice0:amd64 0.6.55-0ubuntu12~20.04.5
- dbus:amd64 1.12.16-2ubuntu2.1

I - again - had the usual suspect entries:

systemd[1]: Starting Daily apt upgrade and clean activities...
dbus-daemon[2266]: [system] Reloaded configuration
dbus-daemon[2266]: Unknown group "power" in message bus configuration file
systemd[1]: Reloading.
systemd[1]: NetworkManager.service: Unexpected error response from 
GetNameOwner(): Connection terminated

I didn't see anything in the log we didn't have before, but for
completeness I'm attaching journal of the issue and a few hours before
it

** Attachment added: "journal entries around the issues happening on 
unattended-upgrades"
   
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/+attachment/5541619/+files/fail-18Nov-6-24-07.log

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

Title:
  dbus timeout-ed during an upgrade, taking services down including gdm

Status in D-Bus:
  Unknown
Status in systemd:
  New
Status in accountsservice package in Ubuntu:
  Invalid
Status in dbus package in Ubuntu:
  Incomplete
Status in gnome-shell package in Ubuntu:
  Invalid
Status in accountsservice source package in Focal:
  Invalid
Status in dbus source package in Focal:
  Incomplete
Status in gnome-shell source package in Focal:
  Invalid
Status in accountsservice source package in Groovy:
  Invalid
Status in dbus source package in Groovy:
  Incomplete
Status in gnome-shell source package in Groovy:
  Invalid
Status in accountsservice source package in Hirsute:
  Invalid
Status in dbus source package in Hirsute:
  Incomplete
Status in gnome-shell source package in Hirsute:
  Invalid
Status in accountsservice source package in Impish:
  Invalid
Status in dbus source package in Impish:
  Incomplete
Status in gnome-shell source package in Impish:
  Invalid

Bug description:
  This morning I found my computer on the login screen.
  But not the one of the screen log, no a new one - so something must have 
crashed.

  Logging in again confirmed that all apps were gone and the gnome shell
  was brought down what seems like triggered by a background update o
  accountsservice.

  As always things are not perfectly clear :-/
  The following goes *back* in time through my logs one by one.

  Multiple apps crashed at 06:09, but we will find later that this is a follow 
on issue of the underlying gnome/X/... recycling.
  -rw-r-  1 paelzer  whoopsie 52962868 Apr  8 06:09 
_usr_bin_konversation.1000.crash
  -rw-r-  1 paelzer  whoopsie   986433 Apr  8 06:09 
_usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash

  
  rdkit was failing fast and giving up (that will be a different bug, it just 
seems broken on my system):
  Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling 
Policy Service.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called 
chroot.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped 
privileges.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited 
resources.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: 
Resource temporarily unavailable
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time 
threads.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via 
systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=>
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request 
repeated too quickly.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit 
Scheduling Policy Service.
  Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53

  
  But that already was only triggered by a gnome restart that kicked of earlier:

  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on 
Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
is initialized.
  Apr 08 06:09:27 Keschdeichel 

[Touch-packages] [Bug 1639452] Re: systemd ExecStartPre test config

2021-11-17 Thread Christian Ehrhardt
oh Focal is affected as well, that makes it more reasonable to at least
consider a smaller version (not the full rewrite, but as suggested maybe
pass the config dir at least).

** Also affects: dnsmasq (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: dnsmasq (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: dnsmasq (Ubuntu Focal)
   Status: New => Triaged

** Changed in: dnsmasq (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: dnsmasq (Ubuntu Bionic)
   Importance: Undecided => Low

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

** Tags added: server-todo

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

Title:
  systemd ExecStartPre test config

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Bionic:
  Triaged
Status in dnsmasq source package in Focal:
  Triaged

Bug description:
  The standard configuration file of dnsmasq is complete commented out.
  The real configuration is saved in /etc/dnsmasq.d, so the test of
  systemd is a fake.

  In the Service Section of /lib/systemd/system/dnsmasq.service the
  ExecStartPre directive should be set to "/usr/sbin/dnsmasq --conf-
  dir=/etc/dnsmasq.d --test"

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


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


[Touch-packages] [Bug 1639452] Re: systemd ExecStartPre test config

2021-11-17 Thread Christian Ehrhardt
Enough late posts for a lack of activity on this, this time I think we
can close it :-)

What used to be:
ExecStartPre=/usr/sbin/dnsmasq --test

Nowadays is:
ExecStartPre=/etc/init.d/dnsmasq checkconfig
that maps it to
${DAEMON} --test ${CONFIG_DIR:+ -7 ${CONFIG_DIR}} ${DNSMASQ_OPTS:+ 
${DNSMASQ_OPTS}} >/dev/null 2>&1

Which includes not only config-dir but also all other configs that might
affect it.


It is not yet started as After=systemd-resolved.service but tolerates both 
modes nowadays.
1. with systemd-resolved stopped

● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
 Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Wed 2021-11-17 15:49:59 UTC; 5s ago
Process: 29898 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, 
status=0/SUCCESS)
Process: 29906 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
Process: 29915 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=exited, status=0/SUCCESS)
   Main PID: 29914 (dnsmasq)
  Tasks: 1 (limit: 38266)
 Memory: 2.0M
 CGroup: /system.slice/dnsmasq.service
 └─29914 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq 
-7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service 
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c>

Nov 17 15:49:59 j systemd[1]: Starting dnsmasq - A lightweight DHCP and caching 
DNS server...
Nov 17 15:49:59 j dnsmasq[29914]: started, version 2.85 cachesize 150
Nov 17 15:49:59 j dnsmasq[29914]: DNS service limited to local subnets
Nov 17 15:49:59 j dnsmasq[29914]: compile time options: IPv6 GNU-getopt DBus 
no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash 
DNSSEC loop-detect inotify dumpfile
Nov 17 15:49:59 j dnsmasq[29914]: reading /etc/resolv.conf
Nov 17 15:49:59 j dnsmasq[29914]: using nameserver 127.0.0.53#53
Nov 17 15:49:59 j dnsmasq[29914]: read /etc/hosts - 7 addresses
Nov 17 15:49:59 j systemd[1]: Started dnsmasq - A lightweight DHCP and caching 
DNS server.

2. with systemd-resolved stopped and /etc/resolv.conf removed

● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
 Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Wed 2021-11-17 15:50:41 UTC; 3s ago
Process: 29937 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, 
status=0/SUCCESS)
Process: 29945 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
Process: 29954 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=exited, status=0/SUCCESS)
   Main PID: 29953 (dnsmasq)
  Tasks: 1 (limit: 38266)
 Memory: 1.8M
 CGroup: /system.slice/dnsmasq.service
 └─29953 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq 
-7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service 
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c>

Nov 17 15:50:41 j systemd[1]: Starting dnsmasq - A lightweight DHCP and caching 
DNS server...
Nov 17 15:50:41 j dnsmasq[29953]: started, version 2.85 cachesize 150
Nov 17 15:50:41 j dnsmasq[29953]: DNS service limited to local subnets
Nov 17 15:50:41 j dnsmasq[29953]: compile time options: IPv6 GNU-getopt DBus 
no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash 
DNSSEC loop-detect inotify dumpfile
Nov 17 15:50:41 j dnsmasq[29953]: read /etc/hosts - 7 addresses
Nov 17 15:50:41 j systemd[1]: Started dnsmasq - A lightweight DHCP and caching 
DNS server.


In none of these modes it gets stuck and I'm unsure if adding the After 
nowadays would really be right. Even if so as I explained in the past that 
should go through a report to the Debian bug tracker as the issue is not Ubuntu 
specific in this case and we'd like to fix both.


---

Backports of this change are unlikely to qualify for the SRU process [1]
as the rework of the init scripts can have plenty of side effects that
might break existing users.

So the check it runs in ExecStartPre might be useless, but only if it
would really break people (and I've not seen reports other than this
one, so it might not be that common of a problem at all) it might
justify the risk of changing that. It is valid for a backport, but IMHO
low prio and probably not done unless somebody speaks up outlining why
this is more severe than it seems.

Bionic is still affected, I'm marking this as such.

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

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

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

Title:
  systemd ExecStartPre test config

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Bionic:
  Triaged
Status in dnsmasq source package in Focal:
 

[Touch-packages] [Bug 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

2021-11-17 Thread Christian Ehrhardt
** Changed in: openssl (Ubuntu)
   Status: New => Invalid

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

Title:
  strongswan: Fail to build against OpenSSL 3.0

Status in OpenSSL:
  Fix Released
Status in strongSwan:
  New
Status in openssl package in Ubuntu:
  Invalid
Status in strongswan package in Ubuntu:
  New

Bug description:
  Hello,

  As part of a rebuild against OpenSSL3, this package failed to build on one or
  several architectures. You can find the details of the rebuild at 

  https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html

  or for the amd64 failed build, directly at

  
https://launchpad.net/~schopin/+archive/ubuntu/openssl-3.0.0/+build/22099394/+files/buildlog_ubuntu-
  impish-amd64.strongswan_5.9.1-1ubuntu3.0~ssl3ppa1.1_BUILDING.txt.gz

  We're planning to transition to OpenSSL 3.0 for the 22.04 release, and 
consider
  this issue as blocking for this transition.

  You can find general migration informations at
  https://www.openssl.org/docs/manmaster/man7/migration_guide.html
  For your tests, you can build against libssl-dev as found in the PPA
  schopin/openssl-3.0.0

  The issue looks fixed upstream on master:
  
https://github.com/strongswan/strongswan/commit/72e5b3b7022ad14b245565a5aadcd097106af168

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


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


[Touch-packages] [Bug 1662620] Re: "ip addr add" permits illegal labels

2021-10-21 Thread Christian Ehrhardt
Thanks Chris for having a look.

> On the other hand, from the bug it looks like if you *don't* mix valid and 
> invalid labels
> then everything actually works? So this would potentially be breaking 
> currently working setups?

Yes while having that echoing in my head for a while I think you are
right. We would have the chance to disrupt working setups, so I beg your
pardon and would step back marking it won't fix.

** Changed in: iproute2 (Ubuntu Bionic)
   Status: Incomplete => Won't Fix

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

Title:
  "ip addr add" permits illegal labels

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Won't Fix

Bug description:
  [Impact]

   * The filter on label names does not match the intention
 by upstream nor the description in the man page

   * Fix by backporting upstream fix that strengthens the check

  [Test Plan]

  Bad case:
  root@b:~# ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).
  root@b:~# ip addr add 1.1.1.1 label eth0-test dev eth0
  root@b:~# ip addr show dev eth0 | grep test
  inet 1.1.1.1/32 scope global eth0-test

  With the fix it should look like:
  root@i:~# ip addr add 1.1.1.1 label test1 dev eth0
  "label" (test1) must match "dev" (eth0) or be prefixed by "dev" with a colon.
  root@i:~# ip addr add 1.1.1.1 label eth0-test dev eth0
  "label" (eth0-test) must match "dev" (eth0) or be prefixed by "dev" with a 
colon.
  root@i:~# ip addr show dev eth0 | grep test

  [Where problems could occur]

   * While the fix indeed "corrects" behavior I must say that if someone 
 relied on the non-intended behavior it would now break e.g. his 
 scripting or automation.

  [Other Info]
   
   * It was too easy to fix and too long dormant to ignore it further,
 but if the SRU team says this is too much regression risk relative to 
 the gain we will mark it Won't Fix based on that decision.

  
  ---

  ip-address(8) manpage states:

    label NAME
  Each address may be tagged with a label string.  In order to preserve 
compatibility with Linux-2.0 net aliases, this string must coincide with the 
name of the device or must be prefixed with the device name followed by colon.

  But you can omit the colon, "ip addr add" is ONLY checking the label
  is prefixed with the device:

  # ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).

  # ip addr add 1.1.1.2 label eth0-test2 dev eth0

  # ip addr add 1.1.1.3 label eth0:test3 dev eth0

  Now ifconfig becomes confused about eth0-test2:

  # ifconfig eth0-test2
  eth0-test2: error fetching interface information: Device not found

  # ifconfig eth0:test3
  eth0:test3 Link encap:Ethernet  HWaddr b0:d5:cc:fe:1d:7c
    inet addr:1.1.1.3  Bcast:0.0.0.0  Mask:255.255.255.255
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    Interrupt:171

  And daemons like ntpd also log errors about the interface with the
  illegal label:

  ntpd[7570]: eth0-test3: getting interface flags: No such device
    ## => many of this error per minute until:
  ntpd[7570]: Too many errors.  Shutting up.

  So, I think ip addr show disallow adding address with illegal (as
  stated by his own documentation) labels, it must also check for the
  colon following the dev name.

  Version: 4.3.0-1ubuntu3

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


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


[Touch-packages] [Bug 1946854] Re: Merge dnsmasq from Debian unstable for 22.04

2021-10-14 Thread Christian Ehrhardt
** Changed in: dnsmasq (Ubuntu)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Tags removed: needs-merge
** Tags added: needs-sync

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

Title:
  Merge dnsmasq from Debian unstable for 22.04

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  Scheduled-For: 23.01
  Upstream: tbd
  Debian:   2.86-1
  Ubuntu:   2.85-1ubuntu2


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  dnsmasq (2.86-1) unstable; urgency=low

 * Fix debian/changelog format error. (closes: #986626)

   -- Simon Kelley   Thu, 08 Apr 2021 22:39:00
  +0100

  dnsmasq (2.85-1) unstable; urgency=low

 * New upstream.
 * Includes fix to CVE-2021-3448.
 * Fix manpage typos. (closes: #986150)

   -- Simon Kelley   Sat, 03 Apr 2021 22:17:23
  +0100

  dnsmasq (2.84-1.2) unstable; urgency=medium

 * Non-maintainer upload.
 * Bump old-version in dpkg-maintscript-helper dir_to_symlink calls to also
   clean up after upgrades to an earlier version in testing.

   -- Andreas Beckmann   Thu, 01 Apr 2021 16:01:51
  +0200

  dnsmasq (2.84-1.1) unstable; urgency=medium

 * Non-maintainer upload.
 * Fix symlink to directory conversion for /usr/share/doc/dnsmasq.
   This is achieved by directly calling dpkg-maintscript-helper in the 
preinst,
   postinst, and postrm scripts, since the package does not use debhelper.
   (Closes: #985282)

   -- Sébastien Villemot   Sun, 28 Mar 2021
  10:55:07 +0200

  dnsmasq (2.84-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Sun, 24 Jan 2021 22:02:01
  +

  dnsmasq (2.83-1) unstable; urgency=high

 * New upstream.
 * Includes fixes to CVE-2020-25681 - CVE-2020-25687 inclusive.

   -- Simon Kelley   Fri, 15 Jan 2021 22:22:41
  +

  dnsmasq (2.82-1) unstable; urgency=low

 * New upstream.

   -- Simon Kelley   Fri, 26 Jun 2020 22:22:41
  +

  dnsmasq (2.81-4) unstable; urgency=low

 * Remove runit support when building for Ubuntu. (closes: #960401)

   -- Simon Kelley   Fri, 26 Jun 2020 21:52:44
  +

  dnsmasq (2.81-3) unstable; urgency=low

 * Fixes to control file for bug 958100

   -- Simon Kelley   Sun, 19 Apr 2020 21:44:12
  +

  dnsmasq (2.81-2) unstable; urgency=low

 * Fix FTBFS on kFreeBSD. (closes: #958100)
  
   -- Simon Kelley   Sat, 18 Apr 2020 18:34:15 +

  dnsmasq (2.81-1) unstable; urgency=low

 * New upstream.
 * Fix nodocs/nodoc confusion in rules. (closes: #922758)
 * Add Vcs-* fields to control. (closes: #922422)
 * Add systemd support for multiple daemon instances. (closes: #914305)
 * Add note explaining that ENABLED is SYSV-init only. (closes: #914755)
 * Replace ash with dash in contrib/reverse-dns. (closes: #920224)
 * Move to libidn2. (closes: #932695)
 * Fix RA problem with two interfaces on same net, but RA service on
   only one of the interfaces. (closes: #949565)
 * Fix breakage of dig +trace. (closes: #942363)
 * Fix build faliure with newer Nettle libraries. (closes: #940985)
 * Support runscript init-system (closes: #929884)
 * Security fix for CVE-2019-14834 (closes: #948373)
  
   -- Simon Kelley   Wed, 8 Apr 2020 17:33:15 +

  dnsmasq (2.80-1) unstable; urgency=low

 * New upstream. (closes: #837602) (closes: #794640) (closes: #794636)
 * Close old bugs, long agp fixed. (closes: #802845) (closes: #754299)
 * Provide usr/lib/tmpfiles.d/dnsmasq.conf. (closes: #872396)
 * Run restorecon on /run/dnsmasq for SE Linux. (closes: #872397)

   -- Simon Kelley   Mon, 17 Sep 2018 23:11:25
  +

  dnsmasq (2.79-1) unstable; urgency=low

 * New upstream. (closes: #888200)
 * Fix trust-anchor regex in init script. (closes: #884347)


  ### Old Ubuntu Delta ###

  dnsmasq (2.85-1ubuntu2) impish; urgency=medium

* Revert: 'src/radv.c: avoid leases to be issued forever when not set'
  (LP 1894619) according to the bug and upstream discussion.

   -- Christian Ehrhardt   Tue, 22 Jun
  2021 07:18:30 +0200

  dnsmasq (2.85-1ubuntu1) impish; urgency=medium

* Merge with Debian unstable. Remaining changes:
  - src/radv.c: avoid leases to be issued forever when not set
(LP 1894619)

   -- Christian Ehrhardt   Wed, 02 Jun
  2021 09:34:26 +0200

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


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


[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode

2021-10-14 Thread Christian Ehrhardt
Hi Christian,
I saw both, the close and your question.
I'd assume that Steve is updating those in a semi-automated fashion, there is 
no way he could read all those bugs.

Per bug status this one is marked fixed and only had a bug task open to 
backport to Precise.
In fact the upstream commit that fixes this:

commit 9380ba70d67db6b69f817d8e318de5ba1e990b12
Author: Simon Kelley 
Date:   Mon Apr 16 14:41:56 2012 +0100

Set SO_BINDTODEVICE on DHCP sockets when doing DHCP on one interface
only. Fixes OpenSTack use-case.

Has landed in 2.61.

And all Ubuntu release are >2.61 nowadays

 dnsmasq | 2.68-1 | trusty| source
 dnsmasq | 2.68-1 | trusty/universe   | all
 dnsmasq | 2.68-1ubuntu0.2| trusty-security   | source
 dnsmasq | 2.68-1ubuntu0.2| trusty-security/universe  | all
 dnsmasq | 2.68-1ubuntu0.2| trusty-updates| source
 dnsmasq | 2.68-1ubuntu0.2| trusty-updates/universe   | all
 dnsmasq | 2.75-1 | xenial| source
 dnsmasq | 2.75-1 | xenial/universe   | all
 dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-security   | source
 dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-security/universe  | all
 dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-updates| source
 dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-updates/universe   | all
 dnsmasq | 2.79-1 | bionic| source
 dnsmasq | 2.79-1 | bionic/universe   | all
 dnsmasq | 2.79-1ubuntu0.4| bionic-security   | source
 dnsmasq | 2.79-1ubuntu0.4| bionic-security/universe  | all
 dnsmasq | 2.79-1ubuntu0.4| bionic-updates| source
 dnsmasq | 2.79-1ubuntu0.4| bionic-updates/universe   | all
 dnsmasq | 2.79-1ubuntu0.5| bionic-proposed   | source
 dnsmasq | 2.79-1ubuntu0.5| bionic-proposed/universe  | all
 dnsmasq | 2.80-1.1ubuntu1| focal | source
 dnsmasq | 2.80-1.1ubuntu1| focal/universe| all
 dnsmasq | 2.80-1.1ubuntu1.4  | focal-security| source
 dnsmasq | 2.80-1.1ubuntu1.4  | focal-security/universe   | all
 dnsmasq | 2.80-1.1ubuntu1.4  | focal-updates | source
 dnsmasq | 2.80-1.1ubuntu1.4  | focal-updates/universe| all
 dnsmasq | 2.84-1ubuntu2  | hirsute   | source
 dnsmasq | 2.84-1ubuntu2  | hirsute/universe  | all
 dnsmasq | 2.84-1ubuntu2.1| hirsute-security  | source
 dnsmasq | 2.84-1ubuntu2.1| hirsute-security/universe | all
 dnsmasq | 2.84-1ubuntu2.1| hirsute-updates   | source
 dnsmasq | 2.84-1ubuntu2.1| hirsute-updates/universe  | all
 dnsmasq | 2.85-1ubuntu2  | impish| source
 dnsmasq | 2.85-1ubuntu2  | impish/universe   | all

Therefore, yes the assumption would be that it is fixed in all remaining active 
releases.
I've not done a practical check with a full testbed setup, but code-wise it 
should indeed be good now.

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

Title:
  [SRU] dnsmasq fails at leasing issues when using vlan mode

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Precise:
  Won't Fix

Bug description:
  ** Issue **

  There is an issue with the way nova uses dnsmasq in VLAN mode. It starts
  up a single copy of dnsmasq for each vlan on the network host (or on
  every host in multi_host mode). The problem is in the way that dnsmasq
  binds to an ip address and port[2]. Both copies can respond to broadcast
  packet, but unicast packets can only be answered by one of the copies.

  In nova this means that guests from only one project will get responses
  to their unicast dhcp renew requests. Unicast projects from guests in
  other projects get ignored. What happens next is different depending on
  the guest os. Linux generally will send a broadcast packet out after
  the unicast fails, and so the only effect is a small (tens of ms) hiccup
  while interface is reconfigured. It can be much worse than that,
  however. I have seen cases where Windows just gives up and ends up with
  a non-configured interface.

  This bug was first noticed by some users of openstack who rolled their
  own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket
  option, it will allow different daemons to share the port and respond to
  unicast packets, as long as they listen on different interfaces. I
  managed to communicate with Simon Kelley, the maintainer of dnsmasq and
  he has integrated a fix[3] for the issue in the current version[1] of
  dnsmaq.

  [3]
  

[Touch-packages] [Bug 1875708] Re: Truncated messages in journald since systemd v244

2021-10-13 Thread Christian Ehrhardt
** No longer affects: libvirt (Ubuntu 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/1875708

Title:
  Truncated messages in journald since systemd v244

Status in libvirt package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in libvirt source package in Groovy:
  Invalid
Status in systemd source package in Groovy:
  Fix Released

Bug description:
  [Impact]

   * since 09d0b46a "journal: refresh cached credentials of stdout streams"
 in ~244 output may be trincated.

   * Upstream has a fix in https://github.com/systemd/systemd/pull/15685

   * Backporting the fix will avoid truncation of log output to journald

  [Test Case]

   * This could happen in any case, but is more likely when a program that 
 has output going to journald is spawning short-lived sub-programs often.
 Therefore the test emphasizes on that:

 - Use a test service like /etc/systemd/system/test.service:
  [Unit]
  Description=Test Truncate
  After=network.target

  [Service]
  ExecStart=/usr/lib/test.sh long-test-for-start
  ExecStop=/usr/lib/test.sh long-test-for-stop
  Type=oneshot
  RemainAfterExit=yes
  StandardOutput=journal+console
  TimeoutStopSec=0

  [Install]
  WantedBy=multi-user.target

 - And a test script like /usr/lib/test.sh:
  #!/bin/sh
  gettext "This will"
  echo
  gettext "usually fail"
  echo
  gettext "and be truncated"
  echo 

  Start/Stopping that service without the fix will look like:
  Apr 30 18:56:40 f systemd[1]: Stopping Test Truncate...
  Apr 30 18:56:40 f test.sh[1165]: T
  Apr 30 18:56:40 f test.sh[1167]: T
  Apr 30 18:56:40 f test.sh[1167]: sually fai
  Apr 30 18:56:40 f test.sh[1165]: s
  Apr 30 18:56:40 f test.sh[1168]: s
  Apr 30 18:56:40 f test.sh[1168]: nd be truncate
  Apr 30 18:56:40 f test.sh[1165]: n
  Apr 30 18:56:40 f systemd[1]: test.service: Succeeded.
  Apr 30 18:56:40 f systemd[1]: Stopped Test Truncate.

  
  [Regression Potential] 

   * The patches are rather small, but there might be a slightly increased 
 memory consumption of journald for output buffers. 
   * Issues (if any and I couldn't find any so far) should be only to 
 journald output handling. Systemd is huge, this at least narrows
 down the potential places of a regression a lot.

  [Other Info]
   
   * n/a

  --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

  Originally reported against libvirt which happens to be one of the
  example-triggers

  Hi,

  when I shut down my machine I see messages from
  /usr/lib/libvirt/libvirt-guests.sh but there are 2 anomalies:

   - 3 libvirt-guests.sh processes are run
   - messages are truncated

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libvirt-daemon 6.0.0-0ubuntu8
  Uname: Linux 5.6.7-050607-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Tue Apr 28 19:42:56 2020
  SourcePackage: libvirt
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.libvirt.nwfilter.allow-arp.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-arp.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-dhcp-server.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp-server.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-dhcp.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-incoming-ipv4.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-ipv4.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-ipv4.xml']
  modified.conffile..etc.libvirt.nwfilter.clean-traffic-gateway.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic-gateway.xml']
  modified.conffile..etc.libvirt.nwfilter.clean-traffic.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/clean-traffic.xml']
  modified.conffile..etc.libvirt.nwfilter.no-arp-ip-spoofing.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml']
  modified.conffile..etc.libvirt.nwfilter.no-arp-mac-spoofing.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml']
  modified.conffile..etc.libvirt.nwfilter.no-arp-spoofing.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-spoofing.xml']
  modified.conffile..etc.libvirt.nwfilter.no-ip-multicast.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-ip-multicast.xml']
  modified.conffile..etc.libvirt.nwfilter.no-ip-spoofing.xml: [inaccessible: 
[Errno 13] 

[Touch-packages] [Bug 1662620] Re: "ip addr add" permits illegal labels

2021-10-08 Thread Christian Ehrhardt
Reviewed and tested - uploading to Bionic-unapproved for a check by the
SRU Team.

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

Title:
  "ip addr add" permits illegal labels

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Triaged

Bug description:
  [Impact]

   * The filter on label names does not match the intention
 by upstream nor the description in the man page

   * Fix by backporting upstream fix that strengthens the check

  [Test Plan]

  Bad case:
  root@b:~# ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).
  root@b:~# ip addr add 1.1.1.1 label eth0-test dev eth0
  root@b:~# ip addr show dev eth0 | grep test
  inet 1.1.1.1/32 scope global eth0-test

  With the fix it should look like:
  root@i:~# ip addr add 1.1.1.1 label test1 dev eth0
  "label" (test1) must match "dev" (eth0) or be prefixed by "dev" with a colon.
  root@i:~# ip addr add 1.1.1.1 label eth0-test dev eth0
  "label" (eth0-test) must match "dev" (eth0) or be prefixed by "dev" with a 
colon.
  root@i:~# ip addr show dev eth0 | grep test

  [Where problems could occur]

   * While the fix indeed "corrects" behavior I must say that if someone 
 relied on the non-intended behavior it would now break e.g. his 
 scripting or automation.

  [Other Info]
   
   * It was too easy to fix and too long dormant to ignore it further,
 but if the SRU team says this is too much regression risk relative to 
 the gain we will mark it Won't Fix based on that decision.

  
  ---

  ip-address(8) manpage states:

    label NAME
  Each address may be tagged with a label string.  In order to preserve 
compatibility with Linux-2.0 net aliases, this string must coincide with the 
name of the device or must be prefixed with the device name followed by colon.

  But you can omit the colon, "ip addr add" is ONLY checking the label
  is prefixed with the device:

  # ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).

  # ip addr add 1.1.1.2 label eth0-test2 dev eth0

  # ip addr add 1.1.1.3 label eth0:test3 dev eth0

  Now ifconfig becomes confused about eth0-test2:

  # ifconfig eth0-test2
  eth0-test2: error fetching interface information: Device not found

  # ifconfig eth0:test3
  eth0:test3 Link encap:Ethernet  HWaddr b0:d5:cc:fe:1d:7c
    inet addr:1.1.1.3  Bcast:0.0.0.0  Mask:255.255.255.255
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    Interrupt:171

  And daemons like ntpd also log errors about the interface with the
  illegal label:

  ntpd[7570]: eth0-test3: getting interface flags: No such device
    ## => many of this error per minute until:
  ntpd[7570]: Too many errors.  Shutting up.

  So, I think ip addr show disallow adding address with illegal (as
  stated by his own documentation) labels, it must also check for the
  colon following the dev name.

  Version: 4.3.0-1ubuntu3

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


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


[Touch-packages] [Bug 1662620] Re: "ip addr add" permits illegal labels

2021-10-07 Thread Christian Ehrhardt
Not sure if it will pass build, review or be acceptable as SRU since it is so 
low impact.
But the fix was so trivial that after all this time I'd feel bad to keep it 
as-is.

So I've prepared an MP to fix it
https://code.launchpad.net/~paelzer/ubuntu/+source/iproute2/+git/iproute2/+merge/409821

And a PPA with a test build
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4676/+packages


** Tags added: server-todo

** Changed in: iproute2 (Ubuntu Bionic)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Description changed:

+ [Impact]
+ 
+  * The filter on label names does not match the intention
+by upstream nor the description in the man page
+ 
+  * Fix by backporting upstream fix that strengthens the check
+ 
+ [Test Plan]
+ 
+ Bad case:
+ root@b:~# ip addr add 1.1.1.1 label test1 dev eth0
+ "dev" (eth0) must match "label" (test1).
+ root@b:~# ip addr add 1.1.1.1 label eth0-test dev eth0
+ root@b:~# ip addr show dev eth0 | grep test
+ inet 1.1.1.1/32 scope global eth0-test
+ 
+ With the fix it should look like:
+ root@i:~# ip addr add 1.1.1.1 label test1 dev eth0
+ "label" (test1) must match "dev" (eth0) or be prefixed by "dev" with a colon.
+ root@i:~# ip addr add 1.1.1.1 label eth0-test dev eth0
+ "label" (eth0-test) must match "dev" (eth0) or be prefixed by "dev" with a 
colon.
+ root@i:~# ip addr show dev eth0 | grep test
+ 
+ [Where problems could occur]
+ 
+  * While the fix indeed "corrects" behavior I must say that if someone 
+relied on the non-intended behavior it would now break e.g. his 
+scripting or automation.
+ 
+ [Other Info]
+  
+  * It was too easy to fix and too long dormant to ignore it further,
+but if the SRU team says this is too much regression risk relative to 
+the gain we will mark it Won't Fix based on that decision.
+ 
+ 
+ ---
+ 
  ip-address(8) manpage states:
  
-   label NAME
- Each address may be tagged with a label string.  In order to preserve 
compatibility with Linux-2.0 net aliases, this string must coincide with the 
name of the device or must be prefixed with the device name followed by colon.
+   label NAME
+ Each address may be tagged with a label string.  In order to preserve 
compatibility with Linux-2.0 net aliases, this string must coincide with the 
name of the device or must be prefixed with the device name followed by colon.
  
  But you can omit the colon, "ip addr add" is ONLY checking the label is
  prefixed with the device:
  
  # ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).
  
  # ip addr add 1.1.1.2 label eth0-test2 dev eth0
  
  # ip addr add 1.1.1.3 label eth0:test3 dev eth0
- 
  
  Now ifconfig becomes confused about eth0-test2:
  
  # ifconfig eth0-test2
  eth0-test2: error fetching interface information: Device not found
  
  # ifconfig eth0:test3
- eth0:test3 Link encap:Ethernet  HWaddr b0:d5:cc:fe:1d:7c  
-   inet addr:1.1.1.3  Bcast:0.0.0.0  Mask:255.255.255.255
-   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
-   Interrupt:171 
+ eth0:test3 Link encap:Ethernet  HWaddr b0:d5:cc:fe:1d:7c
+   inet addr:1.1.1.3  Bcast:0.0.0.0  Mask:255.255.255.255
+   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+   Interrupt:171
  
  And daemons like ntpd also log errors about the interface with the
  illegal label:
  
  ntpd[7570]: eth0-test3: getting interface flags: No such device
-   ## => many of this error per minute until:
+   ## => many of this error per minute until:
  ntpd[7570]: Too many errors.  Shutting up.
  
- 
- So, I think ip addr show disallow adding address with illegal (as stated by 
his own documentation) labels, it must also check for the colon following the 
dev name.
+ So, I think ip addr show disallow adding address with illegal (as stated
+ by his own documentation) labels, it must also check for the colon
+ following the dev name.
  
  Version: 4.3.0-1ubuntu3

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

Title:
  "ip addr add" permits illegal labels

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Triaged

Bug description:
  [Impact]

   * The filter on label names does not match the intention
 by upstream nor the description in the man page

   * Fix by backporting upstream fix that strengthens the check

  [Test Plan]

  Bad case:
  root@b:~# ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).
  root@b:~# ip addr add 1.1.1.1 label eth0-test dev eth0
  root@b:~# ip addr show dev eth0 | grep test
  inet 1.1.1.1/32 scope global eth0-test

  With the fix it should look like:
  root@i:~# ip a

[Touch-packages] [Bug 1662620] Re: "ip addr add" permits illegal labels

2021-10-07 Thread Christian Ehrhardt
SRU template added

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

Title:
  "ip addr add" permits illegal labels

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Triaged

Bug description:
  [Impact]

   * The filter on label names does not match the intention
 by upstream nor the description in the man page

   * Fix by backporting upstream fix that strengthens the check

  [Test Plan]

  Bad case:
  root@b:~# ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).
  root@b:~# ip addr add 1.1.1.1 label eth0-test dev eth0
  root@b:~# ip addr show dev eth0 | grep test
  inet 1.1.1.1/32 scope global eth0-test

  With the fix it should look like:
  root@i:~# ip addr add 1.1.1.1 label test1 dev eth0
  "label" (test1) must match "dev" (eth0) or be prefixed by "dev" with a colon.
  root@i:~# ip addr add 1.1.1.1 label eth0-test dev eth0
  "label" (eth0-test) must match "dev" (eth0) or be prefixed by "dev" with a 
colon.
  root@i:~# ip addr show dev eth0 | grep test

  [Where problems could occur]

   * While the fix indeed "corrects" behavior I must say that if someone 
 relied on the non-intended behavior it would now break e.g. his 
 scripting or automation.

  [Other Info]
   
   * It was too easy to fix and too long dormant to ignore it further,
 but if the SRU team says this is too much regression risk relative to 
 the gain we will mark it Won't Fix based on that decision.

  
  ---

  ip-address(8) manpage states:

    label NAME
  Each address may be tagged with a label string.  In order to preserve 
compatibility with Linux-2.0 net aliases, this string must coincide with the 
name of the device or must be prefixed with the device name followed by colon.

  But you can omit the colon, "ip addr add" is ONLY checking the label
  is prefixed with the device:

  # ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).

  # ip addr add 1.1.1.2 label eth0-test2 dev eth0

  # ip addr add 1.1.1.3 label eth0:test3 dev eth0

  Now ifconfig becomes confused about eth0-test2:

  # ifconfig eth0-test2
  eth0-test2: error fetching interface information: Device not found

  # ifconfig eth0:test3
  eth0:test3 Link encap:Ethernet  HWaddr b0:d5:cc:fe:1d:7c
    inet addr:1.1.1.3  Bcast:0.0.0.0  Mask:255.255.255.255
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    Interrupt:171

  And daemons like ntpd also log errors about the interface with the
  illegal label:

  ntpd[7570]: eth0-test3: getting interface flags: No such device
    ## => many of this error per minute until:
  ntpd[7570]: Too many errors.  Shutting up.

  So, I think ip addr show disallow adding address with illegal (as
  stated by his own documentation) labels, it must also check for the
  colon following the dev name.

  Version: 4.3.0-1ubuntu3

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


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


[Touch-packages] [Bug 1662620] Re: "ip addr add" permits illegal labels

2021-10-07 Thread Christian Ehrhardt
Hi,
I come by trying to clear out a few old bugs that might still need to be 
resolved (or can be closed by now).

Even though this one seems to be forgotten by everyone so far it has
been fixed.

Bionic (affected)
root@b:~# ip addr add 1.1.1.1 label test1 dev eth0
"dev" (eth0) must match "label" (test1).
root@b:~# ip addr add 1.1.1.1 label eth0-test dev eth0
root@b:~# ip addr show dev eth0 | grep test
inet 1.1.1.1/32 scope global eth0-test


Impish (fixed)
root@i:~# ip addr add 1.1.1.1 label test1 dev eth0
"label" (test1) must match "dev" (eth0) or be prefixed by "dev" with a colon.
root@i:~# ip addr add 1.1.1.1 label eth0-test dev eth0
"label" (eth0-test) must match "dev" (eth0) or be prefixed by "dev" with a 
colon.
root@i:~# ip addr show dev eth0 | grep test

This was effectively fixed by
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=cad73425d8813

Which is in since v4.18.0

That version is in >=20.04 as well as in 18.04-backports.

 iproute2 | 3.12.0-2  | trusty   | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el
 iproute2 | 3.12.0-2ubuntu1.2 | trusty-updates   | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el
 iproute2 | 4.3.0-1ubuntu3| xenial   | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el, s390x
 iproute2 | 4.3.0-1ubuntu3.16.04.5| xenial-updates   | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el, s390x
 iproute2 | 4.15.0-2ubuntu1   | bionic   | source, amd64, 
arm64, armhf, i386, ppc64el, s390x
 iproute2 | 4.15.0-2ubuntu1.1 | bionic-security  | source, amd64, 
arm64, armhf, i386, ppc64el, s390x
 iproute2 | 4.15.0-2ubuntu1.3 | bionic-updates   | source, amd64, 
arm64, armhf, i386, ppc64el, s390x
 iproute2 | 4.18.0-1ubuntu2~ubuntu18.04.1 | bionic-backports | source, amd64, 
arm64, armhf, i386, ppc64el, s390x
 iproute2 | 5.5.0-1ubuntu1| focal| source, amd64, 
arm64, armhf, i386, ppc64el, riscv64, s390x
 iproute2 | 5.10.0-4ubuntu1   | hirsute  | source, amd64, 
arm64, armhf, i386, ppc64el, riscv64, s390x
 iproute2 | 5.10.0-4ubuntu1   | impish   | source, amd64, 
arm64, armhf, i386, ppc64el, riscv64, s390x


Thereby the active release that still is affected is Bionic (unless you use 
bionic-backports which already have 4.18).

I think to fix this in bionic is only prio-low since it is mostly a cosmetic.
Since it is fixed in newer releases there isn't more work to be done to drive 
this to conclusion for future releases.

@Nahuel - I can only beg your pardon that this was dormant for so long
:-/

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

** Changed in: iproute2 (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: iproute2 (Ubuntu Bionic)
   Importance: Undecided => Low

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

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

Title:
  "ip addr add" permits illegal labels

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Triaged

Bug description:
  ip-address(8) manpage states:

label NAME
  Each address may be tagged with a label string.  In order to preserve 
compatibility with Linux-2.0 net aliases, this string must coincide with the 
name of the device or must be prefixed with the device name followed by colon.

  But you can omit the colon, "ip addr add" is ONLY checking the label
  is prefixed with the device:

  # ip addr add 1.1.1.1 label test1 dev eth0
  "dev" (eth0) must match "label" (test1).

  # ip addr add 1.1.1.2 label eth0-test2 dev eth0

  # ip addr add 1.1.1.3 label eth0:test3 dev eth0
  

  Now ifconfig becomes confused about eth0-test2:

  # ifconfig eth0-test2
  eth0-test2: error fetching interface information: Device not found

  # ifconfig eth0:test3
  eth0:test3 Link encap:Ethernet  HWaddr b0:d5:cc:fe:1d:7c  
inet addr:1.1.1.3  Bcast:0.0.0.0  Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
Interrupt:171 

  And daemons like ntpd also log errors about the interface with the
  illegal label:

  ntpd[7570]: eth0-test3: getting interface flags: No such device
## => many of this error per minute until:
  ntpd[7570]: Too many errors.  Shutting up.

  
  So, I think ip addr show disallow adding address with illegal (as stated by 
his own documentation) labels, it must also check for the colon following the 
dev name.

  Version: 4.3.0-1ubuntu3

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


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

[Touch-packages] [Bug 1505670] Re: "uncaptured python exception"

2021-10-05 Thread Christian Ehrhardt
@Miriam - please consider applying [1] to impish and later on the same for the 
SRUs.
Let me know if the test steps that I created based on all the discussions would 
not work for you.

This can then, down the road become a sync again once there is 0.8.16
released.

[1]: https://github.com/mvo5/squid-deb-
proxy/commit/604ba3f98beff25a8fd51783d3ffc4db5e987dab

** Changed in: squid-deb-proxy (Ubuntu)
 Assignee: (unassigned) => Miriam España Acebal (mirespace)

** Tags added: server-next

** Changed in: squid-deb-proxy (Ubuntu Bionic)
 Assignee: (unassigned) => Miriam España Acebal (mirespace)

** Changed in: squid-deb-proxy (Ubuntu Focal)
 Assignee: (unassigned) => Miriam España Acebal (mirespace)

** Also affects: python2.7 (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: squid-deb-proxy (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Changed in: squid-deb-proxy (Ubuntu Hirsute)
 Assignee: (unassigned) => Miriam España Acebal (mirespace)

** No longer affects: python2.7 (Ubuntu)

** No longer affects: python2.7 (Ubuntu Bionic)

** No longer affects: python2.7 (Ubuntu Focal)

** No longer affects: python2.7 (Ubuntu Hirsute)

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

Title:
  "uncaptured python exception"

Status in squid-deb-proxy package in Ubuntu:
  Confirmed
Status in squid-deb-proxy source package in Bionic:
  New
Status in squid-deb-proxy source package in Focal:
  New
Status in squid-deb-proxy source package in Hirsute:
  New

Bug description:
  Steps to reproduce (for later SRU work)

  #0
  # On the test Host install apt-cacher-ng
  # you need to do so before creating the guest to propagate
  # and configure correctly when spawned
  $ sudo apt install apt-cacher-ng

  #1
  # create a VM guest or container with at least three IPv4 adresses
  # In the example below I used 4 virtio net in KVM all with DHCP configured

  #2
  # install prereq packages
  $ sudo apt install avahi-utils squid-deb-proxy-client

  #3
  # check if all are interfaces are configured and avahi probes them all
  # (you might need to edit netplan or E/N/I to e.g. dhcp on all of them)
  $ avahi-browse -kprtf _apt_proxy._tcp
  +;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  
+;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
  +;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  +;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  
+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
  +;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  +;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
  +;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  +;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  
+;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
  +;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  +;lo;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
  
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
  
=;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
  
=;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
  
=;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
  
=;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
  
=;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe73:b27d;8000;
  
=;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
  
=;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe4e:2923;8000;
  
=;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.125;8000;
  
=;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.202;8000;
  
=;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.186;8000;
  
=;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.42;8000;
  

[Touch-packages] [Bug 1505670] Re: "uncaptured python exception"

2021-10-05 Thread Christian Ehrhardt
> Christian, thank you for stepping in. It seems you finally got the ball 
> rolling
> here where I was unsuccessful in a good half dozen attempts in #ubuntu-devel
> and other venues. That's the good news I suppose.

Np, glad to help - although this time as you said it was more "stepping
in" as I wanted to avoid things getting out of control between several
people that all only want to help to improve Ubuntu.

> I maintain my assessment of the situation of Ubuntu as stated in #16. I've 
> been
> with Ubuntu since breezy or so. I've been very active in bug triage, I know 
> the 
> processes. I'm happy to back up my rant with facts, if you want to hear.

TBH - You don't really have to provide other evidence, I've seen you triage and 
comment on many cases as I'm active myself. And I'm glad about your and other 
community members work!
Also I know that sometimes cases can be forgotten, ignored or punted too long 
for various reasons that are too manifold to be covered here.
My personal and my teams stance is to help to resolve those cases we come by 
and to help training (our and other) people if we see a structural issue.

> I also maintain that this bug ticket and the problem was clearly described 
> including a
> test case in #7 and a clear analysis of where the problem is IN THE CODE 
> right in #1.

I'm ok if you feel that way and do not want to convince you otherwise.
With so much delay you have all right to complain as long as neither of us gets 
personal (or other break other community guidelines).
As I said before, with my reply I wanted to show others POV and thereby explain 
why it might have been not as clear for others.

> You don't need more bug triage at that point. You need a dev to look at the 
> code and
> that did not happen, no matter the effort, here and elsewhere. I believe I 
> even tried
> to get the patch sponsored but nobody dared touching mvo's stuff without an 
> ACK.

As I said in my former post, yes the issue is valid, but not affecting
many users, not being in a main package and not yet was coming up to
someones attention having the extra bit of driving force to resolve it.
All those are aspects of how this happened.

I managed to get it resolved just by the luck of (like you) being very
active and thereby knowing some people to ask for favors :-) And
sometimes that is what you need to get a stuck ball rolling. I'm sure
there are other cases/contacts where you'd be more effective than I
would for the same reason :-)

> I'm not sure, but it seems that both you and Miriam mistakenly assume that 
> this bug can
> be triggered by some configuration on the computer where 
> squid-deb-proxy-CLIENT is
> installed. As stated in #7 "this problem occurs whenever there is more than 
> one
> host/IP discovered via avahi." in other words, a certain state of affairs 
> with regards
> to the LAN (plus VPNs) is needed.

On our "request for configuration" I have to beg your pardon for myself and
others. We are coming by so many bugs that our wording (just like your
descriptions in this case) might have been mis-understandable for the same
reasons (we have context in mind that the others do not know).
But without an intention of bikeshedding, that is still a "configuration" of 
some kind.

I didn't mean to imply "config file foo with entry bar in line X".
Any further detail how to recreate would have helped to clarify.
As always the detail matters, which is part of the reason that the
SRU process encourages literal steps to reproduce.

I've started my own draft (below) on steps how to trigger this based on our
discussions here.
But I think I have managed to fulfill "whenever there is more than one
host/IP discovered via avahi" and it still does not show the reported issue.
This might again be a case of "clear for you but not for everyone else".

#1
# create a VM guest or container with at least three IPv4 adresses
# In the example below I used 4 virtio net in KVM all with DHCP configured
#2
# install prereq packages
$ sudo apt install avahi-utils squid-deb-proxy-client
#3
# check if all are interfaces are configured and avahi probes them all
# (you might need to edit netplan or E/N/I to e.g. dhcp on all of them)
$ avahi-browse -kprtf _apt_proxy._tcp
+;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local

[Touch-packages] [Bug 1505670] Re: "uncaptured python exception"

2021-10-05 Thread Christian Ehrhardt
** Description changed:

+ Steps to reproduce (for later SRU work)
+ 
+ #0
+ # On the test Host install apt-cacher-ng
+ # you need to do so before creating the guest to propagate
+ # and configure correctly when spawned
+ $ sudo apt install apt-cacher-ng
+ 
+ #1
+ # create a VM guest or container with at least three IPv4 adresses
+ # In the example below I used 4 virtio net in KVM all with DHCP configured
+ 
+ #2
+ # install prereq packages
+ $ sudo apt install avahi-utils squid-deb-proxy-client
+ 
+ #3
+ # check if all are interfaces are configured and avahi probes them all
+ # (you might need to edit netplan or E/N/I to e.g. dhcp on all of them)
+ $ avahi-browse -kprtf _apt_proxy._tcp
+ +;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ 
+;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+ +;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ +;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ 
+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+ +;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ +;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ 
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+ +;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ +;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ 
+;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+ +;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ +;lo;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+ 
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
+ 
=;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
+ 
=;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
+ 
=;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
+ 
=;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
+ 
=;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe73:b27d;8000;
+ 
=;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
+ 
=;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe4e:2923;8000;
+ 
=;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.125;8000;
+ 
=;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.202;8000;
+ 
=;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.186;8000;
+ 
=;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.42;8000;
+ 
=;lo;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;127.0.0.1;8000;
+ 
+ #5
+ # After being announced stop the cacher on the host
+ $ sudo systemctl stop apt-cacher-ng.service
+ 
+ #6
+ Check it is now dead from the guests POV
+ $ curl 192.168.122.1:3142
+ curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused
+ 
+ #7
+ # Ensure that it is still announced in avahi in the guest
+ $ avahi-browse -kprtf _apt_proxy._tcp | grep '^=' | cut -d";" -f 4,8-9 | grep 
-v '::'
+ ...
+ apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
+ 
+ #8
+ # Now run apt-avahi-discover which shows the python errors
+ # bleeding into the output even with stderr redirected
+ $ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null 
+ error: uncaptured python exception, closing channel  
('192.168.122.1', 3142): 9223372036854775807 (:[Errno 111] Connection refused 
[/usr/lib/python3.9/asyncore.py|read|83] 
[/usr/lib/python3.9/asyncore.py|handle_read_event|417] 
[/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
+ error: uncaptured python exception, closing channel  
('192.168.122.1', 3142): 9223372036854775807 (:[Errno 111] Connection refused 
[/usr/lib/python3.9/asyncore.py|read|83] 
[/usr/lib/python3.9/asyncore.py|handle_read_event|417] 
[/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
+ error: uncaptured python exception, closing channel  
('192.168.122.1', 3142): 9223372036854775807 (:[Errno 111] Connection refused 
[/usr/lib/python3.9/asyncore.py|read|83] 
[/usr/lib/python3.9/asyncore.py|handle_read_event|417] 
[/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
+ error: uncaptured python exception, closing channel  

[Touch-packages] [Bug 1794997] Re: virNetlinkEventCallback:700 : nl_recv returned with error: No buffer space available

2021-09-30 Thread Christian Ehrhardt
I've dupped another case onto this, it stays an issue that from the libvirt 
side has been handled by
https://gitlab.com/libvirt/libvirt/-/commit/8c70d04bab7278c96390a913fa949a17cd3124f9
 which is in >=Bionic.

AFAIU remaining issues as outlined in comment #2 are still considered
more an libnl/driver than a libvirt issue.

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

Title:
  virNetlinkEventCallback:700 : nl_recv returned with error: No buffer
  space available

Status in libnl3 package in Ubuntu:
  Expired
Status in libvirt package in Ubuntu:
  Expired

Bug description:
  We are observing the following error while creating VMs

  Sep 27 14:25:47 xpl-dvt-41 libvirtd[4927]: 2018-09-27
  21:25:47.387+: 4927: error : virNetlinkEventCallback:700 : nl_recv
  returned with error: No buffer space available

  This message is observed with latest Bionic libvirt packages.

  lab@xpl-dvt-35:~$ dpkg -l | grep libvirt
  ii  gir1.2-libvirt-glib-1.0:amd64 1.0.0-1 
amd64GObject introspection files for the libvirt-glib library
  ii  libsys-virt-perl  4.0.0-1 
amd64Perl module providing an extension for the libvirt library
  ii  libvirt-bin   4.0.0-1ubuntu8.5
amd64programs for the libvirt library
  ii  libvirt-clients   4.0.0-1ubuntu8.5
amd64Programs for the libvirt library
  ii  libvirt-daemon4.0.0-1ubuntu8.5
amd64Virtualization daemon
  ii  libvirt-daemon-system 4.0.0-1ubuntu8.5
amd64Libvirt daemon configuration files
  ii  libvirt-glib-1.0-0:amd64  1.0.0-1 
amd64libvirt GLib and GObject mapping library
  ii  libvirt0:amd644.0.0-1ubuntu8.5
amd64library for interfacing with different virtualization systems
  ii  python-libvirt4.0.0-1 
amd64libvirt Python bindings

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


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


[Touch-packages] [Bug 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2021-09-30 Thread Christian Ehrhardt
** Tags added: server-todo

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  New
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1505670] Re: "uncaptured python exception"

2021-09-30 Thread Christian Ehrhardt
Hi Rolf,
let me try to calm things down a bit via clarifications on the
technical and ubuntu-process side of this.


> I'm not sure I understand what you did and what your results were. It
> appears that you got the issue of an "uncaptured python exception" at
> least once "when you removed squid-deb-proxy"? I really don't know what
> you mean there. Then you list the output of /usr/share/squid-deb-proxy-
> client/apt-avahi-discover twice, unchanged, but apparently get an IPv4
> result once and an IPv6 result on the next, identical invocation.


The bug initially just describes to run apt-avahi-discover and it would fail.
That is exactly what everyone retrying it here did AFAICS.
But that does not fail that way.

The later insight posted on the bug that "more than one host/IP
discovered via avahi" are required isn't enough either. The setup those
people used has Ipv4+ipv6 = 2 IPs in avahi but still work fine.

And yes - as you quoted on Miriams example - under that condition it is
reporting one of the potential IPv4/IPv6 proxy addresses in a random
fashion and that might be another bug. But not a problem here.

It seems @Miriam then still didn't give up on your case, but went
further trying to provoke a similar exception by removing some of the
python sources and wondered if that could be similar to the reported
issue. It isn't similar nor helpful in hindsight - but I appreciate that
she did insist on trying to help you by evaluating other options.


> The problem with squid-deb-proxy is easy to trigger. All it needs is two
> or more responses to the avahi discovery in your LAN. See the initial
> report where it shows three different IP numbers. These days, I believe an
> IPv4 and IPv6 response from the same server is actually enough.


I've re-read it all again, but the bug description (= the initial report) does 
not tell that in any way.  "Three" as in your last post definitely isn't 
mentioned anywhere before and as I outlined before "multiple" was mentioned but 
IPv4+IPv6 = 2 and that does not trigger it.

Comment #1 then re-analyzed the same issue providing an initial fix which is 
great, but still has no further details how to reproduce this. Up to comment #4 
it is about revising the patch, you then kindly tested the patch #5 and called 
for consideration #6.
So far all was great, and then I agree the lack of a reaction then is what 
makes this a bad case.

Then in comment #7 you clarified that to trigger it one will need "more
than one host/IP discovered via avahi." But the test setup that Andreas
(comment #8) and Miriam (comment #14) was a common LXD setup which has
multiple IPs which also causes the alternating ipv4/ipv6 responses.

For example here from a similar setup to the one they used:

$ avahi-browse -kprtf _apt_proxy._tcp
+;eth0;IPv6;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;eth0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
=;eth0;IPv6;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;fd42:fa18:c923:35d5::1;3142;
=;eth0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;10.253.194.1;3142;

So it might strictly need multiple-hosts with multiple-ipv4 adresses then?
Or is it three (as you say above)?
Or "three or more?"
If so is it "three or more IPv4?" or does IPv47IPv6 not matter?
Can those IPs be on the same host, or does it have to be different systems?
...
You do know at least from your example, but we or anyone else just reading the 
case does not.

And as far as I read comment #14 Miriam is mostly asking for "I don't
see your issue here can you help me to see why". The proper answer would
IMHO be elaborating out how to setup the surrounding environment so that
avahi-browse will return a set of hosts/IPs that will make it break
avahi.


BTW no one ever adapted the bug description summarizing any of the new insights 
- I did this now to help anyone looking at it later on. There are a few open 
questions there which you might be able to fill in @Rolf.


> Frankly, we don't need more bug triage here, it's all been laid out
> forever, we've had a working patch for years. The patch is as far as I can
> tell correct in that it is not simply a workaround. I assume you haven't
> looked at the code.


That might be another misunderstanding - again let me try to help to clarify.
This isn't so much about triaging, but about finding a way to reliable steps to 
recreate it.
They want to help you and anyone else affected, but to apply the patch to 
anything else but future Ubuntu releases it will have to go through the SRU 
process [1] and that rather strictly dictates reproducibility for a test along 
the publishing & verification. So without very special conditions the lack of a 
clear test/repro can be almost as inhibiting as the lack of a fix in
the first place.


> Truth be told, the state of this bug is disgusting and demotivating.
> Ubuntu used to be about making 

[Touch-packages] [Bug 1505670] Re: "uncaptured python exception"

2021-09-30 Thread Christian Ehrhardt
** Description changed:

  I get the following error when running the discovery script on the
  command line.
  
  $ /usr/share/squid-deb-proxy-client/apt-avahi-discover
  error: uncaptured python exception, closing channel  
('10.1.2.3', 3142): 2147483647 (:[Errno 111] Connection 
refused [/usr/lib/python2.7/asyncore.py|read|83] 
[/usr/lib/python2.7/asyncore.py|handle_read_event|446] 
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
  error: uncaptured python exception, closing channel  
('10.0.3.1', 3142): 2147483647 (:[Errno 111] Connection 
refused [/usr/lib/python2.7/asyncore.py|read|83] 
[/usr/lib/python2.7/asyncore.py|handle_read_event|446] 
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
  error: uncaptured python exception, closing channel  
('172.24.74.129', 3142): 2147483647 (:[Errno 111] 
Connection refused [/usr/lib/python2.7/asyncore.py|read|83] 
[/usr/lib/python2.7/asyncore.py|handle_read_event|446] 
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
  http://172.24.74.145:3142/
  
  The last line still returns the proper proxy URI so as far as I can tell
  things are still working.  The IP 10.1.2.3 is for an n2n VPN.  This is
  on trusty with version 0.8.6ubuntu1.
+ 
+ To trigger the bug the environment setup needs to be in a specific way.
+ It seems for the problem to occur it need more than one host/IP discovered 
via avahi. This can be probed via $ avahi-browse -kprtf _apt_proxy._tcp
+ and e.g. the common LXD setup of IPv4 + ipv6 is NOT enough to trigger it.
+ 
+ TODO: a sample output of the above command in an affected environment
+ could be helpful.
+ 
+ TODO: if possible outlining how the environment can be configured to
+ have this multi host/IP reply in avahi would be helpful as well.

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

Title:
  "uncaptured python exception"

Status in python2.7 package in Ubuntu:
  New
Status in squid-deb-proxy package in Ubuntu:
  Confirmed
Status in python2.7 source package in Bionic:
  New
Status in squid-deb-proxy source package in Bionic:
  New
Status in python2.7 source package in Focal:
  New
Status in squid-deb-proxy source package in Focal:
  New

Bug description:
  I get the following error when running the discovery script on the
  command line.

  $ /usr/share/squid-deb-proxy-client/apt-avahi-discover
  error: uncaptured python exception, closing channel  
('10.1.2.3', 3142): 2147483647 (:[Errno 111] Connection 
refused [/usr/lib/python2.7/asyncore.py|read|83] 
[/usr/lib/python2.7/asyncore.py|handle_read_event|446] 
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
  error: uncaptured python exception, closing channel  
('10.0.3.1', 3142): 2147483647 (:[Errno 111] Connection 
refused [/usr/lib/python2.7/asyncore.py|read|83] 
[/usr/lib/python2.7/asyncore.py|handle_read_event|446] 
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
  error: uncaptured python exception, closing channel  
('172.24.74.129', 3142): 2147483647 (:[Errno 111] 
Connection refused [/usr/lib/python2.7/asyncore.py|read|83] 
[/usr/lib/python2.7/asyncore.py|handle_read_event|446] 
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
  http://172.24.74.145:3142/

  The last line still returns the proper proxy URI so as far as I can
  tell things are still working.  The IP 10.1.2.3 is for an n2n VPN.
  This is on trusty with version 0.8.6ubuntu1.

  To trigger the bug the environment setup needs to be in a specific way.
  It seems for the problem to occur it need more than one host/IP discovered 
via avahi. This can be probed via $ avahi-browse -kprtf _apt_proxy._tcp
  and e.g. the common LXD setup of IPv4 + ipv6 is NOT enough to trigger it.

  TODO: a sample output of the above command in an affected environment
  could be helpful.

  TODO: if possible outlining how the environment can be configured to
  have this multi host/IP reply in avahi would be helpful as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1505670/+subscriptions


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


[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-29 Thread Christian Ehrhardt
Martin, I almost expected that would be the call but wanted to leave it to you 
to decide.
Thank you as always!
o/

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  In Progress
Status in umockdev package in Ubuntu:
  Invalid
Status in umockdev package in Debian:
  Unknown

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 17082)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 17083)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = -1
  (gdb) n
  186   g_warning ("could not create %s", bus);
  (gdb) n

  ** (/usr/libexec/installed-tests/bolt/test-power:17078): WARNING **:
  15:11:06.614: could not create /tmp/umockdev.TK2VA1/sys/bus

  Thread 1 "test-power" received signal SIGTRAP, Trace/breakpoint trap.

  
  I'll tag this 

[Touch-packages] [Bug 1945205] Re: [FFe] Add zstd support

2021-09-29 Thread Christian Ehrhardt
Held back in proposed migration:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/a/autopkgtest/20210929_062309_c71f0@/log.gz

That test fail can't be reproduced in local autopkgtest (LXD init is
different in the autopkgtest infra compared to a "normal" cloudimage)
nor does it seem to be triggered by this upload.

Most likely a regression-in-release due to image/lxd changes but one
will have to do the homework to verify and then fix or test-hint this.

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

Title:
   [FFe] Add zstd support

Status in python-debian package in Ubuntu:
  Confirmed

Bug description:
  [Feature Freeze Exception]

  Now that dpkg-deb defaults to compressing with zstd, python-debian can
  no longer decompress the compressed data into the binary package
  archive [1].

  The proposed change, created as an MP at [2], introduces zstd support
  to python-debian 0.1.39 by adding a dependency to zstd to the package
  and by extending the python-debian xz support for python < 3.3, where
  xz was still not supported by tarfile, to also support the zstd
  compression.

  It is also important to note that, for python-debian 0.1.40, the
  relevant (here patched) code was re-worked (python < 3.3 support was
  dropped) and this proposed patch, along with the relevant proposed
  unit test, will need to be re-written. This re-writing effort is
  already an ongoing work proposed upstream in [3].

  Once [3] is merged, this patch can be dropped and python-debian can be
  sync'd from upstream again. If there is a need to merge python-debian
  before [3] is accepted and released upstream, the next version of
  python-debian will need to drop the proposed patch and apply [3]
  instead, for the reasons listed above.

  While python-debian is not completely broken without this FFe patch,
  some of its features will not work properly on Ubuntu packages now
  they are compressed with zstd. For instance, any packages or scripts
  that try to use python-debian for extracting data from deb packages
  will no longer work. Namely, dh-cmake FTBFS when trying to decompress
  a deb package during its unit test run step [4].

  A PPA with the proposed fix is available at [5], along with the build
  logs.

  I ran the dep8 test suite locally with the following results:

autopkgtest [20:04:02]:  summary
python3-debian PASS

  I am also attaching the logs for installation, removal and upgrades of
  the patched package.

  [1] https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/1923845
  [2] 
https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/python-debian/+git/python-debian/+merge/407413
  [3] 
https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/65
  [4] 
https://launchpadlibrarian.net/552708462/buildlog_ubuntu-impish-amd64.dh-cmake_0.6.1_BUILDING.txt.gz
  [5] 
https://launchpad.net/~athos-ribeiro/+archive/ubuntu/lp-1923845-python-debian/+packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/1945205/+subscriptions


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


[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-28 Thread Christian Ehrhardt
Since Debian is also affected I filed it there as well:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995248

** Bug watch added: Debian Bug tracker #995248
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995248

** Also affects: umockdev (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995248
   Importance: Unknown
   Status: Unknown

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  Invalid
Status in umockdev package in Ubuntu:
  In Progress
Status in umockdev package in Debian:
  Unknown

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 17082)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 17083)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = -1
  (gdb) n
  186   g_warning ("could not create %s", 

[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-28 Thread Christian Ehrhardt
** Changed in: bolt (Ubuntu)
   Status: In Progress => Invalid

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  Invalid
Status in umockdev package in Ubuntu:
  In Progress

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 17082)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 17083)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = -1
  (gdb) n
  186   g_warning ("could not create %s", bus);
  (gdb) n

  ** (/usr/libexec/installed-tests/bolt/test-power:17078): WARNING **:
  15:11:06.614: could not create /tmp/umockdev.TK2VA1/sys/bus

  Thread 1 "test-power" received signal SIGTRAP, Trace/breakpoint trap.

  
  I'll tag this update-excuse and FYI-subscribe Martin who has done the Debian 
upload and the Ubuntu sync of this on 

[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

2021-09-28 Thread Christian Ehrhardt
Looking at the changelog this looks suspicious:
  - Immediately create "bus" and "class" directories in /sys to fix udev   
enumerator (thanks David Lechner)

That change is at
  
https://github.com/martinpitt/umockdev/commit/5e829601434610ef510bda12571291509a3a51d2

And that explains it, the bolt test code wants to create
/tmp/umockdev.RQBNA1/sys/bus and it already exists.

Offending code in bolt tests is at:
https://gitlab.freedesktop.org/bolt/bolt/-/blob/master/tests/mock-sysfs.c#L183

Checking that theory in the debugger confirms that - breaking just prior
to the failing mkdir.

Good-case
183   r = g_mkdir (bus, 0744);
(gdb) p bus
$4 = 0x555be330 "/tmp/umockdev.P7PGA1/sys/bus"
(gdb) shell find /tmp/umockdev.P7PGA1/
/tmp/umockdev.P7PGA1/
/tmp/umockdev.P7PGA1/sys
/tmp/umockdev.P7PGA1/ioctl
/tmp/umockdev.P7PGA1/ioctl/_default

Bad-case
183   r = g_mkdir (bus, 0744);
(gdb) p bus
$4 = 0x555be560 "/tmp/umockdev.7MRGA1/sys/bus"
gdb) shell find /tmp/umockdev.7MRGA1/
/tmp/umockdev.7MRGA1/
/tmp/umockdev.7MRGA1/sys
/tmp/umockdev.7MRGA1/sys/bus
/tmp/umockdev.7MRGA1/sys/class
/tmp/umockdev.7MRGA1/ioctl
/tmp/umockdev.7MRGA1/ioctl/_default

So we either need to stop umockdev from doing that (but that will break
whatever it fixed to introduce this) OR we need to teach bolt tests to
be ok, if the directory already exists.

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

Title:
  umockdev 0.16.3-1 breaks autopkgtest of bolt

Status in bolt package in Ubuntu:
  Invalid
Status in umockdev package in Ubuntu:
  In Progress

Bug description:
  The test of bolt fails with the new version due to a crash:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz

  ...
Trace/breakpoint trap (core dumped)

  The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
  python3-dbusmock and the new version causes this.

  Retrying autopkgtest locally with no, all and just umockdev from proposed
  and it seems reproducible.
   - impish-release - works
   - impish-all-proposed - crashes
   - impish-release + umockdev+libc6 from proposed - crashes

  Repro:
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power

  FYI:
  Downgrading to umockdev 0.16.2-1 in the same environment does not
  eliminate the issue. So it might happen at the bolt test-build time.

  Debian has the same issue in:
  https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz

  The new mockdev fails to create /sys/bus which is requested by the test.
  From there the error path is what crashes, but the root cause is why we enter
  the error-path in the first place.

  One should be aware, this fail is "normal" if the environment is not mocked.
  Even in the good case the different calls with/without umockdev lead to
  exactly the same crash.
  # good
  $ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
  # same crash as the new version has with umockdev-wrapper
  $ gdb /usr/libexec/installed-tests/bolt/test-power

  This is based on ldpreload.
  $ cat /usr/bin/umockdev-wrapper
  #!/bin/sh
  # Wrapper program to preload the libumockdev library, so that test programs 
can
  # set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
  exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"

  Gut feeling: it seems the mocking no more happens, and due to that
  it runs into the non-mocked crash

  Debugging with that:
  $ pull-lp-source bolt
  $ cd bolt-0.9.1/tests
  $ gdb /usr/libexec/installed-tests/bolt/test-power
  (gdb) set environment LD_PRELOAD libumockdev-preload.so.0
  (gdb) b mock_sysfs_init
  (gdb) run

  With that we can see that while the crash is somewhere inside g_warning the
  reason is in the g_mkdir failing with the new umockdev.

  
  Good-case

  Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
  165   {
  (gdb) n
  171 ms->bed = umockdev_testbed_new ();
  (gdb) 
  [New Thread 0x76e65640 (LWP 11444)]
  # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
after threads are created
  # DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
  172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
  (gdb) 
  [New Thread 0x76664640 (LWP 11445)]
  175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
  (gdb) 
  180 sys = umockdev_testbed_get_sys_dir (ms->bed);
  (gdb) 
  182 bus = g_build_filename (sys, "bus", NULL);
  (gdb) p sys
  $1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
  (gdb) n
  183 r = g_mkdir (bus, 0744);
  (gdb) p bus
  $2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
  (gdb) n
  185 if (r < 0)
  (gdb) p r
  $3 = 0
  (gdb) n
  188 cls = g_build_filename (sys, "class", NULL);

  Bad-Case

  Breakpoint 1, mock_sysfs_init 

  1   2   3   4   5   6   7   8   9   10   >