06:13 <shoragan> RP, thanks. hey halstead and ndec :)

06:30 <ndec> hey shoragan , i think you need dl9pf, he created yocto and oe.

06:30 <shoragan> ndec, i pinged him yesterday. then RP told me to contact you :) khem "owns" the channel on the matrix side

06:31 <shoragan> i'm just trying to connect the required people

06:31 <ndec> yesterday was Sunday, let's see if dl9pf is around today :)

06:53 <mckoan> good morning

07:00 <mckoan> we should activate a BOT saying every hour "This channel moved to 'irc.libera.chat'"

07:00 <mckoan> sayng that on the old IRC of course

07:01 <ndec> mckoan: we are working on 'announcing' the transition over here.

07:03 <mckoan> ndec: ;-)

07:05 <mckoan> ndec: IMHO the problem is not simply announcing that. It's like when you change phone number, a lot of people still call you on the old number for a while

07:05 <ndec> I know, and we are looking at using bots to help during the migration.

07:05 <mckoan> ndec: great!

07:11 <mckoan> do we also have an IRC community name now ?

07:14 <mckoan> https://libera.chat/chanreg#the-projects--community-team

07:36 <mckoan> Today we have 171 nicks in Freenode, 65 nicks in Libera

07:36 <mckoan> ATM I'm joining both

09:28 <dl9pf> shoragan: yes, sri about the delay. yesterday afk

09:28 <dl9pf> ndec: I'm waiting for the ok from you. halstead is OP already so he can as well.

09:31 <ndec> shoragan: dl9pf: ok.. i am not completely familiar with matrix.. but the request is to bridge #yocto from here with the Yocto 'room' on matrix.org, is that correct? so that users would transparently be able to use IRC or Matrix. is that correct? e.g. it's not about to be able to connect from matrix using the 'irc server' , right?

09:34 <shoragan> yes, that's correct. a matrix user joining #yocto:matrix.org wouldn't need to know that the IRC channel is hosted on libera.chat (or even what IRC is)

09:35 <shoragan> the bridge simulates each user from the "other side"

09:37 <shoragan> dl9pf, we could also do this for #oe first, as in that case i've got op on the matrix side (for #yocto, khem's support would be needed)

09:39 <shoragan> ndec, for project channels, i like matrix as it already provides the benefits of an irc bouncer (always connected and multi client) but without the setup burden for each user

09:42 <ndec> shoragan: dl9pf : i would be happy for us to try this bridge.

09:42 <dl9pf> ok roger

09:43 <dl9pf> shoragan: we can do #oe as well ... doh Jan, saaach do was ...

09:44 <dl9pf> wenn isch uff'm schlauch steh

09:44 <shoragan> dl9pf, o/ Moin!

09:44 <shoragan> didn't want to pressure you

13:27 <kpo> Hello, I've got a question - I'm working on suppressing u-boot logs sent to LCD. Setting stdout and stderr to just serial works fine. Is there any place in yocto where I could add (modify) those variables to u-boots default environment?

13:43 <dev1990> kpo: did you try to remove vidconsole from stdout u-boot env?

13:45 <kpo> dev1990: yes, I removed it on booted-up system and it works fine, however I'd like to set it during build time

14:16 <manuel1985> Can several yocto builds use the same sstate-cache at the same time?

14:17 <mckoan> manuel1985: yes if the MACHINE is the same

14:20 <manuel1985> mckoan: Interesting, thank you. Wouldn't have expected MACHINE to play a role here.

14:20 <manuel1985> Also, would have expected write conflicts between the running builds.

14:38 <qschulz> to be clear, you can share the sstate-cache directory between all builds. You'll anyway use the sstate-cache for native recipes, and architecture-specific packages, for machine-specific ones (e.g. kernel) only if MACHINE is identical in both Yocto builds

17:02 <alex88> Is there a way to debug why a do_fetch is not progressing?

17:04 <alex88> nvm found it with pstree

17:34 <Saur> RP: Can you explain the idea behind changing newdeps.append(dep + "-native") to newdeps.append(dep.replace("-native", "") + "-native") in native.bbclass (commit fd6a007e)? The reason I ask is because we apparently have a recipe called "crate-native-tls", which builds the native-tls crate from crates.io. This now fails when we are trying to build with Hardknott because bitbake complains that it cannot find the crate-tls-native recipe...

