[Touch-packages] [Bug 1791405]

2019-05-28 Thread bcotton
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

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

Title:
  bluetooth always in discoverable mode (security issue)

Status in bluez package in Ubuntu:
  New
Status in gnome-bluetooth package in Ubuntu:
  Fix Released
Status in bluez source package in Bionic:
  New
Status in gnome-bluetooth source package in Bionic:
  Fix Released
Status in bluez source package in Cosmic:
  New
Status in gnome-bluetooth source package in Cosmic:
  Fix Released
Status in bluez source package in Disco:
  New
Status in gnome-bluetooth source package in Disco:
  Fix Released
Status in bluez source package in Eoan:
  Fix Committed
Status in gnome-bluetooth package in Fedora:
  Won't Fix

Bug description:
  Excerpt from a similar report
  (https://bugzilla.redhat.com/show_bug.cgi?id=1602985) :

  Opening the Bluetooth settings will make the device discoverable
  again, but does not make the device undiscoverable after the settings
  are closed (this is not intended behavior; devices should only be
  discoverable when the bluetooth settings UI is open).

  There seem to be a merge request :

  https://gitlab.gnome.org/GNOME/gnome-bluetooth/merge_requests/1

  Could you please merge it asap, it should be treated as a security
  issue IMHO.

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

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


[Touch-packages] [Bug 1791405]

2019-05-28 Thread bcotton
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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

Title:
  bluetooth always in discoverable mode (security issue)

Status in bluez package in Ubuntu:
  New
Status in gnome-bluetooth package in Ubuntu:
  Fix Released
Status in bluez source package in Bionic:
  New
Status in gnome-bluetooth source package in Bionic:
  Fix Released
Status in bluez source package in Cosmic:
  New
Status in gnome-bluetooth source package in Cosmic:
  Fix Released
Status in bluez source package in Disco:
  New
Status in gnome-bluetooth source package in Disco:
  Fix Released
Status in bluez source package in Eoan:
  Fix Committed
Status in gnome-bluetooth package in Fedora:
  Won't Fix

Bug description:
  Excerpt from a similar report
  (https://bugzilla.redhat.com/show_bug.cgi?id=1602985) :

  Opening the Bluetooth settings will make the device discoverable
  again, but does not make the device undiscoverable after the settings
  are closed (this is not intended behavior; devices should only be
  discoverable when the bluetooth settings UI is open).

  There seem to be a merge request :

  https://gitlab.gnome.org/GNOME/gnome-bluetooth/merge_requests/1

  Could you please merge it asap, it should be treated as a security
  issue IMHO.

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

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


[Touch-packages] [Bug 1791405] Re: bluetooth always in discoverable mode (security issue)

2019-05-28 Thread Bug Watch Updater
** Changed in: gnome-bluetooth (Fedora)
   Status: Confirmed => Won't Fix

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

Title:
  bluetooth always in discoverable mode (security issue)

Status in bluez package in Ubuntu:
  New
Status in gnome-bluetooth package in Ubuntu:
  Fix Released
Status in bluez source package in Bionic:
  New
Status in gnome-bluetooth source package in Bionic:
  Fix Released
Status in bluez source package in Cosmic:
  New
Status in gnome-bluetooth source package in Cosmic:
  Fix Released
Status in bluez source package in Disco:
  New
Status in gnome-bluetooth source package in Disco:
  Fix Released
Status in bluez source package in Eoan:
  Fix Committed
Status in gnome-bluetooth package in Fedora:
  Won't Fix

Bug description:
  Excerpt from a similar report
  (https://bugzilla.redhat.com/show_bug.cgi?id=1602985) :

  Opening the Bluetooth settings will make the device discoverable
  again, but does not make the device undiscoverable after the settings
  are closed (this is not intended behavior; devices should only be
  discoverable when the bluetooth settings UI is open).

  There seem to be a merge request :

  https://gitlab.gnome.org/GNOME/gnome-bluetooth/merge_requests/1

  Could you please merge it asap, it should be treated as a security
  issue IMHO.

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

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


[Touch-packages] [Bug 1821269] Re: [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch (4-pole combo jack mic doesn't detect)

2019-05-28 Thread Hui Wang
** Package changed: alsa-driver (Ubuntu) => linux (Ubuntu)

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

Title:
  [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch (4-pole
  combo jack mic doesn't detect)

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  I use realtek alc255 analog audio jack. External jack is 4 pole combo(apple 
type. not europe type.).
  When I plug 4 pole mic into jack, It doesn't detect.
  So I can't my voice through external mic.

  My laptop has internal mic. It belongs to Intel sound(HDA Intel PCH. Audio 
device: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx 
Series High Definition Audio Controller (rev 21)).
  Internal mic works well.

  Please check 4pole external mic detection.

  Thank you.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
  Uname: Linux 4.15.0-46-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0c:   jimnong1441 F...m pulseaudio
   /dev/snd/pcmC0D0p:   jimnong1441 F...m pulseaudio
   /dev/snd/controlC0:  jimnong1441 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 22 11:30:39 2019
  InstallationDate: Installed on 2017-07-27 (603 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: 내장 오디오 - HDA Intel PCH
  Symptom_Jack: Mic, Internal
  Symptom_Type: No auto-switch between inputs
  Title: [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch
  UpgradeStatus: Upgraded to bionic on 2018-09-23 (179 days ago)
  dmi.bios.date: 09/06/2016
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: V1.24
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: Garp_BA
  dmi.board.vendor: Acer
  dmi.board.version: V1.24
  dmi.chassis.type: 10
  dmi.chassis.vendor: Chassis Manufacturer
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.24:bd09/06/2016:svnAcer:pnAspireES1-131:pvrV1.24:rvnAcer:rnGarp_BA:rvrV1.24:cvnChassisManufacturer:ct10:cvrChassisVersion:
  dmi.product.family: BSW
  dmi.product.name: Aspire ES1-131
  dmi.product.version: V1.24
  dmi.sys.vendor: Acer

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

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


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

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

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

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

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

Status in openssh package in Ubuntu:
  Expired

Bug description:
  .

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

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

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


[Touch-packages] [Bug 1830744] Re: Stuck in 1024x768 resolution. Modeset can't detect VGA EDID on Ivybridge.

2019-05-28 Thread Daniel van Vugt
This might be a driver bug or it might be a hardware problem.

In case it is a driver bug then I have assigned it to both the 'modeset'
Xorg driver and the kernel 'i915' driver. Can you please boot a newer
version of Ubuntu from USB and tell us if it has the same problem?

  19.10: http://cdimages.ubuntu.com/daily-live/current/
  19.04: http://releases.ubuntu.com/19.04/

If this is a hardware problem then there are two possible causes I can
think of:

* Poor VGA connection or cable. Can you try a different cable?

* Maybe the monitor does not support EDIDs, but unlikely.

** Summary changed:

- Not able to get updated version of Driver
+ Stuck in 1024x768 resolution. Modeset can't detect VGA EDID on Ivybridge.

** Package changed: xorg (Ubuntu) => xorg-server (Ubuntu)

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

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

** Changed in: xorg-server (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/1830744

Title:
  Stuck in 1024x768 resolution. Modeset can't detect VGA EDID on
  Ivybridge.

Status in linux package in Ubuntu:
  Incomplete
Status in xorg-server package in Ubuntu:
  Incomplete

Bug description:
  Hey Support ,

  I am not able to get resolution of my Monitor which is 1080P, I
  checked with the cables and its all good. I think drivers are causing
  this issue. Might need help with that.

  Regards

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20
  Uname: Linux 4.18.0-21-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue May 28 20:04:43 2019
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller 
[8086:0162] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Xeon E3-1200 v2/3rd Gen Core processor 
Graphics Controller [103c:339a]
  InstallationDate: Installed on 2019-03-12 (77 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Hewlett-Packard HP Compaq Pro 6300 SFF
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-21-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/16/2013
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: K01 v02.90
  dmi.board.asset.tag: SGH333S866
  dmi.board.name: 339A
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: SGH333S866
  dmi.chassis.type: 4
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrK01v02.90:bd07/16/2013:svnHewlett-Packard:pnHPCompaqPro6300SFF:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct4:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP Compaq Pro 6300 SFF
  dmi.product.sku: QV985AV
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1~18.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.2-1ubuntu1~18.04.1
  version.xserver-xorg-core: xserver-xorg-core N/A
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

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

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


[Touch-packages] [Bug 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel

2019-05-28 Thread Ubuntu Foundations Team Bug Bot
The attachment "Fix tagged pointer support." seems to be a debdiff.  The
ubuntu-sponsors team has been subscribed to the bug report so that they
can review and hopefully sponsor the debdiff.  If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe
the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]

** Tags added: patch

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

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'.

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch is low.

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

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


[Touch-packages] [Bug 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel

2019-05-28 Thread Manoj Iyer
** Description changed:

  [Impact]
- GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'. 
+ GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'.
  
  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)
  
  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support
  
  [Regression Potential]
- The risk of regression after applying this patch is low, tagged pointer test 
cases still pass.
+ The risk of regression after applying this patch is low.

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

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'.

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch is low.

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

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


[Touch-packages] [Bug 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel

2019-05-28 Thread Manoj Iyer
== Testing on PPC64EL ==

ubuntu@tiselius:~$ apt policy gdb
gdb:
  Installed: 8.1-0ubuntu4
  Candidate: 8.1-0ubuntu4
  Version table:
 *** 8.1-0ubuntu4 500
500 http://ppa.launchpad.net/manjo/gdb-lp1830796/ubuntu bionic/main 
ppc64el Packages
100 /var/lib/dpkg/status
 8.1-0ubuntu3 500
500 http://ports.ubuntu.com/ubuntu-ports bionic/main ppc64el Packages
ubuntu@tiselius:~$

root@hotdog:~# gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore 
GNU gdb (Ubuntu 8.1-0ubuntu4) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/debug/boot/vmlinux-4.18.0-20-generic...done.

warning: core file may not match specified executable file.
[New process 1]
Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
#0  0x in ?? ()
(gdb) p jiffies_64
$1 = 4406710034
(gdb)

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

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'. 

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch is low, tagged pointer test 
cases still pass.

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

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


[Touch-packages] [Bug 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel

2019-05-28 Thread Manoj Iyer
Test package is available in PPA:
ppa:manjo/gdb-lp1830796 

ubuntu@hotdog:~$ apt policy gdb
gdb:
  Installed: 8.1-0ubuntu4
  Candidate: 8.1-0ubuntu4
  Version table:
 *** 8.1-0ubuntu4 500
500 http://ppa.launchpad.net/manjo/gdb-lp1830796/ubuntu bionic/main 
arm64 Packages
100 /var/lib/dpkg/status
 8.1-0ubuntu3 500
500 http://ports.ubuntu.com/ubuntu-ports bionic/main arm64 Packages
ubuntu@hotdog:~$ 

root@hotdog:~# gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore 
GNU gdb (Ubuntu 8.1-0ubuntu4) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/debug/boot/vmlinux-4.18.0-20-generic...done.

warning: core file may not match specified executable file.
[New process 1]
Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
#0  0x in ?? ()
(gdb) p jiffies_64
$1 = 4406710034
(gdb)

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

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'. 

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch is low, tagged pointer test 
cases still pass.

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

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


[Touch-packages] [Bug 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel

2019-05-28 Thread Manoj Iyer
The attached debdiff to gdb fixes the issue. The patch was cleanly
applied from the upstream GDB git repo, and test results are as posted
to this bug report. No regression were found.

** Patch added: "Fix tagged pointer support."
   
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1830796/+attachment/5267248/+files/gdb-fix-tagged-pointer-support.diff

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

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'. 

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch is low, tagged pointer test 
cases still pass.

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

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread Xav Paice
udevadm info -e >/tmp/1828617-2.out

~# ls -l /var/lib/ceph/osd/ceph*
-rw--- 1 ceph ceph  69 May 21 08:44 
/var/lib/ceph/osd/ceph.client.osd-upgrade.keyring

/var/lib/ceph/osd/ceph-11:
total 24
lrwxrwxrwx 1 ceph ceph 93 May 28 22:12 block -> 
/dev/ceph-33de740d-bd8c-4b47-a601-3e6e634e489a/osd-block-33de740d-bd8c-4b47-a601-3e6e634e489a
-rw--- 1 ceph ceph 37 May 28 22:12 ceph_fsid
-rw--- 1 ceph ceph 37 May 28 22:12 fsid
-rw--- 1 ceph ceph 56 May 28 22:12 keyring
-rw--- 1 ceph ceph  6 May 28 22:12 ready
-rw--- 1 ceph ceph 10 May 28 22:12 type
-rw--- 1 ceph ceph  3 May 28 22:12 whoami

/var/lib/ceph/osd/ceph-18:
total 24
lrwxrwxrwx 1 ceph ceph 93 May 28 22:12 block -> 
/dev/ceph-eb5270dc-1110-420f-947e-aab7fae299c9/osd-block-eb5270dc-1110-420f-947e-aab7fae299c9
lrwxrwxrwx 1 ceph ceph 94 May 28 22:12 block.db -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-db-eb5270dc-1110-420f-947e-aab7fae299c9
lrwxrwxrwx 1 ceph ceph 95 May 28 22:12 block.wal -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-wal-eb5270dc-1110-420f-947e-aab7fae299c9
-rw--- 1 ceph ceph 37 May 28 22:12 ceph_fsid
-rw--- 1 ceph ceph 37 May 28 22:12 fsid
-rw--- 1 ceph ceph 56 May 28 22:12 keyring
-rw--- 1 ceph ceph  6 May 28 22:12 ready
-rw--- 1 ceph ceph 10 May 28 22:12 type
-rw--- 1 ceph ceph  3 May 28 22:12 whoami

/var/lib/ceph/osd/ceph-24:
total 24
lrwxrwxrwx 1 ceph ceph 93 May 28 22:12 block -> 
/dev/ceph-d38a7e91-cf06-4607-abbe-53eac89ac5ea/osd-block-d38a7e91-cf06-4607-abbe-53eac89ac5ea
-rw--- 1 ceph ceph 37 May 28 22:12 ceph_fsid
-rw--- 1 ceph ceph 37 May 28 22:12 fsid
-rw--- 1 ceph ceph 56 May 28 22:12 keyring
-rw--- 1 ceph ceph  6 May 28 22:12 ready
-rw--- 1 ceph ceph 10 May 28 22:12 type
-rw--- 1 ceph ceph  3 May 28 22:12 whoami

/var/lib/ceph/osd/ceph-31:
total 24
lrwxrwxrwx 1 ceph ceph 93 May 28 22:12 block -> 
/dev/ceph-053e000a-76ed-427e-98b3-e5373e263f2d/osd-block-053e000a-76ed-427e-98b3-e5373e263f2d
lrwxrwxrwx 1 ceph ceph 94 May 28 22:12 block.db -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-db-053e000a-76ed-427e-98b3-e5373e263f2d
lrwxrwxrwx 1 ceph ceph 95 May 28 22:12 block.wal -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-wal-053e000a-76ed-427e-98b3-e5373e263f2d
-rw--- 1 ceph ceph 37 May 28 22:12 ceph_fsid
-rw--- 1 ceph ceph 37 May 28 22:12 fsid
-rw--- 1 ceph ceph 56 May 28 22:12 keyring
-rw--- 1 ceph ceph  6 May 28 22:12 ready
-rw--- 1 ceph ceph 10 May 28 22:12 type
-rw--- 1 ceph ceph  3 May 28 22:12 whoami

/var/lib/ceph/osd/ceph-38:
total 24
lrwxrwxrwx 1 ceph ceph 93 May 28 22:12 block -> 
/dev/ceph-c2669da2-63aa-42e2-b049-cf00a478e076/osd-block-c2669da2-63aa-42e2-b049-cf00a478e076
lrwxrwxrwx 1 ceph ceph 94 May 28 22:12 block.db -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-db-c2669da2-63aa-42e2-b049-cf00a478e076
lrwxrwxrwx 1 ceph ceph 95 May 28 22:12 block.wal -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-wal-c2669da2-63aa-42e2-b049-cf00a478e076
-rw--- 1 ceph ceph 37 May 28 22:12 ceph_fsid
-rw--- 1 ceph ceph 37 May 28 22:12 fsid
-rw--- 1 ceph ceph 56 May 28 22:12 keyring
-rw--- 1 ceph ceph  6 May 28 22:12 ready
-rw--- 1 ceph ceph 10 May 28 22:12 type
-rw--- 1 ceph ceph  3 May 28 22:12 whoami

/var/lib/ceph/osd/ceph-4:
total 24
lrwxrwxrwx 1 ceph ceph 93 May 28 22:12 block -> 
/dev/ceph-7478edfc-f321-40a2-a105-8e8a2c8ca3f6/osd-block-7478edfc-f321-40a2-a105-8e8a2c8ca3f6
lrwxrwxrwx 1 ceph ceph 94 May 28 22:12 block.db -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-db-7478edfc-f321-40a2-a105-8e8a2c8ca3f6
lrwxrwxrwx 1 ceph ceph 95 May 28 22:12 block.wal -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-wal-7478edfc-f321-40a2-a105-8e8a2c8ca3f6
-rw--- 1 ceph ceph 37 May 28 22:12 ceph_fsid
-rw--- 1 ceph ceph 37 May 28 22:12 fsid
-rw--- 1 ceph ceph 55 May 28 22:12 keyring
-rw--- 1 ceph ceph  6 May 28 22:12 ready
-rw--- 1 ceph ceph 10 May 28 22:12 type
-rw--- 1 ceph ceph  2 May 28 22:12 whoami

/var/lib/ceph/osd/ceph-45:
total 24
lrwxrwxrwx 1 ceph ceph 93 May 28 22:12 block -> 
/dev/ceph-12e68fcb-d2b6-459f-97f2-d3eb4e28c75e/osd-block-12e68fcb-d2b6-459f-97f2-d3eb4e28c75e
lrwxrwxrwx 1 ceph ceph 94 May 28 22:12 block.db -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-db-12e68fcb-d2b6-459f-97f2-d3eb4e28c75e
lrwxrwxrwx 1 ceph ceph 95 May 28 22:12 block.wal -> 
/dev/ceph-wal-4de27554-2d05-440e-874a-9921dfc6f47e/osd-wal-12e68fcb-d2b6-459f-97f2-d3eb4e28c75e
-rw--- 1 ceph ceph 37 May 28 22:12 ceph_fsid
-rw--- 1 ceph ceph 37 May 28 22:12 fsid
-rw--- 1 ceph ceph 56 May 28 22:12 keyring
-rw--- 1 ceph ceph  6 May 28 22:12 ready
-rw--- 1 ceph ceph 10 May 28 22:12 type
-rw--- 1 ceph ceph  3 May 28 22:12 whoami


** Attachment added: "1828617-2.out"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828617/+attachment/5267247/+files/1828617-2.out

-- 
You received this bug 

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

2019-05-28 Thread Xav Paice
journalctl --no-pager -lu systemd-udevd.service >/tmp/1828617-1.out

Hostname obfusticated

lsblk:

NAME
 MAJ:MIN  RM   SIZE RO TYPE  MOUNTPOINT
loop0   
   7:0 0  88.4M  1 loop  /snap/core/6964
loop1   
   7:1 0  89.4M  1 loop  /snap/core/6818
loop2   
   7:2 0   8.4M  1 loop  
/snap/canonical-livepatch/77
sda 
   8:0 0   1.8T  0 disk  
├─sda1  
   8:1 0   476M  0 part  /boot/efi
├─sda2  
   8:2 0   3.7G  0 part  /boot
└─sda3  
   8:3 0   1.7T  0 part  
  └─bcache7 
 252:896   0   1.7T  0 disk  /
sdb 
   8:160   1.8T  0 disk  
└─bcache0   
 252:0 0   1.8T  0 disk  
sdc 
   8:320   1.8T  0 disk  
└─bcache6   
 252:768   0   1.8T  0 disk  
  └─crypt-7478edfc-f321-40a2-a105-8e8a2c8ca3f6  
 253:0 0   1.8T  0 crypt 

└─ceph--7478edfc--f321--40a2--a105--8e8a2c8ca3f6-osd--block--7478edfc--f321--40a2--a105--8e8a2c8ca3f6
253:2 0   1.8T  0 lvm   
sdd 
   8:480   1.8T  0 disk  
└─bcache4   
 252:512   0   1.8T  0 disk  
  └─crypt-33de740d-bd8c-4b47-a601-3e6e634e489a  
 253:4 0   1.8T  0 crypt 

└─ceph--33de740d--bd8c--4b47--a601--3e6e634e489a-osd--block--33de740d--bd8c--4b47--a601--3e6e634e489a
253:5 0   1.8T  0 lvm   
sde 
   8:640   1.8T  0 disk  
└─bcache3   
 252:384   0   1.8T  0 disk  
  └─crypt-eb5270dc-1110-420f-947e-aab7fae299c9  
 253:1 0   1.8T  0 crypt 

└─ceph--eb5270dc--1110--420f--947e--aab7fae299c9-osd--block--eb5270dc--1110--420f--947e--aab7fae299c9
253:3 0   1.8T  0 lvm   
sdf 
   8:800   1.8T  0 disk  
└─bcache1   
 252:128   0   1.8T  0 disk  
  └─crypt-d38a7e91-cf06-4607-abbe-53eac89ac5ea  
 253:6 0   1.8T  0 crypt 

└─ceph--d38a7e91--cf06--4607--abbe--53eac89ac5ea-osd--block--d38a7e91--cf06--4607--abbe--53eac89ac5ea
253:7 0   1.8T  0 lvm   
sdg 
   8:960   1.8T  0 disk  
└─bcache5   
 252:640   0   1.8T  0 disk  
  └─crypt-053e000a-76ed-427e-98b3-e5373e263f2d  
 253:8 0   1.8T  0 crypt 

└─ceph--053e000a--76ed--427e--98b3--e5373e263f2d-osd--block--053e000a--76ed--427e--98b3--e5373e263f2d
253:9 0   1.8T  0 lvm   
sdh 
   8:112   0   1.8T  0 disk  
└─bcache8   
 252:1024  0   1.8T  0 disk  
  └─crypt-c2669da2-63aa-42e2-b049-cf00a478e076  
 253:250   1.8T  0 crypt 


[Touch-packages] [Bug 215940] Re: Intermittent testsuite failure on (at least) amd64

2019-05-28 Thread Brian Murray
** Summary changed:

- Itermittent testsuite failure on (at least) amd64
+ Intermittent testsuite failure on (at least) amd64

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

Title:
  Intermittent testsuite failure on (at least) amd64

Status in tar package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: tar

  tar occasionally fails the truncate test on (at least) amd64, as can
  be seen in the ubuntu-autotest logs at
  https://lists.ubuntu.com/archives/ubuntu-
  autotest/2008-April/018799.html ... Note that a retry of this build
  (on the same machine, in the same build environment) succeeded, so
  reproducing this probably relies on performing several looping builds
  (or looking at the test itself to determine why it might be racy or
  time-of-day dependant)

  I'm marking this as low priority, since it's easily worked around by
  just reattempting the build, but it's still a bug, so should be filed
  until proven fixed.

  Note that this is *not* bug #25084, so please don't dupe it at such.
  :)

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

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


[Touch-packages] [Bug 1189310] Re: Broken markup in tar.1 manual page

2019-05-28 Thread Brian Murray
** Changed in: tar (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  Broken markup in tar.1 manual page

Status in tar package in Ubuntu:
  Fix Released
Status in tar package in Debian:
  Fix Released

Bug description:
  tar.1 has the following error codes in my database of manpage
  glitches:

  C Broken command synopsis syntax.  This may mean you're using a 
construction in the command synopsis other than the standard 
[ ] | { }, or it may mean you have running text in the command synopsis
section (the latter is not technically an error, but most cases of it
are impossible to translate into DocBook markup), or it may mean the 
command syntax fails to match the description.

  V Missing body content in list trips up doclifter and is likely to
cause rendering problems in non-troff viewers.  I have been able to fill
in what was missing except for what should be under TAR_LONGLINK_100.

  A fix patch is attached.

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

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


[Touch-packages] [Bug 1554715] Re: rmt and rmt-tar should not be autoinstalled

2019-05-28 Thread Brian Murray
** Changed in: tar (Ubuntu)
   Status: New => Triaged

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

Title:
  rmt and rmt-tar should not be autoinstalled

Status in tar package in Ubuntu:
  Triaged

Bug description:
  A "remote magtape protocol module? On PCs? In 2016?

  The are potential users for this thing, maybe, on Z-series mainframes,
  but having it be autoinstalled  on vanilla desktop machines, or even
  ordinary servers, is deeply silly.

  Recommendation: split the package.  Yes, tar is essential; rmt is not.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: tar 1.27.1-2
  ProcVersionSignature: Ubuntu 4.2.0-25.30-generic 4.2.6
  Uname: Linux 4.2.0-25-generic x86_64
  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
  CurrentDesktop: i3
  Date: Tue Mar  8 15:23:17 2016
  InstallationDate: Installed on 2016-01-02 (65 days ago)
  InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
  SourcePackage: tar
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

2019-05-28 Thread Dimitri John Ledkov
Test suite got fixed in master too, all is good:
https://git.busybox.net/busybox/commit/?id=b2c123d484dbe261758f27ced213f4649173803b

Thanks a lot for the quick fixes! Included in Ubuntu devel series.

-- 
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 BusyBox:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Invalid
Status in busybox package in Ubuntu:
  Fix Released
Status in glibc package in Ubuntu:
  Invalid

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/busybox/+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 1829785] Re: Evince: ∞ not found

2019-05-28 Thread Launchpad Bug Tracker
This bug was fixed in the package poppler - 0.74.0-0ubuntu1.1

---
poppler (0.74.0-0ubuntu1.1) disco; urgency=medium

  * debian/patches/git_unicode_search.patch:
- backport a fix for a regression on case-insensitive search
  (lp: #1829785)

 -- Sebastien Bacher   Tue, 21 May 2019 16:30:23
+0200

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

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

Title:
  Evince: ∞ not found

Status in Evince:
  Fix Released
Status in poppler package in Ubuntu:
  Fix Released
Status in poppler source package in Disco:
  Fix Released

Bug description:
  Impact
  Case-insensitive search of unicde chars in PDF documents is broken

  Test case
  1) Open the attached document in Evince
  2) Select the infinity symbol ∞ (U+221E) and copy it into clipboard
  3) Press Ctrl+F and paste the symbol from the clipboard into the search field

  The symbol should be found in the document

  Regression potential
  Check in different pdf renderer using poppler than search still work correctly

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

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


[Touch-packages] [Bug 1830802] [NEW] AppArmor profile transition changes required by Linux kernel fix for CVE-2019-11190

2019-05-28 Thread Tyler Hicks
Public bug reported:

[Impact]

* As discussed in bug #1628745, the following kernel commit changes
  AppArmor mediation behavior on exec transitions:

   commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
   Author: Linus Torvalds 
   Date: Mon Aug 22 16:41:46 2016 -0700

   binfmt_elf: switch to new creds when switching to new mm

* This change made its way into the Xenial kernel that's currently in
  xenial-proposed (4.4.0-149.175-generic) as it fixes CVE-2019-11190.

* jdstrand identified a couple missing fixes that are needed from the
  AppArmor tree:

  d8278f51ecb3c736d697fa367faf99457210a7d8
  7a49f37c2481f761f8304712aa380acddfdb6303

[Test Case]

TODO

[Regression Potential]

The dnsmasq profile change adds permissions to the child profile.
There's really no change of regression involved there.

The aa.py change adds the 'm' permission to the allowed permissions of a
binary on ix transitions. While there is a code change involved, it is a
small change and the resulting profile output involved no risk of
regression.

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

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

Title:
  AppArmor profile transition changes required by Linux kernel fix for
  CVE-2019-11190

Status in apparmor package in Ubuntu:
  New

Bug description:
  [Impact]

  * As discussed in bug #1628745, the following kernel commit changes
AppArmor mediation behavior on exec transitions:

 commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
 Author: Linus Torvalds 
 Date: Mon Aug 22 16:41:46 2016 -0700

 binfmt_elf: switch to new creds when switching to new mm

  * This change made its way into the Xenial kernel that's currently in
xenial-proposed (4.4.0-149.175-generic) as it fixes CVE-2019-11190.

  * jdstrand identified a couple missing fixes that are needed from the
AppArmor tree:

d8278f51ecb3c736d697fa367faf99457210a7d8
7a49f37c2481f761f8304712aa380acddfdb6303

  [Test Case]

  TODO

  [Regression Potential]

  The dnsmasq profile change adds permissions to the child profile.
  There's really no change of regression involved there.

  The aa.py change adds the 'm' permission to the allowed permissions of a
  binary on ix transitions. While there is a code change involved, it is a
  small change and the resulting profile output involved no risk of
  regression.

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

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread Corey Bryant
Andrey, I don't know if you saw James' comment as yours may have
coincided but if you can get the ceph-osd package version that would be
helpful. Thanks!

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

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 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel

2019-05-28 Thread Manoj Iyer
** Changed in: gdb (Ubuntu)
   Status: New => In Progress

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

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'. 

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch is low, tagged pointer test 
cases still pass.

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

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


[Touch-packages] [Bug 1830796] [NEW] [Bionic][ARM64]Failure debugging linux kernel

2019-05-28 Thread Manoj Iyer
Public bug reported:

[Impact]
GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'. 

[Test]
# gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
[New process 1]
Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
#0  0x in ?? ()
(gdb) p jiffies_64
Cannot access memory at address 0x09616980
(gdb)

[Fix]
This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
8727de56b0  Fix tagged pointer support

[Regression Potential]
The risk of regression after applying this patch is low, tagged pointer test 
cases still pass.

** Affects: gdb (Ubuntu)
 Importance: High
 Assignee: Manoj Iyer (manjo)
 Status: New


** Tags: cn99xx

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

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  New

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'. 

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch is low, tagged pointer test 
cases still pass.

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

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


[Touch-packages] [Bug 1797386] Proposed package upload rejected

2019-05-28 Thread Steve Langasek
An upload of libio-socket-ssl-perl to bionic-proposed has been rejected
from the upload queue for the following reason: "reupload required as
this version is known to introduce regressions".

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

Title:
  [SRU] OpenSSL 1.1.1 to 18.04 LTS

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

Bug description:
  [Impact]

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

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

   * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.

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

  [Test Case]

   * Rebuild all reverse dependencies

   * Execute autopkg tests for all of them

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

   * Backport TLS v1.3 support patches, where applicable

  [Test cases for the python updates]

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

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

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

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

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

  [Regression Potential]

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

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

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

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

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

     - non-application data records. TLSv1.3 sends more of these, when compared 
with previous versions, and some applications may not handle this correctly. 
Resulting in application data not being available, when previously expected. 
Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY or 
setting max protocol version to TLSv1.2. For example see discussion identified 
in the perl stack https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
  Similar hangs are possible with prior versions of TLS as well, it is however 
easier to trigger this with TLSv1.3.

   * Deprecated npn extenstion does not exist in TLSv1.3 implementation.

   * This update bundles python 3.6 and 3.7 point 

[Touch-packages] [Bug 1551980] Re: /etc/inid.d/clvm references inexisting /etc/rc.d/init.d/functions

2019-05-28 Thread Rafael David Tinoco
*** This bug is a duplicate of bug 1248054 ***
https://bugs.launchpad.net/bugs/1248054

** This bug has been marked a duplicate of bug 1248054
   [SRU] dlm package installation fails

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

Title:
  /etc/inid.d/clvm references inexisting /etc/rc.d/init.d/functions

Status in lvm2 package in Ubuntu:
  New

Bug description:
  Start of service fails with `Can't open /etc/rc.d/init.d/functions`
  should be `/lib/lsb/init-functions`.

  https://bugs.launchpad.net/ubuntu/+source/dlm/+bug/1248054 seems very
  similar.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: clvm 2.02.122-1ubuntu1
  Uname: Linux 4.3.3-040303-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
  Date: Tue Mar  1 22:57:31 2016
  InstallationDate: Installed on 2015-04-20 (316 days ago)
  InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 
(20141022.2)
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: lvm2
  UpgradeStatus: Upgraded to wily on 2015-10-26 (127 days ago)
  mtime.conffile..etc.default.clvm: 2016-02-29T21:18:26.193340
  mtime.conffile..etc.init.d.clvm: 2016-03-01T14:17:26.717605

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

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


[Touch-packages] [Bug 1695601] Re: IPv6 temporary/privacy addresses lifetime are not renewed upon new ICMPv6 Router-Advertisement packet

2019-05-28 Thread Sebastien Bacher
Thanks for keeping the bug updated

** Changed in: network-manager (Ubuntu)
   Status: Confirmed => 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/1695601

Title:
  IPv6 temporary/privacy addresses lifetime are not renewed upon new
  ICMPv6 Router-Advertisement packet

Status in network-manager package in Ubuntu:
  Fix Released

Bug description:
  My ISP's router provides IPv6 connectivity and advertises valid
  lifetime of 900 secs and preferred lifetime of 300 secs. My Ubuntu
  17.04 (and previous) installation has been showing weird behavior over
  IPv6, with connections dropping quite often but on a regular basis.

  After extensive debugging and verification that there was no issue on router 
side, and on WiFi physical connection, I have verified that this was not 
related to the lack of ICMPv6 RA packets.
  Running |watch -d -n1 ip -6 addr show dev wlan0| shows:
   - decreasing valid_lft and preferred_lft on both IPv6 addresses
   - upon ICMPv6 RA packet received, the global SLAAC address derived from MAC 
gets valid_lft and preferred_lft field updated
   - at the same time, the privacy extension address is still decreasing

  System uses NetworkManager to handle all of that. I could verify that
  my desktop system, running Debian Sid with NetworkManager v1.6 was not
  exposing the issue.

  Running NetworkManager in debug mode gives more informations:
  > nm_ubuntu_zesty.log:NetworkManager[2418]:  [1496447074.7897] 
platform-linux: event-notification: NEWADDR, seq 0: 
2a01:::::::39c5/64 lft 900sec pref 300sec lifetime 
289-289[300,900] dev 3 flags secondary src kernel
  > nm_ubuntu_zesty.log:NetworkManager[2418]:  [1496447074.7901] 
platform-linux: event-notification: NEWADDR, seq 0: 
2a01:::::::39c5/64 lft 622sec pref 22sec lifetime 
289-289[22,622] dev 3 flags secondary src kernel

  The two timestamps of the NEWADDR event are very very close. The first
  one shows proper update of the lifetimes values ; while the second one
  shows invalid values being pushed. With those informations in mind, I
  dug a little bit in the NetworkManager source code, and I found that
  there was one change between v1.4.4 (current Zesty package) and v1.6
  (Debian sid package) that was touching the code handling IPv6
  addresses sync:
  
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1dbd9d7948
  ; the commit states that without this change, NM might overwrite IPv6
  temporary addresses changes.

  I took my chance and rebuilt network-manager-1.4.4 package with that
  patch included: IPv6 temporary privacy extensions enabled addresses
  gets proper updates of their lifetime when ICMPv6 packets reaches my
  system.

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

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


[Touch-packages] [Bug 1829913] Re: openconnect VPN is not propagating internal DNS anymore

2019-05-28 Thread Till Kamppeter
What do you mean with "Can't do anything"? Does your problem now also
occur with the old version, too?

What I want to ask you to do is the following:

With network-manager and systemd updated the problem occurs for you. To
find a possible solution, install the updates, reboot, and do the
following test:

Run

sudo nmcli con modify "$COMPANY VPN" ipv4.dns-priority -1 ipv4.dns-
search ~.

and check whether this solves the problem. Tell us your result.

If this does not solve the problem, reboot and follow my instructions in
comment #9. Attach the log file you get.

After that, downgrade network-manager to the old version again to get
back to a working configuration.

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

Title:
  openconnect VPN is not propagating internal DNS anymore

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  Openconnect VPN stopped propagating DNSes to the system.

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

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


[Touch-packages] [Bug 1829913] Re: openconnect VPN is not propagating internal DNS anymore

2019-05-28 Thread Joe_Bishop
Can't do anything:

apt policy network-manager
network-manager:
  Installed: 1.10.6-2ubuntu1.1
  Candidate: 1.10.6-2ubuntu1.1
  Version table:
 *** 1.10.6-2ubuntu1.1 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
 1.10.6-2ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

This is old network-manager.

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

Title:
  openconnect VPN is not propagating internal DNS anymore

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  Openconnect VPN stopped propagating DNSes to the system.

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

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


[Touch-packages] [Bug 1817097] Re: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices

2019-05-28 Thread Frank Heimes
Updated package landed in release pocket - changing project entry to Fix
Released.

** Changed in: ubuntu-z-systems
   Status: Incomplete => Fix Released

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

Title:
  pvmove causes file system corruption without notice upon move from 512
  -> 4096 logical block size devices

Status in lvm2:
  Confirmed
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in e2fsprogs package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in lvm2 package in Ubuntu:
  Invalid

Bug description:
  Problem Description---
  Summary
  ===
  Environment: IBM Z13 LPAR and z/VM Guest
   IBM Type: 2964 Model: 701 NC9
  OS:  Ubuntu 18.10 (GNU/Linux 4.18.0-13-generic s390x)
   Package: lvm2 version 2.02.176-4.1ubuntu3
  LVM: pvmove operation corrupts file system when using 4096 (4k) logical block 
size
   and default block size being 512 bytes in the underlying devices
  The problem is immediately reproducible.

  We see a real usability issue with data destruction as consequence - which is 
not acceptable.
  We expect 'pvmove' to fail with error in such situations to prevent fs 
destruction,
  which might possibly be overridden by a force flag.

  
  Details
  ===
  After a 'pvmove' operation is run to move a physical volume onto an ecrypted
  device with 4096 bytes logical block size we experience a file system 
corruption.
  There is no need for the file system to be mounted, but the problem surfaces
  differently if so.

  Either, the 'pvs' command after the pvmove shows
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 4096: Invalid argument

  or

  a subsequent mount shows (after umount if the fs had previously been mounted 
as in our
  setup)
  mount: /mnt: wrong fs type, bad option, bad superblock on 
/dev/mapper/LOOP_VG-LV, missing codepage or helper program, or other error.

  A minimal setup of LVM using one volume group with one logical volume defined,
  based on one physical volume is sufficient to raise the problem. One more 
physical
  volume of the same size is needed to run the pvmove operation to. 

LV
 |
  VG: LOOP_VG [ ]
 |
  PV: /dev/loop0   -->   /dev/mapper/enc-loop
  ( backed by /dev/mapper/enc-loop )

  The physical volumes are backed by loopback devices (losetup) to base the
  problem report on, but we have seen the error on real SCSI multipath volumes
  also, with and without cryptsetup mapper devices in use.

  
  Further discussion
  ==
  https://www.saout.de/pipermail/dm-crypt/2019-February/006078.html
  The problem does not occur on block devices with native size of 4k.
  E.g. DASDs, or file systems with mkfs -b 4096 option.

  
  Terminal output
  ===
  See attached file pvmove-error.txt

  
  Debug data
  ==
  pvmove was run with -dd (maximum debug level)
  See attached journal file.
   
  Contact Information = christian.r...@de.ibm.com 
   
  ---uname output---
  Linux system 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:00:35 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = IBM Type: 2964 Model: 701 NC9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1.) Create two image files of 500MB in size
  and set up two loopback devices with 'losetup -fP FILE'
  2.) Create one physical volume and one volume group 'LOOP_VG',
  and one logical volume 'VG'
  Run:
  pvcreate /dev/loop0
  vgcreate LOOP_VG /dev/loop0
  lvcreate -L 300MB LOOP_VG -n LV /dev/loop0
  3.) Create a file system on the logical volume device:
  mkfs.ext4 /dev/mapper/LOOP_VG-LV
  4.) mount the file system created in the previous step to some empty 
available directory:
  mount /dev/mapper/LOOP_VG-LV /mnt
  5.) Set up a second physical volume, this time encrypted with LUKS2,
  and open the volume to make it available:
  cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1
  cryptsetup luksOpen /dev/loop1 enc-loop
  6.) Create the second physical volume, and add it to the LOOP_VG
  pvcreate /dev/mapper/enc-loop
  vgextend LOOP_VG /dev/mapper/enc-loop
  7.) Ensure the new physical volume is part of the volume group:
  pvs
  8.) Move the /dev/loop0 volume onto the encrypted volume with maximum debug 
option:
  pvmove -dd /dev/loop0 /dev/mapper/enc-loop
  9.) The previous step succeeds, but corrupts the file system on the logical 
volume
   We expect an error here. 
   There might be a command line flag to override used because 

[Touch-packages] [Bug 1830502] Re: apparmor fails to start with no parser errors

2019-05-28 Thread Ian Johnson
How would you recommend I go about checking which profiles are actually
loaded and which profiles are reported as loaded? I have this from aa-
status: https://pastebin.ubuntu.com/p/c2FbrndDzs/

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

Title:
  apparmor fails to start with no parser errors

Status in apparmor package in Ubuntu:
  New

Bug description:
  On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
  my system was unable to finish booting and I had to go into recovery
  mode and remove a number of files before the system would boot. After
  doing so I discovered that now the apparmor.service systemd unit
  always fails to start. I see this in dmesg:

  [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 
or sacrifice child
  [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, 
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
  [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now 
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

  Whenever apparmor.service is attempted to be started by systemd, i.e.
  either on boot, or later with `systemctl start apparmor`.

  The log from journalctl doesn't show any actual issues with any
  profiles just this:

  -- Reboot --
  May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
  May 25 17:00:58 apparmor[1521]:  * Starting AppArmor profiles
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:01:40 apparmor[1521]:...fail!
  May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
  May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
  May 25 17:04:53 apparmor[4747]:  * Starting AppArmor profiles
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:05:25 apparmor[4747]:...fail!
  May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.

  I can see that apparmor profiles are active after doing this (using
  aa-status), but it's still troubling that apparmor runs into an issue
  without actually saying what the error is.

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

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


[Touch-packages] [Bug 1820140] Re: euronews plugin needs to be updated to the website changes

2019-05-28 Thread Launchpad Bug Tracker
This bug was fixed in the package grilo-plugins - 0.3.8-2ubuntu1.1

---
grilo-plugins (0.3.8-2ubuntu1.1) cosmic; urgency=medium

  * debian/patches/git_euronews_update.patch:
- euronews: Update for site changes (lp: #1820140)

 -- Sebastien Bacher   Fri, 15 Mar 2019 00:37:25
+0100

** Changed in: grilo-plugins (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 grilo-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1820140

Title:
  euronews plugin needs to be updated to the website changes

Status in grilo-plugins package in Ubuntu:
  Fix Released
Status in grilo-plugins source package in Cosmic:
  Fix Released

Bug description:
  * Impact

  In totem the euronews section is giving parsing error and not
  displaying the video content

  * Test case

  Browse the euronews channel in totem, the video should play correctly

  * Impact

  The change is updating the url in the euronews plugin which is current
  not working, it shouldn't be able to create a regression

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

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


[Touch-packages] [Bug 1820140] Update Released

2019-05-28 Thread Brian Murray
The verification of the Stable Release Update for grilo-plugins 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 grilo-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1820140

Title:
  euronews plugin needs to be updated to the website changes

Status in grilo-plugins package in Ubuntu:
  Fix Released
Status in grilo-plugins source package in Cosmic:
  Fix Released

Bug description:
  * Impact

  In totem the euronews section is giving parsing error and not
  displaying the video content

  * Test case

  Browse the euronews channel in totem, the video should play correctly

  * Impact

  The change is updating the url in the euronews plugin which is current
  not working, it shouldn't be able to create a regression

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

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


[Touch-packages] [Bug 1817097] Re: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices

2019-05-28 Thread Launchpad Bug Tracker
This bug was fixed in the package e2fsprogs - 1.45.1-1ubuntu1

---
e2fsprogs (1.45.1-1ubuntu1) eoan; urgency=medium

  * Use 4k blocksize in all ext4 mke2fs.conf such that lvm migration
between non-4k PVs and 4k PVs works irrespective of the volume
size. LP: #1817097

 -- Dimitri John Ledkov   Wed, 15 May 2019 16:15:22
+0200

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

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

Title:
  pvmove causes file system corruption without notice upon move from 512
  -> 4096 logical block size devices

Status in lvm2:
  Confirmed
Status in Ubuntu on IBM z Systems:
  Incomplete
Status in e2fsprogs package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in lvm2 package in Ubuntu:
  Invalid

Bug description:
  Problem Description---
  Summary
  ===
  Environment: IBM Z13 LPAR and z/VM Guest
   IBM Type: 2964 Model: 701 NC9
  OS:  Ubuntu 18.10 (GNU/Linux 4.18.0-13-generic s390x)
   Package: lvm2 version 2.02.176-4.1ubuntu3
  LVM: pvmove operation corrupts file system when using 4096 (4k) logical block 
size
   and default block size being 512 bytes in the underlying devices
  The problem is immediately reproducible.

  We see a real usability issue with data destruction as consequence - which is 
not acceptable.
  We expect 'pvmove' to fail with error in such situations to prevent fs 
destruction,
  which might possibly be overridden by a force flag.

  
  Details
  ===
  After a 'pvmove' operation is run to move a physical volume onto an ecrypted
  device with 4096 bytes logical block size we experience a file system 
corruption.
  There is no need for the file system to be mounted, but the problem surfaces
  differently if so.

  Either, the 'pvs' command after the pvmove shows
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 4096: Invalid argument

  or

  a subsequent mount shows (after umount if the fs had previously been mounted 
as in our
  setup)
  mount: /mnt: wrong fs type, bad option, bad superblock on 
/dev/mapper/LOOP_VG-LV, missing codepage or helper program, or other error.

  A minimal setup of LVM using one volume group with one logical volume defined,
  based on one physical volume is sufficient to raise the problem. One more 
physical
  volume of the same size is needed to run the pvmove operation to. 

LV
 |
  VG: LOOP_VG [ ]
 |
  PV: /dev/loop0   -->   /dev/mapper/enc-loop
  ( backed by /dev/mapper/enc-loop )

  The physical volumes are backed by loopback devices (losetup) to base the
  problem report on, but we have seen the error on real SCSI multipath volumes
  also, with and without cryptsetup mapper devices in use.

  
  Further discussion
  ==
  https://www.saout.de/pipermail/dm-crypt/2019-February/006078.html
  The problem does not occur on block devices with native size of 4k.
  E.g. DASDs, or file systems with mkfs -b 4096 option.

  
  Terminal output
  ===
  See attached file pvmove-error.txt

  
  Debug data
  ==
  pvmove was run with -dd (maximum debug level)
  See attached journal file.
   
  Contact Information = christian.r...@de.ibm.com 
   
  ---uname output---
  Linux system 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:00:35 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = IBM Type: 2964 Model: 701 NC9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1.) Create two image files of 500MB in size
  and set up two loopback devices with 'losetup -fP FILE'
  2.) Create one physical volume and one volume group 'LOOP_VG',
  and one logical volume 'VG'
  Run:
  pvcreate /dev/loop0
  vgcreate LOOP_VG /dev/loop0
  lvcreate -L 300MB LOOP_VG -n LV /dev/loop0
  3.) Create a file system on the logical volume device:
  mkfs.ext4 /dev/mapper/LOOP_VG-LV
  4.) mount the file system created in the previous step to some empty 
available directory:
  mount /dev/mapper/LOOP_VG-LV /mnt
  5.) Set up a second physical volume, this time encrypted with LUKS2,
  and open the volume to make it available:
  cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1
  cryptsetup luksOpen /dev/loop1 enc-loop
  6.) Create the second physical volume, and add it to the LOOP_VG
  pvcreate /dev/mapper/enc-loop
  vgextend LOOP_VG /dev/mapper/enc-loop
  7.) Ensure the new physical volume is part of the volume group:
  pvs
  8.) Move the /dev/loop0 volume onto the encrypted volume with 

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

