[Touch-packages] [Bug 1807709] Re: dbus always crashes at session start (on wayland)

2019-03-11 Thread Launchpad Bug Tracker
[Expired for dbus (Ubuntu) because there has been no activity for 60
days.]

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

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

Title:
  dbus always crashes at session start (on wayland)

Status in dbus package in Ubuntu:
  Expired

Bug description:
  When you login in ubuntu 18.10 using gnome shell and wayland, dbus
  always crashes and you are welcomed with a dialog to report the crash.

  Looking into the file `/var/crash/_usr_bin_dbus-daemon.1000.crash` one
  can see that there is antoher bug, previoulsy reported as #1591548
  (https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1591548)

  So may be the bug report is never sent, either ?

  /var/crash/_usr_bin_dbus-daemon.1000.crash content is:

  ProblemType: Crash
  Architecture: amd64
  Date: Sun Dec  9 11:16:22 2018
  DistroRelease: Ubuntu 18.10
  ExecutablePath: /usr/bin/dbus-daemon
  ExecutableTimestamp: 1536206167
  ProcCmdline: /usr/bin/dbus-daemon --session --address=systemd: --nofork 
--nopidfile --systemd-activation --syslog-only
  ProcCwd: /home/solstice
  ProcEnviron:
   LANG=fr_FR.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  ProcMaps:
   55c9bfc7a000-55c9bfc83000 r--p  08:07 787824 
/usr/bin/dbus-daemon
   55c9bfc83000-55c9bfca5000 r-xp 9000 08:07 787824 
/usr/bin/dbus-daemon
   55c9bfca5000-55c9bfcb3000 r--p 0002b000 08:07 787824 
/usr/bin/dbus-daemon
   55c9bfcb3000-55c9bfcb5000 r--p 00038000 08:07 787824 
/usr/bin/dbus-daemon
   55c9bfcb5000-55c9bfcb6000 rw-p 0003a000 08:07 787824 
/usr/bin/dbus-daemon
   55c9c1bd8000-55c9c1f1e000 rw-p  00:00 0  
[heap]
   7eff0278c000-7eff02792000 r--p  08:07 650406 
/lib/x86_64-linux-gnu/libnss_systemd.so.2
   7eff02792000-7eff027bd000 r-xp 6000 08:07 650406 
/lib/x86_64-linux-gnu/libnss_systemd.so.2
   7eff027bd000-7eff027cc000 r--p 00031000 08:07 650406 
/lib/x86_64-linux-gnu/libnss_systemd.so.2
   7eff027cc000-7eff027cf000 r--p 0003f000 08:07 650406 
/lib/x86_64-linux-gnu/libnss_systemd.so.2
   7eff027cf000-7eff027d rw-p 00042000 08:07 650406 
/lib/x86_64-linux-gnu/libnss_systemd.so.2
   7eff027d-7eff027d1000 rw-p  00:00 0 
   7eff027d1000-7eff027d4000 r--p  08:07 654769 
/lib/x86_64-linux-gnu/libnss_files-2.28.so
   7eff027d4000-7eff027db000 r-xp 3000 08:07 654769 
/lib/x86_64-linux-gnu/libnss_files-2.28.so
   7eff027db000-7eff027de000 r--p a000 08:07 654769 
/lib/x86_64-linux-gnu/libnss_files-2.28.so
   7eff027de000-7eff027df000 r--p c000 08:07 654769 
/lib/x86_64-linux-gnu/libnss_files-2.28.so
   7eff027df000-7eff027e rw-p d000 08:07 654769 
/lib/x86_64-linux-gnu/libnss_files-2.28.so
   7eff027e-7eff027e6000 rw-p  00:00 0 
   7eff027e6000-7eff027ea000 r--p  08:07 654766 
/lib/x86_64-linux-gnu/libnsl-2.28.so
   7eff027ea000-7eff027f8000 r-xp 4000 08:07 654766 
/lib/x86_64-linux-gnu/libnsl-2.28.so
   7eff027f8000-7eff027fd000 r--p 00012000 08:07 654766 
/lib/x86_64-linux-gnu/libnsl-2.28.so
   7eff027fd000-7eff027fe000 r--p 00016000 08:07 654766 
/lib/x86_64-linux-gnu/libnsl-2.28.so
   7eff027fe000-7eff027ff000 rw-p 00017000 08:07 654766 
/lib/x86_64-linux-gnu/libnsl-2.28.so
   7eff027ff000-7eff02801000 rw-p  00:00 0 
   7eff02801000-7eff02803000 r--p  08:07 654771 
/lib/x86_64-linux-gnu/libnss_nis-2.28.so
   7eff02803000-7eff0280b000 r-xp 2000 08:07 654771 
/lib/x86_64-linux-gnu/libnss_nis-2.28.so
   7eff0280b000-7eff0280d000 r--p a000 08:07 654771 
/lib/x86_64-linux-gnu/libnss_nis-2.28.so
   7eff0280d000-7eff0280e000 r--p b000 08:07 654771 
/lib/x86_64-linux-gnu/libnss_nis-2.28.so
   7eff0280e000-7eff0280f000 rw-p c000 08:07 654771 
/lib/x86_64-linux-gnu/libnss_nis-2.28.so
   7eff0280f000-7eff02811000 r--p  08:07 654767 
/lib/x86_64-linux-gnu/libnss_compat-2.28.so
   7eff02811000-7eff02817000 r-xp 2000 08:07 654767 
/lib/x86_64-linux-gnu/libnss_compat-2.28.so
   7eff02817000-7eff02818000 r--p 8000 08:07 654767 
/lib/x86_64-linux-gnu/libnss_compat-2.28.so
   7eff02818000-7eff02819000 r--p 8000 08:07 654767 
/lib/x86_64-linux-gnu/libnss_compat-2.28.so
   7eff02819000-7eff0281a000 rw-p 9000 08:07 654767 

[Touch-packages] [Bug 1819572] Re: do-release-upgrade from cosmic to disco make the network of this specific machine malfunction

2019-03-11 Thread Taihsiang Ho
** Attachment added: 
"201606-22344-network-manager-nplusone-190312.var-log.tar.gz"
   
https://bugs.launchpad.net/ubuntu/+bug/1819572/+attachment/5245585/+files/201606-22344-network-manager-nplusone-190312.var-log.tar.gz

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

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

** Also affects: Ubuntu Cosmic
   Importance: Undecided
   Status: New

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

** Also affects: Ubuntu Disco
   Importance: Undecided
   Status: New

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

Title:
  do-release-upgrade from cosmic to disco make the network of this
  specific machine malfunction

Status in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New
Status in The Cosmic Cuttlefish:
  New
Status in network-manager source package in Cosmic:
  New
Status in The Disco Dingo:
  New
Status in network-manager source package in Disco:
  New

Bug description:
  Hardware: Dell Vostro 5568 (CID 201606-22344)

  [Steps To Reproduce]
  1. Install cosmic on this machine
  2. Connect to the internet with ethernet
  3. do-release-upgrade

  [Expected Result]
  Upgrade completes. The wired connection is ready to access the internet.

  [Actual Result]
  - The ethernet interface has an IP address assigned by the associated DHCP 
(checked by "ip -a")
  - "ping 8.8.8.8" will get "Destination Host Unreachable"

  [More Information]
  I tried the same steps on different machine-distro matrix[1]  and could only 
reproduce the issue on this machine.

  [1] distro are: xenial-to-bionic, bionic-to-cosmic, cosmic-to-disco

  
  ---

  [Logs]

  - /var/log tarball of the system: the attachment 201606-22344-network-
  manager-nplusone-190312.var-log.tar.gz

  - Collected by "ubuntu-bug network-manager":
  /media/tai271828/certsd/201606-22344-network-manager-
  nplusone-190312.ubuntu.bug

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

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


[Touch-packages] [Bug 1819567] [NEW] [HD-Audio Generic - HD-Audio Generic, playback] Bad quality 2.1 surround sound

2019-03-11 Thread Antonio
Public bug reported:

using a (2010?) 2.1 surround Creative speaker but the sound seems to
fall back to a generic stereo output with only left and right channels
(using the green plug).

