[Touch-packages] [Bug 1876486] Re: Kernel panic booting after 18.04 to 20.04 upgrade

2020-08-12 Thread Christian Ehrhardt 
Hmm thanks Raphaël.
So files were still around that were unowned, that really should not happen.
Thanks for the exact file names.

The files you had in your case were part of libseccomp2 2.3.1-2.1ubuntu4 which 
is what Ubuntu had in Bionic-release.
 libseccomp2 | 2.3.1-2.1ubuntu4 | bionic   |

But before you'd be able to upgrade to Focal (do-release-upgrade will otherwise 
block) that would even in Bionic be upgraded to 2.4.3-1ubuntu3.18.04.3
 libseccomp2 | 2.4.3-1ubuntu3.18.04.3   | bionic-security  |
 libseccomp2 | 2.4.3-1ubuntu3.18.04.3   | bionic-updates   |

On that upgrade these files would vanish.

I've taken a Bionic system, downgraded to 2.3.1-2.1ubuntu4 and from there 
upgraded the package.
The files went away as one would expect:

root@b:~# ll /lib/x86_64-linux-gnu/libseccomp.so*
lrwxrwxrwx 1 root root 19 Mar  1  2018 
/lib/x86_64-linux-gnu/libseccomp.so.2 -> libseccomp.so.2.3.1
-rw-r--r-- 1 root root 280776 Mar  1  2018 
/lib/x86_64-linux-gnu/libseccomp.so.2.3.1
root@b:~# apt install libseccomp2
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  libseccomp2
1 upgraded, 0 newly installed, 0 to remove and 28 not upgraded.
Need to get 42.0 kB of archives.
After this operation, 29.7 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libseccomp2 
amd64 2.4.3-1ubuntu3.18.04.3 [42.0 kB]
Fetched 42.0 kB in 0s (312 kB/s)   
(Reading database ... 43328 files and directories currently installed.)
Preparing to unpack .../libseccomp2_2.4.3-1ubuntu3.18.04.3_amd64.deb ...
Unpacking libseccomp2:amd64 (2.4.3-1ubuntu3.18.04.3) over (2.3.1-2.1ubuntu4) ...
Setting up libseccomp2:amd64 (2.4.3-1ubuntu3.18.04.3) ...
Processing triggers for libc-bin (2.27-3ubuntu1.2) ...
root@b:~# ll /lib/x86_64-linux-gnu/libseccomp.so*
lrwxrwxrwx 1 root root 19 Jun 29 12:52 
/lib/x86_64-linux-gnu/libseccomp.so.2 -> libseccomp.so.2.4.3
-rw-r--r-- 1 root root 309456 Jun 29 12:52 
/lib/x86_64-linux-gnu/libseccomp.so.2.4.3


Do you have any chance (backup, snapshot or anything) to check which package 
(if any) owned these files on your Bionic system before upgrade?

Furthermore from your system it might be interesting to get /var/log/dpkg.log* 
attached here.
Not sure one can find something in there, but we could track exactly what 
happened to your libseccomp2 in the past - maybe that reconstruction helps to 
find how/why these files got left on your disk.

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

Title:
  Kernel panic booting after 18.04 to 20.04 upgrade

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  Upgraded Ubuntu 18.04 to 20.04.  Following the upgrade, booting was not 
possible.  The error messages is:
  /sbin/init: symbol lookup error: /lib/systemd/libsystemd-shared-245.so: 
undefined symbol: seccomp_api_get
  [4.608900] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  See also attached photograph of screen during boot.

  Upgrade followed steps from here: 
https://help.ubuntu.com/community/FocalUpgrades/Kubuntu
  With the excpetion that The -d flag was used for the do-release-upgrade:
  sudo do-release-upgrade -d -m desktop

  1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Prior to upgrade: Ubuntu 18.04.4
  After upgrade (but never booted): Ubuntu (Kubuntu) 20.04
  Note that Ubuntu had originally be installed, but kubuntu-desktop was 
recently installed to change to Kubuntu, but no booting problems were 
experienced before updating to 20.04.

  2) The version of the package you are using, via 'apt-cache policy pkgname' 
or by checking in 
  Unknown -- Package version may have changed when upgrading to 20.04.

  3) What you expected to happen
  Boot without kernel panic.

  4) What happened instead
  Could not boot.  Even selecting safe mode from grub could not boot.  Had to 
restore system from backups.  Will not attempt upgrade again.

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

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


[Touch-packages] [Bug 1891313] Re: Xorg crash

2020-08-12 Thread Daniel van Vugt
At first I thought this might be boot failure bug 1872159. To test that,
just try removing the 'splash' kernel parameter. But maybe that's not
the problem...

I can see another problem; that your Nvidia driver is not only an
unsupported version, but it's also not installed properly. This seems to
be resulting in the open source driver running the Nvidia GPU when it
shouldn't.

So this bug is invalid for now. Please uninstall the Nvidia driver you
have and use the 'Additional Drivers' app to install the supported
version 440.

If you encounter any problems after that then please open new bugs for
them. Also, if you find any evidence of crashes in /var/crash then
please use the 'ubuntu-bug' command to turn those into new bugs.

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

** Summary changed:

- Xorg crash
+ [nvidia] Xorg crash

** Tags added: nvidia

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

Title:
  [nvidia] Xorg crash

Status in xorg package in Ubuntu:
  Invalid

Bug description:
  I have a ACER Nitro 5 NVIDIA GTX 1650 Mobile with Ubuntu 20.04
  instated and i tryed to boot my notebook with a second monitor plugged
  by HDMI port. Now, my internal monitor can't be recognized and its
  crashing on the initial load screem. They can load only whit the HDMI
  is connected.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.capabilities.gpu0: Error: [Errno 21] É um diretório: 
'/proc/driver/nvidia/capabilities/gpu0'
  .proc.driver.nvidia.capabilities.mig: Error: [Errno 21] É um diretório: 
'/proc/driver/nvidia/capabilities/mig'
  .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] É um diretório: 
'/proc/driver/nvidia/gpus/:01:00.0'
  .proc.driver.nvidia.registry: Binary: ""
  .proc.driver.nvidia.suspend: suspend hibernate resume
  .proc.driver.nvidia.suspend_depth: default modeset uvm
  .proc.driver.nvidia.version:
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  450.51.06  Sun Jul 19 
20:02:54 UTC 2020
   GCC version:  gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
  ApportVersion: 2.20.11-0ubuntu27.6
  Architecture: amd64
  BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Aug 12 07:55:04 2020
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 450.51.06, 5.4.0-42-generic, x86_64: installed
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Intel Corporation UHD Graphics 630 (Mobile) [8086:3e9b] (prog-if 00 [VGA 
controller])
 Subsystem: Acer Incorporated [ALI] UHD Graphics 630 (Mobile) [1025:1331]
   NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] [10de:1f91] (rev 
a1) (prog-if 00 [VGA controller])
 Subsystem: Acer Incorporated [ALI] TU117M [GeForce GTX 1650 Mobile / 
Max-Q] [1025:1332]
  InstallationDate: Installed on 2020-08-05 (7 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 04f2:b64f Chicony Electronics Co., Ltd HD User Facing
   Bus 001 Device 002: ID 1a2c:0043 China Resource Semico Co., Ltd USB Mouse
   Bus 001 Device 004: ID 8087:0029 Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Acer Nitro AN515-54
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic 
root=UUID=b286d151-6958-4e94-8f2b-2af178b1dc88 ro vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  Title: Xorg crash
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/11/2020
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: V1.30
  dmi.board.asset.tag: Type2 - Board Serial Number
  dmi.board.name: Octavia_CFS
  dmi.board.vendor: CFL
  dmi.board.version: V1.30
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: V1.30
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.30:bd05/11/2020:svnAcer:pnNitroAN515-54:pvrV1.30:rvnCFL:rnOctavia_CFS:rvrV1.30:cvnAcer:ct10:cvrV1.30:
  dmi.product.family: Nitro 5
  dmi.product.name: Nitro AN515-54
  dmi.product.sku: 
  dmi.product.version: V1.30
  dmi.sys.vendor: Acer
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.101-2
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: 

[Touch-packages] [Bug 1880250] Re: Ctrl-C message displayed without any actual disk check

2020-08-12 Thread Daniel van Vugt
Are you sure about that? Is the footer functionality explicitly bound to
fsck or is it more general? I thought (from memory) that it was more
general and therefore it's the client's job to clear it. But I'm only
going from memory. Glad you fixed it.

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

Title:
  Ctrl-C message displayed without any actual disk check

Status in plymouth package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Confirmed
Status in plymouth source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Confirmed
Status in plymouth source package in Groovy:
  Fix Committed
Status in systemd source package in Groovy:
  Confirmed

Bug description:
  It seems the transition to bgrt lost something with Ubuntu's disk
  check details. The only thing I see on my screen during a long disk
  check is the "press Ctrl-C to stop all in progress disk checks" with
  no progress.

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

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


[Touch-packages] [Bug 1891407] Re: [journalctl --follow] Wi-Fi auto disconnect randomly, unable fix and better uninstall ubuntu

2020-08-12 Thread hatsune
** Description changed:

  Ubuntu 20.04.01 LTS (newly installed)
  (Moved that device from windows 10, didnt had issue in it)
  HP 15T-au000 device.
  
  [lspci]Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE
  PCIe Wireless Network Adapter
  
  [lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %]
  02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI 
Express Fast Ethernet controller (rev 0a)
-   DeviceName: Realtek PCIe FE Family Controller
-   Subsystem: Hewlett-Packard Company RTL810xE PCI Express Fast Ethernet 
controller
-   Kernel driver in use: r8169
-   Kernel modules: r8169
+  DeviceName: Realtek PCIe FE Family Controller
+  Subsystem: Hewlett-Packard Company RTL810xE PCI Express Fast Ethernet 
controller
+  Kernel driver in use: r8169
+  Kernel modules: r8169
  03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe 
Wireless Network Adapter
-   DeviceName: Realtek Sanji2 RTL8723BE b/g/n 1x1 + BT 4 LE PCIe+USB M.2
-   Subsystem: Hewlett-Packard Company RTL8723BE PCIe Wireless Network 
Adapter
-   Kernel driver in use: rtl8723be
-   Kernel modules: rtl8723be
+  DeviceName: Realtek Sanji2 RTL8723BE b/g/n 1x1 + BT 4 LE PCIe+USB M.2
+  Subsystem: Hewlett-Packard Company RTL8723BE PCIe Wireless Network Adapter
+  Kernel driver in use: rtl8723be
+  Kernel modules: rtl8723be
  
  Wi-Fi key is correct (i can use internet to visit sites, watch videos in 
youtube etc) however randomly disconnect and appear window to re-connect 
(sometimes constantly disconnect)
- No network related change had made (IPv6 disabled through settings)
+ No network related change has made (IPv6 disabled through settings)
+ Only one SSID is in use: Dialog 4G
  
  I ran `journalctl --follow` and below is the log. let me know if
  required to provide further details

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

Title:
  [journalctl --follow] Wi-Fi auto disconnect randomly, unable fix and
  better uninstall ubuntu

Status in network-manager package in Ubuntu:
  New

Bug description:
  Ubuntu 20.04.01 LTS (newly installed)
  (Moved that device from windows 10, didnt had issue in it)
  HP 15T-au000 device.

  [lspci]Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE
  PCIe Wireless Network Adapter

  [lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %]
  02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI 
Express Fast Ethernet controller (rev 0a)
   DeviceName: Realtek PCIe FE Family Controller
   Subsystem: Hewlett-Packard Company RTL810xE PCI Express Fast Ethernet 
controller
   Kernel driver in use: r8169
   Kernel modules: r8169
  03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe 
Wireless Network Adapter
   DeviceName: Realtek Sanji2 RTL8723BE b/g/n 1x1 + BT 4 LE PCIe+USB M.2
   Subsystem: Hewlett-Packard Company RTL8723BE PCIe Wireless Network Adapter
   Kernel driver in use: rtl8723be
   Kernel modules: rtl8723be

  Wi-Fi key is correct (i can use internet to visit sites, watch videos in 
youtube etc) however randomly disconnect and appear window to re-connect 
(sometimes constantly disconnect)
  No network related change has made (IPv6 disabled through settings)
  Only one SSID is in use: Dialog 4G

  I ran `journalctl --follow` and below is the log. let me know if
  required to provide further details

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

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


[Touch-packages] [Bug 1452115] Re: Python interpreter binary is not compiled as PIE

2020-08-12 Thread Bug Watch Updater
** Changed in: python3.7 (Debian)
   Status: Unknown => New

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

Title:
  Python interpreter binary is not compiled as PIE

Status in Python:
  New
Status in python2.7 package in Ubuntu:
  Fix Released
Status in python3.4 package in Ubuntu:
  Fix Released
Status in python3.6 package in Ubuntu:
  Confirmed
Status in python3.7 package in Ubuntu:
  Confirmed
Status in python3.8 package in Ubuntu:
  Confirmed
Status in python3.7 package in Debian:
  New
Status in python3.8 package in Debian:
  New

Bug description:
  The python2.7 binary (installed at /usr/bin/python2.7; package version
  2.7.6-8) is not compiled as a position independent executable (PIE).
  It appears that the python compilation process is somewhat arcane and
  the hardening wrapper probably doesn't do the trick for it.

  This is incredibly dangerous as it means that any vulnerability within
  a native module (e.g. ctypes-based), or within python itself will
  expose an incredibly large amount of known memory contents at known
  addresses (including a large number of dangerous instruction
  groupings). This enables ROP-based (https://en.wikipedia.org/wiki
  /Return-oriented_programming) to abuse the interpreter itself to
  bypass non-executable page protections.

  I have put together an example vulnerable C shared object (with a buffer 
overflow) accessed via python through the ctypes interface as an example. This 
uses a single ROP "gadget" on top of using the known PLT location for system(3) 
(https://en.wikipedia.org/wiki/Return-to-libc_attack) to call "id". The example 
code is accessible at:
  - https://gist.github.com/ChaosData/ae6076cb1c3cc7b0a367

  I'm not exactly familiar enough with the python build process to say
  where exactly an -fPIE needs to be injected into a script/makefile,
  but I feel that given the perceived general preference for ctypes-
  based modules over python written ones, as the native code
  implementations tend to be more performant, this feels like a large
  security hole within the system. Given the nature of this "issue," I'm
  not 100% sure of where it is best reported, but from what I can tell,
  this conflicts with the Ubuntu hardening features and is definitely
  exploitable should a native module contain a sufficiently exploitable
  vulnerability that allows for control of the instruction register.

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

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


[Touch-packages] [Bug 1891407] Re: [journalctl --follow] Wi-Fi auto disconnect randomly, unable fix and better uninstall ubuntu

2020-08-12 Thread hatsune
** Description changed:

  Ubuntu 20.04.01 LTS (newly installed)
  (Moved that device from windows 10, didnt had issue in it)
  HP 15T-au000 device.
+ 
+ [lspci]Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE
+ PCIe Wireless Network Adapter
+ 
+ [lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %]
+ 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI 
Express Fast Ethernet controller (rev 0a)
+   DeviceName: Realtek PCIe FE Family Controller
+   Subsystem: Hewlett-Packard Company RTL810xE PCI Express Fast Ethernet 
controller
+   Kernel driver in use: r8169
+   Kernel modules: r8169
+ 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe 
Wireless Network Adapter
+   DeviceName: Realtek Sanji2 RTL8723BE b/g/n 1x1 + BT 4 LE PCIe+USB M.2
+   Subsystem: Hewlett-Packard Company RTL8723BE PCIe Wireless Network 
Adapter
+   Kernel driver in use: rtl8723be
+   Kernel modules: rtl8723be
  
  Wi-Fi key is correct (i can use internet to visit sites, watch videos in 
youtube etc) however randomly disconnect and appear window to re-connect 
(sometimes constantly disconnect)
  No network related change had made (IPv6 disabled through settings)
  
  I ran `journalctl --follow` and below is the log. let me know if
  required to provide further details

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

Title:
  [journalctl --follow] Wi-Fi auto disconnect randomly, unable fix and
  better uninstall ubuntu

Status in network-manager package in Ubuntu:
  New

Bug description:
  Ubuntu 20.04.01 LTS (newly installed)
  (Moved that device from windows 10, didnt had issue in it)
  HP 15T-au000 device.

  [lspci]Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE
  PCIe Wireless Network Adapter

  [lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %]
  02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI 
Express Fast Ethernet controller (rev 0a)
DeviceName: Realtek PCIe FE Family Controller
Subsystem: Hewlett-Packard Company RTL810xE PCI Express Fast Ethernet 
controller
Kernel driver in use: r8169
Kernel modules: r8169
  03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe 
Wireless Network Adapter
DeviceName: Realtek Sanji2 RTL8723BE b/g/n 1x1 + BT 4 LE PCIe+USB M.2
Subsystem: Hewlett-Packard Company RTL8723BE PCIe Wireless Network 
Adapter
Kernel driver in use: rtl8723be
Kernel modules: rtl8723be

  Wi-Fi key is correct (i can use internet to visit sites, watch videos in 
youtube etc) however randomly disconnect and appear window to re-connect 
(sometimes constantly disconnect)
  No network related change had made (IPv6 disabled through settings)

  I ran `journalctl --follow` and below is the log. let me know if
  required to provide further details

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

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


[Touch-packages] [Bug 1891407] [NEW] [journalctl --follow] Wi-Fi auto disconnect randomly, unable fix and better uninstall ubuntu

2020-08-12 Thread hatsune
Public bug reported:

Ubuntu 20.04.01 LTS (newly installed)
(Moved that device from windows 10, didnt had issue in it)
HP 15T-au000 device.

Wi-Fi key is correct (i can use internet to visit sites, watch videos in 
youtube etc) however randomly disconnect and appear window to re-connect 
(sometimes constantly disconnect)
No network related change had made (IPv6 disabled through settings)

I ran `journalctl --follow` and below is the log. let me know if
required to provide further details

** Affects: network-manager (Ubuntu)
 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/1891407

Title:
  [journalctl --follow] Wi-Fi auto disconnect randomly, unable fix and
  better uninstall ubuntu

Status in network-manager package in Ubuntu:
  New

Bug description:
  Ubuntu 20.04.01 LTS (newly installed)
  (Moved that device from windows 10, didnt had issue in it)
  HP 15T-au000 device.

  Wi-Fi key is correct (i can use internet to visit sites, watch videos in 
youtube etc) however randomly disconnect and appear window to re-connect 
(sometimes constantly disconnect)
  No network related change had made (IPv6 disabled through settings)

  I ran `journalctl --follow` and below is the log. let me know if
  required to provide further details

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

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


[Touch-packages] [Bug 1891221] Re: libgdk-pixbuf2.0-bin package does not contain gdk-pixbuf-query-loaders

2020-08-12 Thread Jan Claeys
One can specify an alternative path, but it would be nice if the fact
that the tool was relocated to a non-default (or at least not-in-$PATH)
location was documented somewhere…

(Neither its manpage nor the other gdk-pixbuf documentation seems to
mention that.)

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

Title:
  libgdk-pixbuf2.0-bin package does not contain gdk-pixbuf-query-loaders

Status in gdk-pixbuf package in Ubuntu:
  Invalid

Bug description:
  Because EOG can't show webp images by default I tried to build
  https://github.com/aruiz/webp-pixbuf-loader but it complains that it
  can't find the 'gdk-pixbuf-query-loaders' tool it needs.

  I assume it should be in the 'libgdk-pixbuf2.0-bin' package, as that
  does contain a manpage for it, but not the tool itself?

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

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


[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

2020-08-12 Thread Richard Laager
Excellent. I'm available to test the -proposed update for focal whenever
it is ready.

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

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  Invalid
Status in bind9-libs source package in Groovy:
  Fix Released
Status in isc-dhcp source package in Groovy:
  Invalid

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

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

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


[Touch-packages] [Bug 1866681] Re: [HP Pavilion dv9000] Mute toggles on/off while plugged into the headphone/speaker jack (19.04+)

2020-08-12 Thread Kuroš Taheri-Golværzi
Just checked both my other (unaffected) drives. Neither Manjaro nor
CentOS have that line in the `/etc/pulse/default.pa` file. I used the
/ search in Less with the word "switch", and that line wasn't in
either of them.

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

Title:
  [HP Pavilion dv9000] Mute toggles on/off while plugged into the
  headphone/speaker jack (19.04+)

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

Bug description:
  I'm on an HP Pavilion dv9000 (https://www.cnet.com/products/hp-
  pavilion-dv9000/specs/) built many years ago.

  
  Whenever I'm using any distro that's based on Ubuntu which was published from 
Version 19.04 onwards, I've been having a major issue with the mute button 
toggling on and off whenever I have something plugged into the audio out jack. 
I know that it's not the fault of XFCE, because I also use the latest version 
of Manjaro with XFCE on this same computer, and it works fine. I also know it's 
not any Red Hat-based distro, because I use Stella (which is a remix of CentOS 
6) also on this exact same computer, and it also works fine. Qubes, Mageia, and 
Fedora 31 also work perfectly fine and don't have this issue.

  My "lsb-release" is:
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=19.10
  DISTRIB_CODENAME=eoan
  DISTRIB_DESCRIPTION="Ubuntu 19.10"

  and "apt-cache policy pulseaudio" outputs:
  pulseaudio:
Installed: 1:13.0-1ubuntu1.1
Candidate: 1:13.0-1ubuntu1.1
Version table:
   *** 1:13.0-1ubuntu1.1 500
  500 http://us.archive.ubuntu.com/ubuntu eoan-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:13.0-1ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu eoan/main amd64 Packages

  I've uploaded a short video of the problem that I recorded with my phone here:
  https://www.youtube.com/watch?v=GXaHXQA-5uQ

  
  The problem appears with Kali 2019 and 2020, Peppermint 19.04, Lubuntu 19.04, 
Xubuntu 19.04, and Sparky 5.10 and 2020.02.

  
  I've checked pretty much everything I can think of. There's a log for my ALSA 
help diagnostics results on my current computer (which works properly with 
18.04) at:
  http://alsa-project.org/db/?f=4859b85cd7fc32e7f01f8df63591b5a43dbf6829

  
  the result output of lspci is:
  [code]00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2)
  00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev a2)
  00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 (rev a2)
  00:00.3 RAM memory: NVIDIA Corporation C51 Memory Controller 5 (rev a2)
  00:00.4 RAM memory: NVIDIA Corporation C51 Memory Controller 4 (rev a2)
  00:00.5 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2)
  00:00.6 RAM memory: NVIDIA Corporation C51 Memory Controller 3 (rev a2)
  00:00.7 RAM memory: NVIDIA Corporation C51 Memory Controller 2 (rev a2)
  00:02.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1)
  00:03.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1)
  00:04.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1)
  00:09.0 RAM memory: NVIDIA Corporation MCP51 Host Bridge (rev a2)
  00:0a.0 ISA bridge: NVIDIA Corporation MCP51 LPC Bridge (rev a3)
  00:0a.1 SMBus: NVIDIA Corporation MCP51 SMBus (rev a3)
  00:0a.3 Co-processor: NVIDIA Corporation MCP51 PMU (rev a3)
  00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3)
  00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3)
  00:0d.0 IDE interface: NVIDIA Corporation MCP51 IDE (rev f1)
  00:0e.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev f1)
  00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev f1)
  00:10.0 PCI bridge: NVIDIA Corporation MCP51 PCI Bridge (rev a2)
  00:10.1 Audio device: NVIDIA Corporation MCP51 High Definition Audio (rev a2)
  00:14.0 Bridge: NVIDIA Corporation MCP51 Ethernet Controller (rev a3)
  00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
  00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
