[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


[Touch-packages] [Bug 1894907] Re: FTBFS with sphinx 2.4: cannot import name 'NoUri'

2020-09-10 Thread Paride Legovini
** Changed in: cyrus-sasl2 (Ubuntu)
   Status: New => Triaged

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

Title:
  FTBFS with sphinx 2.4: cannot import name 'NoUri'

Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 package in Debian:
  New

Bug description:
  Getting this failure to build on groovy:

  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'NoUri' from 'sphinx.environment' 
(/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
  make[2]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make[1]: *** [Makefile:686: all-recursive] Error 1
  make[1]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make: *** [Makefile:556: all] Error 2

  
  Debian has a bug report already at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1894907/+subscriptions

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


[Touch-packages] [Bug 1891548] Re: autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

2020-08-20 Thread Paride Legovini
Hi Michael and thanks for all the digging. If I understand correctly
there are two issues here:

1. The slapd crash due to the caseExactMatch/caseExactIA5Match typo, for
which you submitted a fix upstream [1].

2. The need to "start ; stop ; restart" the slapd service in order to
avoid the "invalid per syntax" errors.

What I suggest is to:

A. Let's wait for upstream to comment on or pickup your patch. We'll
then be able to cherry-pick the fix from the upstream repository. This
makes things easier to manage and give us more confidence on the
correctness on the patch (could be obvious for a ldap/autofs expert, I
am not.)

B. File a separate bug for the "start ; stop ; restart" thing, which
appears to be unrelated. If you do so, please make it clear it's a
Bionic -> Focal regression. Having a minimal steps to reproduce the
issue from a fresh Focal install would be the best.

What do you think?

Paride

[1] https://www.spinics.net/lists/autofs/msg02276.html

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

Title:
  autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

Status in autofs package in Ubuntu:
  New
Status in openldap package in Ubuntu:
  New
Status in autofs package in Debian:
  Unknown

Bug description:
  Ubuntu Release:
  # lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  Version of packages in use:
  # dpkg -l autofs autofs-ldap slapd | grep '^ii'
  ii  autofs 5.1.6-2ubuntu0.1   amd64kernel-based 
automounter for Linux
  ii  autofs-ldap5.1.6-2ubuntu0.1   amd64LDAP map support for 
autofs
  ii  slapd  2.4.49+dfsg-2ubuntu1.3 amd64OpenLDAP server (slapd)

  Expected:
  No errors from slaptest

  Actual Output:
  5f359370 /etc/ldap/schema/autofs.schema: line 14 attributetype: AttributeType 
inappropriate matching rule: "caseExactMatch"

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

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


[Touch-packages] [Bug 1891548] Re: autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

2020-08-20 Thread Paride Legovini
** Also affects: autofs (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968675
   Importance: Unknown
   Status: Unknown

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

Title:
  autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

Status in autofs package in Ubuntu:
  New
Status in openldap package in Ubuntu:
  New
Status in autofs package in Debian:
  Unknown

Bug description:
  Ubuntu Release:
  # lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  Version of packages in use:
  # dpkg -l autofs autofs-ldap slapd | grep '^ii'
  ii  autofs 5.1.6-2ubuntu0.1   amd64kernel-based 
automounter for Linux
  ii  autofs-ldap5.1.6-2ubuntu0.1   amd64LDAP map support for 
autofs
  ii  slapd  2.4.49+dfsg-2ubuntu1.3 amd64OpenLDAP server (slapd)

  Expected:
  No errors from slaptest

  Actual Output:
  5f359370 /etc/ldap/schema/autofs.schema: line 14 attributetype: AttributeType 
inappropriate matching rule: "caseExactMatch"

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

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


[Touch-packages] [Bug 1888685] Re: rsync fails after installing level 3.2.1

2020-07-31 Thread Paride Legovini
OK, so the directory being in /home is the culprit, I could reproduce
the issue and found where the problem is. At some point rsync added

  ProtectHome=on
  
option to its service file, /lib/systemd/system/rsync.service. This has been 
reverted in upstream git at [1] as it's too restrictive. The fix landed in 
rsync v3.2.2 which is already in Debian; Ubuntu will pick it up with the next 
sync. In the meantime you can workaround the problem by manually disabling 
ProtectHome.

Thanks again for reporting the issue and for providing all the details.

[1]
https://github.com/WayneD/rsync/commit/ce12142c459788b611da5f5d525e0486822b043a

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

** Changed in: rsync (Ubuntu)
Milestone: None => ubuntu-20.10

** Also affects: rsync (Debian)
   Importance: Undecided
   Status: New

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

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

Title:
  rsync fails after installing level 3.2.1

Status in rsync package in Ubuntu:
  Triaged
Status in rsync package in Debian:
  Fix Released

Bug description:
  After installation of rsync.3.2.1 my attempt to sync fails with chroot
  error.  The rsyncd.log indicates that rsync can't find the directories
  I want to sync.

  2020/07/18 10:01:20 [3689] rsyncd version 3.2.1 starting, listening on port 
873
  2020/07/18 11:00:01 [5786] name lookup failed for 192.168.1.159: Name or 
service not known
  2020/07/18 11:00:01 [5786] connect from UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5786] rsync allowed access on module Bin_dir from 
UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5786] rsync: [Receiver] chroot /home/cliff/Bin failed: 
No such file or directory (2)
  2020/07/18 11:00:01 [5794] name lookup failed for 192.168.1.159: Name or 
service not known
  2020/07/18 11:00:01 [5794] connect from UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5794] rsync allowed access on module Bin_dir from 
UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5794] rsync: [Receiver] chroot /home/cliff/Bin failed: 
No such file or directory (2)
  2020/07/18 11:00:01 [5795] name lookup failed for 192.168.1.159: Name or 
service not known
  2020/07/18 11:00:01 [5795] connect from UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5795] rsync allowed access on module Drawings_dir from 
UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5795] rsync: [Receiver] chroot /home/cliff/Drawings 
failed: No such file or directory (2)

  Dropping back to Ubuntu 20.04 and rsync works again.  The rsync update
  was install 7/18.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: rsync 3.2.1-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
  Uname: Linux 5.4.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu42
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul 23 10:28:17 2020
  InstallationDate: Installed on 2020-07-06 (16 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200609)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.rsync: 2020-07-06T11:31:56.141217

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

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


[Touch-packages] [Bug 1888685] Re: rsync fails after installing level 3.2.1

2020-07-30 Thread Paride Legovini
Hi Cliff,

This is odd, but if I understand correctly you have a setup that
triggers the problem and a slightly different setup that does not, on
the same system. This means we are in a good position already. I'd
follow Christian's suggestion and make them even more and more similar
until you can spot what actually triggers the problem.

E.g.: Can you move /mnt/testrsync to /home? To /home/cliff? Can you
rename it to Bin?

Sounds silly, but there *has* to be something that makes it work with
/mnt/testrsync but not with /home/cliff/Bin.

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

Title:
  rsync fails after installing level 3.2.1

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  After installation of rsync.3.2.1 my attempt to sync fails with chroot
  error.  The rsyncd.log indicates that rsync can't find the directories
  I want to sync.

  2020/07/18 10:01:20 [3689] rsyncd version 3.2.1 starting, listening on port 
873
  2020/07/18 11:00:01 [5786] name lookup failed for 192.168.1.159: Name or 
service not known
  2020/07/18 11:00:01 [5786] connect from UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5786] rsync allowed access on module Bin_dir from 
UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5786] rsync: [Receiver] chroot /home/cliff/Bin failed: 
No such file or directory (2)
  2020/07/18 11:00:01 [5794] name lookup failed for 192.168.1.159: Name or 
service not known
  2020/07/18 11:00:01 [5794] connect from UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5794] rsync allowed access on module Bin_dir from 
UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5794] rsync: [Receiver] chroot /home/cliff/Bin failed: 
No such file or directory (2)
  2020/07/18 11:00:01 [5795] name lookup failed for 192.168.1.159: Name or 
service not known
  2020/07/18 11:00:01 [5795] connect from UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5795] rsync allowed access on module Drawings_dir from 
UNKNOWN (192.168.1.159)
  2020/07/18 11:00:01 [5795] rsync: [Receiver] chroot /home/cliff/Drawings 
failed: No such file or directory (2)

  Dropping back to Ubuntu 20.04 and rsync works again.  The rsync update
  was install 7/18.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: rsync 3.2.1-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
  Uname: Linux 5.4.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu42
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul 23 10:28:17 2020
  InstallationDate: Installed on 2020-07-06 (16 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200609)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.rsync: 2020-07-06T11:31:56.141217

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

-- 
Mailing list: https://launchpad.net/~touch-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/

2020-07-09 Thread Paride Legovini
I agree the generated keys doesn't belong to /etc, while I'm not so sure
about the default configuration files, as there are options that once
set can't be "undone" by a config file loaded later, e.g. the Port
option.

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

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 1659719] Re: ssh can't call a binary from a snap without the full path

2020-07-03 Thread Paride Legovini
That won't be too different from /usr/local/sbin and /usr/local/bin
being in the PATH but empty I think. I am not aware of any problem or
annoyance caused by nonexisting directories being in the PATH.

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

Title:
  ssh can't call a binary from a snap without the full path

Status in Snappy:
  Fix Committed
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in openssh package in Ubuntu:
  Confirmed
Status in pam package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed
Status in livecd-rootfs source package in Groovy:
  Fix Released
Status in openssh source package in Groovy:
  Confirmed
Status in pam source package in Groovy:
  Confirmed
Status in snapd source package in Groovy:
  Confirmed

Bug description:
  ssh can't call a binary from a snap, it will only work using the full
  path.

  Let's say I have the hello snap installed in 192.168.122.24. Then:

  elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 hello
  elopio@192.168.122.24's password:
  bash: hello: command not found
  elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 /snap/bin/hello
  elopio@192.168.122.24's password:
  Hello, world!

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

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


[Touch-packages] [Bug 827151] Re: Annoying log message "DIGEST-MD5 common mech free"

2020-07-02 Thread Paride Legovini
I proposed a possible workaround here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805310

Some feedback on it will certainly be appreciated by the package
maintainers.

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

Title:
  Annoying log message "DIGEST-MD5 common mech free"

Status in Cyrus-sasl2:
  New
Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 source package in Trusty:
  Won't Fix
Status in cyrus-sasl2 source package in Xenial:
  Incomplete
Status in cyrus-sasl2 source package in Yakkety:
  Fix Released
Status in cyrus-sasl2 source package in Focal:
  Triaged
Status in cyrus-sasl2 package in Debian:
  Unknown

Bug description:
  I recently updated the libsasl2-modules to 