The subwoofer receives little sound and the left and right speakers
receive the bulk of the sound. If I increase the sound level the bass
gets almost muted. The Pulse Audio manager doesn't show also any 3rd
channel (don't know if it was supposed to), only Left and Right.

It seems a problem with mixing, since the sound goes with the same level
to the front left and right speakers and the subwoofer only gets a small
part of it, and it gets worst as the sound level is increased on the
hardware volume control since the speakers handle almost all sound
ranges.

Tried to create Profiles and Mappings for an "analog-surround-21" and
changed the LFE information on the usual config files, but nothing seems
to work and I lack more deeply knowledge of how ALSA and Pulse Audio
work to figure out how to implement a (up)mixing.

I Win7 the speakers worked great, but in the new MoBo and Ryzen CPU Win7
is no longer supported and I want to finally use Linux (X)Ubuntu.

This issue seems to have been tackled with previously here:
https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/1286021

-

lsb_release -rd
Description:Ubuntu 18.04.2 LTS
Release:18.04

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.5
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC1:  antonio   13557 F pulseaudio
 /dev/snd/controlC0:  antonio   13557 F pulseaudio
CurrentDesktop: XFCE
Date: Tue Mar 12 02:06:24 2019
InstallationDate: Installed on 2019-01-10 (61 days ago)
InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_Card: HD-Audio Generic - HD-Audio Generic
Symptom_Type: Volume slider, or mixer problems
Title: [HD-Audio Generic - HD-Audio Generic, playback] volume slider problem
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/19/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.10
dmi.board.name: B450M Pro4
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrP1.10:bd06/19/2018:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnB450MPro4:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

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


** Tags: amd64 apport-bug bionic

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

Title:
  [HD-Audio Generic - HD-Audio Generic, playback] Bad quality 2.1
  surround sound

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  using a (2010?) 2.1 surround Creative speaker but the sound seems to
  fall back to a generic stereo output with only left and right channels
  (using the green plug).

  The subwoofer receives little sound and the left and right speakers
  receive the bulk of the sound. If I increase the sound level the bass
  gets almost muted. The Pulse Audio manager doesn't show also any 3rd
  channel (don't know if it was supposed to), only Left and Right.

  It seems a problem with mixing, since the sound goes with the same
  level to the front left and right speakers and the subwoofer only gets
  a small part of it, and it gets worst as the sound level is increased
  on the hardware volume control since the speakers handle almost all
  sound ranges.

  Tried to create Profiles and Mappings for an "analog-surround-21" and
  changed the LFE information on the usual config files, but nothing
  seems to work and I lack more deeply knowledge of how ALSA and Pulse
  Audio work to figure out how to implement a (up)mixing.

  I Win7 the speakers worked great, but in the new MoBo and Ryzen CPU
  Win7 is no longer supported and I want to finally use Linux (X)Ubuntu.

  This issue seems to have been tackled with previously here:
  https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/1286021

  -

  lsb_release -rd
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04

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

[Touch-packages] [Bug 1818802] Re: [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails after a while

2019-03-11 Thread Daniel van Vugt
Also, does this bug apply to the laptop's internal speakers? Or are you
using headphones?

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

Title:
  [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails
  after a while

Status in linux package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  Audio dies after few seconds, returns after few minutes and dies again

  filip@ux433:~$ lsb_release -rd
  Description:  Ubuntu 18.10
  Release:  18.10

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  Uname: Linux 4.20.14-042014-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  filip  8566 F pulseaudio
   /dev/snd/pcmC0D0p:   filip  8566 F...m pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar  6 10:11:01 2019
  InstallationDate: Installed on 2019-01-05 (59 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Speaker, Internal
  Symptom_PulseAudioLog: mar 06 10:04:08 ux433 dbus-daemon[3008]: [system] 
Activating via systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.37' (uid=121 pid=6142 
comm="/usr/bin/pulseaudio --daemonize=no ")
  Symptom_Type: Sound works for a while, then breaks
  Title: [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails 
after a while
  UpgradeStatus: Upgraded to cosmic on 2019-01-28 (36 days ago)
  dmi.bios.date: 11/21/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX433FN.301
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX433FN
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX433FN.301:bd11/21/2018:svnASUSTeKCOMPUTERINC.:pnZenBookUX433FN_UX433FN:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX433FN:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: ZenBook
  dmi.product.name: ZenBook UX433FN_UX433FN
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

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

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


[Touch-packages] [Bug 1818802] Re: [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails after a while

2019-03-11 Thread Daniel van Vugt
Next, please wait until the audio has stopped working AND has later come
back, then run:

  dmesg > dmesgafter.txt
  journalctl -b0 > journalafter.txt

and send us the files 'dmesgafter.txt' and 'journalafter.txt'.

** Summary changed:

- [ZenBook UX433FN_UX433FN] Audio only works when the laptop is plugged in or 
the battery % is above 20 - 40%
+ [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails after a 
while

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

Title:
  [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails
  after a while

Status in linux package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  Audio dies after few seconds, returns after few minutes and dies again

  filip@ux433:~$ lsb_release -rd
  Description:  Ubuntu 18.10
  Release:  18.10

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  Uname: Linux 4.20.14-042014-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  filip  8566 F pulseaudio
   /dev/snd/pcmC0D0p:   filip  8566 F...m pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar  6 10:11:01 2019
  InstallationDate: Installed on 2019-01-05 (59 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Speaker, Internal
  Symptom_PulseAudioLog: mar 06 10:04:08 ux433 dbus-daemon[3008]: [system] 
Activating via systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.37' (uid=121 pid=6142 
comm="/usr/bin/pulseaudio --daemonize=no ")
  Symptom_Type: Sound works for a while, then breaks
  Title: [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails 
after a while
  UpgradeStatus: Upgraded to cosmic on 2019-01-28 (36 days ago)
  dmi.bios.date: 11/21/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX433FN.301
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX433FN
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX433FN.301:bd11/21/2018:svnASUSTeKCOMPUTERINC.:pnZenBookUX433FN_UX433FN:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX433FN:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: ZenBook
  dmi.product.name: ZenBook UX433FN_UX433FN
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

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

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


[Touch-packages] [Bug 1815889]

2019-03-11 Thread Baker-dylan-c
I'm removing this from the 19.0 blocking tracker. Generally we don't add
bugs to block a release if they were present in the previous release,
additionally there doesn't seem to be any consensus on a solution, at
this moment. If there is a fix implemented I'd be happy to pull that
into a later 19.0 release.

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

Title:
  qemu-system-x86_64 crashed with signal 31 in
  __pthread_setaffinity_new()

Status in Mesa:
  Confirmed
Status in QEMU:
  New
Status in mesa package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Triaged
Status in mesa source package in Disco:
  Triaged

Bug description:
  Unable to launch Default Fedora 29 images in gnome-boxes

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
  Uname: Linux 4.19.0-12-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  Date: Thu Feb 14 11:00:45 2019
  ExecutablePath: /usr/bin/qemu-system-x86_64
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: Dell Inc. Precision T3610
  ProcEnviron: PATH=(custom, user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic 
root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1
  Signal: 31
  SourcePackage: qemu
  StacktraceTop:
   __pthread_setaffinity_new (th=, cpusetsize=128, 
cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   start_thread (arg=) at pthread_create.c:486
   clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  Title: qemu-system-x86_64 crashed with signal 31 in 
__pthread_setaffinity_new()
  UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video
  dmi.bios.date: 11/14/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A18
  dmi.board.name: 09M8Y8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr:
  dmi.product.name: Precision T3610
  dmi.product.sku: 05D2
  dmi.product.version: 00
  dmi.sys.vendor: Dell Inc.

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

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


[Touch-packages] [Bug 1819240] Re: Many sites will not connect. Very slow. Some siezing.

2019-03-11 Thread Alex Murray
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  Many sites will not connect. Very slow. Some siezing.

Status in xorg package in Ubuntu:
  New

Bug description:
  N/A

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3.1
  ProcVersionSignature: Ubuntu 4.4.0-142.168-generic 4.4.167
  Uname: Linux 4.4.0-142-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  Date: Fri Mar  8 19:20:55 2019
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] [1002:9710] 
(prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company RS880 [Radeon HD 4200] [103c:2ab1]
  InstallationDate: Installed on 2016-09-11 (908 days ago)
  InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  MachineType: Hewlett-Packard p6710f
  ProcEnviron:
   LANGUAGE=en_US
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-142-generic 
root=UUID=03dbc475-0f36-4145-a3a0-9293828af31a ro quiet splash
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/04/2011
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 6.07
  dmi.board.name: 2AB1
  dmi.board.vendor: FOXCONN
  dmi.board.version: 1.00
  dmi.chassis.asset.tag: 4CE0480TV4
  dmi.chassis.type: 3
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr6.07:bd05/04/2011:svnHewlett-Packard:pnp6710f:pvr:rvnFOXCONN:rn2AB1:rvr1.00:cvnHewlett-Packard:ct3:cvr:
  dmi.product.name: p6710f
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz 1:0.9.12.3+16.04.20180221-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.91-2~16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~16.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.8
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2
  xserver.bootTime: Fri Mar  8 18:28:14 2019
  xserver.configfile: default
  xserver.devices:
   inputPower Button KEYBOARD, id 6
   inputPower Button KEYBOARD, id 7
   inputCHICONY HP USB Multimedia Keyboard KEYBOARD, id 8
   inputCHICONY HP USB Multimedia Keyboard KEYBOARD, id 9
   inputLogitech USB Optical Mouse MOUSE, id 10
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.18.4-0ubuntu0.8
  xserver.video_driver: radeon

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

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


[Touch-packages] [Bug 1819183] Re: FFe: Update pygobject to 3.32

2019-03-11 Thread Jeremy Bicha
This bug was fixed in the package pygobject - 3.32.0-1

---
pygobject (3.32.0-1) experimental; urgency=medium

  * New upstream release

 -- Jeremy Bicha   Sun, 10 Mar 2019 12:59:34 -0400

pygobject (3.31.4-1) experimental; urgency=medium

  * New upstream release
  * Bump minimum glib to 2.48.0

 -- Jeremy Bicha   Fri, 08 Mar 2019 09:45:40 -0500

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

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

Title:
  FFe: Update pygobject to 3.32

Status in pygobject package in Ubuntu:
  Fix Released

Bug description:
  Feature Freeze exception request
  
  Since we're updating the rest of GNOME to 3.32 (including glib and 
gobject-introspection), it seems like it would be a good idea to update 
pygobject also.

  3.32.0-1 is in Debian experimental ready to be synced over once this
  FFe is approved.

  https://gitlab.gnome.org/GNOME/pygobject/blob/master/NEWS
  https://gitlab.gnome.org/GNOME/pygobject/compare/3.30.4...3.32.0 (includes 
several commits that were already included in the current 3.30.4 version)

  Justification for lateness
  --
  Sorry, we've been a bit busy and this wasn't a high priority.

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

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


[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures

2019-03-11 Thread Steve Langasek
Dimitri didn't post results from a power8 system, but here's what I see
in a Power8 VM, with up-to-date 19.04:

$ lscpu
Architecture:ppc64le
Byte Order:  Little Endian
CPU(s):  1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   1
NUMA node(s):1
Model:   2.1 (pvr 004b 0201)
Model name:  POWER8E (raw), altivec supported
Hypervisor vendor:   KVM
Virtualization type: para
L1d cache:   64K
L1i cache:   32K
NUMA node0 CPU(s):   0
$ ./test.pl 
Calling mblen with str=data
mblen returned with len=-2
$

Same behavior with any of C, C.UTF-8, en_US.UTF-8 as the configured
locale.

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

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Confirmed
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

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


[Touch-packages] [Bug 1819549] Re: Cannot Update Ubuntu MATE 16.04.2 RP1

2019-03-11 Thread Sebastien Bacher
** Package changed: network-manager (Ubuntu) => ubuntu

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

Title:
  Cannot Update Ubuntu MATE 16.04.2 RP1

Status in Ubuntu:
  New

Bug description:
  When attempting to use the Update utility on Ubuntu MATE 16.04.2 on
  Raspberry Pi 3 for the latest security updates the user is informed
  that approximately 50MB of space is required and there is not enough
  space on /boot.

  The user is advised to use "sudo apt-get clean" to free up the
  necessary 4000KB of space required, however, this will not free enough
  space on /boot.  The user is unable to download security updates.

  When looking into this issue it was noted that in the latest version of 
Ubuntu MATE the following change was made:
  Re-size file system
  Since Ubuntu MATE 16.04.2 the root parition is automatically resized, to 
fully utilise the all available space on the microSD card, on first boot.
  Source: https://ubuntu-mate.org/raspberry-pi/

  This represents a significant impediment to installing security
  updates AND future use cases where more space is required on the
  primary partition.

  My suggestion would be removing the automatic file system re-size and
  allow the user to use parted or gparted to set partition sizes.

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

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


[Touch-packages] [Bug 1110147] Re: Error in manual

2019-03-11 Thread Christian Kastner
This was fixed in -121.

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

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

Title:
  Error in manual

Status in cron package in Ubuntu:
  Fix Released

Bug description:
  The manual for crontab(5) shows various examples of using the date command as 
such:
  $(date +%u)

  This contradicts the note specifying that any % sign needs to be
  escaped

  Entering something like that as a command for execution fails to
  interpret anything past the % sign.

  so, for example:
  * * * * * echo $(date +%Y)
  fails with
  /bin/sh: 1: Syntax error: end of file unexpected (expecting ")")

  The syslog shows this
   CRON[10104]: (root) CMD (echo $(date +)

  Simply escaping the % resolves it, so in this example, the manual
  should be updated so that each 'date' example looks as

  $(date +\%u) - or whatever the format character example is.
  My example cron from above executes as expected as
  * * * * * echo $(date +\%Y)

  which send me an email simply with "2013"

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

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


[Touch-packages] [Bug 1819549] [NEW] Cannot Update Ubuntu MATE 16.04.2 RP1

2019-03-11 Thread Saint Leibowitz
Public bug reported:

When attempting to use the Update utility on Ubuntu MATE 16.04.2 on
Raspberry Pi 3 for the latest security updates the user is informed that
approximately 50MB of space is required and there is not enough space on
/boot.

The user is advised to use "sudo apt-get clean" to free up the necessary
4000KB of space required, however, this will not free enough space on
/boot.  The user is unable to download security updates.

When looking into this issue it was noted that in the latest version of Ubuntu 
MATE the following change was made:
Re-size file system
Since Ubuntu MATE 16.04.2 the root parition is automatically resized, to fully 
utilise the all available space on the microSD card, on first boot.
Source: https://ubuntu-mate.org/raspberry-pi/

This represents a significant impediment to installing security updates
AND future use cases where more space is required on the primary
partition.

My suggestion would be removing the automatic file system re-size and
allow the user to use parted or gparted to set partition sizes.

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  When attempting to use the Update utility on Ubuntu MATE 16.04.2 on
  Raspberry Pi 3 for the latest security updates the user is informed that
  approximately 50MB of space is required and there is not enough space on
  /boot.
  
  The user is advised to use "sudo apt-get clean" to free up the necessary
  4000KB of space required, however, this will not free enough space on
  /boot.  The user is unable to download security updates.
  
  When looking into this issue it was noted that in the latest version of 
Ubuntu MATE the following change was made:
  Re-size file system
  Since Ubuntu MATE 16.04.2 the root parition is automatically resized, to 
fully utilise the all available space on the microSD card, on first boot.
  Source: https://ubuntu-mate.org/raspberry-pi/
  
  This represents a significant impediment to installing security updates
  AND future use cases where more space is required on the primary
  partition.
  
  My suggestion would be removing the automatic file system re-size and
- allow the user to use parted or gparted set partition sizes.
+ allow the user to use parted or gparted to set partition sizes.

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

Title:
  Cannot Update Ubuntu MATE 16.04.2 RP1

Status in network-manager package in Ubuntu:
  New

Bug description:
  When attempting to use the Update utility on Ubuntu MATE 16.04.2 on
  Raspberry Pi 3 for the latest security updates the user is informed
  that approximately 50MB of space is required and there is not enough
  space on /boot.

  The user is advised to use "sudo apt-get clean" to free up the
  necessary 4000KB of space required, however, this will not free enough
  space on /boot.  The user is unable to download security updates.

  When looking into this issue it was noted that in the latest version of 
Ubuntu MATE the following change was made:
  Re-size file system
  Since Ubuntu MATE 16.04.2 the root parition is automatically resized, to 
fully utilise the all available space on the microSD card, on first boot.
  Source: https://ubuntu-mate.org/raspberry-pi/

  This represents a significant impediment to installing security
  updates AND future use cases where more space is required on the
  primary partition.

  My suggestion would be removing the automatic file system re-size and
  allow the user to use parted or gparted to set partition sizes.

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

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


[Touch-packages] [Bug 1818654] Re: unable to login in non-graphic terminal (e.g. tty1)

2019-03-11 Thread crysman
PS: the issue is not present any more. It had been for some two/three
weeks, now it's gone... (no, I have not been using hibernation or
suspend)

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

Title:
  unable to login in non-graphic terminal (e.g. tty1)

Status in lightdm package in Ubuntu:
  New

Bug description:
  I am unable to login in non-graphic terminal (e.g. tty1) ending with
  "Login incorrect" all the time because password prompt does not wait
  for user input.

  Steps to reproduce:
  1) switch to non-graphical terminal (tty1) with CTRL+ALT+F1
  2) you see prompt for login ("login:")
  3) type-in user login -> ENTER
  4) you see password prompt ("password:")
  5) try to type password... what you see is that it behaves as just as if you 
pressed ENTER before actually typing all the passwords characters
  6) this repeats automatically 5 times and then screen is automatically reset 
with blank login prompt

  
  I do not know since when this has occured, but it is VERY SERIOUS bug - if 
something happens in my X (tty7), I am unable to kill or manage it :/

  What might be wrong?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: lightdm 1.26.0-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-45.48-generic 4.15.18
  Uname: Linux 4.15.0-45-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Tue Mar  5 13:09:49 2019
  InstallationDate: Installed on 2018-09-03 (182 days ago)
  InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: lightdm
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-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] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS

2019-03-11 Thread Steve Langasek
Acceptance of openssl currently blocked on coverage of the (distro
patch) OPENSSL_TLS_SECURITY_LEVEL change as part of the SRU template.

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

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

Title:
  [SRU] OpenSSL 1.1.1 to 18.04 LTS

Status in openssl package in Ubuntu:
  In Progress
Status in libio-socket-ssl-perl source package in Bionic:
  New
Status in libnet-ssleay-perl source package in Bionic:
  New
Status in nova source package in Bionic:
  New
Status in openssl source package in Bionic:
  Incomplete
Status in python-cryptography source package in Bionic:
  New
Status in python2.7 source package in Bionic:
  New
Status in python3.6 source package in Bionic:
  New
Status in python3.7 source package in Bionic:
  New
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:
  New

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

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

   * This update bundles python 3.6 and 3.7 point releases

  [Other Info]

   * Previous FFe for OpenSSL in 18.10 is at
     https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092

   * TLS v1.3 support in NSS is expected to make it to 18.04 via
  security updates

   * TLS v1.3 support in GnuTLS is expected to be available in 19.04

   * Test OpenSSL is being prepared in
     https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473

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

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


Re: [Touch-packages] [Bug 1553685] Re: Lenovo Y700-17ISK subwoofer doesn't work

2019-03-11 Thread San cordar
Same here on OpenSUSE Tumbleweed u,u

El lun., 11 de mar. de 2019, 13:45, magdiychuk <1553...@bugs.launchpad.net>
escribió:

> I really hope that the problem will be solved. I use Arch Linux and the
> same problem. The subwoofer does not work ... :-( It is a pity. I would
> like to solve the problem.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1553685
>
> Title:
>   Lenovo Y700-17ISK subwoofer doesn't work
>
> Status in alsa-driver package in Ubuntu:
>   Confirmed
>
> Bug description:
>   Lenovo Y700-17ISK (Intel Core i7-6700HQ/RAM 16GB/SSD 512GB/Nvidia
> GTX960M 4GB)
>   Operating system: Ubuntu 16.04 (xenial-desktop-amd64.iso 04-Mar-2016,
> kernel 4.4.0-10-generic, nvidia 361.28)
>
>   Problem: Notebook subwoofer doesn't work.
>
>   Judging from alsa-info.sh output, there is no pin declared for the bass
> output by BIOS.
>   Please find a zip file attached:
> 'alsa-info_hdajackretask-unconnected-pins'
>
>   ProblemType: Bug
>   DistroRelease: Ubuntu 16.04
>   Package: linux-image-4.4.0-10-generic 4.4.0-10.25
>   ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3
>   Uname: Linux 4.4.0-10-generic x86_64
>   ApportVersion: 2.20-0ubuntu3
>   Architecture: amd64
>   AudioDevicesInUse:
>USERPID ACCESS COMMAND
>/dev/snd/controlC0:  aljosa 1776 F pulseaudio
>   CurrentDesktop: Unity
>   Date: Sun Mar  6 11:02:21 2016
>   HibernationDevice: RESUME=UUID=ac022671-63df-40ae-bffe-66fff3b35125
>   InstallationDate: Installed on 2016-03-05 (0 days ago)
>   InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64
> (20160304)
>   MachineType: LENOVO 80Q0
>   ProcFB: 0 inteldrmfb
>   ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-10-generic.efi.signed
> root=UUID=aa4325c4-4b4c-4372-b8ca-a66c3e5b2aa6 ro quiet splash vt.handoff=7
>   RelatedPackageVersions:
>linux-restricted-modules-4.4.0-10-generic N/A
>linux-backports-modules-4.4.0-10-generic  N/A
>linux-firmware1.156
>   SourcePackage: linux
>   UpgradeStatus: No upgrade log present (probably fresh install)
>   dmi.bios.date: 01/31/2016
>   dmi.bios.vendor: LENOVO
>   dmi.bios.version: CDCN30WW
>   dmi.board.asset.tag: NO Asset Tag
>   dmi.board.name: Allsparks 7A
>   dmi.board.vendor: LENOVO
>   dmi.board.version: NO DPK
>   dmi.chassis.asset.tag: NO Asset Tag
>   dmi.chassis.type: 10
>   dmi.chassis.vendor: LENOVO
>   dmi.chassis.version: Lenovo ideapad Y700-17ISK
>   dmi.modalias:
> dmi:bvnLENOVO:bvrCDCN30WW:bd01/31/2016:svnLENOVO:pn80Q0:pvrLenovoideapadY700-17ISK:rvnLENOVO:rnAllsparks7A:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapadY700-17ISK:
>   dmi.product.name: 80Q0
>   dmi.product.version: Lenovo ideapad Y700-17ISK
>   dmi.sys.vendor: LENOVO
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1553685/+subscriptions
>

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

Title:
  Lenovo Y700-17ISK subwoofer doesn't work

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Lenovo Y700-17ISK (Intel Core i7-6700HQ/RAM 16GB/SSD 512GB/Nvidia GTX960M 4GB)
  Operating system: Ubuntu 16.04 (xenial-desktop-amd64.iso 04-Mar-2016, kernel 
4.4.0-10-generic, nvidia 361.28)

  Problem: Notebook subwoofer doesn't work.

  Judging from alsa-info.sh output, there is no pin declared for the bass 
output by BIOS.
  Please find a zip file attached: 'alsa-info_hdajackretask-unconnected-pins'

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-10-generic 4.4.0-10.25
  ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3
  Uname: Linux 4.4.0-10-generic x86_64
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  aljosa 1776 F pulseaudio
  CurrentDesktop: Unity
  Date: Sun Mar  6 11:02:21 2016
  HibernationDevice: RESUME=UUID=ac022671-63df-40ae-bffe-66fff3b35125
  InstallationDate: Installed on 2016-03-05 (0 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160304)
  MachineType: LENOVO 80Q0
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-10-generic.efi.signed 
root=UUID=aa4325c4-4b4c-4372-b8ca-a66c3e5b2aa6 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-10-generic N/A
   linux-backports-modules-4.4.0-10-generic  N/A
   linux-firmware1.156
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/31/2016
  dmi.bios.vendor: LENOVO
  dmi.bios.version: CDCN30WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Allsparks 7A
  dmi.board.vendor: LENOVO
  dmi.board.version: NO DPK
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10

[Touch-packages] [Bug 1818802] Re: [ZenBook UX433FN_UX433FN] Audio only works when the laptop is plugged in or the battery % is above 20 - 40%

2019-03-11 Thread Filip Golab
Hello, it seems like now audio is not working even when on full battery
or plugged in. It's so weird.

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

Title:
  [ZenBook UX433FN_UX433FN] Audio only works when the laptop is plugged
  in or the battery % is above 20 - 40%

Status in linux package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  Audio dies after few seconds, returns after few minutes and dies again

  filip@ux433:~$ lsb_release -rd
  Description:  Ubuntu 18.10
  Release:  18.10

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  Uname: Linux 4.20.14-042014-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  filip  8566 F pulseaudio
   /dev/snd/pcmC0D0p:   filip  8566 F...m pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar  6 10:11:01 2019
  InstallationDate: Installed on 2019-01-05 (59 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Speaker, Internal
  Symptom_PulseAudioLog: mar 06 10:04:08 ux433 dbus-daemon[3008]: [system] 
Activating via systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.37' (uid=121 pid=6142 
comm="/usr/bin/pulseaudio --daemonize=no ")
  Symptom_Type: Sound works for a while, then breaks
  Title: [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails 
after a while
  UpgradeStatus: Upgraded to cosmic on 2019-01-28 (36 days ago)
  dmi.bios.date: 11/21/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX433FN.301
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX433FN
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX433FN.301:bd11/21/2018:svnASUSTeKCOMPUTERINC.:pnZenBookUX433FN_UX433FN:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX433FN:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: ZenBook
  dmi.product.name: ZenBook UX433FN_UX433FN
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

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

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


[Touch-packages] [Bug 1819503] Re: Drop imagemagick-display from the default install [disco regression]

2019-03-11 Thread amano
** Description changed:

  This is actually a regression in Disco from Artful, Bionic and Cosmic,
  where this was fixed in https://bugs.launchpad.net/bugs/1717951
  
- Since the update to Disco the unprofessional and childish ImageMagick
- icon is back. It was removed in Artful, Bionic and Cosmic for the
- following reasons, perfectly summed up by Jeremy Bicha (a copy and paste
- from Bug #171951):
+ Since the update to Disco the unprofessional ImageMagick icon is back.
+ It was removed in Artful, Bionic and Cosmic for the following reasons,
+ perfectly summed up by Jeremy Bicha (a copy and paste from Bug #171951):
+ 
+ I tested this in the "Ubuntu", "Ubuntu on Wayland" and "GNOME" session
+ and it it returned in all three instances.
  
  Impact
  ==
  I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.
  
  It is visible in the Show Applications view of the Activities Overview
  so this could impact screenshots.
  
  Justification
  =
  imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.
  
  Bundled with imagemagick is the "display" app, which is an app with an
  unusual, difficult-to-use UI. It was not intentionally included in the
  default Ubuntu install but was only there because it was packaged
  together.
  
  I am proposing splitting the display app to a separate binary package so
  that it is available for install for the few who do want to use the app.
  
  I tried proposing this to Debian. See comment #60 on the attached Debian
  bug but the Debian maintainer doesn't seem interested in accepting my
  proposal any time soon. (I emailed him directly a few months ago too.)

** Description changed:

  This is actually a regression in Disco from Artful, Bionic and Cosmic,
  where this was fixed in https://bugs.launchpad.net/bugs/1717951
  
- Since the update to Disco the unprofessional ImageMagick icon is back.
- It was removed in Artful, Bionic and Cosmic for the following reasons,
- perfectly summed up by Jeremy Bicha (a copy and paste from Bug #171951):
  
- I tested this in the "Ubuntu", "Ubuntu on Wayland" and "GNOME" session
- and it it returned in all three instances.
+ I tested this in the "Ubuntu", "Ubuntu on Wayland" and "GNOME" session and 
the bug is visible in all three instances.
+ 
+ Since the update to Disco the rather unprofessional ImageMagick icon is
+ back. It was removed in Artful, Bionic and Cosmic for the following
+ reasons, perfectly summed up by Jeremy Bicha (a copy and paste from Bug
+ #171951):
+ 
  
  Impact
  ==
  I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.
  
  It is visible in the Show Applications view of the Activities Overview
  so this could impact screenshots.
  
  Justification
  =
  imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.
  
  Bundled with imagemagick is the "display" app, which is an app with an
  unusual, difficult-to-use UI. It was not intentionally included in the
  default Ubuntu install but was only there because it was packaged
  together.
  
  I am proposing splitting the display app to a separate binary package so
  that it is available for install for the few who do want to use the app.
  
  I tried proposing this to Debian. See comment #60 on the attached Debian
  bug but the Debian maintainer doesn't seem interested in accepting my
  proposal any time soon. (I emailed him directly a few months ago too.)

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

Title:
  Drop imagemagick-display from the default install  [disco regression]

Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  This is actually a regression in Disco from Artful, Bionic and Cosmic,
  where this was fixed in https://bugs.launchpad.net/bugs/1717951

  
  I tested this in the "Ubuntu", "Ubuntu on Wayland" and "GNOME" session and 
the bug is visible in all three instances.

  Since the update to Disco the rather unprofessional ImageMagick icon
  is back. It was removed in Artful, Bionic and Cosmic for the following
  reasons, perfectly summed up by Jeremy Bicha (a copy and paste from
  Bug #171951):

  
  Impact
  ==
  I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.

  It is visible in the Show Applications view of the Activities Overview
  so this could impact screenshots.

  Justification
  =
  imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.

  Bundled with imagemagick is the "display" app, which is an app with an
  

[Touch-packages] [Bug 1717951] Re: UIFe: Drop imagemagick-display from the default install

2019-03-11 Thread amano
Filed https://bugs.launchpad.net/ubuntu/+source/ubuntu-
settings/+bug/1819503

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

Title:
  UIFe: Drop imagemagick-display from the default install

Status in ubuntu-settings package in Ubuntu:
  Fix Released
Status in imagemagick package in Debian:
  New

Bug description:
  Impact
  ==
  I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.

  It is visible in the Show Applications view of the Activities Overview
  so this could impact screenshots.

  Justification
  =
  imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.

  Bundled with imagemagick is the "display" app, which is an app with an
  unusual, difficult-to-use UI. It was not intentionally included in the
  default Ubuntu install but was only there because it was packaged
  together.

  I am proposing splitting the display app to a separate binary package
  so that it is available for install for the few who do want to use the
  app.

  I tried proposing this to Debian. See comment #60 on the attached
  Debian bug but the Debian maintainer doesn't seem interested in
  accepting my proposal any time soon. (I emailed him directly a few
  months ago too.)

  List Notifications
  ==
  https://lists.ubuntu.com/archives/ubuntu-doc/2017-September/020534.html
  
https://lists.ubuntu.com/archives/ubuntu-translators/2017-September/007403.html

  Other Info
  ==
  I will be attaching a patch for review by the Desktop Team here soon.

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

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


[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 237-3ubuntu10.15

---
systemd (237-3ubuntu10.15) bionic; urgency=medium

  [ Victor Tapia ]
  * d/p/stop-mount-error-propagation.patch:
keep mount errors local to the failing mount point instead of blocking
the processing of all mounts (LP: #1755863)

 -- Dan Streetman   Thu, 28 Feb 2019 16:03:40
-0500

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

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

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

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Mounting manually a network share (NFS) and masking it breaks the state of 
other units (and their dependencies).
  Casper is masking a mounted NFS share, blocking the normal boot process as 
described in the original description, but the issue comes from systemd.

  [Test Case]

  - NFS mount point at /media
  root@iscsi-bionic:/home/ubuntu# mount | grep media
  10.230.56.72:/tmp/mnt on /media type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72)

  - Test mount point (/test) defined in /etc/fstab:
  root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test
  tmpfs /test tmpfs nosuid,nodev 0 0

  1. If media.mount is not masked, everything works fine:

  root@iscsi-bionic:/home/ubuntu# mount | grep test
  root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active
 Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days 
ago
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test

  2. If media.mount is masked, other mounts are failing:

  root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount
  Created symlink /etc/systemd/system/media.mount → /dev/null.
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)

  [Regression potential]

  Minimal. Originally, one failing mount point blocked the processing of
  the rest due to how the return codes were handled for every line in
  /proc/self/mountinfo. This patch removes this "dependency" and keeps
  the failure local to the affected mount point, allowing the rest to be
  processed normally.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10874
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3

  [Original Description]

  
  netbooting the bionic live CD[1] over NFS goes straight to maintenance mode 

[Touch-packages] [Bug 1815101] Re: netplan removes keepalived configuration

2019-03-11 Thread Andreas Hasenack
Seems a dupe to me.

For the bionic case, with keepalived < 2.0, is there some keepalived
script that can be run to restore the vip, after networkd removed it? We
could run it as a network-dispatcher hook then. Has this been
considered?

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

Title:
  netplan removes keepalived configuration

Status in netplan:
  Invalid
Status in keepalived package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth2:
  addresses:
- 12.13.14.18/29
- 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
  vrrp_mcast_group6 ff02::12   # optional, default ff02::12
  enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
  group {
  wan
  lan
  phone
  }
  vrrp_instance wan {
  state MASTER
  interface eth2
  virtual_router_id 77
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass BlahBlah
  }
  virtual_ipaddress {
  12.13.14.20
  }
  }
  vrrp_instance lan {
  state MASTER
  interface eth3
  virtual_router_id 78
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MoreBlah
  }
  virtual_ipaddress {
  10.22.11.13/24
  }
  }
  vrrp_instance phone {
  state MASTER
  interface eth4
  virtual_router_id 79
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MostBlah
  }
  virtual_ipaddress {
  10.22.14.3/24
  }
  }

  At boot the affected interfaces have:
  5: eth4:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
  inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
 valid_lft forever preferred_lft forever
  inet 10.22.14.3/24 scope global secondary eth4
 valid_lft forever preferred_lft forever
  inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link 
 valid_lft forever preferred_lft forever
  7: eth3:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:b0:26:29 brd ff:ff:ff:ff:ff:ff
  inet 10.22.11.6/24 brd 10.22.11.255 scope global eth3
 valid_lft forever preferred_lft forever
  inet 10.22.11.13/24 scope global secondary eth3
 valid_lft forever preferred_lft forever
  inet6 fe80::ae1f:6bff:feb0:2629/64 scope link 
 valid_lft forever preferred_lft forever
  9: eth2:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:b0:26:2b brd 

[Touch-packages] [Bug 1795764] Re: systemd: core: Fix edge case when processing /proc/self/mountinfo

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 229-4ubuntu21.17

---
systemd (229-4ubuntu21.17) xenial; urgency=medium

  [ Victor Tapia ]
  * d/p/stop-mount-error-propagation.patch:
keep mount errors local to the failing mount point instead of blocking
the processing of all mounts (LP: #1755863)

  [ Eric Desrochers ]
  * d/p/fix-egde-case-when-processing-proc-self-mountinfo.patch:
Mounting any file system to a mount point in a directory
that is bind mounted to itself will create an inactive
mount unit. (LP: #1795764)

 -- Dan Streetman   Thu, 28 Feb 2019 17:50:50
-0500

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

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

Title:
  systemd: core: Fix edge case when processing /proc/self/mountinfo

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  kubernetes loaded inactive dead transient mount points grows
  https://github.com/kubernetes/kubernetes/issues/57345

  [Test Case]

  # cd /tmp
  # mkdir -p bind-test/abc
  # mount --bind bind-test bind-test
  # mount -t tmpfs tmpfs bind-test/abc
  # umount bind-test/abc
  # systemctl list-units --all | grep bind-test
  tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
  tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test

  Expected outcome (w/ the fix) :

  # cd /tmp
  # mkdir -p bind-test/abc
  # mount --bind bind-test bind-test
  # mount -t tmpfs tmpfs bind-test/abc
  # umount bind-test/abc
  # systemctl list-units --all | grep bind-test
  tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test

  [Regression Potential]

  This is a adapted version of 2 upstream fixes as the original upstream
  commit has been made on top on 2 functions mount_setup_new_unit() &
  mount_setup_existing_unit() that not yet exist systemd 229. It is
  easily adaptable because the current function mount_setup_unit() is
  dealing with both of at the moment instead of being individually
  separate in two distinct function.

  It is an adaptation of commits :
  [65d36b495] core: Fix edge case when processing /proc/self/mountinfo
  [03b8cfede] core: make sure to init mount params before calling 
mount_is_extrinsic()

  This patch changes mount_setup_unit() to prevent the just_mounted
  mount setup flag from being overwritten if it is set to true. This
  will allow all mount units created from /proc/self/mountinfo entries
  to be initialised properly.

  Additionally, the patch got the blessing of 'xnox' who looked at it
  and mention it looks fine to him.

  [Pending SRU]

  Note: No autopkgtests has been reported since systemd (21.5) ...
  between 21.5 and now (21.11) everything released has been about
  security fixes :

  systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
  systemd (229-4ubuntu21.10) xenial-security; urgency=medium
  systemd (229-4ubuntu21.9) xenial-security; urgency=medium
  systemd (229-4ubuntu21.8) xenial-security; urgency=medium
  systemd (229-4ubuntu21.6) xenial-security; urgency=medium
  systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU

  
  Note: I don't know the level of adoption of Netplan in Xenial, but I suspect 
it is low as Netplan replaced ifupdown as the default configuration utility 
starting with Ubuntu 17.10 Artful only AFAIK.

  
  * Regression in autopkgtest for nplan (s390x): test log
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz

  Error:
  modprobe: FATAL: Module cfg80211 not found in directory 
/lib/modules/4.4.0-138-generic

  Justification:
  This above seems to be a recurrent failure since a couple of release already. 
This wasn't introduce by this particular SRU.

  I don't think having wifi module is relevant in s390x anyway, so most
  likely the module is not there on purpose for kernel w/ s390x
  architecture.

  * Regression in autopkgtest for nplan (amd64): test log
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz

  Error: (Ran on autopkgtest Ubuntu infra)
  test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could 
not create NMClient object: Cannot invoke method; proxy is for a well-known 
name without an owner and proxy was constructed with the 
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  test_bridge_priority (__main__.TestNetworkManager) ... Error: Could
  not create NMClient object: Cannot invoke method; proxy is for a well-
  known name without an owner and proxy was constructed with the
  G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  test_dhcp6 (__main__.TestNetworkManager) ... 

[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 239-7ubuntu10.10

---
systemd (239-7ubuntu10.10) cosmic; urgency=medium

  [ Victor Tapia ]
  * d/p/stop-mount-error-propagation.patch:
keep mount errors local to the failing mount point instead of
blocking the processing of all mounts (LP: #1755863)

 -- Dan Streetman   Thu, 28 Feb 2019 14:29:48
-0500

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

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Mounting manually a network share (NFS) and masking it breaks the state of 
other units (and their dependencies).
  Casper is masking a mounted NFS share, blocking the normal boot process as 
described in the original description, but the issue comes from systemd.

  [Test Case]

  - NFS mount point at /media
  root@iscsi-bionic:/home/ubuntu# mount | grep media
  10.230.56.72:/tmp/mnt on /media type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72)

  - Test mount point (/test) defined in /etc/fstab:
  root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test
  tmpfs /test tmpfs nosuid,nodev 0 0

  1. If media.mount is not masked, everything works fine:

  root@iscsi-bionic:/home/ubuntu# mount | grep test
  root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active
 Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days 
ago
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test

  2. If media.mount is masked, other mounts are failing:

  root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount
  Created symlink /etc/systemd/system/media.mount → /dev/null.
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)

  [Regression potential]

  Minimal. Originally, one failing mount point blocked the processing of
  the rest due to how the return codes were handled for every line in
  /proc/self/mountinfo. This patch removes this "dependency" and keeps
  the failure local to the affected mount point, allowing the rest to be
  processed normally.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10874
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3

  [Original Description]

  
  netbooting the bionic live CD[1] over NFS goes straight to maintenance mode :

  [1] http://cdimage.ubuntu.com/daily-live/current/

  # casper.log
  Begin: 

[Touch-packages] [Bug 1755863] Update Released

2019-03-11 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1755863

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Mounting manually a network share (NFS) and masking it breaks the state of 
other units (and their dependencies).
  Casper is masking a mounted NFS share, blocking the normal boot process as 
described in the original description, but the issue comes from systemd.

  [Test Case]

  - NFS mount point at /media
  root@iscsi-bionic:/home/ubuntu# mount | grep media
  10.230.56.72:/tmp/mnt on /media type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72)

  - Test mount point (/test) defined in /etc/fstab:
  root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test
  tmpfs /test tmpfs nosuid,nodev 0 0

  1. If media.mount is not masked, everything works fine:

  root@iscsi-bionic:/home/ubuntu# mount | grep test
  root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active
 Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days 
ago
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test

  2. If media.mount is masked, other mounts are failing:

  root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount
  Created symlink /etc/systemd/system/media.mount → /dev/null.
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)

  [Regression potential]

  Minimal. Originally, one failing mount point blocked the processing of
  the rest due to how the return codes were handled for every line in
  /proc/self/mountinfo. This patch removes this "dependency" and keeps
  the failure local to the affected mount point, allowing the rest to be
  processed normally.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10874
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3

  [Original Description]

  
  netbooting the bionic live CD[1] over NFS goes straight to maintenance mode :

  [1] http://cdimage.ubuntu.com/daily-live/current/

  # casper.log
  

[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package systemd - 229-4ubuntu21.17

---
systemd (229-4ubuntu21.17) xenial; urgency=medium

  [ Victor Tapia ]
  * d/p/stop-mount-error-propagation.patch:
keep mount errors local to the failing mount point instead of blocking
the processing of all mounts (LP: #1755863)

  [ Eric Desrochers ]
  * d/p/fix-egde-case-when-processing-proc-self-mountinfo.patch:
Mounting any file system to a mount point in a directory
that is bind mounted to itself will create an inactive
mount unit. (LP: #1795764)

 -- Dan Streetman   Thu, 28 Feb 2019 17:50:50
-0500

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

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Mounting manually a network share (NFS) and masking it breaks the state of 
other units (and their dependencies).
  Casper is masking a mounted NFS share, blocking the normal boot process as 
described in the original description, but the issue comes from systemd.

  [Test Case]

  - NFS mount point at /media
  root@iscsi-bionic:/home/ubuntu# mount | grep media
  10.230.56.72:/tmp/mnt on /media type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72)

  - Test mount point (/test) defined in /etc/fstab:
  root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test
  tmpfs /test tmpfs nosuid,nodev 0 0

  1. If media.mount is not masked, everything works fine:

  root@iscsi-bionic:/home/ubuntu# mount | grep test
  root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active
 Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days 
ago
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test

  2. If media.mount is masked, other mounts are failing:

  root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount
  Created symlink /etc/systemd/system/media.mount → /dev/null.
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)

  [Regression potential]

  Minimal. Originally, one failing mount point blocked the processing of
  the rest due to how the return codes were handled for every line in
  /proc/self/mountinfo. This patch removes this "dependency" and keeps
  the failure local to the affected mount point, allowing the rest to be
  processed normally.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10874
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3

  [Original Description]

  
  

[Touch-packages] [Bug 1819503] Re: Drop imagemagick-display from the default install [disco regression]

2019-03-11 Thread amano
** Summary changed:

- Drop imagemagick-display from the default install  [regression]
+ Drop imagemagick-display from the default install  [disco regression]

** Description changed:

- This is actually a regression from
- https://bugs.launchpad.net/bugs/1717951
+ This is actually a regression in Disco from Artful, Bionic and Cosmic,
+ where this was fixed in https://bugs.launchpad.net/bugs/1717951
  
  Since the update to Disco the unprofessional and childish ImageMagick
  icon is back. It was removed in Artful, Bionic and Cosmic for the
  following reasons, perfectly summed up by Jeremy Bicha (a copy and paste
  from Bug #171951):
  
  Impact
  ==
  I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.
  
  It is visible in the Show Applications view of the Activities Overview
  so this could impact screenshots.
  
  Justification
  =
  imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.
  
  Bundled with imagemagick is the "display" app, which is an app with an
  unusual, difficult-to-use UI. It was not intentionally included in the
  default Ubuntu install but was only there because it was packaged
  together.
  
  I am proposing splitting the display app to a separate binary package so
  that it is available for install for the few who do want to use the app.
  
  I tried proposing this to Debian. See comment #60 on the attached Debian
  bug but the Debian maintainer doesn't seem interested in accepting my
  proposal any time soon. (I emailed him directly a few months ago too.)

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

Title:
  Drop imagemagick-display from the default install  [disco regression]

Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  This is actually a regression in Disco from Artful, Bionic and Cosmic,
  where this was fixed in https://bugs.launchpad.net/bugs/1717951

  
  I tested this in the "Ubuntu", "Ubuntu on Wayland" and "GNOME" session and 
the bug is visible in all three instances.

  Since the update to Disco the rather unprofessional ImageMagick icon
  is back. It was removed in Artful, Bionic and Cosmic for the following
  reasons, perfectly summed up by Jeremy Bicha (a copy and paste from
  Bug #171951):

  
  Impact
  ==
  I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.

  It is visible in the Show Applications view of the Activities Overview
  so this could impact screenshots.

  Justification
  =
  imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.

  Bundled with imagemagick is the "display" app, which is an app with an
  unusual, difficult-to-use UI. It was not intentionally included in the
  default Ubuntu install but was only there because it was packaged
  together.

  I am proposing splitting the display app to a separate binary package
  so that it is available for install for the few who do want to use the
  app.

  I tried proposing this to Debian. See comment #60 on the attached
  Debian bug but the Debian maintainer doesn't seem interested in
  accepting my proposal any time soon. (I emailed him directly a few
  months ago too.)

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

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


[Touch-packages] [Bug 1795764] Update Released

2019-03-11 Thread Łukasz Zemczak
The verification of the Stable Release Update for systemd 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1795764

Title:
  systemd: core: Fix edge case when processing /proc/self/mountinfo

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  kubernetes loaded inactive dead transient mount points grows
  https://github.com/kubernetes/kubernetes/issues/57345

  [Test Case]

  # cd /tmp
  # mkdir -p bind-test/abc
  # mount --bind bind-test bind-test
  # mount -t tmpfs tmpfs bind-test/abc
  # umount bind-test/abc
  # systemctl list-units --all | grep bind-test
  tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
  tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test

  Expected outcome (w/ the fix) :

  # cd /tmp
  # mkdir -p bind-test/abc
  # mount --bind bind-test bind-test
  # mount -t tmpfs tmpfs bind-test/abc
  # umount bind-test/abc
  # systemctl list-units --all | grep bind-test
  tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test

  [Regression Potential]

  This is a adapted version of 2 upstream fixes as the original upstream
  commit has been made on top on 2 functions mount_setup_new_unit() &
  mount_setup_existing_unit() that not yet exist systemd 229. It is
  easily adaptable because the current function mount_setup_unit() is
  dealing with both of at the moment instead of being individually
  separate in two distinct function.

  It is an adaptation of commits :
  [65d36b495] core: Fix edge case when processing /proc/self/mountinfo
  [03b8cfede] core: make sure to init mount params before calling 
mount_is_extrinsic()

  This patch changes mount_setup_unit() to prevent the just_mounted
  mount setup flag from being overwritten if it is set to true. This
  will allow all mount units created from /proc/self/mountinfo entries
  to be initialised properly.

  Additionally, the patch got the blessing of 'xnox' who looked at it
  and mention it looks fine to him.

  [Pending SRU]

  Note: No autopkgtests has been reported since systemd (21.5) ...
  between 21.5 and now (21.11) everything released has been about
  security fixes :

  systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
  systemd (229-4ubuntu21.10) xenial-security; urgency=medium
  systemd (229-4ubuntu21.9) xenial-security; urgency=medium
  systemd (229-4ubuntu21.8) xenial-security; urgency=medium
  systemd (229-4ubuntu21.6) xenial-security; urgency=medium
  systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU

  
  Note: I don't know the level of adoption of Netplan in Xenial, but I suspect 
it is low as Netplan replaced ifupdown as the default configuration utility 
starting with Ubuntu 17.10 Artful only AFAIK.

  
  * Regression in autopkgtest for nplan (s390x): test log
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz

  Error:
  modprobe: FATAL: Module cfg80211 not found in directory 
/lib/modules/4.4.0-138-generic

  Justification:
  This above seems to be a recurrent failure since a couple of release already. 
This wasn't introduce by this particular SRU.

  I don't think having wifi module is relevant in s390x anyway, so most
  likely the module is not there on purpose for kernel w/ s390x
  architecture.

  * Regression in autopkgtest for nplan (amd64): test log
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz

  Error: (Ran on autopkgtest Ubuntu infra)
  test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could 
not create NMClient object: Cannot invoke method; proxy is for a well-known 
name without an owner and proxy was constructed with the 
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  test_bridge_priority (__main__.TestNetworkManager) ... Error: Could
  not create NMClient object: Cannot invoke method; proxy is for a well-
  known name without an owner and proxy was constructed with the
  G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create
  NMClient object: Cannot invoke method; proxy is for a well-known name
  without an owner and proxy was constructed with the
  G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  Justification:

  The test are 

[Touch-packages] [Bug 1553685] Re: Lenovo Y700-17ISK subwoofer doesn't work

2019-03-11 Thread magdiychuk
I really hope that the problem will be solved. I use Arch Linux and the
same problem. The subwoofer does not work ... :-( It is a pity. I would
like to solve the problem.

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

Title:
  Lenovo Y700-17ISK subwoofer doesn't work

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Lenovo Y700-17ISK (Intel Core i7-6700HQ/RAM 16GB/SSD 512GB/Nvidia GTX960M 4GB)
  Operating system: Ubuntu 16.04 (xenial-desktop-amd64.iso 04-Mar-2016, kernel 
4.4.0-10-generic, nvidia 361.28)

  Problem: Notebook subwoofer doesn't work.

  Judging from alsa-info.sh output, there is no pin declared for the bass 
output by BIOS.
  Please find a zip file attached: 'alsa-info_hdajackretask-unconnected-pins'

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-10-generic 4.4.0-10.25
  ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3
  Uname: Linux 4.4.0-10-generic x86_64
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  aljosa 1776 F pulseaudio
  CurrentDesktop: Unity
  Date: Sun Mar  6 11:02:21 2016
  HibernationDevice: RESUME=UUID=ac022671-63df-40ae-bffe-66fff3b35125
  InstallationDate: Installed on 2016-03-05 (0 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160304)
  MachineType: LENOVO 80Q0
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-10-generic.efi.signed 
root=UUID=aa4325c4-4b4c-4372-b8ca-a66c3e5b2aa6 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-10-generic N/A
   linux-backports-modules-4.4.0-10-generic  N/A
   linux-firmware1.156
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/31/2016
  dmi.bios.vendor: LENOVO
  dmi.bios.version: CDCN30WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Allsparks 7A
  dmi.board.vendor: LENOVO
  dmi.board.version: NO DPK
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad Y700-17ISK
  dmi.modalias: 
dmi:bvnLENOVO:bvrCDCN30WW:bd01/31/2016:svnLENOVO:pn80Q0:pvrLenovoideapadY700-17ISK:rvnLENOVO:rnAllsparks7A:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapadY700-17ISK:
  dmi.product.name: 80Q0
  dmi.product.version: Lenovo ideapad Y700-17ISK
  dmi.sys.vendor: LENOVO

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

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


[Touch-packages] [Bug 1815415] Update Released

2019-03-11 Thread Łukasz Zemczak
The verification of the Stable Release Update for libseccomp 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 libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415

Title:
  please update libseccomp for newer kernel syscalls

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Bionic:
  Fix Released
Status in libseccomp source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * The libseccomp library provides an easy to use, platform independent,
     interface to the Linux Kernel's syscall filtering mechanism. But it can
     only "control" those syscalls it knows about. Therefore staying up to
     date with newer kernels is a requirement to be fully funcitonal.

   * At the time 18.04 was released with the 4.15 kernel the new definitions
     were not yet released for libseccomp - lets fix this mismatch by
     backporting the new syscall definitions [2][3][4].

  [Test Case]

   * Note: a lot of this is kernel dependent it should work with the
  intended SRU target of Bionic with kernel 4.15 or 4.18, but be careful
  to run it there (e.g. not a LXD container on Xenials 4.4 kernel)

   * we modify the already existing autopkgtest for this SRU
  verification

  # Prep
  $ apt install ubuntu-dev-tools build-essential linux-libc-dev libseccomp-dev 
libseccomp2 seccomp
  $ pull-lp-source libseccomp bionic
  $ cd libseccomp-2.3.1
  $ export ADTTMP=$(mktemp -d); echo $ADTTMP
  # run original tests as-is (should pass/fail as expected)
  $ ./debian/tests/test-filter
  # add new syscalls of this SRU
  $ cp debian/tests/data/safe.filter debian/tests/data/newcodes.filter
  $ printf 
"preadv2\npwritev2\npkey_mprotect\npkey_alloc\npkey_free\nget_tls\ns390_guarded_storage\ns390_sthyi\n"
 >> debian/tests/data/newcodes.filter
  # remove unknown calls (x86 4.18 kernel)
  sed -i -e '/^_exit$/d' -e '/^fstatvfs$/d' -e '/^llseek$/d' -e '/^pread$/d' -e 
'/^pselect$/d' -e '/^pwrite$/d' -e '/^sigtimedwait$/d' -e '/^sigwaitinfo$/d' -e 
'/^statvfs$/d' debian/tests/data/newcodes.filter
  # make unknown call a fail
  $ sed -i -e '111s/continue;/{fprintf(stderr, "failed to find %s\\n",buf);rc = 
-1;goto out;}/' debian/tests/src/test-seccomp.c
  # build new test binary
  $ export ADTTMP=$(mktemp -d); echo $ADTTMP
  $ ./debian/tests/test-filter
  # run this special test and check return value
  ${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?

  Without the fix it will fail like:
  DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
  failed to find preadv2
  seccomp_load_filters failed with -1
  1

  But with the fix applied those new calls will work:
  DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
  Tue Feb 12 07:41:05 UTC 2019
  0

  [Regression Potential]

   * This isn't adding new active code like functions, but only extending
     the definitions of per-arch syscall numbers to be aware of the newer
     syscalls that were added in the kernel. Therefore no old use-cases
     should regress (they are not touched). The only change in behavior for
     an SRU POV would be that things that got denied so far (e.g. if you
     tried to set such a new syscall through libseccomp) was denied before
     and would now work. I think that is exactly the intention of the SRU
     and not a regression.

  [Other Info]

   * Requested while security reviewing an libseccomp SRU to have one update
     for both [1].
   * we also missed the former update for kernel 4.9 [3] AND 4.10 [4] as the
     official releases of the lib are rather seldom.
   * In general there already are build time tests and autopkgtests in the
     package already. So coverage of "old calls" for regressions is already
     good.

  ---

  This came up while working on bug 1755250 which asked for statx.
  But on the review of that it was pointed out [1] that it would be great to 
support further new kernel syscall defines - this isn't even looking at HWE 
kernels for Bionic, but "just" adding those which are there for the 4.15 kernel 
Bionic was released with.
  With the HWE kernels in mind there would be even more one might want to add, 
but there is no newer such update in the upstream repo yet.

  [1]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
  [2]: 
https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
  [3]: 

[Touch-packages] [Bug 1755250] Re: backport statx syscall whitelist fix

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package libseccomp - 2.3.1-2.1ubuntu4.1

---
libseccomp (2.3.1-2.1ubuntu4.1) bionic; urgency=medium

  * d/p/lp-1755250-add-the-statx-syscall.patch: add statx support (LP: #1755250)
  * d/p/lp-1815415-*: Add syscalls up to kernel 4.15 (LP: #1815415)

 -- Christian Ehrhardt   Fri, 08 Feb
2019 09:17:23 +0100

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

Title:
  backport statx syscall whitelist fix

Status in docker.io package in Ubuntu:
  Invalid
Status in libseccomp package in Ubuntu:
  Fix Released
Status in docker.io source package in Bionic:
  Invalid
Status in libseccomp source package in Bionic:
  Fix Released
Status in docker.io source package in Cosmic:
  Invalid
Status in libseccomp source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * Some newer workloads fail due to libseccomp as in Bionic lacking
  statx support

   * This backports the syscall definitions for statx to Bionic to allow
  to manage those

  [Test Case]

  # Note: I took a KVM image of Bionic to not spoil my system with Docker 
config for this test too much
  $ sudo apt install docker.io
  $ sudo usermod -a -G docker ubuntu
  $ cat > test-statx/Dockerfile << EOF
  FROM ubuntu:18.04
  RUN apt-get update && apt-get install -y wget gcc
  WORKDIR /tmp
  RUN wget -q 
https://raw.githubusercontent.com/torvalds/linux/master/samples/statx/test-statx.c
  RUN gcc test-statx.c -o test-statx
  RUN touch test-file
  RUN chmod +x ./test-statx
  RUN ./test-statx test-file
  EOF
  $ docker build test-statx

  With the bug and current docker 18.06.1-0ubuntu1~18.04.1 in Bionic
  that yields

  [...]
  Step 8/8 : RUN ./test-statx test-file
   ---> Running in 6e60a82409e6
  test-file: Operation not permitted
  statx(test-file) = -1
  The command '/bin/sh -c ./test-statx test-file' returned a non-zero code: 1

  With the fix applied it would work and look like:
  Step 8/8 : RUN ./test-statx test-file
   ---> Running in a83bc043e7bd
  statx(test-file) = 0
  results=fff
Size: 0   Blocks: 0  IO Block: 4096regular file
  Device: 00:32   Inode: 261994  Links: 1
  Access: (0644/-rw-r--r--)  Uid: 0   Gid: 0
  Access: 2019-02-08 07:57:42.0+
  Modify: 2019-02-08 07:57:42.0+
  Change: 2019-02-08 07:57:43.076507007+
   Birth: 2019-02-08 07:57:43.076507007+
  Attributes:  (     
 -... .---.-..)
  Removing intermediate container a83bc043e7bd
   ---> d428d14cbc57
  Successfully built d428d14cbc57

  
  [Regression Potential] 

   * This "only" defines a new syscall number for all the architectures.
  It does not make any other changes, thereby it should be rather safe.
  If anything software could now manage statx through libseccomp and
  behavior that was formerly failing (like the reported docker case)
  would not succeed and due to that be a change in behavior - but I
  think it is a wanted change.

  [Other Info]
   
   * n/a

  ---

  
  Hello maintainer,

  The docker version 17.03 (bionic) in ubuntu doesn't allow the statx syscall 
which is needed to build qt >=5.10 applications:
  https://github.com/docker/for-linux/issues/208#issuecomment-372400859

  Could this fix be backported in the ubuntu package ?
  https://github.com/moby/moby/pull/36417

  regards,
  xan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1755250/+subscriptions

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


[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package libseccomp - 2.3.1-2.1ubuntu4.1

---
libseccomp (2.3.1-2.1ubuntu4.1) bionic; urgency=medium

  * d/p/lp-1755250-add-the-statx-syscall.patch: add statx support (LP: #1755250)
  * d/p/lp-1815415-*: Add syscalls up to kernel 4.15 (LP: #1815415)

 -- Christian Ehrhardt   Fri, 08 Feb
2019 09:17:23 +0100

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

Title:
  please update libseccomp for newer kernel syscalls

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Bionic:
  Fix Released
Status in libseccomp source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * The libseccomp library provides an easy to use, platform independent,
     interface to the Linux Kernel's syscall filtering mechanism. But it can
     only "control" those syscalls it knows about. Therefore staying up to
     date with newer kernels is a requirement to be fully funcitonal.

   * At the time 18.04 was released with the 4.15 kernel the new definitions
     were not yet released for libseccomp - lets fix this mismatch by
     backporting the new syscall definitions [2][3][4].

  [Test Case]

   * Note: a lot of this is kernel dependent it should work with the
  intended SRU target of Bionic with kernel 4.15 or 4.18, but be careful
  to run it there (e.g. not a LXD container on Xenials 4.4 kernel)

   * we modify the already existing autopkgtest for this SRU
  verification

  # Prep
  $ apt install ubuntu-dev-tools build-essential linux-libc-dev libseccomp-dev 
libseccomp2 seccomp
  $ pull-lp-source libseccomp bionic
  $ cd libseccomp-2.3.1
  $ export ADTTMP=$(mktemp -d); echo $ADTTMP
  # run original tests as-is (should pass/fail as expected)
  $ ./debian/tests/test-filter
  # add new syscalls of this SRU
  $ cp debian/tests/data/safe.filter debian/tests/data/newcodes.filter
  $ printf 
"preadv2\npwritev2\npkey_mprotect\npkey_alloc\npkey_free\nget_tls\ns390_guarded_storage\ns390_sthyi\n"
 >> debian/tests/data/newcodes.filter
  # remove unknown calls (x86 4.18 kernel)
  sed -i -e '/^_exit$/d' -e '/^fstatvfs$/d' -e '/^llseek$/d' -e '/^pread$/d' -e 
'/^pselect$/d' -e '/^pwrite$/d' -e '/^sigtimedwait$/d' -e '/^sigwaitinfo$/d' -e 
'/^statvfs$/d' debian/tests/data/newcodes.filter
  # make unknown call a fail
  $ sed -i -e '111s/continue;/{fprintf(stderr, "failed to find %s\\n",buf);rc = 
-1;goto out;}/' debian/tests/src/test-seccomp.c
  # build new test binary
  $ export ADTTMP=$(mktemp -d); echo $ADTTMP
  $ ./debian/tests/test-filter
  # run this special test and check return value
  ${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?

  Without the fix it will fail like:
  DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
  failed to find preadv2
  seccomp_load_filters failed with -1
  1

  But with the fix applied those new calls will work:
  DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
  Tue Feb 12 07:41:05 UTC 2019
  0

  [Regression Potential]

   * This isn't adding new active code like functions, but only extending
     the definitions of per-arch syscall numbers to be aware of the newer
     syscalls that were added in the kernel. Therefore no old use-cases
     should regress (they are not touched). The only change in behavior for
     an SRU POV would be that things that got denied so far (e.g. if you
     tried to set such a new syscall through libseccomp) was denied before
     and would now work. I think that is exactly the intention of the SRU
     and not a regression.

  [Other Info]

   * Requested while security reviewing an libseccomp SRU to have one update
     for both [1].
   * we also missed the former update for kernel 4.9 [3] AND 4.10 [4] as the
     official releases of the lib are rather seldom.
   * In general there already are build time tests and autopkgtests in the
     package already. So coverage of "old calls" for regressions is already
     good.

  ---

  This came up while working on bug 1755250 which asked for statx.
  But on the review of that it was pointed out [1] that it would be great to 
support further new kernel syscall defines - this isn't even looking at HWE 
kernels for Bionic, but "just" adding those which are there for the 4.15 kernel 
Bionic was released with.
  With the HWE kernels in mind there would be even more one might want to add, 
but there is no newer such update in the upstream repo yet.

  [1]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
  [2]: 
https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
  [3]: 
https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c
  [4]: 

[Touch-packages] [Bug 1755250] Update Released

2019-03-11 Thread Łukasz Zemczak
The verification of the Stable Release Update for libseccomp 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 libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1755250

Title:
  backport statx syscall whitelist fix

Status in docker.io package in Ubuntu:
  Invalid
Status in libseccomp package in Ubuntu:
  Fix Released
Status in docker.io source package in Bionic:
  Invalid
Status in libseccomp source package in Bionic:
  Fix Released
Status in docker.io source package in Cosmic:
  Invalid
Status in libseccomp source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * Some newer workloads fail due to libseccomp as in Bionic lacking
  statx support

   * This backports the syscall definitions for statx to Bionic to allow
  to manage those

  [Test Case]

  # Note: I took a KVM image of Bionic to not spoil my system with Docker 
config for this test too much
  $ sudo apt install docker.io
  $ sudo usermod -a -G docker ubuntu
  $ cat > test-statx/Dockerfile << EOF
  FROM ubuntu:18.04
  RUN apt-get update && apt-get install -y wget gcc
  WORKDIR /tmp
  RUN wget -q 
https://raw.githubusercontent.com/torvalds/linux/master/samples/statx/test-statx.c
  RUN gcc test-statx.c -o test-statx
  RUN touch test-file
  RUN chmod +x ./test-statx
  RUN ./test-statx test-file
  EOF
  $ docker build test-statx

  With the bug and current docker 18.06.1-0ubuntu1~18.04.1 in Bionic
  that yields

  [...]
  Step 8/8 : RUN ./test-statx test-file
   ---> Running in 6e60a82409e6
  test-file: Operation not permitted
  statx(test-file) = -1
  The command '/bin/sh -c ./test-statx test-file' returned a non-zero code: 1

  With the fix applied it would work and look like:
  Step 8/8 : RUN ./test-statx test-file
   ---> Running in a83bc043e7bd
  statx(test-file) = 0
  results=fff
Size: 0   Blocks: 0  IO Block: 4096regular file
  Device: 00:32   Inode: 261994  Links: 1
  Access: (0644/-rw-r--r--)  Uid: 0   Gid: 0
  Access: 2019-02-08 07:57:42.0+
  Modify: 2019-02-08 07:57:42.0+
  Change: 2019-02-08 07:57:43.076507007+
   Birth: 2019-02-08 07:57:43.076507007+
  Attributes:  (     
 -... .---.-..)
  Removing intermediate container a83bc043e7bd
   ---> d428d14cbc57
  Successfully built d428d14cbc57

  
  [Regression Potential] 

   * This "only" defines a new syscall number for all the architectures.
  It does not make any other changes, thereby it should be rather safe.
  If anything software could now manage statx through libseccomp and
  behavior that was formerly failing (like the reported docker case)
  would not succeed and due to that be a change in behavior - but I
  think it is a wanted change.

  [Other Info]
   
   * n/a

  ---

  
  Hello maintainer,

  The docker version 17.03 (bionic) in ubuntu doesn't allow the statx syscall 
which is needed to build qt >=5.10 applications:
  https://github.com/docker/for-linux/issues/208#issuecomment-372400859

  Could this fix be backported in the ubuntu package ?
  https://github.com/moby/moby/pull/36417

  regards,
  xan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1755250/+subscriptions

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


[Touch-packages] [Bug 1819503] [NEW] Drop imagemagick-display from the default install [disco regression]

2019-03-11 Thread amano
Public bug reported:

This is actually a regression in Disco from Artful, Bionic and Cosmic,
where this was fixed in https://bugs.launchpad.net/bugs/1717951

Since the update to Disco the unprofessional and childish ImageMagick
icon is back. It was removed in Artful, Bionic and Cosmic for the
following reasons, perfectly summed up by Jeremy Bicha (a copy and paste
from Bug #171951):

Impact
==
I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.

It is visible in the Show Applications view of the Activities Overview
so this could impact screenshots.

Justification
=
imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.

Bundled with imagemagick is the "display" app, which is an app with an
unusual, difficult-to-use UI. It was not intentionally included in the
default Ubuntu install but was only there because it was packaged
together.

I am proposing splitting the display app to a separate binary package so
that it is available for install for the few who do want to use the app.

I tried proposing this to Debian. See comment #60 on the attached Debian
bug but the Debian maintainer doesn't seem interested in accepting my
proposal any time soon. (I emailed him directly a few months ago too.)

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

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

Title:
  Drop imagemagick-display from the default install  [disco regression]

Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  This is actually a regression in Disco from Artful, Bionic and Cosmic,
  where this was fixed in https://bugs.launchpad.net/bugs/1717951

  Since the update to Disco the unprofessional and childish ImageMagick
  icon is back. It was removed in Artful, Bionic and Cosmic for the
  following reasons, perfectly summed up by Jeremy Bicha (a copy and
  paste from Bug #171951):

  Impact
  ==
  I'm proposing to drop the ImageMagick app from the default Ubuntu 17.10.

  It is visible in the Show Applications view of the Activities Overview
  so this could impact screenshots.

  Justification
  =
  imagemagick is a collection of commandline utilities for working with images, 
photos, etc. It is a required dependency for many things and will still be 
installed by default.

  Bundled with imagemagick is the "display" app, which is an app with an
  unusual, difficult-to-use UI. It was not intentionally included in the
  default Ubuntu install but was only there because it was packaged
  together.

  I am proposing splitting the display app to a separate binary package
  so that it is available for install for the few who do want to use the
  app.

  I tried proposing this to Debian. See comment #60 on the attached
  Debian bug but the Debian maintainer doesn't seem interested in
  accepting my proposal any time soon. (I emailed him directly a few
  months ago too.)

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

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


[Touch-packages] [Bug 1777994] Re: the header xcb/xinput.h is missing

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package libxcb - 1.13-2~ubuntu18.04

---
libxcb (1.13-2~ubuntu18.04) bionic-proposed; urgency=medium

  [ Timo Aaltonen ]
  * Package libxcb-xinput0/libxcb-xinput-dev. (Closes: #733227) (LP: #1777994)

  [ Andreas Boll ]
  * control: Fix VCS urls.

 -- Jonathan Riddell   Thu, 21 Jun 2018 13:52:59 +0300

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

Title:
  the header xcb/xinput.h is missing

Status in libxcb package in Ubuntu:
  Fix Released
Status in libxcb source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  Allow Qt 5.12 to be compiled with full input support.  This allows 
applications to be built using complex input devices such as drawing pads.  
This is used in e.g Krita which KDE builds into a Snap package for 
distribution.  Currently Krita does not work with pen input devices with 
pressure sensitivity.

  [Test Case]
  Install Krita with Qt 5.12 from current Snap and note how pressure 
sensitivity does not work.

  [Regression Potential] 
  None that I can see, it's just packaging a few new header files.

  

  
  I suspect this means there should be another package, libxcb-xinput-dev 
perhaps?

  I already did sudo apt install "libxcb*dev" to get all related dev
  packages, but none of them provide xcb/xinput.h.

  The result is that when building Qt from source, it's necessary to use
  a copy of this file which Qt provides
  (qtbase/src/3rdparty/xcb/include/xcb/xinput.h), because it's missing
  from the system.  So if you don't give the option -qt-xcb to
  configure, then Qt will be built without multi-touch support.

  https://bugreports.qt.io/browse/QTBUG-69045

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: libxcb1-dev 1.13-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 21 08:32:12 2018
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA 
controller])
     Subsystem: Lenovo UHD Graphics 620 [17aa:3802]
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 0cf3:e300 Atheros Communications, Inc.
   Bus 001 Device 003: ID 06cb:0081 Synaptics, Inc.
   Bus 001 Device 002: ID 04f2:b5da Chicony Electronics Co., Ltd
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: LENOVO 80Y7
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-23-generic 
root=ZFS=rpool/ROOT/ubuntu ro
  SourcePackage: libxcb
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/22/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 5NCN38WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 31
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo YOGA 920-13IKB
  dmi.modalias: 
dmi:bvnLENOVO:bvr5NCN38WW:bd02/22/2018:svnLENOVO:pn80Y7:pvrLenovoYOGA920-13IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct31:cvrLenovoYOGA920-13IKB:
  dmi.product.family: YOGA 920-13IKB
  dmi.product.name: 80Y7
  dmi.product.version: Lenovo YOGA 920-13IKB
  dmi.sys.vendor: LENOVO
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.91-2
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.0~rc5-1ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.0~rc5-1ubuntu1
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2

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

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


[Touch-packages] [Bug 1777994] Update Released

2019-03-11 Thread Łukasz Zemczak
The verification of the Stable Release Update for libxcb 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 libxcb in Ubuntu.
https://bugs.launchpad.net/bugs/1777994

Title:
  the header xcb/xinput.h is missing

Status in libxcb package in Ubuntu:
  Fix Released
Status in libxcb source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  Allow Qt 5.12 to be compiled with full input support.  This allows 
applications to be built using complex input devices such as drawing pads.  
This is used in e.g Krita which KDE builds into a Snap package for 
distribution.  Currently Krita does not work with pen input devices with 
pressure sensitivity.

  [Test Case]
  Install Krita with Qt 5.12 from current Snap and note how pressure 
sensitivity does not work.

  [Regression Potential] 
  None that I can see, it's just packaging a few new header files.

  

  
  I suspect this means there should be another package, libxcb-xinput-dev 
perhaps?

  I already did sudo apt install "libxcb*dev" to get all related dev
  packages, but none of them provide xcb/xinput.h.

  The result is that when building Qt from source, it's necessary to use
  a copy of this file which Qt provides
  (qtbase/src/3rdparty/xcb/include/xcb/xinput.h), because it's missing
  from the system.  So if you don't give the option -qt-xcb to
  configure, then Qt will be built without multi-touch support.

  https://bugreports.qt.io/browse/QTBUG-69045

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: libxcb1-dev 1.13-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 21 08:32:12 2018
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA 
controller])
     Subsystem: Lenovo UHD Graphics 620 [17aa:3802]
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 0cf3:e300 Atheros Communications, Inc.
   Bus 001 Device 003: ID 06cb:0081 Synaptics, Inc.
   Bus 001 Device 002: ID 04f2:b5da Chicony Electronics Co., Ltd
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: LENOVO 80Y7
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-23-generic 
root=ZFS=rpool/ROOT/ubuntu ro
  SourcePackage: libxcb
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/22/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 5NCN38WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 31
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo YOGA 920-13IKB
  dmi.modalias: 
dmi:bvnLENOVO:bvr5NCN38WW:bd02/22/2018:svnLENOVO:pn80Y7:pvrLenovoYOGA920-13IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct31:cvrLenovoYOGA920-13IKB:
  dmi.product.family: YOGA 920-13IKB
  dmi.product.name: 80Y7
  dmi.product.version: Lenovo YOGA 920-13IKB
  dmi.sys.vendor: LENOVO
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.91-2
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.0~rc5-1ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.0~rc5-1ubuntu1
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2

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

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


[Touch-packages] [Bug 1817903] Re: systemd-resolve appends "options edns0" to resolv.conf

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package resolvconf - 1.79ubuntu10.18.04.1

---
resolvconf (1.79ubuntu10.18.04.1) bionic; urgency=medium

  * Pull systemd-resolved conf from non-stub file; the stub file should
not be used unless all dns traffic goes to the local stub resolver.
Specifically, now that stub-resolv.conf includes edns0 option,
using the stub conf with non-local dns servers can break dns
resolution. (LP: #1817903)

 -- Dan Streetman   Wed, 27 Feb 2019 17:03:57
-0500

** Changed in: resolvconf (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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1817903

Title:
  systemd-resolve appends "options edns0" to resolv.conf

Status in resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

Bug description:
  [impact]

  systems upgraded from pre-Bionic releases to Bionic or later will
  continue to use ifupdown/resolvconf for network conf and management,
  but resolvconf has a new systemd service in Bionic and later that
  pulls systemd-resolved stub-resolv.conf into its local configuration.
  With the recent addition of edns0 option to the stub resolver conf in
  systemd to fix bug 1811471, this means resolvconf now sets up the
  /etc/resolv.conf file to include upstream servers but also use edns.
  For any systems where the upstream resolver(s) don't support edns, dns
  lookups will break.

  [test case]

  == upgrade from pre-bionic (e.g. xenial) to bionic or later ==

  1) create a xenial system with ifupdown/resolvconf.  The ifupdown
  config needs to include an upstream name server (must be static).  At
  this point, once the network is configured and up, the resolvconf
  should have put the upstream name server(s) and search domain into the
  /etc/resolv.conf.  As is usual for pre-systemd releases, there should
  be no local dns resolver in /etc/resolv.conf (i.e. 127.0.0.53 should
  not be included) at this point.

  2) upgrade the system to bionic (alternately it should be possible to install 
bionic, then remove netplan and install/configure ifupdown and resolvconf, but 
I have not specifically tested this).  The upgrade will retain the 
ifupdown/resolvconf configuration, and will not change to 
netplan/systemd-networkd.  After upgrade is finished, the /etc/resolv.conf will 
contain:
    a) the upstream name server(s)
    b) options edns0
    c) the local stub resolver (127.0.0.53)
    d) search domain

  the fixed resolvconf will remove (b) and (c), and restore
  /etc/resolv.conf to what it contained in Xenial release, before the
  upgrade to Bionic.

  As mentioned, this case also should cover the situation of a native
  Bionic install, where netplan is removed and ifupdown/resolvconf is
  manually installed.

  == bionic or later install ==

  with a bionic install, ifupdown is not installed, instead netplan
  /systemd-networkd handle networking.  In this case, systemd-networkd
  manages the /etc/resolv.conf, and symlinks it to networkd's stub-
  resolv.conf which always contains only the local stub resolver
  (127.0.0.53) and (recently) options edns0, and local search domain.

  If resolvconf is installed while systemd-networkd is managing the
  network, then currently the resolv.conf contents will remain
  completely unchanged, still pointing to the local stub resolver.

  This resolvconf change will alter that, to revert the /etc/resolv.conf
  to Xenial's contents; specifically, the upstream name server(s) and
  search domain.  It will no longer include the local stub resolver nor
  edns0.

  [regression potential]

  Regressions due to this change would likely be seen in dns query
  failures with other system configurations.

  Additionally, for the case where systemd-networkd is actually managing
  the network, this change will stop sending dns traffic to the local
  stub resolver, and instead send it to the upstream name server(s).
  This will increase outgoing dns traffic (since it's no longer cached
  locally), but will matches the behavior from Xenial.  Additionally,
  resolvconf should not be needed when systemd-networkd is managing the
  network (and thus systemd-resolved is managing dns), and resolvconf
  can simply be uninstalled from the system to move back to normal use
  of the local 

[Touch-packages] [Bug 1788998] Re: Vertical GtkBox.linked > GtkEntry not supported

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

** Changed in: ubuntu-themes (Ubuntu)
   Status: New => Confirmed

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

Title:
  Vertical GtkBox.linked > GtkEntry not supported

Status in ubuntu-themes package in Ubuntu:
  Confirmed

Bug description:
  If a vertical GtkBox with .linked style-class contains GtkEntry
  widgets, their borders don't match.

  See attached screenshots.

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

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


[Touch-packages] [Bug 1787729] Re: apport-autoreport.service fails if whoopsie isn't running

2019-03-11 Thread Brian Murray
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic

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

Title:
  apport-autoreport.service fails if whoopsie isn't running

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Bionic:
  Fix Committed
Status in apport source package in Cosmic:
  Fix Released

Bug description:
  Impact
  --
  If automatic crash reporting is enabled and apport-autoreport.service starts 
before whoopsie on boot then crash reports that happened during shutdown or 
start up will not be automatically uploaded to the error tracker.

  Test Case
  -
  1) install apport-noui
  2) sudo service apport stop
  3) modify /usr/share/apport/whoopsie-upload-all to exit(1) thereby recreating 
the situation where whoopsie isn't running. I did this by copying lines 159,160 
to 161,162 and unindenting them. N.B. this isn't necessary if you are on a 
system where whoopsie is starting after apport.
  4) touch /var/crash/my.crash
  5) reboot
  5) run 'systemctl status apport-autoreport.service' and observe it failed 
because whoopsie isn't running

  When testing the proposed version of apport you'll want to revert the
  changes you made to whoopsie-upload-all. With the version of apport
  from -proposed you should no longer see the failure message for the
  apport-autoreport.service. The best test case is just having an
  affected system test the package from -proposed though.

  Regression Potential
  
  We are clearly fixing something that was a mistake in the original service so 
there is little chance for regression.

  

  ProblemType: BugDistroRelease: Ubuntu 18.10
  Package: apport 2.20.10-0ubuntu7
  Uname: Linux 4.18.3-041803-generic x86_64
  ApportLog:

  ApportVersion: 2.20.10-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Aug 18 11:48:00 2018
  InstallationDate: Installed on 2017-10-13 (308 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170926)
  PackageArchitecture: allSourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


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

2019-03-11 Thread dwmw2
@seb128 please see "In 16.04 the NetworkManager package used to carry
this patch..." in the bug description above.

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

Title:
  Full-tunnel VPN DNS leakage regression

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

Bug description:
  * Impact

  When using a VPN the DNS requests might still be sent to a DNS server
  outside the VPN when they should not

  * Test case

  Configure the system to send all the traffic to a VPN, do a name
  resolution, the request should not go to the public DNS server (to be
  checked by capturing the traffic by example with wireshark)

  
  * Regression potential

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

  -

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

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

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

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

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

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


[Touch-packages] [Bug 1815236] Re: totem assert failure: totem: src/intel/genxml/gen9_pack.h:72: __gen_uint: La declaración `v <= max' no se cumple.

2019-03-11 Thread El jinete sin cabeza
I am looking for if the patch was included before the release of mesa
"19.0.0-rc7"

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

Title:
  totem assert failure: totem: src/intel/genxml/gen9_pack.h:72:
  __gen_uint: La declaración `v <= max' no se cumple.

Status in Mesa:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Committed
Status in totem package in Ubuntu:
  Invalid

Bug description:
  https://gitlab.gnome.org/GNOME/totem/issues/297 (Not GNOME)

  ---

  I'm not sure, but this happened after updating to gstreamer 1.15.1, I
  have problems when I maximize totem.

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: totem 3.30.0-4ubuntu1
  Uname: Linux 4.20.7-042007-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  AssertionMessage: totem: src/intel/genxml/gen9_pack.h:72: __gen_uint: La 
declaración `v <= max' no se cumple.
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb  7 18:40:29 2019
  ExecutablePath: /usr/bin/totem
  InstallationDate: Installed on 2018-12-02 (68 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcCmdline: /usr/bin/totem --gapplication-service
  Signal: 6
  SourcePackage: totem
  StacktraceTop:
   __assert_fail_base (fmt=0x7ff31939be23 , assertion=0x7ff312a5416c "v <= max", 
file=0x7ff312a5644c "src/intel/genxml/gen9_pack.h", line=72, 
function=) at assert.c:92
   __GI___assert_fail (assertion=0x7ff312a5416c "v <= max", file=0x7ff312a5644c 
"src/intel/genxml/gen9_pack.h", line=72, function=0x7ff312a56938 "__gen_uint") 
at assert.c:101
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
  Title: totem assert failure: totem: src/intel/genxml/gen9_pack.h:72: 
__gen_uint: La declaración `v <= max' no se cumple.
  UpgradeStatus: Upgraded to disco on 2018-12-02 (67 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

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

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


[Touch-packages] [Bug 1815236] Re: totem assert failure: totem: src/intel/genxml/gen9_pack.h:72: __gen_uint: La declaración `v <= max' no se cumple.

2019-03-11 Thread El jinete sin cabeza
They could pass to [1]mesa_19.0.0~rc7
[1] 
https://metadata.ftp-master.debian.org/changelogs/main/m/mesa/mesa_19.0.0~rc7-1_changelog

https://bugs.freedesktop.org/show_bug.cgi?id=109535
The error is corrected in master.

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

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

Title:
  totem assert failure: totem: src/intel/genxml/gen9_pack.h:72:
  __gen_uint: La declaración `v <= max' no se cumple.

Status in Mesa:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Committed
Status in totem package in Ubuntu:
  Invalid

Bug description:
  https://gitlab.gnome.org/GNOME/totem/issues/297 (Not GNOME)

  ---

  I'm not sure, but this happened after updating to gstreamer 1.15.1, I
  have problems when I maximize totem.

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: totem 3.30.0-4ubuntu1
  Uname: Linux 4.20.7-042007-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  AssertionMessage: totem: src/intel/genxml/gen9_pack.h:72: __gen_uint: La 
declaración `v <= max' no se cumple.
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb  7 18:40:29 2019
  ExecutablePath: /usr/bin/totem
  InstallationDate: Installed on 2018-12-02 (68 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcCmdline: /usr/bin/totem --gapplication-service
  Signal: 6
  SourcePackage: totem
  StacktraceTop:
   __assert_fail_base (fmt=0x7ff31939be23 , assertion=0x7ff312a5416c "v <= max", 
file=0x7ff312a5644c "src/intel/genxml/gen9_pack.h", line=72, 
function=) at assert.c:92
   __GI___assert_fail (assertion=0x7ff312a5416c "v <= max", file=0x7ff312a5644c 
"src/intel/genxml/gen9_pack.h", line=72, function=0x7ff312a56938 "__gen_uint") 
at assert.c:101
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
  Title: totem assert failure: totem: src/intel/genxml/gen9_pack.h:72: 
__gen_uint: La declaración `v <= max' no se cumple.
  UpgradeStatus: Upgraded to disco on 2018-12-02 (67 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

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

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


[Touch-packages] [Bug 1819052] Re: tar makes full backup not incremental when not using "z"

2019-03-11 Thread Sebastien Bacher
Thank you for your bug report, that might be best reported upstream on
https://lists.gnu.org/mailman/listinfo/bug-tar

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

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

Title:
  tar makes full backup not incremental when not using "z"

Status in tar package in Ubuntu:
  New

Bug description:
  Using tar with: tar -czpf ... -g ...  the incremtal function works right.
  Using tar with: tar -cpf ... -g ...  the incremtal function dont work.
  Without compressing tar always produce a full backup archive.

  tar-version:  GNU tar 1.29 on Ubuntu Bionic Beaver 18.04.2

  Making achives over network using Samba cifs

  /etc/fstab:
  //192.168.178.165/x/home/asterix/carola  cifs 
auto,rw,users,username=asterix,password=leo,uid=asterix,gid=asterix  0 0

  Now i am using the compression, but thereby the backuptime is much
  longer.

  Thank you for Ubuntu/Linux :-)

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

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


[Touch-packages] [Bug 1815236] Re: totem assert failure: totem: src/intel/genxml/gen9_pack.h:72: __gen_uint: La declaración `v <= max' no se cumple.

2019-03-11 Thread Sebastien Bacher
** Changed in: mesa (Ubuntu)
   Importance: Undecided => High

** Changed in: mesa (Ubuntu)
 Assignee: (unassigned) => Timo Aaltonen (tjaalton)

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

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

Title:
  totem assert failure: totem: src/intel/genxml/gen9_pack.h:72:
  __gen_uint: La declaración `v <= max' no se cumple.

Status in Mesa:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Committed
Status in totem package in Ubuntu:
  Invalid

Bug description:
  https://gitlab.gnome.org/GNOME/totem/issues/297 (Not GNOME)

  ---

  I'm not sure, but this happened after updating to gstreamer 1.15.1, I
  have problems when I maximize totem.

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: totem 3.30.0-4ubuntu1
  Uname: Linux 4.20.7-042007-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  AssertionMessage: totem: src/intel/genxml/gen9_pack.h:72: __gen_uint: La 
declaración `v <= max' no se cumple.
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb  7 18:40:29 2019
  ExecutablePath: /usr/bin/totem
  InstallationDate: Installed on 2018-12-02 (68 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcCmdline: /usr/bin/totem --gapplication-service
  Signal: 6
  SourcePackage: totem
  StacktraceTop:
   __assert_fail_base (fmt=0x7ff31939be23 , assertion=0x7ff312a5416c "v <= max", 
file=0x7ff312a5644c "src/intel/genxml/gen9_pack.h", line=72, 
function=) at assert.c:92
   __GI___assert_fail (assertion=0x7ff312a5416c "v <= max", file=0x7ff312a5644c 
"src/intel/genxml/gen9_pack.h", line=72, function=0x7ff312a56938 "__gen_uint") 
at assert.c:101
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
   ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
  Title: totem assert failure: totem: src/intel/genxml/gen9_pack.h:72: 
__gen_uint: La declaración `v <= max' no se cumple.
  UpgradeStatus: Upgraded to disco on 2018-12-02 (67 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

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

-- 
Mailing list: https://launchpad.net/~touch-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-03-11 Thread Bug Watch Updater
Launchpad has imported 6 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1669751.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.


On 2019-01-26T17:38:46+00:00 nkshirsa wrote:

Description of problem:

lvm should not allow extending an LV with a PV of different sector size
than existing PVs making up the LV, since the FS on the LV does not
mount once LVM adds in the new PV and extends the LV.


How reproducible:
Steps to Reproduce:

** Device: sdc (using the device with default sector size of 512)

# blockdev --report /dev/sdc
RORA   SSZ   BSZ   StartSecSize   Device
rw  8192   512  4096  0  1073741824   /dev/sdc

** LVM is created with the default sector size of 512.

# blockdev --report /dev/mapper/testvg-testlv 
RORA   SSZ   BSZ   StartSecSize   Device
rw  8192   512  4096  0  1069547520   /dev/mapper/testvg-testlv

** The filesystem will also pick up 512 sector size.

# mkfs.xfs /dev/mapper/testvg-testlv 
meta-data=/dev/mapper/testvg-testlv isize=512agcount=4, agsize=65280 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=0, sparse=0
data =   bsize=4096   blocks=261120, imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal log   bsize=4096   blocks=855, version=2
 =   sectsz=512   sunit=0 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0

** Now we will mount it

# xfs_info /test
meta-data=/dev/mapper/testvg-testlv isize=512agcount=4, agsize=65280 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=0 spinodes=0
data =   bsize=4096   blocks=261120, imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=855, version=2
 =   sectsz=512   sunit=0 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0

** Let's extend it with a PV with a sector size of 4096:

#modprobe scsi_debug sector_size=4096 dev_size_mb=512

# fdisk -l /dev/sdd
 
Disk /dev/sdd: 536 MB, 536870912 bytes, 131072 sectors
Units = sectors of 1 * 4096 = 4096 bytes <==
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 262144 bytes
 
# blockdev --report /dev/sdd
RORA   SSZ   BSZ   StartSecSize   Device
rw  8192  4096  4096  0   536870912   /dev/sdd

# vgextend testvg /dev/sdd
  Physical volume "/dev/sdd" successfully created
  Volume group "testvg" successfully extended

# lvextend -l +100%FREE /dev/mapper/testvg-testlv
  Size of logical volume testvg/testlv changed from 1020.00 MiB (255 extents) 
to 1.49 GiB (382 extents).
  Logical volume testlv successfully resized.

# umount /test

# mount /dev/mapper/testvg-testlv /test
mount: mount /dev/mapper/testvg-testlv on /test failed: Function not 
implemented <===

# dmesg | grep -i dm-2

[  477.517515] XFS (dm-2): Unmounting Filesystem
[  486.905933] XFS (dm-2): device supports 4096 byte sectors (not 512) 
<

The sector size of the lv is now 4096.
# blockdev --report /dev/mapper/testvg-testlv 
RORA   SSZ   BSZ   StartSecSize   Device
rw  8192  4096  4096  0  1602224128   /dev/mapper/testvg-testlv


Expected results:
LVM should fail the lvextend if sector size is different to existing PV's


Additional info:
Discussed with Zdenek during LVM meeting in Brno

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1817097/comments/0


On 2019-01-28T15:53:23+00:00 teigland wrote:

Should we just require all PVs in the VG to have the same sector size?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1817097/comments/1


On 2019-01-28T16:46:28+00:00 zkabelac wrote:

Basically that's what we have agreed in meeting - since we don't know
yet how to handle different sector-sized PVs.

And a short fix could be to not allow that to happen on creating time.

But still there are already users having that  VGs already created - so lvm2 
can't just say such VG is invalid
and disable access to it...

So I'd probably see something similar we did for 'mirrorlog' -
add lvm.conf option to disable creation - that is respected on vgcreate 

[Touch-packages] [Bug 1816415] Re: gjs-console crashed with SIGSEGV in g_socket_receive_message_with_timeout()

2019-03-11 Thread Andrea Azzarone
Fixed in gobject-introspection (1.60.0-1).

** Changed in: glib2.0 (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  gjs-console crashed with SIGSEGV in
  g_socket_receive_message_with_timeout()

Status in glib2.0 package in Ubuntu:
  Fix Released

Bug description:
  https://errors.ubuntu.com/problem/434b8b4abd971c7f84ca824ef5878a00d547753a
  https://gitlab.gnome.org/GNOME/gjs/issues/227

  ---

  I have performance problems, after updating.

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: gjs 1.54.3-1build1
  Uname: Linux 5.0.0-05rc6-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 18 07:39:11 2019
  ExecutablePath: /usr/bin/gjs-console
  InstallationDate: Installed on 2018-12-02 (77 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcCmdline: gjs 
/home/username/.local/share/gnome-shell/extensions/gsconn...@andyholmes.github.io/service/daemon.js
  SegvAnalysis:
   Segfault happened at: 0x7f224b1fafd8:mov(%r15),%edx
   PC (0x7f224b1fafd8) ok
   source "(%r15)" (0xfff98002) not located in a known VMA region 
(needed readable region)!
   destination "%edx" ok
  SegvReason: reading unknown VMA
  Signal: 11
  SourcePackage: gjs
  StacktraceTop:
   ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
   g_socket_receive_message () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
   ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
   ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
   ?? () from /usr/lib/libgjs.so.0
  Title: gjs-console crashed with SIGSEGV in g_socket_receive_message()
  UpgradeStatus: Upgraded to disco on 2018-12-02 (77 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  separator:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1816415/+subscriptions

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


[Touch-packages] [Bug 1817903] Re: systemd-resolve appends "options edns0" to resolv.conf

2019-03-11 Thread Launchpad Bug Tracker
This bug was fixed in the package resolvconf - 1.79ubuntu10.18.10.1

---
resolvconf (1.79ubuntu10.18.10.1) cosmic; urgency=medium

  * Pull systemd-resolved conf from non-stub file; the stub file should
not be used unless all dns traffic goes to the local stub resolver.
Specifically, now that stub-resolv.conf includes edns0 option,
using the stub conf with non-local dns servers can break dns
resolution. (LP: #1817903)

 -- Dan Streetman   Wed, 27 Feb 2019 17:01:03
-0500

** Changed in: resolvconf (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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1817903

Title:
  systemd-resolve appends "options edns0" to resolv.conf

Status in resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

Bug description:
  [impact]

  systems upgraded from pre-Bionic releases to Bionic or later will
  continue to use ifupdown/resolvconf for network conf and management,
  but resolvconf has a new systemd service in Bionic and later that
  pulls systemd-resolved stub-resolv.conf into its local configuration.
  With the recent addition of edns0 option to the stub resolver conf in
  systemd to fix bug 1811471, this means resolvconf now sets up the
  /etc/resolv.conf file to include upstream servers but also use edns.
  For any systems where the upstream resolver(s) don't support edns, dns
  lookups will break.

  [test case]

  == upgrade from pre-bionic (e.g. xenial) to bionic or later ==

  1) create a xenial system with ifupdown/resolvconf.  The ifupdown
  config needs to include an upstream name server (must be static).  At
  this point, once the network is configured and up, the resolvconf
  should have put the upstream name server(s) and search domain into the
  /etc/resolv.conf.  As is usual for pre-systemd releases, there should
  be no local dns resolver in /etc/resolv.conf (i.e. 127.0.0.53 should
  not be included) at this point.

  2) upgrade the system to bionic (alternately it should be possible to install 
bionic, then remove netplan and install/configure ifupdown and resolvconf, but 
I have not specifically tested this).  The upgrade will retain the 
ifupdown/resolvconf configuration, and will not change to 
netplan/systemd-networkd.  After upgrade is finished, the /etc/resolv.conf will 
contain:
    a) the upstream name server(s)
    b) options edns0
    c) the local stub resolver (127.0.0.53)
    d) search domain

  the fixed resolvconf will remove (b) and (c), and restore
  /etc/resolv.conf to what it contained in Xenial release, before the
  upgrade to Bionic.

  As mentioned, this case also should cover the situation of a native
  Bionic install, where netplan is removed and ifupdown/resolvconf is
  manually installed.

  == bionic or later install ==

  with a bionic install, ifupdown is not installed, instead netplan
  /systemd-networkd handle networking.  In this case, systemd-networkd
  manages the /etc/resolv.conf, and symlinks it to networkd's stub-
  resolv.conf which always contains only the local stub resolver
  (127.0.0.53) and (recently) options edns0, and local search domain.

  If resolvconf is installed while systemd-networkd is managing the
  network, then currently the resolv.conf contents will remain
  completely unchanged, still pointing to the local stub resolver.

  This resolvconf change will alter that, to revert the /etc/resolv.conf
  to Xenial's contents; specifically, the upstream name server(s) and
  search domain.  It will no longer include the local stub resolver nor
  edns0.

  [regression potential]

  Regressions due to this change would likely be seen in dns query
  failures with other system configurations.

  Additionally, for the case where systemd-networkd is actually managing
  the network, this change will stop sending dns traffic to the local
  stub resolver, and instead send it to the upstream name server(s).
  This will increase outgoing dns traffic (since it's no longer cached
  locally), but will matches the behavior from Xenial.  Additionally,
  resolvconf should not be needed when systemd-networkd is managing the
  network (and thus systemd-resolved is managing dns), and resolvconf
  can simply be uninstalled from the system to move back to normal use
  of the local 

[Touch-packages] [Bug 1817903] Update Released

2019-03-11 Thread Łukasz Zemczak
The verification of the Stable Release Update for resolvconf 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1817903

Title:
  systemd-resolve appends "options edns0" to resolv.conf

Status in resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

Bug description:
  [impact]

  systems upgraded from pre-Bionic releases to Bionic or later will
  continue to use ifupdown/resolvconf for network conf and management,
  but resolvconf has a new systemd service in Bionic and later that
  pulls systemd-resolved stub-resolv.conf into its local configuration.
  With the recent addition of edns0 option to the stub resolver conf in
  systemd to fix bug 1811471, this means resolvconf now sets up the
  /etc/resolv.conf file to include upstream servers but also use edns.
  For any systems where the upstream resolver(s) don't support edns, dns
  lookups will break.

  [test case]

  == upgrade from pre-bionic (e.g. xenial) to bionic or later ==

  1) create a xenial system with ifupdown/resolvconf.  The ifupdown
  config needs to include an upstream name server (must be static).  At
  this point, once the network is configured and up, the resolvconf
  should have put the upstream name server(s) and search domain into the
  /etc/resolv.conf.  As is usual for pre-systemd releases, there should
  be no local dns resolver in /etc/resolv.conf (i.e. 127.0.0.53 should
  not be included) at this point.

  2) upgrade the system to bionic (alternately it should be possible to install 
bionic, then remove netplan and install/configure ifupdown and resolvconf, but 
I have not specifically tested this).  The upgrade will retain the 
ifupdown/resolvconf configuration, and will not change to 
netplan/systemd-networkd.  After upgrade is finished, the /etc/resolv.conf will 
contain:
    a) the upstream name server(s)
    b) options edns0
    c) the local stub resolver (127.0.0.53)
    d) search domain

  the fixed resolvconf will remove (b) and (c), and restore
  /etc/resolv.conf to what it contained in Xenial release, before the
  upgrade to Bionic.

  As mentioned, this case also should cover the situation of a native
  Bionic install, where netplan is removed and ifupdown/resolvconf is
  manually installed.

  == bionic or later install ==

  with a bionic install, ifupdown is not installed, instead netplan
  /systemd-networkd handle networking.  In this case, systemd-networkd
  manages the /etc/resolv.conf, and symlinks it to networkd's stub-
  resolv.conf which always contains only the local stub resolver
  (127.0.0.53) and (recently) options edns0, and local search domain.

  If resolvconf is installed while systemd-networkd is managing the
  network, then currently the resolv.conf contents will remain
  completely unchanged, still pointing to the local stub resolver.

  This resolvconf change will alter that, to revert the /etc/resolv.conf
  to Xenial's contents; specifically, the upstream name server(s) and
  search domain.  It will no longer include the local stub resolver nor
  edns0.

  [regression potential]

  Regressions due to this change would likely be seen in dns query
  failures with other system configurations.

  Additionally, for the case where systemd-networkd is actually managing
  the network, this change will stop sending dns traffic to the local
  stub resolver, and instead send it to the upstream name server(s).
  This will increase outgoing dns traffic (since it's no longer cached
  locally), but will matches the behavior from Xenial.  Additionally,
  resolvconf should not be needed when systemd-networkd is managing the
  network (and thus systemd-resolved is managing dns), and resolvconf
  can simply be uninstalled from the system to move back to normal use
  of the local stub resolver.

  [other info]

  This affects only Bionic and later; in Xenial and earlier, resolvconf
  does not include 