Address Map
  00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
DRAM Controller
  00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
  03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4311 802.11b/g 
WLAN (rev 01)
  05:00.0 VGA compatible controller: NVIDIA Corporation G73M [GeForce Go 7600] 
(rev a1)
  07:05.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
  07:05.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 19)
  07:05.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter 
(rev 0a)
  07:05.3 System 

[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

2020-08-12 Thread Launchpad Bug Tracker
This bug was fixed in the package bind9-libs - 1:9.11.19+dfsg-1ubuntu1

---
bind9-libs (1:9.11.19+dfsg-1ubuntu1) groovy; urgency=medium

  [ Jorge Niedbalski  ]
  * debian/patches/0010-fix-1872118.patch: Check if pending_send
if set before calling dispatch_send. Fixes LP: #1872118.

 -- Gianfranco Costamagna   Tue, 11 Aug 2020
15:25:14 +0200

** Changed in: bind9-libs (Ubuntu Groovy)
   Status: In Progress => Fix Released

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

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  Invalid
Status in bind9-libs source package in Groovy:
  Fix Released
Status in isc-dhcp source package in Groovy:
  Invalid

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

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

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


[Touch-packages] [Bug 1889052] Re: 20.10: vlc crashes with seg fault when a video should be played

2020-08-12 Thread Sebastian Ramacher
** Package changed: vlc (Ubuntu) => mesa (Ubuntu)

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

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

Title:
  20.10: vlc crashes with seg fault when a video should be played

Status in mesa package in Ubuntu:
  New

Bug description:
  When I try to play "any" video vlc crashes with a seg fault.

  Tested: 
  - mkv + h.264
  - mp4 + h.264
  - wmv

  Maybe it's a good idea to choose a different vlc release for the
  repos?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: vlc 3.0.9.2-1
  ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.4
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: XFCE
  Date: Mon Jul 27 17:27:42 2020
  SourcePackage: vlc
  UpgradeStatus: Upgraded to focal on 2020-07-24 (3 days ago)

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

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


[Touch-packages] [Bug 1889052] [NEW] 20.10: vlc crashes with seg fault when a video should be played

2020-08-12 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

When I try to play "any" video vlc crashes with a seg fault.

Tested: 
- mkv + h.264
- mp4 + h.264
- wmv

Maybe it's a good idea to choose a different vlc release for the repos?

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vlc 3.0.9.2-1
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
Date: Mon Jul 27 17:27:42 2020
SourcePackage: vlc
UpgradeStatus: Upgraded to focal on 2020-07-24 (3 days ago)

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


** Tags: amd64 apport-bug focal
-- 
20.10: vlc crashes with seg fault when a video should be played
https://bugs.launchpad.net/bugs/1889052
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to mesa in Ubuntu.

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


[Touch-packages] [Bug 1880250] Re: Ctrl-C message displayed without any actual disk check

2020-08-12 Thread Dimitri John Ledkov
Plymouth does not clear the footer at the end of fsck.

But with that fix in-place it still looks like fsckd flickers the ctrl+c
message, despite not having any progress to show.

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

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

Title:
  Ctrl-C message displayed without any actual disk check

Status in plymouth package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Confirmed
Status in plymouth source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Confirmed
Status in plymouth source package in Groovy:
  Fix Committed
Status in systemd source package in Groovy:
  Confirmed

Bug description:
  It seems the transition to bgrt lost something with Ubuntu's disk
  check details. The only thing I see on my screen during a long disk
  check is the "press Ctrl-C to stop all in progress disk checks" with
  no progress.

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

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


[Touch-packages] [Bug 1891397] Re: package initramfs-tools 0.136ubuntu6.2 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1

2020-08-12 Thread Apport retracing service
** Tags removed: need-duplicate-check

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

Title:
  package initramfs-tools 0.136ubuntu6.2 failed to install/upgrade:
  installed initramfs-tools package post-installation script subprocess
  returned error exit status 1

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  was doing do-release-upgrade -d  (from 18.04 to 20.04, before "proper"
  20.04.1 LTS release was released)

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: initramfs-tools 0.136ubuntu6.2
  ProcVersionSignature: Ubuntu 4.15.0-112.113-generic 4.15.18
  Uname: Linux 4.15.0-112-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.6
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Tue Aug 11 18:50:32 2020
  ErrorMessage: installed initramfs-tools package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2016-01-23 (1663 days ago)
  InstallationMedia: Ubuntu-Server 14.04.3 LTS "Trusty Tahr" - Beta amd64 
(20150805)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 
2.7.17-4
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SourcePackage: initramfs-tools
  Title: package initramfs-tools 0.136ubuntu6.2 failed to install/upgrade: 
installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to focal on 2020-08-11 (0 days ago)

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

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


[Touch-packages] [Bug 1891397] [NEW] package initramfs-tools 0.136ubuntu6.2 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status

2020-08-12 Thread Martin
Public bug reported:

was doing do-release-upgrade -d  (from 18.04 to 20.04, before "proper"
20.04.1 LTS release was released)

ProblemType: Package
DistroRelease: Ubuntu 20.04
Package: initramfs-tools 0.136ubuntu6.2
ProcVersionSignature: Ubuntu 4.15.0-112.113-generic 4.15.18
Uname: Linux 4.15.0-112-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.6
Architecture: amd64
CasperMD5CheckResult: skip
Date: Tue Aug 11 18:50:32 2020
ErrorMessage: installed initramfs-tools package post-installation script 
subprocess returned error exit status 1
InstallationDate: Installed on 2016-01-23 (1663 days ago)
InstallationMedia: Ubuntu-Server 14.04.3 LTS "Trusty Tahr" - Beta amd64 
(20150805)
PackageArchitecture: all
Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 2.7.17-4
RelatedPackageVersions:
 dpkg 1.19.7ubuntu3
 apt  2.0.2ubuntu0.1
SourcePackage: initramfs-tools
Title: package initramfs-tools 0.136ubuntu6.2 failed to install/upgrade: 
installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
UpgradeStatus: Upgraded to focal on 2020-08-11 (0 days ago)

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


** Tags: amd64 apport-package focal

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

Title:
  package initramfs-tools 0.136ubuntu6.2 failed to install/upgrade:
  installed initramfs-tools package post-installation script subprocess
  returned error exit status 1

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  was doing do-release-upgrade -d  (from 18.04 to 20.04, before "proper"
  20.04.1 LTS release was released)

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: initramfs-tools 0.136ubuntu6.2
  ProcVersionSignature: Ubuntu 4.15.0-112.113-generic 4.15.18
  Uname: Linux 4.15.0-112-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.6
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Tue Aug 11 18:50:32 2020
  ErrorMessage: installed initramfs-tools package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2016-01-23 (1663 days ago)
  InstallationMedia: Ubuntu-Server 14.04.3 LTS "Trusty Tahr" - Beta amd64 
(20150805)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 
2.7.17-4
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SourcePackage: initramfs-tools
  Title: package initramfs-tools 0.136ubuntu6.2 failed to install/upgrade: 
installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to focal on 2020-08-11 (0 days ago)

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

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


[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

2020-08-12 Thread Andreas Hasenack
** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
  
  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
  
  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
  This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded and /e/d/motd-news was manually removed by the user, 
there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" 
below for details).
  
  In general, the regression risks here are:
  - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
  - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
  - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
  - have some sort of dpkg postinst or dependency error because of unpredicted 
scenarios. Certain assumptions are being made, like the renames that 
dpkg-maintscript-helper does, and that the filename 
/etc/default/motd-news.wasremoved that I'm touching and verifying is really 
mine and not something that was there already.
  - the versions 

[Touch-packages] [Bug 1891394] [NEW] systemd breaks upgrade with useless error if /var is not owned by root

2020-08-12 Thread Darxus
Public bug reported:

I just upgraded from 16.04 to 18.04.  The upgrade broke.  The error,
from systemd, was:

"Unsafe symlinks encountered in /var/log/journal, refusing."

That directory was empty.  The fix was "chmod root:root /var".  Yes,
it's weird that my /var wasn't owned by root, but upgrade breaking
errors should say something useful.

panic:~# chown darxus:darxus /var
panic:~# dpkg-reconfigure systemd
Unsafe symlinks encountered in /var/spool/rsyslog, refusing.
Unsafe symlinks encountered in /var/lib/colord, refusing.
Unsafe symlinks encountered in /var/lib/colord/icc, refusing.
Unsafe symlinks encountered in /var/cache/man, refusing.
Unsafe symlinks encountered in /var/run/opendkim, refusing.
Unsafe symlinks encountered in /var/lib/systemd, refusing.
Unsafe symlinks encountered in /var/lib/systemd/coredump, refusing.
Unsafe symlinks encountered in /var/log/wtmp, refusing.
Unsafe symlinks encountered in /var/log/btmp, refusing.
Unsafe symlinks encountered in /var/log/lastlog, refusing.
Unsafe symlinks encountered in /var/log, refusing.
Unsafe symlinks encountered in /var/log/auth.log, refusing.
Unsafe symlinks encountered in /var/log/mail.err, refusing.
Unsafe symlinks encountered in /var/log/mail.log, refusing.
Unsafe symlinks encountered in /var/log/kern.log, refusing.
Unsafe symlinks encountered in /var/log/syslog, refusing.
Unsafe symlinks encountered in /var/log/journal, refusing.
Unsafe symlinks encountered in /var/log/journal, refusing.
Unsafe symlinks encountered in /var/log/journal, refusing.
Unsafe symlinks encountered in /var/log/journal, refusing.
Unsafe symlinks encountered in 
/var/log/journal/6118992be5f52430d74ed66e4cc8d590, refusing.
Unsafe symlinks encountered in 
/var/log/journal/6118992be5f52430d74ed66e4cc8d590, refusing.
Unsafe symlinks encountered in 
/var/log/journal/6118992be5f52430d74ed66e4cc8d590, refusing.
Unsafe symlinks encountered in 
/var/log/journal/6118992be5f52430d74ed66e4cc8d590, refusing.
Unsafe symlinks encountered in 
/var/log/journal/6118992be5f52430d74ed66e4cc8d590/system.journal, refusing.
Unsafe symlinks encountered in 
/var/log/journal/6118992be5f52430d74ed66e4cc8d590/system.journal, refusing.
panic:~# chown root:root /var
panic:~# dpkg-reconfigure systemd

I found the fix here: https://askubuntu.com/a/1095796
Showing that I'm not the only one encountering this.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu10.42
Uname: Linux 5.6.14-x86_64-linode135 x86_64
ApportVersion: 2.20.9-0ubuntu7.16
Architecture: i386
Date: Wed Aug 12 15:58:33 2020
Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
ProcKernelCmdLine: root=/dev/sda console=tty1 console=ttyS0 ro  devtmpfs.mount=1
ProcModules:
 
SourcePackage: systemd
UpgradeStatus: Upgraded to bionic on 2020-08-12 (0 days ago)
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-q35-3.1
dmi.modalias: 
dmi:bvnSeaBIOS:bvrrel-1.12.0-0-ga698c8995f-prebuilt.qemu.org:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-3.1:cvnQEMU:ct1:cvrpc-q35-3.1:
dmi.product.name: Standard PC (Q35 + ICH9, 2009)
dmi.product.version: pc-q35-3.1
dmi.sys.vendor: QEMU

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


** Tags: apport-bug bionic i386

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

Title:
  systemd breaks upgrade with useless error if /var is not owned by root

Status in systemd package in Ubuntu:
  New

Bug description:
  I just upgraded from 16.04 to 18.04.  The upgrade broke.  The error,
  from systemd, was:

  "Unsafe symlinks encountered in /var/log/journal, refusing."

  That directory was empty.  The fix was "chmod root:root /var".  Yes,
  it's weird that my /var wasn't owned by root, but upgrade breaking
  errors should say something useful.

  panic:~# chown darxus:darxus /var
  panic:~# dpkg-reconfigure systemd
  Unsafe symlinks encountered in /var/spool/rsyslog, refusing.
  Unsafe symlinks encountered in /var/lib/colord, refusing.
  Unsafe symlinks encountered in /var/lib/colord/icc, refusing.
  Unsafe symlinks encountered in /var/cache/man, refusing.
  Unsafe symlinks encountered in /var/run/opendkim, refusing.
  Unsafe symlinks encountered in /var/lib/systemd, refusing.
  Unsafe symlinks encountered in /var/lib/systemd/coredump, refusing.
  Unsafe symlinks encountered in /var/log/wtmp, refusing.
  Unsafe symlinks encountered in /var/log/btmp, refusing.
  Unsafe symlinks encountered in /var/log/lastlog, refusing.
  Unsafe symlinks encountered in /var/log, refusing.
  Unsafe symlinks encountered in /var/log/auth.log, refusing.
  Unsafe symlinks encountered in /var/log/mail.err, refusing.
  Unsafe symlinks encountered in /var/log/mail.log, 

[Touch-packages] [Bug 1876486] Re: Kernel panic booting after 18.04 to 20.04 upgrade

2020-08-12 Thread Raphaël Jakse
I'm in the same case as Joi: I went from Ubuntu 16.04 to Ubuntu 18.04 to
Ubuntu 20.04. Removing libsecomp libraries in /lib and the old one in
/usr/lib (version 2.3) allowed the system to boot.

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

Title:
  Kernel panic booting after 18.04 to 20.04 upgrade

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  Upgraded Ubuntu 18.04 to 20.04.  Following the upgrade, booting was not 
possible.  The error messages is:
  /sbin/init: symbol lookup error: /lib/systemd/libsystemd-shared-245.so: 
undefined symbol: seccomp_api_get
  [4.608900] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  See also attached photograph of screen during boot.

  Upgrade followed steps from here: 
https://help.ubuntu.com/community/FocalUpgrades/Kubuntu
  With the excpetion that The -d flag was used for the do-release-upgrade:
  sudo do-release-upgrade -d -m desktop

  1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Prior to upgrade: Ubuntu 18.04.4
  After upgrade (but never booted): Ubuntu (Kubuntu) 20.04
  Note that Ubuntu had originally be installed, but kubuntu-desktop was 
recently installed to change to Kubuntu, but no booting problems were 
experienced before updating to 20.04.

  2) The version of the package you are using, via 'apt-cache policy pkgname' 
