Tuesday, 2020-09-08

*** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-dzbpayzogjztxspk> has joined #yocto00:02
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC00:26
*** armpit <armpit!~armpit@2601:202:4180:a5c0:f534:593a:c9d7:eb3d> has quit IRC00:33
*** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has joined #yocto00:37
*** j2411 <j2411!~Adium@20.ip-51-79-160.net> has quit IRC01:00
*** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto01:01
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto01:03
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC01:07
*** yizhao <yizhao!~zhaoyi@> has joined #yocto01:50
*** yizhao <yizhao!~zhaoyi@> has quit IRC03:06
*** yizhao <yizhao!~zhaoyi@> has joined #yocto03:08
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC03:14
*** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC03:20
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC03:28
*** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto03:32
*** yizhao <yizhao!~zhaoyi@> has quit IRC03:33
*** yizhao <yizhao!~zhaoyi@> has joined #yocto03:37
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC03:38
*** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC03:51
*** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-099.hsi5.kabel-badenwuerttemberg.de> has joined #yocto04:30
*** yizhao <yizhao!~zhaoyi@> has quit IRC04:50
*** yizhao <yizhao!~zhaoyi@> has joined #yocto04:53
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto04:56
*** yizhao <yizhao!~zhaoyi@> has quit IRC05:00
*** yizhao <yizhao!~zhaoyi@> has joined #yocto05:01
*** yizhao <yizhao!~zhaoyi@> has quit IRC05:19
*** yizhao <yizhao!~zhaoyi@> has joined #yocto05:22
*** yizhao <yizhao!~zhaoyi@> has quit IRC05:27
*** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto05:33
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto05:39
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:44
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto05:49
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC05:50
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:04
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto06:12
*** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC06:13
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:14
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto06:15
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC06:19
*** elGamal <elGamal!~elg@> has quit IRC06:20
*** elGamal <elGamal!~elg@> has joined #yocto06:22
*** mckoan|away is now known as mckoan06:30
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto06:35
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC06:39
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC06:43
*** chris_ber <chris_ber!~quassel@> has joined #yocto06:52
*** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto06:56
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto06:56
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto07:06
*** zandrey <zandrey!~zandrey@> has joined #yocto07:08
*** zandrey_ <zandrey_!~zandrey@> has joined #yocto07:10
*** zandrey <zandrey!~zandrey@> has quit IRC07:13
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto07:19
*** tensa <tensa!~tensa@vm-irc.spline.inf.fu-berlin.de> has quit IRC07:28
*** tensa <tensa!~tensa@vm-irc.spline.inf.fu-berlin.de> has joined #yocto07:28
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto07:44
*** xxxx <xxxx!34bba72f@> has joined #yocto07:56
*** xxxx <xxxx!34bba72f@> has quit IRC07:58
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:16
*** rperier <rperier!~quassel@unaffiliated/bambee> has quit IRC08:26
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC08:31
*** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC08:32
*** rperier <rperier!~quassel@234.ip-51-91-57.eu> has joined #yocto08:34
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto08:36
*** wbn <wbn!~badegg@2607:5300:60:2ca::1> has quit IRC08:41
*** wbn <wbn!~badegg@ns509729.ip-198-245-62.net> has joined #yocto08:41
alejandrohsis 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 201508:50
RPalejandrohs: it means we need to get the CVE information about effected versions fixed as I understand it08:51
RPrburton: ^^^08:51
rburtonalejandrohs: yes, the qemu cves are famous for not putting versions in08:52
rburtoni've been trawling through them slowly fixing the cve database upstream, they don't start from 2012 now :)08:52
RPrburton: you should get a star for that :)08:54
alejandrohsOkay I see, I just saw it and was just wondering if it was known08:55
*** dlan <dlan!~dennis@> has joined #yocto08:55
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto08:55
rburtonwill try and do a few more today, the plan is to slowly chip at a few every day08:57
alejandrohsgoing 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 some08:58
alejandrohsrburton: ^^08:58
RParmpit: fixed the signing failure, perf issue didn't recur09:09
*** hpsy <hpsy!~hpsy@> has quit IRC09:17
*** hpsy1 <hpsy1!~hpsy@> has joined #yocto09:17
*** Bunio_FH <Bunio_FH!~bunio@> has joined #yocto09:17
*** Bunio_FH1 <Bunio_FH1!~bunio@81-18-201-214.static.chello.pl> has joined #yocto09:20
*** Bunio_FH <Bunio_FH!~bunio@> has quit IRC09:22
*** mihai is now known as mihaix09:30
*** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto09:31
*** eduardas <eduardas!~eduardas@> has joined #yocto09:39
eduardashello, 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
eduardaswhat 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@> has quit IRC09:56
*** elGamal <elGamal!~elg@> has joined #yocto09:57
*** pbb <pbb!~quassel@2a0f:4ac0::7> has quit IRC10:17
*** pbb <pbb!~quassel@2a0f:4ac0::7> has joined #yocto10:17
*** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC10:36
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto10:40
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-jizbuaqyarwisjbe> has joined #yocto10:48
*** Guest5286 <Guest5286!a5e14934@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto10:50
*** Guest5286 <Guest5286!a5e14934@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC10:53
*** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto10:54
shan1Hi 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 great10:55
shan1Also I keep getting an error10:57
shan1ERROR: 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@> has joined #yocto10:58
kayterinahello, I think you just add that machine in COMPATIBLE_MACHINE in your layer10:59
shan1kayterina 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
kayterinaok, so the error comes from the BSP, not a cusotm layer?11:02
kayterinahm...can you search for COMPATIBLE_MACHINE in their layers?11:04
kayterinakeep in mind I am not experienced with yocto,that's just what I'd do11:04
shan1It is there, the BSP version is on Yocto Warrior > http://layers.openembedded.org/layerindex/branch/warrior/layer/meta-phytec/11:04
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto11:08
*** hpsy1 <hpsy1!~hpsy@> has quit IRC11:29
*** hpsy <hpsy!~hpsy@> has joined #yocto11:29
*** ilkkappe <ilkkappe!c65a42b1@> has joined #yocto11:35
ilkkappeHello 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 lines11:36
ilkkappe   24.673938] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:11:36
ilkkappeAlso, the strange thing is that it seems related to the dtb file11:37
ilkkappethis is beacause if I use the same kernel with dtbA the kernel boots correctly11:37
ilkkappeif I use the same kernel with dtbB the kernel doesn't boot correctly and continue to report the previous lines11:38
*** Spock_ncc1701 <Spock_ncc1701!~Spock_ncc@> has joined #yocto11:38
ilkkappeThe 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@> has joined #yocto11:44
RobertBerger@ilkkappe: What new kernel modules does the new device tree activate?12:04
ilkkappebasically one clock distributor and one adc converter12:04
RobertBerger@ilkkappe: https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt12:04
RobertBergerI guess something is wrong in those ;)12:05
ilkkappeis it possible in your opinio, that if the board with the adc and the distributor is not plugged in the kernel hangs12:05
ilkkappeRobertBerger, I've seen that file, but it's nosense to me, I haven't that kind of knowledge12:06
ilkkappeThe strange thing is that the kernel itself provides the two dtbs, so I expected both to be working12:07
RobertBergerif you want to learn about RCU: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html12:08
ilkkappeThe logical difference between the two dtbs (apart from the nodes) is that one expect a second evaluation board on the target12:08
ilkkappethat I don't already have at the moment12:08
ilkkappeRobertBerger, 533 pages ? I expected no more than 10 !12:09
RobertBergerHehe - sure ;)12:10
RobertBergerThere was just a new paper published from the RCU people "Eighteen Years Later"12:11
RobertBergerRCU Usage In the Linux Kernel: Eighteen Years Later12:12
RobertBergerThat's less pages ;)12:12
ilkkappeRobertBerger, thanks btw12:15
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC12:16
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto12:25
*** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC12:29
*** Spock_ncc1701 <Spock_ncc1701!~Spock_ncc@> has quit IRC12:31
*** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto12:37
*** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has quit IRC12:40
*** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto13:10
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto13:11
*** ilkkappe <ilkkappe!c65a42b1@> has quit IRC13:18
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto13:18
*** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has quit IRC13:25
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-11-174-88-220-58.dsl.bell.ca> has joined #yocto13:28
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto13:29
*** adelcast1 <adelcast1!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has quit IRC13:32
*** yann <yann!~yann@> has joined #yocto13:33
*** dmoseley <dmoseley!~dmoseley@> has quit IRC13:50
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto13:51
*** jwessel <jwessel!~jwessel@> has joined #yocto13:52
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto13:56
*** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto13:58
*** Bunio_FH1 <Bunio_FH1!~bunio@81-18-201-214.static.chello.pl> has quit IRC13:59
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto14:01
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC14:01
*** zandrey_ <zandrey_!~zandrey@> has quit IRC14:02
*** simonpe^^ <simonpe^^!~starlord@c80-217-45-228.bredband.comhem.se> has joined #yocto14:15
*** Bunio_FH <Bunio_FH!~bunio@> has joined #yocto14:16
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto14: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 slow14:20
*** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has quit IRC14:29
*** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has joined #yocto14:30
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC14:32
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto14:36
rburtonsimonpe^^: 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
rburtonmy old builder was a dual E5-2690 and it took 45 minutes14:44
rburtona modern xeon can do that in closer to 20 minutes14:44
simonpe^^rburton: thx14:48
*** simonpe^^ <simonpe^^!~starlord@c80-217-45-228.bredband.comhem.se> has quit IRC14:57
smurrayYPTM: Scott Murray is on14:59
*** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto15:01
RPYPTM: Richard is on15:01
fraywhere is the current dial-in, I don't have a conflict for once15:01
sgwMorning folks, YPTM Saul is on also15:01
RPfray: https://zoom.us/j/99089271215:01
rburtonYPTM ross in15:03
frayYPTM mark is on15:03
sgwIs there a wiki or something that Stephen is working from?15:04
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:15
dl9pfYPTM Jan-Simon is on15:18
*** eduardas <eduardas!~eduardas@> has quit IRC15:18
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto15:20
JaMasimonpe^^: see https://github.com/shr-project/test-oe-build-time15:23
*** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC15:27
rburtonoh yes, i forgot about the total overkill of test-oe-build-time :)15:39
RPsgw: it was from the weekly status report15:40
rburtonJaMa: IMAGE_INSTALL_append_pn-core-image-sato = " qtwebengine qtwebkit chromium-x11 firefox epiphany" <-- you're *evil*15:41
rburtonarguably that's pretty unrepresentative15:41
sgwRP: ok, re-finding where stuff is.15:42
*** rcw <rcw!~rcw@> has joined #yocto15:45
*** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-099.hsi5.kabel-badenwuerttemberg.de> has quit IRC15:48
JaMarburton: 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@> has quit IRC15:49
JaMaNOTE: Running task 63633 of 65163 ...15:50
rburtonJaMa: just a few more and discover if there's an overflow bug15:59
*** mckoan is now known as mckoan|away16:06
frayJaMa: "that's all"?  lol my current build: Running task 104757 of 10475716:13
fray(this is zeus)16:13
JaMarburton: see fray is evil not me :)16:17
rburtonthat's quite a large build indeed16:18
fraymulticonfig build, 9 configurations at once..16:25
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC16:26
neverpanicugh, and I thought we had way too many tasks :/16:29
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC16:36
fray...nad the build died cause XZ ran my system out of memory.. ugh16:39
frayOOM killer killed an xz process consuming 43 GB of ram...16:39
fray 8294 mhatle    20   0 41.381g 0.028t      0 S  1597 22.9 125:26.10 xz16:40
fray 6289 mhatle    20   0 41.381g 0.028t    120 S  1596 23.0 132:05.87 xz16:40
*** jwessel <jwessel!~jwessel@> has quit IRC16:48
*** dmoseley <dmoseley!~dmoseley@> has quit IRC16:50
*** vineela <vineela!vtummala@nat/intel/x-ehyfqifbnpkpcvjp> has joined #yocto16:51
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto16:52
JaMafray: I had to lower XZ_MEMLIMIT as well16:59
*** jwessel <jwessel!~jwessel@> has joined #yocto17:02
frayXZ_DEFAULTS = "--memlimit=10% --threads=8"17:02
frayI just did that.. we'll see if it fixes it..17:02
frayby "percentage" this means with 9 builds, it can take up to 90% of my memory -- which SHOULD be ok17:03
frayand 72 threads (machine only has 16 cores, 32 threads) -- but again that should be fine17:03
*** stew-dw <stew-dw!~stew-dw@2607:fb90:6c2c:5d38:1ff7:6795:a1db:edd3> has quit IRC17:04
JaMafor me with 80 threads machine with 384G ram it was failing when building sdk17:05
frayya, these are SDK builds as well.. 9 in parallel17:05
JaMabut not OOMK killing it, but xz failing to allocate more17:05
frayohh, this is OOM K.. :P17:05
JaMaI don't use multiconfig17:05
frayno different hten building 9 SDKs in a normal build...17:06
frayso multiconfig shouldn't be different, in this case..17:06
JaMaI'm building just 1 SDK in 1 build and xz fails with "xz: (stdin): Cannot allocate memory17:07
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto17:07
JaMawith the default 50% XZ_MEMLIMIT, lowering it to 10% works fine17:07
*** stew-dw <stew-dw!~stew-dw@> has joined #yocto17:10
*** dmoseley <dmoseley!~dmoseley@> has quit IRC17:12
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto17:28
*** jwessel <jwessel!~jwessel@> has quit IRC17:30
*** rperier <rperier!~quassel@234.ip-51-91-57.eu> has quit IRC17:30
*** rperier <rperier!~quassel@234.ip-51-91-57.eu> has joined #yocto17:30
*** rperier <rperier!~quassel@unaffiliated/bambee> has joined #yocto17:31
*** jwessel <jwessel!~jwessel@> has joined #yocto17:33
*** thecomet <thecomet!~thecomet@212-51-148-26.fiber7.init7.net> has joined #yocto17:36
thecometQuick question: What is wrong with this URL?17:37
thecometSRC_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 IRC17:41
*** yann <yann!~yann@> has quit IRC17:43
rburtonneeds 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 #yocto17:46
thecometThat worked17:48
thecometBut I don't understand. I thought SSH URLs need to be of the form git://host.xz[:port]/path/to/repo.git/17:48
thecometIt differs from the github clone URL17:49
*** stew-dw <stew-dw!~stew-dw@> has quit IRC17:50
*** stew-dw <stew-dw!~stew-dw@2607:fb90:a22e:3676:f2b7:9997:754d:360d> has joined #yocto17:51
*** rewitt <rewitt!rewitt@unaffiliated/rewitt> has quit IRC18:06
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC18:07
rburtonits a bitbake SRC_URI18:08
*** yann <yann!~yann@> has joined #yocto18:08
rburtonotherwise, how would you tell bitbake that https://github.com/foo/foo is a git clone and not a wget?18:08
kergoththe 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 eventually18:23
*** psnsilva <psnsilva!~psnsilva@> has quit IRC18:37
*** jrun <jrun!~jrun@unaffiliated/glphvgacs> has joined #yocto18:43
jrunlooking for a good vs-read on portage vs. bitbake; i come from gentoo...18:43
jrun2 things i would like to know; does the notion of USE flags has an equivalent in bitbake?18:44
jrun2 where should the kernel part in bitbake?18:44
jrun... i mean is that done in BSP?18:45
neverpanicjrun: sort of, there's the PACKAGECONFIG mechanism.18:45
neverpanicand yes, the kernel is usually part of the bsp18:46
jrunneverpanic: 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 #yocto18:48
jrunneverpanic: good pionter; thanks18:49
neverpanicjrun: 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
jrunDISTRO_FEATURES sounds more like eselect then18:50
*** fl0v0 <fl0v0!~fvo@> has quit IRC18:52
jrunneverpanic: anything like ```equery use $pkg_name``` for listing available "flags"?18:52
jrunneverpanic: is it safe to consider layers like overlays in gentoo?18:55
neverpanicI don't know enough about Gentoo to answer these.18:55
kergoththere's no direct equivalent, it depends onw hat you're setting18:55
kergothDISTRO_FEATURES, MACHINE_FEATURES, IMAGE_FEATURES all toggle behavior, and per-recipe there's PACKAGECONFIG18:56
kergothbut i.e. 'opengl' is a distro feature, not a use flag18:56
kergothand where the kernel is depends on what MACHINE you're targeting18:56
kergothbitbake -e virtual/kernel | grep '^FILE=' should tell you given your current configuration18:56
kergothso yes, the bsp for that18:56
kergothbitbake was originally highly portage inspired, but the requirements were substantially different, and we wanted a directly parsed format, not shell18:57
kergothbeing 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 prioritized18:58
jrunkergoth: by filesystem, i'm guessing, you meanr root tree, correct?18:58
rburtonmainly but not exclusively18:59
jrunkergoth: how does layers come into this? they're like local/layman overlays on top of the main receipies?18:59
kergothi believe so given my limited knowledge of how those work, at least conceptually, but how things are implemented is much different19:00
jrunrburton: 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
jrunrburton: but i'm just guessing; i actually i don't know what filesystem mean in what kergoth said.19:02
kergoththat would be a distro feature for us, since it's an overall policy decision that affects multiple recipe behavior19:02
jrunkergoth: uh, starting to make sense19:02
kergothi meant a rootfs, disk image, iso, binary to flash an sdcard, etc19:02
jrunkergoth: or pack into kernel if there is enough ram :)19:03
kergothmachine controls bsp behavior and hardware capabilities. for example, there are cases where a machine might support something but your distro doesn't, or vice versa19:03
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC19:03
kergothyep, 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 in19:04
kergothand 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 intention19:04
kergothother distro decisions include packaging format, systemd vs sysvinit, etc19:04
jrunkergoth: and how come Gentoo is not supported!19:05
kergothsplit-usr specifically does exist for us, i don't recall the exact name of the distro feature, though19:05
kergothexactly 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
frayWay 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
kergothyeah. and of course packageconfig often sets defaults based on the distro features19:06
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto19:06
kergoththings 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 rare19:07
jrunwhich means DISTRO_FEATURES and PACKAGE_CONFIG have intersections, right?19:07
frayexactly.. 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
kergoththis 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 requirements19:08
kergoththe downside of course is the rather steep learning curve, but it's a tradeoff19:08
frayyup, 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  PACKAGECONFIG19:10
jrunso 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 on19: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 happened19:10
frayroughly speaking VIDEO_CARD would be.. but CFLAGS is influended by the 'MACHINE', but it's really distro..19:11
jrunit's fuzzy in gentoo too, i'm just used to it19:11
frayagain, fuzzy..19:11
kergothyeah, 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
fraymachine (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 work19:12
frayit 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 machine19:13
fraydefault 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
frayi.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.a7219:14
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC19:16
jrunwhat tools are the for listing stuff? listing other people's meta layers, listing available DISTRO_FEATURES, PACKAGECONFIG etc?19:17
jrunis it all in bitbake?19:17
jrunactually 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 me19:19
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto19: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
jrunwhere 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 #yocto19:28
PaowZhi 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 #yocto19:36
frayjrun 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 IRC19:49
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC19:49
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC19:51
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto19:53
*** berton <berton!~berton@> has quit IRC19:54
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC19:58
*** vineela <vineela!vtummala@nat/intel/x-ehyfqifbnpkpcvjp> has quit IRC20:01
kergothfray: i think angstrom did some work on the generic vs specific tuning stuff for its feeds to maximize sharing20:01
kergothjrun: 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 packageconfig20:02
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto20:03
*** yann <yann!~yann@> has quit IRC20:05
*** yann <yann!~yann@> has joined #yocto20:06
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC20:13
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto20: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 IRC20:17
RobertBerger@fray: I did benchmarks on cortex-a53 vs. armv8-hf (which is more generic) and absolutely no difference in the benchmarks20:17
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto20:17
RobertBerger@fray: hopefully I will soon also have something for the cortex-a7220: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 benchmarks20:19
frayI honestly don't expect any difference between a53 and armv820:19
RobertBergerI can't see any on CPU benchmarks.20:20
frayIt'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 place20:20
RobertBergerAlso no difference between cortex-a9-hf and armv7-hf20:20
frayI've never looked into that..20:21
RobertBergerI will try the a72 also with armv8-hf-crc-crypto and see if that makes any difference20:21
frayI need generic.. code needs run on both a72 and a53..  so the CRC-CRYPTO can be disabled for all I care20:26
RobertBergerThen you want only armv8-hf I guess20:34
RobertBergerMaybe something here? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/arm/arch-armv8a.inc20:35
fraybut scheduling the code for the out of order unit on the a72 does provide wins20:35
RobertBergerI am very curious - in my case it's 2 different boards.20:35
frayand for my use, I don't care about any other variants, other then a53 adn a72..20:35
frayI'm supporting many different boards, but only two arm cores (for 64-bit)20:36
frayif the end user wants further optimization (like crc-crypto) then they would enable that themselves20:36
zandreyfray, 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
RobertBergerIf you want big-little also this maybe: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/tune-cortexa72-cortexa53.inc20:36
fraythis is the one I'm running20:37
zandreythis is detailed in Cortex-A53 MPCore TRM, where the description of ISAR[0-5] is provided20:37
frayzandrey in my case, these are "standard" implementations from ARM.. so simple ennough20:37
RobertBerger@zandrey: It's all just marketing for hardware nerds - Show me the benchmarks ;)20:37
zandreyfray: 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 RTL20:38
frayfrom 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
zandreyRobertBerger: 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-case20:39
zandreywhat 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 taken20:41
*** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC20:41
zandreythis is - not considering -hf or course20:42
RobertBergerSo why we optimize and fine tune out compiler tunes with YP/OE? Just to burn more electricity while building?20:42
zandreyRobertBerger: nope, that is not quite a complete picture. i still would expect the best performance from the code that toolchain produces.20:43
RobertBergerWell in theory, since benchmarks don't show that.20:43
zandreyi'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
frayI 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
RobertBergerReally I expected to see some difference - a small one. But NOPE. So please feed me with test cases and benchmarks.20:45
frayso 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
frayfor the remaining 10% who are trying to build more generic software, we have easy ways to adapt20:45
RobertBergerI 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
frayit'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
kergothminor 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 reuse20:48
kergothand often you want a from scratch build regularly anyway20:49
frayagreed, this is a 'minor' use-case20:49
zandreyagreed, i can live with that too :P20:49
RobertBergerLet 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
RobertBergerIf you pick a different compiler tune it's not a minor change - it's totally different20:52
kergoththat sort of thing might be of interest20:53
RobertBergerHehe - apparently I like that ;)20:54
kergothangstrom has long prioritized more generic tuning to increase reuse of packages in their maintained package feeds20:55
*** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto20:56
RobertBergerI currently use this for arm32: TUNE_FEATURES        = "arm armv7a vfp thumb callconvention-hard"20:56
RobertBergerTARGET_FPU           = "hard"20:56
zandreykergoth: i like the signature of the statement in that file :)20:56
RobertBergerhehe - even Khem agrees ;)20:56
kergothit would be nice to more easily control the behavior at the very least20:58
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC20:58
zandreyRobertBerger: this is an interesting bug which looks at the crc32 improvements: https://bugs.chromium.org/p/chromium/issues/detail?id=70971620:59
fraywe'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.conf20:59
zandreywith 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 #yocto21:00
zandreythe claim there was - up to 10x, so you might reproduce this test case21:01
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC21:02
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC21:07
*** MiskaX <MiskaX!ykf0erb5kw@rankki.sonarnerd.net> has quit IRC21:07
*** stew-dw <stew-dw!~stew-dw@2607:fb90:a22e:3676:f2b7:9997:754d:360d> has quit IRC21:09
zandreyRobertBerger: and this one - is for SHA, which you would get *only* with -crypto: https://github.com/minio/sha256-simd21:09
zandreydunno 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 #yocto21:12
*** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC21:13
*** MiskaX <MiskaX!trop0y73ze@rankki.sonarnerd.net> has joined #yocto21:13
*** stew-dw <stew-dw!~stew-dw@2607:fb90:2ae:1057:177:6615:75b3:e1d7> has joined #yocto21:14
RobertBerger@zandry - in x86 assembly on arm?21:18
RobertBergerAnd now to something completely different21:19
zandreyRobertBerger: nope, this one - it "pure" aarch64 https://github.com/minio/sha256-simd/blob/master/sha256block_arm64.s21:20
RobertBergeris nativesdk-packagegroup-sdk-host used both by the extensible SDK and the "classic" one?21:20
RobertBergerit looks like it's only used by the "classic" sdk21:21
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto21:21
RobertBergerI 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: 29: gcc: not found21:23
RobertBergerResy (Reliable Embedded Systems Reference Distro) Extensible SDK installer version 3.1.221:23
RobertBergerERROR: the SDK requires the following missing utilities, please install them:  diffstat gcc g++21:23
RobertBergerI need to a gcc and g++ to install an SDK???21:23
RobertBergerit looks like nativesdk-packagegroup-sdk-host is used by both extensible SDK and the "classic" one via the populate_sdk_base.bbclass21:29
*** jatedev <jatedev!~jatedev@c-69-254-209-160.hsd1.fl.comcast.net> has quit IRC21:46
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC22:12
*** angery <angery!~dave@d66-183-215-121.bchsia.telus.net> has joined #yocto22:19
*** jatedev <jatedev!~jatedev@c-69-254-209-160.hsd1.fl.comcast.net> has joined #yocto22:22
frayOdd, setting XZ_DEFAULTS didn't seem to change the way 'xz' worked.. it still rand out of memory after gobbling > 10%22:24
RPfray: I think you have to lower the compression options to do that22:25
frayxz man page says that: XZ_DEFAULTS = "--memlimit=10% --threads=8" "should" work22:28
frayxz -f -k -c -9 --memlimit=10% --threads=8 --check=crc32 <file> > <output>22:28
fraycurrently skimming the man page to figure this out22:31
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC22:32
fraylooks 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 #yocto22:35
fray(looking at Zeus, but it looks like a bug in populate_sdk_base)22:36
frayahh looks like master has a fix for it...22:37
frayFixed in Poky commit: 27ff81bfd880280607c79dce2f724c8bfafce02d  Marh 20 2020.. so newer then eus22:38
fray'er.. Zeus.. at least i know what I need to fix it22:38
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto22:39
*** armpit <armpit!~armpit@2601:202:4180:a5c0:38b0:6e28:1342:89b5> has quit IRC23:21
*** armpit <armpit!~armpit@2601:202:4180:a5c0:812e:2d2f:a669:186f> has joined #yocto23:24
*** dev1990 <dev1990!~dev@dynamic-78-8-114-156.ssp.dialog.net.pl> has quit IRC23:28

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!