[Touch-packages] [Bug 1835863] Re: Screens do not stay off when blanking
We will need to find out what is turning the screen on again. To do this please: 1. Wait until the screen turns off. 2. Wait until the screen turns on again by itself. 3. As soon as the screen turns itself on, run this command in a terminal: journalctl -b0 > curjournal.txt and send us the file 'curjournal.txt'. ** Package changed: xorg (Ubuntu) => ubuntu ** Changed in: ubuntu Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1835863 Title: Screens do not stay off when blanking Status in Ubuntu: Incomplete Bug description: After some idle period (5-15 minutes) the screens are supposed to blank and power off. They appear to do this once but then come right back on and stay on. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Jul 9 00:09:01 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 5.0.0-19-generic, x86_64: installed bcmwl, 6.30.223.271+bdcom, 5.0.0-20-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X] [1002:67b0] (rev 80) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Radeon R9 390X [1043:04df] InstallationDate: Installed on 2019-06-21 (17 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) MachineType: ASUS All Series ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-20-generic root=UUID=df9fe4e8-eacc-47f5-9df4-85a524802645 ro quiet splash radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/18/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2704 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: Z97I-PLUS dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2704:bd02/18/2016:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ97I-PLUS:rvrRevX.0x:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: ASUS MB dmi.product.name: All Series dmi.product.sku: All dmi.product.version: System Version dmi.sys.vendor: ASUS version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu3 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/+bug/1835863/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1717352] Re: Locale settings broken after debootstrap installation
[Expired for gnome-control-center (Ubuntu) because there has been no activity for 60 days.] ** Changed in: gnome-control-center (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1717352 Title: Locale settings broken after debootstrap installation Status in gnome-control-center package in Ubuntu: Expired Status in ubuntu-meta package in Ubuntu: Invalid Bug description: After installing Ubuntu 17.10 through debootstrap (because I stubbornly want to use ZFS), locale settings are broken. I've tested on a regular installation, where they operate fine. When trying to switch to English (United Kingdom), I found out that the only option is "English"... a dozen times Please see added screenshot for more information. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: gnome-control-center 1:3.25.92.1-0ubuntu2 ProcVersionSignature: Ubuntu 4.12.0-13.14-generic 4.12.10 Uname: Linux 4.12.0-13-generic x86_64 NonfreeKernelModules: nvidia_uvm zfs zunicode zavl zcommon znvpair nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Sep 14 22:14:04 2017 ExecutablePath: /usr/bin/gnome-control-center SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1717352/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835863] [NEW] Screens do not stay off when blanking
Public bug reported: After some idle period (5-15 minutes) the screens are supposed to blank and power off. They appear to do this once but then come right back on and stay on. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Jul 9 00:09:01 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 5.0.0-19-generic, x86_64: installed bcmwl, 6.30.223.271+bdcom, 5.0.0-20-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X] [1002:67b0] (rev 80) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Radeon R9 390X [1043:04df] InstallationDate: Installed on 2019-06-21 (17 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) MachineType: ASUS All Series ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-20-generic root=UUID=df9fe4e8-eacc-47f5-9df4-85a524802645 ro quiet splash radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/18/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2704 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: Z97I-PLUS dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2704:bd02/18/2016:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ97I-PLUS:rvrRevX.0x:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: ASUS MB dmi.product.name: All Series dmi.product.sku: All dmi.product.version: System Version dmi.sys.vendor: ASUS version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu3 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: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug disco 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/1835863 Title: Screens do not stay off when blanking Status in xorg package in Ubuntu: New Bug description: After some idle period (5-15 minutes) the screens are supposed to blank and power off. They appear to do this once but then come right back on and stay on. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Jul 9 00:09:01 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 5.0.0-19-generic, x86_64: installed bcmwl, 6.30.223.271+bdcom, 5.0.0-20-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X] [1002:67b0] (rev 80) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Radeon R9 390X [1043:04df] InstallationDate: Installed on 2019-06-21 (17 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) MachineType: ASUS All Series ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-20-generic root=UUID=df9fe4e8-eacc-47f5-9df4-85a524802645 ro quiet splash radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1
[Touch-packages] [Bug 1830858] Re: TOCTOU vulnerability in _get_ignore_dom (report.py)
** Branch linked: lp:~alexmurray/apport/apport -- 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/1830858 Title: TOCTOU vulnerability in _get_ignore_dom (report.py) Status in Apport: New Status in apport package in Ubuntu: Fix Released Bug description: Dear Ubuntu Security Team, I would like to report a privilege escalation vulnerability in Apport. The vulnerability is a TOCTOU which enables me to trick Apport into reading any file on the system and including it in a crash report file. I have attached a proof-of-concept which triggers the vulnerability. I have tested it on an up-to-date Ubuntu 18.04. Run it as follows: bunzip2 PoC.tar.bz2 tar -xf PoC.tar cd PoC make ./gencrashreport /etc/shadow At this point the following file has been created: /var/crash/_usr_share_apport_apport.0.crash You can use the apport-unpack tool to decompress this file. If you look at the contents of the CoreDump file then you will see that it contains the contents of /etc/shadow (or whichever other file you passed on the command line of gencrashreport). The bug has a couple of mitigations: 1. My PoC does not work if a file named /var/crash/.lock already exists and is owned by root. This file will only exist if Apport has previously generated a crash report. Based on an informal survey of my own 4 computers (yes - maybe I don't need that many), it usually does not exist (unless the computer is used for security research). 2. The generated crash report file, /var/crash/_usr_share_apport_apport.0.crash, is only readable by root and by the whoopsie user. It will be uploaded to daisy.ubuntu.com if you create a file named /var/crash/_usr_share_apport_apport.0.upload, but that is not a huge security concern because it wouldn't be of much benefit to an attacker. However, I have found some integer overflow vulnerabilities in whoopsie (which I will report separately). If those overflows can be exploited to gain code execution in whoopsie, then this will enable an attacker to read the contents of the crash report file. To improve the effectiveness of the first mitigation, I would recommend that you make sure that /var/crash/.lock is created (and owned by root) by the Ubuntu installer and/or whoopsie when it starts up. It does not fix the root cause though, which I will describe next. This is the source location of the TOCTOU vulnerability: https://git.launchpad.net/ubuntu/+source/apport/tree/apport/report.py?h=applied/ubuntu /bionic-devel=2fc8fb446c78e950d643bf49bb7d4a0dc3b05429#n962 Apport allows the user to place a file in their home directory named `~/.apport-ignore.xml`. The call to os.access() on line 962 is intended to check that this file belongs to the correct user. But on line 967, the file is read again using xml.dom.minidom.parse. This creates a window of opportunity for an attacker to replace the file with a symlink. The symlink does not need to point to a valid XML file, because there is a try-except around the call to the parser, so if the file is invalid then Apport just ignores it and continues. However, the contents of the file still ends up in Apport's heap. Here's a summary of how the PoC works: 1. Start a /bin/sleep and kill it with a SIGSEGV. 2. Apport starts up to generate a crash report for /bin/sleep 3. Replace ~/.apport-ignore.xml with a symlink at exactly the right moment, so that Apport loads a forbidden file into memory. 4. Wait until Apport drops privileges so that we can kill it with a SIGTRAP. 5. A second Apport starts up to generate a crash report for the first Apport. 6. The second Apport writes out a crash report for the first, containing a copy of the forbidden file in the core dump. Apport tries quite hard to not run recursively on itself, so I had to jump through a few hoops to make the PoC work: 1. Apport sets a lock on /var/crash/.lock, using lockf. But locks created by lockf are only "advisory". If I own the file, then I can replace it with a different file, thereby deactivating the lock. This is why my PoC only works if /var/crash/.lock doesn't already exist. I need to create it before Apport does, so that I can maintain ownership of it. 2. Apport has signal handlers for most of the core-generating signals, like SIGSEGV. But it doesn't have a handler for SIGTRAP, so that's what my PoC uses. 3. Apport is started with an RLIMIT_CORE value of 1, which is another recursion detection mechanism (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/498525/comments/3). But it is possible for another process to change it to zero, using prlimit. As I mentioned earlier, I have also found a few other vulnerabilities in whoopsie and Apport. I will file them as separate bugs and include a link to this issue.
[Touch-packages] [Bug 1830863] Re: Integer overflow in parse_report (whoopsie.c:425)
** Branch linked: lp:~alexmurray/whoopsie/whoopsie -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1830863 Title: Integer overflow in parse_report (whoopsie.c:425) Status in Whoopsie: New Status in whoopsie package in Ubuntu: Fix Released Bug description: Dear Ubuntu Security Team, I would like to report an integer overflow vulnerability in whoopsie. In combination with issue 1830858, this vulnerability may enable an local attacker to read arbitrary files on the system. I have attached a proof-of-concept which triggers the vulnerability. I have tested it on an up-to-date Ubuntu 18.04. Run it as follows: bunzip2 PoC.tar.bz2 tar -xf PoC.tar cd PoC make ./killwhoopsie1 The PoC works by creating a file named `/var/crash/killwhoopsie.crash`, just over 4GB in size. It then creates a file named `/var/crash/killwhoopsie.upload`, which prompts whoopsie to start processing the .crash file. Be aware that whoopsie will keep restarting and crash repeatedly until you remove the files from /var/crash. This is the source location of the integer overflow bug: http://bazaar.launchpad.net/~daisy- pluckers/whoopsie/trunk/view/698/src/whoopsie.c#L425 The problem is that the type of value_pos is int, but the size of the file can be larger than INT_MAX. My PoC arranges things such that value_pos == -16, leading to an out-of-bounds write on line 440. Please let me know when you have fixed the vulnerability, so that I can coordinate my disclosure with yours. For reference, here is a link to Semmle's vulnerability disclosure policy: https://lgtm.com/security#disclosure_policy Thank you, Kevin Backhouse Semmle Security Research Team To manage notifications about this bug go to: https://bugs.launchpad.net/whoopsie/+bug/1830863/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1834138] Re: PA: Don't restore the streams to sinks/sources with only unavailable ports
This is the debdiff for Cosmic. Thanks. ** Patch added: "pulseaudio_12.2-0ubuntu4.1.debdiff" https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1834138/+attachment/5275752/+files/pulseaudio_12.2-0ubuntu4.1.debdiff -- 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/1834138 Title: PA: Don't restore the streams to sinks/sources with only unavailable ports Status in HWE Next: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Disco: Fix Committed Bug description: SRU Document: [Impact] The Lenovo P520 machine has dual analogue codecs, so there are two sinks and two sources in the PA, one has the front headphone and front microphone, the other has the rear lineout, linein and rear microphone, and the rear microphone always shows up in the gnome- sound-setting, When we plug a microphone to front audio jack, there are two input devices: rear mic and front mic in the gnome-sound- setting, and suppose users select the the front mic to record sound via audio app like arecord, the front mic will be bond the arecord, after the front mic is unplugged, there is only one rear mic left in the gnome-sound-setting, but the binding will not be changed, the arecrod still bind to front mic, under this situation if users record sound via arecord, they will find they can't record any sound from any other input devices even they are listed in the gnome-sound-setting. This problem also happens to output devices too. [Test Case] After applying this patch, I did the same test: unplug the front mic, then use the arecord to record sound, the app can record sound from rear mic now. After I plug the front mic back, the arecord still record from front mic. Also did the similar test for output devices, it worked as expected too. [Regression Potential] No, Just make a simple check when creating new streams (sink_input/source_output), If the restored device (sink/source) has ports and all ports are unavialble, it will not restore the binding, otherwise it will work as before. [Other Info] No more info here To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1834138/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
I read through Bionic's systemd-random-seed.service source (src/random- seed/random-seed.c) and didn't see any references to RNDADDTOENTCNT or RNDADDENTROPY, the ioctl(2)s that are used to indicate to the kernel that added entropy should be used for the random(4) device. Maybe they're hidden behind some abstraction layers, but if so, I didn't spot them. Does anyone know if this is intentional? Or what reasoning might have lead to this decision? 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/1835464 Title: nginx service fails after libssl update due to low entropy at boot Status in nginx package in Ubuntu: Opinion Status in openssl package in Ubuntu: New Status in nginx source package in Bionic: Opinion Status in openssl source package in Bionic: New Bug description: After updating libssl and related packages, nginx will no longer autostart at system boot. Immediately after boot, nginx.service is in a failed state. # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Fri 2018-08-24 21:27:51 UTC; 32min ago Docs: man:nginx(8) systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Start-pre operation timed out. Terminating. systemd[1]: nginx.service: Failed with result 'timeout'. systemd[1]: Failed to start A high performance web server and a reverse proxy server. The service can be manually started after boot. # service nginx start # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-08-24 22:02:06 UTC; 2s ago Docs: man:nginx(8) Process: 2704 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 2703 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 2705 (nginx) CGroup: /system.slice/nginx.service ├─2705 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─2706 nginx: worker process systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument systemd[1]: Started A high performance web server and a reverse proxy server. This happens on an ARMHF based microcontroller running ubuntu 18.04.2 raspi server distribution with a stock kernel.org 4.9-181 kernel. Ubuntu repositories are not accessible from the device, so packages are copied to the device, and apt install is used to upgrade them: apt install --no-install-recommends $dir/updates/system/*.deb | logger 2>&1 The following is a list of packages that, when upgraded, cause the nginx systemd service to fail to autostart at boot. 201,205c201,205 < ii libpython2.7:armhf 2.7.15-4ubuntu4~18.04 armhf Shared Python runtime library (version 2.7) < ii libpython2.7-minimal:armhf 2.7.15-4ubuntu4~18.04 armhf Minimal subset of the Python language (version 2.7) < ii libpython2.7-stdlib:armhf 2.7.15-4ubuntu4~18.04 armhf Interactive high-level object-oriented language (standard library, version 2.7) < ii libpython3.6-minimal:armhf 3.6.8-1~18.04.1 armhf Minimal subset of the Python language (version 3.6) < ii libpython3.6-stdlib:armhf 3.6.8-1~18.04.1 armhf Interactive high-level object-oriented language (standard library, version 3.6) --- > ii libpython2.7:armhf 2.7.15~rc1-1ubuntu0.1 armhf Shared Python runtime library (version 2.7) > ii libpython2.7-minimal:armhf 2.7.15~rc1-1ubuntu0.1 armhf Minimal subset of the Python language (version 2.7) > ii libpython2.7-stdlib:armhf 2.7.15~rc1-1ubuntu0.1 armhf Interactive high-level object-oriented language (standard library, version 2.7) > ii libpython3.6-minimal:armhf 3.6.7-1~18.04 armhf Minimal subset of the Python language (version 3.6) > ii libpython3.6-stdlib:armhf 3.6.7-1~18.04 armhf Interactive high-level object-oriented language (standard library, version 3.6) 225c225 < ii libssl1.1:armhf 1.1.1-1ubuntu2.1~18.04.2 armhf Secure Sockets Layer toolkit - shared libraries --- > ii libssl1.1:armhf 1.1.0g-2ubuntu4.3 armhf
[Touch-packages] [Bug 1834138] Re: PA: Don't restore the streams to sinks/sources with only unavailable ports
Verification done on the Disco, it fixed the problem. On the lenovo P520, I installed the disco (19.04), edit the /etc/apt/sources.list to add disco-proposed repository, then run apt-get update abd sudo apt install pulseaudio, now the pulseaudio is: ii pulseaudio 1:12.2-2ubuntu3.1 amd64PulseAudio sound server ii pulseaudio-utils 1:12.2-2ubuntu3.1 amd64Command line tools for the PulseAudio sound server recording: plug a mic into the front audio jack, and select it from sound-setting, use arecord to record sound, after recording, unplug the front mic and plug it to rear mic, use arecord to record sound again, it still can record sound. playback: plug a headphone to rear lineout and select lineout as output device, then play sound via totem, after a while, close the totem and unplug the rear lineout and plug the headphone to front headphone jack, use totem to play sound, I can hear the sound from front headphone. ** Tags removed: verification-needed-disco ** Tags added: verification-done-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/1834138 Title: PA: Don't restore the streams to sinks/sources with only unavailable ports Status in HWE Next: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Disco: Fix Committed Bug description: SRU Document: [Impact] The Lenovo P520 machine has dual analogue codecs, so there are two sinks and two sources in the PA, one has the front headphone and front microphone, the other has the rear lineout, linein and rear microphone, and the rear microphone always shows up in the gnome- sound-setting, When we plug a microphone to front audio jack, there are two input devices: rear mic and front mic in the gnome-sound- setting, and suppose users select the the front mic to record sound via audio app like arecord, the front mic will be bond the arecord, after the front mic is unplugged, there is only one rear mic left in the gnome-sound-setting, but the binding will not be changed, the arecrod still bind to front mic, under this situation if users record sound via arecord, they will find they can't record any sound from any other input devices even they are listed in the gnome-sound-setting. This problem also happens to output devices too. [Test Case] After applying this patch, I did the same test: unplug the front mic, then use the arecord to record sound, the app can record sound from rear mic now. After I plug the front mic back, the arecord still record from front mic. Also did the similar test for output devices, it worked as expected too. [Regression Potential] No, Just make a simple check when creating new streams (sink_input/source_output), If the restored device (sink/source) has ports and all ports are unavialble, it will not restore the binding, otherwise it will work as before. [Other Info] No more info here To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1834138/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830858] Re: TOCTOU vulnerability in _get_ignore_dom (report.py)
** Information type changed from Private Security to Public Security ** Attachment removed: "PoC.tar.bz2" https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1830858/+attachment/5267305/+files/PoC.tar.bz2 -- 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/1830858 Title: TOCTOU vulnerability in _get_ignore_dom (report.py) Status in Apport: New Status in apport package in Ubuntu: Fix Released Bug description: Dear Ubuntu Security Team, I would like to report a privilege escalation vulnerability in Apport. The vulnerability is a TOCTOU which enables me to trick Apport into reading any file on the system and including it in a crash report file. I have attached a proof-of-concept which triggers the vulnerability. I have tested it on an up-to-date Ubuntu 18.04. Run it as follows: bunzip2 PoC.tar.bz2 tar -xf PoC.tar cd PoC make ./gencrashreport /etc/shadow At this point the following file has been created: /var/crash/_usr_share_apport_apport.0.crash You can use the apport-unpack tool to decompress this file. If you look at the contents of the CoreDump file then you will see that it contains the contents of /etc/shadow (or whichever other file you passed on the command line of gencrashreport). The bug has a couple of mitigations: 1. My PoC does not work if a file named /var/crash/.lock already exists and is owned by root. This file will only exist if Apport has previously generated a crash report. Based on an informal survey of my own 4 computers (yes - maybe I don't need that many), it usually does not exist (unless the computer is used for security research). 2. The generated crash report file, /var/crash/_usr_share_apport_apport.0.crash, is only readable by root and by the whoopsie user. It will be uploaded to daisy.ubuntu.com if you create a file named /var/crash/_usr_share_apport_apport.0.upload, but that is not a huge security concern because it wouldn't be of much benefit to an attacker. However, I have found some integer overflow vulnerabilities in whoopsie (which I will report separately). If those overflows can be exploited to gain code execution in whoopsie, then this will enable an attacker to read the contents of the crash report file. To improve the effectiveness of the first mitigation, I would recommend that you make sure that /var/crash/.lock is created (and owned by root) by the Ubuntu installer and/or whoopsie when it starts up. It does not fix the root cause though, which I will describe next. This is the source location of the TOCTOU vulnerability: https://git.launchpad.net/ubuntu/+source/apport/tree/apport/report.py?h=applied/ubuntu /bionic-devel=2fc8fb446c78e950d643bf49bb7d4a0dc3b05429#n962 Apport allows the user to place a file in their home directory named `~/.apport-ignore.xml`. The call to os.access() on line 962 is intended to check that this file belongs to the correct user. But on line 967, the file is read again using xml.dom.minidom.parse. This creates a window of opportunity for an attacker to replace the file with a symlink. The symlink does not need to point to a valid XML file, because there is a try-except around the call to the parser, so if the file is invalid then Apport just ignores it and continues. However, the contents of the file still ends up in Apport's heap. Here's a summary of how the PoC works: 1. Start a /bin/sleep and kill it with a SIGSEGV. 2. Apport starts up to generate a crash report for /bin/sleep 3. Replace ~/.apport-ignore.xml with a symlink at exactly the right moment, so that Apport loads a forbidden file into memory. 4. Wait until Apport drops privileges so that we can kill it with a SIGTRAP. 5. A second Apport starts up to generate a crash report for the first Apport. 6. The second Apport writes out a crash report for the first, containing a copy of the forbidden file in the core dump. Apport tries quite hard to not run recursively on itself, so I had to jump through a few hoops to make the PoC work: 1. Apport sets a lock on /var/crash/.lock, using lockf. But locks created by lockf are only "advisory". If I own the file, then I can replace it with a different file, thereby deactivating the lock. This is why my PoC only works if /var/crash/.lock doesn't already exist. I need to create it before Apport does, so that I can maintain ownership of it. 2. Apport has signal handlers for most of the core-generating signals, like SIGSEGV. But it doesn't have a handler for SIGTRAP, so that's what my PoC uses. 3. Apport is started with an RLIMIT_CORE value of 1, which is another recursion detection mechanism (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/498525/comments/3). But it is possible for another process to change it to zero, using prlimit. As
[Touch-packages] [Bug 1830863] Re: Integer overflow in parse_report (whoopsie.c:425)
** Attachment removed: "PoC.tar.bz2" https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1830863/+attachment/5267311/+files/PoC.tar.bz2 ** 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 whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1830863 Title: Integer overflow in parse_report (whoopsie.c:425) Status in Whoopsie: New Status in whoopsie package in Ubuntu: Fix Released Bug description: Dear Ubuntu Security Team, I would like to report an integer overflow vulnerability in whoopsie. In combination with issue 1830858, this vulnerability may enable an local attacker to read arbitrary files on the system. I have attached a proof-of-concept which triggers the vulnerability. I have tested it on an up-to-date Ubuntu 18.04. Run it as follows: bunzip2 PoC.tar.bz2 tar -xf PoC.tar cd PoC make ./killwhoopsie1 The PoC works by creating a file named `/var/crash/killwhoopsie.crash`, just over 4GB in size. It then creates a file named `/var/crash/killwhoopsie.upload`, which prompts whoopsie to start processing the .crash file. Be aware that whoopsie will keep restarting and crash repeatedly until you remove the files from /var/crash. This is the source location of the integer overflow bug: http://bazaar.launchpad.net/~daisy- pluckers/whoopsie/trunk/view/698/src/whoopsie.c#L425 The problem is that the type of value_pos is int, but the size of the file can be larger than INT_MAX. My PoC arranges things such that value_pos == -16, leading to an out-of-bounds write on line 440. Please let me know when you have fixed the vulnerability, so that I can coordinate my disclosure with yours. For reference, here is a link to Semmle's vulnerability disclosure policy: https://lgtm.com/security#disclosure_policy Thank you, Kevin Backhouse Semmle Security Research Team To manage notifications about this bug go to: https://bugs.launchpad.net/whoopsie/+bug/1830863/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1473011] Re: [PATCH] Skip network checks on always dispatchable accounts
** Changed in: mission-control-5 Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to telepathy-mission- control-5 in Ubuntu. https://bugs.launchpad.net/bugs/1473011 Title: [PATCH] Skip network checks on always dispatchable accounts Status in Telepathy Mission Control 5: Fix Released Status in telepathy-mission-control-5 package in Ubuntu: Fix Released Bug description: MissionControl does not seem to connect accounts that have always_dispatch=true attribute set; that attribute is meant to serve as "skip network connection checks when connecting"-kind of thing. After some investigation, I've found a possible bug and created a patch. I've posted this patch to upstream [1] but the general activity in the project has declined and so it might take quite some time before it's reviewed and put into a release. Therefore I was advised to file a bug report here for a chance for this patch to be included as a distro patch. This would also help fix this issue in ubuntu-phone, where it is currently being workarounded[2]. The patch itself is located at [1] so I'm not going to reupload it here. Cheers, Martin [1] - https://bugs.freedesktop.org/show_bug.cgi?id=91272 [2] - http://bazaar.launchpad.net/~phablet-team/telephony-service/trunk/view/head:/tools/ofono-setup#L39 To manage notifications about this bug go to: https://bugs.launchpad.net/mission-control-5/+bug/1473011/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1473011]
Applied to the 5.16 branch, thanks! https://cgit.freedesktop.org/telepathy/telepathy-mission- control/commit/?h=telepathy-mission- control-5.16=31268fec582776593e54c10c862d9f7af7b3153c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to telepathy-mission- control-5 in Ubuntu. https://bugs.launchpad.net/bugs/1473011 Title: [PATCH] Skip network checks on always dispatchable accounts Status in Telepathy Mission Control 5: Fix Released Status in telepathy-mission-control-5 package in Ubuntu: Fix Released Bug description: MissionControl does not seem to connect accounts that have always_dispatch=true attribute set; that attribute is meant to serve as "skip network connection checks when connecting"-kind of thing. After some investigation, I've found a possible bug and created a patch. I've posted this patch to upstream [1] but the general activity in the project has declined and so it might take quite some time before it's reviewed and put into a release. Therefore I was advised to file a bug report here for a chance for this patch to be included as a distro patch. This would also help fix this issue in ubuntu-phone, where it is currently being workarounded[2]. The patch itself is located at [1] so I'm not going to reupload it here. Cheers, Martin [1] - https://bugs.freedesktop.org/show_bug.cgi?id=91272 [2] - http://bazaar.launchpad.net/~phablet-team/telephony-service/trunk/view/head:/tools/ofono-setup#L39 To manage notifications about this bug go to: https://bugs.launchpad.net/mission-control-5/+bug/1473011/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
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/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: Confirmed Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1827842] Re: pulseaudio should not load module-x11-bell in gnome-shell
Hello Pierre-Antoine, or anyone else affected, Accepted pulseaudio into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pulseaudio/1:12.2-2ubuntu3.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-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: pulseaudio (Ubuntu Disco) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1827842 Title: pulseaudio should not load module-x11-bell in gnome-shell Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Disco: Fix Committed Bug description: * Impact The package force load a bell sound which can conflicts with the user configuration * Test case - Enable a login sound in session - Login into a GNOME/Ubuntu session -> the configured sound should be played * Regression potential Try other desktop environments to make sure their login sound behaviour isn't changed, it shouldn't since the customization dropped was specific to the Ubuntu sound theme --- The package `pulseaudio` installs a startup script in `/etc/xdg/autostart/pulseaudio.desktop`, which itself runs `/usr/bin/start-pulseaudio-x11`, which loads a number of x11 related modules in `pulseaudio`. One of these modules is `module-x11-bell`, which makes `pulseaudio` play a sound each time a system bell is emitted (usually by terminal applications, such as bash or vim). This is redundant with gnome-shell, which is also able to handle the system bell (through the gsetting key `org.gnome.desktop.sound event-sounds`). The gnome system bell is directly configurable by the user (Settings > Sound), so it should be preferred over pulseaudio's own system bell. I suggest to patch the `/usr/bin/start-pulseaudio-x11`, to avoid loading `start-pulseaudio-x11` if it detects it is running in Gnome Shell (e.g. if GNOME_SHELL_SESSION_MODE is set). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1827842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1834138] Re: PA: Don't restore the streams to sinks/sources with only unavailable ports
Hello Hui, or anyone else affected, Accepted pulseaudio into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pulseaudio/1:12.2-2ubuntu3.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-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: pulseaudio (Ubuntu Disco) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1834138 Title: PA: Don't restore the streams to sinks/sources with only unavailable ports Status in HWE Next: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Disco: Fix Committed Bug description: SRU Document: [Impact] The Lenovo P520 machine has dual analogue codecs, so there are two sinks and two sources in the PA, one has the front headphone and front microphone, the other has the rear lineout, linein and rear microphone, and the rear microphone always shows up in the gnome- sound-setting, When we plug a microphone to front audio jack, there are two input devices: rear mic and front mic in the gnome-sound- setting, and suppose users select the the front mic to record sound via audio app like arecord, the front mic will be bond the arecord, after the front mic is unplugged, there is only one rear mic left in the gnome-sound-setting, but the binding will not be changed, the arecrod still bind to front mic, under this situation if users record sound via arecord, they will find they can't record any sound from any other input devices even they are listed in the gnome-sound-setting. This problem also happens to output devices too. [Test Case] After applying this patch, I did the same test: unplug the front mic, then use the arecord to record sound, the app can record sound from rear mic now. After I plug the front mic back, the arecord still record from front mic. Also did the similar test for output devices, it worked as expected too. [Regression Potential] No, Just make a simple check when creating new streams (sink_input/source_output), If the restored device (sink/source) has ports and all ports are unavialble, it will not restore the binding, otherwise it will work as before. [Other Info] No more info here To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1834138/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1795959] Re: [FFe] Seed xdg-desktop-portal-gtk
** Description changed: - Security and MIR reviews have been completed for xdg-desktop-portal- - gtk[1] and xdg-desktop-portal[2]. + [Impact] + * These packages can improve desktop integration of snap packages. The risk is low as nothing in the default desktop install actually exercises the portals at this time. We need to seed the portals so they are available when snaps are installed that can utilize them. Flatpak packages will also benefit. - These packages can improve desktop integration of snap packages. The - risk is low as nothing in the default desktop install actually exercises - the portals at this time. We need to seed the portals so they are - available when snaps are installed that can utilize them. Flatpak - packages will also benefit. + [Test Case] + * This can be tested by using the portal-test snap + + [Regression potential] + * Nothing in the default install utilizes it, so there should be no risk. + + [Other Info] + * Security and MIR reviews have been completed for xdg-desktop-portal-gtk[1] and xdg-desktop-portal[2]. 1. https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal-gtk/+bug/1750069 2. https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1749672 ** Also affects: ubuntu-meta (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: ubuntu-meta (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: ubuntu-meta (Ubuntu Xenial) Assignee: (unassigned) => Ken VanDine (ken-vandine) ** Changed in: ubuntu-meta (Ubuntu Bionic) Assignee: (unassigned) => Ken VanDine (ken-vandine) ** Changed in: ubuntu-meta (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: ubuntu-meta (Ubuntu Bionic) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1795959 Title: [FFe] Seed xdg-desktop-portal-gtk Status in ubuntu-meta package in Ubuntu: Fix Released Status in ubuntu-meta source package in Xenial: New Status in ubuntu-meta source package in Bionic: New Bug description: [Impact] * These packages can improve desktop integration of snap packages. The risk is low as nothing in the default desktop install actually exercises the portals at this time. We need to seed the portals so they are available when snaps are installed that can utilize them. Flatpak packages will also benefit. [Test Case] * This can be tested by using the portal-test snap [Regression potential] * Nothing in the default install utilizes it, so there should be no risk. [Other Info] * Security and MIR reviews have been completed for xdg-desktop-portal-gtk[1] and xdg-desktop-portal[2]. 1. https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal-gtk/+bug/1750069 2. https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1749672 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1795959/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
FWIW, I think not booting a 19.04 ISO is probably fine, and it's not worth spinning a point release for this. "I can't install a 9mo release on this hardware" is unforunate, but not world-ending. However, we should definitely SRU this for people who are likely to take their EXISTING 19.04 system with a Ryzen 1xxx/2xxx and drop in a 3xxx and find it doesn't boot anymore. Also, obviously, we should make sure it's fixed for 19.10. -- 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/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835711] Re: Ubuntu-bug collects bug data but does not upload it
I wonder if this is the same issue as in bug 1814611 where the reporter had to "enable the error reporting switch in system settings/privacy protection". Do you have error reporting disabled? Thanks in advance. ** Project changed: apport => apport (Ubuntu) -- 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/1835711 Title: Ubuntu-bug collects bug data but does not upload it Status in apport package in Ubuntu: New Bug description: I'm trying to report some bugs from a stable release, 18.04. I enabled apport reporting as suggested here:https://help.ubuntu.com/community/ReportingBugs#Reporting_a_crash_in_the_stable_release and also here: https://www.linuxbabe.com/ubuntu/disable-apport-error- reporting-ubuntu-16-04-lts I also have whoopsie package installed. When I try to report a bug using `ubuntu-bug $package_name` it seem to be collecting data, but then it doesn't send them to launchpad. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1835711/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1829968] Re: motd [on at least some instances] does not auto-update daily
** Changed in: base-files (Ubuntu Disco) Status: New => In Progress ** Changed in: base-files (Ubuntu Disco) Assignee: (unassigned) => Brian Murray (brian-murray) ** Changed in: base-files (Ubuntu Cosmic) Status: New => In Progress ** Changed in: base-files (Ubuntu Cosmic) Assignee: (unassigned) => Brian Murray (brian-murray) ** Changed in: base-files (Ubuntu Bionic) Status: Triaged => In Progress ** Changed in: base-files (Ubuntu Bionic) 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 base-files in Ubuntu. https://bugs.launchpad.net/bugs/1829968 Title: motd [on at least some instances] does not auto-update daily Status in base-files package in Ubuntu: Fix Released Status in base-files source package in Bionic: In Progress Status in base-files source package in Cosmic: In Progress Status in base-files source package in Disco: In Progress Status in base-files source package in Eoan: Fix Released Bug description: [Impact] motd-news timer is not properly configured and may not run regularly so long running systems will not get an updated motd [Test Case] The motd-news.timer is known to be incorrectly configured because motd-news.services is a one shot service which will not become active. Subsequently, have a timer with OnUnitActiveSec is wrong and the timer will not work reliably. However, because it can work some of the time it is difficult to find a case where the timer always fails so test case will involve only confirming that the new timer is correct. 1) On a system with curl installed, install the new version of base-files 2) Run 'systemctl list-timers motd* --all 3) Confirm that "LEFT" is less than 12 hours (Its less than 24 hours because we don't want people to miss important messages) 4) Wait until "NEXT" is reached 5) Confirm that there is another "NEXT" and that the time stamp of /var/cache/motd-news was updated [Regression Potential] I can't think of any on the client side as the job wasn't working as it was intended but it may cause extra load on the motd server. Original Description I have a VM running on AWS. It was launched on May 9th: $ uptime 05:26:21 up 12 days, 6:34, 1 user, load average: 0.00, 0.00, 0.00 $ date Wed May 22 05:26:24 UTC 2019 I touched none of the system defaults, and yet the motd has not updated automatically. $ ls -l /var/cache/motd-news -rw-r--r-- 1 root root 0 May 9 22:53 /var/cache/motd-news The systemd timer unit looks like this: $ systemctl status motd-news.timer ● motd-news.timer - Message of the Day Loaded: loaded (/lib/systemd/system/motd-news.timer; enabled; vendor preset: enabled) Active: active (elapsed) since Thu 2019-05-09 22:51:58 UTC; 1 weeks 5 days ago Trigger: n/a May 09 22:51:58 ip-172-31-23-224 systemd[1]: Started Message of the Day. If I run /etc/update-motd.d/50-motd-news --force manually, the file does update correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1829968/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835711] [NEW] Ubuntu-bug collects bug data but does not upload it
You have been subscribed to a public bug: I'm trying to report some bugs from a stable release, 18.04. I enabled apport reporting as suggested here:https://help.ubuntu.com/community/ReportingBugs#Reporting_a_crash_in_the_stable_release and also here: https://www.linuxbabe.com/ubuntu/disable-apport-error- reporting-ubuntu-16-04-lts I also have whoopsie package installed. When I try to report a bug using `ubuntu-bug $package_name` it seem to be collecting data, but then it doesn't send them to launchpad. ** Affects: apport (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 bionic ubuntu -- Ubuntu-bug collects bug data but does not upload it https://bugs.launchpad.net/bugs/1835711 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport 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 1668771] Re: systemd-resolved negative caching for extended period of time
** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Jorge Niedbalski (niedbalski) -- 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/1668771 Title: systemd-resolved negative caching for extended period of time Status in systemd: New Status in systemd package in Ubuntu: Confirmed Bug description: 231-9ubuntu3 If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the result for very long (infinity?). I have to restart systemd-resolved to have the negative caching purged. After SERVFAIL DNS server issue has been resolved, chromium/firefox still returns DNS error despite host can correctly resolve the name. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1668771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
Sebastien, thanks for getting eyes on it! Éric, these systems will not boot the 19.04 ISO without either new firmware fixing the rdrand instruction, or a new ISO updating systemd with this patch. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
Good findings! Thank you so much for testing the rdrand theory. I guess a read fix would require a new ISO, which could easily be made as a dot release (19.04.1). Regards, Eric -- 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/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832919] Re: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10
** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1832919 Title: installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10 Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: Fix Committed Status in openssl source package in Cosmic: Fix Committed Status in openssl source package in Disco: Fix Committed Status in openssl source package in Eoan: Fix Released Bug description: [Impact] * Systems that have in error removed debconf database fail to upgrade libssl1.1 (as e.g. is known to be done in some vagrant boxes) * libssl1.1 tries to use debconf template from libc6 package, but doesn't ship one by itself as it should for shared templates. As it is not guaranteed that template will be available. [TestCase] # DO NOT DO THIS ON PRODUCTION MACHINES # # echo PURGE | debconf-communicate libpam0g:amd64 0 # echo PURGE | debconf-communicate libpam0g 0 # echo PURGE | debconf-communicate libc6:amd64 0 # echo PURGE | debconf-communicate libc6 0 Then upgrade from bionic-release to the -proposed package and it should work. It should not fail with exit code 10. [Regression Potential] * A new template is added, an identical import from glibc without any further changes. This registers the template in debconf, for this package, preventing the above describe error. This has no codechanges, only metadata. [Other Info] * Original bug report The error happens when trying to configure libssl1.1:amd64 (dpkg --configure -D 2 libssl1.1) dpkg: error processing package libssl1.1:amd64 (--configure): installed libssl1.1:amd64 package post-installation script subprocess returned error exit status 10 D02: post_script_tasks - ensure_diversions D02: post_script_tasks - trig_incorporate D02: check_triggers_cycle pnow=libc-bin:amd64 first Processing triggers for libc-bin (2.27-3ubuntu1) ... D02: post_postinst_tasks - trig_incorporate Errors were encountered while processing: libssl1.1:amd64 [ WORKAROUND TO RECOVER YOUR SYSTEM ] $ sudo dpkg-reconfigure libc6 $ sudo dpkg --configure libssl1.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832919/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
Thanks for your bug report & patch! I'm subscribing ubuntu-sponsors which is what is needed for the bug to get on the sponsoring queue (http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html) I'm also tagging the bug rls-dd-incoming and rls-ee-incoming so it gets on the list of targetted to review which should help visibility ** Changed in: systemd (Ubuntu) Importance: Undecided => High ** Tags added: rls-dd-incoming rls-ee-incoming -- 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/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835213] Re: CVE-2019-13132
Thanks Luca for all the help and contribution, the fix is released. Feel free to contact us in case of new issues. ** Changed in: zeromq3 (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 zeromq3 in Ubuntu. https://bugs.launchpad.net/bugs/1835213 Title: CVE-2019-13132 Status in zeromq3 package in Ubuntu: Fix Released Bug description: Dear Security Team, I am the upstream maintainer of libzmq/zeromq - https://github.com/zeromq/libzmq CVE-2019-13132 has been reported privately, and I have confirmed it is not only valid but quite bad (TM). The bug allows any unauthenticated client to cause a stack overflow on any server that is supposed to be protected by encryption/authentication. Arbitrary data sent by the client will overwrite the stack, so although the reporter didn't provide a specific exploit, it is entirely possible that a crafty attacker could take advantage of this vulnerability to do more than "just" crash the server. The bug affects all libzmq/zeromq releases from 4.0.0 onward. Any server running with CURVE encryption/authentication is vulnerable. Due to the severity, I have not yet published the details on the CVE or the issue tracker, and would like to do a release before it is disclosed, to let the fix percolate in all distros. The proposed plan is as follows: I will release upstream versions 4.3.2, 4.1.7 and 4.0.9 on Monday the 8th of July at 16:00 UTC. I would kindly ask to hold on publishing the security updates with the attached patches until the above time or later, as your schedule permits, if possible. The CVE details and the upstream issue tracker will then be published a week later, on the 15th. The per-version patches cover the following distro releases: xenial 4.1.4 bionic 4.2.5 cosmic 4.2.5 disco 4.3.1 Thank you for your help! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zeromq3/+bug/1835213/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835135] Re: FIPS OpenSSL crashes Python2 hashlib
Upon looking at the source for both python2.7 and python3.5 in xenial, neither checks the return value from EVP_DigestInit in Modules/_hashopenssl.c file. However, python3.6 (in bionic, cosmic and disco) does have the check. So the check will need to be backported to python 2.7 and python 3.5 in xenial. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1835135 Title: FIPS OpenSSL crashes Python2 hashlib Status in python2.7 package in Ubuntu: Triaged Bug description: If Ubuntu/Canonical's FIPS-compliant OpenSSL is initialized with SSL_library_init, then Python2's hashlib bindings for MD5 can trigger a SIGSEGV via a NULL pointer dereference (if calling the .update method) or a SIGABRT (if passing input to the constructor or passing no input and invoking the .final method). This happens if, for example, PyOpenSSL is imported before hashlib. Canonical's FIPS patches for OpenSSL introduce some odd behavior that arguably should be revisited, but the (TL;DR) core bug is that Python2 hashlib doesn't properly check the return value of EVP_DigestInit, preventing hashlib from falling back to it's internal MD5 implementation and instead setting things up for use of the MD5 context to trigger SIGSEGV or SIGABRT. Python3 correctly checks the return value, so the fix is to backport the relevant code into Python2 (see python2.7-2.7.12/Modules/_hashopenssl.c). See attached good.py and bad.py files which exhibit the import order- dependent crashing issue. See attached fips-md5-python-init-bug.c which shows the FIPS OpenSSL behaviors that conditionally tickle the Python2 bug. The C file also contains a much more detailed description of the Python2 bug and other behavior which I'd rather not repeat here. I discovered this bug investigating an issue with the third-party apt- boto-s3 package. See https://github.com/boto/boto3/issues/2021 Note that this bug effects Splunk, Inc, which has a corporate Ubuntu Advantage license. My login account is attached to a different, single-seat license. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1835135/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1794997] Re: virNetlinkEventCallback:700 : nl_recv returned with error: No buffer space available
We have not seen this bug in the recent time. So, this bug can be closed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1794997 Title: virNetlinkEventCallback:700 : nl_recv returned with error: No buffer space available Status in libnl3 package in Ubuntu: Expired Status in libvirt package in Ubuntu: Expired Bug description: We are observing the following error while creating VMs Sep 27 14:25:47 xpl-dvt-41 libvirtd[4927]: 2018-09-27 21:25:47.387+: 4927: error : virNetlinkEventCallback:700 : nl_recv returned with error: No buffer space available This message is observed with latest Bionic libvirt packages. lab@xpl-dvt-35:~$ dpkg -l | grep libvirt ii gir1.2-libvirt-glib-1.0:amd64 1.0.0-1 amd64GObject introspection files for the libvirt-glib library ii libsys-virt-perl 4.0.0-1 amd64Perl module providing an extension for the libvirt library ii libvirt-bin 4.0.0-1ubuntu8.5 amd64programs for the libvirt library ii libvirt-clients 4.0.0-1ubuntu8.5 amd64Programs for the libvirt library ii libvirt-daemon4.0.0-1ubuntu8.5 amd64Virtualization daemon ii libvirt-daemon-system 4.0.0-1ubuntu8.5 amd64Libvirt daemon configuration files ii libvirt-glib-1.0-0:amd64 1.0.0-1 amd64libvirt GLib and GObject mapping library ii libvirt0:amd644.0.0-1ubuntu8.5 amd64library for interfacing with different virtualization systems ii python-libvirt4.0.0-1 amd64libvirt Python bindings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1794997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1801540]
Anders, looks like those two files are exactly the same? I think the Linux file didn't get uploaded. -- 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/1801540 Title: Microphone distorted sound on ALC892/1220 on AMD chipsets Status in Linux: Confirmed Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: Confirmed Bug description: Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec. Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch. alsa-info on the attachments To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1801540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1801540]
Created attachment 283579 linuxdecoded -- 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/1801540 Title: Microphone distorted sound on ALC892/1220 on AMD chipsets Status in Linux: Confirmed Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: Confirmed Bug description: Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec. Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch. alsa-info on the attachments To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1801540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1801540]
better now? -- 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/1801540 Title: Microphone distorted sound on ALC892/1220 on AMD chipsets Status in Linux: Confirmed Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: Confirmed Bug description: Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec. Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch. alsa-info on the attachments To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1801540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1801540]
Created attachment 283581 windecoded -- 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/1801540 Title: Microphone distorted sound on ALC892/1220 on AMD chipsets Status in Linux: Confirmed Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: Confirmed Bug description: Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec. Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch. alsa-info on the attachments To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1801540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1801540]
Created attachment 283577 winn pci data translated -- 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/1801540 Title: Microphone distorted sound on ALC892/1220 on AMD chipsets Status in Linux: Confirmed Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: Confirmed Bug description: Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec. Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch. alsa-info on the attachments To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1801540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1801540]
Created attachment 283575 linux pci data translated -- 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/1801540 Title: Microphone distorted sound on ALC892/1220 on AMD chipsets Status in Linux: Confirmed Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: Confirmed Bug description: Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec. Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch. alsa-info on the attachments To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1801540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
I have tested the patch posted, and it produces a bootable system with 19.04. We will be releasing the patched version of systemd in the following PPAs: Pop!_OS - https://launchpad.net/~system76/+archive/ubuntu/pop Ubuntu support for System76 computers - https://launchpad.net/~system76-dev/+archive/ubuntu/stable Please let me know what needs to happen to get this patch into Ubuntu 19.04 -- 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/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
@racb I'm not sure that I would consider it normal or expected, though, for system services to suddenly stop working due to regular updates, and for a server to suddenly become unreachable and unresponsive just because it was updated. On the other hand, it's certainly not desirable for a system to silently operate with poor entropy and poor encryption quality. In my case, this is easily resolved due to the hardware RNG on the TI AM335X chip. However, AFAIK a Raspberry PI does not have a hardware RNG, nor do many embedded processors / systems - meaning they would have low entropy at boot, and rng-tools most likely won't help. Without looking at any code, here are a few observations. Does nginx really need to make this blocking call to openssl when the service starts? or only when the first https request is made to the service? That is, if no https request comes in for 2 min, or 10 min, maybe there would be sufficient entropy by then due to system activity. Does openssl really need to block on initialization until sufficient entropy exists? Or could it defer that until some subsequent call that does actually need adequate entropy? In other words, would moving this blocking behavior to a different function satisfy the security need that led to its implementation, without potentially blocking systemd services at boot time? Finally, I have a couple of the same devices that do not exhibit this blocking behavior. I'm not sure exactly why, but the difference appears somehow related to the way updates are applied. I've noticed a file '/.rnd' (from memory) which is used and/or generated by openssl. Looks like this file is used as an entropy seed. Once deleted (and the hardware RNG is not used), the nginx systemd service will start blocking and timing out. Attempts to create this file manually using openssl do not allow the nginx service to start successfully at boot. Maybe the simple fix is to find the right way to create and manage the /.rnd file on devices with low entropy? -- 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/1835464 Title: nginx service fails after libssl update due to low entropy at boot Status in nginx package in Ubuntu: Opinion Status in openssl package in Ubuntu: New Status in nginx source package in Bionic: Opinion Status in openssl source package in Bionic: New Bug description: After updating libssl and related packages, nginx will no longer autostart at system boot. Immediately after boot, nginx.service is in a failed state. # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Fri 2018-08-24 21:27:51 UTC; 32min ago Docs: man:nginx(8) systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Start-pre operation timed out. Terminating. systemd[1]: nginx.service: Failed with result 'timeout'. systemd[1]: Failed to start A high performance web server and a reverse proxy server. The service can be manually started after boot. # service nginx start # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-08-24 22:02:06 UTC; 2s ago Docs: man:nginx(8) Process: 2704 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 2703 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 2705 (nginx) CGroup: /system.slice/nginx.service ├─2705 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─2706 nginx: worker process systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument systemd[1]: Started A high performance web server and a reverse proxy server. This happens on an ARMHF based microcontroller running ubuntu 18.04.2 raspi server distribution with a stock kernel.org 4.9-181 kernel. Ubuntu repositories are not accessible from the device, so packages are copied to the device, and apt install is used to upgrade them: apt install --no-install-recommends $dir/updates/system/*.deb | logger 2>&1 The following is a list of packages that, when upgraded, cause the nginx systemd service to fail to autostart at boot. 201,205c201,205 < ii libpython2.7:armhf 2.7.15-4ubuntu4~18.04 armhf Shared Python runtime library (version 2.7) < ii libpython2.7-minimal:armhf
[Touch-packages] [Bug 1829968] Re: motd [on at least some instances] does not auto-update daily
** Description changed: [Impact] motd-news timer is not properly configured and may not run regularly so long running systems will not get an updated motd [Test Case] - The system being tested must have curl installed - base-files does not depend on it because reasons. - 1) Run 'systemctl status mot-news.timer' - 2) Observe that the Trigger section is n/a + The motd-news.timer is known to be incorrectly configured because motd-news.services is a one shot service which will not become active. Subsequently, have a timer with OnUnitActiveSec is wrong and the timer will not work reliably. However, because it can work some of the time it is difficult to find a case where the timer always fails so test case will involve only confirming that the new timer is correct. - With the version of the package from -proposed the Trigger section - should instead contain something like the following: - - Trigger: Mon 2019-06-17 11:42:25 PDT; 20min left - - One should also wait to ensure that the trigger actually ran and that - /var/cache/motd-news has been updated. + 1) On a system with curl installed, install the new version of base-files + 2) Run 'systemctl list-timers motd* --all + 3) Confirm that "LEFT" is less than 12 hours (Its less than 24 hours because we don't want people to miss important messages) + 4) Wait until "NEXT" is reached + 5) Confirm that there is another "NEXT" and that the time stamp of /var/cache/motd-news was updated [Regression Potential] - I can't think of any on the client side as the job wasn't working at all but it may cause extra load on the motd server. - + I can't think of any on the client side as the job wasn't working as it was intended but it may cause extra load on the motd server. Original Description I have a VM running on AWS. It was launched on May 9th: $ uptime 05:26:21 up 12 days, 6:34, 1 user, load average: 0.00, 0.00, 0.00 $ date Wed May 22 05:26:24 UTC 2019 I touched none of the system defaults, and yet the motd has not updated automatically. $ ls -l /var/cache/motd-news -rw-r--r-- 1 root root 0 May 9 22:53 /var/cache/motd-news The systemd timer unit looks like this: $ systemctl status motd-news.timer ● motd-news.timer - Message of the Day Loaded: loaded (/lib/systemd/system/motd-news.timer; enabled; vendor preset: enabled) Active: active (elapsed) since Thu 2019-05-09 22:51:58 UTC; 1 weeks 5 days ago Trigger: n/a May 09 22:51:58 ip-172-31-23-224 systemd[1]: Started Message of the Day. If I run /etc/update-motd.d/50-motd-news --force manually, the file does update correctly. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/1829968 Title: motd [on at least some instances] does not auto-update daily Status in base-files package in Ubuntu: Fix Released Status in base-files source package in Bionic: Triaged Status in base-files source package in Cosmic: New Status in base-files source package in Disco: New Status in base-files source package in Eoan: Fix Released Bug description: [Impact] motd-news timer is not properly configured and may not run regularly so long running systems will not get an updated motd [Test Case] The motd-news.timer is known to be incorrectly configured because motd-news.services is a one shot service which will not become active. Subsequently, have a timer with OnUnitActiveSec is wrong and the timer will not work reliably. However, because it can work some of the time it is difficult to find a case where the timer always fails so test case will involve only confirming that the new timer is correct. 1) On a system with curl installed, install the new version of base-files 2) Run 'systemctl list-timers motd* --all 3) Confirm that "LEFT" is less than 12 hours (Its less than 24 hours because we don't want people to miss important messages) 4) Wait until "NEXT" is reached 5) Confirm that there is another "NEXT" and that the time stamp of /var/cache/motd-news was updated [Regression Potential] I can't think of any on the client side as the job wasn't working as it was intended but it may cause extra load on the motd server. Original Description I have a VM running on AWS. It was launched on May 9th: $ uptime 05:26:21 up 12 days, 6:34, 1 user, load average: 0.00, 0.00, 0.00 $ date Wed May 22 05:26:24 UTC 2019 I touched none of the system defaults, and yet the motd has not updated automatically. $ ls -l /var/cache/motd-news -rw-r--r-- 1 root root 0 May 9 22:53 /var/cache/motd-news The systemd timer unit looks like this: $ systemctl status motd-news.timer ● motd-news.timer - Message of the Day Loaded: loaded (/lib/systemd/system/motd-news.timer; enabled;
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
A systemd package with this patch applied is building here: - amd64 - https://launchpad.net/~system76/+archive/ubuntu/proposed/+build/17236776 - i386 - https://launchpad.net/~system76/+archive/ubuntu/proposed/+build/17236777 -- 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/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1650634] Re: when installing systemd, it creates /run/nologin preventing all users from logging in.
Deploy Ubuntu Bionic machine from AWS, try and log in: "System is booting up. See pam_nologin(8)" Given it is impossible to log in, it's impossible to see what's wrong, or fix it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1650634 Title: when installing systemd, it creates /run/nologin preventing all users from logging in. Status in systemd: New Status in systemd package in Ubuntu: Confirmed Status in systemd package in Suse: Unknown Bug description: How to replicate: sudo apt-get install systemd wait for 5 minutes check to see if /run/nologin appears. If it does the bug is present. See https://ubuntuforums.org/showthread.php?t=2327330 I ran this command via ansible on all of my servers. Then I could no longer log into any of them. Pretty big bug in my opinion. Please fix. -Tim ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: systemd 204-5ubuntu20.20 ProcVersionSignature: Ubuntu 3.13.0-105.152-generic 3.13.11-ckt39 Uname: Linux 3.13.0-105-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.23 Architecture: amd64 CurrentDesktop: KDE Date: Fri Dec 16 12:03:55 2016 InstallationDate: Installed on 2014-04-21 (970 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1650634/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
The attachment "Rebase of https://github.com/systemd/systemd/pull/12536; seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835213] Re: CVE-2019-13132
Hello, I have made the report public. The issue has been posted to oss- security, and the upstream releases are in progress and will be available in a few minutes. ** 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 zeromq3 in Ubuntu. https://bugs.launchpad.net/bugs/1835213 Title: CVE-2019-13132 Status in zeromq3 package in Ubuntu: In Progress Bug description: Dear Security Team, I am the upstream maintainer of libzmq/zeromq - https://github.com/zeromq/libzmq CVE-2019-13132 has been reported privately, and I have confirmed it is not only valid but quite bad (TM). The bug allows any unauthenticated client to cause a stack overflow on any server that is supposed to be protected by encryption/authentication. Arbitrary data sent by the client will overwrite the stack, so although the reporter didn't provide a specific exploit, it is entirely possible that a crafty attacker could take advantage of this vulnerability to do more than "just" crash the server. The bug affects all libzmq/zeromq releases from 4.0.0 onward. Any server running with CURVE encryption/authentication is vulnerable. Due to the severity, I have not yet published the details on the CVE or the issue tracker, and would like to do a release before it is disclosed, to let the fix percolate in all distros. The proposed plan is as follows: I will release upstream versions 4.3.2, 4.1.7 and 4.0.9 on Monday the 8th of July at 16:00 UTC. I would kindly ask to hold on publishing the security updates with the attached patches until the above time or later, as your schedule permits, if possible. The CVE details and the upstream issue tracker will then be published a week later, on the 15th. The per-version patches cover the following distro releases: xenial 4.1.4 bionic 4.2.5 cosmic 4.2.5 disco 4.3.1 Thank you for your help! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zeromq3/+bug/1835213/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
** Changed in: nginx (Ubuntu) Status: Incomplete => Opinion ** Changed in: nginx (Ubuntu Bionic) Status: Incomplete => Opinion -- 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/1835464 Title: nginx service fails after libssl update due to low entropy at boot Status in nginx package in Ubuntu: Opinion Status in openssl package in Ubuntu: New Status in nginx source package in Bionic: Opinion Status in openssl source package in Bionic: New Bug description: After updating libssl and related packages, nginx will no longer autostart at system boot. Immediately after boot, nginx.service is in a failed state. # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Fri 2018-08-24 21:27:51 UTC; 32min ago Docs: man:nginx(8) systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Start-pre operation timed out. Terminating. systemd[1]: nginx.service: Failed with result 'timeout'. systemd[1]: Failed to start A high performance web server and a reverse proxy server. The service can be manually started after boot. # service nginx start # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-08-24 22:02:06 UTC; 2s ago Docs: man:nginx(8) Process: 2704 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 2703 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 2705 (nginx) CGroup: /system.slice/nginx.service ├─2705 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─2706 nginx: worker process systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument systemd[1]: Started A high performance web server and a reverse proxy server. This happens on an ARMHF based microcontroller running ubuntu 18.04.2 raspi server distribution with a stock kernel.org 4.9-181 kernel. Ubuntu repositories are not accessible from the device, so packages are copied to the device, and apt install is used to upgrade them: apt install --no-install-recommends $dir/updates/system/*.deb | logger 2>&1 The following is a list of packages that, when upgraded, cause the nginx systemd service to fail to autostart at boot. 201,205c201,205 < ii libpython2.7:armhf 2.7.15-4ubuntu4~18.04 armhf Shared Python runtime library (version 2.7) < ii libpython2.7-minimal:armhf 2.7.15-4ubuntu4~18.04 armhf Minimal subset of the Python language (version 2.7) < ii libpython2.7-stdlib:armhf 2.7.15-4ubuntu4~18.04 armhf Interactive high-level object-oriented language (standard library, version 2.7) < ii libpython3.6-minimal:armhf 3.6.8-1~18.04.1 armhf Minimal subset of the Python language (version 3.6) < ii libpython3.6-stdlib:armhf 3.6.8-1~18.04.1 armhf Interactive high-level object-oriented language (standard library, version 3.6) --- > ii libpython2.7:armhf 2.7.15~rc1-1ubuntu0.1 armhf Shared Python runtime library (version 2.7) > ii libpython2.7-minimal:armhf 2.7.15~rc1-1ubuntu0.1 armhf Minimal subset of the Python language (version 2.7) > ii libpython2.7-stdlib:armhf 2.7.15~rc1-1ubuntu0.1 armhf Interactive high-level object-oriented language (standard library, version 2.7) > ii libpython3.6-minimal:armhf 3.6.7-1~18.04 armhf Minimal subset of the Python language (version 3.6) > ii libpython3.6-stdlib:armhf 3.6.7-1~18.04 armhf Interactive high-level object-oriented language (standard library, version 3.6) 225c225 < ii libssl1.1:armhf 1.1.1-1ubuntu2.1~18.04.2 armhf Secure Sockets Layer toolkit - shared libraries --- > ii libssl1.1:armhf 1.1.0g-2ubuntu4.3 armhf Secure Sockets Layer toolkit - shared libraries 272c272 < ii openssl 1.1.1-1ubuntu2.1~18.04.2 armhf Secure Sockets Layer toolkit - cryptographic utility --- > ii openssl 1.1.0g-2ubuntu4.3 armhf Secure Sockets
[Touch-packages] [Bug 1835809] [NEW] AMD Ryzen 3000 series fails to boot
Public bug reported: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: patch ** Patch added: "Rebase of https://github.com/systemd/systemd/pull/12536; https://bugs.launchpad.net/bugs/1835809/+attachment/5275667/+files/rdrand-workaround-on-amd.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: New Bug description: On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
I think understand the problem here, but it isn't clear to me that it's a bug in the openssl update either. It is surely normal and expected that regular updates (including security updates) might result in a greater entropy requirement. It would be nice if we could arrange things to block for longer without failing when blocked on entropy. I'm not sure that increasing timeouts is really going to help though, if the system fundamentally doesn't have a good entropy source. So it isn't obvious to me where this needs to be fixed, if anywhere at all but the sysadmin in providing the system with no entropy. Further discussion welcome. -- 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/1835464 Title: nginx service fails after libssl update due to low entropy at boot Status in nginx package in Ubuntu: Incomplete Status in openssl package in Ubuntu: New Status in nginx source package in Bionic: Incomplete Status in openssl source package in Bionic: New Bug description: After updating libssl and related packages, nginx will no longer autostart at system boot. Immediately after boot, nginx.service is in a failed state. # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Fri 2018-08-24 21:27:51 UTC; 32min ago Docs: man:nginx(8) systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Start-pre operation timed out. Terminating. systemd[1]: nginx.service: Failed with result 'timeout'. systemd[1]: Failed to start A high performance web server and a reverse proxy server. The service can be manually started after boot. # service nginx start # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-08-24 22:02:06 UTC; 2s ago Docs: man:nginx(8) Process: 2704 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 2703 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 2705 (nginx) CGroup: /system.slice/nginx.service ├─2705 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─2706 nginx: worker process systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument systemd[1]: Started A high performance web server and a reverse proxy server. This happens on an ARMHF based microcontroller running ubuntu 18.04.2 raspi server distribution with a stock kernel.org 4.9-181 kernel. Ubuntu repositories are not accessible from the device, so packages are copied to the device, and apt install is used to upgrade them: apt install --no-install-recommends $dir/updates/system/*.deb | logger 2>&1 The following is a list of packages that, when upgraded, cause the nginx systemd service to fail to autostart at boot. 201,205c201,205 < ii libpython2.7:armhf 2.7.15-4ubuntu4~18.04 armhf Shared Python runtime library (version 2.7) < ii libpython2.7-minimal:armhf 2.7.15-4ubuntu4~18.04 armhf Minimal subset of the Python language (version 2.7) < ii libpython2.7-stdlib:armhf 2.7.15-4ubuntu4~18.04 armhf Interactive high-level object-oriented language (standard library, version 2.7) < ii libpython3.6-minimal:armhf 3.6.8-1~18.04.1 armhf Minimal subset of the Python language (version 3.6) < ii libpython3.6-stdlib:armhf 3.6.8-1~18.04.1 armhf Interactive high-level object-oriented language (standard library, version 3.6) --- > ii libpython2.7:armhf 2.7.15~rc1-1ubuntu0.1 armhf Shared Python runtime library (version 2.7) > ii libpython2.7-minimal:armhf 2.7.15~rc1-1ubuntu0.1 armhf Minimal subset of the Python language (version 2.7) > ii libpython2.7-stdlib:armhf 2.7.15~rc1-1ubuntu0.1 armhf Interactive high-level object-oriented language (standard library, version 2.7) > ii libpython3.6-minimal:armhf 3.6.7-1~18.04 armhf Minimal subset of the Python language (version 3.6) > ii libpython3.6-stdlib:armhf 3.6.7-1~18.04 armhf Interactive high-level object-oriented language (standard library, version 3.6) 225c225 < ii libssl1.1:armhf
[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed
** Tags added: rls-ee-incoming -- 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/1835660 Title: initramfs unpacking failed Status in initramfs-tools package in Ubuntu: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes
** Changed in: systemd (Ubuntu Disco) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Disco) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Cosmic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Disco) Status: New => In Progress ** Changed in: systemd (Ubuntu Cosmic) Status: New => In Progress ** Changed in: systemd (Ubuntu Bionic) Status: New => In Progress ** Changed in: systemd (Ubuntu Cosmic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Tags added: ddstreet-next systemd -- 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/1835581 Title: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes Status in systemd: Unknown Status in systemd package in Ubuntu: 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 Status in systemd source package in Eoan: In Progress Bug description: [impact] the systemd networkd dhcp4 client sets the prefsrc for the default route added when a dhcp server provides only the gateway; but if the dhcp server provides classless route(s), those are configured instead, and the prefsrc is not set for those. Normally this is ok, but if the dhcp client system has other address(es) configured on the interface using dhcp, then the src for packets sent through a classless/static route might not be the same as the address provided by the dhcp server. If the gateway/router provided in the dhcp classless/static route(s) only allows traffic from the address provided to the dhcp client, then traffic from the dhcp client may be dropped by the gateway/router. [test case] set up a dhcp server system (e.g. ubuntu with dnsmasq installed and configured) and a dhcp client system. For example on the dhcp server, use this dnsmasq config: interface=ens8 bind-interfaces domain=test,10.10.0.0/24 dhcp-option=42,10.10.0.1 dhcp-range=test,10.10.0.10,10.10.0.100,1h On the dhcp client system, use networkd config such as: $ cat /etc/systemd/network/80-ens8.network [Match] Name=ens8 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 Address=10.10.0.5/24 Reboot the client, or restart networkd, and it should result in: $ ip -4 a show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8 valid_lft forever preferred_lft forever inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8 valid_lft 3580sec preferred_lft 3580sec $ ip r default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024 10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5 10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024 Note that, because networkd completes the static ip configuration before the dhcp reply is returned and processed, the static address is used for the subnet-local routing. But for global routing through the gateway, the dhcp-provided address is used: $ ip r get 1.1.1.1 1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000 Now on the server, add a classless route: dhcp-option=121,0.0.0.0/0,10.10.0.1 and restart dnsmasq on the server. Then on the client, reboot. It should now have: $ ip -4 a show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8 valid_lft forever preferred_lft forever inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8 valid_lft 3585sec preferred_lft 3585sec $ ip r default via 10.10.0.1 dev ens8 proto dhcp metric 1024 10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5 Now, the global route will use the static address, not the dhcp- provided address: $ ip r get 1.1.1.1 1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000 If the router, 10.10.0.1, only will forward traffic sent from the dhcp address it provided, 10.10.0.75, then this configuration will result in the client being unable to reach anything through the router, because all its packets will have a source address of 10.10.0.5, which the router would drop/reject. [regression potential] this only affects dhcp routes provided by a dhcp server using the 'static' or 'classless' route dhcp options. Since this behavior is currently the default when a system doesn't add static address(es) to interfaces that also get dhcp addresses, this is likely not a
[Touch-packages] [Bug 1835541] Re: ibus only provides non-standard UK keyboard layouts
** Changed in: ibus (Ubuntu) Status: Incomplete => 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/1835541 Title: ibus only provides non-standard UK keyboard layouts Status in ibus package in Ubuntu: New Bug description: When I attempt to add my standard UK keyboard to the layouts ibus knows about, I cannot do so. (See the attached image for the list of available layouts.) ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: ibus 1.5.19-4ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu3 Architecture: amd64 CurrentDesktop: i3 Date: Fri Jul 5 10:07:41 2019 InstallationDate: Installed on 2019-05-07 (58 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) SourcePackage: ibus UpgradeStatus: Upgraded to eoan on 2019-05-08 (57 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1835541/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835541] Re: ibus only provides non-standard UK keyboard layouts
Hi Seb, I'm using i3, and something was starting it during session startup (I have since used im-config to disable it entirely, as it isn't useful for me). I could reach that UI by right-clicking on the tray icon, selecting Preferences, switching to the Input Method tab and pressing the Add button. (To double check this, I launched ibus once by running ibus-daemon in a terminal.) Thanks! -- 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/1835541 Title: ibus only provides non-standard UK keyboard layouts Status in ibus package in Ubuntu: Incomplete Bug description: When I attempt to add my standard UK keyboard to the layouts ibus knows about, I cannot do so. (See the attached image for the list of available layouts.) ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: ibus 1.5.19-4ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu3 Architecture: amd64 CurrentDesktop: i3 Date: Fri Jul 5 10:07:41 2019 InstallationDate: Installed on 2019-05-07 (58 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) SourcePackage: ibus UpgradeStatus: Upgraded to eoan on 2019-05-08 (57 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1835541/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835738] [NEW] SRU: Update Python interpreter to 3.6.9 and 3.7.4
Public bug reported: Update Python interpreter to 3.6.9 and 3.7.4. As done with earlier subminor upstream releases. ** Affects: python3-defaults (Ubuntu) Importance: Undecided Status: New ** Affects: python3-stdlib-extensions (Ubuntu) Importance: Undecided Status: New ** Affects: python3.6 (Ubuntu) Importance: Undecided Status: New ** Affects: python3.7 (Ubuntu) Importance: Undecided Status: New ** Also affects: python3.7 (Ubuntu) Importance: Undecided Status: New ** Also affects: python3-stdlib-extensions (Ubuntu) Importance: Undecided Status: New ** Also affects: python3-defaults (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-defaults in Ubuntu. https://bugs.launchpad.net/bugs/1835738 Title: SRU: Update Python interpreter to 3.6.9 and 3.7.4 Status in python3-defaults package in Ubuntu: New Status in python3-stdlib-extensions package in Ubuntu: New Status in python3.6 package in Ubuntu: New Status in python3.7 package in Ubuntu: New Bug description: Update Python interpreter to 3.6.9 and 3.7.4. As done with earlier subminor upstream releases. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1835738/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: initramfs-tools (Ubuntu) Status: New => Confirmed -- 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/1835660 Title: initramfs unpacking failed Status in initramfs-tools package in Ubuntu: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1752656] Re: Please SRU archive keyrings to older releases
Note that SRUing debian-archive-keyring to xenial and earlier is hard, because its keyring generation code relies on gpg features that were added after bionic, and avoiding those features would break reproducibility of the generated keyring files and invalidate the signatures by Debian release team members. If we need to do this it's possible the only sensible option would be to smash in the generated files. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-keyring in Ubuntu. https://bugs.launchpad.net/bugs/1752656 Title: Please SRU archive keyrings to older releases Status in debian-archive-keyring package in Ubuntu: New Status in ubuntu-keyring package in Ubuntu: New Bug description: While not necessarily a critical issue for the Ubuntu keyrings, as Debian uses newer keys periodically, it becomes impossible with the default keyrings to verify the latest Debian archive files. It seems reasonable to ensure the keyring contents in all releases are the same, as the latest release is reflecting the latest archives. Related: bug 1801725 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-archive-keyring/+bug/1752656/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1835521] Re: [regression] Windows flicker to black when resizing (Intel Apollo Lake)
Please, take attention to this bug. It's very important!!! https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1835664 пн, 8 июл. 2019 г., 10:00 Daniel van Vugt : > ** Tags added: visual-quality > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1835521 > > Title: > [regression] Windows flicker to black when resizing (Intel Apollo > Lake) > > Status in gnome-shell package in Ubuntu: > New > Status in mesa package in Ubuntu: > New > Status in mutter package in Ubuntu: > New > > Bug description: > I see the black zones, small windows breaks. For additional details, I > use eoan-proposed and eoan-backports packages. > You can see this problem in my video: > https://photos.app.goo.gl/3rvLkqJj6hZwSscw9 > > ProblemType: Bug > DistroRelease: Ubuntu 19.10 > Package: gnome-shell 3.32.2-2ubuntu1 > ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 > Uname: Linux 5.0.0-20-generic x86_64 > ApportVersion: 2.20.11-0ubuntu3 > Architecture: amd64 > CurrentDesktop: ubuntu:GNOME > Date: Fri Jul 5 13:39:13 2019 > DisplayManager: gdm3 > InstallationDate: Installed on 2019-07-01 (3 days ago) > InstallationMedia: > > ProcEnviron: >LANGUAGE=ru_UA:ru >PATH=(custom, no user) >XDG_RUNTIME_DIR= >LANG=ru_UA.UTF-8 >SHELL=/bin/bash > RelatedPackageVersions: mutter-common 3.32.2+git20190626-1ubuntu1 > SourcePackage: gnome-shell > UpgradeStatus: No upgrade log present (probably fresh install) > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1835521/+subscriptions > -- 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/1835521 Title: [regression] Windows flicker to black when resizing (Intel Apollo Lake) Status in gnome-shell package in Ubuntu: New Status in mesa package in Ubuntu: New Status in mutter package in Ubuntu: New Bug description: I see the black zones, small windows breaks. For additional details, I use eoan-proposed and eoan-backports packages. You can see this problem in my video: https://photos.app.goo.gl/3rvLkqJj6hZwSscw9 ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.32.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Jul 5 13:39:13 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-07-01 (3 days ago) InstallationMedia: ProcEnviron: LANGUAGE=ru_UA:ru PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_UA.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.32.2+git20190626-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1835521/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
I think it falls into the gaps between the various packaging approaches and distributions. >From the discussions with the OpenLDAP chaps, they were pretty confident that they couldn't replicate the issue with the package built against OpenSSL, plus there was some talk of issue being related to a GNUTLS bug that was resolved. So between the two the thread went dead at that end. To replicate, run up a code snipped that connects to a destination WITH AN INVALID CERT: ldap_initialize ldap_set_option (enumerate the various LDAP_OPT_X_TLS_REQUIRE_CERT values) if uri != ldaps: then ldap_start_tls_s ldap_sasl_bind_s The LDAPS connections fail as expected. The STARTTLS connections all succeed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: Incomplete Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830169] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2019-07-08 05:18 EDT---
IBM bugzilla status -> closed, Fix Released with all requested distros
--
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/1830169
Title:
lvm udev rule fails to call systemd-run
Status in Ubuntu on IBM z Systems:
Fix Released
Status in lvm2 package in Ubuntu:
Fix Released
Status in lvm2 source package in Bionic:
Fix Released
Status in lvm2 source package in Cosmic:
Fix Released
Status in lvm2 source package in Disco:
Fix Released
Status in lvm2 source package in Eoan:
Fix Released
Bug description:
[Impact]
Judging from the rule, this probably means that volumes do not disappear when
the physical volume disappears.
[Test case]
Not available. But since it's just a path fix, it should not be a problem.
[Regression potential]
Removal might now actually work correctly, but it's not entirely clear how
that could cause a regression.
[Other info]
In /lib/udev/rules.d/69-lvm-metad.rules file, it calls /bin/systemd-run
command during removal ---
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm
pvscan --cache $major:$minor", GOTO="lvm_end"
But /bin/systemd-run is not found, in fact systemd-run is in /usr/bin
/systemd-run.
xx:~$ cat /etc/issue
Ubuntu 18.04.2 LTS \n \l
xx:~$ ls /bin/systemd-run
ls: cannot access '/bin/systemd-run': No such file or directory
xx:~$ ls /usr/bin/systemd-run
/usr/bin/systemd-run
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830169/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1802483] Re: Notifications emitted by a snap with local files or desktop files use wrong namespace
The changes got reviews on https://gitlab.gnome.org/GNOME/libnotify/merge_requests/5 and some work is needed so unsubscribing sponsors for now, please subscribe them back once you get the upstream reviewers agreeing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnotify in Ubuntu. https://bugs.launchpad.net/bugs/1802483 Title: Notifications emitted by a snap with local files or desktop files use wrong namespace Status in libnotify package in Ubuntu: In Progress Bug description: As can be tested using this example snap: - https://github.com/3v1n0/notify-send-test-snap Basically the icons are referenced using absolute paths in snap environment, while they should be readapted so that they depend on $SNAP location. As we do with appindicators and libunity emblems. [ Impact ] Icons sonuds and desktop files referenced by a snapped app using notifications aren't exposed to the desktop in absolute paths [ Test case ] Build the test snap: git clone https://github.com/3v1n0/notify-send-test-snap snapcraft prime snap try prime Check that icons are shown when launching: notify-send-test-snap notify-send-test-snap.image-path Running them with G_MESSAGES_DEBUG=all should provide translation logging [ Regression potential ] Normal applications that are run with a SNAP environment variable set, might use wrong paths for files or desktop file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/1802483/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1311056] Re: apt-add-repository adds duplicate commented/disabled source lines
** Changed in: python-apt (Ubuntu) Importance: Low => Medium ** Changed in: python-apt (Ubuntu) Importance: Medium => Critical ** Changed in: python-apt (Ubuntu) Importance: Critical => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1311056 Title: apt-add-repository adds duplicate commented/disabled source lines Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Triaged Bug description: Trusty Tahr 14.04 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main 0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y ppa:aims/aims-desktop gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main 0 root@osprey:/etc/apt/sources.list.d# That deb-src line should have stayed commented out, and not been duplicated. (Commented deb lines should of course be uncommented, as already fixed per https://bugs.launchpad.net/ubuntu/+source/python- apt/+bug/1042916 .) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830169] Re: lvm udev rule fails to call systemd-run
** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
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/1830169
Title:
lvm udev rule fails to call systemd-run
Status in Ubuntu on IBM z Systems:
Fix Released
Status in lvm2 package in Ubuntu:
Fix Released
Status in lvm2 source package in Bionic:
Fix Released
Status in lvm2 source package in Cosmic:
Fix Released
Status in lvm2 source package in Disco:
Fix Released
Status in lvm2 source package in Eoan:
Fix Released
Bug description:
[Impact]
Judging from the rule, this probably means that volumes do not disappear when
the physical volume disappears.
[Test case]
Not available. But since it's just a path fix, it should not be a problem.
[Regression potential]
Removal might now actually work correctly, but it's not entirely clear how
that could cause a regression.
[Other info]
In /lib/udev/rules.d/69-lvm-metad.rules file, it calls /bin/systemd-run
command during removal ---
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm
pvscan --cache $major:$minor", GOTO="lvm_end"
But /bin/systemd-run is not found, in fact systemd-run is in /usr/bin
/systemd-run.
xx:~$ cat /etc/issue
Ubuntu 18.04.2 LTS \n \l
xx:~$ ls /bin/systemd-run
ls: cannot access '/bin/systemd-run': No such file or directory
xx:~$ ls /usr/bin/systemd-run
/usr/bin/systemd-run
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830169/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1311056] Re: apt-add-repository adds duplicate commented/disabled source lines
clarification: breaking regex parsing at /usr/lib/python3/dist- packages/aptsources/sourceslist.py that is -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1311056 Title: apt-add-repository adds duplicate commented/disabled source lines Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Triaged Bug description: Trusty Tahr 14.04 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main 0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y ppa:aims/aims-desktop gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main 0 root@osprey:/etc/apt/sources.list.d# That deb-src line should have stayed commented out, and not been duplicated. (Commented deb lines should of course be uncommented, as already fixed per https://bugs.launchpad.net/ubuntu/+source/python- apt/+bug/1042916 .) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1311056] Re: apt-add-repository adds duplicate commented/disabled source lines
We're seeing this in the context of a charm where add-apt-repository is called periodically. We ended up with a sources.list file weighing in at 2.6Mb, which created problems for the regex engine there. In light of this can I ask to reconsider the "low" importance of this bug? FTR. this is Bionic, software-properties ver 0.96.24.32.7 ** Tags added: canonical-bootstack -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1311056 Title: apt-add-repository adds duplicate commented/disabled source lines Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Triaged Bug description: Trusty Tahr 14.04 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main 0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y ppa:aims/aims-desktop gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main 0 root@osprey:/etc/apt/sources.list.d# That deb-src line should have stayed commented out, and not been duplicated. (Commented deb lines should of course be uncommented, as already fixed per https://bugs.launchpad.net/ubuntu/+source/python- apt/+bug/1042916 .) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830169] Re: lvm udev rule fails to call systemd-run
This bug was fixed in the package lvm2 - 2.02.176-4.1ubuntu3.18.04.1
---
lvm2 (2.02.176-4.1ubuntu3.18.04.1) bionic; urgency=medium
* Fix patch of systemd-run in 69-lvm-metad.rules (LP: #1830169)
-- Julian Andres Klode Tue, 04 Jun 2019 11:59:58
+0200
** Changed in: lvm2 (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 lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1830169
Title:
lvm udev rule fails to call systemd-run
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in lvm2 package in Ubuntu:
Fix Released
Status in lvm2 source package in Bionic:
Fix Released
Status in lvm2 source package in Cosmic:
Fix Released
Status in lvm2 source package in Disco:
Fix Released
Status in lvm2 source package in Eoan:
Fix Released
Bug description:
[Impact]
Judging from the rule, this probably means that volumes do not disappear when
the physical volume disappears.
[Test case]
Not available. But since it's just a path fix, it should not be a problem.
[Regression potential]
Removal might now actually work correctly, but it's not entirely clear how
that could cause a regression.
[Other info]
In /lib/udev/rules.d/69-lvm-metad.rules file, it calls /bin/systemd-run
command during removal ---
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm
pvscan --cache $major:$minor", GOTO="lvm_end"
But /bin/systemd-run is not found, in fact systemd-run is in /usr/bin
/systemd-run.
xx:~$ cat /etc/issue
Ubuntu 18.04.2 LTS \n \l
xx:~$ ls /bin/systemd-run
ls: cannot access '/bin/systemd-run': No such file or directory
xx:~$ ls /usr/bin/systemd-run
/usr/bin/systemd-run
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830169/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822776] Update Released
The verification of the Stable Release Update for bash 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 bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: Fix Released Status in bash source package in Cosmic: Fix Committed Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 sudo apt-get update sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done Reproducer script: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+attachment/5275112/+files /bash-crash-test.sh It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. 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. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] 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. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. 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 1822776] Re: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait
This bug was fixed in the package bash - 4.4.18-2ubuntu1.2 --- bash (4.4.18-2ubuntu1.2) bionic; urgency=medium * d/p/bash44-020.diff: Add fix for hang on 'wait' statement (LP: #1822776) -- Bryce Harrington Thu, 06 Jun 2019 15:28:15 -0700 ** Changed in: bash (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 bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: Fix Released Status in bash source package in Cosmic: Fix Committed Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 sudo apt-get update sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done Reproducer script: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+attachment/5275112/+files /bash-crash-test.sh It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. 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. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] 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. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. 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 1822776] Re: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait
It's not clear to me if cosmic has been tested as part of the validation. Please make sure that's the case and then adjust the tag accordingly. That being said, since cosmic is going EOL soon, I will not block the release of bionic on the lack of cosmic validation. ** Tags removed: verification-done verification-done-cosmic ** 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 bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: Fix Released Status in bash source package in Cosmic: Fix Committed Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 sudo apt-get update sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done Reproducer script: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+attachment/5275112/+files /bash-crash-test.sh It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. 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. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] 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. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. 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 1835521] Re: [regression] Windows flicker to black when resizing (Intel Apollo Lake)
** Tags added: visual-quality -- 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/1835521 Title: [regression] Windows flicker to black when resizing (Intel Apollo Lake) Status in gnome-shell package in Ubuntu: New Status in mesa package in Ubuntu: New Status in mutter package in Ubuntu: New Bug description: I see the black zones, small windows breaks. For additional details, I use eoan-proposed and eoan-backports packages. You can see this problem in my video: https://photos.app.goo.gl/3rvLkqJj6hZwSscw9 ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.32.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Jul 5 13:39:13 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-07-01 (3 days ago) InstallationMedia: ProcEnviron: LANGUAGE=ru_UA:ru PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_UA.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.32.2+git20190626-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1835521/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1835521] Re: [regression] Artifacts appears when windows are maximizing or minimizing (Intel Apollo Lake)
Thank you very much. Will GNOME 3.34 bereally faster and smoother? I am very tired of the creepy animations and the long opening of the application menu. Sometimes there is a desire to change the graphical shell, but I hold on. I envy the device owners on macOS with their cool Launchpad (menu of apps, not website) and and the animations of minimizing/maximizing. I really wish to make Ubuntu so beautiful system as macOS. пн, 8 июл. 2019 г., 8:55 Daniel van Vugt : > Thanks for that. > > It seems you are reporting multiple different issues here. The black > flickering on window resizing seems to be a new problem so I'll make > that the main bug. > > The asymmetric artifacts seen when restoring from maximized is an old > bug (https://gitlab.gnome.org/GNOME/mutter/issues/636) so should be > reported separately. > > ** Bug watch added: gitlab.gnome.org/GNOME/mutter/issues #636 >https://gitlab.gnome.org/GNOME/mutter/issues/636 > > ** Summary changed: > > - [regression] Artifacts appears when windows are maximizing or minimizing > (Intel Apollo Lake) > + [regression] Windows flicker to black when resizing (Intel Apollo Lake) > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1835521 > > Title: > [regression] Windows flicker to black when resizing (Intel Apollo > Lake) > > Status in gnome-shell package in Ubuntu: > New > Status in mesa package in Ubuntu: > New > Status in mutter package in Ubuntu: > New > > Bug description: > I see the black zones, small windows breaks. For additional details, I > use eoan-proposed and eoan-backports packages. > You can see this problem in my video: > https://photos.app.goo.gl/3rvLkqJj6hZwSscw9 > > ProblemType: Bug > DistroRelease: Ubuntu 19.10 > Package: gnome-shell 3.32.2-2ubuntu1 > ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 > Uname: Linux 5.0.0-20-generic x86_64 > ApportVersion: 2.20.11-0ubuntu3 > Architecture: amd64 > CurrentDesktop: ubuntu:GNOME > Date: Fri Jul 5 13:39:13 2019 > DisplayManager: gdm3 > InstallationDate: Installed on 2019-07-01 (3 days ago) > InstallationMedia: > > ProcEnviron: >LANGUAGE=ru_UA:ru >PATH=(custom, no user) >XDG_RUNTIME_DIR= >LANG=ru_UA.UTF-8 >SHELL=/bin/bash > RelatedPackageVersions: mutter-common 3.32.2+git20190626-1ubuntu1 > SourcePackage: gnome-shell > UpgradeStatus: No upgrade log present (probably fresh install) > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1835521/+subscriptions > -- 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/1835521 Title: [regression] Windows flicker to black when resizing (Intel Apollo Lake) Status in gnome-shell package in Ubuntu: New Status in mesa package in Ubuntu: New Status in mutter package in Ubuntu: New Bug description: I see the black zones, small windows breaks. For additional details, I use eoan-proposed and eoan-backports packages. You can see this problem in my video: https://photos.app.goo.gl/3rvLkqJj6hZwSscw9 ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.32.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.11-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Jul 5 13:39:13 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-07-01 (3 days ago) InstallationMedia: ProcEnviron: LANGUAGE=ru_UA:ru PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_UA.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.32.2+git20190626-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1835521/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1785778] Re: Hash Sum mismatch Ubuntu Server 18.04.1 LTS
** Changed in: apt (Ubuntu) Status: Invalid => New -- 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/1785778 Title: Hash Sum mismatch Ubuntu Server 18.04.1 LTS Status in apt package in Ubuntu: New Bug description: Hi, I'm getting weird Hashes mismatch error while trying to update Ubuntu server 18.04.1 LTS server. The error I'm receiving is as follows. $ sudo apt-get update Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [83.2 kB] Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease Hit:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] Get:5 http://archive.ubuntu.com/ubuntu bionic-updates/universe Sources [52.2 kB] Get:6 http://archive.ubuntu.com/ubuntu bionic-updates/main Sources [152 kB] Get:7 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse Sources [2,676 B] Get:8 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [277 kB] Get:9 http://archive.ubuntu.com/ubuntu bionic-updates/main Translation-en [105 kB] Get:10 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [157 kB] Err:10 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages Hash Sum mismatch Hashes of expected file: - Filesize:157408 [weak] - SHA256:95fae016beb34455d4601a44c76d1823479178cbcdc58365750d4c039eecfb18 - SHA1:ad29965fe436d84b62331a4662e5fc679103fa0d [weak] - MD5Sum:4375646a0495b45597e06fb3e21dbd10 [weak] Hashes of received file: - SHA256:cdb9774bad7ab6f191ce597e3139f105477428fdc2509c63fcac8e5b904e4f4a - SHA1:96a041a735ddb8be1b14cc214ce0f56b486b42db [weak] - MD5Sum:a33f0341357c0be32207618a14b500db [weak] - Filesize:157408 [weak] Last modification reported: Tue, 07 Aug 2018 07:15:09 + Release file created at: Tue, 07 Aug 2018 07:15:03 + Get:11 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [71.0 kB] Get:12 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [3,772 B] Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse Translation-en [2,376 B] Err:14 http://download.webmin.com/download/repository sarge InRelease Could not connect to download.webmin.com:80 (108.60.199.109), connection timed out Fetched 329 kB in 30s (10.9 kB/s) Reading package lists... Done W: Failed to fetch http://download.webmin.com/download/repository/dists/sarge/InRelease Could not connect to download.webmin.com:80 (108.60.199.109), connection timed out E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/bionic-updates/universe/binary-amd64/by-hash/SHA256/95fae016beb34455d4601a44c76d1823479178cbcdc58365750d4c039eecfb18 Hash Sum mismatch Hashes of expected file: - Filesize:157408 [weak] - SHA256:95fae016beb34455d4601a44c76d1823479178cbcdc58365750d4c039eecfb18 - SHA1:ad29965fe436d84b62331a4662e5fc679103fa0d [weak] - MD5Sum:4375646a0495b45597e06fb3e21dbd10 [weak] Hashes of received file: - SHA256:cdb9774bad7ab6f191ce597e3139f105477428fdc2509c63fcac8e5b904e4f4a - SHA1:96a041a735ddb8be1b14cc214ce0f56b486b42db [weak] - MD5Sum:a33f0341357c0be32207618a14b500db [weak] - Filesize:157408 [weak] Last modification reported: Tue, 07 Aug 2018 07:15:09 + Release file created at: Tue, 07 Aug 2018 07:15:03 + W: Some index files failed to download. They have been ignored, or old ones used instead. I have tried solution provided in search as "removing all files in /var/lib/apt/lists and update again" but it doesn't work. Don't know how to resolve it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1785778/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
** Changed in: openldap (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: Incomplete Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