or by checking in 
  Unknown -- Package version may have changed when upgrading to 20.04.

  3) What you expected to happen
  Boot without kernel panic.

  4) What happened instead
  Could not boot.  Even selecting safe mode from grub could not boot.  Had to 
restore system from backups.  Will not attempt upgrade again.

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

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


[Touch-packages] [Bug 1876486] Re: Kernel panic booting after 18.04 to 20.04 upgrade

2020-08-12 Thread Raphaël Jakse
These files didn't belong to any package (anymore?). Here are the files I 
removed:
- /lib/x86_64-linux-gnu/libseccomp.so.2.3.1
- /lib/x86_64-linux-gnu/libseccomp.so.2 (link to the previous file)
- /usr/lib/x86_64-linux-gnu/libseccomp.so.2.3.3

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

Title:
  Kernel panic booting after 18.04 to 20.04 upgrade

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  Upgraded Ubuntu 18.04 to 20.04.  Following the upgrade, booting was not 
possible.  The error messages is:
  /sbin/init: symbol lookup error: /lib/systemd/libsystemd-shared-245.so: 
undefined symbol: seccomp_api_get
  [4.608900] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  See also attached photograph of screen during boot.

  Upgrade followed steps from here: 
https://help.ubuntu.com/community/FocalUpgrades/Kubuntu
  With the excpetion that The -d flag was used for the do-release-upgrade:
  sudo do-release-upgrade -d -m desktop

  1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Prior to upgrade: Ubuntu 18.04.4
  After upgrade (but never booted): Ubuntu (Kubuntu) 20.04
  Note that Ubuntu had originally be installed, but kubuntu-desktop was 
recently installed to change to Kubuntu, but no booting problems were 
experienced before updating to 20.04.

  2) The version of the package you are using, via 'apt-cache policy pkgname' 
or by checking in 
  Unknown -- Package version may have changed when upgrading to 20.04.

  3) What you expected to happen
  Boot without kernel panic.

  4) What happened instead
  Could not boot.  Even selecting safe mode from grub could not boot.  Had to 
restore system from backups.  Will not attempt upgrade again.

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

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


[Touch-packages] [Bug 1888101] Re: 'unsupported protocol' error when using PyMySQL

2020-08-12 Thread Seth Arnold
** Changed in: openssl (Ubuntu)
   Status: Incomplete => Confirmed

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

Title:
  'unsupported protocol' error when using PyMySQL

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  1)
  Description:  Ubuntu 20.04 LTS
  Release:  20.04

  2)
  openssl:
Installiert:   1.1.1f-1ubuntu2
Installationskandidat: 1.1.1f-1ubuntu2
Versionstabelle:
   *** 1.1.1f-1ubuntu2 500
  500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  3) + 4)
  I am trying to connect to my MariaDB with python package "PyMySQL" and SSL 
enabled. On my old installation (Kubuntu 19.10) this worked. With the new 
installation (also new PC: Xubuntu 20.04) I get this error message:

  ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol
  (_ssl.c:1108)

  Here are my installation details:
  Old installation: python 3.7.5, pymysql 0.9.3, ssl.OPENSSL_VERSION = 1.1.1c 
28 May 2019
  New installation: python 3.8.2, pymysql 0.9.3, ssl.OPENSSL_VERSION = 1.1.1f 
31 Mar 2020

  When I use python with a different SSL version...:
  this works: python 3.7.5, ssl.OPENSSL_VERSION = OpenSSL 1.1.0m-dev xx XXX 
  this works: python 3.7.5, ssl.OPENSSL_VERSION = OpenSSL 1.1.1h-dev xx XXX 
  this works: python 3.8.2, ssl.OPENSSL_VERSION = OpenSSL 1.1.1h-dev xx XXX 

  
  It seems, like the one specific version of openSSL (1.1.1f 31 Mar 2020) does 
not work together with PyMySQL.

  Some more details I have posted here:
  
https://stackoverflow.com/questions/62964998/unsupported-protocol-error-when-using-pymysql

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssl 1.1.1f-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
  Uname: Linux 5.4.0-40-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.4
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: XFCE
  Date: Sat Jul 18 15:42:27 2020
  InstallationDate: Installed on 2020-07-13 (4 days ago)
  InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-08-12 Thread Guilherme G. Piccoli
Attaching a new Bionic debdiff, which now includes a fix for a third bug
(LP #1820929).

** Patch added: "bionic_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5401090/+files/bionic_initramfs_lp1879980_V2.debdiff

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

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

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

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

2020-08-12 Thread Guilherme G. Piccoli
Attaching a new Bionic debdiff, which now includes a fix for a third bug
(LP #1820929).

** Patch added: "bionic_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5401089/+files/bionic_initramfs_lp1879980_V2.debdiff

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

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

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

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


[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces

2020-08-12 Thread Guilherme G. Piccoli
Although the debdiff is hereby attached, 3 bugs have fixes carried on
such patch - the main work is done on LP ##1879980 (and the other LP
handled in this SRU is #1879987) .

** Tags added: sts

** Description changed:

- This bug is a follow-up to
+ [Impact]
  
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
+ * At present, virtual machines utilizing net_failover network interface
+ configurations are incorrectly configured due to the reliance on the MAC
+ address to identify specific network interfaces.  When net_failover is
+ utilized, multiple interfaces will bear the same MAC address (the
+ net_failover master itself, as well as the interfaces subordinate to
+ it), rendering the MAC address ineffective for unique identification of
+ the interface.  This results in incorrect naming of network interfaces
+ from the "set-name" directive in the netplan configuration.
  
- after applying the 0001-net_failover-delay-taking-over-primary-device-
- to-acc.patch attached in that bug, the VF interface "eth0" is renamed to
- "rename4" instead of "ens4". Log is showing that attempt to rename
- "eth0" to "ens3" failed because of conflict with existing name, so
- that's why it ends up with rename4.
+ * The solution here is to use the interface name instead of the MAC
+ address when the interface is a net_failover master device.  Logic is
+ added on initramfs-tools to check the device type and virtio flags to
+ apply this change only to net_failover master devices.
  
- vsbalakr@ubuntu-18:~$ uname -a
- Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
- vsbalakr@ubuntu-18:~$ ip l 
- 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
- 2: ens3:  mtu 1500 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff 
- 3: ens3nsby:  mtu 1500 qdisc pfifo_fast 
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether 
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff 
- 4: rename4:  mtu 1500 qdisc mq master ens3 
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff
+ [Test Case]
  
- vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
- ...
- Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): carrier: link connected
- Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): enslaved to non-master-type device ens3; ignoring
- Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface 
name 'eth0' to 'ens3': Device or resource busy
- Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4' 
from 'eth0' to 'ens3': Device or resource busy
+ * The change can be tested by configuring a virtual machine with a
+ virtio_net network device with the "failover=on" option to the "-device"
+ option to qemu, e.g.,
  
- Within VM there's netplan config as below:
+ -device virtio-net-
+ 
pci,netdev=hostnet0,id=net0,bus=pci.0,addr=0x3,mac=00:00:17:00:18:04,failover=on
  
- vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
- # This file describes the network interfaces available on your system
- # For more information, see netplan(5).
- network:
-   version: 2
-   renderer: networkd
-   ethernets:
- ens3:
-   dhcp4: yes
-   gateway4: 10.211.8.1
-   nameservers:
-   addresses: [10.211.11.1,10.209.76.197]
+ * This will set the virtio device "standby" feature bit (bit 62,
+ counting from 0).  This requires a version of qemu with support for this
+ feature.
  
- By running udevadm test, we can see the conflicting ens3 name comes from
- netplan's /run/udev/rules.d/99-netplan-ens3.rules
+ * When so configured, the netplan configuration generated by initramfs
+ will not contain a "macaddress:" match directive for the network
+ interface in question.
  
- vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
- SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
+ [Regression Potential]
  
- vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add" 
/sys/class/net/eth0
- calling: test
- version 237
- This program is for debugging only, it does not run any program
- specified by a RUN key. It may show incorrect results, because
- some values may be different, or not available at a simulation run.
- 
- Load module index
- Parsed configuration file /lib/systemd/network/99-default.link
- Parsed configuration file /run/systemd/network/10-netplan-ens3.link
- Created link configuration context.
- Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
- ..
- Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
- rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
- 25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie 
nodes 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

2020-08-12 Thread Andreas Hasenack
** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
  
  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
  
  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
- This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded, there will be a /e/d/motd-news.wasremoved leftover 
empty file (see "other info" below for details).
+ This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded and /e/d/motd-news was manually removed by the user, 
there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" 
below for details).
  
  In general, the regression risks here are:
  - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
  - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
  - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
  - have some sort of dpkg postinst or dependency error because 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

2020-08-12 Thread Andreas Hasenack
** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
  
  [Regression Potential]
+ This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
+ a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
+ 
+ b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
+ This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded, there will be a /e/d/motd-news.wasremoved leftover 
empty file (see "other info" below for details).
+ 
+ In general, the regression risks here are:
+ - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
+ - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
+ - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
+ - have some sort of dpkg postinst or dependency error because of unpredicted 
scenarios. Certain assumptions are being made, like the renames that 
dpkg-maintscript-helper does, and that the filename 
/etc/default/motd-news.wasremoved that I'm touching and verifying is really 
mine and not something that was there already.
+ - the versions I'm breaking/replacing on, and using rm_conffiles 

[Touch-packages] [Bug 1878519] Re: Unable to use TLSv1.1 to connect to external servers

2020-08-12 Thread Andrea Giudiceandrea
See
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1864689/comments/13
for a workaround.

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

Title:
  Unable to use TLSv1.1 to connect to external servers

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  I'm on 20.04 LTS (Focal Fossa). (Kubuntu)

  openssl (I'm on 1.1.1f-1ubuntu2) appears to now be set to use a
  minimum of TLSv1.2

  This is despite the fact that the Changelog 
(https://launchpad.net/ubuntu/+source/openssl/+changelog) says:
Revert "Enable system default config to enforce TLS1.2 as a
minimum" & "Increase default security level from 1 to 2".

  As a result of this I can't get fetchmail to connect to an external
  IMPA server I use, which only uses TLSv1.1

  I *can* get:
openssl s_client -state -cipher "DEFAULT:@SECLEVEL=1" -connect ... 
-starttls imap
  to open a connexion, but I can find no way of getting that option into a 
configuration file such that it is used.

  Consequently I cannot use a secure connexion to retrieve my emails.

  All was fine in 19.10.

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

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


[Touch-packages] [Bug 1878519] Re: Unable to use TLSv1.1 to connect to external servers

2020-08-12 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

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

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

Title:
  Unable to use TLSv1.1 to connect to external servers

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  I'm on 20.04 LTS (Focal Fossa). (Kubuntu)

  openssl (I'm on 1.1.1f-1ubuntu2) appears to now be set to use a
  minimum of TLSv1.2

  This is despite the fact that the Changelog 
(https://launchpad.net/ubuntu/+source/openssl/+changelog) says:
Revert "Enable system default config to enforce TLS1.2 as a
minimum" & "Increase default security level from 1 to 2".

  As a result of this I can't get fetchmail to connect to an external
  IMPA server I use, which only uses TLSv1.1

  I *can* get:
openssl s_client -state -cipher "DEFAULT:@SECLEVEL=1" -connect ... 
-starttls imap
  to open a connexion, but I can find no way of getting that option into a 
configuration file such that it is used.

  Consequently I cannot use a secure connexion to retrieve my emails.

  All was fine in 19.10.

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

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


[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

2020-08-12 Thread Andreas Hasenack
** Description changed:

- The motd-news script is largely useless for desktop users, as they
- rarely login via a text console. It makes more sense for server users.
+ [Impact] 
+ The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a NEW package 
(motd-news-config)
  - have ubuntu-server depend on motd-news-config (or recommends)
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends (or recommends) on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
+ 
+ [Test Case]
+ a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
+ apt install base-files
+ - upgrades ubuntu-server
+ - installs motd-news-config
+ - /e/d/motd-news remains, motd-news remains enabled
+ 
+ b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
+ apt install base-files
+ - upgrades ubuntu-server
+ - installs motd-news-config
+ - /e/d/motd-news remains with the original modification
+ 
+ c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
+ apt install base-files
+ - upgrades base-files
+ - removes /e/d/motd-news
+ - motd-news is disabled
+ 
+ d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
+ apt install base-files
+ - upgrades base-files
+ - /e/d/motd-news gets renamed to backup
+ - motd-news is disabled
+ 
+ e) removing motd-news-config will also remove ubuntu-server (since it's
+ a depends, and not a recommends)
+ 
+ f) upgrading just ubuntu-server should pull motd-news-config in, and
+ force-upgrade base-files
+ 
+ g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
+ news-server removes the /e/d/motd-news config file
+ 
+ h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
+ - apt install base-files
+ - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
+ - /e/d/motd-news is installed with ENABLED=0
+ 
+ i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
+ - apt install base-files
+ - base-files is upgraded
+ - no /e/d/motd-news is installed, motd-news remains disabled
+ 
+ [Regression Potential]
+ 
+ 
+ [Other Info]
+ 
+ Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved 
file, created by the base-files postinst. This file is removed by the 
motd-news-config postinst, but since that package doesn't get installed in that 
particular scenario, the file remains. I toyed with the idea of adding an extra 
check to base-file's postinst, like this:
+ --- a/debian/postinst.in
+ +++ b/debian/postinst.in
+ @@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
+  if [ ! -e ${motd_news_config} ]; then
+if [ ! -e ${motd_news_config}.dpkg-remove ]; then
+  if [ ! -e ${motd_news_config}.dpkg-backup ]; then
+ -  touch ${motd_news_config}.wasremoved
+ +  # The .wasremoved file only matters if ubuntu-server is installed,
+ +  # because that's what will pull in motd-news-config
+ +  if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ +touch ${motd_news_config}.wasremoved
+ +  fi
+  fi
+fi
+  fi
+ 
+ But deemed it too risky, and not worth further potential regressions.

** Description changed:

- [Impact] 
+ [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
- - move /etc/default/motd-news from base-files into a NEW package 
(motd-news-config)
- - have ubuntu-server depend on motd-news-config (or recommends)
- - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends (or recommends) on motd-news-config
+ - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
+ - have ubuntu-server depend on motd-news-config
+ - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on 

[Touch-packages] [Bug 1861451] Re: apport's cloud-init-specific handling tracebacks on minimal cloud images

2020-08-12 Thread Brian Murray
** Description changed:

- Steps to reproduce:
+ Impact
+ --
+ It is not possible to run ubuntu-bug for some packages which gather 
information as root because pkexec does not work in non-graphical environments 
(LP: #1821415). This was worked around in Ubuntu 19.10 by not gathering any 
information that would require root access.
+ 
+ 
+ Test Case
+ -
  
  1) Install multipass.
  2) `multipass launch 
http://cloud-images.ubuntu.com/minimal/daily/bionic/current/bionic-minimal-cloudimg-amd64.img
 -n reproducer`
  3) `multipass shell reproducer`
  4) `ubuntu-bug cloud-init`
  
  Expected behaviour:
  
  Usual bug reporting flow (though, currently, I would really expect to
  see just the issue reported in bug 1861450).
  
  Actual behaviour:
  
  ERROR: hook /usr/share/apport/package-hooks/cloud-init.py crashed:
  Traceback (most recent call last):
-   File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in 
_run_hook
- symb['add_info'](report, ui)
-   File "/usr/share/apport/package-hooks/cloud-init.py", line 6, in add_info
- return cloudinit_add_info(report, ui)
-   File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 123, in 
add_info
- attach_cloud_init_logs(report, ui)
-   File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 57, in 
attach_cloud_init_logs
- 'cloud-init-output.log.txt': 'cat /var/log/cloud-init-output.log'})
-   File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 444, in 
attach_root_command_outputs
- sp = subprocess.Popen(_root_command_prefix() + [wrapper_path, 
script_path])
-   File "/usr/lib/python3.6/subprocess.py", line 729, in __init__
- restore_signals, start_new_session)
-   File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
- raise child_exception_type(errno_num, err_msg, err_filename)
+   File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in 
_run_hook
+ symb['add_info'](report, ui)
+   File "/usr/share/apport/package-hooks/cloud-init.py", line 6, in add_info
+ return cloudinit_add_info(report, ui)
+   File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 123, in 
add_info
+ attach_cloud_init_logs(report, ui)
+   File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 57, in 
attach_cloud_init_logs
+ 'cloud-init-output.log.txt': 'cat /var/log/cloud-init-output.log'})
+   File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 444, in 
attach_root_command_outputs
+ sp = subprocess.Popen(_root_command_prefix() + [wrapper_path, 
script_path])
+   File "/usr/lib/python3.6/subprocess.py", line 729, in __init__
+ restore_signals, start_new_session)
+   File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
+ raise child_exception_type(errno_num, err_msg, err_filename)
  FileNotFoundError: [Errno 2] No such file or directory: 'pkexec': 'pkexec'
  
  (As alluded to above, this also demonstrates bug 1861450 after the
  traceback is emitted.)
+ 
+ Regression Potential
+ 
+ None as we are just returning and empty list if pkexec is not available.

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

Title:
  apport's cloud-init-specific handling tracebacks on minimal cloud
  images

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Focal:
  Invalid

Bug description:
  Impact
  --
  It is not possible to run ubuntu-bug for some packages which gather 