17:35 <Saur> Since the line before that checks that dep does not end with "-native", what other "-native" are expected to be in dep that needs to be removed before adding "-native" at the end?

17:38 <Saur> Btw, there is similar code for provides later in the same function. However, there it uses nprovides.append(prov.replace(prov, prov + "-native")), which I also do not understand. How is prov.replace(prov, prov + "-native") not the same as just doing prov + "-native" ?

17:40 <RP> Saur: I suspect the idea was that if we didn't do that, the patch and intended changes didn't work

17:41 <RP> Saur: there are assumptions elsewhere in the system about native recipes ending with "-native" which is why I didn't feel too bad about doing it there as well

17:42 <RP> Saur: some of the other areas of the code are more subtle

17:43 <Saur> Sure, but why is it removing "-native" from anywhere in the recipe name? As we know the recipe name does not end with "-native", using dep + "-native" should do the right thing, shouldn't it?

17:45 <RP> Saur: Easy way to illustrate it is probably to disable that and try a dry run world build of OE-Core

17:46 <RP> Saur: I'd guess it is something like PN being replaced with XXX-native so PN-YYY becomes XXX-native-YYY and the code is correcting that

17:51 <Saur> RP: Ok, so then the correct thing would be something like dep.replace(pn + "-native", pn) + "-native") ?

17:53 <Saur> Except pn in that function ends with "-native". Hmm...

20:35 <Saur> RP: I have sent two patches now that should fix the problem.

21:49 <RP> Saur: You're ignoring the bit where I said that having native recipes not ending in -native will cause other subtle problems :(

21:50 <RP> I don't remember the examples off the top of my head but I'd strongly recommend against doing it

21:56 <RP> Saur: put another way, I think changing things like this will break things for other people/layers and I'm not sure whether we want to do that :/

21:56 <Saur> RP: Hmm, if you said that, I did not get it. However, AFAICT, there are no recipes in OE-Core nor in meta-openembedded that inherit native without also havinga recipe name that ends with "-native".

21:57 <Saur> RP: Well, I will argue that the current code is definitely wrong and needs to be fixed.

22:03 <RP> Saur: "grep endswith.*native * -R" shows 25 references in code where I think things could break if you don't name things -native

22:04 <RP> The reason we have no recipes in OE-Core that inherit native but don't end with -native is because we don't support it.

22:05 <RP> Saur: I agree that not all 25 references listed there are problematic but some definitely are

22:08 <Saur> RP: Sure, but they are not affected by my patch. Actually they just show that using dep.replace(pn, bpn) + "-native" as I do will work, because if there is a native recipe that has a name that does not end with "-native", it will fail all those 25 other places...

22:09 <RP> Saur: Using native in recipes not named ending with -native is not supported. It will not be supported and I don't want to take the patch, sorry.

22:10 <RP> Saur: I have enough other problems without chasing down subtle bugs like that

22:10 <Saur> RP: Yes, but with the patch applied there is one less bug to chase down.

22:11 <RP> Saur: From what I remember it is not possible to fix some of these cases which is why we don't support this

22:11 <Saur> As long as you only use endswith() there is no problem using foo-native-bar as a recipe name.

22:12 <Saur> It's when you start using replace("-native", foo) things go wrong, and AFAICT that was only done in native.bbclass.

22:14 <RP> Saur: what you never said above but I'm now guessing is that "crate-native-tls" is not a native recipe?

22:14 <RP> crate-native-tls-native would be the native recipe?

22:14 <Saur> RP: No, it is not. Sorry, if I failed to convey that information.

22:14 <Saur> Exactly.

22:15 <Saur> The upstream crate is apparently called "native-tls".

22:16 <RP> Saur: I have a sinking feeling that if I add your patch to my next test build I'm going to end up chasing some subtle horrible bug. The code was added before that util-linux split so I don't think that would be the only reason it is there :/

22:17 <Saur> No, it has nothing to do with util-linux. util-linux.inc is just doing something stupid when it messes around with modifying BPN (at least IMHO).

22:24 <RP> Saur: ok. I'll put it in for testing I guess :/

22:43 <Saur> RP: Btw, I just stumbled upon meta/lib/oe/distro_check.py. AFAICT, it has not been used since distrodata.bbclass was removed three years ago. Maybe something to clean up?

22:45 <RP> Saur: hmm, yes, that does look old/obsolete