[Touch-packages] [Bug 1822754] [NEW] Chrome and other programs not resizing on HiDPI and Non-Hidpi setup
Public bug reported: To try the new support for EGLStreams and Wayland I have directly tried some programs to see how this performs. Unfortunately there are multiple problems: Chrome does not use GPU hardware acceleration anymore (I get huge CPU spikes while scrolling on normal pages). Also the automatic resizing when a program is moved from one display to another only works with system applications such as settings, terminal etc. The programs then are still scaled 2x on the Non-HIDPI screen. I am running the latest NVIDIA Drivers with 418.56. Is there a fix for this behaviour? Best Nicolas ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Ist ein Verzeichnis: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 418.56 Fri Mar 15 12:59:26 CDT 2019 GCC version: gcc version 8.3.0 (Ubuntu 8.3.0-3ubuntu1) ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Keine Berechtigung: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 11:25:53 2019 DistUpgraded: 2019-03-31 23:11:06,205 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py' DistroCodename: disco DistroVariant: ubuntu DkmsStatus: nvidia, 418.56, 5.0.0-8-generic, x86_64: installed rtl8814au, 4.3.21, 4.18.0-16-generic, x86_64: installed rtl8814au, 4.3.21, 5.0.0-8-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation GP104 [GeForce GTX 1070 Ti] [10de:1b82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] GP104 [GeForce GTX 1070 Ti] [1462:c303] InstallationDate: Installed on 2019-01-04 (87 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: MSI MS-7976 ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/usr/bin/zsh ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-8-generic root=UUID=367ba2c7-63e9-46a2-9d19-aa86d3dcc21d ro quiet splash nvidia-drm.modeset=1 vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to disco on 2019-03-31 (1 days ago) dmi.bios.date: 04/25/2017 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.I0 dmi.board.asset.tag: Default string dmi.board.name: Z170A GAMING M7 (MS-7976) dmi.board.vendor: MSI dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: MSI dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.I0:bd04/25/2017:svnMSI:pnMS-7976:pvr1.0:rvnMSI:rnZ170AGAMINGM7(MS-7976):rvr1.0:cvnMSI:ct3:cvr1.0: dmi.product.family: Default string dmi.product.name: MS-7976 dmi.product.sku: Default string dmi.product.version: 1.0 dmi.sys.vendor: MSI nvidia-settings: ERROR: Unable to find display on any available system ERROR: Unable to find display on any available system version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.1-1ubuntu1 version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20180925-2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: wayland (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug disco performance possible-manual-nvidia-install ubuntu wayland-session ** Package changed: xorg (Ubuntu) => wayland (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/1822754 Title: Chrome and other programs not resizing on HiDPI and Non-Hidpi setup Status in wayland package in Ubuntu: New Bug description: To try the new support for EGLStreams and Wayland I have directly tried some programs to see how this performs. Unfortunately there are multiple problems: Chrome does not use GPU hardware acceleration anymore (I get huge CPU spikes while scrolling on normal pages). Also the automatic resizing when a program is moved from one display to another only works with system applications such as settings, terminal etc. The programs then are still scaled 2x on the Non-HIDPI screen. I am running the latest NVIDIA Drivers with 418.56. Is there a fix for this behaviour? Best Nicolas ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12
[Touch-packages] [Bug 1816221] Re: package libpam-systemd:amd64 239-7ubuntu10.7 failed to install/upgrade: installed libpam-systemd:amd64 package post-installation script subprocess returned error exi
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1816221 Title: package libpam-systemd:amd64 239-7ubuntu10.7 failed to install/upgrade: installed libpam-systemd:amd64 package post- installation script subprocess returned error exit status 128 Status in systemd package in Ubuntu: Confirmed Bug description: My mouse locks up and the only way out is a remote reboot ProblemType: Package DistroRelease: Ubuntu 18.10 Package: libpam-systemd:amd64 239-7ubuntu10.7 ProcVersionSignature: Ubuntu 4.18.0-15.16-generic 4.18.20 Uname: Linux 4.18.0-15-generic x86_64 ApportVersion: 2.20.10-0ubuntu13.2 Architecture: amd64 Date: Sat Feb 16 00:47:02 2019 DuplicateSignature: package:libpam-systemd:amd64:239-7ubuntu10.7 Setting up libpam-systemd:amd64 (239-7ubuntu10.7) ... Use of uninitialized value $ret in string eq at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 134. dpkg: error processing package libpam-systemd:amd64 (--configure): installed libpam-systemd:amd64 package post-installation script subprocess returned error exit status 128 ErrorMessage: installed libpam-systemd:amd64 package post-installation script subprocess returned error exit status 128 InstallationDate: Installed on 2019-01-28 (19 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) Python3Details: /usr/bin/python3.6, Python 3.6.7, python3-minimal, 3.6.7-1~18.10 PythonDetails: /usr/bin/python2.7, Python 2.7.15+, python-minimal, 2.7.15-3 RelatedPackageVersions: dpkg 1.19.0.5ubuntu5 apt 1.7.2 SourcePackage: systemd Title: package libpam-systemd:amd64 239-7ubuntu10.7 failed to install/upgrade: installed libpam-systemd:amd64 package post-installation script subprocess returned error exit status 128 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1816221/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822730] [NEW] Disco server install fails to boot using encrypted partitions
Public bug reported: Performing a fresh Disco (daily build from 2019-03-31) server install with / mounted from LVM over dm-crypt (over mdadm), the boot fails just after asking the encrypted partition passphrase with the following error: /scripts/local-top/cryptroot: line 1: fold: not found Building a custom busybox package with "fold" binary enabled for busybox-initramfs and busybox-static configs fixes the issue. Diff from debian/ directory: diff --git a/config/pkg/initramfs b/config/pkg/initramfs index 2ef98e5..5725daf 100644 --- a/config/pkg/initramfs +++ b/config/pkg/initramfs @@ -228,7 +228,7 @@ CONFIG_EXPR=y CONFIG_EXPR_MATH_SUPPORT_64=y # CONFIG_FACTOR is not set CONFIG_FALSE=y -# CONFIG_FOLD is not set +CONFIG_FOLD=y # CONFIG_FSYNC is not set # CONFIG_HEAD is not set # CONFIG_FEATURE_FANCY_HEAD is not set diff --git a/config/pkg/udeb b/config/pkg/udeb index 7538ae5..f9a6d4c 100644 --- a/config/pkg/udeb +++ b/config/pkg/udeb @@ -228,7 +228,7 @@ CONFIG_EXPR=y CONFIG_EXPR_MATH_SUPPORT_64=y # CONFIG_FACTOR is not set CONFIG_FALSE=y -# CONFIG_FOLD is not set +CONFIG_FOLD=y # CONFIG_FSYNC is not set CONFIG_HEAD=y CONFIG_FEATURE_FANCY_HEAD=y It might be enough to add "fold" to the initramfs variant only. ** Affects: busybox (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/1822730 Title: Disco server install fails to boot using encrypted partitions Status in busybox package in Ubuntu: New Bug description: Performing a fresh Disco (daily build from 2019-03-31) server install with / mounted from LVM over dm-crypt (over mdadm), the boot fails just after asking the encrypted partition passphrase with the following error: /scripts/local-top/cryptroot: line 1: fold: not found Building a custom busybox package with "fold" binary enabled for busybox-initramfs and busybox-static configs fixes the issue. Diff from debian/ directory: diff --git a/config/pkg/initramfs b/config/pkg/initramfs index 2ef98e5..5725daf 100644 --- a/config/pkg/initramfs +++ b/config/pkg/initramfs @@ -228,7 +228,7 @@ CONFIG_EXPR=y CONFIG_EXPR_MATH_SUPPORT_64=y # CONFIG_FACTOR is not set CONFIG_FALSE=y -# CONFIG_FOLD is not set +CONFIG_FOLD=y # CONFIG_FSYNC is not set # CONFIG_HEAD is not set # CONFIG_FEATURE_FANCY_HEAD is not set diff --git a/config/pkg/udeb b/config/pkg/udeb index 7538ae5..f9a6d4c 100644 --- a/config/pkg/udeb +++ b/config/pkg/udeb @@ -228,7 +228,7 @@ CONFIG_EXPR=y CONFIG_EXPR_MATH_SUPPORT_64=y # CONFIG_FACTOR is not set CONFIG_FALSE=y -# CONFIG_FOLD is not set +CONFIG_FOLD=y # CONFIG_FSYNC is not set CONFIG_HEAD=y CONFIG_FEATURE_FANCY_HEAD=y It might be enough to add "fold" to the initramfs variant only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1822730/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822717] Re: SRU: build more cross packages on arm64 and ppc64el
Hello Matthias, or anyone else affected, Accepted binutils into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/binutils/2.30-21ubuntu1~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 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: binutils (Ubuntu Bionic) Status: New => 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 binutils in Ubuntu. https://bugs.launchpad.net/bugs/1822717 Title: SRU: build more cross packages on arm64 and ppc64el Status in binutils package in Ubuntu: New Status in binutils source package in Bionic: Fix Committed Status in binutils source package in Cosmic: Fix Committed Bug description: extending LP: #1769657, this builds more cross packages on arm64 and ppc64el: * Build ppc64el packages on arm64. * Build s390x packages on arm64 and ppc64el. * Build riscv64 packages on arm64 and ppc64el. SRU information: This is a no-change upload for all existing binary packages, it just add some more new cross packages. Regression potential is the same as for any other no-change upload. Test case: make sure the selected new cross packages build on the newly enabled architectures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1822717/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1796251] Re: gnome-shell crashed with SIGSEGV in __strlen_avx2() from real_save_png() from gdk_pixbuf__png_image_save_to_callback() from gdk_pixbuf_real_save_to_callback() from g
** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/issues #1017 https://gitlab.gnome.org/GNOME/gnome-shell/issues/1017 ** Also affects: gnome-shell via https://gitlab.gnome.org/GNOME/gnome-shell/issues/1017 Importance: Unknown Status: Unknown ** Changed in: gdk-pixbuf (Ubuntu) Status: Confirmed => Invalid ** Changed in: gnome-shell (Ubuntu) Status: Confirmed => Triaged ** Tags added: fixed-in-3.32.1 fixed-upstream ** No longer affects: gdk-pixbuf -- 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/1796251 Title: gnome-shell crashed with SIGSEGV in __strlen_avx2() from real_save_png() from gdk_pixbuf__png_image_save_to_callback() from gdk_pixbuf_real_save_to_callback() from gdk_pixbuf_save_to_callbackv() Status in GNOME Shell: Unknown Status in gdk-pixbuf package in Ubuntu: Invalid Status in gnome-shell package in Ubuntu: Triaged Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-shell. This problem was most recently seen with package version 3.30.0-3ubuntu1, the problem page at https://errors.ubuntu.com/problem/1473c291c70d181ad72605561ac28f3b860445d5 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/gnome-shell/+bug/1796251/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 33101] Re: update-initramfs -u fails during install when /boot contains vmlinux symlink to an old kernel.
** Changed in: linux-signed-hwe (Ubuntu) Status: New => Invalid ** Changed in: initramfs-tools Status: New => Invalid -- 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/33101 Title: update-initramfs -u fails during install when /boot contains vmlinux symlink to an old kernel. Status in initramfs-tools: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux-signed-hwe package in Ubuntu: Invalid Bug description: I tried a Flight-4 i386 install on my amd64 and selected an old /boot partition that had a 2.6.9-amd64 kernel on it from a previous install. The install failed because update-initramfs -u was being run as part of a post install script (for either initramfs-tools, initrd-tools, or udev I can't recall exactly). update-initramfs was erroring out with: "Kernel too old, requires at least 2.6.12". I fixed the problem by dropping into a console and removing the old kernel and the symlinks (vmlinux, initrd) that had been created to the old kernels, and then rerunning update-initramfs. To manage notifications about this bug go to: https://bugs.launchpad.net/initramfs-tools/+bug/33101/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
Just to add some more detail to this bug; for the impacted deployment we actually ended up re-configuring the power regulator settings via the BIOS to delegate to the OS for control; after a reboot we've just stuck with the default ondemand behaviour and performance has been consistent/better than before. -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822730] Re: Disco server install fails to boot using encrypted partitions
** Tags added: disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/1822730 Title: Disco server install fails to boot using encrypted partitions Status in busybox package in Ubuntu: New Bug description: Performing a fresh Disco (daily build from 2019-03-31) server install with / mounted from LVM over dm-crypt (over mdadm), the boot fails just after asking the encrypted partition passphrase with the following error: /scripts/local-top/cryptroot: line 1: fold: not found Building a custom busybox package with "fold" binary enabled for busybox-initramfs and busybox-static configs fixes the issue. Diff from debian/ directory: diff --git a/config/pkg/initramfs b/config/pkg/initramfs index 2ef98e5..5725daf 100644 --- a/config/pkg/initramfs +++ b/config/pkg/initramfs @@ -228,7 +228,7 @@ CONFIG_EXPR=y CONFIG_EXPR_MATH_SUPPORT_64=y # CONFIG_FACTOR is not set CONFIG_FALSE=y -# CONFIG_FOLD is not set +CONFIG_FOLD=y # CONFIG_FSYNC is not set # CONFIG_HEAD is not set # CONFIG_FEATURE_FANCY_HEAD is not set diff --git a/config/pkg/udeb b/config/pkg/udeb index 7538ae5..f9a6d4c 100644 --- a/config/pkg/udeb +++ b/config/pkg/udeb @@ -228,7 +228,7 @@ CONFIG_EXPR=y CONFIG_EXPR_MATH_SUPPORT_64=y # CONFIG_FACTOR is not set CONFIG_FALSE=y -# CONFIG_FOLD is not set +CONFIG_FOLD=y # CONFIG_FSYNC is not set CONFIG_HEAD=y CONFIG_FEATURE_FANCY_HEAD=y It might be enough to add "fold" to the initramfs variant only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1822730/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
@Frank - that is good for you and thanks for confirming my assumptions. But it is unfortunate for openssh :-/ ** Bug watch added: github.com/hashicorp/vagrant/issues #10730 https://github.com/hashicorp/vagrant/issues/10730 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
Until resolved - as a landing page (I'll put that in the description as well): The summary for the workarounds for now is: You can configure your /etc/ssh/ssh_config permanently Host * IPQoS lowdelay throughput Or per command via: $ ssh -o IPQoS=throughput user@host --- Per the other bugs and discussions this seems to affect any VMWare backed hosts which I guess most commonly would be: - VMware based computing centers - vagrant users through the vmware backend (see [7]) - home users of VMWare player We will have to make our decision for Ubuntu the same way Fedora did [1] for themselve. They decided to keep the change and be broken on VMWare for now. I'd not like to break users right now already with the soon to be released 19.04. How are the opinions about for now reverting [2] for 19.04 to give VMWare a chance to fix it up in their products. We could then get into contact with VMWare (I can do that) that this was a close gap action for just now. Without such a discussion I'm not sure on this as [3][4] are community discussions but no bug reports, as well as [5] being wrong as it isn't a open-vm-tools bug. But I'd also make clear that we intend drop that revert in 19.10 and later. I'm polling a few people for opinions on this change (it is easy to do, but hard to decide). [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1624437#c8 [2]: https://anongit.mindrot.org/openssh.git/commit/?id=5ee8448ad7c306f05a9f56769f95336a8269f379 [3]: https://communities.vmware.com/message/2803219 [4]: https://communities.vmware.com/thread/590825 [5]: https://github.com/vmware/open-vm-tools/issues/287 [6]: https://github.com/hashicorp/vagrant/issues/10730 ** Changed in: openssh (Ubuntu) Status: Incomplete => Triaged ** Changed in: openssh (Ubuntu) Importance: Undecided => Critical ** Tags added: server-next ** Description changed: + New versions of openssh (as in Ubuntu 19.04) are reported to trigger a + connection issue: + +packet_write_wait: Connection to x.x.x.x port 22: Broken pipe + + In most of the cases this seems to affect VMWare based environments as + there is a bug in their implementation in regard to the traffic shaping + protocols. + + Until resolved by VMWare the workarounds for now are: + + Configure your client to use the old defaults permanently in + => /etc/ssh/ssh_config + Host * + IPQoS lowdelay throughput + # You might want to limit to your VMware based systems + + Or per command via: + $ ssh IPQoS="latency throughput" user@host + + Two values as one is for interactive and one for non-interactive use + cases. + + original report + Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: - LANGUAGE=en_US - PATH=(custom, no user) - XDG_RUNTIME_DIR= - LANG=en_US.UTF-8 - SHELL=/bin/bash + LANGUAGE=en_US + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=en_US.UTF-8 + SHELL=/bin/bash RelatedPackageVersions: - ssh-askpass N/A - libpam-sshN/A - keychain N/A - ssh-askpass-gnome N/A + ssh-askpass N/A + libpam-sshN/A + keychain N/A + ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
I don't want to revert this as that just takes the pressure off VMware; ultimately this is their bug that they need to fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822717] Re: SRU: build more cross packages on arm64 and ppc64el
Hello Matthias, or anyone else affected, Accepted binutils into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/binutils/2.31.1-6ubuntu1.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 and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Description changed: extending LP: #1769657, this builds more cross packages on arm64 and ppc64el: - * Build ppc64el packages on arm64. - * Build s390x packages on arm64 and ppc64el. - * Build riscv64 packages on arm64 and ppc64el. + * Build ppc64el packages on arm64. + * Build s390x packages on arm64 and ppc64el. + * Build riscv64 packages on arm64 and ppc64el. SRU information: This is a no-change upload for all existing binary packages, it just add some more new cross packages. Regression potential is the same as for any other no-change upload. + + Test case: make sure the selected new cross packages build on the newly + enabled architectures. ** Changed in: binutils (Ubuntu Cosmic) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-cosmic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1822717 Title: SRU: build more cross packages on arm64 and ppc64el Status in binutils package in Ubuntu: New Status in binutils source package in Bionic: New Status in binutils source package in Cosmic: Fix Committed Bug description: extending LP: #1769657, this builds more cross packages on arm64 and ppc64el: * Build ppc64el packages on arm64. * Build s390x packages on arm64 and ppc64el. * Build riscv64 packages on arm64 and ppc64el. SRU information: This is a no-change upload for all existing binary packages, it just add some more new cross packages. Regression potential is the same as for any other no-change upload. Test case: make sure the selected new cross packages build on the newly enabled architectures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1822717/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
Colin was so kind to also find this reference [1] in Debian. Which asks about the same revert, but not yet for it affecting VMWare - instead it seems it also conflicts with "iptables -m tos" as well. I'll bring it up with VMWare, but if also conflicting with some iptables options that would be one more reason to revert it for 19.04, but none of us has looked deeper into it yet. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879 ** Bug watch added: Debian Bug tracker #923879 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822745] [NEW] /usr/bin/unattended-upgrade:IsADirectoryError:/usr/bin/unattended-upgrade@2138:main:run:conffile_prompt
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 1.5ubuntu3.18.10.3, the problem page at https://errors.ubuntu.com/problem/7551745f47e60a92582dfa16b5ae7f1c0383d5f7 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: cosmic -- 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/1822745 Title: /usr/bin/unattended-upgrade:IsADirectoryError:/usr/bin/unattended- upgrade@2138:main:run:conffile_prompt 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 1.5ubuntu3.18.10.3, the problem page at https://errors.ubuntu.com/problem/7551745f47e60a92582dfa16b5ae7f1c0383d5f7 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/1822745/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
See also LP: #1732696 and LP: #1579278. -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1796251] Re: gnome-shell crashed with SIGSEGV in __strlen_avx2() from real_save_png() from gdk_pixbuf__png_image_save_to_callback() from gdk_pixbuf_real_save_to_callback() from g
** Changed in: gnome-shell Status: Unknown => Fix Released -- 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/1796251 Title: gnome-shell crashed with SIGSEGV in __strlen_avx2() from real_save_png() from gdk_pixbuf__png_image_save_to_callback() from gdk_pixbuf_real_save_to_callback() from gdk_pixbuf_save_to_callbackv() Status in GNOME Shell: Fix Released Status in gdk-pixbuf package in Ubuntu: Invalid Status in gnome-shell package in Ubuntu: Triaged Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-shell. This problem was most recently seen with package version 3.30.0-3ubuntu1, the problem page at https://errors.ubuntu.com/problem/1473c291c70d181ad72605561ac28f3b860445d5 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/gnome-shell/+bug/1796251/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
Something I was not previously aware of that informs this a bit more, is that in some BIOS modes (apparently HP uses this extensively, unsure about Dell and others) you get a "Collaborative Power Control" mode, which sets the scaling_driver to pcc-cpufreq (as opposed to cpufreq) and is some weird hybrid of OS+BIOS defined behavior. In the case of these collaborative modes, the exact behavior is probably wildly different based on what the BIOS is doing and likely would explain why we get weird and inconsistent performance behavior. Unclear to me if such BIOS modes will still use intel_pstate or not.. something I'd have to look into. Or whether it's specific to pre-pstate. Some more information about collaborative mode in this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447763 -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
(as context to this information, apparently this particularly bad performance experienced with 'powersave' happens when the BIOS power control is set to the default, and goes away when in the BIOS you set power management to 'os control' - so there is some additional information needed to determine why this particular case offers bad performance, when as shown below, powersave/performance governors should not normally present more than a few percent performance difference) I would have not expected the governor choice (powersave or otherwise) to limit performance so severely as to prevent a VM from booting/working usefully. I would expect the frequency governor settings to see make a difference in benchmarks and power usage, not general interactive performance. The phoronix data referred to later supports that view (the performance difference is minimal generally). The behavior you experienced is really a bug in my view. On modern Intel CPUs (Sandy Bridge and newer, many 2011/2012+ models but varies depending on the exact CPU) the Intel "Pstate" driver is used which is significantly different to the older "cpufreq" driver. This is important to note as you have the two different drivers in use based on which CPU you have - rather than OS (Xenial/Bionic use the same settings). Although both drivers have governor modes with the name "powersave" and "performance" they are similar in name only and their behavior is quite different and they do not share any code. To that end you may find different behavior between some kind of test/lab environment which is not unlikely to have much older hardware and current new hardware FCBs. It would also be good to know for this specific badly broken system which scaling_driver was in use and what the precise processor model information from /proc/cpuinfo. This article from Phoronix was released recently which compares the performance with various different benchmarks as well as power-usage of the various driver and governor mode combinations (it's a good read separately) https://www.phoronix.com/scan.php?page=article=linux50-pstate-cpufreq It has a few interesting observations. In the majority of benchmarks the performance between the two is very similar, and in fact the p-state powersave governor is slightly faster (!) than the pstate performance governor in many of the tests by a small margin. Another major observation from the phoronix data is that the CPUfreq-powersave governor is VERY significantly slower, by a factor of 4-5 times in most cases. While the *cpufreq*-powersave (which remember, is different to the intel_pstate-powersave governor, which should be used) governor is very slow, it should also not be used by default on any Xenial or Bionic system from what I can see unless I am missing another script/tool that is changing the governor somewhere (I couldn't see any scripts in the charm or qemu packages that do so). If we read the code of the systemd service on bionic to set the CPU scheduler, we find that the script /lib/systemd/set-cpufreq (which is an Ubuntu/Debian addition, not systemd upstream, xenial uses more or less the same script at /etc/init.d/ondemand) it is quite simple and will basically prefer "interactive", "ondemand" and "powersave" in that order if they exist. This should result in non-pstate systems using ondemand (correct) and pstate systems using powersave (also correct). So it seems the bug is most likely not in the script, but some strange interaction with the BIOS that needs to be investigated further. To that end if anyone with an affected system with noticeably worse performance in powersave/ondemand, I'd love to either get access or see the following data: - Output of "sudo dmidecode" - A copy of /sys/devices/system/cpu/cpufreq (tar is fine) with particular attention to the values of scaling_driver and scaling_governor - A basic CPU benchmark, run under 'powertop' to collect information on the frequency and idle states. You can run that like so "sudo powertop -C test.csv -r test.html --workload=/usr/bin/updatedb" - it will output a CSV and HTML file with the data. But we probably need a better benchmark that updatedb and I'm not 100% sure off the top of my head what we could use - I suggest we could try a few things on a "broken" machine to figure out benchmark we can use that reflects the poor performance - updatedb may well do the job but it's not what I'd actually suggest we use. Ideally we would collect this information in a matrix of all 4 combinations of: CPU Governor (Default Ubuntu, User Optimised) and BIOS setting (OS Control, BIOS Default) so we can understand why we get the pathologically bad performance in some cases of BIOS Default + powersave. -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu
[Touch-packages] [Bug 1819487] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2019-04-02 07:38 EDT--- IBM Bugzilla status -> closed, Fix Released with Disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1819487 Title: sshd crashed on s390x with hw crypto enabled Status in Ubuntu on IBM z Systems: Fix Released Status in openssh package in Ubuntu: Invalid Status in openssl-ibmca package in Ubuntu: Fix Released Bug description: While using today's daily image of disco (either in z/VM or on LPAR) and enabling s309x hardware crypto support in openssh, sshd crashes with the following messages: $ ssh ubuntu@localhost The authenticity of host 'localhost (::1)' can't be established. ECDSA key fingerprint is SHA256:KoTYC0jCQPtmsOMmBW9DrCiBbkrKTL0leQ/zoIaInNw. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. ubuntu@localhost's password: packet_write_wait: Connection to ::1 port 22: Broken pipe (local session is sufficient to reproduce) Steps to reproduce - on disco daily: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Codename: disco $ uname -a Linux zlin42 5.0.0-7-generic #8-Ubuntu SMP Mon Mar 4 16:25:21 UTC 2019 s390x s390x s390x GNU/Linux - enable z hw crypto support for openssh on an Ubuntu host (zlin42) on s390x like this: - sudo apt-get install openssl-ibmca libica-utils libica3 - sudo tee -a /etc/ssl/openssl.cnf < /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample - sudo sed -i 's/^\(openssl_conf = openssl_def.*$\)/# \1/g' /etc/ssl/openssl.cnf - sudo sed -i '10i openssl_conf = openssl_def' /etc/ssl/openssl.cnf - afterwards ssh login attempts fail (existing session are unaffected): $ ssh ubuntu@localhost The authenticity of host 'localhost (::1)' can't be established. ECDSA key fingerprint is SHA256:KoTYC0jCQPtmsOMmBW9DrCiBbkrKTL0leQ/zoIaInNw. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. ubuntu@localhost's password: packet_write_wait: Connection to ::1 port 22: Broken pipe [94629.032586] User process fault: interruption code 003b ilc:2 in libpthread-2.29.so[3ff7d48+1c000] [94629.032597] Failing address: TEID: 0800 [94629.032598] Fault in primary space mode while using user ASCE. [94629.032601] AS:0007450281c7 R3:0024 [94629.032606] CPU: 0 PID: 8183 Comm: sshd Not tainted 5.0.0-7-generic #8-Ubuntu [94629.032607] Hardware name: IBM 2964 N63 400 (LPAR) [94629.032608] User PSW : 070520018000 03ff7d48e954 [94629.032610]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 [94629.032611] User GPRS: 03ff7e0085c8 [94629.032612]03ff7e510108 03ff7db1c3a8 03fff857eea0 [94629.032613]03ff7e525040 02aa3f5ec090 03ff7e4916f0 03ff7e4921a8 [94629.032614]03ff7db17c18 0002 03ff7e07238a 03fff857ea20 [94629.032622] User Code: 03ff7d48e946: b9040012 lgr %r1,%r2 03ff7d48e94a: e3f0ff60ff71 lay %r15,-160(%r15) #03ff7d48e950: 4700 bc 0,0 >03ff7d48e954: 58202018 l %r2,24(%r2) 03ff7d48e958: b24f00b0 ear %r11,%a0 03ff7d48e95c: ebbb002d sllg %r11,%r11,32 03ff7d48e962: b24f00b1 ear %r11,%a1 03ff7d48e966: 5920b0d0 c %r2,208(%r11) [94629.032634] Last Breaking-Event-Address: [94629.032638] [<03ff7df773b4>] 0x3ff7df773b4 For more details see attachments ... --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu23 Architecture: s390x DistroRelease: Ubuntu 19.04 Package: openssh-server 1:7.9p1-9 PackageArchitecture: s390x ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code -11: Tags: disco Uname: Linux 5.0.0-7-generic s390x UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: pkcs11 _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1819487/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
Just to be prepared I added an MP for this at [1]. But I agree to cjwatson that we should (if possible) either revert this in Buster+Disco or none of them to not split up the behavior of different releases even more. Never the less, one might want to peek at the change and or play with the PPA [2]. Therefore it is worth having that ready here on the bug. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/openssh/+git/openssh/+merge/365396 [2]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1822370-openssh-qos-defaults -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
FYI - Up for discussion in the scope of Debian-Buster at [1]. [1]: https://lists.debian.org/debian-devel/2019/04/msg00010.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/openssh/+git/openssh/+merge/365396 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822736] Re: Passwords longer than 255 characters break authentication
** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1822736 Title: Passwords longer than 255 characters break authentication Status in pam package in Ubuntu: New Bug description: DISCUSSION When a password longer than 255 characters is set for any user account, this user will become unable to authenticate when running 'sudo' or 'passwd'. IMPACT This affects 18.04.2 systems, whether they were installed using Desktop (ubiquity) or Server (subiquity) installers. It may also affect other releases - this is yet untested. Tagged 'security' since these utilities then deny service to this user. REPRODUCTION # Add user 'test' with password 'testtest' sudo adduser --gecos '' test # Add user 'test' to the 'sudo' group sudo adduser test sudo # Become user 'test' sudo -iu test # Verify user 'test' can run commands via sudo sudo whoami # Change password of 'test' to this 255 character long password: 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to 'testtest': passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to this 256 character long password: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # This authentication fails, as sudo does not accept the 256 character password. # Attempting to change this password to a different value also fails: passwd # Effectively, user 'test' is now unable to use sudo, or to change their password. # The 'login' command, run by root, does, however, still enable user 'test' to login using the newly set 256 character password. # At the same time, a different restricted user who is a member of the 'sudo' group can still set a new password for 'test' (after authenticating to sudo with their own password) by supplying the current 256 character password using: sudo -u test passwd # Finally, to clean up sudo deluser --remove-home test ADDITIONAL OBSERVATIONS * A root-initiated 'login' command still allows this user to authenticate. * A different restricted user who is a member of the 'sudo' group can still set a new password for for this users' account (after authenticating to sudo with their own password) by supplying the >=256 character password CREDIT This was originally reported by 'Fieldy', I just reproduced it / filed this bug report. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libpam0g 1.1.8-3.6ubuntu2.18.04.1 ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-16-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 09:39:39 2019 SourcePackage: pam UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1822736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822768] [NEW] libgtk window resize problem
Public bug reported: An app using libgtk-3 as GUI-lib shows strange behaviour since on ubuntu 18.04 an later. The problem is, that a not resizeable window not sets its correct size, when it shows up a second and all further times - but the first time, the size is correct. In that window a gtk element is inserted while showing up, so the size have to be recalculated. This stange behaviour is only found on Ubuntu 18.04 and later (libgtk-3-0 >> 3.22.30-1ubuntu2 ONLY on ubuntu - not kubuntu). On Debian systems (stable and testing) and Kubuntu systems of the same version all things are all right. A short list, which versions have failures (os and libgtk-3-0 version) : debian stretch with 3.22.11 is OK debian buster with 3.24.5 is OK ubuntu 17.10with 3.22.25-0ubuntu0.1 is OK ubuntu 18.04 (also LTS version)with 3.22.30-1ubuntu2 failure ubuntu 18.10with 3.24.4-0ubuntu1 failure A screenshot of the correct first show of the window an the second on is attached. A minimal example would also be attached in a replay to this report. ** Affects: gtk+3.0 (Ubuntu) Importance: Undecided Status: New ** Attachment added: "screenshot of correct window size (left) and the faulty on (right)" https://bugs.launchpad.net/bugs/1822768/+attachment/5252034/+files/screenshot_gtk_window_resize_problem.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1822768 Title: libgtk window resize problem Status in gtk+3.0 package in Ubuntu: New Bug description: An app using libgtk-3 as GUI-lib shows strange behaviour since on ubuntu 18.04 an later. The problem is, that a not resizeable window not sets its correct size, when it shows up a second and all further times - but the first time, the size is correct. In that window a gtk element is inserted while showing up, so the size have to be recalculated. This stange behaviour is only found on Ubuntu 18.04 and later (libgtk-3-0 >> 3.22.30-1ubuntu2 ONLY on ubuntu - not kubuntu). On Debian systems (stable and testing) and Kubuntu systems of the same version all things are all right. A short list, which versions have failures (os and libgtk-3-0 version) : debian stretch with 3.22.11 is OK debian buster with 3.24.5 is OK ubuntu 17.10with 3.22.25-0ubuntu0.1 is OK ubuntu 18.04 (also LTS version)with 3.22.30-1ubuntu2 failure ubuntu 18.10with 3.24.4-0ubuntu1 failure A screenshot of the correct first show of the window an the second on is attached. A minimal example would also be attached in a replay to this report. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1822768/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
I filed this bug at Debian as well => https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=926229 ** Bug watch added: Debian Bug tracker #926229 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926229 ** Also affects: openssh (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926229 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: Unknown Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822768] Re: libgtk window resize problem
A minimal example program to reproduce the behaviour. In the example a click on "show subwindow" opens a second window, in which a component is inserted at showing up. On the first time all is ok like shown in the left part of the screenshot. But if you close the second (sub) window and open it again, then the is a wrong size calculation for the window size. Further testing shows up, that this only happen, when the window is set to not resizeable. As soon as the window is set to resizeable, all is ok. ** Attachment added: "minimal example program to reproduce the bug" https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1822768/+attachment/5252035/+files/example.tar -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1822768 Title: libgtk window resize problem Status in gtk+3.0 package in Ubuntu: New Bug description: An app using libgtk-3 as GUI-lib shows strange behaviour since on ubuntu 18.04 an later. The problem is, that a not resizeable window not sets its correct size, when it shows up a second and all further times - but the first time, the size is correct. In that window a gtk element is inserted while showing up, so the size have to be recalculated. This stange behaviour is only found on Ubuntu 18.04 and later (libgtk-3-0 >> 3.22.30-1ubuntu2 ONLY on ubuntu - not kubuntu). On Debian systems (stable and testing) and Kubuntu systems of the same version all things are all right. A short list, which versions have failures (os and libgtk-3-0 version) : debian stretch with 3.22.11 is OK debian buster with 3.24.5 is OK ubuntu 17.10with 3.22.25-0ubuntu0.1 is OK ubuntu 18.04 (also LTS version)with 3.22.30-1ubuntu2 failure ubuntu 18.10with 3.24.4-0ubuntu1 failure A screenshot of the correct first show of the window an the second on is attached. A minimal example would also be attached in a replay to this report. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1822768/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822754] Re: Chrome and other programs not resizing on HiDPI and Non-Hidpi setup
Could you please try installing the previous mutter version by downloading the .deb files from here: https://launchpad.net/ubuntu/+source/mutter/3.32.0-1/+build/16489975 and then install them all. ** Tags added: nvidia ** Package changed: wayland (Ubuntu) => mutter (Ubuntu) ** Changed in: mutter (Ubuntu) Status: New => Incomplete ** Tags added: hidpi -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1822754 Title: Chrome and other programs not resizing on HiDPI and Non-Hidpi setup Status in mutter package in Ubuntu: Incomplete Bug description: To try the new support for EGLStreams and Wayland I have directly tried some programs to see how this performs. Unfortunately there are multiple problems: Chrome does not use GPU hardware acceleration anymore (I get huge CPU spikes while scrolling on normal pages). Also the automatic resizing when a program is moved from one display to another only works with system applications such as settings, terminal etc. The programs then are still scaled 2x on the Non-HIDPI screen. I am running the latest NVIDIA Drivers with 418.56. Is there a fix for this behaviour? Best Nicolas ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Ist ein Verzeichnis: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 418.56 Fri Mar 15 12:59:26 CDT 2019 GCC version: gcc version 8.3.0 (Ubuntu 8.3.0-3ubuntu1) ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Keine Berechtigung: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 11:25:53 2019 DistUpgraded: 2019-03-31 23:11:06,205 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py' DistroCodename: disco DistroVariant: ubuntu DkmsStatus: nvidia, 418.56, 5.0.0-8-generic, x86_64: installed rtl8814au, 4.3.21, 4.18.0-16-generic, x86_64: installed rtl8814au, 4.3.21, 5.0.0-8-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation GP104 [GeForce GTX 1070 Ti] [10de:1b82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] GP104 [GeForce GTX 1070 Ti] [1462:c303] InstallationDate: Installed on 2019-01-04 (87 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: MSI MS-7976 ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/usr/bin/zsh ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-8-generic root=UUID=367ba2c7-63e9-46a2-9d19-aa86d3dcc21d ro quiet splash nvidia-drm.modeset=1 vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to disco on 2019-03-31 (1 days ago) dmi.bios.date: 04/25/2017 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.I0 dmi.board.asset.tag: Default string dmi.board.name: Z170A GAMING M7 (MS-7976) dmi.board.vendor: MSI dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: MSI dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.I0:bd04/25/2017:svnMSI:pnMS-7976:pvr1.0:rvnMSI:rnZ170AGAMINGM7(MS-7976):rvr1.0:cvnMSI:ct3:cvr1.0: dmi.product.family: Default string dmi.product.name: MS-7976 dmi.product.sku: Default string dmi.product.version: 1.0 dmi.sys.vendor: MSI nvidia-settings: ERROR: Unable to find display on any available system ERROR: Unable to find display on any available system version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.1-1ubuntu1 version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20180925-2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1822754/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1745032] Re: AC adapter status not detected on Asus ZenBook UX410UAK
This bug was fixed in the package linux - 4.15.0-47.50
---
linux (4.15.0-47.50) bionic; urgency=medium
* linux: 4.15.0-47.50 -proposed tracker (LP: #1819716)
* Packaging resync (LP: #1786013)
- [Packaging] resync getabis
- [Packaging] update helper scripts
- [Packaging] resync retpoline extraction
* C++ demangling support missing from perf (LP: #1396654)
- [Packaging] fix a mistype
* arm-smmu-v3 arm-smmu-v3.3.auto: CMD_SYNC timeout (LP: #1818162)
- iommu/arm-smmu-v3: Fix unexpected CMD_SYNC timeout
* Crash in nvme_irq_check() when using threaded interrupts (LP: #1818747)
- nvme-pci: fix out of bounds access in nvme_cqe_pending
* CVE-2019-9213
- mm: enforce min addr even if capable() in expand_downwards()
* CVE-2019-3460
- Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt
* amdgpu with mst WARNING on blanking (LP: #1814308)
- drm/amd/display: Don't use dc_link in link_encoder
- drm/amd/display: Move wait for hpd ready out from edp power control.
- drm/amd/display: eDP sequence BL off first then DP blank.
- drm/amd/display: Fix unused variable compilation error
- drm/amd/display: Fix warning about misaligned code
- drm/amd/display: Fix MST dp_blank REG_WAIT timeout
* tun/tap: unable to manage carrier state from userland (LP: #1806392)
- tun: implement carrier change
* CVE-2019-8980
- exec: Fix mem leak in kernel_read_file
* raw_skew in timer from the ubuntu_kernel_selftests failed on Bionic
(LP: #1811194)
- selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock
adjustments are in progress
* [Packaging] Allow overlay of config annotations (LP: #1752072)
- [Packaging] config-check: Add an include directive
* CVE-2019-7308
- bpf: move {prev_,}insn_idx into verifier env
- bpf: move tmp variable into ax register in interpreter
- bpf: enable access to ax register also from verifier rewrite
- bpf: restrict map value pointer arithmetic for unprivileged
- bpf: restrict stack pointer arithmetic for unprivileged
- bpf: restrict unknown scalars of mixed signed bounds for unprivileged
- bpf: fix check_map_access smin_value test when pointer contains offset
- bpf: prevent out of bounds speculation on pointer arithmetic
- bpf: fix sanitation of alu op with pointer / scalar type from different
paths
- bpf: add various test cases to selftests
* CVE-2017-5753
- bpf: properly enforce index mask to prevent out-of-bounds speculation
- bpf: fix inner map masking to prevent oob under speculation
* BPF: kernel pointer leak to unprivileged userspace (LP: #1815259)
- bpf/verifier: disallow pointer subtraction
* squashfs hardening (LP: #1816756)
- squashfs: more metadata hardening
- squashfs metadata 2: electric boogaloo
- squashfs: more metadata hardening
- Squashfs: Compute expected length from inode size rather than block length
* efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted (LP: #1814982)
- efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted
* Update ENA driver to version 2.0.3K (LP: #1816806)
- net: ena: update driver version from 2.0.2 to 2.0.3
- net: ena: fix race between link up and device initalization
- net: ena: fix crash during failed resume from hibernation
* ipset kernel error: 4.15.0-43-generic (LP: #1811394)
- netfilter: ipset: Fix wraparound in hash:*net* types
* Silent "Unknown key" message when pressing keyboard backlight hotkey
(LP: #1817063)
- platform/x86: dell-wmi: Ignore new keyboard backlight change event
* CVE-2018-18021
- arm64: KVM: Tighten guest core register access from userspace
- KVM: arm/arm64: Introduce vcpu_el1_is_32bit
- arm64: KVM: Sanitize PSTATE.M when being set from userspace
* CVE-2018-14678
- x86/entry/64: Remove %ebx handling from error_entry/exit
* CVE-2018-19824
- ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in
card.c
* CVE-2019-3459
- Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer
* Bionic update: upstream stable patchset 2019-02-08 (LP: #1815234)
- fork: unconditionally clear stack on fork
- spi: spi-s3c64xx: Fix system resume support
- Input: elan_i2c - add ACPI ID for lenovo ideapad 330
- Input: i8042 - add Lenovo LaVie Z to the i8042 reset list
- Input: elan_i2c - add another ACPI ID for Lenovo Ideapad 330-15AST
- kvm, mm: account shadow page tables to kmemcg
- delayacct: fix crash in delayacct_blkio_end() after delayacct init failure
- tracing: Fix double free of event_trigger_data
- tracing: Fix possible double free in event_enable_trigger_func()
- kthread, tracing: Don't expose half-written comm when creating kthreads
- tracing/kprobes: Fix trace_probe flags on enable_trace_kprobe() failure
- tracing: Quiet gcc warning about maybe unused link
[Touch-packages] [Bug 1821091] Re: [FFe] Qt 5.12.2 update
Ok, it's really late for such a big landing and I'm worried it might complicate things, but seeing that all the packages are ready and that it's all well-coordinated by two people, I'll approve this FFe. Please be sure to proceed as soon as possible not to block the release. ** Changed in: qtbase-opensource-src (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtbase-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1821091 Title: [FFe] Qt 5.12.2 update Status in qtbase-opensource-src package in Ubuntu: Triaged Bug description: Dear Release Team, I would like to update Qt in disco from 5.11.3 to 5.12.2. The reasons are the following: 1) The 5.11 branch is EOL and no longer receiving any fixes. The 5.12 branch is LTS and will be supported for three years. 2) New versions of Plasma are going to require Qt 5.12, and the Kubuntu team would like to be able to package them in their backports PPA for disco. 3) In Qt 5.12, the memory usage of the QML Engine is reduced by up to 30 %. 4) Finally we will be able to sync all packages from Debian. I have managed to drop the delta in qtbase, qtmultimedia and qtwebkit. Why we haven’t packaged it early: we did not want to package 5.12.1 because it had some known bugs. And 5.12.2 was released upstream later than it was originally planned. Changelog: https://wiki.qt.io/New_Features_in_Qt_5.12 The packages are being prepared in https://launchpad.net/~ci-train- ppa-service/+archive/ubuntu/3680/+packages, but these will be replaced with syncs from Debian when qtbase and qtdeclarative get accepted from Debian’s NEW queue. This transition will require syncs of all Qt packages, and no-change rebuilds of packages that build-depend on qtbase5-private-dev or qtdeclarative5-private-dev. All Qt modules are in universe. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1821091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821091] Re: [FFe] Qt 5.12.2 update
Just give me a poke once you perform the uploads. I can then do a quick NEW review of the pyqt5webengine package. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtbase-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1821091 Title: [FFe] Qt 5.12.2 update Status in qtbase-opensource-src package in Ubuntu: Triaged Bug description: Dear Release Team, I would like to update Qt in disco from 5.11.3 to 5.12.2. The reasons are the following: 1) The 5.11 branch is EOL and no longer receiving any fixes. The 5.12 branch is LTS and will be supported for three years. 2) New versions of Plasma are going to require Qt 5.12, and the Kubuntu team would like to be able to package them in their backports PPA for disco. 3) In Qt 5.12, the memory usage of the QML Engine is reduced by up to 30 %. 4) Finally we will be able to sync all packages from Debian. I have managed to drop the delta in qtbase, qtmultimedia and qtwebkit. Why we haven’t packaged it early: we did not want to package 5.12.1 because it had some known bugs. And 5.12.2 was released upstream later than it was originally planned. Changelog: https://wiki.qt.io/New_Features_in_Qt_5.12 The packages are being prepared in https://launchpad.net/~ci-train- ppa-service/+archive/ubuntu/3680/+packages, but these will be replaced with syncs from Debian when qtbase and qtdeclarative get accepted from Debian’s NEW queue. This transition will require syncs of all Qt packages, and no-change rebuilds of packages that build-depend on qtbase5-private-dev or qtdeclarative5-private-dev. All Qt modules are in universe. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1821091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
** Changed in: openssh (Debian) Status: Unknown => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822775] Re: Different input sources per window not work
Confirmed. The setting can be changed in the "Region & Languague" panel: gnome-control-center region (cog icon next to "Input Sources" section) But this doesn't actually change the corresponding gsetting: $ gsettings get org.gnome.desktop.input-sources per-window false ** Package changed: ibus (Ubuntu) => gnome-control-center (Ubuntu) ** Changed in: gnome-control-center (Ubuntu) Status: New => Confirmed ** Tags added: rls-dd-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1822775 Title: Different input sources per window not work Status in gnome-control-center package in Ubuntu: Confirmed Bug description: Ubuntu 19.04 The option to apply different input source for each window doesn't work (it automatically reset itself) However, I manually change org.gnome.desktop.input-sources.per-window and it works. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1822775/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1754294] Re: After last updated libcurl3 on libcurl4, some apps are removed.
> None of the packages which you are having an issue with are ones from the official Ubuntu archive What about these? Why is libcurl3 even in Bionic as a conflicting package if nothing was supposed to use it? $ apt-cache rdepends libcurl3 libcurl3 Reverse Depends: libcurl-openssl1.0-dev |flashplugin-installer libxmltooling7 ruby-ethon -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1754294 Title: After last updated libcurl3 on libcurl4, some apps are removed. Status in curl package in Ubuntu: Confirmed Bug description: Hi! After last updated libcurl3 on libcurl4, system (Kubuntu 18.04 bionic) deleted such applications as: virtualbox-5.2 opera-stable slack-desktop mongodb I really need these applications, I installed them with broken dependencies, but they are deleted after each update. Is it possible to make the dependence of the libcurl3 in libcurl4, and not remove it altogether from system? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1754294/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820858] Re: /usr/bin/software-properties-gtk:RuntimeError(org.freedesktop.DBus.Python.RuntimeError):_on_clicked:_deferable:_convert_dbus_exception:_convert_dbus_exception:cancel
*** This bug is a duplicate of bug 1820860 *** https://bugs.launchpad.net/bugs/1820860 ** This bug has been marked a duplicate of bug 1820860 /usr/bin/software-properties-gtk:RuntimeError(org.freedesktop.DBus.Python.RuntimeError):on_driver_changes_cancel:_deferable:_convert_dbus_exception:_convert_dbus_exception:cancel:__call__:call_blocking:_inline_callbacks:get_uid_from_dbus_name:return_value:_inline_callbacks:_cancel:_inline_callbacks -- 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/1820858 Title: /usr/bin/software-properties- gtk:RuntimeError(org.freedesktop.DBus.Python.RuntimeError):_on_clicked:_deferable:_convert_dbus_exception:_convert_dbus_exception:cancel:__call__:call_blocking:_inline_callbacks:get_uid_from_dbus_name:return_value:_inline_callbacks:_cancel:_inline_callbacks Status in software-properties package in Ubuntu: New Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding software-properties. This problem was most recently seen with package version 0.97.9, the problem page at https://errors.ubuntu.com/problem/9dd1fadc5a92a7832c23ed5340c79bf6c9f88eee 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/software-properties/+bug/1820858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820860] Re: /usr/bin/software-properties-gtk:RuntimeError(org.freedesktop.DBus.Python.RuntimeError):on_driver_changes_cancel:_deferable:_convert_dbus_exception:_convert_dbus_exc
The issue was due to aptdaemon bug #1811694 not software-properties ** Changed in: software-properties (Ubuntu) Importance: Undecided => Low ** Changed in: software-properties (Ubuntu) Status: New => Invalid -- 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/1820860 Title: /usr/bin/software-properties- gtk:RuntimeError(org.freedesktop.DBus.Python.RuntimeError):on_driver_changes_cancel:_deferable:_convert_dbus_exception:_convert_dbus_exception:cancel:__call__:call_blocking:_inline_callbacks:get_uid_from_dbus_name:return_value:_inline_callbacks:_cancel:_inline_callbacks Status in software-properties package in Ubuntu: Invalid Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding software-properties. This problem was most recently seen with package version 0.97.9, the problem page at https://errors.ubuntu.com/problem/6567b1f317a885bc109de031608c5f1c675d1ae0 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/software-properties/+bug/1820860/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
No need to re-test these; it's already been included in bionic/cosmic
and bug comments are a side-effect of the changelogs for the upload with
this backport.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
[Touch-packages] [Bug 1658188] Re: /usr/share/apport/apport-gtk:TypeError:/usr/share/apport/apport-gtk@597:run_argv:run_crashes
Some how part of this fix got lost in Cosmic. ** Changed in: apport (Ubuntu Bionic) Status: New => Fix Released ** Changed in: apport (Ubuntu Cosmic) Status: New => In Progress ** Changed in: apport (Ubuntu Cosmic) Assignee: (unassigned) => Brian Murray (brian-murray) -- 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/1658188 Title: /usr/share/apport/apport-gtk:TypeError:/usr/share/apport/apport- gtk@597:run_argv:run_crashes Status in apport package in Ubuntu: Fix Released Status in apport source package in Xenial: Fix Released Status in apport source package in Bionic: Fix Released Status in apport source package in Cosmic: In Progress Bug description: [Test Case] Check Error Tracker bucket and make sure version from -proposed doesn't show up there. Given that this happens a whole bunch we should know pretty quick if its fixed. [Regression Potential] The test being modified is designed to not report crashes that happen during logout. It's possible that some reports don't have a Date in them but in that case we couldn't compare the logind_session information to the Date anyway so those crashes would have been reported anyway. Regardless, the potential is that we'll have some more crashes reported about things crashing on logout which is better than the hundreds of crashes we get like this one. The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with package version 2.20.3-0ubuntu8.2, the problem page at https://errors.ubuntu.com/problem/65cb22d7c29a308dad9368b971e1b8d6384c9089 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 you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1658188/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821609] Re: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870
okay after rebooting via grub installed by sda1 .. as before .. red flash (no plymouth) lightdm briefly displays login screen .. then underline cursor then blank screen. attached is zl10-boot2-xorg.0.log xorg.0.log.old is now the already uploaded zl10-xorg.0.log above a crashing time is revealed in the log file .. ** Attachment added: "zl10-boot2-xorg.0.log" https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1821609/+attachment/5252075/+files/zl10-boot2-Xorg.0.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1821609 Title: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 Status in lightdm package in Ubuntu: New Status in xorg-server package in Ubuntu: New Bug description: Okay the has happened recently at least since march 18, 2019 iso and march 22, 2019 iso are both effected very similar to one of my previously reported bugs .. which was related to xorg not being installed .. back ground .. PC is lenovo sl 500 with evo860 SSD drive 3 partions contain installs of disco sda1 -- main working system -- I usually install grub from here as master .. sda6 and sda7 are test installs of disco daily iso's 03-18-2019, 03-22-2019 repectively on the test installs as long as the iso is using the grub boot loader installed from that install the system will boot normally .. the display manger tends to flicker on and off but does final start and login can proceed. but if another install re-installs grub as master the display manager fails to stay active or even come-up for sda6 or sda7 only if their own grubs are reinstalled will they work normally sda1 display manager/xorg login works always no matter which "grub- source" is in control. if I use rescue boot from any grub as master I can get the displays to work by running dpkg fix which does nothing .. and then resuming the boot .. then things work normally.. if the "non-rescue" boots are used the screen/computer locks and only a power down and reboot gives access. (sometime requiring radical depowering .. unpluging and removing battery) now the is a message that appears that RCs??? level is missing. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu11 ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 Uname: Linux 5.0.0-7-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Mon Mar 25 11:25:58 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GpuHangFrequency: Several times a day GpuHangReproducibility: Yes, I can easily reproduce it GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] InstallationDate: Installed on 2019-03-23 (1 days ago) InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190322) MachineType: LENOVO 2746CTO ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-7-generic root=UUID=1d61086d-275b-4537-bed5-f2d3080670eb ro recovery nomodeset SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 6AET64WW dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: 2746CTO dmi.board.vendor: LENOVO dmi.board.version: LENOVO 6AET64WW dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: LENOVO 6AET64WW dmi.modalias: dmi:bvnLENOVO:bvr6AET64WW:bd12/01/2010:svnLENOVO:pn2746CTO:pvrThinkPadSL500:rvnLENOVO:rn2746CTO:rvrLENOVO6AET64WW:cvnLENOVO:ct10:cvrLENOVO6AET64WW: dmi.product.name: 2746CTO dmi.product.version: ThinkPad SL500 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1821609/+subscriptions -- Mailing list:
[Touch-packages] [Bug 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
Confirmed that pcc-cpufreq *can* be used in preference to intel_pstate even on a CPU that supports intel_pstate if the firmware tables are setup to request such. One such server is an E5-2630 v3 HP DL360 G9 (shuckle). On the default "dynamic" firmware setting you get driver=pcc-cpufreq + governor=ondemand, with the "OS Control" setting you get driver=intel_pstate + governor=powersave. As above this would explain why the very poor performance is only seen without "OS Control" set, and then, only on some hardware. Since the firmware is in control of the CPU power states in pcc-cpufreq mode the exact frequencies / the rate they are changed / etc are partly under BIOS control. Secondarily it's using an entirely separate kernel path for when and how to choose these frequencies. Note that when pcc-cpufreq is in use the startup script (xenial:/etc/init.d/ondemand, bionic:/lib/systemd/set-cpufreq) will use ondemand and not powersave (contrary to what the bug report description states). If a system using 'cpufreq' is somehow getting the powersave governor set, this is a bug, but I haven't seen any case where that would be true as of yet. Also note that in Xenial, the ondemand script runs "sleep 60" before setting the governor, apparently to let most desktops boot to the login screen. So any method that tries to override this setting may fail on Xenial if it runs before the 60 seconds is up (e.g. /etc/rc.local, an init script, sysctl, etc) I did find that we have 1 other method of setting the governor, which is a charm ~canonical-bootstack/sysconfig which had an option added to allow setting the governor to performance (though it doesn't default to that). This charm installs the cpufrequtils package which also seems to default to 'ondemand'. However if this charm was configured with governor=powersave on such a cpufreq system, we would expect very poor performance. Secondly when configured with governor=performance on Xenial it runs before the 'ondemand' script finishes its 60 second wait, so the change gets reverted. But it will work when first deployed if no reboot is done. (Bug: https://bugs.launchpad.net/bootstack- ops/+bug/1822774) To my mind this leaves two remaining questions: - Are we ever getting into a state where we have scaling-driver=pcc-cpufreq or acpi-cpufreq, but governor=powersave. Such a case is likely a bug. I haven't found any such case as yet unless someone deployed the sysconfig charm with governor=powersave explicitly set (which I have not ruled out) - Is there some specific hardware where scaling-driver=pcc-cpufreq and scaling-governor=ondemand performs poorly. I have yet to run a benchmark on my example hardware to find out. -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on
[Touch-packages] [Bug 1822776] [NEW] Apply Bash 4.4.20 to fix cpu spinning on built-in wait
Public bug reported: Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical, also for older Ubuntus. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. ** Affects: bash (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Bug description: Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical, also for older Ubuntus. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822775] [NEW] Different input sources per window not work
Public bug reported: Ubuntu 19.04 The option to apply different input source for each window doesn't work (it automatically reset itself) However, I manually change org.gnome.desktop.input-sources.per-window and it works. ** Affects: ibus (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1822775 Title: Different input sources per window not work Status in ibus package in Ubuntu: New Bug description: Ubuntu 19.04 The option to apply different input source for each window doesn't work (it automatically reset itself) However, I manually change org.gnome.desktop.input-sources.per-window and it works. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1822775/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821609] Re: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870
the " surprise log file " not expected on a first boot .. with normal xorg startup should not exist .. ** Attachment added: "zl10-xorg.0.log.old -- first boot (inital xorg-server start which flickered lightdm?)" https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1821609/+attachment/5252073/+files/zl10-Xorg.0.log.old -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1821609 Title: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 Status in lightdm package in Ubuntu: New Status in xorg-server package in Ubuntu: New Bug description: Okay the has happened recently at least since march 18, 2019 iso and march 22, 2019 iso are both effected very similar to one of my previously reported bugs .. which was related to xorg not being installed .. back ground .. PC is lenovo sl 500 with evo860 SSD drive 3 partions contain installs of disco sda1 -- main working system -- I usually install grub from here as master .. sda6 and sda7 are test installs of disco daily iso's 03-18-2019, 03-22-2019 repectively on the test installs as long as the iso is using the grub boot loader installed from that install the system will boot normally .. the display manger tends to flicker on and off but does final start and login can proceed. but if another install re-installs grub as master the display manager fails to stay active or even come-up for sda6 or sda7 only if their own grubs are reinstalled will they work normally sda1 display manager/xorg login works always no matter which "grub- source" is in control. if I use rescue boot from any grub as master I can get the displays to work by running dpkg fix which does nothing .. and then resuming the boot .. then things work normally.. if the "non-rescue" boots are used the screen/computer locks and only a power down and reboot gives access. (sometime requiring radical depowering .. unpluging and removing battery) now the is a message that appears that RCs??? level is missing. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu11 ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 Uname: Linux 5.0.0-7-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Mon Mar 25 11:25:58 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GpuHangFrequency: Several times a day GpuHangReproducibility: Yes, I can easily reproduce it GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] InstallationDate: Installed on 2019-03-23 (1 days ago) InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190322) MachineType: LENOVO 2746CTO ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-7-generic root=UUID=1d61086d-275b-4537-bed5-f2d3080670eb ro recovery nomodeset SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 6AET64WW dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: 2746CTO dmi.board.vendor: LENOVO dmi.board.version: LENOVO 6AET64WW dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: LENOVO 6AET64WW dmi.modalias: dmi:bvnLENOVO:bvr6AET64WW:bd12/01/2010:svnLENOVO:pn2746CTO:pvrThinkPadSL500:rvnLENOVO:rn2746CTO:rvrLENOVO6AET64WW:cvnLENOVO:ct10:cvrLENOVO6AET64WW: dmi.product.name: 2746CTO dmi.product.version: ThinkPad SL500 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1821609/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1791405] Re: bluetooth always in discoverable mode (security issue)
That has been fixed in bluez upstream but there has been no new version since ** Package changed: gnome-bluetooth (Ubuntu) => bluez (Ubuntu) ** Changed in: bluez (Ubuntu) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1791405 Title: bluetooth always in discoverable mode (security issue) Status in bluez package in Ubuntu: Fix Committed Status in gnome-bluetooth package in Fedora: Confirmed Bug description: Excerpt from a similar report (https://bugzilla.redhat.com/show_bug.cgi?id=1602985) : Opening the Bluetooth settings will make the device discoverable again, but does not make the device undiscoverable after the settings are closed (this is not intended behavior; devices should only be discoverable when the bluetooth settings UI is open). There seem to be a merge request : https://gitlab.gnome.org/GNOME/gnome-bluetooth/merge_requests/1 Could you please merge it asap, it should be treated as a security issue IMHO. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1791405/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821609] Re: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870
iso april 2 2019 tested .. adding xorg.0.log & xorg.0.log.old files from first boot into fresh install .. There was a 1 to 2 second flicker in lightdm appearing then blanking and then reappearing on first boot .. have not yet rebooted into this from grub as installed by sda1 .. wanted to save the above log files first. files are prefixed with "zl10-" ** Attachment added: "zl10-xorg.0.log first boot" https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1821609/+attachment/5252072/+files/zl10-Xorg.0.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1821609 Title: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 Status in lightdm package in Ubuntu: New Status in xorg-server package in Ubuntu: New Bug description: Okay the has happened recently at least since march 18, 2019 iso and march 22, 2019 iso are both effected very similar to one of my previously reported bugs .. which was related to xorg not being installed .. back ground .. PC is lenovo sl 500 with evo860 SSD drive 3 partions contain installs of disco sda1 -- main working system -- I usually install grub from here as master .. sda6 and sda7 are test installs of disco daily iso's 03-18-2019, 03-22-2019 repectively on the test installs as long as the iso is using the grub boot loader installed from that install the system will boot normally .. the display manger tends to flicker on and off but does final start and login can proceed. but if another install re-installs grub as master the display manager fails to stay active or even come-up for sda6 or sda7 only if their own grubs are reinstalled will they work normally sda1 display manager/xorg login works always no matter which "grub- source" is in control. if I use rescue boot from any grub as master I can get the displays to work by running dpkg fix which does nothing .. and then resuming the boot .. then things work normally.. if the "non-rescue" boots are used the screen/computer locks and only a power down and reboot gives access. (sometime requiring radical depowering .. unpluging and removing battery) now the is a message that appears that RCs??? level is missing. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu11 ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 Uname: Linux 5.0.0-7-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Mon Mar 25 11:25:58 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GpuHangFrequency: Several times a day GpuHangReproducibility: Yes, I can easily reproduce it GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] InstallationDate: Installed on 2019-03-23 (1 days ago) InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190322) MachineType: LENOVO 2746CTO ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-7-generic root=UUID=1d61086d-275b-4537-bed5-f2d3080670eb ro recovery nomodeset SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 6AET64WW dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: 2746CTO dmi.board.vendor: LENOVO dmi.board.version: LENOVO 6AET64WW dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: LENOVO 6AET64WW dmi.modalias: dmi:bvnLENOVO:bvr6AET64WW:bd12/01/2010:svnLENOVO:pn2746CTO:pvrThinkPadSL500:rvnLENOVO:rn2746CTO:rvrLENOVO6AET64WW:cvnLENOVO:ct10:cvrLENOVO6AET64WW: dmi.product.name: 2746CTO dmi.product.version: ThinkPad SL500 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1821609/+subscriptions --
[Touch-packages] [Bug 604572] Re: Parse error when running "...display"-Tools
Thanks for above. I had the same issue while creating physical volume as below. pvcreate /dev/sda4 deleting /etc/lvm/cache/.cache solved issue! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/604572 Title: Parse error when running "...display"-Tools Status in lvm2 package in Ubuntu: Confirmed Bug description: Binary package hint: lvm2 Hey nerd-friends, when I use the "...display"-Tools, for example lvdisplay or pvdisplay, I get this error: > Parse error at byte 7 (line 1): expect a value Thanks for helping ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: lvm2 2.02.54-1ubuntu4 ProcVersionSignature: Ubuntu 2.6.32-23.37-generic 2.6.32.15+drm33.5 Uname: Linux 2.6.32-23-generic x86_64 NonfreeKernelModules: fglrx Architecture: amd64 Date: Mon Jul 12 14:08:37 2010 InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) ProcEnviron: SHELL=/bin/bash LANG=de_DE.utf8 SourcePackage: lvm2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/604572/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 604572] Re: Parse error when running "...display"-Tools
Has this been solved in newer versions of ubuntu? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/604572 Title: Parse error when running "...display"-Tools Status in lvm2 package in Ubuntu: Confirmed Bug description: Binary package hint: lvm2 Hey nerd-friends, when I use the "...display"-Tools, for example lvdisplay or pvdisplay, I get this error: > Parse error at byte 7 (line 1): expect a value Thanks for helping ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: lvm2 2.02.54-1ubuntu4 ProcVersionSignature: Ubuntu 2.6.32-23.37-generic 2.6.32.15+drm33.5 Uname: Linux 2.6.32-23-generic x86_64 NonfreeKernelModules: fglrx Architecture: amd64 Date: Mon Jul 12 14:08:37 2010 InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) ProcEnviron: SHELL=/bin/bash LANG=de_DE.utf8 SourcePackage: lvm2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/604572/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822768] Re: libgtk window resize problem
** Tags added: bionic ** Tags added: comic ui -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1822768 Title: libgtk window resize problem Status in gtk+3.0 package in Ubuntu: New Bug description: An app using libgtk-3 as GUI-lib shows strange behaviour since on ubuntu 18.04 an later. The problem is, that a not resizeable window not sets its correct size, when it shows up a second and all further times - but the first time, the size is correct. In that window a gtk element is inserted while showing up, so the size have to be recalculated. This stange behaviour is only found on Ubuntu 18.04 and later (libgtk-3-0 >> 3.22.30-1ubuntu2 ONLY on ubuntu - not kubuntu). On Debian systems (stable and testing) and Kubuntu systems of the same version all things are all right. A short list, which versions have failures (os and libgtk-3-0 version) : debian stretch with 3.22.11 is OK debian buster with 3.24.5 is OK ubuntu 17.10with 3.22.25-0ubuntu0.1 is OK ubuntu 18.04 (also LTS version)with 3.22.30-1ubuntu2 failure ubuntu 18.10with 3.24.4-0ubuntu1 failure A screenshot of the correct first show of the window an the second on is attached. A minimal example would also be attached in a replay to this report. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1822768/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791405] [NEW] bluetooth always in discoverable mode (security issue)
*** This bug is a security vulnerability *** You have been subscribed to a public security bug: Excerpt from a similar report (https://bugzilla.redhat.com/show_bug.cgi?id=1602985) : Opening the Bluetooth settings will make the device discoverable again, but does not make the device undiscoverable after the settings are closed (this is not intended behavior; devices should only be discoverable when the bluetooth settings UI is open). There seem to be a merge request : https://gitlab.gnome.org/GNOME/gnome-bluetooth/merge_requests/1 Could you please merge it asap, it should be treated as a security issue IMHO. ** Affects: bluez (Ubuntu) Importance: Medium Status: Fix Committed ** Affects: gnome-bluetooth (Fedora) Importance: Undecided Status: Confirmed -- bluetooth always in discoverable mode (security issue) https://bugs.launchpad.net/bugs/1791405 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez 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 1821308] Re: apt-get upgrade ignores pinning preferences since 1.0.1ubuntu2.22
@mathew-hodson It's in git, and will make it's way in in a future
release
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1821308
Title:
apt-get upgrade ignores pinning preferences since 1.0.1ubuntu2.22
Status in apt package in Ubuntu:
Invalid
Status in apt source package in Trusty:
Fix Released
Bug description:
[Impact]
Pinning on local-only package versions is ignored, causing them to be
upgraded.
[Test case]
The integration tests run in autopkgtest include an automated test case that
contains a package called coolstuff in three versions. We are specifying a Pin
for the installed one, set to 1000.
The bug caused 1.0 to become the candidate, as the existing pin was
ignored. The test checks that 2.0~bpo1 to remains the candidate, that
is, apt-cache policy looks like this:
coolstuff:
Installed: 2.0~bpo1
Candidate: 2.0~bpo1
Package pin: 2.0~bpo1
Version table:
2.0~bpo2 1000
100 file:${tmppath}/aptarchive/ backports/main i386 Packages
*** 2.0~bpo1 1000
100 ${tmppath}/rootdir/var/lib/dpkg/status
1.0 1000
500 file:${tmppath}/aptarchive/ stable/main i386 Packages
On the output of the autopkgtest we'll see:
Check that local-only versions can be pinned correctly (LP: #1821308)
Test for successful execution of apt-cache policy coolstuff … PASS
Test for correctness of file testsuccess.output … PASS
[Regression potential]
Other weird pinning bugs.
[Original bug report]
I have updated apt this morning:
Start-Date: 2019-03-22 09:36:18
Commandline: apt-get dist-upgrade
Upgrade: apt:amd64 (1.0.1ubuntu2.20, 1.0.1ubuntu2.22), ...
Afterwards, apt-get ignores my pinning preferences:
# apt-get --dry-run upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be DOWNGRADED:
burp
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Inst burp [2.0.54-1] (1.3.48-4 Ubuntu:14.04/trusty [amd64])
Conf burp (1.3.48-4 Ubuntu:14.04/trusty [amd64])
# cat /etc/apt/preferences.d/burp.pref
Package: burp
Pin: version 2.0.54*
Pin-Priority: 1000
This might be caused by bug 1814727 as it's the only thing I can see
in the changelog regarding apt/pinning.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1821308/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1795696] Re: /usr/bin/unattended-upgrade:UnboundLocalError:/usr/bin/unattended-upgrade@1991:main:do_auto_remove
This bug was fixed in the package unattended-upgrades - 1.1ubuntu1.18.04.10 --- unattended-upgrades (1.1ubuntu1.18.04.10) bionic; urgency=medium * do_auto_remove() is successful unless a commit() operation fails (LP: #1795696) * Compare apt.package.Version objects and not the versions' string representation. (LP: #1820888) This prevented adjusting candidates when the strings sorted differently. Also extend tests to catch issue. * Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade. (LP: #1821101) -- Balint Reczey Mon, 25 Mar 2019 18:17:56 +0100 ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1795696 Title: /usr/bin/unattended-upgrade:UnboundLocalError:/usr/bin/unattended- upgrade@1991:main:do_auto_remove Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: New Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Unattended-upgrades crashes while auto-removing kernel packages. [Test Case] 1. Install kernel packages to be automatically removed: # eatmydata apt install linux-image-4.18.0-13-generic linux-image-4.18.0-14-generic linux-image-4.18.0-15-generic # apt-mark auto linux-image-4.18.0-13-generic linux-image-4.18.0-14-generic linux-image-4.18.0-15-generic # /etc/kernel/postinst.d/apt-auto-removal 2. Set up u-u to perform action in non-minimal steps: # grep Minimal /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::MinimalSteps "false"; 3. Run u-u in dry-run mode. Observe it failing with not fixed versions: # unattended-upgrade --dry-run Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 1998, in sys.exit(main(options)) File "/usr/bin/unattended-upgrade", line 1798, in main options.verbose or options.debug, options.dry_run) File "/usr/bin/unattended-upgrade", line 1495, in do_auto_remove if res: UnboundLocalError: local variable 'res' referenced before assignment Observe the fixed version running properly: # ./unattended-upgrade --dry-run # [Regression Potential] * The fix is very small and isolated, but a programming error could cause the misreporting of the success of auto-removals. Considering the size and simplicity of the change, regressions here seem unlikely. [Original Bug Text] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.5, the problem page at https://errors.ubuntu.com/problem/651a7b7a070dd794d8cf2f5ea8e974614fdedb8e 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/1795696/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
I've just built and installed the master branch of gnome-bluetooth
(commit b4edf6a8) and didn't see any behavioral change. Since it isn't
even possible to pair through bluetoothctl, I wasn't particularly
hopeful that an update to gnome-bluetooth would fix things.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1822633
Title:
Pairing failure with BLE 4.0
Status in bluez package in Ubuntu:
New
Status in linux package in Ubuntu:
Confirmed
Bug description:
When attempting to pair a BLE 4.0 pen using Bluez, we receive
authentication errors.
Here is the FW from Jason.
Details:
===
I added a few debug statements (patch attached) to the kernel's
net/bluetooth/smp.c:smp_sig_channel() function
(https://github.com/torvalds/linux/blob/v5.0/net/bluetooth/smp.c#L2883).
When I try to pair the PN579X, I get the following logs:
[ 5653.563048] DBG: Received code 2 (allowed = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) with 7 bytes
[ 5654.246182] DBG: Processing code...
[ 5657.610656] input: Dell Active Pen PN579X Keyboard as
/devices/virtual/misc/uhid/0005:413C:81D5.0004/input/input23
[ 5657.610997] hid-generic 0005:413C:81D5.0004: input,hidraw0: BLUETOOTH HID
vf.08 Keyboard [Dell Active Pen PN579X] on 18:56:80:18:6A:E5
When I try to pair the PN557W, however, I only get the following:
[ 64.924901] DBG: Received code 11 (allowed = 0024) with 1 bytes
[ 64.924906] DBG: AuthReq = 00
[ 64.924907] ERR: Code not allowed on existing connection
[ 64.924943] Bluetooth: hci0: unexpected SMP command 0x0b from
bc:82:5d:fa:5e:b7
[ 64.940314] NET: Registered protocol family 38
[ 65.022326] DBG: Received code 5 (allowed = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 means that only event
code 2 and 5 are allowed. The "smp_sig_channel()" function does allow
code 11 ("SMP_CMD_SECURITY_REQ") to be sent from the device at the
beginning of the connection but *only* if the "smp" variable hasn't
been set yet. It looks like the host starts the pairing process and
initializes the "smp" variable, which then prevents code 11 from being
allowed.
I did try to force the code to allow code 11 at any time, but this
didn't seem to help the situation any. The device still sent code 5
("SMP_CMD_PAIRING_FAIL") immediately afterwards, just like it does in
the trace above. Worse, the kernel logs a general protection fault
several seconds afterwards, so it clearly doesn't like the workaround.
I also find it odd that the "AuthReq = 00". I found a copy of the core
Bluetooth spec at https://www.bluetooth.com/specifications/bluetooth-
core-specification and Vol. 3 Part H Chapter 3.6.7 describes the
AuthReq flags. All zero would seem to indicate that no security is
requested, and I'm not sure if the kernel enforces a minimum security
level or something.
Finally, I also tried the suggestion at
https://www.raymondjdouglas.com/blog/2019/airpods-on-arch/ on the assumption
that maybe this is an issue caused by LE communication rather than classic
BR/EDR communication. Alas, my computer wasn't even able to start the pairing
process after making the change.
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 18.04
InstallationDate: Installed on 2019-01-21 (70 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64
(20180725)
InterestingModules: bnep btusb bluetooth
MachineType: Dell Inc. XPS 13 9360
Package: linux
PackageArchitecture: amd64
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-46-generic
root=UUID=c045330d-1b98-41ff-99cb-26bf69b59fd3 ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
Tags: third-party-packages bionic
Uname: Linux 4.15.0-46-generic x86_64
UnreportableReason: This is not an official Ubuntu package. Please remove any
third party package and try again.
UpgradeStatus: No upgrade log present
[Touch-packages] [Bug 1396160] Re: /usr/share/apport/recoverable_problem:PermissionError:/usr/share/apport/recoverable_problem@75:main:add_proc_info
** Also affects: apport (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: apport (Ubuntu Bionic) Status: New => Triaged ** Changed in: apport (Ubuntu Bionic) Importance: Undecided => Medium -- 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/1396160 Title: /usr/share/apport/recoverable_problem:PermissionError:/usr/share/apport/recoverable_problem@75:main:add_proc_info Status in apport package in Ubuntu: In Progress Status in apport source package in Bionic: Triaged Status in apport source package in Disco: In Progress Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with version 2.14.7-0ubuntu10, the problem page at https://errors.ubuntu.com/problem/9a1df90760a88c9b4e5e7e3b4ef450f6b5669c7c contains more details. More Buckets: https://errors.ubuntu.com/problem/2a97a88118a1d8746cff239205a4cd9eb3d0357d https://errors.ubuntu.com/problem/72c621876cfe04b51b37f8f3ef08c3da0460b462 Other reference: bug 1394919 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1396160/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821101] Update Released
The verification of the Stable Release Update for unattended-upgrades has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1821101 Title: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: In Progress Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Without the introduced fallbacks u-u could not upgrade particular package sets from -security. It could be observed in Cosmic with systemd security updates failing to install in: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:falling back to marking test2-package, then adjusting changes DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:falling back to marking test3-package, then adjusting changes WARNING:root:package test3-package upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) DEBUG:root:falling back to adjusting all packages DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-old-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 WARNING:root:package z-package upgradable but fails to be marked for upgrade () . -- Ran 1 test in 0.039s OK [Regression Potential] * When failing to mark a package to upgrade/install from the allowed origin holding the highest version the first fallback resets all already adjusted candidates to the highest available version irrespective to the origin of this version being allowed or not. This itself is not a risky operation and sanity checks later ensure that no package would be installed from not allowed origins but it can trigger code paths in apt that were not tried before and may crash. * In testing apt's resolver failed to find a solution for upgrading packages with the first fallback raising an error, but the second fallback handles the error and tries adjusting _all_ potentially upgradable/installable package at the expense of using much more CPU time. This second fallback is not expected to be reached often (it is not reached in autopkgtests either) and adjusting all of those packages matches an earlier behavior of u-u, thus the slow-down may not be considered a regression. [Other Info] * If the second fallback is found to be reached often a different fallback can be introduced before the first one, to adjust all packages from the same source package then try again: See: https://github.com/mvo5/unattended-upgrades/pull/175#discussion_r268226796 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821101/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820888] Update Released
The verification of the Stable Release Update for unattended-upgrades has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1820888 Title: unattended-upgrades may hold back upgrades due to comparing package versions by their string representation Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: In Progress Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Without the fix u-u could not upgrade particular packages from -security. It could be observed in Cosmic with systemd security updates failing to install partly due to 239-7ubuntu10.10 being smaller than 239-7ubuntu10.8 when comparing them as strings: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: ... Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 ... With the unfixed version the test case fails here because u-u tries to upgrade test-package to version 12.0 because it does not find version 2.0 smaller. [Regression Potential] * The change is very small and isolated, but fixing it revealed the issue fixed in LP: #1821101. Since the found issue's fix introduces fallbacks when apt's resolver can't find a the solution it is unlikely that other failures are triggered by the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1820888/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
FYI the QEMU change merged in the following pull request changed to return an EPERM errno for the thread affinity syscalls: commit 12f067cc14b90aef60b2b7d03e1df74cc50a0459 Merge: 84bdc58c06 035121d23a Author: Peter Maydell Date: Thu Mar 28 12:04:52 2019 + Merge remote-tracking branch 'remotes/otubo/tags/pull-seccomp-20190327' into staging pull-seccomp-20190327 # gpg: Signature made Wed 27 Mar 2019 12:12:39 GMT # gpg:using RSA key DF32E7C0F0FFF9A2 # gpg: Good signature from "Eduardo Otubo (Senior Software Engineer) " [full] # Primary key fingerprint: D67E 1B50 9374 86B4 0723 DBAB DF32 E7C0 F0FF F9A2 * remotes/otubo/tags/pull-seccomp-20190327: seccomp: report more useful errors from seccomp seccomp: don't kill process for resource control syscalls Signed-off-by: Peter Maydell IOW, mesa's usage of this syscalls will still be blocked, but it will no longer kill the process. ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() Status in Mesa: Confirmed Status in QEMU: Fix Committed Status in mesa package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Triaged Status in mesa source package in Disco: Fix Released Bug description: Unable to launch Default Fedora 29 images in gnome-boxes ProblemType: Crash DistroRelease: Ubuntu 19.04 Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18 Uname: Linux 4.19.0-12-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 Date: Thu Feb 14 11:00:45 2019 ExecutablePath: /usr/bin/qemu-system-x86_64 KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND MachineType: Dell Inc. Precision T3610 ProcEnviron: PATH=(custom, user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1 Signal: 31 SourcePackage: qemu StacktraceTop: __pthread_setaffinity_new (th=, cpusetsize=128, cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so start_thread (arg=) at pthread_create.c:486 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video dmi.bios.date: 11/14/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A18 dmi.board.name: 09M8Y8 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 7 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr: dmi.product.name: Precision T3610 dmi.product.sku: 05D2 dmi.product.version: 00 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815889/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
I tried to get the ondemand script dropped in 2015 #1503773, Got Nacked. -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
I created internal VMware bug 2319367 to track looking into this. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820132] Re: /usr/share/apport/whoopsie-upload-all:AssertionError:/usr/share/apport/whoopsie-upload-all@162:collect_info:process_report:add_gdb_info:gdb_command
** Also affects: apport (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: apport (Ubuntu Bionic) Status: New => Triaged ** Changed in: apport (Ubuntu Bionic) Importance: Undecided => High -- 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/1820132 Title: /usr/share/apport/whoopsie-upload-all:AssertionError:/usr/share/apport /whoopsie-upload- all@162:collect_info:process_report:add_gdb_info:gdb_command Status in apport package in Ubuntu: In Progress Status in apport source package in Bionic: Triaged Status in apport source package in Disco: In Progress Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with package version 2.20.10-0ubuntu23, the problem page at https://errors.ubuntu.com/problem/4a48673e60f08b7d2b9067d1b47766a57f7e693e 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/apport/+bug/1820132/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821101] Re: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade
This bug was fixed in the package unattended-upgrades - 1.5ubuntu3.18.10.3 --- unattended-upgrades (1.5ubuntu3.18.10.3) cosmic; urgency=medium * Compare apt.package.Version objects and not the versions' string representation. (LP: #1820888) This prevented adjusting candidates when the strings sorted differently. Also extend tests to catch issue. * Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade. (LP: #1821101) -- Balint Reczey Mon, 25 Mar 2019 17:10:19 +0100 ** Changed in: unattended-upgrades (Ubuntu Cosmic) Status: Fix Committed => Fix Released ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1821101 Title: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: In Progress Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Without the introduced fallbacks u-u could not upgrade particular package sets from -security. It could be observed in Cosmic with systemd security updates failing to install in: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:falling back to marking test2-package, then adjusting changes DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:falling back to marking test3-package, then adjusting changes WARNING:root:package test3-package upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) DEBUG:root:falling back to adjusting all packages DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-old-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 WARNING:root:package z-package upgradable but fails to be marked for upgrade () . -- Ran 1 test in 0.039s OK [Regression Potential] * When failing to mark a package to upgrade/install from the allowed origin holding the highest version the first fallback resets all already adjusted candidates to the highest available version irrespective to the origin of this version being allowed or not. This itself is not a risky operation and sanity checks later ensure that no package would be installed from not allowed origins but it can trigger code paths in apt that were not tried before and may crash. * In testing apt's resolver failed to find a solution for upgrading packages with the first fallback raising an error, but the second fallback handles the error and tries adjusting _all_ potentially upgradable/installable package at the expense of using much more CPU time. This second fallback is not expected to be reached often (it is not reached in autopkgtests either) and adjusting all of those packages matches an earlier behavior of u-u, thus the slow-down may not be considered a regression. [Other Info] * If the second fallback is found to be reached often a different fallback can be introduced before the first one, to adjust all packages from the same source package then try again: See: https://github.com/mvo5/unattended-upgrades/pull/175#discussion_r268226796 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821101/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1795696] Update Released
The verification of the Stable Release Update for unattended-upgrades has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1795696 Title: /usr/bin/unattended-upgrade:UnboundLocalError:/usr/bin/unattended- upgrade@1991:main:do_auto_remove Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: New Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Unattended-upgrades crashes while auto-removing kernel packages. [Test Case] 1. Install kernel packages to be automatically removed: # eatmydata apt install linux-image-4.18.0-13-generic linux-image-4.18.0-14-generic linux-image-4.18.0-15-generic # apt-mark auto linux-image-4.18.0-13-generic linux-image-4.18.0-14-generic linux-image-4.18.0-15-generic # /etc/kernel/postinst.d/apt-auto-removal 2. Set up u-u to perform action in non-minimal steps: # grep Minimal /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::MinimalSteps "false"; 3. Run u-u in dry-run mode. Observe it failing with not fixed versions: # unattended-upgrade --dry-run Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 1998, in sys.exit(main(options)) File "/usr/bin/unattended-upgrade", line 1798, in main options.verbose or options.debug, options.dry_run) File "/usr/bin/unattended-upgrade", line 1495, in do_auto_remove if res: UnboundLocalError: local variable 'res' referenced before assignment Observe the fixed version running properly: # ./unattended-upgrade --dry-run # [Regression Potential] * The fix is very small and isolated, but a programming error could cause the misreporting of the success of auto-removals. Considering the size and simplicity of the change, regressions here seem unlikely. [Original Bug Text] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.5, the problem page at https://errors.ubuntu.com/problem/651a7b7a070dd794d8cf2f5ea8e974614fdedb8e 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/1795696/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures
This is fixed in perl 5.28.1-6, now in the disco release pocket.
** Changed in: perl (Ubuntu Disco)
Status: Confirmed => Fix Released
** Changed in: ubuntu-power-systems
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to perl in Ubuntu.
https://bugs.launchpad.net/bugs/1818953
Title:
mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
executing perl script, multiple architectures
Status in The Ubuntu-power-systems project:
Fix Released
Status in perl package in Ubuntu:
Fix Released
Status in perl source package in Disco:
Fix Released
Status in perl package in Debian:
Unknown
Bug description:
== Comment: #0 - NAGENDRA P. DONTAMSETTY - 2019-02-28
00:14:49 ==
---Problem Description---
Perl core dumping core on UBUNTU 19.04 by executing perl script
---uname output---
root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = ppc64le and power8
---Debugger Data---
root@p8ct1p13:/tmp# file core
core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0,
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
---Steps to Reproduce---
Description: Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"
root@p8ct1p13:/tmp# uname -a
Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
root@p8ct1p13:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="19.04 (Disco Dingo)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
VERSION_ID="19.04"
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
VERSION_CODENAME=disco
UBUNTU_CODENAME=disco
root@p8ct1p13:~# ctversion -bv
RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49
RSCT_Build_Context=ppc64le_linux_2
root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1"
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test
String 2"
perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
Aborted (core dumped)
root@p8ct1p13:/tmp# file core
core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0,
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
root@p8ct1p13:/tmp# which mkrsrc
/usr/bin/mkrsrc
root@p8ct1p13:/tmp# file /usr/bin/mkrsrc
/usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc
root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
/opt/rsct/bin/mkrsrc: Perl script text executable
Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com,
Anirban/anirb...@in.ibm.com
Userspace tool common name: perl 5
The userspace tool has the following bit modes: 64bit
Userspace rpm: ii perl 5.28.1-4
ppc64el
Userspace tool obtained from project website: na
*Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com,
Anirban/anirb...@in.ibm.com:
-Post a private note with access information to the machine that is currently
in the debugger.
-Attach ltrace and strace of userspace application.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1818953/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
Can someone clarify, what VMware products is this know to affect (vSphere/ESXi or Workstation/Fusion) and what versions? Also what virtual NIC is used in the VM? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1817799] Re: [FFe] apparmor 2.13
This bug was fixed in the package apparmor - 2.13.2-9ubuntu4 --- apparmor (2.13.2-9ubuntu4) disco; urgency=medium * debian/tests/control and debian/tests/compile-policy: don't test thunderbird since the Ubuntu packaging doesn't ship a profile -- Jamie Strandboge Wed, 27 Mar 2019 18:01:33 + ** Changed in: apparmor (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1817799 Title: [FFe] apparmor 2.13 Status in apparmor package in Ubuntu: Fix Released Bug description: Feature Freeze exception for AppArmor 2.13.2 The security team is pushing to get AppArmor 2.13 into 19.04 since we want AppArmor 3 (or higher) in 20.04 and we'd like to update to 2.13.2 to have widespread use of its new features and make the overall experience to AppArmor 3 better tested and less disruptive. The 2.13.2 series over 2.12 is primarily incremental improvements in the parser, libapparmor, userspace tooling and policy; Debian started preparing 2.13 in experimental last June where the first upload to unstable was made in July. Since then, Debian has worked closely with upstream and Ubuntu devs to shake out bugs and improve the packaging. There are no new mediation rules so the chance of regression in terms of parser/kernel/policy updates is considered low. IME, the primary points of interest for the FFe surround the following: * apparmor_parser in 2.13 now creates subdirectories in the cache directory with the subdir name based on the kernel features. This improves the experience when booting between kernels with different feature sets * Debian moved /etc/apparmor.d/cache to /var/cache/apparmor (first upload with this change in August) * the init process now uses proper systemd unit instead of calling out to SysV init script. This and rc.apparmor.functions cleanups were done in coordination with Ubuntu devs (first upload in December) * due to bug #1820068, the 2.12 and earlier Ubuntu-distro patch to use -O no-expr-simplify (helps with policy compilation times on armhf) has been reverted. We'll get the bug fixed before disco release Debian has been very active in improving the packaging since the plan is to release with AppArmor by default in Buster (it has been on by default in Debian testing for a long time, before the 2.13 uploads). A version of 2.13.2 has been in Debian testing (Buster) since January with the 2.13.2-9 version that this FFe is based on migrating last week. Debian improved autopkgtests throughout Buster, worked with upstream and Ubuntu devs throughout. Because of the extensive baking in Debian, I think it is reasonable to consider granting the exception (indeed, part of why we missed Disco's freeze was because we were working with Debian on improving the package for Buster's freeze). While most software in Ubuntu doesn't care about the systemd or cache changes, it was known that snapd manages snap cache files on snap remove, and snapd needed to be changed to account for this[2]. This update is included in snapd 2.38 which is now in disco. Because of the change in the apparmor cache, I have introduced a Breaks: snapd (<< 2.38~) in the apparmor package since snaps cannot be removed (snapd aborts the removal when the cache file is not found; which is a little strict IMO, but I digress). In terms of testing, we exercised our test plan, like normal[1]. This includes upgrade testing, verifying profile load on boot, cache is used and software with apparmor integration continue to work (snapd, lxc, lxd, libvirt, docker, etc). Anecdotally I have been using 2.13.2 for some time without issue (and I have a lot of snap, distro and personal policy). The source tarball does not contain a changelog, instead the upstream release notes can be found here: * https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13 * https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13.1 * https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.13.2 [1]https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor [2]https://github.com/snapcore/snapd/pull/6549 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1817799/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820888] Re: unattended-upgrades may hold back upgrades due to comparing package versions by their string representation
This bug was fixed in the package unattended-upgrades - 1.5ubuntu3.18.10.3 --- unattended-upgrades (1.5ubuntu3.18.10.3) cosmic; urgency=medium * Compare apt.package.Version objects and not the versions' string representation. (LP: #1820888) This prevented adjusting candidates when the strings sorted differently. Also extend tests to catch issue. * Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade. (LP: #1821101) -- Balint Reczey Mon, 25 Mar 2019 17:10:19 +0100 ** Changed in: unattended-upgrades (Ubuntu Cosmic) Status: Fix Committed => Fix Released ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1820888 Title: unattended-upgrades may hold back upgrades due to comparing package versions by their string representation Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: In Progress Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Without the fix u-u could not upgrade particular packages from -security. It could be observed in Cosmic with systemd security updates failing to install partly due to 239-7ubuntu10.10 being smaller than 239-7ubuntu10.8 when comparing them as strings: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: ... Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 ... With the unfixed version the test case fails here because u-u tries to upgrade test-package to version 12.0 because it does not find version 2.0 smaller. [Regression Potential] * The change is very small and isolated, but fixing it revealed the issue fixed in LP: #1821101. Since the found issue's fix introduces fallbacks when apt's resolver can't find a the solution it is unlikely that other failures are triggered by the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1820888/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820888] Re: unattended-upgrades may hold back upgrades due to comparing package versions by their string representation
This bug was fixed in the package unattended-upgrades - 1.1ubuntu1.18.04.10 --- unattended-upgrades (1.1ubuntu1.18.04.10) bionic; urgency=medium * do_auto_remove() is successful unless a commit() operation fails (LP: #1795696) * Compare apt.package.Version objects and not the versions' string representation. (LP: #1820888) This prevented adjusting candidates when the strings sorted differently. Also extend tests to catch issue. * Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade. (LP: #1821101) -- Balint Reczey Mon, 25 Mar 2019 18:17:56 +0100 -- 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/1820888 Title: unattended-upgrades may hold back upgrades due to comparing package versions by their string representation Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: In Progress Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Without the fix u-u could not upgrade particular packages from -security. It could be observed in Cosmic with systemd security updates failing to install partly due to 239-7ubuntu10.10 being smaller than 239-7ubuntu10.8 when comparing them as strings: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: ... Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 ... With the unfixed version the test case fails here because u-u tries to upgrade test-package to version 12.0 because it does not find version 2.0 smaller. [Regression Potential] * The change is very small and isolated, but fixing it revealed the issue fixed in LP: #1821101. Since the found issue's fix introduces fallbacks when apt's resolver can't find a the solution it is unlikely that other failures are triggered by the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1820888/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815889]
(In reply to Michel Dänzer from comment #8) > Mesa doesn't really need explicit thread affinity at all. All it wants is > that certain sets of threads run on the same CPU module; it doesn't care > which particular CPU module that is. What's really needed is an API to > express this affinity between threads, instead of to specific CPU cores. I think the thread affinity API is a correct way to optimize for CPU cache topologies. pthread is a basic user API. Security policies shouldn't disallow pthread functions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() Status in Mesa: Confirmed Status in QEMU: New Status in mesa package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Triaged Status in mesa source package in Disco: Fix Released Bug description: Unable to launch Default Fedora 29 images in gnome-boxes ProblemType: Crash DistroRelease: Ubuntu 19.04 Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18 Uname: Linux 4.19.0-12-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 Date: Thu Feb 14 11:00:45 2019 ExecutablePath: /usr/bin/qemu-system-x86_64 KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND MachineType: Dell Inc. Precision T3610 ProcEnviron: PATH=(custom, user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1 Signal: 31 SourcePackage: qemu StacktraceTop: __pthread_setaffinity_new (th=, cpusetsize=128, cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so start_thread (arg=) at pthread_create.c:486 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video dmi.bios.date: 11/14/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A18 dmi.board.name: 09M8Y8 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 7 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr: dmi.product.name: Precision T3610 dmi.product.sku: 05D2 dmi.product.version: 00 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815889/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821920] Re: apparmor-profiles installs the chromium-browser profile but not the abstraction
This bug was fixed in the package apparmor - 2.13.2-9ubuntu4 --- apparmor (2.13.2-9ubuntu4) disco; urgency=medium * debian/tests/control and debian/tests/compile-policy: don't test thunderbird since the Ubuntu packaging doesn't ship a profile -- Jamie Strandboge Wed, 27 Mar 2019 18:01:33 + ** Changed in: apparmor (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1821920 Title: apparmor-profiles installs the chromium-browser profile but not the abstraction Status in apparmor package in Ubuntu: Fix Released Bug description: The apparmor-profiles binary package from apparmor 2.13.2-9ubuntu2 in disco-proposed is not handling the chromium-browser profile and abstraction correctly. It installs the profile but not the abstraction which makes profile loading fail. $ sudo apt install apparmor-profiles/disco-proposed Reading package lists... Done Building dependency tree Reading state information... Done Selected version '2.13.2-9ubuntu2' (Ubuntu:19.04/disco-proposed [all]) for 'apparmor-profiles' The following NEW packages will be installed: apparmor-profiles 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 32.5 kB of archives. After this operation, 353 kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 apparmor-profiles all 2.13.2-9ubuntu2 [32.5 kB] Fetched 32.5 kB in 0s (95.3 kB/s) Selecting previously unselected package apparmor-profiles. (Reading database ... 119746 files and directories currently installed.) Preparing to unpack .../apparmor-profiles_2.13.2-9ubuntu2_all.deb ... Unpacking apparmor-profiles (2.13.2-9ubuntu2) ... Setting up apparmor-profiles (2.13.2-9ubuntu2) ... AppArmor parser error for /etc/apparmor.d/usr.bin.chromium-browser in /etc/apparmor.d/ usr.bin.chromium-browser at line 20: Could not open 'abstractions/ubuntu-browsers.d/chromium-browser' This makes the apparmor service fail to start: $ sudo service apparmor restart Job for apparmor.service failed because the control process exited with error code. See "systemctl status apparmor.service" and "journalctl -xe" for details. $ systemctl status apparmor.service | cat ● apparmor.service - Load AppArmor profiles Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2019-03-27 13:05:37 UTC; 41s ago Docs: man:apparmor(7) https://gitlab.com/apparmor/apparmor/wikis/home/ Process: 5103 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=1/FAILURE) Main PID: 5103 (code=exited, status=1/FAILURE) Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Restarting AppArmor Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Reloading AppArmor profiles Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error for /etc/apparmor.d in /etc/apparmor.d/usr.bin.chromium-browser at line 20: Could not open 'abstractions/ubuntu-browsers.d/chromium-browser' Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error for /etc/apparmor.d/usr.bin.chromium-browser in /etc/apparmor.d/usr.bin.chromium-browser at line 20: Could not open 'abstractions/ubuntu-browsers.d/chromium-browser' Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Error: At least one profile failed to load Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Failed with result 'exit-code'. Mar 27 13:05:37 sec-disco-amd64 systemd[1]: Failed to start Load AppArmor profiles. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1821920/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821101] Re: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade
This bug was fixed in the package unattended-upgrades - 1.1ubuntu1.18.04.10 --- unattended-upgrades (1.1ubuntu1.18.04.10) bionic; urgency=medium * do_auto_remove() is successful unless a commit() operation fails (LP: #1795696) * Compare apt.package.Version objects and not the versions' string representation. (LP: #1820888) This prevented adjusting candidates when the strings sorted differently. Also extend tests to catch issue. * Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade. (LP: #1821101) -- Balint Reczey Mon, 25 Mar 2019 18:17:56 +0100 -- 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/1821101 Title: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: In Progress Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Without the introduced fallbacks u-u could not upgrade particular package sets from -security. It could be observed in Cosmic with systemd security updates failing to install in: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:falling back to marking test2-package, then adjusting changes DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:falling back to marking test3-package, then adjusting changes WARNING:root:package test3-package upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) DEBUG:root:falling back to adjusting all packages DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-old-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 WARNING:root:package z-package upgradable but fails to be marked for upgrade () . -- Ran 1 test in 0.039s OK [Regression Potential] * When failing to mark a package to upgrade/install from the allowed origin holding the highest version the first fallback resets all already adjusted candidates to the highest available version irrespective to the origin of this version being allowed or not. This itself is not a risky operation and sanity checks later ensure that no package would be installed from not allowed origins but it can trigger code paths in apt that were not tried before and may crash. * In testing apt's resolver failed to find a solution for upgrading packages with the first fallback raising an error, but the second fallback handles the error and tries adjusting _all_ potentially upgradable/installable package at the expense of using much more CPU time. This second fallback is not expected to be reached often (it is not reached in autopkgtests either) and adjusting all of those packages matches an earlier behavior of u-u, thus the slow-down may not be considered a regression. [Other Info] * If the second fallback is found to be reached often a different fallback can be introduced before the first one, to adjust all packages from the same source package then try again: See: https://github.com/mvo5/unattended-upgrades/pull/175#discussion_r268226796 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821101/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
I've recently found that while pairing with this pen does not work,
"merely" connecting to the pen does work. That is:
# This command fails
$ echo -e "scan on\npair \nscan off" | bluetoothctl
# But this command works
$ echo -e "scan on\nconnect \nscan off" | bluetoothctl
Looking through the hcidump logs, it appears that "connect" has lower
(really, "no") security requirements, which could explain why it
succeeds where pairing fails (the AuthReq = 00 sent from the device
implies it doesn't want/support security).
I see that GNOME ships /usr/share/gnome-bluetooth/pin-code-database.xml
which defines default PINs. Inside the file, it says "the special NULL
pin means that the devices will not be paired, but connected to and
marked as trusted. This is for devices such as mice and joypads where
there is no encryption." If I add the pen to the database by adding the
following lines at the top of the "device" section, GNOME pairing starts
working (although it seems to be a little hit-or-miss):
With the connection fix in place, a new issue has been identified.
Specifically, the kernel input device is removed after processing just a
single Bluetooth HID event. Looking at the output of "journalctl -b0", I
see the following error message logged, followed by normal device
disconnect messages:
bluetoothd[6318]: Error Reading PNP_ID value: Request attribute has
encountered an unlikely error
Looking at the hcidump logs, it seems that when the pen's Bluetooth
button is pressed, it briefly wakes up only long enough to send a HID
report to the system. After doing so, it disconnects to save power. The
logs show that the system begins requesting information from the device
when it connects, and that it gets a response to some of those requests,
but at some point (e.g. when asking for PNP_ID) the device goes to sleep
and a response is never returned.
It would seem that there either the system needs to not re-ask the
device for information like PNP-ID (which it already received in the
initial "connect" process and should have associated with its MAC) or to
not be so stringent when these requests fail.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1822633
Title:
Pairing failure with BLE 4.0
Status in bluez package in Ubuntu:
New
Status in linux package in Ubuntu:
Confirmed
Bug description:
When attempting to pair a BLE 4.0 pen using Bluez, we receive
authentication errors.
Here is the FW from Jason.
Details:
===
I added a few debug statements (patch attached) to the kernel's
net/bluetooth/smp.c:smp_sig_channel() function
(https://github.com/torvalds/linux/blob/v5.0/net/bluetooth/smp.c#L2883).
When I try to pair the PN579X, I get the following logs:
[ 5653.563048] DBG: Received code 2 (allowed = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) with 7 bytes
[ 5654.246182] DBG: Processing code...
[ 5657.610656] input: Dell Active Pen PN579X Keyboard as
/devices/virtual/misc/uhid/0005:413C:81D5.0004/input/input23
[ 5657.610997] hid-generic 0005:413C:81D5.0004: input,hidraw0: BLUETOOTH HID
vf.08 Keyboard [Dell Active Pen PN579X] on 18:56:80:18:6A:E5
When I try to pair the PN557W, however, I only get the following:
[ 64.924901] DBG: Received code 11 (allowed = 0024) with 1 bytes
[ 64.924906] DBG: AuthReq = 00
[ 64.924907] ERR: Code not allowed on existing connection
[ 64.924943] Bluetooth: hci0: unexpected SMP command 0x0b from
bc:82:5d:fa:5e:b7
[ 64.940314] NET: Registered protocol family 38
[ 65.022326] DBG: Received code 5 (allowed = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 means that only event
code 2 and 5 are allowed. The "smp_sig_channel()" function does allow
code 11 ("SMP_CMD_SECURITY_REQ") to be sent from the device at the
beginning of the connection but *only* if the "smp" variable hasn't
been set yet. It looks like the host starts the pairing process and
initializes the "smp" variable, which then prevents code 11 from being
allowed.
I did try to force the code to allow code 11 at any time, but this
didn't seem to help the situation any. The device still sent
[Touch-packages] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest
Please review and consider this debdiff to Xenial. It fixes the issue reported here. == Before Patch == ubuntu@P8lpar4:~$ lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):128 On-line CPU(s) list: 0-127 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 16 NUMA node(s): 2 Model: 2.1 (pvr 004b 0201) Model name:POWER8 (architected), altivec supported Hypervisor vendor: horizontal Virtualization type: full L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node2 CPU(s): 0-127 ubuntu@P8lpar4:~$ == After Patch == ubuntu@P8lpar4:~$ lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):128 On-line CPU(s) list: 0-127 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 16 NUMA node(s): 2 Model: 2.1 (pvr 004b 0201) Model name:POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node2 CPU(s): 0-127 ubuntu@P8lpar4:~$ ** Patch added: "Fix to identify virtualization type correctly in Xenial on PowerPC" https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1764628/+attachment/5252296/+files/fix-virtualization-type.debdiff ** Changed in: util-linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: ubuntu-power-systems Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1764628 Title: incorrect hypervisor and virtualization type reported in compat mode guest Status in The Ubuntu-power-systems project: In Progress Status in util-linux package in Ubuntu: In Progress Bug description: [IMPACT] In xenial lscpu prints the wrong "Hypervisor vendor" and "Virtualization type" on PowerVM or KVM systems. Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC. [TEST] Curent output: ubuntu@P8lpar3:~$ dpkg -l "*util-linux*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii util-linux 2.31.1-0.4ub ppc64el miscellaneous system utilities un util-linux-loc (no description available) ubuntu@P8lpar3:~$ lscpu Architecture:ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s):2 Model: 2.1 (pvr 004b 0201) Model name: POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 ubuntu@P8lpar3:~$ Expected Output: $ lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):128 On-line CPU(s) list: 0-127 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 16 NUMA node(s): 2 Model: 2.1 (pvr 004b 0201) Model name:POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 [Potential Regression] The fix changes the logic to how lscpu-dmi returns from read_hypervisor_dmi() this could introduce potential regression in platforms that has incorrect DMI information. [Other Info] ---uname output--- Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux Machine Type = boston-LC ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC: root@guest:/tmp# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):2 On-line CPU(s) list: 0,1 Thread(s) per core:2 Core(s) per socket:1 Socket(s): 1 NUMA node(s): 1 Model: 2.2 (pvr 004e 1202) Model name:POWER8 (architected), altivec supported >> Hypervisor vendor: horizontal >> Virtualization type: full L1d cache: 32K L1i cache: 32K NUMA node0 CPU(s): 0,1 Stack trace
Re: [Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
This is Workstation and Player 15 I do not have ability to test on ESXi I am using VMnet8 On 4/2/19 1:30 PM, John Savanyo wrote: > Can someone clarify, what VMware products is this know to affect > (vSphere/ESXi or Workstation/Fusion) and what versions? Also what > virtual NIC is used in the VM? > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821101] Re: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade
@bdmurray The second fallback when debug is on, but the apt error is shown as a warning even when debug mode is not enabled: ... WARNING:root:package test3-package upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) IMO this is enough for the collected logs and in the development branch i would like to retire the adjustment logic and rely on internal pinning to make apt resolver do the right thing without fallbacks in u-u. -- 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/1821101 Title: unattended-upgrades: Fall back to adjusting more packages' candidates when a package from an allowed origin can't be marked to install/upgrade Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: In Progress Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Bug description: [Impact] * Without the introduced fallbacks u-u could not upgrade particular package sets from -security. It could be observed in Cosmic with systemd security updates failing to install in: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz [Test Case] * The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback: Running ./test_rewind.py with python3 DEBUG:root:APT::VersionedKernelPackages is not set DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:falling back to marking test2-package, then adjusting changes DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:falling back to marking test3-package, then adjusting changes WARNING:root:package test3-package upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.) DEBUG:root:falling back to adjusting all packages DEBUG:root:adjusting candidate version: test-package=2.0 DEBUG:root:adjusting candidate version: test2-package=2.0 DEBUG:root:adjusting candidate version: test2-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-old-package-dependency=2.0 DEBUG:root:adjusting candidate version: test3-package=2.0 WARNING:root:package z-package upgradable but fails to be marked for upgrade () . -- Ran 1 test in 0.039s OK [Regression Potential] * When failing to mark a package to upgrade/install from the allowed origin holding the highest version the first fallback resets all already adjusted candidates to the highest available version irrespective to the origin of this version being allowed or not. This itself is not a risky operation and sanity checks later ensure that no package would be installed from not allowed origins but it can trigger code paths in apt that were not tried before and may crash. * In testing apt's resolver failed to find a solution for upgrading packages with the first fallback raising an error, but the second fallback handles the error and tries adjusting _all_ potentially upgradable/installable package at the expense of using much more CPU time. This second fallback is not expected to be reached often (it is not reached in autopkgtests either) and adjusting all of those packages matches an earlier behavior of u-u, thus the slow-down may not be considered a regression. [Other Info] * If the second fallback is found to be reached often a different fallback can be introduced before the first one, to adjust all packages from the same source package then try again: See: https://github.com/mvo5/unattended-upgrades/pull/175#discussion_r268226796 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821101/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822370] Re: 19.04 beta openssh-client broken pipe
The internal VMware bug 2319367 I created was closed as a duplicate of bug 2275007 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: New versions of openssh (as in Ubuntu 19.04) are reported to trigger a connection issue: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe In most of the cases this seems to affect VMWare based environments as there is a bug in their implementation in regard to the traffic shaping protocols. Until resolved by VMWare the workarounds for now are: Configure your client to use the old defaults permanently in => /etc/ssh/ssh_config Host * IPQoS lowdelay throughput # You might want to limit to your VMware based systems Or per command via: $ ssh IPQoS="latency throughput" user@host Two values as one is for interactive and one for non-interactive use cases. original report Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: debconf (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Confirmed Bug description: AFFECTED RELEASE: Bionic PACKAGE VERSION: debconf - 1.5.66 DESCRIPTION: When upgrading the kernel on a recent Bionic minimal image, the user is prompted to resolve a conflict in the file /boot/grub/menu.lst. The minimal images do not have dialog/whiptail installed, so debconf falls back to using the readline frontend. The user sees the prompt: "What would you like to do about menu.lst?" but is not presented with the list of options to choose from. If a valid option is typed in, debconf will continue processing correctly and the list of options appears on the screen. See also https://pastebin.ubuntu.com/p/8xvSn88SKG/ STEPS TO REPRODUCE: Launch the minimal Bionic image with serial 20190212 http://cloud- images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04 -minimal-cloudimg-amd64.img for example via multipass and run `apt-get update` and `apt-get dist- upgrade`. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822736] Re: Passwords longer than 255 characters break authentication
I followed Tom's REPRODUCTION test, and got exactly what Tom said I would. I can confirm the issue with 256 character passwords. (I used `wc` to count characters in my buffer) I could set the 256 character password (I used it with a backspace to enter the old password, so it was only 1 character longer) but it wouldn't then let me use it for the next `sudo whoami`. x86 Lubuntu 19.04 (fully-updated) box OS: Ubuntu Disco Dingo (development branch) i686 Host: HP Compaq dx6120 MT(PL926AV) Kernel: 5.0.0-8-generic Uptime: 14 mins Packages: 1968 (dpkg) Shell: bash 5.0.2 Theme: Arc-Darker [GTK3] Icons: Adwaita [GTK3] Terminal: qterminal CPU: Intel Pentium 4 2.80GHz (2) @ 2.790GHz GPU: NVIDIA GeForce 7600 GT Memory: 487MiB / 2953MiB test@dx6120-lubu:~$ apt-cache policy libpam0g libpam0g: Installed: 1.3.1-5ubuntu1 Candidate: 1.3.1-5ubuntu1 Version table: *** 1.3.1-5ubuntu1 500 500 http://ftp.iinet.net.au/pub/ubuntu disco/main i386 Packages 100 /var/lib/dpkg/status -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1822736 Title: Passwords longer than 255 characters break authentication Status in pam package in Ubuntu: Confirmed Bug description: DISCUSSION When a password longer than 255 characters is set for any user account, this user will become unable to authenticate when running 'sudo' or 'passwd'. IMPACT This affects 18.04.2 systems, whether they were installed using Desktop (ubiquity) or Server (subiquity) installers. It may also affect other releases - this is yet untested. Tagged 'security' since these utilities then deny service to this user. REPRODUCTION # Add user 'test' with password 'testtest' sudo adduser --gecos '' test # Add user 'test' to the 'sudo' group sudo adduser test sudo # Become user 'test' sudo -iu test # Verify user 'test' can run commands via sudo sudo whoami # Change password of 'test' to this 255 character long password: 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to 'testtest': passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to this 256 character long password: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # This authentication fails, as sudo does not accept the 256 character password. # Attempting to change this password to a different value also fails: passwd # Effectively, user 'test' is now unable to use sudo, or to change their password. # The 'login' command, run by root, does, however, still enable user 'test' to login using the newly set 256 character password. # At the same time, a different restricted user who is a member of the 'sudo' group can still set a new password for 'test' (after authenticating to sudo with their own password) by supplying the current 256 character password using: sudo -u test passwd # Finally, to clean up sudo deluser --remove-home test ADDITIONAL OBSERVATIONS * A root-initiated 'login' command still allows this user to authenticate. * A different restricted user who is a member of the 'sudo' group can still set a new password for for this users' account (after authenticating to sudo with their own password) by supplying the >=256 character password CREDIT This was originally reported by 'Fieldy', I just reproduced it / filed this bug report. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libpam0g 1.1.8-3.6ubuntu2.18.04.1 ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-16-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 09:39:39 2019 SourcePackage: pam UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1822736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest
The attachment "Fix to identify virtualization type correctly in Xenial on PowerPC" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1764628 Title: incorrect hypervisor and virtualization type reported in compat mode guest Status in The Ubuntu-power-systems project: In Progress Status in util-linux package in Ubuntu: In Progress Bug description: [IMPACT] In xenial lscpu prints the wrong "Hypervisor vendor" and "Virtualization type" on PowerVM or KVM systems. Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC. [TEST] Curent output: ubuntu@P8lpar3:~$ dpkg -l "*util-linux*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii util-linux 2.31.1-0.4ub ppc64el miscellaneous system utilities un util-linux-loc (no description available) ubuntu@P8lpar3:~$ lscpu Architecture:ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s):2 Model: 2.1 (pvr 004b 0201) Model name: POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 ubuntu@P8lpar3:~$ Expected Output: $ lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):128 On-line CPU(s) list: 0-127 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 16 NUMA node(s): 2 Model: 2.1 (pvr 004b 0201) Model name:POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 [Potential Regression] The fix changes the logic to how lscpu-dmi returns from read_hypervisor_dmi() this could introduce potential regression in platforms that has incorrect DMI information. [Other Info] ---uname output--- Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux Machine Type = boston-LC ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC: root@guest:/tmp# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):2 On-line CPU(s) list: 0,1 Thread(s) per core:2 Core(s) per socket:1 Socket(s): 1 NUMA node(s): 1 Model: 2.2 (pvr 004e 1202) Model name:POWER8 (architected), altivec supported >> Hypervisor vendor: horizontal >> Virtualization type: full L1d cache: 32K L1i cache: 32K NUMA node0 CPU(s): 0,1 Stack trace output: no Oops output: no We test what is coming along with distro. If you are not able to see issue with : https://launchpad.net/ubuntu/+source/util- linux/2.27.1-6ubuntu3.5 .. can we get this included in 16.04.x train ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1764628/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822881] [NEW] Whenever an application accesses the audio device there's a loud pop
Public bug reported: Upon an upgrade to disco, now when anything access the audio output I get a loud pop. Happens with a browser (firefox and chrome), spotify, etc. It's independent of the application. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: pulseaudio 1:12.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: dean 3841 F pulseaudio /dev/snd/controlC0: dean 3841 F pulseaudio /dev/snd/controlC1: dean 3841 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 15:45:32 2019 InstallationDate: Installed on 2018-07-24 (252 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180724) ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: Upgraded to disco on 2019-04-02 (0 days ago) dmi.bios.date: 05/16/2018 dmi.bios.vendor: Intel Corp. dmi.bios.version: KYSKLi70.86A.0055.2018.0516.1629 dmi.board.name: NUC6i7KYB dmi.board.vendor: Intel Corporation dmi.board.version: H90766-406 dmi.chassis.type: 3 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnIntelCorp.:bvrKYSKLi70.86A.0055.2018.0516.1629:bd05/16/2018:svn:pn:pvr:rvnIntelCorporation:rnNUC6i7KYB:rvrH90766-406:cvnIntelCorporation:ct3:cvr1.0: ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug disco -- 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/1822881 Title: Whenever an application accesses the audio device there's a loud pop Status in pulseaudio package in Ubuntu: New Bug description: Upon an upgrade to disco, now when anything access the audio output I get a loud pop. Happens with a browser (firefox and chrome), spotify, etc. It's independent of the application. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: pulseaudio 1:12.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: dean 3841 F pulseaudio /dev/snd/controlC0: dean 3841 F pulseaudio /dev/snd/controlC1: dean 3841 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 15:45:32 2019 InstallationDate: Installed on 2018-07-24 (252 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180724) ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: Upgraded to disco on 2019-04-02 (0 days ago) dmi.bios.date: 05/16/2018 dmi.bios.vendor: Intel Corp. dmi.bios.version: KYSKLi70.86A.0055.2018.0516.1629 dmi.board.name: NUC6i7KYB dmi.board.vendor: Intel Corporation dmi.board.version: H90766-406 dmi.chassis.type: 3 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnIntelCorp.:bvrKYSKLi70.86A.0055.2018.0516.1629:bd05/16/2018:svn:pn:pvr:rvnIntelCorporation:rnNUC6i7KYB:rvrH90766-406:cvnIntelCorporation:ct3:cvr1.0: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1822881/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1816032] Re: gtk_widget_destroy reports error
Hello Anthony, or anyone else affected, Accepted gtk+3.0 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gtk+3.0/3.22.30-1ubuntu3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: gtk+3.0 (Ubuntu Bionic) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1816032 Title: gtk_widget_destroy reports error Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Bionic: Fix Committed Bug description: * Impact Buggy warnings are displayed in some cases, which can confuses users/coders * Test case Build and use the small program attached in the comments, it should display no warning * Regression potential The change is a simple null check in the combo widget code, the regression potential is low but make sure combos work in a few softwares just in case -- I have recently installed Ubuntu 18.04 on a new computer and have a Gtk+3.0 program that reports an error:- Gtk-CRITICAL gtk_widget_is_drawable: assertion 'GTK_IS_WIDGET (widget)' failed The same program runs without error on another computer with 16.04. The problem occurs when a ComboBoxText widget in a container (grid) is destroyed using gtk_widget_destroy. Other widgets may be affected but the problem does not occur for GtkScale widgets. The widget does actually get destroyed, but the message is produced in the process. I have also found that using gtk_container_remove avoids the error, but the docs indicate that this is inefficient and not preferred. I have attached a test program to reproduce the error. It also includes a few other things that I tried to see if they made any difference but to no avail. 'Destroy cbox' is the essential test to reproduce. System details: Description:Ubuntu 18.04.1 LTS Release:18.04 libwxgtk3.0-dev: Installed: (none) Candidate: 3.0.4+dfsg-3 Version table: 3.0.4+dfsg-3 500 500 http://au.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1816032/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
I'm slightly concerned about raising the TLS minimums in our next LTS release without some exposure to it in the 19.10 release. But this plan sounds better than waiting until 20.10 to raise the minimums -- and 19.10 may be too soon to take the step. But we don't have to decide on 19.10 defaults just yet. Thanks for the explanation on why the change wouldn't make sense to backport to previous releases. Modifying enough applications to allow downgrades where necessary would carry significant risk of regressions for users. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: In Progress Status in libio-socket-ssl-perl source package in Bionic: New Status in libnet-ssleay-perl source package in Bionic: New Status in nova source package in Bionic: New Status in openssl source package in Bionic: Confirmed Status in python-cryptography source package in Bionic: New Status in python2.7 source package in Bionic: New Status in python3.6 source package in Bionic: New Status in python3.7 source package in Bionic: New Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: New Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. * This update bundles python 3.6 and 3.7 point releases * Following the change in Cosmic and up, this SRU also includes a distro patch that lowers OPENSSL_TLS_SECURITY_LEVEL from 1 to 0, to allow for establishing client->server server->client connections with lower grade security settings (e.g. sub-80bits keys, MD5/SHA1 certificate checksums, and other crap like that). This is to continue allow bionic clients to connect to servers operating with older 1.0.x based openssl, as typically clients are at no mercy to reject servers that do not have any better certs/keys/signatures. Thus potentially weak-security connections that previously would fail to establish to/from bionic, may now be accepted. Some may view this as a regression. In that case adjust openssl.cnf to a higher TLS_SECURITY_LEVEL, or use the openssl ctx APIs to set a higher TLS security level. See further comments in this bug report as to when we will be raising this LEVEL up (currently timeline is to raise to 2, in 20.04 LTS). [Other Info] * Previous FFe for OpenSSL in 18.10 is at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates * TLS v1.3 support in GnuTLS is expected to be available in 19.04 * Test OpenSSL is being prepared in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822898] [NEW] wget https://geoip.ubuntu.com/lookup fails in mini.iso d-i
Public bug reported: wget https://geoip.ubuntu.com/lookup fails in mini.iso d-i with Disabling SSL due to encountered errors ** Affects: debian-installer (Ubuntu) Importance: Undecided Status: New ** Affects: tzsetup (Ubuntu) Importance: Undecided Status: New ** Affects: wget (Ubuntu) Importance: Undecided Status: New ** Tags: rls-dd-incoming ** Also affects: tzsetup (Ubuntu) Importance: Undecided Status: New ** Also affects: debian-installer (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wget in Ubuntu. https://bugs.launchpad.net/bugs/1822898 Title: wget https://geoip.ubuntu.com/lookup fails in mini.iso d-i Status in debian-installer package in Ubuntu: New Status in tzsetup package in Ubuntu: New Status in wget package in Ubuntu: New Bug description: wget https://geoip.ubuntu.com/lookup fails in mini.iso d-i with Disabling SSL due to encountered errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1822898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest
Please review and consider this debdiff to Xenial. It fixes the issue reported here. == Before the patch == ubuntu@P8lpar3:~$ lscpu Architecture:ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s):2 Model: 2.1 (pvr 004b 0201) Model name: POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 ubuntu@P8lpar3:~$ == After the patch == ubuntu@P8lpar3:~$ ~/lscpu/build/util-linux-2.27.1/lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):128 On-line CPU(s) list: 0-127 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 16 NUMA node(s): 2 Model: 2.1 (pvr 004b 0201) Model name:POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 ubuntu@P8lpar3:~$ ** Description changed: + [IMPACT] + + In xenial lscpu prints the wrong "Hypervisor vendor" and "Virtualization + type" on PowerVM or KVM systems. Incorrect hypervisor and virtualization + type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 + boston-LC. + + [TEST] + + Curent output: + + ubuntu@P8lpar3:~$ dpkg -l "*util-linux*" + Desired=Unknown/Install/Remove/Purge/Hold + | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend + |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) + ||/ Name Version Architecture Description + +++-==---= + ii util-linux 2.31.1-0.4ub ppc64el miscellaneous system utilities + un util-linux-loc (no description available) + + ubuntu@P8lpar3:~$ lscpu + Architecture:ppc64le + Byte Order: Little Endian + CPU(s): 128 + On-line CPU(s) list: 0-127 + Thread(s) per core: 8 + Core(s) per socket: 1 + Socket(s): 16 + NUMA node(s):2 + Model: 2.1 (pvr 004b 0201) + Model name: POWER8 (architected), altivec supported + Hypervisor vendor: pHyp + Virtualization type: para + L1d cache: 64K + L1i cache: 32K + NUMA node0 CPU(s): + NUMA node4 CPU(s): 0-127 + ubuntu@P8lpar3:~$ + + Expected Output: + + $ lscpu + Architecture: ppc64le + Byte Order:Little Endian + CPU(s):128 + On-line CPU(s) list: 0-127 + Thread(s) per core:8 + Core(s) per socket:1 + Socket(s): 16 + NUMA node(s): 2 + Model: 2.1 (pvr 004b 0201) + Model name:POWER8 (architected), altivec supported + Hypervisor vendor: pHyp + Virtualization type: para + L1d cache: 64K + L1i cache: 32K + NUMA node0 CPU(s): + NUMA node4 CPU(s): 0-127 + + [Potential Regression] + The fix changes the logic to how lscpu-dmi returns from read_hypervisor_dmi() this could introduce potential regression in platforms that has incorrect DMI information. + + [Other Info] ---uname output--- Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux - - Machine Type = boston-LC - + + Machine Type = boston-LC + ---Debugger--- A debugger is not configured - + ---Steps to Reproduce--- - Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC: + Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC: root@guest:/tmp# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):2 On-line CPU(s) list: 0,1 Thread(s) per core:2 Core(s) per socket:1 Socket(s): 1 NUMA node(s): 1 Model: 2.2 (pvr 004e 1202) Model name:POWER8 (architected), altivec supported >> Hypervisor vendor: horizontal >> Virtualization type: full L1d cache: 32K L1i cache: 32K NUMA node0 CPU(s): 0,1 + Stack trace output: + no - - Stack trace output: - no - Oops output: - no - + no - - We test what is coming along with distro. If you are not able to see issue with : https://launchpad.net/ubuntu/+source/util-linux/2.27.1-6ubuntu3.5 .. can we get this included in 16.04.x train ? + We test what is coming along with distro. If you are not able to see + issue with : https://launchpad.net/ubuntu/+source/util- + linux/2.27.1-6ubuntu3.5 .. can we get this included in 16.04.x train ? ** Patch added: "Fix to identify virtualization type correctly in
[Touch-packages] [Bug 1822736] Re: Passwords longer than 255 characters break authentication
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: pam (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1822736 Title: Passwords longer than 255 characters break authentication Status in pam package in Ubuntu: Confirmed Bug description: DISCUSSION When a password longer than 255 characters is set for any user account, this user will become unable to authenticate when running 'sudo' or 'passwd'. IMPACT This affects 18.04.2 systems, whether they were installed using Desktop (ubiquity) or Server (subiquity) installers. It may also affect other releases - this is yet untested. Tagged 'security' since these utilities then deny service to this user. REPRODUCTION # Add user 'test' with password 'testtest' sudo adduser --gecos '' test # Add user 'test' to the 'sudo' group sudo adduser test sudo # Become user 'test' sudo -iu test # Verify user 'test' can run commands via sudo sudo whoami # Change password of 'test' to this 255 character long password: 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to 'testtest': passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to this 256 character long password: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # This authentication fails, as sudo does not accept the 256 character password. # Attempting to change this password to a different value also fails: passwd # Effectively, user 'test' is now unable to use sudo, or to change their password. # The 'login' command, run by root, does, however, still enable user 'test' to login using the newly set 256 character password. # At the same time, a different restricted user who is a member of the 'sudo' group can still set a new password for 'test' (after authenticating to sudo with their own password) by supplying the current 256 character password using: sudo -u test passwd # Finally, to clean up sudo deluser --remove-home test ADDITIONAL OBSERVATIONS * A root-initiated 'login' command still allows this user to authenticate. * A different restricted user who is a member of the 'sudo' group can still set a new password for for this users' account (after authenticating to sudo with their own password) by supplying the >=256 character password CREDIT This was originally reported by 'Fieldy', I just reproduced it / filed this bug report. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libpam0g 1.1.8-3.6ubuntu2.18.04.1 ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-16-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 09:39:39 2019 SourcePackage: pam UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1822736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1503773] Re: Drop ondemand init script
** Also 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 sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1503773 Title: Drop ondemand init script Status in systemd package in Ubuntu: New Status in sysvinit package in Ubuntu: Fix Released Bug description: Ondemand init script is not inherited from Debian, it's an Ubuntu specific change. Some reasons to get rid of it: On my wily cloud test, systemd blame's 669ms on ondemand on a cloud instance with no ability to change frequency.. In the init script we don't run this for android Ondemand is already on by default! Why don't we just always use whatever is that kernel's default? There are a number of other reported problems with it: https://launchpad.net/ubuntu/+source/sysvinit/+bugs?field.searchtext=ondemand To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1503773/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1592177] Re: Focus drops from search input in GtkFileChooserDialog after first character, which stops searching (broken behaviour)
Hello Wise, or anyone else affected, Accepted gtk+3.0 into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gtk+3.0/3.24.4-0ubuntu1.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 and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: gtk+3.0 (Ubuntu Cosmic) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-cosmic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1592177 Title: Focus drops from search input in GtkFileChooserDialog after first character, which stops searching (broken behaviour) Status in GTK+: Expired Status in Ubuntu GNOME: New Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Bionic: Fix Committed Status in gtk+3.0 source package in Cosmic: Fix Committed Bug description: * Impact The focus gets removed from the search entry widget in the fileselector while typing which makes it difficult to use * Test case Steps: 1. Open Gedit 2. Choose Open -> Other Documents... to open a GtkFileChooserDialog 3. Press on the search button next to Open 4. Type what you are searching for Expected behaviour: Focus remains in the search input until I finish typing then results come up What happens instead: Searching stops after I enter the first characters because focus is lost from the search input * Regression potential The change is desactivating/reactivating typeahead in the gtk fileselector, check that this feature keeps working as it should (keyboard navigate by typing the first chars of a file/folder, that should move the focus to the first matching item and allows to navigate by hitting enter) I have noticed that after upgrading to GNOME 3.20 on Ubuntu GNOME 16.04 that the built-in search functionality is almost impossible to use in the GTK file chooser (though it is the same one that allows you to save files as well as choose them). So if one types something into the search, after they have typed the first letter it will immediately select the top search result meaning one has to re-select the search box, this happens for every letter so searching for a long string becomes very annoying. If one carries on typing once it has selected the top result and unselected the search box it will start searching in the other search which only looks at results. Upstream bug: https://gitlab.gnome.org/GNOME/gtk/issues/1572 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1592177/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Steve Langasek has pointed out that I missed the point of the bug. I'm not comfortable with OPENSSL_TLS_SECURITY_LEVEL=0 in bionic. (Or, indeed, in cosmic either.) We shipped 18.04 LTS with OPENSSL_TLS_SECURITY_LEVEL=1, correct? I don't recall seeing more than a handful of complaints about security parameter mismatches over the last year. If anything, users are asking for tighter defaults, not looser defaults. I don't believe we should be downgrading the default security level as a side effect of this transition. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: In Progress Status in libio-socket-ssl-perl source package in Bionic: New Status in libnet-ssleay-perl source package in Bionic: New Status in nova source package in Bionic: New Status in openssl source package in Bionic: Confirmed Status in python-cryptography source package in Bionic: New Status in python2.7 source package in Bionic: New Status in python3.6 source package in Bionic: New Status in python3.7 source package in Bionic: New Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: New Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. * This update bundles python 3.6 and 3.7 point releases * Following the change in Cosmic and up, this SRU also includes a distro patch that lowers OPENSSL_TLS_SECURITY_LEVEL from 1 to 0, to allow for establishing client->server server->client connections with lower grade security settings (e.g. sub-80bits keys, MD5/SHA1 certificate checksums, and other crap like that). This is to continue allow bionic clients to connect to servers operating with older 1.0.x based openssl, as typically clients are at no mercy to reject servers that do not have any better certs/keys/signatures. Thus potentially weak-security connections that previously would fail to establish to/from bionic, may now be accepted. Some may view this as a regression. In that case adjust openssl.cnf to a higher TLS_SECURITY_LEVEL, or use the openssl ctx APIs to set a higher TLS security level. See further comments in this bug report as to when we will be raising this LEVEL up (currently timeline is to raise to 2, in 20.04 LTS). [Other Info] * Previous FFe for OpenSSL in 18.10 is at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates * TLS v1.3 support in GnuTLS is expected to be available in 19.04 * Test OpenSSL is being prepared in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Proposed package upload rejected
An upload of openssl to bionic-proposed has been rejected from the upload queue for the following reason: "Should not introduce a delta to downgrade to OPENSSL_TLS_SECURITY_LEVEL=0 as part of this SRU". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: In Progress Status in libio-socket-ssl-perl source package in Bionic: New Status in libnet-ssleay-perl source package in Bionic: New Status in nova source package in Bionic: New Status in openssl source package in Bionic: Confirmed Status in python-cryptography source package in Bionic: New Status in python2.7 source package in Bionic: New Status in python3.6 source package in Bionic: New Status in python3.7 source package in Bionic: New Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: New Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. * This update bundles python 3.6 and 3.7 point releases * Following the change in Cosmic and up, this SRU also includes a distro patch that lowers OPENSSL_TLS_SECURITY_LEVEL from 1 to 0, to allow for establishing client->server server->client connections with lower grade security settings (e.g. sub-80bits keys, MD5/SHA1 certificate checksums, and other crap like that). This is to continue allow bionic clients to connect to servers operating with older 1.0.x based openssl, as typically clients are at no mercy to reject servers that do not have any better certs/keys/signatures. Thus potentially weak-security connections that previously would fail to establish to/from bionic, may now be accepted. Some may view this as a regression. In that case adjust openssl.cnf to a higher TLS_SECURITY_LEVEL, or use the openssl ctx APIs to set a higher TLS security level. See further comments in this bug report as to when we will be raising this LEVEL up (currently timeline is to raise to 2, in 20.04 LTS). [Other Info] * Previous FFe for OpenSSL in 18.10 is at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates * TLS v1.3 support in GnuTLS is expected to be available in 19.04 * Test OpenSSL is being prepared in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1592177] Re: Focus drops from search input in GtkFileChooserDialog after first character, which stops searching (broken behaviour)
Hello Wise, or anyone else affected, Accepted gtk+3.0 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gtk+3.0/3.22.30-1ubuntu3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: gtk+3.0 (Ubuntu Bionic) Status: New => 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 gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1592177 Title: Focus drops from search input in GtkFileChooserDialog after first character, which stops searching (broken behaviour) Status in GTK+: Expired Status in Ubuntu GNOME: New Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Bionic: Fix Committed Status in gtk+3.0 source package in Cosmic: Fix Committed Bug description: * Impact The focus gets removed from the search entry widget in the fileselector while typing which makes it difficult to use * Test case Steps: 1. Open Gedit 2. Choose Open -> Other Documents... to open a GtkFileChooserDialog 3. Press on the search button next to Open 4. Type what you are searching for Expected behaviour: Focus remains in the search input until I finish typing then results come up What happens instead: Searching stops after I enter the first characters because focus is lost from the search input * Regression potential The change is desactivating/reactivating typeahead in the gtk fileselector, check that this feature keeps working as it should (keyboard navigate by typing the first chars of a file/folder, that should move the focus to the first matching item and allows to navigate by hitting enter) I have noticed that after upgrading to GNOME 3.20 on Ubuntu GNOME 16.04 that the built-in search functionality is almost impossible to use in the GTK file chooser (though it is the same one that allows you to save files as well as choose them). So if one types something into the search, after they have typed the first letter it will immediately select the top search result meaning one has to re-select the search box, this happens for every letter so searching for a long string becomes very annoying. If one carries on typing once it has selected the top result and unselected the search box it will start searching in the other search which only looks at results. Upstream bug: https://gitlab.gnome.org/GNOME/gtk/issues/1572 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libgtk-3-0 3.22.30-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1592177/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1798313] Re: traceoute6 gives error sendto: Invalid argument
Hello! I just wanted to chime in: My co-worker and I ran into this exact problem. The `traceroute6` command was giving us "sendto: Invalid argument", and we did not have the `traceroute` package installed. It was only by finding this Launchpad bug that we became aware of the problem, after about half an hour of confusion and web-searching. One other note: In addition to installing the `traceroute` package, we also had to use `update-alternatives`, so that running traceroute (or traceroute6) would go to the executable provided by the traceroute package. This was really confusing, so I would like to suggest that some sort of action be taken upstream: Maybe a Release Notes item, or some other way to let sysadmins know that the `traceroute6` executable in the iputils package has an important bug (as per the Debian bug entry), and that the workaround is to install the traceroute package, and then use `update- alternatives` to set traceroute's traceroute6 as the preferred traceroute6. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1798313 Title: traceoute6 gives error sendto: Invalid argument Status in Iputils: Fix Released Status in iputils package in Ubuntu: Confirmed Status in iputils package in Debian: Fix Released Bug description: When running the following command all get is an error. (traceroute6.db works) # traceroute6.iputils 2001:4860:4860:: traceroute to 2001:4860:4860:: (2001:4860:4860::) from 2a00:8780:3:42:b92a:b222:8bed:4a9b, 30 hops max, 24 byte packets sendto: Invalid argument 1 traceroute: wrote 2001:4860:4860:: 24 chars, ret=-1 *sendto: Invalid argument traceroute: wrote 2001:4860:4860:: 24 chars, ret=-1 *sendto: Invalid argument traceroute: wrote 2001:4860:4860:: 24 chars, ret=-1 * This seems like a regression of Debian bug https://bugs.debian.org /cgi-bin/bugreport.cgi?bug=843264 Package version installed: iputils-tracepath 3:20161105-1ubuntu2 amd64 # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic To manage notifications about this bug go to: https://bugs.launchpad.net/iputils/+bug/1798313/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1658188] Re: /usr/share/apport/apport-gtk:TypeError:/usr/share/apport/apport-gtk@597:run_argv:run_crashes
Hello errors.ubuntu.com, or anyone else affected, Accepted apport into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apport/2.20.10-0ubuntu13.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apport (Ubuntu Cosmic) Status: In Progress => Fix Committed ** Tags removed: verification-done ** Tags added: verification-needed verification-needed-cosmic -- 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/1658188 Title: /usr/share/apport/apport-gtk:TypeError:/usr/share/apport/apport- gtk@597:run_argv:run_crashes Status in apport package in Ubuntu: Fix Released Status in apport source package in Xenial: Fix Released Status in apport source package in Bionic: Fix Released Status in apport source package in Cosmic: Fix Committed Bug description: [Test Case] Check Error Tracker bucket and make sure version from -proposed doesn't show up there. Given that this happens a whole bunch we should know pretty quick if its fixed. [Regression Potential] The test being modified is designed to not report crashes that happen during logout. It's possible that some reports don't have a Date in them but in that case we couldn't compare the logind_session information to the Date anyway so those crashes would have been reported anyway. Regardless, the potential is that we'll have some more crashes reported about things crashing on logout which is better than the hundreds of crashes we get like this one. The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with package version 2.20.3-0ubuntu8.2, the problem page at https://errors.ubuntu.com/problem/65cb22d7c29a308dad9368b971e1b8d6384c9089 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 you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1658188/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest
A test package is available in PPA: https://launchpad.net/~manjo/+archive/ubuntu/lp1764628/ -- 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/1764628 Title: incorrect hypervisor and virtualization type reported in compat mode guest Status in The Ubuntu-power-systems project: In Progress Status in util-linux package in Ubuntu: In Progress Bug description: [IMPACT] In xenial lscpu prints the wrong "Hypervisor vendor" and "Virtualization type" on PowerVM or KVM systems. Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC. [TEST] Curent output: ubuntu@P8lpar3:~$ dpkg -l "*util-linux*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii util-linux 2.31.1-0.4ub ppc64el miscellaneous system utilities un util-linux-loc (no description available) ubuntu@P8lpar3:~$ lscpu Architecture:ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s):2 Model: 2.1 (pvr 004b 0201) Model name: POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 ubuntu@P8lpar3:~$ Expected Output: $ lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):128 On-line CPU(s) list: 0-127 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 16 NUMA node(s): 2 Model: 2.1 (pvr 004b 0201) Model name:POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 [Potential Regression] The fix changes the logic to how lscpu-dmi returns from read_hypervisor_dmi() this could introduce potential regression in platforms that has incorrect DMI information. [Other Info] ---uname output--- Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux Machine Type = boston-LC ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC: root@guest:/tmp# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):2 On-line CPU(s) list: 0,1 Thread(s) per core:2 Core(s) per socket:1 Socket(s): 1 NUMA node(s): 1 Model: 2.2 (pvr 004e 1202) Model name:POWER8 (architected), altivec supported >> Hypervisor vendor: horizontal >> Virtualization type: full L1d cache: 32K L1i cache: 32K NUMA node0 CPU(s): 0,1 Stack trace output: no Oops output: no We test what is coming along with distro. If you are not able to see issue with : https://launchpad.net/ubuntu/+source/util- linux/2.27.1-6ubuntu3.5 .. can we get this included in 16.04.x train ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1764628/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822717] Re: SRU: build more cross packages on arm64 and ppc64el
ppc64el, s390x and riscv64 packages are built on arm64, s390x and riscv64 packages are built on ppc64el ** Tags removed: verification-needed verification-needed-bionic verification-needed-cosmic ** Tags added: verification-done verification-done-bionic verification-done-cosmic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1822717 Title: SRU: build more cross packages on arm64 and ppc64el Status in binutils package in Ubuntu: New Status in binutils source package in Bionic: Fix Committed Status in binutils source package in Cosmic: Fix Committed Bug description: extending LP: #1769657, this builds more cross packages on arm64 and ppc64el: * Build ppc64el packages on arm64. * Build s390x packages on arm64 and ppc64el. * Build riscv64 packages on arm64 and ppc64el. SRU information: This is a no-change upload for all existing binary packages, it just add some more new cross packages. Regression potential is the same as for any other no-change upload. Test case: make sure the selected new cross packages build on the newly enabled architectures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1822717/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822736] Re: Passwords longer than 255 characters break authentication
It is yet unclear what the root cause of this issue is - libpam, crypt, passwd and sudo seem like primary suspects. The 256 character password is hashed to a value which still allows a TTY login to succeed. Also, passwd run by a different user in the context of the affected user (using sudo) still works. So apparently it only breaks for the logged-in user. This may help identify the root cause. pam_unix(8) (on bionic) states: The maximum length of a password supported by the pam_unix module via the helper binary is PAM_MAX_RESP_SIZE - currently 512 bytes. The rest of the password provided by the conversation function to the module will be ignored. Regarding passwd, I was told this on IRC: passwd uses getpass() to read the password from the user, and testing just getpass() alone shows it will return up to 4095 bytes long (i.e. truncates at that length). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1822736 Title: Passwords longer than 255 characters break authentication Status in pam package in Ubuntu: Confirmed Bug description: DISCUSSION When a password longer than 255 characters is set for any user account, this user will become unable to authenticate when running 'sudo' or 'passwd'. IMPACT This affects 18.04.2 systems, whether they were installed using Desktop (ubiquity) or Server (subiquity) installers. It may also affect other releases - this is yet untested. Tagged 'security' since these utilities then deny service to this user. REPRODUCTION # Add user 'test' with password 'testtest' sudo adduser --gecos '' test # Add user 'test' to the 'sudo' group sudo adduser test sudo # Become user 'test' sudo -iu test # Verify user 'test' can run commands via sudo sudo whoami # Change password of 'test' to this 255 character long password: 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to 'testtest': passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to this 256 character long password: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # This authentication fails, as sudo does not accept the 256 character password. # Attempting to change this password to a different value also fails: passwd # Effectively, user 'test' is now unable to use sudo, or to change their password. # The 'login' command, run by root, does, however, still enable user 'test' to login using the newly set 256 character password. # At the same time, a different restricted user who is a member of the 'sudo' group can still set a new password for 'test' (after authenticating to sudo with their own password) by supplying the current 256 character password using: sudo -u test passwd # Finally, to clean up sudo deluser --remove-home test ADDITIONAL OBSERVATIONS * A root-initiated 'login' command still allows this user to authenticate. * A different restricted user who is a member of the 'sudo' group can still set a new password for for this users' account (after authenticating to sudo with their own password) by supplying the >=256 character password CREDIT This was originally reported by 'Fieldy', I just reproduced it / filed this bug report. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libpam0g 1.1.8-3.6ubuntu2.18.04.1 ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-16-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 09:39:39 2019 SourcePackage: pam UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1822736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822426] Re: 19.04 Built in Intel HDA sound is disabled upon resume
Not sure if recent updates have fixed the issue, but problem has not appeared after several sleep and awake events. I will ensure to post details and try the above edit if problem recurs. -- 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/1822426 Title: 19.04 Built in Intel HDA sound is disabled upon resume Status in pulseaudio package in Ubuntu: Incomplete Bug description: With 19.04, Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller intermittently is not enabled when resuming from sleep. The HDMI sound device is enabled but that is not hooked up on my system. New with 19.04, when sound works after resume, an icon labeled "Built in Audio Stereo" appears during the resume process. Unsure if this is related, but sound seems to sleep when not in use. Launching sound enabled apps produces a quiet "tick, thud" sound as sound system turns on. When sound is not working, killall pusleaudio "fixes" the issue. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: pulseaudio 1:12.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: darin 4814 F pulseaudio /dev/snd/controlC1: darin 4814 F pulseaudio /dev/snd/controlC0: darin 4814 F pulseaudio CurrentDesktop: KDE Date: Sat Mar 30 10:20:24 2019 InstallationDate: Installed on 2018-01-13 (441 days ago) InstallationMedia: Kubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180112) SourcePackage: pulseaudio UpgradeStatus: Upgraded to disco on 2019-03-27 (3 days ago) dmi.bios.date: 08/18/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2103 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: Z87-PRO dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2103:bd08/18/2014:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ87-PRO:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: ASUS MB dmi.product.name: All Series dmi.product.sku: All dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1822426/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822881] Re: Whenever an application accesses the audio device there's a loud pop
*** This bug is a duplicate of bug 1821663 *** https://bugs.launchpad.net/bugs/1821663 Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 1821663, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find. ** This bug has been marked a duplicate of bug 1821663 [snd_hda_codec_realtek] repeating crackling noise after 19.04 upgrade -- 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/1822881 Title: Whenever an application accesses the audio device there's a loud pop Status in pulseaudio package in Ubuntu: New Bug description: Upon an upgrade to disco, now when anything access the audio output I get a loud pop. Happens with a browser (firefox and chrome), spotify, etc. It's independent of the application. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: pulseaudio 1:12.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: dean 3841 F pulseaudio /dev/snd/controlC0: dean 3841 F pulseaudio /dev/snd/controlC1: dean 3841 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 15:45:32 2019 InstallationDate: Installed on 2018-07-24 (252 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180724) ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: Upgraded to disco on 2019-04-02 (0 days ago) dmi.bios.date: 05/16/2018 dmi.bios.vendor: Intel Corp. dmi.bios.version: KYSKLi70.86A.0055.2018.0516.1629 dmi.board.name: NUC6i7KYB dmi.board.vendor: Intel Corporation dmi.board.version: H90766-406 dmi.chassis.type: 3 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnIntelCorp.:bvrKYSKLi70.86A.0055.2018.0516.1629:bd05/16/2018:svn:pn:pvr:rvnIntelCorporation:rnNUC6i7KYB:rvrH90766-406:cvnIntelCorporation:ct3:cvr1.0: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1822881/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821609] Re: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870
now this begs the question why does kernel module i915 not auto load anymore? i.e. the newer iso's since mid-march ..??? what got yanked out that would cause this ?? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1821609 Title: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 Status in lightdm package in Ubuntu: New Status in xorg-server package in Ubuntu: New Bug description: Okay the has happened recently at least since march 18, 2019 iso and march 22, 2019 iso are both effected very similar to one of my previously reported bugs .. which was related to xorg not being installed .. back ground .. PC is lenovo sl 500 with evo860 SSD drive 3 partions contain installs of disco sda1 -- main working system -- I usually install grub from here as master .. sda6 and sda7 are test installs of disco daily iso's 03-18-2019, 03-22-2019 repectively on the test installs as long as the iso is using the grub boot loader installed from that install the system will boot normally .. the display manger tends to flicker on and off but does final start and login can proceed. but if another install re-installs grub as master the display manager fails to stay active or even come-up for sda6 or sda7 only if their own grubs are reinstalled will they work normally sda1 display manager/xorg login works always no matter which "grub- source" is in control. if I use rescue boot from any grub as master I can get the displays to work by running dpkg fix which does nothing .. and then resuming the boot .. then things work normally.. if the "non-rescue" boots are used the screen/computer locks and only a power down and reboot gives access. (sometime requiring radical depowering .. unpluging and removing battery) now the is a message that appears that RCs??? level is missing. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu11 ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 Uname: Linux 5.0.0-7-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Mon Mar 25 11:25:58 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GpuHangFrequency: Several times a day GpuHangReproducibility: Yes, I can easily reproduce it GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] InstallationDate: Installed on 2019-03-23 (1 days ago) InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190322) MachineType: LENOVO 2746CTO ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-7-generic root=UUID=1d61086d-275b-4537-bed5-f2d3080670eb ro recovery nomodeset SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 6AET64WW dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: 2746CTO dmi.board.vendor: LENOVO dmi.board.version: LENOVO 6AET64WW dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: LENOVO 6AET64WW dmi.modalias: dmi:bvnLENOVO:bvr6AET64WW:bd12/01/2010:svnLENOVO:pn2746CTO:pvrThinkPadSL500:rvnLENOVO:rn2746CTO:rvrLENOVO6AET64WW:cvnLENOVO:ct10:cvrLENOVO6AET64WW: dmi.product.name: 2746CTO dmi.product.version: ThinkPad SL500 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1821609/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1821609] Re: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870
okay .. thought about this for a bit i915 compiled as module by default in kernel sources.. lets force it to load.. added module i915 to /etc/modules to force loading .. it is the only entry .. reboot into the problem install .. and no problems .. lightdm starts and stays going. no flicker or flash off, delay, and on again at all either .. ** Attachment added: "Xorg.0.log--zl10 --module-i915 -forced to load" https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1821609/+attachment/5252326/+files/Xorg.0.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1821609 Title: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 Status in lightdm package in Ubuntu: New Status in xorg-server package in Ubuntu: New Bug description: Okay the has happened recently at least since march 18, 2019 iso and march 22, 2019 iso are both effected very similar to one of my previously reported bugs .. which was related to xorg not being installed .. back ground .. PC is lenovo sl 500 with evo860 SSD drive 3 partions contain installs of disco sda1 -- main working system -- I usually install grub from here as master .. sda6 and sda7 are test installs of disco daily iso's 03-18-2019, 03-22-2019 repectively on the test installs as long as the iso is using the grub boot loader installed from that install the system will boot normally .. the display manger tends to flicker on and off but does final start and login can proceed. but if another install re-installs grub as master the display manager fails to stay active or even come-up for sda6 or sda7 only if their own grubs are reinstalled will they work normally sda1 display manager/xorg login works always no matter which "grub- source" is in control. if I use rescue boot from any grub as master I can get the displays to work by running dpkg fix which does nothing .. and then resuming the boot .. then things work normally.. if the "non-rescue" boots are used the screen/computer locks and only a power down and reboot gives access. (sometime requiring radical depowering .. unpluging and removing battery) now the is a message that appears that RCs??? level is missing. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu11 ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 Uname: Linux 5.0.0-7-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Mon Mar 25 11:25:58 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GpuHangFrequency: Several times a day GpuHangReproducibility: Yes, I can easily reproduce it GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] InstallationDate: Installed on 2019-03-23 (1 days ago) InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190322) MachineType: LENOVO 2746CTO ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-7-generic root=UUID=1d61086d-275b-4537-bed5-f2d3080670eb ro recovery nomodeset SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 6AET64WW dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: 2746CTO dmi.board.vendor: LENOVO dmi.board.version: LENOVO 6AET64WW dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: LENOVO 6AET64WW dmi.modalias: dmi:bvnLENOVO:bvr6AET64WW:bd12/01/2010:svnLENOVO:pn2746CTO:pvrThinkPadSL500:rvnLENOVO:rn2746CTO:rvrLENOVO6AET64WW:cvnLENOVO:ct10:cvrLENOVO6AET64WW: dmi.product.name: 2746CTO dmi.product.version: ThinkPad SL500 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1821609/+subscriptions
[Touch-packages] [Bug 1817903] Re: systemd-resolve appends "options edns0" to resolv.conf
** No longer affects: resolvconf (Ubuntu Trusty) ** No longer affects: resolvconf (Ubuntu Xenial) ** No longer affects: systemd (Ubuntu Trusty) ** No longer affects: systemd (Ubuntu Xenial) ** No longer affects: systemd (Ubuntu) ** No longer affects: systemd (Ubuntu Cosmic) ** No longer affects: systemd (Ubuntu Bionic) ** No longer affects: systemd (Ubuntu Disco) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1817903 Title: systemd-resolve appends "options edns0" to resolv.conf Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf source package in Bionic: Fix Released Status in resolvconf source package in Cosmic: Fix Released Status in resolvconf source package in Disco: Fix Released Bug description: [impact] systems upgraded from pre-Bionic releases to Bionic or later will continue to use ifupdown/resolvconf for network conf and management, but resolvconf has a new systemd service in Bionic and later that pulls systemd-resolved stub-resolv.conf into its local configuration. With the recent addition of edns0 option to the stub resolver conf in systemd to fix bug 1811471, this means resolvconf now sets up the /etc/resolv.conf file to include upstream servers but also use edns. For any systems where the upstream resolver(s) don't support edns, dns lookups will break. [test case] == upgrade from pre-bionic (e.g. xenial) to bionic or later == 1) create a xenial system with ifupdown/resolvconf. The ifupdown config needs to include an upstream name server (must be static). At this point, once the network is configured and up, the resolvconf should have put the upstream name server(s) and search domain into the /etc/resolv.conf. As is usual for pre-systemd releases, there should be no local dns resolver in /etc/resolv.conf (i.e. 127.0.0.53 should not be included) at this point. 2) upgrade the system to bionic (alternately it should be possible to install bionic, then remove netplan and install/configure ifupdown and resolvconf, but I have not specifically tested this). The upgrade will retain the ifupdown/resolvconf configuration, and will not change to netplan/systemd-networkd. After upgrade is finished, the /etc/resolv.conf will contain: a) the upstream name server(s) b) options edns0 c) the local stub resolver (127.0.0.53) d) search domain the fixed resolvconf will remove (b). As mentioned, this case also should cover the situation of a native Bionic install, where netplan is removed and ifupdown/resolvconf is manually installed. == bionic or later install == with a bionic install, ifupdown is not installed, instead netplan /systemd-networkd handle networking. In this case, systemd-networkd manages the /etc/resolv.conf, and symlinks it to networkd's stub- resolv.conf which always contains only the local stub resolver (127.0.0.53) and (recently) options edns0, and local search domain. If resolvconf is installed while systemd-networkd is managing the network, then currently the resolv.conf contents will remain completely unchanged, still pointing to the local stub resolver. This resolvconf change will alter that, to remove 'options edns0'. No other changes will be made from the stub-resolv.conf. [regression potential] Regressions due to this change would likely be seen in dns query failures with other system configurations. This will cause systems with resolvconf installed to lose the fix from bug 1811471, and again experience that bug. [other info] This affects only Bionic and later; in Xenial and earlier, systemd does not handle dns, and the 'edns0' option was not added to that systemd-resolved anyway. This also does not affect Debian, as it does not include the 'resolvconf-pull-resolved' service either. original description: -- Mint 19 (Ubuntu 18.04) Following latest mint update done on 24/02/2019, DNS is broken nslookup and dig of certain domain names work as expected, ping does not (ip works but not domain name) After a day of trial and error, testing I found that the problem lies with the presence of "options edns0" in /run/resolvconf/resolv.conf (link to by /etc/resolv.conf) With option present many dns lookups fail with both FF and chrome browswers and thunderbird... This is on a home network, with router set as dns proxy for external wan, not using NetworkManager Deleting the option on live system results in the issue immediately disappearing, but on reboot it is added back in (by systemd-resolve ?) I cannot find any option to prevent this being added, so presumably it is hard-coded in systemd following the update? systemd: Installed: 237-3ubuntu10.13 To manage notifications about this bug go to:
[Touch-packages] [Bug 1822736] Re: Passwords longer than 255 characters break authentication
Booted up a Ubuntu 14.04 LTS box & followed test procedure. Same result - steps followed fine until I once 256 char password was entered, I was unable to `sudo whoami` (password was not accepted) OS: Ubuntu 14.04.6 LTS x86_64 Host: HP Compaq dc7700 Small Form Factor Kernel: 3.13.0-168-generic Uptime: 22 mins Packages: 2377 (dpkg) Shell: bash 4.3.11 Theme: Ambiant-MATE [GTK3] Icons: Ambiant-MATE [GTK3] Terminal: gnome-terminal CPU: Intel Core 2 6320 (2) @ 1.867GHz GPU: NVIDIA Quadro NVS 290 Memory: 1071MiB / 4896MiB test@dc7700ub:~$ apt-cache policy libpam0g libpam0g: Installed: 1.1.8-1ubuntu2.2 Candidate: 1.1.8-1ubuntu2.2 Version table: *** 1.1.8-1ubuntu2.2 0 500 http://ftp.iinet.net.au/pub/ubuntu/ trusty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.8-1ubuntu2 0 500 http://ftp.iinet.net.au/pub/ubuntu/ trusty/main amd64 Packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1822736 Title: Passwords longer than 255 characters break authentication Status in pam package in Ubuntu: Confirmed Bug description: DISCUSSION When a password longer than 255 characters is set for any user account, this user will become unable to authenticate when running 'sudo' or 'passwd'. IMPACT This affects 18.04.2 systems, whether they were installed using Desktop (ubiquity) or Server (subiquity) installers. It may also affect other releases - this is yet untested. Tagged 'security' since these utilities then deny service to this user. REPRODUCTION # Add user 'test' with password 'testtest' sudo adduser --gecos '' test # Add user 'test' to the 'sudo' group sudo adduser test sudo # Become user 'test' sudo -iu test # Verify user 'test' can run commands via sudo sudo whoami # Change password of 'test' to this 255 character long password: 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to 'testtest': passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # Change password of 'test' to this 256 character long password: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 passwd # Verify user 'test' can run commands via sudo with the new password set sudo -k sudo whoami# should report "root" # This authentication fails, as sudo does not accept the 256 character password. # Attempting to change this password to a different value also fails: passwd # Effectively, user 'test' is now unable to use sudo, or to change their password. # The 'login' command, run by root, does, however, still enable user 'test' to login using the newly set 256 character password. # At the same time, a different restricted user who is a member of the 'sudo' group can still set a new password for 'test' (after authenticating to sudo with their own password) by supplying the current 256 character password using: sudo -u test passwd # Finally, to clean up sudo deluser --remove-home test ADDITIONAL OBSERVATIONS * A root-initiated 'login' command still allows this user to authenticate. * A different restricted user who is a member of the 'sudo' group can still set a new password for for this users' account (after authenticating to sudo with their own password) by supplying the >=256 character password CREDIT This was originally reported by 'Fieldy', I just reproduced it / filed this bug report. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libpam0g 1.1.8-3.6ubuntu2.18.04.1 ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-16-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Apr 2 09:39:39 2019 SourcePackage: pam UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1822736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791405] Re: bluetooth always in discoverable mode (security issue)
Although the gnome-bluetooth "fix" sounds like a workaround. So re- adding a bluez task. ** Also affects: bluez (Ubuntu) Importance: Undecided Status: New ** Also affects: gnome-bluetooth (Ubuntu Ee-series) Importance: Undecided Status: New ** Also affects: bluez (Ubuntu Ee-series) Importance: Undecided Status: New ** Changed in: bluez (Ubuntu Ee-series) Status: New => Fix Committed ** No longer affects: gnome-bluetooth (Ubuntu Ee-series) ** Changed in: gnome-bluetooth (Ubuntu Bionic) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1791405 Title: bluetooth always in discoverable mode (security issue) Status in bluez package in Ubuntu: New Status in gnome-bluetooth package in Ubuntu: Fix Released Status in bluez source package in Bionic: New Status in gnome-bluetooth source package in Bionic: Fix Released Status in bluez source package in Cosmic: New Status in gnome-bluetooth source package in Cosmic: Fix Released Status in bluez source package in Disco: New Status in gnome-bluetooth source package in Disco: Fix Released Status in bluez source package in EE-Series: Fix Committed Status in gnome-bluetooth package in Fedora: Confirmed Bug description: Excerpt from a similar report (https://bugzilla.redhat.com/show_bug.cgi?id=1602985) : Opening the Bluetooth settings will make the device discoverable again, but does not make the device undiscoverable after the settings are closed (this is not intended behavior; devices should only be discoverable when the bluetooth settings UI is open). There seem to be a merge request : https://gitlab.gnome.org/GNOME/gnome-bluetooth/merge_requests/1 Could you please merge it asap, it should be treated as a security issue IMHO. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1791405/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791405] Re: bluetooth always in discoverable mode (security issue)
And the gnome-bluetooth fix was released in 3.28.2. ** Package changed: bluez (Ubuntu) => gnome-bluetooth (Ubuntu) ** Changed in: gnome-bluetooth (Ubuntu) Status: Fix Committed => Fix Released ** Also affects: gnome-bluetooth (Ubuntu Disco) Importance: Medium Status: Fix Released ** Also affects: gnome-bluetooth (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: gnome-bluetooth (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: gnome-bluetooth (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: gnome-bluetooth (Ubuntu Cosmic) Importance: Undecided => Medium ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-10910 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1791405 Title: bluetooth always in discoverable mode (security issue) Status in bluez package in Ubuntu: New Status in gnome-bluetooth package in Ubuntu: Fix Released Status in bluez source package in Bionic: New Status in gnome-bluetooth source package in Bionic: Fix Released Status in bluez source package in Cosmic: New Status in gnome-bluetooth source package in Cosmic: Fix Released Status in bluez source package in Disco: New Status in gnome-bluetooth source package in Disco: Fix Released Status in bluez source package in EE-Series: Fix Committed Status in gnome-bluetooth package in Fedora: Confirmed Bug description: Excerpt from a similar report (https://bugzilla.redhat.com/show_bug.cgi?id=1602985) : Opening the Bluetooth settings will make the device discoverable again, but does not make the device undiscoverable after the settings are closed (this is not intended behavior; devices should only be discoverable when the bluetooth settings UI is open). There seem to be a merge request : https://gitlab.gnome.org/GNOME/gnome-bluetooth/merge_requests/1 Could you please merge it asap, it should be treated as a security issue IMHO. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1791405/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
