[Group.of.nepali.translators] [Bug 1515513] Re: /boot/initrd.img-*.old-dkms files left behind
** No longer affects: initramfs-tools (Ubuntu) ** No longer affects: initramfs-tools (Ubuntu Xenial) ** No longer affects: initramfs-tools (Ubuntu Zesty) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1515513 Title: /boot/initrd.img-*.old-dkms files left behind Status in dkms package in Ubuntu: Fix Released Status in dkms source package in Xenial: Fix Released Status in dkms source package in Zesty: Fix Released Status in dkms package in Debian: New Bug description: [Impact] If a dkms package is installed which has REMAKE_INITRD or the same setting has be manually configured by a user then when a kernel is removed its possible for an ".old-dkms" file to be left in /boot with no associated kernel. [Test Case] On a system with two old kernels and one new kernel available in -updates: 1) install r8168-dkms 2) install the dkms module for the old kernel e.g. 'sudo dkms install -m r8168 -v 8.041.00 -k 4.4.0-31-generic' 3) upgrade your kernel e.g. "sudo apt install linux-image-generic' 4) sudo apt autoremove 5) observe something like "initrd.img-4.4.0-31-generic.old-dkms" in /boot without a corresponding "initrd.img-4.4.0-31-generic" With the version of dkms in -proposed, the .old-dkms file will be removed when the kernel is auto removed. [Regression Potential] Somebody out there might expect the .old-dkms file to be kept, but that seems like an odd expectation. One notices *.old-dkms files being left behind still sitting on the disk after purging the related kernel. This can cause /boot to become full, and when it gets really bad, even sudo apt-get autoremove won't fix the problem - only deleting the old-dkms files manually solves the problem. Note: Filling up the /boot partition causes updates to fail. ProblemType: BugDistroRelease: Ubuntu 15.04 Package: dkms 2.2.0.3-2ubuntu3.3 ProcVersionSignature: Ubuntu 3.19.0-28.30-generic 3.19.8-ckt5 Uname: Linux 3.19.0-28-generic x86_64 ApportVersion: 2.17.2-0ubuntu1.7 Architecture: amd64 CurrentDesktop: KDE Date: Thu Nov 12 08:17:10 2015 InstallationDate: Installed on 2015-05-05 (190 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) PackageArchitecture: allSourcePackage: dkms UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1515513/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
** No longer affects: cups (Ubuntu Trusty) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1811471] Re: local resolver stub fails to handle multiple TCP dns queries
** Bug watch added: github.com/systemd/systemd/issues #11332 https://github.com/systemd/systemd/issues/11332 ** Also affects: systemd via https://github.com/systemd/systemd/issues/11332 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1811471 Title: local resolver stub fails to handle multiple TCP dns queries Status in systemd: Unknown Status in systemd package in Ubuntu: In Progress Status in systemd source package in Trusty: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] The systemd local 'stub' resolver handles all local DNS queries (by default configuration used in Ubuntu), and essentially proxies all requests to its configured upstream DNS resolvers. Most local DNS resolution by applications uses glibc's getaddrinfo() function. This function is configured in various ways by the /etc/resolv.conf file, which tells glibc what nameserver/resolver to contact as well as how to talk to the name server. By default, glibc performs UDP DNS queries, with a single DNS query per UDP packet. The UDP packet size is limited per DNS spec to 512 bytes. For some DNS lookups, a 512 byte UDP packet is not large enough to contain the entire response - for example, an A record lookup with a large number (e.g. 30) of A record addresses. This number of A record entries is possible in some cases of load balancing. When the DNS UDP response size is larger than 512 bytes, the server puts as much response as it can into the DNS UDP response, and marks the "trunacted" flag. This lets glibc know that the DNS UDP packet did not contain the entire response for all the A records. When glibc sees a UDP response that is "trunacted", by default it ignores the contents of that response and issues a new DNS query, using TCP instead of UDP. The TCP packet size has a higher size limit (though see bug 1804487 which is a bug in systemd's max-sizing of TCP DNS packets), and so *should* allow glibc to receive the entire DNS response. However, glibc issues DNS queries for both A and records. When it uses UDP, those DNS queries are separate (i.e. one UDP DNS packet with a single A query, and one UDP DNS packet with a single query). When glibc uses TCP, it puts both DNS queries into a single TCP DNS packet - the RFC refers to this as "pipelining" (https://tools.ietf.org/html/rfc7766#section-6.2.1.1) and states that clients SHOULD do this, and that servers MUST expect to receive pipelined queries and SHOULD respond to all of them. (Technically pipelining can be separate DNS queries, one per TCP packet, but both using the same TCP connection - but the clear intention of pipelining is to improve TCP performance, and putting both DNS queries into a single TCP packet is clearly more performant than using separate TCP packets). Unfortunately, systemd's local stub resolver has only very basic support for TCP DNS, and it handles TCP DNS queries almost identically to UDP DNS queries - it reads the DNS query 2-byte header (containing the length of the query data), reads in the single DNS query data, performs lookup and sends a response to that DNS query, and closes the TCP connection. It does not check for "pipelined" queries in the TCP connection. That would be bad enough, as glibc is (rightly) expecting a response to both its A and queries; however what glibc gets is a TCP connection-reset error. That is because the local systemd stub resolver has closed its TCP socket while input data was still pending (i.e. it never even read the second pipelined DNS query). When the kernel sees unread input bytes in a TCP connection that is closed, it sends a TCP RST to the peer (i.e. glibc) and when the kernel sees the RST, it dumps all data in its socket buffer and passes the ECONNRESET error up to the application. So glibc gets nothing besides a connection reset error. Note also that even if the systemd local stub resolver's socket flushes its input buffer before closing the TCP connection (which will avoid the TCP RST), glibc still expects responses to both its A and queries before systemd closes the TCP connection, and so a simple change to systemd to flush the input buffer is not enough to fix the bug (and would also not actually fix the bug since glibc would never get the response). [Test Case] This can be reproduced on any system using a local systemd stub resolver, when using an application that uses getaddrinfo() - such as ssh, telnet, ping, etc - or
[Group.of.nepali.translators] [Bug 1807439] Re: openvpn crashes when run with fips openssl
This bug was fixed in the package openvpn - 2.4.6-1ubuntu3 --- openvpn (2.4.6-1ubuntu3) disco; urgency=medium * d/p/openvpn-fips-2.4.patch: Allow MD5 in FIPS mode (openssl) for PRF. (LP: #1807439) -- Joy Latten Wed, 09 Jan 2019 12:25:59 -0600 ** Changed in: openvpn (Ubuntu Disco) 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/1807439 Title: openvpn crashes when run with fips openssl Status in OpenVPN: Unknown Status in openvpn package in Ubuntu: Fix Released Status in openvpn source package in Xenial: New Status in openvpn source package in Bionic: New Status in openvpn source package in Cosmic: New Status in openvpn source package in Disco: Fix Released Bug description: [IMPACT] openvpn segfaults when using fips-mode openssl because of MD5. xenial has version 2.3.x and subsequent releases have 2.4.x. MD5 is used in 2 places in 2.3.x and one place in 2.4.x. First place: openvpn when estabishing a tls connection will segfault when used with Ubuntu's FIPS 140-2 libcrypto.so (openssl). openvpn tls connection does TLS PRF(pseudorandom function) to produce securely generated pseudo random output that is used to generate keys. MD5 is used as the hash in this computation. FIPS 140-2 does not permit MD5 use except when used for pseudorandom function (PRF). When openvpn requests MD5 operation to FIPS-mode libcrypto.so, since it is not allowed in general, FIPS-mode libcrypto.so goes into an error state. The context flag value, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW, is defined in both FIPS and non-FIPS libcrypto.so. However, the MD5 check for it is only in FIPS-mode libcrypto.so to permit MD5. In non-FIPS libcrypto.so this check does not exist since it always permits MD5. openvpn should use this flag when it makes its MD5 request. Second place (only in 2.3.x): **NOTE: The openvpn 2.3 version in xenial has the above issue and an additional one. It also use MD5 internally for configuration status verification. It is not communicated externally. However, this particular use of MD5 is not allowed by FIPS and thus when openvpn tries to use FIPS-mode libcrypto.so to compute MD5, it results in openvpn segfaulting. This 2nd issue was fixed by upstream openvpn community in subsequent versions(2.4) to not use MD5 and use SHA(256) instead and thus why bionic, cosmic, and disco do not require any change for this 2nd issue. [TEST] Test data including commands and parameters are included below. Testing comprised establishing a tls connection between an openvpn client and server. Once the connection was successfully established, a ping thru the established vpn tunnel was done from the client for assurance. Interoperability testing was done to ensure no regression. Test data reflects testing was done between openvpn server and client with and without the patch and between various releases (xenial, bionic, and disco). Test was also done with FIPS-enabled libcrypto.so to ensure everything worked in FIPS mode. [REGRESSION] The context flag value, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW, is defined in both FIPS-mode openssl and non-FIPS openssl. However, the MD5-permit check against this flag-value does not occur in non-FIPS libcrypto.so, so there should be no change in behaviour. non-FIPS libcrypto.so should continue to service all MD5 requests. xenial with version 2.3.x, has additional change of using SHA instead of MD5 for configuration status verification. This is an internal hash that is not communicated externally. Thus it should not regress interoperability or ability to establish connections. To manage notifications about this bug go to: https://bugs.launchpad.net/openvpn/+bug/1807439/+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 1710390] Re: iwlwifi: Microcode SW error detected. Restarting 0x2000000
This is actually about two bugs in one and related to bug 1804841 Lets disambiguate them. One can be avoided by a config in network-manager as mentioned in comment #19 Lets handle this bug here as "that one" - at least in Bionic and later - fixed by being set by default. This was initially fixed in 1.12.4-1ubuntu1 >From changelog: - NetworkManager.conf: disable MAC randomization feature. There is no easy way for desktop users to disable this feature yet. And there are reports that it doesn't work well with some systems. And also became part of Bionic in 1.10.6-2ubuntu1 I'm marking this bug fixed since Bionic due to that. --- Everyone else still affected despite this workaround has another yet unclarified issue. This shall be tracked in bug 1804841 ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Status: New => Fix Released ** Changed in: linux (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Xenial) Status: New => Incomplete -- 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/1710390 Title: iwlwifi: Microcode SW error detected. Restarting 0x200 Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Incomplete Status in linux source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Bug description: This bug was resolved (see 1588632) On ubuntu 17.04 recent update from kernel 4.10.0-30-generic to 4.10.0-32-generic has resulted in a regression, reintroducing this bug. iwlwifi :03:00.0: Microcode SW error detected. Restarting 0x200. [ 12.294262] iwl_pcie_irq_handle_error+0x39/0x160 [iwlwifi] --- ApportVersion: 2.20.4-0ubuntu4.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: janice 1664 F pulseaudio CurrentDesktop: XFCE DistroRelease: Ubuntu 17.04 HibernationDevice: RESUME=UUID=be1fb904-a9f5-4c1f-a154-349c0a6e63de InstallationDate: Installed on 2016-07-12 (396 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160712) MachineType: Dell Inc. Dell System XPS 15Z Package: linux (not installed) ProcFB: 0 nouveaufb 1 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-30-generic root=UUID=c280c3d0-6ec1-4080-9d10-74acc2399bad ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 4.10.0-30.34-generic 4.10.17 RelatedPackageVersions: linux-restricted-modules-4.10.0-30-generic N/A linux-backports-modules-4.10.0-30-generic N/A linux-firmware 1.164.1 Tags: zesty Uname: Linux 4.10.0-30-generic x86_64 UpgradeStatus: Upgraded to zesty on 2017-03-11 (153 days ago) UserGroups: adm cdrom dip lpadmin plugdev root sambashare sudo www-data _MarkForUpload: True dmi.bios.date: 09/07/2012 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 0XK6HV dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 0.1 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd09/07/2012:svnDellInc.:pnDellSystemXPS15Z:pvr:rvnDellInc.:rn0XK6HV:rvrA00:cvnDellInc.:ct8:cvr0.1: dmi.product.name: Dell System XPS 15Z dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1710390/+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 1807439] Re: openvpn crashes when run with fips openssl
** Also affects: openvpn via https://community.openvpn.net/openvpn/ticket/725 Importance: Unknown Status: Unknown -- 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/1807439 Title: openvpn crashes when run with fips openssl Status in OpenVPN: Unknown Status in openvpn package in Ubuntu: New Status in openvpn source package in Xenial: New Status in openvpn source package in Bionic: New Status in openvpn source package in Cosmic: New Status in openvpn source package in Disco: New Bug description: [IMPACT] openvpn segfaults when using fips-mode openssl because of MD5. xenial has version 2.3.x and subsequent releases have 2.4.x. MD5 is used in 2 places in 2.3.x and one place in 2.4.x. First place: openvpn when estabishing a tls connection will segfault when used with Ubuntu's FIPS 140-2 libcrypto.so (openssl). openvpn tls connection does TLS PRF(pseudorandom function) to produce securely generated pseudo random output that is used to generate keys. MD5 is used as the hash in this computation. FIPS 140-2 does not permit MD5 use except when used for pseudorandom function (PRF). When openvpn requests MD5 operation to FIPS-mode libcrypto.so, since it is not allowed in general, FIPS-mode libcrypto.so goes into an error state. The context flag value, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW, is defined in both FIPS and non-FIPS libcrypto.so. However, the MD5 check for it is only in FIPS-mode libcrypto.so to permit MD5. In non-FIPS libcrypto.so this check does not exist since it always permits MD5. openvpn should use this flag when it makes its MD5 request. Second place (only in 2.3.x): **NOTE: The openvpn 2.3 version in xenial has the above issue and an additional one. It also use MD5 internally for configuration status verification. It is not communicated externally. However, this particular use of MD5 is not allowed by FIPS and thus when openvpn tries to use FIPS-mode libcrypto.so to compute MD5, it results in openvpn segfaulting. This 2nd issue was fixed by upstream openvpn community in subsequent versions(2.4) to not use MD5 and use SHA(256) instead and thus why bionic, cosmic, and disco do not require any change for this 2nd issue. [TEST] Test data including commands and parameters are included below. Testing comprised establishing a tls connection between an openvpn client and server. Once the connection was successfully established, a ping thru the established vpn tunnel was done from the client for assurance. Interoperability testing was done to ensure no regression. Test data reflects testing was done between openvpn server and client with and without the patch and between various releases (xenial, bionic, and disco). Test was also done with FIPS-enabled libcrypto.so to ensure everything worked in FIPS mode. [REGRESSION] The context flag value, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW, is defined in both FIPS-mode openssl and non-FIPS openssl. However, the MD5-permit check against this flag-value does not occur in non-FIPS libcrypto.so, so there should be no change in behaviour. non-FIPS libcrypto.so should continue to service all MD5 requests. xenial with version 2.3.x, has additional change of using SHA instead of MD5 for configuration status verification. This is an internal hash that is not communicated externally. Thus it should not regress interoperability or ability to establish connections. To manage notifications about this bug go to: https://bugs.launchpad.net/openvpn/+bug/1807439/+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 1811432] [NEW] linux-gcp: -proposed tracker
Public bug reported: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. 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: 1811419 reason: prepare-package: Stalled -- waiting for master bug ** Affects: kernel-sru-workflow Importance: Medium Status: In Progress ** Affects: kernel-sru-workflow/automated-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/certification-testing Importance: Medium Assignee: Canonical Hardware Certification (canonical-hw-cert) Status: Invalid ** Affects: kernel-sru-workflow/prepare-package Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-meta Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-signed Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/promote-to-proposed Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-security Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-updates Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/regression-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/security-signoff Importance: Medium Assignee: Canonical Security Team (canonical-security) Status: New ** Affects: kernel-sru-workflow/snap-release-to-beta Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/snap-release-to-candidate Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/snap-release-to-edge Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/snap-release-to-stable Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/upload-to-ppa Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/verification-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: linux-gcp (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux-gcp (Ubuntu Xenial) Importance: Medium Status: Confirmed ** Tags: kernel-release-tracking-bug kernel-release-tracking-bug-live kernel-sru-backport-of-1811419 kernel-sru-cycle-2019.01.14-1 xenial ** Tags added: kernel-release-tracking-bug ** Tags added: kernel-release-tracking-bug-live ** Also affects: linux-gcp (Ubuntu Xenial) Importance: Undecided Status: New ** Tags added: xenial ** Changed in: linux-gcp (Ubuntu Xenial) Status: New => Confirmed ** Also affects: kernel-sru-workflow/automated-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/certification-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-meta Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-signed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-proposed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-security Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-updates Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/regression-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/security-signoff Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/snap-release-to-beta Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/snap-release-to-candidate Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/snap-release-to-edge Importance: Undecided Status: New ** Also affects:
[Group.of.nepali.translators] [Bug 1811431] [NEW] linux-azure: -proposed tracker
Public bug reported: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. 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: 1811419 reason: prepare-package: Stalled -- waiting for master bug ** Affects: kernel-sru-workflow Importance: Medium Status: In Progress ** Affects: kernel-sru-workflow/automated-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/certification-testing Importance: Medium Assignee: Canonical Hardware Certification (canonical-hw-cert) Status: Invalid ** Affects: kernel-sru-workflow/prepare-package Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-meta Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-signed Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/promote-to-proposed Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-security Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-updates Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/regression-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/security-signoff Importance: Medium Assignee: Canonical Security Team (canonical-security) Status: New ** Affects: kernel-sru-workflow/snap-release-to-beta Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/snap-release-to-candidate Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/snap-release-to-edge Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/snap-release-to-stable Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/stakeholder-signoff Importance: Medium Assignee: linux-azure stakeholder signoff (linux-azure-signoff) Status: New ** Affects: kernel-sru-workflow/upload-to-ppa Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/verification-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: linux-azure (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux-azure (Ubuntu Xenial) Importance: Medium Status: Confirmed ** Tags: kernel-release-tracking-bug kernel-release-tracking-bug-live kernel-sru-backport-of-1811419 kernel-sru-cycle-2019.01.14-1 xenial ** Tags added: kernel-release-tracking-bug ** Tags added: kernel-release-tracking-bug-live ** Also affects: linux-azure (Ubuntu Xenial) Importance: Undecided Status: New ** Tags added: xenial ** Changed in: linux-azure (Ubuntu Xenial) Status: New => Confirmed ** Also affects: kernel-sru-workflow/automated-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/certification-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-meta Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-signed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-proposed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-security Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-updates Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/regression-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/security-signoff Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/snap-release-to-beta Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/snap-release-to-candidate Importance: Undecided
[Group.of.nepali.translators] [Bug 1811434] [NEW] linux-hwe: -proposed tracker
Public bug reported: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. 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: 1811419 reason: prepare-package: Stalled -- waiting for master bug ** Affects: kernel-sru-workflow Importance: Medium Status: In Progress ** Affects: kernel-sru-workflow/automated-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/certification-testing Importance: Medium Assignee: Canonical Hardware Certification (canonical-hw-cert) Status: New ** Affects: kernel-sru-workflow/prepare-package Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-meta Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-signed Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/promote-to-proposed Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-security Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-updates Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/regression-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/security-signoff Importance: Medium Assignee: Canonical Security Team (canonical-security) Status: New ** Affects: kernel-sru-workflow/upload-to-ppa Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/verification-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: linux-hwe (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux-hwe (Ubuntu Xenial) Importance: Medium Status: Confirmed ** Tags: kernel-release-tracking-bug kernel-release-tracking-bug-live kernel-sru-backport-of-1811419 kernel-sru-cycle-2019.01.14-1 xenial ** Tags added: kernel-release-tracking-bug ** Tags added: kernel-release-tracking-bug-live ** Also affects: linux-hwe (Ubuntu Xenial) Importance: Undecided Status: New ** Tags added: xenial ** Changed in: linux-hwe (Ubuntu Xenial) Status: New => Confirmed ** Also affects: kernel-sru-workflow/automated-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/certification-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-meta Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-signed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-proposed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-security Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-updates Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/regression-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/security-signoff Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/upload-to-ppa Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/verification-testing Importance: Undecided Status: New ** Changed in: kernel-sru-workflow/automated-testing Importance: Undecided => Medium ** Changed in: kernel-sru-workflow/automated-testing Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) ** Changed in: kernel-sru-workflow/certification-testing Importance: Undecided => Medium ** Changed in: kernel-sru-workflow/certification-testing Assignee: (unassigned) => Canonical Hardware Certification (canonical-hw-cert) ** Changed in: kernel-sru-workflow/prepare-package Importance: Undecided => Medium ** Changed in: kernel-sru-workflow/prepare-package Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) ** Changed in: kernel-sru-workflow/prepare-package-meta Importance: Undecided => Medium ** Changed in: kernel-sru-workflow/prepare-package-meta
[Group.of.nepali.translators] [Bug 1811418] [NEW] linux-azure-edge: -proposed tracker
Public bug reported: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. 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: 1811406 reason: prepare-package: Stalled -- waiting for master bug ** Affects: kernel-sru-workflow Importance: Medium Status: In Progress ** Affects: kernel-sru-workflow/automated-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/certification-testing Importance: Medium Assignee: Canonical Hardware Certification (canonical-hw-cert) Status: Invalid ** Affects: kernel-sru-workflow/prepare-package Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-meta Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/prepare-package-signed Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/promote-to-proposed Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-security Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/promote-to-updates Importance: Medium Assignee: Ubuntu Stable Release Updates Team (ubuntu-sru) Status: New ** Affects: kernel-sru-workflow/regression-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/security-signoff Importance: Medium Assignee: Canonical Security Team (canonical-security) Status: New ** Affects: kernel-sru-workflow/stakeholder-signoff Importance: Medium Assignee: Canonical Kernel Distro Team (canonical-kernel-distro-team) Status: New ** Affects: kernel-sru-workflow/upload-to-ppa Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: kernel-sru-workflow/verification-testing Importance: Medium Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Affects: linux-azure-edge (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux-azure-edge (Ubuntu Xenial) Importance: Medium Status: Confirmed ** Tags: kernel-release-tracking-bug kernel-release-tracking-bug-live kernel-sru-backport-of-1811406 kernel-sru-cycle-2019.01.14-1 xenial ** Tags added: kernel-release-tracking-bug ** Tags added: kernel-release-tracking-bug-live ** Also affects: linux-azure-edge (Ubuntu Xenial) Importance: Undecided Status: New ** Tags added: xenial ** Changed in: linux-azure-edge (Ubuntu Xenial) Status: New => Confirmed ** Also affects: kernel-sru-workflow/automated-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/certification-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-meta Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/prepare-package-signed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-proposed Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-security Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/promote-to-updates Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/regression-testing Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/security-signoff Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/stakeholder-signoff Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/upload-to-ppa Importance: Undecided Status: New ** Also affects: kernel-sru-workflow/verification-testing Importance: Undecided Status: New ** Changed in: kernel-sru-workflow/automated-testing Importance: Undecided => Medium ** Changed in: kernel-sru-workflow/automated-testing Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) ** Changed in: kernel-sru-workflow/certification-testing Importance: Undecided => Medium ** Changed in: kernel-sru-workflow/certification-testing Assignee: (unassigned) => Canonical Hardware Certification (canonical-hw-cert) ** Changed in: kernel-sru-workflow/certification-testing
[Group.of.nepali.translators] [Bug 1808366] Re: Led trigger not working on rpi3b+
** Also affects: linux-raspi2 (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1808366 Title: Led trigger not working on rpi3b+ Status in linux-raspi2 package in Ubuntu: Invalid Status in linux-raspi2 source package in Xenial: New Bug description: Impact: User are reporting that the green led (the one next to the red power led) is not working on the RaspberryPi 3B+ board. After debugging the issue, this is what i found: 1) during boot, all leds are initialized in a function loop, and if one of them fails to setup, the loop tears down all initialized instances: ... [2.299216] leds-gpio: probe of soc:leds failed with error -2 ... in this particular case, it's not the green action led that fails to initialize, but it's red power led that fails and the loop tears down both of them but since the red (by default) is connected to Vcc, it stays lit (see point 3 below for more info on the wiring) so we have the impression that the one to fail is the green one. This can easily tested by adding debug to drivers/leds/leds- gpio.c::gpio_leds_create() and drivers/leds/leds- gpio.c::gpio_led_probe(), or commenting out the red pwr_led block in arch/arm/boot/dts/bcm2710-rpi-3-b-plus.dts - the board will boot up, the above leds-gpio error will disappear and the green action led will work properly. 2) the pwr_led in the rpi3 b+ is not available direcly to the OS, instead only the Broadcom firmware can access its gpio, thus a new mechanism (the exgpio driver) that uses the bcm firmware as a middleman was developed: using a mailbox mechanism, messages are sent from the Linux kernel to the Broadcom firmware to query or set the status of the led, this way it's possible to plumb the Linux led subsystem to this gpio 3) the biasing of the two leds (power and action) is "opposite" and can be easily confirmed by looking at the board schematics[1]: -D5 (the action led) uses the transistor Q5 in a switch configuration - when Q5 is not biased, it acts as an open switch and no current goes through the led - so by default the led is off -D6 (the power led) uses Q4 in a sink configuration - when Q4 is off, current normally flows through the led, while when Q4 is biased, all current is sinked to GND via Q4 - the led by default on Fix: The fix is composed of 8 patches: 1f50a81 UBUNTU: [Config] GPIO_BCM_EXP=y 53bc3cc UBUNTU: SAUCE: dts: rpi3: remove hpd-gpios overwrite a1252a5 UBUNTU: SAUCE: dts: cm3: revert hpd-gpios to gpio 0d136d8 UBUNTU: SAUCE: make pwr_led GPIO_ACTIVE_LOW e2d3ba2 UBUNTU: SAUCE: make it build on bcm2709 245fc18 Revert "UBUNTU: SAUCE: dts: use the virtgpio driver" be25728 bcm2835-gpio-exp: Copy/paste error adding base twice 4ccdf22 bcm2835-gpio-exp: Driver for GPIO expander via mailbox service From the bottom: -patch 0001 and 002 contain the "gpio via firmware" exgpio driver (and a fix for it) - those are the original patches that are present in the Github's RaspberryPi repository[2] rpi-4.9.y branch, and they were cherry-picked cleanly from it (minus same mechanical changes in Kconfig and Makefile surrounding context to make it apply). -patch 0003 reverts a change that tried to pilot pwr led gpio using the default virtgpio driver -patch 004 fixes the arch name - in 4.9 where the driver originated, the Raspberry arch was called "ARCH_BCM2835", while in Xenial 4.4 is "ARCH_BCM2709". -patch 005 fixes the pwr led biasing level -patch 006 and 007 reduce the "regression surface": when patch 001 was introduced in 4.9, the hdmi phy in the RaspberryPi3 and CM3 was moved to use the new driver, but since our hdmi driver is significantly different from the one in the rpy-4.9 tree, and since this bug deal only with leds and noone has opened one against the hvmi video output, to reduce the regression surface, i reverted these chunks in the new driver (using these two SAUCE patches) and kept using the mechanism we used so far in Xenial. -patch 008 enable the new driver By apply these patches, the power led correctly initialize during boot, and as a consequence the action led work too. How to test: Add this to config.txt: dtparam=act_led_trigger=heartbeat dtparam=pwr_led_trigger=heartbeat and reboot - on a non-patched kernel, the power led (red) will be always-on, while the action led (green) will be off. On a patched kernel, both leds will blink intermittently. Regression: It's new code, so there's always regression potential in it, but by reducing the scope of the original patch, the impact is limited to the led code, and only applies to the RaspberryPi3B+ board. 1:
[Group.of.nepali.translators] [Bug 1810372] Re: Infinite busy-loop trying to cull when cache space is short
** Also affects: cachefilesd (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: cachefilesd (Ubuntu Trusty)
Status: New => In Progress
** Changed in: cachefilesd (Ubuntu Xenial)
Status: New => In Progress
** Changed in: cachefilesd (Ubuntu Trusty)
Assignee: (unassigned) => Daniel Axtens (daxtens)
** Changed in: cachefilesd (Ubuntu Xenial)
Assignee: (unassigned) => Daniel Axtens (daxtens)
** Changed in: cachefilesd (Ubuntu Trusty)
Importance: Undecided => Medium
** Changed in: cachefilesd (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: cachefilesd (Ubuntu)
Importance: Undecided => Medium
** Changed in: cachefilesd (Ubuntu)
Status: Confirmed => Fix Released
** Description changed:
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started
on a filesystem where the free space is less than the bcull threshold
and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that
culling is required, tries to cull, and does not realise that culling
cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid
filesystem to over the bcull threshold, and started cachefilesd. When running
top, the cachefilesd process is at the top using approx 100% of 1 CPU. It
appears to be trying to free up space in the cache (that is not even used)
because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with
minimal effort.
[Other Info]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk
space is short.")
+
+ Since bionic has version 0.10.10-0.1, this fix is needed only for xenial
+ and trusty.
--
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/1810372
Title:
Infinite busy-loop trying to cull when cache space is short
Status in cachefilesd package in Ubuntu:
Fix Released
Status in cachefilesd source package in Trusty:
In Progress
Status in cachefilesd source package in Xenial:
In Progress
Bug description:
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when
started on a filesystem where the free space is less than the bcull
threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that
culling is required, tries to cull, and does not realise that culling
cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid
filesystem to over the bcull threshold, and started cachefilesd. When running
top, the cachefilesd process is at the top using approx 100% of 1 CPU. It
appears to be trying to free up space in the cache (that is not even used)
because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with
minimal effort.
[Other Info]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk
space is short.")
Since bionic has version 0.10.10-0.1, this fix is needed only for
xenial and trusty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cachefilesd/+bug/1810372/+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 1550983] Re: Fails to start with "Couldn't open libGL.so.1" (missing dependency?)
Closing as all other bug tasks are showing "Fix Released" ** Changed in: hundredpapercuts 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/1550983 Title: Fails to start with "Couldn't open libGL.so.1" (missing dependency?) Status in One Hundred Papercuts: Fix Released Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Xenial: Fix Released Status in gtk+3.0 source package in Yakkety: Fix Released Status in gtk+3.0 package in Debian: Fix Released Bug description: [Impact] There are some unlinked calls to libGL.so.1 undetected in the build process because of using libepoxy. Running an application that does not depend on libgl1 (directly or indirectly) may lead to aborting the process with an undefined reference to libGL.so.1. [Test Case] 1. Deploy a server / cloud image of Xenial or Yakkety. 2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine. 3. sudo apt install firefox; firefox Expected result: firefox is launched on the client machine. Actual result: "Couldn't open libGL.so.1" message is printed. [Regression Potential] Minimal, it is an upstream change already released to zesty. It performs a runtime check for GL support and disables GLX function calls in case they're not available. [Other Info] Original bug description: virt-manager fails to start: $ virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with command line: /usr/share/virt-manager/virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) virt-manager version: 1.3.2 [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) virtManager import: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory $ Installing the 'libgl1-mesa-glx' package resolves the issue. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: virt-manager 1:1.3.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Sun Feb 28 19:19:27 2016 InstallationDate: Installed on 2016-02-27 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) PackageArchitecture: all SourcePackage: virt-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1550983/+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 1593469] Re: [2.0] VMware power type error: __init__() takes 1 positional argument but 2 were given
As far as I can see, this issue should now be fixed .If it's not, please reopen the bug with log output from the latest version. ** Changed in: maas Status: Incomplete => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1593469 Title: [2.0] VMware power type error: __init__() takes 1 positional argument but 2 were given Status in MAAS: Fix Released Status in python-pyvmomi package in Ubuntu: Fix Released Status in python-pyvmomi source package in Xenial: Fix Released Bug description: [Impact] python-pyvmomi in xenial is outdated and does not allow connecting to vsphere with TLS validation. Updating to 6.5 fixes this and probably a few other issues. [Test case] For example, >>> from pyVim.connect import SmartConnect >>> import ssl >>> context = ssl.SSLContext(ssl.PROTOCOL_SSLv23) >>> context.verify_mode = ssl.CERT_NONE >>> si = SmartConnect(host=host, user=user, pwd=password, port=port, sslContext=context) should work. This is basically a HWE type scenario. [Regression potential] Compatibility with vSphere 4.1 is not guaranteed anymore. Some bug fixes; and otherwise it's mostly just new data types and methods, so low likelihood of regressions on that side. As a bonus point, we won't have any changes to bionic. [Original bug report] When adding VMware power type in 2.0.0 beta7: Failed to query node's BMC - __init__() takes 1 positional argument but 2 were given The same VMware details (UUID, vCenter IP address, username/password, etc.) worked in an earlier version of the maas server, which was Ubuntu 14.04 / maas 1.9. 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) ||/ NameVersion Architecture Description +++-===---= ii maas2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all "Metal as a Service" is a physical cloud and IPAM ii maas-cli2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS client and command-line interface un maas-cluster-controller (no description available) ii maas-common 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS server common files ii maas-dhcp 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS DHCP server ii maas-dns2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS DNS server ii maas-proxy 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS Caching Proxy ii maas-rack-controller2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all Rack Controller for MAAS ii maas-region-api 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all Region controller API service for MAAS ii maas-region-controller 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all Region Controller for MAAS un maas-region-controller-min (no description available) un python-django-maas (no description available) un python-maas-client (no description available) un python-maas-provisioningserver (no description available) ii python3-django-maas 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS server Django web framework (Python 3) ii python3-maas-client 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS python API client (Python 3) ii python3-maas-provisioningserver 2.0.0~beta7+bzr5112-0ubuntu1~xenial1 all MAAS server provisioning libraries (Python 3) To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1593469/+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
