[00:38] <jbicha> vorlon: glgrib depends on eccodes which has sad autopkgtests
[00:41] <jbicha> hmm, slurm-wlm in the new queue (with a 1-package transition) is also part of the perl transition
[01:03] <vorlon> well that's getting rolled back the
[01:03] <vorlon> n
[01:04] <vorlon> LocutusOfBorg: ^^ not helpful to be merging packages right now that have existing versions depending on perl in -proposed
[01:06] <vorlon> (well, initially was a manual sync, and then an Ubuntu fix-up, not a merge; still, autosyncs are off for a reason and that reason is perl!)
[01:06] <vorlon> eccodes: <table flip>
[01:08] <vorlon> jbicha: looks to me like gnudatalanguage autopkgtests are broken by other stuff in -proposed and not by perl; do you want to try to work out a proper trigger that handles this or should I?
[01:08] <vorlon> ah glgrib has no revdeps
[01:08] <vorlon> axing from release pocket
[01:10] <vorlon> hmm triggering retries of graphviz autopkgtests but that doesn't look pretty
[01:23] <ItzSwirlz> hey release-team, any updates as to getting me the perms i need on the qa tracker?
[01:26] <ItzSwirlz> ubuntu-release ^
[01:30] <vorlon> hi, sorry, haven't had a chance to look at that and now I have to go pick up dinner
[01:31] <vorlon> ItzSwirlz: to confirm, what's your account on iso.qa.u.c?
[01:31] <ItzSwirlz> "itzswirlz"
[01:31] <ItzSwirlz> np, i hope your dinner is nice :)
[02:16] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (jammy-proposed) [1:22.04.19]
[03:20] <vorlon> oh good graphviz looking much better now
[03:20] <vorlon> just waiting for one test result to trickle in
[03:21] <vorlon> triggering tests for openbabel, zbar
[03:48] <vorlon> bdmurray: ^^ fwiw it appears to be nonviable to add a user to a role through the iso.qa web interface because you cannot add users from the role interface, and you cannot search by username from the people interface; so I guess I have to drop to sql to administer flavor leads
[03:48] <vorlon> bdmurray: maybe you want addressing that on your backlog since this site will never die
[03:54] <vorlon> ItzSwirlz: I think you have access now
[03:56] <Eickmeyer> vorlon: I'm not sure what's going on, but despite having lvm2 on the edubuntu live seed, it's not showing up in the manifest. (subiquity needs it)
[03:56] <vorlon> hmm
[03:56] <vorlon> Eickmeyer: I only see it in the ship-live seed not the live seed?
[03:57] <Eickmeyer> It's in both.
[03:57] <vorlon> well it shouldn't be in both
[03:57] <Eickmeyer> I can take it out of ship-live.
[03:57] <vorlon> it should only ever be one or the other. anyway, refreshed now and I see it in live ok
[03:57] <vorlon> which image are you looking at?
[03:57] <vorlon> (serial)
[03:57] <Eickmeyer> Latest.
[03:58] <Eickmeyer> https://cdimage.ubuntu.com/edubuntu/daily-live/20240214/noble-desktop-amd64.manifest
[03:58] <vorlon> ok
[03:59] <vorlon> which is https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/edubuntu/+build/576931
[03:59] <Eickmeyer> Yes
[03:59] <vorlon> are you coming to this via an installer failure?
[04:00] <vorlon> for the record lvm2 is NOT in the live seed on Ubuntu, it's in ship-live
[04:00] <vorlon> because it's something intended for subiquity to pool in as needed from the package pool based on the target install setup
[04:00] <Eickmeyer> Yes. Installer crashes if lvm2 is not installed in the live system. And yes, I realize it's in ship-live for Ubuntu.
[04:01] <vorlon> ok are you able to get some debugging logs on this? because I think we shouldn't be crashing and there is maybe a failure here in not properly setting up apt for the package pool so that it can be installed on demand
[04:01] <vorlon> anyway, still looking at why it's not seeded
[04:01] <vorlon> eh seeded but not in manifest
[04:02] <Eickmeyer> Right.
[04:02] <vorlon> you know that image builds pull from ubuntu-archive-team.ubuntu.com/seeds/ not directly from git?
[04:02] <Eickmeyer> The errors are reported by subiquity: mdadm command not found: [Errno 2] No such file or directory: 'mdadm'
[04:02] <vorlon> so there's a propagation delay
[04:02] <Eickmeyer> subiquity/Filesystem/_probe/probe_once: FAIL: [Errno 2] No such file or directory: 'pvscan'
[04:03] <Eickmeyer> Yes, this isn't a recent addition.
[04:03] <vorlon> ok so please report that against subiquity, dunno if mwhudson is available to look at it now but they should at least be able to triage
[04:03] <vorlon> indeed, I see it's there since Jan 17 and https://ubuntu-archive-team.ubuntu.com/seeds/edubuntu.noble/live is definitely newer than that
[04:03] <Eickmeyer> Well, bdrung closed it as "wontfix" today. bug 2049798
[04:03] -ubottu:#ubuntu-release- Bug 2049798 in Edubuntu Desktop Installer "Edubuntu install failed crashed with CalledProcessError" [Undecided, Fix Released] https://launchpad.net/bugs/2049798
[04:04] <vorlon> well bdrung is not a subiquity developer either
[04:04] <vorlon> ah no it was dbungert
[04:05] <Eickmeyer> ope, my bad
[04:06] <vorlon> huh why does edubuntu still have both live and dvd-live seeds
[04:06] <Eickmeyer> Legacy. They're pretty irrellevant and can probably be deleted.
[04:07] <vorlon> probably worth cleaning up to avoid confusion fwiw; but not critical path for this
[04:07] <Eickmeyer> Future Erich problems.
[04:08] <vorlon> so, it's in the seed but missing from https://ubuntu-archive-team.ubuntu.com/germinate-output/edubuntu.noble/live
[04:08] <vorlon> ah lvm2 is in platform/live-common
[04:09] <vorlon> so that all looks correct for it to be included in the squashfs
[04:09] <Eickmeyer> I'm missing a Task-Seed: live-common
[04:10] <vorlon> Task-Seed is obsolete
[04:10] <Eickmeyer> Oh, then nevermind.
[04:10] <vorlon> ... I think
[04:10] <vorlon> (most of the Task-* headers are)
[04:10] <vorlon> it does mean in any case that adding it to the live seed is redundant because it's supposed to come via live-common
[04:10] <Eickmeyer> STRUCTURE has live: desktop-gnome live-common
[04:10] <Eickmeyer> So that should do i.t
[04:11] <Eickmeyer> *it
[04:11] <vorlon> Eickmeyer: ok I retract; Ubuntu does have Task-Seeds: live-common
[04:11] <vorlon> so that is probably what's missing
[04:11] <vorlon> and STRUCTURE means the opposite of what you would intuit it to mean
[04:11] <Eickmeyer> Oh fun. One of those reverse-intuits.
[04:11] <vorlon> STRUCTURE means "when germinating, don't include in this seed any of the packages that are already in these other seeds"
[04:11] <vorlon> so yeah, please give Task-Seeds a try
[04:11] <vorlon> afk now
[04:13] <Eickmeyer> Ok, good night. I'll give it a respin in a few.
[04:19] <dbungert> Eickmeyer: have you analyzed yet the differences between edubuntu seeds for these packages and baseline ubuntu desktop?
[04:20] <Eickmeyer> dbungert: Seems that Edubuntu's live seed is missing the Task-Seeds: live-common line, so that might be a factor. With edubuntu-desktop-installer (based on the now-deprecated ubuntu-flavor-installer framework), I had to make lvm2 explicitly part of the snap. I don't have that option anymore, so the issue is back.
[04:21] <dbungert> the live-common change sounds promising
[04:23] <Eickmeyer> Indeed. I'm waiting for it to propogate to https://ubuntu-archive-team.ubuntu.com/seeds/edubuntu.noble/live so I can trigger a rebuild.
[04:23] <dbungert> Eickmeyer: would you point me to the correct repo for the edubuntu seeds?
[04:24] <dbungert> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/edubuntu ?
[04:24] <Eickmeyer> Close, but https://code.launchpad.net/~edubuntu-dev/ubuntu-seeds/+git/edubuntu
[04:25] <Eickmeyer> The ~ubuntu-core-dev one is the old archived copy.
[04:27] -queuebot:#ubuntu-release- New source: involflt (noble-proposed/primary) [0.1.0-0ubuntu5]
[04:55] <mwhudson> vorlon: task-seeds is not obsolete
[04:55] <mwhudson> (the code in livecd-rootfs's expand-task script looks at it)
[05:25] <vorlon> mwhudson: heh yes figured that out; unhelpful that Task-* is overloaded in this sense
[05:25] <mwhudson> vorlon: no kidding
[05:25] <vorlon> we would benefit from decrufting our seeds of fields we know are obsolete for Ubuntu
[05:27] <mwhudson> has livecd-rootfs migrated yet?
[05:27] <mwhudson> nope
[06:08] -queuebot:#ubuntu-release- Packageset: Added java-atk-wrapper to i386-whitelist in focal
[06:08] -queuebot:#ubuntu-release- Packageset: Added gcc-14-cross-ports to i386-whitelist in jammy
[06:08] -queuebot:#ubuntu-release- Packageset: Added java-atk-wrapper to i386-whitelist in jammy
[06:08] -queuebot:#ubuntu-release- Packageset: Added java-atk-wrapper to i386-whitelist in mantic
[06:10] <vorlon> mwhudson: it has now
[06:10] <vorlon> mwhudson: will you upload the next one?
[06:39] -queuebot:#ubuntu-release- Packageset: Added x11-utils to i386-whitelist in focal
[06:39] -queuebot:#ubuntu-release- Packageset: Added x11-utils to i386-whitelist in jammy
[06:39] -queuebot:#ubuntu-release- Packageset: Added x11-utils to i386-whitelist in mantic
[07:34] <lanoxx> Hello release time, I am having a hard-time understanding how and when packages are currently synced from Debian unstable into Ubuntu, all documentation that I could find seems to suggest that a daily auto sync is active and imports packages from unstable and should continue until the Debian import freeze which is not until the 29.2., but on Ubuntu next someone suggested that the autosync have already been turned off.
[07:35] <lanoxx> s/time/team
[07:38] <lanoxx> I have a couple of questions: 1) Where is this process documented? If its documented then it seems hard to discover (I tried searching for several hours on multiple days). I looked at (https://iso.qa.ubuntu.com/qatracker, and https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649 and https://wiki.ubuntu.com/DebianImportFreeze
[07:40] <lanoxx> 2) If autosync has already been turned of, then can I request a sync of the package tilda 2.0.0-1 (see: https://packages.debian.org/sid/tilda), this package adds many bug fixes, D-Bus support for Wayland and other new changes and is the first upload since 3 years so it would be great if it could still make it into Ubuntu 24.04.
[07:49] <lanoxx> I was thinking that I can maybe go to launchpad or some other page in the wiki to see when the next sync happens, if autosync is currently active (or disabled as it was suggested in #ubuntu-release) and what packages have been imported by each sync? If such a page exists then it seems to be difficult to find via Google, maybe we can add more prominent links or document this process n the wiki.
[07:55] <LocutusOfBorg> vorlon, I was going to really just upload fixed mpich after the accept, (something that didn't happen). The reason for the upload is Debian bug: #1058720 with severity grave
[07:55] -ubottu:#ubuntu-release- Debian bug 1058720 in src:slurm-wlm "slurm-wlm: CVE-2023-49933 CVE-2023-49935 CVE-2023-49936 CVE-2023-49937 CVE-2023-49938" [Grave, Fixed] https://bugs.debian.org/1058720
[07:55] <LocutusOfBorg> so, something we should get in ASAP, and sorry for delaying perl
[07:56] <LocutusOfBorg> anyway, will fix once perl migrates then
[07:57] <LocutusOfBorg> lanoxx, see topic, perl is migrating, for this reason autosync is off
[07:57] <LocutusOfBorg> that said, tilda shouldn't be an issue, manually syncd
[07:58] <LocutusOfBorg> in any case there should be time to have auto sync back to on before debian import freeze, so it would have been autosyncd anyway :)
[08:00] <LocutusOfBorg> btw I can't fix llvm-toolchain-18, I guess time64 and lfs should be enabled for every arch except i386, right?
[08:00] <LocutusOfBorg> so I have to make it build with that hack
[08:16] -queuebot:#ubuntu-release- Unapproved: cd-boot-images-riscv64 (jammy-proposed/main) [5.2 => 5.3] (no packageset)
[08:25] -queuebot:#ubuntu-release- Unapproved: accepted cd-boot-images-amd64 [source] (jammy-proposed) [20.3]
[08:26] -queuebot:#ubuntu-release- Unapproved: accepted cd-boot-images-arm64 [source] (jammy-proposed) [16.2]
[08:27] -queuebot:#ubuntu-release- Unapproved: accepted cd-boot-images-riscv64 [source] (jammy-proposed) [5.3]
[10:08] <juliank> Note that ubuntu-release-upgrader has migrated, but python-apt has not, but the u-r-u tests rely on the new python-apt behavior
[10:09] <juliank> python-apt somehow got retries triggered for apt 2.7.10 that have failed, but succeeded before, hopefully this will get sorted out soon, but they also passed previously, so maybe, ubuntu-release wants to hint it
[10:11] <juliank> Though I reran them they might clear up next britney run
[10:11] <juliank> It's just we can't tell, the autopkgtests.ubuntu.com page still doesn't receive new results
[10:39] <LocutusOfBorg> lanoxx, it's blocked by glib2.0 migration, and this might happen together with perl or python, don't know
[11:19] <LocutusOfBorg> ubuntu-release and ubuntu-archive: if we kick ruby-omniauth-oauth2-generic out (Debian bug: #1019643), ruby-default becomes migrateable
[11:19] -ubottu:#ubuntu-release- Debian bug 1019643 in src:ruby-omniauth-oauth2-generic "ruby-omniauth-oauth2-generic: FTBFS with ruby3.1: ERROR: Test 'ruby3.0' failed:      Failure/Error: expect(last_response.headers['Location']).to match(%r{redirect_uri=https%3A%2F%2Fmy_server.com%2Foauth%2Fcallback&})" [Serious, Open] https://bugs.debian.org/1019643
[11:19] <LocutusOfBorg> kanashiro, ^^
[11:20] <LocutusOfBorg> this makes ruby-defaults migratable, unblocking some perl sadness (due to src:marisa)
[11:21] <LocutusOfBorg> and probably this is the last blocker?
[11:21] <LocutusOfBorg> even restoring an old marisa works, disentangling them
[11:21] <LocutusOfBorg> vorlon, ^^
[11:56] -queuebot:#ubuntu-release- Unapproved: rejected chromium-browser [source] (focal-proposed) [2:1snap1-0ubuntu1.20.04.1]
[11:56] -queuebot:#ubuntu-release- Unapproved: rejected chromium-browser [source] (jammy-proposed) [2:1snap1-0ubuntu1.22.04.1]
[11:57] -queuebot:#ubuntu-release- Unapproved: rejected chromium-browser [source] (mantic-proposed) [2:1snap1-0ubuntu1.23.10.1]
[12:08] -queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (focal-proposed) [2:17.0.1-0ubuntu2]
[13:04] <jbicha> LocutusOfBorg: glib won't migrate until gobject-introspection does which is part of the python transition
[13:17] <LocutusOfBorg> jbicha, ack
[13:17] <LocutusOfBorg> so today maybe we can have perl migrate
[13:23] -queuebot:#ubuntu-release- Unapproved: cups (jammy-proposed/main) [2.4.1op1-1ubuntu4.7 => 2.4.1op1-1ubuntu4.8] (core, i386-whitelist)
[14:06] -queuebot:#ubuntu-release- Unapproved: accepted cmake [source] (jammy-proposed) [3.22.1-1ubuntu1.22.04.2]
[14:13] -queuebot:#ubuntu-release- Unapproved: accepted sysdig [source] (jammy-proposed) [0.27.1-0.3ubuntu0.3]
[14:25] <juliank> Note that cmake in release pocket is broken, fixed one is stuck a bit
[14:25] <juliank> Will try to get it unstuck
[14:26] <juliank> cmake exposes bug on ppc64el, so it segfaults e.g. in apt autopkgtest.
[14:26] <juliank> it's blocked by llvm-toolchain-14, i retried that with migration-reference/0 trigger
[14:34] <sgmoore> Hello folks, I have spoken to tsimonq2 and have been given a +1 to go ahead and upload our new kf5 frameworks release and Plasma debian merges despite the long going qt transistion. I understand the risks and take full responsibility. If there are any objections, please let me know ASAP. Thanks!
[14:35] -queuebot:#ubuntu-release- Unapproved: sagemath (mantic-proposed/universe) [9.5-6 => 9.5-6ubuntu0.1] (no packageset)
[14:35] -queuebot:#ubuntu-release- Unapproved: rejected sagemath [source] (mantic-proposed) [9.5-6ubuntu1]
[14:36] -queuebot:#ubuntu-release- Unapproved: accepted sagemath [source] (mantic-proposed) [9.5-6ubuntu0.1]
[14:39] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (mantic-proposed) [20230808.00-0ubuntu2~23.10.0]
[14:52] <tsimonq2> If there is any further clarification needed, I am happy to help. For the record, recent Qt transitions have been bugfix, so I am not expecting issues.
[14:53] -queuebot:#ubuntu-release- Unapproved: base-files (jammy-proposed/main) [12ubuntu4.5 => 12ubuntu4.6] (core, i386-whitelist)
[14:54] <tsimonq2> Hm, so Qt is blocked on two autopkgtests for pyqt5. Might be able to get that through today.
[14:55] <tsimonq2> Both of those failures seem to be transient, I have retried them.
[15:00] <tsimonq2> qa-help: Okay, that ubiquity ppc64el autopkgtest failure is a service blip, in my estimation.
[15:01] <tsimonq2> https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/ppc64el/u/ubiquity/20240214_034033_22990@/log.gz is an example, it just failed the same way again.
[15:01] <tsimonq2> It seems to be shutting off the virtual machine when it intends on restarting it.
[15:06] <dbungert> tsimonq2: agree, I sent a retest for that one.
[15:06] <dbungert> (ubiquity ppc64el)
[15:06] <tsimonq2> dbungert: I saw :) thanks for your help!
[15:06] <dbungert> welcome!
[15:07] -queuebot:#ubuntu-release- Unapproved: rejected vim [source] (jammy-proposed) [2:8.2.3995-1ubuntu2.16]
[15:07] -queuebot:#ubuntu-release- Unapproved: rejected vim [source] (mantic-proposed) [2:9.0.1672-1ubuntu2.3]
[15:07] -queuebot:#ubuntu-release- Unapproved: rejected vim [source] (focal-proposed) [2:8.1.2269-1ubuntu5.22]
[16:08] <vorlon> temporary rollback of libsys-virt-perl for perl transition
[16:11] <vorlon> LocutusOfBorg: tiem64 and lfs> "every arch" except i386 but it's a complete no-op in terms of output on 64-bit archs, so really just armhf?
[16:14] -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [riscv64] (noble-proposed/main) [31] (core)
[16:14] <vorlon> oops didn't want to remove libsys-virt-perl from the release pocket though; darn shell history
[16:15] <vorlon> LocutusOfBorg, kanashiro: thanks, have removed ruby-omniauth-oauth2-generic from the release pocket, and if someone cares Debian bug #1019643 should get fixed
[16:15] -ubottu:#ubuntu-release- Debian bug 1019643 in src:ruby-omniauth-oauth2-generic "ruby-omniauth-oauth2-generic: FTBFS with ruby3.1: ERROR: Test 'ruby3.0' failed:      Failure/Error: expect(last_response.headers['Location']).to match(%r{redirect_uri=https%3A%2F%2Fmy_server.com%2Foauth%2Fcallback&})" [Serious, Open] https://bugs.debian.org/1019643
[16:17] <tsimonq2> ubuntu-release: Qt looks ready to migrate, in and of itself. The reason Britney hasn't migrated yet is because qgis entangles Qt and Python 3.12.
[16:18] <tsimonq2> I would like to know, just for my own future reference, whether it would be proper to roll back qgis/demote it to -proposed, or simply hint it Britney-side.
[16:21] <vorlon> rolling back the release pocket is messy and I try to avoid it.  demotion to proposed is something I only do when the package in the release pocket is unreleasably buggy *and* there is an Ubuntu delta that is worth keeping track of; otherwise it's just a removal instead to not clutter proposed-migration with a known-broken package.  In both cases you have to account for revdeps
[16:23] <tsimonq2> Okay great, that makes a lot of sense!
[16:27] <tsimonq2> Now that my general question has been addressed, what would be the best steps forward to get Qt to migrate? I could personally see a few potential options, what makes most sense to me would be hinting qgis.
[16:28] <tsimonq2> I say that because the package is not broken, Britney just wants to associate the two transitions through that one package. Python 3.11 is still default in Unstable, and I see no changes in the debdiff between what is in release and proposed to indicate removing support for 3.11.
[16:28] <tsimonq2> It's also not seeded.
[16:28] <vorlon> sorry, don't have bandwidth at the moment to dig into the specifics and figure out a recommendation
[16:29] <vorlon> queuing for ~later this morning
[16:29] <tsimonq2> Not a problem, thank you :)
[16:29] <LocutusOfBorg> vorlon, upstream after 10 months didn't look at that bug and the tool si just not compatible :)
[16:29] <LocutusOfBorg> so, meh!
[16:29] <LocutusOfBorg> thanks for removing
[16:29] <LocutusOfBorg> so, now perl migrating?
[16:30] <vorlon> maybe
[16:30] <LocutusOfBorg> vorlon, for me w.r.t. llvm-toolchain-18, is more complicated
[16:30] <vorlon> I also just raised https://code.launchpad.net/~vorlon/britney/+git/britney2-ubuntu/+merge/460522
[16:31] <vorlon> about the fact that the 'implicit dependency' info on update_excuses turns what should be a straightforward divide-and-conquer exercise into a game of whack-a-mole
[16:31] <LocutusOfBorg> I had to do something like https://pastebin.ubuntu.com/p/7RBtwTBdm9/
[16:31] <LocutusOfBorg> compiler-rt doesn't compile with +time64+lfs on 32bit architectures, because of #undef of the variable
[16:31] <LocutusOfBorg> so I have to drop compiler-rt on all 32bits, but enable on i386
[16:32] <LocutusOfBorg> ./compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:#undef _TIME_BITS
[16:32] <LocutusOfBorg> / Tests in this file assume that off_t-dependent data structures match the
[16:32] <LocutusOfBorg> / libc ABI. For example, struct dirent here is what readdir() function (as
[16:32] <LocutusOfBorg> / exported from libc) returns, and not the user-facing "dirent", which
[16:32] <LocutusOfBorg> / depends on _FILE_OFFSET_BITS setting.
[16:32] <LocutusOfBorg> / To get this "true" dirent definition, we undefine _FILE_OFFSET_BITS below.
[16:32] <LocutusOfBorg> #undef _FILE_OFFSET_BITS
[16:32] <LocutusOfBorg> #undef _TIME_BITS
[16:32] <vorlon> ok
[16:32] <LocutusOfBorg> did you test all your NMUs for 32bit buildability? :)
[16:32] <LocutusOfBorg> I'm wondering how many packages will just FTBFS
[16:33] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages
[16:34] <vorlon> certainly not
[16:38] <LocutusOfBorg> ack :D
[16:38] <LocutusOfBorg> can we have a dpkg with changed default in experimental maybe? :)
[16:38] <LocutusOfBorg> this will make rebuilds easier
[16:43] <vorlon> you'd have to talk to guillem; we discussed and concluded it wasn't necessary for this
[16:43] <vorlon> also adding a few build failures in unstable is not as bad as the other things we're guarding against (runtime explosions; libraries going missing from disk)
[17:09] <adrien> UnivrslSuprBox: it took me a while... that was ridiculous of me... yes, I am aware of this issue and there is no solution
[17:10] <adrien> UnivrslSuprBox: I don't know the details for faketime's build and testsuite, only for datefudge
[17:10] <adrien> it also turns out that datefudge, due to being much more limited, was able to add support for cross-bitness AFAIU
[17:11] <adrien> for datefudge it was a test failure only so we were able to skip tests; an FTBFS would be different but I don't know if we can do much about it for now
[17:12] <adrien> for armhf the solution is the current transition which is already ongoing
[17:12] <adrien> for i386, well, we decided not to do that transition for this architecture
[17:13] <adrien> do we need faketime for i386?
[17:14] <vorlon> something "needs" it, it's built on i386
[17:14] <vorlon> but users don't need it
[17:14] <adrien> vorlon: maybe we can skip it... if we don't, we'd have to transition i386 too, right?
[17:15] <vorlon> what do you mean transition
[17:15] <vorlon> we're absolutely not converting i386 to 64-bit time_t by default
[17:15] <adrien> and I don't think we can "fix" faketime
[17:17] <adrien> which is why reviewing requirements of faketime for i386 might be the easiest route, especially since datefudge could be used for some of faketime's needs (and some packages now have options to fake time rather than rely on datefudge/faketime)
[17:17] <adrien> (afk cutting shrooms)
[17:24] <dbungert> release team - for 22.04.4 I intend to merge this fix to the stable branch of Subiquity.  LP: #2052524 - please review
[17:24] -ubottu:#ubuntu-release- Launchpad bug 2052524 in cloud-images "INSECURE permissions for Ubuntu Netplan YAML on installer execution, cloud images" [Undecided, New] https://launchpad.net/bugs/2052524
[17:35] <adrien> I never had to take i386 into account; is there a quick way to find why a package is built on that arch? or do I have to do it like on any other arch?
[17:37] <vorlon> adrien: https://ubuntu-archive-team.ubuntu.com/germinate-output/i386.noble/
[17:42] <UnivrslSuprBox> adrien: it does build successfully on i386 and armhf, but dh_auto_test fails. Turns out there's only one integration test that checks that the date command outputs the correct stuff.
[17:43] <UnivrslSuprBox> It can be made to work by building it with 64-bit timestamps, which I assume will fix date(1) and anything else using 64-bit timestamps but break anything still using 32-bit timestamps.
[17:44] <vorlon> I have zero care about whether faketime does the right thing on i386
[17:44] <vorlon> nobody is going to install the faketime i386 binary package on a real system
[17:45] <vorlon> all I care is that the closure of build-dependencies is complete, and the i386 compat libraries that users ACTUALLY want/need are usable
[17:46] <adrien> vorlon: thanks
[17:47] <adrien> UnivrslSuprBox: if it's tests, it's best to skip it; the issue is not that faketime does not work, it's that the architecture does not work
[17:47] <UnivrslSuprBox> Right, it's an integration issue between Ubuntu using 64-bit timestamps in coreutils and faketime only intercepting the calls to 32-bit gettimeish calls.
[17:48] <adrien> IOW, the issue is with the arch, not with faketime/datefudge: you can take any program and it will give wrong results for times not-so-far-away
[17:48] <LocutusOfBorg> he Jammy Jellyfish (supported)
[17:48] <LocutusOfBorg> ￼ 8.0.102-8.0.2-0ubuntu1~22.04.1	security, updates (universe)	20 hours ago
[17:48] <LocutusOfBorg> ￼ 8.0.100-8.0.0-0ubuntu1~22.04.1	proposed (universe)	2024-02-08
[17:49] <LocutusOfBorg> dotnet8 is higher on security and updates w.r.t. proposed :/
[17:52] <vorlon> also no one will ever install coreutils:i386 on a real system and if it's broken I don't care! :)
[17:57] <LocutusOfBorg> hey perl what is your problem?
[18:06] <LocutusOfBorg> ruby-defaults migrated, I would have expected perl to be in that list...
[18:08] <tsimonq2> Implicit dependency: qtbase-opensource-src pyside2 (not considered) - oh come on Britney, so close :)
[18:26] <vorlon> hey perl> digging up https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper to try to answer this
[19:09] <vorlon> fwiw I mis-drove update-output-helper on the first go around (needs a list of packages with versions and not just packages and I drove my shell wrong), now waiting again for it to regenerate the list from slow rmadison calls
[19:09] <vorlon> afk now for a bit
[19:20] <vorlon> $ ./update-output-helper $list
[19:20] <vorlon> grep-dctrl: filter is too long.
[19:20] <vorlon> fail
[19:48] <Eickmeyer> vorlon or any ubuntu-archive: If you have a quick cycle to let the new ubuntucinnamon-meta with the minimal binary through, that would be greeeeeat. :)
[20:01] <mwhudson> vorlon: apparently i was not
[20:06] -queuebot:#ubuntu-release- New binary: yade [arm64] (noble-proposed/universe) [2024.02a-1] (no packageset)
[20:20] -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [amd64] (noble-proposed/main) [31.1] (core)
[20:21] -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [armhf] (noble-proposed/main) [31.1] (core)
[20:21] -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [s390x] (noble-proposed/main) [31.1] (core)
[20:21] <jbicha> glusterfs is part of the perl transition because of uwsgi. glusterfs needs its armhf package removed LP: #2052734 but tgt has failed to build on arm64 & riscv64
[20:21] -ubottu:#ubuntu-release- Launchpad bug 2052734 in glusterfs (Ubuntu) "Please remove glusterfs on armhf" [Undecided, Incomplete] https://launchpad.net/bugs/2052734
[20:22] -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [ppc64el] (noble-proposed/main) [31.1] (core)
[20:29] -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [arm64] (noble-proposed/main) [31.1] (core)
[20:38] -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [riscv64] (noble-proposed/main) [31.1] (core)
[20:46] -queuebot:#ubuntu-release- New binary: yade [amd64] (noble-proposed/universe) [2024.02a-1] (no packageset)
[20:50] <vorlon> Eickmeyer: not me today; head down on getting these massive migrations through into the release pocket and then pivoting to the time_t stuff again
[20:52] -queuebot:#ubuntu-release- New: accepted yade [amd64] (noble-proposed) [2024.02a-1]
[20:52] -queuebot:#ubuntu-release- New: accepted yade [arm64] (noble-proposed) [2024.02a-1]
[20:58] <Eickmeyer> vorlon: Ah, fun. No worries.
[21:01] <cpete> posting again with the right pings (cc: ubuntu-release) So ros-ros-comm is the final blocker for the tinyxml2 transition and is one of the blockers in the python3-defaults transition, mainly due to usage of now deprecated unittest code in python3.12. I've been working on a patch to update the test code, but between the growing complexity of the patch and the question of if we even want to ship these packages in noble, I think we
[21:01] <cpete> should just hint it.  Wdyt?
[21:35] <ginggs> cpete: I don't see ros-ros-comm at all on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html
[21:36] <ginggs> I did retry an autopkgtest failure blocking python3.12 (not python3-defaults) yesterday, which passed
[21:36] <ginggs> https://autopkgtest.ubuntu.com/packages/ros-ros-comm/noble/ppc64el
[21:38] <ginggs> cpete: what are you looking at?  https://ubuntu-archive-team.ubuntu.com/transitions/html/auto-tinyxml2.html ?
[22:28] <dbungert> ginggs: that is indeed a green checkmark but the log looks strange at the end
[22:35] <ginggs> dbungert: the repeated "Creating nova instance..." lines?
[22:35] <dbungert> yes
[22:35] <ginggs> even the result from 2023-10-08 18:29:09 UTC has that
[22:51] <vorlon> ... how did libsys-virt-perl autopkgtest regress since the last britney run
[22:52] <vorlon> because of the britney "try against all packages in -proposed at once" heuristic yaaaay
[22:52] <vorlon> skiptesting perl
[23:03] <bdmurray> ginggs, dbungert: The "Creating nova instance..." is usual noise. I suspect that gets logged last but for reasons.
[23:20] <ginggs> vorlon: i think that particular combination had never been run before (or britney can't see the results)
[23:21] <vorlon> ginggs: yes but we don't actually want or care about that combination, this is a britney misfeature
[23:21] <ginggs> i've been retrying the autopkgtests with 'unknown' versions as they've been appearing for the last few hours
[23:22] <ginggs> (and the last week)
[23:22] <vorlon> it's a useful optimization for britney to try "test this package against all relevant triggers in -proposed and see what happens" but it shouldn't do that for a package in -proposed that it ALREADY tested with and it DEFINITELY shouldn't move a test result for that -proposed package from success to fail as a result
[23:22] <vorlon> so the skiptest hint I've added should undo this
[23:22] <vorlon> any further tests britney logs as failures against perl are wrong tests
[23:23] <cpete> ginggs: sorry for the delay, yes the ubuntu-archive-team.ubuntu.com link is what I was looking at
[23:25] <ginggs> vorlon: well you did roll back libsys-virt-perl, and the last pass was with 10.0.0-1 https://autopkgtest.ubuntu.com/packages/libs/libsys-virt-perl/noble/arm64
[23:25] <ginggs> but i agree with the skiptest hint :)
[23:25] <vorlon> ginggs: I rolled it back 7 hours ago and britney didn't think it was a blocker for 6 of those hours
[23:26] <ginggs> cpete: so what's needed there is a no-change rebuild of ros-ros-comm and ros-diagnostics to pick up a dependency on libtinyxml2-10 instead of libtinyxml2-9
[23:26] <cpete> Ah well they both are on that domain, but it was the tinyxml transition
[23:28] <cpete> gotcha, for the tinyxml2 case that sounds good
[23:28] <vorlon> only took 9 years to do something about https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/+merge/267970 ...
[23:28] <cpete> ginggs: but it definitely won't build with python3.12
[23:49] <ginggs> Migration status for perl (5.36.0-10ubuntu1 to 5.38.2-3): Will attempt migration (Any information below is purely informational)
[23:50] <cpete> ginggs: Ah, the build tests for ros-ros-comm are slighly different on amd64 (and also different from the autopkgtests). So as long as it doesn't have to rebuild against python3.12 it should be fine
[23:51] <ginggs> cpete: i think it will, because python3-defaults in proposed says python3.12 is the default
[23:53]  * ginggs has a rolling blackout schedule in ~6 minutes
[23:54] <ginggs> which is probably a good thing, as I should get some sleep
[23:56] <cpete> ginggs: Sounds good, we can take care of this tomorrow.
[23:56] -queuebot:#ubuntu-release- New sync: budgie-session (noble-proposed/primary) [0.9.1-1]
[23:57] <jbicha> Budgie needs budgie-session, thanks ^