Wednesday, 2022-10-19

*** 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 #yocto00: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 #yocto00: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 #yocto00: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 #yocto00:34
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto00: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 #yocto00: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 #yocto01:06
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto01: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 #yocto01: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 #yocto01:23
*** RobertBerger <RobertBerger!~rber|res@91-114-219-213.adsl.highway.telekom.at> has joined #yocto01: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 #yocto02: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 #yocto02: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 #yocto02:38
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto03:23
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer)03:24
*** camus1 is now known as camus03: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 #yocto03:48
*** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has joined #yocto03:48
*** starblue <starblue!~juergen@dslb-188-100-139-193.188.100.pools.vodafone-ip.de> has joined #yocto03:48
*** fleg <fleg!~fleg@user/fleg> has joined #yocto03:49
*** T_UNIX[m] <T_UNIX[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto03:49
*** barometz <barometz!~dvanb@92-109-61-249.cable.dynamic.v4.ziggo.nl> has joined #yocto03:49
*** SSmoogen <SSmoogen!~Smooge@centos/qa/smooge> has joined #yocto03:49
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto03:49
*** hpsy[m] <hpsy[m]!~hpsymatri@2001:470:69fc:105::f822> has joined #yocto03:50
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto03:50
*** Haxxa <Haxxa!~Haxxa@202-65-79-43.ip4.superloop.com> has joined #yocto03:50
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto03:50
*** zkrx <zkrx!~slimshady@adsl-89-217-230-95.adslplus.ch> has joined #yocto03:53
*** khem <khem!~khem@2001:470:69fc:105::b81> has joined #yocto03:54
*** kmaincent[m] <kmaincent[m]!~kmaincent@2001:470:69fc:105::2:825d> has joined #yocto03:55
*** MichaelNazzareno <MichaelNazzareno!~panicking@2001:470:69fc:105::2:886d> has joined #yocto03:55
*** skoink[m] <skoink[m]!~skoinkmat@2001:470:69fc:105::2:8a4c> has joined #yocto03:55
*** jaskij[m] <jaskij[m]!~jaskijmat@2001:470:69fc:105::fa76> has joined #yocto03: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 #yocto04:19
*** schtobia <schtobia!~quassel@schmidl.dev> has quit IRC (Quit: Bye!)04:42
*** schtobia <schtobia!~quassel@88.99.170.71> has joined #yocto04: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 #yocto04:59
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto04: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 #yocto05: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 #yocto05:48
*** vladest <vladest!~Thunderbi@109.202.94.214> has quit IRC (Quit: vladest)06:10
*** vladest <vladest!~Thunderbi@109.202.94.214> has joined #yocto06:12
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto06: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 #yocto06: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 #yocto06: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 #yocto06:36
*** frieder <frieder!~frieder@200116b824ac6d810000000000001cba.dip.versatel-1u1.de> has joined #yocto06: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 #yocto06: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 #yocto06:54
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto07:01
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:02
*** vladest <vladest!~Thunderbi@109.202.94.214> has quit IRC (Quit: vladest)07:05
*** vladest <vladest!~Thunderbi@109.202.94.214> has joined #yocto07:07
*** mckoan|away is now known as mckoan07:08
mckoangood morning07: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 #yocto07: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 #yocto07: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 #yocto07:27
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto07: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 #yocto07:35
Schlumpfgood morning07:40
*** zpfvo <zpfvo!~fvo@89.245.206.182> has joined #yocto07: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 #yocto07:46
rfuentessmorning07:47
*** manuel_ <manuel_!~manuel198@185.144.162.58> has joined #yocto07: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 #yocto07:53
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)07:53
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto07:53
*** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto08:00
qschulzo/08:03
*** hcg <hcg!~hcg@178.197.224.127> has joined #yocto08: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 #yocto08:29
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08: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 #yocto08: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 #yocto08:34
*** nucatus <nucatus!~nucatus@i16-les02-ix2-176-180-153-249.sfr.lns.abo.bbox.fr> has joined #yocto08: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 #yocto08:36
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has joined #yocto08: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 #yocto08:44
*** zpfvo <zpfvo!~fvo@89.245.206.182> has quit IRC (Ping timeout: 268 seconds)08:45
qschulztlwoerner: 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 #yocto08:47
qschulzI 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 layer08:47
qschulzI'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
qschulztlwoerner: 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 #yocto08:54
kayterina[m]Is there something special when SRC_URI:append:machineA in a native recipe? Because it is read once?08:56
qschulzkayterina[m]: using a machine override in a native recipe shows there is some logic issue08:58
qschulza native recipe runs on your host, it does not (and should not) have knowledge of the target your're building for08:59
kayterina[m]hm.it is logical.08:59
qschulzsince 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 it08:59
qschulzkayterina[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 #yocto09: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
qschulzkayterina[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 .mk09:11
kayterina[m]some flags and a library09:11
qschulzkayterina[m]: I would go with a different recipe per machine you want to support09:12
qschulzat least a different BPN/PN09:12
qschulzand you'll need to explicit on which "version" of the native recipe a given target recipe depends on09:12
qschulzthe 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
qschulzbut ideally, modifying the native recipe to have one binary that can be configured via environment variables or parameters would be best09: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
qschulzkayterina[m]: that's not going to change the fact that your native recipe does not know about your machine09:16
kayterina[m]Wait, $machine has a value inside the recipe.09:17
kayterina[m]it should not know, but it knows.09:17
qschulzkayterina[m]: check the value of OVERRIDES09:17
qschulzI don't think you have this info there09: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}:forcevariable09: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}:forcevariable09:21
qschulzkayterina[m]: OVERRIDES is the mechanism that allows you to do SRC_URI:append:machineA09:24
qschulzif machineA is not in OVERRIDES, it won't work09:24
qschulzand I highly suspect target machines aren't part of OVERRIDES for native recipes09:24
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds)09:26
rburtoncorrect, native recipes have no idea what the target is09:28
qschulzkayterina[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 idea09:28
rburtonits a terrible idea09: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 #yocto09:29
kayterina[m]I will try to keep good ideas on the project.09:29
rburtonif you *really* need the host binary to be modified per-target then look at the cross class, instead of native09: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 #yocto10:02
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto10:03
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)10:09
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto10:09
*** Bardon_ <Bardon_!~Bardon@user/Bardon> has joined #yocto10: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 #yocto10:18
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 258 seconds)10:29
*** mckoan is now known as mckoan|away10:34
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto10:41
*** zhmylove <zhmylove!~zhmylove@80.254.50.127> has joined #yocto10: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 #yocto11:08
*** Schiller <Schiller!~Schiller@dynamic-046-114-211-237.46.114.pool.telefonica.de> has joined #yocto11:11
*** seninha <seninha!~seninha@user/seninha> has joined #yocto11: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 #yocto11:15
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto11:15
*** alejandrohs <alejandrohs!~alejandro@189.237.55.61> has quit IRC (Ping timeout: 264 seconds)11:17
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto11:19
*** mvlad <mvlad!~mvlad@2a02:2f08:4605:ca00:24d7:51ff:fed6:906d> has joined #yocto11:23
tlwoernerqschulz: absolutely YES! :-D :-D11:42
tlwoernerand i'm not opposed to meta-rockchip carrying a couple patches for some SoC that doesn't quite have 100% upstream support11:44
tlwoernerdoes YP have some sort of vision/roadmap document that lays out its linux-yocto strategy? specifically wrt upstream versions?11:46
tlwoernerzeddii: ^11:46
*** fitzsim <fitzsim!~user@mail.fitzsim.org> has joined #yocto11: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 #yocto11: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 #yocto11:55
*** hcg <hcg!~hcg@178.197.233.207> has joined #yocto11:55
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto11:56
*** vladest <vladest!~Thunderbi@109.202.94.214> has quit IRC (Ping timeout: 264 seconds)12:13
rburtontlwoerner: latest LTS version, as close to mainline as possible12:14
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)12:15
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto12:15
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto12:18
*** Guest13 <Guest13!~Guest13@46.221.0.162> has joined #yocto12:25
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)12:25
Guest13hi12:25
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto12:25
Guest13hi, i am getting error while trying to build initramfs : pastebin.com/BwDR2kJk12:27
zeddiitlwoerner: 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 #yocto12: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 #yocto12: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 #yocto12:36
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)12:41
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto12:42
*** hcg <hcg!~hcg@178.197.233.207> has quit IRC (Ping timeout: 244 seconds)12:44
*** SSmoogen is now known as Ebeneezer_Smooge12:51
tlwoernerzeddii: yes, but i was hoping to point someone to something "concrete". rburton's wording will do nicely, thanks!12:57
zeddiiit's on the wiki somewhere. I remember writing it.13:02
tlwoernerzeddii: 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
LetoThe2ndzeddii: that means nothing, if your brain is even only remotely similar to mine.13:04
tlwoernerhttps://wiki.yoctoproject.org/wiki/Linux_Yocto13:04
zeddiiLetoThe2nd. precisely. I always say that wiki pages are where information goes to be lost.13:05
LetoThe2ndzeddii: +113:05
zeddiitlwoerner. impressive! :)13:05
tlwoernerzeddii: i'll take a poke at updating it post 3.113:06
zeddiiyou'd have my thanks!!13:06
tlwoernermaybe it should also make some mention of the kernel mixin?13:07
tlwoerner(for 3.1)13:07
rburtonwhat mixin?13:07
rburtonit looks like paul's meta-kernel-mainline is dead13:07
tlwoerner:-(13:08
* tlwoerner hopes paul is fairing better13:09
*** pasherring <pasherring!~paulo@2804:14c:598a:86b6:649f:e36c:4315:5376> has joined #yocto13:12
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)13:12
Guest13trying 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 #yocto13:12
LetoThe2ndGuest13: guess thats some package you're pulling in. what are you installing? does it happen for core-image-minimal also?13:16
Guest13yes, it happens when getting "core-image-minimal" build as well.13:17
*** vladest <vladest!~Thunderbi@214.94.cust.tetanet.cz> has joined #yocto13:18
LetoThe2ndGuest13: 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
Guest13using meta-openembedded,qt5,raspberrypi,poky and my layer.13:30
Guest13my image.bb : https://pastebin.com/Ef9URtE613:30
Guest13raspberrypi4.conf(32bit)13:30
LetoThe2ndGuest13: what happens if you first remove your layer? if it still happends, then does it persist if you remobe meta-qt5?13:32
Guest13meta-qt5 not included in this build. im using meta-poky,openembedded,raspberrypi and my layer.13:34
LetoThe2ndthen remove your layer.13:36
Guest13i will remove my layer and try, thank you.13:36
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto13:51
vvnJaMa: 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
JaMavvn: 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
JaMavvn: but if you have powers to enforce it, then great and I'll envy you14:16
JaMaI'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 available14: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 #yocto14:20
JaMasince 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 mad14:21
*** kscherer <kscherer!~kscherer@dsl-173-206-79-119.tor.primus.ca> has joined #yocto14:21
JaMaand 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 years14:22
tlwoernerqschulz: your meta-rockchip patch ended up in my spam folder... grr14:40
qschulztlwoerner: do you have any information on why?14:42
vvnJaMa: 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
tlwoernerqschulz: 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 folder14:48
tlwoernerjonathan cameron's patches and emails end up in my spam folder...14:48
qschulztlwoerner: I do have a weird mail setup too so I wouldn't put all the blame on Google (for once :D)14:50
tlwoernerrburton: 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
zeddiiit died.14:51
tlwoernerlong live the king!14:52
qschulztlwoerner: is it replaced by CIP?14:52
JaMavvn: 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
tlwoernerbut is the project attempting to track the CIP kernels in any way? (as was done with the LTSI kernels)14:54
qschulztlwoerner: 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 yet14:55
tlwoernersounds great!14:55
qschulzfor 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
qschulzmaster branch of Yocto* I meant14:56
qschulzHence why I wanted to wait a bit14:56
tlwoernerconfig fragments that are added per machine would be ideal14:56
tlwoerneri'm _this_ close to adding some sort of set of rockchip config fragments for configuring a kernel per-machine14:57
*** Shazam <Shazam!~Shazam@52.95.4.3> has joined #yocto14:57
qschulzthe PX30-based module will have some support in kernel 6.1, for U-Boot it's currently 8 patches on top of 2022.1014:57
qschulztlwoerner: yeah, I'm really not a fan of config fragments :/14:57
tlwoernerqschulz: i'd be interested to know your thinking on them14:58
qschulzthe one thing I don't like is having to maintain a config in different BSPs, e.g. for our Debian image, Buildroot and then Yocto14:59
tlwoerner(we could chat about it at the next happy hour if that's easier, rather than typing a bunch)14:59
qschulzshipping + syncing one every now and then is much easier14:59
vvnJaMa: 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
qschulztlwoerner: conflicting fragments are an issue, because depending on the order in which they are applied, your fragment might be applied but not actually doing anything15:00
qschulztlwoerner: also creating fragments is difficult, especially when you want to combine them15:01
vvnThe 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
qschulzI 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
zeddiiyou can't trust them ? really ?15:02
* tlwoerner runs15:03
* zeddii takes a minute and declines to go any further in the discussion :)15:03
vvnzeddii: 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
tlwoerneri like that you can pair kernel configs with patches15:04
vvnzeddii: whoops, ignore my message then :)15:04
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 264 seconds)15:04
qschulzvvn: 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 #yocto15:05
vvnqschulz: 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
tlwoernerthe 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
qschulztlwoerner: absolutely! Wasn't implying it was a Yocto issue :)15:09
tlwoernerat 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 intentions15:09
tlwoernerso there is a step to catch these changes, if you set the checking level high enough15:09
vvnI 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
qschulztlwoerner: i'm listening15:10
* tlwoerner is looking for the knobs15:11
ShazamHey! 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-everywhere15:11
vvnho, that'd be interesting to have such setting in a variable that a distro could set to enforce strong kernel config checking15:11
rburtonJPEW: 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
tlwoernerqschulz: vvm: in meta/classes-recipe/kernel-yocto.bbclass, towards the top of the file, there are various knobs to setup the *_AUDIT_* levels15:41
tlwoernerKCONF_AUDIT_LEVEL=1 will warn you if you set an option that doesn't make it to the final .config15:42
tlwoernerKMETA_AUDIT_WERROR will turn the warning into a build failure15:43
vvntoo bad, meta-ti isn't using kernel-yocto15:44
*** justache is now known as justHaunted15:44
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto15:44
*** Guest14 <Guest14!~Guest14@185.148.248.30> has joined #yocto15:46
*** manuel_ <manuel_!~manuel198@185.144.162.58> has quit IRC (Ping timeout: 252 seconds)15:47
qschulztlwoerner: thanks for the pointers, I'll check that15: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 #yocto15: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 #yocto15: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 #yocto16:20
JPEWrburton: ya, I'll look at it later today16: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 #yocto17: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 #yocto17: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 #yocto17: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 #yocto17:40
vvndo 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 preferred17:50
vvnthat'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
vvnJaMa: 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
JaMayes 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 #yocto17:57
JaMacorrect, append unlike += is processed later and :remove last17:57
JaMathat's why += replaces ?= while :append doesn't17: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 confs18:02
JaMaright with flags you would need python to undo as well18:05
vvn-= would solve this, but well18:06
*** bfcoqg <bfcoqg!~bfcoqg@user/ako> has joined #yocto18:08
*** kevinrowland <kevinrowland!~kevinrowl@136.226.67.0> has joined #yocto18:17
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto18: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 #yocto18: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 #yocto19: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 #yocto19:17
*** florian_kc <florian_kc!~florian@dynamic-002-243-184-039.2.243.pool.telefonica.de> has joined #yocto19:54
vvnJaMa: 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
JaMavvn: well as I said it depends how different these configurations are20:30
JaMaour targets were from watches through phones to TVs and car infotainment and DISTRO_FEATURES could be used the same for all, other differences were worse20:32
JaMaor evil BSPs where most a DISTRO was dealing with various issues and limitations of that20: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 #yocto20: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 #yocto20:54
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)21:00
vvnJaMa: 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
JaMawe would enable it for all, because our target devices have very different form factor, but all of them support sound, wifi, media, ...21:09
vvnwell sound might not be the best example in your case, but you see what I mean21:10
JaMaI 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 story21:12
JaMaand we do have multiple hierarchical DISTROs21:13
vvnand 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
vvnJaMa: or actually, is it safe to use the same TMPDIR with something like DISTRO_FEATURES:remove:machine-foo = "feature-foo"?21:35
JaMaDISTRO_FEATURES are for DISTRO to define, they shouldn't be MACHINE specific21:36
JaMausing 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 issues21:37
JaMaif 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.ipk21:39
vvnthis is what I want to avoid indeed21:40
JaMaif 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 before21:40
JaMas/package feed, but/package feed, then it's not so bad, but/g21:41
vvnI see the reasoning behind MACHINE_ARCH fix, this makes all packages being in deploy/ipk/<machine>/ instead of <arch> or all for example21:42
vvnthus "easily" avoiding clashes between distros21:43
JaMabetween machines21:43
vvnoops yes21:43
vvnat the cost of duplicating a lot of packages and compiling exactly the same thing multiple times21:44
JaMabut that's terrible work around for bad architecture of some components, not realy a fix21:44
JaMathat's why it was supposed to be temporary in 2013 :)21:45
vvnha ha21:45
vvnit'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 packages21:46
JaMaonce you add chromium into the image, the build time of kernel becames irrelevant :)21:47
vvnI 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 possible21:48
vvneven though meta-ti's linux-ti-staging recompiles almost every times...21:50
JaMafor 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 script21:51
vvnJaMa: so it's ok in this case to have different PACKAGECONFIG per machine for the same distro?21:59
JaMano, that's why had to fix it, so that pp has panfrost enabled as well even when it doesn't use in runtime22:01
vvnI see22:02
vvnso that sstate can be reused22:02
vvnthinking 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 all22:03
vvn(like "ext2", "wiki", or "xattr", ...)22:04
vvns/wiki/wifi/22:04
JaMait's union of all the features needed by machines/images it needs to support22:06
JaMaif 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 them22:07
*** bfcoqg <bfcoqg!~bfcoqg@user/ako> has quit IRC (Ping timeout: 246 seconds)22:08
JaMaif 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
vvnJaMa: then if you support both powerful and very limited hardware, then you'll likely need two distros22:09
JaMayes, it will be easier in such case22:10
vvnI unfortunately have to support this case ha ha22:11
JaMathat'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 #yocto22:11
JaMathey can still share a lot of .inc files for common parts22:12
JaMaanyway, my builds are now triggered, time for sleep22:12
vvnthank you, have a good build o/22:13
*** jetm <jetm!~quassel@177.93.3.185> has joined #yocto22: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 #yocto22: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/!