[Touch-packages] [Bug 1978816] Re: sshd: ClientAliveCountMax=0 not honoured as expected

2022-06-16 Thread Paride Legovini
Hello James and thanks for your bug report. The "Make
ClientAliveCountMax=0 have sensible semantics" change you refer to is
actually an upstream change, see the OpenSSH bugfixes here:

  https://www.openssh.com/releasenotes.html

the upstream bug being:

  https://bugzilla.mindrot.org/show_bug.cgi?id=2627

which has a comment similar to yours here.

Even if the new behavior may be sometimes inconvenient I don't think
we're going to make Ubuntu deviate from what upstream does (for reasons
you clearly understand). As an Ubuntu bug I think this is Invalid, but
I'm marking it as Incomplete for now. Please comment back if there's
anything I missed or misunderstood, or mark this report as Invalid if
you agree with my findings. Thanks!

** Bug watch added: OpenSSH Portable Bugzilla #2627
   https://bugzilla.mindrot.org/show_bug.cgi?id=2627

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

Title:
  sshd: ClientAliveCountMax=0 not honoured as expected

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  $ apt-cache policy openssh-server
  openssh-server:
Installed: 1:8.2p1-4ubuntu0.4
Candidate: 1:8.2p1-4ubuntu0.4

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.4 LTS
  Release:20.04
  Codename:   focal

  After upgrading from 'bionic' the openssh ClientAlive* parameters are
  not functioning as expected in sshd:

  /etc/ssh/sshd_config:ClientAliveInterval 900
  /etc/ssh/sshd_config:ClientAliveCountMax 0

  The expected behaviour is that after 900s with no traffic in the
  session the server terminates the connection.  There appears to be a
  custom patch in the package which changes this:

  - sshd(8): Make ClientAliveCountMax=0 have sensible semantics: it will
now disable connection killing entirely rather than the current
behaviour of instantly killing the connection after the first liveness
test regardless of success.

  It is unclear why this is a beneficial change in the default behaviour
  of sshd.  If the user doesn't want the session disconnected then they
  should set ClientAliveInterval=0.  It also defeats our requirement to
  have idle ssh sessions terminated when nothing has been done for 15
  minutes.

  It is tempting to mark this as a security issue due to unexpected
  change in behaviour and the fact it would leave idle sessions open
  whereas a vanilla ssh package would close them.

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


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


[Touch-packages] [Bug 1923845] Re: Please compress packages with zstd by default

2022-06-06 Thread Paride Legovini
aptly is Fix Release in Kinetic in:

aptly (1.4.0+ds1-7) unstable; urgency=medium

  * Team upload.
  * Add support for zstd compression (Closes: #1010465)


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

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

Title:
  Please compress packages with zstd by default

Status in appstream-glib package in Ubuntu:
  New
Status in apt package in Ubuntu:
  Fix Released
Status in aptly package in Ubuntu:
  Fix Released
Status in boinc package in Ubuntu:
  New
Status in busybox package in Ubuntu:
  New
Status in cdebootstrap package in Ubuntu:
  New
Status in cdist package in Ubuntu:
  New
Status in debdelta package in Ubuntu:
  New
Status in debian-el package in Ubuntu:
  New
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debsig-verify package in Ubuntu:
  New
Status in debsigs package in Ubuntu:
  New
Status in diffoscope package in Ubuntu:
  Fix Released
Status in dpkg package in Ubuntu:
  Fix Released
Status in dpkg-sig package in Ubuntu:
  New
Status in file package in Ubuntu:
  New
Status in hello package in Ubuntu:
  Fix Released
Status in libsolv package in Ubuntu:
  New
Status in lintian package in Ubuntu:
  Fix Released
Status in lutris package in Ubuntu:
  Invalid
Status in obs-build package in Ubuntu:
  New
Status in osc package in Ubuntu:
  New
Status in python-debian package in Ubuntu:
  Fix Released
Status in radare2 package in Ubuntu:
  New
Status in reprepro package in Ubuntu:
  Fix Released
Status in vim-scripts package in Ubuntu:
  New
Status in zeroinstall-injector package in Ubuntu:
  New
Status in reprepro source package in Focal:
  Fix Released
Status in reprepro source package in Groovy:
  Fix Released
Status in reprepro source package in Hirsute:
  Fix Released
Status in debian-el package in Debian:
  New

Bug description:
  https://people.canonical.com/~rbalint/zstd-debs/ contains a .deb built
  on Hirsute having both data and control members of the .deb being
  compressed with zstd. It can be handy for testing various tools.

  [dpkg]
  Decompression support in dpkg landed first in Bionic and is being SRUd to 
Xenial in LP: #1764220 enable Launchpad's Xenial systems to process the 
zstd-compressed binary packages.
  From dpkg's perspective the upgrade path is cleared.

  The original plan was compressing only the internal data.tar .deb
  member, but dpkg uses uniform compression by default since dpkg 1.19.0
  thus I'm collecting all the changes to support control.tar.zst, too,
  in this bug.

  Reviewed packages from:
  https://codesearch.debian.net/search?q=data.tar.xz=1=1
  https://codesearch.debian.net/search?q=control.tar.xz=1=1

  appstream-glib  - needs fix: libappstream-builder/asb-package-deb.c
  aptly   - needs fix: deb/deb.go
  boinc   - needs fix: debian/fetch_example_applications.sh
  busybox - needs fix: archival/dpkg_deb.c archival/dpkg.c
  cdebootstrap- needs fix: src/package.c
  cdist   - may need fix, can use dpkg-deb: 
cdist/preos/debootstrap/files/devuan-debootstrap/functions
  debdelta- needs fix: debdelta debpatch.sh
  debian-el   - needs fix: deb-view.el
  debian-handbook - needs fix, maybe later, for Debian
  debootstrap - needs fix, 
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/54
  debsigs - needs fix, debsigs
  debsig-verify   - needs fix, src/debsig-verify.c
  diffoscope  - needs fix, diffoscope/comparators/deb.py
  dpkg- needs fix, change default
  dpkg-sig- needs fix, dpkg-sig
  dpmb- needs fix, maybe later, for Debian
  elfutils- may need fix, uses dpkg-deb if it is available, does not 
handle .gz either
  file- needs fix, magic/Magdir/archive
  libsolv - needs fix, ext/repo_deb.c
  lintian - needs fix malformed-deb-archive
  lutris  - needs fix, lutris/util/extract.py
  obs-build   - needs fix Build/Deb.pm
  osc - needs fix osc/util/debquery.py control.tar.zst only
  python-apt  - needs fix 
apt_inst.DebFile("glibc-doc-reference_2.33-0ubuntu2~zstd1_all.deb").control.extractall()
  radare2 - needs fix
  reprepro- needs fix, debfile.c
  vim-scripts - needs fix debPlugin/autoload/deb.vim
  winetricks  - needs fix when Debian switches src/winetricks
  zeroinstall-injector - needs fix src/zeroinstall/archive.ml

  acr - skip, does not _have to_ be fixed, just creates packages, 
see dist/deb_hand.mak
  alien   - skip, uses dpkg-deb to extract .deb
  ansible - not affected, just test data in dbdata.tar.xz
  anthy   - not affected, just changelog entry
  apt - seems fixed already
  ceph- not affected in Ubuntu's version
  circlator   - not affected, just test data
  cowdancer   - not 

[Touch-packages] [Bug 1971932] Re: error in rsync protocol data stream

2022-05-12 Thread Paride Legovini
Well, "large" can span orders of magnitude, depending who you ask. :-)

Can you please try to identify some steps to reproduce that include the
big file generation? For example:

  # 100MB file, random data (difficult to compress)
  head -c 100M /dev/urandom > foo

  # 100MB file, all 0s (easy to compress)
  head -c 100M /dev/zero > foo

Then you can try to rsync it to localhost via ssh to a different
directory (I assume you're using ssh and not the rsync protocol).
Thanks!

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

Title:
  error in rsync protocol data stream

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  When synchronizing to other systems, rsync exits with "error in rsync
  protocol data stream (code 12)".

  The problem occurs since ubuntu 22.04 LTS with two different
  destination systems not running ubuntu but plain debian. The error did
  not occur under 20.04 LTS.

  Synchronisation runs fine for most other files, but always stops at
  the same (relative large) file. The file itself has also been changed
  on a test basis to make sure the file is not the problem itself.

  Log snippet:
  

  ...
  chunk[46131] len=46120 offset=2127561720 sum1=2f48caf4
  chunk[46132] len=46120 offset=2127607840 sum1=5dfcb4ee
  chunk[46133] len=46120 offset=2127653960 sum1=d1037d81
  chunk[46134] len=8870 offset=2127700080 sum1=6deedc97
  send_files mapped 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX of size 
2135722584
  calling match_sums 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX
  built hash table
  hash search b=46120 len=2135722584
  sum=1e1722dc k=46120
  hash search s->blength=46120 len=2135722584 count=46135
  potential match at 0 i=0 sum=1e1722dc
  match at 0 last_match=0 j=0 len=46120 n=0
  potential match at 46120 i=1 sum=c482d6b6
  match at 46120 last_match=46120 j=1 len=46120 n=0
  potential match at 92240 i=2 sum=b21c7e11
  match at 92240 last_match=92240 j=2 len=46120 n=0
  potential match at 138360 i=3 sum=d066473a
  match at 138360 last_match=138360 j=3 len=46120 n=0
  potential match at 184480 i=4 sum=a32a2984
  match at 184480 last_match=184480 j=4 len=46120 n=0
  potential match at 230600 i=5 sum=39cc049f
  match at 230600 last_match=230600 j=5 len=46120 n=0
  potential match at 276720 i=6 sum=ad3de98a
  match at 276720 last_match=276720 j=6 len=46120 n=0
  potential match at 322840 i=7 sum=83e16fa9
  match at 322840 last_match=322840 j=7 len=46120 n=0
  deflate on token returned 0 (8512 bytes left)
  rsync error: error in rsync protocol data stream (code 12) at token.c(476) 
[sender=3.2.3]
  [sender] _exit_cleanup(code=12, file=token.c, line=476): entered
  [sender] _exit_cleanup(code=12, file=token.c, line=476): about to call 
exit(12)

  Sender system: (rsync 3.2.3-8ubuntu3)
  -

  rsync  version 3.2.3  protocol version 31
  Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
  Web site: https://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes,
  batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv,
  symtimes, prealloc, stop-at, no crtimes
  Optimizations:
  SIMD, no asm, openssl-crypto
  Checksum list:
  xxh128 xxh3 xxh64 (xxhash) md5 md4 none
  Compress list:
  zstd lz4 zlibx zlib none

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

  Recipient systems: (rsync 3.1.3-6)
  --

  rsync  version 3.1.3  protocol version 31
  Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
  Web site: http://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
  append, ACLs, xattrs, iconv, symtimes, prealloc

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

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


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


[Touch-packages] [Bug 1966886] Re: ssh-copy-id and Dropbear Server

2022-05-09 Thread Paride Legovini
** Tags added: server-todo

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

Title:
  ssh-copy-id and Dropbear Server

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  on Dropbear SSH Servers ssh-copy-id installs the key in
  /etc/dropbear/authorized_keys

  only the openwrt dropbear server uses that path
  
https://github.com/openwrt/openwrt/blob/2211ee0037764e1c6b1576fe7a0975722cd4acdc/package/network/services/dropbear/patches/100-pubkey_path.patch

  the upstream dropbear server uses the normal path
  ~/.ssh/authorized_keys

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


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


[Touch-packages] [Bug 1966886] Re: ssh-copy-id and Dropbear Server

2022-05-09 Thread Paride Legovini
I found a (somehow stale) upstream PR that addresses this:

  https://github.com/openssh/openssh-portable/pull/250

We could include this as an Ubuntu patch, but it would be better to
first see it merged upstream. It may be worth pinging there.

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

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

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

Title:
  ssh-copy-id and Dropbear Server

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  on Dropbear SSH Servers ssh-copy-id installs the key in
  /etc/dropbear/authorized_keys

  only the openwrt dropbear server uses that path
  
https://github.com/openwrt/openwrt/blob/2211ee0037764e1c6b1576fe7a0975722cd4acdc/package/network/services/dropbear/patches/100-pubkey_path.patch

  the upstream dropbear server uses the normal path
  ~/.ssh/authorized_keys

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


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


[Touch-packages] [Bug 1971932] Re: error in rsync protocol data stream

2022-05-09 Thread Paride Legovini
Hello and thanks for this bug report. I tried to reproduce this locally
but I failed. We're certainly willing to investigate this, but first we
need some steps to reproduce the problem. Could you please try to
identify a somehow reliable way to reproduce the issue and share your
findings? Thanks!

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

Title:
  error in rsync protocol data stream

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  When synchronizing to other systems, rsync exits with "error in rsync
  protocol data stream (code 12)".

  The problem occurs since ubuntu 22.04 LTS with two different
  destination systems not running ubuntu but plain debian. The error did
  not occur under 20.04 LTS.

  Synchronisation runs fine for most other files, but always stops at
  the same (relative large) file. The file itself has also been changed
  on a test basis to make sure the file is not the problem itself.

  Log snippet:
  

  ...
  chunk[46131] len=46120 offset=2127561720 sum1=2f48caf4
  chunk[46132] len=46120 offset=2127607840 sum1=5dfcb4ee
  chunk[46133] len=46120 offset=2127653960 sum1=d1037d81
  chunk[46134] len=8870 offset=2127700080 sum1=6deedc97
  send_files mapped 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX of size 
2135722584
  calling match_sums 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX
  built hash table
  hash search b=46120 len=2135722584
  sum=1e1722dc k=46120
  hash search s->blength=46120 len=2135722584 count=46135
  potential match at 0 i=0 sum=1e1722dc
  match at 0 last_match=0 j=0 len=46120 n=0
  potential match at 46120 i=1 sum=c482d6b6
  match at 46120 last_match=46120 j=1 len=46120 n=0
  potential match at 92240 i=2 sum=b21c7e11
  match at 92240 last_match=92240 j=2 len=46120 n=0
  potential match at 138360 i=3 sum=d066473a
  match at 138360 last_match=138360 j=3 len=46120 n=0
  potential match at 184480 i=4 sum=a32a2984
  match at 184480 last_match=184480 j=4 len=46120 n=0
  potential match at 230600 i=5 sum=39cc049f
  match at 230600 last_match=230600 j=5 len=46120 n=0
  potential match at 276720 i=6 sum=ad3de98a
  match at 276720 last_match=276720 j=6 len=46120 n=0
  potential match at 322840 i=7 sum=83e16fa9
  match at 322840 last_match=322840 j=7 len=46120 n=0
  deflate on token returned 0 (8512 bytes left)
  rsync error: error in rsync protocol data stream (code 12) at token.c(476) 
[sender=3.2.3]
  [sender] _exit_cleanup(code=12, file=token.c, line=476): entered
  [sender] _exit_cleanup(code=12, file=token.c, line=476): about to call 
exit(12)

  Sender system: (rsync 3.2.3-8ubuntu3)
  -

  rsync  version 3.2.3  protocol version 31
  Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
  Web site: https://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes,
  batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv,
  symtimes, prealloc, stop-at, no crtimes
  Optimizations:
  SIMD, no asm, openssl-crypto
  Checksum list:
  xxh128 xxh3 xxh64 (xxhash) md5 md4 none
  Compress list:
  zstd lz4 zlibx zlib none

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

  Recipient systems: (rsync 3.1.3-6)
  --

  rsync  version 3.1.3  protocol version 31
  Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
  Web site: http://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
  append, ACLs, xattrs, iconv, symtimes, prealloc

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

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


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


[Touch-packages] [Bug 1957104] Re: updating openssh-server fails, because port 22 is in use by systemd

2022-05-09 Thread Paride Legovini
Hello Thomas. You filed this bug against:

  DistroRelease: Ubuntu 21.10
  Package: openssh-server 1:8.4p1-6ubuntu2.1

By "Solved by a later version of systemd and sshd". Do you mean that you
found you can't reproduce the issue on Jammy (22.04 LTS)? Can you still
reproruce the issue on Impish? Thank you.

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

Title:
  updating openssh-server fails, because port 22 is in use by systemd

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  openssh-server tries to restart itself, but openssh-server reports
  port 22 in use. This is true: systemd has taken port 22 to start sshd
  if one connects to port 22.

  two solutions:
  1. dont start sshd after installing.
 configure it without starting it afterwards.
  2. stop systemd listening on port 22
 before starting sshd, then start sshd,
 terminate it after configuring, then
 start systemd listening on port 22 again.

  Second problem:
  starting ssh.service does not check if "/run/sshd" exists. This directory has 
to be created before sshd is started. Unclear if this is an error with sshd not 
creating this directory before dropping privileges or if this has to be done 
once while installing. IMHO the first is the case.

  
  Workaround:
  systemctl stop ssh.service
  systemctl disable ssh.service
  apt upgrade
  systemctl enable ssh.service
  killall sshd
  mkdir /run/sshd
  systemctl start ssh.service

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: openssh-server 1:8.4p1-6ubuntu2.1
  ProcVersionSignature: Ubuntu 5.13.0-23.23-generic 5.13.19
  Uname: Linux 5.13.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Tue Jan 11 19:11:47 2022
  InstallationDate: Installed on 2021-08-18 (146 days ago)
  InstallationMedia: Xubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  SSHDConfig: Error: command ['pkexec', '/usr/sbin/sshd', '-T'] failed with 
exit code 255: Missing privilege separation directory: /run/sshd
  SourcePackage: openssh
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1971888] Re: Can not ssh to github.com or gitlab.com when upgrading to 22.04

2022-05-09 Thread Paride Legovini
Hello Alvaro and thanks for this bug report. We have many systems
running Jammy and they're able to connect to GitHub with no issues. I
also tried with GitLab.com and it works just fine. This is not to
dismiss your report, but there's clearly something else involved in the
problem you're hitting. My suggestion is to try to reproduce the issue
from a freshly installed Jammy system, and if ssh *does* work there go
look for any relevant difference. I'm marking this report as Incomplete
for now, as we need more information from your side to move it forward.

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

