[00:33] <vorlon> arraybolt3: you reported test results for kubuntu 20.04.5 on http://iso.qa.ubuntu.com/qatracker/milestones/438/builds/257634/testcases/1301/results; did you follow the test case saying to click on the release notes hyperlink and confirm it launches?  It doesn't work for me on focal daily
[00:35] <arraybolt3> Shoot... no, I didn't. I almost certainly went on autopilot and did testing for Kubuntu the same way I do it for Lubuntu, where that isn't part of the instructions.
[00:35] <arraybolt3> It opens a Kate window right?
[00:35] <vorlon> it currently does nothing
[00:35] <arraybolt3> That's what it used to do for me the times I clicked that link.
[00:35] <arraybolt3> Oh. For me it always opened a Kate window before.
[00:36] <vorlon> ok then I should cross-check against 20.04.5
[00:36] <arraybolt3> Maybe, lemme see if I have the ISO here.
[00:36] <arraybolt3> I don't have Focal, so yeah, it will probably be faster if someone other than me does it.
[00:36] <arraybolt3> (I don't have the ISO I mean.)
[00:37] <arraybolt3> Sorry about that, I will look at the testcases more closely for future testing.
[00:38] <arraybolt3> The times I tested before were on Jammy, so it's entirely possible that the feature is broken on Focal entirely, I don't think I've ever tested the release notes on Focal.
[00:40]  * arraybolt3 wget's the new Desktop ISO
[00:48] <vorlon> confirmed, same behavior w/ kubuntu release notes in .5
[00:53] <vorlon> mwhudson, dbungert: twice now with ubuntu-server focal daily, subiquity has stalled at the 'probing for disks' stage.  Going back and forward again clears the error
[00:55] <Eickmeyer> sil2100: ope, Ubuntu Studio should've been opted-out of Focal 20.04.6 since it's so close to EOL for Studio Focal (3 years), just seems silly to release a new image just to retire it in a month.
[00:56] <sil2100> Eickmeyer: ah, ok, that's fine
[00:56] <vorlon> Eickmeyer: thanks, we can drop it from the list
[00:56] <sil2100> +1
[00:56] <Eickmeyer> I just marked it as disabled.
[00:56]  * arraybolt3 is having trouble getting my testing laptop to boot...
[00:57] <vorlon> I've disabled ubuntustudio on the series manifest
[00:57] <Eickmeyer> vorlon: Thanks
[00:58] <sil2100> vorlon: I kicked the focal source build now as well o/
[00:58] <vorlon> sil2100: cheers
[00:58] <Eickmeyer> sil2100: Thanks! And, don't lose too much sleep.
[00:58] <sil2100> No worries, vorlon's got it all covered
[00:58] <arraybolt3> (boot problems are a hardware issue, nothing wrong with the ISOs)
[00:58] <arraybolt3> *my boot problems, I mean
[00:58] <sil2100> I'm just here out of curiosity!
[00:59] <Eickmeyer> Haha
[01:18] <arraybolt3> Well, tar. My testing is going to be limited to virtual machines and maybe Chromebooks, since my primary testing machine has an intermittent hardware fault that has decided to rear its head today.
[01:19] <sarnold> :(
[01:19] <arraybolt3> Anyway, I guess I'll use VBox for testing since others are likely already using QEMU-based VMs for testing.
[01:21] <vorlon> arraybolt3: if you find any images that don't have explicit UEFI test cases, let me know.  Every image should get at least one smoke test on an appropriately-configured UEFI system to ensure it actually has the right boot bits and nothing got missed
[01:21] <arraybolt3> vorlon: Will do. I think GNOME Boxes should let me test UEFI Secure Boot properly, I'll make sure and if so I'll use that for doing said smoke testing.
[01:22] <vorlon> arraybolt3: note the SecureBoot test case listed in https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/2009078
[01:22] -ubottu:#ubuntu-release- Launchpad bug 2009078 in debian-installer (Ubuntu Focal) "rebuild debian-installer against current boot stack (SecureBoot security updates / revocations)" [Undecided, Fix Released]
[01:22] <dbungert> vorlon: I haven't been able to reproduce getting blocked on probing, any speculation on what we might be doing differently?
[01:23] <vorlon> dbungert: nope.  Is there something you want me to look at in the logs?
[01:23] <vorlon> dbungert: it didn't happen the first few times I tested.  It happened the first time when I added a second disk for RAID; but then I deleted that disk again and it still happened
[01:24] <dbungert> vorlon: ok, I'll try multi disk.  Not sure what to look for in the logs, a pastebin of the subiquity-server-debug.log would be nice
[01:25] <vorlon> dbungert: ok.  I'm doing a kubuntu install now and then going to dinner, but I'll try to dig that up this evening
[01:32] <jbicha> arraybolt3: btw, the EFI option in Boxes breaks the Boxes Snapshot feature (in case you were curious why the buttons didn't seem to work) https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/920
[01:32] -ubottu:#ubuntu-release- Issue 920 in GNOME/gnome-boxes "EFI option silently breaks snapshots" [Opened]
[01:33] <arraybolt3> jbicha: Interesting, never noticed that (I hardly ever use snapshots, sometimes to my detriment...).
[01:33] <arraybolt3> I decided to go for virt-manager though since it lets me do more involved configuration which is handy for booting different ISOs on the same VM.
[01:34] <arraybolt3> I just noticed a *possible* graphical regression when booting 20.04.6 in VBox - the "Checking disks" prompt at the beginning renders in a weird way. I'll check to see if it's an actual regression and report it if so.
[01:36] <arraybolt3> https://i.imgur.com/fEXmyiP.png (is what I'm seeing)
[03:03] <arraybolt3> Nice, it's not a regression. The behavior of the graphical weirdness has changed a bit, but it's not a regression, at least not on a 800x600 screen.
[04:57] <arraybolt3> Only MATE and Budgie still need UEFI smoke testing - I've done Desktop, Xubuntu, and Kylin, and it looks like everyone else beat me to Kubuntu.
[04:58] <arraybolt3> (everyone else, i.e. vorlo'n)
[04:58] <arraybolt3> I'll snag MATE next since it's probably smaller than Budgie and therefore should download faster.
[05:00] <arraybolt3> Also the MATE download link on the ISO tracker is broken.
[05:00] <vorlon> hmm shouldn't be, the link looks correct
[05:01] <arraybolt3> vorlon: It's missing a "focal".
[05:01] <vorlon> oh
[05:01] <arraybolt3> It's pointing to the Lunar image directory.
[05:01] <arraybolt3> (lol, the MATE image is a gigabyte *bigger* than Budgie. Didn't expect that.)
[05:01] <vorlon> yeah I can take a look at fixing that after I finish this last Kubuntu test
[05:04] <vorlon> heh somehow xenial,bionic,jammy have correct download links for mate but focal was missed
[05:06] <vorlon> http link fixed
[06:39] -queuebot:#ubuntu-release- New binary: ubiquity-slideshow-ubuntu [amd64] (lunar-proposed/main) [188] (ubuntu-desktop)
[07:25] -queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (lunar-proposed/main) [23.04.1] (desktop-core)
[07:28] <LocutusOfBorg> please unblacklist meson autopkgtests
[07:28] <LocutusOfBorg> I did upload 1.0.1-5ubuntu1 with fixes and additional logs for the disk space full issue
[07:31] <arraybolt3> Every flavor of Ubuntu that is part of the 20.04.6 release has been smoke-tested in a Secure Boot UEFI environment that refuses to boot a 20.04.5 ISO. I just finished the last one.
[07:49] <ginggs> arraybolt3: thank you!
[07:50] <arraybolt3> Glad to help!
[07:56] <ginggs> LocutusOfBorg: meson/armhf/lunar removed from never_run
[08:05] <arraybolt3> UIF-related question, if I upload a package *before* the freeze, and Britney migrated it out *after* the freeze, that's still allowable, right? Just like we do for FF?
[08:06] <arraybolt3> (Asking because there's a last-minute change for the UI that I intend to push to Lubuntu and need to know if I should push it right now or if it's OK to wait until after I wake up.)
[08:08] <arraybolt3> nvm, I'm realizing it's probably a good idea to push it now.
[08:32] -queuebot:#ubuntu-release- New: accepted ubiquity-slideshow-ubuntu [amd64] (lunar-proposed) [188]
[08:32] -queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (lunar-proposed) [23.04.1]
[08:33] <seb128> arraybolt3, yes, upload time is what counts, not when it migrates
[08:33] <LocutusOfBorg> thanks ginggs I'll update as soon as I have feedbacks on the test
[08:34] <LocutusOfBorg> vorlon, I stole your ugene diff on Debian tracker and uploaded :) libprocps-dev can be NBS cleanup in some hours
[08:36] <LocutusOfBorg> interestingly somebody NBS cleaned it up with ugene depending on it...
[08:39] <ginggs> LocutusOfBorg: ugene did not depend on libprocps8
[08:46] <LocutusOfBorg> ginggs, build-depend on libprocps-dev
[08:47] <LocutusOfBorg> in fact, removing the build-dependency and uploading was the fix
[08:54] -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-510-server from i386-whitelist in lunar
[08:54] -queuebot:#ubuntu-release- Packageset: Added argyll to i386-whitelist in lunar
[08:54] -queuebot:#ubuntu-release- Packageset: Added jam to i386-whitelist in lunar
[08:54] -queuebot:#ubuntu-release- Packageset: Added libstring-license-perl to i386-whitelist in lunar
[09:18] <sil2100> tjaalton: hey! I see you submitted an FFe for mesa 23.0.1 last week - how's that looking?
[09:19] <tjaalton> sil2100: it hasn't been released yet
[09:19] <tjaalton> but having a pre-ack would allow me to upload once it arrives
[09:19] <tjaalton> 23.0.1 is way overdue
[09:20] <tjaalton> been four weeks since .0 came out
[09:32] <sil2100> tjaalton: ouch, man. I thought it would be already released last week
[09:36] <tjaalton> should happen today, their CI is slow
[09:36] <tjaalton> or having some issues, dunno
[09:54] <ricotz> tjaalton, hi :), would you still be available to look at the libreoffice SRU?
[10:00] <ginggs> LocutusOfBorg: 1.0.1-5ubuntu1 	meson/1.0.1-5ubuntu1 	2023-03-15 09:58:07 UTC 	0h 31m 41s 	- 	pass
[10:00] <ginggs> ^ for lunar/armhf
[10:09] <LocutusOfBorg> yay
[12:47] -queuebot:#ubuntu-release- Unapproved: accepted dotnet6 [source] (kinetic-proposed) [6.0.114-0ubuntu1~22.10.1]
[12:56] -queuebot:#ubuntu-release- Unapproved: accepted dotnet6 [source] (jammy-proposed) [6.0.114-0ubuntu1~22.04.1]
[13:32] -queuebot:#ubuntu-release- Unapproved: accepted dotnet7 [source] (kinetic-proposed) [7.0.103-0ubuntu1~22.10.1]
[13:41] -queuebot:#ubuntu-release- Unapproved: glance (kinetic-proposed/main) [2:25.0.0-0ubuntu1.1 => 2:25.1.0-0ubuntu1] (openstack)
[13:42] -queuebot:#ubuntu-release- Unapproved: neutron (kinetic-proposed/main) [2:21.0.0-0ubuntu1 => 2:21.1.0-0ubuntu1] (openstack)
[13:43] -queuebot:#ubuntu-release- Unapproved: glance (jammy-proposed/main) [2:24.1.0-0ubuntu1.1 => 2:24.2.0-0ubuntu1] (openstack)
[14:30] <vorlon> LocutusOfBorg: ah fwiw I already did the NBS cleanup of libprocps-dev, because while I submitted a diff for ugene build-deps, I guess you'll have also seen that it FTBFS (a pre-existing issue seen on the rebuild test)
[14:30] <vorlon> LocutusOfBorg: so removing libprocps-dev first doesn't regress ugene in the release pocket
[14:37] <LocutusOfBorg> vorlon, the FTBFS is already fixed :D
[14:37] <LocutusOfBorg> I though you had forgot to upload it, this is why I pinged
[14:42] <vorlon> ack
[14:51] <ricotz> hello SRU team, please accept libreoffice/kinetic https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2009354
[14:51] -ubottu:#ubuntu-release- Launchpad bug 2009354 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.6 for kinetic" [High, Incomplete]
[15:01] -queuebot:#ubuntu-release- Unapproved: ceph (jammy-proposed/main) [17.2.5-0ubuntu0.22.04.1 => 17.2.5-0ubuntu0.22.04.2] (ubuntu-server)
[15:02] -queuebot:#ubuntu-release- Unapproved: ceph (kinetic-proposed/main) [17.2.5-0ubuntu0.22.10.1 => 17.2.5-0ubuntu0.22.10.2] (ubuntu-server)
[15:02] <seb128> I tried to trigger a rebuild for the Ubuntu lunar daily through the ISO tracker some hours ago but it's not showing up on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/lunar/ubuntu for some reason
[15:02] <seb128> could someone from the release team trigger one?
[15:15] <vorlon> seb128: is this legacy or subiquity?
[15:16] <vorlon> seb128: my guess is the failure to trigger is related to my unpleasant cowboy to post daily-live images for 20.04.4 under the 'Legacy' product even though daily-live isn't legacy for lunar
[15:16] <vorlon> (done so that it posts to the right place to get the relevant test suites for that image)
[15:16] <seb128> vorlon, yes, daily-live is the new installer
[15:17] <vorlon> seb128: so you want the daily-live image built - ok building
[15:17] <vorlon> it still won't post to the right place on the iso tracker, but, well
[15:17] <vorlon> this is a problem we should plan to sort out better for the future, since it will also affect 22.04 point releases
[15:22] <seb128> vorlon, thanks
[15:22] <seb128> vorlon, oh, is that why the 'Ubuntu Desktop amd64 (re-building)' entry on http://iso.qa.ubuntu.com/qatracker/milestones/441/builds has a version from yesterday despite the fact we had a daily build this morning
[15:23] <bdmurray> ginggs: why was meson/armhf/linux removed from never_run?
[15:25]  * bdmurray does some detective work and finds out
[15:25] <vorlon> seb128: yes
[15:26] <ginggs> bdmurray: i thought the commit message was clear
[15:26] <vorlon> seb128: we probably need to extend the file format to include a 'series' field like a lot of the other config files do :/
[15:26] <bdmurray> ginggs: I was just reading scrollback not actually looking at other things.
[15:27] <bdmurray> Is it possible a test with the previous version will get triggered?
[15:28] <ginggs> bdmurray: possible if someone tries a migration-reference before the new meson migrates
[15:33] <vorlon> I am planning to quiesce proposed-migration for a couple of hours today for the final cutover from snakefruit to ubuntu-archive-toolbox.  A 1-2 hour gap in proposed-migration output is nothing extraordinary so I don't expect this to have significant impact on development (and it shouldn't matter for the in-flight 20.04.6 which hopefully won't need any more packages uploaded anyway!) but just a
[15:33] <vorlon> heads-up
[15:34] <jbicha> ubuntu-release: could you figure out what's going wrong with the libreoffice/lunar-proposed i386 autopkgtest? It's shown as running despite being denylisted. Also it looks like the test keeps being triggered according to the test history
[15:38] <vorlon> bdmurray, paride: ^^
[15:43] <bdmurray> jbicha: shows as running where? I'm not seeing it a.u.c/running
[15:44] <jbicha> bdmurray: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libreoffice
[15:44] <vorlon> that says that britney is waiting for results, not that it's running
[15:45] <vorlon> the denylist causes britney's request for the test to disappear into the ether
[15:45] <vorlon> but britney separately needs to know not to wait for it
[15:53] <vorlon> jbicha, bdmurray: I've added a badtest hint for libreoffice now (with an extensive commit message)
[16:01] <ricotz> vorlon, it this a typo? "i386w"
[16:01] <vorlon> ricotz: sure is!
[16:02] <ricotz> I am wondering why libreoffice is that special here, aren't there other packages having autopkgtest but no i386 binaries?
[16:04] <vorlon> ricotz: yes. Per the commit message, it's the fact that the denylist will prevent us from ever getting a migration-reference run that britney will honor
[16:05] <ricotz> vorlon, ok, if it weren't on this denylist, then what?
[16:06] <ricotz> the libreoffice debian/control file doesn't list i386 as supported why is it even considered still?
[16:07] <vorlon> ricotz: then autopkgtest generates a result that proposed-migration can pick up and use to reset its understanding of the baseline.
[16:08] <vorlon> ricotz: because the implementation can't tell the difference between arch: all and arch: any packages wrt what needs to be tested.  Libreoffice has binaries published in the i386 Packages file which are Architecture: all
[16:09] <ricotz> I see, although isn't arch-all handled by amd64 for a long time already
[16:09] <vorlon> that's not the point
[16:10] <vorlon> autopkgtests for Architecture: all packages run on ALL architectures
[16:10] <vorlon> because the fact that there's no arch-dependent code does not mean that the package doesn't have to work on non-amd64 architectures
[16:11] <ricotz> ok, still weird that there aren't a whole lot of other packages suffering from this condition
[16:11] <vorlon> no it isn't
[16:12] <vorlon> this package was explicitly blacklisted
[16:13] <ricotz> hmm, git grep force-badtest | grep i386 | wc -l == 9
[16:18] -queuebot:#ubuntu-release- New source: gcr4 (lunar-proposed/primary) [4.1.0-0ubuntu1]
[16:31] <seb128> is there a known issue 'blocked in proposed for <n> days' emails?
[16:31] <seb128> I've some people who told me they didn't get notified recently that their uploads were stucked in proposed
[16:32] -queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.4-4ubuntu3.20 => 245.4-4ubuntu3.21] (core, i386-whitelist)
[16:33] <arraybolt3> seb128: I personally have never gotten an email like that even when my uploads have gotten stuck.
[16:33] <arraybolt3> I didn't even know that was a thing.
[16:35] <seb128> vorlon, ^ is that a potential regression from the migration you are working on?
[16:36] <seb128> arraybolt3, weird
[16:36] <arraybolt3> LocutusOfBorg: Please do not sync LXQt packages from Debian into Ubuntu. Lubuntu and the Debian LXQt Team are having disagreements and are currently maintaining LXQt separately. Every sync from Debian means more work for the Lubuntu team to revert the sync and return things to the state Lubuntu should be in.
[16:37] <arraybolt3> (In particular, I now need to fix the watch file and version deps and review the patch for lxqt-session.)
[16:38] <arraybolt3> We do intend on eventually resolving the disagreements so that hopefully this isn't a problem anymore.
[16:40] <arraybolt3> *dep versions
[16:46] <LocutusOfBorg> arraybolt3, some parts of the delta were just wrong, e.g.
[16:46] <LocutusOfBorg> -               liblxqt1-dev (>= 1.2.0),
[16:46] <LocutusOfBorg> +               liblxqt1-dev (>= 1.2.0~),
[16:47] <LocutusOfBorg> the version in Debian packaging with ~ is better than the Ubuntu part
[16:47] <LocutusOfBorg> the package needed some care and patches, that were already in Debian
[16:47] <arraybolt3> Perhaps. But there's still the point that there is extra work to be done now. We could have pulled that in ourselves when we were ready.
[16:47] <LocutusOfBorg> arraybolt3, ack
[16:48] <arraybolt3> Sorry, this is a weird situation, and hopefully this will end up going away in the future.
[16:48] <LocutusOfBorg> btw I kept the Ubuntu specific patches, I didn't plain sync
[16:58] <vorlon> seb128: I have heard reports of the email notifications about stuck packages not going through.  They all go through for me (and I tend to get a lot of them due to no-change rebuilds).  But other mail providers may be dropping them / not delivering them and there's not much I can do about that (and I'm not signing up to fight gmail's filtering)
[16:58] <arraybolt3> LocutusOfBorg: That's good, maybe this isn't as "oh no!" as I thought. (We had one time where the whole stack accidentally got synced. That may have made me a bit... protective :P)
[16:59] <arraybolt3> Anyway, I needed to audit that package anyway for copyright file reasons, so I guess this is a good push into doing that.
[17:01] -queuebot:#ubuntu-release- Unapproved: nova (kinetic-proposed/main) [3:26.1.0-0ubuntu1 => 3:26.1.0-0ubuntu2] (openstack)
[17:12] <seb128> vorlon, alright, thanks
[17:17] <vorlon> arraybolt3: ^^ anyway you can check whether you have any mails in your gmail spam box
[17:17] <vorlon> schopin: LP: #2006739> December 2011? Not a typo?
[17:17] -ubottu:#ubuntu-release- Launchpad bug 2006739 in glibc (Ubuntu) "[FFe] Include Memory Tagging Extension support in the arm64 glibc build" [Medium, Triaged] https://launchpad.net/bugs/2006739
[17:18] <arraybolt3> vorlon: Not in spam, but I am using Gmail.
[17:18] <seb128> vorlon, Jeremy confirmed that for him gmail had put them in spam
[17:18] <arraybolt3> They just aren't coming through at all.
[17:18] <arraybolt3> (I clear my spam regularly.)
[17:18] <schopin> vorlon: erm. typo. That should be 2021.
[17:19] <seb128> Till also said he hasn't those in his spams
[17:20] <cjwatson> We probably need to get IS to set up DKIM signing for those
[17:21] <cjwatson> Assuming they're already going via one of the modern relays
[17:21] <vorlon> yeah.  gmail sometimes decides to accept mail but drop it from delivery and not give the user any way to find it.  Or they might be giving an error from Canonical's outbound mail server that I don't see.  And what Colin said
[17:21] <vorlon> I can tune it to make sure we're using best internal practices for the mail, but I can't control gmail's hostility to mail
[17:21] <cjwatson> If somebody has one of the emails in question with full headers, I suggest running it through dkimproxy-verify to see what it says
[17:22] <vorlon> I delete them after receipt so I don't have any to reference currently and it's hard to intentionally trigger the conditions for their sending :)
[17:22] <vorlon> I'll watch out for the next one, but er today I'm also switching the server they're sent from soooooo
[17:23] <vorlon> schopin: you shouldn't set FFe requests triaged yourself, we use that for workflow management of the FFes themselves
[17:23] <cjwatson> Oh, that in itself might help, of course, depending on what the mail relay situation is for snakefruit vs. u-a-t
[17:24] <vorlon> IS had us specifically switch to noreply+proposed-migration@ubuntu.com as the sender a while ago specifically for integrating with the modern policies
[17:25] <vorlon> so switching servers *shouldn't* make it better or worse
[17:25] <cjwatson> Right
[18:11] <dbungert> vorlon: I tried a few variations of the probe test you mention hung, I haven't seen that yet.  If you have a moment, a retest with 20.04.5 would be nice.
[18:51] <vorlon> dbungert: ok.  I'm afk for a bit right now, and then I'm working on ubuntu-archive-toolbox.internal, but I should have time to look at this today.  It's not high priority from my side if you can't reproduce it, so don't worry over much on your side, but I will be sure to follow through
[18:51] <dbungert> vorlon: ack
[19:37] <kanashiro[m]> ubuntu-archive: could I get someone to promote mosh to main? LP: #1997106
[19:37] -ubottu:#ubuntu-release- Launchpad bug 1997106 in mosh (Ubuntu) "[MIR] mosh" [Undecided, In Progress] https://launchpad.net/bugs/1997106
[19:37] <sarnold> \o/
[19:57] <vorlon> kanashiro[m]: a) mosh is not seeded, we should see it on https://ubuntu-archive-team.ubuntu.com/component-mismatches.html before it gets promoted; b) 'in progress' is not 'fix committed' so at a glance the MIR is not done yet
[19:57] <vorlon> quiescing proposed-migration now for the cutover
[20:11] <kanashiro[m]> vorlon: ok, it should show up as a component mismatch soon (it was committed in seeds). And the bug status I did not touch, this was redirected by me as already approved and towards promotion (requiring seeds change and poking an AA), I do not know if it would be ok for me to change the status to Fix Committed, AFAICS it was approved by the MIR and security team
[20:11] <vorlon> kanashiro[m]: yes, it's for the MIR team to move it to fix committed; if they haven't done so you should poke them as to why
[20:11] <vorlon> but I won't action a MIR promotion until it is
[20:12] <kanashiro[m]> ack
[20:13] <kanashiro[m]> slyon: since you reviewed and approved the mosh MIR could you please check the status of the bug and set it accordingly? LP: #1997106
[20:13] -ubottu:#ubuntu-release- Launchpad bug 1997106 in mosh (Ubuntu) "[MIR] mosh" [Undecided, In Progress] https://launchpad.net/bugs/1997106
[20:34] <vorlon> proposed-migration finished, final sync from snakefruit is done; turning off the dry-run mode on u-a-t and turning the jobs back on
[20:46] <vorlon> found a bug specific to the autopkgtest queuing from p-m; rolling back
[22:00] <vorlon> sorry, had a few things come up so haven't actually rolled p-m back to snakefruit yet - but IS installed the missing dependency so trying again
[22:11] <vorlon> amqp connection failing from britney but this time not because of a missing package dep.  going to see if I can figure this out, p-m offline still for a bit while I debug
[22:20] <vorlon> aha firewall issue
[22:21] <vorlon> still trying to work through this and see if I can get it done in short order so that we don't have to rollback
[22:47] <vorlon> firewall sorted, trying again
[22:57] <vorlon> it's running, autopkgtest requests are not failing on the client side
[22:57] <vorlon> and https://autopkgtest.ubuntu.com/running#queue-huge-lunar-s390x shows them - we're in business
[23:26] <vorlon> ok things are live now!  https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html shows the first successful run on ubuntu-archive-toolbox
[23:27] <vorlon> for the moment there will be some publication delays because there's a frontend that only syncs data every hour @ :17.  Now that things are up I'm going to work on moving that to an ssh trigger so that we don't have delays seeing the output
[23:29] -queuebot:#ubuntu-release- Unapproved: squid (kinetic-proposed/main) [5.6-1ubuntu3 => 5.6-1ubuntu3.1] (ubuntu-desktop, ubuntu-server)