Wednesday, 2023-05-31

*** seninha_ <seninha_!~seninha@user/seninha> has quit IRC (Quit: Leaving)00:28
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)00:32
*** qschulz <qschulz!> has joined #yocto00:35
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 240 seconds)01:03
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:10
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto01:21
*** starblue <starblue!> has quit IRC (Ping timeout: 265 seconds)01:28
*** starblue <starblue!> has joined #yocto01:30
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)01:43
*** nemik <nemik!~nemik@> has joined #yocto01:43
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto01:44
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)01:48
*** nemik <nemik!~nemik@> has joined #yocto01:48
*** sakoman <sakoman!> has joined #yocto02:28
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 256 seconds)02:40
*** jclsn <jclsn!~jclsn@2a04:4540:652b:f400:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 250 seconds)02:41
*** jclsn <jclsn!~jclsn@2a04:4540:6509:100:2ce:39ff:fecf:efcd> has joined #yocto02:43
*** nerdboy <nerdboy!~nerdboy@> has joined #yocto02:53
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 240 seconds)03:46
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 250 seconds)04:05
*** camus <camus!~Instantbi@> has joined #yocto04:09
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 250 seconds)04:29
*** florian_kc <florian_kc!> has joined #yocto04:46
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:58
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has quit IRC (Ping timeout: 240 seconds)05:09
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto05:16
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:29
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)05:31
*** davidinux <davidinux!~davidinux@> has joined #yocto05:41
landgrafHi there. What the best way to redeploy artifacts in do_deploy() if they're changed? I have a recipe which produces boot.scr in do_compile and deploys it. However sometimes wrong (old) version is deployed. For example I've changed the source and proper artifact has been produced but the one which was redeployed (after -c clean)was outadated.  cleanall solved the issue but costed me 8 hours of not so05:51
landgrafmuch enjoyable debugging05:51
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)05:54
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:54
RPJPEW: Testing was interesting. Lots failed, is probably the simplest error message. It looks bad from the autobuilder but I think things are on the right track05:59
RPJPEW: too05:59
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto06:06
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)06:14
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:14
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)06:27
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:32
*** rob_w <rob_w!> has joined #yocto06:35
*** frieder <frieder!> has joined #yocto06:44
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto06:45
*** Ablu[m] is now known as Ablu06:51
*** Ablu <Ablu!~ablumatri@2001:470:69fc:105::2f63> has quit IRC (Remote host closed the connection)07:05
*** zpfvo <zpfvo!> has joined #yocto07:07
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:45
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)07:48
*** nemik <nemik!~nemik@> has joined #yocto07:48
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)07:54
*** nemik <nemik!~nemik@> has joined #yocto07:54
*** amitk_ <amitk_!~amit@> has joined #yocto07:54
*** florian_kc <florian_kc!> has joined #yocto07:59
*** OnkelUlla <OnkelUlla!> has quit IRC (Ping timeout: 250 seconds)08:17
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)08:21
*** OnkelUlla <OnkelUlla!> has joined #yocto08:40
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)08:49
*** nemik <nemik!~nemik@> has joined #yocto08:49
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 246 seconds)08:49
__adhi, is it possible to install 2 different versions of the same recipe ? as openssl 1.0.0 and 1.1.1 ?08:52
*** davidinux <davidinux!> has joined #yocto08:52
qschulz__ad: no08:52
__adok thanks08:52
qschulzyou would need to go with a trick around recipe renaming (e.g. we had libopenssl10 for some time I think)08:52
qschulzor use multilib as a horrible hack08:53
qschulzbut I would highly recommend figuring out how to make everything work with the same libs because it is a nightmare to manage :)08:53
__adqschulz: ok. i mainly have a propertary app that cannot easily be rebuilt over 1.1.108:54
__admaybe i could symlink ?08:54
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)08:54
__ad1.1.1 is safer, so would keep it in the system08:54
*** nemik <nemik!~nemik@> has joined #yocto08:55
qschulz__ad: everyting is bad with openssl1.08:58
qschulzas it's EOL in September IIRC08:58
*** davidinux <davidinux!> has quit IRC (Ping timeout: 240 seconds)08:59
qschulzI suspect openssl 1.1 and openssl 1.0 aren't compatible so the symlink wouldn't help08:59
*** davidinux <davidinux!~davidinux@> has joined #yocto08:59
__adugh :( thanks08:59
__adqschulz: i am in dunfell now, do you think is possible to move to openssl 3 staying in dunfell ?09:03
* qschulz shrugs09:04
qschulzThat would probably be a question for the LTS maintainer since this means we have components that cannot receive security fixes09:05
qschulzbut short answer is "everything is possible if you give it time"09:05
qschulzbut you'd need to replace openssl 1.1 recipe with openssl 3.0 and fix all the compilation issues09:06
__adok thanks09:06
qschulzyou could also migrate to kirkstone, which EoLs at the same time as Dunfell09:06
__adok, will see, thanks09:07
*** paulbarker <paulbarker!> has quit IRC (Quit: The Lounge -
*** paulbarker <paulbarker!> has joined #yocto09:15
*** bps <bps!> has joined #yocto09:16
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 265 seconds)09:36
RP__ad: someone could create a mixin layer for that...09:49
*** prabhakarlad <prabhakarlad!> has joined #yocto09:51
*** seninha <seninha!~seninha@user/seninha> has joined #yocto09:59
*** starblue <starblue!> has quit IRC (Ping timeout: 265 seconds)10:04
*** starblue <starblue!> has joined #yocto10:06
RPJPEW: I have a patch which helps the spdx failures FWIW10:20
landgrafI'm looking for a way of sharing patches between my layer and dynamic-layer (for linux-yocto and linux-raspberrypi recipes to be precise). Is it possible or it's better to just copy them over ?10:20
RPlandgraf: I'd have thought it might prove tricky to keep in sync since you don't control either of them :/10:21
landgrafFILESEXTRAPATHS:append  = "LAYERDIR/..." I guess?10:21
landgrafRP: I have control over patches and apply them in bbappends..10:22
landgrafso far so good except the fact I don't want to have two copies of them10:22
landgrafand I cannot put linux-raspberrypi.bbappend into main layer because it breaks other machines which don't need rpi layer10:23
*** hrberg <hrberg!> has joined #yocto10:24
RPlandgraf: you should be able to put a common path in both recipes10:27
landgrafRP: yes. Adding FILESEXTRAPATHS:prepend := "${LAYERDIR}/recipes-kernel/linux/files/xen_shared_memory/: into dynamic-layer recipe did the trick. Thank you.10:30
* landgraf spent few days of debugging of the issues caused by cheap ttl-usb adapter and burnt out :-/10:31
*** hrberg <hrberg!> has quit IRC (Read error: Connection reset by peer)10:33
RPlandgraf: doesn't sound good :/10:34
*** hrberg <hrberg!> has joined #yocto10:34
*** yannd <yannd!~yann@> has joined #yocto10:34
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)10:44
* mcfrisk also had test HW failing in the past weeks: at least one board and a bunch of SD cards triggered really odd userspace and tmpfs data corruption, turning all CI test runs red...10:44
*** nemik <nemik!~nemik@> has joined #yocto10:44
*** alessioigor <alessioigor!~alessioig@> has joined #yocto10:46
landgrafmcfrisk: in my case it was combined with few software issues and strict deadline, I started to think it's some sort of mystery (and blamed devicetree as usual). :-/10:48
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)10:48
*** nemik <nemik!~nemik@> has joined #yocto10:49
mcfriskyea, we also had SW issues to deal with at the same time, regressions in firmware and higher up kernel and userspace, flaky tests. Luckily no hard deadlines though. CI makes it impossible to hide these details, which is both good and bad10:52
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)10:54
mcfrisksome people want to avoid target HW and BSP SW stack issues completely and push for virtual validation. I think it's important to validate the real product, to not hide HW and BSP SW stack issues. I think both are needed when target is a realy physical product10:56
RPJPEW: I can fix the sdk pkgdata not found and hack around the world build issue, it looks like there is also some kind of race:
*** otavio_ <otavio_!> has quit IRC (Ping timeout: 240 seconds)10:59
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)11:01
*** alessioigor <alessioigor!~alessioig@> has joined #yocto11:01
tctHey guys, I'm using an existing recipe for SDL2. However, I need to apply a patch to the SDL2 source. How would one go about that properly?11:21
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 240 seconds)11:28
*** otavio <otavio!> has joined #yocto11:45
*** yannd <yannd!~yann@> has joined #yocto11:46
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)11:47
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)12:07
*** florian <florian!> has quit IRC (Ping timeout: 250 seconds)12:07
__adwhat recipe includes useradd command ?12:08
__adok, looks shadow-utils12:09
*** jtoomey <jtoomey!~jtoomey@> has quit IRC (Ping timeout: 240 seconds)12:10
__adright recipe seems shadow, but it's only native12:30
*** florian <florian!> has joined #yocto12:31
*** florian_kc <florian_kc!> has joined #yocto12:32
RPtct: add a patch to the recipe's SRC_URI ?12:33
tctRP, but then I'd have to modify the meta-oe recipe/repo :(12:43
RPtct: you can do it from a bbappend12:43
tctRP, oh... reasonable!12:43
tctthanks :)12:43
sudip__ad: you can use oe-pkgdata-util to find out, in my image it shows "shadow: /usr/sbin/useradd"13:03
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)13:03
*** nemik <nemik!~nemik@> has joined #yocto13:03
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto13:03
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)13:09
*** nemik <nemik!~nemik@> has joined #yocto13:09
*** otavio <otavio!> has quit IRC (Ping timeout: 240 seconds)13:11
*** otavio <otavio!> has joined #yocto13:11
*** otavio <otavio!> has quit IRC (Ping timeout: 250 seconds)13:17
*** otavio <otavio!> has joined #yocto13:18
RPJPEW: bitbake python3-bcrypt; bitbake python3-pycparser-native python3-cffi-native -c clean; bitbake python3-bcrypt -c create_spdx -f breaks13:29
JPEWRP: Cool, I'll try that13:30
JPEWRP: Where is your patch?13:34
RPJPEW: it is some kind of missing dependency, "bitbake python3-bcrypt -g" shows no dependency on python3-pycparser-native from bcrypt, only from cffi-native13:34
RPJPEW: master-next13:34
JPEWsdk pkgdata fixup?13:35
RPJPEW: yes, one second as I have another13:35
JPEWWhy is that necessary? Does the SDK not have pkgdata?13:35
RPJPEW: there are two locations, target and SDK13:35
RPJPEW: master-next now has "meta-world-pkgdata-Fix-for-create-spdx" (will be syncing to the mirrors)13:36
RPJPEW: it is a bit hacky but was the best solution I could find right now. I was curious what builds looked like with that "fixed"13:37
RPthe meta-world-pkgdata fix makes "bitbake world" work again when multilibs are enabled13:37
RPso then we're left with this weird sstate dependency issue13:37
JPEWOK. I'm running the bcrypt test now.... rust is building so... it will be a bit :)13:37
RPoh, and oe-selftest sstate sigs test failures13:37
RPJPEW: you could probably find a simpler example, that was just the one the autobuilder showed me :/13:38
*** sakoman <sakoman!> has joined #yocto13:48
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)13:49
RPJPEW: changing do_create_spdx[deptask] = "do_create_spdx" to do_create_spdx[recrdeptask] = "do_create_spdx" "fixes" it13:52
*** Xagen <Xagen!~Xagen@> has joined #yocto13:52
RPwhether that is the right thing or not, less sure13:52
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto13:53
JPEWRP: Why would it be in BB_TASKDEPDATA, but not run?13:54
*** xmn <xmn!> has joined #yocto13:54
JPEWHmm, `python3-pycparser-native` is a transitive dependency from `python3-cffi-native`; but I thought transtive dependencies didn't show up in BB_TASKDEPDATA?14:06
* JPEW is confused14:06
*** Xagen <Xagen!~Xagen@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)14:11
RPJPEW: if an sstate task runs, it is assumed that "covers" everything needed14:15
RPi.e. sstate task dependencies won't run if the sstate task runs14:15
JPEWSo is the assumption that python3-cffi-native:do_create_spdx "covers" python3-pycparser-native:do_create_spdx ?14:16
*** Xagen <Xagen!~Xagen@> has joined #yocto14:17
RPJPEW: yes. If you really want indirect dependencies, that is where recrdeptask comes into play14:18
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 250 seconds)14:19
RPJPEW: saying X uses Y-native to build. You don't want Y-native everytime you use X if it is just a build tool14:19
JPEWIs there a way to know python3-pycparser-native is transitive? I can just ignore it if I can know that because the SPDX relationship chain will still take it back there via python3-cffi-native14:19
JPEW(I didn't realize those transitive dependencies were in BB_TASKDEPDATA in the first place)14:20
RPJPEW: BB_TASKDEPDATA shows the complete dependency chain. It is up to the user of it to decide which dependencies make sense to them. You probably want to know if the task in question is an sstate one or not?14:26
JPEWRP: Hmm.... sort of I guess. I wouldn't want to filter on if sstate was ran because then the SPDX would be different  in different circumstances14:28
RPJPEW: right, you can't do that14:28
RPJPEW: can you assume the other create_spdx task would have the links needed in that document?14:29
JPEWPhilosphically speaking, I only _really_ need the direct dependencies because the relationship chains will eventually lead back to all of the transitive dependencies14:29
RPJPEW: that is what I was wondering14:29
JPEWBut if python3-pycparser-native didn't run, there will be a broken document chain, even if we only report the direct dependencies14:31
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:31
JPEWSo... may we need both a change to only report the direct dependencies and recrdeptask?14:31
RPJPEW: right, it would point at a document which isn't there. Which is why recrdeptask might be the correct thing to do?14:31
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:31
JPEWYa, I think so14:32
*** ajfriesen8 <ajfriesen8!> has quit IRC (Quit: The Lounge -
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:33
*** ajfriesen8 <ajfriesen8!> has joined #yocto14:37
*** kscherer <kscherer!> has joined #yocto14:39
RPJPEW: I'll try a new build, see if this narrows us down to a smaller set of issues14:41
*** vladest <vladest!> has quit IRC (Ping timeout: 250 seconds)14:41
JPEWYa, filter only direct dependencies is a good idea, but shouldn't affect the build errors14:42
JPEWRP: Something like maybe?14:42
RPJPEW: that looks horrible and I'm not sure it will work deterministically14:44
RPthe idea of direct is task dependent unfortunately :(14:44
RPthe staging and sstate code both have differing ideas of what "direct" is14:45
JPEWIs that why taskdepdata is calculated twice independently in the runqueue?14:46
RPJPEW: is basically a function deciding which dependencies it should follow and which it shouldn't14:46
RPJPEW: taskdepdata is calculated twice as there is the "setscene" context and the real task context iirc14:47
RPone is quite different as it is setscene task dependencies rather than task dependencies14:48
JPEWAh, but only relevent when restoring from sstate? So do_create_spdx never "sees" the setsecene one because if it's looking at it, it means the task is actually running14:51
RPJPEW: do_create_spdx_setscene would see the setscene one but that is just straight into the sstate code14:53
RPbut yes14:53
*** paulbarker <paulbarker!> has quit IRC (Quit: The Lounge -
*** paulbarker <paulbarker!> has joined #yocto14:55
RPJPEW: in the new build we still have with meta-aws, not looked at what might be special there14:58
JPEWSimilar problem maybe?15:03
JPEWIs the do_create_spdx in the recipe assumed to "cover" all the dependencies?15:04
JPEWCover all the recrdeptask of do_create_spdx that is15:04
JPEWAlso.... recrdeptask is for runtime dependencies which isn't the same as deptask for do_create_spdx15:06
JPEWrecrdeptask seems correct for do_create_runtime_spdx; it already does `do_create_runtime_spdx[rdeptask] = "do_create_spdx"`15:07
*** yannd <yannd!~yann@> has quit IRC (Read error: Connection reset by peer)15:08
RPJPEW: I think recrdeptask covers both build and runtime dependencies, the distinction doesn't make sense for rec deps iirc15:08
RPJPEW: the new build has lots of runtime task failures:
* RP stops that build15:10
JPEWYa, that one should also be changed to recrdeptask I tink15:10
JPEWDoes that mean all the runtime dependencies will be in BB_TASKDEPDATA for do_create_spdx also?15:12
JPEW(in addition to build time)15:12
RPJPEW: yes :/15:15
JPEWWell.... I guess no one will be able to claim our SPDX isn't through at least15:17
JPEWI'm sure there is a reason that recdeptask doesn't exist?15:18
*** Xagen <Xagen!~Xagen@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)15:18
*** Xagen <Xagen!~Xagen@> has joined #yocto15:19
*** yannd <yannd!~yann@> has joined #yocto15:22
*** PobodysNerfect <PobodysNerfect!~PobodysNe@> has quit IRC (Ping timeout: 240 seconds)15:26
tctis there a way to clean stuff from the build directory but ONLY stuff that is not used in the currently built image? I removed a distrofeature (x11) and would like to free up some disk space but don't feel like building everything from scratch again15:28
JPEWtct: If you keep sstate, things that don't need to rebuild will restore from that instead, which should be reasonbly fast15:28
tctJPEW, could you be a bit more specific? what does "keep sstate" mean?15:29
JPEWtct: The sstate directory where bitbake caches build output; I think it defaults to ${BUILDDIR}/sstate ?15:30
tctJPEW, so you'd recommend me to just delete everything in the build dir except for conf/ and sstate and then bitbake again?15:30
JPEWtct: I think if you only delete $BUILDDIR/tmp it will do what you want15:31
JPEWleave everything else15:31
RPJPEW: recdeptask doesn't make any sense when you look at the code15:32
tctJPEW, thanks!15:33
RPit did exist once, kind of15:33
tctJPEW, actually, I am not sure why mine is called  /build/tmp-glibc  ever since I moved to a custom distro15:33
RPJPEW: meta-aws was green this time15:33
JPEWRP: I can't quite see why it doesn't make sense.... similar to recrdeptask handling, but doesn't call add_runtime_dependencies()?15:37
*** PobodysNerfect <PobodysNerfect!~PobodysNe@> has joined #yocto15:41
RPJPEW: at every other level beyond the top level, the runtime pieces end up pulled in regardless15:42
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 240 seconds)15:42
RPJPEW: I'm fuzzy on the exact details now but it ended up not making much sense :/15:44
JPEWYa, the processing after that definitely is confusing so I can believe it does some stuff like that15:45
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:57
*** florian <florian!> has quit IRC (Ping timeout: 240 seconds)16:10
JPEWRP: Well.... I was hoping I could use the deps for the current task in BB_TASKDEPDATA to only transverse one level of task dependency data, but neither `do_create_spdx[deptask]` nor `do_create_spdx[recrdeptask]` actually cause the task depenencies in BB_TASKDEPDATA to change16:11
RPJPEW: they should!16:14
JPEWI though so too16:14
JPEWLet me see if it's user error16:14
RPJPEW: I just checked and you're right. It does add python3-pycparser-native to python3-bcrypt.do_create_runtime_spdx but not create_spdx16:16
JPEWdo_create_spdx[depends] is the culprit maybe?16:17
*** yannd <yannd!~yann@> has joined #yocto16:18
*** zpfvo <zpfvo!> has quit IRC (Remote host closed the connection)16:22
*** frieder <frieder!> has quit IRC (Remote host closed the connection)16:22
*** Guest58 <Guest58!> has joined #yocto16:22
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 250 seconds)16:23
JPEWAh, runqueue explicitly removes self-referential tasks (`recursivetaskselfref`) ?16:23
*** Guest58 <Guest58!> has quit IRC (Client Quit)16:23
*** MartinX <MartinX!> has joined #yocto16:24
RPJPEW: that shouldn't matter though? :/16:24
RPJPEW: this is a bit weird ;/16:24
RPJPEW: the other dependency is "hiding" the race16:25
RPJPEW: I see what you mean about recursivetaskselfref :/16:32
RPJPEW: the fundamental issue is task using something can't also recursively depend upon it16:35
MartinXI'm pretty new to yocto and am building an image for some IoT devices.  We got a yocto project from our SoC supplier.  It's yocto 2.4.3 "rocko" and everything is really out of date.  I've had some luck updating individual recipes, but it seems like there should be a better way to update the whole project?16:36
RPJPEW: disabling that cross linkage code results in ERROR: Task /media/build/poky/meta/recipes-devtools/python/ has circular dependency on /media/build/poky/meta/recipes-support/bash-completion/
RPMartinX: using a new release would get you all the newer versions. Your supplier should really give you something more recent. rocko is old16:37
RPlast release November 201816:38
MartinX@RP Yeah..  We've talked about it with them, but I guess this SoC is mainly used for Android devices, so they don't want to spend engineering update to upgrade it for us.  Any chance I could do it myself?16:40
*** starblue <starblue!> has quit IRC (Ping timeout: 240 seconds)16:40
RPMartinX: it certainly can be done. Depends what you need from the SoC specific pieces16:40
RPPersonally I'd start from master or our last LTS kirkstone and add in the pieces you need, see if you can get the SoC to work16:41
RPJPEW: I'm going to change my mind. I think the deptask was right before and we need to limit how far the tar recurses16:46
RPJPEW: It is fine for someone to run all the tasks if they want all the spdx documents pulled from sstate16:46
JPEWLimiting the recursion would be fairly easy if the recursive tasks were in BB_TASKDEPDATA16:48
MartinXRP Where would you start trying to add pieces in?  It seems like they've got a lot of SoC specific pieces.  To use any of the peripherals, there's some API or custom code to get it all working, so it's not always clear how it works under the covers.16:49
MartinXAlternatively, the minimum we need is python 3.10.  Maybe I should just migrate a recipe from that to rocko?16:49
JPEWerr, if the _circular_ tasks were in BB_TASKDEPDATA16:52
RPJPEW: that would have everything backwards though. You'd never get to the point where you could generate it!16:53
RPJPEW: I think create_spdx needs something like what extend_recipe_sysroot() has, where it has "# Create collapsed do_populate_sysroot -> do_populate_sysroot tree"16:55
RPbut in this case, using the spdx tasks as markers16:55
* JPEW reads the code16:56
RPJPEW: so prune the tree to the next set of spdx recipes16:56
JPEWRight, I wrote that; AFAICT, it works for extend_recipe_sysroot because it's not a circular task dependency (`do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"`, not `do_prepare_recipe_sysroot[deptask] = "do_prepare_recipe_sysroot"`)16:58
RPJPEW: if we do this, we can drop the recrdeptask for do_create_spdx though ?16:59
JPEWMaybe? It might just fail when collecting all the document for image creation instead17:00
*** florian <florian!> has joined #yocto17:00
RPJPEW: we can add the right dependency there?17:00
JPEWAh, yes17:00
JPEWSure that seems reasonble then17:00
RPthe issue is do_X on do_X is problematic17:00
RPdo_Y on do_X is fine17:00
*** florian <florian!> has quit IRC (Ping timeout: 240 seconds)17:11
*** MartinX <MartinX!> has quit IRC (Quit: Client closed)17:12
*** MartinX <MartinX!> has joined #yocto17:12
RPJPEW: which of us is going to try this? :)17:12
JPEWI can17:14
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto17:16
RPJPEW: this build was with the latest set of hacks: - failures look much more defined. reprodicuble issue is due to meta-selftest being present. The sstate sigs might be the remaining problem to solve17:18
RPJPEW: yes, I think it means we're finding the set of issues! :)17:19
*** sudip <sudip!~sudipmukh@> has quit IRC (Quit: ZNC -
*** MartinX <MartinX!> has quit IRC (Quit: Client closed)17:29
*** sudip <sudip!~sudipmukh@> has joined #yocto17:32
*** florian__ <florian__!> has joined #yocto17:39
*** amitk_ <amitk_!~amit@> has joined #yocto17:55
*** yannd <yannd!~yann@> has quit IRC (Remote host closed the connection)18:06
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving)18:06
*** seninha <seninha!~seninha@user/seninha> has joined #yocto18:20
*** sakoman1 <sakoman1!> has joined #yocto18:20
*** sakoman1 <sakoman1!> has left #yocto18:22
* paulg fines sakoman $2 for not writing a one sentence json long log18:29
*** dacav <dacav!> has quit IRC (Quit: leaving)18:42
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)18:55
*** starblue <starblue!> has joined #yocto19:08
frayI can push a master-next or something like that for testing19:30
RPfray: New TSC member in OE-Core takeover? :)19:31
* RP does know the real context but this is more fun19:31
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)19:32
fraylol much more fun to take things out of context.  lol19:32
*** alessioigor <alessioigor!~alessioig@> has joined #yocto19:32
frayI don't even have write/push access to the repository in question afterall..19:32
JPEWRP: I updated my contrib branch19:44
JPEWshould be good for testing now19:45
*** zwelch <zwelch!> has quit IRC (Remote host closed the connection)19:48
*** zwelch <zwelch!> has joined #yocto19:50
RPJPEW: thanks, I triggered a build with CVE and kernel stuff but I'll work something out after that19:58
RPJPEW: I sent a patch for the world build issue, the main worry left is the selftest failures19:59
RPe.g. oe-selftest -r sstatetests.SStateHashSameSigs2.test_sstate_allarch_samesigs  -j 119:59
JPEWI'll try that locally19:59
RPJPEW: there are several failing but that is a place to start...20:02
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 240 seconds)20:02
*** Haxxa <Haxxa!~Haxxa@> has quit IRC (Quit: Haxxa flies away.)20:15
*** Haxxa <Haxxa!> has joined #yocto20:18
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)20:24
*** nemik <nemik!~nemik@> has joined #yocto20:25
JPEWdo_create_spdx depends on STAGING_KERNEL_DIR, since it can peek into the kernel sources20:27
JPEW(which in turn depends on MACHINE)20:27
JPEWI think this variable can just be ignored with vardepsexclude20:27
JPEWCan I convince oe-selftest to leave the directories around for a closer look?20:39
*** olani- <olani-!> has quit IRC (Ping timeout: 246 seconds)20:42
JPEWAh, nm. I found it20:43
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)20:47
*** sakoman <sakoman!> has joined #yocto20:48
RPJPEW: we should really make that configurable somehow20:50
JPEWI just commented out the lines that delete them20:50
JPEWBut ya20:50
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)20:54
RPJPEW: that is what I do too :/20:59
JPEWFor the allarch hashes.... I don't know what to do there. The hash changed because a dependency changed, but isn't it supposed to do that?21:00
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 265 seconds)21:00
*** amitk <amitk!~amit@> has joined #yocto21:00
JPEWdo_prepare_recipe_sysroot presumably solves this I guess... I'll look there21:01
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 248 seconds)21:06
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)21:07
*** alessioigor <alessioigor!~alessioig@> has joined #yocto21:07
*** Xagen <Xagen!~Xagen@> has quit IRC (Ping timeout: 240 seconds)21:08
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 250 seconds)21:20
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 250 seconds)21:24
tctI've probably read the SDK vs eSDK documentation like three times now and I am still not sure which one to pick :D21:26
*** bps <bps!~bps@user/bps> has joined #yocto21:26
*** paulg <paulg!> has quit IRC (Ping timeout: 268 seconds)21:31
JPEWtct: SDK is a traditional SDK; you download, you install, you have a toolchain you can compile with21:34
JPEWeSDK is like taking a snapshot of your Yocto setup and users can download that and compile things against it21:35
JPEWI don't use the eSDK, so that's probably not a great explination21:35
tctnow that sounds like an explanation worth putting into the documentation. Obviously it's not telling the full story but this helps a lot.21:35
tctJPEW, thanks a lot :)21:36
*** tct is now known as jbo21:36
jboJPEW, so assuming my fellow delevopers are all building the yocto images themselves anyway there's nothing wrong with going the traditional SDK way?21:36
JPEWWe use the SDK this way:21:36
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds)21:38
JPEWYocto devs publish SDKs for our products. App developers download the SDK to compile applications (never touching Yocto) and we have mechanisms to sideload the applications they build for testing. When they are happy with their app, they update the recipe for that application to point to the new SHA-121:38
JPEWSo they don't do app development "in-yocto"21:38
jboJPEW, based on your previous explanation of SDK vs. eSDK that sounds more like eSDK rather than SDK, no?21:40
JPEWNo... it's traditional SDK21:40
jboso what you publish is basically the setup script that  `bitbake <image> -c populate_sdk`  creates?21:40
JPEWtraditional SDK lets you compile applications without having to do any yocto things, you just have a toolchain21:41
JPEWjbo: Correct21:41
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Remote host closed the connection)21:41
jbothat's what I want/need :)21:41
jboI'm actually interested in the sideloading you mentioned. Currently I just rsync the resulting binary/package to the target. However, I'm not particularly happy with that.21:42
JPEWYa, it's complicated21:42
jbois there a way to include what was built with the SDK into the image without rebuilding the entire image?21:42
jboone of the devices I'm working with doesn't have any networking or USB :D21:42
jboSDcard is literally my only interface.21:42
JPEWjbo: Ah ya, we do that with a sdk-packagegroup that feeds into both our "developer" image and the SDK, but not our "release" image21:43
JPEWBy doing that, anything that was built against the SDK should be able to run on the target if it's running the "developer" image (e.g. shared libraries are all there)21:44
JPEWBut in the "release" image, it's the minimal set of what you actually need21:44
JPEWjbo: Ah, I'm not sure about that21:44
JPEWSerial port?21:44
jbothat I have21:45
jbobut just the regular serial port to have a shell21:45
JPEWThere are programs that can transfer files across the serial terminal21:45
JPEWold tech, but useful :)21:45
jboI'm just using picocom on that serial port so far21:45
jbomight be worth looking into - could safe me a lot of trouble21:45
jbohow does that work / what should I be looking for?21:45
JPEWzmodem I think?21:46
JPEWI think theres another one too21:46
jboI guess that will be pretty manual in use as in that I have to log out of the shell, use that particular tech to transfer files and then bring the shell back up?21:47
JPEWIt's possible some terminal programs have support integrated21:47
JPEWI've not use it much, we usually have ethernet on our devices21:48
jbosame here.21:48
jboI'll look into that - thanks for the tipp!21:48
*** florian__ <florian__!> has quit IRC (Ping timeout: 240 seconds)21:55
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto21:57
*** starblue <starblue!> has joined #yocto22:03
RPJPEW: allarch recipes shouldn't have dependencies that change?22:10
frayallarch can change from distro to distro, but not within a single distro (unless something critical like init_manager) changes..  or well it shouldn't change22:12
RPfray: the context here is that a given allarch recipe wouldn't change in a given TMPDIR for different MACHINEs or SDKMACHINEs22:15
frayI have seen cases where someone will set a distro feature or INIT_MANAGER in a machine.. it's wrong, but it can do that22:17
JPEWRP: I traced it back to binutils-cross:do_unpacl22:17
fraybut I agree, it shouldn't22:18
JPEWdo_create_spdx directly depends on do_unpack so it can get the source code, but I'm not sure why do_unpack for binutils-cross causes problems here but not normally22:19
JPEWSupper time though22:19
jboso I was crying for help on the DTS for a custom board with an on-board I2S codec a week ago. if anybody cares, I managed to get it working:
fraysomething changing patches for binutils (or configs) per arch or tune?22:23
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto22:26
jboJPEW, picocom certainly has a "send file" option.22:34
jboJPEW, seems like I just need something on the device side. looks like `lrzsz` and `kermit` are viable options22:34
*** olani- <olani-!> has joined #yocto22:50
*** paulg <paulg!> has joined #yocto22:51
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)22:58
*** nemik <nemik!~nemik@> has joined #yocto22:58
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)23:04
*** nemik <nemik!~nemik@> has joined #yocto23:04
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving)23:07
*** neverpanic <neverpanic!~clemens@2a01:4f8:262:439d::1> has quit IRC (Quit: Bye!)23:13
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:18
JPEWfray: no, TARGET_ARCH is in PN23:19
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:bc2d:57d7:406e:f9ca> has quit IRC (Remote host closed the connection)23:43
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:8d18:63b7:dd1d:3c16> has joined #yocto23:43
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 246 seconds)23:54

Generated by 2.17.2 by Marius Gedminas - find it at!