| 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:43 |
|---|---|---|
| ubottu | Launchpad bug 1867908 in wpasupplicant (Ubuntu) "Patch for MAC randomization" [Undecided,New] | 02:43 |
| 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 | 02:49 |
| 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! | 07:39 |
| ubottu | Launchpad bug 1867908 in wpasupplicant (Ubuntu) "Patch for MAC randomization" [Undecided,New] https://launchpad.net/bugs/1867908 | 07:39 |
| seb128 | xnox, hey, you hacked on casper/plymouth before, do you maybe have debugging hint you can share on bug #1867909 ? | 09:25 |
| ubottu | bug 1867909 in plymouth (Ubuntu) "plymouth spinner can not show the messages after installation." [Medium,Confirmed] https://launchpad.net/bugs/1867909 | 09:25 |
| === Wryhder is now known as Lucas_Gray | ||
| === didrocks999 is now known as didrocks | ||
| rbasak | bryce: here's the MP: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/381116 | 16:38 |
| bryce | rbasak, thanks | 16:55 |
| === Enlik is now known as Guest42372 | ||
| === Guest42372 is now known as Enlik | ||
| doko | tjaalton: dogtag-pki is missing build-deps, trying to download stuff during the build | 18:36 |
| tjaalton | doko: yes, somehow it wasn't an issue on debian, but -1u1 fixes it | 18:44 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 18:59 |
| 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:00 |
| ahasenack | I can experiment without throwing this away | 19:01 |
| 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:06 |
| 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:07 |
| 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:10 |
| Laney | build-time tests are: is that thing I just built something which works properly? | 19:12 |
| 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:24 |
| 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:25 |
| ahasenack | I'll add some more verbosity and call it good, and submit an MP | 19:26 |
| sarnold | ahasenack: very nice, thanks! | 19:26 |
| 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 |
| ubottu | 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 |
| doko | sforshee: ^^^ | 20:10 |
| === vorlon` is now known as vorlon | ||
| doko | so why didn't that help? | 20:16 |
| rafaeldtinoco | doko: will check | 20:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| doko | so maybe also merge from debian | 20:28 |
| 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:29 |
| rafaeldtinoco | ah great they dropped it | 20:32 |
| 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:28 |
| 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) | 21:29 |
| LocutusOfBorg | rbalint, hello kodi* syncs? | 22:11 |
| rbalint | they would just drop the delta | 22:25 |
| rbalint | LocutusOfBorg where it mattered i've already synced | 22:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!