information as root because pkexec does not work in non-graphical environments 
(LP: #1821415). This was worked around in Ubuntu 19.10 by not gathering any 
information that would require root access.

  
  Test Case
  -

  1) Install multipass.
  2) `multipass launch 
http://cloud-images.ubuntu.com/minimal/daily/bionic/current/bionic-minimal-cloudimg-amd64.img
 -n reproducer`
  3) `multipass shell reproducer`
  4) `ubuntu-bug cloud-init`

  Expected behaviour:

  Usual bug reporting flow (though, currently, I would really expect to
  see just the issue reported in bug 1861450).

  Actual behaviour:

  ERROR: hook /usr/share/apport/package-hooks/cloud-init.py crashed:
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in 
_run_hook
  symb['add_info'](report, ui)
    File "/usr/share/apport/package-hooks/cloud-init.py", line 6, in add_info
  return cloudinit_add_info(report, ui)
    File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 123, in 
add_info
  attach_cloud_init_logs(report, ui)
    File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 57, in 
attach_cloud_init_logs
  'cloud-init-output.log.txt': 'cat /var/log/cloud-init-output.log'})
    File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 444, in 

[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

2020-08-12 Thread Gianfranco Costamagna
I'm marking isc-dhcp tasks as invalid!

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

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  Invalid
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  Invalid

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

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

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


[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

2020-08-12 Thread Gianfranco Costamagna
I uploaded in groovy (sorry, I didn't find the debdiff and it was
partially wrong) and focal for review.

** Changed in: isc-dhcp (Ubuntu Focal)
   Status: In Progress => Invalid

** Changed in: isc-dhcp (Ubuntu Groovy)
   Status: In Progress => Incomplete

** Changed in: isc-dhcp (Ubuntu Groovy)
   Status: Incomplete => Invalid

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

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  Invalid
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  Invalid

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

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

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


[Touch-packages] [Bug 1890716] Re: xdg-mime query filetype index.html reports wrong type

2020-08-12 Thread Alex A. D.
why did you tag the report*

Bump.

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

Title:
  xdg-mime query filetype index.html reports wrong type

Status in shared-mime-info package in Ubuntu:
  Invalid

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+subscriptions

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


[Touch-packages] [Bug 1890716] Re: xdg-mime query filetype index.html reports wrong type

2020-08-12 Thread Alex A. D.
Hi Sebastien. Thaks your for your reply.

I suggest you to do the following to see that even if file is starting
with proper tags it is recognized as `application/x-perl`:

$ tee "index.html" <
use strict
eol

$ xdg-mime query filetype index.html # -> application/x-perl - wrong
type

Why did you tagged report as invalid? 
I just got a file with minified JS code which has `use strict` burrowed deep 
somewhere inside correct html file but it's still recognized as perl script.

I can't use some tools to open the file in browser by using xdg-open and
forced to use browser-specific launcher.

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

Title:
  xdg-mime query filetype index.html reports wrong type

Status in shared-mime-info package in Ubuntu:
  Invalid

Bug description:
  For .html files `xdg-mime` reports wrong type. The culprit is the
  `"use strict"` phrase which is used in JavaScript. It should not
  mistake .html files for anything else except of text/html !

  STEPS TO REPRODUCE:
  Run the following step by step in any folder:
  1. $ echo "\"use strict\"" > index.html
  2. $ xdg-mime query filetype index.html # -> application/x-perl - this should 
be text/html!

  Platform:
  Ubuntu 20.04.1 LTS (Focal Fossa)"
  Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2))

  xdg-utils: 1.1.3-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+subscriptions

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


[Touch-packages] [Bug 1838258] Re: Unable to configure VLAN on an additional OSA interface

2020-08-12 Thread Dimitri John Ledkov
It is unclear how to reproduce the issue.

So far, I always have multiple VLANs configured and accessible. The only
time I see errors similar to the ones from the reporter, is when the
same vlan with the same name is configured multiple times in a row
(which is an input/configuration error)

This bug will autoclose, unless better details are provided about the
initial state of the machine / cards, current and prior VLAN
configuration attempts. So far I cannot detect invalid behaviour, and
the only errors that are produced are correct (i.e. when attempting to
create a duplicate interface name)

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

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

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

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

Title:
  Unable to configure VLAN on an additional OSA interface

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in iproute2 package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  After installing a base Ubuntu 18.04.1 server, an additional OSA device 
"e530" is attached and configured with chzdev. Then a VLAN configuration should 
be applied using the ip command.
  However this results in the error message "RTNETLINK answers: File exists". 

  >snip
  ip link add link ence530 name ence530.209 type vlan id 209
  RTNETLINK answers: File exists
  snip<

  Executing the same steps on an Ubuntu 16.04.5 server, the ip command
  finishes without an error message but the VLAN interface is also not
  configured.

  Reproduction:

  - Install a 18.04.1 server
  - attach an additional OSA interface
  - configure a VLAN using the ip command

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

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


[Touch-packages] [Bug 1891358] [NEW] systemd not respecting EXTEND_TIMEOUT_USEC when stopping service

2020-08-12 Thread Adrian Barkus
Public bug reported:

It seems like systemd is not consistently respecting
EXTEND_TIMEOUT_USEC. When I stop a service, it is being killed
prematurely even after EXTEND_TIMEOUT_USEC was recently sent to systemd
(however it is not killed immediately after the default TimeoutStopSec
either).

The service `ihm-eco-sputnik-agent.service` includes the following
configuration:

  [Service]
  Restart=always
  RestartSec=5
  Type=notify
  TimeoutStartSec=10
  WatchdogSec=60
  TimeoutStopSec=60
  KillMode=mixed
  ...

When I `systemctl restart ihm-eco-sputnik-agent.service`, I see the
following logs in `journalctl`:

```
Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Trying 
to enqueue job ihm-eco-sputnik-agent.service/restart/replace
Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: 
Installed new job ihm-eco-sputnik-agent.service/restart as 1149303
Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: 
Enqueued job ihm-eco-sputnik-agent.service/restart as 1149303
Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Changed 
running -> stop-sigterm
Aug 12 15:43:59 00044bcbe9bc systemd[1]: Stopping ihm-eco
sputnik-agent...
-- Subject: Unit ihm-eco-sputnik-agent.service has begun shutting down
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- Unit ihm-eco-sputnik-agent.service has begun shutting down.
Aug 12 15:44:49 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got 
notification message from PID 19520 (WATCHDOG=1)
Aug 12 15:44:49 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got 
notification message from PID 19520 (EXTEND_TIMEOUT_USEC=6000)
Aug 12 15:45:09 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got 
notification message from PID 19520 (WATCHDOG=1)
Aug 12 15:45:09 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got 
notification message from PID 19520 (EXTEND_TIMEOUT_USEC=6000)
Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: State 
'stop-sigterm' timed out. Killing.
Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Killing 
process 19520 (ihm-eco-sputnik) with signal SIGKILL.
Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Killing 
process 21114 (systemctl) with signal SIGKILL.
Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Killing 
process 2 (200_IhmEcoDeplo) with signal SIGKILL.
Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Main 
process exited, code=killed, status=9/KILL
```

I'm not sure if this is related but I'm also seeing the application
successfully writing notification messages which systemd apparently
doesn't receive (they aren't logged).

lsb_release -rd:
```
Description:Ubuntu 18.04.5 LTS
Release:18.04
```

apt-cache policy systemd:
```
systemd:
  Installed: 237-3ubuntu10.42
  Candidate: 237-3ubuntu10.42
  Version table:
 *** 237-3ubuntu10.42 500
500 
s3://ihm-eco-apt-repository-us-west-2.s3-accelerate.amazonaws.com/ihm-eco-apt-repository-us-west-2
 bionic-20200810/ubuntu arm64 Packages
100 /var/lib/dpkg/status
```

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

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

Title:
  systemd not respecting EXTEND_TIMEOUT_USEC when stopping service

Status in systemd package in Ubuntu:
  New

Bug description:
  It seems like systemd is not consistently respecting
  EXTEND_TIMEOUT_USEC. When I stop a service, it is being killed
  prematurely even after EXTEND_TIMEOUT_USEC was recently sent to
  systemd (however it is not killed immediately after the default
  TimeoutStopSec either).

  The service `ihm-eco-sputnik-agent.service` includes the following
  configuration:

