[04:19] <bryceh> vorlon, bdmurray question on britney...  if I run packages with all-proposed=1 they pass, but they don't seem to then transition.  Is 'all-proposed=1' "good enough" to get things to migrate, or do I have to run a retrigger with specific package versions of each dependency?
[04:20] <bryceh> specifically, I'm trying to figure out wtf needs to happen to get symfony to migrate.  I keep rebuilding/repatching/retriggering things but it seems resistant to going through.  I'm running out of ideas.
[07:03] <vorlon> bryceh: if you mean runs like https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/d/doctrine/20210618_021356_3d27e@/log.gz the problem is the trigger doesn't mention symfony at all
[07:04] <vorlon> bryceh: you likely want retry-autopkgtest-regressions --all-proposed --blocks symfony (which I've now just run)
[07:05] <bryceh> vorlon, ah thanks, I didn't know about --blocks
[07:08] <vorlon> um.  well, I *tried* to run it, but something seems to be wrong now with my cookie handling. >_<
[07:11] <vorlon> ugh I'm logged out of autopkgtest.ubuntu.com and can't seem to get logged back in
[07:11] <vorlon> bryceh: so, if retry-autopkgtest-regressions works for you, you'll want to do the above
[07:12] <vorlon> oh hey NOW I'm logged in
[07:12] <bryceh> ok, I'm looking.  '--blocks' says "rerun only those tests that were triggered by the named package".  It's not evident what that implies specifically...
[07:13] <vorlon> apparently login redirect was failing because I was trying to use a retry link with multiple triggers. >_<
[07:13] <bryceh> retry-autopkgtest-regressions's code docs are a bit spartan
[07:17] <bryceh> $ ./retry-autopkgtest-regressions --all-proposed --blocks symfony
[07:17] <bryceh> returns empty
[07:19] <bryceh> OTOH, running this I get some actions:
[07:19] <bryceh> stirling:~/src/ExcusesKicker/excuses-kicker$ ./scripts/excuses-kicker symfony
[07:19] <bryceh> https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=symfony&trigger=symfony%2F5.2.6%2Bdfsg-1ubuntu7&trigger=glibc%2F2.33-0ubuntu8&trigger=php-psr-container%2F2.0.1-1&trigger=php-psr-cache%2F3.0.0-1&trigger=php-async-aws-sqs%2F1.5.0-1&trigger=php-async-aws-ses%2F1.4.0-1&trigger=phpunit%2F9.5.4-1&trigger=php-twig%2F3.3.2-1ubuntu3&trigger=php-async-aws-core%2F1.10.0-1&trigger=php-symfony-contracts%2F2.4.0-1ubuntu2&trigger=doctr
[07:19] <bryceh> e%2F2.8.4%2Bdfsg-1&trigger=php-email-validator%2F3.1.1-2build1&trigger=php-monolog%2F2.2.0-1&trigger=php-symfony-security-acl%2F3.1.1-1ubuntu1&trigger=php-defaults%2F82~0build1
[08:12] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.23 => 2.664.24] (desktop-core, i386-whitelist)
[08:13] -queuebot:#ubuntu-release- New source: openjdk-18 (impish-proposed/primary) [18~2-0ubuntu1]
[08:16] -queuebot:#ubuntu-release- New: accepted golang-code.rocketnine-tslocum-cview [amd64] (impish-proposed) [1.5.4-1]
[08:16] -queuebot:#ubuntu-release- New: accepted libpod [arm64] (impish-proposed) [3.2.1+ds1-2ubuntu2]
[08:16] -queuebot:#ubuntu-release- New: accepted libpod [ppc64el] (impish-proposed) [3.2.1+ds1-2ubuntu2]
[08:16] -queuebot:#ubuntu-release- New: accepted libpod [s390x] (impish-proposed) [3.2.1+ds1-2ubuntu2]
[08:16] -queuebot:#ubuntu-release- New: accepted libpod [amd64] (impish-proposed) [3.2.1+ds1-2ubuntu2]
[08:16] -queuebot:#ubuntu-release- New: accepted libpod [riscv64] (impish-proposed) [3.2.1+ds1-2ubuntu2]
[08:16] -queuebot:#ubuntu-release- New: accepted libpod [armhf] (impish-proposed) [3.2.1+ds1-2ubuntu2]
[08:16] -queuebot:#ubuntu-release- New: accepted openjdk-18 [source] (impish-proposed) [18~2-0ubuntu1]
[08:29] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.143-0ubuntu0.18.04.2]
[08:46] -queuebot:#ubuntu-release- Unapproved: linux-gcp (focal-proposed/main) [5.4.0-1044.47 => 5.4.0-1045.48] (core, kernel) (sync)
[08:46] -queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (focal-proposed/main) [5.4.0-1044.47 => 5.4.0-1045.48] (core, kernel) (sync)
[08:46] -queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (focal-proposed/main) [5.4.0.1044.54 => 5.4.0.1045.54] (core, kernel) (sync)
[08:46] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-gcp (focal-proposed/restricted) [5.4.0-1044.47+2 => 5.4.0-1045.48] (kernel) (sync)
[08:46] -queuebot:#ubuntu-release- Unapproved: linux-restricted-signatures-gcp (focal-proposed/restricted) [5.4.0-1044.47+2 => 5.4.0-1045.48] (no packageset) (sync)
[08:47] <utkarsh2102> hey
[08:48] <utkarsh2102> I am not sure if I understand this https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#phpunit
[08:49] <utkarsh2102> phpunit seems to be blocked by php-league-html-to-markdown/4.10.0-2 on s390x but 4.10.0-2build1 was uploaded and it is in -release & passes on s390x if one checks the history on s390x
[08:50] <utkarsh2102> since a new php-league-html-to-markdown is already in -release, should phpunit not run against that? And we already did the re-triggers, so I am wondering why is it being held back?
[09:06] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (hirsute-proposed) [0.99.10.1]
[09:06] <laney> utkarsh2102: they need to have a trigger on phpunit, if it's migrated to -release you should just be able to click the retry button?
[09:07] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (focal-proposed) [0.99.9.6]
[09:08] <utkarsh2102> laney: thanks, can you please re-trigger for me: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=s390x&package=php-league-html-to-markdown&trigger=phpunit%2F9.5.4-1
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.16]
[09:08] <laney> ok
[09:09] <utkarsh2102> thank you! And I suppose that should be enough to get it migrating, so it's just a matter of waiting for an hour or two?
[09:14] <utkarsh2102> laney: gotcha, that failed & this was long known, thanks! I'll add hints.
[09:15] <utkarsh2102> s/long known/long failing on s390x/g
[09:16] <laney> well it does look like the new phpunit makes it fail ...
[09:16] -queuebot:#ubuntu-release- Unapproved: accepted simplestreams [source] (hirsute-proposed) [0.1.0-30-g3cc8988a-0ubuntu1.21.04.1]
[09:16] <laney> i.e. we're finding a regression, no?
[09:20] <utkarsh2102> laney: it is actually the incompatibility on s390x, not a "real" regression, though
[09:21] -queuebot:#ubuntu-release- Unapproved: accepted simplestreams [source] (groovy-proposed) [0.1.0-30-g3cc8988a-0ubuntu1.20.10.1]
[09:36] <utkarsh2102> laney: hey, can you please merge https://code.launchpad.net/~utkarsh/britney/+git/britney/+merge/404374? TIA!
[09:55] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.24]
[10:01] -queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (focal-proposed) [5.4.0-1045.48]
[10:01] -queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-gcp [sync] (focal-proposed) [5.4.0-1045.48]
[10:01] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (focal-proposed) [5.4.0-1045.48]
[10:01] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (focal-proposed) [5.4.0.1045.54]
[10:01] -queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-signatures-gcp [sync] (focal-proposed) [5.4.0-1045.48]
[10:06] -queuebot:#ubuntu-release- New binary: openjdk-18 [s390x] (impish-proposed/universe) [18~2-0ubuntu1] (no packageset)
[10:49] -queuebot:#ubuntu-release- New binary: openjdk-18 [amd64] (impish-proposed/universe) [18~2-0ubuntu1] (no packageset)
[11:05] <xnox> FYI! Uploading canary package for Zstd compression change in .deb https://bugs.launchpad.net/ubuntu/+source/hello/+bug/1923845
[11:05] <ubottu> Launchpad bug 1923845 in zeroinstall-injector (Ubuntu) "Please compress packages with zstd by default" [Undecided, New]
[11:48] -queuebot:#ubuntu-release- New binary: openjdk-18 [ppc64el] (impish-proposed/universe) [18~2-0ubuntu1] (no packageset)
[12:29] <seb128> hum, does anyone has an idea why impish ubuntu daily started failing on wed
[12:30] <seb128> checking the log it seems like the [ -e main/conf/uuid.conf ] check is failing?
[12:30] <seb128> in daily-live
[12:42] <seb128> hum
[12:43] <seb128> seems like the unmkinitramfs call on the initrd fails with a cpio error
[12:43] <seb128> what's going on?
[12:47] -queuebot:#ubuntu-release- New: accepted openjdk-18 [amd64] (impish-proposed) [18~2-0ubuntu1]
[12:47] -queuebot:#ubuntu-release- New: accepted openjdk-18 [s390x] (impish-proposed) [18~2-0ubuntu1]
[12:47] -queuebot:#ubuntu-release- New: accepted openjdk-18 [ppc64el] (impish-proposed) [18~2-0ubuntu1]
[12:52] -queuebot:#ubuntu-release- New binary: openjdk-18 [armhf] (impish-proposed/universe) [18~2-0ubuntu1] (no packageset)
[12:56] <xnox> seb128:  zstd compression by default.
[12:56] <xnox> seb128:  zstd not installed?
[12:56] <xnox> seb128:  can you please tell me where you see this error?
[12:59] <seb128> xnox, https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/impish/daily-live-20210618.log
[13:00] <seb128> xnox, same error on server, https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/impish/daily-live-20210618.log
[13:00] <seb128> xnox, or canary, https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/impish/daily-canary-20210618.log
[13:03] <xnox> sil2100: laney: how does one request for new packages to be installed on ubuntu-cdimage? what release does it run on? does its initramfs-tools support zstd? and if it does, does the host have zstd package installed?
[13:04] <ogra> probably 16.04 .... the buulders have traditionally been very conservative in the past (not sure that changed)
[13:04] <ogra> *builders
[13:05] -queuebot:#ubuntu-release- New: accepted openjdk-18 [armhf] (impish-proposed) [18~2-0ubuntu1]
[13:05] <xnox> ogra: they have been upgraded multiple times recently and moved to new hardware. pretty sure it is focal host.
[13:05] <ogra> ah, that would be nice
[13:06] <xnox> ogra: if you don't know for sure, please don't speculate.
[13:06] <ogra> i just remember nusakan and that was always rather on an ESM release
[13:06] <xnox> you have not been active ~ubuntu-cdimage for a while now?
[13:06] <xnox> nusakan is not the host in use anymore
[13:06] <ogra> i know
[13:06] <seb128> xnox, I'm curious but which upload or infra change trigger that behaviour change?
[13:08] <xnox> seb128:  https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu6 impish builds generate zstd compressed initrds by default now. But the debian-cd repacking code, and making matching uuid.conf in the .disk/ on the iso and inside the initrd runs wherever ubuntu-cdimage runs. As it needs to be able to extract the uuid from the initrd and put it on the iso.
[13:09] <seb128> xnox, ah, males sense, I checked the upload on the 15th but didn't go back far enough, that was one day earlier just was a blit slow to migrate
[13:09] <seb128> makes*
[13:09] <seb128> xnox, it's something to keep in mind for next initramfs changes, making sure the image builders can deal with the change
[13:12] <xnox> seb128: it looks like it cant'.
[13:12] <xnox> not sure if i should upload livebuild to ovveride compression back to lz4 whilst I sru initramfs-tools, or if i should revert the default in the initramfs-tools for now.
[13:13] <xnox> or install impish version of initramfs-tools on cdimage host
[13:16] <seb128> let's wait for someone from ubuntu-release to be around before deciding anything
[13:28] <juliank> laney: investigating apt regressions in hirsute, I guess we need to set "always-include-phased-updates" option inside autopkgtest, as I guess it's now applying it, and that's the reason apt-source ubuntu-advantage-tools is failing in https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/u/ubuntu-advantage-tools/20210618_132205_96afa@/log.gz
[13:28] <xnox> seb128:  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1932542
[13:28] <ubottu> Launchpad bug 1932542 in initramfs-tools (Ubuntu Focal) "Add support for zstd" [Undecided, In Progress]
[13:28] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu6.5 => 0.136ubuntu6.6] (core, i386-whitelist)
[13:28] <xnox> i will need/want SRU regardless, so at least i have prepared that.
[13:29] <seb128> xnox, thx
[13:29] <seb128> right
[13:29] <juliank> laney: I'm trying to reproduce on staging, but it seems to hang
[13:32] <cjwatson> xnox: ancientminister is 20.04, initramfs-tools 0.136ubuntu6.5, zstd package is not installed
[13:34] <cjwatson> xnox: that version of unmkinitramfs doesn't support zstd, so I think a fix will need to involve an initramfs-tools SRU to at least add minimal extraction support there
[13:37] <sil2100> xnox, seb128: it's running on 20.04 but I don't see zstd installed right now
[13:38] <sil2100> Oh, yes, cjwatson was first!
[13:38] <seb128> Coling just said that yes :)
[13:38] <juliank> --shell-fail shells not having job control, then you press Ctrl+C, and it kills the VM, is just a bad debug experience
[13:38] <seb128> installing zstd should be enough to fix the builds right?
[13:38] <sil2100> New packages are usually installed by requesting them via IS I think
[13:39] <cjwatson> seb128: No, because unmkinitramfs's xcpio function still won't attempt to call zstdcat
[13:39] <seb128> ah, right
[13:39] <cjwatson> sil2100: or by depending on them in an SRU, if that seems appropriate
[13:39] <seb128> any workaround we can do to get images building again until that SRU goes through?
[13:40] <cjwatson> IMO the correct approach would be to revert until focal's unmkinitramfs is confirmed to be able to cope
[13:41] <cjwatson> But if that isn't possible then I suppose could ask IS to manually install zstd and hack debian-cd to call zstdcat | something rather than unmkinitramfs
[13:48] <utkarsh2102> hey, can someone please TAL at https://code.launchpad.net/~utkarsh/britney/+git/britney/+merge/404374? Thanks!
[13:48] <utkarsh2102> it'll help phpunit migrate, finally
[13:50] <xnox> cjwatson:  juliank: please install zstd + need sru-accept of my initramfs-tools upload
[13:50] <xnox> cjwatson:  i don't like hacking debian-cd.
[13:51] <cjwatson> xnox: Won't be me, I'm just advising from memory :)
[13:51] <xnox> cjwatson:  i can upload live-build into impish to override initramfs compression to lz4 for now.
[13:58] <laney> juliank: we discussed that in #ubuntu-devel earlier. setting the option sounds good, it's one place you always want the new stuff, to make sure it's what is tested
[13:58] <laney> do it
[13:58] <laney> also, I think you can revert the grub hack too while you're there
[13:59] <juliank> laney: I'm adding the phased stuff to setup-testbed, as the phasing code is not ubuntu-specific (albeit debian does not use it)
[13:59] <laney> sounds good, make sure to forward it
[14:00] <juliank> test running now on https://autopkgtest.staging.ubuntu.com/running
[14:00] <juliank> I think it runs at autopkgtest time, not image build time
[14:00] <juliank> which would be convenient
[14:00] <juliank> if this runs at all
[14:00] <laney> what is "it"?
[14:02] <juliank> laney: setup-testbed
[14:02] <juliank> seems to have worked
[14:06] <juliank> laney: is there an official way to pull the repo on prod?
[14:07] <juliank> I think it pulls it in a timer?
[14:07] <juliank> I don't know
[14:09] <laney> juliank: action update-sources
[14:11] <juliank> laney: probably won't work as there's a local hack in there
[14:11] <laney> in where?
[14:11] <juliank> oh but it did
[14:11] <juliank> laney: on cloud worker
[14:11] <laney> why are there local hacks?
[14:11] <juliank> I don't know
[14:11] <laney> well revert it, commit it on the branch
[14:11] <juliank> -    if ! timeout 5m nova reboot --poll "$SRVUUID"; then
[14:11] <juliank> +    if ! timeout 2m nova reboot --poll "$SRVUUID"; then
[14:11] <juliank> it's not one of my things
[14:11] <laney> no idea
[14:12] <laney> kill it
[14:25] <laney> juliank: will you retry the failures?
[14:25] <juliank> i have
[14:25] <laney> nice
[14:25] <laney> N I C E
[14:28] <laney> sil2100: alright, gonna attempt to deploy your thing now
[14:29] <laney> hmm
[14:29] <laney> juliank: how should we keep track of what is deployed? like if I update staging from this branch
[14:29] <laney> tag when pushing a charm to the store?
[14:30] <juliank> laney: hmm
[14:30] <laney> then you can use juju status to see the revision, and look that up in git
[14:30] <juliank> laney: I push to staging before I push to the branch, so there's that
[14:30] <laney> don't :p
[14:30] <laney> or I guess a tag doesn't need to be on any branch does it
[14:31] <juliank> tags are on commits, not branches
[14:31] <juliank> :D
[14:31] <laney> 'zactly
[14:31] <laney> so you can just push the tag
[14:32] <laney> let's try to do that
=== fnordahl_ is now known as fnordahl
[15:43] <laney> juliank: what do you think about putting "channel: edge" for the workers / web for staging?
[15:48] <juliank> laney: that switches the default channel when pushing the charm? sounds like a superb idea to me
[15:49] <laney> that's the idea
[15:49] <laney> so you can use mojo for this
[15:54] <juliank> laney: new workflows :D
[15:56] <laney> :>
[15:56] <laney> getting semi modern *cough cough*
[16:02] <bdmurray> hey there autopkgtest people - I'm looking at https://autopkgtest.ubuntu.com/packages/t/thin/impish/amd64 and it passed in the end of April but now fails. Looking at the package it setups up a webserver listening at 0.0.0.0 and when trying to access that it gets a squid proxy page
[16:08] <bryceh> bdmurray, is its web server actually up and taking connections when the access attempt is made?
[16:11] <bryceh> bdmurray, the Thin::UnixConnection shows 127.0.0.1, could it be accessing 0.0.0.0 in error?
[16:12] <bdmurray> bryceh: it passes for me locally
[16:14] <laney> do you have a proxy locally?
[16:16] <bdmurray> Nope, but the same version of the package passed in late April and isn't now.
[16:16] <laney> Plenty in the archive will have changed since then though
[16:22] -queuebot:#ubuntu-release- Unapproved: accepted gupnp [source] (focal-proposed) [1.2.4-0ubuntu1]
[16:53]  * laney fixes some things in the private branch ;-)
[16:57] <laney> some more
[17:00] <laney> right, now it's running
[17:01] <laney> sil2100: you can try that now
[17:01] <laney> there's one bug in the charm - it didn't write the updated web config, we need to fix that somehow (add another flag?)
[17:01] <laney> and I didn't test the worker side
[17:01] <laney> also some of those bugs were real brown paper bag ones, should fix the testsuite :/
[17:38] <juliank> laney: Does setup-testbed run automatically on a local machine if I run autopkgtest?
[17:38] <juliank> laney: I definitely have to SRU _something_ to make local autopkgtests work in hirsute and newer
[17:38] <juliank> (when using VMs)
[17:40] <juliank> I see the -build- scripts run it, which is probably good enough
[17:41] <juliank> I need/want to fix chrooty/containery stuff too this cycle
[20:49] <bryceh> if any @ubuntu-archive are around, we could use help processing https://bugs.launchpad.net/ubuntu/+source/twig-extensions/+bug/1932967
[20:49] <ubottu> Launchpad bug 1932967 in twig-extensions (Ubuntu) "Please remove twig-extensions from Impish" [Undecided, New]
[21:52] <jawn-smith> I still think this is a flakey test, especially when looking back at the historical results on hirsute. Is any core dev available to try this again? https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=arm64&package=opensaml&trigger=glibc/2.33-0ubuntu8
[21:52] <jawn-smith> please and thank you
=== mwhudson_ is now known as mwhudson
[22:19] <bdmurray> jawn-smith: I clicked it