| *** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has quit IRC | 00:27 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 00:28 | |
| *** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has joined #yocto | 00:30 | |
| *** geissona_ <geissona_!~geissonat@45-18-127-186.lightspeed.austtx.sbcglobal.net> has joined #yocto | 00:44 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 01:30 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 01:36 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC | 02:04 | |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto | 02:19 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 02:23 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 02:23 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 02:46 | |
| *** vmeson <vmeson!~rmacleod@138.229.221.104> has quit IRC | 03:00 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 03:01 | |
| *** vmeson <vmeson!~rmacleod@138.229.221.104> has joined #yocto | 03:02 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 03:23 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 03:23 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 03:32 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 03:34 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:22 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:23 | |
| *** aehs29 <aehs29!~aehs29@149.199.62.131> has quit IRC | 04:26 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 04:26 | |
| *** flihp <flihp!~flihp@76.243.124.132> has quit IRC | 04:26 | |
| *** DuClare <DuClare!~duclare@freenet/Freetalk/developer/DuClare> has quit IRC | 04:26 | |
| *** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has quit IRC | 04:26 | |
| *** ctlnwr_ <ctlnwr_!~catalin@89.121.200.102> has quit IRC | 04:26 | |
| *** maathieu2a <maathieu2a!~mathieu@92-111-78-37.static.v4.ziggozakelijk.nl> has quit IRC | 04:26 | |
| *** anubani <anubani!~quassel@213.6.2.253> has quit IRC | 04:26 | |
| *** jofr <jofr!~jofr@193.182.166.3> has quit IRC | 04:26 | |
| *** RB2 <RB2!~RB2@c-73-178-160-56.hsd1.nj.comcast.net> has quit IRC | 04:26 | |
| *** sven^ <sven^!~quassel@unaffiliated/sven/x-8293843> has quit IRC | 04:26 | |
| *** rokm <rokm!rokm@freeshell.de> has quit IRC | 04:26 | |
| *** beneth <beneth!~beneth@lxcb.beneth.fr> has quit IRC | 04:26 | |
| *** cmichel <cmichel!~cmichel@mail.sv-maberzell.de> has quit IRC | 04:26 | |
| *** Mylene <Mylene!~Mylene@95.ip-51-255-48.eu> has quit IRC | 04:26 | |
| *** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-chqqugdaahfjqllv> has quit IRC | 04:47 | |
| *** ctlnwr <ctlnwr!~catalin@89.121.200.102> has quit IRC | 04:51 | |
| *** aehs29 <aehs29!~aehs29@149.199.62.131> has joined #yocto | 04:53 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 04:53 | |
| *** flihp <flihp!~flihp@76.243.124.132> has joined #yocto | 04:53 | |
| *** DuClare <DuClare!~duclare@freenet/Freetalk/developer/DuClare> has joined #yocto | 04:53 | |
| *** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has joined #yocto | 04:53 | |
| *** ctlnwr_ <ctlnwr_!~catalin@89.121.200.102> has joined #yocto | 04:53 | |
| *** maathieu2a <maathieu2a!~mathieu@92-111-78-37.static.v4.ziggozakelijk.nl> has joined #yocto | 04:53 | |
| *** anubani <anubani!~quassel@213.6.2.253> has joined #yocto | 04:53 | |
| *** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 04:53 | |
| *** RB2 <RB2!~RB2@c-73-178-160-56.hsd1.nj.comcast.net> has joined #yocto | 04:53 | |
| *** sven^ <sven^!~quassel@unaffiliated/sven/x-8293843> has joined #yocto | 04:53 | |
| *** rokm <rokm!rokm@freeshell.de> has joined #yocto | 04:53 | |
| *** beneth <beneth!~beneth@lxcb.beneth.fr> has joined #yocto | 04:53 | |
| *** cmichel <cmichel!~cmichel@mail.sv-maberzell.de> has joined #yocto | 04:53 | |
| *** Mylene <Mylene!~Mylene@95.ip-51-255-48.eu> has joined #yocto | 04:53 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ynpcwuquxbttbgae> has quit IRC | 05:15 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 05:19 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 05:22 | |
| *** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-xuaqubhiunjaqssq> has joined #yocto | 05:23 | |
| *** kaspter <kaspter!~Instantbi@115.204.165.136> has quit IRC | 05:25 | |
| *** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-xuaqubhiunjaqssq> has quit IRC | 05:32 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 05:40 | |
| *** AndersD <AndersD!~AndersD@194.237.220.218> has joined #yocto | 06:09 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 06:20 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 06:21 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 06:22 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 07:20 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:21 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 07:22 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:23 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 07:26 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 07:28 | |
| *** henriknj <henriknj!~hnje@193.106.123.182> has joined #yocto | 07:36 | |
| *** cvasilak <cvasilak!~cvasilak@ppp-94-64-10-185.home.otenet.gr> has joined #yocto | 07:39 | |
| henriknj | Installing kernel-devsrc as part of my sdk ends up with a dead link to /lib/modules/ - shouldn't it be pointing to the /lib/modules in the sdksysroot path? | 07:40 |
|---|---|---|
| *** spriyanka <spriyanka!~Priyanka@123.252.238.18> has joined #yocto | 07:49 | |
| *** mckoan|away is now known as mckoan | 07:50 | |
| *** fl0v0 <fl0v0!~fvo@mue-88-130-100-247.dsl.tropolys.de> has joined #yocto | 07:53 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 08:07 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 08:08 | |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 08:08 | |
| *** lusus <lusus!~lusus@62.91.23.180> has joined #yocto | 08:09 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 08:19 | |
| *** Tamis <Tamis!504e056a@gateway/web/freenode/ip.80.78.5.106> has joined #yocto | 08:20 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 08:22 | |
| Tamis | in bitbake.conf I can see exports of AR, AS, RANLIB, STRIP etc. Is there a special reason why the SIZE export is missing? | 08:23 |
| RP | Tamis: we've never seen anything need/use it? | 08:25 |
| Tamis | RP: I have some Makefiles that they use it. They don't do anything they just print a nice table... So I guess if we put it there with a patch wouldn't be a problem. It will complete also the list | 08:29 |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 08:29 | |
| RP | Tamis: just do it in your recipe. Changing bitbake.conf changes shell environment globally and we need probably reduce what we have there, not add to it if we can help it | 08:31 |
| RP | Tamis: I doubt it would break anything but its not something I'm keen to see upstream | 08:32 |
| Tamis | RP: ok ty | 08:33 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 08:35 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:38 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 08:44 | |
| *** ant_work <ant_work!~ant__@host205-129-static.31-195-b.business.telecomitalia.it> has joined #yocto | 08:46 | |
| *** cvasilak <cvasilak!~cvasilak@ppp-94-64-10-185.home.otenet.gr> has quit IRC | 08:47 | |
| *** Marex <Marex!~Marex@195.140.253.167> has quit IRC | 08:57 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:04 | |
| *** dkc <dkc!~dkc@55.ip-158-69-215.net> has quit IRC | 09:05 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 09:14 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-pkbnezjtyiynegpo> has joined #yocto | 09:15 | |
| *** jij <jij!jonashg@nat/axis/x-ujowyojsyhyjjpoe> has quit IRC | 09:15 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 09:19 | |
| *** Marex <Marex!~Marex@195.140.253.167> has joined #yocto | 09:23 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 09:23 | |
| *** ronybeck <ronybeck!~ronybeck@46.140.63.234> has quit IRC | 09:24 | |
| *** naknick <naknick!1f9a4286@gateway/web/freenode/ip.31.154.66.134> has quit IRC | 09:28 | |
| *** jij <jij!jonashg@nat/axis/x-ixfyepuzjhezqfpj> has joined #yocto | 09:31 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 09:33 | |
| *** ronybeck <ronybeck!~ronybeck@46.140.63.234> has joined #yocto | 09:37 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 09:38 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 09:54 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 10:20 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:22 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 10:23 | |
| *** ronybeck <ronybeck!~ronybeck@46.140.63.234> has quit IRC | 10:29 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 10:41 | |
| *** ronybeck <ronybeck!~ronybeck@46.140.63.234> has joined #yocto | 10:42 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 10:42 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 10:44 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 10:48 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:49 | |
| *** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 10:56 | |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 10:59 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 11:19 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 11:23 | |
| *** berton <berton!~berton@177.194.204.148> has joined #yocto | 11:27 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 11:44 | |
| *** gsalazar <gsalazar!~gsalazar@66.252.115.89.rev.vodafone.pt> has quit IRC | 11:50 | |
| *** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 11:57 | |
| *** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 12:00 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 12:02 | |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has quit IRC | 12:09 | |
| *** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 12:11 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 12:19 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 12:23 | |
| *** rubdos_ <rubdos_!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has joined #yocto | 12:27 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 12:37 | |
| Willie2 | Hi, I'm trying to build my custom image based on a demo image. I keep getting the error : amixer: Unable to find simple control 'Speaker',0 in my custom image. I can see that the alsa libs are installed and there were no specific sound recipes that i could see in the old image, but now I'm unable to get the sound to work | 12:37 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 12:51 | |
| Willie2 | The image recipes are similiar : https://pastebin.com/FQ5RpaVn but something must be missing | 12:59 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 13:09 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 13:15 | |
| *** luneff <luneff!~yury@109.165.109.216> has joined #yocto | 13:16 | |
| luneff | hey guys! is there a reason why I can't find a ready yocto recipe for electron? Noone does kiosk applications with Electron or something? meta-electron seems to be gone from OSSystems github... | 13:17 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 13:20 | |
| LetoThe2nd | luneff: it might also be that just nobody shared. so, be the first to improve the situation! | 13:22 |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 13:23 | |
| LetoThe2nd | luneff: we have support for chromium and webkit, though | 13:23 |
| *** gsalazar <gsalazar!~gsalazar@66.252.115.89.rev.vodafone.pt> has joined #yocto | 13:23 | |
| luneff | yes, I saw meta-browser etc, but I wondered with there's anything related to electron other than this https://github.com/vulcanoio/meta-electron :-) it's 4 year old | 13:24 |
| luneff | maybe indeed I'll have to be the first one :-D I just need underlying Chromium to be properly hw accelerated on a RPi3 :-) | 13:25 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 13:32 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 13:45 | |
| *** AndersD <AndersD!~AndersD@194.237.220.218> has quit IRC | 14:00 | |
| *** luneff <luneff!~yury@109.165.109.216> has quit IRC | 14:06 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 14:19 | |
| Willie2 | I'm using the exact same zImage so as long as the same sound recipes are installed I don't see how it can work in one image but not the other | 14:21 |
| *** spriyanka <spriyanka!~Priyanka@123.252.238.18> has quit IRC | 14:22 | |
| angelo_ts | hi, in a kernel .bb i have a LIC_FILES_CHKSUM but also in included linux.inc ... is this correct ? Also, is sufficient to midify the LIC_FILES_CHKSUM in the .bb recipe ? | 14:22 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 14:23 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 14:26 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 14:28 | |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto | 14:31 | |
| *** dkc <dkc!~dkc@55.ip-158-69-215.net> has joined #yocto | 14:43 | |
| dkc | This commit breaks mosquitto for thud: http://cgit.openembedded.org/meta-openembedded/commit/meta-networking/recipes-connectivity/mosquitto/mosquitto_1.5.1.bb?h=thud&id=a483d344d9fb42709c09b523c1768f4142ab9da4 | 14:44 |
| dkc | as PACKAGECONFIG_CONFARGS is not passed to EXTRA_OEMAKE | 14:44 |
| *** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has quit IRC | 14:44 | |
| dkc | so I don't know what'a the right tactic, should this patch be backported to thud? http://cgit.openembedded.org/meta-openembedded/commit/meta-networking/recipes-connectivity/mosquitto?id=e39709e381f4a1229584a3c47e219536a35b78e2 | 14:45 |
| rburton | yes | 14:46 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 14:49 | |
| dkc | should I send an email to request so? | 14:50 |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 14:51 | |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 14:51 | |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 14:53 | |
| *** AndersD_ <AndersD_!~AndersD@194.237.220.218> has joined #yocto | 14:53 | |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 14:55 | |
| RP | dkc: yes please | 14:58 |
| angelo_ts | Not sure if it's ok, about my issue above, i removed LIC_FILES_CHKSUM from the linux.inc, while i am leaving it into the linux_X.X.bb only. Seems to build fine. | 14:59 |
| dkc | okay, I have plenty of meetings today but I'll do it later today | 14:59 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 15:05 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 15:09 | |
| *** Striking7 <Striking7!~jon@96-94-100-129-static.hfc.comcastbusiness.net> has joined #yocto | 15:09 | |
| *** Striking7 <Striking7!~jon@96-94-100-129-static.hfc.comcastbusiness.net> has joined #yocto | 15:11 | |
| Striking7 | Hey all. I'm having some problems with the instructions with auto-update-helper | 15:11 |
| Striking7 | https://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/about/ | 15:11 |
| Striking7 | I've followed the directions, but I'm pretty new to yocto, so I haven't been able to get it to properly run. | 15:11 |
| Striking7 | I ran ". ./oe-init-build-env build-auh" from a fresh clone of yocto | 15:13 |
| Striking7 | where does it expect the auto upgrade helper sources to be? | 15:13 |
| Striking7 | I don't see a bitbake target for it either | 15:13 |
| *** justanotherboy <justanotherboy!~justanoth@THOUSAND-EY.bear1.Houston1.Level3.net> has joined #yocto | 15:15 | |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto | 15:16 | |
| *** slips <slips!~slips@2.51-174-212.customer.lyse.net> has quit IRC | 15:16 | |
| yates | could someone please point me to the doc for pkgconfig? i'm not seeing it in a google search | 15:18 |
| yates | when building an autotools-based recipe, how do i see the ./configure options that are being used in the actual ./configure command? | 15:19 |
| *** User__ <User__!~learningc@219.92.37.145> has joined #yocto | 15:19 | |
| *** meego <meego!500b97ce@gateway/web/freenode/ip.80.11.151.206> has joined #yocto | 15:20 | |
| RP | yates: try pkg-config ? | 15:20 |
| RP | yates: look at the files in ${WORKDIR}/temp e.g. run.do_configure | 15:20 |
| yates | RP: ok thanks (twice) | 15:20 |
| *** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 15:20 | |
| meego | hi there, what might be the Right Way™ of having conditional SRC_URI (a different git branch) depending on the image being built ? | 15:21 |
| kergoth | meego: images are constructed from packages. at the time the package is built, we have no idea what images it'll be installed into | 15:21 |
| kergoth | so you could change it via local.conf between the two builds, to make it rebuild with the new rev, or use two recipes/packages and select between them | 15:22 |
| yates | meego: perhaps having a bbappend in your image layer to modify the SRC_URI? | 15:22 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 15:23 | |
| kergoth | unlikely the images are in separate layers, and violates the convention where layer inclusion shouldn't change the build without opting in | 15:24 |
| *** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 15:24 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has quit IRC | 15:25 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 15:26 | |
| Striking7 | How can I query what versions of a package are available? | 15:28 |
| meego | thanks for the help. i've considered the .bbappend path. Won't there be a naming issue ? Let's say my debug image has IMAGE_INSTALL_append += "packageX-dbg", and i create a "packageX-dbg.bbapend" file. That bbappend can't modify the packageX build process, can it ? | 15:29 |
| kergoth | package, or recipe? bitbake -s is probably sufficient | 15:29 |
| kergoth | meego: bbappends apply to recipes, not packages | 15:29 |
| Striking7 | Looking at it | 15:29 |
| Striking7 | Thank you. | 15:29 |
| Striking7 | Still quite new to this | 15:29 |
| RP | jonmason, zeddii: FWIW KMACHINE_qemuarm = "qemuarma15" works locally for me | 15:29 |
| *** User__ <User__!~learningc@219.92.37.145> has quit IRC | 15:30 | |
| Striking7 | kergoth - bitbake -s ran fast enough that it's obviously looking at a local copy | 15:30 |
| kergoth | Striking7: as opposed to what? | 15:30 |
| kergoth | bitbake builds from local recipes, that's what it is | 15:30 |
| Striking7 | is there a utility to run the same type of lookups remotely? For instance, to see if a CVE has been patched yet according to version numbers? | 15:30 |
| jonmason | RP: cool! | 15:31 |
| kergoth | devtool has a subcommand to check for new upstream versions, but you can't build them without using it to first upgrade the recipe | 15:31 |
| Striking7 | Sure - I understand: bitbake is a local deal. Not a problem. That package info has to be grabbed by some utility though | 15:31 |
| Striking7 | Ok, good to know | 15:31 |
| jonmason | where did you put it? in the linux-yocto_4.19.bb? | 15:31 |
| kergoth | no, it doesn't. determining what upstream versions are available used to be entirely manual | 15:31 |
| RP | jonmason: linux-yocto_5.0.bb | 15:31 |
| kergoth | the fact that we have such a tool now is a convenience | 15:31 |
| Striking7 | I agree. I'm trying to figure out how best to use it. | 15:32 |
| zeddii | the kernel part works fine here as well. | 15:32 |
| jonmason | RP: weird, I wonder why it wasn't working for me. Anyway, ship it ;-) | 15:32 |
| Striking7 | Thanks for the tip about devtool | 15:33 |
| meego | kergoth: OK. If i understand correctly, there is no way to conditionally load a bbappend from an image bb file. Because of the layer separation you mentioned. Is that right ? | 15:34 |
| *** stephano <stephano!~stephano@134.134.139.76> has joined #yocto | 15:34 | |
| kergoth | appending an image isn't going to magically change a different recipe | 15:35 |
| kergoth | one recipe can't change how another recipe builds | 15:35 |
| kergoth | yates was proposing changing the recipe configuration based on inclusion of a layer, not changing the image | 15:35 |
| kergoth | afaict anyway | 15:35 |
| kergoth | i'd suggest just changing ther ecipe's SRCREV from local.conf when you switch image builds | 15:35 |
| kergoth | bitbake picks a single provider of a package to build, builds it one way, and then that package is available to install in any and all images | 15:36 |
| kergoth | an image can't change another reicpe/package | 15:36 |
| meego | kergoth: ok understood | 15:36 |
| meego | i'll take the local.conf path. Thank you both for your help. | 15:37 |
| kergoth | you could use a second recipe, and switch versions/providers to select it, or change how the one recipe builds via configuration | 15:37 |
| kergoth | in either case you're having to change providers in the config, so it doesn't matter either way | 15:37 |
| zeddii | @#!@! gmail, RP it filed your follow up from this morning as spam. | 15:39 |
| zeddii | I’m shocked I even bothered to check the spam folder | 15:39 |
| * zeddii clicks ‘not spam’ | 15:39 | |
| * kergoth giving serious thought to ditching gmail at some point | 15:39 | |
| yates | please take my suggestion with a grain of salt. kergoth has two orders of magnitude more experience with yocto than i | 15:40 |
| Crofton | only 2? | 15:41 |
| kergoth | it's a valid suggestion, my objections are more to do with conventions and "best practices" .. i hate that term, but drawing a blank | 15:41 |
| yates | Crofton: the order of magnitude estimate is an order of magnitude. could be 20... | 15:42 |
| kergoth | idiomatic. that's the word i was looking for. oe allows you a hell of a lot of flexibility, so a certain amount of thought as to the cleanest most maintainable approach is useful | 15:42 |
| yates | will my .bbappend for a recipe in my layer get utilized when devtool building | 15:42 |
| yates | ? | 15:42 |
| kergoth | devtool build just runs bitbake | 15:43 |
| kergoth | if the layer is included, and the bbappend matches the patterns in BBFILES, and its filename matches the recipe, it'll be applied whether you're using devtool or not | 15:43 |
| yates | kergoth: aha. that was going to be antoher question: difference between "devtool build <recipe" and "bitbake <recipe"? nada? | 15:43 |
| yates | within context of a devtool modify, that is | 15:44 |
| Striking7 | Is there a way to roll a package back to a previous version using bitbake, devtool, and the like? | 15:45 |
| kergoth | looks like it just bitbakes the populate_sysroot packagedata tasks for you, optionally temporarily disabling parallel make during the build | 15:45 |
| kergoth | https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/devtool/build.py | 15:45 |
| yates | Striking7: seems like a git/svn function, | 15:45 |
| kergoth | https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/devtool/build.py#L57-L73 | 15:45 |
| kergoth | https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/devtool/build.py#L49-L51 | 15:45 |
| Striking7 | Reading your links - thanks for the info | 15:45 |
| kergoth | those 3 links were for yates | 15:46 |
| kergoth | to "roll back" a version you need to change/rename the recipe to the old version, and adjust patches appropriately | 15:46 |
| Striking7 | Oh, came in kind of handy for me anyway :-) | 15:46 |
| kergoth | if we already had a recipe for the old version at some point, as yates says, use git to resurrect the old version | 15:46 |
| Striking7 | ok. | 15:46 |
| kergoth | bitbake only builds the verisons of the recipes we have in the layers, not arbitrary versions | 15:47 |
| kergoth | devtool assists with upgrades to newer upstream versions, but you'll have to fix patches, if we'd already built the old version, it makes more sense to pull it out of source control than to re-do the work | 15:47 |
| Striking7 | Makes sense. | 15:47 |
| yates | back to the .bbappend question, i have a .bbappend in a layer which should be selected for matchbox-wm which is simply this: https://paste.fedoraproject.org/paste/jrnTHd6sigstMaPuPqlQsg | 15:48 |
| Striking7 | I don't mind doing it that way, I'm just trying to figure out all the data that's available to me here. For instance, one thing we would really like is a list of available package versions | 15:48 |
| yates | yet the ./configure option --enable-composite" is not being specified | 15:48 |
| Striking7 | I can get the list of latest packages, but not info about previous versions for a single package. | 15:48 |
| kergoth | †he only list you can get is what recipes you have right now, or what upstream upgrades are available. by policy we don't keep old versions around in our layers, it's a maintenance nightmare to keep everything building going forward | 15:49 |
| Striking7 | Of course, I understand completely | 15:49 |
| kergoth | *if* the recipe name includes the version, i.e. for non-git recipes, you could use git to extract a list of the files we've removed from history | 15:49 |
| kergoth | Striking7: https://github.com/kergoth/dotfiles/blob/master/git/scripts/git-attic | 15:50 |
| Striking7 | So really all the remote access these tools do is git? | 15:50 |
| yates | here is my latest log.do_configure: https://paste.fedoraproject.org/paste/gus2ueMRZMOi0ZACyE1GFw | 15:50 |
| *** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 15:50 | |
| yates | it's just not ther.e | 15:50 |
| kergoth | via http://chneukirchen.org/dotfiles/bin/git-attic | 15:51 |
| yates | there | 15:51 |
| kergoth | Striking7: no, devtool's upgrade checking uses patterns and remote urls to check for remote version availability | 15:51 |
| Striking7 | Thanks kergoth | 15:51 |
| kergoth | but other than that,e verything is local | 15:51 |
| yates | i need "Building with Composite manager" to be "yes" | 15:51 |
| kergoth | yates: make sure your append is in an included layer (see conf/bblayers.conf in BBLAYERS) and in the correct path to be included (see BBFILES in <layerdir>/conf/layer.conf) | 15:51 |
| Striking7 | kergoth: perfect! I'll dive into its source to see where all that comes from. That looks like the right direction for me | 15:52 |
| kergoth | and the filename has to match the recipe | 15:52 |
| yates | i'm using matchbox-wm_%.bbappend - wouldn't that work ? | 15:52 |
| kergoth | bitbake/oe is designed to be self-contained and independent of host and target distro and machine, we've never designed or implemented a protocol to access metadata anywhere but in the local layers | 15:52 |
| kergoth | yates: also, use bitbake-layers show-appends, way quicker way to check if it's being applied | 15:53 |
| *** meego <meego!500b97ce@gateway/web/freenode/ip.80.11.151.206> has quit IRC | 15:53 | |
| yates | matchbox-wm_1.2.1.bb is the recipe | 15:53 |
| yates | ok | 15:53 |
| kergoth | that filename is fine, yeah, so check layer inclusion and its location within the layer | 15:53 |
| kergoth | you can't just drop a bbappend wherever you want, it has to match the wildcards in BBFILES in the layer it's in | 15:53 |
| kergoth | i.e. <layerdir>/recipes-*/*/*.bbappend, or whatever | 15:54 |
| yates | ok | 15:54 |
| yates | let me check.. | 15:54 |
| *** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 15:54 | |
| kergoth | Striking7: https://gist.github.com/5f34aff94cce3b0d66b5ffc4b1b24959 if you want to pursue the scm history route. | 15:56 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:59 | |
| Striking7 | kergoth you are a life saver | 15:59 |
| kergoth | np. that attic script is handy, particularly since it includes the last commit where the file existed, so you can look at the recipe with git show, or use checkout to resurrect it | 16:00 |
| Striking7 | veeeeery cool | 16:00 |
| Striking7 | This is all still a bit over my head - I just started this job Tuesday. | 16:01 |
| Striking7 | So the terminology (recipe vs. package, layers, etc) is all still soft and squishy in the brain | 16:01 |
| kergoth | no worries, we all have to start somewhere, and oe/yocto is complex (of necessity, due to the flexibility), with a fairly steep learning curve | 16:01 |
| kergoth | once you grasp the big picture it starts to come together in your head, i think | 16:01 |
| kergoth | but some learn best bottup-up, others top-down, so depends on the person | 16:02 |
| Striking7 | Totally understand - I usually do a little of each | 16:06 |
| Striking7 | lets you use your right brained creativity in "reverse engineering" from top down, lets you use left brain methodical tendencies for bottom up | 16:06 |
| yates | i am confused about how layers are configured. is it via sources/poky/<build>/conf/bblayers.conf? but i also have a sources/<my-meta>/conf/layer.conf? | 16:13 |
| yates | if <my-meta> is in the build bblayers.conf, does its layer.conf get appended? | 16:15 |
| yates | or some other means... | 16:15 |
| yates | bitbake-layers show-appends is NOT showing my .bbappend file | 16:16 |
| yates | am i even making sense? | 16:17 |
| Striking7 | Anyone knows where devtool checks for upstream updates? | 16:19 |
| *** AndersD_ <AndersD_!~AndersD@194.237.220.218> has quit IRC | 16:19 | |
| Striking7 | know* | 16:19 |
| *** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 16:19 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 16:23 | |
| *** User_ <User_!~learningc@2001:d08:d6:105c:adc6:65fb:fc79:61af> has joined #yocto | 16:29 | |
| yates | my sources/<my-meta>/conf/layer.conf does not specify layers but it does specify BBILES, how layers are to be searched I guess. | 16:30 |
| *** lusus <lusus!~lusus@62.91.23.180> has quit IRC | 16:31 | |
| *** learningc <learningc!~learningc@14.192.212.129> has joined #yocto | 16:32 | |
| yates | so if the sources/poky/<build>/conf/bblayers.conf contains source/<my-meta> as a layer, does that layer's <my-meta>/conf/layer.conf get applied (e.g., the BBIILES)? | 16:32 |
| yates | ..the BBFILES | 16:34 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 16:34 | |
| *** User_ <User_!~learningc@2001:d08:d6:105c:adc6:65fb:fc79:61af> has quit IRC | 16:34 | |
| *** jp24 <jp24!b8477076@gateway/web/cgi-irc/kiwiirc.com/ip.184.71.112.118> has quit IRC | 16:42 | |
| yates | nm - got it. | 16:45 |
| *** vmeson <vmeson!~rmacleod@138.229.221.104> has quit IRC | 16:49 | |
| yates | yocto schoolboy mistake... it was in <my-mega>/<my-recipe>/matchbox-wm_%.bbappend instead of <my-mega>/<my-recipe>/matchbox-wm/matchbox-wm_%.bbappend | 16:49 |
| yates | s/mega/meta/ | 16:49 |
| *** gattuso <gattuso!~gattuso@pompel.me> has quit IRC | 16:50 | |
| *** gattuso <gattuso!~gattuso@pompel.me> has joined #yocto | 16:51 | |
| kergoth | figured, you're not the first one to put it in the wrong spot. been there myself | 16:56 |
| yates | would be nice if bitbake-layers show-appends took a recipe as a final argument, so you don't have to grep through ALL appends to fihd the one... | 16:59 |
| kergoth | not a bad idea, maybe submit a bug to bugzilla? | 16:59 |
| kergoth | debatable whether it should accept layer or recipe as first argument, so probably use an option. -r RECIPE or something | 17:00 |
| yates | kergoth: good idea. just to complete, was i right on the application of the BBFILES in layer.conf? | 17:01 |
| kergoth | yes, bblayers lists layers to process, conf/layer.conf is parsed in each layer to construct a final BBPATH and BBFILES, and bitbake uses those to do the actual parsing | 17:01 |
| yates | ack - good. | 17:02 |
| kergoth | then BBFILE_COLLECTIONS/BBFILE_PATTERN_<name>/BBFILE_PRIORITY_<name> controls layer priority. when the same recipe exists in multiple layers with different versions, the higher priority layer recipe is used, even if it's the older one, unless PREFERRED_VERSION selects explicitly | 17:02 |
| *** User_ <User_!~learningc@14.192.212.129> has joined #yocto | 17:06 | |
| yates | ok | 17:08 |
| kergoth | I'd highly suggest both of you to read http://www.aosabook.org/en/yocto.html | 17:09 |
| kergoth | it covers this, and isn't particularly long | 17:09 |
| *** learningc <learningc!~learningc@14.192.212.129> has quit IRC | 17:09 | |
| *** fl0v0 <fl0v0!~fvo@mue-88-130-100-247.dsl.tropolys.de> has quit IRC | 17:10 | |
| *** learningc <learningc!~learningc@14.192.212.129> has joined #yocto | 17:10 | |
| *** User_ <User_!~learningc@14.192.212.129> has quit IRC | 17:11 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 17:14 | |
| *** CoLa|work <CoLa|work!~cordlandw@91.239.177.14> has quit IRC | 17:14 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC | 17:16 | |
| yates | i'm getting errors in the build and having a hard time parsing. could someone please have a look? https://paste.fedoraproject.org/paste/D1eOHqORDezbOZVkp5vbTg | 17:17 |
| yates | do i need a DEPENDS on glibc? | 17:19 |
| RP | jonmason: we're missing a patch I think to replace qemuarm with the a15 one? | 17:19 |
| RP | zeddii: how dare it! :) | 17:19 |
| Striking7 | Thanks Kergoth - reading | 17:20 |
| *** geissona_ <geissona_!~geissonat@45-18-127-186.lightspeed.austtx.sbcglobal.net> has quit IRC | 17:22 | |
| zeddii | RP: I’ve reproduced the perf 4.19 issue, looking at a fix now. | 17:27 |
| zeddii | and I’m randomly throwing configs at qemuarm64 to see if I can get a framebuffer to activate. but it is nearly random ;) | 17:27 |
| jonmason | RP: I thought you didn't want to remove it for legacy reasons | 17:28 |
| RP | jonmason: no, I want to switch it over and leave armarmv5 for legacy | 17:31 |
| *** mckoan is now known as mckoan|away | 17:32 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 17:33 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 17:40 | |
| jonmason | ah, ok. I can push that patch then....when I get home on Monday. Is that long of a delay okay? | 17:41 |
| RP | jonmason: It'll be my turn to travel | 17:45 |
| RP | jonmason: I'll take what I can get, when I can get it. I might sort something before then, we'll see. I know I'm running out of time to do everything before my travel now | 17:46 |
| *** ant_work <ant_work!~ant__@host205-129-static.31-195-b.business.telecomitalia.it> has quit IRC | 17:49 | |
| jonmason | In SCaLE now, and for some reason my dyndns isn't working :( | 17:58 |
| *** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-xzwbzkepstukpopi> has joined #yocto | 17:58 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto | 18:03 | |
| *** geissona_ <geissona_!~geissonat@32.97.110.57> has joined #yocto | 18:03 | |
| RP | jonmason: right, no problem. I think the M3 build is going to be a bit rocky timing wise... | 18:05 |
| *** armpit <armpit!~armpit@2601:202:4180:c33:812:f55f:93a9:af21> has quit IRC | 18:06 | |
| Striking7 | anyone here using cve-check-tool? | 18:15 |
| *** Tamis <Tamis!504e056a@gateway/web/freenode/ip.80.78.5.106> has quit IRC | 18:18 | |
| kergoth | and now oe-selftest for devtool is failing due to a lack of git user name/email configuration | 18:21 |
| kergoth | despite it being configured | 18:21 |
| psrcode | is there a way to require a busybox version with FEATURE_FANCY_HEAD enabled for a recipe (ptest actually)? | 18:29 |
| psrcode | head is missing the -c option... and end-up screwing a basic bash randomstring generator. We can change it upstream but if I can add a dependancy for a *fancy* head utils in yocto, I would prefer that | 18:30 |
| kergoth | nope, not possible. you'd have to change the busybox configuration at a configuration or busybox recipe level | 18:32 |
| kergoth | you could always depend on the real tool, not busybox, for head | 18:32 |
| kergoth | i.e. coreutils i'm guessing? | 18:32 |
| psrcode | yeah | 18:33 |
| psrcode | does oe-core have the recipe for the "real" tool... | 18:34 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-pkbnezjtyiynegpo> has quit IRC | 18:34 | |
| psrcode | nevermind, did a quick grep. got my answer | 18:35 |
| psrcode | thanks | 18:35 |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has quit IRC | 18:41 | |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto | 18:56 | |
| yates | does bitbake dump the screen output to a file? | 18:57 |
| kergoth | tmp/log/ | 19:22 |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has quit IRC | 19:28 | |
| *** mattsm <mattsm!~mattsm@76-205-175-243.lightspeed.austtx.sbcglobal.net> has joined #yocto | 19:29 | |
| yates | is there a better display system than matchbox? namely, something with a decent compositor? | 19:36 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 19:37 | |
| yates | or... does anyone know how to make --enable-composite work? | 19:48 |
| yates | in the matchbox-wm recipe? | 19:48 |
| yates | has anyone gotten this to work? | 19:49 |
| yates | i'm reading some nasty stuff that it won't work with compositing enabled: http://lists.busybox.net/pipermail/buildroot/2015-June/129897.html | 19:50 |
| yates | rburton: any thoughts? | 19:52 |
| JPEW | yates: Would weston work? | 19:58 |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has quit IRC | 19:59 | |
| Striking7 | So I like devtool so far - its "upgrade" command takes a preferred version as a param, and it can downgrade or upgrade pretty seamlessly. | 20:00 |
| Striking7 | What I'd like is to get a list of versions of a package that are available and present that to the user | 20:00 |
| Striking7 | (or rather, long term, to another component in the system) | 20:00 |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 20:00 | |
| Striking7 | Anyone know if devtool has a way of doing that already? I know it's using SRC_URI and scraping latest_version from there, but I wasn't sure if it stored all the versions available as well | 20:01 |
| khem | JPEW: icecc in my env did not solve the world hunger | 20:01 |
| khem | JPEW: I have 16Core+16GB+300GB-SSD | 20:01 |
| Striking7 | khem - that's the worst: I hate it when my code fails to solve world hunger | 20:01 |
| JPEW | khem: Too bad. It is a bit twiddly.... for example, we are all running a patched version of icecc | 20:02 |
| khem | and I add another box with same spec and build times are same or worse | 20:02 |
| khem | I guess n/w is my bottleneck | 20:02 |
| khem | I need 10G backhaul | 20:02 |
| JPEW | That would be nice. What do you have now? | 20:03 |
| khem | or maybe even thats not enough to beat SSDs | 20:03 |
| khem | JPEW: this is some cloud that someone else manages I have asked them the question | 20:03 |
| JPEW | khem: Could be the SSDs. I still have spinny drives | 20:04 |
| khem | JPEW:I am doing another experiment where I will have 4 8 core machines as slaves and then do -j30 to build chromium-x11 | 20:04 |
| khem | yeah SSDs are the biggest improvement for OE builds I agree | 20:05 |
| yates | JPEW: it looks like that is for wayland | 20:05 |
| yates | we are using x11 | 20:05 |
| JPEW | Ah. too bad | 20:05 |
| khem | yates:you can look into westeros which is a light weight wayland compositor | 20:05 |
| khem | https://github.com/rdkcmf/westeros | 20:06 |
| yates | JPEW: have you used wayland/weston on an embedded device with like a smallish LCD display? (ours is 800x480) | 20:06 |
| khem | yates:whats the app ? | 20:06 |
| khem | do you run in kiosk mode ? | 20:06 |
| yates | khem: i don't understrand the question(s) | 20:07 |
| khem | x11+qt5 is decent | 20:07 |
| yates | we are using x11+wxwidgets | 20:07 |
| JPEW | yates: I've used weston for testing purposes. We have our own proprietary wayland compositor we use in production (not by choice.... I'd rather use weston) | 20:07 |
| JPEW | weston is pretty configurable with plugin shells and such | 20:08 |
| yates | JPEW: would it be easy to bring weston/wayland in instead of x11/matchbox? | 20:08 |
| khem | weston is heavier, surely thats why we wrote westeros for RDK and its opensource( Apache-2.0) so enjoy and contribure back | 20:08 |
| JPEW | yates: depends on what applications you want to run on top of it | 20:08 |
| JPEW | yates: Just getting weston is pretty easy | 20:09 |
| JPEW | IMAGE_INSTALL += "weston" | 20:09 |
| khem | or base your image on top of core-image-weston | 20:09 |
| JPEW | Oh, ya that would work :) I didn't even know that was a thing | 20:09 |
| JPEW | khem: Does core-image-weston default weston to use DRM for hardware accelerated rendering? | 20:10 |
| yates | DRM? | 20:10 |
| khem | We have a browser based UI running on top of wayland+westeros doing full HD video in less than 512M RAM device | 20:10 |
| JPEW | yates: Direct Rendering Management, basically the kernels GPU API | 20:11 |
| khem | see https://github.com/WebPlatformForEmbedded/meta-wpe | 20:11 |
| JPEW | yates: AFAIK, weston in OE defaults to using (non-accelerated) framebuffer backend, which might feel pretty slow. If you have a GPU, enabling the DRM backend in weston makes it much better :) | 20:12 |
| yates | holy crap! | 20:12 |
| yates | no, nothing near HD video required in our stuff. | 20:13 |
| yates | but we do want sexy-looking UI with gradients, transparency, etc. | 20:13 |
| JPEW | yates: sure, are you using OpenGL (or OpenGLES) for that? | 20:14 |
| yates | i don't know... (sheepish look). i'm using wxWidgets wxDC classes and a little of my own, but transparencies don't work because we have no compositor | 20:16 |
| yates | wxDC has a built-in gradient fill | 20:16 |
| yates | perhaps under-the-hood wx uses OpenGL | 20:17 |
| yates | ? | 20:17 |
| JPEW | yates: Probably not | 20:17 |
| khem | wxwidgets would use opengl if platform enabled it | 20:19 |
| *** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC | 20:19 | |
| khem | build it with --with-opengl | 20:20 |
| yates | thanks for all the input folks, i'm still parsing/thinking on it. | 20:20 |
| yates | khem: you mean build wxWidgets --with-opengl? | 20:20 |
| khem | yes | 20:20 |
| khem | and ensure that your graphics driver supports openGL and is enabled there too | 20:21 |
| JPEW | FWIW: My recollection is that wxDC is a simple (non-acclerated) raster bitmap backing, and there are other classes for using OpenGL in wxWidgets, but I could be wrong | 20:21 |
| yates | yes, we already are: https://paste.fedoraproject.org/paste/UC7v7DGyhgPfuYhQYMht8w | 20:21 |
| yates | this is from the wx recipe i wrote a few weeks back. | 20:22 |
| khem | thats possible maybe they rely on GLX | 20:22 |
| yates | libglu is a depends - is that opengl? | 20:22 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 20:22 | |
| JPEW | khem: Very possible. wxWidgets does line to punt the underlying system when possible. My knowledge of X is very weak (more of a Wayland fan), and I'm OK with that :) | 20:23 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 20:23 | |
| yates | JPEW: re: raster bitmap, the transparencies work on fedora - exact same code as what i run on matchbox | 20:25 |
| yates | same wx version, 3.0.4 | 20:25 |
| yates | so it's not wx | 20:25 |
| khem | latest fedora uses wayland IIRC | 20:26 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 20:28 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:29 | |
| JPEW | khem: Yes it does, running it right now | 20:29 |
| JPEW | yates: Can you run wxwidgets without a windowing system (e.g. gtk)? | 20:31 |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 20:36 | |
| yates | it is the gtk-based version of wx, so .. yes? | 20:37 |
| yates | i've never done it, don't really know | 20:37 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 20:37 | |
| yates | i'm just trying to determine the quickest way to get our project transparency. | 20:37 |
| yates | if that means switching to weston/wayland, so be it. | 20:38 |
| yates | that will also probably be the time to upgrade morty to something this century.. | 20:38 |
| yates | it seems wayland is the wy of the future. | 20:38 |
| yates | but i do have questions. like can i still run an xterm if x11 is not there? | 20:39 |
| yates | can i run vnc server ? | 20:40 |
| yates | yada yada.. | 20:40 |
| yates | i guess i'm ignorant of the deeps parts of x11 versus wayland | 20:40 |
| yates | deep | 20:40 |
| yates | khem: are you implying that if the graphics driver supported openGL and it is enabled there, that we'd have transparencies with matchbox-wm? | 20:45 |
| yates | matchbox-wm + wxWidgets, that is? | 20:48 |
| rburton | yates: those comments are not very accurate. we autoreconf mbwm for a start | 20:52 |
| rburton | yates: nobody that i'm aware of has used the compositor since nokia/maemo so who knows if it still *works* | 20:52 |
| rburton | yates: ideally, just ditch X entirely and use weston | 20:52 |
| yates | right, coming to the same conclusion | 20:53 |
| rburton | x11 is legacy at this point basically | 20:54 |
| rburton | if you can use wayland | 20:54 |
| yates | khem/rburton: by "base your image on core-image-weston" do you mean "inherit core-image-weston" instead of "inherit core-image"? | 20:55 |
| rburton | no, i mean ditch X entirely and use weston | 20:55 |
| rburton | core-image-weston is an example, like core-image-sato | 20:55 |
| rburton | enabling compositing in mbwm is most likely trivial though | 20:55 |
| yates | rburton: oh? | 20:56 |
| rburton | --enable-composite and come back with patches | 20:56 |
| yates | you mean just rewrite part of the compositor? | 20:57 |
| yates | :) | 20:57 |
| yates | i've already done the --enable-composite | 20:58 |
| *** berton <berton!~berton@177.194.204.148> has quit IRC | 20:58 | |
| yates | that scares me.. but perhaps i'm just a wuss... | 20:58 |
| rburton | so voila, you have a compositing window manager | 20:58 |
| yates | no, it won't build. | 20:58 |
| rburton | right, so. fix that then :) | 20:58 |
| yates | i am honored that you have so much confidence in my abilities! | 20:59 |
| rburton | its just C | 20:59 |
| yates | so is the kernel... | 20:59 |
| khem | honor is hard to earn and easy to loose :) | 20:59 |
| rburton | yates: pastebin errors if you actually want a hand | 21:00 |
| yates | ok, thanks much | 21:00 |
| rburton | otherwise we're just telling you to fix it and you're saying its broken | 21:00 |
| khem | require recipes-graphics/images/core-image-weston.bb | 21:00 |
| khem | add that in your image recipe | 21:01 |
| dkc | is a signed-off-by required for a backport? | 21:01 |
| rburton | dkc: yes | 21:01 |
| dkc | ok! | 21:01 |
| rburton | khem: no need for that really but lets not complicate matters, yates is going to try fixing mbwm first :) | 21:01 |
| yates | :) | 21:02 |
| yates | ok, course laid in, engaging... | 21:02 |
| yates | Chekov: "But Captain (rburton), it will take 13.4 light years at sub-warp!" | 21:03 |
| *** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto | 21:05 | |
| yates | https://paste.fedoraproject.org/paste/1L0gQixPQo07dBAsLKmBmQ | 21:06 |
| yates | rburton: from this output i'd say the problem is a wrong link order, but how do i change that? a Makefile change? | 21:06 |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 21:07 | |
| *** aidanh_ is now known as aidanh | 21:07 | |
| yates | should i try modifying the build/src/Makefile? or is that auto-generated? | 21:12 |
| yates | there is a build/Makefile too | 21:13 |
| RP | zeddii: looks like stap works except for qemuarm | 21:21 |
| RP | yates: I think you're right and its a link order issue | 21:26 |
| RP | yates: you could probably prove easily by hacking Wl,--as-needed out of LDFLAGS | 21:26 |
| RP | yates: not the proper fix but would tell you if there are any other issues lurking | 21:27 |
| * nerdboy finally got his silly internet back again... | 21:28 | |
| psrcode | I'm having a hard time understanding the goal of " | 21:29 |
| psrcode | PACKAGECONFIG ??=" | 21:29 |
| psrcode | this https://lists.yoctoproject.org/pipermail/yocto/2013-November/016969.html indicate that it list the "enabled" feature | 21:29 |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 21:29 | |
| psrcode | but if I take the lttng-tools recipe which define PACKAGECONFIG ??= "lttng-ust" lttng-ust is not present in the end image. | 21:30 |
| *** wildwillie <wildwillie!50d98c5d@gateway/web/freenode/ip.80.217.140.93> has joined #yocto | 21:31 | |
| psrcode | I have to add PACKAGECONFIG += "lttng-ust" to a bbapend (lttng-tools) to see lttng-ust feature used | 21:31 |
| psrcode | is it because lttng-ust is not part of the "runtime dependencies" and only in the "build dependencies"? | 21:33 |
| wildwillie | Hi, Anyone here using RPI3 with Yocto? I have tried following : https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.html but I cannot get it generate the bootcode.bin. This whole workflow is very different from other stuff, like imx6 | 21:34 |
| RP | psrcode: PACKAGECONFIG is primarily about build time things | 21:36 |
| RP | psrcode: What would work here is to change the lttng-ust line to PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, lttng-ust, lttng-ust" | 21:38 |
| RP | psrcode: that 4th position in the PACKAGECONFIG entry adds to RDEPENDS | 21:38 |
| RP | psrcode: so then the lttng-tools package would depend on lttng-ust | 21:39 |
| RP | psrcode: normally we pick up rdepends through dynamic linking analysis but I guess lttng doesn't directly link to ust | 21:40 |
| psrcode | RP: based on the PACKAGECONFIG ??= line was it the intention to have lttng-ust by default? | 21:40 |
| RP | psrcode: I think so | 21:40 |
| psrcode | because lttng-tools can be built without lttng-ust | 21:40 |
| psrcode | if so this solve a big chunk of the ptest suite | 21:41 |
| RP | psrcode: ah, interesting. Yes, its being made configurable and turned on there | 21:41 |
| psrcode | still we do have a fuckup on our side regarding how we handle ust dependant tests | 21:41 |
| RP | psrcode: I guess we just never realised there wasn't a direct linkage to cause it to be pulled in | 21:42 |
| psrcode | I'm looking into adding the python agent option on lttng-ust so we can run the python agent test via lttng-tools, otherwise the ptest suite works all green | 21:42 |
| RP | psrcode: sounds great! :) | 21:43 |
| psrcode | RP: there was a couple missing dep for the tests and 1~2 fuckup on our side. I'll send you a RFC when I'm confident with the work. | 21:43 |
| psrcode | next step will be to have all this integrated in our CI to track stuff either from scratch or using report from your builder | 21:44 |
| RP | psrcode: FWIW our ptest builds do run lttng-tools-ptest at least on qemux86 | 22:02 |
| RP | psrcode: shows up on a-full builds: https://autobuilder.yocto.io/pub/non-release/20190228-9/testresults/testresult-report.txt | 22:03 |
| RP | lttng-tools | 4431 | 7 | 391 | 549 | 22:03 |
| RP | psrcode: we're actively working on improving our ptest handling and reporting | 22:04 |
| *** geissona_ <geissona_!~geissonat@32.97.110.57> has quit IRC | 22:15 | |
| *** geissona_ <geissona_!~geissonat@cpe-173-174-77-252.austin.res.rr.com> has joined #yocto | 22:41 | |
| *** justanotherboy <justanotherboy!~justanoth@THOUSAND-EY.bear1.Houston1.Level3.net> has quit IRC | 22:49 | |
| RP | jonmason: with my patch to change qemuarm to your a15 config, I find graphics doesn't work there either with the 5.0 kernel | 23:03 |
| jonmason | does the qemu command still include the VGA? | 23:04 |
| RP | jonmason: yes | 23:05 |
| jonmason | Can you send me the patch? I'll look in a VM | 23:09 |
| RP | jonmason: its in master-next | 23:10 |
| rburton | yates: add -lm to src/Makefile.am | 23:10 |
| RP | jonmason: it builds on top of you a15 one | 23:10 |
| jonmason | RP: ok, fetching now | 23:10 |
| rburton | yates: presumably guaded by if composite checks | 23:10 |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC | 23:10 | |
| *** vmeson <vmeson!~rmacleod@138.229.221.104> has joined #yocto | 23:18 | |
| *** neverpanic <neverpanic!~clemens@79.140.40.203> has quit IRC | 23:20 | |
| *** wildwillie <wildwillie!50d98c5d@gateway/web/freenode/ip.80.217.140.93> has quit IRC | 23:20 | |
| * RP -> Zzzz | 23:21 | |
| yates | rburton: yes, i just discovered that .. | 23:25 |
| yates | rburton: right now i'm modifying the Makefile in the workspace. how would i get that into the recipe? is src/Makefile.am in the recipe somewhere? | 23:26 |
| rburton | yates: no, its upstream. patch it | 23:26 |
| yates | by "upstream" do you mean in the git repo for matchbox-window-manager? | 23:27 |
| rburton | yes | 23:27 |
| yates | ah. | 23:27 |
| rburton | use devtool modify! | 23:27 |
| rburton | literally what its for | 23:27 |
| yates | oh. i thought you met to submit a patch to the git repo | 23:28 |
| rburton | that too | 23:28 |
| rburton | but you can generate it iwth devtool modify | 23:28 |
| rburton | when you have a working patch, send it in | 23:29 |
| yates | how did you know the problem was -lm?!? | 23:29 |
| yates | ok, right | 23:29 |
| rburton | | /Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/x86_64-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/6.2.0/ld: composite-engine.o: undefined reference to symbol 'exp@@GLIBC_2.4' | 23:30 |
| rburton | exp() is in libm.so | 23:30 |
| jonmason | RP: are you forcing the kernel to 5.0? | 23:30 |
| yates | ah | 23:30 |
| rburton | yates: man exp says "Link with -lm" | 23:31 |
| yates | rburton: src/Makefile.am uses several predefined variables such as LIBMB_LIBS. that is apparently defined in src/Makefile.in. but in src/Makefile.in it is defined as LIBMB_LIBS = @LIBMB_LIBS@. where does "@LIBMB_LIBS@" come from? | 23:37 |
| rburton | yates: configure.ac sets LIBMB_LIBS, most likely via a PKG_CHECK call | 23:38 |
| rburton | RP: the go 1.9 drop didn't drop the recipe | 23:38 |
| yates | and i should be modifying the git/src/... files with devtool, right? it will generate a .bbappends for those files, right? | 23:39 |
| rburton | honestly, don't know the workflow | 23:40 |
| rburton | rtm | 23:40 |
| bluelightning | yates: git/src ? | 23:40 |
| yates | yes..? | 23:40 |
| bluelightning | where exactly are the files you are talking about modifying?\ | 23:41 |
| yates | config.ac and/or Makefile.in | 23:41 |
| bluelightning | the path, I mean | 23:41 |
| yates | /sources/poky/build-hw-test-image/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/matchbox-wm/1.2.1-r0/git/ | 23:41 |
| yates | is that wrong? | 23:42 |
| rburton | yes | 23:42 |
| bluelightning | unless you specified that path (unlikely), devtool modify checks out the source to workspace/sources/<recipename> | 23:42 |
| rburton | there's a source tree in the devtool workspace | 23:42 |
| rburton | (read the manual) | 23:42 |
| yates | oh yeah... | 23:42 |
| yates | i knew this already.. | 23:42 |
| bluelightning | no worries :) | 23:42 |
| yates | it's late, i'm tired... | 23:43 |
| yates | is Makefile.in automatically generated from configure.ac? i.e, would it be pointless to modify Makefile.in? | 23:47 |
| Tartarus | RP: ugh, all those warnings for inetutils come from a specific oe-selftest? | 23:48 |
| yates | no, nm, | 23:48 |
| yates | stupid question | 23:48 |
| yates | configure.ac is the right file to modify, no? | 23:49 |
| rburton | right | 23:49 |
| rburton | makefile.am and configure.ac are the source files | 23:49 |
| *** stephano <stephano!~stephano@134.134.139.76> has quit IRC | 23:50 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:74e7:4b05:34cf:13e6> has joined #yocto | 23:56 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!