2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric.
  That triggered the bug also described in Debian here: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932

  The annoying message is logged in auth.log. In my case, it is associated with 
svnserve:
  svnserve: DIGEST-MD5 common mech free

  I'm not exactly sure what action triggers the message, but I can
  investigate more if required.

  $ lsb_release -rd
  Description:Ubuntu oneiric (development branch)
  Release:11.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+subscriptions

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


[Touch-packages] [Bug 827151] Re: Annoying log message "DIGEST-MD5 common mech free"

2020-07-02 Thread Paride Legovini
There's a "new" (2015) Debian bug for this issue, which I linked to the
cyrus-sasl2 task. Apparently the regexp in
/etc/logcheck/ignore.d.server/libsasl2-modules which is used to ignore
the annoying log message doesn't match the log message format of the
newer releases. The Debian bug has a patch for it, however it would be
better for this change to land in the Debian package. Ubuntu will then
pick it up with the next package sync.

The Debian bug has seen no activity since 2018. I'll try to poke the
maintainers.

** Changed in: cyrus-sasl2 (Debian)
   Status: Fix Released => Unknown

** Changed in: cyrus-sasl2 (Debian)
 Remote watch: Debian Bug tracker #631932 => Debian Bug tracker #805310

** Changed in: cyrus-sasl2 (Ubuntu)
   Status: Fix Released => Triaged

** Also affects: cyrus-sasl2 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: cyrus-sasl2 (Ubuntu Focal)
   Status: New => Triaged

** Changed in: cyrus-sasl2 (Ubuntu Focal)
   Importance: Undecided => Low

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

Title:
  Annoying log message "DIGEST-MD5 common mech free"

Status in Cyrus-sasl2:
  New
Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 source package in Trusty:
  Won't Fix
Status in cyrus-sasl2 source package in Xenial:
  Incomplete
Status in cyrus-sasl2 source package in Yakkety:
  Fix Released
Status in cyrus-sasl2 source package in Focal:
  Triaged
Status in cyrus-sasl2 package in Debian:
  Unknown

Bug description:
  I recently updated the libsasl2-modules to 
2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric.
  That triggered the bug also described in Debian here: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932

  The annoying message is logged in auth.log. In my case, it is associated with 
svnserve:
  svnserve: DIGEST-MD5 common mech free

  I'm not exactly sure what action triggers the message, but I can
  investigate more if required.

  $ lsb_release -rd
  Description:Ubuntu oneiric (development branch)
  Release:11.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+subscriptions

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


[Touch-packages] [Bug 827151] Re: Annoying log message "DIGEST-MD5 common mech free"

2020-07-02 Thread Paride Legovini
** Changed in: cyrus-sasl2 (Ubuntu Trusty)
   Status: Triaged => Won't Fix

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

Title:
  Annoying log message "DIGEST-MD5 common mech free"

Status in Cyrus-sasl2:
  New
Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 source package in Trusty:
  Won't Fix
Status in cyrus-sasl2 source package in Xenial:
  Incomplete
Status in cyrus-sasl2 source package in Yakkety:
  Fix Released
Status in cyrus-sasl2 package in Debian:
  Unknown

Bug description:
  I recently updated the libsasl2-modules to 
2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric.
  That triggered the bug also described in Debian here: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932

  The annoying message is logged in auth.log. In my case, it is associated with 
svnserve:
  svnserve: DIGEST-MD5 common mech free

  I'm not exactly sure what action triggers the message, but I can
  investigate more if required.

  $ lsb_release -rd
  Description:Ubuntu oneiric (development branch)
  Release:11.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+subscriptions

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


[Touch-packages] [Bug 1874953] Re: dpkg: conffile difference visualizer subprocess returned error exit status 127

2020-06-10 Thread Paride Legovini
I filed a less bug in Debian: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=962590

** Bug watch added: Debian Bug tracker #962590
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962590

