[04:08] <alkisg> ty mwhudson :)
[08:01] <cpaelzer> rbasak: sil2100: is there a good way to bring https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936 to the SRU team for an evaluation and decision?
[08:01] <cpaelzer> It would be a no-change rebuilt, so there is no actual debdiff content to review in this case
[08:01] <cpaelzer> more the implications it will have as outlined in the SRU template
[08:03] <cpaelzer> I can upload a rebuild, but taking this as a precedent I wondered if there are other ways to get things onto your queues?
[08:09] <oysteins> Does anyone know in which package the text for unlocking a LUKS partition is (the "Please unlock [partition]" text that appears on boot)?
[08:09] <oysteins> Someone suggested cryptsetup-initramfs, but it's not on Launchpad, and the text isn't in the cryptsetup package either.
[08:11] <Faux> https://codesearch.debian.net/search?q=enter+passphrase&literal=1
[08:11] <RAOF> cpaelzer: Uploading a no-change rebuild (with bug link in the changelog) is a perfectly fine way of getting it on our queue.
[08:13] <oysteins> Faux: Wow, thanks. :-)
[08:24] <cpaelzer> ok RAOF, thanks
[08:25] <oysteins> The weirdest thing; there's no string "Please enter passphrase for disk %s:" in cryptsetup, cryptsetup-luks or systemd on translations.launchpad.net/ubuntu/eoan
[08:26] <cpaelzer> oysteins: could it be https://codesearch.debian.net/show?file=cryptsetup_2%3A2.2.0-3%2Fdebian%2Finitramfs%2Fcryptroot-unlock&line=184
[08:27] <cpaelzer> but you sid it isn't cryptsetup .. hmmm
[08:29] <oysteins> Hm, no package called cryptroot on Launchpad. There is a package called cryptsetup-initramfs in Ubuntu repos, though.
[08:50] <rbasak> cpaelzer: I've added it to a list for discussion
[08:50] <RAOF> oysteins: that's in the cryptsetup source package
[09:00] <rbalint> RAOF, could you please check this hint for systemd? https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/372181
[09:02] <RAOF> Hm. We don't still need the ppc64el hint for the old version, right?
[09:04] <RAOF> When's the next upload (mentioned as “this hint will be made unnecessary by the next upload”)
[09:06] <rbalint> RAOF, in a few days hopefully, but i'd like to have this migrated without a rebuild because it triggers a lot of tests and rebuilding it would pick up new glibc
[09:07] <RAOF> Sure. I'm not at a computer right now, so I can't actually merge it, but that seems sane.
[09:09] <rbalint> RAOF, also the old version is gone from the archive
[09:09] <RAOF> Right, so you can clean up the badtest line by removing the reference to the old version?
[09:10] <rbalint> RAOF, could you please merge it later today or i should ping other AAs?
[09:10] <rbalint> RAOF, exactly
[09:16] <cjwatson> Laney: Huh, so I figured out what's going wrong with the image build failures from yesterday - iptables in eoan is now effectively nftables, iptables-legacy is there for the older kernel interface, and it all gets a bit confusing when you run the newer version in a container when the host system already has rules set up using the older version.  Trying to work out the exact constraints ...
[09:17] <cjwatson> tobikoch: ^- FYI this is what you were asking about the other day
[09:39] <RAOF> rbalint: I can merge it later, before my 9pm meeting 😀
[09:41] <RAOF> rbalint: actually… now that I look at it again, will that actually mark the test as bad? You've dropped the `force-badtest` directive from the start of the line.
[09:48] <Laney> cjwatson: Huh indeed
[09:48] <Laney> so I guess it's trying to talk nftables to an iptables-using kernel, which isn't going to work AIUI
[09:52] <cjwatson> Might be kernel version, might be confusion with existing rules
[09:52] <cjwatson> Trying to narrow that down with a small pile of VMs on Canonistack at the moment :)
[09:53] <cjwatson> It doesn't seem to *completely* fail to talk nftables - it seems to add the rule, but in a slightly weird way, and then indeed it can't remove it again
[09:58] <Laney> I wonder if it'll work, even if you do manage to wangle it so that the rule can be inserted & deleted properly (it was my understanding that you can't mix them, BICBW)
[10:00] <cjwatson> Even in that case I still want to work out exactly how to detect the situation from livecd-rootfs
[10:35] <RAOF> rbalint: Bah, also, I can't actually merge it - you're after a release team member, not an AA. Oops!
[10:45] <rbalint> RAOF, i fixed the the line now
[10:45] <rbalint> RAOF, ah, i thought you wear that hat, too, thanks for the review then
[10:46] <rbalint> sil2100, Laney: could you please check this hint for systemd? https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/372181
[10:50] <cjwatson> On bionic and disco kernels, iptables at least inserts the rule into just the OUTPUT chain rather than all chains in the nat table.  Still can't delete it though
[11:16] <cjwatson> (Also, on >=bionic kernels, the redirect rule actually works; on xenial it doesn't)
[11:47] <sil2100> rbalint: looking in a moment
[12:22] <ahasenack> cpaelzer: are you uploading rafaeldtinoco's ocfs2-tools?
[12:31] <cpaelzer> ahasenack: I haven't checked mails for a while
[12:31] <cpaelzer> ahasenack: if he said "please do so then I will"
[12:31] <cpaelzer> ok seeing the MP update
[12:31] <cpaelzer> yes I'll do the sponsoring
[12:32] <ahasenack> thx
[12:40] <ahasenack> rbasak: the php7.3 excuses page is live, since yesterday's fix for the universe dependencies
[12:40] <ahasenack> rbasak: but it's showing tests results from early august
[12:40] <ahasenack> rbasak: they used mysql 5.7, not 8. A few red ones used mysql-8
[12:45] <Skuggen> ahasenack: Where is that page (I might have input for mysql)?
[12:45] <ahasenack> Skuggen: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.3
[12:46] <ahasenack> my question is why the tests were apparently run before php7.3 was ready. It was showing "not considered" due to missing dependencies, but that was only fixed yesterday, and the test timestamps that suddently showed up are from weeks ago
[12:47] <Skuggen> Oh, I had that page up, maybe I just misunderstood the issue
[12:57] <rafaeldtinoco> cpaelzer: ahasenack: tks
[13:18] <ddstreet> Laney thnx for autopkgtest-cloud mojo branch link, i had been using master branch, i'll give that one a try deploying :)
[13:18] <rbasak> ahasenack: I believe the algorithm is that it initially looks for autopkgtest results that match its criteria, and only if they aren't present does it request new runs.
[13:18] <rbasak> ahasenack: so the logic probably just thinks that the historical results are acceptable.
[13:19] <ahasenack> rbasak: well, those greens cannot be trusted
[13:20] <ahasenack> rbasak: the log from early august does show 7.3.8 was used, which is what was uploaded
[13:20] <rbasak> ahasenack: I believe that if we manually rerun tests, the new ones will be picked up instead.
[13:20] <ahasenack> so the tests ran before the deps check was resolved
[13:20] <rbasak> Providing the triggers are correct.
[13:23] <ahasenack> rbasak: my surprise is that there shouldn't have been "historical results" for 7.3.8, given it had that universe dependency issue we uncovered yesterday
[13:24] <ahasenack> looks like the tests are run before, and that check just hides them if it fails
[13:26] <rbasak> ahasenack: I think it's understood that the current infrastructure doesn't really ensure that tests are run with the correct combination of packages but only an approximation
[13:27] <ahasenack> rbasak: I think all tests need to be re-run. If only those red ones are fixed, it might migrate without having been exposed to mysql-8
[13:27] <rbasak> ahasenack: that sounds right
[13:35] <ddstreet> sil2100 hey, minor point re: the new 'autopkgtest regression report' emails, the proposed-migration url link is line-wrapped, making it not clickable, e.g. https://lists.ubuntu.com/archives/ubuntu-sponsors/2019-September/063139.html
[13:37] <Laney> ddstreet: looks like that's done by pipermail? https://bugs.launchpad.net/cloud-utils/+bug/1836593/comments/4 seems ok to me
[13:37] <ddstreet> Laney ah well that's annoying then, wonder if pipermail has an option to not do that
[13:39] <ddstreet> Laney if pipermail is just the archiver, then it's earlier than that i think, as it's line-wrapped in my inbox
[13:39] <Laney> could be
[13:47] <rcj> cjwatson: I was out yesterday but I'm reading the backlog on the iptables issues in eoan builds.  Looks like the magic-proxy isn't working at all on eoan (based on 0-byte logs) while only i386 fails due to the rule removal failure.  Are you still chasing this down in the builders?
[13:48] <rcj> Laney: I was out but I see that your livecd-rootfs change causes our builds to fail now for cloud-images because the variable is unset outside the preseeda and we're running with 'set -u'
[13:49] <Laney> ah man
[13:49] <Laney> I ran the autopkgtests, guess there isn't one for this case
[13:49] <rcj> I guess not :-/
[13:50] <cjwatson> rcj: I'm still chasing it down, yes.  Almost done
[13:50] <cjwatson> rcj: (none of it is a problem with the builders, incidentally - it's all to do with iptables, although one part of it can sensibly be handled in livecd-rootfs IMO)
[13:51] <rcj> cjwatson: thank you.  I was worried that you had to put in code to download 0-byte files and you said the magic-proxy log was empty, but it was hard to know what was going on without logs from failed builds (which aren't so helpful anyhow)
[13:51] <cjwatson> Yeah, it's empty and that is indeed a problem.  I only worked around it because the failure mode was excessively obscure
[13:52] <cjwatson> rcj: There are two problems: one is that livecd-rootfs needs to run iptables-legacy on old kernels; the other is https://bugs.debian.org/939336 which I just filed
[13:52] <cjwatson> rcj: The workaround for the first part will avoid the second for now though
[13:53] <Laney> rcj: https://paste.debian.net/1098560/ ?
[13:54] <rcj> Laney: that works
[13:54] <Laney> ok, I pushed that
[13:54] <Laney> thanks for the heads up
[13:54] <rcj> Laney: thank you
[13:55] <rcj> Laney: we'll add a task to get the tests updated
[13:55] <Laney> neat
[14:02] <rcj> cjwatson: I'm trying to decide if we should check something in livecd-rootfs to decide which to use or use iptables-legacy unconditionally as builders are the intended environment.
[14:02] <cjwatson> rcj: I think a kernel version test is closer to being correct, and that's what I'm testing at the moment
[14:03] <cjwatson> rcj: Testing for whether it's on a builder, or being unconditional, are both incorrect - at some point we'll upgrade build VMs to bionic, and at that point the nft-based iptables works (modulo the i386 bug)
[14:04] <cjwatson> I haven't narrowed down exactly which kernel versions are too old for the nft-based iptables to work properly, but 4.4 fails and 4.15 works, which is good enough information
[14:04] <cjwatson> https://paste.ubuntu.com/p/XYhpDQ87p5/ is the patch I'm testing at the moment
[14:24] <cjwatson> rcj,Laney: Could you review https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/372203 ?  I've tested it locally and it seems to be behaving itself?
[14:24] <cjwatson> s/\?$/./
[14:31] <rcj> cjwatson: That looks good
[14:34] <cjwatson> Thanks.  Will get that uploaded
[14:34] <cjwatson> (including Iain's changes)
[14:36] <cjwatson> Uploaded
[14:44] <Laney> thanks
[15:40] <ahasenack> rbasak: php-horde-db (http://autopkgtest.ubuntu.com/packages/p/php-horde-db/eoan/amd64) ran with mysql-8, but that run was with php7.3
[15:41] <ahasenack> rbasak: the php-defaults run was with with mysql8 too, but php 7.3.6 (not 7.3.8)
[16:00] <rbasak> ahasenack: that's good at least
[16:00] <rbasak> So it's not that the tests were skipped entirely
[16:00] <rbasak> Only the current problem of needing to tweak them to be against the right thing
[16:01] <ahasenack> rbasak: just talked about it in #ubuntu-release
[16:02]  * ahasenack -> quick lunch
[18:38] <tumbleweed> cyphermox: a year ago, you added ubuntu-archive-assistant to ubuntu-dev-tools source, but nothing to actually install it
[18:38] <tumbleweed> am I missing something?
[18:40] <cyphermox> not really, I was so far only using that from the git tree; and there's been pushback on having it there
[18:40] <cyphermox> also, kinda lacking time to look at it :/
[18:41] <tumbleweed> OK, I'll leave it to languish there
[18:42] <cyphermox> feel free to remove if it's in the way; I have the code elsewhere too. no clue if people actually use that for proposed migration or MIR review
[18:42] <cyphermox> (aside from me, I mean)
[21:10] <choon> test
[21:12] <sarnold> pong