[11:15] <rafaeldtinoco> @pilot in
[11:50] <cpaelzer> xnox: dannf: do you for 1883114 have a working setup/script/...?
[11:51] <cpaelzer> as I'm forced to remove https from the e1000e rom for bug 1882671 I wanted to test if your setup is affected
[11:51] <cpaelzer> but the bug you used only lists how to check if https support is compiled in, not how to actually use it
[11:51] <cpaelzer> so I wonder if the actual use-case exists somewhere already
[11:53] <dannf> cpaelzer: i don't
[12:09] <xnox> cpaelzer:  i don't have a working setup for 1883114 but i'm trying to find time to make that work. With 1883114 the idea is that UEFI firmware can do https boot directly, and then it looks as if one is inside a hard-drive, which happens to have http/https in the "disk-drive path"
[12:09] <xnox> cpaelzer: stuff in 1882671 is iPXE which is separate / different.
[12:10] <xnox> i think/hope the two things are independent of each other.
[12:30] <cpaelzer> xnox: I was hoping that as well, but they are not perfectly separate
[12:31] <cpaelzer> xnox: EDK2/OVMF formware will use the lower layers (stuff in ipxe-qemu beginning with efi-*) SNP to do low level things, but if the efi-* roms have more than just basics built in the lines start to blur which component does what
[12:31] <cpaelzer> this is what made it fail in the bug that I try to fix
[12:31] <xnox> ouch
[12:32] <xnox> cpaelzer:  is it borked in groovy too? or having https-enabled edkII makes things "better"?
[12:32] <cpaelzer> xnox: as far as I can tell it made it better
[12:32] <xnox> cpaelzer:  so i should SRU edk2 sooner, rather than later, i guess
[12:33] <xnox> cpaelzer:  but there is one more fix that needs to go in.
[12:33] <cpaelzer> there is a chance that my fix for ipxe-qemu requires the EDK" with HTTPS enabled
[12:33] <cpaelzer> so +1 on your fix better being or later - but OTOH no urgency from me
[12:33] <cpaelzer> my change can wait
[12:34] <cpaelzer> I'm only looking for extended testing, that is why I asked for that setup
[12:37] <xnox> cpaelzer:  we know that our grub is not good enough, so testing this stuff at the moment is more-or-less "follow openSUSE instructions and try to https boot their NET.iso"
[12:37] <xnox> and saying that, makes me sad.
[12:46] <cpaelzer> yeah https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup also is the #1 documentation hit one finds
[12:46] <xnox> indeed.
[12:46] <cpaelzer> once this works well for us we really should add that to the serverguide then as the suse docs is quite different (e.g. how to enable ssl on apache)
[12:46] <xnox> cpaelzer:  for a simple test, downloading their net.iso putting it on https; enrolling said https server cert; should be enough to test netbooting their net.iso
[13:52] <ahasenack> hi sil2100, how's bileto today?
[13:54] <sil2100> ahasenack: hey! Better, but there's still one more crash that I'm seeing now, will fix it in a moment
[13:54] <ahasenack> ok
[13:54] <ahasenack> thanks for working on it
[14:41] <sil2100> geh, phew, found the last one
[14:42] <sil2100> Apparently the new britney2 now defaults with a --distribution of Debian instead of 'ubuntu'
[14:42] <sil2100> But I added an explicit --distribution parameter to the britney command
[14:59] <Laney> phew, we already set that for the main runs ;-)
[15:01] <sil2100> This run now should be better I hope
[15:31] <oSoMoN> LocutusOfBorg, when you have a moment, can you sponsor https://salsa.debian.org/js-team/node-grunt-contrib-nodeunit/-/merge_requests/1 ?
[15:40] <sil2100> GunnarHj: hello! Did you manage to send out the call-for-testing for bionic?
[15:44] <niub> o/ quick and easy question: what's the package that replace libvirt-bin in Focal: libvirt-daemon?
[15:47] <GunnarHj> sil2100: Not yet, but I will later today.
[15:47] <GunnarHj> sil2100: Btw, I installed langpacks for some languages from focal-proposed, and my computer is still not burning. :)
[15:48] <sil2100> \o/
[15:48] <sil2100> ;)
[15:49] <sil2100> That's certainly a good sign!
[15:49] <sil2100> ahasenack: bileto britney seems to be working now! Please give me a poke if you see something not working as intended
[15:49] <sil2100> uh, the logfile from this britney run is 123M big
[15:50] <oSoMoN> LocutusOfBorg, also, node-iconv-lite needs a no-change rebuild against the version of node-iconv in groovy-proposed: https://people.canonical.com/~osomon/+1maintenance/node-iconv-lite.debdiff
[16:11] <oSoMoN> LocutusOfBorg, another trivial node-* related MR that needs sponsoring: https://salsa.debian.org/js-team/node-immutable-tuple/-/merge_requests/1
[16:14] <oSoMoN> if there are MOTUs/core devs around, I have a bunch of node-* autopkgtests that need triggering, here is the list: https://paste.ubuntu.com/p/qdrPkhQRjX/
[16:14] <oSoMoN> thanks in advance!
[16:15] <LocutusOfBorg> oSoMoN, will do them
[16:15] <oSoMoN> cheers
[16:20] <LocutusOfBorg> grunt-contrib-nodeunit done
[16:20] <LocutusOfBorg> iconv-lite done
[16:22] <LocutusOfBorg> immutable-tuple done
[16:24] <LocutusOfBorg> retries done in some seconds
[16:25] <LocutusOfBorg> let me know if you need anything else!
[16:40] <LocutusOfBorg> oSoMoN, why is the node-iconv-lite change needed?
[16:42] <LocutusOfBorg> looks like the built deb is really the same as the previous one
[17:11] <ahasenack> sil2100: thanks! Will try it now
[17:11] <oSoMoN> LocutusOfBorg, node-iconv is a build dep of node-iconv-lite, I assume because the tests are run at build time
[19:02] <rafaeldtinoco> maint+1: opened zsys upstream bug for armhf regression of its own regression tests issue (object file serialization / de-serialization issues when comparing 2 objects as it looks)
[19:02] <rafaeldtinoco> working on sqlite3 issues and libgpg-error
[19:02] <rafaeldtinoco> sergiodj is working on rsync migration issues
[19:02] <rafaeldtinoco> fyio ^
[21:36] <rafaeldtinoco> @pilot out
[21:37] <ahasenack> oh, nice macro
[22:41] <mwhudson> morning
[22:41] <sarnold> morning mwhudson :)
[22:52] <mwhudson> Laney: my browser thanks you for making update_excuses.html so much smaller
[23:43] <xnox> Laney:  it is nice.
[23:43] <xnox> no idea how it went from 23M to like 3M