[Service]
Restart=always
RestartSec=5
Type=notify
TimeoutStartSec=10
WatchdogSec=60
TimeoutStopSec=60
KillMode=mixed
...

  When I `systemctl restart ihm-eco-sputnik-agent.service`, I see the
  following logs in `journalctl`:

  ```
  Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: 
Trying to enqueue job ihm-eco-sputnik-agent.service/restart/replace
  Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: 
Installed new job ihm-eco-sputnik-agent.service/restart as 1149303
  Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: 
Enqueued job ihm-eco-sputnik-agent.service/restart as 1149303
  Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: 
Changed running -> stop-sigterm
  Aug 12 15:43:59 00044bcbe9bc systemd[1]: Stopping ihm-eco
  sputnik-agent...
  -- Subject: Unit ihm-eco-sputnik-agent.service has begun shutting down
  -- Defined-By: systemd
  -- Support: http://www.ubuntu.com/support
  --
  -- Unit 

[Touch-packages] [Bug 1771041] Re: Remove gconf from Ubuntu

2020-08-12 Thread Sebastien Bacher
the package has been removed from the archive which resolves the issue

** Changed in: evolution-indicator (Ubuntu)
   Status: New => Fix Released

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

Title:
  Remove gconf from Ubuntu

Status in desktopnova package in Ubuntu:
  New
Status in evolution-indicator package in Ubuntu:
  Fix Released
Status in gconf package in Ubuntu:
  New
Status in gconf-editor package in Ubuntu:
  New
Status in gkdebconf package in Ubuntu:
  New
Status in gnome-mastermind package in Ubuntu:
  New
Status in gnome-phone-manager package in Ubuntu:
  New
Status in gnome-xcf-thumbnailer package in Ubuntu:
  New
Status in gnomint package in Ubuntu:
  New
Status in gtkwave package in Ubuntu:
  Fix Released
Status in guake-indicator package in Ubuntu:
  New
Status in gyrus package in Ubuntu:
  Fix Released
Status in jack-mixer package in Ubuntu:
  Fix Committed
Status in jana package in Ubuntu:
  New
Status in mssh package in Ubuntu:
  New
Status in ogmrip package in Ubuntu:
  New
Status in ooo-thumbnailer package in Ubuntu:
  New
Status in planner package in Ubuntu:
  New
Status in ogmrip package in Debian:
  Confirmed

Bug description:
  gconf is being removed from Debian Testing. We should remove it from
  Ubuntu also.

  eclipse is troublesome. At a minimum, we can remove everything but
  eclipse and gconf.

  libgnome is sort of a blocker so do it first LP: #1771031
  And remove libqt-gconf LP: #1740538

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

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


[Touch-packages] [Bug 1890286] Re: ansi escape sequence injection in add-apt-repository

2020-08-12 Thread Jason A. Donenfeld
You might be right that the remaining ones that slip through your regex
are mere "nuisance"s. But you know how those things go - one man's
nuisance is another man's vuln. Some of those, anyhow, are implemented
by the Linux console driver.

Why not just take the tried and true "safe" route, as implemented by
vis(3)'s VIS_SAFE or similar? Otherwise it sounds like you're playing
with a bit of fire.

Put differently, is there some legitimate use case of the ANSI escape
characters that make you want to preserve some of their usage while
disallowing other parts? If so, that would really surprise me.

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

Title:
  ansi escape sequence injection in add-apt-repository

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:
  This was reported to oss-security and to secur...@ubuntu.com, but I
  figure I should make a real bug report, as otherwise it'll probably be
  missed. Original post from https://www.openwall.com/lists/oss-
  security/2020/08/03/1 follows below.

  --

  Hi,

  I've found a rather low grade concern: I'm able to inject ANSI escape
  sequences into PPA descriptions on Launchpad, and then have them
  rendered by add-apt-repository *before* the user consents to actually
  adding that repository. There might be some sort of trust barrier
  issue with that. This could be used to clear the screen and imitate a
  fresh bash prompt, upload files, dump the current screen to a file, or
  other classic shenanigans, well chronicled in the archives of oss-sec.

  PoC time -- I'm using this "feature" for good at the moment to
  announce the deprecation in bold text of a PPA that I maintain:
  https://data.zx2c4.com/add-apt-repository-ansi-injection.png

  The proper fix to this is likely to do sanitization on the
  add-apt-repository side.

  Regards,
  Jason

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

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


[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-08-12 Thread Seth Forshee
** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

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

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

Title:
  bcache by-uuid links disappear after mounting bcache0

Status in bcache-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Released
Status in bcache-tools source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Won't Fix
Status in bcache-tools source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  In Progress

Bug description:
  SRU TEAM: The last 2 commits show a summary for the merges/changes
  I added some specific (to Bionic) notes in the template.
  Thanks!

  [Impact]

   * bcache-tools udev created symlinks might disappear when other udev
  events are processed for the same devices.

   * after mkfs.XXX in /dev/bcacheY you might face a condition where
  /dev/bcache/by-{uuid,label}/zzz symlinks are gone.

   * /dev/bcache/by-{uuid,label}/ symlinks are important so bcache
  devices can be addressed by their UUIDs and not the ordering they were
  assembled (MAAS depends on this feature, for example).

   * it was also discussed in this bug that systemd-udev should *not*
  populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
  backing devices. this was turned into a discussion whether blkid
  should report those or not, and this discussion "died" after sometime.
  This last item is what the systemd update is all about: to disallow
  /dev/disk/by-XXX/ creation for bcache backing devices (a simple
  change that will reduce end users confusion).

  [Test Case]

   * The reproducer script is here:

     https://paste.ubuntu.com/p/37KGy2Smnp/

   * Bionic can't reproduce the issue with the 18.04 kernel, nor with
  the HWE kernel. Nevertheless, it is preferable that Bionic also do the
  same thing: to read bcache superblock and feed environment for
  /dev/bcache/by-{uuid,label} symlinks creation.

  [Regression Potential]

   * We are not depending on bcache device udev events any more when
  creating the /dev/bcache/by-{uuid,label}/ symlinks. Instead, we are
  depending on a wrapper script that heads bcache device superblock. If
  there is a bug in this wrapper the symlinks wouldn't work.

   * Previously we were thinking in asking the kernel team to remove the
  bcache udev event delta script they've done for previous case (LP:
  #1729145). It creates the udev events that were being read and filling
  the symlinks. We decided not to remove those (just from Groovy and on)
  so we don't need to worry on Breaks/Conflicts in between the kernel
  package and bcache-tools (and udev)).

   * Long story short: kernel will continue to emit bcache udev events
  as it did previously but now those events won't be used by anything -
  after installing this SRU - because udev wrapper script is doing this
  job (and doing it properly)

  [Other Info]

  - Original Description:

  1.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  2.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04
  root@ubuntu:~# apt-cache policy linux-image-virtual
  linux-image-virtual:
    Installed: 5.4.0.12.15
    Candidate: 5.4.0.12.15
    Version table:
   *** 5.4.0.12.15 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
  linux-image-5.4.0-12-generic:
    Installed: 5.4.0-12.15
    Candidate: 5.4.0-12.15
    Version table:
   *** 5.4.0-12.15 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/
  + ls -al /dev/bcache/by-uuid/
  total 0
  drwxr-xr-x 2 root root 60 Feb  4 23:31 .
  drwxr-xr-x 3 root root 60 Feb  4 23:31 ..
  lrwxrwxrwx 1 root root 13 Feb  4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a 
-> ../../bcache0

  4.
  root@ubuntu:~# ls -al /dev/bcache/by-uuid
  ls: cannot access '/dev/bcache/by-uuid': No such file or directory

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-12-generic 5.4.0-12.15
  ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
  Uname: Linux 5.4.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  Date: Tue Feb  4 23:31:52 2020
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: linux-signed-5.4
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:

[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces

2020-08-12 Thread Guilherme G. Piccoli
** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

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

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

** Also affects: netplan.io (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Bionic)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Bionic)
 Assignee: Guilherme G. Piccoli (gpiccoli) => Jay Vosburgh (jvosburgh)

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

Title:
  netplan should consider adding more udev attribute for exact matching
  of failover 3-netdev interfaces

Status in netplan:
  Triaged
Status in initramfs-tools package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Incomplete
Status in initramfs-tools source package in Bionic:
  In Progress
Status in netplan.io source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  This bug is a follow-up to

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268

  after applying the 0001-net_failover-delay-taking-over-primary-device-
  to-acc.patch attached in that bug, the VF interface "eth0" is renamed
  to "rename4" instead of "ens4". Log is showing that attempt to rename
  "eth0" to "ens3" failed because of conflict with existing name, so
  that's why it ends up with rename4.

  vsbalakr@ubuntu-18:~$ uname -a
  Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
  vsbalakr@ubuntu-18:~$ ip l 
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
  2: ens3:  mtu 1500 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff 
  3: ens3nsby:  mtu 1500 qdisc pfifo_fast 
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether 
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff 
  4: rename4:  mtu 1500 qdisc mq master ens3 
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff

  vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
  ...
  Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): carrier: link connected
  Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): enslaved to non-master-type device ens3; ignoring
  Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface 
name 'eth0' to 'ens3': Device or resource busy
  Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4' 
from 'eth0' to 'ens3': Device or resource busy

  Within VM there's netplan config as below:

  vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
  # This file describes the network interfaces available on your system
  # For more information, see netplan(5).
  network:
version: 2
renderer: networkd
ethernets:
  ens3:
dhcp4: yes
gateway4: 10.211.8.1
nameservers:
addresses: [10.211.11.1,10.209.76.197]

  By running udevadm test, we can see the conflicting ens3 name comes
  from netplan's /run/udev/rules.d/99-netplan-ens3.rules

  vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"

  vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add" 
/sys/class/net/eth0
  calling: test
  version 237
  This program is for debugging only, it does not run any program
  specified by a RUN key. It may show incorrect results, because
  some values may be different, or not available at a simulation run.

  Load module index
  Parsed configuration file /lib/systemd/network/99-default.link
  Parsed configuration file /run/systemd/network/10-netplan-ens3.link
  Created link configuration context.
  Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
  ..
  Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
  rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
  25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie 
nodes used
  RUN '/lib/open-iscsi/net-interface-handler start' 
/lib/udev/rules.d/70-iscsi-network-interface.rules:2
  IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.rules:6
  IMPORT builtin 'hwdb' /lib/udev/rules.d/75-net-description.rules:12
  RUN 'ifupdown-hotplug' 

[Touch-packages] [Bug 1890286] Re: ansi escape sequence injection in add-apt-repository

2020-08-12 Thread Marc Deslauriers
Hi,

Could you elaborate which codes in that manpage you feel are dangerous
and are actually implemented by the common terminals? The old screendump
and window title codes were disabled long ago, I'm not sure any of the
others are anything other than a nuisance.

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

Title:
  ansi escape sequence injection in add-apt-repository

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:
  This was reported to oss-security and to secur...@ubuntu.com, but I
  figure I should make a real bug report, as otherwise it'll probably be
  missed. Original post from https://www.openwall.com/lists/oss-
  security/2020/08/03/1 follows below.

  --

  Hi,

  I've found a rather low grade concern: I'm able to inject ANSI escape
  sequences into PPA descriptions on Launchpad, and then have them
  rendered by add-apt-repository *before* the user consents to actually
  adding that repository. There might be some sort of trust barrier
  issue with that. This could be used to clear the screen and imitate a
  fresh bash prompt, upload files, dump the current screen to a file, or
  other classic shenanigans, well chronicled in the archives of oss-sec.

  PoC time -- I'm using this "feature" for good at the moment to
  announce the deprecation in bold text of a PPA that I maintain:
  https://data.zx2c4.com/add-apt-repository-ansi-injection.png

  The proper fix to this is likely to do sanitization on the
  add-apt-repository side.

  Regards,
  Jason

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

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


[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-08-12 Thread Robie Basak
Hello Ryan, or anyone else affected,

Accepted bcache-tools into bionic-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/bcache-
tools/1.0.8-2ubuntu0.18.04.1 in a few hours, and then in the -proposed
repository.

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

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

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

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

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

** Tags added: verification-needed-bionic

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

Title:
  bcache by-uuid links disappear after mounting bcache0

Status in bcache-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in bcache-tools source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Won't Fix
Status in bcache-tools source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  In Progress

Bug description:
  SRU TEAM: The last 2 commits show a summary for the merges/changes
  I added some specific (to Bionic) notes in the template.
  Thanks!

  [Impact]

   * bcache-tools udev created symlinks might disappear when other udev
  events are processed for the same devices.

   * after mkfs.XXX in /dev/bcacheY you might face a condition where
  /dev/bcache/by-{uuid,label}/zzz symlinks are gone.

   * /dev/bcache/by-{uuid,label}/ symlinks are important so bcache
  devices can be addressed by their UUIDs and not the ordering they were
  assembled (MAAS depends on this feature, for example).

   * it was also discussed in this bug that systemd-udev should *not*
  populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
  backing devices. this was turned into a discussion whether blkid
  should report those or not, and this discussion "died" after sometime.
  This last item is what the systemd update is all about: to disallow
  /dev/disk/by-XXX/ creation for bcache backing devices (a simple
  change that will reduce end users confusion).

  [Test Case]

   * The reproducer script is here:

     https://paste.ubuntu.com/p/37KGy2Smnp/

   * Bionic can't reproduce the issue with the 18.04 kernel, nor with
  the HWE kernel. Nevertheless, it is preferable that Bionic also do the
  same thing: to read bcache superblock and feed environment for
  /dev/bcache/by-{uuid,label} symlinks creation.

  [Regression Potential]

   * We are not depending on bcache device udev events any more when
  creating the /dev/bcache/by-{uuid,label}/ symlinks. Instead, we are
  depending on a wrapper script that heads bcache device superblock. If
  there is a bug in this wrapper the symlinks wouldn't work.

   * Previously we were thinking in asking the kernel team to remove the
  bcache udev event delta script they've done for previous case (LP:
  #1729145). It creates the udev events that were being read and filling
  the symlinks. We decided not to remove those (just from Groovy and on)
  so we don't need to worry on Breaks/Conflicts in between the kernel
  package and bcache-tools (and udev)).

   * Long story short: kernel will continue to emit bcache udev events
  as it did previously but now those events won't be used by anything -
  after installing this SRU - because udev wrapper script is doing this
  job (and doing it properly)

  [Other Info]

  - Original Description:

  1.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  2.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04
  root@ubuntu:~# apt-cache policy linux-image-virtual
  linux-image-virtual:
    Installed: 5.4.0.12.15
    Candidate: 5.4.0.12.15
    Version table:
   *** 5.4.0.12.15 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  root@ubuntu:~# apt-cache policy 

[Touch-packages] [Bug 1891196] Re: FTBFS because of porefs=noline, wrap is unrecognized

2020-08-12 Thread Lukas Märdian
** Changed in: sensible-utils (Ubuntu)
   Status: New => Fix Committed

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

Title:
  FTBFS because of porefs=noline,wrap is unrecognized

Status in sensible-utils package in Ubuntu:
  Fix Committed
Status in sensible-utils package in Debian:
  Fix Released

Bug description:
  THe porefs value needs to be changed from 'noline,wrap' to 'noline'.

  This will be solved with 'sensible-utils 0.0.13', currently in Debian
  experimental.

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

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


[Touch-packages] [Bug 1576559] Re: Refused to switch profile to headset_head_unit: Not connected

2020-08-12 Thread Timothy Clarke
For those approaching the issue from afresh it looks like HSP/HFP shares
functionality with bluetooth modems rather than solely audio. As such
there's a disagreement between pulseaudio who are only interested in the
audio parts, ofono who deals with the modem parts and the bluetooth
stack (bluez) who connect the to the hardware.

The issue came about as support was dropped (assuming someone else would
pick it up) as pulse audio and bluez went to later versions. It hasn't
been resolved because no one wants to ether deal with the other part, or
have another abstraction layer to switch between modem and audio
functionality

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

Title:
  Refused to switch profile to headset_head_unit: Not connected

Status in PulseAudio:
  Unknown
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to connect a bluetooth-speaker-with-microphone (Mi
  Bluetooth Speaker) to Ubuntu. It works well as an A2DP sync, but can't
  use it as a headset with microphone.

  The device doesn't list in the "Input Devices" by default, and using
  the sound settings to change the profile of the device to HSP/HFP
  results in this log message:

  W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to
  headset_head_unit: Not connected

  
  I'm running Ubuntu 16.04 LTS. I did an upgrade from Ubuntu 15.10.

  pulseaudio:
Installed: 1:8.0-0ubuntu3

  bluez:
Installed: 5.37-0ubuntu5

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

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


[Touch-packages] [Bug 1890286] Re: ansi escape sequence injection in add-apt-repository

2020-08-12 Thread Jason A. Donenfeld
I'm not convinced that really cuts it. Namely, from the diff:

-print(" %s" % (info["description"] or ""))
+# strip ANSI escape sequences
+description = re.sub(r"(\x9B|\x1B\[)[0-?]*[ -/]*[@-~]",
+ "", info["description"] or "")
+
+print(" %s" % description)

There are sequences that don't get filtered by that. Aside from the
usual things like \r or \b, it looks like https://man7.org/linux/man-
pages/man4/console_codes.4.html lists a few codes that defy it too.
While that diff above might be the "stackoverflow answer", it doesn't
seem complete.

Instead, why not just adopt a whitelist policy? Only allow visible and
space characters, or something like that.

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

Title:
  ansi escape sequence injection in add-apt-repository

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:
  This was reported to oss-security and to secur...@ubuntu.com, but I
  figure I should make a real bug report, as otherwise it'll probably be
  missed. Original post from https://www.openwall.com/lists/oss-
  security/2020/08/03/1 follows below.

  --

  Hi,

  I've found a rather low grade concern: I'm able to inject ANSI escape
  sequences into PPA descriptions on Launchpad, and then have them
  rendered by add-apt-repository *before* the user consents to actually
  adding that repository. There might be some sort of trust barrier
  issue with that. This could be used to clear the screen and imitate a
  fresh bash prompt, upload files, dump the current screen to a file, or
  other classic shenanigans, well chronicled in the archives of oss-sec.

  PoC time -- I'm using this "feature" for good at the moment to
  announce the deprecation in bold text of a PPA that I maintain:
  https://data.zx2c4.com/add-apt-repository-ansi-injection.png

  The proper fix to this is likely to do sanitization on the
  add-apt-repository side.

  Regards,
  Jason

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

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


[Touch-packages] [Bug 1891342] [NEW] network manager does not auto connect to hidden wifi networks

2020-08-12 Thread PC
Public bug reported:

Environment:
Fresh installation of Lubuntu 20.04 (it also occurs in a fresh installation of 
Ubuntu 20.04)

Steps to reproduce the situation:
1) Lubuntu -> Network Manager -> Edit Connections -> Add SSID of a hidden WiFi 
network
2) Network Manager does not connect automatically with the hidden Wifi Network

However, once the WiFi network SSID is set to broadcast mode, it starts
connecting automatically.

The workaround suggested in Bug 1542733 works here.
https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1542733

However, it was suggested to create a new bug report for later releases.
Please provide your assistance. Thank you.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: network-manager 1.22.10-1ubuntu2.1
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.11-0ubuntu27.6
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: LXQt
Date: Wed Aug 12 20:11:18 2020
InstallationDate: Installed on 2020-08-09 (3 days ago)
InstallationMedia: Lubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
IpRoute:
 default via 192.168.29.1 dev wlp2s0 proto dhcp metric 600 
 192.168.29.0/24 dev wlp2s0 proto kernel scope link src 192.168.29.22 metric 600
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-dev:
 DEVICE  TYPE  STATEIP4-CONNECTIVITY  IP6-CONNECTIVITY  DBUS-PATH   
   CONNECTION  CON-UUID 
 CON-PATH   
 wlp2s0  wifi  connectedfull  full  
/org/freedesktop/NetworkManager/Devices/3  PCWiFi  
9a5f3d88-a43e-4862-9cac-b65102e9e135  
/org/freedesktop/NetworkManager/ActiveConnection/1 
 enp3s0  ethernet  unavailable  none  none  
/org/freedesktop/NetworkManager/Devices/2  --  --   
 -- 
 lo  loopback  unmanagedunknown   unknown   
/org/freedesktop/NetworkManager/Devices/1  --  --   
 --
nmcli-nm:
 RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  WIFI  
   WWAN-HW  WWAN
 running  1.22.10  connected  started  full  enabled enabled  
enabled  enabled  enabled

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


** Tags: amd64 apport-bug focal

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

Title:
  network manager does not auto connect to hidden wifi networks

Status in network-manager package in Ubuntu:
  New

Bug description:
  Environment:
  Fresh installation of Lubuntu 20.04 (it also occurs in a fresh installation 
of Ubuntu 20.04)

  Steps to reproduce the situation:
  1) Lubuntu -> Network Manager -> Edit Connections -> Add SSID of a hidden 
WiFi network
  2) Network Manager does not connect automatically with the hidden Wifi Network

  However, once the WiFi network SSID is set to broadcast mode, it
  starts connecting automatically.

  The workaround suggested in Bug 1542733 works here.
  https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1542733

  However, it was suggested to create a new bug report for later releases.
  Please provide your assistance. Thank you.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: network-manager 1.22.10-1ubuntu2.1
  ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu27.6
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: LXQt
  Date: Wed Aug 12 20:11:18 2020
  InstallationDate: Installed on 2020-08-09 (3 days ago)
  InstallationMedia: Lubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 
(20200731)
  IpRoute:
   default via 192.168.29.1 dev wlp2s0 proto dhcp metric 600 
   192.168.29.0/24 dev wlp2s0 proto kernel scope link src 192.168.29.22 metric 
600
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)
  nmcli-dev:
   DEVICE  TYPE  STATEIP4-CONNECTIVITY  IP6-CONNECTIVITY  DBUS-PATH 
 CONNECTION  CON-UUID   
   CON-PATH   
   wlp2s0  wifi  connectedfull  full  
/org/freedesktop/NetworkManager/Devices/3  PCWiFi  
9a5f3d88-a43e-4862-9cac-b65102e9e135  
/org/freedesktop/NetworkManager/ActiveConnection/1 
   enp3s0  ethernet  unavailable  none  none  
/org/freedesktop/NetworkManager/Devices/2  --  --   
 -- 
   lo  

[Touch-packages] [Bug 1856574] Re: removal of various autopilot packages

2020-08-12 Thread Christian Ehrhardt 
still build-depends on python-evdev - we will have to remove autopilot-
gtk as it didn't build for two releases now (F+G).

Fixable with a new upload that resolves the dependency issues.

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

Title:
  removal of various autopilot packages

Status in autopilot-gtk package in Ubuntu:
  Triaged
Status in autopilot-legacy package in Ubuntu:
  Fix Released
Status in python-fixtures package in Ubuntu:
  Fix Released
Status in python-testtools package in Ubuntu:
  Fix Released

Bug description:
  python-fixtures and python-testtools are not built anymore in focal,
  but still referenced by some Ubuntu-only packages.  We need to at
  least remove autopilot-legacy if we don't want to re-introduce those
  package, and modify autopilot-gtk to build witout the autopilot-legacy
  b-d.

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

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


[Touch-packages] [Bug 1281580] Re: glib-compile-schemas doesn't compile relocatable schemas

2020-08-12 Thread Rudra Saraswat
I can confirm that this issue is still present in Ubuntu 20.04.1 Focal
Fossa.

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

Title:
  glib-compile-schemas doesn't compile relocatable schemas

Status in GLib:
  Expired
Status in glib2.0 package in Ubuntu:
  Confirmed

Bug description:
  Dear Developers,

  I am using the Ubuntu 14.04 development release with the GNOME Shell 3.10 
and, because my wife is using this system as well, I defined some settings in a 
gschema.override file.
  Everything is working right, except applying settings related to custom 
key-bindings.

  I added following lines my gschema.override file:
  [org.gnome.settings-daemon.plugins.media-keys]
  www='w'
  email='e'
  custom-keybindings = 
['/org/gnome/settings-daemon/plugins/media-keys/custom-keybinding/custom0']

  
[org.gnome.settings-daemon.plugins.media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/]
  name = 'Launch Gedit'
  command = 'gedit'
  binding = 'g'

  I put my gschema.override file in the '/usr/share/glib-2.0/schemas' 
directory. After I added these lines, I ran 'glib-compile-schemas 
/usr/share/glib2.0/schemas' and no error was reported.
  For testing purposes I created a new user, logged out, and logged in with the 
new user. In the best case, the custom key-binding were applied automatically, 
but this has not happened. Other defined key-bindings were applied correctly.
  In the gnome-control-center's key-bindings tab, the table containing  custom 
shortcuts is empty, containing one row with empty columns.

  Running 'gsettings list-recursively org.gnome.settings-daemon.plugins
  .media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins
  /media-keys/custom-keybindings/custom0/' shows, the name, command, and
  binding key pairs contain empty ('') values.

  If I manually run following commands, the custom key-binding is created 
correctly:
  gsettings set 
org.gnome.settings-daemon.plugins.media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/
 name "Launch Gedit"
  gsettings set 
org.gnome.settings-daemon.plugins.media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/
 command "gedit"
  gsettings set 
org.gnome.settings-daemon.plugins.media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/
 binding "g"

  Am I doing anything wrong when I want to add a custom key-bindings in
  my schema file, or  is 'glib-compile-schemas' really not applying this
  part from the schema file?

  Attila

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: libglib2.0-bin 2.39.4-0ubuntu1
  ProcVersionSignature: Ubuntu 3.13.0-8.28-generic 3.13.2
  Uname: Linux 3.13.0-8-generic i686
  ApportVersion: 2.13.2-0ubuntu4
  Architecture: i386
  CurrentDesktop: GNOME
  Date: Tue Feb 18 13:58:37 2014
  InstallationDate: Installed on 2013-12-13 (67 days ago)
  InstallationMedia: BeLin 3.02 i386
  SourcePackage: glib2.0
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1891158] Re: riscv64 build - hang at the end of the build with hanging "dbus-test-runner"

2020-08-12 Thread Christian Ehrhardt 
When running the build in a local groovy qemu riscv64 guest the test
left no dbus-test-runner processes for debugging around :-/

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

Title:
  riscv64 build - hang at the end of the build with hanging "dbus-test-
  runner"

Status in dbus-test-runner package in Ubuntu:
  New
Status in dee package in Ubuntu:
  Confirmed

Bug description:
  The builds for riscv64 on e.g.
  https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1
  hang eventually.

  All other architectures work fine.

  
  Build log tail will be like:
  ...
symlinking changelog.Debian.gz in dee-tools to file in libdee-1.0-4
  pkgstripfiles: Running PNG optimization (using 8 cpus) for package dee-tools 
...
  pkgstripfiles: No PNG files.
  dpkg-deb: building package 'dee-tools' in 
'../dee-tools_1.2.7+17.10.20170616-6build1_riscv64.deb'.
  pkgstriptranslations: libdee-1.0-4-dbgsym does not contain translations, 
skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/libdee-1.0-4/dbgsym-root/DEBIAN/control, package 
libdee-1.0-4-dbgsym, directory debian/.debhelper/libdee-1.0-4/dbgsym-root
  dpkg-deb: building package 'libdee-1.0-4-dbgsym' in 
'debian/.debhelper/scratch-space/build-libdee-1.0-4/libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
  pkgstriptranslations: dee-tools-dbgsym does not contain translations, skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/dee-tools/dbgsym-root/DEBIAN/control, package 
dee-tools-dbgsym, directory debian/.debhelper/dee-tools/dbgsym-root
  dpkg-deb: building package 'dee-tools-dbgsym' in 
'debian/.debhelper/scratch-space/build-dee-tools/dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
   dpkg-genbuildinfo --build=any
   dpkg-genchanges --build=any -mLaunchpad Build Daemon 
 
>../dee_1.2.7+17.10.20170616-6build1_riscv64.changes
  dpkg-genchanges: info: binary-only arch-specific upload (source code and 
arch-indep packages not included)
   dpkg-source --after-build .
  dpkg-buildpackage: info: binary-only upload (no source included)

  
  Then it will be stuck until at 24h a timeout will reap the builder.

  It turned out (thanks cjwatson) that on these systems there is a
  leftover process

  Zombie schroot process
  Looks like there's a dbus-daemon process still running in the background of 
the build that the build didn't clean up properly
  buildd481987  0.0  0.0   5244  2780 ?SAug10   0:00 
dbus-daemon --config-file /usr/share/dbus-test-runner/session.conf 
--print-address
  # ls -l /proc/481987/cwd
  lrwxrwxrwx 1 buildd buildd 0 Aug 11 10:08 /proc/481987/cwd -> 
/home/buildd/build-PACKAGEBUILD-19646792/chroot-autobuild/build/dee-1HAMJl/dee-1.2.7+17.10.20170616/tests

  
  On #ubuntu-devel we discussed this and agreed that we should not just retry 
until it slips through by accident, we might never be able to build it again.

  Instead we should try looking for what actually hangs on riscv64 and
  why.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus-test-runner/+bug/1891158/+subscriptions

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


[Touch-packages] [Bug 1891332] [NEW] /usr/bin/unattended-upgrade:apt_pkg.Error:try_to_upgrade:mark_upgrade_adjusted:call_adjusted:clear:/usr/bin/unattended-upgrade@2514:main:run:calculate_upgradable_p

2020-08-12 Thread errors.ubuntu.com bug bridge
Public bug reported:

The Ubuntu Error Tracker has been receiving reports about a problem regarding 
unattended-upgrades.  This problem was most recently seen with package version 
2.3ubuntu0.1, the problem page at 
https://errors.ubuntu.com/problem/a16ab8014a871a4f125fcf1b5f1412bd338f9b5c 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

** Affects: unattended-upgrades (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: focal

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

Title:
  /usr/bin/unattended-
  
upgrade:apt_pkg.Error:try_to_upgrade:mark_upgrade_adjusted:call_adjusted:clear:/usr/bin
  /unattended-
  
upgrade@2514:main:run:calculate_upgradable_pkgs:try_to_upgrade:rewind_cache:clear

Status in unattended-upgrades package in Ubuntu:
  New

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
unattended-upgrades.  This problem was most recently seen with package version 
2.3ubuntu0.1, the problem page at 
https://errors.ubuntu.com/problem/a16ab8014a871a4f125fcf1b5f1412bd338f9b5c 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

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

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


[Touch-packages] [Bug 1891158] Re: riscv64 build - hang at the end of the build with hanging "dbus-test-runner"

2020-08-12 Thread Christian Ehrhardt 
Bumping the timeout isn't enough :-/
It still gets into the hang and breaks build.

Chances are we are not actually facing a timeout issue, but something around
  /var/log/launchpad-buildd/default.log-20200812:2020-08-11 12:45:42+ [-] 
Build log: (dbus-test-runner:1807632): libdbustest-CRITICAL **: 12:45:42.692: 
dbus_test_service_run: assertion 'all_tasks(service, all_tasks_finished_helper, 
NULL)' failed

leaving behind the process.

Therefore - for the time being to unblock things - skip the test on riscv64.
Since that is avoidance and not a fix I'll leave this bug up.

Maybe a debug in dbus-test-runner will eventually fix things for
real.

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

Title:
  riscv64 build - hang at the end of the build with hanging "dbus-test-
  runner"

Status in dbus-test-runner package in Ubuntu:
  New
Status in dee package in Ubuntu:
  Confirmed

Bug description:
  The builds for riscv64 on e.g.
  https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1
  hang eventually.

  All other architectures work fine.

  
  Build log tail will be like:
  ...
symlinking changelog.Debian.gz in dee-tools to file in libdee-1.0-4
  pkgstripfiles: Running PNG optimization (using 8 cpus) for package dee-tools 
...
  pkgstripfiles: No PNG files.
  dpkg-deb: building package 'dee-tools' in 
'../dee-tools_1.2.7+17.10.20170616-6build1_riscv64.deb'.
  pkgstriptranslations: libdee-1.0-4-dbgsym does not contain translations, 
skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/libdee-1.0-4/dbgsym-root/DEBIAN/control, package 
libdee-1.0-4-dbgsym, directory debian/.debhelper/libdee-1.0-4/dbgsym-root
  dpkg-deb: building package 'libdee-1.0-4-dbgsym' in 
'debian/.debhelper/scratch-space/build-libdee-1.0-4/libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
  pkgstriptranslations: dee-tools-dbgsym does not contain translations, skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/dee-tools/dbgsym-root/DEBIAN/control, package 
dee-tools-dbgsym, directory debian/.debhelper/dee-tools/dbgsym-root
  dpkg-deb: building package 'dee-tools-dbgsym' in 
'debian/.debhelper/scratch-space/build-dee-tools/dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
   dpkg-genbuildinfo --build=any
   dpkg-genchanges --build=any -mLaunchpad Build Daemon 
 
>../dee_1.2.7+17.10.20170616-6build1_riscv64.changes
  dpkg-genchanges: info: binary-only arch-specific upload (source code and 
arch-indep packages not included)
   dpkg-source --after-build .
  dpkg-buildpackage: info: binary-only upload (no source included)

  
  Then it will be stuck until at 24h a timeout will reap the builder.

  It turned out (thanks cjwatson) that on these systems there is a
  leftover process

  Zombie schroot process
  Looks like there's a dbus-daemon process still running in the background of 
the build that the build didn't clean up properly
  buildd481987  0.0  0.0   5244  2780 ?SAug10   0:00 
dbus-daemon --config-file /usr/share/dbus-test-runner/session.conf 
--print-address
  # ls -l /proc/481987/cwd
  lrwxrwxrwx 1 buildd buildd 0 Aug 11 10:08 /proc/481987/cwd -> 
/home/buildd/build-PACKAGEBUILD-19646792/chroot-autobuild/build/dee-1HAMJl/dee-1.2.7+17.10.20170616/tests

  
  On #ubuntu-devel we discussed this and agreed that we should not just retry 
until it slips through by accident, we might never be able to build it again.

  Instead we should try looking for what actually hangs on riscv64 and
  why.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus-test-runner/+bug/1891158/+subscriptions

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


[Touch-packages] [Bug 1890286] Re: ansi escape sequence injection in add-apt-repository

2020-08-12 Thread Launchpad Bug Tracker
This bug was fixed in the package software-properties - 0.98.9.2

---
software-properties (0.98.9.2) focal-security; urgency=medium

  * SECURITY UPDATE: malicious repo could send ANSI sequences to terminal
(LP: #1890286)
- add-apt-repository: strip ANSI sequences from the description.
- CVE-2020-15709

 -- Marc Deslauriers   Fri, 07 Aug 2020
09:15:34 -0400

** Changed in: software-properties (Ubuntu)
   Status: New => Fix Released

** Changed in: software-properties (Ubuntu)
   Status: New => Fix Released

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

Title:
  ansi escape sequence injection in add-apt-repository

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:
  This was reported to oss-security and to secur...@ubuntu.com, but I
  figure I should make a real bug report, as otherwise it'll probably be
  missed. Original post from https://www.openwall.com/lists/oss-
  security/2020/08/03/1 follows below.

  --

  Hi,

  I've found a rather low grade concern: I'm able to inject ANSI escape
  sequences into PPA descriptions on Launchpad, and then have them
  rendered by add-apt-repository *before* the user consents to actually
  adding that repository. There might be some sort of trust barrier
  issue with that. This could be used to clear the screen and imitate a
  fresh bash prompt, upload files, dump the current screen to a file, or
  other classic shenanigans, well chronicled in the archives of oss-sec.

  PoC time -- I'm using this "feature" for good at the moment to
  announce the deprecation in bold text of a PPA that I maintain:
  https://data.zx2c4.com/add-apt-repository-ansi-injection.png

  The proper fix to this is likely to do sanitization on the
  add-apt-repository side.

  Regards,
  Jason

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

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


[Touch-packages] [Bug 1890286] Re: ansi escape sequence injection in add-apt-repository

2020-08-12 Thread Launchpad Bug Tracker
This bug was fixed in the package software-properties - 0.96.24.32.14

---
software-properties (0.96.24.32.14) bionic-security; urgency=medium

  * SECURITY UPDATE: malicious repo could send ANSI sequences to terminal
(LP: #1890286)
- add-apt-repository: strip ANSI sequences from the description.
- CVE-2020-15709

 -- Marc Deslauriers   Fri, 07 Aug 2020
10:07:43 -0400

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

Title:
  ansi escape sequence injection in add-apt-repository

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:
  This was reported to oss-security and to secur...@ubuntu.com, but I
  figure I should make a real bug report, as otherwise it'll probably be
  missed. Original post from https://www.openwall.com/lists/oss-
  security/2020/08/03/1 follows below.

  --

  Hi,

  I've found a rather low grade concern: I'm able to inject ANSI escape
  sequences into PPA descriptions on Launchpad, and then have them
  rendered by add-apt-repository *before* the user consents to actually
  adding that repository. There might be some sort of trust barrier
  issue with that. This could be used to clear the screen and imitate a
  fresh bash prompt, upload files, dump the current screen to a file, or
  other classic shenanigans, well chronicled in the archives of oss-sec.

  PoC time -- I'm using this "feature" for good at the moment to
  announce the deprecation in bold text of a PPA that I maintain:
  https://data.zx2c4.com/add-apt-repository-ansi-injection.png

  The proper fix to this is likely to do sanitization on the
  add-apt-repository side.

  Regards,
  Jason

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

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


[Touch-packages] [Bug 1866681] Re: [HP Pavilion dv9000] Mute toggles on/off while plugged into the headphone/speaker jack (19.04+)

2020-08-12 Thread Kai-Heng Feng
Do unaffected distros have "module-switch-on-port-available" loaded?

Can you please try not loading the module?

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

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

Title:
  [HP Pavilion dv9000] Mute toggles on/off while plugged into the
  headphone/speaker jack (19.04+)

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

Bug description:
  I'm on an HP Pavilion dv9000 (https://www.cnet.com/products/hp-
  pavilion-dv9000/specs/) built many years ago.

  
  Whenever I'm using any distro that's based on Ubuntu which was published from 
Version 19.04 onwards, I've been having a major issue with the mute button 
toggling on and off whenever I have something plugged into the audio out jack. 
I know that it's not the fault of XFCE, because I also use the latest version 
of Manjaro with XFCE on this same computer, and it works fine. I also know it's 
not any Red Hat-based distro, because I use Stella (which is a remix of CentOS 
6) also on this exact same computer, and it also works fine. Qubes, Mageia, and 
Fedora 31 also work perfectly fine and don't have this issue.

  My "lsb-release" is:
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=19.10
  DISTRIB_CODENAME=eoan
  DISTRIB_DESCRIPTION="Ubuntu 19.10"

  and "apt-cache policy pulseaudio" outputs:
  pulseaudio:
Installed: 1:13.0-1ubuntu1.1
Candidate: 1:13.0-1ubuntu1.1
Version table:
   *** 1:13.0-1ubuntu1.1 500
  500 http://us.archive.ubuntu.com/ubuntu eoan-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:13.0-1ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu eoan/main amd64 Packages

  I've uploaded a short video of the problem that I recorded with my phone here:
  https://www.youtube.com/watch?v=GXaHXQA-5uQ

  
  The problem appears with Kali 2019 and 2020, Peppermint 19.04, Lubuntu 19.04, 
Xubuntu 19.04, and Sparky 5.10 and 2020.02.

  
  I've checked pretty much everything I can think of. There's a log for my ALSA 
help diagnostics results on my current computer (which works properly with 
18.04) at:
  http://alsa-project.org/db/?f=4859b85cd7fc32e7f01f8df63591b5a43dbf6829

  
  the result output of lspci is:
  [code]00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2)
  00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev a2)
  00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 (rev a2)
  00:00.3 RAM memory: NVIDIA Corporation C51 Memory Controller 5 (rev a2)
  00:00.4 RAM memory: NVIDIA Corporation C51 Memory Controller 4 (rev a2)
  00:00.5 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2)
  00:00.6 RAM memory: NVIDIA Corporation C51 Memory Controller 3 (rev a2)
  00:00.7 RAM memory: NVIDIA Corporation C51 Memory Controller 2 (rev a2)
  00:02.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1)
  00:03.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1)
  00:04.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1)
  00:09.0 RAM memory: NVIDIA Corporation MCP51 Host Bridge (rev a2)
  00:0a.0 ISA bridge: NVIDIA Corporation MCP51 LPC Bridge (rev a3)
  00:0a.1 SMBus: NVIDIA Corporation MCP51 SMBus (rev a3)
  00:0a.3 Co-processor: NVIDIA Corporation MCP51 PMU (rev a3)
  00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3)
  00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3)
  00:0d.0 IDE interface: NVIDIA Corporation MCP51 IDE (rev f1)
  00:0e.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev f1)
  00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev f1)
  00:10.0 PCI bridge: NVIDIA Corporation MCP51 PCI Bridge (rev a2)
  00:10.1 Audio device: NVIDIA Corporation MCP51 High Definition Audio (rev a2)
  00:14.0 Bridge: NVIDIA Corporation MCP51 Ethernet Controller (rev a3)
  00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
  00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
Address Map
  00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
DRAM Controller
  00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
  03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4311 802.11b/g 
WLAN (rev 01)
  05:00.0 VGA compatible controller: NVIDIA Corporation G73M [GeForce Go 7600] 
(rev a1)
  07:05.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
  07:05.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 19)
  07:05.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter 
(rev 0a)
  07:05.3 System peripheral: Ricoh Co Ltd xD-Picture Card 

[Touch-packages] [Bug 1891260] Re: iptables doesn't work with kernel 5.8

2020-08-12 Thread Kai Kasurinen
*** This bug is a duplicate of bug 1891020 ***
https://bugs.launchpad.net/bugs/1891020

** This bug has been marked a duplicate of bug 1891020
   No IPv4 iptable kernel module can be loaded

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

Title:
  iptables doesn't work with kernel 5.8

Status in iptables package in Ubuntu:
  New
Status in ufw package in Ubuntu:
  New

Bug description:
  Hi dear maintainers,
  iptables doesn't work since kernel 5.8 updated. Maybe you could update this 
package to 1.8.5 to fix this issue?

  iptables v1.8.4 (legacy): can't initialize iptables table `filter': Bad 
