[Group.of.nepali.translators] [Bug 1870683] Re: xenial/linux-azure: 4.15.0-1082.92~16.04.1 -proposed tracker
Only some out-of-place (unneeded) tests are MISSing. Manually setting ADT. ** Changed in: kernel-sru-workflow/automated-testing 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/1870683 Title: xenial/linux-azure: 4.15.0-1082.92~16.04.1 -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 prepare-package-signed series: Fix Released 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: In Progress Status in Kernel SRU Workflow security-signoff series: Fix Released Status in Kernel SRU Workflow stakeholder-signoff series: Confirmed Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-azure 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: 1870673 packages: main: linux-azure meta: linux-meta-azure signed: linux-signed-azure phase: Testing phase-changed: Tuesday, 21. April 2020 11:37 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: regression-testing: Ongoing -- testing in progress stakeholder-signoff: Stalled -- waiting for signoff trackers: trusty/linux-azure: bug 1870682 xenial/linux-azure/azure-kernel: bug 1870681 variant: debs versions: main: 4.15.0-1082.92~16.04.1 meta: 4.15.0.1082.81 signed: 4.15.0-1082.92~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1870683/+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 1874286] Re: Add debian/rules targets to compile/run kernel selftests
** No longer affects: linux (Ubuntu Precise) ** No longer affects: linux (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/1874286 Title: Add debian/rules targets to compile/run kernel selftests Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Bug description: [Impact] When compiling and building the Ubuntu kernels, the kernel selftests located under 'tools/testing/selftests/' do not get compiled. Some of these testcases are used by our test infrastructure, which downloads the kernel source, compiles and run them. The problem with this approach is that patches applied to the testcases can break the compilation and this is detected only after the kernels are already released to -proposed. I am proposing that we add some simple debian/rules targets that will keep a list of the selftests that Ubuntu cares about, compile and run them. This could be plugged into our test build infrastructure in order to be able to detect such breaks. [Test Case] With these changes, one would be able to run the following to compile/run the selftests: # fakeroot debian/rules clean # fakeroot debian/rules compileselftests # fakeroot debian/rules runselftests [Regression Potential] None. This only adds new rules targets that will not break any existing targets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874286/+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 1349028] Re: getitimer returns it_value=0 erroneously
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Focal)
Importance: Medium
Assignee: Colin Ian King (colin-king)
Status: Fix Released
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Eoan)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Bionic)
Status: New => In Progress
** Changed in: linux (Ubuntu Eoan)
Status: New => In Progress
** Changed in: linux (Ubuntu Eoan)
Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)
--
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/1349028
Title:
getitimer returns it_value=0 erroneously
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Fix Released
Status in linux source package in Utopic:
Fix Released
Status in linux source package in Xenial:
In Progress
Status in linux source package in Bionic:
In Progress
Status in linux source package in Eoan:
In Progress
Status in linux source package in Focal:
Fix Released
Bug description:
According to the 'getitimer()' man page: "The element it_value is set
to the amount of time remaining on the timer, or zero if the timer is
disabled. Similarly, it_interval is set to the reset value."
As such the following Perl program should never exit:
use Time::HiRes;
$SIG{VTALRM} = sub { };
Time::HiRes::setitimer(::HiRes::ITIMER_VIRTUAL, 0.5, 0.4);
while (1) {
my @t = Time::HiRes::getitimer(::HiRes::ITIMER_VIRTUAL);
exit 0 if $t[0] == 0;
}
and on linux-image 3.11.0-18-generic (and all other systems tested) it
loops forever but 3.13.0-32-generic it exits. Have not bisected
between those kernels, nor am I likely to be able to do so soon.
This Perl program shows the timer countdown:
use Time::HiRes;
my $r = [Time::HiRes::gettimeofday()];
sub display {
my ($desc) = @_;
my @t = Time::HiRes::getitimer(::HiRes::ITIMER_VIRTUAL);
my $i = Time::HiRes::tv_interval($r);
printf "%s: elasped=%.8f; time left=%.6f reset time=%.6f\n", $desc,
$i,@t;
}
$SIG{VTALRM} = sub {
display('VTALRM');
exit;
};
Time::HiRes::setitimer(::HiRes::ITIMER_VIRTUAL, 0.5, 0.4);
while (1) {
display('inloop');
}
on other (working) systems it gives:
inloop: elasped=1.65178400; time left=0.001000 reset time=0.401000
inloop: elasped=1.65184200; time left=0.001000 reset time=0.401000
inloop: elasped=1.65186800; time left=0.001000 reset time=0.401000
inloop: elasped=1.65192300; time left=0.001000 reset time=0.401000
inloop: elasped=1.65198100; time left=0.001000 reset time=0.401000
VTALRM: elasped=1.65209800; time left=0.40 reset time=0.401000
(end of file)
but on the 3.13.0-32-generic or later kernel I get:
inloop: elasped=0.54692100; time left=0.33 reset time=0.40
inloop: elasped=0.54692800; time left=0.26 reset time=0.40
inloop: elasped=0.54693500; time left=0.20 reset time=0.40
inloop: elasped=0.54694100; time left=0.13 reset time=0.40
inloop: elasped=0.54694800; time left=0.07 reset time=0.40
inloop: elasped=0.54695500; time left=0.00 reset time=0.40
inloop: elasped=0.54696200; time left=0.004000 reset time=0.40
[...]
VTALRM: elasped=0.55013600; time left=0.397062 reset time=0.40
(end of file)
The reset time also looks dodgy.
Hardware is an Intel Core i7-920 on Asus P6T Deluxe v2 (X58)
motherboard and hasn't changed.
Requested information:
Ubuntu 3.13.0-32.57-generic 3.13.11.4
Description: Ubuntu 14.04.1 LTS
Release: 14.04
# apt-cache policy linux-image-generic
linux-image-generic:
Installed: 3.13.0.32.38
Candidate: 3.13.0.32.38
Version table:
*** 3.13.0.32.38 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64
Packages
500 http://us.archive.ubuntu.com/ubuntu/ trusty-security/main amd64
Packages
500 http://us.archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64
Packages
500 http://ppa.launchpad.net/canonical-kernel-team/ppa/ubuntu/
trusty/main amd64 Packages
100 /var/lib/dpkg/status
3.13.0.24.28 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
---
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1:
[Group.of.nepali.translators] [Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd
Eoan FTBFS as follows: ==> rabbitmqctl ** (Mix) You're trying to run :rabbitmqctl on Elixir v1.9.1 but it has declared in its mix.exs file it supports only Elixir >= 1.6.6 and < 1.8.0 make[4]: *** [Makefile:93: escript/rabbitmqctl] Error 1 make[4]: Leaving directory '/<>/deps/rabbitmq_cli' make[3]: *** [erlang.mk:4322: deps] Error 2 make[3]: Leaving directory '/<>/deps/rabbit' make[2]: *** [erlang.mk:4322: deps] Error 2 make[2]: Leaving directory '/<>' make[1]: *** [debian/rules:18: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:11: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Bug reference: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1773324 - Eric ** Changed in: rabbitmq-server (Ubuntu Eoan) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1874075 Title: rabbitmq-server startup timeouts differ between SysV and systemd Status in rabbitmq-server package in Ubuntu: In Progress Status in rabbitmq-server source package in Xenial: In Progress Status in rabbitmq-server source package in Bionic: In Progress Status in rabbitmq-server source package in Eoan: Won't Fix Status in rabbitmq-server source package in Focal: In Progress Bug description: The startup timeouts were recently adjusted and synchronized between the SysV and systemd startup files. https://github.com/rabbitmq/rabbitmq-server-release/pull/129 The new startup files should be included in this package. [Impact] After starting the RabbitMQ server process, the startup script will wait for the server to start by calling `rabbitmqctl wait` and will time out after 10 s. The startup time of the server depends on how quickly the Mnesia database becomes available and the server will time out after `mnesia_table_loading_retry_timeout` ms times `mnesia_table_loading_retry_limit` retries. By default this wait is 30,000 ms times 10 retries, i.e. 300 s. The mismatch between these two timeout values might lead to the startup script failing prematurely while the server is still waiting for the Mnesia tables. This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the `--timeout` option into the startup script. The default value for this timeout is set to 10 minutes (600 seconds). This change also updates the systemd service file to match the timeout values between the two service management methods. [Test Case] In a clustered setup with two nodes, A and B. 1. create queue on A 2. shut down B 3. shut down A 4. boot B The broker on B will wait for A. The systemd service will wait for 10 seconds and then fail. Boot A and the rabbitmq-server process on B will complete startup. [Regression Potential] This change alters the behavior of the startup scripts when the Mnesia database takes long to become available. This might lead to failures further down the service dependency chain. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1872757] Re: shiftfs: O_TMPFILE reports ESTALE
** No longer affects: linux (Ubuntu Bionic)
** No longer affects: linux (Ubuntu Xenial)
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1872757
Title:
shiftfs: O_TMPFILE reports ESTALE
Status in linux package in Ubuntu:
In Progress
Bug description:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
def test():
with tempfile.TemporaryFile() as fd:
fd.write("data".encode('utf-8'))
# re-open the file to get a read-only file descriptor
return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
fd = test()
fd.close()
if __name__ == "__main__":
main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
Fix: Our revalidate methods were very opinionated about whether or not
a dentry was valid when we really should've just let the underlay tell
us what's what. This has led to bugs where a ESTALE was returned for
e.g. temporary files that were created and directly re-opened
afterwards through /proc//fd/. When a file is
re-opened through /proc//fd/ LOOKUP_JUMP is set and the vfs
will revalidate via d_weak_revalidate(). Since the file has been
unhashed or even already gone negative we'd fail the open when we
should've succeeded.
I had also foolishly provided a .tmpfile method which so far only has
caused us trouble. If we really need this then we can reimplement it
properly but I doubt it. Remove it for now.
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757/+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
