Wednesday, 2022-01-19

*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds)00:00
*** Skinny79 <Skinny79!> has quit IRC (Quit: Connection closed)01:13
*** paulg <paulg!> has quit IRC (Ping timeout: 240 seconds)01:14
*** paulg <paulg!> has joined #yocto01:14
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)01:32
*** qschulz <qschulz!> has joined #yocto01:34
*** rr12zer <rr12zer!> has joined #yocto01:37
*** prabhakarlad <prabhakarlad!> has joined #yocto01:46
*** u1106 <u1106!> has quit IRC (Quit: - Chat comfortably. Anywhere.)01:47
*** u1106 <u1106!> has joined #yocto01:50
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)02:10
*** sakoman <sakoman!> has joined #yocto02:31
*** snapsd <snapsd!> has joined #yocto04:11
snapsdHello all,  I have set SOURCE_MIRROR_URL pointing to my local server + appended few PREMIRRORS for source download04:13
snapsdnow, when fetcher runs, it finds the tar ball on SOURCE_MIRROR_URL, but still try to translate that URL with PREMIRROR...04:14
snapsdis it possible, if fetcher finds tarball on SOURCE_MIRROR_URL, it uses that only and if not, than only move to other PREMIRRORS....04:14
snapsdI know, with own-mirrors, source mirror url is PREMIRROR only.. but still04:14
*** amitk <amitk!~amit@> has joined #yocto04:34
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:34
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)04:46
snapsdanyone? any idea05:06
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)05:39
*** camus <camus!~Instantbi@> has joined #yocto05:40
*** tlwoerner <tlwoerner!> has quit IRC (Ping timeout: 240 seconds)05:46
*** tlwoerner <tlwoerner!> has joined #yocto05:52
*** tlwoerner <tlwoerner!> has quit IRC (Ping timeout: 268 seconds)06:04
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC (Quit: install gentoo)06:19
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto06:20
*** tlwoerner <tlwoerner!> has joined #yocto06:28
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds)06:32
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:58
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:15
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)07:15
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:17
*** Wouter0100 <Wouter0100!> has quit IRC (Read error: Connection reset by peer)07:23
*** Wouter0100 <Wouter0100!> has joined #yocto07:23
*** olani <olani!> has quit IRC (Ping timeout: 256 seconds)07:29
*** olani <olani!~olani@> has joined #yocto07:30
*** dushara <dushara!> has quit IRC (Quit: Leaving)07:33
*** frieder <frieder!> has joined #yocto07:47
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:58
*** rfuentess <rfuentess!> has joined #yocto08:03
ziga_How cann I tell which .dts files a kernel recipe used to create .dtb that is used in hte end? I am asking because there are plenty of .dts files and I don't know which one to patch.08:04
ziga_And one more thing... Do I have to download a kernel repository and use that one in order to do ANY KIND of patching to the device tree?08:05
*** kroon <kroon!> has joined #yocto08:10
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto08:11
*** dev1990 <dev1990!~dev@> has joined #yocto08:26
*** mckoan|away is now known as mckoan08:33
mckoanziga_: look at the kernel recipe08:34
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)08:37
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:37
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:a02:4dcb:a9a:1e46> has quit IRC (Quit: vladest)08:39
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:b812:be26:7125:7354> has joined #yocto08:42
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)08:45
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:46
*** kroon <kroon!> has quit IRC (Ping timeout: 256 seconds)08:47
*** kroon <kroon!> has joined #yocto08:47
*** olani <olani!~olani@> has quit IRC (Remote host closed the connection)08:48
*** olani <olani!~olani@> has joined #yocto08:50
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto08:54
ziga_@mckoan I used "oe-pkgdata-util lookup-recipe kernel" which tells me that recipe for a package "kernel" is "linux-ti-staging" (link: Here I can see the line "require recipes-kernel/linux/", so I assume that it uses "" (link:
ziga_c) somehow... I don't understand this one.09:01
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)09:05
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:06
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)09:11
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:11
*** gsalazar_ <gsalazar_!~gsalazar@> has joined #yocto09:14
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)09:16
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:16
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 256 seconds)09:17
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)09:21
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:22
*** gsalazar_ <gsalazar_!~gsalazar@> has quit IRC (Quit: Leaving)09:24
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto09:25
*** leonanavi <leonanavi!~Leon@> has joined #yocto09:25
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Ping timeout: 256 seconds)09:27
*** xmn <xmn!> has quit IRC (Ping timeout: 268 seconds)09:28
*** olani <olani!~olani@> has quit IRC (Remote host closed the connection)09:37
*** snapsd <snapsd!> has quit IRC (Ping timeout: 250 seconds)09:38
*** olani <olani!~olani@> has joined #yocto09:40
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto09:44
*** osama <osama!> has joined #yocto09:50
*** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has joined #yocto09:51
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)09:51
*** tnovotny <tnovotny!> has joined #yocto09:51
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:52
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)09:53
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)09:56
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:57
*** florian <florian!> has joined #yocto09:58
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)10:01
*** camus <camus!~Instantbi@> has joined #yocto10:01
*** osama <osama!> has quit IRC (Ping timeout: 256 seconds)10:10
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)10:11
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:12
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)10:16
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:17
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)10:21
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:21
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)10:26
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:27
RPkanavin: we're going to wait on michael to look at debian9 I guess? It does seem to be very slow and we both have hung builds now :/10:43
kanavinRP: yes, it does seem as if the CPU cores are 5x slower than they should be10:44
kanavinI was watching your repro build via ssh - it's progressing but at a snail pace10:44
kanavinnot hung exactly10:45
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)10:45
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:45
kanavinRP: in other news, I just sent the upgrade rollup10:46
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)10:50
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:50
RPkanavin: I just triggered the M2 build so I guess this is going in after that :)10:52
kanavinRP: perfect timing ;)10:52
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto10:55
RPkanavin: interesting use of mcextend10:55
RPkanavin: a little worrying as it isn't a real mc and I worry what happens if we add a real mc into the mix10:56
RPkanavin: I like the idea, I just worry we can't use mcextend like this10:57
kanavinRP: this comes from me working on a proof of concept for cross compiling a cross compiler for the target - I used the mcextend extensively there to avoid duplicating .bb files10:58
kanavine.g. add a mcextend variant, and tweak TARGET_SYS in it10:58
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto10:58
kanavinadding recipe variants like this for common configurations is very handy, devupstream is another example10:59
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)10:59
*** camus <camus!~Instantbi@> has joined #yocto10:59
RPkanavin: right, but using the mcextend namespace like that means it would no longer work for real multiconfig work11:01
RPkanavin: we need something which would stack for the multiconfig case correctly11:02
kanavinRP: I see, can you describe a test case where things would break?11:02
kanavinmaybe on the mailing list so that it's preserved and visible11:03
RPkanavin: I'd be curious if the multiconfig tests in oe-selftest work with larger images that include mesa after your change11:03
RPkanavin: the multiconfig tests don't use large images due to time/resource usage constraints11:05
kanavinRP: I can try that11:06
kayterina[m]hello. How can I keep my previous built when I use devtool modify <component>, make changes to the code and devtool deploy <component>? I want to devtool-deploy between two builds without rebuilding11:06
RPkanavin: I'd need to spend more time on a specific test case/reproducer and I may be worrying about nothing but I think it does need to be checked. We may need a different version of the class for non-mc use11:07
*** d0ku <d0ku!> has joined #yocto11:09
kanavinRP: I can try the multiconfig tests meanwhile11:15
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)11:16
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:16
RPkanavin: please, that would be where I'd start11:19
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)11:21
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:21
RPWhy do we find networking failures in a release build :(11:29
RPNot sure it is a network issue. It is always rust-native and cargo-native11:41
RPand no error in the logs11:41
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)11:45
madisoxRP: looks like the crate fetcher issue11:49
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:50
rburton0: rust-native-1.57.0-r0 do_compile - 26m29s (pid 1417874)11:51
* rburton grumbles at rust11:52
*** pgowda_ <pgowda_!> has joined #yocto11:52
coldspark29[m]rburton: I printed the error with `bb.error(f)` as you suggested. The last path processed is12:03
coldspark29[m]I don't see anything odd about it. Everything seems okay with the file name. Here is the full error12:03
coldspark29[m]s/claussenj/user/, s/vti2/mymachine/, s/eppendorf/custom/12:03
coldspark29[m] * rburton: I printed the error with `bb.error(f)` as you suggested. The last path processed is12:03
coldspark29[m]I don't see anything odd about it. Everything seems okay with the file name. Here is the full error12:03
coldspark29[m]It complains about too many values. Maybe lgpl-3.0 exists twice?12:04
*** rob_w <rob_w!> has joined #yocto12:06
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:9caa:1499:5129:dd6e> has joined #yocto12:08
RPmadisox: which crate fetcher issue?12:08
*** kroon_ <kroon_!> has joined #yocto12:10
*** kroon <kroon!> has quit IRC (Ping timeout: 268 seconds)12:11
madisoxRP: the one I sent patches for - crate-fetch.bbclass sets SRCPV to import the crate fetcher, but that fetcher doesn't support srcrevs, and that causes a silent failure (bb throwing an exception) during pstaging_fetch for any sstate package that needs to be fetched from the sstate mirror12:12
RPmadisox: oh, right, yes. I really should remember that :/12:14
RPand it only hits our release builds as we change config to populate a new sstate directory12:14
RPand only early builds as later it is populated12:14
RPmadisox: I've been hoping we could sort the test cases and get that fetcher merged12:15
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has quit IRC (Ping timeout: 256 seconds)12:17
rburtonmoto-timo: py-crypto-native doesn't work12:18
RPabelloni: some useful insight into the rust/cargo sstate warnings ^^^12:18
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto12:18
madisoxRP: I haven't volunteered to do the bitbake integration because I don't know rust well enough to put together those test cases, sorry12:25
RPmadisox: right, neither do I really :(12:28
*** Skinny79 <Skinny79!> has joined #yocto12:37
*** doquiros[m] <doquiros[m]!~doquirosm@2001:470:69fc:105::c8e> has joined #yocto12:38
Skinny79Hi Guys! Made a lot of progress (I think) with your help yesterday, thanks again! According to the docs I should be able to create a systemd service with the following recipe & unit file :  . The files are correctly on the rootfs but the service is never enabled. When I enable it manually at runtime it works just12:41
Skinny79fine. Afaik I don't need 'SYSTEMD_AUTO_ENABLE' because that defaults to 'enable'. I also saw some recipes that manually add the symlink to the FILES_ collection but other do not.12:41
*** armpit__ <armpit__!> has joined #yocto12:42
*** darknighte_ <darknighte_!sid214177@user/darknighte> has joined #yocto12:42
*** rsalveti_ <rsalveti_!> has joined #yocto12:42
*** pgowda__ <pgowda__!> has joined #yocto12:42
*** NishanthMenon_ <NishanthMenon_!> has joined #yocto12:42
*** chrfle_ <chrfle_!> has joined #yocto12:42
*** mrnuke_ <mrnuke_!~mrnuke@2601:2c1:8501:182d::c66> has joined #yocto12:42
*** dkl_ <dkl_!> has joined #yocto12:42
*** Bardon_ <Bardon_!~Bardon@user/Bardon> has joined #yocto12:43
*** rfs613- <rfs613-!> has joined #yocto12:43
*** rburton_ <rburton_!rburton@user/rburton> has joined #yocto12:43
*** bluelightning_ <bluelightning_!~paul@2406:e003:151f:d701:4144:c8c8:67ba:4419> has joined #yocto12:43
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0::f824> has joined #yocto12:44
*** michalkotyla_ <michalkotyla_!> has joined #yocto12:44
*** frosteyes2 <frosteyes2!~frosteyes@> has joined #yocto12:45
*** armpit <armpit!> has quit IRC (Ping timeout: 240 seconds)12:46
*** _whitelogger <_whitelogger!> has quit IRC (Ping timeout: 240 seconds)12:46
*** beneth <beneth!~beneth@2001:41d0:c:a71:1000:25::> has quit IRC (Ping timeout: 240 seconds)12:46
*** darknighte <darknighte!sid214177@user/darknighte> has quit IRC (Ping timeout: 240 seconds)12:46
*** Habbie <Habbie!> has quit IRC (Ping timeout: 240 seconds)12:46
*** frosteyes1 <frosteyes1!~frosteyes@> has quit IRC (Ping timeout: 240 seconds)12:46
*** Bardon <Bardon!~Bardon@user/Bardon> has quit IRC (Ping timeout: 240 seconds)12:46
*** NishanthMenon <NishanthMenon!> has quit IRC (Ping timeout: 240 seconds)12:46
*** bluelightning <bluelightning!~paul@2406:e003:151f:d701:f:9c5f:9d81:d33f> has quit IRC (Ping timeout: 240 seconds)12:46
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::f824> has quit IRC (Ping timeout: 240 seconds)12:46
*** dkl <dkl!> has quit IRC (Ping timeout: 240 seconds)12:46
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 240 seconds)12:46
*** chrfle <chrfle!> has quit IRC (Ping timeout: 240 seconds)12:46
*** rsalveti <rsalveti!> has quit IRC (Ping timeout: 240 seconds)12:46
*** rfs613 <rfs613!> has quit IRC (Ping timeout: 240 seconds)12:46
*** pgowda_ <pgowda_!> has quit IRC (Ping timeout: 240 seconds)12:46
*** rburton <rburton!rburton@user/rburton> has quit IRC (Ping timeout: 240 seconds)12:46
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 240 seconds)12:46
*** mrnuke <mrnuke!~mrnuke@2601:2c1:8501:182d:4191:bd77:8e38:4433> has quit IRC (Ping timeout: 240 seconds)12:46
*** michalkotyla <michalkotyla!> has quit IRC (Ping timeout: 240 seconds)12:46
*** chrfle_ is now known as chrfle12:46
*** pgowda__ is now known as pgowda_12:46
*** armpit__ is now known as armpit12:46
*** rburton_ is now known as rburton12:46
*** darknighte_ is now known as darknighte12:46
*** NishanthMenon_ is now known as NishanthMenon12:46
*** rsalveti_ is now known as rsalveti12:46
*** _whitelogger <_whitelogger!> has joined #yocto12:46
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0::f824> has quit IRC (Client Quit)12:47
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto12:47
*** nerdboy <nerdboy!~nerdboy@> has joined #yocto12:47
*** Habbie <Habbie!> has joined #yocto12:47
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::f824> has joined #yocto12:47
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 268 seconds)12:48
*** rfs613- <rfs613-!> has quit IRC (Ping timeout: 256 seconds)12:49
*** mcfrisk <mcfrisk!> has quit IRC (Ping timeout: 256 seconds)12:49
*** rfs613 <rfs613!> has joined #yocto12:49
*** mcfrisk <mcfrisk!> has joined #yocto12:51
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:52
*** camus1 <camus1!~Instantbi@> has joined #yocto12:52
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)12:52
*** camus1 is now known as camus12:52
smurrayfray: when you're around, could you elaborate on the qtbase failures you mentioned last week?  Someone else building AGL is seeing failures there that I don't see13:00
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)13:13
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:14
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)13:18
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:19
*** beneth <beneth!~beneth@2001:41d0:c:a71:1000:25::> has joined #yocto13:25
RPrburton: did you ever work out that sstate failure improvement patch?13:38
RPrburton: I've sent a blind attempt at improving it13:44
coldspark29[m]I am confused about linux-fscl-imx. If you look at the recipe, you see that linux-fscl and linux-imx are required. I added all our custom patches to the lf-5.10.y branch of linux-imx, but it seems that linux-fslc is built13:45
coldspark29[m] I guess I patched the wrong kernel source?... (full message at
smurraycoldspark29[m]: at least on master, linux-fslc-imx looks like uses a branch in linux-fslc.git? (based on KBRANCH = "5.10-2.1.x-imx")13:50
moto-timorburton: did you get any further with py-native host ssl contamination theory?13:50
coldspark29[m]smurray: Yes, but it includes, which includes So I thought I would need to patch linux-imx as before on gatesgarth13:51
smurraycoldspark29[m]: it's what SRC_URI points at that matters, and sets it to linux-fslc.git13:52
smurraycoldspark29[m]: that plus the KBRANCH set what gets used13:52
*** florian_kc <florian_kc!> has joined #yocto13:53
coldspark29[m]smurray: Yeah and in the SRC_URI points to the NXP kernel. I assume since the is included at the top, its SRC_URI is overwritten by the linux-fslc one?13:54
coldspark29[m]I think I need to learn something about inheritance in Yocto13:54
smurraycoldspark29[m]: yes.  When in doubt check variable values in the 'bitbake -e <recipe>' output or with the newer bitbake-getVar tool13:55
coldspark29[m]So why is it including linux-imx? Is it just getting the patches from there?13:55
*** sakoman <sakoman!> has joined #yocto13:59
*** codavi <codavi!~akiCA@user/akica> has joined #yocto14:04
coldspark29[m]Well, I guess this is a good opportunity to learn about all of that :D14:04
coldspark29[m]How security patches are applied if they are not in the mainline or NPX branch14:04
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto14:05
smurraycoldspark29[m]: by the maintainer or by an enduser like yourself?14:05
coldspark29[m]By the maintainer14:05
coldspark29[m]This kernel seems to be patched together from different sources. It is a bit complex, but a good learning opportunity14:06
coldspark29[m]In Gatesgarth or Hardknott there was just linux-imx or linux-fslc14:06
coldspark29[m]This is like a fused kernel14:07
smurraycoldspark29[m]: I assume he has some scripting to manage it14:07
coldspark29[m]s/fused/kernel/, s/kernel/fusion/14:07
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto14:08
smurraycoldspark29[m]: if you have questions about how Andrey puts those kernels together, perhaps email him or post to the meta-freescale mailing list14:08
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds)14:11
*** kroon_ <kroon_!> has quit IRC (Remote host closed the connection)14:12
*** kroon <kroon!> has joined #yocto14:12
RPmadisox: I've pushed something to master-next to try and resolve this14:23
RPsome really basic tests14:23
qschulzSkinny79: you're missing `inherit systemd` I think14:35
*** kroon_ <kroon_!> has joined #yocto14:37
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:b812:be26:7125:7354> has quit IRC (Remote host closed the connection)14:38
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:b812:be26:7125:7354> has joined #yocto14:38
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)14:39
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:39
*** kroon <kroon!> has quit IRC (Ping timeout: 250 seconds)14:40
Perceval[m]Hello all :)14:42
Perceval[m]Has anyone experienced a significant gap in runtime performance between nvidia Jetpack stock OS and the meta-tegra OS on Jetson TX2 board?14:42
Perceval[m]My camera gige software (IDS ueye) has no issue with the basic install and no tweaking on the jetpack stock OS but when I run it on the meta-tegra based OS the software starts dropping frames.14:42
Perceval[m]We profiled the app on the jetpack OS using Nsight Systems (I really recommend this tool if you are having performance issues. It's really well integrated.) Cleaned up the software.  Our software was working perfectly on the jetpack even while profiling.14:42
Perceval[m]When we deployed the software on the meta-tegra based OS there was almost no difference between (10% improvement I would say) before and after all the performance improvements14:42
Perceval[m]If someone has any idea that could help us ! That would be awesome ! :)14:43
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)14:43
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 256 seconds)14:43
Skinny79qschulz ohmy.. reading and mixing all kind of blogs posts is not helping in this case.. that was it, thanks!14:53
*** xmn <xmn!> has joined #yocto14:54
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:59
*** jatedev <jatedev!~jatedev@> has quit IRC (Quit: Client closed)15:01
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)15:02
*** jatedev <jatedev!~jatedev@> has joined #yocto15:07
rburtonmoto-timo: i tried adding -Bsymbolic-functions to openssl-native but that didnt appear to work15:08
moto-timorburton: also a report about sdk broken... but that smells like a rust sdk issue15:09
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:17
vdI create multiple psplash-{foo,bar} alternatives but the build system still complain about them even though I set PREFERRED_PROVIDER_psplash = "psplash-foo". Isn't it the correct way to do it?15:21
qschulzvd: "complains about them" ?15:24
vdqschulz: yes a warning stating that there are multiple alternatives for the psplash package15:25
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 240 seconds)15:26
RPvd: your alternatives are overlapping somehow and bitbake isn't happy about it or both aren't providing everything they need to15:38
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)15:39
vdRP: in a psplash_git.bbappend I'm simply adding a few SPLASH_IMAGES += "file://psplash-foo-img.h;outsuffix=foo". My distro then sets PREFERRED_PROVIDER_psplash = "psplash-bar". Isn't it the correct way to do it?15:42
*** kroon_ <kroon_!> has quit IRC (Quit: Leaving)15:43
rburtonwhere is psplash-bar defined?15:44
vdrburton: same as for psplash-foo with s/foo/bar/ obviously15:46
vd(psplash-foo, psplash-bar are just example names of psplashes I have)15:47
RPvd: what are "psplash-foo" and "psplash-bar" though? You've changed the PN for the recipe?15:47
vdRP: isn't it how you're supposed to add custom splash screens? I might be wrong. I looked at a few examples and they seem to do the same, then setting SPLASH = "psplash-bar" in an image recipe15:49
vdI understood that the psplash recipe was somehow dynamically adding alternatives to the main psplash package15:50
vdShould the distro set a default SPLASH ?= "psplash-foo" instead of PREFERRED_PROVIDER_psplash?15:53
RPvd: I had to look at what the recipe is doing as the information above is very confusing. The psplash recipe adds multiple PACKAGES15:54
RPvd: you do not select things in the PACKAGES/runtime namespace with PREFERRED_PROVIDER which is the PN namespace15:54
RPvd: so yes, changing SPLASH would be more appropriate15:56
*** d0ku <d0ku!> has quit IRC (Ping timeout: 268 seconds)15:57
vdRP: sorry about the confusion, but to be fair this package is quite confusing itself.15:58
vdBut I understand it's just doing dynamically what you could do with PACKAGES = "${PN}-foo ${PN}-bar", thank you.16:01
RPvd: writing up an example of using it for the manual would be great now you understand it! ;-)16:03
vdRP: sure. What's the best place for it?16:05
RPvd: not sure, probably a new section in the development tasks going from memory?16:06
vdRP: btw do you think you could consider replying to the patches on the mailing list, so that a contributor knows if the bad has been applied or not?16:06
vdRP: I've sent two patches for beaglebone-yocto a few days ago without follow-up16:07
vds/bad/patch/ (I don't know how that came out)16:08
vdInstead of quietly applying the patch I mean.16:08
RPvd: you're asking me to send an extra 4000 emails a year?16:09
vdRP: didn't you do it for the kernel?16:10
rburtonRP: i'm sure jonmason will be quick to point out that if you use lore/b4/etc, it can send those for you16:11
RPrburton: in that case someone else can just script it and make it work as it is so easy to do16:11
*** amitk <amitk!~amit@> has joined #yocto16:11
rburtonyeah, i know you have a pile of local scripting to manage patches-on-list16:11
RPrburton: I do have an email from jon to look at some details on that stuff16:12
vdI rarely saw a kernel patch applied with a reply, yet I bet these "Applied, thanks." messages are automatic.16:12
RPbut people really don't want an extra 4000 emails on list and the email they really want is why their patch is being ignored, not that it merged16:12
vdthat's not really the problem here...16:13
RPvd: ok, so what is the problem?16:13
vdFirst problem is that the yocto MLs are quite annoying with their digest configs and footer. Then replying to an email for notifying that the patch is applied is part of a thread, that won't bother anyone16:14
RPThe reason I get a little "touchy" on this subject is that basically people want me to do a ton of extra work. I don't know where this time comes from.16:14
RPvd: I can tell you they would bother me as I don't use digests16:14
RPI know they will annoy others too, we've discussed this before16:14
qschulzRP: I remember there was some discussion about fixing a patchwork instance somewhere?16:15
frayOr, you can just watch master-next...  that's what I do16:15
vdRP: So you're basically saying that you don't want to notify when a patch is applied, because it will bother a few people?16:16
RPqschulz: still in progress and I'm getting very annoyed/frustrated about how long it is taking16:16
smurrayfray: those intermittent qtbase errors you mentioned last week, do you recall if they were from linking?16:17
jonmasonhonestly, b4 and lei are your friends16:17
RPvd: I don't want to do it as it is a fair chunk of work. Even automation isn't as easy/good as anyone thinks it is. If it were, patchwork would be easy too16:17
fraysmurray: linking and referencing a file, but I forget what file16:18
rburtonassuming your patches are in local branches, rebase onto latest master. when the branch disappears, they were merged.16:18
jonmasonIt won't take an hour, and you can use any email reader you want16:18
jonmasonand if your keys get triggered, it'll add the whole thread to your inbox16:18
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto16:18
fraysmurray: we ended up doing a bbappend to qtbase, setting PARALLEL_MAKEINST = "-j 1" and then replacing EXTRA_OEMAKE:task-install = "...." using PARALLEL_MAKEINST instead of PARALLE_MAKE16:19
smurrayfray: the log I've been given has a lot of "DWARF error: could not find variable specification at offset X" errors16:19
jonmasonand you can add more at any time.  For example, I started tracking the stuff in tunes now just by adding a single line16:19
RPYou know I'm actually really close to just walking away from this all. If its all so damn easy, someone else can just step up and do it all.16:19
jonmasonRP: I'm just trying to help16:20
* zeddii has the same feeling about things as RP :)16:20
smurrayfray: I'm hesitant to offer that as a solution as the person with the issue is building on a developer laptop ;)16:20
jonmasonok, if I can get zeddii to convert, would that work for everyone that it is trivial to learn?16:20
frayIn reality it's far easier to have people actually monitor the work.. i.e. go to (or openembedded) and look at master-next..16:20
fraythat is 100% how I watch if my patches have been accepted or the status.. takes me seconds to do it16:21
vdsmurray: who's that?16:21
fraywe get it on our container build systems16:21
smurrayfray: someone attempting to build AGL16:21
RPjonmason: I have your email about b4/lei in my inbox marked as important and need to look at properly16:21
smurrayvd: someone attempting to build AGL16:21
RPI just don't get the time :(16:21
jonmason`b4 ty` automatically emails in the thread for patches that have been applied16:21
jonmasonthats what I'm doing now for meta-arm16:22
qschulzjust for the sake of completeness, Buildroot does the extreme opposite by sending a mail as answer to the original thread + a mail which notifies a new commit has made it to the X branch16:22
jonmasonRP: you'll never have the time.  you don't have time to properly sleep as it is16:22
qschulzand I'm frankly annoyed by it, every monday I've like 500 mails from Buildroot over the weekend :)16:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)16:22
RPzeddii: the trouble is people think I'm joking and I'm not. I don't know if I want to keep doing this :(16:22
vdRP: well I obviously didn't mean to piss you off. I just have trouble understand this different workflow for yocto since you actually are a kernel maintainer.16:23
RPvd: we built yocto project differently from the kernel and I don't think the kernel is right about everything.16:23
qschulzRP: I think it's always going to be the issue that people have so many different workflows and whatever the upstream project (or its maintainer(s))  picks as workflow, it'll always bother people16:24
frayevery projects workflow is different.. it's the user's responsibility to adapt to the communities/maintainers workflow16:25
*** zpfvo <zpfvo!~fvo@> has joined #yocto16:27
fraysmurray: BTW the message I was seeing most was "Makefile:144: recipe for target 'sub-dbus-install_subtargets' failed"16:27
RPqschulz: this is the challenge. If I started replying to patches I could probably only do it privately as people wouldn't want the list spam. Even then I'd need an exclusion list for those people who asked not to get such a reply (and yes, there would be some)16:27
* rburton decides not to lob the gitlab-shaped grenade into the room :)16:27
rburtonarguably, if b4 was used, people who object to the replies can at least then filter them all out relatively easily16:28
fraysmurray: what was happening was a file either already existed (so it didn't overwrite and failed) or it DIDN'T already exist to copy it over..16:28
rburtonbut that does mean RP rewriting his workflow to use b416:28
RPit would mean RP having time to even think about this stuff16:28
rburtonwhich may be a net win in the long term but is a time sink in the short16:28
vdproblem is that you send a patch, you can no reply, the patch being good or bad. Then what? You come bother the maintainer on IRC.16:28
rburtonvd: ideally the sender pings the list first instead of bothering on irc16:29
frayvd -- or you look at the git repository.. if it's not merged into -next within a week.. ping..16:29
smurrayfray: this log I'm looking at has a failure down in the qdbus stuff, but not exactly that target16:29
Saurvd: You do as fray said, you monitor master-next and master.16:29
RPvd: what happens is that either you need it merge or see it in master-next. If it fails for some reason you generally get a reply. If it languishes most people ping in reply to the message and I realise it got lost and do something16:29
fraysmurray: there is definitely something wrong with the dbus stuff in qtbase.. like I said, it's not always int he same place.. but in my case 90% of the reports were in that place16:29
vdI don't understand this point about people being annoyed by too many emails. That's a mailing list for patches. What's the matter?16:30
jonmasonRP: if I wrote a script to take everything off a mailing list (e.g., oe-core) and apply it to a tree, throw it in a cronjob and run it for a week or so to prove it works.  would that be a good example for you?16:30
RPsome people reply to the message losing the mail id and that *really* annoys me as I then have to find the original mail as my threading doesn't work. I tend not to complain though as that is my problem16:30
rburtonjonmason: you're wildly over-estimating how good 50% of the patches are16:30
smurrayfray: okay.  I'll perhaps get them to try a build with it at -j 1 to see16:31
zeddiijonmason: except that's pulling in all patches. regardless of their quality16:31
jonmasonlol, probably16:31
RPjonmason: no. I can't just accept some random script I wasn't party to writing as I'm the one left trying to use/maintain it16:31
fraysmurray: we found if we just switch to -j1, the do_compile moves to HOURS..  but if we do it only for do_install issue is fine and the time difference is "reasonable".. again your config may vary16:31
jonmasonRP: I'm not saying it's yours, I'm saying as an example for you to modify.  a starting point to show you it's useful16:32
RPEven the reply to patch stuff is difficult as a lot of the time I end up correcting spelling mistakes and so on so the patch doesn't match the original shortlog and so on16:32
smurrayfray: hrm, the failure I've been pointed at is in do_compile, though, so perhaps it's different16:32
frayup different then.  I've not seen any do_compile failures (I'm speaking very much of honister BTW)16:33
*** fitzsim <fitzsim!> has quit IRC (Remote host closed the connection)16:33
smurrayfray: this is dunfell, but would be similar qt version, I imagine16:33
frayin gatesgarth, we DID see do_compile as well as do_install.. so that required the -j 1.. and a lot of upset people that their build times jumped by 2-3 hours16:33
smurrayfray: if I could reproduce it myself it'd be a lot easier, but I've never seen it16:34
qschulzrburton: I've stumbled upon sourcehut recently too, mailing list based reviews and I read somewhere ("sources tell me" kinda) that they were tracking the result of the patch on the mailing list or something?16:34
fraywe see it about 1 out of every 10 builds.. (maybe even less honestly).. but when it happens it's catastrophic to automated building..16:34
smurrayfray: yeah, that's a pretty high frequency16:35
qschulzrburton: just wanted to add this, not start a new debate though :)16:35
frayI should clarify when I say 10 builds, we do 1 "build" a day and inside of that 1 build is probably 20+ configurations..16:35
frayso it's pretty rare..b ut we'll occasionally see it with multiple trys.. then it just goes away for 2 weeks16:36
fraywe've not seen any failures (honister) since moving it exclusively to -j 1 in do_install though.  I doubt it's "fixed", but it's "better"16:37
*** tnovotny <tnovotny!> has quit IRC (Remote host closed the connection)16:42
RPrburton, jonmason: - qemuarm64 on the release build taken out by a network glitch :(16:42
vdRP: I'm definitely not telling you how to do your job. I am also grateful for what you're doing with Yocto. I'm just giving a feedback as a modest contributor. Even though each project has a different workflow, it seems like the tooling for yocto isn't appropriate and/or you might have too much on your plate and might need an extra hand for maintainership. Sorry for bringing this up.16:42
smurrayfray: okay, good to know, as we'll be bumping AGL to kirkstone in the not too distant future, so it might be something we see then16:42
RPvd: I understand the request. Sadly it just isn't as easy as you'd think and we do have a significant lack of maintainers :(16:43
RPI think we need to write off 3.5 M2 rc116:44
* rburton shakes fist at networks in general16:46
RPI think I can see at least four issues in that build16:49
RPand sadly I think the best way to fix some of them is heavy rewriting on some core bits of bitbake16:49
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto16:50
*** ferlzc57 <ferlzc57!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto16:51
*** dev1990 <dev1990!~dev@> has joined #yocto16:53
*** ferlzc95 <ferlzc95!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto16:54
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)16:55
*** ferlzc95 <ferlzc95!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Client Quit)16:55
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Ping timeout: 256 seconds)16:55
*** ferlzc57 <ferlzc57!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Ping timeout: 256 seconds)16:56
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto16:56
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Client Quit)16:57
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto16:58
vdTo ask for a following on a patch, do you guys prefer to reply to the thread, resending the series with a prefix such as RESEND?16:59
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)16:59
rburtonvd: a 'ping' is sufficient16:59
*** zpfvo <zpfvo!~fvo@> has joined #yocto16:59
ferlzchello I'm trying to create a recipe on (Yocto 3.3) for an project using Makefile. I'm suck on a missing library : <libpq-fe.h> . I tried to in my recipe the following DEPENDS = "postgresql" but it still no getting to compile. Any suggestion on where I should look/tweak to make it work ?17:00
rburtonferlzc: most likely you're not using pkgconfig to find the postgresl headers, and they're not in the default search path17:01
vdrburton: like you literally reply 'ping' to your own patch?17:02
rburtonpretty much17:03
RPvd: since I know about this one I'll take a look at them17:04
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Quit: Client closed)17:04
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto17:05
qschulzvd: e.g.
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)17:07
vdThe biggest (and more interesting) challenge in FOSS to me is the mixture of culture and the language barrier. I can write things that seem offending when I don't mean to, and sometimes I see offense when there's none.17:08
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto17:18
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Quit: Client closed)17:21
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)17:22
*** frieder <frieder!> has quit IRC (Read error: Connection reset by peer)17:27
vdqschulz: I still have the same psplash message: "Warn: update-alternatives: psplash has multiple providers with the same priority" even though the distro sets SPLASH ?= "psplash-foo".17:30
RPvd: Set ALTERNATIVE_PRIORITY_psplash-foo to something17:31
*** rfuentess <rfuentess!> has quit IRC (Quit: CHELAS!)17:33
RPvd: btw, for the docs if you don't know where it should go, just write the section in an email and mail to the docs list. michaelo and/or qschulz or someone else can find where it should be17:33
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:34
vdRP: got it.17:34
vmesonPerceval[m]: is seems that there isn't anyone here with relevant meta-tegra performance experience, maybe try the yocto email list and provide more info such as kernel versions and a simple reproducer if possible.17:46
Perceval[m]okay, thank you for the hint :)17:48
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)17:50
*** fitzsim <fitzsim!> has joined #yocto17:55
ziga_Where should variable PREFERED_PROVIDER be set? I saw a lot of exaples where this variable is used in "conf/local.conf" but i don't like to put it there... Is there any better file where I can put it?17:55
rburtonyour distro conf17:56
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto17:56
ziga_So basically in any kind of .conf file? If it is insice conf/local.conf we would say that this is a "poking" approach? This approach is not the correct one and should be for testing only?17:57
rburtonlocal.conf should be as minimal as possible, yes17:58
rburtonideally, you have your own distro config for the policy stuff like that17:58
rburtonwell, some things are machine-specific, so can go in the machine conf17:59
rburtonlike 'what boot loader do i use'17:59
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)18:02
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto18:03
*** mckoan is now known as mckoan|away18:03
ziga_Ok. In mmy case I have no machine .conf file so I can only use distro currently. Thank you.18:04
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Client Quit)18:05
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto18:05
*** neverpanic <neverpanic!> has quit IRC (Quit: reboot)18:34
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)18:35
*** neverpanic <neverpanic!> has joined #yocto18:37
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto18:43
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)18:52
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto18:54
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:9caa:1499:5129:dd6e> has quit IRC (Remote host closed the connection)19:16
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto19:16
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto19:19
*** florian_kc <florian_kc!> has joined #yocto19:27
*** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Quit: Client closed)19:28
*** Dhruvagole[m] is now known as Dhruvag2000[m]19:33
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)19:35
*** tlwoerner <tlwoerner!> has quit IRC (Remote host closed the connection)20:03
*** tlwoerner <tlwoerner!> has joined #yocto20:04
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto20:05
*** leonanavi <leonanavi!~Leon@> has quit IRC (Ping timeout: 240 seconds)20:08
jonmasonzeddii: thanks for fixing dtc stuff!20:20
*** leonanavi <leonanavi!~Leon@> has joined #yocto20:33
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)20:44
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto20:46
ziga_Can I require/include a one machine's .conf file inside the other machine's .conf file?20:50
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Read error: Connection reset by peer)20:51
*** pabigot <pabigot!> has quit IRC (Ping timeout: 240 seconds)20:53
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds)20:55
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)20:55
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)20:56
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto20:57
*** leonanavi <leonanavi!~Leon@> has quit IRC (Ping timeout: 240 seconds)21:00
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Client Quit)21:01
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Ping timeout: 240 seconds)21:01
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto21:04
kergothziga_: yes, just remember to set MACHINEOVERRIDES if you also want overrides in recipes to take effect for both machines21:05
ziga_@kergoth Thank you. I thought that include/require is only applicable to the .inc files! :D21:06 is just a convention for the file being included, same syntax as .bb, but any bitbake file can be included, even a bbclass (inherit is shorthand for require classes/foo.bbclass with a bit of wrapper logic)21:07
*** pabigot <pabigot!> has joined #yocto21:07
kergothjust remember that you want to use the full path fromt he root of the repo for your inclusion21:07
kergoththat is, don't require somemachine.conf, but require conf/machine/somemachine.conf21:07
*** leonanavi <leonanavi!~Leon@> has joined #yocto21:08
ziga_Yes. I understand. I can use conf/machine/ part for all the machines from all the layers? Even for the layers that are downloaded additionally from Openembedded layer index for example? Does bitbake somehow see them as all being stored inside "conf/machine/" ?21:11
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)21:13
frayI've got a recipe that has an anonymous python section looking to see if a file pointed to by a variable exists.  If it doesn't then it does a bb.parse.SkipRecipe w/ a message21:15
fraythe problem is I create the file.. and it never re-runs the anon python, it caches that the recipe isn't available.21:15
frayHow can I deal with this?21:15
fray(the purpose of the recipe is to take a binary firmware blob provided by the user.. so we can't "build it", and I don't want to wait until it tries to use it to warn the user it's missing -- if they try to build somethat that needs the firmware blob)21:16
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto21:27
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)21:33
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 240 seconds)21:33
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto21:34
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)21:36
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Client Quit)21:39
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto21:39
fraylooks like I might be able to set BB_DONT_CACHE21:51
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto21:56
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 250 seconds)21:56
zeddiiyah. I think that is the right var.21:57
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto22:50
kergothfray: i'd expect you to be able to set file-checksums, programmatically in the anonymous python if necessary22:50
frayThats what I'm going to be doing.. setting SRC_URI, file-checksums and BB_NO_CACHE in the anon python..  I've not tested it much, but I suspect this will do what I want22:51
*** Skinny79 <Skinny79!> has quit IRC (Quit: Connection closed)22:52
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)22:52
frayin the end if the user doesn't set it, I need the recipe skipped.. but if they do set it.. I need to pay attention to the checksum and change if they put in a new binary.. I THINK this will do what I need now22:52
fray(I only set the BB_NO_CACHE if I'm doing the skip recipe exception.. I'm fine with caching otherwise as long as the file-checksums are set)22:52
*** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)22:57
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto23:00
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Quit: Leaving)23:01
RPrburton: - aahhrg. (that is with your workaround)23:02
RPqemuarm stap23:02
*** risca <risca!> has quit IRC (Ping timeout: 250 seconds)23:05
RPJPEW, sgw: I was looking at the spdx code and it looks like we don't scan for any license header to inject into the SPDX data yet, do I understand correctly?23:08
RPJPEW: also, if I remember rightly you use the icecc class? Is there a good reason to separate the *_SYSTEM_* and *_USER_* variables or could those be merged?23:09
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto23:10
sgwRP: that's my understanding, currently the License Declared is from the recipe, there is no further parsing of Source code to create a license concluded value.23:15
*** huseyinkozan <huseyinkozan!~hk@> has quit IRC (Quit: Konversation terminated!)23:15
rburtonRP damnit!23:15
RPsgw: I think we should find a tool or just add something really simple that scans the source file for an SPDX-License-Identifier23:16
sgwRP: I will add it to my list, not sure when I will get to it, maybe JPEW has cycles to look at it more closely if you want it for the spring release.23:27
RPsgw: ok, I just thought I'd mention it as it would make things much more interesting/useful. It shouldn't be hard to do so I might give it a go, we'll see23:28
*** otavio_ <otavio_!> has joined #yocto23:31
*** otavio <otavio!> has quit IRC (Read error: Connection reset by peer)23:31
JPEWNo, we don't do scanning23:34
sgwRP: was that a request based on sharing the kernel data?23:35
sgwI can give it a go, I know you have alot on your plate also.23:35
JPEWWe only do the "declared" right now. Scanning gives you the "concluded" license23:36
JPEWI was hoping something like reuse would become standard and we could use that, but I haven't seen anything23:37
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)23:43
*** leonanavi <leonanavi!~Leon@> has quit IRC (Ping timeout: 256 seconds)23:44
RPsgw: It wasn't but I know it will be the next question I get asked!23:50
RPI think we should be able to do something relaitvely easily if we limit it to the SPDX license identifier standard23:51
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)23:55

Generated by 2.17.2 by Marius Gedminas - find it at!