[00:24] <amurray> doko:
[00:24] <amurray> doko: thanks for the heads up on those bugs but they don't look related to the hardening changes, plus looks like sforshee is on top of it :)
[02:00] <Unit193> bryce: Re: ruby2.5/openssl bug.  This is my nick on IRC if you want to poke here as well.
[02:37] <bryce> Unit193, oh heya :-)
[02:37] <bryce> Unit193, I was just doing a triaging pass through yesterday's bug activity, but feel free to ping me on that bug.
[02:38] <bryce> I'm at EOD now, but will check back tomorrow
[07:51] <doko> sforshee: so the powerpc cross succeeds, with linux-libc-dev-powerpc-cross built from the 5.2 sources. I'm not that that keen to further investigate, as we only need the powerpc cross compiler to build some firmware for ppc64el
[07:52] <doko> sforshee: so once gcc-8-cross and gcc-9-cross migrate, you should have cross compilers again, matching the native compilers
[07:52] <doko> and the alpha fix was the only thing needed
[09:06] <cpaelzer> rbasak: (and other SRU folks) thanks for having a discussion on the 1829823 case
[09:07] <Unit193> (LP 1829823)
[09:07] <cpaelzer> rbasak: I know it is not a common case, but if at the end of this we can come up with a clear guideline how to handle those that will benefit all of us
[10:41] <doko> sforshee: all cross compilers now in the release pocket
[11:28] <seb128> paride, hey, I just got an email about the eoan/desktop iso job failing with that error
[11:29] <seb128>   File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1035, in create
[11:29] <seb128>     if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
[11:29] <seb128> libvirtError: unsupported configuration: append not supported in this QEMU binary
[11:29] <seb128> paride, is that a known issue on the utah side?
[11:30] <paride> seb128, I just updated utah on venonat, in part because it was due time, in part to allow mwhudson's last changes to land
[11:30] <cpaelzer> not sure what it is worth, but qemu-system-* in eoan still has the -append parameter
[11:30] <paride> seb128, I knew it would probably explode, and it did :(
[11:31] <paride> seb128, trying to fix it now, anyway I backed up the old packages, so if it turns out more complex than expected I should be able to downgrade it again
[11:43] <rbasak> cpaelzer: I added to the agenda of our next meeting. We have been talking about staging SRUs that we don't think are worth the cost of landing, so this can add to that discussion.
[11:58] <paride> cpaelzer, seb128, I think I found it: https://bugs.launchpad.net/utah/+bug/1548499
[12:09]  * paride fingers crossed
[12:11] <seb128> paride, thx for looking at it!
[12:29] <paride> seb128, seems to be working again. if you notice anything unusual do not hesitate to ping me
[12:30] <seb128> paride, wiil do, thx for responding and for fixing it!
[13:24] <LocutusOfBorg> tjaalton, FYI https://launchpad.net/ubuntu/+source/intel-compute-runtime/19.13.12717-0ubuntu2 :)
[13:24] <LocutusOfBorg> I did that because intel new driver transition was stuck...
[13:39] <LocutusOfBorg> and now a build failure, probably due to new intel, or new gcc or whatever... can you help?
[13:47] <LocutusOfBorg> I don't want to upload intel-graphics-compiler to new releases....
[13:47] <LocutusOfBorg> better force gcc-8 and leave the update to you if you agree
[13:49] <DanyC> hi, i'm new around and so please accept my apologise for a silly q: i'm trying to understand how the ubuntu cloudimg ova image is being built? I'm trying to understand the mechanics done around the cloud-init and the user-data PropertyMapping present in the ova spec file. Any help much appreciated
[15:01] <tjaalton> LocutusOfBorg: i don't have time for that until next month, most likely
[15:02] <LocutusOfBorg> tjaalton, it migrated, so on the next upload you will probably want to drop the hack
[15:02] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/intel-compute-runtime/19.13.12717-0ubuntu3
[15:11] <tjaalton> next one should be to sid
[15:12] <tjaalton> assuming the deps go through NEW some year
[15:40] <seb128> cpaelzer, hey, the Debian maintainer pointed out for usbguard that the lib is private/shipped in a subdir and that upstream consider it non-stable so it doesn't make much sense to have a .symbols, I commented back on https://bugs.launchpad.net/ubuntu/+source/usbguard/+bug/1816548 , would be nice if you have a +1/-1 about that point as a follow up since you did raise the issue in your review
[22:48] <Unit193> ...So where exactly *is* casper's vcs? https://code.launchpad.net/~ubuntu-core-dev/casper/trunk points to a dead url and nothing else I'm finding is right.
[22:48] <Unit193> ...Having Vcs-Browser would most certainly help here.