| === mfo_ is now known as mfo | ||
| -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:34 | |
| -queuebot:#ubuntu-release- Unapproved: libmbim (focal-proposed/main) [1.22.0-2 => 1.24.8-1~20.04] (desktop-core, i386-whitelist) | 08:52 | |
| -queuebot:#ubuntu-release- Unapproved: rejected libmbim [source] (focal-proposed) [1.24.8-1~20.04] | 08:53 | |
| -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:09 | |
| -queuebot:#ubuntu-release- New binary: s390-tools [s390x] (impish-proposed/main) [2.17.0-0ubuntu1] (core) | 09:15 | |
| -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 | 11:22 | |
| 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:05 |
|---|---|---|
| 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:06 |
| 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:07 |
| juliank | or do I have to push there? | 12:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| juliank | But a lot of queues would work best | 12:16 |
| 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:20 |
| 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:21 |
| doko | apw, no, just looking at the package | 12:22 |
| 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:23 |
| 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:24 |
| doko | or even better, a linux-libc-dev with a real upstream version in the package version | 12:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| juliank | But kernels are not rebased upon point release right now, so that's a ton of extra work, presumably? | 12:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| cjwatson | apw: Oh right, yeah, they get temporarily added as duplicates and then librarian-gc deduplicates them | 12:42 |
| doko | so the space usage wouldn't be an issue in the end? | 12:43 |
| cjwatson | So it'd still be a TB a month or so, which isn't entirely insignificant | 12:47 |
| 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:48 |
| cjwatson | Actually no, neither apw nor I can multiply apparently | 12:49 |
| cjwatson | 180M * 82 is 14G not 14T | 12:49 |
| doko | ;p | 12:49 |
| 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:50 |
| 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:51 |
| cjwatson | And of course it would presumably require some tooling changes. I do think it would be ultimately the right thing to do though. | 12:53 |
| -queuebot:#ubuntu-release- New: accepted ruby-js-image-paths [amd64] (impish-proposed) [0.1.1-2] | 13:32 | |
| -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) | 13:41 | |
| 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:06 |
| 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:07 |
| 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:08 |
| laney | yours is sleepless so nicer | 14:09 |
| laney | assuming it works | 14:09 |
| juliank | laney: It does work AFAICT | 14:09 |
| 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:10 |
| juliank | And yes, this rabbitmq extension was designed to avoid the need for polling | 14:11 |
| juliank | laney: Next step essentially is to rewrite build-adt-image in python and then just have to integrate the class | 14:15 |
| 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:16 |
| 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:18 | |
| laney | 👍 | 14:20 |
| laney | we'll need a logging stack after this! | 14:20 |
| laney | going en ter prise | 14:20 |
| juliank | Waiting for ACaaS | 14:21 |
| bdmurray | laney, juliank: could one of you merge https://code.launchpad.net/~juergh/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/405620 ? | 14:22 |
| 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:15 |
| jawn-smith | I built an image with -proposed enabled to verify that | 15:16 |
| laney | bdmurray: yeah | 15:16 |
| 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:17 |
| bdmurray | laney: Thanks | 15:31 |
| juergh | laney, coz I tried to create an ADT base image in canonistack to reproduce an ADT kernel test problem but failed miserably. | 15:32 |
| 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... | 15:38 |
| -queuebot:#ubuntu-release- Unapproved: accepted networkd-dispatcher [source] (focal-proposed) [2.1-2~ubuntu20.04.1] | 16:25 | |
| -queuebot:#ubuntu-release- Unapproved: accepted libmbim [source] (focal-proposed) [1.24.8-1~20.04] | 16:31 | |
| -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:41 | |
| -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) | 16:43 | |
| -queuebot:#ubuntu-release- New binary: libmbim [riscv64] (focal-proposed/main) [1.24.8-1~20.04] (desktop-core, i386-whitelist) | 17:04 | |
| === blackboxsw_ is now known as blackboxsw | ||
| -queuebot:#ubuntu-release- Unapproved: libqmi (focal-proposed/main) [1.24.8-1 => 1.28.6-1~20.04] (desktop-core, i386-whitelist) | 17:18 | |
| -queuebot:#ubuntu-release- Unapproved: rejected libqmi [source] (focal-proposed) [1.28.6-1~20.04] | 17:29 | |
| -queuebot:#ubuntu-release- New binary: ceph [amd64] (impish-proposed/main) [16.2.5-0ubuntu2] (ubuntu-desktop, ubuntu-server) | 17:34 | |
| -queuebot:#ubuntu-release- Unapproved: accepted libqmi [source] (focal-proposed) [1.28.6-1~20.04] | 17:41 | |
| -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:55 | |
| -queuebot:#ubuntu-release- New binary: libqmi [arm64] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist) | 17:57 | |
| -queuebot:#ubuntu-release- New binary: libqmi [riscv64] (focal-proposed/main) [1.28.6-1~20.04] (desktop-core, i386-whitelist) | 18:20 | |
| -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:14 | |
| 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:15 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.1~18.04.1 => 27.2~18.04.1] (core) | 19:16 | |
| 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:18 | |
| athos | thanks, sergiodj :) | 19:23 |
| bdmurray | blackboxsw: Is it important to get the xenial one in before the archive closes? | 19:37 |
| 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:54 |
| 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:55 |
| 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. | 19:56 |
| 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:15 |
| bdmurray | blackboxsw: Okay, so this isn't that upload but you'd still like it reviewed posthaste - correct? | 20:18 |
| 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:19 |
| 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. | 20:20 |
| 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:38 |
| 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:39 |
| 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:45 |
| 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. | 21:47 |
| 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:25 |
| bdmurray | blackboxsw: I don't think I'm going to get to it today so ping that other person ;-) | 22:28 |
| blackboxsw | thanks bdmurray! | 23:12 |
| 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:14 |
| sil2100 | blackboxsw: o/ | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!