07:02 <amahnui> Hello everyone I'm amahnui, I'm an outreachy applicant and would like to work on this project. Also the link on the outreachy platform that is supposed to direct us here is rather taking me and other applicants to kiwiirc.

07:33 <Amahnui_> Hello everyone I would like to say the link on the outreachy portal is redirecting us to #kiwi

10:45 <rburton> ndec: ^^^

11:04 <ndec> Amahnui: where are you seeing that?

15:50 <Amahnui> ndec: I'm seeing at the "How do work with the Yocto Project community " on the outreachy platform

15:51 <Amahnui> the link to Yocto Project IRC and DRESDEN IRC link https://usercontent.irccloud-cdn.com/file/2M0HWePe/irccloudcapture5985801229209423957.jpg

17:34 <RP> Saur[m]: that patch looks good, thanks!

17:35 <Saur[m]> RP: Well, it seems to work at least...

17:36 <Saur[m]> Not so sure about the "looking good" part. ;)

17:53 <RP> Saur[m]: I have a slightly different approach I was experimenting with and I think together these could work well

17:54 <RP> Saur[m]: I don't think there is a perfect way to solve this

17:54 <RP> Saur[m]: I'm also very unhappy with bitbake's Ctrl+C handling to interrupt when parsing :/

17:55 <Saur[m]> I agree. Especially given the numerous warnings in the documentation related to terminating processes and the use of Locks/Queues/etc.

17:55 <RP> Saur[m]: those weren't there when we wrote this :)

18:01 <Saur[m]> RP: I have prepared patches for OE-Core to change all SRC_URI:s (but one) that use the Git protocol to switch to using HTTPS instead. While there is an entry in the default `MIRRORS` variable that will automatically do this, it means there will be warnings issued that it is happening. The reason for this was brought on by a perfect storm: 1) we no longer have a SOCKS proxy and thus we can no longer use the Git protocol after we were

18:01 <Saur[m]> cyber-attacked, 2) the current bandwidth problems with downloads.yoctoproject.org, causing me to have to wait two hours to download the 1.3 GB tar ball for binutils, and 3) having said tar ball being immediately discarded once downloaded, which I assume was due to the unpacked Git repository being configured to use the Git protocol and thus not being usable due to 1). Assuming these changes are accepted, which I of course hope they will be, do you

18:01 <Saur[m]> want them as one patch per recipe or can I make one patch for all 48 affected recipes?

18:02 <RP> Saur[m]: we've been around in circles on this issue before, I did refuse to accept this change at least once in the past :/

18:02 <RP> Saur[m]: could we fix that mirror handling bug so the downloaded sources have the correct url configured?

18:02 <Saur[m]> Hmm, ok. What was the rationale for refusing it?

18:03 <RP> Saur[m]: mainly that the project doesn't have a policy of requiring https only urls and merging such a patch would start to suggest we did have :/

18:04 <RP> Going back in time I did used to think the git protocol was potentially more efficient too

18:04 <Saur[m]> Well, I didn't change the URLs in the tests. ;)

18:04 <RP> in some ways it still is

18:05 <Saur[m]> I did some measurements on downloading linux-yocto and the linux kernel from kernel.org, and I got approximately the same speeds for both protocols.

18:06 <RP> Saur[m]: right, but what about small incremental updates to existing trees for example

18:06 <RP> It isn't just about raw speed :/

18:07 <Saur[m]> It's hard to tell though when using live data as the bandwidth seems more affected by the state of the link at the current minute (i.e., both sites fluctuated quite a lot).

18:07 <RP> Saur[m]: I'd like to understand why the tarballs were discarded, that sounds rather bad and is in my view the more important thing to fix

18:09 <Saur[m]> Yeah, I haven't looked into that yet. The two hour download time was a bit detrimental to any testing. ;)

18:09 <RP> Saur[m]: I'd imagine it could reproduce with one of the smaller repos?

18:09 <Saur[m]> Most likely. I'll see what I can come up with.

18:12 <Saur[m]> On the positive side, there are https support for all Git repositories used in OE-Core, but one (mtd-utils). So that is the only one where we will have to rely on the download cache.

18:16 <RP> Saur[m]: that is good

18:46 <RP> Saur[m]: do you think your patch could be simplified to use signal.pthread_sigmask() ?

18:48 <RP> Saur[m]: I was going to add in SIGINT handling but this may be simpler

18:54 <RP> Saur[m]: I've added a patch to -next I'll experiment with

19:11 <Saur[m]> RP: Using `signal.pthread_sigmask()` seems much better than my solution. Feel free to drop my commit from the stack as it doesn't really add anything after your change.

19:57 <RP> Saur[m]: I only found it by reading the signal docs. I appreciate your patch though as it gave me some ideas I hadn't thought about

21:01 <smurray> khem: I'm seeing packaging QA errors from duktape with meta-oe master

21:02 <smurray> khem: mentioned of /usr/usr/lib/, which makes me suspect a usrmerge related issue, as I've been testing with it

21:02 <smurray> err, mentions of

22:13 <RP> Saur[m]: pthread_sigmask doesn't seem to work :/

22:18 <Saur[m]> RP: Odd, it definitely looked like it should do exactly what I tried to achieve (but in a correct way)...

22:18 <RP> Saur[m]: I think in order to block the signal, you may need a handler

22:23 <Saur[m]> RP: Hold on. The second argument to `pthread_sigmask()` is supposed to be a set.

22:24 <RP> Saur[m]: I think it should take an iterable?

22:25 <Saur[m]> Well, the documentation says set, so no idea what will happen when you give it a list...

22:25 <RP> Saur[m]: I did look at code examples and tried a few different things, it behaves the same :/

22:25 <Saur[m]> :(

22:32 <RP> I'll have to rework that patchset

22:33 <RP> I did wonder if SIGINT would be enough and to drop the .terminate()

22:34 <RP> tomorrow... :)

22:34 <Saur[m]> Well, there won't be much force to it if you drop the .terminate() call...

22:41 <RP> Saur[m]: my series adds SIGINT support which could be used instead

22:41 <RP> I think we need to have SIGTERM being reliable though as the user could send it

22:42 <Saur[m]> Won't sending SIGINT affect the process just as much as sending SIGTERM to it?