[Group.of.nepali.translators] [Bug 1822834] Re: linux: 4.4.0-146.172 -proposed tracker
** Changed in: kernel-sru-workflow/automated-testing Status: Incomplete => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow backports: bug 1822833 (trusty/linux-lts-xenial), bug 1824775 (trusty/linux-aws) derivatives: bug 1822826 (linux-kvm), bug 1822828 (linux-raspi2), bug 1822829 (linux-snapdragon), bug 1822830 (linux-fips), bug 1824774 (linux-aws) -- swm properties -- boot-testing-requested: true bugs-spammed: true phase: Testing phase-changed: Thursday, 04. April 2019 18:05 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: - automated-testing: Stalled -- testing FAILED certification-testing: Ongoing -- testing in progress regression-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff -- 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/1822834 Title: linux: 4.4.0-146.172 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: In Progress Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Confirmed Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-certification-testing series: Fix Released Status in Kernel SRU Workflow snap-release-to-beta series: Fix Released Status in Kernel SRU Workflow snap-release-to-candidate series: Fix Released Status in Kernel SRU Workflow snap-release-to-edge series: Fix Released Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow backports: bug 1822833 (trusty/linux-lts-xenial), bug 1824775 (trusty/linux-aws) derivatives: bug 1822826 (linux-kvm), bug 1822828 (linux-raspi2), bug 1822829 (linux-snapdragon), bug 1822830 (linux-fips), bug 1824774 (linux-aws) -- swm properties -- boot-testing-requested: true bugs-spammed: true phase: Testing phase-changed: Thursday, 04. April 2019 18:05 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Ongoing -- testing in progress regression-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1822834/+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 1754655] Re: Installing snap from command line confuses GNOME Software
This fix wasn't correctly applied in xenial, so will be re-uploaded ** Tags removed: verification-done-xenial ** Changed in: gnome-software (Ubuntu Xenial) Status: Fix Released => Fix Committed -- 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/1754655 Title: Installing snap from command line confuses GNOME Software Status in gnome-software package in Ubuntu: Fix Released Status in gnome-software source package in Xenial: Fix Committed Status in gnome-software source package in Artful: Won't Fix Status in gnome-software source package in Bionic: Fix Released Bug description: [Impact] Installing snaps from the command line (or any other client) causes the state in GNOME Software to wrongly represented. [Test Case] 1. Ensure you don't have moon-buggy installed $ sudo snap remove moon-buggy 2. Start GNOME Software 3. Install moon-buggy from the command line: $ sudo snap install moon-buggy 4. Search for "moon" in GNOME Software Expected result: Moon Buggy shows in search results as installed Observed result: Moon Buggy not returned in search results. [Regression Potential] Low, we fix a bug where were reading invalid metadata and a check that makes stops unexpected (but valid) state notification from the snap plugin. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1754655/+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 1799614] Re: Use new media API
** Changed in: snapd-glib (Ubuntu Bionic) Status: In Progress => Fix Released ** Changed in: snapd-glib (Ubuntu Cosmic) Status: In Progress => 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/1799614 Title: Use new media API Status in gnome-software package in Ubuntu: Fix Released Status in snapd-glib package in Ubuntu: Fix Released Status in gnome-software source package in Xenial: Fix Committed Status in gnome-software source package in Bionic: Fix Committed Status in snapd-glib source package in Bionic: Fix Released Status in gnome-software source package in Cosmic: Fix Committed Status in snapd-glib source package in Cosmic: Fix Released Bug description: [Impact] snapd now provides 'media' which replaces the old 'screenshots' data. We need to migrate to this as the old screenshot data will be removed in the future. [Test Case] Run gnome-software with updated snapd-glib and confirm that screenshots and promoted snap banners continue to work. [Regression Potential] Possibility of new errors being introduced in updated code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1799614/+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 1621386] Re: [MIR] libsodium
Copy candidates: libsodium 1.0.8-5 in xenial libsodium-dbg 1.0.8-5 in xenial amd64 libsodium-dbg 1.0.8-5 in xenial arm64 libsodium-dbg 1.0.8-5 in xenial armhf libsodium-dbg 1.0.8-5 in xenial i386 libsodium-dbg 1.0.8-5 in xenial powerpc libsodium-dbg 1.0.8-5 in xenial ppc64el libsodium-dbg 1.0.8-5 in xenial s390x libsodium-dev 1.0.8-5 in xenial amd64 libsodium-dev 1.0.8-5 in xenial arm64 libsodium-dev 1.0.8-5 in xenial armhf libsodium-dev 1.0.8-5 in xenial i386 libsodium-dev 1.0.8-5 in xenial powerpc libsodium-dev 1.0.8-5 in xenial ppc64el libsodium-dev 1.0.8-5 in xenial s390x libsodium-dev-dbgsym 1.0.8-5 in xenial amd64 libsodium-dev-dbgsym 1.0.8-5 in xenial arm64 libsodium-dev-dbgsym 1.0.8-5 in xenial armhf libsodium-dev-dbgsym 1.0.8-5 in xenial i386 libsodium-dev-dbgsym 1.0.8-5 in xenial powerpc libsodium-dev-dbgsym 1.0.8-5 in xenial ppc64el libsodium-dev-dbgsym 1.0.8-5 in xenial s390x libsodium18 1.0.8-5 in xenial amd64 libsodium18 1.0.8-5 in xenial arm64 libsodium18 1.0.8-5 in xenial armhf libsodium18 1.0.8-5 in xenial i386 libsodium18 1.0.8-5 in xenial powerpc libsodium18 1.0.8-5 in xenial ppc64el libsodium18 1.0.8-5 in xenial s390x libsodium18-dbgsym 1.0.8-5 in xenial amd64 libsodium18-dbgsym 1.0.8-5 in xenial arm64 libsodium18-dbgsym 1.0.8-5 in xenial armhf libsodium18-dbgsym 1.0.8-5 in xenial i386 libsodium18-dbgsym 1.0.8-5 in xenial powerpc libsodium18-dbgsym 1.0.8-5 in xenial ppc64el libsodium18-dbgsym 1.0.8-5 in xenial s390x Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary Copy [y|N]? y 36 copies requested. $ q -Q unapproved -s xenial-updates override -c main libsodium Overriding libsodium_1.0.8-5 (universe/misc) 20445625 | X- | libsodium| 1.0.8-5 | 1 minute | * libsodium/1.0.8-5 Component: main Section: misc $ q -Q unapproved -s xenial-updates accept libsodium Accepting libsodium/1.0.8-5 ** Changed in: libsodium (Ubuntu Xenial) Status: In Progress => 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/1621386 Title: [MIR] libsodium Status in libsodium package in Ubuntu: Fix Released Status in libsodium source package in Trusty: Fix Released Status in libsodium source package in Xenial: Fix Released Bug description: [Availability] The package is currently available in universe, currently imported directly from Debian with no Ubuntu specific patches. [Rationale] libsodium is a dependency of ZeroMQ, which in turn is a dependency of unity-scopes-api. Therefore, we will need to include it in main to support Unity 8. [Security] I couldn't find any CVEs or other advisories for the libsodium library, or djb's "nacl" library (http://nacl.cr.yp.to/) that it is derived from. [Quality Assurance] Package is a library, so not something end users will interact with directly. There are other apps and libraries in universe that currently link with libsodium, and install without issue. The library asks no debconf questions on install. Bugs are tracked in Debian and Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/libsodium https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libsodium The one Ubuntu bug looks like it might be user confusion about -dev packages. The one Debian report is complaining about Debian packaging an old version of libsodium: something that seems to have since been fixed but not noted in the bug report. New releases appear to be packaged in Debian promptly (https://packages.qa.debian.org/libs/libsodium.html), and the latest Debian release was recently migrated into Yakkety. The package is a software crypto library, so doesn't rely on exotic hardware. Library has a test suite that is run as part of the package build. The package has a debian/watch file checking for new releases on github. [UI Standards] The package contains a non-graphical crypto library. [Dependencies] The libsodium18 binary package only depends on libc6. For source build-depends, there is debhelper, pkg-config, and dh-autoreconf. All are already in main. [Maintenance] The package currently lists ubuntu-devel-discuss as its maintainer. It doesn't look like we've ever made any changes to the versions of the package migrated from Debian though. [Background information] The package has reasonable description strings and hasn't been renamed recently. The source package name matches the upstream project name. [ABI Stability] The library is plain C, so should be fairly robust. The upstream
[Group.of.nepali.translators] [Bug 1621386] Re: [MIR] libsodium
Override component to main libsodium 1.0.8-5~ubuntu14.04.1 in trusty: universe/libs -> main libsodium-dbg 1.0.8-5~ubuntu14.04.1 in trusty amd64: universe/debug/extra/100% -> main libsodium-dbg 1.0.8-5~ubuntu14.04.1 in trusty arm64: universe/debug/extra/100% -> main libsodium-dbg 1.0.8-5~ubuntu14.04.1 in trusty armhf: universe/debug/extra/100% -> main libsodium-dbg 1.0.8-5~ubuntu14.04.1 in trusty i386: universe/debug/extra/100% -> main libsodium-dbg 1.0.8-5~ubuntu14.04.1 in trusty powerpc: universe/debug/extra/100% -> main libsodium-dbg 1.0.8-5~ubuntu14.04.1 in trusty ppc64el: universe/debug/extra/100% -> main libsodium-dev 1.0.8-5~ubuntu14.04.1 in trusty amd64: universe/libdevel/optional/100% -> main libsodium-dev 1.0.8-5~ubuntu14.04.1 in trusty arm64: universe/libdevel/optional/100% -> main libsodium-dev 1.0.8-5~ubuntu14.04.1 in trusty armhf: universe/libdevel/optional/100% -> main libsodium-dev 1.0.8-5~ubuntu14.04.1 in trusty i386: universe/libdevel/optional/100% -> main libsodium-dev 1.0.8-5~ubuntu14.04.1 in trusty powerpc: universe/libdevel/optional/100% -> main libsodium-dev 1.0.8-5~ubuntu14.04.1 in trusty ppc64el: universe/libdevel/optional/100% -> main libsodium18 1.0.8-5~ubuntu14.04.1 in trusty amd64: universe/libs/optional/100% -> main libsodium18 1.0.8-5~ubuntu14.04.1 in trusty arm64: universe/libs/optional/100% -> main libsodium18 1.0.8-5~ubuntu14.04.1 in trusty armhf: universe/libs/optional/100% -> main libsodium18 1.0.8-5~ubuntu14.04.1 in trusty i386: universe/libs/optional/100% -> main libsodium18 1.0.8-5~ubuntu14.04.1 in trusty powerpc: universe/libs/optional/100% -> main libsodium18 1.0.8-5~ubuntu14.04.1 in trusty ppc64el: universe/libs/optional/100% -> main 19 publications overridden. ** Changed in: libsodium (Ubuntu Trusty) Status: In Progress => 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/1621386 Title: [MIR] libsodium Status in libsodium package in Ubuntu: Fix Released Status in libsodium source package in Trusty: Fix Released Status in libsodium source package in Xenial: In Progress Bug description: [Availability] The package is currently available in universe, currently imported directly from Debian with no Ubuntu specific patches. [Rationale] libsodium is a dependency of ZeroMQ, which in turn is a dependency of unity-scopes-api. Therefore, we will need to include it in main to support Unity 8. [Security] I couldn't find any CVEs or other advisories for the libsodium library, or djb's "nacl" library (http://nacl.cr.yp.to/) that it is derived from. [Quality Assurance] Package is a library, so not something end users will interact with directly. There are other apps and libraries in universe that currently link with libsodium, and install without issue. The library asks no debconf questions on install. Bugs are tracked in Debian and Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/libsodium https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libsodium The one Ubuntu bug looks like it might be user confusion about -dev packages. The one Debian report is complaining about Debian packaging an old version of libsodium: something that seems to have since been fixed but not noted in the bug report. New releases appear to be packaged in Debian promptly (https://packages.qa.debian.org/libs/libsodium.html), and the latest Debian release was recently migrated into Yakkety. The package is a software crypto library, so doesn't rely on exotic hardware. Library has a test suite that is run as part of the package build. The package has a debian/watch file checking for new releases on github. [UI Standards] The package contains a non-graphical crypto library. [Dependencies] The libsodium18 binary package only depends on libc6. For source build-depends, there is debhelper, pkg-config, and dh-autoreconf. All are already in main. [Maintenance] The package currently lists ubuntu-devel-discuss as its maintainer. It doesn't look like we've ever made any changes to the versions of the package migrated from Debian though. [Background information] The package has reasonable description strings and hasn't been renamed recently. The source package name matches the upstream project name. [ABI Stability] The library is plain C, so should be fairly robust. The upstream developers committed to API and ABI stability with the 1.0.0 release (October 2014): https://github.com/jedisct1/libsodium/releases/tag/1.0.0 A bit worryingly though, they changed soname in the 1.0.6 release (November 2015): https://github.com/jedisct1/libsodium/releases/tag/1.0.6 The changelog seems to indicate that the release should have been compatible but they changed soname just to be sure. It is unclear whether
[Group.of.nepali.translators] [Bug 1817327] Re: [Mir] python-libnacl
Override component to main python-libnacl 1.4.5-0ubuntu1~ubuntu14.04.1 in trusty: universe/python -> main 1 publication overridden. Override component to main python3-libnacl 1.4.5-0ubuntu1~ubuntu14.04.1 in trusty amd64: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1~ubuntu14.04.1 in trusty arm64: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1~ubuntu14.04.1 in trusty armhf: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1~ubuntu14.04.1 in trusty i386: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1~ubuntu14.04.1 in trusty powerpc: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1~ubuntu14.04.1 in trusty ppc64el: universe/python/optional/100% -> main 6 publications overridden. ** Changed in: python-libnacl (Ubuntu Trusty) Status: In Progress => 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/1817327 Title: [Mir] python-libnacl Status in python-libnacl package in Ubuntu: Invalid Status in python-libnacl source package in Trusty: Fix Released Status in python-libnacl source package in Xenial: Fix Released Bug description: # MIR for python-libnacl Availability: - - python-libnacl package is available in xenial-universe. - package needs to be uploaded to trusty and no previous version is present Rationale: -- - There is a newer dependency chain on python-nacl instead of python- libnacl in bionic and later already, but we do not want to introduce a risk of regression by adapting python-pymacaroons. - This is a new build dependency from ubuntu-advantage-tools package which will deliver the abilty to enable Ubuntu Advantage support entitlement. Security: - - No known CVEs Quality assurance: -- - Working defaults [its a library for external consumption] - It does not ask debconf questions - No long standing high or critical bugs in debian and upstream project - Maintainership looks active from both debian and upstream project - tests exist and are run during build - the package uses a debian/watch file - lintian notifications do not raise siginificant warnings - the package builds python2 elements but we are only pulling python3 binary UI standards: (generally only for user-facing applications) - - None Dependencies: - - libsodium which will be pulled in per LP: #1621386 Standards compliance: - Maintenance: - upstream and debian package maintenance is active and well maintained Background information: This is needed for the UA client and support pymacaroons - To avoid added risk in shifting python-pymacaroons to python-nacl package, we would like to introduce a separate package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-libnacl/+bug/1817327/+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 1817327] Re: [Mir] python-libnacl
Override component to main python-libnacl 1.4.5-0ubuntu1 in xenial: universe/python -> main 1 publication overridden. Override component to main python3-libnacl 1.4.5-0ubuntu1 in xenial amd64: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1 in xenial arm64: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1 in xenial armhf: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1 in xenial i386: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1 in xenial powerpc: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1 in xenial ppc64el: universe/python/optional/100% -> main python3-libnacl 1.4.5-0ubuntu1 in xenial s390x: universe/python/optional/100% -> main 7 publications overridden. ** Changed in: python-libnacl (Ubuntu Xenial) Status: In Progress => 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/1817327 Title: [Mir] python-libnacl Status in python-libnacl package in Ubuntu: Invalid Status in python-libnacl source package in Trusty: Fix Released Status in python-libnacl source package in Xenial: Fix Released Bug description: # MIR for python-libnacl Availability: - - python-libnacl package is available in xenial-universe. - package needs to be uploaded to trusty and no previous version is present Rationale: -- - There is a newer dependency chain on python-nacl instead of python- libnacl in bionic and later already, but we do not want to introduce a risk of regression by adapting python-pymacaroons. - This is a new build dependency from ubuntu-advantage-tools package which will deliver the abilty to enable Ubuntu Advantage support entitlement. Security: - - No known CVEs Quality assurance: -- - Working defaults [its a library for external consumption] - It does not ask debconf questions - No long standing high or critical bugs in debian and upstream project - Maintainership looks active from both debian and upstream project - tests exist and are run during build - the package uses a debian/watch file - lintian notifications do not raise siginificant warnings - the package builds python2 elements but we are only pulling python3 binary UI standards: (generally only for user-facing applications) - - None Dependencies: - - libsodium which will be pulled in per LP: #1621386 Standards compliance: - Maintenance: - upstream and debian package maintenance is active and well maintained Background information: This is needed for the UA client and support pymacaroons - To avoid added risk in shifting python-pymacaroons to python-nacl package, we would like to introduce a separate package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-libnacl/+bug/1817327/+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 1746772] Re: [MIR] pymacaroons, python-libnacl
Override component to main
pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial: universe/python -> main
1 publication overridden.
Override component to main
python3-pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial amd64:
universe/python/optional/100% -> main
python3-pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial arm64:
universe/python/optional/100% -> main
python3-pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial armhf:
universe/python/optional/100% -> main
python3-pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial i386:
universe/python/optional/100% -> main
python3-pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial powerpc:
universe/python/optional/100% -> main
python3-pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial ppc64el:
universe/python/optional/100% -> main
python3-pymacaroons 0.12.0-1~ubuntu16.04.1 in xenial s390x:
universe/python/optional/100% -> main
7 publications overridden.
** Changed in: pymacaroons (Ubuntu Xenial)
Status: In Progress => 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/1746772
Title:
[MIR] pymacaroons, python-libnacl
Status in pymacaroons package in Ubuntu:
Fix Released
Status in pymacaroons source package in Trusty:
Fix Released
Status in pymacaroons source package in Xenial:
Fix Released
Bug description:
pymacaroons
=
1. Availability: all
2. Rationale:
macaroon is a new dependency that MAAS will use. This provides the library
for macaroon based authentication, which MAAS will use for the support
remote/centralized authentication.
3. Security:
No CVE's
4. QA:
0 bugs in debian/ubuntu
5. UI standards:
None
6. Dependencies:
Dependencies in universe:
- python{3}-libnacl - Python 3 bindings for libsodium based on ctypes
7. Standards:
No lintian errors.
Packaged with debhelper. Source format is 3.0 (quilt)
Standards version: 3.9.8
8. Maintenance:
Easy.
9. Background information:
This package provides the macaroon library for MAAS to allow it to work for
macaroon based authentication systems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pymacaroons/+bug/1746772/+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 1746772] Re: [MIR] pymacaroons, python-libnacl
Override component to main
pymacaroons 0.9.2-0ubuntu1~ubuntu14.04.2 in trusty: universe/python -> main
1 publication overridden.
python3-pymacaroons 0.9.2-0ubuntu1~ubuntu14.04.2 in trusty amd64:
universe/python/optional/100% -> main
python3-pymacaroons 0.9.2-0ubuntu1~ubuntu14.04.2 in trusty arm64:
universe/python/optional/100% -> main
python3-pymacaroons 0.9.2-0ubuntu1~ubuntu14.04.2 in trusty armhf:
universe/python/optional/100% -> main
python3-pymacaroons 0.9.2-0ubuntu1~ubuntu14.04.2 in trusty i386:
universe/python/optional/100% -> main
python3-pymacaroons 0.9.2-0ubuntu1~ubuntu14.04.2 in trusty powerpc:
universe/python/optional/100% -> main
python3-pymacaroons 0.9.2-0ubuntu1~ubuntu14.04.2 in trusty ppc64el:
universe/python/optional/100% -> main
6 publications overridden.
** Changed in: pymacaroons (Ubuntu Trusty)
Status: In Progress => 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/1746772
Title:
[MIR] pymacaroons, python-libnacl
Status in pymacaroons package in Ubuntu:
Fix Released
Status in pymacaroons source package in Trusty:
Fix Released
Status in pymacaroons source package in Xenial:
Fix Released
Bug description:
pymacaroons
=
1. Availability: all
2. Rationale:
macaroon is a new dependency that MAAS will use. This provides the library
for macaroon based authentication, which MAAS will use for the support
remote/centralized authentication.
3. Security:
No CVE's
4. QA:
0 bugs in debian/ubuntu
5. UI standards:
None
6. Dependencies:
Dependencies in universe:
- python{3}-libnacl - Python 3 bindings for libsodium based on ctypes
7. Standards:
No lintian errors.
Packaged with debhelper. Source format is 3.0 (quilt)
Standards version: 3.9.8
8. Maintenance:
Easy.
9. Background information:
This package provides the macaroon library for MAAS to allow it to work for
macaroon based authentication systems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pymacaroons/+bug/1746772/+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 1824227] Re: console-setup failure due to race with systemd-tmpfiles
This bug was fixed in the package console-setup - 1.178ubuntu9.1 --- console-setup (1.178ubuntu9.1) cosmic; urgency=medium * setupcon: use /run for tempfiles (and dump the various unnecessary fallback paths), since /run is always mountable rw at least as early as /tmp is and is guaranteed to be safe from tmpcleaners at boot. Only keep /tmp as a fallback in case we have access to write to /tmp and to a console, but not to /run. LP: #1824227. -- Steve Langasek Wed, 10 Apr 2019 13:02:51 -0700 ** Changed in: console-setup (Ubuntu Cosmic) 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/1824227 Title: console-setup failure due to race with systemd-tmpfiles Status in console-setup package in Ubuntu: Fix Released Status in console-setup source package in Xenial: Fix Released Status in console-setup source package in Bionic: Fix Released Status in console-setup source package in Cosmic: Fix Released Status in console-setup source package in Disco: Fix Released Bug description: [SRU Justification] I'm seeing a console-setup.service failure quite regularly in testing where the temp file that should have been created can't be found. This is a regular xenial cloud image. 19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. ... 19:51:13 systemd[1]: Starting Set console font and keymap... 19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file 19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE 19:51:15 systemd[1]: Failed to start Set console font and keymap. 19:51:15 systemd[1]: console-setup.service: Unit entered failed state. 19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'. ... /bin/setupcon has a lovely tempfile function that looks like: if \ TMPFILE=`mktemp /tmp/tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp /run/tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp /dev/.tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp /lib/init/rw/tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp 2>/dev/null` Here's our edited IRC conversation on the bug: <@vorlon> so I do think you're being hit by the tmp cleaner <@vorlon> also this seems like bad pathological default behavior for the tmp cleaner, to delete files that have just been created <@vorlon> but we should fix console-setup to not rely on /tmp <@vorlon> and I prefer that we do that instead of trying to fiddle with the ordering of the systemd units on startup <@vorlon> i.e. console-setup has an undeclared dependency on systemd-tmpfiles-clean; let's remove the dependency instead of declaring it <@vorlon> are you failing the race more often now than in the past? <@rcj>vorlon: it feels like it's failing more often but I don't have data to answer that. <@vorlon> are we shipping an image with a dirty rootfs? <@vorlon> dirty in the sense that e2fsck doesn't take one look at it, say "yep, nothing to do here" and exit <@vorlon> in the sense that this is what would make dev-sda1.device slow to complete AIUI <@rcj>would filesystem resize on first boot mark it dirty? Because that will happen <@vorlon> huh good question <@vorlon> it might rcj, unclean shutdown? <@rcj>xnox: first boot [Test case] 1. Install console-setup from -proposed 2. Reboot 3. Verify that `systemctl status console-setup` shows that the service has completed successfully. Since this is a race, additional fuzz testing may be warranted for the cloud images to confirm that the issue experienced in GCE is really fixed. However, that should not block promotion of this SRU fix since there definitely is a race here that should be fixed per se even if there are other issues still causing a failure in GCE. [Regression potential] None known. /run is guaranteed to be mounted rw very early in boot - generally before /tmp is mounted, due to /tmp being on the rootfs that needs to be fscked before remount. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: console-setup 1.108ubuntu15.4 ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18 Uname: Linux 4.15.0-1029-gcp x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Wed Apr 10 19:24:12 2019 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: console-setup UpgradeStatus: No upgrade log present (probably fresh install) To manage
[Group.of.nepali.translators] [Bug 1824227] Re: console-setup failure due to race with systemd-tmpfiles
This bug was fixed in the package console-setup - 1.178ubuntu2.8 --- console-setup (1.178ubuntu2.8) bionic; urgency=medium * setupcon: use /run for tempfiles (and dump the various unnecessary fallback paths), since /run is always mountable rw at least as early as /tmp is and is guaranteed to be safe from tmpcleaners at boot. Only keep /tmp as a fallback in case we have access to write to /tmp and to a console, but not to /run. LP: #1824227. -- Steve Langasek Wed, 10 Apr 2019 13:13:34 -0700 ** Changed in: console-setup (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: console-setup (Ubuntu Xenial) 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/1824227 Title: console-setup failure due to race with systemd-tmpfiles Status in console-setup package in Ubuntu: Fix Released Status in console-setup source package in Xenial: Fix Released Status in console-setup source package in Bionic: Fix Released Status in console-setup source package in Cosmic: Fix Released Status in console-setup source package in Disco: Fix Released Bug description: [SRU Justification] I'm seeing a console-setup.service failure quite regularly in testing where the temp file that should have been created can't be found. This is a regular xenial cloud image. 19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. ... 19:51:13 systemd[1]: Starting Set console font and keymap... 19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file 19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE 19:51:15 systemd[1]: Failed to start Set console font and keymap. 19:51:15 systemd[1]: console-setup.service: Unit entered failed state. 19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'. ... /bin/setupcon has a lovely tempfile function that looks like: if \ TMPFILE=`mktemp /tmp/tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp /run/tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp /dev/.tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp /lib/init/rw/tmpkbd.XX 2>/dev/null` \ || TMPFILE=`mktemp 2>/dev/null` Here's our edited IRC conversation on the bug: <@vorlon> so I do think you're being hit by the tmp cleaner <@vorlon> also this seems like bad pathological default behavior for the tmp cleaner, to delete files that have just been created <@vorlon> but we should fix console-setup to not rely on /tmp <@vorlon> and I prefer that we do that instead of trying to fiddle with the ordering of the systemd units on startup <@vorlon> i.e. console-setup has an undeclared dependency on systemd-tmpfiles-clean; let's remove the dependency instead of declaring it <@vorlon> are you failing the race more often now than in the past? <@rcj>vorlon: it feels like it's failing more often but I don't have data to answer that. <@vorlon> are we shipping an image with a dirty rootfs? <@vorlon> dirty in the sense that e2fsck doesn't take one look at it, say "yep, nothing to do here" and exit <@vorlon> in the sense that this is what would make dev-sda1.device slow to complete AIUI <@rcj>would filesystem resize on first boot mark it dirty? Because that will happen <@vorlon> huh good question <@vorlon> it might rcj, unclean shutdown? <@rcj>xnox: first boot [Test case] 1. Install console-setup from -proposed 2. Reboot 3. Verify that `systemctl status console-setup` shows that the service has completed successfully. Since this is a race, additional fuzz testing may be warranted for the cloud images to confirm that the issue experienced in GCE is really fixed. However, that should not block promotion of this SRU fix since there definitely is a race here that should be fixed per se even if there are other issues still causing a failure in GCE. [Regression potential] None known. /run is guaranteed to be mounted rw very early in boot - generally before /tmp is mounted, due to /tmp being on the rootfs that needs to be fscked before remount. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: console-setup 1.108ubuntu15.4 ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18 Uname: Linux 4.15.0-1029-gcp x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Wed Apr 10 19:24:12 2019 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash
[Group.of.nepali.translators] [Bug 1822807] Re: linux-gcp: 4.15.0-1030.32~16.04.1 -proposed tracker
** Changed in: kernel-sru-workflow/regression-testing Status: Confirmed => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822808 phase: Testing phase-changed: Thursday, 11. April 2019 12:13 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: automated-testing: Stalled -- testing FAILED promote-to-updates: Pending -- nvidia GCP object not found -- 4.15.0-1030 - regression-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff verification-testing: Ongoing -- testing in progress -- 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/1822807 Title: linux-gcp: 4.15.0-1030.32~16.04.1 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Incomplete Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Fix Released Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-release-to-beta series: Fix Released Status in Kernel SRU Workflow snap-release-to-candidate series: Fix Released Status in Kernel SRU Workflow snap-release-to-edge series: Fix Released Status in Kernel SRU Workflow snap-release-to-stable series: Invalid Status in Kernel SRU Workflow verification-testing series: Confirmed Status in linux-gcp package in Ubuntu: Invalid Status in linux-gcp source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822808 phase: Testing phase-changed: Thursday, 11. April 2019 12:13 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: automated-testing: Stalled -- testing FAILED promote-to-updates: Pending -- nvidia GCP object not found -- 4.15.0-1030 security-signoff: Pending -- waiting for signoff verification-testing: Ongoing -- testing in progress To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1822807/+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 1808383] Re: Java 9+ multi-release jars are not supported in ant tasks
This bug was fixed in the package ant - 1.10.5-3~18.04 --- ant (1.10.5-3~18.04) bionic; urgency=medium * Backport for OpenJDK 11. LP: #1818647. ant (1.10.5-3) unstable; urgency=medium [ Matthias Klose ] * Mark binary packages as M-A: foreign. Closes: #925467. * Bump standards version. [ Tiago Stürmer Daitx ] * Enable multi release jar support. LP: #1808383. - debian/patches/0016-multirelease-jar-support.patch: apply 2 upstream patches to provide mrjar support. ant (1.10.5-2) unstable; urgency=medium * Team upload. * Lower the minimum required source/target level to 1.6 again. This is acceptable for OpenJDK 11 but must be reverted for OpenJDK 12. Thanks to Bdale Garbee for the report and patch. (Closes: #906785) * Declare compliance with Debian Policy 4.2.1. ant (1.10.5-1) unstable; urgency=medium * Team upload. * New upstream release * Replaced debian/orig-tar.sh with the Files-Excluded mechanism * Standards-Version updated to 4.1.5 ant (1.10.4-2) unstable; urgency=medium * Team upload. * Reverted the modification setting the 'release' attribute automatically since this renders the internal JDK APIs unavailable at compile time. (Closes: #902895) ant (1.10.4-1) unstable; urgency=medium * Team upload. * New upstream release - Refreshed the patches - Compile with hamcrest-all on the classpath ant (1.10.3-2) unstable; urgency=medium * Team upload. * Automatically set the value of the javac --release attribute to improve the backward compatibility of the code compiled with Java 9 or later. * Standards-Version updated to 4.1.4 * Use salsa.debian.org Vcs-* URLs -- Matthias Klose Thu, 28 Mar 2019 11:13:28 +0100 ** Changed in: ant (Ubuntu Cosmic) 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/1808383 Title: Java 9+ multi-release jars are not supported in ant tasks Status in ant package in Ubuntu: Fix Released Status in ant source package in Xenial: New Status in ant source package in Bionic: Fix Released Status in ant source package in Cosmic: Fix Released Status in ant source package in Disco: Fix Released Bug description: Reproduced in release: Ubuntu 18.04.1 LTS Version of ant used: 1.10.3-1ubuntu0.1 Having a multi-release jar with different .class files for Java 8 and Java 9, when using this jar in a custom ant task and running in Java 9+, the Java 8 class file will be loaded instead of the Java 9 one. This may lead to errors when the older class uses a deprecated/removed API. This can be easily reproduced using the code pushed to this repository: https://github.com/katanagari7c1/ant-mrjar-support-test This issue have already been reported in the ant bug tracker: https://bz.apache.org/bugzilla/show_bug.cgi?id=62952 It has already been fixed and will be introduced in next release 1.10.6: https://github.com/apache/ant/commit/593aff2d2ea52a025cfe7da32155216719029a7d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ant/+bug/1808383/+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 1808383] Re: Java 9+ multi-release jars are not supported in ant tasks
This bug was fixed in the package ant - 1.10.5-3~18.04 --- ant (1.10.5-3~18.04) bionic; urgency=medium * Backport for OpenJDK 11. LP: #1818647. ant (1.10.5-3) unstable; urgency=medium [ Matthias Klose ] * Mark binary packages as M-A: foreign. Closes: #925467. * Bump standards version. [ Tiago Stürmer Daitx ] * Enable multi release jar support. LP: #1808383. - debian/patches/0016-multirelease-jar-support.patch: apply 2 upstream patches to provide mrjar support. ant (1.10.5-2) unstable; urgency=medium * Team upload. * Lower the minimum required source/target level to 1.6 again. This is acceptable for OpenJDK 11 but must be reverted for OpenJDK 12. Thanks to Bdale Garbee for the report and patch. (Closes: #906785) * Declare compliance with Debian Policy 4.2.1. ant (1.10.5-1) unstable; urgency=medium * Team upload. * New upstream release * Replaced debian/orig-tar.sh with the Files-Excluded mechanism * Standards-Version updated to 4.1.5 ant (1.10.4-2) unstable; urgency=medium * Team upload. * Reverted the modification setting the 'release' attribute automatically since this renders the internal JDK APIs unavailable at compile time. (Closes: #902895) ant (1.10.4-1) unstable; urgency=medium * Team upload. * New upstream release - Refreshed the patches - Compile with hamcrest-all on the classpath ant (1.10.3-2) unstable; urgency=medium * Team upload. * Automatically set the value of the javac --release attribute to improve the backward compatibility of the code compiled with Java 9 or later. * Standards-Version updated to 4.1.4 * Use salsa.debian.org Vcs-* URLs -- Matthias Klose Thu, 28 Mar 2019 11:13:28 +0100 ** Changed in: ant (Ubuntu Bionic) 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/1808383 Title: Java 9+ multi-release jars are not supported in ant tasks Status in ant package in Ubuntu: Fix Released Status in ant source package in Xenial: New Status in ant source package in Bionic: Fix Released Status in ant source package in Cosmic: Fix Committed Status in ant source package in Disco: Fix Released Bug description: Reproduced in release: Ubuntu 18.04.1 LTS Version of ant used: 1.10.3-1ubuntu0.1 Having a multi-release jar with different .class files for Java 8 and Java 9, when using this jar in a custom ant task and running in Java 9+, the Java 8 class file will be loaded instead of the Java 9 one. This may lead to errors when the older class uses a deprecated/removed API. This can be easily reproduced using the code pushed to this repository: https://github.com/katanagari7c1/ant-mrjar-support-test This issue have already been reported in the ant bug tracker: https://bz.apache.org/bugzilla/show_bug.cgi?id=62952 It has already been fixed and will be introduced in next release 1.10.6: https://github.com/apache/ant/commit/593aff2d2ea52a025cfe7da32155216719029a7d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ant/+bug/1808383/+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 1822828] Re: linux-raspi2: 4.4.0-1107.115 -proposed tracker
** Changed in: kernel-sru-workflow/verification-testing Status: Confirmed => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822834 phase: Testing phase-changed: Monday, 15. April 2019 02:08 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff - verification-testing: Ongoing -- testing in progress -- 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/1822828 Title: linux-raspi2: 4.4.0-1107.115 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: In Progress Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Invalid Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-certification-testing series: Fix Released Status in Kernel SRU Workflow snap-release-to-beta series: Fix Released Status in Kernel SRU Workflow snap-release-to-candidate series: Fix Released Status in Kernel SRU Workflow snap-release-to-edge series: Fix Released Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-raspi2 package in Ubuntu: Invalid Status in linux-raspi2 source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822834 phase: Testing phase-changed: Monday, 15. April 2019 02:08 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1822828/+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 1822826] Re: linux-kvm: 4.4.0-1044.50 -proposed tracker
** Changed in: kernel-sru-workflow/verification-testing Status: Confirmed => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822834 phase: Signoff phase-changed: Friday, 05. April 2019 11:38 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: + promote-to-updates: Holding -- security signoff not verified security-signoff: Pending -- waiting for signoff - verification-testing: Ongoing -- testing in progress -- 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/1822826 Title: linux-kvm: 4.4.0-1044.50 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Fix Released Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-kvm package in Ubuntu: Invalid Status in linux-kvm source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822834 phase: Signoff phase-changed: Friday, 05. April 2019 11:38 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: promote-to-updates: Holding -- security signoff not verified security-signoff: Pending -- waiting for signoff To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1822826/+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 1822829] Re: linux-snapdragon: 4.4.0-1111.116 -proposed tracker
** Changed in: kernel-sru-workflow/verification-testing Status: Confirmed => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822834 phase: Testing phase-changed: Monday, 15. April 2019 02:08 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff - verification-testing: Ongoing -- testing in progress -- 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/1822829 Title: linux-snapdragon: 4.4.0-.116 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: In Progress Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Invalid Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-certification-testing series: Fix Released Status in Kernel SRU Workflow snap-release-to-beta series: Fix Released Status in Kernel SRU Workflow snap-release-to-candidate series: Fix Released Status in Kernel SRU Workflow snap-release-to-edge series: Fix Released Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-snapdragon package in Ubuntu: Invalid Status in linux-snapdragon source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1822834 phase: Testing phase-changed: Monday, 15. April 2019 02:08 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1822829/+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 1822834] Re: linux: 4.4.0-146.172 -proposed tracker
Verification testing completed successfully with this release. ** Changed in: kernel-sru-workflow/verification-testing 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/1822834 Title: linux: 4.4.0-146.172 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Incomplete Status in Kernel SRU Workflow certification-testing series: In Progress Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Confirmed Status in Kernel SRU Workflow security-signoff series: In Progress Status in Kernel SRU Workflow snap-certification-testing series: Fix Released Status in Kernel SRU Workflow snap-release-to-beta series: Fix Released Status in Kernel SRU Workflow snap-release-to-candidate series: Fix Released Status in Kernel SRU Workflow snap-release-to-edge series: Fix Released Status in Kernel SRU Workflow snap-release-to-stable series: New Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow backports: bug 1822833 (trusty/linux-lts-xenial), bug 1824775 (trusty/linux-aws) derivatives: bug 1822826 (linux-kvm), bug 1822828 (linux-raspi2), bug 1822829 (linux-snapdragon), bug 1822830 (linux-fips), bug 1824774 (linux-aws) -- swm properties -- boot-testing-requested: true bugs-spammed: true phase: Testing phase-changed: Thursday, 04. April 2019 18:05 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: automated-testing: Stalled -- testing FAILED certification-testing: Ongoing -- testing in progress regression-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff verification-testing: Ongoing -- testing in progress To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1822834/+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] [NEW] v3.7 is now the latest release
Public bug reported: https://github.com/sosreport/sos/releases/tag/3.7 --- The sos team is pleased to announce the release of sos-3.7. This is a significant release containing a large number of enhancements, new features, and bug fixes, including: New distribution policies for CentOS and Amazon Linux 19 new plugins: candlepin, cifs, cockpit, composer, crio, gssproxy, katello, openstack_novajoin, ovirt_node, peripety, podman, pulp, rasdaemon, rhcos, rhv_analyzer, rpmostree, ruby, stratis, sudo Obsolete IPSec plugin removed (in favour of OpenSwan) Support for passphrase and key based encryption of the report archive Ability to encrypt the archive using GPG, with either a key or passphrase New --encrypt-key and --encrypt-pass arguments to sosreport Improved handling of paths containing directory symbolic links (for e.g. /sys) Previous versions of sos would replace intermediate path components that contain a symbolic link to a directory in the host file system with an actual directory in the report archive. The host file system structure is now reflected properly in the report directory structure. New InitSystem abstraction Allows plugin and collection enablement based on the presence of a service, and methods to test whether a given service is currently running LVM2 plugin enhancements Locking fixes for LVM2 metadata and reporting output capture Additional LVM2 logical volume manager report data Append plugin exceptions to sos_logs/*-plugin-exception.txt Previous versions of sos would overwrite earlier exceptions if more than one exception occurred while running a plugin (for example, when an exception occurs in both setup() and postproc() phases). Dry run mode (--dry-run) Allows sos to run without collecting data, or executing commands, and proving a log of actions that would have been taken by a normal run on the current system configuration. Plugin API enhancements SoSPredicates for gating collection on service and kernel module presence, and during dry-run mode Significant enhancements to core features and existing plugins Fixes to threaded exception handling, and interactive debugging with --debug Support for OpenShift 3.10 deployments Improved multipath data collection Fixed RHEL Atomic default command line preset Support for PowerPC DLPAR and LPM logs Additional FIPS and crypto-policies data collection Test suite and CI support for Python-3.7 final Additional systemd listings and statuses Support for user-controlled per-plugin timeouts Do not leave report artefacts in TMP when executing list commands Improvements to command termination in the event of plugin timeouts Policy support for Red Hat Enterprise Linux 8.0 Improved STONITH and watchdog data collection for Pacemaker clusters Support for Debian journald logging in the logs plugin New built-in 'cantboot' preset for collecting information relevant to failed boots Ability to disable default presets on the command line (--preset=none) Support for setting all sosreport command line options (including global and plugin options) in the sos.conf configuration file The deprecated XML reporting module has been removed Continuous integration with the LGTM static analyser (rated 'A') Apache plugin fixed to support --log-size global option Native support for collecting foreman-debug equivalent data in sos --- ** Affects: sosreport (Ubuntu) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Cosmic) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Disco) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Ee-series) Importance: Low Assignee: Eric Desrochers (slashd) Status: In Progress ** Also affects: sosreport (Ubuntu Ee-series) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Ee-series) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Ee-series) Importance: Undecided => Low ** Changed in: sosreport (Ubuntu Ee-series) Status: New => In Progress ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs
[Group.of.nepali.translators] [Bug 1744079] Re: [SRU] disk over-commit still not correctly calculated during live migration
This bug was fixed in the package nova - 2:15.1.5-0ubuntu1~cloud3 --- nova (2:15.1.5-0ubuntu1~cloud3) xenial-ocata; urgency=medium . * d/p/(re)fix-disk-size-during-live-migration-with-disk-over-commit.patch: Cherry-picked from upstream ocata gerrit reviews to ensure disk size check is corectly calculated on the destination host for live migration with disk over-commit (LP: #1708572) (LP: #1744079). ** Changed in: cloud-archive/ocata 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/1744079 Title: [SRU] disk over-commit still not correctly calculated during live migration Status in Ubuntu Cloud Archive: Fix Committed Status in Ubuntu Cloud Archive mitaka series: New Status in Ubuntu Cloud Archive ocata series: Fix Released Status in Ubuntu Cloud Archive pike series: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Triaged Status in nova source package in Bionic: Fix Released Status in nova source package in Cosmic: Fix Released Status in nova source package in Disco: Fix Released Bug description: [Impact] nova compares disk space with disk_available_least field, which is possible to be negative, due to overcommit. So the migration may fail because of a "Migration pre-check error: Unable to migrate dfcd087a-5dff-439d-8875-2f702f081539: Disk of instance is too large(available on destination host:-3221225472 < need:22806528)" when trying a migration to another compute that has plenty of free space in his disk. [Test Case] Deploy openstack environment. Make sure there is a negative disk_available_least and a adequate free_disk_gb in one test compute node, then migrate a VM to it with disk-overcommit (openstack server migrate --live --block-migration --disk-overcommit ). You will see above migration pre-check error. This is the formula to compute disk_available_least and free_disk_gb. disk_free_gb = disk_info_dict['free'] disk_over_committed = self._get_disk_over_committed_size_total() available_least = disk_free_gb * units.Gi - disk_over_committed data['disk_available_least'] = available_least / units.Gi The following command can be used to query the value of disk_available_least nova hypervisor-show |grep disk Steps to Reproduce: 1. set disk_allocation_ratio config option > 1.0 2. qemu-img resize cirros-0.3.0-x86_64-disk.img +40G 3. glance image-create --disk-format qcow2 ... 4. boot VMs based on resized image 5. we see disk_available_least becomes negative [Regression Potential] Minimal - we're just changing from the following line: disk_available_gb = dst_compute_info['disk_available_least'] to the following codes: if disk_over_commit: disk_available_gb = dst_compute_info['free_disk_gb'] else: disk_available_gb = dst_compute_info['disk_available_least'] When enabling overcommit, disk_available_least is possible to be negative, so we should use free_disk_gb instead of it by backporting the following two fixes. https://git.openstack.org/cgit/openstack/nova/commit/?id=e097c001c8e0efe8879da57264fcb7bdfdf2 https://git.openstack.org/cgit/openstack/nova/commit/?id=e2cc275063658b23ed88824100919a6dfccb760d This is the code path for check_can_live_migrate_destination: _migrate_live(os-migrateLive API, migrate_server.py) -> migrate_server -> _live_migrate -> _build_live_migrate_task -> _call_livem_checks_on_host -> check_can_live_migrate_destination BTW, redhat also has a same bug - https://bugzilla.redhat.com/show_bug.cgi?id=1477706 [Original Bug Report] Change I8a705114d47384fcd00955d4a4f204072fed57c2 (written by me... sigh) addressed a bug which prevented live migration to a target host with overcommitted disk when made with microversion <2.25. It achieved this, but the fix is still not correct. We now do: if disk_over_commit: disk_available_gb = dst_compute_info['local_gb'] Unfortunately local_gb is *total* disk, not available disk. We actually want free_disk_gb. Fun fact: due to the way we calculate this for filesystems, without taking into account reserved space, this can also be negative. The test we're currently running is: could we fit this guest's allocated disks on the target if the target disk was empty. This is at least better than it was before, as we don't spuriously fail early. In fact, we're effectively disabling a test which is
[Group.of.nepali.translators] [Bug 1744079] Re: [SRU] disk over-commit still not correctly calculated during live migration
This bug was fixed in the package nova - 2:16.1.7-0ubuntu1~cloud2 --- nova (2:16.1.7-0ubuntu1~cloud2) xenial-pike; urgency=medium . * d/p/(re)fix-disk-size-during-live-migration-with-disk-over-commit.patch: Cherry-picked from upstream stable/pike branch to ensure disk size check is corectly calculated on the destination host for live migration with disk over-commit (LP: #1708572) (LP: #1744079). ** Changed in: cloud-archive/pike 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/1744079 Title: [SRU] disk over-commit still not correctly calculated during live migration Status in Ubuntu Cloud Archive: Fix Committed Status in Ubuntu Cloud Archive mitaka series: New Status in Ubuntu Cloud Archive ocata series: Fix Released Status in Ubuntu Cloud Archive pike series: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Triaged Status in nova source package in Bionic: Fix Released Status in nova source package in Cosmic: Fix Released Status in nova source package in Disco: Fix Released Bug description: [Impact] nova compares disk space with disk_available_least field, which is possible to be negative, due to overcommit. So the migration may fail because of a "Migration pre-check error: Unable to migrate dfcd087a-5dff-439d-8875-2f702f081539: Disk of instance is too large(available on destination host:-3221225472 < need:22806528)" when trying a migration to another compute that has plenty of free space in his disk. [Test Case] Deploy openstack environment. Make sure there is a negative disk_available_least and a adequate free_disk_gb in one test compute node, then migrate a VM to it with disk-overcommit (openstack server migrate --live --block-migration --disk-overcommit ). You will see above migration pre-check error. This is the formula to compute disk_available_least and free_disk_gb. disk_free_gb = disk_info_dict['free'] disk_over_committed = self._get_disk_over_committed_size_total() available_least = disk_free_gb * units.Gi - disk_over_committed data['disk_available_least'] = available_least / units.Gi The following command can be used to query the value of disk_available_least nova hypervisor-show |grep disk Steps to Reproduce: 1. set disk_allocation_ratio config option > 1.0 2. qemu-img resize cirros-0.3.0-x86_64-disk.img +40G 3. glance image-create --disk-format qcow2 ... 4. boot VMs based on resized image 5. we see disk_available_least becomes negative [Regression Potential] Minimal - we're just changing from the following line: disk_available_gb = dst_compute_info['disk_available_least'] to the following codes: if disk_over_commit: disk_available_gb = dst_compute_info['free_disk_gb'] else: disk_available_gb = dst_compute_info['disk_available_least'] When enabling overcommit, disk_available_least is possible to be negative, so we should use free_disk_gb instead of it by backporting the following two fixes. https://git.openstack.org/cgit/openstack/nova/commit/?id=e097c001c8e0efe8879da57264fcb7bdfdf2 https://git.openstack.org/cgit/openstack/nova/commit/?id=e2cc275063658b23ed88824100919a6dfccb760d This is the code path for check_can_live_migrate_destination: _migrate_live(os-migrateLive API, migrate_server.py) -> migrate_server -> _live_migrate -> _build_live_migrate_task -> _call_livem_checks_on_host -> check_can_live_migrate_destination BTW, redhat also has a same bug - https://bugzilla.redhat.com/show_bug.cgi?id=1477706 [Original Bug Report] Change I8a705114d47384fcd00955d4a4f204072fed57c2 (written by me... sigh) addressed a bug which prevented live migration to a target host with overcommitted disk when made with microversion <2.25. It achieved this, but the fix is still not correct. We now do: if disk_over_commit: disk_available_gb = dst_compute_info['local_gb'] Unfortunately local_gb is *total* disk, not available disk. We actually want free_disk_gb. Fun fact: due to the way we calculate this for filesystems, without taking into account reserved space, this can also be negative. The test we're currently running is: could we fit this guest's allocated disks on the target if the target disk was empty. This is at least better than it was before, as we don't spuriously fail early. In fact, we're effectively disabling a test which is
[Group.of.nepali.translators] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest
** Changed in: ubuntu-power-systems Status: In Progress => Fix Released ** Changed in: ubuntu-power-systems Status: Fix Released => Fix Committed ** Also affects: util-linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: util-linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: util-linux (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: util-linux (Ubuntu Xenial) Status: In Progress => Fix Committed -- 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/1764628 Title: incorrect hypervisor and virtualization type reported in compat mode guest Status in The Ubuntu-power-systems project: Fix Committed Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Committed Bug description: [IMPACT] In xenial lscpu prints the wrong "Hypervisor vendor" and "Virtualization type" on PowerVM or KVM systems. Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC. [TEST] Curent output: ubuntu@P8lpar3:~$ dpkg -l "*util-linux*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii util-linux 2.31.1-0.4ub ppc64el miscellaneous system utilities un util-linux-loc (no description available) ubuntu@P8lpar3:~$ lscpu Architecture:ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s):2 Model: 2.1 (pvr 004b 0201) Model name: POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 ubuntu@P8lpar3:~$ Expected Output: $ lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):128 On-line CPU(s) list: 0-127 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 16 NUMA node(s): 2 Model: 2.1 (pvr 004b 0201) Model name:POWER8 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 64K L1i cache: 32K NUMA node0 CPU(s): NUMA node4 CPU(s): 0-127 [Potential Regression] The fix changes the logic to how lscpu-dmi returns from read_hypervisor_dmi() this could introduce potential regression in platforms that has incorrect DMI information. [Other Info] ---uname output--- Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux Machine Type = boston-LC ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC: root@guest:/tmp# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):2 On-line CPU(s) list: 0,1 Thread(s) per core:2 Core(s) per socket:1 Socket(s): 1 NUMA node(s): 1 Model: 2.2 (pvr 004e 1202) Model name:POWER8 (architected), altivec supported >> Hypervisor vendor: horizontal >> Virtualization type: full L1d cache: 32K L1i cache: 32K NUMA node0 CPU(s): 0,1 Stack trace output: no Oops output: no We test what is coming along with distro. If you are not able to see issue with : https://launchpad.net/ubuntu/+source/util- linux/2.27.1-6ubuntu3.5 .. can we get this included in 16.04.x train ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1764628/+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 1818880] Re: Deadlock when detaching network interface
** Changed in: cloud-archive/mitaka 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/1818880 Title: Deadlock when detaching network interface Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive mitaka series: Fix Released Status in Ubuntu Cloud Archive ocata series: Fix Released Status in Ubuntu Cloud Archive pike series: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Won't Fix Status in Ubuntu Cloud Archive stein series: Fix Released Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Xenial: Fix Released Status in qemu source package in Bionic: Fix Released Status in qemu source package in Cosmic: Fix Released Status in qemu source package in Disco: Fix Released Bug description: [Impact] Qemu guests hang indefinitely [Description] When running a Qemu guest with VirtIO network interfaces, detaching an interface that's currently being used can result in a deadlock. The guest instance will hang and become unresponsive to commands, and the only option is to kill -9 the instance. The reason for this is a dealock between a monitor and an RCU thread, which will fight over the BQL (qemu_global_mutex) and the critical RCU section locks. The monitor thread will acquire the BQL for detaching the network interface, and fire up a helper thread to deal with detaching the network adapter. That new thread needs to wait on the RCU thread to complete the deletion, but the RCU thread wants the BQL to commit its transactions. This bug is already fixed upstream (73c6e4013b4c rcu: completely disable pthread_atfork callbacks as soon as possible) and included for other series (see below), so we don't need to backport it to Bionic onwards. Upstream commit: https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c $ git describe --contains 73c6e4013b4c v2.10.0-rc2~1^2~8 $ rmadison qemu ===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe | amd64, ... qemu | 1:2.11+dfsg-1ubuntu7| bionic/universe | amd64, ... qemu | 1:2.12+dfsg-3ubuntu8| cosmic/universe | amd64, ... qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe| amd64, ... [Test Case] Being a racing condition, this is a tricky bug to reproduce consistently. We've had reports of users running into this with OpenStack deployments and Windows Server guests, and the scenario is usually like this: 1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface 2) Stress the network interface with e.g. Windows HLK test suite or similar 3) Repeatedly attach/detach the network adapter that's in use It usually takes more than ~4000 attach/detach cycles to trigger the bug. [Regression Potential] Regressions for this might arise from the fact that the fix changes RCU lock code. Since this patch has been upstream and in other series for a while, it's unlikely that it would regressions in RCU code specifically. Other code that makes use of the RCU locks (MMIO and some monitor events) will be thoroughly tested for any regressions with use-case scenarios and scripted runs. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+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 1822129] Re: [SRU] leave device name empty so that nova can determine it instead
** Also affects: horizon (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: horizon (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: horizon (Ubuntu Xenial) Status: New => In Progress ** Changed in: horizon (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) -- 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/1822129 Title: [SRU] leave device name empty so that nova can determine it instead Status in Ubuntu Cloud Archive: Confirmed Status in Ubuntu Cloud Archive pike series: Confirmed Status in Ubuntu Cloud Archive queens series: Confirmed Status in Ubuntu Cloud Archive rocky series: Confirmed Status in Ubuntu Cloud Archive stein series: Confirmed Status in horizon package in Ubuntu: Fix Released Status in horizon source package in Xenial: In Progress Status in horizon source package in Bionic: In Progress Status in horizon source package in Cosmic: In Progress Status in horizon source package in Disco: Fix Released Bug description: [IMPACT] Horizon hardcoded 'vda' no matter what (legacy code) for boot volume scenarios. Meaning that if for instance we use an image with scsi decoration[1] horizon will name the device_name as 'vda' when it should be 'sda'. Inside the instance, it will be 'sda' but horizon will show 'vda', if you then attach a second volume the volume will be seen as 'sda' in horizon, but 'sdb' in the instance and so on ... creating a inconsistency, and can also cause in certain circumstance VM to have issue to successfully reboot, hanging with "No bootable device". There is 2 functions (thus fixes) separated as follow: * setFinalSpecBootImageToVolume() which already uses BDMv2, in this case it was just a matter to remove the 'device_name' attribute as suggested per documentation[2]. This function take care of boot image from volume scenario. -> https://review.openstack.org/#/c/644982/ * setFinalSpecBootFromVolumeDevice() which currently uses BDMv1 (legacy), in this case an upgrade to BDMv2 without setting up a 'device_name' attribute is sufficient to fix the issue. This function take care of booting from existing volume and snapshot. -> https://review.openstack.org/648328/ Basically, with theses 2 fixes, it is no longer relying on "vol_device_name= 'vda'" as it was before as it is no longer needed since Liberty (again as per documentation) An instance with scsi decoration will properly show 'sda' and without will show 'vda'.'vda' will still be taken when it's the right thing to do, but not because it is hardcorded like it used to before these fixes. [1] - scsi meta decoration: hw_disk_bus='scsi' hw_scsi_model='virtio-scsi' [2]- https://docs.openstack.org/nova/stein/user/block-device-mapping [TEST CASE] Here's some use case I can think of With fix 1 in setFinalSpecBootImageToVolume(): * Test #1: Use scsi meta data image decoration: hw_disk_bus='scsi' hw_scsi_model='virtio-scsi' 1. Go to the Horizon dashboard and launch an instance 2. Select "Boot from image (creates a new volume)" as Instance Boot Source Expected result: Instance should starts with /dev/sda as root device, instead of 'dev/vda' * Test #2: Use no scsi meta data image decoration 1. Go to the Horizon dashboard and launch an instance 2. Select "Boot from image (creates a new volume)" as Instance Boot Source Expected result: Instance will remain with /dev/vda as root device. No behaviour change here. With fix 2 in setFinalSpecBootFromVolumeDevice(): * Test #1: Creating a server using an existing volume or volume snapshot. [POTENTIAL REGRESSION] * none expected, we basically leave nova to determine the device_name instead of having it force for Horizon by removing the 'device_name' attribute, and we also take benefit of it to upgrade some part of the code from legacy BDMv1 in flavor of BDMv2. * Note: This will not fix device name inconsistency already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced. * Both fixes aren't dependant and can be SRU'd separately. [OTHER INFORMATION] * Upstream bug: https://bugs.launchpad.net/nova/+bug/1560965 * Upstream git-review: # Taking care of bootimagefromvolume https://review.openstack.org/644982/ https://github.com/openstack/horizon/commit/4788c4d2f59b8aa08e5f599a6d2c327b6004dc0c # Taking care of existing volume and snapshot https://review.openstack.org/648328/ * Upstream Cherry Pick request: https://review.openstack.org/#/q/I9d114c2c2e6736a8f1a8092afa568f930b656f0 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1822129/+subscriptions
[Group.of.nepali.translators] [Bug 1794232] Re: Geneve tunnels don't work when ipv6 is disabled
** Changed in: linux (Ubuntu Disco) Status: In Progress => Fix Released ** Description changed: [Impact] When attempting to create a geneve tunnel on Ubuntu 16.04 Xenial, in an OS environment with open vswitch, where ipv6 has been disabled, the create fails with the error : “ovs-vsctl: Error detected while setting up 'geneve0': could not add network device geneve0 to ofproto (Address family not supported by protocol)." [Fix] - There is an upstream commit for this in v5.0 mainline. + There is an upstream commit for this in v5.0 mainline. "geneve: correctly handle ipv6.disable module parameter" Commit: cf1c9ccba7308e48a68fa77f476287d9d614e4c7 - This fix is needed on all our series: X, C, B, D. It is identical + This fix is needed on all our series prior to Disco and the v5.0 kernel: X, C, B. It is identical to the fix we implemented and tested internally with, but - had not pushed upstream yet. - + had not pushed upstream yet. [Test Case] (Best to do this on a kvm guest VM so as not to interfere with your system's networking) 1. On any Ubuntu Xenial kernel, disable ipv6. This example is shown with the4.15.0-23-generic kernel (which differs slightly from 4.4.x in symptoms): - Edit /etc/default/grub to add the line: GRUB_CMDLINE_LINUX="ipv6.disable=1" - # update-grub - Reboot 2. Install OVS # apt install openvswitch-switch 3. Create a Geneve tunnel # ovs-vsctl add-br br1 # ovs-vsctl add-port br1 geneve1 -- set interface geneve1 type=geneve options:remote_ip=192.168.x.z (where remote_ip is the IP of the other host) You will see the following error message: "ovs-vsctl: Error detected while setting up 'geneve1'. See ovs-vswitchd log for details." From /var/log/openvswitch/ovs-vswitchd.log you will see: "2018-07-02T16:48:13.295Z|00026|dpif|WARN|system@ovs-system: failed to add geneve1 as port: Address family not supported by protocol" You will notice from the "ifconfig" output that the device genev_sys_6081 is not created. If you do not disable IPv6 (remove ipv6.disable=1 from /etc/default/grub + update-grub + reboot), the same 'ovs-vsctl add-port' command completes successfully. You can see that it is working properly by adding an IP to the br1 and pinging each host. On kernel 4.4 (4.4.0-128-generic), the error message doesn't happen using the 'ovs-vsctl add-port' command, no warning is shown in ovs-vswitchd.log, but the device genev_sys_6081 is also not created and ping test won't work. - With the fixed test kernel, the interfaces and tunnel + With the fixed test kernel, the interfaces and tunnel is created successfully. - [Other Info] * Analysis Geneve tunnels should work with either IPv4 or IPv6 environments as a design and support principle. Currently, however, what's in the implementation requires support for ipv6 for metadata-based tunnels which geneve is: rather than: a) ipv4 + metadata // whether ipv6 compiled or dynamically disabled b) ipv4 + metadata + ipv6 What enforces this in the current 4.4.0-x code when opening a Geneve tunnel is the following in geneve_open() : bool ipv6 = geneve->remote.sa.sa_family == AF_INET6; bool metadata = geneve->collect_md; ... #if IS_ENABLED(CONFIG_IPV6) geneve->sock6 = NULL; if (ipv6 || metadata) ret = geneve_sock_add(geneve, true); #endif if (!ret && (!ipv6 || metadata)) ret = geneve_sock_add(geneve, false); CONFIG_IPV6 is enabled, IPv6 is disabled at boot, but even though ipv6 is false, metadata is always true for a geneve open as it is set unconditionally in ovs: In /lib/dpif_netlink_rtnl.c : case OVS_VPORT_TYPE_GENEVE: nl_msg_put_flag(, IFLA_GENEVE_COLLECT_METADATA); The second argument of geneve_sock_add is a boolean value indicating whether it's an ipv6 address family socket or not, and we thus incorrectly pass a true value rather than false. The current "|| metadata" check is unnecessary and incorrectly sends the tunnel creation code down the ipv6 path, which fails subsequently when the code expects an ipv6 family socket. * This issue exists in all versions of the kernel upto present mainline and net-next trees. * Testing with a trivial patch to remove that and make similar changes to those made for vxlan (which had the same issue) has been successful. Patches for various versions to be attached here soon. * Example Versions (bug exists in all versions of Ubuntu and mainline): $ uname -r 4.4.0-135-generic $ lsb_release -rd Description: Ubuntu 16.04.5 LTS Release: 16.04 $ dpkg -l | grep openvswitch-switch ii openvswitch-switch 2.5.4-0ubuntu0.16.04.1 ** Description changed: [Impact] When attempting to
[Group.of.nepali.translators] [Bug 1794232] Re: Geneve tunnels don't work when ipv6 is disabled
We had tested a patch discussed above and tested internally, with success - although we have limited testing (opening up a geneve tunnel between 2 kvm guests). Jiri has now pushed an identical patch upstream which is available in the v5.0 kernel and later. "geneve: correctly handle ipv6.disable module parameter" Commit: cf1c9ccba7308e48a68fa77f476287d9d614e4c7 Although I do not have testing validation from original poster, since it has been committed upstream, I'm going to go ahead and get the SRU request started. ** Changed in: linux (Ubuntu) Status: Triaged => In Progress ** Changed in: linux (Ubuntu) Importance: Medium => High ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: High Status: In Progress ** Changed in: linux (Ubuntu Cosmic) Status: New => In Progress ** Changed in: linux (Ubuntu Disco) Assignee: (unassigned) => Nivedita Singhvi (niveditasinghvi) ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => Nivedita Singhvi (niveditasinghvi) ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Nivedita Singhvi (niveditasinghvi) ** Changed in: linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux (Ubuntu Cosmic) Importance: Undecided => High ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => High ** Description changed: [Impact] - When attempting to create a geneve tunnel on Ubuntu 16.04 Xenial, in - an OS environment with open vswitch, where ipv6 has been disabled, + When attempting to create a geneve tunnel on Ubuntu 16.04 Xenial, in + an OS environment with open vswitch, where ipv6 has been disabled, the create fails with the error : - “ovs-vsctl: Error detected while setting up 'geneve0': could not - add network device geneve0 to ofproto (Address family not supported + “ovs-vsctl: Error detected while setting up 'geneve0': could not + add network device geneve0 to ofproto (Address family not supported by protocol)." - + [Fix] + There is an upstream commit for this in v5.0 mainline. + + "geneve: correctly handle ipv6.disable module parameter" + Commit: cf1c9ccba7308e48a68fa77f476287d9d614e4c7 + + This fix is needed on all our series: X, C, B, D + + [Test Case] - (Best to do this on a kvm guest VM so as not to interfere with - your system's networking) + (Best to do this on a kvm guest VM so as not to interfere with + your system's networking) 1. On any Ubuntu Xenial kernel, disable ipv6. This example -is shown with the4.15.0-23-generic kernel (which differs -slightly from 4.4.x in symptoms): - + is shown with the4.15.0-23-generic kernel (which differs + slightly from 4.4.x in symptoms): + - Edit /etc/default/grub to add the line: - GRUB_CMDLINE_LINUX="ipv6.disable=1" + GRUB_CMDLINE_LINUX="ipv6.disable=1" - # update-grub - Reboot - 2. Install OVS # apt install openvswitch-switch 3. Create a Geneve tunnel # ovs-vsctl add-br br1 - # ovs-vsctl add-port br1 geneve1 -- set interface geneve1 + # ovs-vsctl add-port br1 geneve1 -- set interface geneve1 type=geneve options:remote_ip=192.168.x.z (where remote_ip is the IP of the other host) You will see the following error message: - "ovs-vsctl: Error detected while setting up 'geneve1'. + "ovs-vsctl: Error detected while setting up 'geneve1'. See ovs-vswitchd log for details." From /var/log/openvswitch/ovs-vswitchd.log you will see: - "2018-07-02T16:48:13.295Z|00026|dpif|WARN|system@ovs-system: - failed to add geneve1 as port: Address family not supported + "2018-07-02T16:48:13.295Z|00026|dpif|WARN|system@ovs-system: + failed to add geneve1 as port: Address family not supported by protocol" - You will notice from the "ifconfig" output that the device + You will notice from the "ifconfig" output that the device genev_sys_6081 is not created. - If you do not disable IPv6 (remove ipv6.disable=1 from - /etc/default/grub + update-grub + reboot), the same - 'ovs-vsctl add-port' command completes successfully. - You can see that it is working properly by adding an - IP to the br1 and pinging each host. + If you do not disable IPv6 (remove ipv6.disable=1 from + /etc/default/grub + update-grub + reboot), the same + 'ovs-vsctl add-port' command completes successfully. + You can see that it is working properly by adding an + IP to the br1 and pinging each host. - On kernel 4.4 (4.4.0-128-generic), the error message doesn't - happen using the 'ovs-vsctl add-port' command, no warning is - shown in ovs-vswitchd.log, but the device genev_sys_6081 is + On kernel 4.4 (4.4.0-128-generic), the error message doesn't + happen using the 'ovs-vsctl add-port' command, no warning is + shown in ovs-vswitchd.log, but the device genev_sys_6081 is also
[Group.of.nepali.translators] [Bug 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux kernel
command line in the dmesg (journalctl -k -b). And it is consistently
failing on arm64 scalingstack KVM EFI machines with messages of "missing
81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
+ Please backport this to xenial and up.
- Please backport this to xenial and up.
+
+
+ === systemd ===
+
+ systemd, boot-and-services test case can bump the ring buffer before
+ running the tests.
--
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/1824864
Title:
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
Status in linux package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
New
Status in linux source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
New
Status in linux source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
New
Status in linux source package in Cosmic:
Confirmed
Status in systemd source package in Cosmic:
New
Status in linux source package in Disco:
Confirmed
Status in systemd source package in Disco:
New
Status in linux source package in EE-Series:
Confirmed
Status in systemd source package in EE-Series:
New
Bug description:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux
kernel command line in the dmesg (journalctl -k -b). And it is
consistently failing on arm64 scalingstack KVM EFI machines with
messages of "missing 81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
Please backport this to xenial and up.
=== systemd ===
systemd, boot-and-services test case can bump the ring buffer before
running the tests.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864/+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 :
[Group.of.nepali.translators] [Bug 1824774] Re: linux-aws: 4.4.0-1081.91 -proposed tracker
** Changed in: kernel-sru-workflow/prepare-package Status: In Progress => Fix Released ** Changed in: kernel-sru-workflow/prepare-package-meta Status: In Progress => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- kernel-stable-master-bug: 1822834 - phase: Packaging - phase-changed: Tuesday, 16. April 2019 01:10 UTC + phase: Holding before Promote to Proposed + phase-changed: Tuesday, 16. April 2019 08:40 UTC reason: - prepare-package: Pending -- package not yet uploaded - prepare-package-meta: Pending -- package not yet uploaded + promote-to-proposed: Holding -- builds not complete -- 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/1824774 Title: linux-aws: 4.4.0-1081.91 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: New Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: New Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: New Status in Kernel SRU Workflow security-signoff series: New Status in Kernel SRU Workflow snap-release-to-beta series: New Status in Kernel SRU Workflow snap-release-to-candidate series: New Status in Kernel SRU Workflow snap-release-to-edge series: New Status in Kernel SRU Workflow snap-release-to-stable series: Invalid Status in Kernel SRU Workflow verification-testing series: New Status in linux-aws package in Ubuntu: Invalid Status in linux-aws source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- kernel-stable-master-bug: 1822834 phase: Holding before Promote to Proposed phase-changed: Tuesday, 16. April 2019 08:40 UTC reason: promote-to-proposed: Holding -- builds not complete To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1824774/+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 1744079] Re: [SRU] disk over-commit still not correctly calculated during live migration
** Also affects: cloud-archive/mitaka Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1744079 Title: [SRU] disk over-commit still not correctly calculated during live migration Status in Ubuntu Cloud Archive: Fix Committed Status in Ubuntu Cloud Archive mitaka series: New Status in Ubuntu Cloud Archive ocata series: Fix Committed Status in Ubuntu Cloud Archive pike series: Fix Committed Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Triaged Status in nova source package in Bionic: Fix Released Status in nova source package in Cosmic: Fix Released Status in nova source package in Disco: Fix Released Bug description: [Impact] nova compares disk space with disk_available_least field, which is possible to be negative, due to overcommit. So the migration may fail because of a "Migration pre-check error: Unable to migrate dfcd087a-5dff-439d-8875-2f702f081539: Disk of instance is too large(available on destination host:-3221225472 < need:22806528)" when trying a migration to another compute that has plenty of free space in his disk. [Test Case] Deploy openstack environment. Make sure there is a negative disk_available_least and a adequate free_disk_gb in one test compute node, then migrate a VM to it with disk-overcommit (openstack server migrate --live --block-migration --disk-overcommit ). You will see above migration pre-check error. This is the formula to compute disk_available_least and free_disk_gb. disk_free_gb = disk_info_dict['free'] disk_over_committed = self._get_disk_over_committed_size_total() available_least = disk_free_gb * units.Gi - disk_over_committed data['disk_available_least'] = available_least / units.Gi The following command can be used to query the value of disk_available_least nova hypervisor-show |grep disk Steps to Reproduce: 1. set disk_allocation_ratio config option > 1.0 2. qemu-img resize cirros-0.3.0-x86_64-disk.img +40G 3. glance image-create --disk-format qcow2 ... 4. boot VMs based on resized image 5. we see disk_available_least becomes negative [Regression Potential] Minimal - we're just changing from the following line: disk_available_gb = dst_compute_info['disk_available_least'] to the following codes: if disk_over_commit: disk_available_gb = dst_compute_info['free_disk_gb'] else: disk_available_gb = dst_compute_info['disk_available_least'] When enabling overcommit, disk_available_least is possible to be negative, so we should use free_disk_gb instead of it by backporting the following two fixes. https://git.openstack.org/cgit/openstack/nova/commit/?id=e097c001c8e0efe8879da57264fcb7bdfdf2 https://git.openstack.org/cgit/openstack/nova/commit/?id=e2cc275063658b23ed88824100919a6dfccb760d This is the code path for check_can_live_migrate_destination: _migrate_live(os-migrateLive API, migrate_server.py) -> migrate_server -> _live_migrate -> _build_live_migrate_task -> _call_livem_checks_on_host -> check_can_live_migrate_destination BTW, redhat also has a same bug - https://bugzilla.redhat.com/show_bug.cgi?id=1477706 [Original Bug Report] Change I8a705114d47384fcd00955d4a4f204072fed57c2 (written by me... sigh) addressed a bug which prevented live migration to a target host with overcommitted disk when made with microversion <2.25. It achieved this, but the fix is still not correct. We now do: if disk_over_commit: disk_available_gb = dst_compute_info['local_gb'] Unfortunately local_gb is *total* disk, not available disk. We actually want free_disk_gb. Fun fact: due to the way we calculate this for filesystems, without taking into account reserved space, this can also be negative. The test we're currently running is: could we fit this guest's allocated disks on the target if the target disk was empty. This is at least better than it was before, as we don't spuriously fail early. In fact, we're effectively disabling a test which is disabled for microversion >=2.25 anyway. IOW we should fix it, but it's probably not a high priority. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1744079/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe :
[Group.of.nepali.translators] [Bug 1768452] Re: Unable to insert test_bpf module for ubuntu_bpf_jit on Xenial s390x
** Also affects: linux (Ubuntu Disco) Importance: Medium Status: 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/1768452 Title: Unable to insert test_bpf module for ubuntu_bpf_jit on Xenial s390x Status in ubuntu-kernel-tests: Confirmed Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Confirmed Status in linux source package in Disco: Confirmed Bug description: After the test_bpf insert issue for Xenial was fixed in bug 1765698 But it looks like the s390x needs some extra work. $ sudo modprobe test_bpf modprobe: ERROR: could not insert 'test_bpf': Invalid argument 4 tests failed here: test_bpf: #243 BPF_MAXINSNS: Ctx heavy transformations FAIL to prog_create err=-524 len=4096 test_bpf: #244 BPF_MAXINSNS: Call heavy transformations FAIL to prog_create err=-524 len=4096 test_bpf: #249 BPF_MAXINSNS: ld_abs+get_processor_id FAIL to prog_create err=-524 len=4096 test_bpf: #250 BPF_MAXINSNS: ld_abs+vlan_push/pop FAIL to select_runtime err=-524 Complete test result: https://pastebin.ubuntu.com/p/zMDwVjwF7X/ ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-123-generic 4.4.0-123.147 ProcVersionSignature: Ubuntu 4.4.0-123.147-generic 4.4.128 Uname: Linux 4.4.0-123-generic s390x NonfreeKernelModules: zfs zunicode zcommon znvpair zavl AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.1-0ubuntu2.16 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found. Date: Wed May 2 03:45:22 2018 HibernationDevice: RESUME=UUID=f578fa27-1d57-41c9-bb1d-7ff64c1c9345 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: Error: [Errno 2] No such file or directory: '/proc/fb' ProcKernelCmdLine: root=UUID=f26894a2-496d-4891-aa9a-f66344c9 crashkernel=196M BOOT_IMAGE=0 RelatedPackageVersions: linux-restricted-modules-4.4.0-123-generic N/A linux-backports-modules-4.4.0-123-generic N/A linux-firmware 1.157.17 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1768452/+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
