| 2019-09-23 19:01:15 |
Dan Streetman |
bug |
|
|
added bug |
| 2019-09-24 16:46:55 |
Stéphane Graber |
affects |
lxd (Ubuntu) |
autopkgtest (Ubuntu) |
|
| 2019-09-24 17:10:06 |
Dan Streetman |
autopkgtest (Ubuntu): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-09-24 17:10:08 |
Dan Streetman |
autopkgtest (Ubuntu): importance |
Undecided |
High |
|
| 2019-09-24 17:10:10 |
Dan Streetman |
autopkgtest (Ubuntu): status |
New |
In Progress |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
bug task added |
|
autopkgtest (Ubuntu Bionic) |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
bug task added |
|
autopkgtest (Ubuntu Eoan) |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
bug task added |
|
autopkgtest (Ubuntu Xenial) |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
nominated for series |
|
Ubuntu Disco |
|
| 2019-09-24 17:10:20 |
Dan Streetman |
bug task added |
|
autopkgtest (Ubuntu Disco) |
|
| 2019-09-24 18:33:41 |
Dan Streetman |
autopkgtest (Ubuntu Eoan): importance |
High |
Low |
|
| 2019-09-24 18:33:42 |
Dan Streetman |
autopkgtest (Ubuntu Disco): importance |
Undecided |
Low |
|
| 2019-09-24 18:33:44 |
Dan Streetman |
autopkgtest (Ubuntu Bionic): importance |
Undecided |
Low |
|
| 2019-09-24 18:33:46 |
Dan Streetman |
autopkgtest (Ubuntu Xenial): importance |
Undecided |
Low |
|
| 2019-09-24 18:33:49 |
Dan Streetman |
autopkgtest (Ubuntu Disco): status |
New |
In Progress |
|
| 2019-09-24 18:33:50 |
Dan Streetman |
autopkgtest (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-09-24 18:33:54 |
Dan Streetman |
autopkgtest (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-09-24 18:33:55 |
Dan Streetman |
autopkgtest (Ubuntu Disco): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-09-24 18:33:58 |
Dan Streetman |
autopkgtest (Ubuntu Bionic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-09-24 18:34:00 |
Dan Streetman |
autopkgtest (Ubuntu Xenial): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-09-25 00:52:38 |
Dan Streetman |
description |
[impact]
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
note that this is failing only for disco and eoan, and note that the 'lxd' test is skipped for non-intel archs. this does not appear to be failing on bionic:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
[regression potential]
TBD
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing; it seems that some change in the lxd snap recently has caused this regression. |
[impact]
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
note that this is failing only for disco and eoan, and note that the 'lxd' test is skipped for non-intel archs. this does not appear to be failing on bionic:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
[regression potential]
this only redirects stdin from /dev/null, for the call to 'lxc launch' inside autopkgtest-build-lxd; so the regression potential should be low. Any regressions would almost certainly involve a failure during the call to autopkgtest-build-lxd, during the creation of the lxd container.
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing.
I put the 'importance' of this as low because this bug will only be reproduced when calling autopkgtest-build-lxd from inside a here document passed to a shell, or otherwise called with input queued on stdin, which seems like an unusual way to call autopkgest-build-lxd. |
|
| 2019-09-26 14:27:25 |
Dan Streetman |
description |
[impact]
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
note that this is failing only for disco and eoan, and note that the 'lxd' test is skipped for non-intel archs. this does not appear to be failing on bionic:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
[regression potential]
this only redirects stdin from /dev/null, for the call to 'lxc launch' inside autopkgtest-build-lxd; so the regression potential should be low. Any regressions would almost certainly involve a failure during the call to autopkgtest-build-lxd, during the creation of the lxd container.
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing.
I put the 'importance' of this as low because this bug will only be reproduced when calling autopkgtest-build-lxd from inside a here document passed to a shell, or otherwise called with input queued on stdin, which seems like an unusual way to call autopkgest-build-lxd. |
[impact]
"lxd launch" behavior recently changed to parse any queued input on stdin and process it as a yaml file.
Since the "autopkgtest-build-lxd" script calls "lxd launch", and input queued to stdin when calling "autopkgtest-build-lxd" will cause the internal call to lxd to fail, such as calling "autopkgtest-build-lxd" from inside a here document (see test case below).
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
note that this is failing only for disco and eoan, and note that the 'lxd' test is skipped for non-intel archs. this does not appear to be failing on bionic:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
[regression potential]
this only redirects stdin from /dev/null, for the call to 'lxc launch' inside autopkgtest-build-lxd; so the regression potential should be low. Any regressions would almost certainly involve a failure during the call to autopkgtest-build-lxd, during the creation of the lxd container.
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing.
note that the autopkgtest fails only for disco and eoan, becuase on xenial and bionic the lxd deb is used, which still has the older behavior, however the lxd snap is available to install on both xenial and bionic, so this problem still exists for both those releases, as well as disco and eoan.
also, this is not just a testcase failure - this is actual new behavior that can break existing users of the "autopkgtest-build-lxd" script in the manner described in the test case.
I put the 'importance' of this as low because this bug will only be reproduced when calling autopkgtest-build-lxd from inside a here document passed to a shell, or otherwise called with input queued on stdin, which seems like an unusual way to call autopkgest-build-lxd. |
|
| 2019-09-27 13:28:56 |
Dan Streetman |
description |
[impact]
"lxd launch" behavior recently changed to parse any queued input on stdin and process it as a yaml file.
Since the "autopkgtest-build-lxd" script calls "lxd launch", and input queued to stdin when calling "autopkgtest-build-lxd" will cause the internal call to lxd to fail, such as calling "autopkgtest-build-lxd" from inside a here document (see test case below).
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
note that this is failing only for disco and eoan, and note that the 'lxd' test is skipped for non-intel archs. this does not appear to be failing on bionic:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
[regression potential]
this only redirects stdin from /dev/null, for the call to 'lxc launch' inside autopkgtest-build-lxd; so the regression potential should be low. Any regressions would almost certainly involve a failure during the call to autopkgtest-build-lxd, during the creation of the lxd container.
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing.
note that the autopkgtest fails only for disco and eoan, becuase on xenial and bionic the lxd deb is used, which still has the older behavior, however the lxd snap is available to install on both xenial and bionic, so this problem still exists for both those releases, as well as disco and eoan.
also, this is not just a testcase failure - this is actual new behavior that can break existing users of the "autopkgtest-build-lxd" script in the manner described in the test case.
I put the 'importance' of this as low because this bug will only be reproduced when calling autopkgtest-build-lxd from inside a here document passed to a shell, or otherwise called with input queued on stdin, which seems like an unusual way to call autopkgest-build-lxd. |
[impact]
"lxd launch" behavior recently changed to parse any queued input on stdin and process it as a yaml file.
Since the "autopkgtest-build-lxd" script calls "lxd launch", and input queued to stdin when calling "autopkgtest-build-lxd" will cause the internal call to lxd to fail, such as calling "autopkgtest-build-lxd" from inside a here document (see test case below).
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
root@autopkgtest:~# cat <<EOF | su - ubuntu
> autopkgtest-build-lxd ubuntu:bionic
> echo ok done
> EOF
Error: yaml: unmarshal errors:
line 1: cannot unmarshal !!str `echo ok...` into api.ContainerPut
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
note that this is failing only for disco and eoan, and note that the 'lxd' test is skipped for non-intel archs.
the autopkgtest does not fail on bionic or xenial, because the tests there run with the lxd deb, which is still at the older version.
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
However, the lxd snap can be installed in xenial or bionic, and the failure is reproducable when the lxd snap is installed.
[regression potential]
this only redirects stdin from /dev/null, for the call to 'lxc launch' inside autopkgtest-build-lxd; so the regression potential should be low. Any regressions would almost certainly involve a failure during the call to autopkgtest-build-lxd, during the creation of the lxd container.
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing.
note that the autopkgtest fails only for disco and eoan, becuase on xenial and bionic the lxd deb is used, which still has the older behavior, however the lxd snap is available to install on both xenial and bionic, so this problem still exists for both those releases, as well as disco and eoan.
also, this is not just a testcase failure - this is actual new behavior that can break existing users of the "autopkgtest-build-lxd" script in the manner described in the test case.
I put the 'importance' of this as low because this bug will only be reproduced when calling autopkgtest-build-lxd from inside a here document passed to a shell, or otherwise called with input queued on stdin, which seems like an unusual way to call autopkgest-build-lxd. |
|
| 2019-09-27 13:33:44 |
Dan Streetman |
description |
[impact]
"lxd launch" behavior recently changed to parse any queued input on stdin and process it as a yaml file.
Since the "autopkgtest-build-lxd" script calls "lxd launch", and input queued to stdin when calling "autopkgtest-build-lxd" will cause the internal call to lxd to fail, such as calling "autopkgtest-build-lxd" from inside a here document (see test case below).
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
root@autopkgtest:~# cat <<EOF | su - ubuntu
> autopkgtest-build-lxd ubuntu:bionic
> echo ok done
> EOF
Error: yaml: unmarshal errors:
line 1: cannot unmarshal !!str `echo ok...` into api.ContainerPut
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
note that this is failing only for disco and eoan, and note that the 'lxd' test is skipped for non-intel archs.
the autopkgtest does not fail on bionic or xenial, because the tests there run with the lxd deb, which is still at the older version.
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
However, the lxd snap can be installed in xenial or bionic, and the failure is reproducable when the lxd snap is installed.
[regression potential]
this only redirects stdin from /dev/null, for the call to 'lxc launch' inside autopkgtest-build-lxd; so the regression potential should be low. Any regressions would almost certainly involve a failure during the call to autopkgtest-build-lxd, during the creation of the lxd container.
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing.
note that the autopkgtest fails only for disco and eoan, becuase on xenial and bionic the lxd deb is used, which still has the older behavior, however the lxd snap is available to install on both xenial and bionic, so this problem still exists for both those releases, as well as disco and eoan.
also, this is not just a testcase failure - this is actual new behavior that can break existing users of the "autopkgtest-build-lxd" script in the manner described in the test case.
I put the 'importance' of this as low because this bug will only be reproduced when calling autopkgtest-build-lxd from inside a here document passed to a shell, or otherwise called with input queued on stdin, which seems like an unusual way to call autopkgest-build-lxd. |
[impact]
"lxd launch" behavior recently changed to parse any queued input on stdin and process it as a yaml file.
Since the "autopkgtest-build-lxd" script calls "lxd launch", and input queued to stdin when calling "autopkgtest-build-lxd" will cause the internal call to lxd to fail, such as calling "autopkgtest-build-lxd" from inside a here document (see test case below).
the failure is seen in (at least) the "lxd" autopkgtest from the autopkgtest package itself, e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/autopkgtest/20190923_160817_66dbe@/log.gz
[test case]
root@autopkgtest:~# cat <<EOF | su - ubuntu
> autopkgtest-build-lxd ubuntu:bionic
> echo ok done
> EOF
Error: yaml: unmarshal errors:
line 1: cannot unmarshal !!str `echo ok...` into api.ContainerPut
run the autopkgtests for the package 'autopkgtest', or check autopkgtest.ubuntu.com, e.g.:
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/disco/i386
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/amd64
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/eoan/i386
the autopkgtest test case is failing only for disco and eoan, and only for amd64/i386 as the 'lxd' test is skipped for non-intel archs.
the autopkgtest test case does not fail on bionic or xenial, because the tests there run with the lxd deb, which is still at the older version.
http://autopkgtest.ubuntu.com/packages/a/autopkgtest/bionic/amd64
However, the lxd snap can be installed in xenial or bionic, and the failure is reproducable when the lxd snap is installed, i.e.:
$ sudo apt remove lxd
$ sudo snap install lxd
...perform test case
[regression potential]
this only redirects stdin from /dev/null, for the call to 'lxc launch' inside autopkgtest-build-lxd; so the regression potential should be low. Any regressions would almost certainly involve a failure during the call to autopkgtest-build-lxd, during the creation of the lxd container.
[other info]
this is reproducable with the current packages from disco-updates using a local qemu vm for testing.
note that the autopkgtest fails only for disco and eoan, becuase on xenial and bionic the lxd deb is used, which still has the older behavior, however the lxd snap is available to install on both xenial and bionic, so this problem still exists for both those releases, as well as disco and eoan.
also, this is not just a testcase failure - this is actual new behavior that can break existing users of the "autopkgtest-build-lxd" script in the manner described in the test case.
I put the 'importance' of this as low because this bug will only be reproduced when calling autopkgtest-build-lxd from inside a here document passed to a shell, or otherwise called with input queued on stdin, which seems like an unusual way to call autopkgest-build-lxd, although still a perfectly valid way to use it. |
|
| 2019-09-27 22:59:11 |
Steve Langasek |
tags |
|
block-proposed-disco |
|
| 2019-09-27 22:59:24 |
Steve Langasek |
autopkgtest (Ubuntu Disco): status |
In Progress |
Fix Committed |
|
| 2019-09-27 22:59:27 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-09-27 22:59:30 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2019-09-27 22:59:34 |
Steve Langasek |
tags |
block-proposed-disco |
block-proposed-disco verification-needed verification-needed-disco |
|
| 2019-09-27 23:03:29 |
Steve Langasek |
autopkgtest (Ubuntu Eoan): status |
In Progress |
Fix Committed |
|
| 2019-09-29 03:16:59 |
Launchpad Janitor |
autopkgtest (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
| 2019-10-07 09:23:26 |
Łukasz Zemczak |
autopkgtest (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-10-07 09:23:32 |
Łukasz Zemczak |
tags |
block-proposed-disco verification-needed verification-needed-disco |
block-proposed-disco verification-needed verification-needed-bionic verification-needed-disco |
|
| 2019-10-07 09:24:38 |
Łukasz Zemczak |
autopkgtest (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-10-07 09:24:43 |
Łukasz Zemczak |
tags |
block-proposed-disco verification-needed verification-needed-bionic verification-needed-disco |
block-proposed-disco verification-needed verification-needed-bionic verification-needed-disco verification-needed-xenial |
|
| 2019-10-08 11:47:59 |
Dan Streetman |
tags |
block-proposed-disco verification-needed verification-needed-bionic verification-needed-disco verification-needed-xenial |
block-proposed-disco verification-done verification-done-bionic verification-done-disco verification-done-xenial |
|
| 2019-10-16 13:25:45 |
Łukasz Zemczak |
tags |
block-proposed-disco verification-done verification-done-bionic verification-done-disco verification-done-xenial |
block-proposed-bionic block-proposed-disco block-proposed-xenial verification-done verification-done-bionic verification-done-disco verification-done-xenial |
|
| 2020-07-02 19:55:09 |
Steve Langasek |
autopkgtest (Ubuntu Disco): status |
Fix Committed |
Won't Fix |
|
| 2020-11-17 15:31:07 |
Dan Streetman |
autopkgtest (Ubuntu Eoan): assignee |
Dan Streetman (ddstreet) |
|
|
| 2020-11-17 15:31:09 |
Dan Streetman |
autopkgtest (Ubuntu Disco): assignee |
Dan Streetman (ddstreet) |
|
|
| 2020-11-17 15:31:11 |
Dan Streetman |
autopkgtest (Ubuntu Bionic): assignee |
Dan Streetman (ddstreet) |
|
|
| 2020-11-17 15:31:13 |
Dan Streetman |
autopkgtest (Ubuntu Xenial): assignee |
Dan Streetman (ddstreet) |
|
|
| 2020-11-17 15:31:15 |
Dan Streetman |
autopkgtest (Ubuntu): assignee |
Dan Streetman (ddstreet) |
|
|
| 2021-06-30 20:14:02 |
Brian Murray |
tags |
block-proposed-bionic block-proposed-disco block-proposed-xenial verification-done verification-done-bionic verification-done-disco verification-done-xenial |
block-proposed-bionic block-proposed-disco block-proposed-xenial verification-done-disco verification-done-xenial verification-needed verification-needed-bionic |
|
| 2021-06-30 20:17:47 |
Brian Murray |
tags |
block-proposed-bionic block-proposed-disco block-proposed-xenial verification-done-disco verification-done-xenial verification-needed verification-needed-bionic |
block-proposed-disco block-proposed-xenial verification-done-disco verification-done-xenial verification-needed verification-needed-bionic |
|
| 2021-07-06 20:15:55 |
Dan Streetman |
tags |
block-proposed-disco block-proposed-xenial verification-done-disco verification-done-xenial verification-needed verification-needed-bionic |
block-proposed-disco block-proposed-xenial verification-done verification-done-bionic verification-done-disco verification-done-xenial |
|
| 2021-07-08 16:27:18 |
Launchpad Janitor |
autopkgtest (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2021-07-08 16:27:24 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
