from:"John"

On Thu, 26 Sep 2019 at 20:11, Dan Streetman  wrote:
>
> So, am I understanding right that such a system will have two ethernet
> interfaces with identical mac addresses?  Isn't that an obvious problem
> that should be fixed instead?

Digging into this, It seems that it is an explicitly supported
configuration that was added in 2016
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579984

Ie. the dock copies the MAC address of the laptop, such that the same
lease is still usable.

Thus the timeouts now observed, are a regression of said feature.

-- 
Regards,

Dimitri.

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

Title:
  Dell system takes a long time to connect network with external dock

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is a bug reopen from
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700
  The original one caused systemd regressed.
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651

  This issue needs an alternative solution.

  Dell has a feature called MAC addrss passthrough[1] that would force usb 
ethernet adapters to be assigned with a predefined MAC address stored in BIOS 
or so. This feature has been landed to mainline kernel in driver r8152[2]. So 
whenever a r8152 managed device is plugged into Dell devices with MAC addrss 
passthrough enabled, this driver will set NIC MAC to a predefined one.

  And some Dell devices have already one built-in r8152 NIC port. On
  these devices, when a second r8152 NIC is plugged in, a Debian
  originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev
  built-in command `net_id` to give a persistent name, and that will be
  based on MAC address. However, since the system has already
  initialized the built-in r8152 NIC with that name, renaming the second
  interface with this name will always fail.

  While Debian still carries a patch called "Revert-udev-network-device-
  renaming-immediately-give.patch"[4] that tries to keep support of
  already deprecated "75-persistent-net-generator.rules" based interface
  renaming mechanism, this patch also propagated into Ubuntu[5]. This
  patch will retry renaming with a 90 seconds timeout when the error
  code is -EEXIST, so the uevent processing will always be blocked in
  the last ifrename step in the victim system.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules 
lib/udev/rules.d/50-udev-default.rules 
lib/udev/rules.d/73-special-net-names.rules 
lib/udev/rules.d/73-usb-net-by-mac.rules]
  ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18
  Uname: Linux 4.15.0-1043-oem x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules
  Date: Wed Jul 24 15:30:59 2019
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90
  InstallationDate: Installed on 2019-07-03 (20 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  MachineType: Dell Inc. Latitude 7424 Rugged Extreme
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed 
root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet 
splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M 
vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/27/2019
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.5.0
  dmi.board.name: 0Y7FK3
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X03
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 7424 Rugged Extreme
  dmi.sys.vendor: Dell Inc.

  [1]: 
https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en
  [2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c
  [3]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules
  [4]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch
  [5]:

[Touch-packages] [Bug 1769297] Re: resume from hibernation broken when resume image is autodetected

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

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

Title:
  resume from hibernation broken when resume image is autodetected

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  I found a reason of non-functioning resume from hibernation when
  resume partition/file is autodetected by intiramfs hook /usr/share
  /initramfs-tools/hooks/resume.

  Here is the scenario:
  1) hook /usr/share/initramfs-tools/hooks/resume creates config 
conf/conf.d/zz-resume-auto saved in initrd image, containing one variable: 
RESUME=UUID=106238b0-707d-4422-866d-a7534da50702 in my case

  2) during boot init script sets 'resume' variable to 'RESUME' value
  from conf/conf.d/zz-resume-auto, then it executes local-premount
  scripts including local-premount/resume

  3) resuming script local-premount/resume 
(/usr/share/initramfs-tools/scripts/local-premount/resume) tries to get resume 
device major-minor numbers by these lines:
  DEV=$(readlink ${resume})
  DEV=/sys/class/block/${DEV##*/}/dev
  if [ -r "$DEV" ]; then
  read MAJMIN < "$DEV"
  fi

  4) next check fails and resume process silently aborts:
  if [ -z "$MAJMIN" ]; then
  exit 1
  fi

  Resuming script fails to get device major-minor because
  resume=UUID=106238b0-707d-4422-866d-a7534da50702 -- it's not resolved
  into device path in init script.

  Commonly mentioned workaround is to explicitly specify kernel
  parameter resume=UUID=106238b0-707d-4422-866d-a7534da50702 -- only in
  this case init script resolves it to device path.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: initramfs-tools 0.130ubuntu3
  Uname: Linux 4.16.6-041606-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May  5 11:32:31 2018
  InstallationDate: Installed on 2018-03-27 (38 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180327)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1779767] Re: Default cron PATH does not include /snap/bin

I believe this will be fixed in v2.41 snapd.

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

Title:
  Default cron PATH does not include /snap/bin

Status in cron package in Ubuntu:
  Confirmed

Bug description:
  I recently changed from a .deb install of LXD to a snap, and was
  surprised that one of my crontab scripts stopped working.

  I see that $PATH in a cron script only contains "/usr/bin:/bin",
  whereas my default shell also includes "/snap/bin".

  It seems to me that for the best user experience with snaps,
  "/snap/bin" should be part of the default $PATH in cron.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cron 3.0pl1-128.1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 
kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 
livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon 
znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul  2 14:30:06 2018
  InstallationDate: Installed on 2017-12-20 (194 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cron
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1845190] Re: binutils nm wrong output format breaks i386 nm work

I think this should land in Ubuntu as part of a regular snapshot upload
of binutils. I.e. without any special cherrypicking.

This may or might not be fixed in Eoan or f-cycle.

** Changed in: binutils (Ubuntu)
   Importance: High => Wishlist

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

Title:
  binutils nm wrong output format breaks i386 nm work

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  Confirmed

Bug description:
  discovered with diffoscope autopkgregression, looks like a real bug, based on
  https://salsa.debian.org/reproducible-builds/diffoscope/issues/69

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

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

[Touch-packages] [Bug 1703194] Re: package snapd 2.25~14.04 failed to install/upgrade: подпроцесс установлен сценарий post-installation возвратил код ошибки 1

2019-09-26 Thread John Lenton

I suspect you've been able to resolve this, sorry we never got back to
you about it.

I'm closing it as "Won't fix", because we didn't do anything about this,
but if you're still stuck there's probably a cause for this that isn't
necessarily snapd itself and we can probably figure it out.

Again, sorry.


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

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

Title:
  package snapd 2.25~14.04 failed to install/upgrade: подпроцесс
  установлен сценарий post-installation возвратил код ошибки 1

Status in apport package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  Won't Fix

Bug description:
  Пытался откатиться с 16.04 до 14 путём выполнения команды sudo gedit
  /etc/apt/sources.list. не вышло. как быть?

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: snapd 2.25~14.04
  ProcVersionSignature: Ubuntu 4.4.0-83.106~14.04.1-generic 4.4.70
  Uname: Linux 4.4.0-83-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  Date: Sun Jul  9 16:18:43 2017
  ErrorMessage: подпроцесс установлен сценарий post-installation возвратил код 
ошибки 1
  InstallationDate: Installed on 2017-07-09 (0 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.19
  SourcePackage: snapd
  Title: package snapd 2.25~14.04 failed to install/upgrade: подпроцесс 
установлен сценарий post-installation возвратил код ошибки 1
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1844868] [NEW] cloud-images should not contain plymouth

2019-09-21 Thread Dimitri John Ledkov

Public bug reported:

cloud-images should not contain plymouth

** Affects: cloud-images
 Importance: Undecided
 Status: New

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Status: New

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

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

Title:
  cloud-images should not contain plymouth

Status in cloud-images:
  New
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  cloud-images should not contain plymouth

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1844868/+subscriptions

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

[Touch-packages] [Bug 1769297] Re: resume from hibernation broken when resume image is autodetected

2019-09-20 Thread Dimitri John Ledkov

** Tags added: rls-ee-incoming

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

Title:
  resume from hibernation broken when resume image is autodetected

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  I found a reason of non-functioning resume from hibernation when
  resume partition/file is autodetected by intiramfs hook /usr/share
  /initramfs-tools/hooks/resume.

  Here is the scenario:
  1) hook /usr/share/initramfs-tools/hooks/resume creates config 
conf/conf.d/zz-resume-auto saved in initrd image, containing one variable: 
RESUME=UUID=106238b0-707d-4422-866d-a7534da50702 in my case

  2) during boot init script sets 'resume' variable to 'RESUME' value
  from conf/conf.d/zz-resume-auto, then it executes local-premount
  scripts including local-premount/resume

  3) resuming script local-premount/resume 
(/usr/share/initramfs-tools/scripts/local-premount/resume) tries to get resume 
device major-minor numbers by these lines:
  DEV=$(readlink ${resume})
  DEV=/sys/class/block/${DEV##*/}/dev
  if [ -r "$DEV" ]; then
  read MAJMIN < "$DEV"
  fi

  4) next check fails and resume process silently aborts:
  if [ -z "$MAJMIN" ]; then
  exit 1
  fi

  Resuming script fails to get device major-minor because
  resume=UUID=106238b0-707d-4422-866d-a7534da50702 -- it's not resolved
  into device path in init script.

  Commonly mentioned workaround is to explicitly specify kernel
  parameter resume=UUID=106238b0-707d-4422-866d-a7534da50702 -- only in
  this case init script resolves it to device path.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: initramfs-tools 0.130ubuntu3
  Uname: Linux 4.16.6-041606-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May  5 11:32:31 2018
  InstallationDate: Installed on 2018-03-27 (38 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180327)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1784499] Re: AppArmor treats regular NFS file access as network op

2019-09-20 Thread John Johansen

zyga well patches are welcome ;-)

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

Title:
  AppArmor treats regular NFS file access as network op

Status in AppArmor:
  Confirmed
Status in snapd:
  Invalid
Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  I am using AppArmor 2.12-4ubuntu5 on Ubuntu 18.04/bionic.

  I have the usr.bin.man profile enforced, and home directories in NFS.

  The log excerpt copied below is the result of a single invocation of
  "man ls" by an unprivileged user. (The program did display the man
  page correctly to the user.)

  It does not seem appropriate for AppArmor to report the man(1) program
  as having attempted to contact the NFS server directly, when it only
  tried to access an NFS-served file in the normal way. "man" is not a
  network-aware program and the log below misleadingly implies
  otherwise.

  

  Jul 30 17:38:35 darkstar kernel: [69963.052243] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052274] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052297] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052314] kauditd_printk_skb: 34 
callbacks suppressed
  Jul 30 17:38:35 darkstar kernel: [69963.052316] audit: type=1400 
audit(1532986715.854:214): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052323] audit: type=1400 
audit(1532986715.854:215): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 
faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052327] audit: type=1400 
audit(1532986715.854:216): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052339] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052363] audit: type=1400 
audit(1532986715.854:217): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052364] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052369] audit: type=1400 
audit(1532986715.854:218): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 
faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052386] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052450] audit: type=1400 
audit(1532986715.854:219): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.059570] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.059640] audit: type=1400 
audit(1532986715.862:220): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.061907] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.061925] audit: type=1400 
audit(1532986715.862:221): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2792 comm="less" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.062006] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.062014] audit: type=1400 
audit(1532986715.862:222): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2792 comm="less" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.066404] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.066434] audit: type=1400 
audit(1532986715.866:223): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2788 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y

[Touch-packages] [Bug 1784499] Re: AppArmor treats regular NFS file access as network op

2019-09-20 Thread John Johansen

With that said, some networking work is being done this cycle and we
will try to address this.

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

Title:
  AppArmor treats regular NFS file access as network op

Status in AppArmor:
  Confirmed
Status in snapd:
  Invalid
Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  I am using AppArmor 2.12-4ubuntu5 on Ubuntu 18.04/bionic.

  I have the usr.bin.man profile enforced, and home directories in NFS.

  The log excerpt copied below is the result of a single invocation of
  "man ls" by an unprivileged user. (The program did display the man
  page correctly to the user.)

  It does not seem appropriate for AppArmor to report the man(1) program
  as having attempted to contact the NFS server directly, when it only
  tried to access an NFS-served file in the normal way. "man" is not a
  network-aware program and the log below misleadingly implies
  otherwise.

  

  Jul 30 17:38:35 darkstar kernel: [69963.052243] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052274] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052297] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052314] kauditd_printk_skb: 34 
callbacks suppressed
  Jul 30 17:38:35 darkstar kernel: [69963.052316] audit: type=1400 
audit(1532986715.854:214): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052323] audit: type=1400 
audit(1532986715.854:215): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 
faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052327] audit: type=1400 
audit(1532986715.854:216): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052339] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052363] audit: type=1400 
audit(1532986715.854:217): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052364] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052369] audit: type=1400 
audit(1532986715.854:218): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 
faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.052386] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.052450] audit: type=1400 
audit(1532986715.854:219): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.059570] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.059640] audit: type=1400 
audit(1532986715.862:220): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.061907] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.061925] audit: type=1400 
audit(1532986715.862:221): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2792 comm="less" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.062006] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.062014] audit: type=1400 
audit(1532986715.862:222): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man" pid=2792 comm="less" laddr=X.X.X.X lport=719 
faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 
requested_mask="send" denied_mask="send"
  Jul 30 17:38:35 darkstar kernel: [69963.066404] nfs: RPC call returned error 
13
  Jul 30 17:38:35 darkstar kernel: [69963.066434] audit: type=1400 
audit(1532986715.866:223): apparmor="DENIED" operation="sendmsg" 
profile="/usr/bin/man"

