dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
paulg has joined #yocto
ecdhe_ has joined #yocto
ecdhe has quit [Ping timeout: 272 seconds]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 265 seconds]
goliath has quit [Quit: SIGSEGV]
georgem has quit [Quit: Connection closed for inactivity]
vd has quit [Ping timeout: 246 seconds]
sakoman has quit [Quit: Leaving.]
ykrons has quit [Ping timeout: 265 seconds]
paulg has quit [Ping timeout: 252 seconds]
behanw has quit [Quit: Connection closed for inactivity]
Vonter has joined #yocto
dkl has quit [Quit: %quit%]
dkl has joined #yocto
amitk has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
RobertBerger has quit [Quit: Leaving]
rber|res has joined #yocto
ant__ has quit [Quit: Leaving]
florian has joined #yocto
xmn has quit [Quit: ZZZzzz…]
florian has quit [Ping timeout: 252 seconds]
zeddii has quit [Ping timeout: 265 seconds]
goliath has joined #yocto
bluelightning has joined #yocto
u1106 has joined #yocto
jwillikers has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
u1106 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
u1106 has joined #yocto
florian has joined #yocto
u1106 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
u1106 has joined #yocto
florian has quit [Ping timeout: 272 seconds]
u1106 has quit [Client Quit]
u1106 has joined #yocto
u1106 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
u1106 has joined #yocto
florian has joined #yocto
florian has quit [Ping timeout: 272 seconds]
u1106 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
u1106 has joined #yocto
florian has joined #yocto
Ad0 has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 272 seconds]
Ad0 has joined #yocto
georgem has joined #yocto
xmn has joined #yocto
florian has joined #yocto
Guest63 has joined #yocto
Xagen has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 240 seconds]
florian has joined #yocto
florian has quit [Ping timeout: 272 seconds]
sakoman has joined #yocto
mihai- has joined #yocto
mihai has quit [Ping timeout: 245 seconds]
jmiehe has joined #yocto
florian has joined #yocto
rber|res has quit [Read error: Connection reset by peer]
xmn has quit [Ping timeout: 272 seconds]
jmiehe has quit [Quit: jmiehe]
florian has quit [Ping timeout: 272 seconds]
mihai- is now known as mihai
paulg has joined #yocto
florian has joined #yocto
sakoman has quit [Quit: Leaving.]
UmbrellaMan has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
<RP> khem: any idea how we look with meta-oe and the overrides transition?
<UmbrellaMan> Hey all, in what context does it make sense to use the `VARIABLE_pn-recipename` versus the `VARIABLE_recipename`?
<UmbrellaMan> For example. I've seen `PREFERRED_VERSION_pn-<recipe_name>` as well as `PREFERRED_VERSION_<recipe_name>`
<RP> UmbrellaMan: PREFERRED_VERSION is special, it would be _pn- in most other cases
<UmbrellaMan> Thanks,
<UmbrellaMan> RP What about `RDEPENDS_${PN}`? It's also having the recipe name directly used as the override?
sakoman has joined #yocto
florian has quit [Ping timeout: 272 seconds]
ant__ has joined #yocto
<kergoth> UmbrellaMan in that case ${PN} is the same of a package listed in PACKAGES, the fact that it's a recipe name is incidental
<UmbrellaMan> kergoth (diverging from original question...) Why does it need the _${PN} in the first place? According to the Yocto Chant #1 recipe data is local, so why isn't `RDPENDS` enough?
<kergoth> UmbrellaMan because one recipe will create many packages.
<kergoth> we use granular packaging to ease constructing filesystems with just what we want. documentation, development files, etc is all split out into separate binary packages
<kergoth> RDEPENDS_${PN} only applies to the ${PN} package
<kergoth> see PACKAGES = in meta/conf/bitbake.conf
<UmbrellaMan> Thanks, seems those are totally different mechanisms. It's more clear now
<UmbrellaMan> I'm trying to understand the mechanism on hoe OVERRIDES is used. From what can see, the value of OVERRIDES will change for every recipe and it will contain at least the name of that recipe.
<kergoth> Only during do_package & friends will the package name be added to OVERRIDES, not generally
<UmbrellaMan> Yeah, just confirmed it doesn't contain the recipe name always for different recipes... I guess I'm missing the point then.
<UmbrellaMan> The example here shows the override mechanism from a purely bitbake perspective. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#conditional-metadata
<UmbrellaMan> I'm reading it as: "If the string in VARIABLE_<string> also exists in the OVERRIDES variable, the VARIABLE will take that value."
<UmbrellaMan> Now trying to translate that into open embedded concepts I though it was saying that the overridden variables for a local recipe scope get filtered out from the global scope by the fact that the recipe name is in the OVERRIDES
florian has joined #yocto
<kergoth> recipe name is not in overrides specifically, and never globally. only during packaging are the *package name* added to it, and only while processing that package while it iterates over the contents of the PACKAGES variable
florian has quit [Ping timeout: 240 seconds]
<UmbrellaMan> Thanks, I'm trying to merge what you are saying together with what's in the docs. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-OVERRIDES
<UmbrellaMan> And it does specify a "state" which implies that the current recipe is some kind of an override state.
<kergoth> pn-${PN} is always in overrides, but ${PN} is only in overrides during packaging.
<UmbrellaMan> A ok, that makes thing fit into place better. So the `pn-` is kind of like a hacky namespace to prevent recipe names conflicting with other override names?
<UmbrellaMan> kergoth Cool. Thanks for clarifying things :)
<UmbrellaMan> So, what I was hoping to achieve before realizing I don't understang the overrides mechanism was to add a the chosen recipe version to an image name.
<UmbrellaMan> Let me try to thing out loud and see where it get's me. Problem definition: There is a local variable in the image recipe called `IMAGE_LINK_NAME` and I want to expand it with a version of a particular recipe....
<UmbrellaMan> Let's say I want to have the version of `nano` in my image name because I want to build 20 different images all with different nano versions
<UmbrellaMan> So to not get lost, having the version in the build image would help me a lot
<UmbrellaMan> So how can the local namespace of the image recipe get the local PV of the `nano` recipe. Obviously, it can't.
<UmbrellaMan> But perhaps there is a global alternative. Maybe I can access the override value directly. Something like `IMAGE_LINK_NAME_append="${PV_pn-nano)"`
<UmbrellaMan> In my current mental model, there isn't a reason for that to work (at least in theory)
jwillikers has quit [Remote host closed the connection]
<UmbrellaMan> Nope, that doesn't seem to be the case. It isn't resolving `${PV_pn-nano)` to a number, but is treating it as a literal
<kergoth> correct, recipes cannot access the metadata of other recipes by design