[Touch-packages] [Bug 1820011] Re: package python3 3.6.7-1~18.04 failed to install/upgrade: installed python3 package post-installation script subprocess returned error exit status 4

2019-05-13 Thread Launchpad Bug Tracker
[Expired for python3-defaults (Ubuntu) because there has been no
activity for 60 days.]

** Changed in: python3-defaults (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  package python3 3.6.7-1~18.04 failed to install/upgrade: installed
  python3 package post-installation script subprocess returned error
  exit status 4

Status in python3-defaults package in Ubuntu:
  Expired

Bug description:
  I also get dpkg error and it does not get corrected I got error in
  that also . I am not able to install any library or app anything
  please correct it faster

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: python3 3.6.7-1~18.04
  ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
  Uname: Linux 4.15.0-36-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  AptOrdering: NULL: ConfigurePending
  Architecture: amd64
  Date: Thu Mar 14 12:21:33 2019
  DpkgHistoryLog:
   Start-Date: 2019-03-14  12:21:14
   Commandline: apt-get install build-essential
   Requested-By: pooja-gaikwad (1000)
  ErrorMessage: installed python3 package post-installation script subprocess 
returned error exit status 4
  InstallationDate: Installed on 2018-03-16 (362 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  Python3Details: /usr/bin/python3.6, Python 3.6.7, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 
2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.1
   apt  1.6.6ubuntu0.1
  SourcePackage: python3-defaults
  Title: package python3 3.6.7-1~18.04 failed to install/upgrade: installed 
python3 package post-installation script subprocess returned error exit status 4
  UpgradeStatus: Upgraded to bionic on 2018-08-02 (223 days ago)

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

-- 
Mailing list: https://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 1786574] Re: remove i2c-i801 from blacklist

2019-05-13 Thread Khairul Aizat Kamarudzzaman
Hi @Aaron & @Kai-Heng,
I've installed the package and reboot + tried suspend 1 time.

So far so good. Will let you know if this problem still occur in the future.
Thanks !
On May 10 2019, at 11:35 pm, Kai-Heng Feng  wrote:
> Khairul,
>
> Does the touchpad work after boot, and after suspend?
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1786574
>
> Title:
> remove i2c-i801 from blacklist
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/hwe-next/+bug/1786574/+subscriptions
>

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

Title:
  remove i2c-i801 from blacklist

Status in HWE Next:
  In Progress
Status in OEM Priority Project:
  New
Status in kmod package in Ubuntu:
  Fix Released
Status in kmod source package in Xenial:
  In Progress
Status in kmod source package in Bionic:
  In Progress
Status in kmod source package in Cosmic:
  In Progress

Bug description:
  SRU justification
  

  [Impact]
  Many modern notebooks need i2c-i801 kernel module to function, but it is 
blacklisted by /etc/modprobe/blacklist.conf, which gives a very poor user 
experience.

  [Test case]
  1. Install Ubuntu
  2. Check touchpad works or not
  3. Install the fixed kmod package
  4. Confirm touchpad works

  [Regression Potential]
  i2c-i801 was blacklisted due to bug 16602. The user complains an HP Compaq 
nc6000 notebook cannot suspend without blacklisting i2c-i801. While this is a 
way to workaround the suspend issue, the proper fix should be in linux kernel. 
Since nc6000 was a machine sold in 2004, it is too difficult to find someone to 
verify if it will regress due to this SRU. The rationale to blacklist it is: 
https://bugs.launchpad.net/ubuntu/+source/hotplug/+bug/16602/comments/5, 
however it is no longer valid nowadays on modern computers.

  Besides, there look like to be a quirk in linux kernel that fixes it:
  https://github.com/torvalds/linux/blame/master/drivers/pci/quirks.c#L1434

  [Other Info]
  rationale of i2c_i801 driver blacklist: 
https://answers.launchpad.net/ubuntu/+source/kmod/+question/269329

  
---
  Original bug report:

  We have a Lenovo Thinkpad machine that requires i2c-i801 kernel module
  to work, but it is listed in /etc/modprobe/blacklist.conf in Ubuntu.
  To use the touchpad, users have to remove the i2c-i801 line manually.

  i2c-i801 in blacklist.conf is a very old workaround to fix HP compaq nc6000
  (Bug #16602), this module should be removed from blacklist.

  There is also another bug (Bug #1475945) that needs this module for
  Acer trackpad to work.

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

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


[Touch-packages] [Bug 1828901] Re: add PTY support for runuser

2019-05-13 Thread Bug Watch Updater
** Changed in: util-linux (Debian)
   Status: Unknown => Fix Released

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

Title:
  add PTY support for runuser

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress
Status in util-linux package in Debian:
  Fix Released

Bug description:
  [IMPACT]

  [TEST CASE]

  [REGRESSION POTENTIAL]

  [OTHER INFORMATION]

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

  This is fixing a CVE vulnerability:
  https://security-tracker.debian.org/tracker/CVE-2016-2779

  Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
  http://www.openwall.com/lists/oss-security/2016/02/27/1
  https://marc.info/?l=util-linux-ng=145694736107128=2
  2.31 introduces a new --pty option to separate privileged and unprivileged
  shells (not enabled by default and the cli switch is necessary).

  [ORIGINAL DESCRIPTION]
  After a discussion with security team on what would be their recommended way 
to run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.

  The recommendation was to use 'runuser -P'

  runuser PTY support is present in Bionic and late, but not in Xenial.

  I'm opening this bug in the effort to update util-linux/runuser code
  in Xenial to add the PTY support.

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

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


[Touch-packages] [Bug 1614080] Re: PATH contains dot when PATH is unset before running bash

2019-05-13 Thread Bug Watch Updater
** Changed in: bash (Debian)
   Status: Unknown => New

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

Title:
  PATH contains dot when PATH is unset before running bash

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Precise:
  Fix Released
Status in bash source package in Trusty:
  Won't Fix
Status in bash source package in Xenial:
  Fix Committed
Status in bash source package in Bionic:
  Fix Committed
Status in bash source package in Cosmic:
  Fix Released
Status in bash source package in Disco:
  Fix Committed
Status in bash source package in Eoan:
  Fix Released
Status in bash package in Debian:
  New

Bug description:
  [Impact]

   * The fallback path built into bash contains '.' which leads to
  unexpected addition of the current working directory. It should not be
  there, just like it isnt' in pre-precise and cosmic+.

  [Test Case]

   * $ env -u PATH /bin/bash -c 'echo $PATH'

  Should not have '.' as any component. Nor should there be any empty
  components, i.e. '::'.

  [Regression Potential]

   * Normally PATH is always set by either init, systemd, or any other
  hypervisor. Thus this only affects executions under bash, when it was
  started without any environment - e.g. booting with 'init=/bin/bash'.

  [Other Info]
   
   * Original bug report.

  On ubuntu 16.04 (but also 14.04), running bash with PATH unset always
  adds '.' to PATH:

  philippe@pv-desktop:~$ echo $PATH
  
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  philippe@pv-desktop:~$ unset PATH
  philippe@pv-desktop:~$ /bin/bash
  philippe@pv-desktop:~$ echo $PATH
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

  Even when testing in a virtual machine / docker, and erasing
  /root/.profile /root/.bashrc /etc/profile /etc/bash.bashrc the problem
  still happens.

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

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


[Touch-packages] [Bug 1828215] Re: openssl ca -spkac output regressed

2019-05-13 Thread Mathew Hodson
** Tags added: regression-release

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

Title:
  openssl ca -spkac output regressed

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

Bug description:
  [Impact]

   * openssl command line utility option parsing has regressed in
  1.1.0i+ and produces binary output, where text output is expected,
  breaking applications that parse that.

  [Test Case]

   * OPENSSL_ENABLE_MD5_VERIFY=1 openssl ca -config test.openssl.cnf
  -passin stdin -batch -spkac input_file -startdate 190121130654Z

   Currently produces binary goop.

   Should produce PEM format Base64 encoded certificate data in a block 
surrounded
   with BEGIN/END certificate.

  [Regression Potential]

   * This is a regression in cosmic and up, and impeding regression in
  bionic with the upcoming 1.1.1 SRU. A bugfix exists upstream.

  [Other Info]
   
   * Originally reported 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/39

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

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


[Touch-packages] [Bug 1792004] Re: built-in PATH seems to have sbin and bin out of order; and inconsistent

2019-05-13 Thread Mathew Hodson
** Changed in: bash (Debian)
   Importance: Unknown => Undecided

** Changed in: bash (Debian)
 Remote watch: Debian Bug tracker #781367 => None

** Package changed: bash (Debian) => ubuntu-translations

** No longer affects: ubuntu-translations

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

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

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

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

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

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

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

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

** No longer affects: apt (Ubuntu Cosmic)

** No longer affects: busybox (Ubuntu Cosmic)

** No longer affects: dash (Ubuntu Cosmic)

** No longer affects: dpkg (Ubuntu Cosmic)

** No longer affects: pam (Ubuntu Cosmic)

** No longer affects: systemd (Ubuntu Cosmic)

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

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

Title:
  built-in PATH seems to have sbin and bin out of order; and
  inconsistent

Status in apt package in Ubuntu:
  Fix Released
Status in bash package in Ubuntu:
  Fix Released
Status in busybox package in Ubuntu:
  New
Status in dash package in Ubuntu:
  New
Status in dpkg package in Ubuntu:
  Won't Fix
Status in pam package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in bash source package in Xenial:
  Fix Committed
Status in bash source package in Bionic:
  Fix Committed
Status in bash source package in Cosmic:
  Fix Released
Status in bash source package in Disco:
  Fix Committed

Bug description:
  [Impact]

   * For consistency reasons sbin should be ordered before bin in PATH.

  [Test Case]

   * $ env -u PATH /bin/bash -c 'echo $PATH'

  And check that matching pairs in PATH, have /sbin variant leading /bin
  variant.

  [Regression Potential]

   * Ubuntu does not ship duplicate binries, with different behaviour
  between /sbin and /bin, thus all binaries will continue to be found in
  all locations. Also PATH is normally already set in the environment,
  and this change only affects the fallback path when bash is executed
  without any environment, i.e. booting with 'init=/bin/bash'

  [Other Info]
   
   * Original bug report detailing inconsistent paths between various shells.

  ---

  
  $ env -u PATH /bin/sh -c 'echo $PATH'
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  $ env -u PATH /bin/dash -c 'echo $PATH'
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  $ systemd-run --unit test-env env # ... and check journal for PATH
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  $ env -u PATH /bin/bash -c 'echo $PATH'
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

  $ env -u PATH /bin/busybox sh -c 'echo $PATH'
  /sbin:/usr/sbin:/bin:/usr/bin

  $ grep 'export PATH=' -r initramfs-tools-0.131ubuntu10/
  initramfs-tools-0.131ubuntu10/mkinitramfs:export PATH='/usr/bin:/sbin:/bin'
  initramfs-tools-0.131ubuntu10/init:export PATH=/sbin:/usr/sbin:/bin:/usr/bin

  dracut.sh has DRACUT_PATH=${DRACUT_PATH:-/sbin /bin /usr/sbin /usr/bin} 
exported as PATH
  dracut-047+31/modules.d/99shutdown/shutdown.sh:export 
PATH=/usr/sbin:/usr/bin:/sbin:/bin

  $ cat /etc/environment
  
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

  apt & dpkg => should probably initiate /usr/local-less PATH

  Imho the rest should probably be harmonised to:

  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

  ===

  From a duplicate
  https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1614080 :

  $ for i in 12.04 12.10 13.04 13.10 14.04 14.10 15.04 15.10 16.04; do echo $i; 
docker run -it --rm ubuntu:$i bash -c "unset PATH; /bin/bash -c 'echo \$PATH'"; 
done
  12.04
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  12.10
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  13.04
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  13.10
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  14.04
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
  14.10
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
  15.04
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
  15.10
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
  16.04
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

  I believe later releases of 

[Touch-packages] [Bug 1614080] Re: PATH contains dot when PATH is unset before running bash

2019-05-13 Thread Mathew Hodson
** Also affects: bash (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781367
   Importance: Unknown
   Status: Unknown

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

Title:
  PATH contains dot when PATH is unset before running bash

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Precise:
  Fix Released
Status in bash source package in Trusty:
  Won't Fix
Status in bash source package in Xenial:
  Fix Committed
Status in bash source package in Bionic:
  Fix Committed
Status in bash source package in Cosmic:
  Fix Released
Status in bash source package in Disco:
  Fix Committed
Status in bash source package in Eoan:
  Fix Released
Status in bash package in Debian:
  Unknown

Bug description:
  [Impact]

   * The fallback path built into bash contains '.' which leads to
  unexpected addition of the current working directory. It should not be
  there, just like it isnt' in pre-precise and cosmic+.

  [Test Case]

   * $ env -u PATH /bin/bash -c 'echo $PATH'

  Should not have '.' as any component. Nor should there be any empty
  components, i.e. '::'.

  [Regression Potential]

   * Normally PATH is always set by either init, systemd, or any other
  hypervisor. Thus this only affects executions under bash, when it was
  started without any environment - e.g. booting with 'init=/bin/bash'.

  [Other Info]
   
   * Original bug report.

  On ubuntu 16.04 (but also 14.04), running bash with PATH unset always
  adds '.' to PATH:

  philippe@pv-desktop:~$ echo $PATH
  
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  philippe@pv-desktop:~$ unset PATH
  philippe@pv-desktop:~$ /bin/bash
  philippe@pv-desktop:~$ echo $PATH
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

  Even when testing in a virtual machine / docker, and erasing
  /root/.profile /root/.bashrc /etc/profile /etc/bash.bashrc the problem
  still happens.

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

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


[Touch-packages] [Bug 1828901] Re: add PTY support for runuser

2019-05-13 Thread Eric Desrochers
** Tags added: sosreport37

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

Title:
  add PTY support for runuser

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress
Status in util-linux package in Debian:
  Unknown

Bug description:
  [IMPACT]

  [TEST CASE]

  [REGRESSION POTENTIAL]

  [OTHER INFORMATION]

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

  This is fixing a CVE vulnerability:
  https://security-tracker.debian.org/tracker/CVE-2016-2779

  Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
  http://www.openwall.com/lists/oss-security/2016/02/27/1
  https://marc.info/?l=util-linux-ng=145694736107128=2
  2.31 introduces a new --pty option to separate privileged and unprivileged
  shells (not enabled by default and the cli switch is necessary).

  [ORIGINAL DESCRIPTION]
  After a discussion with security team on what would be their recommended way 
to run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.

  The recommendation was to use 'runuser -P'

  runuser PTY support is present in Bionic and late, but not in Xenial.

  I'm opening this bug in the effort to update util-linux/runuser code
  in Xenial to add the PTY support.

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

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


[Touch-packages] [Bug 1828901] Re: add PTY support for runuser

2019-05-13 Thread Eric Desrochers
** Changed in: util-linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: util-linux (Ubuntu Xenial)
 Assignee: (unassigned) => Eric Desrochers (slashd)

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

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

** Changed in: util-linux (Ubuntu Xenial)
   Status: New => In Progress

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

Title:
  add PTY support for runuser

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress
Status in util-linux package in Debian:
  Unknown

Bug description:
  [IMPACT]

  [TEST CASE]

  [REGRESSION POTENTIAL]

  [OTHER INFORMATION]

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

  This is fixing a CVE vulnerability:
  https://security-tracker.debian.org/tracker/CVE-2016-2779

  Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
  http://www.openwall.com/lists/oss-security/2016/02/27/1
  https://marc.info/?l=util-linux-ng=145694736107128=2
  2.31 introduces a new --pty option to separate privileged and unprivileged
  shells (not enabled by default and the cli switch is necessary).

  [ORIGINAL DESCRIPTION]
  After a discussion with security team on what would be their recommended way 
to run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.

  The recommendation was to use 'runuser -P'

  runuser PTY support is present in Bionic and late, but not in Xenial.

  I'm opening this bug in the effort to update util-linux/runuser code
  in Xenial to add the PTY support.

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

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


[Touch-packages] [Bug 1828901] [NEW] add PTY support for runuser

2019-05-13 Thread Eric Desrochers
Public bug reported:

[IMPACT]

[TEST CASE]

[REGRESSION POTENTIAL]

[OTHER INFORMATION]

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

This is fixing a CVE vulnerability:
https://security-tracker.debian.org/tracker/CVE-2016-2779

Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
http://www.openwall.com/lists/oss-security/2016/02/27/1
https://marc.info/?l=util-linux-ng=145694736107128=2
2.31 introduces a new --pty option to separate privileged and unprivileged
shells (not enabled by default and the cli switch is necessary).

[ORIGINAL DESCRIPTION]
After a discussion with security team on what would be their recommended way to 
run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.

The recommendation was to use 'runuser -P'

runuser PTY support is present in Bionic and late, but not in Xenial.

I'm opening this bug in the effort to update util-linux/runuser code in
Xenial to add the PTY support.

** Affects: util-linux (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: util-linux (Ubuntu Xenial)
 Importance: Undecided
 Status: New


** Tags: sts

** Tags added: sts

** Also affects: util-linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: util-linux (Ubuntu)
   Status: New => Fix Released

** Description changed:

- After a discussion with security team on what would be their recommended
- way to run command as 'juju-user' inside the sosreport juju plugin which
- is run as root, in order to avoid using 'sudo' or 'su' command.
+ [IMPACT]
+ 
+ [TEST CASE]
+ 
+ [REGRESSION POTENTIAL]
+ 
+ [OTHER INFORMATION]
+ 
+ Debbug:
+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922
+ 
+ This is fixing a CVE vulnerability:
+ https://security-tracker.debian.org/tracker/CVE-2016-2779
+ 
+ Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
+ http://www.openwall.com/lists/oss-security/2016/02/27/1
+ https://marc.info/?l=util-linux-ng=145694736107128=2
+ 2.31 introduces a new --pty option to separate privileged and unprivileged
+ shells (not enabled by default and the cli switch is necessary).
+ 
+ [ORIGINAL DESCRIPTION]
+ After a discussion with security team on what would be their recommended way 
to run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.
  
  The recommendation was to use 'runuser -P'
  
  runuser PTY support is present in Bionic and late, but not in Xenial.
  
  I'm opening this bug in the effort to update util-linux/runuser code in
  Xenial to add the PTY support.

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

Title:
  add PTY support for runuser

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  New

Bug description:
  [IMPACT]

  [TEST CASE]

  [REGRESSION POTENTIAL]

  [OTHER INFORMATION]

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

  This is fixing a CVE vulnerability:
  https://security-tracker.debian.org/tracker/CVE-2016-2779

  Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
  http://www.openwall.com/lists/oss-security/2016/02/27/1
  https://marc.info/?l=util-linux-ng=145694736107128=2
  2.31 introduces a new --pty option to separate privileged and unprivileged
  shells (not enabled by default and the cli switch is necessary).

  [ORIGINAL DESCRIPTION]
  After a discussion with security team on what would be their recommended way 
to run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.

  The recommendation was to use 'runuser -P'

  runuser PTY support is present in Bionic and late, but not in Xenial.

  I'm opening this bug in the effort to update util-linux/runuser code
  in Xenial to add the PTY support.

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

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


[Touch-packages] [Bug 1796193] Re: DistUpgradeViewNonInteractive crashes / requires interaction

2019-05-13 Thread Brian Murray
** Description changed:

  [Impact]
  The NonInteractive view of ubuntu-release-upgrader doesn't work so it is hard 
to automate upgrade testing.
  
  [Test Case]
  You need to create a situation where you'll receive a conffile prompt since 
the handling of those is broken.
  
  1) On a bionic system modify /etc/update-manager/release-upgrades so that 
Prompt=normal
  2) Test an upgrade from bionic to cosmic or disco i.e. run do-release-upgrade
  3) Observe the upgrade hang on the '/etc/update-manager/release-upgrades' 
conffifle and the following in /var/log/dist-upgrade/main.log
  "2019-05-10 21:21:21,313 WARNING got a conffile-prompt from dpkg for file: 
'/etc/update-manager/release-upgrades'
  2019-05-10 21:21:26,319 ERROR error 'a bytes-like object is required, not 
'str'' when trying to write to the conffile"
  
  With the version of the release-upgrader from -proposed you'll no longer
  observe the upgrade process hanging.
  
  [Regression Potential]
- The fix is making it so that a byte object is passed to the prompt instead of 
a string one so there really isn't one.
+ The fix is making it so that a byte object is passed to the prompt instead of 
a string one so there really isn't one, however additional logging which could 
result in a Traceback if the syntax of that is wrong.
  
  [Original Description]
  I'm trying to do some automated testing that involved upgrading a system from 
xenial to bionic, so I need it to not ask for user input.
  
  Before running do-release-upgrade, the system got a fresh dist-upgrade
  and reboot.
  
  To avoid interactive responses, I'm using:
  $ sudo do-release-upgrade -d -f DistUpgradeViewNonInteractive
  
  Part way through the upgrade, I do get prompted for something though:
  Preparing to unpack .../apt_1.6.3ubuntu0.1_amd64.deb ...
  
  Unpacking apt (1.6.3ubuntu0.1) over (1.2.27) ...
  
  Processing triggers for libc-bin (2.27-3ubuntu1) ...
  
  /sbin/ldconfig.real: Warning: ignoring configuration file that cannot be
  opened: /etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf: No such file or
  directory
  
  /sbin/ldconfig.real: Warning: ignoring configuration file that cannot be
  opened: /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf: No such file or
  directory
  
  Setting up apt (1.6.3ubuntu0.1) ...
  
  Installing new version of config file /etc/apt/apt.conf.d/01autoremove
  ...
  
  Configuration file '/etc/cron.daily/apt-compat'
  
   ==> Deleted (by you or by a script) since installation.
  
   ==> Package distributor has shipped an updated version.
  
     What would you like to do about it ?  Your options are:
  
  Y or I  : install the package maintainer's version
  
  N or O  : keep your currently-installed version
  
    D : show the differences between the versions
  
    Z : start a shell to examine the situation
  
   The default action is to keep your current version.
  
  Comparing the sha1 of apt-compat before the upgrade to another xenial
  system that has been unmodified, they are the same:
  
  In /var/log/dist-upgrade/main.log, I also found this:
  2018-10-04 14:20:24,575 WARNING got a conffile-prompt from dpkg for file: 
'/etc/cron.daily/apt-compat'
  2018-10-04 14:20:29,580 ERROR error 'a bytes-like object is required, not 
'str'' when trying to write to the conffile

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

Title:
  DistUpgradeViewNonInteractive crashes / requires interaction

Status in apt package in Ubuntu:
  Incomplete
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in apt source package in Cosmic:
  New
Status in ubuntu-release-upgrader source package in Cosmic:
  In Progress
Status in apt source package in Disco:
  New
Status in ubuntu-release-upgrader source package in Disco:
  In Progress
Status in apt source package in Eoan:
  Incomplete
Status in ubuntu-release-upgrader source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  The NonInteractive view of ubuntu-release-upgrader doesn't work so it is hard 
to automate upgrade testing.

  [Test Case]
  You need to create a situation where you'll receive a conffile prompt since 
the handling of those is broken.

  1) On a bionic system modify /etc/update-manager/release-upgrades so that 
Prompt=normal
  2) Test an upgrade from bionic to cosmic or disco i.e. run do-release-upgrade
  3) Observe the upgrade hang on the '/etc/update-manager/release-upgrades' 