[Touch-packages] [Bug 1809856] Re: [XPS 13 9370, Realtek ALC3271, Headphone Out, Right] Static/Electric background noise when volume is not muted

2019-03-11 Thread Kai-Heng Feng
Please see if this kernel helps:
https://people.canonical.com/~khfeng/lp1809856/

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

Title:
  [XPS 13 9370, Realtek ALC3271, Headphone Out, Right] Static/Electric
  background noise when volume is not muted

Status in alsa-driver package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Whenever I plug in my Sennheiser HD1 Wired headphones with mic, I start 
hearing a static/electric (some internal?) sound if the volume isn't muted. 
Something similar occurs with my other earbuds with mic, just much quieter and 
less noticable. It works fine on Windows 10 running on the same machine, and on 
my Android phone. I don't notice is when something is playing, but the 
frequency of the sound changes when I play something, then pause it, the 
background noise will sound slightly different.
  This is from an installed Ubuntu 18.10. I have tried booting 18.10 Live USB 
and 18.04.1 LTS Live USB, and the issue still occurs. I have tried playing with 
alsamixer and pavucontrol settings, and nothing fixed this background noise.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  davidkoplik   1891 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Dec 26 20:17:59 2018
  InstallationDate: Installed on 2018-12-26 (0 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Black Headphone Out, Right
  Symptom_PulsePlaybackTest: PulseAudio playback test successful
  Symptom_Type: High background noise, or volume is too low
  Title: [XPS 13 9370, Realtek ALC3271, Black Headphone Out, Right] Background 
noise or low volume
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/04/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.6.3
  dmi.board.name: 0F6P3V
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.6.3:bd11/04/2018:svnDellInc.:pnXPS139370:pvr:rvnDellInc.:rn0F6P3V:rvrA00:cvnDellInc.:ct10:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9370
  dmi.product.sku: 07E6
  dmi.sys.vendor: Dell Inc.

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

-- 
Mailing list: https://launchpad.net/~touch-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-03-11 Thread Dimitri John Ledkov
/etc/mke2fs.conf:
[defaults]
blocksize = 4096
[fs_types]
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}