[Touch-packages] [Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

2019-09-20 Thread Dimitri John Ledkov

@bryanquigley are you going to SRU that?

And please just that alone?

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

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

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

Bug description:
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

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

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

[Touch-packages] [Bug 1824384] Re: libapparmor not built with -fPIC

2019-09-17 Thread John Johansen

apparmor's library build uses automake and libtool so the static version
of the library is built without -fPIC while the dynamic is built with
-fPIC. It is possible to override this.

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

Title:
  libapparmor not built with -fPIC

Status in apparmor package in Ubuntu:
  Triaged

Bug description:
  Attempted to build snap-confine with DEB_BUILD_MAINT_OPTIONS =
  hardening=+pie. The build fails with:

  mv -f snap-confine/.deps/snap_confine_snap_confine-user-support.Tpo 
snap-confine/.deps/snap_confine_snap_confine-user-support.Po
 
  gcc -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes 
-Wno-missing-field-initializers -Wno-unused-parameter -Werror  
-DLIBEXECDIR=\"/usr/lib/snapd\" -DNATIVE_LIBDIR=\"/usr/lib\" -g -O2 -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security   
-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -o snap-confine/snap-confine 
snap-confine/snap_confine_snap_confine-cookie-support.o 
snap-confine/snap_confine_snap_confine-mount-support-nvidia.o 
snap-confine/snap_confine_snap_confine-mount-support.o 
snap-confine/snap_confine_snap_confine-ns-support.o 
snap-confine/snap_confine_snap_confine-seccomp-support-ext.o 
snap-confine/snap_confine_snap_confine-seccomp-support.o 
snap-confine/snap_confine_snap_confine-snap-confine-args.o 
snap-confine/snap_confine_snap_confine-snap-confine-invocation.o 
snap-confine/snap_confine_snap_confine-snap-confine.o 
snap-confine/snap_confine_snap_confine-udev-support.o 
snap-confine/snap_confine_snap_confine-user-support.o  
libsnap-confine-private.a -ludev-Wl,-Bstatic -lcap -lapparmor  
-Wl,-Bdynamic -pthread
  /usr/bin/ld: /lib/x86_64-linux-gnu/libapparmor.a(kernel.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared 
object; recompile with -fPIC
  /lib/x86_64-linux-gnu/libapparmor.a: error adding symbols: Bad value
  collect2: error: ld returned 1 exit status

  By default, because of snapd reexec support on Ubuntu (and some other
  distros), snap-confine will try to link a static version libapparmor.
  It appears that libapparmor object files are built without -fPIC
  though.

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

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

[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules

2019-09-04 Thread Dimitri John Ledkov

Neither .25 nor .26 are the most current systemd versions in bionic.

Can you please double check your version numbers?

Could you please try 237-3ubuntu10.28 and check if problem persists?

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

Title:
  Regression: after Uprade from udev_237-3ubuntu10.25 to
  udev_237-3ubuntu10.26 network interfaces don't get renamed by 70
  -persistent-network.rules

Status in systemd package in Ubuntu:
  New

Bug description:
  Since the latest update from udev_237-3ubuntu10.25 and
  systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and
  systemd_237-3ubuntu10.26 the renaming of network interfaces by
  /etc/udev/rules/70-persistent-network.rules does not work.

  /etc/udev/rules/70-persistent-network.rules:
  SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", 
NAME="eth0"
  SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", 
NAME="eth1"

  /var/log/syslog:
  systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File 
exists

  When I downgrade the packages to the version with 237-3ubuntu10.25 the 
following messages are in /var/log/syslog:
  Sep  4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2: 
renamed from eth0
  Sep  4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed 
from eth1

  The latest version does not rename the interfaces temporary if there
  is a conflict!

  Manually installing the old packages with 
  dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb 
libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb 
systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb
  did fix the problem temporary.

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

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

[Touch-packages] [Bug 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups

2019-09-03 Thread Dimitri John Ledkov

** Changed in: lvm2 (Ubuntu)
 Assignee: Skipper Bug Screeners (skipper-screen-team) => Julian Andres 
Klode (juliank)

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

Title:
  [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups

Status in Ubuntu on IBM z Systems:
  New
Status in lvm2 package in Ubuntu:
  New

Bug description:
  efault blocksize of a file-system seems to be dependent on the volume-size.
  Big volume (at least ext4) does have 4k blk-size, even the underlaying devise 
with a smaller phyiscal blk-size.

  The patch, avoiding define mixed-sized volume groups is now upstream
  in the master branch of LVM2
  
https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b

  Using this patch within the distribution is for sanity reasons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1842436/+subscriptions

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

[Touch-packages] [Bug 1837926] Re: snapd snap ftbfs in eoan due to python-apt regression

2019-09-02 Thread Dimitri John Ledkov

python-apt is fixed, and actually snapd will stay on xenial for now.

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

** Changed in: snapd (Ubuntu Eoan)
   Status: Fix Released => Invalid

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

Title:
  snapd snap ftbfs in eoan due to python-apt regression

Status in python-apt package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Invalid
Status in python-apt source package in Eoan:
  Fix Released
Status in snapd source package in Eoan:
  Invalid

Bug description:
  snapd snap FTBFS in launchpad snap build due to python-apt regression
  in eoan

  https://launchpad.net/~xnox/+snap/snapd/+build/626157

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

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

[Touch-packages] [Bug 1841790] Re: [FFe] Please accept systemd 241 to Eoan

2019-08-29 Thread Dimitri John Ledkov

For a long time we had v243 rc in proposed, however we have identified
that it has too many regressions. And whilst regressions are getting
fixed upstream, we decided to pull it and start doing slightly more
incremental updates to systemd and jump to v243 final in stages.

Imho this shouldn't require FFe cause we did have v243 in -proposed, and
are still trying to get there in stages.

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

Title:
  [FFe] Please accept systemd 241 to Eoan

Status in systemd package in Ubuntu:
  New

Bug description:
  Eoan currently has 240-6ubuntu13, but it is not used widely, Debian stable 
already has 241 and Debian testing moved to 242 last week.
  Version 241 is the safest choice for Eoan (from v240, v241 and v242) since it 
is widely tested, while going forward 20.04 will most likely ship a systemd 
release which is not released yet, probably v244+.

  Updating to v241 will allow us to carry fewer patches in Eoan and
  makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing:
  https://bileto.ubuntu.com/#/ticket/3789

  The final version will be 241-7ubuntu1 and I'm tidying up the
  changelog, too.

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

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

Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-08-28 Thread Dimitri John Ledkov

I thought custom ipv6 MTU may not be lower than ipv4 one.

Hence request for 6000 ipv6 is not valid, when link is on 8958.

Can you try 9000?


On Wed, 28 Aug 2019, 15:41 Ryan Harper, <1671...@bugs.launchpad.net> wrote:

> I launched a bionic image on serverstack, updated the netplan.io to
> proposed, modified the network config to set ipv6-mtu to 6000 and
> rebooted.
>
> root@b-test-ipv6-mtu:~# apt-cache policy netplan.io
> netplan.io:
>   Installed: 0.98-0ubuntu1~18.04.1
>   Candidate: 0.98-0ubuntu1~18.04.1
>   Version table:
>  *** 0.98-0ubuntu1~18.04.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu
> bionic-proposed/main amd64 Packages
> 100 /var/lib/dpkg/status
>  0.97-0ubuntu1~18.04.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu
> bionic-updates/main amd64 Packages
>  0.40.1~18.04.4 500
> 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
> Packages
>  0.36.1 500
> 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main
> amd64 Packages
>
> root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml
> network:
> version: 2
> ethernets:
> ens3:
> dhcp4: true
> match:
> macaddress: fa:16:3e:4d:3c:6a
> set-name: ens3
> ipv6-mtu: 6000
>
> root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link
> [Match]
> MACAddress=fa:16:3e:4d:3c:6a
>
> [Link]
> Name=ens3
> WakeOnLan=off
> root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network
> [Match]
> MACAddress=fa:16:3e:4d:3c:6a
> Name=ens3
>
> [Network]
> DHCP=ipv4
> LinkLocalAddressing=ipv6
> IPv6MTUBytes=6000
>
> [DHCP]
> RouteMetric=100
> UseMTU=true
>
>
> ~# cat /sys/class/net/ens3/mtu
> 8958
> ~# sysctl net.ipv6.conf.ens3.mtu
> net.ipv6.conf.ens3.mtu = 8958
>
> --
> You received this bug notification because you are subscribed to systemd
> in Ubuntu.
> Matching subscriptions: systemd
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
>   networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions
>

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

Title:
  networkd should allow configuring IPV6 MTU

Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  = netplan.io =

  [Impact]

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

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

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

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

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

  [Regression Potential]

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

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

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

  [Test Case]

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

  [Regression Potential]

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

  [Other Info]

   * Original bug report below

  = end of systemd =

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

  Upstream has discussed this issue here:

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

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

  However, we know of multiple use-case which

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-08-28 Thread Dimitri John Ledkov

Followup on my comments, are any changes required in networkd to support
this in bionic?

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

Title:
  networkd should allow configuring IPV6 MTU

Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  = netplan.io =

  [Impact]

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

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

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

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

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

  [Regression Potential]

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

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

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

  [Test Case]

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

  [Regression Potential]

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

  [Other Info]

   * Original bug report below

  = end of systemd =

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

  Upstream has discussed this issue here:

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

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

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

  Some context from those discussions

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

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

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

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

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

[Touch-packages] [Bug 1841052] Re: [19.10 FEAT] gzip compression improvements - addl. patch required

2019-08-23 Thread Dimitri John Ledkov

** Information type changed from Private to Public

** Changed in: gzip (Ubuntu)
   Status: New => Fix Committed

** Changed in: ubuntu-z-systems
   Status: New => Fix Committed

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

Title:
  [19.10 FEAT] gzip compression improvements - addl. patch required

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in gzip package in Ubuntu:
  Fix Committed

Bug description:
  Due to fact that LP:
  https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1825350 is alread
  fix released , this new ticket is opened to fix a configuration
  problem:

  dpkg-buildpackage: info: source package gzip
  dpkg-buildpackage: info: source version 1.10-0ubuntu2
  ...
  configure: WARNING: unrecognized options: --enable-dfltc

  The configure flag: should be --enable-dfltcc

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841052/+subscriptions

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

[Touch-packages] [Bug 1837700] Re: Dell system takes a long time to connect network with external dock

** Also affects: systemd (Ubuntu Eoan)
Importance: Medium
Assignee: Shih-Yuan Lee (fourdollars)
Status: New

** Changed in: systemd (Ubuntu Eoan)
Status: New => Fix Committed

** Changed in: systemd (Ubuntu Eoan)
Assignee: Shih-Yuan Lee (fourdollars) => Dimitri John Ledkov (xnox)

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

Title:
Dell system takes a long time to connect network with external dock

Status in HWE Next:
New
Status in OEM Priority Project:
In Progress
Status in systemd package in Ubuntu:
Fix Committed
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
In Progress
Status in systemd source package in Eoan:
Fix Committed

Bug description:
update for SRU process:

[Impact]
1. On system featured mac passthrough, e.g., Dell/Lenovo laptop, or system
occasionally install two USB ethernet with same MAC address, the system will
suffer 90 seconds for network interface renaming mechanism before the last USB
ethernet interface to activate.

[Test Case]
1. Install ubuntu on Dell laptop.
2. Connect the Dell laptop with two Realtek 8153 USB ethernet dongle. Users
can observe the last one will take 90 seconds for renaming to rename0.
3. Users can also find that the two USB ethernet have the same MAC address.

[Regression Potential]
To resolve the issue, drop a debian patch from systemd package. The debian
patch is to revert an upstream commit to support
75-persistent-net-generator.rules udev rule. Since the udev rule is deprecated,
the regression potential should be relatively low.

---

Dell has a feature called MAC addrss passthrough[1] that would force usb
ethernet adapters to be assigned with a predefined MAC address stored in BIOS
or so. This feature has been landed to mainline kernel in driver r8152[2]. So
whenever a r8152 managed device is plugged into Dell devices with MAC addrss
passthrough enabled, this driver will set NIC MAC to a predefined one.

And some Dell devices have already one built-in r8152 NIC port. On
these devices, when a second r8152 NIC is plugged in, a Debian
originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev
built-in command `net_id` to give a persistent name, and that will be
based on MAC address. However, since the system has already
initialized the built-in r8152 NIC with that name, renaming the second
interface with this name will always fail.

While Debian still carries a patch called "Revert-udev-network-device-
renaming-immediately-give.patch"[4] that tries to keep support of
already deprecated "75-persistent-net-generator.rules" based interface
renaming mechanism, this patch also propagated into Ubuntu[5]. This
patch will retry renaming with a 90 seconds timeout when the error
code is -EEXIST, so the uevent processing will always be blocked in
the last ifrename step in the victim system.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules
lib/udev/rules.d/50-udev-default.rules
lib/udev/rules.d/73-special-net-names.rules
lib/udev/rules.d/73-usb-net-by-mac.rules]
ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18
Uname: Linux 4.15.0-1043-oem x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules
Date: Wed Jul 24 15:30:59 2019
DistributionChannelDescriptor:
# This is the distribution channel descriptor for the OEM CDs
# For more information see
http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90
InstallationDate: Installed on 2019-07-03 (20 days ago)
InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary
20180608-09:38
MachineType: Dell Inc. Latitude 7424 Rugged Extreme
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed
root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet
splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M
vt.handoff=1
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/27/2019
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.5.0
dmi.board.name: 0Y7FK3
dmi.board.vendor: Dell Inc.
dmi.board.version: X03
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias:
dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr:
dmi.product.family: Latitude
dmi.product.name: Latitude 7424 Rugged Extreme
dmi.sys.vendor: Dell Inc.

[1]:
https://www.dell.com/support/article/tw/zh/twdhs

[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

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

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

Title:
  [SRU] systemd-resolved negative caching for extended period of time

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

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

  [Other Info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want to disturb the merge. If
  needed after the merge, I'll add to Eoan.

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

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

[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot

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

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

Title:
  AMD Ryzen 3000 series fails to boot

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

Bug description:
  [Impact]

   * Systems with AMD Ryzen 3000 series CPUs don't boot.

  [Test Case]

   * Boot with fixed systemd on an AMD Ryzen 3000 series system.

  [Regression Potential]

   * The fix itself is very small, it ignores known to be faulty random
  values returned by the rdrand instruction and use a different random
  source. Those values can still be returned by a properly working
  rdrand implementation in 2 in 2^32 cases on 32 bit arches and in 2 in
  2^64 cases on 64 bit arches, but the fallback to the other random
  source ensures that in those rare occasions a random number can be
  generated.

  [Original Bug Text]

  On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd
  preventing the boot process from completing. This issue does not
  affect the older systemd version in 18.04, but affects the 19.04
  version.

  Here is a screenshot showing what happens:
  
https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show

  I am currently testing a patch to systemd, derived from this pull request:
  https://github.com/systemd/systemd/pull/12536

  This is a high severity issue, as I do not believe there is no
  potential workaround without either a firmware update or an ISO
  respin.

  I have attached a rebase of the potential patch on the current 19.04
  version of systemd for reference. I will provide more details after
  testing.

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

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

[Touch-packages] [Bug 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes

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

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

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

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

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3580sec preferred_lft 3580sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
  10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024

  Note that, because networkd completes the static ip configuration
  before the dhcp reply is returned and processed, the static address is
  used for the subnet-local routing.  But for global routing through the
  gateway, the dhcp-provided address is used:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000

  Now on the server, add a classless route:

  dhcp-option=121,0.0.0.0/0,10.10.0.1

  and restart dnsmasq on the server.  Then on the client, reboot.  It
  should now have:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3585sec preferred_lft 3585sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5

  Now, the global route will use the static address, not the dhcp-
  provided address:

  $ ip r get 1.1.1.1
  1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000

  If the router, 10.10.0.1, only will forward traffic sent from the dhcp
  address it provided, 10.10.0.75, then this configuration will result
  in the client being unable to reach anything through the router,
  because all its packets will have a source address of 10.10.0.5, which
  the router would drop/reject.

  [regression potential]

  this only affects dhcp routes provided by a dhcp server using the
  'static' or 'classless' route dhcp options.  Since this behavior is
  currently the default when a system doesn't add static address(es) to
  interfaces that also get dhcp addresses, this is likely not a change
  in behavior for the vast majority of systems.  And any systems that do
  add static address(es) would usually be able to route through a
  gateway from either the dhcp-provided, or static, address.  So the
  regression potential for this change should be low.

  [other info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want to disturb the merge.  If
  needed after the merge, I'll add to Eoan.

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

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

[Touch-packages] [Bug 1841006] Re: gdb reports a segfault in ld-linux.so.3 on armhf

And the VM in question has an arm64 kernel right? Have you tried an
armhf kernel?

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

Title:
  gdb reports a segfault in ld-linux.so.3 on armhf

Status in binutils package in Ubuntu:
  New

Bug description:
  In an eoan armhf container on a disco arm64 vm:

  root@helped-oyster:~# gdb /bin/true
  GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
  ...
  (gdb) r
  Starting program: /usr/bin/true 

  Program received signal SIGSEGV, Segmentation fault.
  0xf7fc8ee0 in ?? () from /lib/ld-linux-armhf.so.3

  It happens in a disco container too.

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

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

[Touch-packages] [Bug 1840943] [NEW] [hint] zlib through due to osp1 regression

2019-08-21 Thread Dimitri John Ledkov

Public bug reported:

hint zlib through due to osp1 regression

zlib is blocked in eoan-proposed due to linux-oem-osp1 regression, which
it cannot have caused as that package is compiled in bionic.

Please hint zlib through.

** Affects: linux-oem-osp1 (Ubuntu)
 Importance: Undecided
 Status: New

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

** Affects: linux-oem-osp1 (Ubuntu Eoan)
 Importance: Undecided
 Status: New

** Affects: zlib (Ubuntu Eoan)
 Importance: Undecided
 Status: New


** Tags: ubuntu-hints

** Also affects: zlib (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: linux-oem-osp1 (Ubuntu)
   Importance: Undecided
   Status: New

** Branch linked: lp:~xnox/britney/oem-osp1

** Summary changed:

- hint zlib through due to osp1 regression
+ [hint] zlib through due to osp1 regression

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

Title:
  [hint] zlib through due to osp1 regression

Status in linux-oem-osp1 package in Ubuntu:
  New
Status in zlib package in Ubuntu:
  New
Status in linux-oem-osp1 source package in Eoan:
  New
Status in zlib source package in Eoan:
  New

Bug description:
  hint zlib through due to osp1 regression

  zlib is blocked in eoan-proposed due to linux-oem-osp1 regression,
  which it cannot have caused as that package is compiled in bionic.

  Please hint zlib through.

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

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

[Touch-packages] [Bug 1840902] Re: ejabberd fails incoming connections with "Failed to secure c2s connection: TLS failed: client renegotiations forbidden"

2019-08-21 Thread Dimitri John Ledkov

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

https://launchpad.net/ubuntu/+source/erlang-p1-tls/1.0.20-1ubuntu0.1

erlang-p1-tls (1.0.20-1ubuntu0.1) bionic; urgency=medium

  * Cherrypick upstream patches for openssl1.1 support:
- fix client cert authentication
- update test certificates
- add support for 'no_tlsv1_3' option
- testsuite fixes
- do not attempt unsupported renegotiation LP: #1832933

 -- Dimitri John Ledkov   Sun, 16 Jun 2019 01:48:12
+0100

In updates.

** This bug has been marked a duplicate of bug 1832933
   upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

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

Title:
  ejabberd fails incoming connections with "Failed to secure c2s
  connection: TLS failed: client renegotiations forbidden"

Status in ejabberd package in Ubuntu:
  New
Status in openssl package in Ubuntu:
  Invalid
Status in ejabberd source package in Bionic:
  New
Status in openssl source package in Bionic:
  Invalid

Bug description:
  ejabberd 18.01-2 on Bionic.
  Bad: openssl/libssl1.1 1.1.1-1ubuntu2.1~18.04.4
  Good: openssl/libssl1.1 1.1.0g-2ubuntu4.3

  This hit the Bionic security pocket yesterday, so everyone who uses
  unattended-upgrades for security only (which is the default) will have
  received this overnight.

  Workaround: downgrade openssl/libssl1.1 to 1.1.0g-2ubuntu4.3 using old
  builds that are available from
  https://launchpad.net/ubuntu/+source/openssl/1.1.0g-2ubuntu4.3 (follow
  the architecture link eg. "amd64")

  The error logged by ejabberd is:

  2019-08-21 06:52:28.402 [warning]
  <0.539.0>@ejabberd_c2s:process_terminated:290 (tls|<0.539.0>) Failed
  to secure c2s connection: TLS failed: client renegotiations forbidden

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

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

[Touch-packages] [Bug 1840902] Re: ejabberd fails incoming connections with "Failed to secure c2s connection: TLS failed: client renegotiations forbidden"

2019-08-21 Thread Dimitri John Ledkov

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

I'm pretty sure this is a duplicate and was fixed before. Let me try to
find the actual relevant package.

Possibly it may need a rebuild / publish in the security pocket, if it
was only published in updates.

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

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

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

Title:
  ejabberd fails incoming connections with "Failed to secure c2s
  connection: TLS failed: client renegotiations forbidden"

Status in ejabberd package in Ubuntu:
  New
Status in openssl package in Ubuntu:
  Invalid
Status in ejabberd source package in Bionic:
  New
Status in openssl source package in Bionic:
  Invalid

Bug description:
  ejabberd 18.01-2 on Bionic.
  Bad: openssl/libssl1.1 1.1.1-1ubuntu2.1~18.04.4
  Good: openssl/libssl1.1 1.1.0g-2ubuntu4.3

  This hit the Bionic security pocket yesterday, so everyone who uses
  unattended-upgrades for security only (which is the default) will have
  received this overnight.

  Workaround: downgrade openssl/libssl1.1 to 1.1.0g-2ubuntu4.3 using old
  builds that are available from
  https://launchpad.net/ubuntu/+source/openssl/1.1.0g-2ubuntu4.3 (follow
  the architecture link eg. "amd64")

  The error logged by ejabberd is:

  2019-08-21 06:52:28.402 [warning]
  <0.539.0>@ejabberd_c2s:process_terminated:290 (tls|<0.539.0>) Failed
  to secure c2s connection: TLS failed: client renegotiations forbidden

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

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

[Touch-packages] [Bug 1736704] Re: [19.10 FEAT] openssl: SIMD implementation of poly1305

2019-08-20 Thread Dimitri John Ledkov

** Information type changed from Private to Public

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

Title:
  [19.10 FEAT] openssl: SIMD implementation of poly1305

Status in Ubuntu on IBM z Systems:
  In Progress
Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Enable support for TLS 1.3 with  chacha20poly1305 cipher suites 
  using SIMD instructions
  Planned with openssl 1.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1736704/+subscriptions

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

[Touch-packages] [Bug 1736705] Re: [19.10 FEAT] openssl: SIMD implementation of chacha20

2019-08-20 Thread Dimitri John Ledkov

** Information type changed from Private to Public

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

Title:
  [19.10 FEAT] openssl: SIMD implementation of chacha20

Status in Ubuntu on IBM z Systems:
  Triaged
Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Enable support for TLS 1.3 with  chacha20poly1305 cipher suites using SIMD 
instructions
  Planned for openssl 1.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1736705/+subscriptions

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

[Touch-packages] [Bug 1823157] Re: [19.10 FEAT] zlib compression improvements

2019-08-19 Thread Dimitri John Ledkov

** Information type changed from Private Security to Public

** Changed in: zlib (Ubuntu)
   Status: New => Fix Committed

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

Title:
  [19.10 FEAT] zlib compression improvements

Status in Ubuntu on IBM z Systems:
  Triaged
Status in zlib package in Ubuntu:
  Fix Committed

Bug description:
  Compression improvements for Linux on z using zlib in support of
  better performance.

  Upstream post 2019-03-15: https://github.com/madler/zlib/pull/410

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1823157/+subscriptions

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

[Touch-packages] [Bug 1840640] Re: sync_file_range fails in nspawn containers on arm, ppc

2019-08-19 Thread Dimitri John Ledkov

this is cherrypickable, yes.

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

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

Title:
  sync_file_range fails in nspawn containers on arm, ppc

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  ARM has two sync_file_range syscalls, sync_file_range and
  sync_file_range2. The former is apparently not used, and glibc calls
  the latter whenever a userspace program calls sync_file_range. I'm
  guessing systemd-nspawn doesn't know this, because the follow code
  consistently fails in an nspawn container on ARM:

  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 

  void main()
  {
  int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
  int r=sync_file_range(f, 0, 0, 0);
  if (r)
  perror("sync_file_range");
  close(f);
  }

  This seems to be causing problems specifically for borg(backup) and
  postgres:

  https://github.com/borgbackup/borg/issues/4710
  
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93

  The solution should be to cherrypick
  https://github.com/systemd/systemd/pull/13352, I am currently waiting
  for systemd to rebuild on a slow ARM box. Any chance of an SRU?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd-container 237-3ubuntu10.24
  Uname: Linux 4.14.66+ armv7l
  NonfreeKernelModules: extcon_usb_gpio
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: armhf
  Date: Mon Aug 19 11:10:48 2019
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1840640] Re: sync_file_range fails in nspawn containers on arm, ppc

2019-08-19 Thread Dimitri John Ledkov

https://github.com/systemd/systemd/pull/13352/commits/90ddac6087b5f8f3736364cfdf698e713f7e8869.patch

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

Title:
  sync_file_range fails in nspawn containers on arm, ppc

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  ARM has two sync_file_range syscalls, sync_file_range and
  sync_file_range2. The former is apparently not used, and glibc calls
  the latter whenever a userspace program calls sync_file_range. I'm
  guessing systemd-nspawn doesn't know this, because the follow code
  consistently fails in an nspawn container on ARM:

  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 

  void main()
  {
  int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
  int r=sync_file_range(f, 0, 0, 0);
  if (r)
  perror("sync_file_range");
  close(f);
  }

  This seems to be causing problems specifically for borg(backup) and
  postgres:

  https://github.com/borgbackup/borg/issues/4710
  
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93

  The solution should be to cherrypick
  https://github.com/systemd/systemd/pull/13352, I am currently waiting
  for systemd to rebuild on a slow ARM box. Any chance of an SRU?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd-container 237-3ubuntu10.24
  Uname: Linux 4.14.66+ armv7l
  NonfreeKernelModules: extcon_usb_gpio
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: armhf
  Date: Mon Aug 19 11:10:48 2019
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10

2019-08-16 Thread Dimitri John Ledkov

Using bionic as a base, and upgrading all the way to disco:
(bionic-amd64)root@ottawa:~# echo PURGE | debconf-communicate libpam0g:amd64
0
(bionic-amd64)root@ottawa:~# echo PURGE | debconf-communicate libpam0g
0
(bionic-amd64)root@ottawa:~# echo PURGE | debconf-communicate libc6:amd64
0
(bionic-amd64)root@ottawa:~# echo PURGE | debconf-communicate libc6
0
(bionic-amd64)root@ottawa:~# echo PURGE | debconf-communicate libssl1.1
0
(bionic-amd64)root@ottawa:~# echo PURGE | debconf-communicate libssl1.1:amd64
0
(bionic-amd64)root@ottawa:~# dpkg-query -W libssl1.1
libssl1.1:amd64 1.1.0g-2ubuntu4

(upgrade)
(got promted for restarting services, meaning template got initiated correctly)

Services restarted successfully.

Setting up openssl (1.1.1b-1ubuntu2.4) ...


** Tags removed: verification-needed verification-needed-cosmic 
verification-needed-disco
** Tags added: verification-done verification-done-cosmic 
verification-done-disco

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

Title:
  installed libssl1.1:amd64 package post-installation script subprocess
  returned error exit status 10

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

Bug description:
  [Impact]

   * Systems that have in error removed debconf database fail to upgrade
  libssl1.1 (as e.g. is known to be done in some vagrant boxes)

   * libssl1.1 tries to use debconf template from libc6 package, but
  doesn't ship one by itself as it should for shared templates. As it is
  not guaranteed that template will be available.

  [TestCase]

  # DO NOT DO THIS ON PRODUCTION MACHINES #
  # echo PURGE | debconf-communicate libpam0g:amd64
  0
  # echo PURGE | debconf-communicate libpam0g
  0
  # echo PURGE | debconf-communicate libc6:amd64
  0
  # echo PURGE | debconf-communicate libc6
  0

  Then upgrade from bionic-release to the -proposed package and it
  should work.

  It should not fail with exit code 10.

  [Regression Potential]

   * A new template is added, an identical import from glibc without any
  further changes. This registers the template in debconf, for this
  package, preventing the above describe error. This has no codechanges,
  only metadata.

  [Other Info]
   
   * Original bug report 

  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)

  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64

  [ WORKAROUND TO RECOVER YOUR SYSTEM ]

  $ sudo dpkg-reconfigure libc6
  $ sudo dpkg --configure libssl1.1

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

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

[Touch-packages] [Bug 1837700] Re: Dell system takes a long time to connect network with external dock

2019-08-15 Thread Dimitri John Ledkov

Fix committed status is only for SRU team to set on the distro tasks,
when an SRU upload is accepted.

** Changed in: systemd (Ubuntu Bionic)
Status: Fix Committed => 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/1837700

Title:
Dell system takes a long time to connect network with external dock

Status in HWE Next:
New
Status in OEM Priority Project:
In Progress
Status in systemd package in Ubuntu:
New
Status in systemd source package in Bionic:
New
Status in systemd source package in Disco:
New

Bug description:
update for SRU process:

---

[1]:
https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c
[3]:

[Touch-packages] [Bug 1839123] Re: [19.10 FEAT] gzip compression improvements addl. patch required

2019-08-12 Thread Dimitri John Ledkov

** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Committed

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

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

Title:
  [19.10 FEAT] gzip compression improvements addl. patch required

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in gzip package in Ubuntu:
  Fix Committed

Bug description:
  This patch (unfortunately not yet upstream acepted) is needed on top
  of LP 1825350
  (https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1825350), and
  fixes a serious bug.

  It was already developed and published a while ago:
  https://lists.gnu.org/archive/html/bug-gzip/2019-07/msg0.html

  This patch fixes data corruption issues, and thus is very important.
  Unfortunately, so far it has been ignored (there is not much going on
  on gzip mailing list in general). I would like to ask you to pick it
  up for the distro.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1839123/+subscriptions

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

[Touch-packages] [Bug 1839123] Re: [19.10 FEAT] gzip compression improvements addl. patch required

2019-08-12 Thread Dimitri John Ledkov

** Information type changed from Private to Public

** Changed in: gzip (Ubuntu)
   Status: New => In Progress

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

Title:
  [19.10 FEAT] gzip compression improvements addl. patch required

Status in Ubuntu on IBM z Systems:
  Triaged
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  This patch (unfortunately not yet upstream acepted) is needed on top
  of LP 1825350
  (https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1825350), and
  fixes a serious bug.

  It was already developed and published a while ago:
  https://lists.gnu.org/archive/html/bug-gzip/2019-07/msg0.html

  This patch fixes data corruption issues, and thus is very important.
  Unfortunately, so far it has been ignored (there is not much going on
  on gzip mailing list in general). I would like to ask you to pick it
  up for the distro.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1839123/+subscriptions

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

[Touch-packages] [Bug 1838485] [NEW] package policykit-1 0.105-14.1ubuntu0.5 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1

2019-07-30 Thread John Stewart

Public bug reported:

I don't have Window.

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: policykit-1 0.105-14.1ubuntu0.5
ProcVersionSignature: Ubuntu 4.10.0-28.32~16.04.2-generic 4.10.17
Uname: Linux 4.10.0-28-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.1-0ubuntu2.19
Architecture: amd64
Date: Tue Jul 30 11:19:23 2019
ErrorMessage: subprocess new pre-installation script returned error exit status 
1
InstallationDate: Installed on 2019-07-27 (3 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801)
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1.5
 apt  1.2.32
SourcePackage: policykit-1
Title: package policykit-1 0.105-14.1ubuntu0.5 failed to install/upgrade: 
subprocess new pre-installation script returned error exit status 1
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: policykit-1 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package xenial

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

Title:
  package policykit-1 0.105-14.1ubuntu0.5 failed to install/upgrade:
  subprocess new pre-installation script returned error exit status 1

Status in policykit-1 package in Ubuntu:
  New

Bug description:
  I don't have Window.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: policykit-1 0.105-14.1ubuntu0.5
  ProcVersionSignature: Ubuntu 4.10.0-28.32~16.04.2-generic 4.10.17
  Uname: Linux 4.10.0-28-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.1-0ubuntu2.19
  Architecture: amd64
  Date: Tue Jul 30 11:19:23 2019
  ErrorMessage: subprocess new pre-installation script returned error exit 
status 1
  InstallationDate: Installed on 2019-07-27 (3 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.5
   apt  1.2.32
  SourcePackage: policykit-1
  Title: package policykit-1 0.105-14.1ubuntu0.5 failed to install/upgrade: 
subprocess new pre-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/policykit-1/+bug/1838485/+subscriptions

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

[Touch-packages] [Bug 1838215] Re: I can't log in with my user and password

2019-07-28 Thread John Erick Cabrera

I use Xubuntu operating system

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

Title:
  I can't log in with my user and password

Status in lightdm package in Ubuntu:
  New

Bug description:
  First I had the message  "No running instance of xfce-4 panel was
  found", then I rebooted my computer and the menu bar had disappeared,
  I rebooted again but now I try to loggin and password and the computer
  returns me to the menu of input user and password as if I had typed
  wrong my password.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: lightdm 1.26.0-0ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-25.26~18.04.1-generic 4.18.20
  Uname: Linux 4.18.0-25-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  Date: Sun Jul 28 17:33:45 2019
  InstallationDate: Installed on 2019-07-02 (26 days ago)
  InstallationMedia: Xubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: lightdm
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1838215] [NEW] I can't log in with my user and password

2019-07-28 Thread John Erick Cabrera

Public bug reported:

First I had the message  "No running instance of xfce-4 panel was
found", then I rebooted my computer and the menu bar had disappeared, I
rebooted again but now I try to loggin and password and the computer
returns me to the menu of input user and password as if I had typed
wrong my password.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: lightdm 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-25.26~18.04.1-generic 4.18.20
Uname: Linux 4.18.0-25-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
Date: Sun Jul 28 17:33:45 2019
InstallationDate: Installed on 2019-07-02 (26 days ago)
InstallationMedia: Xubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-bug bionic

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

Title:
  I can't log in with my user and password

Status in lightdm package in Ubuntu:
  New

Bug description:
  First I had the message  "No running instance of xfce-4 panel was
  found", then I rebooted my computer and the menu bar had disappeared,
  I rebooted again but now I try to loggin and password and the computer
  returns me to the menu of input user and password as if I had typed
  wrong my password.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: lightdm 1.26.0-0ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-25.26~18.04.1-generic 4.18.20
  Uname: Linux 4.18.0-25-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  Date: Sun Jul 28 17:33:45 2019
  InstallationDate: Installed on 2019-07-02 (26 days ago)
  InstallationMedia: Xubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: lightdm
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1837926] [NEW] snapd snap ftbfs in eoan due to python-apt regression

2019-07-25 Thread Dimitri John Ledkov

Public bug reported:

snapd snap FTBFS in launchpad snap build due to python-apt regression in
eoan

https://launchpad.net/~xnox/+snap/snapd/+build/626157

** Affects: python-apt (Ubuntu)
 Importance: Undecided
 Status: New

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


** Tags: core20 rls-ee-incoming

** Tags added: core20

** Tags added: rls-ee-incoming

** Also affects: python-apt (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  snapd snap ftbfs in eoan due to python-apt regression

Status in python-apt package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  New

Bug description:
  snapd snap FTBFS in launchpad snap build due to python-apt regression
  in eoan

  https://launchpad.net/~xnox/+snap/snapd/+build/626157

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

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

[Touch-packages] [Bug 1787225] Re: systemctl disable apache2 does nothing

2019-07-15 Thread Dimitri John Ledkov

** Also affects: apache2 (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/1787225

Title:
  systemctl disable apache2 does nothing

Status in apache2 package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I installed apache2 on Ubuntu 16.04, and out of the box it was enabled
  as a service, meaning it would automatically start at every boot. That
  is not what I want as this is my personal computer, not a server.

  $ systemctl is-enabled apache2.service 
  enabled

  
  So I ran:

  $ sudo systemctl disable apache2

  and this was the output:
 apache2.service is not a native service, redirecting to 
systemd-sysv-install
 Executing /lib/systemd/systemd-sysv-install disable apache2
 insserv: warning: current start runlevel(s) (empty) of script `apache2' 
overrides LSB defaults (2 3 4 5).
 insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`apache2' overrides LSB defaults (0 1 6).
 insserv: warning: current start runlevel(s) (empty) of script `apache2' 
overrides LSB defaults (2 3 4 5).
 insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`apache2' overrides LSB defaults (0 1 6).

  Then I rebooted. I expected to find apache2 not running. Instead, it was 
running.
  Surprisingly:

  $ systemctl is-enabled apache2.service 
  apache2.service is not a native service, redirecting to systemd-sysv-install
  Executing /lib/systemd/systemd-sysv-install is-enabled apache2
  disabled

  so, it shows up as disabled, yet it is started at startup.

  
  I wonder if this is what those warnings were about. Those messages are 
unclear as fuck, I have no f***ing clue what they are supposed to mean. I read 
that the CURRENT runlevel overrides a DEFAULT. I guess that should be fine, 
unless what systemctl actually changes are the defaults, and those are 
overwritten by something else, which means that "sysctl disable" will have no 
effect. If that is the case, then the warning should be more explicit:
  - be specific about the fact that "LSB defaults" are what the command is 
changing
  - tell me that as a result, the services will not be disabled
  - tell me WHAT is overriding the defaults that I'm attempting to change
  - and/or tell me what I am supposed to do to fix the issue

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu21.4
  ProcVersionSignature: Ubuntu 4.4.0-133.159-generic 4.4.134
  Uname: Linux 4.4.0-133-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Aug 15 16:26:28 2018
  InstallationDate: Installed on 2013-10-11 (1768 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MachineType: Acer Aspire V3-571G
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-133-generic.efi.signed 
root=UUID=5830b30e-69e8-4bb4-8a2b-bc2b43c7414a ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/15/2012
  dmi.bios.vendor: Acer
  dmi.bios.version: V2.07
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: VA50_HC_CR
  dmi.board.vendor: Acer
  dmi.board.version: Type2 - Board Version
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: V2.07
  dmi.modalias: 
dmi:bvnAcer:bvrV2.07:bd10/15/2012:svnAcer:pnAspireV3-571G:pvrV2.07:rvnAcer:rnVA50_HC_CR:rvrType2-BoardVersion:cvnAcer:ct10:cvrV2.07:
  dmi.product.name: Aspire V3-571G
  dmi.product.version: V2.07
  dmi.sys.vendor: Acer

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

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

[Touch-packages] [Bug 1832108] Re: unmkinitramfs fails with lz4 compressed initrds

lz4

6644040 bytes read in 282 ms (22.5 MiB/s)
4466915 bytes read in 191 ms (22.3 MiB/s)
reboot time 39.49s
2019-07-04T16:54:38.012115+ localhost kernel: Unpacking initramfs...
2019-07-04T16:54:38.012178+ localhost kernel: Initramfs unpacking failed: 
Decoding failed
2019-07-04T16:54:38.012246+ localhost kernel: Freeing initrd memory: 4404K

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

Title:
  unmkinitramfs fails with lz4 compressed initrds

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools package in Debian:
  New

Bug description:
  [Impact]

   * Cannot unpack initrds compressed with lz4 due to changes in lz4

  [Test Case]

  $ sudo apt install initramfs-tools lz4 file
  $ mkinitramfs -c lz4 -o foo.img
  $ lsinitramfs foo.img
  cpio: premature end of archive

  [Regression Potential]

   * New lz4cat is more strict w.r.t. enforcing file name extensions,
  thus the fix is to feed a stream to lz4cat instead of asking it to
  open a file. The performance impact should be similar between both
  methods of reading file contents during ls/unmk-initramfs time.

  [Other Info]

  Original bug report:

  unmkinitramfs fails with lz4 compressed initrds

  Note:
  $ lz4cat -t unmkinitramfs_Cz6Yl9
  File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: unmkinitramfs_Cz6Yl9

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

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

[Touch-packages] [Bug 1832108] Re: unmkinitramfs fails with lz4 compressed initrds

uncompressed:

7330304 bytes read in 311 ms (22.5 MiB/s)
reboot time 39.39s
2019-07-04T16:54:38.050180+ localhost kernel: Unpacking initramfs...
2019-07-04T16:54:38.050253+ localhost kernel: Freeing initrd memory: 7200K

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

Title:
  unmkinitramfs fails with lz4 compressed initrds

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools package in Debian:
  New

Bug description:
  [Impact]

   * Cannot unpack initrds compressed with lz4 due to changes in lz4

  [Test Case]

  $ sudo apt install initramfs-tools lz4 file
  $ mkinitramfs -c lz4 -o foo.img
  $ lsinitramfs foo.img
  cpio: premature end of archive

  [Regression Potential]

   * New lz4cat is more strict w.r.t. enforcing file name extensions,
  thus the fix is to feed a stream to lz4cat instead of asking it to
  open a file. The performance impact should be similar between both
  methods of reading file contents during ls/unmk-initramfs time.

  [Other Info]

  Original bug report:

  unmkinitramfs fails with lz4 compressed initrds

  Note:
  $ lz4cat -t unmkinitramfs_Cz6Yl9
  File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: unmkinitramfs_Cz6Yl9

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

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

[Touch-packages] [Bug 1832108] Re: unmkinitramfs fails with lz4 compressed initrds

gzip

6644040 bytes read in 283 ms (22.4 MiB/s)
3889013 bytes read in 167 ms (22.2 MiB/s)
reboot time 40.31s
2019-07-04T16:54:37.997158+ localhost kernel: Unpacking initramfs...
2019-07-04T16:54:37.997230+ localhost kernel: Freeing initrd memory: 3840K

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

Title:
  unmkinitramfs fails with lz4 compressed initrds

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools package in Debian:
  New

Bug description:
  [Impact]

   * Cannot unpack initrds compressed with lz4 due to changes in lz4

  [Test Case]

  $ sudo apt install initramfs-tools lz4 file
  $ mkinitramfs -c lz4 -o foo.img
  $ lsinitramfs foo.img
  cpio: premature end of archive

  [Regression Potential]

   * New lz4cat is more strict w.r.t. enforcing file name extensions,
  thus the fix is to feed a stream to lz4cat instead of asking it to
  open a file. The performance impact should be similar between both
  methods of reading file contents during ls/unmk-initramfs time.

  [Other Info]

  Original bug report:

  unmkinitramfs fails with lz4 compressed initrds

  Note:
  $ lz4cat -t unmkinitramfs_Cz6Yl9
  File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: unmkinitramfs_Cz6Yl9

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

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

[Touch-packages] [Bug 1832108] Re: unmkinitramfs fails with lz4 compressed initrds

ls -latr initrd-lzma.img initrd-uncompressed.img initrd-gzip.img 
initrd-lz49l.img | sort
-rwxr-xr-x 1 xnox xnox 2852487 Jul  5 00:19 initrd-lzma.img
-rwxr-xr-x 1 xnox xnox 3889013 Jul  5 00:21 initrd-gzip.img
-rwxr-xr-x 1 xnox xnox 4466915 Jul  5 00:22 initrd-lz49l.img
-rwxr-xr-x 1 xnox xnox 7330304 Jul  5 00:20 initrd-uncompressed.img

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

Title:
  unmkinitramfs fails with lz4 compressed initrds

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools package in Debian:
  New

Bug description:
  [Impact]

   * Cannot unpack initrds compressed with lz4 due to changes in lz4

  [Test Case]

  $ sudo apt install initramfs-tools lz4 file
  $ mkinitramfs -c lz4 -o foo.img
  $ lsinitramfs foo.img
  cpio: premature end of archive

  [Regression Potential]

   * New lz4cat is more strict w.r.t. enforcing file name extensions,
  thus the fix is to feed a stream to lz4cat instead of asking it to
  open a file. The performance impact should be similar between both
  methods of reading file contents during ls/unmk-initramfs time.

  [Other Info]

  Original bug report:

  unmkinitramfs fails with lz4 compressed initrds

  Note:
  $ lz4cat -t unmkinitramfs_Cz6Yl9
  File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: unmkinitramfs_Cz6Yl9

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

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

[Touch-packages] [Bug 1832108] Re: unmkinitramfs fails with lz4 compressed initrds

$ file initrd.img 
initrd.img: LZMA compressed data, streamed

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

Title:
  unmkinitramfs fails with lz4 compressed initrds

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools package in Debian:
  New

Bug description:
  [Impact]

   * Cannot unpack initrds compressed with lz4 due to changes in lz4

  [Test Case]

  $ sudo apt install initramfs-tools lz4 file
  $ mkinitramfs -c lz4 -o foo.img
  $ lsinitramfs foo.img
  cpio: premature end of archive

  [Regression Potential]

   * New lz4cat is more strict w.r.t. enforcing file name extensions,
  thus the fix is to feed a stream to lz4cat instead of asking it to
  open a file. The performance impact should be similar between both
  methods of reading file contents during ls/unmk-initramfs time.

  [Other Info]

  Original bug report:

  unmkinitramfs fails with lz4 compressed initrds

  Note:
  $ lz4cat -t unmkinitramfs_Cz6Yl9
  File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: unmkinitramfs_Cz6Yl9

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

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

[Touch-packages] [Bug 1832108] Re: unmkinitramfs fails with lz4 compressed initrds

Testing on cm3

switch to partitions #0, OK
mmc0(part 0) is current device
LOADBOOTENV
** Unable to read file uEnv.txt **
Running uenvcmd ...
ENVCMD
6644040 bytes read in 282 ms (22.5 MiB/s) (this is kernel)
2852487 bytes read in 123 ms (22.1 MiB/s) (this is initrd)
FAT: Misaligned buffer address (023b8687)
42049 bytes read in 14 ms (2.9 MiB/s)

2019-07-04T15:35:05.998027+ localhost kernel: Unpacking initramfs...
2019-07-04T15:35:05.998089+ localhost kernel: Freeing initrd memory: 2828K

(not sure if above is true gzip decompression speed of initramfs or not)

Watching telnet, from reboot until "Press enter to configure" took
41.84s (42.25s 41.50s).

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

Title:
  unmkinitramfs fails with lz4 compressed initrds

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools package in Debian:
  New

Bug description:
  [Impact]

   * Cannot unpack initrds compressed with lz4 due to changes in lz4

  [Test Case]

  $ sudo apt install initramfs-tools lz4 file
  $ mkinitramfs -c lz4 -o foo.img
  $ lsinitramfs foo.img
  cpio: premature end of archive

  [Regression Potential]

   * New lz4cat is more strict w.r.t. enforcing file name extensions,
  thus the fix is to feed a stream to lz4cat instead of asking it to
  open a file. The performance impact should be similar between both
  methods of reading file contents during ls/unmk-initramfs time.

  [Other Info]

  Original bug report:

  unmkinitramfs fails with lz4 compressed initrds

  Note:
  $ lz4cat -t unmkinitramfs_Cz6Yl9
  File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: unmkinitramfs_Cz6Yl9

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

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

[Touch-packages] [Bug 1835257] Re: update tzdata package to 2019b

https://trello.com/c/CVhZRo2o

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

Title:
  update tzdata package to 2019b

Status in tzdata package in Ubuntu:
  New

Bug description:
  Update tzdata package to 2019b.

  https://mm.icann.org/pipermail/tz-announce/2019-July/56.html

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

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

[Touch-packages] [Bug 1830169] Re: lvm udev rule fails to call systemd-run

2019-07-01 Thread Dimitri John Ledkov

@hws as the status says on launchpad, both xenial and bionic are "in
progress". Awaiting SRU team reviews to be accepted into -proposed.

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

Title:
  lvm udev rule fails to call systemd-run

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 source package in Xenial:
  In Progress
Status in lvm2 source package in Bionic:
  In Progress
Status in lvm2 source package in Cosmic:
  Fix Released
Status in lvm2 source package in Disco:
  Fix Released
Status in lvm2 source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  Judging from the rule, this probably means that volumes do not disappear when 
the physical volume disappears.

  [Test case]
  Not available. But since it's just a path fix, it should not be a problem.

  [Regression potential]
  Removal might now actually work correctly, but it's not entirely clear how 
that could cause a regression.

  [Other info]
  In /lib/udev/rules.d/69-lvm-metad.rules file, it calls /bin/systemd-run 
command during removal ---
     ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm 
pvscan --cache $major:$minor", GOTO="lvm_end"

  But /bin/systemd-run is not found,  in fact systemd-run is in /usr/bin
  /systemd-run.

  xx:~$ cat /etc/issue
  Ubuntu 18.04.2 LTS \n \l

  xx:~$ ls /bin/systemd-run
  ls: cannot access '/bin/systemd-run': No such file or directory

  xx:~$ ls /usr/bin/systemd-run
  /usr/bin/systemd-run

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830169/+subscriptions

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

[Touch-packages] [Bug 1834832] [NEW] printer keeps on printing and it is rubish

2019-07-01 Thread John

Public bug reported:

Xerox Phaser-3435 printer starts will not stop and the print job is not
showing to close,as well as that it is just spitting out rubbish on the
pages,windows may be coming back.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: cups 2.2.7-1ubuntu2.6
ProcVersionSignature: Ubuntu 4.15.0-54.58-generic 4.15.18
Uname: Linux 4.15.0-54-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CupsErrorLog:
 
CurrentDesktop: ubuntu:GNOME
Date: Mon Jul  1 17:58:08 2019
InstallationDate: Installed on 2019-01-06 (175 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
Lpstat: device for Phaser-3435: usb://Xerox/Phaser%203435?serial=RVX451472
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 045e:0084 Microsoft Corp. Basic Optical Mouse
 Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
 Bus 001 Device 005: ID 0bda:0103 Realtek Semiconductor Corp. USB 2.0 Card 
Reader
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Gigabyte Technology Co., Ltd. B250M-HD3
Papersize: a4
PpdFiles: Error: command ['fgrep', '-H', '*NickName', 
'/etc/cups/ppd/Phaser-3435.ppd'] failed with exit code 2: grep: 
/etc/cups/ppd/Phaser-3435.ppd: Permission denied
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-54-generic 
root=UUID=063c3aa1-dc53-4693-882d-d4fe078115f5 ro quiet splash vt.handoff=1
SourcePackage: cups
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/10/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F9
dmi.board.asset.tag: Default string
dmi.board.name: B250M-HD3-CF
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF9:bd04/10/2018:svnGigabyteTechnologyCo.,Ltd.:pnB250M-HD3:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB250M-HD3-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.family: Default string
dmi.product.name: B250M-HD3
dmi.product.version: Default string
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

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


** Tags: amd64 apport-bug bionic

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

Title:
  printer keeps on printing and it is rubish

Status in cups package in Ubuntu:
  New

Bug description:
  Xerox Phaser-3435 printer starts will not stop and the print job is
  not showing to close,as well as that it is just spitting out rubbish
  on the pages,windows may be coming back.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cups 2.2.7-1ubuntu2.6
  ProcVersionSignature: Ubuntu 4.15.0-54.58-generic 4.15.18
  Uname: Linux 4.15.0-54-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  CupsErrorLog:
   
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul  1 17:58:08 2019
  InstallationDate: Installed on 2019-01-06 (175 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lpstat: device for Phaser-3435: usb://Xerox/Phaser%203435?serial=RVX451472
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 045e:0084 Microsoft Corp. Basic Optical Mouse
   Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
   Bus 001 Device 005: ID 0bda:0103 Realtek Semiconductor Corp. USB 2.0 Card 
Reader
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Gigabyte Technology Co., Ltd. B250M-HD3
  Papersize: a4
  PpdFiles: Error: command ['fgrep', '-H', '*NickName', 
'/etc/cups/ppd/Phaser-3435.ppd'] failed with exit code 2: grep: 
/etc/cups/ppd/Phaser-3435.ppd: Permission denied
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-54-generic 
root=UUID=063c3aa1-dc53-4693-882d-d4fe078115f5 ro quiet splash vt.handoff=1
  SourcePackage: cups
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/10/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F9
  dmi.board.asset.tag: Default string
  dmi.board.name: B250M-HD3-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF9:bd04/10/2018:svnGigabyteTechnologyCo.,Ltd.:pnB250M-HD3:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB250M-HD3-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: B250M-HD3
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1814355] Re: snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression)

** Description changed:

  [Impact]
  
-  * Initramfs exports PATH to init, which is different than the expected
+  * Initramfs exports PATH to init, which is different than the expected
  stock / compiled one, which results in slightly different runtime
  behaviour of init, if it has environment generators as well.
  
- 
  [Test Case]
  
-  * Disable snapd env generator & disable initrd-less boot (if enabled)
-sudo chmod -x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator
-set empty GRUB_FORCE_PARTUUID= and update-grub
-
-  * Reboot cosmic system with an initramfs
-$ journalctl -b -k | grep initramfs
-(verify that initramfs was unpacked)
+  * Disable snapd env generator & disable initrd-less boot (if enabled)
+    sudo chmod -x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator
+    set empty GRUB_FORCE_PARTUUID= and update-grub
  
-  * Check the path used by systemd, ie.:
-systemd-run /usr/bin/env
-journalctl -b -e | grep PATH
+  * Reboot cosmic system with an initramfs
+    $ journalctl -b -k | grep initramfs
+    (verify that initramfs was unpacked)
  
-It should contain /usr/local
+  * Check the path used by systemd, ie.:
+    systemd-run /usr/bin/env
+    journalctl -b -e | grep PATH
  
-  * Upgrade initramfs-tools & reboot
+    It should contain /usr/local
  
-The path should remain the same and it should contain /usr/local
+  * Enable any env generator for example & reboot:
+/usr/lib/systemd/system-environment-generators/xnox.sh
+#!/bin/sh
+echo XNOX=ROCKS
  
-  * Enable snapd env generator and reboot again
+  * Verify path used by systemd
  
-  * Verify path used by systemd
+    It should still contain /usr/local
  
-It should still contain /usr/local & /snap/bin
+ Repeat again with the new initramfs-tools.
+ 
  
  [Regression Potential]
  
-  * We are hardcoding, the same path, yet again, in one more place.
- However, we are setting it to a well-known value as it was pre
+  * We are hardcoding, the same path, yet again, in one more place. However, 
we are setting it to a well-known value (see https://wiki.ubuntu.com/PATH
+  ) as it is universally expected and regressed when booted (a) with initrd 
AND (b) with broken path exported by initrd AND (c) with an env-generator.
  
  [Other Info]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
+ 
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
  
  ===
  
  Big regression in 2.37.1+18.04 compare to version 2.34.2
  
  all these paths  /usr/local/sbin &  /usr/local/bin are not anymore in
  the path of all systemd process .
  
  So we can not start a daemon that use /usr/local/bin
  
  reinstalling package 2.34.2 fix the problem
  
  in 2.34.2 :
  
  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  
  in 2.37.1+18.04 :
  
  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/sbin:/usr/sbin:/bin:/usr/bin:/snap/bin

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

Title:
  snapd remove /usr/local/bin from the PATH for all systemd unit (bionic
  SRU regression)

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in snapd source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in initramfs-tools source package in Cosmic:
  New
Status in snapd source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  New

Bug description:
  [Impact]

   * Initramfs exports PATH to init, which is different than the
  expected stock / compiled one, which results in slightly different
  runtime behaviour of init, if it has environment generators as well.

  [Test Case]

   * Disable snapd env generator & disable initrd-less boot (if enabled)
     sudo chmod -x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator
     set empty GRUB_FORCE_PARTUUID= and update-grub

   * Reboot cosmic system with an initramfs
     $ journalctl -b -k | grep initramfs
     (verify that initramfs was unpacked)

   * Check the path used by systemd, ie.:
     systemd-run /usr/bin/env
     journalctl -b -e | grep PATH

     It should contain /usr/local

   * Enable any env generator for example & reboot:
 /usr/lib/systemd/system-environment-generators/xnox.sh
 #!/bin/sh
 echo XNOX=ROCKS

   * Verify path used by systemd

[Touch-packages] [Bug 1814355] Re: snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression)

** Description changed:

+ [Impact]
+ 
+  * Initramfs exports PATH to init, which is different than the expected
+ stock / compiled one, which results in slightly different runtime
+ behaviour of init, if it has environment generators as well.
+ 
+ 
+ [Test Case]
+ 
+  * Disable snapd env generator & disable initrd-less boot (if enabled)
+sudo chmod -x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator
+set empty GRUB_FORCE_PARTUUID= and update-grub
+
+  * Reboot cosmic system with an initramfs
+$ journalctl -b -k | grep initramfs
+(verify that initramfs was unpacked)
+ 
+  * Check the path used by systemd, ie.:
+systemd-run /usr/bin/env
+journalctl -b -e | grep PATH
+ 
+It should contain /usr/local
+ 
+  * Upgrade initramfs-tools & reboot
+ 
+The path should remain the same and it should contain /usr/local
+ 
+  * Enable snapd env generator and reboot again
+ 
+  * Verify path used by systemd
+ 
+It should still contain /usr/local & /snap/bin
+ 
+ [Regression Potential]
+ 
+  * We are hardcoding, the same path, yet again, in one more place.
+ However, we are setting it to a well-known value as it was pre
+ 
+ [Other Info]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ ===
+ 
  Big regression in 2.37.1+18.04 compare to version 2.34.2
  
  all these paths  /usr/local/sbin &  /usr/local/bin are not anymore in
  the path of all systemd process .
  
  So we can not start a daemon that use /usr/local/bin
  
- 
  reinstalling package 2.34.2 fix the problem
  
  in 2.34.2 :
-  
+ 
  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  
  in 2.37.1+18.04 :
  
  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/sbin:/usr/sbin:/bin:/usr/bin:/snap/bin

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

Title:
  snapd remove /usr/local/bin from the PATH for all systemd unit (bionic
  SRU regression)

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in snapd source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in initramfs-tools source package in Cosmic:
  New
Status in snapd source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  New

Bug description:
  [Impact]

   * Initramfs exports PATH to init, which is different than the
  expected stock / compiled one, which results in slightly different
  runtime behaviour of init, if it has environment generators as well.

  
  [Test Case]

   * Disable snapd env generator & disable initrd-less boot (if enabled)
 sudo chmod -x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator
 set empty GRUB_FORCE_PARTUUID= and update-grub
 
   * Reboot cosmic system with an initramfs
 $ journalctl -b -k | grep initramfs
 (verify that initramfs was unpacked)

   * Check the path used by systemd, ie.:
 systemd-run /usr/bin/env
 journalctl -b -e | grep PATH

 It should contain /usr/local

   * Upgrade initramfs-tools & reboot

 The path should remain the same and it should contain /usr/local

   * Enable snapd env generator and reboot again

   * Verify path used by systemd

 It should still contain /usr/local & /snap/bin

  [Regression Potential]

   * We are hardcoding, the same path, yet again, in one more place.
  However, we are setting it to a well-known value as it was pre

  [Other Info]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  ===

  Big regression in 2.37.1+18.04 compare to version 2.34.2

  all these paths  /usr/local/sbin &  /usr/local/bin are not anymore in
  the path of all systemd process .

  So we can not start a daemon that use /usr/local/bin

  reinstalling package 2.34.2 fix the problem

  in 2.34.2 :

  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  in 2.37.1+18.04 :

  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/sbin:/usr/sbin:/bin:/usr/bin:/snap/bin

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

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

[Touch-packages] [Bug 1814355] Re: snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression)

** Also affects: initramfs-tools (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

** Also affects: snapd (Ubuntu Cosmic)
   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/1814355

Title:
  snapd remove /usr/local/bin from the PATH for all systemd unit (bionic
  SRU regression)

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in snapd source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in initramfs-tools source package in Cosmic:
  New
Status in snapd source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  New

Bug description:
  Big regression in 2.37.1+18.04 compare to version 2.34.2

  all these paths  /usr/local/sbin &  /usr/local/bin are not anymore in
  the path of all systemd process .

  So we can not start a daemon that use /usr/local/bin

  
  reinstalling package 2.34.2 fix the problem

  in 2.34.2 :
   
  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  in 2.37.1+18.04 :

  ~# strings  /proc/$(pidof /lib/systemd/systemd-resolved)/environ | grep PATH
  PATH=/sbin:/usr/sbin:/bin:/usr/bin:/snap/bin

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

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

[Touch-packages] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

In effect, I'm saying that we need to (a) fix systemd as per this bug
report (b) fix initramfs-tools (c) only then enable snapd env generator

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

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in snapd source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed
Status in snapd source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Fix Committed
Status in snapd source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

   * When a generator started to be provided by systemd, it was
  recognized that $PATH is not correctly set, nonetheless, due to an
  environment bug that systemd generators run in.

  [Testcase]

  # make snapd-env-generator executable if it is not
  $ sudo chmod +x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator

  # reboot, then test the effect of the fix
  $ systemd-run /usr/bin/env
  $ journalctl -e | grep PATH

  Output should contain /snap/bin

  Output should contain a complete and a valid PATH, i.e.
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" 
or similar.

  [Regression Potential]

   * snapd generator was already fixed separately to cause no harm, when
  running under a broken systemd. With the corrected environment,
  generators will now run with a correct PATH out of the box. A slight
  change of PATH will be observed by all generators, when running in
  containers/initramfs-less boots. However most generators will not be
  affected as they typically do not execute external binaries.

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

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

[Touch-packages] [Bug 1791691] Re: PATH broken in systemd units

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  PATH broken in systemd units

Status in cloud-images:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  New
Status in snapd source package in Bionic:
  In Progress
Status in initramfs-tools source package in Cosmic:
  New
Status in snapd source package in Cosmic:
  Fix Released

Bug description:
  systemd units have broken PATH in recent cloud images.
  The PATH set for them is
    PATH=:/snap/bin.
  Previously value is
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  # cat /etc/cloud/build.info
  build_name: server
  serial: 20180906

  Booted in lxc that fails like:
  # lxc launch ubuntu-daily:cosmic c3
  # lxc exec c3 cat /run/cloud-init/result.json
  {
   "v1": {
    "datasource": null,
    "errors": [
     "Unexpected error while running command.\nCommand: ['netplan', 
'generate']\nExit code: -\nReason: [Errno 2] No such file or directory: 
b'netplan': b'netplan'\nStdout: -\nStderr: -",
     "Unexpected error while running command.\nCommand: ['netplan', 
'generate']\nExit code: -\nReason: [Errno 2] No such file or directory: 
b'netplan': b'netplan'\nStdout: -\nStderr: -",
     "('ssh-authkey-fingerprints', KeyError('getpwnam(): name not found: 
ubuntu',))"
    ]
   }
  }

  
  Related bugs:
   * bug 1771382: ds-identify: does not have expected PATH.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1791691/+subscriptions

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

[Touch-packages] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

We have codepaths with and without initrd, which results in different
environment that systemd starts up with.

In bionic, initramfs-tools sets PATH to
PATH=/sbin:/usr/sbin:/bin:/usr/bin

In later releases, initramfs-tools sets PATH to
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

And systemd can come up without initrd (lxd) in which case PATH is not
set at all, and internally systemd uses the built-in compiled PATH.

The snapd environment generator has been fixed to handle the case of
empty or unset PATH. But it only appends the snapd path, meaning that it
doesn't inject /usr/local into the PATH.

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

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in snapd source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed
Status in snapd source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Fix Committed
Status in snapd source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

   * When a generator started to be provided by systemd, it was
  recognized that $PATH is not correctly set, nonetheless, due to an
  environment bug that systemd generators run in.

  [Testcase]

  # make snapd-env-generator executable if it is not
  $ sudo chmod +x 
/usr/lib/systemd/system-environment-generators/snapd-env-generator

  # reboot, then test the effect of the fix
  $ systemd-run /usr/bin/env
  $ journalctl -e | grep PATH

  Output should contain /snap/bin

  Output should contain a complete and a valid PATH, i.e.
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" 
or similar.

  [Regression Potential]

   * snapd generator was already fixed separately to cause no harm, when
  running under a broken systemd. With the corrected environment,
  generators will now run with a correct PATH out of the box. A slight
  change of PATH will be observed by all generators, when running in
  containers/initramfs-less boots. However most generators will not be
  affected as they typically do not execute external binaries.

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

-- 
Mailing list: https://launchpad.net/~touch-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-06-25 Thread Dimitri John Ledkov

I think for this ticket we want:

commit b5872f95b64177212b2e129dcae15d91c46abbc8
Author: Yann Ylavic 
Date:   Fri Jun 15 11:12:19 2018 +

mod_ssl: disable check for client initiated renegotiations with TLS 1.3.

This is already forbidden by the protocol, enforced by OpenSSL, and the
current logic can't work (ssl_callback_Info() may be called multiple times
with TLS 1.3).


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1833588 
13f79535-47bb-0310-9956-ff
a450edef68

-- 
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 1833039] Re: 18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1

2019-06-25 Thread Dimitri John Ledkov

@ssp297

I believe this is different. renegotiation & client certs do not depend
on each other, and can be used together or separately.

-- 
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 1833039] Re: 18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1

2019-06-25 Thread Dimitri John Ledkov

@benjamin

I believe disabling TLSv1.3 via openssl.cnf tweak would work too,
without downgrading openssl.

Ie. Using something like this https://launchpadlibrarian.net/428208982
/cap-to-tls1.2.patch

(Probably without the CipherString line, which will raise security
requirements higher than the default)

-- 
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 1832108] Re: unmkinitramfs fails with lz4 compressed initrds

2019-06-24 Thread Dimitri John Ledkov

Reproduce the problem:

# dpkg-query -W initramfs-tools lz4
initramfs-tools 0.131ubuntu19
lz4 1.8.3-1ubuntu1

# sed -i 's/gzip/lz4/' /etc/initramfs-tools/initramfs.conf

# update-initramfs -c -k test

# lsinitramfs /boot/initrd.img-test 
cpio: premature end of archive

===

# sed 's/-updates/-proposed/' -i /etc/apt/sources.list
# apt update
# dpkg-query -W initramfs-tools lz4
initramfs-tools 0.131ubuntu19.1
lz4 1.8.3-1ubuntu1

# lsinitramfs /boot/initrd.img-test
...
all the files are listed


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

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

Title:
  unmkinitramfs fails with lz4 compressed initrds

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Committed
Status in initramfs-tools package in Debian:
  New

Bug description:
  [Impact]

   * Cannot unpack initrds compressed with lz4 due to changes in lz4

  [Test Case]

  $ sudo apt install initramfs-tools lz4 file
  $ mkinitramfs -c lz4 -o foo.img
  $ lsinitramfs foo.img
  cpio: premature end of archive

  [Regression Potential]

   * New lz4cat is more strict w.r.t. enforcing file name extensions,
  thus the fix is to feed a stream to lz4cat instead of asking it to
  open a file. The performance impact should be similar between both
  methods of reading file contents during ls/unmk-initramfs time.

  [Other Info]

  Original bug report:

  unmkinitramfs fails with lz4 compressed initrds

  Note:
  $ lz4cat -t unmkinitramfs_Cz6Yl9
  File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process 
file: unmkinitramfs_Cz6Yl9

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

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

[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-06-24 Thread Dimitri John Ledkov

verification-needed-cosmic is blocking publishing the next initramfs-
tools update in cosmic.

Am I ok to trump the current initramfs-tools in cosmic-proposed with a
new upload?

Do we want to back out this change?

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

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  Fix Committed
Status in initramfs-tools source package in Disco:
  Fix Released

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  In order to verify the fix, one needs to change MODULES option to dep
  on /etc/initramfs-tools/initramfs.conf, recreate initramfs and reboot,
  check the system has booted fine. That should not break on systems
  with non nvme disks or systems with non multipath nvme systems, and
  that should now work on multipath nvme systems.

  sed -i /MODULES=/s,=.*,=dep, /etc/initramfs-tools/initramfs.conf
  update-initramfs -u -k all
  reboot

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.

  -

  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

  root@woo:~#  kdump-config status
  current state   : ready to kdump

  root@woo:~#  kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
  crashkernel addr:
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652]

[Touch-packages] [Bug 1833758] Re: lvm2: vgcfgbackup in postinst takes several minutes

2019-06-24 Thread Dimitri John Ledkov

** Tags added: rls-ee-incoming

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

Title:
lvm2: vgcfgbackup in postinst takes several minutes

Status in lvm2 package in Ubuntu:
New

Bug description:
The postinst for lvm2 includes a call to vgcfgbackup; in the version
included in eoan 2.03.02-2ubuntu4 (and 2.03.02-2ubuntu3 before it),
this command takes several minutes to run when invoked in an schroot
as happens when a building a package with sbuild that ends up pulling
lvm2 as part of its build dependency chain. An example package with
lvm2 in its build depends is rsnapshot, but this behavior was seen
with a build of glibc. Some notes:

- this behavior is NOT seen with the version of lvm2 in disco.
- this happens in bionic with a 4.15 kernel and disco with a 5.0 kernel
(different hosts, so different sets of block devices)
- this happens regardless of whether the host is currently using logical
volumes or not

Here's the time difference between running the disco version and the
eoan version:

(disco-amd64)root@HOSTNAME:~# time vgcfgbackup
WARNING: Failed to connect to lvmetad. Falling back to device scanning.

real0m0.204s
user0m0.014s
sys 0m0.010s

(eoan-amd64)root@HOSTNAME:~# time vgcfgbackup
WARNING: Device /dev/sda not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sda1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sda2 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sda3 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdb not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdb1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdb2 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdb3 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdc not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdc1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdd not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdd1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sde not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sde1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sde2 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sda1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sda2 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sda3 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdb1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdb2 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdb3 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdc1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sdd1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sde1 not initialized in udev database even after
waiting 1000 microseconds.
WARNING: Device /dev/sde2 not initialized in udev database even after
waiting 1000 microseconds.

real4m11.405s
user0m0.470s
sys 0m0.576s

/proc/mounts in the schroot:

(eoan-amd64)root@HOSTNAME:~# cat /proc/mounts
eoan-amd64 / overlay
rw,relatime,lowerdir=/var/lib/schroot/union/underlay/eoan-amd64-29c7f791-9409-4505-9192-7c4685b8be34,upperdir=/srv/devel/schroot-overlays/eoan-amd64-29c7f791-9409-4505-9192-7c4685b8be34/upper,workdir=/srv/devel/schroot-overlays/eoan-amd64-29c7f791-9409-4505-9192-7c4685b8be34/work
0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs
rw,nosuid,relatime,size=10197712k,nr_inodes=2549428,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
0 0
/dev/sda2 /home ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda2 /tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /run/shm tmpfs rw,relatime 0 0
/dev/sda2 /scratch ext4

[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS

Looking at autopkgtest regressions for python-tornado
http://autopkgtest.ubuntu.com/packages/b/bdfproxy/bionic/ppc64el has
never passed on bionic.

Can sru team please commit badtest hint for bdfproxy and release python-
tarnado?

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

Title:
  [SRU] OpenSSL 1.1.1 to 18.04 LTS

Status in libwww-perl package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in libio-socket-ssl-perl source package in Bionic:
  Fix Released
Status in libnet-ssleay-perl source package in Bionic:
  Fix Released
Status in libwww-perl source package in Bionic:
  Fix Released
Status in openssl source package in Bionic:
  Fix Released
Status in python-cryptography source package in Bionic:
  Fix Released
Status in python-tornado source package in Bionic:
  Fix Committed
Status in python2.7 source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in r-cran-openssl source package in Bionic:
  Fix Released
Status in ruby-openssl source package in Bionic:
  Fix Released
Status in ruby2.5 source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * OpenSSL 1.1.1 is an LTS release upstream, which will continue to
  receive security support for much longer than 1.1.0 series will.

   * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
  be rapidly adopted due to increased set of supported hashes & algoes,
  as well as improved handshake [re-]negotiation.

   * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.

   * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
  software is sensitive to the negotiation handshake and may either need
  patches/improvements or clamp-down to maximum v1.2.

  [Test Case]

   * Rebuild all reverse dependencies

   * Execute autopkg tests for all of them

   * Clamp down to TLS v1.2 software that does not support TLS v1.3
  (e.g. mongodb)

   * Backport TLS v1.3 support patches, where applicable

  [Test cases for the python updates]

  python3.7 is a preview in bionic as a non-supported/non-default
  version of python3. Passing it's own autopkgtests is sufficient
  validation for python3.7. It includes a point release update, with
  OpenSSL 1.1.1 compat and features.

  python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
  also includes a point release update to 3.6.8. It has been part of the
  full-archive rebuild and regression analysis. Autopkgtests were
  triggered for python3.6 and python3-defaults with regressions already
  fixed in the individual packages as appropriate.

  python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
  compat only. It has been part of the full-archive rebuild and
  regression analysis. Autopkgtests were triggered for python2.7 and
  python-defaults with regressions already fixed in the individual
  packages as appropriate.

  The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 
and python point releases as seen in:
  
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
  
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html

  And analyzed in
  
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652

  [ Test case libwww-perl (and deps) regression ]

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

  1. apt install liblwp-protocol-https-perl
  2. enable -proposed
  3. apt install libio-socket-ssl-perl libnet-ssleay-perl
  4. perl -MLWP::UserAgent -e 
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'

  [Regression Potential]

   * Connectivity interop is the biggest issues which will be
  unavoidable with introducing TLS v1.3. However, tests on cosmic
  demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
  negotiate TLS v1.3 without issues.

   * Mitigation of discovered connectivity issues will be possible by
  clamping down to TLS v1.2 in either server-side or client-side
  software or by backporting relevant support fixes

   * Notable changes are listed here
  https://wiki.openssl.org/index.php/TLS1.3

   * Most common connectivity issues so far:
     - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. 
Solution is client change to set hostname, or to clamp down the client to 
TLSv1.2.

     - session negotiation is different in TLSv1.3, existing client code
  may fail to create/negotiate/resume session. Clients need to learn how
  to use session callback.

     - non-application data records. TLSv1.3 sends more of these, when compared 
with previous versions, and some applications may not handle this correctly. 
Resulting in application data not being

[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10

downgraded bionic lxd container to bionic release / security packages only.
installing libssl1.1 from -updates fails with:
dpkg: error processing package libssl1.1:amd64 (--configure):
 installed libssl1.1:amd64 package post-installation script subprocess returned 
error exit status 10
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Errors were encountered while processing:
 libssl1.1:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Upgrading back to libssl1.1 from bionic-updates fails.
Upgrading from bionic-security to the CI train ppa succeeds.

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

Title:
  installed libssl1.1:amd64 package post-installation script subprocess
  returned error exit status 10

Status in openssl package in Ubuntu:
  Fix Committed
Status in openssl source package in Bionic:
  Fix Committed
Status in openssl source package in Cosmic:
  In Progress
Status in openssl source package in Disco:
  In Progress
Status in openssl source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Systems that have in error removed debconf database fail to upgrade
  libssl1.1 (as e.g. is known to be done in some vagrant boxes)

   * libssl1.1 tries to use debconf template from libc6 package, but
  doesn't ship one by itself as it should for shared templates. As it is
  not guaranteed that template will be available.

  [TestCase]

  # DO NOT DO THIS ON PRODUCTION MACHINES #
  # echo PURGE | debconf-communicate libpam0g:amd64
  0
  # echo PURGE | debconf-communicate libpam0g
  0
  # echo PURGE | debconf-communicate libc6:amd64
  0
  # echo PURGE | debconf-communicate libc6
  0

  Then upgrade from bionic-release to the -proposed package and it
  should work.

  It should not fail with exit code 10.

  [Regression Potential]

   * A new template is added, an identical import from glibc without any
  further changes. This registers the template in debconf, for this
  package, preventing the above describe error. This has no codechanges,
  only metadata.

  [Other Info]
   
   * Original bug report 

  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)

  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64

  [ WORKAROUND TO RECOVER YOUR SYSTEM ]

  $ sudo dpkg-reconfigure libc6
  $ sudo dpkg --configure libssl1.1

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

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

[Touch-packages] [Bug 1829805] Re: Lubuntu Eoan Daily Image fails to boot after install on KVM

For initramfs-tools... please provide steps to reproduce the issue of
when initrds are expected to be created and are not, with steps how to
get in such situation (e.g. rm /boot/initrd*; update-initramfs...)

*without* requiring to use calamares, or specific images. ie. from any
regular normal working installed system.

Until then, I'm failing to understand what the bug in initramfs-tools is
allegedly identified.

** Changed in: initramfs-tools (Ubuntu)
   Status: Triaged => Incomplete

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

Title:
  Lubuntu Eoan Daily Image fails to boot after install on KVM

Status in calamares-settings-ubuntu package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Incomplete

Bug description:
  Context: The live environment appears to function properly and install
  proceeds as expected with no noticeable errors.

  Expected results: After a system reboot the virtual machine enters the
  graphical environment

  Actual Results: After rebooting the virtual machine a kernel panic
  error screen appears. I will attempt to attach the screenshot after
  submitting this bug report.

  The collected data is from the live environment as the installed
  environment will not boot.

  lubuntu@lubuntu:~$ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10
  Codename:   eoan

  lubuntu@lubuntu:~$ apt-cache policy grub2
  grub2:
Installed: (none)
Candidate: 2.02+dfsg1-12ubuntu2
Version table:
   2.02+dfsg1-12ubuntu2 500
  500 cdrom://Lubuntu 19.10 _Eoan Ermine_ - Alpha amd64 (20190519) 
eoan/universe amd64 Packages
  500 http://archive.ubuntu.com/ubuntu eoan/universe amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: grub2 (not installed)
  ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
  Uname: Linux 5.0.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  CasperVersion: 1.407
  CurrentDesktop: LXQt
  Date: Tue May 21 00:30:39 2019
  LiveMediaBuild: Lubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190519)
  SourcePackage: grub2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/1829805/+subscriptions

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

[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10

** Description changed:

+ [Impact]
+ 
+  * Systems that have in error removed debconf database fail to upgrade
+ libssl1.1 (as e.g. is known to be done in some vagrant boxes)
+ 
+  * libssl1.1 tries to use debconf template from libc6 package, but
+ doesn't ship one by itself as it should for shared templates. As it is
+ not guaranteed that template will be available.
+ 
+ [TestCase]
+ 
+ # DO NOT DO THIS ON PRODUCTION MACHINES #
+ # echo PURGE | debconf-communicate libpam0g:amd64
+ 0
+ # echo PURGE | debconf-communicate libpam0g
+ 0
+ # echo PURGE | debconf-communicate libc6:amd64
+ 0
+ # echo PURGE | debconf-communicate libc6
+ 0
+ 
+ Then upgrade from bionic-release to the -proposed package and it should
+ work.
+ 
+ It should not fail with exit code 10.
+ 
+ [Regression Potential]
+ 
+  * A new template is added, an identical import from glibc without any
+ further changes. This registers the template in debconf, for this
+ package, preventing the above describe error. This has no codechanges,
+ only metadata.
+ 
+ [Other Info]
+  
+  * Original bug report 
+ 
  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)
  
  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64
  
  [ WORKAROUND TO RECOVER YOUR SYSTEM ]
  
  $ sudo dpkg-reconfigure libc6
  $ sudo dpkg --configure libssl1.1
- 
- [ Reproducer steps ]
- 
- # DO NOT DO THIS ON PRODUCTION MACHINES #
- 
- # echo PURGE | debconf-communicate libpam0g:amd64
- 0
- # echo PURGE | debconf-communicate libpam0g
- 0
- # echo PURGE | debconf-communicate libc6:amd64
- 0
- # echo PURGE | debconf-communicate libc6
- 0
- # sh -x /var/lib/dpkg/info/libssl1.1\:amd64.postinst configure 1.1.1
- + . /usr/share/debconf/confmodule
- + [ !  ]
- + PERL_DL_NONLAZY=1
- + export PERL_DL_NONLAZY
- + [  ]
- + exec /usr/share/debconf/frontend 
/var/lib/dpkg/info/libssl1.1:amd64.postinst configure 1.1.1
- Checking for services that may need to be restarted...done.
- Checking for services that may need to be restarted...done.
- Checking init scripts...
- 
- # echo $?
- 10

** Changed in: openssl (Ubuntu Eoan)
   Status: Confirmed => Fix Committed

** Changed in: openssl (Ubuntu Disco)
   Status: Confirmed => In Progress

** Changed in: openssl (Ubuntu Cosmic)
   Status: Confirmed => In Progress

** Changed in: openssl (Ubuntu Bionic)
   Status: Confirmed => In Progress

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

Title:
  installed libssl1.1:amd64 package post-installation script subprocess
  returned error exit status 10

Status in openssl package in Ubuntu:
  Fix Committed
Status in openssl source package in Bionic:
  In Progress
Status in openssl source package in Cosmic:
  In Progress
Status in openssl source package in Disco:
  In Progress
Status in openssl source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Systems that have in error removed debconf database fail to upgrade
  libssl1.1 (as e.g. is known to be done in some vagrant boxes)

   * libssl1.1 tries to use debconf template from libc6 package, but
  doesn't ship one by itself as it should for shared templates. As it is
  not guaranteed that template will be available.

  [TestCase]

  # DO NOT DO THIS ON PRODUCTION MACHINES #
  # echo PURGE | debconf-communicate libpam0g:amd64
  0
  # echo PURGE | debconf-communicate libpam0g
  0
  # echo PURGE | debconf-communicate libc6:amd64
  0
  # echo PURGE | debconf-communicate libc6
  0

  Then upgrade from bionic-release to the -proposed package and it
  should work.

  It should not fail with exit code 10.

  [Regression Potential]

   * A new template is added, an identical import from glibc without any
  further changes. This registers the template in debconf, for this
  package, preventing the above describe error. This has no codechanges,
  only metadata.

  [Other Info]
   
   * Original bug report 

  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)

  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate

