Monday, 2023-10-02

*** florian <florian!> has quit IRC (Ping timeout: 248 seconds)00:34
*** sakman_ <sakman_!~sakman@> has joined #yocto00:58
*** sakman_ <sakman_!~sakman@> has quit IRC (Remote host closed the connection)00:58
*** sakman <sakman!~sakman@> has quit IRC (Ping timeout: 272 seconds)01:02
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 240 seconds)01:04
*** davidinux <davidinux!~davidinux@> has joined #yocto01: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 #yocto01:18
*** starblue <starblue!> has quit IRC (Ping timeout: 255 seconds)01:43
*** starblue <starblue!> has joined #yocto01:45
*** amitk <amitk!~amit@> has joined #yocto01: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 #yocto02:07
*** amitk <amitk!~amit@> 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!> has joined #yocto02: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 #yocto03: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 #yocto03:16
*** sgw <sgw!~swold@user/sgw> has joined #yocto03:39
*** amitk <amitk!~amit@> has joined #yocto04:19
*** florian <florian!> has joined #yocto04:31
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 255 seconds)04:36
*** amitk <amitk!~amit@> has joined #yocto04:40
*** slimak <slimak!> has joined #yocto04:43
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)05:14
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto05:15
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:18
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 255 seconds)05:22
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto05:30
PhoenixMageAfternoon all05:31
*** Guest98 <Guest98!~Guest98@> has joined #yocto05:44
*** Guest98 <Guest98!~Guest98@> has quit IRC (Quit: Client closed)05:57
*** Guest98 <Guest98!~Guest98@> has joined #yocto05:58
*** mvlad <mvlad!~mvlad@2a02:2f05:8414:c500:7656:3cff:fe3f:7ce9> has joined #yocto06:06
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:25
*** mckoan|away is now known as mckoan06:31
mckoangood morning06:32
WinstonSmith2600So... I was wondering... why does it take longer to do a minimal yocto build than a minimal buildroot build?06:36
mcfriskWinstonSmith2600: 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
*** rfuentess <rfuentess!~rfuentess@2001:861:208:5b0:dd10:27cc:1d08:7eb2> has joined #yocto06:56
*** Guest98 <Guest98!~Guest98@> has quit IRC (Ping timeout: 245 seconds)07:02
*** radanter <radanter!> has joined #yocto07:28
*** louson <louson!~louson@> has joined #yocto07:28
yoctonHi! FYI, Greg Kroah-Hartman does a "Mentorship Session exploring Demystifying the Linux Kernel Security Process" (tomorrow) I thought that might interrest some of you (Sadly it does partially clash with the weekly tech call)07:28
*** Guest98 <Guest98!~Guest98@> has joined #yocto07:28
*** Guest98 <Guest98!~Guest98@> has quit IRC (Quit: Client closed)07:39
mcfriskyocton: yep, and slides are possibly already available from
yoctonmcfrisk: hhoooOOOoo nice! Thanks!07:41
mcfrisk(these were mentioned on oss-security list discussion )07:43
*** Guest98 <Guest98!~Guest98@> has joined #yocto07:54
Guest98I'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
Guest98How 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
mckoanGuest98: we did a complete porting based on L4T for a similar board here:
*** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Ping timeout: 260 seconds)08:17
Guest98mckoan I'll take a look and try to understand. Thank you.08:17
*** mdb977 <mdb977!~mdb977@> has joined #yocto08:17
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)08:23
*** alessioigor <alessioigor!~alessioig@> has joined #yocto08:23
Guest98mckoan 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@> has joined #yocto08:25
*** florian_kc <florian_kc!> has joined #yocto08:26
*** xmn <xmn!~xmn@2600:4040:9390:8c00:f467:5dd2:6c3c:c9b8> has quit IRC (Ping timeout: 248 seconds)08:27
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 248 seconds)08:32
*** khem <khem!> has quit IRC (Quit: Connection closed for inactivity)08:34
mdb977Hello 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!> has joined #yocto08:35
rburtonWinstonSmith2600: 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
TillthemanHi 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
rburtonRP: re numpy, that's just enraging08:37
rburtonRP: and fwiw, whilst upstream moved to meson for the top-level build, that file is still in the tree08:38
RPrburton: it was a bit crazy!08:42
RPrburton: I think I'm going to need help with the 6.5 kernel stability issues08:43
RPrburton: arm has jitterentropy issues but x86 is randomly crashing or something08:43
RPalso see arm LTP OOM08:44
*** tct is now known as jbo08:44
rburtonok i'm about to walk the dog but can you sling bugs at me?08:45
RPrburton: no bugs yet but see the discussion with Bruce on list08:46
*** Kubu_work <Kubu_work!~kubu@2a04:cec0:104d:7cc1:bde5:68d0:d0d7:ef63> has joined #yocto08:50
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:53
*** dacav <dacav!> has joined #yocto08:55
dacavHi. 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 to exist under the installation path of the SDK, which is of course not08:57
dacavthe case.08:57
dacavChicken & Egg problem.08:57
dacavI assume that the -nativesdk should depend on the -native to provide the tools.08:58
LetoThe2ndyo dudX08:58
mcfriskdacav: split the recipe into -native and target one08:58
rburtondacav: remember a nativesdk is still cross-built, you need to depend on native recipes for native tools08:58
dacavmcfrisk: if by target you mean -nativesdk, then it is already split08:59
dacavI 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
rburtondacav: its probably trying to run the binary it just build, instead of the native binary09:00
dacavYes, this is the same conclusion I reached09:00
mcfriskno a -native to build the tooling/code generator which runs on build host, then that is used to compile target and nativesdk recipe09:00
dacavAlso the build system is CMake, and it uses NO_DEFAULT_PATH to avoid searching under the "normal" /usr/lib09:00
mcfrisksigh, CMake is really painful to work with and developers frequently mess it up and extend its use to mix host and target build parts09:01
rburtoncmake 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, themselves09:01
dacavmcfrisk: roger :) Then I'm in the right direction.09:01
dacav(hope no user is named 'roger')09:02
dacavrburton: 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
mcfriskdacav: CMake builds must use the yocto/bitbake/cmake.bbclass generated toolchain file for all paths09:03
dacavmcfrisk: 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 #yocto09:07
mcfriskdacav: 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
mcfriskwith luck things will work, with some more luck QA checks will find worst offenders too09:10
dacavQA checks do not seem to find much.  I think I found the culprit in the CMake using NO_DEFAULT_PATH when using find_program09:11
dacavI'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 #yocto09:13
*** vladest1 <vladest1!> has joined #yocto09:21
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:28
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:29
mischiefdown with cmake, go meson09:31
dacavhaha, yes, I can totally ask upstream to change it.09:34
*** Guest98 <Guest98!~Guest98@> has quit IRC (Quit: Client closed)09:35
dacavWhat 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@> has joined #yocto09:37
dacavAh, found it! :D do_prepare_recipe_sysroot.  Sorry09:38
*** amitk <amitk!~amit@> has joined #yocto09:39
*** vladest1 <vladest1!> has quit IRC (Ping timeout: 260 seconds)09:42
*** mbulut <mbulut!> has joined #yocto09:55
*** mbulut <mbulut!> 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!> has quit IRC (Quit: Client closed)10:26
*** mckoan is now known as mckoan|away10:30
rburtoni found a use for bitbake -b!10:32
rburtondare not count how many years its taken10:32
* dacav learns about -b10:35
dacavrburton: what is the use for it?10:35
dacav*that you found10:35
rburtonextracting variables from many recipes for post-processing, especially when there's multiple versions10:35
rburtonspecifically, getting _all_of the kernel versions that are in core10:36
rburtondon't use -b10:36
rburtonyou (almost) never need -b10:36
dacavThe "WARNING" in the usage text makes me think it is a somewhat plumby tool10:36
*** lars31 <lars31!~lars@> has joined #yocto10:43
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 255 seconds)11:12
ernstpJPEW: hey, what do you think about?
ernstphappened when I built a kernel module before the kernel was built11:15
ernstpif I built the kernel and then the module again it worked11:15
*** WinstonSmith2600 <WinstonSmith2600!> has quit IRC (Ping timeout: 240 seconds)11:20
ernstp(that was with Kirkstone)11:23
*** WinstonSmith2600 <WinstonSmith2600!> has joined #yocto11:38
*** WinstonSmith2600 <WinstonSmith2600!> has quit IRC (Ping timeout: 240 seconds)11:43
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto11:44
*** dvergatal <dvergatal!~dvergatal@> has quit IRC (Read error: Connection reset by peer)11:50
*** dvergatal <dvergatal!~dvergatal@> has joined #yocto11:53
*** Guest98 <Guest98!~Guest98@> has quit IRC (Quit: Client closed)12:04
*** Guest98 <Guest98!~Guest98@> has joined #yocto12:14
*** WinstonSmith2600 <WinstonSmith2600!> has joined #yocto12:19
RPmcfrisk: 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 and
* RP just wondered if you'd seen anything like this? :/12:22
RPI've added more logging in master-next to see if we can catch anything there12:22
mcfriskRP: was there a way to get to the task log files from main stdio? I'm really missing that12:27
*** amitk <amitk!~amit@> has joined #yocto12:29
*** lars31 <lars31!~lars@> has quit IRC (Quit: Client closed)12:30
*** Guest43 <Guest43!~Guest98@> has joined #yocto12:31
*** lars20 <lars20!~lars@> has joined #yocto12:33
*** amitk__ <amitk__!~amit@> has quit IRC (Quit: Lost terminal)12:33
*** Guest98 <Guest98!~Guest98@> has quit IRC (Ping timeout: 245 seconds)12:33
*** lars20 <lars20!~lars@> has left #yocto12:34
mcfriskRP: 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@> has quit IRC (Ping timeout: 248 seconds)12:37
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Ping timeout: 245 seconds)12:42
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:d875:6297:4e81:e577> has joined #yocto12:45
*** amitk <amitk!~amit@> has joined #yocto12:47
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto12:48
*** Guest43 <Guest43!~Guest98@> has quit IRC (Quit: Client closed)12:58
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 255 seconds)12:59
mcfriskRP: 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
RPmcfrisk: there isn't one in this case as it was run outside bitbake13:10
RPmcfrisk: here is one with the testimage log:
*** Guest98 <Guest98!~Guest98@> has joined #yocto13:22
mcfriskRP: the partial serial read logs don't show the login prompt, as if the last line was eaten by some buffering13:22
RPmcfrisk: 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 flushing13:24
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)13:29
*** alessioigor <alessioigor!~alessioig@> has joined #yocto13:29
mcfriskutf8 decoding issue due to ^M in the stream?13:30
mcfriskboth partial logging and login detection happens after utf8 encoding, raw logging without. there is an issue with utf8 decoding of the stream from serial console13:33
*** dacav <dacav!> has quit IRC (Quit: leaving)13:33
RPmcfrisk: possible :/13:34
*** amsobr <amsobr!~amsobr@2a01:14:113:53b0:62f7:1ded:6d26:b629> has joined #yocto13:36
*** xmn <xmn!~xmn@2600:4040:9390:8c00:c1ec:6280:2b2:76c> has joined #yocto13:50
*** Guest98 <Guest98!~Guest98@> has quit IRC (Ping timeout: 245 seconds)13:50
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@> has quit IRC (Quit: KVIrc 5.0.0 Aria
*** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Remote host closed the connection)14:07
*** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto14:08
JPEWernstp: Interesting.... with Kirkstone you say?14:17
mcfriskRP: maybe could help?14:18
*** Piraty <Piraty!~irc@user/piraty> has quit IRC (Quit: -)14:19
*** Piraty <Piraty!~irc@user/piraty> has joined #yocto14:21
RPmcfrisk: I'm trying surrogateescape in my test branch. It is hard to know which one we should use14:24
mcfriskRP: hope this helps. This is poorly documented if it does :(14:32
ernstpJPEW: yes. Seems reproducible14:32
ernstpJPEW: I guess out of tree modules are not super common... ?14:33
JPEWernstp: They happen sometimes14:34
*** WinstonSmith2600 <WinstonSmith2600!> has quit IRC (Ping timeout: 255 seconds)14:41
*** florian_kc <florian_kc!> has quit IRC (Quit: Ex-Chat)14:41
*** khem <khem!> has joined #yocto14:44
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:44
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:44
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:57
JPEWRP, mcfrisk: Maybe it would be helpful to print the raw hex data in the partial boot log?14:58
*** sakman <sakman!~sakman@> has joined #yocto15:07
LetoThe2ndzeddii: 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
mcfriskJPEW: possibly, but there was some resistance to increasing logging data.15:08
JPEWmcfrisk: Ah. Or maybe the qemu_boot_log could be the raw data instead of decoded15:08
mcfriskLetoThe2nd: switch to docker-moby and update to latest from master branch15:09
LetoThe2ndmcfrisk: master of?15:09
zeddiiLetoThe2nd. 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
LetoThe2ndzeddii: all mickledore.15:09
mcfriskLetoThe2nd: meta-virtualization15:09
JPEWWe'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
mcfriskor cherry-pick the patches to docker-moby in master branch. backport has been proposed on mailing list15:10
zeddiiLetoThe2nd. 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
mcfriskJPEW: the boot log is already raw, which is good15:10
*** mdb977 <mdb977!~mdb977@> has quit IRC (Quit: Leaving)15:10
JPEWmcfrisk: If it's the self.log() call, it is not raw15:11
LetoThe2ndzeddii: 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
zeddiiLetoThe2nd. yep. known. will be cherry-picked shortly. Just a few more things to test on my end.15:12
LetoThe2ndzeddii: great! thanks a lot man15:12
mcfriskJPEW: 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 while15:13
JPEWmcfrisk: Hmm, how is it garbled?15:13
mcfriskJPEW: not clear, but python3 decode('utf-8', errors='ignore') is missing the last crucial line for login prompt15:14
*** Guest19 <Guest19!~Guest19@> has joined #yocto15:15
JPEWmcfrisk: That sounds like a line buffering problem15:17
mcfriskJPEW: exactly but where...15:19
mcfriska single read(1024) has the data, conversion to utf8 misses few last lines, raw log data has the login prompt15:20
JPEWmcfrisk: Where is the raw log?15:26
JPEWernstp: Hmm, is your recipe around that I can see it?15:30
tlwoernerqschulz: i've been simply appending to the end of the list the most recent one(s) added (in the README)15:31
tlwoernerthanks for the review, does the earlier rock-pi-s look okay too?15:31
*** slimak <slimak!> has quit IRC (Ping timeout: 248 seconds)15:40
Saurkhem, 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@> has quit IRC (Quit: alessioigor)15:54
*** alessioigor <alessioigor!~alessioig@> has joined #yocto15:55
RPmcfrisk: is really interesting (with the patch on master-next)15:56
qschulztlwoerner: rock-pi-s patch series has some issues15:58
*** geoffhp <geoffhp!> has quit IRC (Remote host closed the connection)16:10
*** chep <chep!> has quit IRC (Read error: Connection reset by peer)16:13
RPrburton: not sure how much you're looking at the logging issue but the above log is very puzzling :/16:13
*** chep <chep!> has joined #yocto16:14
*** florian <florian!> has quit IRC (Ping timeout: 255 seconds)16:22
*** Guest19 <Guest19!~Guest19@> has quit IRC (Quit: Client closed)16:23
rburtonwell clearly it read that last line16:24
rburtonoh its not doing something stupid like not considering the last line because it doesn't get a newline?16:24
RPrburton: why does it think bootlog is empty but self.msg has everything?16:27
RPrburton: the issue is that bootlog is empty but looking at the code, I can't see why16:27
ernstpJPEW: is really exactly like the kernel mod from meta skeleton, except it's in a git repo16:29
*** radanter <radanter!> has quit IRC (Remote host closed the connection)16:37
khemRP: I sent a patch for python3-docutils which would be needed with kernel 6.5 if/when we upgrade16:49
khemkernel-selftest package needs it16:49
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:51
RPkhem: ok, thanks for the heads up. I was wondering what it was connected to so that info helps16:56
khemyeah I have fixed meta-openembedded  to work with 6.5 kernel and it came out of that17:02
*** amitk <amitk!~amit@> has joined #yocto17:11
*** florian <florian!> has joined #yocto17:15
*** amitk_ <amitk_!~amit@> has joined #yocto17:27
landgrafJPEW: 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
JPEWlandgraf: Ya, this has been floating around. I've been looking into it, but it's been hard because I cannot reproduce locally17:34
JPEWWhat branch are you on17:34
landgrafJPEW: master. latest greatest17:35
landgrafJPEW: 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@> has quit IRC (Remote host closed the connection)17:44
*** hrberg <hrberg!> has quit IRC (Quit: - Chat comfortably. Anywhere.)17:45
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)17:45
*** alessioigor <alessioigor!~alessioig@> has joined #yocto17:45
*** hrberg <hrberg!> has joined #yocto17:45
JPEWlandgraf: mmm, I think that's different17:45
JPEWIf you can share you diff that would be helpful17:45
JPEWI need to go eat before I can look though17:46
landgrafJPEW: Enjoy. I'll try to simplify the reproducer17:52
*** florian <florian!> has quit IRC (Ping timeout: 272 seconds)18:51
*** l3s8g <l3s8g!~l3s8g@user/l3s8g> has joined #yocto18: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
ad__JaMa: thanks, trying it19:13
*** Haxxa <Haxxa!> has quit IRC (Quit: Haxxa flies away.)19:15
*** Haxxa <Haxxa!> has joined #yocto19:16
ad__seems not helping. So i have 2 different recipes inside same meta-layer, both "install" a same file19:16
ad__trying to figure out if i can define a precedence, but order of recipe processing seems not changable19:16
ad__dpendences may be involved19:17
JaMais it the same component with 2 different versions?19:18
ad__no, 2 different recipes19:18
ad__different names19:18
ad__both are installing iptables.rules19:18
JaMaaha, then DEFAULT_PREFERENCE nor P_V will work19:18
ad__yeah, isee19:20
ad__thanks anyway19:21
*** goliath <goliath!~goliath@user/goliath> has joined #yocto19:27
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 264 seconds)19:58
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto19:59
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:20
enteso I have go-1.14 included in poky (dunfell) and I'm trying to replace it with 1.20.720:20
enteif I remove the files from poky and replace the directory with the new files, everything works fine20:21
entehowever poking around in poky feels like bad practice so I would rather replace them in my own layer20:21
enteso if I back out my change to poky and put them in my own layer, "inherit go" always pulls in go 1.1420:22
enteI tried adding the new bbclasses to my own layer but that didn't help20:22
enteany hints about how to completely replace a recipe?20:22
rburtonente: 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
entethe package that pulls in go via "inherit go" is in the same layer as the go recipe20:24
entethis layer has priority 20, poky has 520:25
rburtonoh have a look at  There's a GOVERSION which controls what version is preferred.20:25
rburtonhonestly, i'd set priority to the same as oe-core.  anything else is painful.20:25
entegenerally or in this particular case?20:25
rburtonlayer priority is madness20:26
entelayers are madness if you ask me :)20:26
enteI inherited the project like this20:26
rburtoni think i prefer layers to the olden days where 1000+ recipes where in a single folder20:26
entewe 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 620:27
entefeels like someone rolled dice20:28
enteaha! thanks for the tip about GOVERSION, I had found that before and then forgotten all about it20:30
JaMathat'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
JaMakeeping them all uniq and generating BBLAYERS in matching order is additional benefit of that20:31
rburtonente: for layers which add software (like meta-oe or meta-qt5) i'd say the priority should be _identical_ to core20:33
JaMaand as long as they don't do any funny bussiness with BBPATH, then order of BBPATH is matching the layer priorities as well20:33
enterburton: good to know, will mention this to the other people on the project20:34
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 255 seconds)20:37
*** florian <florian!> has joined #yocto20:40
CroftonWHy did we create pseudo again>20:58
JPEWCrofton: I think the requirements were such that nothing existed that would work20:58
Croftonof course more than poky uses it20:59
RPCrofton: fakeroot was the alternative and at the time it couldn't save state between restarts of the process correctly20:59
RPWR donated pseudo which worked and did what we needed21:00
RPso we didn't create it as such, just polished up an existing codebase that was close21:00
*** Minvera2 <Minvera2!~Minvera@user/Minvera> has joined #yocto21:03
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Ping timeout: 255 seconds)21:05
*** slimak <slimak!> has joined #yocto22: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!> has quit IRC (Ping timeout: 240 seconds)22:27
*** GillesM <GillesM!> has joined #yocto22:27
*** prabhakarlad <prabhakarlad!> has joined #yocto22:36
*** prabhakar <prabhakar!> has quit IRC (Quit: Connection closed)23:07
*** prabhakarlad <prabhakarlad!> 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!> has joined #yocto23:13
*** prabhakarlad <prabhakarlad!> has joined #yocto23:13
*** florian <florian!> has quit IRC (Ping timeout: 255 seconds)23:37
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)23:48
*** florian <florian!> has joined #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!