conffifle and the following in /var/log/dist-upgrade/main.log
  "2019-05-10 21:21:21,313 WARNING got a conffile-prompt from dpkg for file: 
'/etc/update-manager/release-upgrades'
  2019-05-10 21:21:26,319 ERROR error 'a bytes-like object is required, not 
'str'' when trying to write to the conffile"

  With the version of the release-upgrader from -proposed you'll no
  longer observe the upgrade process hanging.

  [Regression Potential]
 

[Touch-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le

2019-05-13 Thread Thadeu Lima de Souza Cascardo
https://lists.freedesktop.org/archives/systemd-
devel/2019-May/042570.html

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

Title:
  storage / luks / dmsetup regressed (or got better) on ppc64le

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in udisks2 package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in udisks2 source package in Bionic:
  New
Status in linux source package in Disco:
  New
Status in systemd source package in Disco:
  New
Status in udisks2 source package in Disco:
  New
Status in linux source package in Eoan:
  Confirmed
Status in systemd source package in Eoan:
  New
Status in udisks2 source package in Eoan:
  New

Bug description:
  in disco proposed with new systemd and v4.19 kernel it appears that
  dmsetup / cryptsetup storage either got better or worse.

  Devices take very long to activate, and sometimes remain in use during
  test clean up.

  This leads to udisks autopkgtest failing on ppc64le and systemd's
  "storage" autopkgtest is also failing.

  I've tried to make ppc64le test more resilient, but it's still odd
  that it became unstable in disco, and used to be rock solid on
  ppc64le.

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

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


[Touch-packages] [Bug 1828892] [NEW] systemctl - alias service reports inactive while aliased is active

2019-05-13 Thread Ioanna Alifieraki
Public bug reported:

[Impact]

'systemctl is-active' command reports an alias service as inactive even though 
the aliased service
is active.
Currently the 'systemctl is-active' command does not load units to minimise its 
effect on the system (i.e. that a monitoring command does not itself alter the 
state of the system).
However, this behaviour leads to inconsistencies when services are aliased.

[Test case]

- Test case 1 - libvirtd

alias service : libvirtd
aliased service : libvirt-bin

/etc/systemd/system$ ls -la libvirtd.service 
lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> 
/lib/systemd/system/libvirt-bin.service

$ systemctl is-active libvirtd
inactive

$ systemctl is-active libvirt-bin
active


- Test case 2 - sshd

alias service : sshd
aliased service : ssh

/ect/systemd/system$ ls -la sshd.service 
lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> 
/lib/systemd/system/ssh.service

$ systemctl is-active sshd
inactive

$ systemctl is-active ssh
active


[Regression Potential]

This fix may result into systemctl reporting inconsistent information
concerning the status of a service.

[Other]

Upstream issue : https://github.com/systemd/systemd/issues/7875
Upstream fix : https://github.com/systemd/systemd/pull/7997

Xenial is affected, fix exists on Bionic onward.

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

$ apt-cache policy systemd
systemd:
  Installed: 229-4ubuntu21.21
  Candidate: 229-4ubuntu21.21

** Affects: systemd (Ubuntu)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: systemd (Ubuntu Xenial)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed


** Tags: sts

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

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

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

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

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

** Changed in: systemd (Ubuntu Xenial)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Tags added: sts

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

Title:
  systemctl - alias service reports inactive while aliased is active

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  [Impact]

  'systemctl is-active' command reports an alias service as inactive even 
though the aliased service
  is active.
  Currently the 'systemctl is-active' command does not load units to minimise 
its effect on the system (i.e. that a monitoring command does not itself alter 
the state of the system).
  However, this behaviour leads to inconsistencies when services are aliased.

  [Test case]

  - Test case 1 - libvirtd

  alias service : libvirtd
  aliased service : libvirt-bin

  /etc/systemd/system$ ls -la libvirtd.service 
  lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> 
/lib/systemd/system/libvirt-bin.service

  $ systemctl is-active libvirtd
  inactive

  $ systemctl is-active libvirt-bin
  active

  
  - Test case 2 - sshd

  alias service : sshd
  aliased service : ssh

  /ect/systemd/system$ ls -la sshd.service 
  lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> 
/lib/systemd/system/ssh.service

  $ systemctl is-active sshd
  inactive

  $ systemctl is-active ssh
  active

  
  [Regression Potential]

  This fix may result into systemctl reporting inconsistent information
  concerning the status of a service.

  [Other]

  Upstream issue : https://github.com/systemd/systemd/issues/7875
  Upstream fix : https://github.com/systemd/systemd/pull/7997

  Xenial is affected, fix exists on Bionic onward.

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

  $ apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu21.21
Candidate: 229-4ubuntu21.21

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

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


[Touch-packages] [Bug 1657646] Re: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation

2019-05-13 Thread Andreas Hasenack
I'll prepare an MIR in https://bugs.launchpad.net/ubuntu/+source/thin-
provisioning-tools/+bug/1828887

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

Title:
  [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV
  from being (de)activated, but not its creation

Status in The Ubuntu-power-systems project:
  Triaged
Status in lvm2 package in Ubuntu:
  Confirmed
Status in lvm2 package in Debian:
  New

Bug description:
  Creating a thin pool LV is allowed even when thin-provisioning-tools
  is not installed. But deactivating or activating that VG fails. Since
  deactivating the VG usually only happens at reboot, the user might
  fail to notice this big problem until then.

  I think the lvconvert tool, used to combine the two "thin LVs" into a
  thin pool LV, should refuse to run if thin-provisioning-tools, or the
  needed scripts, aren't installed.

  Steps to reproduce:
  root@15-89:~# vgcreate vg /dev/vdb1
    Volume group "vg" successfully created

  root@15-89:~# vgs
    VG   #PV #LV #SN Attr   VSize  VFree
    vg 1   0   0 wz--n- 40.00g 40.00g

  root@15-89:~# lvcreate -n pool0 -l 90%VG vg
    Logical volume "pool0" created.

  root@15-89:~# lvcreate -n pool0meta -l 5%VG vg
    Logical volume "pool0meta" created.

  root@15-89:~# lvs
    LVVG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%Sync Convert
    pool0 vg   -wi-a- 36.00g
    pool0meta vg   -wi-a-  2.00g

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 100 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3820 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:14 vg-pool0 -> ../dm-0
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0meta -> ../dm-1

  root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0
    WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data 
and metadata volumes.
    THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y
    Converted vg/pool0 to thin pool.

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 120 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3840 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0 -> ../dm-2
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0
  root@15-89:~# lvs -a
    LV  VG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%S
  ync Convert
    [lvol0_pmspare] vg   ewi---  2.00g
    pool0   vg   twi-a-tz-- 36.00g 0.00   0.01
    [pool0_tdata]   vg   Twi-ao 36.00g
    [pool0_tmeta]   vg   ewi-ao  2.00g

  If you now reboot the system, all that is gone:
  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:28 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:28 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

  The same happens if you deactivate the VG (which the reboot
  undoubtedly triggers). It fails because of a missing
  /usr/sbin/thin_check which is provided by the thin-provisioning-tools
  package:

  root@15-89:~# vgchange -a n
    /usr/sbin/thin_check: execvp failed: No such file or directory
    WARNING: Integrity check of metadata for pool vg/pool0 failed.
    0 logical volume(s) in volume group "vg" now active

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:29 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:29 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

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

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


[Touch-packages] [Bug 1828883] Re: systemd sysv-compatibility eats exit codes

2019-05-13 Thread Ronny Trommer
I've verified this on Ubuntu 18.04 LTS

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.2 LTS
Release:18.04
Codename:   bionic

root@ubuntu:/etc/init.d# systemctl start exitcode
root@ubuntu:/etc/init.d# echo $?
0

root@ubuntu:/etc/init.d# systemctl status exitcodetest
● exitcodetest.service - LSB: Test Exit Code (SysV)
   Loaded: loaded (/etc/init.d/exitcodetest; generated)
   Active: active (exited) since Mon 2019-05-13 20:14:31 UTC; 9s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 3141 ExecStop=/etc/init.d/exitcodetest stop (code=exited, status=6)
  Process: 3152 ExecStart=/etc/init.d/exitcodetest start (code=exited, status=6)

May 13 20:14:31 ubuntu systemd[1]: Starting LSB: Test Exit Code (SysV)...
May 13 20:14:31 ubuntu systemd[1]: Started LSB: Test Exit Code (SysV).

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

Title:
  systemd sysv-compatibility eats exit codes

Status in systemd package in Ubuntu:
  New

Bug description:
  Systemd properly honors an exit code of 6 when creating a native
  service, like so:

  ---8<---
  ranger@carolina:/lib/systemd/system$ cat exitcode.service
  [Unit]
  Description=Test Exit Code (Systemd)

  [Service]
  Type=oneshot
  ExecStart=/bin/bash -c 'exit 6'

  [Install]
  WantedBy=default.target
  ranger@carolina:/lib/systemd/system$ sudo systemctl start exitcode
  Job for exitcode.service failed because the control process exited with error 
code.
  See "systemctl status exitcode.service" and "journalctl -xe" for details.
  ranger@carolina:/lib/systemd/system$ echo $?
  1
  ---8<---

  However, the equivalent SysV init file improperly returns an exit code
  of 0 when starting under the compatibility layer:

  ---8<---
  ranger@carolina:/etc/init.d$ cat exitcode
  #! /bin/sh

  ### BEGIN INIT INFO
  # Provides:  exitcode
  # Required-Start:$local_fs
  # Default-Start: 2 3 4 5
  # Default-Stop:  0 1 6
  # Short-Description: Test Exit Code (SysV)
  # Description:   Test case for Systemd SysV compatibility layer
  ### END INIT INFO

  exit 6
  ranger@carolina:/etc/init.d$ sudo systemctl enable exitcode
  exitcode.service is not a native service, redirecting to systemd-sysv-install.
  Executing: /lib/systemd/systemd-sysv-install enable exitcode
  ranger@carolina:/etc/init.d$ sudo systemctl start exitcode
  ranger@carolina:/etc/init.d$ echo $?
  0
  ---8<---

  Even if I change the script to do `exit 1` it still returns exit code
  0.

  These are tiny examples but we are hitting it in the real world with
  the startup scripts for the OpenNMS Debian/Ubuntu packages, which
  return exit code 6 (LSB "not configured") when there are leftover
  upgrade files in `/etc/opennms`. The OpenNMS startup is not properly
  failing on attempted startup in this case.

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

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


[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd

2019-05-13 Thread Eric Desrochers
FAIL: 12 warning messages, expected 8.
W [13/May/2019:13:53:19.857395 +] No JobPrivateAccess defined in policy 
default - using defaults.
W [13/May/2019:13:53:19.857412 +] No JobPrivateValues defined in policy 
default - using defaults.
W [13/May/2019:13:53:19.857428 +] No SubscriptionPrivateAccess defined in 
policy default - using defaults.
W [13/May/2019:13:53:19.857443 +] No SubscriptionPrivateValues defined in 
policy default - using defaults.
W [13/May/2019:13:53:30.125242 +] [Job 7] temp file: can\'t find PDF header
W [13/May/2019:13:53:30.125347 +] [Job 7] temp file: file is damaged
W [13/May/2019:13:53:30.125422 +] [Job 7] temp file: can\'t find startxref
W [13/May/2019:13:53:30.125486 +] [Job 7] temp file: Attempting to 
reconstruct cross-reference table
W [13/May/2019:13:53:46.287322 +] No JobPrivateAccess defined in policy 
default - using defaults.
W [13/May/2019:13:53:46.287338 +] No JobPrivateValues defined in policy 
default - using defaults.
W [13/May/2019:13:53:46.287355 +] No SubscriptionPrivateAccess defined in 
policy default - using defaults.
W [13/May/2019:13:53:46.287372 +] No SubscriptionPrivateValues defined in 
policy default - using defaults.

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

Title:
  Race condition on boot between cups and sssd

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

Bug description:
  [Impact]

   * When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist.

   * The patch adds an "After=sssd.service" clause to the service unit
  file.

  [Test Case]

   * Configure an external authentication service (LDAP, AD...) and
  create a group, for instance "lpadmins@tests.local"

   * Set SystemGroup to match that group in /etc/cups/cups-files.conf:
  SystemGroup lpadmins@tests.local

   * Reboot

   * If cups has started before sssd has finished booting, cups will crash:
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.

   * If cups starts after sssd, it will work fine.

  [Regression Potential]

   * Minimal: this patch affects just the ordering of the service unit
  file.

  [Other Info]

   * Upstream:
  https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d

  [Original description]

  When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist. For instance, with a
  group named lpadmins@tests.local served from Active Directory through
  sssd, if the sssd service hasn't booted before cups:

  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read 
"/etc/cups/cups-files.conf" due to errors.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, 
code=exited, status=1/FAILURE
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 
'exit-code'.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time 
over, scheduling restart.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, 
restart counter is at 2.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers 
available locally...
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler.

  If sssd is running before cups starts, everything works as expected.

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

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


[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd

2019-05-13 Thread Eric Desrochers
I re-run a few test myselfs, and was able to clean them up.
Only remaining blocker is the FTBFS situation in Xenial for s390x arch which 
seems to fails at override_dh_auto_test.

# Pending SRU:
cups
s390x: Failed to build
https://launchpadlibrarian.net/423558504/buildlog_ubuntu-xenial-s390x.cups_2.1.3-4ubuntu0.8_BUILDING.txt.gz

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

Title:
  Race condition on boot between cups and sssd

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

Bug description:
  [Impact]

   * When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist.

   * The patch adds an "After=sssd.service" clause to the service unit
  file.

  [Test Case]

   * Configure an external authentication service (LDAP, AD...) and
  create a group, for instance "lpadmins@tests.local"

   * Set SystemGroup to match that group in /etc/cups/cups-files.conf:
  SystemGroup lpadmins@tests.local

   * Reboot

   * If cups has started before sssd has finished booting, cups will crash:
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.

   * If cups starts after sssd, it will work fine.

  [Regression Potential]

   * Minimal: this patch affects just the ordering of the service unit
  file.

  [Other Info]

   * Upstream:
  https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d

  [Original description]

  When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist. For instance, with a
  group named lpadmins@tests.local served from Active Directory through
  sssd, if the sssd service hasn't booted before cups:

  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read 
"/etc/cups/cups-files.conf" due to errors.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, 
code=exited, status=1/FAILURE
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 
'exit-code'.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time 
over, scheduling restart.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, 
restart counter is at 2.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers 
available locally...
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler.

  If sssd is running before cups starts, everything works as expected.

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

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


[Touch-packages] [Bug 1828883] [NEW] systemd sysv-compatibility eats exit codes

2019-05-13 Thread Benjamin Reed
Public bug reported:

Systemd properly honors an exit code of 6 when creating a native
service, like so:

---8<---
ranger@carolina:/lib/systemd/system$ cat exitcode.service
[Unit]
Description=Test Exit Code (Systemd)

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'exit 6'

[Install]
WantedBy=default.target
ranger@carolina:/lib/systemd/system$ sudo systemctl start exitcode
Job for exitcode.service failed because the control process exited with error 
code.
See "systemctl status exitcode.service" and "journalctl -xe" for details.
ranger@carolina:/lib/systemd/system$ echo $?
1
---8<---

However, the equivalent SysV init file improperly returns an exit code
of 0 when starting under the compatibility layer:

---8<---
ranger@carolina:/etc/init.d$ cat exitcode
#! /bin/sh

### BEGIN INIT INFO
# Provides:  exitcode
# Required-Start:$local_fs
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: Test Exit Code (SysV)
# Description:   Test case for Systemd SysV compatibility layer
### END INIT INFO

exit 6
ranger@carolina:/etc/init.d$ sudo systemctl enable exitcode
exitcode.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable exitcode
ranger@carolina:/etc/init.d$ sudo systemctl start exitcode
ranger@carolina:/etc/init.d$ echo $?
0
---8<---

Even if I change the script to do `exit 1` it still returns exit code 0.

These are tiny examples but we are hitting it in the real world with the
startup scripts for the OpenNMS Debian/Ubuntu packages, which return
exit code 6 (LSB "not configured") when there are leftover upgrade files
in `/etc/opennms`. The OpenNMS startup is not properly failing on
attempted startup in this case.

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

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

Title:
  systemd sysv-compatibility eats exit codes

Status in systemd package in Ubuntu:
  New

Bug description:
  Systemd properly honors an exit code of 6 when creating a native
  service, like so:

  ---8<---
  ranger@carolina:/lib/systemd/system$ cat exitcode.service
  [Unit]
  Description=Test Exit Code (Systemd)

  [Service]
  Type=oneshot
  ExecStart=/bin/bash -c 'exit 6'

  [Install]
  WantedBy=default.target
  ranger@carolina:/lib/systemd/system$ sudo systemctl start exitcode
  Job for exitcode.service failed because the control process exited with error 
code.
  See "systemctl status exitcode.service" and "journalctl -xe" for details.
  ranger@carolina:/lib/systemd/system$ echo $?
  1
  ---8<---

  However, the equivalent SysV init file improperly returns an exit code
  of 0 when starting under the compatibility layer:

  ---8<---
  ranger@carolina:/etc/init.d$ cat exitcode
  #! /bin/sh

  ### BEGIN INIT INFO
  # Provides:  exitcode
  # Required-Start:$local_fs
  # Default-Start: 2 3 4 5
  # Default-Stop:  0 1 6
  # Short-Description: Test Exit Code (SysV)
  # Description:   Test case for Systemd SysV compatibility layer
  ### END INIT INFO

  exit 6
  ranger@carolina:/etc/init.d$ sudo systemctl enable exitcode
  exitcode.service is not a native service, redirecting to systemd-sysv-install.
  Executing: /lib/systemd/systemd-sysv-install enable exitcode
  ranger@carolina:/etc/init.d$ sudo systemctl start exitcode
  ranger@carolina:/etc/init.d$ echo $?
  0
  ---8<---

  Even if I change the script to do `exit 1` it still returns exit code
  0.

  These are tiny examples but we are hitting it in the real world with
  the startup scripts for the OpenNMS Debian/Ubuntu packages, which
  return exit code 6 (LSB "not configured") when there are leftover
  upgrade files in `/etc/opennms`. The OpenNMS startup is not properly
  failing on attempted startup in this case.

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

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


[Touch-packages] [Bug 1828102] Re: Regression in ModemManager

2019-05-13 Thread Till Kamppeter
** Summary changed:

- regression in modemmanager
+ Regression in ModemManager

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

Title:
  Regression in ModemManager

Status in modemmanager package in Ubuntu:
  Fix Released
Status in modemmanager source package in Cosmic:
  In Progress
Status in modemmanager source package in Disco:
  In Progress
Status in modemmanager source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  [Test case]

  [Regression potential]

  The patch is tiny, fixing an obvious overlook, and it only affects
  CDMA broadband modems, so the risk of a regression is very low.

  [Original description]

  ModemManager disconnects after ~30 sec

  caused by a typo in 1.8

  see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615
  and
  https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119
  for details

  needs a SRU for cosmic and dingo

  patch attached

  yechiel

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

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


[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2019-05-13 Thread Jamie Lokier
For what it's worth, I'm still seeing set-name having no affect on a
server's only interface.

Server is using Ubuntu 19.04, with netplan.io-0.96-0ubuntu4.1, AMD64
arch.  It's a bare-metal server with a single "e1000e" ethernet device.
No cloud-init installed.

Config file /etc/netplan/01-netcfg.yaml starts like this:

network:
  version: 2
  renderer: networkd
  ethernets:
enp4s0:
  match:
name: enp4s0
  set-name: eth0
  addresses:
- $IPV4
- $IPV6
   (etc.)

The interface is configured adequately in boot, but the interface name
is not changed according to "set-name eth0".  It just doesn't change,
with "netplan apply" or not.

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

Title:
  systemd-networkd not renaming devices on boot

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

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0
  - Bring down interface : 'ip link set dev ens3 down'
  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 

[Touch-packages] [Bug 1828102] Re: regression in modemmanager

2019-05-13 Thread yparitcher
launchpad errors whenever i try to update or post a comment directly
from a bug. it only works from the comment/attachment page so here is
the updated desc.


[Impact]

ModemManager disconnects from CDMA modem after 30 sec failing to check
signal status due to incorrect error handling

[Test case]

connect to a cdma device without an extra AT channel (Eg. Samsung
brightside phone) and modemmanager will terminate the connection

[Regression potential]

The patch is tiny, fixing an obvious overlook, and it only affects CDMA
broadband modems, so the risk of a regression is very low.

[Original description]

ModemManager disconnects after ~30 sec

caused by a typo in 1.8

see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615
and
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119
for details

needs a SRU for cosmic and dingo

patch attached

yechiel

** Bug watch added: gitlab.freedesktop.org/mobile-broadband/ModemManager/issues 
#119
   https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119

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

Title:
  regression in modemmanager

Status in modemmanager package in Ubuntu:
  Fix Released
Status in modemmanager source package in Cosmic:
  In Progress
Status in modemmanager source package in Disco:
  In Progress
Status in modemmanager source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  [Test case]

  [Regression potential]

  The patch is tiny, fixing an obvious overlook, and it only affects
  CDMA broadband modems, so the risk of a regression is very low.

  [Original description]

  ModemManager disconnects after ~30 sec

  caused by a typo in 1.8

  see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615
  and
  https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119
  for details

  needs a SRU for cosmic and dingo

  patch attached

  yechiel

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

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


[Touch-packages] [Bug 1828102] Re: regression in modemmanager

2019-05-13 Thread Till Kamppeter
debdiff for SRU for cosmic.

** Patch added: "modemmanager_1.8.2-1_1.8.2-1ubuntu0.18.10.1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1828102/+attachment/5263498/+files/modemmanager_1.8.2-1_1.8.2-1ubuntu0.18.10.1.debdiff

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

** Description changed:

+ [Impact]
+ 
+ [Test case]
+ 
+ [Regression potential]
+ 
+ The patch is tiny, fixing an obvious overlook, and it only affects CDMA
+ broadband modems, so the risk of a regression is very low.
+ 
+ [Original description]
+ 
  ModemManager disconnects after ~30 sec
  
  caused by a typo in 1.8
  
- see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615 
+ see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615
  and
  https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119
  for details
  
  needs a SRU for cosmic and dingo
  
  patch attached
  
  yechiel

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

Title:
  regression in modemmanager

Status in modemmanager package in Ubuntu:
  Fix Released
Status in modemmanager source package in Cosmic:
  In Progress
Status in modemmanager source package in Disco:
  In Progress
Status in modemmanager source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  [Test case]

  [Regression potential]

  The patch is tiny, fixing an obvious overlook, and it only affects
  CDMA broadband modems, so the risk of a regression is very low.

  [Original description]

  ModemManager disconnects after ~30 sec

  caused by a typo in 1.8

  see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615
  and
  https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119
  for details

  needs a SRU for cosmic and dingo

  patch attached

  yechiel

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

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


[Touch-packages] [Bug 1828102] Re: regression in modemmanager

2019-05-13 Thread Till Kamppeter
yparitcher, thank you very much for this bug report and the patch. To
start the SRU approval process could you please edit the initial
description, filling in the [Impact] and [Test case] sections? The first
is to describe what impact this bug has to the users, the second is for
describing how to reproduce the bug.

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

Title:
  regression in modemmanager

Status in modemmanager package in Ubuntu:
  Fix Released
Status in modemmanager source package in Cosmic:
  In Progress
Status in modemmanager source package in Disco:
  In Progress
Status in modemmanager source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  [Test case]

  [Regression potential]

  The patch is tiny, fixing an obvious overlook, and it only affects
  CDMA broadband modems, so the risk of a regression is very low.

  [Original description]

  ModemManager disconnects after ~30 sec

  caused by a typo in 1.8

  see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615
  and
  https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119
  for details

  needs a SRU for cosmic and dingo

  patch attached

  yechiel

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

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


[Touch-packages] [Bug 378783] Re: xdg-open *.desktop opens text editor

2019-05-13 Thread xChris
Temp "patch" (works with gnome-shell)

install "dex" , then @ $HOME/.local/share/applications create 
a file "userapp-dex.desktop" as:


[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/usr/bin/dex %u
Name=Dex
Comment=Dex-opener

"asssociate" a .desktop file with that

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

Title:
  xdg-open *.desktop opens text editor

Status in GLib:
  New
Status in gvfs:
  New
Status in glib2.0 package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: xdg-utils

  In order to reproduce it execute "xdg-open *.desktop" (choose any
  .desktop file, e.g. one from /usr/share/applications). Actually your
  favorite text editor will open the file. Expected result: It'll be
  executed.

  Because of this bug, desktop entries with the new "#!/usr/bin/env xdg-
  open" shebang feature were opened in the text editor when executed
  from command line.

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

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


[Touch-packages] [Bug 1828102] Re: regression in modemmanager

2019-05-13 Thread Till Kamppeter
debdiff for SRU for disco.

** Patch added: "modemmanager_1.10.0-1_1.10.0-1ubuntu0.19.04.1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1828102/+attachment/5263493/+files/modemmanager_1.10.0-1_1.10.0-1ubuntu0.19.04.1.debdiff

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

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

Title:
  regression in modemmanager

Status in modemmanager package in Ubuntu:
  Fix Released
Status in modemmanager source package in Cosmic:
  New
Status in modemmanager source package in Disco:
  In Progress
Status in modemmanager source package in Eoan:
  Fix Released

Bug description:
  ModemManager disconnects after ~30 sec

  caused by a typo in 1.8

  see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615 
  and
  https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119
  for details

  needs a SRU for cosmic and dingo

  patch attached

  yechiel

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

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


[Touch-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression

2019-05-13 Thread Adam Conrad
The original bug report was about a regression in 16.04 with the dnsmasq
integration.  While I'm glad this got the ball rolling on the bionic
networkd integration, let's not forget that we broke xenial?  Added a
xenial task for network-manager accordingly.

** Also affects: network-manager (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

Title:
  Full-tunnel VPN DNS leakage regression

Status in NetworkManager:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in network-manager source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Triaged

Bug description:
  [Impact]
  When using a VPN the DNS requests might still be sent to a DNS server outside 
the VPN when they should not

  [Test case]
  1) Set up a VPN with split tunneling:
a) Configure VPN normally (set up remote host, any ports and options needed 
for the VPN to work)
b) Under the IPv4 tab: enable "Use this connection only for the resources 
on its network".
c) Under the IPv6 tab: enable "Use this connection only for the resources 
on its network".

  2) Connect to the VPN.

  3) Run 'systemd-resolve --status'; note the DNS servers configured:
a) For the VPN; under a separate link (probably tun0), note down the IP of 
the DNS server(s). Also note the name of the interface (link).
b) For the "main" connection; under the link for your ethernet or wireless 
devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). 
Also note the name of the interface (link).

  4) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  5) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  6) In yet another terminal, issue name resolution requests using dig:
a) For a name known to be reachable via the public network:
   'dig www.yahoo.com'
b) For a name known to be reachable only via the VPN:
   'dig '

  7) Check the output of each terminal running tcpdump. When requesting
  the public name, traffic can go through either. When requesting the
  "private" name (behind the VPN), traffic should only be going through
  the interface for the VPN. Additionally, ensure the IP receiving the
  requests for the VPN name is indeed the IP address noted above for the
  VPN's DNS server.

  If you see no traffic showing in tcpdump output when requesting a
  name, it may be because it is cached by systemd-resolved. Use a
  different name you have not tried before.

  
  [Regression potential]
  The code change the handling of DNS servers when using a VPN, we should check 
that name resolution still work whne using a VPN in different configurations

  -

  In 16.04 the NetworkManager package used to carry this patch:
  
http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch

  It fixed the DNS setup so that when I'm on the VPN, I am not sending
  unencrypted DNS queries to the (potentially hostile) local
  nameservers.

  This patch disappeared in an update. I think it was present in
  1.2.2-0ubuntu0.16.04.4 but was dropped some time later.

  This security bug exists upstream too: 
https://bugzilla.gnome.org/show_bug.cgi?id=746422
  It's not a *regression* there though, as they didn't fix it yet 
(unfortunately!)

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

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