address
  Perhaps iptables or your kernel needs to be upgraded.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: iptables 1.8.4-3ubuntu2
  ProcVersionSignature: Ubuntu 5.8.0-12.13-generic 5.8.0-rc7
  Uname: Linux 5.8.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu44
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Aug 12 10:54:29 2020
  InstallationDate: Installed on 2020-04-13 (120 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402)
  SourcePackage: iptables
  UpgradeStatus: Upgraded to groovy on 2020-06-02 (70 days ago)

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

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


[Touch-packages] [Bug 1891316] Re: duplicate "progname" under gcc-10

2020-08-12 Thread Dave Jones
** Description changed:

  Under gcc-10's linker an error occurs wherein "progname" appears to be
  included from multiple locations (as it's defined in version.h rather
  than merely declared).
+ 
+ A trivial patch is available from the following branch:
+ 
+ https://code.launchpad.net/~waveform/ubuntu/+source/kbd/+git/kbd/+ref
+ /fix-duplicate-progname
+ 
+ With test builds in the following PPA:
+ 
+ https://launchpad.net/~waveform/+archive/ubuntu/kbd

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

Title:
  duplicate "progname" under gcc-10

Status in kbd package in Ubuntu:
  New

Bug description:
  Under gcc-10's linker an error occurs wherein "progname" appears to be
  included from multiple locations (as it's defined in version.h rather
  than merely declared).

  A trivial patch is available from the following branch:

  https://code.launchpad.net/~waveform/ubuntu/+source/kbd/+git/kbd/+ref
  /fix-duplicate-progname

  With test builds in the following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/kbd

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

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


[Touch-packages] [Bug 1891158] Re: riscv64 build - hang at the end of the build (groovy)

2020-08-12 Thread Christian Ehrhardt 
It turned out that this has happened in the past and then resolved, so this is 
a comeback.
For "dee" we can bump the timeout or skip the test on riscv64 for the immediate 
problem

But the "dbus-test-runner timeout makes riscv64 builds" hang is a problem on 
its own.
Therefore I added a bug task to dbus-test-runner

** Also affects: dbus-test-runner (Ubuntu)
   Importance: Undecided
   Status: New

** Summary changed:

- riscv64 build - hang at the end of the build (groovy)
+ riscv64 build - hang at the end of the build with hanging "dbus-test-runner"

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

Title:
  riscv64 build - hang at the end of the build with hanging "dbus-test-
  runner"

Status in dbus-test-runner package in Ubuntu:
  New
Status in dee package in Ubuntu:
  Confirmed

Bug description:
  The builds for riscv64 on e.g.
  https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1
  hang eventually.

  All other architectures work fine.

  
  Build log tail will be like:
  ...
symlinking changelog.Debian.gz in dee-tools to file in libdee-1.0-4
  pkgstripfiles: Running PNG optimization (using 8 cpus) for package dee-tools 
...
  pkgstripfiles: No PNG files.
  dpkg-deb: building package 'dee-tools' in 
'../dee-tools_1.2.7+17.10.20170616-6build1_riscv64.deb'.
  pkgstriptranslations: libdee-1.0-4-dbgsym does not contain translations, 
skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/libdee-1.0-4/dbgsym-root/DEBIAN/control, package 
libdee-1.0-4-dbgsym, directory debian/.debhelper/libdee-1.0-4/dbgsym-root
  dpkg-deb: building package 'libdee-1.0-4-dbgsym' in 
'debian/.debhelper/scratch-space/build-libdee-1.0-4/libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
  pkgstriptranslations: dee-tools-dbgsym does not contain translations, skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/dee-tools/dbgsym-root/DEBIAN/control, package 
dee-tools-dbgsym, directory debian/.debhelper/dee-tools/dbgsym-root
  dpkg-deb: building package 'dee-tools-dbgsym' in 
'debian/.debhelper/scratch-space/build-dee-tools/dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
   dpkg-genbuildinfo --build=any
   dpkg-genchanges --build=any -mLaunchpad Build Daemon 
 
>../dee_1.2.7+17.10.20170616-6build1_riscv64.changes
  dpkg-genchanges: info: binary-only arch-specific upload (source code and 
arch-indep packages not included)
   dpkg-source --after-build .
  dpkg-buildpackage: info: binary-only upload (no source included)

  
  Then it will be stuck until at 24h a timeout will reap the builder.

  It turned out (thanks cjwatson) that on these systems there is a
  leftover process

  Zombie schroot process
  Looks like there's a dbus-daemon process still running in the background of 
the build that the build didn't clean up properly
  buildd481987  0.0  0.0   5244  2780 ?SAug10   0:00 
dbus-daemon --config-file /usr/share/dbus-test-runner/session.conf 
--print-address
  # ls -l /proc/481987/cwd
  lrwxrwxrwx 1 buildd buildd 0 Aug 11 10:08 /proc/481987/cwd -> 
/home/buildd/build-PACKAGEBUILD-19646792/chroot-autobuild/build/dee-1HAMJl/dee-1.2.7+17.10.20170616/tests

  
  On #ubuntu-devel we discussed this and agreed that we should not just retry 
