[05:41] <vorlon> juliank: fwiw after applying the apt-get install --fix-policy hack, I still see the following in the build logs; any idea why --fix-policy doesn't take care of this? Calculating upgrade...  ignore old unsatisfied important dependency on e2fsprogs-l10n:amd64
[06:45] <ginggs> those PEP-668 changes were in python3.11 3.11.2-3, and 3.11.2-4 is currently in -proposed
=== m_ueberall is now known as ueberall
[07:33] <cpaelzer> dannf: FYI I still see some edk2 timeout on x86 https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/e/edk2/20230302_173015_62004@/log.gz
[07:33] <cpaelzer> dannf: but they locally are just fine (and fast) at 5-7s execution time
[07:34] <cpaelzer> dannf: I've explcitly retriggered with -5 if that makes any different in the autopkgtest infrastructure runs
[07:43] <zhsj> could someone sync arno-iptables-firewall (bug 2009123). it should help kmod proposed migration.
[07:43] -ubottu:#ubuntu-devel- Bug 2009123 in arno-iptables-firewall (Ubuntu) "Sync arno-iptables-firewall 2.1.1-7 (universe) from Debian unstable (main)" [Undecided, New] https://launchpad.net/bugs/2009123
[07:55] <zhsj> oh kernel has just migrated. so another reference run for arno-iptables-firewall also helps. but syncing the fixed version seems better.
[08:41] <ginggs> zhsj: .
[12:52] <danilogondolfo> Looking for a friend to click this link for me :) https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=rspamd&trigger=lsb/11.6&trigger=rspamd/3.4-1
[12:53] <mdeslaur> danilogondolfo: clicked!
[12:53] <danilogondolfo> mdeslaur, thank you!
[13:14] <ahasenack> Eickmeyer: hi, I didn't see the sddm original bug on my system, sorry. This was with sddm on kinetic, updates, but the same thing happened with sddm from the release pocket: https://www.youtube.com/watch?v=SgiEUxdz1JY
[14:58] <Eickmeyer> ahasenack: Huh. I wonder if it's nvidia optimus related then and the underlying qt bug in kinetic is fixed in which case the bug in kinetic is invalid, but regardless the script is crashing in kinetic.
[14:58] <Eickmeyer> I'll have the people who reported the issue test Jammy.
[15:25] <enr0n> Can a core dev please retry this test? It passed for me locally. https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=software-properties&trigger=software-properties%2F0.99.33
[15:27] <juliank> done
[15:39] <dannf> cpaelzer: weird. i should probably add timing stats into the tests by default. how about I do that and also bump to timeout to 60s?
[22:00] <cpaelzer> dannf: I've had good results with using pytest and adding --durations=0 to get some insight in the duration it actually takes
[22:00] <cpaelzer> dannf: and yes, given what we see doubling the timeout (and then looking at the results we get on the autopkgtets infra) should be good
[22:02] <dannf> cpaelzer: i realized we're already at 60s, which seems like it should be plenty. i'm running a test w/ a package in ppa:dannf/edk2 that reports test times to see if it follows any particular test type
[22:04] <dannf> i'll look at bumping to 120s if that doesn't turn up anything obvious.
[22:06] <dannf> hm.. xorriso output in the existing logs has timing, could see if that points to general IO slowness
[22:09] <cpaelzer> dannf: on my laptop all is int he 5-7s range and works just fine each time
[22:09] <cpaelzer> dannf: curious what timing you will see on the infrastructure
[22:11] <dannf> cpaelzer: "xorriso : UPDATE : Thank you for being patient. Working since 13 seconds." in https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/e/edk2/20230303_211732_cfb9e@/log.gz - that seems awfully slow
[22:12] <dannf> "xorriso : UPDATE : Thank you for being patient. Working since 23 seconds." in https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/e/edk2/20230303_211732_cfb9e@/log.gz
[22:14] <dannf> er https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/e/edk2/20230222_131732_f2176@/log.gz for the 23s one