| *** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-dzbpayzogjztxspk> has joined #yocto | 00:02 | |
| *** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC | 00:26 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:f534:593a:c9d7:eb3d> has quit IRC | 00:33 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has joined #yocto | 00:37 | |
| *** j2411 <j2411!~Adium@20.ip-51-79-160.net> has quit IRC | 01:00 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 01:01 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 01:03 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 01:07 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 01:50 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 03:06 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 03:08 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:14 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 03:20 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC | 03:28 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 03:32 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 03:33 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 03:37 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 03:38 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 03:51 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-099.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 04:30 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 04:50 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 04:53 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 04:56 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 05:00 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 05:01 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 05:19 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 05:22 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 05:27 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 05:33 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 05:39 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:44 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 05:49 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 05:50 | |
| *** fl0v0 <fl0v0!~fvo@88.130.219.85> has joined #yocto | 06:04 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 06:12 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 06:13 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:14 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 06:15 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 06:19 | |
| *** elGamal <elGamal!~elg@217.138.222.44> has quit IRC | 06:20 | |
| *** elGamal <elGamal!~elg@217.138.222.44> has joined #yocto | 06:22 | |
| *** mckoan|away is now known as mckoan | 06:30 | |
| *** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto | 06:35 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 06:39 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 06:43 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 06:52 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto | 06:56 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 06:56 | |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has joined #yocto | 07:06 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 07:08 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto | 07:10 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 07:13 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:19 | |
| *** tensa <tensa!~tensa@vm-irc.spline.inf.fu-berlin.de> has quit IRC | 07:28 | |
| *** tensa <tensa!~tensa@vm-irc.spline.inf.fu-berlin.de> has joined #yocto | 07:28 | |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 07:44 | |
| *** xxxx <xxxx!34bba72f@52.187.167.47> has joined #yocto | 07:56 | |
| *** xxxx <xxxx!34bba72f@52.187.167.47> has quit IRC | 07:58 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:16 | |
| *** rperier <rperier!~quassel@unaffiliated/bambee> has quit IRC | 08:26 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 08:31 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 08:32 | |
| *** rperier <rperier!~quassel@234.ip-51-91-57.eu> has joined #yocto | 08:34 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 08:36 | |
| *** wbn <wbn!~badegg@2607:5300:60:2ca::1> has quit IRC | 08:41 | |
| *** wbn <wbn!~badegg@ns509729.ip-198-245-62.net> has joined #yocto | 08:41 | |
| alejandrohs | is i expected that qemu-native is showing like 20 cve? its clear cves are mostly updated but the cve_check task still shows a bunch of them, even starting from 2015 | 08:50 |
|---|---|---|
| RP | alejandrohs: it means we need to get the CVE information about effected versions fixed as I understand it | 08:51 |
| RP | rburton: ^^^ | 08:51 |
| rburton | alejandrohs: yes, the qemu cves are famous for not putting versions in | 08:52 |
| rburton | i've been trawling through them slowly fixing the cve database upstream, they don't start from 2012 now :) | 08:52 |
| alejandrohs | hahaha | 08:54 |
| RP | rburton: you should get a star for that :) | 08:54 |
| alejandrohs | Okay I see, I just saw it and was just wondering if it was known | 08:55 |
| *** dlan <dlan!~dennis@222.65.91.131> has joined #yocto | 08:55 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 08:55 | |
| rburton | will try and do a few more today, the plan is to slowly chip at a few every day | 08:57 |
| alejandrohs | going to bed now but if you already have a clear process on doing that, if you send that to me I may be able to help you with some | 08:58 |
| alejandrohs | rburton: ^^ | 08:58 |
| RP | armpit: fixed the signing failure, perf issue didn't recur | 09:09 |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has quit IRC | 09:17 | |
| *** hpsy1 <hpsy1!~hpsy@92.118.12.80> has joined #yocto | 09:17 | |
| *** Bunio_FH <Bunio_FH!~bunio@188.146.177.223.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 09:17 | |
| *** Bunio_FH1 <Bunio_FH1!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:20 | |
| *** Bunio_FH <Bunio_FH!~bunio@188.146.177.223.nat.umts.dynamic.t-mobile.pl> has quit IRC | 09:22 | |
| *** mihai is now known as mihaix | 09:30 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto | 09:31 | |
| *** eduardas <eduardas!~eduardas@85.254.96.13> has joined #yocto | 09:39 | |
| eduardas | hello, can anyone tell me if people practice reverse SSH tunnels at scale for embedded Linux devices deployed for clients? I have certain doubts whether that would be considered good practice? | 09:41 |
| eduardas | what is the safest and most preferred way to do remote debugging/bug report data collection on a Yocto system at scale in production? | 09:42 |
| *** elGamal <elGamal!~elg@217.138.222.44> has quit IRC | 09:56 | |
| *** elGamal <elGamal!~elg@217.138.222.44> has joined #yocto | 09:57 | |
| *** pbb <pbb!~quassel@2a0f:4ac0::7> has quit IRC | 10:17 | |
| *** pbb <pbb!~quassel@2a0f:4ac0::7> has joined #yocto | 10:17 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC | 10:36 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 10:40 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-jizbuaqyarwisjbe> has joined #yocto | 10:48 | |
| *** Guest5286 <Guest5286!a5e14934@gateway/web/cgi-irc/kiwiirc.com/ip.165.225.73.52> has joined #yocto | 10:50 | |
| *** Guest5286 <Guest5286!a5e14934@gateway/web/cgi-irc/kiwiirc.com/ip.165.225.73.52> has quit IRC | 10:53 | |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto | 10:54 | |
| shan1 | Hi all is there any write up on how one can create their meta layers according to the yocto versions i.e. warrior, dunfell etc as most of the other layers do. I can't wrap my head around it. Any reference simple meta layer would be great | 10:55 |
| shan1 | Also I keep getting an error | 10:57 |
| shan1 | ERROR: Nothing PROVIDES 'virtual/prebootloader'barebox-ipl PROVIDES virtual/prebootloader but was skipped: incompatible with machine phyboard-mira-imx6-3 (not in COMPATIBLE_MACHINE)for an IMX6 Board what does this actually imply _ | 10:57 |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has joined #yocto | 10:58 | |
| kayterina | hello, I think you just add that machine in COMPATIBLE_MACHINE in your layer | 10:59 |
| shan1 | kayterina I don't have a layer yet because I want to create a minimal image for the board, I have all the BSP layer from the manufacturer (phytec). | 11:00 |
| kayterina | ok, so the error comes from the BSP, not a cusotm layer? | 11:02 |
| shan1 | yes. | 11:02 |
| kayterina | hm...can you search for COMPATIBLE_MACHINE in their layers? | 11:04 |
| kayterina | keep in mind I am not experienced with yocto,that's just what I'd do | 11:04 |
| shan1 | It is there, the BSP version is on Yocto Warrior > http://layers.openembedded.org/layerindex/branch/warrior/layer/meta-phytec/ | 11:04 |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.206.116.248.dynamic.adsl.gvt.net.br> has joined #yocto | 11:08 | |
| *** hpsy1 <hpsy1!~hpsy@92.118.12.80> has quit IRC | 11:29 | |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has joined #yocto | 11:29 | |
| *** ilkkappe <ilkkappe!c65a42b1@198.90.66.177> has joined #yocto | 11:35 | |
| ilkkappe | Hello guys, I've a problem (yes, of course). I'm booting a xilinx zcu102 board. After the kernel's booted for some seconds I get these lines | 11:36 |
| ilkkappe | 24.673938] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: | 11:36 |
| ilkkappe | 0x0000000a | 11:36 |
| ilkkappe | Also, the strange thing is that it seems related to the dtb file | 11:37 |
| ilkkappe | this is beacause if I use the same kernel with dtbA the kernel boots correctly | 11:37 |
| ilkkappe | if I use the same kernel with dtbB the kernel doesn't boot correctly and continue to report the previous lines | 11:38 |
| *** Spock_ncc1701 <Spock_ncc1701!~Spock_ncc@85.203.44.80> has joined #yocto | 11:38 | |
| ilkkappe | The differences between the two dtbs is that dtbB has some new nodes, while dtbA is the compiled version of the default dts in arch/arm64/boot/dts/... | 11:39 |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:44 | |
| RobertBerger | @ilkkappe: What new kernel modules does the new device tree activate? | 12:04 |
| ilkkappe | basically one clock distributor and one adc converter | 12:04 |
| RobertBerger | @ilkkappe: https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt | 12:04 |
| RobertBerger | I guess something is wrong in those ;) | 12:05 |
| ilkkappe | is it possible in your opinio, that if the board with the adc and the distributor is not plugged in the kernel hangs | 12:05 |
| ilkkappe | RobertBerger, I've seen that file, but it's nosense to me, I haven't that kind of knowledge | 12:06 |
| ilkkappe | The strange thing is that the kernel itself provides the two dtbs, so I expected both to be working | 12:07 |
| RobertBerger | if you want to learn about RCU: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html | 12:08 |
| ilkkappe | The logical difference between the two dtbs (apart from the nodes) is that one expect a second evaluation board on the target | 12:08 |
| ilkkappe | that I don't already have at the moment | 12:08 |
| ilkkappe | RobertBerger, 533 pages ? I expected no more than 10 ! | 12:09 |
| RobertBerger | Hehe - sure ;) | 12:10 |
| RobertBerger | There was just a new paper published from the RCU people "Eighteen Years Later" | 12:11 |
| RobertBerger | RCU Usage In the Linux Kernel: Eighteen Years Later | 12:12 |
| RobertBerger | That's less pages ;) | 12:12 |
| ilkkappe | RobertBerger, thanks btw | 12:15 |
| *** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC | 12:16 | |
| *** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto | 12:25 | |
| *** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC | 12:29 | |
| *** Spock_ncc1701 <Spock_ncc1701!~Spock_ncc@85.203.44.80> has quit IRC | 12:31 | |
| *** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto | 12:37 | |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has quit IRC | 12:40 | |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto | 13:10 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 13:11 | |
| *** ilkkappe <ilkkappe!c65a42b1@198.90.66.177> has quit IRC | 13:18 | |
| *** psnsilva <psnsilva!~psnsilva@194.38.148.130> has joined #yocto | 13:18 | |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has quit IRC | 13:25 | |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-11-174-88-220-58.dsl.bell.ca> has joined #yocto | 13:28 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 13:29 | |
| *** adelcast1 <adelcast1!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has quit IRC | 13:32 | |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 13:33 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 13:50 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 13:51 | |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has joined #yocto | 13:52 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 13:56 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 13:58 | |
| *** Bunio_FH1 <Bunio_FH1!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 13:59 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:01 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 14:01 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC | 14:02 | |
| *** simonpe^^ <simonpe^^!~starlord@c80-217-45-228.bredband.comhem.se> has joined #yocto | 14:15 | |
| *** Bunio_FH <Bunio_FH!~bunio@188.146.177.223.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 14:16 | |
| *** dmoseley <dmoseley!~dmoseley@143.59.236.83> has joined #yocto | 14:18 | |
| simonpe^^ | has anyone been experimenting with build times on different CPU:s? | 14:19 |
| simonpe^^ | I was given a VM with an old Xeon E5530 and I need some data to throw at the person holding the bag of money proving that it is slow | 14:20 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has quit IRC | 14:29 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has joined #yocto | 14:30 | |
| *** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC | 14:32 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 14:36 | |
| rburton | simonpe^^: my standard metric is to remove ptest from DISTRO_FEATURES, do a bitbake core-image-sato --runall fetch to populate the DL_DIR, and time a bitbake core-image-sato. less than an hour is reasonable. | 14:43 |
| rburton | my old builder was a dual E5-2690 and it took 45 minutes | 14:44 |
| rburton | a modern xeon can do that in closer to 20 minutes | 14:44 |
| simonpe^^ | rburton: thx | 14:48 |
| *** simonpe^^ <simonpe^^!~starlord@c80-217-45-228.bredband.comhem.se> has quit IRC | 14:57 | |
| smurray | YPTM: Scott Murray is on | 14:59 |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto | 15:01 | |
| RP | YPTM: Richard is on | 15:01 |
| fray | where is the current dial-in, I don't have a conflict for once | 15:01 |
| sgw | Morning folks, YPTM Saul is on also | 15:01 |
| RP | fray: https://zoom.us/j/990892712 | 15:01 |
| fray | thanks | 15:01 |
| rburton | YPTM ross in | 15:03 |
| fray | YPTM mark is on | 15:03 |
| sgw | Is there a wiki or something that Stephen is working from? | 15:04 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:15 | |
| dl9pf | YPTM Jan-Simon is on | 15:18 |
| *** eduardas <eduardas!~eduardas@85.254.96.13> has quit IRC | 15:18 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 15:20 | |
| JaMa | simonpe^^: see https://github.com/shr-project/test-oe-build-time | 15:23 |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:27 | |
| rburton | oh yes, i forgot about the total overkill of test-oe-build-time :) | 15:39 |
| RP | sgw: it was from the weekly status report | 15:40 |
| rburton | JaMa: IMAGE_INSTALL_append_pn-core-image-sato = " qtwebengine qtwebkit chromium-x11 firefox epiphany" <-- you're *evil* | 15:41 |
| rburton | arguably that's pretty unrepresentative | 15:41 |
| sgw | RP: ok, re-finding where stuff is. | 15:42 |
| *** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 15:45 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-099.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 15:48 | |
| JaMa | rburton: I really wanted to stress dual epyc 7742, so I had to be *evil*, but on the other hand it's not worse than our "bigger" images for TVs :/ | 15:49 |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 15:49 | |
| JaMa | NOTE: Running task 63633 of 65163 ... | 15:50 |
| smurray | gah | 15:57 |
| rburton | ! | 15:59 |
| rburton | JaMa: just a few more and discover if there's an overflow bug | 15:59 |
| *** mckoan is now known as mckoan|away | 16:06 | |
| fray | JaMa: "that's all"? lol my current build: Running task 104757 of 104757 | 16:13 |
| fray | (this is zeus) | 16:13 |
| JaMa | rburton: see fray is evil not me :) | 16:17 |
| rburton | that's quite a large build indeed | 16:18 |
| fray | multiconfig build, 9 configurations at once.. | 16:25 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:26 | |
| neverpanic | ugh, and I thought we had way too many tasks :/ | 16:29 |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has quit IRC | 16:36 | |
| fray | ...nad the build died cause XZ ran my system out of memory.. ugh | 16:39 |
| fray | OOM killer killed an xz process consuming 43 GB of ram... | 16:39 |
| rburton | ! | 16:39 |
| fray | 8294 mhatle 20 0 41.381g 0.028t 0 S 1597 22.9 125:26.10 xz | 16:40 |
| fray | 6289 mhatle 20 0 41.381g 0.028t 120 S 1596 23.0 132:05.87 xz | 16:40 |
| fray | yikes.. | 16:40 |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has quit IRC | 16:48 | |
| *** dmoseley <dmoseley!~dmoseley@143.59.236.83> has quit IRC | 16:50 | |
| *** vineela <vineela!vtummala@nat/intel/x-ehyfqifbnpkpcvjp> has joined #yocto | 16:51 | |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has joined #yocto | 16:52 | |
| JaMa | fray: I had to lower XZ_MEMLIMIT as well | 16:59 |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has joined #yocto | 17:02 | |
| fray | XZ_DEFAULTS = "--memlimit=10% --threads=8" | 17:02 |
| fray | I just did that.. we'll see if it fixes it.. | 17:02 |
| fray | by "percentage" this means with 9 builds, it can take up to 90% of my memory -- which SHOULD be ok | 17:03 |
| fray | and 72 threads (machine only has 16 cores, 32 threads) -- but again that should be fine | 17:03 |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:6c2c:5d38:1ff7:6795:a1db:edd3> has quit IRC | 17:04 | |
| JaMa | for me with 80 threads machine with 384G ram it was failing when building sdk | 17:05 |
| fray | ya, these are SDK builds as well.. 9 in parallel | 17:05 |
| JaMa | but not OOMK killing it, but xz failing to allocate more | 17:05 |
| fray | ohh, this is OOM K.. :P | 17:05 |
| JaMa | I don't use multiconfig | 17:05 |
| fray | no different hten building 9 SDKs in a normal build... | 17:06 |
| fray | so multiconfig shouldn't be different, in this case.. | 17:06 |
| JaMa | I'm building just 1 SDK in 1 build and xz fails with "xz: (stdin): Cannot allocate memory | 17:07 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 17:07 | |
| JaMa | with the default 50% XZ_MEMLIMIT, lowering it to 10% works fine | 17:07 |
| *** stew-dw <stew-dw!~stew-dw@172.58.139.18> has joined #yocto | 17:10 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 17:12 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 17:28 | |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has quit IRC | 17:30 | |
| *** rperier <rperier!~quassel@234.ip-51-91-57.eu> has quit IRC | 17:30 | |
| *** rperier <rperier!~quassel@234.ip-51-91-57.eu> has joined #yocto | 17:30 | |
| *** rperier <rperier!~quassel@unaffiliated/bambee> has joined #yocto | 17:31 | |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has joined #yocto | 17:33 | |
| *** thecomet <thecomet!~thecomet@212-51-148-26.fiber7.init7.net> has joined #yocto | 17:36 | |
| thecomet | Quick question: What is wrong with this URL? | 17:37 |
| thecomet | SRC_URI = "git://git@github.com:technokrat/raichu-core.git;protocol=ssh;branch=rolling" | 17:37 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 17:41 | |
| *** yann <yann!~yann@88.120.44.86> has quit IRC | 17:43 | |
| rburton | needs to be a proper url: turn the : into a / | 17:43 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 17:46 | |
| thecomet | That worked | 17:48 |
| thecomet | But I don't understand. I thought SSH URLs need to be of the form git://host.xz[:port]/path/to/repo.git/ | 17:48 |
| thecomet | It differs from the github clone URL | 17:49 |
| *** stew-dw <stew-dw!~stew-dw@172.58.139.18> has quit IRC | 17:50 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:a22e:3676:f2b7:9997:754d:360d> has joined #yocto | 17:51 | |
| *** rewitt <rewitt!rewitt@unaffiliated/rewitt> has quit IRC | 18:06 | |
| *** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC | 18:07 | |
| rburton | its a bitbake SRC_URI | 18:08 |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 18:08 | |
| rburton | otherwise, how would you tell bitbake that https://github.com/foo/foo is a git clone and not a wget? | 18:08 |
| kergoth | the convention in most projects nowadays is to use git+ssh or the like to distinguish the scheme from the underlying scheme, i could see supporting that eventually | 18:23 |
| *** psnsilva <psnsilva!~psnsilva@194.38.148.130> has quit IRC | 18:37 | |
| *** jrun <jrun!~jrun@unaffiliated/glphvgacs> has joined #yocto | 18:43 | |
| jrun | looking for a good vs-read on portage vs. bitbake; i come from gentoo... | 18:43 |
| jrun | 2 things i would like to know; does the notion of USE flags has an equivalent in bitbake? | 18:44 |
| jrun | 2 where should the kernel part in bitbake? | 18:44 |
| jrun | ... i mean is that done in BSP? | 18:45 |
| neverpanic | jrun: sort of, there's the PACKAGECONFIG mechanism. | 18:45 |
| neverpanic | and yes, the kernel is usually part of the bsp | 18:46 |
| jrun | neverpanic: is it like set once; will be applied everywhere with per-package granularity? | 18:47 |
| *** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:5555:66ce:2859:d3e9> has joined #yocto | 18:48 | |
| jrun | neverpanic: good pionter; thanks | 18:49 |
| neverpanic | jrun: DISTRO_FEATURES provides that to an extent, e.g. being able to select whether you boot with systemd or sysv-init (not sure whether that's still supported, it was back in the days) | 18:49 |
| jrun | DISTRO_FEATURES sounds more like eselect then | 18:50 |
| *** fl0v0 <fl0v0!~fvo@88.130.219.85> has quit IRC | 18:52 | |
| jrun | neverpanic: anything like ```equery use $pkg_name``` for listing available "flags"? | 18:52 |
| jrun | neverpanic: is it safe to consider layers like overlays in gentoo? | 18:55 |
| neverpanic | I don't know enough about Gentoo to answer these. | 18:55 |
| kergoth | there's no direct equivalent, it depends onw hat you're setting | 18:55 |
| kergoth | DISTRO_FEATURES, MACHINE_FEATURES, IMAGE_FEATURES all toggle behavior, and per-recipe there's PACKAGECONFIG | 18:56 |
| kergoth | but i.e. 'opengl' is a distro feature, not a use flag | 18:56 |
| kergoth | and where the kernel is depends on what MACHINE you're targeting | 18:56 |
| kergoth | bitbake -e virtual/kernel | grep '^FILE=' should tell you given your current configuration | 18:56 |
| kergoth | so yes, the bsp for that | 18:56 |
| kergoth | bitbake was originally highly portage inspired, but the requirements were substantially different, and we wanted a directly parsed format, not shell | 18:57 |
| kergoth | being able to build *on* any architecture or distro and build *for* any architecture or distro and produce any number of filesystems for any of those was prioritized | 18:58 |
| jrun | kergoth: by filesystem, i'm guessing, you meanr root tree, correct? | 18:58 |
| rburton | mainly but not exclusively | 18:59 |
| jrun | kergoth: how does layers come into this? they're like local/layman overlays on top of the main receipies? | 18:59 |
| kergoth | i believe so given my limited knowledge of how those work, at least conceptually, but how things are implemented is much different | 19:00 |
| jrun | rburton: a good example here i guess would be split-usr; a use flag in portage for systemd's requirement to put root tree in one directory; mkosi et al... | 19:01 |
| jrun | rburton: but i'm just guessing; i actually i don't know what filesystem mean in what kergoth said. | 19:02 |
| kergoth | that would be a distro feature for us, since it's an overall policy decision that affects multiple recipe behavior | 19:02 |
| jrun | kergoth: uh, starting to make sense | 19:02 |
| kergoth | i meant a rootfs, disk image, iso, binary to flash an sdcard, etc | 19:02 |
| jrun | kergoth: or pack into kernel if there is enough ram :) | 19:03 |
| kergoth | machine controls bsp behavior and hardware capabilities. for example, there are cases where a machine might support something but your distro doesn't, or vice versa | 19:03 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 19:03 | |
| kergoth | yep, for us that means an image recipe that emits a cpio and setting a config variable that the kernel recipe obeys to depend on that and pull it in | 19:04 |
| kergoth | and any image recipe should work for any distro or machine, any distro should work for any machine, etc. of course it's not always so clear cut, but that's the intention | 19:04 |
| kergoth | other distro decisions include packaging format, systemd vs sysvinit, etc | 19:04 |
| jrun | kergoth: and how come Gentoo is not supported! | 19:05 |
| kergoth | split-usr specifically does exist for us, i don't recall the exact name of the distro feature, though | 19:05 |
| kergoth | exactly what you mean by gentoo would be the question. distro decisions? packaging format? host? the latter would already build fine. the others would be just a matter of inclination and resources. | 19:05 |
| fray | Way I look at it.. MACHINE features are how is the kernel, and other 'pre-userspace' software configured (at a high level), DISTRO FEATUREs are how are the userspace software configured (across the bredth of recipes), and PACKAGECONFIG is how is a single recipe configured.. | 19:05 |
| kergoth | yeah. and of course packageconfig often sets defaults based on the distro features | 19:06 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 19:06 | |
| kergoth | things do get fuzzy at times, though. if i want my distro to enable additional debugging or tracing features that require kernel config fragments to be enabled for all of my bsps, for example, gets messy :) but that's pretty rare | 19:07 |
| jrun | which means DISTRO_FEATURES and PACKAGE_CONFIG have intersections, right? | 19:07 |
| fray | exactly.. PACKAGECONFIG usually inherits from DISTRO_FEATURES, it CAN inherit from MACHINE features (for machine specific packages).. etc.. but everything is to add flexibility -- so like kergoth says.. "it's fuzzy" | 19:07 |
| kergoth | this structure of highly flexible components and orthogonal axes of configuration is a big part of how so many companies are able to collaborate on the same baseline with their highly different requirements | 19:08 |
| kergoth | the downside of course is the rather steep learning curve, but it's a tradeoff | 19:08 |
| fray | yup, tradeoff we're always trying to balance, but at least it's (usually) easy to think "what does my change affect", and that can be a guide on how to do it 'right'.. I want to change the whole system to use 'PAM'? that would be distro feature.. I want this one recipe to not enable something PACKAGECONFIG | 19:10 |
| fray | etc | 19:10 |
| jrun | so VIDEO_CARD, CFLAGS in portage for example is a MACHINE thing; X, bluetooth, nvme etc USE flags also could be MACHINE things; split-usr is DISTRO and so on | 19:10 |
| fray | (risk in all of this of course is you define 1000 DISTRO FEATURES that nobody knows what they are or how to use them).. but so far, that hasn't happened | 19:10 |
| fray | roughly speaking VIDEO_CARD would be.. but CFLAGS is influended by the 'MACHINE', but it's really distro.. | 19:11 |
| jrun | it's fuzzy in gentoo too, i'm just used to it | 19:11 |
| fray | again, fuzzy.. | 19:11 |
| kergoth | yeah, that's the thing, there's so strict list of available features, it's controlled where they're used. if a recipe checks for a feature, then that feature clearly exists :) | 19:12 |
| fray | machine (configuration) is responsible for saying 'I support this kind of CPU and it's associated tunings..'... Then distro uses this to actually confgiure and make things work | 19:12 |
| kergoth | s/so/no/ | 19:12 |
| fray | it was done this way (machine/tune) so that you can build multiple machines that used (most of) the same userspace... where only machine specific things were optimized for that machine | 19:13 |
| fray | default though is usually to optimize as much as possible.. while I'm working on creating a more generic system, so I'm having to override a lot of this stuff (tunings) to set more generic CPU related cflags.. | 19:14 |
| fray | i.e. where something may be defined as cortex-a53 or cortex-a72.. since I'm focusing on a common runtime for both.. I need to configure for the hybrid cortex-a53.a72 | 19:14 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 19:16 | |
| jrun | what tools are the for listing stuff? listing other people's meta layers, listing available DISTRO_FEATURES, PACKAGECONFIG etc? | 19:17 |
| jrun | is it all in bitbake? | 19:17 |
| jrun | actually something else; years ago i proposed something to GSoC for easing kernel configuration for users (genkernel i guess), i would have db of boards and it would configure the kernel based on that; anyway... BSP sounds like that idea to me | 19:19 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 19:21 | |
| jrun | ... so as an example i gutted the modem my ISP gave me yesterday... pretty sure it's arm, it asks for uboot.bin via dhcp on reboot... now i i wanna see if OEM has some branch or BSP for it (i don't even know if bsp is supposed to be a branch in poky, will find out) | 19:22 |
| jrun | where do i look for this? is there tool for it or just plaint git branch inside poky? | 19:22 |
| *** abest <abest!43b6c2ec@c-67-182-194-236.hsd1.ut.comcast.net> has joined #yocto | 19:28 | |
| PaowZ | hi guys ! Is there a procedure to release an unattended installation image with wic ? I cannot see anything like that in the doc.. the command features for wic has been narrowed down to part/bootloader, therefore, I cant fiddle a proper kickstart file.. | 19:28 |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 19:36 | |
| fray | jrun look at layers.openembedded.org this is all published stuff.. | 19:36 |
| *** abest <abest!43b6c2ec@c-67-182-194-236.hsd1.ut.comcast.net> has quit IRC | 19:49 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 19:49 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 19:51 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 19:53 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 19:54 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 19:58 | |
| *** vineela <vineela!vtummala@nat/intel/x-ehyfqifbnpkpcvjp> has quit IRC | 20:01 | |
| kergoth | fray: i think angstrom did some work on the generic vs specific tuning stuff for its feeds to maximize sharing | 20:01 |
| kergoth | jrun: the layer index is your best bet, really. there area couple scripts in oe-core that do a little, but as we said, listing available is problematic for anything but packageconfig | 20:02 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 20:03 | |
| *** yann <yann!~yann@88.120.44.86> has quit IRC | 20:05 | |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 20:06 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 20:13 | |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 20:14 | |
| RobertBerger | @fray: I am currently playing with cortex-a53 and cortex-a72 as well and try to come up with more generic compiler tunes which work on both. | 20:16 |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 20:17 | |
| RobertBerger | @fray: I did benchmarks on cortex-a53 vs. armv8-hf (which is more generic) and absolutely no difference in the benchmarks | 20:17 |
| *** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 20:17 | |
| RobertBerger | @fray: hopefully I will soon also have something for the cortex-a72 | 20:17 |
| RobertBerger | @fray: I would really like to see benchmark which show a difference between e.g. cortex-a53 and armv8-hf - what I actually see is that the more generic is slightly better on some benchmarks | 20:19 |
| fray | I honestly don't expect any difference between a53 and armv8 | 20:19 |
| RobertBerger | I can't see any on CPU benchmarks. | 20:20 |
| fray | It's adding the a72 that makes a difference, but it needs to be done in a way not to negatively impact a53.. so that is where the hybrid one comes into place | 20:20 |
| RobertBerger | Also no difference between cortex-a9-hf and armv7-hf | 20:20 |
| fray | I've never looked into that.. | 20:21 |
| RobertBerger | I will try the a72 also with armv8-hf-crc-crypto and see if that makes any difference | 20:21 |
| fray | I need generic.. code needs run on both a72 and a53.. so the CRC-CRYPTO can be disabled for all I care | 20:26 |
| RobertBerger | Then you want only armv8-hf I guess | 20:34 |
| fray | yes | 20:35 |
| RobertBerger | Maybe something here? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc | 20:35 |
| fray | but scheduling the code for the out of order unit on the a72 does provide wins | 20:35 |
| RobertBerger | I am very curious - in my case it's 2 different boards. | 20:35 |
| fray | and for my use, I don't care about any other variants, other then a53 adn a72.. | 20:35 |
| fray | I'm supporting many different boards, but only two arm cores (for 64-bit) | 20:36 |
| fray | if the end user wants further optimization (like crc-crypto) then they would enable that themselves | 20:36 |
| zandrey | fray, RobertBerger: hope you guys would not mind if I jump in here. i guess for CA53 it would all depends also on the CPU implementer. there are some instructions that might be supported by the compiler, but core would not have them implemented. | 20:36 |
| RobertBerger | If you want big-little also this maybe: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 20:36 |
| fray | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 20:37 |
| fray | this is the one I'm running | 20:37 |
| zandrey | this is detailed in Cortex-A53 MPCore TRM, where the description of ISAR[0-5] is provided | 20:37 |
| fray | zandrey in my case, these are "standard" implementations from ARM.. so simple ennough | 20:37 |
| RobertBerger | @zandrey: It's all just marketing for hardware nerds - Show me the benchmarks ;) | 20:37 |
| zandrey | fray: this is what i've seen several times - ARM says: "it's implementer-dependent", and then SOC manufacturer opt-in or opt-out for that in its RTL | 20:38 |
| fray | from everything I've seen it's the 'standard' default ARM core.. no other changes from a software perspective.. | 20:39 |
| fray | (I'm sure there are changes from SOC to SOC wiring it to the rest of the chip.. but that doesn't affect userspace) | 20:39 |
| zandrey | RobertBerger: i don't think you would get some. unless the benchmark is so hand-crafter (in asm as well) to show the best performance for a very narrow use-case | 20:39 |
| zandrey | what i was trying to say: it might be that even if tunes are available and properly set - there would be little to no benefit, unless a specialized use-case is taken | 20:41 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 20:41 | |
| zandrey | this is - not considering -hf or course | 20:42 |
| RobertBerger | So why we optimize and fine tune out compiler tunes with YP/OE? Just to burn more electricity while building? | 20:42 |
| zandrey | RobertBerger: nope, that is not quite a complete picture. i still would expect the best performance from the code that toolchain produces. | 20:43 |
| RobertBerger | Well in theory, since benchmarks don't show that. | 20:43 |
| zandrey | i'm one of those kind of guys who opts for performance over conformance ;) | 20:44 |
| RobertBerger | "hardware nerd" | 20:44 |
| zandrey | :D guilty as charged! | 20:44 |
| fray | I have seen in the past, a 5% difference in general performance (gained from tuning) was the difference between a core meeting requirements, and the project having to start over on a different core.. | 20:44 |
| RobertBerger | Really I expected to see some difference - a small one. But NOPE. So please feed me with test cases and benchmarks. | 20:45 |
| fray | so the default to tune, I think is good for the SEMIs and for the users who don't have any need for generic behavir (which to be honest is pretty much 90% of the users) | 20:45 |
| RobertBerger | @fray, but this is most likely by writing the code differently - you could even get more. | 20:45 |
| fray | for the remaining 10% who are trying to build more generic software, we have easy ways to adapt | 20:45 |
| RobertBerger | I mean using the brain to write optimized code (which is rather hard with the compilers we have nowadays) and not turning non magic compiler flags. | 20:46 |
| fray | it's been mostly graphics code where i've seen the true performance issues in the past.. and it's been too complex to write without optimizing compiler.. (except for limited functions) | 20:48 |
| kergoth | minor differences in sstate reuse or oe build time haven't tended to be a problem in my experience, the weekly build takes forever regardless of tuning, and very few care about package feed reuse | 20:48 |
| kergoth | and often you want a from scratch build regularly anyway | 20:49 |
| fray | agreed, this is a 'minor' use-case | 20:49 |
| zandrey | agreed, i can live with that too :P | 20:49 |
| RobertBerger | Let me put it otherwise - if I have a single user space/kernel for many different arm32 boards it really helps with build time and testing. | 20:50 |
| RobertBerger | If you pick a different compiler tune it's not a minor change - it's totally different | 20:52 |
| kergoth | https://github.com/Angstrom-distribution/meta-angstrom/blob/master/conf/distro/include/arm-defaults.inc | 20:52 |
| kergoth | that sort of thing might be of interest | 20:53 |
| RobertBerger | Hehe - apparently I like that ;) | 20:54 |
| kergoth | angstrom has long prioritized more generic tuning to increase reuse of packages in their maintained package feeds | 20:55 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 20:56 | |
| RobertBerger | I currently use this for arm32: TUNE_FEATURES = "arm armv7a vfp thumb callconvention-hard" | 20:56 |
| RobertBerger | TARGET_FPU = "hard" | 20:56 |
| zandrey | kergoth: i like the signature of the statement in that file :) | 20:56 |
| RobertBerger | hehe - even Khem agrees ;) | 20:56 |
| kergoth | it would be nice to more easily control the behavior at the very least | 20:58 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 20:58 | |
| zandrey | RobertBerger: this is an interesting bug which looks at the crc32 improvements: https://bugs.chromium.org/p/chromium/issues/detail?id=709716 | 20:59 |
| fray | we've done a different tactic.. we define the machines to use the generic machines (via a soc include file).. and then if the user wants it more optimized they can override the DEFAULTTUNE in their local.conf | 20:59 |
| zandrey | with generic tunes i don't think you would have CRC32 opcode produced... | 21:00 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 21:00 | |
| zandrey | the claim there was - up to 10x, so you might reproduce this test case | 21:01 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:02 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 21:07 | |
| *** MiskaX <MiskaX!ykf0erb5kw@rankki.sonarnerd.net> has quit IRC | 21:07 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:a22e:3676:f2b7:9997:754d:360d> has quit IRC | 21:09 | |
| zandrey | RobertBerger: and this one - is for SHA, which you would get *only* with -crypto: https://github.com/minio/sha256-simd | 21:09 |
| zandrey | dunno if one can trust those, but results are quite astonishing! | 21:10 |
| *** jatedev <jatedev!~jatedev@c-69-254-209-160.hsd1.fl.comcast.net> has joined #yocto | 21:12 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 21:13 | |
| *** MiskaX <MiskaX!trop0y73ze@rankki.sonarnerd.net> has joined #yocto | 21:13 | |
| *** stew-dw <stew-dw!~stew-dw@2607:fb90:2ae:1057:177:6615:75b3:e1d7> has joined #yocto | 21:14 | |
| RobertBerger | @zandry - in x86 assembly on arm? | 21:18 |
| RobertBerger | And now to something completely different | 21:19 |
| zandrey | RobertBerger: nope, this one - it "pure" aarch64 https://github.com/minio/sha256-simd/blob/master/sha256block_arm64.s | 21:20 |
| RobertBerger | is nativesdk-packagegroup-sdk-host used both by the extensible SDK and the "classic" one? | 21:20 |
| RobertBerger | it looks like it's only used by the "classic" sdk | 21:21 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 21:21 | |
| RobertBerger | I also like this one: | 21:23 |
| RobertBerger | ./resy-glibc-x86_64-core-image-sato-sdk-armv7a-neon-multi-v7-ml-toolchain-ext-3.1.2.sh | 21:23 |
| RobertBerger | ./resy-glibc-x86_64-core-image-sato-sdk-armv7a-neon-multi-v7-ml-toolchain-ext-3.1.2.sh: 29: gcc: not found | 21:23 |
| RobertBerger | Resy (Reliable Embedded Systems Reference Distro) Extensible SDK installer version 3.1.2 | 21:23 |
| RobertBerger | ======================================================================================== | 21:23 |
| RobertBerger | ERROR: the SDK requires the following missing utilities, please install them: diffstat gcc g++ | 21:23 |
| RobertBerger | I need to a gcc and g++ to install an SDK??? | 21:23 |
| RobertBerger | it looks like nativesdk-packagegroup-sdk-host is used by both extensible SDK and the "classic" one via the populate_sdk_base.bbclass | 21:29 |
| *** jatedev <jatedev!~jatedev@c-69-254-209-160.hsd1.fl.comcast.net> has quit IRC | 21:46 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:12 | |
| *** angery <angery!~dave@d66-183-215-121.bchsia.telus.net> has joined #yocto | 22:19 | |
| *** jatedev <jatedev!~jatedev@c-69-254-209-160.hsd1.fl.comcast.net> has joined #yocto | 22:22 | |
| fray | Odd, setting XZ_DEFAULTS didn't seem to change the way 'xz' worked.. it still rand out of memory after gobbling > 10% | 22:24 |
| RP | fray: I think you have to lower the compression options to do that | 22:25 |
| fray | xz man page says that: XZ_DEFAULTS = "--memlimit=10% --threads=8" "should" work | 22:28 |
| fray | xz -f -k -c -9 --memlimit=10% --threads=8 --check=crc32 <file> > <output> | 22:28 |
| fray | currently skimming the man page to figure this out | 22:31 |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC | 22:32 | |
| fray | looks like I have a use of 'xz' that does NOT use XZ_DEFAULTS.. now I have to track down if it's my bug or something belse.. | 22:34 |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 22:35 | |
| fray | (looking at Zeus, but it looks like a bug in populate_sdk_base) | 22:36 |
| fray | ahh looks like master has a fix for it... | 22:37 |
| fray | Fixed in Poky commit: 27ff81bfd880280607c79dce2f724c8bfafce02d Marh 20 2020.. so newer then eus | 22:38 |
| fray | 'er.. Zeus.. at least i know what I need to fix it | 22:38 |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 22:39 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has quit IRC | 23:21 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:812e:2d2f:a669:186f> has joined #yocto | 23:24 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-114-156.ssp.dialog.net.pl> has quit IRC | 23:28 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!