We default to 4k, unless one is formatting small filesystems which from manpage:
If the filesystem size is greater than or equal to 3 but less than 512 
megabytes, mke2fs(8) will use the  filesystem  type  small.

And in your tests you do appear to use 500MiB big images.

I wonder if we should bump even small ext4 filesystems to use 4k sector
sizes.

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

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

Status in lvm2:
  Unknown
Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  Invalid
Status in lvm2 package in Ubuntu:
  Incomplete

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
  

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

2019-03-11 Thread Dimitri John Ledkov
This is a well-known upstream issue/bug.
This is not s390x, Ubuntu 18.10, any other Ubuntu release specific.
There is no dataloss -> one can execute pvmove operation in reverse (or i guess 
onto any 512 sector size PV) to mount the filesystems again.

Thus this is not critical at all.

Also, I am failing to understand what is the expectation for Canonical
to do, w.r.t. this bug report?

If you want support, as a workaround one can force using 4k sizes, with
vgcreate and ext4, then moving volumes to/from 512/4k physical volumes
appears to work seamlessly:

$ sudo vgcreate --physicalextentsize 4k newtestvg /dev/...
$ sudo mkfs.ext4 -b 4096 /dev/mapper/...

For a more general solution, do create stand-alone new VGs/LVs/FSs, and
migrate data over using higther level tools - e.g. dump/restore, rsync,
etc.

