Thursday, 2023-05-25

*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto00:07
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:17
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)00:20
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 256 seconds)01:04
*** davidinux <davidinux!~davidinux@> has joined #yocto01:06
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving)01:20
*** starblue <starblue!> has quit IRC (Ping timeout: 268 seconds)01:35
*** starblue <starblue!> has joined #yocto01:37
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 240 seconds)02:10
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)02:17
*** sakoman <sakoman!> has joined #yocto02:33
*** jclsn <jclsn!~jclsn@2a04:4540:653f:4700:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 265 seconds)02:48
*** jclsn <jclsn!~jclsn@2a04:4540:6520:3d00:2ce:39ff:fecf:efcd> has joined #yocto02:50
*** rfs613 <rfs613!> has quit IRC (Ping timeout: 240 seconds)02:51
*** rfs613 <rfs613!> has joined #yocto02:54
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection)03:27
*** nerdboy <nerdboy!~nerdboy@> has joined #yocto03:27
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto03:36
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection)03:38
*** nerdboy <nerdboy!~nerdboy@> has joined #yocto03:44
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto04:07
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 268 seconds)04:53
*** davidinux <davidinux!~davidinux@> has joined #yocto04:55
*** vladest <vladest!> has joined #yocto04:56
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)05:10
*** xmn <xmn!> has quit IRC (Ping timeout: 268 seconds)05:36
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:43
*** rob_w <rob_w!~rob@2001:a61:6012:6901:4487:d0d2:ab75:244c> has joined #yocto05:50
*** prabhakarlad <prabhakarlad!> has joined #yocto06:13
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Remote host closed the connection)06:13
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:14
*** mckoan|away is now known as mckoan06:48
mckoangood morning06:48
*** frieder <frieder!> has joined #yocto06:51
RPkhem: awesome, thanks!07:00
*** zpfvo <zpfvo!> has joined #yocto07:09
*** xantoz <xantoz!> has quit IRC (Read error: Connection reset by peer)07:27
*** vladest <vladest!> has quit IRC (Remote host closed the connection)07:30
*** vladest <vladest!~Thunderbi@2a02:1210:760b:9500:9c0b:172e:d38b:ea5> has joined #yocto07:31
*** thomasd13 <thomasd13!> has joined #yocto07:37
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)07:39
*** prabhakarlad <prabhakarlad!> has joined #yocto07:42
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto07:51
LetoThe2ndyo dudX08:06
*** alex88 <alex88!~alex88@user/alex88> has quit IRC (Ping timeout: 260 seconds)08:10
*** alex88 <alex88!~alex88@user/alex88> has joined #yocto08:11
mckoanLetoThe2nd: hey!08:15
*** seninha <seninha!~seninha@user/seninha> has joined #yocto08:25
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)08:26
*** seninha <seninha!~seninha@user/seninha> has joined #yocto08:26
*** Guest65 <Guest65!> has joined #yocto08:34
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:36
Guest65Hi! I have a SRCREV question. The recipe fetches from an upstream git repo. After that 1 patch is applied. When checking with devtool modify xxx, the original git repo + 1 patch is applied (branch devtool). When I use SRCREV="${AUTOREV}" it works, but because it is not recommended I try with SRCREV="<upstream SHA1>". Then I get "basehash is not08:42
Guest65deterministic"-errors. If I try with SRCREV="<devtooled SHA1>", I also get basehash and/or fetch issues. What have I misunderstood?08:42
*** ptsneves <ptsneves!> has joined #yocto08:42
qschulzGuest65: are you pasting all 40 characters in SRCREV?08:44
qschulzalso no leading nor trailing space?08:44
Guest65Yes, e.g. SRCREV = "0bf86d03592f8ee6139559f0977df16a27d835ea"08:45
qschulzGuest65: mmm would you be able to share the recipe in a pastebin somewhere?08:47
qschulzwhat's PV set to for example?08:47
Guest65PV = "1.0+git${SRCPV}"08:47
qschulzfirst time I see the not deterministic error, usually it's written as "basehash mismatch| or something like that08:47
Guest65So it should work? I might have done something in the wrong order08:49
rburtonshare the recipe if you can, sounds like something went wrong. a recipe with a patch should work obviously :)08:51
Guest65I was just able to build if I started doing :08:51
Guest65bitbake -c cleanall -c cleanssate xxx08:51
Guest65<edit recipe with SHA1_upstream>08:51
Guest65bitbake xxx08:51
rburtonfwiw cleanall/cleansstate are almost never needed, don't use them08:51
qschulzGuest65: mmm any chance you still had devtool'ed recipe in your workspace? since it is a bbappend applied on top of the recipe in your layers, maybe it messed up something?08:53
qschulzbut yes, if you need cleanall/cleansstate to fix something, that recipe is seriously broken :)08:53
Guest65I better share it... I nee to google pastebin first :-)08:53
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 256 seconds)08:54
Guest65devtool status does not mention lsdbus (xxx)08:59
Guest65It's an old yocto version - hardknott09:00
qschulzGuest65: am not so sure about name=lsdbus in SRC_URI09:02
qschulzI think this may require SRCREV[lsdbus] = "<sha>"09:02
qschulzalso not sure about the use of SRCPV when one's not using AUTOREV mechanism09:02
Guest65qschulz thank you for the advice. I'll try without them09:05
*** berton[m] <berton[m]!~berton@2001:470:69fc:105::ce36> has quit IRC (Remote host closed the connection)09:07
TRO[m]FYI: Demo - how to build, run EC2 AMI images easy with meta-aws:
TRO[m](that feature:
michaelorburton: thanks for the patch!09:20
Entei[m]I am trying to build a container with podman build on yocto, getting this error... (full message at <>)09:36
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 265 seconds)09:41
*** kalj <kalj!> has joined #yocto09:48
*** thomasd13 <thomasd13!> has quit IRC (Remote host closed the connection)09:53
*** starblue <starblue!> has quit IRC (Ping timeout: 240 seconds)09:54
*** zpfvo <zpfvo!> has joined #yocto09:56
*** starblue <starblue!> has joined #yocto09:56
rburtonGuest65: you won't need FILESEXTRAPATHS to be set but there's nothing in there that looks wrong. i'd check your workspace/ for anything like a lsdbus%.bbappend which might be changing the recipe10:03
rburtonTRO[m]: nice!10:03
rburtonEntei[m]: what are you trying to do?  what bit is yocto?10:04
*** goliath <goliath!~goliath@user/goliath> has joined #yocto10:05
*** car1t <car1t!> has joined #yocto10:18
*** mckoan is now known as mckoan|away10:21
*** car1t <car1t!> has quit IRC (Quit: leaving)10:26
*** car1t <car1t!> has joined #yocto10:27
*** seninha <seninha!~seninha@user/seninha> has joined #yocto10:33
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)10:55
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 240 seconds)10:59
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 264 seconds)11:03
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto11:07
*** kpo_ <kpo_!> has quit IRC (Ping timeout: 264 seconds)11:09
*** d-s-e <d-s-e!> has joined #yocto11:16
*** lars <lars!~lars@> has joined #yocto11:40
*** lars is now known as Guest537911:40
Guest5379Hello, I have for some reason trouble getting a clean fresh clone of poky kirkstone to build. Cmake-native fails and claims that g++ does not support C++11 and the specified C++ flags. Any ideas? My gcc is 13.1.1 so it should be new enough to build cmake11:43
Guest5379I have done absolutely nothing to the repo after I cloned it, there are no local modifications11:44
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)12:02
RPGuest5379: which host OS are you using? Something new?12:08
RPGuest5379: well, since you say gcc 13 it has to be. Things don't work on gcc13 yet out the box12:09
Guest5379I'm on Arch12:10
Guest5379When you say things don't work "out of the box" yet, does that imply that there is something I can do to make it work?12:11
RPGuest5379: disable uninative12:11
Guest5379How do I do that?12:11
RPguessing you have meta-poky/conf/distro/poky.conf:INHERIT += "uninative" ?12:12
RPdisable that12:12
*** gsalazar <gsalazar!> has joined #yocto12:13
Guest5379Seems to be working. Thanks12:17
Guest5379Are there any side effects of doing this that I should be aware of?12:18
RPGuest5379: sstate isn't sharable between different machines12:18
Guest5379Okay, I can live with that12:19
*** kalj <kalj!> has quit IRC (Quit: Client closed)12:22
*** gsalazar <gsalazar!> has quit IRC (Remote host closed the connection)12:25
*** kpo_ <kpo_!> has joined #yocto12:26
*** Zaid <Zaid!~Zaid@> has joined #yocto12:32
RPabelloni: is your gcc 13 branch somewhere?12:33
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 256 seconds)12:33
*** nemik <nemik!~nemik@> has joined #yocto12:34
Guest65rburton there's an lsdbus%.bbappend that reference the patch-file.12:37
Guest65SRC_URI += " file://0001-New-bus-method.patch"12:37
Guest65I removed name=lsdbus;, use SRCREV="<upstream_SHA1>" and it worked as I wanted .The patch was applied (as you all said).12:37
Guest65So now everything is working as I wanted it to.12:37
Entei[m]<rburton> "Entei: what are you trying to do..." <- The bit where I am not sure what I am doing wrong...sorry. How do I get podman working on yocto?12:37
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)12:38
*** goliath <goliath!~goliath@user/goliath> has joined #yocto12:38
*** nemik <nemik!~nemik@> has joined #yocto12:39
rburtondo you mean "i've built an image with yocto and i want to use podman in it"12:40
rburtonin that case, you need to install the fuse kernel module, like the error says12:40
Guest65I do not understand why I've had so many issues with "basehash".In my conf/local.conf I have INHERIT += "rm_work" and I had BB_SERVER_TIMEOUT = "3600".12:41
Guest65Sometimes I feel a bit uncertain if those two cause extra issues.12:41
rburtonthat server timeout is quite high, i just use a minute. but rm_work is definitely safe.12:41
Entei[m]rburton: I don't have much knowledge of this particular thing tbh. Is fuse just supposed to be package or I have to edit my Kconfig to enable it?12:44
Entei[m] 12:44
*** jetm <jetm!~quassel@> has joined #yocto12:44
Guest65Great. My disk space is limited. I was desperate to shorten the time of recipe parsing, but after getting rid of the AUTOREV's, it's fast enough (y)12:44
rburtonEntei[m]: make sure your kernel config actually enables fuse, and then ensure you actually install the kernel-module-fuse packages into the image.  you can install _every_ kernel module build by adding 'kernel-modules' to the image if you want.12:45
*** camus <camus!~Instantbi@> has joined #yocto12:46
Entei[m]rburton: I see. I'll try it out. Thanks12:47
rburtonEntei[m]: feel free to send a patch to the podman recipe if you found more module depends, it lists a few already12:47
Entei[m]Will do as soon as I get it working12:48
RPabelloni: found khem's patches on his branch12:54
abelloniah sorry, I wasn't paying attention here12:54
abelloniI can push a branch if required12:54
RPabelloni: I think master-next should be ok now12:55
*** jetm <jetm!~quassel@> has quit IRC (Quit: - Chat comfortably. Anywhere.)12:58
*** Guest98 <Guest98!~Guest98@> has joined #yocto13:07
*** rfs613 <rfs613!> has quit IRC (Ping timeout: 248 seconds)13:13
*** xmn <xmn!> has joined #yocto13:15
*** rfs613 <rfs613!> has joined #yocto13:15
*** Guest98 <Guest98!~Guest98@> has quit IRC (Quit: Client closed)13:15
*** Guest65 <Guest65!> has quit IRC (Quit: Client closed)13:17
*** jetm <jetm!> has joined #yocto13:30
*** sakoman <sakoman!> has joined #yocto13:47
mcfriskwhat is the yocto way of enabling kernel features like seccomp, CONFIG_SECCOMP? DISTRO_FEATURE enables the support in userspace, but not kernel. Then default linux-yocto kmeta has broken config file for seccomp, or it looks like that to me. A custom config fragment in my layer to enable CONFIG_SECCOMP=y to linux-yocto, in our layer?13:51
*** bunk <bunk!~bunk@debian/bunk> has joined #yocto14:00
rburtonmcfrisk: fix the seccomp file if its broken, but yeah a custom fragment is the answer14:03
mcfriskrburton: ok, I think I could send the config fragment to oe-core and make it enabled on DISTRO_FEATURE seccomp14:05
*** Zaid <Zaid!~Zaid@> has quit IRC (Quit: Client closed)14:08
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:24
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:24
*** d-s-e <d-s-e!> has quit IRC (Ping timeout: 265 seconds)14:24
*** kscherer <kscherer!> has joined #yocto14:25
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 240 seconds)14:27
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:29
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:30
*** zpfvo <zpfvo!> has joined #yocto14:30
jboHey guys, the WIC I'm currently getting out of bitbake has two partitions as usual. I'm trying to figure out how I could add a 3rd partition for on-device data storage. However, I'm struggling figuring out what the minimal setup would look like by reading the docs. could somebody point me towards the right direction? I'd just like a 3rd partition which will be empty in the WIC so the device has something to store data on itself.14:52
rburtonmy understanding is you just define a new partition in the wic and don't tell it to fill it with an image14:53
JPEWjbo: I think adding a line like `part /userdata --size=1G --fstype=ext4 --label userdata` will do it14:54
jbothat would be more or less what I understood as well. However, I'm unclear what would need to happen in my custom layer to "automate" this14:54
JPEWjbo: The main key is to omit the `--source` option14:54
jboJPEW, that is good info, thanks!14:54
jborburton, yeah, I'd like to end up with a WIC which I can flash just like now (using dd).14:55
rburtonjust add that line to your wic and you're good14:55
jbothen I might be lacking the understanding of what "your wic" is.14:55
jboso far I just run bitbake and get a *.wic out of it :D14:55
rburtonthere is no implicit wic, but some BSPs have a default wic14:56
rburtonchange that, or write your own14:56
jborburton, when you're referring to "wic", is that a/the tool, the resulting image, some recipie, ... ?14:56
*** d-s-e <d-s-e!> has joined #yocto14:56
JPEWjbo: A .wic file14:57
JPEWjbo: Sorry .wks14:57
jboI'm using meta-atmel and there's one .wks in there:
jboso I guess this is the correct direction :)14:58
jbooh, and the machine config has WKS_FILE=14:58
JPEWjbo: Your image recipe keys off the WKS_FILES variable to know which .wks file to use to generate the disk image; you can double check which one it's using with `bitbake -e`14:58
jboJPEW, thanks! I used grep instead but I guess I should start using  bitbake -e  more when I try to figure out how things work14:59
JPEWRight. So you can modify the .wks file it's using, or write your own and change `WKS_FILES` to point to it14:59
jboI'll probably write my own as that seems more proper (correct me if I'm wrong). however, I don't have a custom machine config yet.14:59
JPEWYou probably want your own15:00
JPEWYou can also set it in your image recipe, if you already have a custom image recipe15:00
jboI do have that!15:00
jboI have custom image & distro stuff by now. I guess custom machine is the last thing missing :)15:01
JPEWjbo: Depends on what you are doing, but ya15:01
jboJPEW, well it's a custom board I designed so I think it's more than warrented. just didn't do that yet as I am completely new to yocto15:01
jbothanks for the information on the WKS file. that is exactly what I was looking for!15:01
JPEWjbo: We try not to use custom machines unless we are actually doing our own hardware, so for example when we do our build for a RPi4, we us the upstream machine15:02
JPEWjbo: Ya, if you have a custom board you should have a custom machine to match15:02
jboI'll digg into that now that I know that the hardware is actually working. I was struggling quite a bit with the audio codec I slapped on the board and the LTE modem. but I managed to finally get everything sorted out. kinda weird to have a rev 1.0 where everything is working :x15:03
JPEW_batman voice_: First try!15:04
*** jtoomey <jtoomey!~jtoomey@> has joined #yocto15:08
jboheh :)15:09
jbocertainly took me longer to understand some of the basic yocto concepts than to design & assemble the PCB15:10
LetoThe2ndjbo: eventually that will change. but also, eventually not.15:12
jboLetoThe2nd, as a C++ dev I am used to spending well over a decade on some tech and still feeling like I don't understand any of it :D15:16
*** kpo_ <kpo_!> has quit IRC (Ping timeout: 240 seconds)15:19
jboquestion regarding creating a custom machine conf: So far I have been using this:   in there, they  require/include  some other files. Can I just reuse those although they are in a different layer?15:25
jboor would I have to copy all those / copy-paste their contents into my custom machine config?15:25
LetoThe2ndjbo: you can require/include, it just needs the full path in the layer then, which is not the case if both files are in the same layer. then a relative path is fine.15:28
jboLetoThe2nd, is that a "traditional UNIX relative path" or is there some fancy syntax involved?15:28
LetoThe2ndjbo: now that you ask, i actually don't know if the ..  operator is supported.15:29
jbofor example, in my custom bblayers.conf.sample I have ##OEROOT## to reference some top level dir.15:29
JPEWjbo: bitbake searches BBPATH for relative include/requires, so `require conf/machine/include/` should work15:30
JPEWNo need to reference relative to OEROOT or the current file15:31
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)15:31
JPEWwell, as long as you use the correct file name, which my example did not :)15:31
jboI spotted that ;-)15:31
jboalright, now bitbake is complaining about my custom machine not being listed in COMPATIBLE_MACHINE for the kernel. The manual section 6.2 talks about that but I don't actually have a defconfig file. I do have a .cfg file where I set kernel specific configs tho.15:32
jbofrom manual section 6.2 it's unclear to me where COMPATIBLE_MACHINE would need to be specified.15:33
*** bunk <bunk!~bunk@debian/bunk> has quit IRC (Quit: leaving)15:33
JPEWIt's not uncommon for a BSP to use a bbappend to add to COMPATIBLE_MACHINES for upstream kernels...15:33
* JPEW finds an example15:33
JPEWIt looks weird to use the machine override to set it to the machine, but it keeps the layer "Yocto compatible" (e.g. it plays nice with other layers)15:35
jbowait... why is this:   COMPATIBLE_MACHINE:<machine>: "<machine>"  that seems weird  -  or is that exactly what you meant with "looks weird"? :D15:37
JPEWYa, thats what I mean15:37
JPEWThe naive (but still functional) way would be `COMPATIBLE_MACHINE += "<machine>"`15:38
JPEWBut that technically changes the parsing of the recipe for other machines, which is not "Yocto compatible"15:38
jbohmm. I see15:38
JPEW(There is a script you can run to check your layer for such things)15:39
jbowell, it seems like I need some extra steps in my setup. after adding that COMPATIBLE_MACHINE:custom = "custom" line the previous complains about the kernel are gone. However, now it's complaing about  "at91bootstrap was skipped: incompatible with machine synature (not in COMPATIBLE_MACHINE)"15:39
JPEWThe basic idea is that a layer should modify the parsing of any recipes it doesn't provide itself (e.g. in bbappends), unless the user opts into a machine or distro provided by that layer15:39
jboI tried adding a 2nd COMPATIBLE_MACHINE:custom = "at91bootstrap" but that didn't seem to be the way to go15:40
jboJPEW, that does seem reasonable15:40
JPEWProbably also need a bbappend for at91boostrap?15:40
jbowhy would I need a bbappend for at91bootstrap when I add a custom machine?15:40
jbooh, you mean just for the COMPATIBLE_MACHINE sake?15:41
JPEWYa, just like the kernel15:41
jboin situations like this right now, I find myself not knowing where that bbappend file would need to be located in my custom layer. how do I properly figure that out without guessing?15:42
JPEWMatch the same path as the original recipe, just in your layer15:43
jboso what I did now is grep the vendor's layer and deducing the path from that - that is the correct way of doing things?15:43
JPEWYa pretty much15:44
JPEW`find . -name 'at91bootstrap*'`15:44
jboalright, that got me further. now it complains about the same for  u-boot-at91  so I guess more of this :D15:45
paulganyone seen a systemd based initramfs/initrd .bb example before? (vs /init just being a quick-and-dirty script)?15:45
JPEWpaulg: Can you elaborate? We use systemd with a custom /init script; you just exec the systemd /init to have it take over when you are  done (same as sysvinit FWIW)15:46
JPEWjbo: COMPATIBLE_MACHINE actually matches anything in MACHINEOVERRIDES, so some recipes will be nice and be compatible with ${SOC_FAMILY) so you don't have to do that15:47
paulgJPEW, so it is a chicken and egg thing.  The systemd has its own parsing tool for setting up dm-verity stuff from bootargs.15:48
paulgbut that tool isn't available unless systemd and the assoc helper tools are in the initramfs.  Because they are in the dm-verity protected rootfs.  :(15:49
JPEWAh, you want an initrd with /init handled by systemd so it can setup the rootfs and chain to itself?15:49
JPEWpaulg: Ya, I think it supports that, but I've not done it before15:50
paulgyep - see bottom of page here -   apparently supported and recommended.15:50
paulgI'm just unsure if I'm brave enough to try going down that road...  vs. more manual setup steps in the shell variant of /init we (yocto) normally use with core-image-minimal15:52
JPEWpaulg: It actually looks pretty straight forward TBH; just make the initrd a normal image with systemd and it knows its in an initrd because of the /etc/initrd-release file15:53
JPEWAnd when you are done, run `systemctl switch-root`?15:53
paulgI've learned to never assume anything involving systemd will be easy or straight forward...15:53
RPrburton, jonmason: How painful will be ?15:53
jboJPEW, I got quite a bit further with this. but I am currently not understanding this bitbake error:   ERROR: at91bootstrap-4.0.6+gitAUTOINC+d166742ae1-r0 do_configure: No config files found   I created meta-custom/recipes-bsp/at91bootstrap/at91bootstrap_%.bbappend    which only contains  COMPATIBLE_MACHINE:custom = "custom"   is there some other magic missing I'm not yet familiar with?15:54
JPEWpaulg: It can be if you go off the rails of what they expect15:54
paulgI'll probably give it quick try, and if it all goes pear shaped, I'll simply walk away.15:54
JPEWjbo: Probably something with that specific recipe?15:54
JPEWjbo: Looks like it's expecting you to provide something for your machine (maybe some variable that says which config to use)? IDK much about that15:55
jonmasonRP: a quick/dirty look doesn't show anything actively using it.  let me try ripping it out and see who complains15:55
JPEWpaulg: Now that you pointed me here, I'm tempted to switch our initrd to use systemd :)15:56
paulgJPEW, heh. Wasn't my intention of course.15:59
*** zpfvo <zpfvo!> has quit IRC (Quit: Leaving.)16:03
jboJPEW, thanks for mentioning that. I digged around and spotted a missing AT91BOOTSTRAP_CONFIG:custom  adding that got me a bit further :)16:09
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto16:16
*** ardo <ardo!> has quit IRC (Ping timeout: 264 seconds)16:35
*** car1t <car1t!> has quit IRC (Ping timeout: 240 seconds)16:40
*** rob_w <rob_w!~rob@2001:a61:6012:6901:4487:d0d2:ab75:244c> has quit IRC (Quit: Leaving)16:49
rburtonkhem: so networkmanager was broken before i touched it - it appears to depend on pygobject being on the host16:54
*** d-s-e <d-s-e!> has quit IRC (Quit: Konversation terminated!)17:01
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto17:03
*** florian__ <florian__!> has joined #yocto17:10
*** ardo <ardo!> has joined #yocto17:11
jboJPEW, so I made quite some progress on the custom machine config. But I've been stuck now for quite some time and don't know anymore what to check for. bitbake complains about not being able to complet  do_image_wic. It complains about  uboot.env  missing from the  build/tmp/  directory. any pointers on what to look for?17:14
*** frieder <frieder!> has quit IRC (Remote host closed the connection)17:18
*** ardo <ardo!> has quit IRC (Ping timeout: 240 seconds)17:19
JPEWjob: Check out WIC_DEPENDS17:20
JPEW^^ jbo17:20
jboJPEW, well, so far I just want to have a custom machine config which does exactly the same as the vendor provided one for their EVK so I just copied their machine config. In there there is this:  do_image_wic[depends] += "u-boot-at91:do_deploy"17:21
jbois that what you're referring to?17:22
*** ardo <ardo!> has joined #yocto17:23
*** kpo_ <kpo_!> has joined #yocto17:24
JPEWjbo: Ah, yes. Sorry17:35
*** kpo_ <kpo_!> has quit IRC (Ping timeout: 240 seconds)17:35
JPEW"A particular BSP" made a WIC_DEPENDS variable to encompass that :)17:36
jboJPEW, that would be  meta-atmel/recpies-bsp/u-boot/  I already created a   meta-custom/recipes-bsp/u-boot/u-boot-at91_%.bbappend  where I only added the COMPATIBLE_MACHINE:custom = "custom"  line to it. I fail at figuring out what else is necessary. I did a grep for  'WIC_DEPENDS'  within meta-atmel and nothing showed up. kinda out of ideas :(17:43
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Quit: Relax, its only ONES and ZEROS!)17:44
jboI've also searched the yocto documentation for WIC_DEPENDS (and out of desparation WKS_DEPENDS) and nothing showed up there either.17:44
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto17:44
JPEWjbo: It's do_image_wic[depends], I was mistaken17:45
jbothere are:  do_deploy()   in these:
jbobut in any case I don't know what I have to do in general tbh :D17:45
jboJPEW, well, the `do_image_wic[depends]`  line is in my custom machine config (copied from meta-atmel machine config):  do_image_wic[depends] += "u-boot-at91:do_deploy17:46
*** florian__ <florian__!> has quit IRC (Ping timeout: 240 seconds)17:56
jbomeh, I'll try again tomorrow.17:59
*** BWhitten <BWhitten!> has joined #yocto18:00
*** aardo <aardo!> has joined #yocto18:02
JPEWjbo: Not sure then, sorry18:04
*** ardo- <ardo-!> has joined #yocto18:05
*** ardo <ardo!> has quit IRC (Ping timeout: 240 seconds)18:05
*** aardo <aardo!> has quit IRC (Ping timeout: 240 seconds)18:07
*** zenstoic <zenstoic!> has joined #yocto18:26
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)18:27
*** seninha <seninha!~seninha@user/seninha> has joined #yocto18:27
*** florian__ <florian__!> has joined #yocto18:38
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 240 seconds)18:39
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)18:40
JPEWRP: Theory on the SPDX problems: Currently, SPDX documents are deployed to `${DEPLOY_DIR}/spdx/${MACHINE}/`, when perhaps they should be `${DEPLOY_DIR}/spdx/${PACKAGE_ARCH}/`; I think this would probably fix the multilib and SDK issues? The problem it introduces is that now do_create_spdx can't find another recipe's document because it doesn't know the ${PACKAGE_ARCH} for that recipe. Presumably this is a actually a solved problem somewhere18:52
JPEWthough because DEPENDS _does_ work so somehow it knows how to find the sysroot for a recipe without knowing it's exact ${PACKAGE_ARCH}... I can't quite figure out how though18:52
rburtonpkgdata probably knows18:59
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 246 seconds)19:06
*** car1t <car1t!> has joined #yocto19:22
*** vmeson <vmeson!> has quit IRC (Read error: Connection reset by peer)19:25
JPEWrburton: It does not19:25
JPEWPerhaps could though?19:25
*** vmeson <vmeson!> has joined #yocto19:30
*** kpo_ <kpo_!~kpo@> has joined #yocto19:34
JPEWmmm, pkgdata also doesn't appear to be defined for -native recipes19:35
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)19:44
RPJPEW: would SSTATE_PKGARCH be more appropriate?20:02
RPJPEW: the sstate code already has what I think might be needed here20:03
JPEWRP: the anon code that munges is based on inherits_class ?20:04
JPEW*munges is20:04
JPEW*munges it20:04
RPJPEW: yes. There is magic which allows it to look up the pkgarch of a dependency iirc20:04
RPdeep magic :/20:04
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto20:06
RPJPEW: yes, it isn't what I was thinking it does20:06
JPEWIt returns a datastore for the target recipe I think?20:07
JPEWwell.... target task20:07
RPJPEW: no, it can't do that20:08
RPJPEW: it can apply multilib overrides to an existing datastore20:08
JPEWAh, I see20:08
JPEWIt loops over all pacakges arches until it finds a matching manifest file... can it return the pkgarch for the manifest it found as well?20:09
RPJPEW: it is basically constructing a search path and it looks for the manifest through each in turn20:09
RPJPEW: we could certainly refactor things a little to do that20:09
JPEWOr factor that out to a new function would also work I think20:10
RPJPEW: right, that was what I was thinking20:10
RPThere is something nagging me that we could do this in a better way20:11
JPEWSeems like it should be possible20:11
JPEWDoes the MACHINE -> PACKAGE_ARCH seem like it is probably the issue in the first place though?20:12
RPJPEW: That was my conclusion last time I looked at this, yes20:12
RPJPEW: the other trick I'm thinking of is BB_HASHFILENAME (see sstate.bbclass)20:15
RPJPEW: currently it is just used by the scenequeue data but I'm wondering what if that was combined with the TASKDEPS structure20:15
RPJPEW: this is "hashfn" inside bitbake20:18
RPJPEW: I suspect if we add hashfn to build_taskdepdata() in then things might get a little easier all around20:19
*** kpo_ <kpo_!~kpo@> has quit IRC (Ping timeout: 240 seconds)20:21
*** kpo_ <kpo_!~kpo@> has joined #yocto20:54
*** kpo_ <kpo_!~kpo@> has quit IRC (Ping timeout: 268 seconds)21:05
*** zenstoic <zenstoic!> has quit IRC (Quit: Connection closed for inactivity)21:13
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 268 seconds)21:27
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto21:28
*** astlep55047 <astlep55047!> has joined #yocto21:30
*** ramok_ <ramok_!~komar@> has joined #yocto21:30
*** dlan_ <dlan_!~dennis@> has joined #yocto21:30
*** PobodysNerfect_ <PobodysNerfect_!~PobodysNe@> has joined #yocto21:31
*** mlaga97_ <mlaga97_!~quassel@user/mlaga97> has joined #yocto21:31
*** zeddiii <zeddiii!~zeddii@> has joined #yocto21:36
*** sakoman <sakoman!> has quit IRC (*.net *.split)21:37
*** astlep5504 <astlep5504!> has quit IRC (*.net *.split)21:37
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (*.net *.split)21:37
*** PobodysNerfect <PobodysNerfect!~PobodysNe@> has quit IRC (*.net *.split)21:37
*** Piraty <Piraty!~irc@user/piraty> has quit IRC (*.net *.split)21:37
*** RP <RP!> has quit IRC (*.net *.split)21:37
*** Estrella <Estrella!> has quit IRC (*.net *.split)21:37
*** louis_ <louis_!~louis@> has quit IRC (*.net *.split)21:37
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (*.net *.split)21:37
*** sugarbeet <sugarbeet!~barbas@> has quit IRC (*.net *.split)21:37
*** ramok <ramok!~komar@> has quit IRC (*.net *.split)21:37
*** zeddii <zeddii!~zeddii@> has quit IRC (*.net *.split)21:37
*** derRichard <derRichard!> has quit IRC (*.net *.split)21:37
*** mlaga97 <mlaga97!~quassel@user/mlaga97> has quit IRC (*.net *.split)21:37
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (*.net *.split)21:37
*** eLmankku_ <eLmankku_!> has quit IRC (*.net *.split)21:37
*** duncan^ <duncan^!> has quit IRC (*.net *.split)21:37
*** BWhitten <BWhitten!> has quit IRC (Ping timeout: 240 seconds)21:42
*** sakoman <sakoman!> has joined #yocto22:04
*** duncan^ <duncan^!> has joined #yocto22:04
*** Piraty <Piraty!~irc@user/piraty> has joined #yocto22:04
*** RP <RP!> has joined #yocto22:04
*** Estrella <Estrella!> has joined #yocto22:04
*** louis_ <louis_!~louis@> has joined #yocto22:04
*** sugarbeet <sugarbeet!~barbas@> has joined #yocto22:04
*** derRichard <derRichard!> has joined #yocto22:04
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto22:04
*** eLmankku_ <eLmankku_!> has joined #yocto22:04
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 265 seconds)22:09
*** ardo <ardo!> has joined #yocto22:13
*** ardo- <ardo-!> has quit IRC (Ping timeout: 268 seconds)22:14
*** florian__ <florian__!> has quit IRC (Ping timeout: 256 seconds)22:19
*** aardo <aardo!> has joined #yocto22:21
*** ardo <ardo!> has quit IRC (Ping timeout: 240 seconds)22:22
*** aardo <aardo!> has quit IRC (Ping timeout: 240 seconds)22:28
*** ardo <ardo!> has joined #yocto22:39
*** aardo <aardo!> has joined #yocto22:48
*** goliath <goliath!~goliath@user/goliath> has joined #yocto22:50
*** ardo <ardo!> has quit IRC (Ping timeout: 240 seconds)22:51
*** ardo <ardo!> has joined #yocto22:56
*** aardo <aardo!> has quit IRC (Ping timeout: 240 seconds)22:57
*** xmn <xmn!> has quit IRC (Ping timeout: 265 seconds)23:00
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)23:43
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto23:51
*** seninha <seninha!~seninha@user/seninha> has joined #yocto23:56
*** kpo_ <kpo_!> has joined #yocto23:57

Generated by 2.17.2 by Marius Gedminas - find it at!