| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has quit IRC | 00:10 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 00:25 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has joined #yocto | 00:25 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 00:33 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 00:35 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 00:36 | |
| *** sakoman <sakoman!~steve@72.173.249.164> has quit IRC | 01:08 | |
| *** bzb <bzb!~bzb@135-23-193-53.cpe.pppoe.ca> has quit IRC | 01:09 | |
| *** dreyna_ <dreyna_!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 01:15 | |
| *** [Sno] <[Sno]!~sno@p4fe9347b.dip0.t-ipconnect.de> has joined #yocto | 01:19 | |
| *** sno <sno!~sno@p4fe93f65.dip0.t-ipconnect.de> has quit IRC | 01:21 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:3d86:e11:ab6d:9d24> has joined #yocto | 01:24 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 01:24 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 01:25 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 01:26 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 01:26 | |
| *** itseris <itseris!~itseris@d75-157-111-210.bchsia.telus.net> has joined #yocto | 01:30 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 01:31 | |
| *** itseris <itseris!~itseris@d75-157-111-210.bchsia.telus.net> has joined #yocto | 01:31 | |
| * paulg wonders who'd complain if we declared xxd-native a part of ASSUME_PROVIDED... | 01:56 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:59 | |
| *** fl0v0 <fl0v0!~fvo@88.130.223.227> has quit IRC | 02:30 | |
| *** fl0v01 <fl0v01!~fvo@89.244.121.89> has joined #yocto | 02:30 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 02:40 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:44 | |
| *** dreyna_ <dreyna_!~dreyna@2601:646:4201:e280:e8d1:57a4:e041:cb94> has joined #yocto | 03:06 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-fuuogvxihmbjyoqb> has joined #yocto | 03:21 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 03:25 | |
| *** RP <RP!~RP@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has quit IRC | 03:35 | |
| *** RP <RP!~RP@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has joined #yocto | 03:42 | |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has joined #yocto | 03:48 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC | 04:01 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 04:02 | |
| *** jobroe <jobroe!~manjaro-u@p579eb96e.dip0.t-ipconnect.de> has joined #yocto | 04:05 | |
| *** ctlnwr <ctlnwr!~catalin@46.97.150.20> has joined #yocto | 04:22 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:3d86:e11:ab6d:9d24> has quit IRC | 04:22 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 04:37 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 04:40 | |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:589e:5d0e:8469:633b> has quit IRC | 05:07 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 05:13 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 05:14 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 05:18 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 05:26 | |
| *** nslu2-log__ <nslu2-log__!~nslu2-log@milla.nas-admin.org> has quit IRC | 05:27 | |
| *** nslu2-log <nslu2-log!~nslu2-log@leia.nas-admin.org> has quit IRC | 05:27 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 05:28 | |
| *** nslu2-log <nslu2-log!~nslu2-log@leia.nas-admin.org> has joined #yocto | 05:28 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 05:28 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 05:31 | |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 05:37 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 05:39 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 05:40 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 05:41 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 05:43 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 05:45 | |
| *** ctlnwr_ <ctlnwr_!~catalin@unknown-3-102.windriver.com> has joined #yocto | 05:48 | |
| *** ctlnwr <ctlnwr!~catalin@46.97.150.20> has quit IRC | 05:52 | |
| *** agust <agust!~agust@pd95f1388.dip0.t-ipconnect.de> has joined #yocto | 05:57 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 05:58 | |
| *** dreyna_ <dreyna_!~dreyna@2601:646:4201:e280:e8d1:57a4:e041:cb94> has quit IRC | 06:04 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 06:05 | |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:589e:5d0e:8469:633b> has joined #yocto | 06:08 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-fuuogvxihmbjyoqb> has quit IRC | 06:11 | |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:589e:5d0e:8469:633b> has quit IRC | 06:12 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 06:32 | |
| *** rcoote <rcoote!~rcoote@2a02:908:692:81c0:1c6f:f48c:3ebc:63d> has joined #yocto | 06:33 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:35 | |
| *** mckoan|away is now known as mckoan | 06:38 | |
| mckoan | good morning | 06:39 |
|---|---|---|
| *** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has joined #yocto | 07:25 | |
| *** Fanfwe <Fanfwe!~fanfwe@im.goudal.net> has quit IRC | 07:27 | |
| *** Fanfwe <Fanfwe!~fanfwe@im.goudal.net> has joined #yocto | 07:27 | |
| *** caiortp <caiortp!~caiortp@92-108-245-63.cable.dynamic.v4.ziggo.nl> has joined #yocto | 07:33 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:dbe9:fd6c:d1a9:4bb5> has joined #yocto | 07:41 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:43 | |
| *** kyanres <kyanres!~kyanres@ecascr.ecatou.fr> has joined #yocto | 07:43 | |
| *** ENPJ <ENPJ!~ENPJ@46.183.103.17> has joined #yocto | 07:44 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 07:50 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-61-64.ssp.dialog.net.pl> has joined #yocto | 07:53 | |
| qschulz | mornin' | 08:01 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 08:25 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 08:26 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 08:30 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has joined #yocto | 08:31 | |
| *** oobitots51 <oobitots51!ad26d106@aer01-mda1-dmz-wsa-1.cisco.com> has joined #yocto | 08:33 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 08:38 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 08:38 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 08:45 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 08:45 | |
| *** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 08:48 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 08:58 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 09:19 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 09:20 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 09:21 | |
| *** pankaj347 <pankaj347!7aa678a8@122.166.120.168> has joined #yocto | 09:24 | |
| *** Bunio_FH <Bunio_FH!~bunio@188.146.164.170.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 09:36 | |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has joined #yocto | 09:45 | |
| *** JosephAntony <JosephAntony!a5e17a71@165.225.122.113> has joined #yocto | 09:46 | |
| eFfeM1 | Hi, anyone an idea what is wrong with the following: | 09:49 |
| eFfeM1 | I'm trying to write a recipe for a python package whose source is on github, but I end with a package: | 09:49 |
| eFfeM1 | ./deploy-debs/aarch64/python3-bosdyn-mission_2.3.3-r0_arm64.deb | 09:49 |
| eFfeM1 | there is no platform specific code in the package. (just py/pyc files) | 09:49 |
| eFfeM1 | How do I set the right architecture? | 09:49 |
| qschulz | eFfeM1: what is the right architecture? | 09:54 |
| eFfeM1 | qschulz I want to build for arm64 but the .deb ends up in aarch64 | 09:55 |
| eFfeM1 | but effectively the package is architecture independent | 09:56 |
| qschulz | eFfeM1: aarch64 is the official name of arm64 | 09:57 |
| eFfeM1 | facepalm; of course :-) | 09:57 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 09:57 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:852:178e:b383:9e8d> has joined #yocto | 09:58 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 09:58 | |
| eFfeM1 | qschulz I came here because my rootfs complained about mismatches, trying again now to get the actual error message back | 09:59 |
| qschulz | In the end, I think most python recipes aren't architecture independent from Yocto PoV. I guess because anyway they depend on the Python binary which is architecture dependent so the benefit is extremely minimal. Wild guess though | 09:59 |
| qschulz | runtime depend* | 09:59 |
| eFfeM1 | makes sense | 09:59 |
| qschulz | eFfeM1: then let's have a look at this error first :) | 10:00 |
| eFfeM1 | qschulz here is the end oof the do_rootfs log: https://pastebin.com/anrcVqqv | 10:05 |
| eFfeM1 | lots of similar dpgt warnings before that | 10:05 |
| eFfeM1 | dpkg: warning: package architecture (arm64) does not match system (amd64) | 10:05 |
| abelloni | aren't they architecture dependent because of the .pyc ? | 10:07 |
| eFfeM1 | abelloni yes, actually the architecture dependency is not the problem, it is the issue in install | 10:09 |
| qschulz | abelloni: that would indeed make sense yes. But I'm not sure it is the issue? My guess right now is that the dpkg warnings are ok because dpkg is running on the building machine (amd64) to build the rootfs on the building machine for the target (which is arm64) | 10:09 |
| abelloni | eFfeM1: can you share the do_rootfs.log ? | 10:10 |
| eFfeM1 | abelloni that is a bit hard as it is on a docker whose host I have to access via ssh, but you and qschulz helped me looking at the right place in the log and I now know what the issue is (but not yet how to fix it) | 10:12 |
| eFfeM1 | The issue is that the src git repo actually contains sources for three packages, and do_rootfs fails with | 10:13 |
| eFfeM1 | trying to overwrite '/usr/lib/python3.7/site-packages/bosdyn/__init__.py', which is also in package python3-bosdyn-choreography-client:arm64 2.3.3-r0 | 10:13 |
| eFfeM1 | whiich si the real cause of my problem | 10:14 |
| qschulz | eFfeM1: do you have multiple recipes for the same src git repo? | 10:15 |
| eFfeM1 | basically the packages are in subdirs of the git repo, so I ended up with | 10:15 |
| eFfeM1 | S="${WORKDIR}/git/python/bosdyn-mission" | 10:15 |
| eFfeM1 | etc | 10:15 |
| eFfeM1 | qschulz Yes! | 10:15 |
| abelloni | bitbake should have complained earlier | 10:15 |
| eFfeM1 | 3 recipes that buiild a python package in 3 different subdirs of the same git repo | 10:16 |
| eFfeM1 | oh and I am a bit of a python n00b; I was just asked to create a recipe for these three packages | 10:18 |
| eFfeM1 | they are 3 different pip packages that in the end I want to get into my image | 10:18 |
| eFfeM1 | I also tried a do_install() with body pip3 install bosdyn-mission etc but then of course it all ended up in sysroot-native or so, so that did not fly | 10:20 |
| eFfeM1 | qschulz would it help if I carve one recipe that does three python3 setup.py calls in do_compile and do_install ? | 10:22 |
| rburton | why not just have three recipes that use the same SRC_URI | 10:24 |
| rburton | as they're separate packages | 10:24 |
| rburton | you *can* do what you want | 10:25 |
| eFfeM1 | rburton that is what I have now and that gives me | 10:25 |
| eFfeM1 | trying to overwrite '/usr/lib/python3.7/site-packages/bosdyn/__init__.py', which is also in package python3-bosdyn-choreography-client:arm64 2.3.3-r0 | 10:25 |
| eFfeM1 | when adding all three packages to my image | 10:25 |
| rburton | so presumably pip installing the 'top level' one is installing the others for you | 10:25 |
| rburton | sounds like you don't really need multiple | 10:26 |
| rburton | how i'd approach the 'multiple packages in a repo' thing is a custom do_compile that sets DISTUTILS_SETUP_PATH to $S/packageone then calls distutils3_do_compile, then DISTUTILS_SETUP_PATH=$S/packagetwo; distutils3_do_compile, etc | 10:27 |
| rburton | that will run setup in each directory. ditto for install. | 10:27 |
| rburton | but if there's a "top level" module that depends on the others, just install that and it looks like the dependencies are being handled for you | 10:27 |
| eFfeM1 | yeah I was considering your multiple packages approach, I'll also peek at the dependencies. Will be after lunch though as it is now noon here, back in 30mins | 10:29 |
| *** zbodek <zbodek!~zbb@89-64-66-107.dynamic.chello.pl> has joined #yocto | 10:30 | |
| *** BimBam <BimBam!531fc3b6@83.31.195.182> has joined #yocto | 10:30 | |
| *** BimBamBim <BimBamBim!531fc3b6@83.31.195.182> has joined #yocto | 10:34 | |
| zbodek | hey. I have a question. In the bb recipe I created I include a .inc file from another recipe in another layer. Everything would work but the .inc file pulls a patch in SRC_URI and of course unless I have a local "files" with that patch, it won't be found. | 10:36 |
| zbodek | Is there a way to do it "right" ? | 10:36 |
| BimBamBim | Hello, Im experiencing weird problem with my yocto and cant handle that alone, maybe someone here has experienced that. | 10:38 |
| BimBamBim | I got my new build machine and it works fast etc, BUT, for few packages the build stalls. I mean - they keep rolling forever (now its over 5000s and cpu usage is almost 0% on all cores). I made some investination and I found out that for 4 out of 6 of there packages the build blocks on: | 10:38 |
| BimBamBim | ``` | 10:38 |
| BimBamBim | if [ -p <MY_PATH>/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtquickcontrols/5.9.7+gitAUTOINC+1afae24d7f-r0/temp/fifo.3554347 ] ; then | 10:38 |
| BimBamBim | ``` | 10:38 |
| BimBamBim | Do you have any ideas what could cause that ? I didnt touch this recipe and this build works wello n 4 other machines | 10:38 |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has quit IRC | 10:41 | |
| *** kyanres <kyanres!~kyanres@ecascr.ecatou.fr> has quit IRC | 10:41 | |
| *** vitali <vitali!~vitali@5.20.142.87> has quit IRC | 11:03 | |
| *** richbridger <richbridger!~richbridg@089144195136.atnat0004.highway.a1.net> has quit IRC | 11:03 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-mnkjjqgqbtpwawnc> has joined #yocto | 11:04 | |
| *** vitali <vitali!~vitali@5.20.142.87> has joined #yocto | 11:05 | |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has joined #yocto | 11:06 | |
| *** vitali <vitali!~vitali@5.20.142.87> has quit IRC | 11:07 | |
| eFfeM1 | zbodek you could consider adding a FILESEXTRAPATHS_prepend or so to your recipe | 11:08 |
| *** vitali <vitali!~vitali@5.20.142.87> has joined #yocto | 11:11 | |
| *** BimBamBim <BimBamBim!531fc3b6@83.31.195.182> has quit IRC | 11:15 | |
| kanavin | khem, can you look at https://gitlab.com/procps-ng/procps/-/merge_requests/126 please? | 11:16 |
| zbodek | eFfeM1: I could but then it would need to be an absolute path wouldn't it? | 11:18 |
| zbodek | eFfeM1: and the "files" directory is in another layer | 11:18 |
| eFfeM1 | I suspect the layering is not a problem, the fact that it is a different package could be. | 11:20 |
| eFfeM1 | If what you want to do is to create a recipe for a different version best keep the directory structure the same (so the same folder in your layer) | 11:20 |
| eFfeM1 | if you have a different recipe thaen consider if youu want to include an inc file from a different package | 11:21 |
| eFfeM1 | and if you want a quuick and dirty solution copy over whatever you need; this is basically what I did when I had to go for an older version of python | 11:22 |
| zbodek | eFfeM1: copying of the files directory to have same structure works fine but I am afraid it won't be acceptable | 11:26 |
| zbodek | I'm trying to add a sample application to my layer, that will use this layer+recipe http://git.yoctoproject.org/cgit/cgit.cgi/meta-zephyr/tree/recipes-kernel/zephyr-kernel | 11:27 |
| zbodek | my recipe will look similar to this one http://git.yoctoproject.org/cgit/cgit.cgi/meta-zephyr/tree/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb | 11:27 |
| zbodek | with an exception that the source code will be pulled from somewhere else. still I'm including zephyr-sample.inc which will pull the patch from meta-zephyr files via SRC_URI | 11:28 |
| zbodek | quite weird usage of meta-zephyr layer but I don't know how to attack it differently | 11:29 |
| *** BimBamBim <BimBamBim!531fc3b6@83.31.195.182> has joined #yocto | 11:29 | |
| BimBamBim | Im sorry I got disconnected, if someone replied to my question please repeat | 11:30 |
| *** ENPJ <ENPJ!~ENPJ@46.183.103.17> has quit IRC | 11:31 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 11:31 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 11:35 | |
| *** JosephAntony <JosephAntony!a5e17a71@165.225.122.113> has quit IRC | 11:36 | |
| qschulz | zbodek: I think you could probably setup a PREMIRRORS in your local.conf to redirect the SRC_URI request to one of your "somewhere else" repo? | 11:38 |
| qschulz | zbodek: but indeed, FILESEXTRAPATHS does nto seem to be an appropriate mechanism since you need to know where the layer with the .inc file is located ont he FS and it's not guaranteed to be stable over time | 11:39 |
| eFfeM1 | qschulz do you by any chance have a suggestion or pointer on how to build 3 packages from the same git repo. I'm also good if it just generates one yocto package, but being a python n00b I do not really know how to tackle this | 11:42 |
| *** ENPJ <ENPJ!~ENPJ@46.183.103.17> has joined #yocto | 11:43 | |
| eFfeM1 | actually the way I build now each package gets an __init__.py at top level but they are identical | 11:44 |
| qschulz | eFfeM1: rburton suggested something, have you tried that already? | 11:59 |
| rburton | if they're writing the same file then you'll need to understand any dependencies and sort out the packaging | 12:03 |
| rburton | as you're not showing us the source, it's hard to help | 12:04 |
| *** ahalaney <ahalaney!~ahalaney@136.33.227.6> has joined #yocto | 12:06 | |
| *** sagner <sagner!~ags@2a02:169:3df5::4db> has joined #yocto | 12:08 | |
| eFfeM1 | rburton I have this: | 12:08 |
| eFfeM1 | do_compile() { | 12:09 |
| eFfeM1 | DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-client; distutils3_do_compile | 12:09 |
| eFfeM1 | DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-choreography-client; distutils3_do_compile | 12:09 |
| eFfeM1 | DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-mission; distutils3_do_compile | 12:09 |
| eFfeM1 | } | 12:09 |
| eFfeM1 | oops, I see something | 12:09 |
| eFfeM1 | the git part should not be there as it is part of #{S}; hovever without it, it also tries to find setup.py in ${S} | 12:11 |
| eFfeM1 | I also tried without the ; but saem result | 12:11 |
| eFfeM1 | ...python3-bosdyn-sdk/2.3.3-r0/git//setup.py': [Errno 2] No such file or directory | 12:11 |
| rburton | why dont' you just do separate recipes for client, mission and choroegograph, and let -core ship the top-level bosdyn/__init__ | 12:13 |
| rburton | (deleting it from the other recipes) | 12:13 |
| eFfeM1 | rburton that seems the simplest solution, I have the 3 recipes already but need to see how to best get rid of the __init__py file in the other recipes | 12:14 |
| rburton | do_install_append() { rm ${D}/${libdir}/python*/bosdyn/__init__.py} | 12:15 |
| zbodek | eFfeM1: It seems my problem can be resolved by adding FILESEXTRAPATHS_prepend := "${THISDIR}/files:" to the inc file that pulls the patch. thank's for your help anyway | 12:15 |
| eFfeM1 | rburton guess I need to make sure that the one with the __init__.py is installed last | 12:16 |
| eFfeM1 | zbodek you're welcome, glad to be of help | 12:17 |
| *** zbodek <zbodek!~zbb@89-64-66-107.dynamic.chello.pl> has quit IRC | 12:18 | |
| *** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:212b:99c:9e11:bd49> has joined #yocto | 12:28 | |
| eFfeM1 | rburton the rm is a good plan, your snippet was missing the site-packages part in the path but that was easy to fix, now still seeing how to get them installed in the right order as indeed the one with the __init__ must be last; but they are not processed in the order as they appear in IMAGE_INSTALL, seems they are sorted | 12:34 |
| eFfeM1 | I'm now trying to have the recipe with the __init__ to have an RDEPENDS on the other two | 12:34 |
| eFfeM1 | that does not work either, as they are sorted I either need to get rid of the __init__.py in the package, for now I am considering just to stuff the __init__.py file in the dbg package or so | 12:39 |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:dbe9:fd6c:d1a9:4bb5> has quit IRC | 12:43 | |
| *** Yumasi <Yumasi!~guillaume@static-176-175-104-214.ftth.abo.bbox.fr> has joined #yocto | 12:44 | |
| eFfeM1 | rburton in the end I did this in two packages and that solved the issue: | 12:46 |
| eFfeM1 | FILES_${PN}-dbg += "${libdir}/python*/site-packages/bosdyn/__init__.py" | 12:47 |
| eFfeM1 | will probably make it a separate package | 12:47 |
| eFfeM1 | anyyway I now can proceed. | 12:47 |
| eFfeM1 | rburton qschulz abelloni thanks for your help! | 12:48 |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has quit IRC | 12:51 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 12:53 | |
| *** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:212b:99c:9e11:bd49> has quit IRC | 12:59 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 13:01 | |
| *** Spooster_ <Spooster_!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 13:01 | |
| rburton | eFfeM1: why do they need to be installed in a particular order? just putting the init in the -dbg package is *horrible* | 13:03 |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has quit IRC | 13:03 | |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has joined #yocto | 13:05 | |
| *** aganders3 <aganders3!~aganders3@c-73-253-41-35.hsd1.ma.comcast.net> has joined #yocto | 13:10 | |
| aganders3 | Hi all - I'm a Yocto newbie and just have my first build (Gatesgarth core-image-minimal) running on my target hardware (intel x86-64). For the next step, I'd like to add Nvidia GPU drivers, but I have not found much information. This seems like it would be a relatively common use-case, so I'm curious if I have the wrong idea here. | 13:23 |
| aganders3 | I found an old mailing list thread about this but it seemed to die off without resolution: https://www.yoctoproject.org/pipermail/yocto/2018-October/042982.html | 13:23 |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has joined #yocto | 13:38 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has quit IRC | 13:40 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has joined #yocto | 13:43 | |
| *** emrius <emrius!~emrius@dslb-002-206-166-055.002.206.pools.vodafone-ip.de> has joined #yocto | 13:51 | |
| qschulz | aganders3: you probably need the nouveau kernel driver to be compiled by the kernel recipe either built in or as a module and have mesa packages installed | 13:51 |
| qschulz | maybe some additional X packages too | 13:52 |
| aganders3 | qschulz: thanks! Unfortunately my primary use (headless system) is CUDA, which I don't think the nouveau driver supports. | 13:52 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:53 | |
| aganders3 | I noticed there is a gentoo ebuild for these drivers (https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-drivers/nvidia-drivers/nvidia-drivers-450.102.04.ebuild), maybe that would be a good starting point for creating a bitbake recipe? | 13:54 |
| qschulz | aganders3: is there a reason for going with Yocto for this build and not, e.g. gentoo or other distros? | 13:57 |
| *** ENPJ <ENPJ!~ENPJ@46.183.103.17> has quit IRC | 13:59 | |
| aganders3 | Maybe it's the wrong direction. We're using Ubuntu now and having trouble managing updates in the field (kind of an IoT-like setup). I've been looking at projects like RAUC and SWupdate to enable atomic updates, and that led me to looking into Yocto. | 14:00 |
| aganders3 | We're in kind of a weird space I feel where we have a headless system with basically desktop-class hardware, but we want to treat it a lot like an embedded system. | 14:00 |
| *** sakoman <sakoman!~steve@72.173.249.164> has joined #yocto | 14:01 | |
| *** sgw1 <sgw1!~sgw@2601:642:c400:ecf0:a579:bb0e:c0d7:fe81> has quit IRC | 14:08 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC | 14:11 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 14:17 | |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-18-184-147-76-169.dsl.bell.ca> has joined #yocto | 14:18 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 14:19 | |
| emrius | Hey folks, could you help me out on this one? | 14:20 |
| emrius | https://stackoverflow.com/questions/66834542/append-variable-does-not-update-kernel-command-line?noredirect=1#comment118172990_66834542 | 14:20 |
| emrius | I'm trying to set the `APPEND` variable to set `isolcpus=2` for the kernel cmdline. | 14:20 |
| *** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has joined #yocto | 14:20 | |
| emrius | I just added a dedicated machine config named `raspberrypi4-custom.conf` within which I then added `APPEND...` and override MACHINE back to `raspberrypi4` to not break any other dependencies | 14:21 |
| emrius | Still, my `/proc/cmdline` does not include the `isolcpus` statement. I'm a bit puzzled how to do that | 14:22 |
| qschulz | emrius: kernel parameters are set via a config.txt file on the boot partition on RPi IIRC | 14:22 |
| emrius | I thought that was just one out of several options? Do I *have* to do that via conig.txt on RPis? | 14:23 |
| qschulz | emrius: bootloader is board specific. RPi has its own weird bootloader. By default, this weird bootloader is used and it uses config.txt (at least in *MANY* distros, don't remember for Yocto). | 14:26 |
| emrius | qschulz: Okay, thanks. But also are you sure about `config.txt`? I tried that on an already bitbaked image and it doesn't work either. Or does the flag have to be present at compile time? | 14:27 |
| qschulz | emrius: otherwise, you have bootargs in U-Boot if it's used, but needs to be put into U-Boot environment which can be done in several ways | 14:28 |
| qschulz | emrius: config.txt is a txt file, so no, no need for it to be done at compile time if you just want to play with it | 14:28 |
| emrius | qschulz: Okay, then it doesnt work through config.txt. Or works through `/uboot/cmdline.txt` though. But, I felt that the `APPEND` variable was just so much more convenient. (If it worked) | 14:29 |
| emrius | ... and I'm still a bit puzzled. I mean technically that sounds like the right approach right? cf C.1.6. at the veeeeery bottom here https://www.yoctoproject.org/docs/2.5/kernel-dev/kernel-dev.html | 14:32 |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has quit IRC | 14:34 | |
| *** sgw1 <sgw1!~sgw@2601:642:c400:ecf0:3dcc:7a70:d6f3:cfc6> has joined #yocto | 14:36 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 14:41 | |
| qschulz | emrius: it appears nowhere in poky thud (2.6), so it was maybe removed and forgotten in the docs? | 14:43 |
| qschulz | emrius: oh geez | 14:43 |
| emrius | qschulz: ah hm... maybe. Tried to tackle that with grep but didn't really come to a conclusion. | 14:44 |
| emrius | Well, then I'm happy that I could contribute to keeping the documentation up to date :) | 14:45 |
| emrius | When can I patch the docs? | 14:45 |
| *** thaytan <thaytan!~thaytan@159-196-146-150.9fc492.syd.nbn.aussiebb.net> has quit IRC | 14:46 | |
| qschulz | emrius: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=136d9cd07d1c2ad316cd59b8fd95b772698e1be2 | 14:49 |
| qschulz | it is OLD | 14:49 |
| qschulz | emrius: for 2.5, check if there's someone willing to take patches but I would say you won't get approval | 14:50 |
| qschulz | emrius: otherwise: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/ | 14:50 |
| emrius | qschulz: Ok thanks | 14:51 |
| qschulz | I would say it makes sense to remove it since I don't think there's any way to formulate it well enough to list all possible cases | 14:52 |
| *** thaytan <thaytan!~thaytan@159-196-146-150.9fc492.syd.nbn.aussiebb.net> has joined #yocto | 14:53 | |
| *** Lihis_ <Lihis_!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 14:53 | |
| *** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has quit IRC | 14:54 | |
| *** Lihis_ is now known as Lihis | 14:54 | |
| *** kaspter <kaspter!~Instantbi@183.192.143.108> has joined #yocto | 14:57 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 14:58 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 14:58 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 15:00 | |
| *** gsalazar <gsalazar!~gsalazar@173.111.90.149.rev.vodafone.pt> has joined #yocto | 15:04 | |
| *** diego_r <diego_r!~diego@dynamic-adsl-84-221-249-106.clienti.tiscali.it> has joined #yocto | 15:05 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 15:06 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 15:13 | |
| *** pankaj347 <pankaj347!7aa678a8@122.166.120.168> has quit IRC | 15:14 | |
| alex88 | Is there a way to get the output uboot env variables generated by yocto (without running u-boot since we don't get any output)? | 15:16 |
| *** ctlnwr__ <ctlnwr__!~catalin@46.97.22.179> has joined #yocto | 15:19 | |
| *** ctlnwr_ <ctlnwr_!~catalin@unknown-3-102.windriver.com> has quit IRC | 15:21 | |
| qschulz | alex88: a few env variables are actually set at runtime by U-Boot itself so it wouldn't be complete anyway | 15:22 |
| alex88 | qschulz, ok so it's better to rely on UBOOT_* checked with bitbake -e? | 15:26 |
| qschulz | alex88: which u-boot env variables are you talking about? | 15:27 |
| *** ctlnwr_ <ctlnwr_!~catalin@46.97.150.20> has joined #yocto | 15:28 | |
| alex88 | qschulz, basically we have a device that doesn't show anything in the serial console (while with the original SD card from the manufacturer it does) so I'm just trying to compare the u-boot configuration (somehow) to see what can be wrong | 15:29 |
| alex88 | I've been told the dtb might be wrong but the dtb is in the rootfs partition so it should be something that's used after u-boot loaded right? | 15:30 |
| qschulz | alex88: there's dtb support in U-Boot too and U-Boot has its own dtb, separate from the kernel;s | 15:31 |
| *** ctlnwr__ <ctlnwr__!~catalin@46.97.22.179> has quit IRC | 15:31 | |
| alex88 | qschulz, oh ok, because right know what I've done is, took the dtb from the manufacturer SD card, converted to dts with dtc, added it to the kernel using a custom recipe by modifying SRC_URI and setting KERNEL_DEVICETREE to the custom dtb name and that correctly outputs the dtb in the deploy dir | 15:33 |
| qschulz | alex88: the u-boot environment will be for sure accessible at runtime but since I guess you have nothing on serial, it won't help much. If it;s a configuration issue, menuconfig and include/configs/yourboard.h as well as board/<vendor>/<board>/*.c would help you figure out things probably | 15:33 |
| alex88 | so this only adds the dtb to the kernel and not u-boot? | 15:34 |
| qschulz | alex88: yeah no, they are different device trees, with potentially different properties/syntaxes/nodes, etc... | 15:34 |
| qschulz | alex88: don't recompile a decompiled dtb, just put the dtb as is in the install step | 15:34 |
| alex88 | oh ok, so the dtb I took in rootfs/boot is only for the kernel, I should get the one used in u-boot which without manufacturer support will be hard I imagine | 15:35 |
| alex88 | oh ok will do that | 15:35 |
| qschulz | alex88: some old U-Boot don't have dtb support | 15:35 |
| qschulz | I mean, for configuring itself | 15:35 |
| alex88 | the one they use is 2014.07 and it contains a fdtfile variable that points to the device dtb filename https://gist.github.com/alex88/5e8d604ab15540b84353040a83bc0606 | 15:36 |
| *** AndersD__ <AndersD__!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 15:38 | |
| qschulz | alex88: you're in for a treat with such an old u-boot :) | 15:38 |
| *** AndersD__ <AndersD__!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:38 | |
| alex88 | qschulz, at least that one is working :) | 15:39 |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 15:39 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:852:178e:b383:9e8d> has quit IRC | 15:40 | |
| qschulz | alex88: the file you send very much looks like a file used to setup the environment and you also have uEnv.txt support probably seeing it being mentioned | 15:40 |
| alex88 | the sd card they provide doesn't contain uEnv.txt, that file is the output of the printenv command run from u-boot | 15:41 |
| alex88 | so, without a dtb for u-boot, is it hard to achieve a working u-boot? we're also considering getting a consultant do it but since we're doing this as a favor for a customer that has hundreds of these useless devices we can't invest week of development, we will rather have the customer buy another hardware with an available bsp layer | 15:43 |
| alex88 | *weeks | 15:43 |
| paulg | WARNING: SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '1302044400' | 15:43 |
| qschulz | alex88: what exactly are you trying to achieve? | 15:43 |
| paulg | getting a bunch of them in what is probably about a month old(ish?) build directory. | 15:44 |
| qschulz | alex88: since it seems you have a working U-Boot from your vendor and don't have much time to spend :) | 15:48 |
| qschulz | alex88: anyway, you might receive more help on #u-boot IRC channel, but porting your board support to a new U-Boot is probably not a one week thing | 15:49 |
| alex88 | qschulz, get a minimal image (created via yocto) to boot on the device.. yes we have the working u-boot from the vendor. I've also tried to just replace the rootfs but it hangs on "starting kernel" | 15:49 |
| alex88 | qschulz, last question, the make menuconfig should be run where? | 15:50 |
| alex88 | qschulz, if it's that hard we won't even bother doing it, my boss said to not spend more than a day, I was ok doing more for free just for fun but not weeks for sure :) | 15:50 |
| qschulz | alex88: if you replaced the rootfs but you reach only Starting kernel it's probably that your rootfs overrode the place in RAM where you kernel was loaded by U-Boot (I guess you went for an initramfs?) | 15:51 |
| qschulz | alex88: root of U-Boot git repo after having sourced the correct defconfig | 15:51 |
| qschulz | alex88: shameless plug: https://www.youtube.com/watch?v=5E0sdYkvq-Q | 15:52 |
| *** psiva87 <psiva87!c6b209b4@fw800-d-ashburn-va-corp.comcast.net> has joined #yocto | 15:52 | |
| qschulz | at least for the abstract steps and some explanations | 15:52 |
| alex88 | ok thank you, regarding initramfs I think I'll have to read more about it, not sure what you mean :) I've just tried to use the am335x-evm config that meta-ti provides | 15:52 |
| alex88 | thanks a lot for the link, at least I'll get more context | 15:52 |
| *** aganders3 <aganders3!~aganders3@c-73-253-41-35.hsd1.ma.comcast.net> has quit IRC | 15:53 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 15:53 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 15:55 | |
| qschulz | alex88: welcome to the wonderful world of vendor BSPs of very varying quality (more often bad than good unfortunately) | 15:57 |
| alex88 | Definitely not a fun experience so far, but very interesting and lots to learn :) | 16:00 |
| *** psiva87 <psiva87!c6b209b4@fw800-d-ashburn-va-corp.comcast.net> has quit IRC | 16:01 | |
| *** fl0v01 <fl0v01!~fvo@89.244.121.89> has quit IRC | 16:02 | |
| *** caiortp <caiortp!~caiortp@92-108-245-63.cable.dynamic.v4.ziggo.nl> has quit IRC | 16:03 | |
| *** felix_inst <felix_inst!~fevi8970@pool-108-18-223-253.washdc.fios.verizon.net> has joined #yocto | 16:03 | |
| felix_inst | Hi, I am looking to get some training with board bringup, u-boot and kernel configuration for Xilinx FPGA boards. Ideally this would be 1 on 1 sessions via zoom. Does anybody have recommendations for who can offer these services? Thanks! | 16:04 |
| alex88 | is there a well known brand that makes industrial devices that have good compatibility with yocto? or should I just go in the machines list in the openembedded site? | 16:04 |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-47-76-71-204-197.dsl.bell.ca> has joined #yocto | 16:05 | |
| roussinm | If I would like to have a SDK to be able to develop on a platform that has glibc 2.19 and I can't upgrade it, do I have to absolute use the `daisy` release? | 16:15 |
| *** savolla <savolla!~savolla@95.10.206.84> has joined #yocto | 16:17 | |
| *** savolla <savolla!~savolla@95.10.206.84> has joined #yocto | 16:18 | |
| *** savolla <savolla!~savolla@95.10.206.84> has joined #yocto | 16:20 | |
| *** berton <berton!~user@200-180-244-11.user3p.brasiltelecom.net.br> has joined #yocto | 16:21 | |
| savolla | hi everyone! o/ | 16:22 |
| *** aganders3 <aganders3!~aganders3@50.238.244.46> has joined #yocto | 16:22 | |
| *** kaspter <kaspter!~Instantbi@183.192.143.108> has quit IRC | 16:28 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has quit IRC | 16:36 | |
| *** [Sno] <[Sno]!~sno@p4fe9347b.dip0.t-ipconnect.de> has quit IRC | 16:37 | |
| *** yann <yann!~yann@88.120.44.86> has quit IRC | 16:39 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:5256:f8ad:2da9:7c02> has joined #yocto | 16:42 | |
| malinus | alex88: most manufactureres of SoC and SoM's make "industrial grade" versions | 16:44 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC | 16:49 | |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 16:50 | |
| *** vineela <vineela!vtummala@nat/intel/x-xterpqdhqhxoklew> has joined #yocto | 16:56 | |
| alex88 | malinus, I mean complete devices (with enclosure and I/O) not just SoC/SoM.. as I imagine having a compatible SoC isn't enough to get a working image OOB (but I might be wrong) | 16:56 |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has joined #yocto | 17:04 | |
| savolla | I never heard SoM before | 17:06 |
| alex88 | Since I've started playing with yocto I had to look up most of the words :) | 17:07 |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has quit IRC | 17:09 | |
| *** mckoan is now known as mckoan|away | 17:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:13 | |
| denix | alex88: you mentioned your board was from another manufacturer based on TI am335x SoC - did you get BSP sources and build instructions from that manufacturer? or are you trying to straight load TI referencce BSP from meta-ti? | 17:17 |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.130> has joined #yocto | 17:18 | |
| denix | alex88: as discussed above, devicetree would be the biggest difference to get a custom board up and running, especially if your manufacturer didn't follow the TI reference closely | 17:19 |
| denix | alex88: from the Yocto perspective, you get all the vendor BSPs here for their SoCs and their reference and evaluation platforms, like EVMs, EVks, etc. | 17:21 |
| alex88 | denix, the latter (which isn't obviously so simple), unfortunately the manufacturer doesn't have public BSP for that (they have it since they use yocto too but they want us to use their OS) | 17:21 |
| alex88 | denix, by vendor you mean like meta-ti for TI devices? because TI is the one doing the SoC and someone like (e.g. beaglebone) is putting the soc on a board? sorry I'm a bit confused as you can tell :) | 17:23 |
| paulg | RP, any idea if poky 64662290d3 / bb d978e7b35 is still an issue 9 years on? I spotted the double slash in alternates and went data mining to see where it came from... | 17:23 |
| denix | alex88: if a 3rd-party manufacturer does a custom board with enough differences from reference, they need to provide a modified BSP for that board. or at least instructions | 17:23 |
| alex88 | denix, it can very possibly be that I'm just not able to correctly use yocto myself, as on top of meta-ti am335x-evm the only thing I've done was to get the dtb in the kernel (but probably not in uboot at this point) | 17:25 |
| denix | alex88: well, in your case TI is an SoC vendor. they also provide so called evaluation boards (EVM). so TI BSP officially supports own SoCs and EVMs. they you also have a different vendor who designed own board with TI SoC, so if it's too different from TI EVM, you can't straight up load TI BSP on that board - need to change configs and devicetrees, etc. | 17:27 |
| denix | alex88: I'm not trying to say you'd need a completely new BSP - TI BSP (kernel, u-boot, firmwares) probably covers most if not all of that custom board of yours. but you still need to configure it properly for that board | 17:30 |
| *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto | 17:31 | |
| alex88 | denix, I'll check the board to see if it's similar to the evm.. I just hoped, having a working OS image, that I could somehow find the configuration changes needed to get it to work with our own yocto image | 17:32 |
| alex88 | the other option would be to find a complete product (not just a board) with an available BSP so we can skip all the work needed to get it to boot and focus on the actual OS contents | 17:33 |
| denix | alex88: do you get any decent documentation with the board, besides just the binary images? | 17:35 |
| alex88 | denix, not really, it's a complete device with an enclosure not a board so they only provide documentation about the I/O and how to use it with their software | 17:36 |
| denix | alex88: do you need to customize u-boot? can you simply use their u-boot binary and load own kernel and rootfs? | 17:40 |
| *** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has joined #yocto | 17:40 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.130> has quit IRC | 17:40 | |
| alex88 | denix, that's definitely an option, but when I've tried it was first complaining about not finding /boot/zImage then I've formatted the partition using "-O ^metadata_csum,^64bit" and it was able to get to the "Starting kernel" point and then it was stuck | 17:42 |
| alex88 | but maybe that's because of initramfs as qschulz mentioned (which I have to understand better) | 17:42 |
| alex88 | (stuck and restarting after a while) | 17:43 |
| denix | alex88: I don't know if it's possible to re-create necessary board/<vendor>/<board>/*.c and corresponding dts files from the binary image of u-boot | 17:43 |
| denix | alex88: check if the right uart is used for the console output to see kernel messages | 17:44 |
| alex88 | the board/<vendor>/<board>/*.c files are for uboot? | 17:47 |
| *** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has quit IRC | 17:47 | |
| alex88 | denix, ok I'll look into how to change the UART, thank you! | 17:48 |
| alex88 | becuase in my case the machine I use (am335x-evm from meta-ti) already sets the serial consoles with SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS3" and that matches what I see in the working SD uboot env | 17:49 |
| *** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has quit IRC | 17:50 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.128> has joined #yocto | 17:52 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 17:52 | |
| *** emrius <emrius!~emrius@dslb-002-206-166-055.002.206.pools.vodafone-ip.de> has quit IRC | 17:52 | |
| denix | alex88: yeah, IIRC ttyS0 is used for GP am335 and ttyS3 was added for ICE industrial variant | 17:54 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:54 | |
| alex88 | this is what I see in the working SD kernel log https://gist.github.com/alex88/8dad9739f758b22581c1f5e8de15b067 | 17:55 |
| alex88 | so the serial port seems to be correct | 17:55 |
| denix | alex88: can you check what bootargs are passed to the kernel in the working logs? | 17:57 |
| alex88 | could be the bootargs env variable from their u-boot? | 17:58 |
| alex88 | bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait | 17:58 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 17:59 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:00 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:03 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:04 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 18:07 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:09 | |
| *** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::282c> has quit IRC | 18:10 | |
| *** aganders3 <aganders3!~aganders3@50.238.244.46> has quit IRC | 18:10 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:11 | |
| *** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::282c> has joined #yocto | 18:13 | |
| *** renegade <renegade!~renegade@2601:241:8a00:46e0:3842:5e5:ecdd:1fd0> has joined #yocto | 18:16 | |
| renegade | what would be a good way to build qt 5.12 with gatesgarth? Get meta-qt gatesgarth then make appends in my layer? | 18:17 |
| *** sam__ <sam__!~sam@c-24-11-124-12.hsd1.ut.comcast.net> has joined #yocto | 18:17 | |
| *** sam__ is now known as swright | 18:21 | |
| *** swright is now known as samw | 18:21 | |
| samw | hey everyone. Does anybody have experience with bringing up any NXP layerscape boards? I can get along fine enough (still very new to me) with the qemu targets, but am struggling with bringing up the "real" board. | 18:24 |
| *** BimBamBim <BimBamBim!531fc3b6@83.31.195.182> has quit IRC | 18:40 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:5256:f8ad:2da9:7c02> has quit IRC | 18:41 | |
| malinus | samw: SoM is System On Module. It's what you usually run with when you don't want to make your own carrier board for the SoC. Kinda like the rpi zero. | 18:44 |
| malinus | alex88: usually manufactureres provide working yocto | 18:45 |
| alex88 | malinus, unfortunately that's not possible in our scenario | 18:46 |
| malinus | how so? | 18:46 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:47 | |
| denix | alex88: you might want to pressure your board manufacturer to release sources to meet GPL obligations... | 18:48 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:49 | |
| alex88 | is that somehow mandatory? | 18:52 |
| denix | malinus: they got a custom board/product with binaries only (and those are quite old). the manufacturer used TI SoC in the board, but TI BSP won't boot on the board. no sources or instructions | 18:52 |
| malinus | h-how did they end up in that situation? | 18:53 |
| denix | alex88: GPL license does require sources to be available on request | 18:54 |
| alex88 | denix, what's under the GPL license that will give me the right to ask them for sources? | 18:55 |
| neverpanic | The Linux kernel and busybox, for example. | 18:56 |
| denix | as well as u-boot | 18:56 |
| alex88 | so theoretically just by using u-boot/busybox in their OS they would have to provide the meta layer used to build the image? | 18:57 |
| samw | I have found the NXP docs extremely lacking. I've spoken with a few reps from them and they are strongly pushing their LSDK over continuing to support yocto | 18:58 |
| derRichard | hi! one of the recipes a layer here uses SRC_URI_append_machineX and SRC_URI_append_machineY. when i run "devtool modify <recipe>", it applies patches from both SRC_URI_append_machineX and SRC_URI_append_machineY. | 18:58 |
| derRichard | bug? feature? :> | 18:58 |
| *** aganders3 <aganders3!~aganders3@104.226.19.98> has joined #yocto | 19:01 | |
| denix | alex88: not sure about the yocto layer, as metadata is usually MIT licensed. but at least you can (in theory) get kernel and u-boot soures and peek into necessary configuration and devicetree | 19:01 |
| derRichard | strictly speaking they don't even have to provide kernel configs nor devicetree files | 19:02 |
| derRichard | just the plain sources | 19:02 |
| denix | alex88: those will be 7-year old code bases, of course... | 19:03 |
| alex88 | at this point it's probably easier to find a device alternative | 19:03 |
| alex88 | I mean, it's not us those with hundreds of bricks so there's no way we can get the investment back by fixing it | 19:03 |
| alex88 | anyway, thank you very much denix for helping! | 19:04 |
| denix | derRichard: just the plain sources can get enough info, like u-boot board config, etc. but yeah, it may not be straighforward anyway and require extra work on alex88 part... | 19:06 |
| denix | alex88: you are certainly welcome! | 19:07 |
| *** aganders3 <aganders3!~aganders3@104.226.19.98> has quit IRC | 19:08 | |
| RP | paulg: I have no idea to be honest | 19:08 |
| *** jobroe <jobroe!~manjaro-u@p579eb96e.dip0.t-ipconnect.de> has quit IRC | 19:09 | |
| paulg | RP, ok, I guess I'll either just ignore the // or investigate further "someday"... | 19:10 |
| *** rcoote <rcoote!~rcoote@2a02:908:692:81c0:1c6f:f48c:3ebc:63d> has quit IRC | 19:10 | |
| RP | paulg: I reported it, worked around it, moved on... | 19:11 |
| paulg | :) | 19:11 |
| *** mansi <mansi!~mansi@h-154-99.A246.priv.bahnhof.se> has quit IRC | 19:11 | |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has joined #yocto | 19:25 | |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has quit IRC | 19:27 | |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has joined #yocto | 19:27 | |
| bluelightning | derRichard: that's not a bug per se, but it is supposed to apply them to different branches (creating one per separate configuration) - does it do that? | 19:28 |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has quit IRC | 19:29 | |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has joined #yocto | 19:29 | |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has quit IRC | 19:30 | |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has joined #yocto | 19:30 | |
| derRichard | bluelightning: it creates also one combined branch, for whatever reasons. just found that i can stop it from doing so by passing --no-overrides to it | 19:34 |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:f25b:aad3:93:ea00> has joined #yocto | 19:36 | |
| vdl | What is the preferred tool for a python recipe? setuptools? | 19:40 |
| *** dmytro007 <dmytro007!~AndroidIR@37.46.225.62> has joined #yocto | 19:40 | |
| vdl | I see that pyproject.toml is somehow the new thing for packaging python apps. But meta-python use a lot of setuptools3, I guess it's still the preferred (yocto) way | 19:53 |
| smurray | vdl: moto-timo mentioned on last week's technical call that he's working on a transition | 20:06 |
| vdl | smurray: in the meantime, it's better if I add a setup.py file and use | 20:08 |
| vdl | setuptools3, right? | 20:08 |
| vdl | (until a new yocto release switches to pyproject.toml | 20:09 |
| vdl | ) | 20:09 |
| smurray | vdl: setuptools3 is what is supported today AFAIK | 20:10 |
| smurray | vdl: moto-timo may pop on at some point and be able to describe his plans | 20:11 |
| vdl | I'll stick with setup.py/setuptools3 for now then. | 20:12 |
| rburton | feel free to write a class for the toml stuff | 20:25 |
| rburton | the sooner someone starts a class the sooner its supported | 20:25 |
| RP | vdl: I suspect someone will write a class and then we'll migrate over as newer releases come out as we're doing with meson for example | 20:29 |
| rburton | vdl: isn't setuptools mostly merged into distutils these days? | 20:32 |
| rburton | i admit i don't use it that heavoy | 20:32 |
| rburton | erm, heavily | 20:32 |
| savolla | hey guys what is the most reliable distro for yocto? I'm having troubles on manjaro as my host. I want to pull a docker image and build there | 20:39 |
| savolla | they say ubuntu is the most stable one but which version? | 20:40 |
| felix_inst | savolla, I had good luck with Ubuntu 18.04 | 20:40 |
| savolla | oh thanks! | 20:40 |
| felix_inst | depends on the poky version you want | 20:40 |
| savolla | felix_inst: I want to build for bbb | 20:40 |
| savolla | this is my first experience with yocto | 20:40 |
| felix_inst | savolla, I used 18.04 with zeus. 20.04 would not work. dunfell may be the other way around | 20:41 |
| savolla | zeus and dunfell. they are yocto releases right? | 20:41 |
| savolla | branches sorry | 20:42 |
| Crofton|cloud | savolla: also look at pyrex | 20:42 |
| felix_inst | zeus is 3.0.x | 20:42 |
| Crofton|cloud | https://github.com/garmin/pyrex | 20:43 |
| felix_inst | dunfell appears to be 3.1.x | 20:43 |
| savolla | guys I really don't understand the yocto terminology yet. those are yocto branches? which we specify with -b option while cloning? | 20:43 |
| felix_inst | the last argument is the branch. the -b flag just makes you create a local branch at checkout | 20:44 |
| felix_inst | it's a git thing | 20:44 |
| savolla | I looked at yocto reference but it is very long and I don't have the time at the moment. but deffinitely will read the manual later. maybe you guys can guide me to build a minimal image for bbb | 20:45 |
| felix_inst | savolla, I am pretty much in the same boat. So I don't know how to help you there. I would imaging BBB has a quickstart tutorial | 20:46 |
| *** bps <bps!~bps@80.71.142.18> has quit IRC | 20:47 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 20:48 | |
| denix | savolla: dunfell 3.1 is the current yocto LTS release. many yocto layers have separate branches specific to the release. https://wiki.yoctoproject.org/wiki/Releases | 20:52 |
| savolla | thanks anyway felix_inst . I also need to make a Qt application for bbb which displays some sensor information. I tryed to cross compile my application with qtcreator but didn't work. so someone told me that I need to create an image with yocto first. I really don't know if this is true. I'm asking you guys now | 20:53 |
| savolla | denix: oh thank you! | 20:53 |
| savolla | I get it now | 20:53 |
| *** richbridger <richbridger!~richbridg@089144195136.atnat0004.highway.a1.net> has joined #yocto | 20:57 | |
| felix_inst | savolla, there is a qt layer - and you should be able to generate the cross compiler toolchain after the main build | 20:58 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:03 | |
| savolla | felix_inst: really? that is really cool then.. where can I get that layer? | 21:05 |
| savolla | I just started with yocto and watching this tutorial https://www.youtube.com/watch?v=MKpLQ2bGsAk . sorry for my annoying questions again | 21:06 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:06 | |
| felix_inst | savolla, I have not used it myself, so take it with a grain of salt. This is the layer I *think* might be useful: https://github.com/meta-qt5/meta-qt5 | 21:09 |
| savolla | felix_inst: thank you so much! I'll definitely try it. | 21:11 |
| felix_inst | savolla, yw, I hope that's what you need | 21:12 |
| *** berton <berton!~user@200-180-244-11.user3p.brasiltelecom.net.br> has quit IRC | 21:15 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:15 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-63-48-72.static.zebra.lt> has joined #yocto | 21:16 | |
| renegade | savolla you will need to pull in meta-qt build your app. The recipe should include inherit qmake5 if you are using qmake. You can then also build the SDK which you can integrate with qt creator to cross compile and deploy to your machine | 21:17 |
| *** mansi <mansi!~mansi@h-154-99.A246.priv.bahnhof.se> has joined #yocto | 21:17 | |
| *** sbach <sbach!~sbachmatr@192.184.90.156> has quit IRC | 21:18 | |
| *** vineela <vineela!vtummala@nat/intel/x-xterpqdhqhxoklew> has quit IRC | 21:18 | |
| *** sbach <sbach!~sbachmatr@192.184.90.156> has joined #yocto | 21:18 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:18 | |
| savolla | renegade: yeah this is exactly what I was planning for :) thank you | 21:19 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-63-48-72.static.zebra.lt> has quit IRC | 21:21 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:24 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:28 | |
| *** karlyeurl <karlyeurl!~Karlssel@2001:41d0:8:9a4b::1> has joined #yocto | 21:28 | |
| *** karlyeurl <karlyeurl!~Karlssel@2001:41d0:8:9a4b::1> has quit IRC | 21:32 | |
| moto-timo | vdl: smurray: oe-core currently only supports setuptools and distutils. When we last started looking at new packaging methods, upstream wasn't ready yet. I forget the details. It's worth another look, but any new bbclass should really be landing in oe-core first IMHO. | 21:32 |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 21:33 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:34 | |
| moto-timo | vdl: smurray: I'm more interested in a common ptest-pytest class for my own development at the moment. | 21:34 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:38 | |
| *** savolla <savolla!~savolla@95.10.206.84> has quit IRC | 21:41 | |
| *** karlyeurl <karlyeurl!~Karlssel@2001:41d0:8:9a4b::1> has joined #yocto | 21:47 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-63-48-72.static.zebra.lt> has joined #yocto | 21:48 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has quit IRC | 21:48 | |
| *** vineela <vineela!vtummala@nat/intel/x-gnsmbbtsehajoupa> has joined #yocto | 21:49 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-63-48-72.static.zebra.lt> has quit IRC | 21:52 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 22:03 | |
| *** mansi <mansi!~mansi@h-154-99.A246.priv.bahnhof.se> has quit IRC | 22:06 | |
| *** mansi <mansi!~mansi@h-154-99.A246.priv.bahnhof.se> has joined #yocto | 22:14 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 22:14 | |
| *** renegade <renegade!~renegade@2601:241:8a00:46e0:3842:5e5:ecdd:1fd0> has quit IRC | 22:14 | |
| *** diego_r <diego_r!~diego@dynamic-adsl-84-221-249-106.clienti.tiscali.it> has quit IRC | 22:22 | |
| *** Yumasi <Yumasi!~guillaume@static-176-175-104-214.ftth.abo.bbox.fr> has quit IRC | 22:33 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:f25b:aad3:93:ea00> has quit IRC | 22:50 | |
| *** agust <agust!~agust@pd95f1388.dip0.t-ipconnect.de> has quit IRC | 22:52 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-61-64.ssp.dialog.net.pl> has quit IRC | 22:58 | |
| *** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has joined #yocto | 23:03 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.128> has quit IRC | 23:03 | |
| *** Gaffel <Gaffel!~gaffel@h-170-170.A1405.priv.bahnhof.se> has quit IRC | 23:14 | |
| *** vineela <vineela!vtummala@nat/intel/x-gnsmbbtsehajoupa> has quit IRC | 23:24 | |
| *** oberstet_ <oberstet_!~oberstet@213.170.219.39> has joined #yocto | 23:32 | |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has quit IRC | 23:34 | |
| *** vineela <vineela!vtummala@nat/intel/x-wqbqhugetegeewps> has joined #yocto | 23:47 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-63-48-72.static.zebra.lt> has joined #yocto | 23:49 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-63-48-72.static.zebra.lt> has quit IRC | 23:53 | |
| *** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has quit IRC | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!