[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10

** Also affects: openssl (Ubuntu Eoan)
   Importance: Undecided
   Status: Confirmed

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

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

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

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

Title:
  installed libssl1.1:amd64 package post-installation script subprocess
  returned error exit status 10

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Cosmic:
  New
Status in openssl source package in Disco:
  New
Status in openssl source package in Eoan:
  Confirmed

Bug description:
  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)

  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64

  [ WORKAROUND TO RECOVER YOUR SYSTEM ]

  $ sudo dpkg-reconfigure libc6
  $ sudo dpkg --configure libssl1.1

  [ Reproducer steps ]

  # DO NOT DO THIS ON PRODUCTION MACHINES #

  # echo PURGE | debconf-communicate libpam0g:amd64
  0
  # echo PURGE | debconf-communicate libpam0g
  0
  # echo PURGE | debconf-communicate libc6:amd64
  0
  # echo PURGE | debconf-communicate libc6
  0
  # sh -x /var/lib/dpkg/info/libssl1.1\:amd64.postinst configure 1.1.1
  + . /usr/share/debconf/confmodule
  + [ !  ]
  + PERL_DL_NONLAZY=1
  + export PERL_DL_NONLAZY
  + [  ]
  + exec /usr/share/debconf/frontend 
/var/lib/dpkg/info/libssl1.1:amd64.postinst configure 1.1.1
  Checking for services that may need to be restarted...done.
  Checking for services that may need to be restarted...done.
  Checking init scripts...

  # echo $?
  10

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

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

