*** 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 #yocto | 00: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 #yocto | 01: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 #yocto | 01: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 #yocto | 02: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 #yocto | 02:25 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02: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 #yocto | 03: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 #yocto | 03:34 | |
*** amitk <amitk!~amit@103.59.74.42> has joined #yocto | 03:46 | |
*** tlwoerner_ <tlwoerner_!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 04:22 | |
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 04: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 #yocto | 04: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 #yocto | 04: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 #yocto | 04:44 | |
*** thomasd13 <thomasd13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:14 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:25 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 05:33 | |
thomasd13 | Good morning guys | 05: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 #yocto | 05:58 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06: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 #yocto | 06: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 #yocto | 06: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 #yocto | 06:26 | |
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto | 06:31 | |
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer) | 06:38 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 06:39 | |
*** mckoan|away is now known as mckoan | 06:40 | |
khem | https://www.phoronix.com/scan.php?page=news_item&px=Yocto-4.0-Released | 06:44 |
*** amahnui1 <amahnui1!uid502939@id-502939.tinside.irccloud.com> has joined #yocto | 06:46 | |
LetoThe2nd | yo dudX | 06:53 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:01 | |
mckoan | good morning | 07:03 |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 07:08 | |
*** pbergin <pbergin!~pbergin@83.218.73.98> has joined #yocto | 07:09 | |
*** hcg <hcg!~hcg@185.210.97.85> has joined #yocto | 07: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 #yocto | 07:14 | |
*** gsalazar <gsalazar!~gsalazar@213.58.201.38> has joined #yocto | 07: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 #yocto | 07:54 | |
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has joined #yocto | 07:59 | |
*** mkorpershoek <mkorpershoek!sid537056@id-537056.uxbridge.irccloud.com> has joined #yocto | 08: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 #yocto | 08:15 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 246 seconds) | 08:19 | |
kanavin | manuel1985, 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 #yocto | 08: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 #yocto | 08:30 | |
*** ilunev <ilunev!~koolkhel@95.174.114.26> has joined #yocto | 08: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 #yocto | 08: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 |
kranzo | kayterina[m]: if its not in the default directories inherited from cmake/autotools etc you need to add it, so it will be packed | 08:49 |
kayterina[m] | hm, where are the default directories from cmake? I also do not compile anithing, so I don't explicitely inherit cmake | 08:51 |
kranzo | otherwise it will trigger: installed-vs-shipped | 08:51 |
kranzo | https://docs.yoctoproject.org/ref-manual/classes.html?highlight=insane#insane-bbclass | 08:51 |
kranzo | then FILES:${PN} += "path/to/your/file" should do the trick | 08:52 |
kranzo | you can check with bitbake -e <recipe> |less and search for FILES_ or FILES: depending on your yocto version | 08: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 #yocto | 09: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 #yocto | 09:19 | |
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has joined #yocto | 09: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 recipe | 09:21 |
kayterina[m] | FILES_${PN} += "${sysconfdir}/my-config/my-global.conf"? | 09:21 |
mnme | Hi 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 |
ptsneves | kayterina[m] if BPN==my-config yes | 09: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 |
ptsneves | kayterina[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 workspace | 09: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 |
ptsneves | ok 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 though | 09: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 |
ptsneves | cargo 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_cult | 09:41 |
thomasd13 | Lol - Its such a satisfying feeling, when a yocto build keeps all the 24 cores at 100% for hours | 09:44 |
kranzo | ptsneves: i love learning new descriptions of behaviour i've seen before :D | 09:44 |
thomasd13 | work harder server. WORK HARDER! | 09:45 |
kayterina[m] | haha,nice. | 09:45 |
ptsneves | oh it seems that wikipedia even has a cargo cult disambiguation for programming https://en.wikipedia.org/wiki/Cargo_cult_programming | 09: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 #yocto | 10:01 | |
*** argonautx <argonautx!~argonautx@muedsl-82-207-240-130.citykom.de> has joined #yocto | 10:03 | |
LetoThe2nd | in 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 |
qschulz | LetoThe2nd: U-Boot might not be running on the RPi | 10:14 |
LetoThe2nd | qschulz: it certainly is, I get the messages on the serial. | 10:15 |
ptsneves | https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/bootfiles/rpi-bootfiles.bb | 10:17 |
ptsneves | And yes it uses uboot | 10:17 |
LetoThe2nd | ptsneves: yeah but still, where is it? | 10:19 |
ptsneves | in a .bin file? | 10:20 |
agherzan | LetoThe2nd: it uses the recipe in oe-core | 10:20 |
ptsneves | "${DEPLOYDIR}/${BOOTFILES_DIR_NAME}" | 10:20 |
agherzan | for uboot. | 10:20 |
agherzan | What you are pointing at ptsneves is the firmware from rpi which in turn chains the uboot when used | 10:21 |
agherzan | Here is the uboot bbappend https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/u-boot/u-boot_%25.bbappend | 10:21 |
ptsneves | @agherzan. You are right. Even so that bbappend does not modify where the files are deployed. So the oe-core defaults prevail | 10:22 |
agherzan | That would be correct. So what is the question again? | 10:22 |
LetoThe2nd | agherzan: ah I'm getting closer. so the magic is the UBOOT_BINARY variable? | 10:22 |
ptsneves | actually agherzan is the maintainer of the layer *@ptsneves shows itself self out* | 10:22 |
LetoThe2nd | ptsneves: i know :-) | 10:24 |
agherzan | LetoThe2nd: the entire logic is in https://git.yoctoproject.org/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc#n205 | 10:24 |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 10:25 | |
LetoThe2nd | agherzan: okay i'll dig deeper there then. thanks! | 10:25 |
agherzan | the deployment is triggered by https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi4.conf#L19 LetoThe2nd | 10:26 |
agherzan | So 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#n57 | 10:26 |
LetoThe2nd | agherzan: well if I could only buy an rpi4.... *SCNR* | 10:27 |
agherzan | You don't need to buy an rPi to build u-boot | 10:27 |
LetoThe2nd | yeah, thanks! | 10:27 |
agherzan | :) | 10:27 |
LetoThe2nd | nah, referring to you pointing at the rpi4-config. | 10:27 |
ptsneves | LetoThe2nd why? Do you not have >$100 for a $20 piece? | 10:28 |
agherzan | I see LetoThe2nd . The thing is identical for any other machine in meta-raspberrypi | 10:28 |
agherzan | For example here is the conf for rpi3 https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi3.conf#L17 | 10: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 #yocto | 10: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 #yocto | 11:19 | |
*** kovalevsky <kovalevsky!~kovalevsk@fedora/kovalevsky> has joined #yocto | 11: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 #yocto | 11:24 | |
ptsneves | has 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 intended | 11:31 |
ptsneves | i 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 #yocto | 11: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 #yocto | 12: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 | |
ptsneves | Ok regarding the issue with kernel-devsrc i have the following model: | 12:09 |
ptsneves | kernel-devsrc.bb:do_install[depends] += virtual/kernel:do_shared_workdir | 12:09 |
ptsneves | virtual/kernel:do_shared_workdir is a cleandir task for the kernel build dir! | 12:09 |
ptsneves | but 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 |
ptsneves | meaning, 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 |
ptsneves | Basically this recipe is broken as is | 12: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 #yocto | 12:10 | |
*** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has joined #yocto | 12: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 #yocto | 12: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 #yocto | 12: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 #yocto | 12:49 | |
JaMa | rburton: 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 |
JaMa | maybe because SConscript.py has own filtering of shell environment :/ | 12:58 |
JaMa | https://scons.org/doc/2.4.0/HTML/scons-api/SCons.Script.SConscript%27.DefaultEnvironmentCall-class.html | 12:59 |
*** ptsneves <ptsneves!~ptsneves@83.11.63.53.ipv4.supernova.orange.pl> has joined #yocto | 13:04 | |
rburton | JaMa: yeah that would do it | 13:12 |
JaMa | ok, will check that after full-rebuild is finished | 13:13 |
rburton | this patch is madness | 13:21 |
rburton | it could just not run stuff | 13:21 |
LetoThe2nd | rün stüff? | 13:25 |
LetoThe2nd | rburton: https://youtu.be/Kvqr366Op3k | 13:25 |
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has joined #yocto | 13: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 #yocto | 13:28 | |
sotaoverride | How would I get started on somethng like backporting rootfs overlay stuff from kirkstone to dunfell? | 13:45 |
sotaoverride | just need the broadstrokes for now / thoughts now | 13:46 |
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has joined #yocto | 13:46 | |
sotaoverride | talking about back porting overlayfs.bbclass from kirkstone to dunfell | 13: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 #yocto | 13: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 #yocto | 13:56 | |
LetoThe2nd | sotaoverride: cp, start build and see what fails. | 13:59 |
sotaoverride | got it. Thanks | 14: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 #yocto | 14:04 | |
ptsneves | Couldnt 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 #yocto | 14:09 | |
rburton | LetoThe2nd: i know better than to click on your links | 14: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 | |
kranzo | I'm porting some stuff from dunfell to kirkstone, can someeone explain me: | 14:19 |
kranzo | Fetcher failure: Recipe uses a floating tag/branch without a fixed SRCREV | 14:19 |
kranzo | I'm using git fetcher and have set branch=fixedname and tag=Bla_${PV} | 14:19 |
rburton | the SRCREV should be a sha, not a name | 14:20 |
rburton | tag names are not fixed | 14:20 |
rburton | a sha is fixed, everything else can change | 14:20 |
kranzo | true 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 |
kranzo | ok that would break the whole idea i think .. | 14:23 |
rburton | yes | 14:24 |
rburton | its a change in kirkstone | 14:24 |
LetoThe2nd | rburton: booooooring not clicking my links. | 14:24 |
JaMa | and 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 webOS | 14:25 |
sotaoverride | ok why dont i see the kirkstone branch on here https://github.com/yoctoproject/poky ? | 14:25 |
JaMa | Updated on Mar 24 | 14:26 |
JaMa | I don't think this is official mirror ^ | 14:26 |
LetoThe2nd | sotaoverride: https://git.yoctoproject.org/poky/log/?h=kirkstone | 14:26 |
sotaoverride | and 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 | |
kranzo | i see, is this correlated to the nonetwork stuff? | 14:30 |
kranzo | https://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 |
qschulz | kranzo: are you passing both branch and tag to SRC_URI? | 14:32 |
qschulz | also, tags aren't recommended in SRC_URI because they can be moved so aren't guaranteeing reproducibility | 14:32 |
kranzo | right now, yes | 14:32 |
kranzo | i totally agree, I'm still complaining about this but it's not fully under my control by now | 14:33 |
kranzo | creating tags and changing versionnumbers on recipes seems to be easier :) | 14:34 |
qschulz | kranzo: https://git.openembedded.org/bitbake/commit/?id=4b5eed1626709ef3dc06b32fd55d40a2a6edd179 | 14:37 |
qschulz | this seems to indicate it is not possible anymore to use tags/branches without SRCREV | 14:37 |
qschulz | Would need confirmation from RP but that's mny understanding. We should therefore update the docs to reflect that | 14:38 |
qschulz | kranzo: wondering if you couldn't use AUTOREV with the tag then | 14:41 |
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving) | 14:42 | |
kranzo | I'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 :D | 14:43 |
RP | qschulz: I don't think we intended to stop tags working | 14:47 |
RP | kranzo: you probably need to trigger the get_autorev() call somehow, then things will work again | 14:49 |
kranzo | RP: that gives me some hope, that i don't need to fight about tag usage:D any startingpoint to this ? | 14:53 |
RP | kranzo: how are you setting PV in these recipes? | 14:55 |
RP | kranzo: 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 that | 14:57 |
kranzo | RP: inherited from the recipename | 14:57 |
RP | kranzo: that will be the issue | 14:57 |
RP | zeddii, 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 issue | 14:58 |
RP | zeddii: rather than revert, we might be able to add the missing bit back? | 14:59 |
zeddii | RP 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 strace | 15:00 | |
RP | zeddii: did you get it to reproduce? | 15:00 |
* zeddii has NFI what a landlock is. | 15:00 | |
zeddii | yah, 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 #yocto | 15:01 | |
jonmason | Is this the fbdev thing? | 15:01 |
kranzo | RP: sadly even if i change to PV="'1.2.3" SRC_URI unchanged the error is raised | 15:01 |
zeddii | I 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 |
zeddii | jonmason: yah, the sato qemuarm boot. I think you said you had it working locally. | 15:01 |
RP | zeddii: I think we just have two landlock failures which are the issue | 15:01 |
jonmason | zeddii: +CONFIG_DRM_VKMS=y | 15:01 |
RP | kranzo: try adding SRCPV in there | 15:01 |
RP | jonmason: I'm not convinced at that :/ | 15:02 |
jonmason | I've been reworking my gitlab CI stuff to not suck, and got pulled into a hole of getting it to now suck | 15:02 |
RP | an unfortunate typo | 15:03 |
jonmason | RP: yeah, it does seem dodgy but does fix it | 15:03 |
jonmason | RP: lol, more accurate though | 15:03 |
RP | jonmason: fix with your patch series or fix without your patch series | 15:03 |
RP | jonmason: I'm worried we'll end up porting this bug into kirkstone | 15:03 |
*** adrian_ <adrian_!~F_Adrian@165.225.27.3> has quit IRC (Ping timeout: 272 seconds) | 15:03 | |
kranzo | RP: so PV = "${SRCPV}" | 15:04 |
kranzo | results into a single line: | 15:04 |
kranzo | ERROR: Parsing halted due to errors, see error messages above | 15:04 |
kranzo | without any error message above oO | 15:04 |
jonmason | RP: thats why I'm trying to determine, because I layered the defconfig change with the machine conf change | 15:04 |
jonmason | together they work | 15: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 #yocto | 15:07 | |
jonmason | zeddii: your changes are in your poky-contrib? | 15:08 |
zeddii | yup. | 15:08 |
zeddii | zedd/kernel | 15:08 |
jonmason | ok, let me run with that instead of adding your SHA changes by hand | 15:09 |
RP | jonmason: also in master-next atm | 15:09 |
jonmason | is 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 seeing | 15:10 |
jonmason | of course, the odds are good I screwed something up :) | 15:11 |
zeddii | jonmason: not in this case, they build fine here. | 15:12 |
jonmason | ok, let me do it by hand, off of master-next | 15:13 |
RP | jonmason: 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 something | 15:15 | |
jonmason | RP: I had qemuarm working without PCI, since all of the virtio was -device | 15:15 |
fray | "local build position".. I assume that isn't standing on your head with a keyboard ont he ceiling? | 15:16 |
jonmason | but I have a patch queued to just use PCI, since all the rest are using PCI and its common | 15:16 |
RP | jonmason: right, but that will break kirkstone if we backport the kernel change | 15:16 |
*** kranzo <kranzo!~kranzo@http-v.fe.bosch.de> has joined #yocto | 15:16 | |
jonmason | and IIRC removing PCI graphics caused the xorg test to fail on sato | 15:16 |
kranzo | RP: ok -D flag showed me another problem here, so i would say for now the tag stuff is done solved | 15:17 |
kranzo | [17:16:22] <kranzo> thx all have a nice weekend | 15: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 #yocto | 15: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 #yocto | 15:29 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 15:31 | |
*** GLumen_ <GLumen_!~Gregory@97-113-69-197.tukw.qwest.net> has joined #yocto | 15: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 #yocto | 15: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.xz | 15:40 |
RP | jonmason, zeddii: I've confirmed that if I add back those PCI options, qemuarm works again without the virtio changes | 15:41 |
RP | does 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 compressed | 15:43 |
zeddii | RP: from my side, not so much, jon was trying to get something minimal, so he may have a stronger opinion. | 15:45 |
jonmason | RP: this is the defconfig? | 15:45 |
jonmason | add them back, and I do another to fix it afterward | 15:45 |
jonmason | I'm working to repro now, base passes and sato is taking a bit of time | 15:47 |
RP | jonmason, zeddii: https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=1054f014a3c96f69456ba0000e032382fc7de0ec is what I did to brute force it to test | 15:47 |
jonmason | RP: yeah, that actually should get added to virtio.cfg | 15:50 |
jonmason | but seems sane | 15:50 |
RP | jonmason: I'm assuming you/zeddii know the correct place to put it | 15:51 |
jonmason | RP: yes, I'll do a follow on with better testing this time | 15:51 |
zeddii | yah. 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 |
jonmason | I've expanded my setup recently and I'm actually testing all the various kernels | 15:53 |
jonmason | just wasn't doing graphics/sato | 15:53 |
*** argonautx <argonautx!~argonautx@muedsl-82-207-240-130.citykom.de> has joined #yocto | 15:53 | |
jonmason | which blows up on other stuff, like beaglebone-yocto and generic-x86 | 15:53 |
*** F_Adrian <F_Adrian!~F_Adrian@62.32.0.69> has joined #yocto | 15:56 | |
zeddii | I'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 yesterday | 16:02 |
RP | zeddii, jonmason: confirmed we just need the CONFIG_PCI_HOST_COMMON, CONFIG_PCI_HOST_GENERIC | 16:02 |
zeddii | ack'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 CI | 16:06 |
RP | lrusak[m]: IMAGE_FSTYPE:pn-<recipe> would probably work | 16:09 |
RP | jonmason: I also confirmed CONFIG_DRM_VKMS=y alone is not enough to get virtio graphics working | 16:11 |
*** mckoan is now known as mckoan|away | 16:24 | |
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has joined #yocto | 16:29 | |
jonmason | RP: that's for the fbdev issue | 16:31 |
jonmason | I'll work off of master next and get it working | 16:32 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 16:32 | |
RP | jonmason: 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 #yocto | 17: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 #yocto | 17:23 | |
jonmason | RP: i think you need to drop e2d8c1dfbef93b1305cac58f43562ccff730df0d (qemuarm: use virtio device interface for graphics) from master-next | 17:29 |
jonmason | that was causing problems for me for the past few weeks | 17:29 |
jonmason | (from oe-core master-next) | 17:31 |
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 17:44 | |
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has quit IRC (Quit: Client closed) | 18:05 | |
RP | jonmason: I plan to, yes. Was just there in case it helped | 18:06 |
RP | jonmason: dropped :) | 18:07 |
jonmason | no, it makes things worse | 18:07 |
RP | jonmason: I did test the PCI change without that FWIW | 18:08 |
jonmason | a few weeks ago, i was messing with it and the graphics device was never found unless it was pci | 18:09 |
jonmason | never caught it because I wasn't doing sato | 18:09 |
RP | jonmason: Glad you can reproduce it now at least :) | 18:10 |
jonmason | right 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 qemuarm64 | 18:11 |
RP | jonmason: sounds good. I did just drop that one again too as I thought it might have the same graphics issue | 18:12 |
jonmason | the dev-kernel is expected to work, right? | 18:13 |
RP | jonmason: I'd think so but we don't test on the autobuilder | 18:17 |
jonmason | it wasn't for some of the machines, and just wondering if it was my changes or not | 18: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 #yocto | 18:57 | |
*** m_jimmer12345 <m_jimmer12345!~m_jimmer1@66.186.100.194> has joined #yocto | 19:01 | |
m_jimmer12345 | Does anyone know of a bitbake command to clean all recipes that are in a image ? | 19:05 |
m_jimmer12345 | I tried | 19:06 |
m_jimmer12345 | bitbake -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 | uniq | 19:06 |
m_jimmer12345 | it does not remove the "everything" before } | 19:06 |
m_jimmer12345 | export 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_jimmer12345 | bitbake -c clean $(echo $t | sed "s/.*}//g") | 19:24 |
m_jimmer12345 | there we bo | 19:24 |
m_jimmer12345 | go * | 19:24 |
*** florian_kc <florian_kc!~florian@dynamic-093-132-188-013.93.132.pool.telefonica.de> has joined #yocto | 19:30 | |
rfs613 | m_jimmer12345: might be simpler to just delete tmp directory? | 19:31 |
m_jimmer12345 | No because there is so many other things to consider\ | 19:31 |
m_jimmer12345 | My deploy and sstate and stamps are not in the tmp | 19:32 |
m_jimmer12345 | this the kinda the issue | 19:32 |
rfs613 | afaik do_clean will not clean sstate, and it also doesn't clean downloads | 19:32 |
m_jimmer12345 | If they where It would kill alll 20+ machines in the cache or dep;loy ect | 19:32 |
rfs613 | there is do_cleansstate though | 19:32 |
m_jimmer12345 | yeah that is do_cleanall right ? \ | 19:32 |
rfs613 | cleanall should do it yeah | 19:33 |
m_jimmer12345 | we really just want to run do_clean becuase there are license isssues | 19:33 |
rfs613 | still doesn't clean downloads, in case you want to check you can still fetch sources | 19:33 |
m_jimmer12345 | example | 19:34 |
m_jimmer12345 | ERROR: 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_jimmer12345 | example build fails once then I run again ^^ | 19:35 |
rfs613 | m_jimmer12345: that's above my pay grade :P | 19:35 |
m_jimmer12345 | DEPLOY_DIR = "/srv/XXX-oe/deploy/${XXX_XXX_XXX}/${XX_XXX}/${MACHINE}" | 19:35 |
m_jimmer12345 | DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/image" | 19:35 |
m_jimmer12345 | LICENSE_DIRECTORY = "${DEPLOY_DIR}/license" | 19:35 |
m_jimmer12345 | DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb" | 19:35 |
m_jimmer12345 | DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk" | 19:35 |
m_jimmer12345 | DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm" | 19:35 |
neverpanic | you 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_jimmer12345 | right so the fact that DEPLOY_DIR is nto in tmp and if I | 19:37 |
m_jimmer12345 | ls /srv/XXX-oe/ | 19:37 |
m_jimmer12345 | deploy downloads sstate-cache stamp | 19:37 |
m_jimmer12345 | build dir and tmp dir's(mc) are in like /home/whatever/somebuild | 19:37 |
m_jimmer12345 | if I remove tmp sstate and stamps(this really) freaks out. But If I remove stamps ..... | 19:39 |
m_jimmer12345 | if 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 it | 19:40 |
m_jimmer12345 | so 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 |
neverpanic | Your setup it weird. Sounds a lot like self-inflicted damage to me. | 19:41 |
m_jimmer12345 | Setup is here. its public | 19:41 |
m_jimmer12345 | http://git.emacinc.com/OE/emac-oe/-/blob/dunfell-next/.gitlab-ci.yml | 19:41 |
neverpanic | Just set DEPLOY_DIR = "${TMPDIR}/deploy" for now while keeping SSTATE_DIR and DL_DIR and build again and it should pass. | 19:42 |
m_jimmer12345 | what is the advantage of having the deploy there ? | 19:43 |
m_jimmer12345 | it 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 #yocto | 19:48 | |
neverpanic | the 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 |
neverpanic | LICENSE_DIRECTORY is "${DEPLOY_DIR}/licenses" | 19:48 |
m_jimmer12345 | Ok thanks for looking into that | 19:49 |
neverpanic | Your DEPLOY_DIR/licenses contains a file that your sstate restore wants to write | 19:49 |
neverpanic | Hence, if you start with an empty DEPLOY_DIR, this can't happen. | 19:49 |
m_jimmer12345 | but I would figure that the sstate would know that it already did such a task | 19:49 |
m_jimmer12345 | or that stamps would. Is this not true ? | 19:49 |
neverpanic | Apparently it decided that the task needs re-running for packagegroup-core-boot. Figuring out why is a longer journey. | 19:50 |
m_jimmer12345 | yeah I kinda went down that rabbit hole the other night. | 19:51 |
m_jimmer12345 | neverpanic 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_jimmer12345 | like 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_jimmer12345 | sorry 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 why | 19:54 |
neverpanic | sstate is independent of tmp, why would it will your sstate? | 19:56 |
neverpanic | I 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_jimmer12345 | I did not know if sstate was or was not. I just figured that it used the packages(in deploy dir) to set the scene | 20:00 |
m_jimmer12345 | but I guess you are saying it does not. Ill give it a test run | 20:01 |
m_jimmer12345 | does 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 well | 20:06 |
m_jimmer12345 | deploy is* | 20:06 |
turkeykittin | In 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 SDK | 20:18 |
turkeykittin | after changing this? | 20:18 |
m_jimmer12345 | PREFERRED_VERSION_cmake = "VERSION" | 20:22 |
m_jimmer12345 | I think that is what you are after | 20:22 |
turkeykittin | where would I include PREFERRED_VERSION_cmake? | 20:22 |
m_jimmer12345 | save for native sdk | 20:23 |
m_jimmer12345 | I put mine in the distro but you can add to local.conf | 20:23 |
turkeykittin | Alrighty, thank you! I'll try this out | 20:23 |
m_jimmer12345 | make sure yo do the same for native as well | 20:24 |
m_jimmer12345 | you * | 20:25 |
turkeykittin | would the hyphen convert to underscore? i.e. PREFERRED_VERSION_cmake_native | 20:25 |
m_jimmer12345 | * nativesdk-cmake | 20:25 |
turkeykittin | ah thanks | 20:25 |
m_jimmer12345 | depends on your version of poky or oe | 20:25 |
m_jimmer12345 | and no its not like that | 20:26 |
m_jimmer12345 | very very confusing | 20:26 |
turkeykittin | where would you find the used notation? | 20:26 |
m_jimmer12345 | Example all things like :append and file: but not the PREFERRED_VERSION or PREFERRED_PROVIDER | 20:27 |
m_jimmer12345 | PREFERRED_VERSION_nativesdk-cmake = "whtaever" | 20:28 |
m_jimmer12345 | not | 20:28 |
m_jimmer12345 | PREFERRED_VERSION:nativesdk-cmake | 20:28 |
turkeykittin | got 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 |
turkeykittin | specifically nativesdk-cmake vs cmake-native | 20:30 |
m_jimmer12345 | native is your host native-sdk could mean cross compiled for say things like qt or cmake or your toolchain | 20: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 #yocto | 20:35 | |
turkeykittin | ah I see it now, I had assumed it was a version difference but yeah I see it in my current version, a higher level dependency | 20:35 |
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Ping timeout: 276 seconds) | 20:36 | |
m_jimmer12345 | neverpanic same error:( | 20:37 |
m_jimmer12345 | LICSSTATEDIR seems to be read only:( | 20:41 |
neverpanic | m_jimmer12345: sounds like you have two sstate tasks that attempt to setscene the same file | 20:45 |
m_jimmer12345 | maybe Ill look | 20:45 |
m_jimmer12345 | I think we found it ..... | 20:50 |
m_jimmer12345 | legacy stuff | 20: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_jimmer12345 | false alarm no extra calls to sstate or anything:( | 20:55 |
m_jimmer12345 | I am thinking that LICSSTATEDIR is show getting currrupted | 20:56 |
m_jimmer12345 | Ok so from sstate.bb I see that we have a hardcoded value of | 21:01 |
m_jimmer12345 | SSTATE_DUPWHITELIST = "${DEPLOY_DIR}/licenses/" | 21:01 |
m_jimmer12345 | but my license is | 21:01 |
m_jimmer12345 | LICENSE_DIRECTORY = "${DEPLOY_DIR}/license" | 21:01 |
m_jimmer12345 | license vs licenses dunfell for what it is worth | 21:03 |
m_jimmer12345 | maybe should just be SSTATE_DUPWHITELIST ?= "${LICENSE_DIRECTORY}" | 21:03 |
m_jimmer12345 | that way we can overwrite if need be ? | 21:04 |
m_jimmer12345 | https://git.yoctoproject.org/poky/tree/meta/classes/sstate.bbclass?h=dunfell#n51 | 21: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 #yocto | 21: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 #yocto | 21:14 | |
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 21:17 | |
turkeykittin | So 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 sdk | 21:57 |
turkeykittin | the 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 |
turkeykittin | I don't know why suddenly it would no longer generate an environment setup script? | 21:58 |
m_jimmer12345 | what was your command is it a meta script or just stright up do_populate-sdk ? | 21:59 |
turkeykittin | just bitbake myimage -c populate_sdk | 21:59 |
turkeykittin | I 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 it | 22:00 |
turkeykittin | I _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 |
turkeykittin | Havent touched the SDK until today. | 22:01 |
m_jimmer12345 | Im not sure TBH. Are you doing anything with SDK_DEPLOY_DIR or anything like that ? | 22:02 |
turkeykittin | Nope | 22:02 |
turkeykittin | Just using defaults | 22:02 |
m_jimmer12345 | have you tried to re-generate it ? | 22:03 |
m_jimmer12345 | can you show your local.conf in a paste bin ? | 22:03 |
turkeykittin | Like 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 :X | 22:05 |
turkeykittin | Yeah I can include that, one second | 22:05 |
turkeykittin | https://pastebin.com/sYted3SP | 22:07 |
turkeykittin | Going to try it without the task... | 22:13 |
m_jimmer12345 | what version are you on ? dunfell ? | 22:14 |
turkeykittin | Yeah | 22:14 |
m_jimmer12345 | so can you run the following | 22:14 |
m_jimmer12345 | bitbake -e IMAGE_NAME | grep ^TOOLCHAIN | 22:15 |
m_jimmer12345 | please change imagename to your image | 22:15 |
turkeykittin | pc go brrrr trying to do this in parallel with a do_populate_sdk | 22:17 |
m_jimmer12345 | ahh just wait. You could set your threads in your local.conf pretty sure nproc with out | 22:18 |
turkeykittin | I'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 #yocto | 22:19 | |
m_jimmer12345 | ## Set these when building locally | 22:19 |
m_jimmer12345 | BB_NUMBER_THREADS ?= "X" | 22:19 |
m_jimmer12345 | PARALLEL_MAKE ?= "-j X" | 22:19 |
m_jimmer12345 | Where X is the number's | 22:19 |
turkeykittin | oh that's beautiful | 22: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_jimmer12345 | I'm pretty sure that it defaults to nproc | 22:20 |
m_jimmer12345 | but its been a bit sense I looked at that code | 22:20 |
turkeykittin | hmmm | 22:20 |
turkeykittin | yeah actually I think I recall seeing it already at 8 | 22:20 |
turkeykittin | erm actually that may have been just errors from me building with cmake earlier... | 22:20 |
turkeykittin | does bitbake use ninja to build? If not then it was unrelated. Otherwise ninja was for sure using my nproc | 22:21 |
m_jimmer12345 | depends | 22:21 |
m_jimmer12345 | see generator at https://git.yoctoproject.org/poky/tree/meta/classes/cmake.bbclass?h=kirkstone#n17 | 22:24 |
*** frieder <frieder!~frieder@i59F4B2B7.versanet.de> has quit IRC (Remote host closed the connection) | 22:24 | |
m_jimmer12345 | so OECMAKE_GENERATOR="Ninja" | 22:24 |
m_jimmer12345 | would use ninja but the other is unix make files. Look likes there is not support for Watcom or green hills | 22:26 |
m_jimmer12345 | maybe i missed it | 22:26 |
turkeykittin | Ah 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 |
turkeykittin | Interesting, removing the toolchain host task fixed the environment issue | 22:28 |
turkeykittin | YES | 22:29 |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 276 seconds) | 22:29 | |
turkeykittin | cmake --version prints out 3.18.2. Greatly appreciated m_jimmer12345 | 22:29 |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 22:29 | |
m_jimmer12345 | good job !:) | 22:29 |
turkeykittin | The preferred version was a life saver. That was what was missing | 22:30 |
turkeykittin | and 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 |
turkeykittin | Don't try to fix multiple things at once! :X You'll only break it more! haha | 22:31 |
turkeykittin | For anyone curious, TOOLCHAIN_HOST_TASK += "nativesdk-cmake" in local.conf seems to make bitbake unhappy when populating the sdk | 22:31 |
turkeykittin | populating/installing* | 22:32 |
*** kevinrowland <kevinrowland!~kevinrowl@12.3.202.154> has joined #yocto | 22:33 | |
kergoth | turkeykittin: 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 addition | 22:35 |
turkeykittin | Will check that out, thank you kergoth ! | 22:36 |
turkeykittin | Interesting, 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 |
turkeykittin | Thank 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_jimmer12345 | thank you for the nice words. We found the root issue and are testing | 22:52 |
m_jimmer12345 | gotta 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/!