But note, that launchpad should not be used for support requests. Please
use your UA account (salesforce) for support request for your production
systems.

This is discussed upstream, where they are trying to introduce a soft
check to prevent from moving data across.
https://bugzilla.redhat.com/show_bug.cgi?id=1669751 But it's not a real
solution, just a weak safety check. As one can still force create ext4fs
of either 512 or 4k, and move the volume to the "wrong" size. As ideally
it would be user friendly if moving to/from mixed sector sizes would
just work(tm) but that's unlikely to happen upstream, thus is wont-fix
downstream too.

Was there anything in particular that you were expecting for us to
change?

We could change the cloud-images (if they don't already), installers
(i.e. d-i / subiquity) or the utils (i.e. vgcreate, mkfs.ext4) to
default to 4k minimum sector sizes. But at the moment, these utils try
to guess the sector sizes based on heuristics at creation time, and
obviously get is "wrong" if the underlying device is swapped away from
under their feet post creation time. Thus this is expected.

References:
The upstream bug report is https://bugzilla.redhat.com/show_bug.cgi?id=1669751
The upstream overridable weak safety-net check is 
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=dd6ff9e3a75801fc5c6166aa0983fa8df098e91a
And that will make it into ubuntu eventually, when released in a stable lvm2 
release and integration into ubuntu.

Please remove severity critical
Please remove target ubuntu 18.10
Please provide explanation as to why this issue was filed


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

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

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

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

** Also affects: lvm2 via
   https://bugzilla.redhat.com/show_bug.cgi?id=1669751
   Importance: Unknown
   Status: Unknown

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

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

Status in lvm2:
  Unknown
Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  Invalid
Status in lvm2 package in Ubuntu:
  Incomplete

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 

[Touch-packages] [Bug 1818395] Re: Please demote lightdm greeter recommends to suggests

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

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

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

Title:
  Please demote lightdm greeter recommends to suggests

Status in lightdm package in Ubuntu:
  Confirmed

Bug description:
  Please see https://bugs.launchpad.net/ubuntu/+source/indicator-
  datetime/+bug/1754872/comments/25 for some background on this bug
  report.

  I'd like to request that the lightdm greeter Recommends...
  unity-greeter | lightdm-greeter (virtual package) | lightdm-kde-greeter

  be moved to Suggests. It seems the apt installation order causes
  unity-greeter (and other unity components) to be installed along with
  lightdm-gtk-greeter when installing the xubuntu-desktop task.

  Since each of the lightdm greeters should depend on lightdm, I think
  this change helps make greeter installation more explicit and should
  prevent the installation of multiple greeters when only one is needed
  or requested.

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

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


[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures

2019-03-11 Thread Manoj Iyer
** Changed in: perl (Ubuntu)
 Assignee: (unassigned) => Canonical Foundations Team 
(canonical-foundations)

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

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Confirmed
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

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


[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures

2019-03-11 Thread Frank Heimes
** Changed in: ubuntu-power-systems
   Status: Incomplete => Confirmed

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

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

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Confirmed
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

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


[Touch-packages] [Bug 1450588] Re: /var/log/dmesg No Longer Being Updated

2019-03-11 Thread Christian Ehrhardt 
Per former discussion, better safe than sorry - added a FFe request to
the description and subscribed the release-team.

** Description changed:

+ [FFe]
+  * (re-)introduce a feature to ensure the initial (boot time) kernel 
+messages are preserved
+  * This existed up to Trusty (upstart) but was lost afterwards as it had 
+no systemd coutnerpart.
+  * It is a "new" feature since we have lacked it for so many releases and 
+worth - a hopefully simple - ack by the release Team
+ 
+  * It is not a new version or any change to the actual rsyslog code.
+Instead it just adds a new service "dmesg" that will achieve what was 
+lost post trusty. Therefore the potential regression to the existing 
+function should be minimal, if anything the new service might hit 
+issues on some unexpected environments but atm that seems unlikely.
+ 
+  * It does not add/remove Dependencies nor modify build
+ 
+  * I ahve made upgrade/install tests as well as Ahasenack doing the same 
+on the MP that is linked.
+ 
+ 
+ ---
+ 
  After upgrading to Ubuntu 15.04 Vivid, /var/log/dmesg is no longer
  updated after boot.
  
  It appears that this was previously done via /etc/init/dmesg.conf

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

** Summary changed:

- /var/log/dmesg No Longer Being Updated
+ [FFe] /var/log/dmesg No Longer Being Updated

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

Title:
  [FFe] /var/log/dmesg No Longer Being Updated

Status in rsyslog package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  [FFe]
   * (re-)introduce a feature to ensure the initial (boot time) kernel 
 messages are preserved
   * This existed up to Trusty (upstart) but was lost afterwards as it had 
 no systemd coutnerpart.
   * It is a "new" feature since we have lacked it for so many releases and 
 worth - a hopefully simple - ack by the release Team

   * It is not a new version or any change to the actual rsyslog code.
 Instead it just adds a new service "dmesg" that will achieve what was 
 lost post trusty. Therefore the potential regression to the existing 
 function should be minimal, if anything the new service might hit 
 issues on some unexpected environments but atm that seems unlikely.

   * It does not add/remove Dependencies nor modify build

   * I ahve made upgrade/install tests as well as Ahasenack doing the same 
 on the MP that is linked.

  
  ---

  After upgrading to Ubuntu 15.04 Vivid, /var/log/dmesg is no longer
  updated after boot.

  It appears that this was previously done via /etc/init/dmesg.conf

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

-- 
Mailing list: https://launchpad.net/~touch-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-03-11 Thread Dimitri John Ledkov
Ok, reproduced this on x86_64 with raw files which are in multiples of
4k.

This is not an architecture specific issue.

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

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

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

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 corruption 
does not cause a data loss.
  
   
  Userspace tool common name: pvmove 
   
  The userspace tool has the following bit modes: 64bit 

[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

2019-03-11 Thread Dan Streetman
note this is listed in pending-sru as being at 5 days aging, however it
was actually uploaded 9 days ago, then re-uploaded mid-last-week with
the patches for bug 1812760 removed; so the patches for this bug have
been in the systemd in -proposed for 9 days.

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

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Mounting manually a network share (NFS) and masking it breaks the state of 
other units (and their dependencies).
  Casper is masking a mounted NFS share, blocking the normal boot process as 
described in the original description, but the issue comes from systemd.

  [Test Case]

  - NFS mount point at /media
  root@iscsi-bionic:/home/ubuntu# mount | grep media
  10.230.56.72:/tmp/mnt on /media type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72)

  - Test mount point (/test) defined in /etc/fstab:
  root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test
  tmpfs /test tmpfs nosuid,nodev 0 0

  1. If media.mount is not masked, everything works fine:

  root@iscsi-bionic:/home/ubuntu# mount | grep test
  root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active
 Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days 
ago
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test

  2. If media.mount is masked, other mounts are failing:

  root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount
  Created symlink /etc/systemd/system/media.mount → /dev/null.
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)

  [Regression potential]

  Minimal. Originally, one failing mount point blocked the processing of
  the rest due to how the return codes were handled for every line in
  /proc/self/mountinfo. This patch removes this "dependency" and keeps
  the failure local to the affected mount point, allowing the rest to be
  processed normally.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10874
  Fixed upstream with commit: 
https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3

  [Original Description]

  
  netbooting the bionic live CD[1] over NFS goes straight to maintenance mode :

  [1] http://cdimage.ubuntu.com/daily-live/current/

  # casper.log
  Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 
pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' 
(uid=999 pid=569 comm="" label="unconfined")
  

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

2019-03-11 Thread bugproxy
--- Comment From ifran...@de.ibm.com 2019-03-11 08:22 EDT---
The message "Device size is not aligned to the requested sector size." is 
because the size of your loopback device is not a multiple of 4096 bytes. With 
--sector-size 4096, it's size must be a multiple of 4096 bytes, otherwise you 
would a half sector at the end of the device.

Besides the setup with cryptsetup and 4K sector size, you can also try to setup 
your loopback devices with different sector sizes (and omit dm-crypt/cryptsetup 
totally).
By default loopback devices use a physical block size of 512, however, you can 
create them with -b 4096 to get a loopback device with 4K physical block size. 
With that you should also be able to reproduce this.

BTW: Please also see the thread about this topic on the LVM Mailing list that I 
have started in parallel, and especially the following post from David Teigland:
https://www.redhat.com/archives/linux-lvm/2019-March/msg00018.html

There is also already a draft patch from David Teigland for this in a private 
branch of the LVM2 git repository: 
https://sourceware.org/git/?p=lvm2.git;a=commit;h=dd6ff9e3a75801fc5c6166aa0983fa8df098e91a
I hope that this fix will make it into the master branch at some point in time.

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

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

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

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 

[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures

2019-03-11 Thread Dimitri John Ledkov
bah, mbrtowc claims to fail, tested that with C too, that works too.
And I cannot understand how perl XS stuff works. But it is fairly recent that 
mbrtowc was started to be used.

See: 6de6aebdf89cb5abd8296cf686184e4b9461d11b

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

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Incomplete
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

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


[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures

2019-03-11 Thread Dimitri John Ledkov
Sample C usage of mblen() appears to be fine, so libc is probably fine.

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

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Incomplete
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

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


[Touch-packages] [Bug 1818953] Re: Perl core dumping core on UBUNTU 19.04 by executing perl script

2019-03-11 Thread Dimitri John Ledkov
On an amd64 machine, I do get a core dump:

xnox@ottawa:~$ lscpu 
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   39 bits physical, 48 bits virtual
CPU(s):  8
On-line CPU(s) list: 0-7
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):   1
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   94
Model name:  Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
Stepping:3
CPU MHz: 800.003
CPU max MHz: 3500.
CPU min MHz: 800.
BogoMIPS:5184.00
Virtualization:  VT-x
L1d cache:   32K
L1i cache:   32K
L2 cache:256K
L3 cache:6144K
NUMA node0 CPU(s):   0-7
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 
monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 
x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 
3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp 
tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 
smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt 
xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window 
hwp_epp flush_l1d
xnox@ottawa:~$ cat test.pl 
#!//usr/bin/perl

use POSIX qw(mblen);

my $str = "data";

print "Calling mblen with str=$str\n";
my $len = mblen($str, MB_CUR_MAX);
print "mblen returned with len=$len\n";
 
xnox@ottawa:~$ ./test.pl 
Calling mblen with str=data
perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
Aborted (core dumped)


** Summary changed:

- Perl core dumping core on UBUNTU 19.04 by executing perl script
+ mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing 
perl script, multiple architectures

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

** Changed in: perl (Ubuntu)
   Importance: Undecided => Critical

** Changed in: perl (Ubuntu)
Milestone: None => ubuntu-19.04

** Tags added: rls-bb-incoming

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

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Incomplete
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  

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

2019-03-11 Thread Dimitri John Ledkov
I see that this bug was created with Ubuntu 18.10 (judging by the tags).
I am trying to reproduce the issue on Ubuntu 19.04 (current development 
release).

I am failing to produce a mixed blocksize cryptsetup device:
$ sudo cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1

is failing for me with:
"Device size is not aligned to the requested sector size."

And on this machine, I do not have access to native 4k and non-4k drives
at the same time. Let me get a better machine to debug this further.

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

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

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

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 

[Touch-packages] [Bug 1745032] Re: AC adapter status not detected on Asus ZenBook UX410UAK

2019-03-11 Thread Treviño
Kay-Heng, what's the status of the linux image landing on bionic?

Can you help in verify this once we've all there?

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

Title:
  AC adapter status not detected on Asus ZenBook UX410UAK

Status in gnome-control-center package in Ubuntu:
  Fix Released
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in upower package in Ubuntu:
  Fix Released
Status in gnome-control-center source package in Bionic:
  Fix Committed
Status in gnome-shell source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in upower source package in Bionic:
  Fix Committed
Status in gnome-control-center source package in Cosmic:
  Fix Released
Status in gnome-shell source package in Cosmic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in upower source package in Cosmic:
  Fix Released

Bug description:
  === SRU Justification ===
  [Impact]
  Some Asus laptops report "discharging" when the battery is full and AC
  is plugged

  [Test]
  Charge battery to full, the issue appears.
  Users report with the patch the behaviour is correct.

  [Fix]
  The discharge rate is 0 on those machines. Use that to detect the wrong
  status report.

  [Regression Potential]
  Low. The quirk uses strict DMI to match affected systems.

  === Original Bug Report ===
  The AC adapter status is incorrectly reported when the battery is fully 
charged. It always shows as if the adapter is not plugged in. If the battery is 
drained for a while, the adapter status is shown correctly (both connects and 
disconnects are shown).

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-image-4.13.0-31-generic 4.13.0-31.34
  ProcVersionSignature: Ubuntu 4.13.0-31.34-generic 4.13.13
  Uname: Linux 4.13.0-31-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  abarto 1388 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jan 23 18:26:18 2018
  InstallationDate: Installed on 2018-01-23 (0 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 8087:0a2b Intel Corp.
   Bus 001 Device 003: ID 04f2:b57a Chicony Electronics Co., Ltd
   Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: ASUSTeK COMPUTER INC. UX410UAK
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-31-generic.efi.signed 
root=UUID=58ea0561-3f74-4566-9332-5e7021275160 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.13.0-31-generic N/A
   linux-backports-modules-4.13.0-31-generic  N/A
   linux-firmware 1.169.2
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/08/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX410UAK.306
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX410UAK
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX410UAK.306:bd08/08/2017:svnASUSTeKCOMPUTERINC.:pnUX410UAK:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX410UAK:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: UX
  dmi.product.name: UX410UAK
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

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

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


[Touch-packages] [Bug 1450588] Re: /var/log/dmesg No Longer Being Updated

2019-03-11 Thread Robie Basak
It would be the readdition of a feature that we lost as a feature
regression nine releases ago. I don't see why the release team would
object, but I can't speak for the release team. It feels like a feature
to me. In the general case, ignoring feature freeze for features being
readded that were dropped multiple releases ago seems disingenuous to
me.

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

Title:
  /var/log/dmesg No Longer Being Updated

Status in rsyslog package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  After upgrading to Ubuntu 15.04 Vivid, /var/log/dmesg is no longer
  updated after boot.

  It appears that this was previously done via /etc/init/dmesg.conf

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

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


[Touch-packages] [Bug 1818516] Re: FFe: Mesa 19.0.x for disco

2019-03-11 Thread Iain Lane
what testing has happened / what are the risks?

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

Title:
  FFe: Mesa 19.0.x for disco

Status in mesa package in Ubuntu:
  New

Bug description:
  Mesa 19.0.0 will be soon released, and we should get that for disco,
  and then follow point-releases until the last one is released (roughly
  next July, will need an SRU).

  We'll also migrate it to use LLVM 8.

  New features according to upstream release notes:

  GL_AMD_texture_texture4 on all GL 4.0 drivers.
  GL_EXT_shader_implicit_conversions on all drivers (ES extension).
  GL_EXT_texture_compression_bptc on all GL 4.0 drivers (ES extension).
  GL_EXT_texture_compression_rgtc on all GL 3.0 drivers (ES extension).
  GL_EXT_render_snorm on gallium drivers (ES extension).
  GL_EXT_texture_view on drivers supporting texture views (ES extension).
  GL_OES_texture_view on drivers supporting texture views (ES extension).
  GL_NV_shader_atomic_float on nvc0 (Fermi/Kepler only).
  Shader-based software implementations of GL_ARB_gpu_shader_fp64, 
GL_ARB_gpu_shader_int64, GL_ARB_vertex_attrib_64bit, and GL_ARB_shader_ballot 
on i965.
  VK_ANDROID_external_memory_android_hardware_buffer on Intel
  Fixed and re-exposed VK_EXT_pci_bus_info on Intel and RADV
  VK_EXT_scalar_block_layout on Intel and RADV
  VK_KHR_depth_stencil_resolve on Intel
  VK_KHR_draw_indirect_count on Intel
  VK_EXT_conditional_rendering on Intel
  VK_EXT_memory_budget on RADV

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

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


[Touch-packages] [Bug 1818953] Re: Perl core dumping core on UBUNTU 19.04 by executing perl script

2019-03-11 Thread Dimitri John Ledkov
ubuntu@baltar:~$ lscpu 
Architecture:ppc64le
Byte Order:  Little Endian
CPU(s):  160
On-line CPU(s) list: 0-159
Thread(s) per core:  4
Core(s) per socket:  20
Socket(s):   2
NUMA node(s):2
Model:   2.2 (pvr 004e 1202)
Model name:  POWER9, altivec supported
CPU max MHz: 3800.
CPU min MHz: 2166.
L1d cache:   32K
L1i cache:   32K
L2 cache:512K
L3 cache:10240K
NUMA node0 CPU(s):   0-79
NUMA node8 CPU(s):   80-159
ubuntu@baltar:~$ cat test.pl 
#!//usr/bin/perl

use POSIX qw(mblen);

my $str = "data";

print "Calling mblen with str=$str\n";
my $len = mblen($str, MB_CUR_MAX);
print "mblen returned with len=$len\n";

ubuntu@baltar:~$ ./test.pl 
Calling mblen with str=data
mblen returned with len=-2


Not sure if the result of "-2" is expected, or not. From my expectations of 
what mblen() is supposed to do, that's a wrong answer
And that was POWER9, will redo on POWER8 now.

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

Title:
  Perl core dumping core on UBUNTU 19.04 by executing perl script

Status in The Ubuntu-power-systems project:
  Incomplete
Status in perl package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

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


[Touch-packages] [Bug 1819183] Re: FFe: Update pygobject to 3.32

2019-03-11 Thread Iain Lane
Yep, sure. (Ideally as a sync.)

It'd be nicer for me in future if you could paste the NEWS entries and
other things, so that I can read it all and reply directly from my email
client. :-)

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

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

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

Title:
  FFe: Update pygobject to 3.32

Status in pygobject package in Ubuntu:
  Confirmed

Bug description:
  Feature Freeze exception request
  
  Since we're updating the rest of GNOME to 3.32 (including glib and 
gobject-introspection), it seems like it would be a good idea to update 
pygobject also.

  3.32.0-1 is in Debian experimental ready to be synced over once this
  FFe is approved.

  https://gitlab.gnome.org/GNOME/pygobject/blob/master/NEWS
  https://gitlab.gnome.org/GNOME/pygobject/compare/3.30.4...3.32.0 (includes 
several commits that were already included in the current 3.30.4 version)

  Justification for lateness
  --
  Sorry, we've been a bit busy and this wasn't a high priority.

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

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


[Touch-packages] [Bug 1450588] Re: /var/log/dmesg No Longer Being Updated

2019-03-11 Thread Christian Ehrhardt 
@xnox - thanks for your ping, I agree if we would have worked on this in Vivid 
or at least Xenial.
But being so late I'd think to ask for an ack by the Release team is not wrong.
I thought here "better safe than sorry" somewhat applies.
OTOH fortunately the change itself isn't very invasive to an existing thing (as 
it is a new service), so it seems rather safe anyway.