Title:
  Can not ssh to github.com or gitlab.com when upgrading to 22.04

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  Dear all,

  After the upgrading to Ubuntu 22.04 I can not use git over ssh.

  The best way to reproduce the error is:

  ```
  acs@lsp-022:~$ ssh -vT g...@github.com
  OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  debug1: Connecting to github.com [140.82.121.4] port 22.
  debug1: connect to address 140.82.121.4 port 22: Connection timed out
  ```

  Before the upgrading I can connect correctly with:

  ```
  ssh -vT g...@github.com
  OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 23: Applying options for *
  debug1: Connecting to github.com [140.82.121.4] port 22.
  debug1: Connection established
  ```

  The same issue is happening with gitlab.com.

  Probably it is related with the OpenSSL version.

  Cheers!

  -- Alvaro

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: ssh 1:8.9p1-3
  ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30
  Uname: Linux 5.15.0-27-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: GNOME
  Date: Thu May  5 23:00:33 2022
  InstallationDate: Installed on 2021-03-08 (423 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  SourcePackage: openssh
  UpgradeStatus: Upgraded to jammy on 2022-05-05 (0 days ago)

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


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


[Touch-packages] [Bug 1971523] Re: Static build does not work for libmnl (-lmnl)

2022-05-05 Thread Paride Legovini
Hello Lars and thanks for this bug report. I can confirm this: libmnl-
dev 1.0.4-2 installs

  /usr/lib/x86_64-linux-gnu/libmnl.a

while libmnl-dev 1.0.4-3 does not. I tracked this down to this Debian
packaging change (see the debian/libmnl-dev.install diff):

https://salsa.debian.org/pkg-netfilter-team/pkg-
libmnl/-/commit/3526970e4dfb5598a9023496211c908e9ab7c9dc

Dropping the .a file looks like unintentional to me, at least by reading
the commit message. Ideally this should be fixed in Debian, to make
Debian benefit from the fix and keep the packages in sync, lowering the
maintenance work from the Ubuntu side.

Do you you think you can file a bug in Debian against the libmnl source
package and report it back here? This would speed up things. Thanks!

** Tags added: server-todo

** Changed in: libmnl (Ubuntu)
   Status: New => Triaged

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

Title:
  Static build does not work for libmnl (-lmnl)

Status in libmnl package in Ubuntu:
  Triaged

Bug description:
  Example;
  # gcc -o /tmp/hello /tmp/hello.c -lmnl
  (dynamic libs work)
  # gcc -static -o /tmp/hello /tmp/hello.c -lmnl
  /usr/bin/ld: cannot find -lmnl: No such file or directory

  
  My program uses both -lmnl and -lnetfilter_queue and in Ubuntu 20.04 the 
-lnetfilter_queue did not work and -lmnl worked for static builds. In Ubuntu 
22.04 the problem is reversed, -lnetfilter_queue works but -lmnl doesn't for 
static builds. This is very awkward during the transition 20.04->22.04 when 
both should be supported.

  I compensated in Ubuntu 20.04 by building netfilter_queue locally;
  https://github.com/Nordix/nfqueue-loadbalancer#build

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: libmnl0:amd64 1.0.4-3build2
  ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30
  Uname: Linux 5.15.0-27-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: XFCE
  Date: Wed May  4 07:33:26 2022
  InstallationDate: Installed on 2018-09-07 (1334 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: libmnl
  UpgradeStatus: Upgraded to jammy on 2022-05-01 (2 days ago)

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


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


[Touch-packages] [Bug 1969960] [NEW] Jammy's /etc/os-release missing LTS string in VERSION

2022-04-22 Thread Paride Legovini
Public bug reported:

[Description]

In Jammy (base-files 12ubuntu4) we have:

$ grep VERSION= /etc/os-release 
VERSION="22.04 (Jammy Jellyfish)"

but expected is:

VERSION="22.04 LTS (Jammy Jellyfish)"

Compare with Focal:

$ grep VERSION= /etc/os-release 
VERSION="20.04.4 LTS (Focal Fossa)"

[Impact]

Having VERSION without LTS is inconsistent with the previous LTS
releases and is wrong, as the official name of the release is "22.04
LTS". This can confuse users.

Any script relying on VERSION to detect if the Ubuntu version it is
running on in an LTS won't be work as expected.

[Test Plan]

1. grep VERSION= /etc/os-release 
2. check that it is: VERSION="22.04 LTS (Jammy Jellyfish)"

[Where problems could occur]

Software already packaged in Jammy may already have adapted to the fact
that VERSION doesn't have the LTS string in it.

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Assignee: Paride Legovini (paride)
 Status: Triaged

** Changed in: base-files (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

** Changed in: base-files (Ubuntu)
   Status: New => Triaged

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

Title:
  Jammy's /etc/os-release missing LTS string in VERSION

Status in base-files package in Ubuntu:
  Triaged

Bug description:
  [Description]

  In Jammy (base-files 12ubuntu4) we have:

  $ grep VERSION= /etc/os-release 
  VERSION="22.04 (Jammy Jellyfish)"

  but expected is:

  VERSION="22.04 LTS (Jammy Jellyfish)"

  Compare with Focal:

  $ grep VERSION= /etc/os-release 
  VERSION="20.04.4 LTS (Focal Fossa)"

  [Impact]

  Having VERSION without LTS is inconsistent with the previous LTS
  releases and is wrong, as the official name of the release is "22.04
  LTS". This can confuse users.

  Any script relying on VERSION to detect if the Ubuntu version it is
  running on in an LTS won't be work as expected.

  [Test Plan]

  1. grep VERSION= /etc/os-release 
  2. check that it is: VERSION="22.04 LTS (Jammy Jellyfish)"

  [Where problems could occur]

  Software already packaged in Jammy may already have adapted to the
  fact that VERSION doesn't have the LTS string in it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1969960/+subscriptions


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


[Touch-packages] [Bug 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

2022-04-19 Thread Paride Legovini
I tried reproducing the issue on a Rpi4, cloning a repository via ssh
using pubkey authentication with a rsa2048 key stored in ssh-agent, it
worked fine. If you believe there's actually a bug here please provide
some steps we can follow to reproduce the issue from a clean Jammy
system, and we'll look into this again. Thanks!

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

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

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


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


[Touch-packages] [Bug 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

2022-04-14 Thread Paride Legovini
** 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/1968876

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

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


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


[Touch-packages] [Bug 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

2022-04-14 Thread Paride Legovini
Also: you mention that "ssh agent crashes". What do you see exactly to
be able to tell it's a crash and not some other authentication or key
handling issue?

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

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  New

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

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


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


[Touch-packages] [Bug 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

2022-04-14 Thread Paride Legovini
Hello testpi and thanks for this bug report. Can you reproduce this
issue from a fresh install on the Raspberry, and attempting a simple ssh
login instead of a git clone? Something on these lines:

-
ssh-keygen
cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
killall ssh-agent || true
eval $(ssh-agent)
ssh-add
ssh localhost
-

I'll try to reproduce this issue myself but I don't have access to a
Rpi4 at the moment, but I should have soon. As we're waiting for more
information here I'm marking this report as Incomplete for now.

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

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  New

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

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


-- 
Mailing list: https://launchpad.net/~touch-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 Paride Legovini
Hello Alexander, note that Xorg is available in Jammy both as the native
graphical session and via xwayland. On this bug report: could you please
elaborate more on what exactly happens? In particular could you guide us
into reproducing the problem on a clean Jammy install, making clear
"what should happen" and "what actually happens" when facing the
problem?

As we're waiting for more information here I'm marking this bug report
as Incomplete.

Thanks!

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

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

[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used

2022-03-21 Thread Paride Legovini
Still no activity in the upstream issue, however I think OpenSSH 8.9
offers a mechanism that can help avoiding hitting MaxAuthTries in some
cases: "destination constraints", see documentation for -h in ssh-
add(1). AIUI constraining should limit the number of keys tried against
a given host, making reaching MaxAuthTries more difficult. More info:

  https://www.openssh.com/agent-restrict.html
  https://lwn.net/Articles/880458/

It is not clear to me if setting destination constraints also affects
the order in which keys are tried (narrower scope => higher priority).

Another workaround is preventing ssh to reach the agent:

  SSH_AUTH_SOCK= ssh -i  

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

Title:
  explicit key offered after all agent keys, auth can fail before
  explicit key used

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh package in Debian:
  New

Bug description:
  A user creates an ssh key and specifies it on the cmdline with 'ssh -i
  new_key user@host'.  The connection fails with the message "Too many
  authentication failures" displayed to the user.

  This would lead the user to believe that they failed to put the public
  portion of the new key on the destination and it will probably be hard
  for the average user to debug this.

  The root of this issue is that the user has a number of keys in
  ~/.ssh/ registered with their ssh agent.  The ssh command is offering
  each of these keys from the agent to the remote system before trying
  the explicit key from the command line.  There are enough agent keys
  to reach the failure limit (usually 5 keys) with the remote before
  they get to the explicit key.

  The solution today for the user is to head down into the ssh_config
  man page to find '-o IdentitiesOnly=yes' to skip the agent keys and
  only use the specified key.  But they're unlikely to do this because
  '-i' in the ssh man page doesn't suggest this and they'd only look for
  this if they actually understood the root cause of the problem, which
  is a bit cruel.

  We should consider changing the order of the keys offered to the
  remote to use explicit keys first followed by agent keys.  It would
  seem to me that this would honor the users intent of explicitly
  specifying a key to use.

  The current order makes this difficult for anyone fielding a user's
  authentication failure report as they must double check that ssh
  managed to actually try the key the user specified before it raised an
  error message about authentication failures.

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


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


[Touch-packages] [Bug 1965076] Re: rsync --update incorrectly reports file "is newer" than itself

2022-03-17 Thread Paride Legovini
I see your point; my suggestion here is to file a bug upstream with your
findings:

  https://github.com/WayneD/rsync/issues

I don't think this should be tackled on the Ubuntu side, especially
given that the issue is really minor and unlikely to affect a
significant amount of users. As you say what changed is a double-
verbosity info message with no promise of stability, the actual behavior
of rsync is correct.

If you file a bug upstream please mention it here, we'll track it and
once fixed we'll consider applying the fix to the supported Ubuntu
releases. Thanks!


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

** Changed in: rsync (Ubuntu)
   Status: Incomplete => Confirmed

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

Title:
  rsync --update incorrectly reports file "is newer" than itself

Status in rsync package in Ubuntu:
  Confirmed

Bug description:
  rsync 3.2.3 has a broken "--update" option.See the examples below.
  The "--update" option incorrectly makes rsync say a file is newer than itself.
  Remove the "--update" option, and rsync correctly says the file is "uptodate".
  The right output should of course be "is uptodate" in all cases.
  This bug also shows up between machines if the source rsync is 3.1.3 and the 
destination is 3.2.3.
  The bug does not show up if the source rsync is 3.2.3 and the destination is 
3.1.3.

  $ touch foo
  $ rsync -avv --update foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is newer <=== THIS IS NOT CORRECT - A file can't be newer 
than itself.
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 38 bytes  received 96 bytes  268.00 bytes/sec
  total size is 0  speedup is 0.00

  $ rsync -avv foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is uptodate  <=== THIS IS CORRECT
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 41 bytes  received 106 bytes  294.00 bytes/sec
  total size is 0  speedup is 0.00

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: rsync 3.2.3-4ubuntu1
  ProcVersionSignature: Ubuntu 5.13.0-35.40-generic 5.13.19
  Uname: Linux 5.13.0-35-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Mar 15 22:47:44 2022
  InstallationDate: Installed on 2022-03-16 (0 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1965076] Re: rsync --update incorrectly reports file "is newer" than itself

2022-03-17 Thread Paride Legovini
Hello Ian and thanks for this bug report. My question here is: is this
actually a bug?

The manpage for --update says:

  This forces rsync to skip any files which exist on the destination
  and have a modified time that is newer

It seems sensible to me to make this a '>=' comparison, and not a strict
'>' comparison: when considering modification times there's no need to
update a file which has the same timestamp of the source file.

In other words: I fail to see the problem here. Could you please
elaborate a bit more? Thanks!

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

Title:
  rsync --update incorrectly reports file "is newer" than itself

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  rsync 3.2.3 has a broken "--update" option.See the examples below.
  The "--update" option incorrectly makes rsync say a file is newer than itself.
  Remove the "--update" option, and rsync correctly says the file is "uptodate".
  The right output should of course be "is uptodate" in all cases.
  This bug also shows up between machines if the source rsync is 3.1.3 and the 
destination is 3.2.3.
  The bug does not show up if the source rsync is 3.2.3 and the destination is 
3.1.3.

  $ touch foo
  $ rsync -avv --update foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is newer <=== THIS IS NOT CORRECT - A file can't be newer 
than itself.
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 38 bytes  received 96 bytes  268.00 bytes/sec
  total size is 0  speedup is 0.00

  $ rsync -avv foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is uptodate  <=== THIS IS CORRECT
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 41 bytes  received 106 bytes  294.00 bytes/sec
  total size is 0  speedup is 0.00

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: rsync 3.2.3-4ubuntu1
  ProcVersionSignature: Ubuntu 5.13.0-35.40-generic 5.13.19
  Uname: Linux 5.13.0-35-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Mar 15 22:47:44 2022
  InstallationDate: Installed on 2022-03-16 (0 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1964642] Re: Packer virtualbox ssh can't connect to unattended Ubuntu 20.04.1/2/3/4 but can connect to Ubuntu 20.4

2022-03-17 Thread Paride Legovini
** 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/1964642

Title:
  Packer virtualbox ssh can't connect to unattended Ubuntu 20.04.1/2/3/4
  but can connect to Ubuntu 20.4

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  Two years ago I was able to create a Virtualbox Ubuntu 20.04 guest in a 
Windows 10 host with Packer 1.5.6, using an unattended installation.
  The Packer command was:
    "boot_command": [
  " ",
  "autoinstall ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/",
  ""
    ],
  The user-data file was:
  #cloud-config
  autoinstall:
    version: 1
    identity:
  realname: mclibre
  hostname: ubuntu
  password: 
'$6$mclibre$YiuRPSZM3ZXVe4UyIqv1dvy9rUjf5/LsGCkDyaex.WN45wzVTuRmW5QLuctuicGAFZIO2M3QR8NLdtQYatKTn1'
  username: mclibre
    locale: es_ES.UTF-8
    keyboard:
  layout: es
    network:
  network:
    version: 2
    ethernets:
  ens33: {dhcp4: true, dhcp-identifier: mac}
    ssh:
  install-server: true
    late-commands:
  - sed -i 's/^#*\(send dhcp-client-identifier\).*$/\1 = hardware;/' 
/target/etc/dhcp/dhclient.conf
  - 'sed -i "s/dhcp4: true/&\n  dhcp-identifier: mac/" 
/target/etc/netplan/00-installer-config.yaml'
  Now, I have tried to create a Virtualbox Ubuntu 20.04.4/.3/.2/.1 guest using 
packer 1.5.6 but Packer can't create the image because once the installation is 
done, after rebooting the SSH server does not answer (the packer log error 
says: SSH handshake err: Timeout during SSH handshake).
  I have tried with the last version of Packer, Packer 1.8.0, and the result is 
the same. I can create a Ubuntu Server 20.4 image but not a Ubuntu Server 
20.4.1, .2, .3 or .4 image.
  I can provide as much aditional information as you want.
  Thanking you in advance,
  Bartolome Sintes

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


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


[Touch-packages] [Bug 1964642] Re: Packer virtualbox ssh can't connect to unattended Ubuntu 20.04.1/2/3/4 but can connect to Ubuntu 20.4

2022-03-17 Thread Paride Legovini
Hello Barto,

If I understand it correctly you can create working images using 20.04
ISOs *right now*, but with the exact same tooling images created with
20.04.x ISOs do not work. I think you have been clear about this, but it
is of course very important to know that the only moving part is the ISO
image.

Given that you have console access to the machine, at least for a few
minutes before Virtualbox tears it down, can you please share the output
of the following commands?

 - ip addr
 - systemctl status
 - systemctl status ssh

My wild guess here is that for some reason the 20.04.x images get a
different Ethernet interface name (you hardcoded ens33 in cloud-config).

Also: can you login from the machine to itself (ssh mclibre@127.0.0.1)?

Also: can you share the contents of /etc/dhcp/dhclient.conf and
/etc/netplan/00-installer-config.yaml?

Thank you.

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

Title:
  Packer virtualbox ssh can't connect to unattended Ubuntu 20.04.1/2/3/4
  but can connect to Ubuntu 20.4

Status in openssh package in Ubuntu:
  New

Bug description:
  Two years ago I was able to create a Virtualbox Ubuntu 20.04 guest in a 
Windows 10 host with Packer 1.5.6, using an unattended installation.
  The Packer command was:
    "boot_command": [
  " ",
  "autoinstall ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/",
  ""
    ],
  The user-data file was:
  #cloud-config
  autoinstall:
    version: 1
    identity:
  realname: mclibre
  hostname: ubuntu
  password: 
'$6$mclibre$YiuRPSZM3ZXVe4UyIqv1dvy9rUjf5/LsGCkDyaex.WN45wzVTuRmW5QLuctuicGAFZIO2M3QR8NLdtQYatKTn1'
  username: mclibre
    locale: es_ES.UTF-8
    keyboard:
  layout: es
    network:
  network:
    version: 2
    ethernets:
  ens33: {dhcp4: true, dhcp-identifier: mac}
    ssh:
  install-server: true
    late-commands:
  - sed -i 's/^#*\(send dhcp-client-identifier\).*$/\1 = hardware;/' 
/target/etc/dhcp/dhclient.conf
  - 'sed -i "s/dhcp4: true/&\n  dhcp-identifier: mac/" 
/target/etc/netplan/00-installer-config.yaml'
  Now, I have tried to create a Virtualbox Ubuntu 20.04.4/.3/.2/.1 guest using 
packer 1.5.6 but Packer can't create the image because once the installation is 
done, after rebooting the SSH server does not answer (the packer log error 
says: SSH handshake err: Timeout during SSH handshake).
  I have tried with the last version of Packer, Packer 1.8.0, and the result is 
the same. I can create a Ubuntu Server 20.4 image but not a Ubuntu Server 
20.4.1, .2, .3 or .4 image.
  I can provide as much aditional information as you want.
  Thanking you in advance,
  Bartolome Sintes

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


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


[Touch-packages] [Bug 1778073] Re: dnsmasq and resolvconf hangs on start

2022-03-03 Thread Paride Legovini
** Changed in: dnsmasq (Ubuntu)
 Assignee: Paride Legovini (paride) => (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/1778073

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

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


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


[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x due to LTO

2022-02-18 Thread Paride Legovini
I reviewed this issue again and I don't think we're ready to drop the
"Disable LTO on s390x" delta for now. There are newer NSS upstream
versions worth testing but in Ubuntu we're still at 3.68 for now.

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

Title:
  Test of dogtag-pki is failing on s390x due to LTO

Status in NSS:
  New
Status in nss package in Ubuntu:
  Triaged
Status in nss package in Fedora:
  Unknown

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server
  ii  libnss3:s390x  2:3.63-1ubuntu1 

[Touch-packages] [Bug 1959365] Re: openssh-client tab completion faills if shopt failglob is set

2022-01-31 Thread Paride Legovini
I can reproduce this:

$ shopt -s failglob
$ ssh bash: no match: /etc/ssh/ssh_config.d/*.conf

but I believe the bugs belongs to the bash-completion package.

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

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

** Package changed: openssh (Ubuntu) => bash-completion (Ubuntu)

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

Title:
  openssh-client tab completion faills if shopt failglob is set

Status in bash-completion package in Ubuntu:
  Confirmed

Bug description:
  $ ssh 

  ends up looking like

  $ ssh bash: no match: /etc/ssh/ssh_config.d/*.conf
  $ _

  
  I have shopt failglob set in my bashrc as a personal preference and most 
other packages' tab completion can deal with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1959365/+subscriptions


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


[Touch-packages] [Bug 1959488] Re: Error loading key ".../id_ed25519.pub": error in libcrypto

2022-01-31 Thread Paride Legovini
Hello Thomas and thanks for your bug report. I have no problems adding
ed25519 keys to ssh-agent on a Jammy system. Could you please try the
following steps, which may help identifying where the problem is?
Thanks!

$ mkdir /tmp/ed25519test
$ cd /tmp/ed25519test

$ echo $SSH_AUTH_SOCK
/run/user/1000/openssh_agent

$ ssh-keygen -t ed25519 -C foobar -P '' -f ./test
Generating public/private ed25519 key pair.
Your identification has been saved in ./test
Your public key has been saved in ./test.pub
The key fingerprint is:
SHA256:EFUY6Ke0diCIoFQjCvhiUBzondDLMidZN4/bzkt1X6I foobar
The key's randomart image is: [...]

$ cat test.pub
ssh-ed25519 
C3NzaC1lZDI1NTE5IEqKBt+j+61A9GtPaA9RLEEHxBQpAgvUSkjpqlRpVXOh foobar

$ ssh-add ./test
Identity added: ./test (foobar)

$ ssh-add -L | grep foobar
ssh-ed25519 
C3NzaC1lZDI1NTE5IEqKBt+j+61A9GtPaA9RLEEHxBQpAgvUSkjpqlRpVXOh foobar


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

Title:
  Error loading key ".../id_ed25519.pub": error in libcrypto

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  I can't add my ED25519 ssh-key to my ssh-agent. I am getting this
  error message:

  user@pc:~$ ssh-add ~/.ssh/id_ed25519.pub
  Error loading key "/home/user/.ssh/id_ed25519.pub": error in libcrypto

  I have setup key agent for KDE like this:

  user@pc:~$ cat ~/.config/plasma-workspace/env/ssh-agent.sh
  #!/bin/bash

  [ -n "$SSH\_AGENT\_PID" ] || eval "$(ssh-agent -s)"

  user@pc:~$ cat ~/.config/plasma-workspace/env/ssh-askpass.sh
  #!/bin/bash

  [ -n "$SSH\_ASKPASS" ] || export SSH\_ASKPASS=/usr/bin/ksshaskpass

  user@pcc:~$ cat ~/.config/plasma-workspace/shutdown/ssh-agent-shutdown.sh 
  #!/bin/bash

  [ -z "$SSH\_AGENT\_PID" ] || eval "$(ssh-agent -k)"

  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh-client 1:8.7p1-4
  Uname: Linux 5.15.0-051500-generic x86_64
  ApportVersion: 2.20.11-0ubuntu76
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: KDE
  Date: Sat Jan 29 16:43:55 2022
  InstallationDate: Installed on 2022-01-21 (7 days ago)
  InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 
(20220121)
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions:
   ssh-askpass   N/A
   libpam-sshN/A
   keychain  N/A
   ssh-askpass-gnome N/A
  SSHClientVersion: OpenSSH_8.7p1 Ubuntu-4, OpenSSL 3.0.1 14 Dec 2021
  SourcePackage: openssh
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange

2022-01-27 Thread Paride Legovini
That PR is still pending review, no movements there unfortunately.

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

Title:
  monitor_read: unpermitted request 48 on server while attempting GSSAPI
  key exchange

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh source package in Focal:
  Triaged
Status in openssh source package in Hirsute:
  Won't Fix

Bug description:
  I'm using openssh 1:8.2p1-4ubuntu0.2 on Ubuntu 20.04.2 LTS (client and
  server) with the option "GSSAPIKeyExchange=yes", and this causes the
  connection to fail. The server has GSSAPI (Kerberos authentication)
  enabled, but is is only used for non-root users (root uses SSH keys).

  Client command:

  ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex
  root@server -v -p  -o GSSAPIKeyExchange=yes

  Client log:

  OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
  debug1: Reading configuration data /home/user/.ssh/config
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  debug1: Connecting to compute-test [130.75.80.46] port .
  debug1: Connection established.
  debug1: identity file /home/rother/.ssh/id_rsa type 0
  debug1: identity file /home/rother/.ssh/id_rsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_dsa type -1
  debug1: identity file /home/rother/.ssh/id_dsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa_sk type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa_sk-cert type -1
  debug1: identity file /home/rother/.ssh/id_ed25519 type -1
  debug1: identity file /home/rother/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/rother/.ssh/id_ed25519_sk type -1
  debug1: identity file /home/rother/.ssh/id_ed25519_sk-cert type -1
  debug1: identity file /home/rother/.ssh/id_xmss type -1
  debug1: identity file /home/rother/.ssh/id_xmss-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
  debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 
Ubuntu-4ubuntu0.2
  debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x0400
  debug1: Authenticating to server: as 'root'
  debug1: Offering GSSAPI proposal: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug1: kex: algorithm: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==
  debug1: kex: host key algorithm: ecdsa-sha2-nistp256
  debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: Doing group exchange
  debug1: Calling gss_init_sec_context
  debug1: Delegating credentials
  debug1: Received GSSAPI_COMPLETE
  debug1: Calling gss_init_sec_context
  debug1: Delegating credentials
  debug1: Rekey has happened - updating saved versions
  debug1: rekey out after 134217728 blocks
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug1: SSH2_MSG_NEWKEYS received
  debug1: rekey in after 134217728 blocks
  debug1: Will attempt key: /home/rother/.ssh/id_rsa RSA 
SHA256:n/EY/cGjgd/r+7JpuqODxIotHHLsYptGXYx9GlKCWSM agent
  debug1: Will attempt key: /home/rother/.ssh/root_id_rsa RSA 
SHA256:yCLAID9FMILharHmDpCB8wW8eiA+iHa4oQKLODbbzKw agent
  debug1: Will attempt key: /home/user/.ssh/id_dsa 
  debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
  debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk 
  debug1: Will attempt key: /home/user/.ssh/id_ed25519 
  debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk 
  debug1: Will attempt key: /home/user/.ssh/id_xmss 
  debug1: SSH2_MSG_EXT_INFO received
  debug1: kex_input_ext_info: 
server-sig-algs=
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next authentication method: gssapi-with-mic
  debug1: Delegating credentials
  debug1: Delegating credentials
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next authentication method: gssapi-keyex
  Connection closed by 1.2.3.4 port 

  Server log:

  debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1f  31 Mar 2020
  debug1: private host key #0: ssh-rsa SHA256:REDACTED
  debug1: private host key #1: ecdsa-sha2-nistp256 

[Touch-packages] [Bug 1956954] Re: Can't load seccomp filter

2022-01-24 Thread Paride Legovini
Hi, glad to know it worked. There is some heuristics behind the default
bpf_jit_limit [1], it isn't a simple hardcoded value. We may discuss
bumping the default in Ubuntu, but I don't think that's a good idea: the
in-kernel heuristics has certainly been well thought, and just bumping
the number is likely to have other unintended consequences.

My take here is: your setup needs tuning, and that's what those config
knobs are for. Note that it's better to add a config file under
/etc/sysctl.d rather than modifying the default /etc/sysctl.conf.

Let me know if this makes sense for you. I'm leaving this bug marked
Incomplete for now.

[1]
https://github.com/torvalds/linux/blob/8efd0d9c316af470377894a6a0f9ff63ce18c177/kernel/bpf/core.c#L826

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

Title:
  Can't load seccomp filter

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  After migrating from Ubuntu 20 amd64 to aarch64 I started experiencing
  "can't load seccomp filter" when doing `apt update && apt upgrade` and
  "Kernel refuses to turn on BPF filters" when using Puppeteer.

  I wrote about it more extensively here:
  https://stackoverflow.com/questions/69892137/after-a-few-days-i-can-
  no-longer-start-puppeteer-until-i-restart-the-server

  
  lsb_release -rd
  ---
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04

  apt-cache policy seccomp
  ---
  seccomp:
Installed: (none)
Candidate: 2.5.1-1ubuntu1~20.04.2
Version table:
   2.5.1-1ubuntu1~20.04.2 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports 
focal-updates/main arm64 Packages
  500 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 
Packages
   2.4.3-1ubuntu1 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports focal/main 
arm64 Packages

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


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


[Touch-packages] [Bug 1958453] Re: clamav-freshclam does not upgrade successfuly

2022-01-20 Thread Paride Legovini
Hello and thanks for your bug report. While you hit this issue while
upgrading clamav-freshclam, those hashfiles are owned by ucf(1), so I'm
reassigning the bug to the ucf package.

There isn't really enough information here for a developer to confirm
this issue is a bug, or to begin working on it, so I am marking this bug
Incomplete for now. If you can provide exact steps so that a developer
can reproduce the original problem, then please add them to this bug and
change the status back to New. Thanks!

** Package changed: clamav (Ubuntu) => ucf (Ubuntu)

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

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

Title:
  clamav-freshclam does not upgrade successfuly

Status in ucf package in Ubuntu:
  Incomplete

Bug description:
  When upgrading my email server:

  Setting up clamav-freshclam (0.103.5+dfsg-1~20.04.1) ...
  Replacing config file /etc/clamav/freshclam.conf with new version
  cp: '/var/lib/ucf/hashfile.5' and '/var/lib/ucf/hashfile.6' are the same file
  dpkg: error processing package clamav-freshclam (--configure):
   installed clamav-freshclam package post-installation script subprocess 
returned error exit status 1

  I chose to install the package maintainers configuration

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: clamav-freshclam 0.103.5+dfsg-1~20.04.1
  ProcVersionSignature: Ubuntu 5.4.0-94.106-generic 5.4.157
  Uname: Linux 5.4.0-94-generic x86_64
  NonfreeKernelModules: cpuid xt_conntrack xt_MASQUERADE nf_conntrack_netlink 
nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter br_netfilter bridge stp llc 
aufs overlay dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua amd64_edac_mod 
edac_mce_amd kvm_amd ccp input_leds kvm macvlan mac_hid k10temp sch_fq_codel 
w83795 msr ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 multipath linear radeon i2c_algo_bit ttm drm_kms_helper 
syscopyarea hid_generic sysfillrect sysimgblt fb_sys_fops usbhid pata_acpi ahci 
hid pata_atiixp i2c_piix4 drm libahci tg3
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Wed Jan 19 21:19:00 2022
  KernLog:
   
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IE.UTF-8
   SHELL=/bin/bash
  SourcePackage: clamav
  UpgradeStatus: Upgraded to focal on 2020-12-29 (386 days ago)

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


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


[Touch-packages] [Bug 1956954] Re: Can't load seccomp filter

2022-01-13 Thread Paride Legovini
If you want to change the value without rebooting that's:

  sudo sysctl net.core.bpf_jit_limit=264241152

Add it to /etc/sysctl.conf if you want to set it automatically at boot,
but it's more meaningful to test as you said: wait for the issue to
happen and then change the value while the system is running.

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

Title:
  Can't load seccomp filter

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  After migrating from Ubuntu 20 amd64 to aarch64 I started experiencing
  "can't load seccomp filter" when doing `apt update && apt upgrade` and
  "Kernel refuses to turn on BPF filters" when using Puppeteer.

  I wrote about it more extensively here:
  https://stackoverflow.com/questions/69892137/after-a-few-days-i-can-
  no-longer-start-puppeteer-until-i-restart-the-server

  
  lsb_release -rd
  ---
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04

  apt-cache policy seccomp
  ---
  seccomp:
Installed: (none)
Candidate: 2.5.1-1ubuntu1~20.04.2
Version table:
   2.5.1-1ubuntu1~20.04.2 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports 
focal-updates/main arm64 Packages
  500 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 
Packages
   2.4.3-1ubuntu1 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports focal/main 
arm64 Packages

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


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


[Touch-packages] [Bug 1956954] Re: Can't load seccomp filter

2022-01-13 Thread Paride Legovini
Hi Nino, I found a RedHat bug [1] that describes a similar situation
(affected is dhclient on ppc64le, but the error is the same).

The suggested workaround is setting

  net.core.bpf_jit_limit = 262144000

via sysctl. I checked and on amd64 I find

  net.core.bpf_jit_limit = 264241152

while on an arm64 machine that's:

  net.core.bpf_jit_limit = 33554432

(both machines are running Bionic), so it looks arch-dependent indeed.
Could you please try bumping that value, and check if the issue goes
away?

If it does go away we can ask the kernel team what they think about
bumping it by default.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1647947

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

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

Title:
  Can't load seccomp filter

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  After migrating from Ubuntu 20 amd64 to aarch64 I started experiencing
  "can't load seccomp filter" when doing `apt update && apt upgrade` and
  "Kernel refuses to turn on BPF filters" when using Puppeteer.

  I wrote about it more extensively here:
  https://stackoverflow.com/questions/69892137/after-a-few-days-i-can-
  no-longer-start-puppeteer-until-i-restart-the-server

  
  lsb_release -rd
  ---
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04

  apt-cache policy seccomp
  ---
  seccomp:
Installed: (none)
Candidate: 2.5.1-1ubuntu1~20.04.2
Version table:
   2.5.1-1ubuntu1~20.04.2 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports 
focal-updates/main arm64 Packages
  500 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 
Packages
   2.4.3-1ubuntu1 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports focal/main 
arm64 Packages

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


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


[Touch-packages] [Bug 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

2021-12-08 Thread Paride Legovini
The upstream commit [1] included as a patch in strongswan
(5.9.4-1ubuntu2) should be released in strongswan 5.9.5 [2].

[1] 
https://github.com/strongswan/strongswan/commit/b158c08c4b919b878ded10bb57e969ed7b3cabc3
[2] https://github.com/strongswan/strongswan/milestone/3?closed=1

-- 
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:
  Fix Released
Status in strongswan package in Ubuntu:
  Fix Released

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 1952918] Re: Please temporarely pull fluidsynth 2.2.4-2 from jammy-proposed

2021-12-01 Thread Paride Legovini
** Description changed:

  fluidsynth 2.2.4-2 (currently in jammy-proposed) has a SONAME bump:
  
    libfluidsynth2 -> libfluidsynth3
  
  which is a fairly large transition:
  
  $ reverse-depends -b -l src:fluidsynth | wc -l
  30
  
  This list of reverse-dependencies has exactly one package in common with
  other two currently ongoing transitions:
  
  $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:libidn)
  vlc
  
  $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:liburing)
  mpd
  
- These other two migrations are almost done, hopefully just requiring
+ These other two transitions are almost done, hopefully just requiring
  couple of minor uploads (merging a new Debian revision of ghostscript
  and uploading a new Ubuntu revision of exim4 to resolve a components-
  mismatch).
  
  I think it it would be better to finish these other two transitions
  first, without fluidsynth, and then sync fluidsynth again, to be handled
  separately.

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

Title:
  Please temporarely pull fluidsynth 2.2.4-2 from jammy-proposed

Status in fluidsynth package in Ubuntu:
  New

Bug description:
  fluidsynth 2.2.4-2 (currently in jammy-proposed) has a SONAME bump:

    libfluidsynth2 -> libfluidsynth3

  which is a fairly large transition:

  $ reverse-depends -b -l src:fluidsynth | wc -l
  30

  This list of reverse-dependencies has exactly one package in common
  with other two currently ongoing transitions:

  $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:libidn)
  vlc

  $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:liburing)
  mpd

  These other two transitions are almost done, hopefully just requiring
  couple of minor uploads (merging a new Debian revision of ghostscript
  and uploading a new Ubuntu revision of exim4 to resolve a components-
  mismatch).

  I think it it would be better to finish these other two transitions
  first, without fluidsynth, and then sync fluidsynth again, to be
  handled separately.

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


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


[Touch-packages] [Bug 1952918] [NEW] Please temporarely pull fluidsynth 2.2.4-2 from jammy-proposed

2021-12-01 Thread Paride Legovini
Public bug reported:

fluidsynth 2.2.4-2 (currently in jammy-proposed) has a SONAME bump:

  libfluidsynth2 -> libfluidsynth3

which is a fairly large transition:

$ reverse-depends -b -l src:fluidsynth | wc -l
30

This list of reverse-dependencies has exactly one package in common with
other two currently ongoing transitions:

$ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:libidn)
vlc

$ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:liburing)
mpd

These other two migrations are almost done, hopefully just requiring
couple of minor uploads (merging a new Debian revision of ghostscript
and uploading a new Ubuntu revision of exim4 to resolve a components-
mismatch).

I think it it would be better to finish these other two transitions
first, without fluidsynth, and then sync fluidsynth again, to be handled
separately.

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

** Description changed:

  fluidsynth 2.2.4-2 (currently in jammy-proposed) has a SONAME bump:
  
-   libfluidsynth2 -> libfluidsynth3
+   libfluidsynth2 -> libfluidsynth3
  
  which is a fairly large transition:
  
  $ reverse-depends -b -l src:fluidsynth | wc -l
  30
  
  This list of reverse-dependencies has exactly one package in common with
  other two currently ongoing transitions:
  
- $ comm -12 <( reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:libidn)
+ $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:libidn)
  vlc
  
- $ comm -12 <( reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:liburing)
+ $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:liburing)
  mpd
  
  These other two migrations are almost done, hopefully just requiring
  couple of minor uploads (merging a new Debian revision of ghostscript
  and uploading a new Ubuntu revision of exim4 to resolve a components-
  mismatch).
  
  I think it it would be better to finish these other two transitions
  first, without fluidsynth, and then sync fluidsynth again, to be handled
  separately.

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

Title:
  Please temporarely pull fluidsynth 2.2.4-2 from jammy-proposed

Status in fluidsynth package in Ubuntu:
  New

Bug description:
  fluidsynth 2.2.4-2 (currently in jammy-proposed) has a SONAME bump:

    libfluidsynth2 -> libfluidsynth3

  which is a fairly large transition:

  $ reverse-depends -b -l src:fluidsynth | wc -l
  30

  This list of reverse-dependencies has exactly one package in common
  with other two currently ongoing transitions:

  $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:libidn)
  vlc

  $ comm -12 <(reverse-depends -b -l src:fluidsynth) <(reverse-depends -b -l 
src:liburing)
  mpd

  These other two migrations are almost done, hopefully just requiring
  couple of minor uploads (merging a new Debian revision of ghostscript
  and uploading a new Ubuntu revision of exim4 to resolve a components-
  mismatch).

  I think it it would be better to finish these other two transitions
  first, without fluidsynth, and then sync fluidsynth again, to be
  handled separately.

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


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


[Touch-packages] [Bug 1871465] Re: ssh_config(5) contains outdated information

2021-11-18 Thread Paride Legovini
As the fix is in Jammy I think we can mark the devel task as Fix
Released.

I doubt this is SRU material as the impact of the bug is really low;
maybe it could be done with a staged upload [1]. I'm marking the SRU
tasks as Triaged as the bug is well understood.

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

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

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

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

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

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

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

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

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

Title:
  ssh_config(5) contains outdated information

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Focal:
  Triaged
Status in openssh source package in Hirsute:
  Triaged
Status in openssh source package in Impish:
  Triaged

Bug description:
  The release of OpenSSH 8.2 has removed `ssh-rsa` from the default list
  of CACertificateAlgorithms. However the latest `openssh-client` still
  ships the man page for ssh_config(5) that contains the following
  description:

   CASignatureAlgorithms
   Specifies which algorithms are allowed for signing of 
certificates 
   by certificate authorities (CAs).  The default is:

     
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
     ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

   ssh(1) will not accept host certificates signed using algorithms 
   other than those specified.

  As far as I am concerned, `ssh-rsa` should be dropped from the list so
  as to match the behavior of ssh(1).

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


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


[Touch-packages] [Bug 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

2021-11-17 Thread Paride Legovini
** Changed in: strongswan (Ubuntu)
   Status: New => In Progress

-- 
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:
  In Progress

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 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

2021-11-16 Thread Paride Legovini
Issue #735 has been closed as it's actually an OpenSSL bug (and we
already have a task for that). I'm making this track #759 instead.

** Changed in: strongswan
   Status: New => Unknown

** Changed in: strongswan
 Remote watch: github.com/strongswan/strongswan/issues #753 => 
github.com/strongswan/strongswan/issues #759

-- 
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:
  New
Status in strongSwan:
  Unknown
Status in openssl package in Ubuntu:
  New
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 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

2021-11-16 Thread Paride Legovini
With openssl 3.0.0-1ubuntu1~ppa2 the ed25519_fail issue is fixed, but we
then hit another (unrelated) test failure. I reported it upstream here:

https://github.com/strongswan/strongswan/issues/759


** Bug watch added: github.com/strongswan/strongswan/issues #759
   https://github.com/strongswan/strongswan/issues/759

-- 
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:
  New
Status in strongSwan:
  New
Status in openssl package in Ubuntu:
  New
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 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

2021-11-15 Thread Paride Legovini
Thanks! I'll re-test the strongswan build once 3.0.0-1ubuntu1~ppa2 gets
published in the PPA.

-- 
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:
  New
Status in strongSwan:
  New
Status in openssl package in Ubuntu:
  New
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 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

2021-11-15 Thread Paride Legovini
Apparently this is an OpenSSL 3 bug uncovered by the strongswan
testsuite:

https://github.com/openssl/openssl/issues/17017

It's actively being worked on upstream.

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

** Bug watch added: github.com/openssl/openssl/issues #17017
   https://github.com/openssl/openssl/issues/17017

** Also affects: openssl via
   https://github.com/openssl/openssl/issues/17017
   Importance: Unknown
   Status: Unknown

-- 
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:
  Unknown
Status in strongSwan:
  New
Status in openssl package in Ubuntu:
  New
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 1778073] Re: dnsmasq and resolvconf hangs on start

2021-11-10 Thread Paride Legovini
** Tags removed: server-next

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

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

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


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


[Touch-packages] [Bug 1949535] Re: X-forwarding no longer works

2021-11-08 Thread Paride Legovini
Hello Robert and thanks for your bug report. You wrote:

> I recently upgraded my debian shell server to Bullet

but I'm not sure I get what you mean. Is it a Debian system or an Ubuntu
system? If it's upgrading a Debian system that broke your setup then
there's nothing I can see that points to a bug in Ubuntu. Moreover: what
is Bullet? Did you mean Bullseye or Bookworm?

If you think there's actually a bug in Ubuntu here please share more of
your reasoning, possibly providing a reproducer, e.g. by ssh -X to a
container or VM. I'm marking this bug report as Incomplete for the
moment. Feel free to change it back to New after commenting back.
Thanks!

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

Title:
  X-forwarding no longer works

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  I operate a Linux based Internet hosting service that includes Linux
  shell servers of various flavors.  I control these from home using
  Ubuntu 21.10 presently.  Until recently, X-forwarding has worked from
  all but ancient Redhat 6.2 servers.  I recently upgraded my debian
  shell server to Bullet, and after the upgrade ssh -X debian.eskimo.com
  from my workstation nanook.eskimo.com ceased to function.  It simply
  says "Cannot open DISPLAY".  At the time, all the others continued to
  work.  Today, when I went to do upgrades, now ssh -X is forwarding
  across the board to all flavors of Linux.  I did an ssh -V, nothing
  obvious wrong in the connection.

  debug1: Authentications that can continue: publickey,password
  debug1: Next authentication method: publickey
  debug1: Offering public key: /home/nanook/.ssh/id_rsa RSA 
SHA256:a5bReJXl7L91eGOuCYugHsY2rn2a0WTDXEBTC93YdmA agent
  debug1: Server accepts key: /home/nanook/.ssh/id_rsa RSA 
SHA256:a5bReJXl7L91eGOuCYugHsY2rn2a0WTDXEBTC93YdmA agent
  debug1: Authentication succeeded (publickey).
  Authenticated to igloo.eskimo.com ([204.122.16.128]:22).
  debug1: channel 0: new [client-session]
  debug1: Requesting no-more-sessi...@openssh.com
  debug1: Entering interactive session.
  debug1: pledge: network
  debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0
  debug1: Remote: /home/nanook/.ssh/authorized_keys:1: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding
  debug1: Remote: /home/nanook/.ssh/authorized_keys:1: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding
  debug1: Sending environment.
  debug1: Sending env LANG = en_US.UTF-8
  debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
  debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0
  debug1: channel 0: free: client-session, nchannels 1
  debug1: fd 2 clearing O_NONBLOCK
  Connection to igloo.eskimo.com closed.
  Transferred: sent 3748, received 3820 bytes, in 6.4 seconds
  Bytes per second: sent 589.4, received 600.8

  I don't see anything obviously wrong here but still it does not work, I get:
  xclock
  Error: Can't open display:

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: ssh (not installed)
  Uname: Linux 5.13.19 x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: MATE
  Date: Tue Nov  2 17:31:14 2021
  SourcePackage: openssh
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-10-14 Thread Paride Legovini
Bionic verification done according to the [Test Plan].

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

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

Bug description:
  [Impact]

  dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
  empty answer for a domain it is authoritative for. systemd-resolved
  seems to get confused by this in certain circumstances; when using the
  stub resolver and requesting an address for which there are no 
  records, there can sometimes be a five second hang in resolution.

  [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS

  [Test Plan]

  Test case for bionic:

  -
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # returns "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't.
  # does so with the -proposed package.
  -

  [Where problems could occur]

  Problems may occur in case a client queries dnsmasq and relies on
  EDNS0 not being available for behaving correctly. This covers cases
  where the software querying dnsmasq is buggy or misconfigured.

  [Development Fix]

  Fixed upstream in dnsmasq >= 2.80.

  [Stable Fix]

  Partial cherry-pick of upstream commit
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  The cherry-pick is partial because half if it is already in the
  package .diff we have in Bionic.

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


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


[Touch-packages] [Bug 1896251] Re: rsync --delete-missing-args fails with "error: protocol incompatibility"

2021-10-14 Thread Paride Legovini
** Tags added: server-todo

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

Title:
  rsync --delete-missing-args fails with "error: protocol
  incompatibility"

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Xenial:
  Won't Fix
Status in rsync source package in Bionic:
  Triaged
Status in rsync source package in Focal:
  Triaged

Bug description:
  Running

 rsync --delete-missing-args --files-from=...

  fails with error message like

  ABORTING due to invalid path from sender: dir1/dir2/dir3
  rsync error: protocol incompatibility (code 2) at generator.c(1271) 
[generator=3.1.2]

  if the listed directories are trying to delete full subtree of files.

  According to https://bugzilla.samba.org/show_bug.cgi?id=12569 this has
  been fixed in version 3.2.2.

  See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863334

  Could you update the rsync package or backport the fix?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: rsync 3.1.2-2.1ubuntu1.1
  ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-lowlatency 5.4.55
  Uname: Linux 5.4.0-47-lowlatency x86_64
  ApportVersion: 2.20.9-0ubuntu7.17
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Fri Sep 18 18:27:53 2020
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2019-01-05 (621 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1896251] Re: rsync --delete-missing-args fails with "error: protocol incompatibility"

2021-10-14 Thread Paride Legovini
Still a valid bug for Bionic and Focal, updating the other tasks.

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

** Changed in: rsync (Ubuntu Xenial)
   Status: Triaged => Won't Fix

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

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

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

Title:
  rsync --delete-missing-args fails with "error: protocol
  incompatibility"

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Xenial:
  Won't Fix
Status in rsync source package in Bionic:
  Triaged
Status in rsync source package in Focal:
  Triaged

Bug description:
  Running

 rsync --delete-missing-args --files-from=...

  fails with error message like

  ABORTING due to invalid path from sender: dir1/dir2/dir3
  rsync error: protocol incompatibility (code 2) at generator.c(1271) 
[generator=3.1.2]

  if the listed directories are trying to delete full subtree of files.

  According to https://bugzilla.samba.org/show_bug.cgi?id=12569 this has
  been fixed in version 3.2.2.

  See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863334

  Could you update the rsync package or backport the fix?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: rsync 3.1.2-2.1ubuntu1.1
  ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-lowlatency 5.4.55
  Uname: Linux 5.4.0-47-lowlatency x86_64
  ApportVersion: 2.20.9-0ubuntu7.17
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Fri Sep 18 18:27:53 2020
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2019-01-05 (621 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-10-14 Thread Paride Legovini
I retriggered those two tests and they passed.

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

Bug description:
  [Impact]

  dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
  empty answer for a domain it is authoritative for. systemd-resolved
  seems to get confused by this in certain circumstances; when using the
  stub resolver and requesting an address for which there are no 
  records, there can sometimes be a five second hang in resolution.

  [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS

  [Test Plan]

  Test case for bionic:

  -
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # returns "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't.
  # does so with the -proposed package.
  -

  [Where problems could occur]

  Problems may occur in case a client queries dnsmasq and relies on
  EDNS0 not being available for behaving correctly. This covers cases
  where the software querying dnsmasq is buggy or misconfigured.

  [Development Fix]

  Fixed upstream in dnsmasq >= 2.80.

  [Stable Fix]

  Partial cherry-pick of upstream commit
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  The cherry-pick is partial because half if it is already in the
  package .diff we have in Bionic.

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


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


[Touch-packages] [Bug 1641919] Re: hibernation has stopped working in 16.10 Yakkety Yak

2021-10-13 Thread Paride Legovini
This bug was last reported happening in Ubuntu 17.10, which is EOL,
while Ubuntu 16.04 reached end of standard support, and this bug doesn't
qualify for it.

I'm marking this bug report as Incomplete for the moment; if anybody can
confirm that Ubuntu >= Bionic is still affected by this please chime in
and we'll look at this again. Thanks!

** Changed in: nouveau-firmware (Ubuntu)
   Status: Confirmed => Incomplete

** Changed in: pm-utils (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  hibernation has stopped working in 16.10 Yakkety Yak

Status in nouveau-firmware package in Ubuntu:
  Incomplete
Status in pm-utils package in Ubuntu:
  Incomplete

Bug description:
  After upgrading to 16.10 (from 16.04) hibernation has stopped working.
  I've been using hibernation for years already without problems (with
  some initial tuning).

  I am talking about using "pm-hibernate"

  There is a workaround to make it work I've described here:
  http://askubuntu.com/a/849679/208566

  Also, there are some warnings while updating initramfs, which had not been 
present before:
  
  sudo update-initramfs -u
  update-initramfs: Generating /boot/initrd.img-4.8.0-27-generic
  W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for 
module i915
  W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module 
i915
  

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: ubuntu-release-upgrader-core 1:16.10.8
  ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1
  Uname: Linux 4.8.0-27-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8
  Architecture: amd64
  CrashDB: ubuntu
  CurrentDesktop: XFCE
  Date: Tue Nov 15 12:19:19 2016
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-11-06 (374 days ago)
  InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
  PackageArchitecture: all
  SourcePackage: ubuntu-release-upgrader
  Symptom: dist-upgrade
  UpgradeStatus: Upgraded to yakkety on 2016-11-12 (3 days ago)
  VarLogDistupgradeTermlog:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nouveau-firmware/+bug/1641919/+subscriptions


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


[Touch-packages] [Bug 1659950] Re: rsync -u --inplace --partial -a can't resume transfer

2021-10-07 Thread Paride Legovini
Thanks Nahuel! We're doing some retriage and cleanup of old bugs, and I
stumbled on this one :-)

I linked your upstream bug report to this bug, Launchpad will keep its
status in sync. You may have noticed that I didn't set the status of
this bug to Wontfix but to Opinion ("Doesn't fit with the project, but
can be discussed"), I think it fits better.

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

Title:
  rsync -u --inplace --partial -a can't resume transfer

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Opinion

Bug description:
  Suppose you have a file in hostA:

hostA$ ls -l /tmp/files
 -rw-rw-r-- 2 root root 563016 Jan 10 15:01 test.txt

  You download it from the hostB using:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  If the transfer is aborted, hostB will get only a partial file:

hostB$ ls -l /tmp/files
 -rw-rw-r-- 2 root root   2024 Jan 11 18:00 test.txt

  BUT the ctime/mtime of hostB/test.txt now is NEWER than hostA/test.txt(and 
mtime == ctime). So, if you run the same rsync -u command again:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  Rsync will SKIP THE FILE, because hostB/test.txt is "newer" than
  hostA/test.txt. So you CAN'T resume using rsync -u command, and you
  will think there are no differences.

  To avoid this bug, rsync must create the file with ctime=mtime=0. And
  if the file already exists before transfer, rsync -u must not change
  his current ctime/mtime. Ctime/mtime must be updated ONLY after the
  transfer was successfully completed.

  Note this is really need because there are scenarios where checksum
  comparison can't be used, only comparison by time. For example, to
  avoid deleting changes made in hostB to test.txt. Also I need to use
  --inplace.

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


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


[Touch-packages] [Bug 1659950] Re: rsync -u --inplace --partial -a can't resume transfer

2021-10-06 Thread Paride Legovini
** Also affects: rsync via
   https://github.com/WayneD/rsync/issues/236
   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/1659950

Title:
  rsync -u --inplace --partial -a can't resume transfer

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Opinion

Bug description:
  Suppose you have a file in hostA:

hostA$ ls -l /tmp/files
 -rw-rw-r-- 2 root root 563016 Jan 10 15:01 test.txt

  You download it from the hostB using:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  If the transfer is aborted, hostB will get only a partial file:

hostB$ ls -l /tmp/files
 -rw-rw-r-- 2 root root   2024 Jan 11 18:00 test.txt

  BUT the ctime/mtime of hostB/test.txt now is NEWER than hostA/test.txt(and 
mtime == ctime). So, if you run the same rsync -u command again:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  Rsync will SKIP THE FILE, because hostB/test.txt is "newer" than
  hostA/test.txt. So you CAN'T resume using rsync -u command, and you
  will think there are no differences.

  To avoid this bug, rsync must create the file with ctime=mtime=0. And
  if the file already exists before transfer, rsync -u must not change
  his current ctime/mtime. Ctime/mtime must be updated ONLY after the
  transfer was successfully completed.

  Note this is really need because there are scenarios where checksum
  comparison can't be used, only comparison by time. For example, to
  avoid deleting changes made in hostB to test.txt. Also I need to use
  --inplace.

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


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


[Touch-packages] [Bug 1659950] Re: rsync -u --inplace --partial -a can't resume transfer

2021-10-06 Thread Paride Legovini
Hello Nahuel,

According to your reasoning I assume the "root" issue should still
affect the versions of rsync shipped with the newer Ubuntu releases.

I agree it would be nice for the behavior you describe to be documented,
but I don't think it's worth patching the Ubuntu package for it. I
recognize we have a papercut here, but I don't think the fix for it
belongs to Ubuntu; it should instead be driven (and thus also validated)
upstream. For this reason I'm marking this bug as a Won't Fix. Should
you disagree with my assessment please comment back and set the bug
status back to New, we'll look at it again. Thanks!

** Changed in: rsync (Ubuntu)
   Status: Triaged => Opinion

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

Title:
  rsync -u --inplace --partial -a can't resume transfer

Status in rsync package in Ubuntu:
  Opinion

Bug description:
  Suppose you have a file in hostA:

hostA$ ls -l /tmp/files
 -rw-rw-r-- 2 root root 563016 Jan 10 15:01 test.txt

  You download it from the hostB using:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  If the transfer is aborted, hostB will get only a partial file:

hostB$ ls -l /tmp/files
 -rw-rw-r-- 2 root root   2024 Jan 11 18:00 test.txt

  BUT the ctime/mtime of hostB/test.txt now is NEWER than hostA/test.txt(and 
mtime == ctime). So, if you run the same rsync -u command again:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  Rsync will SKIP THE FILE, because hostB/test.txt is "newer" than
  hostA/test.txt. So you CAN'T resume using rsync -u command, and you
  will think there are no differences.

  To avoid this bug, rsync must create the file with ctime=mtime=0. And
  if the file already exists before transfer, rsync -u must not change
  his current ctime/mtime. Ctime/mtime must be updated ONLY after the
  transfer was successfully completed.

  Note this is really need because there are scenarios where checksum
  comparison can't be used, only comparison by time. For example, to
  avoid deleting changes made in hostB to test.txt. Also I need to use
  --inplace.

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


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


[Touch-packages] [Bug 1608965] Re: ssh GSSAPI rekey failure

2021-10-06 Thread Paride Legovini
Yakkety reached EOL, while Xenial is now in Extended Security
Maintenance, and this bug doesn't qualify for it, so this bug won't be
fixed in those releases.

** Changed in: openssh (Ubuntu Xenial)
   Status: Triaged => Won't Fix

** Changed in: openssh (Ubuntu Yakkety)
   Status: Triaged => Won't Fix

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

Title:
  ssh GSSAPI rekey failure

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Xenial:
  Won't Fix
Status in openssh source package in Yakkety:
  Won't Fix

Bug description:
  If I have ssh set up using GSSAPI with rekeying enabled, then the
  connection fails on rekey, and tries to do host-based verification
  'mid-session'.

  Steps to reproduce:

  $ ssh -vvv server.example.com
  
  debug1: Authenticating to ssh.example.com:22 as 'user'
  
  debug2: local client KEXINIT proposal
  debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group1-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
  
  debug2: peer server KEXINIT proposal
  debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
  
  Last login: Tue Aug 02 10:47:20 2016 from foo

  # Then do 'kinit' on the client to get a new ticket...

  debug1: need rekeying
  debug1: SSH2_MSG_KEXINIT sent
  debug1: rekeying in progress
  debug1: SSH2_MSG_KEXINIT received
  debug2: local client KEXINIT proposal
  debug2: KEX algorithms: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
  debug2: host key algorithms: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,null
  [...]
  debug2: peer server KEXINIT proposal
  debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
  [...]
  debug1: kex: algorithm: curve25519-sha...@libssh.org
  debug1: kex: host key algorithm: ecdsa-sha2-nistp256
  debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
  debug1: rekeying in progress
  debug1: rekeying in progress
  debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:w7yxbCZNBX4d5EAgmCrFYa3XUpDjvWiDOw4/YOY9q8E
  The authenticity of host 'server.example.com (10.0.0.1)' can't be established.
  ECDSA key fingerprint is SHA256:w7yxbCZNBX4d5EAgmCrFYa3XUpDjvWiDOw4/YOY9q8E.
  Are you sure you want to continue connecting (yes/no)? 
  Host key verification failed.

  It looks like the list of KEX algorithms differs between the initial
  connection, and the rekeying.

  This behaviour seems to occur with a client running 16.04 (openssh-
  client 1:7.2p2-4ubuntu1) but not on 15.10 (openssh-client
  1:6.9p1-2ubuntu0.2).

  ssh_config is as follows:

  HashKnownHosts no
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes
  GSSAPIRenewalForcesRekey yes
  GSSAPITrustDNS yes
  GSSAPIKeyExchange yes
  ForwardX11 yes
  ForwardX11Trusted yes

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


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


[Touch-packages] [Bug 1618719] Re: scp1 reports ssh1 is not supported

2021-10-06 Thread Paride Legovini
Xenial is now in Extended Security Maintenance and this bug doesn't
qualify for it, so this bug won't be fixed in that release.

** Changed in: openssh (Ubuntu Xenial)
   Status: Triaged => Won't Fix

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

Title:
  scp1 reports ssh1 is not supported

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Xenial:
  Won't Fix

Bug description:
  For getting ssh protocol 1 support I installed the package 
openssh-client-ssh1.
  This works with .ssh/config host entries, when omitting any "Protocol 1" 
lines, but calling "ssh1 -1 host".
  This package also has the command scp1 included, but this command doesn't 
have ssh protocol 1 support:
  > corben@ubuntu:~$ scp1 -1 host:/path/to/file .
  > ssh1 is not supported
  Is the ssh protocol 1 support not included for scp1 during compile time?

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


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


[Touch-packages] [Bug 1645002] Re: ssh sessions are not cleanly terminated on shutdown/restart with systemd

2021-10-06 Thread Paride Legovini
Xenial is now in Extended Security Maintenance and this bug doesn't
qualify for it, so the bugfix won't be SRUed there.

** Changed in: openssh (Ubuntu Xenial)
   Status: Triaged => Won't Fix

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

Title:
  ssh sessions are not cleanly terminated on shutdown/restart with
  systemd

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Xenial:
  Won't Fix
Status in openssh source package in Yakkety:
  Fix Released
Status in openssh package in Debian:
  Fix Released

Bug description:
  In Ubuntu 16.04, a "reboot" command does not terminate the ssh
  session. This results in clients hanging, until timing out (sometimes
  as much as 120 seconds).

  This also introduces bugs to all  orchestration / automation tools which work 
over SSH, since they cannot issue their reboot equivalent for Ubuntu 16.04 
hosts. For example, have a look at this issue for Fabric:
  https://github.com/fabric/fabric/issues/1488

  The exact same bug has been fixed in Debian in version openssh/1:7.2p2-6. 
  There is a very detailed discussion in their bug tracker:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636

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


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


[Touch-packages] [Bug 1651044] Re: ProxyDHCP replies on invalid range

2021-10-06 Thread Paride Legovini
Hi,

I had a look at [1] and AIUI this wasn't recognized as an upstream bug.
I also can't find a relevant Debian bug about this issue. The bug
description says it affected Xenial, which is now in Extended Security
Maintenance, so it's a Won't Fix there.

For >= Bionic we need confirmation from an affected user the bug is
still present and valid. Waiting for feedback I'm marking this bug
report as Incomplete.

[1] https://lists.thekelleys.org.uk/pipermail/dnsmasq-
discuss/2016q4/011010.html

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

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

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

Title:
  ProxyDHCP replies on invalid range

Status in dnsmasq package in Ubuntu:
  Incomplete

Bug description:
  In Ubuntu 16.04, I've configured dnsmasq to reply on subnet=10.160.37.0/24, 
yet it replies even when it gets an IP on subnet=10.161.254.0/24.
  I've only seen this after clean system restart. If I restart dnsmasq later 
on, it works as expected.
  Maybe when dnsmasq starts, the network isn't up yet, and it incorrectly 
initializes some networking information? I'm using network-manager with DHCP.

  Details:
  $ egrep -rv '^#|^$' /etc/dnsmasq.*
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.37.0,proxy
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,"Linux ipconfig"
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:pxe-service=X86PC, "Boot from 
network", /ltsp/i386/pxelinux

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  2: enp2s0:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether d0:50:99:a6:bc:0a brd ff:ff:ff:ff:ff:ff
  inet 10.161.254.185/24 brd 10.161.254.255 scope global dynamic enp2s0
 valid_lft 431873sec preferred_lft 431873sec
  inet6 fe80::f363:c1e2:9cb8:d9e2/64 scope link 
 valid_lft forever preferred_lft forever

  $ sudo netstat -nap | grep dnsmasq
  [sudo] password for administrator: 
  tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN
  843/dnsmasq 
  tcp6   0  0 :::53   :::*LISTEN
  843/dnsmasq 
  udp0  0 0.0.0.0:53  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:67  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:69  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:40110.0.0.0:* 
  843/dnsmasq 
  udp6   0  0 :::53   :::*  
  843/dnsmasq 
  udp6   0  0 :::69   :::*  
  843/dnsmasq 
  unix  2  [ ] DGRAM15746843/dnsmasq
 

  $ grep dnsmasq /var/log/syslog | tail -n 30
  Dec 19 10:52:17 ltsp-server systemd[1]: Starting dnsmasq - A lightweight DHCP 
and caching DNS server...
  Dec 19 10:52:17 ltsp-server dnsmasq[630]: dnsmasq: syntax check OK.
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: started, version 2.75 cachesize 150
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: compile time options: IPv6 
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC 
loop-detect inotify
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: DNS service limited to local subnets
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, IP range 192.168.67.20 
-- 192.168.67.250, lease time 8h
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, proxy on subnet 
10.160.37.0
  Dec 19 10:52:20 ltsp-server dnsmasq-tftp[843]: TFTP root is /var/lib/tftpboot/
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: no servers found in 
/var/run/dnsmasq/resolv.conf, 

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-10-06 Thread Paride Legovini
The MP got reviewed and the dnsmasq upload is currently waiting in the
Bionic unapproved queue.

Being a format 1.0 package the diff [1] looks huge at first glance, but
the real changes are actually very limited (those in the MP).

[1]
https://launchpadlibrarian.net/560828569/dnsmasq_2.79-1ubuntu0.5.diff.gz

** Merge proposal linked:
   
https://code.launchpad.net/~paride/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/409149

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

Bug description:
  [Impact]

  dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
  empty answer for a domain it is authoritative for. systemd-resolved
  seems to get confused by this in certain circumstances; when using the
  stub resolver and requesting an address for which there are no 
  records, there can sometimes be a five second hang in resolution.

  [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS

  [Test Plan]

  Test case for bionic:

  -
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # returns "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't.
  # does so with the -proposed package.
  -

  [Where problems could occur]

  Problems may occur in case a client queries dnsmasq and relies on
  EDNS0 not being available for behaving correctly. This covers cases
  where the software querying dnsmasq is buggy or misconfigured.

  [Development Fix]

  Fixed upstream in dnsmasq >= 2.80.

  [Stable Fix]

  Partial cherry-pick of upstream commit
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  The cherry-pick is partial because half if it is already in the
  package .diff we have in Bionic.

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


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


[Touch-packages] [Bug 1849560] Re: Please revise the files installed in /etc/

2021-10-05 Thread Paride Legovini
I share Christian's concern on nobody actually caring about this. Given
the absence of activity in >1 year I'm marking this bug as Incomplete,
which is an invite for anybody interested to chime in.

In absence of feedback I doubt there will be any progress here, as the
direction to take isn't fully clear, and from our point of view the
openssh packages are behaving as expected.

** Changed in: openssh (Ubuntu)
   Status: Triaged => 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/1849560

Title:
  Please revise the files installed in /etc/

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  openssh-server and openssh-client install various files under /etc:

  /etc/ssh/*
  /etc/systemd/system/sshd.service

  Please see if these files can be moved elsewhere, in accordance with
  FHS: /etc should only contain files writable by the system
  administrator, and in Ubuntu Core 20 we should aim to have no writable
  files in /etc (as it will be included in images, avoid conflict
  resolution on upgrades).

  At a glance, it looks like /etc/systemd/system/sshd.service could be
  moved to /lib/systemd/system, and many of the files in /etc/ssh do
  have suitable locations elsewhere on the system, such as /var/lib/ for
  generated keys, /usr/share/ for default SSH configurations, etc.)

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


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


[Touch-packages] [Bug 1432935] Re: ntpd -x steps clock on leap second (upstream bug: 2745)

2021-10-05 Thread Paride Legovini
Trusty is now in Extended Security Maintenance [1], and this bug doesn't
qualify for it, so it won't be fixed in that release.

[1] https://wiki.ubuntu.com/Releases

** Changed in: ntp (Ubuntu Trusty)
   Status: New => Won't Fix

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

Title:
  ntpd -x steps clock on leap second (upstream bug: 2745)

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  Won't Fix

Bug description:
  in http://bugs.ntp.org/show_bug.cgi?id=2745
   | With older versions it was possible to use the -x option to avoid upsetting
   | applications running on the system when the clock is stepped due to a leap
   | second.
   | 
   | It seems in 4.2.6 was added support for inserting/deleting leap seconds on
   | systems without kernel discipline. However, the clock is now stepped even 
when
   | the -x option or tinker step is used to disable stepping.

  I'm not sure this bug could affect Ubuntu's ntp packages, but I
  believe that this information is IMPORTANT for some ubuntu users.

  Note: This bug is copied from
  https://rhn.redhat.com/errata/RHBA-2015-0690.html, thanks Red Hat.

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


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


[Touch-packages] [Bug 1945787] Re: heimdal: fails to build, symbols don't match

2021-10-04 Thread Paride Legovini
Thanks for this bug report; I can reproduce the issue and will prepare
an upload with your debdiff.

** Changed in: heimdal (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

** Tags added: server-next

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

Title:
  heimdal: fails to build, symbols don't match

Status in heimdal package in Ubuntu:
  New

Bug description:
  heimdal 7.7.0+dfsg-2ubuntu1 fails to build with

  dpkg-gensymbols: warning: debian/libroken18-heimdal/DEBIAN/symbols doesn't 
match completely debian/libroken18-heimdal.symbols
  --- debian/libroken18-heimdal.symbols 
(libroken18-heimdal_7.7.0+dfsg-2ubuntu1_riscv64)
  +++ dpkg-gensymbolsYtlvSr   2021-10-01 12:31:59.102451503 +
  @@ -42,7 +42,7 @@
rk_cloexec_dir@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_cloexec_file@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_cloexec_socket@HEIMDAL_ROKEN_1.0 1.6~git20131117
  - rk_closefrom@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  +#MISSING: 7.7.0+dfsg-2ubuntu1# rk_closefrom@HEIMDAL_ROKEN_1.0 
1.4.0+git20110226
rk_copyhostent@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_dns_free_data@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_dns_lookup@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  dh_makeshlibs: error: failing due to earlier errors

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


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


[Touch-packages] [Bug 1922130] Re: Request addition of Fedora / Redhat "sftp-force-permissions" patch

2021-10-04 Thread Paride Legovini
** Bug watch added: OpenSSH Portable Bugzilla #1844
   https://bugzilla.mindrot.org/show_bug.cgi?id=1844

** Also affects: openssh via
   https://bugzilla.mindrot.org/show_bug.cgi?id=1844
   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/1922130

Title:
  Request addition of Fedora / Redhat "sftp-force-permissions" patch

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh package in Debian:
  Confirmed

Bug description:
  Fedora / Redhat ships openssh with a patch which adds "-m force
  permission" flag to sftp-server.

  This is quite a common feature request / support request on the
  various stackexchange sites -
  https://superuser.com/questions/332284/in-sftp-how-to-set-the-default-
  permission-for-all-files-in-a-folder

  You will see that someone has answered "add -m" there which is indeed
  the simplest answer by a distance but unfortunately it's a non
  standard patch:

  https://src.fedoraproject.org/rpms/openssh/blob/f34/f/openssh-6.7p1-sftp-
  force-permission.patch

  This I think should supersede #563216 because they have been shipping
  this in production presumably since at least 2015 (I see it in fedora
  22 branch), so it is a known stable patch compared to the one
  suggested there.

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


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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-09-29 Thread Paride Legovini
MP to fix this bug in Bionic, already reviewed and uploaded:

https://code.launchpad.net/~paride/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/409149

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

Bug description:
  [Impact]

  dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
  empty answer for a domain it is authoritative for. systemd-resolved
  seems to get confused by this in certain circumstances; when using the
  stub resolver and requesting an address for which there are no 
  records, there can sometimes be a five second hang in resolution.

  [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS

  [Test Plan]

  Test case for bionic:

  -
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # returns "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't.
  # does so with the -proposed package.
  -

  [Where problems could occur]

  Problems may occur in case a client queries dnsmasq and relies on
  EDNS0 not being available for behaving correctly. This covers cases
  where the software querying dnsmasq is buggy or misconfigured.

  [Development Fix]

  Fixed upstream in dnsmasq >= 2.80.

  [Stable Fix]

  Partial cherry-pick of upstream commit
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  The cherry-pick is partial because half if it is already in the
  package .diff we have in Bionic.

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


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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-09-24 Thread Paride Legovini
I dropped the verification-* as there were about the systemd SRU, while
I'm preparing the dnsmasq one at the moment.

** Description changed:

  [Impact]
- dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.
  
- [Fix]
- This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
+ dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
+ empty answer for a domain it is authoritative for. systemd-resolved
+ seems to get confused by this in certain circumstances; when using the
+ stub resolver and requesting an address for which there are no 
+ records, there can sometimes be a five second hang in resolution.
  
- Not sure if it is worth cherry picking? I imagine the most likely
- trigger will be dnsmasq on routers which are not likely to be running
- Ubuntu, but maybe just in case.
+ [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS
  
- I also think there are some logic issues in systemd-resolved, upstream
- bug filed:
+ [Test Plan]
  
- https://github.com/systemd/systemd/issues/9785
+ Test case for bionic:
  
- [Test Case]
- Simple-ish test case for bionic:
- 
- ---
+ -
  IFACE=dummy0
  SUBNET=10.0.0
  
  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &
  
  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
- ---
+ -
  
- To reproduce the systemd-resolved side of the problem
+ [Where problems could occur]
  
- ---
- # as above, but
- # now configure systemd-resolved to look at only 10.0.0.1, then
+ Problems may occur in case a client queries dnsmasq and relies on EDNS0
+ not being available for behaving correctly. This covers cases where the
+ software querying dnsmasq is buggy or misconfigured.
  
- systemd-resolve --reset-server-features
- # should exhibit five second delay then connect, assuming sshd is running :)
- ssh test.test
- ---
+ [Development Fix]
  
+ Fixed upstream in dnsmasq >= 2.80.
  
- More detailed test case for focal and later:
+ [Stable Fix]
  
- install dnsmasq on a bionic system and start it, listening to an
- interface that is externally reachable, e.g. for a normal libvirt vm
- with interface name 'ens3':
+ Partial cherry-pick of upstream commit
+ 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
  
- IFACE=ens3
- dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/
- 
- note that the '1.2.3.4' address doesn't matter, any addr is ok.
- 
- then setup a test system that can reach the dnsmasq system, and
- configure networkd to use the dnsmasq server, e.g. using config like:
- 
- [Match]
- Name=ens3
- 
- [Network]
- DHCP=yes
- DNS=DNSMASQ_IP_ADDRESS
- Domains=test
- 
- [DHCPv4]
- UseDNS=no
- UseDomains=no
- 
- replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
- dnsmasq is running, and replace 'ens3' with whatever the test system
- interface name is. Then restart systemd-networkd, and test:
- 
- systemd-resolve --reset-server-features
- systemd-resolve --flush-caches
- host test.test
- 
- The lookup using 'host' should complete immediately;.
- 
- [Discussion]
- ProblemType: Bug
- DistroRelease: Ubuntu 18.04
- Package: dnsmasq-base 2.79-1
- ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
- Uname: Linux 4.15.0-23-generic x86_64
- ApportVersion: 2.20.9-0ubuntu7.2
- Architecture: amd64
- Date: Sat Aug  4 11:33:56 2018
- InstallationDate: Installed on 2018-05-31 (64 days ago)
- InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
- ProcEnviron:
-  TERM=xterm
-  PATH=(custom, no user)
-  LANG=en_GB.UTF-8
-  SHELL=/bin/bash
- SourcePackage: dnsmasq
- UpgradeStatus: No upgrade log present (probably fresh install)
+ The cherry-pick is partial because half if it is already in the package
+ .diff we have in Bionic.

** Tags removed: verification-done verification-done-bionic
verification-done-focal verification-done-groovy verification-done-
hirsute

** Description changed:

  [Impact]
  
  dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
  empty answer for a domain it is authoritative for. systemd-resolved
  seems to get confused by this in certain circumstances; when using the
  stub resolver and requesting an address for which there are no 
  records, there can sometimes be a five second hang in 

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-09-24 Thread Paride Legovini
** Changed in: dnsmasq (Ubuntu Bionic)
   Status: Triaged => In Progress

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

Bug description:
  [Impact]
  dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

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

  [Test Case]
  Simple-ish test case for bionic:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  
  More detailed test case for focal and later:

  install dnsmasq on a bionic system and start it, listening to an
  interface that is externally reachable, e.g. for a normal libvirt vm
  with interface name 'ens3':

  IFACE=ens3
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/

  note that the '1.2.3.4' address doesn't matter, any addr is ok.

  then setup a test system that can reach the dnsmasq system, and
  configure networkd to use the dnsmasq server, e.g. using config like:

  [Match]
  Name=ens3

  [Network]
  DHCP=yes
  DNS=DNSMASQ_IP_ADDRESS
  Domains=test

  [DHCPv4]
  UseDNS=no
  UseDomains=no

  replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
  dnsmasq is running, and replace 'ens3' with whatever the test system
  interface name is. Then restart systemd-networkd, and test:

  systemd-resolve --reset-server-features
  systemd-resolve --flush-caches
  host test.test

  The lookup using 'host' should complete immediately;.

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-23 Thread Paride Legovini
Reminds me of LP: #1943049. I mentioned this bug there, as we should
make sure that close_range doesn't bring us back to that same issue.

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

Title:
  Please backport support for "close_range" syscall

Status in libseccomp package in Ubuntu:
  New

Bug description:
  Please backport support for the "close_range" syscall .. may be as
  simple as cherrypicking

  
https://github.com/seccomp/libseccomp/commit/01e5750e7c84bb14e5a5410c924bed519209db06

  from upstream. I've hit problems running buildah in a systemd-nspawn
  container, but this will probably affect people trying to run modern
  code in other container systems as well, e.g. docker.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libseccomp2 2.5.1-1ubuntu1~20.04.1
  ProcVersionSignature: Ubuntu 5.4.0-84.94-generic 5.4.133
  Uname: Linux 5.4.0-84-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.20
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: Xpra
  Date: Tue Sep 21 15:10:54 2021
  InstallationDate: Installed on 2017-01-08 (1717 days ago)
  InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  SourcePackage: libseccomp
  UpgradeStatus: Upgraded to focal on 2021-09-02 (19 days ago)

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


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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-09-23 Thread Paride Legovini
The only task that remains to tackled here is dnsmasq on Bionic.

By following the [Test Case] I verified that applying [1] fixes the bug
in Bionic. The first two hunks of the patch are already applied in the
Ubuntu package, what remains to apply is in the attached patch.

[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

** Patch added: "lp1785383-dnsmasq-bionic.patch"
   
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1785383/+attachment/5527343/+files/lp1785383-dnsmasq-bionic.patch

** Changed in: dnsmasq (Ubuntu Bionic)
 Assignee: (unassigned) => Paride Legovini (paride)

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

Title:
  missing EDNS0 record confuses systemd-resolved

Status in systemd:
  Fix Released
Status in dnsmasq package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Bionic:
  Triaged
Status in systemd source package in Bionic:
  Fix Released
Status in dnsmasq source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in dnsmasq source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in dnsmasq source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in dnsmasq source package in Impish:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

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

  [Test Case]
  Simple-ish test case for bionic:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  
  More detailed test case for focal and later:

  install dnsmasq on a bionic system and start it, listening to an
  interface that is externally reachable, e.g. for a normal libvirt vm
  with interface name 'ens3':

  IFACE=ens3
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/

  note that the '1.2.3.4' address doesn't matter, any addr is ok.

  then setup a test system that can reach the dnsmasq system, and
  configure networkd to use the dnsmasq server, e.g. using config like:

  [Match]
  Name=ens3

  [Network]
  DHCP=yes
  DNS=DNSMASQ_IP_ADDRESS
  Domains=test

  [DHCPv4]
  UseDNS=no
  UseDomains=no

  replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
  dnsmasq is running, and replace 'ens3' with whatever the test system
  interface name is. Then restart systemd-networkd, and test:

  systemd-resolve --reset-server-features
  systemd-resolve --flush-caches
  host test.test

  The lookup using 'host' should complete immediately;.

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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


-- 
Mailing l

[Touch-packages] [Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange

2021-09-16 Thread Paride Legovini
** Also affects: openssh (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

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

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

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

** Tags added: server-next

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

Title:
  monitor_read: unpermitted request 48 on server while attempting GSSAPI
  key exchange

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh source package in Focal:
  Triaged
Status in openssh source package in Hirsute:
  Triaged

Bug description:
  I'm using openssh 1:8.2p1-4ubuntu0.2 on Ubuntu 20.04.2 LTS (client and
  server) with the option "GSSAPIKeyExchange=yes", and this causes the
  connection to fail. The server has GSSAPI (Kerberos authentication)
  enabled, but is is only used for non-root users (root uses SSH keys).

  Client command:

  ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex
  root@server -v -p  -o GSSAPIKeyExchange=yes

  Client log:

  OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
  debug1: Reading configuration data /home/user/.ssh/config
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  debug1: Connecting to compute-test [130.75.80.46] port .
  debug1: Connection established.
  debug1: identity file /home/rother/.ssh/id_rsa type 0
  debug1: identity file /home/rother/.ssh/id_rsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_dsa type -1
  debug1: identity file /home/rother/.ssh/id_dsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa_sk type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa_sk-cert type -1
  debug1: identity file /home/rother/.ssh/id_ed25519 type -1
  debug1: identity file /home/rother/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/rother/.ssh/id_ed25519_sk type -1
  debug1: identity file /home/rother/.ssh/id_ed25519_sk-cert type -1
  debug1: identity file /home/rother/.ssh/id_xmss type -1
  debug1: identity file /home/rother/.ssh/id_xmss-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
  debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 
Ubuntu-4ubuntu0.2
  debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x0400
  debug1: Authenticating to server: as 'root'
  debug1: Offering GSSAPI proposal: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug1: kex: algorithm: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==
  debug1: kex: host key algorithm: ecdsa-sha2-nistp256
  debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: Doing group exchange
  debug1: Calling gss_init_sec_context
  debug1: Delegating credentials
  debug1: Received GSSAPI_COMPLETE
  debug1: Calling gss_init_sec_context
  debug1: Delegating credentials
  debug1: Rekey has happened - updating saved versions
  debug1: rekey out after 134217728 blocks
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug1: SSH2_MSG_NEWKEYS received
  debug1: rekey in after 134217728 blocks
  debug1: Will attempt key: /home/rother/.ssh/id_rsa RSA 
SHA256:n/EY/cGjgd/r+7JpuqODxIotHHLsYptGXYx9GlKCWSM agent
  debug1: Will attempt key: /home/rother/.ssh/root_id_rsa RSA 
SHA256:yCLAID9FMILharHmDpCB8wW8eiA+iHa4oQKLODbbzKw agent
  debug1: Will attempt key: /home/user/.ssh/id_dsa 
  debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
  debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk 
  debug1: Will attempt key: /home/user/.ssh/id_ed25519 
  debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk 
  debug1: Will attempt key: /home/user/.ssh/id_xmss 
  debug1: SSH2_MSG_EXT_INFO received
  debug1: kex_input_ext_info: 
server-sig-algs=
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next authentication method: gssapi-with-mic
  debug1: Delegating credentials
  debug1: Delegating credentials
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next 

[Touch-packages] [Bug 1778073] Re: dnsmasq and resolvconf hangs on start

2021-09-15 Thread Paride Legovini
Hi, I had another look at this one and Ciaby's analysis looks correct to
me, however I want to setup a full reproducer before attempting a fix. I
assigned the bug to myself.

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

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

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


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


[Touch-packages] [Bug 1778073] Re: dnsmasq and resolvconf hangs on start

2021-09-15 Thread Paride Legovini
** Changed in: dnsmasq (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

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

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

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


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


[Touch-packages] [Bug 1939940] Re: package openssh-server 1:8.2p1-4ubuntu0.3 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status

2021-08-17 Thread Paride Legovini
Hello and thanks for this bug report. By reading the bug description it
looks like there is an issue in your sshd_config:

SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit
code 255: /etc/ssh/sshd_config line 15: Badly formatted port number.

If sshd was working before it may be that the service wasn't restarted
after the breaking config change. The upgrade triggered a restart and
thus the failure.

I'm setting this bug report as Incomplete for now. Should you think that
this is actually a bug in Ubuntu and not a local configuration issue
please comment back providing your reasoning and a  sshd_config line
that reproduces the issue in a clean Ubuntu system.

On the other hand should you find out this is actually a local
configuration issue please set the status of this bug report to Invalid.
Thanks!

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

Title:
  package openssh-server 1:8.2p1-4ubuntu0.3 failed to install/upgrade:
  installed openssh-server package post-installation script subprocess
  returned error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  this happened during an update

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.2p1-4ubuntu0.3
  ProcVersionSignature: Ubuntu 5.11.0-25.27~20.04.1-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sat Aug 14 08:13:05 2021
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2020-11-11 (275 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.6
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: /etc/ssh/sshd_config line 15: Badly formatted port number.
  SourcePackage: openssh
  Title: package openssh-server 1:8.2p1-4ubuntu0.3 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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


[Touch-packages] [Bug 1939857] Re: package openssh-server 1:7.6p1-4ubuntu0.5 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status

2021-08-17 Thread Paride Legovini
Hello and thanks for your bug report. From the attached logs it seems
that you have syntax errors in your sshd_config

sshd[1556]: /etc/ssh/sshd_config: line 124: Bad configuration option: Host
sshd[1556]: /etc/ssh/sshd_config: line 125: Bad configuration option: 
ServerAliveInterval
sshd[1556]: /etc/ssh/sshd_config: terminating, 2 bad configuration options

If sshd was working before it may be that the service wasn't restarted
after the breaking config change. The upgrade triggered a restart and
thus the failure.

I'm setting this bug report as Incomplete for now. Should you think that
this is actually a bug in Ubuntu and not a local configuration issue
please comment back providing you reasoning ans possibly a minimal
sshd_config that reproduces the issue in a clean Ubuntu system.

On the other hand should you find out this is actually a local
configuration issue please set the status of this bug report to Invalid.
Thanks!

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

Title:
  package openssh-server 1:7.6p1-4ubuntu0.5 failed to install/upgrade:
  installed openssh-server package post-installation script subprocess
  returned error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ¯\_(ツ)_/¯

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: openssh-server 1:7.6p1-4ubuntu0.5
  ProcVersionSignature: Ubuntu 4.15.0-147.151-generic 4.15.18
  Uname: Linux 4.15.0-147-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.24
  Architecture: amd64
  Date: Fri Aug 13 08:12:44 2021
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2014-05-30 (2631 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.3
   apt  1.6.14
  SourcePackage: openssh
  Title: package openssh-server 1:7.6p1-4ubuntu0.5 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to bionic on 2019-01-28 (927 days ago)

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


-- 
Mailing list: https://launchpad.net/~touch-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

2021-08-09 Thread Paride Legovini
Fixing this properly is not straightforward.

* I'm -1 for calling configure-instance.sh when ca-certificates is
updated as that script is not meant do be run while postfix is running.
We can't be sure that changing the postfix environment without
restarting it won't have unexpected consequences. We could check the
script now, but we can't be sure of what it will do in the future.

* Even if configure-instance.sh is run, I think that at least a postfix
reload is needed to make it pick up the new certificates.

* Postfix only Recommends: ca-certificates, so when implementing the fix
we should take into account the fact that ca-certificates may not be
installed. This shouldn't really add complexity but it's something to
keep in mind.

* While a postfix restart should update the certificates in the chroot,
I agree that doing it automatically on ca-certificates update is too
invasive. (Moreover, while me and Simon found out that a restart works,
the linked debbug mentions it does not, so this should be double-
checked.)

* A solution would to fix this on the ca-certificates side, making ca-
certificates detect running services possibly needing a restart and
interactively asking to restart them. This is basically what e.g. glibc
and pam do, and the debconf logic could be taken from there. This
solution also has downsides: it's one more blocking debconf question,
and added interaction logic between packages without a dpkg relation (at
least not in the ca-certificates -> postfix direction). Ideally this
change should land in Debian.

In the end I think this should be fixed on the Postfix side by adding a
debconf question asking if postfix should be restarted on ca-
certificates updates, and dropping a script in /etc/ca-
certificates/update.d/ doing the restart if desired. This is also
something I'd like to see land in Debian and not in an Ubuntu delta.

I'm sorry for the wall-of-text :-)

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

** Changed in: postfix (Ubuntu)
 Assignee: Paride Legovini (paride) => (unassigned)

-- 
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:
  New
Status in postfix package in Ubuntu:
  Triaged
Status in postfix package in Debian:
  Unknown

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 1915238] Re: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

2021-08-09 Thread Paride Legovini
** Also affects: ca-certificates (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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:
  New
Status in postfix package in Ubuntu:
  Incomplete
Status in postfix package in Debian:
  Unknown

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 1931104] Re: Test of dogtag-pki is failing on s390x due to LTO

2021-08-08 Thread Paride Legovini
** Tags removed: server-next update-excuse

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

** Also affects: fedora via
   https://bugzilla.redhat.com/show_bug.cgi?id=1986627
   Importance: Unknown
   Status: Unknown

** Package changed: fedora => nss (Fedora)

** Changed in: nss (Ubuntu)
 Assignee: Paride Legovini (paride) => (unassigned)

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

Title:
  Test of dogtag-pki is failing on s390x due to LTO

Status in NSS:
  Unknown
Status in nss package in Ubuntu:
  Triaged
Status in nss package in Fedora:
  Unknown

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
  >>>> CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 T

[Touch-packages] [Bug 1856428] Re: Disable TLS below 1.2 by default

2021-07-27 Thread Paride Legovini
** Bug watch added: Debian Bug tracker #991562
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991562

** Also affects: nss via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991562
   Importance: Unknown
   Status: Unknown

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

Title:
  Disable TLS below 1.2 by default

Status in NSS:
  Unknown
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in golang-1.13 package in Ubuntu:
  New
Status in nss package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Disable TLS 1.0, TLS1.1, DTLS1.0

  As part of focal commitment, we shall disable obsolete protocols by
  default.

  Users can override this behaviour with a config file.

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


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


[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x due to LTO

2021-07-23 Thread Paride Legovini
MP for a merge from Debian which also disabled LTO via
DEB_BUILD_MAINT_OPTIONS=optimize=-lto:

https://code.launchpad.net/~paride/ubuntu/+source/nss/+git/nss/+merge/406163

** Summary changed:

- Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed
+ Test of dogtag-pki is failing on s390x due to LTO

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

Title:
  Test of dogtag-pki is failing on s390x due to LTO

Status in NSS:
  Unknown
Status in nss package in Ubuntu:
  Triaged

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x   

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-23 Thread Paride Legovini
All of the above still applies to nss 3.68-1, for which I'm preparing a
merge right now.

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in NSS:
  Unknown
Status in nss package in Ubuntu:
  Triaged

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server
  ii  libnss3:s390x  2:3.63-1ubuntu1 s390xNetwork Security Service 
libraries

  With this the install fail is reprodicible.
  So we can switch in/out bad 

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-23 Thread Paride Legovini
** Bug watch added: Mozilla Bugzilla #1721995
   https://bugzilla.mozilla.org/show_bug.cgi?id=1721995

** Also affects: nss via
   https://bugzilla.mozilla.org/show_bug.cgi?id=1721995
   Importance: Unknown
   Status: Unknown

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in NSS:
  Unknown
Status in nss package in Ubuntu:
  Triaged

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server
  ii  libnss3:s390x  

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-23 Thread Paride Legovini
I tracked the problem down to the LTO optimizations that were enabled by
default in dpkg 1.20.9ubuntu1.

** Changed in: nss (Ubuntu)
   Status: New => Triaged

** Tags added: lto

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in nss package in Ubuntu:
  Triaged

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server
  ii  libnss3:s390x  2:3.63-1ubuntu1 s390xNetwork Security Service 
libraries

  With 

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-21 Thread Paride Legovini
The good news is that the test passes when building nss in a Groovy lxd
container, but fails when copying that container (lxc copy), upgrading
the copy to Hirsute and rebuilding there, so I have good pair of
containers to do the "bisect" on.

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in nss package in Ubuntu:
  New

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server
  ii  libnss3:s390x  2:3.63-1ubuntu1 

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-21 Thread Paride Legovini
My plan is now to:

 - Setup a Groovy container
 - Build nss 2:3.61-1ubuntu2 and verify the libnss3 is good
 - Add Hirsute to sources.list and manually update the
   Build-Deps, starting from the usual suspects (compilers),
   hopefully finding which package breaks the dogtag-pki tests.

The testbed system will remain fixed (ubuntu:impish lxd container).

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in nss package in Ubuntu:
  New

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-21 Thread Paride Legovini
Diff of the sbuild Installed-Build-Depends from the "good" Hirsute build
that produced the nss packages now in the archive and a "bad" Hirsute
build done in an up-to-date Hirsute schroot:

--- good2021-07-21 12:02:03.870339411 +0200
+++ bad 2021-07-21 12:03:20.367850047 +0200
@@ -3,38 +3,39 @@
  automake (= 1:1.16.3-2ubuntu1),
  autopoint (= 0.21-3ubuntu2),
  autotools-dev (= 20180224.1+nmu1),
- base-files (= 11ubuntu16),
+ base-files (= 11ubuntu19),
  base-passwd (= 3.5.49),
- bash (= 5.1-1ubuntu1),
- binutils (= 2.36.1-0ubuntu1),
- binutils-common (= 2.36.1-0ubuntu1),
- binutils-s390x-linux-gnu (= 2.36.1-0ubuntu1),
- bsdextrautils (= 2.36.1-1ubuntu2),
- bsdutils (= 1:2.36.1-1ubuntu2),
+ bash (= 5.1-2ubuntu1),
+ binutils (= 2.36.1-6ubuntu1),
+ binutils-common (= 2.36.1-6ubuntu1),
+ binutils-s390x-linux-gnu (= 2.36.1-6ubuntu1),
+ bsdextrautils (= 2.36.1-7ubuntu2),
+ bsdutils (= 1:2.36.1-7ubuntu2),
  build-essential (= 12.8ubuntu3),
- bzip2 (= 1.0.8-4ubuntu2),
+ bzip2 (= 1.0.8-4ubuntu3),
  coreutils (= 8.32-4ubuntu2),
- cpp (= 4:10.2.0-1ubuntu1),
- cpp-10 (= 10.2.1-19ubuntu1),
+ cpp (= 4:10.3.0-1ubuntu1),
+ cpp-10 (= 10.3.0-1ubuntu1),
  dash (= 0.5.11+git20200708+dd9ef66+really0.5.11+git20200708+dd9ef66-5ubuntu1),
  debconf (= 1.5.74),
- debhelper (= 13.3.3ubuntu2),
+ debhelper (= 13.3.4ubuntu1),
  debianutils (= 4.11.2),
+ debugedit (= 1:0.1-0ubuntu2),
  dh-autoreconf (= 20),
- dh-exec (= 0.23.2),
+ dh-exec (= 0.23.4),
  dh-strip-nondeterminism (= 1.11.0-1),
  diffutils (= 1:3.7-3ubuntu1),
- dpkg (= 1.20.7.1ubuntu2),
- dpkg-dev (= 1.20.7.1ubuntu2),
- dwz (= 0.13+20210201-1),
+ dpkg (= 1.20.9ubuntu1),
+ dpkg-dev (= 1.20.9ubuntu1),
+ dwz (= 0.14-1),
  file (= 1:5.39-3),
- findutils (= 4.7.0-1ubuntu2),
- g++ (= 4:10.2.0-1ubuntu1),
- g++-10 (= 10.2.1-19ubuntu1),
- gcc (= 4:10.2.0-1ubuntu1),
- gcc-10 (= 10.2.1-19ubuntu1),
- gcc-10-base (= 10.2.1-19ubuntu1),
- gcc-11-base (= 11-20210207-1ubuntu1),
+ findutils (= 4.8.0-1ubuntu1),
+ g++ (= 4:10.3.0-1ubuntu1),
+ g++-10 (= 10.3.0-1ubuntu1),
+ gcc (= 4:10.3.0-1ubuntu1),
+ gcc-10 (= 10.3.0-1ubuntu1),
+ gcc-10-base (= 10.3.0-1ubuntu1),
+ gcc-11-base (= 11.1.0-1ubuntu1~21.04),
  gettext (= 0.21-3ubuntu2),
  gettext-base (= 0.21-3ubuntu2),
  grep (= 3.6-1),
@@ -43,113 +44,114 @@
  hostname (= 3.23),
  init-system-helpers (= 1.60),
  intltool-debian (= 0.35.0+20060710.5),
- libacl1 (= 2.2.53-10),
+ libacl1 (= 2.2.53-10ubuntu1),
  libarchive-zip-perl (= 1.68-1),
- libasan6 (= 10.2.1-19ubuntu1),
- libatomic1 (= 11-20210207-1ubuntu1),
- libattr1 (= 1:2.4.48-6),
+ libasan6 (= 11.1.0-1ubuntu1~21.04),
+ libatomic1 (= 11.1.0-1ubuntu1~21.04),
+ libattr1 (= 1:2.4.48-6build1),
  libaudit-common (= 1:3.0-2ubuntu1),
  libaudit1 (= 1:3.0-2ubuntu1),
- libbinutils (= 2.36.1-0ubuntu1),
- libblkid1 (= 2.36.1-1ubuntu2),
- libbz2-1.0 (= 1.0.8-4ubuntu2),
- libc-bin (= 2.33-0ubuntu2),
- libc-dev-bin (= 2.33-0ubuntu2),
- libc6 (= 2.33-0ubuntu2),
- libc6-dev (= 2.33-0ubuntu2),
+ libbinutils (= 2.36.1-6ubuntu1),
+ libblkid1 (= 2.36.1-7ubuntu2),
+ libbz2-1.0 (= 1.0.8-4ubuntu3),
+ libc-bin (= 2.33-0ubuntu5),
+ libc-dev-bin (= 2.33-0ubuntu5),
+ libc6 (= 2.33-0ubuntu5),
+ libc6-dev (= 2.33-0ubuntu5),
  libcap-ng0 (= 0.7.9-2.2build1),
- libcap2 (= 1:2.44-1),
- libcc1-0 (= 11-20210207-1ubuntu1),
- libcom-err2 (= 1.45.7-1ubuntu1),
- libcrypt-dev (= 1:4.4.17-1ubuntu1),
- libcrypt1 (= 1:4.4.17-1ubuntu1),
- libctf-nobfd0 (= 2.36.1-0ubuntu1),
- libctf0 (= 2.36.1-0ubuntu1),
- libdb5.3 (= 5.3.28+dfsg1-0.6ubuntu3),
- libdebconfclient0 (= 0.256ubuntu1),
- libdebhelper-perl (= 13.3.3ubuntu2),
- libdpkg-perl (= 1.20.7.1ubuntu2),
- libelf1 (= 0.183-1),
+ libcap2 (= 1:2.44-1build1),
+ libcc1-0 (= 11.1.0-1ubuntu1~21.04),
+ libcom-err2 (= 1.45.7-1ubuntu2),
+ libcrypt-dev (= 1:4.4.17-1ubuntu3),
+ libcrypt1 (= 1:4.4.17-1ubuntu3),
+ libctf-nobfd0 (= 2.36.1-6ubuntu1),
+ libctf0 (= 2.36.1-6ubuntu1),
+ libdb5.3 (= 5.3.28+dfsg1-0.6ubuntu4),
+ libdebconfclient0 (= 0.256ubuntu3),
+ libdebhelper-perl (= 13.3.4ubuntu1),
+ libdpkg-perl (= 1.20.9ubuntu1),
+ libdw1 (= 0.183-8),
+ libelf1 (= 0.183-8),
  libfile-stripnondeterminism-perl (= 1.11.0-1),
- libgcc-10-dev (= 10.2.1-19ubuntu1),
- libgcc-s1 (= 11-20210207-1ubuntu1),
- libgcrypt20 (= 1.8.7-2ubuntu1),
+ libgcc-10-dev (= 10.3.0-1ubuntu1),
+ libgcc-s1 (= 11.1.0-1ubuntu1~21.04),
+ libgcrypt20 (= 1.8.7-2ubuntu2),
  libgdbm-compat4 (= 1.19-2),
  libgdbm6 (= 1.19-2),
- libgmp10 (= 2:6.2.1+dfsg-1ubuntu1),
- libgomp1 (= 11-20210207-1ubuntu1),
- libgpg-error0 (= 1.38-2),
+ libgmp10 (= 2:6.2.1+dfsg-1ubuntu2),
+ libgomp1 (= 11.1.0-1ubuntu1~21.04),
+ libgpg-error0 (= 1.38-2build1),
  libgssapi-krb5-2 (= 1.18.3-4),
- libicu67 (= 67.1-6ubuntu1),
- libisl23 (= 0.23-1),
- libitm1 (= 11-20210207-1ubuntu1),
+ libicu67 (= 67.1-6ubuntu2),
+ libisl23 (= 0.23-1build1),
+ libitm1 (= 11.1.0-1ubuntu1~21.04),
  libk5crypto3 (= 1.18.3-4),
  libkeyutils1 (= 1.6.1-2ubuntu1),
  libkrb5-3 (= 1.18.3-4),
  libkrb5support0 (= 1.18.3-4),
- liblz4-1 (= 1.9.3-1),
- liblzma5 (= 5.2.5-1.0),
+ liblz4-1 (= 

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-21 Thread Paride Legovini
Rebuilding the same source package on Groovy produces a "good" libnss3
package (the Impish dogtag-pki autopkgtests pass when using it). This
means that a build-dependency that was upgraded in Hirsute caused the
regression.

(As Christian made me notice rebuilding on Hirsute *release* with no
updates may still produce a broken package, even if the "good" package
in the archive was built on Hirsute. This is because back when the
Hirsute package was built Hirsute was still in development. The true way
to go back to what Hirsute was initially is to go back to Groovy.)

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in nss package in Ubuntu:
  New

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check 

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-07-21 Thread Paride Legovini
After some work and testing, here are my findings.

 - The dogtag-pki autopkgtest failure is manually reproducible
   using autopkgtest-virt-lxd.
 - The dogtag-pki autopkgtests pass with in Impish using
   libnss3 *from the archive* (uploaded and built on Hirsute).
 - The dogtag-pki autopkgtests FAIL when using the very same
   libnss3 version but rebuilt from source on a Hirsute schroot.
   The debdiff between the two binary packages is:

File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Installed-Size: [-4255-] {+4318+}

 - This seems to be s390x-specific (I can't reproduce on my
   amd64 laptop)
 - I tried merging the latest version of src:nss from Debian,
   which required refreshing a s390x-specific patch, so I was
   really hoping this would fix it, but no: it fails in the
   same way.

FWIW I have a branch ready for merging 2:3.67-2 to Impish, but
I'm not sure on how to handle this dogtag-pki autopkgtest failure.

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in nss package in Ubuntu:
  New

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in 

[Touch-packages] [Bug 1934936] Re: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is dif

2021-07-13 Thread Paride Legovini
Hello and thanks for this bug report. You mentioned you hit this problem
from a fresh 21.10 install, however two things that caught my attention:

 - The package you are trying to install is for i386, for which there is no 
installation media for Impish. I guess you added i386 as a foreign 
architecture, but then your system doesn't count as a "fresh install" anymore 
:-)
 - libwind0-heimdal 7.7.0+dfsg-2build1 is currently in impish-proposed, so I 
guess you manually enabled -proposed. This is fine (thanks for testing!), but 
again your system doesn't really qualify as a "fresh install" in this case.

Could you please provide steps reproduce the problem from an actual
fresh install? If this requires adding i386 and -proposed that's fine,
however in order to verify this is actually a bug in Ubuntu and start
working on it we need a more complete reproducer.

I'm marking this report as Incomplete for now; please change it back to
New after commenting back and we'll look at it again. Thanks!

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

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

Title:
  package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade:
  trying to overwrite shared
  '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is
  different from other instances of package libwind0-heimdal:i386

Status in heimdal package in Ubuntu:
  Incomplete

Bug description:
  fresh 21.10 install and 1 reboot later it said there was additional
  updates and while doing so the error popped up

  ProblemType: Package
  DistroRelease: Ubuntu 21.10
  Package: libwind0-heimdal 7.7.0+dfsg-2build1
  ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21
  Uname: Linux 5.11.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Thu Jul  8 01:45:16 2021
  DuplicateSignature:
   package:libwind0-heimdal:7.7.0+dfsg-2build1
   Unpacking libwind0-heimdal:i386 (7.7.0+dfsg-2build1) over (7.7.0+dfsg-2) ...
   dpkg: error processing archive 
/tmp/apt-dpkg-install-8FDC3J/53-libwind0-heimdal_7.7.0+dfsg-2build1_i386.deb 
(--unpack):
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  ErrorMessage: trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  InstallationDate: Installed on 2021-06-05 (32 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  Python3Details: /usr/bin/python3.9, Python 3.9.6, python3-minimal, 3.9.4-1
  PythonDetails: N/A
  RebootRequiredPkgs:
   libc6
   libc6
  RelatedPackageVersions:
   dpkg 1.20.9ubuntu2
   apt  2.3.6
  SourcePackage: heimdal
  Title: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: 
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  UpgradeStatus: Upgraded to impish on 2021-07-07 (0 days ago)

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


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


[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

2021-06-16 Thread Paride Legovini
** Changed in: nss (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in nss package in Ubuntu:
  New

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
  >>>> CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server
  ii  libnss3:s390x  2:3.63-1ubuntu1 s

[Touch-packages] [Bug 1929854] Re: Vital and critical configuration files get overridden by system updates without warning

2021-05-31 Thread Paride Legovini
Hello Dominik and thanks for this bug report. An umbrella bug report
doesn't really help here, especially given that there's no single "reset
config files on updates" policy in Ubuntu. Actually it's quite the
contrary: as a Debian derivative Ubuntu basically inherits [1] and in
particular [2].

Please file individual bug reports against the affected packages,
possibly providing steps to reproduce the problem. In the case of
openssh-server I can say that the overwrite shouldn't happen, as
ssh_config is handles via ucf [3]. But let's discuss this in a dedicated
bug, once opened. I'll just add that the newer versions of openssh-
server support dropping custom config snippets in
/etc/ssh/sshd_config.d/, for easier handling of custom configurations.

Thanks!

[1] https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files
[2] https://www.debian.org/doc/debian-policy/ch-files.html#behavior
[3] http://manpages.ubuntu.com/manpages/focal/man1/ucf.1.html

** 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 libx11 in Ubuntu.
https://bugs.launchpad.net/bugs/1929854

Title:
  Vital and critical configuration files get overridden by system
  updates without warning

Status in grub2 package in Ubuntu:
  New
Status in libx11 package in Ubuntu:
  New
Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  • In my /usr/share/X11/locale/en_US.UTF-8/Compose I have about 10'000 lines 
of special compose keys defined.
  • In my /boot/grub/grub.cfg I have a very complicated special setup for my 
various boot configurations, and a 5-sec timout for my EFI-config.
  • My /etc/ssh/sshd_config contains a well-balanced configuration 

  All these files are regularly overridden WITHOUT EVEN A SINGLE WARNING
  or ASKING BACK by ubuntu system setups (discover).

  I set all of them to read-only by root and no-access for group and
  other users, but they still get overridden by every other system
  update.  I even have a shutdown process in place which should actually
  make sure that changes to these files are reverted by writing a backup
  copy over any newly installed override — unfortunately, everything I
  did to run either a custom shutdown process or a startup process with
  systemd turned out to not work and be a nightmare to make work.

  How somebody could be as bold as to override vital configuration files
  like this without even asking  for consent is one of the strange
  miracles in this world which I'll probably never understand.  However,
  if "ubuntu" is really what it translates to, it should take a little
  bit more care about pre-existing configurations on systems on which it
  is set up and running well — until one system update suddenly
  jeopardizes the functioning of the entire system.  I'm pretty sure
  these are not the only configuration files which are carelessly just
  overridden.  They're just the ones every other update breaks my system
  and inflinges on my the costs of hours of research until I find out
  that — of course — it was an overridden critical system configuration
  again.  The really mean thing is that you don't notice anything when
  you run the update … only next time you start your system and of
  course are not aware anymore that you did a system update, the new
  (absolutely wrong and/or insufficent) settings are in place and shoot
  you in the leg.

  Take an example from gentoo's etc-update feature which lets you merge
  new configuration files with pre-existing ones using a diff3-update.
  I went away from gentoo for other reasons, but I always praised that
  feature.

  Please make sure immediately that critical configuration files do not
  get overridden if they are non-writable by root, and then gradually
  introduce a system that merges changes to configuration files with the
  current situation on the target system.  Or at least present the
  configs that would be changed in a particular directory, so that
  anybody who is interested in preserving local settings could merge
  them in a suitable way.

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu15
  ProcVersionSignature: Ubuntu 5.8.0-53.60-generic 5.8.18
  Uname: Linux 5.8.0-53-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Thu May 27 18:48:15 2021
  DistUpgraded: Fresh install
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] [10de:1fb9] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo TU117GLM [Quadro T1000 Mobile] [17aa:2297]
  InstallationDate: Installed on 2021-01-15 (132 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - 

[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-05-10 Thread Paride Legovini
Hi, I went a bit down the rabbit hole Sergio mentioned and found the
same old reports and nothing really useful. I'd also be curios to see if
the problem still occurs with the newer releases.

Did you see this happen on more that one machine/deployment?

The backtrace didn't suggest my anything, but maybe Sergio will have
better use for it.

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  New

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

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

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


[Touch-packages] [Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute

2021-04-23 Thread Paride Legovini
** Changed in: cloud-init (Ubuntu)
   Status: New => Incomplete

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

Title:
  Azure: issues with accelerated networking on Hirsute

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

Bug description:
  [General]

  On Azure, when provisioning a Hirsute VM with Accelerated Networking
  enabled, sometimes part of the cloud-init configuration is not
  applied.

  Especially, in those cases, the public SSH key is not setup properly.

  [how to reproduce]

  Start a VM with AN enabled:

  ```
  az vm create --name "$VM_NAME --resource-group "$GROUP" --location "UK South" 
 --image 
'Canonical:0001-com-ubuntu-server-hirsute-daily:21_04-daily-gen2:latest' --size 
Standard_F8s_v2 --admin-username ubuntu --ssh-key-value "$SSH_KEY" 
--accelerated-networking
  ```

  After a moment, try to SSH: if you succeed, delete and recreate a new
  VM.

  [troubleshooting]

  To be able to connect into the VM, run:

  az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id 
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
  ```

  In "/run/cloud-init/instance-data.json", I can see:
  ```
   "publicKeys": [
    {
     "keyData": "",
     "path": "/home/ubuntu/.ssh/authorized_keys"
    }
   ],
  ```

  as expected.

  [workaround]

  As mentioned, Azure allows the user to run command into the VM without
  SSH connection. To do so, one can use the Azure CLI:

  az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
  RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"

  This example uses "ssh-import-id" but it's also possible to just echo
  a given public key into /home/ubuntu/.ssh/authorized_keys

  NOTE: this will only solves the SSH issue, I do not know if this bug
  affects other things. If so the user would have to apply those things
  manually.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions

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


[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together

2021-04-22 Thread Paride Legovini
Hello Bill and thanks for this bug report. I can see the issue you
described here (thanks for the reproducer), however I believe it should
be filed/fixed upstream. Maybe [1] should be expanded to cover --remove-
source-files, as the two issues could be related.

Diverging from upstream (or from Debian) has a long-term maintenance
cost (e.g. rebasing the patch at every release) and can lead to
situations which are difficult to handle well: think of a bug that is
later fixed upstream but in a different way, with user-facing
differences. What to do then, break compatibility with the older Ubuntu
releases, or break compatibility with upstream?

While I agree this is a bug in my opinion it is not worth diverging from
upstream here. I am setting the status of this bug report to Triaged (it
is well understood) but with importance: Wishlist.

Should you disagree with my reasoning please comment back and change the
bug status back to New, we'll look at it again. Thanks!

[1] https://bugzilla.samba.org/show_bug.cgi?id=3844

** Bug watch added: Samba Bugzilla #3844
   https://bugzilla.samba.org/show_bug.cgi?id=3844

** Changed in: rsync (Ubuntu)
   Status: New => Triaged

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

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

Title:
  rsync conceals file deletions from reporting when --dry-run --remove-
  source-files are used together

Status in rsync package in Ubuntu:
  Triaged

Bug description:
  Rsync has an astonishing and dangerous bug:

  The dry run feature (-n / --dry-run) inhibits reporting of file
  deletions when --remove-source-files is used. This is quite serious.
  People use --dry-run to see if an outcome will work as expected before
  a live run. When the simulated run shows *less* destruction than the
  live run, the consequences can be serious because rsync may
  unexpectedly destroy the only copy(*) of a file.

  Users rely on --dry-run. Although users probably expect --dry-run to
  have limitations, we don't expect destructive operations to be under
  reported. If it were reversed, such that the live run were less
  destructive than the dry run, this wouldn't be as serious.

  Reproducer:

  $ mkdir -p /tmp/src /tmp/dest
  $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt
  $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt
  $ cp /tmp/src/foo.txt /tmp/dest
  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt  foo.txt

  $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/
  (no output)

  $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/
  sender removed foo.txt

  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt

  (*) note when I say it can destroy the only copy of a file, another
  circumstance is needed: that is, rsync does not do a checksum by
  default.  It checks for identical files based on superficial
  parameters like name and date.  So it's possible that two files match
  in the default superficial comparison but differ in the actual
  content.  Losing a unique file in this scenario is perhaps a rare
  corner case, but this bug should be fixed nonetheless.  In the typical
  case of losing files at the source, there is still a significant
  inconvenience of trying to identify what files to copy back.

  Note this bug is similar but differs in a few ways:
  https://bugzilla.samba.org/show_bug.cgi?id=3844

  I've marked this as a security vulnerability because it causes
  unexpected data loss due to --dry-run creating a false expectation.

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

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


[Touch-packages] [Bug 1922130] Re: Request addition of Fedora / Redhat "sftp-force-permissions" patch

2021-04-01 Thread Paride Legovini
Hi Mark and thanks for this bug report. I can see how the flag
introduced by the "sftp-force-permissions" patch could come handy,
however I doubt we are going to include in the Ubuntu package unless
there's a compelling reason for doing so. And if such a compelling
reason did exist, then I think it should be brought to the attention of
the upstream openssh developers, without delivering the functionality
with a distribution specific patch.

My suggestion here is to:

 - Poke upstream about this. Note that they may have a good rationale
for *not* including the patch, given that it's small and they didn't
already do so.

 - File a bug in Debian. The Ubuntu openssh package is almost a sync
from Debian, which is another good reason to avoid including an
additional delta to it, with all its long-term implications (old
memories here: [1]). If Debian includes the patch then Ubuntu will pick
it up with the following package syncs or merges.

I'm going to triage this as a Wishlist bug for now. This is not a final
word, but I doubt the importance of this bug is likely to be bumped
without a compelling use case that would be enabled by adding the patch.

[1] https://www.debian.org/security/2008/dsa-1571

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

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

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

Title:
  Request addition of Fedora / Redhat "sftp-force-permissions" patch

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  Fedora / Redhat ships openssh with a patch which adds "-m force
  permission" flag to sftp-server.

  This is quite a common feature request / support request on the
  various stackexchange sites - https://superuser.com/questions/332284
  /in-sftp-how-to-set-the-default-permission-for-all-files-in-a-folder

  You will see that someone has answered "add -m" there which is indeed
  the simplest answer by a distance but unfortunately it's a non
  standard patch:

  https://src.fedoraproject.org/rpms/openssh/blob/f34/f/openssh-6.7p1
  -sftp-force-permission.patch

  This I think should supersede #563216 because they have been shipping
  this in production presumably since at least 2015 (I see it in fedora
  22 branch), so it is a known stable patch compared to the one
  suggested there.

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

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


[Touch-packages] [Bug 1915887] Re: systemd spams the syslog about lack of native systemd unit file

2021-03-11 Thread Paride Legovini
Fixed in Debian with the introduction of a new quilt patch:

https://salsa.debian.org/systemd-
team/systemd/-/commit/0c6d90f783093fc255e529f8a33b2ed2a8e6c2d6

Counting this as Fix Committed.

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

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

Title:
  systemd spams the syslog about lack of native systemd unit file

Status in apport package in Ubuntu:
  Invalid
Status in fam package in Ubuntu:
  Invalid
Status in freeradius package in Ubuntu:
  Invalid
Status in ipfm package in Ubuntu:
  Invalid
Status in n2n package in Ubuntu:
  Invalid
Status in pfm package in Ubuntu:
  Invalid
Status in shadowsocks package in Ubuntu:
  Invalid
Status in sysfsutils package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Committed
Status in virtualbox package in Ubuntu:
  Invalid
Status in xl2tpd package in Ubuntu:
  Invalid
Status in systemd package in Debian:
  Fix Released

Bug description:
  systemd in hirsute spams the syslog file several times per second
  about services lacking native systemd unit files.  Two things should
  happen.

  1) a systemd unit file ought to be created
  2) systemd should be slowed down with regards to these messages

  Feb 17 02:02:48 ubuntu-devel kernel: [  289.794825] 
systemd-sysv-generator[7105]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:49 ubuntu-devel kernel: [  290.165351] 
systemd-sysv-generator[7126]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:49 ubuntu-devel kernel: [  291.111278] 
systemd-sysv-generator[7170]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:50 ubuntu-devel kernel: [  291.507164] 
systemd-sysv-generator[7199]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.

  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386062] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/fam' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386321] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/xl2tpd' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386742] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/ipfm' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386767] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/shadowsocks' lacks a 
native systemd unit file. Automatically generating a unit file for 
compatibility. Please update package to include a native systemd unit file, in 
order to make it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.387281] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/virtualbox' lacks a 
native systemd unit file. Automatically generating a unit file for 
compatibility. Please update package to include a native systemd unit file, in 
order to make it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.388931] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/sysfsutils' lacks a 
native systemd unit file. Automatically generating a unit file for 
compatibility. Please update package to include a native systemd unit file, in 
order to make it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.388955] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/apport' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.389412] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/freeradius' lacks a 
native systemd unit file. 

[Touch-packages] [Bug 1915887] Re: systemd spams the syslog about lack of native systemd unit file

2021-03-11 Thread Paride Legovini
Also: setting all the other tasks to Invalid as there's noting wrong
with them; the issue (and the fix) belong to systemd.

** Changed in: apport (Ubuntu)
   Status: Incomplete => Invalid

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

** Changed in: fam (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: freeradius (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: ipfm (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: n2n (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: pfm (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: shadowsocks (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: sysfsutils (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: virtualbox (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: xl2tpd (Ubuntu)
   Status: Incomplete => 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/1915887

Title:
  systemd spams the syslog about lack of native systemd unit file

Status in apport package in Ubuntu:
  Invalid
Status in fam package in Ubuntu:
  Invalid
Status in freeradius package in Ubuntu:
  Invalid
Status in ipfm package in Ubuntu:
  Invalid
Status in n2n package in Ubuntu:
  Invalid
Status in pfm package in Ubuntu:
  Invalid
Status in shadowsocks package in Ubuntu:
  Invalid
Status in sysfsutils package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Committed
Status in virtualbox package in Ubuntu:
  Invalid
Status in xl2tpd package in Ubuntu:
  Invalid
Status in systemd package in Debian:
  Fix Released

Bug description:
  systemd in hirsute spams the syslog file several times per second
  about services lacking native systemd unit files.  Two things should
  happen.

  1) a systemd unit file ought to be created
  2) systemd should be slowed down with regards to these messages

  Feb 17 02:02:48 ubuntu-devel kernel: [  289.794825] 
systemd-sysv-generator[7105]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:49 ubuntu-devel kernel: [  290.165351] 
systemd-sysv-generator[7126]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:49 ubuntu-devel kernel: [  291.111278] 
systemd-sysv-generator[7170]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:50 ubuntu-devel kernel: [  291.507164] 
systemd-sysv-generator[7199]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.

  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386062] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/fam' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386321] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/xl2tpd' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386742] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/ipfm' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386767] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/shadowsocks' lacks a 
native systemd unit file. Automatically generating a unit file for 
compatibility. Please update package to include a native systemd unit file, in 
order to make it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.387281] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/virtualbox' lacks a 
native systemd unit file. Automatically generating a unit file for 
compatibility. Please update package to include a native systemd unit file, in 
order to make it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.388931] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/sysfsutils' lacks a 
native systemd unit file. Automatically 

[Touch-packages] [Bug 1691474] Re: invoke-rc.d service start fails on services with upstart-only scripts

2021-03-04 Thread Paride Legovini
I'm marking the main task as "Fix Released" as Ubuntu moved past
upstart, so I believe this is not an issue anymore.

Is this issue still relevant on Xenial? Marking the Xenial task a
Incomplete for the moment.

Tasks for EOL relases => Won't Fix.

** Changed in: init-system-helpers (Ubuntu Yakkety)
   Status: Confirmed => Won't Fix

** Changed in: init-system-helpers (Ubuntu Zesty)
   Status: Confirmed => Won't Fix

** Changed in: init-system-helpers (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: init-system-helpers (Ubuntu Xenial)
   Status: Confirmed => Incomplete

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

Title:
  invoke-rc.d service start fails on services with upstart-only scripts

Status in init-system-helpers package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Incomplete
Status in init-system-helpers source package in Yakkety:
  Won't Fix
Status in init-system-helpers source package in Zesty:
  Won't Fix

Bug description:
  [Impact]
  On 16.04+ if you using upstart as your primary init system "enabled" services 
that _only_ have upstart scripts fail to start with invoke-rc.d (with a default 
policy). This is problematic as #DEBHELPER# tokens in maintscripts rely on 
invoke-rc.d to start/stop services and fail to start services on installation.

  [Test Case]
  Boot into affected system with upstart as default init.
  Try starting an 'upstart only' service with 'invoke-rc.d service start'.
  It is expected this should work.

  [Regression Potential]
  14.04/upstart behavior is that invoke-rc.d works, and 16.04/systemd also has 
invoke-rc.d start working with enabled services and default policy. 
16.04/upstart should be the same.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1691474/+subscriptions

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


[Touch-packages] [Bug 1916729] Re: libnss3 package in Ubuntu 20.10 ships files under `/usr/lib/${DEB_HOST_MULTIARCH}` literally without expansion

2021-02-25 Thread Paride Legovini
Thanks for this bug report. This is fixed already in Hirsute (the
current development release) in version 2:3.55-1ubuntu4, but as you
noted the bug still affects Groovy.

** Changed in: nss (Ubuntu)
   Status: New => Triaged

** Also affects: nss (Ubuntu Groovy)
   Importance: Undecided
   Status: New

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

** Changed in: nss (Ubuntu Groovy)
   Status: New => Triaged

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

Title:
  libnss3 package in Ubuntu 20.10 ships files under
  `/usr/lib/${DEB_HOST_MULTIARCH}` literally without expansion

Status in nss package in Ubuntu:
  Fix Released
Status in nss source package in Groovy:
  Triaged

Bug description:
  ```
  brlin@groovy:~$ dpkg-query --listfiles libnss3
  /.
  /usr
  /usr/lib
  /usr/lib/${DEB_HOST_MULTIARCH}

  ...stripped...

  /usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.chk
  /usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so
  /usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.chk
  /usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.so
  ```

  The path appears to be a result of a failed parameter expansion.

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

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


[Touch-packages] [Bug 1915887] Re: systemd spams the syslog about lack of native systemd unit file

2021-02-18 Thread Paride Legovini
Hello Rolf and thanks for this bug report. I can't reproduce the issue
you described neither on my laptop, which has been following Ubuntu
"devel" for quite some cycles now, nor in a clean LXD container running
Hirsute.

You brought freeradius as an example, but freeradius *does* ship with a
systemd unit file:

  /lib/systemd/system/freeradius.service

So this looks like a local (mis)configuration issue to me. If you still
think there's actually a bug here we need more information on how to
reproduce it from a clean environment, otherwise it's difficult to
confirm the problem or to begin working on it.

I'm marking this bug report as Incomplete for the moment.

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

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

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

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

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

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

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

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

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

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

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

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

Title:
  systemd spams the syslog about lack of native systemd unit file

Status in apport package in Ubuntu:
  Incomplete
Status in fam package in Ubuntu:
  Incomplete
Status in freeradius package in Ubuntu:
  Incomplete
Status in ipfm package in Ubuntu:
  Incomplete
Status in n2n package in Ubuntu:
  Incomplete
Status in pfm package in Ubuntu:
  Incomplete
Status in shadowsocks package in Ubuntu:
  Incomplete
Status in sysfsutils package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Incomplete
Status in virtualbox package in Ubuntu:
  Incomplete
Status in xl2tpd package in Ubuntu:
  Incomplete

Bug description:
  systemd in hirsute spams the syslog file several times per second
  about services lacking native systemd unit files.  Two things should
  happen.

  1) a systemd unit file ought to be created
  2) systemd should be slowed down with regards to these messages

  Feb 17 02:02:48 ubuntu-devel kernel: [  289.794825] 
systemd-sysv-generator[7105]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:49 ubuntu-devel kernel: [  290.165351] 
systemd-sysv-generator[7126]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:49 ubuntu-devel kernel: [  291.111278] 
systemd-sysv-generator[7170]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:02:50 ubuntu-devel kernel: [  291.507164] 
systemd-sysv-generator[7199]: SysV service '/etc/init.d/n2n' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.

  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386062] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/fam' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386321] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/xl2tpd' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386742] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/ipfm' lacks a native 
systemd unit file. Automatically generating a unit file for compatibility. 
Please update package to include a native systemd unit file, in order to make 
it more safe and robust.
  Feb 17 02:05:57 ubuntu-devel kernel: [  478.386767] 
systemd-sysv-generator[9909]: SysV service '/etc/init.d/shadowsocks' lacks a 
native systemd unit file. Automatically generating a unit file for 
compatibility. Please update package to include a native systemd unit file, in 
order to make it more safe and robust.
  Feb 17 02:05:57 

[Touch-packages] [Bug 1915903] Re: Up-to-date net-tools package tells me to recompile it

2021-02-18 Thread Paride Legovini
Hello Richard and thanks for this bug report. According to the manpage
the -f option is equivalent to the --rfcomm long option, which isn't
really well documented. Just to check: are you actually trying to use
netstat in rfcomm mode? My impression is that --rfcomm is a legacy
option superseded by --protocol, which allows to explicitly specify the
desired protocol.

In general I can't match `netstat -f inet` with the command synopsis in
the manpage. Were you perhaps meaning `netstat -p inet`?

Please note that while the net-tools are fully supported in Ubuntu
(they're in "main"), they're considered deprecated and tools from the
iproute2 package should be used instead. The replacement for netstat is
normally the 'ss' tool. Unless you have specific requirements my
suggestion is to start using the "new" (> 10 years old) tools from the
beginning.

** Changed in: net-tools (Ubuntu)
   Status: New => Incomplete

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

Title:
  Up-to-date net-tools package tells me to recompile it

Status in net-tools package in Ubuntu:
  Incomplete

Bug description:
  Attempting to run

netstat -f inet

  results in

netstat: feature `AF BLUETOOTH' not supported.
Please recompile `net-tools' with newer kernel source or full configuration.

  Both my net-tools and kernel packages are fully up-to-date.  (Version
  details are in the report collected by ubuntu-bug.)

  This looks to me like a package inconsistency.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: net-tools 1.60+git20161116.90da8a0-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-135.139-generic 4.15.18
  Uname: Linux 4.15.0-135-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.23
  Architecture: amd64
  Date: Wed Feb 17 09:02:39 2021
  Dependencies:
   gcc-8-base 8.4.0-1ubuntu1~18.04
   libc6 2.27-3ubuntu1.4
   libgcc1 1:8.4.0-1ubuntu1~18.04
   libpcre3 2:8.39-9
   libselinux1 2.7-2build2
  InstallationDate: Installed on 2017-12-02 (1172 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  SourcePackage: net-tools
  UpgradeStatus: Upgraded to bionic on 2018-09-04 (896 days ago)

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

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


[Touch-packages] [Bug 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages

2021-01-22 Thread Paride Legovini
Hi Valters,

This really seems to be a systemd issue: sssd never sets SYSLOG_PID when
calling sd_journal_send(), yet journalctl shows e.g. SYSLOG_PID=sudo
instead of an empty string. Looks like systemd is mixing the variables
or leaking one into the others. The sssd upstream patch you pointed to
may act as a partial workaround, but the logging is still odd as you
noted.

The sssd upstream devs agree the problem is likely on the systemd side
in the bug report you opened [1].

I tried to install systemd and its dependencies from Groovy and Hirsute
on a Focal system as a rough way to see if a newer version of systemd
fixes the issue, but it kept behaving exactly the same.

I think debugging this requires writing a reproducer in the form of a
minimal C program calling sd_journal_send() like sssd does, having it
log/set SYSLOG_PID even when it should not.

I'm adding a systemd task to this bug report.

Paride

[1] https://github.com/SSSD/sssd/issues/5431, Dec 15 comment.

** Bug watch added: github.com/SSSD/sssd/issues #5431
   https://github.com/SSSD/sssd/issues/5431

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

Title:
  Invalid SYSLOG_PID for (systemd) journal messages

Status in sssd package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  New

Bug description:
  [Impact]

   * On Ubuntu (Focal) 20.04, SSSD 2.2.3-3, logs in Journald have
  invalid (non-numeric) SYSLOG_PID. Any tooling collecting SYSLOG_PID
  further, or attempting to work with syslog directly, fail to parse the
  PID as number.

   * Systemd does not validate, and simply expects SYSLOG_PID as numeric 
integers formatted as decimal strings:
     
https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#SYSLOG_FACILITY=

  [Test Case]

   * Deploy fresh 20.04 image, and update:
     apt update && apt dist-upgrade

   * apt -qqy install sssd

   * cat << EOF > /etc/sssd/sssd.conf
  [sssd]
    config_file_version = 2
    domains = EXAMPLE.COM
    services =

  [nss]

  [pam]

  [sudo]

  [domain/EXAMPLE.COM]
    id_provider = files
    access_provider = permit
  EOF

   * chmod 600 /etc/sssd/sssd.conf

   * systemctl restart sssd.service

   * journalctl -o verbose -u sssd-sudo.service | grep SYSLOG_PID=
     SYSLOG_PID=sudo

   * journalctl -u sssd.service # Produces malformed example lines:
     Dec 07 14:10:00 servername sssd[be[1234]: Starting up

   * grep sssd /var/log/syslog # Displays non-numeric PIDs:
     Dec  7 08:00:00 servername sssd[be[EXAMPLE.COM]]: Starting up
     Dec  7 08:00:00 servername sssd[nss]: Starting up
     Dec  7 08:00:00 servername sssd[sudo]: Starting up
     Dec  7 08:00:00 servername sssd[pam]: Starting up

  [Where problems could occur]

   * Someone might depend on the malformed output already, and have
  tooling in place to transform it manually.

  [Other Info]

   * Is not reproducible on Ubuntu (Groovy) 20.10 containing SSSD
  2.3.1-3. Considering Debian testing is currently at SSSD 2.4.0-1, it
  does not appear applicable to fix in upstream.

   * The package itself does not appear to provide any SYSLOG_PID. The
  SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at
  trouble on systemd side. SSSD source at:
  https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110

   * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and 
suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no 
SYSLOG_PID being reported.
 Cherry-picked upstream commit for testing: 
https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c

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

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


[Touch-packages] [Bug 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages

2021-01-22 Thread Paride Legovini
** 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908065

Title:
  Invalid SYSLOG_PID for (systemd) journal messages

Status in sssd package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  New

Bug description:
  [Impact]

   * On Ubuntu (Focal) 20.04, SSSD 2.2.3-3, logs in Journald have
  invalid (non-numeric) SYSLOG_PID. Any tooling collecting SYSLOG_PID
  further, or attempting to work with syslog directly, fail to parse the
  PID as number.

   * Systemd does not validate, and simply expects SYSLOG_PID as numeric 
integers formatted as decimal strings:
     
https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#SYSLOG_FACILITY=

  [Test Case]

   * Deploy fresh 20.04 image, and update:
     apt update && apt dist-upgrade

   * apt -qqy install sssd

   * cat << EOF > /etc/sssd/sssd.conf
  [sssd]
    config_file_version = 2
    domains = EXAMPLE.COM
    services =

  [nss]

  [pam]

  [sudo]

  [domain/EXAMPLE.COM]
    id_provider = files
    access_provider = permit
  EOF

   * chmod 600 /etc/sssd/sssd.conf

   * systemctl restart sssd.service

   * journalctl -o verbose -u sssd-sudo.service | grep SYSLOG_PID=
     SYSLOG_PID=sudo

   * journalctl -u sssd.service # Produces malformed example lines:
     Dec 07 14:10:00 servername sssd[be[1234]: Starting up

   * grep sssd /var/log/syslog # Displays non-numeric PIDs:
     Dec  7 08:00:00 servername sssd[be[EXAMPLE.COM]]: Starting up
     Dec  7 08:00:00 servername sssd[nss]: Starting up
     Dec  7 08:00:00 servername sssd[sudo]: Starting up
     Dec  7 08:00:00 servername sssd[pam]: Starting up

  [Where problems could occur]

   * Someone might depend on the malformed output already, and have
  tooling in place to transform it manually.

  [Other Info]

   * Is not reproducible on Ubuntu (Groovy) 20.10 containing SSSD
  2.3.1-3. Considering Debian testing is currently at SSSD 2.4.0-1, it
  does not appear applicable to fix in upstream.

   * The package itself does not appear to provide any SYSLOG_PID. The
  SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at
  trouble on systemd side. SSSD source at:
  https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110

   * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and 
suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no 
SYSLOG_PID being reported.
 Cherry-picked upstream commit for testing: 
https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c

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

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


[Touch-packages] [Bug 1903516] Re: aborted (core dumped) when using ConnectTimeout > 2147483

2020-11-12 Thread Paride Legovini
Hello Bert and thanks for this bug report. I could easily reproduce the
issue you described, but I think it would best be fixed upstream rather
than with an Ubuntu specific patch. I filed an upstream bug report [1]
and linked it to this one.

Given that triggering this bug requires a very odd setting I'm marking
this report with Importance: Low. Should there be an actual use case for
such a high timeout please explain it in a comment and we'll re-evaluate
the bug importance. Thanks!

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=3229

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

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

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

Title:
  aborted (core dumped) when using ConnectTimeout > 2147483

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged

Bug description:
  The ssh client fails with the message "Aborted (core dumped)" when
  setting the ConnectTimeout to 2147484 or higher.

  lsb_release: Linux Mint 20 (but also tested this on latest ubuntu:20.04 
docker container)
  openssh-client version: 1:8.2p1-4ubuntu0.1

  I expected that either the connect timeout would be used correctly, or
  that it would fail with a proper error message saying the connect
  timeout can't be higher than 2147483.

  What happened:

  $ ssh -o "ConnectTimeout=2147484" localhost
  Aborted (core dumped)

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

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


[Touch-packages] [Bug 1903516] Re: aborted (core dumped) when using ConnectTimeout > 2147483

2020-11-12 Thread Paride Legovini
** Bug watch added: OpenSSH Portable Bugzilla #3229
   https://bugzilla.mindrot.org/show_bug.cgi?id=3229

** Also affects: openssh via
   https://bugzilla.mindrot.org/show_bug.cgi?id=3229
   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/1903516

Title:
  aborted (core dumped) when using ConnectTimeout > 2147483

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  The ssh client fails with the message "Aborted (core dumped)" when
  setting the ConnectTimeout to 2147484 or higher.

  lsb_release: Linux Mint 20 (but also tested this on latest ubuntu:20.04 
docker container)
  openssh-client version: 1:8.2p1-4ubuntu0.1

  I expected that either the connect timeout would be used correctly, or
  that it would fail with a proper error message saying the connect
  timeout can't be higher than 2147483.

  What happened:

  $ ssh -o "ConnectTimeout=2147484" localhost
  Aborted (core dumped)

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

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


[Touch-packages] [Bug 1902760] Re: Please merge linker bugfix into Ubuntu 20.04 LTS

2020-11-03 Thread Paride Legovini
** Bug watch added: Sourceware.org Bugzilla #26262
   https://sourceware.org/bugzilla/show_bug.cgi?id=26262

** Also affects: binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=26262
   Importance: Unknown
   Status: Unknown

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

Title:
  Please merge linker bugfix into Ubuntu 20.04 LTS

Status in binutils:
  Unknown
Status in binutils package in Ubuntu:
  New

Bug description:
  Binutils bug https://sourceware.org/bugzilla/show_bug.cgi?id=26262
  fixes a problem that Intel Fortran is running into when using the -ipo
  option to request link time optimization. Please merge the fix into
  Ubuntu 20.04 LTS

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

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


[Touch-packages] [Bug 1901295] Re: python3-chardet breaks install of python-chardet

2020-10-29 Thread Paride Legovini
Hi Julien and thanks for filing this bug.

I think your suggestion could work in principle, however I doubt it will
be implemented in practice. It would mean modifying a package to support
an unsupported package and more in general an unsupported setup.

Splitting the package in Debian would require it to go through the NEW
queue again, which can be a quite lengthy process. Moreover Ubuntu would
pickup the fixed package only in Hirsute (at best), so your existing
systems wouldn't get the fix. Fixing the package directly in Ubuntu
isn't a good idea either, as it's currently a sync from Debian, and we
tend to avoid adding package deltas when possible, and still the fix
could only land in Hirsute.

If you still want to try this way I suggest you to file a bug in Debian
and wait for the package maintainers opinion, however the true way
forward here is to leave Python2 behind. If that's not an option you can
still stick to Bionic for the moment, it's supported until 2028.

I'm setting this bug to Incomplete to leave it open for further
discussion if needed, but I think it should be considered a Won't Fix.

** Changed in: python3-chardet (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  python3-chardet breaks install of python-chardet

Status in python3-chardet package in Ubuntu:
  Incomplete

Bug description:
  I'm trying to install python-chardet (for python-2.7), but it fails
  because latest python3-chardet breaks python-chardet. I fail to
  understand why the python3 version of chardet would break the
  python2.7 version of the same module.

  PS: I know that python2.7 is not supported anymore, but I have an
  application that depends on it, and I need to install it, and that's
  now impossible because of this bug.

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

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


[Touch-packages] [Bug 1880193] Re: autofs: Assertion 'set_remove(iterator->links, link) == link' failed at src/shared/userdb.c:314, function userdb_on_query_reply(). Aborting.

2020-10-15 Thread Paride Legovini
Hello Michael, thanks for the followup and for filing the bug in the
first place.

For the moment I'm changing the status of this report to Incomplete
across the packages/series it targets. If this specific issue can't be
reproduced anymore please set the statuses to Invalid (I'd prefer it to
Fix Released as we didn't identify what actually fixed it), and go ahead
filing a new bug for the remaining issues you're facing. On the other
hand if you still think this should be investigated please comment back
with your findings, change the bug status back to New and we'll look at
it again. Thanks!

** Changed in: autofs (Ubuntu)
   Status: Triaged => Incomplete

** Changed in: autofs (Ubuntu Focal)
   Status: Triaged => Incomplete

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

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

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

Title:
  autofs: Assertion 'set_remove(iterator->links, link) == link' failed
  at src/shared/userdb.c:314, function userdb_on_query_reply().
  Aborting.

Status in autofs package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Incomplete
Status in autofs source package in Focal:
  Incomplete
Status in systemd source package in Focal:
  Incomplete

Bug description:
  autofs has a periodic error on mounting shares in Ubuntu 20.04 (it happens 
about 1 time out of 5):
  "Assertion 'set_remove(iterator->links, link) == link' failed at 
src/shared/userdb.c:314, function userdb_on_query_reply(). Aborting.
  Aborted (core dumped)"


  `autofs.service` restart (or `automount` app restart) fixes this
  issue. However if some of home dirs (like `Desktop` or `Documents`)
  are mounted by `autofs`, user can't login into Ubuntu Desktop
  Environment (PC freezes on login with black screen). Since this error
  can prevent user log in, it might be considered as critical bug.


  It happens both in `autofs` systemd service and by direct execution of
  `automount` app (`automount -f -d` command).


  May be it's an underlying error in `systemd` library (I found the
  line, mentioned in error, in its source codes).


  This issue has place in Ubuntu 20.04 (it works correctly in Ubuntu
  18.04):

  > lsb_release -rd
  Description: Ubuntu 20.04 LTS
  Release: 20.04


  Packages versions:

  > apt-cache policy autofs systemd
  autofs:
Installed: 5.1.6-2
Candidate: 5.1.6-2
Version table:
   *** 5.1.6-2 500
  500 http://ru.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  systemd:
Installed: 245.4-4ubuntu3
Candidate: 245.4-4ubuntu3
Version table:
   *** 245.4-4ubuntu3 500
  500 http://ru.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status


  Steps to reproduce:
  1. Ubuntu 20.04 clean install
  2. `apt install realmd sssd sssd-tools libnss-sss libpam-sss adcli 
samba-common-bin`
  3. `realm join DOMAIN.NAME`
  4. Enable makehomedir by command: `pam-auth-update`
  5. `apt install cifs-utils`
  6. `apt install autofs`
  7. Add next line inside [domain/DOMAIN.EXT] section into /etc/sssd/sssd.conf: 
`krb5_ccname_template = FILE:%d/krb5cc_%U`
  8. Reboot
  9. Login as domain user and try to open directory, mounted by `autofs` (in my 
configuration shares are provided by AD).
  10. `autofs.service` stops with the error above about 1 time out of 5 (not 
always).

  Found workaround:
  Add `Restart=always` into `[Service]` section in 
`/lib/systemd/system/autofs.service` file (in other words configure 
auto-restart on failures for autofs service).


  Attachments:
  1. Full log of `automount -f -d` command.

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

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


  1   2   >