[Touch-packages] [Bug 1825946] Re: 'nm' autopkgtest fails due to GI stderr output

2019-05-13 Thread Till Kamppeter
network-manager 1.10.14-0ubuntu2 witrh the fix for this bug got
transferred to bionic-updates. Thanks to the SRU team for the great
cooperation.

** Changed in: network-manager (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

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

Title:
  'nm' autopkgtest fails due to GI stderr output

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Xenial:
  In Progress
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  [impact]

  'nm' testcase contains:
  from gi.repository import NetworkManager, NMClient, GLib  


 

  which generates output to stderr:
  /tmp/autopkgtest.naU0ts/build.riU/src/debian/tests/nm:23: PyGIWarning: 
NetworkManager was imported without specifying a version first. Use 
gi.require_version('NetworkManager', '1.0') before import to ensure that the 
right version gets loaded.

  the gi.require_version call has already been added to cosmic and
  disco.

  [test case]

  see http://autopkgtest.ubuntu.com/packages/network-manager bionic test
  results.

  [other info]

  this only fails intermittently, but the failure is clearly not an
  actual problem.

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

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


[Touch-packages] [Bug 942856] Update Released

2019-05-13 Thread Łukasz Zemczak
The verification of the Stable Release Update for network-manager has
completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  NetworkManager does not support AES-encrypted private keys for WPA
  802.1x authentication

Status in NetworkManager:
  Confirmed
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  * Impact

  Selecting AES-{192,256}-CBC keys to connect isn't working

  * Test case

  1. Start with a working (cleartext or DES-3) private key/cert for a network.  
Set up a connection and verify that everything works.
  2. Re-encrypt the key with AES-256 with this command: "openssl rsa -in 
working-key.pem -out aes-key.pem -aes256" (the output should have a line 
starting with "DEK-Info: AES-256-CBC,")
  3. Delete the settings for the test network and attempt to reconnect using 
the new key. 

  That should work

  * Regression potential

  That's new code for an extra type of keys, it shouldn't impact
  existing options

  --

  NetworkManager does not appear to support private keys encrypted with
  AES.  At the very least, it will not validate such a key in nm-util
  when setting up a WPA 802.1x TLS wifi connection.

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

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


[Touch-packages] [Bug 942856] Re: NetworkManager does not support AES-encrypted private keys for WPA 802.1x authentication

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package network-manager - 1.10.14-0ubuntu2

---
network-manager (1.10.14-0ubuntu2) bionic; urgency=medium

  [ Till Kamppeter ]
  * debian/tests/nm: Add gi.require_version() calls for NetworkManager
and NMClient to avoid stderr output which fails the test.

  [ Iain Lane ]
  * debian/tests/control: The nm tests need dnsmasq-base and isc-dhcp-client
too.

network-manager (1.10.14-0ubuntu1) bionic; urgency=medium

  * New stable version (LP: #1809132), including:
- Support private keys encrypted with AES-{192,256}-CBC in libnm
  (LP: #942856)
- Fix leak of DNS queries to local name servers when connecting to a
  full-tunnel VPN (CVE-2018-1000135) (LP: #1754671)
  * Dropped patch applied upstream:
- debian/patches/CVE-2018-15688.patch
- debian/patches/e91f1a7d2a6b8400b6b331d5b72287dcb5164a39.patch
  * Refreshed patches:
- debian/patches/Don-t-make-NetworkManager-D-Bus-activatable.patch
- debian/patches/Force-online-state-with-unmanaged-devices.patch
- debian/patches/Read-system-connections-from-run.patch
- debian/patches/Update-dnsmasq-parameters.patch
- 
debian/patches/libnm-register-empty-NMClient-and-NetworkManager-when-loa.patch

 -- Till Kamppeter   Fri, 10 May 2019 13:34:00
+0200

** Changed in: network-manager (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2018-1000135

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-15688

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

Title:
  NetworkManager does not support AES-encrypted private keys for WPA
  802.1x authentication

Status in NetworkManager:
  Confirmed
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  * Impact

  Selecting AES-{192,256}-CBC keys to connect isn't working

  * Test case

  1. Start with a working (cleartext or DES-3) private key/cert for a network.  
Set up a connection and verify that everything works.
  2. Re-encrypt the key with AES-256 with this command: "openssl rsa -in 
working-key.pem -out aes-key.pem -aes256" (the output should have a line 
starting with "DEK-Info: AES-256-CBC,")
  3. Delete the settings for the test network and attempt to reconnect using 
the new key. 

  That should work

  * Regression potential

  That's new code for an extra type of keys, it shouldn't impact
  existing options

  --

  NetworkManager does not appear to support private keys encrypted with
  AES.  At the very least, it will not validate such a key in nm-util
  when setting up a WPA 802.1x TLS wifi connection.

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

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


[Touch-packages] [Bug 1809132] Update Released

2019-05-13 Thread Łukasz Zemczak
The verification of the Stable Release Update for network-manager has
completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  Updated bionic to the current 1.10 stable version

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  * Impact

  The updates in the stable serie include several fixes for
  misbehaviour, segfaults and security issues, those are the sort of
  improvements that should be in the LTS

  The detail of the changes can be seen in the NEWS entry
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/nm-1-10/NEWS

  * Test case

  There is no specific test case for the update, the changelog includes
  some specific bugs which have their own test case, otherwise it's
  important to get testing/feedback from users on desktop & server,
  using IPv4, IPv6, VPN, wifi, eth connections, etc.

  * Regression potential

  The update is non trivial, there are several changes are IPv6 and DNS
  (especially in the context of VPNs) handling so it would be good to
  give those extra testing

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

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


[Touch-packages] [Bug 1657646] Re: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation

2019-05-13 Thread Frank Heimes
** Summary changed:

- [20.04]Missing thin-provisioning-tools prevents VG with thin pool LV from 
being (de)activated, but not its creation
+ [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from 
being (de)activated, but not its creation

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

Title:
  [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV
  from being (de)activated, but not its creation

Status in The Ubuntu-power-systems project:
  Triaged
Status in lvm2 package in Ubuntu:
  Confirmed
Status in lvm2 package in Debian:
  New

Bug description:
  Creating a thin pool LV is allowed even when thin-provisioning-tools
  is not installed. But deactivating or activating that VG fails. Since
  deactivating the VG usually only happens at reboot, the user might
  fail to notice this big problem until then.

  I think the lvconvert tool, used to combine the two "thin LVs" into a
  thin pool LV, should refuse to run if thin-provisioning-tools, or the
  needed scripts, aren't installed.

  Steps to reproduce:
  root@15-89:~# vgcreate vg /dev/vdb1
    Volume group "vg" successfully created

  root@15-89:~# vgs
    VG   #PV #LV #SN Attr   VSize  VFree
    vg 1   0   0 wz--n- 40.00g 40.00g

  root@15-89:~# lvcreate -n pool0 -l 90%VG vg
    Logical volume "pool0" created.

  root@15-89:~# lvcreate -n pool0meta -l 5%VG vg
    Logical volume "pool0meta" created.

  root@15-89:~# lvs
    LVVG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%Sync Convert
    pool0 vg   -wi-a- 36.00g
    pool0meta vg   -wi-a-  2.00g

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 100 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3820 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:14 vg-pool0 -> ../dm-0
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0meta -> ../dm-1

  root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0
    WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data 
and metadata volumes.
    THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y
    Converted vg/pool0 to thin pool.

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 120 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3840 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0 -> ../dm-2
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0
  root@15-89:~# lvs -a
    LV  VG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%S
  ync Convert
    [lvol0_pmspare] vg   ewi---  2.00g
    pool0   vg   twi-a-tz-- 36.00g 0.00   0.01
    [pool0_tdata]   vg   Twi-ao 36.00g
    [pool0_tmeta]   vg   ewi-ao  2.00g

  If you now reboot the system, all that is gone:
  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:28 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:28 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

  The same happens if you deactivate the VG (which the reboot
  undoubtedly triggers). It fails because of a missing
  /usr/sbin/thin_check which is provided by the thin-provisioning-tools
  package:

  root@15-89:~# vgchange -a n
    /usr/sbin/thin_check: execvp failed: No such file or directory
    WARNING: Integrity check of metadata for pool vg/pool0 failed.
    0 logical volume(s) in volume group "vg" now active

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:29 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:29 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

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

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


[Touch-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package network-manager - 1.10.14-0ubuntu2

---
network-manager (1.10.14-0ubuntu2) bionic; urgency=medium

  [ Till Kamppeter ]
  * debian/tests/nm: Add gi.require_version() calls for NetworkManager
and NMClient to avoid stderr output which fails the test.

  [ Iain Lane ]
  * debian/tests/control: The nm tests need dnsmasq-base and isc-dhcp-client
too.

network-manager (1.10.14-0ubuntu1) bionic; urgency=medium

  * New stable version (LP: #1809132), including:
- Support private keys encrypted with AES-{192,256}-CBC in libnm
  (LP: #942856)
- Fix leak of DNS queries to local name servers when connecting to a
  full-tunnel VPN (CVE-2018-1000135) (LP: #1754671)
  * Dropped patch applied upstream:
- debian/patches/CVE-2018-15688.patch
- debian/patches/e91f1a7d2a6b8400b6b331d5b72287dcb5164a39.patch
  * Refreshed patches:
- debian/patches/Don-t-make-NetworkManager-D-Bus-activatable.patch
- debian/patches/Force-online-state-with-unmanaged-devices.patch
- debian/patches/Read-system-connections-from-run.patch
- debian/patches/Update-dnsmasq-parameters.patch
- 
debian/patches/libnm-register-empty-NMClient-and-NetworkManager-when-loa.patch

 -- Till Kamppeter   Fri, 10 May 2019 13:34:00
+0200

** Changed in: network-manager (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-15688

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

Title:
  Full-tunnel VPN DNS leakage regression

Status in NetworkManager:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Triaged

Bug description:
  [Impact]
  When using a VPN the DNS requests might still be sent to a DNS server outside 
the VPN when they should not

  [Test case]
  1) Set up a VPN with split tunneling:
a) Configure VPN normally (set up remote host, any ports and options needed 
for the VPN to work)
b) Under the IPv4 tab: enable "Use this connection only for the resources 
on its network".
c) Under the IPv6 tab: enable "Use this connection only for the resources 
on its network".

  2) Connect to the VPN.

  3) Run 'systemd-resolve --status'; note the DNS servers configured:
a) For the VPN; under a separate link (probably tun0), note down the IP of 
the DNS server(s). Also note the name of the interface (link).
b) For the "main" connection; under the link for your ethernet or wireless 
devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). 
Also note the name of the interface (link).

  4) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  5) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  6) In yet another terminal, issue name resolution requests using dig:
a) For a name known to be reachable via the public network:
   'dig www.yahoo.com'
b) For a name known to be reachable only via the VPN:
   'dig '

  7) Check the output of each terminal running tcpdump. When requesting
  the public name, traffic can go through either. When requesting the
  "private" name (behind the VPN), traffic should only be going through
  the interface for the VPN. Additionally, ensure the IP receiving the
  requests for the VPN name is indeed the IP address noted above for the
  VPN's DNS server.

  If you see no traffic showing in tcpdump output when requesting a
  name, it may be because it is cached by systemd-resolved. Use a
  different name you have not tried before.

  
  [Regression potential]
  The code change the handling of DNS servers when using a VPN, we should check 
that name resolution still work whne using a VPN in different configurations

  -

  In 16.04 the NetworkManager package used to carry this patch:
  
http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch

  It fixed the DNS setup so that when I'm on the VPN, I am not sending
  unencrypted DNS queries to the (potentially hostile) local
  nameservers.

  This patch disappeared in an update. I think it was present in
  1.2.2-0ubuntu0.16.04.4 but was dropped some time later.

  This security bug exists upstream too: 
https://bugzilla.gnome.org/show_bug.cgi?id=746422
  It's not a *regression* there though, as they didn't fix it yet 
(unfortunately!)

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

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

[Touch-packages] [Bug 1809132] Re: Updated bionic to the current 1.10 stable version

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package network-manager - 1.10.14-0ubuntu2

---
network-manager (1.10.14-0ubuntu2) bionic; urgency=medium

  [ Till Kamppeter ]
  * debian/tests/nm: Add gi.require_version() calls for NetworkManager
and NMClient to avoid stderr output which fails the test.

  [ Iain Lane ]
  * debian/tests/control: The nm tests need dnsmasq-base and isc-dhcp-client
too.

network-manager (1.10.14-0ubuntu1) bionic; urgency=medium

  * New stable version (LP: #1809132), including:
- Support private keys encrypted with AES-{192,256}-CBC in libnm
  (LP: #942856)
- Fix leak of DNS queries to local name servers when connecting to a
  full-tunnel VPN (CVE-2018-1000135) (LP: #1754671)
  * Dropped patch applied upstream:
- debian/patches/CVE-2018-15688.patch
- debian/patches/e91f1a7d2a6b8400b6b331d5b72287dcb5164a39.patch
  * Refreshed patches:
- debian/patches/Don-t-make-NetworkManager-D-Bus-activatable.patch
- debian/patches/Force-online-state-with-unmanaged-devices.patch
- debian/patches/Read-system-connections-from-run.patch
- debian/patches/Update-dnsmasq-parameters.patch
- 
debian/patches/libnm-register-empty-NMClient-and-NetworkManager-when-loa.patch

 -- Till Kamppeter   Fri, 10 May 2019 13:34:00
+0200

** Changed in: network-manager (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2018-1000135

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-15688

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

Title:
  Updated bionic to the current 1.10 stable version

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  * Impact

  The updates in the stable serie include several fixes for
  misbehaviour, segfaults and security issues, those are the sort of
  improvements that should be in the LTS

  The detail of the changes can be seen in the NEWS entry
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/nm-1-10/NEWS

  * Test case

  There is no specific test case for the update, the changelog includes
  some specific bugs which have their own test case, otherwise it's
  important to get testing/feedback from users on desktop & server,
  using IPv4, IPv6, VPN, wifi, eth connections, etc.

  * Regression potential

  The update is non trivial, there are several changes are IPv6 and DNS
  (especially in the context of VPNs) handling so it would be good to
  give those extra testing

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

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


[Touch-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression

2019-05-13 Thread Łukasz Zemczak
Will be releasing network-manager without the systemd part for now as it
poses no threat to the user.

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

Title:
  Full-tunnel VPN DNS leakage regression

Status in NetworkManager:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Triaged

Bug description:
  [Impact]
  When using a VPN the DNS requests might still be sent to a DNS server outside 
the VPN when they should not

  [Test case]
  1) Set up a VPN with split tunneling:
a) Configure VPN normally (set up remote host, any ports and options needed 
for the VPN to work)
b) Under the IPv4 tab: enable "Use this connection only for the resources 
on its network".
c) Under the IPv6 tab: enable "Use this connection only for the resources 
on its network".

  2) Connect to the VPN.

  3) Run 'systemd-resolve --status'; note the DNS servers configured:
a) For the VPN; under a separate link (probably tun0), note down the IP of 
the DNS server(s). Also note the name of the interface (link).
b) For the "main" connection; under the link for your ethernet or wireless 
devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). 
Also note the name of the interface (link).

  4) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  5) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  6) In yet another terminal, issue name resolution requests using dig:
a) For a name known to be reachable via the public network:
   'dig www.yahoo.com'
b) For a name known to be reachable only via the VPN:
   'dig '

  7) Check the output of each terminal running tcpdump. When requesting
  the public name, traffic can go through either. When requesting the
  "private" name (behind the VPN), traffic should only be going through
  the interface for the VPN. Additionally, ensure the IP receiving the
  requests for the VPN name is indeed the IP address noted above for the
  VPN's DNS server.

  If you see no traffic showing in tcpdump output when requesting a
  name, it may be because it is cached by systemd-resolved. Use a
  different name you have not tried before.

  
  [Regression potential]
  The code change the handling of DNS servers when using a VPN, we should check 
that name resolution still work whne using a VPN in different configurations

  -

  In 16.04 the NetworkManager package used to carry this patch:
  
http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch

  It fixed the DNS setup so that when I'm on the VPN, I am not sending
  unencrypted DNS queries to the (potentially hostile) local
  nameservers.

  This patch disappeared in an update. I think it was present in
  1.2.2-0ubuntu0.16.04.4 but was dropped some time later.

  This security bug exists upstream too: 
https://bugzilla.gnome.org/show_bug.cgi?id=746422
  It's not a *regression* there though, as they didn't fix it yet 
(unfortunately!)

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

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


[Touch-packages] [Bug 1748956] Re: replace uses of net-tools with iproute2

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package ubuntu-meta - 1.434