But I can be convinced - let me ask in the Team if everyone else also
thinks this wouldn't be requiring an FFe. If so we can just upload.

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

Title:
  /var/log/dmesg No Longer Being Updated

Status in rsyslog package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  After upgrading to Ubuntu 15.04 Vivid, /var/log/dmesg is no longer
  updated after boot.

  It appears that this was previously done via /etc/init/dmesg.conf

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

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


[Touch-packages] [Bug 1818802] Re: [ZenBook UX433FN_UX433FN] Audio only works when the laptop is plugged in or the battery % is above 20 - 40%

2019-03-11 Thread Filip Golab
There you go

** Attachment added: "allpackages.txt"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818802/+attachment/5245381/+files/allpackages.txt

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

Title:
  [ZenBook UX433FN_UX433FN] Audio only works when the laptop is plugged
  in or the battery % is above 20 - 40%

Status in linux package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  Audio dies after few seconds, returns after few minutes and dies again

  filip@ux433:~$ lsb_release -rd
  Description:  Ubuntu 18.10
  Release:  18.10

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  Uname: Linux 4.20.14-042014-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  filip  8566 F pulseaudio
   /dev/snd/pcmC0D0p:   filip  8566 F...m pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar  6 10:11:01 2019
  InstallationDate: Installed on 2019-01-05 (59 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_Jack: Speaker, Internal
  Symptom_PulseAudioLog: mar 06 10:04:08 ux433 dbus-daemon[3008]: [system] 
Activating via systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.37' (uid=121 pid=6142 
comm="/usr/bin/pulseaudio --daemonize=no ")
  Symptom_Type: Sound works for a while, then breaks
  Title: [ZenBook UX433FN_UX433FN, Realtek ALC294, Speaker, Internal] fails 
