[02:43] <alkisg> Hi, I'd like to help in getting the patch in https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/1867908 accepted for Focal, how can I help? Send it as a debdiff instead of a .patch?
[02:49] <sarnold> alkisg: I can't promise anything, but a tested debdiff, and descriptions of how to test, would probably help, yes
[02:49] <alkisg> sarnold: thank you, I will try to do that later on today
[07:39] <alkisg> sarnold: I uploaded a merge request for LP bug #1867908, and I've tested the generated .deb package for four wifi adapters that I had, and it solved the issue for all of them. If/when you have time, please have a look, thank you!
[09:25] <seb128> xnox, hey, you hacked on casper/plymouth before, do you maybe have debugging hint you can share on bug #1867909 ?
[16:38] <rbasak> bryce: here's the MP: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/381116
[16:55] <bryce> rbasak, thanks
[18:36] <doko> tjaalton: dogtag-pki is missing build-deps, trying to download stuff during the build
[18:44] <tjaalton> doko: yes, somehow it wasn't an issue on debian, but -1u1 fixes it
[18:50] <ahasenack> hi, some imput please. I was tasked with adding "tests" to a package that is going through a MIR (libfido2). The package has regression tests, but they are only enabled in a debug build. So I added this as DEP8: https://paste.ubuntu.com/p/ns5WzVcCnH/
[18:51] <ahasenack> I do a build with debug enabled, which is enough to run the tests. To be sure, I do another run, where I patch a test to fail, and then expect the test run to fail, that way I'm sure the tests were being run
[18:51] <ahasenack> when they pass, they are invisible
[18:51] <ahasenack> now, I could have done the same thing in a dh_auto_test override in d/rules
[18:51] <ahasenack> what do you think is better?
[18:51] <ahasenack> sarnold: ^
[18:51] <doko> tjaalton: debian buildds have network access
[18:52] <ahasenack> this is the good dep8 output: https://pastebin.ubuntu.com/p/KQqcfYPtFv/
[18:52] <ahasenack> this is when the expected failure doesn't happen: https://pastebin.ubuntu.com/p/JqttQZCSrN/
[18:53] <sarnold> ahasenack: "Expected regression test failure did not happen", nice
[18:53] <tjaalton> doko: huh, ok
[18:53] <ahasenack> sarnold: I commented out the patch on that run
[18:54] <ahasenack> the patch that introduced the failure
[18:54] <ahasenack> for srus, I generally feel that a build-time test is more effective, as excuses will be looked at much later after the package was built, once the sru is accepted
[18:55] <sarnold> ahasenack: it's not the easiest thing to try to convey that something should have failed, but it didn't fail, and that's a failure :)
[18:55] <sarnold> ahasenack: but this does a good job of it, well done
[18:55] <ahasenack> thanks
[18:56] <ahasenack> the messaging in the good case should be better, after all, anyone looking will see a core dump, and go wtf
[18:56] <ahasenack> why did this pass
[18:57] <sarnold> ahasenack: I don't know what the dh_auto_test override would look like, but this looks nice to me
[18:57] <ahasenack> it would be similar. I would create an empty directory, cd into it, invoke the build with the debug parameter
[18:58] <ahasenack> might use sed instead of a patch to change the source for the expected failure case, and do it again
[18:58] <ahasenack> and I think it would be easier for the security team, since you usually can't use the public dep8 infrastructure to test packages
[18:59] <ahasenack> so if you see a failure in your private ppa, that's immediate
[18:59] <sarnold> oh, right, so .. that'd be double the build time, roughly, but provide 'instant' feedback?
[19:00] <ahasenack> 3 times
[19:00] <ahasenack> the real build, then build 1 for the good case, build 2 for the bad case
[19:00] <ahasenack> all 3 took about 5min on my laptop
[19:00] <sarnold> oh right
[19:00] <ahasenack> together
[19:00] <sarnold> wow, that's a lot better than I feared
[19:00] <sarnold> (same as the autopkgtest, I expected that runtime to be worse too)
[19:00] <ahasenack> well, 5min was with dep8, and in my dep8 run i was also building the package itself
[19:01] <ahasenack> I can experiment without throwing this away
[19:06] <Laney> ahasenack: The best autopkgtests are supposed to test the artifacts that users will run; building something and then testing that thing is not really ideal in that respect
[19:06] <Laney> If you can build the tests and then convince them to run against the system's stuff, ...
[19:07] <ahasenack> Laney: agreed, I have seen dep8 tests being just unit tests, and wondered why they were never run at build time
[19:07] <ahasenack> turns out some are, and again as dep8. I think the latter is to check interactions with other packages in the system, that were not there at build time (different versions?)
[19:10] <Laney> I guess you can summarise it as "is the package in the archive still working properly?" - you should be trying to write autopkgtests which answer that question IMO
[19:12] <Laney> build-time tests are: is that thing I just built something which works properly?
[19:24] <ahasenack> sarnold: ok, now it's at build time
[19:24] <ahasenack> sarnold: https://paste.ubuntu.com/p/gnP7FFRSqp/ <-- when the injected failure did not happen
[19:25] <ahasenack> https://paste.ubuntu.com/p/PYWSksqBXC/ <-- when it happened and was caught
[19:25] <ahasenack> for both cases, scroll to the bottom
[19:25] <ahasenack> actually, for the good case, go to line 4925: SUCCESS, the expected failure happened.
[19:25] <ahasenack> easier to find
[19:26] <ahasenack> I'll add some more verbosity and call it good, and submit an MP
[19:26] <sarnold> ahasenack: very nice, thanks!
[20:10] <doko> rafaeldtinoco: you merged kmod to suppress warnings, however these still show up in every autopkg tests. could you have a look? see https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1864992
[20:10] <doko> sforshee: ^^^
[20:16] <doko> so why didn't that help?
[20:24] <rafaeldtinoco> doko: will check
[20:25] <rafaeldtinoco> doko: https://git.launchpad.net/~rafaeldtinoco/ubuntu/+source/kmod/commit/?id=d08be3cad6af9e1d414af1aed7cdaa158f43773c
[20:25] <rafaeldtinoco> this is the fix
[20:25] <rafaeldtinoco> -proposed for bionic and eoan
[20:26] <doko> but not working in focal
[20:26] <rafaeldtinoco> hum. ok]
[20:26] <rafaeldtinoco> let me fix it
[20:26] <doko> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/d/doit/20200323_182614_c1613@/log.gz
[20:27] <rafaeldtinoco> doko: alright, ill push a fix in a few
[20:27] <rafaeldtinoco> focal is still applying that patch, I missed that before the sru
[20:28] <doko> so maybe also merge from debian
[20:29] <rafaeldtinoco> there was a fight about this fix and we decided to drop that change while they decided
[20:29] <rafaeldtinoco> lets see if they got that sorted out
[20:32] <rafaeldtinoco> ah great they dropped it
[21:28] <rafaeldtinoco> doko: kmod gets updated after linux-image and thats why there is still errors there. you can see kmod being updated *after* The kernel gets updated
[21:28] <rafaeldtinoco> so you would have to wait for the cloud images to get kmod updated
[21:28] <rafaeldtinoco> paride: ^
[21:29] <rafaeldtinoco> paride: as you opened this bug.. just to make sure we get kmod updated in cloud images
[21:29] <rafaeldtinoco> orelse kernel updates might take end users crazy with those libkmod error messages
[21:29] <rafaeldtinoco> (if kernel is updated before kmod)
[22:11] <LocutusOfBorg> rbalint, hello kodi* syncs?
[22:25] <rbalint> they would just drop the delta
[22:25] <rbalint> LocutusOfBorg where it mattered i've already synced