---
ubuntu-meta (1.434) eoan; urgency=medium

  * Refreshed dependencies
  * Added fwupd to server-recommends (LP: #1749774)
  * Removed net-tools from server (LP: #1748956)

 -- Christian Ehrhardt   Mon, 13 May
2019 12:08:01 +0200

** Changed in: ubuntu-meta (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  replace uses of net-tools with iproute2

Status in byobu:
  Fix Committed
Status in Release Notes for Ubuntu:
  Confirmed
Status in byobu package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released

Bug description:
  As ubuntu goes forward, net-tools is looking to be dropped.

  Byobu currently depends on net-tools.  That code should be replaced by
  iproute2.

  
  Related bugs:
   * bug 925145: cloud-init  Use ip instead of ifconfig and route

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: byobu 5.124-0ubuntu1
  ProcVersionSignature: Ubuntu 4.13.0-25.29-generic 4.13.13
  Uname: Linux 4.13.0-25-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu8
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 12 13:34:27 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (935 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: byobu
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1749774] Re: include fwupd packages in Server Seed

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package ubuntu-meta - 1.434

---
ubuntu-meta (1.434) eoan; urgency=medium

  * Refreshed dependencies
  * Added fwupd to server-recommends (LP: #1749774)
  * Removed net-tools from server (LP: #1748956)

 -- Christian Ehrhardt   Mon, 13 May
2019 12:08:01 +0200

** Changed in: ubuntu-meta (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  include fwupd packages in Server Seed

Status in ubuntu-meta package in Ubuntu:
  Fix Released

Bug description:
  fwupd is the closest we have to a standard mechanism currently for
  doing in-band firmware updates in a vendor agnostic way.  As long as
  the vendors provide firmware blobs in an appropriately formatted
  package, fwupd (or fwupdate) can install those firmware blobs from
  within Ubuntu.

  Because of this, we should include the related packages in the server
  seed.  The main components all live in Main currently.  As far as I
  can tell (verified on a Bionic install), nothing in the current server
  seed pulls in fwupd, fwupdate, or fwupdate-signed as a dependency.

  ubuntu@xwing:~$ apt-cache policy fwup*

  fwupdate:
Installed: (none)
Candidate: 10-2
Version table:
   10-2 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  fwupd:
Installed: (none)
Candidate: 1.0.4-3build1
Version table:
   1.0.4-3build1 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  fwupdate-signed:
Installed: (none)
Candidate: 1.17+10-2
Version table:
   1.17+10-2 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

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

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


[Touch-packages] [Bug 1781699] Re: DHCPv6 server crashes regularly (bionic)

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package isc-dhcp - 4.3.5-3ubuntu9.1

---
isc-dhcp (4.3.5-3ubuntu9.1) cosmic-security; urgency=medium

  * SECURITY UPDATE: DoS via change in bind behaviour (LP: #1781699)
- debian/patches/CVE-2019-6470.patch: use 0 instead of -1 to indicate
  empty heap index in includes/dhcpd.h, server/mdb6.c,
  server/tests/mdb6_unittest.c.
- CVE-2019-6470

 -- Marc Deslauriers   Mon, 06 May 2019
08:57:40 -0400

** Changed in: isc-dhcp (Ubuntu Cosmic)
   Status: In Progress => Fix Released

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

Title:
  DHCPv6 server crashes regularly (bionic)

Status in DHCP:
  Unknown
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Fix Released
Status in isc-dhcp source package in Cosmic:
  Fix Released
Status in isc-dhcp source package in Disco:
  Fix Released
Status in isc-dhcp source package in Eoan:
  Fix Released
Status in isc-dhcp package in Debian:
  New
Status in isc-dhcp package in Fedora:
  Unknown

Bug description:
  The isc-dhcp-server crashes regularly on bionic, sometimes directly after 
boot, sometimes later.
  The version installed is 4.3.5-3ubuntu7.

  journalctl shows:
  Jul 14 09:35:11  dhcpd[1543]: Solicit message from 
fe80::18eb:dfc7:17e5:c8d7 port 546, transaction ID 0x7E8EC00
  Jul 14 09:35:11  dhcpd[1543]: Advertise NA: address ::1998 
to client with duid 00:01:00:01:21:9f:3a:02:d4:a3:3d:bf:17:e9 iaid = 0 valid 
for 8
  Jul 14 09:35:11  dhcpd[1543]: Sending Advertise to 
fe80::18eb:dfc7:17e5:c8d7 port 546
  Jul 14 09:35:12  dhcpd[1543]: Request message from 
fe80::18eb:dfc7:17e5:c8d7 port 546, transaction ID 0x65FADB00
  Jul 14 09:35:12  dhcpd[1543]: Reply NA: address ::1998 to 
client with duid 00:01:00:01:21:9f:3a:02:d4:a3:3d:bf:17:e9 iaid = 0 valid for 
86400
  Jul 14 09:35:12  dhcpd[1543]: Sending Reply to 
fe80::18eb:dfc7:17e5:c8d7 port 546
  Jul 14 09:35:53  dhcpd[1543]: Confirm message from 
fe80::725a:b6ff:fea2:6120 port 546, transaction ID 0x5105F400
  Jul 14 09:35:53  dhcpd[1543]: Sending Reply to 
fe80::725a:b6ff:fea2:6120 port 546
  Jul 14 09:35:53  dhcpd[1543]: Rebind message from 
fe80::725a:b6ff:fea2:6120 port 546, transaction ID 0x1FEA7E00
  Jul 14 09:35:53  dhcpd[1543]: Reply NA: address ::1992 to 
client with duid 00:04:c2:47:10:e8:8b:dc:d4:a1:0a:1d:21:f2:be:20:e8:a0 iaid = 
-1230
  Jul 14 09:35:53  sh[1543]: ../../../lib/isc/heap.c:251: REQUIRE(idx 
>= 1 && idx <= heap->last) failed, back trace
  Jul 14 09:35:53  sh[1543]: #0 0x7efc458a6417 in ??
  Jul 14 09:35:53  sh[1543]: #1 0x7efc458a636a in ??
  Jul 14 09:35:53  sh[1543]: #2 0x7efc458ad4ea in ??
  Jul 14 09:35:53  sh[1543]: #3 0x55d9ee65d571 in ??
  Jul 14 09:35:53  sh[1543]: #4 0x55d9ee658701 in ??
  Jul 14 09:35:53  sh[1543]: #5 0x55d9ee65ab05 in ??
  Jul 14 09:35:53  sh[1543]: #6 0x55d9ee65bff3 in ??
  Jul 14 09:35:53  sh[1543]: #7 0x55d9ee65cafc in ??
  Jul 14 09:35:53  sh[1543]: #8 0x55d9ee678402 in ??
  Jul 14 09:35:53  sh[1543]: #9 0x55d9ee667463 in ??
  Jul 14 09:35:53  sh[1543]: #10 0x55d9ee696476 in ??
  Jul 14 09:35:53  sh[1543]: #11 0x7efc458dd73b in ??
  Jul 14 09:35:53  sh[1543]: #12 0x7efc458ccf9e in ??
  Jul 14 09:35:53  sh[1543]: #13 0x7efc458d1e60 in ??
  Jul 14 09:35:53  sh[1543]: #14 0x7efc458d2325 in ??
  Jul 14 09:35:53  sh[1543]: #15 0x55d9ee6696b0 in ??
  Jul 14 09:35:53  sh[1543]: #16 0x55d9ee61d519 in ??
  Jul 14 09:35:53  sh[1543]: #17 0x7efc454c6b97 in ??
  Jul 14 09:35:53  sh[1543]: #18 0x55d9ee61de0a in ??
  Jul 14 09:35:54  systemd[1]: isc-dhcp-server6.service: Main process 
exited, code=dumped, status=6/ABRT
  Jul 14 09:35:54  systemd[1]: isc-dhcp-server6.service: Failed with 
result 'core-dump'.

  The bug was reported to Debian independently, https://bugs.debian.org
  /cgi-bin/bugreport.cgi?bug=896122.

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

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


[Touch-packages] [Bug 1781699] Re: DHCPv6 server crashes regularly (bionic)

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package isc-dhcp - 4.3.5-3ubuntu7.1

---
isc-dhcp (4.3.5-3ubuntu7.1) bionic-security; urgency=medium

  * SECURITY UPDATE: DoS via change in bind behaviour (LP: #1781699)
- debian/patches/CVE-2019-6470.patch: use 0 instead of -1 to indicate
  empty heap index in includes/dhcpd.h, server/mdb6.c,
  server/tests/mdb6_unittest.c.
- CVE-2019-6470

 -- Marc Deslauriers   Mon, 06 May 2019
09:00:01 -0400

** Changed in: isc-dhcp (Ubuntu Bionic)
   Status: In Progress => Fix Released

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

Title:
  DHCPv6 server crashes regularly (bionic)

Status in DHCP:
  Unknown
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Fix Released
Status in isc-dhcp source package in Cosmic:
  In Progress
Status in isc-dhcp source package in Disco:
  Fix Released
Status in isc-dhcp source package in Eoan:
  Fix Released
Status in isc-dhcp package in Debian:
  New
Status in isc-dhcp package in Fedora:
  Unknown

Bug description:
  The isc-dhcp-server crashes regularly on bionic, sometimes directly after 
boot, sometimes later.
  The version installed is 4.3.5-3ubuntu7.

  journalctl shows:
  Jul 14 09:35:11  dhcpd[1543]: Solicit message from 
fe80::18eb:dfc7:17e5:c8d7 port 546, transaction ID 0x7E8EC00
  Jul 14 09:35:11  dhcpd[1543]: Advertise NA: address ::1998 
to client with duid 00:01:00:01:21:9f:3a:02:d4:a3:3d:bf:17:e9 iaid = 0 valid 
for 8
  Jul 14 09:35:11  dhcpd[1543]: Sending Advertise to 
fe80::18eb:dfc7:17e5:c8d7 port 546
  Jul 14 09:35:12  dhcpd[1543]: Request message from 
fe80::18eb:dfc7:17e5:c8d7 port 546, transaction ID 0x65FADB00
  Jul 14 09:35:12  dhcpd[1543]: Reply NA: address ::1998 to 
client with duid 00:01:00:01:21:9f:3a:02:d4:a3:3d:bf:17:e9 iaid = 0 valid for 
86400
  Jul 14 09:35:12  dhcpd[1543]: Sending Reply to 
fe80::18eb:dfc7:17e5:c8d7 port 546
  Jul 14 09:35:53  dhcpd[1543]: Confirm message from 
fe80::725a:b6ff:fea2:6120 port 546, transaction ID 0x5105F400
  Jul 14 09:35:53  dhcpd[1543]: Sending Reply to 
fe80::725a:b6ff:fea2:6120 port 546
  Jul 14 09:35:53  dhcpd[1543]: Rebind message from 
fe80::725a:b6ff:fea2:6120 port 546, transaction ID 0x1FEA7E00
  Jul 14 09:35:53  dhcpd[1543]: Reply NA: address ::1992 to 
client with duid 00:04:c2:47:10:e8:8b:dc:d4:a1:0a:1d:21:f2:be:20:e8:a0 iaid = 
-1230
  Jul 14 09:35:53  sh[1543]: ../../../lib/isc/heap.c:251: REQUIRE(idx 
>= 1 && idx <= heap->last) failed, back trace
  Jul 14 09:35:53  sh[1543]: #0 0x7efc458a6417 in ??
  Jul 14 09:35:53  sh[1543]: #1 0x7efc458a636a in ??
  Jul 14 09:35:53  sh[1543]: #2 0x7efc458ad4ea in ??
  Jul 14 09:35:53  sh[1543]: #3 0x55d9ee65d571 in ??
  Jul 14 09:35:53  sh[1543]: #4 0x55d9ee658701 in ??
  Jul 14 09:35:53  sh[1543]: #5 0x55d9ee65ab05 in ??
  Jul 14 09:35:53  sh[1543]: #6 0x55d9ee65bff3 in ??
  Jul 14 09:35:53  sh[1543]: #7 0x55d9ee65cafc in ??
  Jul 14 09:35:53  sh[1543]: #8 0x55d9ee678402 in ??
  Jul 14 09:35:53  sh[1543]: #9 0x55d9ee667463 in ??
  Jul 14 09:35:53  sh[1543]: #10 0x55d9ee696476 in ??
  Jul 14 09:35:53  sh[1543]: #11 0x7efc458dd73b in ??
  Jul 14 09:35:53  sh[1543]: #12 0x7efc458ccf9e in ??
  Jul 14 09:35:53  sh[1543]: #13 0x7efc458d1e60 in ??
  Jul 14 09:35:53  sh[1543]: #14 0x7efc458d2325 in ??
  Jul 14 09:35:53  sh[1543]: #15 0x55d9ee6696b0 in ??
  Jul 14 09:35:53  sh[1543]: #16 0x55d9ee61d519 in ??
  Jul 14 09:35:53  sh[1543]: #17 0x7efc454c6b97 in ??
  Jul 14 09:35:53  sh[1543]: #18 0x55d9ee61de0a in ??
  Jul 14 09:35:54  systemd[1]: isc-dhcp-server6.service: Main process 
exited, code=dumped, status=6/ABRT
  Jul 14 09:35:54  systemd[1]: isc-dhcp-server6.service: Failed with 
result 'core-dump'.

  The bug was reported to Debian independently, https://bugs.debian.org
  /cgi-bin/bugreport.cgi?bug=896122.

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

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


[Touch-packages] [Bug 1825946] Re: 'nm' autopkgtest fails due to GI stderr output

2019-05-13 Thread Dan Streetman
** Changed in: network-manager (Ubuntu Bionic)
 Assignee: Dan Streetman (ddstreet) => Till Kamppeter (till-kamppeter)

** Changed in: network-manager (Ubuntu Bionic)
   Status: In Progress => Fix Committed

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

Title:
  'nm' autopkgtest fails due to GI stderr output

Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Xenial:
  In Progress
Status in network-manager source package in Bionic:
  Fix Committed

Bug description:
  [impact]

  'nm' testcase contains:
  from gi.repository import NetworkManager, NMClient, GLib  


 

  which generates output to stderr:
  /tmp/autopkgtest.naU0ts/build.riU/src/debian/tests/nm:23: PyGIWarning: 
NetworkManager was imported without specifying a version first. Use 
gi.require_version('NetworkManager', '1.0') before import to ensure that the 
right version gets loaded.

  the gi.require_version call has already been added to cosmic and
  disco.

  [test case]

  see http://autopkgtest.ubuntu.com/packages/network-manager bionic test
  results.

  [other info]

  this only fails intermittently, but the failure is clearly not an
  actual problem.

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

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


[Touch-packages] [Bug 1828617] Re: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration

2019-05-13 Thread David A. Desrosiers
This manifests itself as the following, as reported by lsblk(1). Note
the missing Ceph LVM volume on the 6th NVME disk:

$ cat sos_commands/block/lsblk
NAME
  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda 
8:00  1.8T  0 disk 
|-sda1  
8:10  512M  0 part /boot/efi
`-sda2  
8:20  1.8T  0 part 
  |-foobar--vg-root 
 253:00  1.8T  0 lvm  /
  `-foobar--vg-swap_1   
 253:10  976M  0 lvm  [SWAP]
nvme0n1 
  259:00  1.8T  0 disk 
`-ceph--c576f63e--dfd4--48f7--9d60--6a7708cbccf6-osd--block--9fdd78b2--0745--47ae--b8d4--04d9803ab448
 253:60  1.8T  0 lvm  
nvme1n1 
  259:10  1.8T  0 disk 
`-ceph--6eb6565f--6392--44a8--9213--833b09f7c0bc-osd--block--a7d3629c--724f--4218--9d15--593ec64781da
 253:50  1.8T  0 lvm  
nvme2n1 
  259:20  1.8T  0 disk 
`-ceph--c14f9ee5--90d0--4306--9b18--99576516f76a-osd--block--bbf5bc79--edea--4e43--8414--b5140b409397
 253:40  1.8T  0 lvm  
nvme3n1 
  259:30  1.8T  0 disk 
`-ceph--a821146b--7674--4bcc--b5e9--0126c4bd5e3b-osd--block--b9371499--ff99--4d3e--ab3f--62ec3cf918c4
 253:30  1.8T  0 lvm  
nvme4n1 
  259:40  1.8T  0 disk 
`-ceph--2e39f75a--5d2a--49ee--beb1--5d0a2991fd6c-osd--block--a1be083e--1fa7--4397--acfa--2ff3d3491572
 253:20  1.8T  0 lvm  
nvme5n1 
  259:50  1.8T  0 disk

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

Title:
  Hosts randomly 'losing' disks, breaking ceph-osd service enumeration

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 18.04.2 Ceph deployment.

  Ceph OSD devices utilizing LVM volumes pointing to udev-based physical 
devices.
  LVM module is supposed to create PVs from devices using the links in 
/dev/disk/by-dname/ folder that are created by udev.
  However on reboot it happens (not always, rather like race condition) that 
Ceph services cannot start, and pvdisplay doesn't show any volumes created. The 
folder /dev/disk/by-dname/ however has all necessary device created by the end 
of boot process.

  The behaviour can be fixed manually by running "#/sbin/lvm pvscan
  --cache --activate ay /dev/nvme0n1" command for re-activating the LVM
  components and then the services can be started.

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

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


[Touch-packages] [Bug 1748956] Re: replace uses of net-tools with iproute2

2019-05-13 Thread Launchpad Bug Tracker
** Merge proposal linked:
   https://code.launchpad.net/~xnox/ubuntu-seeds/+git/ubuntu-seeds/+merge/367347

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

Title:
  replace uses of net-tools with iproute2

Status in byobu:
  Fix Committed
Status in Release Notes for Ubuntu:
  Confirmed
Status in byobu package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Triaged

Bug description:
  As ubuntu goes forward, net-tools is looking to be dropped.

  Byobu currently depends on net-tools.  That code should be replaced by
  iproute2.

  
  Related bugs:
   * bug 925145: cloud-init  Use ip instead of ifconfig and route

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: byobu 5.124-0ubuntu1
  ProcVersionSignature: Ubuntu 4.13.0-25.29-generic 4.13.13
  Uname: Linux 4.13.0-25-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu8
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 12 13:34:27 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (935 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: byobu
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le

2019-05-13 Thread Sebastien Bacher
** Changed in: udisks2 (Ubuntu Eoan)
   Importance: Undecided => High

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

Title:
  storage / luks / dmsetup regressed (or got better) on ppc64le

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in udisks2 package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in udisks2 source package in Bionic:
  New
Status in linux source package in Disco:
  New
Status in systemd source package in Disco:
  New
Status in udisks2 source package in Disco:
  New
Status in linux source package in Eoan:
  Confirmed
Status in systemd source package in Eoan:
  New
Status in udisks2 source package in Eoan:
  New

Bug description:
  in disco proposed with new systemd and v4.19 kernel it appears that
  dmsetup / cryptsetup storage either got better or worse.

  Devices take very long to activate, and sometimes remain in use during
  test clean up.

  This leads to udisks autopkgtest failing on ppc64le and systemd's
  "storage" autopkgtest is also failing.

  I've tried to make ppc64le test more resilient, but it's still odd
  that it became unstable in disco, and used to be rock solid on
  ppc64le.

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

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


[Touch-packages] [Bug 1828617] Re: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration

2019-05-13 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

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

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

Title:
  Hosts randomly 'losing' disks, breaking ceph-osd service enumeration

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 18.04.2 Ceph deployment.

  Ceph OSD devices utilizing LVM volumes pointing to udev-based physical 
devices.
  LVM module is supposed to create PVs from devices using the links in 
/dev/disk/by-dname/ folder that are created by udev.
  However on reboot it happens (not always, rather like race condition) that 
Ceph services cannot start, and pvdisplay doesn't show any volumes created. The 
folder /dev/disk/by-dname/ however has all necessary device created by the end 
of boot process.

  The behaviour can be fixed manually by running "#/sbin/lvm pvscan
  --cache --activate ay /dev/nvme0n1" command for re-activating the LVM
  components and then the services can be started.

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

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


[Touch-packages] [Bug 520546] Please test proposed package

2019-05-13 Thread Łukasz Zemczak
Hello David, or anyone else affected,

Accepted kbd into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/kbd/1.15.5-1ubuntu5.16.04.0 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT
  switch from Alt+Left/Right

Status in console-setup package in Ubuntu:
  Fix Released
Status in kbd package in Ubuntu:
  Fix Released
Status in xorg-server package in Ubuntu:
  Invalid
Status in console-setup source package in Xenial:
  Confirmed
Status in kbd source package in Xenial:
  Fix Committed
Status in xorg-server source package in Xenial:
  Confirmed
Status in console-setup source package in Bionic:
  Fix Released
Status in kbd source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Confirmed
Status in xorg-server source package in Bionic:
  Invalid
Status in console-setup source package in Cosmic:
  Fix Released
Status in kbd source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Confirmed
Status in xorg-server source package in Cosmic:
  Invalid
Status in console-setup source package in Disco:
  Fix Released
Status in kbd source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Confirmed
Status in xorg-server source package in Disco:
  Invalid
Status in console-setup source package in Eoan:
  Fix Released
Status in kbd source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Confirmed
Status in xorg-server source package in Eoan:
  Invalid

Bug description:
  (kbd)
  [Impact]

   * kbd_mode -u is documented to break keyboards in modes other than xlate and 
unicode, while it is still called by some scripts. Those scripts are called 
transitively by maintainer scripts such as the one already fixed in 
console-setup. 
   * To avoid accidentally breaking keyboards a -f option is added to force 
such breaking mode changes. Without -f only the safe mode changes are performed 
and an error is printed when the requested mode change is not safe. Next 
upstream version will also exit with error, but the cherry-picked fix makes 
kbd_mode return success even when the mode switch is not performed to avoid 
regressions of scripts.

  [Test case]

   * Verify that safe mode switches work and dangerous ones are skipped
  without -f. Please note that the test will temporarily break the
  system's keyboard and it is recommended to run the test in a VM.

  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4; echo $?
  The keyboard is in Unicode (UTF-8) mode
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in xlate (8-bit) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in some unknown mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -f -u -C /dev/tty0; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -s -C /dev/tty0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in raw (scancode) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in raw (scancode) mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0

  [Regression Potential]

   * kbd_mode stops performing 

[Touch-packages] [Bug 520546] Please test proposed package

2019-05-13 Thread Łukasz Zemczak
Hello David, or anyone else affected,

Accepted kbd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/kbd/2.0.4-2ubuntu1.18.04.0 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: kbd (Ubuntu Xenial)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed-xenial

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

Title:
  Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT
  switch from Alt+Left/Right

Status in console-setup package in Ubuntu:
  Fix Released
Status in kbd package in Ubuntu:
  Fix Released
Status in xorg-server package in Ubuntu:
  Invalid
Status in console-setup source package in Xenial:
  Confirmed
Status in kbd source package in Xenial:
  Fix Committed
Status in xorg-server source package in Xenial:
  Confirmed
Status in console-setup source package in Bionic:
  Fix Released
Status in kbd source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Confirmed
Status in xorg-server source package in Bionic:
  Invalid
Status in console-setup source package in Cosmic:
  Fix Released
Status in kbd source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Confirmed
Status in xorg-server source package in Cosmic:
  Invalid
Status in console-setup source package in Disco:
  Fix Released
Status in kbd source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Confirmed
Status in xorg-server source package in Disco:
  Invalid
Status in console-setup source package in Eoan:
  Fix Released
Status in kbd source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Confirmed
Status in xorg-server source package in Eoan:
  Invalid

Bug description:
  (kbd)
  [Impact]

   * kbd_mode -u is documented to break keyboards in modes other than xlate and 
unicode, while it is still called by some scripts. Those scripts are called 
transitively by maintainer scripts such as the one already fixed in 
console-setup. 
   * To avoid accidentally breaking keyboards a -f option is added to force 
such breaking mode changes. Without -f only the safe mode changes are performed 
and an error is printed when the requested mode change is not safe. Next 
upstream version will also exit with error, but the cherry-picked fix makes 
kbd_mode return success even when the mode switch is not performed to avoid 
regressions of scripts.

  [Test case]

   * Verify that safe mode switches work and dangerous ones are skipped
  without -f. Please note that the test will temporarily break the
  system's keyboard and it is recommended to run the test in a VM.

  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4; echo $?
  The keyboard is in Unicode (UTF-8) mode
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in xlate (8-bit) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in some unknown mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -f -u -C /dev/tty0; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -s -C /dev/tty0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in raw (scancode) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in raw (scancode) mode
  Changing to the requested mode may make your 

[Touch-packages] [Bug 520546] Re: Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT switch from Alt+Left/Right

2019-05-13 Thread Łukasz Zemczak
Hello David, or anyone else affected,

Accepted kbd into cosmic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/kbd/2.0.4-2ubuntu1.18.10.0 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-cosmic to verification-done-cosmic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-cosmic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: kbd (Ubuntu Cosmic)
   Status: Confirmed => Fix Committed

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

** Changed in: kbd (Ubuntu Bionic)
   Status: Confirmed => Fix Committed

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

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

Title:
  Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT
  switch from Alt+Left/Right

Status in console-setup package in Ubuntu:
  Fix Released
Status in kbd package in Ubuntu:
  Fix Released
Status in xorg-server package in Ubuntu:
  Invalid
Status in console-setup source package in Xenial:
  Confirmed
Status in kbd source package in Xenial:
  Fix Committed
Status in xorg-server source package in Xenial:
  Confirmed
Status in console-setup source package in Bionic:
  Fix Released
Status in kbd source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Confirmed
Status in xorg-server source package in Bionic:
  Invalid
Status in console-setup source package in Cosmic:
  Fix Released
Status in kbd source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Confirmed
Status in xorg-server source package in Cosmic:
  Invalid
Status in console-setup source package in Disco:
  Fix Released
Status in kbd source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Confirmed
Status in xorg-server source package in Disco:
  Invalid
Status in console-setup source package in Eoan:
  Fix Released
Status in kbd source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Confirmed
Status in xorg-server source package in Eoan:
  Invalid

Bug description:
  (kbd)
  [Impact]

   * kbd_mode -u is documented to break keyboards in modes other than xlate and 
unicode, while it is still called by some scripts. Those scripts are called 
transitively by maintainer scripts such as the one already fixed in 
console-setup. 
   * To avoid accidentally breaking keyboards a -f option is added to force 
such breaking mode changes. Without -f only the safe mode changes are performed 
and an error is printed when the requested mode change is not safe. Next 
upstream version will also exit with error, but the cherry-picked fix makes 
kbd_mode return success even when the mode switch is not performed to avoid 
regressions of scripts.

  [Test case]

   * Verify that safe mode switches work and dangerous ones are skipped
  without -f. Please note that the test will temporarily break the
  system's keyboard and it is recommended to run the test in a VM.

  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4; echo $?
  The keyboard is in Unicode (UTF-8) mode
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in xlate (8-bit) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in some unknown mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -f -u -C /dev/tty0; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -s -C /dev/tty0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C 

[Touch-packages] [Bug 520546] Please test proposed package

2019-05-13 Thread Łukasz Zemczak
Hello David, or anyone else affected,

Accepted kbd into disco-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/kbd/2.0.4-4ubuntu1.19.04.0 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-disco to verification-done-disco. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-disco. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT
  switch from Alt+Left/Right

Status in console-setup package in Ubuntu:
  Fix Released
Status in kbd package in Ubuntu:
  Fix Released
Status in xorg-server package in Ubuntu:
  Invalid
Status in console-setup source package in Xenial:
  Confirmed
Status in kbd source package in Xenial:
  Fix Committed
Status in xorg-server source package in Xenial:
  Confirmed
Status in console-setup source package in Bionic:
  Fix Released
Status in kbd source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Confirmed
Status in xorg-server source package in Bionic:
  Invalid
Status in console-setup source package in Cosmic:
  Fix Released
Status in kbd source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Confirmed
Status in xorg-server source package in Cosmic:
  Invalid
Status in console-setup source package in Disco:
  Fix Released
Status in kbd source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Confirmed
Status in xorg-server source package in Disco:
  Invalid
Status in console-setup source package in Eoan:
  Fix Released
Status in kbd source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Confirmed
Status in xorg-server source package in Eoan:
  Invalid

Bug description:
  (kbd)
  [Impact]

   * kbd_mode -u is documented to break keyboards in modes other than xlate and 
unicode, while it is still called by some scripts. Those scripts are called 
transitively by maintainer scripts such as the one already fixed in 
console-setup. 
   * To avoid accidentally breaking keyboards a -f option is added to force 
such breaking mode changes. Without -f only the safe mode changes are performed 
and an error is printed when the requested mode change is not safe. Next 
upstream version will also exit with error, but the cherry-picked fix makes 
kbd_mode return success even when the mode switch is not performed to avoid 
regressions of scripts.

  [Test case]

   * Verify that safe mode switches work and dangerous ones are skipped
  without -f. Please note that the test will temporarily break the
  system's keyboard and it is recommended to run the test in a VM.

  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4; echo $?
  The keyboard is in Unicode (UTF-8) mode
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in xlate (8-bit) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in some unknown mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -f -u -C /dev/tty0; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -s -C /dev/tty0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in raw (scancode) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in raw (scancode) mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0

  [Regression Potential]

   * kbd_mode stops performing 

[Touch-packages] [Bug 520546] Re: Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT switch from Alt+Left/Right

2019-05-13 Thread Łukasz Zemczak
I see that the kbd changes didn't really get reviewed upstream yet,
right? Anyway, the change is a bit intrusive, but it does make sense
(especially with the additional patch of not erroring out), so I will
accept it for now at least into -proposed.

** Changed in: kbd (Ubuntu Disco)
   Status: Confirmed => Fix Committed

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

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

Title:
  Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT
  switch from Alt+Left/Right

Status in console-setup package in Ubuntu:
  Fix Released
Status in kbd package in Ubuntu:
  Fix Released
Status in xorg-server package in Ubuntu:
  Invalid
Status in console-setup source package in Xenial:
  Confirmed
Status in kbd source package in Xenial:
  Fix Committed
Status in xorg-server source package in Xenial:
  Confirmed
Status in console-setup source package in Bionic:
  Fix Released
Status in kbd source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Confirmed
Status in xorg-server source package in Bionic:
  Invalid
Status in console-setup source package in Cosmic:
  Fix Released
Status in kbd source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Confirmed
Status in xorg-server source package in Cosmic:
  Invalid
Status in console-setup source package in Disco:
  Fix Released
Status in kbd source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Confirmed
Status in xorg-server source package in Disco:
  Invalid
Status in console-setup source package in Eoan:
  Fix Released
Status in kbd source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Confirmed
Status in xorg-server source package in Eoan:
  Invalid

Bug description:
  (kbd)
  [Impact]

   * kbd_mode -u is documented to break keyboards in modes other than xlate and 
unicode, while it is still called by some scripts. Those scripts are called 
transitively by maintainer scripts such as the one already fixed in 
console-setup. 
   * To avoid accidentally breaking keyboards a -f option is added to force 
such breaking mode changes. Without -f only the safe mode changes are performed 
and an error is printed when the requested mode change is not safe. Next 
upstream version will also exit with error, but the cherry-picked fix makes 
kbd_mode return success even when the mode switch is not performed to avoid 
regressions of scripts.

  [Test case]

   * Verify that safe mode switches work and dangerous ones are skipped
  without -f. Please note that the test will temporarily break the
  system's keyboard and it is recommended to run the test in a VM.

  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4; echo $?
  The keyboard is in Unicode (UTF-8) mode
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -a -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in xlate (8-bit) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty4; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty4
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in some unknown mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -f -u -C /dev/tty0; echo $?
  0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in Unicode (UTF-8) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -s -C /dev/tty0
  rbalint@MacBookAir-test:~$ sudo kbd_mode -C /dev/tty0
  The keyboard is in raw (scancode) mode
  rbalint@MacBookAir-test:~$ sudo kbd_mode -u -C /dev/tty0; echo $?
  The keyboard is in raw (scancode) mode
  Changing to the requested mode may make your keyboard unusable, please use -f 
to force the change.
  0

  [Regression Potential]

   * kbd_mode stops performing breaking mode switches and this may make
  scripts ineffective when trying to perform a breaking change. This is
  the intention of the change and the emitter error helps in finding the
  offending script.

  The following packages found to call kbd_mode directly:
  console-setup
  xinit
  console-cyrillic
  initramfs-tools
  dracut
  console-tools
  xview
  ubiquity's embedded console-setup copy
  console-data
  vnc4

  The console related packages are expected to execute only safe mode
  changes because they should operate on consoles only and the rest seem
  to be safe, too.

  (console-setup)
  [Impact]

   * keyboard-configuration's postinst changes keyboard mode breaking X
  keys.

  [Test Case]

   * Ssh to a system or open a terminal and unset 

[Touch-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le

2019-05-13 Thread Thadeu Lima de Souza Cascardo
After applying the two fixes, I managed to get the test running on a
loop for more than 24 hours on disco. Will review the case with someone
on the team before attaching the fix.

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

Title:
  storage / luks / dmsetup regressed (or got better) on ppc64le

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in udisks2 package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in udisks2 source package in Bionic:
  New
Status in linux source package in Disco:
  New
Status in systemd source package in Disco:
  New
Status in udisks2 source package in Disco:
  New
Status in linux source package in Eoan:
  Confirmed
Status in systemd source package in Eoan:
  New
Status in udisks2 source package in Eoan:
  New

Bug description:
  in disco proposed with new systemd and v4.19 kernel it appears that
  dmsetup / cryptsetup storage either got better or worse.

  Devices take very long to activate, and sometimes remain in use during
  test clean up.

  This leads to udisks autopkgtest failing on ppc64le and systemd's
  "storage" autopkgtest is also failing.

  I've tried to make ppc64le test more resilient, but it's still odd
  that it became unstable in disco, and used to be rock solid on
  ppc64le.

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

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


[Touch-packages] [Bug 1828685] Re: openssh-server will not start at boot if ListenAddress is set to an address delivered by radvd

2019-05-13 Thread Jean-Marie Delapierre
** Description changed:

  The /etc/systemd/system/sshd.service file does not request radvd (if
  installed).
  
  If one sets ListenAddress to the interface address set by radvd,
  openssh-server crashes at boot time because there is no address affected
  to the interface.
  
  A subsequent "sudo systemctl start ssh.service" works fine.
  
  ProblemType: Bug
- DistroRelease: Ubuntu 19.04
- Package: openssh-server (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
+ DistroRelease: Ubuntu 18.04 minimal
+ Package: openssh-server
+ ProcVersionSignature: Ubuntu 4.15.0-48-generic
+ Uname: Linux 4.15.0-48-generic x86_64
  Architecture: amd64
- CurrentDesktop: ubuntu:GNOME
+ CurrentDesktop: server (no desktop)
  Date: Sat May 11 18:50:54 2019
  InstallationDate: Installed on 2019-01-07 (124 days ago)
- InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
- SourcePackage: openssh
- UpgradeStatus: Upgraded to disco on 2019-04-19 (22 days ago)
+ InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 Minimal
+ SourcePackage: openssh-server

** Description changed:

  The /etc/systemd/system/sshd.service file does not request radvd (if
  installed).
  
- If one sets ListenAddress to the interface address set by radvd,
- openssh-server crashes at boot time because there is no address affected
- to the interface.
+ In /etc/ssh/sshd_config, if one sets ListenAddress to the interface
+ address set by radvd, openssh-server crashes at boot time because there
+ is no address affected to the interface.
  
- A subsequent "sudo systemctl start ssh.service" works fine.
+ A subsequent "sudo systemctl start sshd.service" works fine.
  
  ProblemType: Bug
- DistroRelease: Ubuntu 18.04 minimal
- Package: openssh-server
- ProcVersionSignature: Ubuntu 4.15.0-48-generic
- Uname: Linux 4.15.0-48-generic x86_64
+ DistroRelease: Ubuntu 19.04
+ Package: openssh-server (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
- CurrentDesktop: server (no desktop)
+ CurrentDesktop: ubuntu:GNOME
  Date: Sat May 11 18:50:54 2019
  InstallationDate: Installed on 2019-01-07 (124 days ago)
- InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 Minimal
- SourcePackage: openssh-server
+ InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
+ SourcePackage: openssh
+ UpgradeStatus: Upgraded to disco on 2019-04-19 (22 days ago)

** Description changed:

  The /etc/systemd/system/sshd.service file does not request radvd (if
  installed).
  
  In /etc/ssh/sshd_config, if one sets ListenAddress to the interface
  address set by radvd, openssh-server crashes at boot time because there
  is no address affected to the interface.
  
  A subsequent "sudo systemctl start sshd.service" works fine.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: openssh-server (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
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May 11 18:50:54 2019
- InstallationDate: Installed on 2019-01-07 (124 days ago)
+ InstallationDate: Installed on 2019-05-07 (6 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: openssh
- UpgradeStatus: Upgraded to disco on 2019-04-19 (22 days ago)

** Description changed:

  The /etc/systemd/system/sshd.service file does not request radvd (if
  installed).
  
  In /etc/ssh/sshd_config, if one sets ListenAddress to the interface
  address set by radvd, openssh-server crashes at boot time because there
  is no address affected to the interface.
  
  A subsequent "sudo systemctl start sshd.service" works fine.
  
  ProblemType: Bug
- DistroRelease: Ubuntu 19.04
+ DistroRelease: Ubuntu 18.04
  Package: openssh-server (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
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May 11 18:50:54 2019
  InstallationDate: Installed on 2019-05-07 (6 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: openssh

** Description changed:

  The /etc/systemd/system/sshd.service file does not request radvd (if
  installed).
  
  In /etc/ssh/sshd_config, if one sets ListenAddress to the interface
  address set by radvd, openssh-server crashes at boot time because there
  is no address affected to the interface.
  
  A subsequent "sudo systemctl start sshd.service" works fine.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
- Package: openssh-server (not installed)
+ Package: openssh-server
  ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 

[Touch-packages] [Bug 1828282] Re: busybox 1.30.1 crashes bzip2 test case with glibc 2.29, always

2019-05-13 Thread Dimitri John Ledkov
Will do! thanks for digging into this even though it's well, busybox
issue.

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

Title:
  busybox 1.30.1 crashes bzip2 test case with glibc 2.29, always

Status in Ubuntu on IBM z Systems:
  New
Status in busybox package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  New

Bug description:
  Steps to reproduce:

  1) Get a system with glibc 2.29

  2) Get busybox 1.30.1 installed (e.g. eoan, or download busybox
  package from
  https://launchpad.net/ubuntu/+source/busybox/1:1.30.1-4ubuntu3/+build/16724246
  and use $ apt install ./busybox*.deb to install)

  3) Get busybox 1.30.1 source code, e.g. $ pull-lp-source busybox
  Or like download the orig tarball from 
https://launchpad.net/ubuntu/+source/busybox/1:1.30.1-4ubuntu3

  4) Run the bunzip2 testsuite:

  cd testsuite/
  ECHO=/bin/echo ./bunzip2.tests

  Observe that with glibc 2.29 the:
  PASS: bunzip2: bz2_issue_11.bz2 corrupted example

  is XFAIL or FAIL, on s390x, whereas it passes on all other arches.

  If one uses glibc 2.28 (ie. use Cosmic, and install busybox & use
  matching test suite from eoan using links above) one can observe that
  the testcase always passes.

  We suspect this might be a glibc 2.29 s390x-specific setjmp
  regression. Probably due to setjmp usage in
  ./archival/libarchive/decompress_bunzip2.c

  The tests were done on a z13 machine.

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

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


[Touch-packages] [Bug 1828282] Comment bridged from LTC Bugzilla

2019-05-13 Thread bugproxy
--- Comment From s...@de.ibm.com 2019-05-13 07:27 EDT---
Hi xnox,

this issue has nothing todo with an issue in s390x specific setjmp/longjmp 
implementation!
Setjmp/longjmp is just used for error handling inside bunzip2 implementation in 
busybox!
But due to an issue in busybox implementation, longjmp is called on s390x but 
not on e.g. x86.
Please report this bug to busybox with the detailed information below!

According to bunzip2.tests:
bunzip2: bunzip error -5 => PASS
bunzip2: bunzip error -3 => XFAIL

As side note:
Error -3 also occures on s390x Ubuntu 18.04.2 LTS!

According to archival/libarchive/decompress_bunzip2.c:
62#define RETVAL_UNEXPECTED_INPUT_EOF (dbg("%d", __LINE__), -3)
64#define RETVAL_DATA_ERROR   (dbg("%d", __LINE__), -5)

RETVAL_UNEXPECTED_INPUT_EOF is used only in get_bits():
128bd->inbufCount = read(bd->in_fd, bd->inbuf, 
IOBUF_SIZE);
129if (bd->inbufCount <= 0)
130longjmp(*bd->jmpbuf, 
RETVAL_UNEXPECTED_INPUT_EOF);
If you start gdb and set a breakpoint there ...:
busybox-1.30.1/testsuite$ gdb ../busybox_unstripped
(gdb) b decompress_bunzip2.c:130
(gdb) run bunzip2 &1 >/dev/null
... it will be hit, bd->inbufCount will be zero and the longjmp jumps back to 
setjmp in unpack_bz2_stream().
i will be -3 and "bunzip error -3" will be reported.:
788i = setjmp(jmpbuf);
789if (i == 0)
790i = start_bunzip(, , xstate->src_fd, 
outbuf + 2, len);
791
792if (i == 0) {
793while (1) { /* "Produce some output bytes" loop */
794i = read_bunzip(bd, outbuf, IOBUF_SIZE);
795if (i < 0) /* error? */
796break;
...
808if (i != RETVAL_LAST_BLOCK
809/* Observed case when i == RETVAL_OK:
810 * "bzcat z.bz2", where "z.bz2" is a bzipped zero-length file
811 * (to be exact, z.bz2 is exactly these 14 bytes:
812 * 42 5a 68 39 17 72 45 38 50 90 00 00 00 00).
813 */
814 && i != RETVAL_OK
815) {
816bb_error_msg("bunzip error %d", i);
817break;
818}

The difference between reporting -5 or -3 depends on uninitialized values on 
the stack while calling read_bunzip()->get_next_block().
There you have the array mtfSymbol on stack:
156/* Unpacks the next block and sets up for the inverse Burrows-Wheeler step. 
*/
157static int get_next_block(bunzip_data *bd)
158{
159int groupCount, selector,
160i, j, symCount, symTotal, nSelectors, byteCount[256];
161uint8_t uc, symToByte[256], mtfSymbol[256], *selectors;
...

The groupCount is read and values in mtfSymbol are initialized:
...
219/* How many different Huffman coding groups does this block use? */
220groupCount = get_bits(bd, 3);
221if (groupCount < 2 || groupCount > MAX_GROUPS)
222return RETVAL_DATA_ERROR;
...
228for (i = 0; i < groupCount; i++)
229mtfSymbol[i] = i;
...
=> In the relevant case, groupCount == 6 and mtfSymbol[0..5] are initialized to 
0..5.

For each selector, the group (see variable n) is determined
and tmp_byte is set to the value of mtfSymbol[n]:
233for (i = 0; i < nSelectors; i++) {
234uint8_t tmp_byte;
235/* Get next value */
236int n = 0;
237while (get_bits(bd, 1)) {
=> For each "1" bit, n is incremented. Unfortunately the "too-large" check is 
done before incrementing n!!!
If the "n++" line is moved before the check, then the bz2_issue_11.bz2 testcase 
passes also on s390x!
238if (n >= groupCount)
239return RETVAL_DATA_ERROR;
240n++;
241}
242/* Decode MTF to get the next selector */
243tmp_byte = mtfSymbol[n];
=> In this testcase, for selector i==395, n is 6 and the uninitialized value of 
mtfSymbol[6] is first stored to tmp_byte and afterwards to selectors[395] 
although groupCount == 6!
(Note: there is also an commented out check which would return -5!)
244while (--n >= 0)
245mtfSymbol[n + 1] = mtfSymbol[n];
246//We catch it later, in the second loop where we use selectors[i].
247//Maybe this is a better place, though?
248//  if (tmp_byte >= groupCount) {
249//  dbg("%d: selectors[%d]:%d groupCount:%d",
250//  __LINE__, i, tmp_byte, groupCount);
251//  return RETVAL_DATA_ERROR;
252//  }
253mtfSymbol[0] = selectors[i] = tmp_byte;
254}
=> Note: on the s390x case, selectors[395] == 0 whereas on x86 it was 

[Touch-packages] [Bug 1826870] Re: cache.commit() doesn't release the archives lock

2019-05-13 Thread Julian Andres Klode
xenial:
- ubuntu-make not a regression, same bug as before
- apport retried
- snapcraft not a regression, same issues as before

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

Title:
  cache.commit() doesn't release the archives lock

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Cosmic:
  Fix Released
Status in python-apt package in Debian:
  Fix Released

Bug description:
  [Impact]
  cache.commit() does not release all the locks it acquires as part of 
committing. This is a regression of locking fixes in bug 1795407.

  [Test case]
  This script should work:

  #!/usr/bin/env python
  import apt
  import subprocess

  cache = apt.Cache()
  pkg = cache["hello"]
  pkg.mark_install()
  cache.commit()
  subprocess.check_call(["apt", "remove", "--yes", "hello"])

  [Regression potential]
  Other new locking bugs could pop up

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

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


[Touch-packages] [Bug 1826870] Re: cache.commit() doesn't release the archives lock

2019-05-13 Thread Łukasz Zemczak
Both the bionic and xenial uploads seems to have a few ADT regressions -
could you take at those and see if they're not regressions? Thanks!

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

Title:
  cache.commit() doesn't release the archives lock

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Cosmic:
  Fix Released
Status in python-apt package in Debian:
  Fix Released

Bug description:
  [Impact]
  cache.commit() does not release all the locks it acquires as part of 
committing. This is a regression of locking fixes in bug 1795407.

  [Test case]
  This script should work:

  #!/usr/bin/env python
  import apt
  import subprocess

  cache = apt.Cache()
  pkg = cache["hello"]
  pkg.mark_install()
  cache.commit()
  subprocess.check_call(["apt", "remove", "--yes", "hello"])

  [Regression potential]
  Other new locking bugs could pop up

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

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


[Touch-packages] [Bug 1826870] Update Released

2019-05-13 Thread Łukasz Zemczak
The verification of the Stable Release Update for python-apt has
completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  cache.commit() doesn't release the archives lock

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Cosmic:
  Fix Released
Status in python-apt package in Debian:
  Fix Released

Bug description:
  [Impact]
  cache.commit() does not release all the locks it acquires as part of 
committing. This is a regression of locking fixes in bug 1795407.

  [Test case]
  This script should work:

  #!/usr/bin/env python
  import apt
  import subprocess

  cache = apt.Cache()
  pkg = cache["hello"]
  pkg.mark_install()
  cache.commit()
  subprocess.check_call(["apt", "remove", "--yes", "hello"])

  [Regression potential]
  Other new locking bugs could pop up

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

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


[Touch-packages] [Bug 1826870] Re: cache.commit() doesn't release the archives lock

2019-05-13 Thread Launchpad Bug Tracker
This bug was fixed in the package python-apt - 1.7.1

---
python-apt (1.7.1) cosmic; urgency=medium

  * apt.Cache: Fix (un)locking of archives (Closes: #922416) (LP: #1826870)
  * apt.Cache: Use explicit, more safe locking in update()
  * Update mirror lists

 -- Julian Andres Klode   Mon, 29 Apr 2019 13:44:16
+0200

** Changed in: python-apt (Ubuntu Cosmic)
   Status: Fix Committed => Fix Released

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

Title:
  cache.commit() doesn't release the archives lock

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Cosmic:
  Fix Released
Status in python-apt package in Debian:
  Fix Released

Bug description:
  [Impact]
  cache.commit() does not release all the locks it acquires as part of 
committing. This is a regression of locking fixes in bug 1795407.

  [Test case]
  This script should work:

  #!/usr/bin/env python
  import apt
  import subprocess

  cache = apt.Cache()
  pkg = cache["hello"]
  pkg.mark_install()
  cache.commit()
  subprocess.check_call(["apt", "remove", "--yes", "hello"])

  [Regression potential]
  Other new locking bugs could pop up

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

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


[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd

2019-05-13 Thread Łukasz Zemczak
Some of the cups SRUs have some ADT failures reported for them, but from
what I see most are just testbed/infrastructure issues. I have re-ran
the tests for now - let's look into releasing this later today once the
re-runs are finished.

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

Title:
  Race condition on boot between cups and sssd

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

Bug description:
  [Impact]

   * When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist.

   * The patch adds an "After=sssd.service" clause to the service unit
  file.

  [Test Case]

   * Configure an external authentication service (LDAP, AD...) and
  create a group, for instance "lpadmins@tests.local"

   * Set SystemGroup to match that group in /etc/cups/cups-files.conf:
  SystemGroup lpadmins@tests.local

   * Reboot

   * If cups has started before sssd has finished booting, cups will crash:
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.

   * If cups starts after sssd, it will work fine.

  [Regression Potential]

   * Minimal: this patch affects just the ordering of the service unit
  file.

  [Other Info]

   * Upstream:
  https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d

  [Original description]

  When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist. For instance, with a
  group named lpadmins@tests.local served from Active Directory through
  sssd, if the sssd service hasn't booted before cups:

  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read 
"/etc/cups/cups-files.conf" due to errors.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, 
code=exited, status=1/FAILURE
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 
'exit-code'.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time 
over, scheduling restart.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, 
restart counter is at 2.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers 
available locally...
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler.

  If sssd is running before cups starts, everything works as expected.

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

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


[Touch-packages] [Bug 1828218] Re: boeug

2019-05-13 Thread Daniel van Vugt
Thank you for taking the time to report this bug and helping to make
Ubuntu better. Unfortunately, we cannot work on this bug because your
description didn't include enough information. You may find it helpful
to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at
http://wiki.ubuntu.com/DebuggingProcedures.

At a minimum, we need:
1. The specific steps or actions you took that caused you to encounter the 
problem.
2. The behavior you expected. 
3. The behavior you actually encountered (in as much detail as possible).
Thanks!

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

** Changed in: ubuntu
   Status: New => Incomplete

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

Title:
  boeug

Status in Ubuntu:
  Incomplete

Bug description:
  l'ecran seiltiller et sauter aucune action possible

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: xorg 1:7.7+19ubuntu8
  ProcVersionSignature: Ubuntu 4.15.0-1030.35-oem 4.15.18
  Uname: Linux 4.15.0-1030-oem x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Wed May  8 14:07:10 2019
  DistUpgraded: 2018-12-01 19:20:26,688 ERROR got error from PostInstallScript 
./xorg_fix_proprietary.py (g-exec-error-quark: L’exécution du processus fils « 
./xorg_fix_proprietary.py » a échoué (Aucun fichier ou dossier de ce type) (8))
  DistributionChannelDescriptor:
   # This is a distribution channel descriptor
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-xenial-amd64-osp1-20171027-1
  DistroCodename: cosmic
  DistroVariant: ubuntu
  DpkgLog:
   
  GraphicsCard:
   Intel Corporation Device [8086:3e9b] (prog-if 00 [VGA controller])
 Subsystem: Dell Device [1028:0870]
  InstallationDate: Installed on 2018-11-14 (174 days ago)
  InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 
20171027-10:57
  MachineType: Dell Inc. G3 3779
  ProcEnviron:
   PATH=(custom, no user)
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1030-oem 
root=UUID=4a3ac732-314e-4b02-a764-e7333473d040 ro acpi_osi=Linux-Dell-Video 
acpi_osi=Linux-Dell-Video acpi_osi=Linux-Dell-Video acpi_osi=Linux-Dell-Video 
quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to cosmic on 2018-12-01 (157 days ago)
  dmi.bios.date: 07/18/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.2.1
  dmi.board.name: 0NY03M
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd07/18/2018:svnDellInc.:pnG33779:pvr:rvnDellInc.:rn0NY03M:rvrA00:cvnDellInc.:ct10:cvr:
  dmi.product.family: GSeries
  dmi.product.name: G3 3779
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz 1:0.9.13.1+18.10.20180930-0ubuntu1
  version.libdrm2: libdrm2 2.4.95-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.2-0ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.2-0ubuntu1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.1-3ubuntu2.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1ubuntu1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-3

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

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