[Touch-packages] [Bug 1833001] Re: openssl should register libraries/restart-without-asking template or handle gracefully when it is missing

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

@javier

I recommend instead:

dpkg-reconfigure libc6
dpkg --configure -a

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

Title:
  openssl should register libraries/restart-without-asking template or
  handle gracefully when it is missing

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  openssl should register libraries/restart-without-asking template or
  handle gracefully when it is missing

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

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

[Touch-packages] [Bug 1833001] Re: openssl should register libraries/restart-without-asking template or handle gracefully when it is missing

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

Because your solution, answers the template without showing it to the
user without the appropriate warning as to what the implications of
setting it to true are.

** This bug has been marked a duplicate of bug 1832919
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10

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

Title:
  openssl should register libraries/restart-without-asking template or
  handle gracefully when it is missing

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  openssl should register libraries/restart-without-asking template or
  handle gracefully when it is missing

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

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

[Touch-packages] [Bug 1833476] Re: libssl1.1 version 1.1.1-1ubuntu2.1~18.04.2 breaks nginx ssl tests

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

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

Title:
  libssl1.1 version 1.1.1-1ubuntu2.1~18.04.2 breaks nginx ssl tests

Status in nginx package in Ubuntu:
  New
Status in openssl package in Ubuntu:
  New