until it slips through by accident, we might never be able to build it again.

  Instead we should try looking for what actually hangs on riscv64 and
  why.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus-test-runner/+bug/1891158/+subscriptions

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


[Touch-packages] [Bug 1891158] Re: riscv64 build - hang at the end of the build with hanging "dbus-test-runner"

2020-08-12 Thread Christian Ehrhardt 
>From IRC:
[13:34]  Laney: ha - timeout = 1 on x86 triggers the same 
warnings/erorrs, but NOT the hang of the builder
[13:34]  
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4200/+build/19818311
 is an example
[13:34]  interesting
[13:35]  perhaps riscv64 does process reaping differently
[13:37]  Laney, cpaelzer: dbus-test-runner is what generally gets 
stuck, I haven't worked out why.
[13:37]  But there are a couple of packages that were consistently 
hanging because it didn't die for a while. But they seemed to eventually fix 
themselves by around maybe September.

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

Title:
  riscv64 build - hang at the end of the build with hanging "dbus-test-
  runner"

Status in dbus-test-runner package in Ubuntu:
  New
Status in dee package in Ubuntu:
  Confirmed

Bug description:
  The builds for riscv64 on e.g.
  https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1
  hang eventually.

  All other architectures work fine.

  
  Build log tail will be like:
  ...
symlinking changelog.Debian.gz in dee-tools to file in libdee-1.0-4
  pkgstripfiles: Running PNG optimization (using 8 cpus) for package dee-tools 
...
  pkgstripfiles: No PNG files.
  dpkg-deb: building package 'dee-tools' in 
'../dee-tools_1.2.7+17.10.20170616-6build1_riscv64.deb'.
  pkgstriptranslations: libdee-1.0-4-dbgsym does not contain translations, 
skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/libdee-1.0-4/dbgsym-root/DEBIAN/control, package 
libdee-1.0-4-dbgsym, directory debian/.debhelper/libdee-1.0-4/dbgsym-root
  dpkg-deb: building package 'libdee-1.0-4-dbgsym' in 
'debian/.debhelper/scratch-space/build-libdee-1.0-4/libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
  pkgstriptranslations: dee-tools-dbgsym does not contain translations, skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/dee-tools/dbgsym-root/DEBIAN/control, package 
dee-tools-dbgsym, directory debian/.debhelper/dee-tools/dbgsym-root
  dpkg-deb: building package 'dee-tools-dbgsym' in 
'debian/.debhelper/scratch-space/build-dee-tools/dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
   dpkg-genbuildinfo --build=any
   dpkg-genchanges --build=any -mLaunchpad Build Daemon 
 
>../dee_1.2.7+17.10.20170616-6build1_riscv64.changes
  dpkg-genchanges: info: binary-only arch-specific upload (source code and 
arch-indep packages not included)
   dpkg-source --after-build .
  dpkg-buildpackage: info: binary-only upload (no source included)

  
  Then it will be stuck until at 24h a timeout will reap the builder.

  It turned out (thanks cjwatson) that on these systems there is a
  leftover process

  Zombie schroot process
  Looks like there's a dbus-daemon process still running in the background of 
the build that the build didn't clean up properly
  buildd481987  0.0  0.0   5244  2780 ?SAug10   0:00 
dbus-daemon --config-file /usr/share/dbus-test-runner/session.conf 
--print-address
  # ls -l /proc/481987/cwd
  lrwxrwxrwx 1 buildd buildd 0 Aug 11 10:08 /proc/481987/cwd -> 
/home/buildd/build-PACKAGEBUILD-19646792/chroot-autobuild/build/dee-1HAMJl/dee-1.2.7+17.10.20170616/tests

  
  On #ubuntu-devel we discussed this and agreed that we should not just retry 
until it slips through by accident, we might never be able to build it again.

  Instead we should try looking for what actually hangs on riscv64 and
  why.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus-test-runner/+bug/1891158/+subscriptions

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


[Touch-packages] [Bug 1891316] [NEW] duplicate "progname" under gcc-10

2020-08-12 Thread Dave Jones
Public bug reported:

Under gcc-10's linker an error occurs wherein "progname" appears to be
included from multiple locations (as it's defined in version.h rather
than merely declared).

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

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

Title:
  duplicate "progname" under gcc-10

Status in kbd package in Ubuntu:
  New

Bug description:
  Under gcc-10's linker an error occurs wherein "progname" appears to be
  included from multiple locations (as it's defined in version.h rather
  than merely declared).

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

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


[Touch-packages] [Bug 1891158] Re: riscv64 build - hang at the end of the build (groovy)

2020-08-12 Thread Christian Ehrhardt 
When lowering the timeout to trigger the same on x86 (to see if the hang
occurs there as well) I can see that the test breaks as it does on
riscv64, but the hang does not happen.

task-0:   /Model/Transaction/Target2ChangeRemoveAppend:
OK

** (dbus-test-runner:15767): WARNING **: 11:26:03.671: Timing out at maximum 
wait of 1 seconds.
task-0:   /Model/Transaction/SignalOrder:  
OK
task-0:   /Model/Transaction/ConcurrentModification:   
OK
task-0:   /Model/Transaction/DoubleCommit: 
OK
task-0:   /Model/Transaction/BasicTypes:   
OK
task-0:   /Model/Transaction/Rows/Allocation:  
OK

(dbus-test-runner:15767): libdbustest-CRITICAL **: 11:26:03.671: 
dbus_test_service_run: assertion 'all_tasks(service, all_tasks_finished_helper, 
NULL)' failed
task-0: Shutting down
DBus daemon: Shutdown
make[4]: *** [Makefile:1151: test] Error 255
make[4]: Leaving directory '/<>/dee-1.2.7+17.10.20170616/tests'
make[3]: *** [Makefile:939: check-am] Error 2
make[3]: Leaving directory '/<>/dee-1.2.7+17.10.20170616/tests'
kill: (15773): No such process
make[2]: *** [Makefile:525: check-recursive] Error 1
make[2]: Leaving directory '/<>/dee-1.2.7+17.10.20170616'
dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
make[1]: *** [debian/rules:26: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>/dee-1.2.7+17.10.20170616'
make: *** [debian/rules:14: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2
semop(1): encountered an error: Invalid argument

Build finished at 2020-08-12T11:26:03Z

>From https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4200/+build/19818311

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

Title:
  riscv64 build - hang at the end of the build (groovy)

Status in dee package in Ubuntu:
  Confirmed

Bug description:
  The builds for riscv64 on e.g.
  https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1
  hang eventually.

  All other architectures work fine.

  
  Build log tail will be like:
  ...
symlinking changelog.Debian.gz in dee-tools to file in libdee-1.0-4
  pkgstripfiles: Running PNG optimization (using 8 cpus) for package dee-tools 
...
  pkgstripfiles: No PNG files.
  dpkg-deb: building package 'dee-tools' in 
'../dee-tools_1.2.7+17.10.20170616-6build1_riscv64.deb'.
  pkgstriptranslations: libdee-1.0-4-dbgsym does not contain translations, 
skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/libdee-1.0-4/dbgsym-root/DEBIAN/control, package 
libdee-1.0-4-dbgsym, directory debian/.debhelper/libdee-1.0-4/dbgsym-root
  dpkg-deb: building package 'libdee-1.0-4-dbgsym' in 
'debian/.debhelper/scratch-space/build-libdee-1.0-4/libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
libdee-1.0-4-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
  pkgstriptranslations: dee-tools-dbgsym does not contain translations, skipping
  pkgstriptranslations: no translation files, not creating tarball
  pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
  pkgstripfiles: processing control file: 
debian/.debhelper/dee-tools/dbgsym-root/DEBIAN/control, package 
dee-tools-dbgsym, directory debian/.debhelper/dee-tools/dbgsym-root
  dpkg-deb: building package 'dee-tools-dbgsym' in 
'debian/.debhelper/scratch-space/build-dee-tools/dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb'.
   Renaming dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.deb to 
dee-tools-dbgsym_1.2.7+17.10.20170616-6build1_riscv64.ddeb
   dpkg-genbuildinfo --build=any
   dpkg-genchanges --build=any -mLaunchpad Build Daemon 
 
>../dee_1.2.7+17.10.20170616-6build1_riscv64.changes
  dpkg-genchanges: info: binary-only arch-specific upload (source code and 
arch-indep packages not included)
   dpkg-source --after-build .
  dpkg-buildpackage: info: binary-only upload (no source included)

  
  Then it will be stuck until at 24h a timeout will reap the builder.

  It turned out (thanks cjwatson) that on these systems there is a
  leftover process

  Zombie schroot process
  Looks like there's a dbus-daemon process still running in the background of 
the build that the build didn't clean up properly
  buildd481987  0.0  0.0   5244  2780 ?SAug10   0:00 
dbus-daemon --config-file /usr/share/dbus-test-runner/session.conf 
--print-address
  # ls -l /proc/481987/cwd
  lrwxrwxrwx 1 buildd buildd 0 

[Touch-packages] [Bug 1891313] [NEW] Xorg crash

2020-08-12 Thread Luan Orion de Oliveira Barauna Ferreira
Public bug reported:

I have a ACER Nitro 5 NVIDIA GTX 1650 Mobile with Ubuntu 20.04  instated
and i tryed to boot my notebook with a second monitor plugged by HDMI
port. Now, my internal monitor can't be recognized and its crashing on
the initial load screem. They can load only whit the HDMI is connected.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
.proc.driver.nvidia.capabilities.gpu0: Error: [Errno 21] É um diretório: 
'/proc/driver/nvidia/capabilities/gpu0'
.proc.driver.nvidia.capabilities.mig: Error: [Errno 21] É um diretório: 
'/proc/driver/nvidia/capabilities/mig'
.proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] É um diretório: 
'/proc/driver/nvidia/gpus/:01:00.0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.suspend: suspend hibernate resume
.proc.driver.nvidia.suspend_depth: default modeset uvm
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module  450.51.06  Sun Jul 19 20:02:54 
UTC 2020
 GCC version:  gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
ApportVersion: 2.20.11-0ubuntu27.6
Architecture: amd64
BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Wed Aug 12 07:55:04 2020
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
DkmsStatus: nvidia, 450.51.06, 5.4.0-42-generic, x86_64: installed
ExtraDebuggingInterest: Yes, including running git bisection searches
GraphicsCard:
 Intel Corporation UHD Graphics 630 (Mobile) [8086:3e9b] (prog-if 00 [VGA 
controller])
   Subsystem: Acer Incorporated [ALI] UHD Graphics 630 (Mobile) [1025:1331]
 NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] [10de:1f91] (rev 
a1) (prog-if 00 [VGA controller])
   Subsystem: Acer Incorporated [ALI] TU117M [GeForce GTX 1650 Mobile / Max-Q] 
[1025:1332]
InstallationDate: Installed on 2020-08-05 (7 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 04f2:b64f Chicony Electronics Co., Ltd HD User Facing
 Bus 001 Device 002: ID 1a2c:0043 China Resource Semico Co., Ltd USB Mouse
 Bus 001 Device 004: ID 8087:0029 Intel Corp. 
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Acer Nitro AN515-54
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic 
root=UUID=b286d151-6958-4e94-8f2b-2af178b1dc88 ro vt.handoff=7
SourcePackage: xorg
Symptom: display
Title: Xorg crash
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/11/2020
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: V1.30
dmi.board.asset.tag: Type2 - Board Serial Number
dmi.board.name: Octavia_CFS
dmi.board.vendor: CFL
dmi.board.version: V1.30
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: V1.30
dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.30:bd05/11/2020:svnAcer:pnNitroAN515-54:pvrV1.30:rvnCFL:rnOctavia_CFS:rvrV1.30:cvnAcer:ct10:cvrV1.30:
dmi.product.family: Nitro 5
dmi.product.name: Nitro AN515-54
dmi.product.sku: 
dmi.product.version: V1.30
dmi.sys.vendor: Acer
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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


** Tags: amd64 apport-bug crash focal ubuntu

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

Title:
  Xorg crash

Status in xorg package in Ubuntu:
  New

Bug description:
  I have a ACER Nitro 5 NVIDIA GTX 1650 Mobile with Ubuntu 20.04
  instated and i tryed to boot my notebook with a second monitor plugged
  by HDMI port. Now, my internal monitor can't be recognized and its
  crashing on the initial load screem. They can load only whit the HDMI
  is connected.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  .proc.driver.nvidia.capabilities.gpu0: Error: [Errno 21] É um diretório: 
'/proc/driver/nvidia/capabilities/gpu0'
  .proc.driver.nvidia.capabilities.mig: Error: [Errno 21] É um diretório: 

[Touch-packages] [Bug 304393] Re: rpcbind grabs ports used by other daemons such as cupsd

2020-08-12 Thread Robie Basak
The Ubuntu Xenial SRU looks fine in principle but is currently blocked
until the previous SRU is released. I've not reviewed this in detail
yet.

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

Title:
  rpcbind grabs ports used by other daemons such as cupsd

Status in cups package in Ubuntu:
  Invalid
Status in rpcbind package in Ubuntu:
  Fix Released
Status in rpcbind source package in Xenial:
  In Progress
Status in rpcbind source package in Bionic:
  Fix Committed
Status in rpcbind package in Debian:
  Fix Released
Status in Fedora:
  Confirmed

Bug description:
  [impact]

  rpcbind binds to a 'random' reserved port at startup, which can
  conflict with the reserved port number for other applications that
  actually 'own' the reserved port number. One example is cups, which
  uses the reserved port 631.

  This prevents the actual 'owner' of the reserved port from starting,
  since it can't bind to its reserved port.

  Additionally, this can raise alarms from security monitoring software
  that does not expect programs to be listening on random reserved
  ports.

  [test case]

  start rpcbind and check which ports it is listening on, e.g.:

  $ sudo netstat --inet -p -l | grep rpcbind | grep -v sunrpc
  udp0  0 0.0.0.0:614 0.0.0.0:* 
  4678/rpcbind

  each time rpcbind is restarted, it will be listening to a different
  'random' port.

  [regression potential]

  this adds a way to disable rpcbind from listening to the 'random'
  port. any regression would likely prevent rpcbind from starting, or
  may cause problems with the interaction between rpcinfo and rpcbind,
  as rpcinfo may use the random reserved port in some cases, as detailed
  in the Debian bug.

  [scope]

  This is needed only for Bionic and earlier.

  In Focal and later, and in Debian, rpcbind defaults to not opening the
  random reserved port.  The admin can use the -r parameter to cause
  rpcbind to restore the old behavior of opening the random reserved
  port.

  [other info]

  Note that the -r parameter is a Debian addition, and the upstream
  rpcbind has disabled the random port functionality at build time;
  there is no runtime parameter to allow the admin to choose the
  behavior.

  Also, as discussed in the Debian bug, disabling this rpcbind 'feature'
  is known to cause problems for the rpcinfo program, which is why
  Debian introduced the -r parameter. So, when this -r parameter is
  backported to Bionic and earlier, we must retain the default behavior
  for those releases, which is for rpcbind to open the random reserved
  port.

  Thus, the patch for this will first backport the upstream patch that adds 
functionality to be able to disable the 'remote calls' function, and also 
backports the debian patch to change that from a compile-time to run-time 
option. Then, another patch is added, which changes the default back to the 
behavior of x/b, which is for remote calls to be enabled by default,
  and also adds a check for the existence of an environment variable 
"RPCBIND_RMTCALL_DEFAULT_DISABLED" which, if defined (to anything), will change 
the default to disabled.

  This allows 1) retaining the existing default behavior of rpcbind in x
  and b, while also 2) providing a mechanism to change that default for
  anyone who does *not* want remote calls to be enabled, and 3) allowing
  the mechanism to change the default to remain in place after an
  upgrade to Focal. Using the environment variable allows anyone to
  disable the remote calls in x and/or b, and then upgrade to Focal
  without breaking rpcbind or needing to remove the env var. After the
  upgrade to Focal, the environment variable (defined in
  /etc/default/rpcbind and/or /etc/rpcbind.conf) will simply be ignored
  without any change needed to the rpcbind package in Focal or later.

  [original description]

  Binary package hint: cups

  cups 1.3.9-2ubuntu4
  From /var/log/cups/error_log:
  cups: unable to bind socket for address 127.0.0.1:631 - Address already in 
use.

  Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd
  when started.

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

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


[Touch-packages] [Bug 1888101] Re: 'unsupported protocol' error when using PyMySQL

2020-08-12 Thread Tiago
Hi Seth,

In my case its sort of a complicated setup. We have a MariaDB running on an 
Ubuntu 18.04 server with SSL and ed25519. Then, I followed the instructions on 
the Superset documentation for manual installation 
(https://superset.incubator.apache.org/installation.html) and installed the 
software on an Ubuntu 20.04. When using the mysqldb python driver the Superset 
software was giving out an error and I decided to try to change to PyMySQL 
(since superset uses SLQAlchemy should not make a big difference). Then the 
error is shown when trying to connect.
I haven't tried another version of Python or Openssl.

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

Title:
  'unsupported protocol' error when using PyMySQL

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  1)
  Description:  Ubuntu 20.04 LTS
  Release:  20.04

  2)
  openssl:
Installiert:   1.1.1f-1ubuntu2
Installationskandidat: 1.1.1f-1ubuntu2
Versionstabelle:
   *** 1.1.1f-1ubuntu2 500
  500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  3) + 4)
  I am trying to connect to my MariaDB with python package "PyMySQL" and SSL 
enabled. On my old installation (Kubuntu 19.10) this worked. With the new 
installation (also new PC: Xubuntu 20.04) I get this error message:

  ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol
  (_ssl.c:1108)

  Here are my installation details:
  Old installation: python 3.7.5, pymysql 0.9.3, ssl.OPENSSL_VERSION = 1.1.1c 
28 May 2019
  New installation: python 3.8.2, pymysql 0.9.3, ssl.OPENSSL_VERSION = 1.1.1f 
31 Mar 2020

  When I use python with a different SSL version...:
  this works: python 3.7.5, ssl.OPENSSL_VERSION = OpenSSL 1.1.0m-dev xx XXX 
  this works: python 3.7.5, ssl.OPENSSL_VERSION = OpenSSL 1.1.1h-dev xx XXX 
  this works: python 3.8.2, ssl.OPENSSL_VERSION = OpenSSL 1.1.1h-dev xx XXX 

  
  It seems, like the one specific version of openSSL (1.1.1f 31 Mar 2020) does 
