Friday, 2022-04-29

*** GLumen_ <GLumen_!~Gregory@97-113-69-197.tukw.qwest.net> has quit IRC (Ping timeout: 276 seconds)00:02
*** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)00:30
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 276 seconds)00:34
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:37
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto00:39
*** turkeykittin <turkeykittin!~turkeykit@c-73-231-202-96.hsd1.ca.comcast.net> has quit IRC (Quit: Connection closed)00:57
*** amahnui1 <amahnui1!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)01:19
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Quit: Konversation terminated!)01:20
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto01:29
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)01:38
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)01:41
*** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has joined #yocto01:54
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 272 seconds)02:19
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto02:19
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 272 seconds)02:24
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto02:25
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto02:26
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Client Quit)02:30
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds)03:28
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto03:29
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 240 seconds)03:33
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto03:34
*** amitk <amitk!~amit@103.59.74.42> has joined #yocto03:46
*** tlwoerner_ <tlwoerner_!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto04:22
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto04:23
*** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Ping timeout: 260 seconds)04:24
*** tlwoerner_ <tlwoerner_!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Ping timeout: 240 seconds)04:26
*** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto04:31
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds)04:39
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto04:39
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 240 seconds)04:43
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto04:44
*** thomasd13 <thomasd13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto05:14
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto05:25
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)05:33
thomasd13Good morning guys05:37
*** tgamblin <tgamblin!~tgamblin@cpe64777de11593-cm64777de11590.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 256 seconds)05:38
*** adrian_ <adrian_!~F_Adrian@165.225.27.3> has joined #yocto05:58
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06:00
*** adrian__ <adrian__!~F_Adrian@62.32.0.69> has quit IRC (Ping timeout: 272 seconds)06:01
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto06:02
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer)06:02
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto06:05
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)06:25
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06:26
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto06:31
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer)06:38
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto06:39
*** mckoan|away is now known as mckoan06:40
khemhttps://www.phoronix.com/scan.php?page=news_item&px=Yocto-4.0-Released06:44
*** amahnui1 <amahnui1!uid502939@id-502939.tinside.irccloud.com> has joined #yocto06:46
LetoThe2ndyo dudX06:53
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto07:01
mckoangood morning07:03
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto07:08
*** pbergin <pbergin!~pbergin@83.218.73.98> has joined #yocto07:09
*** hcg <hcg!~hcg@185.210.97.85> has joined #yocto07:09
*** amitk <amitk!~amit@103.59.74.42> has quit IRC (Ping timeout: 276 seconds)07:13
*** amitk <amitk!~amit@103.59.74.42> has joined #yocto07:14
*** gsalazar <gsalazar!~gsalazar@213.58.201.38> has joined #yocto07:14
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Quit: WeeChat 3.5)07:22
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has joined #yocto07:54
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has joined #yocto07:59
*** mkorpershoek <mkorpershoek!sid537056@id-537056.uxbridge.irccloud.com> has joined #yocto08:03
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 272 seconds)08:14
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto08:15
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 246 seconds)08:19
kanavinmanuel1985, not in a standard setup, only through use of externalsrc, e.g. 'devtool modify'08:19
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto08:19
*** camus <camus!~Instantbi@2409:8a1e:9112:6900:a067:7638:8bbf:a96f> has quit IRC (Ping timeout: 240 seconds)08:29
*** camus <camus!~Instantbi@183.192.143.145> has joined #yocto08:30
*** ilunev <ilunev!~koolkhel@95.174.114.26> has joined #yocto08:33
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has quit IRC (Quit: Client closed)08:37
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has joined #yocto08:41
kayterina[m]hello. In a recipe that simply installs a config file, I can do so with do_install{ install -m blabla }. Should I also add the config file in the package with FILES variable?08:43
kranzokayterina[m]: if its not in the default directories inherited from cmake/autotools etc you need to add it, so it will be packed08:49
kayterina[m]hm, where are the default directories from cmake? I also do not compile anithing, so I don't explicitely inherit cmake08:51
kranzootherwise it will trigger: installed-vs-shipped08:51
kranzohttps://docs.yoctoproject.org/ref-manual/classes.html?highlight=insane#insane-bbclass08:51
kranzothen FILES:${PN} += "path/to/your/file" should do the trick08:52
kranzoyou can check with bitbake -e <recipe> |less and search for FILES_ or FILES: depending on your yocto version08:55
*** ilunev <ilunev!~koolkhel@95.174.114.26> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)08:57
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto09:01
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has quit IRC (Remote host closed the connection)09:05
*** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has joined #yocto09:19
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has joined #yocto09:19
kayterina[m]I see that FILES_${PN} in bitbake.conf includes $sysconfdir and ${datadir}/${BPN}09:21
kayterina[m]Does that mean that it is redundant to set in the recipe09:21
kayterina[m]FILES_${PN} += "${sysconfdir}/my-config/my-global.conf"?09:21
mnmeHi all! What's the best way to do an inherit depending on a PACKAGECONFIG? And is there a way to "remove" an inherit in a bbappend?09:23
ptsneveskayterina[m] if BPN==my-config yes09:26
_angelo_hi, building kernel i get ".do_preconfigure.1236297' failed with exit code 128:" but no other info.09:26
kayterina[m]Is the PATH '/usr/share/my-config' equal to  '/usr/share/my-config/my-global.conf' for the FILES variable?09:26
ptsneveskayterina[m] give it a try. If the file is not packaged anywhere you will get an error. If you are unsure it went to another package just check the packages-split directory in the recipe's workspace09:27
kayterina[m]The recipe builds without errors and I checked FILES_ with bitbake -e. Τhe config ends-up in packages-split. But the client builds all their recipes with appending to FILES with these paths, ${datadir}, ${sysconfdir}09:32
ptsnevesok good so everything is working. that is a good step. If they do it, there is no harm besides it being redundant and may create some cargo cutting(quite common in Yocto). Harmless though09:34
kayterina[m]well, thanks. What is 'cargo cutting'?09:38
_angelo_sry, solved, it was a "SRC_URI = " in place of "SRC_URI +=". Error message was anyway not helping.09:40
ptsnevescargo culting, sorry typo. People trying to do something have seen before in a ritualistic way without really understanding what they are doing https://en.wikipedia.org/wiki/Cargo_cult09:41
thomasd13Lol - Its such a satisfying feeling, when a yocto build keeps all the 24 cores at 100% for hours09:44
kranzoptsneves: i love learning new descriptions of behaviour i've seen before :D09:44
thomasd13work harder server. WORK HARDER!09:45
kayterina[m]haha,nice.09:45
ptsnevesoh it seems that wikipedia even has a cargo cult disambiguation for programming https://en.wikipedia.org/wiki/Cargo_cult_programming09:55
*** amitk <amitk!~amit@103.59.74.42> has quit IRC (Ping timeout: 250 seconds)10:00
*** amitk <amitk!~amit@103.59.74.42> has joined #yocto10:01
*** argonautx <argonautx!~argonautx@muedsl-82-207-240-130.citykom.de> has joined #yocto10:03
LetoThe2ndin which file is u-boot hiding on the raspi? I'm just too stupid to find the link between recipe/package and resulting image at the moment.10:13
qschulzLetoThe2nd: U-Boot might not be running on the RPi10:14
LetoThe2ndqschulz: it certainly is, I get the messages on the serial.10:15
ptsneveshttps://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/bootfiles/rpi-bootfiles.bb10:17
ptsnevesAnd yes it uses uboot10:17
LetoThe2ndptsneves: yeah but still, where is it?10:19
ptsnevesin a .bin file?10:20
agherzanLetoThe2nd: it uses the recipe in oe-core10:20
ptsneves"${DEPLOYDIR}/${BOOTFILES_DIR_NAME}"10:20
agherzanfor uboot.10:20
agherzanWhat you are pointing at ptsneves is the firmware from rpi which in turn chains the uboot when used10:21
agherzanHere is the uboot bbappend https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/u-boot/u-boot_%25.bbappend10:21
ptsneves@agherzan. You are right. Even so that bbappend does not modify where the files are deployed. So the oe-core defaults prevail10:22
agherzanThat would be correct. So what is the question again?10:22
LetoThe2ndagherzan: ah I'm getting closer. so the magic is the UBOOT_BINARY variable?10:22
ptsnevesactually agherzan is the maintainer of the layer *@ptsneves shows itself self out*10:22
LetoThe2ndptsneves: i know :-)10:24
agherzanLetoThe2nd: the entire logic is in https://git.yoctoproject.org/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc#n20510:24
*** goliath <goliath!~goliath@user/goliath> has joined #yocto10:25
LetoThe2ndagherzan: okay i'll dig deeper there then. thanks!10:25
agherzanthe deployment is triggered by https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi4.conf#L19 LetoThe2nd10:26
agherzanSo at first sight you probably are looking at this for rpi: https://git.yoctoproject.org/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc#n5710:26
LetoThe2ndagherzan: well if I could only buy an rpi4.... *SCNR*10:27
agherzanYou don't need to buy an rPi to build u-boot10:27
LetoThe2ndyeah, thanks!10:27
agherzan:)10:27
LetoThe2ndnah, referring to you pointing at the rpi4-config.10:27
ptsnevesLetoThe2nd why? Do you not have >$100 for a $20 piece?10:28
agherzanI see LetoThe2nd . The thing is identical for any other machine in meta-raspberrypi10:28
agherzanFor example here is the conf for rpi3 https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi3.conf#L1710:29
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 240 seconds)10:32
*** hcg <hcg!~hcg@185.210.97.85> has quit IRC (Quit: Client closed)10:34
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)10:34
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 252 seconds)10:36
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has joined #yocto10:39
*** thomasd13 <thomasd13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 256 seconds)11:10
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds)11:18
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto11:19
*** kovalevsky <kovalevsky!~kovalevsk@fedora/kovalevsky> has joined #yocto11:23
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 272 seconds)11:24
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto11:24
ptsneveshas anybody had issues with kernel-devsrc recipe causing races with make-mod-scripts? I see there is a do_install[lockfiles] but the kernel-scripts.lock does not get used anywhere else, leading me to believe it is not working as intended11:31
ptsnevesi ask because i have work-shared/kernel-source files magically not existing.11:31
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has quit IRC (Quit: Client closed)11:39
*** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has quit IRC (Quit: Client closed)11:44
*** hcg <hcg!~hcg@185.210.97.85> has joined #yocto11:47
*** hcg <hcg!~hcg@185.210.97.85> has quit IRC (Quit: Ping timeout (120 seconds))12:00
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 272 seconds)12:03
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto12:03
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)12:06
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has quit IRC (Quit: Client closed)12:08
ptsnevesOk regarding the issue with kernel-devsrc i have the following model:12:09
ptsneveskernel-devsrc.bb:do_install[depends] += virtual/kernel:do_shared_workdir12:09
ptsnevesvirtual/kernel:do_shared_workdir is a cleandir task for the kernel build dir!12:09
ptsnevesbut in kernel-devsrc.bb: module_base is inherited as well and that means that kernel-devsrc.bb:do_configure[depends] += make-mod-scripts:do_compile and that means that make-mod-scripts:do_compile happens after make-mod-scripts.bb:do_configure. Also we can see make-mod-scripts.bb:do_configure[depends] += "virtual/kernel:do_shared_workdir"12:09
ptsnevesmeaning, that do_shared_workdir done by make-mod-scripts will be erased concurrently by kernel-devsrc.bb:do_install[depends] += "virtual/kernel:do_shared_workdir" as well as kernel-devsrc.bb:do_install[depends] += "virtual/kernel:do:install"12:09
ptsnevesBasically this recipe is broken as is12:09
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 276 seconds)12:09
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto12:10
*** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has joined #yocto12:14
*** argonautx <argonautx!~argonautx@muedsl-82-207-240-130.citykom.de> has quit IRC (Quit: Leaving)12:15
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has quit IRC (Quit: Client closed)12:17
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto12:21
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 246 seconds)12:44
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto12:44
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 246 seconds)12:49
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto12:49
JaMarburton: are there any known corner-cases where export GIT_CONFIG_PARAMETERS isn't enough to keep git happy? e.g. I'm seeing it from scons in iotivity build "fatal: unsafe repository ('git/extlibs/tinycbor/tinycbor' is owned by someone else); CalledProcessError: Command 'git tag -l v0.5.1' returned non-zero exit status 128.12:57
JaMamaybe because SConscript.py has own filtering of shell environment :/12:58
JaMahttps://scons.org/doc/2.4.0/HTML/scons-api/SCons.Script.SConscript%27.DefaultEnvironmentCall-class.html12:59
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has joined #yocto13:04
rburtonJaMa: yeah that would do it13:12
JaMaok, will check that after full-rebuild is finished13:13
rburtonthis patch is madness13:21
rburtonit could just not run stuff13:21
LetoThe2ndrün stüff?13:25
LetoThe2ndrburton: https://youtu.be/Kvqr366Op3k13:25
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has joined #yocto13:27
*** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has quit IRC (Ping timeout: 252 seconds)13:27
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto13:28
sotaoverrideHow would I get started on somethng like backporting rootfs overlay stuff from kirkstone to dunfell?13:45
sotaoverridejust need the broadstrokes for now / thoughts now13:46
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has joined #yocto13:46
sotaoverridetalking about back porting overlayfs.bbclass from kirkstone to dunfell13:50
*** camus <camus!~Instantbi@183.192.143.145> has quit IRC (Ping timeout: 240 seconds)13:51
*** otavio_ <otavio_!~otavio@201-3-135-79.paemt705.dsl.brasiltelecom.net.br> has joined #yocto13:53
*** otavio <otavio!~otavio@201-3-135-79.paemt705.dsl.brasiltelecom.net.br> has quit IRC (Read error: Connection reset by peer)13:53
*** Circuitsoft <Circuitsoft!uid393878@id-393878.lymington.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)13:54
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto13:56
LetoThe2ndsotaoverride: cp, start build and see what fails.13:59
sotaoverridegot it. Thanks14:00
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds)14:03
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto14:04
ptsnevesCouldnt make-mod-scripts use inherit nopackages?14:04
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 276 seconds)14:09
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto14:09
rburtonLetoThe2nd: i know better than to click on your links14:12
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)14:13
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 276 seconds)14:17
*** Piraty <Piraty!~irc@user/piraty> has left #yocto (-)14:18
kranzoI'm porting some stuff from dunfell to kirkstone, can someeone explain me:14:19
kranzoFetcher failure: Recipe uses a floating tag/branch without a fixed SRCREV14:19
kranzoI'm using git fetcher and have set branch=fixedname and tag=Bla_${PV}14:19
rburtonthe SRCREV should be a sha, not a name14:20
rburtontag names are not fixed14:20
rburtona sha is fixed, everything else can change14:20
kranzotrue but in dunfell this was working. is sha enforced now? and how to work around this? is there something in place to receive the sha from the tag?14:22
kranzook that would break the whole idea i think ..14:23
rburtonyes14:24
rburtonits a change in kirkstone14:24
LetoThe2ndrburton: booooooring not clicking my links.14:24
JaMaand you can write a function which confirms that the sha mathes with the tag (or at least does in your local checkout) after bitbake fetches from sha, that's what we're using in webOS14:25
sotaoverrideok why dont i see the kirkstone branch on here https://github.com/yoctoproject/poky ?14:25
JaMaUpdated on Mar 2414:26
JaMaI don't think this is official mirror ^14:26
LetoThe2ndsotaoverride: https://git.yoctoproject.org/poky/log/?h=kirkstone14:26
sotaoverrideand for fsoverlay.bbclass what branch would it make the most sense to be backporting from even. (im trying to get it into dunfell)14:26
*** pbergin <pbergin!~pbergin@83.218.73.98> has quit IRC (Quit: Leaving)14:30
kranzoi see, is this correlated to the nonetwork stuff?14:30
kranzohttps://docs.yoctoproject.org/bitbake/2.0/bitbake-user-manual/bitbake-user-manual-fetching.html#git-fetcher-git seems outdated then if i cant use a tag and a ref is forced or do i misunderstand it?14:30
qschulzkranzo: are you passing both branch and tag to SRC_URI?14:32
qschulzalso, tags aren't recommended in SRC_URI because they can be moved so aren't guaranteeing reproducibility14:32
kranzoright now, yes14:32
kranzoi totally agree, I'm still complaining about this but it's not fully under my control by now14:33
kranzocreating tags and changing versionnumbers on recipes seems to be easier :)14:34
qschulzkranzo: https://git.openembedded.org/bitbake/commit/?id=4b5eed1626709ef3dc06b32fd55d40a2a6edd17914:37
qschulzthis seems to indicate it is not possible anymore to use tags/branches without SRCREV14:37
qschulzWould need confirmation from RP but that's mny understanding. We should therefore update the docs to reflect that14:38
qschulzkranzo: wondering if you couldn't use AUTOREV with the tag then14:41
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving)14:42
kranzoI'm scanning every variable right now to check how to make it work, but my brain just creates loops in what chain i can use this :D14:43
RPqschulz: I don't think we intended to stop tags working14:47
RPkranzo: you probably need to trigger the get_autorev() call somehow, then things will work again14:49
kranzoRP: that gives me some hope, that i don't need to fight about tag usage:D   any startingpoint to this ?14:53
RPkranzo: how are you setting PV in these recipes?14:55
RPkranzo: something like SOMEVAR := "${@bb.fetch2.get_srcrev(d)}" in the recipe will probably make it work but it does mean your PV isn't triggering that14:57
kranzoRP: inherited from the recipename14:57
RPkranzo: that will be the issue14:57
RPzeddii, jonmason: For this qemuarm thing, I had a look at the defconfig, CONFIG_PCIEPORTBUS changes as does CONFIG_PCIE_PME and CONFIG_HOTPLUG_PCI, CONFIG_PCI_HOST_COMMON, CONFIG_PCI_HOST_GENERIC. I suspect one of these is the cause of the issue14:58
RPzeddii: rather than revert, we might be able to add the missing bit back?14:59
zeddiiRP jonmason said he located the option, but I haven't gotten the patch yet. hopefully he pops up soon.14:59
* zeddii is fighting with strace15:00
RPzeddii: did you get it to reproduce?15:00
* zeddii has NFI what a landlock is.15:00
zeddiiyah, I've been installing the strace-ptest package on all my images for a while, since it has caused issues int he past.15:00
*** adrian__ <adrian__!~F_Adrian@62.32.0.69> has joined #yocto15:01
jonmasonIs this the fbdev thing?15:01
kranzoRP: sadly even if i change to PV="'1.2.3" SRC_URI unchanged the error is raised15:01
zeddiiI ran it manually and landlock and a couple of others failed. I'm looking at the first one now. maybe the other ones will follow.15:01
zeddiijonmason: yah, the sato qemuarm boot. I think you said you had it working locally.15:01
RPzeddii: I think we just have two landlock failures which are the issue15:01
jonmasonzeddii: +CONFIG_DRM_VKMS=y15:01
RPkranzo: try adding SRCPV in there15:01
RPjonmason: I'm not convinced at that :/15:02
jonmasonI've been reworking my gitlab CI stuff to not suck, and got pulled into a hole of getting it to now suck15:02
RPan unfortunate typo15:03
jonmasonRP: yeah, it does seem dodgy but does fix it15:03
jonmasonRP: lol, more accurate though15:03
RPjonmason: fix with your patch series or fix without your patch series15:03
RPjonmason: I'm worried we'll end up porting this bug into kirkstone15:03
*** adrian_ <adrian_!~F_Adrian@165.225.27.3> has quit IRC (Ping timeout: 272 seconds)15:03
kranzoRP: so PV = "${SRCPV}"15:04
kranzoresults into a single line:15:04
kranzoERROR: Parsing halted due to errors, see error messages above15:04
kranzowithout any error message above oO15:04
jonmasonRP: thats why I'm trying to determine, because I layered the defconfig change with the machine conf change15:04
jonmasontogether they work15:04
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)15:06
*** adrian_ <adrian_!~F_Adrian@165.225.27.11> has joined #yocto15:07
jonmasonzeddii: your changes are in your poky-contrib?15:08
zeddiiyup.15:08
zeddiizedd/kernel15:08
jonmasonok, let me run with that instead of adding your SHA changes by hand15:09
RPjonmason: also in master-next atm15:09
jonmasonis the issue qemuarm and qemuarmv5 not having a bsp definition?15:09
*** adrian__ <adrian__!~F_Adrian@62.32.0.69> has quit IRC (Ping timeout: 246 seconds)15:09
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has quit IRC (Quit: Client closed)15:10
jonmason"Could not locate BSP definition for qemuarm/standard and no defconfig was provided" is what I'm seeing15:10
jonmasonof course, the odds are good I screwed something up :)15:11
zeddiijonmason: not in this case, they build fine here.15:12
jonmasonok, let me do it by hand, off of master-next15:13
RPjonmason: I dumped a defconfig before and after your changes. Did you intend to turn off the pci bits?15:14
* RP is trying to get to a local build position where he could test something15:15
jonmasonRP: I had qemuarm working without PCI, since all of the virtio was -device15:15
fray"local build position".. I assume that isn't standing on your head with a keyboard ont he ceiling?15:16
jonmasonbut I have a patch queued to just use PCI, since all the rest are using PCI and its common15:16
RPjonmason: right, but that will break kirkstone if we backport the kernel change15:16
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has joined #yocto15:16
jonmasonand IIRC removing PCI graphics caused the xorg test to fail on sato15:16
kranzoRP: ok -D flag showed me another problem here, so i would say for now the tag stuff is done solved15:17
kranzo[17:16:22] <kranzo> thx all have a nice weekend15:17
kranzo[17:16:28] [NOTICE] Last login from: ~kranzo@http-v.fe.bosch.de on Apr 29 15:10:09 2022 +0000.15:17
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has quit IRC (Client Quit)15:17
*** kovalevsky <kovalevsky!~kovalevsk@fedora/kovalevsky> has quit IRC (Quit: Leaving)15:23
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 276 seconds)15:24
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto15:24
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has quit IRC (Quit: Client closed)15:27
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 256 seconds)15:29
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto15:29
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto15:31
*** GLumen_ <GLumen_!~Gregory@97-113-69-197.tukw.qwest.net> has joined #yocto15:32
*** amitk <amitk!~amit@103.59.74.42> has quit IRC (Quit: leaving)15:34
*** GLumen <GLumen!~Gregory@97-113-69-197.tukw.qwest.net> has joined #yocto15:34
*** GLumen_ <GLumen_!~Gregory@97-113-69-197.tukw.qwest.net> has quit IRC (Ping timeout: 246 seconds)15:36
*** adrian_ <adrian_!~F_Adrian@165.225.27.11> has quit IRC (Ping timeout: 256 seconds)15:37
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)15:38
lrusak[m]Hey guys, can I make the IMAGE_FSTYPE conditional to a recipe? If I build my image directly I want to use wic.xz but if I build my rauc bundle (which builds my image recipe) I want to use tar.xz15:40
RPjonmason, zeddii: I've confirmed that if I add back those PCI options, qemuarm works again without the virtio changes15:41
RPdoes it help if I try and figure out the ones that we really actually need?15:42
shoragan[m]lrusak: you can have multiple entries in IMAGE_FSTYPE. also, for the rauc bundle, you probably want to use a tar, as the rauc bundle itself is already compressed15:43
zeddiiRP: from my side, not so much, jon was trying to get something minimal, so he may have a stronger opinion.15:45
jonmasonRP: this is the defconfig?15:45
jonmasonadd them back, and I do another to fix it afterward15:45
jonmasonI'm working to repro now, base passes and sato is taking a bit of time15:47
RPjonmason, zeddii: https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=1054f014a3c96f69456ba0000e032382fc7de0ec is what I did to brute force it to test15:47
jonmasonRP: yeah, that actually should get added to virtio.cfg15:50
jonmasonbut seems sane15:50
RPjonmason: I'm assuming you/zeddii know the correct place to put it15:51
jonmasonRP: yes, I'll do a follow on with better testing this time15:51
zeddiiyah. I can always drop it in, but I'm not set up to test it easily, my poor builder is chugging on strace right now.15:52
jonmasonI've expanded my setup recently and I'm actually testing all the various kernels15:53
jonmasonjust wasn't doing graphics/sato15:53
*** argonautx <argonautx!~argonautx@muedsl-82-207-240-130.citykom.de> has joined #yocto15:53
jonmasonwhich blows up on other stuff, like beaglebone-yocto and generic-x8615:53
*** F_Adrian <F_Adrian!~F_Adrian@62.32.0.69> has joined #yocto15:56
zeddiiI'll update the fragments here, my 2nd builder is quite slow, so it'll be a bit before I can do a test, but it can sit with me and I'll sned a patch that goes on top of the series I sent yesterday16:02
RPzeddii, jonmason: confirmed we just need the CONFIG_PCI_HOST_COMMON, CONFIG_PCI_HOST_GENERIC16:02
zeddiiack'd. making the change now.16:06
lrusak[m]shoragan: yep I’m aware, I would have just liked to separate the steps for our CI16:06
RPlrusak[m]: IMAGE_FSTYPE:pn-<recipe> would probably work16:09
RPjonmason: I also confirmed CONFIG_DRM_VKMS=y alone is not enough to get virtio graphics working16:11
*** mckoan is now known as mckoan|away16:24
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has joined #yocto16:29
jonmasonRP: that's for the fbdev issue16:31
jonmasonI'll work off of master next and get it working16:32
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving)16:32
RPjonmason: ah, ok.16:32
*** gsalazar <gsalazar!~gsalazar@213.58.201.38> has quit IRC (Ping timeout: 276 seconds)16:37
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection)16:45
*** amahnui1 <amahnui1!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)17:04
*** amahnui1 <amahnui1!uid502939@id-502939.tinside.irccloud.com> has joined #yocto17:15
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:cb1f:d54d:81af:4127> has quit IRC (Remote host closed the connection)17:23
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:c81b:96bb:de6c:1e82> has joined #yocto17:23
jonmasonRP: i think you need to drop e2d8c1dfbef93b1305cac58f43562ccff730df0d (qemuarm: use virtio device interface for graphics) from master-next17:29
jonmasonthat was causing problems for me for the past few weeks17:29
jonmason(from oe-core master-next)17:31
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto17:44
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has quit IRC (Quit: Client closed)18:05
RPjonmason: I plan to, yes. Was just there in case it helped18:06
RPjonmason: dropped :)18:07
jonmasonno, it makes things worse18:07
RPjonmason: I did test the PCI change without that FWIW18:08
jonmasona few weeks ago, i was messing with it and the graphics device was never found unless it was pci18:09
jonmasonnever caught it because I wasn't doing sato18:09
RPjonmason: Glad you can reproduce it now at least :)18:10
jonmasonright now, I'm only needing "qemuarmv5: use arm-versatile-926ejs KMACHINE and add more virtio devices" patch and normal kernel is working for qemuarm, qemuarmv5, and qemuarm6418:11
RPjonmason: sounds good. I did just drop that one again too as I thought it might have the same graphics issue18:12
jonmasonthe dev-kernel is expected to work, right?18:13
RPjonmason: I'd think so but we don't test on the autobuilder18:17
jonmasonit wasn't for some of the machines, and just wondering if it was my changes or not18:25
*** argonautx <argonautx!~argonautx@muedsl-82-207-240-130.citykom.de> has quit IRC (Quit: Leaving)18:35
*** turkeykittin <turkeykittin!~turkeykit@c-73-231-202-96.hsd1.ca.comcast.net> has joined #yocto18:57
*** m_jimmer12345 <m_jimmer12345!~m_jimmer1@66.186.100.194> has joined #yocto19:01
m_jimmer12345Does anyone know of a bitbake command to clean all recipes that are in a image ?19:05
m_jimmer12345I tried19:06
m_jimmer12345bitbake -g IMAGE_NAME && cat task-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sed "s|\.do_*.*$||g" | sed "s/*}/:/g" | sed "s/.*://" | sed "s|\"||g"| sort | uniq19:06
m_jimmer12345it does not remove the "everything" before }19:06
m_jimmer12345export t=$(bitbake -g MY_IMAGE && cat task-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sed "s|\.do_*.*$||g" | uniq | sort | sed "s|\"||g" )19:24
m_jimmer12345bitbake -c clean $(echo $t | sed "s/.*}//g")19:24
m_jimmer12345there we bo19:24
m_jimmer12345go *19:24
*** florian_kc <florian_kc!~florian@dynamic-093-132-188-013.93.132.pool.telefonica.de> has joined #yocto19:30
rfs613m_jimmer12345: might be simpler to just delete tmp directory?19:31
m_jimmer12345No because there is so many other things to consider\19:31
m_jimmer12345My deploy and sstate and stamps are not in the tmp19:32
m_jimmer12345this the kinda the issue19:32
rfs613afaik do_clean will not clean sstate, and it also doesn't clean downloads19:32
m_jimmer12345If they where It would kill alll 20+ machines in the cache or dep;loy ect19:32
rfs613there is do_cleansstate though19:32
m_jimmer12345yeah that is do_cleanall right ? \19:32
rfs613cleanall should do it yeah19:33
m_jimmer12345we really just want to run do_clean becuase there are license isssues19:33
rfs613still doesn't clean downloads, in case you want to check you can still fetch sources19:33
m_jimmer12345example19:34
m_jimmer12345ERROR: packagegroup-core-boot-1.0-r17 do_populate_lic: The recipe packagegroup-core-boot is trying to install files into a shared area when those files already exist. Those files and their manifest location are:19:34
m_jimmer12345example  build fails once then I run again ^^19:35
rfs613m_jimmer12345: that's above my pay grade :P19:35
m_jimmer12345DEPLOY_DIR        = "/srv/XXX-oe/deploy/${XXX_XXX_XXX}/${XX_XXX}/${MACHINE}"19:35
m_jimmer12345DEPLOY_DIR_IMAGE  = "${DEPLOY_DIR}/image"19:35
m_jimmer12345LICENSE_DIRECTORY = "${DEPLOY_DIR}/license"19:35
m_jimmer12345DEPLOY_DIR_DEB    = "${DEPLOY_DIR}/deb"19:35
m_jimmer12345DEPLOY_DIR_IPK    = "${DEPLOY_DIR}/ipk"19:35
m_jimmer12345DEPLOY_DIR_RPM    = "${DEPLOY_DIR}/rpm"19:35
neverpanicyou should be able to get rid of this by wiping tmp, unless they are systematic issues, in which case they will happen again on the next build.19:35
m_jimmer12345right so the fact that DEPLOY_DIR is nto in tmp  and if I19:37
m_jimmer12345ls /srv/XXX-oe/19:37
m_jimmer12345deploy  downloads  sstate-cache  stamp19:37
m_jimmer12345build dir and tmp dir's(mc) are in like /home/whatever/somebuild19:37
m_jimmer12345if I remove tmp sstate and stamps(this really) freaks out. But If I remove stamps .....19:39
m_jimmer12345if I remove the license dir that it is saying I am installing to something that is alreay there. I have to rebuild the bsp(kernel, uboot/redboot at91bootstrap loader) layers (clean -> build) and the image will make it19:40
m_jimmer12345so I figure if I loop each of the deps of the image and tell it to clean the thing. Will that clean the /deploy/license dir ?19:41
neverpanicYour setup it weird. Sounds a lot like self-inflicted damage to me.19:41
m_jimmer12345Setup is here. its public19:41
m_jimmer12345http://git.emacinc.com/OE/emac-oe/-/blob/dunfell-next/.gitlab-ci.yml19:41
neverpanicJust set DEPLOY_DIR = "${TMPDIR}/deploy" for now while keeping SSTATE_DIR and DL_DIR and build again and it should pass.19:42
m_jimmer12345what is the advantage of having the deploy there ?19:43
m_jimmer12345it will not do the license deal ?19:43
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)19:46
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto19:48
neverpanicthe error message is triggered in sstate.bbclass in sstate_install. Because it happens in do_populate_lic it's clear that it happens when restoring the license.bbclass sstate cache, which according to https://git.yoctoproject.org/poky/tree/meta/classes/license.bbclass#n411 deploys from ${LICSSTATEDIR} to ${LICENSE_DIRECTORY}19:48
neverpanicLICENSE_DIRECTORY is "${DEPLOY_DIR}/licenses"19:48
m_jimmer12345Ok thanks for looking into that19:49
neverpanicYour DEPLOY_DIR/licenses contains a file that your sstate restore wants to write19:49
neverpanicHence, if you start with an empty DEPLOY_DIR, this can't happen.19:49
m_jimmer12345but I would figure that the sstate would know that it already did such a task19:49
m_jimmer12345or that stamps would. Is this not true ?19:49
neverpanicApparently it decided that the task needs re-running for packagegroup-core-boot. Figuring out why is a longer journey.19:50
m_jimmer12345yeah I kinda went down that rabbit hole the other night.19:51
m_jimmer12345neverpanic  thanks for all your nice words and help.  I have changed everything back tpo tmp.  But will this kill my other builds sstate ?19:52
m_jimmer12345like if my other (12) boards have the sstate and it thinks that the deploy dir is .... and that the package groups are located X would that not break the cache ?19:53
m_jimmer12345sorry for all the questions just really dont want to lose that cache unless I do it over the weekend on the ci/cd. I am sure that you understand why19:54
neverpanicsstate is independent of tmp, why would it will your sstate?19:56
neverpanicI don't think the path of DEPLOY_DIR should affect sstate – if the value of $DEPLOY_DIR ends up in the contents of your sstate cache, wouldn't that be a bug anyway?19:57
m_jimmer12345I did not know if sstate was or was not. I just figured that it used the packages(in deploy dir) to set the scene20:00
m_jimmer12345but I guess you are saying it does not. Ill give it a test run20:01
m_jimmer12345does stamps dir want to know where the deploy if ?  Should that also be in tmp. We have a large number of devices that are the same really minus the bsp layers as I am sure you all do as well20:06
m_jimmer12345deploy is*20:06
turkeykittinIn an attempt to upgrade cmake in my yocto, I found a poor mans way of forcing cmake 3.16.5 to cmake 3.18.2 by changing the cmake bb file versions (and checksums). Seems like everything rebuilt fine (albeit with some warnings) but my populated SDK (after install) still maintains cmake 3.16.5. Do I have to manually wipe and rebuild the whole SDK20:18
turkeykittinafter changing this?20:18
m_jimmer12345PREFERRED_VERSION_cmake = "VERSION"20:22
m_jimmer12345I think that is what you are after20:22
turkeykittinwhere would I include PREFERRED_VERSION_cmake?20:22
m_jimmer12345save for native sdk20:23
m_jimmer12345I put mine in the distro but you can add to local.conf20:23
turkeykittinAlrighty, thank you! I'll try this out20:23
m_jimmer12345make sure yo do the same for native as well20:24
m_jimmer12345you *20:25
turkeykittinwould the hyphen convert to underscore? i.e. PREFERRED_VERSION_cmake_native20:25
m_jimmer12345* nativesdk-cmake20:25
turkeykittinah thanks20:25
m_jimmer12345depends on your version of poky or oe20:25
m_jimmer12345and no its not like that20:26
m_jimmer12345very very confusing20:26
turkeykittinwhere would you find the used notation?20:26
m_jimmer12345Example all things like :append and file: but not the  PREFERRED_VERSION or  PREFERRED_PROVIDER20:27
m_jimmer12345PREFERRED_VERSION_nativesdk-cmake = "whtaever"20:28
m_jimmer12345not20:28
m_jimmer12345PREFERRED_VERSION:nativesdk-cmake20:28
turkeykittingot it, thank you! What indicates that it should be "nativesdk-cmake" as opposed to what I have in my current yocto/poky configuration as "cmake-native_3.16.5"? Is it just something that changed over versions? (I'm a bit behind, still on Dunfell)20:29
turkeykittin(obviously ignoring version)20:29
turkeykittinspecifically nativesdk-cmake vs cmake-native20:30
m_jimmer12345native is your host native-sdk could mean cross compiled for say things like qt or cmake or your toolchain20:33
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)20:34
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has quit IRC (Ping timeout: 276 seconds)20:35
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has joined #yocto20:35
turkeykittinah I see it now, I had assumed it was a version difference but yeah I see it in my current version, a higher level dependency20:35
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Ping timeout: 276 seconds)20:36
m_jimmer12345neverpanic same error:(20:37
m_jimmer12345LICSSTATEDIR seems to be read only:(20:41
neverpanicm_jimmer12345: sounds like you have two sstate tasks that attempt to setscene the same file20:45
m_jimmer12345maybe Ill look20:45
m_jimmer12345I think we found it .....20:50
m_jimmer12345legacy stuff20:50
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 250 seconds)20:52
*** amahnui1 <amahnui1!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)20:54
m_jimmer12345false alarm no extra calls to sstate or anything:(20:55
m_jimmer12345I am thinking that LICSSTATEDIR is show getting currrupted20:56
m_jimmer12345Ok so from sstate.bb I see that we have a hardcoded value of21:01
m_jimmer12345SSTATE_DUPWHITELIST = "${DEPLOY_DIR}/licenses/"21:01
m_jimmer12345but my license is21:01
m_jimmer12345LICENSE_DIRECTORY = "${DEPLOY_DIR}/license"21:01
m_jimmer12345license vs licenses   dunfell for what it is worth21:03
m_jimmer12345maybe should just be    SSTATE_DUPWHITELIST ?= "${LICENSE_DIRECTORY}"21:03
m_jimmer12345that way we can overwrite if need be ?21:04
m_jimmer12345https://git.yoctoproject.org/poky/tree/meta/classes/sstate.bbclass?h=dunfell#n5121:05
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 246 seconds)21:09
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto21:09
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 272 seconds)21:14
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto21:14
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto21:17
turkeykittinSo ever since I made the cmake change with preferred cmake (as well as added TOOLCHAIN_HOST_TASK += "nativesdk-cmake" to my conf), Ive encountered an issue when installing the sdk21:57
turkeykittinthe SDK extracts fine but hangs trying to set up the environment: "Setting it up...ls: cannot access '/opt/fslc-xwayland/3.1/environment-setup-*': No such file or directory"21:57
turkeykittinI don't know why suddenly it would no longer generate an environment setup script?21:58
m_jimmer12345what was your command is it a meta script or just stright up do_populate-sdk ?21:59
turkeykittinjust bitbake myimage -c populate_sdk21:59
turkeykittinI suppose I could do it for the core (my image is more or less a very slightly modified core) but I dont understand why it worked before and suddenly the change regarding cmake would break it22:00
turkeykittinI _did_ delete the /opt/fslc-xwayland/3.1 directory for a fresh install, but I don't believe it existed prior to populating the sdk. My only concern would be that it may have existed and been pulling from it prior. Not sure what other commands I could have used would have generated it though...22:01
turkeykittinHavent touched the SDK until today.22:01
m_jimmer12345Im not sure TBH. Are you doing anything with SDK_DEPLOY_DIR or anything like that ?22:02
turkeykittinNope22:02
turkeykittinJust using defaults22:02
m_jimmer12345have you tried to re-generate it ?22:03
m_jimmer12345can you show your local.conf in a paste bin ?22:03
turkeykittinLike run bitbake myimage -c populate_sdk after deleting the directory? Or the image itself? I've regenerated the image (without a clean, just a rebuild) in an attempt to fix, but wanted to hold off on regenerating the whole image due to how long it takes on my host :X22:05
turkeykittinYeah I can include that, one second22:05
turkeykittinhttps://pastebin.com/sYted3SP22:07
turkeykittinGoing to try it without the task...22:13
m_jimmer12345what version are you on ? dunfell ?22:14
turkeykittinYeah22:14
m_jimmer12345so can you run the following22:14
m_jimmer12345bitbake -e IMAGE_NAME | grep ^TOOLCHAIN22:15
m_jimmer12345please change imagename to your image22:15
turkeykittinpc go brrrr trying to do this in parallel with a do_populate_sdk22:17
m_jimmer12345ahh just wait. You could set your threads in your local.conf pretty sure nproc with out22:18
turkeykittinI'm not sure what you mean by set my threads in local.conf?22:19
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 276 seconds)22:19
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto22:19
m_jimmer12345## Set these when building locally22:19
m_jimmer12345BB_NUMBER_THREADS ?= "X"22:19
m_jimmer12345PARALLEL_MAKE ?= "-j X"22:19
m_jimmer12345Where X is the number's22:19
turkeykittinoh that's beautiful22:19
*** florian_kc <florian_kc!~florian@dynamic-093-132-188-013.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 276 seconds)22:20
m_jimmer12345I'm pretty sure that it defaults to nproc22:20
m_jimmer12345but its been a bit sense I looked at that code22:20
turkeykittinhmmm22:20
turkeykittinyeah actually I think I recall seeing it already at 822:20
turkeykittinerm actually that may have been just errors from me building with cmake earlier...22:20
turkeykittindoes bitbake use ninja to build? If not then it was unrelated. Otherwise ninja was for sure using my nproc22:21
m_jimmer12345depends22:21
m_jimmer12345see generator at https://git.yoctoproject.org/poky/tree/meta/classes/cmake.bbclass?h=kirkstone#n1722:24
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has quit IRC (Remote host closed the connection)22:24
m_jimmer12345so OECMAKE_GENERATOR="Ninja"22:24
m_jimmer12345would use ninja but the other is unix make files. Look likes there is not support for Watcom or green hills22:26
m_jimmer12345maybe i missed it22:26
turkeykittinAh good to know! So it's using 8 already then (from memory of seeing ninja -j 8 or something similar in a recent error)22:26
turkeykittinInteresting, removing the toolchain host task fixed the environment issue22:28
turkeykittinYES22:29
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 276 seconds)22:29
turkeykittincmake --version prints out 3.18.2. Greatly appreciated m_jimmer1234522:29
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto22:29
m_jimmer12345good job !:)22:29
turkeykittinThe preferred version was a life saver. That was what was missing22:30
turkeykittinand then me inserting legacy code that I didnt know would work or not after I realized I had inserted it into bblayers instead of local.conf...22:30
turkeykittinDon't try to fix multiple things at once! :X  You'll only break it more! haha22:31
turkeykittinFor anyone curious, TOOLCHAIN_HOST_TASK += "nativesdk-cmake" in local.conf seems to make bitbake unhappy when populating the sdk22:31
turkeykittinpopulating/installing*22:32
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has joined #yocto22:33
kergothturkeykittin: beware of direct operations with variables used by recipes/classes, if the recipe/class sets its value with ?=, your += will result in that value not being applied, and only nativesdk-cmake will be listed, instead of adding to the existing value as would be the case with :append/_append. i'd examine bitbake -e yoursdkrecipe | grep TOOLCHAIN_HOST_TASK= with and without that addition22:35
turkeykittinWill check that out, thank you kergoth !22:36
turkeykittinInteresting, it's having a hard time finding python when I'm sourcing and trying to manually cmake some cpp to python bindings... sounds like an issue for another time though. Gotta head out for an hour or two :\22:40
turkeykittinThank you for all the help! Hope you track down the root of your issue m_jimmer12345! Unfortunately it's way over my head :(22:40
m_jimmer12345thank you for the nice words. We found the root issue and are testing22:52
m_jimmer12345gotta build close to 40 + machines and all with multi images.  Let alone the multiconfig emulators that we do.22:53
*** dev1990 <dev1990!~dev@77-255-244-179.adsl.inetia.pl> has quit IRC (Quit: Konversation terminated!)23:00
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has quit IRC (Quit: Client closed)23:31
*** GLumen <GLumen!~Gregory@97-113-69-197.tukw.qwest.net> has quit IRC (Ping timeout: 248 seconds)23:44

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!