Bug description:
  Many nginx ssl tests pass with libssl1.1 version 1.1.0g-2ubuntu4.3 but
  fail when libssl1.1 is updated to version 1.1.1-1ubuntu2.1~18.04.2.

  Repro steps:
  1. Create control Dockerfile:
  ==
  FROM ubuntu:18.04

  RUN apt-get update -y && \
apt-get upgrade -y && \
apt-get install -y git nginx-core xdg-utils openssl=1.1.0g-2ubuntu4.3 
libnet-ssleay-perl=1.84-1build1 libio-socket-ssl-perl=2.056-1 
libssl1.1=1.1.0g-2ubuntu4.3

  RUN git clone https://github.com/nginx/nginx-tests.git
  WORKDIR /nginx-tests

  ENV TEST_NGINX_BINARY=/usr/sbin/nginx
  ENV TEST_NGINX_MODULES=/usr/lib/nginx/modules

  USER www-data

  ENTRYPOINT ["prove", "."]
  ==

  2. Run the command in a directory with only the Dockerfile:
  docker build -t nginx_image . && docker run --rm -it nginx_image

  3. See output:
  ==
  Test Summary Report
  ---
  ./grpc_request_buffering.t   (Wstat: 512 Tests: 14 Failed: 2)
Failed tests:  11-12
Non-zero exit status: 2
  ./h2_server_tokens.t (Wstat: 1536 Tests: 14 Failed: 6)
