[00:00] <volty> After hours of trying, I came with the idea of googling for ubuntu bios corrupt after installation, and found that it happens with some computers since version 17.
[00:00] <volty> sorry, previous is by error
[00:00] <volty> (pasting)
[00:05] <volty> So, now a question for you, since nobody in the user-level #ubuntu, is going to know this --- does the bios get touched only during the installation? Can I now use the installed kubuntu-18.04 without fear (with normal use, no distro upgrade) that it is going to touch the bios again ?
[08:28] <cjwatson> doko: Is your FTBFS report generation not cronned?
[08:29] <cjwatson> doko: I fixed a bunch of failures last night (casualties of some kind of infrastructure glitch over the holidays) but the effects aren't visible yet
[08:38] <doko> cjwatson: no, I was traveling, and the report takes a few hours. I should move it to some machine like p.c.c
[08:46] <cjwatson> if you do then make sure the cron job has appropriate locking (maybe obvious but people.c.c often has problems with people who've written cron jobs assuming that they can get away without locking and then ending up with multiple copies running)
[10:20] <cjwatson> mwhudson: Would you mind re-reviewing https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/361172 ?  You reviewed an earlier version
[13:31] <zyga> kissiel: hey,
[13:31] <zyga> kissiel: can you please look at https://forum.snapcraft.io/t/stage-package-not-able-to-pull-latest-source-for-checkbox-ng/9106
[13:32] <kissiel> zyga: ack
[13:32] <zyga> thank you
[15:01] <cyphermox> LocutusOfBorg: probably fine to upload, IIRC they don't have update-secureboot-policy.
[15:02] <cek> Not sure whether it's a dev question... I'm wondering why every document I find on uefi SecureBoot says signing certs should be installed into databases and at the same time they are mentioning PKI. So, should the `db` contain the signing cert or should/can it contain the CA cert that issued the signing cert?
[15:06] <cpaelzer> doko: the massive kopanocore issues breaking it badly were removed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907396
[15:06] <cpaelzer> doko: also all my former Delta is accepted
[15:06] <cpaelzer> the only thing left as Delta are the two fixes you added recently "Build-depend on libsystemd-dev" and "Fix the kopano-spamd install file."
[15:07] <cpaelzer> IMHO your two fixes are nice but not super important atm, it builds and works sort of ok as-is
[15:07] <cpaelzer> we also don't need the php7.1mapi rename as we are post 18.04
[15:07] <cpaelzer> I'm tempted to suggest making it a sync, especially given that it is "universe only"
[15:07] <cpaelzer> doko: what do you think?
[15:11] <cyphermox> cek: it's a proper PKI -- you need to have a proper chain of trust though
[15:12] <cyphermox> ie. we ship shim with a certificate that is the issuer for what actually signs kernels.
[15:25] <doko> cpaelzer: up to you. iirc, I removed it from the release pocket, so no current migratons are affected
[15:37] <LocutusOfBorg> cyphermox, can you please add -v?
[15:37] <LocutusOfBorg> I already uploaded in debian...
[15:37] <LocutusOfBorg> but not all the delta
[15:40] <cyphermox> what?
[15:41] <cpaelzer> doko: right you removed it, let me build latest Debian in a PPA and decide then
[15:43] <LocutusOfBorg> [16:01:54] <cyphermox> LocutusOfBorg: probably fine to upload, IIRC they don't have update-secureboot-policy.
[15:43] <LocutusOfBorg> "to upload" <-- what and where?
[15:43] <LocutusOfBorg> I forgot the exact question :
[15:43] <LocutusOfBorg> :p
[15:45] <cyphermox> dkms
[15:51] <LocutusOfBorg> cyphermox, to debian, the very same delta?
[16:05] <cek> there's proper chain of trust, it just seems that secureboot requires the pubkey/certificate that was directly used to sign the binary, not the CA that issued the cert.
[16:29] <cyphermox> LocutusOfBorg: yeah, should just work, I guard against doing anything if the script isn't there.
[16:33] <LocutusOfBorg> ack
[18:10] <ricotz> mwhudson, hello :), could you update rustc to 1.31.1 (firefox trunk already requires it)
[18:59] <ahasenack> hi, I added a block-proposed tag to https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1806035 a while back, and now I uploaded a new samba package which has a fix for that bug
[18:59] <ahasenack> should I remove the tag, or will things happen automagically?
[18:59] <ahasenack> I have a feeling this is a chicken-and-egg problem
[18:59] <ahasenack> and that I should remove the tag manually
[19:01] <infinity> ahasenack: Remove the tag, yes.
[19:01] <ahasenack> thx
[19:01] <infinity> ahasenack: To understand the chicken and egg issue, the bug won't auto-close until it migrates, and it can't migrate with the tag. :)
[19:02] <ahasenack> exactly :)
[19:03] <infinity> ahasenack: I've tossed around the idea of making britney smart enough to detect that the current version closes the blocking bug, BUT that breaks a useful workflow people have developed where they close the blocking bug in the changelog, but rely on the block to keep it there until they've done manual testing.
[20:22] <mwhudson> ricotz: um maybe, pings on irc aren't how i do work scheduling though :)
[20:45] <ricotz> mwhudson, I see, so I am hoping it is already on your schedule ;)
[20:46] <mwhudson> ricotz: heh it probably should be but christmas and all that
[20:47] <ricotz> mwhudson, heh, thank you
[20:58] <mwhudson> ricotz: blargh, someone(tm) should update https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox
[22:15] <tomreyn> are you saying the "rust update policy for firefox" is rusty?
[22:52] <mwhudson> the part of my brain responsible for puns is still on leave
[22:57] <tomreyn> doing employed work wouldn't be possible for me without this.