[Group.of.nepali.translators] [Bug 1226962] Re: Keyboard shortcuts (hotkeys) not functional in some cases in non-latin keyboard layouts
** No longer affects: openjdk-7 (Ubuntu) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1226962 Title: Keyboard shortcuts (hotkeys) not functional in some cases in non-latin keyboard layouts Status in aptana-studio-installer: New Status in Default settings and artwork for Baltix OS: New Status in LibreOffice: Fix Released Status in ibus: New Status in Indicator keyboard: Fix Released Status in Inkscape: Fix Released Status in Intellij Idea: New Status in monodevelop: New Status in Mutter: Fix Released Status in okular: New Status in OpenOffice: New Status in sigram: New Status in Unity: Fix Released Status in Visual Studio Code: New Status in gnome-settings-daemon package in Ubuntu: Triaged Status in gnome-terminal package in Ubuntu: Triaged Status in kdevelop package in Ubuntu: Confirmed Status in mc package in Ubuntu: Confirmed Status in terminator package in Ubuntu: Confirmed Status in unity package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: In Progress Status in gnome-settings-daemon source package in Xenial: Triaged Status in gnome-terminal source package in Xenial: Triaged Status in kdevelop source package in Xenial: Confirmed Status in mc source package in Xenial: Confirmed Status in terminator source package in Xenial: Confirmed Status in unity source package in Xenial: Fix Released Status in unity-settings-daemon source package in Xenial: In Progress Status in gnome-shell package in Fedora: Won't Fix Status in openoffice package in Fedora: Won't Fix Bug description: Keyboard shortcuts are key combinations like Alt+F (usually opens the File menu) and Ctrl+O (usually opens the File→Open... dialog box). There is an issue with non-latin keyboard layouts that the keys under F or O (for Alt+F and Ctrl+O respectively) would correspond to some other character. What should happen then? There is some smart functionality (at least in the GTK+ library) that when we press a shortcut, it will try to make Alt+F or Ctrl+O work, even if the active keyboard layout is not English. For this smart functionality to work, it requires us to have as first keyboard layout the English (en) layout. Then, GTK+ will be able to check whether the shortcut makes sense for English, and if so, will run it. All that even if the active layout is Greek or Russian or something else. This report has over 300 comments and these comments include all sort of corner cases that indeed shortcuts do not work. In general, shortcuts work, but in specific cases there are issues that need to be fixed. What we need to do, is collect those corner cases and create new separate reports. Here are the corner cases: 1. In Dash (in Unity 7), shortcuts like Super+S/W work (for example, Greek, Russian), but they do not work for Super+A/F/M/C/V. Report: 2. Java GUI applications on Linux do not support shortcuts in non-latin languages. This is an issue with Java and should be reported there. Java GUI apps are not included in any of the Ubuntu ISOs. Report: 3. Shortcuts that use Ctrl on LibreOffice work for several languages (like Greek, Russian), but has been reported not to work on Hebrew. This should be a separate bug report specific to Hebrew and other languages affected in the same way. Report: To manage notifications about this bug go to: https://bugs.launchpad.net/aptana-studio-installer/+bug/1226962/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1226962] Re: Keyboard shortcuts (hotkeys) not functional in some cases in non-latin keyboard layouts
** No longer affects: openjdk-7 (Ubuntu Xenial) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1226962 Title: Keyboard shortcuts (hotkeys) not functional in some cases in non-latin keyboard layouts Status in aptana-studio-installer: New Status in Default settings and artwork for Baltix OS: New Status in LibreOffice: Fix Released Status in ibus: New Status in Indicator keyboard: Fix Released Status in Inkscape: Fix Released Status in Intellij Idea: New Status in monodevelop: New Status in Mutter: Fix Released Status in okular: New Status in OpenOffice: New Status in sigram: New Status in Unity: Fix Released Status in Visual Studio Code: New Status in gnome-settings-daemon package in Ubuntu: Triaged Status in gnome-terminal package in Ubuntu: Triaged Status in kdevelop package in Ubuntu: Confirmed Status in mc package in Ubuntu: Confirmed Status in openjdk-7 package in Ubuntu: Incomplete Status in terminator package in Ubuntu: Confirmed Status in unity package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: In Progress Status in gnome-settings-daemon source package in Xenial: Triaged Status in gnome-terminal source package in Xenial: Triaged Status in kdevelop source package in Xenial: Confirmed Status in mc source package in Xenial: Confirmed Status in terminator source package in Xenial: Confirmed Status in unity source package in Xenial: Fix Released Status in unity-settings-daemon source package in Xenial: In Progress Status in gnome-shell package in Fedora: Won't Fix Status in openoffice package in Fedora: Won't Fix Bug description: Keyboard shortcuts are key combinations like Alt+F (usually opens the File menu) and Ctrl+O (usually opens the File→Open... dialog box). There is an issue with non-latin keyboard layouts that the keys under F or O (for Alt+F and Ctrl+O respectively) would correspond to some other character. What should happen then? There is some smart functionality (at least in the GTK+ library) that when we press a shortcut, it will try to make Alt+F or Ctrl+O work, even if the active keyboard layout is not English. For this smart functionality to work, it requires us to have as first keyboard layout the English (en) layout. Then, GTK+ will be able to check whether the shortcut makes sense for English, and if so, will run it. All that even if the active layout is Greek or Russian or something else. This report has over 300 comments and these comments include all sort of corner cases that indeed shortcuts do not work. In general, shortcuts work, but in specific cases there are issues that need to be fixed. What we need to do, is collect those corner cases and create new separate reports. Here are the corner cases: 1. In Dash (in Unity 7), shortcuts like Super+S/W work (for example, Greek, Russian), but they do not work for Super+A/F/M/C/V. Report: 2. Java GUI applications on Linux do not support shortcuts in non-latin languages. This is an issue with Java and should be reported there. Java GUI apps are not included in any of the Ubuntu ISOs. Report: 3. Shortcuts that use Ctrl on LibreOffice work for several languages (like Greek, Russian), but has been reported not to work on Hebrew. This should be a separate bug report specific to Hebrew and other languages affected in the same way. Report: To manage notifications about this bug go to: https://bugs.launchpad.net/aptana-studio-installer/+bug/1226962/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1777827] Re: remove log from Vagrantfile
** Also affects: livecd-rootfs (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1777827 Title: remove log from Vagrantfile Status in cloud-images: Confirmed Status in livecd-rootfs package in Ubuntu: New Status in livecd-rootfs source package in Xenial: New Status in livecd-rootfs source package in Bionic: New Status in livecd-rootfs source package in Cosmic: New Bug description: Please remove the log file configuration from Vagrantfile. I'm not aware of any other vagrant box that does this. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1777827/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1801134] Re: /etc/resolv.conf broken in Xenial minimal
** Also affects: livecd-rootfs (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: livecd-rootfs (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1801134 Title: /etc/resolv.conf broken in Xenial minimal Status in livecd-rootfs package in Ubuntu: Fix Released Status in livecd-rootfs source package in Xenial: New Bug description: DNS was broken in Xenial minimal images under some circumstances due to a 0-byte /etc/resolv.conf file. [Test Case] Build Xenial Minimal Image Check /etc/resolv.conf and confirm it is a symlink and not a 0-byte file. [Regression Potential] Regression would manifest in inability to do name resolution completely. Although a 0-byte /etc/resolv.conf does currently prevent name resolution, it can be repaired by running `# dhclient`. An example of a regression would potentially be that the above workaround is no longer effective. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1801134/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1800792] Re: Update to openjdk-8 8u181-b13-1ubuntu0.18.04.1 and openjdk-lts 10.0.2+13-1ubuntu0.18.04.3 breaks Maven builds
** Summary changed: - Update to 8u181-b13-1ubuntu0.18.04.1 breaks Maven builds + Update to openjdk-8 8u181-b13-1ubuntu0.18.04.1 and openjdk-lts 10.0.2+13-1ubuntu0.18.04.3 breaks Maven builds ** Description changed: Today both the OpenJDK 8 and 11 packages were updated. In the case of - OpenJDK 8: + OpenJDK 8 (openjdk-8): openjdk-8-jdk: 8u181-b13-0ubuntu0.18.04.1 → 8u181-b13-1ubuntu0.18.04.1 - OpenJDK 11 (10 really): + OpenJDK 10 (openjdk-lts in Bionic): openjdk-11-jdk: 10.0.2+13-1ubuntu0.18.04.2 → 10.0.2+13-1ubuntu0.18.04.3 After this update all my local Maven builds fail with a crashed VM. From the console output it looks like one of the prerequisites of JaCoCo (Java code coverage tool) is no longer met, but I haven't been able to figure out what the root cause is. This problem occurs with both OpenJDK 8 and 10. Reproduction: This is one of our projects: https://github.com/LableOrg/java-nicerxvi Clone the project, and call `mvn clean install`. For me it now fails to build (output attached). When I downgrade to 8u162-b12-1 everything works again. ** No longer affects: openjdk-11 (Ubuntu) ** Also affects: openjdk-8 (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: openjdk-lts (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: openjdk-8 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: openjdk-lts (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: openjdk-8 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: openjdk-lts (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: openjdk-lts (Ubuntu) Status: New => Invalid ** Changed in: openjdk-lts (Ubuntu Xenial) Status: New => Invalid ** Changed in: openjdk-lts (Ubuntu Cosmic) Status: New => Invalid ** Description changed: Today both the OpenJDK 8 and 11 packages were updated. In the case of - OpenJDK 8 (openjdk-8): + OpenJDK 8 (openjdk-8 in Xenial, Bionic, Cosmic, and Disco): openjdk-8-jdk: 8u181-b13-0ubuntu0.18.04.1 → 8u181-b13-1ubuntu0.18.04.1 OpenJDK 10 (openjdk-lts in Bionic): openjdk-11-jdk: 10.0.2+13-1ubuntu0.18.04.2 → 10.0.2+13-1ubuntu0.18.04.3 After this update all my local Maven builds fail with a crashed VM. From the console output it looks like one of the prerequisites of JaCoCo (Java code coverage tool) is no longer met, but I haven't been able to figure out what the root cause is. This problem occurs with both OpenJDK 8 and 10. Reproduction: This is one of our projects: https://github.com/LableOrg/java-nicerxvi Clone the project, and call `mvn clean install`. For me it now fails to build (output attached). When I downgrade to 8u162-b12-1 everything works again. ** Changed in: openjdk-lts (Ubuntu Bionic) Status: New => Confirmed ** Changed in: openjdk-8 (Ubuntu Xenial) Status: New => Confirmed ** Changed in: openjdk-8 (Ubuntu Bionic) Status: New => Confirmed ** Changed in: openjdk-8 (Ubuntu Cosmic) Status: New => Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1800792 Title: Update to openjdk-8 8u181-b13-1ubuntu0.18.04.1 and openjdk-lts 10.0.2+13-1ubuntu0.18.04.3 breaks Maven builds Status in openjdk-8 package in Ubuntu: Confirmed Status in openjdk-lts package in Ubuntu: Invalid Status in openjdk-8 source package in Xenial: Confirmed Status in openjdk-lts source package in Xenial: Invalid Status in openjdk-8 source package in Bionic: Confirmed Status in openjdk-lts source package in Bionic: Confirmed Status in openjdk-8 source package in Cosmic: Confirmed Status in openjdk-lts source package in Cosmic: Invalid Status in openjdk-10 package in Debian: New Status in openjdk-8 package in Debian: Fix Released Bug description: Today both the OpenJDK 8 and 11 packages were updated. In the case of OpenJDK 8 (openjdk-8 in Xenial, Bionic, Cosmic, and Disco): openjdk-8-jdk: 8u181-b13-0ubuntu0.18.04.1 → 8u181-b13-1ubuntu0.18.04.1 OpenJDK 10 (openjdk-lts in Bionic): openjdk-11-jdk: 10.0.2+13-1ubuntu0.18.04.2 → 10.0.2+13-1ubuntu0.18.04.3 After this update all my local Maven builds fail with a crashed VM. From the console output it looks like one of the prerequisites of JaCoCo (Java code coverage tool) is no longer met, but I haven't been able to figure out what the root cause is. This problem occurs with both OpenJDK 8 and 10. Reproduction: This is one of our projects: https://github.com/LableOrg/java-nicerxvi Clone the project, and call `mvn clean install`. For me it now fails to build (output attached). When I downgrade to 8u162-b12-1 everything works again. To manage notifications about this bug go to:
[Group.of.nepali.translators] [Bug 1662813] Re: Libjna-jni uses wrong path on package installation on s390x
** Changed in: libjna-java (Ubuntu Xenial) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1662813 Title: Libjna-jni uses wrong path on package installation on s390x Status in Ubuntu on IBM z Systems: Invalid Status in libjna-java package in Ubuntu: Invalid Status in libjna-java source package in Xenial: Invalid Bug description: libjna-jni uses the wrong path for linking the library /usr/lib/s390x-linux-gnu/libjnidispatch.so on the z Systems s390x architecture, therefore applications relying on this library are unable to link to it, even if the package is installed. Creating the link manually fixes this problem. It should be linked from /usr/lib/s390x-linux- gnu/jni/libjnidispatch.system.so /sbin/ldconfig.real: Can't link /usr/lib/s390x-linux-gnu//build /libjna-java-D1S9TX/libjna-java-4.2.2/build/native-linux- s390x/libjnidispatch.system.so to libjnidispatch.so dpkg -S /usr/lib/s390x-linux-gnu/jni/libjnidispatch.system.so libjna-jni: /usr/lib/s390x-linux-gnu/jni/libjnidispatch.system.so To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1662813/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1791959] Re: [SRU] remove orphaned initrd old-dkms files in /boot
SRU as a merge proposal for both this and bug 1667512 available at Bionic: https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355189 Xenial: https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355190 ** No longer affects: dkms (Ubuntu) ** No longer affects: dkms (Ubuntu Xenial) ** No longer affects: dkms (Ubuntu Bionic) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1791959 Title: [SRU] remove orphaned initrd old-dkms files in /boot Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Xenial: New Status in initramfs-tools source package in Bionic: New Bug description: [Impact] If a dkms package is installed which has REMAKE_INITRD or the same setting has been manually configured by a user then when a kernel is removed its possible for an ".old-dkms" file to be left in /boot with no associated kernel. bug 1515513 dealt with removing old-dkms initrd files using the kernel's prerm hook, but that is only executed for the kernel version being removed: any other old-dkms file generated prior to that would not be removed by the hook, taking space in the /boot directory and being carried forward with every upgrade. Note: Filling up the /boot partition causes updates and upgrades to fail. [Test Case] As the fix for bug 1515513 is available on Xenial and Bionic it is no longer possible to reproduce this by simply installing and updating kernels - dkms 2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. In order to replicate it an old dkms file will be created by hand. This assumes a new Xenial/Bionic schroot. 1) create files to work as a placeholders for old dkms files (there are 4 possible namings for these files) touch /boot/initrd-4.0.0-0-generic.img.old-dkms /boot/initramfs-4.0.0-0-generic.img.old-dkms /boot/initrd.img-4.0.0-0-generic.old-dkms /boot/initrd-4.0.0-0-generic.old-dkms 2) install 3 old kernels, r8168-dkms, and the current initramfs-tools * xenial: apt-get install -y linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms initramfs-tools=0.122ubuntu8.12 * bionic: apt-get install -y linux-image-4.15.0-32-generic linux-image-4.15.0-33-generic linux-image-4.15.0-34-generic r8168-dkms initramfs-tools=0.130ubuntu3.3 3) install the headers for the old kernels (forces dkms to run) * xenial: apt-get install -y linux-headers-4.4.0-21-generic linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic * bionic: apt-get install -y linux-headers-4.15.0-32-generic linux-headers-4.15.0-33-generic linux-headers-4.15.0-34-generic 4) verify that there are 7 old-dkms, the 4 manually created ones and one for each installed kernel ls -1 /boot/*.old-dkms 5) install the initramfs-tools from proposed that contains this fix apt-get install -y initramfs-tools 6) verify that the manually created old-dkms files were removed and that there are only 3 files now, one for each installed kernel ls /boot/*.old-dkms 7) mark kernel images and headers as automatically installed apt-mark auto linux-image-4*-generic linux-headers-4*-generic 8) autoremove the older kernel apt-get autoremove -y 9) verify that there are now only 2 old-dkms, one for each installed kernel ls -1 /boot/*.old-dkms These steps guarantees that: - orphaned old-dkms are correctly removed from /boot - non-orphaned old-dkms are kept - when kernel is removed the related old-dkms are also deleted [Regression Potential] Somebody out there might expect the .old-dkms file to be kept, but that seems like an odd expectation. One notices *.old-dkms files being left behind still sitting on the disk after purging the related kernel. This can cause /boot to become full, and when it gets really bad, even sudo apt-get autoremove won't fix the problem - only deleting the old-dkms files manually solves the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1791959/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1791959] Re: remove /boot/initrd.img-*.old-dkms files left behind
** Changed in: dkms (Ubuntu Xenial) Status: New => Invalid ** Changed in: dkms (Ubuntu Bionic) Status: New => Invalid ** Description changed: [Impact] If a dkms package is installed which has REMAKE_INITRD or the same setting has been manually configured by a user then when a kernel is removed its possible for an ".old-dkms" file to be left in /boot with no associated kernel. bug 1515513 dealt with removing initrd.img-.old-dkms files using the kernel's prerm hook, but that is only executed for the kernel version being removed: any other old-dkms file generated prior to that would not be removed by the hook, taking space in the /boot directory. Note: Filling up the /boot partition causes updates to fail. [Test Case] - As the fix for bug 1515513 is available on Xenial it is no longer possible to reproduce this by simply installing and updating kernels (dkms 2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an old dkms file will be created by hand. + As the fix for bug 1515513 is available on Xenial and Bionic it is no longer possible to reproduce this by simply installing and updating kernels - dkms 2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. In order to replicate it an old dkms file will be created by hand. - This assumes a new Xenial schroot. + This assumes a new Xenial/Bionic schroot. 1) create a file to work as a placeholder for the initrd.img old dkms file sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms 2) install 3 old kernels, r8168-dkms, and the current initramfs-tools + * xenial: sudo apt-get install -y linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms initramfs-tools=0.122ubuntu8.12 + * bionic: + TBD 3) install the headers for the old kernels (forces dkms to run) + * xenial: sudo apt-get install -y linux-headers-4.4.0-21-generic linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic + * bionic: + TBD 4) verify that there are 4 old-dkms, the manually created and one for each installed kernel ls /boot/*.old-dkms 5) install the initramfs-tools that contains this fix sudo apt-get install -y initramfs-tools 6) verify that the manually created old-dkms file was removed and that there are only 3 files now, one for each installed kernel ls /boot/*.old-dkms 7) autoremove the older kernel sudo apt-get autoremove -y 8) verify that there are now only 2 old-dkms, one for each installed kernel ls /boot/*.old-dkms [Regression Potential] Somebody out there might expect the .old-dkms file to be kept, but that seems like an odd expectation. One notices *.old-dkms files being left behind still sitting on the disk after purging the related kernel. This can cause /boot to become full, and when it gets really bad, even sudo apt-get autoremove won't fix the problem - only deleting the old-dkms files manually solves the problem. -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1791959 Title: remove /boot/initrd.img-*.old-dkms files left behind Status in dkms package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Confirmed Status in dkms source package in Xenial: Invalid Status in initramfs-tools source package in Xenial: New Status in dkms source package in Bionic: Invalid Status in initramfs-tools source package in Bionic: New Bug description: [Impact] If a dkms package is installed which has REMAKE_INITRD or the same setting has been manually configured by a user then when a kernel is removed its possible for an ".old-dkms" file to be left in /boot with no associated kernel. bug 1515513 dealt with removing initrd.img-.old-dkms files using the kernel's prerm hook, but that is only executed for the kernel version being removed: any other old-dkms file generated prior to that would not be removed by the hook, taking space in the /boot directory. Note: Filling up the /boot partition causes updates to fail. [Test Case] As the fix for bug 1515513 is available on Xenial and Bionic it is no longer possible to reproduce this by simply installing and updating kernels - dkms 2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. In order to replicate it an old dkms file will be created by hand. This assumes a new Xenial/Bionic schroot. 1) create a file to work as a placeholder for the initrd.img old dkms file sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms 2) install 3 old kernels, r8168-dkms, and the current initramfs-tools * xenial: sudo apt-get install -y linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms initramfs-tools=0.122ubuntu8.12 * bionic: TBD 3) install the
