| *** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has joined #yocto | 00:01 | |
| *** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has quit IRC | 00:01 | |
| *** paulbarker <paulbarker!sid269702@gateway/web/irccloud.com/x-refzyzumcmntklzq> has joined #yocto | 00:01 | |
| *** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has joined #yocto | 00:03 | |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has quit IRC | 00:09 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto | 00:11 | |
| *** ernstp <ernstp!sid168075@gateway/web/irccloud.com/x-gehttxdsavgjhgiq> has quit IRC | 00:13 | |
| *** ernstp <ernstp!sid168075@gateway/web/irccloud.com/x-iajsiaqnzepohyqz> has joined #yocto | 00:16 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 00:17 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto | 00:19 | |
| robbawebba | hmm this article seems to be helpful (although what I'm doing is definitely feeling hacky): https://wiki.yoctoproject.org/wiki/TipsAndTricks/Running_YP_binaries_on_Ubuntu_and_Vice_Versa | 00:20 |
|---|---|---|
| *** vineela <vineela!vtummala@nat/intel/x-rlfbbtkcktmijclm> has quit IRC | 00:21 | |
| zeddii | khem: I have a change for that here. will send with my queue tomorrow. | 00:25 |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has quit IRC | 00:27 | |
| khem | thanks zeddii | 00:27 |
| khem | robbawebba: that article is right, use patchelf to insert the right linker path. usually we distribute nativesdk binaries and they also rewrite ldso path when SDK is installed, this of course happens behind the scene | 00:29 |
| khem | RP: do we still have performance issues on mips ? | 00:34 |
| robbawebba | khem: thanks for the support once again! It feels wrong trying to skirt around uninative which provides a lot of benefits to the build system and sdk, but I guess this is necessary if I want to avoid distributing the full SDK for a single application. | 00:34 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 00:35 | |
| khem | robbawebba: sure, you will have to create a post processing step anyway so add patchelf step in that | 00:36 |
| *** geissonator <geissonator!~geissonat@129.41.86.5> has joined #yocto | 00:37 | |
| robbawebba | khme: thanks! Another question that came to mind after finding this patch (https://www.openembedded.org/pipermail/openembedded-core/2018-April/268457.html): is it possible to override or remove the --dynamic-linker flag for a specific recipe? or is this less practical or ineffective compared to the patchelf approach? | 00:39 |
| *** vineela <vineela!vtummala@nat/intel/x-ivnouytilwrzplcz> has joined #yocto | 01:04 | |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 01:11 | |
| *** vineela <vineela!vtummala@nat/intel/x-ivnouytilwrzplcz> has quit IRC | 01:18 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:36 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:47 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:48 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 02:27 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:35 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:38 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto | 02:41 | |
| khem | robbawebba: I think for your case you are better of not using uninative | 02:42 |
| *** gregw <gregw!3a604a9b@155.74.96.58.static.exetel.com.au> has joined #yocto | 02:51 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:52 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:53 | |
| gregw | I'm packaging code with its own complex build-system that requires the `fakeroot` command. Is there a way to make that available as a host-tool during build commands? I'm really having trouble searching for a solution (besides "don't"). | 03:01 |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 03:03 | |
| khem | gregw: you have explore using pseudo which is provided by yocto project to do privilige management like fakeroot | 03:07 |
| khem | https://www.yoctoproject.org/software-item/pseudo/ | 03:07 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:08 | |
| khem | also see this https://git.congatec.com/yocto/poky/commit/29d5edffb051df34317e588335c6a454bbb42765 | 03:09 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 03:11 | |
| *** gregw <gregw!3a604a9b@155.74.96.58.static.exetel.com.au> has quit IRC | 03:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:14 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 03:15 | |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 03:26 | |
| *** gregw <gregw!3a604a9b@155.74.96.58.static.exetel.com.au> has joined #yocto | 03:26 | |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 03:27 | |
| gregw | thanks khem - I'm aware that pseudo is the preferred way to acheive this - the issue is that the build system of the package calls `fakeroot` by name deep in its bowels. Really i just need to satisfy the builder without having to dismantle the build system. | 03:29 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:30 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 03:31 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 03:34 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:37 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 03:45 | |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC | 04:05 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 04:20 | |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 04:23 | |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 04:23 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto | 04:27 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-bhseyojlgvdeelvo> has quit IRC | 04:27 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC | 04:53 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto | 04:53 | |
| *** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has quit IRC | 05:01 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-191.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 05:03 | |
| *** gregw <gregw!3a604a9b@155.74.96.58.static.exetel.com.au> has quit IRC | 05:07 | |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto | 05:15 | |
| *** gtristan <gtristan!~tristanva@175.211.69.194> has quit IRC | 05:17 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 05:27 | |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 05:29 | |
| *** camus1 is now known as kaspter | 05:29 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 05:33 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 05:35 | |
| *** camus1 <camus1!~Instantbi@180.168.140.162> has joined #yocto | 05:37 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 05:38 | |
| *** camus1 is now known as kaspter | 05:38 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 05:41 | |
| *** ada91 <ada91!cb7e0071@203.126.0.113> has joined #yocto | 05:43 | |
| *** ada100 <ada100!cb7e0071@203.126.0.113> has joined #yocto | 05:44 | |
| *** jobroe <jobroe!~manjaro-u@p579eb81b.dip0.t-ipconnect.de> has joined #yocto | 05:46 | |
| *** minimaxw1ll <minimaxw1ll!~minimaxwe@204.ip-51-254-215.eu> has joined #yocto | 05:46 | |
| *** minimaxwell <minimaxwell!~minimaxwe@204.ip-51-254-215.eu> has quit IRC | 05:47 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-ezfofhazkwvedzav> has joined #yocto | 06:00 | |
| *** ibinderwolf <ibinderwolf!~quassel@etrn.topcontrol.it> has quit IRC | 06:08 | |
| *** ibinderwolf <ibinderwolf!~quassel@etrn.topcontrol.it> has joined #yocto | 06:10 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 06:17 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 06:18 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:18 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:19 | |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has quit IRC | 06:38 | |
| *** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has quit IRC | 06:38 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpe-188-129-99-153.dynamic.amis.hr> has quit IRC | 06:38 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 06:38 | |
| *** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-ggsbtxigcznvuxkg> has quit IRC | 06:38 | |
| *** junland <junland!~junland@142.93.201.46> has quit IRC | 06:38 | |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 06:38 | |
| *** denix <denix!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has quit IRC | 06:38 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC | 06:38 | |
| *** stew-dw <stew-dw!~stew-dw@172.58.140.35> has quit IRC | 06:38 | |
| *** laurittr <laurittr!~laurittr@indie.ed.ntnu.no> has quit IRC | 06:38 | |
| *** woky <woky!~woky@li1651-31.members.linode.com> has quit IRC | 06:38 | |
| *** dkc <dkc!~dkc@55.ip-158-69-215.net> has quit IRC | 06:38 | |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has quit IRC | 06:38 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 06:38 | |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto | 06:43 | |
| *** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has joined #yocto | 06:43 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpe-188-129-99-153.dynamic.amis.hr> has joined #yocto | 06:43 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 06:43 | |
| *** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-ggsbtxigcznvuxkg> has joined #yocto | 06:43 | |
| *** junland <junland!~junland@142.93.201.46> has joined #yocto | 06:43 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 06:43 | |
| *** denix <denix!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has joined #yocto | 06:43 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto | 06:43 | |
| *** stew-dw <stew-dw!~stew-dw@172.58.140.35> has joined #yocto | 06:43 | |
| *** laurittr <laurittr!~laurittr@indie.ed.ntnu.no> has joined #yocto | 06:43 | |
| *** woky <woky!~woky@li1651-31.members.linode.com> has joined #yocto | 06:43 | |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has joined #yocto | 06:43 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 06:43 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpe-188-129-99-153.dynamic.amis.hr> has quit IRC | 06:49 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpe-188-129-99-153.dynamic.amis.hr> has joined #yocto | 06:50 | |
| ada100 | Are there any documents about how to use meta-virtualization? | 06:54 |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 06:54 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 06:56 | |
| *** dkc <dkc!~dkc@55.ip-158-69-215.net> has joined #yocto | 06:59 | |
| LetoThe2nd | ada100: other than https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/README probably not. | 07:00 |
| LetoThe2nd | ada100: what is not clear? | 07:01 |
| *** creich <creich!~creich@p200300f6af272610000000000000039b.dip0.t-ipconnect.de> has quit IRC | 07:03 | |
| ada100 | LetoThe2nd Yeah, It's not very clear. I have read this readme before. | 07:04 |
| LetoThe2nd | ada100: but *what* ist not clear? | 07:05 |
| LetoThe2nd | its just a layer like any other AFAICS | 07:05 |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 07:05 | |
| *** creich <creich!~creich@p200300f6af272610000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 07:05 | |
| *** sajjad__ <sajjad__!~xtron@103.113.103.91> has joined #yocto | 07:06 | |
| ada100 | LetoThe2nd It's hard to have a clear dependencis. I want to install docker. I built it and found it depend on containerd. And containerd require cni | 07:07 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 07:08 | |
| LetoThe2nd | um, so what? | 07:10 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:10 | |
| LetoThe2nd | from a first peek, the docker dependencies are defined here: https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-containers/docker/docker.inc | 07:10 |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto | 07:13 | |
| LetoThe2nd | plus, the layer dependencies are also properly set up: https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/conf/layer.conf#n33 | 07:14 |
| ada100 | LetoThe2nd I am a new to it. So is it enough to specify IMAGE_INSTALL_append = " docker" and DISTRO_FEATURES_append = " systemd virtualization " in local.conf? And all of the dependencies will be install automaticlly? | 07:15 |
| LetoThe2nd | hum. close. | 07:15 |
| ada100 | LetoThe2nd Got it. I'll have a try. Thank a lot | 07:16 |
| LetoThe2nd | ada100: do yourself a favor, watch this: https://youtu.be/nqHylLP2NmA and this https://youtu.be/o-8g0TPVVGg and then act accordingly. e.g. create a layer, a custom image, and a custom distro | 07:17 |
| LetoThe2nd | ada100: in a nutshell: the build time dependencies will be built automatically, the runtime dependencies will be installed automatically. but do *NOT* do extensive modifications in your local.conf. | 07:20 |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 07:20 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 07:21 | |
| ada100 | LetoThe2nd Another question. After building this image and runqemu with it, to start docker service with systemctl. Any is any other configuration needed? | 07:21 |
| ada100 | LetoThe2nd I followed this document https://wiki.yoctoproject.org/wiki/TipsAndTricks/DockerOnImage to build docker. | 07:22 |
| LetoThe2nd | ada100: it should be automatically started: https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-containers/docker/docker.inc#n53 | 07:23 |
| LetoThe2nd | ada100: just like the wiki page you linked says. | 07:23 |
| LetoThe2nd | ada100: and while the page says to work with local.conf, well... its only the half truth. its enough to make it work, but certainly not the way to go if you actually want to use and maintain whatever you built with it. | 07:25 |
| LetoThe2nd | ada100: so seriously, getting a grasp of a custom layer/image/distro is absolutely mandatory. | 07:25 |
| ada100 | letothe2nd: Yeah, a lot long way to go | 07:27 |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC | 07:27 | |
| LetoThe2nd | ada100: so i strongly suggest to get an understanding of the basics, before playing with docker :) | 07:29 |
| *** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto | 07:31 | |
| ada100 | LetoThe2nd Sharpen the knife and chop wood. Thanks for your advice.<3 | 07:34 |
| *** sajjad__ <sajjad__!~xtron@103.113.103.91> has quit IRC | 07:34 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 07:39 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 07:43 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 07:44 | |
| *** risca <risca!~quassel@212.85.71.156> has quit IRC | 07:50 | |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC | 07:50 | |
| *** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has quit IRC | 07:54 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 08:01 | |
| RP | khem: yes, mips issues basically remain :( | 08:07 |
| *** Brian90 <Brian90!3eca076f@111.7.202.62.static.wline.lns.sme.cust.swisscom.ch> has joined #yocto | 08:17 | |
| *** camus1 <camus1!~Instantbi@180.168.140.162> has joined #yocto | 08:20 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 08:21 | |
| *** camus1 is now known as kaspter | 08:21 | |
| *** risca <risca!~quassel@212.85.71.156> has joined #yocto | 08:22 | |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 08:22 | |
| Brian90 | Hi i have with yocto zeus the following problem: I want to integrate my self builded qt 5 (for Arm) as a recipe but yocto have the problem that the sdk for qt5 have x86 (like qmake)... How can i solve it??? | 08:22 |
| LetoThe2nd | Brian90: if your recipe sticks to the usual qt practises, this should all work automagically. | 08:28 |
| *** xtron1 <xtron1!~xtron@110.93.212.98> has quit IRC | 08:31 | |
| *** Sibert <Sibert!b98ee38f@185.142.227.143> has joined #yocto | 08:32 | |
| Sibert | Hello everyone. I'm using yocto from a docker container. I would like to use the devshell for some things, but I cannot scroll/go up in the devshell. Does anyone if it's possible and ifso, how? | 08:33 |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-ezfofhazkwvedzav> has quit IRC | 08:46 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-gpkkqkgvqemhincb> has joined #yocto | 08:47 | |
| *** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto | 08:58 | |
| *** sstiller <sstiller!~sstiller@p200300f07f117f01f0e61e69cba0238b.dip0.t-ipconnect.de> has joined #yocto | 09:00 | |
| *** RichterDirk[m] <RichterDirk[m]!rrdsofting@gateway/shell/matrix.org/x-rgqykzjlixooyogo> has quit IRC | 09:03 | |
| *** xtron1 <xtron1!~xtron@110.93.212.98> has quit IRC | 09:03 | |
| *** xtron1 <xtron1!~xtron@103.113.103.91> has joined #yocto | 09:05 | |
| *** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 09:11 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 09:12 | |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has quit IRC | 09:14 | |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has joined #yocto | 09:15 | |
| Sibert | Hello everyone. I'm using yocto from a docker container. I would like to use the devshell for some things, but I cannot scroll/go up in the devshell. Does anyone if it's possible and ifso, how? | 09:16 |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has quit IRC | 09:17 | |
| *** samvlewis <samvlewis!~samvlewis@45.32.247.239> has joined #yocto | 09:17 | |
| LetoThe2nd | Sibert: it probably depends a bit on the exact environment, where the shell is executed. | 09:18 |
| LetoThe2nd | if you execute it inside a tmux session or such it doesn't help? | 09:20 |
| Sibert | I don't know what tmux is, I'll have to look into it | 09:25 |
| Sibert | I'm currently using a ubuntu 18.04 VM, that runs a docker with docker | 09:25 |
| *** florian_kc is now known as florian | 09:25 | |
| Sibert | Well I'll be damned, thanks LetoThe2nd | 09:27 |
| Sibert | Googling tmux helped me achieve what I needed | 09:27 |
| Sibert | Thnaks | 09:27 |
| *** xtron1 <xtron1!~xtron@103.113.103.91> has quit IRC | 09:28 | |
| LetoThe2nd | no need to be damned, but screen/tmux are core parts of each linux developers toolbox :) | 09:29 |
| *** xtron <xtron!~xtron@103.113.103.91> has joined #yocto | 09:30 | |
| Sibert | Yeah I know screen | 09:31 |
| Sibert | but those commands didn't seem to work | 09:31 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 09:33 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 09:44 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 09:44 | |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC | 09:46 | |
| *** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto | 09:57 | |
| *** xtron <xtron!~xtron@103.113.103.91> has quit IRC | 09:59 | |
| *** goliath <goliath!~goliath@91.141.3.173.wireless.dyn.drei.com> has joined #yocto | 10:12 | |
| fbre | Hi! The kernel does not start. What does this error happen?: | 10:22 |
| fbre | failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC | 10:23 |
| fbre | base fdt does did not have a /__symbols__ node | 10:23 |
| fbre | make sure you've compiled with -@ | 10:23 |
| fbre | It happened as I changed via bitbake virtual/kernel -c menuconfig from overlayfs (M) to (*) which means not as kernel module but compiled in | 10:28 |
| *** ada100 <ada100!cb7e0071@203.126.0.113> has quit IRC | 10:40 | |
| *** luneff <luneff!~yury@80.72.17.178> has joined #yocto | 10:49 | |
| *** goliath <goliath!~goliath@91.141.3.173.wireless.dyn.drei.com> has quit IRC | 10:49 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 11:00 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 11:01 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 11:03 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 11:15 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ghbipnjxlceqwboc> has joined #yocto | 11:16 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 11:19 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:38 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 11:40 | |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC | 11:43 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 11:44 | |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto | 11:51 | |
| *** Sibert <Sibert!b98ee38f@185.142.227.143> has quit IRC | 11:53 | |
| *** jobroe <jobroe!~manjaro-u@p579eb81b.dip0.t-ipconnect.de> has quit IRC | 11:56 | |
| *** goliath <goliath!~goliath@77.119.128.36.wireless.dyn.drei.com> has joined #yocto | 12:01 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.30> has quit IRC | 12:04 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has joined #yocto | 12:04 | |
| *** florian_kc is now known as florian | 12:05 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:07 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 12:07 | |
| *** sh00p <sh00p!~sh00p@h-38-105.A498.priv.bahnhof.se> has quit IRC | 12:13 | |
| *** laurittr <laurittr!~laurittr@indie.ed.ntnu.no> has quit IRC | 12:18 | |
| *** laurittr <laurittr!~laurittr@indie.ed.ntnu.no> has joined #yocto | 12:18 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 12:37 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 12:38 | |
| *** gsalazar87 <gsalazar87!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 12:38 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 12:42 | |
| *** gsalazar87 is now known as gsalazar | 12:42 | |
| *** Brian90 <Brian90!3eca076f@111.7.202.62.static.wline.lns.sme.cust.swisscom.ch> has quit IRC | 12:51 | |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 12:52 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 12:56 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 12:56 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:13 | |
| *** goliath <goliath!~goliath@77.119.128.36.wireless.dyn.drei.com> has quit IRC | 13:14 | |
| *** sstiller <sstiller!~sstiller@p200300f07f117f01f0e61e69cba0238b.dip0.t-ipconnect.de> has quit IRC | 13:17 | |
| *** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has joined #yocto | 13:21 | |
| *** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto | 13:25 | |
| *** vineela <vineela!~vtummala@134.134.137.77> has quit IRC | 13:29 | |
| kanavin_home | RP: I see some of the version updates are making their way from other people - I guess sunday evening would be a good moment to rebase and send my patchset? | 13:30 |
| kanavin_home | M3 deadlines are drawing closer | 13:30 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 13:32 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 13:33 | |
| zeddii | khem: I just did a clean build of qemumips with what is in master currently, and the virtio warning isn't showing. If you can send me your layer configuration later today, I'll double check before sending my series. | 13:33 |
| *** luneff <luneff!~yury@80.72.17.178> has quit IRC | 13:39 | |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC | 13:41 | |
| *** awe003 <awe003!~awe00@unaffiliated/awe00> has joined #yocto | 13:42 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.98.213> has quit IRC | 13:47 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.98.213> has joined #yocto | 13:48 | |
| *** clement <clement!~clement@51.158.149.110> has quit IRC | 13:52 | |
| RP | kanavin_home: probably, yes. We have seen some bits coming through at least | 13:52 |
| RP | zeddii: I merged the 5.8 bits since they seemed to build cleanly and it gives more exposure | 13:54 |
| zeddii | yah. I'll send the default changing patches soon, just so they are out there. I havent' seen any issues for a couple of weeks now | 13:54 |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has quit IRC | 13:55 | |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has joined #yocto | 13:55 | |
| zeddii | I expect I'll have some config tweaks to do, since the enhanced audit is more capabable. but the default configs are all clean (I made sure of that). | 13:55 |
| RP | zeddii: makes sense. we can run the patches through over the weekend and see what state things are in | 13:55 |
| *** clement <clement!~clement@51.158.149.110> has joined #yocto | 13:59 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 14:00 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 14:01 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto | 14:11 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 14:14 | |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto | 14:15 | |
| *** awe003 <awe003!~awe00@unaffiliated/awe00> has quit IRC | 14:17 | |
| *** xtron1 <xtron1!~xtron@110.93.212.98> has quit IRC | 14:20 | |
| RP | JPEW: Are you ok with my fix in master-next of mingw? | 14:27 |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC | 14:42 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 14:47 | |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto | 14:50 | |
| kanavin_home | This patch series add a new flag "-fparallel-jobs=" to control if the compiler should try to compile the current file in parallel. | 14:52 |
| kanavin_home | https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552346.html | 14:52 |
| kanavin_home | not sure if oe-core has many recipes which would benefit, but definitely something to consider | 14:52 |
| kanavin_home | I guess particularly very large (e.g. generated) c++ files would benefit | 14:52 |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 14:54 | |
| RP | kanavin_home: right, sounds fairly specialist for our general use case but interesting | 14:55 |
| *** creich <creich!~creich@p200300f6af272610000000000000039b.dip0.t-ipconnect.de> has quit IRC | 15:02 | |
| kanavin_home | RP: you wouldn't believe abuses of c++ I see internally :) | 15:03 |
| *** creich <creich!~creich@p200300f6af272610000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 15:03 | |
| kanavin_home | it is considered okay to generate a c++ file so large that gcc takes 10 minutes to process it | 15:04 |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has quit IRC | 15:07 | |
| kanavin_home | RP: btw, Konrad (the linter guy) sits next to me in the daimler office ;) | 15:10 |
| kanavin_home | (just reading the minutes from yesterday) | 15:10 |
| kanavin_home | we all applied for travelling to Dublin, but alas, wont happen this year | 15:11 |
| RP | kanavin_home: I would believe them but it is sad :/ | 15:11 |
| RP | kanavin_home: it is a shame about Dublin, could have been a good 10 year celebration | 15:11 |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC | 15:14 | |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC | 15:20 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 15:21 | |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 15:23 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:27 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto | 15:31 | |
| kanavin_home | RP: is anything virtual planned? | 15:31 |
| RP | kanavin_home: There will be a two day YP summit/YPDD sometime around the conference | 15:32 |
| *** rcoote <rcoote!~rcoote@5.146.199.158> has quit IRC | 15:36 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 15:39 | |
| *** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has quit IRC | 15:42 | |
| *** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has joined #yocto | 15:43 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 15:43 | |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-zvpnycluhsoafehk> has joined #yocto | 15:46 | |
| dl9pf | JPEW: RP: fyi compare these 2: | 15:58 |
| dl9pf | prserv: 2020-08-21 15:46:57,783 poiapp-git-r0 corei7-64 fad44da993bf97cea3e4899f1b2a0a2e1bb92652a3d86c61ef1510a65e447623 | 15:59 |
| dl9pf | hashserv: Adding taskhash fad44da993bf97cea3e4899f1b2a0a2e1bb92652a3d86c61ef1510a65e447623 with unihash fad44da993bf97cea3e4899f1b2a0a2e1bb92652a3d86c61ef1510a65e447623 | 15:59 |
| dl9pf | so in my understanding, we would want a specific PR value tied to the unihash then. no ? | 16:00 |
| dl9pf | same unihash should get same pr from prserv ? | 16:00 |
| RP | dl9pf: It depends on the mode of PRServ you have enabled. There are cases where you always want PR to increment | 16:05 |
| RP | dl9pf: fray is working on some changes here which should help a lot (and separate out PR policy from hashequiv) | 16:05 |
| RP | dl9pf: the differing policies are one reason I do not want to tie PR serv and hash equiv tables | 16:06 |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has joined #yocto | 16:10 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-191.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 16:23 | |
| RP | dl9pf: think of it this way - you could want a package feed where PR always increases, so if that hash was replaced and PR bumped, then something reverted, you'd want PR to increase again so on target you got the newer change | 16:24 |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-gpkkqkgvqemhincb> has quit IRC | 16:29 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 16:33 | |
| *** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 16:35 | |
| *** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC | 16:38 | |
| RP | JPEW: talking with fray, I think it may be an idea to keep a client side outhash cache inside unihash.dat | 16:39 |
| RP | JPEW: it does mean we'd need to server to tell us the outhash when we request a unihash though | 16:39 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:3543:531d:382f:ed2a> has quit IRC | 16:41 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:ccb4:20b:5f9e:68b5> has joined #yocto | 16:54 | |
| *** robbawebba <robbawebba!~rob@12.206.203.186> has joined #yocto | 16:55 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 16:58 | |
| *** robbawebba <robbawebba!~rob@12.206.203.186> has left #yocto | 16:59 | |
| *** robbawebba <robbawebba!~rob@12.206.203.186> has joined #yocto | 16:59 | |
| kergoth | hmm, on dunfell hitting TypeError: can't pickle _thread.RLock objects in runCommand connection.send(). guessing that was probably fixed in master | 17:01 |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 17:02 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 17:04 | |
| JPEW | RP: meta-mingw fix seem sfine | 17:18 |
| JPEW | RP: Hmm; IIRC requesting the initial unihash is one of the slowest operations (its why we have the streaming mode); doubling the data may not help | 17:23 |
| JPEW | Unless the idea is that the client can deduce it's own unihashes without talking to the server? | 17:24 |
| khem | zeddii: my setup is https://github.com/yoedistro/yoe-distro | 17:25 |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto | 17:44 | |
| *** rcoote <rcoote!~rcoote@5.146.198.218> has joined #yocto | 17:53 | |
| zeddii | cool. thanks khem, I'll dig into it! | 17:56 |
| *** rcoote <rcoote!~rcoote@5.146.198.218> has quit IRC | 18:03 | |
| fray | JPEW the use-case is: user created an eSDK.. user modifies some setting.. user runs a build.. We don't want things that 'didn't actually change' to change, because there is not hashequiv 'database'.. So if we have the data stored in the unihash.dat then we don't need a 'server' | 18:05 |
| fray | (user runs a build FROM WITHIN THE eSDK) | 18:05 |
| *** osullivan99 <osullivan99!~osullivan@host-82-135-4-50.static.customer.m-online.net> has quit IRC | 18:06 | |
| JPEW | fray: How does the outhash help with that? | 18:06 |
| fray | RP was saying that today (with no changes made by the user) the unihash.dat is used without the database.. | 18:08 |
| fray | since the database is "big", he was saying he didn't want the database in the eSDK.. but if the data is there, we can protect the eSDK user from having to create new things if the unihash matches the prior build (what was cached in the unihash.dat) | 18:08 |
| fray | We have a similar problem with the PR service data BTW. | 18:09 |
| JPEW | Well, like I said it's going to double the about of data transfered at whats already the largest bottleneck.... is there a way we can only request that data when we are build the eSDK instead of all the time? | 18:11 |
| fray | I don't understand enough about what is happening, but RP just said can't we store on each entry the "outhash".. | 18:12 |
| fray | we're not going to computer it or anything, just store it when we have it | 18:12 |
| fray | with the other data already stored per entry, I'm not sure how much large it makes things? 1/4? | 18:13 |
| JPEW | fray: Probably about that; I don't *think* the size of unihashes.dat is what RP is concerned about, but rather the hashequiv SQL database (which can be GB's) | 18:15 |
| JPEW | He should correct me if that's wrong | 18:16 |
| fray | correct.. | 18:16 |
| fray | which is why he was saying do NOT use the datbase, but use the bb_unihashes.dat file | 18:16 |
| fray | but it doesn't have the outhash in it | 18:16 |
| *** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has joined #yocto | 18:17 | |
| JPEW | Right, I think putting the outhash there is fine, but we already try to make the communication with the hashequiv server as fast as possible when bitbake is initializing the runqueue because it's the biggest bottle neck of the whole process | 18:17 |
| JPEW | There is a very lightweight protocol where the client sends over a taskhash as a single line of text and the server responds with the unihash | 18:18 |
| fray | the bb_unihashes.dat is all we were talking aobut.. my solution was to download the database that matched teh user's sstate-cache at the start of the build.. it's not lightweight but would work | 18:18 |
| JPEW | Right thats fine. The server has an API to get the full details about a taskhash from the server (client.get_taskhash()) | 18:19 |
| JPEW | As long as we don't do it during the runqueue initialization, thats fine | 18:19 |
| JPEW | fray: The reason that I point this out is that currently the way bb_unihashes.dat is populate is using the fast mechanism during runqueue initialization, so you'll needs some way to go back and query the outhash for each taskhash you care about at a later point | 18:21 |
| fray | like I said, I was focusing on the DB, cause I don't know how this works -- nor do I intend to hack on initilization sequences.. | 18:22 |
| fray | I understand what RP wants, but I have no (current) way to do it myself.. | 18:22 |
| JPEW | fray: Hmm, I feel like I'm missing something | 18:23 |
| fray | I distribute an eSDK to my customers. My customers will make changes to the config.. They need to be able to use the optimizations within the hashequivalency to avoid buildings when it's not necessary. So I need 'a hash equivalency database' (note, not an actual database, but the functionality of one) in the eSDK to enable that, unless I am missing something.. | 18:25 |
| fray | RP's response was the database is too big, so instead use the unihash.dat file, and add the missing element to it as a better way to distribute it -- as that .dat file is already distributed as part of the eSDK | 18:26 |
| JPEW | Yes, that all seems reasonable | 18:26 |
| fray | At this time, I have no plans to change the way the unihash.dat works or how the hash equivalency works -- outside of the PR service parts I'm working on now.. | 18:26 |
| fray | I don't have the knowledge or the time to do it in before the end of this development sprint.. | 18:26 |
| fray | so if I copy around a database (ignroing the size) it meets my immediate needs.. but isn't a OE/YP solution to this workflow | 18:27 |
| JPEW | got it | 18:28 |
| JPEW | How are you going to deal with the database after you have it? Are you going to start up a server when the user uses the eSDK? | 18:28 |
| fray | not sure, but most likely we'll shove the database (both hash equiv and pr service) into a directory along side the matching sstate-cache.. then on startup, verify we have the current one download it if we don't.. (or alternatively download a configuration file that points to an external server..) | 18:29 |
| fray | I'm not sure any of that will ACTUALLY work though to be clear | 18:30 |
| JPEW | Sure | 18:30 |
| fray | but the way I look at it, hash equiv DB, PR DB and sstate-cache all three go together, so I need to try to keep them 'aligned'. | 18:31 |
| JPEW | Correct | 18:32 |
| fray | still have the problem of what happens to local data when the user deviates, etc.. I dont have any solutions to this.. | 18:32 |
| fray | I'm hoping on the PR service side, I can supply a lockdown file, and 'add another digit' to the PR.. but that would all custom code.. | 18:32 |
| fray | i.e. we release foo-1.0-r0.1 ... the user modifies something that causes a rebuild and then get r0.1.1 .. we release an update our update becomes r0.2 (or r0.2.0) | 18:33 |
| JPEW | Ya, not sure. There is no "read-only" option for hash equiv (although it's requested a lot), so if your running the server to read the database (which the the only way to do it really...) it will write back changes the user makes | 18:33 |
| JPEW | but perhaps thats not a problem for hash equiv like it is for PR | 18:34 |
| fray | Might have to do something 'similar' to the PR service and have some sort of static file that makes it read only.. but then again, maybe it's not REALLY a problem | 18:34 |
| fray | for PR, I can customize the PR auto code to combine the lockdown and (local) service code.. | 18:34 |
| fray | (right now they're mutually exclusive) | 18:34 |
| JPEW | Ya, I suspect it's not really a problem since hash equiv is supposed to be more of a optimization | 18:34 |
| fray | yes.. and the sstate-cache we're shipping to customers isn't months worth of development either.. it'll be "one build".. so the database size (starting) is significantly smaller.. | 18:35 |
| JPEW | fray: Ya, that approach seems reasonable (for that use case) | 18:36 |
| zeddii | khem: what's the magic to force 5.8 for qemumips in your yoe setup ? is it master-next or something ? I'm only seeing the 5.4 bits in my clone of master. | 18:39 |
| JPEW | fray: FWIW, I've also intended for hash equiv servers to be hierarchical where one server could have an "upstream" server where it would query/push equivalencies; in that case you could always run a local server and the solution would look very similar to what you are planning | 18:42 |
| fray | that was the orgiinal intent on the PR server as well.. along with rules to dictate which server set which values.. | 18:43 |
| fray | so the return could be 0.0 vs 0... but it wasn't implemented that way in the end | 18:43 |
| JPEW | fray: Ya, it's probably a lot harder with PR having to make sure the number never goes backwards | 18:43 |
| fray | ya, to me that is an action for the local server.. but coordinating could be difficult to say the least | 18:44 |
| JPEW | The data hashequiv is reporting is actually pretty simple | 18:44 |
| JPEW | The tricky part is the SQL qeury that the server uses to find the equivalencies (and all the bitbake code to make it work!) | 18:44 |
| *** rokm <rokm!rokm@freeshell.de> has joined #yocto | 18:45 | |
| rokm | HI, is it possible to use override mechanism with image name ? | 18:46 |
| rokm | PREFERRED_PROVIDER_virtual/my_package_qemu-x86 ?= "my_real_package" | 18:47 |
| rokm | PREFERRED_PROVIDER_virtual/my_package_qemu-x86_core-image-test = "my_test_package" | 18:48 |
| fray | no | 18:49 |
| rokm | So when I build core-image-test for qemu I expect that "my_test_package" will be used and installed on rootfs but it uses "my_real_package" | 18:49 |
| fray | overrides are on a distribution basis. You can chnge variable definitions within a recipe (image being no exception) but PREFERRED_PROVIDER is distribution wide.. | 18:49 |
| rokm | hmm | 18:50 |
| fray | You will need to be explicit in your test image that you want 'my_test_package', not virtual/my_package_qemu | 18:50 |
| rokm | So it is not possible (even with some trick) to switch package depends on image type | 18:51 |
| fray | no. PREFERRED_PROVIDER is a 'build this, not this' behavior.. so you can't build both | 18:52 |
| rokm | I don't want to build both | 18:52 |
| fray | What if you run 'bitbake core-image-one core-image-two core-image-test core-image-something-else" | 18:53 |
| fray | the system doesn't know which package (PREFERED_PROVIDER) for each image.. and the image 'override' wouldn't have meaning since you selected 4 images | 18:53 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 18:54 | |
| rokm | So solution would be to remove PREFERRED_PROVIDER and define packages per image | 18:54 |
| rokm | my_test_package for core-image-test | 18:54 |
| fray | yes.. have a relase image and a test image.. | 18:54 |
| rokm | and mu_teal_package for core-image-real | 18:54 |
| rokm | ok | 18:54 |
| fray | the release image gets one package, the test image gets a different one.. that kind of thing | 18:54 |
| rokm | thx | 18:54 |
| rokm | thanks | 18:54 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 18:56 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 19:01 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 19:01 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 19:03 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpe-188-129-99-153.dynamic.amis.hr> has quit IRC | 19:11 | |
| *** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto | 19:18 | |
| *** creich_ <creich_!~creich@p200300f6af272610000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 19:30 | |
| *** armpit2 <armpit2!~armpit@2601:202:4180:a5c0:ccb4:20b:5f9e:68b5> has joined #yocto | 19:31 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:ccb4:20b:5f9e:68b5> has quit IRC | 19:32 | |
| *** creich <creich!~creich@p200300f6af272610000000000000039b.dip0.t-ipconnect.de> has quit IRC | 19:32 | |
| *** NiksDev2 <NiksDev2!~NiksDev@192.91.101.31> has joined #yocto | 19:32 | |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has quit IRC | 19:33 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 19:34 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 19:35 | |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto | 19:38 | |
| *** adelcast1 <adelcast1!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has joined #yocto | 19:39 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has quit IRC | 19:42 | |
| *** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has quit IRC | 19:42 | |
| *** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has quit IRC | 19:42 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 19:42 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 19:48 | |
| *** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has joined #yocto | 19:49 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 20:07 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 20:21 | |
| *** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 20:22 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 20:28 | |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC | 20:30 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 20:30 | |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 20:33 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 20:35 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 20:37 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 20:59 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 21:02 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 21:05 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 21:05 | |
| *** odda <odda!~quassel@mustbehax.de> has joined #yocto | 21:22 | |
| *** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC | 21:50 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:19 | |
| RP | JPEW: my thinking was that if we have the outhash data in the local cache we can avoid trips to the server under the "new rebuild matches the last one" scenario. We still need to notify the server of the equivalence but if there is no longer a server, things can still show more magic | 22:25 |
| RP | JPEW: but to do that, we need the outhash that matches the unihash | 22:25 |
| RP | JPEW: the eSDK currently neatly uses the unihash.dat file and I'd really prefer we use that than add something new | 22:26 |
| khem | RP: I saw patches from you for nativesdk do they handle the /usr/bin/env sh issue ? | 22:39 |
| RP | khem: yes, they do | 22:42 |
| RP | khem: took me quite a bit of work to find those but its the better fix | 22:42 |
| RP | khem: I just need another round of tests to confirm all is now well | 22:42 |
| khem | RP: something is failing on me on master-next | 22:44 |
| RP | khem: where/how? | 22:45 |
| khem | http://sprunge.us/2BZx0t | 22:45 |
| *** vineela <vineela!~vtummala@134.134.137.77> has quit IRC | 22:46 | |
| khem | recipe-sysroot-native/usr/lib/rpm/rpmdeps: /mnt/b/yoe/master/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6: version `GLIBC_2.32' not found (required by /usr/lib/libgomp.so.1) | 22:46 |
| RP | khem: did you upgrade the system to a new glibc? | 22:47 |
| RP | khem: I suspect you need a newer uninative release | 22:47 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 22:47 | |
| khem | RP: glibc is updates see [2020-08-21T15:41:21-0700] [ALPM] upgraded glibc (2.31-5 -> 2.32-2) | 22:48 |
| RP | khem: we need a new uninative release with 2.32 | 22:49 |
| khem | RP: ok is it available somewhere or need to cook ? | 22:50 |
| RP | halstead: fancy making a new uninative release? :) | 22:50 |
| halstead | RP, Sounds fun. | 22:50 |
| RP | khem: we need to make one | 22:50 |
| RP | halstead: current master is probably as good as anything | 22:50 |
| halstead | RP, That's what I was about to ask. :) | 22:50 |
| khem | ok would be good to have my machine is stalled otherwise for weekend : | 22:51 |
| RP | khem: you can disable uninative worst case | 22:51 |
| khem | yeah that would mean new sstate but I will do that | 22:51 |
| RP | khem: if we have halstead around, we can probably sort a release quite quickly, depends what he's doing as I always struggle to get the tarballs where they should be | 22:53 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 22:54 | |
| halstead | Uninative 2.9.rc1 is building now. | 22:57 |
| RP | halstead: thanks. Not sure what happened to khem! | 22:58 |
| RP | halstead: I need to sleep, if you could drop khem an email pointing at the uninative build output he can likely test it | 23:06 |
| halstead | RP, Okay. Okay will do. | 23:11 |
| halstead | RP, Shall I put in in it's final place for testing? | 23:12 |
| RP | halstead: please, I just noticed its finished | 23:12 |
| RP | halstead: sorry, I'm struggling to stay awake, didn't realise how late it was here :/ | 23:14 |
| RP | I'll test tomorrow if khem hasn't | 23:14 |
| * RP really goes | 23:14 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 23:21 | |
| *** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has quit IRC | 23:22 | |
| khem | RP: I ran testimages with -fno-common defaults and it seems to improve performance a notch too | 23:32 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 23:35 | |
| halstead | khem, Files are up at https://downloads.yoctoproject.org/releases/uninative/2.9/ | 23:39 |
| khem | halstead: oh cool | 23:40 |
| halstead | khem, This includes the switch from md5sum to sha256sum. Let me know if I need to create md5sum files. | 23:40 |
| halstead | khem, I've made signed tags for the release. Let me know if tests are successful and I can push them. | 23:43 |
| khem | halstead: I send yocto-uninative.inc update to fetch 2.9 uninative to ml | 23:52 |
| khem | let me run it locally it seems to be holding well thus dar | 23:52 |
| khem | far | 23:52 |
| *** armpit2 is now known as armpit | 23:52 | |
| halstead | Thank you khem | 23:53 |
| *** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC | 23:54 | |
| khem | zeddii: btw. the kernel warning is still happening with latest master-next http://sprunge.us/kgrNq7 | 23:55 |
| khem | this is on qemumips | 23:55 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!