Monday, 2022-01-17

*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 250 seconds)00:36
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)00:39
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Ping timeout: 240 seconds)01:29
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto01:31
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Ping timeout: 250 seconds)01:36
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto01:37
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Ping timeout: 250 seconds)01:41
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto01:42
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:44
*** camus <camus!~Instantbi@> has joined #yocto02:09
*** xmn <xmn!> has joined #yocto02:39
*** marka <marka!> has quit IRC (Quit: ZNC 1.8.2 -
*** geoff__ <geoff__!> has quit IRC (Quit: Leaving)03:20
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)03:28
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto03:28
*** xmn <xmn!> has quit IRC (Ping timeout: 240 seconds)03:44
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto04:55
*** wooosaiiii <wooosaiiii!> has quit IRC (Remote host closed the connection)05:01
*** wooosaii <wooosaii!> has quit IRC (Remote host closed the connection)05:01
*** wooosaiiii <wooosaiiii!> has joined #yocto05:02
*** wooosaii <wooosaii!> has joined #yocto05:02
*** marka <marka!> has joined #yocto05:05
*** amitk <amitk!~amit@> has joined #yocto05:22
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)05:24
*** goliath <goliath!~goliath@user/goliath> has joined #yocto05:29
*** ziga_ <ziga_!> has joined #yocto05:55
*** ziga_ <ziga_!> has quit IRC (Read error: Connection reset by peer)05:58
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto06:08
*** djsands <djsands!> has quit IRC (Quit: Client closed)06:23
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds)06:46
*** kroon <kroon!> has joined #yocto06:54
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:04
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)07:08
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto07:12
*** rob_w <rob_w!> has joined #yocto07:20
coldspark29[m]What is the difference between linux-imx and linux-fslc? It is not clear to me07:20
krooncoldspark29[m], check the SUMMARY/DESCRIPTION for the corresponding recipes07:30
coldspark29[m]So linux-fslc is community and linux-imx is from NXP. Does linux-fslc have graphics support?07:33
*** mckoan|away is now known as mckoan07:44
mckoangood morning07:45
mckoancoldspark29[m]: linux-fslc has graphics support as well07:47
mckoancoldspark29[m]: we usually use only linux-fslc07:48
mckoancoldspark29[m]: but actually depends on your vendor BSP07:48
coldspark29[m]We have our custom board based on an imx8mm07:49
*** kroon <kroon!> has quit IRC (Quit: Leaving)07:53
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:54
coldspark29[m]On gatesgarth we based it on the official imx8mm configuration and that worked07:55
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:59
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)08:08
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:08
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Quit: Leaving)08:12
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto08:12
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:16
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto08:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)08:22
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:23
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)08:27
*** dev1990 <dev1990!~dev@> has joined #yocto08:27
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:28
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:32
*** florian <florian!> has joined #yocto08:45
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)08:48
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:49
coldspark29[m]qschulz: Why does kas not automatically fetch new commits from the layers? I always have to delete the layer and run kas checkout again09:08
*** otavio_ <otavio_!> has joined #yocto09:10
*** otavio <otavio!> has quit IRC (Read error: Connection reset by peer)09:10
qschulzcoldspark29[m]: I don't have this problem as I use commit hashes and not branch names09:24
coldspark29[m]qschulz: I thought so. It is a pity that this isn't possible09:35
coldspark29[m]Does bitbake not support Gitlab btw? I am getting a fetcher failure, which I can't seem to solve09:36
qschulzbitbake perfectly supports gitlab09:37
qschulzwe need more info to be able to help09:37
coldspark29[m]I am getting a fetcher failure... (full message at
coldspark29[m]I do have the right ssh keys and can perfectly check it out manually09:41
coldspark29[m] * I am getting a fetcher failure... (full message at
coldspark29[m]First I was changing the @ from git@gitlab to git://gitlab, but I don't know what else to change09:43
coldspark29[m]I just exchanged the Gerrit repository with the one from Gitlab. That is all09:44
qschulzcoldspark29[m]: it's a slash and not a colon between the url and the repo IIRC09:47
qschulzbefore vti-basesystem09:47
coldspark29[m]I already tried that and in fact it isn't09:48
coldspark29[m]This is the link I get from Gitlab
coldspark29[m]when I click on clone and copy paste the link09:49
hmw[m]Hi, i think i mis somthing in my distro im getting no key input in the qt application ( qt.qpa.wayland: xkbcommon not available on this build, not performing key mapping)09:50
qschulzcoldspark29[m]: the URL you get from gitlab with ssh protocol is not the one you should put in SRC_URI09:51
qschulzReplace : by /09:51
coldspark29[m]I tried that and it doesn't work09:52
coldspark29[m]and bitbake should be able to use the one I get from Gitlab imo09:52
qschulzthat's not exactly the code Bitbake is using but it gives you a reason for that09:53
qschulzcoldspark29[m]: is your browser able to deal with that kind of URL?09:53
qschulzI don't think so, because it isn't a URL :)09:53
qschulz: usually splits domain name and port09:53
qschulzI'm not saying it cannot be done, I'm just explaining why it is currently like this (or at least the reason I see)09:54
coldspark29[m]qschulz: No, because the protocol is ssh09:54
coldspark29[m]I hear you but it still doesn't work with those fixes09:55
coldspark29[m]I tried everything. Exchanging @ for ://, : for / and removing the .git at the end09:55
qschulzcoldspark29[m]: are you building with kas-container?09:56
coldspark29[m]s/for/with/, s/for/with/09:56
coldspark29[m]No Pyrex09:56
coldspark29[m]But both have the same outcome09:56
qschulzgit://;protocol=ssh is what's it's suypposed to be09:57
qschulzyeah but they are building in a container09:57
*** frieder <frieder!> has joined #yocto09:58
qschulzso yourssh-agent needs to be running and passed to the container09:58
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)09:58
qschulzcoldspark29[m]: SSH_AUTH_SOCK09:58
qschulzenv variable that needs to be passed to Pyrex (see pyrex.ini I think)09:59
coldspark29[m]I already did that09:59
coldspark29[m]That was also necessary when the repo was still on Gerrit10:00
*** frieder <frieder!> has quit IRC (Remote host closed the connection)10:00
coldspark29[m]Ah actually no10:01
coldspark29[m]I was just binding the .ssh directory10:01
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:01
coldspark29[m]But well the same error occurs10:02
coldspark29[m]Just tried it10:02
qschulzotherwise, it seems you can enter the Pyrex container by running pyrex-shell and try git clone of your gitlab repo there just to make sure it isn't an issue with the keys10:02
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Remote host closed the connection)10:02
*** frieder <frieder!> has joined #yocto10:03
coldspark29[m]No issue there10:04
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection)10:05
qschulzwhat's your SRC_URI now?10:05
qschulzFYI, mounting .ssh in containers is not a good practice security wise10:07
qschulzhence the use of SSH_AUTH_SOCK instead10:07
qschulzwhich forwards the SSH agent without having the private key (and authorized_keys, known_hosts et al) in the container10:08
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto10:09
*** frieder <frieder!> has quit IRC (Remote host closed the connection)10:11
*** frieder <frieder!> has joined #yocto10:11
coldspark29[m]Do you just uncomment SSH_AUTH_SOCK?10:17
coldspark29[m]SRC_URI = "git://;protocol=ssh;branch=${SRCBRANCH}"10:18
coldspark29[m]coldspark29[m]: Yeah I guess...10:20
qschulzand envvars= I assume10:22
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto10:22
ad__hi, on dunfell, i cannot see separate rootfs files before the image is created. Is ther ean option to allow this ?10:24
qschulzand envsockproxy I assume coldspark29[m]10:31
qschulzad__: not sure to understand the question. What do  you want to do exactly?10:31
coldspark29[m]Yeah, it doesn't work. Maybe something is wrong with our local Gitlab server.10:37
qschulzcoldspark29[m]: which distribution are you using currently on your desktop/10:40
qschulzwhat I could suggest is to ditch pyrex for a moment and build directly from your system.10:41
qschulzby using master poky for example10:41
coldspark29[m]So use kas build?10:41
qschulzand just run bitbake -c fetch your-recipe10:41
qschulzuntil you get it working10:41
qschulzat least we'd know it's not something weird with bitbake+containers10:41
coldspark29[m]kas builds on the host, doesn't it?10:42
qschulzuse bitbake directly, i.e. source oe-init=build-env ../build from the poky git repo10:42
qschulzthe less tools in play, the better10:42
coldspark29[m]Same issue on the host10:44
coldspark29[m]It is not a Pyrex issue10:44
qschulzcoldspark29[m]: wait10:47
qschulzno I don't know10:49
coldspark29[m]Yeah me neither10:50
coldspark29[m]What an awful week already :D10:50
qschulzalso, not sure it's really worth putting a kernel behind ssh auth since it's all open-source but eh :)10:51
coldspark29[m]Yeah I know10:52
coldspark29[m]My colleague thinks it is easier to host the kernel ourselves and just commit our patches10:52
coldspark29[m]Plus they want to be able to build in case the network should be down10:53
coldspark29[m]Like that ever happens...10:53
* qschulz coughs upstream coughs the coughs patches10:53
*** kroon <kroon!> has joined #yocto10:53
ad__qschulz: in some yocto version i can see all the target rootfs files in a specific dictory, actually in this dunfell not. Maybe it get deleted after packing ext4 image ?10:53
qschulzbut yeah it's extremly common to have fork of the Linux kernel10:53
qschulzif the network being down is an issue, just host a PRE_MIRROR on your premises and you're done with this problem10:54
coldspark29[m]Which would fail in this case :P10:55
qschulzad__: do you have INHERIT rm_work in your local.conf? otherwise, I think it might be in tmp/work/<machine>/<image-name>10:55
qschulzcoldspark29[m]: what would fail?10:55
*** florian_kc <florian_kc!> has joined #yocto10:55
coldspark29[m]The PREMIRROR source10:56
coldspark29[m]Being our Gitlab server10:56
qschulzad__: yocto/build/tmp/work/puma_haikou-poky-linux/core-image-minimal/1.0-r0/rootfs is where's mine10:56
coldspark29[m]which is anger expressed in pre-emoji times10:57
qschulzcoldspark29[m]: no no no, the PREMIRROR is an HTTP server serving the tarball you have in your build/downloads10:57
qschulzand it'll ask this PREMIRROR server first before going for the upstream URL10:57
qschulzif your company is going to do a lot of CI, I would highly recmomend looking into hosting your own PREMIRROR and a SSTATE_MIRROR10:58
coldspark29[m]But you can't push to repos checked out with http10:58
qschulzcoldspark29[m]: yocto does not push to repo, it's read-only10:58
qschulzcontinuous intgegration10:58
coldspark29[m]Yeah, but first things first. I can't even build this bloody honister release10:59
qschulzbasically building automatically your images/distros for you (and ideally testing them right after)10:59
coldspark29[m]So frustrating10:59
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)11:03
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:03
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)11:08
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:08
*** pgowda_ <pgowda_!> has joined #yocto11:12
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)11:13
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:13
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)11:17
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:18
rburtonRP: vim and lighttpd cve fixes sent11:21
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)11:33
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:33
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 250 seconds)11:35
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)11:37
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:37
RPrburton: awesome, thanks :)11:46
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)11:57
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:57
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)12:02
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:02
rburtonzeddii: 99% sure you broke python3-dtc12:04
rburton(100% sure012:05
RPrburton: clearly we need better tests :/12:08
rburtonthe 'port to setuptools' result in do packaging happening12:08
coldspark29[m]@qschulz It is git://
coldspark29[m]It worked from the host like this12:09
coldspark29[m]Now that it has fetched, it doesn't fetch again. Is there a way to force the refetch to test it for Pyrex as well?12:10
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 250 seconds)12:11
*** camus1 <camus1!~Instantbi@> has joined #yocto12:12
*** davidinux <davidinux!~davidinux@> has quit IRC (Quit: WeeChat 2.8)12:13
*** camus1 is now known as camus12:14
coldspark29[m]I tried `clean` and `cleansstate` without success12:19
qschulzcoldspark29[m]: -c fetch -f (note that any task run with -f will require a cleansstate at one point int time)12:22
qschulzcoldspark29[m]: otherwise, -c cleanall IIRC12:22
coldspark29[m]Yep that worked12:28
coldspark29[m]and fetching only works if I bind the .ssh directory. SSH_AUTH_SOCK is not sufficient12:28
coldspark29[m]which is insecure you said12:29
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)12:31
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:32
*** davidinux <davidinux!~davidinux@> has joined #yocto12:35
*** otavio_ <otavio_!> has quit IRC (Remote host closed the connection)12:36
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)12:36
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:37
qschulzcoldspark29[m]: from within containers, run `ssh-add -l`. If a pubkey is not returned, you need to fiddle with things12:43
coldspark29[m]qschulz: That is too complicated. I will just bind the .ssh container from now. We are in our own network anyway and it is readonly12:44
coldspark29[m]Pyrex really loses its charm if you have to fiddle with things inside the container.12:45
coldspark29[m]Any other idea here @JPEW?12:48
coldspark29[m]s/Any other idea here @JPEW?/Any other idea here JPEW ?/12:48
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)12:53
*** otavio <otavio!> has joined #yocto12:55
*** Saur <Saur!> has joined #yocto12:56
qschulzcoldspark29[m]: mmmm, I did mount read-only ~/.ssh/known_hosts. I think otherwise it complains .ssh/known_hosts does not exist when trying to add your gitlab server to it. While when it's mounted RO, it just fails to write to it but does not fail the build. But that's very vague recollection from months ago12:58
qschulzI haven't used Pyrex for a while now12:58
*** oberonc <oberonc!> has joined #yocto12:58
qschulzalso, it's very likely your host distribution is compatible with honister branch. I am on fedora35 and I don't build inside container locally12:58
oberoncGםא איןד קררםר וגרןמע נןאנשלק:12:58
oberonckernel-image-bzimage-5.10.63-yocto-standard-5.10.63+git0+e0147386e9_c4f9e689da-r0.intel_x86_64: sha256 check failed: 6386446dea6133df79e77296ec5862eb2173735f6f3d3287711e26c3c37ebdc9 vs cecfb00ba16f5925ec58da8cf7e2e59e668015263fc696c72c71730a9cbcaaf712:59
oberoncPackage "kernel-image-bzimage-5.10.63-yocto-standard-5.10.63+git0+e0147386e9_c4f9e689da-r0.intel_x86_64" from local repository "oe-repo" has incorrect checksum12:59
oberoncError: Some packages from local repository have incorrect checksum12:59
oberonc-> Got this error during 'bitbake':12:59
oberoncsomething to do with the git repository ?12:59
oberonchow can I solve this ?13:00
coldspark29[m]qschulz: It is, but I don't like to see warnings13:00
qschulzyou can mount it read-write too if you want13:03
coldspark29[m]Yeah I guess13:04
*** gsalazar_ <gsalazar_!~gsalazar@> has joined #yocto13:24
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 240 seconds)13:26
zeddiirburton: hah. I had that same fix, but I was just switching to a new SRCREV to pick it up.13:34
rburtonthey need to get on and make a new release13:38
*** xmn <xmn!> has joined #yocto13:38
zeddiimaybe, the pypi stuff rob is doing is likely slowing things down.13:39
rburtonzeddii: how far are you bumping the SRCREV?13:41
rburtongo enough and they move to another directory and you'll have the same problem again13:41
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)13:41
zeddiito the tip. one from early jan, IIRC. I was adapting to it over the weekend, when I did a build on a new machine and my old dtc wasn't around to save the day.13:41
zeddiinot sure what happened on my main builder, it is not taking 5 minutes to clean dtc so I can test.13:42
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:42
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)13:47
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:48
rburtonclean is overrated13:49
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto13:49
rburtoni have a mini script builddifftron, git checkout sha1 ; bitbake foo ; git checkout sha2; bitbake foo; buildhistory-diff.  Useful for stuff like 'builddifftron master featurebranch image-recipe'13:50
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)13:52
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:53
JPEWcoldspark29[m]: SSH_AUTH_SOCK is supposed to work, iirc, but we don't it's it so it's possible it got broken. We just bind in .ssh.13:55
JPEWHoliday here, so I'm afk and can't check right now13:55
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto13:57
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)13:57
RPwho is cancelling my builds on the autobuilder? :/13:57
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:58
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Remote host closed the connection)13:58
*** sakoman <sakoman!> has joined #yocto14:00
*** camus1 <camus1!~Instantbi@> has joined #yocto14:01
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)14:01
*** camus1 is now known as camus14:01
*** gsalazar_ is now known as gsalazar14:02
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Quit: Leaving)14:02
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto14:03
coldspark29[m]<JPEW> "Holiday here, so I'm afk and can..." <- Alright thank your for answering then. Enjoy your holidays!14:11
*** kroon <kroon!> has quit IRC (Quit: Leaving)14:12
coldspark29[m]Does anyone have an idea what this means? Corrupted sstate-cache? Has happened quite frequenctly lately... (full message at
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)14:13
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:14
*** codavi <codavi!~akiCA@user/akica> has joined #yocto14:15
coldspark29[m]Only solution is to delete the tmp directory and start over so far14:17
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds)14:18
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)14:18
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:18
*** jatedev <jatedev!~jatedev@> has joined #yocto14:19
rburtoncoldspark29[m]: is the sstate on a 'normal' filesystem?14:20
rburtonor are you doing something like having recipes with : in their name14:21
rburtona good start would be to catch the valueerror and print out f14:21
rburtonfigure out what the bad input is14:21
*** ilunev <ilunev!~koolkhel@> has joined #yocto14:21
coldspark29[m]rburton: Well, I am on honister so I was figuring this has something to do with the override syntax script I used. The one that you showed me14:22
coldspark29[m]rburton: How?14:22
coldspark29[m]-DDD ?14:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)14:23
coldspark29[m]The other weird thing is that there doesn't seem to be a pattern. You can run the command and build successfully the first time. Then when you run again, without having changed anything, this happens.14:23
coldspark29[m]So it's trying to split a filename by :14:27
coldspark29[m]Guess something went wrong porting to honister14:28
coldspark29[m]Or the sstate-cache from gatesgarth is not compatbile with the new syntax14:28
qschulzcoldspark29[m]: sstate-caches from different versions aren't mixed so that shouldn't be possible14:29
coldspark29[m]Okay, so I will hold back my delete impulse14:30
coldspark29[m]But how to debug this14:30
coldspark29[m]How can I catch the value it is processing14:31
qschulzyou add what rburton is suggesting in the python scripts of bitbake I assume14:31
rburtonyeah, find out what it is splitting14:32
*** alimon <alimon!~alimon@2806:10b7:3:1a01:2c32:cfff:fe8e:de1f> has joined #yocto14:33
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:35
coldspark29[m]Ah you mean just print the value. Sure14:37
coldspark29[m]The printed value doesn't land in the shell14:41
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)14:47
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:48
coldspark29[m]I am  going to delete everything now. This is too annoying14:48
kanavinRP: I guess it was me, they were hanging for something like 16 hours or more14:53
kanavinqemuarm-ltp is particularly not doing well lately14:53
kanavinthey were all almost complete, except for one hanging job14:55
RPkanavin: could you at least ask before you do that? We really need to go and debug these which is why I'd left it around14:57
kanavinI will, apologies. Typically no one pays attention to those and arm workers get blocked :-/14:58
RPkanavin: right, but someone needs to dive and and work out what the issue is :(14:59
kanavinRP: I have an update patchbomb upcoming, so if anything hangs there, I'll look at it.15:00
vdis it a bad idea to derive multiple distro configs (requiring a common one) to isolate build profiles, rather than managing and switching between multiple local.conf?15:00
kanavinthis should roll up our update backlog nicely15:00
qschulzvd: local.conf should be local to the dev/build machine. Typically variables such as SSTATE_DIR or DL_DIR in there for example. Ideally, it should be left untouched from the moment you source oe-init-buildenv. Might want to add DISTRO= and MACHINE= in it but I don't put anything else than the mentioned variables in local.conf15:02
*** Konsgn <Konsgn!~Konsgn@user/Konsgn> has joined #yocto15:02
rburtoncoldspark29[m]: bb.error() will write it to the console15:03
KonsgnHi All, How would one modify u-boot so it doesn't load the am335x-pocketbeagle.dtb file? I see the findfdt script, but not where in the u-boot it is instantiate15:04
Konsgnworking off of bbb-meta15:05
vdqschulz: here's my concern. I need multiple variants of my builds, developer, customer-branded, etc. The "classic" yocto way would be to set a few variables in the local.conf. But it seems messy when you need to build multiple variants like this at the same time. Having for example a foo-dev variant of the main distro seemed ideal so you could build a common image with MACHINE=bar15:06
kergothThat doesn't seem unreasonable15:08
qschulzyou probably would need to feedle with the default PACKAGE_ARCH value I guess15:09
qschulzeh, english's hard15:09
qschulzand make use of DISTROOVERRIDES mechanism too probably15:09
vdHaving multiple image can be an option too, but with complex images (like embedded images), it creates a lot of duplicate rather than relying on a fixed set of image names.15:09
qschulzbiggest benefit of using images instead of distros is that you can build them all at the same time with only one bitbake command15:10
*** rob_w <rob_w!> has quit IRC (Quit: Leaving)15:10
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)15:12
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:13
vdI guess I must try to make it work with multiple images and find a way to avoid too much duplication.15:14
kergothqschulz, vd: multiconfig is an option with multiple distros, though depending on the exactly configurations being changed you might also need to separate TMPDIR to be per-multiconfig15:14
kergothbut that would give you the single bitbake command15:15
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)15:17
qschulzkergoth: isn't it technically abusing multiconfig?15:18
vdkergoth: true. I dropped the idea of multiconfig because I figured out SSTATE wasn't shared between them and multiconfig even though they are a cool feature, must be ideally used only for embedded different config into one another. Abusing them only for parallel builds doesn't seem like a good idea15:18
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:18
kergothI don't believe that's the case, and the purpose is to build multiple configurations at once, how that's utilized is entirely up to you, i wouldn't consider using it to build multiple configs an abuse, that's literally the name :)15:19
kergothAlso some external tooling specifically utilizes it for multiple machines and config sets, see garmin's whisk for example (
*** leonanavi <leonanavi!~Leon@> has joined #yocto15:20
kergothNow whether it meets your particular needs is of course a different question, but I don't personally think it's out of scope15:21
kergothJust my opinion, of course.15:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)15:23
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Ping timeout: 256 seconds)15:23
*** ilunev <ilunev!~koolkhel@> has quit IRC (Quit: Textual IRC Client:
vdkergoth: I did believe that for a while. But what about the shared sstate? Isn't it limited with multiconfig?15:23
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:23
kergothI've seen shared state utilized across multiconfig boundaries, for example native recipes aren't rebuilt when switching from one multiconfig to another, even when they use different tmpdirs.15:25
vdhum ok15:25
vdkergoth: I think the "issue" here is that you may use yocto to simple build an image (or a few), or use it as a "build system framework" to set up a complex build-all-you-need system. The latter brings in the headache regarding multiple distros, tools managing local.conf fragments, many images, etc.15:27
vdTrying to keep things simple in this case is not that easy :-)15:27
*** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has joined #yocto15:28
kergothI think it's just that the situation *is* complecated, so using yocto to solve it also is :) But the fact that there isn't always a single best *way* to do it adds to confusion at times. The flexibility is both an asset and a liability :)15:29
vdkergoth: exactly.15:30
vdSo far I've figured out that the simpler the better, so I will try to stick with a single distro and multiple images, even though it duplicates a lot.15:32
qschulzwhat is duplicated?15:32
SaurWell, one image recipe can require another, so you might be able to have a base image recipe and then extend it into the actual image recipes you need.15:33
qschulzyou can also have classes inherited by image recipes15:33
qschulzbut as for all recipes, you cannot impact other recipes from your image recipe15:34
*** xmn <xmn!> has quit IRC (Ping timeout: 240 seconds)15:36
coldspark29[m]<rburton> "coldspark29: bb.error() will..." <- Thanks15:37
*** xmn <xmn!> has joined #yocto15:38
kayterina[m]hello. Are 10 minutes a logical time for parsing recipes in a project?15:38
qschulzkayterina[m]: it depends on the build machine and the number of recipes to parse15:39
kayterina[m]it is a big project I suppose, running in docker in wsl. ok.15:40
qschulzI've seen <insert very bad vendor> BSP layer take AGES to parse on a 32c machine15:40
SaurParsing our 4500 recipes takes 45 seconds on my machine (8 cores with HT)15:40
qschulzyeah 10min seems a lot but depends on the machine15:41
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto15:41
kayterina[m] i7-4600U CPU, with 8gb ram given to the wsl.15:42
qschulzalthough, parsing should get faster overtime since it's cached15:42
*** oberonc <oberonc!> has quit IRC (Quit: Client closed)15:43
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)15:46
rburtonmore ram would be nice, and worst case if the layer is using autorev or similar it will be doing network operations during the parse, which can really slow things down15:47
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:47
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)15:52
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:52
vdkergoth: qschulz: well quick shower and kergoth is right once again, multiconfigs aren't abusing the build system. In fact tools like kas wrapping local.conf fragments in yaml are. I can keep one distro, a fixed set of default images, and a few conf/multiconfig/<customerX>.conf files appending TMPDIR/DEPLOY_DIR with "/${BB_CURRENT_MC}" and including tweaks for branding.15:58
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Quit: Leaving)16:03
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)16:03
qschulzvd: I meant using multiconfig for building effectively multiple flavors of something for the same board. In my mind, multiconfig is for systems with two or more OS running on the same target16:04
qschulze.g. Cortex-A + Cortex-M16:04
*** zpfvo <zpfvo!~fvo@> has joined #yocto16:04
vdqschulz: true, but not necessarily16:06
vdI see it as a clean way to store fixed build configs, rather than documenting local.conf snippets in a README16:07
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)16:09
*** marc1 <marc1!> has quit IRC (Read error: Connection reset by peer)16:19
*** frieder <frieder!> has quit IRC (Remote host closed the connection)16:26
kergothI think both are viable use cases for it, but depends on your needs16:26
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)16:32
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)16:32
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)16:32
*** zpfvo <zpfvo!~fvo@> has joined #yocto16:33
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)16:37
*** jatedev <jatedev!~jatedev@> has quit IRC (Quit: Client closed)16:37
*** zpfvo <zpfvo!~fvo@> has joined #yocto16:37
rburtonhm sure i saw a function somewhere to map a path to a layer name16:40
*** prabhakarlad <prabhakarlad!> has joined #yocto16:40
kergothrburton: bb.utils.get_file_layer() will get the layer name for a file in a layer16:50
kergothI used to have a class which would set LAYERDIR_name for each layer that didn't do so in their layer.conf and then used get_file_layer() to get the LAYERDIR for the current recipe. Dropped it ages ago since id idn't need it anymore16:51
*** osama <osama!> has joined #yocto16:56
*** jatedev <jatedev!~jatedev@> has joined #yocto16:58
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)17:03
rburtonRP: what's the state of depending on py3.7 on the host? I can't remember if there is a distro still clinging to 3.6.17:07
rburton(which was EOL last month)17:08
RPrburton: I really don't remember17:20
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:23
*** xmn <xmn!> has quit IRC (Quit: xmn)17:24
vddid something change with the wic.vdmk image type?17:27
rburtonRP: me neither :(17:27
*** osama <osama!> has quit IRC (Ping timeout: 256 seconds)17:28
*** mckoan is now known as mckoan|away17:40
moto-timoRHEL 7.7 was still Python 3.6 at last17:41
Konsgnwhat is a series file?17:42
KonsgnPatch remove-redundant-yyloc-global.patch is already applied; check your series file..17:42
*** ziga_ <ziga_!> has joined #yocto18:10
ziga_How can I know which device tree files were used to create the final .dtb which is then included in the image?18:11
Konsgnyou can have many dtb's made at once, the loaded dtb then gets selected by your u-boot settings/enviroment18:12
Konsgnfirst place to look would be uEnv.txt18:13
ziga_In which folder inside the build directory would I find this? U-boots?18:14
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)18:15
alex88is there a way to have BUILD_ID increment on every build in os-release package? it seems the last time it changed the value is when I've I've changed the os-release.bbappend I have18:15
*** camus <camus!~Instantbi@> has joined #yocto18:15
Konsgnyou should be able to see dtb's in tmp/deploy/images/blah/ there you will find dtb's ... at least in my case.18:17
Konsgnthey also end up packaged into the root filesystem image in  the /boot/ directory... again... in my case18:17
*** huseyinkozan <huseyinkozan!~hk@> has quit IRC (Quit: Konversation terminated!)18:19
ziga_Thank you.18:19
Konsgnbtw, the u-boot enviroment has a really comfortable fdt tool to examine the loaded device tree18:21
Konsgnfdt info/ fdt print allow you to print out entries.18:21
*** rgov[m] <rgov[m]!~rgovmatri@2001:470:69fc:105::1:6c47> has joined #yocto18:27
rgov[m]I'm trying to debug a build failure when using KERNEL_DEVICETREE_BUNDLE = "1". I posted about it on Is anyone familiar with that?18:30
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)18:31
*** camus <camus!~Instantbi@> has joined #yocto18:31
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto18:32
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 240 seconds)18:35
alex88if I want to remove DATETIME in BUILD_ID[vardepsexclude] here, what's the syntax I should use?18:38
alex88I've tried BUILD_ID[vardepsexclude]:remove = "DATETIME" but it says ParseError18:38
kergothif they didn't use an intermediate variable you can't use :remove, as it doesn't work on flags18:39
kergothyou'd have to use anonymous python to remove it programmatically18:39
kergothpython () { d.setVarFlag('BUILD_ID', 'vardepsexclude', ' '.join(v for v in d.getVarFlag('BUILD_ID', 'vardepsexclude').split() if v != 'DATETIME')) } or so18:40
alex88oh ok got it, I'll se if I can get it to work, trying to just assign it to "" doesn't.. it says "The metadata is not deterministic and this needs to be fixed."18:40
alex88thanks a lot for the example!18:40
kergothIt's correct, trying to let the checksums include a date/timestamp is going to end in failure, as it'll change every time the recipe is parsed, and it's parsed more than once even in a single build18:41
kergothI'd suggest taking a step back to revisit the purpose18:41
alex88oh, ok, so it might be probably better to set the variable somewhere else18:42
kergothremoving it from vardepsexclude will also make that recipe rebuild itself every time you do a bitbake build18:43
*** leonanavi <leonanavi!~Leon@> has quit IRC (Quit: Leaving)18:43
alex88that's kind of what I want, because I want the os-release file to change on every build to include the build timestamp18:43
alex88to be able to keep track of what's in each release by knowing the build it comes from18:44
alex88unless there's a more "yocto-way" of doing so18:44
rburtonalex88: image-buildinfo18:45
alex88oh, ok, let me try that18:46
vmesonKonsgn: not sure if anyone already answered but a series file is a quilt term:
alex88there's no timestamp in that, but the git commit might be enough!18:52
*** florian_kc <florian_kc!> has joined #yocto18:53
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds)18:58
rgov[m]I want to add a function to execute after poky/meta/classes/kernel-uboot.bbclass's uboot_prep_kimage. Would it be correct to create a .bbappend file in my layer's recipes directory and write `uboot_prep_kimage_append () { ... }` ?18:59
alex88I've just copied that bbclass and added the timestamp myself, thanks!19:01
alex88nvm, timestamp isn't updated... :/19:05
Konsgnthanks vmeson19:18
*** jatedev <jatedev!~jatedev@> has quit IRC (Quit: Client closed)19:21
*** jatedev <jatedev!~jatedev@> has joined #yocto19:23
*** otavio <otavio!> has quit IRC (Remote host closed the connection)19:41
zeddiigrass was sticking out before this storm!19:43
zeddiiup arrow gone wrong!19:43
*** otavio <otavio!> has joined #yocto19:47
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)20:20
*** agrue <agrue!> has quit IRC (Quit: ZNC 1.7.5+deb4 -
*** agrue <agrue!> has joined #yocto20:25
alex88oh using the datetime from python works! finally20:26
*** marka <marka!> has quit IRC (Quit: ZNC 1.8.2 -
*** TundraMan <TundraMan!> has joined #yocto20:39
*** TundraMan <TundraMan!> has quit IRC (Remote host closed the connection)20:39
*** TundraMan <TundraMan!> has joined #yocto20:41
vdqschulz: multiconfigs are very slow though :)20:44
*** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)20:53
LetoThe2ndo dudX20:59
LetoThe2ndcan anybody give me a short rundown of this arm edk2 thing?21:00
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds)21:00
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)21:07
*** Guest68 <Guest68!> has joined #yocto21:08
Guest68Hello Everyone. Starting with Honister, I can't access the network from do_compile (for example, calling ping result in "ping: socket: Operation not permitted", of course, ping from the command line works correctly)21:10
vdhow can I print FILESEXTRAPATHS for recipe?21:10
rfs613vd: maybe with bitbake -e recipename | grep FILESEXTRAPATHS=21:25
rgov[m]I’m trying to build the kernel with the in-tree lpc32xx_defconfig (, so I set the variable KBUILD_DEFCONFIG = "lpc32xx_defconfig" .21:26
rgov[m]But I notice if I inspect my .config file after the fact, some of the settings didn’t make it over. Like CONFIG_ARCH_LPC32XX should definitely be set.21:26
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)21:26
rfs613rgov[m]: might be due to configuration fragments being added? Maybe check KCONFIG_MODE setting.21:27
*** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Remote host closed the connection)21:30
rgov[m]rfs613: The docs say "An “in-tree” defconfig file can be selected via the KBUILD_DEFCONFIG variable. KCONFIG_MODE does not need to be explicitly set." I do not set it anywhere.21:31
LetoThe2ndGuest68: why would you want to do that anyways? it's called do_compile, not do_network_stuff21:31
rburtonLetoThe2nd: quite a vague question. It’s UEFI firmware, for arm. Same as what runs on x86.21:32
Guest68LetoThe2nd: because the do_compile calls the dart compiler, which in turn, needs to download package from the net21:33
*** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto21:35
LetoThe2ndGuest68: well AFAIK yocto doesn't actively block network access unless you set BB_NO_NETWORK = "1" (or similar, not sure about the exact name), but random network accesses by random toolchains in random tasks are the blueprint of broken reproducibility, therefore discouraged21:35
LetoThe2ndrburton: so in th meta-arm context, its... a uefi firmware drop-in, and which is the first stage in bootloading? or not?21:36
*** florian_kc <florian_kc!> has joined #yocto21:37
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)21:38
*** prabhakarlad <prabhakarlad!> has joined #yocto21:41
rfs613rgov[m]: while the manual should be correct, I know that we had to set the MODE in our recipe, and it was related to getting the config to come out correctly. This was done a few years back and details are foggy.21:43
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto21:44
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 250 seconds)21:46
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Quit: Leaving)22:09
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:09
zeddiiit's better to just set it. That part of the manual hasn't been clear for years now, and this is the second time in a week I've had it mentioned.22:15
zeddiionce I get out from under a pile of other things, I plan to update the docs.22:15
*** xperia64 <xperia64!> has joined #yocto22:17
bluelightninganyone had an issue where bitbake sometimes waits forever after showing a parsing error instead of exiting? I'm debugging it now (on top of dunfell)22:41
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto22:48
RPbluelightning: that does sound familiar22:58
bluelightningnice, thanks - those do look like they might help23:00
RPbluelightning: could be something else but I think that is what was triggering my memory23:01
bluelightningshoot, for a moment I thought it had fixed it but then the hang reproduced again :/23:04
*** florian_kc <florian_kc!> has joined #yocto23:06
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)23:25
*** otavio <otavio!> has quit IRC (Ping timeout: 250 seconds)23:27
*** otavio <otavio!> has joined #yocto23:29
*** TundraMan <TundraMan!> has quit IRC (Quit: ZNC 1.8.2 -
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)23:33
*** marka <marka!> has joined #yocto23:37
*** paulg <paulg!> has quit IRC (Ping timeout: 240 seconds)23:40
*** paulg <paulg!> has joined #yocto23:41
rgov[m]The kernel image produced by Poky is much larger than the one I get if I just manually do a Linux build with `make intree_defconfig && make all` -- if I diff the .config files I see a couple options creeping in like CONFIG_NET_INGRESS=y. Where are these happening? Is there a diagnostic I can use to track them down?23:59

Generated by 2.17.2 by Marius Gedminas - find it at!