sfo has quit [Read error: Connection reset by peer]
sfo has joined #yocto
PhoenixMage has joined #yocto
florian has joined #yocto
frieder has joined #yocto
florian has quit [Ping timeout: 252 seconds]
ehussain has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
fabatera_ has joined #yocto
Jones42 has joined #yocto
lowfi has quit [Ping timeout: 252 seconds]
mbulut has joined #yocto
mbulut has quit [Remote host closed the connection]
mbulut has joined #yocto
mbulut has quit [Ping timeout: 245 seconds]
mbulut has joined #yocto
prabhakalad has quit [Ping timeout: 248 seconds]
olani has quit [Remote host closed the connection]
olani has joined #yocto
prabhakalad has joined #yocto
<aduskett>
I have a .bbappend file that changes the URI and SRCREV of a .bb file, but yocto-check-layer gets quite upset about this. What is the appropriate way to overwrite a src_url and srvrev so yocto-check-layer passes the signature check?
ehussain has quit [Ping timeout: 252 seconds]
Piraty has quit [Quit: -]
Piraty has joined #yocto
ehussain has joined #yocto
ehussain has quit [Remote host closed the connection]
lowfi has joined #yocto
<mcfrisk>
aduskett: make the modifications conditional to layer specific packageconfig, distro, machine or similar feature?
<mcfrisk>
thus when adding the layer, by default it does not change anything in upstream recipes
<fabatera_>
:) yes, if the objective is to apply for compatibility.
albeu has quit [Changing host]
albeu has joined #yocto
sakoman has joined #yocto
jmiehe has quit [Quit: jmiehe]
alejandrohs has quit [Ping timeout: 252 seconds]
alejandrohs has joined #yocto
dmoseley has joined #yocto
dmoseley_ has quit [Ping timeout: 252 seconds]
fabatera_ has quit [Ping timeout: 246 seconds]
rm5248 has joined #yocto
<Saur>
kanavin: That totally depends on your use case. We use versioned bbappends to do updates of upstream recipes. That way we get automatic tracking of when upstream catches up (since the bbappend no longer applies) and can then remove the bbappend. If we instead had used separate recipes, someone (i.e., me) would have had to manually keep track of all recipe updates. And if there is one thing I have learned from the cases where we have had t
<Saur>
o use a separate recipe due to the changes being too extensive, is that while initially intended to update to a newer version than what is in upstream, the risk of eventually ending up with using what is then an older version due to missing that upstream has updated to an even newer version is huge.
<kanavin>
Saur, why don't you send the update directly upstream?
<kanavin>
why put it into a bbappend first?
<Saur>
kanavin: Typically master of OE has already updated to the new version, but we are currently using Scarthgap. So we use the versioned bbappend to, e.g., update curl to the same version that is in Styhead. And when we update to Styhead in a couple of weeks, we remove the bbappend.
rfuentess has quit [Remote host closed the connection]
<kanavin>
But why would you miss an even newer version, if bitbake picks up the biggest (newest) version by default?
<Saur>
kanavin: It doesn't. Since our layer has higher priority, it uses the recipe in our layer regardless of the version in OE Core.
<kanavin>
The reason I don't like the .bbappends is that when you put stuff in it, you then rely on the original recipe not changing behind your back in ways that break what .bbappend is doing. I guess for small-ish version updates it can work, but otherwise I'd still not do it.
<kanavin>
e.g. when it's used to change SRC_URI
<Saur>
kanavin: Well, there are definitely pros and cons to it, but at least for us it is a very useful technique.
<kanavin>
oh, and everyone should track master, instead of moving from one release to another :)
<Saur>
The problem with the SRC_URI is typically that one has to change the branch= parameter to match SRCREV, and since there is no corresponding SRCBRANCH variable, one has to change the SRC_URI.
<kanavin>
Saur, I mean change it to a fork on a different server
sakman has quit [Remote host closed the connection]
<kanavin>
this is where I would draw the line, and ask to make a standalone recipe
sakman has joined #yocto
dkc has quit [Remote host closed the connection]
dkc has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
fabatera_ has joined #yocto
rm5248 has left #yocto [#yocto]
florian_kc is now known as florian
<rburton>
kanavin: that patch just merged into python so its a backport now
rob_w has quit [Read error: Connection reset by peer]
dmoseley has quit [Ping timeout: 252 seconds]
dmoseley has joined #yocto
debbie has joined #yocto
debbie is now known as debbiemartin
Xagen has joined #yocto
<frieder>
Hi, is there a way to make bitbake treat compiler warnings as errors?
rty has joined #yocto
<rty>
hi, is there a more detailed document/reference on sstate-cache internals? for example, is there separate cache for recipes with different PVs?
<rty>
e.g. foo_1.0 and foo_1.1 and foo_git
<mcfrisk>
frieder: bitbake no but build scripts inside recipes can amend -Werror to CFLAGS etc. Recipes can also do that. Adding this distro wide is a bad idea since compiler versions get updated frequently and new warnings are triggered
<frieder>
mcfrisk: Ok, thanks. I see. Still, it would be nice to do this globally for a single run of bitbake, so that we can check if some recipe build throws warnings that need to be addressed. Just as a kind of extra QA check.
<mcfrisk>
frieder: you can quite easily do this in poky/meta/conf/bitbake.conf for your build, but note that recipe and their build scripts can still change the flags. every recipe needs to be reviewed that they also used the flags as intended and did not disable the warnings.
<frieder>
mcfrisk: Ok, understood. Thanks!
<kanavin>
frieder, if you do this, pretty much every recipe will fail
<kanavin>
the majority of them throw warnings that no one bothers to address
<frieder>
kanavin: Ok, thanks for the warning ;)
<kanavin>
I've learned that drowning people in warnings is a bad idea, as they'll just learn to ignore them
<kanavin>
a better way is to introduce a managed, small amount of warnings
<kanavin>
then when those are addressed, again introduce more warnings
<kanavin>
etc
<frieder>
kanavin: yeah, I get your point. I need to rethink this.
<rburton>
frieder: if its code you own that you definitely don't want to have warnings then sure, add -Werror=... to the recipe CFLAGS
<rburton>
just don't expect the rest of the system to build cleanly :)
<frieder>
rburton: Yeah, that's basically the context. I just didn't frame it that way in my initial question.
<kanavin>
frieder, just in case, adding -Werror to the component makefile itself is not a good idea, and we patch this out when upstream does it.
<kanavin>
for the same reason: this causes breakage with compilers that upstream isn't testing with (which is almost always the case in yocto)
<mcfrisk>
I've found only one way to increase quality, and that's to make qa tool results comparable. stopping new warnings from popping is more important than fixing all the tons of warnings in old codebases. I think there was a recent study on this
<mcfrisk>
comparing compile logs isn't easy. other tools may be better.
<rburton>
gcc can emit the warnings and errors as a machine readable format
<frieder>
kanavin: ok, got it
<rburton>
i've been meaning to hack up a tool to extract them from a build
<mcfrisk>
readable != comparable, comparing previous release build results with latest development build results is really important, IMO