Comment 6 for bug 1830859

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

[13:09] <mdeslaur> cpaelzer: oh, we knew about that one :(
[13:09] <cpaelzer> well
[13:09] <cpaelzer> then had you a plan how we should resolve that
[13:10] <cpaelzer> either in general (magic great code I haven't thought of) or in particular (how I should resolve it for qemu) ?
[13:10] <cpaelzer> and good morning mdeslaur sorry to start with such issues :-/
[13:10] <mdeslaur> cpaelzer: good morning! :)
[13:11] <-- lborda-eod (lborda@173-246-24-26.qc.cable.ebox.net) has left this server (Quit: Ex-Chat).
[13:11] <mdeslaur> cpaelzer: the plan is to publish the libseccomp update ;)
[13:11] --> lborda (lborda@173-246-24-26.qc.cable.ebox.net) has joined this channel.
[13:11] <mdeslaur> cpaelzer: we searched the archive, and qemu was the only problematic package that used those new apis
[13:12] <mdeslaur> jdstrand: are we ready to publish the seccomp updates?
[13:12] <cpaelzer> mdeslaur: ok then should I add an explicit dependency for Disco
[13:12] <cpaelzer> only there the "transition" might occur
[13:13] <cpaelzer> that we rebuild with the new version around but the old might be installed
[13:13] <jjohansen> hey mdeslaur
[13:13] <cpaelzer> I'm prepping an SRU anyway and that would avoid the "rebuilt to 2.4 but not installed"
[13:13] <cpaelzer> if qemu really is the only one I'm ok to carry this
[13:13] <mdeslaur> cpaelzer: yeah, you can add an explicit dependency, or you can wait until we publish seccomp...we may publish it today or monday
[13:13] <cpaelzer> and in Eoan things are fine as that will release with >=2.4
[13:14] <cpaelzer> mdeslaur: well, my point is even if you publish it there are no guarantees
[13:14] <cpaelzer> people might update qemu but not libseccomp
[13:14] <cpaelzer> and they would be screwed
[13:14] <cpaelzer> so the first rebuild of qemu in disco (=now) will need to add the dependency
[13:14] <cpaelzer> mdeslaur: ^^
[13:15] <mdeslaur> yes, selective installing of security updates is an untested and probably broken configuration
[13:15] <mdeslaur> if you add the explicit dependency, you'll need to wait until we do publish seccomp too
[13:15] <cpaelzer> yes, but I'll need a few days anyway
[13:15] <cpaelzer> and you seem close
[13:16] <mdeslaur> ok
[13:16] <cpaelzer> and for testing interim wise I can throw a no change rebuild of libseccomp 2.4 in my ppa
[13:16] <mdeslaur> I'll try and remember to add the explicit dependency to the next round of qemu updates
[13:16] <cpaelzer> Hmm, you have some in the pipe as well?
[13:16] <mdeslaur> I don't currently, no
[13:16] <cpaelzer> I have
[13:16] <cpaelzer> I'll add them right away
[13:17] <cpaelzer> if testing goes well those should hit -unapproved early next week
[13:17] <mdeslaur> sorry our timezones don't overlap and you had to spend time debugging this
[13:17] <mdeslaur> we spotted this issue when we prepared the emergency qemu update last week

TL;DR
we will make is a qemu fix in Disco, by adding an explicit dependency.
All others don't need the change.