2019-05-28 Thread Launchpad Bug Tracker
This bug was fixed in the package busybox - 1:1.30.1-4ubuntu4

---
busybox (1:1.30.1-4ubuntu4) eoan; urgency=medium

  * Revert previous upload, cherrypick upstream fix for the issue. LP:
#1828282
  * Adjust testsuite expectations.

 -- Dimitri John Ledkov   Thu, 23 May 2019 14:37:05
+0100

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to 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 BusyBox:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Invalid
Status in busybox package in Ubuntu:
  Fix Released
Status in glibc package in Ubuntu:
  Invalid

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/busybox/+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 1778844] Re: nvme multipath does not report path relationships

2019-05-28 Thread Launchpad Bug Tracker
This bug was fixed in the package initramfs-tools - 0.130ubuntu3.8

---
initramfs-tools (0.130ubuntu3.8) bionic; urgency=medium

  * Add modules for nvme path components on multipath nvme. LP: #1778844

 -- Thadeu Lima de Souza Cascardo   Tue, 16 Apr
2019 21:25:56 -0300

** Changed in: initramfs-tools (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 initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

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

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

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

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

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

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

  -

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

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

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

  >. Crashkernel value as below

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

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

  >  kdump status

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

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

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

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

  > Triggered crash

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

[Touch-packages] [Bug 1778844] Update Released

2019-05-28 Thread Brian Murray
The verification of the Stable Release Update for initramfs-tools 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 initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

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

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

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

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

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

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

  -

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

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

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

  >. Crashkernel value as below

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

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

  >  kdump status

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

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

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

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

  > Triggered crash

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

[Touch-packages] [Bug 1830502] Re: apparmor fails to start with no parser errors

2019-05-28 Thread John Johansen
I'm not aware of any way to get the apparmor.service to print out what
profile it is working on without actually modifying the service

however your dmesg does show the reason for the failure, it looks like
the apparmor_parser is being killed by the oom killer

[ 5986.338089] [13520] 0 13520  3056587  3053749 245391360  
   0 apparmor_parser
[ 5986.338090] Out of memory: Kill process 13520 (apparmor_parser) score 646 or 
sacrifice child
[ 5986.338095] Killed process 13520 (apparmor_parser) total-vm:12226348kB, 
anon-rss:12214996kB, file-rss:0kB, shmem-rss:0kB

we should be able to narrow down which profile is causing the problem by
comparing the set of profiles being reported as loaded to those that are
on the system.

We can then manually run the apparmor_parser to see which profile is
using some much memory to compile

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

Title:
  apparmor fails to start with no parser errors

Status in apparmor package in Ubuntu:
  New

Bug description:
  On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
  my system was unable to finish booting and I had to go into recovery
  mode and remove a number of files before the system would boot. After
  doing so I discovered that now the apparmor.service systemd unit
  always fails to start. I see this in dmesg:

  [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 
or sacrifice child
  [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, 
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
  [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now 
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

  Whenever apparmor.service is attempted to be started by systemd, i.e.
  either on boot, or later with `systemctl start apparmor`.

  The log from journalctl doesn't show any actual issues with any
  profiles just this:

  -- Reboot --
  May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
  May 25 17:00:58 apparmor[1521]:  * Starting AppArmor profiles
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:01:40 apparmor[1521]:...fail!
  May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
  May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
  May 25 17:04:53 apparmor[4747]:  * Starting AppArmor profiles
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:05:25 apparmor[4747]:...fail!
  May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.

  I can see that apparmor profiles are active after doing this (using
  aa-status), but it's still troubling that apparmor runs into an issue
  without actually saying what the error is.

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

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread Frank Heimes
** Changed in: lvm2 (Ubuntu)
 Assignee: Canonical Foundations Team (canonical-foundations) => 
(unassigned)

** Changed in: ubuntu-power-systems
 Assignee: Canonical Foundations Team (canonical-foundations) => Canonical 
Server Team (canonical-server)

-- 
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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

2019-05-28 Thread Ubuntu Foundations Team Bug Bot
The attachment "fix-memlock-bump.patch" seems to be a patch.  If it
isn't, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are a member of the ~ubuntu-reviewers,
unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

** Tags added: patch

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  New

Bug description:
  See also https://discuss.linuxcontainers.org/t/limits-kernel-memlock-
  cannot-exceed-16777216/4856/5

  In containers, the limits.kernel.memlock cannot exceed 16777216 when
  the container is bionic. The memlock setting is set to 16M in systemd
  and cannot be bumped up in an unprivileged container.

  This is fixed in upstream systemd.

  Container ubuntu version:
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04
  Codename: bionic

  systemd package version: 237-3ubuntu10.21

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

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


[Touch-packages] [Bug 1830502] Re: apparmor fails to start with no parser errors

2019-05-28 Thread Ian Johnson
Well I tried restarting AppArmor using `systemctl start apparmor` while
running `dmesg -w -k` and got the following log:
https://pastebin.ubuntu.com/p/98zXMsr6Sy/ I don't see a stack trace for
apparmor itself, just for chrome and pulseaudio.

Is there anyway to have apparmor.service show what profiles it's trying
to load to see what profile it might be trying to load when it is
killed?

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

Title:
  apparmor fails to start with no parser errors

Status in apparmor package in Ubuntu:
  New

Bug description:
  On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
  my system was unable to finish booting and I had to go into recovery
  mode and remove a number of files before the system would boot. After
  doing so I discovered that now the apparmor.service systemd unit
  always fails to start. I see this in dmesg:

  [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 
or sacrifice child
  [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, 
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
  [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now 
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

  Whenever apparmor.service is attempted to be started by systemd, i.e.
  either on boot, or later with `systemctl start apparmor`.

  The log from journalctl doesn't show any actual issues with any
  profiles just this:

  -- Reboot --
  May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
  May 25 17:00:58 apparmor[1521]:  * Starting AppArmor profiles
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:01:40 apparmor[1521]:...fail!
  May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
  May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
  May 25 17:04:53 apparmor[4747]:  * Starting AppArmor profiles
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:05:25 apparmor[4747]:...fail!
  May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.

  I can see that apparmor profiles are active after doing this (using
  aa-status), but it's still troubling that apparmor runs into an issue
  without actually saying what the error is.

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

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


[Touch-packages] [Bug 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

2019-05-28 Thread Kees Bos
** Patch added: "fix-memlock-bump.patch"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+attachment/5267179/+files/fix-memlock-bump.patch

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  New

Bug description:
  See also https://discuss.linuxcontainers.org/t/limits-kernel-memlock-
  cannot-exceed-16777216/4856/5

  In containers, the limits.kernel.memlock cannot exceed 16777216 when
  the container is bionic. The memlock setting is set to 16M in systemd
  and cannot be bumped up in an unprivileged container.

  This is fixed in upstream systemd.

  Container ubuntu version:
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04
  Codename: bionic

  systemd package version: 237-3ubuntu10.21

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

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread Andrey Grebennikov
Yes, it is latest - the cluster is being re-deployed as part of
Bootstack handover.

Corey,
The bug you point to is fixing the sequence of ceph/udev. Here however udev 
can't create any devices as they don't exist at the moment of udev run seems so 
- when the host boots and settles down - there is no PVs exist at all.

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

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 1829566] Re: network-manager 1.10.14-0ubuntu2 ignores systemd-resolved configured dns

2019-05-28 Thread Till Kamppeter
Sorry there was a part missing. Let us try again:

Please create the following files (and directories if needed for them):

1. /etc/systemd/journald.d/noratelimit.conf containing

RateLimitIntervalSec=0
RateLimitBurst=0

2. /etc/NetworkManager/conf.d/debug.conf

[logging]
level=TRACE
domains=ALL

Then restart journald:

sudo systemctl restart systemd-journald

and NetworkManager:

sudo systemctl restart network-manager

Then you get the full debug log of NetworkManager via

journalctl -u NetworkManager

After all that, reboot and/or connect to your VPN and do

journalctl -u NetworkManager > log.txt

and attach the log.txt file to this bug report. Do not compress the file
and do not package it together with other files.

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

Title:
  network-manager 1.10.14-0ubuntu2 ignores systemd-resolved configured
  dns

Status in network-manager package in Ubuntu:
  Incomplete
Status in network-manager source package in Bionic:
  Incomplete

Bug description:
  On 18.04.2 the `upgrade network-manager:amd64 1.10.6-2ubuntu1.1
  1.10.14-0ubuntu2` lead to scoped DNS servers defined in
  `/etc/systemd/resolved.conf.d/*.conf` being ignored.

  Downgrading with `sudo apt-get install network-
  manager=1.10.6-2ubuntu1.1` has resolved the issue for now.

  Example systemd-resolved conf:

  [Resolve]
  Cache=no
  DNS=127.0.0.54
  Domains=~.local.org.com

  Where 127.0.0.54:53 is bound to a dnsmasq server capable of resolving
  queries in that subdomain.

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

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


[Touch-packages] [Bug 1830746] [NEW] memlock setting in systemd (pid 1) too low for containers (bionic)

2019-05-28 Thread Kees Bos
Public bug reported:

See also https://discuss.linuxcontainers.org/t/limits-kernel-memlock-
cannot-exceed-16777216/4856/5

In containers, the limits.kernel.memlock cannot exceed 16777216 when the
container is bionic. The memlock setting is set to 16M in systemd and
cannot be bumped up in an unprivileged container.

This is fixed in upstream systemd.

Container ubuntu version:
Distributor ID: Ubuntu
Description:Ubuntu 18.04.2 LTS
Release:18.04
Codename:   bionic

systemd package version: 237-3ubuntu10.21

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  New

Bug description:
  See also https://discuss.linuxcontainers.org/t/limits-kernel-memlock-
  cannot-exceed-16777216/4856/5

  In containers, the limits.kernel.memlock cannot exceed 16777216 when
  the container is bionic. The memlock setting is set to 16M in systemd
  and cannot be bumped up in an unprivileged container.

  This is fixed in upstream systemd.

  Container ubuntu version:
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04
  Codename: bionic

  systemd package version: 237-3ubuntu10.21

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

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


[Touch-packages] [Bug 1829838] Re: 1.10.14-0ubuntu2 breaks DNS propagation from VPN

2019-05-28 Thread Till Kamppeter
Sorry there was a part missing. Let us try again:

Please create the following files (and directories if needed for them):

1. /etc/systemd/journald.d/noratelimit.conf containing

RateLimitIntervalSec=0
RateLimitBurst=0

2. /etc/NetworkManager/conf.d/debug.conf

[logging]
level=TRACE
domains=ALL

Then restart journald:

sudo systemctl restart systemd-journald

and NetworkManager:

sudo systemctl restart network-manager

Then you get the full debug log of NetworkManager via

journalctl -u NetworkManager

After all that, reboot and/or connect to your VPN and do

journalctl -u NetworkManager > log.txt

and attach the log.txt file to this bug report. Do not compress the file
and do not package it together with other files.

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

Title:
  1.10.14-0ubuntu2 breaks DNS propagation from VPN

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  I have an OpenVPN connection, and I use the update-systemd-resolved to
  correctly fetch the DNS from the VPN. The issue arose updating my
  Ubuntu 18.04: the script is no longer invoked, and even invoking it
  manually (sudo openvpn myfile.ovpn) does not work anymore, even if in
  that case systemd-resolve --status shows the new DNS on the interface
  correctly.

  As suggested in https://bugs.launchpad.net/ubuntu/+source/network-
  manager/+bug/120/comments/99, reverting to 1.10.6-2ubuntu1.1 fixes
  the issue.

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

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


[Touch-packages] [Bug 1829913] Re: openconnect VPN is not propagating internal DNS anymore

2019-05-28 Thread Till Kamppeter
Sorry there was a part missing. Let us try again:

Please create the following files (and directories if needed for them):

1. /etc/systemd/journald.d/noratelimit.conf containing

RateLimitIntervalSec=0
RateLimitBurst=0

2. /etc/NetworkManager/conf.d/debug.conf

[logging]
level=TRACE
domains=ALL

Then restart journald:

sudo systemctl restart systemd-journald

and NetworkManager:

sudo systemctl restart network-manager

Then you get the full debug log of NetworkManager via

journalctl -u NetworkManager

After all that, reboot and/or connect to your VPN and do

journalctl -u NetworkManager > log.txt

and attach the log.txt file to this bug report. Do not compress the file
and do not package it together with other files.

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

Title:
  openconnect VPN is not propagating internal DNS anymore

Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  Openconnect VPN stopped propagating DNSes to the system.

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

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread James Page
Please can you confirm which version of the ceph-osd package you have
installed; older versions rely on a charm shipped udev ruleset, rather
than it being provided by the packaging.

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

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 1828617] Re: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration

2019-05-28 Thread Corey Bryant
This feels similar to https://bugs.launchpad.net/charm-ceph-
osd/+bug/1812925. First question, are you running with the latest stable
charms which have the fix for that bug?

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

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 1830744] [NEW] Not able to get updated version of Driver

2019-05-28 Thread Deep Jari
Public bug reported:

Hey Support ,

I am not able to get resolution of my Monitor which is 1080P, I checked
with the cables and its all good. I think drivers are causing this
issue. Might need help with that.

Regards

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20
Uname: Linux 4.18.0-21-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Tue May 28 20:04:43 2019
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller 
[8086:0162] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Hewlett-Packard Company Xeon E3-1200 v2/3rd Gen Core processor 
Graphics Controller [103c:339a]
InstallationDate: Installed on 2019-03-12 (77 days ago)
InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
MachineType: Hewlett-Packard HP Compaq Pro 6300 SFF
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-21-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/16/2013
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: K01 v02.90
dmi.board.asset.tag: SGH333S866
dmi.board.name: 339A
dmi.board.vendor: Hewlett-Packard
dmi.chassis.asset.tag: SGH333S866
dmi.chassis.type: 4
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: 
dmi:bvnHewlett-Packard:bvrK01v02.90:bd07/16/2013:svnHewlett-Packard:pnHPCompaqPro6300SFF:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct4:cvr:
dmi.product.family: 103C_53307F G=D
dmi.product.name: HP Compaq Pro 6300 SFF
dmi.product.sku: QV985AV
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1~18.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.2-1ubuntu1~18.04.1
version.xserver-xorg-core: xserver-xorg-core N/A
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

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


** Tags: amd64 apport-bug bionic ubuntu

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

Title:
  Not able to get updated version of Driver

Status in xorg package in Ubuntu:
  New

Bug description:
  Hey Support ,

  I am not able to get resolution of my Monitor which is 1080P, I
  checked with the cables and its all good. I think drivers are causing
  this issue. Might need help with that.

  Regards

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20
  Uname: Linux 4.18.0-21-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue May 28 20:04:43 2019
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller 
[8086:0162] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Xeon E3-1200 v2/3rd Gen Core processor 
Graphics Controller [103c:339a]
  InstallationDate: Installed on 2019-03-12 (77 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Hewlett-Packard HP Compaq Pro 6300 SFF
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-21-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/16/2013
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: K01 v02.90
  dmi.board.asset.tag: SGH333S866
  dmi.board.name: 339A
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: SGH333S866
  dmi.chassis.type: 4
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrK01v02.90:bd07/16/2013:svnHewlett-Packard:pnHPCompaqPro6300SFF:pvr:rvnHewlett-Packard:rn339A:rvr:cvnHewlett-Packard:ct4:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP Compaq Pro 6300 SFF
  dmi.product.sku: QV985AV
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1~18.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.2-1ubuntu1~18.04.1
  

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

2019-05-28 Thread James Page
The ceph-osd package provide udev rules which should switch the owner
for all ceph related LVM VG's to ceph:ceph.

# OSD LVM layout example
# VG prefix: ceph-
# LV prefix: osd-
ACTION=="add", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="disk", \
  ENV{DM_LV_NAME}=="osd-*", \
  ENV{DM_VG_NAME}=="ceph-*", \
  OWNER:="ceph", GROUP:="ceph", MODE:="660"
ACTION=="change", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="disk", \
  ENV{DM_LV_NAME}=="osd-*", \
  ENV{DM_VG_NAME}=="ceph-*", \
  OWNER="ceph", GROUP="ceph", MODE="660"

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

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 1828617] Re: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration

2019-05-28 Thread James Page
by-dname udev rules are created by MAAS/curtin as part of the server
install I think.

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

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 1830022] Re: DirtyCleanInterval should be 0 by default

2019-05-28 Thread Dariusz Gadomski
** Tags removed: rls-nn-incoming

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

Title:
  DirtyCleanInterval should be 0 by default

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  Please consider changing DirtyCleanInterval value to 0 as default.

  Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy
  workload even hundreds of jobs may be lost. This concern is backed up
  by a real-life scenario and leaves the client sending thousands of
  jobs unaware that many of them are lost during a crash.

  After cupsd gets restarted it rewinds it's job counter to the last
  cached and continues unaware about the jobs accepted and lost.

  Having DirtyCleanInterval set to 0 will cause some performance impact,
  but not significant under lighter workloads and a completely justified
  price for reliability under heavy workloads.

  Test scenario:
  1. sudo apt install printer-driver-cups-pdf
  2. while [ 1 ]; do lp -d PDF somepdf.pdf; done;
  3. # on other terminal
 kill -9 $(pidof cupsd)
  4. Note last job number and wait for cupsd to be restarted by systemd.
  5. Once accepting jobs is resumend the job counter is rewound.

  Expected behavior:
  Accepted jobs are queued for processing.

  Actual behavior:
  Some accepted jobs are lost.

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

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread Andrey Grebennikov
Steve,
This is MAAS who creates these udev rules. We requested this feature to be 
implemented in order to be able to use persistent names in further services 
configuration (using templating). We couldn't go with /dev/sdX names as they 
may change after the reboot, and can't use wwn names as they are unique per 
node and don't allow us to use templates with FCB.

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

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 1825940] Re: [graphics] Enable ICL

2019-05-28 Thread Launchpad Bug Tracker
This bug was fixed in the package mesa - 19.0.5-0ubuntu1

---
mesa (19.0.5-0ubuntu1) eoan; urgency=medium

  * New upstream bugfix release.
  * icl-backport.diff: Backport support for fast color clears and
bugfixes for Ice Lake (LP: #1825940).

 -- Timo Aaltonen   Tue, 28 May 2019 11:54:16 +0300

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

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

Title:
  [graphics] Enable ICL

Status in intel:
  Fix Committed
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Invalid
Status in linux-oem-osp1 source package in Bionic:
  New
Status in mesa source package in Bionic:
  New

Bug description:
  [Impact]
  Ice Lake (ICL) graphics needs to be enabled for OEM OSP1 image which is based 
on 18.04.3 graphics stack with linux-oem-osp1 kernel.

  
  [Test case]
  The usual desktop usage, graphics tests etc.

  
  [Regression potential]
  Linux-oem-osp1 kernel is a new kernel used only on new OEM enablements, and 
it can't regress any currently running system.

  Mesa backports are limited to ICL, so they shouldn't regress earlier
  generations either.

  --

  Original description:

  ICL graphics is not enabled in 19.04.
  if you want to use 19.04 on ICL platform, you need do like this

  Add kernel option
  i915.alpha_support=1

  Target Release:19.10
  Target Kernel: 5.2
  Target Mesa: 19.1

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

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


[Touch-packages] [Bug 1162475] Re: [hostnamed] Changing hostname doesn't update /etc/hosts

2019-05-28 Thread Sebastien Bacher
** Changed in: gnome-control-center (Ubuntu)
   Status: Triaged => 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/1162475

Title:
  [hostnamed] Changing hostname doesn't update /etc/hosts

Status in gnome-control-center package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Triaged
Status in unity-control-center package in Ubuntu:
  Won't Fix
Status in gnome-control-center source package in Xenial:
  New
Status in systemd source package in Xenial:
  Triaged
Status in unity-control-center source package in Xenial:
  New
Status in gnome-control-center package in Debian:
  Fix Released

Bug description:
  GUI
  ---
  1a. Run sudo gnome-control-center, or...
  1b. Save the gnome-control-center.pkla from 
https://bazaar.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/revision/556
 to /var/lib/polkit-1/localauthority/10-vendor.d/ and then run 
gnome-control-center as an admin user

  2. Enter the Details panel
  3. The "Device name" (hostname) text field should be editable; change the 
text to something else.
  4. The hostname is updated instantly which can be verified by looking in 
/etc/hostname. However /etc/hosts/ is not updated.

  Command line
  
  hostnamectl set-hostname

  The hostnamed documentation at 
http://www.freedesktop.org/wiki/Software/systemd/hostnamed says
  "To properly handle name lookups with changing local hostnames without having 
to edit /etc/hosts for them we recommend using hostnamed in combination with 
nss-myhostname: http://0pointer.de/lennart/projects/nss-myhostname/ "

  Without /etc/hosts being handled correctly, the hostnamed integration
  is only half-working.


  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: gnome-control-center 1:3.6.3-0ubuntu18
  ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4
  Uname: Linux 3.8.0-15-generic x86_64
  ApportVersion: 2.9.2-0ubuntu5
  Architecture: amd64
  Date: Sun Mar 31 08:52:57 2013
  MarkForUpload: True
  SourcePackage: gnome-control-center
  UpgradeStatus: No upgrade log present (probably fresh install)
  usr_lib_gnome-control-center:
   activity-log-manager-control-center 0.9.4-0ubuntu6.1
   deja-dup26.0-0ubuntu1
   gnome-control-center-signon 0.1.5-0ubuntu1
   gnome-control-center-unity  1.2daily13.02.15-0ubuntu1
   indicator-datetime  12.10.3daily13.03.26-0ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1162475/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread Sebastien Bacher
** Changed in: network-manager (Ubuntu Bionic)
 Assignee: (unassigned) => Till Kamppeter (till-kamppeter)

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

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 1830022] Re: DirtyCleanInterval should be 0 by default

2019-05-28 Thread Dariusz Gadomski
** Tags added: rls-nn-incoming

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

Title:
  DirtyCleanInterval should be 0 by default

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  Please consider changing DirtyCleanInterval value to 0 as default.

  Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy
  workload even hundreds of jobs may be lost. This concern is backed up
  by a real-life scenario and leaves the client sending thousands of
  jobs unaware that many of them are lost during a crash.

  After cupsd gets restarted it rewinds it's job counter to the last
  cached and continues unaware about the jobs accepted and lost.

  Having DirtyCleanInterval set to 0 will cause some performance impact,
  but not significant under lighter workloads and a completely justified
  price for reliability under heavy workloads.

  Test scenario:
  1. sudo apt install printer-driver-cups-pdf
  2. while [ 1 ]; do lp -d PDF somepdf.pdf; done;
  3. # on other terminal
 kill -9 $(pidof cupsd)
  4. Note last job number and wait for cupsd to be restarted by systemd.
  5. Once accepting jobs is resumend the job counter is rewound.

  Expected behavior:
  Accepted jobs are queued for processing.

  Actual behavior:
  Some accepted jobs are lost.

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

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


[Touch-packages] [Bug 1825940] Re: [graphics] Enable ICL

2019-05-28 Thread Timo Aaltonen
** Changed in: mesa (Ubuntu Bionic)
 Assignee: (unassigned) => Timo Aaltonen (tjaalton)

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

Title:
  [graphics] Enable ICL

Status in intel:
  Fix Committed
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  Invalid
Status in linux-oem-osp1 source package in Bionic:
  New
Status in mesa source package in Bionic:
  New

Bug description:
  [Impact]
  Ice Lake (ICL) graphics needs to be enabled for OEM OSP1 image which is based 
on 18.04.3 graphics stack with linux-oem-osp1 kernel.

  
  [Test case]
  The usual desktop usage, graphics tests etc.

  
  [Regression potential]
  Linux-oem-osp1 kernel is a new kernel used only on new OEM enablements, and 
it can't regress any currently running system.

  Mesa backports are limited to ICL, so they shouldn't regress earlier
  generations either.

  --

  Original description:

  ICL graphics is not enabled in 19.04.
  if you want to use 19.04 on ICL platform, you need do like this

  Add kernel option
  i915.alpha_support=1

  Target Release:19.10
  Target Kernel: 5.2
  Target Mesa: 19.1

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

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


[Touch-packages] [Bug 1830022] Re: DirtyCleanInterval should be 0 by default

2019-05-28 Thread Sebastien Bacher
** No longer affects: cups (Ubuntu Xenial)

** No longer affects: cups (Ubuntu Bionic)

** No longer affects: cups (Ubuntu Cosmic)

** No longer affects: cups (Ubuntu Disco)

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

Title:
  DirtyCleanInterval should be 0 by default

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  Please consider changing DirtyCleanInterval value to 0 as default.

  Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy
  workload even hundreds of jobs may be lost. This concern is backed up
  by a real-life scenario and leaves the client sending thousands of
  jobs unaware that many of them are lost during a crash.

  After cupsd gets restarted it rewinds it's job counter to the last
  cached and continues unaware about the jobs accepted and lost.

  Having DirtyCleanInterval set to 0 will cause some performance impact,
  but not significant under lighter workloads and a completely justified
  price for reliability under heavy workloads.

  Test scenario:
  1. sudo apt install printer-driver-cups-pdf
  2. while [ 1 ]; do lp -d PDF somepdf.pdf; done;
  3. # on other terminal
 kill -9 $(pidof cupsd)
  4. Note last job number and wait for cupsd to be restarted by systemd.
  5. Once accepting jobs is resumend the job counter is rewound.

  Expected behavior:
  Accepted jobs are queued for processing.

  Actual behavior:
  Some accepted jobs are lost.

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

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


[Touch-packages] [Bug 1768166] Re: Random crashes

2019-05-28 Thread Łukasz Zemczak
So generally, with my SRU hat on, after a longer discussion with Gunnar
I think we should give the backport a spin - but under specific
conditions. We would be keeping the SRU in -proposed for longer than 7
days and I'd appreciate some wider-testing during that time (maybe some
call for testing?).

** Description changed:

  [Impact]
  
  ibus-libpinyin has proved to crash far too often. One or more files in
  ~/.cache/ibus/libpinyin get corrupted somehow, and emptying that
  directory allows the user to keep using ibus-libpinyin.
  
  In disco (and eoan) ibus-libpinyin 1.11.0 and libpinyin 2.2.2 are
  present, and the number of crashes has been reduced significantly:
  
  https://errors.ubuntu.com/?package=ibus-libpinyin=month
  
  Upstream ChangeLog ibus-libpinyin:
  --
  version 1.11.0
  * fixes keypad decimal
  * fixes emoji candidates
  * support configurable opencc config
  
  version 1.10.92
  * fixes Enter handling
  
  version 1.10.91
  * support ime.register_trigger in lua extension
  * support predicted candidates
  * support emoji input
  
  version 1.10.0
  * bug fixes
  
  version 1.9.91
  * migrate to use GSettings
  * fixes lyx short cut issue
  
  version 1.9.3
  * translate input method name in ibus menu
  
  Upstream ChangeLog libpinyin:
  -
  version 2.2.2
  * minor fixes
  
  version 2.2.1
  * fixes predicted candidates
  
  version 2.2.0
  * bug fixes
  
  The proposal is to backport the disco versions of those packages to
  bionic and cosmic in an attempt to prevent crashes. Proposed uploads are
  available in this PPA:
  
  https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus-libpinyin
  
  [Test Case]
  
  * Install from {bionic,cosmic}-proposed:
    - libpinyin13
    - libpinyin-data
    - ibus-libpinyin
  
  * Use "Intelligent Pinyin" for typing and confirm that no new issues
    show up when doing so.
  
  (This is apparently not a confirmation that the upload really fixes the
  bug. To compensate for that, we will await testing of the -proposed
  packages by a few Chinese users before considering the uploads
  verified.)
  
  Reverse dependencies
  
  Besides ibus-libpinyin, also fcitx-libpinyin and ibus-zhuyin depend on 
packages belonging to the libpinyin source package. So additional test measures 
are:
  
  * Install fcitx-libpinyin and ibus-zhuyin.
  
  * Use both those tools for typing Chinese, and confirm that you don't
-   observe any adverse effects of the libpinyin upgrade.
+   observe any adverse effects of the libpinyin upgrade.
  
  [Regression Potential]
  
  The changes are mostly bug fixes, so the regression risk should be
  limited. Also consider that the starting point is a rather unstable
  functionality.
+ 
+ NOTE TO SRU TEAM: Please let the SRU age for longer than 7 days to get
+ as much testing as possible. There do not seem to be too many risky
+ changes carried, but such jumps in upstream versions always carry some
+ regression-risk.
  
  [Original description]
  
  I have experienced random ibus-libpinyin crashes in bionic.  I cannot
  reproduce it, but it occurred at least a few times, even after the
  official bionic release.  Same crashes were also reported in the Ubuntu
  Chinese forum.
  
  Currently, the workaround is to delete the ~/.cache/ibus/libpinyin
  folder.
  
  I talked to Peng Wu, ibus-libpinyin's creator and main maintainer, he
  suggested that we update the version of ibus-libpinyin to 1.10.
  
  Can we give this update a trial?

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

Title:
  Random crashes

Status in ibus-libpinyin package in Ubuntu:
  Fix Released
Status in libpinyin package in Ubuntu:
  Fix Released
Status in ibus-libpinyin source package in Bionic:
  In Progress
Status in libpinyin source package in Bionic:
  In Progress
Status in ibus-libpinyin source package in Cosmic:
  In Progress
Status in libpinyin source package in Cosmic:
  In Progress

Bug description:
  [Impact]

  ibus-libpinyin has proved to crash far too often. One or more files in
  ~/.cache/ibus/libpinyin get corrupted somehow, and emptying that
  directory allows the user to keep using ibus-libpinyin.

  In disco (and eoan) ibus-libpinyin 1.11.0 and libpinyin 2.2.2 are
  present, and the number of crashes has been reduced significantly:

  https://errors.ubuntu.com/?package=ibus-libpinyin=month

  Upstream ChangeLog ibus-libpinyin:
  --
  version 1.11.0
  * fixes keypad decimal
  * fixes emoji candidates
  * support configurable opencc config

  version 1.10.92
  * fixes Enter handling

  version 1.10.91
  * support ime.register_trigger in lua extension
  * support predicted candidates
  * support emoji input

  version 1.10.0
  * bug fixes

  version 1.9.91
  * migrate to use GSettings
  * fixes lyx short cut 

[Touch-packages] [Bug 1821269] Re: [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch (4-pole combo jack mic doesn't detect)

2019-05-28 Thread Ji-min Hong
I will take your opinion. Thank you.

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

Title:
  [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch (4-pole
  combo jack mic doesn't detect)

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  I use realtek alc255 analog audio jack. External jack is 4 pole combo(apple 
type. not europe type.).
  When I plug 4 pole mic into jack, It doesn't detect.
  So I can't my voice through external mic.

  My laptop has internal mic. It belongs to Intel sound(HDA Intel PCH. Audio 
device: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx 
Series High Definition Audio Controller (rev 21)).
  Internal mic works well.

  Please check 4pole external mic detection.

  Thank you.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
  Uname: Linux 4.15.0-46-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0c:   jimnong1441 F...m pulseaudio
   /dev/snd/pcmC0D0p:   jimnong1441 F...m pulseaudio
   /dev/snd/controlC0:  jimnong1441 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 22 11:30:39 2019
  InstallationDate: Installed on 2017-07-27 (603 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: 내장 오디오 - HDA Intel PCH
  Symptom_Jack: Mic, Internal
  Symptom_Type: No auto-switch between inputs
  Title: [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch
  UpgradeStatus: Upgraded to bionic on 2018-09-23 (179 days ago)
  dmi.bios.date: 09/06/2016
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: V1.24
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: Garp_BA
  dmi.board.vendor: Acer
  dmi.board.version: V1.24
  dmi.chassis.type: 10
  dmi.chassis.vendor: Chassis Manufacturer
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.24:bd09/06/2016:svnAcer:pnAspireES1-131:pvrV1.24:rvnAcer:rnGarp_BA:rvrV1.24:cvnChassisManufacturer:ct10:cvrChassisVersion:
  dmi.product.family: BSW
  dmi.product.name: Aspire ES1-131
  dmi.product.version: V1.24
  dmi.sys.vendor: Acer

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

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


[Touch-packages] [Bug 1695601] Re: IPv6 temporary/privacy addresses lifetime are not renewed upon new ICMPv6 Router-Advertisement packet

2019-05-28 Thread Pirouette Cacahuète
Newer versions of NetworkManager, after upgrading from 17.04, have been
bundling the proper fix.

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

Title:
  IPv6 temporary/privacy addresses lifetime are not renewed upon new
  ICMPv6 Router-Advertisement packet

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  My ISP's router provides IPv6 connectivity and advertises valid
  lifetime of 900 secs and preferred lifetime of 300 secs. My Ubuntu
  17.04 (and previous) installation has been showing weird behavior over
  IPv6, with connections dropping quite often but on a regular basis.

  After extensive debugging and verification that there was no issue on router 
side, and on WiFi physical connection, I have verified that this was not 
related to the lack of ICMPv6 RA packets.
  Running |watch -d -n1 ip -6 addr show dev wlan0| shows:
   - decreasing valid_lft and preferred_lft on both IPv6 addresses
   - upon ICMPv6 RA packet received, the global SLAAC address derived from MAC 
gets valid_lft and preferred_lft field updated
   - at the same time, the privacy extension address is still decreasing

  System uses NetworkManager to handle all of that. I could verify that
  my desktop system, running Debian Sid with NetworkManager v1.6 was not
  exposing the issue.

  Running NetworkManager in debug mode gives more informations:
  > nm_ubuntu_zesty.log:NetworkManager[2418]:  [1496447074.7897] 
platform-linux: event-notification: NEWADDR, seq 0: 
2a01:::::::39c5/64 lft 900sec pref 300sec lifetime 
289-289[300,900] dev 3 flags secondary src kernel
  > nm_ubuntu_zesty.log:NetworkManager[2418]:  [1496447074.7901] 
platform-linux: event-notification: NEWADDR, seq 0: 
2a01:::::::39c5/64 lft 622sec pref 22sec lifetime 
289-289[22,622] dev 3 flags secondary src kernel

  The two timestamps of the NEWADDR event are very very close. The first
  one shows proper update of the lifetimes values ; while the second one
  shows invalid values being pushed. With those informations in mind, I
  dug a little bit in the NetworkManager source code, and I found that
  there was one change between v1.4.4 (current Zesty package) and v1.6
  (Debian sid package) that was touching the code handling IPv6
  addresses sync:
  
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1dbd9d7948
  ; the commit states that without this change, NM might overwrite IPv6
  temporary addresses changes.

  I took my chance and rebuilt network-manager-1.4.4 package with that
  patch included: IPv6 temporary privacy extensions enabled addresses
  gets proper updates of their lifetime when ICMPv6 packets reaches my
  system.

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

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


[Touch-packages] [Bug 1830705] [NEW] [HDA-Intel - HDA Intel PCH, playback] No sound at all

2019-05-28 Thread Jack Jackson
Public bug reported:

I have dual-booted Ubuntu and Windows and I don't have sound at all.
Before when restart laptop sound back shortly but if I boot it again
there is no sound anymore. Interesting, when type alsamixer I get cannot
open mixer: No such file or directory. I'm noticing that I have
installed driver. Sound sometimes works sometimes not

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 4.4.0-146.172-generic 4.4.177
Uname: Linux 4.4.0-146-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC1:  lukab  1862 F pulseaudio
CurrentDesktop: Unity
Date: Tue May 28 11:35:56 2019
InstallationDate: Installed on 2019-05-09 (18 days ago)
InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed
Symptom_Card: Built-in Audio - HDA Intel PCH
Symptom_DevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC1:  lukab  1862 F pulseaudio
Symptom_Type: No sound at all
Title: [HDA-Intel - HDA Intel PCH, playback] No sound at all
UpgradeStatus: Upgraded to xenial on 2019-05-09 (18 days ago)
dmi.bios.date: 09/08/2016
dmi.bios.vendor: Insyde
dmi.bios.version: F.17
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 81EE
dmi.board.vendor: HP
dmi.board.version: 62.29
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnInsyde:bvrF.17:bd09/08/2016:svnHP:pnHPNotebook:pvrType1ProductConfigId:rvnHP:rn81EE:rvr62.29:cvnHP:ct10:cvrChassisVersion:
dmi.product.name: HP Notebook
dmi.product.version: Type1ProductConfigId
dmi.sys.vendor: HP
mtime.conffile..etc.modprobe.d.alsa-base.conf: 2019-05-20T21:39:20.719208

** Affects: alsa-driver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug xenial

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

Title:
  [HDA-Intel - HDA Intel PCH, playback] No sound at all

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  I have dual-booted Ubuntu and Windows and I don't have sound at all.
  Before when restart laptop sound back shortly but if I boot it again
  there is no sound anymore. Interesting, when type alsamixer I get
  cannot open mixer: No such file or directory. I'm noticing that I have
  installed driver. Sound sometimes works sometimes not

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-146.172-generic 4.4.177
  Uname: Linux 4.4.0-146-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  lukab  1862 F pulseaudio
  CurrentDesktop: Unity
  Date: Tue May 28 11:35:56 2019
  InstallationDate: Installed on 2019-05-09 (18 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  lukab  1862 F pulseaudio
  Symptom_Type: No sound at all
  Title: [HDA-Intel - HDA Intel PCH, playback] No sound at all
  UpgradeStatus: Upgraded to xenial on 2019-05-09 (18 days ago)
  dmi.bios.date: 09/08/2016
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.17
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 81EE
  dmi.board.vendor: HP
  dmi.board.version: 62.29
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.17:bd09/08/2016:svnHP:pnHPNotebook:pvrType1ProductConfigId:rvnHP:rn81EE:rvr62.29:cvnHP:ct10:cvrChassisVersion:
  dmi.product.name: HP Notebook
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP
  mtime.conffile..etc.modprobe.d.alsa-base.conf: 2019-05-20T21:39:20.719208

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

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


[Touch-packages] [Bug 1825940] Re: [graphics] Enable ICL

2019-05-28 Thread Timo Aaltonen
** Description changed:

- Description:
+ [Impact]
+ Ice Lake (ICL) graphics needs to be enabled for OEM OSP1 image which is based 
on 18.04.3 graphics stack with linux-oem-osp1 kernel.
+ 
+ 
+ [Test case]
+ The usual desktop usage, graphics tests etc.
+ 
+ 
+ [Regression potential]
+ Linux-oem-osp1 kernel is a new kernel used only on new OEM enablements, and 
it can't regress any currently running system.
+ 
+ Mesa backports are limited to ICL, so they shouldn't regress earlier
+ generations either.
+ 
+ --
+ 
+ Original description:
  
  ICL graphics is not enabled in 19.04.
  if you want to use 19.04 on ICL platform, you need do like this
  
  Add kernel option
  i915.alpha_support=1
  
  Target Release:19.10
- Target Kernel: 5.1
+ Target Kernel: 5.2
+ Target Mesa: 19.1

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

Title:
  [graphics] Enable ICL

Status in intel:
  Fix Committed
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  Invalid
Status in linux-oem-osp1 source package in Bionic:
  New
Status in mesa source package in Bionic:
  New

Bug description:
  [Impact]
  Ice Lake (ICL) graphics needs to be enabled for OEM OSP1 image which is based 
on 18.04.3 graphics stack with linux-oem-osp1 kernel.

  
  [Test case]
  The usual desktop usage, graphics tests etc.

  
  [Regression potential]
  Linux-oem-osp1 kernel is a new kernel used only on new OEM enablements, and 
it can't regress any currently running system.

  Mesa backports are limited to ICL, so they shouldn't regress earlier
  generations either.

  --

  Original description:

  ICL graphics is not enabled in 19.04.
  if you want to use 19.04 on ICL platform, you need do like this

  Add kernel option
  i915.alpha_support=1

  Target Release:19.10
  Target Kernel: 5.2
  Target Mesa: 19.1

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

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


[Touch-packages] [Bug 1825940] Re: [graphics] Enable ICL

2019-05-28 Thread Timo Aaltonen
backported patches for mesa 19.0:

f8c3f408a6026f2 intel/genxml: Update MI_ATOMIC genxml definition.
11518384c465b9f i965: Re-enable fast color clears for GEN11.
9175c7058efb13d intel/blorp: Make blorp update the clear color in gen11.
232c0f64891e2f9 isl: Set ClearColorConversionEnable.
f2041d2a9266ec1 intel/isl: Resize clear color buffer to full cacheline
ff642fb0e6523db intel/compiler/fs/icl: Use dummy masked urb write for tess eval
ea42ba36b936e26 intel/compiler/icl: Use tcs barrier id bits 24:30 instead of 
24:27
2be60e0c73ed155 anv/icl: Add WA_2204188704 to disable pixel shader panic 
dispatch
85ecd14ef6a084f i965/icl: Add WA_2204188704 to disable pixel shader panic 
dispatch

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

Title:
  [graphics] Enable ICL

Status in intel:
  Fix Committed
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  Invalid
Status in linux-oem-osp1 source package in Bionic:
  New
Status in mesa source package in Bionic:
  New

Bug description:
  [Impact]
  Ice Lake (ICL) graphics needs to be enabled for OEM OSP1 image which is based 
on 18.04.3 graphics stack with linux-oem-osp1 kernel.

  
  [Test case]
  The usual desktop usage, graphics tests etc.

  
  [Regression potential]
  Linux-oem-osp1 kernel is a new kernel used only on new OEM enablements, and 
it can't regress any currently running system.

  Mesa backports are limited to ICL, so they shouldn't regress earlier
  generations either.

  --

  Original description:

  ICL graphics is not enabled in 19.04.
  if you want to use 19.04 on ICL platform, you need do like this

  Add kernel option
  i915.alpha_support=1

  Target Release:19.10
  Target Kernel: 5.2
  Target Mesa: 19.1

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

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


[Touch-packages] [Bug 1768166] Re: Random crashes

2019-05-28 Thread Gunnar Hjalmarsson
** Description changed:

  [Impact]
  
  ibus-libpinyin has proved to crash far too often. One or more files in
  ~/.cache/ibus/libpinyin get corrupted somehow, and emptying that
  directory allows the user to keep using ibus-libpinyin.
  
  In disco (and eoan) ibus-libpinyin 1.11.0 and libpinyin 2.2.2 are
  present, and the number of crashes has been reduced significantly:
  
  https://errors.ubuntu.com/?package=ibus-libpinyin=month
  
  Upstream ChangeLog ibus-libpinyin:
  --
  version 1.11.0
  * fixes keypad decimal
  * fixes emoji candidates
  * support configurable opencc config
  
  version 1.10.92
  * fixes Enter handling
  
  version 1.10.91
  * support ime.register_trigger in lua extension
  * support predicted candidates
  * support emoji input
  
  version 1.10.0
  * bug fixes
  
  version 1.9.91
  * migrate to use GSettings
  * fixes lyx short cut issue
  
  version 1.9.3
  * translate input method name in ibus menu
  
  Upstream ChangeLog libpinyin:
  -
  version 2.2.2
  * minor fixes
  
  version 2.2.1
  * fixes predicted candidates
  
  version 2.2.0
  * bug fixes
  
  The proposal is to backport the disco versions of those packages to
  bionic and cosmic in an attempt to prevent crashes. Proposed uploads are
  available in this PPA:
  
  https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus-libpinyin
  
  [Test Case]
  
  * Install from {bionic,cosmic}-proposed:
-   - libpinyin13
-   - libpinyin-data
-   - ibus-libpinyin
+   - libpinyin13
+   - libpinyin-data
+   - ibus-libpinyin
  
  * Use "Intelligent Pinyin" for typing and confirm that no new issues
-   show up when doing so.
+   show up when doing so.
  
  (This is apparently not a confirmation that the upload really fixes the
- bug. Time will tell.)
+ bug. To compensate for that, we will await testing of the -proposed
+ packages by a few Chinese users before considering the uploads
+ verified.)
+ 
+ Reverse dependencies
+ 
+ Besides ibus-libpinyin, also fcitx-libpinyin and ibus-zhuyin depend on 
packages belonging to the libpinyin source package. So additional test measures 
are:
+ 
+ * Install fcitx-libpinyin and ibus-zhuyin.
+ 
+ * Use both those tools for typing Chinese, and confirm that you don't
+   observe any adverse effects of the libpinyin upgrade.
  
  [Regression Potential]
  
  The changes are mostly bug fixes, so the regression risk should be
  limited. Also consider that the starting point is a rather unstable
  functionality.
  
  [Original description]
  
  I have experienced random ibus-libpinyin crashes in bionic.  I cannot
  reproduce it, but it occurred at least a few times, even after the
  official bionic release.  Same crashes were also reported in the Ubuntu
  Chinese forum.
  
  Currently, the workaround is to delete the ~/.cache/ibus/libpinyin
  folder.
  
  I talked to Peng Wu, ibus-libpinyin's creator and main maintainer, he
  suggested that we update the version of ibus-libpinyin to 1.10.
  
  Can we give this update a trial?

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

Title:
  Random crashes

Status in ibus-libpinyin package in Ubuntu:
  Fix Released
Status in libpinyin package in Ubuntu:
  Fix Released
Status in ibus-libpinyin source package in Bionic:
  In Progress
Status in libpinyin source package in Bionic:
  In Progress
Status in ibus-libpinyin source package in Cosmic:
  In Progress
Status in libpinyin source package in Cosmic:
  In Progress

Bug description:
  [Impact]

  ibus-libpinyin has proved to crash far too often. One or more files in
  ~/.cache/ibus/libpinyin get corrupted somehow, and emptying that
  directory allows the user to keep using ibus-libpinyin.

  In disco (and eoan) ibus-libpinyin 1.11.0 and libpinyin 2.2.2 are
  present, and the number of crashes has been reduced significantly:

  https://errors.ubuntu.com/?package=ibus-libpinyin=month

  Upstream ChangeLog ibus-libpinyin:
  --
  version 1.11.0
  * fixes keypad decimal
  * fixes emoji candidates
  * support configurable opencc config

  version 1.10.92
  * fixes Enter handling

  version 1.10.91
  * support ime.register_trigger in lua extension
  * support predicted candidates
  * support emoji input

  version 1.10.0
  * bug fixes

  version 1.9.91
  * migrate to use GSettings
  * fixes lyx short cut issue

  version 1.9.3
  * translate input method name in ibus menu

  Upstream ChangeLog libpinyin:
  -
  version 2.2.2
  * minor fixes

  version 2.2.1
  * fixes predicted candidates

  version 2.2.0
  * bug fixes

  The proposal is to backport the disco versions of those packages to
  bionic and cosmic in an attempt to prevent crashes. Proposed uploads
  are available in this PPA:

  https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus-libpinyin

  

[Touch-packages] [Bug 1821269] Re: [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch (4-pole combo jack mic doesn't detect)

2019-05-28 Thread Hui Wang
It is fixed from kernel driver, So all linux distros have this issue. We
plan to send the patch to upstream kernel and cc stable-kernel, after
this patch is merged to stable-kernel, I guess all linux distros will
have this fix automatically.

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

Title:
  [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch (4-pole
  combo jack mic doesn't detect)

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  I use realtek alc255 analog audio jack. External jack is 4 pole combo(apple 
type. not europe type.).
  When I plug 4 pole mic into jack, It doesn't detect.
  So I can't my voice through external mic.

  My laptop has internal mic. It belongs to Intel sound(HDA Intel PCH. Audio 
device: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx 
Series High Definition Audio Controller (rev 21)).
  Internal mic works well.

  Please check 4pole external mic detection.

  Thank you.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
  Uname: Linux 4.15.0-46-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0c:   jimnong1441 F...m pulseaudio
   /dev/snd/pcmC0D0p:   jimnong1441 F...m pulseaudio
   /dev/snd/controlC0:  jimnong1441 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 22 11:30:39 2019
  InstallationDate: Installed on 2017-07-27 (603 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: 내장 오디오 - HDA Intel PCH
  Symptom_Jack: Mic, Internal
  Symptom_Type: No auto-switch between inputs
  Title: [Aspire ES1-131, Realtek ALC255, Mic, Internal] No autoswitch
  UpgradeStatus: Upgraded to bionic on 2018-09-23 (179 days ago)
  dmi.bios.date: 09/06/2016
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: V1.24
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: Garp_BA
  dmi.board.vendor: Acer
  dmi.board.version: V1.24
  dmi.chassis.type: 10
  dmi.chassis.vendor: Chassis Manufacturer
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.24:bd09/06/2016:svnAcer:pnAspireES1-131:pvrV1.24:rvnAcer:rnGarp_BA:rvrV1.24:cvnChassisManufacturer:ct10:cvrChassisVersion:
  dmi.product.family: BSW
  dmi.product.name: Aspire ES1-131
  dmi.product.version: V1.24
  dmi.sys.vendor: Acer

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

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


[Touch-packages] [Bug 1830635] Re: Regression: xenial: Uses apt_pkg.Error, which is only available in later versions

2019-05-28 Thread Julian Andres Klode
Verified 1.1.0~beta1ubuntu0.16.04.5 by running the attached script. It
does properly throw LockFailedException now. It does give you the cause
of the LockFailedException, which we might want to change eventually,
but um, that's just cosmetics, and might even be useful.

# python3 -c "import apt; apt.Cache().update()" 
  
Traceback (most recent call last):  
   
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 63, in __enter__ 
   
return self._lock.__enter__()   
   
SystemError: E:Could not get lock /var/lib/apt/lists/lock - open (11: Resource 
temporarily unavailable)

   
During handling of the above exception, another exception occurred: 
   

   
Traceback (most recent call last):  
   
  File "", line 1, in   
   
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 481, in update   
   
with _WrappedLock(apt_pkg.config.find_dir("Dir::State::Lists")):
   
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 66, in __enter__ 
   
(self._path, e))
   
apt.cache.LockFailedException: Failed to lock directory /var/lib/apt/lists/: 
E:Could not get lock /var/lib/apt/lists
/lock - open (11: Resource temporarily unavailable)  


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

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

Title:
  Regression: xenial: Uses apt_pkg.Error, which is only available in
  later versions

Status in python-apt package in Ubuntu:
  Invalid
Status in python-apt source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  The last SRU introduced a regression in error handling, where apt_pkg.Error 
is being caught - but that class is not available in xenial - it still uses 
SystemError

  [Test case]

  Run python3 -c "import apt; apt.Cache().update()" while running apt
  update.

  You should see:

  # 
  Traceback (most recent call last):
    File "", line 1, in 
    File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 468, in update
  raise LockFailedException("Failed to lock %s" % lockfile)
  apt.cache.LockFailedException: Failed to lock /var/lib/apt/lists/lock

  Currently you see:
  # 
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/apt/cache.py", line 63, in __enter__
  return self._lock.__enter__()
  SystemError: E:Could not get lock /var/lib/apt/lists/lock - open (11: 
Resource temporarily unavailable)

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
    File "", line 1, in 
    File "/usr/lib/python3/dist-packages/apt/cache.py", line 481, in update
  with _WrappedLock(apt_pkg.config.find_dir("Dir::State::Lists")):
    File "/usr/lib/python3/dist-packages/apt/cache.py", line 64, in __enter__
  except apt_pkg.Error as e:
  AttributeError: module 'apt_pkg' has no attribute 'Error'

  [Regression potential]
  It really can't get worse than this. But FWIW: This only affects code paths 
where we could not lock the lists/ or archives/ directory - they currently 
throw the AttributeError, and will then throw LockFailedException again - as 
they did before the SRU.

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

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


[Touch-packages] [Bug 1772844] Re: snapd didn't initialize all the seeded snaps

2019-05-28 Thread Bin Li
@Peter,

 Yes, we met the same issue.

 https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1828604

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

Title:
  snapd didn't initialize all the seeded snaps

Status in OEM Priority Project:
  Fix Released
Status in snapd:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Won't Fix
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Fix Released
Status in ubuntu-meta source package in Bionic:
  Fix Released

Bug description:
  snapd didn't initialize all the seeded snaps

  bionic-desktop-amd64.iso (20180522)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: snapd 2.32.9+18.04
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue May 22 22:59:18 2018
  InstallationDate: Installed on 2018-05-23 (0 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180522)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: snapd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1772844/+subscriptions

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


[Touch-packages] [Bug 1825940] Re: [graphics] Enable ICL

2019-05-28 Thread Timo Aaltonen
** Also affects: mesa (Ubuntu)
   Importance: Undecided
   Status: New

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

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

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

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

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

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

Title:
  [graphics] Enable ICL

Status in intel:
  Fix Committed
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  Invalid
Status in linux-oem-osp1 source package in Bionic:
  New
Status in mesa source package in Bionic:
  New

Bug description:
  Description:

  ICL graphics is not enabled in 19.04.
  if you want to use 19.04 on ICL platform, you need do like this

  Add kernel option
  i915.alpha_support=1

  Target Release:19.10
  Target Kernel: 5.1

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

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


[Touch-packages] [Bug 1824111] Re: Backport packages for 18.04.3 HWE stack

2019-05-28 Thread Timo Aaltonen
we'll get the last update of 19.0.x series eventually

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

Title:
  Backport packages for 18.04.3 HWE stack

Status in libclc package in Ubuntu:
  Invalid
Status in libdrm package in Ubuntu:
  Invalid
Status in llvm-toolchain-8 package in Ubuntu:
  Invalid
Status in mesa package in Ubuntu:
  Invalid
Status in xorg-server-hwe-18.04 package in Ubuntu:
  Invalid
Status in xserver-xorg-video-amdgpu-hwe-18.04 package in Ubuntu:
  Invalid
Status in xserver-xorg-video-ati-hwe-18.04 package in Ubuntu:
  Invalid
Status in libclc source package in Bionic:
  Fix Committed
Status in libdrm source package in Bionic:
  Fix Committed
Status in llvm-toolchain-8 source package in Bionic:
  Fix Committed
Status in mesa source package in Bionic:
  Fix Committed
Status in xorg-server-hwe-18.04 source package in Bionic:
  New
Status in xserver-xorg-video-amdgpu-hwe-18.04 source package in Bionic:
  New
Status in xserver-xorg-video-ati-hwe-18.04 source package in Bionic:
  New

Bug description:
  [Impact]

  These are needed for 18.04.3 images.

  [Test case]

  Boot a daily image, see that it still has the necessary stack
  installed and working.

  Check upgrade from stock bionic.

  [Regression potential]

  libdrm: very minimal chance for regressions

  llvm-8: a new package, no regression potential on it's own

  libclc: more or less just adds support for new llvm

  mesa: a new major release, but we'll pull the final stable release of
  19.0.x series, so there shouldn't be any regressions left at that
  point

  xserver: a new minor release

  xorg drivers: modest updates, mainly just new ati/amdgpu

  [Other info]

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

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


[Touch-packages] [Bug 1824111] Re: Backport packages for 18.04.3 HWE stack

2019-05-28 Thread Boaz Dodin
I would suggest to ship at least Mesa 19.0.4, because of the bug
https://bugs.freedesktop.org/show_bug.cgi?id=110355 in some popular
programs.

** Bug watch added: freedesktop.org Bugzilla #110355
   https://bugs.freedesktop.org/show_bug.cgi?id=110355

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

Title:
  Backport packages for 18.04.3 HWE stack

Status in libclc package in Ubuntu:
  Invalid
Status in libdrm package in Ubuntu:
  Invalid
Status in llvm-toolchain-8 package in Ubuntu:
  Invalid
Status in mesa package in Ubuntu:
  Invalid
Status in xorg-server-hwe-18.04 package in Ubuntu:
  Invalid
Status in xserver-xorg-video-amdgpu-hwe-18.04 package in Ubuntu:
  Invalid
Status in xserver-xorg-video-ati-hwe-18.04 package in Ubuntu:
  Invalid
Status in libclc source package in Bionic:
  Fix Committed
Status in libdrm source package in Bionic:
  Fix Committed
Status in llvm-toolchain-8 source package in Bionic:
  Fix Committed
Status in mesa source package in Bionic:
  Fix Committed
Status in xorg-server-hwe-18.04 source package in Bionic:
  New
Status in xserver-xorg-video-amdgpu-hwe-18.04 source package in Bionic:
  New
Status in xserver-xorg-video-ati-hwe-18.04 source package in Bionic:
  New

Bug description:
  [Impact]

  These are needed for 18.04.3 images.

  [Test case]

  Boot a daily image, see that it still has the necessary stack
  installed and working.

  Check upgrade from stock bionic.

  [Regression potential]

  libdrm: very minimal chance for regressions

  llvm-8: a new package, no regression potential on it's own

  libclc: more or less just adds support for new llvm

  mesa: a new major release, but we'll pull the final stable release of
  19.0.x series, so there shouldn't be any regressions left at that
  point

  xserver: a new minor release

  xorg drivers: modest updates, mainly just new ati/amdgpu

  [Other info]

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

-- 
Mailing list: https://launchpad.net/~touch-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-28 Thread Steve Langasek
> LVM module is supposed to create PVs from devices using the links in 
> /dev/disk/by-dname/
> folder that are created by udev.

Created by udev how?  disk/by-dname is not part of the hierarchy that is
populated by the standard udev rules, nor is this created by lvm2.  Is
there something in the ceph-osd packaging specifically which generates
these links - and, in turn, depends on them for assembling LVs?

Can you provide udev logs (journalctl --no-pager -lu systemd-
udevd.service; udevadm info -e) from the system following a boot when
this race is hit?

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

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

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

Status in systemd package in Ubuntu:
  Incomplete

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