As Eoan releases with >=2.4 this isn't a problem for Eoan, closing the
task.
** Changed in: qemu (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830859
This bug was fixed in the package qemu - 1:3.1+dfsg-2ubuntu3.2
---
qemu (1:3.1+dfsg-2ubuntu3.2) disco; urgency=medium
* d/p/ubuntu/define-ubuntu-machine-types.patch: fix wily machine type being
broken since 2.11 due to 2.3/2.4 version mismatch in its definition to
fix
On this rebuild not only did it pick up the new libseccomp for build
libseccomp2 amd64 2.4.1-0ubuntu0.19.04.3
but also has the dependency to libseccomp2 (>= 2.4.1) to ensure it has to be
upgraded.
Seen in e.g.: https://launchpadlibrarian.net/427212564/buildlog_ubuntu-
Hello Christian, or anyone else affected,
Accepted qemu into disco-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/qemu/1:3.1+dfsg-
2ubuntu3.2 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
Uploaded to Disco-unapproved.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
To manage
Checked on the PPA:
root@d-wily:~# apt install libseccomp2=2.3.3-3ubuntu2
Reading package lists... Done
Building dependency tree
Reading state information... Done
[...]
The following packages will be REMOVED:
qemu-kvm qemu-system-x86
The following packages will be DOWNGRADED:
Tested on the PPA, working as expected (after moved to qemu-system-*packacges)
The reason to no more use qemu-system-common is that this only was a recommends
which would not enforce the update.
Even qemu-system-data which is a depends would be wrong as people could install
that without the
** Description changed:
+ [Impact]
+
+ * Just as of yesterday we have a new libseccomp in all releases.
+This brings some new code and features which might impact packages.
+For qemu being one of the few that is not so much a problem in many
+cases. Prior to Disco we didn't have
Thanks Jamie,
as discussed an explicit dependency as fix will be part of the next SRU upload
to qemu to avoid anybody running into trouble due to this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
FYI, libseccomp is now published: https://usn.ubuntu.com/4001-1/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
[13:09] cpaelzer: oh, we knew about that one :(
[13:09] well
[13:09] then had you a plan how we should resolve that
[13:10] either in general (magic great code I haven't thought of) or
in particular (how I should resolve it for qemu) ?
[13:10] and good morning mdeslaur sorry to start with
Two Disco containers (one per PPA)
$ sudo add-apt-repository ppa:paelzer/bug-1830859-with-proposed-seccomp
or
$ sudo add-apt-repository ppa:paelzer/bug-1830859-without-proposed-seccomp
# add main/debug and enable the deb-src in the PPA sources
$ sudo apt install gdb qemu-system-x86
** Description changed:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
I have set up two new PPAs
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-with-proposed-seccomp
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-without-proposed-seccomp
They both build amd64 qemu with/without proposed for Disco.
Including debug symbols for further
Until a simpler testcase is found, the qemu in PPA [1] built for Disco will
trigger it.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+packages
** Description changed:
It started with some of my usual KVM checks and found them failing on Disco
with:
- error: internal
To be clear - this will likely resolve over time when people upgrade to seccomp
2.4.
But right now SRUs could release things built in -proposed against it and then
end up broken until 2.4 is released as well.
Furthermore without a strict dependency it might stay broken as nothing
enforces 2.4
Task for now is:
- Critical (for the chance of breaking a potentially arbitrary amount of SRUs
that were built against it in proposed)
- Assigned to ubuntu-security as they are driving the libseccomp update
We need to understand it more to then re-triage severity and potential
actions.
--
You
17 matches
Mail list logo