** Also affects: less (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962590
   Importance: Unknown
   Status: Unknown

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

Title:
  dpkg: conffile difference visualizer subprocess returned error exit
  status 127

Status in dpkg package in Ubuntu:
  Triaged
Status in less package in Ubuntu:
  Fix Released
Status in smartmontools package in Ubuntu:
  Invalid
Status in dpkg source package in Focal:
  Confirmed
Status in less source package in Focal:
  Triaged
Status in smartmontools source package in Focal:
  Confirmed
Status in dpkg source package in Groovy:
  Triaged
Status in less source package in Groovy:
  Fix Released
Status in smartmontools source package in Groovy:
  Invalid
Status in dpkg package in Debian:
  New
Status in less package in Debian:
  Unknown

Bug description:
  Issue occurred on upgrade from 19.10 to 20.04

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: smartmontools 7.1-1build1
  ProcVersionSignature: Ubuntu 5.3.0-46.38-generic 5.3.18
  Uname: Linux 5.3.0-46-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Apr 24 21:33:08 2020
  ErrorMessage: conffile difference visualizer subprocess returned error exit 
status 127
  InstallationDate: Installed on 2011-06-18 (3233 days ago)
  InstallationMedia: Ubuntu-Server 11.04 "Natty Narwhal" - Release amd64 
(20110426)
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 
2.7.17-4
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2
  SourcePackage: smartmontools
  Title: package smartmontools 7.1-1build1 failed to install/upgrade: conffile 
difference visualizer subprocess returned error exit status 127
  UpgradeStatus: Upgraded to focal on 2020-04-25 (0 days ago)
  mtime.conffile..etc.default.smartmontools: 2017-12-08T19:12:02.064375
  mtime.conffile..etc.smartd.conf: 2017-12-08T20:27:28.727282

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

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


[Touch-packages] [Bug 1874953] Re: dpkg: conffile difference visualizer subprocess returned error exit status 127

2020-06-05 Thread Paride Legovini
The minimal change is probably moving

update-alternatives --quiet --remove pager /bin/less

from postinst to preinst. The pager alternative will fallback to 'more'
at least until the new alternative is set up. Strictly speaking it is
probably the most correct thing to do, as 'pager' is never left wrongly
configured.

However there are several packages calling `update-alternatives
--install` from preinst [1]. That's probably OK too.

[1] https://codesearch.debian.net/search?q=path%3Adebian%2Fpreinst
+update-alternatives=1

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

Title:
  dpkg: conffile difference visualizer subprocess returned error exit
  status 127

Status in dpkg package in Ubuntu:
  Triaged
Status in less package in Ubuntu:
  In Progress
Status in smartmontools package in Ubuntu:
  Invalid
Status in dpkg source package in Focal:
  New
Status in less source package in Focal:
  Triaged
Status in smartmontools source package in Focal:
  New
Status in dpkg source package in Groovy:
  Triaged
Status in less source package in Groovy:
  In Progress
Status in smartmontools source package in Groovy:
  Invalid
Status in dpkg package in Debian:
  New

Bug description:
  Issue occurred on upgrade from 19.10 to 20.04

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: smartmontools 7.1-1build1
  ProcVersionSignature: Ubuntu 5.3.0-46.38-generic 5.3.18
  Uname: Linux 5.3.0-46-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Apr 24 21:33:08 2020
  ErrorMessage: conffile difference visualizer subprocess returned error exit 
status 127
  InstallationDate: Installed on 2011-06-18 (3233 days ago)
  InstallationMedia: Ubuntu-Server 11.04 "Natty Narwhal" - Release amd64 
(20110426)
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 
2.7.17-4
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2
  SourcePackage: smartmontools
  Title: package smartmontools 7.1-1build1 failed to install/upgrade: conffile 
difference visualizer subprocess returned error exit status 127
  UpgradeStatus: Upgraded to focal on 2020-04-25 (0 days ago)
  mtime.conffile..etc.default.smartmontools: 2017-12-08T19:12:02.064375
  mtime.conffile..etc.smartd.conf: 2017-12-08T20:27:28.727282

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

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


[Touch-packages] [Bug 1876320] Re: Port parameter sshd_config is 22 AND whatever you specify

2020-05-29 Thread Paride Legovini
Thanks for verifying. The patch will be applied to the OpenSSH version
already in Focal, so OpenSSH will stay at version 8.2 in Focal.

Christian set up the PPA specifically for testing the patched package,
it's not meant for production use. It's unlikely that you'll hit any
surprise by using it, but it's entirely up to you. The patched package
meant for production will eventually land in focal-updates.

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

Title:
  Port parameter sshd_config is 22 AND whatever you specify

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

Bug description:
  On my Ubuntu Server 20.04 LTS with OpenSSH 1:8.2p1-4, I have TWO sshd
  deamons. One (on port 22) is for internal use, accepts passwords etc.
  The second (on port 7722) does not allow PAM use and no passwords,
  allows only one user(name) and uses an alternative autorized_keys file
  (that only root can edit).

  Any parameter FIRST encountered in sshd_config is the one that is
  accepted; others do not override (like in many other config files).
  There is one exception: 'Port', which is accumulative. To make life
  easier, I set the more restrictive parameters for port 7722 first and
  next include the system-default /etc/ssh/sshd_config.

  The /etc/ssh/sshd_config file(s) in Ubuntu Server 20.04 DO NOT specify
  'Port' anywhere - the default is 22. But: it is obviously still
  accumulative: Setting 'Port' to 7722 makes sshd listen on port 7722
  AND 22. This is unwanted.

  Proposed solution: Remove the accumulative behavior for 'Port' and
  REQUIRE the 'Port' parameter like before (and maybe have second and
  later parameters override the earlier ones, like 'everyone else').

  Regards,

  Adriaan

  PS Searching for solutions, I found that specifying 'ListenAddress
  0.0.0.0:7722' stops sshd from listening to port 22. This, however, is
  not documented in 'man 5 sshd_config' and may be an unreliable side-
  effect.

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

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


[Touch-packages] [Bug 1874953] Re: package smartmontools 7.1-1build1 failed to install/upgrade: conffile difference visualizer subprocess returned error exit status 127

2020-05-28 Thread Paride Legovini
Hi! I agree, this:

less (551-1) sid; urgency=low
  * move binaries back to /usr/bin (closes: #500092)

is almost certainly related. If during the upgrade process the new
'less' package is unpacked but not configured yet, there's a window
where the pager alternative points to the wrong location.

I can't see an easy way to fix this. What the linked Debian bug
suggests, that is: make dpkg fallback to more(1) if $PAGER is not
available, is probably the right balance between making dpkg solid and
not adding an overly complex logic for what basically is a one-off
failure.

** Summary changed:

- package smartmontools 7.1-1build1 failed to install/upgrade: conffile 
difference visualizer subprocess returned error exit status 127
+ dpkg: conffile difference visualizer subprocess returned error exit status 127

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

Title:
  dpkg: conffile difference visualizer subprocess returned error exit
  status 127

Status in dpkg package in Ubuntu:
  Triaged
Status in less package in Ubuntu:
  Confirmed
Status in smartmontools package in Ubuntu:
  Invalid
Status in dpkg package in Debian:
  Unknown

Bug description:
  Issue occurred on upgrade from 19.10 to 20.04

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: smartmontools 7.1-1build1
  ProcVersionSignature: Ubuntu 5.3.0-46.38-generic 5.3.18
  Uname: Linux 5.3.0-46-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Apr 24 21:33:08 2020
  ErrorMessage: conffile difference visualizer subprocess returned error exit 
status 127
  InstallationDate: Installed on 2011-06-18 (3233 days ago)
  InstallationMedia: Ubuntu-Server 11.04 "Natty Narwhal" - Release amd64 
(20110426)
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 
2.7.17-4
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2
  SourcePackage: smartmontools
  Title: package smartmontools 7.1-1build1 failed to install/upgrade: conffile 
difference visualizer subprocess returned error exit status 127
  UpgradeStatus: Upgraded to focal on 2020-04-25 (0 days ago)
  mtime.conffile..etc.default.smartmontools: 2017-12-08T19:12:02.064375
  mtime.conffile..etc.smartd.conf: 2017-12-08T20:27:28.727282

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

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


[Touch-packages] [Bug 1876320] Re: Port parameter sshd_config is 22 AND whatever you specify

2020-05-28 Thread Paride Legovini
The upstream bug now has a patch attached, so I'm tagging this server-
next.

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

Title:
  Port parameter sshd_config is 22 AND whatever you specify

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

Bug description:
  On my Ubuntu Server 20.04 LTS with OpenSSH 1:8.2p1-4, I have TWO sshd
  deamons. One (on port 22) is for internal use, accepts passwords etc.
  The second (on port 7722) does not allow PAM use and no passwords,
  allows only one user(name) and uses an alternative autorized_keys file
  (that only root can edit).

  Any parameter FIRST encountered in sshd_config is the one that is
  accepted; others do not override (like in many other config files).
  There is one exception: 'Port', which is accumulative. To make life
  easier, I set the more restrictive parameters for port 7722 first and
  next include the system-default /etc/ssh/sshd_config.

  The /etc/ssh/sshd_config file(s) in Ubuntu Server 20.04 DO NOT specify
  'Port' anywhere - the default is 22. But: it is obviously still
  accumulative: Setting 'Port' to 7722 makes sshd listen on port 7722
  AND 22. This is unwanted.

  Proposed solution: Remove the accumulative behavior for 'Port' and
  REQUIRE the 'Port' parameter like before (and maybe have second and
  later parameters override the earlier ones, like 'everyone else').

  Regards,

  Adriaan

  PS Searching for solutions, I found that specifying 'ListenAddress
  0.0.0.0:7722' stops sshd from listening to port 22. This, however, is
  not documented in 'man 5 sshd_config' and may be an unreliable side-
  effect.

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

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


[Touch-packages] [Bug 1876320] Re: Port parameter sshd_config is 22 AND whatever you specify

2020-05-25 Thread Paride Legovini
Excellent, thanks Adriaan! I linked this bug report to the upstream bug,
so its status will be automatically monitored by Launchpad.

** Also affects: openssh via
   https://bugzilla.mindrot.org/show_bug.cgi?id=3169
   Importance: Unknown
   Status: Unknown

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

Title:
  Port parameter sshd_config is 22 AND whatever you specify

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

Bug description:
  On my Ubuntu Server 20.04 LTS with OpenSSH 1:8.2p1-4, I have TWO sshd
  deamons. One (on port 22) is for internal use, accepts passwords etc.
  The second (on port 7722) does not allow PAM use and no passwords,
  allows only one user(name) and uses an alternative autorized_keys file
  (that only root can edit).

  Any parameter FIRST encountered in sshd_config is the one that is
  accepted; others do not override (like in many other config files).
  There is one exception: 'Port', which is accumulative. To make life
  easier, I set the more restrictive parameters for port 7722 first and
  next include the system-default /etc/ssh/sshd_config.

  The /etc/ssh/sshd_config file(s) in Ubuntu Server 20.04 DO NOT specify
  'Port' anywhere - the default is 22. But: it is obviously still
  accumulative: Setting 'Port' to 7722 makes sshd listen on port 7722
  AND 22. This is unwanted.

  Proposed solution: Remove the accumulative behavior for 'Port' and
  REQUIRE the 'Port' parameter like before (and maybe have second and
  later parameters override the earlier ones, like 'everyone else').

  Regards,

  Adriaan

  PS Searching for solutions, I found that specifying 'ListenAddress
  0.0.0.0:7722' stops sshd from listening to port 22. This, however, is
  not documented in 'man 5 sshd_config' and may be an unreliable side-
  effect.

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

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


[Touch-packages] [Bug 1878723] Re: Kernel panic when used with upstart after 0.11-4ubuntu2.1 update

2020-05-15 Thread Paride Legovini
** Changed in: json-c (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  Kernel panic when used with upstart after 0.11-4ubuntu2.1 update

Status in json-c package in Ubuntu:
  Confirmed

Bug description:
  Installing the 0.11-4ubuntu2.1 security update on a Xenial system with
  upstart installed, the system crashes with a kernel panic.

  The error message is:

  [   99.992278] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0100
  [   99.992278] 
  [   99.996057] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-1105-aws #116-Ubuntu
  [   99.996057] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
  [   99.996057]  0086 0f10ff6977efbf32 88003d45fe10 
8140926b
  [   99.996057]  81caddf8 88003d45fea8 88003d45fe98 
81195a84
  [   99.996057]  8810 88003d45fea8 88003d45fe40 
0f10ff6977efbf32
  [   99.996057] Call Trace:
  [   99.996057]  [] dump_stack+0x6d/0x92
  [   99.996057]  [] panic+0xd3/0x227
  [   99.996057]  [] do_exit+0xb9d/0xba0
  [   99.996057]  [] do_group_exit+0x47/0xb0
  [   99.996057]  [] SyS_exit_group+0x14/0x20
  [   99.996057]  [] entry_SYSCALL_64_fastpath+0x22/0xcb
  [   99.996057] Kernel Offset: disabled

  Downgrading to libjson-c2_0.11-4ubuntu2 resolves the issue.

  Steps to reproduce:
  * Create a system with Xenial installed (I'm using an AWS instance with AMI 
ami-0f2ed58082cb08a4d)
  * Install upstart: apt-get install upstart-sysv
  * Reboot
  * Update apt and upgrade the packages: apt-get update && apt-get upgrade . 
This causes the kernel panic.
  * To repeat the kernel panic, run dpkg --configure -a

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/json-c/+bug/1878723/+subscriptions

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


[Touch-packages] [Bug 1659719] Re: ssh can't call a binary from a snap without the full path

2020-05-14 Thread Paride Legovini
+1, tweaking /etc/environment makes it work. It seems that this has to
be fixed in the libpam-modules postinst script then.

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

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

Title:
  ssh can't call a binary from a snap without the full path

Status in Snappy:
  Fix Committed
Status in livecd-rootfs package in Ubuntu:
  Fix Committed
Status in openssh package in Ubuntu:
  Confirmed
Status in pam package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Confirmed

Bug description:
  ssh can't call a binary from a snap, it will only work using the full
  path.

  Let's say I have the hello snap installed in 192.168.122.24. Then:

  elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 hello
  elopio@192.168.122.24's password:
  bash: hello: command not found
  elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 /snap/bin/hello
  elopio@192.168.122.24's password:
  Hello, world!

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

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


[Touch-packages] [Bug 1876320] Re: Port parameter sshd_config is 22 AND whatever you specify

2020-05-05 Thread Paride Legovini
@Adriaan thanks for providing some minimal steps to reproduce the
problem, I indeed can reproduce it. Interestingly reversing the two
sshd_config lines, like this:

  Port 7722
  Include /etc/ssh/something_else

causes sshd to listen only on port 7722. I think this is an upstream
OpenSSH bug, and should be reported to the upstream portable OpenSSH bug
tracker:

  https://bugzilla.mindrot.org/

I had a look at the existing bugs but only found this one related to the
Include functionality:

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

It's a problem specific to Match stanzas, so I don't think it applies
here, however it tells us there are probably still some edge cases to
iron out. Do you think you can follow up and file a bug upstream? If you
do, please link to it here. Thanks!

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

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

Title:
  Port parameter sshd_config is 22 AND whatever you specify

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  On my Ubuntu Server 20.04 LTS with OpenSSH 1:8.2p1-4, I have TWO sshd
  deamons. One (on port 22) is for internal use, accepts passwords etc.
  The second (on port 7722) does not allow PAM use and no passwords,
  allows only one user(name) and uses an alternative autorized_keys file
  (that only root can edit).

  Any parameter FIRST encountered in sshd_config is the one that is
  accepted; others do not override (like in many other config files).
  There is one exception: 'Port', which is accumulative. To make life
  easier, I set the more restrictive parameters for port 7722 first and
  next include the system-default /etc/ssh/sshd_config.

  The /etc/ssh/sshd_config file(s) in Ubuntu Server 20.04 DO NOT specify
  'Port' anywhere - the default is 22. But: it is obviously still
  accumulative: Setting 'Port' to 7722 makes sshd listen on port 7722
  AND 22. This is unwanted.

  Proposed solution: Remove the accumulative behavior for 'Port' and
  REQUIRE the 'Port' parameter like before (and maybe have second and
  later parameters override the earlier ones, like 'everyone else').

  Regards,

  Adriaan

  PS Searching for solutions, I found that specifying 'ListenAddress
  0.0.0.0:7722' stops sshd from listening to port 22. This, however, is
  not documented in 'man 5 sshd_config' and may be an unreliable side-
  effect.

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

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


[Touch-packages] [Bug 1851695] Re: DEP8 failure/regression in nspr on arm64 and armhf

2020-04-30 Thread Paride Legovini
Fix released in Focal with version 0.6.1~ds2-5.

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

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

Title:
  DEP8 failure/regression in nspr on arm64 and armhf

Status in notary package in Ubuntu:
  Fix Released
Status in nspr package in Ubuntu:
  Invalid
Status in notary package in Debian:
  Fix Released

Bug description:
  nspr 0.6.1~ds1-4 is failing DEP8 test in arm64 and armhf:

  
  autopkgtest [09:46:25]: test command1: /usr/bin/dh_golang_autopkgtest
  autopkgtest [09:46:25]: test command1: [---
  [info] Testing github.com/theupdateframework/notary...
  [info] Source code installed by binary package, overriding 
dh_auto_configure...
  [info] Disabling existing override_dh_auto_configure...
  dh build --builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build \
--buildsystem=golang \
--with=golang
 dh_update_autotools_config 
-O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build 
-O--buildsystem=golang
 dh_autoreconf 
-O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build 
-O--buildsystem=golang
 debian/rules override_dh_auto_configure
  make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
  mkdir -p "_build"
  cp -a /usr/share/gocode/src "_build"
  make[1]: Leaving directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
 debian/rules override_dh_auto_build
  make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
  dh_auto_build -- -tags "pkcs11"
cd _build && go install 
-gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-v -p 1 -tags pkcs11 github.com/theupdateframework/notary 
github.com/theupdateframework/notary/client 
github.com/theupdateframework/notary/client/changelist 
github.com/theupdateframework/notary/cmd/escrow 
github.com/theupdateframework/notary/cmd/notary 
github.com/theupdateframework/notary/cmd/notary-server 
github.com/theupdateframework/notary/cmd/notary-signer 
github.com/theupdateframework/notary/cryptoservice 
github.com/theupdateframework/notary/passphrase 
github.com/theupdateframework/notary/proto 
github.com/theupdateframework/notary/server 
github.com/theupdateframework/notary/server/errors 
github.com/theupdateframework/notary/server/handlers 
github.com/theupdateframework/notary/server/snapshot 
github.com/theupdateframework/notary/server/storage 
github.com/theupdateframework/notary/server/timestamp 
github.com/theupdateframework/notary/signer 
github.com/theupdateframework/notary/signer/api 
github.com/theupdateframework/notary/signer/client 
github.com/theupdateframework/notary/signer/keydbstore 
github.com/theupdateframework/notary/storage 
github.com/theupdateframework/notary/storage/rethinkdb 
github.com/theupdateframework/notary/trustmanager 
github.com/theupdateframework/notary/trustmanager/remoteks 
github.com/theupdateframework/notary/trustmanager/yubikey 
github.com/theupdateframework/notary/trustpinning 
github.com/theupdateframework/notary/tuf 
github.com/theupdateframework/notary/tuf/data 
github.com/theupdateframework/notary/tuf/signed 
github.com/theupdateframework/notary/tuf/testutils 
github.com/theupdateframework/notary/tuf/testutils/interfaces 
github.com/theupdateframework/notary/tuf/testutils/keys 
github.com/theupdateframework/notary/tuf/utils 
github.com/theupdateframework/notary/tuf/validation 
github.com/theupdateframework/notary/utils 
github.com/theupdateframework/notary/version
  src/github.com/docker/distribution/digestset/set.go:9:2: cannot find package 
"github.com/opencontainers/go-digest" in any of:

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/go-digest
 (vendor tree)
/usr/lib/go-1.12/src/github.com/opencontainers/go-digest (from $GOROOT)

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/go-digest
 (from $GOPATH)
  src/github.com/docker/distribution/blobs.go:13:2: cannot find package 
"github.com/opencontainers/image-spec/specs-go/v1" in any of:

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/image-spec/specs-go/v1
 (vendor tree)
/usr/lib/go-1.12/src/github.com/opencontainers/image-spec/specs-go/v1 
(from $GOROOT)

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/image-spec/specs-go/v1
 (from $GOPATH)
  dh_auto_build: cd _build && go install 
-gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-v -p 1 -tags pkcs11 github.com/theupdateframework/notary 

[Touch-packages] [Bug 1870932] Re: ssh-add -L incorrectly reports a failure when successfully retrieving an empty identity list

2020-04-30 Thread Paride Legovini
Hi Kike, I'm marking this bug report as Invalid, per your request.
Thanks for taking the time to file it!

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

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

Title:
  ssh-add -L incorrectly reports a failure when successfully retrieving
  an empty identity list

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  Example of behavior:

  ```
  mikemol@kaylee:~$ ssh-add -L
  The agent has no identities.
  mikemol@kaylee:~$ echo $?
  1
  mikemol@kaylee:~$
  ```

  I expected an exit code of 0 if the agent was running. I don't need
  the list of identities; I'm trying to validate that the agent is
  running, accessible, and operational.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssh-client 1:7.6p1-4ubuntu0.3
  ProcVersionSignature: Ubuntu 4.15.0-69.78-generic 4.15.18
  Uname: Linux 4.15.0-69-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.14
  Architecture: amd64
  Date: Sun Apr  5 10:38:25 2020
  InstallationDate: Installed on 2018-12-16 (475 days ago)
  InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  RelatedPackageVersions:
   ssh-askpass   N/A
   libpam-sshN/A
   keychain  N/A
   ssh-askpass-gnome N/A
  SSHClientVersion: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
  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/1870932/+subscriptions

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


[Touch-packages] [Bug 1868474] Re: 20.04 Xorg doesn't detect/load Elantech mouse driver on Lenovo P73

2020-03-24 Thread Paride Legovini
Reassigned to package xorg.

** Package changed: init-system-helpers (Ubuntu) => xorg (Ubuntu)

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

Title:
  20.04 Xorg doesn't detect/load Elantech mouse driver on Lenovo P73

Status in xorg package in Ubuntu:
  New

Bug description:
  The installation scripts loads the correct drivers so the touch pad
  and pointer works during the install. However after the install
  neither work.

  I've worked around it by using a wireless USB from Vilros for mouse input 
while logging in. Then issuing (found on 
https://askubuntu.com/questions/1143663):
   sudo 'echo -n "elantech">/sys/bus/serio/devices/serio1/protocol'

  So it's a bug for me but one I can work around and should be fixed
  before 20.04 goes live.

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

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


[Touch-packages] [Bug 1868473] Re: 20.04 Install screen corrupt on Lenovo P73+NVIDEA RTX-5000

2020-03-24 Thread Paride Legovini
Hello and thanks for filing this bug report. This report has been filed
against the init-system-helpers package, but according to the bug
description it does not seem to be the correct package.

As the problem is related to the Desktop installer I'm reassigning the
report to the casper package.

** Package changed: init-system-helpers (Ubuntu) => casper (Ubuntu)

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

Title:
  20.04 Install screen corrupt on Lenovo P73+NVIDEA RTX-5000

Status in casper package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo P73 with NVIDEA RTX-5000 QMax

  20.04 Daily Build install.

  On using the USB drive for a new install the screen is corrupt. This can be 
worked around by:
  1. Waiting for Focal Fossa to give the sound showing the splash screen.
  2. Closing the screen so it goes into sleep mode.
  3. Open the screen and hit the power button to wake the system.
  4. Wait a second or two and screen loads correctly and the rest of the 
install works beautifully.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: init 1.57
  ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
  Uname: Linux 5.4.0-18-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Mar 22 08:27:04 2020
  InstallationDate: Installed on 2020-03-21 (1 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200315)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: init-system-helpers
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


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

2019-12-12 Thread Paride Legovini
Thank you for your feedback. @Stoo: if `rsync -vvv` is the culprit then
[1] is the right upstream bug, however there are so many (mostly stale)
"rsync hangs" upstream bugs [2] that I'm not sure which one is the
correct one to follow-up to here. The command in the description of this
report only has a single -v after all.

I think it won't be easy to make progress here without a reliable way to
reproduce the issue and without the involvement of the upstream
developers. What I suggest is to try to narrow the steps needed to
reproduce the hang, check if it still affects the latest upstream
release, and try to make the most appropriate bug move forward.

[1] https://bugzilla.samba.org/show_bug.cgi?id=11166
[2] https://bugzilla.samba.org/show_bug.cgi?id=11166#c2

** Bug watch added: Samba Bugzilla #11166
   https://bugzilla.samba.org/show_bug.cgi?id=11166

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

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

Status in rsync package in Ubuntu:
  Confirmed

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

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

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

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

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


  lsb_release -rd
  Description:Ubuntu 14.04.3 LTS
  Release:14.04

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

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

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

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


[Touch-packages] [Bug 1856008] Re: issuse

2019-12-12 Thread Paride Legovini
Thank you for taking the time to report this bug and helping to make
Ubuntu better. Packages from third-party repositories can interfere with
the way Ubuntu resolves and installs dependencies. Even if you now
disabled the third party repositories the packages you installed
(possibly during a system upgrade) were not removed.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers
to get help for this sort of problem here:
https://discourse.ubuntu.com/t/community-support/709

Or if you believe that this is really a bug, then you may find it
helpful to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

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

** Summary changed:

- issuse
+ openssh-server: Depends: openssh-client (= 1:8.0p1-6build1) but it is not 
installed

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

Title:
  openssh-server: Depends: openssh-client (= 1:8.0p1-6build1) but it is
  not installed

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  Check if you are using third party repositories. If so disable them, since 
they are a common source of problems.
  Furthermore run the following command in a Terminal: apt-get install -f
  Transaction failed: The package system is broken
   The following packages have unmet dependencies:

  openssh-server: Depends: openssh-client (= 1:8.0p1-6build1) but it is not 
installed
  openssh-sftp-server: Depends: openssh-client (= 1:8.0p1-6build1) but it is 
not installed

  
  i will not installed the open ssh server

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

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


[Touch-packages] [Bug 1463846] Re: if ip is specified on cmdline, networking should be brought up in initramfs

2019-12-05 Thread Paride Legovini
** Also affects: initramfs-tools (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789067
   Importance: Unknown
   Status: Unknown

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

Title:
  if ip is specified on cmdline, networking should be brought up in
  initramfs

Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Triaged
Status in initramfs-tools package in Debian:
  Unknown

Bug description:
  if the initramfs has 'ip=' on the cmdline, it is arguable that we
  should bring the respective interface up as indicated.

  Currently, initramfs only does this if something thinks it should.

  Ie, open-iscsi might do it, or some other things might call 
'configure_networking'.
  But it seems reasonable that if the user put 'ip=' on the cmdline then they 
wanted that to happen in initramfs.

  Additionally, one feature i'd like to have (admittedly for debug
  purposes) is the ability to write the /run/initramfs/open-
  iscsi.interface file that is used at least by open-iscsi to say "do
  not bring this interface down".

  
  I've done this before, the code to do it is available in intramfs-tools style 
module at
    
http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/files/head:/ephemtest-vivid/initrd-updates/

  generically, it seems like it'd be nice to have a way to have the same
  functionality that open-iscsi.interface accomplishes but not tied to
  open-iscsi.  Ie, the user may for any reason want to keep a network
  from getting re-configured by normal OS bringup.   I used
  '/run/network/initramfs-persistent-iface' file to do that.

  that is explicitly to patch over an existing initramfs  (no 'hooks'
  directory).

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

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


[Touch-packages] [Bug 299158] Re: DejaVu, Liberation Mono, Noto Mono, Tlwg Mono, Oxygen Mono, Bitstream Vera Mono: Combining diacritics out of place

2019-12-04 Thread Paride Legovini
Maintainer of the fonts-hack Debian package here. I can't reproduce the
issue with fonts-hack 3.003-3 on Eoan, I get the expected result, i.e.:

* Two grapheme clusters are displayed: Latin small letter a with acute
accent, Latin small letter e.

On which Ubuntu release are you observing it?

** Changed in: fonts-hack (Ubuntu)
   Status: New => Incomplete

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

Title:
  DejaVu, Liberation Mono, Noto Mono, Tlwg Mono, Oxygen Mono, Bitstream
  Vera Mono: Combining diacritics out of place

Status in fonts-dejavu package in Ubuntu:
  Confirmed
Status in fonts-droid package in Ubuntu:
  Won't Fix
Status in fonts-hack package in Ubuntu:
  Incomplete
Status in fonts-liberation package in Ubuntu:
  Confirmed
Status in fonts-noto package in Ubuntu:
  New
Status in fonts-tlwg package in Ubuntu:
  New
Status in fonts-ubuntu package in Ubuntu:
  New
Status in msttcorefonts package in Ubuntu:
  Won't Fix
Status in oxygen-fonts package in Ubuntu:
  New
Status in ttf-bitstream-vera package in Ubuntu:
  New

Bug description:
  In the Liberation Mono font, combining diacritical marks are drawn
  over the following character rather than the preceding.

  According to the Unicode standard since at least version 3.0, chapter
  3.6, verse D56, combining characters apply to the preceding base
  character. However, this font renders them on the following base
  character.

  Version info:
  Ubuntu Intrepid
  ttf-liberation 1.04~beta2-2

  To reproduce:
  1. Open gedit.
  2. Type the following three code points: U+0061 U+0301 U+0065 (Latin small 
letter a, Combining acute accent, Latin small letter e).
  3. Via Edit|Preferences|Font & Colors|Font, select the Liberation Mono font.

  Expected:
  * Two grapheme clusters are displayed: Latin small letter a with acute 
accent, Latin small letter e.

  Observed:
  * The grapheme clusters displayed are: Latin small letter a, Latin small 
letter e with acute accent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fonts-dejavu/+bug/299158/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-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

2019-12-03 Thread Paride Legovini
** Changed in: dnsmasq (Ubuntu)
   Status: Confirmed => Triaged

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

Title:
  missing EDNS0 record confuses systemd-resolved

Status in dnsmasq package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  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.

  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

  Simple-ish test case:

  ---
  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 &

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

  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/ubuntu/+source/dnsmasq/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

2019-10-23 Thread Paride Legovini
Bug status updated accordingly. I set the linux task to Invalid as the
kernel was not involved after all. Thanks again Stéphane and Colin!

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

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

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

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

** No longer affects: linux (Ubuntu Eoan)

** No longer affects: linux (Ubuntu Disco)

** No longer affects: linux (Ubuntu Cosmic)

** Changed in: linux (Ubuntu)
   Status: Triaged => Invalid

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

Title:
  lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

Status in linux package in Ubuntu:
  Invalid
Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Cosmic:
  Fix Released
Status in lxc source package in Disco:
  Fix Released
Status in lxc source package in Eoan:
  Fix Released

Bug description:
  I'm not sure exactly what got me into this state, but I have several
  lxc containers that cannot be deleted.

  $ lxc info
  
  api_status: stable
  api_version: "1.0"
  auth: trusted
  public: false
  auth_methods:
  - tls
  environment:
addresses: []
architectures:
- x86_64
- i686
certificate: |
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
certificate_fingerprint: 
3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb
driver: lxc
driver_version: 3.0.1
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.15.0-23-generic
server: lxd
server_pid: 15123
server_version: "3.2"
storage: zfs
storage_version: 0.7.5-1ubuntu15
server_clustered: false
server_name: milhouse

  $ lxc delete --force b1
  Error: Failed to destroy ZFS filesystem: cannot destroy 
'default/containers/b1': dataset is busy

  Talking in #lxc-dev, stgraber and sforeshee provided diagnosis:

   | short version is that something unshared a mount namespace causing
   | them to get a copy of the mount table at the time that dataset was
   | mounted, which then prevents zfs from being able to destroy it)

  The work around provided was

   | you can unstick this particular issue by doing:
   |  grep default/containers/b1 /proc/*/mountinfo
   | then for any of the hits, do:
   |   nsenter -t PID -m -- umount 
/var/snap/lxd/common/lxd/storage-pools/default/containers/b1
   | then try the delete again

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: linux-image-4.15.0-23-generic 4.15.0-23.25
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  smoser31412 F pulseaudio
   /dev/snd/controlC2:  smoser31412 F pulseaudio
   /dev/snd/controlC0:  smoser31412 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 10:42:45 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1071 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  MachineType: 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-23-generic N/A
   linux-backports-modules-4.15.0-23-generic  N/A
   linux-firmware 1.174
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/09/2015
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355
  dmi.board.asset.tag: �
  dmi.board.name: NUC5i5RYB
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H40999-503
  dmi.chassis.asset.tag: �
  dmi.chassis.type: 3
  dmi.chassis.vendor: �
  dmi.chassis.version: �
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr:
  dmi.product.family: �
  dmi.product.name: 

[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

2019-10-23 Thread Paride Legovini
The current stable snap seems to fully address the issue. See:

https://github.com/lxc/lxd/issues/4656#issuecomment-542886330

and following.

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

Title:
  lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

Status in linux package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Confirmed
Status in linux source package in Cosmic:
  Triaged
Status in lxc source package in Cosmic:
  Confirmed
Status in linux source package in Disco:
  New
Status in lxc source package in Disco:
  New
Status in linux source package in Eoan:
  Triaged
Status in lxc source package in Eoan:
  Confirmed

Bug description:
  I'm not sure exactly what got me into this state, but I have several
  lxc containers that cannot be deleted.

  $ lxc info
  
  api_status: stable
  api_version: "1.0"
  auth: trusted
  public: false
  auth_methods:
  - tls
  environment:
addresses: []
architectures:
- x86_64
- i686
certificate: |
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
certificate_fingerprint: 
3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb
driver: lxc
driver_version: 3.0.1
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.15.0-23-generic
server: lxd
server_pid: 15123
server_version: "3.2"
storage: zfs
storage_version: 0.7.5-1ubuntu15
server_clustered: false
server_name: milhouse

  $ lxc delete --force b1
  Error: Failed to destroy ZFS filesystem: cannot destroy 
'default/containers/b1': dataset is busy

  Talking in #lxc-dev, stgraber and sforeshee provided diagnosis:

   | short version is that something unshared a mount namespace causing
   | them to get a copy of the mount table at the time that dataset was
   | mounted, which then prevents zfs from being able to destroy it)

  The work around provided was

   | you can unstick this particular issue by doing:
   |  grep default/containers/b1 /proc/*/mountinfo
   | then for any of the hits, do:
   |   nsenter -t PID -m -- umount 
/var/snap/lxd/common/lxd/storage-pools/default/containers/b1
   | then try the delete again

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: linux-image-4.15.0-23-generic 4.15.0-23.25
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  smoser31412 F pulseaudio
   /dev/snd/controlC2:  smoser31412 F pulseaudio
   /dev/snd/controlC0:  smoser31412 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 10:42:45 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1071 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  MachineType: 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-23-generic N/A
   linux-backports-modules-4.15.0-23-generic  N/A
   linux-firmware 1.174
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/09/2015
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355
  dmi.board.asset.tag: �
  dmi.board.name: NUC5i5RYB
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H40999-503
  dmi.chassis.asset.tag: �
  dmi.chassis.type: 3
  dmi.chassis.vendor: �
  dmi.chassis.version: �
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr:
  dmi.product.family: �
  dmi.product.name: �
  dmi.product.version: �
  dmi.sys.vendor: �

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

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

[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

2019-10-16 Thread Paride Legovini
The released fix does not appear to fully address the problem:

https://github.com/lxc/lxd/issues/4656#issuecomment-542630903

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

Title:
  lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

Status in linux package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Confirmed
Status in linux source package in Cosmic:
  Triaged
Status in lxc source package in Cosmic:
  Confirmed
Status in linux source package in Disco:
  New
Status in lxc source package in Disco:
  New
Status in linux source package in Eoan:
  Triaged
Status in lxc source package in Eoan:
  Confirmed

Bug description:
  I'm not sure exactly what got me into this state, but I have several
  lxc containers that cannot be deleted.

  $ lxc info
  
  api_status: stable
  api_version: "1.0"
  auth: trusted
  public: false
  auth_methods:
  - tls
  environment:
addresses: []
architectures:
- x86_64
- i686
certificate: |
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
certificate_fingerprint: 
3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb
driver: lxc
driver_version: 3.0.1
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.15.0-23-generic
server: lxd
server_pid: 15123
server_version: "3.2"
storage: zfs
storage_version: 0.7.5-1ubuntu15
server_clustered: false
server_name: milhouse

  $ lxc delete --force b1
  Error: Failed to destroy ZFS filesystem: cannot destroy 
'default/containers/b1': dataset is busy

  Talking in #lxc-dev, stgraber and sforeshee provided diagnosis:

   | short version is that something unshared a mount namespace causing
   | them to get a copy of the mount table at the time that dataset was
   | mounted, which then prevents zfs from being able to destroy it)

  The work around provided was

   | you can unstick this particular issue by doing:
   |  grep default/containers/b1 /proc/*/mountinfo
   | then for any of the hits, do:
   |   nsenter -t PID -m -- umount 
/var/snap/lxd/common/lxd/storage-pools/default/containers/b1
   | then try the delete again

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: linux-image-4.15.0-23-generic 4.15.0-23.25
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  smoser31412 F pulseaudio
   /dev/snd/controlC2:  smoser31412 F pulseaudio
   /dev/snd/controlC0:  smoser31412 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 10:42:45 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1071 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  MachineType: 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-23-generic N/A
   linux-backports-modules-4.15.0-23-generic  N/A
   linux-firmware 1.174
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/09/2015
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355
  dmi.board.asset.tag: �
  dmi.board.name: NUC5i5RYB
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H40999-503
  dmi.chassis.asset.tag: �
  dmi.chassis.type: 3
  dmi.chassis.vendor: �
  dmi.chassis.version: �
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr:
  dmi.product.family: �
  dmi.product.name: �
  dmi.product.version: �
  dmi.sys.vendor: �

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

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

[Touch-packages] [Bug 1846506] Re: autopkgtest fail in Eoan

2019-10-08 Thread Paride Legovini
** Also affects: python3-defaults (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  autopkgtest fail in Eoan

Status in python-azure package in Ubuntu:
  New
Status in python-cryptography package in Ubuntu:
  New
Status in python3-defaults package in Ubuntu:
  New

Bug description:
  The python-azure autopkgtest is failing on Eoan, currently blocking
  the migration of:

   - python-cryptography
   - python-defaults

  I had a look at the test log but it's not clear to me where the
  problem is. The autopkgtest history suggests that the failure is not
  actually caused by the two packages held in the migration queue. The
  python-azure autopkgtest is python3-only.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-azure/+bug/1846506/+subscriptions

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


[Touch-packages] [Bug 1838525] Re: LVM setup fails to install grub on virtio storage

2019-10-08 Thread Paride Legovini
Thanks Rafael, Andreas and everybody for the great work done here! I
successfully tested your fix as follows:

1. Followed the steps in the original description of this
   bug up the point where the installer tries to install
   grub to /dev/mapper and fails.

2. Replaced /target/usr/sbin/grub-mkdevicemap with the
   one extracted from the grub-common package in your PPA.

3. Retried the "install boot loader" installer step.

4. Success!

Funny how the original grub-mkdevicemap and your fixed version have the
same size up to the byte.

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

Title:
  LVM setup fails to install grub on virtio storage

Status in debian-installer package in Ubuntu:
  In Progress
Status in grub2 package in Ubuntu:
  In Progress
Status in lvm2 package in Ubuntu:
  In Progress
Status in debian-installer package in Debian:
  New

Bug description:
  [Impact]

   * Any Eoan installation that depends on latest installer will face
  this issue when final user chooses LVM full disk partitioning type.

   * Grub won't be able to install due to bad bootdevice variable in the
  installer. It will try to install grub to "/dev/mapper" and will fail.
  The default boot option will also be "/dev/mapper".

  [Test Case]

   * Download netboot files from current installer (vmlinuz and initrd
  files).

   * Create a KVM guest running from these files, with a NIC connected
  to the internet.

   * Initiate a network installation inside the KVM guest, choosing the
  Entire Disk - LVM partitioning option.

   * Wait installation to finish and to start the grub-install phase. It
  will ask where to install grub, having, as default, "/dev/mapper". By
  default, it might simply try to grub-install /dev/mapper, which will
  also fail.

   * That happens because /dev/disk/by-id/ has an unexpected (by the
  installer) symlink added by lvm2 package that grub-installer (used by
  debian-installer) does not expect (when using grub-mkdevice command).

  [Simplified Test Case]

   * To add a PV + VG + LVM in a KVM guest to an empty virtio disk, for
  example, and to check if the command:

  grub-mkdevicemap --no-floppy -m -

  lists /dev/vdX1 in front of /dev/vdX. This will be a sign that:

  /dev/disk/by-id/*lvm* file exists and will be enough to confuse
  installer.

  [Regression Potential]

  There are 3 alternatives to fix this and I have chosen the one I
  believe has the smaller potential for any type of regression. Comment
  #30 describes what caused the regression and these 3 alternatives:

  (1) To revert this change for current release, since this rule was
  added to "make navigation a bit easier using PV UUIDs", as the commit
  says. We would worry about installer changes in the next release.

  (2) Another possibility would be to change the logic inside "grub-
  mkdevicemap.c: make_device_map()->grub_util_iterate_devices()" to
  ignore all symlinks from /dev/disk/by-id/ containing lvm-pv-uuid-*. We
  would not have to worry about this in the next release if using
  debian-installer.

  (3) Another option would be to change grub-installer package/logic.
  Unfortunately, a few days before the full freeze, I don't think
  messing with the installer would be a good option to avoid regressions
  (potential regression item would grow in significance).

  => I'm choosing (2) because ubuntu foundations already faced a similar
  situation, when grub-mkdevicemap.c file was removed from grub2 code
  and they re-added it by using a quilt patch, assuming it was the
  easiest and better to maintain. I'm doing something similar, patching
  the patch that creates grub-mkdevicemap.c file again to ignore
  /dev/disk/by-id/lvm-pv-uuid-* files (like it already does for other
  symlinks, actually).

  [Other Info]

  Comment #26 has the TL;DR version of the problem.
  
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/comments/26

  [Original Description]

  The Eoan debian-installer ISO fails to install GRUB on LVM installs
  with virtio storage, as it runs grub-install with /dev/mapper as a
  target (a directory), even if instructed to target a device.

  The following steps to reproduce have been prepared running the
  20190730 build, but this has been broken since about June 18, 2019.
  Steps to reproduce:

  $ md5sum eoan-server-amd64.iso
  f591e30485e5f0b5117f6c116e538c42  eoan-server-amd64.iso
  $ qemu-img create -f raw disk1.img 8G
  Formatting 'disk1.img', fmt=raw size=8589934592
  $ kvm -m 1024 -boot d -cdrom eoan-server-amd64.iso -drive 
file=disk1.img,if=virtio

  Proceed with all the defaults. In the "Partition disk" step select
  "Guided - use entire disk and set up LVM". Go ahead accepting the
  defaults. At the "Install the GRUB boot loader" step select "/dev/vda"
  as the target device. The installer will actually run `grub-install
  --force /dev/mapper` and 

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

2019-10-03 Thread Paride Legovini
** Changed in: systemd (Ubuntu)
   Status: Confirmed => Triaged

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

** Changed in: qemu (Ubuntu Disco)
   Status: Confirmed => Triaged

** Changed in: qemu (Ubuntu)
   Status: Confirmed => Triaged

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

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

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

Bug description:
  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  
  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

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

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


[Touch-packages] [Bug 1842255] Re: package libnss3:amd64 2:3.28.4-0ubuntu0.16.04.6 [origin: Ubuntu] failed to install/upgrade: package libnss3:amd64 is already installed and configured

2019-09-02 Thread Paride Legovini
Thanks for your report. From this line of the Bug Description:

  DistroRelease: elementary 0.4.1

it seems that you are not experiencing this issue with Ubuntu, but with
elementary OS. We are not able to investigate problems or provide
support for operating systems different from Ubuntu, even if they derive
from Ubuntu, like in this case. Since we use this bug tracker to track
bugs in Ubuntu, I'm marking this bug as Invalid. If you believe this is
actually a bug in Ubuntu and that elementary OS is inheriting it, please
file a new bug report with all the logs generated and captured on an
Ubuntu system. Thanks!

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

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

Title:
  package libnss3:amd64 2:3.28.4-0ubuntu0.16.04.6 [origin: Ubuntu]
  failed to install/upgrade: package libnss3:amd64 is already installed
  and configured

Status in nss package in Ubuntu:
  Invalid

Bug description:
  No more

  ProblemType: Package
  DistroRelease: elementary 0.4.1
  Package: libnss3:amd64 2:3.28.4-0ubuntu0.16.04.6
  ProcVersionSignature: Ubuntu 4.15.0-58.64~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-58-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.19
  AptdaemonVersion: 1.1.1+bzr982-0ubuntu14.1
  Architecture: amd64
  Date: Sun Sep  1 13:00:20 2019
  DuplicateSignature:
   package:libnss3:amd64:2:3.28.4-0ubuntu0.16.04.6 [origin: Ubuntu]
   Removing linux-modules-4.15.0-43-generic (4.15.0-43.46~16.04.1) ...
   dpkg: error processing package libnss3-nssdb (--configure):
package libnss3-nssdb is already installed and configured
  ErrorMessage: package libnss3:amd64 is already installed and configured
  InstallationDate: Installed on 2018-05-26 (463 days ago)
  InstallationMedia: elementary OS 0.4.1 "Loki" - Stable amd64 (20180214)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32
  SourcePackage: nss
  Title: package libnss3:amd64 2:3.28.4-0ubuntu0.16.04.6 [origin: Ubuntu] 
failed to install/upgrade: package libnss3:amd64 is already installed and 
configured
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

2019-08-30 Thread Paride Legovini
To be clear: point(3) above is what I see happening most of the time at
the moment.

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

Title:
  lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

Status in linux package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Confirmed
Status in linux source package in Cosmic:
  Triaged
Status in lxc source package in Cosmic:
  Confirmed

Bug description:
  I'm not sure exactly what got me into this state, but I have several
  lxc containers that cannot be deleted.

  $ lxc info
  
  api_status: stable
  api_version: "1.0"
  auth: trusted
  public: false
  auth_methods:
  - tls
  environment:
addresses: []
architectures:
- x86_64
- i686
certificate: |
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
certificate_fingerprint: 
3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb
driver: lxc
driver_version: 3.0.1
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.15.0-23-generic
server: lxd
server_pid: 15123
server_version: "3.2"
storage: zfs
storage_version: 0.7.5-1ubuntu15
server_clustered: false
server_name: milhouse

  $ lxc delete --force b1
  Error: Failed to destroy ZFS filesystem: cannot destroy 
'default/containers/b1': dataset is busy

  Talking in #lxc-dev, stgraber and sforeshee provided diagnosis:

   | short version is that something unshared a mount namespace causing
   | them to get a copy of the mount table at the time that dataset was
   | mounted, which then prevents zfs from being able to destroy it)

  The work around provided was

   | you can unstick this particular issue by doing:
   |  grep default/containers/b1 /proc/*/mountinfo
   | then for any of the hits, do:
   |   nsenter -t PID -m -- umount 
/var/snap/lxd/common/lxd/storage-pools/default/containers/b1
   | then try the delete again

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: linux-image-4.15.0-23-generic 4.15.0-23.25
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  smoser31412 F pulseaudio
   /dev/snd/controlC2:  smoser31412 F pulseaudio
   /dev/snd/controlC0:  smoser31412 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 10:42:45 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1071 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  MachineType: 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-23-generic N/A
   linux-backports-modules-4.15.0-23-generic  N/A
   linux-firmware 1.174
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/09/2015
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355
  dmi.board.asset.tag: �
  dmi.board.name: NUC5i5RYB
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H40999-503
  dmi.chassis.asset.tag: �
  dmi.chassis.type: 3
  dmi.chassis.vendor: �
  dmi.chassis.version: �
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr:
  dmi.product.family: �
  dmi.product.name: �
  dmi.product.version: �
  dmi.sys.vendor: �

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

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


[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

2019-08-30 Thread Paride Legovini
Hi,

I hit this issue on Bionic, Disco and Eoan. Our (server-team) Jenkins
nodes are often filled by stale LXD containers which are left there
because of "fails to destroy ZFS filesystem" errors.

Some thoughts and qualitative observations:

0. This is not a corner case, I see the problem all the time.

1. There is probably more than one issue involved here, even we get
similar error messages when trying to delete a container.

2. One issue is about mount namespaces: stray mounts that prevent to the
container to be deleted. This issue can be worked around by entering the
namespace and unmounting. The container can then be deleted. When this
happens retrying `lxd delete` doesn't help. This is described in [0]. I
think the newer versions of LXD are way less prone to end up in this
case.

3. In other cases `lxc delete --force` fails with the "ZFS dataset is
busy" error, but the deletion succeeds if the delete is retried
immediately after. In my case I don't even need to wait for a single
second: the second delete in `lxc delete --force  ; lxc delete `
already works. Stopping and deleting the container as separate
operations also works.

4. It has been suggested in [0] that LXD could retry the "delete"
operation if it fails. stgraber wrote that LXD *already* retries the
operation 20 times over 10 seconds, but the outcome is still a failure.
It is not clear to me how retrying manually works, while LXD auto-
retrying does not.

5. Some time ago (weeks) the error message changed from "Failed to
destroy ZFS filesystem: dataset is busy" to "Failed to destroy ZFS
filesystem:" with no other detail. I can't tell which specific upgrade
triggered this change.

6. I see this problem in both file-backed and device-backed zpools.

7. I'm not sure system load plays a role: I often hit the problem on my
lightly loaded laptop.

8. I don't have clear steps to reproduce the problem, but I personally
see it happening most of the time. While I don't have steps to reproduce
with 100% probability, I'm seeing this more times than I don't. But see
the next point.

9. In my experience a system can be in a "bad state" (the problem always
happens), or in a "good state" (the problem never happens). When the
system is in a "good state" we can `lxc delete` hundreds of containers
with no errors. I can't tell what makes a system switch from a good to a
bad state. I almost certain I also saw systems switching from a bad to a
good state.

10. The lxcfs package it not installed in the systems where I hit this
issue

That's it for the moment. Thanks for looking into this!

Paride

[0] https://github.com/lxc/lxd/issues/4656

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

Title:
  lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

Status in linux package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Confirmed
Status in linux source package in Cosmic:
  Triaged
Status in lxc source package in Cosmic:
  Confirmed

Bug description:
  I'm not sure exactly what got me into this state, but I have several
  lxc containers that cannot be deleted.

  $ lxc info
  
  api_status: stable
  api_version: "1.0"
  auth: trusted
  public: false
  auth_methods:
  - tls
  environment:
addresses: []
architectures:
- x86_64
- i686
certificate: |
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
certificate_fingerprint: 
3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb
driver: lxc
driver_version: 3.0.1
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.15.0-23-generic
server: lxd
server_pid: 15123
server_version: "3.2"
storage: zfs
storage_version: 0.7.5-1ubuntu15
server_clustered: false
server_name: milhouse

  $ lxc delete --force b1
  Error: Failed to destroy ZFS filesystem: cannot destroy 
'default/containers/b1': dataset is busy

  Talking in #lxc-dev, stgraber and sforeshee provided diagnosis:

   | short version is that something unshared a mount namespace causing
   | them to get a copy of the mount table at the time that dataset was
   | mounted, which then prevents zfs from being able to destroy it)

  The work around provided was

   | you can unstick this particular issue by doing:
   |  grep default/containers/b1 /proc/*/mountinfo
   | then for any of the hits, do:
   |   nsenter -t PID -m -- umount 
/var/snap/lxd/common/lxd/storage-pools/default/containers/b1
   | then try the delete again

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: linux-image-4.15.0-23-generic 4.15.0-23.25
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  

[Touch-packages] [Bug 1838436] Re: popt download location broken

2019-08-01 Thread Paride Legovini
I filed a bug in Debian. FIY the original source code is also available
via Git here:

  https://salsa.debian.org/debian/popt/

in the upstream/latest branch.

** Bug watch added: Debian Bug tracker #933635
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933635

** Also affects: popt (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933635
   Importance: Unknown
   Status: Unknown

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

** Changed in: popt (Ubuntu)
   Status: Incomplete => Triaged

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

Title:
  popt download location broken

Status in popt package in Ubuntu:
  Triaged
Status in popt package in Debian:
  Unknown

Bug description:
  rpm5.org disappeared, with download area, home page and CVS repo.

  See also https://bugs.archlinux.org/task/62888?project=1=popt

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

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


[Touch-packages] [Bug 1833039] Re: 18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1

2019-07-02 Thread Paride Legovini
I followed the test steps in the description and I can confirm the fix
works as expected. Thanks Andreas for making a complicated setup so easy
to test!

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

Title:
  18.04/Apache2: rejecting client initiated renegotiation due to openssl
  1.1.1

Status in apache2 package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Invalid
Status in apache2 source package in Bionic:
  In Progress
Status in apache2 source package in Cosmic:
  In Progress

Bug description:
  [Impact]
  Under the following conditions, https connections using client cert 
authentication will suffer a long delay (about 15s if modreqtimeout is enabled, 
more if it is disabled):
  * TLSv1.2
  * client certificate authentication in use
  * a Location, Directory, or other such block defining the client certificate 
authentication for that block only, differing from the SSL vhost as a whole

  This was triggered by the OpenSSL 1.1.1 SRU and was caused by this
  openssl change in SSL_MODE_AUTO_RETRY from disabled to enabled by
  default:
  
https://github.com/openssl/openssl/blob/a4a90a8a3bdcb9336b5c9c15da419e99a87bc6ed/CHANGES#L121-L130

  [Test Case]

  It helps if you have lxd up and running. Otherwise, a VM or even bare
  metal host also works, as long as you stick to the "ubuntu" hostname.

  Launch a container for the release you are testing. The command below is for 
bionic:
  $ lxc launch ubuntu-daily:bionic ubuntu

  Enter the container as root:
  $ lxc exec ubuntu bash

  Verify hostname is "ubuntu":
  # hostname
  ubuntu

  Install apache2:
  apt update && apt install apache2

  Download the following files from this bug report and place them in 
/etc/apache2:
  cd /etc/apache2
  wget 
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274492/+files/cacert.pem
 
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274493/+files/ubuntu.pem
 
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274494/+files/ubuntu.key

  Adjust permissions of the key file:
  chmod 0640 /etc/apache2/ubuntu.key
  chgrp www-data /etc/apache2/ubuntu.key

  Download the client certificate and key files and place them in /root:
  cd /root
  wget 
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274495/+files/client-auth.pem
 
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274496/+files/client-auth.key

  Create this vhost file (caution, lines may wrap, in particular LogFormat: it 
should be one long line):
  cat > /etc/apache2/sites-available/cert-auth-test.conf <
  
  LogLevel info ssl:warn
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html
  LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" 
\"%{User-Agent}i\" protocol=%{SSL_PROTOCOL}x commonName=%{SSL_CLIENT_S_DN_CN}x" 
combined-ssl
  ErrorLog \${APACHE_LOG_DIR}/error.log
  CustomLog \${APACHE_LOG_DIR}/access.log combined-ssl
  SSLEngine on
  SSLCertificateFile  /etc/apache2/ubuntu.pem
  SSLCertificateKeyFile /etc/apache2/ubuntu.key
  SSLCACertificateFile /etc/apache2/cacert.pem
  
  SSLOptions +StdEnvVars
  
  
  SSLOptions +StdEnvVars
  
  
  SSLVerifyClient require
  Require ssl-verify-client
  
  
  
  EOF

  Enable the ssl module and this new vhost we just created:
  a2enmod ssl && a2ensite cert-auth-test.conf

  Restart apache2:
  systemctl restart apache2

  If at this stage you try the following command, it will fail like this 
because no client certificate was provided:
  # curl --output /dev/null https://ubuntu/ --cacert /etc/apache2/cacert.pem
    % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
    0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  curl: (56) OpenSSL SSL_read: error:14094410:SSL 
routines:ssl3_read_bytes:sslv3 alert handshake failure, errno 0

  And the apache error log will confirm the reason:
  [Mon Jul 01 14:10:23.312645 2019] [ssl:error] [pid 1685:tid 140326396421888] 
SSL Library Error: error:1417C0C7:SSL 
routines:tls_process_client_certificate:peer did not return a certificate -- No 
CAs known to server for verification?

  Now retry, but providing the client certificate and key files, and forcing 
TLSv1.2 just to be sure. Due to the bug, the command will stall for about 15 
seconds, but the index.html file will be downloaded:
  # rm -f index.html
  # curl --output index.html https://ubuntu/ --cacert /etc/apache2/cacert.pem 
--cert client-auth.pem --key client-auth.key --tlsv1.2
    % Total% Received % 

[Touch-packages] [Bug 1833039] Re: 18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1

2019-06-27 Thread Paride Legovini
Thanks for the reports and comments. I setup a PPA with patch pointed
out by xnox in comment #7 on bionic's apache2 source package:

  https://launchpad.net/~legovini/+archive/ubuntu/apache2-lp1833039

It would be great to have some feedback on the effectiveness of the
patch. Thank you!

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

Title:
  18.04/Apache2: rejecting client initiated renegotiation due to openssl
  1.1.1

Status in apache2 package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  I am using Apache2 with client certificate authentication.
  Since recently (last week) and without any configuration changes, the 
following errors occur frequently:

  AH02042: rejecting client initiated renegotiation

  Client connections are very slow and sometimes it takes more than a minute 
until a weg page can be opened in the browser.
  Before installation of the latest security fixes last week, this error did 
not occur.

  Could it be related to
  https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1803689?

  
  System information:

  Description:Ubuntu 18.04.2 LTS
  Release:18.04

  apache2:
Installiert:   2.4.29-1ubuntu4.6
Installationskandidat: 2.4.29-1ubuntu4.6
Versionstabelle:
   *** 2.4.29-1ubuntu4.6 500
  500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.4.29-1ubuntu4 500
  500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  openssl:
Installiert:   1.1.1-1ubuntu2.1~18.04.2
Installationskandidat: 1.1.1-1ubuntu2.1~18.04.2
Versionstabelle:
   *** 1.1.1-1ubuntu2.1~18.04.2 500
  500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.1.0g-2ubuntu4.3 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   1.1.0g-2ubuntu4 500
  500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

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

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


[Touch-packages] [Bug 1831765] Re: Privilege Separation Directory default

2019-06-06 Thread Paride Legovini
Thank you for taking the time to report this bug and helping to make
Ubuntu better. I think the description of the problem your are facing
and the workaround you found are missing one main fact: sshd in Ubuntu
is managed with systemd unit files, the legacy init scripts in
/etc/init.d/ are not used. The /run/sshd directory is created by systemd
because /lib/systemd/system/ssh.service contains the
RuntimeDirectory=sshd directive.

You can find pointers to get help with your specific need here:
http://www.ubuntu.com/support/community

As this is a configuration issue, rather than a bug a in Ubuntu, I'm
marking this bug as Invalid. If you believe that this is really a bug,
then you may find it helpful to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then explain why you believe this is a bug in Ubuntu rather
than a configuration issue, and then change the bug status back to New.

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

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

Title:
  Privilege Separation Directory default

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  Ubuntu: 18.04.2 LTS
  OpenSSH: 7.6p1

  I am having a problem starting multiple sshd processes. The default location 
of the sshd privilege separation directory is hard-coded to /run/sshd (see man 
page). The original OpenSSH 7.6p1 located this file are /var/empty. Somehow the 
default location in the pathnames.h for _PATH_PRIVSEP_CHROOT_DIR has been 
changed from /var/empty to /run/sshd. I have asked OpenSSH to provision the 
ability to change this directory location from either the command-line or the 
sshd_config file; Theo de Raadt, et. al. pretty much said "NO!" using some 
rather provocative language.
  Here is the problem with using /run/sshd:
  1) Every time there is a boot, the /run directory is cleaned out.
  2) The /etc/init.d/ssh script is required to check and mkdir the /run/sshd 
directory.
  3) If you have multiple service scripts, like lan_ssh and wan_ssh, the 2 
scripts conflict in the generation and creation of the /run/sshd directory.
  4) The only work-around I have found is to have a rc.local script mkdir the 
/run/sshd directory and remove the mkdir /run/sshd from the /etc/init.d/ 
scripts.
  If we revert back to the /var/empty directory approach and remove the "mkdir 
/run/sshd" operation from the /etc/init.d/ script(s), this problem goes away 
since the system does not recreate /var during every boot.
  This would require 1 of 2 changes to the existing release of sshd, 
specifically:
  1) Change the default location of the privilege separation directory from 
/run/sshd back to the original /var/empty. This would require the install 
script to create this directory if it does not already exist.
  2) Modify the sshd.c file to provision the ability to change the default 
location of the privilege separation directory.

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

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


[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found

2019-05-20 Thread Paride Legovini
Thanks for sharing your findings. What you found out is indeed
interesting, however I'm not sure you can say the change happened in
modprobe, as you are using two different kernel versions. Perhaps insmod
and modprobe always behaved differently, and what changed is what the
kernel does.

Your suggestion for a more robust handling of dummy interfaces makes
sense, however even if this were done I don't think your use case alone
would be enough to justify an upgrade in Bionic (a so-called Stable
Release Upgrade). On the other side, newer releases of Ubuntu are
switching from ifupdown to netplan, so at this point it is unlikely that
any active work will be put into ifupdown unless there is a compelling
reason to do so.

Should a wider-impact use case come up then we will certainly re-
evaluate the importance of this report.

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

Title:
  ifconfig dummy0 : Device not found

Status in ifupdown package in Ubuntu:
  New
Status in net-tools package in Ubuntu:
  New

Bug description:
  Desired behavior:
The ifconfig command should be able to deal with the
dummy device.  This worked fine until recently.

  Observed behavior:
:; ifconfig dummy0
dummy0: error fetching interface information: Device not found

This problem appeared when I upgraded to bionic.

  Highly informative workaround:
:; ip link add dummy0 type dummy
That command works, and makes the problem go away permanently.
The ifconfig command works fine after that.
The ifup and ifdown commands also work fine after that.

For convenient debugging, you can use the command:
:; ip link del dummy0 type dummy
which makes the problem come back.
You can also experiment with dummy1 et cetera.

  Package ownership issues:
Compare: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909204
That report was filed against ippusbxd, which is almost certainly
not the relevant package.

For that matter, I have no idea whether the root cause is in the
net-tools package or the kernel networking stack.  All I know is
the ip command plays nicely with the kernel while the ifconfig
command does not.

  
  Notes:
The kernel module for the dummy interface is preloaded in
all situations described here.  That's not the issue.

An apport file is attached, to describe the environment.
Also, since you asked:

:; apt-cache policy net-tools
  net-tools:
Installed: 1.60-26ubuntu1
Candidate: 1.60-26ubuntu1
Version table:
   *** 1.60-26ubuntu1 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

:; lsb_release -rd
Description:Ubuntu 16.04.6 LTS
Release:16.04

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

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


[Touch-packages] [Bug 1792544] Re: demotion of pcre3 (8.x) a.k.a pcre (without the 3) in favor of pcre2 (10.x)

2019-05-02 Thread Paride Legovini
** Changed in: zsh (Ubuntu)
   Status: Fix Released => Triaged

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

Title:
  demotion of pcre3 (8.x) a.k.a pcre (without the 3) in favor of pcre2
  (10.x)

Status in aide package in Ubuntu:
  Incomplete
Status in anope package in Ubuntu:
  Incomplete
Status in apache2 package in Ubuntu:
  Triaged
Status in apr-util package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Fix Released
Status in exim4 package in Ubuntu:
  Incomplete
Status in freeradius package in Ubuntu:
  Incomplete
Status in git package in Ubuntu:
  Fix Released
Status in glib2.0 package in Ubuntu:
  Incomplete
Status in grep package in Ubuntu:
  Incomplete
Status in haproxy package in Ubuntu:
  Fix Released
Status in libpam-mount package in Ubuntu:
  Fix Released
Status in libselinux package in Ubuntu:
  Triaged
Status in nginx package in Ubuntu:
  Incomplete
Status in nmap package in Ubuntu:
  Incomplete
Status in pcre3 package in Ubuntu:
  Confirmed
Status in php-defaults package in Ubuntu:
  Triaged
Status in php7.2 package in Ubuntu:
  Won't Fix
Status in postfix package in Ubuntu:
  Incomplete
Status in python-pyscss package in Ubuntu:
  Incomplete
Status in quagga package in Ubuntu:
  Invalid
Status in rasqal package in Ubuntu:
  Incomplete
Status in slang2 package in Ubuntu:
  Incomplete
Status in sssd package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Triaged
Status in tilix package in Ubuntu:
  New
Status in ubuntu-core-meta package in Ubuntu:
  New
Status in vte2.91 package in Ubuntu:
  Fix Released
Status in wget package in Ubuntu:
  Fix Released
Status in zsh package in Ubuntu:
  Triaged

Bug description:
  https://people.canonical.com/~ubuntu-
  archive/transitions/html/pcre2-main.html

  demotion of pcre3 in favor of pcre2. These packages need analysis what
  needs to be done for the demotion of pcre3:

  Packages which are ready to build with pcre2 should be marked as
  'Triaged', packages which are not ready should be marked as
  'Incomplete'.

  --
  For clarification: pcre2 is actually newer than pcre3.  pcre3 is just poorly 
named.

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

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


[Touch-packages] [Bug 1821939] Re: package openssh-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

2019-03-28 Thread Paride Legovini
Thank you for taking the time to report this bug and helping to make
Ubuntu better.

Since there isn't enough information in your report to differentiate
between a local configuration problem and a bug in Ubuntu, I'm marking
this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers
to get help for this sort of problem here:
http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it
helpful to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

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

Title:
  package openssh-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade:
  subprocess installed post-installation script returned error exit
  status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  .

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: openssh-server 1:7.2p2-4ubuntu2.8
  ProcVersionSignature: Ubuntu 4.15.0-46.49~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-46-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Wed Mar 27 15:11:18 2019
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationDate: Installed on 2019-01-21 (65 days ago)
  InstallationMedia: Ubuntu 16.04.5 LTS "Xenial Xerus" - Release amd64 
(20180731)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.5
   apt  1.2.31
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: Missing privilege separation directory: /var/run/sshd
  SourcePackage: openssh
  Title: package openssh-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: 
subprocess installed post-installation script 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/1821939/+subscriptions

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


[Touch-packages] [Bug 1820944] Re: package openssh-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: подпроцесс установлен сценарий post-installation возвратил код ошибки 2

2019-03-21 Thread Paride Legovini
Thank you for your report.

This looks like a local configuration problem, rather than a bug in
Ubuntu.

You can find pointers to get help for this sort of problem here:
http://www.ubuntu.com/support/community

Since we use this bug tracker to track bugs in Ubuntu, rather than
configuration problems, I'm marking this bug as Invalid. This helps us
to focus on fixing bugs in Ubuntu.

If you believe that this is really a bug, then you may find it helpful
to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

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

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

Title:
  package openssh-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade:
  подпроцесс установлен сценарий post-installation возвратил код ошибки
  2

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  I tried to command "sudo apt-get install ssh"

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: openssh-server 1:7.2p2-4ubuntu2.8
  ProcVersionSignature: Ubuntu 4.15.0-46.49~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-46-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Tue Mar 19 10:15:17 2019
  ErrorMessage: подпроцесс установлен сценарий post-installation возвратил код 
ошибки 2
  InstallationDate: Installed on 2018-08-11 (220 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.5
   apt  1.2.29ubuntu0.1
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: 
/etc/ssh/sshd_config: No such file or directory
  SourcePackage: openssh
  Title: package openssh-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: 
подпроцесс установлен сценарий post-installation возвратил код ошибки 2
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1817967] Re: 16.04.6 LTS OpenSSH-Server requires 0705 directory privileges for pubkey auth

2019-02-28 Thread Paride Legovini
Thank you for your report.

This looks like a local configuration problem: if
/etc/ssh/authorized_keys is chmod 0700 non-root users can't reach their
/etc/ssh/authorized_keys/%u directory. You probably want to chmod 0700
/etc/ssh/authorized_keys/%u.

Since we use this bug tracker to track bugs in Ubuntu, rather than
configuration problems, I'm marking this bug as Invalid. This helps us
to focus on fixing bugs in Ubuntu.

If you believe that this is really a bug, then you may find it helpful
to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

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

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

Title:
  16.04.6 LTS OpenSSH-Server requires 0705 directory privileges for
  pubkey auth

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  Many servers are set up to simplify and centralize ssh key management
  within a single directory.

  This is typically done with the line "AuthorizedKeysFile /somedir/%u".
  Much online discussion suggests placing the destination in
  /etc/ssh/authorized_keys/%u with 0700 on the authorized_keys folder
  and 0600 or 0644 on the separate public key-files, StrictTypes is
  enabled and is supposed to check for the 0700 and 0600 permissions...
  but doesn't appear to be working?.

  The current supported version for SSH on 16.04.6 LTS appears to be:
  OpenSSH_7.2p2 Ubuntu-4ubuntu2.7, OpenSSL 1.0.2g  1 Mar 2016

  
  Under this configuration, standard key-based authentication is unable to 
complete without the key directory having at least 0705 on the directory, 0700 
fails, and 0644 on the files is sufficient regardless.

  This was tested on a 16.04.6 LTS release instance created on Linode.

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

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