Failed tests:  1-2, 7-8, 10-11
Non-zero exit status: 6
  ./upstream_ip_hash_ipv6.t(Wstat: 512 Tests: 0 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
  Files=346, Tests=3782, 317 wallclock secs ( 1.87 usr  0.78 sys + 35.84 cusr 
16.99 csys = 55.48 CPU) 

  Result: FAIL
  ==

  4. Create new Dockerfile (only difference is updating libssl1.1):
  ==
  FROM ubuntu:18.04

  RUN apt-get update -y && \
apt-get upgrade -y && \
apt-get install -y git nginx-core xdg-utils openssl=1.1.0g-2ubuntu4.3 
libnet-ssleay-perl=1.84-1build1 libio-socket-ssl-perl=2.056-1 
libssl1.1=1.1.1-1ubuntu2.1~18.04.2

  RUN git clone https://github.com/nginx/nginx-tests.git
  WORKDIR /nginx-tests

  ENV TEST_NGINX_BINARY=/usr/sbin/nginx
  ENV TEST_NGINX_MODULES=/usr/lib/nginx/modules

  USER www-data

  ENTRYPOINT ["prove", "."]
  ==

  5. See output
  ==
  Test Summary Report
  ---
  ./grpc_request_buffering.t   (Wstat: 512 Tests: 14 Failed: 2)
Failed tests:  11-12
Non-zero exit status: 2
  ./h2_server_tokens.t (Wstat: 1536 Tests: 14 Failed: 6)
Failed tests:  1-2, 7-8, 10-11
Non-zero exit status: 6
  ./mail_ssl.t (Wstat: 768 Tests: 22 Failed: 3)
Failed tests:  3, 5-6
Non-zero exit status: 3
  ./proxy_ssl.t(Wstat: 512 Tests: 9 Failed: 2)
Failed tests:  4-5
Non-zero exit status: 2
  ./stream_proxy_ssl.t (Wstat: 512 Tests: 8 Failed: 2)
Failed tests:  4-5
Non-zero exit status: 2
  ./stream_ssl.t   (Wstat: 768 Tests: 9 Failed: 3)
Failed tests:  2, 4-5
Non-zero exit status: 3
  ./stream_upstream_zone_ssl.t (Wstat: 768 Tests: 11 Failed: 3)
Failed tests:  4-5, 9
Non-zero exit status: 3
  ./upstream_ip_hash_ipv6.t(Wstat: 512 Tests: 0 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
  ./upstream_zone_ssl.t(Wstat: 768 Tests: 11 Failed: 3)
Failed tests:  4-5, 9
Non-zero exit status: 3
  Files=346, Tests=3764, 317 wallclock secs ( 2.00 usr  0.73 sys + 36.49 cusr 
16.91 csys = 56.13 CPU)
  Result: FAIL
  ==

  New failures: mail_ssl.t, proxy_ssl.t, stream_proxy_ssl.t,
  stream_ssl.t, stream_upstream_zone_ssl.t, upstream_zone_ssl.t.

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

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

[Touch-packages] [Bug 1832651] Re: jackdbus fails to start: cannot allocate memory

** Also affects: systemd (Ubuntu Eoan)
   Importance: High
   Status: Confirmed

** Also affects: jackd2 (Ubuntu Eoan)
   Importance: Undecided
   Status: Invalid

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

Title:
  jackdbus fails to start: cannot allocate memory

Status in systemd:
  Fix Released
Status in jackd2 package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Confirmed
Status in jackd2 source package in Eoan:
  Invalid
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  The `.log/jack/jackdbus.log` shows the following after trying to
  start/restart jack using "Ubuntu Studio Controls" (also tried using
  `jack_control start`):

  ERROR: Cannot lock down 82280346 byte memory area (Cannot allocate
  memory)

  This is a fresh install of Ubuntu Studio 19.04, installed via USB. The
  first thing I did after installing was check to see if jack was
  running, but unfortunately it's not working. The error would seem to
  indicate that I'm not in the `audio` group, however checking `groups`
  shows that I am in the audio group.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: jackd2 1.9.12~dfsg-2build1
  ProcVersionSignature: Ubuntu 5.0.0-13.14-lowlatency 5.0.6
  Uname: Linux 5.0.0-13-lowlatency x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Wed Jun 12 18:13:25 2019
  InstallationDate: Installed on 2019-06-12 (0 days ago)
  InstallationMedia: Ubuntu-Studio 19.04 "Disco Dingo" - Release amd64 
(20190416)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: jackd2
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

Re: [Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS

2019-06-19 Thread Dimitri John Ledkov

On Wed, 19 Jun 2019, 16:30 Sascha Silbe,
 wrote:
>
> This update breaks salt-ssh 2016.11.2 (started from a different computer
> that's running Debian Stretch) on Ubuntu 18.04 (running on the machine
> being managed). Having Salt break from one day to the next for managing
> an LTS (!) release is a rather major PITA.

salt 2016 is an old obsolete version. Ubuntu 18.04 ships salt 2017.
this regression was already identified, and an update to address
compatibility with older software is being staged in bionic-proposed.

See for more details
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832659

>
> Curiously enough, salt-ssh 2016.11.2 continues to work just fine on
> minions running Ubuntu 19.04 which ships openssl 1.1.1b-1ubuntu2.1. So
> whatever this SRU does apparently is different from how it works on
> Ubuntu 19.04.
>

Have you tried openssl 1.1.1-1ubuntu2.1~18.04.3 from bionic proposed?

If that one helps, please leave a comment on
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832659 to help
us release the update sooner.

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

Title:
  [SRU] OpenSSL 1.1.1 to 18.04 LTS

Status in libwww-perl package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in libio-socket-ssl-perl source package in Bionic:
  Fix Released
Status in libnet-ssleay-perl source package in Bionic:
  Fix Released
Status in libwww-perl source package in Bionic:
  Fix Released
Status in openssl source package in Bionic:
  Fix Released
Status in python-cryptography source package in Bionic:
  Fix Released
Status in python-tornado source package in Bionic:
  Fix Committed
Status in python2.7 source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in r-cran-openssl source package in Bionic:
  Fix Released
Status in ruby-openssl source package in Bionic:
  Fix Released
Status in ruby2.5 source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * OpenSSL 1.1.1 is an LTS release upstream, which will continue to
  receive security support for much longer than 1.1.0 series will.

   * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
  be rapidly adopted due to increased set of supported hashes & algoes,
  as well as improved handshake [re-]negotiation.

   * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.

   * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
  software is sensitive to the negotiation handshake and may either need
  patches/improvements or clamp-down to maximum v1.2.

  [Test Case]

   * Rebuild all reverse dependencies

   * Execute autopkg tests for all of them

   * Clamp down to TLS v1.2 software that does not support TLS v1.3
  (e.g. mongodb)

   * Backport TLS v1.3 support patches, where applicable

  [Test cases for the python updates]

  python3.7 is a preview in bionic as a non-supported/non-default
  version of python3. Passing it's own autopkgtests is sufficient
  validation for python3.7. It includes a point release update, with
  OpenSSL 1.1.1 compat and features.

  python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
  also includes a point release update to 3.6.8. It has been part of the
  full-archive rebuild and regression analysis. Autopkgtests were
  triggered for python3.6 and python3-defaults with regressions already
  fixed in the individual packages as appropriate.

  python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
  compat only. It has been part of the full-archive rebuild and
  regression analysis. Autopkgtests were triggered for python2.7 and
  python-defaults with regressions already fixed in the individual
  packages as appropriate.

  The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 
and python point releases as seen in:

http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html

http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html

  And analyzed in

https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652

  [ Test case libwww-perl (and deps) regression ]

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

  1. apt install liblwp-protocol-https-perl
  2. enable -proposed
  3. apt install libio-socket-ssl-perl libnet-ssleay-perl
  4. perl -MLWP::UserAgent -e 
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'

  [Regression Potential]

   * Connectivity interop is the biggest issues which will be
  unavoidable with introducing TLS v1.3. However, tests on cosmic
  demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
  negotiate TLS v1.3 without issues.

   * Mitigation of

[Touch-packages] [Bug 1832659] Re: openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

2019-06-19 Thread Dimitri John Ledkov

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

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

Title:
  openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

Status in OpenSSL:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  Fix Committed
Status in openssl source package in Cosmic:
  Fix Committed
Status in openssl source package in Disco:
  Fix Released
Status in openssl source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Regression was introduced in OpenSSL 1.1.1 and fixed in 1.1.1b that 
prevents initialising libcrypto/libssl multiple times, and/or with different 
options.
   * This breaks existing applications that correctly use init API, ie. 
initialise libcrypto before/separately from libssl and/or with different 
options.

  [Test Case]

   * wget
  
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270802/+files/test_multiple_libssl_libcrypto_init.py

   * python3 ./test_multiple_libssl_libcrypto_init.py

  test_multiple_init (__main__.TestMultipleInit) ... ok

  --
  Ran 1 test in 0.014s

  OK

  [Regression Potential]

   * This is a cherrypick from upstream, and is backwards compatible
  with existing code. Simply init succeeds under more conditions now,
  than it did previously in 1.1.1. Also with this fix, OpenSSL is back
  to how things used to work with 1.1.0 and prior releases.

  [Original Bug report]

  After the update of openssl in bionic, I started having an issue and
  after troubleshooting found this issue:

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

  Applying the patch linked in that issue and rebuilding the openssl
  package avoided the issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Thu Jun 13 00:21:16 2019
  InstallationDate: Installed on 2019-06-12 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1833265] [NEW] laptop reported that there is a problem

2019-06-18 Thread john davey

Public bug reported:

computer takes ages to start.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 4.15.0-52.56-generic 4.15.18
Uname: Linux 4.15.0-52-generic i686
.tmp.unity_support_test.0:
 
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: i386
CompositorRunning: None
Date: Tue Jun 18 15:37:29 2019
DistUpgraded: 2018-10-26 13:01:13,910 DEBUG icon theme changed, re-reading
DistroCodename: bionic
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) 
[8086:2a02] (rev 03) (prog-if 00 [VGA controller])
   Subsystem: Toshiba America Info Systems Mobile GM965/GL960 Integrated 
Graphics Controller (primary) [1179:ff64]
   Subsystem: Toshiba America Info Systems Mobile GM965/GL960 Integrated 
Graphics Controller (secondary) [1179:ff64]
InstallationDate: Installed on 2016-03-15 (1190 days ago)
InstallationMedia: Ubuntu 14.04.4 LTS "Trusty Tahr" - Release i386 (20160217.1)
MachineType: TOSHIBA Satellite L300
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-52-generic 
root=UUID=f510ae88-8078-4876-a589-6f3bbdcc970d ro quiet splash
SourcePackage: xorg
UpgradeStatus: Upgraded to bionic on 2018-10-26 (235 days ago)
dmi.bios.date: 05/28/2008
dmi.bios.vendor: INSYDE
dmi.bios.version: 1.40
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: Base Board Product Name
dmi.board.vendor: Intel Corp.
dmi.board.version: Base Board Version
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: Chassis Manufacturer
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnINSYDE:bvr1.40:bd05/28/2008:svnTOSHIBA:pnSatelliteL300:pvrPSLB0E-02H00SEN:rvnIntelCorp.:rnBaseBoardProductName:rvrBaseBoardVersion:cvnChassisManufacturer:ct1:cvrChassisVersion:
dmi.product.family: Type1Family
dmi.product.name: Satellite L300
dmi.product.version: PSLB0E-02H00SEN
dmi.sys.vendor: TOSHIBA
version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
version.libdrm2: libdrm2 2.4.95-1~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.04.2
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
xserver.bootTime: Fri Oct 26 09:59:10 2018
xserver.configfile: default
xserver.errors:
 /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
 /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id   14145 
 vendor SEC
xserver.version: 2:1.18.4-0ubuntu0.8

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


** Tags: apport-bug bionic i386 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/1833265

Title:
  laptop reported that there is a problem

Status in xorg package in Ubuntu:
  New

Bug description:
  computer takes ages to start.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-52.56-generic 4.15.18
  Uname: Linux 4.15.0-52-generic i686
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: i386
  CompositorRunning: None
  Date: Tue Jun 18 15:37:29 2019
  DistUpgraded: 2018-10-26 13:01:13,910 DEBUG icon theme changed, re-reading
  DistroCodename: bionic
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller 
(primary) [8086:2a02] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Toshiba America Info Systems Mobile GM965/GL960 Integrated 
Graphics Controller (primary) [1179:ff64]
 Subsystem: Toshiba America Info Systems Mobile GM965/GL960 Integrated 
Graphics Controller (secondary) [1179:ff64]
  InstallationDate: Installed on 2016-03-15 (1190 days ago)
  InstallationMedia: Ubuntu 14.04.4 LTS "Trusty Tahr" - Release i386 
(20160217.1)
  MachineType: TOSHIBA Satellite L300
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-52-generic 
root=UUID=f510ae88-8078-4876-a589-6f3bbdcc970d ro quiet splash
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2018-10-26 (235 days ago)
  dmi.bios.date: 05/28/2008
  dmi.bios.vendor: INSYDE
  dmi.bios.version: 1.40

[Touch-packages] [Bug 1833227] [NEW] apparmor denied connecting to spice console

2019-06-18 Thread Dimitri John Ledkov

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

Public bug reported:

Jun 18 13:12:01 ottawa audit[7163]: AVC apparmor="DENIED" 
operation="file_receive" profile="libvirt-2a671814-742d-4afc-867d-eae2349b336b" 
pid=7163 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 
requested_mask="send receive" denied_mask="send receive" addr=none 
peer_addr=none peer="libvirtd"
Jun 18 13:12:01 ottawa kernel: audit: type=1400 audit(1560859921.530:160): 
apparmor="DENIED" operation="file_receive" 
profile="libvirt-2a671814-742d-4afc-867d-eae2349b336b" pid=7163 
comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 
requested_mask="send receive" denied_mask="send receive" addr=none 
peer_addr=none peer="libvirtd"
Jun 18 13:12:01 ottawa libvirtd[2168]: internal error: unable to execute QEMU 
command 'getfd': No file descriptor supplied via SCM_RIGHTS
Jun 18 13:12:01 ottawa libvirtd[2168]: operation failed: Active console session 
exists for this domain
Jun 18 13:13:14 ottawa sudo[7402]: xnox : TTY=pts/3 ; 
PWD=/var/log/libvirt/qemu ; USER=root ; COMMAND=/usr/bin/less ubuntucore.log
Jun 18 13:13:44 ottawa libvirtd[2168]: operation failed: Active console session 
exists for this domain


This is in eoan.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: libvirt-daemon 5.4.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-16.17-generic 5.0.8
Uname: Linux 5.0.0-16-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu3
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jun 18 13:17:07 2019
InstallationDate: Installed on 2016-01-26 (1239 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 
(20160125)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libvirt
UpgradeStatus: Upgraded to eoan on 2019-01-15 (153 days ago)
modified.conffile..etc.libvirt.nwfilter.allow-arp.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-arp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp-server.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp-server.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-incoming-ipv4.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-incoming-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.allow-ipv4.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.clean-traffic-gateway.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic-gateway.xml']
modified.conffile..etc.libvirt.nwfilter.clean-traffic.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/clean-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-ip-spoofing.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-mac-spoofing.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-spoofing.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-multicast.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-ip-multicast.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-spoofing.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-broadcast.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-mac-broadcast.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-spoofing.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-l2-traffic.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-other-l2-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-rarp-traffic.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-other-rarp-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self-rarp.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/qemu-announce-self.xml']
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission 
denied: '/etc/libvirt/qemu.conf']
modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: [Errno 
13] Permission denied:

[Touch-packages] [Bug 1833001] [NEW] openssl should register libraries/restart-without-asking template or handle gracefully when it is missing

2019-06-16 Thread Dimitri John Ledkov

Public bug reported:

openssl should register libraries/restart-without-asking template or
handle gracefully when it is missing

** Affects: openssl (Ubuntu)
 Importance: Undecided
 Assignee: Dimitri John Ledkov (xnox)
 Status: New

** Changed in: openssl (Ubuntu)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

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

Title:
  openssl should register libraries/restart-without-asking template or
  handle gracefully when it is missing

Status in openssl package in Ubuntu:
  New

Bug description:
  openssl should register libraries/restart-without-asking template or
  handle gracefully when it is missing

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

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

[Touch-packages] [Bug 1832933] Re: upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

** Description changed:

  Hello!
  
  After upgrade to
  
  libssl1.1 1.1.1-1ubuntu2.1~18.04.2
  openssl 1.1.1-1ubuntu2.1~18.04.2
  
  on Ubuntu 18.04 server clients can't connect to ejabberd server:
  
  2019-06-15 15:56:26.431 [warning]
  <0.858.0>@ejabberd_c2s:process_terminated:290 (tls|<0.858.0>) Failed to
  secure c2s connection: TLS failed: client renegotiations forbidden
  
- 
  ejabberd   version is18.01-2
  
  which is from Ubuntu 18.04.
  
- As far as I know ejabberd can work with openssl 1.1.1 only from 18.09 
+ As far as I know ejabberd can work with openssl 1.1.1 only from 18.09
  https://blog.process-one.net/ejabberd-18-09/
  
  OpenSSL 1.1.1 support
  
  Either ejabberd in 18.04 should be updated or openssl should not be
  upgraded to 1.1.1 on 18.04 .
  
  Thank you!
+ 
+ 
+ == erlang-p1-tls ==
+ 
+ Looking at all upstream patches since 1.0.20 (current bionic) these are
+ the useful ones:
+ 
+ 0002-Specify-accepted-Client-CAs-during-handshake.patch
+ - quite small fixes Client CA negotiation
+ 
+ 0013-Update-cert-used-by-test-to-use-sha256-signature.patch
+ - updates test cert to a stronger one
+ 
+ 0014-Add-no_tlsv1_3-option-parsing-from-openssl1.1.patch
+ - tiny, andd "no_tlsv1_3" option
+ 
+ 0016-Improve-tests-to-make-them-work-with-openssl1.1.patch
+ - testsuite fixes
+ 
+ 0022-Use-SSL_OP_NO_RENEGOTIATION-when-available.patch
+ - needed to fix this bug, do not attempt renegotiation as that is no longer 
supported. Just ifdefs.
+ 
+ 
+ There are also patches that add new apis, to rebuild cert caches, and query 
negotiated protocols, but meh.

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

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

** Also affects: erlang-p1-tls (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: erlang-p1-tls (Ubuntu)
   Status: Confirmed => Fix Released

** No longer affects: openssl (Ubuntu Bionic)

** No longer affects: openssl (Ubuntu)

** No longer affects: ejabberd (Ubuntu Bionic)

** No longer affects: ejabberd (Ubuntu)

** Changed in: erlang-p1-tls (Ubuntu Bionic)
   Status: New => Confirmed

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

Title:
  upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

Status in erlang-p1-tls package in Ubuntu:
  Fix Released
Status in erlang-p1-tls source package in Bionic:
  Confirmed

Bug description:
  Hello!

  After upgrade to

  libssl1.1 1.1.1-1ubuntu2.1~18.04.2
  openssl 1.1.1-1ubuntu2.1~18.04.2

  on Ubuntu 18.04 server clients can't connect to ejabberd server:

  2019-06-15 15:56:26.431 [warning]
  <0.858.0>@ejabberd_c2s:process_terminated:290 (tls|<0.858.0>) Failed
  to secure c2s connection: TLS failed: client renegotiations forbidden

  ejabberd   version is18.01-2

  which is from Ubuntu 18.04.

  As far as I know ejabberd can work with openssl 1.1.1 only from 18.09
  https://blog.process-one.net/ejabberd-18-09/

  OpenSSL 1.1.1 support

  Either ejabberd in 18.04 should be updated or openssl should not be
  upgraded to 1.1.1 on 18.04 .

  Thank you!

  
  == erlang-p1-tls ==

  Looking at all upstream patches since 1.0.20 (current bionic) these
  are the useful ones:

  0002-Specify-accepted-Client-CAs-during-handshake.patch
  - quite small fixes Client CA negotiation

  0013-Update-cert-used-by-test-to-use-sha256-signature.patch
  - updates test cert to a stronger one

  0014-Add-no_tlsv1_3-option-parsing-from-openssl1.1.patch
  - tiny, andd "no_tlsv1_3" option

  0016-Improve-tests-to-make-them-work-with-openssl1.1.patch
  - testsuite fixes

  0022-Use-SSL_OP_NO_RENEGOTIATION-when-available.patch
  - needed to fix this bug, do not attempt renegotiation as that is no longer 
supported. Just ifdefs.

  
  There are also patches that add new apis, to rebuild cert caches, and query 
negotiated protocols, but meh.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/erlang-p1-tls/+bug/1832933/+subscriptions

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

[Touch-packages] [Bug 1832933] Re: upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

** Also affects: erlang-p1-tls (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: erlang-p1-tls (Ubuntu)
   Status: New => Confirmed

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

Title:
  upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

Status in ejabberd package in Ubuntu:
  New
Status in erlang-p1-tls package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  New

Bug description:
  Hello!

  After upgrade to

  libssl1.1 1.1.1-1ubuntu2.1~18.04.2
  openssl 1.1.1-1ubuntu2.1~18.04.2

  on Ubuntu 18.04 server clients can't connect to ejabberd server:

  2019-06-15 15:56:26.431 [warning]
  <0.858.0>@ejabberd_c2s:process_terminated:290 (tls|<0.858.0>) Failed
  to secure c2s connection: TLS failed: client renegotiations forbidden

  ejabberd   version is18.01-2

  which is from Ubuntu 18.04.

  As far as I know ejabberd can work with openssl 1.1.1 only from 18.09
  https://blog.process-one.net/ejabberd-18-09/

  OpenSSL 1.1.1 support

  Either ejabberd in 18.04 should be updated or openssl should not be
  upgraded to 1.1.1 on 18.04 .

  Thank you!

  
  == erlang-p1-tls ==

  Looking at all upstream patches since 1.0.20 (current bionic) these
  are the useful ones:

  0002-Specify-accepted-Client-CAs-during-handshake.patch
  - quite small fixes Client CA negotiation

  0013-Update-cert-used-by-test-to-use-sha256-signature.patch
  - updates test cert to a stronger one

  0014-Add-no_tlsv1_3-option-parsing-from-openssl1.1.patch
  - tiny, andd "no_tlsv1_3" option

  0016-Improve-tests-to-make-them-work-with-openssl1.1.patch
  - testsuite fixes

  0022-Use-SSL_OP_NO_RENEGOTIATION-when-available.patch
  - needed to fix this bug, do not attempt renegotiation as that is no longer 
supported. Just ifdefs.

  
  There are also patches that add new apis, to rebuild cert caches, and query 
negotiated protocols, but meh.

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

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

[Touch-packages] [Bug 1832933] Re: upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

I wonder if
https://github.com/processone/fast_tls/commit/9b25543cf1200e3b216996598771962461ea51c8
is enough to fix connectivity.

Things to test:
- ejabberd server works and accepts various clients
- ejabberd clinet works and connects to various servers

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

Title:
  upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

Status in ejabberd package in Ubuntu:
  New
Status in openssl package in Ubuntu:
  New

Bug description:
  Hello!

  After upgrade to

  libssl1.1 1.1.1-1ubuntu2.1~18.04.2
  openssl 1.1.1-1ubuntu2.1~18.04.2

  on Ubuntu 18.04 server clients can't connect to ejabberd server:

  2019-06-15 15:56:26.431 [warning]
  <0.858.0>@ejabberd_c2s:process_terminated:290 (tls|<0.858.0>) Failed
  to secure c2s connection: TLS failed: client renegotiations forbidden

  
  ejabberd   version is18.01-2

  which is from Ubuntu 18.04.

  As far as I know ejabberd can work with openssl 1.1.1 only from 18.09 
  https://blog.process-one.net/ejabberd-18-09/

  OpenSSL 1.1.1 support

  Either ejabberd in 18.04 should be updated or openssl should not be
  upgraded to 1.1.1 on 18.04 .

  Thank you!

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

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

[Touch-packages] [Bug 1832933] Re: upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

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

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

Title:
  upgrade to libssl1.1 1.1.1-1ubuntu2.1~18.04.2 breaks ejabbrd

Status in ejabberd package in Ubuntu:
  New
Status in openssl package in Ubuntu:
  New

Bug description:
  Hello!

  After upgrade to

  libssl1.1 1.1.1-1ubuntu2.1~18.04.2
  openssl 1.1.1-1ubuntu2.1~18.04.2

  on Ubuntu 18.04 server clients can't connect to ejabberd server:

  2019-06-15 15:56:26.431 [warning]
  <0.858.0>@ejabberd_c2s:process_terminated:290 (tls|<0.858.0>) Failed
  to secure c2s connection: TLS failed: client renegotiations forbidden

  
  ejabberd   version is18.01-2

  which is from Ubuntu 18.04.

  As far as I know ejabberd can work with openssl 1.1.1 only from 18.09 
  https://blog.process-one.net/ejabberd-18-09/

  OpenSSL 1.1.1 support

  Either ejabberd in 18.04 should be updated or openssl should not be
  upgraded to 1.1.1 on 18.04 .

  Thank you!

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

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

[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10

** Description changed:

  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)
  
  dpkg: error processing package libssl1.1:amd64 (--configure):
-  installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
+  installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
-  libssl1.1:amd64
+  libssl1.1:amd64
  
  The attempted fix
  Line #153 of file /var/lib/dpkg/info/libssl1.1\:amd64.postinst
  - db_get libraries/restart-without-asking
  + db_get libraries/restart-without-asking || true
+ 
+ 
+ [ Reproducer steps ]
+ 
+ # DO NOT DO THIS ON PRODUCTION MACHINES #
+ 
+ # echo PURGE | debconf-communicate libpam0g:amd64
+ 0
+ # echo PURGE | debconf-communicate libpam0g
+ 0
+ # echo PURGE | debconf-communicate libc6:amd64
+ 0
+ # echo PURGE | debconf-communicate libc6
+ 0
+ # sh -x /var/lib/dpkg/info/libssl1.1\:amd64.postinst configure 1.1.1
+ + . /usr/share/debconf/confmodule
+ + [ !  ]
+ + PERL_DL_NONLAZY=1
+ + export PERL_DL_NONLAZY
+ + [  ]
+ + exec /usr/share/debconf/frontend 
/var/lib/dpkg/info/libssl1.1:amd64.postinst configure 1.1.1
+ Checking for services that may need to be restarted...done.
+ Checking for services that may need to be restarted...done.
+ Checking init scripts...
+ 
+ # echo $?
+ 10

** Description changed:

  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)
  
  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64
  
  The attempted fix
  Line #153 of file /var/lib/dpkg/info/libssl1.1\:amd64.postinst
  - db_get libraries/restart-without-asking
  + db_get libraries/restart-without-asking || true
  
+ [ WORKAROUND TO RECOVER YOUR SYSTEM ]
+ 
+ $ sudo dpkg-reconfigure libc6
+ $ sudo dpkg --configure libssl1.1
  
  [ Reproducer steps ]
  
  # DO NOT DO THIS ON PRODUCTION MACHINES #
  
  # echo PURGE | debconf-communicate libpam0g:amd64
  0
  # echo PURGE | debconf-communicate libpam0g
  0
  # echo PURGE | debconf-communicate libc6:amd64
  0
  # echo PURGE | debconf-communicate libc6
  0
  # sh -x /var/lib/dpkg/info/libssl1.1\:amd64.postinst configure 1.1.1
  + . /usr/share/debconf/confmodule
  + [ !  ]
  + PERL_DL_NONLAZY=1
  + export PERL_DL_NONLAZY
  + [  ]
  + exec /usr/share/debconf/frontend 
/var/lib/dpkg/info/libssl1.1:amd64.postinst configure 1.1.1
  Checking for services that may need to be restarted...done.
  Checking for services that may need to be restarted...done.
  Checking init scripts...
  
  # echo $?
  10

** Description changed:

  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)
  
  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64
- 
- The attempted fix
- Line #153 of file /var/lib/dpkg/info/libssl1.1\:amd64.postinst
- - db_get libraries/restart-without-asking
- + db_get libraries/restart-without-asking || true
  
  [ WORKAROUND TO RECOVER YOUR SYSTEM ]
  
  $ sudo dpkg-reconfigure libc6
  $ sudo dpkg --configure libssl1.1
  
  [ Reproducer steps ]
  
  # DO NOT DO THIS ON PRODUCTION MACHINES #
  
  # echo PURGE | debconf-communicate libpam0g:amd64
  0
  # echo PURGE | debconf-communicate libpam0g
  0
  # echo PURGE | debconf-communicate libc6:amd64
  0
  # echo PURGE | debconf-communicate libc6
  0
  # sh -x /var/lib/dpkg/info/libssl1.1\:amd64.postinst configure 1.1.1
  + . /usr/share/debconf/confmodule
  + [ !  ]
  + PERL_DL_NONLAZY=1
  + export PERL_DL_NONLAZY
  + [  ]
  + exec /usr/share/debconf/frontend 
/var/lib/dpkg/info/libssl1.1:amd64.postinst configure 1.1.1
  Checking for services that may need to be restarted...done.
  Checking for services that may need to be restarted...done.
  Checking init scripts...
  
  # echo $?
  10

-- 
You received this bug notification

[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10

if `db_get libraries/restart-without-asking` fails with exit code 10, it
means this templates is not in the debconf database.

However, libc6 should be installed and configured on the system, with
that template registered.

I wonder, if your debconf database is corrupted / destroyed? Does

$ dpkg-reconfigure libc6

help?

** Tags added: bionic

** Tags added: regression-update

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

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

Title:
  installed libssl1.1:amd64 package post-installation script subprocess
  returned error exit status 10

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)

  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64

  The attempted fix
  Line #153 of file /var/lib/dpkg/info/libssl1.1\:amd64.postinst
  - db_get libraries/restart-without-asking
  + db_get libraries/restart-without-asking || true

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

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

[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10

Can you please paste the output of below two commands:


debconf-get-selections | grep restart-without-asking

dpkg-query -W libc6

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

Title:
  installed libssl1.1:amd64 package post-installation script subprocess
  returned error exit status 10

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  The error happens when trying to configure libssl1.1:amd64 (dpkg
  --configure -D 2  libssl1.1)

  dpkg: error processing package libssl1.1:amd64 (--configure):
   installed libssl1.1:amd64 package post-installation script subprocess 
returned error exit status 10
  D02: post_script_tasks - ensure_diversions
  D02: post_script_tasks - trig_incorporate
  D02: check_triggers_cycle pnow=libc-bin:amd64 first
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  D02: post_postinst_tasks - trig_incorporate
  Errors were encountered while processing:
   libssl1.1:amd64

  The attempted fix
  Line #153 of file /var/lib/dpkg/info/libssl1.1\:amd64.postinst
  - db_get libraries/restart-without-asking
  + db_get libraries/restart-without-asking || true

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

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

[Touch-packages] [Bug 1832370] Re: Unable to configure or disable TLS 1.3 via openssl.cnf

** Changed in: openssl (Ubuntu Bionic)
   Status: Incomplete => Invalid

** Changed in: openssl (Ubuntu Cosmic)
   Status: Incomplete => Invalid

** Changed in: openssl (Ubuntu Disco)
   Status: Incomplete => Invalid

** Changed in: openssl (Ubuntu Eoan)
   Status: Incomplete => Invalid

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

Title:
  Unable to configure or disable TLS 1.3 via openssl.cnf

Status in openssl package in Ubuntu:
  Invalid
Status in openssl source package in Bionic:
  Invalid
Status in openssl source package in Cosmic:
  Invalid
Status in openssl source package in Disco:
  Invalid
Status in openssl source package in Eoan:
  Invalid

Bug description:
  [Description]

  Since OpenSSL 1.1.1 was backported to Bionic, some (all?) applications
  gained access to TLS 1.3 by default. The applications that were not
  rebuilt against OpenSSL 1.1.1 can't tune the TLS 1.3 settings
  (protocol, ciphersuites selection, ciphersuites order) like it's
  possible with 1.2 and below. As such, one should turn to configuring
  /etc/ssl/openssl.cnf to alter TLS 1.3 settings.

  Here is how I'd expect to be able to turn off TLS 1.3:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:15:23.805113804 -0400
  @@ -12,6 +12,16 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +MaxProtocol = TLSv1.2
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  This doesn't work as 'openssl s_client -connect
  rproxy.sdeziel.info:443' negotiates TLS 1.3 with
  TLS_AES_256_GCM_SHA384.

  
  Similarly, trying to change the 'Ciphers' or the 'Ciphersuites' list with:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:37:23.362889367 -0400
  @@ -12,6 +12,17 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +Ciphers = TLS_AES_128_GCM_SHA256
  +Ciphersuites = TLS_AES_128_GCM_SHA256
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  Doesn't work as s_client keeps negotiating TLS 1.3 with
  TLS_AES_256_GCM_SHA384 (!= 128)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jun 11 11:22:47 2019
  InstallationDate: Installed on 2018-07-15 (331 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   LANG=en_CA.UTF-8
   TERM=xterm-256color
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
   PATH=(custom, no user)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1382054] Re: Add support for configuring VLAN interfaces in the initrd

** Changed in: initramfs-tools (Ubuntu)
   Status: Confirmed => Fix Committed

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

Title:
  Add support for configuring VLAN interfaces in the initrd

Status in initramfs-tools package in Ubuntu:
  Fix Committed

Bug description:
  It would be helpful to be able to create VLAN network interfaces in initrd 
images provided
  by Ubuntu, based on kernel command line parameters. (i.e. VLAN=eth0.100, )

  Some use cases for this feature addition are MAAS users trying to boot 
machines
  using a specific VLAN interface.

  On a specific case we have 2 physical network interfaces, one is plugged into 
a specific VLAN interface,
  Since we can specify the network interface on BIOS, the initial PXE boot 
occurs, but
  then the installation fails when using the fast-path installer because the 
specific VLAN is not configured on the ram disk.

  While we can use the other network interface because is a trunk interface 
that allows us to use
  several VLANs, this is not supported on all the network architectures and 
some security limitations doesn't allows this method.

  Reference Redhat implementation can be found here:

  - http://marc.info/?l=initramfs=133767307516594

  Reference Suse implementation can be found here:

  - https://gitorious.org/opensuse/agrafs-
  mkinitrd/commit/6124f87f3132b6369c0335c319832619a49d0bf7

  The command line syntax for this could be something like, similar to
  Redhat implementation

  vlan=:

  For an example:

  vlan=eth0.2:eth0

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

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

[Touch-packages] [Bug 1832659] Re: openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

** Attachment removed: "test_multiple_libssl_libcrypto_init.py"
   
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270782/+files/test_multiple_libssl_libcrypto_init.py

** Attachment added: "test_multiple_libssl_libcrypto_init.py"
   
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270802/+files/test_multiple_libssl_libcrypto_init.py

** Description changed:

  [Impact]
  
-  * Regression was introduced in OpenSSL 1.1.1 and fixed in 1.1.1b that 
prevents initialising libcrypto/libssl multiple times, and/or with different 
options.
-  * This breaks existing applications that correctly use init API, ie. 
initialise libcrypto before/separately from libssl and/or with different 
options.
+  * Regression was introduced in OpenSSL 1.1.1 and fixed in 1.1.1b that 
prevents initialising libcrypto/libssl multiple times, and/or with different 
options.
+  * This breaks existing applications that correctly use init API, ie. 
initialise libcrypto before/separately from libssl and/or with different 
options.
  
  [Test Case]
  
-  * wget
- 
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270782/+files/test_multiple_libssl_libcrypto_init.py
+  * wget
+ 
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270802/+files/test_multiple_libssl_libcrypto_init.py
  
-  * python3 ./test_multiple_libssl_libcrypto_init.py
+  * python3 ./test_multiple_libssl_libcrypto_init.py
  
  test_multiple_init (__main__.TestMultipleInit) ... ok
  
  --
  Ran 1 test in 0.014s
  
  OK
  
  [Regression Potential]
  
-  * This is a cherrypick from upstream, and is backwards compatible with
+  * This is a cherrypick from upstream, and is backwards compatible with
  existing code. Simply init succeeds under more conditions now, than it
  did previously in 1.1.1. Also with this fix, OpenSSL is back to how
  things used to work with 1.1.0 and prior releases.
  
  [Original Bug report]
  
  After the update of openssl in bionic, I started having an issue and
  after troubleshooting found this issue:
  
  https://github.com/openssl/openssl/issues/7350
  
  Applying the patch linked in that issue and rebuilding the openssl
  package avoided the issue.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Thu Jun 13 00:21:16 2019
  InstallationDate: Installed on 2019-06-12 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

Status in OpenSSL:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New
Status in openssl source package in Cosmic:
  New
Status in openssl source package in Disco:
  Fix Released
Status in openssl source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Regression was introduced in OpenSSL 1.1.1 and fixed in 1.1.1b that 
prevents initialising libcrypto/libssl multiple times, and/or with different 
options.
   * This breaks existing applications that correctly use init API, ie. 
initialise libcrypto before/separately from libssl and/or with different 
options.

  [Test Case]

   * wget
  
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270802/+files/test_multiple_libssl_libcrypto_init.py

   * python3 ./test_multiple_libssl_libcrypto_init.py

  test_multiple_init (__main__.TestMultipleInit) ... ok

  --
  Ran 1 test in 0.014s

  OK

  [Regression Potential]

   * This is a cherrypick from upstream, and is backwards compatible
  with existing code. Simply init succeeds under more conditions now,
  than it did previously in 1.1.1. Also with this fix, OpenSSL is back
  to how things used to work with 1.1.0 and prior releases.

  [Original Bug report]

  After the update of openssl in bionic, I started having an issue and
  after troubleshooting found this issue:

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

  Applying the patch linked in that issue and rebuilding the openssl
  package avoided the issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname:

[Touch-packages] [Bug 1832659] Re: openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

** Description changed:

+ [Impact]
+ 
+  * Regression was introduced in OpenSSL 1.1.1 and fixed in 1.1.1b that 
prevents initialising libcrypto/libssl multiple times, and/or with different 
options.
+  * This breaks existing applications that correctly use init API, ie. 
initialise libcrypto before/separately from libssl and/or with different 
options.
+ 
+ [Test Case]
+ 
+  * wget
+ 
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270782/+files/test_multiple_libssl_libcrypto_init.py
+ 
+  * python3 ./test_multiple_libssl_libcrypto_init.py
+ 
+ test_multiple_init (__main__.TestMultipleInit) ... ok
+ 
+ --
+ Ran 1 test in 0.014s
+ 
+ OK
+ 
+ [Regression Potential]
+ 
+  * This is a cherrypick from upstream, and is backwards compatible with
+ existing code. Simply init succeeds under more conditions now, than it
+ did previously in 1.1.1. Also with this fix, OpenSSL is back to how
+ things used to work with 1.1.0 and prior releases.
+ 
+ [Original Bug report]
+ 
  After the update of openssl in bionic, I started having an issue and
  after troubleshooting found this issue:
  
  https://github.com/openssl/openssl/issues/7350
  
  Applying the patch linked in that issue and rebuilding the openssl
  package avoided the issue.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Thu Jun 13 00:21:16 2019
  InstallationDate: Installed on 2019-06-12 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

Status in OpenSSL:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New
Status in openssl source package in Cosmic:
  New
Status in openssl source package in Disco:
  Fix Released
Status in openssl source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Regression was introduced in OpenSSL 1.1.1 and fixed in 1.1.1b that 
prevents initialising libcrypto/libssl multiple times, and/or with different 
options.
   * This breaks existing applications that correctly use init API, ie. 
initialise libcrypto before/separately from libssl and/or with different 
options.

  [Test Case]

   * wget
  
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270782/+files/test_multiple_libssl_libcrypto_init.py

   * python3 ./test_multiple_libssl_libcrypto_init.py

  test_multiple_init (__main__.TestMultipleInit) ... ok

  --
  Ran 1 test in 0.014s

  OK

  [Regression Potential]

   * This is a cherrypick from upstream, and is backwards compatible
  with existing code. Simply init succeeds under more conditions now,
  than it did previously in 1.1.1. Also with this fix, OpenSSL is back
  to how things used to work with 1.1.0 and prior releases.

  [Original Bug report]

  After the update of openssl in bionic, I started having an issue and
  after troubleshooting found this issue:

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

  Applying the patch linked in that issue and rebuilding the openssl
  package avoided the issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Thu Jun 13 00:21:16 2019
  InstallationDate: Installed on 2019-06-12 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1832659] Re: openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

** Attachment added: "test_multiple_libssl_libcrypto_init.py"
   
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270782/+files/test_multiple_libssl_libcrypto_init.py

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

Title:
  openssl 1.1.1-1ubuntu2.1~18.04.1 contains upstream bug 7350

Status in OpenSSL:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New
Status in openssl source package in Cosmic:
  New
Status in openssl source package in Disco:
  Fix Released
Status in openssl source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Regression was introduced in OpenSSL 1.1.1 and fixed in 1.1.1b that 
prevents initialising libcrypto/libssl multiple times, and/or with different 
options.
   * This breaks existing applications that correctly use init API, ie. 
initialise libcrypto before/separately from libssl and/or with different 
options.

  [Test Case]

   * wget
  
https://bugs.launchpad.net/ubuntu/cosmic/+source/openssl/+bug/1832659/+attachment/5270782/+files/test_multiple_libssl_libcrypto_init.py

   * python3 ./test_multiple_libssl_libcrypto_init.py

  test_multiple_init (__main__.TestMultipleInit) ... ok

  --
  Ran 1 test in 0.014s

  OK

  [Regression Potential]

   * This is a cherrypick from upstream, and is backwards compatible
  with existing code. Simply init succeeds under more conditions now,
  than it did previously in 1.1.1. Also with this fix, OpenSSL is back
  to how things used to work with 1.1.0 and prior releases.

  [Original Bug report]

  After the update of openssl in bionic, I started having an issue and
  after troubleshooting found this issue:

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

  Applying the patch linked in that issue and rebuilding the openssl
  package avoided the issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Thu Jun 13 00:21:16 2019
  InstallationDate: Installed on 2019-06-12 (0 days ago)
  InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1832421] Re: openssl reboot needed message using incorrect path to X server

