00:33 <halstead> All Yocto Project hardware is staged in the new data center. Starting to rack it now. Network and power are tested and working after several major snags. Proceeding!

06:21 <halstead> All services except Yocto Autobuilder workers are restored.

08:54 <RP> thanks Michael, sounds like some challenges but good progress!

19:05 <Saur[m]> RP: I've sent a number of patches now to the lists with changes mostly related to the license changes.

19:06 <Saur[m]> RP, sgw: I have also pushed a branch (pkj/spdx-licenses) to poky-contrib. It has the all the changes I sent as mail, then it has Saul

19:07 <Saur[m]> ... Saul's two changes cherry-picked from master-next, and on top of that are four changes that you can consider as review comments (i.e., I do not expect them to be integrated as is, but rather squashed with Saul's changes).

19:58 <RP> Saur[m]: thanks, one of the patches appears to address an issue seen in testing but I am worried about the wildcard change :/

20:10 <Saur[m]> RP: What do you mean "about the wildcard change"?

20:13 <RP> Saur[m]: https://git.yoctoproject.org/poky-contrib/commit/?h=pkj/spdx-licenses&id=18c55d8a38d93c3028d58823e087de84d648a309

20:13 <RP> Saur[m]: I can see what the issue is but it seems odd to not be able to use SPDX licenses there

20:15 <sgw> Hey RP Saur[m], I just happened to see this, did you see my updated patches from Friday late afternoon?

20:24 <Saur[m]> RP: That change reverts parts of what was changed in Saul's changes to go back to what we currently use. We could change the code to not rely on the mapping code, but then the correct change is to use `INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0-only GPL-3.0-or-later LGPL-3.0-only LGPL-3.0-or-later"`

20:25 <Saur[m]> I have a couple of other changes that remove the mapping support. They also include the above change.

20:27 <Saur[m]> Also, one thing to note with the new `INCOMPATIBLE_LICENSE_EXCEPTIONS` variable is that it does not support license mapping. I have not addressed that in my changes as I think it is the way we want to go, but it will have to be mentioned on the documentation.

20:32 <Saur[m]> sgw: I was by work earlier today for a little while and I did see that you had sent newer patches. I did not study them in detail, but I did notice that you have tried to bring back the `Including foo as buildable despite it having an incompatible license` message. I am pretty sure that is not working as intended, and I believe it is actually hard to get that right unless we have two variables for the exceptions, one for recipes and one for

20:32 <Saur[m]> packages.

21:15 <Saur[m]> Another question: what do I need to do to be able to run the incompatible_lic.NoGPL3InImagesTests.test_core_image_full_cmdline_weston test? Whenever I try it, it fails due to qemu not being able to setup a tap device using sudo. I can run the image from the failed test using `runqemu` and then setup a tap device using sudo, but that apparently does not help the test to succeed.

21:27 <jaskij[m]> I got around to testing that CMake toolchain patch, and then it dawned on me: I have never, ever, worked with mail supplied patches. I know the theory - download the patch, `git apply` it (against master?), test that it actually works, but how to go on from there?

21:29 <Saur[m]> jaskij: How do you mean to go on from there? That's pretty much the process to receive and apply a patch via mail.

21:30 <jaskij[m]> Saur: and then just reply on Bugzilla with my findings?

21:30 <Saur[m]> Well, if the patch came via a mailing list, it is probably better to answer via the list as well.

21:31 <Saur[m]> You probably also want to use `git am` instead of `git apply` as that recreates the commits.

21:32 <jaskij[m]> It came to me via Bugzilla, but tbf I haven't been monitoring the mailing list. This is literally my first time contributing to OSS via mail.

21:34 <Saur[m]> Well, if the patch came from Bugzilla, then commenting on it in Bugzilla should be fine as well.

21:35 <jaskij[m]> now, last question: apply it against master?

21:36 <Saur[m]> Most likely, though it of course depends on what branch was used when the patch was generated. If the patch was generated, e.g., for Dunfell, then it should of course be applied to the dunfell branch instead.

22:04 <jaskij[m]> Now I'm frantically porting everything - I haven't touched Yocto since... November? and all my layers were still on Hardknott a few hours ago. And since I want to test this by deploying to actual hardware, welp... only thing I have is our custom board, so now I'm frantically porting our BSP to at least get stuff to build.

22:04 <RP> Saur[m]: fwiw I usually setup the tap device in advance and then qemu just uses it

22:12 <Saur[m]> RP: I thought that would happen if I ran `runqemu` manually, but it does not seem to help. :(

22:30 <RP> Saur[m]: Did you use the script to set it up?

22:30 <RP> Saur[m]: I think it touches some file somewhere so the system knows it can be used without pseudo

22:32 <Saur[m]> RP: I just ran `runqemu`. Haven't used any other script.

22:39 <Saur[m]> RP: I found `runqemu-gen-tapdevs`. I guess that was the script you were referring to. I have run it now so hopefully the next test run will work...

23:11 <Saur[m]> Yay, it worked. :)