[Touch-packages] [Bug 282186] Re: HP Photosmart 2610 top first cm not printed
You can download the driver for the HP Deskjet 2630 in : https://file- hpdrivers.com/hp-photosmart/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/282186 Title: HP Photosmart 2610 top first cm not printed Status in HPLIP: Confirmed Status in cups package in Ubuntu: Fix Released Status in foomatic-db-hpijs package in Ubuntu: Invalid Status in cups source package in Intrepid: Fix Released Status in foomatic-db-hpijs source package in Intrepid: Invalid Status in cups source package in Jaunty: Fix Released Status in foomatic-db-hpijs source package in Jaunty: Invalid Bug description: Binary package hint: hpijs Since I upgraded to Intrepid I experienced a strange printout bug. The printer normally leaves a margin of about 5 millimeter around the printout. Now since Intrepid it just cuts of about another 7 to 8 millimeters off at the top. The problem occurs on both 32bit and 64bit. I attached a couple of pictures as PDFs. The testprintout.pdf is what I printed out once in Hardy and once in Intrepid. I attached the results as hardy and intrepid_printout. Also I printed out once the default test printout page. As you can clearly see, the lines that should go all around the document are just cut off. The only hint about it, I got so far, is that when I print out the default test page, it says in the "Printer status" field in the "Printer properties" window the following: "No %%Pages: comment in header!". I tried downloading the .ppd from openprinting.org, replacing the intrepid one with the one from Hardy, but nothing helped. If you need any other debug info please say so, what and how. To manage notifications about this bug go to: https://bugs.launchpad.net/hplip/+bug/282186/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841745] [NEW] Update to 1.2.0 not this cycle
Public bug reported: The new version has non trivial change and is not in Debian/Fedora yet, better to wait for next cycle at this point ** Affects: libxt (Ubuntu) Importance: Wishlist Status: New ** Tags: upgrade-software-version version-blocked-ff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libxt in Ubuntu. https://bugs.launchpad.net/bugs/1841745 Title: Update to 1.2.0 not this cycle Status in libxt package in Ubuntu: New Bug description: The new version has non trivial change and is not in Debian/Fedora yet, better to wait for next cycle at this point To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libxt/+bug/1841745/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841742] [NEW] Ubuntu says: "The problem cannot be reported."
You have been subscribed to a public bug: With Ubuntu 19.10 I get continuously problem reports, which I try to send to Ubuntu, but which don't leave my PC, because the next info is: The problem cannot be reported: The problem happened with the program /usr/lib/gnome-session/gnome-session-binary which changed since the crash occurred. --- I have done nothing in between. Only Ubuntu has acted. ** Affects: apport (Ubuntu) Importance: Undecided Status: New -- Ubuntu says: "The problem cannot be reported." https://bugs.launchpad.net/bugs/1841742 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841742] Re: Ubuntu says: "The problem cannot be reported."
** Project changed: launchpad => apport (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1841742 Title: Ubuntu says: "The problem cannot be reported." Status in apport package in Ubuntu: New Bug description: With Ubuntu 19.10 I get continuously problem reports, which I try to send to Ubuntu, but which don't leave my PC, because the next info is: The problem cannot be reported: The problem happened with the program /usr/lib/gnome-session/gnome-session-binary which changed since the crash occurred. --- I have done nothing in between. Only Ubuntu has acted. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1841742/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU
** Changed in: systemd (Ubuntu) Status: Confirmed => Invalid ** Changed in: bluez (Ubuntu) Status: Invalid => Confirmed ** Changed in: bluez (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: bluez (Ubuntu) Status: Confirmed => In Progress ** Changed in: bluez (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Status: Incomplete => Invalid -- 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/1759836 Title: systemd-udevd consumes 100% of CPU Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez package in Debian: Unknown Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1740894] Re: KEY_RFKILL is not passed to userspace
** Changed in: oem-priority/bionic Status: In Progress => Fix Committed ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic ** Changed in: oem-priority Status: New => Fix Released ** Changed in: oem-priority/bionic Status: Fix Committed => Fix Released ** Tags removed: verification-needed ** Tags added: verification-done -- 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/1740894 Title: KEY_RFKILL is not passed to userspace Status in OEM Priority Project: Fix Released Status in OEM Priority Project bionic series: Fix Released Status in libxkbcommon package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in xkeyboard-config package in Ubuntu: Fix Released Status in xorgproto package in Ubuntu: Fix Released Status in libxkbcommon source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Committed Status in xkeyboard-config source package in Bionic: Fix Committed Status in xorgproto source package in Bionic: Fix Released Status in libxkbcommon source package in Cosmic: Fix Released Status in xkeyboard-config source package in Cosmic: Fix Released Status in xorgproto source package in Cosmic: Fix Released Bug description: * Impact the airplane mode key doesn't work in GNOME * Test case Use a laptop with a key to activate airplane mode, it should toggle the corresponding mode on/off when used * Regression potential The change adds a new key definition but doesn't touch any existing one, nothing specific to test out of the new key working - There are a couple things going on, that could be fixed by a Debian or Ubuntu maintainer: - libxkbdcommon needs to be updated from 0.7.1 to 0.7.2. This introduces the RFKill key: https://lists.freedesktop.org/archives /wayland-devel/2017-August/034721.html - x11-proto needs a new release. This commit added RFKill, but it is not in a release: https://cgit.freedesktop.org/xorg/proto/xproto/commit/?id=98a32d328e7195e12c38baa877917335bceffbaf - Likely other X11 packages need to be rebuilt. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1740894/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU
As many have commented, this is almost certainly a bug in the bluez udev rule 'hid2hci', that is caused by the introduction of 'bind' and 'unbind' uevents. Can anyone who can reproduce this bug test with the bluez package from this ppa: https://launchpad.net/~ddstreet/+archive/ubuntu/lp1759836 -- 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/1759836 Title: systemd-udevd consumes 100% of CPU Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez package in Debian: Unknown Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1102906] Re: Cannot broadcast both on global and link address on same interface
Would it be possible to add a flag to AvahiPublishFlags to allow the application to request the required behaviour on a per-service basis? I can't see any options for Pidgin that don't require pretty radical restructuring of its codebase (more discussion at https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1841621/comments/10) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1102906 Title: Cannot broadcast both on global and link address on same interface Status in Avahi: Unknown Status in avahi package in Ubuntu: New Bug description: Avahi seems to be hardwired to not over any link-local addresses on an interface, if there also exists a global (non-link-local) address on the same interface. Unfortunately I have need for this feature. I patched the source accordingly myself, creating a new config option 'publish-local-always' to enable that behavior. It's actually I minimal change, and I would be pleased, if you could integrate it (or something similar). You can find my patch in the attachment below. To manage notifications about this bug go to: https://bugs.launchpad.net/avahi/+bug/1102906/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1822075] Re: tooltips and combo boxes in webbrowsers are all garbage in xserver-xorg-video-radeon 1:19.0.0-1
Hi Dan I did not report this bug Steve On August 28, 2019 3:26:09 AM Daniel van Vugt wrote: > Returned in bug 1841718? > > -- > You received this bug notification because you are subscribed to a > duplicate bug report (1821552). > https://bugs.launchpad.net/bugs/1822075 > > Title: > tooltips and combo boxes in webbrowsers are all garbage in xserver- > xorg-video-radeon 1:19.0.0-1 > > Status in gtk+3.0 package in Ubuntu: > Invalid > Status in mesa package in Ubuntu: > Invalid > Status in mutter package in Ubuntu: > Invalid > Status in xserver-xorg-video-ati package in Ubuntu: > Fix Released > > Bug description: > Disco up to date > > With Chrome and Firefox tooltips and combo boxes are all garbage and > make the browser unusable. Cf screenshots. > > Graphics card: > Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 5770] > > I tried gtk2 and gtk3 demos and the combo boxes are broken in the same > way. > > I also tried FF as a snap and as a deb and the problem is the same. > > ProblemType: Bug > DistroRelease: Ubuntu 19.04 > Package: gnome-shell 3.32.0-1ubuntu1 > ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 > Uname: Linux 5.0.0-7-generic x86_64 > NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair > ApportVersion: 2.20.10-0ubuntu23 > Architecture: amd64 > CurrentDesktop: ubuntu:GNOME > Date: Thu Mar 28 11:51:41 2019 > DisplayManager: gdm3 > InstallationDate: Installed on 2014-07-15 (1717 days ago) > InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140520) > SourcePackage: gnome-shell > UpgradeStatus: Upgraded to disco on 2018-03-24 (368 days ago) > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1822075/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1822075 Title: tooltips and combo boxes in webbrowsers are all garbage in xserver- xorg-video-radeon 1:19.0.0-1 Status in gtk+3.0 package in Ubuntu: Invalid Status in mesa package in Ubuntu: Invalid Status in mutter package in Ubuntu: Invalid Status in xserver-xorg-video-ati package in Ubuntu: Fix Released Bug description: Disco up to date With Chrome and Firefox tooltips and combo boxes are all garbage and make the browser unusable. Cf screenshots. Graphics card: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 5770] I tried gtk2 and gtk3 demos and the combo boxes are broken in the same way. I also tried FF as a snap and as a deb and the problem is the same. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: gnome-shell 3.32.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 Uname: Linux 5.0.0-7-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 28 11:51:41 2019 DisplayManager: gdm3 InstallationDate: Installed on 2014-07-15 (1717 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140520) SourcePackage: gnome-shell UpgradeStatus: Upgraded to disco on 2018-03-24 (368 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1822075/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1726068] Re: debconf socket closes if aptdaemon/PK client exits
** Also affects: software-properties (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: packagekit (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: aptdaemon (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: apper (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: software-properties (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: packagekit (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: aptdaemon (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: apper (Ubuntu Bionic) Importance: Undecided Status: New ** No longer affects: software-properties (Ubuntu Bionic) ** No longer affects: software-properties (Ubuntu Disco) ** Changed in: packagekit (Ubuntu Disco) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1726068 Title: debconf socket closes if aptdaemon/PK client exits Status in apper package in Ubuntu: New Status in aptdaemon package in Ubuntu: Fix Released Status in packagekit package in Ubuntu: Fix Released Status in software-properties package in Ubuntu: Invalid Status in apper source package in Bionic: New Status in aptdaemon source package in Bionic: New Status in packagekit source package in Bionic: New Status in apper source package in Disco: New Status in aptdaemon source package in Disco: New Status in packagekit source package in Disco: In Progress Bug description: [Impact] Closing an application using PackageKit or aptdaemon to install packages kills the debconf endpoint (because it's a subprocess that's cleaned up), causing debconf to use defaults which might lead to wrong results, or even cause installations to fail. [Solution] The solution is to move the end point into a socket-activated systemd unit, so that it is independent of the graphical frontend that started the transaction. The other advantage is that this offers us restart if the end point crashes. [Test case] 1. Install opera deb using packagekit, ensure service is activated 2. Install opera deb using aptdaemon, ensure service is activated Alternatively, you might use another deb that has debconf prompts. [Regression potential] Systems that do not yet use systemd will fall back to the old method, so should not regress. Otherwise, if there are bugs, they'd affect the ability to show debconf prompts, and behavior would revert to using the defaults. There might be some uncertainty if you restart your desktop while the helper is running and it does not pick up the new X/Wayland display until it restarts (it should fail to connect and restart). Given that the helper times out, this should not be an issue in practice, as you'd have to logout, login, and start a new install within 60 seconds. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apper/+bug/1726068/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1726068] Re: debconf socket closes if aptdaemon/PK client exits
** Description changed: - error message on start up + [Impact] + Closing an application using PackageKit or aptdaemon to install packages kills the debconf endpoint (because it's a subprocess that's cleaned up), causing debconf to use defaults which might lead to wrong results, or even cause installations to fail. - ProblemType: Package - DistroRelease: Ubuntu 16.04 - Package: shim-signed 1.32~16.04.1+0.9+1474479173.6c180c6-1ubuntu1 - ProcVersionSignature: Ubuntu 4.10.0-37.41~16.04.1-generic 4.10.17 - Uname: Linux 4.10.0-37-generic x86_64 - .proc.sys.kernel.moksbstate_disabled: 0 - ApportVersion: 2.20.1-0ubuntu2.10 - Architecture: amd64 - Date: Sun Oct 22 12:33:48 2017 - DpkgHistoryLog: - Start-Date: 2017-10-22 12:31:01 - Commandline: aptdaemon role='role-commit-packages' sender=':1.94' - Install: linux-image-generic:amd64 (4.4.0.97.102, automatic), libcuda1-387:amd64 (387.12-0ubuntu0~gpu16.04.1, automatic), linux-image-4.4.0-97-generic:amd64 (4.4.0-97.120, automatic), linux-image-extra-4.4.0-97-generic:amd64 (4.4.0-97.120, automatic), nvidia-prime:amd64 (0.8.2, automatic), libxnvctrl0:amd64 (384.90-0ubuntu0~gpu16.04.1, automatic), lib32gcc1:amd64 (1:6.0.1-0ubuntu1, automatic), libc6-i386:amd64 (2.23-0ubuntu9, automatic), screen-resolution-extra:amd64 (0.17.1, automatic), ocl-icd-libopencl1:amd64 (2.2.8-1, automatic), libjansson4:amd64 (2.7-3, automatic), bbswitch-dkms:amd64 (0.8-3ubuntu1, automatic), linux-generic:amd64 (4.4.0.97.102), nvidia-opencl-icd-387:amd64 (387.12-0ubuntu0~gpu16.04.1, automatic), nvidia-387:amd64 (387.12-0ubuntu0~gpu16.04.1), nvidia-settings:amd64 (384.90-0ubuntu0~gpu16.04.1, automatic) - EFITables: - Oct 22 12:34:32 crs-Ubuntu kernel: efi: EFI v2.40 by American Megatrends - Oct 22 12:34:32 crs-Ubuntu kernel: efi: ESRT=0x77e72f98 ACPI=0x77591000 ACPI 2.0=0x77591000 SMBIOS=0x77e71000 SMBIOS 3.0=0x77e7 - Oct 22 12:34:32 crs-Ubuntu kernel: esrt: Reserving ESRT space from 0x77e72f98 to 0x77e72fd0. - Oct 22 12:34:32 crs-Ubuntu kernel: Secure boot enabled - ErrorMessage: subprocess installed post-installation script returned error exit status 1 - InstallationDate: Installed on 2017-05-16 (159 days ago) - InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) - RelatedPackageVersions: - dpkg 1.18.4ubuntu1.2 - apt 1.2.24 - SecureBoot: 6 0 0 0 1 - SourcePackage: shim-signed - Title: package shim-signed 1.32~16.04.1+0.9+1474479173.6c180c6-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 - UpgradeStatus: No upgrade log present (probably fresh install) + [Solution] + The solution is to move the end point into a socket-activated systemd unit, so that it is independent of the graphical frontend that started the transaction. The other advantage is that this offers us restart if the end point crashes. + + [Test case] + 1. Install opera deb using packagekit, ensure service is activated + 2. Install opera deb using aptdaemon, ensure service is activated + + Alternatively, you might use another deb that has debconf prompts. + + [Regression potential] + Systems that do not yet use systemd will fall back to the old method, so should not regress. + + Otherwise, if there are bugs, they'd affect the ability to show debconf + prompts, and behavior would revert to using the defaults. + + There might be some uncertainty if you restart your desktop while the + helper is running and it does not pick up the new X/Wayland display + until it restarts (it should fail to connect and restart). Given that + the helper times out, this should not be an issue in practice, as you'd + have to logout, login, and start a new install within 60 seconds. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1726068 Title: debconf socket closes if aptdaemon/PK client exits Status in apper package in Ubuntu: New Status in aptdaemon package in Ubuntu: Fix Released Status in packagekit package in Ubuntu: Fix Released Status in software-properties package in Ubuntu: Invalid Status in apper source package in Bionic: New Status in aptdaemon source package in Bionic: New Status in packagekit source package in Bionic: New Status in apper source package in Disco: New Status in aptdaemon source package in Disco: New Status in packagekit source package in Disco: In Progress Bug description: [Impact] Closing an application using PackageKit or aptdaemon to install packages kills the debconf endpoint (because it's a subprocess that's cleaned up), causing debconf to use defaults which might lead to wrong results, or even cause installations to fail. [Solution] The solution is to move the end point into a socket-activated systemd unit, so that it is independent of the graphical frontend that started the transaction. The o
Re: [Touch-packages] [Bug 1841659] Re: shaky, unreadable screens; orig. prog seems to be over written??
*** This bug is a duplicate of bug 1841318 *** https://bugs.launchpad.net/bugs/1841318 How can it be repaired? On Tue, Aug 27, 2019 at 8:45 PM Daniel van Vugt < daniel.van.v...@canonical.com> wrote: > *** This bug is a duplicate of bug 1841318 *** > https://bugs.launchpad.net/bugs/1841318 > > Thank you for taking the time to report this bug and helping to make > Ubuntu better. This particular bug has already been reported and is a > duplicate of bug 1841318, so it is being marked as such. Please look at > the other bug report to see if there is any missing information that you > can provide, or to see if there is a workaround for the bug. > Additionally, any further discussion regarding the bug should occur in > the other report. Feel free to continue to report any other bugs you may > find. > > > ** This bug has been marked a duplicate of bug 1841318 >Shaky display on GM965 [X3100] (Core 2 Duo L7500) > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1841659 > > Title: > shaky, unreadable screens; orig. prog seems to be over written?? > > Status in xorg package in Ubuntu: > New > > Bug description: > I apologize that I cannot explain clearly what happened to end up with > this problem. The machine works when I get into firefox, but I really > don't have much. My orig. sys. did not have a "dash"? but I had top > and bottom options. I just do not know what occurred, but I would like > to get rid of the shaky pages either with this or my original > settings. > > This problem occurred when I was trying to fix or change something. I > do not think this is a bug but it is probably my fault somehow. > > Is there a chance this can be fixed? If not I'll have to re-install > after I save all my documents and stuff. It is a dual boot win 7/ > Uuntu system. > > Is there a step by step guide to help me get this fixed? > > Is there any chance you all can help? > > Does my explanation of this problem make any sense? > > ProblemType: Bug > DistroRelease: Ubuntu 19.04 > Package: xorg 1:7.7+19ubuntu12 > ProcVersionSignature: Ubuntu 5.0.0-25.26-generic 5.0.18 > Uname: Linux 5.0.0-25-generic x86_64 > .tmp.unity_support_test.0: > > ApportVersion: 2.20.10-0ubuntu27.1 > Architecture: amd64 > CompizPlugins: No value set for > `/apps/compiz-1/general/screen0/options/active_plugins' > CompositorRunning: compiz > CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' > CompositorUnredirectFSW: true > CurrentDesktop: Unity:Unity7:ubuntu > Date: Tue Aug 27 14:04:31 2019 > DistUpgraded: Fresh install > DistroCodename: disco > DistroVariant: ubuntu > ExtraDebuggingInterest: Yes, if not too technical > GraphicsCard: >Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller > (primary) [8086:2a02] (rev 0c) (prog-if 00 [VGA controller]) > Subsystem: Lenovo GM965 [X3100] on ThinkPad T61/R61 [17aa:20b5] > Subsystem: Lenovo GM965 [X3100] on ThinkPad T61/R61 [17aa:20b5] > InstallationDate: Installed on 2015-09-10 (1447 days ago) > InstallationMedia: Ubuntu-MATE 15.04 "Vivid Vervet" - Release amd64 > (20150422.1) > MachineType: LENOVO 7763CU8 > PccardctlIdent: >Socket 0: > no product info available > PccardctlStatus: >Socket 0: > no card > ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-25-generic > root=UUID=125478c5-8ad6-45c1-b162-78e61507b85c ro quiet splash vt.handoff=1 > SourcePackage: xorg > Symptom: display > UpgradeStatus: No upgrade log present (probably fresh install) > dmi.bios.date: 10/12/2009 > dmi.bios.vendor: LENOVO > dmi.bios.version: 7SET38WW (1.24 ) > dmi.board.name: 7763CU8 > dmi.board.vendor: LENOVO > dmi.board.version: Not Available > dmi.chassis.asset.tag: 2075960 > dmi.chassis.type: 10 > dmi.chassis.vendor: LENOVO > dmi.chassis.version: Not Available > dmi.modalias: > dmi:bvnLENOVO:bvr7SET38WW(1.24):bd10/12/2009:svnLENOVO:pn7763CU8:pvrThinkPadX61Tablet:rvnLENOVO:rn7763CU8:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: > dmi.product.family: ThinkPad X61 Tablet > dmi.product.name: 7763CU8 > dmi.product.version: ThinkPad X61 Tablet > dmi.sys.vendor: LENOVO > version.compiz: compiz 1:0.9.14.0+19.04.20190223.1-0ubuntu1 > version.libdrm2: libdrm2 2.4.97-1ubuntu1 > version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~19.04.1 > version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~19.04.1 > version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu3 > version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-1 > version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1 > version.xserver-xorg-video-intel: xserver-xorg-video-intel > 2:2.99.917+git20180925-2 > version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+so
[Touch-packages] [Bug 1841785] [NEW] Update to 3.5.1 not this cycle
Public bug reported: Debian did the update but it includes a soname change ** Affects: nettle (Ubuntu) Importance: Wishlist Status: Triaged ** Tags: upgrade-software-version version-blocked-ff ** Changed in: nettle (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nettle in Ubuntu. https://bugs.launchpad.net/bugs/1841785 Title: Update to 3.5.1 not this cycle Status in nettle package in Ubuntu: Triaged Bug description: Debian did the update but it includes a soname change To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1841785/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841783] [NEW] Update to 1.2.0 not this cycle
Public bug reported: The source was split in rc2, Debian didn't follow the change and we are in sync (also not the sort of changes we want to deal with after feature freeze this cycle) ** Affects: speex (Ubuntu) Importance: Wishlist Status: Triaged ** Tags: upgrade-software-version version-blocked-ff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to speex in Ubuntu. https://bugs.launchpad.net/bugs/1841783 Title: Update to 1.2.0 not this cycle Status in speex package in Ubuntu: Triaged Bug description: The source was split in rc2, Debian didn't follow the change and we are in sync (also not the sort of changes we want to deal with after feature freeze this cycle) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/speex/+bug/1841783/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841378] Re: MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces
Fixed in 240 and up. ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released ** Also affects: systemd (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Disco) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1841378 Title: MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: New Status in systemd source package in Disco: Fix Released Bug description: I have machine with the following nspawn file: -- [Network] MACVLAN=laneth0 [Exec] PrivateUsers=false -- if I start it with systemctl start systemd-nspawn@name, all works as expected. If I start manually with systemd-nspawn -M name -b, I seem to correctly get a new network namespace (ip link output in container is correct), but ls /sys/class/net shows the host's interfaces. The difference turns out to be that starting with systemctl uses a default command line which includes --private-network; the MACVLAN= in the config file should imply this, but instead it seems I'm getting "half" a private network, with the namespace correctly set but /sys not. Having a quick poke around, I suspect https://github.com/systemd/systemd/commit/60f1ec13ed059e412c2a2ee4cc3093e2d520673c may have 'accidentally' fixed this - it moves if (arg_private_network) arg_mount_settings |= MOUNT_APPLY_APIVFS_NETNS; from parse_argv to verify_arguments which is called later. This bug causes netplan to fail as well as it rummages around in /sys/class/net. If the planets ever align appropriately, I will try to come up with a patch to 237 for bionic, but I don't recommend anyone holds their breath.. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.25 Uname: Linux 4.19.13-041913-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: XFCE Date: Sun Aug 25 17:54:50 2019 InstallationDate: Installed on 2018-03-22 (521 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180306.1) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841378/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841790] [NEW] [FFe] Please accept systemd 241 to Eoan
Public bug reported: Eoan currently has 240-6ubuntu13, but it is not used widely, Debian stable already has 241 and Debian testing moved to 242 last week. Version 241 is the safest choice for Eoan (from v240, v241 and v242) since it is widely tested, while going forward 20.04 will most likely ship a systemd release which is not released yet, probably v244+. Updating to v241 will allow us to carry fewer patches in Eoan and makes moving to the next release easier. The proposed package is tested in Bileto and all tests are passing: https://bileto.ubuntu.com/#/ticket/3789 The final version will be 241-7ubuntu1 and I'm tidying up the changelog, too. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1841790 Title: [FFe] Please accept systemd 241 to Eoan Status in systemd package in Ubuntu: New Bug description: Eoan currently has 240-6ubuntu13, but it is not used widely, Debian stable already has 241 and Debian testing moved to 242 last week. Version 241 is the safest choice for Eoan (from v240, v241 and v242) since it is widely tested, while going forward 20.04 will most likely ship a systemd release which is not released yet, probably v244+. Updating to v241 will allow us to carry fewer patches in Eoan and makes moving to the next release easier. The proposed package is tested in Bileto and all tests are passing: https://bileto.ubuntu.com/#/ticket/3789 The final version will be 241-7ubuntu1 and I'm tidying up the changelog, too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841790/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
I launched a bionic image on serverstack, updated the netplan.io to proposed, modified the network config to set ipv6-mtu to 6000 and rebooted. root@b-test-ipv6-mtu:~# apt-cache policy netplan.io netplan.io: Installed: 0.98-0ubuntu1~18.04.1 Candidate: 0.98-0ubuntu1~18.04.1 Version table: *** 0.98-0ubuntu1~18.04.1 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages 100 /var/lib/dpkg/status 0.97-0ubuntu1~18.04.1 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 0.40.1~18.04.4 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 0.36.1 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: fa:16:3e:4d:3c:6a set-name: ens3 ipv6-mtu: 6000 root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link [Match] MACAddress=fa:16:3e:4d:3c:6a [Link] Name=ens3 WakeOnLan=off root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network [Match] MACAddress=fa:16:3e:4d:3c:6a Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 IPv6MTUBytes=6000 [DHCP] RouteMetric=100 UseMTU=true ~# cat /sys/class/net/ens3/mtu 8958 ~# sysctl net.ipv6.conf.ens3.mtu net.ipv6.conf.ens3.mtu = 8958 -- 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/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop
[Touch-packages] [Bug 872483] Re: laser printer only prints first job correct
By the way, the relevant command for my case was: lpadmin -p -o usb-no-reattach-default=true -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/872483 Title: laser printer only prints first job correct Status in cups package in Ubuntu: Fix Released Status in cups source package in Oneiric: Won't Fix Status in cups source package in Precise: Fix Released Bug description: please also refer to this bug - this seems to be exactly my issue and does not seem to be solved. https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/855412 ProblemType: Bug DistroRelease: Ubuntu 11.10 - all updates as of today applied. I followed https://wiki.ubuntu.com/DebuggingPrintingProblems according to https://bugs.launchpad.net/ubuntu/+source/foomatic- db/+bug/855412/comments/20 I printed two copies of the same document, since this forces the error easily. The content under /var/spool/cups/d... look fine - see attached files. after cupsenable the first copy comes out fine - the second as random character - I stopped after some pages. The test is with Samsung ML-2250 Series (SPL II) - which worked fine under all previous versions of Ubuntu Samsung ML-2250 Foomatic/pxlmono (recommended) generates basically the same result. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/872483/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841798] [NEW] rsyslog debian build scripts ignoring rabbitmq module
Public bug reported: Hi, rsyslog comes with a rabbitmq output module included in the source, but although the debian build scripts do create lots of packages and modules, they do not create the rabbitmq module. See https://www.rsyslog.com/doc/v8-stable/configuration/modules/omrabbitmq.html ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: rsyslog 8.32.0-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-55.60-generic 4.15.18 Uname: Linux 4.15.0-55-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: LXDE Date: Wed Aug 28 17:03:01 2019 InstallationDate: Installed on 2018-04-30 (485 days ago) InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1841798 Title: rsyslog debian build scripts ignoring rabbitmq module Status in rsyslog package in Ubuntu: New Bug description: Hi, rsyslog comes with a rabbitmq output module included in the source, but although the debian build scripts do create lots of packages and modules, they do not create the rabbitmq module. See https://www.rsyslog.com/doc/v8-stable/configuration/modules/omrabbitmq.html ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: rsyslog 8.32.0-1ubuntu4 ProcVersionSignature: Ubuntu 4.15.0-55.60-generic 4.15.18 Uname: Linux 4.15.0-55-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CurrentDesktop: LXDE Date: Wed Aug 28 17:03:01 2019 InstallationDate: Installed on 2018-04-30 (485 days ago) InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1841798/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1817537] Re: libsoup should support ntlmv2
Quick question. Will this be added to the regular updates? I'm still using proposed for this update in bionic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsoup2.4 in Ubuntu. https://bugs.launchpad.net/bugs/1817537 Title: libsoup should support ntlmv2 Status in libsoup2.4 package in Ubuntu: Fix Released Status in libsoup2.4 source package in Bionic: Fix Committed Bug description: * Impact Without NTLMv2 support evolution-ews can't connect to some exchange servers * Test case Try connecting from evolution-ews to an exchange server which enforces NTLMV2 * Regression potential The change adds extra cases in the ntlm handling support, it should impact existing feature but check out for any potential regression in libsoup user (check at least evolution and epiphany-browser). Note that the patch include additional code tests --- Our Exchange admins recently made NTLMv2 obligatory. Since then interaction with Exchange through Evolution isn't possible anymore. In newer versions of libsoup that has been implemented, see https://gitlab.gnome.org/GNOME/evolution-ews/issues/38 Could that be backported to Ubuntu 18.04? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libsoup2.4-1 2.62.1-1ubuntu0.1 ProcVersionSignature: Ubuntu 4.15.0-45.48-generic 4.15.18 Uname: Linux 4.15.0-45-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: XFCE Date: Mon Feb 25 12:10:26 2019 SourcePackage: libsoup2.4 UpgradeStatus: Upgraded to bionic on 2018-09-27 (150 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsoup2.4/+bug/1817537/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Followup on my comments, are any changes required in networkd to support this in bionic? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
I tested with your single-file approach and that also fails. Note that bionic now has systemd 237, so maybe something is missing (or regressed) ? $ apt-cache policy systemd systemd: Installed: 237-3ubuntu10.26 Candidate: 237-3ubuntu10.26 Version table: *** 237-3ubuntu10.26 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10.25 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 237-3ubuntu10.19 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 237-3ubuntu10 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- 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/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/16719
Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
I thought custom ipv6 MTU may not be lower than ipv4 one. Hence request for 6000 ipv6 is not valid, when link is on 8958. Can you try 9000? On Wed, 28 Aug 2019, 15:41 Ryan Harper, <1671...@bugs.launchpad.net> wrote: > I launched a bionic image on serverstack, updated the netplan.io to > proposed, modified the network config to set ipv6-mtu to 6000 and > rebooted. > > root@b-test-ipv6-mtu:~# apt-cache policy netplan.io > netplan.io: > Installed: 0.98-0ubuntu1~18.04.1 > Candidate: 0.98-0ubuntu1~18.04.1 > Version table: > *** 0.98-0ubuntu1~18.04.1 500 > 500 http://nova.clouds.archive.ubuntu.com/ubuntu > bionic-proposed/main amd64 Packages > 100 /var/lib/dpkg/status > 0.97-0ubuntu1~18.04.1 500 > 500 http://nova.clouds.archive.ubuntu.com/ubuntu > bionic-updates/main amd64 Packages > 0.40.1~18.04.4 500 > 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 > Packages > 0.36.1 500 > 500 http://nova.clouds.archive.ubuntu.com/ubuntu bionic/main > amd64 Packages > > root@b-test-ipv6-mtu:~# cat /etc/netplan/50-cloud-init.yaml > network: > version: 2 > ethernets: > ens3: > dhcp4: true > match: > macaddress: fa:16:3e:4d:3c:6a > set-name: ens3 > ipv6-mtu: 6000 > > root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.link > [Match] > MACAddress=fa:16:3e:4d:3c:6a > > [Link] > Name=ens3 > WakeOnLan=off > root@b-test-ipv6-mtu:/run/systemd/network# cat 10-netplan-ens3.network > [Match] > MACAddress=fa:16:3e:4d:3c:6a > Name=ens3 > > [Network] > DHCP=ipv4 > LinkLocalAddressing=ipv6 > IPv6MTUBytes=6000 > > [DHCP] > RouteMetric=100 > UseMTU=true > > > ~# cat /sys/class/net/ens3/mtu > 8958 > ~# sysctl net.ipv6.conf.ens3.mtu > net.ipv6.conf.ens3.mtu = 8958 > > -- > You received this bug notification because you are subscribed to systemd > in Ubuntu. > Matching subscriptions: systemd > https://bugs.launchpad.net/bugs/1671951 > > Title: > networkd should allow configuring IPV6 MTU > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions > -- 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/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which ar
[Touch-packages] [Bug 1841790] Re: [FFe] Please accept systemd 241 to Eoan
I have uploaded the version for eoan to ppa:rbalint/scratch3 Changes from the bileto-tested version: http://paste.ubuntu.com/p/QJFGPf4HB2/ -- 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/1841790 Title: [FFe] Please accept systemd 241 to Eoan Status in systemd package in Ubuntu: New Bug description: Eoan currently has 240-6ubuntu13, but it is not used widely, Debian stable already has 241 and Debian testing moved to 242 last week. Version 241 is the safest choice for Eoan (from v240, v241 and v242) since it is widely tested, while going forward 20.04 will most likely ship a systemd release which is not released yet, probably v244+. Updating to v241 will allow us to carry fewer patches in Eoan and makes moving to the next release easier. The proposed package is tested in Bileto and all tests are passing: https://bileto.ubuntu.com/#/ticket/3789 The final version will be 241-7ubuntu1 and I'm tidying up the changelog, too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841790/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
err, on Eoan, I used ipv6-mtu 6000. -- 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/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU
Great! Thank you, Dan, that is a fix for me. My config: Dell Studio 1558 Ubuntu MATE 18.04.3 LTS, Linux 5.0.0-25-generic x86_64 lsusb (partial): Bus 001 Device 007: ID 413c:8160 Dell Computer Corp. Wireless 365 Bluetooth Bus 001 Device 006: ID 413c:8162 Dell Computer Corp. Integrated Touchpad [Synaptics] Bus 001 Device 005: ID 413c:8161 Dell Computer Corp. Integrated Keyboard Bus 001 Device 003: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) -- 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/1759836 Title: systemd-udevd consumes 100% of CPU Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez package in Debian: Unknown Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
See comment #20; ipv6 mtu is 1280 -> DEVICE_MTU. I'm testing something in the middle now. On Eoan with: network: version: 2 ethernets: ens3: addresses: [10.5.0.16/16] gateway4: 10.5.0.1 dhcp4: false match: macaddress: fa:16:3e:c9:1e:fb mtu: 8958 ipv6-mtu: 8960 set-name: ens3 nameservers: addresses: [10.5.0.2] search: [project.serverstack] It works. Now on bionic-proposed, it does not. Aug 28 16:59:56.659125 b-test-ipv6-mtu systemd-networkd[1149]: /run/systemd/network/10-netplan-ens3.network:11: Unknown lvalue 'IPv6MTUBytes' in section 'Network' So, looks like bionic systemd is missing something. -- 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/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+so
[Touch-packages] [Bug 1841640] Re: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed')
** Description changed: - No se bien lo que acontecio. + No se bien lo que acontecio. ("I don't know well what happened") ProblemType: Package DistroRelease: Ubuntu 16.04 Package: rsync 3.1.1-3ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131 Uname: Linux 4.4.0-128-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 AptOrdering: - oem-workaround-force-install-intel-red: Remove - oem-workaround-force-install-qualcomm-red: Remove - rsync: Configure - NULL: ConfigurePending + oem-workaround-force-install-intel-red: Remove + oem-workaround-force-install-qualcomm-red: Remove + rsync: Configure + NULL: ConfigurePending Architecture: amd64 Date: Mon Aug 26 06:37:59 2019 DistributionChannelDescriptor: - # This is a distribution channel descriptor - # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor - canonical-oem-somerville-xenial-amd64-20160624-2 + # This is a distribution channel descriptor + # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor + canonical-oem-somerville-xenial-amd64-20160624-2 DpkgTerminalLog: - A remover oem-workaround-force-install-intel-red (1.4) ... - A remover oem-workaround-force-install-qualcomm-red (3.2) ... - dpkg: erro ao processar o pacote rsync (--configure): - pacote rsync não está pronto para configuração - não posso configurar (estado atual 'half-installed') + A remover oem-workaround-force-install-intel-red (1.4) ... + A remover oem-workaround-force-install-qualcomm-red (3.2) ... + dpkg: erro ao processar o pacote rsync (--configure): + pacote rsync não está pronto para configuração + não posso configurar (estado atual 'half-installed') ErrorMessage: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') InstallationDate: Installed on 2019-08-01 (25 days ago) InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 20160624-10:47 RelatedPackageVersions: - dpkg 1.18.4ubuntu1 - apt 1.2.29ubuntu0.1 + dpkg 1.18.4ubuntu1 + apt 1.2.29ubuntu0.1 SourcePackage: rsync Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: No se bien lo que acontecio. ("I don't know well what happened") ProblemType: Package DistroRelease: Ubuntu 16.04 Package: rsync 3.1.1-3ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131 Uname: Linux 4.4.0-128-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 AptOrdering: oem-workaround-force-install-intel-red: Remove oem-workaround-force-install-qualcomm-red: Remove rsync: Configure NULL: ConfigurePending Architecture: amd64 Date: Mon Aug 26 06:37:59 2019 DistributionChannelDescriptor: # This is a distribution channel descriptor # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-xenial-amd64-20160624-2 DpkgTerminalLog: A remover oem-workaround-force-install-intel-red (1.4) ... A remover oem-workaround-force-install-qualcomm-red (3.2) ... dpkg: erro ao processar o pacote rsync (--configure): pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') + (dpkg: Error processing rsync package (--configure): + rsync package not ready for configuration + i can't configure) ErrorMessage: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') InstallationDate: Installed on 2019-08-01 (25 days ago) InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 20160624-10:47 RelatedPackageVersions: dpkg 1.18.4ubuntu1 apt 1.2.29ubuntu0.1 SourcePackage: rsync Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: No se bien lo que acontecio. ("I don't know well what happened") ProblemType: Package DistroRelease: Ubuntu 16.04 Package: rsync 3.1.1-3ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131 Uname: Linux 4.4.0-128-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 AptOrdering: oem-workaround-force-install-intel-red: Remove oem-workaround-force-install-qualcomm-red: Remove rsync: Configure NULL: ConfigurePending Architecture: amd64 Date: Mon Aug 26 06:37:59 2019 DistributionChannelDescriptor: # This is a distribution channel descriptor # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-xenial-amd64-20160624-2 DpkgTerminalLog: A remover oem-workaround-force-install-intel-red (1.4) ... A remover oem-workaround-force-
[Touch-packages] [Bug 1841654] Re: Replace mawk with gawk in main
** Tags added: server-next -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mawk in Ubuntu. https://bugs.launchpad.net/bugs/1841654 Title: Replace mawk with gawk in main Status in mawk package in Ubuntu: New Bug description: For POSIX compatibility reasons Ubuntu ships with mawk ("Mike's awk" = mawk) in main. There is an awk-symlink to mawk, thus mawk is the official awk implementation in Ubuntu. == Reasons against keeping mawk == *The mawk package is synced from debian and it is heavily undermaintained: Debian (and thus Ubuntu) still ships version 1.3.3-17, the same version at least since oldoldstable: https://packages.debian.org/search?searchon=names&keywords=mawk *part-time maintainer Thomas E. Dickey (https://invisible- island.net/mawk/) called officially out that Debian "neglected" mawk in 2014 ("As noted, mawk has been neglected by some packagers (see for example this http://bugs.debian.org/cgi- bin/pkgreport.cgi?package=mawk)". And Debian (and Ubuntu) still ship the same version five years later *Most other distributions ship mawk at least in its last official incarnation 1.3.4 in their repositories. Dickey lists AIX, Fedora, FinkPorts (Mac OS X), FreeBSD port, Gentoo, HPUX, MacPorts (Mac OS X), NetBSD pkgsrc/lang, OpenCSW (Solaris). But even that version is from 2014 and doesn't seem to be developed anymore: https://github.com/ThomasDickey/mawk-20140914/commits/master *A planned rewrite mawk2 was planned by original author Mike Brennan in 2016 but obviously came to nothing: https://github.com/ploxiln/mawk-2/commits/master *Thus mawk sits in Ubuntu main in a version published upstream in 2009 and celebrates its 10th anniversary of negligence. In a state that Debian was called out for 5 years ago. *This year it is 10 years unmaintained and largely untouched. At the end of the next LTS-support-cycle we can celebrate 15 years of not supporting it. *awk is included in Linux for POSIX standard compliance. Mawk is known to be fast and small but it is the implementation that is farthest from being POSIX compliant, missing things like named character classes like [[:space:]] within its EREs. == Reasons for gawk as a replacement == *It is the official GNU awk implementation and known to work well with the rest of the GNU userland. *It is actively maintained with the last version 5.01 shipping in June, 2019 (even if Ubuntu will obviously still ship 4.2 for Eoan). *It is mostly compliant with the POSIX standard. *Most other distributions ship it as the standard POSIX implementation, with a awk symlink. So it had security reviews already by Red Hat and others. == Possible problems with switching to gawk in time for Ubuntu 20.4 == - It might need to be MIRed by the Ubuntu security team and a review might take some time. So I filed this bug early with Eoan not yet out of the door. - It is much larger than mawk, the Ubuntu package is 1600 kB in size, while mawk is only about 190KB. Thus some might want to split out some basic functionality to save size. Like what is vim-tiny to vim. To start gawk in --traditional or --posix mode and disable the extensions at compile time might be a good start to reduce the size. See: https://www.gnu.org/software/gawk/manual/html_node/Additional- Configuration-Options.html#Additional-Configuration-Options = ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: mawk 1.3.3-17ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Aug 27 20:12:11 2019 Dependencies: gcc-9-base 9.1.0-2ubuntu2~19.04 libc6 2.29-0ubuntu2 libgcc1 1:9.1.0-2ubuntu2~19.04 libidn2-0 2.0.5-1 libunistring2 0.9.10-1ubuntu2 InstallationDate: Installed on 2018-02-23 (550 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) ProcEnviron: LANGUAGE=de_AT:de PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_AT.UTF-8 SHELL=/bin/bash SourcePackage: mawk UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/1841654/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU
> that is a fix for me excellent, thanks. The patch there is the same idea as from comment 70, to only process the hid2hci rules on 'add' action events. It's the same as was proposed upstream: https://lore.kernel.org/patchwork/patch/902126/#1138115 The only thing needed now before merging this fix is for upstream to accept the patch, I sent an email to poke the mailing list. https://lore.kernel.org/linux- bluetooth/CAOZ2QJOZStRYa=5fyod_AEJcJQw90_yX40dPYY3Dhvfso1e=r...@mail.gmail.com/ -- 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/1759836 Title: systemd-udevd consumes 100% of CPU Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez package in Debian: Unknown Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841640] Re: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed')
Hi Leonardo, It sounds like your upgrade may have been interrupted for some reason, and rsync didn't finish getting configured. Forcibly removing and reinstalling rsync might help. There is some advice about fixing half- installed packages here: https://askubuntu.com/questions/490671/fix-half-installed-package If this doesn't work, or if you determine the reason why it got into this state, please let us know. ** Changed in: rsync (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1841640 Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') Status in rsync package in Ubuntu: Incomplete Bug description: No se bien lo que acontecio. ("I don't know well what happened") ProblemType: Package DistroRelease: Ubuntu 16.04 Package: rsync 3.1.1-3ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131 Uname: Linux 4.4.0-128-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 AptOrdering: oem-workaround-force-install-intel-red: Remove oem-workaround-force-install-qualcomm-red: Remove rsync: Configure NULL: ConfigurePending Architecture: amd64 Date: Mon Aug 26 06:37:59 2019 DistributionChannelDescriptor: # This is a distribution channel descriptor # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-xenial-amd64-20160624-2 DpkgTerminalLog: A remover oem-workaround-force-install-intel-red (1.4) ... A remover oem-workaround-force-install-qualcomm-red (3.2) ... dpkg: erro ao processar o pacote rsync (--configure): pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') (dpkg: Error processing rsync package (--configure): rsync package not ready for configuration i can't configure) ErrorMessage: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') (ErrorMessage: rsync package not ready for configuration can't configure) InstallationDate: Installed on 2019-08-01 (25 days ago) InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 20160624-10:47 RelatedPackageVersions: dpkg 1.18.4ubuntu1 apt 1.2.29ubuntu0.1 SourcePackage: rsync Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed') UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1841640/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841654] Re: Replace mawk with gawk in main
** Tags removed: server-next -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mawk in Ubuntu. https://bugs.launchpad.net/bugs/1841654 Title: Replace mawk with gawk in main Status in mawk package in Ubuntu: New Bug description: For POSIX compatibility reasons Ubuntu ships with mawk ("Mike's awk" = mawk) in main. There is an awk-symlink to mawk, thus mawk is the official awk implementation in Ubuntu. == Reasons against keeping mawk == *The mawk package is synced from debian and it is heavily undermaintained: Debian (and thus Ubuntu) still ships version 1.3.3-17, the same version at least since oldoldstable: https://packages.debian.org/search?searchon=names&keywords=mawk *part-time maintainer Thomas E. Dickey (https://invisible- island.net/mawk/) called officially out that Debian "neglected" mawk in 2014 ("As noted, mawk has been neglected by some packagers (see for example this http://bugs.debian.org/cgi- bin/pkgreport.cgi?package=mawk)". And Debian (and Ubuntu) still ship the same version five years later *Most other distributions ship mawk at least in its last official incarnation 1.3.4 in their repositories. Dickey lists AIX, Fedora, FinkPorts (Mac OS X), FreeBSD port, Gentoo, HPUX, MacPorts (Mac OS X), NetBSD pkgsrc/lang, OpenCSW (Solaris). But even that version is from 2014 and doesn't seem to be developed anymore: https://github.com/ThomasDickey/mawk-20140914/commits/master *A planned rewrite mawk2 was planned by original author Mike Brennan in 2016 but obviously came to nothing: https://github.com/ploxiln/mawk-2/commits/master *Thus mawk sits in Ubuntu main in a version published upstream in 2009 and celebrates its 10th anniversary of negligence. In a state that Debian was called out for 5 years ago. *This year it is 10 years unmaintained and largely untouched. At the end of the next LTS-support-cycle we can celebrate 15 years of not supporting it. *awk is included in Linux for POSIX standard compliance. Mawk is known to be fast and small but it is the implementation that is farthest from being POSIX compliant, missing things like named character classes like [[:space:]] within its EREs. == Reasons for gawk as a replacement == *It is the official GNU awk implementation and known to work well with the rest of the GNU userland. *It is actively maintained with the last version 5.01 shipping in June, 2019 (even if Ubuntu will obviously still ship 4.2 for Eoan). *It is mostly compliant with the POSIX standard. *Most other distributions ship it as the standard POSIX implementation, with a awk symlink. So it had security reviews already by Red Hat and others. == Possible problems with switching to gawk in time for Ubuntu 20.4 == - It might need to be MIRed by the Ubuntu security team and a review might take some time. So I filed this bug early with Eoan not yet out of the door. - It is much larger than mawk, the Ubuntu package is 1600 kB in size, while mawk is only about 190KB. Thus some might want to split out some basic functionality to save size. Like what is vim-tiny to vim. To start gawk in --traditional or --posix mode and disable the extensions at compile time might be a good start to reduce the size. See: https://www.gnu.org/software/gawk/manual/html_node/Additional- Configuration-Options.html#Additional-Configuration-Options = ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: mawk 1.3.3-17ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Aug 27 20:12:11 2019 Dependencies: gcc-9-base 9.1.0-2ubuntu2~19.04 libc6 2.29-0ubuntu2 libgcc1 1:9.1.0-2ubuntu2~19.04 libidn2-0 2.0.5-1 libunistring2 0.9.10-1ubuntu2 InstallationDate: Installed on 2018-02-23 (550 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) ProcEnviron: LANGUAGE=de_AT:de PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_AT.UTF-8 SHELL=/bin/bash SourcePackage: mawk UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/1841654/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841790] Re: [FFe] Please accept systemd 241 to Eoan
Autopkgtest passing on s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-rbalint-scratch3/eoan/s390x/s/systemd/20190828_180654_f1072@/log.gz Autopkgtest failing once on amd64 which is strange, since it passed in Bileto and there were no related changes: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-rbalint-scratch3/eoan/amd64/s/systemd/20190828_185123_f1072@/log.gz I reran it and it should just be flaky or unrelated to systemd. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1841790 Title: [FFe] Please accept systemd 241 to Eoan Status in systemd package in Ubuntu: New Bug description: Eoan currently has 240-6ubuntu13, but it is not used widely, Debian stable already has 241 and Debian testing moved to 242 last week. Version 241 is the safest choice for Eoan (from v240, v241 and v242) since it is widely tested, while going forward 20.04 will most likely ship a systemd release which is not released yet, probably v244+. Updating to v241 will allow us to carry fewer patches in Eoan and makes moving to the next release easier. The proposed package is tested in Bileto and all tests are passing: https://bileto.ubuntu.com/#/ticket/3789 The final version will be 241-7ubuntu1 and I'm tidying up the changelog, too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841790/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink
** Changed in: gdb (Ubuntu) Status: Expired => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1818918 Title: gdb doesn't search in debug-file-directory for .gnu_debugaltlink Status in gdb package in Ubuntu: New Bug description: As far as I can tell gdb version 8.2.90 isn't searching the debug- file-directory, which I set, for the '.gnu_debugaltlink' which is in the debug symbols. Here's the error I'm seeing: Type "apropos word" to search for commands related to "word". Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox//usr/bin/gnome-calculator... Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug... could not find '.gnu_debugaltlink' file for /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug) Here's part of an strace of what's going on behind the scenes: lstat("/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug", {st_mode=S_IFREG|0644, st_size=839744, ...}) = 0 openat(AT_FDCWD, "/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) This is the only time "/usr/lib/debug" is searched, generally "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report- sandbox/usr/lib/debug/" is used. I'll attach the full strace though. For completeness here's the gdb command I'm using: Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64 /report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb' --ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute- prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox' --ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64 -linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox- dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report- sandbox//usr/bin/gnome-calculator"' --ex 'core-file /tmp/apport_core_1b6dn6np' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1818918/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink
I recently started seeing issues with some other applications too e.g.: Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox//usr/lib/gdm3/gdm-session-worker... Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox/usr/lib/debug/.build-id/d8/4d9e76a9073d1195af86ff6620382437e41977.debug... could not find '.gnu_debugaltlink' file for /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox/usr/lib/debug/.build-id/d8/4d9e76a9073d1195af86ff6620382437e41977.debug (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox/usr/lib/debug/.build-id/d8/4d9e76a9073d1195af86ff6620382437e41977.debug) ... Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox//usr/bin/gnome-shell... Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox/usr/lib/debug/.build-id/2c/28a1bf7a132275c4fd2f9f44011c043d4424e5.debug... could not find '.gnu_debugaltlink' file for /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox/usr/lib/debug/.build-id/2c/28a1bf7a132275c4fd2f9f44011c043d4424e5.debug (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64/report-sandbox/usr/lib/debug/.build-id/2c/28a1bf7a132275c4fd2f9f44011c043d4424e5.debug) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1818918 Title: gdb doesn't search in debug-file-directory for .gnu_debugaltlink Status in gdb package in Ubuntu: New Bug description: As far as I can tell gdb version 8.2.90 isn't searching the debug- file-directory, which I set, for the '.gnu_debugaltlink' which is in the debug symbols. Here's the error I'm seeing: Type "apropos word" to search for commands related to "word". Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox//usr/bin/gnome-calculator... Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug... could not find '.gnu_debugaltlink' file for /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug) Here's part of an strace of what's going on behind the scenes: lstat("/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug", {st_mode=S_IFREG|0644, st_size=839744, ...}) = 0 openat(AT_FDCWD, "/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) This is the only time "/usr/lib/debug" is searched, generally "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report- sandbox/usr/lib/debug/" is used. I'll attach the full strace though. For completeness here's the gdb command I'm using: Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64 /report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb' --ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute- prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox' --ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64 -linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox- dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report- sandbox//usr/bin/gnome-calculator"' --ex 'core-file /tmp/apport_core_1b6dn6np' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1818918/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837700] Re: Dell system takes a long time to connect network with external dock
** Tags removed: verification-needed ** Tags added: verification-done -- 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/1837700 Title: Dell system takes a long time to connect network with external dock Status in HWE Next: New Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: update for SRU process: [Impact] 1. On system featured mac passthrough, e.g., Dell/Lenovo laptop, or system occasionally install two USB ethernet with same MAC address, the system will suffer 90 seconds for network interface renaming mechanism before the last USB ethernet interface to activate. [Test Case] 1. Install ubuntu on Dell laptop. 2. Connect the Dell laptop with two Realtek 8153 USB ethernet dongle. Users can observe the last one will take 90 seconds for renaming to rename0. 3. Users can also find that the two USB ethernet have the same MAC address. [Regression Potential] To resolve the issue, drop a debian patch from systemd package. The debian patch is to revert an upstream commit to support 75-persistent-net-generator.rules udev rule. Since the udev rule is deprecated, the regression potential should be relatively low. --- Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/27/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0Y7FK3 dmi.board.vendor: Dell Inc. dmi.board.version: X03 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7424 Rugged Extreme dmi.sys.vendor: Dell Inc. [1]: https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c [3]: https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules [4]:
[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink
looking up the .gnu_debugaltlink in a normal debug session works perfectly fine. Please can you show this behavior without any sandbox, or try to diagnose why it doesn't work in this sandbox? I am not familiar with this sandbox environment. ** Changed in: gdb (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1818918 Title: gdb doesn't search in debug-file-directory for .gnu_debugaltlink Status in gdb package in Ubuntu: Incomplete Bug description: As far as I can tell gdb version 8.2.90 isn't searching the debug- file-directory, which I set, for the '.gnu_debugaltlink' which is in the debug symbols. Here's the error I'm seeing: Type "apropos word" to search for commands related to "word". Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox//usr/bin/gnome-calculator... Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug... could not find '.gnu_debugaltlink' file for /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug) Here's part of an strace of what's going on behind the scenes: lstat("/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug", {st_mode=S_IFREG|0644, st_size=839744, ...}) = 0 openat(AT_FDCWD, "/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) This is the only time "/usr/lib/debug" is searched, generally "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report- sandbox/usr/lib/debug/" is used. I'll attach the full strace though. For completeness here's the gdb command I'm using: Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64 /report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb' --ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute- prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox' --ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64 -linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox- dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report- sandbox//usr/bin/gnome-calculator"' --ex 'core-file /tmp/apport_core_1b6dn6np' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1818918/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp