| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds) | 00:00 | |
| *** Skinny79 <Skinny79!~Skinny79@88-159-172-31.fixed.kpn.net> has quit IRC (Quit: Connection closed) | 01:13 | |
| *** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds) | 01:14 | |
| *** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 01:14 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 01:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 01:34 | |
| *** rr12zer <rr12zer!~rr12zer@62-183-153-56.bb.dnainternet.fi> has joined #yocto | 01:37 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 01:46 | |
| *** u1106 <u1106!~quassel@ec2-18-193-68-189.eu-central-1.compute.amazonaws.com> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 01:47 | |
| *** u1106 <u1106!~quassel@ec2-18-193-68-189.eu-central-1.compute.amazonaws.com> has joined #yocto | 01:50 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 02:10 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 02:31 | |
| *** snapsd <snapsd!~snapsd@061238109209.ctinets.com> has joined #yocto | 04:11 | |
| snapsd | Hello all, I have set SOURCE_MIRROR_URL pointing to my local server + appended few PREMIRRORS for source download | 04:13 |
|---|---|---|
| snapsd | now, when fetcher runs, it finds the tar ball on SOURCE_MIRROR_URL, but still try to translate that URL with PREMIRROR... | 04:14 |
| snapsd | is 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 |
| snapsd | I know, with own-mirrors, source mirror url is PREMIRROR only.. but still | 04:14 |
| *** amitk <amitk!~amit@103.208.69.151> has joined #yocto | 04:34 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 04:34 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 04:46 | |
| snapsd | anyone? any idea | 05:06 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 05:39 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 05:40 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Ping timeout: 240 seconds) | 05:46 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 05:52 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> 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 #yocto | 06:20 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 06:28 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds) | 06:32 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:58 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:15 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 07:15 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 07:17 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 07:23 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 07:23 | |
| *** olani <olani!~olani@h85-238-221-104.cust.a3fiber.se> has quit IRC (Ping timeout: 256 seconds) | 07:29 | |
| *** olani <olani!~olani@66.159.215.7> has joined #yocto | 07:30 | |
| *** dushara <dushara!~D@119-18-18-27.771212.mel.static.aussiebb.net> has quit IRC (Quit: Leaving) | 07:33 | |
| *** frieder <frieder!~frieder@i59F72B18.versanet.de> has joined #yocto | 07:47 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 07:58 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 08: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!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 08:10 | |
| *** gsalazar <gsalazar!~gsalazar@161.230.168.194> has joined #yocto | 08:11 | |
| *** dev1990 <dev1990!~dev@81.168.185.188> has joined #yocto | 08:26 | |
| *** mckoan|away is now known as mckoan | 08:33 | |
| mckoan | ziga_: look at the kernel recipe | 08:34 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 08:37 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 08: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 #yocto | 08:42 | |
| *** dev1990 <dev1990!~dev@81.168.185.188> has quit IRC (Quit: Konversation terminated!) | 08:45 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:46 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Ping timeout: 256 seconds) | 08:47 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 08:47 | |
| *** olani <olani!~olani@66.159.215.7> has quit IRC (Remote host closed the connection) | 08:48 | |
| *** olani <olani!~olani@66.159.215.7> has joined #yocto | 08:50 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 08: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: https://git.yoctoproject.org/meta-ti/tree/recipes-kernel/linux/linux-ti-staging_5.4.bb?h=master). Here I can see the line "require recipes-kernel/linux/bundle-devicetree.inc", so I assume that it uses "bundle-devicetree.inc" (link: https://git.yoctoproject.org/meta-ti/tree/recipes-kernel/linux/bundle-devicetree.in | 09:01 |
| ziga_ | c) somehow... I don't understand this one. | 09:01 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 09:05 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:06 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 09:11 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:11 | |
| *** gsalazar_ <gsalazar_!~gsalazar@194.38.148.130> has joined #yocto | 09:14 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 09:16 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:16 | |
| *** gsalazar <gsalazar!~gsalazar@161.230.168.194> has quit IRC (Ping timeout: 256 seconds) | 09:17 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 09:21 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:22 | |
| *** gsalazar_ <gsalazar_!~gsalazar@194.38.148.130> has quit IRC (Quit: Leaving) | 09:24 | |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has joined #yocto | 09:25 | |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has joined #yocto | 09:25 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Ping timeout: 256 seconds) | 09:27 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 268 seconds) | 09:28 | |
| *** olani <olani!~olani@66.159.215.7> has quit IRC (Remote host closed the connection) | 09:37 | |
| *** snapsd <snapsd!~snapsd@061238109209.ctinets.com> has quit IRC (Ping timeout: 250 seconds) | 09:38 | |
| *** olani <olani!~olani@66.159.215.7> has joined #yocto | 09:40 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 09:44 | |
| *** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has joined #yocto | 09:50 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4e02:5400:24d7:51ff:fed6:906d> has joined #yocto | 09:51 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 09:51 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 09:51 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:52 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 09:53 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 09:56 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 09:57 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:58 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 10:01 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 10:01 | |
| *** osama <osama!~osama@eth1-fw1-nbg6.eb.noris.de> has quit IRC (Ping timeout: 256 seconds) | 10:10 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 10:11 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:12 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 10:16 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:17 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 10:21 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:21 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 10:26 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:27 | |
| RP | kanavin: 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 |
| kanavin | RP: yes, it does seem as if the CPU cores are 5x slower than they should be | 10:44 |
| kanavin | I was watching your repro build via ssh - it's progressing but at a snail pace | 10:44 |
| kanavin | not hung exactly | 10:45 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 10:45 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:45 | |
| kanavin | RP: in other news, I just sent the upgrade rollup | 10:46 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 10:50 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 10:50 | |
| RP | kanavin: I just triggered the M2 build so I guess this is going in after that :) | 10:52 |
| kanavin | RP: perfect timing ;) | 10:52 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 10:55 | |
| RP | kanavin: interesting use of mcextend | 10:55 |
| RP | kanavin: a little worrying as it isn't a real mc and I worry what happens if we add a real mc into the mix | 10:56 |
| RP | kanavin: I like the idea, I just worry we can't use mcextend like this | 10:57 |
| kanavin | RP: 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 files | 10:58 |
| kanavin | e.g. add a mcextend variant, and tweak TARGET_SYS in it | 10:58 |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.191> has joined #yocto | 10:58 | |
| kanavin | adding recipe variants like this for common configurations is very handy, devupstream is another example | 10:59 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 10:59 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 10:59 | |
| RP | kanavin: right, but using the mcextend namespace like that means it would no longer work for real multiconfig work | 11:01 |
| RP | kanavin: we need something which would stack for the multiconfig case correctly | 11:02 |
| kanavin | RP: I see, can you describe a test case where things would break? | 11:02 |
| kanavin | maybe on the mailing list so that it's preserved and visible | 11:03 |
| RP | kanavin: I'd be curious if the multiconfig tests in oe-selftest work with larger images that include mesa after your change | 11:03 |
| RP | kanavin: the multiconfig tests don't use large images due to time/resource usage constraints | 11:05 |
| kanavin | RP: I can try that | 11: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 rebuilding | 11:06 |
| RP | kanavin: 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 use | 11:07 |
| *** d0ku <d0ku!~d0ku@178.43.152.233.ipv4.supernova.orange.pl> has joined #yocto | 11:09 | |
| kanavin | RP: I can try the multiconfig tests meanwhile | 11:15 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 11:16 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:16 | |
| RP | kanavin: please, that would be where I'd start | 11:19 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 11:21 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:21 | |
| RP | Why do we find networking failures in a release build :( | 11:29 |
| RP | Not sure it is a network issue. It is always rust-native and cargo-native | 11:41 |
| RP | and no error in the logs | 11:41 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 11:45 | |
| madisox | RP: looks like the crate fetcher issue | 11:49 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 11:50 | |
| rburton | 0: rust-native-1.57.0-r0 do_compile - 26m29s (pid 1417874) | 11:51 |
| * rburton grumbles at rust | 11:52 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 11:52 | |
| coldspark29[m] | rburton: I printed the error with `bb.error(f)` as you suggested. The last path processed is | 12:03 |
| coldspark29[m] | `/home/claussenj/Workspace/Yocto-Workspace/vti2/sources/meta-eppendorf/recipes-eppendorf/preinstalled/files/lgpl-3.0.txt` | 12:03 |
| coldspark29[m] | I don't see anything odd about it. Everything seems okay with the file name. Here is the full error | 12:03 |
| coldspark29[m] | https://pastebin.com/M99jg2gP | 12: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 is | 12:03 |
| coldspark29[m] | `/home/user/Workspace/Yocto-Workspace/mymachine/sources/meta-custom/recipes-custom/preinstalled/files/lgpl-3.0.txt` | 12:03 |
| coldspark29[m] | I don't see anything odd about it. Everything seems okay with the file name. Here is the full error | 12:03 |
| coldspark29[m] | https://pastebin.com/M99jg2gP | 12:03 |
| coldspark29[m] | It complains about too many values. Maybe lgpl-3.0 exists twice? | 12:04 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 12:06 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:9caa:1499:5129:dd6e> has joined #yocto | 12:08 | |
| RP | madisox: which crate fetcher issue? | 12:08 |
| *** kroon_ <kroon_!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 12:10 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Ping timeout: 268 seconds) | 12:11 | |
| madisox | RP: 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 mirror | 12:12 |
| RP | madisox: oh, right, yes. I really should remember that :/ | 12:14 |
| RP | and it only hits our release builds as we change config to populate a new sstate directory | 12:14 |
| RP | and only early builds as later it is populated | 12:14 |
| RP | madisox: I've been hoping we could sort the test cases and get that fetcher merged | 12:15 |
| *** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has quit IRC (Ping timeout: 256 seconds) | 12:17 | |
| rburton | moto-timo: py-crypto-native doesn't work | 12:18 |
| RP | abelloni: some useful insight into the rust/cargo sstate warnings ^^^ | 12:18 |
| rburton | https://www.irccloud.com/pastebin/AB6H4AHp/ | 12:18 |
| rburton | moto-timo: https://www.irccloud.com/pastebin/AB6H4AHp/ | 12:18 |
| *** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto | 12:18 | |
| madisox | RP: I haven't volunteered to do the bitbake integration because I don't know rust well enough to put together those test cases, sorry | 12:25 |
| RP | madisox: right, neither do I really :( | 12:28 |
| *** Skinny79 <Skinny79!~Skinny79@88-159-172-31.fixed.kpn.net> has joined #yocto | 12:37 | |
| *** doquiros[m] <doquiros[m]!~doquirosm@2001:470:69fc:105::c8e> has joined #yocto | 12:38 | |
| Skinny79 | Hi 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 : https://pastebin.com/sucPP8DE . The files are correctly on the rootfs but the service is never enabled. When I enable it manually at runtime it works just | 12:41 |
| Skinny79 | fine. 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__!sid501830@id-501830.uxbridge.irccloud.com> has joined #yocto | 12:42 | |
| *** darknighte_ <darknighte_!sid214177@user/darknighte> has joined #yocto | 12:42 | |
| *** rsalveti_ <rsalveti_!uid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 12:42 | |
| *** pgowda__ <pgowda__!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 12:42 | |
| *** NishanthMenon_ <NishanthMenon_!sid138049@id-138049.uxbridge.irccloud.com> has joined #yocto | 12:42 | |
| *** chrfle_ <chrfle_!~chrfle@217-209-195-249-no206.tbcn.telia.com> has joined #yocto | 12:42 | |
| *** mrnuke_ <mrnuke_!~mrnuke@2601:2c1:8501:182d::c66> has joined #yocto | 12:42 | |
| *** dkl_ <dkl_!~dkl@prometheus.umask.eu> has joined #yocto | 12:42 | |
| *** Bardon_ <Bardon_!~Bardon@user/Bardon> has joined #yocto | 12:43 | |
| *** rfs613- <rfs613-!~rfs613@rfs.netwinder.org> has joined #yocto | 12:43 | |
| *** rburton_ <rburton_!rburton@user/rburton> has joined #yocto | 12:43 | |
| *** bluelightning_ <bluelightning_!~paul@2406:e003:151f:d701:4144:c8c8:67ba:4419> has joined #yocto | 12:43 | |
| *** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0::f824> has joined #yocto | 12:44 | |
| *** michalkotyla_ <michalkotyla_!~quassel@85-222-117-222.dynamic.chello.pl> has joined #yocto | 12:44 | |
| *** frosteyes2 <frosteyes2!~frosteyes@185.53.130.211> has joined #yocto | 12:45 | |
| *** armpit <armpit!sid501830@id-501830.uxbridge.irccloud.com> has quit IRC (Ping timeout: 240 seconds) | 12:46 | |
| *** _whitelogger <_whitelogger!~whitelogg@uruz.whitequark.org> 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!peter@lorentz.7bits.nl> has quit IRC (Ping timeout: 240 seconds) | 12:46 | |
| *** frosteyes1 <frosteyes1!~frosteyes@185.53.130.211> 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!sid138049@id-138049.uxbridge.irccloud.com> 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!~dkl@prometheus.umask.eu> 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!~chrfle@217-209-195-249-no206.tbcn.telia.com> has quit IRC (Ping timeout: 240 seconds) | 12:46 | |
| *** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has quit IRC (Ping timeout: 240 seconds) | 12:46 | |
| *** rfs613 <rfs613!~rfs613@rfs.netwinder.org> has quit IRC (Ping timeout: 240 seconds) | 12:46 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> 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!~quassel@85-222-117-222.dynamic.chello.pl> has quit IRC (Ping timeout: 240 seconds) | 12:46 | |
| *** chrfle_ is now known as chrfle | 12:46 | |
| *** pgowda__ is now known as pgowda_ | 12:46 | |
| *** armpit__ is now known as armpit | 12:46 | |
| *** rburton_ is now known as rburton | 12:46 | |
| *** darknighte_ is now known as darknighte | 12:46 | |
| *** NishanthMenon_ is now known as NishanthMenon | 12:46 | |
| *** rsalveti_ is now known as rsalveti | 12:46 | |
| *** _whitelogger <_whitelogger!~whitelogg@uruz.whitequark.org> has joined #yocto | 12: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 #yocto | 12:47 | |
| *** nerdboy <nerdboy!~nerdboy@47.143.129.145> has joined #yocto | 12:47 | |
| *** Habbie <Habbie!peter@lorentz.7bits.nl> has joined #yocto | 12:47 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::f824> has joined #yocto | 12:47 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 268 seconds) | 12:48 | |
| *** rfs613- <rfs613-!~rfs613@rfs.netwinder.org> has quit IRC (Ping timeout: 256 seconds) | 12:49 | |
| *** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has quit IRC (Ping timeout: 256 seconds) | 12:49 | |
| *** rfs613 <rfs613!~rfs613@rfs.netwinder.org> has joined #yocto | 12:49 | |
| *** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has joined #yocto | 12:51 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 12:52 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 12:52 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 12:52 | |
| *** camus1 is now known as camus | 12:52 | |
| smurray | fray: 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 see | 13:00 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 13:13 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 13:14 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 13:18 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 13:19 | |
| *** beneth <beneth!~beneth@2001:41d0:c:a71:1000:25::> has joined #yocto | 13:25 | |
| RP | rburton: did you ever work out that sstate failure improvement patch? | 13:38 |
| RP | rburton: I've sent a blind attempt at improving it | 13: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 built | 13:45 |
| coldspark29[m] | I guess I patched the wrong kernel source?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e1d732df71d034556d7c5e1df380f9ce99b8934c) | 13:49 |
| smurray | coldspark29[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-timo | rburton: did you get any further with py-native host ssl contamination theory? | 13:50 |
| coldspark29[m] | smurray: Yes, but it includes linux-fslc.inc, which includes linux-imx.inc. So I thought I would need to patch linux-imx as before on gatesgarth | 13:51 |
| smurray | coldspark29[m]: it's what SRC_URI points at that matters, and linux-fslc.inc sets it to linux-fslc.git | 13:52 |
| smurray | coldspark29[m]: that plus the KBRANCH set what gets used | 13:52 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 13:53 | |
| coldspark29[m] | smurray: Yeah and in linux-imx.inc the SRC_URI points to the NXP kernel. I assume since the linux-imx.inc 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 Yocto | 13:54 |
| smurray | coldspark29[m]: yes. When in doubt check variable values in the 'bitbake -e <recipe>' output or with the newer bitbake-getVar tool | 13:55 |
| coldspark29[m] | So why is it including linux-imx? Is it just getting the patches from there? | 13:55 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:59 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 14:04 | |
| coldspark29[m] | Well, I guess this is a good opportunity to learn about all of that :D | 14:04 |
| coldspark29[m] | How security patches are applied if they are not in the mainline or NPX branch | 14:04 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 14:05 | |
| smurray | coldspark29[m]: by the maintainer or by an enduser like yourself? | 14:05 |
| coldspark29[m] | By the maintainer | 14:05 |
| coldspark29[m] | This kernel seems to be patched together from different sources. It is a bit complex, but a good learning opportunity | 14:06 |
| coldspark29[m] | In Gatesgarth or Hardknott there was just linux-imx or linux-fslc | 14:06 |
| coldspark29[m] | This is like a fused kernel | 14:07 |
| smurray | coldspark29[m]: I assume he has some scripting to manage it | 14:07 |
| coldspark29[m] | s/fused/kernel/, s/kernel/fusion/ | 14:07 |
| *** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 14:08 | |
| smurray | coldspark29[m]: if you have questions about how Andrey puts those kernels together, perhaps email him or post to the meta-freescale mailing list | 14:08 |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds) | 14:11 | |
| *** kroon_ <kroon_!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Remote host closed the connection) | 14:12 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 14:12 | |
| RP | madisox: I've pushed something to master-next to try and resolve this | 14:23 |
| RP | some really basic tests | 14:23 |
| qschulz | Skinny79: you're missing `inherit systemd` I think | 14:35 |
| *** kroon_ <kroon_!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 14: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 #yocto | 14:38 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 14:39 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 14:39 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> 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 improvements | 14:42 |
| Perceval[m] | If someone has any idea that could help us ! That would be awesome ! :) | 14:43 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 256 seconds) | 14:43 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 256 seconds) | 14:43 | |
| Skinny79 | qschulz ohmy.. reading and mixing all kind of blogs posts is not helping in this case.. that was it, thanks! | 14:53 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:54 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 14:59 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has quit IRC (Quit: Client closed) | 15:01 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 15:02 | |
| *** jatedev <jatedev!~jatedev@63.148.217.19> has joined #yocto | 15:07 | |
| rburton | moto-timo: i tried adding -Bsymbolic-functions to openssl-native but that didnt appear to work | 15:08 |
| moto-timo | rburton: also a report about sdk broken... but that smells like a rust sdk issue | 15:09 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 15:17 | |
| vd | I 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 |
| qschulz | vd: "complains about them" ? | 15:24 |
| vd | qschulz: yes a warning stating that there are multiple alternatives for the psplash package | 15:25 |
| *** amitk <amitk!~amit@103.208.69.151> has quit IRC (Ping timeout: 240 seconds) | 15:26 | |
| RP | vd: your alternatives are overlapping somehow and bitbake isn't happy about it or both aren't providing everything they need to | 15:38 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 15:39 | |
| vd | RP: 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_!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving) | 15:43 | |
| rburton | where is psplash-bar defined? | 15:44 |
| vd | rburton: same as for psplash-foo with s/foo/bar/ obviously | 15:46 |
| vd | (psplash-foo, psplash-bar are just example names of psplashes I have) | 15:47 |
| RP | vd: what are "psplash-foo" and "psplash-bar" though? You've changed the PN for the recipe? | 15:47 |
| vd | RP: 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 recipe | 15:49 |
| vd | I understood that the psplash recipe was somehow dynamically adding alternatives to the main psplash package | 15:50 |
| vd | Should the distro set a default SPLASH ?= "psplash-foo" instead of PREFERRED_PROVIDER_psplash? | 15:53 |
| RP | vd: I had to look at what the recipe is doing as the information above is very confusing. The psplash recipe adds multiple PACKAGES | 15:54 |
| RP | vd: you do not select things in the PACKAGES/runtime namespace with PREFERRED_PROVIDER which is the PN namespace | 15:54 |
| RP | vd: so yes, changing SPLASH would be more appropriate | 15:56 |
| *** d0ku <d0ku!~d0ku@178.43.152.233.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 268 seconds) | 15:57 | |
| vd | RP: sorry about the confusion, but to be fair this package is quite confusing itself. | 15:58 |
| vd | But I understand it's just doing dynamically what you could do with PACKAGES = "${PN}-foo ${PN}-bar", thank you. | 16:01 |
| RP | vd: writing up an example of using it for the manual would be great now you understand it! ;-) | 16:03 |
| vd | RP: sure. What's the best place for it? | 16:05 |
| RP | vd: not sure, probably a new section in the development tasks going from memory? | 16:06 |
| vd | RP: 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 |
| vd | RP: I've sent two patches for beaglebone-yocto a few days ago without follow-up | 16:07 |
| vd | s/bad/patch/ (I don't know how that came out) | 16:08 |
| vd | Instead of quietly applying the patch I mean. | 16:08 |
| RP | vd: you're asking me to send an extra 4000 emails a year? | 16:09 |
| vd | RP: didn't you do it for the kernel? | 16:10 |
| rburton | RP: i'm sure jonmason will be quick to point out that if you use lore/b4/etc, it can send those for you | 16:11 |
| RP | rburton: in that case someone else can just script it and make it work as it is so easy to do | 16:11 |
| *** amitk <amitk!~amit@103.208.69.151> has joined #yocto | 16:11 | |
| rburton | yeah, i know you have a pile of local scripting to manage patches-on-list | 16:11 |
| RP | rburton: I do have an email from jon to look at some details on that stuff | 16:12 |
| vd | I rarely saw a kernel patch applied with a reply, yet I bet these "Applied, thanks." messages are automatic. | 16:12 |
| RP | but 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 merged | 16:12 |
| vd | that's not really the problem here... | 16:13 |
| RP | vd: ok, so what is the problem? | 16:13 |
| vd | First 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 anyone | 16:14 |
| RP | The 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 |
| RP | vd: I can tell you they would bother me as I don't use digests | 16:14 |
| RP | I know they will annoy others too, we've discussed this before | 16:14 |
| qschulz | RP: I remember there was some discussion about fixing a patchwork instance somewhere? | 16:15 |
| fray | Or, you can just watch master-next... that's what I do | 16:15 |
| vd | RP: 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 |
| RP | qschulz: still in progress and I'm getting very annoyed/frustrated about how long it is taking | 16:16 |
| smurray | fray: those intermittent qtbase errors you mentioned last week, do you recall if they were from linking? | 16:17 |
| jonmason | honestly, b4 and lei are your friends | 16:17 |
| RP | vd: 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 too | 16:17 |
| fray | smurray: linking and referencing a file, but I forget what file | 16:18 |
| rburton | assuming your patches are in local branches, rebase onto latest master. when the branch disappears, they were merged. | 16:18 |
| jonmason | It won't take an hour, and you can use any email reader you want | 16:18 |
| jonmason | and if your keys get triggered, it'll add the whole thread to your inbox | 16:18 |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.238> has joined #yocto | 16:18 | |
| fray | smurray: 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_MAKE | 16:19 |
| smurray | fray: the log I've been given has a lot of "DWARF error: could not find variable specification at offset X" errors | 16:19 |
| jonmason | and you can add more at any time. For example, I started tracking the stuff in tunes now just by adding a single line | 16:19 |
| RP | You 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 |
| jonmason | lmao | 16:19 |
| jonmason | RP: I'm just trying to help | 16:20 |
| * zeddii has the same feeling about things as RP :) | 16:20 | |
| smurray | fray: I'm hesitant to offer that as a solution as the person with the issue is building on a developer laptop ;) | 16:20 |
| jonmason | ok, if I can get zeddii to convert, would that work for everyone that it is trivial to learn? | 16:20 |
| fray | In reality it's far easier to have people actually monitor the work.. i.e. go to git.yoctoproject.org (or openembedded) and look at master-next.. | 16:20 |
| fray | that is 100% how I watch if my patches have been accepted or the status.. takes me seconds to do it | 16:21 |
| vd | smurray: who's that? | 16:21 |
| fray | we get it on our container build systems | 16:21 |
| smurray | fray: someone attempting to build AGL | 16:21 |
| RP | jonmason: I have your email about b4/lei in my inbox marked as important and need to look at properly | 16:21 |
| smurray | vd: someone attempting to build AGL | 16:21 |
| RP | I just don't get the time :( | 16:21 |
| jonmason | `b4 ty` automatically emails in the thread for patches that have been applied | 16:21 |
| jonmason | thats what I'm doing now for meta-arm | 16:22 |
| qschulz | just 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 branch | 16:22 |
| jonmason | RP: you'll never have the time. you don't have time to properly sleep as it is | 16:22 |
| qschulz | and I'm frankly annoyed by it, every monday I've like 500 mails from Buildroot over the weekend :) | 16:22 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 16:22 | |
| RP | zeddii: 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 |
| vd | RP: 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 |
| RP | vd: we built yocto project differently from the kernel and I don't think the kernel is right about everything. | 16:23 |
| qschulz | RP: 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 people | 16:24 |
| fray | every projects workflow is different.. it's the user's responsibility to adapt to the communities/maintainers workflow | 16:25 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 16:27 | |
| fray | smurray: BTW the message I was seeing most was "Makefile:144: recipe for target 'sub-dbus-install_subtargets' failed" | 16:27 |
| RP | qschulz: 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 | |
| rburton | arguably, if b4 was used, people who object to the replies can at least then filter them all out relatively easily | 16:28 |
| fray | smurray: 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 |
| rburton | but that does mean RP rewriting his workflow to use b4 | 16:28 |
| RP | it would mean RP having time to even think about this stuff | 16:28 |
| rburton | which may be a net win in the long term but is a time sink in the short | 16:28 |
| vd | problem 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 |
| rburton | vd: ideally the sender pings the list first instead of bothering on irc | 16:29 |
| fray | vd -- or you look at the git repository.. if it's not merged into -next within a week.. ping.. | 16:29 |
| smurray | fray: this log I'm looking at has a failure down in the qdbus stuff, but not exactly that target | 16:29 |
| Saur | vd: You do as fray said, you monitor master-next and master. | 16:29 |
| RP | vd: 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 something | 16:29 |
| fray | smurray: 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 place | 16:29 |
| vd | I 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 |
| jonmason | RP: 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 |
| RP | some 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 problem | 16:30 |
| rburton | jonmason: you're wildly over-estimating how good 50% of the patches are | 16:30 |
| smurray | fray: okay. I'll perhaps get them to try a build with it at -j 1 to see | 16:31 |
| zeddii | jonmason: except that's pulling in all patches. regardless of their quality | 16:31 |
| jonmason | lol, probably | 16:31 |
| RP | jonmason: 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 it | 16:31 |
| zeddii | snap | 16:31 |
| fray | smurray: 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 vary | 16:31 |
| jonmason | RP: 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 useful | 16:32 |
| RP | Even 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 on | 16:32 |
| smurray | fray: hrm, the failure I've been pointed at is in do_compile, though, so perhaps it's different | 16:32 |
| fray | up different then. I've not seen any do_compile failures (I'm speaking very much of honister BTW) | 16:33 |
| *** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC (Remote host closed the connection) | 16:33 | |
| smurray | fray: this is dunfell, but would be similar qt version, I imagine | 16:33 |
| fray | in 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 hours | 16:33 |
| smurray | fray: if I could reproduce it myself it'd be a lot easier, but I've never seen it | 16:34 |
| qschulz | rburton: 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 |
| fray | we 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 |
| smurray | fray: yeah, that's a pretty high frequency | 16:35 |
| qschulz | rburton: just wanted to add this, not start a new debate though :) | 16:35 |
| fray | I 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 |
| fray | so it's pretty rare..b ut we'll occasionally see it with multiple trys.. then it just goes away for 2 weeks | 16:36 |
| fray | we'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!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Remote host closed the connection) | 16:42 | |
| RP | rburton, jonmason: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/4616 - qemuarm64 on the release build taken out by a network glitch :( | 16:42 |
| vd | RP: 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 |
| smurray | fray: 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 then | 16:42 |
| RP | vd: 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 |
| RP | I think we need to write off 3.5 M2 rc1 | 16:44 |
| * rburton shakes fist at networks in general | 16:46 | |
| RP | I think I can see at least four issues in that build | 16:49 |
| RP | and sadly I think the best way to fix some of them is heavy rewriting on some core bits of bitbake | 16:49 |
| *** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto | 16:50 | |
| *** ferlzc57 <ferlzc57!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto | 16:51 | |
| *** dev1990 <dev1990!~dev@81.168.185.188> has joined #yocto | 16:53 | |
| *** ferlzc95 <ferlzc95!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto | 16:54 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> 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 #yocto | 16: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 #yocto | 16:58 | |
| vd | To 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@88.130.217.69> has quit IRC (Ping timeout: 240 seconds) | 16:59 | |
| rburton | vd: a 'ping' is sufficient | 16:59 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has joined #yocto | 16:59 | |
| ferlzc | hello 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 |
| rburton | ferlzc: most likely you're not using pkgconfig to find the postgresl headers, and they're not in the default search path | 17:01 |
| vd | rburton: like you literally reply 'ping' to your own patch? | 17:02 |
| rburton | pretty much | 17:03 |
| RP | vd: since I know about this one I'll take a look at them | 17: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 #yocto | 17:05 | |
| qschulz | vd: e.g. https://lists.yoctoproject.org/g/docs/message/2421 | 17:06 |
| *** zpfvo <zpfvo!~fvo@88.130.217.69> has quit IRC (Quit: Leaving.) | 17:07 | |
| vd | The 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@31.0.173.147> has joined #yocto | 17:18 | |
| *** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has quit IRC (Quit: Client closed) | 17:21 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 17:22 | |
| *** frieder <frieder!~frieder@i59F72B18.versanet.de> has quit IRC (Read error: Connection reset by peer) | 17:27 | |
| vd | qschulz: 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 |
| RP | vd: Set ALTERNATIVE_PRIORITY_psplash-foo to something | 17:31 |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Quit: CHELAS!) | 17:33 | |
| RP | vd: 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 be | 17:33 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:34 | |
| vd | RP: got it. | 17:34 |
| vmeson | Perceval[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@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 17:50 | |
| *** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto | 17: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 |
| rburton | your distro conf | 17:56 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 17: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 |
| rburton | local.conf should be as minimal as possible, yes | 17:58 |
| rburton | ideally, you have your own distro config for the policy stuff like that | 17:58 |
| rburton | well, some things are machine-specific, so can go in the machine conf | 17:59 |
| rburton | like 'what boot loader do i use' | 17:59 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> 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 #yocto | 18:03 | |
| *** mckoan is now known as mckoan|away | 18: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@31.0.173.147> has joined #yocto | 18:05 | |
| *** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC (Quit: reboot) | 18:34 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 18:35 | |
| *** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto | 18:37 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 18:43 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.238> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 18:52 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.238> has joined #yocto | 18: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 #yocto | 19:16 | |
| *** ferlzc <ferlzc!~ferlzc@2804:431:cfec:3071:64ee:69a5:b58f:6934> has joined #yocto | 19:19 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-133-106-109.93.133.pool.telefonica.de> has joined #yocto | 19: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!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 19:35 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Remote host closed the connection) | 20:03 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 20:04 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 20:05 | |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has quit IRC (Ping timeout: 240 seconds) | 20:08 | |
| jonmason | zeddii: thanks for fixing dtc stuff! | 20:20 |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has joined #yocto | 20:33 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:44 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 20: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!~pab@67-1-7-95.tcso.qwest.net> 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@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:55 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-133-106-109.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 20:56 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 20:57 | |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has quit IRC (Ping timeout: 240 seconds) | 21:00 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Client Quit) | 21:01 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 240 seconds) | 21:01 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 21:04 | |
| kergoth | ziga_: yes, just remember to set MACHINEOVERRIDES if you also want overrides in recipes to take effect for both machines | 21:05 |
| ziga_ | @kergoth Thank you. I thought that include/require is only applicable to the .inc files! :D | 21:06 |
| kergoth | .inc 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!~pab@67-1-16-117.tcso.qwest.net> has joined #yocto | 21:07 | |
| kergoth | just remember that you want to use the full path fromt he root of the repo for your inclusion | 21:07 |
| kergoth | that is, don't require somemachine.conf, but require conf/machine/somemachine.conf | 21:07 |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has joined #yocto | 21: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@172.58.188.238> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 21:13 | |
| fray | I'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 message | 21:15 |
| fray | the problem is I create the file.. and it never re-runs the anon python, it caches that the recipe isn't available. | 21:15 |
| fray | How 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@31.0.173.147> has joined #yocto | 21:27 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 21:33 | |
| *** davidinux <davidinux!~davidinux@37.120.201.222> has quit IRC (Ping timeout: 240 seconds) | 21:33 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 21:34 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 21:36 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Client Quit) | 21:39 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 21:39 | |
| fray | looks like I might be able to set BB_DONT_CACHE | 21:51 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 21:56 | |
| *** amitk <amitk!~amit@103.208.69.151> has quit IRC (Ping timeout: 250 seconds) | 21:56 | |
| zeddii | yah. I think that is the right var. | 21:57 |
| *** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has joined #yocto | 22:50 | |
| kergoth | fray: i'd expect you to be able to set file-checksums, programmatically in the anonymous python if necessary | 22:50 |
| fray | Thats 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 want | 22:51 |
| *** Skinny79 <Skinny79!~Skinny79@88-159-172-31.fixed.kpn.net> has quit IRC (Quit: Connection closed) | 22:52 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 22:52 | |
| fray | in 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 now | 22: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@31.0.173.147> has joined #yocto | 23:00 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Quit: Leaving) | 23:01 | |
| RP | rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/3512 - aahhrg. (that is with your workaround) | 23:02 |
| RP | qemuarm stap | 23:02 |
| *** risca <risca!~quassel@h-176-10-232-62.A980.priv.bahnhof.se> has quit IRC (Ping timeout: 250 seconds) | 23:05 | |
| RP | JPEW, 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 |
| RP | JPEW: 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@172.58.188.238> has joined #yocto | 23:10 | |
| sgw | RP: 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@31.223.46.191> has quit IRC (Quit: Konversation terminated!) | 23:15 | |
| rburton | RP damnit! | 23:15 |
| RP | sgw: I think we should find a tool or just add something really simple that scans the source file for an SPDX-License-Identifier | 23:16 |
| sgw | RP: 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 |
| RP | sgw: 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 see | 23:28 |
| *** otavio_ <otavio_!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 23:31 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Read error: Connection reset by peer) | 23:31 | |
| JPEW | No, we don't do scanning | 23:34 |
| sgw | RP: was that a request based on sharing the kernel data? | 23:35 |
| sgw | I can give it a go, I know you have alot on your plate also. | 23:35 |
| JPEW | We only do the "declared" right now. Scanning gives you the "concluded" license | 23:36 |
| JPEW | I was hoping something like reuse would become standard and we could use that, but I haven't seen anything | 23:37 |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.238> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 23:43 | |
| *** leonanavi <leonanavi!~Leon@46.55.231.62> has quit IRC (Ping timeout: 256 seconds) | 23:44 | |
| RP | sgw: It wasn't but I know it will be the next question I get asked! | 23:50 |
| RP | I think we should be able to do something relaitvely easily if we limit it to the SPDX license identifier standard | 23:51 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 23:55 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!