| *** florian <florian!~florian@dynamic-002-243-122-188.2.243.pool.telefonica.de> has quit IRC (Ping timeout: 248 seconds) | 00:34 | |
| *** sakman_ <sakman_!~sakman@99.209.85.164> has joined #yocto | 00:58 | |
| *** sakman_ <sakman_!~sakman@99.209.85.164> has quit IRC (Remote host closed the connection) | 00:58 | |
| *** sakman <sakman!~sakman@208.111.77.233> has quit IRC (Ping timeout: 272 seconds) | 01:02 | |
| *** davidinux <davidinux!~davidinux@45.11.82.203> has quit IRC (Ping timeout: 240 seconds) | 01:04 | |
| *** davidinux <davidinux!~davidinux@45.11.82.201> has joined #yocto | 01:06 | |
| *** brazuca <brazuca!~brazuca@2804:7f4:3598:bdc1:b01b:e1ba:2be7:372c> has quit IRC (Quit: Client closed) | 01:10 | |
| *** Ablu <Ablu!~Ablu@user/Ablu> has quit IRC (Ping timeout: 260 seconds) | 01:18 | |
| *** Ablu <Ablu!~Ablu@user/Ablu> has joined #yocto | 01:18 | |
| *** starblue <starblue!~juergen@dslb-094-221-183-202.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 255 seconds) | 01:43 | |
| *** starblue <starblue!~juergen@dslb-088-078-099-048.088.078.pools.vodafone-ip.de> has joined #yocto | 01:45 | |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 01:58 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6537:4c00:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 272 seconds) | 02:06 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6534:500:2ce:39ff:fecf:efcd> has joined #yocto | 02:07 | |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Quit: Lost terminal) | 02:27 | |
| *** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:71eb:b8e9:8589:9ca5> has quit IRC (Ping timeout: 258 seconds) | 02:34 | |
| *** WinstonSmith2600 <WinstonSmith2600!~WinstonSm@24-116-18-78.cpe.sparklight.net> has joined #yocto | 02:56 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6534:500:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 264 seconds) | 03:02 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6506:6500:2ce:39ff:fecf:efcd> has joined #yocto | 03:04 | |
| *** sgw <sgw!~swold@user/sgw> has quit IRC (Ping timeout: 248 seconds) | 03:08 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 260 seconds) | 03:15 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 03:16 | |
| *** sgw <sgw!~swold@user/sgw> has joined #yocto | 03:39 | |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 04:19 | |
| *** florian <florian!~florian@dynamic-092-229-053-086.92.229.pool.telefonica.de> has joined #yocto | 04:31 | |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Ping timeout: 255 seconds) | 04:36 | |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 04:40 | |
| *** slimak <slimak!~slimak@eu242.internetdsl.tpnet.pl> has joined #yocto | 04:43 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 05:14 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 05:15 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 05:18 | |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Ping timeout: 255 seconds) | 05:22 | |
| *** PhoenixMage <PhoenixMage!~phoenix@65.181.3.195> has joined #yocto | 05:30 | |
| PhoenixMage | Afternoon all | 05:31 |
|---|---|---|
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has joined #yocto | 05:44 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has quit IRC (Quit: Client closed) | 05:57 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has joined #yocto | 05:58 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:8414:c500:7656:3cff:fe3f:7ce9> has joined #yocto | 06:06 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:25 | |
| *** mckoan|away is now known as mckoan | 06:31 | |
| mckoan | good morning | 06:32 |
| Guest98 | morning | 06:34 |
| WinstonSmith2600 | So... I was wondering... why does it take longer to do a minimal yocto build than a minimal buildroot build? | 06:36 |
| mcfrisk | WinstonSmith2600: don't know much about buildroot but yocto compiles the toolchain needed to cross-compile the SW. The linux distro is bootstrapped from scratch. And those dependencies are quite complex. | 06:38 |
| WinstonSmith2600 | Ahh | 06:39 |
| *** rfuentess <rfuentess!~rfuentess@2001:861:208:5b0:dd10:27cc:1d08:7eb2> has joined #yocto | 06:56 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has quit IRC (Ping timeout: 245 seconds) | 07:02 | |
| *** radanter <radanter!~rad@host86-132-34-232.range86-132.btcentralplus.com> has joined #yocto | 07:28 | |
| *** louson <louson!~louson@193.33.56.84> has joined #yocto | 07:28 | |
| yocton | Hi! FYI, Greg Kroah-Hartman does a "Mentorship Session exploring Demystifying the Linux Kernel Security Process" (tomorrow) https://www.linuxfoundation.org/webinars/demystifying-the-linux-kernel-security-process. I thought that might interrest some of you (Sadly it does partially clash with the weekly tech call) | 07:28 |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has joined #yocto | 07:28 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has quit IRC (Quit: Client closed) | 07:39 | |
| mcfrisk | yocton: yep, and slides are possibly already available from https://git.sr.ht/~gregkh/presentation-security/blob/main/security-stuff.pdf | 07:40 |
| yocton | mcfrisk: hhoooOOOoo nice! Thanks! | 07:41 |
| mcfrisk | (these were mentioned on oss-security list discussion https://www.openwall.com/lists/oss-security/2023/10/01/6 ) | 07:43 |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has joined #yocto | 07:54 | |
| Guest98 | I'm trying to get a build for a custom board on the yocto side. I asked for the kernel sources from the company i bought the board from but there is no documentation in it. Is it normal not to have documentation? Should there be? I dont know since i'm a rookie trying to do something on my own. | 08:04 |
| Guest98 | https://github.com/forecr/forecr_xavier_kernel/tree/Jetpack-5.1.2 | 08:04 |
| Guest98 | How should i proceed to implement it on the yocto side? Is there any documentation, video or something i can follow about preparing a custom board? | 08:04 |
| mckoan | Guest98: we did a complete porting based on L4T for a similar board here: https://github.com/koansoftware/meta-aaeon-nvidia | 08:10 |
| mckoan | https://github.com/koansoftware/koan-aaeon-bsp-repo | 08:10 |
| *** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Ping timeout: 260 seconds) | 08:17 | |
| Guest98 | mckoan I'll take a look and try to understand. Thank you. | 08:17 |
| *** mdb977 <mdb977!~mdb977@147.161.138.110> has joined #yocto | 08:17 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 08:23 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 08:23 | |
| Guest98 | mckoan i used dtb's as you shared, but i also have kernel image. I need to override it too. But, Leto told this is illegal. So, i got all the source from the company. I guess, i need to build the kernel as well. | 08:24 |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 08:25 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:26 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:f467:5dd2:6c3c:c9b8> has quit IRC (Ping timeout: 248 seconds) | 08:27 | |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Ping timeout: 248 seconds) | 08:32 | |
| *** khem <khem!uid220931@id-220931.helmsley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 08:34 | |
| mdb977 | Hello together, may I ask what is the binary 'recipe-sysroot-native/usr/bin/nativepython3 'for? Is this the binary for the python3-native package, and if yes, why is it named nativepython3? | 08:34 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:35 | |
| rburton | WinstonSmith2600: a default yocto has more turned on than a default buildroot. you can easily turn stuff off, but we want to be sure things work so they're on by default. | 08:36 |
| Tilltheman | Hi all, is it possible to have a recipe depend on a task of a bbclass, e.g. such that when this recipe is built, all of the recipes inheriting the bbclass also are progressed up to that task (e.g. fetched, configured)? | 08:36 |
| rburton | RP: re numpy, that's just enraging | 08:37 |
| rburton | RP: and fwiw, whilst upstream moved to meson for the top-level build, that file is still in the tree | 08:38 |
| RP | rburton: it was a bit crazy! | 08:42 |
| RP | rburton: I think I'm going to need help with the 6.5 kernel stability issues | 08:43 |
| RP | rburton: arm has jitterentropy issues but x86 is randomly crashing or something | 08:43 |
| RP | also see arm LTP OOM | 08:44 |
| *** tct is now known as jbo | 08:44 | |
| rburton | ok i'm about to walk the dog but can you sling bugs at me? | 08:45 |
| RP | rburton: no bugs yet but see the discussion with Bruce on list | 08:46 |
| rburton | ok | 08:46 |
| *** Kubu_work <Kubu_work!~kubu@2a04:cec0:104d:7cc1:bde5:68d0:d0d7:ef63> has joined #yocto | 08:50 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:53 | |
| *** dacav <dacav!~dacav@82-209-166-158.cust.bredband2.com> has joined #yocto | 08:55 | |
| dacav | Hi. I've got a recipe that I'd like to build for the SDK. As part of the do_compile task, the build system creates a binary which is later used to generate some code. Everything works fine for a -native build, but with -nativesdk I end up with many "No such file or directory". It looks like the code-generating tool expects the ld.so to exist under the installation path of the SDK, which is of course not | 08:57 |
| dacav | the case. | 08:57 |
| dacav | Chicken & Egg problem. | 08:57 |
| dacav | I assume that the -nativesdk should depend on the -native to provide the tools. | 08:58 |
| LetoThe2nd | yo dudX | 08:58 |
| rburton | yes | 08:58 |
| mcfrisk | dacav: split the recipe into -native and target one | 08:58 |
| rburton | dacav: remember a nativesdk is still cross-built, you need to depend on native recipes for native tools | 08:58 |
| dacav | mcfrisk: if by target you mean -nativesdk, then it is already split | 08:59 |
| dacav | I believe I should force the build system of the software I'm packaging to search the executable in the sysroot that provides the dependencies. | 09:00 |
| rburton | dacav: its probably trying to run the binary it just build, instead of the native binary | 09:00 |
| dacav | Yes, this is the same conclusion I reached | 09:00 |
| mcfrisk | no a -native to build the tooling/code generator which runs on build host, then that is used to compile target and nativesdk recipe | 09:00 |
| dacav | Also the build system is CMake, and it uses NO_DEFAULT_PATH to avoid searching under the "normal" /usr/lib | 09:00 |
| mcfrisk | sigh, CMake is really painful to work with and developers frequently mess it up and extend its use to mix host and target build parts | 09:01 |
| rburton | cmake makes it more fun because it doesn't support "build this binary for the build or find it on the host" so everyone reimplements it, or doesn't even bother, themselves | 09:01 |
| dacav | mcfrisk: roger :) Then I'm in the right direction. | 09:01 |
| dacav | (hope no user is named 'roger') | 09:02 |
| dacav | rburton: I can try applying a patch conditionally, to tweak the cmake configuration. Is there a variable which points to the sysroot of the dependencies? I will try to inject that. | 09:02 |
| mcfrisk | dacav: CMake builds must use the yocto/bitbake/cmake.bbclass generated toolchain file for all paths | 09:03 |
| dacav | mcfrisk: I'm using cmake.bbclass. Is that enough or should I do something more? | 09:05 |
| *** Kubu_work <Kubu_work!~kubu@2a04:cec0:104d:7cc1:bde5:68d0:d0d7:ef63> has quit IRC (Quit: Leaving.) | 09:05 | |
| *** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto | 09:07 | |
| mcfrisk | dacav: you need to review all the CMakeFiles and scripts that they use the variables from the generated toolchain file correctly to find binaries, CMake modules, shared libraries, headers and also set the target install paths using variables defined there. | 09:09 |
| *** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Remote host closed the connection) | 09:09 | |
| mcfrisk | with luck things will work, with some more luck QA checks will find worst offenders too | 09:10 |
| dacav | QA checks do not seem to find much. I think I found the culprit in the CMake using NO_DEFAULT_PATH when using find_program | 09:11 |
| dacav | I'm trying to rewire that so it will force the search to the yocto-provided paths. | 09:12 |
| *** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto | 09:13 | |
| *** vladest1 <vladest1!~Thunderbi@mob-194-230-160-195.cgn.sunrise.net> has joined #yocto | 09:21 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 09:28 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 09:29 | |
| mischief | down with cmake, go meson | 09:31 |
| dacav | haha, yes, I can totally ask upstream to change it. | 09:34 |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has quit IRC (Quit: Client closed) | 09:35 | |
| dacav | What is the "opposite" of do_populate_sysroot? That is, when does the recipe take in all the sysroots populated by dependencies? | 09:36 |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has joined #yocto | 09:37 | |
| dacav | Ah, found it! :D do_prepare_recipe_sysroot. Sorry | 09:38 |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 09:39 | |
| *** vladest1 <vladest1!~Thunderbi@mob-194-230-160-195.cgn.sunrise.net> has quit IRC (Ping timeout: 260 seconds) | 09:42 | |
| *** mbulut <mbulut!~mbulut@ip1f120fbc.dynamic.kabel-deutschland.de> has joined #yocto | 09:55 | |
| *** mbulut <mbulut!~mbulut@ip1f120fbc.dynamic.kabel-deutschland.de> has quit IRC (Client Quit) | 09:55 | |
| *** rfuentess <rfuentess!~rfuentess@2001:861:208:5b0:dd10:27cc:1d08:7eb2> has quit IRC (Remote host closed the connection) | 10:16 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 10:26 | |
| *** mckoan is now known as mckoan|away | 10:30 | |
| rburton | i found a use for bitbake -b! | 10:32 |
| rburton | dare not count how many years its taken | 10:32 |
| * dacav learns about -b | 10:35 | |
| dacav | rburton: what is the use for it? | 10:35 |
| dacav | *that you found | 10:35 |
| rburton | extracting variables from many recipes for post-processing, especially when there's multiple versions | 10:35 |
| rburton | specifically, getting _all_of the kernel versions that are in core | 10:36 |
| rburton | don't use -b | 10:36 |
| rburton | you (almost) never need -b | 10:36 |
| dacav | The "WARNING" in the usage text makes me think it is a somewhat plumby tool | 10:36 |
| *** lars31 <lars31!~lars@193.15.95.2> has joined #yocto | 10:43 | |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Ping timeout: 255 seconds) | 11:12 | |
| ernstp | JPEW: hey, what do you think about? https://pastebin.ubuntu.com/p/mpRbphHJWk/ | 11:15 |
| ernstp | happened when I built a kernel module before the kernel was built | 11:15 |
| ernstp | if I built the kernel and then the module again it worked | 11:15 |
| *** WinstonSmith2600 <WinstonSmith2600!~WinstonSm@24-116-18-78.cpe.sparklight.net> has quit IRC (Ping timeout: 240 seconds) | 11:20 | |
| ernstp | (that was with Kirkstone) | 11:23 |
| *** WinstonSmith2600 <WinstonSmith2600!~WinstonSm@24-116-18-78.cpe.sparklight.net> has joined #yocto | 11:38 | |
| *** WinstonSmith2600 <WinstonSmith2600!~WinstonSm@24-116-18-78.cpe.sparklight.net> has quit IRC (Ping timeout: 240 seconds) | 11:43 | |
| *** bhstalel <bhstalel!~bhstalel@193.95.99.58> has joined #yocto | 11:44 | |
| *** dvergatal <dvergatal!~dvergatal@185.53.145.32> has quit IRC (Read error: Connection reset by peer) | 11:50 | |
| *** dvergatal <dvergatal!~dvergatal@185.53.145.32> has joined #yocto | 11:53 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has quit IRC (Quit: Client closed) | 12:04 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has joined #yocto | 12:14 | |
| *** WinstonSmith2600 <WinstonSmith2600!~WinstonSm@24-116-18-78.cpe.sparklight.net> has joined #yocto | 12:19 | |
| RP | mcfrisk: We're seeing some weird issues on the autobuilder where with the 6.5 kernel, it doesn't detect the login prompt appearing in the 1000s window despite it clearly being present in the log on disk :( | 12:20 |
| RP | e.g. https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5833/steps/14/logs/stdio | 12:21 |
| RP | https://autobuilder.yocto.io/pub/failed-builds-data/qemu_boot_log.20231001121414 and https://autobuilder.yocto.io/pub/failed-builds-data/qemurunner_log.20231001121414 | 12:22 |
| * RP just wondered if you'd seen anything like this? :/ | 12:22 | |
| RP | I've added more logging in master-next to see if we can catch anything there | 12:22 |
| mcfrisk | RP: was there a way to get to the task log files from main stdio? I'm really missing that | 12:27 |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 12:29 | |
| *** lars31 <lars31!~lars@193.15.95.2> has quit IRC (Quit: Client closed) | 12:30 | |
| *** Guest43 <Guest43!~Guest98@31.145.189.2> has joined #yocto | 12:31 | |
| *** lars20 <lars20!~lars@193.15.95.2> has joined #yocto | 12:33 | |
| *** amitk__ <amitk__!~amit@58.84.60.207> has quit IRC (Quit: Lost terminal) | 12:33 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has quit IRC (Ping timeout: 245 seconds) | 12:33 | |
| *** lars20 <lars20!~lars@193.15.95.2> has left #yocto | 12:34 | |
| mcfrisk | RP: well there is the ^M on login prompt line, but I doubt that is causing this. could be a timeout to start the actual login shell. | 12:35 |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Ping timeout: 248 seconds) | 12:37 | |
| *** bhstalel <bhstalel!~bhstalel@193.95.99.58> has quit IRC (Ping timeout: 245 seconds) | 12:42 | |
| *** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:d875:6297:4e81:e577> has joined #yocto | 12:45 | |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 12:47 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 12:48 | |
| *** Guest43 <Guest43!~Guest98@31.145.189.2> has quit IRC (Quit: Client closed) | 12:58 | |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Ping timeout: 255 seconds) | 12:59 | |
| mcfrisk | RP: with latest code I've not seen failures like this on qemu. The data pipe to serial console has been reliable and login detection has worked, read() calls have not been blocking. | 13:09 |
| RP | mcfrisk: there isn't one in this case as it was run outside bitbake | 13:10 |
| RP | mcfrisk: here is one with the testimage log: https://autobuilder.yocto.io/pub/failed-builds-data/6.5%20kernel/log.do_testimage.3051530 https://autobuilder.yocto.io/pub/failed-builds-data/6.5%20kernel/qemu_boot_log.20231001114436 | 13:17 |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has joined #yocto | 13:22 | |
| mcfrisk | RP: the partial serial read logs don't show the login prompt, as if the last line was eaten by some buffering | 13:22 |
| RP | mcfrisk: that was what I was thinking too. How does it make it into the log eventually I wonder? I wonder if qemu needs to do something differently with serial flushing | 13:24 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 13:29 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 13:29 | |
| mcfrisk | utf8 decoding issue due to ^M in the stream? | 13:30 |
| mcfrisk | both partial logging and login detection happens after utf8 encoding, raw logging without. there is an issue with utf8 decoding of the stream from serial console | 13:33 |
| *** dacav <dacav!~dacav@82-209-166-158.cust.bredband2.com> has quit IRC (Quit: leaving) | 13:33 | |
| RP | mcfrisk: possible :/ | 13:34 |
| *** amsobr <amsobr!~amsobr@2a01:14:113:53b0:62f7:1ded:6d26:b629> has joined #yocto | 13:36 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:c1ec:6280:2b2:76c> has joined #yocto | 13:50 | |
| *** Guest98 <Guest98!~Guest98@31.145.189.2> has quit IRC (Ping timeout: 245 seconds) | 13:50 | |
| *** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 13:52 | |
| *** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Remote host closed the connection) | 14:07 | |
| *** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto | 14:08 | |
| JPEW | ernstp: Interesting.... with Kirkstone you say? | 14:17 |
| mcfrisk | RP: maybe https://lists.openembedded.org/g/openembedded-core/message/188612 could help? | 14:18 |
| *** Piraty <Piraty!~irc@user/piraty> has quit IRC (Quit: -) | 14:19 | |
| *** Piraty <Piraty!~irc@user/piraty> has joined #yocto | 14:21 | |
| RP | mcfrisk: I'm trying surrogateescape in my test branch. It is hard to know which one we should use | 14:24 |
| mcfrisk | RP: hope this helps. This is poorly documented if it does :( | 14:32 |
| ernstp | JPEW: yes. Seems reproducible | 14:32 |
| ernstp | JPEW: I guess out of tree modules are not super common... ? | 14:33 |
| JPEW | ernstp: They happen sometimes | 14:34 |
| *** WinstonSmith2600 <WinstonSmith2600!~WinstonSm@24-116-18-78.cpe.sparklight.net> has quit IRC (Ping timeout: 255 seconds) | 14:41 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 14:41 | |
| *** khem <khem!uid220931@id-220931.helmsley.irccloud.com> has joined #yocto | 14:44 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 14:44 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 14:44 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:57 | |
| JPEW | RP, mcfrisk: Maybe it would be helpful to print the raw hex data in the partial boot log? | 14:58 |
| *** sakman <sakman!~sakman@99.209.85.164> has joined #yocto | 15:07 | |
| LetoThe2nd | zeddii: just doing some simple experiments with docker, and "docker run --rm hello-world" fails with "http: invalid Host header". environment is qemux86-64. as some people on the web suggested go 1.20.7 is the problem, i rolled back to 1.20.6 but it seems to persist. any pointer? | 15:08 |
| mcfrisk | JPEW: possibly, but there was some resistance to increasing logging data. | 15:08 |
| JPEW | mcfrisk: Ah. Or maybe the qemu_boot_log could be the raw data instead of decoded | 15:08 |
| JPEW | We | 15:08 |
| mcfrisk | LetoThe2nd: switch to docker-moby and update to latest from master branch | 15:09 |
| LetoThe2nd | mcfrisk: master of? | 15:09 |
| zeddii | LetoThe2nd. It's a docker/moby version issue. what release are you on ? I have two pending moby patches for mickledore, but I've been tied up with the kernel uprev last week. | 15:09 |
| LetoThe2nd | zeddii: all mickledore. | 15:09 |
| mcfrisk | LetoThe2nd: meta-virtualization | 15:09 |
| JPEW | We've had trouble with the kernel interrupting the login sequence before. We ended up silencing the kernel on init on the platforms where it was a problem (not QEMU though) | 15:10 |
| mcfrisk | or cherry-pick the patches to docker-moby in master branch. backport has been proposed on mailing list | 15:10 |
| zeddii | LetoThe2nd. yah, you need a couple of bumps, I'm doing them today and also a final round of version bumps shortly. | 15:10 |
| * zeddii gives up. | 15:10 | |
| mcfrisk | JPEW: the boot log is already raw, which is good | 15:10 |
| *** mdb977 <mdb977!~mdb977@147.161.138.110> has quit IRC (Quit: Leaving) | 15:10 | |
| JPEW | mcfrisk: If it's the self.log() call, it is not raw | 15:11 |
| LetoThe2nd | zeddii: np. if its known and not something wrong on my end, then I'm all fine with it. no need to hurry, this is not a blocker. | 15:11 |
| JPEW | (unless that was changed recently) | 15:11 |
| zeddii | LetoThe2nd. yep. known. will be cherry-picked shortly. Just a few more things to test on my end. | 15:12 |
| LetoThe2nd | zeddii: great! thanks a lot man | 15:12 |
| mcfrisk | JPEW: in this case the raw from qemu socket is logged to separate file and shows correct content which even passes as utf8, but when it is read by python select/read loop it seems to get garbled for a while | 15:13 |
| JPEW | mcfrisk: Hmm, how is it garbled? | 15:13 |
| mcfrisk | JPEW: not clear, but python3 decode('utf-8', errors='ignore') is missing the last crucial line for login prompt | 15:14 |
| *** Guest19 <Guest19!~Guest19@31.32.81.187> has joined #yocto | 15:15 | |
| JPEW | mcfrisk: That sounds like a line buffering problem | 15:17 |
| mcfrisk | JPEW: exactly but where... | 15:19 |
| mcfrisk | a single read(1024) has the data, conversion to utf8 misses few last lines, raw log data has the login prompt | 15:20 |
| JPEW | mcfrisk: Where is the raw log? | 15:26 |
| JPEW | ernstp: Hmm, is your recipe around that I can see it? | 15:30 |
| tlwoerner | qschulz: i've been simply appending to the end of the list the most recent one(s) added (in the README) | 15:31 |
| tlwoerner | thanks for the review, does the earlier rock-pi-s look okay too? | 15:31 |
| *** slimak <slimak!~slimak@eu242.internetdsl.tpnet.pl> has quit IRC (Ping timeout: 248 seconds) | 15:40 | |
| Saur | khem, armpit: What's the plan for the nanbield branch in meta-openembedded? Will it remain as is even though it branched long before the actual Nanbield release, or will it sync up with master? | 15:51 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 15:54 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 15:55 | |
| RP | mcfrisk: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5837/steps/14/logs/stdio is really interesting (with the patch on master-next) | 15:56 |
| qschulz | tlwoerner: rock-pi-s patch series has some issues | 15:58 |
| *** geoffhp <geoffhp!~geoff@cpe-107-185-48-203.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 16:10 | |
| *** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer) | 16:13 | |
| RP | rburton: not sure how much you're looking at the logging issue but the above log is very puzzling :/ | 16:13 |
| *** chep <chep!~chep@82-65-36-115.subs.proxad.net> has joined #yocto | 16:14 | |
| *** florian <florian!~florian@dynamic-092-229-053-086.92.229.pool.telefonica.de> has quit IRC (Ping timeout: 255 seconds) | 16:22 | |
| *** Guest19 <Guest19!~Guest19@31.32.81.187> has quit IRC (Quit: Client closed) | 16:23 | |
| rburton | well clearly it read that last line | 16:24 |
| rburton | oh its not doing something stupid like not considering the last line because it doesn't get a newline? | 16:24 |
| RP | rburton: why does it think bootlog is empty but self.msg has everything? | 16:27 |
| RP | rburton: the issue is that bootlog is empty but looking at the code, I can't see why | 16:27 |
| ernstp | JPEW: is really exactly like the kernel mod from meta skeleton, except it's in a git repo | 16:29 |
| *** radanter <radanter!~rad@host86-132-34-232.range86-132.btcentralplus.com> has quit IRC (Remote host closed the connection) | 16:37 | |
| khem | RP: I sent a patch for python3-docutils which would be needed with kernel 6.5 if/when we upgrade | 16:49 |
| khem | kernel-selftest package needs it | 16:49 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 16:51 | |
| RP | khem: ok, thanks for the heads up. I was wondering what it was connected to so that info helps | 16:56 |
| khem | yeah I have fixed meta-openembedded to work with 6.5 kernel and it came out of that | 17:02 |
| *** amitk <amitk!~amit@58.84.60.207> has joined #yocto | 17:11 | |
| *** florian <florian!~florian@dynamic-092-229-053-086.92.229.pool.telefonica.de> has joined #yocto | 17:15 | |
| *** amitk_ <amitk_!~amit@58.84.60.207> has joined #yocto | 17:27 | |
| landgraf | JPEW: Hi. Around? I'm figthing with SDK generation bugs and hit something I've never seen before ' Unable to find package with name 'perl' in SPDX file' . perl is provided by dummy sdk package, should it be in the spdx file target-sdk-provides-dummy.spdx.json? | 17:33 |
| JPEW | landgraf: Ya, this has been floating around. I've been looking into it, but it's been hard because I cannot reproduce locally | 17:34 |
| JPEW | What branch are you on | 17:34 |
| landgraf | JPEW: master. latest greatest | 17:35 |
| landgraf | JPEW: but I've modified dummy-sdk-package because of the bug 14995 . I can either share diff with you or file bugreport... | 17:41 |
| *** amitk <amitk!~amit@58.84.60.207> has quit IRC (Remote host closed the connection) | 17:44 | |
| *** hrberg <hrberg!~quassel@171.79-160-161.customer.lyse.net> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 17:45 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 17:45 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has joined #yocto | 17:45 | |
| *** hrberg <hrberg!~quassel@171.79-160-161.customer.lyse.net> has joined #yocto | 17:45 | |
| JPEW | landgraf: mmm, I think that's different | 17:45 |
| JPEW | If you can share you diff that would be helpful | 17:45 |
| JPEW | I need to go eat before I can look though | 17:46 |
| landgraf | JPEW: Enjoy. I'll try to simplify the reproducer | 17:52 |
| *** florian <florian!~florian@dynamic-092-229-053-086.92.229.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 18:51 | |
| *** l3s8g <l3s8g!~l3s8g@user/l3s8g> has joined #yocto | 18:51 | |
| *** l3s8g <l3s8g!~l3s8g@user/l3s8g> has quit IRC (Remote host closed the connection) | 18:52 | |
| ad__ | is there a way to set a precedence of a recipe over another of the same layer ? | 19:08 |
| JaMa | ad__: DEFAULT_PREFERENCE | 19:12 |
| ad__ | JaMa: thanks, trying it | 19:13 |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has quit IRC (Quit: Haxxa flies away.) | 19:15 | |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has joined #yocto | 19:16 | |
| ad__ | seems not helping. So i have 2 different recipes inside same meta-layer, both "install" a same file | 19:16 |
| ad__ | trying to figure out if i can define a precedence, but order of recipe processing seems not changable | 19:16 |
| ad__ | dpendences may be involved | 19:17 |
| JaMa | is it the same component with 2 different versions? | 19:18 |
| ad__ | no, 2 different recipes | 19:18 |
| ad__ | different names | 19:18 |
| ad__ | both are installing iptables.rules | 19:18 |
| JaMa | aha, then DEFAULT_PREFERENCE nor P_V will work | 19:18 |
| ad__ | yeah, isee | 19:20 |
| ad__ | thanks anyway | 19:21 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 19:27 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 264 seconds) | 19:58 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 19:59 | |
| ente | hi | 20:20 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.233> has quit IRC (Quit: alessioigor) | 20:20 | |
| ente | so I have go-1.14 included in poky (dunfell) and I'm trying to replace it with 1.20.7 | 20:20 |
| ente | if I remove the files from poky and replace the directory with the new files, everything works fine | 20:21 |
| ente | however poking around in poky feels like bad practice so I would rather replace them in my own layer | 20:21 |
| ente | so if I back out my change to poky and put them in my own layer, "inherit go" always pulls in go 1.14 | 20:22 |
| ente | I tried adding the new bbclasses to my own layer but that didn't help | 20:22 |
| ente | any hints about how to completely replace a recipe? | 20:22 |
| rburton | ente: check the layer priority, it should be the same as oe-core so that bitbake just looks at recipe versions. or set PREFERRED_VERSION for the go pieces. Worth checking that it's actually reading your layer... | 20:23 |
| ente | the package that pulls in go via "inherit go" is in the same layer as the go recipe | 20:24 |
| ente | this layer has priority 20, poky has 5 | 20:25 |
| rburton | oh have a look at tcmode-default.inc. There's a GOVERSION which controls what version is preferred. | 20:25 |
| rburton | honestly, i'd set priority to the same as oe-core. anything else is painful. | 20:25 |
| ente | generally or in this particular case? | 20:25 |
| rburton | generally | 20:26 |
| rburton | layer priority is madness | 20:26 |
| ente | layers are madness if you ask me :) | 20:26 |
| ente | I inherited the project like this | 20:26 |
| rburton | i think i prefer layers to the olden days where 1000+ recipes where in a single folder | 20:26 |
| ente | we have a bunch of layers at different priorities and no one told me why, let's say meta-qt5 has prio 7, poky has 5, meta-freescale has 5 and meta-oe has 6 | 20:27 |
| ente | feels like someone rolled dice | 20:28 |
| ente | aha! thanks for the tip about GOVERSION, I had found that before and then forgotten all about it | 20:30 |
| JaMa | that's why (LGE) we set all priorities in generated bblayers.conf, so that we have control over all of them (instead of depending on the default set in layer.conf) | 20:30 |
| JaMa | keeping them all uniq and generating BBLAYERS in matching order is additional benefit of that | 20:31 |
| rburton | ente: for layers which add software (like meta-oe or meta-qt5) i'd say the priority should be _identical_ to core | 20:33 |
| JaMa | and as long as they don't do any funny bussiness with BBPATH, then order of BBPATH is matching the layer priorities as well | 20:33 |
| ente | rburton: good to know, will mention this to the other people on the project | 20:34 |
| *** amitk_ <amitk_!~amit@58.84.60.207> has quit IRC (Ping timeout: 255 seconds) | 20:37 | |
| *** florian <florian!~florian@dynamic-092-229-053-086.92.229.pool.telefonica.de> has joined #yocto | 20:40 | |
| Crofton | WHy did we create pseudo again> | 20:58 |
| Crofton | ? | 20:58 |
| JPEW | Crofton: I think the requirements were such that nothing existed that would work | 20:58 |
| Crofton | https://www.yoctoproject.org/software-item/pseudo/#:~:text=Pseudo%20has%20a%20lot%20of,in%20many%20other%20use%20cases. | 20:59 |
| Crofton | of course more than poky uses it | 20:59 |
| JPEW | Ya | 20:59 |
| RP | Crofton: fakeroot was the alternative and at the time it couldn't save state between restarts of the process correctly | 20:59 |
| Crofton | thanks | 21:00 |
| RP | WR donated pseudo which worked and did what we needed | 21:00 |
| RP | so we didn't create it as such, just polished up an existing codebase that was close | 21:00 |
| *** Minvera2 <Minvera2!~Minvera@user/Minvera> has joined #yocto | 21:03 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 255 seconds) | 21:05 | |
| *** slimak <slimak!~slimak@eu242.internetdsl.tpnet.pl> has joined #yocto | 22:00 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:c1ec:6280:2b2:76c> has quit IRC (Ping timeout: 252 seconds) | 22:05 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 22:11 | |
| *** GillesMMM <GillesMMM!~gilles@116.79.123.78.rev.sfr.net> has quit IRC (Ping timeout: 240 seconds) | 22:27 | |
| *** GillesM <GillesM!~gilles@116.79.123.78.rev.sfr.net> has joined #yocto | 22:27 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 22:36 | |
| *** prabhakar <prabhakar!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Connection closed) | 23:07 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 23:07 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:8414:c500:7656:3cff:fe3f:7ce9> has quit IRC (Remote host closed the connection) | 23:11 | |
| *** prabhakar <prabhakar!~prabhakar@pc.renesas.eu> has joined #yocto | 23:13 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 23:13 | |
| *** florian <florian!~florian@dynamic-092-229-053-086.92.229.pool.telefonica.de> has quit IRC (Ping timeout: 255 seconds) | 23:37 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 23:48 | |
| *** florian <florian!~florian@dynamic-092-229-053-086.92.229.pool.telefonica.de> has joined #yocto | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!