** Description changed:

  [Impact]
  
-  * On desktop, upgrading libssl1.1 does not show reboot required
+  * On desktop, upgrading libssl1.1 does not show reboot required
  notification
  
  [Test Case]
  
-  * Boot ubuntu desktop
-  * Upgrade libssl1.1
-  * Observe reboot notification pop-up from update-notifier
+  * Boot ubuntu desktop
+  * Upgrade libssl1.1
+  * Observe reboot notification pop-up from update-notifier is _not_ shown
  
  [Regression Potential]
  
-  * Tweaking postinst only to correct for the Xorg path. Current code is
+  * Tweaking postinst only to correct for the Xorg path. Current code is
  innert, but is well excercised in prior releases.
  
  [Other Info]
-  
-  * Original bug report:
+ 
+  * Original bug report:
  
  Hello, the openssl library postinst file is using pidof /usr/bin/X, but
  that doesn't appear to be the path to the X11 server any more:
  
  debian/libssl1.1.postinst:
  
  # Only issue the reboot notification for servers; we proxy this by
  # testing that the X server is not running (LP: #244250)
  if ! pidof /usr/bin/X > /dev/null && [ -x 
/usr/share/update-notifier/notify-reboot-required ]; then
  /usr/share/update-notifier/notify-reboot-required
  fi
  
  On my 18.04 LTS laptop:
  
  $ ps auxw | grep Xorg
  root  2440  0.5  0.4 495932 78996 tty7 Rsl+ May10 264:45 
