[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Hello @Eric.
> What make Bionic more susceptible to this particular problem ? Bionic
kernel version in use ? else ?
I believe klibc/ipconfig itself is susceptible to the problem in Bionic
and Focal and elsewhere. However, Focal (which uses klibc 2.0.7) uses
dhclient for networking initialization instead of ipconfig, therefore I
am not really concerned about fixing the ipconfig issue in Focal since
it is not causing any noticeable problems.
I have checked the HEAD of the klibc project and it appears that
ipconfig is still susceptible to the timeout problem. Sure I can propose
the patch upstream if you like - however, even if they accept it I
believe we will still need to apply it separately for Bionic because I
do not expect that Bionic will receive any major updates for klibc, so
it will not get any upstream fixes. It will remain on 2.0.4 as far as I
know. It is currently version 2.0.4-9ubuntu2 in Bionic which means we
are carrying (2?) Ubuntu-specific patches on top of 2.0.4. I believe
this fix can be added as well to produce 2.0.4-9ubuntu3.
I will attempt to upstream this fix to klibc, but I believe the change
to Bionic should happen in parallel/independently since the upstream
patch will not make its way back to Bionic (which is stuck at 2.0.4, as
mentioned above).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1339518] Re: sudo config file specifies group "admin" that doesn't exist in system
Subscribing Marc as he seems to be largely maintaining this and made the original changes and has been keeping the delta. Hopefully he can provide some insight. Seems this is a delta to Debian that is being kept intentionally for a long time, it's frequently in the changelog even in the most recent Debian merge. I'd have thought if we kept this in here by default we probably should have kept a default 'admin' group with no members but it's a bit late for that at this point. - debian/sudoers: + also grant admin group sudo access Also seems this change was originally made in 2014: sudo (1.8.9p5-1ubuntu3) vivid; urgency=medium * debian/patches/also_check_sudo_group.diff: also check the sudo group in plugins/sudoers/sudoers.c to create the admin flag file. Leave the admin group check for backwards compatibility. (LP: #1387347) -- Marc Deslauriers Wed, 29 Oct 2014 15:55:34 -0400 sudo (1.8.9p5-1ubuntu2) utopic; urgency=medium * debian/sudo_root.8: mention sudo group instead of deprecated group admin (LP: #1130643) -- Andrey Bondarenko Sat, 23 Aug 2014 01:18:05 +0600 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1339518 Title: sudo config file specifies group "admin" that doesn't exist in system Status in sudo package in Ubuntu: Confirmed Bug description: In the configuration file for sudo ( /etc/sudoers ) you find this section: # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL The sudo group is in /etc/group, but not admin group. This is a cosmetic bug, but if we specify a group that are allowed to use sudo command, then the group should exist in the system too. Installed version: Ubuntu 14.04 LTS all upgrades up to 9 july 2014 installed, 64 bit desktop ISO used for installation. Sudo package installed: ii sudo1.8.9p5-1ubuntu1 amd64 Provide limited super user privileges to specific users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1339518/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1339518] Re: sudo config file specifies group "admin" that doesn't exist in system
Just noticed this today, it's still the same on Ubuntu 20.04. The default sudoers file ships the admin group having sudo privileges but the group doesn't exist by default. While it doesn't have out of the box security implications, I think this is a security concern as someone could potentially add an 'admin' user and not expect them to get sudo access with the default matching group name created for them. For example downstream products like web hosting or control panel style tools that creates users with a user-provided name. Since neither the user or group 'admin' exists by default they could be fooled into creating escalatable privileges. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1339518 Title: sudo config file specifies group "admin" that doesn't exist in system Status in sudo package in Ubuntu: Confirmed Bug description: In the configuration file for sudo ( /etc/sudoers ) you find this section: # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL The sudo group is in /etc/group, but not admin group. This is a cosmetic bug, but if we specify a group that are allowed to use sudo command, then the group should exist in the system too. Installed version: Ubuntu 14.04 LTS all upgrades up to 9 july 2014 installed, 64 bit desktop ISO used for installation. Sudo package installed: ii sudo1.8.9p5-1ubuntu1 amd64 Provide limited super user privileges to specific users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1339518/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1339518] Re: sudo config file specifies group "admin" that doesn't exist in system
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: sudo (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1339518 Title: sudo config file specifies group "admin" that doesn't exist in system Status in sudo package in Ubuntu: Confirmed Bug description: In the configuration file for sudo ( /etc/sudoers ) you find this section: # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL The sudo group is in /etc/group, but not admin group. This is a cosmetic bug, but if we specify a group that are allowed to use sudo command, then the group should exist in the system too. Installed version: Ubuntu 14.04 LTS all upgrades up to 9 july 2014 installed, 64 bit desktop ISO used for installation. Sudo package installed: ii sudo1.8.9p5-1ubuntu1 amd64 Provide limited super user privileges to specific users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1339518/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
FYI triggered again for me due to unattended upgrades. The time in the journal when things go down matches the unpack/configuee/install phase of - accountsservice:amd64 0.6.55-0ubuntu12~20.04.5 - libaccountsservice0:amd64 0.6.55-0ubuntu12~20.04.5 - dbus:amd64 1.12.16-2ubuntu2.1 I - again - had the usual suspect entries: systemd[1]: Starting Daily apt upgrade and clean activities... dbus-daemon[2266]: [system] Reloaded configuration dbus-daemon[2266]: Unknown group "power" in message bus configuration file systemd[1]: Reloading. systemd[1]: NetworkManager.service: Unexpected error response from GetNameOwner(): Connection terminated I didn't see anything in the log we didn't have before, but for completeness I'm attaching journal of the issue and a few hours before it ** Attachment added: "journal entries around the issues happening on unattended-upgrades" https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/+attachment/5541619/+files/fail-18Nov-6-24-07.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to accountsservice in Ubuntu. https://bugs.launchpad.net/bugs/1871538 Title: dbus timeout-ed during an upgrade, taking services down including gdm Status in D-Bus: Unknown Status in systemd: New Status in accountsservice package in Ubuntu: Invalid Status in dbus package in Ubuntu: Incomplete Status in gnome-shell package in Ubuntu: Invalid Status in accountsservice source package in Focal: Invalid Status in dbus source package in Focal: Incomplete Status in gnome-shell source package in Focal: Invalid Status in accountsservice source package in Groovy: Invalid Status in dbus source package in Groovy: Incomplete Status in gnome-shell source package in Groovy: Invalid Status in accountsservice source package in Hirsute: Invalid Status in dbus source package in Hirsute: Incomplete Status in gnome-shell source package in Hirsute: Invalid Status in accountsservice source package in Impish: Invalid Status in dbus source package in Impish: Incomplete Status in gnome-shell source package in Impish: Invalid Bug description: This morning I found my computer on the login screen. But not the one of the screen log, no a new one - so something must have crashed. Logging in again confirmed that all apps were gone and the gnome shell was brought down what seems like triggered by a background update o accountsservice. As always things are not perfectly clear :-/ The following goes *back* in time through my logs one by one. Multiple apps crashed at 06:09, but we will find later that this is a follow on issue of the underlying gnome/X/... recycling. -rw-r- 1 paelzer whoopsie 52962868 Apr 8 06:09 _usr_bin_konversation.1000.crash -rw-r- 1 paelzer whoopsie 986433 Apr 8 06:09 _usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash rdkit was failing fast and giving up (that will be a different bug, it just seems broken on my system): Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling Policy Service. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called chroot. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped privileges. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited resources. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: Resource temporarily unavailable Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time threads. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads. Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process exited, code=exited, status=1/FAILURE Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with result 'exit-code'. Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=> Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request repeated too quickly. Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with result 'exit-code'. Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit Scheduling Policy Service. Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53 But that already was only triggered by a gnome restart that kicked of earlier: Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland. Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on Wayland. Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session is initialized. Apr 08 06:09:27 Keschdeichel
[Touch-packages] [Bug 1951279] Re: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds
same issue my environment is inside docker -- docker run -it --platform linux/arm64 ubuntu:20.04 /bin/bash Linux 888c7f7b294c 5.10.47-linuxkit #1 SMP PREEMPT Sat Jul 3 21:50:16 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux curl 7.68.0 (aarch64-unknown-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3 Release-Date: 2020-01-08 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSocket -- maybe that will help finding the root cause. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1951279 Title: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds Status in openssl package in Ubuntu: Incomplete Bug description: Description --- It seems that current Ubuntu 20.04 (Focal) distribution for Arm64/Aarch64 raise a segmentation fault when certain validates some certificates. This issue affects only to Arm64/Aarch64 all the tools statically or dynamically linked with this version of the library are affected (Libcurl4, Curl, Wget, OpenJDK, Curl-PHP, etc). Environment and platform Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:29:20 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux Steps to reproduce -- 1. Run: curl -v https://graph.facebook.com/v12.0/act_111/ or wget https://graph.facebook.com/v12.0/act_111/ Result received --- Segmentation fault (core dumped) Notes - This bug was found by the Curl users: See: https://github.com/curl/curl/issues/8024 I believe that this bug is related to https://ubuntu.com/security/CVE-2020-1967 that maybe used as a vector point for code injection. Actually there isn't any replacement for OpenSSL 1.1.1f for Focal (Arm64), so it makes difficult to use Ubuntu 20.04 in a production environment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1951279/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1909373] Re: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10
[Expired for ufw (Ubuntu) because there has been no activity for 60 days.] ** Changed in: ufw (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1909373 Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10 Status in ufw package in Ubuntu: Expired Bug description: dont upgrade ProblemType: Package DistroRelease: Ubuntu 18.04 Package: ufw 0.36-0ubuntu0.18.04.1 Uname: Linux 3.18.14-17162658-QB35446819 aarch64 ApportVersion: 2.20.9-0ubuntu7.21 Architecture: arm64 Date: Sat Dec 26 20:56:19 2020 Df: Filesystem 1K-blocks Used Available Use% Mounted on rootfs 24604780 19261268 5251352 79% / tmpfs1434188 1020 1433168 1% /dev Dmesg: ErrorMessage: installed ufw package post-installation script subprocess returned error exit status 10 PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, unpackaged PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, unpackaged RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: ufw Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1909373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1934931] Re: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently
[Expired for ufw (Ubuntu) because there has been no activity for 60 days.] ** Changed in: ufw (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1934931 Title: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently Status in Gufw: Invalid Status in ufw package in Ubuntu: Expired Bug description: Thanks for Gufw! inxi -S output: Xubuntu standard LTS installation - Kernel: 5.4.0-77-generic x86_64 bits: 64 Desktop: Xfce 4.14.2 Distro: Ubuntu 20.04.2 LTS (Focal Fossa). GUFW 20.04.1, MS Teams 1.4.00.13653 (64-Bit) (all up to date at the time of this report). ** Problem: 250 Mbit LAN connection slowing down *intermittently*, but reproducible, to a crawl of 300 kbit or less if Gufw is activated parallel to MS teams. * Gufw is used with only basic settings provided after installation (in:denied/out:allowed and nothing else set, no further rules). * There has not to be any active call in teams, just running it seems to cause the problem after a while (<5 minutes). * After congestion for some time (minutes), the system may recover to full speed again, only to succumb again after a few minutes. * Other parallel running programs' connections are slowed down as well in accordance, e.g. parallel samba file sharing download is affected as well. * Stopping teams restores the connection speed after a short while (~1 minute). * Parallel connections to the LAN(router) are not inhibited, it is just the one computer. Teams seems to switch ports after restarting (UDP6/~34nnn-4). I set up a range to be allowed within ports used by teams (e.g. 3:5, allow in/outbound) to no avail, connections dropped still to low speed. Thanks and regards, Christoph To manage notifications about this bug go to: https://bugs.launchpad.net/gui-ufw/+bug/1934931/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1888598] Re: Pulseaudio breaks HDMI audio on sleep/wake
I'm gonna try Hui Wang's patch because I'm having the same issue on a fresh install. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1888598 Title: Pulseaudio breaks HDMI audio on sleep/wake Status in pulseaudio package in Ubuntu: Confirmed Bug description: on a fresh Ubuntu 20.04 x64 install, I've noticed some troubling bugs with pulseaudio after putting my system to sleep and then waking it up. these bugs aren't present on a fresh boot, only after resuming from sleep: - it forgets which sound output device it's set to, and always reverse to the motherboard's S/PDIF output. - I have two devices connected to my video card, one is a displayport monitor, and one is a home theater receiver via HDMI. it confuses the two, and randomly switches which device it thinks is capable of surround sound. - it sometimes refuses to switch to the correct audio device, and just resets any choice back to the internal S/PDIF, until the system is rebooted. as you can imagine, this a pretty frustrating state of affairs. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.4 ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44 Uname: Linux 5.4.0-40-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: tessa 3387 F pulseaudio /dev/snd/pcmC1D7p: tessa 3387 F...m pulseaudio /dev/snd/controlC2: tessa 3387 F pulseaudio /dev/snd/controlC0: tessa 3387 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jul 22 18:38:42 2020 InstallationDate: Installed on 2020-07-15 (7 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/18/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3503 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: GRYPHON Z97 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3503:bd04/18/2018:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnGRYPHONZ97:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: ASUS MB dmi.product.name: All Series dmi.product.sku: All dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1888598/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951161] Re: Please merge shadow 1:4.8.1-2 (main) from Debian unstable
I think the changelog entry should still list the private home dirs change for login.defs under Remaining changes -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1951161 Title: Please merge shadow 1:4.8.1-2 (main) from Debian unstable Status in shadow package in Ubuntu: Confirmed Bug description: This merge is necessary because there are changes present in Ubuntu that are not present in Debian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts
** Merge proposal linked:
https://code.launchpad.net/~sergiodj/ubuntu/+source/postfix/+git/postfix/+merge/412054
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1718227
Title:
replacement of ifupdown with netplan needs integration for
/etc/network/if{up,down}.d scripts
Status in aiccu package in Ubuntu:
Invalid
Status in aoetools package in Ubuntu:
New
Status in avahi package in Ubuntu:
New
Status in bind9 package in Ubuntu:
Invalid
Status in chrony package in Ubuntu:
Fix Released
Status in clamav package in Ubuntu:
Triaged
Status in controlaula package in Ubuntu:
Invalid
Status in ethtool package in Ubuntu:
Triaged
Status in guidedog package in Ubuntu:
New
Status in htpdate package in Ubuntu:
New
Status in ifenslave package in Ubuntu:
Won't Fix
Status in ifmetric package in Ubuntu:
Won't Fix
Status in ifupdown-multi package in Ubuntu:
New
Status in ifupdown-scripts-zg2 package in Ubuntu:
Invalid
Status in isatapd package in Ubuntu:
New
Status in lprng package in Ubuntu:
New
Status in miredo package in Ubuntu:
New
Status in mythtv package in Ubuntu:
New
Status in nplan package in Ubuntu:
New
Status in nss-pam-ldapd package in Ubuntu:
Triaged
Status in ntp package in Ubuntu:
Won't Fix
Status in openntpd package in Ubuntu:
New
Status in openresolv package in Ubuntu:
Won't Fix
Status in openssh package in Ubuntu:
Fix Released
Status in openvpn package in Ubuntu:
Confirmed
Status in openvswitch package in Ubuntu:
Triaged
Status in postfix package in Ubuntu:
Triaged
Status in quicktun package in Ubuntu:
New
Status in resolvconf package in Ubuntu:
New
Status in sendmail package in Ubuntu:
New
Status in shorewall-init package in Ubuntu:
New
Status in sidedoor package in Ubuntu:
New
Status in slrn package in Ubuntu:
New
Status in tinc package in Ubuntu:
New
Status in ubuntu-fan package in Ubuntu:
Fix Released
Status in ucarp package in Ubuntu:
New
Status in uml-utilities package in Ubuntu:
New
Status in uruk package in Ubuntu:
New
Status in vlan package in Ubuntu:
Won't Fix
Status in vzctl package in Ubuntu:
Triaged
Status in wide-dhcpv6 package in Ubuntu:
New
Status in wpa package in Ubuntu:
New
Bug description:
when network is configured with ifupdown, scripts in
/etc/network/ifup.d/ were called on network being brought up and
/etc/network/ifdown.d were called on network being brought down.
Any packages that shipped these hooks need to be verified to have the
same functionality under a netplan configured system.
# binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
# for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u
aiccu
aoetools
avahi
bind9
chrony
clamav
controlaula
epoptes
ethtool
guidedog
htpdate
ifenslave
ifmetric
ifupdown-extra
ifupdown-multi
ifupdown-scripts-zg2
isatapd
lprng
miredo
mythtv-backend
nss-pam-ldapd
ntp
openntpd
openresolv
openssh
openvpn
postfix
quicktun
resolvconf
sendmail
shorewall-init
sidedoor
slrn
tinc
ubuntu-fan
ucarp
uml-utilities
uruk
vlan
vzctl
wide-dhcpv6
wpa
Related bugs:
* bug 1718227: replacement of ifupdown with netplan needs integration for
/etc/network/if{up,down}.d scripts
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for
dhclient needs integration
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: netplan (not installed)
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Sep 19 10:53:08 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-07-23 (789 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: plan
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951279] Re: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds
Hmm, something else to keep in mind: many aarch64 systems run on SD cards or USB memory sticks and those are notorious garbage. Is this a reasonable hard drive or is this cheap flash storage? Are there messages in dmesg that might indicate filesystem or block storage errors? If this isn't a real hard drive then your debugging time is probably better spent replacing the storage as a first effort. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1951279 Title: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds Status in openssl package in Ubuntu: Incomplete Bug description: Description --- It seems that current Ubuntu 20.04 (Focal) distribution for Arm64/Aarch64 raise a segmentation fault when certain validates some certificates. This issue affects only to Arm64/Aarch64 all the tools statically or dynamically linked with this version of the library are affected (Libcurl4, Curl, Wget, OpenJDK, Curl-PHP, etc). Environment and platform Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:29:20 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux Steps to reproduce -- 1. Run: curl -v https://graph.facebook.com/v12.0/act_111/ or wget https://graph.facebook.com/v12.0/act_111/ Result received --- Segmentation fault (core dumped) Notes - This bug was found by the Curl users: See: https://github.com/curl/curl/issues/8024 I believe that this bug is related to https://ubuntu.com/security/CVE-2020-1967 that maybe used as a vector point for code injection. Actually there isn't any replacement for OpenSSL 1.1.1f for Focal (Arm64), so it makes difficult to use Ubuntu 20.04 in a production environment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1951279/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951279] Re: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds
Can you provide more information on your environment and how to
reproduce this? I wasn't able to reproduce this on my rpi3b+ running
focal, with either libssl1.1 1.1.1f-1ubuntu2.8 or 1.1.1f-1ubuntu2.9:
First, 1.1.1f-1ubuntu2.8 installed:
$ curl -v https://graph.facebook.com/v12.0/act_111/
* Trying 157.240.3.20:443...
* TCP_NODELAY set
* Connected to graph.facebook.com (157.240.3.20) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Menlo Park; O=Facebook, Inc.;
CN=*.facebook.com
* start date: Nov 4 00:00:00 2021 GMT
* expire date: Feb 2 23:59:59 2022 GMT
* subjectAltName: host "graph.facebook.com" matched cert's "*.facebook.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High
Assurance Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xc4c9dee0)
> GET /v12.0/act_111/ HTTP/2
> Host: graph.facebook.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 403
< vary: Origin
< x-ad-account-usage: {"acc_id_util_pct":0}
< x-fb-rlafr: 0
< content-type: application/json; charset=UTF-8
< www-authenticate: OAuth "Facebook Platform" "insufficient_scope" "(#200)
Provide valid app ID"
< access-control-allow-origin: *
< facebook-api-version: v12.0
< strict-transport-security: max-age=15552000; preload
< pragma: no-cache
< cache-control: no-store
< expires: Sat, 01 Jan 2000 00:00:00 GMT
< x-fb-request-id: AYFxZKGuw4Uidu_b6_RsyRn
< x-fb-trace-id: C1HBc2Oi1S3
< x-fb-rev: 1004746171
< x-fb-debug:
yza+SwSrqD6mY1INQSyb5rcHmU89PziSoE3txYwg1BjWybYcgB36mUMVxq9bsRAJXZGkc34nNcSps5APpyG8QA==
< content-length: 125
< date: Wed, 17 Nov 2021 20:48:02 GMT
< alt-svc: h3=":443"; ma=3600, h3-29=":443"; ma=3600
<
* Connection #0 to host graph.facebook.com left intact
{"error":{"message":"(#200) Provide valid app
ID","type":"OAuthException","code":200,"fbtrace_id":"AYFxZKGuw4Uidu_b6_RsyRn"}}ubuntu@ubuntu:~
$ wget https://graph.facebook.com/v12.0/act_111/
--2021-11-17 20:48:16-- https://graph.facebook.com/v12.0/act_111/
Resolving graph.facebook.com (graph.facebook.com)... 157.240.3.20,
2a03:2880:f001:6:face:b00c:0:2
Connecting to graph.facebook.com (graph.facebook.com)|157.240.3.20|:443...
connected.
HTTP request sent, awaiting response... 403 Forbidden
2021-11-17 20:48:16 ERROR 403: Forbidden.
ubuntu@ubuntu:~ 8 $
Next, 1.1.1f-1ubuntu2.9 installed:
ubuntu@ubuntu:~ 10s $ curl -v https://graph.facebook.com/v12.0/act_111/
* Trying 157.240.3.20:443...
* TCP_NODELAY set
* Connected to graph.facebook.com (157.240.3.20) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Menlo Park; O=Facebook, Inc.;
CN=*.facebook.com
* start date: Nov 4 00:00:00 2021 GMT
* expire date: Feb 2 23:59:59 2022 GMT
* subjectAltName: host "graph.facebook.com" matched cert's "*.facebook.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High
Assurance Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xf7766ee0)
> GET /v12.0/act_111/ HTTP/2
> Host: graph.facebook.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 403
<
[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
> @slyon you might want to see if commit 918e6f1c0151429f5095355f4f3f74f16e79724a fixes this (and there are a couple follow on commits to this) -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951161] Re: Please merge shadow 1:4.8.1-2 (main) from Debian unstable
** Patch added: "Diff from Debian" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+attachment/5541538/+files/debian_ubuntu.debdiff ** Changed in: shadow (Ubuntu) Assignee: William Wilson (jawn-smith) => (unassigned) ** Changed in: shadow (Ubuntu) Status: In Progress => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1951161 Title: Please merge shadow 1:4.8.1-2 (main) from Debian unstable Status in shadow package in Ubuntu: Confirmed Bug description: This merge is necessary because there are changes present in Ubuntu that are not present in Debian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951161] Re: Please merge shadow 1:4.8.1-2 (main) from Debian unstable
** Patch added: "Diff from Debian" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+attachment/5541536/+files/debian_ubuntu.debdiff ** Changed in: shadow (Ubuntu) Assignee: (unassigned) => William Wilson (jawn-smith) ** Changed in: shadow (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1951161 Title: Please merge shadow 1:4.8.1-2 (main) from Debian unstable Status in shadow package in Ubuntu: Confirmed Bug description: This merge is necessary because there are changes present in Ubuntu that are not present in Debian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951161] Re: Please merge shadow 1:4.8.1-2 (main) from Debian unstable
** Patch added: "Diff from 1:4.8.1-1ubuntu9" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+attachment/5541537/+files/ubuntu_ubuntu.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1951161 Title: Please merge shadow 1:4.8.1-2 (main) from Debian unstable Status in shadow package in Ubuntu: Confirmed Bug description: This merge is necessary because there are changes present in Ubuntu that are not present in Debian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951161] Re: Please merge shadow 1:4.8.1-2 (main) from Debian unstable
** Patch added: "Diff from 1:4.8.1-1ubuntu9" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+attachment/5541535/+files/ubuntu_ubuntu.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1951161 Title: Please merge shadow 1:4.8.1-2 (main) from Debian unstable Status in shadow package in Ubuntu: Confirmed Bug description: This merge is necessary because there are changes present in Ubuntu that are not present in Debian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1939986] Re: Missing firmware files, in Ubuntu 20.04 LTS, for initramfs, when it loads i915
** Also affects: initramfs-tools (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux-firmware (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-firmware (Ubuntu Focal) Assignee: (unassigned) => Juerg Haefliger (juergh) ** Changed in: linux-firmware (Ubuntu Focal) Status: New => Confirmed ** Changed in: linux-firmware (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux-firmware (Ubuntu) Assignee: Juerg Haefliger (juergh) => (unassigned) ** Changed in: initramfs-tools (Ubuntu Focal) Status: New => Invalid ** No longer affects: initramfs-tools (Ubuntu Focal) ** No longer affects: initramfs-tools (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1939986 Title: Missing firmware files, in Ubuntu 20.04 LTS, for initramfs, when it loads i915 Status in linux-firmware package in Ubuntu: Invalid Status in linux-firmware source package in Focal: Confirmed Bug description: Dear all, I can see that the linux-firmware is missing firmware files, in Ubuntu 20.04.1 LTS, for initramfs, when it loads i915. Package: linux-firmware 1.187.15 It contains the following files, for the module i915: i915/tgl_dmc_ver2_04.bin 2019-09-13 installed i915/tgl_dmc_ver2_06.bin 2020-03-04 installed i915/tgl_dmc_ver2_08.bin 2020-08-13 installed i915/tgl_guc_35.2.0.bin 2019-11-06 installed i915/tgl_huc_7.0.12.bin 2020-03-04 installed i915/tgl_huc_7.0.3.bin2019-11-06 installed Package: linux-firmware MUST at least contain the following files, for the module i915: i915/tgl_huc_7.5.0.bin2020-08-13 i915: Add HuC firwmare v7.5.0 for TGL as the module asks for it, during 'update-initramfs', to avoid: W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module i915 But it COULD also contain : i915/tgl_dmc_ver2_12.bin 2021-07-28 i915: Add v2.12 DMC for TGL i915/tgl_guc_49.0.1.bin 2020-11-24 i915: Add GuC firmware v49.0.1 for all platforms i915/tgl_guc_62.0.0.bin 2021-06-29 firmware/i915/guc: Add GuC v62.0.0 for all platforms i915/tgl_huc_7.9.3.bin2021-06-29 firmware/i915/guc: Add HuC v7.9.3 for TGL & DG1 Source: $ modprobe --show-depends --ignore-install i915 ... insmod /lib/modules/5.10.0-1038-oem/kernel/drivers/gpu/drm/i915/i915.ko $ modinfo -F firmware /lib/modules/5.10.0-1038-oem/kernel/drivers/gpu/drm/i915/i915.ko ... i915/tgl_dmc_ver2_08.bin i915/tgl_guc_35.2.0.bin i915/tgl_huc_7.5.0.bin Actual result: $ sudo update-initramfs -u W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module i915 Expected result: No Warning. and the firmware "i915/tgl_huc_7.5.0.bin" loaded for module i915 Info : INTEL Repository of firmware: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-firmware 1.187.15 ProcVersionSignature: Ubuntu 5.10.0-1038.40-oem 5.10.46 Uname: Linux 5.10.0-1038-oem x86_64 ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chris 1699 F pulseaudio /dev/snd/pcmC0D0p: chris 1699 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: XFCE Date: Sun Aug 15 14:46:47 2021 Dependencies: DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-focal-amd64-20200502-85+fossa-bulbasaur+X54 InstallationDate: Installed on 2021-08-12 (2 days ago) InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20200502-05:58 MachineType: Dell Inc. XPS 13 9310 PackageArchitecture: all ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1038-oem root=UUID=3dae0247-a884-48d8-83b7-fea7c803faa3 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-5.10.0-1038-oem N/A linux-backports-modules-5.10.0-1038-oem N/A linux-firmware 1.187.15 SourcePackage: linux-firmware UpgradeStatus: No upgrade log present (probably fresh install) WifiSyslog: dmi.bios.date: 07/16/2021 dmi.bios.release: 3.0 dmi.bios.vendor: Dell Inc. dmi.bios.version: 3.0.4 dmi.board.name: 08607K dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr3.0.4:bd07/16/2021:br3.0:svnDellInc.:pnXPS139310:pvr:rvnDellInc.:rn08607K:rvrA00:cvnDellInc.:ct10:cvr:
[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
I spend a bit of quality time with this bug today and it seems there is (also?)
a kernel dimension to it. I ran the following:
"""
$ git status
On branch tests-use-core18-from-gce
Your branch is up to date with 'sergiocazzolato/tests-use-core18-from-gce'.
$ git diff
diff --git a/overlord/devicestate/devicestate.go
b/overlord/devicestate/devicestate.go
index d40b32bcbd..77ec3fc0a8 100644
--- a/overlord/devicestate/devicestate.go
+++ b/overlord/devicestate/devicestate.go
@@ -117,6 +117,8 @@ func canAutoRefresh(st *state.State) (bool, error) {
if !seeded {
return false, nil
}
+ // HACK
+ return false, nil
// Try to ensure we have an accurate time before doing any
// refreshy stuff. Note that this call will not block.
diff --git a/spread.yaml b/spread.yaml
index 0aef5dea7c..68cbdc09b7 100644
--- a/spread.yaml
+++ b/spread.yaml
@@ -37,7 +37,7 @@ environment:
MANAGED_DEVICE: "false"
# a global setting for LXD channel to use in the tests
LXD_SNAP_CHANNEL: "latest/edge"
-UBUNTU_IMAGE_SNAP_CHANNEL: "latest/candidate"
+UBUNTU_IMAGE_SNAP_CHANNEL: "beta/1.11"
CORE_CHANNEL: '$(HOST: echo "${SPREAD_CORE_CHANNEL:-edge}")'
BASE_CHANNEL: '$(HOST: echo "${SPREAD_BASE_CHANNEL:-edge}")'
KERNEL_CHANNEL: '$(HOST: echo "${SPREAD_KERNEL_CHANNEL:-edge}")'
diff --git a/tests/lib/prepare.sh b/tests/lib/prepare.sh
index e6b984c4d0..215d0611be 100755
--- a/tests/lib/prepare.sh
+++ b/tests/lib/prepare.sh
@@ -973,8 +973,8 @@ EOF
fi
if os.query is-core18; then
-curl -s -o core18.snap
https://storage.googleapis.com/snapd-spread-tests/snaps/core18_20211102_amd64.snap
-EXTRA_FUNDAMENTAL="$EXTRA_FUNDAMENTAL --snap $PWD/core18.snap"
+curl --insecure -o pc-kernel.snap
https://people.canonical.com/~mvo/tmp/pYVQrBcKmBa0mZ4CCN7ExT6jH8rY1hza_831.snap
+EXTRA_FUNDAMENTAL="$EXTRA_FUNDAMENTAL --snap $PWD/pc-kernel.snap"
fi
/snap/bin/ubuntu-image snap \
"""
which essentially moves the image to a 2 month older 4.14 kernel. With that I
could not reproduce the error for three subsequent runs of 2 repeats.
However when I disabled this code and use the current "18/edge" pc-
kernel (or stable, it's the same revision) then I can trigger the bug
right away.
--
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/1949089
Title:
systemd randomly fails to activate mount units in Ubuntu Core 18
Status in systemd package in Ubuntu:
New
Status in systemd source package in Bionic:
New
Bug description:
Since a month or so, we've been seeing random failures in our snapd
spread tests where systemd could not start the mount unit associated
with a snap because of a failed dependency.
The issue is described in the comments to PR
https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
here.
When starting a snap, snapd creates a mount unit to mount the snap's
squashfs (the template is
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
The snapd asks systemd to reload the configuration, and starts the
mount unit.
The failure we've observed is that sometimes systemd decides to stop
our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
flip-flop" in the attached log), and then tries to reactivate it
again, and at that point it fails.
When I asked for help, Lukas pointed out that the latest update
contains a patch that is related to reload handling and mount units:
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
(the patch itself is better visible at
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
When looking at the systemd git log, though, I noticed another patch
that was applied shortly after this one, which also seems related but
was not backported:
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0
Since the stopping of our mount unit happens immediately after a
systemd reload, it actually seems very likely that the inclusion of
f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
causes our woes (though, indeed, the issue is not reliably
reproducible, so we cannot be sure).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1946213] Re: strongswan: Fail to build against OpenSSL 3.0
** Merge proposal linked: https://code.launchpad.net/~paride/ubuntu/+source/strongswan/+git/strongswan/+merge/412022 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1946213 Title: strongswan: Fail to build against OpenSSL 3.0 Status in OpenSSL: Fix Released Status in strongSwan: New Status in openssl package in Ubuntu: Invalid Status in strongswan package in Ubuntu: In Progress Bug description: Hello, As part of a rebuild against OpenSSL3, this package failed to build on one or several architectures. You can find the details of the rebuild at https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html or for the amd64 failed build, directly at https://launchpad.net/~schopin/+archive/ubuntu/openssl-3.0.0/+build/22099394/+files/buildlog_ubuntu- impish-amd64.strongswan_5.9.1-1ubuntu3.0~ssl3ppa1.1_BUILDING.txt.gz We're planning to transition to OpenSSL 3.0 for the 22.04 release, and consider this issue as blocking for this transition. You can find general migration informations at https://www.openssl.org/docs/manmaster/man7/migration_guide.html For your tests, you can build against libssl-dev as found in the PPA schopin/openssl-3.0.0 The issue looks fixed upstream on master: https://github.com/strongswan/strongswan/commit/72e5b3b7022ad14b245565a5aadcd097106af168 To manage notifications about this bug go to: https://bugs.launchpad.net/openssl/+bug/1946213/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951279] Re: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds
I observed that many users are affected by this bug. (See: https://github.com/curl/curl/issues/8024) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1951279 Title: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds Status in openssl package in Ubuntu: New Bug description: Description --- It seems that current Ubuntu 20.04 (Focal) distribution for Arm64/Aarch64 raise a segmentation fault when certain validates some certificates. This issue affects only to Arm64/Aarch64 all the tools statically or dynamically linked with this version of the library are affected (Libcurl4, Curl, Wget, OpenJDK, Curl-PHP, etc). Environment and platform Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:29:20 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux Steps to reproduce -- 1. Run: curl -v https://graph.facebook.com/v12.0/act_111/ or wget https://graph.facebook.com/v12.0/act_111/ Result received --- Segmentation fault (core dumped) Notes - This bug was found by the Curl users: See: https://github.com/curl/curl/issues/8024 I believe that this bug is related to https://ubuntu.com/security/CVE-2020-1967 that maybe used as a vector point for code injection. Actually there isn't any replacement for OpenSSL 1.1.1f for Focal (Arm64), so it makes difficult to use Ubuntu 20.04 in a production environment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1951279/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951279] [NEW] OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds
Public bug reported: Description --- It seems that current Ubuntu 20.04 (Focal) distribution for Arm64/Aarch64 raise a segmentation fault when certain validates some certificates. This issue affects only to Arm64/Aarch64 all the tools statically or dynamically linked with this version of the library are affected (Libcurl4, Curl, Wget, OpenJDK, Curl-PHP, etc). Environment and platform Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:29:20 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux Steps to reproduce -- 1. Run: curl -v https://graph.facebook.com/v12.0/act_111/ or wget https://graph.facebook.com/v12.0/act_111/ Result received --- Segmentation fault (core dumped) Notes - This bug was found by the Curl users: See: https://github.com/curl/curl/issues/8024 I believe that this bug is related to https://ubuntu.com/security/CVE-2020-1967 that maybe used as a vector point for code injection. Actually there isn't any replacement for OpenSSL 1.1.1f for Focal (Arm64), so it makes difficult to use Ubuntu 20.04 in a production environment. ** Affects: openssl (Ubuntu) Importance: Undecided Status: New ** Bug watch added: github.com/curl/curl/issues #8024 https://github.com/curl/curl/issues/8024 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1951279 Title: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds Status in openssl package in Ubuntu: New Bug description: Description --- It seems that current Ubuntu 20.04 (Focal) distribution for Arm64/Aarch64 raise a segmentation fault when certain validates some certificates. This issue affects only to Arm64/Aarch64 all the tools statically or dynamically linked with this version of the library are affected (Libcurl4, Curl, Wget, OpenJDK, Curl-PHP, etc). Environment and platform Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:29:20 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux Steps to reproduce -- 1. Run: curl -v https://graph.facebook.com/v12.0/act_111/ or wget https://graph.facebook.com/v12.0/act_111/ Result received --- Segmentation fault (core dumped) Notes - This bug was found by the Curl users: See: https://github.com/curl/curl/issues/8024 I believe that this bug is related to https://ubuntu.com/security/CVE-2020-1967 that maybe used as a vector point for code injection. Actually there isn't any replacement for OpenSSL 1.1.1f for Focal (Arm64), so it makes difficult to use Ubuntu 20.04 in a production environment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1951279/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951161] Re: Please merge shadow 1:4.8.1-2 (main) from Debian unstable
** Tags added: needs-debian-merge -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1951161 Title: Please merge shadow 1:4.8.1-2 (main) from Debian unstable Status in shadow package in Ubuntu: New Bug description: This merge is necessary because there are changes present in Ubuntu that are not present in Debian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1951161/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951228] Re: autoload/netrw.vim contains a typo on NetrwBrowseUpDir mapping
This is not the case with the version of vim (2:8.2.2434-3ubuntu3.1)
which is included with Ubuntu 21.10 so I'm setting this task to Fix
Released but opening one for Focal.
** Also affects: vim (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: vim (Ubuntu)
Status: New => Fix Released
** Changed in: vim (Ubuntu Focal)
Status: New => Triaged
** Changed in: vim (Ubuntu Focal)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1951228
Title:
autoload/netrw.vim contains a typo on NetrwBrowseUpDir mapping
Status in vim package in Ubuntu:
Fix Released
Status in vim source package in Focal:
Triaged
Bug description:
Hello,
File /usr/share/vim/vim81/autoload/netrw.vim contains a typo on
NetrwBrowseUpDir. It should be
```
if !hasmapto('NetrwBrowseUpDir') |nmap
- NetrwBrowseUpDir|endif
``` (without space)
This minor but very annoying :-)
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vim 2:8.1.2269-1ubuntu5.4
ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
Uname: Linux 5.4.0-90-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 17 09:44:27 2021
InstallationDate: Installed on 2020-01-07 (679 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64
(20190805)
ProcEnviron:
TERM=screen-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=fr_FR.UTF-8
SHELL=/usr/bin/zsh
SourcePackage: vim
UpgradeStatus: Upgraded to focal on 2021-08-16 (92 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1951228/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639452] Re: systemd ExecStartPre test config
oh Focal is affected as well, that makes it more reasonable to at least consider a smaller version (not the full rewrite, but as suggested maybe pass the config dir at least). ** Also affects: dnsmasq (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: dnsmasq (Ubuntu Bionic) Status: New => Triaged ** Changed in: dnsmasq (Ubuntu Focal) Status: New => Triaged ** Changed in: dnsmasq (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: dnsmasq (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: dnsmasq (Ubuntu) Status: Triaged => Fix Released ** Tags added: server-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1639452 Title: systemd ExecStartPre test config Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Bionic: Triaged Status in dnsmasq source package in Focal: Triaged Bug description: The standard configuration file of dnsmasq is complete commented out. The real configuration is saved in /etc/dnsmasq.d, so the test of systemd is a fake. In the Service Section of /lib/systemd/system/dnsmasq.service the ExecStartPre directive should be set to "/usr/sbin/dnsmasq --conf- dir=/etc/dnsmasq.d --test" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639452/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639452] Re: systemd ExecStartPre test config
Enough late posts for a lack of activity on this, this time I think we
can close it :-)
What used to be:
ExecStartPre=/usr/sbin/dnsmasq --test
Nowadays is:
ExecStartPre=/etc/init.d/dnsmasq checkconfig
that maps it to
${DAEMON} --test ${CONFIG_DIR:+ -7 ${CONFIG_DIR}} ${DNSMASQ_OPTS:+
${DNSMASQ_OPTS}} >/dev/null 2>&1
Which includes not only config-dir but also all other configs that might
affect it.
It is not yet started as After=systemd-resolved.service but tolerates both
modes nowadays.
1. with systemd-resolved stopped
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor
preset: enabled)
Active: active (running) since Wed 2021-11-17 15:49:59 UTC; 5s ago
Process: 29898 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited,
status=0/SUCCESS)
Process: 29906 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited,
status=0/SUCCESS)
Process: 29915 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf
(code=exited, status=0/SUCCESS)
Main PID: 29914 (dnsmasq)
Tasks: 1 (limit: 38266)
Memory: 2.0M
CGroup: /system.slice/dnsmasq.service
└─29914 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq
-7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c>
Nov 17 15:49:59 j systemd[1]: Starting dnsmasq - A lightweight DHCP and caching
DNS server...
Nov 17 15:49:59 j dnsmasq[29914]: started, version 2.85 cachesize 150
Nov 17 15:49:59 j dnsmasq[29914]: DNS service limited to local subnets
Nov 17 15:49:59 j dnsmasq[29914]: compile time options: IPv6 GNU-getopt DBus
no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash
DNSSEC loop-detect inotify dumpfile
Nov 17 15:49:59 j dnsmasq[29914]: reading /etc/resolv.conf
Nov 17 15:49:59 j dnsmasq[29914]: using nameserver 127.0.0.53#53
Nov 17 15:49:59 j dnsmasq[29914]: read /etc/hosts - 7 addresses
Nov 17 15:49:59 j systemd[1]: Started dnsmasq - A lightweight DHCP and caching
DNS server.
2. with systemd-resolved stopped and /etc/resolv.conf removed
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor
preset: enabled)
Active: active (running) since Wed 2021-11-17 15:50:41 UTC; 3s ago
Process: 29937 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited,
status=0/SUCCESS)
Process: 29945 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited,
status=0/SUCCESS)
Process: 29954 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf
(code=exited, status=0/SUCCESS)
Main PID: 29953 (dnsmasq)
Tasks: 1 (limit: 38266)
Memory: 1.8M
CGroup: /system.slice/dnsmasq.service
└─29953 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq
-7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c>
Nov 17 15:50:41 j systemd[1]: Starting dnsmasq - A lightweight DHCP and caching
DNS server...
Nov 17 15:50:41 j dnsmasq[29953]: started, version 2.85 cachesize 150
Nov 17 15:50:41 j dnsmasq[29953]: DNS service limited to local subnets
Nov 17 15:50:41 j dnsmasq[29953]: compile time options: IPv6 GNU-getopt DBus
no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash
DNSSEC loop-detect inotify dumpfile
Nov 17 15:50:41 j dnsmasq[29953]: read /etc/hosts - 7 addresses
Nov 17 15:50:41 j systemd[1]: Started dnsmasq - A lightweight DHCP and caching
DNS server.
In none of these modes it gets stuck and I'm unsure if adding the After
nowadays would really be right. Even if so as I explained in the past that
should go through a report to the Debian bug tracker as the issue is not Ubuntu
specific in this case and we'd like to fix both.
---
Backports of this change are unlikely to qualify for the SRU process [1]
as the rework of the init scripts can have plenty of side effects that
might break existing users.
So the check it runs in ExecStartPre might be useless, but only if it
would really break people (and I've not seen reports other than this
one, so it might not be that common of a problem at all) it might
justify the risk of changing that. It is valid for a backport, but IMHO
low prio and probably not done unless somebody speaks up outlining why
this is more severe than it seems.
Bionic is still affected, I'm marking this as such.
[1]: https://wiki.ubuntu.com/StableReleaseUpdates
** Also affects: dnsmasq (Ubuntu Bionic)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639452
Title:
systemd ExecStartPre test config
Status in dnsmasq package in Ubuntu:
Fix Released
Status in dnsmasq source package in Bionic:
Triaged
Status in dnsmasq source package in Focal:
[Touch-packages] [Bug 1946213] Re: strongswan: Fail to build against OpenSSL 3.0
** Changed in: strongswan (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1946213 Title: strongswan: Fail to build against OpenSSL 3.0 Status in OpenSSL: Fix Released Status in strongSwan: New Status in openssl package in Ubuntu: Invalid Status in strongswan package in Ubuntu: In Progress Bug description: Hello, As part of a rebuild against OpenSSL3, this package failed to build on one or several architectures. You can find the details of the rebuild at https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html or for the amd64 failed build, directly at https://launchpad.net/~schopin/+archive/ubuntu/openssl-3.0.0/+build/22099394/+files/buildlog_ubuntu- impish-amd64.strongswan_5.9.1-1ubuntu3.0~ssl3ppa1.1_BUILDING.txt.gz We're planning to transition to OpenSSL 3.0 for the 22.04 release, and consider this issue as blocking for this transition. You can find general migration informations at https://www.openssl.org/docs/manmaster/man7/migration_guide.html For your tests, you can build against libssl-dev as found in the PPA schopin/openssl-3.0.0 The issue looks fixed upstream on master: https://github.com/strongswan/strongswan/commit/72e5b3b7022ad14b245565a5aadcd097106af168 To manage notifications about this bug go to: https://bugs.launchpad.net/openssl/+bug/1946213/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
And let them judge if it's worth an upstream adoption or not as a first
exercise. Then we can take a decision for Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
I still believe, it would be a good practice to submit the patch to
upstream.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
And let them judge if it's worth the adoption or not as a first
exercise. Then we can take a decision for Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers
Reverting this upstream commit seems to fix the problem: https://github.com/systemd/systemd/commit/0299deab53d2a087727a5d04c1500c322c48b63e -- 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/1950794 Title: DHCPv4 (IAID+DUID) networking broken in LXC containers Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: DHCPv4 networking does not work in the default IAID+DUID (ClientIdentifier=duid) mode in LXC containers, using systemd-networkd v249.5-2ubuntu1. Static configuration and DHCPv6 work without problem. Reproducer: $ lxc launch ubuntu-daily:jammy jj $ lxc exec jj bash # add-apt-repository ppa:ci-train-ppa-service/4704 # apt install systemd # install systemd 249.5-2ubuntu1 # cat /etc/systemd/network/00-test.network [Match] Name=eth0 [Network] DHCP=ipv4 # systemctl restart systemd-networkd.service # networkctl IDX LINK TYPE OPERATIONAL SETUP [...] 611 eth0 ethercarrier failed A workaround is to avoid IAID+DUID mode via: [DHCPv4] #ClientIdentifier=mac ClientIdentifier=duid-only Interesting logs: Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Requested to activate link Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCPv4 client: Failed to set IAID: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCP4 CLIENT: Failed to set IAID+DUID: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: Failed to check link is initialized: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838151] Re: Poor quality audio with modern Bluetooth headsets in HSP/HFP. Missing wide band speech support (Bluetooth A2DP codecs).
While waiting for the next LTS version of Ubuntu I was able to fix the mic issue on 20.04 by installing pipewire (followed this guide https://askubuntu.com/questions/1330395/newly-installed- ubuntu-20-04-bluetooth-headset-sound-and-mic-not-working/1340889#1340889 except I installed wireplumber instead of media session as the latter one was not able to remember the chosen profile) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1838151 Title: Poor quality audio with modern Bluetooth headsets in HSP/HFP. Missing wide band speech support (Bluetooth A2DP codecs). Status in PulseAudio: Fix Released Status in bluez package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: Fix Released Status in Arch Linux: New Bug description: Bluetooth HSP/HFP audio quality is poor on Ubuntu comparative to all other major platforms (Windows, MacOS, ChromeOS, Android, iOS). Modern Bluetooth headsets (such as the Bose QC series headphones, many others) are capable of using HFP 1.6 with mSBC 16kHz audio encoding. As it currently stands, Ubuntu defaults to only supporting HSP headsets using 8kHz CVSD, and is incapable of supporting HFP 1.6 at this time. The ChromiumOS team recently tackled this issue - https://bugs.chromium.org/p/chromium/issues/detail?id=843048 Their efforts may assist in bringing this to Ubuntu, however it appears that there are quite a lot of differences considering they have developed their own audio server solution etc. The Bluetooth Telephony Working Group published the HFP 1.6 spec in May 2011 - https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238193 Patches have been proposed in the past for this issue to the kernel and PulseAudio: PulseAudio: https://patchwork.freedesktop.org/patch/245272/ Kernel: https://www.spinics.net/lists/linux-bluetooth/msg76982.html It appears that the Chromium OS team applied the same kernel patch: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/77dd0cb94c1713a8a12f6e392955dfa64c430e54 ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: pulseaudio 1:12.2-2ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jnappi 2777 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sat Jul 27 11:08:29 2019 EcryptfsInUse: Yes InstallationDate: Installed on 2017-11-04 (629 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: Upgraded to disco on 2019-07-18 (9 days ago) dmi.bios.date: 06/07/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R07ET67W (2.07 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FW000TUS dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR07ET67W(2.07):bd06/07/2016:svnLENOVO:pn20FW000TUS:pvrThinkPadT460p:rvnLENOVO:rn20FW000TUS:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460p dmi.product.name: 20FW000TUS dmi.product.sku: LENOVO_MT_20FW_BU_Think_FM_ThinkPad T460p dmi.product.version: ThinkPad T460p dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/1838151/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
@slyon you might want to see if commit 918e6f1c0151429f5095355f4f3f74f16e79724a fixes this -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Khaled El Mously (kmously),
Thanks for the update. I'll review this and talk with sil2100, an SRU
verification member.
Could you please help to fill the SRU template in the description above.
Extra documentations can be found here:
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
What make Bionic more susceptible to this particular problem ? Bionic
kernel version in use ? else ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950996] Re: Missing all modules for usb nics in initrd which makes PXE boot impossible
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: initramfs-tools (Ubuntu Impish) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1950996 Title: Missing all modules for usb nics in initrd which makes PXE boot impossible Status in initramfs-tools package in Ubuntu: Triaged Status in initramfs-tools source package in Focal: Confirmed Status in initramfs-tools source package in Hirsute: Confirmed Status in initramfs-tools source package in Impish: Confirmed Status in initramfs-tools source package in Jammy: Triaged Bug description: initrd taken from the live iso for PXE boot does not contain USB NIC drivers which makes PXE installation/netboot impossible via usb. This is the case on 20.04 server iso (both hwe and normal kernel/initrd) and desktop iso. "kernel/drivers/net/usb" is empty and needs to be included in the initramfs build. As most modern thin laptops lack physical rj45 ethernet this is a big issue. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.6 ProcVersionSignature: Ubuntu 5.8.0-64.72-generic 5.8.18 Uname: Linux 5.8.0-64-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Nov 15 16:47:45 2021 PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: Upgraded to focal on 2020-05-11 (552 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1950996/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950996] Re: Missing all modules for usb nics in initrd which makes PXE boot impossible
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: initramfs-tools (Ubuntu Hirsute) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1950996 Title: Missing all modules for usb nics in initrd which makes PXE boot impossible Status in initramfs-tools package in Ubuntu: Triaged Status in initramfs-tools source package in Focal: Confirmed Status in initramfs-tools source package in Hirsute: Confirmed Status in initramfs-tools source package in Impish: Confirmed Status in initramfs-tools source package in Jammy: Triaged Bug description: initrd taken from the live iso for PXE boot does not contain USB NIC drivers which makes PXE installation/netboot impossible via usb. This is the case on 20.04 server iso (both hwe and normal kernel/initrd) and desktop iso. "kernel/drivers/net/usb" is empty and needs to be included in the initramfs build. As most modern thin laptops lack physical rj45 ethernet this is a big issue. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.6 ProcVersionSignature: Ubuntu 5.8.0-64.72-generic 5.8.18 Uname: Linux 5.8.0-64-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Nov 15 16:47:45 2021 PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: Upgraded to focal on 2020-05-11 (552 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1950996/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950996] Re: Missing all modules for usb nics in initrd which makes PXE boot impossible
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: initramfs-tools (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1950996 Title: Missing all modules for usb nics in initrd which makes PXE boot impossible Status in initramfs-tools package in Ubuntu: Triaged Status in initramfs-tools source package in Focal: Confirmed Status in initramfs-tools source package in Hirsute: Confirmed Status in initramfs-tools source package in Impish: Confirmed Status in initramfs-tools source package in Jammy: Triaged Bug description: initrd taken from the live iso for PXE boot does not contain USB NIC drivers which makes PXE installation/netboot impossible via usb. This is the case on 20.04 server iso (both hwe and normal kernel/initrd) and desktop iso. "kernel/drivers/net/usb" is empty and needs to be included in the initramfs build. As most modern thin laptops lack physical rj45 ethernet this is a big issue. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.6 ProcVersionSignature: Ubuntu 5.8.0-64.72-generic 5.8.18 Uname: Linux 5.8.0-64-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Nov 15 16:47:45 2021 PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: Upgraded to focal on 2020-05-11 (552 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1950996/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915238] Re: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
This bug is in our backlog, we still did not have time to tackle it. Paride made a great analysis above, and I believe we should try to talk to the Debian maintainer to see if they agree with the proposed solution and land the fix there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1915238 Title: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ Status in ca-certificates package in Ubuntu: New Status in postfix package in Ubuntu: Triaged Status in postfix package in Debian: New Bug description: Postfix package doesn't utilize update-ca-certificate's hooks mechanism. By simply copying certs from /etc/ssl/certs/ca- certificates.crt to /var/spool/postfix/etc/ssl/certs/ca- certificates.crt, this warning and potential security issues could be avoided. Something like this would be a start: $ cat /etc/ca-certificates/update.d/postfix #!/bin/bash if [ -e /var/spool/postfix/etc/ssl/certs/ca-certificates.crt ]; then echo "Updating postfix chrooted certs" cp /etc/ssl/certs/ca-certificates.crt /var/spool/postfix/etc/ssl/certs/ca-certificates.crt systemctl reload postfix fi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1915238/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1934439] Re: Add Ubuntu Pro banner to Livepatch page
This bug was fixed in the package software-properties - 0.99.16 --- software-properties (0.99.16) jammy; urgency=medium * Show Ubuntu Pro banner on Livepatch page (LP: #1934439) -- Robert Ancell Wed, 17 Nov 2021 16:17:44 +1300 ** Changed in: software-properties (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1934439 Title: Add Ubuntu Pro banner to Livepatch page Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: New Status in software-properties source package in Bionic: Fix Committed Status in software-properties source package in Focal: Fix Released Bug description: [Impact] Add a banner to the Livepatch page to invite users to join the Ubuntu Pro for Desktop. Note that this is not shown in current releases, as this feature only applies to older versions. [Test Case] 1. Open Software Properties. 2. Go to Livepatch tab. Expected result: A banner is shown directing the user to Ubuntu Pro. The banner can be dismissed, and doesn't return when restarting software-properties. [Regression Potential] Some risk of introducing a new bug, however the change is quite small and doesn't have any complex interactions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1934439/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
** Also affects: ufw Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python Status in ufw: New Status in ufw package in Ubuntu: New Bug description: Version: ufw 0.36 Ubuntu Version: 20.04.3 LTS There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner. In the source code (root/src/backend.py) there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method: def get_rules(self): '''Return list of all rules''' return self.rules + self.rules6 The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following. 1 allow 22/tcp 2 allow 80 3 allow 443 4 allow 22/tcp 5 allow 80 6 allow 443 I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.: rules_ipv4 = backend.rules rules_ipv6 = backend.rules6 One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.: def get_rules_ipv4(self): '''Return list of all ipv4 rules''' return self.rules def get_rules_ipv6(self): '''Return list of all ipv6 rules''' return self.rules6 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1871465] Re: ssh_config(5) contains outdated information
This has been fixed upstream, as shown in [1] and is available in jammy. [1] https://github.com/openssh/openssh-portable/commit/53ea05e09b04fd7b6dea66b42b34d65fe61b9636 ** Also affects: openssh (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: openssh (Ubuntu) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1871465 Title: ssh_config(5) contains outdated information Status in openssh package in Ubuntu: Fix Committed Status in openssh source package in Focal: New Status in openssh source package in Hirsute: New Status in openssh source package in Impish: New Bug description: The release of OpenSSH 8.2 has removed `ssh-rsa` from the default list of CACertificateAlgorithms. However the latest `openssh-client` still ships the man page for ssh_config(5) that contains the following description: CASignatureAlgorithms Specifies which algorithms are allowed for signing of certificates by certificate authorities (CAs). The default is: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa ssh(1) will not accept host certificates signed using algorithms other than those specified. As far as I am concerned, `ssh-rsa` should be dropped from the list so as to match the behavior of ssh(1). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1871465/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951228] Re: autoload/netrw.vim contains a typo on NetrwBrowseUpDir mapping
The attachment "netrw.diff" seems to be a patch. If it isn't, please
remove the "patch" flag from the attachment, remove the "patch" tag, and
if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1951228
Title:
autoload/netrw.vim contains a typo on NetrwBrowseUpDir mapping
Status in vim package in Ubuntu:
New
Bug description:
Hello,
File /usr/share/vim/vim81/autoload/netrw.vim contains a typo on
NetrwBrowseUpDir. It should be
```
if !hasmapto('NetrwBrowseUpDir') |nmap
- NetrwBrowseUpDir|endif
``` (without space)
This minor but very annoying :-)
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vim 2:8.1.2269-1ubuntu5.4
ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
Uname: Linux 5.4.0-90-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 17 09:44:27 2021
InstallationDate: Installed on 2020-01-07 (679 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64
(20190805)
ProcEnviron:
TERM=screen-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=fr_FR.UTF-8
SHELL=/usr/bin/zsh
SourcePackage: vim
UpgradeStatus: Upgraded to focal on 2021-08-16 (92 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1951228/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1921518] Re: OpenSSL "double free" error
** No longer affects: openssl (Ubuntu Focal) ** No longer affects: openssl (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wget in Ubuntu. https://bugs.launchpad.net/bugs/1921518 Title: OpenSSL "double free" error Status in wget package in Ubuntu: Fix Released Status in wget source package in Focal: Fix Committed Bug description: [Impact] openssl config file is being loaded twice, causing engines to be loaded twice if specified therein, causing double free errors and other strange behavior. [Test plan] Run the command of the package being tested in gdb -ex "break CONF_modules_load_file" -ex "run" --args and make sure it only breaks one. Regression test: In default Ubuntu configuration, either no openssl configuration is provided, or it contains no settings that affect wget. This code path changes how/when openssl configuration is loaded and used by openssl. One should verify that: 1) wget continues to work without openssl.cnf 2) wget continues to work with stock ubuntu unmodified openssl.cnf 3) wget continue to honor and use custom TLS settings that one may have specified in openssl.cnf (for example custom engine) [Where problems could occur] wget: This is an upstream change that changes initialization and is in use in later releases. Since it mostly removes an unneeded call to the load file function, a regression could be a config file being ignored, but it seems unlikely given the use in later releases [Original bug report] "double free" error is seen when using curl utility. Error is from libcrypto.so which is part of the OpenSSL package. This happens only when OpenSSL is configured to use a dynamic engine. OpenSSL version is 1.1.1f The issue is not encountered if http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead. OpenSSL can be configured to use a dynamic engine by editing the default openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu systems. On Bluefield systems, config diff to enable PKA dynamic engine, is as below: +openssl_conf = conf_section + # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section= new_oids +[ conf_section ] +engines = engine_section + +[ engine_section ] +bf = bf_section + +[ bf_section ] +engine_id=pka +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so +init=0 + engine_id above refers to dynamic engine name/identifier. dynamic_path points to the .so file for the dynamic engine. # curl -O https://tpo.pe/pathogen.vim double free or corruption (out) Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1921518/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers
Turns out dropping "debian/patches/units-Don-t-start-systemd-udev- trigger.service-in-a-conta.patch" (that we want to drop anyway) makes a difference here, i.e. removing the "ConditionVirtualization=!container" line from /usr/lib/systemd/service/systemd-udev-trigger.service. # apt install systemd udev # upgrade systemd & udev to v249 # systemctl restart systemd-udev-trigger # run the 'udevadm trigger' commands # systemctl restart systemd-networkd # restart networkd to re-run the DHCPv4 client. That is even though the systemd-udev-trigger.service fails to execute successfully: # systemctl status systemd-udev-trigger.service ● systemd-udev-trigger.service - Coldplug All udev Devices Loaded: loaded (/lib/systemd/system/systemd-udev-trigger.service; static) Active: active (exited) since Wed 2021-11-17 09:39:01 UTC; 37s ago Docs: man:udev(7) man:systemd-udevd.service(8) Process: 74 ExecStart=udevadm trigger --type=subsystems --action=add (code=exited, status=1/FAILURE) Process: 101 ExecStart=udevadm trigger --type=devices --action=add (code=exited, status=1/FAILURE) Main PID: 101 (code=exited, status=1/FAILURE) CPU: 160ms Nov 17 09:39:01 jj2 udevadm[101]: nvme-delete-wq: Failed to write 'add' to '/sys/devices/virtual/workqueue/nvme-delete-wq/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: nvme-reset-wq: Failed to write 'add' to '/sys/devices/virtual/workqueue/nvme-reset-wq/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: nvme-wq: Failed to write 'add' to '/sys/devices/virtual/workqueue/nvme-wq/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: raid5wq: Failed to write 'add' to '/sys/devices/virtual/workqueue/raid5wq/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: scsi_tmf_0: Failed to write 'add' to '/sys/devices/virtual/workqueue/scsi_tmf_0/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: writeback: Failed to write 'add' to '/sys/devices/virtual/workqueue/writeback/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: dm-0: Failed to write 'add' to '/sys/devices/virtual/block/dm-0/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: dm-1: Failed to write 'add' to '/sys/devices/virtual/block/dm-1/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: dm-2: Failed to write 'add' to '/sys/devices/virtual/block/dm-2/uevent': Permission denied Nov 17 09:39:01 jj2 udevadm[101]: dm-3: Failed to write 'add' to '/sys/devices/virtual/block/dm-3/uevent': Permission denied -- 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/1950794 Title: DHCPv4 (IAID+DUID) networking broken in LXC containers Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: DHCPv4 networking does not work in the default IAID+DUID (ClientIdentifier=duid) mode in LXC containers, using systemd-networkd v249.5-2ubuntu1. Static configuration and DHCPv6 work without problem. Reproducer: $ lxc launch ubuntu-daily:jammy jj $ lxc exec jj bash # add-apt-repository ppa:ci-train-ppa-service/4704 # apt install systemd # install systemd 249.5-2ubuntu1 # cat /etc/systemd/network/00-test.network [Match] Name=eth0 [Network] DHCP=ipv4 # systemctl restart systemd-networkd.service # networkctl IDX LINK TYPE OPERATIONAL SETUP [...] 611 eth0 ethercarrier failed A workaround is to avoid IAID+DUID mode via: [DHCPv4] #ClientIdentifier=mac ClientIdentifier=duid-only Interesting logs: Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Requested to activate link Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCPv4 client: Failed to set IAID: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCP4 CLIENT: Failed to set IAID+DUID: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: Failed to check link is initialized: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1946213] Re: strongswan: Fail to build against OpenSSL 3.0
** Changed in: openssl (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1946213 Title: strongswan: Fail to build against OpenSSL 3.0 Status in OpenSSL: Fix Released Status in strongSwan: New Status in openssl package in Ubuntu: Invalid Status in strongswan package in Ubuntu: New Bug description: Hello, As part of a rebuild against OpenSSL3, this package failed to build on one or several architectures. You can find the details of the rebuild at https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html or for the amd64 failed build, directly at https://launchpad.net/~schopin/+archive/ubuntu/openssl-3.0.0/+build/22099394/+files/buildlog_ubuntu- impish-amd64.strongswan_5.9.1-1ubuntu3.0~ssl3ppa1.1_BUILDING.txt.gz We're planning to transition to OpenSSL 3.0 for the 22.04 release, and consider this issue as blocking for this transition. You can find general migration informations at https://www.openssl.org/docs/manmaster/man7/migration_guide.html For your tests, you can build against libssl-dev as found in the PPA schopin/openssl-3.0.0 The issue looks fixed upstream on master: https://github.com/strongswan/strongswan/commit/72e5b3b7022ad14b245565a5aadcd097106af168 To manage notifications about this bug go to: https://bugs.launchpad.net/openssl/+bug/1946213/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951228] [NEW] autoload/netrw.vim contains a typo on NetrwBrowseUpDir mapping
Public bug reported:
Hello,
File /usr/share/vim/vim81/autoload/netrw.vim contains a typo on
NetrwBrowseUpDir. It should be
```
if !hasmapto('NetrwBrowseUpDir') |nmap-
NetrwBrowseUpDir|endif
``` (without space)
This minor but very annoying :-)
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vim 2:8.1.2269-1ubuntu5.4
ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
Uname: Linux 5.4.0-90-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 17 09:44:27 2021
InstallationDate: Installed on 2020-01-07 (679 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
ProcEnviron:
TERM=screen-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=fr_FR.UTF-8
SHELL=/usr/bin/zsh
SourcePackage: vim
UpgradeStatus: Upgraded to focal on 2021-08-16 (92 days ago)
** Affects: vim (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal third-party-packages
** Patch added: "netrw.diff"
https://bugs.launchpad.net/bugs/1951228/+attachment/5541433/+files/netrw.diff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1951228
Title:
autoload/netrw.vim contains a typo on NetrwBrowseUpDir mapping
Status in vim package in Ubuntu:
New
Bug description:
Hello,
File /usr/share/vim/vim81/autoload/netrw.vim contains a typo on
NetrwBrowseUpDir. It should be
```
if !hasmapto('NetrwBrowseUpDir') |nmap
- NetrwBrowseUpDir|endif
``` (without space)
This minor but very annoying :-)
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vim 2:8.1.2269-1ubuntu5.4
ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
Uname: Linux 5.4.0-90-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 17 09:44:27 2021
InstallationDate: Installed on 2020-01-07 (679 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64
(20190805)
ProcEnviron:
TERM=screen-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=fr_FR.UTF-8
SHELL=/usr/bin/zsh
SourcePackage: vim
UpgradeStatus: Upgraded to focal on 2021-08-16 (92 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1951228/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
