[02:43] 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:43] Launchpad bug 1867908 in wpasupplicant (Ubuntu) "Patch for MAC randomization" [Undecided,New] [02:49] alkisg: I can't promise anything, but a tested debdiff, and descriptions of how to test, would probably help, yes [02:49] sarnold: thank you, I will try to do that later on today [07:39] 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! [07:39] Launchpad bug 1867908 in wpasupplicant (Ubuntu) "Patch for MAC randomization" [Undecided,New] https://launchpad.net/bugs/1867908 [09:25] xnox, hey, you hacked on casper/plymouth before, do you maybe have debugging hint you can share on bug #1867909 ? [09:25] bug 1867909 in plymouth (Ubuntu) "plymouth spinner can not show the messages after installation." [Medium,Confirmed] https://launchpad.net/bugs/1867909 === Wryhder is now known as Lucas_Gray === didrocks999 is now known as didrocks [16:38] bryce: here's the MP: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/381116 [16:55] rbasak, thanks === Enlik is now known as Guest42372 === Guest42372 is now known as Enlik [18:36] tjaalton: dogtag-pki is missing build-deps, trying to download stuff during the build [18:44] doko: yes, somehow it wasn't an issue on debian, but -1u1 fixes it [18:50] 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] 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] when they pass, they are invisible [18:51] now, I could have done the same thing in a dh_auto_test override in d/rules [18:51] what do you think is better? [18:51] sarnold: ^ [18:51] tjaalton: debian buildds have network access [18:52] this is the good dep8 output: https://pastebin.ubuntu.com/p/KQqcfYPtFv/ [18:52] this is when the expected failure doesn't happen: https://pastebin.ubuntu.com/p/JqttQZCSrN/ [18:53] ahasenack: "Expected regression test failure did not happen", nice [18:53] doko: huh, ok [18:53] sarnold: I commented out the patch on that run [18:54] the patch that introduced the failure [18:54] 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] 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] ahasenack: but this does a good job of it, well done [18:55] thanks [18:56] the messaging in the good case should be better, after all, anyone looking will see a core dump, and go wtf [18:56] why did this pass [18:57] ahasenack: I don't know what the dh_auto_test override would look like, but this looks nice to me [18:57] it would be similar. I would create an empty directory, cd into it, invoke the build with the debug parameter [18:58] might use sed instead of a patch to change the source for the expected failure case, and do it again [18:58] 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] so if you see a failure in your private ppa, that's immediate [18:59] oh, right, so .. that'd be double the build time, roughly, but provide 'instant' feedback? [19:00] 3 times [19:00] the real build, then build 1 for the good case, build 2 for the bad case [19:00] all 3 took about 5min on my laptop [19:00] oh right [19:00] together [19:00] wow, that's a lot better than I feared [19:00] (same as the autopkgtest, I expected that runtime to be worse too) [19:00] well, 5min was with dep8, and in my dep8 run i was also building the package itself [19:01] I can experiment without throwing this away [19:06] 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] If you can build the tests and then convince them to run against the system's stuff, ... [19:07] Laney: agreed, I have seen dep8 tests being just unit tests, and wondered why they were never run at build time [19:07] 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] 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] build-time tests are: is that thing I just built something which works properly? [19:24] sarnold: ok, now it's at build time [19:24] sarnold: https://paste.ubuntu.com/p/gnP7FFRSqp/ <-- when the injected failure did not happen [19:25] https://paste.ubuntu.com/p/PYWSksqBXC/ <-- when it happened and was caught [19:25] for both cases, scroll to the bottom [19:25] actually, for the good case, go to line 4925: SUCCESS, the expected failure happened. [19:25] easier to find [19:26] I'll add some more verbosity and call it good, and submit an MP [19:26] ahasenack: very nice, thanks! [20:10] 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] Launchpad bug 1864992 in kmod (Ubuntu Focal) "depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'" [Medium,New] [20:10] sforshee: ^^^ === vorlon` is now known as vorlon [20:16] so why didn't that help? [20:24] doko: will check [20:25] doko: https://git.launchpad.net/~rafaeldtinoco/ubuntu/+source/kmod/commit/?id=d08be3cad6af9e1d414af1aed7cdaa158f43773c [20:25] this is the fix [20:25] -proposed for bionic and eoan [20:26] but not working in focal [20:26] hum. ok] [20:26] let me fix it [20:26] e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/d/doit/20200323_182614_c1613@/log.gz [20:27] doko: alright, ill push a fix in a few [20:27] focal is still applying that patch, I missed that before the sru [20:28] so maybe also merge from debian [20:29] there was a fight about this fix and we decided to drop that change while they decided [20:29] lets see if they got that sorted out [20:32] ah great they dropped it [21:28] 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] so you would have to wait for the cloud images to get kmod updated [21:28] paride: ^ [21:29] paride: as you opened this bug.. just to make sure we get kmod updated in cloud images [21:29] orelse kernel updates might take end users crazy with those libkmod error messages [21:29] (if kernel is updated before kmod) [22:11] rbalint, hello kodi* syncs? [22:25] they would just drop the delta [22:25] LocutusOfBorg where it mattered i've already synced