/usr/lib/xorg/Xorg :0 vt7 -nolisten tcp -auth /var/l
  
  Thanks
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
  Uname: Linux 4.15.0-50-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Tue Jun 11 18:06:51 2019
  InstallationDate: Installed on 2012-10-18 (2427 days ago)
  InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 
(20120823.1)
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: Upgraded to bionic on 2018-05-02 (406 days ago)

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

Title:
  openssl reboot needed message using incorrect path to X server

Status in openssl package in Ubuntu:
  Fix Committed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Cosmic:
  New
Status in openssl source package in Disco:
  New
Status in openssl source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * On desktop, upgrading libssl1.1 does not show reboot required
  notification

  [Test Case]

   * Boot ubuntu desktop
   * Upgrade libssl1.1
   * Observe reboot notification pop-up from update-notifier is _not_ shown

  [Regression Potential]

   * Tweaking postinst only to correct for the Xorg path. Current code
  is innert, but is well excercised in prior releases.

  [Other Info]

   * Original bug report:

  Hello, the openssl library postinst file is using pidof /usr/bin/X,
  but that doesn't appear to be the path to the X11 server any more:

  debian/libssl1.1.postinst:

  # Only issue the reboot notification for servers; we proxy this by
  # testing that the X server is not running (LP: #244250)
  if ! pidof /usr/bin/X > /dev/null && [ -x 
/usr/share/update-notifier/notify-reboot-required ]; then
  /usr/share/update-notifier/notify-reboot-required
  fi

  On my 18.04 LTS laptop:

  $ ps auxw | grep Xorg
  root  2440  0.5  0.4 495932 78996 tty7 Rsl+ May10 264:45 
/usr/lib/xorg/Xorg :0 vt7 -nolisten tcp -auth /var/l

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
  Uname: Linux 4.15.0-50-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Tue Jun 11 18:06:51 2019
  InstallationDate: Installed on 2012-10-18 (2427 days ago)
  InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 
(20120823.1)
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: Upgraded to bionic on 2018-05-02 (406 days ago)

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

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

[Touch-packages] [Bug 1832421] Re: openssl reboot needed message using incorrect path to X server

** Description changed:

+ [Impact]
+ 
+  * On desktop, upgrading libssl1.1 does not show reboot required
+ notification
+ 
+ [Test Case]
+ 
+  * Boot ubuntu desktop
+  * Upgrade libssl1.1
+  * Observe reboot notification pop-up from update-notifier
+ 
+ [Regression Potential]
+ 
+  * Tweaking postinst only to correct for the Xorg path. Current code is
+ innert, but is well excercised in prior releases.
+ 
+ [Other Info]
+  
+  * Original bug report:
+ 
  Hello, the openssl library postinst file is using pidof /usr/bin/X, but
  that doesn't appear to be the path to the X11 server any more:
  
  debian/libssl1.1.postinst:
  
- # Only issue the reboot notification for servers; we proxy this by
- # testing that the X server is not running (LP: #244250)
- if ! pidof /usr/bin/X > /dev/null && [ -x 
/usr/share/update-notifier/notify-reboot-required ]; then
- /usr/share/update-notifier/notify-reboot-required
- fi
- 
+ # Only issue the reboot notification for servers; we proxy this by
+ # testing that the X server is not running (LP: #244250)
+ if ! pidof /usr/bin/X > /dev/null && [ -x 
/usr/share/update-notifier/notify-reboot-required ]; then
+ /usr/share/update-notifier/notify-reboot-required
+ fi
  
  On my 18.04 LTS laptop:
  
  $ ps auxw | grep Xorg
  root  2440  0.5  0.4 495932 78996 tty7 Rsl+ May10 264:45 
/usr/lib/xorg/Xorg :0 vt7 -nolisten tcp -auth /var/l
  
  Thanks
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
  Uname: Linux 4.15.0-50-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Tue Jun 11 18:06:51 2019
  InstallationDate: Installed on 2012-10-18 (2427 days ago)
  InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 
(20120823.1)
  ProcEnviron:
-  TERM=rxvt-unicode-256color
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=rxvt-unicode-256color
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: Upgraded to bionic on 2018-05-02 (406 days ago)

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

Title:
  openssl reboot needed message using incorrect path to X server

Status in openssl package in Ubuntu:
  Fix Committed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Cosmic:
  New
Status in openssl source package in Disco:
  New
Status in openssl source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * On desktop, upgrading libssl1.1 does not show reboot required
  notification

  [Test Case]

   * Boot ubuntu desktop
   * Upgrade libssl1.1
   * Observe reboot notification pop-up from update-notifier

  [Regression Potential]

   * Tweaking postinst only to correct for the Xorg path. Current code
  is innert, but is well excercised in prior releases.

  [Other Info]
   
   * Original bug report:

  Hello, the openssl library postinst file is using pidof /usr/bin/X,
  but that doesn't appear to be the path to the X11 server any more:

  debian/libssl1.1.postinst:

  # Only issue the reboot notification for servers; we proxy this by
  # testing that the X server is not running (LP: #244250)
  if ! pidof /usr/bin/X > /dev/null && [ -x 
/usr/share/update-notifier/notify-reboot-required ]; then
  /usr/share/update-notifier/notify-reboot-required
  fi

  On my 18.04 LTS laptop:

  $ ps auxw | grep Xorg
  root  2440  0.5  0.4 495932 78996 tty7 Rsl+ May10 264:45 
/usr/lib/xorg/Xorg :0 vt7 -nolisten tcp -auth /var/l

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
  Uname: Linux 4.15.0-50-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Tue Jun 11 18:06:51 2019
  InstallationDate: Installed on 2012-10-18 (2427 days ago)
  InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 
(20120823.1)
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: Upgraded to bionic on 2018-05-02 (406 days ago)

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

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

[Touch-packages] [Bug 1832370] Re: Unable to configure or disable TLS 1.3 via openssl.cnf