| *** seninha_ <seninha_!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 00:28 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 00:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:35 | |
| *** davidinux <davidinux!~davidinux@194.34.233.120> has quit IRC (Ping timeout: 240 seconds) | 01:03 | |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 01:10 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 01:21 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 01:21 | |
| *** starblue <starblue!~juergen@dslb-094-221-189-001.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 265 seconds) | 01:28 | |
| *** starblue <starblue!~juergen@dslb-094-220-106-167.094.220.pools.vodafone-ip.de> has joined #yocto | 01:30 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 246 seconds) | 01:43 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 01:43 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 01:44 | |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 250 seconds) | 01:48 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 01:48 | |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> has joined #yocto | 02: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 #yocto | 02:43 | |
| *** nerdboy <nerdboy!~nerdboy@47.143.129.200> has joined #yocto | 02:53 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 240 seconds) | 03:46 | |
| *** camus <camus!~Instantbi@58.246.136.203> has quit IRC (Ping timeout: 250 seconds) | 04:05 | |
| *** camus <camus!~Instantbi@58.246.136.203> has joined #yocto | 04:09 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 250 seconds) | 04:29 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-131-059-245.93.131.pool.telefonica.de> has joined #yocto | 04:46 | |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> 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 #yocto | 05:16 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:29 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-131-059-245.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 05:31 | |
| *** davidinux <davidinux!~davidinux@194.34.233.147> has joined #yocto | 05:41 | |
| landgraf | Hi 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 so | 05:51 |
|---|---|---|
| landgraf | much enjoyable debugging | 05:51 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 05:54 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:54 | |
| RP | JPEW: Testing was interesting. Lots failed, https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/7586/steps/11/logs/stdio is probably the simplest error message. It looks bad from the autobuilder but I think things are on the right track | 05:59 |
| RP | JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/7089 too | 05:59 |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 06:06 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 06:06 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:14 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:14 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:27 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:32 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:35 | |
| *** frieder <frieder!~frieder@i577B91DF.versanet.de> has joined #yocto | 06:44 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 06:45 | |
| *** Ablu[m] is now known as Ablu | 06:51 | |
| *** Ablu <Ablu!~ablumatri@2001:470:69fc:105::2f63> has quit IRC (Remote host closed the connection) | 07:05 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFD5.versanet.de> has joined #yocto | 07:07 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:45 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds) | 07:48 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 07:48 | |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 250 seconds) | 07:54 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 07:54 | |
| *** amitk_ <amitk_!~amit@103.208.71.114> has joined #yocto | 07:54 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:59 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Ping timeout: 250 seconds) | 08:17 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 08:21 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 08:40 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds) | 08:49 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 08:49 | |
| *** davidinux <davidinux!~davidinux@194.34.233.147> has quit IRC (Ping timeout: 246 seconds) | 08:49 | |
| __ad | hi, 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!~davidinux@host-95-251-214-81.retail.telecomitalia.it> has joined #yocto | 08:52 | |
| qschulz | __ad: no | 08:52 |
| __ad | ok thanks | 08:52 |
| qschulz | you would need to go with a trick around recipe renaming (e.g. we had libopenssl10 for some time I think) | 08:52 |
| qschulz | or use multilib as a horrible hack | 08:53 |
| qschulz | but I would highly recommend figuring out how to make everything work with the same libs because it is a nightmare to manage :) | 08:53 |
| __ad | qschulz: ok. i mainly have a propertary app that cannot easily be rebuilt over 1.1.1 | 08:54 |
| __ad | maybe i could symlink ? | 08:54 |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 248 seconds) | 08:54 | |
| __ad | 1.1.1 is safer, so would keep it in the system | 08:54 |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 08:55 | |
| qschulz | __ad: everyting is bad with openssl1. | 08:58 |
| qschulz | x | 08:58 |
| qschulz | as it's EOL in September IIRC | 08:58 |
| *** davidinux <davidinux!~davidinux@host-95-251-214-81.retail.telecomitalia.it> has quit IRC (Ping timeout: 240 seconds) | 08:59 | |
| qschulz | I suspect openssl 1.1 and openssl 1.0 aren't compatible so the symlink wouldn't help | 08:59 |
| *** davidinux <davidinux!~davidinux@92.118.62.19> has joined #yocto | 08:59 | |
| __ad | ugh :( thanks | 08:59 |
| __ad | qschulz: i am in dunfell now, do you think is possible to move to openssl 3 staying in dunfell ? | 09:03 |
| * qschulz shrugs | 09:04 | |
| qschulz | That would probably be a question for the LTS maintainer since this means we have components that cannot receive security fixes | 09:05 |
| qschulz | but short answer is "everything is possible if you give it time" | 09:05 |
| qschulz | but you'd need to replace openssl 1.1 recipe with openssl 3.0 and fix all the compilation issues | 09:06 |
| __ad | ok thanks | 09:06 |
| qschulz | you could also migrate to kirkstone, which EoLs at the same time as Dunfell | 09:06 |
| __ad | ok, will see, thanks | 09:07 |
| *** paulbarker <paulbarker!~paulbarke@152.236.187.81.in-addr.arpa> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 09:15 | |
| *** paulbarker <paulbarker!~paulbarke@152.236.187.81.in-addr.arpa> has joined #yocto | 09:15 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 09:16 | |
| *** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 265 seconds) | 09:36 | |
| RP | __ad: someone could create a mixin layer for that... | 09:49 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 09:51 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 09:59 | |
| *** starblue <starblue!~juergen@dslb-094-220-106-167.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 265 seconds) | 10:04 | |
| *** starblue <starblue!~juergen@dslb-094-220-106-167.094.220.pools.vodafone-ip.de> has joined #yocto | 10:06 | |
| RP | JPEW: I have a patch which helps the spdx failures FWIW | 10:20 |
| landgraf | I'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 |
| RP | landgraf: I'd have thought it might prove tricky to keep in sync since you don't control either of them :/ | 10:21 |
| landgraf | FILESEXTRAPATHS:append = "LAYERDIR/..." I guess? | 10:21 |
| landgraf | RP: I have control over patches and apply them in bbappends.. | 10:22 |
| landgraf | so far so good except the fact I don't want to have two copies of them | 10:22 |
| landgraf | and I cannot put linux-raspberrypi.bbappend into main layer because it breaks other machines which don't need rpi layer | 10:23 |
| *** hrberg <hrberg!~quassel@171.79-160-161.customer.lyse.net> has joined #yocto | 10:24 | |
| RP | landgraf: you should be able to put a common path in both recipes | 10:27 |
| landgraf | RP: 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!~quassel@171.79-160-161.customer.lyse.net> has quit IRC (Read error: Connection reset by peer) | 10:33 | |
| RP | landgraf: doesn't sound good :/ | 10:34 |
| *** hrberg <hrberg!~quassel@171.79-160-161.customer.lyse.net> has joined #yocto | 10:34 | |
| *** yannd <yannd!~yann@37.170.181.241> has joined #yocto | 10:34 | |
| *** nemik <nemik!~nemik@207.237.248.190> 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@76.74.126.42> has joined #yocto | 10:44 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:46 | |
| landgraf | mcfrisk: 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@76.74.126.42> has quit IRC (Ping timeout: 250 seconds) | 10:48 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 10:49 | |
| mcfrisk | yea, 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 bad | 10:52 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 10:54 | |
| mcfrisk | some 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 product | 10:56 |
| RP | JPEW: 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:https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/7208/steps/12/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/122/builds/2803 | 10:57 |
| *** otavio_ <otavio_!~otavio@177-4-253-230.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 240 seconds) | 10:59 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 11:01 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 11:01 | |
| tct | Hey 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@37.170.181.241> has quit IRC (Ping timeout: 240 seconds) | 11:28 | |
| *** otavio <otavio!~otavio@177-4-253-192.user3p.brasiltelecom.net.br> has joined #yocto | 11:45 | |
| *** yannd <yannd!~yann@37.170.181.241> has joined #yocto | 11:46 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 11:47 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 256 seconds) | 12:07 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 250 seconds) | 12:07 | |
| __ad | what recipe includes useradd command ? | 12:08 |
| __ad | ok, looks shadow-utils | 12:09 |
| *** jtoomey <jtoomey!~jtoomey@149.199.80.130> has quit IRC (Ping timeout: 240 seconds) | 12:10 | |
| __ad | right recipe seems shadow, but it's only native | 12:30 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 12:31 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 12:32 | |
| RP | tct: add a patch to the recipe's SRC_URI ? | 12:33 |
| tct | RP, but then I'd have to modify the meta-oe recipe/repo :( | 12:43 |
| RP | tct: you can do it from a bbappend | 12:43 |
| tct | RP, oh... reasonable! | 12:43 |
| tct | thanks :) | 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@207.237.248.190> has quit IRC (Ping timeout: 240 seconds) | 13:03 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 13:03 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 13:03 | |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 240 seconds) | 13:09 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 13:09 | |
| *** otavio <otavio!~otavio@177-4-253-192.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 240 seconds) | 13:11 | |
| *** otavio <otavio!~otavio@177-4-253-192.user3p.brasiltelecom.net.br> has joined #yocto | 13:11 | |
| *** otavio <otavio!~otavio@177-4-253-192.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 250 seconds) | 13:17 | |
| *** otavio <otavio!~otavio@177-4-253-192.user3p.brasiltelecom.net.br> has joined #yocto | 13:18 | |
| RP | JPEW: bitbake python3-bcrypt; bitbake python3-pycparser-native python3-cffi-native -c clean; bitbake python3-bcrypt -c create_spdx -f breaks | 13:29 |
| JPEW | RP: Cool, I'll try that | 13:30 |
| JPEW | RP: Where is your patch? | 13:34 |
| RP | JPEW: it is some kind of missing dependency, "bitbake python3-bcrypt -g" shows no dependency on python3-pycparser-native from bcrypt, only from cffi-native | 13:34 |
| RP | JPEW: master-next | 13:34 |
| JPEW | sdk pkgdata fixup? | 13:35 |
| RP | JPEW: yes, one second as I have another | 13:35 |
| JPEW | Why is that necessary? Does the SDK not have pkgdata? | 13:35 |
| RP | JPEW: there are two locations, target and SDK | 13:35 |
| RP | JPEW: master-next now has "meta-world-pkgdata-Fix-for-create-spdx" (will be syncing to the mirrors) | 13:36 |
| RP | JPEW: 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 |
| RP | the meta-world-pkgdata fix makes "bitbake world" work again when multilibs are enabled | 13:37 |
| RP | so then we're left with this weird sstate dependency issue | 13:37 |
| JPEW | OK. I'm running the bcrypt test now.... rust is building so... it will be a bit :) | 13:37 |
| RP | oh, and oe-selftest sstate sigs test failures | 13:37 |
| RP | JPEW: you could probably find a simpler example, that was just the one the autobuilder showed me :/ | 13:38 |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> has joined #yocto | 13:48 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 13:49 | |
| RP | JPEW: changing do_create_spdx[deptask] = "do_create_spdx" to do_create_spdx[recrdeptask] = "do_create_spdx" "fixes" it | 13:52 |
| *** Xagen <Xagen!~Xagen@4.14.206.69> has joined #yocto | 13:52 | |
| RP | whether that is the right thing or not, less sure | 13:52 |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 13:53 | |
| JPEW | RP: Why would it be in BB_TASKDEPDATA, but not run? | 13:54 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:54 | |
| JPEW | Hmm, `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 confused | 14:06 | |
| *** Xagen <Xagen!~Xagen@4.14.206.69> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 14:11 | |
| RP | JPEW: if an sstate task runs, it is assumed that "covers" everything needed | 14:15 |
| RP | i.e. sstate task dependencies won't run if the sstate task runs | 14:15 |
| JPEW | hmmm | 14:15 |
| JPEW | So is the assumption that python3-cffi-native:do_create_spdx "covers" python3-pycparser-native:do_create_spdx ? | 14:16 |
| *** Xagen <Xagen!~Xagen@4.14.206.69> has joined #yocto | 14:17 | |
| RP | JPEW: yes. If you really want indirect dependencies, that is where recrdeptask comes into play | 14:18 |
| *** amitk_ <amitk_!~amit@103.208.71.114> has quit IRC (Ping timeout: 250 seconds) | 14:19 | |
| RP | JPEW: saying X uses Y-native to build. You don't want Y-native everytime you use X if it is just a build tool | 14:19 |
| JPEW | Is 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-native | 14:19 |
| JPEW | (I didn't realize those transitive dependencies were in BB_TASKDEPDATA in the first place) | 14:20 |
| RP | JPEW: 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 |
| JPEW | RP: 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 circumstances | 14:28 |
| RP | JPEW: right, you can't do that | 14:28 |
| RP | JPEW: can you assume the other create_spdx task would have the links needed in that document? | 14:29 |
| JPEW | Philosphically speaking, I only _really_ need the direct dependencies because the relationship chains will eventually lead back to all of the transitive dependencies | 14:29 |
| RP | JPEW: that is what I was wondering | 14:29 |
| JPEW | But if python3-pycparser-native didn't run, there will be a broken document chain, even if we only report the direct dependencies | 14:31 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 14:31 | |
| JPEW | So... may we need both a change to only report the direct dependencies and recrdeptask? | 14:31 |
| RP | JPEW: 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@185.178.95.254> has joined #yocto | 14:31 | |
| RP | probably! | 14:32 |
| JPEW | Ya, I think so | 14:32 |
| *** ajfriesen8 <ajfriesen8!~ajfriesen@p54b94d31.dip0.t-ipconnect.de> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 14:32 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:33 | |
| *** ajfriesen8 <ajfriesen8!~ajfriesen@p54b94d31.dip0.t-ipconnect.de> has joined #yocto | 14:37 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-33-70-53-64-242.dsl.bell.ca> has joined #yocto | 14:39 | |
| RP | JPEW: I'll try a new build, see if this narrows us down to a smaller set of issues | 14:41 |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Ping timeout: 250 seconds) | 14:41 | |
| JPEW | Ya, filter only direct dependencies is a good idea, but shouldn't affect the build errors | 14:42 |
| JPEW | RP: Something like https://git.yoctoproject.org/poky-contrib/commit/?h=jpew/spdx-pkg-arch&id=a7b31d607fa17b1dc8dd4e0e39a5b563aa3e171b maybe? | 14:42 |
| RP | JPEW: that looks horrible and I'm not sure it will work deterministically | 14:44 |
| RP | the idea of direct is task dependent unfortunately :( | 14:44 |
| RP | the staging and sstate code both have differing ideas of what "direct" is | 14:45 |
| JPEW | Ah | 14:45 |
| JPEW | Is that why taskdepdata is calculated twice independently in the runqueue? | 14:46 |
| RP | JPEW: https://git.yoctoproject.org/poky/tree/meta/lib/oe/sstatesig.py#n10 is basically a function deciding which dependencies it should follow and which it shouldn't | 14:46 |
| RP | JPEW: taskdepdata is calculated twice as there is the "setscene" context and the real task context iirc | 14:47 |
| RP | one is quite different as it is setscene task dependencies rather than task dependencies | 14:48 |
| JPEW | Ah, 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 running | 14:51 |
| JPEW | ? | 14:51 |
| RP | JPEW: do_create_spdx_setscene would see the setscene one but that is just straight into the sstate code | 14:53 |
| RP | but yes | 14:53 |
| *** paulbarker <paulbarker!~paulbarke@152.236.187.81.in-addr.arpa> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 14:54 | |
| *** paulbarker <paulbarker!~paulbarke@152.236.187.81.in-addr.arpa> has joined #yocto | 14:55 | |
| RP | JPEW: in the new build we still have https://autobuilder.yoctoproject.org/typhoon/#/builders/122/builds/2805/steps/12/logs/stdio with meta-aws, not looked at what might be special there | 14:58 |
| JPEW | Similar problem maybe? | 15:03 |
| JPEW | Is the do_create_spdx in the recipe assumed to "cover" all the dependencies? | 15:04 |
| JPEW | Cover all the recrdeptask of do_create_spdx that is | 15:04 |
| JPEW | Also.... recrdeptask is for runtime dependencies which isn't the same as deptask for do_create_spdx | 15:06 |
| JPEW | recrdeptask seems correct for do_create_runtime_spdx; it already does `do_create_runtime_spdx[rdeptask] = "do_create_spdx"` | 15:07 |
| *** yannd <yannd!~yann@37.170.181.241> has quit IRC (Read error: Connection reset by peer) | 15:08 | |
| RP | JPEW: I think recrdeptask covers both build and runtime dependencies, the distinction doesn't make sense for rec deps iirc | 15:08 |
| RP | JPEW: the new build has lots of runtime task failures: https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/7490/steps/14/logs/stdio | 15:10 |
| * RP stops that build | 15:10 | |
| JPEW | Ya, that one should also be changed to recrdeptask I tink | 15:10 |
| JPEW | Does 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 |
| RP | JPEW: yes :/ | 15:15 |
| JPEW | Well.... I guess no one will be able to claim our SPDX isn't through at least | 15:17 |
| JPEW | I'm sure there is a reason that recdeptask doesn't exist? | 15:18 |
| *** Xagen <Xagen!~Xagen@4.14.206.69> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 15:18 | |
| *** Xagen <Xagen!~Xagen@4.14.206.69> has joined #yocto | 15:19 | |
| *** yannd <yannd!~yann@37.171.125.106> has joined #yocto | 15:22 | |
| *** PobodysNerfect <PobodysNerfect!~PobodysNe@84.214.105.47> has quit IRC (Ping timeout: 240 seconds) | 15:26 | |
| tct | is 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 again | 15:28 |
| JPEW | tct: If you keep sstate, things that don't need to rebuild will restore from that instead, which should be reasonbly fast | 15:28 |
| tct | JPEW, could you be a bit more specific? what does "keep sstate" mean? | 15:29 |
| JPEW | tct: The sstate directory where bitbake caches build output; I think it defaults to ${BUILDDIR}/sstate ? | 15:30 |
| tct | JPEW, so you'd recommend me to just delete everything in the build dir except for conf/ and sstate and then bitbake again? | 15:30 |
| JPEW | tct: I think if you only delete $BUILDDIR/tmp it will do what you want | 15:31 |
| JPEW | leave everything else | 15:31 |
| RP | JPEW: recdeptask doesn't make any sense when you look at the code | 15:32 |
| tct | JPEW, thanks! | 15:33 |
| RP | it did exist once, kind of | 15:33 |
| tct | JPEW, actually, I am not sure why mine is called /build/tmp-glibc ever since I moved to a custom distro | 15:33 |
| RP | JPEW: meta-aws was green this time | 15:33 |
| JPEW | RP: 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@84.214.105.47> has joined #yocto | 15:41 | |
| RP | JPEW: at every other level beyond the top level, the runtime pieces end up pulled in regardless | 15:42 |
| *** yannd <yannd!~yann@37.171.125.106> has quit IRC (Ping timeout: 240 seconds) | 15:42 | |
| RP | JPEW: I'm fuzzy on the exact details now but it ended up not making much sense :/ | 15:44 |
| JPEW | Ya, the processing after that definitely is confusing so I can believe it does some stuff like that | 15:45 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 15:57 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 240 seconds) | 16:10 | |
| JPEW | RP: 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 change | 16:11 |
| RP | JPEW: they should! | 16:14 |
| JPEW | I though so too | 16:14 |
| JPEW | Let me see if it's user error | 16:14 |
| RP | JPEW: I just checked and you're right. It does add python3-pycparser-native to python3-bcrypt.do_create_runtime_spdx but not create_spdx | 16:16 |
| JPEW | Weird | 16:16 |
| JPEW | do_create_spdx[depends] is the culprit maybe? | 16:17 |
| JPEW | Nope | 16:18 |
| *** yannd <yannd!~yann@37.171.125.106> has joined #yocto | 16:18 | |
| *** zpfvo <zpfvo!~fvo@i59F5CFD5.versanet.de> has quit IRC (Remote host closed the connection) | 16:22 | |
| *** frieder <frieder!~frieder@i577B91DF.versanet.de> has quit IRC (Remote host closed the connection) | 16:22 | |
| *** Guest58 <Guest58!~Guest58@99-121-116-88.lightspeed.gdrpmi.sbcglobal.net> has joined #yocto | 16:22 | |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 250 seconds) | 16:23 | |
| JPEW | Ah, runqueue explicitly removes self-referential tasks (`recursivetaskselfref`) ? | 16:23 |
| *** Guest58 <Guest58!~Guest58@99-121-116-88.lightspeed.gdrpmi.sbcglobal.net> has quit IRC (Client Quit) | 16:23 | |
| *** MartinX <MartinX!~MartinX@99-121-116-88.lightspeed.gdrpmi.sbcglobal.net> has joined #yocto | 16:24 | |
| RP | JPEW: that shouldn't matter though? :/ | 16:24 |
| RP | JPEW: this is a bit weird ;/ | 16:24 |
| RP | JPEW: the other dependency is "hiding" the race | 16:25 |
| RP | JPEW: I see what you mean about recursivetaskselfref :/ | 16:32 |
| RP | JPEW: the fundamental issue is task using something can't also recursively depend upon it | 16:35 |
| MartinX | I'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 |
| RP | JPEW: disabling that cross linkage code results in ERROR: Task /media/build/poky/meta/recipes-devtools/python/python3_3.11.2.bb:do_create_spdx has circular dependency on /media/build/poky/meta/recipes-support/bash-completion/bash-completion_2.11.bb:do_create_spdx | 16:37 |
| RP | MartinX: using a new release would get you all the newer versions. Your supplier should really give you something more recent. rocko is old | 16:37 |
| RP | MartinX: https://wiki.yoctoproject.org/wiki/Releases | 16:38 |
| RP | last release November 2018 | 16: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!~juergen@dslb-094-220-106-167.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 240 seconds) | 16:40 | |
| RP | MartinX: it certainly can be done. Depends what you need from the SoC specific pieces | 16:40 |
| RP | Personally 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 work | 16:41 |
| RP | JPEW: I'm going to change my mind. I think the deptask was right before and we need to limit how far the tar recurses | 16:46 |
| RP | JPEW: It is fine for someone to run all the tasks if they want all the spdx documents pulled from sstate | 16:46 |
| RP | s/tar/task/ | 16:47 |
| JPEW | Limiting the recursion would be fairly easy if the recursive tasks were in BB_TASKDEPDATA | 16:48 |
| MartinX | RP 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 |
| MartinX | Alternatively, the minimum we need is python 3.10. Maybe I should just migrate a recipe from that to rocko? | 16:49 |
| JPEW | err, if the _circular_ tasks were in BB_TASKDEPDATA | 16:52 |
| RP | JPEW: that would have everything backwards though. You'd never get to the point where you could generate it! | 16:53 |
| RP | JPEW: 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 |
| RP | but in this case, using the spdx tasks as markers | 16:55 |
| * JPEW reads the code | 16:56 | |
| RP | JPEW: so prune the tree to the next set of spdx recipes | 16:56 |
| JPEW | Right, 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 |
| RP | JPEW: if we do this, we can drop the recrdeptask for do_create_spdx though ? | 16:59 |
| JPEW | Maybe? It might just fail when collecting all the document for image creation instead | 17:00 |
| *** florian <florian!~florian@dynamic-093-131-059-245.93.131.pool.telefonica.de> has joined #yocto | 17:00 | |
| RP | JPEW: we can add the right dependency there? | 17:00 |
| JPEW | Ah, yes | 17:00 |
| JPEW | Sure that seems reasonble then | 17:00 |
| RP | the issue is do_X on do_X is problematic | 17:00 |
| RP | do_Y on do_X is fine | 17:00 |
| *** florian <florian!~florian@dynamic-093-131-059-245.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 17:11 | |
| *** MartinX <MartinX!~MartinX@99-121-116-88.lightspeed.gdrpmi.sbcglobal.net> has quit IRC (Quit: Client closed) | 17:12 | |
| *** MartinX <MartinX!~MartinX@99-121-116-88.lightspeed.gdrpmi.sbcglobal.net> has joined #yocto | 17:12 | |
| RP | JPEW: which of us is going to try this? :) | 17:12 |
| JPEW | I can | 17:14 |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 17:16 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 17:16 | |
| RP | JPEW: this build was with the latest set of hacks: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5374 - failures look much more defined. reprodicuble issue is due to meta-selftest being present. The sstate sigs might be the remaining problem to solve | 17:18 |
| JPEW | progress! | 17:19 |
| RP | JPEW: yes, I think it means we're finding the set of issues! :) | 17:19 |
| *** sudip <sudip!~sudipmukh@78.40.148.182> has quit IRC (Quit: ZNC - http://znc.in) | 17:28 | |
| *** MartinX <MartinX!~MartinX@99-121-116-88.lightspeed.gdrpmi.sbcglobal.net> has quit IRC (Quit: Client closed) | 17:29 | |
| *** sudip <sudip!~sudipmukh@78.40.148.182> has joined #yocto | 17:32 | |
| *** florian__ <florian__!~florian@dynamic-093-131-059-245.93.131.pool.telefonica.de> has joined #yocto | 17:39 | |
| *** amitk_ <amitk_!~amit@103.59.74.23> has joined #yocto | 17:55 | |
| *** yannd <yannd!~yann@37.171.125.106> 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 #yocto | 18:20 | |
| *** sakoman1 <sakoman1!~sakoman-l@dhcp-72-234-106-30.hawaiiantel.net> has joined #yocto | 18:20 | |
| *** sakoman1 <sakoman1!~sakoman-l@dhcp-72-234-106-30.hawaiiantel.net> has left #yocto | 18:22 | |
| * paulg fines sakoman $2 for not writing a one sentence json long log | 18:29 | |
| *** dacav <dacav!~dacav@82-209-166-158.cust.bredband2.com> has quit IRC (Quit: leaving) | 18:42 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 18:55 | |
| *** starblue <starblue!~juergen@99-131-142-46.pool.kielnet.net> has joined #yocto | 19:08 | |
| fray | I can push a master-next or something like that for testing | 19:30 |
| fray | oops | 19:30 |
| RP | fray: New TSC member in OE-Core takeover? :) | 19:31 |
| * RP does know the real context but this is more fun | 19:31 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 19:32 | |
| fray | lol much more fun to take things out of context. lol | 19:32 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:32 | |
| fray | I don't even have write/push access to the repository in question afterall.. | 19:32 |
| JPEW | RP: I updated my contrib branch | 19:44 |
| JPEW | should be good for testing now | 19:45 |
| *** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has quit IRC (Remote host closed the connection) | 19:48 | |
| *** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has joined #yocto | 19:50 | |
| RP | JPEW: thanks, I triggered a build with CVE and kernel stuff but I'll work something out after that | 19:58 |
| JPEW | Cool | 19:59 |
| RP | JPEW: I sent a patch for the world build issue, the main worry left is the selftest failures | 19:59 |
| RP | e.g. oe-selftest -r sstatetests.SStateHashSameSigs2.test_sstate_allarch_samesigs -j 1 | 19:59 |
| JPEW | I'll try that locally | 19:59 |
| RP | JPEW: there are several failing but that is a place to start... | 20:02 |
| *** amitk_ <amitk_!~amit@103.59.74.23> has quit IRC (Ping timeout: 240 seconds) | 20:02 | |
| *** Haxxa <Haxxa!~Haxxa@202.65.68.206> has quit IRC (Quit: Haxxa flies away.) | 20:15 | |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has joined #yocto | 20:18 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 250 seconds) | 20:24 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 20:25 | |
| JPEW | do_create_spdx depends on STAGING_KERNEL_DIR, since it can peek into the kernel sources | 20:27 |
| JPEW | (which in turn depends on MACHINE) | 20:27 |
| JPEW | I think this variable can just be ignored with vardepsexclude | 20:27 |
| JPEW | Can I convince oe-selftest to leave the directories around for a closer look? | 20:39 |
| *** olani- <olani-!~olani@31-208-215-248.cust.bredband2.com> has quit IRC (Ping timeout: 246 seconds) | 20:42 | |
| JPEW | Ah, nm. I found it | 20:43 |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 20:47 | |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> has joined #yocto | 20:48 | |
| RP | JPEW: we should really make that configurable somehow | 20:50 |
| JPEW | I just commented out the lines that delete them | 20:50 |
| JPEW | But ya | 20:50 |
| *** starblue <starblue!~juergen@99-131-142-46.pool.kielnet.net> has quit IRC (Ping timeout: 256 seconds) | 20:54 | |
| RP | JPEW: that is what I do too :/ | 20:59 |
| JPEW | For 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@103.59.74.23> has quit IRC (Ping timeout: 265 seconds) | 21:00 | |
| *** amitk <amitk!~amit@103.59.74.23> has joined #yocto | 21:00 | |
| JPEW | do_prepare_recipe_sysroot presumably solves this I guess... I'll look there | 21:01 |
| *** amitk <amitk!~amit@103.59.74.23> has quit IRC (Ping timeout: 248 seconds) | 21:06 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 21:07 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 21:07 | |
| *** Xagen <Xagen!~Xagen@4.14.206.69> 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 | |
| tct | I've probably read the SDK vs eSDK documentation like three times now and I am still not sure which one to pick :D | 21:26 |
| *** bps <bps!~bps@user/bps> has joined #yocto | 21:26 | |
| *** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has quit IRC (Ping timeout: 268 seconds) | 21:31 | |
| JPEW | tct: SDK is a traditional SDK; you download, you install, you have a toolchain you can compile with | 21:34 |
| JPEW | eSDK is like taking a snapshot of your Yocto setup and users can download that and compile things against it | 21:35 |
| JPEW | I don't use the eSDK, so that's probably not a great explination | 21:35 |
| tct | now 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 |
| tct | JPEW, thanks a lot :) | 21:36 |
| *** tct is now known as jbo | 21:36 | |
| jbo | JPEW, 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 |
| JPEW | We use the SDK this way: | 21:36 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds) | 21:38 | |
| JPEW | Yocto 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-1 | 21:38 |
| JPEW | So they don't do app development "in-yocto" | 21:38 |
| jbo | JPEW, based on your previous explanation of SDK vs. eSDK that sounds more like eSDK rather than SDK, no? | 21:40 |
| JPEW | No... it's traditional SDK | 21:40 |
| jbo | so what you publish is basically the setup script that `bitbake <image> -c populate_sdk` creates? | 21:40 |
| JPEW | traditional SDK lets you compile applications without having to do any yocto things, you just have a toolchain | 21:41 |
| JPEW | jbo: Correct | 21:41 |
| jbo | cool | 21:41 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 21:41 | |
| jbo | that's what I want/need :) | 21:41 |
| jbo | I'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 |
| JPEW | Ya, it's complicated | 21:42 |
| jbo | is there a way to include what was built with the SDK into the image without rebuilding the entire image? | 21:42 |
| jbo | one of the devices I'm working with doesn't have any networking or USB :D | 21:42 |
| jbo | SDcard is literally my only interface. | 21:42 |
| JPEW | jbo: Ah ya, we do that with a sdk-packagegroup that feeds into both our "developer" image and the SDK, but not our "release" image | 21:43 |
| JPEW | By 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 |
| JPEW | But in the "release" image, it's the minimal set of what you actually need | 21:44 |
| JPEW | jbo: Ah, I'm not sure about that | 21:44 |
| JPEW | Serial port? | 21:44 |
| jbo | that I have | 21:45 |
| jbo | but just the regular serial port to have a shell | 21:45 |
| JPEW | There are programs that can transfer files across the serial terminal | 21:45 |
| JPEW | old tech, but useful :) | 21:45 |
| jbo | I'm just using picocom on that serial port so far | 21:45 |
| jbo | might be worth looking into - could safe me a lot of trouble | 21:45 |
| jbo | how does that work / what should I be looking for? | 21:45 |
| JPEW | zmodem I think? | 21:46 |
| JPEW | I think theres another one too | 21:46 |
| jbo | I 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 |
| JPEW | It's possible some terminal programs have support integrated | 21:47 |
| JPEW | I've not use it much, we usually have ethernet on our devices | 21:48 |
| jbo | same here. | 21:48 |
| jbo | I'll look into that - thanks for the tipp! | 21:48 |
| *** florian__ <florian__!~florian@dynamic-093-131-059-245.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 21:55 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 21:57 | |
| *** starblue <starblue!~juergen@dslb-094-220-106-167.094.220.pools.vodafone-ip.de> has joined #yocto | 22:03 | |
| RP | JPEW: allarch recipes shouldn't have dependencies that change? | 22:10 |
| fray | allarch can change from distro to distro, but not within a single distro (unless something critical like init_manager) changes.. or well it shouldn't change | 22:12 |
| RP | fray: the context here is that a given allarch recipe wouldn't change in a given TMPDIR for different MACHINEs or SDKMACHINEs | 22:15 |
| fray | I have seen cases where someone will set a distro feature or INIT_MANAGER in a machine.. it's wrong, but it can do that | 22:17 |
| JPEW | RP: I traced it back to binutils-cross:do_unpacl | 22:17 |
| fray | but I agree, it shouldn't | 22:18 |
| JPEW | *do_unpack | 22:18 |
| JPEW | do_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 normally | 22:19 |
| JPEW | Supper time though | 22:19 |
| fray | strange | 22:22 |
| jbo | so 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: https://blog.insane.engineer/post/linux_dts_audio_codec/ | 22:22 |
| fray | something changing patches for binutils (or configs) per arch or tune? | 22:23 |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 22:25 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 22:26 | |
| jbo | JPEW, picocom certainly has a "send file" option. | 22:34 |
| jbo | JPEW, seems like I just need something on the device side. looks like `lrzsz` and `kermit` are viable options | 22:34 |
| *** olani- <olani-!~olani@31-208-215-248.cust.bredband2.com> has joined #yocto | 22:50 | |
| *** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has joined #yocto | 22:51 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds) | 22:58 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 22:58 | |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 250 seconds) | 23:04 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 23: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 | |
| JPEW | fray: no, TARGET_ARCH is in PN | 23: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 #yocto | 23:43 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 246 seconds) | 23:54 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!