*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 00:14 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 00:14 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 00:14 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 248 seconds) | 00:18 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 00:19 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 00:28 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 00:29 | |
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Quit: qschulz) | 00:32 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 252 seconds) | 00:33 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 00:34 | |
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:35 | |
*** otavio <otavio!~otavio@191-221-69-78.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 248 seconds) | 00:55 | |
*** otavio <otavio!~otavio@191-221-69-78.user3p.brasiltelecom.net.br> has joined #yocto | 00:55 | |
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 00:57 | |
*** davidinux <davidinux!~davidinux@host-79-21-24-32.retail.telecomitalia.it> has quit IRC (Ping timeout: 250 seconds) | 01:03 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 258 seconds) | 01:03 | |
*** davidinux <davidinux!~davidinux@62.211.10.144> has joined #yocto | 01:06 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 01:12 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 01:17 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 01:17 | |
*** starblue <starblue!~juergen@dslb-094-221-186-229.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 248 seconds) | 01:21 | |
*** starblue <starblue!~juergen@188.100.139.193> has joined #yocto | 01:23 | |
*** RobertBerger <RobertBerger!~rber|res@91-114-219-213.adsl.highway.telekom.at> has joined #yocto | 01:32 | |
*** rber|res <rber|res!~rber|res@91-114-219-213.adsl.highway.telekom.at> has quit IRC (Ping timeout: 252 seconds) | 01:34 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 02:24 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 02:24 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 252 seconds) | 02:28 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 02:29 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 02:33 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6537:5500:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 250 seconds) | 02:36 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6516:f500:2ce:39ff:fecf:efcd> has joined #yocto | 02:38 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 03:23 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 03:24 | |
*** camus1 is now known as camus | 03:24 | |
*** starblue <starblue!~juergen@188.100.139.193> has quit IRC (*.net *.split) | 03:48 | |
*** Haxxa <Haxxa!~Haxxa@89nnjg0xckz9ggn6r5xm.ip6.superloop.com> has quit IRC (*.net *.split) | 03:48 | |
*** fitzsim <fitzsim!~user@mail.fitzsim.org> has quit IRC (*.net *.split) | 03:48 | |
*** skoink[m] <skoink[m]!~skoinkmat@2001:470:69fc:105::2:8a4c> has quit IRC (*.net *.split) | 03:48 | |
*** MichaelNazzareno <MichaelNazzareno!~panicking@2001:470:69fc:105::2:886d> has quit IRC (*.net *.split) | 03:48 | |
*** jaskij[m] <jaskij[m]!~jaskijmat@2001:470:69fc:105::fa76> has quit IRC (*.net *.split) | 03:48 | |
*** kmaincent[m] <kmaincent[m]!~kmaincent@2001:470:69fc:105::2:825d> has quit IRC (*.net *.split) | 03:48 | |
*** hpsy[m] <hpsy[m]!~hpsymatri@2001:470:69fc:105::f822> has quit IRC (*.net *.split) | 03:48 | |
*** khem <khem!~khem@2001:470:69fc:105::b81> has quit IRC (*.net *.split) | 03:48 | |
*** T_UNIX[m] <T_UNIX[m]!~tunixmatr@2001:470:69fc:105::9ea> has quit IRC (*.net *.split) | 03:48 | |
*** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has quit IRC (*.net *.split) | 03:48 | |
*** Ebeneezer_Smooge <Ebeneezer_Smooge!~Smooge@centos/qa/smooge> has quit IRC (*.net *.split) | 03:48 | |
*** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has quit IRC (*.net *.split) | 03:48 | |
*** barometz <barometz!~dvanb@92-109-61-249.cable.dynamic.v4.ziggo.nl> has quit IRC (*.net *.split) | 03:48 | |
*** u1106 <u1106!~quassel@ec2-18-193-68-189.eu-central-1.compute.amazonaws.com> has quit IRC (*.net *.split) | 03:48 | |
*** zkrx <zkrx!~slimshady@adsl-89-217-230-95.adslplus.ch> has quit IRC (*.net *.split) | 03:48 | |
*** fleg <fleg!~fleg@user/fleg> has quit IRC (*.net *.split) | 03:48 | |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (*.net *.split) | 03:48 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (*.net *.split) | 03:48 | |
*** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 03:48 | |
*** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has joined #yocto | 03:48 | |
*** starblue <starblue!~juergen@dslb-188-100-139-193.188.100.pools.vodafone-ip.de> has joined #yocto | 03:48 | |
*** fleg <fleg!~fleg@user/fleg> has joined #yocto | 03:49 | |
*** T_UNIX[m] <T_UNIX[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 03:49 | |
*** barometz <barometz!~dvanb@92-109-61-249.cable.dynamic.v4.ziggo.nl> has joined #yocto | 03:49 | |
*** SSmoogen <SSmoogen!~Smooge@centos/qa/smooge> has joined #yocto | 03:49 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 03:49 | |
*** hpsy[m] <hpsy[m]!~hpsymatri@2001:470:69fc:105::f822> has joined #yocto | 03:50 | |
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 03:50 | |
*** Haxxa <Haxxa!~Haxxa@202-65-79-43.ip4.superloop.com> has joined #yocto | 03:50 | |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto | 03:50 | |
*** zkrx <zkrx!~slimshady@adsl-89-217-230-95.adslplus.ch> has joined #yocto | 03:53 | |
*** khem <khem!~khem@2001:470:69fc:105::b81> has joined #yocto | 03:54 | |
*** kmaincent[m] <kmaincent[m]!~kmaincent@2001:470:69fc:105::2:825d> has joined #yocto | 03:55 | |
*** MichaelNazzareno <MichaelNazzareno!~panicking@2001:470:69fc:105::2:886d> has joined #yocto | 03:55 | |
*** skoink[m] <skoink[m]!~skoinkmat@2001:470:69fc:105::2:8a4c> has joined #yocto | 03:55 | |
*** jaskij[m] <jaskij[m]!~jaskijmat@2001:470:69fc:105::fa76> has joined #yocto | 03:55 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 04:19 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 04:19 | |
*** schtobia <schtobia!~quassel@schmidl.dev> has quit IRC (Quit: Bye!) | 04:42 | |
*** schtobia <schtobia!~quassel@88.99.170.71> has joined #yocto | 04:43 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 04:58 | |
*** nemik <nemik!~nemik@162.245.20.117> has joined #yocto | 04:59 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 04:59 | |
*** nemik <nemik!~nemik@162.245.20.117> has quit IRC (Ping timeout: 268 seconds) | 05:04 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 05:04 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 260 seconds) | 05:40 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 05:47 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 05:48 | |
*** vladest <vladest!~Thunderbi@109.202.94.214> has quit IRC (Quit: vladest) | 06:10 | |
*** vladest <vladest!~Thunderbi@109.202.94.214> has joined #yocto | 06:12 | |
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 06:18 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 06:19 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 06:19 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 06:27 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.dsl.dyn.abo.bbox.fr> has joined #yocto | 06:28 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.dsl.dyn.abo.bbox.fr> has quit IRC (Ping timeout: 246 seconds) | 06:32 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 06:36 | |
*** frieder <frieder!~frieder@200116b824ac6d810000000000001cba.dip.versatel-1u1.de> has joined #yocto | 06:44 | |
*** frieder <frieder!~frieder@200116b824ac6d810000000000001cba.dip.versatel-1u1.de> has quit IRC (Remote host closed the connection) | 06:46 | |
*** frieder <frieder!~frieder@200116b824ac6d810000000000001cba.dip.versatel-1u1.de> has joined #yocto | 06:47 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Ping timeout: 264 seconds) | 06:50 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 06:54 | |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 07:01 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:02 | |
*** vladest <vladest!~Thunderbi@109.202.94.214> has quit IRC (Quit: vladest) | 07:05 | |
*** vladest <vladest!~Thunderbi@109.202.94.214> has joined #yocto | 07:07 | |
*** mckoan|away is now known as mckoan | 07:08 | |
mckoan | good morning | 07:08 |
---|---|---|
*** frieder <frieder!~frieder@200116b824ac6d810000000000001cba.dip.versatel-1u1.de> has quit IRC (Read error: Connection timed out) | 07:10 | |
*** zpfvo <zpfvo!~fvo@89.245.206.182> has joined #yocto | 07:10 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 07:11 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 07:11 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 07:26 | |
*** frieder <frieder!~frieder@200116b824ac6d810000000000001cba.dip.versatel-1u1.de> has joined #yocto | 07:27 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 07:27 | |
*** zpfvo <zpfvo!~fvo@89.245.206.182> has quit IRC (Ping timeout: 268 seconds) | 07:30 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 07:35 | |
Schlumpf | good morning | 07:40 |
*** zpfvo <zpfvo!~fvo@89.245.206.182> has joined #yocto | 07:44 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 07:46 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:46 | |
rfuentess | morning | 07:47 |
*** manuel_ <manuel_!~manuel198@185.144.162.58> has joined #yocto | 07:48 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 246 seconds) | 07:53 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:53 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 07:53 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:53 | |
*** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 08:00 | |
qschulz | o/ | 08:03 |
*** hcg <hcg!~hcg@178.197.224.127> has joined #yocto | 08:04 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 260 seconds) | 08:29 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 08:29 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:31 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 08:32 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.dsl.dyn.abo.bbox.fr> has joined #yocto | 08:32 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.dsl.dyn.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 08:33 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 264 seconds) | 08:34 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 08:34 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 08:35 | |
*** RobertBerger <RobertBerger!~rber|res@91-114-219-213.adsl.highway.telekom.at> has quit IRC (Ping timeout: 252 seconds) | 08:36 | |
*** zhmylove <zhmylove!~zhmylove@80.254.50.127> has joined #yocto | 08:36 | |
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has joined #yocto | 08:37 | |
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Ping timeout: 244 seconds) | 08:41 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 08:43 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 08:44 | |
*** zpfvo <zpfvo!~fvo@89.245.206.182> has quit IRC (Ping timeout: 268 seconds) | 08:45 | |
qschulz | tlwoerner: o/ We just released a new Rockchip-based module and I'd like some initial support in meta-rockchip layer. I just send a patch for the SoC support for the master branch and was wondering if there's any chance we can have it in kirkstone branch? | 08:46 |
*** zpfvo <zpfvo!~fvo@89.245.206.182> has joined #yocto | 08:47 | |
qschulz | I don't plan to send support for the board to meta-rockchip until we have decent support upstream, to avoid meta-rockchip becoming a vendored BSP layer | 08:47 |
qschulz | I'm still catching up with our older module that I still want to have in meta-rockchip, we finally should have a fixed U-Boot for 2023.01 version, so I guess it's for after Langdale :) | 08:48 |
qschulz | tlwoerner: if we cannot get the SoC support in meta-rockchip kirkstone branch, we'll just carry it locally until next releases, just to know if I should wait a bit before releasing our venmdor BSP layer :) | 08:49 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 08:54 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 08:54 | |
kayterina[m] | Is there something special when SRC_URI:append:machineA in a native recipe? Because it is read once? | 08:56 |
qschulz | kayterina[m]: using a machine override in a native recipe shows there is some logic issue | 08:58 |
qschulz | a native recipe runs on your host, it does not (and should not) have knowledge of the target your're building for | 08:59 |
kayterina[m] | hm.it is logical. | 08:59 |
qschulz | since native recipes are re-used for all builds with the same distro, whatever the image or machine you build for, it is essential there's nothing machine specific in it | 08:59 |
qschulz | kayterina[m]: so, the question is.. what are you tryuing to do so we can maybe advise on a solution :) | 09:00 |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 09:01 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 09:02 | |
kayterina[m] | Correct. So, it is a tool that builds and runs on different machines and there is also a native version to run on pc because target machine has limited powers. I see the patches change some make options dependant on the machine. | 09:07 |
kayterina[m] | so perhaps it is an override on a do_configure? | 09:07 |
qschulz | kayterina[m]: is it required at build time or can it be a runtime option, parameter, flag, variable passed to the native version? | 09:08 |
kayterina[m] | it is required at build time, it removes a lib from the .mk | 09:11 |
kayterina[m] | some flags and a library | 09:11 |
qschulz | kayterina[m]: I would go with a different recipe per machine you want to support | 09:12 |
qschulz | at least a different BPN/PN | 09:12 |
qschulz | and you'll need to explicit on which "version" of the native recipe a given target recipe depends on | 09:12 |
qschulz | the proper way would maybe be to take inspiration from what was done for gcc, since it is a native recipe but need to know about the target (because it cross compiles) | 09:13 |
qschulz | but ideally, modifying the native recipe to have one binary that can be configured via environment variables or parameters would be best | 09:14 |
kayterina[m] | there is also a hack. The native and target recipe share a patch. A variable is added in an .inc and it gets appended SRC_URI:append I can append that recipe per machine. | 09:16 |
qschulz | kayterina[m]: that's not going to change the fact that your native recipe does not know about your machine | 09:16 |
kayterina[m] | Wait, $machine has a value inside the recipe. | 09:17 |
kayterina[m] | it should not know, but it knows. | 09:17 |
qschulz | kayterina[m]: check the value of OVERRIDES | 09:17 |
qschulz | I don't think you have this info there | 09:17 |
kayterina[m] | I checked with an "echo $MACHINE" inside do_configure. What am I looking at OVERRIDES? | 09:21 |
kayterina[m] | # pre-expansion value: | 09:21 |
kayterina[m] | # "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable" | 09:21 |
kayterina[m] | * I checked with an "echo $MACHINE" inside do\_configure. What am I looking at OVERRIDES? | 09:21 |
kayterina[m] | # pre-expansion value: | 09:21 |
kayterina[m] | ${TARGET\_OS}:${TRANSLATED\_TARGET\_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable | 09:21 |
kayterina[m] | * I checked with an "echo $MACHINE" inside do\_configure. What am I looking at OVERRIDES? | 09:21 |
kayterina[m] | pre-expansion value: | 09:21 |
kayterina[m] | ${TARGET\_OS}:${TRANSLATED\_TARGET\_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable | 09:21 |
qschulz | kayterina[m]: OVERRIDES is the mechanism that allows you to do SRC_URI:append:machineA | 09:24 |
qschulz | if machineA is not in OVERRIDES, it won't work | 09:24 |
qschulz | and I highly suspect target machines aren't part of OVERRIDES for native recipes | 09:24 |
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds) | 09:26 | |
rburton | correct, native recipes have no idea what the target is | 09:28 |
qschulz | kayterina[m]: but if MACHINE is set, you could do something like SRC_URI:append = "${@ 'file://additional.patch" if d.getVar('MACHINE') else ''}" but I'm sure this is a bad idea | 09:28 |
rburton | its a terrible idea | 09:28 |
kayterina[m] | OVERRIDES="linux:x86-64:pn-<recipe>-native::<distro>:class-native:forcevariable" | 09:28 |
kayterina[m] | so ${MACHINEOVERRIDES} is empty. | 09:28 |
kayterina[m] | I will check gcc recipe then , thanks. | 09:28 |
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has joined #yocto | 09:29 | |
kayterina[m] | I will try to keep good ideas on the project. | 09:29 |
rburton | if you *really* need the host binary to be modified per-target then look at the cross class, instead of native | 09:31 |
*** zhmylove <zhmylove!~zhmylove@80.254.50.127> has quit IRC (Ping timeout: 246 seconds) | 09:37 | |
*** zpfvo <zpfvo!~fvo@89.245.206.182> has quit IRC (Ping timeout: 268 seconds) | 09:59 | |
*** zpfvo <zpfvo!~fvo@i59F5CEB6.versanet.de> has joined #yocto | 10:02 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:03 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 10:09 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:09 | |
*** Bardon_ <Bardon_!~Bardon@user/Bardon> has joined #yocto | 10:10 | |
*** Bardon <Bardon!~Bardon@user/Bardon> has quit IRC (Ping timeout: 268 seconds) | 10:12 | |
*** starblue <starblue!~juergen@dslb-188-100-139-193.188.100.pools.vodafone-ip.de> has quit IRC (Ping timeout: 248 seconds) | 10:16 | |
*** starblue <starblue!~juergen@dslb-188-100-139-193.188.100.pools.vodafone-ip.de> has joined #yocto | 10:18 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 258 seconds) | 10:29 | |
*** mckoan is now known as mckoan|away | 10:34 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 10:41 | |
*** zhmylove <zhmylove!~zhmylove@80.254.50.127> has joined #yocto | 10:43 | |
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds) | 10:44 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 10:48 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@user/mrpelotazo> has quit IRC (Read error: Connection reset by peer) | 10:50 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@user/mrpelotazo> has joined #yocto | 11:08 | |
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has joined #yocto | 11:11 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 11:13 | |
*** hcg <hcg!~hcg@178.197.224.127> has quit IRC (Ping timeout: 244 seconds) | 11:14 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 11:14 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 11:14 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 11:15 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 11:15 | |
*** alejandrohs <alejandrohs!~alejandro@189.237.55.61> has quit IRC (Ping timeout: 264 seconds) | 11:17 | |
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto | 11:19 | |
*** mvlad <mvlad!~mvlad@2a02:2f08:4605:ca00:24d7:51ff:fed6:906d> has joined #yocto | 11:23 | |
tlwoerner | qschulz: absolutely YES! :-D :-D | 11:42 |
tlwoerner | and i'm not opposed to meta-rockchip carrying a couple patches for some SoC that doesn't quite have 100% upstream support | 11:44 |
tlwoerner | does YP have some sort of vision/roadmap document that lays out its linux-yocto strategy? specifically wrt upstream versions? | 11:46 |
tlwoerner | zeddii: ^ | 11:46 |
*** fitzsim <fitzsim!~user@mail.fitzsim.org> has joined #yocto | 11:48 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 11:49 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 11:50 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 11:54 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.dsl.dyn.abo.bbox.fr> has joined #yocto | 11:55 | |
*** hcg <hcg!~hcg@178.197.233.207> has joined #yocto | 11:55 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 11:56 | |
*** vladest <vladest!~Thunderbi@109.202.94.214> has quit IRC (Ping timeout: 264 seconds) | 12:13 | |
rburton | tlwoerner: latest LTS version, as close to mainline as possible | 12:14 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 12:15 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:15 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 12:18 | |
*** Guest13 <Guest13!~Guest13@46.221.0.162> has joined #yocto | 12:25 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 12:25 | |
Guest13 | hi | 12:25 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:25 | |
Guest13 | hi, i am getting error while trying to build initramfs : pastebin.com/BwDR2kJk | 12:27 |
zeddii | tlwoerner: I did an entire yocto summit on that, and what rburton said! | 12:27 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 12:35 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:36 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 12:36 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:36 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 12:36 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:36 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 12:41 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:42 | |
*** hcg <hcg!~hcg@178.197.233.207> has quit IRC (Ping timeout: 244 seconds) | 12:44 | |
*** SSmoogen is now known as Ebeneezer_Smooge | 12:51 | |
tlwoerner | zeddii: yes, but i was hoping to point someone to something "concrete". rburton's wording will do nicely, thanks! | 12:57 |
zeddii | it's on the wiki somewhere. I remember writing it. | 13:02 |
tlwoerner | zeddii: okay i'll look for it, and i'll review the yps video. btw i wasn't trying to imply the yps video isn't concrete :-) | 13:03 |
LetoThe2nd | zeddii: that means nothing, if your brain is even only remotely similar to mine. | 13:04 |
tlwoerner | https://wiki.yoctoproject.org/wiki/Linux_Yocto | 13:04 |
zeddii | LetoThe2nd. precisely. I always say that wiki pages are where information goes to be lost. | 13:05 |
LetoThe2nd | zeddii: +1 | 13:05 |
zeddii | tlwoerner. impressive! :) | 13:05 |
tlwoerner | zeddii: i'll take a poke at updating it post 3.1 | 13:06 |
zeddii | you'd have my thanks!! | 13:06 |
tlwoerner | maybe it should also make some mention of the kernel mixin? | 13:07 |
tlwoerner | (for 3.1) | 13:07 |
rburton | what mixin? | 13:07 |
rburton | it looks like paul's meta-kernel-mainline is dead | 13:07 |
tlwoerner | :-( | 13:08 |
* tlwoerner hopes paul is fairing better | 13:09 | |
*** pasherring <pasherring!~paulo@2804:14c:598a:86b6:649f:e36c:4315:5376> has joined #yocto | 13:12 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 13:12 | |
Guest13 | trying to get a build using "meta-raspberrypi" kirkstone, but im getting the error "The postinstall intercept hook 'update_mime_database' failed". what could it be caused by? | 13:12 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 13:12 | |
LetoThe2nd | Guest13: guess thats some package you're pulling in. what are you installing? does it happen for core-image-minimal also? | 13:16 |
Guest13 | yes, it happens when getting "core-image-minimal" build as well. | 13:17 |
*** vladest <vladest!~Thunderbi@214.94.cust.tetanet.cz> has joined #yocto | 13:18 | |
LetoThe2nd | Guest13: which layers are involved? what are they pulling into IMAGE_INSTALL, or some form of RDEPENDS? which specific machine are you building for? | 13:19 |
*** landgraf <landgraf!~landgraf@164.90.195.62> has quit IRC (Ping timeout: 264 seconds) | 13:19 | |
Guest13 | using meta-openembedded,qt5,raspberrypi,poky and my layer. | 13:30 |
Guest13 | my image.bb : https://pastebin.com/Ef9URtE6 | 13:30 |
Guest13 | raspberrypi4.conf(32bit) | 13:30 |
LetoThe2nd | Guest13: what happens if you first remove your layer? if it still happends, then does it persist if you remobe meta-qt5? | 13:32 |
Guest13 | meta-qt5 not included in this build. im using meta-poky,openembedded,raspberrypi and my layer. | 13:34 |
LetoThe2nd | then remove your layer. | 13:36 |
Guest13 | i will remove my layer and try, thank you. | 13:36 |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:51 | |
vvn | JaMa: I want to make sure I understand what you said yesterday regarding @LGE. In an ideal world, would you rather maintain a single distro and more images or more distros and less images for your products? | 14:11 |
JaMa | vvn: it depends, having single distro and just multiple images will be best for maintenance, but as mentioned the limitations can restrict you too much (e.g. once different configuration will prefer different gstreamer versions or something like that) | 14:15 |
JaMa | vvn: but if you have powers to enforce it, then great and I'll envy you | 14:16 |
JaMa | I'm still damn angry about allowing this _temporary_ solution to be merged https://github.com/openwebos/meta-webos/commit/7d5dafb66f38b1be71ebda3f6ac988d95f6ef677 as I wasn't able to persuade other people to revert it when I had better alternative available | 14:19 |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 14:19 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 14:20 | |
JaMa | since then almost everything got MACHINE_ARCH not only "formally" due to some dependency being MACHINE_ARCH (luna-service2 was causing most issues back then), but developer started to use MACHINE variable left and right like mad | 14:21 |
*** kscherer <kscherer!~kscherer@dsl-173-206-79-119.tor.primus.ca> has joined #yocto | 14:21 | |
JaMa | and now even when they complain that adding support for new MACHINE is a lot of work (many #ifdefs need to be duplicated in the code to catch another MACHINE value), it's a bit too late to untangle this mess after 10 years | 14:22 |
tlwoerner | qschulz: your meta-rockchip patch ended up in my spam folder... grr | 14:40 |
qschulz | tlwoerner: do you have any information on why? | 14:42 |
vvn | JaMa: I see. That's what scares me with OE sometimes. It's kinda too flexible so you can actually get something done quick, but it is so hard to keep it in such a way that developers don't hack it too much and thus ensure good maintainance. Especially given the distributed nature of the project, it can quickly become an unmanageable mess. | 14:47 |
tlwoerner | qschulz: do we know anyone who works at google's gmail team? everything from TI ends up in spam, anything from mediatek ends up there, heck even many of the bootlin emails end up in my spam folder | 14:48 |
tlwoerner | jonathan cameron's patches and emails end up in my spam folder... | 14:48 |
qschulz | tlwoerner: I do have a weird mail setup too so I wouldn't put all the blame on Google (for once :D) | 14:50 |
tlwoerner | rburton: zeddii: is LTSI still alive? seems like their last kernel was 4.14.75-ltsi from october 2018? https://ltsi.linuxfoundation.org/software/releases/ | 14:51 |
zeddii | it died. | 14:51 |
tlwoerner | long live the king! | 14:52 |
qschulz | tlwoerner: is it replaced by CIP? | 14:52 |
JaMa | vvn: good compromise might be to start with just separate images and once it gets too restrictive adding new DISTRO which would inherit most of the "base" distro to support some "special" configurations all our DISTROs are depending on each other (with webOS OSE the common root base for all) | 14:52 |
tlwoerner | but is the project attempting to track the CIP kernels in any way? (as was done with the LTSI kernels) | 14:54 |
qschulz | tlwoerner: re: "i'm not opposed to meta-rockchip carrying a couple patches for some SoC that doesn't quite have 100% upstream support", our RK3399 module needs 12 patches on top of latest U-Boot which isn't in master branch yet | 14:55 |
tlwoerner | sounds great! | 14:55 |
qschulz | for linux-yocto, there are only a few (though I would need to check how the config is handled, we enforce a local defconfig) | 14:55 |
qschulz | master branch of Yocto* I meant | 14:56 |
qschulz | Hence why I wanted to wait a bit | 14:56 |
tlwoerner | config fragments that are added per machine would be ideal | 14:56 |
tlwoerner | i'm _this_ close to adding some sort of set of rockchip config fragments for configuring a kernel per-machine | 14:57 |
*** Shazam <Shazam!~Shazam@52.95.4.3> has joined #yocto | 14:57 | |
qschulz | the PX30-based module will have some support in kernel 6.1, for U-Boot it's currently 8 patches on top of 2022.10 | 14:57 |
qschulz | tlwoerner: yeah, I'm really not a fan of config fragments :/ | 14:57 |
tlwoerner | qschulz: i'd be interested to know your thinking on them | 14:58 |
qschulz | the one thing I don't like is having to maintain a config in different BSPs, e.g. for our Debian image, Buildroot and then Yocto | 14:59 |
tlwoerner | (we could chat about it at the next happy hour if that's easier, rather than typing a bunch) | 14:59 |
qschulz | shipping + syncing one every now and then is much easier | 14:59 |
vvn | JaMa: totally true. Most of the difference are package selections and default configuration files. For the latter I can maybe use a postprocess function and/or have default files in .../images/${PN} for example. | 14:59 |
qschulz | tlwoerner: conflicting fragments are an issue, because depending on the order in which they are applied, your fragment might be applied but not actually doing anything | 15:00 |
qschulz | tlwoerner: also creating fragments is difficult, especially when you want to combine them | 15:01 |
vvn | The override mechanism looks nice for that, but it doesn't justify different distros yet. And I could use multiconfig and OVERRIDES .= ":${BB_CURRENT_MC}" eventually if I do want to use overrides. | 15:01 |
qschulz | I understand the appeal, and I would really like to like them but the fact that you cannot trust them is a no-go for me. | 15:02 |
zeddii | you can't trust them ? really ? | 15:02 |
* tlwoerner runs | 15:03 | |
* zeddii takes a minute and declines to go any further in the discussion :) | 15:03 | |
vvn | zeddii: I think that qschulz means that fragment-A could set CONFIG_FOO=n then fragment-B (applied after) sets CONFIG_FOO=y and then you end up with FOO being built. | 15:04 |
tlwoerner | i like that you can pair kernel configs with patches | 15:04 |
vvn | zeddii: whoops, ignore my message then :) | 15:04 |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 264 seconds) | 15:04 | |
qschulz | vvn: that was my point yes. But I think we've discussed that already months ago with zeddii and nothing has changed since so not sure there's a point starting the discussion again :) | 15:05 |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 15:05 | |
vvn | qschulz: I actually thought about providing a full config for the kernel, and only relying on the (sub)machine or distro to override it when necessary, because I don't like to maintain multiple fragments too. | 15:07 |
*** Guest13 <Guest13!~Guest13@46.221.0.162> has quit IRC (Quit: Client closed) | 15:08 | |
tlwoerner | the automatic setting (or un-setting) of kconfig values based on other values isn't the "fault" of anything we're doing in yocto, that's the way the kconfig langauge works (or doesn't) | 15:08 |
qschulz | tlwoerner: absolutely! Wasn't implying it was a Yocto issue :) | 15:09 |
tlwoerner | at the end of configuration there is a sanity step (which you can specify the level of analysis) that goes through and lets you know if settings have changed with respect to (what it believes are) your intentions | 15:09 |
tlwoerner | so there is a step to catch these changes, if you set the checking level high enough | 15:09 |
vvn | I wanted to use allmodconfig for meta-ti's beaglebone but that silently didn't work somehow (no additional modules installed despite having kernel-modules in the image). I'm wondering if that's not because of such kconfig ordering. | 15:10 |
qschulz | tlwoerner: i'm listening | 15:10 |
* tlwoerner is looking for the knobs | 15:11 | |
Shazam | Hey! Sorry if this isn't the right place to ask, but does anyone know where to find documentation on building the yocto kernel with BTF/pahole? I'm trying to get this eBPF project running: https://github.com/libbpf/libbpf#bpf-co-re-compile-once--run-everywhere | 15:11 |
vvn | ho, that'd be interesting to have such setting in a variable that a distro could set to enforce strong kernel config checking | 15:11 |
rburton | JPEW: can you check that '[OE-core] [PATCH 2/3] create-spdx: Fix "licenseDeclared" shows weird value' does the right thing? | 15:31 |
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 268 seconds) | 15:32 | |
tlwoerner | qschulz: vvm: in meta/classes-recipe/kernel-yocto.bbclass, towards the top of the file, there are various knobs to setup the *_AUDIT_* levels | 15:41 |
tlwoerner | KCONF_AUDIT_LEVEL=1 will warn you if you set an option that doesn't make it to the final .config | 15:42 |
tlwoerner | KMETA_AUDIT_WERROR will turn the warning into a build failure | 15:43 |
vvn | too bad, meta-ti isn't using kernel-yocto | 15:44 |
*** justache is now known as justHaunted | 15:44 | |
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 15:44 | |
*** Guest14 <Guest14!~Guest14@185.148.248.30> has joined #yocto | 15:46 | |
*** manuel_ <manuel_!~manuel198@185.144.162.58> has quit IRC (Ping timeout: 252 seconds) | 15:47 | |
qschulz | tlwoerner: thanks for the pointers, I'll check that | 15:48 |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 260 seconds) | 15:49 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 15:49 | |
*** Shazam <Shazam!~Shazam@52.95.4.3> has quit IRC (Quit: Client closed) | 15:52 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 264 seconds) | 15:53 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 15:54 | |
*** Guest14 <Guest14!~Guest14@185.148.248.30> has quit IRC (Quit: Client closed) | 15:57 | |
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has quit IRC (Quit: Client closed) | 16:07 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 16:10 | |
*** zpfvo <zpfvo!~fvo@i59F5CEB6.versanet.de> has quit IRC (Quit: Leaving.) | 16:11 | |
*** Shazam <Shazam!~Shazam@52.95.4.19> has joined #yocto | 16:20 | |
JPEW | rburton: ya, I'll look at it later today | 16:26 |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 16:27 | |
*** frieder <frieder!~frieder@200116b824ac6d810000000000001cba.dip.versatel-1u1.de> has quit IRC (Remote host closed the connection) | 16:35 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:39 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds) | 16:42 | |
*** zhmylove <zhmylove!~zhmylove@80.254.50.127> has quit IRC (Quit: Leaving) | 16:42 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.dsl.dyn.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 17:02 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 17:02 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 17:03 | |
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto | 17:04 | |
*** Shazam <Shazam!~Shazam@52.95.4.19> has quit IRC (Quit: Client closed) | 17:04 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 244 seconds) | 17:12 | |
*** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Read error: Connection reset by peer) | 17:12 | |
*** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 17:13 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 17:21 | |
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 17:40 | |
vvn | do you guys usually explicitly set MACHINE/DISTRO_FEATURES or do you usually rely on :append/remove? | 17:48 |
JaMa | :remove is impossible to undo, so don't use it lightly, if you need many :remove ops, then setting whole value would be preferred | 17:50 |
vvn | that's a very good point. I guess :remove should preferably used in end user conf such as local.conf or product specify distros. | 17:55 |
vvn | JaMa: this means that :append and :remove are not interpreted in their order of definitions (i.e. the order of the lines) but :remove's will always be executed *after* the :append's statements by bitbake? | 17:56 |
JaMa | yes and goog practise is to use some intermediate variable as :remove = "${THINGS_TO_REMOVE}", then you can undo it later by setting THINGS_TO_REMOVE = "" | 17:56 |
*** geoff_ <geoff_!~geoff@207.154.79.70> has joined #yocto | 17:57 | |
JaMa | correct, append unlike += is processed later and :remove last | 17:57 |
JaMa | that's why += replaces ?= while :append doesn't | 17:58 |
vvn | += is actually something you cannot undo as well if used on variable flags, e.g. do_image_wic[depends] += "u-boot:do_deploy" in machine confs | 18:02 |
JaMa | right with flags you would need python to undo as well | 18:05 |
vvn | -= would solve this, but well | 18:06 |
*** bfcoqg <bfcoqg!~bfcoqg@user/ako> has joined #yocto | 18:08 | |
*** kevinrowland <kevinrowland!~kevinrowl@136.226.67.0> has joined #yocto | 18:17 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 18:45 | |
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 246 seconds) | 18:52 | |
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 18:58 | |
*** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Remote host closed the connection) | 19:10 | |
*** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 19:11 | |
*** Haxxa <Haxxa!~Haxxa@202-65-79-43.ip4.superloop.com> has quit IRC (Quit: Haxxa flies away.) | 19:15 | |
*** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 252 seconds) | 19:16 | |
*** Haxxa <Haxxa!~Haxxa@89nnjg0xckz9ggn6r5xm.ip6.superloop.com> has joined #yocto | 19:17 | |
*** florian_kc <florian_kc!~florian@dynamic-002-243-184-039.2.243.pool.telefonica.de> has joined #yocto | 19:54 | |
vvn | JaMa: actually the fact that DISTRO_FEATURES is mixed in most PACKAGECONFIGs makes it unrealistic to maintain a single distro for multiple embedded products (you end up compiling support for unnecessary features and pull in dependencies you don't even need). | 20:13 |
*** mvlad <mvlad!~mvlad@2a02:2f08:4605:ca00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 20:15 | |
JaMa | vvn: well as I said it depends how different these configurations are | 20:30 |
JaMa | our targets were from watches through phones to TVs and car infotainment and DISTRO_FEATURES could be used the same for all, other differences were worse | 20:32 |
JaMa | or evil BSPs where most a DISTRO was dealing with various issues and limitations of that | 20:33 |
*** florian_kc <florian_kc!~florian@dynamic-002-243-184-039.2.243.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 20:48 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 246 seconds) | 20:49 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 20:49 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 255 seconds) | 20:54 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 20:54 | |
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 21:00 | |
vvn | JaMa: but let's say watch-foo has no sound support, if you keep e.g. alsa and pulseaudio in DISTRO_FEATURES, packages (e.g. qt*) will DEPENDS on alsa-lib even though MACHINE_FEATURES doesn't have alsa. How do you deal with that? | 21:07 |
JaMa | we would enable it for all, because our target devices have very different form factor, but all of them support sound, wifi, media, ... | 21:09 |
vvn | well sound might not be the best example in your case, but you see what I mean | 21:10 |
JaMa | I know what you mean, but still our targets are similar, building image for something like pinecil with the same DISTRO as TV would be different story | 21:12 |
JaMa | and we do have multiple hierarchical DISTROs | 21:13 |
vvn | and if a distro uses :machine overrides, then you have to be careful and likely use a different TMPDIR, which kinda comes back to defining different distros in the end :/ | 21:15 |
vvn | JaMa: or actually, is it safe to use the same TMPDIR with something like DISTRO_FEATURES:remove:machine-foo = "feature-foo"? | 21:35 |
JaMa | DISTRO_FEATURES are for DISTRO to define, they shouldn't be MACHINE specific | 21:36 |
JaMa | using the same TMPDIR is fine as long as you PACKAGE_ARCHs are set correctly, oe-core/scripts/sstate-diff-machines.sh can help to check for possible issues | 21:37 |
JaMa | if there are issues like this, then bitbake will still correctly rebuild what changed (based on sstate signatures), but if you're using package feed, then you won't know which "version" you'll fetch from deploy/ipk/arch/foo_bar.ipk | 21:39 |
vvn | this is what I want to avoid indeed | 21:40 |
JaMa | if you're just building images and never use package feed, but it's still an issue, which in the end lead to the MACHINE_ARCH being default PACKAGE_ARCH in webOS I mentioned before | 21:40 |
JaMa | s/package feed, but/package feed, then it's not so bad, but/g | 21:41 |
vvn | I see the reasoning behind MACHINE_ARCH fix, this makes all packages being in deploy/ipk/<machine>/ instead of <arch> or all for example | 21:42 |
vvn | thus "easily" avoiding clashes between distros | 21:43 |
JaMa | between machines | 21:43 |
vvn | oops yes | 21:43 |
vvn | at the cost of duplicating a lot of packages and compiling exactly the same thing multiple times | 21:44 |
JaMa | but that's terrible work around for bad architecture of some components, not realy a fix | 21:44 |
JaMa | that's why it was supposed to be temporary in 2013 :) | 21:45 |
vvn | ha ha | 21:45 |
vvn | it's also tempting to write submachine configs in order to isolate such tweaks, but again it's stupid because you won't share the kernel or other identical MACHINE_ARCH packages | 21:46 |
JaMa | once you add chromium into the image, the build time of kernel becames irrelevant :) | 21:47 |
vvn | I did and that's why I'm asking so much about the ideal setup for multiple products. I really wish to reuse qtwebengine, kernels and stuffs like that if possible | 21:48 |
vvn | even though meta-ti's linux-ti-staging recompiles almost every times... | 21:50 |
JaMa | for LuneOS we're still using single DISTRO and multiple MACHINEs per TUNE_PKGARCH and it saves a lot of build time, but issues still sneak in from time to time, e.g. https://github.com/webOS-ports/meta-pine64-luneos/commit/8946d3e2350ae83fbb001ba640db59b207341481 which was found with that oe-core/scripts/sstate-diff-machines.sh script | 21:51 |
vvn | JaMa: so it's ok in this case to have different PACKAGECONFIG per machine for the same distro? | 21:59 |
JaMa | no, that's why had to fix it, so that pp has panfrost enabled as well even when it doesn't use in runtime | 22:01 |
vvn | I see | 22:02 |
vvn | so that sstate can be reused | 22:02 |
vvn | thinking that way (doing your best to stick to a single distro), I'm wondering what is the reasoning for removing a distro feature vs keeping them all | 22:03 |
vvn | (like "ext2", "wiki", or "xattr", ...) | 22:04 |
vvn | s/wiki/wifi/ | 22:04 |
JaMa | it's union of all the features needed by machines/images it needs to support | 22:06 |
JaMa | if you're supporting only MACHINEs with very small flash and limited set of possible features (e.g. all headless) then you can remove a lot of them | 22:07 |
*** bfcoqg <bfcoqg!~bfcoqg@user/ako> has quit IRC (Ping timeout: 246 seconds) | 22:08 | |
JaMa | if your target are "embedded" devices which are bigger than average desktop and need to support all latest fancy features, then you'll probably just add more DISTRO_FEATUREs for ML, NFT, .. | 22:08 |
vvn | JaMa: then if you support both powerful and very limited hardware, then you'll likely need two distros | 22:09 |
JaMa | yes, it will be easier in such case | 22:10 |
vvn | I unfortunately have to support this case ha ha | 22:11 |
JaMa | that's what I was asking at first :) | 22:11 |
*** florian_kc <florian_kc!~florian@dynamic-002-243-184-039.2.243.pool.telefonica.de> has joined #yocto | 22:11 | |
JaMa | they can still share a lot of .inc files for common parts | 22:12 |
JaMa | anyway, my builds are now triggered, time for sleep | 22:12 |
vvn | thank you, have a good build o/ | 22:13 |
*** jetm <jetm!~quassel@177.93.3.185> has joined #yocto | 22:28 | |
*** jetm <jetm!~quassel@177.93.3.185> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 22:36 | |
*** pasherring <pasherring!~paulo@2804:14c:598a:86b6:649f:e36c:4315:5376> has quit IRC (Quit: Leaving) | 22:44 | |
*** florian_kc <florian_kc!~florian@dynamic-002-243-184-039.2.243.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 22:49 | |
*** geoff_ <geoff_!~geoff@207.154.79.70> has quit IRC (Remote host closed the connection) | 22:51 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 22:59 | |
kiwi_29_[m] | Hello, I have a custom distro make from core-image-minimal and I am NOT using systemd as init system.. For including crontab, I am compiling the cronie recipe, which compiles without issues. However, when I upload the recipe on my package repo and then use apt-get install cronie, then I get these errors The following... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/8c701eef0ae24a7984f17a3ee739635b629068cd>) | 23:02 |
kiwi_29_[m] | s/make/made/, s/cronie_1/cronie\_1/ | 23:05 |
kiwi_29_[m] | * Hello, I have a custom distro made from core-image-minimal and I am NOT using systemd as init system.. For including crontab, I am compiling the cronie recipe, which compiles without issues. However, when I upload the recipe on my package repo and then use apt-get install cronie, then I get these errors... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/7100c67b58700346e93eb87e9531a293555eca37>) | 23:06 |
*** kscherer <kscherer!~kscherer@dsl-173-206-79-119.tor.primus.ca> has quit IRC (Quit: Konversation terminated!) | 23:12 | |
kiwi_29_[m] | * Hello, I have a custom distro made from core-image-minimal and I am NOT using systemd as init system.. For including crontab, I am compiling the **cronie** recipe, which compiles without issues. However, when I upload the recipe on my package repo and then use apt-get install cronie, then I get these errors... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/9187500b321a8b5c24d7a1c08b47067cc1205c00>) | 23:47 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!