[Group.of.nepali.translators] [Bug 1934506] Re: Mirrored MOK variables could be accidentally deleted
** Changed in: shim 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/1934506 Title: Mirrored MOK variables could be accidentally deleted Status in shim: Fix Released Status in shim package in Ubuntu: Fix Released Status in shim-signed package in Ubuntu: Fix Released Status in shim source package in Xenial: Fix Released Status in shim-signed source package in Xenial: Fix Released Status in shim source package in Bionic: Fix Released Status in shim-signed source package in Bionic: Fix Released Status in shim source package in Focal: Fix Released Status in shim-signed source package in Focal: Fix Released Status in shim source package in Hirsute: Fix Released Bug description: [Impact] On some systems, Mok variables mirrored are accidentally deleted after the mirroring. This can prevent the kernel from loading DKMS modules, if it does not yet use the config table to parse the MokList variable; and userspace tools relying on the variables will have wrong results. Most implementations reject the accidental delete, as the flags do not match, this bug was produced on VMWare. [Test plan] If we can get a VMWare Workstation or Player license, it would be good to validate that. Without a license, the best we can do is ensure there are no regressions on other machines and rely on the authors of the patch (SUSE) to have tested this properly. [Where problems could occur] We could accidentally delete the variable on other systems now. To manage notifications about this bug go to: https://bugs.launchpad.net/shim/+bug/1934506/+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 1515513] Re: /boot/initrd.img-*.old-dkms files left behind
** Changed in: dkms (Debian) Status: Fix Committed => 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/1515513 Title: /boot/initrd.img-*.old-dkms files left behind Status in DKMS: Fix Released Status in dkms package in Ubuntu: Fix Released Status in dkms source package in Xenial: Fix Released Status in dkms source package in Zesty: Fix Released Status in dkms package in Debian: Fix Released Bug description: [Impact] If a dkms package is installed which has REMAKE_INITRD or the same setting has be 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. [Test Case] On a system with two old kernels and one new kernel available in -updates: 1) install r8168-dkms 2) install the dkms module for the old kernel e.g. 'sudo dkms install -m r8168 -v 8.041.00 -k 4.4.0-31-generic' 3) upgrade your kernel e.g. "sudo apt install linux-image-generic' 4) sudo apt autoremove 5) observe something like "initrd.img-4.4.0-31-generic.old-dkms" in /boot without a corresponding "initrd.img-4.4.0-31-generic" With the version of dkms in -proposed, the .old-dkms file will be removed when the kernel is auto removed. [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. Note: Filling up the /boot partition causes updates to fail. ProblemType: BugDistroRelease: Ubuntu 15.04 Package: dkms 2.2.0.3-2ubuntu3.3 ProcVersionSignature: Ubuntu 3.19.0-28.30-generic 3.19.8-ckt5 Uname: Linux 3.19.0-28-generic x86_64 ApportVersion: 2.17.2-0ubuntu1.7 Architecture: amd64 CurrentDesktop: KDE Date: Thu Nov 12 08:17:10 2015 InstallationDate: Installed on 2015-05-05 (190 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) PackageArchitecture: allSourcePackage: dkms UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/dkms/+bug/1515513/+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 1599646] Re: E-mail report contains repeated "Reading database ... NN%" lines
** Changed in: apt (Debian) 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/1599646 Title: E-mail report contains repeated "Reading database ... NN%" lines Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Cosmic: Fix Released Status in apt package in Debian: Fix Released Bug description: [Impact] * Unattended-upgrades sends the following repeating dpkg progress lines with almost no informational value in the email report: ... (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 60486 files and directories currently installed.) ... * This makes the report email too verbose and makes harder to spot real problems. [Test Case] * Run package autopkgtest and observe no such lines in the echoed email in upgrade-all-security and upgrade-between-snapshots tests. [Regression Potential] * The fix filters dpkg's output only and in the worst case other lines could be missing or u-u could crash. Since the applied hard- coded regex pattern is fairly simple and we observed no crashes in the tests those regressions are unlikey to occur. [Originial Bug Text] This concerns unattended-upgrades 0.90 in Xenial. Here is an excerpt from an e-mail report sent out by u-u after the upgrade process is completed: Package installation log: Log started: 2016-07-06 17:24:21 Preconfiguring packages ... (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 314949 files and directories currently installed.) Preparing to unpack .../tzdata_2016f-0ubuntu0.16.04_all.deb ... Unpacking tzdata (2016f-0ubuntu0.16.04) over (2016d-0ubuntu0.16.04) ... Preparing to unpack .../libgimp2.0_2.8.16-1ubuntu1.1_i386.deb ... All but the last "Reading database ..." line should be elided from the message. As a matter of fact, those lines do not appear in messages mailed out from current Trusty systems (u-u version 0.82.1ubuntu2.4), so this appears to be a regression. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1599646/+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 1755447] Re: issue 32185: SSLContext.wrap_socket sends SNI Extension when server_hostname is IP
** Changed in: python3.5 (Debian) Status: New => Fix Released ** Changed in: python3.4 (Debian) Status: New => Fix Released ** Changed in: python2.7 (Debian) 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/1755447 Title: issue 32185: SSLContext.wrap_socket sends SNI Extension when server_hostname is IP Status in Python: Fix Released Status in python2.7 package in Ubuntu: Fix Released Status in python3.6 package in Ubuntu: Fix Released Status in python3.7 package in Ubuntu: Fix Released Status in python2.7 source package in Trusty: Won't Fix Status in python3.4 source package in Trusty: Won't Fix Status in python2.7 source package in Xenial: Won't Fix Status in python3.5 source package in Xenial: Won't Fix Status in python2.7 source package in Artful: Won't Fix Status in python3.6 source package in Artful: Won't Fix Status in python3.7 source package in Artful: Won't Fix Status in python2.7 source package in Bionic: Fix Released Status in python3.6 source package in Bionic: Fix Released Status in python3.7 source package in Bionic: Fix Released Status in python2.7 package in Debian: Fix Released Status in python3.4 package in Debian: Fix Released Status in python3.5 package in Debian: Fix Released Bug description: the fix for https://bugs.python.org/issue32185 needs backports for the stable releases. To manage notifications about this bug go to: https://bugs.launchpad.net/python/+bug/1755447/+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 1764220] Re: [SRU] dpkg zstd support
** Changed in: dpkg Status: Incomplete => 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/1764220 Title: [SRU] dpkg zstd support Status in dpkg: Fix Released Status in dpkg package in Ubuntu: Fix Released Status in dpkg source package in Xenial: Fix Released Bug description: [Impact] * Xenial's dpkg can't decompress zstd-compressed binary packages preventing some systems of Launchpad from processing packages with such compression. This blocks publishing zstd-compressed binary packages through Launchpad for later Ubuntu releases as well. [Test Plan] * https://people.canonical.com/~rbalint/zstd-debs/ contains a .deb built on Hirsute having both data and control members of the .deb being compressed with zstd. * Download and unpack it. With unfixed dpkg an error should be shown. $ wget https://people.canonical.com/~rbalint/zstd-debs/glibc-doc- reference_2.33-0ubuntu2~zstd1_all.deb # unfixed: $ dpkg-deb -R glibc-doc-reference_2.33-0ubuntu2~zstd1_all.deb glibc-doc-extracted dpkg-deb: error: archive 'glibc-doc-reference_2.33-0ubuntu2~zstd1_all.deb' uses unknown compression for member 'control.tar.zst', giving up # fixed $ time dpkg-deb -R glibc-doc-reference_2.33-0ubuntu2~zstd1_all.deb glibc-doc-extracted real 0m0.148s user 0m0.041s sys 0m0.124s * Also install the package: root@x-zstd:~# dpkg -i glibc-doc-reference_2.33-0ubuntu2~zstd1_all.deb Selecting previously unselected package glibc-doc-reference. (Reading database ... 25816 files and directories currently installed.) Preparing to unpack glibc-doc-reference_2.33-0ubuntu2~zstd1_all.deb ... Unpacking glibc-doc-reference (2.33-0ubuntu2~zstd1) ... Setting up glibc-doc-reference (2.33-0ubuntu2~zstd1) ... Processing triggers for install-info (6.1.0.dfsg.1-5) ... root@x-zstd:~# * Build the hello package, it should work * Build the hello package overriding the compression to zstd, this should fail: $ cat debian/rules ... override_dh_builddeb: dh_builddeb -- -Zzstd ... make[1]: Entering directory '/root/hello-2.10' dh_builddeb -- -Zzstd dpkg-deb: error: only decompression is supported for 'zstd'! Type dpkg-deb --help for help about manipulating *.deb files; Type dpkg --help for help about installing and deinstalling packages. dh_builddeb: dpkg-deb -Zzstd --build debian/hello .. returned exit code 2 debian/rules:12: recipe for target 'override_dh_builddeb' failed [Where problems could occur] * The fix is isolated and is a backport from Bionic with the compression part omitted. Crashes could happen due to coding errors should they exist. Only decompression should be supported and this is verified in the test plan. * Incompabilities between libzstd present in Xenial and present in later releases could prevent dpkg running on Xenial from successfully processing packages built on later releases. The package for Xenial is built with libzstd1 (build-depending on libzstd1-dev) which is at version 1.3.1+dfsg-1~ubuntu0.16.04.1. Bionic's version is 1.3.3+dfsg-2ubuntu1.2 and there were no format breaking changes between those versions, not in any later version. See https://github.com/facebook/zstd/issues/999#issuecomment-359538229 . [Original Bug Text] As discussed previously, we want to have zstd support in 18.04 to evaluate and potentially enable it in later releases. The zstd support adds a dependency on libzstd1 to dpkg. This should not have any effect on live images, since libzstd1 is part of the various live tasks, as btrfs-progs need it. For installed systems, this might be a new dependency (if they do not use btrfs, tor, or some other tools), so an increase of ~520 KB, as that's the size of the library and the library only depends on libc6. The change is isolated, it adds the compressor and decompressor to dpkg, please see the attached patch for the details. The change is being discussed here: https://lists.ubuntu.com/archives/ubuntu-devel/2018-March/040211.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664 To manage notifications about this bug go to: https://bugs.launchpad.net/dpkg/+bug/1764220/+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 1508290] Re: zemberek-ooo: FTBFS: /usr/lib/libreoffice/ure-link/share/java does not exist
** Changed in: zemberek-ooo (Debian) 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/1508290 Title: zemberek-ooo: FTBFS: /usr/lib/libreoffice/ure-link/share/java does not exist Status in zemberek-ooo package in Ubuntu: Triaged Status in zemberek-ooo source package in Wily: New Status in zemberek-ooo source package in Xenial: Triaged Status in zemberek-ooo package in Debian: Fix Released Bug description: Imported from Debian bug http://bugs.debian.org/802416: Source: zemberek-ooo Version: 1.0~rc2-10.4 Severity: serious Justification: fails to build from source Tags: sid stretch User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, The package fails to build: compile-java: [javac] /zemberek-ooo-1.0~rc2/build.xml:60: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 11 source files to /zemberek-ooo-1.0~rc2/build/classes BUILD FAILED /zemberek-ooo-1.0~rc2/build.xml:167: The following error occurred while executing this line: /zemberek-ooo-1.0~rc2/build.xml:60: /usr/lib/libreoffice/ure-link/share/java does not exist. Total time: 0 seconds Possibly related to https://bugs.debian.org/802402 Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/zemberek-ooo.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zemberek-ooo/+bug/1508290/+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 1584485] Re: Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS
** Changed in: samba (Debian) 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/1584485 Title: Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS Status in samba package in Ubuntu: Incomplete Status in samba source package in Trusty: Fix Released Status in samba source package in Xenial: Fix Committed Status in samba source package in Yakkety: Fix Committed Status in samba package in Debian: Fix Released Bug description: [Impact] * Upgrading samba when using winbind as NSS service can break OS. * Probably not triggered if "compat" is BEFORE "winbind" in nsswitch.conf. * Huge impact due to big version different between winbind and libraries. [Test Case 1] Verify that the regression reported in bug 1644428 has not recurred. [Test Case 2] 1) Start an ubuntu Trusty container 2) cp /etc/apt/sources.list /etc/apt/sources.list.back 3) Disable the trusty-updates and trusty-security archives in /etc/apt/sources.list 4) sudo apt-get update 5) sudo apt-get install samba winbind libnss-winbind libpam-winbind 6) Set /etc/nsswitch.conf to : passwd: winbind compat 7) Restart the services 7.1) sudo restart smbd 7.2) sudo restart nmbd 7.3) sudo restart winbind 8) cp /etc/apt/sources.list.back /etc/apt/sources.list 9) sudo apt-get update 7) sudo apt-get install samba winbind libnss-winbind libpam-winbind While installing, you will see things similar to this : > Unpacking libnss-winbind:amd64 (2:4.3.11+dfsg-0ubuntu0.14.04.1) over (2:4.1.6+dfsg-1ubuntu2) ... > dpkg-deb: error: subprocess tar was killed by signal (Segmentation fault), core dumped > dpkg: error processing archive /var/cache/apt/archives/libpam-winbind_2%3a4.3.11+dfsg-0ubuntu0.14.04.1_amd64.deb (- > -unpack): > subprocess dpkg-deb --control returned error exit status 2 > dpkg-deb: error: subprocess tar was killed by signal (Segmentation fault), core dumped [Regression Potential] * "preinst" and "postrm" maintainer scripts are acting only in "upgrade" * uninstalling packages and reinstalling would bypass this change [Other Info] * Original Bug Description: It was brought to my attention that, because of latest security fixes for samba: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1577739 samba (2:4.3.9+dfsg-0ubuntu0.14.04.1) trusty-security; urgency=medium samba (2:4.3.8+dfsg-0ubuntu0.14.04.2) trusty-security; urgency=medium samba (2:4.1.6+dfsg-1ubuntu2.14.04.13) trusty-security; urgency=medium when library symbols changed, a samba upgrade MAY jeopardize an entire Ubuntu OS installation IF /etc/nsswitch.conf uses winbind as a service (specially if used before compat mechanism). How to reproduce easily: $ cat /etc/nsswitch.conf passwd: winbind compat shadow: compat group: winbind compat (winbind is usually used after compat, in this case it was used before) to have samba version "4.1.6+dfsg-1ubuntu2.14.04.13" installed and do a: $ sudo apt-get update and FINALLY: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/comments/1 Leading into an unusable system in the following state: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/comments/2 ## state Workaround: DO REMOVE winbind from /etc/nsswitch.conf (and possibly from pam.d with "pam-auth-update") before ANY attempt of upgrading samba to latest version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/+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 1796047] Re: update-ieee-data throws error because of wrong url
** Changed in: ieee-data (Debian) 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/1796047 Title: update-ieee-data throws error because of wrong url Status in ieee-data package in Ubuntu: Confirmed Status in ieee-data source package in Xenial: Confirmed Status in ieee-data package in Debian: Fix Released Bug description: When trying to run `update-ieee-data`: # update-ieee-data Updating /var/lib/ieee-data//oui.txt Checking permissions on /var/lib/ieee-data//oui.txt Downloading http://standards.ieee.org/regauth/oui/oui.txt to /var/lib/ieee-data//oui.txt wget -q -O- http://standards.ieee.org/regauth/oui/oui.txt exit with 8 It seems the url are simply wrong in the script. all the files are at http://standards-oui.ieee.org/ now. Just update the script with the correct url. Thanks ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: ieee-data 20180204.1 [modified: usr/sbin/update-ieee-data usr/share/ieee-data/iab.csv usr/share/ieee-data/iab.txt usr/share/ieee-data/mam.csv usr/share/ieee-data/mam.txt usr/share/ieee-data/oui.csv usr/share/ieee-data/oui.txt usr/share/ieee-data/oui36.csv usr/share/ieee-data/oui36.txt] ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18 Uname: Linux 4.15.0-36-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Oct 4 11:00:29 2018 InstallationDate: Installed on 2018-05-07 (149 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_FR.UTF-8 SHELL=/bin/bash SourcePackage: ieee-data UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ieee-data/+bug/1796047/+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 1581864] Re: nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument
** Changed in: nginx (Debian) 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/1581864 Title: nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument Status in nginx package in Ubuntu: Fix Released Status in nginx source package in Xenial: Won't Fix Status in nginx source package in Bionic: Confirmed Status in nginx source package in Cosmic: Won't Fix Status in nginx source package in Disco: Won't Fix Status in nginx source package in Eoan: Fix Released Status in nginx package in Debian: Fix Released Bug description: [Description] Nginx logs an error when started on a machine with a single CPU: systemctl start nginx systemctl status nginx ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2016-05-14 19:35:03 UTC; 2s ago Process: 1303 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (code=exited, status=0/SUCCESS) Process: 1307 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 1306 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 1308 (nginx) Tasks: 5 (limit: 512) Memory: 3.1M CPU: 81ms CGroup: /system.slice/nginx.service ├─1308 nginx: master process /usr/sbin/nginx -g daemon on; master_process on ├─1309 nginx: worker process ├─1310 nginx: worker process ├─1311 nginx: worker process └─1312 nginx: worker process May 14 19:35:03 ngx systemd[1]: Starting A high performance web server and a reverse proxy server... May 14 19:35:03 ngx systemd[1]: nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument May 14 19:35:03 ngx systemd[1]: Started A high performance web server and a reverse proxy server. Bumping the number of CPU available makes the error disappear. This is reproducible on VMs and containers. Lastly, the PID file is properly created and matches the PID of the master process. [Workaround] sudo mkdir /etc/systemd/system/nginx.service.d printf "[Service]\nExecStartPost=/bin/sleep 0.1\n" | \ sudo tee /etc/systemd/system/nginx.service.d/override.conf sudo systemctl daemon-reload sudo systemctl restart nginx [Additional information] # lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 # apt-cache policy nginx-core nginx-core: Installed: 1.10.0-0ubuntu0.16.04.1 Candidate: 1.10.0-0ubuntu0.16.04.1 Version table: *** 1.10.0-0ubuntu0.16.04.1 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 1.9.15-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: nginx-core 1.10.0-0ubuntu0.16.04.1 ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Sat May 14 19:35:21 2016 ProcEnviron: TERM=xterm PATH=(custom, no user) SourcePackage: nginx UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1581864/+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 1755858] Re: iscsid autostarts on all servers when it has nothing to do
** Changed in: open-iscsi (Debian) 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/1755858 Title: iscsid autostarts on all servers when it has nothing to do Status in open-iscsi package in Ubuntu: Fix Released Status in open-iscsi source package in Xenial: New Status in open-iscsi source package in Bionic: Fix Released Status in open-iscsi package in Debian: Fix Released Bug description: [Impact] * Service is running uselessly which is consuming a few cycles/memory as well as raising general concerns e.g. on minimizing attack surface of a system. * This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations. * Fix by switching to socket activation [Test Case] * After installing open-iscsi (which is default installed) the service iscsid is running which is mostly useless - this is a bit critical, as we don't want to stop a running service. - so you have two cases 1. uninstall the package before upgrade; then install the new version. should be service off, socket on 2. upgrade install, should have service (still) on, socket enabled. 3. after 2. reboot should be service off, socket on * Also ensure that iscsid.service should come up as needed # should be off $ systemctl status iscsid.service iscsid.socket $ iscsiadm -m discovery -t sendtargets -p 127.0.0.1 # should be enabled now $ systemctl status iscsid.service iscsid.socket [Regression Potential] * We were discussing if we shall SRU this. First of all the change should work as in the new version, abstract sockets are not super new. * We were concerned that one would have e.g. scripts and other upper level code that does like: if service-is-not-running; then break; else do what you should do This would give up before socket-triggering it which might be too much to SRU. On a Upgrade to a newer release such minor adaptions are usual, but for SRUs? But in any config using it it will run, and as slangasek outlined " I think anyone checking for the running status of an open-iscsi service, on a system that does not have any iscsi targets configured, is writing buggy code and that should not be catered to in the face of the significant impact this bug has on all other users of Ubuntu Server." * But also we don't stop the service on upgrade (for safety of the data), so you'd have four different Bionics a) old iscsid.service runnign by default b) upgraded, but not rebooted iscsid.service still running c) upgraded, rebooted iscid.service disabled, iscsid.socket running d) new deploy after this (e.g. new cloud image) iscid.service disabled, iscsid.socket running a+b are similar as well as c+d. * If anyone strictly needs the old behavior it is a config, so one can "systemctl enable iscsid.service" and is done. * OTOH in our discussion it was agreed that the upgrade regression we fix outweighs the potential regression. [Other Info] * The SRU of this change caused a regression described in bug 1802354. --- In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured: # Must have some pre-defined targets to login to ConditionDirectoryNotEmpty=|/etc/iscsi/nodes # or have a session to use via iscsid ConditionDirectoryNotEmpty=|/sys/class/iscsi_session However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do. We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed. Related bugs: * bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid * bug 1802354: iscsid does not run if there are only initramfs initiated targets To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1755858/+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 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
** Changed in: cyrus-sasl2 Status: Confirmed => Fix Released ** Changed in: cyrus-sasl2 (Debian) Status: Confirmed => 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/827151 Title: Annoying log message "DIGEST-MD5 common mech free" Status in Cyrus-sasl2: Fix Released Status in cyrus-sasl2 package in Ubuntu: Triaged Status in cyrus-sasl2 source package in Trusty: Won't Fix Status in cyrus-sasl2 source package in Xenial: Incomplete Status in cyrus-sasl2 source package in Yakkety: Fix Released Status in cyrus-sasl2 source package in Focal: Triaged Status in cyrus-sasl2 package in Debian: Fix Released Bug description: I recently updated the libsasl2-modules to 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric. That triggered the bug also described in Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932 The annoying message is logged in auth.log. In my case, it is associated with svnserve: svnserve: DIGEST-MD5 common mech free I'm not exactly sure what action triggers the message, but I can investigate more if required. $ lsb_release -rd Description:Ubuntu oneiric (development branch) Release:11.10 To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+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 1931243] Re: FTBFS in Impish on s390x
** Changed in: gdisk (Debian) 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/1931243 Title: FTBFS in Impish on s390x Status in Release Notes for Ubuntu: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in gdisk package in Ubuntu: Fix Released Status in gdisk source package in Xenial: Invalid Status in gdisk source package in Bionic: Invalid Status in gdisk source package in Focal: Invalid Status in gdisk source package in Groovy: Invalid Status in gdisk source package in Hirsute: Invalid Status in gdisk source package in Impish: Fix Released Status in gdisk package in Debian: Fix Released Bug description: The bug here is mostly for tracking and the update-excuse tag. I've reported it to Debian already at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589 And at upstream: https://sourceforge.net/p/gptfdisk/mailman/gptfdisk-general/thread/CAATJJ0LdpVeVGMMaYUe995%3DZFtuJu6tW5VjQ%3DONbpwci_fezZw%40mail.gmail.com/#msg37298406 See update details there. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1931243/+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 1800159] Re: keepalived does not autoload the ip_vs kernel module when it is required
** Changed in: keepalived (Debian) 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/1800159 Title: keepalived does not autoload the ip_vs kernel module when it is required Status in keepalived package in Ubuntu: Fix Released Status in keepalived source package in Xenial: Won't Fix Status in keepalived source package in Bionic: Fix Released Status in keepalived package in Debian: Fix Released Bug description: 1) Description: Ubuntu 16.04.5 LTS Release: 16.04 2) keepalived: Installed: 1:1.2.24-1ubuntu0.16.04.1 Candidate: 1:1.2.24-1ubuntu0.16.04.1 Version table: *** 1:1.2.24-1ubuntu0.16.04.1 500 500 http://ftp.hosteurope.de/mirror/archive.ubuntu.com xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 3) not loading the kernel module systemctl start keepalived.service Keepalived_healthcheckers[1680]: IPVS: Protocol not available Keepalived_healthcheckers[1680]: message repeated 8 times: [ IPVS: Protocol not available] ... 4) loading the module manually systemctl stop keepalived.service modprobe ip_vs kernel: [ 445.363609] IPVS: ipvs loaded. systemctl start keepalived.service Keepalived_healthcheckers[5533]: Initializing ipvs kernel: [ 600.828683] IPVS: [wlc] scheduler registered. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1800159/+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 1668474] Re: AH00526 when using long ProxyPass worker name
** Changed in: apache2 Status: Confirmed => 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/1668474 Title: AH00526 when using long ProxyPass worker name Status in Apache2 Web Server: Fix Released Status in apache2 package in Ubuntu: Triaged Status in apache2 source package in Trusty: Triaged Status in apache2 source package in Xenial: Triaged Status in apache2 source package in Yakkety: Won't Fix Status in apache2 package in Debian: New Bug description: When using a long ProxyPass worker name such as unix:///var/php- fpm/146527084714328.sock|fcgi://localhost/home/mysite/domains/subdomain.com/public_html/$1 Apache issues the fatal error AH00526 and refuses to proceed during reload. This is a typical configuration generated by Virtualmin for a subdomain running php-fpm. A couple of workarounds are available using mod_rewrite, but they do not use connection pooling for the proxy and aren't available for packaged solutions like Virtualmin. The patch from trunk is fairly straightforward. To manage notifications about this bug go to: https://bugs.launchpad.net/apache2/+bug/1668474/+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 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd
** Changed in: rabbitmq-server (Debian) 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/1874075 Title: rabbitmq-server startup timeouts differ between SysV and systemd Status in rabbitmq-server package in Ubuntu: Fix Released Status in rabbitmq-server source package in Xenial: Fix Released Status in rabbitmq-server source package in Bionic: Fix Released Status in rabbitmq-server source package in Eoan: Won't Fix Status in rabbitmq-server source package in Focal: Fix Released Status in rabbitmq-server source package in Groovy: Fix Released Status in rabbitmq-server package in Debian: Fix Released Bug description: The startup timeouts were recently adjusted and synchronized between the SysV and systemd startup files. https://github.com/rabbitmq/rabbitmq-server-release/pull/129 The new startup files should be included in this package. [Impact] After starting the RabbitMQ server process, the startup script will wait for the server to start by calling `rabbitmqctl wait` and will time out after 10 s. The startup time of the server depends on how quickly the Mnesia database becomes available and the server will time out after `mnesia_table_loading_retry_timeout` ms times `mnesia_table_loading_retry_limit` retries. By default this wait is 30,000 ms times 10 retries, i.e. 300 s. The mismatch between these two timeout values might lead to the startup script failing prematurely while the server is still waiting for the Mnesia tables. This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the `--timeout` option into the startup script. The default value for this timeout is set to 10 minutes (600 seconds). This change also updates the systemd service file to match the timeout values between the two service management methods. [Scope] Upstream patch: https://github.com/rabbitmq/rabbitmq-server- release/pull/129 * Fix is not included in the Debian package * Fix is not included in any Ubuntu series * Groovy and Focal can apply the upstream patch as is * Bionic and Xenial need an additional fix in the systemd service file to set the `RABBITMQ_STARTUP_TIMEOUT` variable for the `rabbitmq-server-wait` helper script. [Test Case] In a clustered setup with two nodes, A and B. 1. create queue on A 2. shut down B 3. shut down A 4. boot B The broker on B will wait for A. The systemd service will wait for 10 seconds and then fail. Boot A and the rabbitmq-server process on B will complete startup. [Regression Potential] This change alters the behavior of the startup scripts when the Mnesia database takes long to become available. This might lead to failures further down the service dependency chain. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+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 1668474] Re: AH00526 when using long ProxyPass worker name
** Changed in: apache2 Status: Fix Released => 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/1668474 Title: AH00526 when using long ProxyPass worker name Status in Apache2 Web Server: Confirmed Status in apache2 package in Ubuntu: Triaged Status in apache2 source package in Trusty: Triaged Status in apache2 source package in Xenial: Triaged Status in apache2 source package in Yakkety: Won't Fix Status in apache2 package in Debian: New Bug description: When using a long ProxyPass worker name such as unix:///var/php- fpm/146527084714328.sock|fcgi://localhost/home/mysite/domains/subdomain.com/public_html/$1 Apache issues the fatal error AH00526 and refuses to proceed during reload. This is a typical configuration generated by Virtualmin for a subdomain running php-fpm. A couple of workarounds are available using mod_rewrite, but they do not use connection pooling for the proxy and aren't available for packaged solutions like Virtualmin. The patch from trunk is fairly straightforward. To manage notifications about this bug go to: https://bugs.launchpad.net/apache2/+bug/1668474/+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 1916486] Re: zfs_zrele_async can cause txg sync deadlocks
** Changed in: zfs-linux (Debian) 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/1916486 Title: zfs_zrele_async can cause txg sync deadlocks Status in zfs-linux package in Ubuntu: Fix Released Status in zfs-linux source package in Xenial: Fix Released Status in zfs-linux source package in Bionic: Fix Released Status in zfs-linux source package in Focal: Fix Released Status in zfs-linux source package in Groovy: Fix Released Status in zfs-linux source package in Hirsute: Fix Released Status in zfs-linux package in Debian: Fix Released Bug description: [Impact] TXG sync stalls, causing ZFS workloads to hang indefinitely [Description] For certain ZFS workloads, we can see hung task timeouts in the kernel logs due to a transaction group deadlock. Userspace process will hang and display stack traces similar to the one below: [49181.619711] clnt_server D0 21699 28868 0x0320 [49181.619715] Call Trace: [49181.619725] __schedule+0x24e/0x880 [49181.619730] schedule+0x2c/0x80 [49181.619750] cv_wait_common+0x11e/0x140 [spl] [49181.619763] ? wait_woken+0x80/0x80 [49181.619775] __cv_wait+0x15/0x20 [spl] [49181.619872] zil_commit.part.14+0x80/0x8c0 [zfs] [49181.619884] ? _cond_resched+0x19/0x40 [49181.619887] ? mutex_lock+0x12/0x40 [49181.619959] zil_commit+0x17/0x20 [zfs] [49181.620026] zfs_fsync+0x77/0xe0 [zfs] [49181.620093] zpl_fsync+0x68/0xa0 [zfs] [49181.620100] vfs_fsync_range+0x51/0xb0 [49181.620105] do_fsync+0x3d/0x70 [49181.620109] SyS_fsync+0x10/0x20 [49181.620114] do_syscall_64+0x73/0x130 [49181.620119] entry_SYSCALL_64_after_hwframe+0x41/0xa6 We also might see a kworker thread blocking in the zfs writeback/evict path: [49181.881570] kworker/u17:3 D0 4915 2 0x8000 [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10) [49181.881577] Call Trace: [49181.881580] __schedule+0x24e/0x880 [49181.881582] ? atomic_t_wait+0x60/0x60 [49181.881584] schedule+0x2c/0x80 [49181.881588] bit_wait+0x11/0x60 [49181.881592] __wait_on_bit+0x4c/0x90 [49181.881596] ? atomic_t_wait+0x60/0x60 [49181.881599] __inode_wait_for_writeback+0xb9/0xf0 [49181.881601] ? bit_waitqueue+0x40/0x40 [49181.881605] inode_wait_for_writeback+0x26/0x40 [49181.881609] evict+0xb5/0x1a0 [49181.881611] iput+0x19c/0x230 [49181.881648] zfs_iput_async+0x1d/0x80 [zfs] [49181.881682] zfs_get_data+0x1d4/0x2a0 [zfs] [49181.881718] zil_commit.part.14+0x640/0x8c0 [zfs] [49181.881752] zil_commit+0x17/0x20 [zfs] [49181.881784] zpl_writepages+0xd5/0x160 [zfs] [49181.881787] do_writepages+0x4b/0xe0 [49181.881790] __writeback_single_inode+0x45/0x350 [49181.881792] ? __writeback_single_inode+0x45/0x350 [49181.881794] writeback_sb_inodes+0x1d7/0x530 [49181.881796] wb_writeback+0xfb/0x300 [49181.881799] wb_workfn+0xad/0x400 [49181.881800] ? wb_workfn+0xad/0x400 [49181.881803] ? __switch_to_asm+0x35/0x70 [49181.881809] process_one_work+0x1de/0x420 [49181.881811] worker_thread+0x32/0x410 [49181.881813] kthread+0x121/0x140 [49181.881815] ? process_one_work+0x420/0x420 [49181.881817] ? kthread_create_worker_on_cpu+0x70/0x70 [49181.881819] ret_from_fork+0x35/0x40 This is caused by a race between ZFS writeback and evict threads, usually during a transaction group sync operation. It's possible to have two iput() threads racing for the same inode: one of them scheduled async and the other executed synchronously as part of the writeback path. If the writeback thread tries to evict the inode while the async thread is running, it might re-enter the block layer for the same inode due to ZFS counters being in an inconsistent state. This then causes the kworker thread to stall the writeback, which in turn prevents the transaction group sync to complete and locks other ZFS threads. This is fixed by the upstream commit: - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0] [Test Case] Being a race condition, this issue has been hard to reproduce consistently. This has been reported on heavy I/O workloads, mixing file creation and deletion. We have some reports both from upstream and from Ubuntu users that this is usually reproducible on e.g. heavy SQL workloads or on complex ccache-enabled builds [1]. [0] https://github.com/openzfs/zfs/pull/11530 [1] https://github.com/openzfs/zfs/issues/11527 [Regression Potential] The patch has been tested in the ZFS test suite and in production environments, so the potential for further regressions should be fairly controlled. Potential regressions might arise in the ZFS writeback path, causing write hangs and eventually stalling all ZFS-backed operations indefinitely. We should monitor
[Group.of.nepali.translators] [Bug 1819345] Re: knockd systemd service uses After=network.target instead of network-online.target
** Changed in: knockd (Debian) 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/1819345 Title: knockd systemd service uses After=network.target instead of network- online.target Status in knockd package in Ubuntu: Fix Released Status in knockd source package in Trusty: Invalid Status in knockd source package in Xenial: Invalid Status in knockd source package in Bionic: Fix Released Status in knockd source package in Cosmic: Fix Released Status in knockd source package in Disco: Fix Released Status in knockd package in Debian: Fix Released Bug description: [impact] the knockd systemd service file is configured to start knockd After=network.target, however the systemd 'network.target' only means network configuration has started, not completed; the interface(s) that knockd is configured to listen on may not even be up yet. In that case, starting knockd fails. [test case] install, configure, and enable knockd on a system. reboot the system, and check the logs for knockd errors about the interface not being up. verify knockd is not running. Note that since the 'network.target' dependency is essentially a race condition between knockd.service executing and the interface it listens on being configured, it may be necessary to have a more complex network configuration (which takes longer to fully set up) to more easily trigger this, such as setting up a bridge or bond with multiple interfaces and using dhcp and configuring knockd to listen on the bridge or bond interface. [regression potential] changing the systemd service dependency to use network-online instead of network delays when knockd starts, and regressions would be related to knockd not running before the network was fully configured, or not running at all if systemd failed to ever reach network-online target. [other info] this requires the knock systemd service file fix from bug 1799697 also, since the knockd systemd service cannot be enabled at all without that fix. this applies only to b/c/d since t/x use upstart for service management, and this bug is only in the knockd systemd service file. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/knockd/+bug/1819345/+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 1799697] Re: knockd do not start at boot after enabling it with systemctl
** Changed in: knockd (Debian) 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/1799697 Title: knockd do not start at boot after enabling it with systemctl Status in knockd package in Ubuntu: Fix Released Status in knockd source package in Trusty: Invalid Status in knockd source package in Xenial: Invalid Status in knockd source package in Bionic: Fix Released Status in knockd source package in Cosmic: Fix Released Status in knockd source package in Disco: Fix Released Status in knockd package in Debian: Fix Released Bug description: [impact] on systems controlled by systemd, the knockd service will never start because it is not possible to enable it. [test case] install a system that uses systemd, and install knockd package. try to enable the service: $ sudo systemctl enable knockd Synchronizing state of knockd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable knockd The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. after fixing the knockd.service file, the service can be enabled: $ sudo systemctl enable knockd.service Synchronizing state of knockd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable knockd [regression potential] very low, as knockd is useless currently since it can never be started from systemd. any regressions would be in the area of starting knockd. [other info] the systemd service for knockd also needs the fix from bug 1819345 this applies only to b/c/d since t/x use upstart to manage services, and this problem is only in the knockd systemd service file. original description: --- About my Ubuntu: Description: Ubuntu 18.04 Release: 18.04 About Knockd: knockd: Installed: 0.7-1ubuntu1 Candidate: 0.7-1ubuntu1 Version table: *** 0.7-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages 100 /var/lib/dpkg/status >> When enabling knockd with systemctl y get the following error: ### $ sudo systemctl enable knockd Synchronizing state of knockd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable knockd The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. ### It doesnt start at boot also. If I add the following to the end of /lib/systemd/system/knockd.service then I can enable it successfully and starts at boot: ### [Install] WantedBy=multi-user.target Alias=knockd.service ### ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: knockd 0.7-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18 Uname: Linux 4.15.0-38-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 CurrentDesktop: KDE Date: Wed Oct 24 14:42:40 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2017-06-28 (483 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) SourcePackage: knockd UpgradeStatus: Upgraded to bionic on 2018-08-10 (74 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/knockd/+bug/1799697/+subscriptions ___ Mailing list:
[Group.of.nepali.translators] [Bug 304393] Re: rpcbind grabs ports used by other daemons such as cupsd
** Changed in: fedora Status: Confirmed => Won't Fix -- 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/304393 Title: rpcbind grabs ports used by other daemons such as cupsd Status in cups package in Ubuntu: Invalid Status in rpcbind package in Ubuntu: Fix Released Status in rpcbind source package in Xenial: Fix Released Status in rpcbind source package in Bionic: Fix Released Status in rpcbind package in Debian: Fix Released Status in Fedora: Won't Fix Bug description: [impact] rpcbind binds to a 'random' reserved port at startup, which can conflict with the reserved port number for other applications that actually 'own' the reserved port number. One example is cups, which uses the reserved port 631. This prevents the actual 'owner' of the reserved port from starting, since it can't bind to its reserved port. Additionally, this can raise alarms from security monitoring software that does not expect programs to be listening on random reserved ports. [test case] start rpcbind and check which ports it is listening on, e.g.: $ sudo netstat --inet -p -l | grep rpcbind | grep -v sunrpc udp0 0 0.0.0.0:614 0.0.0.0:* 4678/rpcbind each time rpcbind is restarted, it will be listening to a different 'random' port. [regression potential] this adds a way to disable rpcbind from listening to the 'random' port. any regression would likely prevent rpcbind from starting, or may cause problems with the interaction between rpcinfo and rpcbind, as rpcinfo may use the random reserved port in some cases, as detailed in the Debian bug. [scope] This is needed only for Bionic and earlier. In Focal and later, and in Debian, rpcbind defaults to not opening the random reserved port. The admin can use the -r parameter to cause rpcbind to restore the old behavior of opening the random reserved port. [other info] Note that the -r parameter is a Debian addition, and the upstream rpcbind has disabled the random port functionality at build time; there is no runtime parameter to allow the admin to choose the behavior. Also, as discussed in the Debian bug, disabling this rpcbind 'feature' is known to cause problems for the rpcinfo program, which is why Debian introduced the -r parameter. So, when this -r parameter is backported to Bionic and earlier, we must retain the default behavior for those releases, which is for rpcbind to open the random reserved port. Thus, the patch for this will first backport the upstream patch that adds functionality to be able to disable the 'remote calls' function, and also backports the debian patch to change that from a compile-time to run-time option. Then, another patch is added, which changes the default back to the behavior of x/b, which is for remote calls to be enabled by default, and also adds a check for the existence of an environment variable "RPCBIND_RMTCALL_DEFAULT_DISABLED" which, if defined (to anything), will change the default to disabled. This allows 1) retaining the existing default behavior of rpcbind in x and b, while also 2) providing a mechanism to change that default for anyone who does *not* want remote calls to be enabled, and 3) allowing the mechanism to change the default to remain in place after an upgrade to Focal. Using the environment variable allows anyone to disable the remote calls in x and/or b, and then upgrade to Focal without breaking rpcbind or needing to remove the env var. After the upgrade to Focal, the environment variable (defined in /etc/default/rpcbind and/or /etc/rpcbind.conf) will simply be ignored without any change needed to the rpcbind package in Focal or later. [original description] Binary package hint: cups cups 1.3.9-2ubuntu4 From /var/log/cups/error_log: cups: unable to bind socket for address 127.0.0.1:631 - Address already in use. Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd when started. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+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 1871471] Re: flash end of life soon, suggest remove from hirsute and also handle stable releases
** Changed in: pepperflashplugin-nonfree (Debian) 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/1871471 Title: flash end of life soon, suggest remove from hirsute and also handle stable releases Status in OEM Priority Project: Fix Released Status in adobe-flashplugin package in Ubuntu: Fix Released Status in flashplugin-nonfree package in Ubuntu: Fix Released Status in pepperflashplugin-nonfree package in Ubuntu: Won't Fix Status in adobe-flashplugin source package in Xenial: Fix Released Status in flashplugin-nonfree source package in Xenial: Fix Released Status in pepperflashplugin-nonfree source package in Xenial: Fix Released Status in adobe-flashplugin source package in Bionic: Fix Released Status in flashplugin-nonfree source package in Bionic: Fix Released Status in pepperflashplugin-nonfree source package in Bionic: Fix Released Status in adobe-flashplugin source package in Focal: Fix Released Status in flashplugin-nonfree source package in Focal: Fix Released Status in pepperflashplugin-nonfree source package in Focal: Fix Released Status in adobe-flashplugin source package in Groovy: Fix Released Status in pepperflashplugin-nonfree source package in Groovy: Fix Released Status in adobe-flashplugin source package in Hirsute: Fix Released Status in pepperflashplugin-nonfree source package in Hirsute: Fix Released Status in pepperflashplugin-nonfree package in Debian: Fix Released Bug description: Hello, Adobe has said they will not be supporting Flash beyond 2020: https://helpx.adobe.com/acrobat/kb/flash-format-support-in-pdf.html https://theblog.adobe.com/adobe-flash-update/ I think we shouldn't ship Flash in hirsute. Does our agreement with Adobe for distributing Flash installers or code allow us to skip shipping Flash in hirsute? Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1871471/+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 1437492] Re: boot stalls on USB detection errors
** Changed in: linux (Debian) 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/1437492 Title: boot stalls on USB detection errors Status in linux package in Ubuntu: Fix Released Status in linux source package in Vivid: Fix Released Status in linux source package in Wily: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Released Status in linux package in Debian: Fix Released Bug description: My system boots slow. I investigated this and it seems systemd-udev-settle.service is the culprit. My system runs ext4 with GPT on UEFI. I do not use encryption or LVM. $ journalctl -u systemd-udev-settle -- Logs begin at fri 2015-03-27 19:03:06 CET, end at fri 2015-03-27 22:06:32 CET. -- mar 27 19:03:42 hostname systemd[1]: Started udev Wait for Complete Device Initialization. $ systemd-analyze Startup finished in 14.865s (firmware) + 11.133s (loader) + 6.127s (kernel) + 42.079s (userspace) = 1min 14.206s $ systemd-analyze critical-chain http://paste.ubuntu.com/10691416/ $ systemd-analyze blame 36.013s systemd-udev-settle.service http://paste.ubuntu.com/10691314/ $ systemctl show systemd-udev-settle.service -p RequiredBy RequiredBy= $ systemctl show systemd-udev-settle.service -p WantedBy WantedBy=friendly-recovery.service $ systemd-analyze plot > boot.svg http://imgh.us/boot_1.svg $ systemd-analyze dump http://paste.ubuntu.com/10691856/ ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-5ubuntu1 ProcVersionSignature: Ubuntu 3.19.0-10.10-generic 3.19.2 Uname: Linux 3.19.0-10-generic x86_64 ApportVersion: 2.16.2-0ubuntu5 Architecture: amd64 CurrentDesktop: GNOME-Flashback:Unity Date: Fri Mar 27 22:05:28 2015 InstallationDate: Installed on 2013-12-26 (455 days ago) InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) MachineType: ASUS All Series ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-10-generic.efi.signed root=UUID=31dc4488-28d4-4d2a-aa51-6733e237d5f8 ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/18/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2103 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: Z87-PRO dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2103:bd08/18/2014:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ87-PRO:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.name: All Series dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1437492/+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 1823444] Re: [SRU] The Japanese Era name will be changed on May 1, 2019
** Changed in: mozc 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/1823444 Title: [SRU] The Japanese Era name will be changed on May 1, 2019 Status in Mozc: Fix Released Status in mozc package in Ubuntu: Fix Released Status in mozc source package in Xenial: Fix Released Status in mozc source package in Bionic: Fix Released Status in mozc source package in Cosmic: Fix Released Status in mozc source package in Disco: Fix Released Status in mozc source package in Eoan: Fix Released Bug description: [Impact] New Japaenese era 'Reiwa' is expected to start on 1 May 2019. https://japan.kantei.go.jp/98_abe/statement/201904/_1.html Mozc has A.D. to Japanese Era converter. * "AD 2018"（２０１８ねん） => "Heisei 30th"（平成三十年） Please support new era too as like following. * "AD 2018"（２０１８ねん） => "Heisei 30th"（平成三十年） * "AD 2019"（２０１９ねん） => "Heisei 31th"（平成三十一年） * "AD 2019"（２０１９ねん） => "Reiwa 1st"（令和元年） [Test Case] * Enable Japanese InputMethod and Mozc. * Start "System Settings" * Open "Regiaon and Language" menu * Select "Japanese (Mozc)" from "Input Sources" * Restart GUI session * Startup gedit. * Input following strings and confirm popping up new era by space key. * "れいわ" => "令和" * "れいわ" => "㋿" (*1) * "２０１８ねん" => "平成三十年" * "２０１８ねん" => "平成三十年" * "２０１９ねん" => "平成三十一年" * "２０１９ねん" => "令和元年" * "２０２０ねん" => "令和二年" * *1: Current fonts-noto-cjk package has no glyph of U+32FF. [Regression Potential] * There's basically no regression potential. To manage notifications about this bug go to: https://bugs.launchpad.net/mozc/+bug/1823444/+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 1699933] Re: ipmi-locate crash on arm64
** Changed in: freeipmi (Debian) Status: Confirmed => 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/1699933 Title: ipmi-locate crash on arm64 Status in freeipmi package in Ubuntu: Fix Released Status in freeipmi source package in Xenial: Fix Released Status in freeipmi source package in Yakkety: Fix Released Status in freeipmi source package in Zesty: Fix Released Status in freeipmi source package in Artful: Fix Released Status in freeipmi package in Debian: Fix Released Bug description: [Impact] * Read from /dev/mem and scan DMI tables is dangerous, if /dev/mem is not stable to read, it will cause ipmi-locate crash. [Test Case] * `sudo ipmi-locate` shall not crash [Regression Potential] * Reading from DMI tables is sysfs is more stable then reading from /dev/mem and if DMI tables is not available ipmi-locate will use the old way to search in /dev/mem. I believe its low regression risk Similiar to bug 1499838 but not 100% same. ipmi-locate looks into /dev/mem for DMI tables and crash when DMI tables are not in accessible memory region. Kernel > v4.2 provides /sys/firmware/DMI/tables/DMI which is a much safer place to read. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1699933/+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 1734983] Re: Request to backport sosreport v3.5
** Changed in: sosreport (Debian) 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/1734983 Title: Request to backport sosreport v3.5 Status in sosreport: Fix Released Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Fix Released Status in sosreport source package in Xenial: Fix Released Status in sosreport source package in Zesty: Won't Fix Status in sosreport source package in Artful: Fix Released Status in sosreport source package in Bionic: Fix Released Status in sosreport package in Debian: Fix Released Bug description: [Impact] Canonical support team (AKA STS) largely depend on sosreport package to troubleshoot system. sosreport is always in constant development including new bugfixes, new features such as new plugins[1], that can be interesting to have in a support context. v3.5 is already found in devel release (bionic). We create this LP in the attempt to justify the SRU of v3.5 backport into current supported stable releases. [1] - New plugins for : * perl * boom * vdo * os_net_config * conntrackd * ovirt_imageio * nss * sas3ircu * openstack_aodh * docker_distribution * gluster_block * snappy Plugin API enhancements * Plugin triggers by executable name * Improved log size limit handling * Better handling of compressed log files * Per-plugin package verification lists Updates to 227 plugins This will also allow us to close some sosreport LP bugs: *Docker plugin uses the wrong command for Ubuntu (LP: #1693574) [Test Case] * Install sosreport $ apt-get install sosreport * Run sosreport $ sosreport -a $ sosreport -o $ ... * Make sure it generate a tar.xz file in /tmp in the form of "/tmp/sosreport--.tar.xz" * Extract files from archive $ tar Jxvf /tmp/sosreport--.tar.xz * Look the content of sosreport, make sure the information is accurate and valid, * Make sure all files that should to be collected by sosreport aren't 0 size. (Files that should be collected may varies from one system to another, it depends on what packages are installed, ...) $ find /tmp/sosreport-- -size 0 # Note : It is normal to see some 0 size files here and there, again it depend on how the plugin is run (package detection or not inside the plugins, ...) and if the package is installed or not on the system where you run sosreport. But in most cases, if the package is installed and if sosreport has a plugin for it then it should gather information, if not then it might be a problem with the plugins itself that need adjustments. [Regression Potential] * autopkgtest[2] didn't reveal any [2] - See Comment #1 * We,STS, have intensively tested the package. During our testing, we found a severe regression that we already took action to fix it via : - Upstream issue - https://github.com/sosreport/sos/issues/1155 - Debian bug - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883537 - Fix Released in Ubuntu Devel release (bionic) via debdiff : lp1734983_bionic.debdiff [Other Info] * Sosreport upstream : https://github.com/sosreport/sos * rmadison -u debian,ubuntu sosreport debian: sosreport | 3.2-2| oldstable | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x sosreport | 3.2-2| oldstable-kfreebsd | source, kfreebsd-amd64, kfreebsd-i386 sosreport | 3.3+git50-g3c0349b-2 | stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x sosreport | 3.5-1| testing| source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x sosreport | 3.5-1| unstable | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x ubuntu: sosreport | 3.0-1~ubuntu12.04.1 | precise-backports/universe | source, amd64, armel, armhf, i386, powerpc sosreport | 3.1-1ubuntu2 | trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el sosreport | 3.1-1ubuntu2.2 | trusty-security| source, amd64, arm64, armhf, i386, powerpc, ppc64el sosreport | 3.2-2~ubuntu14.04.1 | trusty-backports | source, amd64, arm64, armhf, i386, powerpc, ppc64el sosreport | 3.2+git276-g7da50d6-3ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x sosreport | 3.3+git50-g3c0349b-2
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
** Changed in: cryptsetup (Debian) 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/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: Fix Released Status in initramfs-tools source package in Bionic: Fix Released Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: Fix Released Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: Fix Released Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: Fix Released Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1890265] Re: BUG: Version 3.5.27-1ubuntu1.7 breaks config using icap
** Changed in: squid3 (Debian) 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/1890265 Title: BUG: Version 3.5.27-1ubuntu1.7 breaks config using icap Status in squid3 package in Ubuntu: Fix Released Status in squid3 source package in Xenial: Fix Released Status in squid3 source package in Bionic: Fix Released Status in squid3 package in Debian: Fix Released Bug description: Using ubuntu 18.04 I had a squid config using c-icap to scan requests/responses using ClamAV. It was working OK since long time ago. Today, squid has (security)updated to 3.5.27-1ubuntu1.7 and now, connection to icap is broken. That is the error at squid-cache.log 2020/08/04 09:44:08 kid1| essential ICAP service is down after an options fetch failure: icap://127.0.0.1:1344/virus_scan [down,!opt] After downgrading to 3.5.27-1ubuntu1.6 it starts working again. The icap service is working fine, tested with `c-icap-client -i 127.0.0.1 -p 1344 -s virus_scan` Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1890265/+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 1585121] Re: awstats produces regex warnings in version 7.4 with Perl 5.22 on Ubuntu 16.04 LTS
** Changed in: awstats (Debian)
Status: Confirmed => 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/1585121
Title:
awstats produces regex warnings in version 7.4 with Perl 5.22 on
Ubuntu 16.04 LTS
Status in awstats package in Ubuntu:
Fix Released
Status in awstats source package in Xenial:
Fix Released
Status in awstats package in Debian:
Fix Released
Bug description:
[Impact]
The main awstats script triggers the Perl deprecation warnings about
unescaped braces in regexes, every time the script is run (which, by
default is every 10 minutes, via cron, sending out an email with
these).
[Test Case]
1. apt install awstats
2. run '/usr/share/awstats/tools/update.sh'
You should get an error because of a missing config parameter, but if
this bug is present, you also get six "Unescaped left brace in regex
is deprecated, ..." messages before that.
[Regression Potential]
I don't see any way this could go wrong. The patch is trivial, and is
already included upstream and in yakkety.
[Original Description]
> Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/\"%{ <-- HERE Referer}i\"/ at
/usr/lib/cgi-bin/awstats.pl line 9043.
> Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/\"%{ <-- HERE User-Agent}i\"/ at
/usr/lib/cgi-bin/awstats.pl line 9044.
> Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/%{ <-- HERE mod_gzip_input_size}n/ at
/usr/lib/cgi-bin/awstats.pl line 9045.
> Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/%{ <-- HERE mod_gzip_output_size}n/ at
/usr/lib/cgi-bin/awstats.pl line 9046.
> Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/%{ <-- HERE mod_gzip_compression_ratio}n/ at
/usr/lib/cgi-bin/awstats.pl line 9047.
> Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/\(%{ <-- HERE ratio}n\)/ at /usr/lib/cgi-bin/awstats.pl
line 9048.
Those warnings occur whenever we execute awstats and they can easily
be fixed by escaping the "{" and "}" at the mentioned lines. In fact
awstats 7.5 fixed those lines already itself:
> AWStats Changelog
> -
>
> * 7.5 *
>
> - Compatibility with Perl 5.22
Please consider backporting those fixes, because awstats is most
likely executed by cron or such and this produces unnecessary mails
with those warnings. Disabling mails on warnings/errors is of course
no solution, because one would miss real configuration errors or such
this way.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/awstats/+bug/1585121/+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 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Changed in: makedumpfile (Debian) 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/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Released Status in makedumpfile source package in Bionic: Fix Released Status in makedumpfile source package in Eoan: Fix Released Status in makedumpfile source package in Focal: Fix Released Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: Fix Released Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+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 1593003] Re: Fix autopkgtest failure
** Changed in: php-horde-mapi (Debian) Status: Confirmed => 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/1593003 Title: Fix autopkgtest failure Status in php-horde-mapi package in Ubuntu: Fix Released Status in php-horde-mapi source package in Xenial: Fix Released Status in php-horde-mapi package in Debian: Fix Released Bug description: [Impact] If built against phpseclib 1.0.1-4 or newer, php-horde-mapi's autopkgtests fail because of deprecation warnings printed to stderr. The deprecation warnings come from phpseclib's use of old-style constructor names. This can't be fixed in phpseclib because switching to new-style names would break packages that depend on the old-style names (see bug #1574058). rbasak> note that we'd like this SRU done to help with fixing and verifying bug 1574058 while not making the dep8 test become a false positive forever. [Test Case] Run the following: sudo apt-get install autopkgtest qemu-system qemu-utils adt-buildvm-ubuntu-cloud -v -r xenial adt-run --setup-commands='apt-add-repository ppa:rhansen/bug1574058' \ -U --apt-source php-horde-mapi --- qemu ./adt-xenial-amd64-cloud.img [Regression Potential] The change only affects the autopkgtest test cases, so there should be no regressions. However, permitting the tests to write to stderr can potentially hide future regressions in this package or in packages that this depends on. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/php-horde-mapi/+bug/1593003/+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 1536181] Re: bind9-resolvconf service doesn't work
** Changed in: bind9 (Debian) 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/1536181 Title: bind9-resolvconf service doesn't work Status in bind9 package in Ubuntu: Fix Released Status in bind9 source package in Xenial: Fix Released Status in bind9 source package in Yakkety: Fix Released Status in bind9 package in Debian: Fix Released Bug description: [Impact] * If using the bind9-resolvconf service to have the local named managed resolv.conf, the service exits after running starting, and the system resolv.conf ends up reverting to the default content. * The user is effectively prevented from using bind9-resolvconf to manage their local resolv.conf. * The issue is that the bind9-resolvconf service needs to detected as still running even after the /etc/resolv.conf modification occurs. As per Debian Bug 744304: "RemainAfterExit tells systemd that a service should be considered running even after it exited. Currently, systemd thinks the service went inactive after the ExecStart command exits, and then immediately calls the ExecStop command, thus removing 127.0.0.1 from resolvconf." [Test Case] * Install bind9-resolvconf with a local bind9 configuration. Start the bind9-resolvconf service and the prior content of /etc/resolv.conf will remain even if it differs from bind9's configuration. [Regression Potential] * I believe the regression potential to be very low for this change. The bind9-resolvconf service currently does not work as expected. Users may have made manual changes locally, as suggested in this bug, but those seem to generally not be permanent solutions and should not collide with the change to the service. --- I enabled the bind9-resolvconf service and restarted my system, because I want to use the named running on localhost as my nameserver. Even after the restart, however, the nameservers in /etc/resolv.conf (actually /var/run/resolvconf/resolv.conf) were still the ones provided by DHCP. This, despite the fact that the logs claim that bind9-resolvconf ran successfully during boot. I tried manually running "sudo systemctl start bind9-resolv.conf", and again, the logs claim it ran, but /etc/resolv.conf was unmodified. Finally, I manually ran "sudo /bin/sh -c 'echo nameserver 127.0.0.1 | /sbin/resolvconf -a lo.named'", i.e., the command listed in /lib/systemd/system/bind9-resolv.conf.service, and _that_ successfully updated /etc/resolv.conf. After doing that, interestingly, "sudo systemctl stop bind9-resolv.conf" _also_ doesn't change /etc/resolv.conf, i.e., it still retains the 127.0.0.1 line which I added by running the resolvconf command manually. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: bind9 1:9.9.5.dfsg-11ubuntu1.2 ProcVersionSignature: Ubuntu 4.2.0-25.30-generic 4.2.6 Uname: Linux 4.2.0-25-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jan 20 08:03:35 2016 InstallationDate: Installed on 2016-01-16 (4 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) RelatedPackageVersions: bind9utils 1:9.9.5.dfsg-11ubuntu1.2 apparmor 2.10-0ubuntu6 SourcePackage: bind9 UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.bind.named.conf: [modified] modified.conffile..etc.bind.named.conf.local: [modified] mtime.conffile..etc.bind.named.conf: 2016-01-16T19:01:39.827033 mtime.conffile..etc.bind.named.conf.local: 2016-01-16T21:13:51.991632 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1536181/+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 1754671] Re: Full-tunnel VPN DNS leakage regression
** Changed in: network-manager Status: Confirmed => Expired -- 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/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Expired Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Confirmed Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions ___ Mailing list: https://launchpad.net/~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 1828884] Re: [META] Handling Japanese new era "令和 (Reiwa)"
** Changed in: poppler 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/1828884 Title: [META] Handling Japanese new era "令和 (Reiwa)" Status in Poppler: Fix Released Status in fonts-noto-cjk package in Ubuntu: Fix Released Status in libreoffice package in Ubuntu: Fix Released Status in libreoffice-l10n package in Ubuntu: Fix Released Status in mozc package in Ubuntu: Fix Released Status in openjdk-8 package in Ubuntu: Fix Released Status in libreoffice source package in Xenial: Fix Released Status in libreoffice-l10n source package in Xenial: Fix Released Status in mozc source package in Xenial: Fix Released Status in openjdk-8 source package in Xenial: Fix Released Status in fonts-noto-cjk source package in Bionic: Fix Released Status in libreoffice source package in Bionic: Fix Released Status in libreoffice-l10n source package in Bionic: Fix Released Status in mozc source package in Bionic: Fix Released Status in openjdk-8 source package in Bionic: Fix Released Status in libreoffice source package in Cosmic: Fix Released Status in libreoffice-l10n source package in Cosmic: Fix Released Status in mozc source package in Cosmic: Fix Released Status in fonts-noto-cjk source package in Disco: Fix Released Status in libreoffice source package in Disco: Fix Released Status in libreoffice-l10n source package in Disco: Fix Released Status in mozc source package in Disco: Fix Released Status in openjdk-8 source package in Disco: Fix Released Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Date output == 1) Set date to 2019/05/01 2) Output date; verify that the year it is displayed as "令和元年" 3) Set date to 2019/04/30 4) Output date; verify that the year is diplayed as "平成31年" === Displaying formatted year for Japanese era with glibc === Run: LC_ALL=ja_JP.utf8 date +%EY -d 20190430 # previous era (should still work as before SRUs) or LC_ALL=ja_JP.utf8 date +%EY -d 20190501 # new era (should now correctly display the new era) == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. == Typing / input methods == 1) Type in 'heisei' 2) Verify that the input method in use gives you an option "平成", and optionally also the square era glyph. 3) Type in 'reiwa' 4) Verify that the input method in use gives you an option that includes "令和", and possibly also the square era glyph (if supported for Heisei) 5) Type in the following strings, and verify that the options are provided in the input method: * "れいわ"(reiwa) => "令和" * "れいわ"(reiwa) => "㋿" * "２０１８ねん"(2018nenn) => "平成三十年" * "２０１９ねん"(2019nenn) => "平成三十一年" * "２０１９ねん"(2019nenn) => "令和元年" * "２０２０ねん"(2020nenn) => "令和二年" /!\ Some fonts, like fonts-noto-cjk, currently have no glyph for U+32FF. [Regression potential] This is a potentially large change as it impacts font display, character sets as well as date conversions. As such, extreme care should be taken to ensure that regressions are avoided, such that dates previous to May 1, 2019 continue to display as before, and dates onward are displayed with the new era symbols. The included test cases account for verifying the continued behavior or previous dates. To manage notifications about this bug go to: https://bugs.launchpad.net/poppler/+bug/1828884/+subscriptions ___
[Group.of.nepali.translators] [Bug 1873368] Re: ssshuttle server fails to connect endpoints with python 3.8
** Changed in: sshuttle
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/1873368
Title:
ssshuttle server fails to connect endpoints with python 3.8
Status in Sshuttle:
Fix Released
Status in sshuttle package in Ubuntu:
In Progress
Status in sshuttle source package in Xenial:
In Progress
Status in sshuttle source package in Bionic:
In Progress
Status in sshuttle source package in Focal:
In Progress
Status in sshuttle source package in Groovy:
In Progress
Status in sshuttle package in Debian:
Fix Released
Bug description:
[Impact]
sshuttle fails to connect to a remote system with python >= 3.8, or
(after initial patch) to remote system with python <= 3.4.
[Test Case]
connect from a system with sshuttle installed to a remote system, in
all combinations (t/x/b/f/g with sshuttle to remote t/x/b/f/g system).
All combinations should work.
The first failure, connecting to remote systems with python >= 3.8,
will fail like:
$ sshuttle -r ubuntu@{ip-addr} {subnet-1}
assembler.py:3: DeprecationWarning: the imp module is deprecated in favour of
importlib; see the module's documentation for alternative uses
client: Connected.
Traceback (most recent call last):
File "", line 1, in
File "assembler.py", line 38, in
File "sshuttle.server", line 298, in main
File "/usr/lib/python3.8/socket.py", line 544, in fromfd
return socket(family, type, proto, nfd)
File "/usr/lib/python3.8/socket.py", line 231, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket
client: fatal: server died with error code 1
The second failure, connecting to remote systems with python <= 3.4,
will fail like:
Traceback (most recent call last):
File "", line 1, in
File "assembler.py", line 39, in
File "sshuttle.server", line 400, in main
File "sshuttle.ssnet", line 598, in runonce
File "sshuttle.ssnet", line 488, in callback
File "sshuttle.ssnet", line 437, in flush
AttributeError: 'module' object has no attribute 'set_blocking'
client: fatal: server died with error code 1
[Regression Potential]
any regression would likely cause problems at connection
initialization, i.e. when connecting from the sshuttle system to the
remote system. it's unlikely this would cause any regression that
occurs after the initial setup has been completed.
[scope]
First, I'll note this regression illustrates the importance of the
[scope] section, and why I always include it in my SRUs...
tl;dr for scope is 2 fixes are needed (work with remote py >= 3.8 and
work with remote py <= 3.4), and both fixes are needed in sshuttle for
all releases.
details:
this is needed for all releases; x, b, f, and g. However there are 2
parts to fixing this; the first part is fixing sshuttle connecting
from any release to a system with python >= 3.8. That is done for g,
and in proposed for f, and not done for b or x. The second part is to
correct the first patch's regression to allow sshuttle connecting from
any release to a system with python <= 3.4. That is needed for x, b,
f, and g.
a good scope table from @smoser is in comment 26.
[Other Info]
https://github.com/sshuttle/sshuttle/issues/381
https://bugs.python.org/issue39685
https://bugs.python.org/issue35415
[Original Description]
Client
$ python3 --version
Python 3.8.2
$ lsb_release -rd
Description:Ubuntu Focal Fossa (development branch)
Release:20.04
$ apt-cache policy sshuttle
sshuttle:
Installed: 0.78.5-1
Candidate: 0.78.5-1
Server
$ python3 --version
Python 3.8.2
$ lsb_release -rd
Description:Ubuntu 20.04 LTS
Release:20.04
$ apt-cache policy openssh-server
openssh-server:
Installed: 1:8.2p1-4
Candidate: 1:8.2p1-4
$ sshuttle -r ubuntu@{ip-addr} {subnet-1} {subnet-2}
assembler.py:3: DeprecationWarning: the imp module is deprecated in favour of
importlib; see the module's documentation for alternative uses
client: Connected.
Traceback (most recent call last):
File "", line 1, in
File "assembler.py", line 38, in
File "sshuttle.server", line 298, in main
File "/usr/lib/python3.8/socket.py", line 544, in fromfd
return socket(family, type, proto, nfd)
File "/usr/lib/python3.8/socket.py", line 231, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket
client: fatal: server died with error code 1
The sshuttle upstream tracker is issue#381 [0]. They are waiting on a
response to bpo#39685 [1].
This regression was introduced in python 3.8 by bpo#35415 [2], which
restricts socket.fromfd() calls to provide valid
[Group.of.nepali.translators] [Bug 1855481] Re: xenial: debian/tests/basic-smoke fails to debootstrap stable since the release of buster
** Changed in: docker.io (Debian) 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/1855481 Title: xenial: debian/tests/basic-smoke fails to debootstrap stable since the release of buster Status in docker.io package in Ubuntu: Invalid Status in docker.io source package in Xenial: In Progress Status in docker.io package in Debian: Fix Released Bug description: [Impact] * Autopkgtest reports failures/regressions for docker.io on Xenial because debian/tests/basic-smoke fails to deboostrap Debian stable, since the release of the new stable, Debian buster (July 6th 2019). * That caused changes to signatures and debootstrap procedures that Xenial packages currently fail to handle. * Such failures are false-positives of regressions with regards to docker.io code *or* it's dependencies, which are thus flagged as causing a regression to a reverse-dependency on autopkgtest.u.c. * The solution is to revert to / stick with Debian stretch, which has been the stable / status-quo before the buster release, and is working correctly on both debian-archive-keyring/debootstrap on Xenial. [Test Case] * Run docker.io autopkgtests or just 'debian/tests/basic-smoke'. [Regression Potential] * The 'debootstrap' command on 'debian/tests/basic-smoke' should now continue to run past an early error, then hit other issues. At this time, it has been verified to finish sucessfully in the autopkgtest.ubuntu.com infrastructure, tested against a PPA. [Other Info] * Currently only Xenial is being reported/fixed, although this issue might hit Bionic and Focal in the future (with 2+years support period, extending over Debian releases) depending on whether further changes might be needed post-Buster release. * Debian's docker.io package only exists on Buster and later, so are not susceptible to this problem right now. * Waiting a bit on feedback on Debian bug report / BTS 946313 [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946313 [Original Description] With the release of Debian Buster (July 2019) the 'stable' distribution symlink on Debian archives changed from 'stretch' to 'buster'. This caused issues to 'debootstrap stable ' on Xenial: (because of Xenial's older/pre-Buster debian-archive-keyring and debootstrap packages) 1. failure to check signature of the Release file (which can be worked-around with --no-check-gpg) 2. failure to unpack packages (which may need further changes) Thus just revert back to / stick with Debian Stretch as the suite to debootstrap for tests. This should prevent it to keep changing to newer releases, which depend on changes/fixes to other packages (not worth it just for the purpose of running 'true' in a docker container.) Original) + debootstrap --variant=minbase stable /tmp/tmp.CmnWmuSeHY http://httpredir.debian.org/debian I: Retrieving InRelease I: Checking Release signature E: Release signed by unknown key (key id DCC9EFBF77E11517) + doExit ... basic-smoke FAIL non-zero exit status 1 With --no-check-gpg) + debootstrap --no-check-gpg --variant=minbase stable /tmp/tmp.LbI1tZGEJb http://httpredir.debian.org/debian I: Retrieving InRelease I: Retrieving Packages ... I: Unpacking the base system... ... W: Failure while installing base packages. This will be re-attempted up to five times. W: See /tmp/tmp.LbI1tZGEJb/debootstrap/debootstrap.log for details + doExit ... basic-smoke FAIL non-zero exit status 1 With s/stable/stretch/) + debootstrap --variant=minbase stretch /tmp/tmp.Eyr81GS2o6 http://httpredir.debian.org/debian I: Retrieving InRelease I: Failed to retrieve InRelease I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010) I: Retrieving Packages ... I: Base system installed successfully. + tar -cC /tmp/tmp.5qp31fXQau . + docker import - debian ... + docker run --name test debian true ... ++ docker rm -f test ... ++ docker rmi debian ... + eval true ++ true ... basic-smoke PASS ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1855481/+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 997172] Re: [SRU] smbldap-config.pl not installed
** Changed in: smbldap-tools (Debian) 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/997172 Title: [SRU] smbldap-config.pl not installed Status in Ubuntu Server Guide: Fix Released Status in smbldap-tools package in Ubuntu: Fix Released Status in smbldap-tools source package in Trusty: Fix Released Status in smbldap-tools source package in Xenial: Fix Released Status in smbldap-tools package in Debian: Fix Released Bug description: [Impact] * The serverguide currently calls out this bug and requires manual download and extraction of a source package because smbldap-config.pl is not present in the binary smbldap-tools package. * Add smbldap-config.pl appropriately to the Makefile to install it. [Test Case] * Install smbldap-tools, smbldap-config.pl will not be present. [Regression Potential] * The risk of regression is low to none, in this case, as the only effective change is the installation of a new Perl script on upgrade. * The only concern would be if a user manually extracted the same script from the source package and then installed the SRU'd version of smbldap-tools, but I believe dpkg will handle that case correctly. --- Installing and configuring LDAP and Samba, beg¡fore execute the command smbldap-populate we must uncompress a files that in this version of smbldap-tools (from Ubuntu 12.04) it is not present. I refer the configure.pl.gz or better the /usr/share/doc/smbldap-tools/configure.pl.gz file. without it we cannot generate the smbldap.conf nor smbldap_bind.conf before execute the smbldap-populate command to Add Samba LDAP objects to my ldap. Thenks To manage notifications about this bug go to: https://bugs.launchpad.net/serverguide/+bug/997172/+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 1589289] Re: fstrim: cannot open /dev/.lxd-mounts: Permission denied
** Changed in: util-linux (Debian) Status: Confirmed => 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/1589289 Title: fstrim: cannot open /dev/.lxd-mounts: Permission denied Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Released Status in util-linux source package in Bionic: Fix Released Status in util-linux source package in Disco: Fix Released Status in util-linux package in Debian: Fix Released Bug description: [Impact] fstrim weekly cronjob output in an unprivileged LXD container: /etc/cron.weekly/fstrim: fstrim: cannot open /dev/.lxd-mounts: Permission denied fstrim: /dev/fuse: not a directory fstrim: /dev/lxd: FITRIM ioctl failed: Operation not permitted There is a github issue: https://github.com/lxc/lxd/issues/2030 The outcome is that it's purely an fstrim misbehaviour, it could be smarter. Stephane Graber comment: As all of this is handled by the kernel, there isn't anything we can do about it in LXD. I think fstrim should be made slightly more clever: * Don't run on bind-mounts (you can detect bind-mounts by parsing /proc/self/mountinfo instead of /proc/mounts) * Maybe not be as noisy on expected errors like EACCES, EPERM and ENOENT, only log actual failures which would likely be EINVAL or memory related errors. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: util-linux 2.27.1-6ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Sun Jun 5 19:49:04 2016 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) [Test Case] * Ubuntu lxd container * Wait for the scheduled fstrim run (X: cronjob, B and late: systemd timer) * fstrim will run and report errors "Operation not permitted" "Permission denied", ... Container shouldn't run fstrim, it should only be run at host level. [Potential Regression] None, the change will only block fstrim to be automatically run at scheduled time. One can still run fstrim on a container manually, even if there is no purpose of doing that. Xenial uses the cronjob approach /etc/cron.weekly/fstrim Bionic and late switched to a systemd timer. 2 differents fixes (one for X, and one for B and late) will be needed, but they'll do same thing, which prevent fstrim to automatically run if inside a container both fixes using systemd-virt-detect. [Other Informations] * The systemd timer change upstream PR: https://github.com/karelzak/util-linux/pull/841 https://github.com/karelzak/util-linux/commit/0280d31a2bd6292acd9a4b86d0f6b5feb275a618 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1589289/+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 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device
** Changed in: util-linux (Debian) Status: Confirmed => 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/1858802 Title: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Released Status in util-linux source package in Bionic: Fix Released Status in util-linux source package in Disco: Won't Fix Status in util-linux source package in Eoan: Fix Released Status in util-linux source package in Focal: Fix Released Status in util-linux package in Debian: Fix Released Bug description: [Impact] * Users with an XFS filesystem on top of bcache (this is seen on some ceph, cloud deployments) might fail to reference the bcache device by UUID or other udev properties. * The journal of the regular XFS filesystem in the bcache device is incorrectly detected as an XFS external log; so two superblocks are detected (bcache and xfs_external_log). * Thus blkid fails with ambivalent superblocks detected then doesn't provide the usual udev properties (UUID, etc.) * The fix improves the probe function for XFS external log so it detects it's regular XFS and bails out. [Test Case] * See test steps detailed in comment #7 and later. - Create an XFS filesystem with the journal/log in the beginning of the bcache device (< 256K). - Stop the bcache device. - Run '$ blkid -o udev -p $BCACHE_BACKING_DEVICE'. $ sudo make-bcache -B $BACKING_DEV $ sudo mkfs.xfs -d agsize=16m -l agnum=0 -f $BCACHE_DEV $ echo 1 | sudo tee /sys/block/$(basename $BCACHE_DEV)/bcache/stop $ sudo blkid -o udev -p $BACKING_DEV [Regression Potential] * The patch only changes the detection function for XFS external log to be more general about the sector where the magic of regular XFS may be found (which is shifted inside the bcache.) * It still checks at sector zero (the only one checked previously), so this behavior didn't change. * Possible regressions are actual XFS external log devices that are not anymore detected as such. (Although that would probably indicate a different bug in libblkid.) [Other Info] * upstream commit: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+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 1856682] Re: [UBUNTU 20.04] GCC Miscompilation in vectorized code
** Changed in: gcc
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/1856682
Title:
[UBUNTU 20.04] GCC Miscompilation in vectorized code
Status in gcc:
Fix Released
Status in Ubuntu on IBM z Systems:
Triaged
Status in gcc-5 package in Ubuntu:
Invalid
Status in gcc-6 package in Ubuntu:
Invalid
Status in gcc-7 package in Ubuntu:
New
Status in gcc-8 package in Ubuntu:
New
Status in gcc-9 package in Ubuntu:
Fix Released
Status in gcc-5 source package in Xenial:
New
Status in gcc-6 source package in Xenial:
Invalid
Status in gcc-7 source package in Xenial:
Invalid
Status in gcc-8 source package in Xenial:
Invalid
Status in gcc-9 source package in Xenial:
Invalid
Status in gcc-5 source package in Bionic:
New
Status in gcc-6 source package in Bionic:
New
Status in gcc-7 source package in Bionic:
New
Status in gcc-8 source package in Bionic:
New
Status in gcc-9 source package in Bionic:
Invalid
Status in gcc-5 source package in Disco:
Invalid
Status in gcc-6 source package in Disco:
New
Status in gcc-7 source package in Disco:
New
Status in gcc-8 source package in Disco:
New
Status in gcc-9 source package in Disco:
New
Status in gcc-5 source package in Eoan:
Invalid
Status in gcc-6 source package in Eoan:
Invalid
Status in gcc-7 source package in Eoan:
New
Status in gcc-8 source package in Eoan:
New
Status in gcc-9 source package in Eoan:
New
Status in gcc-5 source package in Focal:
Invalid
Status in gcc-6 source package in Focal:
Invalid
Status in gcc-7 source package in Focal:
New
Status in gcc-8 source package in Focal:
New
Status in gcc-9 source package in Focal:
Fix Released
Bug description:
Miscompilation in autovectorized code.
---Steps to Reproduce---
See GCC BZ: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950
The following testcase abort when being compiled with -O3 -march=z13
on IBM Z:
struct a {
int b;
char c;
};
struct a d = {1, 16};
struct a *e =
int f = 0;
int main() {
struct a g = {0, 0 };
f = 0;
for (; f <= 1; f++) {
g = d;
*e = g;
}
if (d.c != 16)
__builtin_abort();
}
The movv1qi pattern emits halfword load instructions instead of character
loads.
All GCC versions since GCC 5 are affected.
Patches for GCC 8, 9, and 10 have been committed to the gcc.gnu.org branches.
Userspace tool common name: gcc
The userspace tool has the following bit modes: 64
Userspace rpm: various Ubuntu gcc packages
Package need to updated within LP
To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/1856682/+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 1842701] Re: Apache2 Balancer Manager mod_proxy_balancer not working after Update
** Changed in: apache2
Status: Confirmed => 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/1842701
Title:
Apache2 Balancer Manager mod_proxy_balancer not working after Update
Status in Apache2 Web Server:
Fix Released
Status in apache2 package in Ubuntu:
Confirmed
Status in apache2 source package in Xenial:
Fix Released
Status in apache2 source package in Bionic:
Fix Released
Status in apache2 source package in Disco:
Fix Released
Status in apache2 package in Debian:
Fix Released
Bug description:
OS
Description:Ubuntu 18.04.3 LTS
Release:18.04
Codename: bionic
I use this kind of configuration to reache the Balancer Manager.
-
|Bastian Host |
|Apache Proxy | ---> LB Apache Balancer Manger
-
After Apache Update
from: 2.4.29-1ubuntu4.8
to: 2.4.29-1ubuntu4.10
The Balancer Manager behind a Proxy is not Working and i think this is
comming with
the fix CVE-2019-10092
https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2019-10092
http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.4.29-1ubuntu4.10/changelog
I strip down the configuration to try and explain the situation.
Install new Ubuntu 18.04 VirtualBox. From an another VM i saved the prior
Apache Packages from /var/cache/apt/archives
:~# apt-get install libapr1 libaprutil1 libaprutil1-dbd-sqlite3
libaprutil1-ldap liblua5.2-0
:~# dpkg -i apache2_2.4.29-1ubuntu4.8_amd64.deb
apache2-bin_2.4.29-1ubuntu4.8_amd64.deb apache2-data_2.4.29-1ubuntu4.8_all.deb
apache2-utils_2.4.29-1ubuntu4.8_amd64.deb
:~# dpkg -l | grep apache2
ii apache2 2.4.29-1ubuntu4.8 amd64Apache HTTP Server
ii apache2-bin 2.4.29-1ubuntu4.8 amd64Apache HTTP Server
(modules and other binary files)
ii apache2-data 2.4.29-1ubuntu4.8 all Apache HTTP Server
(common files)
ii apache2-utils2.4.29-1ubuntu4.8 amd64Apache HTTP Server
(utility programs for web servers)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
:~# vim /etc/apache2/sites-available/management.conf
Servername 127.0.0.1
ServerAdmin root@localhost
SetHandler balancer-manager
Require local
#Require ip 192.168.56.0/24 127.0.0.1/24
Require all granted
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/management_error.log
CustomLog ${APACHE_LOG_DIR}/management_access.log combined
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
:~# vim /etc/apache2/sites-available/proxytest.conf
BalancerMember "http://192.168.168.130/test;
BalancerMember "http://192.168.168.131/test; status=+H
ProxySet lbmethod=bybusyness
ServerAdmin root@localhost
ServerName testapp01
ServerAlias 127.0.0.1:8100
ProxyPass "/test" "balancer://test"
ProxyPassReverse"/test" "balancer://test"
CustomLog ${APACHE_LOG_DIR}/test-access.log combined
ErrorLog ${APACHE_LOG_DIR}/test-error.log
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
:~# a2enmod proxy_balancer proxy_http lbmethod_bybusyness lbmethod_byrequests
:~# a2ensite management proxytest
:~# vim /etc/apache2/ports.conf
[...]
Listen 81
Listen 8100
:~# systemctl restart apache2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
At that point i install also some console Browsers for testing.
:~# apt-get install lynx elinks
:~# tail -f /var/log/apache2/management_error.log
:~# elinks 127.0.0.1:81/balancer-manager
:~# lynx 127.0.0.1:81/balancer-manager
i can do update the Load and made changes. i also connect from outside with
Firefox
http://192.168.56.211:81/balancer-manager
all this creates no error log entrys, the log is still empty
-
update apache
:~# apt-get update
:~# apt-get upgrade
:~# dpkg -l | grep apache2
ii apache22.4.29-1ubuntu4.10 amd64Apache HTTP Server
ii apache2-bin2.4.29-1ubuntu4.10 amd64Apache HTTP Server
(modules and other binary files)
ii apache2-data 2.4.29-1ubuntu4.10 all Apache HTTP Server
(common files)
ii apache2-utils 2.4.29-1ubuntu4.10 amd64Apache HTTP Server
(utility programs for web servers)
do the same with all the Browsers and have the error log in view.
http://192.168.56.211:81/balancer-manager
:~# tail -f /var/log/apache2/management_error.log
[Wed Sep 04 12:24:55.740457 2019]
[Group.of.nepali.translators] [Bug 1565060] Re: defaults file is ignored
** Changed in: bind9 (Debian) 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/1565060 Title: defaults file is ignored Status in bind9 package in Ubuntu: Fix Released Status in bind9 source package in Xenial: Fix Released Status in bind9 source package in Yakkety: Won't Fix Status in bind9 source package in Zesty: Fix Released Status in bind9 package in Debian: Fix Released Bug description: [Impact] Server start up options set in /etc/default/bind9 via the OPTIONS variable are ignored. The fix is to have the systemd service file source that file and use the given OPTIONS value. This is already being done in Ubuntu Artful and higher. The fix here is the same. [Test Case] # install bind9 $ sudo apt install bind9 # start it up $ sudo service bind9 start # inspect the command line of the process: $ ps fxaw|grep named|grep -v grep 396 ?Ssl0:00 /usr/sbin/named -f -u bind # edit /etc/default/bind9 and include "-4" to the OPTIONS value so it looks like this: # startup options for the server OPTIONS="-4 -u bind" # restart bind9 sudo service bind9 restart # inspect the process command line again. Only the fixed version of the package will include the newly added "-4" parameter: $ ps fxaw|grep named|grep -v grep 17891 ?Ssl0:00 /usr/sbin/named -f -4 -u bind [Regression Potential] Administrators who have for some reason altered the defaults file with an incorrect value for OPTIONS might be surprised after this update, since now that file is actually parsed and if it's indeed incorrect, the service may fail to start. [Other Info] None at this time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1565060/+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 1697501] Re: ksh segfault on job_chksave () after it receive a SIGCHLD (Signal 17)
** Changed in: ksh (Debian)
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/1697501
Title:
ksh segfault on job_chksave () after it receive a SIGCHLD (Signal 17)
Status in ksh package in Ubuntu:
Fix Released
Status in ksh source package in Trusty:
Fix Released
Status in ksh source package in Xenial:
Fix Released
Status in ksh source package in Yakkety:
Fix Released
Status in ksh source package in Zesty:
Fix Released
Status in ksh source package in Artful:
Fix Released
Status in ksh package in Debian:
Fix Released
Bug description:
[Impact]
* The compiler optimization dropped parts from the ksh job
locking mechanism from the binary code. As a consequence, ksh could terminate
unexpectedly with a segmentation fault after it received the SIGCHLD signal.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the
segfault.
* But the original reporter of this bug can randomly reproduce the
problem using an in-house ksh script that only works inside his
infrastructure as follow : "ksh " and then once
in a while ksh will segfault as follow :
(gdb) bt
#0 job_chksave (pid=pid@entry=19003) at
/build/ksh-6IEHIC/ksh-93u+20120801/src/cmd/ksh93/sh/jobs.c:1948
#1 0x004282ab in job_reap (sig=17) at
/build/ksh-6IEHIC/ksh-93u+20120801/src/cmd/ksh93/sh/jobs.c:428
#2
...
[Regression Potential]
* Regression risk : low/none expected, the package has been
highly/intensively tested by a user who run over 18M ksh scripts a day
on each of their clusters.
+
* Secondly, I doubt ksh has much traction nowadays, so if a regression
occurs... It will most likely be limited to a small amount of users IMHO.
For instance, the bug has been reported 3 years ago for Red Hat, and we,
Ubuntu, only heard about this same situation for the first time a few weeks ago.
+
* The fix has been written by RH and has been proven to work for them
for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a
unmaintained project) and/or possibly never been proposed to upstream
(to be verified).
+
* A test package including the RH fix has been intensively tested and
verified (pre-SRU) by an affected user with positive feedbacks using a
reproducer that segfault without the RH patch.
+
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast],
thus no new development is made upstream nor in debian upstream.
* Details about the RH bug :
--
- https://bugzilla.redhat.com/show_bug.cgi?id=1123467
- https://bugzilla.redhat.com/show_bug.cgi?id=1112306
- https://access.redhat.com/solutions/1253243
- http://rhn.redhat.com/errata/RHBA-2014-1015.html
# ksh.spec
Fri Jul 25 2014 Michal Hlavinka - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[New LWP 3882]
Core was generated by `/bin/ksh .ksh'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 job_chksave (pid=pid@entry=19385) at
/build/ksh-6IEHIC/ksh-93u+20120801/src/cmd/ksh93/sh/jobs.c:1948
1948 if(jp->pid==pid)
(gdb) p *jp
Cannot access memory at address 0xb
(gdb) p *jp->pid
Cannot access memory at address 0x13
(gdb) p pid
$2 = 19385
(gdb) p *jpold
$1 = {next = 0xb, pid = -604008960, exitval = 11124}
The struct is corrupted at some point looking at the next,pid and
exitval struct members values which isn't valid data.
# assembly code
=> 0x00427159 <+41>: cmp %edi,0x8(%rdx)
(gdb) p $edi ## pid variable
$1 = 19385
(gdb) p *($rdx + 8) ## jp->pid struct
Cannot access memory at address 0x13
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus
cannot de-reference the struct member "jp>pid" ($rdx + 8) at line :
src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid
($edi) variable.
I have looked at the github project "att/ast" upstream repo and some
patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ksh/+bug/1697501/+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 1616123] Re: rpc-svcgssd.service uses incorrrect variable SVCGSSDARGS
** Changed in: nfs-utils (Debian) Status: Fix Committed => 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/1616123 Title: rpc-svcgssd.service uses incorrrect variable SVCGSSDARGS Status in nfs-utils package in Ubuntu: Fix Released Status in nfs-utils source package in Xenial: Fix Released Status in nfs-utils source package in Bionic: Fix Released Status in nfs-utils source package in Cosmic: Fix Released Status in nfs-utils package in Debian: Fix Released Bug description: [Impact] Command line options set for rpc.svcgssd in the /etc/default/nfs-kernel-server file are not passed on to the service, being ignored. [Test Case] * In a VM (LXD won't work), install nfs-server and a kerberos server. Use "EXAMPLE.LOCAL" for the realm, and "localhost" for the servers, when prompted: sudo apt install nfs-server krb5-kdc krb5-user krb5-admin-server * create the EXAMPLE.LOCAL realm. Use any password you want for the database master key, it won't be requested again: sudo krb5_newrealm * create a principal for the nfs service: sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)" * extract the key into the system wide keytab: sudo kadmin.local -q "ktadd -k /etc/krb5.keytab nfs/$(hostname -f)" * edit /etc/default/nfs-common and enable gssd: NEED_GSSD=y * edit /etc/default/nfs-kernel-server and add an option to RPCSVCGSSDOPTS: RPCSVCGSSDOPTS="-v" * restart nfs-server sudo systemctl restart nfs-server * on xenial, you also have to restart nfs-config: sudo systemctl restart nfs-config * verify if /run/sysconfig/nfs-utils has the option we added above: $ cat /run/sysconfig/nfs-utils PIPEFS_MOUNTPOINT=/run/rpc_pipefs RPCNFSDARGS=" 8" RPCMOUNTDARGS="--manage-gids" STATDARGS="" RPCSVCGSSDARGS="-v" * Verify the running rpc.gssd process. Without the fix, it won't have the "-v" option: ps axw|grep svcgssd|grep -v grep 4285 ? Ss 0:00 /usr/sbin/rpc.svcgssd With the fix, right after installing the udpated packages, the option we added to /etc/default/nfs-kernel-server will show up: ps axw|grep svcgssd|grep -v grep 5656 ? Ss 0:00 /usr/sbin/rpc.svcgssd -v [Regression Potential] This is an old bug and whoever was affected by it probably worked around the problem by now. I tried to cope with one such scenario by not just renaming the variable we export, but exporting the correct one in addition to the old incorrect one, but that's it. I hope this, and the explanation added to the shell script wrapper nfs-utils.sh, is enough to help people with corner cases. idance to testers in regression-testing the SRU. [Other Info] This patch was accepted in debian: https://salsa.debian.org/debian/nfs-utils/merge_requests/2 [Original Description] In /etc/default/nfs-kernel-server you can specify parameters for rpc.svcgssd: # Options for rpc.svcgssd. RPCSVCGSSDOPTS="-n" But the variable is named incorrectly in /lib/systemd/system/rpc- svcgssd.service: ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1616123/+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 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution
** Changed in: apt Status: Confirmed => 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/1693361 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt- daily.service execution Status in APT: Fix Released Status in cloud-init: Fix Released Status in apt package in Ubuntu: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Won't Fix Status in cloud-init source package in Zesty: Fix Released Status in cloud-init source package in Artful: Fix Released Bug description: === Begin SRU Template === [Impact] A cloud-config that contains packages to install (see below) or 'package_upgrade' will run 'apt-get update'. That can sometimes fail as a result of contention with the apt-daily.service that updates that information. Cloud-config showing the problem is just like: $ cat my.yaml #cloud-config packages: ['hello'] [Test Case] lxc-proposed-snapshot is https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot It publishes an image to lxd with proposed enabled and cloud-init upgraded. a.) launch an instance with proposed version of cloud-init and some user-data. This is platform independent. The test case demonstrates lxd. $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \ "package_upgrade: true" > config.yaml $ release=xenial $ ref=proposed-$release $ ./lxc-proposed-snapshot --proposed --publish $release $ref; b.) start the instance $ name=$release-1693361 $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml) $ sleep 1 $ lxc exec $name -- tail -f /var/log/cloud-init.log /var/log/cloud-init-output.log # watch this boot. c.) Look for evidence of systemd failure journalctl -o short-precise | grep -i break journalctl -o short-precise | grep -i order [Regression Potential] Regression chance here is low. Its possible that ordering loops could occur. When that does happen, journalctl will mention it. Unfortunately in such cases systemd somewhat randomly picks a service to kil so behavior is somewhat undefined. [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=11121fe4 === End SRU Template === apt-daily is now a systemd service rather than being invoked by cron.daily. If one builds a custom AMI it is possible that the apt- daily.timer will fire during boot. This can fire at the same time cloud-init is running and if cloud-init loses the race the invocation of apt (e.g. use of "packages:" in the config) will fail. There is a lot of discussion online about this change to apt-daily (e.g. unattended upgrades happening during business hours, delaying boot, etc.) and discussion of potential systemd changes regarding timers firing during boot (c.f. https://github.com/systemd/systemd/issues/5659). While it would be better to solve this in apt itself, I suggest that cloud-init be defensive when calling apt and implement some retry mechanism. Various instances of people running into this issue: https://github.com/chef/bento/issues/609 https://clusterhq.atlassian.net/browse/FLOC-4486 https://github.com/boxcutter/ubuntu/issues/73 https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image To manage notifications about this bug go to: https://bugs.launchpad.net/apt/+bug/1693361/+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 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
** Changed in: lua-lpeg (Debian)
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/1580385
Title:
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
Status in lua-lpeg package in Ubuntu:
Fix Released
Status in lua-lpeg source package in Xenial:
Fix Released
Status in lua-lpeg source package in Bionic:
Fix Released
Status in lua-lpeg source package in Disco:
Fix Released
Status in lua-lpeg source package in Eoan:
Fix Released
Status in lua-lpeg package in Debian:
Fix Released
Bug description:
[Impact]
Under certain conditions, lpeg will crash while walking the pattern
tree looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion
in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+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 1842947] Re: dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac'
** Changed in: dpkg (Debian) Status: Fix Committed => 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/1842947 Title: dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac' Status in dpkg package in Ubuntu: Fix Released Status in dpkg source package in Xenial: In Progress Status in dpkg source package in Bionic: Fix Released Status in dpkg source package in Disco: Won't Fix Status in dpkg source package in Eoan: Fix Released Status in dpkg package in Debian: Fix Released Bug description: [impact] dpkg at version 1.19.0.5ubuntu2 had support for zstd added: https://launchpad.net/ubuntu/+source/dpkg/1.19.0.5ubuntu2 part of that change was to update the 'configure.ac' file with zstd support, e.g.: http://launchpadlibrarian.net/366237303/dpkg_1.19.0.5ubuntu1_1.19.0.5ubuntu2.diff.gz note that the 'configure' file was not updated - which *should* be ok, as it should be recreated from the 'configure.ac' file during build. For the build of that version and the next (1.19.0.5ubuntu2.1), the 'configure' file was correctly recreated during build. However at version 1.19.0.5ubuntu2.2, the 'configure' file was not recreated during build. Thus, dpkg was not built linked against libzstd. This regresses the ability of dpkg to uncompress zstd-compressed packages, unless the zstd utility is installed on the local system. Since dpkg does not list the zstd package as a dep, it may not be installed on all users' systems who want to install a zstd-compressed package. [test case] on bionic system: $ sudo apt install ubuntu-dev-tools $ pull-lp-source dpkg 1.19.0.5ubuntu2.2 $ cd dpkg-1.19.0.5ubuntu2.2/ $ sudo apt build-dep . $ dpkg-buildpackage and verify if dpkg-deb is linked against libzstd: $ ldd build-tree/dpkg-deb/dpkg-deb | grep zstd or extract it from the deb itself and check: $ dpkg-deb -x ../dpkg_1.19.0.5ubuntu2.2_amd64.deb ../deb-files $ ldd ../deb-files/usr/bin/dpkg-deb | grep zstd simply touching the 'configure.ac' file (to bring its timestamp newer than the 'configure' file) causes the build to work correctly: $ mkdir no-touch $ cd no-touch $ dpkg-source -x ~/dpkg_1.19.0.5ubuntu2.2.dsc $ cd dpkg-1.19.0.5ubuntu2.2/ $ dpkg-buildpackage $ ldd build-tree/dpkg-deb/dpkg-deb | grep zstd $ $ mkdir touch $ cd touch $ dpkg-source -x ~/dpkg_1.19.0.5ubuntu2.2.dsc $ cd dpkg-1.19.0.5ubuntu2.2/ $ touch configure.ac $ dpkg-buildpackage $ ldd build-tree/dpkg-deb/dpkg-deb | grep zstd libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x7f8c1d8af000) [regression potential] this forces autoreconf to be run for each build, which may add some small amount of time to the build. Other than that, the regression potential seems small, since autoreconf should be getting run for each build, and was for most (but not all) builds. Any regression would almost certainly involve a failure to build the package, or a failure to pick up new configure.ac changes correctly. [other info] this might not be an issue specifically with dpkg itself, it could be an issue with debhelper and other tooling that is responsible for calling autoconf or autoreconf during build. Or possibly a problem with the dpkg debian/rules or other related build config. Or, simply including the 'configure' file in the package source might be considered a bug, since it's an intermediate build file that really shouldn't be included. However, it's included in many source packages, including in debian, and removing it from all of them seems unlikely and/or unwieldy. Additionally, for "normal" packages that use quilt (i.e., aren't native), any changes to the 'configure.ac' file would be done with a patch, meaning the pre-build process would always make the 'configure.ac' file newer than the 'configure' file. Maybe for native packages, autoconf/autoreconf should always be called with -f, or maybe the 'configure' file should be removed from native packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1842947/+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 1862830] Re: Update sosreport to 3.9
** Changed in: sosreport (Debian) 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/1862830 Title: Update sosreport to 3.9 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Eoan: In Progress Status in sosreport source package in Focal: Fix Released Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.9 is now released. It would be great to find sosreport v3.9 in supported stable releases, and active development release considering the fact that the releasea (especially LTSes) are going to be supported for a couple of years still. Sosreport is widely use by Canonical support team to troubleshoot UA (Ubuntu Advantage) customer, other vendors and community users. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Test the new upload functionality (--upload) * Test new --all-logs behaviour * Make sure the new naming pattern doesn't break any current Canonical mechanism (Brickftp scripts, ...). If yes evaluate if easy fixable before considering reverting back to 'legacy' pattern. * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" and "sos_logs" for warnings/errors [Regression Potential] Sosreport has 292 plugins that are all configured differently and configured to run under certains conditions. We can't test all possible scenarios. All we can do is idenfity the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...) . With that being said, it is definitely possible that certains plugins may not work as expected, but the risk will be very low (e.g not collecting the desired informations) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionnalities of sosreport. [Other Informations] * Release note: https://github.com/sosreport/sos/releases/tag/3.9 [Original Description] A new version of sosreport upstream (v3.9) will be released soon. This bug is to track activities to update sosreport in Ubuntu stable + Active Devel release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1862830/+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 1649931] Re: systemd-networkd needs to ensure DNS is up before network-online.target
** Changed in: resolvconf (Debian) Status: Fix Committed => 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/1649931 Title: systemd-networkd needs to ensure DNS is up before network- online.target Status in resolvconf package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in resolvconf source package in Xenial: Fix Released Status in systemd source package in Xenial: Fix Released Status in resolvconf source package in Yakkety: Fix Released Status in resolvconf package in Debian: Fix Released Bug description: Currently resolvconf and systemd-networkd don't ensure DNS has been configured before allowing network-online.target to be reached. This was discussed in https://launchpad.net/bugs/1636912 however it was not a regression since there aren't any users of networkd + DNS early in boot at this time, it was requested that we move this DNS issue to a separate bug. [SRU] Fix: switch resolvconf.service to run Before=network-pre.target and add Wants=network-pre.target. Add a Before=network-online.target to systemd-networkd-resolvconf-update.service to ensure we update /etc/resolv.conf with DNS config prior to reaching network-online.target. Regression potential: Low. networkd is not widely being used outside of netplan/snappy in xenial. Test Case: lxc launch ubuntu-daily:xenial x1 lxc exec x1 /bin/bash # make sure you're on systemd-229-4ubuntu17 apt update && apt install -y systemd # enable networkd and netplan apt install -y nplan cat < /etc/netplan/nplan.yaml network: version: 2 ethernets: all-en: match: name: "en*" dhcp4: true all-eth: match: name: "eth*" dhcp4: true EOF sed -i.orig -e 's/^source/# source/' /etc/network/interfaces netplan generate # make sure cloud-init.service uses networkd sed -i.orig -e '/After=networking.service/a After=systemd-networkd-wait-online.service' /lib/systemd/system/cloud-init.service reboot # check that the order of execution with: journalctl -o short-precise --unit resolvconf.service --unit network-online.target --unit systemd-networkd-wait-online.service --unit systemd-networkd-resolvconf-update.service # the order should be: 1. resolvconf: systemd[1]: Started Nameserver information manager. 2. systemd-networkd-wait-online.service: systemd[1]: Starting Wait for Network to be Configured... 3. systemd-networkd-resolvconf-update.service: systemd[1]: Started Update resolvconf for networkd DNS. 4. network-online.target: systemd[1]: Reached target Network is Online. === BAD OUTPUT === On a failing system, Reached target Network is Online occurs before (1, 2, or 3) above, like this output: Dec 15 19:18:15.233443 x4 systemd[1]: Started Nameserver information manager. Dec 15 19:18:15.797857 x4 systemd[1]: Starting Wait for Network to be Configured... Dec 15 19:18:15.799573 x4 systemd-networkd-wait-online[145]: ignoring: lo Dec 15 19:18:15.804949 x4 systemd-networkd-wait-online[145]: ignoring: lo Dec 15 19:18:15.805079 x4 systemd-networkd-wait-online[145]: ignoring: lo Dec 15 19:18:29.100305 x4 systemd[1]: Starting Update resolvconf for networkd DNS... Dec 15 19:18:29.101870 x4 systemd[1]: Started Wait for Network to be Configured. Dec 15 19:18:29.102144 x4 systemd[1]: Reached target Network is Online. Dec 15 19:18:29.212842 x4 systemd[1]: Started Update resolvconf for networkd DNS. === GOOD OUTPUT === On a passing system, Reached target Network is Online occurs after 1, 2, and 3. Dec 15 19:28:42.548545 x4 systemd[1]: Started Nameserver information manager. Dec 15 19:28:43.144389 x4 systemd[1]: Starting Wait for Network to be Configured... Dec 15 19:28:43.146155 x4 systemd-networkd-wait-online[145]: ignoring: lo Dec 15 19:28:56.081487 x4 systemd[1]: Started Wait for Network to be Configured. Dec 15 19:28:56.100353 x4 systemd[1]: Starting Update resolvconf for networkd DNS... Dec 15 19:28:56.124005 x4 systemd[1]: Started Update resolvconf for networkd DNS. Dec 15 19:28:56.124555 x4 systemd[1]: Reached target Network is Online. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1649931/+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 1850540] Re: multi-zone raid0 corruption
** Changed in: mdadm (Debian) 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/1850540 Title: multi-zone raid0 corruption Status in Release Notes for Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in mdadm package in Ubuntu: Confirmed Status in linux source package in Precise: New Status in mdadm source package in Precise: New Status in linux source package in Trusty: Confirmed Status in mdadm source package in Trusty: Confirmed Status in linux source package in Xenial: Confirmed Status in mdadm source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in mdadm source package in Bionic: Confirmed Status in linux source package in Disco: Confirmed Status in mdadm source package in Disco: Confirmed Status in linux source package in Eoan: Confirmed Status in mdadm source package in Eoan: Confirmed Status in linux source package in Focal: Confirmed Status in mdadm source package in Focal: Confirmed Status in mdadm package in Debian: Fix Released Bug description: Bug 1849682 tracks the temporarily revert of the fix for this issue, while this bug tracks the re-application of that fix once we have a full solution. Fix checklist: [ ] Restore c84a1372df929 md/raid0: avoid RAID0 data corruption due to layout confusion. [ ] Also apply these fixes: 33f2c35a54dfd md: add feature flag MD_FEATURE_RAID0_LAYOUT 3874d73e06c9b md/raid0: fix warning message for parameter default_layout [ ] If upstream, include https://marc.info/?l=linux-raid=157239231220119=2 [ ] mdadm update (see Comment #2) [ ] Packaging work to detect/aide admin before reboot Users of RAID0 arrays are susceptible to a corruption issue if: - The members of the RAID array are not all the same size[*] - Data has been written to the array while running kernels < 3.14 *and* >= 3.14. This is because of an change in v3.14 that accidentally changed how data was written - as described in the upstream commit message: https://github.com/torvalds/linux/commit/c84a1372df929033cb1a0441fb57bd3932f39ac9 That change has been applied to stable, but we reverted it to fix 1849682 until we have a full solution ready. To summarize, upstream is dealing with this by adding a versioned layout in v5.4, and that is being backported to stable kernels - which is why we're now seeing it. Layout version 1 is the pre-3.14 layout, version 2 is post 3.14. Mixing version 1 & version 2 layouts can cause corruption. However, until an mdadm exists that is able to set a layout in the array, there's no way for the kernel to know which version(s) was used to write the existing data. This undefined mode is considered "Version 0", and the kernel will now refuse to start these arrays w/o user intervention. The user experience is pretty awful here. A user upgrades to the next SRU and all of a sudden their system stops at an (initramfs) prompt. A clueful user can spot something like the following in dmesg: Here's the message which , as you can see from the log in Comment #1, is hidden in a ton of other messages: [ 72.720232] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting [ 72.728149] md/raid0: please set raid.default_layout to 1 or 2 [ 72.733979] md: pers->run() failed ... mdadm: failed to start array /dev/md0: Unknown error 524 What that is trying to say is that you should determine if your data - specifically the data toward the end of your array - was most likely written with a pre-3.14 or post-3.14 kernel. Based on that, reboot with the kernel parameter raid0.default_layout=1 or raid0.default_layout=2 on the kernel command line. And note it should be *raid0.default_layout* not *raid.default_layout* as the message says - a fix for that message is now queued for stable: https://github.com/torvalds/linux/commit/3874d73e06c9b9dc15de0b7382fc223986d75571) IMHO, we should work with upstream to create a web page that clearly walks the user through this process, and update the error message to point to that page. I'd also like to see if we can detect this problem *before* the user reboots (debconf?) and help the user fix things. e.g. "We detected that you have RAID0 arrays that maybe susceptible to a corruption problem", guide the user to choosing a layout, and update the mdadm initramfs hook to poke the answer in via sysfs before starting the array on reboot. Note that it also seems like we should investigate backporting this to < 3.14 kernels. Imagine a user switching between the trusty HWE kernel and the GA kernel. References from users of other distros: https://blog.icod.de/2019/10/10/caution-kernel-5-3-4-and-raid0-default_layout/
[Group.of.nepali.translators] [Bug 1842701] Re: Apache2 Balancer Manager mod_proxy_balancer not working after Update
** Changed in: apache2 (Debian)
Status: Fix Committed => 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/1842701
Title:
Apache2 Balancer Manager mod_proxy_balancer not working after Update
Status in Apache2 Web Server:
Confirmed
Status in apache2 package in Ubuntu:
Confirmed
Status in apache2 source package in Xenial:
Fix Released
Status in apache2 source package in Bionic:
Fix Released
Status in apache2 source package in Disco:
Fix Released
Status in apache2 package in Debian:
Fix Released
Bug description:
OS
Description:Ubuntu 18.04.3 LTS
Release:18.04
Codename: bionic
I use this kind of configuration to reache the Balancer Manager.
-
|Bastian Host |
|Apache Proxy | ---> LB Apache Balancer Manger
-
After Apache Update
from: 2.4.29-1ubuntu4.8
to: 2.4.29-1ubuntu4.10
The Balancer Manager behind a Proxy is not Working and i think this is
comming with
the fix CVE-2019-10092
https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2019-10092
http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.4.29-1ubuntu4.10/changelog
I strip down the configuration to try and explain the situation.
Install new Ubuntu 18.04 VirtualBox. From an another VM i saved the prior
Apache Packages from /var/cache/apt/archives
:~# apt-get install libapr1 libaprutil1 libaprutil1-dbd-sqlite3
libaprutil1-ldap liblua5.2-0
:~# dpkg -i apache2_2.4.29-1ubuntu4.8_amd64.deb
apache2-bin_2.4.29-1ubuntu4.8_amd64.deb apache2-data_2.4.29-1ubuntu4.8_all.deb
apache2-utils_2.4.29-1ubuntu4.8_amd64.deb
:~# dpkg -l | grep apache2
ii apache2 2.4.29-1ubuntu4.8 amd64Apache HTTP Server
ii apache2-bin 2.4.29-1ubuntu4.8 amd64Apache HTTP Server
(modules and other binary files)
ii apache2-data 2.4.29-1ubuntu4.8 all Apache HTTP Server
(common files)
ii apache2-utils2.4.29-1ubuntu4.8 amd64Apache HTTP Server
(utility programs for web servers)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
:~# vim /etc/apache2/sites-available/management.conf
Servername 127.0.0.1
ServerAdmin root@localhost
SetHandler balancer-manager
Require local
#Require ip 192.168.56.0/24 127.0.0.1/24
Require all granted
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/management_error.log
CustomLog ${APACHE_LOG_DIR}/management_access.log combined
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
:~# vim /etc/apache2/sites-available/proxytest.conf
BalancerMember "http://192.168.168.130/test;
BalancerMember "http://192.168.168.131/test; status=+H
ProxySet lbmethod=bybusyness
ServerAdmin root@localhost
ServerName testapp01
ServerAlias 127.0.0.1:8100
ProxyPass "/test" "balancer://test"
ProxyPassReverse"/test" "balancer://test"
CustomLog ${APACHE_LOG_DIR}/test-access.log combined
ErrorLog ${APACHE_LOG_DIR}/test-error.log
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
:~# a2enmod proxy_balancer proxy_http lbmethod_bybusyness lbmethod_byrequests
:~# a2ensite management proxytest
:~# vim /etc/apache2/ports.conf
[...]
Listen 81
Listen 8100
:~# systemctl restart apache2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
At that point i install also some console Browsers for testing.
:~# apt-get install lynx elinks
:~# tail -f /var/log/apache2/management_error.log
:~# elinks 127.0.0.1:81/balancer-manager
:~# lynx 127.0.0.1:81/balancer-manager
i can do update the Load and made changes. i also connect from outside with
Firefox
http://192.168.56.211:81/balancer-manager
all this creates no error log entrys, the log is still empty
-
update apache
:~# apt-get update
:~# apt-get upgrade
:~# dpkg -l | grep apache2
ii apache22.4.29-1ubuntu4.10 amd64Apache HTTP Server
ii apache2-bin2.4.29-1ubuntu4.10 amd64Apache HTTP Server
(modules and other binary files)
ii apache2-data 2.4.29-1ubuntu4.10 all Apache HTTP Server
(common files)
ii apache2-utils 2.4.29-1ubuntu4.10 amd64Apache HTTP Server
(utility programs for web servers)
do the same with all the Browsers and have the error log in view.
http://192.168.56.211:81/balancer-manager
:~# tail -f /var/log/apache2/management_error.log
[Wed Sep 04 12:24:55.740457 2019]
[Group.of.nepali.translators] [Bug 1834494] Re: latest bzip2 reports crc errors incorrectly
** Changed in: bzip2 (Debian) Status: Confirmed => 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/1834494 Title: latest bzip2 reports crc errors incorrectly Status in bzip2: Fix Released Status in bzip2 package in Ubuntu: In Progress Status in bzip2 source package in Xenial: Fix Released Status in bzip2 source package in Bionic: Fix Released Status in bzip2 source package in Cosmic: Fix Released Status in bzip2 source package in Disco: Fix Released Status in bzip2 package in Debian: Fix Released Bug description: I just got the bzip2 1.0.6-8.1ubuntu0.1 updates pushed to my machine and am now having problems with some .tbz2 archives. In particular, I can no longer extract this one: https://developer.nvidia.com/embedded/dlc/l4t-jetson-xavier-driver- package-31-1-0 Downloading this and running: bunzip2 -tvv Jetson_Linux_R31.1.0_aarch64.tbz2 ...yields a CRC error. The previous version of bunzip2 does not report any errors with this archive. To manage notifications about this bug go to: https://bugs.launchpad.net/bzip2/+bug/1834494/+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 1372284] Re: nagios3 + livestatus: SIGSEGV everyday at midnight
** Changed in: check-mk (Debian) 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/1372284 Title: nagios3 + livestatus: SIGSEGV everyday at midnight Status in check-mk package in Ubuntu: Fix Released Status in check-mk source package in Trusty: Fix Released Status in check-mk source package in Xenial: Fix Released Status in check-mk source package in Yakkety: Fix Released Status in check-mk source package in Zesty: Fix Released Status in check-mk package in Debian: Fix Released Bug description: [Impact] - Ubuntu 14.04, 16.04, 16.10, and 17.04 Nagios goes down everyday at midnight with livestatus enabled and downtime configured. Here are bug reports in other trackers: https://bugzilla.redhat.com/show_bug.cgi?id=1083003 http://tracker.nagios.org/view.php?id=516 http://tracker.nagios.org/view.php?id=455 People say this patch helps: http://git.mathias-kettner.de/git/?p=omd.git;a=blob;f=packages/nagios/patches/0007-fix_downtime_struct.dif;h=af0e245b585e78c372a69d10c5e3b47ab64ad510;hb=HEAD [Test Case] * Enable check-mk-livestatus plugin (add broker_module=/usr/lib/check_mk/livestatus.o /var/lib/nagios3/livestatus/socket to nagios3/nagios.cfg) * Wait for log rotation (or update log_rotation_method in nagios3/nagios.cfg to rotate hourly so it happens more often) * Without the fix, nagios segfaults, entry in /var/log/nagios3/nagios.log as follows: | [1486857600] Caught SIGSEGV, shutting down... * With the fix, nagios logrotation succeeds and rotated logs present in /var/log/nagios3/archives. [Regression Potential] Nagios will continue to segfault during logrotation. [Other Info] check-mk ships out a different version of nagios/downtime.h which differs from nagios3's downtime.h (defined struct scheduled_downtime_struct differs between the two). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/check-mk/+bug/1372284/+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 1821343] Re: slapd process failure is not detected by systemd
** Changed in: openldap (Debian) 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Fix Released Status in openldap source package in Bionic: Fix Released Status in openldap source package in Cosmic: Fix Released Status in openldap package in Debian: Fix Released Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) 6) Check if systemd has loaded both /run/systemd/generator.late/slapd.service & /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf $ systemctl cat slapd [Regression Potential] The regression potential for this fix should be very low, if we keep the new systemd unit file close to the one generated by systemd-sysv-generator(8). The only significant change would be the RemainAfterExit directive, and this should make the slapd service behave like a "normal" forking service. Nonetheless, we'll perform scripted test runs to make sure no regressions arise. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1831448] Re: adcli: not adding an additional service-name
** Changed in: adcli (Debian) 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/1831448 Title: adcli: not adding an additional service-name Status in adcli package in Ubuntu: New Status in adcli source package in Xenial: New Status in adcli source package in Bionic: New Status in adcli source package in Disco: New Status in adcli source package in Eoan: New Status in adcli package in CentOS: Unknown Status in adcli package in Debian: Fix Released Bug description: I'm trying to add service principals to my computer in an Active Directory environment. The command runs without errors but the computer account attribute "servicePrincipalName" in AD is not changed. The man page says - --service-name=service Additional service name for a Kerberos principal to be created on the computer account. This option may be specified multiple times. -- I've tried this by adcli -v update --service-name=nfs -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details and got * Found realm in keytab: DOMAIN * Found service principal in keytab: host/m15015-lin.DOMAIN * Found host qualified name in keytab: host/m15015-lin.DOMAIN * Found service principal in keytab: host/M15015-LIN * Found computer name in keytab: M15015-LIN * Found service principal in keytab: host/m15015-lin * Using domain name: DOMAIN * Calculated computer account name from fqdn: M15015-LIN * Using domain realm: DOMAIN * Discovering domain controllers: _ldap._tcp.DOMAIN * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.x.X * Received NetLogon info from: WinDC3.DOMAIN * Wrote out krb5.conf snippet to /tmp/adcli-krb5-Q9bim6/krb5.d/adcli-krb5-conf-ZzF3Xh * Looked up short domain name: DOMAIN * Using fully qualified name: m15015-lin * Using domain name: DOMAIN * Using computer account name: M15015-LIN * Using domain realm: DOMAIN * Using fully qualified name: m15015-lin.DOMAIN * Enrolling computer name: M15015-LIN * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for M15015-LIN$ at: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Retrieved kvno '2' for computer account in directory: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Password not too old, no change needed * Modifying computer account: userAccountControl * Modifying computer account: operatingSystem * Modifying computer account: userPrincipalName The errorcode is 0. The cmd line --service-name is not working or do I use the wrong argument? --service-name="nfs/HOSTNAME" is not working too. However, my AD and kerberos configuration is working and so other updates to the computer account in AD are working like: adcli -v update --os-version=19.04 -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details This updates the attribute "operatingSystemVersion" for the computer account in AD. --- Ubuntu 19.04 adcli 0.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1831448/+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 1634496] Re: proc_keys_show crash when reading /proc/keys
** Changed in: linux Status: Confirmed => 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/1634496 Title: proc_keys_show crash when reading /proc/keys Status in Linux: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux source package in Trusty: Fix Released Status in linux source package in Vivid: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: Running stress-ng /proc test trips the following crash: [ 5315.044206] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 8956b1ae [ 5315.044206] [ 5315.044883] CPU: 0 PID: 4820 Comm: Tainted: P OE 4.8.0-25-generic #27-Ubuntu [ 5315.045361] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014 [ 5315.045911] 0086 b337622b 8fe574f37c78 8962f5d2 [ 5315.046371] b3405b00 89e83530 8fe574f37d00 8939e71c [ 5315.046841] 8fe50010 8fe574f37d10 8fe574f37ca8 b337622b [ 5315.047305] Call Trace: [ 5315.047457] [] dump_stack+0x63/0x81 [ 5315.047763] [] panic+0xe4/0x226 [ 5315.048049] [] ? proc_keys_show+0x3ce/0x3d0 [ 5315.048398] [] __stack_chk_fail+0x19/0x30 [ 5315.048735] [] proc_keys_show+0x3ce/0x3d0 [ 5315.049072] [] ? key_validate+0x50/0x50 [ 5315.049396] [] ? key_default_cmp+0x20/0x20 [ 5315.049737] [] seq_read+0x102/0x3c0 [ 5315.050042] [] proc_reg_read+0x42/0x70 [ 5315.050363] [] __vfs_read+0x18/0x40 [ 5315.050674] [] vfs_read+0x96/0x130 [ 5315.050977] [] SyS_read+0x55/0xc0 [ 5315.051275] [] entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 5315.051735] Kernel Offset: 0x820 from 0x8100 (relocation range: 0x8000-0xbfff) [ 5315.052563] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 8956b1ae [ 5315.052563] "The proc_keys_show function in security/keys/proc.c in the Linux kernel through 4.8.2, when the GNU Compiler Collection (gcc) stack protector is enabled, uses an incorrect buffer size for certain timeout data, which allows local users to cause a denial of service (stack memory corruption and panic) by reading the /proc/keys file." Fix detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=1373966 see: https://bugzilla.redhat.com/attachment.cgi?id=1200212=diff To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1634496/+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 1825010] Re: [sru] Update sosreport to 3.8
** Changed in: sosreport (Debian) 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/1825010 Title: [sru] Update sosreport to 3.8 Status in sosreport package in Ubuntu: New Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Cosmic: New Status in sosreport source package in Disco: New Status in sosreport source package in Eoan: In Progress Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.8 has been released including further enhancements in core sosreport functionality: https://github.com/sosreport/sos/releases/tag/3.8 It would be great to find sosreport v3.8 in supported stable releases, considering the fact that the release (especially LTSes) will be supported for a couple of years still: sosreport is widely use by Canonical support team to troubleshoot UA customer, other vendors and community users. These improvement will benefit all of them. sosreport 3.8 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub, zfs,...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. It creates a files under /tmp in the form of : /tmp/sosreport-sos37xenial-20190416160152.tar.xz # Actual sosreport /tmp/sosreport-sos37X-20190416160152.tar.xz.md5 # MD5 checksum Only accessible by root user: -rw--- 1 root root 1619000 Apr 16 16:07 /tmp/sosreport-sos37X-20190416160152.tar.xz Ideally, since we can't test all plugins, it would be good to have a few testers using different HW, kernel, installation with a focus on juju, MAAS, LXD, canonical-livepatch, Looking for any error on the terminal while sosreport is running or post-sosreport run in /tmp/sosreport-*/sos_logs/ [Regression Potential] * Risk is low. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would just be impossible but we have tested the ones we considered important and Ubuntu/Canonical related (canonical-livepatch, MAAS, juju, snappy), Openstack, mandatory file (logs, dmidecode, installed-debs and so on) * Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't (or partially) collect information. [Other information] * Release note: https://github.com/sosreport/sos/releases/tag/3.8 * Plugins: sosreport contains in total: 284 plugins - 185 plugins that used UbuntuPlugin and/or DebianPlugin that might been triggered at sosreport run. - 97 plugins not using UbuntuPlugin and/or DebianPlugin. Basically useless in a Ubuntu context. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1825010/+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 1567557] Re: Performance degradation of "zfs clone"
** Changed in: zfs 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/1567557 Title: Performance degradation of "zfs clone" Status in Native ZFS for Linux: Fix Released Status in zfs-linux package in Ubuntu: Fix Released Status in zfs-linux source package in Xenial: Fix Released Status in zfs-linux source package in Zesty: Fix Released Status in zfs-linux source package in Artful: Fix Released Bug description: [SRU Justification] Creating tens of hundreds of clones can be prohibitively slow. The underlying mechanism to gather clone information is using a 16K buffer which limits performance. Also, the initial assumption is to pass in zero sized buffer to the underlying ioctl() to get an idea of the size of the buffer required to fetch information back to userspace. If we bump the initial buffer to a larger size then we reduce the need for two ioctl calls which improves performance. [Fix] Bump initial buffer size from 16K to 256K [Regression Potential] This is minimal as this is just a tweak in the initial buffer size and larger sizes are handled correctly by ZFS since they are normally used on the second ioctl() call once we have established the size of the buffer required from the first ioctl() call. Larger initial buffers just remove the need for the initial size estimation for most cases where the number of clones is less than ~5000. There is a risk that a larger buffer size could lead to a ENOMEM issue when allocating the buffer, but the size of buffer used is still trivial for modern large 64 bit servers running ZFS. [Test case] Create 4000 clones. With the fix this takes 35-40% less time than without the fix. See the example test.sh script as an example of how to create this many clones. -- I've been running some scale tests for LXD and what I've noticed is that "zfs clone" gets slower and slower as the zfs filesystem is getting busier. It feels like "zfs clone" requires some kind of pool-wide lock or something and so needs for all operations to complete before it can clone a new filesystem. A basic LXD scale test with btrfs vs zfs shows what I mean, see below for the reports. The test is run on a completely dedicated physical server with the pool on a dedicated SSD, the exact same machine and SSD was used for the btrfs test. The zfs filesystem is configured with those settings: - relatime=on - sync=disabled - xattr=sa So it shouldn't be related to pending sync() calls... The workload in this case is ultimately 1024 containers running busybox as their init system and udhcpc grabbing an IP. The problem gets significantly worse if spawning busier containers, say a full Ubuntu system. === zfs === root@edfu:~# /home/ubuntu/lxd-benchmark spawn --count=1024 --image=images:alpine/edge/amd64 --privileged=true Test environment: Server backend: lxd Server version: 2.0.0.rc8 Kernel: Linux Kernel architecture: x86_64 Kernel version: 4.4.0-16-generic Storage backend: zfs Storage version: 5 Container backend: lxc Container version: 2.0.0.rc15 Test variables: Container count: 1024 Container mode: privileged Image: images:alpine/edge/amd64 Batches: 128 Batch size: 8 Remainder: 0 [Apr 3 06:42:51.170] Importing image into local store: 64192037277800298d8c19473c055868e0288b039349b1c6579971fe99fdbac7 [Apr 3 06:42:52.657] Starting the test [Apr 3 06:42:53.994] Started 8 containers in 1.336s [Apr 3 06:42:55.521] Started 16 containers in 2.864s [Apr 3 06:42:58.632] Started 32 containers in 5.975s [Apr 3 06:43:05.399] Started 64 containers in 12.742s [Apr 3 06:43:20.343] Started 128 containers in 27.686s [Apr 3 06:43:57.269] Started 256 containers in 64.612s [Apr 3 06:46:09.112] Started 512 containers in 196.455s [Apr 3 06:58:19.309] Started 1024 containers in 926.652s [Apr 3 06:58:19.309] Test completed in 926.652s === btrfs === Test environment: Server backend: lxd Server version: 2.0.0.rc8 Kernel: Linux Kernel architecture: x86_64 Kernel version: 4.4.0-16-generic Storage backend: btrfs Storage version: 4.4 Container backend: lxc Container version: 2.0.0.rc15 Test variables: Container count: 1024 Container mode: privileged Image: images:alpine/edge/amd64 Batches: 128 Batch size: 8 Remainder: 0 [Apr 3 07:42:12.053] Importing image into local store: 64192037277800298d8c19473c055868e0288b039349b1c6579971fe99fdbac7 [Apr 3 07:42:13.351] Starting the test [Apr 3 07:42:14.793] Started 8 containers in 1.442s [Apr 3 07:42:16.495] Started 16 containers in 3.144s [Apr 3 07:42:19.881] Started 32 containers in
[Group.of.nepali.translators] [Bug 1602813] Re: openvpn-auth-ldap causing segfault on network timeout
** Changed in: openvpn-auth-ldap (Debian) 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/1602813 Title: openvpn-auth-ldap causing segfault on network timeout Status in openvpn-auth-ldap package in Ubuntu: Fix Released Status in openvpn-auth-ldap source package in Trusty: Fix Released Status in openvpn-auth-ldap source package in Xenial: Fix Released Status in openvpn-auth-ldap source package in Yakkety: Won't Fix Status in openvpn-auth-ldap source package in Zesty: Fix Released Status in openvpn-auth-ldap package in Debian: Fix Released Bug description: [Impact] There is a timeout bug in the openvpn-auth-ldap package that causes OpenVPN to crash when the network timeout is exceeded. The openvpn-auth-ldap plugin is not correctly checking the error codes from ldap_result. As a result, it is not catching timeouts, and proceeds as if ldap_result was successful. This results in a segfault when access to the result (which is set to Null) is attempted. Network timeouts are somewhat common and services should be resilient to it. Having a service as a whole crash because of such an occurrence is not acceptable. This upload fixes the problem by simply including the timeout error case in an existing check. It was clearly just an oversight in that one call, as the remainder of the code does handle timeout errors. It was just never reached. [Test Case] To reproduce the problem in an openvpn server: * install openvpn and openvpn-auth-ldap: $ sudo apt install openvpn openvpn-auth-ldap * expand the attached openvpn-test-server.tar.gz tarball inside /etc: $ sudo tar -C /etc -xzf openvpn-test-server.tar.gz * start nc on port 389: $ sudo nc -l -p 389 * In another terminal, start the openvpn server: $ cd /etc/openvpn $ sudo openvpn --config server.conf Next you will need an openvpn client, also configured with the SSL certs as usual, plus "auth-user-pass". This client can be the same for all server tests, if you are testing multiple Ubuntu releases, since what crashes is the server. It also doesn't have to be the fixed package from proposed. * Install openvpn: $ sudo apt install openvpn * Expand the client tarball in /etc: $ sudo tar -C /etc -xzf openvpn-test-client.tar.gz * Edit /etc/openvpn/client.conf and change the "remote " line to point to your openvpn server's hostname * Start the client: $ cd /etc/openvpn $ sudo openvpn --config client.conf * It will prompt you for username and password. The values you provide are irrelevant: (...) Enter Auth Username: asd Enter Auth Password: *** The vulnerable server will crash: root@trusty-openvpn-1602813:/etc/openvpn$ sudo openvpn --config server.conf Tue Jun 20 13:56:55 2017 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014 Tue Jun 20 13:56:55 2017 TUN/TAP device tun0 opened Tue Jun 20 13:56:55 2017 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1) Tue Jun 20 13:56:55 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Tue Jun 20 13:56:55 2017 /sbin/ip link set dev tun0 up mtu 1500 Tue Jun 20 13:56:55 2017 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2 Tue Jun 20 13:56:55 2017 UDPv4 link local (bound): [undef] Tue Jun 20 13:56:55 2017 UDPv4 link remote: [undef] Tue Jun 20 13:56:55 2017 Initialization Sequence Completed openvpn: sasl.c:257: ldap_parse_sasl_bind_result: Assertion `res != ((void *)0)' failed. Aborted (core dumped) The fixed version will just complain about a timeout error and remain running: (...) LDAP bind failed: Timed out Unable to bind as uid=john,ou=People,dc=lxd LDAP connect failed. Tue Jun 20 15:55:51 2017 10.0.100.162:1194 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-ldap.so Tue Jun 20 15:55:51 2017 10.0.100.162:1194 TLS Auth Error: Auth Username/Password verification failed for peer Tue Jun 20 15:55:51 2017 10.0.100.162:1194 [client] Peer Connection Initiated with [AF_INET]10.0.100.162:1194 [Regression Potential] The patch is very focused. I believe the biggest regression potential lies in the fact that this package hasn't been rebuilt very often. This new build will be done with the surrounding system libraries having changed a lot since the last time this package was built. [Other Info] There are two places in the code which mishandled the return code of ldap_result(). They are essentially identical, but the test case I provided only covers one of them. I believe that to be good enough, as the other code path will require setting up an LDAP server with a populated directory. To manage notifications about this
[Group.of.nepali.translators] [Bug 1574849] Re: plain http://paste.ubuntu.com has stopped working while https works
** Changed in: pastebinit (Debian) 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/1574849 Title: plain http://paste.ubuntu.com has stopped working while https works Status in pastebinit: New Status in pastebinit package in Ubuntu: Fix Released Status in pastebinit source package in Xenial: Confirmed Status in pastebinit package in Debian: Fix Released Bug description: The URL shown in the manpage was not updated in 1.5-1 (add https support. Closes: #799580, closes: #708206.) When a user with an existing ~/.pastebinit.xml tries with a URL of http://paste.ubuntu.com or a user creates a config file per the manpage they will get the following error: Unknown website, please post a bugreport to request this pastebin to be added (http://paste.ubuntu.com) To manage notifications about this bug go to: https://bugs.launchpad.net/pastebinit/+bug/1574849/+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 1830479] Re: testcases expect first kernel log line, but not always in logs
** Changed in: systemd (Debian) Status: Fix Committed => 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/1830479 Title: testcases expect first kernel log line, but not always in logs Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: Won't Fix Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: Won't Fix Status in systemd source package in Eoan: Won't Fix Status in systemd package in Debian: Fix Released Bug description: [impact] boot-and-services and cmdline-upstart-boot expect the first(ish) kernel log line to be in the system logs, but that is not guaranteed to be in the logs. [test case] run autopkgtest on arm64 with the current kernel, whose kernel log size is too small for journald or rsyslogd to capture the first kernel log messages. [regression potential] low; testcase fix only. [other info] the specific cause of this currently is too-small kernel log buffer size on arm64, which is being fixed in bug 1824864, but increasing amounts of boot time logging may cause a failure again, or custom kernel configs with small log buffers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830479/+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 1540008] Re: USB permissions not set at install time (udevd name changed?)
** Changed in: nut (Debian) 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/1540008 Title: USB permissions not set at install time (udevd name changed?) Status in nut package in Ubuntu: Fix Released Status in nut source package in Trusty: Fix Released Status in nut source package in Xenial: Fix Released Status in nut source package in Yakkety: Won't Fix Status in nut source package in Zesty: Fix Released Status in nut package in Debian: Fix Released Bug description: [Impact] * Installing nut provides rules to set up the devnodes accordingly, but on an install the trigger to run those is missed to be executed due to an error in postinst. * Fix is a backport from Debian repo (https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/id=d31c6dcb) , which works in artful already [Test Case] * Plug in a usb controlled UPS of your choice * Install nut-server * The device node created should be mode 664 and group "nut", but it is not. * Install the proposed package with the fix * that should trigger the rules to run and it should now be created with proper permissions. * In the lack of special HW there is a fallback * Create a VM and give it some USB device * Start in one console "sudo udevadm monitor" * On installing the nut-server package the USB events should be re-triggered, but they are not yet today - with the fixed package they are. [Regression Potential] * The postinst trigger never worked, now it will work. If on a system the rules fail to execute there might be an issue, but since the are only triggered (async udev) the install will not fail due to that. I think in the worst case they are just still not executed. * Vice versa once they are executed correctly the changed permission could be an issue for odd setups that relied on the broken permission, but I explained in the Regression potential section of bug 1099947 that is released together why I think that is no issue. [Other Info] * n/a 1) $ lsb_release -rd Description: Ubuntu 14.04.3 LTS Release: 14.04 2) nut-server: 2.7.1-1ubuntu1; udev: 204-5ubuntu20.15 3) On a fresh install of Ubuntu 14.04 (amd64), I installed the nut- server package while the UPS was already connected via USB. After installation, the permissions described by /lib/udev/rules.d/52-nut- usbups.rules should have changed the group of the corresponding /dev/bus/usb/*/* node to 'nut'. 4) The owner/group for the /dev/bus/usb node remained root:root. Manually running 'udevadm trigger --subsystem-match=usb --action=change' changed the group to 'nut'. (From past experience tracking down related udev+nut bugs, unplugging and re-plugging the USB cable would yield similar results.) However, that udevadm command is included in the postinst for nut- server, and it is guarded with a pidof check for 'udevd': # ask udev to check for new udev rules [ -x /etc/init.d/udev ] && pidof udevd > /dev/null \ && udevadm trigger --subsystem-match=usb --action=change This most likely needs to be amended to include the current process name, 'systemd-udevd'. I checked the control files, and unless the udevd process name has changed back, I believe this will affect vivid, wily and xenial as well as trusty. (I will let someone else add those later tags if that turns out to be the case.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1540008/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: systemd (Debian) Status: Fix Committed => 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: Fix Released Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Released Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Released Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Released Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Confirmed Status in systemd package in Debian: Fix Released Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions ___ Mailing list: https://launchpad.net/~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 1825250] Re: ethmonitor does not list interfaces without assigned IP address
** Changed in: resource-agents (Debian) 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/1825250 Title: ethmonitor does not list interfaces without assigned IP address Status in resource-agents package in Ubuntu: Fix Released Status in resource-agents source package in Xenial: Fix Released Status in resource-agents source package in Bionic: Fix Released Status in resource-agents source package in Cosmic: Fix Released Status in resource-agents source package in Disco: Fix Released Status in resource-agents source package in Eoan: Fix Released Status in resource-agents package in Debian: Fix Released Bug description: [Impact] Some network interfaces will not be monitored by ethmonitor [Description] The is_interface() function in ethmonitor tries to match an interface to a list obtained from the 'ip' tool. It lists interfaces using the 'inet' family, which omits interfaces that don't have an IP address assigned. If the interface that we're looking for is e.g. a VLAN bridge that does not have an IP address, it won't show up in the listing and is_interface() will return false. ethmonitor will miss that interface, and it won't be available for monitoring. Upstream commits: - https://github.com/ClusterLabs/resource-agents/commit/40d05029ce0b - https://github.com/ClusterLabs/resource-agents/commit/c0ac191c73f1 [Test Case] 1) Ensure there's a network interface without an assigned IP address. For example, virbr0-nic will be created automatically by uvt-kvm: # ip addr show dev virbr0-nic 11: virbr0-nic: mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:e9:5e:af brd ff:ff:ff:ff:ff:ff 2) Install pcs+arping and create a new ethmonitor resource with the target interface: # sudo apt update && sudo apt install pcs arping -y # pcs resource create p_nic ocf:heartbeat:ethmonitor interface=virbr0-nic op monitor timeout="10s" 3) Debug-start ethmonitor resource and check for "Interface does not exist messages" # pcs resource debug-start p_nic Operation start for p_nic (ocf:heartbeat:ethmonitor) returned: 'ok' (0) > stderr: WARNING: Interface virbr0-nic does not exist > stderr: NOTICE: link_status: DOWN [Regression Potential] The regression potential is low, since we are relaxing the monitoring conditions for interfaces without an assigned IP address. The patches have been tested against Travis-CI before being merged upstream, and will be tested against autopkgtest for each target distro. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1825250/+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 1754671] Re: Full-tunnel VPN DNS leakage regression
Launchpad has imported 73 comments from the remote bug at
https://bugzilla.gnome.org/show_bug.cgi?id=746422.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2015-03-18T22:30:03+00:00 Dcbw-y wrote:
If the VPN routes all traffic (eg, its ipv4.never-default=false) that
usually indicates that the VPN's nameservers should be used instead of
the parent interface's nameservers, since the parent interface's
nameservers would be accessed over the VPN anyway (since it's routing
all traffic).
But with dns=dnsmasq, the dnsmasq plugin always does split DNS
regardless of the never-default value of the VPN's IPv4 config:
/* Use split DNS for VPN configs */
for (iter = (GSList *) vpn_configs; iter; iter = g_slist_next (iter)) {
if (NM_IS_IP4_CONFIG (iter->data))
add_ip4_config (conf, NM_IP4_CONFIG (iter->data), TRUE);
else if (NM_IS_IP6_CONFIG (iter->data))
add_ip6_config (conf, NM_IP6_CONFIG (iter->data), TRUE);
}
instead I think that each config should be added with split DNS only if
ipv4.never-default=true for that config. That would ensure that when
the VPN was routing all traffic, split DNS was not used, but when the
VPN was not routing all traffic, split DNS was used.
If the user really does want to use the parent interface's nameservers
even though they will be contacted over the VPN, they can either add
custom dnsmasq options to /etc/NetworkManager/dnsmasq.d or enter them
manually for the connection.
ISTR that the behavior I'm suggesting was always intended, but
apparently we changed that behavior a long time ago and possibly didn't
realize it?
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-
manager/+bug/1754671/comments/0
On 2015-03-19T11:15:43+00:00 Psimerda wrote:
In my opinion it is useful to use split DNS view in all cases and only
use never-default setting to decide the global DNS.
Rationale: There is no such think as sending all traffic across VPN,
only default route traffic, i.e. traffic for which there's no specific
route over a specific interface. As specific routes (as found in the
routing table) are still used even with default route over VPN, I
believe that specific zones (as found in per-connection lists of
domains) should be maintained as well.
Reply at: https://bugs.launchpad.net/ubuntu/+source/network-
manager/+bug/1754671/comments/1
On 2015-03-20T07:58:02+00:00 warthog9 wrote:
Pavel, I'll admit to not 100% following what you've suggested, so please
excuse me if I've horribly miss-understood. I disagree with the
assertion that "There is no such think as sending all traffic across
VPN". The parent interface's adapter will have a local route mainly so
you can get to the gateway, as well as a route for vpn endpoint you need
to push traffic at however, there are some mitigating circumstances that
forcing split-dns, so that the DNS on the VPN is ONLY serving the search
spaces pushed, is actually exactly the opposite of what a user likely
wants and/or causes some rather broken behavior.
- VPNs can, and often do, have IP space overlap issues. So if the
parent interface's network you are on happens to be in the
10.0.0.0/255.255.252.0 (gateway 10.0.0.1, DNS server 10.0.0.2 &
10.0.0.3) ip range, and the VPN uses 10.0.1.0/255.255.255.0, you can end
up in some very screwed up situation. This is actually taken from a
real world scenario (which is why I learned of the change to default to
split DNS at all). If you are routing all traffic over the VPN you now
have lost access to the two parent interface's DNS servers, and with
split DNS you now have *NO* DNS access at all. As it currently stands
the only way to fix this is to either manually edit /etc/resolv.conf or
to restart NM without dnsmasq.
- DNS is not equal at all locations, which your assumption about split
DNS I think assumes. DNS zones mean that something that resolves
externally one way, may resolve completely differently (and
potentially). example.com, to an external resolver may go to a coloed
and public instance, while the same dns entry from an internal dns
server may not. Assuming the VPN only pushes a search of
internal.example.com, but doesn't push a search for example.com (making
the assumption that people will just type it), the internal site is now
unreachable. Keeping in mind I'm talking about VPNs, and those are
typically used in more corporate environments where you are dealing with
corporate IT departments.
- In a more casual environment, lets say a hotel, part of the reasons to
use a VPN is because the
[Group.of.nepali.translators] [Bug 1834494] Re: latest bzip2 reports crc errors incorrectly
** Changed in: bzip2 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/1834494 Title: latest bzip2 reports crc errors incorrectly Status in bzip2: Fix Released Status in bzip2 package in Ubuntu: In Progress Status in bzip2 source package in Xenial: Fix Released Status in bzip2 source package in Bionic: Fix Released Status in bzip2 source package in Cosmic: Fix Released Status in bzip2 source package in Disco: Fix Released Status in bzip2 package in Debian: Confirmed Bug description: I just got the bzip2 1.0.6-8.1ubuntu0.1 updates pushed to my machine and am now having problems with some .tbz2 archives. In particular, I can no longer extract this one: https://developer.nvidia.com/embedded/dlc/l4t-jetson-xavier-driver- package-31-1-0 Downloading this and running: bunzip2 -tvv Jetson_Linux_R31.1.0_aarch64.tbz2 ...yields a CRC error. The previous version of bunzip2 does not report any errors with this archive. To manage notifications about this bug go to: https://bugs.launchpad.net/bzip2/+bug/1834494/+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 1822839] Re: LibreOffice doesn't detect JVM because of unexpected java.vendor property value
** Changed in: libreoffice (Debian) Status: New => Won't Fix -- 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/1822839 Title: LibreOffice doesn't detect JVM because of unexpected java.vendor property value Status in LibreOffice: Fix Released Status in libreoffice package in Ubuntu: Fix Released Status in libreoffice-l10n package in Ubuntu: Fix Released Status in openjdk-lts package in Ubuntu: New Status in libreoffice source package in Xenial: Fix Released Status in libreoffice source package in Bionic: Fix Released Status in libreoffice source package in Disco: Fix Released Status in libreoffice-l10n source package in Disco: Fix Released Status in openjdk-lts source package in Disco: New Status in libreoffice package in Debian: Won't Fix Bug description: [Impact] * A recent OpenJDK update changes the value of the "java.vendor" property from "Oracle Corporation" to "Private Build". This breaks the code in LibreOffice that detects an installed JVM. * The fix is currently in LibreOffice 6.2.3 on eoan. [Test Case] 1. Launch the LibreOffice Start Center 2. Open Tools > Options 3. Navigate to LibreOffice > Advanced 4. A JRE should be listed with Location: /usr/lib/jvm/... [Regression Potential] * This fix is small and concentrated so potential for regression should be relatively low. * A combination of autopkgtests and manual testing as described above should provide reasonable confidence that no regressions sneaked in. To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1822839/+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 1827727] Re: All plugins disabled due to expired cert
** Changed in: firefox Status: Confirmed => 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/1827727 Title: All plugins disabled due to expired cert Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Fix Released Status in firefox source package in Xenial: Fix Released Status in firefox source package in Bionic: Fix Released Status in firefox source package in Cosmic: Fix Released Status in firefox source package in Disco: Fix Released Bug description: See https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 Due to expiration of an intermediate cert, all plugins were disabled. Firefox pushed a fix via 'Studies' option, but this seems to be disabled by default in Ubuntu builds? When this is disabled, no update is getting pushed! Think we need to get a fix into repositories asap :) To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1827727/+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 1598212] Re: /etc/os-release: Please specify VERSION_CODENAME
** Changed in: base-files (Debian) 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/1598212 Title: /etc/os-release: Please specify VERSION_CODENAME Status in base-files package in Ubuntu: Fix Released Status in base-files source package in Xenial: Fix Released Status in base-files package in Debian: Fix Released Bug description: [ SRU Justification ] UBUNTU_CODENAME was added by the snapd team, then proposed upstream in a more generic way. Upstream settled on VERSION_CODENAME, and we should include that as well, in case third party (or, indeed, future versions of our own) software decide to start looking for it. [ SRU Test Case ] Check diffs of both source package and installed os-release, make sure nothing's changed except VERSION_CODENAME, and that the value is correct. [ Regression Potential ] Nein. [ Original Report ] The os-release specification was updated in systemd > 230 to also include a VERSION_CODENAME parameter: https://github.com/systemd/systemd/commit/646b997c118e261c5ececc434dd40d0dbdbac4d8 Please replace the custom UBUNTU_CODENAME parameter by VERSION_CODENAME in yakkety and add VERSION_CODENAME to /etc/os- release to all stable releases. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1598212/+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 1754584] Re: zfs system process hung on container stop/delete
** Changed in: zfs 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/1754584 Title: zfs system process hung on container stop/delete Status in Native ZFS for Linux: Fix Released Status in linux package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in zfs-linux source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in zfs-linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Status in zfs-linux source package in Bionic: Fix Released Bug description: == SRU Request [Xenial][Artful] == == Justification == It is possible to hang zfs asynchronous reads if a read to a page that is mmap'd onto the the file being read is the same offset in the mapping as in the file. This is caused by two lock operations on the page. == Fix == Upstream ZFS fix to ensure the page is not double-locked during async I/O of one or more pages. == Testing == Create a zfs pool + zfs file system, run the reproducer program in comment #28 on the zfs filesystem. Without the fix this can lock up, with the fix this runs to completion. == Regression Potential == Minimal, the locking fix addresses a fundamental bug in the locking and this should not affect ZFS read/write I/O with this fix. -- Summary: On a Bionic system running 4.15.0-10-generic, after attempting to build libaio in a Bionic daily container I cannot stop or delete the container. dmesg shows a variety of hung tasks Steps to Reproduce: Use the following script and watch for the the hang. At that point attempt to stop or delete the container: http://paste.ubuntu.com/p/SxfgbxM8v7/ Originally filed against LXD: https://github.com/lxc/lxd/issues/4314 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-image-4.15.0-10-generic 4.15.0-10.11 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: powersj2414 F pulseaudio /dev/snd/controlC0: powersj2414 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Fri Mar 9 09:19:11 2018 HibernationDevice: RESUME=UUID=40a4eb28-4454-44f0-a377-ea611ce685bb InstallationDate: Installed on 2018-02-19 (17 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) Lsusb: Bus 001 Device 002: ID 8087:8001 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 04f2:b45d Chicony Electronics Co., Ltd Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20BSCTO1WW ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-10-generic root=/dev/mapper/ubuntu--vg-root ro RelatedPackageVersions: linux-restricted-modules-4.15.0-10-generic N/A linux-backports-modules-4.15.0-10-generic N/A linux-firmware 1.172 RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/13/2017 dmi.bios.vendor: LENOVO dmi.bios.version: N14ET42W (1.20 ) dmi.board.asset.tag: Not Available dmi.board.name: 20BSCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0E50512 STD dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN14ET42W(1.20):bd09/13/2017:svnLENOVO:pn20BSCTO1WW:pvrThinkPadX1Carbon3rd:rvnLENOVO:rn20BSCTO1WW:rvrSDK0E50512STD:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 3rd dmi.product.name: 20BSCTO1WW dmi.product.version: ThinkPad X1 Carbon 3rd dmi.sys.vendor: LENOVO --- ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: powersj1878 F pulseaudio /dev/snd/controlC0: powersj1878 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 18.04 HibernationDevice: RESUME=UUID=40a4eb28-4454-44f0-a377-ea611ce685bb InstallationDate: Installed on 2018-02-19 (17 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) Lsusb: Bus 001 Device 002: ID 8087:8001 Intel Corp.
[Group.of.nepali.translators] [Bug 1600000] Re: libnss-resolve treats two trailing dots on a domain name incorrectly
** Changed in: systemd 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/160 Title: libnss-resolve treats two trailing dots on a domain name incorrectly Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Bug description: [Impact] libnss-resolve is an optional component not used by default in xenial. However it treats doubledot incorrectly, meaning it gets resolved when it shouldn't. [Fix] Cherrypick upstream patch to resolve this issue. [Testcase] * Enable resolve nss module * attempt resolving www.gnu.org.. * It should fail to resolve (base)adconrad@nosferatu:~$ getent ahostsv4 www.gnu.org.. 208.118.235.148 STREAM wildebeest.gnu.org 208.118.235.148 DGRAM 208.118.235.148 RAW (base)adconrad@nosferatu:~$ sudo sed -i -e 's/ resolve dns/ dns/' /etc/nsswitch.conf (base)adconrad@nosferatu:~$ getent ahostsv4 www.gnu.org.. (base)adconrad@nosferatu:~$ sudo sed -i -e 's/ dns/ resolve dns/' /etc/nsswitch.conf (base)adconrad@nosferatu:~$ getent ahostsv4 www.gnu.org.. 208.118.235.148 STREAM wildebeest.gnu.org 208.118.235.148 DGRAM 208.118.235.148 RAW (base)adconrad@nosferatu:~$ This is responsible for the new regression in glibc: -- FAIL: posix/tst-getaddrinfo5 original exit status 1 resolving "localhost." worked, proceeding to test resolving "localhost.." failed, test passed resolving "www.gnu.org." worked, proceeding to test resolving "www.gnu.org.." worked, test failed -- [Regression potential] Minimal, since this component is not used by default. However, systems that have this enabled exhibit standards non-compliant behavior. It is not expected for anybody to depend on this broken behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/160/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records
** Changed in: systemd
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/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in Nextcloud:
Fix Released
Status in systemd:
Fix Released
Status in network-manager package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in network-manager source package in Xenial:
Invalid
Status in systemd source package in Xenial:
Invalid
Status in network-manager source package in Yakkety:
Invalid
Status in systemd source package in Yakkety:
Fix Released
Bug description:
[SRU Justification]
Ubuntu 16.10 server uses systemd-resolved by default, configured both as a
DNS stub resolver on 127.0.0.53 and as an NSS module via libnss-resolved
talking to the dbus service. The DNS stub resolver has a bug that causes it to
fail to resolve CNAME records. This went unnoticed before release because by
default the NSS module is used. But a chroot or container on the system that
does not include libnss-resolved and is configured to use the stub resolver
will experience DNS failures.
[Test case]
1. On a yakkety server system, create a xenial chroot with mk-sbuild (or
equivalent).
2. Make sure that the host system has /etc/resolv.conf pointed at 127.0.0.53.
2. Enter the chroot with 'sudo schroot -c xenial-amd64' or such.
3. Install the iputils-ping package.
4. ping www.freedesktop.org
5. Confirm that the hostname does not resolve.
6. Install the systemd package from yakkety-proposed onto the host system.
7. ping www.freedesktop.org
8. Confirm that the hostname does now resolve.
[Regression potential]
With a 247-line patch to a key service, there is some risk of regression.
Regression risk is mitigated because this patch is already present in zesty and
upstream, where no regressions have been reported, and because it only touches
the DNS stub resolver which is not the code path used by default on host
systems.
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nextcloud-snap/+bug/1647031/+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 1734983] Re: Request to backport sosreport v3.5
** Changed in: sosreport 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/1734983 Title: Request to backport sosreport v3.5 Status in sosreport: Fix Released Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Fix Released Status in sosreport source package in Xenial: Fix Released Status in sosreport source package in Zesty: Won't Fix Status in sosreport source package in Artful: Fix Released Status in sosreport source package in Bionic: Fix Released Status in sosreport package in Debian: New Bug description: [Impact] Canonical support team (AKA STS) largely depend on sosreport package to troubleshoot system. sosreport is always in constant development including new bugfixes, new features such as new plugins[1], that can be interesting to have in a support context. v3.5 is already found in devel release (bionic). We create this LP in the attempt to justify the SRU of v3.5 backport into current supported stable releases. [1] - New plugins for : * perl * boom * vdo * os_net_config * conntrackd * ovirt_imageio * nss * sas3ircu * openstack_aodh * docker_distribution * gluster_block * snappy Plugin API enhancements * Plugin triggers by executable name * Improved log size limit handling * Better handling of compressed log files * Per-plugin package verification lists Updates to 227 plugins This will also allow us to close some sosreport LP bugs: *Docker plugin uses the wrong command for Ubuntu (LP: #1693574) [Test Case] * Install sosreport $ apt-get install sosreport * Run sosreport $ sosreport -a $ sosreport -o $ ... * Make sure it generate a tar.xz file in /tmp in the form of "/tmp/sosreport--.tar.xz" * Extract files from archive $ tar Jxvf /tmp/sosreport--.tar.xz * Look the content of sosreport, make sure the information is accurate and valid, * Make sure all files that should to be collected by sosreport aren't 0 size. (Files that should be collected may varies from one system to another, it depends on what packages are installed, ...) $ find /tmp/sosreport-- -size 0 # Note : It is normal to see some 0 size files here and there, again it depend on how the plugin is run (package detection or not inside the plugins, ...) and if the package is installed or not on the system where you run sosreport. But in most cases, if the package is installed and if sosreport has a plugin for it then it should gather information, if not then it might be a problem with the plugins itself that need adjustments. [Regression Potential] * autopkgtest[2] didn't reveal any [2] - See Comment #1 * We,STS, have intensively tested the package. During our testing, we found a severe regression that we already took action to fix it via : - Upstream issue - https://github.com/sosreport/sos/issues/1155 - Debian bug - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883537 - Fix Released in Ubuntu Devel release (bionic) via debdiff : lp1734983_bionic.debdiff [Other Info] * Sosreport upstream : https://github.com/sosreport/sos * rmadison -u debian,ubuntu sosreport debian: sosreport | 3.2-2| oldstable | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x sosreport | 3.2-2| oldstable-kfreebsd | source, kfreebsd-amd64, kfreebsd-i386 sosreport | 3.3+git50-g3c0349b-2 | stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x sosreport | 3.5-1| testing| source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x sosreport | 3.5-1| unstable | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x ubuntu: sosreport | 3.0-1~ubuntu12.04.1 | precise-backports/universe | source, amd64, armel, armhf, i386, powerpc sosreport | 3.1-1ubuntu2 | trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el sosreport | 3.1-1ubuntu2.2 | trusty-security| source, amd64, arm64, armhf, i386, powerpc, ppc64el sosreport | 3.2-2~ubuntu14.04.1 | trusty-backports | source, amd64, arm64, armhf, i386, powerpc, ppc64el sosreport | 3.2+git276-g7da50d6-3ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x sosreport | 3.3+git50-g3c0349b-2 | zesty
[Group.of.nepali.translators] [Bug 1707015] Re: image composite functions not working in php
** Changed in: imagemagick 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/1707015 Title: image composite functions not working in php Status in ImageMagick: Fix Released Status in imagemagick source package in Trusty: Triaged Status in imagemagick source package in Xenial: Triaged Status in imagemagick package in Debian: New Bug description: We use php-imagick to make image compositions on our servers. On July 25 we got an upgrade of imagemagick, from 6.8.9.9-7ubuntu5.7 to 8:6.8.9.9-7ubuntu5.8. After that upgrade our webservers, using the php imagick bindings, stopped making composites. The composite images just have the background layer showing, with no overlay layer composited on top. In PHP there are no errors or exceptions, and other imagick functions work fine. Reading images, scaling, making new images, rendering to bytes, all work fine. It is only the composite functions, in php bindings, that are not working. I downgraded our webservers to imagemagick 6.8.9.9-7ubuntu5, which is still available in the ubuntu archives, and the php composite functions started working again. 6.8.9.9-7ubuntu5.7 is no longer available in the archives (http://security.ubuntu.com/ubuntu/pool/main/i/imagemagick/). A test script to reproduce the bug is attached to this ticket. On version 6.8.9.9-7ubuntu5 this will show the ubuntu logo over a gray background. On the latest version, 6.8.9.9-7ubuntu5.8, this will show garbled fragments of the ubuntu logo over gray background, or perhaps just an empty gray background. This bug was identified on Ubuntu 16.04.2 LTS as a result of an automatic upgrade from ubuntu security. To manage notifications about this bug go to: https://bugs.launchpad.net/imagemagick/+bug/1707015/+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 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)
** Changed in: ibus 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/1580463 Title: Snap blocks access to system input methods (ibus, fcitx, ...) Status in ibus: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in ibus package in Ubuntu: Fix Released Status in im-config package in Ubuntu: Fix Released Status in snapd package in Ubuntu: Fix Released Status in apparmor source package in Xenial: Fix Released Status in im-config source package in Xenial: Fix Released Status in snapd source package in Xenial: Fix Released Status in apparmor source package in Yakkety: Fix Released Status in im-config source package in Yakkety: Fix Released Status in snapd source package in Yakkety: Fix Released Bug description: = SRU im-config = [Impact] ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has AppArmor mediation, ibus-daemon does not so it is important that its abstract socket not be confused with dbus-daemon's. By modifying ibus-daemon's start arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue mediating DBus abstract sockets like normal and also mediate access to the ibus-daemon-specific abstract socket via unix rules. This also tidies up the abstract socket paths so that it is clear which are for ibus-daemon, which for dbus-daemon, etc. The upload simply adjusts 21_ibus.rc to start ibus-daemon with "-- address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code changes are required. [Test Case] 1. start a unity session before updating to the package in -proposed 2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0 IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76 3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus' ibus-daem 2973 jamie8u unix 0x 0t0 29606 @/tmp/dbus-oxKYpN30 type=STREAM 4. update the package in -proposed and perform '2' and '3'. The IBUS_ADDRESSES should be the same as before 5. logout of unity, then log back in 6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0 IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e (notice '/tmp/ibus/' in the path) 7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus' ibus-daem 3471 jamie8u unix 0x 0t0 26107 @/tmp/ibus/dbus-SpxOl8Fc type=STREAM ... (notice '@/tmp/ibus/' in the path) In addition to the above, you can test for regressions by opening 'System Settings' under the 'gear' icon in the panel and selecting 'Text Entry'. From there, add an input source on the right, make sure 'Show current input source in the menu bar' is checked, then use the input source panel indicator to change input sources. Extended test case to verify input support still works in unconfined and confined applications: 1. Systems Settings Language Support, if prompted install the complete language support 2. Install Chinese (simple and traditional) 3. sudo apt-get install ibus-pinyin ibus-sunpinyin 4. logout / login 5. System Settings / Text Entry - add Chinese (Pinyin) (IBus) 6. select pinyin from the indicator 7. sudo lsof | grep ibus | grep @ # will use @/tmp/dbus-... 8. open gnome-calculator and try to type something in (should get a pop-up) 9. open evince and try to search a pdf (should get a pop up) 10. upgrade apparmor and im-config from xenial-proposed 11. logout and back in 12. sudo lsof | grep ibus | grep @ # will use @/tmp/ibus/... 13. open gnome-calculator and try to type something in (should get a pop-up) 14. open evince and try to search a pdf (should get a pop up) 15. verify no new apparmor denials [Regression Potential] The regression potential is considered low because there are no compiled code changes and because the changes only occur after ibus- daemon is restarted, which is upon session start, not package upgrade. When it is restarted, the files in ~/.config/ibus/bus/*-unix-0 are updated accordingly for other applications to pick up. This change intentionally requires a change to the unity7 snapd interface, which is in already done. This change intentionally requires a change to apparmor to add a unix rule for communicating with the new ibus address. This is in xenial- proposed 2.10.95-0ubuntu2.3 (and 2.10.95-0ubuntu2.4). The packages changes to im-config use 'Breaks: apparmor (<< 2.10.95-0ubuntu2.3) to ensure that the apparmor abstraction is updated and policy recompiled before ibus is restarted. This was omitted from the initial im-config upload which resulted in bug #1588197. Test cases ensuring this is working properly are included
[Group.of.nepali.translators] [Bug 1822270] Re: Debconf readline frontend does not show options
** Changed in: debconf (Debian) Status: Fix Committed => 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/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released Status in debconf source package in Xenial: Confirmed Status in debconf source package in Bionic: Confirmed Status in debconf source package in Cosmic: Confirmed Status in debconf source package in Disco: Confirmed Status in debconf source package in Eoan: Fix Released Status in debconf package in Debian: Fix Released Bug description: [Impact] debconf prompts the user for input before displaying options [Description] When upgrading packages with apt or dpkg, debconf scripts are ran through 'run-parts' with the '--report' flag. This causes script output to be handled through pipes set up by run-parts, and buffers output from maintainer scripts nicely for formatting. If debconf makes use of the readline frontend, any prompts will bypass the run-parts buffers and be displayed directly to /dev/tty. This generally causes the prompt to be displayed before the user gets any of the available options for it, and printing will block until the user inputs a valid option. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [Test Case] 1) Deploy a VM through e.g. uvt-kvm $ uvt-kvm create disco release=disco 2) Remove the whiptail package to force the readline frontend in debconf root@disco:~# apt remove --purge whiptail -y 3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade through run-parts root@disco:~# apt update && apt install -y grub-legacy-ec2 root@disco:~# rm -f /boot/grub/menu.lst* root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst 4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we just need it to think menu.lst needs an upgrade) root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d --report ... /etc/kernel/postinst.d/x-grub-legacy-ec2: debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... What would you like to do about menu.lst? The "What would you like to do about menu.lst?" prompt will block until the user enter a valid option, even though it's being displayed before the available options. [Regression Potential] We could hit regressions if changing debconf's printing to /dev/tty is expected by other programs. The changes are needed only in the readline frontend, so that would minimize impact of any possible regressions. The fixes will be thoroughly tested with autopkgtest and use-case scenarios. # # # # [Original Description] When upgrading the kernel on a recent Bionic minimal image, the user is prompted to resolve a conflict in the file /boot/grub/menu.lst. The minimal images do not have dialog/whiptail installed, so debconf falls back to using the readline frontend. The user sees the prompt: "What would you like to do about menu.lst?" but is not presented with the list of options to choose from. If a valid option is typed in, debconf will continue processing correctly and the list of options appears on the screen. See also https://pastebin.ubuntu.com/p/8xvSn88SKG/ STEPS TO REPRODUCE: Launch the minimal Bionic image with serial 20190212 http://cloud- images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04 -minimal-cloudimg-amd64.img for example via multipass and run `apt-get update` and `apt-get dist- upgrade`. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1827391] Re: Japanese era Reiwa SRU
** Changed in: icu (Debian) Status: Confirmed => 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/1827391 Title: Japanese era Reiwa SRU Status in icu package in Ubuntu: New Status in icu source package in Precise: New Status in icu source package in Trusty: New Status in icu source package in Xenial: New Status in icu source package in Bionic: New Status in icu source package in Cosmic: New Status in icu source package in Disco: New Status in icu source package in Eoan: New Status in icu package in Debian: Fix Released Bug description: Japanese era Reiwa SRU $ rmadison icu 4.8.1.1-3ubuntu0.7 | precise-updates 52.1-3ubuntu0.8| trusty-updates 55.1-7ubuntu0.4| xenial-updates 60.2-3ubuntu3 | bionic 60.2-6ubuntu1 | cosmic 63.1-6 | disco 63.1-6 | eoan Note reported abi break / crash of chromium at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1827391/+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 1780442] Re: Please backport fix for & in attributes
** Changed in: fwupd 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/1780442 Title: Please backport fix for & in attributes Status in Fwupd: Fix Released Status in appstream-glib package in Ubuntu: Fix Released Status in fwupd package in Ubuntu: Fix Released Status in appstream-glib source package in Xenial: Fix Released Status in fwupd source package in Xenial: Fix Released Bug description: [Impact] There are instances of fwupd being unable to run updates on certain devices on Ubuntu 16.04. due to a "&" in metadata. [Test Case] * Try to perform an update on a 8bitdo affected device. [Regression Potential] * Regressions would occur in metadata processing where the fwupd daemon wouldn't be able to process it. [Other Info] This was discussed here: https://github.com/hughsie/fwupd/issues/565#issuecomment-402534337 This has been fixed in appstream-glib to prevent & in the metadata. This fix is already in 18.04 and just needs to be backported to 16.04. https://github.com/hughsie/appstream-glib/commit/6048520484101df5d33f3c852c10640e630d20cf To manage notifications about this bug go to: https://bugs.launchpad.net/fwupd/+bug/1780442/+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 1661222] Re: syscall.Getpagesize returns wrong page size on aarch64
** Changed in: docker.io 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/1661222 Title: syscall.Getpagesize returns wrong page size on aarch64 Status in Docker.io: Fix Released Status in golang-1.6 package in Ubuntu: Invalid Status in golang-defaults package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: Fix Released Status in golang-defaults source package in Xenial: Invalid Bug description: syscall.Getpagesize returns wrong page size on aarch64. The code at https://github.com/vielmetti/go-pagesize-test exercises the issue. This is fixed upstream at 1.8 with https://github.com/golang/go/commit/1b9499b06989d2831e5b156161d6c07642926ee1 Downstream, this affects Docker and Kubernetes on aarch64, specifically at https://github.com/docker/docker/issues/27384 for Docker (overlay2 filesystem). Please consider a backport of the page size fix to 1.6 version of Go that is part of 16.04 LTS. thanks Ed root@docker-build-test:/mnt/src/vielmetti/go-pagesize-test# lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 root@docker-build-test:/mnt/src/vielmetti/go-pagesize-test# apt-cache policy golang golang: Installed: 2:1.6-1ubuntu4 Candidate: 2:1.6-1ubuntu4 Version table: *** 2:1.6-1ubuntu4 500 500 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 Packages 100 /var/lib/dpkg/status What I expected to happen: C.getpagesize()) and syscall.Getpagesize() return the same value What happened instead: On aarch64, ✗ go reports correct pagesize (in test file go-pagesize-test.bats, line 3) `[ "$status" -eq 0 ]' failed OS page size = 4096 ; go reports 65536 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: golang 2:1.6-1ubuntu4 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic aarch64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: arm64 Date: Thu Feb 2 11:44:31 2017 PackageArchitecture: all ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: golang-defaults UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/docker.io/+bug/1661222/+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 1789551] Re: qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads
** Changed in: qemu (Debian) Status: Confirmed => 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/1789551 Title: qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Trusty: Won't Fix Status in qemu source package in Xenial: Won't Fix Status in qemu source package in Bionic: Fix Released Status in qemu source package in Cosmic: Fix Released Status in qemu package in Debian: Fix Released Bug description: [Impact] * Backport upstream CVE fix (applies as-is) * This will ensure that the seccomp rules apply to all threads. Without that the security benefit that seccomp provides can be avoided by an attacker. [Test Case] * Run qemu on Bionic, and enable the seccomp feature (not yet default on in Bionic, but in Cosmic). In qemu this is called "sandbox" $ qemu-system-x86_64 -sandbox on -nographic & pid=$!; sleep 2s; echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep Secc; done; kill -9 $pid That will report something like PID 23230 Seccomp: 2 Seccomp: 0 And the two lines should match. [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * This was discussed for other releases e.g. Xenial, but back then the approach to seccomp was different and regression risk would be too high. The Qemu changes are public, so nothing to hide here IMHO, but leaving that to the security team. Copy from the related Debian bug that I commented on: " The following vulnerability was published for qemu. CVE-2018-15746[0]: seccomp: blacklist is not applied to all threads If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-15746 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15746 [1] https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg04892.html [2] https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg02289.html " In addition I think that: - it is available (built in since all still supported releases) - it is default enabled with qemu 2.11 (Bionic) - with libvirt >4.3 (Cosmic) more of the filters are set That in my bad security severity guessing capability makes it - Medium prio =Bionic OTOH, when checking the upstream reproducer with a qemu 2.11 I see nothing being used - so maybe all of it is a red herring (checked on Bionic): $ for pid in $(pidof qemu-system-x86_64); do echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep Secc; done; done PID 10817 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 PID 10657 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 PID 438 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 Seccomp:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789551/+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 1651199] Re: 16.04 - Kernel panic on docker server
** Changed in: linux 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/1651199 Title: 16.04 - Kernel panic on docker server Status in Linux: Fix Released Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Confirmed Bug description: [31016.057405] BUG: unable to handle kernel paging request at 82c4801e6bda [31016.061249] IP: [] __xen_evtchn_do_upcall+0x43/0x80 [31016.061380] PGD 0 [31016.061380] Oops: 0010 [#1] SMP [31016.061380] Modules linked in: binfmt_misc xt_REDIRECT nf_nat_redirect veth xt_comment xt_mark ipt_MASQUERADE nf_nat_masquerade_ipv4 xfrm_user xfrm_algo xt_addrtype iptable_filter xt_conntrack br_netfilter bridge stp llc overlay xt_nat xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables isofs ppdev serio_raw parport_pc parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ixgbevf psmouse floppy [31016.061380] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-53-generic #74-Ubuntu [31016.061380] Hardware name: Xen HVM domU, BIOS 4.2.amazon 11/11/2016 [31016.061380] task: 880406496040 ti: 8804064e task.ti: 8804064e [31016.061380] RIP: 0010:[] [] __xen_evtchn_do_upcall+0x43/0x80 [31016.061380] RSP: 0018:88040fc43f78 EFLAGS: 00010082 [31016.061380] RAX: RBX: 88040fc4b840 RCX: 0001 [31016.061380] RDX: fffe RSI: 000123a0 RDI: 88040fc43f30 [31016.061380] RBP: 88040fc43f90 R08: f24a R09: 0001 [31016.061380] R10: 0001 R11: R12: 0001 [31016.061380] R13: 0003 R14: R15: 8804064e [31016.178419] FS: () GS:88040fc4() knlGS: [31016.178419] CS: 0010 DS: ES: CR0: 80050033 [31016.178419] CR2: 82c4801e6bda CR3: 000204f2f000 CR4: 001406e0 [31016.178419] DR0: DR1: DR2: [31016.178419] DR3: DR6: fffe0ff0 DR7: 0400 [31016.178419] Stack: [31016.178419] 0003 88040fc43fa8 [31016.178419] 814d6bc0 81f36a00 8804064e3e90 81837f32 [31016.178419] 8804064e3de8 8804064e [31016.178419] Call Trace: [31016.178419] [31016.178419] [] xen_evtchn_do_upcall+0x30/0x40 [31016.178419] [] xen_hvm_callback_vector+0x82/0x90 [31016.178419] [31016.178419] [] ? native_safe_halt+0x6/0x10 [31016.178419] [] default_idle+0x1e/0xe0 [31016.239315] [] arch_cpu_idle+0xf/0x20 [31016.239899] [] default_idle_call+0x2a/0x40 [31016.239899] [] cpu_startup_entry+0x2f1/0x350 [31016.239899] [] start_secondary+0x154/0x190 [31016.239899] Code: 01 00 00 00 65 44 8b 2d dc 56 b3 7e c6 03 00 44 89 e0 65 0f c1 05 2e d8 b3 7e 85 c0 75 35 48 8b 05 63 ce d0 00 44 89 ef ff 50 50 <9c> 58 0f 1f 44 00 00 f6 c4 02 75 23 65 8b 05 0a d8 b3 7e 65 c7 [31016.239899] RIP [] __xen_evtchn_do_upcall+0x43/0x80 [31016.239899] RSP [31016.239899] CR2: 82c4801e6bda [31016.239899] ---[ end trace 5b3e8ea32013e327 ]--- [31016.239899] Kernel panic - not syncing: Fatal exception in interrupt [31016.239899] Kernel Offset: disabled We believe this appeared in the last 1-2mo of releases, since this started happening after we did a `apt-get upgrade` on our machines after a bit of a pause. These are EC2 m4.xlarge servers running Ubuntu 16.04.1. They are Kubernetes minions, so I assume docker is likely the trigger. Unfortunately there aren't really any interesting logs in journalctl from the previous boot prior to the panic. Let me know what I can do to debug further. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-53-generic 4.4.0-53.74 ProcVersionSignature: Ubuntu 4.4.0-53.74-generic 4.4.30 Uname: Linux 4.4.0-53-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Dec 19 15:56 seq crw-rw 1 root audio 116, 33 Dec 19 15:56 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.1-0ubuntu2.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
[Group.of.nepali.translators] [Bug 1620754] Re: hash(datetime.datetime(...)) fails with python3.5 on armhf (on an arm64 host) with a bus error
** Changed in: python 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/1620754 Title: hash(datetime.datetime(...)) fails with python3.5 on armhf (on an arm64 host) with a bus error Status in Python: Fix Released Status in python-cryptography package in Ubuntu: Fix Released Status in python3.5 package in Ubuntu: Fix Released Status in python3.4 source package in Trusty: Fix Released Status in python3.5 source package in Xenial: Fix Released Bug description: seen with https://launchpad.net/ubuntu/+source/python-cryptography/1.4-2/+build/10476934 https://launchpad.net/ubuntu/+source/python-cryptography/1.5-1/+build/10678695 the TestInvalidityDate.test_invalid_invalidity_date test is the first one to fail with a bus error. No reasonable traceback from gdb. Trying to build python3.5, python-cffi and python-cryptography with -mno-unaligned-access doesn't fix the issue (buildds running on a 64bit kernel). To manage notifications about this bug go to: https://bugs.launchpad.net/python/+bug/1620754/+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 1692494] Re: klibc does not support reboot arguments
** Changed in: klibc (Debian) Status: Confirmed => 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/1692494 Title: klibc does not support reboot arguments Status in klibc package in Ubuntu: Fix Released Status in klibc source package in Xenial: New Status in klibc package in Debian: Fix Released Bug description: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+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 1779914] Re: unsquashfs does not preserve sticky bit when run as non-root
** Changed in: squashfs-tools (Debian) 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/1779914 Title: unsquashfs does not preserve sticky bit when run as non-root Status in squashfs-tools package in Ubuntu: Fix Released Status in squashfs-tools source package in Trusty: Fix Released Status in squashfs-tools source package in Xenial: Fix Released Status in squashfs-tools source package in Bionic: Fix Released Status in squashfs-tools source package in Cosmic: Fix Released Status in squashfs-tools package in Debian: Fix Released Bug description: [Impact] unsquashfs does not preserve the stickybit when run as non-root (unlike other archive tools, like tar). While this is a bug in and of itself, it causes snaps with sticky directories to fail automated review because the requashed snap has the bit stripped and the resquashed snap as a result has a different checksum. The fix is to attempt the chmod with the stickybit and if it fails with EPERM when not root, try again without the stickybit. [Test Case] 1. create a squashfs with a sticky dir: $ mkdir -p /tmp/foo/sticky-dir $ chmod 1777 /tmp/foo/sticky-dir $ mksquashfs /tmp/foo test.squash -all-root 2. see that the squashfs has the sticky dir in the squash: $ unsquashfs -lls ./test.squash ... drwxrwxrwt root/root 3 2018-07-05 16:03 squashfs-root/sticky-dir 3. unsquash the squash as non-root: $ unsquashfs test.squash 4. verify the stickybit is set: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwt 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ Without the SRU, the directory is 0777: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwx 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ [Regression Potential] Due to the fallback behavior, the regression potential is considered low. Furthermore, because the non-root user is still the owner of the resulting unpacked sticky directories, there is no problem with being able to remove the unpacked directories on error, etc. [ Other Info ] In addition to the above, I've added test-squashfs-tools.py to QRT which verifies type, owner and permissions with mksquashfs and unsquashfs for many different entries. These fail for the sticky bit (but otherwise pass) when unpatched and pass when patched. [ Original description ] From https://sourceforge.net/p/squashfs/mailman/message/36343213/: "This set is an attempt to preserve the sticky bit when running unsquashfs as a non-root user. My main motivation for these changes is to improve reproducability when doing a sequence of "unsquashfs -> mksquashfs" as a non-root user but I think there's even more value in preserving the sticky bit in the case of a squashfs image containing a world-writable directory filled with files owned by a single user. Dropping the sticky bit could be considered to be a real bug in that scenario." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squashfs-tools/+bug/1779914/+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 1770532] Re: DKIM signing not working in bionic
** Changed in: amavisd-new (Debian)
Status: Confirmed => 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/1770532
Title:
DKIM signing not working in bionic
Status in amavisd-new package in Ubuntu:
Fix Released
Status in amavisd-new source package in Xenial:
Won't Fix
Status in amavisd-new source package in Bionic:
Fix Released
Status in amavisd-new source package in Cosmic:
Fix Released
Status in amavisd-new package in Debian:
Fix Released
Bug description:
[Impact]
* There is a known upstream issue in 2.0.11 breaking DKIM signing.
- https://bugzilla.redhat.com/show_bug.cgi?id=1364730
- https://lists.amavis.org/pipermail/amavis-users/2018-February/005292.html
* given the activity on the report it seems plenty of people set this up
pre-Bionic and are now running into these failures on upgrade to the
current LTS.
* Add a fix to avoid more people being hit by this on upgrade and forced
to deploy workarounds (or drop the functionality)
[Test Case]
* Setup amavisd for DKIM signing, see
https://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim
or any of
https://www.faqforge.com/linux/how-to-enable-dkim-email-signatures-in-amavisd-new-and-ispconfig-3/
https://nwgat.ninja/setting-up-dkim-and-spf-with-amavis-on-ubuntu-16-04-2/
...
There seem to be a lot all doing the same essential steps.
TL;DR would be:
$ apt install amavisd-new
$ mkdir -p /var/db/dkim/
$ amavisd-new genrsa /var/db/dkim/example-foo.key.pem
Add in /etc/amavis/conf.d/21-ubuntu_defaults
$enable_dkim_signing = 1;
dkim_key('example.com', 'foo', '/var/db/dkim/example-foo.key.pem');
@dkim_signature_options_bysender_maps = (
{ '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
@mynetworks = qw(0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12
192.168.0.0/16); # list your internal networks
- Now showkeys will report your key including the pblic key you'll need
- amavisd-new showkeys
- add the public key (as displayed) to your DNS zone, increment SOA sequence
number and reload DNS;
- then test signing and a published key
- amavisd-new testkeys
Never the less you'd need to setup a lot of details and it feels
unclear if you test the right thing, therefor my preference is with so
many users reporting about the issue to rely on them to test their
real setups.
[Regression Potential]
* Lacking upstream being active there is always a chance things are
missed, but multiple people came up with very similar solutions and
multiple people tested these successfully.
The actual change sets the originating flag where it is needed on the
creation of dkim signatures.
Due to that setups not triggering dkim_make_signatures should be not
affected at all. And those that use dkim_make_signatures are those
failing now due to the issue.
[Other Info]
* Upstream seems essentially dead atm, so it is on the community (users
reporting patches on the ML) and the Distributions (e.g. Fedora have
taken a very similar change) alone for now.
* For some extra confidence I'd ask for some extra time in proposed for
this update.
Upon upgrading to bionic, amavisd-new DKIM signing no longer works.
A quick google search reveals that this is a known bug in amavisd
2.11.0:
https://bugzilla.redhat.com/show_bug.cgi?id=1364730
https://lists.amavis.org/pipermail/amavis-users/2018-February/005292.html
The redhat bug includes a proposed (one-line) patch. Fedora has
already taken up this patch in their repo. I've applied the patch to
my bionic server and it is a good fix there, too.
Requesting that ubuntu also includes this patch in its repo.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: amavisd-new 1:2.11.0-1ubuntu1 [modified: usr/sbin/amavisd-new]
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
Date: Thu May 10 18:57:32 2018
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: amavisd-new
UpgradeStatus: Upgraded to bionic on 2018-05-10 (0 days ago)
modified.conffile..etc.amavis.conf.d.15-content_filter_mode: [modified]
modified.conffile..etc.amavis.conf.d.50-user: [modified]
mtime.conffile..etc.amavis.conf.d.15-content_filter_mode:
2016-12-11T19:39:20.357027
mtime.conffile..etc.amavis.conf.d.50-user: 2017-06-19T06:44:56.517411
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/amavisd-new/+bug/1770532/+subscriptions
___
Mailing list:
[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
** Changed in: openjdk-8 (Debian) 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/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: Fix Released Status in openjdk-lts package in Ubuntu: Invalid Status in openjdk-8 source package in Xenial: Fix Released Status in openjdk-lts source package in Xenial: Invalid Status in openjdk-8 source package in Bionic: Fix Released Status in openjdk-lts source package in Bionic: Fix Released Status in openjdk-8 source package in Cosmic: Fix Released Status in openjdk-lts source package in Cosmic: Invalid Status in openjdk-10 package in Debian: Fix Released 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: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1800792/+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 1645324] Re: ebtables: Lock file handling has races
** Changed in: ebtables (Debian)
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/1645324
Title:
ebtables: Lock file handling has races
Status in ebtables package in Ubuntu:
Fix Released
Status in ebtables source package in Trusty:
Fix Released
Status in ebtables source package in Xenial:
Fix Released
Status in ebtables source package in Yakkety:
Fix Released
Status in ebtables source package in Zesty:
Fix Released
Status in ebtables source package in Artful:
Fix Released
Status in ebtables package in Debian:
Fix Released
Bug description:
[Impact]
* ebtables uses creation of a file with an exclusive flag
as a lock to synchronize table modification when used
with --concurrent parameter.
* If ebtables crashes it will leave a stale lock file.
This will prevent another copy of ebtables from running,
and indirectly any other service that depends on ebtables
will also be affected.
* This change adds support for real locks that get
cleaned up if a process exits or crashes.
[Test Case]
* Test Case1:
1. $ sudo touch /var/lib/ebtables/lock"
2. $ sudo ebtables --concurrent -L
3. ebtables can't acquire a lock
* Test Case 2:
1. $ while true; do /usr/sbin/ebtables --concurrent -L; done
2. hard reboot VM
3. likely that the lock file is present under /var/lib/ebtables
4. libvird hanging, try to connect to qemu:///system
[Regression Potential]
* Normal Use:
There is no regression potential during normal use and
operation of ebtables.
* Package Upgrade:
There is a very very small regression potential during the package
upgrade to the latest version. Once the package is upgraded that
potential is gone. It is a very small potential because several
things have to happen in a very small time frame and in an exact
order since ebtables is not a resident program like a daemon:
1. ebtables is launched during package upgrade AND
2. new ebtables binary has not yet been written to disk AND
3. it is launched with --concurent switch AND
4. another ebtables with new binary is launched AND
5. it is launched with --concurent switch AND
6. the first ebtables copy hasn't exited yet AND
7. both copies of ebtables are launched with a WRITE command AND
8. both copies of ebtables are manipulating the same resource.
Then one of the binaries could potentially fail, but once the old
binary exits the potential is gone so subsequent re-runs of
ebtables will succeed.
* Dragan's patch has been submitted to Debian via :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860590
* Note that the ebtables upstream project is nearly dead. Nowadays,
all the development is now happening in nft project which is intended
to be replacement.
[Original Text]
libvirtd is hanging after startup due to ebtables lock file -from an earlier
run- remains intact when the system reboots.
Same issue is happening than it is reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1290327 when the system boots.
After booting the system, It's not possible connect to the qemu-service.
- libvirt daemon tried to obtain a lock:
[pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
[pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2,
4294967295) = 1 ([{fd=24, revents=POLLIN}])
[pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
[pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2,
4294967295) = 1 ([{fd=24, revents=POLLIN}])
[pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
[pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2,
4294967295^CProcess 20916 detached
- there was a file named 'lock' in /var/lib/ebtables directory with timestamp
14:54
- ebtables was configured:
* Ebtables support available, number of installed rules [ OK ]
(other nodes appeared to be in the same state from ebtables point of view,
but without the lock file)
- I removed the lock file and libvirt started to work instantly - the lock
obtain messages have disappeared from the trace and virsh commands are working
- at 14:54 the host was booting up. According to the logs, there were other
reboots after that one, but the lock file remained intact (at least the
timestamp was not updated).
Could you please suggest a solution to be sure that ebtables lock file
is removed during boot?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1645324/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to :
[Group.of.nepali.translators] [Bug 1811471] Re: local resolver stub fails to handle multiple TCP dns queries
** Changed in: systemd 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/1811471 Title: local resolver stub fails to handle multiple TCP dns queries Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Trusty: Invalid Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] The systemd local 'stub' resolver handles all local DNS queries (by default configuration used in Ubuntu), and essentially proxies all requests to its configured upstream DNS resolvers. Most local DNS resolution by applications uses glibc's getaddrinfo() function. This function is configured in various ways by the /etc/resolv.conf file, which tells glibc what nameserver/resolver to contact as well as how to talk to the name server. By default, glibc performs UDP DNS queries, with a single DNS query per UDP packet. The UDP packet size is limited per DNS spec to 512 bytes. For some DNS lookups, a 512 byte UDP packet is not large enough to contain the entire response - for example, an A record lookup with a large number (e.g. 30) of A record addresses. This number of A record entries is possible in some cases of load balancing. When the DNS UDP response size is larger than 512 bytes, the server puts as much response as it can into the DNS UDP response, and marks the "trunacted" flag. This lets glibc know that the DNS UDP packet did not contain the entire response for all the A records. When glibc sees a UDP response that is "trunacted", by default it ignores the contents of that response and issues a new DNS query, using TCP instead of UDP. The TCP packet size has a higher size limit (though see bug 1804487 which is a bug in systemd's max-sizing of TCP DNS packets), and so *should* allow glibc to receive the entire DNS response. However, glibc issues DNS queries for both A and records. When it uses UDP, those DNS queries are separate (i.e. one UDP DNS packet with a single A query, and one UDP DNS packet with a single query). When glibc uses TCP, it puts both DNS queries into a single TCP DNS packet - the RFC refers to this as "pipelining" (https://tools.ietf.org/html/rfc7766#section-6.2.1.1) and states that clients SHOULD do this, and that servers MUST expect to receive pipelined queries and SHOULD respond to all of them. (Technically pipelining can be separate DNS queries, one per TCP packet, but both using the same TCP connection - but the clear intention of pipelining is to improve TCP performance, and putting both DNS queries into a single TCP packet is clearly more performant than using separate TCP packets). Unfortunately, systemd's local stub resolver has only very basic support for TCP DNS, and it handles TCP DNS queries almost identically to UDP DNS queries - it reads the DNS query 2-byte header (containing the length of the query data), reads in the single DNS query data, performs lookup and sends a response to that DNS query, and closes the TCP connection. It does not check for "pipelined" queries in the TCP connection. That would be bad enough, as glibc is (rightly) expecting a response to both its A and queries; however what glibc gets is a TCP connection-reset error. That is because the local systemd stub resolver has closed its TCP socket while input data was still pending (i.e. it never even read the second pipelined DNS query). When the kernel sees unread input bytes in a TCP connection that is closed, it sends a TCP RST to the peer (i.e. glibc) and when the kernel sees the RST, it dumps all data in its socket buffer and passes the ECONNRESET error up to the application. So glibc gets nothing besides a connection reset error. Note also that even if the systemd local stub resolver's socket flushes its input buffer before closing the TCP connection (which will avoid the TCP RST), glibc still expects responses to both its A and queries before systemd closes the TCP connection, and so a simple change to systemd to flush the input buffer is not enough to fix the bug (and would also not actually fix the bug since glibc would never get the response). [Test Case] This can be reproduced on any system using a local systemd stub resolver, when using an application that uses getaddrinfo() - such as ssh, telnet, ping, etc - or with a simple C program that uses getaddrinfo(). The dns name looked up must have enough A records to overflow the 512 byte maximum for a UDP DNS packet; e.g.: $ ping
[Group.of.nepali.translators] [Bug 1571436] Re: Needed update to nginx example config file due to dependency change
** Changed in: wordpress (Debian) Status: Fix Committed => 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/1571436 Title: Needed update to nginx example config file due to dependency change Status in wordpress package in Ubuntu: Fix Released Status in wordpress source package in Xenial: Triaged Status in wordpress package in Debian: Fix Released Bug description: Example nginx config in wordpress package fails to find php-fpm socket in 16.04: Either /usr/share/doc/wordpress/examples/nginx-wordpress.conf should have line: fastcgi_pass unix:/var/run/php-fpm.sock; changed to: fastcgi_pass unix:/run/php/php7.0-fpm.sock; To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wordpress/+bug/1571436/+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 1805348] Re: Recent security update broke server-side keyboard-interactive authentication
** Changed in: libssh (Debian) 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/1805348 Title: Recent security update broke server-side keyboard-interactive authentication Status in libssh package in Ubuntu: Fix Released Status in libssh source package in Trusty: Fix Released Status in libssh source package in Xenial: Fix Released Status in libssh source package in Bionic: Fix Released Status in libssh source package in Cosmic: Fix Released Status in libssh package in Debian: Fix Released Bug description: 0.8.4 and the backported fixes for CVE-2018-10933 cause server-side keyboard-interactive authentication to completely break. See https://bugs.libssh.org/T117 for details and a reproducer. This was fixed upstream as part of the 0.8.5 release, so disco is fine. For 16.04/18.04/18.10, please backport the fix: https://git.libssh.org/projects/libssh.git/commit/?id=4ea46eecce9f4 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1805348/+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
** Changed in: openjdk-8 (Debian) Status: Fix Released => 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/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: Fix Released Status in openjdk-lts package in Ubuntu: Invalid Status in openjdk-8 source package in Xenial: Fix Released Status in openjdk-lts source package in Xenial: Invalid Status in openjdk-8 source package in Bionic: Fix Released Status in openjdk-lts source package in Bionic: Fix Released Status in openjdk-8 source package in Cosmic: Fix Released Status in openjdk-lts source package in Cosmic: Invalid Status in openjdk-10 package in Debian: Fix Released Status in openjdk-8 package in Debian: New 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: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1800792/+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 1578821] Re: I'm not able to install galician language in Ubuntu 16.04
** Changed in: libreoffice-dictionaries (Debian) 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/1578821 Title: I'm not able to install galician language in Ubuntu 16.04 Status in language-selector package in Ubuntu: Confirmed Status in libreoffice-dictionaries package in Ubuntu: Fix Released Status in language-selector source package in Xenial: Fix Released Status in libreoffice-dictionaries package in Debian: Fix Released Bug description: [Impact] Installing the Galician language via Language Support fails. The reason is that there is currently two hunspell spellchecking packages in the archive: * hunspell-gl-es, provided by the hunspell-gl-es source package * hunspell-gl, provided by the libreoffice-dictionaries source package Even if hunspell-gl-es conflicts to hunspell-gl, having both of them available in the archive is not compatible with the way the writing aids is pulled via Language Selector. The proposed upload in this PPA: https://launchpad.net/~gunnarhj/+archive/ubuntu/lo-dicts-symlinks drops the hunspell-gl binary from libreoffice-dictionaries. [Test Case] * Open Language Support * Try to install Galician [Regression Potential] Low. [Original description] Hi I just installed Ubuntu 16.04. So as I try to install galician language I get this notification: Transaction failed: Package dependencies cannot be resolved The following packages have unmet dependencies: hunspell-gl-es: Then nothing happens. Several fellows got the same issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1578821/+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 1644057] Re: Excessive Disconnect unmatched entries from sshd
** Changed in: logwatch (Debian) 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/1644057 Title: Excessive Disconnect unmatched entries from sshd Status in logwatch package in Ubuntu: Fix Released Status in logwatch source package in Xenial: New Status in logwatch source package in Bionic: New Status in logwatch package in Debian: Fix Released Bug description: [Impact] User ssh disconnect messages in syslog aren't handled by logwatch, and thus end up in the "Unmatched Entries" section, one per event. This clutters up the logwatch reports unnecessarily. [Test Case] # lxc launch ubuntu-daily:cosmic tester # lxc exec tester bash # apt update # apt dist-upgrade -y # apt install -y logwatch openssh-server mailutils * mail configuration : Local only * System mail name: (use default) # sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config # systemctl restart sshd # passwd ubuntu * choose a password # ssh ubuntu@localhost * login, then exit # logwatch --detail Med --mailto root --service all --range today # sleep 1 # mail * select message 1 * Search for SSHD: /SSHD You will see unmatched entries: **Unmatched Entries** Disconnected from user ubuntu 127.0.0.1 port 53084 : 1 time(s) [Original Description] # lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 # apt-cache policy logwatch logwatch: Installed: 7.4.2-1ubuntu1 Candidate: 7.4.2-1ubuntu1 Version table: *** 7.4.2-1ubuntu1 500 500 http://mirrors.digitalocean.com/ubuntu xenial/main amd64 Packages 500 http://mirrors.digitalocean.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status The issue seems to be exactly as described here: https://bugzilla.redhat.com/show_bug.cgi?id=1317620 In synopsis, Logwatch's "SSHD" output contains excessive "Unmatched Entries" regarding SSH disconnections. They look like this: Received disconnect from 123.123.123.123 port 6887:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 8310:11: disconnected by user : 1 time(s) Disconnected from 123.123.123.123 port 1306 : 1 time(s) Received disconnect from 123.123.123.123 port 3720:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 3001:11: disconnected by user : 1 time(s) Disconnected from 123.123.123.123 port 1054 : 1 time(s) Received disconnect from 123.123.123.123 port 9741:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 3261:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 4650:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 13235:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 1065:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 13868:11: disconnected by user : 1 time(s) Disconnected from 123.123.123.123 port 8542 : 1 time(s) I should mention that these connections are from me, and are legitimate; they are not from "bots" or other types of probes/scans that are, for example, check for the availability of vulnerable ciphers. The key finding from the above report seems to be: "I don't know why there are two different format disconnect messages, but the bit that seems to confuse logwatch was adding the port number to the message." There seem to be several (3-5) such messages that result from a normal connect/disconnect cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logwatch/+bug/1644057/+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 1779863] Re: Ubuntu nodejs package isn't ABI compatible with mainline nodejs.
** Changed in: nodejs (Debian)
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/1779863
Title:
Ubuntu nodejs package isn't ABI compatible with mainline nodejs.
Status in nodejs package in Ubuntu:
Fix Released
Status in nodejs source package in Trusty:
Invalid
Status in nodejs source package in Xenial:
Invalid
Status in nodejs source package in Bionic:
Fix Released
Status in nodejs source package in Cosmic:
Fix Released
Status in nodejs package in Debian:
Fix Released
Bug description:
[impact]
Pre-built addons for nodejs built against the 8.10 version, which is
what is included in Bionic, will fail to load on Bionic because the
version of nodejs there is built using a newer ABI-incompatible
openssl version.
[test case]
1. Run 'sudo apt install nodejs npm'
2. Run 'mkdir /tmp/lp.1779863'
3. Run 'cd /tmp/lp.1779863'
4. Run 'npm install grpc'
5. Note that it mentions installing a prebuilt binary from remote.
6. Run 'node' and enter the following code:
> const grpc = require('grpc')
> const creds = grpc.ServerCredentials.createSsl(null, [])
> const server = new grpc.Server()
> server.bind('0.0.0.0:8080', creds)
7. Observe that this results in a crash, with an error like:
node: symbol lookup error:
/tmp/lp.1779863/node_modules/grpc/src/node/extension_binary/node-v57-linux-x64-glibc/grpc_node.node:
undefined symbol: SSL_library_init
8. Run 'npm install node-webcrypto-ossl'.
9. Observe that compilation fails due to a header expectation mismatch.
10. Install nodejs from -proposed.
11. Repeat steps 6-9 and observe that the commands succeed without errors.
[regression potential]
Although this SRU changes the ABI of nodejs that is exposed to binary
add-ons, the practical regression potential for this ABI change is
minimal. The archive has been scanned to confirm there are no
reverse-dependencies in Ubuntu which use this part of the ABI, and it
is not feasible to build third-party binaries that are compatible with
nodejs as shipped in 18.04 because the gyp build system used by the
nodejs ecosystem exposes system headers that don't match the symbols
exported by the current Ubuntu nodejs built against OpenSSL 1.1.
Thus, the greatest risk of regression is from someone manually working
around this gyp incompatibility in order to build an add-on which uses
these symbols. This risk is negligible.
Changing this to use openssl1.0 assumes that the security team will
maintain security patches for openssl1.0.
There is no risk of regression in protocol compatibility by switching
back from openssl 1.1 to openssl 1.0, because TLS 1.3 support has not
yet landed in the openssl package in 18.04.
[other info]
alternately, this could be fixed by upgrading the nodejs package in
Bionic (and Cosmic) to a newer nodejs - Debian has version 10.4.0 in
experimental.
also debian 904274 has quite a bit of discussion.
original bug description below.
---
Background:
NodeJS has a native extension API: https://nodejs.org/api/addons.html
It's fairly understood by developers that NodeJS's ABI is stable, and that
one module built using a version of nodejs should work on another semantically
version compatible of nodejs.
NodeJS exposes various third party libraries to the native module
developers. Quote from the addons developers page: "Node.js includes a
number of other statically linked libraries including OpenSSL. These
other libraries are located in the deps/ directory in the Node.js
source tree. Only the libuv,i OpenSSL, V8 and zlib symbols are
purposefully re-exported by Node.js and may be used to various extents
by Addons."
It's fairly understood by developers that native modules have the same
ABI guarantee than the rest of the node API.
The NodeJS ecosystem uses native modules extensively, and it's fairly
common for developers to publish precompiled versions of their
extensions so that the typical end-user can simply npm install their
dependencies without worrying about having a compiler installed. Some
packages will do their own thing (see for instance
https://www.npmjs.com/package/uws), while others will rely on third
party extensions to facilitate their work. See for instance prebuild
(https://www.npmjs.com/package/prebuild) that has a handful of
dependents, or node-pre-gyp (https://www.npmjs.com/package/node-pre-
gyp) that has north of 350 dependents. So the nodejs ecosystem has
roughly 400 native packages that are publishing prebuilt versions of
their extensions.
Problem with the Ubuntu nodejs package:
Put simply, it breaks prebuilt packages that depend on OpenSSL. NodeJS 8.10.0
officially comes with OpenSSL 1.0.2n, while the NodeJS 8.10.0 that comes with
the Ubuntu
[Group.of.nepali.translators] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
** Changed in: cups 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/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: In Progress Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: In Progress Status in cups source package in Bionic: In Progress Status in cups source package in Cosmic: In Progress Status in cups source package in Disco: In Progress Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
** Changed in: cups (Debian) 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/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: New Status in cups package in Ubuntu: In Progress Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: In Progress Status in cups source package in Bionic: In Progress Status in cups source package in Cosmic: In Progress Status in cups source package in Disco: In Progress Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+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
** Changed in: openjdk-10 (Debian) 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/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: Fix Released Status in openjdk-lts source package in Xenial: Invalid Status in openjdk-8 source package in Bionic: Fix Released Status in openjdk-lts source package in Bionic: Fix Released Status in openjdk-8 source package in Cosmic: Fix Released Status in openjdk-lts source package in Cosmic: Invalid Status in openjdk-10 package in Debian: Fix Released 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: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1800792/+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 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
** Changed in: systemd (Debian) Status: Fix Committed => 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/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd: Fix Released Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Status in systemd package in Debian: Fix Released Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1804487/+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 1666570] Re: Post install script has error in RegEx
** Changed in: tomcat7 (Debian) 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/1666570 Title: Post install script has error in RegEx Status in tomcat8 package in Ubuntu: Fix Released Status in tomcat7 source package in Trusty: Fix Released Status in tomcat7 source package in Xenial: Triaged Status in tomcat8 source package in Xenial: Fix Released Status in tomcat7 source package in Yakkety: Won't Fix Status in tomcat8 source package in Yakkety: Fix Released Status in tomcat8 source package in Zesty: Fix Released Status in tomcat7 package in Debian: Fix Released Status in tomcat8 package in Debian: Fix Released Bug description: == Begin SRU Template == [Impact] * On upgrade of tomcat7 package, if a user has updated their JAVA_OPTS variable to include a '%' an upgrade will fail. The sed command in the postinst uses the '%' character to act as a delimiter, previous versions used '/' however it was updated to '%' in hopes it was far less common. * This SRU updates it to a character that should not be found in the JAVA_ARGS value, namely '\001'. * This is the same solution Debian and tomcat maintainers are now using for Tomcat8. [Test Case] An example to test Tomcat7 on Trusty. The same instructions can apply to Tomcat8 on the other releases. Overview: Install the version from the current release. Modify JAVA_OPTS and then install the version from proposed to validate it upgrades successfully. * lxc launch ubuntu-daily:trusty trusty * lxc exec trusty bash * apt install tomcat7 * Edit /etc/default/tomcat7, set JAVA_OPTS="-Djava.awt.headless=true -XX:ErrorFile=/var/log/tomcat7/java_error%p.log -XX:+DisableExplicitGC -XX:+UseG1GC" * # Enable proposed * apt update * apt install tomcat7 * When asked, 'Keep the local version currently installed' * With the fix, install will complete * Without the fix, the error as described under "Other Info" will appear [Regression Potential] * Users currently experiencing this issue would be expecting a SRU fix to come from us. Working around it would require changing their JAVA_OPTS temporarily, accepting the maintainers version of the defaults script, or modifying the package's postinst script directly. * In either case the proposed fix will over write any changes an end user may have made to the postinst, and all for correctly working expected behavior. * There is the slight, albeit incredibly low chance, that someone actually has the '\001' character in their JAVA_OPTS. In which, case the upgrade would fail as this bug describes. [Other Info] * Using a new delimiter that is far less likely to be in someone's path. This is not the first time the delimiter has changed, as it originally as '/' which is obviously going to show up as soon as someone adds a path. * Upstream change to tomcat8: https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/patch/?id=7664221d66701e2c31a31fe3b4f22e8bea4158dc * Error message on failure: Setting up tomcat7 (7.0.52-1ubuntu0.10) ... sed: -e expression #1, char 97: unknown option to `s' dpkg: error processing package tomcat7 (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: tomcat7 E: Sub-process /usr/bin/dpkg returned an error code (1) == End SRU Template == To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tomcat8/+bug/1666570/+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 1695093] Re: arm64: "unsupported RELA relocation: 275" loading certain modules
Launchpad has imported 18 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041. If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. On 2017-01-10T11:17:05+00:00 Robert Schiele wrote: Created attachment 40487 test case to reproduce the problem To support older Cortex A53 CPUs that suffer from erratum 843419 the Linux kernel has some option not to allow certain relocations in kernel modules. To achieve that it utilizes the options -mcmodel=large -mpc- relative-literal-loads. Unfortunately we found a case where gcc does still produce such relocations despite the options being used if optimization level is at least -O2. The code in question is attached and the problem can be reproduced like this: $ aarch64-linux-gnu-gcc -O2 -mcmodel=large -mpc-relative-literal-loads -c t.c $ aarch64-linux-gnu-objdump -r t.o t.o: file format elf64-littleaarch64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0018 R_AARCH64_CALL26 strcmp 0030 R_AARCH64_ADR_PREL_PG_HI21 .text+0x0060 0034 R_AARCH64_ADD_ABS_LO12_NC .text+0x0060 0050 R_AARCH64_ABS64 .rodata.str1.8 Obviously the attached code by itself might not be very useful but it is a stripped-down code example of a real-world kernel driver just to demonstrate the problem. Some observations: 1. The problem did reproduce with the latest patches from Linaro and with the upstream version (without the Linaro patches) of latest gcc 6 branch. 2. The problem did also reproduce with the gcc 5 branch including the Linaro patches on that branch. I did not check the gcc 5 branch without the Linaro patches. 3. The problem disappears if the useless (not used in the code) second entry in the array gets removed from the code. 4. The problem seems to be in the code that is generated for the strcpy by the compiler. 5. The problem disappears if the string is made longer. In that case the string ends up in .rodata.str1.8 section like the other string, while in the problematic case it is stored as .xword type in .text section. So my personal conclusion is that some code in the backend involved in this strcpy optimization does not honor the -mpc-relative-literal-loads option properly. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/0 On 2017-01-10T11:36:04+00:00 Ktkachov wrote: Confirmed on GCC 6.3.1 This doesn't appear on trunk. Trunk generates a pc-relative load. aarch64-none-elf-objdump -r t.o reloc.o: file format elf64-littleaarch64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0018 R_AARCH64_CALL26 strcmp 0038 R_AARCH64_ABS64 .rodata.str1.8 0040 R_AARCH64_ABS64 .rodata.str1.8+0x0008 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/1 On 2017-01-10T16:22:55+00:00 Ktkachov wrote: This was fixed by a trunk patch that has been only partially backported to GCC 6. Testing a patch to fix it. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/2 On 2017-01-11T06:25:55+00:00 Robert Schiele wrote: If you point me to the specific patch that you have in mind I can in parallel already test whether besides the test case I provided it also fixes the original problem this was detected with. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/3 On 2017-01-11T16:34:07+00:00 Ktkachov wrote: (In reply to Robert Schiele from comment #3) > If you point me to the specific patch that you have in mind I can in > parallel already test whether besides the test case I provided it also fixes > the original problem this was detected with. I've posted a patch for review at: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00736.html It should apply to a GCC 6-based tree (but not GCC 7 trunk which doesn't exhibit this bug) Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/4 On 2017-01-12T07:39:19+00:00 Robert Schiele wrote: Thanks! I can confirm that this also fixes the original problem for all cases we observed so far. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/5 On 2017-01-12T17:42:22+00:00 Ktkachov wrote: thanks
[Group.of.nepali.translators] [Bug 1771283] Re: iperf2 long time run on 40Gb/s NIC crashes
** Changed in: iperf (Debian) 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/1771283 Title: iperf2 long time run on 40Gb/s NIC crashes Status in iperf package in Ubuntu: Fix Released Status in iperf source package in Xenial: Fix Released Status in iperf source package in Artful: Fix Released Status in iperf source package in Bionic: Fix Released Status in iperf source package in Cosmic: Fix Released Status in iperf package in Debian: Fix Released Bug description: [Impact] Running iperf2 across 40GB connection for a long period of time causes iperf to segfault. [Test] ubuntu@recht:~$ iperf -c 192.168.121.2 -P10 -w 130k -t 3600 Client connecting to 192.168.121.2, TCP port 5001 TCP window size: 254 KByte (WARNING: requested 127 KByte) [ 10] local 192.168.121.3 port 40756 connected with 192.168.121.2 port 5001 [ 12] local 192.168.121.3 port 40760 connected with 192.168.121.2 port 5001 [ 11] local 192.168.121.3 port 40758 connected with 192.168.121.2 port 5001 [ 8] local 192.168.121.3 port 40754 connected with 192.168.121.2 port 5001 [ 9] local 192.168.121.3 port 40752 connected with 192.168.121.2 port 5001 [ 7] local 192.168.121.3 port 40750 connected with 192.168.121.2 port 5001 [ 6] local 192.168.121.3 port 40746 connected with 192.168.121.2 port 5001 [ 5] local 192.168.121.3 port 40748 connected with 192.168.121.2 port 5001 [ 3] local 192.168.121.3 port 40744 connected with 192.168.121.2 port 5001 [ 4] local 192.168.121.3 port 40742 connected with 192.168.121.2 port 5001 Segmentation fault (core dumped) [Fix] This is fixed latest iperf2 git clone https://git.code.sf.net/p/iperf2/code commit fce3254827eb05fee56aa6a2e9f0d69cbe599a69 Author: Robert McMahon Date: Sat Jun 2 11:48:22 2018 -0700 fix for: iperf2 long time run on 40Gb/s NIC crashes, found ubuntu Bug #1771283, reported by Ike Panhc, increase format support to Peta as well [Regression Potential] This patch was tested on ARM64 Cavium ThunderX2 systems and no regressions were found. iperf calculates the sum of all bytes transferred and prints this sum like 'Sum: 100Mbytes'. For example if total data transferred was (simplified) 100,000,000 Bytes, iperf would print Sum: 100 Mbytes. The suffix Mbytes is stored in a static array and it uses the number of time it had to divide the sum by 1000 to determine the index to that array. iperf only accounted for Sums up to GBytes, causing it to segfault on Sums of +TBytes. Currently the patch extends this array to Peta Bytes, but you will segfault again if the sum is in the order of Exabyte or larger. This might be achievable by using 100G connections between server-client (Mellanox 100G nic & switch) and running iperf at max throughput for a long long long periods of time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iperf/+bug/1771283/+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
