[05:16] -queuebot:#ubuntu-release- New binary: duf [ppc64el] (impish-proposed/none) [0.6.2-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: duf [amd64] (impish-proposed/none) [0.6.2-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: duf [arm64] (impish-proposed/universe) [0.6.2-1] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: duf [armhf] (impish-proposed/universe) [0.6.2-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: duf [s390x] (impish-proposed/universe) [0.6.2-1] (no packageset)
[05:36] -queuebot:#ubuntu-release- New binary: duf [riscv64] (impish-proposed/universe) [0.6.2-1] (no packageset)
[06:04] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.167~18.04.1 => 1.167~18.04.2] (core)
[06:04] -queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.167 => 1.167.1] (core)
[06:04] -queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.167~16.04.2 => 1.167~16.04.3] (core)
[06:04] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (bionic-proposed/main) [2.04-1ubuntu44 => 2.04-1ubuntu44.1] (no packageset)
[06:04] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.11 => 2.04-1ubuntu26.12] (core)
[06:05] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (focal-proposed/main) [2.04-1ubuntu44 => 2.04-1ubuntu44.2] (no packageset)
[07:21] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu26.12]
[07:22] -queuebot:#ubuntu-release- New: accepted duf [amd64] (impish-proposed) [0.6.2-1]
[07:22] -queuebot:#ubuntu-release- New: accepted duf [armhf] (impish-proposed) [0.6.2-1]
[07:22] -queuebot:#ubuntu-release- New: accepted duf [riscv64] (impish-proposed) [0.6.2-1]
[07:22] -queuebot:#ubuntu-release- New: accepted gnucobol4 [riscv64] (impish-proposed) [4.0~early~20200606-5]
[07:22] -queuebot:#ubuntu-release- New: accepted duf [arm64] (impish-proposed) [0.6.2-1]
[07:22] -queuebot:#ubuntu-release- New: accepted duf [s390x] (impish-proposed) [0.6.2-1]
[07:22] -queuebot:#ubuntu-release- New: accepted duf [ppc64el] (impish-proposed) [0.6.2-1]
[07:30] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (focal-proposed/main) [2.04-1ubuntu44 => 2.04-1ubuntu44.2] (no packageset)
[07:34] -queuebot:#ubuntu-release- Unapproved: rejected grub2-unsigned [source] (focal-proposed) [2.04-1ubuntu44.2]
[07:36] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [source] (focal-proposed) [2.04-1ubuntu44.2]
[07:37] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.167.1]
[07:40] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [source] (bionic-proposed) [2.04-1ubuntu44.1]
[07:46] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (focal-proposed/main) [2.04-1ubuntu44.2 => 2.04-1ubuntu44.2] (no packageset)
[07:47] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (bionic-proposed/main) [2.04-1ubuntu44.1 => 2.04-1ubuntu44.1] (no packageset)
[07:50] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.167~18.04.2]
[07:51] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [arm64] (focal-proposed) [2.04-1ubuntu44.2]
[07:56] <sil2100> vorlon: looking at grub2-signed in the xenial queue, does this mean we should binary-copy grub2-unsigned from bionic-proposed once it's built?
[07:58] <juliank> sil2100: I'm very confused by this upload, the very point of grub2-unsigned is to have it shared across all releases
[07:59] <juliank> sil2100: I'd ask you to remove this, grub2-unsigned must be built in hirsute or impish
[08:00] <juliank> sil2100: There is no way we can test that, and we know that the arm64 one is completely broken when not built in hirsute+
[08:01] <juliank> or was that shim?
[08:03] <sil2100> ...I don't know, I think we'd need vorlon for that
[08:04] <sil2100> I at least don't remember about any requirement that grub2-unsigned being built in hirsute+, but I also didn't follow the grub2 story too closely
[08:05] <juliank> but rebuilding with a 5 year older toolchain is a massive regression potential :D
[08:05] <juliank> but yes, we did not have consensus on what to change
[08:06] <juliank> So "Where problems could occur" is just plain wrong and completely ignores the toolchain being 5 years older :D
[08:07] <sil2100> Please yell at vorlon if you think we should go the other way! Since I know the other option was to backport the grub2-common move to older series
[08:07] <juliank> I did in bug :D
[08:08] <sil2100> Thanks ;)
[08:08] <sil2100> GRUB IS HARD
[08:08] <juliank> It's at least 3 times the work for the security team if built on 3 releases :D
[08:09] <juliank> well, at most
[08:10] <seb128> sil2100, hey, did you see my ping from yesterday?
[08:10] <sil2100> seb128: hey! Probably missed it, what's up?
[08:11] <sil2100> Ah, u-boot
[08:13] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (bionic-proposed/main) [2.04-1ubuntu44.1 => 2.04-1ubuntu44.1] (no packageset)
[08:14] <sil2100> uh, u-boot-tool, looks like a typo, checking
[08:17] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (focal-proposed/main) [2.04-1ubuntu44.2 => 2.04-1ubuntu44.2] (no packageset)
[08:21] <seb128> sil2100, review https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/402992 is the request basically
[08:25] <sil2100> Good catch! Nasty typo from my sid
[08:25] <sil2100> *side
[08:26] <sil2100> I'll release it now to get the builds going
[08:27] <seb128> sil2100, thanks!
[08:30] -queuebot:#ubuntu-release- New source: llvm-toolchain-12 (focal-proposed/primary) [1:12.0.0-3ubuntu1~20.04.1]
[08:31] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-12 (hirsute-proposed/universe) [1:12.0.0-1ubuntu1 => 1:12.0.0-3ubuntu1~21.04.1] (i386-whitelist)
[08:38] -queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (impish-proposed/main) [5.11.0-1008.8+21.10.1] (core)
[08:42] <sil2100> tseliot: oh no!
[08:42] <tseliot> sil2100, what's up?
[08:43] <sil2100> tseliot: looking at fabric-manager-{450,460} in hirsute-proposed NEW and I think there's a typo there in the new Provides/Replaces/Conflicts - the end debian/control entry has "cuda-drivers-fabricmanager-branch", which I supposed was supposed to be derived from #BRANCH# ?
[08:44] <tseliot> sil2100, didn't I remove that? The "-branch" suffix
[08:44] <sil2100> So I guess the control.in needs to be modified to cuda-drivers-fabricmanager-#BRANCH# and regenerated?
[08:45] <sil2100> Since I ran a debdiff of the hirsute version against the impish version and this is what I got:
[08:45] <sil2100> https://paste.ubuntu.com/p/yxY9Zdv5Z9/
[08:51] <tseliot> sil2100, I think it's just the one for hirsute that has -branch, I removed the suffix in all the other releases
[08:51] <sil2100> Can you re-upload?
[08:51] <tseliot> so, if you can reject just 460 from hirsute I'll fix it
[08:53] <sil2100> o/
[08:54] -queuebot:#ubuntu-release- New: rejected fabric-manager-450 [source] (hirsute-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[08:54] -queuebot:#ubuntu-release- New: rejected fabric-manager-460 [source] (hirsute-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[08:57] -queuebot:#ubuntu-release- New source: fabric-manager-460 (hirsute-proposed/primary) [460.73.01-0ubuntu<IP_ADDRESS>]
[08:58] <sil2100> Ok, this one already looks saner
[08:58] <tseliot> good :)
[08:59] -queuebot:#ubuntu-release- New source: fabric-manager-450 (hirsute-proposed/primary) [450.119.04-0ubuntu<IP_ADDRESS>]
[09:05] <sil2100> tseliot: also, since we're talking about fabric-manager, I see it's still stuck in impish-proposed: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#fabric-manager-450
[09:05] <sil2100> tseliot: will that not be a problem for the stable series?
[09:05] <Laney> stgraber: I think queuebot is not announcing about hirsute unapproved
[09:07] <sil2100> True, I accepted language-pack-gnome-en just some time ago
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (bionic-proposed) [2.04-1ubuntu44.1]
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (focal-proposed) [2.04-1ubuntu44.2]
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [arm64] (bionic-proposed) [2.04-1ubuntu44.1]
[09:25] <Laney> ok looking into this "unknown" problem
[09:57] -queuebot:#ubuntu-release- Packageset: Added libmanette to i386-whitelist in impish
[09:57] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-340 to i386-whitelist in impish
[09:57] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-418-server to i386-whitelist in impish
[09:57] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-435 to i386-whitelist in impish
[09:57] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-tesla-460 to i386-whitelist in impish
[10:01] <apw> ^ that was me ... i am circling with the owner to make sure that is sane
[10:05] -queuebot:#ubuntu-release- Unapproved: neutron (groovy-proposed/main) [2:17.1.1-0ubuntu1 => 2:17.1.2-0ubuntu1] (openstack)
[10:34] <tintou> Hi there! I wonder if there was an estimate on when mutter 3.36.9 will be available in focal, it's already in proposed since a month now :) https://bugs.launchpad.net/oem-priority/+bug/1905825
[10:34] <ubot3> Launchpad bug 1905825 in OEM Priority Project "[SRU] Disable CRTCs when system becomes headless" [Critical, New]
[11:15] -queuebot:#ubuntu-release- New binary: sdl12-compat [amd64] (impish-proposed/none) [0.0~git20210312.a719acd-1] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: sdl12-compat [ppc64el] (impish-proposed/none) [0.0~git20210312.a719acd-1] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: sdl12-compat [arm64] (impish-proposed/none) [0.0~git20210312.a719acd-1] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: sdl12-compat [armhf] (impish-proposed/none) [0.0~git20210312.a719acd-1] (no packageset)
[11:24] -queuebot:#ubuntu-release- New binary: sdl12-compat [s390x] (impish-proposed/universe) [0.0~git20210312.a719acd-1] (no packageset)
[11:25] <apw> tintou, according to the reports it is nor verified on all bugs it purports to fix
[11:26] <apw> tintou, so noone would consider it for promotion; it looks like LP: #1919143 needs appropriate love
[11:26] <ubot3> Launchpad bug 1919143 in mutter (Ubuntu Focal) "SRU mutter to 3.36.9" [Medium, Fix Committed] https://launchpad.net/bugs/1919143
[11:28] -queuebot:#ubuntu-release- New source: golang-1.16 (focal-proposed/primary) [1.16.2-0ubuntu1~20.04]
[11:31] -queuebot:#ubuntu-release- New binary: sdl12-compat [riscv64] (impish-proposed/universe) [0.0~git20210312.a719acd-1] (no packageset)
[11:36] <tseliot> sil2100, sorry, I'll fix it in a bit. And yes, it will be a problem for all series
[11:40] -queuebot:#ubuntu-release- New: accepted rust-retain-mut [s390x] (impish-proposed) [0.1.2-1]
[11:40] -queuebot:#ubuntu-release- New: accepted sdl12-compat [arm64] (impish-proposed) [0.0~git20210312.a719acd-1]
[11:40] -queuebot:#ubuntu-release- New: accepted sdl12-compat [ppc64el] (impish-proposed) [0.0~git20210312.a719acd-1]
[11:40] -queuebot:#ubuntu-release- New: accepted sdl12-compat [s390x] (impish-proposed) [0.0~git20210312.a719acd-1]
[11:40] -queuebot:#ubuntu-release- New: accepted sdl12-compat [amd64] (impish-proposed) [0.0~git20210312.a719acd-1]
[11:40] -queuebot:#ubuntu-release- New: accepted sdl12-compat [riscv64] (impish-proposed) [0.0~git20210312.a719acd-1]
[11:40] -queuebot:#ubuntu-release- New: accepted sdl12-compat [armhf] (impish-proposed) [0.0~git20210312.a719acd-1]
[11:49] -queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (impish-proposed) [5.11.0-1008.8+21.10.1]
[11:56] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [source] (hirsute-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[11:58] -queuebot:#ubuntu-release- New binary: fabric-manager-450 [amd64] (hirsute-proposed/none) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[12:06] -queuebot:#ubuntu-release- New: accepted linux-signed-gkeop-5.4 [amd64] (bionic-proposed) [5.4.0-1016.17~18.04.1]
[12:15] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [source] (hirsute-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[12:19] -queuebot:#ubuntu-release- New binary: fabric-manager-460 [amd64] (hirsute-proposed/none) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[12:51] <tseliot> sil2100, are you going to reject the fabric-managers or shall I simply upload a new revision?
[13:55] -queuebot:#ubuntu-release- New binary: squid [s390x] (impish-proposed/main) [4.13-9ubuntu1] (ubuntu-server)
[13:58] -queuebot:#ubuntu-release- New binary: squid [amd64] (impish-proposed/main) [4.13-9ubuntu1] (ubuntu-server)
[14:02] <doko> do we have the nocheck profile / option still turned on for riscv64 on focal and groovy? I'm just wondering why a gcc build on these releases runs the tests there
[14:02] <tseliot> tjaalton, hey, any chance you can reject all the fabric-managers from hirsute, groovy, focal, bionic again, please?
[14:04] -queuebot:#ubuntu-release- New binary: squid [ppc64el] (impish-proposed/main) [4.13-9ubuntu1] (ubuntu-server)
[14:14] <cjwatson> doko: Hm, I wonder if that was something cowboyed on the buildds that I missed when upgrading them.  wgrant?
[14:16] <tjaalton> tseliot: sure thing
[14:17] -queuebot:#ubuntu-release- New: rejected fabric-manager-450 [source] (bionic-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[14:17] -queuebot:#ubuntu-release- New: rejected fabric-manager-450 [source] (focal-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[14:17] -queuebot:#ubuntu-release- New: rejected fabric-manager-460 [source] (bionic-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[14:17] -queuebot:#ubuntu-release- New: rejected fabric-manager-460 [source] (focal-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[14:17] -queuebot:#ubuntu-release- New: rejected fabric-manager-450 [source] (groovy-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[14:17] -queuebot:#ubuntu-release- New: rejected fabric-manager-460 [source] (groovy-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[14:18] -queuebot:#ubuntu-release- New: rejected fabric-manager-450 [amd64] (hirsute-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[14:18] -queuebot:#ubuntu-release- New: rejected fabric-manager-460 [amd64] (hirsute-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[14:22] <tseliot> tjaalton, thanks
[14:36] -queuebot:#ubuntu-release- New binary: squid [armhf] (impish-proposed/main) [4.13-9ubuntu1] (ubuntu-server)
[14:38] -queuebot:#ubuntu-release- New binary: squid [arm64] (impish-proposed/main) [4.13-9ubuntu1] (ubuntu-server)
[14:39] -queuebot:#ubuntu-release- New source: fabric-manager-460 (focal-proposed/primary) [460.73.01-0ubuntu<IP_ADDRESS>]
[14:39] -queuebot:#ubuntu-release- New source: fabric-manager-460 (groovy-proposed/primary) [460.73.01-0ubuntu<IP_ADDRESS>]
[14:40] -queuebot:#ubuntu-release- New source: fabric-manager-450 (bionic-proposed/primary) [450.119.04-0ubuntu<IP_ADDRESS>]
[14:40] -queuebot:#ubuntu-release- New source: fabric-manager-450 (focal-proposed/primary) [450.119.04-0ubuntu<IP_ADDRESS>]
[14:40] -queuebot:#ubuntu-release- New source: fabric-manager-460 (bionic-proposed/primary) [460.73.01-0ubuntu<IP_ADDRESS>]
[14:40] -queuebot:#ubuntu-release- New source: fabric-manager-450 (groovy-proposed/primary) [450.119.04-0ubuntu<IP_ADDRESS>]
[14:49] -queuebot:#ubuntu-release- Unapproved: fabric-manager-460 (hirsute-proposed/multiverse) [460.73.01-0ubuntu<IP_ADDRESS> => 460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[14:52] -queuebot:#ubuntu-release- Unapproved: fabric-manager-450 (hirsute-proposed/multiverse) [450.119.04-0ubuntu<IP_ADDRESS> => 450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[14:54] <tseliot> sil2100, ok, all the fabric-managers are fixed now
[14:58] -queuebot:#ubuntu-release- New: accepted squid [amd64] (impish-proposed) [4.13-9ubuntu1]
[14:58] -queuebot:#ubuntu-release- New: accepted squid [armhf] (impish-proposed) [4.13-9ubuntu1]
[14:58] -queuebot:#ubuntu-release- New: accepted squid [s390x] (impish-proposed) [4.13-9ubuntu1]
[14:58] -queuebot:#ubuntu-release- New: accepted squid [arm64] (impish-proposed) [4.13-9ubuntu1]
[14:59] -queuebot:#ubuntu-release- New: accepted squid [ppc64el] (impish-proposed) [4.13-9ubuntu1]
[15:12] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (xenial-proposed/main) [2.04-1ubuntu44 => 2.04-1ubuntu44.1] (no packageset) (sync)
[15:13] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (groovy-proposed/main) [2.04-1ubuntu44 => 2.04-1ubuntu44.2] (no packageset) (sync)
[15:34] -queuebot:#ubuntu-release- Unapproved: accepted fabric-manager-460 [source] (hirsute-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[15:35] -queuebot:#ubuntu-release- Unapproved: accepted fabric-manager-450 [source] (hirsute-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[15:37] -queuebot:#ubuntu-release- New binary: fabric-manager-460 [amd64] (hirsute-proposed/multiverse) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[15:38] -queuebot:#ubuntu-release- New binary: fabric-manager-450 [amd64] (hirsute-proposed/multiverse) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[15:47] <Laney> juliank: btw, at the minute we're in some kind of IO death situation, this is a 'multiple cloud workers' case :-)
[15:48] <juliank> Laney: right, maybe week after next week I could work on it, gotta see
[15:50] <Laney> I think we might have to turn down the number of parallel workers
[15:50] <Laney> to make some of these get through
[16:25] <bdmurray> sil2100: Could you have a look at releasing ubuntu-release-upgrader in focal which fixes LP: #1928397?
[16:25] <ubot3> Launchpad bug 1928397 in ubuntu-release-upgrader (Ubuntu Focal) "ensure python is marked for removal when upgrading from 18.04 to 20.04" [Undecided, Fix Committed] https://launchpad.net/bugs/1928397
[16:30] <sil2100> Will do o/ Will get back to SRUs in like 30 mins
[17:14] -queuebot:#ubuntu-release- New binary: confy [amd64] (impish-proposed/none) [0.5.1-2] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: libchemistry-isotope-perl [amd64] (impish-proposed/none) [0.11-1] (no packageset)
[17:15] <Laney> alright, I'm going to tune the number of units down overnight
[17:15] <Laney> it should reduce the load and actually allow some of these big jobs to complete
[17:15] -queuebot:#ubuntu-release- New binary: apispec [amd64] (impish-proposed/none) [3.3.1-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: gsocket [ppc64el] (impish-proposed/none) [1.4.29-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: gsocket [amd64] (impish-proposed/none) [1.4.29-1] (no packageset)
[17:16] <Laney> hopefully when the above mentioned work is done we won't need to do that any more, and can flex the number of controller nodes up instead
[17:16] -queuebot:#ubuntu-release- New binary: libmath-vectorreal-perl [amd64] (impish-proposed/none) [1.02-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: gsocket [armhf] (impish-proposed/none) [1.4.29-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: python-webargs [amd64] (impish-proposed/none) [7.0.1-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: qemu-web-desktop [amd64] (impish-proposed/none) [21.05.03-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: qemu-web-desktop [armhf] (impish-proposed/none) [21.05.03-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: qemu-web-desktop [arm64] (impish-proposed/none) [21.05.03-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: gsocket [arm64] (impish-proposed/none) [1.4.29-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: qemu-web-desktop [ppc64el] (impish-proposed/none) [21.05.03-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (xenial-proposed) [2.04-1ubuntu44.1]
[17:22] <Laney> load average is dropping from 133
[17:32] -queuebot:#ubuntu-release- New binary: gsocket [riscv64] (impish-proposed/universe) [1.4.29-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- Unapproved: python3.9 (focal-proposed/universe) [3.9.5-3~20.04 => 3.9.5-3~20.04.1] (i386-whitelist) (sync)
[17:33] -queuebot:#ubuntu-release- Unapproved: python3.9 (groovy-proposed/universe) [3.9.5-3~20.10 => 3.9.5-3~20.10.1] (i386-whitelist) (sync)
[17:37] -queuebot:#ubuntu-release- Unapproved: accepted python3.9 [sync] (groovy-proposed) [3.9.5-3~20.10.1]
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted python3.9 [sync] (focal-proposed) [3.9.5-3~20.04.1]
[17:41] -queuebot:#ubuntu-release- New binary: qemu-web-desktop [riscv64] (impish-proposed/universe) [21.05.03-1] (no packageset)
[17:42] -queuebot:#ubuntu-release- New binary: gsocket [s390x] (impish-proposed/universe) [1.4.29-1] (no packageset)
[17:43] -queuebot:#ubuntu-release- New binary: qemu-web-desktop [s390x] (impish-proposed/universe) [21.05.03-1] (no packageset)
[17:50] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [source] (groovy-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[17:51] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [source] (groovy-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[17:54] -queuebot:#ubuntu-release- New binary: fabric-manager-450 [amd64] (groovy-proposed/none) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[17:54] -queuebot:#ubuntu-release- New binary: fabric-manager-460 [amd64] (groovy-proposed/none) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[18:04] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [source] (focal-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[18:05] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [source] (focal-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[18:06] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [source] (bionic-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[18:06] -queuebot:#ubuntu-release- New binary: fabric-manager-450 [amd64] (focal-proposed/none) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[18:07] -queuebot:#ubuntu-release- New binary: fabric-manager-460 [amd64] (focal-proposed/none) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[18:09] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [source] (bionic-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[18:10] -queuebot:#ubuntu-release- New binary: fabric-manager-460 [amd64] (bionic-proposed/multiverse) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[18:12] -queuebot:#ubuntu-release- New binary: fabric-manager-450 [amd64] (bionic-proposed/multiverse) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[18:54] -queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.167.1 => 1.167.2] (core)
[18:55] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.167~18.04.2 => 1.167~18.04.3] (core)
[18:55] -queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.167~16.04.2 => 1.167~16.04.4] (core)
[21:09] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [amd64] (groovy-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:09] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [amd64] (groovy-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:10] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [amd64] (focal-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:10] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [amd64] (hirsute-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:10] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [amd64] (focal-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:10] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [amd64] (hirsute-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:11] -queuebot:#ubuntu-release- New: accepted fabric-manager-450 [amd64] (bionic-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:11] -queuebot:#ubuntu-release- New: accepted fabric-manager-460 [amd64] (bionic-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:13] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.167.2]
[21:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.167~18.04.3]
[21:17] -queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (xenial-proposed) [1.167~16.04.3]
[21:18] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.167~16.04.4]
[21:19] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [sync] (groovy-proposed) [2.04-1ubuntu44.2]
[21:35] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [source] (hirsute-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:37] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-460 [amd64] (hirsute-proposed/none) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[21:48] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [source] (hirsute-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:49] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [source] (groovy-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:50] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [source] (groovy-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:50] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-450 [amd64] (hirsute-proposed/none) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[21:51] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [source] (focal-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:52] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [source] (focal-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:52] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-460 [amd64] (groovy-proposed/none) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[21:53] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-460 [amd64] (focal-proposed/none) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[21:53] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-450 [amd64] (groovy-proposed/none) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[21:55] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-450 [amd64] (focal-proposed/none) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[21:56] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [source] (bionic-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:56] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [source] (bionic-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:58] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [amd64] (focal-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:58] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [amd64] (groovy-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:58] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [amd64] (hirsute-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[21:58] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [amd64] (focal-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:58] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [amd64] (hirsute-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[21:58] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [amd64] (groovy-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[22:00] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-450 [amd64] (bionic-proposed/none) [450.119.04-0ubuntu<IP_ADDRESS>] (no packageset)
[22:00] -queuebot:#ubuntu-release- New binary: libnvidia-nscq-460 [amd64] (bionic-proposed/none) [460.73.01-0ubuntu<IP_ADDRESS>] (no packageset)
[22:04] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-450 [amd64] (bionic-proposed) [450.119.04-0ubuntu<IP_ADDRESS>]
[22:04] -queuebot:#ubuntu-release- New: accepted libnvidia-nscq-460 [amd64] (bionic-proposed) [460.73.01-0ubuntu<IP_ADDRESS>]
[22:07] -queuebot:#ubuntu-release- Unapproved: grub2-signed (groovy-proposed/main) [1.167 => 1.167.2] (core) (sync)
[22:25] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [sync] (groovy-proposed) [1.167.2]
[22:32] -queuebot:#ubuntu-release- Unapproved: systemd (groovy-proposed/main) [246.6-1ubuntu1.3 => 246.6-1ubuntu1.4~test1] (core, i386-whitelist) (sync)
[22:34] -queuebot:#ubuntu-release- Unapproved: rejected systemd [sync] (groovy-proposed) [246.6-1ubuntu1.4~test1]
[22:49] -queuebot:#ubuntu-release- New sync: pytest-services (impish-proposed/primary) [2.2.1+ds-2]
[23:06] -queuebot:#ubuntu-release- New: accepted qemu-web-desktop [amd64] (impish-proposed) [21.05.03-1]
[23:06] -queuebot:#ubuntu-release- New: accepted qemu-web-desktop [armhf] (impish-proposed) [21.05.03-1]
[23:06] -queuebot:#ubuntu-release- New: accepted qemu-web-desktop [riscv64] (impish-proposed) [21.05.03-1]
[23:06] -queuebot:#ubuntu-release- New: accepted qemu-web-desktop [arm64] (impish-proposed) [21.05.03-1]
[23:06] -queuebot:#ubuntu-release- New: accepted qemu-web-desktop [s390x] (impish-proposed) [21.05.03-1]
[23:06] -queuebot:#ubuntu-release- New: accepted qemu-web-desktop [ppc64el] (impish-proposed) [21.05.03-1]
[23:07] -queuebot:#ubuntu-release- New: accepted gsocket [amd64] (impish-proposed) [1.4.29-1]
[23:07] -queuebot:#ubuntu-release- New: accepted gsocket [armhf] (impish-proposed) [1.4.29-1]
[23:07] -queuebot:#ubuntu-release- New: accepted gsocket [riscv64] (impish-proposed) [1.4.29-1]
[23:07] -queuebot:#ubuntu-release- New: accepted gsocket [arm64] (impish-proposed) [1.4.29-1]
[23:07] -queuebot:#ubuntu-release- New: accepted gsocket [s390x] (impish-proposed) [1.4.29-1]
[23:07] -queuebot:#ubuntu-release- New: accepted gsocket [ppc64el] (impish-proposed) [1.4.29-1]
[23:07] -queuebot:#ubuntu-release- New: accepted apispec [amd64] (impish-proposed) [3.3.1-1]
[23:07] -queuebot:#ubuntu-release- New: accepted libchemistry-isotope-perl [amd64] (impish-proposed) [0.11-1]
[23:07] -queuebot:#ubuntu-release- New: accepted pytest-services [sync] (impish-proposed) [2.2.1+ds-2]
[23:07] -queuebot:#ubuntu-release- New: accepted confy [amd64] (impish-proposed) [0.5.1-2]
[23:07] -queuebot:#ubuntu-release- New: accepted python-webargs [amd64] (impish-proposed) [7.0.1-1]
[23:07] -queuebot:#ubuntu-release- New: accepted libmath-vectorreal-perl [amd64] (impish-proposed) [1.02-1]
[23:11] -queuebot:#ubuntu-release- New binary: pytest-services [amd64] (impish-proposed/none) [2.2.1+ds-2] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: postgresql-semver [ppc64el] (impish-proposed/none) [0.31.1-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: postgresql-semver [s390x] (impish-proposed/none) [0.31.1-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: postgresql-semver [amd64] (impish-proposed/none) [0.31.1-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: postgresql-semver [armhf] (impish-proposed/none) [0.31.1-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: postgresql-semver [arm64] (impish-proposed/none) [0.31.1-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: postgresql-semver [riscv64] (impish-proposed/universe) [0.31.1-1] (no packageset)
[23:46] -queuebot:#ubuntu-release- New: accepted postgresql-semver [riscv64] (impish-proposed) [0.31.1-1]
[23:47] -queuebot:#ubuntu-release- New: accepted postgresql-semver [amd64] (impish-proposed) [0.31.1-1]
[23:47] -queuebot:#ubuntu-release- New: accepted postgresql-semver [armhf] (impish-proposed) [0.31.1-1]
[23:47] -queuebot:#ubuntu-release- New: accepted postgresql-semver [s390x] (impish-proposed) [0.31.1-1]
[23:47] -queuebot:#ubuntu-release- New: accepted postgresql-semver [arm64] (impish-proposed) [0.31.1-1]
[23:47] -queuebot:#ubuntu-release- New: accepted pytest-services [amd64] (impish-proposed) [2.2.1+ds-2]
[23:47] -queuebot:#ubuntu-release- New: accepted postgresql-semver [ppc64el] (impish-proposed) [0.31.1-1]


[01:52] <duflu> Eeek, brown-out
[01:57] <RAOF> Win!
[02:10] <RAOF> The mediumtests-trusty-touch and mediumtests-runner-mako CI jobs are just failing at the moment, aren't they? That's not an issue with my code?
[02:15] <duflu> RAOF: They are indeed just failing :/
[02:15] <duflu> in 80-90% of cases...
[02:16] <duflu> So you can retry :)
[03:27] <duflu> RAOF: Could you kindly give the changelog and version proposals an honorary approval?
[03:29] <RAOF> There you go.
[03:47] <duflu> RAOF: Ta
[03:48] <RAOF> I know *why* we have debian/ in the repository, I just continue to think it's a bad idea ;)
[03:48] <duflu> RAOF: If we continue with the two separate branches then I agree. But while the goal is to ideally have one, then I disagree
[03:49] <duflu> Hmm, we *could* hide debian/ in dev and just quietly maintain it in lp:mir :)
[03:50] <RAOF> Yes, we could.
[03:50] <duflu> Although that makes code reviews of packaging changes impossible
[03:50] <duflu> Umm, less convenient
[03:50] <RAOF> Not really? We just review on lp:mir
[03:51] <RAOF> I don't think it's a bad idea to have packaging changes reviewed in a different place to code changes; our developer skill sets are almost entirely disjoint, too.
[03:51] <duflu> Surely debian/ as a subdirectory is designed that way so you can keep it with your code without stepping on any toes
[03:52] <RAOF> Historically it has not been; we're being an unhelpful upstream by including it.
[03:52] <RAOF> (This is mostly fixed with deb src 3.0, though)
[03:52] <duflu> RAOF: I hate to say it, but code reviews are even more scarce on lp:mir than dev.
[03:53] <RAOF> Are there any reviews to *do* on lp:mir?
[03:53] <duflu> I mean, if you rely on the subset of developers with the skills to review packaging changes, then you don't have enough reviewers
[03:54] <RAOF> Ah, but we can get potentially get didrocks and other distro people to review those changes.
[03:54] <duflu> Because he loves us so much already
[03:54] <duflu> And rightly so
[03:54] <duflu> I mean that both ways
[03:55] <RAOF> No one from distro is going to regularly check merges that are almost all code changes unrelated to distro work; if we separate out those quite-infrequent changes it's more likely we can shanghai people to do them.
[06:58] <RAOF> duflu: What's the typo?
[06:58] <duflu> RAOF: construtor ?
[06:59] <RAOF> AHA!
[06:59] <duflu> Or is it copy-construe-er?
[07:00] <duflu> If all else fails, copy and paste into an edit field with spell-checking
[07:02] <RAOF> Hm. I do appear to have dropped into my native braces style a bit there, don't I?
[07:04] <RAOF> Also, I'm pretty sure our style guide suggests 120 characters ;)
[07:06] <duflu> RAOF: On the theme of readability, not style compliance :)
[07:07] <duflu> Though I've already spent enough of my life trying to explain to people why a limit of 80 cols is important. I won't waste my breathe (much) more
[07:08] <duflu> breath too
[07:13]  * RAOF wonders if we should set up clang-format as a precommit hook.
[07:22] <duflu> RAOF: I suspect we have too many exceptions we'd like to keep :)
[07:23] <duflu> Including 3rd party, which we wish to not touch where possible
[07:44] <tvoss> RAOF, +1 on clang-format
[08:38] <anpok> is there a rule for curly braces placement .. egyptian vs on the same column?
[08:39] <RAOF> Is egyptian
[08:39] <RAOF> if (foo)
[08:39] <RAOF> {
[08:39] <RAOF>    hello();
[08:39] <RAOF> }
[08:39] <RAOF> ?
[08:39] <RAOF> If so, yes, we use Egyptian :)
[08:39] <anpok> nope
[08:39] <anpok> if (foo) {
[08:39] <anpok>    hello();
[08:39] <anpok> }
[08:40] <anpok> http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html
[08:48] <alf_> anpok: http://unity.ubuntu.com/mir/cppguide/index.html
[08:51] <tvoss> olli, ping
[08:51] <anpok> alf_: yes, but it only states it for function definitions.. and some examples use { on the same line..
[08:52] <alf_> anpok: they are wrong :)
[08:52] <anpok> obviously
[08:54] <duflu> Awesome. Now I can code like an Egyptian and party like it's 1986 simultaneously
[08:57] <RAOF> alf_: I'd like a second opinion on GLContext { void make_current() const; }; duflu has suggested that having it be const is an artefact of using non-C++ types, and I can see that, but I vacillated when writing the commit message for unconstifying it.
[08:57] <RAOF> alf_: cf: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510
[08:58] <duflu> RAOF: I'm happy to keep const. Just expect it to be non-const if the implementation changes
[09:00] <RAOF> duflu: Ok then. I think conceptually const makes more sense, and it's an implementation detail if it isn't.
[09:00] <duflu> Yeah const is always a maintenance risk in that way
[09:01] <duflu> There's a reasonable argument for not having const in the language :)
[09:01] <duflu> Although I think having const with clearly defined policy is better
[09:14] <anpok> it is always simpler to explain the usage of const_cast / mutable if it is to fulfill a const in the problem domain, than because of a possible trivial implementation
[09:16] <anpok> duflu: any suggestions on the pixel format encoding? should I only take RGB based formats into account now..
[09:16] <anpok> or look for something that also adresses yuv ..
[09:17] <duflu> anpok: I suggest sticking with what you have (don't change MirPixelFormat for now). It's nice and forward compatible to just define query functions like you have
[09:17] <duflu> Fitting all the info we need into 32-bits is quite difficult actually
[09:18] <anpok> SDL2 does something similar .. but they dont encode shift values directly
[09:20] <duflu> anpok: The panacea is an accurate set of instructions for interpreting/encoding any pixel :)
[09:20] <duflu> Without switch/case
[09:21] <RAOF> We should probably look at gallium's format descriptor infrastructure.
[09:22] <RAOF> anpok: That's what your merge proposal triggered for me.
[09:22] <anpok> the one in gbm.h
[09:22] <anpok> ?
[09:23] <duflu> I think fourcc is kind of OK, but fails to resolve the bug really. You have to switch on all known fourcc's. It's ugly
[09:23] <RAOF> anpok: No... let me hunt it down.
[09:23] <duflu> Hmm SDL_pixels.h is interesting
[09:26] <RAOF> https://github.com/RAOF/mesa/tree/egl-platform-mir/src/gallium/auxiliary/util - u_format.{c,h,csv}
[09:28] <RAOF> A bunch of that is driver-implementation-specific, but the general gist could be useful.
[09:32] <anpok> hm there are also compressed formats
[09:32] <anpok> hm those would not be needed ...
[09:34] <RAOF> Right. There are a huge number of formats there, most of which we wouldn't need.
[09:35] <RAOF> Also, we (probably?) don't need all that description; block width and height, channel swizzle, layouts that aren't ‘plain’
[09:36] <anpok> that reminds me of https://github.com/laanwj/etna_viv/blob/master/doc/hardware.md
[09:37] <anpok> if I am not mistaken the device can render to super tiled frame buffers.. and the optional composition gpu can do scanouts on those
[09:48] <anpok> that might be relevant again with hwc on android
[09:49] <anpok> different topic in some code parts DisplayConfigurationPolicy is named "initial" conf.. why only initial?
[09:50] <anpok> i initially assumed that.. if changes to the available displays happen the policy would querried again
[09:53] <RAOF> anpok: No; that's only used for initial configuration, and something else is assumed to handle configuration on hotplug events.
[10:00]  * RAOF EODs
[10:26]  * duflu too. Overdue for cooking a healthy meal
[11:45] <mlankhorst> RAOF: grrr! fix your trailing whitespace
[12:31] <mlankhorst> RAOF: anway xorg-server for saucy-proposed, pixman and libdrm for all supported releases in the release queue:)
[13:19] <anpok> i am a bit concerned about the conversion operator usage
[13:19] <anpok> in EGLDisplayHandle and similar... not widely used. it seems odd to have conversion operators for typedefs of void*
[15:16] <kgunn> bregma: did RAOF get you the mesa you needed for nested mir on desktop ?
[15:16] <kgunn> never saw a follow up
[15:22] <anpok> kgunn: iirc nested mir on desktop also needs a small change in mesa platform which is currently in review
[15:23] <kgunn> anpok: exactly, this is what i was asking about
[15:23] <kgunn> anpok: i looked at raof's github but didn't see any reference
[15:23] <kgunn> but maybe i don't know where to look exactly ?
[15:24] <kgunn> can you share if you do ?
[15:25] <anpok> sorry my wording was ambigiuous ..
[15:25] <anpok> mir/mesa needed another change
[15:25] <anpok> there is some utility class that needs surfaceless context, but creates a pbuffer surface which is not supported by mesa.
[15:26] <anpok> https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510 thats the change
[15:40] <xnox> Does mir at all can export / has api to query detected screen resolution and the DPI setting?
[15:44] <anpok> you can querry that through the mir client api - take a look at demo_client_display_config.c in the examples folder
[16:09] <kdub> yay https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037904.html
[16:10] <xnox_> =)
[16:11] <kdub> i was just looking up who to +1... i'll see  if  i can drop my amateur cmake cross compile file from mir
[16:26] <kgunn> kdub: so did you say if you put in some logic to "ignore" the second "on"...display turns on but then hangs ?
[16:27] <kdub> kgunn, right
[16:28] <kdub> like, the problem is
[16:28] <kgunn> kdub: damn...that's just weird...so not only does powerd send it...it meant to send it :)
[16:28] <kdub> right
[16:28] <kdub> i'm still poking around powerd trying to understand
[16:29] <kdub> ricmm, ping
[16:35] <greyback> kdub: anything I could do to help?
[16:36] <kdub> greyback, don't know of anything at the moment
[16:37] <greyback> kdub: ok
[16:37] <kdub> unity-mir's role seems to be pretty straightforward
[17:33]  * mterry pokes ricmm about libhybris
[17:34] <kdub> mterry, what about hybris?
[17:35] <mterry> kdub, that libhybris fix that ricmm identified during the sprint, to allow two different users (root and phablet) to access hw on maguro
[17:36] <mterry> It's the last fix needed for nested mode to land
[17:37] <kdub> ah, okay
[17:37] <kdub> mterry, is screen on/off with nested working okay? i have some concerns about that
[17:38] <kdub> eh, actually, i'd expect it to work
[17:39] <kdub> its just funny that we make the power request to a nested client who asks the host server
[17:39] <kdub> too many hops
[17:40] <mterry> kdub, no, UCS is actually the one that will host the dbus interface
[17:40] <mterry> kdub, the unity-mir code to do it is still there, but will gracefully fail once UCS already owns it
[17:40] <mterry> kdub, and then we can remove that codee
[17:40] <kdub> mterry, great, sounds good
[20:57] <kgunn> kdub: so i was just trying your instructions...i'm on N4 with todays devel-proposed image...after i install mir-test-tools
[20:58] <kgunn> the only mir test i see is mir_stress
[20:58] <kgunn> any ideas?
[20:58] <kgunn> https://docs.google.com/a/canonical.com/document/d/1oxXDxehRQ35rYRwkuBCy1ZNmB_IBpg5UhE3jvNHEk_0/edit
[21:00]  * kdub looks
[21:07] <kdub> they were added in rev 1256
[21:07] <kdub> and it looks like 1248 was the last merge to lp:mir
[21:08] <kdub> kgunn^^
[21:09] <kgunn> kdub: heh
[21:09] <kgunn> fell victim


