[Touch-packages] [Bug 1733321] Re: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18
** Tags removed: block-proposed-eoan -- 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/1733321 Title: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18 Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Artful: Won't Fix Status in network-manager source package in Bionic: Fix Committed Status in network-manager source package in Disco: Won't Fix Status in network-manager source package in Eoan: Fix Released Status in network-manager source package in Focal: Fix Committed Bug description: [Impact] The killswitches-no-urfkill autopkgtest fails sometimes because nmcli reports the old state when it's called right after rfkill block/unblock. ppc64el ADT log from failed testcase: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-artful/artful/ppc64el/n/network- manager/20171120_100719_28642@/log.gz Testcase output: - autopkgtest [10:04:48]: test killswitches-no-urfkill: [--- make -C /lib/modules/4.13.0-17-generic/build KBUILD_SRC=/lib/modules/4.13.0-17-generic/build M=/tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests make[1]: Entering directory '/usr/src/linux-headers-4.13.0-17-generic' AR /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/built-in.o CC [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.o Building modules, stage 2. MODPOST 1 modules CC /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.mod.o LD [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.ko make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-17-generic' ERROR: NM could not track device state. autopkgtest [10:05:20]: test killswitches-no-urfkill: ---] autopkgtest [10:05:20]: test killswitches-no-urfkill: - - - - - - - - - - results - - - - - - - - - - killswitches-no-urfkill FAIL non-zero exit status 1 - Package versions [artful/ppc64el]: network-manager 1.8.4-1ubuntu3 linux-meta 4.13.0.17.18 [Test Case] Assume that test vm and host are ppc64 1. deploy ppc64 vm instance ( with 1 cpu ) 2. modprobe mac80211_hwsim ( may need to install linux-modules-extra- pkg ) 3. apt install network-manager rfkill 4. modify /etc/netplan/[conf], renderer as NetworkManager 5. netplan apply 6. run below command - nmcli radio wifi ; rfkill list 0 ; rfkill block 0 ; rfkill list 0 ; nmcli radio wifi ; rfkill list 0 ; rfkill unblock 0 ; rfkill list 0 ; nmcli radio wifi enabled 0: fake: Wireless LAN Soft blocked: no Hard blocked: no 0: fake: Wireless LAN Soft blocked: yes Hard blocked: no enabled 0: fake: Wireless LAN Soft blocked: yes Hard blocked: no 0: fake: Wireless LAN Soft blocked: no Hard blocked: no enabled second 'enabled' should be 'disabled' but not updated properly. Adding "udevadm settle" in test file ( killswitches-no-urkfill ) between rfkill block/unblock and nmcli radio wifi will help updating status changes after rfkill block/unblock. [Regression Potential] This fixes testcase only, so any regression would cause incorrect test pass/fail, and might cause other missed bugs. [scope] this is needed for all releases. Debian does not include this autopkgtest, and so does not need this fix. [Other Info] this is caused by the 'systemd-rfkill.socket' listening to rfkill, and starting up 'systemd-rfkill.service' for any change. On a 1-cpu system (which all autopkgtest instances for network-manager are), this service startup sometimes blocks the uevent from reaching network- manager before the autopkgtest proceeds to call nmcli to check the rfkill status. This causes the test case to fail. There are (at least) 2 options to fix this: 1) stop/disable the 'systemd-rfkill.socket' at the start of the autopkgtest 2) call udevadm settle between the rfkill block/unblock and the nmcli call to check status This does not need to be fixed outside the test case, as normal nmcli use should be not done by users in a script immediately after changing rfkill state, nor is there anything that either rfkill or nmcli could even do to address this (technically, nmcli could internally issue a 'udevadm settle' every time it's called, but that seems paranoid and extreme). [original description] On ppc64el architecture, it was observed that a fix for systemd is also needed (see bug 1734908) for the testcase to be successful. # original test case 2.1. Download network-manager package source code $ apt-get source network-manager 2.2. Run killswitches-no-urfkill testcase $ cd network-manager-1.8.4 $ sudo ./debian/tests/killswitches-no-urfkill To manage notifications about this bug go
[Touch-packages] [Bug 1867157] Re: Improve command-not-found package headers
** No longer affects: python3.8 (Ubuntu Focal) -- 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/1867157 Title: Improve command-not-found package headers Status in python-defaults package in Ubuntu: Fix Released Status in python2.7 package in Ubuntu: Fix Released Status in python3-defaults package in Ubuntu: Fix Released Status in python3.8 package in Ubuntu: Fix Released Bug description: Improve command-not-found package headers command-not-found uses package metadata, and to improve the UX of the misspelled commands / proposed packages. python2.7-minimal should gain XB-Cnf-Visible-Pkgname: python2.7 python3.8-minimal should gain XB-Cnf-Visible-Pkgname: python3.8 python2-minimal should gain XB-Cnf-Visible-Pkgname: python2 python3-minimal should gain XB-Cnf-Visible-Pkgname: python3 This will then improve these messages from: """ command 'python2.7' from deb python2.7-minimal (2.7.17-1) command 'python3.8' from deb python3.8-minimal (3.8.0-5) command 'python2' from deb python2-minimal (2.7.17-2) command 'python3' from deb python3-minimal (3.7.5-1ubuntu1) """ To """ command 'python2.7' from deb python2.7 (2.7.17-1) command 'python3.8' from deb python3.8 (3.8.0-5) command 'python2' from deb python2 (2.7.17-2) command 'python3' from deb python3 (3.7.5-1ubuntu1) """ python3 should drop XB-Cnf-Extra-Commands: python XB-Cnf-Priority-Bonus: 5 Such that it stops suggesting that somehow python is available from python3 package, which is a lie. There is a special case for "python" command hint in command-not-found already, which simply points people to "python3". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1867157/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906600] Re: WiFi disconnects continually (goes "down" in NetworkManager)
Please test latest mainline kernel: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10-rc6/amd64/ ** Changed in: linux (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1906600 Title: WiFi disconnects continually (goes "down" in NetworkManager) Status in Ubuntu MATE: Confirmed Status in linux package in Ubuntu: Incomplete Status in network-manager package in Ubuntu: Confirmed Bug description: Hello everybody and thank you in advance for your help. After a recent update, my machine rebooted and appeared to be fine, but after a short time the WiFi dropped and the NetworkManager applet shows that the interface is down. I am also getting prompted for a password (which was previously saved) and when I click on connect it will establish the connection for a short time, but then goes down again. In some cases this is immediate in others, I will be online for up to approximately 15 minutes before it goes down again. I have tried restarting NetworkManager, but I get the same results (short time up, then down). I tried to review log data, but I am not a linux expert and so I'm not sure that I am looking at the right log, nor do I know exactly what to look for. Here are some lines from around the time of the disconnect and the restarting of NetworkManager: ' Dec 01 21:13:24 bryan-HP-Notebook NetworkManager[22616]: [1606875204.3541] dhcp4 (wlo1): state changed unknown -> bound Dec 01 21:13:24 bryan-HP-Notebook NetworkManager[22616]: [1606875204.3698] device (wlo1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') Dec 01 21:13:24 bryan-HP-Notebook NetworkManager[22616]: [1606875204.3772] device (wlo1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed') Dec 01 21:13:24 bryan-HP-Notebook NetworkManager[22616]: [1606875204.3856] device (wlo1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') Dec 01 21:13:24 bryan-HP-Notebook NetworkManager[22616]: [1606875204.3882] manager: NetworkManager state is now CONNECTED_SITE Dec 01 21:13:24 bryan-HP-Notebook NetworkManager[22616]: [1606875204.3945] device (wlo1): Activation: successful, device activated. Dec 01 21:13:24 bryan-HP-Notebook NetworkManager[22616]: [1606875204.3969] manager: NetworkManager state is now CONNECTED_GLOBAL Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.8909] device (wlo1): supplicant interface state: completed -> authenticating Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.8910] device (p2p-dev-wlo1): supplicant management interface state: completed -> authenticating Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9011] device (wlo1): supplicant interface state: authenticating -> associating Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9012] device (p2p-dev-wlo1): supplicant management interface state: authenticating -> associating Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9222] device (wlo1): supplicant interface state: associating -> 4-way handshake Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9222] device (p2p-dev-wlo1): supplicant management interface state: associating -> 4-way handshake Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9223] sup-iface[0x562ab0adb110,wlo1]: connection disconnected (reason -1) Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9297] device (wlo1): supplicant interface state: 4-way handshake -> disconnected Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9318] device (wlo1): Activation: (wifi) disconnected during association, asking for new key Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9321] device (wlo1): state change: activated -> need-auth (reason 'supplicant-disconnect', sys-iface-state: 'managed') Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9526] dhcp4 (wlo1): canceled DHCP transaction Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9527] dhcp4 (wlo1): state changed bound -> done Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9544] manager: NetworkManager state is now CONNECTING Dec 01 21:15:48 bryan-HP-Notebook NetworkManager[22616]: [1606875348.9603] device (p2p-dev-wlo1): supplicant management interface state: 4-way handshake -> disconnected Dec 01 21:15:49 bryan-HP-Notebook NetworkManager[22616]: [1606875349.4819] device (wlo1): supplicant interface state: disconnected -> scanning Dec 01 21:15:49 bryan-HP-Notebook
[Touch-packages] [Bug 1893563] Re: netplan: can't login to ap mode with psk
Needs https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/ae31b4bf4eaa9eab9409c59dd420140f5fe6b697 and https://w1.fi/cgit/hostap/commit/?id=1c58317f56e312576b6872440f125f794e45f991 ** Also affects: wpasupplicant (Ubuntu) Importance: Undecided Status: New ** Changed in: wpasupplicant (Ubuntu) Importance: Undecided => Medium ** Package changed: wpasupplicant (Ubuntu) => wpa (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1893563 Title: netplan: can't login to ap mode with psk Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Triaged Status in wpa package in Ubuntu: New Bug description: I've setup my wifi cards as ap over a bridge using netplan. If I add: auth: key-management: psk password: "testinglang" then my clients are unable to connect. If I remove those lines above in netplan then the clients are able to connect but without a password. If I run wpa_cli -i wlp3s0 status, I get: bssid=4c:1d:96:71:a3:90 freq=2412 ssid=walad2 id=0 mode=AP pairwise_cipher=CCMP+TKIP group_cipher=TKIP key_mgmt=UNKNOWN wpa_state=COMPLETED p2p_device_address=4c:1d:96:71:a3:91 address=4c:1d:96:71:a3:90 uuid=85d86b40-7e3d-5fc5-b5fc-aae9af55b29a I notice that key_mgmt=UNKNOWN. Perhaps that's the problem? Any pointers on how to debug and fix this? ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: netplan.io 0.99-0ubuntu3~20.04.2 ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 Uname: Linux 5.4.0-42-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: pass Date: Sun Aug 30 23:11:48 2020 InstallationDate: Installed on 2020-08-16 (14 days ago) InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: netplan.io UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1893563/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906701] Re: Please merge logrotate 3.17.0-1 (main) from Debian unstable (main)
** Changed in: logrotate (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to logrotate in Ubuntu. https://bugs.launchpad.net/bugs/1906701 Title: Please merge logrotate 3.17.0-1 (main) from Debian unstable (main) Status in logrotate package in Ubuntu: Confirmed Bug description: Please merge logrotate 3.17.0-1 (main) from Debian unstable (main) At the time of filling this bug, the target debian unstable version is 3.17.0-2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1906701/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
have tested using libsasl2-modules=2.1.27~101-g0780600+dfsg-3ubuntu2.2, libsasl2-modules-db=2.1.27~101-g0780600+dfsg-3ubuntu2.2, libsasl2 -modules-gssapi-mit=2.1.27~101-g0780600+dfsg-3ubuntu2.2 and adcli=0.8.2-1ubuntu1.1 Join to AD without specifying --use-ldaps seemed to run without error. So from my perspective I'd say those combination of packages fixes the problem. Thanks -J -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake,
[Touch-packages] [Bug 1891632] Re: The network manager does not check the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE bit
** Changed in: oem-priority Status: New => Fix Committed ** Changed in: oem-priority Status: Fix Committed => Fix Released -- 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/1891632 Title: The network manager does not check the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE bit Status in OEM Priority Project: Fix Released Status in OEM Priority Project focal series: Invalid Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Focal: Fix Released Bug description: [Impact] In some cases, the wow is not configured and the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE is set (for to disable management of wake-on-LAN in NetworkManager). The network manager only checks the NM_SETTING_WIRELESS_WAKE_ON_WLAN_NONE bit. But, the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE does not be check. So, the management of wake-on-LAN still is done by NetworkManager. The killer 500s Wi-Fi does not want the network-manger to manager the wake-on-LAN so the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE is set. (The driver will manager itself.) When the network-manager managers the wake-on-LAN, all of the Wi-Fi functions will be lost after the OS resumed from suspend. [Test Case] On a machine with killer 500s Wi-Fi and install the Qualcomm's driver. Step 1. Enter suspend (s2idle) Setp 2. Resume from suspend After resume from suspend, the Wi-Fi function still is normal. You can download the kernel and linux-firmware that backport the Qucalcomm's dirver fro focal from below link: https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1879633 [Regression Potential] * This patch modifies the wake on lan parameters, please test that the corresponding feature still works fine with the different configuration values. 1. Magic packet test: Set Wake on Wireless to off Send magic packet to the system Ensure it does not wake up Set Wake on Wirless to on Send magic packet to the system Ensure it does wake up 2. Wi-Fi function test after resumed from suspend: After resume from suspend, the Wi-Fi should work normally. Scan APs. Connect to an AP. [Other Info] * platform: add the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE status check (!597) · Merge Requests · NetworkManager / NetworkManager · GitLab - https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/597#note_588639 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1891632/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906627] Autopkgtest regression report (cyrus-sasl2/2.1.27~101-g0780600+dfsg-3ubuntu2.2)
All autopkgtests for the newly accepted cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3ubuntu2.2) for bionic have finished running. The following regressions have been reported in tests triggered by the package: kimap/17.12.3-0ubuntu1 (s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#cyrus-sasl2 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Hello Rolf, or anyone else affected, Accepted adcli into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/adcli/0.8.2-1ubuntu1.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: adcli (Ubuntu Bionic) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends:
[Touch-packages] [Bug 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8
** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Bionic) Status: New => In Progress -- 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/1905245 Title: "Failed to parse bus message: Invalid argument" with Linux 5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Bug description: [impact] newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show' [test case] install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel. Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it: ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument the command should correctly show the value, e.g.: $ systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override ...etc... [regression potential] a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services. [scope] this is needed only in focal (and possibly bionic). This is fixed upstream by PR 16424: https://github.com/systemd/systemd/pull/16424 which was first included in v246, so this is already fixed in groovy and later. this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle. For b, unless a kernel is added that includes a new capability, this patch is not needed. [original description] When I run `systemctl show myservice.service`, I get the following error message: Failed to parse bus message: Invalid argument systemd version: 245.4-4ubuntu3.3 linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge) This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926 Please can we port the fix to the ubuntu 20.04 version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905245/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1905044] Re: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8
** Changed in: systemd (Ubuntu Hirsute) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Groovy) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Groovy) Status: New => In Progress ** Changed in: systemd (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Bionic) Status: New => In Progress ** Changed in: systemd (Ubuntu Hirsute) Status: Invalid => In Progress -- 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/1905044 Title: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8 Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Status in systemd source package in Hirsute: In Progress Bug description: [impact] autopkgtest failure when running with 5.8 kernel [test case] see autopkgtest results, e.g. links in original description below [regression potential] as this only fixes a test case, any regression would likely result in an incorrectly passing, or incorrectly failing, test. [scope] this is needed for b/f/g/h. this bug was introduced by upstream commit 23cc81e7c22 which first added testing for 'invalid' cap numbers, but incorrectly using capability_list_length() instead of cap_last_cap(). That commit was first included in v236, so this bug does not existing before Bionic. this is fixed upstream by commit ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in v247, so this is needed for h and earlier. Also note that even though the 5.8 kernel is not planned to be released for Bionic, this test also runs at build time, and since the LP build farm builds inside chroots, if the build farm ever moved up to Focal with a 5.8 kernel, the build of systemd for Bionic would start failing, so this does need to be fixed in Bionic systemd as well. [other info] there is a non-test bug related to this in bug 1905245 [original description] Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20201117_174614_4ece6@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20201117_221555_48b91@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/s/systemd/20201117_175806_e779f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20201117_153051_90e7e@/log.gz The failing testcases are: - root-unittests Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at src/test/test-cap-list.c:60, funct ion test_capability_set_one(). Aborting. FAIL: test-cap-list (code: 134) - upstream TEST-24-UNIT-TESTS: --- test-cap-list begin --- Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at src/test/test-cap-list.c:60, funct ion test_capability_set_one(). Aborting. --- test-cap-list end --- Both seem to be failing with the same assertion. These tests are successful on Focal with linux 5.4, therefore they would regress when upgrading the kernel from 5.4 to 5.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905044/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906364] Re: [SRU] unattended-upgrade still restarts blacklisted daemons
** Merge proposal linked: https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/docker.io/+git/docker.io/+merge/395171 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1906364 Title: [SRU] unattended-upgrade still restarts blacklisted daemons Status in docker.io package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Won't Fix Status in docker.io source package in Xenial: In Progress Status in unattended-upgrades source package in Xenial: Won't Fix Status in docker.io source package in Bionic: In Progress Status in unattended-upgrades source package in Bionic: Won't Fix Status in docker.io source package in Focal: In Progress Status in unattended-upgrades source package in Focal: Won't Fix Status in docker.io source package in Groovy: In Progress Status in unattended-upgrades source package in Groovy: Won't Fix Status in docker.io source package in Hirsute: Fix Released Status in unattended-upgrades source package in Hirsute: Won't Fix Bug description: [Impact] Docker uses containerd under the hood. When containerd is upgraded it stops and restarts its service; docker stops when containerd stops but doesn’t restart. Particularly when doing unattended upgrades, an SRU fix rolled out for containerd can result in unexpected and widespread service outages for docker. [Test Case] $ sudo apt install docker.io $ sudo systemctl start docker $ systemctl status docker | grep Active Active: active (running) since[...] $ systemctl status containerd | grep Active Active: active (running) since[...] $ docker pull ubuntu/redis:latest $ docker run -e REDIS_PASSWORD=1234 --network host \ --name test-redis -d ubuntu/redis:latest $ telnet localhost 6379 $ docker container logs test-redis $ sudo apt install --reinstall containerd $ systemctl status containerd | grep Active Active: active (running) since $ systemctl status docker | grep Active Active: inactive (dead) since [...]; 8s ago $ docker container logs test-redis [Where Problems Could Occur] The challenge with this issue is addressing all important corner cases, and as such the biggest risk is that we miss a corner case and fail to keep the two services running when they should. Areas to watch will be failures during start/stop/restart/upgrade type operations. Issues during runtime are unlikely to relate to this change. [Original Report] Hello, Today plenty of our systems running ubuntu 20.04 were restarting the docker daemon, even if i blacklisted the docker package. Since docker has an dependency on containerd thats the reason why it was restarted. IMO the blacklist should also check the full tree of dependencies... This should NOT happen! From the log you find: 2020-12-01 06:40:13,881 INFO Starting unattended upgrades script 2020-12-01 06:40:13,882 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:13,882 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:13,882 INFO Initial whitelist (not strict): 2020-12-01 06:40:19,139 INFO Packages that will be upgraded: containerd qemu-block-extra qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils 2020-12-01 06:40:19,140 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log 2020-12-01 06:40:46,996 INFO All upgrades installed 2020-12-01 06:40:50,732 INFO Starting unattended upgrades script 2020-12-01 06:40:50,732 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:50,733 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:50,733 INFO Initial whitelist (not strict): Also this happened for us on plenty of our servers almost at the same (why the unattended updates are not spread over time?), which destroyed the second time an production environment. This is not how unattended-upgraded should be, sadly this package lost our trust and we disable it and schedule the 'unattended updates' now on our own. PS: Not to say that on some servers the docker daemon did not even restart.. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1906364/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906364] Re: [SRU] unattended-upgrade still restarts blacklisted daemons
** Merge proposal linked: https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/docker.io/+git/docker.io/+merge/395167 ** Merge proposal linked: https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/docker.io/+git/docker.io/+merge/395168 ** Merge proposal linked: https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/docker.io/+git/docker.io/+merge/395169 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1906364 Title: [SRU] unattended-upgrade still restarts blacklisted daemons Status in docker.io package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Won't Fix Status in docker.io source package in Xenial: In Progress Status in unattended-upgrades source package in Xenial: Won't Fix Status in docker.io source package in Bionic: In Progress Status in unattended-upgrades source package in Bionic: Won't Fix Status in docker.io source package in Focal: In Progress Status in unattended-upgrades source package in Focal: Won't Fix Status in docker.io source package in Groovy: In Progress Status in unattended-upgrades source package in Groovy: Won't Fix Status in docker.io source package in Hirsute: Fix Released Status in unattended-upgrades source package in Hirsute: Won't Fix Bug description: [Impact] Docker uses containerd under the hood. When containerd is upgraded it stops and restarts its service; docker stops when containerd stops but doesn’t restart. Particularly when doing unattended upgrades, an SRU fix rolled out for containerd can result in unexpected and widespread service outages for docker. [Test Case] $ sudo apt install docker.io $ sudo systemctl start docker $ systemctl status docker | grep Active Active: active (running) since[...] $ systemctl status containerd | grep Active Active: active (running) since[...] $ docker pull ubuntu/redis:latest $ docker run -e REDIS_PASSWORD=1234 --network host \ --name test-redis -d ubuntu/redis:latest $ telnet localhost 6379 $ docker container logs test-redis $ sudo apt install --reinstall containerd $ systemctl status containerd | grep Active Active: active (running) since $ systemctl status docker | grep Active Active: inactive (dead) since [...]; 8s ago $ docker container logs test-redis [Where Problems Could Occur] The challenge with this issue is addressing all important corner cases, and as such the biggest risk is that we miss a corner case and fail to keep the two services running when they should. Areas to watch will be failures during start/stop/restart/upgrade type operations. Issues during runtime are unlikely to relate to this change. [Original Report] Hello, Today plenty of our systems running ubuntu 20.04 were restarting the docker daemon, even if i blacklisted the docker package. Since docker has an dependency on containerd thats the reason why it was restarted. IMO the blacklist should also check the full tree of dependencies... This should NOT happen! From the log you find: 2020-12-01 06:40:13,881 INFO Starting unattended upgrades script 2020-12-01 06:40:13,882 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:13,882 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:13,882 INFO Initial whitelist (not strict): 2020-12-01 06:40:19,139 INFO Packages that will be upgraded: containerd qemu-block-extra qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils 2020-12-01 06:40:19,140 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log 2020-12-01 06:40:46,996 INFO All upgrades installed 2020-12-01 06:40:50,732 INFO Starting unattended upgrades script 2020-12-01 06:40:50,732 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:50,733 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:50,733 INFO Initial whitelist (not strict): Also this happened for us on plenty of our servers almost at the same (why the unattended updates are not spread over time?), which destroyed the second time an production environment. This is not how unattended-upgraded should be, sadly this package lost our trust and we disable it and schedule the 'unattended updates' now on our own. PS: Not to say that on some servers the docker daemon did not even restart.. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1906364/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1907510] Re: Apt-get upgrade fails with checksum errors
I just checked the file on the server and the hashes match the expected hashes. I would try a few more times. ** Package changed: apt (Ubuntu) => linux-firmware (Ubuntu) ** Changed in: linux-firmware (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1907510 Title: Apt-get upgrade fails with checksum errors Status in linux-firmware package in Ubuntu: New Bug description: scw@ellen:~$ lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 ? I expected a number of packages to be upgraded What I got was this: Err:3 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 linux-firmware all 1.187.6 Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] - Filesize:99497284 [weak] Hashes of received file: - SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] - Filesize:99497284 [weak] Last modification reported: Thu, 26 Nov 2020 17:18:59 + Fetched 99.7 MB in 14s (6,967 kB/s) E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.187.6_all.deb Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] - Filesize:99497284 [weak] Hashes of received file: - SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] - Filesize:99497284 [weak] Last modification reported: Thu, 26 Nov 2020 17:18:59 + To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1907510/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Hello Rolf, or anyone else affected, Accepted cyrus-sasl2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cyrus- sasl2/2.1.27~101-g0780600+dfsg-3ubuntu2.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Description changed: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS-API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ - Finally, install the fixed cyrus-sasl2 package, which is available from the - below ppa: + Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test - $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus-sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: - |Suggests: ldap-utils - Depends: adcli - Conflicts: libsasl2-modules-gssapi-heimdal - |Suggests: libsasl2-modules - Conflicts: libsasl2-modules-gssapi-heimdal - |Recommends: sssd-krb5-common - |Suggests: slapd - |Suggests: libsasl2-modules - |Suggests: ldap-utils - |Depends: msktutil - Conflicts: libsasl2-modules-gssapi-heimdal - |Depends: libapache2-mod-webauthldap - Depends: freeipa-server
[Touch-packages] [Bug 1907693] Re: curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?)
Figured out that "apt update" wasn't run in fact. Sorry for false alarm. ** Changed in: curl (Ubuntu) Status: New => Invalid ** Changed in: curl (Ubuntu) Assignee: (unassigned) => Vasily Ryabov (vryabov) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1907693 Title: curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?) Status in curl package in Ubuntu: Invalid Bug description: Installation of latest curl and some other packages is broken in Ubuntu 18.04 even after apt update! The output of apt: 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/a/apt/libapt-inst2.0_1.6.12ubuntu0.1_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python-apt-common_1.6.5ubuntu0.3_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python3-apt_1.6.5ubuntu0.3_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/universe/a/apt/apt-transport-https_1.6.12ubuntu0.1_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? What I can see is that curl_7.58.0-2ubuntu3.12_amd64.deb is present! But the latest version still points to removed 3.10. How is that possible? Hope Canonical DevOps guys are already under the gun. Not sure it's correct place for such major incidents. Please re-direct it to the right team as appropriate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1907693/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907693] Re: curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?)
It worked just a few hours ago. All the work is stopped now. Arrrgh! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1907693 Title: curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?) Status in curl package in Ubuntu: New Bug description: Installation of latest curl and some other packages is broken in Ubuntu 18.04 even after apt update! The output of apt: 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/a/apt/libapt-inst2.0_1.6.12ubuntu0.1_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python-apt-common_1.6.5ubuntu0.3_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python3-apt_1.6.5ubuntu0.3_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/universe/a/apt/apt-transport-https_1.6.12ubuntu0.1_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? What I can see is that curl_7.58.0-2ubuntu3.12_amd64.deb is present! But the latest version still points to removed 3.10. How is that possible? Hope Canonical DevOps guys are already under the gun. Not sure it's correct place for such major incidents. Please re-direct it to the right team as appropriate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1907693/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907693] Re: curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?)
"apt update" was done, of course. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1907693 Title: curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?) Status in curl package in Ubuntu: New Bug description: Installation of latest curl and some other packages is broken in Ubuntu 18.04 even after apt update! The output of apt: 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/a/apt/libapt-inst2.0_1.6.12ubuntu0.1_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python-apt-common_1.6.5ubuntu0.3_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python3-apt_1.6.5ubuntu0.3_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/universe/a/apt/apt-transport-https_1.6.12ubuntu0.1_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? What I can see is that curl_7.58.0-2ubuntu3.12_amd64.deb is present! But the latest version still points to removed 3.10. How is that possible? Hope Canonical DevOps guys are already under the gun. Not sure it's correct place for such major incidents. Please re-direct it to the right team as appropriate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1907693/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907693] [NEW] curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?)
Public bug reported: Installation of latest curl and some other packages is broken in Ubuntu 18.04 even after apt update! The output of apt: 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/a/apt/libapt-inst2.0_1.6.12ubuntu0.1_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python-apt-common_1.6.5ubuntu0.3_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python3-apt_1.6.5ubuntu0.3_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/universe/a/apt/apt-transport-https_1.6.12ubuntu0.1_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? What I can see is that curl_7.58.0-2ubuntu3.12_amd64.deb is present! But the latest version still points to removed 3.10. How is that possible? Hope Canonical DevOps guys are already under the gun. Not sure it's correct place for such major incidents. Please re-direct it to the right team as appropriate. ** Affects: curl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1907693 Title: curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found in Ubuntu 18.04 (wrong update in the repo?) Status in curl package in Ubuntu: New Bug description: Installation of latest curl and some other packages is broken in Ubuntu 18.04 even after apt update! The output of apt: 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/a/apt/libapt-inst2.0_1.6.12ubuntu0.1_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python-apt-common_1.6.5ubuntu0.3_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-apt/python3-apt_1.6.5ubuntu0.3_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/universe/a/apt/apt-transport-https_1.6.12ubuntu0.1_all.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.58.0-2ubuntu3.10_amd64.deb 404 Not Found [IP: 91.189.88.152 80] 18:09:53 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? What I can see is that curl_7.58.0-2ubuntu3.12_amd64.deb is present! But the latest version still points to removed 3.10. How is that possible? Hope Canonical DevOps guys are already under the gun. Not sure it's correct place for such major incidents. Please re-direct it to the right team as appropriate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1907693/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8
** Tags removed: rls-bb-incoming rls-ff-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1905245 Title: "Failed to parse bus message: Invalid argument" with Linux 5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: New Status in systemd source package in Focal: In Progress Bug description: [impact] newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show' [test case] install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel. Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it: ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument the command should correctly show the value, e.g.: $ systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override ...etc... [regression potential] a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services. [scope] this is needed only in focal (and possibly bionic). This is fixed upstream by PR 16424: https://github.com/systemd/systemd/pull/16424 which was first included in v246, so this is already fixed in groovy and later. this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle. For b, unless a kernel is added that includes a new capability, this patch is not needed. [original description] When I run `systemctl show myservice.service`, I get the following error message: Failed to parse bus message: Invalid argument systemd version: 245.4-4ubuntu3.3 linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge) This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926 Please can we port the fix to the ubuntu 20.04 version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905245/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906078] Re: Whoopsie sends bug reports automatically without consent
** Tags removed: rls-hh-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1906078 Title: Whoopsie sends bug reports automatically without consent Status in whoopsie package in Ubuntu: Incomplete Bug description: Hello, So, I just realized about an hour ago that whoopsie has been sending bug reports without my consent since May (2020-05-11 to be exact) from checking journalctl where I can see lines like these: Uploading /var/crash/[...] Sent; server replied with: No error Response code: 200 Reported OOPS ID [...] I checked the "Diagnostics" GUI in the gnome-control-center and it does have "Send error reports to Canonical" set to "Never"... I tried switching it to "Manual" and back to "Never" and that did have an effect in /etc/, namelely when going from "Never" to "Manual": renamed:rc2.d/K01whoopsie -> rc2.d/S01whoopsie renamed:rc3.d/K01whoopsie -> rc3.d/S01whoopsie renamed:rc4.d/K01whoopsie -> rc4.d/S01whoopsie renamed:rc5.d/K01whoopsie -> rc5.d/S01whoopsie new file: systemd/system/multi-user.target.wants/whoopsie.service and the opposite effect is achieved when switching back to "Never". So far so good, I guess... My /etc/ does have a "whoopsie" file (/etc/whoopsie) which doesn't seem to be present in clean installations of Ubuntu and which has the following contents: [General] report_metrics=true Switching from "true" to "false" does seem to disable whoopsie, so that's nice I guess... but what is this file doing here in the first place? To clarify, this was originally an Ubuntu 18.04 system which I recently upgraded to 20.04 but the unsolicited error report uploads have been going on since well before the upgrade so that's not the issue. I don't remember touching anything on my system relating to apport or whoopsie and my shell history doesn't contain anything about whoopsie or apport so this situation seems to have occurred on its own (perhaps after an update?). This is a pretty serious breach of privacy (and of the GDPR) and others might also be unknowingly affected like I was, so the team in charge of this might want to push an update that for instance resets the /etc/whoopsie file if present (if that truly is the problem). While I'm at it I would like all the error reports sent from my computer to be deleted. Where can I ask for that? I haven't seen an option for that anywhere, apart from contacting dataprotect...@canonical.com. Best regards. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1906078/+subscriptions -- Mailing list: https://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 1907510] Re: Apt-get upgrade fails with checksum errors
No joy, same error. -Original Message- >From: Daniel Letzeisen <1907...@bugs.launchpad.net> >Sent: Dec 10, 2020 3:34 AM >To: s...@sprynet.com >Subject: [Bug 1907510] Re: Apt-get upgrade fails with checksum errors > >Probably just a transmission glitch. Clear out the apt cache and try again. >sudo apt-get clean >sudo apt-get update > >Let us know if it works. > >** Package changed: ubuntu => apt (Ubuntu) > >** Changed in: apt (Ubuntu) > Status: New => Incomplete > >-- >You received this bug notification because you are subscribed to the bug >report. >https://bugs.launchpad.net/bugs/1907510 > >Title: > Apt-get upgrade fails with checksum errors > >Status in apt package in Ubuntu: > Incomplete > >Bug description: > scw@ellen:~$ lsb_release -rd > Description:Ubuntu 20.04.1 LTS > Release:20.04 > ? > I expected a number of packages to be upgraded > What I got was this: > > > > > Err:3 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 > linux-firmware all 1.187.6 >Hash Sum mismatch >Hashes of expected file: > - > SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 > - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 > - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] > - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] > - Filesize:99497284 [weak] >Hashes of received file: > - > SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba > - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 > - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] > - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] > - Filesize:99497284 [weak] >Last modification reported: Thu, 26 Nov 2020 17:18:59 + > Fetched 99.7 MB in 14s (6,967 kB/s) > E: Failed to fetch > http://us.archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.187.6_all.deb > Hash Sum mismatch > Hashes of expected file: > - > SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 > - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 > - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] > - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] > - Filesize:99497284 [weak] > Hashes of received file: > - > SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba > - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 > - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] > - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] > - Filesize:99497284 [weak] > Last modification reported: Thu, 26 Nov 2020 17:18:59 + > >To manage notifications about this bug go to: >https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1907510/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1907510 Title: Apt-get upgrade fails with checksum errors Status in apt package in Ubuntu: Incomplete Bug description: scw@ellen:~$ lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 ? I expected a number of packages to be upgraded What I got was this: Err:3 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 linux-firmware all 1.187.6 Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] - Filesize:99497284 [weak] Hashes of received file: - SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] - Filesize:99497284 [weak] Last modification reported: Thu, 26 Nov 2020 17:18:59 + Fetched 99.7 MB in 14s (6,967 kB/s) E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.187.6_all.deb Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 -
[Touch-packages] [Bug 1871268] Re: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected
** Changed in: apt (Ubuntu Focal) Status: Fix Released => Triaged ** Changed in: apt (Ubuntu Groovy) Status: Fix Released => Triaged ** Changed in: apt (Ubuntu Bionic) Status: Fix Released => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1871268 Title: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected Status in Ubuntu CD Images: Fix Released Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Confirmed Status in apt source package in Focal: Triaged Status in apt source package in Groovy: Triaged Status in apt package in Debian: Unknown Bug description: [Impact] Installations that really succeeded would then fail because APT could not immediately configure a package. Which is a pointless way to fail at that point, because everything did work out anyway. So what we do is change that to a warning. [Test case] Not available right now. Issues can flare up and then disappear again. [Regression potential] It's imaginable that we missed something somewhere and some path that checked for a set error doesn't check it anymore, and we report success when we hit an error, but it seems unlikely. Behavior of --simulate changes. This used to fail before as well, and will now only produce a warning. We don't believe that is a reason of concern. [Groovy SRU] The groovy SRU is a sync of the 2.1.11 micro release from Debian unstable which also incorporates changes to the documentation: A typo fix, replacing focal with groovy in examples, and minor Dutch manual pages translation updates. We do not have test cases for the documentation changes, and we do not consider there to be a huge regression potential. As long as they build, they should be readable - maybe some words are wrong in the translation, who knows. [Original bug report] Test Case 1. Install Ubuntu Desktop on hardware with an nVidia card and select to install 3rd party drivers 2. Proceed with installation The following error message is displayed in /var/log/syslog /plugininstall.py: Verifying downloads ... /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/gcc_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxcrypt/libcrypt-dev_4.4.10-10ubuntu4_amd64.deb: "Version: '4.4.10-10ubuntu4' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/g++_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/z/zlib/zlib1g_1.2.11.dfsg-2ubuntu1_i386.deb: "Version: '1.2.11.dfsg-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxau/libxau6_1.0.9-0ubuntu1_i386.deb: "Version: '1.0.9-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdmcp/libxdmcp6_1.1.3-0ubuntu1_i386.deb: "Version: '1.1.3-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-6_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxext/libxext6_1.3.4-0ubuntu1_i386.deb: "Version: '1.3.4-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/l/lm-sensors/libsensors5_3.6.0-2ubuntu1_i386.deb: "Version: '3.6.0-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-xcb1_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdamage/libxdamage1_1.1.5-1_i386.deb: "Version: '1.1.5-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxfixes/libxfixes3_5.0.3-1_i386.deb: "Version: '5.0.3-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxxf86vm/libxxf86vm1_1.1.4-1build1_i386.deb: "Version: '1.1.4-1build1' not found." /plugininstall.py: Downloads verified successfully ubiquity: Error in function: install /plugininstall.py: Exception during installation: /plugininstall.py: apt_pkg.Error: E:Could not configure 'libc6:i386'. , E:Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) /plugininstall.py: ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: ubiquity 20.04.9 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] cyrus-sasl2 has been sponsored in Bionic. I have already pinged sil2100 for its SRU verification. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] adcli option #1 has been sponsored in Bionic with the following nitpicking: * Changed version from "0.8.2-1ubuntu2.1" to "0.8.2-1ubuntu1.1" * Changed debian/control to d/control. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are
[Touch-packages] [Bug 1905044] Re: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8
** Description changed: + [impact] + + autopkgtest failure when running with 5.8 kernel + + [test case] + + see autopkgtest results, e.g. links in original description below + + [regression potential] + + as this only fixes a test case, any regression would likely result in an + incorrectly passing, or incorrectly failing, test. + + [scope] + + this is needed for b/f/g/h. + + this bug was introduced by upstream commit 23cc81e7c22 which first added + testing for 'invalid' cap numbers, but incorrectly using + capability_list_length() instead of cap_last_cap(). That commit was + first included in v236, so this bug does not existing before Bionic. + + this is fixed upstream by commit + ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in + v247, so this is needed for h and earlier. + + Also note that even though the 5.8 kernel is not planned to be released + for Bionic, this test also runs at build time, and since the LP build + farm builds inside chroots, if the build farm ever moved up to Focal + with a 5.8 kernel, the build of systemd for Bionic would start failing, + so this does need to be fixed in Bionic systemd as well. + + [other info] + + there is a non-test bug related to this in bug 1905245 + + [original description] + Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20201117_174614_4ece6@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20201117_221555_48b91@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/s/systemd/20201117_175806_e779f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20201117_153051_90e7e@/log.gz The failing testcases are: - root-unittests Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at src/test/test-cap-list.c:60, funct ion test_capability_set_one(). Aborting. FAIL: test-cap-list (code: 134) - upstream TEST-24-UNIT-TESTS: --- test-cap-list begin --- Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at src/test/test-cap-list.c:60, funct ion test_capability_set_one(). Aborting. --- test-cap-list end --- Both seem to be failing with the same assertion. These tests are successful on Focal with linux 5.4, therefore they would regress when upgrading the kernel from 5.4 to 5.8. ** Also affects: systemd (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Hirsute) Importance: Undecided Status: Invalid ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Medium -- 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/1905044 Title: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8 Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: New Status in systemd source package in Focal: Confirmed Status in systemd source package in Groovy: New Status in systemd source package in Hirsute: Invalid Bug description: [impact] autopkgtest failure when running with 5.8 kernel [test case] see autopkgtest results, e.g. links in original description below [regression potential] as this only fixes a test case, any regression would likely result in an incorrectly passing, or incorrectly failing, test. [scope] this is needed for b/f/g/h. this bug was introduced by upstream commit 23cc81e7c22 which first added testing for 'invalid' cap numbers, but incorrectly using capability_list_length() instead of cap_last_cap(). That commit was first included in v236, so this bug does not existing before Bionic. this is fixed upstream by commit ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in v247, so this is needed for h and earlier. Also note that even though the 5.8 kernel is not planned to be released for Bionic, this test also runs at build time, and since the LP build farm builds inside chroots, if the build farm ever moved up to Focal with a 5.8 kernel, the build of systemd for Bionic would start failing, so this does need to be fixed in Bionic systemd as well. [other info] there is a non-test bug related to this in bug 1905245 [original description] Testing failed on: amd64:
[Touch-packages] [Bug 1906078] Re: Whoopsie sends bug reports automatically without consent
It is indeed conceivable that I did at some point in the past fiddle with the reporting UI. That would explain it. Thanks for taking this seriously. Much appreciated! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1906078 Title: Whoopsie sends bug reports automatically without consent Status in whoopsie package in Ubuntu: Incomplete Bug description: Hello, So, I just realized about an hour ago that whoopsie has been sending bug reports without my consent since May (2020-05-11 to be exact) from checking journalctl where I can see lines like these: Uploading /var/crash/[...] Sent; server replied with: No error Response code: 200 Reported OOPS ID [...] I checked the "Diagnostics" GUI in the gnome-control-center and it does have "Send error reports to Canonical" set to "Never"... I tried switching it to "Manual" and back to "Never" and that did have an effect in /etc/, namelely when going from "Never" to "Manual": renamed:rc2.d/K01whoopsie -> rc2.d/S01whoopsie renamed:rc3.d/K01whoopsie -> rc3.d/S01whoopsie renamed:rc4.d/K01whoopsie -> rc4.d/S01whoopsie renamed:rc5.d/K01whoopsie -> rc5.d/S01whoopsie new file: systemd/system/multi-user.target.wants/whoopsie.service and the opposite effect is achieved when switching back to "Never". So far so good, I guess... My /etc/ does have a "whoopsie" file (/etc/whoopsie) which doesn't seem to be present in clean installations of Ubuntu and which has the following contents: [General] report_metrics=true Switching from "true" to "false" does seem to disable whoopsie, so that's nice I guess... but what is this file doing here in the first place? To clarify, this was originally an Ubuntu 18.04 system which I recently upgraded to 20.04 but the unsolicited error report uploads have been going on since well before the upgrade so that's not the issue. I don't remember touching anything on my system relating to apport or whoopsie and my shell history doesn't contain anything about whoopsie or apport so this situation seems to have occurred on its own (perhaps after an update?). This is a pretty serious breach of privacy (and of the GDPR) and others might also be unknowingly affected like I was, so the team in charge of this might want to push an update that for instance resets the /etc/whoopsie file if present (if that truly is the problem). While I'm at it I would like all the error reports sent from my computer to be deleted. Where can I ask for that? I haven't seen an option for that anywhere, apart from contacting dataprotect...@canonical.com. Best regards. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1906078/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] [NEW] segmentation fault when opening fd
*** This bug is a security vulnerability *** Public security bug reported: USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 ** Affects: python-apt (Ubuntu) Importance: Undecided Status: New ** Affects: python-apt (Debian) Importance: Unknown Status: Unknown ** Bug watch added: Debian Bug tracker #977000 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 ** Also affects: python-apt (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: New Status in python-apt package in Debian: Unknown Bug description: USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906364] Re: unattended-upgrade still restarts blacklisted daemons
** Description changed: + [Impact] + + Docker uses containerd under the hood. When containerd is upgraded it + stops and restarts its service; docker stops when containerd stops but + doesn’t restart. Particularly when doing unattended upgrades, an SRU + fix rolled out for containerd can result in unexpected and widespread + service outages for docker. + + [Test Case] + + $ sudo apt install docker.io + $ sudo systemctl start docker + $ systemctl status docker | grep Active + Active: active (running) since[...] + $ systemctl status containerd | grep Active + Active: active (running) since[...] + + $ docker pull ubuntu/redis:latest + $ docker run -e REDIS_PASSWORD=1234 --network host \ + --name test-redis -d ubuntu/redis:latest + $ telnet localhost 6379 + $ docker container logs test-redis + + $ sudo apt install --reinstall containerd + $ systemctl status containerd | grep Active + Active: active (running) since + $ systemctl status docker | grep Active + Active: inactive (dead) since [...]; 8s ago + $ docker container logs test-redis + + [Where Problems Could Occur] + + The challenge with this issue is addressing all important corner cases, + and as such the biggest risk is that we miss a corner case and fail to + keep the two services running when they should. Areas to watch will be + failures during start/stop/restart/upgrade type operations. Issues + during runtime are unlikely to relate to this change. + + [Original Report] + Hello, Today plenty of our systems running ubuntu 20.04 were restarting the docker daemon, even if i blacklisted the docker package. Since docker has an dependency on containerd thats the reason why it was restarted. IMO the blacklist should also check the full tree of dependencies... This should NOT happen! From the log you find: 2020-12-01 06:40:13,881 INFO Starting unattended upgrades script 2020-12-01 06:40:13,882 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:13,882 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:13,882 INFO Initial whitelist (not strict): 2020-12-01 06:40:19,139 INFO Packages that will be upgraded: containerd qemu-block-extra qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils 2020-12-01 06:40:19,140 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log 2020-12-01 06:40:46,996 INFO All upgrades installed 2020-12-01 06:40:50,732 INFO Starting unattended upgrades script 2020-12-01 06:40:50,732 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:50,733 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:50,733 INFO Initial whitelist (not strict): Also this happened for us on plenty of our servers almost at the same (why the unattended updates are not spread over time?), which destroyed the second time an production environment. This is not how unattended-upgraded should be, sadly this package lost our trust and we disable it and schedule the 'unattended updates' now on our own. PS: Not to say that on some servers the docker daemon did not even restart.. ** Summary changed: - unattended-upgrade still restarts blacklisted daemons + [SRU] unattended-upgrade still restarts blacklisted daemons -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1906364 Title: [SRU] unattended-upgrade still restarts blacklisted daemons Status in docker.io package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Won't Fix Status in docker.io source package in Xenial: In Progress Status in unattended-upgrades source package in Xenial: Won't Fix Status in docker.io source package in Bionic: In Progress Status in unattended-upgrades source package in Bionic: Won't Fix Status in docker.io source package in Focal: In Progress Status in unattended-upgrades source package in Focal: Won't Fix Status in docker.io source package in Groovy: In Progress Status in unattended-upgrades source package in Groovy: Won't Fix Status in docker.io source package in Hirsute: Fix Released Status in unattended-upgrades source package in Hirsute: Won't Fix Bug description: [Impact] Docker uses containerd under the hood. When containerd is upgraded it stops and restarts its service; docker stops when containerd stops but doesn’t restart. Particularly when doing unattended upgrades, an SRU fix rolled out for containerd can result in unexpected and widespread service outages for docker. [Test Case] $ sudo apt install docker.io $ sudo systemctl start docker $ systemctl status docker | grep Active
[Touch-packages] [Bug 1907510] Re: Apt-get upgrade fails with checksum errors
Probably just a transmission glitch. Clear out the apt cache and try again. sudo apt-get clean sudo apt-get update Let us know if it works. ** Package changed: ubuntu => apt (Ubuntu) ** Changed in: apt (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1907510 Title: Apt-get upgrade fails with checksum errors Status in apt package in Ubuntu: Incomplete Bug description: scw@ellen:~$ lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 ? I expected a number of packages to be upgraded What I got was this: Err:3 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 linux-firmware all 1.187.6 Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] - Filesize:99497284 [weak] Hashes of received file: - SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] - Filesize:99497284 [weak] Last modification reported: Thu, 26 Nov 2020 17:18:59 + Fetched 99.7 MB in 14s (6,967 kB/s) E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.187.6_all.deb Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] - Filesize:99497284 [weak] Hashes of received file: - SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] - Filesize:99497284 [weak] Last modification reported: Thu, 26 Nov 2020 17:18:59 + To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1907510/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907510] [NEW] Apt-get upgrade fails with checksum errors
You have been subscribed to a public bug: scw@ellen:~$ lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 ? I expected a number of packages to be upgraded What I got was this: Err:3 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 linux-firmware all 1.187.6 Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] - Filesize:99497284 [weak] Hashes of received file: - SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] - Filesize:99497284 [weak] Last modification reported: Thu, 26 Nov 2020 17:18:59 + Fetched 99.7 MB in 14s (6,967 kB/s) E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.187.6_all.deb Hash Sum mismatch Hashes of expected file: - SHA512:b198b64b10643e8515f870c1e8e3edcfec446d1ff82780d50d04b859e14a3448f22ffe1d42a25c73fe8e746e4a764032798d02fdf3287cd8eb378f903d358a59 - SHA256:9e128cf120150f7165b94edd1ac0e0ab32aa799b427523d98abcfe68030b6e12 - SHA1:366eb2906eceb6acf17f4db1e6b02f8b4542f2e4 [weak] - MD5Sum:d6b26be80cf8a51822628cd412202b81 [weak] - Filesize:99497284 [weak] Hashes of received file: - SHA512:6c842fe3eaaa4148939a8dc59472e4229f221b500ea5c7d506d62b218c3d42b9f352f3ae7dc75fc7c9b9bae743abcfce45e5145cf9a05b976c32fb94e713deba - SHA256:429e462403f7680d8377d845ab0d1be8b625339d24a440d226d0622af9a56d98 - SHA1:d506c2bf77b76b5b3e8c008b649a066353dc999f [weak] - MD5Sum:1f56350abd87c4bc6bb3291f0412cded [weak] - Filesize:99497284 [weak] Last modification reported: Thu, 26 Nov 2020 17:18:59 + ** Affects: apt (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: bot-comment -- Apt-get upgrade fails with checksum errors https://bugs.launchpad.net/bugs/1907510 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1899262] Re: Broken dbus GetAll message to wpa supplicant interface properties
@Sebastien: tested on Ubuntu 18.04 $ sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1/Interfaces/1 org.freedesktop.DBus.Properties.GetAll string:fi.w1.wpa_supplicant1.Interface method return time=1607598173.146833 sender=:1.4 -> destination=:1.82 serial=61 reply_serial=2 array [ dict entry( string "Capabilities" variant array [ dict entry( string "Pairwise" [...] It works -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1899262 Title: Broken dbus GetAll message to wpa supplicant interface properties Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Bionic: Fix Committed Bug description: * Impact One of the distro patch is incorrect and create issues when trying to query dbus properties * Test Case $ sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1/Interfaces/1 org.freedesktop.DBus.Properties.GetAll string:fi.w1.wpa_supplicant1.Interface shouldn't error out (the /1 reflect the interface number and could be a different value, check with d-feet if needed) * Regression potential The fixes is in the dbus interface, check that communication with desktop clients (indicator, applet, settings) still works correctly, returning expected informations on the signal, etc - dbus-send is able to read the properties of interface using GetAll. Those information include interface name, status, encryption method, etc. The regression was introduced when someone try to have the Station attribute supported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1899262/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1871268] Re: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected
** Changed in: apt (Ubuntu Bionic) Status: Confirmed => Fix Released ** Changed in: apt (Ubuntu Focal) Status: Triaged => Fix Released ** Changed in: apt (Ubuntu Groovy) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1871268 Title: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected Status in Ubuntu CD Images: Fix Released Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Released Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt package in Debian: Unknown Bug description: [Impact] Installations that really succeeded would then fail because APT could not immediately configure a package. Which is a pointless way to fail at that point, because everything did work out anyway. So what we do is change that to a warning. [Test case] Not available right now. Issues can flare up and then disappear again. [Regression potential] It's imaginable that we missed something somewhere and some path that checked for a set error doesn't check it anymore, and we report success when we hit an error, but it seems unlikely. Behavior of --simulate changes. This used to fail before as well, and will now only produce a warning. We don't believe that is a reason of concern. [Groovy SRU] The groovy SRU is a sync of the 2.1.11 micro release from Debian unstable which also incorporates changes to the documentation: A typo fix, replacing focal with groovy in examples, and minor Dutch manual pages translation updates. We do not have test cases for the documentation changes, and we do not consider there to be a huge regression potential. As long as they build, they should be readable - maybe some words are wrong in the translation, who knows. [Original bug report] Test Case 1. Install Ubuntu Desktop on hardware with an nVidia card and select to install 3rd party drivers 2. Proceed with installation The following error message is displayed in /var/log/syslog /plugininstall.py: Verifying downloads ... /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/gcc_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxcrypt/libcrypt-dev_4.4.10-10ubuntu4_amd64.deb: "Version: '4.4.10-10ubuntu4' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/g++_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/z/zlib/zlib1g_1.2.11.dfsg-2ubuntu1_i386.deb: "Version: '1.2.11.dfsg-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxau/libxau6_1.0.9-0ubuntu1_i386.deb: "Version: '1.0.9-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdmcp/libxdmcp6_1.1.3-0ubuntu1_i386.deb: "Version: '1.1.3-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-6_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxext/libxext6_1.3.4-0ubuntu1_i386.deb: "Version: '1.3.4-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/l/lm-sensors/libsensors5_3.6.0-2ubuntu1_i386.deb: "Version: '3.6.0-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-xcb1_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdamage/libxdamage1_1.1.5-1_i386.deb: "Version: '1.1.5-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxfixes/libxfixes3_5.0.3-1_i386.deb: "Version: '5.0.3-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxxf86vm/libxxf86vm1_1.1.4-1build1_i386.deb: "Version: '1.1.4-1build1' not found." /plugininstall.py: Downloads verified successfully ubiquity: Error in function: install /plugininstall.py: Exception during installation: /plugininstall.py: apt_pkg.Error: E:Could not configure 'libc6:i386'. , E:Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) /plugininstall.py: ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: ubiquity 20.04.9 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 NonfreeKernelModules:
[Touch-packages] [Bug 1903329] Update Released
The verification of the Stable Release Update for librsvg has completed successfully and the package is now being 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 librsvg in Ubuntu. https://bugs.launchpad.net/bugs/1903329 Title: SRU the current 2.48.9 stable update Status in librsvg package in Ubuntu: Fix Released Status in librsvg source package in Focal: Fix Released Bug description: * Impact That's the current GNOME stable update, which fixes a number of issues, including a regression[1] since librsvg 2.40.x which was shipped in Ubuntu 16.04. The NEWS file[2] summarizes the relevant changes between Ubuntu 20.04's current librsvg 2.48.7 (that version was also introduced by an SRU back in July[3]) and the current version 2.48.9. The complete list of changes is available on GNOME GitLab[4]. * Test case The update is part of GNOME stable updates[5]. Smoke testing by opening SVG images with eog or importing them with gimp can be performed to ensure there are no regressions. * Regression potential This is a bugfix-only stable micro-release, however librsvg is a core component with a number of reverse dependencies. A combination of autopkgtests and manual smoke testing to try and detect SVG rendering issues should be performed. * Notes about this report This is my first SRU request (and at the same time my first launchpad bug report). I'm not really familiar with the whole SRU process which is why I first asked about it on Ubuntu's official discourse forum[6]. Canonical's Sebastien Bacher encouraged me to open this ticket. I've copied over some parts of the last librsvg SRU ticket[3]. I hope this is fine. Thanks for considering this SRU. [1]: https://gitlab.gnome.org/GNOME/librsvg/-/issues/642 [2]: https://gitlab.gnome.org/GNOME/librsvg/-/blob/librsvg-2.48/NEWS [3]: https://bugs.launchpad.net/bugs/1884326 [4]: https://gitlab.gnome.org/GNOME/librsvg/-/compare/2.48.7...2.48.9 [5]: https://wiki.ubuntu.com/StableReleaseUpdates/GNOME [6]: https://discourse.ubuntu.com/t/most-straight-forward-way-to-get- librsvg2-microrelease-update-into-focal-updates/19238 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/1903329/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1903329] Re: SRU the current 2.48.9 stable update
This bug was fixed in the package librsvg - 2.48.9-1ubuntu0.20.04.1 --- librsvg (2.48.9-1ubuntu0.20.04.1) focal; urgency=medium * SRU new upstream release to focal (LP: #1903329) -- Olivier Tilloy Mon, 30 Nov 2020 18:08:14 +0100 ** Changed in: librsvg (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to librsvg in Ubuntu. https://bugs.launchpad.net/bugs/1903329 Title: SRU the current 2.48.9 stable update Status in librsvg package in Ubuntu: Fix Released Status in librsvg source package in Focal: Fix Released Bug description: * Impact That's the current GNOME stable update, which fixes a number of issues, including a regression[1] since librsvg 2.40.x which was shipped in Ubuntu 16.04. The NEWS file[2] summarizes the relevant changes between Ubuntu 20.04's current librsvg 2.48.7 (that version was also introduced by an SRU back in July[3]) and the current version 2.48.9. The complete list of changes is available on GNOME GitLab[4]. * Test case The update is part of GNOME stable updates[5]. Smoke testing by opening SVG images with eog or importing them with gimp can be performed to ensure there are no regressions. * Regression potential This is a bugfix-only stable micro-release, however librsvg is a core component with a number of reverse dependencies. A combination of autopkgtests and manual smoke testing to try and detect SVG rendering issues should be performed. * Notes about this report This is my first SRU request (and at the same time my first launchpad bug report). I'm not really familiar with the whole SRU process which is why I first asked about it on Ubuntu's official discourse forum[6]. Canonical's Sebastien Bacher encouraged me to open this ticket. I've copied over some parts of the last librsvg SRU ticket[3]. I hope this is fine. Thanks for considering this SRU. [1]: https://gitlab.gnome.org/GNOME/librsvg/-/issues/642 [2]: https://gitlab.gnome.org/GNOME/librsvg/-/blob/librsvg-2.48/NEWS [3]: https://bugs.launchpad.net/bugs/1884326 [4]: https://gitlab.gnome.org/GNOME/librsvg/-/compare/2.48.7...2.48.9 [5]: https://wiki.ubuntu.com/StableReleaseUpdates/GNOME [6]: https://discourse.ubuntu.com/t/most-straight-forward-way-to-get- librsvg2-microrelease-update-into-focal-updates/19238 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/1903329/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906263] Re: Udev Randomly Doesn't Run Run Script on Remove
I've upgraded to ubuntu 20.4.1. Udev verision now is 245.4-4ununtu3.3. Problem persists -- 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/1906263 Title: Udev Randomly Doesn't Run Run Script on Remove Status in systemd package in Ubuntu: New Bug description: Hello, I'm running ubuntu (Description: Ubuntu 18.04.4 LTS, Release: 18.04) with 5.0.21-sunxi kernel. I've updated udev to latest version (237-3ubuntu10.43 500). I've written the following rule to create (and removing) symlink to modem ports: https://pastebin.com/cUwHrf1f Since many usb modems hase more than one serial i enumerate them with their port number (as just some specific serial can be used to connect) Here link to mu RUN script /opt/trx/gprs-modem-symlink-handler.bash https://pastebin.com/2XTCiV27 What I expect to happen is having many /dev/ttyTRXGPRSMODEM* (enumerated) when I plug-in a modem in the list, and having symlink cleared on removing. every modem listed in rule is using "option" usb serial driver. When i plug in a device I have no issues, everything works fine. But sometimes, on removing, I found that some links are still there (it's not happening everytime). I've enabled debug log with udev and found that sometimes is not calling RUN script: Here the working situation (3 tty remove events and 3 RUN events): https://pastebin.com/EKX5zMh7 And here is the buggy situation (3 tty remove events, but only 2 RUN events) with the same device as the example above: https://pastebin.com/dB7ujQ79 Since it's happening randomly I can't figure out whats causing the problem. I guess it's not the rule because on an old debian 7 release it's working fine, and on the release described above I get others symlinks removed even in the buggy situation (as in the example: two are removed, one not). It seems like sometimes udev ignores totally the run event. Last thing to report: I'm not opening these links! So are not locked or protected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1906263/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 378783] Re: xdg-open *.desktop opens text editor
** Changed in: glib2.0 (Ubuntu) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/378783 Title: xdg-open *.desktop opens text editor Status in GLib: Fix Released Status in gvfs: New Status in glib2.0 package in Ubuntu: Fix Committed Bug description: Binary package hint: xdg-utils In order to reproduce it execute "xdg-open *.desktop" (choose any .desktop file, e.g. one from /usr/share/applications). Actually your favorite text editor will open the file. Expected result: It'll be executed. Because of this bug, desktop entries with the new "#!/usr/bin/env xdg- open" shebang feature were opened in the text editor when executed from command line. To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/378783/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