after a while
  UpgradeStatus: Upgraded to cosmic on 2019-01-28 (36 days ago)
  dmi.bios.date: 11/21/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX433FN.301
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX433FN
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX433FN.301:bd11/21/2018:svnASUSTeKCOMPUTERINC.:pnZenBookUX433FN_UX433FN:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX433FN:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: ZenBook
  dmi.product.name: ZenBook UX433FN_UX433FN
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

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

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


[Touch-packages] [Bug 1817338] Re: HDMI sound output not selectable in 19.04 (but works in 18.10)

2019-03-11 Thread Silvio Bierman
I have the same bug. I used to work around this by installing an
alternative sound device selector shell extension but this one broke
down when Gnome shell upgraded to 3.31.91. So now there is no way for me
to switch to HDMI output any more.

The select box shows the correct devices but selecting a different one
has no effect. It is also not saved and when reopening control center
the default device is once again selected.

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

Title:
  HDMI sound output not selectable in 19.04 (but works in 18.10)

Status in gnome-control-center package in Ubuntu:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Invalid

Bug description:
  In 19.04, HDMI sound stopped working after some upgrade.

  The sink is somehow availalbe, but cannot be selected.
  In gnome-control-center, HDMI output device is listed, but if I choose it, no 
configuration list appears (see screen capture attached).

  aplay -l gives me:
  ~$ aplay -l
   Liste des Périphériques Matériels PLAYBACK 
  carte 0: PCH [HDA Intel PCH], périphérique 0: ALC269VC Analog [ALC269VC 
Analog]
Sous-périphériques: 0/1
Sous-périphérique #0: subdevice #0
  carte 0: PCH [HDA Intel PCH], périphérique 3: HDMI 0 [HDMI 0]
Sous-périphériques: 1/1
Sous-périphérique #0: subdevice #0
  carte 0: PCH [HDA Intel PCH], périphérique 7: HDMI 1 [HDMI 1]
Sous-périphériques: 1/1
Sous-périphérique #0: subdevice #0
  carte 0: PCH [HDA Intel PCH], périphérique 8: HDMI 2 [HDMI 2]
