Public bug reported:
It was originally reported in
https://github.com/systemd/systemd/pull/12583#issuecomment-492949206 5 days
ago. To judge from the logs VMs can't be rebooted there:
```
Ubuntu 18.04.2 LTS autopkgtest ttyS0
autopkgtest login:
---
@pitti would it be possible to temporarily skip the tests where VMs are
rebooted to reduce the blast radius so to speak? I really don't want to
turn Ubuntu CI off completely.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs
To judge from
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-upstream-systemd-ci-systemd-ci/bionic/i386/s/systemd-upstream/20190521_185445_b37c3@/log.gz,
VMs seems to also be throwing kernel panics:
```
[0.894903] BIOS EDD facility
Public bug reported:
Since https://github.com/systemd/systemd/pull/12430 was merged and
libsecomp was updated the test has been failing on Ubuntu CI:
https://github.com/systemd/systemd/issues/12709. By analogy with
https://github.com/systemd/systemd/pull/12430/commits/c3ab2c389ee60d92fb8d7fe779ae9
Today on GitHub a ppc64el webhook was turned on for the systemd project. The
fuzzers (built with ASan) crashed there as soon as they started with something
like
```
757/758 fuzz-varlink:oss-fuzz-14708:address FAIL 0.02 s (exit status 1)
--- command ---
/usr/bin/env
/tmp/autopkgtest.vdKh
Public bug reported:
Since
https://salsa.debian.org/systemd-team/systemd/commit/8d810fda9a640a932d6e7b32afd958fe75e36f5b
was merged Ubuntu CI has been failing with
```
Investigating (0) udev:amd64 < 237-3ubuntu10.13 -> 241-608-gfd541a5f08-0 @ii
pumU Ib >
Broken udev:amd64 Depends on dpkg:amd64
Public bug reported:
I'm not sure this is the right place to report this, but apparently it's
the best way to reach out to Dimitri John Ledkov
(https://github.com/xnox) and Iain Lane (https://github.com/iainlane),
who I believe at least know who maintains Ubuntu CI there.
I'm copying the followin
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1817344
Title:
Ubuntu CI that runs tests via autopkgtest for systemd on Gi
I turned on bionic-amd64 and bionic-i386 yesterday. VMs no longer fail
to boot but apparently something else was broken on bionic-i386 while it
was off: https://github.com/systemd/systemd/issues/12891.
In https://github.com/systemd/systemd/pull/12861#issuecomment-506025351
both bionic-amd64 and bi
Anyway, as I said in
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831296/comments/3,
I don't think Ubuntu CI in its current form is suitable for CI so I'll
just turn it off as soon as it starts failing again. I'm afraid I don't
have time for keeping an eye on it and reporting whatever co
By the way, judging by http://autopkgtest.ubuntu.com/running#pkg-
systemd-upstream, it seems Ubuntu CI keeps running the tests for PR
12618, which was merged about a month ago.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bu
Given that https://github.com/systemd/systemd/issues/11104 is a
variation of this bug and the reason `arm64` has been off since December
2018, I'm wondering how long it will take to fix this on Bionic.
** Bug watch added: github.com/systemd/systemd/issues #11104
https://github.com/systemd/syste
> looks like this has been fixed already upstream
Yes. I merged the PR (created by @yuwata) fixing that this morning.
> looks like someone stopped that; it's only running tests for 12888,
12897, and 12899 currently.
In
https://github.com/systemd/systemd/issues/12891#issuecomment-506093934 I
aske
Good to know! Thank you!
Would it also be possible to mark the "upstream" test
(https://salsa.debian.org/systemd-
team/systemd/blob/master/debian/tests/control#L113) "flaky" or turn it
off altogether? We run it on CentOS and Arch anyway so it should be
safe. On Ubuntu CI it's particularly flaky an
In the meantime, I brought arm64 back almost as soon as
https://salsa.debian.org/systemd-team/systemd/merge_requests/34 was
merged. It looks promising except that the "upstream" test is flaky
there as well. It'd be great to turn it off on Ubuntu CI.
--
You received this bug notification because y
I agree ideally the test should be fixed but it's been flaky for a
couple of years and I didn't notice anyone who would be willing to try
to figure it out. I think it's time to admit nobody cares. Even if I'm
totally wrong and someone is interested in getting it to work on Ubuntu
CI, it should be p
Regarding the blacklist, we started to work on it in
https://github.com/systemd/systemd/issues/11195 (which was initially
about merging PRs where bugs were caught by Travis CI but ignored
because everybody was used to Ubuntu CI failing more often than not) and
ended up with a list of test I suggest
Just to clarify, I think that it would be better to turn off the test
globally because we know it's flaky and unstable and we generally never
roll out globally flaky tests so as not to annoy contributors (I'm not
sure why Ubuntu CI should be different from any other CI system we use
upstream). And
> Opened MR to blacklist TEST-15 and TEST-22
That PR on GitHub hasn't been merged yet so I think it's too soon to
turn those tests off.
> ah, ok - so I did look into this, or at least some failures really
similar to this, a while back, for bug 1831468.
As far as I can tell, several tests failed
Regarding i386, I downloaded the log and took a look at what failed
there. Turns out all the tests except for TEST-34-DYNAMICUSERMIGRATE,
where the global timeout kicked in, passed. Apparently, to judge from
https://salsa.debian.org/systemd-
team/systemd/blob/master/debian/tests/upstream, on Ubuntu
By the way, @ddstreet would it be OK to mention that you maintain Ubuntu
CI at https://www.freedesktop.org/wiki/Software/systemd/autopkgtest/?
Currently it's almost impossible to figure out who is responsible for
it. At some point I assumed it was @xnox but it doesn't seem the case so
I don't even
> it looks like @laney is listed there, which is probably appropriate
(he has admin access to the test systems, while I don't)
My understanding is that @laney can help with the infrastructure where
the tests are run. What usually happens on Ubuntu CI for the most part
has nothing to do with the in
That's correct. The assertion is at https://salsa.debian.org/systemd-
team/systemd/blob/master/debian/tests/boot-and-services#L421.
Regarding which release of Ubuntu is affected, I have to say I don't
know. The issue is mostly about "upstream" mode of Ubuntu CI, which can
be detected by checking a
I'd add that it seems to me the "upstream" mode of Ubuntu CI doesn't
seem to be actively maintained because unlike the other CI systems used
upstream (which are usually fixed almost immediately), it can be broken
for weeks (or sometimes even months) which isn't suitable for CI. In
principle, if nob
Public bug reported:
Description:Ubuntu 14.04.3 LTS
Release:14.04
apt:
Installed: 1.0.1ubuntu2.10
apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80
7A82B743B9B8E46F12C733FA4759FA960E27C0A6
apt-key export 7A82B743B9B8E46F12C733FA4759FA960E27C0A6 # key is here
apt-k
Public bug reported:
# lsb_release -rd
Description:Ubuntu 14.04.3 LTS
Release:14.04
# apt-cache policy systemd-services
systemd-services:
Installed: 204-5ubuntu20.13
Candidate: 204-5ubuntu20.13
Version table:
*** 204-5ubuntu20.13 0
500 http://archive.ubuntu.com/ubuntu/
Looks like `perf` doesn't understand a path /usr/lib/debug/.build-id/
See: https://gist.github.com/evverx/bd0a6748f3c6254d2021#perf-probe
Environment: https://gist.github.com/evverx/bd0a6748f3c6254d2021#environment
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
27 matches
Mail list logo
