[Touch-packages] [Bug 1740894] Re: KEY_RFKILL is not passed to userspace
** Tags removed: verification-failed-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 libxkbcommon in Ubuntu. https://bugs.launchpad.net/bugs/1740894 Title: KEY_RFKILL is not passed to userspace Status in libxkbcommon package in Ubuntu: Fix Released Status in xkeyboard-config package in Ubuntu: Fix Released Status in xorgproto package in Ubuntu: Fix Released Status in libxkbcommon source package in Bionic: Fix Released Status in xkeyboard-config source package in Bionic: Fix Committed Status in xorgproto source package in Bionic: Fix Released Status in libxkbcommon source package in Cosmic: Fix Released Status in xkeyboard-config source package in Cosmic: Fix Released Status in xorgproto source package in Cosmic: Fix Released Bug description: * Impact the airplane mode key doesn't work in GNOME * Test case Use a laptop with a key to activate airplane mode, it should toggle the corresponding mode on/off when used * Regression potential The change adds a new key definition but doesn't touch any existing one, nothing specific to test out of the new key working - There are a couple things going on, that could be fixed by a Debian or Ubuntu maintainer: - libxkbdcommon needs to be updated from 0.7.1 to 0.7.2. This introduces the RFKill key: https://lists.freedesktop.org/archives /wayland-devel/2017-August/034721.html - x11-proto needs a new release. This commit added RFKill, but it is not in a release: https://cgit.freedesktop.org/xorg/proto/xproto/commit/?id=98a32d328e7195e12c38baa877917335bceffbaf - Likely other X11 packages need to be rebuilt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libxkbcommon/+bug/1740894/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1772512] Re: Unable to install i386 and amd64 arch at the same time
use another method to install, it's there -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libxkbcommon in Ubuntu. https://bugs.launchpad.net/bugs/1772512 Title: Unable to install i386 and amd64 arch at the same time Status in libxkbcommon package in Ubuntu: Fix Released Status in libxkbcommon source package in Bionic: Fix Committed Bug description: [Impact] libxkbcommon-dev:i386/amd64 can't be installed at the same time, because the package isn't properly multi-archified in bionic [Test case] apt install libxkbcommon-dev:i386 libxkbcommon-dev:amd64 should succeed [Regression potential] not really -- Not sure if this is intended, but it's not possible to install two architectures of the libxkbcommon-dev at the same time. On Ubuntu 16.04 and 18.04 apt-get says that they are in conflict. The package is a dependency for libegl1-mesa-dev, which I need to have installed in 64 and 32-bit variants. Please see the example output below: $ lsb_release --all No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04 LTS Release: 18.04 Codename: bionic $ sudo apt-get install libxkbcommon-dev:* Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libxkbcommon-dev : Conflicts: libxkbcommon-dev:i386 but 0.8.0-1 is to be installed libxkbcommon-dev:i386 : Conflicts: libxkbcommon-dev but 0.8.0-1 is to be installed E: Unable to correct problems, you have held broken packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libxkbcommon/+bug/1772512/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832292] [NEW] reboot reboots system when -h is passed
Public bug reported: -h is a fairly common shortcut for --help. reboot, however, reboots the machine when one issues the command: reboot -h Now looking at the man page, there is an entry for --halt and --help, but NOTHING for -h at all. reboot should return the same as --help when -h is passed, or at the very least it should error out and not reboot the system, instead perhaps dumping a message like "-h unknown argument". ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-sysv 237-3ubuntu10.21 ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Tue Jun 11 00:50:22 2019 InstallationDate: Installed on 2016-02-11 (1215 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160210) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1832292 Title: reboot reboots system when -h is passed Status in systemd package in Ubuntu: New Bug description: -h is a fairly common shortcut for --help. reboot, however, reboots the machine when one issues the command: reboot -h Now looking at the man page, there is an entry for --halt and --help, but NOTHING for -h at all. reboot should return the same as --help when -h is passed, or at the very least it should error out and not reboot the system, instead perhaps dumping a message like "-h unknown argument". ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-sysv 237-3ubuntu10.21 ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Tue Jun 11 00:50:22 2019 InstallationDate: Installed on 2016-02-11 (1215 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160210) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1832292/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832110] Re: Resource Sharing with multiple sshd services
Robbie, If I upload the sshd.c proposed change, will that be possibility? I have diffed the sshd.c code against the OpenSSH 7.6p1 source. Ubuntu has made significant and substantial changes to all of the OpenSSH source. So I know Ubuntu does not use the original OpenSSH code verbatim. Is there anyway to change your mind from "Won't Fix" to "Investigating"? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1832110 Title: Resource Sharing with multiple sshd services Status in openssh package in Ubuntu: Won't Fix Bug description: Ubuntu: 18.04.2 LTS OpenSSH: 7.6p1 I am having a problem starting multiple sshd processes. The default location of the sshd privilege separation directory is hard-coded to /run/sshd (see man page). If I want to have 2 sshd services using systemd, I need to write 2 service files, let's call them sshd_wan.service ans sshd_lan.service. Both of these services need to have their own "RuntimeDirectory=sshd_wan" and "RuntimeDirectory=sshd_lan". If you do not have separate RuntimeDirectory definitions for the 2 services, then when one service is killed/faults/restarts/stops/etc. the systemd (or init) process deletes the RuntimeDirectory and causes the other service to crash since a RuntimeDirectory does not exist. The problem is the hard-coding of the sshd Privilege Separation Directory. We need to modify the OpenBSD/OpenSSH sshd code to provision command line assignment of the privilege separation directory. I have attempted to contact the OpenSSH team (i.e. OpenSSH.com) and they say it is a Ubuntu problem. I reported this in Ubuntu bug #1831765 and Ubuntu (e.g. Paride Legovini, June 6, 2019 @ 2:55AM PDT) rejected it because I described the problem using the init.d example. I know how to modify the sshd.c file in OpenSSH 7.6p1, the problem is getting Ubuntu and OpenSSH to admit there is a problem and it needs to be fixed. The problem is still there regardless if you are using Upstart (i.e. init.d) or systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1832110/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832074] Re: base-files '/etc/update-motd.d/50-motd-news' reports system use to Ubuntu
Thank you for your interest in improving the default experience in Ubuntu. We do understand that not everyone wants their machines to be talking to the Ubuntu servers, which is why there are several ways to disable this functionality. - on a per-machine basis, you can set ENABLED=0. - on a site-wide basis, you can firewall motd.ubuntu.com. There is a factual inaccuracy in your report, which is to say that this feature can be used to track login activity on machines. The update- motd script in question contains the following check: # If we're not forcing an update, and we have a cached motd-news file, # then just print it and exit as quickly as possible, for login performance. # Note that systemd should keep this cache file up to date, asynchronously if [ "$FORCED" != "1" ]; then if [ -r $CACHE ]; then echo safe_print $CACHE else : > $CACHE fi exit 0 fi Thus, aside from a possible execution at first login, systems will only contact motd.ubuntu.com twice per day with no correlation with user logins. It is also the case that Ubuntu systems already talk to Ubuntu servers daily by default, as apt will check twice daily for updates from archive.ubuntu.com and security.ubuntu.com, so the behavior of this update-motd script in base-files is consistent with the existing experience. Finally, you've raised the concern that this script exposes information about the system that could be used to exploit said system. Canonical takes the security of Ubuntu users very seriously. This is why, by default, security updates are applied to all Ubuntu systems daily in 18.04. This is why we offer a kernel livepatch service that enables users of Ubuntu 18.04 to fix high and critical kernel vulnerabilities outside of scheduled maintenance windows. If motd.ubuntu.com were ever to leak information to an attacker about what machines on the Internet were vulnerable to a particular attack, the root problem there would not be that information was shared with motd.ubuntu.com; the root problem would be that Ubuntu machines connected to the Internet had not had necessary security updates applied to them. Because on the Internet at large, attackers do not wait for a service like motd.ubuntu.com to tell them which machines are vulnerable before exploiting them. On the other hand, motd.ubuntu.com is a very important source of information for US about what versions of Ubuntu are in use in the wild - information that can be used, among other things, to identify problems with the rollout of kernel security updates to our users. So while it's understandable that some users will not want this behavior, I believe that it is defensible as default behavior in Ubuntu. -- 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/1832074 Title: base-files '/etc/update-motd.d/50-motd-news' reports system use to Ubuntu Status in base-files package in Ubuntu: Invalid Bug description: System information:: root@here $ lsb_release -rd Description:Ubuntu 18.04.2 LTS Release:18.04 root@here$ dpkg -l base-files | tail -1 ii base-files 10.1ubuntu2.4 amd64Debian base system miscellaneous files What I expect to happen:: Logins to my machine should not be communicated to anyone else, and should not provide anyone else of information about my machine. What does happen:: Logins to my machine report that a login occurred, and provide details about the installed system, to Ubuntu. Report:: I've just upgraded fromt Trusty to Bionic, and found that on login I get a message telling me something about Ubuntu's Kubernetes. I don't want advertising presented to me when I log in to MY system, so I began to investigate where this is happening - assuming that /etc /update-motd.d/10-help-text or 00-header had been updated during the upgrade and recreated with this content. Instead, I discover that there is another script that has been added - /etc/update-motd.d/50-motd-news - which adds this junk text to the login. Not only that, but the script comminucates with Ubuntu, to fetch that information. Not only that, but it provides information about the system that is running as part of the request. During the upgrade, I was not asked about whether it was ok for the system to call home every time I login (or every 12 hours, whichever is sooner, but at least a minute after you boot), and it absolutely would not be my expectation that this be the default. When I log in to my machine, I do not expect that the event would be reported to any off-site system, and I suspect that most other users would be surprised if not horrified to find that the fact that a system is in use was being reported to Ubuntu. The service can be disabled by
[Touch-packages] [Bug 1832074] Re: base-files '/etc/update-motd.d/50-motd-news' reports system use to Ubuntu
This bug report touches on a number of issues, which are variously 'invalid', 'wontfix', or 'opinion'. Since the bug title appears to refer to the (incorrect) claim that the update-motd script will expose information to the server about when users are logging in to the system, I am closing as invalid. ** Changed in: base-files (Ubuntu) Status: New => Invalid -- 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/1832074 Title: base-files '/etc/update-motd.d/50-motd-news' reports system use to Ubuntu Status in base-files package in Ubuntu: Invalid Bug description: System information:: root@here $ lsb_release -rd Description:Ubuntu 18.04.2 LTS Release:18.04 root@here$ dpkg -l base-files | tail -1 ii base-files 10.1ubuntu2.4 amd64Debian base system miscellaneous files What I expect to happen:: Logins to my machine should not be communicated to anyone else, and should not provide anyone else of information about my machine. What does happen:: Logins to my machine report that a login occurred, and provide details about the installed system, to Ubuntu. Report:: I've just upgraded fromt Trusty to Bionic, and found that on login I get a message telling me something about Ubuntu's Kubernetes. I don't want advertising presented to me when I log in to MY system, so I began to investigate where this is happening - assuming that /etc /update-motd.d/10-help-text or 00-header had been updated during the upgrade and recreated with this content. Instead, I discover that there is another script that has been added - /etc/update-motd.d/50-motd-news - which adds this junk text to the login. Not only that, but the script comminucates with Ubuntu, to fetch that information. Not only that, but it provides information about the system that is running as part of the request. During the upgrade, I was not asked about whether it was ok for the system to call home every time I login (or every 12 hours, whichever is sooner, but at least a minute after you boot), and it absolutely would not be my expectation that this be the default. When I log in to my machine, I do not expect that the event would be reported to any off-site system, and I suspect that most other users would be surprised if not horrified to find that the fact that a system is in use was being reported to Ubuntu. The service can be disabled by changing a setting in /etc/defaults /motd-news from ENABLED=1 to ENABLED=0, but this almost certainly should be defaulting to 0 - tracking disabled by default, not tracking enabled by default. For example, on my system this provides a user agent containing: ``` curl/7.58.0-2ubuntu3.7 Ubuntu/18.04.2/LTS GNU/Linux/4.15.0-50-generic/x86_64 Intel(R)/Xeon(R)/CPU/X5675/@/3.07GHz uptime/580915.35/4598709.84 ``` This means that every time the user logs in (or after 12 hours from the prior log in, whichever is longer) Ubuntu receives: * The IP address of a system that is in use (which might be behind NAT, but it's still a report). * The Distribution version details. * The Kernel version details * The CPU type * The uptime Knowing where a machine is, that it is active, exactly what type of system it is an how often it is restarted, would be an awesome dataset for any attacker to obtain - ideally (for them) it tells them the location of systems that are alive, how they might be attacked - from the distribution version, the kernel and the CPU information, you can determine a set of vulnerabilities to attack - and the uptime, which will indicate how likely the system is to be patched. The only thing that might be worse might be to include a cookie-jar on the curl command, which would allow tracking of individual systems, rather than aggregating them behind NAT using the IP (although it's still possible that the data reported in the user agent may be able to make that information individually usable). That said, the root user could (unintentionally) enable a cookie jar in their .curlrc and thus enable individual system tracking without realising. Whilst there may be legitimate reasons for reporting this information (say for reporting to the user that their system has updates available or that the system is vulnerable!), an advertising tool which reports the system's information regularly back to home does not seem appropriate for a 'base-files' package. The surprise at having my logins recorded on a remote site pales in comparison to the horror of recording a database of systems that might be abused. The Privacy and potential Security concerns of this feature hugely outweigh any perceived benefit to the user, and I believe that the right course of action is to remove this script entirely from the
[Touch-packages] [Bug 1829566] Re: network-manager 1.10.14-0ubuntu2 ignores systemd-resolved configured dns
Process follows directly from previous comment. - Updated to network-manager 1.10.14-0ubuntu2 (from bionic-proposed) - Rebooted and ran dig twice to mirror previous test, never resolved to expected result. :( - Log file from reboot until after the second dig attached. Ran dig a few more times over a couple of minutes, but never resolved successfully. ** Attachment added: "nm-1.10.14.log" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1829566/+attachment/5270070/+files/nm-1.10.14.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1829566 Title: network-manager 1.10.14-0ubuntu2 ignores systemd-resolved configured dns Status in network-manager package in Ubuntu: Incomplete Status in network-manager source package in Bionic: Incomplete Bug description: On 18.04.2 the `upgrade network-manager:amd64 1.10.6-2ubuntu1.1 1.10.14-0ubuntu2` lead to scoped DNS servers defined in `/etc/systemd/resolved.conf.d/*.conf` being ignored. Downgrading with `sudo apt-get install network- manager=1.10.6-2ubuntu1.1` has resolved the issue for now. Example systemd-resolved conf: [Resolve] Cache=no DNS=127.0.0.54 Domains=~.local.org.com Where 127.0.0.54:53 is bound to a dnsmasq server capable of resolving queries in that subdomain. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1829566/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1829566] Re: network-manager 1.10.14-0ubuntu2 ignores systemd-resolved configured dns
Can only attach one file at a time, so this and the next comment are heavily linked. - Updated to systemd 237-3ubuntu10.22 (from bionic-updates) - Enabled debug logging for network manager and disabled flood protection on journald. - Rebooted and successfully ran dig (second attempt) - First run did not return expected IP. - Second run onwards resolved as expected. - Log file from reboot until after the second dig attached. ** Attachment added: "nm-1.10.6.log" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1829566/+attachment/5270066/+files/nm-1.10.6.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1829566 Title: network-manager 1.10.14-0ubuntu2 ignores systemd-resolved configured dns Status in network-manager package in Ubuntu: Incomplete Status in network-manager source package in Bionic: Incomplete Bug description: On 18.04.2 the `upgrade network-manager:amd64 1.10.6-2ubuntu1.1 1.10.14-0ubuntu2` lead to scoped DNS servers defined in `/etc/systemd/resolved.conf.d/*.conf` being ignored. Downgrading with `sudo apt-get install network- manager=1.10.6-2ubuntu1.1` has resolved the issue for now. Example systemd-resolved conf: [Resolve] Cache=no DNS=127.0.0.54 Domains=~.local.org.com Where 127.0.0.54:53 is bound to a dnsmasq server capable of resolving queries in that subdomain. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1829566/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832268] Re: Low performance when I play a game
Thanks for the bug report. It does sound strange that pressing Escape improves performance. I wonder if that's a quirk of the game itself. Does pressing Escape work only in one specific game or multiple games? ** Tags added: nvidia ** Summary changed: - Low performance when I play a game + [nvidia] Low performance when I play a game ** Package changed: xorg (Ubuntu) => mutter (Ubuntu) ** Changed in: mutter (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/1832268 Title: [nvidia] Low performance when I play a game Status in mutter package in Ubuntu: Incomplete Bug description: Low performance when I play a game, i have a 18 fps frame rate, but when I press "Esc" the frame rate come back to usual performance! ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-21-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] É um diretório: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.116 Sun Jan 27 07:21:36 PST 2019 GCC version: gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04) ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jun 10 17:30:56 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: nvidia, 390.116, 4.15.0-51-generic, x86_64: installed nvidia, 390.116, 4.18.0-20-generic, x86_64: installed nvidia, 390.116, 4.18.0-21-generic, x86_64: installed GraphicsCard: NVIDIA Corporation GP107 [GeForce GTX 1050] [10de:1c81] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] GP107 [GeForce GTX 1050] [1462:8c97] InstallationDate: Installed on 2019-05-14 (27 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: System manufacturer System Product Name ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-21-generic root=UUID=ffe2dbb1-cd8c-415e-91c3-d382f32bb40e ro locale=pt_BR quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/18/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0502 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M PLUS/USB3 dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0502:bd11/18/2016:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-MPLUS/USB3:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: System Version dmi.sys.vendor: System manufacturer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.95-1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.04.2 version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1832268/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 508522] Re: Mic is not available with A2DP Bluetooth profile
Duplicate bug 1828393 suggests Bluetooth theoretically allows for two profiles to be enabled simultaneously. That would resolve this, but I don't know if it's true. If it is true then any fix would require modifying PulseAudio and the GUI in gnome-control-center. Maybe it's not really simultaneous. Maybe it's just smarter automatic switching. There is an upstream bug for that already: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/81 ** Bug watch added: PulseAudio #81 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/81 ** Also affects: pulseaudio via https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/81 Importance: Unknown Status: Unknown -- 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/508522 Title: Mic is not available with A2DP Bluetooth profile Status in PulseAudio: Unknown Status in pulseaudio package in Ubuntu: Confirmed Bug description: Binary package hint: pulseaudio I'm testing a Nokia BH-905i headset (see http://www.wissel.net/blog/d6plinks/SHWL-8AZGGF ) on Ubuntu 10.10. The Bluetooth module correctly identifies the headset and the both audio profiles "HSP/ HFP Telephony duplex" and "A2DP High Fidelity Playback". For music playback only A2DP is suitable (HSP/HFP sounds like listening to music played through an old telephone). A2DP does not have an INPUT mode, so use of the headset for VoiP isn't possible. What would be needed is a separate selection to allow to select A2DP for output and HSP/HFP for input. Smartphones (a lot of them *nix based) phones do that (or they switch on the fly?). Formal structure: 1) Ubuntu 10.10 2) Pulse-Audio 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 consisting og pluseaudio, pulseaudio-esound-compat, pulseaudio-module-bluetooth, pulseaudio-module-gconf, pulseaudio-module-x11, pulseaudio-utils 3) Select high quality audio output and still use the Bluetooth microphone 4) Had to choose: either high quality audio or "telephone quality" with microphone I can change the profile without the Bluetooth connection dropping, but that's ridiculous. E.g. listening to music, a call comes in. Then I would need to switch the profile before answering. Please note that in Windows, Mac OS, iOS, Android, and Windows Mobile it's done automatically. Check out attached screencast. ProblemType: Bug AplayDevices: List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 Architecture: i386 ArecordDevices: List of CAPTURE Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: oivasyuv 2309 F pulseaudio Card0.Amixer.info: Card hw:0 'Intel'/'HDA Intel at 0xd850 irq 17' Mixer name : 'Analog Devices AD1984A' Components : 'HDA:11d4194a,103c30e8,00100400' Controls : 22 Simple ctrls : 14 Date: Sat Jan 16 22:31:41 2010 DistroRelease: Ubuntu 9.10 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) Package: pulseaudio 1:0.9.19-0ubuntu4 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-17.54-generic-pae SourcePackage: pulseaudio Uname: Linux 2.6.31-17-generic-pae i686 To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/508522/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832120] Re: i386 - Test fails 'test_get_file_package_uninstalled_multiarch'
This bug was fixed in the package apport - 2.20.11-0ubuntu3 --- apport (2.20.11-0ubuntu3) eoan; urgency=medium * test/test_backend_apt_dpkg.py: Now that there are per architecture cache files we need to make all of them outdated rather than just the first one. (LP: #1832120) -- Brian Murray Mon, 10 Jun 2019 16:02:32 -0700 ** Changed in: apport (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 apport in Ubuntu. https://bugs.launchpad.net/bugs/1832120 Title: i386 - Test fails 'test_get_file_package_uninstalled_multiarch' Status in apport package in Ubuntu: Fix Released Bug description: Version: 2.20.11-0ubuntu2 Release: Eoan 19.10 This failure is currently blocking Konsole 19.04.2-0ubuntu1 from migrating from proposed. The test 'test_get_file_package_uninstalled_multiarch' now appears to be failing, at least the majority of the time, on i386 with: FAIL: test_get_file_package_uninstalled_multiarch (__main__.T) get_file_package() on foreign arches and releases -- Traceback (most recent call last): File "./test_backend_apt_dpkg.py", line 346, in test_get_file_package_uninstalled_multiarch True, cache_dir, arch='even') AssertionError: OSError not raised by get_file_package The test history can be seen here: http://autopkgtest.ubuntu.com/packages/a/apport/eoan/i386 This fails against multiple triggers, including itself in the release pocket. I would also note that the same failure has been seen recently on amd64: http://autopkgtest.ubuntu.com/packages/a/apport/eoan/amd64 however that then passed on subsequent retries. Something that does not seem to be the case after multiple retries on i386. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1832120/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832257] Re: regression: sudo returns exit code 0 if child is killed with SIGTERM
awesome, thanks so much -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1832257 Title: regression: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Xenial: Confirmed Bug description: hey there- it looks like we accidentally removed the patch that fixed this problem when releasing sudo 1.8.16-0ubuntu1.6 - https://git.launchpad.net/ubuntu/+source/sudo/commit/?h=ubuntu/xenial- updates=15345b19b82f587498573b38554e24ec0ab816cb note that `terminate-with-commands-signal.patch` is removed from debian/patches/series in that commit and the behavior described in the original bug (LP 1686803) has returned in xenial. can we get this back into the current sudo package? the fix still exists upstream so it feels like this was an accidental reversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1832257/+subscriptions -- Mailing list: https://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 1828171] Re: New toolchain updates need to be rebuilt against -security only
Note one can create .deb packages with arbitrary version numbers not matching what is listed in debian/changelog. And this package does that, for Spaß and clarity. And both builds appear to produce binaries with version numbers matching the underlying source gcc versions e.g. both builds produce: gccgo-alpha-linux-gnu-4:8.3.0-1ubuntu1.2 Which launchpad will not allow to publish. Also I don't think you need to strictly rebuild and republish gcc-defaults-ports and similar packages. as they should be metapackages only and don't contain any toolchains (and i.e. are safe to copy into -security pocket) -- Regards, Dimitri. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1828171 Title: New toolchain updates need to be rebuilt against -security only Status in binutils package in Ubuntu: New Status in eclipse-titan package in Ubuntu: New Status in gcc-7 package in Ubuntu: New Status in gcc-7-cross package in Ubuntu: New Status in gcc-7-cross-ports package in Ubuntu: New Status in gcc-8 package in Ubuntu: New Status in gcc-8-cross package in Ubuntu: New Status in gcc-8-cross-ports package in Ubuntu: New Status in gcc-defaults package in Ubuntu: New Status in gcc-defaults-ports package in Ubuntu: New Status in ggcov package in Ubuntu: New Status in binutils source package in Bionic: Fix Committed Status in eclipse-titan source package in Bionic: Fix Committed Status in gcc-7 source package in Bionic: Fix Committed Status in gcc-7-cross source package in Bionic: Fix Committed Status in gcc-7-cross-ports source package in Bionic: Fix Committed Status in gcc-8 source package in Bionic: Fix Committed Status in gcc-8-cross source package in Bionic: Fix Committed Status in gcc-8-cross-ports source package in Bionic: Fix Committed Status in gcc-defaults source package in Bionic: Fix Committed Status in gcc-defaults-ports source package in Bionic: Fix Committed Status in ggcov source package in Bionic: Fix Committed Status in binutils source package in Cosmic: Fix Committed Status in eclipse-titan source package in Cosmic: Fix Committed Status in gcc-7 source package in Cosmic: Fix Committed Status in gcc-7-cross source package in Cosmic: Fix Committed Status in gcc-7-cross-ports source package in Cosmic: Fix Committed Status in gcc-8 source package in Cosmic: Fix Committed Status in gcc-8-cross source package in Cosmic: Fix Committed Status in gcc-8-cross-ports source package in Cosmic: Fix Committed Status in gcc-defaults source package in Cosmic: Fix Committed Status in gcc-defaults-ports source package in Cosmic: Fix Committed Status in ggcov source package in Cosmic: Fix Committed Bug description: [Impact] With LP: #1814369, the toolchain packages have been updated in both cosmic and bionic, but due to an error those packages were built in -proposed as any regular SRU. For toolchain updates there exists a policy that those should be always built against -security *only*, and then released to both -security and -updates. Since this is not the case with the current toolchain update, we need to no-change rebuild all of the previously released toolchain packages in a -security enabled devirt PPA, sync them to -proposed with binaries and then release into the archives. [Regression Potential] As these are toolchain packages, there is always some regression potential. These will be no-change rebuilds so in theory the risk should be low, but the current versions of the packages have not been built against -security only before. It is hard to say how any regressions could manifest themselves. [Test Case] Making sure there are no reported regressions in the GCC and binutils test suites. Hopefully this will be sufficient. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1828171/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1770195] Re: OpenSSL missing ciphers
No, we do not wish to support weak-ssl-ciphers, they are long obsolete and dead. If you need to access acient servers or use acient clients you can e.g. launch precise in a lxd container with $ lxc launch ubuntu:precise Which ones are you specifically after? ** Changed in: openssl (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1770195 Title: OpenSSL missing ciphers Status in openssl package in Ubuntu: Incomplete Bug description: In OpenSSL 1.1.0 several ciphers were simply removed. They can be re- enabled by using "enable-weak-ssl-ciphers" option when building. This should be done to increase compatibility. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1770195/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1810129] Re: blake2b512 / sha3-512 invalid digest type
(specifically published RFCs defining the relevant digest-algo / signature types format to be used in x.509 certificates / or any pki generically. Just the definition of the math to calculate the digest is not enough) ** Changed in: openssl (Ubuntu) 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/1810129 Title: blake2b512 / sha3-512 invalid digest type Status in openssl package in Ubuntu: Opinion Bug description: cosmic | openssl 1.1.1-1 Since 1.1.1.a-1 provides support for blake2b512 / sha3-512 it would be expected such to work when generating certificates which however does not. OpenSSL> list -digest-commands blake2b512 blake2s256 gost md4 md5 mdc2 rmd160 sha1 sha224 sha256 sha3-224 sha3-256 sha3-384 sha3-512 sha384 sha512 sha512-224 sha512-256 shake128 shake256 sm3 OpenSSL> list -digest-algorithms ... BLAKE2b512 ... SHA3-512 ... Steps to reproduce: in openssl_ca.conf set 'default_md = blake2b512' or 'default_md = sha3-512' generating a certificate ends with 'error:100C508A:elliptic curve routines:pkey_ec_ctrl:invalid digest type:crypto/ec/ec_pmeth.c:327:' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1810129/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1810129] Re: blake2b512 / sha3-512 invalid digest type
I don't think it follows.
For example, with an RSA key I can use SHA3-512.
Signature Algorithm: RSA-SHA3-512
The point is, that digests are not independant, and one cannot just use
any as they need to have well known identifiers as specified in the
relevant RFCs.
Ie.
https://tools.ietf.org/html/rfc5280
https://tools.ietf.org/html/rfc3279
https://tools.ietf.org/html/rfc4055
And similar.
The SHA3 algorithms are being added in this draft:
https://tools.ietf.org/html/draft-turner-lamps-adding-sha3-to-pkix-01#ref-I-D.ietf-curdle-pkix
But it looks like it has expired
https://datatracker.ietf.org/doc/draft-turner-lamps-adding-sha3-to-pkix/
So i'm not sure what openssl is basing their implementation on. Maybe
something published by IEEE?!
For elliptic curve keys it seems like the supported digests are all the usual
suspects:
if (EVP_MD_type((const EVP_MD *)p2) != NID_sha1 &&
EVP_MD_type((const EVP_MD *)p2) != NID_ecdsa_with_SHA1 &&
EVP_MD_type((const EVP_MD *)p2) != NID_sha224 &&
EVP_MD_type((const EVP_MD *)p2) != NID_sha256 &&
EVP_MD_type((const EVP_MD *)p2) != NID_sha384 &&
EVP_MD_type((const EVP_MD *)p2) != NID_sha512) {
ECerr(EC_F_PKEY_EC_CTRL, EC_R_INVALID_DIGEST_TYPE);
return 0;
}
For RSA keys slightly larger list:
case NID_sha1:
case NID_sha224:
case NID_sha256:
case NID_sha384:
case NID_sha512:
case NID_md5:
case NID_md5_sha1:
case NID_md2:
case NID_md4:
case NID_mdc2:
case NID_ripemd160:
case NID_sha3_224:
case NID_sha3_256:
case NID_sha3_384:
case NID_sha3_512:
return 1;
If there are algos for which there are published RFCs please open a bug
upstream about adding those. If there are none defined, please submit
RFC to IETF to get them defined such that new digest algos can be added
across the internet - and not be specific to just openssl.
It's not up to Ubuntu to define new digest types in x.509, thus i'm
closing this bug report as 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/1810129
Title:
blake2b512 / sha3-512 invalid digest type
Status in openssl package in Ubuntu:
Opinion
Bug description:
cosmic | openssl 1.1.1-1
Since 1.1.1.a-1 provides support for blake2b512 / sha3-512 it would be
expected such to work when generating certificates which however does
not.
OpenSSL> list -digest-commands
blake2b512 blake2s256 gost md4
md5 mdc2 rmd160 sha1
sha224 sha256 sha3-224 sha3-256
sha3-384 sha3-512 sha384 sha512
sha512-224 sha512-256 shake128 shake256
sm3
OpenSSL> list -digest-algorithms
...
BLAKE2b512
...
SHA3-512
...
Steps to reproduce:
in openssl_ca.conf set 'default_md = blake2b512' or 'default_md =
sha3-512'
generating a certificate ends with
'error:100C508A:elliptic curve routines:pkey_ec_ctrl:invalid digest
type:crypto/ec/ec_pmeth.c:327:'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1810129/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832120] Re: i386 - Test fails 'test_get_file_package_uninstalled_multiarch'
** Branch linked: lp:~ubuntu-core-dev/ubuntu/eoan/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/1832120 Title: i386 - Test fails 'test_get_file_package_uninstalled_multiarch' Status in apport package in Ubuntu: In Progress Bug description: Version: 2.20.11-0ubuntu2 Release: Eoan 19.10 This failure is currently blocking Konsole 19.04.2-0ubuntu1 from migrating from proposed. The test 'test_get_file_package_uninstalled_multiarch' now appears to be failing, at least the majority of the time, on i386 with: FAIL: test_get_file_package_uninstalled_multiarch (__main__.T) get_file_package() on foreign arches and releases -- Traceback (most recent call last): File "./test_backend_apt_dpkg.py", line 346, in test_get_file_package_uninstalled_multiarch True, cache_dir, arch='even') AssertionError: OSError not raised by get_file_package The test history can be seen here: http://autopkgtest.ubuntu.com/packages/a/apport/eoan/i386 This fails against multiple triggers, including itself in the release pocket. I would also note that the same failure has been seen recently on amd64: http://autopkgtest.ubuntu.com/packages/a/apport/eoan/amd64 however that then passed on subsequent retries. Something that does not seem to be the case after multiple retries on i386. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1832120/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832257] Re: regression: sudo returns exit code 0 if child is killed with SIGTERM
I've uploaded it to build in the following PPA: https://launchpad.net/~ubuntu-security- proposed/+archive/ubuntu/ppa/+packages You can get it from there if you need it before tomorrow. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1832257 Title: regression: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Xenial: Confirmed Bug description: hey there- it looks like we accidentally removed the patch that fixed this problem when releasing sudo 1.8.16-0ubuntu1.6 - https://git.launchpad.net/ubuntu/+source/sudo/commit/?h=ubuntu/xenial- updates=15345b19b82f587498573b38554e24ec0ab816cb note that `terminate-with-commands-signal.patch` is removed from debian/patches/series in that commit and the behavior described in the original bug (LP 1686803) has returned in xenial. can we get this back into the current sudo package? the fix still exists upstream so it feels like this was an accidental reversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1832257/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828171] Re: New toolchain updates need to be rebuilt against -security only
Hey Colin! I'm EOD now so I didn't have time to look into it (and am probably too sleepy to look at this sanely) but what do you mean by 'versions overlapping'? 1.176ubuntu1.2 and 1.178ubuntu1.2 seem like different versions (1.176 for bionic and 1.178 for cosmic), and one is smaller than the other. How does the overlap look like? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1828171 Title: New toolchain updates need to be rebuilt against -security only Status in binutils package in Ubuntu: New Status in eclipse-titan package in Ubuntu: New Status in gcc-7 package in Ubuntu: New Status in gcc-7-cross package in Ubuntu: New Status in gcc-7-cross-ports package in Ubuntu: New Status in gcc-8 package in Ubuntu: New Status in gcc-8-cross package in Ubuntu: New Status in gcc-8-cross-ports package in Ubuntu: New Status in gcc-defaults package in Ubuntu: New Status in gcc-defaults-ports package in Ubuntu: New Status in ggcov package in Ubuntu: New Status in binutils source package in Bionic: Fix Committed Status in eclipse-titan source package in Bionic: Fix Committed Status in gcc-7 source package in Bionic: Fix Committed Status in gcc-7-cross source package in Bionic: Fix Committed Status in gcc-7-cross-ports source package in Bionic: Fix Committed Status in gcc-8 source package in Bionic: Fix Committed Status in gcc-8-cross source package in Bionic: Fix Committed Status in gcc-8-cross-ports source package in Bionic: Fix Committed Status in gcc-defaults source package in Bionic: Fix Committed Status in gcc-defaults-ports source package in Bionic: Fix Committed Status in ggcov source package in Bionic: Fix Committed Status in binutils source package in Cosmic: Fix Committed Status in eclipse-titan source package in Cosmic: Fix Committed Status in gcc-7 source package in Cosmic: Fix Committed Status in gcc-7-cross source package in Cosmic: Fix Committed Status in gcc-7-cross-ports source package in Cosmic: Fix Committed Status in gcc-8 source package in Cosmic: Fix Committed Status in gcc-8-cross source package in Cosmic: Fix Committed Status in gcc-8-cross-ports source package in Cosmic: Fix Committed Status in gcc-defaults source package in Cosmic: Fix Committed Status in gcc-defaults-ports source package in Cosmic: Fix Committed Status in ggcov source package in Cosmic: Fix Committed Bug description: [Impact] With LP: #1814369, the toolchain packages have been updated in both cosmic and bionic, but due to an error those packages were built in -proposed as any regular SRU. For toolchain updates there exists a policy that those should be always built against -security *only*, and then released to both -security and -updates. Since this is not the case with the current toolchain update, we need to no-change rebuild all of the previously released toolchain packages in a -security enabled devirt PPA, sync them to -proposed with binaries and then release into the archives. [Regression Potential] As these are toolchain packages, there is always some regression potential. These will be no-change rebuilds so in theory the risk should be low, but the current versions of the packages have not been built against -security only before. It is hard to say how any regressions could manifest themselves. [Test Case] Making sure there are no reported regressions in the GCC and binutils test suites. Hopefully this will be sufficient. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1828171/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832257] Re: regression: sudo returns exit code 0 if child is killed with SIGTERM
I'll release it tomorrow. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1832257 Title: regression: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Xenial: Confirmed Bug description: hey there- it looks like we accidentally removed the patch that fixed this problem when releasing sudo 1.8.16-0ubuntu1.6 - https://git.launchpad.net/ubuntu/+source/sudo/commit/?h=ubuntu/xenial- updates=15345b19b82f587498573b38554e24ec0ab816cb note that `terminate-with-commands-signal.patch` is removed from debian/patches/series in that commit and the behavior described in the original bug (LP 1686803) has returned in xenial. can we get this back into the current sudo package? the fix still exists upstream so it feels like this was an accidental reversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1832257/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832120] Re: i386 - Test fails 'test_get_file_package_uninstalled_multiarch'
** Changed in: apport (Ubuntu) Status: New => In Progress ** Changed in: apport (Ubuntu) Importance: Undecided => High ** Changed in: apport (Ubuntu) Assignee: (unassigned) => Brian Murray (brian-murray) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1832120 Title: i386 - Test fails 'test_get_file_package_uninstalled_multiarch' Status in apport package in Ubuntu: In Progress Bug description: Version: 2.20.11-0ubuntu2 Release: Eoan 19.10 This failure is currently blocking Konsole 19.04.2-0ubuntu1 from migrating from proposed. The test 'test_get_file_package_uninstalled_multiarch' now appears to be failing, at least the majority of the time, on i386 with: FAIL: test_get_file_package_uninstalled_multiarch (__main__.T) get_file_package() on foreign arches and releases -- Traceback (most recent call last): File "./test_backend_apt_dpkg.py", line 346, in test_get_file_package_uninstalled_multiarch True, cache_dir, arch='even') AssertionError: OSError not raised by get_file_package The test history can be seen here: http://autopkgtest.ubuntu.com/packages/a/apport/eoan/i386 This fails against multiple triggers, including itself in the release pocket. I would also note that the same failure has been seen recently on amd64: http://autopkgtest.ubuntu.com/packages/a/apport/eoan/amd64 however that then passed on subsequent retries. Something that does not seem to be the case after multiple retries on i386. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1832120/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828171] Re: New toolchain updates need to be rebuilt against -security only
I had to remove gcc-defaults-ports from cosmic-proposed: https://launchpad.net/ubuntu/+source/gcc-defaults-ports/1.176ubuntu1.2 and https://launchpad.net/ubuntu/+source/gcc-defaults- ports/1.178ubuntu1.2 have overlapping binary versions in different builds, so these were unpublishable and were causing the publisher to OOPS frequently. Could you please sort out a non-overlapping version scheme here? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1828171 Title: New toolchain updates need to be rebuilt against -security only Status in binutils package in Ubuntu: New Status in eclipse-titan package in Ubuntu: New Status in gcc-7 package in Ubuntu: New Status in gcc-7-cross package in Ubuntu: New Status in gcc-7-cross-ports package in Ubuntu: New Status in gcc-8 package in Ubuntu: New Status in gcc-8-cross package in Ubuntu: New Status in gcc-8-cross-ports package in Ubuntu: New Status in gcc-defaults package in Ubuntu: New Status in gcc-defaults-ports package in Ubuntu: New Status in ggcov package in Ubuntu: New Status in binutils source package in Bionic: Fix Committed Status in eclipse-titan source package in Bionic: Fix Committed Status in gcc-7 source package in Bionic: Fix Committed Status in gcc-7-cross source package in Bionic: Fix Committed Status in gcc-7-cross-ports source package in Bionic: Fix Committed Status in gcc-8 source package in Bionic: Fix Committed Status in gcc-8-cross source package in Bionic: Fix Committed Status in gcc-8-cross-ports source package in Bionic: Fix Committed Status in gcc-defaults source package in Bionic: Fix Committed Status in gcc-defaults-ports source package in Bionic: Fix Committed Status in ggcov source package in Bionic: Fix Committed Status in binutils source package in Cosmic: Fix Committed Status in eclipse-titan source package in Cosmic: Fix Committed Status in gcc-7 source package in Cosmic: Fix Committed Status in gcc-7-cross source package in Cosmic: Fix Committed Status in gcc-7-cross-ports source package in Cosmic: Fix Committed Status in gcc-8 source package in Cosmic: Fix Committed Status in gcc-8-cross source package in Cosmic: Fix Committed Status in gcc-8-cross-ports source package in Cosmic: Fix Committed Status in gcc-defaults source package in Cosmic: Fix Committed Status in gcc-defaults-ports source package in Cosmic: Fix Committed Status in ggcov source package in Cosmic: Fix Committed Bug description: [Impact] With LP: #1814369, the toolchain packages have been updated in both cosmic and bionic, but due to an error those packages were built in -proposed as any regular SRU. For toolchain updates there exists a policy that those should be always built against -security *only*, and then released to both -security and -updates. Since this is not the case with the current toolchain update, we need to no-change rebuild all of the previously released toolchain packages in a -security enabled devirt PPA, sync them to -proposed with binaries and then release into the archives. [Regression Potential] As these are toolchain packages, there is always some regression potential. These will be no-change rebuilds so in theory the risk should be low, but the current versions of the packages have not been built against -security only before. It is hard to say how any regressions could manifest themselves. [Test Case] Making sure there are no reported regressions in the GCC and binutils test suites. Hopefully this will be sufficient. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1828171/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1744372] Re: gparted does not start - Unit -.mount does not exist, proceeding anyway.
*** This bug is a duplicate of bug 1652282 *** https://bugs.launchpad.net/bugs/1652282 I did not delete libgtk-x11-2.0.so.0. I installed 19.04 a few days ago. Unit tmp.mount does not exist, proceeding anyway. /usr/sbin/gpartedbin: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 19.04 Release:19.04 Codename: disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1744372 Title: gparted does not start - Unit -.mount does not exist, proceeding anyway. Status in gparted package in Ubuntu: Confirmed Status in wayland package in Ubuntu: Invalid Bug description: 1. fresh ubuntu 18.04 daily: lsb_release -rd Description: Ubuntu Bionic Beaver (development branch) Release: 18.04 2. install gparted with Software: gparted: Installiert: 0.30.0-3ubuntu1 Installationskandidat: 0.30.0-3ubuntu1 Versionstabelle: *** 0.30.0-3ubuntu1 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status 3. launch with icon - enter password - nothing. 4.launch in terminal: Unit -.mount does not exist, proceeding anyway. Created symlink /run/systemd/system/-.mount → /dev/null. Created symlink /run/systemd/system/boot-efi.mount → /dev/null. Created symlink /run/systemd/system/home.mount → /dev/null. Created symlink /run/systemd/system/run-snapd-ns-vlc.mnt.mount → /dev/null. Created symlink /run/systemd/system/run-snapd-ns.mount → /dev/null. Created symlink /run/systemd/system/run-user-1000.mount → /dev/null. Created symlink /run/systemd/system/run-user-120.mount → /dev/null. Created symlink /run/systemd/system/snap-core-3748.mount → /dev/null. Created symlink /run/systemd/system/snap-vlc-113.mount → /dev/null. Created symlink /run/systemd/system/tmp.mount → /dev/null. No protocol specified (gpartedbin:8328): Gtk-WARNING **: cannot open display: :0 Removed /run/systemd/system/-.mount. Removed /run/systemd/system/boot-efi.mount. Removed /run/systemd/system/home.mount. Removed /run/systemd/system/run-snapd-ns-vlc.mnt.mount. Removed /run/systemd/system/run-snapd-ns.mount. Removed /run/systemd/system/run-user-1000.mount. Removed /run/systemd/system/run-user-120.mount. Removed /run/systemd/system/snap-core-3748.mount. Removed /run/systemd/system/snap-vlc-113.mount. Removed /run/systemd/system/tmp.mount. How to Fix: run xhost +local: before gparted! # this only bypass the wayland restriction; meaning a security violation (not a fix !!! ) thomas@ubuntu-1804:~$ xhost +local: non-network local connections being added to access control list thomas@ubuntu-1804:~$ gparted Unit -.mount does not exist, proceeding anyway. Created symlink /run/systemd/system/-.mount → /dev/null. Created symlink /run/systemd/system/boot-efi.mount → /dev/null. Created symlink /run/systemd/system/home.mount → /dev/null. Created symlink /run/systemd/system/run-snapd-ns-vlc.mnt.mount → /dev/null. Created symlink /run/systemd/system/run-snapd-ns.mount → /dev/null. Created symlink /run/systemd/system/run-user-1000.mount → /dev/null. Created symlink /run/systemd/system/run-user-120.mount → /dev/null. Created symlink /run/systemd/system/snap-core-3748.mount → /dev/null. Created symlink /run/systemd/system/snap-vlc-113.mount → /dev/null. Created symlink /run/systemd/system/tmp.mount → /dev/null. Gtk-Message: Failed to load module "canberra-gtk-module" == libparted : 3.2 == Removed /run/systemd/system/-.mount. Removed /run/systemd/system/boot-efi.mount. Removed /run/systemd/system/home.mount. Removed /run/systemd/system/run-snapd-ns-vlc.mnt.mount. Removed /run/systemd/system/run-snapd-ns.mount. Removed /run/systemd/system/run-user-1000.mount. Removed /run/systemd/system/run-user-120.mount. Removed /run/systemd/system/snap-core-3748.mount. Removed /run/systemd/system/snap-vlc-113.mount. Removed /run/systemd/system/tmp.mount. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gparted 0.30.0-3ubuntu1 ProcVersionSignature: Ubuntu 4.13.0-25.29-generic 4.13.13 Uname: Linux 4.13.0-25-generic x86_64 ApportVersion: 2.20.8-0ubuntu6 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Jan 19 19:45:14 2018 InstallationDate: Installed on 2018-01-18 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180111) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: gparted UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to:
[Touch-packages] [Bug 1832257] Re: regression: sudo returns exit code 0 if child is killed with SIGTERM
do you have any guidance on how long a fix like this generally takes to land? we're deciding whether or not to roll our own, as this has some immediately undesirable effects in our environment. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1832257 Title: regression: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Xenial: Confirmed Bug description: hey there- it looks like we accidentally removed the patch that fixed this problem when releasing sudo 1.8.16-0ubuntu1.6 - https://git.launchpad.net/ubuntu/+source/sudo/commit/?h=ubuntu/xenial- updates=15345b19b82f587498573b38554e24ec0ab816cb note that `terminate-with-commands-signal.patch` is removed from debian/patches/series in that commit and the behavior described in the original bug (LP 1686803) has returned in xenial. can we get this back into the current sudo package? the fix still exists upstream so it feels like this was an accidental reversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1832257/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
built and passed all autopkgtests on all architectures.
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python-tornado source package in Bionic:
Fix Committed
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn how
to use session callback.
- non-application data records. TLSv1.3 sends more of these, when compared
with previous versions, and some applications may not handle this correctly.
Resulting in application data not being available, when previously expected.
Mitigation
[Touch-packages] [Bug 1832258] Re: Need to backport fix for inability to add Canon printers
** Changed in: cups Status: Unknown => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1832258 Title: Need to backport fix for inability to add Canon printers Status in CUPS: Fix Released Status in cups package in Ubuntu: New Bug description: The following bug was reported and fixed in cups 2.2.11. https://github.com/apple/cups/issues/5484 Without the fix, it is not possible to add or use a number of Canon printers. Currently, 19.04 ships with 2.2.10 + some backports, but those backports do not include the fix for this problem. We either need the fix backported or an update to 2.2.11. Release: Ubuntu 19.04 Version: 2.2.10-4ubuntu2 What you expected: Adding a canon printer works What happened instead: Adding a canon printer fails with a useless error and log investigation lead to upstream issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1832258/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832268] [NEW] Low performance when I play a game
Public bug reported: Low performance when I play a game, i have a 18 fps frame rate, but when I press "Esc" the frame rate come back to usual performance! ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-21-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] É um diretório: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.116 Sun Jan 27 07:21:36 PST 2019 GCC version: gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04) ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jun 10 17:30:56 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: nvidia, 390.116, 4.15.0-51-generic, x86_64: installed nvidia, 390.116, 4.18.0-20-generic, x86_64: installed nvidia, 390.116, 4.18.0-21-generic, x86_64: installed GraphicsCard: NVIDIA Corporation GP107 [GeForce GTX 1050] [10de:1c81] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] GP107 [GeForce GTX 1050] [1462:8c97] InstallationDate: Installed on 2019-05-14 (27 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: System manufacturer System Product Name ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-21-generic root=UUID=ffe2dbb1-cd8c-415e-91c3-d382f32bb40e ro locale=pt_BR quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/18/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0502 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M PLUS/USB3 dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0502:bd11/18/2016:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-MPLUS/USB3:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: System Version dmi.sys.vendor: System manufacturer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.95-1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.04.2 version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic performance 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/1832268 Title: Low performance when I play a game Status in xorg package in Ubuntu: New Bug description: Low performance when I play a game, i have a 18 fps frame rate, but when I press "Esc" the frame rate come back to usual performance! ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-21-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] É um diretório: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.116 Sun Jan 27 07:21:36 PST 2019 GCC version: gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04) ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jun 10 17:30:56 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: nvidia, 390.116, 4.15.0-51-generic, x86_64: installed nvidia, 390.116, 4.18.0-20-generic, x86_64: installed nvidia, 390.116, 4.18.0-21-generic, x86_64: installed GraphicsCard: NVIDIA Corporation GP107 [GeForce GTX 1050] [10de:1c81] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] GP107 [GeForce GTX 1050] [1462:8c97]
[Touch-packages] [Bug 1832041] Re: The mouse stops working
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1832041 Title: The mouse stops working Status in xorg package in Ubuntu: New Bug description: Sometime the wifi is not getting detected and the mouse is not working and and i am using touch instead of mouse, the external mouse is also not working ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-21-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sat Jun 8 00:40:19 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: nvidia, 390.116, 4.15.0-47-generic, x86_64: installed nvidia, 390.116, 4.15.0-51-generic, x86_64: installed nvidia, 390.116, 4.18.0-17-generic, x86_64: installed nvidia, 390.116, 4.18.0-21-generic, x86_64: installed ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company UHD Graphics 620 [103c:83ba] Subsystem: Hewlett-Packard Company GP108M [GeForce MX150] [103c:83ba] InstallationDate: Installed on 2019-04-04 (64 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 8087:0025 Intel Corp. Bus 001 Device 003: ID 05c8:0815 Cheng Uei Precision Industry Co., Ltd (Foxlink) Bus 001 Device 009: ID 03f0:0941 Hewlett-Packard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Spectre x360 Convertible 15-ch0xx ProcEnviron: LANGUAGE=en_IN:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-21-generic root=UUID=a759c10c-be50-4caf-bd43-1516b97d1c6a ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/15/2018 dmi.bios.vendor: AMI dmi.bios.version: F.23 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 83BA dmi.board.vendor: HP dmi.board.version: 57.31 dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAMI:bvrF.23:bd10/15/2018:svnHP:pnHPSpectrex360Convertible15-ch0xx:pvr:rvnHP:rn83BA:rvr57.31:cvnHP:ct31:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Spectre dmi.product.name: HP Spectre x360 Convertible 15-ch0xx dmi.product.sku: 2FW61AV dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.95-1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.04.2 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1832041/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
I installed cosmic on power9 (boston) a non-nvme system, installed initramfs-tools from -proposed and install kdump-tools. Triggered a dump, but I got a kernel panic. Please let me know if I am doing something wrong here. ubuntu@tiselius:~$ uname -a Linux tiselius 4.18.0-21-generic #22-Ubuntu SMP Wed May 15 13:12:45 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux ubuntu@tiselius:~$ ubuntu@tiselius:~$ apt policy initramfs-tools initramfs-tools: Installed: 0.131ubuntu15.2 Candidate: 0.131ubuntu15.2 Version table: *** 0.131ubuntu15.2 500 500 http://ports.ubuntu.com/ubuntu-ports cosmic-proposed/main ppc64el Packages ubuntu@tiselius:~$ ubuntu@tiselius:~$ apt policy kdump-tools kdump-tools: Installed: 1:1.6.5-1ubuntu1~18.10.1 Candidate: 1:1.6.5-1ubuntu1~18.10.1 Version table: *** 1:1.6.5-1ubuntu1~18.10.1 500 500 http://ports.ubuntu.com/ubuntu-ports cosmic-updates/main ppc64el Packages 100 /var/lib/dpkg/status 1:1.6.4-2ubuntu1 500 500 http://ports.ubuntu.com/ubuntu-ports cosmic/main ppc64el Packages ubuntu@tiselius:~$ ubuntu@tiselius:~$ sudo kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.18.0-21-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.18.0-21-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=295f571b-b731-4ebb-b752-60aadc80fc1b ro console=hvc0 nr_cpus=1 systemd.unit=kdump-tools-dump.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz ubuntu@tiselius:~$ ubuntu@tiselius:~$ cat /proc/cmdline root=UUID=295f571b-b731-4ebb-b752-60aadc80fc1b ro console=hvc0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M@128M ubuntu@tiselius:~$ ubuntu@tiselius:~$ dmesg | grep Reser [0.00] Reserving 4096MB of memory at 128MB for crashkernel (System RAM: 131072MB) [0.00] cma: Reserved 6560 MiB at 0x200e6200 ubuntu@tiselius:~$ root@tiselius:/home/ubuntu# echo 1 > /proc/sys/kernel/sysrq root@tiselius:/home/ubuntu# echo c > /proc/sysrq-trigger tiselius login: [ 150.167288] cloud-init[4529]: Cloud-init v. 19.1-1-gbaa47854-0ubuntu1~18.10.1 running 'modules:final' at Mon, 10 Jun 2019 19:53:40 +. Up 149.80 seconds. [ 150.167687] cloud-init[4529]: Cloud-init v. 19.1-1-gbaa47854-0ubuntu1~18.10.1 finished at Mon, 10 Jun 2019 19:53:40 +. Datasource DataSourceMAAS [http://10-245-64-0--21.maas-internal:5248/MAAS/metadata/]. Up 150.11 seconds [ 360.313029] kdump-tools[4915]: Stopping kdump-tools: * unloaded kdump kernel [ 376.552452] kdump-tools[10449]: Starting kdump-tools: * Creating symlink /var/lib/kdump/vmlinuz [ 376.553743] kdump-tools[10449]: * Creating symlink /var/lib/kdump/initrd.img [ 376.585085] kdump-tools[10449]: Modified cmdline:root=UUID=295f571b-b731-4ebb-b752-60aadc80fc1b ro console=hvc0 nr_cpus=1 systemd.unit=kdump-tools-dump.service irqpoll noirqdistrib nousb elfcorehdr=158784K [ 376.953223] kdump-tools[10449]: * loaded kdump kernel [ 398.517900] sysrq: SysRq : Trigger a crash [ 398.517952] Unable to handle kernel paging request for data at address 0x [ 398.518000] Faulting instruction address: 0xc082a3a8 [ 398.518071] Oops: Kernel access of bad area, sig: 11 [#1] [ 398.518115] LE SMP NR_CPUS=2048 NUMA PowerNV [ 398.518172] Modules linked in: joydev input_leds mac_hid vmx_crypto ofpart crct10dif_vpmsum ipmi_powernv ipmi_devintf at24 uio_pdrv_genirq ipmi_msghandler uio cmdlinepart powernv_flash mtd opal_prd ibmpowernv sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear ses enclosure scsi_transport_sas hid_generic usbhid hid ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm crc32c_vpmsum i40e aacraid drm_panel_orientation_quirks [ 398.518769] CPU: 0 PID: 10529 Comm: bash Kdump: loaded Not tainted 4.18.0-21-generic #22-Ubuntu [ 398.518881] NIP: c082a3a8 LR: c082b234 CTR: c082a380 [ 398.518976] REGS: c00b9b88ba00 TRAP: 0300 Not tainted (4.18.0-21-generic) [ 398.519068] MSR: 90009033 CR: 4842 XER: 2004 [ 398.519161] CFAR: c082b230 DAR: DSISR: 4200 IRQMASK: 0 [ 398.519161] GPR00: c082b234 c00b9b88bc80 c178ca00 0063 [ 398.519161] GPR04: 0001 036a 90009033 31c40058 [ 398.519161] GPR08: 0007 0001 90001003 [ 398.519161] GPR12: c082a380 c1b0 0a452fe89760
[Touch-packages] [Bug 1832257] Re: regression: sudo returns exit code 0 if child is killed with SIGTERM
Oh wow, I'm not sure how that happened. I'll release an update for this. ** Changed in: sudo (Ubuntu) Status: New => Confirmed ** Changed in: sudo (Ubuntu) Assignee: (unassigned) => Marc Deslauriers (mdeslaur) ** Also affects: sudo (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: sudo (Ubuntu) Status: Confirmed => Fix Released ** Changed in: sudo (Ubuntu Xenial) Status: New => Confirmed ** Changed in: sudo (Ubuntu Xenial) Assignee: (unassigned) => Marc Deslauriers (mdeslaur) ** Changed in: sudo (Ubuntu Xenial) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1832257 Title: regression: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Xenial: Confirmed Bug description: hey there- it looks like we accidentally removed the patch that fixed this problem when releasing sudo 1.8.16-0ubuntu1.6 - https://git.launchpad.net/ubuntu/+source/sudo/commit/?h=ubuntu/xenial- updates=15345b19b82f587498573b38554e24ec0ab816cb note that `terminate-with-commands-signal.patch` is removed from debian/patches/series in that commit and the behavior described in the original bug (LP 1686803) has returned in xenial. can we get this back into the current sudo package? the fix still exists upstream so it feels like this was an accidental reversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1832257/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832258] [NEW] Need to backport fix for inability to add Canon printers
Public bug reported: The following bug was reported and fixed in cups 2.2.11. https://github.com/apple/cups/issues/5484 Without the fix, it is not possible to add or use a number of Canon printers. Currently, 19.04 ships with 2.2.10 + some backports, but those backports do not include the fix for this problem. We either need the fix backported or an update to 2.2.11. Release: Ubuntu 19.04 Version: 2.2.10-4ubuntu2 What you expected: Adding a canon printer works What happened instead: Adding a canon printer fails with a useless error and log investigation lead to upstream issue. ** Affects: cups Importance: Unknown Status: Unknown ** Affects: cups (Ubuntu) Importance: Undecided Status: New ** Bug watch added: github.com/apple/cups/issues #5484 https://github.com/apple/cups/issues/5484 ** Also affects: cups via https://github.com/apple/cups/issues/5484 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1832258 Title: Need to backport fix for inability to add Canon printers Status in CUPS: Unknown Status in cups package in Ubuntu: New Bug description: The following bug was reported and fixed in cups 2.2.11. https://github.com/apple/cups/issues/5484 Without the fix, it is not possible to add or use a number of Canon printers. Currently, 19.04 ships with 2.2.10 + some backports, but those backports do not include the fix for this problem. We either need the fix backported or an update to 2.2.11. Release: Ubuntu 19.04 Version: 2.2.10-4ubuntu2 What you expected: Adding a canon printer works What happened instead: Adding a canon printer fails with a useless error and log investigation lead to upstream issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1832258/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832257] [NEW] regression: sudo returns exit code 0 if child is killed with SIGTERM
Public bug reported: hey there- it looks like we accidentally removed the patch that fixed this problem when releasing sudo 1.8.16-0ubuntu1.6 - https://git.launchpad.net/ubuntu/+source/sudo/commit/?h=ubuntu/xenial- updates=15345b19b82f587498573b38554e24ec0ab816cb note that `terminate-with-commands-signal.patch` is removed from debian/patches/series in that commit and the behavior described in the original bug (LP 1686803) has returned in xenial. can we get this back into the current sudo package? the fix still exists upstream so it feels like this was an accidental reversion. ** Affects: sudo (Ubuntu) Importance: Undecided Status: New ** Tags: regression-release -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1832257 Title: regression: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo package in Ubuntu: New Bug description: hey there- it looks like we accidentally removed the patch that fixed this problem when releasing sudo 1.8.16-0ubuntu1.6 - https://git.launchpad.net/ubuntu/+source/sudo/commit/?h=ubuntu/xenial- updates=15345b19b82f587498573b38554e24ec0ab816cb note that `terminate-with-commands-signal.patch` is removed from debian/patches/series in that commit and the behavior described in the original bug (LP 1686803) has returned in xenial. can we get this back into the current sudo package? the fix still exists upstream so it feels like this was an accidental reversion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1832257/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1686803] Re: sudo returns exit code 0 if child is killed with SIGTERM
scratch that, this was a regression in -ubuntu16, will open another ticket -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1686803 Title: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo: Unknown Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Xenial: Fix Released Status in sudo source package in Yakkety: Won't Fix Status in sudo source package in Zesty: Fix Released Status in sudo source package in Artful: Fix Released Bug description: [Impact] * sudo returns exit code 0 if child is killed with signals other than SIGINT * This can break scripts assuming successful execution of the command ran by sudo [Test Case] * Open two separate shells 1. In shell 1. run: ubuntu@tough-calf:~$ sudo sleep 300; echo $? 2. In shell 2. run: root@tough-calf:~# killall -TERM sleep 3. In broken versions shell 1. shows this: ubuntu@tough-calf:~$ sudo sleep 300; echo $? 0 4. Install fixed version 5. Execute steps 1. and 2. 6. In fixed version shell 1. shows this: ubuntu@tough-calf:~$ sudo sleep 300; echo $? Terminated 143 [Regression Potential] * sudo may exit with a different status than expected [Other Info] original bug description: Please backport upstream sudo changeset 10917:50b988d0c97f "The fix for Bug #722 contained a typo/thinko that resulted in the" to xenial, yakkety, and zesty versions of sudo. This will fix a regression documented by this upstream bug report: https://bugzilla.sudo.ws/show_bug.cgi?id=784 sudo 1.8.15 changeset 10229:153f016db8f1 "When the command sudo is running is killed by a signal, sudo will" introduced a regression where the exit status is always 0 when a command is killed by a signal other than SIGINT. https://www.sudo.ws/repos/sudo/rev/153f016db8f1 This will be fixed in sudo 1.8.20 with changeset 10917:50b988d0c97f "The fix for Bug #722 contained a typo/thinko that resulted in the". https://www.sudo.ws/repos/sudo/rev/50b988d0c97f trusty sudo is based off sudo 1.8.9 and is not affected. xenial sudo based off sudo 1.8.16, yaketty sudo based off sudo 1.8.16, and zesty sudo based off 1.8.19 need the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/sudo/+bug/1686803/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1686803] Re: sudo returns exit code 0 if child is killed with SIGTERM
Hey, I'm not sure this was ever fixed in Xenial. Seems to still be bad. `pwoodman@iad4c-ra16-40b:~$ sudo sleep 300; echo $? 0 pwoodman@iad4c-ra16-40b:~$ sleep 300; echo $? Terminated 143 pwoodman@iad4c-ra16-40b:~$ apt-cache policy sudo sudo: Installed: 1.8.16-0ubuntu1.6 Candidate: 1.8.16-0ubuntu1.6 Version table: *** 1.8.16-0ubuntu1.6 500 500 http://apt-u16-iad.vip.dbxnw.net/annex-apt-xenial/apt/xenial xenial-security/main amd64 Packages 500 http://apt-u16-iad.vip.dbxnw.net/annex-apt-xenial/apt/xenial xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 1.8.16-0ubuntu1.3dbx11 500 500 http://apt-u16-iad.vip.dbxnw.net/annex-apt-dbx-xenial/apt/dbx-xenial dbx-xenial/main amd64 Packages 1.8.16-0ubuntu1 500 500 http://apt-u16-iad.vip.dbxnw.net/annex-apt-xenial/apt/xenial xenial/main amd64 Packages pwoodman@iad4c-ra16-40b:~$ sudo apt install sudo=1.8.16-0ubuntu1.3dbx11 Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libwireshark6 libwiretap5 libwsutil6 linux-headers-4.4.0-133 linux-headers-4.4.0-133-generic Use 'sudo apt autoremove' to remove them. The following packages will be DOWNGRADED: sudo 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 193 not upgraded. Need to get 1,003 kB of archives. After this operation, 1,268 kB of additional disk space will be used. Get:1 http://apt-u16-iad.vip.dbxnw.net/annex-apt-dbx-xenial/apt/dbx-xenial dbx-xenial/main amd64 sudo amd64 1.8.16-0ubuntu1.3dbx11 [1,003 kB] Fetched 1,003 kB in 0s (14.7 MB/s) dpkg: warning: downgrading sudo from 1.8.16-0ubuntu1.6 to 1.8.16-0ubuntu1.3dbx11 (Reading database ... 327971 files and directories currently installed.) Preparing to unpack .../sudo_1.8.16-0ubuntu1.3dbx11_amd64.deb ... Unpacking sudo (1.8.16-0ubuntu1.3dbx11) over (1.8.16-0ubuntu1.6) ... Processing triggers for man-db (2.7.5-1) ... Setting up sudo (1.8.16-0ubuntu1.3dbx11) ... pwoodman@iad4c-ra16-40b:~$ sleep 300; echo $? Terminated 143 pwoodman@iad4c-ra16-40b:~$ sudo sleep 300; echo $? Terminated 143``` that other package is our own local fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1686803 Title: sudo returns exit code 0 if child is killed with SIGTERM Status in sudo: Unknown Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Xenial: Fix Released Status in sudo source package in Yakkety: Won't Fix Status in sudo source package in Zesty: Fix Released Status in sudo source package in Artful: Fix Released Bug description: [Impact] * sudo returns exit code 0 if child is killed with signals other than SIGINT * This can break scripts assuming successful execution of the command ran by sudo [Test Case] * Open two separate shells 1. In shell 1. run: ubuntu@tough-calf:~$ sudo sleep 300; echo $? 2. In shell 2. run: root@tough-calf:~# killall -TERM sleep 3. In broken versions shell 1. shows this: ubuntu@tough-calf:~$ sudo sleep 300; echo $? 0 4. Install fixed version 5. Execute steps 1. and 2. 6. In fixed version shell 1. shows this: ubuntu@tough-calf:~$ sudo sleep 300; echo $? Terminated 143 [Regression Potential] * sudo may exit with a different status than expected [Other Info] original bug description: Please backport upstream sudo changeset 10917:50b988d0c97f "The fix for Bug #722 contained a typo/thinko that resulted in the" to xenial, yakkety, and zesty versions of sudo. This will fix a regression documented by this upstream bug report: https://bugzilla.sudo.ws/show_bug.cgi?id=784 sudo 1.8.15 changeset 10229:153f016db8f1 "When the command sudo is running is killed by a signal, sudo will" introduced a regression where the exit status is always 0 when a command is killed by a signal other than SIGINT. https://www.sudo.ws/repos/sudo/rev/153f016db8f1 This will be fixed in sudo 1.8.20 with changeset 10917:50b988d0c97f "The fix for Bug #722 contained a typo/thinko that resulted in the". https://www.sudo.ws/repos/sudo/rev/50b988d0c97f trusty sudo is based off sudo 1.8.9 and is not affected. xenial sudo based off sudo 1.8.16, yaketty sudo based off sudo 1.8.16, and zesty sudo based off 1.8.19 need the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/sudo/+bug/1686803/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted
** Tags added: 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/1818527 Title: Stub resolver cache is corrupted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Bug description: [Impact] systemd-resolved fails to resolve A records [Description] When systemd-resolve caches a non-existent CNAME record for a specific domain, further attempts at resolving A records for that same domain fail. This has been fixed upstream in v240. Upstream commit: https://github.com/systemd/systemd/commit/3740146a4cbd $ git describe --contains 3740146a4cbd v240~839 $ rmadison systemd --arch amd64 systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.21 | xenial-security | source, ... systemd | 229-4ubuntu21.21 | xenial-updates | source, ... systemd | 237-3ubuntu10| bionic | source, ... systemd | 237-3ubuntu10.19 | bionic-security | source, ... systemd | 237-3ubuntu10.21 | bionic-updates | source, ... systemd | 237-3ubuntu10.22 | bionic-proposed | source, ... systemd | 239-7ubuntu10| cosmic | source, ... systemd | 239-7ubuntu10.12 | cosmic-security | source, ... systemd | 239-7ubuntu10.13 | cosmic-updates | source, ... systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ... systemd | 240-6ubuntu5 | disco | source, ... systemd | 240-6ubuntu5.1 | disco-proposed | source, ... systemd | 240-6ubuntu9 | eoan| source, ... Despite the package versions above, only Bionic is affected. Cosmic already includes a backported fix, and Xenial doesn't seem affected due to resolvconf handling DNS resolution. [Test Case] Flush resolved's caches and try resolving a non-existent CNAME record. Further resolution attempts for the corresponding A record will fail: $ systemd-resolve --flush-caches $ dig github.com CNAME $ dig github.com A [Regression Potential] The regression potential for this fix should be very low, as it's a direct cherry-pick from upstream systemd. It has seen extensive testing in both upstream and other Ubuntu releases, and was verified for Bionic through autopkgtests. [Original Description] It seems that when systemd-resolve cache an non-existent CNAME record for a domain, any attempt to resolve A record for the same domain fail. systemd version the issue has been seen with Installed: 237-3ubuntu10.13 Used distribution Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic Expected behaviour you didn't see Return A record for a domain when it exists. Unexpected behaviour you saw Resolution failed. Steps to reproduce the problem Whait for 1 minutes (github.com TTL for A record) Try to resolv github.com CNAME record dig CNAME github.com This will return an empty result. Then try to resolve github.com A record dig A github.com. This will now return empty result unless you restart systemd-resolved or wait for cache expiration. At the same time using another DNS will resolve correctly dig A github.com @8.8.8.8. Exemple : Wait for 1 minutes to let cache expire, then run dig CNAME github.com dig A github.com # no result dig A github.com @8.8.8.8 # ;; ANSWER SECTION: # github.com. 59 IN A 192.30.253.113 # github.com. 59 IN A 192.30.253.112 PS: Don't forget to restart systemd-resolve, before trying to post an answer. This bug was first reported in github https://github.com/systemd/systemd/issues/11789 but systemd version in ubuntu is too old. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828892] Re: systemctl - alias service reports inactive while aliased is active
** Tags added: 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/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
This was fixed in systemd 237-3ubuntu10.22 for bionic, and 239-7ubuntu10.14 for cosmic. I missed a "#" in the changelog (sorry) so the tooling didn't automatically mark this bug as fix released. ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: systemd (Ubuntu Cosmic) Status: Fix Committed => Fix Released ** Tags removed: ddstreet-next -- 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/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Won't Fix Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830477] Re: systemd-fsckd, cmdline-upstart-boot tests fail on xenial s390x
** Tags added: 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/1830477 Title: systemd-fsckd, cmdline-upstart-boot tests fail on xenial s390x Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Bug description: [impact] these tests require, and modify, grub. That fails on s390x on xenial because it does not use grub. [test case] run the autopkgtests for xenial on s390x [regression potential] low; only skipping test cases on s390x. [other info] in bionic and later, systemd-fsckd has support for zipl (s390x bootloader) and cmdline-upstart-boot is removed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830477/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1831459] Re: 'storage' test needs to wait for systemd-cryptsetup to be active before stopping it
** Tags added: 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/1831459 Title: 'storage' test needs to wait for systemd-cryptsetup to be active before stopping it Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Released Bug description: [impact] test case fails because it does not wait for the service to become active before stopping it, resulting in failure to rmmod the scsi_debug module because it's still in use. [test case] check 'storage' test results for systemd in autopkgtest logs, e.g.: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/ppc64el/s/systemd/20190601_160043_a5281@/log.gz [regression potential] low; test case fix only. [other info] detected and reported by @cascardo in bug 1814373 comment 4 and 5, but separate (non-test) systemd bugfix uploaded for that bug so opening this bug to track fixing the test case. larger fixes/improvements to 'storage' testcase in bug 1829347, but those rejected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831459/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Hello Dimitri, or anyone else affected,
Accepted python-tornado into bionic-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/python-
tornado/4.5.3-1ubuntu0.1 in a few hours, and then in the -proposed
repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Description changed:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be
rapidly adopted due to increased set of supported hashes & algoes, as
well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software
is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g.
mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be unavoidable
with introducing TLS v1.3. However, tests on cosmic demonstrate that
curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3
without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side software
or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn how
to use session callback.
- non-application data records. TLSv1.3 sends more of these, when compared
with previous versions, and some applications may not handle this correctly.
Resulting in application data not being available, when previously expected.
Mitigation
[Touch-packages] [Bug 1828215] Re: openssl ca -spkac output regressed
reset index.txt, and resigned pkac with upgraded openssl in eoan, the output is pure text and can be read/parsed by humans and machines. -- 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/1828215 Title: openssl ca -spkac output regressed Status in OpenSSL: Fix Released Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: Confirmed Status in openssl source package in Cosmic: Confirmed Status in openssl source package in Disco: Confirmed Status in openssl source package in Eoan: Fix Committed Bug description: [Impact] * openssl command line utility option parsing has regressed in 1.1.0i+ and produces binary output, where text output is expected, breaking applications that parse that. [Test Case] * OPENSSL_ENABLE_MD5_VERIFY=1 openssl ca -config test.openssl.cnf -passin stdin -batch -spkac input_file -startdate 190121130654Z Currently produces binary goop. Should produce PEM format Base64 encoded certificate data in a block surrounded with BEGIN/END certificate. [Regression Potential] * This is a regression in cosmic and up, and impeding regression in bionic with the upcoming 1.1.1 SRU. A bugfix exists upstream. [Other Info] * Originally reported https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/39 To manage notifications about this bug go to: https://bugs.launchpad.net/openssl/+bug/1828215/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 508522] Re: Mic is not available with A2DP Bluetooth profile
Disappointing that 9 years on this is still an issue. If I have A2DP Sink selected I have no Mic option, and if I use HSP/HFP the audio quality sounds like it's being played down a 14.4K modem; you might as well not have audio as it's just going to cause your ears to bleed. -- 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/508522 Title: Mic is not available with A2DP Bluetooth profile Status in pulseaudio package in Ubuntu: Confirmed Bug description: Binary package hint: pulseaudio I'm testing a Nokia BH-905i headset (see http://www.wissel.net/blog/d6plinks/SHWL-8AZGGF ) on Ubuntu 10.10. The Bluetooth module correctly identifies the headset and the both audio profiles "HSP/ HFP Telephony duplex" and "A2DP High Fidelity Playback". For music playback only A2DP is suitable (HSP/HFP sounds like listening to music played through an old telephone). A2DP does not have an INPUT mode, so use of the headset for VoiP isn't possible. What would be needed is a separate selection to allow to select A2DP for output and HSP/HFP for input. Smartphones (a lot of them *nix based) phones do that (or they switch on the fly?). Formal structure: 1) Ubuntu 10.10 2) Pulse-Audio 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 consisting og pluseaudio, pulseaudio-esound-compat, pulseaudio-module-bluetooth, pulseaudio-module-gconf, pulseaudio-module-x11, pulseaudio-utils 3) Select high quality audio output and still use the Bluetooth microphone 4) Had to choose: either high quality audio or "telephone quality" with microphone I can change the profile without the Bluetooth connection dropping, but that's ridiculous. E.g. listening to music, a call comes in. Then I would need to switch the profile before answering. Please note that in Windows, Mac OS, iOS, Android, and Windows Mobile it's done automatically. Check out attached screencast. ProblemType: Bug AplayDevices: List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 Architecture: i386 ArecordDevices: List of CAPTURE Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: oivasyuv 2309 F pulseaudio Card0.Amixer.info: Card hw:0 'Intel'/'HDA Intel at 0xd850 irq 17' Mixer name : 'Analog Devices AD1984A' Components : 'HDA:11d4194a,103c30e8,00100400' Controls : 22 Simple ctrls : 14 Date: Sat Jan 16 22:31:41 2010 DistroRelease: Ubuntu 9.10 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) Package: pulseaudio 1:0.9.19-0ubuntu4 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-17.54-generic-pae SourcePackage: pulseaudio Uname: Linux 2.6.31-17-generic-pae i686 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/508522/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828215] Re: openssl ca -spkac output regressed
** Changed in: openssl (Ubuntu Eoan) Status: Confirmed => Fix Committed -- 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/1828215 Title: openssl ca -spkac output regressed Status in OpenSSL: Fix Released Status in openssl package in Ubuntu: Fix Committed Status in openssl source package in Bionic: Confirmed Status in openssl source package in Cosmic: Confirmed Status in openssl source package in Disco: Confirmed Status in openssl source package in Eoan: Fix Committed Bug description: [Impact] * openssl command line utility option parsing has regressed in 1.1.0i+ and produces binary output, where text output is expected, breaking applications that parse that. [Test Case] * OPENSSL_ENABLE_MD5_VERIFY=1 openssl ca -config test.openssl.cnf -passin stdin -batch -spkac input_file -startdate 190121130654Z Currently produces binary goop. Should produce PEM format Base64 encoded certificate data in a block surrounded with BEGIN/END certificate. [Regression Potential] * This is a regression in cosmic and up, and impeding regression in bionic with the upcoming 1.1.1 SRU. A bugfix exists upstream. [Other Info] * Originally reported https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/39 To manage notifications about this bug go to: https://bugs.launchpad.net/openssl/+bug/1828215/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828215] Re: openssl ca -spkac output regressed
Follow roughly https://blog.felipe-alfaro.com/2005/11/18/setting-up- certificate-authority-ca-using-openssl/ to setup CA Generate req & spkac => however somehow my spkac only had the SPKAC= line so I had to edit in: countryName=AU stateOrProvinceName=Some-State organizationName=Internet Widgits Pty Ltd commonName=foo To make it a valid spkac for batch processing. Then yeah the batch command generates binary garbage to stdout. -- 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/1828215 Title: openssl ca -spkac output regressed Status in OpenSSL: Fix Released Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Bionic: Confirmed Status in openssl source package in Cosmic: Confirmed Status in openssl source package in Disco: Confirmed Status in openssl source package in Eoan: Confirmed Bug description: [Impact] * openssl command line utility option parsing has regressed in 1.1.0i+ and produces binary output, where text output is expected, breaking applications that parse that. [Test Case] * OPENSSL_ENABLE_MD5_VERIFY=1 openssl ca -config test.openssl.cnf -passin stdin -batch -spkac input_file -startdate 190121130654Z Currently produces binary goop. Should produce PEM format Base64 encoded certificate data in a block surrounded with BEGIN/END certificate. [Regression Potential] * This is a regression in cosmic and up, and impeding regression in bionic with the upcoming 1.1.1 SRU. A bugfix exists upstream. [Other Info] * Originally reported https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/39 To manage notifications about this bug go to: https://bugs.launchpad.net/openssl/+bug/1828215/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832031] Re: No sound on external Samsung Monitor via Display Port/HDMI
** Package changed: ubuntu => pulseaudio (Ubuntu) -- 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/1832031 Title: No sound on external Samsung Monitor via Display Port/HDMI Status in pulseaudio package in Ubuntu: New Bug description: Hello, I have two external monitor connected via a Dell TB16 (thunderbolt). One is a Samsung T28C570 and the other one is a Samsung CF791. The first one is connected via HDMI. The second one is connected via Display Port. The problem is that sound on Samsung CF791 doesn't work. I know it's not a mixer problem because: 1) Sometime, If i press CTRL+ALT+F2 (to enter in console mode) and then go back on Desktop with CTRL+ALT+F1 i can heard sound from the monitor when I increase or decrease volume, even if a little bit distorted. Nevertheless, if I try to play a video (for example youtube), sound stops to work. I have to stop any audio stream, return to console mode and back again in desktop to hear again distorted sound then increase volume. 2) On Windows, I have no problem (so it seems not to be an hardware issue). I tried to connect the CF791 via HDMI, but problem persist. I have no problem with the other monitor. I have checked every alsamixer e pavucontrol settings unsuccessful. My laptop is a Dell XPS 13. Description:Ubuntu 18.04.2 LTS Release:18.04 THe HDMI2 is the not working audio device: Lista di PLAYBACK dispositivi hardware scheda 0: PCH [HDA Intel PCH], dispositivo 0: ALC3271 Analog [ALC3271 Analog] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 3: HDMI 0 [HDMI 0] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 7: HDMI 1 [HDMI 1] Sottoperiferiche: 0/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 8: HDMI 2 [HDMI 2] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 9: HDMI 3 [HDMI 3] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 10: HDMI 4 [HDMI 4] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 1: Dock [WD15 Dock], dispositivo 0: USB Audio [USB Audio] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 1: Dock [WD15 Dock], dispositivo 1: USB Audio [USB Audio #1] Sottoperiferiche: 1/1 Hardware list: 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08) 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07) 00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 08) 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21) 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21) 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21) 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21) 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1) 00:1c.2 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f1) 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1) 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1) 00:1f.0 ISA bridge: Intel Corporation Intel(R) 100 Series Chipset Family LPC Controller/eSPI Controller - 9D4E (rev 21) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21) 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01) 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 03:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 05:00.0 System peripheral: Intel Corporation JHL6540
[Touch-packages] [Bug 1832031] [NEW] No sound on external Samsung Monitor via Display Port/HDMI
You have been subscribed to a public bug: Hello, I have two external monitor connected via a Dell TB16 (thunderbolt). One is a Samsung T28C570 and the other one is a Samsung CF791. The first one is connected via HDMI. The second one is connected via Display Port. The problem is that sound on Samsung CF791 doesn't work. I know it's not a mixer problem because: 1) Sometime, If i press CTRL+ALT+F2 (to enter in console mode) and then go back on Desktop with CTRL+ALT+F1 i can heard sound from the monitor when I increase or decrease volume, even if a little bit distorted. Nevertheless, if I try to play a video (for example youtube), sound stops to work. I have to stop any audio stream, return to console mode and back again in desktop to hear again distorted sound then increase volume. 2) On Windows, I have no problem (so it seems not to be an hardware issue). I tried to connect the CF791 via HDMI, but problem persist. I have no problem with the other monitor. I have checked every alsamixer e pavucontrol settings unsuccessful. My laptop is a Dell XPS 13. Description:Ubuntu 18.04.2 LTS Release:18.04 THe HDMI2 is the not working audio device: Lista di PLAYBACK dispositivi hardware scheda 0: PCH [HDA Intel PCH], dispositivo 0: ALC3271 Analog [ALC3271 Analog] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 3: HDMI 0 [HDMI 0] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 7: HDMI 1 [HDMI 1] Sottoperiferiche: 0/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 8: HDMI 2 [HDMI 2] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 9: HDMI 3 [HDMI 3] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 0: PCH [HDA Intel PCH], dispositivo 10: HDMI 4 [HDMI 4] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 1: Dock [WD15 Dock], dispositivo 0: USB Audio [USB Audio] Sottoperiferiche: 1/1 Sottoperiferica #0: subdevice #0 scheda 1: Dock [WD15 Dock], dispositivo 1: USB Audio [USB Audio #1] Sottoperiferiche: 1/1 Hardware list: 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08) 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07) 00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 08) 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21) 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21) 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21) 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21) 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1) 00:1c.2 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f1) 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1) 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1) 00:1f.0 ISA bridge: Intel Corporation Intel(R) 100 Series Chipset Family LPC Controller/eSPI Controller - 9D4E (rev 21) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21) 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01) 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 03:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 04:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) 05:00.0 System peripheral: Intel Corporation JHL6540 Thunderbolt 3 NHI (C step) [Alpine Ridge 4C 2016] (rev 02) 3a:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015] 3b:01.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015] 3b:04.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015] 3d:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015] 3e:01.0 PCI bridge: Intel
[Touch-packages] [Bug 458476] Re: /etc/init.d/ssh gives OK status even if daemon fails to launch
(if this is wrong, then please provide steps to reproduce on a current Ubuntu release and reopen) ** Changed in: openssh (Ubuntu) Status: New => Fix Released ** Changed in: lsb (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/458476 Title: /etc/init.d/ssh gives OK status even if daemon fails to launch Status in lsb package in Ubuntu: Invalid Status in openssh package in Ubuntu: Fix Released Bug description: Binary package hint: lsb lsb-base: /lib/lsb/init-functions appears to let the script /etc/init.d/ssh, from package openssh-server, continue with status OK even if the daemon fails to launch. I can run the script, but no sshd is launched: $ sudo /etc/init.d/ssh start * Starting OpenBSD Secure Shell server sshd [ OK ] $ pgrep -l sshd || echo Not There Not There If I launch sshd manually, it gives me a proper error message: sudo /usr/sbin/sshd -Dd debug1: sshd version OpenSSH_5.1p1 Debian-6ubuntu1 [snip] debug1: Bind to port 22 on 192.168.0.5. Bind to port 22 on 192.168.0.5 failed: Cannot assign requested address. I expect that in such a situation /etc/init.d/ssh should show an error, something like this: $ sudo /etc/init.d/ssh start * Starting OpenBSD Secure Shell server sshd [ FAIL] Starting sshd failed : Bind to port 22 on 192.168.0.5 failed: Cannot assign requested address. $ apt-cache policy lsb-base lsb-base: Installed: 4.0-0ubuntu5 Candidate: 4.0-0ubuntu5 Version table: *** 4.0-0ubuntu5 0 500 http://fi.archive.ubuntu.com karmic/main Packages 100 /var/lib/dpkg/status $ lsb_release -rd Description:Ubuntu 9.10 Release:9.10 If someone misconfigures the server and then uses /etc/init.d/ssh to restart the server. They will get locked out (aka denial of service) if they did not plan carefully enough to test which processes are running, that's not something your average sysadmin should be expected to do. The script should work... ProblemType: Bug Architecture: i386 Date: Thu Oct 22 22:21:28 2009 DistroRelease: Ubuntu 9.10 Package: lsb-base 4.0-0ubuntu5 PackageArchitecture: all ProcEnviron: SHELL=/bin/bash PATH=(custom, no user) LANG=en_US.UTF-8 LANGUAGE= ProcVersionSignature: Ubuntu 2.6.31-14.48-generic SourcePackage: lsb Uname: Linux 2.6.31-14-generic i686 XsessionErrors: (polkit-gnome-authentication-agent-1:2635): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/458476/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832227] Re: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Thank you for taking the time to report this bug and helping to make Ubuntu better. Reviewing your dmesg attachment in this bug report it seems that there is a problem with your hardware. I recommend performing a back up and then investigating the situation. Measures you might take include checking cable connections and using software tools to investigate the health of your hardware. In the event that is is not in fact an error with your hardware please set the bug's status back to New. Thanks and good luck! [This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.] ** Tags added: hardware-error ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Low ** Changed in: initramfs-tools (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1832227 Title: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Status in initramfs-tools package in Ubuntu: Invalid Bug description: está aparecendo várias vezes a mensagem de erro no sistema. não sei especificar qual erro ocorre. ProblemType: Package DistroRelease: Ubuntu 16.04 Package: linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 ProcVersionSignature: Ubuntu 4.15.0-51.55~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-51-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Thu Jun 6 06:53:20 2019 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 InstallationDate: Installed on 2019-04-28 (42 days ago) InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 (20180228) RelatedPackageVersions: dpkg 1.18.4ubuntu1.5 apt 1.2.31 SourcePackage: initramfs-tools Title: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1832227/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 458476] Re: /etc/init.d/ssh gives OK status even if daemon fails to launch
I can't reproduce this on Eoan, so I believe this problem is fixed. In particular, since the init.d handling was overhauled when systemd was introduced, it is likely that the code responsible has completely changed and this bug no longer exists. I'm marking as Fix Released accordingly. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/458476 Title: /etc/init.d/ssh gives OK status even if daemon fails to launch Status in lsb package in Ubuntu: Invalid Status in openssh package in Ubuntu: Fix Released Bug description: Binary package hint: lsb lsb-base: /lib/lsb/init-functions appears to let the script /etc/init.d/ssh, from package openssh-server, continue with status OK even if the daemon fails to launch. I can run the script, but no sshd is launched: $ sudo /etc/init.d/ssh start * Starting OpenBSD Secure Shell server sshd [ OK ] $ pgrep -l sshd || echo Not There Not There If I launch sshd manually, it gives me a proper error message: sudo /usr/sbin/sshd -Dd debug1: sshd version OpenSSH_5.1p1 Debian-6ubuntu1 [snip] debug1: Bind to port 22 on 192.168.0.5. Bind to port 22 on 192.168.0.5 failed: Cannot assign requested address. I expect that in such a situation /etc/init.d/ssh should show an error, something like this: $ sudo /etc/init.d/ssh start * Starting OpenBSD Secure Shell server sshd [ FAIL] Starting sshd failed : Bind to port 22 on 192.168.0.5 failed: Cannot assign requested address. $ apt-cache policy lsb-base lsb-base: Installed: 4.0-0ubuntu5 Candidate: 4.0-0ubuntu5 Version table: *** 4.0-0ubuntu5 0 500 http://fi.archive.ubuntu.com karmic/main Packages 100 /var/lib/dpkg/status $ lsb_release -rd Description:Ubuntu 9.10 Release:9.10 If someone misconfigures the server and then uses /etc/init.d/ssh to restart the server. They will get locked out (aka denial of service) if they did not plan carefully enough to test which processes are running, that's not something your average sysadmin should be expected to do. The script should work... ProblemType: Bug Architecture: i386 Date: Thu Oct 22 22:21:28 2009 DistroRelease: Ubuntu 9.10 Package: lsb-base 4.0-0ubuntu5 PackageArchitecture: all ProcEnviron: SHELL=/bin/bash PATH=(custom, no user) LANG=en_US.UTF-8 LANGUAGE= ProcVersionSignature: Ubuntu 2.6.31-14.48-generic SourcePackage: lsb Uname: Linux 2.6.31-14-generic i686 XsessionErrors: (polkit-gnome-authentication-agent-1:2635): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/458476/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832110] Re: Resource Sharing with multiple sshd services
Thank you for taking the time to file this bug and helping to make Ubuntu better. > ...the problem is getting Ubuntu and OpenSSH to admit there is a problem and it needs to be fixed. It's up to individual projects to decide what configurations they want to support. Just because you can't configure your system to your exact specification doesn't necessarily mean that it's a problem for the project. I understand what you're requesting, but I don't think Ubuntu will be prepared to maintain a patch in sshd to make the privilege separation directory configurable, assuming that upstream don't wish to do this either. It may that there's something I'm missing and the problem can be fixed in Ubuntu, but you haven't relayed the message from upstream so I am unable to comment on that. If you'd like to expand on why exactly they think "it is a Ubuntu problem", then I can look again. As I don't think Ubuntu will maintain the type of patch you suggest, I'm marking this bug as Won't Fix against the Ubuntu openssh package. You might be able to use mount namespaces to give your different sshd processes different views of /run/sshd. However, please note that you can simply comment if you have further information that you think would change this opinion, and change the status back to New yourself to request reconsideration. No need to file a new bug. ** Changed in: openssh (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1832110 Title: Resource Sharing with multiple sshd services Status in openssh package in Ubuntu: Won't Fix Bug description: Ubuntu: 18.04.2 LTS OpenSSH: 7.6p1 I am having a problem starting multiple sshd processes. The default location of the sshd privilege separation directory is hard-coded to /run/sshd (see man page). If I want to have 2 sshd services using systemd, I need to write 2 service files, let's call them sshd_wan.service ans sshd_lan.service. Both of these services need to have their own "RuntimeDirectory=sshd_wan" and "RuntimeDirectory=sshd_lan". If you do not have separate RuntimeDirectory definitions for the 2 services, then when one service is killed/faults/restarts/stops/etc. the systemd (or init) process deletes the RuntimeDirectory and causes the other service to crash since a RuntimeDirectory does not exist. The problem is the hard-coding of the sshd Privilege Separation Directory. We need to modify the OpenBSD/OpenSSH sshd code to provision command line assignment of the privilege separation directory. I have attempted to contact the OpenSSH team (i.e. OpenSSH.com) and they say it is a Ubuntu problem. I reported this in Ubuntu bug #1831765 and Ubuntu (e.g. Paride Legovini, June 6, 2019 @ 2:55AM PDT) rejected it because I described the problem using the init.d example. I know how to modify the sshd.c file in OpenSSH 7.6p1, the problem is getting Ubuntu and OpenSSH to admit there is a problem and it needs to be fixed. The problem is still there regardless if you are using Upstart (i.e. init.d) or systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1832110/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package libio-socket-ssl-perl -
2.060-3~ubuntu18.04.1
---
libio-socket-ssl-perl (2.060-3~ubuntu18.04.1) bionic; urgency=medium
* Backport 2.060 to 18.04 LTS with TLSv1.3 support. LP: #1797386
Includes:
- upstream TLSv1.3 support
- testsuite fixes to ignore SIGPIPE
- depedencies adjusted to match SRUed version numbers
- reverted superflorious changes to metadata/debhelper compat
* Add breaks on hanging libwww-perl with TLSv1.3
-- Dimitri John Ledkov Tue, 11 Dec 2018 11:52:12
+1100
** Changed in: libnet-ssleay-perl (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package python3.7 - 3.7.3-2~18.04.1
---
python3.7 (3.7.3-2~18.04.1) bionic; urgency=medium
* Rebuild with OpenSSL 1.1.1. LP: #1797386
-- Dimitri John Ledkov Wed, 03 Apr 2019 20:16:38
+0100
** Changed in: ruby2.5 (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn how
to use session callback.
- non-application data records. TLSv1.3 sends more of these, when compared
with previous versions, and some
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package libnet-ssleay-perl - 1.84-1ubuntu0.1
---
libnet-ssleay-perl (1.84-1ubuntu0.1) bionic; urgency=medium
* Cherrypick patches prepared by Damyan Ivanov from 1.85-2 for OpenSSL
1.1.1 support (LP: #1797386):
+ add five patches from fedora
+ patch openssl version check about SSL_CTX_set_num_tickets existence
+ add SSL[_CTX]_(set|get)_security_level routines
+ tests: set security level to 1 when loading certificates with small keys
+ patch set_cert_and_key to not return error when none of the underlying
routines does
-- Dimitri John Ledkov Tue, 04 Dec 2018 14:05:51
+
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package python-cryptography - 2.1.4-1ubuntu1.3
---
python-cryptography (2.1.4-1ubuntu1.3) bionic; urgency=medium
* Rebuild against OpenSSL 1.1.1, cherrypick upstream testsuite fix for
1.1.1. LP: #1797386
-- Dimitri John Ledkov Mon, 17 Dec 2018 11:16:35
+1100
** Changed in: python3.7 (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn how
to use session callback.
- non-application data records. TLSv1.3
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package libwww-perl - 6.31-1ubuntu0.1
---
libwww-perl (6.31-1ubuntu0.1) bionic; urgency=medium
[ gregor herrmann ]
* Drop drop-non-blocking-socket.patch.
The patch is not only not needed anymore, it also causes troubles with
OpenSSL 1.1.1 (via IO::Socket::SSL).
Thanks to Guilhem Moulin (on the Debian side) and Steffen Ullrich
(IO::Socket::SSL upstream) for analysing the problem and tracking down the
real culprit.
(Closes: #914034) LP: #1797386
-- Dimitri John Ledkov Tue, 21 May 2019 09:55:53
+0100
** Changed in: libio-socket-ssl-perl (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package python2.7 - 2.7.15-4ubuntu4~18.04
---
python2.7 (2.7.15-4ubuntu4~18.04) bionic; urgency=medium
* Rebuild against OpenSSL 1.1.1. LP: #1797386
* Update to 2.7.15 final.
-- Dimitri John Ledkov Tue, 27 Nov 2018 23:36:35
+
** Changed in: python3.6 (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn how
to use session callback.
- non-application data records. TLSv1.3 sends more of these, when
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package openssl - 1.1.1-1ubuntu2.1~18.04.1
---
openssl (1.1.1-1ubuntu2.1~18.04.1) bionic; urgency=medium
* Backport OpenSSL 1.1.1 to 18.04 LTS. LP: #1797386
* Adjust Breaks on versions published in bionic-release.
openssl (1.1.1-1ubuntu2.1) cosmic-security; urgency=medium
* SECURITY UPDATE: timing side channel attack in DSA
- debian/patches/CVE-2018-0734-1.patch: fix mod inverse in
crypto/dsa/dsa_ossl.c.
- debian/patches/CVE-2018-0734-2.patch: fix timing vulnerability in
crypto/dsa/dsa_ossl.c.
- debian/patches/CVE-2018-0734-3.patch: add a constant time flag in
crypto/dsa/dsa_ossl.c.
- CVE-2018-0734
* SECURITY UPDATE: timing side channel attack in ECDSA
- debian/patches/CVE-2018-0735.patch: fix timing vulberability in
crypto/ec/ec_mult.c.
- CVE-2018-0735
openssl (1.1.1-1ubuntu2) cosmic; urgency=medium
* Fixup typpos in the autopkgtest binary name.
openssl (1.1.1-1ubuntu1) cosmic; urgency=medium
* Merge from Debian unstable, remaining changes:
- Replace duplicate files in the doc directory with symlinks.
- debian/libssl1.1.postinst:
+ Display a system restart required notification on libssl1.1
upgrade on servers.
+ Use a different priority for libssl1.1/restart-services depending
on whether a desktop, or server dist-upgrade is being performed.
- Revert "Enable system default config to enforce TLS1.2 as a
minimum" & "Increase default security level from 1 to 2".
- Further decrease security level from 1 to 0, for compatibility with
openssl 1.0.2.
openssl (1.1.1-1) unstable; urgency=medium
* New upstream version.
- Update symbol file for 1.1.1
- CVE-2018-0732 (actually since pre8).
* Add Breaks on python-httplib2 (Addresses: #907015)
* Add hardening=+all.
* Update to policy 4.2.1
- Less verbose testsuite with terse
- Use RRR=no
openssl (1.1.1~~pre9-1) unstable; urgency=medium
* New upstream version.
- Support the final TLS 1.3 version (RFC 8446)
* Upload to unstable
openssl (1.1.1~~pre8-1) experimental; urgency=medium
* New upstream version.
openssl (1.1.1~~pre7-1) experimental; urgency=medium
* Drop afalgeng on kfreebsd-* which go enabled because they inherit from
the linux target.
* Fix debian-rules-sets-dpkg-architecture-variable.
* Update to policy 4.1.4
- only Suggest: libssl-doc instead Recommends (only documentation and
example code is shipped).
- drop Priority: important.
- use signing-key.asc and a https links for downloads
* Use compat 11.
- this moves the examples to /usr/share/doc/libssl-{doc->dev}/demos but it
seems to make sense.
* Add a 25-test_verify.t for autopkgtest which runs against intalled
openssl binary.
* Fix CVE-2018-0737 (Closes: #895844).
openssl (1.1.1~~pre6-2) experimental; urgency=medium
* Update libssl1.1.symbols
openssl (1.1.1~~pre6-1) experimental; urgency=medium
* New upstream version
* Increase default security level from 1 to 2. This moves from the 80 bit
security level to the 112 bit securit level and will require 2048 bit RSA
and DHE keys.
openssl (1.1.1~~pre4-1) experimental; urgency=medium
* Update to 1.1.1-pre4 (Closes: #892276, #894282).
* Add riscv64 target (Closes: #891797).
openssl (1.1.1~~pre3-1) experimental; urgency=medium
* Update to 1.1.1-pre3
* Don't suggest 1024 bit RSA key to be typical (Closes: #878303).
* Don't insist on TLS1.3 cipher for Thu, 13 Dec 2018 14:02:15
+1100
** Changed in: python2.7 (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package ruby2.5 - 2.5.1-1ubuntu1.4
---
ruby2.5 (2.5.1-1ubuntu1.4) bionic; urgency=medium
* Cherrypick ruby-openssl upstream commits to fix compat with OpenSSL
1.1.1 LP: #1797386
-- Dimitri John Ledkov Tue, 23 Apr 2019 23:50:41
+0100
** Changed in: libwww-perl (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn how
to use session callback.
- non-application data records. TLSv1.3 sends more of these,
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package python3.6 - 3.6.8-1~18.04.1
---
python3.6 (3.6.8-1~18.04.1) bionic; urgency=medium
* Rebuild with OpenSSL 1.1.1. LP: #1797386
python3.6 (3.6.8-1) unstable; urgency=medium
* Python 3.6.8 release.
* Revert the link optimization changes which appeared after the
release candidate.
python3.6 (3.6.8~rc1-1) unstable; urgency=medium
* Python 3.6.8 release candidate 1.
* Update symbols files.
-- Dimitri John Ledkov Mon, 14 Jan 2019 12:02:34
+0100
** Changed in: python-cryptography (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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
-
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package r-cran-openssl - 1.0.1-1ubuntu1.1
---
r-cran-openssl (1.0.1-1ubuntu1.1) bionic; urgency=medium
* Cherrypick testsuite update for OpenSSL 1.1.1 LP: #1797386
-- Dimitri John Ledkov Tue, 11 Dec 2018 16:55:46
+1100
** Changed in: r-cran-openssl (Ubuntu Bionic)
Status: Fix Committed => Fix Released
** Changed in: ruby-openssl (Ubuntu Bionic)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-16395
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
This bug was fixed in the package ruby-openssl - 2.0.9-0ubuntu1
---
ruby-openssl (2.0.9-0ubuntu1) bionic; urgency=medium
* New upstream micro bugfix point release.
* Fixes compatibility with OpenSSL 1.1.1. LP: #1797386
* Fixes CVE-2018-16395
* Drop Debian-specific no-tls-v1.1 patch.
-- Dimitri John Ledkov Mon, 17 Dec 2018 15:37:47
+1100
** Changed in: openssl (Ubuntu Bionic)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-0732
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-0734
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-0735
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-0737
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3
[Touch-packages] [Bug 1797386] Update Released
The verification of the Stable Release Update for r-cran-openssl 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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Ship it!
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1797386
Title:
[SRU] OpenSSL 1.1.1 to 18.04 LTS
Status in libwww-perl package in Ubuntu:
Fix Released
Status in openssl package in Ubuntu:
Fix Released
Status in python-tornado package in Ubuntu:
In Progress
Status in libio-socket-ssl-perl source package in Bionic:
Fix Released
Status in libnet-ssleay-perl source package in Bionic:
Fix Released
Status in libwww-perl source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Fix Released
Status in python-cryptography source package in Bionic:
Fix Released
Status in python2.7 source package in Bionic:
Fix Released
Status in python3.6 source package in Bionic:
Fix Released
Status in python3.7 source package in Bionic:
Fix Released
Status in r-cran-openssl source package in Bionic:
Fix Released
Status in ruby-openssl source package in Bionic:
Fix Released
Status in ruby2.5 source package in Bionic:
Fix Released
Bug description:
[Impact]
* OpenSSL 1.1.1 is an LTS release upstream, which will continue to
receive security support for much longer than 1.1.0 series will.
* OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to
be rapidly adopted due to increased set of supported hashes & algoes,
as well as improved handshake [re-]negotiation.
* OpenSSL 1.1.1 comes with improved hw-acceleration capabilities.
* OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some
software is sensitive to the negotiation handshake and may either need
patches/improvements or clamp-down to maximum v1.2.
[Test Case]
* Rebuild all reverse dependencies
* Execute autopkg tests for all of them
* Clamp down to TLS v1.2 software that does not support TLS v1.3
(e.g. mongodb)
* Backport TLS v1.3 support patches, where applicable
[Test cases for the python updates]
python3.7 is a preview in bionic as a non-supported/non-default
version of python3. Passing it's own autopkgtests is sufficient
validation for python3.7. It includes a point release update, with
OpenSSL 1.1.1 compat and features.
python3.6 not only has OpenSSL 1.1.1 compat and features patches, but
also includes a point release update to 3.6.8. It has been part of the
full-archive rebuild and regression analysis. Autopkgtests were
triggered for python3.6 and python3-defaults with regressions already
fixed in the individual packages as appropriate.
python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1
compat only. It has been part of the full-archive rebuild and
regression analysis. Autopkgtests were triggered for python2.7 and
python-defaults with regressions already fixed in the individual
packages as appropriate.
The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1
and python point releases as seen in:
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
And analyzed in
https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652
[ Test case libwww-perl (and deps) regression ]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034
1. apt install liblwp-protocol-https-perl
2. enable -proposed
3. apt install libio-socket-ssl-perl libnet-ssleay-perl
4. perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[Regression Potential]
* Connectivity interop is the biggest issues which will be
unavoidable with introducing TLS v1.3. However, tests on cosmic
demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and
negotiate TLS v1.3 without issues.
* Mitigation of discovered connectivity issues will be possible by
clamping down to TLS v1.2 in either server-side or client-side
software or by backporting relevant support fixes
* Notable changes are listed here
https://wiki.openssl.org/index.php/TLS1.3
* Most common connectivity issues so far:
- client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname.
Solution is client change to set hostname, or to clamp down the client to
TLSv1.2.
- session negotiation is different in TLSv1.3, existing client code
may fail to create/negotiate/resume session. Clients need to learn how
to use session callback.
- non-application data records. TLSv1.3 sends more of these, when compared
with previous versions, and some applications may not handle this correctly.
Resulting in application data not being available, when previously expected.
Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY
[Touch-packages] [Bug 1690485] Re: openssh-server SIGSYS with 'UsePrivilegeSeparation sandbox'
Thank you for posting the additional information here. It sounds like this will help others affected. I see that the bug Importance has never been set, so I'm setting it now, to Low, based on "unusual end-user configurations" from https://wiki.ubuntu.com/Bugs/Importance. I'd like to make it clear that no progress can be expected from others on this bug, but volunteers are welcome to work on it. ** Changed in: openssh (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1690485 Title: openssh-server SIGSYS with 'UsePrivilegeSeparation sandbox' Status in openssh package in Ubuntu: New Bug description: The 'sshd' process gets 'authentication failure' and refuses to allow any login. dmesg indicates that the problem is SIGSYS on a call to 'socket' (syscall #41, signal #31). On a hunch, I decided to test whether the problem is related to 'seccomp' and changed /etc/ssh/sshd_config from the default # UsePrivilegeSeparation sandbox to the former standard value UsePrivilegeSeparation yes and logins started to work again. Obviously, I'd like to have the additional protection that sandboxing would give me. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: openssh-server 1:7.4p1-10 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 ApportVersion: 2.20.4-0ubuntu4 Architecture: amd64 CurrentDesktop: XFCE Date: Fri May 12 21:06:20 2017 InstallationDate: Installed on 2017-04-08 (35 days ago) InstallationMedia: SourcePackage: openssh UpgradeStatus: Upgraded to zesty on 2017-04-24 (19 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1690485/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830945] Re: DNS settings from interfaces file are ignored
Thank you for reporting back. I will close this ticket as invalid, then. ** Changed in: resolvconf (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1830945 Title: DNS settings from interfaces file are ignored Status in resolvconf package in Ubuntu: Invalid Bug description: Since a recent reboot (00:00 CEST on tuesday to be precise), DNS settings from the interfaces file are no longer present in resolvconf. A file /run/resolvconf/interface/eth0.inet exists but is empty. This is happening on a xenial system. I have since rebooted once more, with the same result. These are the contents of /etc/network/interfaces: iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.200.52 netmask 255.255.255.0 gateway 192.168.200.5 dns-nameserver 192.168.200.5 dns-nameserver 8.8.8.8 # second address iface eth0 inet static address 192.168.200.67 netmask 255.255.255.0 I'm running dnsmasq as a local DNS server on this system, which expects to get the "upstream" dns servers from resolvconf and thus can no longer resolve external addresses. Until this recent reboot, this configuration has worked without issue for many months, I have the etckeeper log to prove it :-). Here are some relevant excerpts from the logs: systemd[1]: Starting Clean up any mess left by 0dns-up... systemd[1]: Reached target Remote File Systems. systemd[1]: Started Clean up any mess left by 0dns-up. systemd[1]: Starting Nameserver information manager... systemd[1]: Started Nameserver information manager. systemd[1]: Reached target Sockets. systemd[1]: Reached target Basic System. systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... systemd[1]: Starting Restore /etc/resolv.conf if the system crashed before the ppp link was shut down... systemd[1]: Starting Raise network interfaces... systemd[1]: Started ifup for eth0. systemd[1]: Started Restore /etc/resolv.conf if the system crashed before the ppp link was shut down. ifup[624]: /sbin/ifup: waiting for lock on /run/network/ifstate.eth0 systemd[1]: Started Raise network interfaces. systemd[1]: Reached target Network. dnsmasq[583]: dnsmasq: syntax check OK. systemd[1]: Reached target Network is Online. ntpdate[840]: name server cannot be used: Temporary failure in name resolution (-3) dnsmasq[975]: started, version 2.75 cachesize 150 dnsmasq[975]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dnsmasq[975]: DNS service limited to local subnets dnsmasq-dhcp[975]: DHCP, IP range 192.168.200.100 -- 192.168.200.200, lease time 1h dnsmasq[975]: using local addresses only for domain myname.local dnsmasq[975]: no servers found in /var/run/dnsmasq/resolv.conf, will retry dnsmasq[975]: read /etc/hosts - 14 addresses ntpd[1060]: error resolving pool 0.ubuntu.pool.ntp.org: Temporary failure in name resolution (-3) systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. systemd[1]: Reached target Host and Network Name Lookups. ntpd[1060]: error resolving pool 1.ubuntu.pool.ntp.org: Temporary failure in name resolution (-3) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1830945/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
Thanks! I've just installed it on one of my Xenial servers for testing... I'll let you know how it goes... Cheers! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Released Status in cups source package in Bionic: Fix Released Status in cups source package in Cosmic: Fix Released Status in cups source package in Disco: Fix Released Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
This bug was fixed in the package cups - 2.1.3-4ubuntu0.9 --- cups (2.1.3-4ubuntu0.9) xenial; urgency=medium * d/p/0045-Fix-an-issue-with-PreserveJobHistory-and-time-values.patch Fix an issue with `PreserveJobHistory` and time values (Issue #5538, Closes: #921741, LP: #1747765) -- Dariusz Gadomski Thu, 30 May 2019 11:33:26 +0200 ** Changed in: cups (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Released Status in cups source package in Bionic: Fix Released Status in cups source package in Cosmic: Fix Released Status in cups source package in Disco: Fix Released Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
This bug was fixed in the package systemd - 237-3ubuntu10.22 --- systemd (237-3ubuntu10.22) bionic; urgency=medium * d/p/resolved-rework-how-we-determine-which-scope-to-send.patch - fix DNS leakage (LP: 1754671) * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Wed, 24 Apr 2019 17:15:36 -0400 ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Released Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Released Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Released Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Confirmed Status in systemd package in Debian: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825212] Update Released
The verification of the Stable Release Update for openssl 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 openssl in Ubuntu. https://bugs.launchpad.net/bugs/1825212 Title: [SRU] openssl disco Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Disco: Fix Released Bug description: [Impact] * openssl has BUF_MEM regression that may affect packages at runtime. * openssl has a regression of failing to initialize SSL context without openssl.cnf file [Test Case] * Compile an old r-cran-openssl and run its autopkgtest against the current & fixed openssl, it should fail and pass respectively * remove openssl.cnf and try to use curl https://www.ubuntu.com it should succeed [Regression Potential] * These are regressions in the 1.1.1 series, witch patches cherrypicked from openssl stable branch and the same patches were uploaded into Debian. * The above two issues may continue to persist To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1825212/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
This bug was fixed in the package systemd - 239-7ubuntu10.14 --- systemd (239-7ubuntu10.14) cosmic; urgency=medium * d/p/resolved-rework-how-we-determine-which-scope-to-send.patch - fix DNS leakage (LP: 1754671) * d/t/boot-and-services: - skip test_no_failed if gdm failed to start (LP: #1830484) * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Wed, 24 Apr 2019 17:08:26 -0400 ** Changed in: systemd (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Released Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Released Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Released Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Confirmed Status in systemd package in Debian: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822993] Re: SRU: update Python 2.7 to 2.7.16, Python 3.7 to 3.7.3 and 3.6 to 3.6.8
This bug was fixed in the package python3-stdlib-extensions - 3.6.8-1~18.04 --- python3-stdlib-extensions (3.6.8-1~18.04) bionic-proposed; urgency=medium * SRU: LP: #1822993. * Update 3.6 extensions and modules to 3.6.8. * Update 3.7 extensions and modules to 3.7.3. -- Matthias Klose Tue, 09 Apr 2019 07:04:33 +0200 -- 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/1822993 Title: SRU: update Python 2.7 to 2.7.16, Python 3.7 to 3.7.3 and 3.6 to 3.6.8 Status in python-stdlib-extensions package in Ubuntu: Fix Released Status in python2.7 package in Ubuntu: Fix Released Status in python3-stdlib-extensions package in Ubuntu: Fix Released Status in python3.7 package in Ubuntu: Fix Released Status in python-stdlib-extensions source package in Bionic: Fix Released Status in python3-stdlib-extensions source package in Bionic: Fix Released Status in python-stdlib-extensions source package in Cosmic: Fix Released Status in python2.7 source package in Cosmic: Fix Released Status in python3-stdlib-extensions source package in Cosmic: Fix Released Status in python3.6 source package in Cosmic: Fix Released Status in python3.7 source package in Cosmic: Fix Released Bug description: SRU: update Python 3.7 to the 3.7.3 release, update Python 3.6 to the 3.6.8 release. python3-stdlib-extensions also updates the modules to the 3.6.8 release for Python 3.6. Acceptance Criteria: The package builds, and the test suite doesn't show regressions. The test suite passes in the autopkg tests. The new packages don't cause regressions in a test rebuild of the main component. http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-cosmic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-gcc8-cosmic.html The test rebuilds are finished, and don't show any regressions for the main component. Regression Potential: Python 3.7 isn't used by default, so we don't have many default users. Regression Potential: Python 3.6 could see some regressions, although we are trying to minimize the risk by doing the test rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-stdlib-extensions/+bug/1822993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
This bug was fixed in the package cups - 2.2.7-1ubuntu2.6 --- cups (2.2.7-1ubuntu2.6) bionic; urgency=medium * d/p/0045-Fix-an-issue-with-PreserveJobHistory-and-time-values.patch Fix an issue with `PreserveJobHistory` and time values (Issue #5538, Closes: #921741, LP: #1747765) -- Dariusz Gadomski Thu, 30 May 2019 10:02:17 +0200 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Released Status in cups source package in Cosmic: Fix Released Status in cups source package in Disco: Fix Released Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1827172] Re: update-rc.d: enabling or disabling S runlevel services incorrectly modifies runlevel
** Tags removed: sts-sponsor sts-sponsor-ddstreet -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1827172 Title: update-rc.d: enabling or disabling S runlevel services incorrectly modifies runlevel Status in sysvinit package in Ubuntu: New Status in sysvinit source package in Trusty: In Progress Bug description: [Impact] * update-rc.d, in sysv-rc-2.88dsf-41ubuntu6.3 is broken in trusty. * update-rc.d incorrectly modifies symlinks when enabling or disabling services which are started on the "S" runlevel. * This can lead to services being changed from S runlevel from where they would be started on boot, to "0" runlevel, and are run on halt, which is incorrect. * The bug is caused by trying to use the runlevel to index into an integer array of runlevels. When the runlevel in question is "S", an error is printed Argument "S" isn't numeric in array element at /usr/sbin/update-rc.d line 232. Perl then sets the index to default to 0, which changes the runlevel. * The fix is to check if the runlevel is "S", and if it is, set the index to 99 which conforms with other expected usages for the "S" runlevel in the script. See the "startstop" and "makelinks" subroutines. [Test Case] * You can reproduce this with any service that is started on the "S" runlevel. We will use open-iscsi for an example. 1) Install open-iscsi $ sudo apt install open-iscsi 2) Check to see symlinks for init.d scripts are set to defaults: root@trusty-openiscsi:/etc# ls -l /etc/rc[0123456S].d/*iscsi* /etc/rc0.d/K80umountiscsi.sh -> ../init.d/umountiscsi.sh /etc/rc0.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rc1.d/K80umountiscsi.sh -> ../init.d/umountiscsi.sh /etc/rc1.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rc6.d/K80umountiscsi.sh -> ../init.d/umountiscsi.sh /etc/rc6.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rcS.d/S45open-iscsi -> ../init.d/open-iscsi 3) Use update-rc.d to enable open-iscsi service root@trusty-openiscsi:/etc# update-rc.d open-iscsi enable update-rc.d: warning: start runlevel arguments (none) do not match open-iscsi Default-Start values (S) update-rc.d: warning: stop runlevel arguments (none) do not match open-iscsi Default-Stop values (0 1 6) Argument "S" isn't numeric in array element at /usr/sbin/update-rc.d line 232. Enabling system startup links for /etc/init.d/open-iscsi ... Removing any system startup links for /etc/init.d/open-iscsi ... /etc/rc0.d/K81open-iscsi /etc/rc1.d/K81open-iscsi /etc/rc6.d/K81open-iscsi /etc/rcS.d/S45open-iscsi Adding system startup for /etc/init.d/open-iscsi ... /etc/rc0.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rc1.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rc6.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rc0.d/S45open-iscsi -> ../init.d/open-iscsi * The problem is the "/etc/rcS.d/S45open-iscsi" symlink is incorrectly changed to "/etc/rc0.d/S45open-iscsi". * Instead, the correct behaviour is to keep the symlink in /etc/rcS.d/ intact: root@trusty-openiscsi:/etc# update-rc.d open-iscsi enable update-rc.d: warning: start runlevel arguments (none) do not match open-iscsi Default-Start values (S) update-rc.d: warning: stop runlevel arguments (none) do not match open-iscsi Default-Stop values (0 1 6) Enabling system startup links for /etc/init.d/open-iscsi ... Removing any system startup links for /etc/init.d/open-iscsi ... /etc/rc0.d/K81open-iscsi /etc/rc1.d/K81open-iscsi /etc/rc6.d/K81open-iscsi /etc/rcS.d/S45open-iscsi Adding system startup for /etc/init.d/open-iscsi ... /etc/rc0.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rc1.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rc6.d/K81open-iscsi -> ../init.d/open-iscsi /etc/rcS.d/S45open-iscsi -> ../init.d/open-iscsi [Regression Potential] * There is only one file modified, which is the update-rc.d perl script. Worst case scenario is that users cannot enable or disable their services, or a symlink is changed such that a service is started / stopped on an incorrect runlevel. * If a regression happens, any damage should be easily spotted by a sysadmin and can be manually repaired by making manual symlinks with "ln -s". * I have built and tested the change in a PPA, which you can find here: https://launchpad.net/~mruffell/+archive/ubuntu/sysvinit-testing * My only cause for concern is that if a regression does happen, it may impact packages that run "update-rc.d [en|dis]able" in a postinstall module, although I haven't managed to find an example that does this, since most use the "defaults" command instead. [Other Info] * trusty is the last Ubuntu release to use sysvinit, and this bug is not present in newer versions since they use systemd,
[Touch-packages] [Bug 1830484] Re: boot-and-services test_no_failed fails if gdm failed to start in testbed
This bug was fixed in the package systemd - 239-7ubuntu10.14 --- systemd (239-7ubuntu10.14) cosmic; urgency=medium * d/p/resolved-rework-how-we-determine-which-scope-to-send.patch - fix DNS leakage (LP: 1754671) * d/t/boot-and-services: - skip test_no_failed if gdm failed to start (LP: #1830484) * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Wed, 24 Apr 2019 17:08:26 -0400 ** Changed in: systemd (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1830484 Title: boot-and-services test_no_failed fails if gdm failed to start in testbed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [impact] gdm on cosmic running in the autopkgtest is flaky and sometimes fails to start; when it does it causes other systemd service failures like 'user@118.service' or other services, which fail the test case. the test_gdm3 testcase was already skipped because of this in bug 1790478, the test_no_failed testcase needs to be skipped as well if gdm fails to start. [test case] the failure is intermittent, but looking through old cosmic systemd autopkgtest logs look for: May 23 11:13:38 autopkgtest systemd[1]: user@118.service: Killing process 1251 (systemctl) with signal SIGKILL. May 23 11:13:38 autopkgtest systemd[1]: Stopped User Manager for UID 118. May 23 11:13:39 autopkgtest systemd[1]: Starting User Manager for UID 118... May 23 11:13:37 autopkgtest systemd[1280]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0) May 23 11:13:38 autopkgtest systemd[1280]: Failed to fully start up daemon: Permission denied May 23 11:13:38 autopkgtest systemd[1]: user@118.service: Failed with result 'protocol'. May 23 11:13:38 autopkgtest systemd[1]: Failed to start User Manager for UID 118. FAIL test_rsyslog (__main__.ServicesTest) ... ok test_tmp_cleanup (__main__.ServicesTest) ... ok test_tmp_mount (__main__.ServicesTest) ... ok test_udev (__main__.ServicesTest) ... ok == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.jGFP4N/build.FWq/src/debian/tests/boot-and-services", line 62, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['user@118.service loaded failed failed User Manager for UID 118'] != [] First list contains 1 additional elements. First extra element 0: 'user@118.service loaded failed failed User Manager for UID 118' - ['user@118.service loaded failed failed User Manager for UID 118'] + [] [regression potential] low; testcase skipping due to flaky gdm inside autopkgtest, only on cosmic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830484/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1831232] Re: Ubuntu 18.04 won't boot - failed to connect to lvmetad
If I leave the machine for a while and the exit the shell it boots, but with no swap. I have not discovered anything useful that I can do while in the busybox shell. I have dited /etc/initramfs-tools/conf.d/resume to read RESUME=none as suggested in https://www.reddit.com/r/Ubuntu/comments/a0whdw/failed_to_connect_to_lvmetad_bug_still_exists/ cat /etc/crypttab sda2_crypt UUID=91558a55-9299-492f-b3b7-324fa7d07396 none luks,swap,discard sda3_crypt UUID=04bbb9dd-9c3f-48c9-ad65-617c4030cd8a none luks,discard cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/sda3_crypt / ext4errors=remount-ro 0 1 # /boot was on /dev/sda1 during installation UUID=bedf1183-2c1a-4271-a983-f4924a87bb09 /boot ext4noatime 0 2 /dev/mapper/sda2_crypt noneswapsw 0 0 -- 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/1831232 Title: Ubuntu 18.04 won't boot - failed to connect to lvmetad Status in linux package in Ubuntu: Incomplete Status in lvm2 package in Ubuntu: Incomplete Bug description: This bug report relates to a machine running 18.04, not the one I am submitting the report from. On 30 May The Software Updater prompted me to update. Included in the update were initramfs components. I now cannot boot the machine. After decrypting the root file system, instead of being prompted for the pass-phrase to decrypt the swap, I get the message "cannot connect to lvmetad: falling back to device scanning". This repeats for a while until I am dropped into a recovery shell of some sort from which I cannot access the root disk. Blocker. My machine is unusable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-generic 4.15.0.48.50 ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18 Uname: Linux 4.15.0-48-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: gdm2433 F pulseaudio raph 8920 F pulseaudio /dev/snd/controlC0: gdm2433 F pulseaudio Date: Fri May 31 12:08:33 2019 HibernationDevice: RESUME=UUID=2538baa4-d43e-4876-8d94-dd3221894bac InstallationDate: Installed on 2018-02-09 (475 days ago) InstallationMedia: Xubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) MachineType: LENOVO 20CJS0UU00 ProcEnviron: LANGUAGE=en_GB:en TERM=xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-48-generic root=/dev/mapper/xubuntu--vg-root ro quiet splash vt.handoff=1 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-4.15.0-48-generic N/A linux-backports-modules-4.15.0-48-generic N/A linux-firmware 1.173.5 SourcePackage: linux UpgradeStatus: Upgraded to bionic on 2018-09-12 (260 days ago) dmi.bios.date: 09/13/2017 dmi.bios.vendor: LENOVO dmi.bios.version: N11ET42W (1.18 ) dmi.board.asset.tag: Not Available dmi.board.name: 20CJS0UU00 dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 WIN dmi.chassis.asset.tag: R90G3N7R dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN11ET42W(1.18):bd09/13/2017:svnLENOVO:pn20CJS0UU00:pvrThinkPadT550:rvnLENOVO:rn20CJS0UU00:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T550 dmi.product.name: 20CJS0UU00 dmi.product.version: ThinkPad T550 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831232/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
This bug was fixed in the package cups - 2.2.8-5ubuntu1.4 --- cups (2.2.8-5ubuntu1.4) cosmic; urgency=medium * d/p/0045-Fix-an-issue-with-PreserveJobHistory-and-time-values.patch Fix an issue with `PreserveJobHistory` and time values (Issue #5538, Closes: #921741, LP: #1747765) -- Dariusz Gadomski Thu, 30 May 2019 14:11:53 +0200 ** Changed in: cups (Ubuntu Cosmic) Status: Fix Committed => Fix Released ** Changed in: cups (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 cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Released Status in cups source package in Cosmic: Fix Released Status in cups source package in Disco: Fix Released Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822993] Re: SRU: update Python 2.7 to 2.7.16, Python 3.7 to 3.7.3 and 3.6 to 3.6.8
This bug was fixed in the package python-stdlib-extensions - 2.7.16-2~18.04 --- python-stdlib-extensions (2.7.16-2~18.04) bionic-proposed; urgency=medium * SRU: LP: #1822993. python-stdlib-extensions (2.7.16-2) unstable; urgency=medium * Re-pack the orig tarball without the VCS repo. python-stdlib-extensions (2.7.16-1) unstable; urgency=medium * Python 2.7.16 release. python-stdlib-extensions (2.7.16~rc1-1) unstable; urgency=medium * Python 2.7.16 release candidate. * Bump standards version. * Fix FTCBFS (Helmut Grohne). Closes: #913417. + Multiarchify Build-Depends. + Set up PYTHONPATH for cross compilation. + cross.patch: Don't import built modules. python-stdlib-extensions (2.7.15-1) unstable; urgency=medium * Python 2.7.15 release. -- Matthias Klose Tue, 09 Apr 2019 06:54:11 +0200 ** Changed in: python-stdlib-extensions (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: python3-stdlib-extensions (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 python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1822993 Title: SRU: update Python 2.7 to 2.7.16, Python 3.7 to 3.7.3 and 3.6 to 3.6.8 Status in python-stdlib-extensions package in Ubuntu: Fix Released Status in python2.7 package in Ubuntu: Fix Released Status in python3-stdlib-extensions package in Ubuntu: Fix Released Status in python3.7 package in Ubuntu: Fix Released Status in python-stdlib-extensions source package in Bionic: Fix Released Status in python3-stdlib-extensions source package in Bionic: Fix Released Status in python-stdlib-extensions source package in Cosmic: Fix Released Status in python2.7 source package in Cosmic: Fix Released Status in python3-stdlib-extensions source package in Cosmic: Fix Released Status in python3.6 source package in Cosmic: Fix Released Status in python3.7 source package in Cosmic: Fix Released Bug description: SRU: update Python 3.7 to the 3.7.3 release, update Python 3.6 to the 3.6.8 release. python3-stdlib-extensions also updates the modules to the 3.6.8 release for Python 3.6. Acceptance Criteria: The package builds, and the test suite doesn't show regressions. The test suite passes in the autopkg tests. The new packages don't cause regressions in a test rebuild of the main component. http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-cosmic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-gcc8-cosmic.html The test rebuilds are finished, and don't show any regressions for the main component. Regression Potential: Python 3.7 isn't used by default, so we don't have many default users. Regression Potential: Python 3.6 could see some regressions, although we are trying to minimize the risk by doing the test rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-stdlib-extensions/+bug/1822993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825212] Re: [SRU] openssl disco
This bug was fixed in the package openssl - 1.1.1b-1ubuntu2.1 --- openssl (1.1.1b-1ubuntu2.1) disco; urgency=medium * SRU the below two regressions fixes from Debian LP: #1825212 - Fix BUF_MEM regression (Closes: #923516) - Fix error when config can't be opened (Closes: #926315) -- Dimitri John Ledkov Wed, 17 Apr 2019 17:50:04 +0100 ** Changed in: openssl (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1825212 Title: [SRU] openssl disco Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Disco: Fix Released Bug description: [Impact] * openssl has BUF_MEM regression that may affect packages at runtime. * openssl has a regression of failing to initialize SSL context without openssl.cnf file [Test Case] * Compile an old r-cran-openssl and run its autopkgtest against the current & fixed openssl, it should fail and pass respectively * remove openssl.cnf and try to use curl https://www.ubuntu.com it should succeed [Regression Potential] * These are regressions in the 1.1.1 series, witch patches cherrypicked from openssl stable branch and the same patches were uploaded into Debian. * The above two issues may continue to persist To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1825212/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825997] Re: boot-smoke fails due to running jobs
This bug was fixed in the package systemd - 237-3ubuntu10.22 --- systemd (237-3ubuntu10.22) bionic; urgency=medium * d/p/resolved-rework-how-we-determine-which-scope-to-send.patch - fix DNS leakage (LP: 1754671) * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Wed, 24 Apr 2019 17:15:36 -0400 ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1825997 Title: boot-smoke fails due to running jobs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [impact] boot-smoke test reboots 5 times and verifies systemd is fully started up after each boot, including checking if there are any running jobs (with list-jobs). However, this test makes the assumption that no further jobs will be started after systemd reaches 'running' (or 'degraded') state, which is a false assumption. [test case] see various boot-smoke failures in autopkgtest.ubuntu.com [regression potential] possible false-positive or false-negative autopkgtest results. [other info] Note: This patch is not required for debian, because debian's boot- smoke does not include the wait for systemctl is-system-running. The problem appears to be that systemd reaches 'running' (or 'degraded') state, and then other systemd services are started. This confuses the boot-smoke test, because it sees that 'is-system-running' is done, but then it sees running jobs, which fails the test. What is starting jobs after systemd reaches running state appears to be X inside the test system. There are various services started by gnome-session and dbus-daemon. Additionally, from the artifacts of one example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- bionic/bionic/i386/s/systemd/20190416_171327_478f6@/artifacts.tar.gz the artifacts/journal.txt shows that after the boot-smoke test causes the reboot and then re-ssh into the system after the reboot, it only gives the test system 9 seconds before deciding it has failed, and only 4 seconds after ssh'ing into the rebooted test system. Another wait is needed when checking for remaining running jobs. Or, the running jobs check could be removed entirely, and we can just trust that systemd correctly knows when it has reached running|degraded state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825997] Re: boot-smoke fails due to running jobs
This bug was fixed in the package systemd - 239-7ubuntu10.14 --- systemd (239-7ubuntu10.14) cosmic; urgency=medium * d/p/resolved-rework-how-we-determine-which-scope-to-send.patch - fix DNS leakage (LP: 1754671) * d/t/boot-and-services: - skip test_no_failed if gdm failed to start (LP: #1830484) * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Wed, 24 Apr 2019 17:08:26 -0400 ** Changed in: systemd (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1825997 Title: boot-smoke fails due to running jobs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [impact] boot-smoke test reboots 5 times and verifies systemd is fully started up after each boot, including checking if there are any running jobs (with list-jobs). However, this test makes the assumption that no further jobs will be started after systemd reaches 'running' (or 'degraded') state, which is a false assumption. [test case] see various boot-smoke failures in autopkgtest.ubuntu.com [regression potential] possible false-positive or false-negative autopkgtest results. [other info] Note: This patch is not required for debian, because debian's boot- smoke does not include the wait for systemctl is-system-running. The problem appears to be that systemd reaches 'running' (or 'degraded') state, and then other systemd services are started. This confuses the boot-smoke test, because it sees that 'is-system-running' is done, but then it sees running jobs, which fails the test. What is starting jobs after systemd reaches running state appears to be X inside the test system. There are various services started by gnome-session and dbus-daemon. Additionally, from the artifacts of one example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- bionic/bionic/i386/s/systemd/20190416_171327_478f6@/artifacts.tar.gz the artifacts/journal.txt shows that after the boot-smoke test causes the reboot and then re-ssh into the system after the reboot, it only gives the test system 9 seconds before deciding it has failed, and only 4 seconds after ssh'ing into the rebooted test system. Another wait is needed when checking for remaining running jobs. Or, the running jobs check could be removed entirely, and we can just trust that systemd correctly knows when it has reached running|degraded state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830484] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1830484 Title: boot-and-services test_no_failed fails if gdm failed to start in testbed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [impact] gdm on cosmic running in the autopkgtest is flaky and sometimes fails to start; when it does it causes other systemd service failures like 'user@118.service' or other services, which fail the test case. the test_gdm3 testcase was already skipped because of this in bug 1790478, the test_no_failed testcase needs to be skipped as well if gdm fails to start. [test case] the failure is intermittent, but looking through old cosmic systemd autopkgtest logs look for: May 23 11:13:38 autopkgtest systemd[1]: user@118.service: Killing process 1251 (systemctl) with signal SIGKILL. May 23 11:13:38 autopkgtest systemd[1]: Stopped User Manager for UID 118. May 23 11:13:39 autopkgtest systemd[1]: Starting User Manager for UID 118... May 23 11:13:37 autopkgtest systemd[1280]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0) May 23 11:13:38 autopkgtest systemd[1280]: Failed to fully start up daemon: Permission denied May 23 11:13:38 autopkgtest systemd[1]: user@118.service: Failed with result 'protocol'. May 23 11:13:38 autopkgtest systemd[1]: Failed to start User Manager for UID 118. FAIL test_rsyslog (__main__.ServicesTest) ... ok test_tmp_cleanup (__main__.ServicesTest) ... ok test_tmp_mount (__main__.ServicesTest) ... ok test_udev (__main__.ServicesTest) ... ok == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.jGFP4N/build.FWq/src/debian/tests/boot-and-services", line 62, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['user@118.service loaded failed failed User Manager for UID 118'] != [] First list contains 1 additional elements. First extra element 0: 'user@118.service loaded failed failed User Manager for UID 118' - ['user@118.service loaded failed failed User Manager for UID 118'] + [] [regression potential] low; testcase skipping due to flaky gdm inside autopkgtest, only on cosmic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830484/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822993] Re: SRU: update Python 2.7 to 2.7.16, Python 3.7 to 3.7.3 and 3.6 to 3.6.8
Autopkgtests are passing for both of the remaining bionic uploads. There is one ADT regression from sphinx, but the failure is the same as for any other package so it can be ignored. Setting as verified and releasing. ** 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 python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1822993 Title: SRU: update Python 2.7 to 2.7.16, Python 3.7 to 3.7.3 and 3.6 to 3.6.8 Status in python-stdlib-extensions package in Ubuntu: Fix Released Status in python2.7 package in Ubuntu: Fix Released Status in python3-stdlib-extensions package in Ubuntu: Fix Released Status in python3.7 package in Ubuntu: Fix Released Status in python-stdlib-extensions source package in Bionic: Fix Released Status in python3-stdlib-extensions source package in Bionic: Fix Released Status in python-stdlib-extensions source package in Cosmic: Fix Released Status in python2.7 source package in Cosmic: Fix Released Status in python3-stdlib-extensions source package in Cosmic: Fix Released Status in python3.6 source package in Cosmic: Fix Released Status in python3.7 source package in Cosmic: Fix Released Bug description: SRU: update Python 3.7 to the 3.7.3 release, update Python 3.6 to the 3.6.8 release. python3-stdlib-extensions also updates the modules to the 3.6.8 release for Python 3.6. Acceptance Criteria: The package builds, and the test suite doesn't show regressions. The test suite passes in the autopkg tests. The new packages don't cause regressions in a test rebuild of the main component. http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-cosmic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-gcc8-cosmic.html The test rebuilds are finished, and don't show any regressions for the main component. Regression Potential: Python 3.7 isn't used by default, so we don't have many default users. Regression Potential: Python 3.6 could see some regressions, although we are trying to minimize the risk by doing the test rebuild. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-stdlib-extensions/+bug/1822993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
This bug was fixed in the package systemd - 240-6ubuntu5.1 --- systemd (240-6ubuntu5.1) disco; urgency=medium * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/p/network-wireguard-fixes-sending-wireguard-peer-setti.patch, d/p/test-network-add-more-checks-in-NetworkdNetDevTests..patch, d/p/sd-netlink-introduce-sd_netlink_message_append_socka.patch, d/p/network-wireguard-use-sd_netlink_message_append_sock.patch: - systemd doesn't set wireguard peer endpoint (LP: #1825378) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Thu, 16 May 2019 06:07:49 -0400 ** Changed in: systemd (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Released Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Confirmed Status in systemd package in Debian: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825997] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1825997 Title: boot-smoke fails due to running jobs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [impact] boot-smoke test reboots 5 times and verifies systemd is fully started up after each boot, including checking if there are any running jobs (with list-jobs). However, this test makes the assumption that no further jobs will be started after systemd reaches 'running' (or 'degraded') state, which is a false assumption. [test case] see various boot-smoke failures in autopkgtest.ubuntu.com [regression potential] possible false-positive or false-negative autopkgtest results. [other info] Note: This patch is not required for debian, because debian's boot- smoke does not include the wait for systemctl is-system-running. The problem appears to be that systemd reaches 'running' (or 'degraded') state, and then other systemd services are started. This confuses the boot-smoke test, because it sees that 'is-system-running' is done, but then it sees running jobs, which fails the test. What is starting jobs after systemd reaches running state appears to be X inside the test system. There are various services started by gnome-session and dbus-daemon. Additionally, from the artifacts of one example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- bionic/bionic/i386/s/systemd/20190416_171327_478f6@/artifacts.tar.gz the artifacts/journal.txt shows that after the boot-smoke test causes the reboot and then re-ssh into the system after the reboot, it only gives the test system 9 seconds before deciding it has failed, and only 4 seconds after ssh'ing into the rebooted test system. Another wait is needed when checking for remaining running jobs. Or, the running jobs check could be removed entirely, and we can just trust that systemd correctly knows when it has reached running|degraded state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825378] Re: systemd-networkd doesn't set wireguard peer endpoint
This bug was fixed in the package systemd - 240-6ubuntu5.1 --- systemd (240-6ubuntu5.1) disco; urgency=medium * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/p/network-wireguard-fixes-sending-wireguard-peer-setti.patch, d/p/test-network-add-more-checks-in-NetworkdNetDevTests..patch, d/p/sd-netlink-introduce-sd_netlink_message_append_socka.patch, d/p/network-wireguard-use-sd_netlink_message_append_sock.patch: - systemd doesn't set wireguard peer endpoint (LP: #1825378) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Thu, 16 May 2019 06:07:49 -0400 ** Changed in: systemd (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1825378 Title: systemd-networkd doesn't set wireguard peer endpoint Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Cosmic: Invalid Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [impact] systemd does not set endpoints for wireguard interfaces correctly. This makes wireguard unusable. [test case] install a disco or eoan system and set up a wireguard interface: $ sudo add-apt-repository ppa:wireguard/wireguard $ sudo apt install wireguard ...(this does a lot of stuff)... create a file as below; There is no need to setup remote server to reproduce this issue, but PublicKey/PrivateKey should be valid one (used instructions from https://www.linode.com/docs/networking/vpn /set-up-wireguard-vpn-on-ubuntu/#configure-wireguard-server): $ cat /etc/systemd/network/wg0.netdev [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=uMuCbguKYdKanRYMbDSriIdgxGxJR57Us1zEy8wRc1M= ListenPort=51820 [WireGuardPeer] PublicKey=ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 $ sudo systemctl restart systemd-networkd $ sudo wg show wg0 interface: wg0 public key: BnvFgvPiVb5xURfzZ5liV1P77qeGeJDIX3C1iNquA2k= private key: (hidden) listening port: 51820 peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= allowed ips: 10.0.0.0/8 the last command should print remote endpoint address, e.g.: peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 [regression potential] any changes to systemd contain the potential for serious regressions. However, this is cherry picked directly from upstream, with the releases requiring patching (disco and eoan) being at exactly the same version and very close to upstream already. Additionally, while this does add 2 new functions (from upstream commit https://github.com/systemd/systemd/pull/11580/commits/abd48ec87f2ac5dd571a99dcb4db88c4affdffc8), they are only used - and code is only changed in - wireguard.c, so any regressions should be limited to wireguard interfaces (unless systemd crashes completely). [other info] this bug is not present in cosmic and earlier, and is already fixed in upstream systemd, so this is needed only for disco and eoan. original description: --- systemd/disco 240 shipped with Ubuntu 19.04 beta does not set endpoints for [WireguradPeer] properly. This regression was introduced in v241 and merged into v240. systemd 241 doesn't set wireguard peer endpoint https://github.com/systemd/systemd/issues/11579 Revert of the regression was landed on v240 stable branch https://github.com/systemd/systemd-stable/pull/39 1)2) confirmed with, systemd/disco 240-6ubuntu5 amd64 3) put a netdev file /etc/systemd/network/wg0.netdev --- [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=** ListenPort=51820 [WireGuardPeer] PublicKey=* AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 and run --- # systemctl restart systemd-networkd # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * allowed ips: 10.0.0.0/8 4) the last command should print remote endpoint address. --- # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825378/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages
[Touch-packages] [Bug 1825378] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1825378 Title: systemd-networkd doesn't set wireguard peer endpoint Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Cosmic: Invalid Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [impact] systemd does not set endpoints for wireguard interfaces correctly. This makes wireguard unusable. [test case] install a disco or eoan system and set up a wireguard interface: $ sudo add-apt-repository ppa:wireguard/wireguard $ sudo apt install wireguard ...(this does a lot of stuff)... create a file as below; There is no need to setup remote server to reproduce this issue, but PublicKey/PrivateKey should be valid one (used instructions from https://www.linode.com/docs/networking/vpn /set-up-wireguard-vpn-on-ubuntu/#configure-wireguard-server): $ cat /etc/systemd/network/wg0.netdev [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=uMuCbguKYdKanRYMbDSriIdgxGxJR57Us1zEy8wRc1M= ListenPort=51820 [WireGuardPeer] PublicKey=ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 $ sudo systemctl restart systemd-networkd $ sudo wg show wg0 interface: wg0 public key: BnvFgvPiVb5xURfzZ5liV1P77qeGeJDIX3C1iNquA2k= private key: (hidden) listening port: 51820 peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= allowed ips: 10.0.0.0/8 the last command should print remote endpoint address, e.g.: peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 [regression potential] any changes to systemd contain the potential for serious regressions. However, this is cherry picked directly from upstream, with the releases requiring patching (disco and eoan) being at exactly the same version and very close to upstream already. Additionally, while this does add 2 new functions (from upstream commit https://github.com/systemd/systemd/pull/11580/commits/abd48ec87f2ac5dd571a99dcb4db88c4affdffc8), they are only used - and code is only changed in - wireguard.c, so any regressions should be limited to wireguard interfaces (unless systemd crashes completely). [other info] this bug is not present in cosmic and earlier, and is already fixed in upstream systemd, so this is needed only for disco and eoan. original description: --- systemd/disco 240 shipped with Ubuntu 19.04 beta does not set endpoints for [WireguradPeer] properly. This regression was introduced in v241 and merged into v240. systemd 241 doesn't set wireguard peer endpoint https://github.com/systemd/systemd/issues/11579 Revert of the regression was landed on v240 stable branch https://github.com/systemd/systemd-stable/pull/39 1)2) confirmed with, systemd/disco 240-6ubuntu5 amd64 3) put a netdev file /etc/systemd/network/wg0.netdev --- [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=** ListenPort=51820 [WireGuardPeer] PublicKey=* AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 and run --- # systemctl restart systemd-networkd # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * allowed ips: 10.0.0.0/8 4) the last command should print remote endpoint address. --- # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825378/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1814373] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Released Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Confirmed Status in systemd package in Debian: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825997] Re: boot-smoke fails due to running jobs
This bug was fixed in the package systemd - 240-6ubuntu5.1 --- systemd (240-6ubuntu5.1) disco; urgency=medium * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch: - prevent buffer overflow when reading keyring (LP: #1814373) * d/p/network-wireguard-fixes-sending-wireguard-peer-setti.patch, d/p/test-network-add-more-checks-in-NetworkdNetDevTests..patch, d/p/sd-netlink-introduce-sd_netlink_message_append_socka.patch, d/p/network-wireguard-use-sd_netlink_message_append_sock.patch: - systemd doesn't set wireguard peer endpoint (LP: #1825378) * d/t/boot-smoke: - Fix false negative checking for running jobs after boot (LP: #1825997) -- Dan Streetman Thu, 16 May 2019 06:07:49 -0400 ** Changed in: systemd (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1825997 Title: boot-smoke fails due to running jobs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [impact] boot-smoke test reboots 5 times and verifies systemd is fully started up after each boot, including checking if there are any running jobs (with list-jobs). However, this test makes the assumption that no further jobs will be started after systemd reaches 'running' (or 'degraded') state, which is a false assumption. [test case] see various boot-smoke failures in autopkgtest.ubuntu.com [regression potential] possible false-positive or false-negative autopkgtest results. [other info] Note: This patch is not required for debian, because debian's boot- smoke does not include the wait for systemctl is-system-running. The problem appears to be that systemd reaches 'running' (or 'degraded') state, and then other systemd services are started. This confuses the boot-smoke test, because it sees that 'is-system-running' is done, but then it sees running jobs, which fails the test. What is starting jobs after systemd reaches running state appears to be X inside the test system. There are various services started by gnome-session and dbus-daemon. Additionally, from the artifacts of one example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- bionic/bionic/i386/s/systemd/20190416_171327_478f6@/artifacts.tar.gz the artifacts/journal.txt shows that after the boot-smoke test causes the reboot and then re-ssh into the system after the reboot, it only gives the test system 9 seconds before deciding it has failed, and only 4 seconds after ssh'ing into the rebooted test system. Another wait is needed when checking for remaining running jobs. Or, the running jobs check could be removed entirely, and we can just trust that systemd correctly knows when it has reached running|degraded state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
This bug was fixed in the package cups - 2.2.10-4ubuntu2 --- cups (2.2.10-4ubuntu2) disco; urgency=medium * d/p/0045-Fix-an-issue-with-PreserveJobHistory-and-time-values.patch Fix an issue with `PreserveJobHistory` and time values (Issue #5538, Closes: #921741, LP: #1747765) -- Dariusz Gadomski Thu, 30 May 2019 09:51:37 +0200 ** Changed in: cups (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Released Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747765] Update Released
The verification of the Stable Release Update for cups 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 cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
Thank you for verifying all the test cases! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832108] Re: unmkinitramfs fails with lz4 compressed initrds
This bug was fixed in the package initramfs-tools - 0.133ubuntu8 --- initramfs-tools (0.133ubuntu8) eoan; urgency=medium * Switch back to lz4 by default. * Patch unmkinitramfs to cat possible lz4 archives first, as lz4 is particular about enforcing .lz4 file extensions when operating on files. LP: #1832108 -- Dimitri John Ledkov Mon, 10 Jun 2019 00:21:17 +0100 ** Changed in: initramfs-tools (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1832108 Title: unmkinitramfs fails with lz4 compressed initrds Status in initramfs-tools package in Ubuntu: Fix Released Bug description: unmkinitramfs fails with lz4 compressed initrds Note: $ lz4cat -t unmkinitramfs_Cz6Yl9 File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process file: unmkinitramfs_Cz6Yl9 And $ lsinitramfs /boot/initrd.img kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/.enuineIntel.align.0123456789abc kernel/x86/microcode/GenuineIntel.bin cpio: premature end of archive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1832108/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832227] Re: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
não posso comentar. o texto acima está todo em inglês e somente entendo portugẽs, desculpe-me. -- 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/1832227 Title: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Status in initramfs-tools package in Ubuntu: New Bug description: está aparecendo várias vezes a mensagem de erro no sistema. não sei especificar qual erro ocorre. ProblemType: Package DistroRelease: Ubuntu 16.04 Package: linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 ProcVersionSignature: Ubuntu 4.15.0-51.55~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-51-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Thu Jun 6 06:53:20 2019 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 InstallationDate: Installed on 2019-04-28 (42 days ago) InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 (20180228) RelatedPackageVersions: dpkg 1.18.4ubuntu1.5 apt 1.2.31 SourcePackage: initramfs-tools Title: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1832227/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted
I can include this in my next systemd upload, once the current -proposed versions are released. ** Tags added: sts-sponsor-ddstreet ** Tags added: ddstreet-next -- 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/1818527 Title: Stub resolver cache is corrupted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Bug description: [Impact] systemd-resolved fails to resolve A records [Description] When systemd-resolve caches a non-existent CNAME record for a specific domain, further attempts at resolving A records for that same domain fail. This has been fixed upstream in v240. Upstream commit: https://github.com/systemd/systemd/commit/3740146a4cbd $ git describe --contains 3740146a4cbd v240~839 $ rmadison systemd --arch amd64 systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.21 | xenial-security | source, ... systemd | 229-4ubuntu21.21 | xenial-updates | source, ... systemd | 237-3ubuntu10| bionic | source, ... systemd | 237-3ubuntu10.19 | bionic-security | source, ... systemd | 237-3ubuntu10.21 | bionic-updates | source, ... systemd | 237-3ubuntu10.22 | bionic-proposed | source, ... systemd | 239-7ubuntu10| cosmic | source, ... systemd | 239-7ubuntu10.12 | cosmic-security | source, ... systemd | 239-7ubuntu10.13 | cosmic-updates | source, ... systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ... systemd | 240-6ubuntu5 | disco | source, ... systemd | 240-6ubuntu5.1 | disco-proposed | source, ... systemd | 240-6ubuntu9 | eoan| source, ... Despite the package versions above, only Bionic is affected. Cosmic already includes a backported fix, and Xenial doesn't seem affected due to resolvconf handling DNS resolution. [Test Case] Flush resolved's caches and try resolving a non-existent CNAME record. Further resolution attempts for the corresponding A record will fail: $ systemd-resolve --flush-caches $ dig github.com CNAME $ dig github.com A [Regression Potential] The regression potential for this fix should be very low, as it's a direct cherry-pick from upstream systemd. It has seen extensive testing in both upstream and other Ubuntu releases, and was verified for Bionic through autopkgtests. [Original Description] It seems that when systemd-resolve cache an non-existent CNAME record for a domain, any attempt to resolve A record for the same domain fail. systemd version the issue has been seen with Installed: 237-3ubuntu10.13 Used distribution Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic Expected behaviour you didn't see Return A record for a domain when it exists. Unexpected behaviour you saw Resolution failed. Steps to reproduce the problem Whait for 1 minutes (github.com TTL for A record) Try to resolv github.com CNAME record dig CNAME github.com This will return an empty result. Then try to resolve github.com A record dig A github.com. This will now return empty result unless you restart systemd-resolved or wait for cache expiration. At the same time using another DNS will resolve correctly dig A github.com @8.8.8.8. Exemple : Wait for 1 minutes to let cache expire, then run dig CNAME github.com dig A github.com # no result dig A github.com @8.8.8.8 # ;; ANSWER SECTION: # github.com. 59 IN A 192.30.253.113 # github.com. 59 IN A 192.30.253.112 PS: Don't forget to restart systemd-resolve, before trying to post an answer. This bug was first reported in github https://github.com/systemd/systemd/issues/11789 but systemd version in ubuntu is too old. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832227] [NEW] package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Public bug reported: está aparecendo várias vezes a mensagem de erro no sistema. não sei especificar qual erro ocorre. ProblemType: Package DistroRelease: Ubuntu 16.04 Package: linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 ProcVersionSignature: Ubuntu 4.15.0-51.55~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-51-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Thu Jun 6 06:53:20 2019 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 InstallationDate: Installed on 2019-04-28 (42 days ago) InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 (20180228) RelatedPackageVersions: dpkg 1.18.4ubuntu1.5 apt 1.2.31 SourcePackage: initramfs-tools Title: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package xenial -- 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/1832227 Title: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Status in initramfs-tools package in Ubuntu: New Bug description: está aparecendo várias vezes a mensagem de erro no sistema. não sei especificar qual erro ocorre. ProblemType: Package DistroRelease: Ubuntu 16.04 Package: linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 ProcVersionSignature: Ubuntu 4.15.0-51.55~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-51-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Thu Jun 6 06:53:20 2019 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 InstallationDate: Installed on 2019-04-28 (42 days ago) InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 (20180228) RelatedPackageVersions: dpkg 1.18.4ubuntu1.5 apt 1.2.31 SourcePackage: initramfs-tools Title: package linux-image-4.15.0-51-generic 4.15.0-51.55~16.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1832227/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828171] Re: New toolchain updates need to be rebuilt against -security only
Ok, packages look fine from the releasability POV. Let me double-confirm with security if those are good to go and then perform the copies. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1828171 Title: New toolchain updates need to be rebuilt against -security only Status in binutils package in Ubuntu: New Status in eclipse-titan package in Ubuntu: New Status in gcc-7 package in Ubuntu: New Status in gcc-7-cross package in Ubuntu: New Status in gcc-7-cross-ports package in Ubuntu: New Status in gcc-8 package in Ubuntu: New Status in gcc-8-cross package in Ubuntu: New Status in gcc-8-cross-ports package in Ubuntu: New Status in gcc-defaults package in Ubuntu: New Status in gcc-defaults-ports package in Ubuntu: New Status in ggcov package in Ubuntu: New Status in binutils source package in Bionic: Fix Committed Status in eclipse-titan source package in Bionic: Fix Committed Status in gcc-7 source package in Bionic: Fix Committed Status in gcc-7-cross source package in Bionic: Fix Committed Status in gcc-7-cross-ports source package in Bionic: Fix Committed Status in gcc-8 source package in Bionic: Fix Committed Status in gcc-8-cross source package in Bionic: Fix Committed Status in gcc-8-cross-ports source package in Bionic: Fix Committed Status in gcc-defaults source package in Bionic: Fix Committed Status in gcc-defaults-ports source package in Bionic: Fix Committed Status in ggcov source package in Bionic: Fix Committed Status in binutils source package in Cosmic: Fix Committed Status in eclipse-titan source package in Cosmic: Fix Committed Status in gcc-7 source package in Cosmic: Fix Committed Status in gcc-7-cross source package in Cosmic: Fix Committed Status in gcc-7-cross-ports source package in Cosmic: Fix Committed Status in gcc-8 source package in Cosmic: Fix Committed Status in gcc-8-cross source package in Cosmic: Fix Committed Status in gcc-8-cross-ports source package in Cosmic: Fix Committed Status in gcc-defaults source package in Cosmic: Fix Committed Status in gcc-defaults-ports source package in Cosmic: Fix Committed Status in ggcov source package in Cosmic: Fix Committed Bug description: [Impact] With LP: #1814369, the toolchain packages have been updated in both cosmic and bionic, but due to an error those packages were built in -proposed as any regular SRU. For toolchain updates there exists a policy that those should be always built against -security *only*, and then released to both -security and -updates. Since this is not the case with the current toolchain update, we need to no-change rebuild all of the previously released toolchain packages in a -security enabled devirt PPA, sync them to -proposed with binaries and then release into the archives. [Regression Potential] As these are toolchain packages, there is always some regression potential. These will be no-change rebuilds so in theory the risk should be low, but the current versions of the packages have not been built against -security only before. It is hard to say how any regressions could manifest themselves. [Test Case] Making sure there are no reported regressions in the GCC and binutils test suites. Hopefully this will be sufficient. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1828171/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832224] [NEW] battery status always shows "Estimating.........."
Public bug reported: This is lenovo G560 laptop. ** Affects: upower (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/1832224 Title: battery status always shows "Estimating.." Status in upower package in Ubuntu: New Bug description: This is lenovo G560 laptop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1832224/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1814653] Re: get_python_lib() returns path to python3 instead of python3.6
Reported this to the correct package: https://bugs.launchpad.net/ubuntu/+source/python3-stdlib- extensions/+bug/1832215 -- 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/1814653 Title: get_python_lib() returns path to python3 instead of python3.6 Status in python3-defaults package in Ubuntu: Confirmed Bug description: Python version is Python 3.6.7 (default, Oct 22 2018, 11:32:17) Ubuntu 18.04.01 When I call get_python_lib() function to get the Python lib path to install a module it returns '/usr/lib/python3/dist-packages' instead of python3.6 dir: python3 -c "from distutils.sysconfig import *;print(get_python_lib())" This is because the source code '/usr/lib/python3.6/distutils/sysconfig.py' has the branch on Ubuntu: Code: if os.name == "posix": libpython = os.path.join(prefix, "lib", "python" + get_python_version()) if standard_lib: return libpython elif (is_default_prefix and 'PYTHONUSERBASE' not in os.environ and 'VIRTUAL_ENV' not in os.environ and 'real_prefix' not in sys.__dict__ and sys.prefix == sys.base_prefix): return os.path.join(prefix, "lib", "python3", "dist-packages") However, this code does not present in the original cpython code 3.6.7: https://github.com/python/cpython/blob/ca7d2933a388677cc3bbc621913b479452c0f25a/Lib/distutils/sysconfig.py#L109 Is it the right behavior? Why the get_python_lib() result should depend on PYTHONUSERBASE and VIRTUAL_ENV and points to python3 instead of python3.6 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: python3 3.6.7-1~18.04 ProcVersionSignature: Ubuntu 4.15.0-44.47-generic 4.15.18 Uname: Linux 4.15.0-44-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Feb 5 12:41:28 2019 InstallationDate: Installed on 2018-09-06 (151 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: python3-defaults UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1814653/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1829872] Re: No more desktop effects since libdrm upgrade in Bionic
I could reproduce the downgrade issue, libgl1-mesa-dri wanted the newer
libdrm-amdgpu1 but apt failed to tell that in a sensible way.. so
downgrading libgl1-mesa-dri was needed in order to downgrade libdrm
anyway, closing now
** Changed in: libdrm (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libdrm in Ubuntu.
https://bugs.launchpad.net/bugs/1829872
Title:
No more desktop effects since libdrm upgrade in Bionic
Status in libdrm package in Ubuntu:
Invalid
Bug description:
Hello.
I upgraded my system on 2019-05-09 and since then desktop effects do not work
anymore. It installed
a new libdrm stack :
$ grep -A 3 "2019-05-09 *08:53:53" /var/log/apt/history.log | tail -n 1 | awk
-F "," '{for(i=1;i<=NF;i++){print $i}}' | grep -A1 libdrm
libdrm-nouveau2:amd64 (2.4.95-1~18.04.1
2.4.97-1ubuntu1~18.04.1)
--
libdrm-amdgpu1:amd64 (2.4.95-1~18.04.1
2.4.97-1ubuntu1~18.04.1)
--
libdrm2:amd64 (2.4.95-1~18.04.1
2.4.97-1ubuntu1~18.04.1)
--
libdrm-intel1:amd64 (2.4.95-1~18.04.1
2.4.97-1ubuntu1~18.04.1)
--
libdrm-radeon1:amd64 (2.4.95-1~18.04.1
2.4.97-1ubuntu1~18.04.1)
--
libdrm-common:amd64 (2.4.95-1~18.04.1
2.4.97-1ubuntu1~18.04.1)
I have an ATI Radeon that was working fine with KDE until then. I waited to
see if someone had realized it before creating a bug report... It really is
annoying : no more transparency, no
more auto-hide of windows : my workflow is strongly impacted.
System information :
$ lsb_release -rd
Description:Ubuntu 18.04.2 LTS
Release:18.04
$ apt-cache policy libdrm2
libdrm2:
Installé : 2.4.97-1ubuntu1~18.04.1
Candidat : 2.4.97-1ubuntu1~18.04.1
Table de version :
*** 2.4.97-1ubuntu1~18.04.1 500
500 http://fr.archive.ubuntu.com/ubuntu bionic-proposed/main amd64
Packages
100 /var/lib/dpkg/status
2.4.95-1~18.04.1 500
500 http://fr.archive.ubuntu.com/ubuntu bionic-updates/main amd64
Packages
2.4.91-2 500
500 http://fr.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
BootLog: Error: [Errno 13] Permission non accordée: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: KDE
DistUpgraded: Fresh install
DistroCodename: bionic
DistroRelease: Ubuntu 18.04
DistroVariant: ubuntu
GraphicsCard:
Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07)
(prog-if 00 [VGA controller])
Subsystem: Dell Skylake GT2 [HD Graphics 520] [1028:06b2]
Subsystem: Dell Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430 / R7
M520] [1028:06b2]
InstallationDate: Installed on 2018-05-05 (397 days ago)
InstallationMedia: Kubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
MachineType: Dell Inc. Inspiron 5759
Package: libdrm (not installed)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-51-generic
root=UUID=2c061bef-bc89-4985-8670-ada8d7af157a ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
Tags: bionic ubuntu
Uname: Linux 4.15.0-51-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo vboxusers
wireshark
_MarkForUpload: True
dmi.bios.date: 12/21/2015
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.1.5
dmi.board.name: 05NVNV
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias:
dmi:bvnDellInc.:bvr1.1.5:bd12/21/2015:svnDellInc.:pnInspiron5759:pvr:rvnDellInc.:rn05NVNV:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: Inspiron 5759
dmi.sys.vendor: Dell Inc.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1.1~18.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.2-1ubuntu1.1~18.04.1
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel
2:2.99.917+git20171229-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1829872/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1830340] Re: icu 63.2 makes acorn ftbfs (*** stack smashing detected ***: terminated)
Seems to have been fixed in the -2 upload currently in proposed... ** Changed in: icu (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1830340 Title: icu 63.2 makes acorn ftbfs (*** stack smashing detected ***: terminated) Status in icu package in Ubuntu: Fix Released Status in icu package in Debian: Fix Released Bug description: https://launchpad.net/ubuntu/+source/acorn/5.5.3+ds3-3/+build/16839533 As you can see, the package is now FTBFS. I traced down this to be an icu problem, by starting from a disco chroot and then manually upgrading packages until I got the icu update. I can confirm also icu from debian experimental (and Debian chroot) has the same issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1830340/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
