[07:14] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (focal-proposed) [2.46+20.04]
[07:48] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (focal-proposed) [2.46.1+20.04]
[07:49] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.46+18.04]
[07:50] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.46.1+18.04]
[07:53] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.46]
[08:16] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.46.1]
[08:29] <rbalint> LocutusOfBorg, instead of hinting systemd haveged should be fixed to not start in lxc
[08:51] <juliank> rbalint: what's the matter?
[08:51] <juliank> We install it by design, not by accident
[08:51] <juliank> AFAIUI
[08:53] <rbalint> juliank, it is ok, it just should not start in lxc because it can't and fails
[08:55] <Laney> rbalint: this is amd64, not lxc ... or are the tests using that internally?
[08:56] <rbalint> juliank, Laney yes, i just realizes i was wrong, haveged fails outside of lxc
[08:56] <juliank> maybe it fails because I install both rng-tools and haveged since a week or two ago?
[08:56] <juliank> maybe you can only have one
[08:56] <rbalint> juliank, this makes sense
[08:57] <juliank> (but not all our clouds support rng-tools)
[08:57] <juliank> Ah, also we don't install inside container
[08:58] <rbalint> juliank, i've patched glibc to ignore the test failure due to lack of entropy, so i'm ok with reverting adding haveged
[08:59] <juliank> rbalint: we've installed haveged for ages
[08:59] <juliank> We're trying to switch to rng-tools
[08:59] <rbalint> juliank, then rng-tools
[08:59] <Laney> no wait
[08:59] <Laney> https://autopkgtest.ubuntu.com/packages/systemd/groovy/amd64
[08:59] <Laney> it used to pass with haveged, the same commit of autopkgtest
[09:00] <Laney> then we started consistently failing on the 5th, so ... what?
[09:00] <juliank> ok
[09:00] <juliank> Laney: well, maybe rng-tools started working, idk?
[09:00] <juliank> Well it should have worked before that I suppose
[09:01] <rbalint> Laney, 2020-09-05 , new haveged landed
[09:01] <Laney> ah
[09:01] <Laney> and this fails to start in the cloud or something?
[09:02] <juliank>  haveged.service loaded failed failed Entropy Daemon based on the HAVEGE algorithm'
[09:02] <Laney> let's see
[09:02] <juliank> there's no status or journalctl
[09:05] <Laney> https://paste.ubuntu.com/p/4Jg83htdf4/
[09:05] <Laney> seems bad
[09:06] <rbalint> Laney, at least we caught it :-)
[09:07] <Laney> not at the right time, but better than nothing
[09:08] <Laney> bah
[09:08] <Laney> haveged's autopkgtests just build it and run 'make check', that is not good
[09:09] <Laney> thinking of reverting this, thoughts?
[09:09] <rbalint> Laney, +1
[09:10] <rbalint> ddstreet, haveged ^^^
[09:10] <Laney> I'll file a bug, just a second
[09:10] <Laney> testing in a sid vm
[09:10] <Laney> lxc launch --vm ♥ ♥ ♥
[09:13] <Laney> "active (running)"
[09:13] <Laney> guess we lose :-)
[09:25] <rbalint> Laney, do you have some time today to check the glibc ffe?
[09:25] <Laney> yeah, I started typing a reply, will send it after haveged
[09:25] <rbalint> Laney, thanks!
[09:33] <LocutusOfBorg> xnox, are you aware that your ghc 8.8.3-1ubuntu1 and 8.8.3-1ubuntu2 can't be published because they will trigger a full transition on armhf? last time I changed  optc--param -optcggc-min-expand=10 on an a single architecture I had to rebuild the world... (and it was a leaf package)
[09:33] <LocutusOfBorg> so, please don't hit publish.
[09:33] <LocutusOfBorg> if we have to do a 1k transition better use 8.8.4, that is a minor bugfix release
[09:46] <Laney> rbalint: would you keep an eye on 'rmadison systemd' and retry the tests once it's published please?
[09:48] <rbalint> Laney, rmadison haveged?
[09:50] <Laney> yeah, you know what I m ean
[09:51] <rbalint> Laney, sure
[09:59] <xnox> LocutusOfBorg:  I am aware of that, but also ghc ftbfs on armhf is holding up 145+ package ffi transition.
[09:59] <xnox> LocutusOfBorg:  something is wrong with either the way we build the new compiler, or how the current one in groovy-release was built.
[10:00] <xnox> LocutusOfBorg:  cause in debian/previously it only took 12-15h or so to build. Yet now, it never finishes for us after going for 4d+ on armhf. Despite taking 12-15h on arm64.
[10:01] <xnox> LocutusOfBorg:  is there something broken in our llvm, or ghc, such that we might need to rebootstrap it off debian again?
[10:02] <Laney> Try asking IS to have a look at the builder, see if it's too overcommitted or weirdly IO bound or something
[10:04] <xnox> well somehow the build is now cancelled.
[10:04] <xnox> not sure why
[10:05] <Laney> doesn't look like it to me https://launchpad.net/ubuntu/+source/ghc/8.8.3-3build1/+build/19872603
[10:06] <cjwatson> Also cancelling is only ever manual - it wouldn't happen automatically
[10:06] <xnox> ah, sorry, got confused in my tabs
[10:06]  * xnox slurps more coffee
[10:06] <xnox> even if it completes building, the build-time there is not acceptable. something is broken.
[10:07] <Laney> no more GHCs for groovy after this I'd say ;-)
[10:07] <xnox> <<ghc: 45287392 bytes, 19 GCs, 6117865/12278732 avg/max bytes residency (4 samples), 31M in use, 0.003 INIT (0.003 elapsed), 13.981 MUT (14.080 elapsed), 0.371 GC (0.375 elapsed) :ghc>>
[10:07] <xnox> not sure if this is good, bad or what it is.
[10:08] <cjwatson> Once it eventually finishes you might find something interesting by diffing build logs
[10:09] <cjwatson> Or what Laney suggested above, though I'd be cautious to avoid accidentally killing something by incautious manual poking
[10:09] <xnox> yeah that =/
[10:10] <Laney> Launchpad being able to use bos01 would probably help a little, too, if it is a problem with overcommit
[10:10] <Laney> as an instance of a general "get more arm hardware" solution
[10:12] <xnox> LocutusOfBorg:  but 8.8.4 hasn't migrated in debian yet.
[10:19] <cjwatson> My vague memory of why we don't currently use bos01 is that we haven't ported the base image building machinery to new keystone or similar, but I could be wrong
[10:19] <cjwatson> wgrant would probably remember
[10:19] <Laney> Yeah, keystone v3, we had to do some light porting for autopkgtest
[10:19] <Laney> it wasn't too bad, but still, work
[10:22] -queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1027.27] (no packageset)
[10:30] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1027.27]
[10:37] <LocutusOfBorg> xnox, 8.8.4 hasn't migrated because of slow new queue, we already have such leaf stuff here :)
[10:37] <rbalint> Laney, if we kill all glibc ppa autopkgtests on arm64/armhf that could help with the load
[10:37] <LocutusOfBorg> I took haskell-gi-harfbuzz from new queue and uploaded into groovy
[10:38] <rbalint> Laney, i would be ok with that, i think the aready ran tests are convincing enough for the ffe
[10:38] <Laney> rbalint: ok, if that's what you want!
[10:39] <rbalint> Laney, if you won't complain later for not enough tests ;-)
[10:40] <Laney> all gone
[10:41] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.3 => 2.04-1ubuntu26.4] (core)
[10:45] <LocutusOfBorg> btw we should according to the build log, be near the end of the armhf build
[10:47] <LocutusOfBorg> xnox, we should (once the build is over) diff the log as Colin said, between 8.8.3-1build1 and 8.8.3-1ubuntu2
[10:48] <LocutusOfBorg> also, can anybody try to test haskell-hoogle/armhf on big_packages?
[10:49] <LocutusOfBorg> its still a libffi blocker
[10:49] <xnox> compared with arm64, it's like at 89% of the buildlog.
[10:49] <xnox> but that's like still hours to get there, i guess.
[10:50] <Laney> I'll make sure to use this ghc a lot :-)
[10:50] <LocutusOfBorg> not on armhf, too slow also in compiling stuff...
[11:04] -queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.142.5 => 1.142.6] (core)
[11:05] <xnox> bdmurray:  grub2 & grub2-signed in focal-proposed are the ones you want to unblock lts->lts upgrades.
[11:18] <rbalint> bdmurray, wsl1 users should also wait for glibc
[11:41] <seb128> could someone update the reset hint for spice on ppc?
[11:41] <seb128> there was one lucky success and it's back to failing and blocking things
[11:43] <Laney> I did it already
[12:03] <seb128> Laney, thanks!
[12:07] <LocutusOfBorg> ubuntu-archive: cat-bat is NBS-proposed on armhf, can anybody please clean it up? depends on diamond-aligner, NBS there
[12:09] -queuebot:#ubuntu-release- New: accepted haskell-shake [amd64] (groovy-proposed) [0.19.1-2]
[12:09] -queuebot:#ubuntu-release- New: accepted haskell-shake [armhf] (groovy-proposed) [0.19.1-2]
[12:09] -queuebot:#ubuntu-release- New: accepted haskell-shake [riscv64] (groovy-proposed) [0.19.1-2]
[12:09] -queuebot:#ubuntu-release- New: accepted haskell-shake [arm64] (groovy-proposed) [0.19.1-2]
[12:09] -queuebot:#ubuntu-release- New: accepted haskell-shake [s390x] (groovy-proposed) [0.19.1-2]
[12:09] -queuebot:#ubuntu-release- New: accepted haskell-shake [ppc64el] (groovy-proposed) [0.19.1-2]
[13:02] <LocutusOfBorg> is it possible ubuntu-archive to remove swt4-gtk on armhf? it is NBS also in Debian...
[14:00] -queuebot:#ubuntu-release- Unapproved: snapcraft (focal-proposed/universe) [3.0ubuntu1 => 3.0ubuntu1.1] (no packageset)
[14:26] <bdmurray> rbalint: the upgrade process doesn't distinguish between wsl1 users or not
[14:27] <ddstreet> Laney rbalint latest haveged upstream is 1.9.13, but debian is still at 1.9.8, would you prefer 1) package 1.9.13 and ask debian to accept it and put it into groovy, or 2) just package 1.9.13 and put it into groovy and worry about debian later, or 3) revert groovy back to the really old 1.9.1, or 4) backport the specific fix for the segfault from upstream into 1.9.8
[14:27] <rbalint> bdmurray, well would better do of glibc should be out before letting them to do release upgrade
[14:32] <Laney> ddstreet: I did (3) already; I would do (1) + (2) or (4) next but I don't have a particular opinion on what because I don't know haveged particularly well
[14:32] <Laney> also beefing up the autopkgtest, as I said
[14:32] <ddstreet> Laney right re: #3 what i meant was give up entirely on a newer haveged for groovy, i.e. touch nothing else
[14:32] <ddstreet> yeah, unfortunately the previous 'dieharder' test wouldn't have failed either, as it only segfaults with --Foreground
[14:33] <bdmurray> rbalint: Is there a bug regarding the glibc update?
[14:33] <rbalint> ddstreet, Laney if 1.9.13 is good i'd go with 2), because tests are still failing because broken haveged is in the image as i see
[14:34] <ddstreet> 1.9.13 works for me, doesn't segfault
[14:34] <rbalint> ddstreet, Laney and getting .13 in is faster than waiting for new images, i think
[14:34] <Laney> ah yeah new images /o\
[14:34] <rbalint> Laney, i forgot about those, too :-)
[14:35] <rbalint> ddstreet, then i think going ahead with .13 is the best, i think
[14:35] <Laney> I don't know the first thing about .13, so I refuse to have an opinion :p
[14:36] <rbalint> bdmurray, glibc is pending sru with several bugs
[14:36] <Laney> but if you're going to package it, also proposing it to Debian would be the decent thing to do
[14:37] <ddstreet> yep i'll definitely open a salsa MR, but presumably it would take time for debian to merge, if we want it in ubuntu immediately to fix breakage probably shouldn't wait for debian
[14:37] <rbalint> Laney, sure
[14:37] <Laney> sure
[14:38] <rbalint> ddstreet, i see bump soname in haveged changelog
[14:39] <rbalint> ddstreet, but there are no reverse deps
[14:39] <ddstreet> yep, seemed nothing but haveged uses libhavege1/2
[14:43] <rbalint> ddstreet, Laney  seems almost only bugfix release, so i think it can be uploaded without an ffe
[14:45]  * rbalint afk a bit
[15:06] <bdmurray> rbalint: when updating hints for a stable release we use ubuntu-sru not ubuntu-release
[15:11] <rbalint> bdmurray, thanks, why is that? it is harder to cherry-pick, not that bzr supported that in the past
[15:11] <cjwatson> bzr supports it just as much as git does
[15:12] <cjwatson> bzr merge -c<revision> has basically the same semantics as git cherry-pick <commit>
[15:13] <rbalint> cjwatson, thanks
[15:13] <cjwatson> and the branch ownership is different because when a series is released responsibility for managing it is effectively handed over from ~ubuntu-release to ~ubuntu-sru
[15:14] <cjwatson> it shouldn't have any particular effect on cherry-picking; it's a different branch either way
[15:19] <rbalint> bdmurray, ok, so the question is even more valid, why using the ubuntu-sru file when the branch is different already and cherry-picking would work using the same file even with brz?
[15:20] <bdmurray> rbalint: I don't recall the reasoning behind it but I think it has to do with separating things pre and post release
[15:22] <rbalint> bdmurray, ok, that's not needed after the migration to git, because the release clearly branches off after release
[15:22] <cjwatson> It's about ownership/permissions, not about branching
[15:23] <rbalint> cjwatson, i thought the o/p is per branch
[15:23] <cjwatson> bzr vs. git has very little to do with it
[15:24] <cjwatson> Oh, you're talking about the actual file name in the branch and not the URL of the branch, I see
[15:24] <rbalint> cjwatson, yes
[15:24] <cjwatson> Still, the bzr/git business isn't relevant
[15:25] <rbalint> cjwatson, did bzr have something like git lot --graph master focal showing where the bzr branch forked off?
[15:25] <cjwatson> I'm not your bzr manual :-)
[15:26] <cjwatson> There are certainly ways to get equivalent information, but I'm not going to go hunting for an exact UI equivalent
[15:26] <rbalint> cjwatson, so seemed to be very good at reminding how historical sw worked :-)
[15:26] <cjwatson> (Worst case, "bzr help revisionspec")
[15:28] <cjwatson> AFAICS the hint permissions for ubuntu-sru and ubuntu-release are identical, so shouldn't be a problem there
[15:28] <rbalint> bdmurray, so how about just updating the ubuntu-release file instead of ubuntu-sru because it will be easier going forward?
[15:29] <rbalint> bdmurray, like not maintaining the hits per user which also used to be a practice
[15:30] <rbalint> cjwatson, good, i've prepared the switch to git for some time, one less thing to worry about
[15:31] <rbalint> bdmurray, also there is a commit to the 'freeze' file which separates pre- and post release
[15:33] <ddstreet> rbalint Laney fyi, haveged 1.9.13 failed on arm64 in my test ppa because it didn't like its self-test results...i'm retrying it but best case there is its self-tests are flaky, so i'm gonna look at just backporting the startup segfault fix in 1.9.8 for groovy
[15:40] -queuebot:#ubuntu-release- Unapproved: squid3 (xenial-proposed/main) [3.5.12-1ubuntu7.13 => 3.5.12-1ubuntu7.14] (ubuntu-server)
[15:40] <rbalint> bdmurray, also in bionic hints there were commits to ubuntu-release and to per user files
[16:28] <Laney> rbalint: I rebuilt the images, now the new old haveged should really be there
[16:28] <Laney> downgrading packages, just say no!
[16:31] <Laney> and now I have retried systemd again
[16:31] <Laney> this looks like we're mashing the button, but we're not, honest
[16:40] <rbalint> Laney, i was not looking , but good!
[17:31] <vorlon> LocutusOfBorg: swt4-gtk seems to have quite a few reverse-build-deps on armhf, what do we do with those?
[17:34] -queuebot:#ubuntu-release- Unapproved: gdm3 (focal-proposed/main) [3.34.1-1ubuntu1 => 3.36.3-0ubuntu0.20.04.1] (desktop-core)
[17:35] <vorlon> LocutusOfBorg: also why are you copying in a new upstream version of swt4-gtk post-FF anyway
[17:37] <bdmurray> Can somebody remove sbuild-launchpad-chroot from bionic-proposed as it FTBFS.
[17:39] <bdmurray> paride: Did something go wrong with your tag editing of bug 1874362? You did verify it correct?
[17:41] <Laney> bdmurray: done
[17:42] <bdmurray> thanks
[17:45] -queuebot:#ubuntu-release- Unapproved: corosync-qdevice (focal-proposed/universe) [3.0.0-4ubuntu1 => 3.0.0-4ubuntu1.1] (no packageset)
[17:58] -queuebot:#ubuntu-release- Unapproved: rejected nvme-cli [source] (focal-proposed) [1.9-1ubuntu0.1]
[18:02] -queuebot:#ubuntu-release- Unapproved: accepted rhythmbox-plugin-alternative-toolbar [source] (focal-proposed) [0.19.3-1.1]
[18:06] <bdmurray> Could python-pip also be removed from xenial-proposed as it fails its autopkgtests?
[18:15] -queuebot:#ubuntu-release- Unapproved: rejected libvirt [source] (focal-proposed) [6.0.0-0ubuntu8.4]
[18:25] <teward> whoever approved the late-sync of xca (unless it's 'soft freeze' right now) thank you.  (that fixes a couple bugs AND lets me say "fixed in Groovy, SRU these fixes to Focal" now.
[18:26] <teward> Laney: remind me, if I try and upload direct to -backports will it prohbit me or go via NEW or something?  Looking to backport `xca` to Focal backports :P
[18:26] <teward> also planning the same for nginx but never got a reply from you
[18:44] -queuebot:#ubuntu-release- Unapproved: accepted nvme-cli [source] (focal-proposed) [1.9-1ubuntu0.1]
[18:45] <ddstreet> rbasak could you import haveged into git-ubuntu? also i forget if there's a process for asking for pkgs to be git-ubuntu imported...
[18:46] <ahasenack> it's fine here, when someone is looking :)
[18:46] <ahasenack> I highlight on git-ubuntu
[18:46] <LocutusOfBorg> vorlon,
[18:46] <LocutusOfBorg>  	2020-09-06 14:33:46 CEST	Published	Groovy	proposed	universe	misc	4.16.0-2
[18:46] <LocutusOfBorg>  	2020-09-06 14:33:54 CEST	Superseded	Groovy	proposed	universe	misc	4.16.0-1
[18:46] <LocutusOfBorg> I copied -2 over -1, hoping to fix something, I didn't copy any new release
[18:46] <LocutusOfBorg> anyway, Debian removed them I presume?
[18:49] <LocutusOfBorg> I did reverse-depends -r sid   src:swt4-gtk, rmadison for all the reverse-dependencies, and they are all source:all architecture
[18:50] <LocutusOfBorg> so no reverse-dependencies on armhf?
[18:50] <ahasenack> ddstreet: importing
[18:51] <ddstreet> thanks!
[18:53] -queuebot:#ubuntu-release- Unapproved: php7.4 (focal-proposed/main) [7.4.3-4ubuntu2.2 => 7.4.3-4ubuntu2.3] (i386-whitelist)
[19:01] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (focal-proposed) [3.0ubuntu1.1]
[19:13] <LocutusOfBorg> vorlon, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962915
[19:30] <ahasenack> ddstreet: https://code.launchpad.net/ubuntu/+source/haveged done, and it will be kept up-to-date now
[20:30] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.3-0ubuntu1]
[20:36] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.10-0ubuntu1]
[20:40] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.1.1-0ubuntu1]
[20:42] -queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (bionic-proposed) [1:12.0.2-0ubuntu1]
[20:52] -queuebot:#ubuntu-release- Unapproved: accepted munin [source] (xenial-proposed) [2.0.25-2ubuntu0.16.04.4]