[00:08] <bdmurray> dude why is q2-phylogeny in the queue 24 times?
[00:09] <jbicha> bdmurray: see https://autopkgtest.ubuntu.com/packages/lib/libreoffice/jammy/amd64 for another example
[00:10] <bdmurray> I'd seen that yesterday when looking at things
[00:10] <bdmurray> Thanks though!
[00:17] <bdmurray> cleared and requeued
=== tomreyn_ is now known as tomreyn
[01:19] <vorlon> 678 tests in the queue with dkms as a trigger, that's... a lot more than britney needs
[01:20] <vorlon> dumping them all and requeuing the subset based on retry-autopkgtest-regressions --blocks dkms --state RUNNING
[01:21] <arraybolt3> vorlon: This is probably a silly question, but how much RAM does the machine that Britney runs on have? I know that SQLite is a bottleneck and might want to try to help optimize it by just loading the whole DB into RAM and depending on that at runtime, but I don't know how practical that is.
[01:21]  * arraybolt3 probably should have asked this in -devel
[01:23] <vorlon> arraybolt3: why do you believe sqlite is a bottleneck?
[01:23] <arraybolt3> vorlon: I thought that's what you and tsimonq2 had concluded, that part of the reason Britney runs were slow was because it was having to do SQLite lookups and that it was a bottleneck.
[01:24] <arraybolt3> Perhaps I misunderstood what I was reading.
[01:25] <vorlon> having to do a query for each requested test for which there is not yet a successful result is time-consuming.  But I have nothing to indicate that this is slow because of I/O
[01:26] <vorlon> it might be - but otoh what do you propose wrt "loading the whole DB into RAM"? this is the sort of thing that ought to be abstracted by the library
[01:26] <arraybolt3> Ah, see I was thinking that if it was loaded into RAM the data could be manipulated without needing SQL involved and that doing so might speed things up, and wanted to try it out, but didn't want to do that if it was going to be destined to fail anyway.
[01:26] <arraybolt3> vorlon: I have no clue about anything tangible right now, this was mostly me wondering if something was even possible before investigating how to do it.
[01:26] <arraybolt3> (Why waste dev time on something useless when you can ask and find out what's possible and a good idea first.)
[01:29] <arraybolt3> Anyway, I can already see something probably wrong with my idea in retrospect, so I'll just test stuff locally in the future and ask questions later.
[01:30] <vorlon> arraybolt3: IMHO any attempt to optimize the sqlite access would be premature optimization at this point.  britney needs to be moved off the current hardware (because it's in a DC that's being shut down) and the next machine will be beefier
[01:31] <arraybolt3> Makes sense.
[01:31] <vorlon> the Linux kernel is also quite good about using free RAM for disk cache so it would be difficult to improve on that I/O performance by pinning stuff in RAM
[01:31] <arraybolt3> It was more about bypassing SQL than about optimizing speed access, otherwise we'd have just moved things into /dev/shm long ago :P
[01:31] <arraybolt3> *disk access speed
[01:33] <vorlon> though one thing that does make me realize, is that we run britney for multiple series in parallel and each has its own copy of autopkgtest.db in local state, which reduces the kernel's efficiency in doing disk caching
[01:33] <vorlon> so adding some logic to deduplicate that could actually improve performance
[01:33] <sarnold> sqlite's crazy good at this though :) https://www.sqlite.org/np1queryprob.html
[01:33] <sarnold> (not magic deduplication, just running sql queries)
[01:33] <vorlon> right, exactly
[01:34] <arraybolt3> Well hey, maybe my silly suggestion was actually good for something :D
[01:35] <vorlon> still, something to try only after we move to the newer hardware :)
[01:36] <vorlon> (which I had originally planned to get done over the holidays, but ran into some firewall regressions)
[01:37] <vorlon> (and then I was waiting for big transitions to be done, but there hasn't been a gap)
[01:40] <vorlon> xnox: so, the non-huge queues are draining quickly (only amd64 and arm64 still have any backlog) and I've rescheduled those tests that actually block dkms migration into the short queue
[02:04] <vorlon> juliank, chrisccoulson_: I have in my notes for this morning that we want grub in jammy-security before releasing shim to jammy-updates but I didn't record a reason for this (and it's not yet done).  shim is in jammy-updates anyway right now
[02:09] <vorlon> juliank, chrisccoulson_: I think I just wrote this wrong because there's another line in the notes below about publication to jammy-security so I'm revising
=== chris14_ is now known as chris14
[04:31] -queuebot:#ubuntu-release- New binary: gcc-13-cross-ports [ppc64el] (lunar-proposed/universe) [3ubuntu1] (i386-whitelist)
[06:25] -queuebot:#ubuntu-release- New source: gcc-13-cross (lunar-proposed/primary) [3ubuntu1]
[06:28] -queuebot:#ubuntu-release- New: accepted gcc-13-cross [source] (lunar-proposed) [3ubuntu1]
[06:28] -queuebot:#ubuntu-release- New: accepted kodi-game-libretro [arm64] (lunar-proposed) [20.2.2-2]
[06:28] -queuebot:#ubuntu-release- New: accepted kodi-game-libretro [ppc64el] (lunar-proposed) [20.2.2-2]
[06:28] -queuebot:#ubuntu-release- New: accepted kodi-game-libretro [s390x] (lunar-proposed) [20.2.2-2]
[06:28] -queuebot:#ubuntu-release- New: accepted mosdepth [arm64] (lunar-proposed) [0.3.3+ds-2]
[06:28] -queuebot:#ubuntu-release- New: accepted mosdepth [ppc64el] (lunar-proposed) [0.3.3+ds-2]
[06:28] -queuebot:#ubuntu-release- New: accepted kodi-game-libretro [amd64] (lunar-proposed) [20.2.2-2]
[06:28] -queuebot:#ubuntu-release- New: accepted kodi-game-libretro [riscv64] (lunar-proposed) [20.2.2-2]
[06:28] -queuebot:#ubuntu-release- New: accepted mosdepth [armhf] (lunar-proposed) [0.3.3+ds-2]
[06:28] -queuebot:#ubuntu-release- New: accepted kodi-game-libretro [armhf] (lunar-proposed) [20.2.2-2]
[06:28] -queuebot:#ubuntu-release- New: accepted mosdepth [riscv64] (lunar-proposed) [0.3.3+ds-2]
[06:28] -queuebot:#ubuntu-release- New: accepted mosdepth [amd64] (lunar-proposed) [0.3.3+ds-2]
[06:40] <doko> LocutusOfBorg: no, python3.10 needs removal
[06:47] -queuebot:#ubuntu-release- New binary: gcc-13-cross-ports [arm64] (lunar-proposed/universe) [3ubuntu1] (i386-whitelist)
[07:18] -queuebot:#ubuntu-release- New: accepted gnome-shell-extension-tiling-assistant [source] (lunar-proposed) [39-1ubuntu1]
[07:18] <juliank> vorlon: the thing is the ubuntu14 grub didn't fully phase so copying it to security at 58% phasing is um suboptimal?
[07:19] <juliank> But it would have been nice in general to get the security fixes to security without the mm stuff
[07:20] -queuebot:#ubuntu-release- New binary: gnome-shell-extension-tiling-assistant [amd64] (lunar-proposed/none) [39-1ubuntu1] (no packageset)
[07:21] <juliank> But that's grub updates only, I didn't have ordering requirements for shim.
[07:22] -queuebot:#ubuntu-release- New: accepted gnome-shell-extension-tiling-assistant [amd64] (lunar-proposed) [39-1ubuntu1]
[08:06] -queuebot:#ubuntu-release- New binary: gcc-13-cross-ports [i386] (lunar-proposed/universe) [3ubuntu1] (i386-whitelist)
[08:11] -queuebot:#ubuntu-release- New binary: gcc-13-cross-ports [amd64] (lunar-proposed/universe) [3ubuntu1] (i386-whitelist)
[08:52] -queuebot:#ubuntu-release- New: accepted gcc-13-cross-ports [amd64] (lunar-proposed) [3ubuntu1]
[08:53] -queuebot:#ubuntu-release- New: accepted gcc-13-cross-ports [i386] (lunar-proposed) [3ubuntu1]
[08:53] -queuebot:#ubuntu-release- New: accepted gcc-13-cross-ports [arm64] (lunar-proposed) [3ubuntu1]
[08:53] -queuebot:#ubuntu-release- New: accepted gcc-13-cross-ports [ppc64el] (lunar-proposed) [3ubuntu1]
[09:17] -queuebot:#ubuntu-release- New binary: bcbio [amd64] (lunar-proposed/multiverse) [1.2.9-2] (no packageset)
[09:52] <LocutusOfBorg> vorlon, do you have any time to badtest dkms tests on i386?
[09:54] <LocutusOfBorg> e.g. acpi-call, dahdi-linux, ddcci-driver-linux, linux-apfs-rw, nvidia-graphics-drivers-390, openafs, openrazer, openvpn-dco-dkms, rapiddisk, rtl8812au, rtpengine, sl-modem, v4l2loopback, west-chamber, xtables-addons, xtrx-dkms
[09:57] -queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (kinetic-proposed) [2.5.1-1ubuntu1]
[09:59] -queuebot:#ubuntu-release- Unapproved: accepted py-macaroon-bakery [source] (kinetic-proposed) [1.3.1-3ubuntu0.1]
[10:00] -queuebot:#ubuntu-release- Unapproved: accepted py-macaroon-bakery [source] (jammy-proposed) [1.3.1-2ubuntu0.1]
[10:03] -queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (kinetic-proposed) [2.13.8-1~ubuntu22.10.0]
[10:09] -queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (jammy-proposed) [2.13.8-1~ubuntu22.04.0]
[10:10] -queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (bionic-proposed) [2.10.8-1ubuntu2~18.04.5]
[10:15] -queuebot:#ubuntu-release- Unapproved: python-libmaas (jammy-proposed/universe) [0.6.4-0ubuntu1 => 0.6.8-0ubuntu0.22.04.1] (no packageset)
[10:15] -queuebot:#ubuntu-release- Unapproved: python-libmaas (kinetic-proposed/universe) [0.6.4-0ubuntu1 => 0.6.8-0ubuntu0.22.10.1] (no packageset)
[11:36] <utkarsh2102> in livecd-rootfs, I see: minimal_packages_url=${SEEDMIRROR}/${SEED}/${BASE_SEED}.minimal-remove
[11:37] <utkarsh2102> but can't find anything here: https://people.canonical.com/~ubuntu-archive/seeds/ubuntu.lunar/
[11:37] <utkarsh2102> sil2100: perhaps you'd know?
[11:37] <utkarsh2102> where can I find that *minimal-remove file?
[11:38] <seb128> utkarsh2102, which iso flavor are you poking at?
[11:39] <sil2100> utkarsh2102: I see the desktop minimal-remove file there
[11:39] <seb128> utkarsh2102, in that directory there is a desktop.minimal-remove
[11:39] <sil2100> Do you look for something else?
[11:39] <utkarsh2102> sil2100: I was looking for server.minimal-remove
[11:40] <seb128> is server having a minimal install option?
[11:40] <utkarsh2102> seb128: hey! I am looking at https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config?h=2.799#n1082
[11:40] <utkarsh2102> isn't there server-minimal?
[11:41] <utkarsh2102> for images on the CPC side, we use "server" as the BASE_SEED; cf:  https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config?h=2.799#n1042
[11:42] <utkarsh2102> and then trim down things from there
[11:42] <sil2100> utkarsh2102: there is no minimal-remove for server for now
[11:42] <ahasenack> is the autopkgtest outage over? bdmurray's email wasn't clear on that
[11:42] <utkarsh2102> sil2100: so we don't remove anything at all is the BASE_SEED is server?
[11:42] <sil2100> utkarsh2102: for instance, if you look at our live server images build logs you can even see: "Checking http://archive-team.internal/seeds//ubuntu.lunar/server.minimal-remove for a minimal installation list... failed to retrieve, not including."
[11:43] <utkarsh2102> aha!
[11:43] <utkarsh2102> interesting, thanks!
[11:44] <seb128> utkarsh2102, you can check 3075d6557 but afaik that feature is specific to the old desktop installer
[11:45] <utkarsh2102> seb128: sweet, thanks!
[11:45] <seb128> np!
[11:53] -queuebot:#ubuntu-release- New binary: libcamera [amd64] (lunar-proposed/universe) [0.0.4-2ubuntu1] (i386-whitelist)
[11:53] -queuebot:#ubuntu-release- New binary: libcamera [i386] (lunar-proposed/universe) [0.0.4-2ubuntu1] (i386-whitelist)
[11:54] -queuebot:#ubuntu-release- New binary: libcamera [ppc64el] (lunar-proposed/universe) [0.0.4-2ubuntu1] (i386-whitelist)
[11:55] -queuebot:#ubuntu-release- New binary: libcamera [arm64] (lunar-proposed/universe) [0.0.4-2ubuntu1] (i386-whitelist)
[11:55] -queuebot:#ubuntu-release- New binary: libcamera [s390x] (lunar-proposed/universe) [0.0.4-2ubuntu1] (i386-whitelist)
[11:55] -queuebot:#ubuntu-release- New binary: libcamera [armhf] (lunar-proposed/universe) [0.0.4-2ubuntu1] (i386-whitelist)
[11:56] -queuebot:#ubuntu-release- New: accepted bcbio [amd64] (lunar-proposed) [1.2.9-2]
[12:01] -queuebot:#ubuntu-release- New binary: gcc-defaults [s390x] (lunar-proposed/main) [1.203ubuntu1] (core, i386-whitelist)
[12:03] -queuebot:#ubuntu-release- New binary: gcc-defaults [armhf] (lunar-proposed/main) [1.203ubuntu1] (core, i386-whitelist)
[12:03] -queuebot:#ubuntu-release- New binary: gcc-defaults [i386] (lunar-proposed/main) [1.203ubuntu1] (core, i386-whitelist)
[12:04] -queuebot:#ubuntu-release- New binary: gcc-defaults [amd64] (lunar-proposed/main) [1.203ubuntu1] (core, i386-whitelist)
[12:05] -queuebot:#ubuntu-release- New binary: gcc-defaults [arm64] (lunar-proposed/main) [1.203ubuntu1] (core, i386-whitelist)
[12:06] -queuebot:#ubuntu-release- New binary: gcc-defaults [ppc64el] (lunar-proposed/main) [1.203ubuntu1] (core, i386-whitelist)
[12:08] -queuebot:#ubuntu-release- New binary: gcc-13-cross [i386] (lunar-proposed/universe) [3ubuntu1] (i386-whitelist)
[12:09] -queuebot:#ubuntu-release- New binary: gcc-defaults-ports [amd64] (lunar-proposed/universe) [1.204ubuntu1] (i386-whitelist)
[12:09] -queuebot:#ubuntu-release- New binary: gcc-defaults-ports [i386] (lunar-proposed/universe) [1.204ubuntu1] (i386-whitelist)
[12:10] -queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [amd64] (lunar-proposed) [1.204ubuntu1]
[12:10] -queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [i386] (lunar-proposed) [1.204ubuntu1]
[12:17] -queuebot:#ubuntu-release- Unapproved: s390-tools (lunar-proposed/main) [2.25.0-0ubuntu1 => 2.26.0-0ubuntu1] (core)
[12:25] -queuebot:#ubuntu-release- New binary: gcc-defaults [riscv64] (lunar-proposed/main) [1.203ubuntu1] (core, i386-whitelist)
[12:26] -queuebot:#ubuntu-release- New: accepted gcc-defaults [amd64] (lunar-proposed) [1.203ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted gcc-defaults [armhf] (lunar-proposed) [1.203ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted gcc-defaults [ppc64el] (lunar-proposed) [1.203ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted gcc-defaults [s390x] (lunar-proposed) [1.203ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted gcc-defaults [arm64] (lunar-proposed) [1.203ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted gcc-defaults [riscv64] (lunar-proposed) [1.203ubuntu1]
[12:26] -queuebot:#ubuntu-release- New: accepted gcc-defaults [i386] (lunar-proposed) [1.203ubuntu1]
[12:50] <utkarsh2102> seb128, sil2100: yet another questions is -
[12:51] <utkarsh2102> add_task install cloud-image
[12:51] <utkarsh2102> what does it actually do and where does this "cloud-image" coming from?
[12:59] -queuebot:#ubuntu-release- New binary: libcamera [riscv64] (lunar-proposed/universe) [0.0.4-2ubuntu1] (i386-whitelist)
[13:16] -queuebot:#ubuntu-release- New: accepted libcamera [amd64] (lunar-proposed) [0.0.4-2ubuntu1]
[13:16] -queuebot:#ubuntu-release- New: accepted libcamera [armhf] (lunar-proposed) [0.0.4-2ubuntu1]
[13:16] -queuebot:#ubuntu-release- New: accepted libcamera [ppc64el] (lunar-proposed) [0.0.4-2ubuntu1]
[13:16] -queuebot:#ubuntu-release- New: accepted libcamera [s390x] (lunar-proposed) [0.0.4-2ubuntu1]
[13:16] -queuebot:#ubuntu-release- New: accepted libcamera [arm64] (lunar-proposed) [0.0.4-2ubuntu1]
[13:16] -queuebot:#ubuntu-release- New: accepted libcamera [riscv64] (lunar-proposed) [0.0.4-2ubuntu1]
[13:16] -queuebot:#ubuntu-release- New: accepted libcamera [i386] (lunar-proposed) [0.0.4-2ubuntu1]
[13:16] -queuebot:#ubuntu-release- New binary: gcc-13-cross [ppc64el] (lunar-proposed/universe) [3ubuntu1] (i386-whitelist)
[13:20] -queuebot:#ubuntu-release- New binary: gcc-13-cross [amd64] (lunar-proposed/universe) [3ubuntu1] (i386-whitelist)
[13:23] <sil2100> utkarsh2102: it basically instructs livecd-rootfs to install all packages that are grouped into the given task. Tasks come from seeds basically, if you check a seed you'll find the 'Task-Key:' there for instance, and listing all the packages and expressions that should be part of that task
[13:23] <utkarsh2102> sil2100: thanks, is there some documentation about "Tasks"?
[13:24] <utkarsh2102> and all the other different (but similar) headers on the seeds
[13:24] <sil2100> utkarsh2102: hm, not sure, they're a bit of a borrowed concept from Debian, so maybe they'd have some docs about those
[13:24] <sil2100> https://people.canonical.com/~ubuntu-archive/seeds/ubuntu.lunar/cloud-image
[13:25] <utkarsh2102> right, okay
[13:25] <utkarsh2102> what does "Task-Section" and "Task-Key" mean here, really?
[13:25] <sil2100> This is for instance what defines the cloud-image task
[13:26] <sil2100> Task-Key is the name of the task that this defines, Section I actually have no idea, I always considered that more of a organizational thing. I think it might not be relevant to Ubuntu
[13:26] <utkarsh2102> :P
[13:26] <utkarsh2102> got it!
[13:26] <utkarsh2102> last: when we say "Task-Key: cloud-init"
[13:27] <utkarsh2102> what are we trying to say?
[13:27] <utkarsh2102> do we really need a Task-Key?
[13:27] <utkarsh2102> since cloud-init is also mentioned below as a separate pacakge
[13:28] <utkarsh2102> and then what does "add_task install cloud-image" finally mean with that Task-Key set as cloud-init?
[13:45] <sil2100> Ok, I think I mixed up that a bit, actually looking at it now I don't know what Task-Key means. The name of the task is derived from the seed name, so basically the filename only - I thought it could be modified by Task-Key, but it doesn't seem to be the case
[13:47] <sil2100> I'm worried that in this case it's also not very relevant to Ubuntu, but maybe someone more tenured would know
[13:47] <sil2100> So basically - task name comes from the seed name, so the filename
[13:55] <ricotz> hello ubuntu-archive, please enable i386 builds for https://launchpad.net/ubuntu/+source/spirv-llvm-translator-15/15.0.0-1ubuntu1
[13:55] <ricotz> it is required for mesa i386 which is in dep-wait
[13:57] <sil2100> utkarsh2102: in overall, tasks are a bit problematic, mostly because they're a bit 'borrowed' from Debian and now we're only using them in build machinery because of legacy reasons. Really we should be using metapackages, as its easy to pull in new things to exising installations this way
[13:58] <sil2100> While for Tasks, well, those are baked into the archive, and basically we only pull them in during build, then the rest is up to metas
[13:58] <sil2100> We generate tasks from the seeds, but the only use for tasks right now is I guess during build of the rootfses and if someone would want to use the good-ol tasksel
[14:04] <Eickmeyer> Don't even ask why images are generated from tasks instead of metas. Nobody knows.
[14:07] <sil2100> I think it's just a matter of 'doing it'. AFAIK there is no reason for that now. We used that probably because of the debian-installer based server images, as tasks had some relevance there still
[14:08] <sil2100> But now?
[14:09] <sil2100> I'm pretty sure that we could even easily make the old ubiquity installer images building without tasks, not to mention the subiquity based ones. We could just nicely generate metas for relevant bits and just use that
[14:10] <ogra> Eickmeyer, iirc that is d-i legacy ... d-i used to use tasks so images did to back then to be consistent (though colin could probably explain it better/more detailed)
[14:10] <ogra> *did too
[14:11] <Eickmeyer> tsimonq2: ^
[14:11] <Eickmeyer> ogra: It's a question that came up during the boat ride in Prague.
[14:11] <sil2100> As said, I think it's just a matter of technical dept
[14:11] <Eickmeyer> Yep.
[14:12] <sil2100> We need to JFDI! But uh, I think everyone has a bit too much on their plates right now ;)
[14:12] <Eickmeyer> :D
[14:13] <Eickmeyer> Yeah, no reason to bikeshed this. It was a silly question tsimonq2 brought up.
[14:18] <sil2100> hm, livefs builders are hanging for me for no reason
[14:20] <sil2100> I'm worried about the candidate images
[14:22] <Eickmeyer> sil2100: I seem to recall this happening before.
[14:27] <sil2100> I'll run a test build of, say, Lubuntu
[14:40] <seb128> ricotz, hey, I will add it to the whitelist
[14:41] <ricotz> seb128, thank you
[14:50] <sil2100> ...networking errors
[15:08] -queuebot:#ubuntu-release- New: rejected xe-guest-utilities [riscv64] (jammy-proposed) [7.20.2-0ubuntu1~22.04.1]
[15:13] -queuebot:#ubuntu-release- Unapproved: rejected xe-guest-utilities [source] (jammy-proposed) [7.20.2-0ubuntu1~22.04.1]
[15:25] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [source] (kinetic-proposed) [7.20.2-0ubuntu1~22.10.1]
[15:26] -queuebot:#ubuntu-release- Unapproved: accepted xe-guest-utilities [source] (jammy-proposed) [7.20.2-0ubuntu1~22.04.2]
[15:26] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [amd64] (kinetic-proposed/none) [7.20.2-0ubuntu1~22.10.1] (ubuntu-cloud)
[15:26] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [armhf] (kinetic-proposed/none) [7.20.2-0ubuntu1~22.10.1] (ubuntu-cloud)
[15:27] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [amd64] (jammy-proposed/universe) [7.20.2-0ubuntu1~22.04.2] (ubuntu-cloud)
[15:27] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [ppc64el] (kinetic-proposed/none) [7.20.2-0ubuntu1~22.10.1] (ubuntu-cloud)
[15:27] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [arm64] (kinetic-proposed/none) [7.20.2-0ubuntu1~22.10.1] (ubuntu-cloud)
[15:27] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [s390x] (kinetic-proposed/none) [7.20.2-0ubuntu1~22.10.1] (ubuntu-cloud)
[15:28] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [armhf] (jammy-proposed/universe) [7.20.2-0ubuntu1~22.04.2] (ubuntu-cloud)
[15:28] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [s390x] (jammy-proposed/universe) [7.20.2-0ubuntu1~22.04.2] (ubuntu-cloud)
[15:29] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [arm64] (jammy-proposed/universe) [7.20.2-0ubuntu1~22.04.2] (ubuntu-cloud)
[15:29] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [ppc64el] (jammy-proposed/universe) [7.20.2-0ubuntu1~22.04.2] (ubuntu-cloud)
[15:33] <bdmurray> ahasenack: We are back to the state we were where we just have deal with issues in scalingstack and run the tests on some arches.
[15:33] <bdmurray> s/run/running/
[15:34] <seb128> ricotz, i386 build failed because pkgconf isn't installable on i386 it seems?
[15:34] -queuebot:#ubuntu-release- Packageset: Added spirv-llvm-translator-15 to i386-whitelist in lunar
[15:35] <ricotz> seb128, hmm, this can't be right
[15:35] <seb128> right, I don't understand, https://launchpadlibrarian.net/652021261/buildlog_ubuntu-lunar-i386.spirv-llvm-translator-15_15.0.0-1ubuntu1_BUILDING.txt.gz
[15:36] <seb128> I tried in a local container but pkgconf:i386 is installable on an amd64 installation, weird
[15:36] <seb128> >  sbuild-build-depends-main-dummy : Depends: pkgconf but it is not installable
[15:37] <seb128> ah, proposed is not being used it seems
[15:37] <seb128> and the release pocket version of pkgconf has no i386 build
[15:37] <seb128> I though buildds were using proposed though?
[15:38] <ricotz> I guess while spirv-llvm-translator-15 is already in release it doesn't use proposed by default
[15:38] <seb128> ah, then my pocket copy isn't enough, I will do a real upload
[15:40] <ricotz> yes, please try that
[15:40] <seb128> ricotz, uploaded
[15:41] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [amd64] (kinetic-proposed) [418.226.00-0ubuntu5~0.22.10.1]
[15:41] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [amd64] (kinetic-proposed) [7.20.2-0ubuntu1~22.10.1]
[15:41] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [armhf] (kinetic-proposed) [7.20.2-0ubuntu1~22.10.1]
[15:41] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [s390x] (kinetic-proposed) [7.20.2-0ubuntu1~22.10.1]
[15:41] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [i386] (kinetic-proposed) [418.226.00-0ubuntu5~0.22.10.1]
[15:41] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [ppc64el] (kinetic-proposed) [7.20.2-0ubuntu1~22.10.1]
[15:41] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [arm64] (kinetic-proposed) [7.20.2-0ubuntu1~22.10.1]
[15:41] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [riscv64] (kinetic-proposed/none) [7.20.2-0ubuntu1~22.10.1] (ubuntu-cloud)
[15:42] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [riscv64] (kinetic-proposed) [7.20.2-0ubuntu1~22.10.1]
[15:55] <utkarsh2102> sil2100: thanks for a wonderful summary! :D
[15:55] <utkarsh2102> so when you say, "So basically - task name comes from the seed name, so the filename" - it means something
[15:55] <utkarsh2102> is wrong with the cloud-image seed, no?
[15:55] -queuebot:#ubuntu-release- New binary: xe-guest-utilities [riscv64] (jammy-proposed/universe) [7.20.2-0ubuntu1~22.04.2] (ubuntu-cloud)
[15:55] <utkarsh2102> https://people.canonical.com/~ubuntu-archive/seeds/ubuntu.lunar/cloud-image has a weird Task-Key, not even related :P
[15:56] <sil2100> Yeah, I don't really know now what Task-Key is used for, I think this actually might be very tasksel related, so I'd just ignore it for now ;p
[15:57] <utkarsh2102> got it!
[15:57] <sil2100> The task name is the seed name, so the above cloud-image seed results in the packages in that seed getting a Tasks: cloud-image field
[15:58] <sil2100> And by doing add_task in livecd-rootfs, livecd-rootfs querries apt to get all packages that have the given task in their Tasks field and installs them to the target layer/pass
[15:58] <utkarsh2102> as you'd know, I am trying to create a new cloud-minimal seed and hence I ask, to be super clear what's happening
[15:58] <utkarsh2102> so for cloud-minimal, I'll just not care about Task* at the moment :)
[15:58] <utkarsh2102> does that seem reasonable?
[16:00] <utkarsh2102> sil2100: oh wait, when queried, apt gets all the packages that have given task in their Tasks field but with cloud-image seed having a weird Task-Key, how does that work? Should it not only install cloud-init then? As that's the Task-Key mentioned?
[16:00] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [amd64] (jammy-proposed) [7.20.2-0ubuntu1~22.04.2]
[16:00] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [armhf] (jammy-proposed) [7.20.2-0ubuntu1~22.04.2]
[16:00] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [riscv64] (jammy-proposed) [7.20.2-0ubuntu1~22.04.2]
[16:00] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [arm64] (jammy-proposed) [7.20.2-0ubuntu1~22.04.2]
[16:00] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [s390x] (jammy-proposed) [7.20.2-0ubuntu1~22.04.2]
[16:01] -queuebot:#ubuntu-release- New: accepted xe-guest-utilities [ppc64el] (jammy-proposed) [7.20.2-0ubuntu1~22.04.2]
[16:01] <sil2100> Yeah, I'd just fill in Task-Description: for descriptive purposes
[16:01] <sil2100> utkarsh2102: as mentioned, I don't think Task-Key is used by our stuff right now
[16:02] <utkarsh2102> gotttttttttt it! thank youuuu. <3
[16:03] <sil2100> utkarsh2102: by 'queries apt to get all packages that have the given task in the Tasks field' I mean that when you create a seed with name 'foo', add some packages to it, push it, and in some ticks basically the archive should make sure to add this 'foo' task to the list of "Task:" it has
[16:03] <sil2100> $ apt-cache show vim |grep Task
[16:03] <sil2100> Task: cloud-image, ubuntu-wsl, server, ubuntu-server-raspi, lubuntu-desktop
[16:04] <utkarsh2102> interesting!
[16:05] <utkarsh2102> how'd the archive now which tasks to add? :)
[16:05] <utkarsh2102> s/now/know/g
[16:06] <sil2100> Those are the bits that are a bit unknown to me as I never dealt with the machinery on the archive side, but I suppose it all comes from germinate runs that are constantly happening
[16:07] <sil2100> This is probably more Colin territory or someone that's more tenured ;p
[16:09] <utkarsh2102> niicee! so I'll try to use as minimal stuff as required and not step on the "Tasks*" landmine for as long as I can avoid it 😌
[16:10] <utkarsh2102> also, it'd just make more sense for me to use "minimal things" for a seed that I am calling "minimal" cloud seed :P
[16:12] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Jammy 22.04.2] (20230217.1) has been added
[16:16] <Eickmeyer> utkarsh2102: That's similar to how we're doing it for edubuntu: using the ubuntu-minimal task, which is the ubuntu-desktop task but in the minimal installation form, and building on that for the edubuntu-desktop-gnome task.
[16:17]  * utkarsh2102 looks at edubuntu
[16:22] <utkarsh2102> https://people.canonical.com/~ubuntu-archive/seeds/edubuntu.lunar/desktop-gnome, this one, I think?
[16:23] <Eickmeyer> utkarsh2102: Yep, that's the one.
[16:23] <utkarsh2102> I see, thanks!
[16:24] <Eickmeyer> utkarsh2102: https://people.canonical.com/~ubuntu-archive/seeds/edubuntu.lunar/STRUCTURE should give you a better clue though.
[16:25] <Eickmeyer> Notice how desktop-gnome is structured with desktop-common, but then desktop-gnome uses ubuntu-minimal as a dep.
[16:25] <Eickmeyer> er... ubuntu-destkop-minimal.
[16:45] <vorlon> LocutusOfBorg: I tried to add a skiptest dkms/all/i386 but I'm not sure if skiptest works per-architecture; let me go see
[16:45] <vorlon> LocutusOfBorg: (I'm off work today though so this is just a quick poke then I'm disappearing)
[16:45] <vorlon> LocutusOfBorg: "Should wait for tests relating to dkms 3.0.10-6, but forced by vorlon
[16:45] <vorlon> "
[16:46] <vorlon> LocutusOfBorg: so no, the per-arch hint appears to *not* work and it appears instead to be ignoring all tests :P
[16:49] <vorlon> utkarsh2102, seb128: server has a minimal option but it doesn't work via a "remove" file which is a ubiquity-ism; instead it pulls from a different squashfs layer
[16:49] <vorlon> utkarsh2102, sil2100: Task-Key means: if this package is absent from the archive, do not emit this task
[16:53] <vorlon> LocutusOfBorg: so dkms has in fact migrated, ignoring all the test results <shrug>
[16:53] <vorlon> xnox: ^^
[16:59] <utkarsh2102> vorlon: aah, I see, thanks. would it be correct to say that it basically is an essential package for that seed?
[16:59] <utkarsh2102> but that sounds a bit odd
[17:00] <ricotz> this deserves a retry now - https://launchpad.net/ubuntu/+source/mesa/22.3.4-1ubuntu1/+build/25559244
[17:02] <utkarsh2102> ricotz: https://launchpad.net/ubuntu/+source/mesa/22.3.4-1ubuntu1/ seems to have been built
[17:02] <bdmurray> sil2100: Do all these language packs need to be phasing?
[17:03] <ricotz> utkarsh2102, i386 isn't
[17:04] <utkarsh2102> oops, sorry
[17:04] <utkarsh2102> Missing build dependencies: libllvmspirvlib-15-dev
[17:05] <vorlon> utkarsh2102: yes, effectively
[17:06] <vorlon> utkarsh2102: it's in the process of being bootstrapped, seb128 did the necessary upload
[17:06] <vorlon> (mesa)
[17:12] <sil2100> bdmurray: I don't think so
[17:13] <sil2100> Ok, firing up some test release candidate images o/
[17:26] <xnox> vorlon:  thanks for the highlight.
[17:28] <bdmurray> sil2100: Okay, an AA would need to fully phase them
[17:37] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Jammy 22.04.2] (20230217.1) has been added
[17:37] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Jammy 22.04.2] (20230217) has been added
[17:41] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Jammy 22.04.2] (20230217.1) has been added
[17:42] <vorlon> bdmurray, sil2100: which what?
[17:43] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Jammy 22.04.2] (20230217.1) has been added
[17:44] <sil2100> Langpacks, they're phasing out slowly
[17:44] <sil2100> Even though I don't think there's any need for that
[17:47] <vorlon> ok I'll phase them
[17:48] <vorlon> would be nice to have a helper to do the phasing for langpacks based on glob, but
[17:48] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Jammy 22.04.2] (20230217) has been added
[17:51] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Jammy 22.04.2] (20230217.1) has been added
[17:52] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Jammy 22.04.2] (20230217.1) has been added
[17:52] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Jammy 22.04.2] (20230217) has been added
[18:17] <vorlon> sil2100, bdmurray: ok my change-overrides command for language-pack* didn't have any typos, it's just committing all the changes now
[18:19] <utkarsh2102> ack, thank you, vorlon!
[18:32] <sil2100> vorlon: thanks!
[19:02] -queuebot:#ubuntu-release- New binary: rustc [i386] (lunar-proposed/main) [1.66.1+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[19:25] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Jammy 22.04.2] (20230217.1) has been added
[19:25] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Jammy 22.04.2] (20230217.1) has been added
[19:25] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Jammy 22.04.2] (20230217.1) has been added
[19:25] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Jammy 22.04.2] (20230217.1) has been added
[19:25] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Jammy 22.04.2] (20230217.1) has been added
[19:25] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Jammy 22.04.2] (20230217.1) has been added
[19:28] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (lunar-proposed/main) [1.66.1+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[19:32] -queuebot:#ubuntu-release- New binary: rustc [amd64] (lunar-proposed/main) [1.66.1+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[19:36] -queuebot:#ubuntu-release- New binary: rustc [s390x] (lunar-proposed/main) [1.66.1+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[20:33] <LocutusOfBorg> vorlon, what does dkms skiptest means? the failures are now "regressed in release" or something like that?
[20:56] <fnordahl> apparently our friends in upstream OpenStack are awaiting some fixes in the newly accepted https://launchpad.net/ubuntu/+source/ovn/22.03.2-0ubuntu0.22.04.1 however that will not build until we also get https://launchpadlibrarian.net/646504743/openvswitch_2.17.5-0ubuntu0.22.04.1_source.changes into -proposed ref bug 2003060 if anyone has a moment to help out
[20:56] -ubottu:#ubuntu-release- Bug 2003060 in openvswitch (Ubuntu Jammy) "[SRU] openvswitch 2.17.5 point release" [High, Triaged] https://launchpad.net/bugs/2003060
[21:08] <Eickmeyer> ubuntu-sru and ubuntu-release: Found a ux regression in Ubuntu Studio for this point release, mostly due to a change in how Plasma propagates its defaults, so not a regression in plasma per se, just a change we weren't made aware of that only affects Studio. bug 2007614
[21:08] -ubottu:#ubuntu-release- Bug 2007614 in ubuntustudio-default-settings (Ubuntu Jammy) "[SRU] Change to plasma causes login splash screen defaults to propogate differently" [High, In Progress] https://launchpad.net/bugs/2007614
[21:30] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Jammy 22.04.2] (20230217.1) has been added
[21:30] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Jammy 22.04.2] (20230217.1) has been added
[21:30] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+nezha [Jammy 22.04.2] (20230217.1) has been added
[21:30] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+visionfive [Jammy 22.04.2] (20230217.1) has been added
[21:58] <vorlon> LocutusOfBorg: I think they won't be considered regressed in release unless there's a baseline retest
[21:58] <LocutusOfBorg> ok
[21:59] <vorlon> LocutusOfBorg: but dkms was allowed to migrate without tests having been run (but they were still queued and will show in results later)
[21:59] <LocutusOfBorg> in any case they were regressed due to new kernel in proposed
[21:59] <LocutusOfBorg> so, I guess they will need fixes for the kernel to migrate?
[22:01] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Jammy 22.04.2] (20230217.1) has been added
[22:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Jammy 22.04.2] (20230217.1) has been added
[22:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Jammy 22.04.2] (20230217.1) has been added
[22:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Jammy 22.04.2] (20230217.1) has been added
[22:03] <LocutusOfBorg> (still sfepy ping to hint i386)
[22:06] <vorlon> LocutusOfBorg: well we don't care about kernel modules on i386
[22:06] <vorlon> but I also didn't see anything dkms-related that was blocking linux currently
[22:07] <vorlon> (certainly not dkms on i386)
[22:12] <vorlon> LocutusOfBorg: sfepy/i386 badtest added
[22:15] <LocutusOfBorg> <3
[22:40] -queuebot:#ubuntu-release- New binary: rustc [armhf] (lunar-proposed/main) [1.66.1+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[22:58] <bdmurray> vorlon: It looks like there are two sets of libzstd tests queued with libzstd/1.5.4+dfsg2-2 being obsolete
[23:38] -queuebot:#ubuntu-release- New binary: rustc [arm64] (lunar-proposed/main) [1.66.1+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)