[07:18] <lordievader> Good morning
[09:30] <rbasak> leftyfb: have you looked into Ubuntu IoT stuff? Read only images, atomic updates, etc.
[11:17] <ahasenack> cpaelzer: rbasak: hi, when any of you have a moment, I have this MP to unblock ldb in disco: https://code.launchpad.net/~ahasenack/ubuntu/+source/ldb/+git/ldb/+merge/359774
[11:20] <rbasak> Looking
[11:21] <rbasak> done
[11:37] <cpaelzer> that was fast rbasak, I didn't even see it until now :-)
[11:41] <rbasak> Anything to distract me from this qemu+libvirt SRU review :-P
[11:43]  * cpaelzer sniff
[12:10] <ahasenack> rbasak: hah, I did forget update-maintainers
[12:10] <ahasenack> ran it and pushed
[12:10] <rbasak> ahasenack: go ahead and upload, no need for me to look again
[12:10] <ahasenack> thx
[12:20] <cpaelzer> thanks rbasak
[12:21] <rbasak> yw
[12:21] <rbasak> Thank you for your diligence in preparing the update. Makes review easier.
[12:22] <rbasak> Lining up the patch names across the releases was a great help.
[12:22] <cpaelzer> yeah
[12:22] <cpaelzer> unfortunately the backports were different for the two target versions
[12:22] <rbasak> Yeah libvirt patch 5 threw me a little
[12:22] <cpaelzer> but as you said - I have hoped that keeping patch metadata and names intact would help
[12:22] <kstenerud> ahasenack: What does it mean when a bileto ticket is abandoned?
[12:22] <cpaelzer> rbasak: was that the fused one?
[12:23] <cpaelzer> rbasak: TBH IBM was the one fusing it into one, I personally would have preferred three stripped down patches. But then I was glad for their help - so no complaining
[12:23] <rbasak> I think so
[12:23] <rbasak> lp1787405-0005-qemu-Extract-MDEV-VFIO-PCI-validation-code-into-a-se.patch vs. lp1787405-0005-qemu-domain-device-definition-hostdev-validation.patch
[12:24] <cpaelzer> I see
[12:26] <rbasak> What I've been doing recently for similar SRUs is to first identify how the uploads are different between devel and the SRU target releases, and confirm I'm happy with those differences. Once done I reduce what I have left to review to one release only.
[12:26] <rbasak> (plus changelog and other metadata, but at least there's less meat that way)
[12:29] <ahasenack> kstenerud: I dropped it, since I was satisfied with the results and uploaded the package already
[12:29] <ahasenack> kstenerud: it will disappear in due time
[13:56] <muhaha> Anyone using Proxmox and using PXE to boot/install unattended install ?
[14:10] <talx> hello folks
[14:25] <ahasenack> rbasak: cpaelzer: hi again, ldb is basically done, but now I need a samba upload, which is a rebuild because of ldb bump, and a merge from debian: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/359776
[14:25] <ahasenack> kstenerud: check "trying: ldb" in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[14:26] <ahasenack> kstenerud: this one is an indication that samba needs a rebuild, because of samba-dsdb-modules
[14:26] <kstenerud> ahasenack: So that means taht samba-dsdb-modules depends on ldb?
[14:27] <ahasenack> yes, a very strict dep
[14:28] <ahasenack> from d/rules (samba's):
[14:28] <ahasenack> # samba ships ldb modules, which are specific to the ldb version, so we need a
[14:28] <ahasenack> # strict dependency on the upstream ldb version
[14:28] <ahasenack> # this also mean samba needs a rebuild when the upstream ldb version changes
[14:28] <ahasenack> LDB_DEPENDS = "libldb1 (<< $(LDB_EPOCH):$(LDB_NEXT_VERSION)~), libldb1 (>> $(LDB_EPOCH):$(LDB_VERSION)~)"
[14:29]  * ahasenack -> lunch
[15:55] <ahasenack> rbasak: when you say "Since we can't easily unpin with a cached copy of pylint", you are talking about https://people.canonical.com/~rbasak/git-ubuntu/pylint-1.7.2.tar.gz or something else that snapcraft caches?
[16:18] <rbasak> ahasenack: yeah, the p.c.c one.
[16:34] <ahasenack> rbasak: ok
[16:47] <Pcost8300> hello Everyone and good afternoon, I would like to know if changing an Ubuntu Server 14.04 Time to just one hour up could cause any trouble with databases or the glassfish server that is running in there.
[16:48] <lordcirth> Why do you need to change the time?  Is it currently wrong?
[16:49] <rbasak> Pcost8300: if you change the server's idea of UTC, then that will break things. Changing the server's timezone is generally fine though.
[16:54] <Pcost8300> rbasak: Thank you for the information, when i type date command it says time with CST 2018 at the end
[16:55] <Pcost8300> rbasak: sorry for asking but what does it mean
[16:57] <Greyztar> Central Standard Time no?
[16:57] <rbasak> He's gone
[16:57] <Greyztar> :/
[18:39] <ahasenack> rbasak: around still? https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1805178 is asking to have apparmor allow access to /etc/letsencrypt for the certificates, is the "canonical" place for the certs? What is its structure?
[18:44] <rbasak> ahasenack: IIRC, /etc/letsencrypt/live/$domain/ and then pem and keys in there
[18:45] <rbasak> ahasenack: private keys are very sensitive. I'm not sure it makes sense to default to giving all services access to them.
[18:45] <ahasenack> rbasak: can you imagine us shipping some sort of default allow-to-read apparmor role?
[18:45] <ahasenack> yeah
[18:45] <ahasenack> I'm inclined to suggest that users override that locally when needed
[18:45] <rbasak> For example, if I were running an HTTPS server, it may be the completely wrong thing for a compromise of slapd to compromise the key
[18:45] <rbasak> Maybe jjohansen and/or jdstrand have an opinion on that: ^
[18:45] <ahasenack> I was hoping that /etc/letsencrypt structure would include the service name, or user name
[18:46] <rbasak> AIUI letsencrypt makes no distinction on service name.
[18:46] <rbasak> Everything is HTTPS, but you apparently can re-use certs for other services
[18:46] <ahasenack> I mean, the directory structure could be something like /etc/letsencrypt/slapd/*.pem
[18:46] <rbasak> (and you don't need HTTP/HTTPS to get a cert, since you can use DNS to prove domain ownership)
[18:46] <sdeziel> ahasenack: I the same cert for various services (postfix + dovecot typically)
[18:46] <ahasenack> yeah, the re-use makes this more complicated, if it's common
[18:47] <sdeziel> s/I the/I use the/
[18:47] <ahasenack> apparmor ships with two abstractions related to certificates
[18:47] <ahasenack>  /etc/apparmor.d/abstractions/ssl_certs and /etc/apparmor.d/abstractions/ssl_keys
[18:48] <ahasenack> they are not pulled in by default
[18:48] <ahasenack> maybe we could have an letsencrypt abstraction, and let the user decide what he/she wants (or augment the existing ones for letsencrypt)
[18:48]  * ahasenack just noticed that he is not in #ubuntu-hardened
[18:49] <sdeziel> with the proliferation of Let's Encrypt clients, it will be hard to catch up with abstractions
[18:50]  * sdeziel uses local/ includes
[18:50] <teward> sdeziel: ahasenack: it sounds like this should be posed to the Security team for additional consideration/review as well?
[18:51] <teward> because such additional abstractions to /etc/letsencrypt or {Insert Paths Here} can be security concerns in and of themselves
[18:51] <teward> (read: privkey security, etc.)
[18:51] <ahasenack> sure
[18:56] <jjohansen> rbasak: hrmmm I need to spend some time looking at this to have an informed opinion. I don't like having a default that might be wrong on servers
[18:57] <jjohansen> I agree with teward that this should go to the security team for additional consideration
[18:58] <teward> rbasak: ahasenack: in *theory* I agree with the idea for the apparmor access via an abstraction
[18:58] <teward> but from the **security** side of theory I have some very harsh critiques for the practice
[18:58] <teward> in sysadmin and ease of use theory*
[18:59] <ahasenack> there is one such abstraction already, fwiw
[18:59] <teward> because as rbasak says, private key sensitivity
[18:59] <teward> ahasenack: the second part of the argument is catching up with all the clients
[18:59] <ahasenack> I fully expect a wide range of paranoid levels around this issue
[18:59] <jjohansen> I marked the bug public security for now
[18:59] <ahasenack> for now I suggested in the bug that he use the apparmor.d/local mechanism to add his local changes
[19:00] <ahasenack> and asked what's the structure of his /etc/letsencrypt directory
[19:00] <teward> +1 for local abstractions per your suggestion ahasenack
[19:00] <ahasenack> teward: about the "all the clients" argument, we should first think about what the ubuntu client (certbot in this case) does
[19:00] <teward> +1
[19:00] <ahasenack> I subscribed to the bug, will know when there is a reply
[19:00] <ahasenack> thanks for the quick discussion :)
[19:00] <teward> ahasenack: AIUI, /etc/letsencrypt/live/*/[crt,key,etc. here] is where it'd need to be reading
[19:01] <teward> * for the individual domain(s) as masters on the cert
[19:01] <teward> and then the individual certs and keys under that
[19:01] <ahasenack> ok
[19:01] <teward> as well as the CA chain where needed
[19:03] <sdeziel> the only sensitive part in there is the key so is it root owned and with a special extension (like .key)?
[19:03] <teward> I think so *double checks his LE test system*
[19:03] <sdeziel> thanks, I only use dehydrated myself :)
[19:04] <teward> sdeziel: actually, access to the dir might be tricky
[19:04] <rbasak> jjohansen: understood. Thanks!
[19:04] <teward> sdeziel: live/* root:root 700
[19:04] <sdeziel> teward: most daemons start as root so what's your concern?
[19:05] <teward> sdeziel: true, but in cases where a daemon woudln't it wouldn't have access
[19:05] <teward> i'm not familiar as much with openldap, it starts as root I assume?
[19:05] <sdeziel> teward: probably since it bind port 389 and/or 686
[19:06] <teward> i just realized I don't have latest certbot on this system :|
[19:06] <teward> sdeziel: at least with 0.22.2, /etc/letsencrypt/live/*/privkey.pem
[19:06] <teward> but i'mma have to spin a bionic for newer testing
[19:07] <teward> ... once I get home (can't access my infra at home for better testing from here at the moment)
[19:07] <sdeziel> teward: thanks
[19:08] <teward> sdeziel: but everything in that folder is a *.pem so it's not a special extension to specify the key
[19:08] <teward> IIRC this is still the way it behaves today in latest but eh
[19:09] <teward> ... oh THERE'S my VPN keys... I was looking for these earlier to VPN back home >.>
[19:10] <sdeziel> so far, the safest way I found (please let me know of any flaw) is to have an install/deploy hook to put the cert/key in /etc/$daemon/certs/ and make them root:root 0600. Combined with this Apparmor rule: "/etc/$daemon/certs/* r,"
[19:11] <teward> sdeziel: 30/60d cert regen means you need to redeploy the cert each time, unless I misunderstand what you mean by 'deploy hook'
[19:11] <sarnold> root:root may mean you've got to run your daemon at higher-than-needed privs
[19:12] <teward> duh I forgot sarnold was in here LOL
[19:12] <teward> *facedesks, then goes to find more caffeine*
[19:12] <sarnold> don't take that to mean I'm *paying attention*
[19:13] <sdeziel> sarnold: for the services I manages, most of them keep a master process (nginx, postfix, dovecot) so a simple reload is enough to pick up the new cert/key. prosody is an outlier here though
[19:13] <teward> sarnold: no, I just meant I can ping you and annoy the heck out of you on these things in here *evil grin*
[19:13] <sarnold> sdeziel: nice
[19:13] <teward> :P
[19:13] <sarnold> ah :)
[19:14] <sdeziel> to improve on the Apparmor rules, I guess that leveraging the hardcoded names would work "/etc/$daemon/*chain.pem r," and "owner /etc/$daemon/privkey.pem r,"
[19:15] <sdeziel> and I forgot the $domain so they should all be prefixed /etc/$daemon/*/ to support whatever CN you happen to use
[19:17] <sdeziel> anyway, I like this scheme better than all the keys in /etc/ssl/private
[19:20] <sdeziel> teward: yes, I re-deploy certs and keys all the time (I don't reuse keys)
[20:03] <Greyztar> setting after and wants in systemd service file ,will that make the parent service not start until the dependencie is successfully started?
[20:20] <lordcirth> Greyztar, that's the idea, yes
[20:21] <Greyztar> lordcirth: ive been doing some reading,just wanted it confirmed as google can be sometimes well...thanks for answering me (,")
[20:23] <lordcirth> np
[22:22] <docmur> I have a fresh apache2 setup with two domains configured 000-default.conf and test.conf, whe nI try to navigate to test.ca, I'm getting the default location /var/www/html returned and not /var/www/test, these are the config files: https://pastebin.com/L8LYfH6x
[22:22] <docmur> shouldn't that work?
[22:22] <docmur> I just did a purge and install of apache2 so everything else should be generic
[22:29] <Greyztar> when sourcing a file with some variables or so in bash,that would only last current session no?So when a reboot takes places what have been sourced is gone?
[23:55] <mybalzitch> will changes made by ovs-vsctl to add/remove ports persist through a reboot?


[06:57] <knightwise> morning everyone
[07:00] <brobostigon> morning
[07:06] <knightwise> hey brobostigon
[07:06] <knightwise> how you doin man
[07:07] <brobostigon> hangover, today is my birthday, i had a drink with my dad yesterday, and this afternoon with my fiance and friends.
[07:07] <brobostigon> and you?
[07:07] <knightwise> happy birthday brobostigon
[07:07] <brobostigon> ty, :)
[07:07] <knightwise> hope you have a great day
[07:07] <brobostigon> :)
[07:07]  * knightwise is writing up a script for the next podcast
[07:07] <brobostigon> :)
[07:08] <knightwise> my new imac running helium is realy helping me with my creativity , i have more focus to write to i started working on a script
[07:09] <brobostigon> thats good,
[07:09]  * brobostigon bought himself a google home, so his productivity will dip a bit now.
[07:36] <knightwise> brobostigon: its quite nice actualy
[07:36] <knightwise> I use it to play podcasts and stuff. Very handy
[07:37] <brobostigon> yes, i found it easy to setup, however the home app isnt the easiest to work out.
[07:37] <knightwise> no thats true. We use it a lot to do stuff like turning on the lights and the tv and stuff
[07:37] <knightwise> I still have 2 spare smartlights for the office I should setup
[07:37] <brobostigon> :)
[11:06]  * zmoylan-pi struggles with the light switch... :-P
[11:09]  * brobostigon points zmoylan-pi in the right direction.
[11:31]  * zmoylan-pi changes the lightbulb to the red bulb for red alerts and initiates red alert procedures... i flick the light switch to turn on the red bulb...
[11:33] <penguin42> klingon's on the starboard bow?
[11:33] <zmoylan-pi> intruder alert pointing at the light switch!!
[11:35]  * brobostigon rolls for perception,
[11:36]  * zmoylan-pi checks stats, half elf, dark vision...
[11:37] <brobostigon> wood elf
[11:37] <zmoylan-pi> now there's an idea. a cut down dnd that can be played irc... maybe an abbreviated tunnels and trolls...
[11:40] <brobostigon> :)
[12:59] <knightwise> I should probably learn how to play DND
[12:59]  * knightwise has no clue
[13:00] <knightwise> Ok , gonna check if I can record a podcast here.
[13:00] <knightwise> ttyl
[14:12] <knightwise> allllright!
[14:12] <knightwise> just managed to get sshfs working via fuse on my mac
[14:13] <knightwise> now mounting all of the folder on my server natively on my mac
[14:13] <knightwise> THIS is gonna save me a ton of time
[14:13] <zmoylan-pi> oooh, sounds good....
[14:16] <knightwise> YES è
[14:16] <knightwise> Thrilled about this. all i need now is to find a way to do the same thing on windows
[14:17] <knightwise> https://codeyarns.com/2018/05/03/how-to-mount-remote-directory-on-windows-using-sshfs-win/
[14:17] <knightwise> gonna try this
[20:37] <brobostigon> is anyone aware of a router/ap that has two earials, ie can connect to one wifi network and the other aerial running as a wifi AP?
[20:41] <zmoylan-pi> does it need 2 aerials to do that?
[20:41] <brobostigon> good question, i am making an assumption.
[20:44] <daftykins> it wouldn't need to be a router if it were just extending an existing network
[20:45] <daftykins> there are extender APs, but making packets hop twice is an absolute abomination and shouldn't be done
[20:45] <daftykins> if you're wanting to cover a wifi deadspot in the home or something, a pair of powerline adapters where one of the two is an access point one would be a good solution
[20:45] <daftykins> better yet - a normal access point with a cable back to the main router
[20:50] <brobostigon> i will research those, good thinking. :)
[20:55] <penguin42> brobostigon: There are wireless extenders that do exactly that
[20:55] <penguin42> brobostigon: There are also wireless routers that you can add multiple and they somehow organise themselves
[20:56] <brobostigon> so either option could work, just need to work out which is going to be most cost effective.
[20:58] <daftykins> those do not sound like routers, but mesh APs - all bollocks
[20:58] <daftykins> i highly, highly... strongly advise against anything that relies on radio hopping twice :P
[21:01] <brobostigon> the issue i am ultimatly trying to solve, is the wifi network at work, cant allow devices to see eachother, ie when i tried to setup a google home at work it wouldnt work because the phone and home couldnt see eachother, which works fine on my home at home, because it allows devices to see eachother connected to the same network.
[21:01] <penguin42> yeh if you can't point to the wire that your packets slithering down, just dont believe it
[21:01] <daftykins> yeah they've probably turned on wifi client isolation
[21:02] <daftykins> pretty common setting on some stuff
[21:02] <daftykins> why is any smart tosh getting hooked up in a workplace though? D:
[21:03] <penguin42> so the boss can say 'Engage!'
[21:03] <daftykins> ooh there's a wet trout with their name on :)
[21:04] <daftykins> ah, exciting times in an hour from now - doing a late birthday surprise for a pal, i paid a couple of sci-fi TV show celebs on cameo.com to do birthday greeting videos for him - and they did an incredible job of it
[21:05] <penguin42> which celebs?
[21:05] <daftykins> two peeps that were in the 2003 Battlestar Galactica
[21:05] <penguin42> ah
[21:06]  * penguin42 hadn't heard of Cameo
[21:06] <brobostigon> daftykins: my thinking exactly, after a little testing.
[21:06] <daftykins> nah nor me, someone mentioned it by chance the Thursday before last - i knew a birthday was coming up so i jumped at the chance :D
[21:07] <brobostigon> my answer right now, is having a usb wifi adaptor on my desktop boardcasting a seperate network, so both devices can see eachother and use the network underneath.
[21:09] <daftykins> dunno what your workplace is like, but that breaks so many terms to me xD
[21:09] <brobostigon> however i am trying to think of a more permanent answer.
[21:10] <brobostigon> daftykins: atm they dont know about it, i plan to bring it up and whats needs changing to get it working.
[21:13] <daftykins> don't know about the wifi isolation or the Google smart trash? :D
[21:13] <penguin42> daftykins: Hehe some names I actually recognise on there
[21:13] <daftykins> :)
[21:14] <brobostigon> i am just trying to think if there is a way around the client isolation.
[21:14] <daftykins> well you'd have to query the config of the wifi providing device(s)
[21:15] <brobostigon> which already a set of extenders anyway.
[21:15] <brobostigon> which is*
[21:15] <daftykins> ugh
[21:15] <brobostigon> exactly.
[21:16] <daftykins> sounds like it's just a symptom of those then, usually a smart gadget would rely on broadcast use so those probably don't work at that layer
[21:16] <daftykins> pretty common shortcoming
[21:16] <brobostigon> agreed.
[22:31] <penguin42> daftykins: I can imagine a version of cameo where it first gives you a deep-fake version of what you ask for, and if you dont think its good enough asks you to pay the real actor $n more
[22:33] <daftykins> hahaha


[11:45] <danilos> bac, hi, I've added a comment to the MP for bug 799001 about how you can easily go about extending the existing framework to perform well, it's just some lovely storm magic to return tuples where appropriate
[11:45] <_mup_> Bug #799001: gnome-panel crashed with SIGSEGV in gtk_widget_pop_verify_invariants() <apport-crash> <i386> <oneiric> <GNOME Panel:New> <gnome-panel (Ubuntu):Triaged> < https://launchpad.net/bugs/799001 >
[11:54] <danilos> uhm, make that bug 799901
[11:54] <_mup_> Bug #799901: "subscribed by" omitted from the title of links in subscriber list <regression> <story-better-bug-notification> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/799901 >
[12:06] <bac> danilos: cool, thanks
[12:07] <bac> danilos: making that part more efficient will be great.  but i wonder if it is really a problem.  this is the same method used before and it wasn't causing time outs afaik
[12:23] <danilos> bac, well, we were not doing person look-ups other than those in the one big query, and those tend to be the slowest
[12:28] <gary_poster> bac benji danilos gmb: skype in 2
[12:29] <bac> ok
[13:41] <benji> gary_poster: do you know anything about how storm caches objects that it has loaded from a DB?
[13:42] <gary_poster> benji, I did art one point :-P
[13:43] <gary_poster> benji, danilos will probably have it more available on the tip of his brain, but you can try me too
[13:43] <benji> this is all I found documentation wise, and it's a bit thin: https://storm.canonical.com/Tutorial#Caching%20behavior
[13:44] <benji> I think I can make my branch perform reasonably if I can just get Storm to stop making the same queries over and over.
[13:44] <gary_poster> I see. It's a simple cache.  object id -> object IIRC
[13:45] <gary_poster> that means that it is not super helpful for mass queries IME
[13:45] <danilos> benji, you can basically just do something like list(store.find()) to bring objects in cache
[13:46] <gary_poster> benji, there are patterns for this stuff that lifeless has pioneered...
[13:46] <gary_poster> danilos is the man.  he will help you :-P
[13:46] <benji> gary_poster: do you know where any of those patterns have been documented or crystallized?
[13:46] <danilos> benji, however, the page you are touching is mostly getting all the data with one query
[13:47] <gary_poster> benji, person.py is what I was thinking of
[13:47] <benji> danilos: I'm confused because I see the same queries being executed (some times back to back)
[13:47] <benji> gary_poster: thanks
[13:47]  * gary_poster looks for details, though he suspects danilos will get him on right track faster
[13:48] <danilos> benji, they could be, but the main query fetching all templates and relevant details is a single query for all however many templates there are
[13:49] <danilos> benji, basically, side-queries on the page are not optimized, but the big one is
[13:49] <gary_poster> benji, I was thinking of getPrecachedPersonsFromIDs
[13:49] <gary_poster> it might be the kind of thing you need
[13:49] <benji> danilos: can you proffer a reason why I'd see the same query executed twice back to back?
[13:50] <benji> gary_poster: thanks, I'll look at that
[13:50] <danilos> benji, which query is it? perhaps a .count() and then the query
[13:50] <gary_poster> because it sounds like you have a single query that gets you the data you want, but then you need to get a bunch of objects on the basis of that query
[13:51] <benji> danilos: here's an example of one that is executed twice, back to back: http://paste.ubuntu.com/649123/
[13:51] <danilos> benji, important thing is that the number of queries is close to constant and that it doesn't scale with the number of objects being fetched; sometimes the code might be doing a few queries as opposed to one (I don't remember exact details for this page)
[13:52] <danilos> benji, that query seems to not be needed for the page as it was before (that's for determining links between packages and projects, to "link" the sharing templates)
[13:52] <benji> danilos: my branch intoduces that query
[13:53] <benji> my increasted query count is roughly linear with the number of rows in the result, so not good
[13:53] <danilos> benji, right
[13:54] <danilos> benji, basically, it'd be good to move this query into the big query as a join
[13:56] <benji> danilos: is "the big query" the potemplateset.getSubset call in iter_templates?  That's the only place I see data being gathered, but it doesn't look much like a query.
[13:56] <danilos> benji, could be the TemplatesCollection stuff which wraps queries with a collection pattern
[13:56] <danilos> benji, let me take a look
[13:57] <benji> danilos: it's a POTemplateSubset object
[14:04] <danilos> benji, right, it'd probably be good to switch it to the TranslationTemplatesCollection which'd work nicer and would be much easier to extend (considering it's storm-based instead of manual query construction)
[14:04] <benji> danilos: ok, let me take a stab at that
[14:05] <danilos> benji, I'd keep that as a branch dependent on the one you already have because you have something that works already I believe :)
[14:06] <benji> danilos: I don't follow.  I intended to start a new branch from devel, refactor the existing code to use TranslationTemplatesCollection and once I got that working add my new functionality on top.
[14:06] <danilos> benji, if you look at model/hastranslationtemplates.py (and interface), that's what all of productseries/distroseries/sourcepackage should implement already
[14:06] <danilos> benji, that's fine as well :)
[14:10] <danilos> benji, fwiw, this refactoring works for me: https://pastebin.canonical.com/50060/
[14:10] <benji> danilos: cool, thanks
[14:12] <danilos> benji, np, I just wanted to confirm it myself; how to get more data easily is shown in other methods of HasTranslationTemplates
[14:13] <benji> k
[14:13] <danilos> gary_poster, btw, I haven't had any food, and I wonder if we can either have an early call so I can go fetch some food after that or if we can delay it a bit so I go fetch the food now? :)
[14:14] <gary_poster> danilos, heh, either way, but I vote for you getting food first.  No one wants to face a hungry danilos alone.
[14:14] <danilos> haha, ok, fair enough, I'll ping when I am back and well fed then :)
[14:14] <gary_poster> :-) ok cool
[14:47] <danilos> gary_poster, ok, back
[14:47] <gary_poster> danilos, k, lemme get my notes...
[14:48] <gary_poster> danilos, ready.  gimme a call when you are
[15:16] <bac> i see lp2kanban is ignoring bug 788685 -- i wonder if it is confused by all the different bug tasks
[15:16] <_mup_> Bug #788685: Enable translating selected Ubuntu universe packages in Launchpad <escalated> <oem-services> <Launchpad itself:In Progress by bac> <OEM Priority Project:Invalid> <Ubuntu Translations:Triaged> <pkgbinarymangler (Ubuntu):Fix Released by pitti> < https://launchpad.net/bugs/788685 >
[15:20] <benji> away
[15:20] <benji> ...for lunch
[15:21] <gary_poster> bac, yeah
[15:21] <gary_poster> I made a card with that guess in Tasks
[15:21] <gary_poster> red one
[15:21] <gary_poster> we've had another one like it
[15:21] <bac> didn't see that
[15:21] <danilos> yay, good news, my apartment seems flooded, heading home :/
[15:22] <gary_poster> !!! :-(
[15:22] <gary_poster> good luck
[15:56] <danilo_> just to report back: nothing too bad, only the bathroom slightly flooded, but water noticed by the floor-below neighbours who nicely phoned me at the sight of first drops
[15:56] <danilo_> (water probably going by the heating/water pipes)
[16:05] <benji> I'm glad it's not too bad.  I know from personal experience how bad that can be.
[16:07] <gary_poster> I'm glad danilo
[16:18] <gary_poster> lunxh
[16:18] <gary_poster> lunch
[18:30] <bac> gary_poster: chat?
[18:31] <gary_poster> bac, sure
[20:00] <gary_poster> benji, gimme a call when you are ready
[20:00] <benji> calling


[06:55] <mup> PR snapd#12918 closed: many: stop using `-O no-expr-simplify` in apparmor_parser <Run nested> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12918>
[10:08] <mup> PR pc-gadget#95 closed: gadget: remove the gap in the middle <Created by dbungert> <Merged by alfonsosanchezbeato> <https://github.com/snapcore/pc-gadget/pull/95>
[10:46] <mup> PR snapd#12926 opened: o/snapstate: continue inhibitted refresh manually <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12926>
[10:51] <mup> PR snapd#12927 opened: Added read access to proc/task/schedstat <Created by Mehdi-Bendriss> <https://github.com/snapcore/snapd/pull/12927>
[13:02] <mup> PR snapd#12926 closed: o/snapstate: continue inhibitted refresh manually <Created by MiguelPires> <Closed by MiguelPires> <https://github.com/snapcore/snapd/pull/12926>
[14:43] <mup> PR snapd#12928 opened: o/snapstate: continue inhibited auto-refresh w/ refresh-candidates <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12928>
[14:44] <mup> Issue snapcraft#4236 opened: lxd-type-base spread test frequently times out <Bug> <Created by lengau> <https://github.com/snapcore/snapcraft/issues/4236>
[14:49] <mup> Issue snapcraft#4237 opened: colcon-ros2-hello spread test is flaky <Bug> <Created by lengau> <https://github.com/snapcore/snapcraft/issues/4237>
[15:04] <mup> PR snapcraft#4039 closed: [EXPERIMENTAL] packaging: update snap base to core22 <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/4039>
[16:14] <mup> PR snapcraft#4233 closed: type: workaround for pyright bug <Created by lengau> <Merged by lengau> <https://github.com/snapcore/snapcraft/pull/4233>
[19:04] <mup> Issue snapcraft#4238 opened: Metadata links are ignored in core22 snaps <Bug> <Created by maxiberta> <https://github.com/snapcore/snapcraft/issues/4238>
[22:39] <mup> PR snapcraft#4239 opened: spread: improve resilience of lxd-type-base test <Created by lengau> <https://github.com/snapcore/snapcraft/pull/4239>
[23:45] <mup> PR snapcraft#4240 opened: tox: exclude submodules from spread-shellcheck <Created by lengau> <https://github.com/snapcore/snapcraft/pull/4240>