Sous-périphériques: 1/1
Sous-périphérique #0: subdevice #0

  pavucontrol shows HDMI as unplugged.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: pulseaudio 1:12.2-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  franck 5998 F pulseaudio
   /dev/snd/pcmC1D0c:   franck 5998 F...m pulseaudio
   /dev/snd/controlC0:  franck 5998 F pulseaudio
  CurrentDesktop: GNOME
  Date: Fri Feb 22 16:16:56 2019
  EcryptfsInUse: Yes
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SourcePackage: pulseaudio
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/27/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G7ETA9WW (2.69 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2353CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG7ETA9WW(2.69):bd09/27/2017:svnLENOVO:pn2353CTO:pvrThinkPadT430s:rvnLENOVO:rn2353CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.family: ThinkPad T430s
  dmi.product.name: 2353CTO
  dmi.product.sku: LENOVO_MT_2353
  dmi.product.version: ThinkPad T430s
  dmi.sys.vendor: LENOVO

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

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


[Touch-packages] [Bug 1817338] Re: HDMI sound output not selectable in 19.04 (but works in 18.10)

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

** Changed in: gnome-control-center (Ubuntu)
   Status: New => Confirmed

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

Title:
  HDMI sound output not selectable in 19.04 (but works in 18.10)

Status in gnome-control-center package in Ubuntu:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Invalid

Bug description:
  In 19.04, HDMI sound stopped working after some upgrade.

  The sink is somehow availalbe, but cannot be selected.
  In gnome-control-center, HDMI output device is listed, but if I choose it, no 
configuration list appears (see screen capture attached).

  aplay -l gives me:
  ~$ aplay -l
   Liste des Périphériques Matériels PLAYBACK 
  carte 0: PCH [HDA Intel PCH], périphérique 0: ALC269VC Analog [ALC269VC 
Analog]
Sous-périphériques: 0/1
Sous-périphérique #0: subdevice #0
  carte 0: PCH [HDA Intel PCH], périphérique 3: HDMI 0 [HDMI 0]
Sous-périphériques: 1/1
Sous-périphérique #0: subdevice #0
  carte 0: PCH [HDA Intel PCH], périphérique 7: HDMI 1 [HDMI 1]
Sous-périphériques: 1/1
Sous-périphérique #0: subdevice #0
  carte 0: PCH [HDA Intel PCH], périphérique 8: HDMI 2 [HDMI 2]
Sous-périphériques: 1/1
Sous-périphérique #0: subdevice #0

  pavucontrol shows HDMI as unplugged.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: pulseaudio 1:12.2-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  franck 5998 F pulseaudio
   /dev/snd/pcmC1D0c:   franck 5998 F...m pulseaudio
   /dev/snd/controlC0:  franck 5998 F pulseaudio
  CurrentDesktop: GNOME
  Date: Fri Feb 22 16:16:56 2019
  EcryptfsInUse: Yes
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SourcePackage: pulseaudio
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/27/2017
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G7ETA9WW (2.69 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2353CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG7ETA9WW(2.69):bd09/27/2017:svnLENOVO:pn2353CTO:pvrThinkPadT430s:rvnLENOVO:rn2353CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.family: ThinkPad T430s
  dmi.product.name: 2353CTO
  dmi.product.sku: LENOVO_MT_2353
  dmi.product.version: ThinkPad T430s
  dmi.sys.vendor: LENOVO

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

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


[Touch-packages] [Bug 1450588] Re: /var/log/dmesg No Longer Being Updated

2019-03-11 Thread Dimitri John Ledkov
I'm not sure why you think an FFe is needed for this. It is a simple
regression since move from upstart->systemd in the rsyslog package, and
we must SRU this back to all the releases back.

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

Title:
  /var/log/dmesg No Longer Being Updated

Status in rsyslog package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  After upgrading to Ubuntu 15.04 Vivid, /var/log/dmesg is no longer
  updated after boot.

  It appears that this was previously done via /etc/init/dmesg.conf

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

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


[Touch-packages] [Bug 1783298] Re: [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

2019-03-11 Thread Ian Gordon
If I also set "AuthType Default" for "/" then the cups 2.2.7-1ubuntu2.4 works.
I did not have this set in 14.04 or 16.04.

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

Title:
  [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

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

Bug description:
  [Impact]

  If a print queue is set up with "auth-info-required=negotiate" because
  the server requires authentication (for example Kerberos) the user is
  asked for user name and password on every join, instead of the
  authentication working automatically. This worked correctly in 14.04
  and 16.04.

  Also setting "AuthType Default" for "/" in cupsd.conf leads to be
  prompted for a password on commands like "lpatat -a", even for root.
  Works correctly in Xenial and Cosmic.

  [Test Case]

  Set up a queue pointing to a Kerberos-authenticated Windows server
  with "lpadmin ... -o auth-info-required=negotiate ..." OR set
  "AuthType Default" for "/" in cupsd.conf. When printing or running
  other commands accessing your print queue you will get prompted for
  credentials. With the fix the authentication will get automatic again.

  [Regression Potential]

  Low, as the fix are simple one-line corrections taken from upstream.

  [Original report]

  Hi,

  We have our printers configured to print to a Windows print server. In
  Ubuntu 14.04 and 16.04 our setup works fine but in 18.04 our setup
  seems to be acting more like AuthInfoRequired username,password i.e.
  it prompts for a password when printing rather than using the
  available Kerberos credentials.

  We are using an unaltered cupsd.conf file and are adding printers with
  the following command:

  lpadmin -p "printer" -D "Printer" -L "room" -v
  "smb://printers.cis.strath.ac.uk/printers" -o Media=A4 -o PageSize=A4
  -o printer-error-policy=abort-job -o auth-info-required=negotiate -m
  "CIS/hp-officejet_pro_476_576_series-ps.ppd"

  the smb backend has been linked to /usr/lib/x86_64-linux-
  gnu/samba/smbspool_krb5_wrapper (I've added this the apparmor profile
  as it's blocked by default) and the permissions on this file changed
  to 700 (owner root) as per manpage instructions.

  When using lp -d printer /tmp/test.txt I get the following response:

  Password for myuid on localhost?

  Typing my password gets the job accepted to the queue but it does
  spool to the Windows Print Server and in the error_log file I can see

  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - 
AUTH_INFO_REQUIRED=negotiate
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - Started with uid=0
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - AUTH_UID is not set

  As I said earlier this all works perfectly on Xenial and Trusty.
  (A similar AuthInfoRequired negotiate setup also works in cups 2.2.5 on MacOS 
10.13)

  Any ideas how to fix this?

  Thanks,

  Ian.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cups 2.2.7-1ubuntu2.1
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Tue Jul 24 10:03:57 2018
  InstallationDate: Installed on 2018-06-22 (31 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0461:4d81 Primax Electronics, Ltd Dell N889 Optical 
Mouse
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. OptiPlex 790
  Papersize: a4
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz root=/dev/mapper/pd--ig--vg-root ro 
quiet splash
  SourcePackage: cups
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/28/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A05
  dmi.board.name: 0HY9JP
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 6
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA05:bd05/28/2011:svnDellInc.:pnOptiPlex790:pvr01:rvnDellInc.:rn0HY9JP:rvrA00:cvnDellInc.:ct6:cvr:
  dmi.product.name: OptiPlex 790
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

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

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

[Touch-packages] [Bug 1783298] Re: [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

2019-03-11 Thread Ian Gordon
cups 2.2.7-1ubuntu2.4 from proposed has exactly the same symptoms for me
- prompts for password when printing. So the original issue seems to be
different from Esko's.

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

Title:
  [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

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

Bug description:
  [Impact]

  If a print queue is set up with "auth-info-required=negotiate" because
  the server requires authentication (for example Kerberos) the user is
  asked for user name and password on every join, instead of the
  authentication working automatically. This worked correctly in 14.04
  and 16.04.

  Also setting "AuthType Default" for "/" in cupsd.conf leads to be
  prompted for a password on commands like "lpatat -a", even for root.
  Works correctly in Xenial and Cosmic.

  [Test Case]

  Set up a queue pointing to a Kerberos-authenticated Windows server
  with "lpadmin ... -o auth-info-required=negotiate ..." OR set
  "AuthType Default" for "/" in cupsd.conf. When printing or running
  other commands accessing your print queue you will get prompted for
  credentials. With the fix the authentication will get automatic again.

  [Regression Potential]

  Low, as the fix are simple one-line corrections taken from upstream.

  [Original report]

  Hi,

  We have our printers configured to print to a Windows print server. In
  Ubuntu 14.04 and 16.04 our setup works fine but in 18.04 our setup
  seems to be acting more like AuthInfoRequired username,password i.e.
  it prompts for a password when printing rather than using the
  available Kerberos credentials.

  We are using an unaltered cupsd.conf file and are adding printers with
  the following command:

  lpadmin -p "printer" -D "Printer" -L "room" -v
  "smb://printers.cis.strath.ac.uk/printers" -o Media=A4 -o PageSize=A4
  -o printer-error-policy=abort-job -o auth-info-required=negotiate -m
  "CIS/hp-officejet_pro_476_576_series-ps.ppd"

  the smb backend has been linked to /usr/lib/x86_64-linux-
  gnu/samba/smbspool_krb5_wrapper (I've added this the apparmor profile
  as it's blocked by default) and the permissions on this file changed
  to 700 (owner root) as per manpage instructions.

  When using lp -d printer /tmp/test.txt I get the following response:

  Password for myuid on localhost?

  Typing my password gets the job accepted to the queue but it does
  spool to the Windows Print Server and in the error_log file I can see

  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - 
AUTH_INFO_REQUIRED=negotiate
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - Started with uid=0
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - AUTH_UID is not set

  As I said earlier this all works perfectly on Xenial and Trusty.
  (A similar AuthInfoRequired negotiate setup also works in cups 2.2.5 on MacOS 
10.13)

  Any ideas how to fix this?

  Thanks,

  Ian.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cups 2.2.7-1ubuntu2.1
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Tue Jul 24 10:03:57 2018
  InstallationDate: Installed on 2018-06-22 (31 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0461:4d81 Primax Electronics, Ltd Dell N889 Optical 
Mouse
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. OptiPlex 790
  Papersize: a4
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz root=/dev/mapper/pd--ig--vg-root ro 
quiet splash
  SourcePackage: cups
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/28/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A05
  dmi.board.name: 0HY9JP
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 6
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA05:bd05/28/2011:svnDellInc.:pnOptiPlex790:pvr01:rvnDellInc.:rn0HY9JP:rvrA00:cvnDellInc.:ct6:cvr:
  dmi.product.name: OptiPlex 790
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

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

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

[Touch-packages] [Bug 1783298] Re: [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

2019-03-11 Thread Till Kamppeter
Esko, thanks for the feedback. I have marked the fix as verified now so
it will get an official update for Bionic soon.

** Tags added: verification-done-bionic

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

Title:
  [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

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

Bug description:
  [Impact]

  If a print queue is set up with "auth-info-required=negotiate" because
  the server requires authentication (for example Kerberos) the user is
  asked for user name and password on every join, instead of the
  authentication working automatically. This worked correctly in 14.04
  and 16.04.

  Also setting "AuthType Default" for "/" in cupsd.conf leads to be
  prompted for a password on commands like "lpatat -a", even for root.
  Works correctly in Xenial and Cosmic.

  [Test Case]

  Set up a queue pointing to a Kerberos-authenticated Windows server
  with "lpadmin ... -o auth-info-required=negotiate ..." OR set
  "AuthType Default" for "/" in cupsd.conf. When printing or running
  other commands accessing your print queue you will get prompted for
  credentials. With the fix the authentication will get automatic again.

  [Regression Potential]

  Low, as the fix are simple one-line corrections taken from upstream.

  [Original report]

  Hi,

  We have our printers configured to print to a Windows print server. In
  Ubuntu 14.04 and 16.04 our setup works fine but in 18.04 our setup
  seems to be acting more like AuthInfoRequired username,password i.e.
  it prompts for a password when printing rather than using the
  available Kerberos credentials.

  We are using an unaltered cupsd.conf file and are adding printers with
  the following command:

  lpadmin -p "printer" -D "Printer" -L "room" -v
  "smb://printers.cis.strath.ac.uk/printers" -o Media=A4 -o PageSize=A4
  -o printer-error-policy=abort-job -o auth-info-required=negotiate -m
  "CIS/hp-officejet_pro_476_576_series-ps.ppd"

  the smb backend has been linked to /usr/lib/x86_64-linux-
  gnu/samba/smbspool_krb5_wrapper (I've added this the apparmor profile
  as it's blocked by default) and the permissions on this file changed
  to 700 (owner root) as per manpage instructions.

  When using lp -d printer /tmp/test.txt I get the following response:

  Password for myuid on localhost?

  Typing my password gets the job accepted to the queue but it does
  spool to the Windows Print Server and in the error_log file I can see

  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - 
AUTH_INFO_REQUIRED=negotiate
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - Started with uid=0
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - AUTH_UID is not set

  As I said earlier this all works perfectly on Xenial and Trusty.
  (A similar AuthInfoRequired negotiate setup also works in cups 2.2.5 on MacOS 
10.13)

  Any ideas how to fix this?

  Thanks,

  Ian.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cups 2.2.7-1ubuntu2.1
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Tue Jul 24 10:03:57 2018
  InstallationDate: Installed on 2018-06-22 (31 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0461:4d81 Primax Electronics, Ltd Dell N889 Optical 
Mouse
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. OptiPlex 790
  Papersize: a4
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz root=/dev/mapper/pd--ig--vg-root ro 
quiet splash
  SourcePackage: cups
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/28/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A05
  dmi.board.name: 0HY9JP
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 6
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA05:bd05/28/2011:svnDellInc.:pnOptiPlex790:pvr01:rvnDellInc.:rn0HY9JP:rvrA00:cvnDellInc.:ct6:cvr:
  dmi.product.name: OptiPlex 790
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

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

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

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

2019-03-11 Thread Sebastien Bacher
@dwmw2, 'This was a regression there caused by an earlier update.' would
give some details ont that? you should probably open another report
specifically about that if there was a regression in a xenial update

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

Title:
  Full-tunnel VPN DNS leakage regression

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

Bug description:
  * Impact

  When using a VPN the DNS requests might still be sent to a DNS server
  outside the VPN when they should not

  * Test case

  Configure the system to send all the traffic to a VPN, do a name
  resolution, the request should not go to the public DNS server (to be
  checked by capturing the traffic by example with wireshark)

  
  * Regression potential

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

  -

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

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

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

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

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

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


[Touch-packages] [Bug 1783298] Re: [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

2019-03-11 Thread Esko Järnfors
cups 2.2.7-1ubuntu2.4 from proposed works and fixes this issue for us.

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

Title:
  [SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work

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

Bug description:
  [Impact]

  If a print queue is set up with "auth-info-required=negotiate" because
  the server requires authentication (for example Kerberos) the user is
  asked for user name and password on every join, instead of the
  authentication working automatically. This worked correctly in 14.04
  and 16.04.

  Also setting "AuthType Default" for "/" in cupsd.conf leads to be
  prompted for a password on commands like "lpatat -a", even for root.
  Works correctly in Xenial and Cosmic.

  [Test Case]

  Set up a queue pointing to a Kerberos-authenticated Windows server
  with "lpadmin ... -o auth-info-required=negotiate ..." OR set
  "AuthType Default" for "/" in cupsd.conf. When printing or running
  other commands accessing your print queue you will get prompted for
  credentials. With the fix the authentication will get automatic again.

  [Regression Potential]

  Low, as the fix are simple one-line corrections taken from upstream.

  [Original report]

  Hi,

  We have our printers configured to print to a Windows print server. In
  Ubuntu 14.04 and 16.04 our setup works fine but in 18.04 our setup
  seems to be acting more like AuthInfoRequired username,password i.e.
  it prompts for a password when printing rather than using the
  available Kerberos credentials.

  We are using an unaltered cupsd.conf file and are adding printers with
  the following command:

  lpadmin -p "printer" -D "Printer" -L "room" -v
  "smb://printers.cis.strath.ac.uk/printers" -o Media=A4 -o PageSize=A4
  -o printer-error-policy=abort-job -o auth-info-required=negotiate -m
  "CIS/hp-officejet_pro_476_576_series-ps.ppd"

  the smb backend has been linked to /usr/lib/x86_64-linux-
  gnu/samba/smbspool_krb5_wrapper (I've added this the apparmor profile
  as it's blocked by default) and the permissions on this file changed
  to 700 (owner root) as per manpage instructions.

  When using lp -d printer /tmp/test.txt I get the following response:

  Password for myuid on localhost?

  Typing my password gets the job accepted to the queue but it does
  spool to the Windows Print Server and in the error_log file I can see

  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - 
AUTH_INFO_REQUIRED=negotiate
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - Started with uid=0
  D [24/Jul/2018:10:33:00 +0100] [Job 45] SMBSPOOL_KRB5 - AUTH_UID is not set

  As I said earlier this all works perfectly on Xenial and Trusty.
  (A similar AuthInfoRequired negotiate setup also works in cups 2.2.5 on MacOS 
10.13)

  Any ideas how to fix this?

  Thanks,

  Ian.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cups 2.2.7-1ubuntu2.1
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Tue Jul 24 10:03:57 2018
  InstallationDate: Installed on 2018-06-22 (31 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0461:4d81 Primax Electronics, Ltd Dell N889 Optical 
Mouse
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. OptiPlex 790
  Papersize: a4
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz root=/dev/mapper/pd--ig--vg-root ro 
quiet splash
  SourcePackage: cups
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/28/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A05
  dmi.board.name: 0HY9JP
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 6
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA05:bd05/28/2011:svnDellInc.:pnOptiPlex790:pvr01:rvnDellInc.:rn0HY9JP:rvrA00:cvnDellInc.:ct6:cvr:
  dmi.product.name: OptiPlex 790
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

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

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


[Touch-packages] [Bug 1818953] Re: Perl core dumping core on UBUNTU 19.04 by executing perl script

2019-03-11 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Importance: Undecided => Critical

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

Title:
  Perl core dumping core on UBUNTU 19.04 by executing perl script

Status in The Ubuntu-power-systems project:
  Incomplete
Status in perl package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

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


[Touch-packages] [Bug 1767312] Re: [radeon] Totem with gstreamer1.0-vaapi and Xorg: wrong color on H264 videos

2019-03-11 Thread Daniel van Vugt
Also verified mpv works, but mpv isn't using VAAPI at all. It's using
software decoding because "VO does not support requested hardware
decoder".

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

Title:
  [radeon] Totem with gstreamer1.0-vaapi and Xorg: wrong color on H264
  videos

Status in gstreamer-vaapi package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  Confirmed

Bug description:
  Ii've found a bug on Ubuntu 18.04 (other distros, as fedora 27, debian 
stable, debian testing) aren't affected).
  When i try to reproduce a video that use h264 codec, i've wrong colors.
  I've a notebook with APU AMD A10 8700p, and integrated gpu radeon r6

  WORKAROUND:
  sudo apt remove gstreamer1.0-vaapi
  or
  sudo apt remove mesa-va-drivers

  See also bug 1720820.

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

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


[Touch-packages] [Bug 1767312] Re: [radeon] Totem with gstreamer1.0-vaapi and Xorg: wrong color on H264 videos

2019-03-11 Thread Daniel van Vugt
Verified on bionic (fresh install and fully updated) that the bug is still 
present, and that the workaround in comment #16 works. It just took me a while 
to remember you need to:
  1. Install ubuntu-restricted-addons; and
  2. Use Xorg (because if you're in a Wayland session you hit bug 1720820 
instead).

---

OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon R6 Graphics (CARRIZO, DRM 3.23.0, 
4.15.0-46-generic, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

---

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wani 
[Radeon R5/R6/R7 Graphics] (rev c6)
Subsystem: Hewlett-Packard Company Carrizo
Kernel driver in use: amdgpu
Kernel modules: amdgpu

---

libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Mesa Gallium driver 18.2.2 for AMD Radeon R6 Graphics 
(CARRIZO, DRM 3.23.0, 4.15.0-46-generic, LLVM 7.0.0)
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

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

Title:
  [radeon] Totem with gstreamer1.0-vaapi and Xorg: wrong color on H264
  videos

Status in gstreamer-vaapi package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  Confirmed

Bug description:
  Ii've found a bug on Ubuntu 18.04 (other distros, as fedora 27, debian 
stable, debian testing) aren't affected).
  When i try to reproduce a video that use h264 codec, i've wrong colors.
  I've a notebook with APU AMD A10 8700p, and integrated gpu radeon r6

  WORKAROUND:
  sudo apt remove gstreamer1.0-vaapi
  or
  sudo apt remove mesa-va-drivers

  See also bug 1720820.

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

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


[Touch-packages] [Bug 1755250] Re: backport statx syscall whitelist fix

2019-03-11 Thread Christian Ehrhardt 
Hi,
it has been released for Cosmic already.
Some tests were blocking it for Bionic but I resolved those already.
It should be released the next time an SRU member will look at this.

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

Title:
  backport statx syscall whitelist fix

Status in docker.io package in Ubuntu:
  Invalid
Status in libseccomp package in Ubuntu:
  Fix Released
Status in docker.io source package in Bionic:
  Invalid
Status in libseccomp source package in Bionic:
  Fix Committed
Status in docker.io source package in Cosmic:
  Invalid
Status in libseccomp source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * Some newer workloads fail due to libseccomp as in Bionic lacking
  statx support

   * This backports the syscall definitions for statx to Bionic to allow
  to manage those

  [Test Case]

  # Note: I took a KVM image of Bionic to not spoil my system with Docker 
config for this test too much
  $ sudo apt install docker.io
  $ sudo usermod -a -G docker ubuntu
  $ cat > test-statx/Dockerfile << EOF
  FROM ubuntu:18.04
  RUN apt-get update && apt-get install -y wget gcc
  WORKDIR /tmp
  RUN wget -q 
https://raw.githubusercontent.com/torvalds/linux/master/samples/statx/test-statx.c
  RUN gcc test-statx.c -o test-statx
  RUN touch test-file
  RUN chmod +x ./test-statx
  RUN ./test-statx test-file
  EOF
  $ docker build test-statx

  With the bug and current docker 18.06.1-0ubuntu1~18.04.1 in Bionic
  that yields

  [...]
  Step 8/8 : RUN ./test-statx test-file
   ---> Running in 6e60a82409e6
  test-file: Operation not permitted
  statx(test-file) = -1
  The command '/bin/sh -c ./test-statx test-file' returned a non-zero code: 1

  With the fix applied it would work and look like:
  Step 8/8 : RUN ./test-statx test-file
   ---> Running in a83bc043e7bd
  statx(test-file) = 0
  results=fff
Size: 0   Blocks: 0  IO Block: 4096regular file
  Device: 00:32   Inode: 261994  Links: 1
  Access: (0644/-rw-r--r--)  Uid: 0   Gid: 0
  Access: 2019-02-08 07:57:42.0+
  Modify: 2019-02-08 07:57:42.0+
  Change: 2019-02-08 07:57:43.076507007+
   Birth: 2019-02-08 07:57:43.076507007+
  Attributes:  (     
 -... .---.-..)
  Removing intermediate container a83bc043e7bd
   ---> d428d14cbc57
  Successfully built d428d14cbc57

  
  [Regression Potential] 

   * This "only" defines a new syscall number for all the architectures.
  It does not make any other changes, thereby it should be rather safe.
  If anything software could now manage statx through libseccomp and
  behavior that was formerly failing (like the reported docker case)
  would not succeed and due to that be a change in behavior - but I
  think it is a wanted change.

  [Other Info]
   
   * n/a

  ---

  
  Hello maintainer,

  The docker version 17.03 (bionic) in ubuntu doesn't allow the statx syscall 
which is needed to build qt >=5.10 applications:
  https://github.com/docker/for-linux/issues/208#issuecomment-372400859

  Could this fix be backported in the ubuntu package ?
  https://github.com/moby/moby/pull/36417

  regards,
  xan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1755250/+subscriptions

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