not work together with PyMySQL.

  Some more details I have posted here:
  
https://stackoverflow.com/questions/62964998/unsupported-protocol-error-when-using-pymysql

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssl 1.1.1f-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
  Uname: Linux 5.4.0-40-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.4
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: XFCE
  Date: Sat Jul 18 15:42:27 2020
  InstallationDate: Installed on 2020-07-13 (4 days ago)
  InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1888628] Re: not automatic connection to hidden wifi

2020-08-12 Thread Kai-Heng Feng
** Package changed: linux (Ubuntu) => network-manager (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/1888628

Title:
  not automatic connection to hidden wifi

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  after restart iḿ no automatically connected to my hidden wifi

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-42-generic 5.4.0-42.46
  ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu27.4
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  thomas 1896 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul 23 10:05:31 2020
  InstallationDate: Installed on 2020-07-22 (0 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  MachineType: Hewlett-Packard HP ProBook 6570b
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=nl_NL.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.4.0-42-generic 
root=UUID=fd19f40c-82a5-40ab-b14a-6d553d287752 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-42-generic N/A
   linux-backports-modules-5.4.0-42-generic  N/A
   linux-firmware1.187.1
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/15/2019
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: 68ICE Ver. F.74
  dmi.board.name: 17AB
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: KBC Version 42.38
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvr68ICEVer.F.74:bd04/15/2019:svnHewlett-Packard:pnHPProBook6570b:pvrA1029D1102:rvnHewlett-Packard:rn17AB:rvrKBCVersion42.38:cvnHewlett-Packard:ct10:cvr:
  dmi.product.family: 103C_5336AN G=N L=BUS B=HP S=PRO
  dmi.product.name: HP ProBook 6570b
  dmi.product.sku: B6P85EA#ABH
  dmi.product.version: A1029D1102
  dmi.sys.vendor: Hewlett-Packard

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

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


[Touch-packages] [Bug 1888628] [NEW] not automatic connection to hidden wifi

2020-08-12 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

after restart iḿ no automatically connected to my hidden wifi

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-42-generic 5.4.0-42.46
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC0:  thomas 1896 F pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Jul 23 10:05:31 2020
InstallationDate: Installed on 2020-07-22 (0 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
MachineType: Hewlett-Packard HP ProBook 6570b
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.4.0-42-generic 
root=UUID=fd19f40c-82a5-40ab-b14a-6d553d287752 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-42-generic N/A
 linux-backports-modules-5.4.0-42-generic  N/A
 linux-firmware1.187.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/15/2019
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68ICE Ver. F.74
dmi.board.name: 17AB
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 42.38
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: 
dmi:bvnHewlett-Packard:bvr68ICEVer.F.74:bd04/15/2019:svnHewlett-Packard:pnHPProBook6570b:pvrA1029D1102:rvnHewlett-Packard:rn17AB:rvrKBCVersion42.38:cvnHewlett-Packard:ct10:cvr:
dmi.product.family: 103C_5336AN G=N L=BUS B=HP S=PRO
dmi.product.name: HP ProBook 6570b
dmi.product.sku: B6P85EA#ABH
dmi.product.version: A1029D1102
dmi.sys.vendor: Hewlett-Packard

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


** Tags: amd64 apport-bug focal
-- 
not automatic connection to hidden wifi
https://bugs.launchpad.net/bugs/1888628
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to network-manager in Ubuntu.

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


[Touch-packages] [Bug 1805666] Re: Evolution Alarm Notify continues pop-up reminders even though notifications disabled

2020-08-12 Thread ejahn
Agree with Joseph Borg about #8.  Evolution notifications are turned on
in Gnome Settings.  But popup reminders are turned off, yet they still
appear.

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

Title:
  Evolution Alarm Notify continues pop-up reminders even though
  notifications disabled

Status in evolution-data-server package in Ubuntu:
  Invalid

Bug description:
  I have turned off notifications for evolution alarm notify in settings:
  https://i.imgur.com/BNlfgzA.png

  But I still get pop-ups from the evolution alarm notify app for calendar 
events:
  https://i.imgur.com/BBdr9gm.png

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: evolution-data-server 3.30.1-1build1
  ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
  Uname: Linux 4.18.0-11-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov 28 11:31:46 2018
  ExecutablePath: 
/usr/lib/evolution/evolution-data-server/evolution-alarm-notify
  InstallationDate: Installed on 2018-07-14 (136 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: evolution-data-server
  UpgradeStatus: Upgraded to cosmic on 2018-10-29 (30 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1805666/+subscriptions

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


[Touch-packages] [Bug 1891292] [NEW] package libext2fs2:amd64 1.44.1-1ubuntu1.3 failed to install/upgrade: a csomag nagyon rossz, következetlen állapotban van - újra kell telepítenie a beállítási kís

2020-08-12 Thread ORBAN IRMA
Public bug reported:

Hello,
The video application (in ubuntu program) can not read mp4 video files. 
Refreshing all ubuntu programs failed. Package seams to be damaged. 
System : Ubuntu 18.04.4 LTS
Gnome 3.28.1
64 bites

ProblemType: Package
DistroRelease: Ubuntu 18.04
Package: libext2fs2:amd64 1.44.1-1ubuntu1.3
ProcVersionSignature: Ubuntu 4.15.0-1021.24-oem 4.15.18
Uname: Linux 4.15.0-1021-oem x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Wed Aug 12 10:59:14 2020
Dependencies:
 gcc-8-base 8-20180414-1ubuntu2
 libc6 2.27-3ubuntu1
 libgcc1 1:8-20180414-1ubuntu2
DistributionChannelDescriptor:
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-bionic-amd64-20180608-47+loki-n3-v3-kbl+X28
DpkgTerminalLog:
 dpkg: hiba a csomag feldolgozásakor: libext2fs2:amd64 (--configure):
  a csomag nagyon rossz, következetlen állapotban van - újra
  kell telepítenie a beállítási kísérlet előtt
ErrorMessage: a csomag nagyon rossz, következetlen állapotban van - újra  kell 
telepítenie a beállítási kísérlet előtt
InstallationDate: Installed on 2020-04-02 (131 days ago)
InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3
PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 
2.7.15~rc1-1
RelatedPackageVersions:
 dpkg 1.19.0.5ubuntu2.3
 apt  1.6.1
SourcePackage: e2fsprogs
Title: package libext2fs2:amd64 1.44.1-1ubuntu1.3 failed to install/upgrade: a 
csomag nagyon rossz, következetlen állapotban van - újra  kell telepítenie a 
beállítási kísérlet előtt
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-package bionic

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

Title:
  package libext2fs2:amd64 1.44.1-1ubuntu1.3 failed to install/upgrade:
  a csomag nagyon rossz, következetlen állapotban van - újra  kell
  telepítenie a beállítási kísérlet előtt

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  Hello,
  The video application (in ubuntu program) can not read mp4 video files. 
Refreshing all ubuntu programs failed. Package seams to be damaged. 
  System : Ubuntu 18.04.4 LTS
  Gnome 3.28.1
  64 bites

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: libext2fs2:amd64 1.44.1-1ubuntu1.3
  ProcVersionSignature: Ubuntu 4.15.0-1021.24-oem 4.15.18
  Uname: Linux 4.15.0-1021-oem x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Wed Aug 12 10:59:14 2020
  Dependencies:
   gcc-8-base 8-20180414-1ubuntu2
   libc6 2.27-3ubuntu1
   libgcc1 1:8-20180414-1ubuntu2
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+loki-n3-v3-kbl+X28
  DpkgTerminalLog:
   dpkg: hiba a csomag feldolgozásakor: libext2fs2:amd64 (--configure):
a csomag nagyon rossz, következetlen állapotban van - újra
kell telepítenie a beállítási kísérlet előtt
  ErrorMessage: a csomag nagyon rossz, következetlen állapotban van - újra  
kell telepítenie a beállítási kísérlet előtt
  InstallationDate: Installed on 2020-04-02 (131 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 
2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.3
   apt  1.6.1
  SourcePackage: e2fsprogs
  Title: package libext2fs2:amd64 1.44.1-1ubuntu1.3 failed to install/upgrade: 
a csomag nagyon rossz, következetlen állapotban van - újra  kell telepítenie a 
beállítási kísérlet előtt
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1788321] Re: swapon failed: invalid argument

2020-08-12 Thread Mélodie
Hello,

thanks to clickwir, this has helped me solve it in Ubuntu 20.04 with
btrfs!

Best regards,
Mélodie

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

Title:
  swapon failed: invalid argument

Status in linux package in Ubuntu:
  Confirmed
Status in util-linux package in Ubuntu:
  Invalid

Bug description:
  Environment:
   - Ubuntu 18.04.1 LTS
   - Linux 4.15.0-32-generic i686

  Description:
  When I try to mount my swap partition or my swap file, I get "swapon failed: 
invalid argument" .

  Steps to reproduce:
  1) sudo bash
  2) dd if=/dev/zero of=/swapfile bs=1024 count=524288
  3) mkswap /swapfile
  4) chown root:root /swapfile
  5) chmod 0600 /swapfile
  6) swapon /swapfile
  Last execution returns "swapon failed: invalid argument" .

  I'm almost sure it's a bug because I have no problems using Linux
  4.15.0-29-generic instead of Linux 4.15.0-32-generic. Also, no
  problems using Ubuntu 18.04.1 LTS Live CD.

  Regards.

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

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


[Touch-packages] [Bug 1703377] Re: Gnome online account login prevents paste or autotype

2020-08-12 Thread Alexander Adam
This bug is still present on Ubuntu 20.04.

Also you can find it on other places like

https://ubuntuforums.org/showthread.php?t=2398097
https://discourse.ubuntubudgie.org/t/online-accounts-cant-copy-and-paste-email-password/3212/3
or
https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1510011

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

Title:
  Gnome online account login prevents paste or autotype

Status in gnome-online-accounts package in Ubuntu:
  Confirmed

Bug description:
  On entering Login data to an online account such as google.

  Using keepass as password manager I now can not enter my password via
  paste nor via autotype. Trying any of them results in an invalid
  password.

  Ubuntu 16.10 - GNOME Shell 3.20.4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1703377/+subscriptions

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


[Touch-packages] [Bug 1868501] Re: software-properties-gtk is blank when run as normal user.

2020-08-12 Thread Sebastien Bacher
Thank you for your bug report, could you add your 'journalctl -b 0'
after getting the issue?

** Changed in: software-properties (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  software-properties-gtk is blank when run as normal user.

Status in software-properties package in Ubuntu:
  Incomplete

Bug description:
  lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  Upgraded install from 19.10

  "Software & Updates" windows is blank when initiated from either the
  terminal or via the "Settings..." button in the "Software Updater".

  If I run "software-properties-gtk" in the terminal the window is also blank.
  If I run it with sudo the "Software and Updates" window opens as normal.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: software-properties-gtk 0.98.7
  ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
  Uname: Linux 5.4.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Mar 22 21:30:12 2020
  InstallationDate: Installed on 2019-12-15 (98 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PackageArchitecture: all
  SourcePackage: software-properties
  UpgradeStatus: Upgraded to focal on 2020-03-22 (0 days ago)

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

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


[Touch-packages] [Bug 1867982] Re: unable to copy and paste login and password

2020-08-12 Thread Alexander Adam
*** This bug is a duplicate of bug 1703377 ***
https://bugs.launchpad.net/bugs/1703377

** This bug has been marked a duplicate of bug 1703377
   Gnome online account login prevents paste or autotype

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

Title:
  unable to copy and paste login and password

Status in gnome-online-accounts package in Ubuntu:
  New

Bug description:
  Select eg Google account when you have your user and password in clipboard.
  In the new account interface, cant paste into fields.
  Expected is paste.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gnome-online-accounts 3.36.0-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
  Uname: Linux 5.4.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu20
  Architecture: amd64
  CurrentDesktop: Budgie:GNOME
  Date: Thu Mar 19 08:37:01 2020
  InstallationDate: Installed on 2020-03-15 (2 days ago)
  InstallationMedia: Ubuntu-Budgie 20.04 LTS "Focal Fossa" - Alpha amd64 
(20200312)
  SourcePackage: gnome-online-accounts
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1867982/+subscriptions

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


[Touch-packages] [Bug 1891260] Re: iptables doesn't work with kernel 5.8

2020-08-12 Thread ymshenyu
** Also affects: ufw (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  iptables doesn't work with kernel 5.8

Status in iptables package in Ubuntu:
  New
Status in ufw package in Ubuntu:
  New

Bug description:
  Hi dear maintainers,
  iptables doesn't work since kernel 5.8 updated. Maybe you could update this 
package to 1.8.5 to fix this issue?

  iptables v1.8.4 (legacy): can't initialize iptables table `filter': Bad 
address
  Perhaps iptables or your kernel needs to be upgraded.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: iptables 1.8.4-3ubuntu2
  ProcVersionSignature: Ubuntu 5.8.0-12.13-generic 5.8.0-rc7
  Uname: Linux 5.8.0-12-generic x86_64
  ApportVersion: 2.20.11-0ubuntu44
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Aug 12 10:54:29 2020
  InstallationDate: Installed on 2020-04-13 (120 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402)
  SourcePackage: iptables
  UpgradeStatus: Upgraded to groovy on 2020-06-02 (70 days ago)

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

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


[Touch-packages] [Bug 1881976] Re: apport-gtk and apport-kde install xiterm+thai as dependency (x-terminal-emulator)

2020-08-12 Thread Dariusz Gadomski
I can verify that version 2.20.11-0ubuntu27.8 for focal fixes the issue.

Running on server install:
sudo apt install apport-gtk
apt offers gnome-terminal as dependency.

sudo apt install apport-kde
pulls in konsole as dependency.



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

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

Title:
  apport-gtk and apport-kde install xiterm+thai as dependency (x
  -terminal-emulator)

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * When installing apport-gtk (or apport-kde) on a non-GUI installation 
(cloud image, server image) as a dependency providing x-terminal-emulator 
xiterm+thai package is pulled in, which is not appropriate for most locales.
  My understanding is it was selected due to lowest number of unsatisfied 
dependencies.

  [Test Case]

   * lxc launch ubuntu:20.04 test
   * lxc shell test
   * apt update
   * apt install apport-gtk
   * Examine the packages listed to be installed: xiterm+thai is one of them.

  [Regression Potential]

   * In dedicated archive mirrors with limited number of packages
  changing that may cause errors due to packages missing in the archive.
  However, that's unlikely.

  [Other Info]

   * It is not affecting bionic, since x-terminal-emulator is listed as 
'Suggests' not 'Depends' there.
   * Original bug description:

  Vanilla install of Ubuntu 20.04 set to an Australian locale includes the 
"Thai X Terminal" package.
  This package should not be included.

  I noticed that it is also reported against Xubuntu and Lubuntu:
  https://bugs.launchpad.net/lubuntu-next/+bug/1747341

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

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


[Touch-packages] [Bug 1888101] Re: 'unsupported protocol' error when using PyMySQL

2020-08-12 Thread Leon
Hi Seth,

first install the server:
sudo apt install mariadb-server

then the PyMySQL:
python3 -m pip install PyMySQL

then create a ca-cert:
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca-cert.pem

then run this python-test-script:
import os
import pymysql

#pymysql.connections.DEBUG = True
#pymysql._auth.DEBUG = True

host = "127.0.0.1"
port = 3306

ca = os.path.expanduser("~/ca-cert.pem")
ssl = {'ca': ca, 'check_hostname': False}

user = 'user'
passwd = 'passwd'


def test_ssl():
con = pymysql.connect(user=user, password=passwd, host=host, port=port, 
ssl=ssl)
con.close()

test_ssl()

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

Title:
  'unsupported protocol' error when using PyMySQL

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  1)
  Description:  Ubuntu 20.04 LTS
  Release:  20.04

  2)
  openssl:
Installiert:   1.1.1f-1ubuntu2
Installationskandidat: 1.1.1f-1ubuntu2
Versionstabelle:
   *** 1.1.1f-1ubuntu2 500
  500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  3) + 4)
  I am trying to connect to my MariaDB with python package "PyMySQL" and SSL 
enabled. On my old installation (Kubuntu 19.10) this worked. With the new 
installation (also new PC: Xubuntu 20.04) I get this error message:

  ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol
  (_ssl.c:1108)

  Here are my installation details:
  Old installation: python 3.7.5, pymysql 0.9.3, ssl.OPENSSL_VERSION = 1.1.1c 
28 May 2019
  New installation: python 3.8.2, pymysql 0.9.3, ssl.OPENSSL_VERSION = 1.1.1f 
31 Mar 2020

  When I use python with a different SSL version...:
  this works: python 3.7.5, ssl.OPENSSL_VERSION = OpenSSL 1.1.0m-dev xx XXX 
  this works: python 3.7.5, ssl.OPENSSL_VERSION = OpenSSL 1.1.1h-dev xx XXX 
  this works: python 3.8.2, ssl.OPENSSL_VERSION = OpenSSL 1.1.1h-dev xx XXX 

  
  It seems, like the one specific version of openSSL (1.1.1f 31 Mar 2020) does 
not work together with PyMySQL.

  Some more details I have posted here:
  
https://stackoverflow.com/questions/62964998/unsupported-protocol-error-when-using-pymysql

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssl 1.1.1f-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
  Uname: Linux 5.4.0-40-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.4
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: XFCE
  Date: Sat Jul 18 15:42:27 2020
  InstallationDate: Installed on 2020-07-13 (4 days ago)
  InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1868501] Re: software-properties-gtk is blank when run as normal user.

2020-08-12 Thread Daniele
I had the same problem, after the upgrade from 18.04 to 20.04.1 it it opens 
correctly.
Then I removed some useless repositories and when updating the list the 
software hung and I had to force its closing.
After that it opens only with root permissions (sudo software-properties-gtk).

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

Title:
  software-properties-gtk is blank when run as normal user.

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  Upgraded install from 19.10

  "Software & Updates" windows is blank when initiated from either the
  terminal or via the "Settings..." button in the "Software Updater".

  If I run "software-properties-gtk" in the terminal the window is also blank.
  If I run it with sudo the "Software and Updates" window opens as normal.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: software-properties-gtk 0.98.7
  ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
  Uname: Linux 5.4.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu21
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Mar 22 21:30:12 2020
  InstallationDate: Installed on 2019-12-15 (98 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  PackageArchitecture: all
  SourcePackage: software-properties
  UpgradeStatus: Upgraded to focal on 2020-03-22 (0 days ago)

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

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