=== mfo_ is now known as mfo
[08:34] -queuebot:#ubuntu-release- Unapproved: bcmwl (focal-proposed/restricted) [6.30.223.271+bdcom-0ubuntu7~20.04.2 => 6.30.223.271+bdcom-0ubuntu7~20.04.3] (kernel-dkms, ubuntu-desktop) (sync)
[08:52] -queuebot:#ubuntu-release- Unapproved: libmbim (focal-proposed/main) [1.22.0-2 => 1.24.8-1~20.04] (desktop-core, i386-whitelist)
[08:53] -queuebot:#ubuntu-release- Unapproved: rejected libmbim [source] (focal-proposed) [1.24.8-1~20.04]
[09:09] -queuebot:#ubuntu-release- Unapproved: rtl8812au (focal-proposed/universe) [4.3.8.12175.20140902+dfsg-0ubuntu13~20.04.2 => 4.3.8.12175.20140902+dfsg-0ubuntu13~20.04.3] (kernel-dkms) (sync)
[09:15] -queuebot:#ubuntu-release- New binary: s390-tools [s390x] (impish-proposed/main) [2.17.0-0ubuntu1] (core)
[11:22] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-gendry-meta to canonical-oem-metapackages in bionic
[11:22] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-gendry-meta to canonical-oem-metapackages in focal
[12:05] <juliank> laney: So the image building on multiple workers, to coordinate which worker is building; we can implement a locking and notification approach using 2 amqp queues.
[12:06] <juliank> laney: So the way it works, is that we use a single active consumer queue: https://www.rabbitmq.com/consumers.html#single-active-consumer
[12:06] <juliank> So while building the image, we need to read from that queue essentially, the queue acts as a mutex, but we don't put anything in it
[12:07] <juliank> Once we are done building the image, we stop the consumer, and then another worker's image building script would start
[12:07] <juliank> ok, that's only one queue actually .D
[12:08] <juliank> or do I have to push there?
[12:09] <juliank> in any case, I could publish to the queue first, then try to read my own message from it -> if that succeeded, I am the active worker
[12:10] <juliank> I must only ack one message, because other workers might have published to it too (they'll get their chance to read when we stop)
[12:11] <juliank> the implementation sucks
[12:11] <juliank> because it can only build an image at a time with one queue
[12:11] <juliank> we need one queue per (release, arch) pair ...
[12:12] <juliank> Or we build another service ensure-image-building-lock that acquires a lock and stays active while image building services run
[12:12] <juliank> Then one worker can build all cloud images in parallel, and the other can do nothing
[12:16] <juliank> But a lot of queues would work best
[12:20] <doko> apw, sforshee, xnox: is there any way to see which upstream version the linux package is based on?
[12:20] <apw> doko, if you are running it?  /proc/version_signature has the full upstream version
[12:21] <apw> doko, for general inquiries we also have: https://people.canonical.com/~kernel/info/kernel-version-map.txt though impish is missing for some reason
[12:22] <doko> apw, no, just looking at the package
[12:23] <apw> doko, with like apt-cache ... likely no
[12:23] <doko> apw, could you add that information to the changlog, when you're uploading?
[12:23] <apw> doko, i guess it would be reasonably easy to do... what is going to consume it?
[12:24] <apw> doko, are you interested in when it changes?
[12:24] <doko> just *knowing* which upstream version is used
[12:24] <apw> it feels like it should be in the package description for "something"
[12:25] <doko> or even better, a linux-libc-dev with a real upstream version in the package version
[12:26] <apw> we have always avoided having the third digit so we don't explode the librarian with new orig files all the time
[12:26] <apw> perhaps we could put somehting on that linux-libc-dev though with the upstream version in it
[12:27] <apw> if that would make life easier for you?
[12:27] <doko> documenting it in the changelog would be ok as well, assuming that you can parse that kind of information
[12:28] <apw> are you intending to consume it as a human, or scripted
[12:28] <doko> yes, or have a different binary version for every binary package built
[12:28] <doko> human
[12:28] <apw> i almost want to put a versioned provides on it
[12:29] <apw> then if something ever did care it could actually do something about it
[12:29] <juliank> Time to rewrite build-adt-image in python :)
[12:29] <doko> and what would be the package that you provide?
[12:29] <apw> linux-libc-dev-mainline (= foo) perhaps
[12:30] <cjwatson> apw: TBH I wonder whether the "avoid new orig files" is still the right tradeoff.  The size of a linux orig tarball looks rather less significant now than it did when we started this practice
[12:31] <juliank> But kernels are not rebased upon point release right now, so that's a ton of extra work, presumably?
[12:33] <apw> cjwatson, we would provide a new .orig for every single SRU cycle in the normal run of things, for every single kernel.  so 180M for each of 82 kernels.
[12:33] <apw> which by my calculation is 14TB every 3 weeks?
[12:33] <cjwatson> Hm yeah, I suppose ...
[12:34] <cjwatson> I always forget what an absurdly enormous number of kernels you have
[12:34] <apw> or are you able to collesce the orig by contents?  as there is more like only 4 for every cycle.
[12:34] <cjwatson> No
[12:34] <cjwatson> Well maybe if they're actually bitwise-identical
[12:34] <apw> they are bitwise identicle
[12:35] <apw> i assume you _arn't_ currently sharing the bits, but you might be able to?
[12:35] <cjwatson> I think we are actually
[12:35] <cjwatson> But I'll check after this meeting
[12:35] <apw> ack and thanks
[12:42] <cjwatson> apw: Oh right, yeah, they get temporarily added as duplicates and then librarian-gc deduplicates them
[12:43] <doko> so the space usage wouldn't be an issue in the end?
[12:47] <cjwatson> So it'd still be a TB a month or so, which isn't entirely insignificant
[12:48] <cjwatson> Maybe better not change it until the librarian is on PS5 and we get a feel for what space usage looks like there
[12:49] <cjwatson> Actually no, neither apw nor I can multiply apparently
[12:49] <cjwatson> 180M * 82 is 14G not 14T
[12:49] <doko> ;p
[12:50] <cjwatson> That makes rather more sense, I was wondering how you'd manage to generate like a sixth of the librarian's total storage size in three weeks
[12:51] <cjwatson> So <1G extra per three weeks is noise and will not really be noticed from our point of view.  I can't speak to whatever extra rebase work it might require of course.
[12:53] <cjwatson> And of course it would presumably require some tooling changes.  I do think it would be ultimately the right thing to do though.
[13:32] -queuebot:#ubuntu-release- New: accepted ruby-js-image-paths [amd64] (impish-proposed) [0.1.1-2]
[13:41] -queuebot:#ubuntu-release- Unapproved: dwarves-dfsg (focal-proposed/universe) [1.15-2 => 1.21-0ubuntu1~ubuntu20.04.1] (no packageset) (sync)
[13:41] -queuebot:#ubuntu-release- Unapproved: libbpf (groovy-proposed/universe) [0.1.0-1 => 0.4.0-1ubuntu1~ubuntu20.10.1] (kubuntu) (sync)
[13:41] -queuebot:#ubuntu-release- Unapproved: libbpf (hirsute-proposed/main) [0.3-2ubuntu1 => 0.4.0-1ubuntu1~ubuntu21.04.1] (core, i386-whitelist) (sync)
[13:41] -queuebot:#ubuntu-release- Unapproved: dwarves-dfsg (groovy-proposed/universe) [1.17-1 => 1.21-0ubuntu1~ubuntu20.10.1] (no packageset) (sync)
[13:41] -queuebot:#ubuntu-release- New sync: libbpf (focal-proposed/primary) [0.4.0-1ubuntu1~ubuntu20.04.1]
[13:41] -queuebot:#ubuntu-release- Unapproved: dwarves-dfsg (hirsute-proposed/universe) [1.20-1 => 1.21-0ubuntu1~ubuntu21.04.1] (no packageset) (sync)
[14:06] <laney> juliank: sorry your pings scrolled off the top, my highlighting is broken somehow
[14:06] <laney> I did a mutex type thing for the /running page the other week
[14:07] <juliank> laney: I implemented a locking class now: https://paste.ubuntu.com/p/Z5bhK8ZxxW/ :D
[14:07] <juliank> laney: Oh, did I do extra effort?
[14:08] <laney> cache-amqp
[14:08] <laney> well, you can port that to your shiny thing?
[14:08] <laney> https://git.launchpad.net/autopkgtest-cloud/commit/?id=13b54e7baa95ab62f8431a03be288596ea46cc99
[14:08] <ubottu> Commit 13b54e7 in autopkgtest-cloud "web: Make cache-amqp not fight with concurrent instances"
[14:09] <laney> yours is sleepless so nicer
[14:09] <laney> assuming it works
[14:09] <juliank> laney: It does work AFAICT
[14:10] <juliank> laney: Probably should bind this to a new exchange?
[14:10] <laney> I guess so
[14:10] <juliank> This requires rabbitmq 3.8, which luckily we have :)
[14:11] <juliank> And yes, this rabbitmq extension was designed to avoid the need for polling
[14:15] <juliank> laney: Next step essentially is to rewrite build-adt-image in python and then just have to integrate the class
[14:16] <juliank> laney: That might be all that's needed for multiple workers (I already have the "delete only our own instances" in the branch)
[14:16] <juliank> Unless you can think of other stuff
[14:18] <juliank> I'll probably rewrite the context manager a bit, maybe using contextlib decorator instead of class it's a bit unwieldy right now
[14:18] <laney> charm work to distribute the nodes
[14:18] <laney> workers*
[14:18] <juliank> oh that
[14:18] <juliank> ack
[14:18]  * juliank adds to checklist
[14:20] <laney> 👍
[14:20] <laney> we'll need a logging stack after this!
[14:20] <laney> going en ter prise
[14:21] <juliank> Waiting for ACaaS
[14:22] <bdmurray> laney, juliank: could one of you merge https://code.launchpad.net/~juergh/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/405620 ?
[15:15] <jawn-smith> sil2100: can we turn on daily image builds for focal on the unmatched?
[15:15] <jawn-smith> while it doesn't have the kernel updates yet, it should boot in qemu
[15:16] <jawn-smith> I built an image with -proposed enabled to verify that
[15:16] <laney> bdmurray: yeah
[15:17] <laney> I wonder why Juerg was looking at that 😳
[15:17] <laney> but GREAT, I knew we had a zombie case somewhere but didn't find it
[15:31] <bdmurray> laney: Thanks
[15:32] <juergh> laney, coz I tried to create an ADT base image in canonistack to reproduce an ADT kernel test problem but failed miserably.
[15:38] <laney> ah
[15:38] <laney> glance (the image service) in Canonistack has been pretty flaky lately
[15:38] <laney> so not surprised if you hit the retry cases there
[15:38] <juergh> so I've noticed...
[16:25] -queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (focal-proposed) [2.1-2~ubuntu20.04.1]
[16:31] -queuebot:#ubuntu-release- Unapproved: accepted libmbim [source] (focal-proposed) [1.24.8-1~20.04]
[16:41] -queuebot:#ubuntu-release- New binary: libmbim [arm64] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist)
[16:41] -queuebot:#ubuntu-release- New binary: libmbim [ppc64el] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist)
[16:41] -queuebot:#ubuntu-release- New binary: libmbim [i386] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist)
[16:41] -queuebot:#ubuntu-release- New binary: libmbim [s390x] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist)
[16:43] -queuebot:#ubuntu-release- New binary: libmbim [armhf] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist)
[16:43] -queuebot:#ubuntu-release- New binary: libmbim [amd64] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist)
[17:04] -queuebot:#ubuntu-release- New binary: libmbim [riscv64] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist)
=== blackboxsw_ is now known as blackboxsw
[17:18] -queuebot:#ubuntu-release- Unapproved: libqmi (focal-proposed/main) [1.24.8-1 => 1.28.6-1~20.04] (desktop-core, i386-whitelist)
[17:29] -queuebot:#ubuntu-release- Unapproved: rejected libqmi [source] (focal-proposed) [1.28.6-1~20.04]
[17:34] -queuebot:#ubuntu-release- New binary: ceph [amd64] (impish-proposed/main) [16.2.5-0ubuntu2] (ubuntu-desktop, ubuntu-server)
[17:41] -queuebot:#ubuntu-release- Unapproved: accepted libqmi [source] (focal-proposed) [1.28.6-1~20.04]
[17:55] -queuebot:#ubuntu-release- New binary: libqmi [amd64] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist)
[17:55] -queuebot:#ubuntu-release- New binary: libqmi [i386] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist)
[17:55] -queuebot:#ubuntu-release- New binary: libqmi [s390x] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist)
[17:55] -queuebot:#ubuntu-release- New binary: libqmi [armhf] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist)
[17:55] -queuebot:#ubuntu-release- New binary: libqmi [ppc64el] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist)
[17:57] -queuebot:#ubuntu-release- New binary: libqmi [arm64] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist)
[18:20] -queuebot:#ubuntu-release- New binary: libqmi [riscv64] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist)
[19:14] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (hirsute-proposed/main) [27.1~21.04.1 => 27.2~21.04.1] (core)
[19:14] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [27.1~20.04.1 => 27.2~20.04.1] (core)
[19:15] <blackboxsw> woot! thanks sergiodj loooking like you are uploading into -proposed for us to start testing. Thanks for the sponsorship
[19:15] <blackboxsw> and thx athos for reviews as well on these PRs
[19:16] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.1~18.04.1 => 27.2~18.04.1] (core)
[19:18] <sergiodj> blackboxsw: +1, my pleasure!  and this was mostly athos' effort, I just uploaded the packages :-P
[19:18] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (xenial-proposed/main) [27.1~16.04.1 => 27.2~16.04.1] (no packageset)
[19:23] <athos> thanks, sergiodj :)
[19:37] <bdmurray> blackboxsw: Is it important to get the xenial one in before the archive closes?
[19:54] <blackboxsw> bdmurray: if the archive closes on Xenial, that would indicate to us that we need to use ESM ppas and the security team for delivering this upload to their PPAs. I think our plan was continue to use Xenial as long as it is considered "allowed" and then once not possible, we'd move to running through security team uploads to ESM-infra PPAs
[19:55] <blackboxsw> since esm-infra needs to be active/enabled for "support" on Xenial, it works for us if we are directed to work with the security team and esm-infra PPAs for uploading Xenial from here on forward.
[19:56] <bdmurray> I thought I'd heard something about an important change in the next version of u-a-t which needed to be in xenial but I could be remembering wrong.
[20:15] <blackboxsw> bdmurray, you remember correctly. There is one ESM-related feature that is waiting in the wings that we were hoping to get into xenial-updates. That feature is still in beta and driven by Lech. We've pinged to sort expectation from him on when that should be solid as it only involves a small change to ua-tools to "enable" it.
[20:18] <bdmurray> blackboxsw: Okay, so this isn't that upload but you'd still like it reviewed posthaste - correct?
[20:19] <blackboxsw> bdmurray: was just typing basically a pleasant request for review. If there is a possibility to review this upload it's a minor point release that does have some significant benefit for FIPS customers and any customers that have proxy configuration needs.
[20:20] <blackboxsw> if xenial is not an option, we can sort that with security team internally, but ultimately version 28.0 would be the esm feature
[20:20] <blackboxsw> that you made allusions to.
[21:38] <blackboxsw> bdmurray: I'm not sure really what to do here with the software-properties-gtk SRU. I know there is a better/cleaner way to do this, but I'm not sure if we should have them address that in a followup iteration for their work or not. https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1920836
[21:38] <ubottu> Launchpad bug 1920836 in software-properties (Ubuntu Xenial) "Show Extended Security Maintenence status" [Undecided, New]
[21:39] <blackboxsw> patch suggested there that will mitigate the SRU verification concerns that were posted..... but not sure if I want to send them back to the drawing board on better handling of ua status output until next SRU. I've pinged Robert on that to see what he things
[21:39] <blackboxsw> thinks
[21:45] <bdmurray> I don't think many people run software-properties-gtk from the terminal so the messages wouldn't be seen, but the extra time isn't great.
[21:47] <blackboxsw> ack. maybe worth a rejection there and get an upload into impish that doesn't call `ua status` given that the default case on most systems it doesn't provide value when running as non-root.
[22:25] <blackboxsw> bdmurray: did your former conversation on ubuntu-advantage-tools mean you were looking over the ua-tools SRU ? Or should I ping sil-2100 for tomorrow's SRU rotation
[22:28] <bdmurray> blackboxsw: I don't think I'm going to get to it today so ping that other person ;-)
[23:12] <blackboxsw> thanks bdmurray!
[23:14] <blackboxsw> sil2100: for tomorrow, we have an ubuntu-advantage-tools SRU queued for review to get into the -proposed pockets for X, B, F and H per LP: #1934902
[23:14] <ubottu> Launchpad bug 1934902 in ubuntu-advantage-tools (Ubuntu Impish) "[SRU] ubuntu-advantage-tools (27.1 -> 27.2) Xenial, Bionic, Focal, Hirsute" [Undecided, New] https://launchpad.net/bugs/1934902
[23:49] <sil2100> blackboxsw: o/