[03:36] <kc2bez> sil2100, juliank, jibel and mwhudson, re: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1861912 I can confirm if there is sufficient space install alongside works as intended. The bug seems to be a lack of warning/exit if there is not.
[03:36] <kc2bez> I have update the bug with the same findings.
[04:51] -queuebot:#ubuntu-release- New: accepted stk [amd64] (focal-proposed) [4.6.1+dfsg-3]
[04:51] -queuebot:#ubuntu-release- New: accepted stk [armhf] (focal-proposed) [4.6.1+dfsg-3]
[04:51] -queuebot:#ubuntu-release- New: accepted stk [ppc64el] (focal-proposed) [4.6.1+dfsg-3]
[04:51] -queuebot:#ubuntu-release- New: accepted stk [arm64] (focal-proposed) [4.6.1+dfsg-3]
[04:51] -queuebot:#ubuntu-release- New: accepted stk [s390x] (focal-proposed) [4.6.1+dfsg-3]
[04:51] -queuebot:#ubuntu-release- New: accepted stk [i386] (focal-proposed) [4.6.1+dfsg-3]
[05:22] -queuebot:#ubuntu-release- New binary: nvidia-settings-tesla-418 [amd64] (focal-proposed/multiverse) [418.113-2] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: nvidia-settings-tesla-418 [ppc64el] (focal-proposed/multiverse) [418.113-2] (no packageset)
[06:22] -queuebot:#ubuntu-release- New source: gcc-10-cross (focal-proposed/primary) [3ubuntu1]
[06:25] -queuebot:#ubuntu-release- New source: gcc-10-cross-ports (focal-proposed/primary) [2ubuntu1]
[06:26] -queuebot:#ubuntu-release- New: accepted gcc-10-cross-ports [source] (focal-proposed) [2ubuntu1]
[06:26] -queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-418 [amd64] (focal-proposed) [418.113-2]
[06:26] -queuebot:#ubuntu-release- New: accepted gcc-10-cross [source] (focal-proposed) [3ubuntu1]
[06:26] -queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-418 [ppc64el] (focal-proposed) [418.113-2]
[08:21] -queuebot:#ubuntu-release- New binary: gcc-10-cross-ports [ppc64el] (focal-proposed/universe) [2ubuntu1] (i386-whitelist)
[10:08] <RikMills> Laney: is it possible to reset the baselines on the pyside2 tests. listed as a regression but in fact never passed http://autopkgtest.ubuntu.com/packages/p/pyside2/focal/amd64
[10:10] <Laney> we can't do that until we merge a branch from juliank
[10:11] <juliank> Oh that branch needs rework I think
[10:11] <juliank> I looked at it recently
[10:12] <Laney> probably would be a good idea to do it I think
[10:12] <Laney> so if you get a chance
[10:15] <RikMills> right. ok
[10:15] <Laney> RikMills: so have to hint it I'm afraid
[10:15] <juliank> Laney: Do you remember where it is?
[10:16] <Laney> haha
[10:16] <Laney> probably in your britney2-ubuntu fork
[10:16] <juliank> yes, thanks, Laney
[10:17] <RikMills> Laney: fair enough. thanks
[10:35] <juliank> Laney: ah reading my merge proposal, you reworked it in https://code.launchpad.net/~laney/britney/+git/britney2-ubuntu/+ref/force-reset-test
[10:36] <Laney> don't really remember doing that
[10:36] <juliank> Then you asked Any comments or should I just merge this??
[10:36] <Laney> but I believe what I see :-)
[10:36] <juliank> https://code.launchpad.net/~juliank/britney/+git/britney2-ubuntu/+merge/344902
[10:36] <juliank> I'd say yes
[10:36] <Laney> you think it's ok?
[10:36] <juliank> Laney: lgtm
[10:36] <juliank> Laney: ship it
[10:37] <Laney> 🤷
[10:37] <Laney> YOLO
[11:37] <Laney> juliank: ok, pushed, let's try it with pyside2 then
[11:37] <juliank> wooohoo
[11:38] <Laney> your branch probably won't record as merged, I guess close that manually?
[11:39] <Laney> also, want to write a mail to ubuntu-release announcing the new hint type?
[11:40] <juliank> I probably can't post there, it'd just be stuck in moderation?
[11:40] <Laney> it's an open list
[11:40] <Laney> well, probbably subscribers only
[11:40] <Laney> but anyone can subscribe
[11:42] <juliank> Let's see how well it works first :)
[11:42] <juliank> Or if it broke everything :D
[11:45] <Laney> heh
[11:45] <Laney> another run should start soon, so we can watch the log of that
[12:45] <Laney> juliank: can't see it live yet, but looks like it worked
[12:45] <Laney> pyside2 is showing as Always failed
[12:46] <juliank> sweet
[12:46] <juliank> time to go back in history and update all the other hints :)
[12:46] <juliank> e.g. aptdaemon's force-badtest and stuff
[12:46]  * juliank should submit a merge
[12:46] <Laney> yeah I dunno which ones should use this, happy to leave that to others to work out :-)
[12:52] <juliank> Laney: I hope people actually read ubuntu-release, I'm sending one out now
[12:52] <Laney> thanks, and the release team should
[12:52] <Laney> they're the main audience for this ...
[12:53] <juliank> I'm subscribed now too
[12:54] <juliank> Laney: I think there's a wiki page somewhere too explaining hints that needs updating, but I don't know for sure
[12:55] <Laney> ah could be
[12:57] <Laney> no results when searching wiki.ubuntu.com tho
[12:58] <cjwatson> I think I've fixed the problem where component-mismatches often didn't run: https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/revision/108 and https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-scripts/trunk/revision/267
[12:58] <cjwatson> I also stopped archive-reports mirroring ubuntu-rtm and the stable phone overlay, since neither has changed for years
[12:59] <Laney> ah good, happy to see the back of that mtime check
[13:08] <juliank> Next I should rework update_excuses to summarize passing tests
[13:08] <juliank> Possibly it should show only one passing test and all failures
[13:09] <juliank> Or you get one passed tests button that you click on and then it does weird javascript
[13:09] <juliank> or split up update_excuses by first letter of package name
[13:10] <coreycb> sil2100: hello, if you have time today could you take a look at 1826114 and 1858933 in eoan unapproved?
[13:22] <sil2100> coreycb: will try! Today is release day of .4 so I'll see how that goes o/
[13:23] <coreycb> sil2100: thanks and good luck
[13:23] <sil2100> jibel: do you think we're good from the desktop POV? Can you mark desktop as ready?
[13:33] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.4] has been marked as ready
[13:33] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.4] has been marked as ready
[13:38] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.4] has been marked as ready
[13:38] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.4] has been marked as ready
[14:13] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.4] has been marked as ready
[14:14] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.4] has been marked as ready
[14:14] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.4] has been marked as ready
[14:14] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.4] has been marked as ready
[14:14] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.4] has been marked as ready
[14:14] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.4] has been marked as ready
[14:19] <jibel> sil2100, yes, I think it's good.
[14:20] <jibel> sil2100, desktop marked as ready
[14:20] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.4] has been marked as ready
[14:30] <cpaelzer> Hi, I'm looking for an archive admin that can spent some minutes to resulve a bunch of things the server team has been waiting on
[14:30] <cpaelzer> I have everything prepared and read in MIRs, component-mismatches and such - but need someone with the permissions
[14:30] <cpaelzer> seb128: apw: sil2100: didrocks: ^^ highlighting those who should be online right now considering timezones
[14:31] <seb128> cpaelzer, which ones do you need moved and where?
[14:31] <cpaelzer> this is the overall todo list for me http://paste.ubuntu.com/p/D2TrSnKPhD/
[14:31] <cpaelzer> lets do them one by one here for coordination
[14:32] <cpaelzer> first
[14:32] <cpaelzer> - REMOVAL: bug 1862017 remove binary postgresql-11-rdkit (NBS)
[14:36] <msalvatore> What's the process for removing a package from the devel release? Moodle 3.0.3 is a 4 year old release. Moodle was removed from debian in 2017. Furthermore, it does not run in bionic or later because it requires php 5.4.4 or later or php7.0, but only php7.2 is available in bionic. https://moodle.org/mod/forum/discuss.php?d=364342
[14:36] <msalvatore> Ideally, moodle is removed from the devel release and replaced with an empty package for bionic and later.
[14:36] <cpaelzer> msalvatore: generally https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages
[14:36] <msalvatore> cpaelzer: thanks
[14:37] <seb128> cpaelzer, done
[14:37] <didrocks> seb128: need any ha?
[14:37] <didrocks> hand*
[14:38] <seb128> didrocks, I'm good but thx for asking
[14:38] <cpaelzer> thanks, second are two MIRs
[14:38] <seb128> cpaelzer, libpmem-dev ... do you need it in main?
[14:38] <cpaelzer> first of these
[14:38] <cpaelzer> MIR: bug 1790856 move to main: src:pmdk binaries: libpmem1 libpmem-dev
[14:38] <seb128> cpaelzer, just asking because you can build-depends on universe packages
[14:38] <cpaelzer> the rule I was told was - if it is not causing any problems then also move the -dev to main
[14:38] <cpaelzer> sometimes -dev have odd dependencies that cause issues, in this case it seems fine
[14:39] <seb128> wfm, worth case it shows up on component mismatch as to demote
[14:39] <didrocks> I always try to move -dev as well if there is no weird dep in it
[14:39] <seb128> done
[14:39] <cpaelzer> didrocks: that was exactly my approach
[14:39] <didrocks> (but I don’t think there are real rules we have written for this)
[14:39] <cpaelzer> thanks seb128
[14:39] <cpaelzer> next is the other MIR
[14:39] <cpaelzer> MIR: bug 1853506 src:ndctl + binaries: libdaxctl-dev libdaxctl1 libndctl-dev libndctl6 ndctl
[14:42] <seb128> cpaelzer, done
[14:42] <cpaelzer> thanks
[14:42] <cpaelzer> next is a demotion
[14:42] <cpaelzer> - DEMOTION: move to universe - binary libvirt-dev
[14:43] <seb128> done
[14:43] <cpaelzer> we changed the seed to Extra-Exclude libvirt-dev from auto-promotion - that is the reason it showed up
[14:43] <cpaelzer> seb128: The next two are dependent on changes that so far are only in -proposed - so if you prefer we might wait until qemu migrated (needed some of the things above to be resolved) and then do the remaining demotions to universe
[14:43] <cpaelzer> I'm not sure about the ordering here
[14:43] <cpaelzer> they are in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
[14:43] <seb128> cpaelzer, I can demote them in proposed, I don't remember how that's handled when it migrates though
[14:44] <cpaelzer> well, lets demote them in proposed then
[14:44] <cpaelzer> and I will recheck what happens once it migrated
[14:44] <seb128> +1
[14:44] <cpaelzer> does that soudn right?
[14:44] <cpaelzer> ok
[14:44] <cpaelzer> then next is
[14:44] <cpaelzer> - DEMOTION: move to universe - binary qemu-system-x86-xen
[14:45] <seb128> done
[14:45] <cpaelzer> ok, the next would be xen itself then
[14:45] <cpaelzer> - DEMOTION: move to universe - src:xen binaries libxen-4.9 libxen-dev libxenstore3.0
[14:46] <seb128> that one is only in focal and not showing on component-mismatch
[14:46] <seb128> so I guess to do once qemu migrates?
[14:46] <cpaelzer> ok, then keep it as is until qemu migrates
[14:46] <cpaelzer> yes
[14:46] <seb128> good
[14:46] <cpaelzer> I'll come back here
[14:46] <cpaelzer> there is one more as a bonus
[14:46] <cpaelzer> for you or didrocks
[14:46] <seb128> shoot :)
[14:46] <cpaelzer> openjpeg2: libopenjp2-7 libopenjp2-7-dev fir MIR 711061
[14:46] <seb128> that was done earlier
[14:46] <cpaelzer> I was part of that as MIR member not in any other way
[14:46] <cpaelzer> ah ok great
[14:47] <didrocks> I did it this morning, didn’t I?
[14:47] <didrocks> k
[14:47] <cpaelzer> it still is in the report
[14:47] <seb128> the report is 2 days old for some reason
[14:47] <didrocks> yep
[14:47] <cpaelzer> no it isn't
[14:47] <seb128> oh, no, it was this morning
[14:47] <seb128> it refreshed since, sorry :)
[14:47] <cpaelzer> cjwatson: did use his magic fix-all-powers
[14:47] <cpaelzer> now it is rather up to date again
[14:47] <seb128> great
[14:48] <cpaelzer> I'm done for now
[14:48] <cpaelzer> thanks seb128
[14:48] <didrocks> I think it’s due to cups which didn’t migrate yet
[14:48] <cpaelzer> I'll come back once qemu migrated to resolve the rest
[14:48] <didrocks> weird, I’ll double check
[14:48] <seb128> cpaelzer, np! thanks for having all the details lined up, it makes it easy :)
[14:48] <cpaelzer> np
[14:50] <didrocks> cpaelzer:  libopenjp2-7 | 2.3.1-1                        | focal                    | amd64, arm64, armhf, i386, ppc64el, s390x
[14:50] <didrocks> from ramdison
[14:51] <didrocks> rmadison* (grrr, can’t type on my new keyboard)
[14:52]  * seb128 wonders what this one is about
[14:52] <seb128>  libxcb (1.13.1-3build1 to 1.13.1-4) in proposed for 0 days
[14:52] <seb128>     Unsatisfiable depends:
[14:52] <seb128>         libxcb-xfixes0-dev.: amd64, arm64, armhf, i386, ppc64el, s390x
[14:52] <seb128> in proposed migration, but not showing on component-mismatch?
[14:56] <cpaelzer> xcb means nothing to me - I'm out on this one
[15:23] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.4] has been marked as ready
[15:23] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.4] has been marked as ready
[15:24] <Laney> juliank: imho we should rebase britney before adding much more divergence
[15:24] <juliank> sounds sensible
[15:25] <juliank> I guess I could  also do server-side post-processing of the html output
[15:26] <juliank> Or write a script that I can give a package name, it extracts the html for it, and then shows me in browser
[15:26] <juliank> oh, it could even follow chains
[15:26] <juliank> could run that locally
[15:26] <juliank> because waiting for excuses to load in browser and then search in there... that takes sometime
[15:26] <juliank> :D
[15:26] <juliank> s/sometime/some time/
[15:26] <Laney> cyphermo_x was working on some kind of excuses tool
[15:26] <Laney> using the yaml iirc
[15:27] <juliank> ah yes
[15:29] -queuebot:#ubuntu-release- New binary: gcc-10-cross-ports [arm64] (focal-proposed/universe) [2ubuntu1] (i386-whitelist)
[15:29] <xnox> seb128:  it's a typpo!
[15:29] <xnox> seb128:  note the dot
[15:29] <xnox> Depends: libxcb-xinput0 (= 1.13.1-4), libxcb1-dev, libxcb-xfixes0-dev.
[15:29] <xnox> and package 'libxcb-xfixes0-dev.' does not exist, only 'libxcb-xfixes0-dev' exists without a final dot
[15:30] <seb128> lol
[15:30] <seb128> xnox, thanks :)
[15:30] <seb128> tjaalton, ^
[15:30] <tjaalton> fixed already
[15:30] <seb128> ah
[15:30] <seb128> sorry :p
[15:30] <seb128> xnox, tjaalton, thx
[15:30] <tjaalton> -5 has the cross-test fix too
[15:30] <tjaalton> forgot to add it in -4
[16:44] <vorlon> rbalint: lp:~rbalint/britney/hints-ubuntu why are you bumping the i386 hint?  is systemd/i386 testable (in which case we should be fixing it so it passes), or not (in which case we should badtest all versions)?
[16:51] <rbalint> vorlon, i wanted to find that out later after the security fixes landed in focal
[16:52] <rbalint> vorlon, i make an attempt to make it at least partly testable
[17:12] <rbalint> vorlon, i went with badtesting all/i386
[17:40] -queuebot:#ubuntu-release- New binary: gcc-10-cross [ppc64el] (focal-proposed/universe) [3ubuntu1] (i386-whitelist)
[17:52] <vorlon> juliank: you might want to mention somewhere what the syntax of this force-reset-test hint is
[17:52] <vorlon> (syntax and semantics)
[17:53] <juliank> vorlon: hmm, well, it's the same as for force-badtest, just that it resets runs to alwaysfailed
[17:53] <juliank> cargo cult the examples in the hints repo :D
[17:54] <vorlon> juliank: right, I'm saying if you're announcing the thing on the mailing list, you should tell people how to use it rather than having them guess.  Does it always take a version? What does the version mean? etc
[17:55] <juliank> Well, we don't have docs for the rest either I guess
[17:55] <vorlon> I mean, I was opposed to the idea of this ever being done via the hints interface, I think that's shoehorned in rather than something that makes sense
[17:55] <juliank> Could we add a README to the hints repo explaining the hints?
[17:55] <vorlon> sure, MP welcome ;)
[17:58] <juliank> I feel like I broke launchpad
[17:59] -queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.38 => 237-3ubuntu10.39] (core)
[17:59] -queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu3.6 => 242-7ubuntu3.7] (core)
[17:59] <juliank> vorlon: At least I have an example here: https://code.launchpad.net/~juliank/britney/hints-ubuntu/+merge/378672
[17:59] <ddstreet> vorlon any chance you could review these...no change in the patches i'm adding from what you reviewed last time, it's just rebased on the security upload that overrode -proposed
[17:59] <juliank> will figure out a README
[18:00] <juliank> vorlon: I preferred Debian's baseline trigger idea, fwiw, but I think it's important to have some option
[18:00] <juliank> And people are split on the debian solution
[18:00] <juliank> If we rebase our britney, we'll have both, though
[18:02] <juliank> then we can have people do their migration-reference/0 triggers
[18:02] <juliank> though it feels like I'm not sure if that's a good thing to do, as it overrides release team control
[18:03] <Laney> Nope, the submission script won't allow them since it enforces that all triggers exist
[18:04] <juliank> ah
[18:04] <juliank> well, that could be changed easily :D
[18:04] <juliank> If we want
[18:05] <Laney> We want automatic release-only (migration-reference, if you like) runs :P
[18:05] <juliank> that'd be nice, yes
[18:05] <juliank> allowing them to be run manually after a test failed in proposed sounds sensible too, though
[18:06] <juliank> I think Debian automatically reruns migration-reference tests if unstable fails the test to see if it is a regression
[18:07] -queuebot:#ubuntu-release- New binary: yaru-theme [amd64] (focal-proposed/main) [20.04.1] (desktop-core)
[18:08] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu18 => 2.04-1ubuntu18] (core)
[18:16] -queuebot:#ubuntu-release- New binary: qt4-x11 [s390x] (focal-proposed/universe) [4:4.8.7+dfsg-20] (i386-whitelist, kubuntu)
[18:18] -queuebot:#ubuntu-release- New: accepted qt4-x11 [s390x] (focal-proposed) [4:4.8.7+dfsg-20]
[18:19] <RikMills> vorlon: qt4-x11 is on i386 whitelist why? it can't build on i386 due to missing libsqlite0-dev
[18:19] <cjwatson> juliank: oi, breaking Launchpad is my job
[18:20] <vorlon> RikMills: explicitly seeded, having been identified as a package that users need for their legacy binaries
[18:20] <vorlon> RikMills: but if it goes away in 20.04, then it falls out of the whitelist
[18:21] <mitya57> in the worst case we can add back our delta to build with libsqlite3-dev
[18:21] <vorlon> well, why would you build against ancient libsqlite0
[18:21] <vorlon> we could add that to the whitelist, but blech
[18:21] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu18 => 2.04-1ubuntu18] (core)
[18:23] <mitya57> vorlon: there was a huge delta and nobody did a merge for years. So we decided to just sync the latest version from Debian, which apparently built with old sqlite.
[18:24] <mitya57> But I would remove qt4-x11 from the whitelist in any case. We do not want to provide any support for Qt 4 at this point.
[18:24] <vorlon> mitya57: no, it will be removed from the whitelist only when it's removed from the archive
[18:24] <vorlon> if qt4 is removed for 20.04 then the whitelist doesn't matter
[18:24] <vorlon> if qt4 ships in 20.04, then i386 compatibility matters
[18:24] <mitya57> When the source package is removed, or when i386 binaries no longer build?
[18:25] <vorlon> when the source package is removed.
[18:25] <mitya57> Ok…
[18:25] <vorlon> and maybe you want to coordinate with tsimonq2 who has been working on qt4-x11 removal for focal
[18:26] <mitya57> I appreciate his work and try to take part in it too :)
[18:26] <vorlon> so, sqlite doesn't add any other dependencies, we could revive it on i386 easily enough and let the current qt4-x11 build
[18:27] <RikMills> I don't think simon is much active on that for now. mostly I have been looking at it
[18:28] <vorlon> ok
[18:28] <vorlon> anyway I've revivified sqlite/i386 now
[18:28] -queuebot:#ubuntu-release- New binary: qt4-x11 [amd64] (focal-proposed/universe) [4:4.8.7+dfsg-20] (i386-whitelist, kubuntu)
[18:29] <RikMills> vorlon: whichever is easiest. on this the aim is just to get qt5base migrated, which has breaks on qt4 < than the debian sync
[18:29] <RikMills> thanks!
[18:29] -queuebot:#ubuntu-release- New: accepted qt4-x11 [amd64] (focal-proposed) [4:4.8.7+dfsg-20]
[18:30] <mitya57> vorlon: thanks
[18:30] <mitya57> Apparently the packaged synced from Debian builds both sqlite2 and sqlite3 backends, while our package built only the latter.
[18:30] <mitya57> *the package
[18:31] <mitya57> If something other breaks and we have to do a new upload, it should be easy to drop the sqlite2 backend again.
[18:54] -queuebot:#ubuntu-release- New binary: ruby-api-pagination [amd64] (focal-proposed/universe) [4.8.2-1] (no packageset)
[20:29] -queuebot:#ubuntu-release- New: accepted ruby-api-pagination [amd64] (focal-proposed) [4.8.2-1]
[21:20] -queuebot:#ubuntu-release- Unapproved: clamav (bionic-proposed/main) [0.102.1+dfsg-0ubuntu0.18.04.2 => 0.102.1+dfsg-0ubuntu0.18.04.3] (ubuntu-server)
[21:20] -queuebot:#ubuntu-release- Unapproved: clamav (eoan-proposed/main) [0.102.1+dfsg-0ubuntu0.19.10.2 => 0.102.1+dfsg-0ubuntu0.19.10.3] (ubuntu-server)
[21:29] -queuebot:#ubuntu-release- Unapproved: clamav (xenial-proposed/main) [0.102.1+dfsg-0ubuntu0.16.04.2 => 0.102.1+dfsg-0ubuntu0.16.04.3] (ubuntu-server)
[21:42] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (eoan-proposed) [242-7ubuntu3.7]
[21:46] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.39]
[22:19] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.4] has been marked as ready
[22:19] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.4] has been marked as ready
[23:09] <xnox> vorlon:  sqlite3 is broken on s390x in forcal-proposed https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1862267 can we please remove the new sqlite3 from focal-proposed for now? I will bisect / debug it tomorrow to understand what is going wrong?
[23:09] <xnox> otherwise it will be blocking boost & other migrations
[23:09] <xnox> on s390x
[23:41] <vorlon> xnox: I don't see where it blocks boost?
[23:41] <vorlon> or anything