| *** Crofton|work <Crofton|work!~Crofton@38.90.133.135> has joined #yocto | 00:13 | |
| robbawebba | hello, quick question: Is it possible to determine the value of MACHINE for a running image on a target? Whether it's an environment variable, /etc file, or some other mechanism? | 00:29 |
|---|---|---|
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 00:37 | |
| *** sajjad_ <sajjad_!~sajjad@110.93.212.98> has joined #yocto | 00:54 | |
| *** xtron <xtron!~sajjad@110.93.212.98> has quit IRC | 00:56 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 01:03 | |
| *** nerdboy <nerdboy!~sarnold@gatekeeper.gentoogeek.org> has joined #yocto | 01:08 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 01:08 | |
| *** kaspter <kaspter!~Instantbi@115.204.110.243> has joined #yocto | 01:38 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto | 01:38 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC | 01:54 | |
| khem | robbawebba: these are build time variables, they do not have much bearings on real target when running but generally output of `hostname` is same as MACHINE | 01:54 |
| khem | but thats not hard and fast rule | 01:55 |
| *** sgw <sgw!~sgw@192.55.54.40> has quit IRC | 03:00 | |
| *** sgw <sgw!~sgw@192.55.54.40> has joined #yocto | 03:02 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto | 03:15 | |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC | 03:19 | |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC | 03:30 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC | 03:32 | |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto | 03:33 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 03:43 | |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 03:45 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto | 04:09 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC | 04:13 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC | 04:19 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto | 04:20 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 04:23 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC | 04:28 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 04:34 | |
| *** dreyna_ <dreyna_!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 04:36 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 04:55 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 04:58 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto | 05:03 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 05:12 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 05:15 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 05:19 | |
| *** hundeboll <hundeboll!~hundeboll@open-mesh.org/catwoman/hundeboll> has quit IRC | 05:35 | |
| *** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC | 05:35 | |
| *** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-lwfuxliqwjdgzeux> has quit IRC | 05:41 | |
| *** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-qxicyplcidouphsy> has joined #yocto | 05:43 | |
| *** suy <suy!~quassel@roger.badopi.com> has joined #yocto | 05:44 | |
| *** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has joined #yocto | 05:48 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 05:56 | |
| *** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC | 06:05 | |
| *** pouet_fo1 <pouet_fo1!~nico@213.56.200.5> has joined #yocto | 06:05 | |
| *** pouet_forever <pouet_forever!~nico@213.56.200.5> has quit IRC | 06:07 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto | 06:11 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has quit IRC | 06:21 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto | 06:22 | |
| *** seebs <seebs!~seebs@24.196.59.174> has quit IRC | 06:25 | |
| *** interruptguy <interruptguy!~interrupt@hel-inetgw01.vaisala.com> has joined #yocto | 06:28 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 06:32 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-duaqvoaxppasfvhn> has quit IRC | 06:40 | |
| *** seebs <seebs!~seebs@24.196.59.174> has joined #yocto | 07:09 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto | 07:22 | |
| *** gtristan <gtristan!~tristanva@110.11.179.72> has joined #yocto | 07:23 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC | 07:25 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto | 07:26 | |
| *** frsc <frsc!~frsc@200116b824720300da7f7100c571aab9.dip.versatel-1u1.de> has joined #yocto | 07:29 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 07:29 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC | 07:31 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto | 07:32 | |
| *** lusus <lusus!~lusus@62.91.23.180> has joined #yocto | 07:33 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:34 | |
| *** Carton__ <Carton__!~jo@193.134.219.72> has joined #yocto | 07:38 | |
| *** Carton__ <Carton__!~jo@193.134.219.72> has left #yocto | 07:40 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 07:40 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 07:41 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 07:54 | |
| *** fl0v0 <fl0v0!~fvo@mue-88-130-104-126.dsl.tropolys.de> has joined #yocto | 07:57 | |
| *** robertmarshall <robertmarshall!~robertmar@cpc126996-macc4-2-0-cust25.1-3.cable.virginm.net> has joined #yocto | 08:09 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 08:09 | |
| *** sagner <sagner!~ags@46.140.72.82> has joined #yocto | 08:11 | |
| pepijndevos | Alright, I'm back at it again... still trying to get a binary native package into my sysroot. Everything indicates this should be really easy, but nothing works. | 08:13 |
| *** pouet_fo1 <pouet_fo1!~nico@213.56.200.5> has quit IRC | 08:15 | |
| pepijndevos | I'm now trying ton install all the files in ${D}${datadir}, because datadir is in SYSROOT_DIRS. But nothing happens... | 08:16 |
| *** robertmarshall <robertmarshall!~robertmar@cpc126996-macc4-2-0-cust25.1-3.cable.virginm.net> has quit IRC | 08:16 | |
| *** pouet_forever <pouet_forever!~nico@213.56.200.5> has joined #yocto | 08:16 | |
| pepijndevos | It now installs into ./tmp/work/x86_64-linux/dds-native/5.3.1-r6/image/home/rove/code/poky/rpi-build/tmp/work/x86_64-linux/dds-native/5.3.1-r6/recipe-sysroot-native/usr/share/rti_connext_dds-5.3.1 | 08:17 |
| *** gtristan <gtristan!~tristanva@110.11.179.72> has quit IRC | 08:19 | |
| *** mckoan|away is now known as mckoan | 08:20 | |
| pepijndevos | Hmmm, getting closer | 08:26 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 08:31 | |
| *** interruptguy <interruptguy!~interrupt@hel-inetgw01.vaisala.com> has quit IRC | 08:35 | |
| *** interruptguy <interruptguy!~interrupt@hel-inetgw01.vaisala.com> has joined #yocto | 08:36 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has joined #yocto | 08:42 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 08:44 | |
| *** cvasilak <cvasilak!~cvasilak@ppp-94-66-25-27.home.otenet.gr> has joined #yocto | 08:48 | |
| pepijndevos | Ok, it kinda works. More details... | 08:50 |
| pepijndevos | Right now I symlink the binaries into bindir so they are found, and then I use readlink -f $(which rtipkginstall) to find their actual location so I can run them without failures. | 08:52 |
| *** kristoiv <kristoiv!~kristoiv@195.139.214.6> has joined #yocto | 08:59 | |
| pepijndevos | cool, this works nicer export NDDSHOME=${STAGING_DIR_NATIVE}/usr/share/rti_connext_dds-${PV} | 09:00 |
| *** anujm <anujm!~anujm@192.55.54.45> has joined #yocto | 09:01 | |
| *** cvasilak <cvasilak!~cvasilak@ppp-94-66-25-27.home.otenet.gr> has quit IRC | 09:02 | |
| pepijndevos | WARNING: dds-native-5.3.1-r6 do_populate_sysroot: File 'somebinary' from dds-native was already stripped, this will prevent future debugging! | 09:03 |
| *** cvasilak <cvasilak!~cvasilak@ppp-94-66-25-27.home.otenet.gr> has joined #yocto | 09:04 | |
| *** kristoiv <kristoiv!~kristoiv@195.139.214.6> has quit IRC | 09:06 | |
| *** kristoiv <kristoiv!~kristoiv@195.139.214.6> has joined #yocto | 09:08 | |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto | 09:10 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:11 | |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 09:12 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 09:12 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC | 09:17 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto | 09:18 | |
| *** rfried <rfried!~rfried@207.154.200.205> has left #yocto | 09:26 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC | 09:26 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto | 09:28 | |
| *** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC | 09:28 | |
| *** florian_kc is now known as floian | 09:30 | |
| *** floian is now known as florian | 09:30 | |
| T_UNIX | what's the supposed way to unset a `PREFERRED_PROVIDER`? | 09:31 |
| T_UNIX | s/supposed/recommended | 09:32 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:32 | |
| LetoThe2nd | T_UNIX: not setting it, in the first place. | 09:32 |
| T_UNIX | it's set by some `.inc` of another layer :-/ | 09:33 |
| LetoThe2nd | T_UNIX: does that sentence virtually continue with "... pulled in by a premade DISTRO or MACHINE i use"? | 09:33 |
| T_UNIX | more or less ;-D | 09:34 |
| LetoThe2nd | because in that very common case, your answer is: create a custom MACHIEN or DISTRO based off that one, and adjust it to your needs. | 09:34 |
| T_UNIX | that's what I already did | 09:34 |
| LetoThe2nd | then you're doing it wrong. | 09:35 |
| T_UNIX | I'm reusing that `.inc`, yet it's a single line that is "unwanted" | 09:35 |
| LetoThe2nd | then don't reuse it. if its in a layer you don't control, then you will run into troubles anyways if somebody updates it for reasons beyond your likings. | 09:36 |
| LetoThe2nd | copy it over to your layer, nail it down. | 09:36 |
| T_UNIX | that's what I do by using git. | 09:36 |
| T_UNIX | but I got your point | 09:36 |
| LetoThe2nd | well you asked for the recommended way :-) | 09:37 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:37 | |
| LetoThe2nd | the technically possible way is: overwrite it after the include. | 09:37 |
| T_UNIX | thank you :) | 09:37 |
| LetoThe2nd | but i explicitly discourage that. | 09:37 |
| T_UNIX | LetoThe2nd: yeah, that's what I just did. But I'll amend that to go the recommended way. | 09:37 |
| *** anujm <anujm!~anujm@192.55.54.45> has quit IRC | 09:39 | |
| *** kaspter <kaspter!~Instantbi@115.204.110.243> has quit IRC | 09:55 | |
| *** kaspter <kaspter!~Instantbi@115.204.110.243> has joined #yocto | 09:56 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 09:58 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 10:09 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 10:10 | |
| LetoThe2nd | has anybody here run into the situation that open() on target always aborts with EPERM, and doesn't even make to strace, while the same come works nicely on the dev host? usual reasons as uid tinkering and O_NOATIME flags don't apply. | 10:13 |
| rburton | well that sounds broken in a really special way | 10:13 |
| rburton | congrats | 10:13 |
| LetoThe2nd | hooray. :-( | 10:14 |
| LetoThe2nd | could at least kinda understand it if it was limited to a specific, maybe special filesystem. but it now fails always, even in tmpfs | 10:15 |
| rburton | how does *anyting* work if open() fails? | 10:15 |
| LetoThe2nd | rburton: the fun part is that the system seems to work fine. just my current dev task which i deploy through devtool fails. | 10:16 |
| *** kanavin <kanavin!~kanavin@62.96.135.139> has quit IRC | 10:24 | |
| *** kanavin <kanavin!~kanavin@62.96.135.139> has joined #yocto | 10:25 | |
| pepijndevos | can i somehow get the version of a dependency? | 10:26 |
| LetoThe2nd | pepijndevos: hum, whats the usecase? | 10:33 |
| *** kristoiv <kristoiv!~kristoiv@195.139.214.6> has quit IRC | 10:33 | |
| pepijndevos | LetoThe2nd, the package installed into somedir-<version>, so now I want to refer to that directory | 10:38 |
| LetoThe2nd | sounds like a broken install process. | 10:39 |
| *** berton <berton!~berton@181.220.65.91> has joined #yocto | 10:39 | |
| pepijndevos | well... it's a binary installer that you can give a prefix that it then adds its version number to. I guess I could manually rename it afterwards... | 10:40 |
| LetoThe2nd | i'd just symlink it to a known place. | 10:40 |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 10:43 | |
| *** berton <berton!~berton@181.220.65.91> has quit IRC | 10:43 | |
| *** berton <berton!~berton@181.220.65.91> has joined #yocto | 10:45 | |
| *** demonimin <demonimin!~demonimin@5.51.222.165> has joined #yocto | 10:46 | |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 10:46 | |
| pepijndevos | LetoThe2nd, everything breaks horribly when i do that. It's just horrible software I'm installing. | 10:48 |
| * LetoThe2nd shrugs. | 10:48 | |
| LetoThe2nd | i'd by now make a summary of your time wasted on that and present it to your supervisor. and get an absolutely explicit "ok, we're gonna waste lots of time there, but we totally want it, you're covered, and its not your fault" | 10:50 |
| pepijndevos | I'll just hardcode the version... | 10:51 |
| LetoThe2nd | i mean, this won't be the last fun time with that. | 10:51 |
| pepijndevos | For sure | 10:52 |
| rburton | can't you glob at the relevant place? | 10:52 |
| pepijndevos | I'l spare you the details of compiling this on android haha weeks of my life I'll never get back. | 10:52 |
| pepijndevos | Not sure... worth a shot (re glob) | 10:54 |
| *** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 10:55 | |
| pepijndevos | We already have the whole system working on RTI and Raspbian, so while we wait for the delivery of new hardware, I'm just trying to improve this hand-rolled Raspbian setup a bit. | 10:58 |
| *** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto | 10:59 | |
| LetoThe2nd | pepijndevos: i actually pitched a paper to a conf here, on why starting your iot development on raspi+raspbian is a stupid idea in the vast majority of cases :-P | 10:59 |
| pepijndevos | I'd love to share that with my supervisor haha | 11:00 |
| LetoThe2nd | pepijndevos: if they accept it, i'll share. its german, though. feel free to hire me for an english version :) | 11:01 |
| pepijndevos | s/iot/robots with rotating blades/ | 11:01 |
| LetoThe2nd | well its a iot conf, hence the concept. | 11:02 |
| LetoThe2nd | the core message actually should read like: "if you want a real product, do not start on a tinkering board using tinkering ways." | 11:03 |
| *** robertmarshall <robertmarshall!~robertmar@office.codethink.co.uk> has joined #yocto | 11:03 | |
| *** sajjad_ <sajjad_!~sajjad@110.93.212.98> has quit IRC | 11:06 | |
| *** xtron <xtron!~sajjad@110.93.212.98> has joined #yocto | 11:07 | |
| *** kristoiv <kristoiv!~kristoiv@195.139.214.6> has joined #yocto | 11:08 | |
| rburton | LetoThe2nd: or if you're going to prototype on a tinker board, be aware that is the one to throw away | 11:14 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:14 | |
| rburton | nothing wrong with prototyping, learning, throwing away and starting again | 11:14 |
| rburton | just be aware that is a valid plan and don't expect to go from tinker to production | 11:14 |
| LetoThe2nd | rburton: thats why its "if you want a product" | 11:15 |
| LetoThe2nd | its fine if you want a) fun b) a one-off thing c) a prototype... whatever | 11:15 |
| LetoThe2nd | but not, "a product" | 11:15 |
| rburton | i'd like to see this presentation in english :) | 11:17 |
| pepijndevos | I'm kind of working on a demo/protoype... but someone might say, hey this seems to work, lets put it in production... which will make me sad. | 11:21 |
| *** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC | 11:21 | |
| rburton | RP: overnight master passed selftest! | 11:21 |
| rburton | so clearly you broke it more with next | 11:22 |
| pepijndevos | meanwhile my recipe complains it's installing some directory that I have no idea where it comes from | 11:22 |
| RP | rburton: overnight master only runs on selftest, "full" runs five | 11:23 |
| RP | one | 11:23 |
| rburton | fake news | 11:23 |
| RP | rburton: gah, just dont, please ;-) | 11:24 |
| rburton | well the cpio thing replicated on debian so we can't call it a suse thing | 11:24 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 11:24 | |
| RP | rburton: and I ruled out files changing :/ | 11:24 |
| rburton | oh how did you do that? | 11:25 |
| RP | rburton: also the bitbake not starting replicated and the logs don't so anything so the new debugging didn't help :( | 11:25 |
| RP | rburton: I replied on list, have a a hacky patch: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c5787a6ddbfd2c1acc0e33fa158c238e6145351e | 11:25 |
| RP | but it proves the files don't change | 11:25 |
| rburton | you verified that code works right | 11:26 |
| LetoThe2nd | sorry for the halfway angry ML post, but that guy really is getting on my nerves. it was about time to vent. | 11:26 |
| * rburton runs to list | 11:26 | |
| LetoThe2nd | rburton: re presentation, throw money! | 11:26 |
| RP | rburton: patch has a foo.txt which shows it does | 11:27 |
| LetoThe2nd | hm actually, it would be interesting for an OE user summit. | 11:27 |
| pepijndevos | I'll read it in german | 11:27 |
| rburton | RP: ah, yes. i like that code, tidy it up and submit. lovely sanity test for dirs which shouldn't change. | 11:28 |
| *** robertmarshall is now known as rajm | 11:28 | |
| RP | LetoThe2nd: which list was this? I could do with something to cheer me up ;-) | 11:29 |
| RP | rburton: I wondered if we should make it a feature | 11:29 |
| rburton | RP: i wonder if any of the machines that cpio is crashing on have abort catchers on that are harvesting the cpio segfaults | 11:29 |
| pepijndevos | the recipe that used to work is now going from bad to worse for some reason... like... how did I get so in my -dev package -.- | 11:29 |
| LetoThe2nd | RP: yocto general | 11:29 |
| *** kanavin <kanavin!~kanavin@62.96.135.139> has quit IRC | 11:29 | |
| RP | rburton: I sadly doubt the core would be preserved | 11:29 |
| *** kristoiv_ <kristoiv_!~kristoiv@195.139.214.6> has joined #yocto | 11:29 | |
| *** kanavin <kanavin!~kanavin@62.96.135.139> has joined #yocto | 11:29 | |
| LetoThe2nd | RP: my cheering up now: lunch. | 11:30 |
| *** kristoiv <kristoiv!~kristoiv@195.139.214.6> has quit IRC | 11:32 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC | 11:35 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto | 11:42 | |
| rburton | RP: so the new parallel sefltest | 11:46 |
| rburton | RP: each test gets a new unique build directory right? | 11:46 |
| RP | rburton: each parallel process | 11:52 |
| rburton | so there are N build dirs for the level of parallelism and they are reused | 11:53 |
| RP | rburton: correct | 11:53 |
| RP | rburton: just realised that watchdir patch is bust, its not recursive :/ | 11:53 |
| rburton | race: you fix the test and i'll finish my directory churn hack! | 11:54 |
| * RP did however just figure out the mystery runqemu duplicate log messages, something that has bugged me for a long time | 11:54 | |
| *** toanju <toanju!~toanju@185.27.182.30> has joined #yocto | 11:54 | |
| RP | rburton: game on :) | 11:57 |
| RP | rburton: do_image does change files, nothing else showing up | 12:00 |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 12:03 | |
| RP | rburton: just needed an os.walk adding | 12:05 |
| rburton | well i have a cpio erroring out because files disappeared or changed, but not segfaulting | 12:06 |
| RP | rburton: which is more what you'd expect | 12:08 |
| RP | rburton: am I right in thinking we use cpio from the host for this? | 12:08 |
| rburton | i believe so | 12:09 |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 12:09 | |
| RP | cpio-native is required by testimage | 12:10 |
| rburton | yeah was just looking there | 12:10 |
| rburton | is that enabled during selftest though? | 12:10 |
| pepijndevos | I'm confused... | 12:12 |
| pepijndevos | -dev package contains non-symlink .so: dds-dev path '/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/dds/5.3.1-r1/packages-split/dds-dev/usr/lib/libnddscpp.so' | 12:12 |
| RP | rburton: It could have been installed by a previous test I guess | 12:13 |
| rburton | pepijndevos: most likely because this software shipped unversioned libraries | 12:13 |
| rburton | which is bad practise | 12:13 |
| rburton | pepijndevos: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries | 12:13 |
| pepijndevos | oooh, I remember that. Yea, this things is bad practice stacked on bad practice haha | 12:14 |
| rburton | RP: replicated on demand! | 12:17 |
| rburton | yeah its cpio-native | 12:17 |
| rburton | i wonder how we broke that! | 12:17 |
| rburton | RP: can you reproduce please? do_image_cpio[depends] += "cpio-native:do_populate_sysroot" to image_types, add cpio to IMAGE_FSTYPES, build something | 12:18 |
| rburton | i bet one of the cve patches we got actually broke cpio | 12:18 |
| rburton | shall grab a second coffee and sort | 12:19 |
| RP | rburton: oddly enough I couldn't get that to crash here | 12:19 |
| rburton | damnit | 12:19 |
| rburton | ok well i made it crash once, lets try again | 12:19 |
| rburton | and maybe i have a coredump to help | 12:19 |
| RP | rburton: I suspect its distro specific | 12:20 |
| RP | rburton: but anything reproducing is good | 12:20 |
| RP | rburton: I tried a couple of different ways and cpio-native works here (on ubuntu) | 12:21 |
| rburton | weird | 12:21 |
| RP | rburton: certainly bitbake XXX-image -c testimage in an earlier test would have put it in the sysroot and it wouldn't get removed | 12:22 |
| rburton | i wonder what the impact of a clean builddir per test will be :) | 12:22 |
| RP | rburton: huge amounts of sstate extraction | 12:23 |
| rburton | well, yeah | 12:24 |
| rburton | that's nice and fast :) | 12:24 |
| RP | breaking cpio would be an achievement | 12:25 |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has left #yocto | 12:27 | |
| rburton | yes | 12:28 |
| pepijndevos | Is there an easy way to figure out what to put in RDEPENDS to satisfy the QA errors I'm getting? Very common stuff like libc, libdl, libm, libstdc++ | 12:28 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 12:34 | |
| pepijndevos | https://paste.ubuntu.com/p/myjNQcx9tw/ | 12:36 |
| pepijndevos | I added RDEPENDS_${PN} = "libstdc++", but nothing changes. Is this also a problem with versioned .so? | 12:37 |
| *** guillaumekh <guillaumekh!5a5674df@gateway/web/freenode/ip.90.86.116.223> has joined #yocto | 12:37 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 12:38 | |
| *** ClmentAubin[m] <ClmentAubin[m]!caubinmatr@gateway/shell/matrix.org/x-pzliphslflolwmfv> has joined #yocto | 12:39 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 12:40 | |
| rburton | pepijndevos: hm it should have found those for you | 12:40 |
| rburton | RP: make it log more, stops segfaulting | 12:41 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 12:41 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has quit IRC | 12:41 | |
| guillaumekh | Mmmh how does one set ownership on a file during do_install ? I've tried using the user & group number (e.g `install -o 1000 -g 1000 -m 755 path/to/file) but file then shows up as owned by 0(root) | 12:42 |
| LetoThe2nd | guillaumekh: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb | 12:43 |
| pepijndevos | Oh... maybe I know... would it fail if the .so is not for the same architecture? Confession: because RTI disabled our Raspberry Pi target, I've been using the Android target for testing the basic recipe. Maybe this is where I actually just need the proper raspi files... | 12:43 |
| LetoThe2nd | pepijndevos: QA barfs if the arch does not match. not sure about the ABI, but i wouldn't rule it out. | 12:44 |
| *** kuzulis <kuzulis!~Denis@37.112.57.60> has joined #yocto | 12:45 | |
| pepijndevos | Another fun challenge down the road is that the rpi target is built with gcc 4.7 and C++11 so linking will break anyway until I solved that by either asking RTI for a new target, or changing yocto compiler flags or compiler version. | 12:48 |
| kuzulis | Hi guys. I want to upgrade my layers to new versions (e.g. to new branch sumo).. But now I have an troubles, like: ERROR: Nothing PROVIDES 'libgal-imx' ... Close matches: | 12:48 |
| kuzulis | libgxim | 12:48 |
| kuzulis | imx-gpu-viv RPROVIDES libgal-imx ... A full log here: https://pastebin.com/s8DNhyUC | 12:48 |
| kuzulis | How to solve this issue? | 12:48 |
| LetoThe2nd | kuzulis: find out why imx-gpu-viv is not buildable, by the looks of it. | 12:50 |
| pepijndevos | (yea, I hacked the recipe to copy my already installed Rpi target and that passes QA... so just keep begging RTI I guess) | 12:51 |
| kuzulis | LetoThe2nd: Do I need to add this 'imx-gpu-viv' recipe e.g to IMAGE_INSTALL_append ? | 12:54 |
| LetoThe2nd | kuzulis: no, dependencies should pull it in. the question is, why isn't it buildable (thats how i interpret it) | 12:55 |
| RP | rburton: but you can reproduce the segv? | 12:56 |
| yocti | New news from stackoverflow: How to flash Yocto Images directly using clonezilla <https://stackoverflow.com/questions/53519885/how-to-flash-yocto-images-directly-using-clonezilla> | 12:57 |
| kuzulis | LetoThe2nd: What commands I need to enter to search that? | 12:58 |
| pepijndevos | Aaaalmost there. My CMake project installs settings in etc, but these end up in /usr/etc and cause QA errors. | 12:58 |
| *** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto | 13:02 | |
| *** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto | 13:02 | |
| rburton | RP: sometimes | 13:02 |
| *** voidead26 <voidead26!~voidead@200.196.38.9> has joined #yocto | 13:02 | |
| pepijndevos | ah, solution: https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html | 13:04 |
| rburton | pepijndevos: yes please use that | 13:04 |
| kuzulis | LetoThe2nd: I have entered: bitbake-layers show-recipes | grep imx-gpu-viv and see that imx-gpu-viv is present.. | 13:05 |
| LetoThe2nd | kuzulis: look at the recipe if it has a COMPATIBLE_MACHINE or something like it | 13:06 |
| kuzulis | LetoThe2nd: I see COMPATIBLE_MACHINE = "(mx6q|mx6dl|mx6sx|mx6sl|mx7ulp)" | 13:07 |
| LetoThe2nd | kuzulis: and do you have one of those? | 13:07 |
| *** kaspter <kaspter!~Instantbi@115.204.110.243> has quit IRC | 13:09 | |
| *** kaspter <kaspter!~Instantbi@115.204.110.243> has joined #yocto | 13:10 | |
| kuzulis | LetoThe2nd: I use apalis-imx6 | 13:10 |
| LetoThe2nd | kuzulis: well then, theres your answer. | 13:10 |
| LetoThe2nd | append it and add that to the compatible machines | 13:11 |
| kuzulis | LetoThe2nd: Hmm.. but for previous layes version, same recipe 'imx-gpu-viv' contains similar COMPATIBLE_MACHINE = "(mx6q|mx6dl|mx6sx|mx6sl)" ... And it does work. | 13:15 |
| kuzulis | LetoThe2nd: Where apalis-imx5.conf machine has following text: MACHINEOVERRIDES =. "mx6:mx6q:" | 13:17 |
| kuzulis | LetoThe2nd: s/apalis-imx5/apalis-imx6 | 13:17 |
| LetoThe2nd | kuzulis: ok, at the point its beyond my knowledge, sorry. | 13:18 |
| kuzulis | So, nobody can help ? :( | 13:19 |
| *** cquast <cquast!~cquast@90.85.130.193> has joined #yocto | 13:37 | |
| T_UNIX | kuzulis: the `OVERRIDES` variables describe which variables' priority. Read the documentation on it :) | 13:40 |
| T_UNIX | s/which// | 13:41 |
| pepijndevos | I have a few robots that have slightly different software. Should those be their own layer or just recipes and different images? | 13:42 |
| T_UNIX | kuzulis: then examine the output of `bitbake -e imx-gpu-viv`. Look at the evaluation of `COMPATIBLE_MACHINE`. | 13:42 |
| T_UNIX | pepijndevos: depends on how they differ. Devicetree? Kernel? Single Binaries? The way something is compiled? Image? | 13:44 |
| kuzulis | T_UNIX: bitbake -e imx-gpu-viv | grep ^COMPATIBLE_MACHINE shows that it is: COMPATIBLE_MACHINE="(mx6q|mx6dl|mx6sx|mx6sl|mx7ulp)" | 13:47 |
| pepijndevos | T_UNIX, just one different package and its deps. One uses wiringpi, one something else. | 13:48 |
| kuzulis | T_UNIX: That is correct for apalis-imx6, because apalis-imx6 is same as "mx6:mx6q:" | 13:48 |
| yates | rburton: was your intention (i.e.., with binconfig_xyz) that all crossscripts would be placed in the /usr/bin/crossscript folder and that folder would be in the path, and that the proper "version" of the script (whether cross build or target build) is placed in that folder for staging or packaging, respectively? | 13:50 |
| T_UNIX | kuzulis: and that matches the `PACKAGE-ARCHITECTURE` (cannot recall the precise variable name)? | 13:50 |
| T_UNIX | pepijndevos: if each software would technically be compatible with any machine, use a different image | 13:51 |
| yates | respectively | 13:52 |
| kuzulis | T_UNIX: Where is PACKAGE-ARCHITECTURE ? | 13:52 |
| T_UNIX | kuzulis: In the package's recipe | 13:53 |
| T_UNIX | it's called `PACKAGE_ARCH` | 13:53 |
| yates | or did you intend to put relative symlinks to each script in /usr/bin, so that they work no matter where /usr/bin/crossscript is located, and the PATH can remain standard? | 13:54 |
| yates | or something else? ;) | 13:55 |
| kuzulis | T_UNIX: There are no PACKAGE_ARCH, in that *.bb file | 13:56 |
| kuzulis | T_UNIX: (nor in new layer branch, nor in previous layer branch) | 13:58 |
| pepijndevos | cool thanks | 13:59 |
| T_UNIX | kuzulis: examine the output of `bitbake -e imx-gpu-viv`. It could be in some `.inc`, some `.bbappend` or in some distribution/machine configuration. | 13:59 |
| *** maudat <maudat!~moda@64.18.88.250> has quit IRC | 14:02 | |
| kuzulis | T_UNIX: bitbake -e imx-gpu-viv | grep PACKAGE-ARCH has an empty output | 14:02 |
| kuzulis | T_UNIX: oops, sorry | 14:03 |
| T_UNIX | kuzulis: what does `bitbake imx-gpu-viv` complain about? Maybe examine the entire output instead of greping for partial words that might be incorrect? | 14:03 |
| kuzulis | T_UNIX: PACKAGE_ARCH="cortexa9hf-neon-mx6qdl" | 14:03 |
| kuzulis | PACKAGE_ARCHS="all any noarch armv5hf-vfp armv5thf-vfp armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7ahf-vfp armv7at2hf-vfp armv7ahf-neon armv7at2hf-neon cortexa9hf-vfp cortexa9hf-neon cortexa9t2hf-vfp cortexa9t2hf-neon cortexa9hf-neon-mx6qdl cortexa9t2hf-neon-mx6qdl apalis_imx6" | 14:03 |
| yates | anyone? | 14:04 |
| yates | is the sysroot for a build under ${B}? | 14:05 |
| derRichard | is it known that gpgme does not build? (sumo) | 14:05 |
| derRichard | the configure script does not find libgpg-error | 14:05 |
| RP | derRichard: it definitely builds on the autobuilder | 14:06 |
| derRichard | RP: hmm. | 14:07 |
| derRichard | just tried with both arm and x86 targets | 14:07 |
| yates | derRichard: does the gpgme recipe have libgpg-error (or some recipe providing it) in its DEPENDS? | 14:07 |
| derRichard | yates: yes, it does. | 14:08 |
| kuzulis | T_UNIX: Any other suggestions? :) | 14:08 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 14:08 | |
| *** marka <marka!~masselst@184.175.21.100> has joined #yocto | 14:09 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 14:09 | |
| T_UNIX | as I said: `bitbake imx-gpu-viv` look why it fails. Does it fail? | 14:09 |
| RP | derRichard: What changes do you have on top of standard sumo? | 14:09 |
| *** interruptguy <interruptguy!~interrupt@hel-inetgw01.vaisala.com> has quit IRC | 14:10 | |
| derRichard | RP: just my layer. i didn't change gpgme at all | 14:10 |
| *** iokill <iokill!~dave@94.130.105.16> has joined #yocto | 14:11 | |
| derRichard | let me read the config.og | 14:11 |
| derRichard | *config.log | 14:11 |
| derRichard | maybe the configure script is just stupid and the root cause is something different | 14:12 |
| RP | derRichard: we do disable a lot of the gnupg -config scripts and differ from upstream there but it should autoreconf and handle that, we do test it on the autobuilders | 14:12 |
| derRichard | configure:22254: $PKG_CONFIG --exists --print-errors "gpg-error >= $min_gpg_error_version" | 14:13 |
| derRichard | Requested 'gpg-error >= 1.24' but version of gpg-error is 1.18 | 14:14 |
| derRichard | now things get interesting | 14:14 |
| derRichard | hmm, makes no sense | 14:14 |
| * derRichard checks layers again | 14:14 | |
| derRichard | meh, somebody copied an old gpg-error recipe into the customer's layer | 14:16 |
| yates | yates: it depends on yocto version. for morty, it is not, it is under ${TMPDIR}/sysroots | 14:16 |
| RP | derRichard: that would explain it | 14:20 |
| derRichard | RP: yes :-( | 14:21 |
| * derRichard needs to review that layer | 14:21 | |
| *** Crofton|work <Crofton|work!~Crofton@38.90.133.135> has quit IRC | 14:25 | |
| *** toanju <toanju!~toanju@185.27.182.30> has quit IRC | 14:35 | |
| kuzulis | T_UNIX: > `bitbake imx-gpu-viv` look why it fails. Does it fail? | 14:36 |
| kuzulis | T_UNIX: It compiles successfully | 14:36 |
| kuzulis | T_UNIX: It fails only then I build image: | 14:36 |
| kuzulis | ERROR: Nothing PROVIDES 'libgal-imx' (but /mnt/data/Yocto-miatech/yocto-miatech/sources/meta-freescale/recipes-graphics/xorg-driver/xf86-video-imx-vivante_6.2.4.p1.2.bb DEPENDS on or otherwise requires it). Close matches: | 14:36 |
| kuzulis | libgxim | 14:36 |
| kuzulis | imx-gpu-viv RPROVIDES libgal-imx | 14:36 |
| kuzulis | wtf? | 14:37 |
| LetoThe2nd | kuzulis: PROVIDES != RPROVIDES | 14:37 |
| T_UNIX | RPROVIDES vs. PROVIDES | 14:37 |
| LetoThe2nd | kuzulis: sounds like somewhere the dependency structure was modified | 14:37 |
| T_UNIX | R(UNTIME)PROVIDES vs PROVIDES | 14:37 |
| kuzulis | and? what I need to do here? :) | 14:39 |
| kuzulis | I did not change anything | 14:39 |
| *** Zajc <Zajc!~Zajc@89-212-111-208.static.t-2.net> has quit IRC | 14:39 | |
| kuzulis | I just update a layers from pyro to sumo | 14:39 |
| LetoThe2nd | kuzulis: if i had to guess, then i'd say that you only updated one or a couple of your layers in use, but not all of them | 14:40 |
| kuzulis | LetoThe2nd: I have updated all layers, exclude qt4/5 layers: https://pastebin.com/5a9mF36B | 14:42 |
| LetoThe2nd | kuzulis: heh its nice that you show such detailed information, but i actually do not know by just looking at git commit hashes which states of the layers those are. | 14:44 |
| *** kaspter <kaspter!~Instantbi@115.204.110.243> has quit IRC | 14:44 | |
| *** kaspter <kaspter!~Instantbi@115.204.110.243> has joined #yocto | 14:45 | |
| kuzulis | LetoThe2nd: I taked this hashes from: http://code.qt.io/cgit/yocto/meta-boot2qt.git/tree/scripts/manifest.xml?h=sumo | 14:46 |
| kuzulis | LetoThe2nd: I hope that that a true hashes :) | 14:47 |
| LetoThe2nd | kuzulis: sorry, i'll actually not dig there further. i'm just saying, something obviously first DEPENDED in it, and it PROVIDES. thats ok. now it changed from PROVIDES to RPROVIDES, but the recipe that DEPENDed did not change. so, thats where you have to go hunting. | 14:48 |
| kuzulis | LetoThe2nd: Ohhh.. many thanks, anyway :( | 14:53 |
| kuzulis | LetoThe2nd: Then, is any workariunds for this, witchout of modifing os a source layers (not my layers)? | 14:55 |
| LetoThe2nd | kuzulis: that would be then reporting to upstream. | 14:55 |
| *** armpit <armpit!~armpit@174-24-96-92.clsp.qwest.net> has quit IRC | 14:56 | |
| *** Crofton|work <Crofton|work!~Crofton@23-25-123-169-static.hfc.comcastbusiness.net> has joined #yocto | 14:57 | |
| *** armpit <armpit!~armpit@174-24-96-92.clsp.qwest.net> has joined #yocto | 14:58 | |
| kuzulis | LetoThe2nd: Nono, I mean, is it possible to fix it without of modifing of a provided (not my) layers? | 14:59 |
| kuzulis | LetoThe2nd: to do not touch that layers? | 14:59 |
| LetoThe2nd | kuzulis: can definitively say. but probably no. | 14:59 |
| LetoThe2nd | s/can/can't/ | 15:00 |
| *** JaMa <JaMa!~martin@217.30.68.212> has joined #yocto | 15:03 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has quit IRC | 15:03 | |
| kuzulis | LetoThe2nd: I see in latest imx-gpu-viv*.inc file this: | 15:05 |
| kuzulis | PROVIDES += " \ | 15:05 |
| kuzulis | imx-gpu-viv \ | 15:05 |
| kuzulis | and: | 15:05 |
| kuzulis | RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv" | 15:05 |
| *** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC | 15:06 | |
| kuzulis | LetoThe2nd: Ahh, sorry, I see: RPROVIDES_libgal-imx += "libgal-imx" | 15:09 |
| *** Zajc <Zajc!~Zajc@89-212-111-208.static.t-2.net> has joined #yocto | 15:09 | |
| kuzulis | LetoThe2nd: but when I see to previous 'imx-gpu-viv*.inc' file, then there are no any mentions of 'libgal-imx' | 15:11 |
| *** no_such_user <no_such_user!~no_such_u@fpc125996-trow7-2-0-cust59.18-1.static.cable.virginm.net> has joined #yocto | 15:16 | |
| kuzulis | LetoThe2nd: Hmm... no... I'm confused.. I see that a newest 'imx-gpu-viv*.inc' file contains: PROVIDES += " \ | 15:16 |
| kuzulis | imx-gpu-viv \ | 15:16 |
| kuzulis | libgal-imx \ | 15:16 |
| kuzulis | but why bitbake say that " Nothing PROVIDES 'libgal-imx' " ? | 15:17 |
| kuzulis | LetoThe2nd: Also this file contains and: RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv" | 15:20 |
| kuzulis | LetoThe2nd: So, maybe I need to remove this RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv" ? | 15:21 |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC | 15:23 | |
| yates | i'm baffled | 15:35 |
| *** alpha <alpha!~alpha@cpc112681-nmal22-2-0-cust726.19-2.cable.virginm.net> has joined #yocto | 15:36 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:39 | |
| yates | nm, ok, i'm good | 15:41 |
| pepijndevos | Yeaaah. Linking errors due to ABI changes in C++11 between gcc 4.x and 5.x. Until RTI comes up with a newer target, my options are basically: make everything that depends on RTI use _GLIBCXX_USE_CXX11_ABI or compile them with gcc 4.x | 15:44 |
| *** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto | 15:45 | |
| pepijndevos | Will poky be fine if I just do GCCVERSION="4.7.%" in local.conf or is that too ancient? And is there an easy way to pass _GLIBCXX_USE_CXX11_ABI from the (cmake) recipe? | 15:48 |
| LetoThe2nd | pepijndevos: it will do, if a recipe actually provides that version | 15:49 |
| pepijndevos | Seems like poky itself only has 8.2 and 7.3. Neeever mind then. I'll go the _GLIBCXX_USE_CXX11_ABI route. Or just do nothing and wait for RTI, they already told me that they have a newer target, they just haven't given it to me yet. | 15:51 |
| *** cvasilak <cvasilak!~cvasilak@ppp-94-66-25-27.home.otenet.gr> has quit IRC | 15:53 | |
| yates | why does specifying the -pthread option to a gcc link error out? | 15:54 |
| yates | https://paste.fedoraproject.org/paste/1nFOMkt0yTNc3ziqNJ8enQ | 15:54 |
| yates | correction: a g++ link | 15:55 |
| georgem | well, something looks messed up because it's looking in the wrong path | 15:55 |
| yates | if i omit the -pthread option and just use -lpthread, it works fine | 15:56 |
| georgem | could be a toolchain problem | 15:57 |
| yocti | New news from stackoverflow: am335x evmsk screen init:id"00" respawning too fast disabled for 5 minutes yocto sumo <https://stackoverflow.com/questions/53523039/am335x-evmsk-screen-initid00-respawning-too-fast-disabled-for-5-minutes-yocto> | 15:57 |
| *** armpit <armpit!~armpit@174-24-96-92.clsp.qwest.net> has quit IRC | 16:03 | |
| *** lazyape <lazyape!~lazyape@athedsl-4549662.home.otenet.gr> has quit IRC | 16:10 | |
| *** lazyape <lazyape!~lazyape@athedsl-4549662.home.otenet.gr> has joined #yocto | 16:10 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 16:11 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 16:12 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 16:14 | |
| *** pouet_forever <pouet_forever!~nico@213.56.200.5> has quit IRC | 16:14 | |
| *** kristoiv_ <kristoiv_!~kristoiv@195.139.214.6> has quit IRC | 16:15 | |
| *** kuzulis_ <kuzulis_!~Denis@176.212.101.42> has joined #yocto | 16:16 | |
| *** kuzulis_ <kuzulis_!~Denis@176.212.101.42> has quit IRC | 16:19 | |
| *** kuzulis <kuzulis!~Denis@37.112.57.60> has quit IRC | 16:20 | |
| yates | right. thanks georgem | 16:20 |
| *** rajm <rajm!~robertmar@office.codethink.co.uk> has quit IRC | 16:44 | |
| *** yann <yann!~yann@lfbn-1-3228-112.w90-79.abo.wanadoo.fr> has joined #yocto | 16:47 | |
| yates | what is the difference between the sysroot-destdir, build, and image subdirectories under <build>/tmp/work/<arch>/${PN}/${PV}-${PR} ? | 16:48 |
| yates | obviously build is when building the recipe. what about the others | 16:49 |
| yates | at what stage in the build process are the others used? | 16:50 |
| aehs29 | rburton: I sent some patches to the python manifest to add comments last week, is there a reason why they haven't been merged yet?, I havent seen them in your contrib branches either, thats why I ask | 16:50 |
| *** lusus <lusus!~lusus@62.91.23.180> has quit IRC | 16:53 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:56 | |
| T_UNIX | damn. `COPY_LIC_DIRS`. somhow broke when I removed a package that used to be a PREFERRED_PROVIDER. For some reason bitbake still wants to handle its license :-/ | 17:05 |
| *** kristoiv <kristoiv!~kristoiv@245.90-149-61.nextgentel.com> has joined #yocto | 17:06 | |
| *** fl0v0 <fl0v0!~fvo@mue-88-130-104-126.dsl.tropolys.de> has quit IRC | 17:06 | |
| T_UNIX | I mean I even `BBMASK`ed the file/package that is now apparently - according to `license.bbclass`' `license_create_manifest`- missing. | 17:08 |
| *** alpha <alpha!~alpha@cpc112681-nmal22-2-0-cust726.19-2.cable.virginm.net> has quit IRC | 17:14 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 17:16 | |
| *** kristoiv <kristoiv!~kristoiv@245.90-149-61.nextgentel.com> has quit IRC | 17:16 | |
| T_UNIX | it somehow comes up witht that via `runtime-reverse/$NOLONGEREXISTINGPACKAGE` | 17:16 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 17:21 | |
| rburton | aehs29: probably forgot to tag them | 17:22 |
| rburton | aehs29: will sort | 17:22 |
| rburton | yates: image is used when building a package too | 17:22 |
| rburton | yates: build/ is the build tree for out-of-tree buids | 17:22 |
| rburton | yates: image/ is where install installs too | 17:23 |
| rburton | sysroot-destdir is the bits from image that are for the sysroot | 17:23 |
| rburton | then there's package/ which is the bits from image for the packages | 17:23 |
| rburton | and then packages-split which is package, but split per-package | 17:23 |
| rburton | (grep can tell you this if you search for ${WORKDIR}/image, etc) | 17:23 |
| rburton | over meta/classes/ | 17:23 |
| T_UNIX | where does that `ipk/` package management get its information from? How does it build its store? | 17:26 |
| *** clementben <clementben!~clementbe@lneuilly-657-1-4-190.w81-250.abo.wanadoo.fr> has joined #yocto | 17:28 | |
| *** clementben is now known as clement_ | 17:28 | |
| *** clement_ is now known as clement__ | 17:28 | |
| *** clement__ is now known as clementben | 17:28 | |
| T_UNIX | that was the culprit: obsolete packages in `deploy/ipk` lead to them retroactively corrupting the build | 17:30 |
| *** stephano <stephano!stephano@nat/intel/x-tghrxmrudbhaoieu> has joined #yocto | 17:46 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 17:46 | |
| *** frsc <frsc!~frsc@200116b824720300da7f7100c571aab9.dip.versatel-1u1.de> has quit IRC | 17:58 | |
| *** sagner <sagner!~ags@46.140.72.82> has quit IRC | 18:00 | |
| *** rewitt1 <rewitt1!~rewitt@134.134.139.76> has joined #yocto | 18:02 | |
| *** moto-tim1 <moto-tim1!~ttorling@134.134.139.72> has joined #yocto | 18:02 | |
| *** rewitt <rewitt!~rewitt@134.134.139.76> has quit IRC | 18:02 | |
| *** moto-timo <moto-timo!ttorling@fsf/member/moto-timo> has quit IRC | 18:02 | |
| yates | i can see a library (namely, libwx_gtk2u_aui-3.0-arm-fslc-linux-gnueabi.so) under <build>/tmp/sysroots/<macharch>/usr/lib, but my link is not finding ti | 18:08 |
| yates | | /opt/fslc-x11/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/7.2.0/real-ld: cannot find -lwx_gtk2u_aui-3.0-arm-fslc-linux-gnueab | 18:09 |
| yates | do i need a special -L<path>? | 18:09 |
| yates | ah, ok, thanks rburton | 18:10 |
| *** scottrif <scottrif!~scottrif@47-40-108-60.dhcp.knwc.wa.charter.com> has joined #yocto | 18:11 | |
| *** dmoseley <dmoseley!~dmoseley@072-184-106-074.res.spectrum.com> has quit IRC | 18:11 | |
| *** dmoseley <dmoseley!~dmoseley@072-184-106-074.res.spectrum.com> has joined #yocto | 18:12 | |
| *** JSwede <JSwede!51aaf86c@gateway/web/freenode/ip.81.170.248.108> has joined #yocto | 18:15 | |
| *** armpit <armpit!~armpit@67.133.97.101> has joined #yocto | 18:22 | |
| *** kanavin_home <kanavin_home!~ak@ip5f5bf106.dynamic.kabel-deutschland.de> has quit IRC | 18:22 | |
| *** mckoan is now known as mckoan|away | 18:23 | |
| *** xtron1 <xtron1!~xtron@103.255.4.247> has joined #yocto | 18:24 | |
| JSwede | Hi. I have created a custom layer, and created a bbappends file that points to a configuration fragment (at least according to my understanding). In my case the configuration fragment only contains one line: "CONFIG_TUN=y". Is there a way to check that the build successfully added this line to the kernel config without actually flashing the image to a real board (since I do not have the hardware where I currently am)? | 18:24 |
| *** kanavin_home <kanavin_home!~ak@ip5f5bf106.dynamic.kabel-deutschland.de> has joined #yocto | 18:25 | |
| *** cquast <cquast!~cquast@90.85.130.193> has quit IRC | 18:28 | |
| *** apteryx <apteryx!~maxim@45.72.138.75> has quit IRC | 18:29 | |
| aehs29 | JSwede: what do you mean by "points to" | 18:31 |
| yates | in general, if a recipe DEPENDS on a library, will the link (ld) command for the recipe need to specify a special path to the library via a -L<libpath> option? | 18:31 |
| aehs29 | JSwede: easiest way would probably be to check the kernel build directory and open the .config, if the config is there, then youre golden | 18:31 |
| aehs29 | JSwede: just fyi if its not there it does not necessarily mean that your bbappend isnt "pointing" to it correctly, there could be dependency issues or something | 18:32 |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 18:32 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 18:33 | |
| aehs29 | yates: the linker should be able to pick them up automatically | 18:33 |
| yates | JSwede: what aehs29 said. so that your files are kept after building, it may be helpful to use devtool | 18:33 |
| *** dv_ <dv_!~dv@62.178.50.190> has quit IRC | 18:33 | |
| yates | aehs29: ok, well it's not! :( | 18:34 |
| yates | i think i know why though | 18:35 |
| aehs29 | yates: ideally, it should | 18:35 |
| yates | i'm specifying a -sysroot in my link command | 18:35 |
| aehs29 | yates: well that would change where the linker is looking for it, the -sysroot parameter should also be populated automaticlaly | 18:36 |
| JSwede | aehs29: If I look in workspace/<project>/tmp/work/<abi dir>/<kernel>/<version>/ the config file is there and it contains CONFIG_TUN=y just as it should. Then I guess I'm all set :) Thanks! | 18:36 |
| aehs29 | JSwede: I think youre still missing a directory "linux-build-something", the .config file should be in there | 18:37 |
| aehs29 | JSwede: just make sure youre looking at the final .config | 18:37 |
| *** labelette14 <labelette14!~labelette@156.223.245.195> has joined #yocto | 18:38 | |
| JSwede | aehs29: ... Ah, maybe I misunderstood. I am not looking at a complete .config file. And now the server was shut down for me so I can't check anything else today. I will give it another shot tomorrow. | 18:38 |
| aehs29 | yates: addind --verbose to the ld command should help you figuring out where its looking for the libraries | 18:39 |
| aehs29 | JSwede: sure, but yes, it should be a complete .config | 18:40 |
| JSwede | aehs29: thanks, then I won't have to sit idle tomorrow :) | 18:41 |
| *** JSwede <JSwede!51aaf86c@gateway/web/freenode/ip.81.170.248.108> has quit IRC | 18:42 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 18:48 | |
| *** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC | 18:53 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 18:57 | |
| *** ant_home <ant_home!~ant__@host55-101-dynamic.58-82-r.retail.telecomitalia.it> has joined #yocto | 19:00 | |
| *** armpit <armpit!~armpit@67.133.97.101> has quit IRC | 19:08 | |
| *** yann <yann!~yann@lfbn-1-3228-112.w90-79.abo.wanadoo.fr> has quit IRC | 19:10 | |
| yates | when does yocto build the cross-toolchain? does it happen automatically when the first recipe is built? | 19:10 |
| yates | yates: yes | 19:18 |
| yates | ok, and where does that toolchain reside? | 19:19 |
| aehs29 | yates: yes, the native and cross toolchain tasks are executed by the runqueue before due to their dependencies, and they reside in the sysroot | 19:20 |
| yates | from the overivew and concepts manual, section 2.7: During a build process, the build system tracks dependencies and performs a native or cross-compilation of the package. As a first step in a cross-build setup, the framework attempts to create a cross-compiler toolchain (i.e. Extensible SDK) suited for the target platform. | 19:20 |
| yates | aehs29: ok, thanks | 19:20 |
| *** toanju <toanju!~toanju@x5ce35ffb.dyn.telefonica.de> has joined #yocto | 19:26 | |
| yates | aehs29: is the proper sysroot specified via the environment variable SYSROOT? | 19:28 |
| yates | i'm using my own custom makefiles and am getitng wrapped around the axle a bit here | 19:29 |
| kergoth | yates: 'first recipe' isn't relevant, it's all based on dependencies. base.bbclass specifies the defualt deps on the cross toolchain via BASEDEPENDS, unless opted out with INHIBIT_DEFAULT_DEPS or inheriting a class that does the same, like native | 19:31 |
| *** gtristan <gtristan!~tristanva@110.11.179.2> has joined #yocto | 19:41 | |
| *** xtron1 <xtron1!~xtron@103.255.4.247> has quit IRC | 19:46 | |
| aehs29 | yates: I think thats probably why you're having issues with the --sysroot parameter to gcc, the Makefile needs to use what it gets from the build system, you can look at the variables such as CC , CFLAGS or LDFLAGS if you open the run.do_compile script inside the temp directory which is inside the work directory for your recipe, if you look at CC for example it already should have a --sysroot parameter | 19:47 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-kxhlnngqtcxfndmj> has quit IRC | 19:48 | |
| robbawebba | khem: Thanks for your suggestion about hostame for determining MACHINE at image runtime! One more robust solution that I could think of is to create a recipe that adds the value of MACHINE to a file in the rootfs, such as /etc/machine/ | 20:01 |
| khem | I think /etc/os-release might be for it | 20:02 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 20:15 | |
| *** berton <berton!~berton@181.220.65.91> has quit IRC | 20:17 | |
| *** yann <yann!~yann@lfbn-1-515-227.w86-245.abo.wanadoo.fr> has joined #yocto | 20:30 | |
| yates | rburton: i see in the wx-config script where your binconfig_package_preprocess() performed this substitution: -e 's:${STAGING_LIBDIR}:${libdir}:g;' | 20:35 |
| yates | this was the <libpath> on a line in wx-config that issued a -L<libpath> when generating library configuration info | 20:36 |
| yates | nm. i thought it was creating an error there, but i think not. | 20:37 |
| yates | well, let me continue.. | 20:38 |
| yates | with that -L${libdir}, a subsequent recipe build that DEPENDS on wxwidgets errors out at the link stage: | /opt/fslc-x11/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/7.2.0/real-ld: cannot find /lib/libpthread.so.0 | 20:39 |
| kergoth | -L${libdir} in a target recipe is going to lead to pain, as that'll reference files on the host. it's also just plain redundant, as that's in the default search path | 20:40 |
| kergoth | just drop it entirely | 20:40 |
| yates | kergoth: already tried that | 20:40 |
| kergoth | and this sort of thing is precisely the type of pain rburton warned you you'd run into trying to use a -config script, and is why binconfig.bbclass exists | 20:40 |
| kergoth | :) | 20:40 |
| yates | well i have to deal with it someway. | 20:41 |
| yates | if i remove the -L, several the libraries wxwidgets DEPENDS on are not found | 20:41 |
| yates | speaking of just the compiler/linker operation, shouldn't a "-L" _append_ the path to the existing search paths/ | 20:43 |
| yates | ? | 20:43 |
| yates | another unrelated recipe i wrote also issues a -lpthread and it gets resolved just fine. works. | 20:44 |
| yates | so the sdk has the pthread library, why isn't it finding it with a -L? | 20:45 |
| yates | if the -lpthread occurs AFTER the -L<libpath>, does that limit the compiler to search for it JUST IN THAT <libpath>? | 20:46 |
| yates | that's what it's acting like. | 20:46 |
| yates | kergoth: i am using the binconfig.bbclass. i'm not sure if you were intimating i disabled it. | 20:47 |
| kergoth | no, it doesn't, but pthread is special. /usr/lib/libpthread.so, iirc, is generally a linker script | 20:48 |
| kergoth | if it loads the host one, it'll go directly to /lib rather than a path relative to the location of the .so | 20:48 |
| yates | kergoth: i don't understand your point. special or not, if one of my recipes with a -lpthread works, why wouldn't this one? | 20:53 |
| kergoth | I just told you, if /usr/lib is in the search path, it'll grab the .so from there first and break | 20:53 |
| kergoth | it doesn't limit to only that path, but the result is the same, as it grabs the first one it finds | 20:53 |
| kergoth | you can't include host paths in the library esarch path when crosscompiling | 20:54 |
| yates | why would /usr/lib be in the search path? | 20:54 |
| kergoth | i don't understand the question. | 20:55 |
| kergoth | libdir by definition is the path in the target rootfs where the libs get installed. in non-native recipes, that's ${prefix}/lib, aka /usr/lib | 20:56 |
| * kergoth shrugs, gets back to work | 20:56 | |
| yates | kergoth: you said "if /usr/lib is in the search path". so i asked why would that happen? in a cross build, you should be using another sysroot, right? | 20:57 |
| yates | more specifically, why would the search path in one of my recipes NOT contain /usr/lib, yet another recipe DOES contain /usr/lib. when the recipes are structured the same with the exception of this -L? | 20:58 |
| kergoth | no, —sysroot affects default paths only, you can specify -I/-L paths to be relative to sysroot by prefixing with =, otherise they're interpreted as absolute paths, not paths relative to the sysroot. | 20:58 |
| kergoth | see also https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html | 20:58 |
| kergoth | afaik, anyway | 20:58 |
| yates | ok, let me check that. | 20:59 |
| yates | both recipes contain a -lpthread | 20:59 |
| kergoth | -L/usr/lib is referencing a host path, not a path relative to the sysroot, and the host's libpthread.so hasn't been fixed up the way ours has | 21:00 |
| yates | but that's not where my -L is pointing: -L/Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/imx6ul-var-dart/usr/lib | 21:01 |
| kergoth | that's the most likely cause, anyway, as far as I can tell. could be missing something, but i'd eliminate that before digging elsewhere | 21:01 |
| kergoth | then something has adjusted it back to STAGING_LIBDIR, don't see a problem with that, but if ithat's the case i'd check the actual libpthread.so it's linking against to ensure it's sane | 21:02 |
| yates | good idea | 21:03 |
| kergoth | if it's trying to link to /lib/libpthread, it's probably a hosted linker script unless something else is going on. could add -v to the linker commandline perhaps? | 21:04 |
| kergoth | and just cat the libpthread.so | 21:04 |
| yates | good ideas, thanks. i will. | 21:05 |
| kergoth | np, good luck with it, sounds like it's an awfully painful recipe | 21:10 |
| yates | you can say that again. thanks! | 21:11 |
| *** Crofton|work <Crofton|work!~Crofton@23-25-123-169-static.hfc.comcastbusiness.net> has quit IRC | 21:28 | |
| yates | i can see a little further what's happening: there is a libpthread.so script at -L/Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/imx6ul-var-dart/usr/lib | 21:31 |
| yates | https://paste.fedoraproject.org/paste/LI-ei~mMFcTc5E-yJ2V0TQ | 21:31 |
| yates | it's apparently the two paths specified in that GROUP that are causing the error | 21:31 |
| *** tprrt <tprrt!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has joined #yocto | 21:36 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 21:39 | |
| *** meow` <meow`!~sbourdeli@147.ip-167-114-97.net> has joined #yocto | 21:43 | |
| *** gtristan <gtristan!~tristanva@110.11.179.2> has quit IRC | 21:48 | |
| *** guillaumekh <guillaumekh!5a5674df@gateway/web/freenode/ip.90.86.116.223> has quit IRC | 21:49 | |
| *** Crofton|work <Crofton|work!~Crofton@38.90.133.135> has joined #yocto | 21:58 | |
| *** toanju <toanju!~toanju@x5ce35ffb.dyn.telefonica.de> has quit IRC | 22:01 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 22:22 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 22:23 | |
| robbawebba | khem: Ahh i see! So I'll probably bbappend the os-release recipe to add MACHINE. Do you think this would be an addition that | 22:35 |
| robbawebba | Do you think that this would be an addition worth submitting a patch for? | 22:36 |
| *** marka <marka!~masselst@184.175.21.100> has quit IRC | 22:37 | |
| khem | I am not sure | 22:43 |
| *** kristoiv <kristoiv!~kristoiv@245.90-149-61.nextgentel.com> has joined #yocto | 22:48 | |
| aehs29 | robbawebba: I think the image-buildinfo class does something similar | 22:51 |
| aehs29 | just saying thats another option | 22:51 |
| *** apteryx <apteryx!~maxim@45.72.138.75> has joined #yocto | 22:55 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 23:22 | |
| *** no_such_user <no_such_user!~no_such_u@fpc125996-trow7-2-0-cust59.18-1.static.cable.virginm.net> has quit IRC | 23:27 | |
| robbawebba | aehs29: ahh, nice suggestion. I'll take a look at both. | 23:30 |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC | 23:32 | |
| *** ant_home <ant_home!~ant__@host55-101-dynamic.58-82-r.retail.telecomitalia.it> has quit IRC | 23:32 | |
| *** kristoiv <kristoiv!~kristoiv@245.90-149-61.nextgentel.com> has quit IRC | 23:33 | |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto | 23:34 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 23:35 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!