[03:40] <toabctl> could somebody retrigger autopkgtests for https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1930686 please? ubuntu-image failed with a 503 when trying to download a snap from the store.
[03:47] <mwhudson> toabctl: done
[03:47] <toabctl> thanks mwhudson
[08:35] <cpaelzer> hi utkarsh2102
[08:35] <cpaelzer> utkarsh2102: is it still the non-recreatable armhf issue that blocks schleuder ?
[08:35] <utkarsh2102> cpaelzer: yep, that's correct.
[08:35] <utkarsh2102> I'm trying hard for it to fail, but it doesn't.
[08:36] <cpaelzer> could you give me a short list of way that you tried and failed?
[08:36] <utkarsh2102> cpaelzer: yep, in a minute
[08:36] <cpaelzer> I want to check if I have any other idea and maybe could try to set up a test env for you having a look there then
[08:38] <utkarsh2102> cpaelzer: I tried on arm64 img + armhf container to get the autopgtest to fail, it didn't. Neither via `-- null` or `-- schroot`. Though when I see the tests running on the builders, I see that the armhf takes > 15m to run the same thing which other architectures finish in about 9m.
[08:39] <utkarsh2102> This makes me think if the tests fail because it's a slow machine/builder.
[08:39] <utkarsh2102> So I increased the timeout of curl here: https://salsa.debian.org/ruby-team/schleuder/-/blob/master/debian/tests/schleuder-api-daemon-reachable#L6
[08:40] <utkarsh2102> from 5 to 15, uploaded to a PPA but no luck. Probably worth increasing it to 60s?
[08:44] <utkarsh2102> interestingly test_v4 doesn't return "status: ok" but test_v6 does and since it's OR conditional, it should still pass. So..
[08:49] <utkarsh2102> cpaelzer: on a different note, is there someone I can ping for LP: #1931257? I did ping in -release, but probably no one could get to it. I don't mind waiting as long as I know someone will take a look whenever they have time.
[08:55] <cpaelzer> utkarsh2102: you'd ping ubuntu-archive in #ubuntu-release the team is supposed to highlight on it
[08:56] <utkarsh2102> I did.
[08:56] <cpaelzer> utkarsh2102: obviously if you know and see someone around feel free to ping him directly
[08:56] <cpaelzer> If unsure you can check here who belongs to the team https://launchpad.net/~ubuntu-archive/+members
[08:57] <cpaelzer> utkarsh2102: when you said "arm64 img + armhf container" that was a canonistack arm64 right?
[08:59] <cpaelzer> and you said null/schroot - did you have a look/try on autopkgtest-virt-lxd ?
[09:00] <cpaelzer> if not armhf I'd say try autopkgtest-virt-ssh + nova, but I'm unsure how that would work for armhf
[09:00] <cpaelzer> here is an example for nova e.g. to run on x86 #~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries --apt-upgrade --setup-commands setup-testbed --shell-fail systemd_247.3-1ubuntu2.dsc -- ssh -s nova -- --flavor m1.small --image ubuntu/ubuntu-hirsute-daily-amd64-server-20201126-disk1.img --keyname paelzer_canonistack-bos01
[09:00] <utkarsh2102> cpaelzer: yep, that was canonistack.
[09:01] <utkarsh2102> right, thanks! but the problem is that it passes although I'll give the above way a shot
[09:02] <cpaelzer> tried lxd runner on that arm64 host ?
[09:02] <cpaelzer> autopkgtest --apt-upgrade --shell-fail schleuder.dsc -- lxd images:ubuntu/impish/armhf
[09:02] <utkarsh2102> yep, passed.
[09:02] <cpaelzer> also was the host small&slow enough, you could have a flavour that is much bigger/smaller than the one used for the test ?
[09:03] <utkarsh2102> m1.large was the flavor, I used
[09:04] <utkarsh2102> I could use small or micro, but unsure if it's going to work
[09:04] <utkarsh2102> do you think it's worth checking w/ timeout increased to 60s or 100s?
[09:04] <cpaelzer> IF we are out of better options, then yes
[09:15] <doko> seb128, the lto-disabled-list is a hack for packages not in main.  is there a rationale not to file a bug report about the ftbfs? Now done as LP: #1931383
[09:25] <seb128> doko, thanks, and no there was no rational, you were the one who added the delta so I though you had done that, was just checking if we could back in sync... couldn't we add main packages to that hack list rather than carry delta to merge with every Debian upload? it would lower you maintainance
[09:33] <doko> seb128, no, we even added a MIR policy to disallow packages in main on this list
[09:35] <mwhudson> who can i talk to about seeds and germinate?
[09:35] <mwhudson> (not now, my brain isn't up to talking about it now)
[09:36] <cpaelzer> mwhudson: when I proposed changes in the past they got merged by cjwatson
[09:37] <cpaelzer> so if you just need someone, I'm here - but if you need the main authority then I guess cjwatson :-)
[09:37] <laney> yeah depends how Deep you want to get
[09:38] <laney> plenty of us in the shallow end
[09:47] <seb128> doko, so we carry a delta for the same result just at an higher cost...
[09:48] <doko> yes, there is a cost, but there are higher costs in other cases for not carrying a delta, and not addressing stuff in Ubuntu
[09:49] <slyon> sergiodj: hey! Is Canonistack working for you again after RT#130493 was resolved? I still see error 503 when trying to create new instances and I'm considering to open a new RT.
[09:50] <cpaelzer> slyon: he's not yet around, but will be after ~"your lunchtime"
[09:50] <slyon> cpaelzer: thanks, that should be soon enough
[10:41] <cpaelzer> utkarsh2102: since I had an instance it was easy to try and for me schleuder@armhf works as well
[10:42] <cpaelzer> utkarsh2102: maybe consider filing a test hint with the argument of non-resaonable-debuggability and since being tested on all other architectures armhf could be ignored
[10:48] <utkarsh2102> cpaelzer: sounds like a plan! will do, thank you!
[12:38] <sergiodj> slyon: hey!  I'm still getting a 503 from time to time, but last time I checked it was working
[12:39] <sergiodj> at least I was able to reserve machines and use them without problems
[12:43] <slyon> okay thanks, that's good to know!
[12:45] <sergiodj> np!
[21:57] <mwhudson> hmm is there some way to predict the impact of a seed change on Task fields without running archive publication locally?
[21:57] <mwhudson> i guess just mirroring and publishing main might not be _that_ painful
[22:02] <cjwatson> it's a bit complicated but running germinate on the local seed branch should give you a decent first approximation
[22:04] <TJ-> Is there anyone can take a look at this? it may infer some changes are needed to initramfs-tools defaults. Bug #1931024
[22:06] <mwhudson> cjwatson: yeah running germinate is easy enough
[22:32]  * mwhudson reads generate_extra_overrides.py and gets a bit confused
[23:11] <mwhudson> cjwatson, vorlon: the text of the minimal seed talks about it getting processed to priority: important, where does that happen?
[23:12] <cjwatson> mwhudson: https://bazaar.launchpad.net/+branch/ubuntu-archive-tools/view/head:/priority-mismatches
[23:12] <cjwatson> mwhudson: which generates https://people.canonical.com/~ubuntu-archive/priority-mismatches.html
[23:13] <mwhudson> ahah
[23:15] <mwhudson> cjwatson: is the ~/mirror/ubuntu-germinate directory this refers to published anywhere?
[23:17] <mwhudson> i guess it's just files like https://people.canonical.com/~ubuntu-archive/germinate-output/edubuntu.xenial/minimal but with a different name
[23:19] <mwhudson> vorlon, cjwatson: so if, uh, you wanted to split the minimal seed in two this needs to change i guess