[08:23] <mwhudson> yeech there are a lot of armhf regressions currently
[09:25] <doko> mwhudson: the release team likes to call those "flaky tests" ;p
[09:25] <doko> just retry those when the autopkg testers are idle
[10:31] <mwhudson> https://paste.ubuntu.com/p/yP6vFw8TMy/ well ok then?
[12:58] <Pinchiukas> Are the pipelines that build images for vagrant, etc public?
[14:46] <nibbon_> o/
[14:47] <nibbon_> question: debian/control is possible to specify Depends: for a specific version?
[14:48] <nibbon_> for instance i have a package that depends from libvirt-bin but that one isn't available in focal anymore
[14:48] <nibbon_> and I need to build that package for both
[14:48] <cjwatson> I mean, you can put a particular version there, but it won't cause that version to magically become available to clients
[14:49] <cjwatson> So it's normally useless to try that
[14:49] <nibbon_> I mean, I would like to have bionic: debian/control Depends: libvirt-bin
[14:49] <nibbon_> focal: debian/control Depends: libvirt-daemons
[14:49] <cjwatson> Oh.  Simplest way is to just branch the packaging for each series.
[14:50] <cjwatson> If you really insist on not branching the packaging, then you can use the substvars mechanism to do that kind of thing
[14:50] <cjwatson> See "man deb-substvars"
[14:51]  * nibbon_ reading
[14:51] <cjwatson> Also a little confused because there's no libvirt-daemons in focal, but there is a libvirt-daemon in both bionic and focal
[14:53] <cjwatson> But if for example you wanted a dependency that would be satisfied by libvirt-daemon in focal and newer releases but libvirt-bin in older releases, you could also write something like "Depends: libvirt-daemon | libvirt-bin (<< 6.0.0)" (I made up the version number, you'd need to pick something actually appropriate
[14:53] <nibbon_> yeah, I made a typo sorry that was the one
[14:53] <cjwatson> )
[14:53] <cjwatson> The last approach there is the simplest and you should probably use it unless you have a good reason not to
[14:54] <nibbon_> cjwatson: yeah, the latter seems a valid solution for my issue
[14:54] <cjwatson> Good good
[15:01] <cpaelzer> nibbon_: libvirt-bin has gone away looong ago
[15:01] <cpaelzer> we have kept it thorugh bionic just for compat, and Focal finally let go
[15:02] <cpaelzer> it was replaced by libvirt-daemon-system (the server) and libvirt-clients (obviously the clients)
[15:02] <cpaelzer> just so you know what to replace dependencies with
[15:02] <cpaelzer> but I have to admit even though this should be clear since a long time it seems it isn't
[15:03] <cpaelzer> I've got the same question just recently
[15:03] <cpaelzer> I think I'll add a note to the release notes to explain better
[15:15] <nibbon_> cpaelzer: so I can safely replace libvirt-bin with libvirt-daemon-system in the bionic version too?
[15:16] <nibbon_> libvirt-daemon-system installs libvirt-clients too so it seems the right candidate :)
[15:17] <nibbon_> and yeah, a remark about this in the release note would clarify things I guess
[15:18] <cpaelzer> nibbon_: yes this was already the case in bionic and can be used there
[15:18] <cpaelzer> nibbon_: there are sub-packages now if you only want the daemon for example
[15:19] <cpaelzer> nibbon_: but for your case libvirt-daemon-system should be the right thing
[16:58] <nibbon_> cpaelzer: you mentioned libvirt-bion has been kept for bionic just for compat: is it a package?
[16:59] <nibbon_> *libvirt-bin
[18:30] <ahasenack> vorlon: hi, there is this trusty sru that is lingering, probably because it's for trusty: https://bugs.launchpad.net/bugs/1881632
[18:31] <ahasenack> can you help there, or clarify if the sru team can proceed as usual with a trusty sru, given it's under esm now?
[21:53] <mwhudson> i would like to nominate src:frr for the worst autopkgtest i've seen in a while
[23:18] <mwhudson> can https://launchpadlibrarian.net/491020170/buildlog_ubuntu-groovy-riscv64.libyang_1.0.184-1_BUILDING.txt.gz be summarised as "don't use symbols files for c++"