[00:02] <mwhudson> vorlon: so to justify hinting glibc vs itself: i could reproduce the failures by running autopkgtest --- null in a local lxc container but if i ran it with --shell-fail and ran the test case by itself, it passed
[00:03] <mwhudson> and even ./debian/rules check_libc after removing the stamp file passed
[00:03] <mwhudson> so it's very odd
[00:03] <mwhudson> but not an indication of a real problem imo
[00:03] <mwhudson> i should try patching the tests to do some stracing i guess
[01:07] <vorlon> mwhudson: ok
[01:43] <mwhudson> uh huh
[01:43] <mwhudson> do we think the boost autopkgtests that have been running for 14 hours on arm64 are doing anything?
[01:44] <mwhudson> uh well they took 11 hours to pass on ppc64el once i guess maybe
[07:55] -queuebot:#ubuntu-release- New: accepted thunderbird [amd64] (impish-proposed) [1:91.0+build1-0ubuntu1]
[07:55] -queuebot:#ubuntu-release- New: accepted thunderbird [armhf] (impish-proposed) [1:91.0+build1-0ubuntu1]
[07:55] -queuebot:#ubuntu-release- New: accepted thunderbird [s390x] (impish-proposed) [1:91.0+build1-0ubuntu1]
[07:55] -queuebot:#ubuntu-release- New: accepted thunderbird [arm64] (impish-proposed) [1:91.0+build1-0ubuntu1]
[07:55] -queuebot:#ubuntu-release- New: accepted thunderbird [ppc64el] (impish-proposed) [1:91.0+build1-0ubuntu1]
[08:20] <laney> vorlon: no, you can see the worker history on https://ubuntu-release.kpi.ubuntu.com/d/76Oe_0-Gz/autopkgtest?orgId=1&from=now-2d&to=now and there's no problem with the number of workers. If there's a problem then it might be to do with something non-fatal like slow boots or reboots maybe...
[08:21] <laney> I'm going to send the feature freeze announcement email
[08:24] <laney> done, could someone review & moderate please? (cjwatson?)
=== laney changed the topic of #ubuntu-release to: Released: 21.04 Hirsute Hippo | Archive: DIF, FF | Highlight ubuntu-archive for archive admin help | Impish Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis | infinity, you will be missed
[08:25] <laney> huh, what, it didn't need moderation, that's new?
[10:04] <laney> apw: can you do me a favour? I just made some discourse tweaks to allow the release team to moderate the release category, want to check if they worked.
[10:04] <laney> Can you see if you see moderator tools like close thread / pin post on threads in that category on discourse?
[10:10] <laney> looks like pin might be in a too-recent release maybe, see if you have /any/ mod tools (https://github.com/discourse/discourse/pull/12325)
[10:10] <ubottu> Pull 12325 in discourse/discourse "FEATURE: allow category group moderators to pin/unpin topics" [Merged]
[10:13] <xnox> I am having issues trying to retrigger autopkgtest tests. It seems like the request.cgi, when trying to do a login, redirects back to http website, instead of https => meaning my browser prevents completing auth http://autopkgtest.ubuntu.com/login?next=http://autopkgtest is the url i see after sso challenge.
[10:13] <xnox> has something in the deployment chnaged? or has my browser become "smarter"?
[10:24] <xnox> i wonder if this is an IS problem, because sso login redirect goes to http:// as if it is in the SSO config.
[10:25] <xnox> <input type="hidden" name="next" value="http://autop
[10:26] <xnox> nope really broken in the app
[10:29] <laney> firefox manages to do it, there's a http -> https redirect in place
[10:29] <laney> but fixing sounds neat, can you send a merge proposal?
[10:30] <laney> I'll be doing an upgrade anyway for sil2100's private browsing stuff, now we got a user
[10:42] <laney> I think it's probably because it's proxied using http, so the app thinks that's what protocol it's using (https happens at the haproxy layer)
[10:46] <xnox> laney:  horum.
[10:47] <laney> xnox: let me have a go, I see a path through maybe
[10:59] <xnox> laney:  yeah, i'm lost and sceptical. this is the best i can do https://code.launchpad.net/~xnox/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/407449
[10:59] <xnox> but i don't know which flask we are deployed with, and if rewritting request.sheme like that is allowed or not
[10:59] <laney> heh
[10:59] <laney> I think you have to wrap it and look at the header from the proxy
[11:00] <xnox> cause there is some X-Original-Request-Was-Blah: thing right
[11:00] <xnox> proxied-for-foo
[11:00] <laney> seems like you make it set X-Forwarded-Proto
[11:00] <laney> and then you can poke that in
[11:16] <xnox> and use werkzeug.meddleware.proxy_fix too?! as in https://flask.palletsprojects.com/en/2.0.x/deploying/wsgi-standalone/#proxy-setups
[11:17] <xnox> i'm not sure i understand it.
[11:17] <xnox> others did the bogus thing i did https://stackoverflow.com/questions/19840051/mutating-request-base-url-in-flask
[11:18] <laney> yes
[11:19] <laney> xnox: can you try on staging?
[11:21] <laney> with gzip or something quick
[11:22] <xnox> laney:  where is staging?
[11:22] <laney> autopkgtest.staging.u.c
[11:23] <xnox> laney:  that was all good! and ubuntu sso did have https:// in the url too.
[11:23] <xnox> and it all worked nicely.
[11:24] <laney> good, let me push a merge proposal, maybe you can review
[11:28] <laney> xnox: https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/407450
[11:28] <laney> mercifully it was packaged
[11:33] <laney> such fun, xwayland crashed on my laptop
[11:41] <xnox> j'approuve
[11:44] <laney> xz: (stdout): Write error: No space left on device
[11:44] <laney> E: mkinitramfs failure xz --check=crc32 --threads=0 1
[11:46] <laney> ubiquity's developers in 2015 have a lot to answer for!
[11:46] <laney> I will release that once I get out of this hole
[12:05] <xnox> release week devs; or non-release week?
[12:09] <laney> whoever made it create tiny /boots
[12:19] <laney> xnox: deployed
[12:22] <schopin> OK so I'm trying the Ubuntu Budgie images out of curiosity (didn't know this DE before yesterday). However the test scenarios on the QA site don't really match what I'm seeing.
[12:23] <schopin> When I boot up the image I drop directly onto the live desktop, not the installer, whereas the tests seem to assume we land on the installer by default.
[13:01] <xnox> schopin:  the qa tests are a rough guide, which at the moment doesn't match reality of most flavours.
[13:02] <xnox> schopin:  get the .0 release and boot that, is the new point release experience the same or better?
[13:02] <xnox> is kind of what one is benchmarking things against
[13:06] -queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.22-dfsg-2~ubuntu1.20.04.1 => 6.1.26-dfsg-3~ubuntu1.20.04.1] (kernel-dkms, ubuntu-cloud)
[13:07] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (focal-proposed/multiverse) [6.1.22-1~ubuntu1.20.04.1 => 6.1.26-2~ubuntu1.20.04.1] (no packageset)
[13:07] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (hirsute-proposed/multiverse) [6.1.22-1~ubuntu1.21.04.1 => 6.1.26-2~ubuntu1.21.04.1] (no packageset)
[13:07] -queuebot:#ubuntu-release- Unapproved: virtualbox (hirsute-proposed/multiverse) [6.1.22-dfsg-2~ubuntu1.21.04.1 => 6.1.26-dfsg-3~ubuntu1.21.04.1] (kernel-dkms, ubuntu-cloud)
[13:07] -queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (focal-proposed/multiverse) [6.1.22-1~ubuntu1.20.04.1 => 6.1.26-1~ubuntu1.20.04.1] (no packageset)
[13:07] -queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (hirsute-proposed/multiverse) [6.1.22-1~ubuntu1.21.04.1 => 6.1.26-1~ubuntu1.21.04.1] (no packageset)
[13:07] <LocutusOfBorg> hello, can anybody put this one in proposed queue to superseed 6.1.24? thanks!
[13:07] <LocutusOfBorg> so I can test over the weekend
[13:07] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.22-dfsg-2~ubuntu1.20.04.1 => 6.1.26-dfsg-3~ubuntu1.20.04.1] (kernel-dkms)
[13:07] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (hirsute-proposed/multiverse) [6.1.22-dfsg-2~ubuntu1.21.04.1 => 6.1.26-dfsg-3~ubuntu1.21.04.1] (kernel-dkms)
[13:07] <LocutusOfBorg> focal and hirsute, since groovy is EOL
[13:22] -queuebot:#ubuntu-release- Unapproved: openssl (focal-proposed/main) [1.1.1f-1ubuntu2.5 => 1.1.1f-1ubuntu2.6] (core, i386-whitelist)
[15:04] -queuebot:#ubuntu-release- Unapproved: thermald (hirsute-proposed/main) [2.4.3-1ubuntu1 => 2.4.3-1ubuntu2] (core)
[15:10] -queuebot:#ubuntu-release- Unapproved: thermald (focal-proposed/main) [1.9.1-1ubuntu0.5 => 1.9.1-1ubuntu0.6] (core)
[18:30] <vorlon> bluesabre: hi, so the Xubuntu daily images have been oversized now for a bit; should the limit be raised, or does someone plan to bring those back down to size?
[18:31] <vorlon> (2076698624 vs 2000000000)
[20:41] <bluesabre> vorlon: sorry for the noise on that. The realistic limit is 2.0G for now.
[20:42] <bluesabre> (just above the 1.9G reported at http://cdimage.ubuntu.com/xubuntu/daily-live/current/)
[20:43] <vorlon> bluesabre: do you mean 2.0GiB, rather than the current 2.0GB?
[20:44] <bluesabre> Yes
[20:46] <bluesabre> I think we'll revisit it in the future, but for now we're shipping components across three different GTK toolkits and are pretty happy with the current packageset, trying to avoid ripping anything else out