[00:08] <mapreri> cjwatson: btw, what would be the launchpad team representing the "launchpad admins"?
[00:08] <mapreri> (~admins?)
[00:20] <cjwatson> mapreri: ~admins, yes
[00:20] <cjwatson> mapreri: being in ~admins shortcuts most permission checks
[00:27] <mapreri> ack
[04:57] <arijit> I filed a bug on launchpad, but have not gotten a response in two weeks (https://bugs.launchpad.net/ubuntu/+source/watchdog/+bug/1750942). I can submit a patch, but I'm not sure if the watchdog package is actively maintained at this point. Does anyone have any suggestions?
[04:57] <nacc> arijit: it's in univere, which means somoene in the community needs to help support it, possibly no one actively is
[04:58] <nacc> arijit: but if you provide a patch, it will go into the sponsorship queue
[05:00] <arijit> nacc: That's good to know, thanks! Will send a patch
[05:00] <nacc> arijit: yw
[05:00] <nacc> arijit: and by patch i meant debdiff, if that wasn't clear
[05:00] <arijit> sg
[07:14] <wgrant> mapreri, cjwatson: I've set the Debian bug supervisor.
[07:14] <wgrant> Distro ownership is very powerful so really needs to be restricted beyond ~registry
[07:39] <ricotz> LocutusOfBorg, hi, libboost-numpy1.65-dev depends on libboost-python1.65.1 which should be ibboost-numpy1.65.1
[08:09] <xnox> ricotz, hmmmmm
[10:09] <mapreri> wgrant: thanks!   What do you mean with "Distro ownership is very powerful" - i.e. what would it entail?
[10:10] <wgrant> mapreri: Particularly because we sync things by copies from Debian, there are spects of the distro configuration that shouldn't be messed with.
[10:11] <wgrant> ~registry generally owns things that don't matter hugely
[10:11] <mapreri> note that debian isn't owned/maintained by ~registry, but by basically just you :)
[10:11] <wgrant> Yes.
[10:11] <wgrant> I'm saying that's right (well, maybe not just me, but not ~registry either)
[10:12] <LocutusOfBorg> ricotz, I don't get
[10:12] <mapreri> And, ack :)
[10:13] <ricotz> LocutusOfBorg, you don't get "what"?
[10:14] <Laney> no satisfaction
[10:14] <LocutusOfBorg> <3 Laney loool
[10:14] <LocutusOfBorg> ricotz, I have zero boost uploads
[10:14] <ricotz> hehe
[10:15] <LocutusOfBorg> xnox, and doko did the whole work
[10:15] <LocutusOfBorg> I could fix it, just I don't get why you pinged me
[10:15] <ricotz> LocutusOfBorg, oh, didn't you came up in the changelog at latest
[10:15] <LocutusOfBorg> I hope not
[10:16] <LocutusOfBorg> doko is, but I'm grabbing it and having a look, I have some boost knowledge
[10:16] <ricotz> LocutusOfBorg, oh, aptitude lied to me then :\
[10:17] <ricotz> thanks
[10:17] <LocutusOfBorg> :) no problem, I'm happy to fix it
[10:17] <LocutusOfBorg> I did some boost merges, but a lot of time ago
[10:18] <ricotz> I see, looks like xnox read my message too
[10:19] <LocutusOfBorg> xnox, let me know, I confirm the issue
[10:35] <LocutusOfBorg> ricotz, done.
[10:50] <ogra_> slangasek, https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
[10:59] <ogra_> slangasek, particulary the livecd-rootfs in that PPA will be a problem ...
[12:50] <seb128> cyphermox, do you think you could have a look to https://bugs.launchpad.net/ubuntu/+source/libdazzle/+bug/1748905 ? it's blocking the gnome-calendar 3.28 update in bionic-proposed, we would like to get that in beta1 if possible
[15:10] <GunnarHj> mapreri: Thanks! You were right - pinging GCS made a difference.
[15:22] <mapreri> GunnarHj: I sometimes believe he sends to /dev/null all mails coming from bts/dak etc…  he maintains too many packages, I wouldn't be surprised he ignores regular bugs.
[15:26] <GunnarHj> mapreri: I noticed this list:
[15:26] <GunnarHj> https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=gcs%40debian.org
[15:26] <GunnarHj> Many of them have patches. Bad. Very demotivational for contributors.
[15:27] <mapreri> well…
[15:36] <sarnold> Unit193: https://usn.ubuntu.com/3590-1/ :)
[15:38] <nacc> cyphermox: is the new MIR verbiage (e.g., "if the Security Team acknowledges they are aware of this requirement" standard now? I had a few MIRs I had looked at that also needed security team review for desktop
[16:21] <xevious> systemd-firstboot is breaking stuff. Pharaoh_Atem figured it out by looking at the process a couple of times
[16:22] <xevious> It's spawning random instance units for unit files that don't accept parameters.
[16:22] <Pharaoh_Atem> which is a bit of a first for me
[16:23] <Pharaoh_Atem> because I don't think I've seen firstboot behave so oddly
[16:26] <bdmurray> jbicha: Do you have time to look at bug 1751546 now?
[16:27] <jbicha> bdmurray: I forwarded it to darkxst
[16:28] <jbicha> did you see his comment there?
[16:30] <bdmurray> jbicha: Ah, I hadn't refreshed
[16:31] <jbicha> I didn't really look into the issue deeply since I was hoping he would :)
[16:50] <xevious> Is anyone else seeing a long pause during boot, followed by the message "Gave up waiting for suspend/resume device"? This started happening in Bionic images I'm building. It doesn't happen on images I created at the beginning of February.
[16:52] <xevious> Pharaoh_Atem: I was able to get the system to boot without creating the weird instance unit symlinks by creating `/lib/systemd/system-preset/01-default.preset` with the contents `disable *`
[18:00] <cyphermox> nacc: there is no standard verbiage, you're welcome to create something (seeing as you're likely more native an English speaker than I am)
[18:00] <cyphermox> nacc: this was just one special case where we didn't need immediate code review blocking the MIR
[18:01] <nacc> cyphermox: oh no, taht's fine, i just wasn't sure if it was somethjing that discussed at the sprint, or if it's something that was done as a one-off (* a few)
[18:30]  * tsimonq2 grumbles (albeit pointlessly) at systemd-resolved
[20:07] <cpaelzer> bdrung: hi, still around?
[20:08] <cpaelzer> bdrung: I see a qemu upload in bionic that fails to build on all arches
[20:08] <cpaelzer> I have other changes to make and wanted to ask if you are already on this?
[20:10] <cpaelzer> bdrung: there also is no bug associated and so far I couldn't find the changes upstream
[20:11] <cpaelzer> bdrung: for now since the current ubuntu3 version FTBFS as it is and I have an alternative already through the usual qemu upload regression testing
[20:12] <cpaelzer> bdrung: I'm going to revert the changes made by you in ubuntu3 for now and push my changes as ubuntu4
[20:12] <cpaelzer> bdrung: but please do not feel set back, I'd ask you to file a bug and attach the changes you had
[20:12] <cpaelzer> bdrung: there we can also check what is causing the build fails
[20:13] <cpaelzer> bdrung: and I could pre-upload push t through regression checks from a ppa
[20:13] <cpaelzer> so TL;DR: Hi, I reverted your ubuntu3 (FTBFS) and pushed other changes as ubuntu4 for now
[20:13] <cpaelzer> please bug me via launchpad :-)
[20:22] <cpaelzer> bdrung: we are sprinting, so I never know when I'm able to respond therefore through a LP bug I expect it to work better
[20:25] <cpaelzer> Hmm, I see that I can run into this issue just as much without your changes
[20:25] <cpaelzer> so something else changed and made this show up now
[20:31] <cpaelzer> bdrung: should be fixed by https://git.qemu.org/?p=qemu.git;a=commitdiff;h=75e5b70e6b5dcc4f2219992
[20:31] <cpaelzer> bdmurray: I'll combine our changes plus the fix and check if it builds
[20:31] <cpaelzer> bdmurray: sorry I meant bdrung
[20:32] <cpaelzer> bdrung_work: but a bug about the reasons to refer to from the changelog and patches would still be great
[20:34] <darkxst> jbicha, bdmurray, bug 1751546 is on my list to look into, however I suspect it is an archive issue with tasks, rather than a tasksel issue
[20:43] <cpaelzer> bdrung: FYI 1753826 is the FTBFS bug
[21:04] <cpaelzer> bdrung: I appreciate to work on it, but this is post FF and could be considered a Feature
[21:05] <cpaelzer> so a bug to discuss is even more appropriate
[21:22] <bdmurray> darkxst: It looks like a tasksel issue to me https://launchpadlibrarian.net/339723238/tasksel_3.34ubuntu8_3.34ubuntu9.diff.gz