| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 00:13 | |
| *** ecdhe_ <ecdhe_!~ecdhe@mms-rf-support.com> has joined #yocto | 00:37 | |
| *** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has quit IRC (Ping timeout: 272 seconds) | 00:40 | |
| *** Emantor <Emantor!~Emantor@magratgarlick.emantor.de> has quit IRC (Quit: ZNC - http://znc.in) | 01:20 | |
| *** Emantor <Emantor!~Emantor@magratgarlick.emantor.de> has joined #yocto | 01:21 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-128-196.home.otenet.gr> has joined #yocto | 01:32 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-128-196.home.otenet.gr> has quit IRC (Ping timeout: 265 seconds) | 01:34 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 02:49 | |
| *** georgem <georgem!uid210681@id-210681.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 03:19 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Ping timeout: 246 seconds) | 03:26 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 03:42 | |
| *** ykrons <ykrons!~guillaume@62.192.23.101> has quit IRC (Ping timeout: 265 seconds) | 03:51 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 252 seconds) | 04:04 | |
| *** behanw <behanw!uid110099@id-110099.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 05:34 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 05:36 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Quit: %quit%) | 05:40 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has joined #yocto | 05:41 | |
| *** amitk <amitk!~amit@103.208.71.30> has joined #yocto | 05:47 | |
| *** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer) | 06:40 | |
| *** sbach <sbach!~sbach@user/sbach> has joined #yocto | 06:40 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-128-196.home.otenet.gr> has quit IRC (Quit: Leaving) | 07:00 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-128-196.home.otenet.gr> has joined #yocto | 07:00 | |
| *** ant__ <ant__!~ant@host-87-0-18-72.retail.telecomitalia.it> has quit IRC (Quit: Leaving) | 07:43 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 07:51 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 07:56 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 08:01 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 265 seconds) | 08:03 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 11:02 | |
| *** bluelightning <bluelightning!~paul@2406:e003:1328:2101:b007:8272:e69d:ffd2> has joined #yocto | 11:05 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 11:26 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 11:44 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 12:02 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 12:04 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 12:09 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 12:09 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 12:12 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 12:22 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 12:22 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 12:26 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Client Quit) | 12:27 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 12:27 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 12:34 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 12:34 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 12:36 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 12:41 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 12:46 | |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 12:46 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 12:58 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 252 seconds) | 13:00 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 13:03 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 13:06 | |
| *** georgem <georgem!uid210681@id-210681.tinside.irccloud.com> has joined #yocto | 13:26 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:05 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 14:24 | |
| *** Guest63 <Guest63!~textual@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 14:37 | |
| *** Xagen <Xagen!~textual@2600:1700:211:7e60:b53b:9f36:5b2:29e2> has quit IRC (Ping timeout: 252 seconds) | 14:40 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 14:47 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 15:04 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 15:10 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 15:54 | |
| *** mihai- <mihai-!~mihai@user/mihai> has joined #yocto | 16:05 | |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Ping timeout: 245 seconds) | 16:08 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 16:18 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 16:31 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-128-196.home.otenet.gr> has quit IRC (Read error: Connection reset by peer) | 16:51 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 272 seconds) | 16:52 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 17:01 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 17:21 | |
| *** mihai- is now known as mihai | 19:09 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 19:30 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 20:19 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 21:08 | |
| *** UmbrellaMan <UmbrellaMan!~UmbrellaM@95.168.121.95> has joined #yocto | 21:19 | |
| *** amitk <amitk!~amit@103.208.71.30> has quit IRC (Ping timeout: 240 seconds) | 21:20 | |
| RP | khem: any idea how we look with meta-oe and the overrides transition? | 21:20 |
|---|---|---|
| UmbrellaMan | Hey all, in what context does it make sense to use the `VARIABLE_pn-recipename` versus the `VARIABLE_recipename`? | 21:30 |
| UmbrellaMan | For example. I've seen `PREFERRED_VERSION_pn-<recipe_name>` as well as `PREFERRED_VERSION_<recipe_name>` | 21:34 |
| RP | UmbrellaMan: PREFERRED_VERSION is special, it would be _pn- in most other cases | 21:35 |
| UmbrellaMan | Thanks, | 21:37 |
| UmbrellaMan | RP What about `RDEPENDS_${PN}`? It's also having the recipe name directly used as the override? | 21:38 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 21:56 | |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 21:57 | |
| *** ant__ <ant__!~ant@host-95-251-77-252.retail.telecomitalia.it> has joined #yocto | 22:06 | |
| 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 | 22:18 |
| 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? | 22:31 |
| kergoth | UmbrellaMan because one recipe will create many packages. | 22:34 |
| 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 | 22:34 |
| kergoth | RDEPENDS_${PN} only applies to the ${PN} package | 22:34 |
| kergoth | see PACKAGES = in meta/conf/bitbake.conf | 22:34 |
| UmbrellaMan | Thanks, seems those are totally different mechanisms. It's more clear now | 22:42 |
| 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. | 22:53 |
| kergoth | Only during do_package & friends will the package name be added to OVERRIDES, not generally | 22:56 |
| UmbrellaMan | Yeah, just confirmed it doesn't contain the recipe name always for different recipes... I guess I'm missing the point then. | 22:58 |
| 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 | 22:58 |
| UmbrellaMan | I'm reading it as: "If the string in VARIABLE_<string> also exists in the OVERRIDES variable, the VARIABLE will take that value." | 23:00 |
| 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 | 23:01 |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has joined #yocto | 23:05 | |
| 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 | 23:06 |
| kergoth | https://github.com/openembedded/openembedded-core/blob/master/meta/conf/bitbake.conf#L292 | 23:07 |
| *** florian <florian!~florian@dynamic-093-131-087-100.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 23:10 | |
| 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 | 23:12 |
| UmbrellaMan | And it does specify a "state" which implies that the current recipe is some kind of an override state. | 23:14 |
| kergoth | pn-${PN} is always in overrides, but ${PN} is only in overrides during packaging. | 23:14 |
| 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? | 23:17 |
| UmbrellaMan | kergoth Cool. Thanks for clarifying things :) | 23:21 |
| 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. | 23:22 |
| 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.... | 23:27 |
| 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 | 23:29 |
| UmbrellaMan | So to not get lost, having the version in the build image would help me a lot | 23:29 |
| UmbrellaMan | So how can the local namespace of the image recipe get the local PV of the `nano` recipe. Obviously, it can't. | 23:30 |
| 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)"` | 23:32 |
| UmbrellaMan | In my current mental model, there isn't a reason for that to work (at least in theory) | 23:33 |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 23:38 | |
| 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 | 23:41 |
| kergoth | correct, recipes cannot access the metadata of other recipes by design | 23:47 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!