| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 00:00 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 00:01 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 00:19 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 00:23 | |
| *** JordonWu <JordonWu!~quassel@221.226.9.57> has joined #yocto | 00:31 | |
| *** cp__ <cp__!~nighty@d246113.ppp.asahi-net.or.jp> has joined #yocto | 00:37 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-tiswevfivlfqvcvi> has joined #yocto | 00:37 | |
| *** RalphJr45 <RalphJr45!~RalphJr45@109.157.254.172> has joined #yocto | 00:40 | |
| *** majuk <majuk!~majuk@50.233.77.210> has joined #yocto | 00:41 | |
| *** yizhao <yizhao!~zhaoyi@106.120.101.38> has quit IRC | 00:45 | |
| *** majuk <majuk!~majuk@50.233.77.210> has quit IRC | 00:45 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 00:49 | |
| *** yizhao <yizhao!~zhaoyi@106.120.101.38> has joined #yocto | 00:56 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 00:57 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 00:59 | |
| *** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC | 01:00 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 01:04 | |
| *** msvb-lab <msvb-lab!~michael@x55b547f3.dyn.telefonica.de> has quit IRC | 01:04 | |
| *** msvb-lab <msvb-lab!~michael@x55b540b0.dyn.telefonica.de> has joined #yocto | 01:17 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 01:17 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 01:24 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 01:26 | |
| *** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-bdlalbqwngyyggee> has joined #yocto | 01:34 | |
| *** RalphJr45 <RalphJr45!~RalphJr45@109.157.254.172> has quit IRC | 01:48 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 01:49 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 01:54 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 02:07 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 02:12 | |
| *** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC | 02:18 | |
| *** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto | 02:25 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 02:25 | |
| *** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC | 02:26 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 02:32 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 02:40 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 02:44 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 02:47 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 02:52 | |
| *** bananadev <bananadev!~onlyester@117.6.99.240> has joined #yocto | 02:56 | |
| *** mkelly <mkelly!~martin@67.171.33.217> has joined #yocto | 03:00 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 03:07 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 03:12 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 03:26 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 03:32 | |
| -YoctoAutoBuilder- build #891 of nightly-oe-selftest is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/891 | 03:41 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 03:46 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-tiswevfivlfqvcvi> has quit IRC | 03:47 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 03:52 | |
| *** mkelly <mkelly!~martin@67.171.33.217> has quit IRC | 04:02 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 04:07 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 04:12 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 04:14 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 04:26 | |
| *** m4t <m4t!~matt@2604:180:0:b2e::bad:beef> has left #yocto | 04:30 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 04:32 | |
| *** clement <clement!~clement@lns-bzn-39-82-255-32-23.adsl.proxad.net> has quit IRC | 04:45 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 04:46 | |
| *** clement <clement!~clement@lns-bzn-39-82-255-32-23.adsl.proxad.net> has joined #yocto | 04:47 | |
| *** agust <agust!~agust@p4FCB52B9.dip0.t-ipconnect.de> has joined #yocto | 04:56 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 05:01 | |
| *** AndersD <AndersD!~anders@194-237-220-218.customer.telia.com> has joined #yocto | 05:12 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has joined #yocto | 05:17 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 05:33 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto | 05:38 | |
| *** qt-x <qt-x!~Thunderbi@217.10.196.2> has joined #yocto | 05:42 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has joined #yocto | 05:44 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 05:48 | |
| *** garbados <garbados!~garbados@2601:1c2:303:6b0:3598:adc3:5994:95c8> has quit IRC | 06:05 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 06:14 | |
| *** pohly <pohly!~pohly@p5DE8EB79.dip0.t-ipconnect.de> has joined #yocto | 06:18 | |
| *** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has joined #yocto | 06:20 | |
| *** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has left #yocto | 06:21 | |
| *** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has joined #yocto | 06:22 | |
| *** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has quit IRC | 06:22 | |
| *** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has joined #yocto | 06:23 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 06:29 | |
| *** bananadev <bananadev!~onlyester@117.6.99.240> has quit IRC | 06:32 | |
| *** arun_ <arun_!~arun@125.16.167.59> has joined #yocto | 06:34 | |
| *** arun_ is now known as Guest12873 | 06:34 | |
| *** bananadev <bananadev!~onlyester@117.6.99.240> has joined #yocto | 06:35 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 06:35 | |
| -YoctoAutoBuilder- build #1230 of nightly is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly/builds/1230 | 06:36 | |
| *** rj_ <rj_!58d39085@gateway/web/freenode/ip.88.211.144.133> has joined #yocto | 06:40 | |
| rj_ | Hey, i'm getting this error, does anyone know how to fix this? https://pastebin.com/yV69D9S8 | 06:42 |
|---|---|---|
| rj_ | I know it has to do that the tmp dir i used in the paths in the .pc file, but im not sure how to fix it | 06:43 |
| *** aurele <aurele!~aurele@srvmsg.castel.fr> has joined #yocto | 06:43 | |
| aurele | hi everyone | 06:43 |
| aurele | is there a way to use recipe to build a package using the sdk | 06:44 |
| aurele | I'm looking for a simple way for developpers to build multiple packages without having to think about configure flags and so on | 06:46 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 06:48 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:53 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 06:53 | |
| *** ed2 <ed2!~Adium@192.198.151.44> has joined #yocto | 06:54 | |
| *** ed2 <ed2!~Adium@192.198.151.44> has joined #yocto | 06:55 | |
| msvb-lab | Anyone remember the bitbake parameter to build targets but discard intermediate object files after each target is built? | 06:58 |
| msvb-lab | I assume by using that bitbake parameter I can build world with only a few hundred gigs. | 06:58 |
| *** adelcast <adelcast!~adelcast@130.164.62.126> has quit IRC | 06:59 | |
| ed2 | msvb-lab: INHERIT += "rm_work" | 07:00 |
| msvb-lab | ed2: So, $ INHERIT += "rm_work" bitbake world | 07:01 |
| ed2 | msvb-lab: echo 'INHERIT += "rm_work"' >> conf/local.conf && bitbake word | 07:02 |
| *** jku <jku!~jku@192.198.151.45> has joined #yocto | 07:02 | |
| msvb-lab | ed2: Oh, thanks. Does that cause bitbake to keep all intermediate 'work' files until the 'world' target finishes and then they are deleted? | 07:02 |
| msvb-lab | Or does bitbake delete the intermediate files as it builds dependencies? | 07:03 |
| LetoThe2nd | msvb-lab: i actually tried building world to get some numbers, as we discussed it. taking only a plain poky into account for qemuarm, it summed up to about 90GB for me | 07:03 |
| msvb-lab | LetoThe2nd: Thank you, that's useful. Because I'm building Wind River (a bit bigger than poky) I need a half terabyte or so. | 07:04 |
| msvb-lab | ...which I don't have to spare. | 07:04 |
| LetoThe2nd | msvb-lab: tell your boss that hardware is cheap in comparison to your testing and waiting time ;-) | 07:05 |
| msvb-lab | LetoThe2nd: True, it's a longer story than that unfortunately. | 07:06 |
| LetoThe2nd | msvb-lab: thats what every boss says ;-) | 07:07 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 07:07 | |
| msvb-lab | ed2: I'd like to retroactively use 'rm_work' for the last 20 hours of building. Does $ bitbake clean world do that? | 07:08 |
| LetoThe2nd | ed2: btw, "bitbake word" is a wonderful typo ;-) | 07:08 |
| *** mckoan|away is now known as mckoan | 07:08 | |
| ed2 | msvb-lab: :) | 07:08 |
| msvb-lab | If bitbake(1) works like make(1), then even after bitbake clean the next run will detect the target.rpm file present and timestamped and will not rebuild it. | 07:09 |
| ed2 | msvb-lab: I'm not sure it's possible to use it like that. bitbake loads configuration at the start as far as I know. | 07:10 |
| ed2 | msvb-lab: you can read about rm_work here: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-rm-work | 07:10 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 07:11 | |
| msvb-lab | ed2: Thanks for the reference, I had seen that document and then lost track of where to find it again. | 07:12 |
| *** rajm <rajm!~robertmar@167.98.27.226> has joined #yocto | 07:13 | |
| msvb-lab | It seems that a half-brained approach like manually deleting 'build/work' once in a while reduces storage considerably. | 07:13 |
| *** adelcast <adelcast!~adelcast@130.164.62.126> has joined #yocto | 07:14 | |
| msvb-lab | ...and probably the bitbake world build (especially if '-k' keep going is used) will still succeed. | 07:14 |
| ed2 | msvb-lab: I usually remove build/tmp. next build takes everything it can from sstate, so it doesn't take long. | 07:14 |
| *** diego_r <diego_r!~diego@host57-224-static.7-79-b.business.telecomitalia.it> has joined #yocto | 07:15 | |
| msvb-lab | ed2: Oh, I was assuming the next build would start from the beginning. I see the sstate directory is quite large so your suggestion makes sense. | 07:15 |
| msvb-lab | ed2: I'm going to stop the build and restart with INHERIT += "rm_work" hoping at least sstate will help. | 07:16 |
| ed2 | msvb-lab: you can play with it on something smaller than 'bitbake world' :) | 07:16 |
| *** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has joined #yocto | 07:17 | |
| ed2 | msvb-lab: you can stop the build, remove tmp, enable rm_work and start it again. That would save you some disk space I believe. | 07:17 |
| msvb-lab | I'll build a few individual packages to be sure, then world after that. | 07:17 |
| msvb-lab | ed2: The stop, remove, rebuild approach is just what I'm planning. | 07:18 |
| msvb-lab | Looking at a week of building, but at least it's the only build I'll need this year. | 07:18 |
| msvb-lab | LetoThe2nd: ...which is the main reason I'm not buing a build farm. Too many days of the year not using it. | 07:19 |
| msvb-lab | LetoThe2nd: I've thought about renting a VPS or cloud computing hours. Not sure how practical that would be for short term (one time) world builds. | 07:19 |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 07:23 | |
| *** florian_kc is now known as florian | 07:23 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 07:25 | |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto | 07:28 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 07:29 | |
| *** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has quit IRC | 07:30 | |
| *** joeythesaint <joeythesaint!~joe@vegas.deserted.net> has quit IRC | 07:31 | |
| *** joeythesaint <joeythesaint!~joe@2605:6400:2:fed5:22:41:45ec:bf91> has joined #yocto | 07:31 | |
| LetoThe2nd | msvb-lab: i can confirm that it is highly useful. if in doubt, just fire up an ec2 instance for the build time, dump everything on s3, done. | 07:31 |
| LetoThe2nd | msvb-lab: if you're only doing a couple of builds per month, it is probably cheaper, yes. | 07:32 |
| msvb-lab | LetoThe2nd: Sounds like an interesting option, although my credits are on Azure. Might have a similar outcome. | 07:33 |
| *** yohboy <yohboy!~yohan@162.38.36.104> has joined #yocto | 07:33 | |
| LetoThe2nd | msvb-lab: as long at it runs linux, all is fine. at the yocto dev day they usually go for GCE. | 07:33 |
| msvb-lab | I wish there were a document for the steps needed to build poky world on EC2/S3 along with cost estimate. | 07:34 |
| LetoThe2nd | i'd say that there's too many variables in this question for a document to properly answer it | 07:35 |
| msvb-lab | LetoThe2nd: Too many variables to build poky world on qemu-x86? | 07:36 |
| LetoThe2nd | msvb-lab: absolutely. | 07:36 |
| msvb-lab | LetoThe2nd: You mean like 'rm_work' type variables? Probably version preferences... | 07:36 |
| LetoThe2nd | i mean like: interactively or not? speed or cost optimized? keep artifacts for later? if yes, which? | 07:37 |
| msvb-lab | Most of those variables apply to noncloud builds too. I wish for a document to help those already established with a local build to do it on a VPS. | 07:38 |
| LetoThe2nd | i guess then i don't understand the question. | 07:38 |
| msvb-lab | ...so I imagine a person who has a $ bitbake <parameters> already correct, should be able to log into VPS and type the same thing there. | 07:39 |
| msvb-lab | There was no question posed, rather a wish 'to have a document listing the steps involved in setting up a VPS and then building pokey on it.' | 07:40 |
| *** _plcp <_plcp!c1382434@gateway/web/freenode/ip.193.56.36.52> has joined #yocto | 07:40 | |
| LetoThe2nd | if the infrastructure on the remote end is already set up accordingly. which you usually have to do on startup, as the compute nodes do not have persistent state - respectively you do not want persistent tate that can be automatically recreated. | 07:40 |
| msvb-lab | So this is a document (that already exists) to just get a VPS up and running on GCE/Azure/Amazon, but specific to bitbake builds. | 07:40 |
| rj_ | I'm getting this error, does anyone know how to fix this? https://pastebin.com/yV69D9S8 | 07:41 |
| *** JoiF <JoiF!~jofr@193.182.166.3> has joined #yocto | 07:41 | |
| LetoThe2nd | msvb-lab: well in the simplest case, this is 1) have your compute provider hand you a linux shell 2) the yocto quick start guide. | 07:41 |
| *** hattzy <hattzy!~hattzy@h-90-120.a137.corp.bahnhof.se> has joined #yocto | 07:41 | |
| *** fabo_ <fabo_!~fabo@a91-156-68-101.elisa-laajakaista.fi> has joined #yocto | 07:42 | |
| msvb-lab | LetoThe2nd: Yes, and those steps can be explained by different 'getting started' docs. | 07:42 |
| *** fabo <fabo!~fabo@linaro/fabo> has quit IRC | 07:43 | |
| LetoThe2nd | msvb-lab: 2) exists. | 07:43 |
| *** ed2 <ed2!~Adium@192.198.151.44> has quit IRC | 07:43 | |
| LetoThe2nd | msvb-lab: 1) exists separately for every provider, its their own documentation. | 07:43 |
| msvb-lab | LetoThe2nd: Even better would be a 'yocto container' which one could start on a given provider and type 'bitbake world' after logging in. Maybe this exists, not sure. | 07:44 |
| msvb-lab | Container like a LXC, Docker, or CoreOS/Rocket. | 07:44 |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC | 07:45 | |
| LetoThe2nd | msvb-lab: such a thing (partially) exists: https://git.yoctoproject.org/cgit/cgit.cgi/crops/tree/README.md | 07:45 |
| msvb-lab | rj_: I took a look at the log but it's not detailed enough to show what's the sanity problem with the file in question 'orocos...pc' | 07:45 |
| msvb-lab | rj_: Have you looked at orocos-rtt-gnulinux.pc to ensure it's okay? Is the file empty or maybe has CR/LF? | 07:46 |
| LetoThe2nd | rj_: probably some magic in the .pc file is wrong but sorry, i'm not competent to comment on it. | 07:46 |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has joined #yocto | 07:47 | |
| msvb-lab | LetoThe2nd: Oh CROPS is cool, thanks for the tip. Particularly since it can bootstrap a Zephyr environment. | 07:47 |
| *** ed2 <ed2!~Adium@192.198.151.44> has joined #yocto | 07:48 | |
| *** toscalix <toscalix!~toscalix@80.91.70.201> has joined #yocto | 07:48 | |
| msvb-lab | rj_: If you don't know how pkg-config(1) works, take a look at some other *.pc files near the one in question and compare them. Maybe you'll find some reason that bitbake considers a sanity problem? | 07:48 |
| LetoThe2nd | msvb-lab: i've never used it, so don't expect me to provide more meaningful information on it besides that "it exists" | 07:49 |
| msvb-lab | LetoThe2nd: In the end, it's okay since yocto and bitbake are seeminly used mostly by folks on a regular basis who know what they're doing. | 07:49 |
| msvb-lab | ...user friendly to the experts but not so much to the novices. | 07:50 |
| rj_ | msvb-lab: Wait a sec, ill pastebin the file | 07:51 |
| LetoThe2nd | msvb-lab: i still don't see why executing two well-documented tasks one after the other is expert only, but ok. of course building a complete distribution is not as trivial as switching on a readily installed lightbulb | 07:51 |
| rj_ | msvb-lab: This is the pc file that is generated: https://pastebin.com/V8R9rkVB | 07:53 |
| msvb-lab | rj_: Best would be if someone with knowledge of the sanity checking logic can speak, but it seems we're out of luck with that. | 07:54 |
| msvb-lab | rj_: I don't see any problem with the .pc file. If bitbake were made for novices (like me) then it would have a easy to find (like in scripts/bin) check_sanity command and we would now pass in the .pc file and get an immediate answer. | 07:55 |
| *** quite <quite!quite@unaffiliated/quite> has quit IRC | 07:56 | |
| LetoThe2nd | guessing from the error message, it is that your build tmp path is leaking into it. | 07:56 |
| msvb-lab | But I'm afraid you'll have to unravel the onion until figuring out what part of bitbake failed, under which conditions, which implicit variables, and if any of that was dynamically generated (and by which script.) | 07:56 |
| ChrysD | there is kind of linux command line to specify something we dont want ? Like for example when we want everything we put "*" if we want everything that ends with ".h" we put *.h ... But in case if we want to do exclusion ? | 07:56 |
| LetoThe2nd | which will be obviously nonexistent during runtime. | 07:56 |
| ChrysD | Thanks. | 07:56 |
| *** quite <quite!quite@gyro.lublin.se> has joined #yocto | 07:57 | |
| *** quite <quite!quite@unaffiliated/quite> has joined #yocto | 07:57 | |
| *** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has joined #yocto | 07:58 | |
| rj_ | LetoThe2nd: then how does it add that path when its nonexistent | 07:59 |
| LetoThe2nd | rj_: "it" | 07:59 |
| LetoThe2nd | rj_: i don't know where the .pc file comes from. and i'd say that it probably is not bitbake that creates it, but maybe some scripting in the package that you want to build | 07:59 |
| rj_ | LetoThe2nd: ah alright, well ill try to find out then | 08:00 |
| msvb-lab | .pc files usually are generated from .pc.in files, which are unpacked from tarballs. | 08:01 |
| LetoThe2nd | so while it often looks like "bitbake fails or breaks", in the most cases it really is crappy upstream source that breaks stuff. | 08:01 |
| msvb-lab | rj_: Manually download orocos*.tar.gz (or whatever it's called) and look for a .pc.in file. | 08:01 |
| msvb-lab | LetoThe2nd: That's true, and in most cases (like this one?) just doing the expected ./configure && make won't produce the sanity error so unravelling the script onion is required. | 08:02 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 08:03 | |
| LetoThe2nd | msvb-lab: of course ./configure and make won't produce any errors. they live in their happy on-target, native compilation world usually. | 08:03 |
| msvb-lab | ...and test a controlled set of variables like on a clean debian system. | 08:04 |
| LetoThe2nd | and thats the reason why we need all this sanity checking, annoying as it might be, | 08:05 |
| msvb-lab | Still it would be nice to have a 'sanitycheck.sh' in order to partially test whatever is described as flawed by bitbake. | 08:05 |
| rj_ | msvb-lab: Alright, found the pc.in file https://pastebin.com/Ua07XwHd | 08:06 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 08:07 | |
| *** grma <grma!~gruberm@80.93.38.128> has joined #yocto | 08:12 | |
| msvb-lab | rj_: It's unlikely the way to go, my suggestion to unpack and look at .pc.in was in response to the question 'where to .pc files come from?' | 08:13 |
| *** fabo_ is now known as fabo | 08:14 | |
| msvb-lab | rj_: But to find the actual problem (which could be within a layer, .bb file, or orocos sources) requires considerable debugging. | 08:14 |
| *** ant_work <ant_work!~ant__@host108-181-dynamic.31-79-r.retail.telecomitalia.it> has joined #yocto | 08:15 | |
| LetoThe2nd | my bets are on the build script just foing one of the path replacements wrong. | 08:15 |
| msvb-lab | Like you might try building orocos manually after matching as much of the bitbake environment as possible? Like at a minimum $ . init-intel-x86-env or whatever environment you set up. | 08:15 |
| *** geoffrey_l <geoffrey_l!~geoffrey_@lns-bzn-39-82-255-32-23.adsl.proxad.net> has joined #yocto | 08:16 | |
| msvb-lab | LetoThe2nd: So you would expect to find the flawed path in a .bb file? | 08:16 |
| LetoThe2nd | msvb-lab: no. the exact opposite. | 08:16 |
| rj_ | The .bb file is costum, it could be that i simply made it the wrong way | 08:16 |
| msvb-lab | LetoThe2nd: Like a hard coded path in '*.pc'? I didn't see any. | 08:16 |
| LetoThe2nd | msvb-lab: i'd expect the script in the source that does the pc.in -> .pc to incorrectly react to one of the paths. | 08:17 |
| LetoThe2nd | of course it could also be the recipe setting a path wrong. but its almost certainly not hardcoded. | 08:17 |
| msvb-lab | rj_: How about starting from scratch and doing $ bitbake orocos? | 08:18 |
| msvb-lab | rj_: It would likely fail in the same way, but at that time you have produced much less intermediate files over which to grep(1) for answers. | 08:19 |
| LetoThe2nd | rj_: probably that even is not needed. look at the logs that are created during the configure stage. | 08:19 |
| JoiF | ChrysD: How flexible are you with regards to stuff you can use? Can you use a pipe? Then I'd suggest "ls | grep -v somthingYouDon'twant" | 08:19 |
| msvb-lab | LetoThe2nd: Are those logs stored in build/tmp/sysroots/orocos* or something? | 08:19 |
| LetoThe2nd | ChrysD: maybe some find -exec :-) | 08:20 |
| msvb-lab | Definitely a good idea if they can be found. | 08:20 |
| ChrysD | JoiF, LetoThe2nd : Thanks. | 08:20 |
| rj_ | msvb-lab: I'll try and locate them | 08:20 |
| JoiF | That'll work too | 08:20 |
| *** yann <yann!~yann@90.90.216.32> has joined #yocto | 08:21 | |
| LetoThe2nd | msvb-lab: they are. like tmp/work/$MACHINEARCH/$PACKAGE/$VERSION/temp | 08:21 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 08:21 | |
| rj_ | log.do_configure right? | 08:21 |
| LetoThe2nd | yes. and the internal config.log (for autotoolized packages for example) are certainly around too, in the build directry. | 08:22 |
| LetoThe2nd | so you just have to dig a little. | 08:22 |
| rj_ | LetoThe2nd: well i got the log.do_configure. It does have some paths in it to : /home/user/poky/build/tmp/sysroots/genericx86-64/usr/include | 08:23 |
| rj_ | Which is to find boost apparently | 08:23 |
| msvb-lab | rj_: Additionally try $ grep -i -d recurse sanity tmp/work/$MACHINEARCH/ | 08:23 |
| msvb-lab | ...oops I mean: grep -i -d recurse sanity tmp/work/$MACHINEARCH/oroco* | 08:24 |
| LetoThe2nd | rj_: of course it has pathes, the question is where and which pathes are put into the .pc - why they are not sysroot relative | 08:24 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 08:26 | |
| msvb-lab | rj_: Compare the oroco*.pc file with another package .pc file, particulary looking at the string 'tmp'. | 08:27 |
| msvb-lab | Do you find that one has 'tmpdir=...' and the other doesn't? | 08:27 |
| msvb-lab | Or do some paths with 'tmp' not exist? Test '/home/user/poky/build/tmp/sysroots/genericx86-64/usr/lib' for example: | 08:28 |
| msvb-lab | ls /home/user/poky/build/tmp/sysroots/genericx86-64/usr/lib | 08:28 |
| msvb-lab | ...and repeat for all paths in the .pc file that contain 'tmp' | 08:28 |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto | 08:28 | |
| msvb-lab | ls /home/user/poky/build/tmp/work/core2-64-poky-linux/orocos-rtt/2.6.0+gitAUTOINC+1df3ad9acd-r0/sysroot-destdir/usr/lib/pkgconfig | 08:28 |
| rj_ | msvb-lab: All paths exist | 08:30 |
| *** groleo <groleo!~groleo@188.27.9.47> has joined #yocto | 08:30 | |
| rj_ | and the last one you just mentioned is where the .pc file is stored | 08:30 |
| msvb-lab | rj_: So bitbake is indicating a problem with oroco (relating to tmpdir and .pc file) that isn't indicated with other targets that have similar .pc files. | 08:32 |
| rj_ | So it seems | 08:32 |
| LetoThe2nd | the look at the other packages with the similar pc files if they need to be passed some additional arguments to the configure stage. | 08:33 |
| *** frsc <frsc!~frsc@80.149.173.68> has joined #yocto | 08:35 | |
| msvb-lab | rj_: The .pc file is not important for building oroco, so one option is to write your own fake .pc.in file and put it in the package 'downloads/oroco-*.tar.gz'. Rebuild with a nearly empty .pc.in and the resulting .pc surely can't be considered insane? | 08:36 |
| *** zeenix <zeenix!~zeenix@83.218.80.243> has joined #yocto | 08:37 | |
| msvb-lab | ...I just fear that if you manipulate the downloads/oroco-*.tar.gz file that it will be overwritten when you rebuild. | 08:37 |
| msvb-lab | rj_: Another option is to try to figure out what criteria bitbake uses when determining the sanity of a .pc file. That's probably an hour long (or afternoon?) task though. | 08:38 |
| *** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has joined #yocto | 08:39 | |
| rj_ | msvb-lab: Sounds like fun... (._.)7 | 08:39 |
| LetoThe2nd | msvb-lab: nope, thats probably easy. | 08:39 |
| rj_ | msvb-lab: I'll try and change the pc.in file when bitbake works again... | 08:40 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 08:40 | |
| *** _plcp is now known as plcp_ | 08:40 | |
| rj_ | "ERROR: Only one copy of bitbake should be run against a build directory" | 08:40 |
| LetoThe2nd | if you look at the pc file that gets packages/installed. if there is a path in there that is not target-relative, but contains something like tmp/whatever, then the .pc file is insane. simple as that. | 08:40 |
| msvb-lab | LetoThe2nd: That's why bitbake must declare any other similar (meaning with hard coded build/tmp paths) as insane as well. | 08:41 |
| msvb-lab | But we're not seeing that? Is bitbake smart enough to understand the purpose of pkg-config(1), it's .pc files, and test for relative paths? | 08:42 |
| msvb-lab | If so, then that's the direction to investigate. | 08:42 |
| LetoThe2nd | msvb-lab: i just don't see the purpose of evaluation how bitbake checks the file. if the path is in there, then the quesiton is *why*. the question is not *how it is detected* | 08:42 |
| msvb-lab | ...like in place modification of the .pc file while bitbake is building (after unpackaging) or hand crafting a new oroco-*.tar.gz and placing in downloads/ | 08:43 |
| *** Smitty_ <Smitty_!86bfdc47@gateway/web/freenode/ip.134.191.220.71> has joined #yocto | 08:43 | |
| Smitty_ | I'm a little confused about something. | 08:43 |
| *** hattzy <hattzy!~hattzy@h-90-120.a137.corp.bahnhof.se> has quit IRC | 08:43 | |
| LetoThe2nd | Smitty_: i am a little confused about soemthing too. | 08:44 |
| Smitty_ | I have a new static library that I wish to include in the SDK build | 08:44 |
| *** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto | 08:44 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 08:44 | |
| msvb-lab | LetoThe2nd: Depends on which problem we're trying to solve first: 1) Getting bitbake to build oroco or 2) correcting the oroco build configuration (for later on after the distro is created. | 08:44 |
| Smitty_ | Right now, nothing requires this library, but in the future some other packages will depend upon it. | 08:44 |
| rj_ | msvb-lab: For now it just has to build | 08:44 |
| LetoThe2nd | msvb-lab: 1) is in most cases pointless, as not reproductible. | 08:44 |
| LetoThe2nd | Smitty_: which holds true for many packages. | 08:45 |
| Smitty_ | So, how do I get the library included in the SDK image ? | 08:45 |
| rj_ | Why can't i kill the bitbake process.... | 08:45 |
| Smitty_ | So far, the only way I can figure out is to add it to a depends list for soemthing else | 08:45 |
| LetoThe2nd | Smitty_: you can for example set it as a TOOLCHAIN_TARGET_TASK for the desired image. | 08:46 |
| *** fray <fray!~fray@kernel.crashing.org> has quit IRC | 08:48 | |
| rj_ | "ERROR: Only one copy of bitbake should be run against a build directory" Anyone knows how to kill the process? | 08:49 |
| msvb-lab | rj_: I'm dealing with a similar problem, lib32-qt4-embedded building for 1 1/2 hours even after Ctrl-C. | 08:49 |
| rj_ | msvb-lab: Building qt4 took me really long aswell yesterday | 08:50 |
| rj_ | msvb-lab: But atm im not building anything... And it still throws me this error | 08:50 |
| msvb-lab | ...oh cool, just after I complained the build finally stopped. Now I can use $ INHERIT += "rm_work" bitbake | 08:50 |
| rj_ | I can't seem to find the bitbake process either... | 08:51 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 08:51 | |
| *** fray <fray!~fray@kernel.crashing.org> has joined #yocto | 08:52 | |
| *** nikincn <nikincn!2a6d1f22@gateway/web/freenode/ip.42.109.31.34> has joined #yocto | 08:52 | |
| rj_ | ill just reboot i guess | 08:52 |
| rj_ | brb | 08:52 |
| *** rj_ <rj_!58d39085@gateway/web/freenode/ip.88.211.144.133> has quit IRC | 08:53 | |
| *** rj_ <rj_!58d39085@gateway/web/freenode/ip.88.211.144.133> has joined #yocto | 08:55 | |
| rj_ | msvb-lab: okay, so should i just remove all paths that contain the tmp dir? | 08:57 |
| rj_ | in the pc.in file | 08:57 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 08:58 | |
| Smitty_ | Leto... Do you mean I would add it at the top level sdk.bb file, or in my library's bb file ? | 08:58 |
| msvb-lab | rj_: Good idea, but you'll have to make sure that your changes to .pc.in (or .pc as bitbake builds - your choice) is actually used. | 08:59 |
| *** ChrysD <ChrysD!d9804861@gateway/web/freenode/ip.217.128.72.97> has left #yocto | 08:59 | |
| *** ChrysD <ChrysD!d9804861@gateway/web/freenode/ip.217.128.72.97> has joined #yocto | 08:59 | |
| msvb-lab | rj_: ...since there's the possibility that whatever you modify before bitbake starts, will get overwritten. Do you think it will? | 08:59 |
| LetoThe2nd | Smitty_: to the image recipe. usually the sdk is meant for a specific image, right? | 08:59 |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC | 09:00 | |
| *** rollcake <rollcake!~yoonki@175.125.129.3> has joined #yocto | 09:00 | |
| msvb-lab | Like I know there's at least one cache (sstate?) that bitbake reads from. And it might download oroco-*.tar.gz again and unpack again. Maybe you can avoid that with a '-c' parameter to just do_config or something? | 09:01 |
| LetoThe2nd | Smitty_: here is some additional information: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#sdk-adding-individual-packages | 09:02 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 09:02 | |
| Smitty_ | yep. So the recipe for my library is the one to modify, by adding my library to TOOLCHIAN_HOST_TASK, and TOOLCHAIN_TARGET_TASK ? | 09:04 |
| LetoThe2nd | Smitty_: no, the image recipe is the one to modify. in natural language: "i want my image to look like this, and the corresponding sdk to contain these additional things." | 09:05 |
| rj_ | msvb-lab: I'll just change it, build it, and look at the file to see if it actually changed ^^ | 09:07 |
| rj_ | msvb-lab: Well...It builds now | 09:10 |
| rj_ | Not sure if everything will work correctly but it passed the sanity check now | 09:10 |
| nikincn | noob here : I ran bitbake for my board . how to try the images generated on 1)Qemu 2)burn it to the flash memory for board any link to documentation will help | 09:12 |
| *** jonakn <jonakn!c33c449c@gateway/web/freenode/ip.195.60.68.156> has joined #yocto | 09:12 | |
| msvb-lab | rj_: So you just did #1 of the 1) build and 2) correct. | 09:13 |
| LetoThe2nd | nikincn: for 1) if your board is not super close to one of the qemu provided emulation boards, you can't run it there. you have to build for MACHINE qemu | 09:13 |
| rj_ | msvb-lab: I removed all paths that had tmp in them. Build the image, and got no errors :) | 09:14 |
| nikincn | i c , thanks @ Letothe2nd | 09:14 |
| msvb-lab | rj_: Obviously, you can ignore #2 (like if you don't have time) but if any other packages depend on oroco libs, there might be another failure when the .pc file is read but it is not correct. | 09:14 |
| LetoThe2nd | nikincn: for 2) please consult the documentation of your board, its hw specific | 09:15 |
| msvb-lab | rj_: Hard to tell if removing all those paths lead to a harmless .pc modification. | 09:15 |
| rj_ | msvb-lab: Yea, i'm working on that now, cause the next package orocos-ocl depends on orocos-rtt, so im curious if it will work | 09:15 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 09:16 | |
| nikincn | ok @Letothe2nd I will check board documentation ,though afai remember they havent given detailed doc | 09:16 |
| LetoThe2nd | nikincn: well then tell them to provide the documentation, thats certainly vendor duty. | 09:17 |
| msvb-lab | rj_: One reason that the dependencies might work (even without correcting the oroco .pc build configuration) is that the hard coded tmp paths actually point to where oroco is temporarily installed during the bitbake build. | 09:18 |
| msvb-lab | I'm not sure about that, but it might be something to worry about. | 09:18 |
| Smitty_ | Still a bit confused by this. Currently the SDK image bb file contains these definitions: TOOLCHAIN_HOST_TASK = "\ packagegroup-cross-canadian-${MACHINE} \ packagegroup-host-minimal-sdk \ " | 09:19 |
| msvb-lab | rj_: At the very least, you might consider after all is done looking at the final oroco-*.pc file in it's final installed location. | 09:19 |
| rj_ | msvb-lab: i will yea | 09:19 |
| msvb-lab | ...and maybe even a simple hello world test in which you read paths like CPPFLAGS and LIBS from pkg-config(1) output. | 09:19 |
| msvb-lab | rj_: $ pkg-config -l -cppflags oroco | 09:20 |
| Smitty_ | The way that my library is included in the SDK is by way of recursion into the subdirectories | 09:20 |
| nikincn | they dont have doc for yocto , they have a link for compiling own image but that is just compiling their version from git and loading the generated image on to the board | 09:20 |
| msvb-lab | ...that kind of thing (adjust and correct, since I just wrote semi pseudocode.) | 09:20 |
| nikincn | are they obliged to support yocto? | 09:20 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 09:20 | |
| LetoThe2nd | nikincn: no, they are obliged to tell you how to load software onto the board. | 09:20 |
| LetoThe2nd | nikincn: if they desribe some way, then it might be up to you to create images that fit the process. | 09:21 |
| Smitty_ | Why wouldn't I append my library to the TOOLCHIAN_HOST_TASK variable in my own library recipe ? | 09:21 |
| msvb-lab | rj_: It's likely that the oroco-*.pc.in file should contain '$DESTDIR/usr/lib/pkgconfig/' or similar but instead has `pwd` or something else leading to a hard coded 'build/tmp' in the path. | 09:21 |
| LetoThe2nd | Smitty_: because then it would be always pulled into the sdk, no matter by which image. | 09:21 |
| Smitty_ | Isn't that what I want ? | 09:22 |
| nikincn | ok got it , but tough for a noob | 09:22 |
| nikincn | i will google more thanks for ur help | 09:22 |
| LetoThe2nd | Smitty_: nah. it probably wouldn't work, because then the addition is not visible during the build of the sdk. | 09:22 |
| LetoThe2nd | Smitty_: scratch my first statement. i think it would never be included. | 09:23 |
| LetoThe2nd | nikincn: if it is a well known board, there might be something already in place for you. what are we talking about? | 09:23 |
| nikincn | firefly rk3288 | 09:23 |
| LetoThe2nd | nikincn: ok, their site look like you're in for a lot of fun. | 09:25 |
| rj_ | msvb-lab: great, next package has the same error and more ;-; | 09:25 |
| LetoThe2nd | nikincn: my personal advice would be to get access to the bootloader and try to network boot | 09:25 |
| nikincn | ok will try that | 09:26 |
| *** nikincn <nikincn!2a6d1f22@gateway/web/freenode/ip.42.109.31.34> has quit IRC | 09:31 | |
| msvb-lab | rj_: If the oroco package didn't have the error anymore after you manually modified .pc.in in the tarball, then this flaw is probably present in all the other oroco-* packages. Congratulations. | 09:31 |
| rj_ | msvb-lab: Proably yea, its a qa issue again: https://pastebin.com/dL6BqDHS | 09:32 |
| rj_ | Only alot more this time | 09:32 |
| msvb-lab | rj_: So once it again it comes down to 1) cheap quick get to build via manual intervention or 2) upstream, figure out maintainer, bug report, correct .pc.in, maybe a newer/older version, lots of other work. | 09:32 |
| ChrysD | bitbake -c clean TARGET will cleans the images of the target ? Or it will remove allso the local.conf etc ? Thanks. | 09:33 |
| msvb-lab | rj_: You're doomed if you do #2 and you're doomed if you don't #1, bitbake and yocto layer maintenance seems to be an equal opportunity project. | 09:33 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 09:34 | |
| Smitty_ | Sorry to make a big point of this, but... Why don't I see a list of every library in the SDK being populated in TOOLCHAIN_HOST_TASK or TARGET_TASK at the top level ? | 09:34 |
| LetoThe2nd | Smitty_: because those that are actually pulled in through dependencies do not have to be explicitly mentioned | 09:35 |
| rj_ | msvb-lab: Oh well, at least i got 1 more package working. Thanks for the help! | 09:35 |
| Smitty_ | If what you are suggesting is the "right" way to accomplish it, I would expect to see hundreds of libraries listed | 09:35 |
| msvb-lab | rj_: That pastebin indicates that the oroco version that pokey maintainers chose is hopelessly flawed. | 09:35 |
| msvb-lab | rj_: What about figuring out how to completely remove oroco-* from the build? | 09:35 |
| rj_ | msvb-lab: Not an option sadly | 09:35 |
| LetoThe2nd | rj_: there is also 3) include a patch in your recipe. | 09:36 |
| msvb-lab | rj_: There is a bitbake target or argument which gives you a dependency tree. Maybe you can take a look at that tree to see how much stuff depends on oroco. | 09:36 |
| msvb-lab | ...and if you're lucky that (almost) nothing depends on it, then remove it from its corresponding bb file. | 09:37 |
| rj_ | msvb-lab: Atm nothing depends on Orocos | 09:37 |
| msvb-lab | rj_: Is it an option then, to simply remove oroco from the build? | 09:37 |
| Smitty_ | So, you are suggesting that all the libraries that are included in an SDK are there because something in the OS image depends upon them ? | 09:37 |
| LetoThe2nd | Smitty_: exactly. | 09:37 |
| rj_ | msvb-lab: It is not sadly, i have to get this working to run some costum software on this build | 09:38 |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto | 09:38 | |
| msvb-lab | rj_: If not, then LetoThe2nd idea of correcting orocos and patching in bb is a good idea. | 09:38 |
| rj_ | msvb-lab: And that software does heavily depend on orocos | 09:38 |
| LetoThe2nd | Smitty_: if i have something in the image that depends on a library, then when i build a sdk for that image, the library is automatically pulled in through dependencies. | 09:38 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 09:38 | |
| msvb-lab | rj_: Take a look at all public versions of the Orocos .pc.in file, and maybe one of them is correct. That gives you an instant patch baseline. | 09:39 |
| rj_ | msvb-lab: as far as i know the one i have now is the newest version straight from their repository | 09:40 |
| Smitty_ | So, the problem I face is that because right now, nothing is using that library, it doesn't show up on a depends list. Since this is the case, you suggest that the best thing to do is to make it totally explicit that it is being added - regardless ? | 09:41 |
| LetoThe2nd | Smitty_: i suggest to explicitly add it in the image for the time now. once something is added to the image that implicitly depends on it, you can remove the explicit part again. | 09:41 |
| Smitty_ | But, how will I know when that happens ? This is a big project with a lot of teams. I can't analyse all their updates to detect when someone finally uses the library. | 09:42 |
| LetoThe2nd | Smitty_: the one that modifies the image recipe is in charge. simple as that. | 09:43 |
| LetoThe2nd | Smitty_: if you allow people without understanding your structure to modify something as essential as the image recipe, you're doomed anyways. | 09:43 |
| *** rburton <rburton!~Adium@home.burtonini.com> has joined #yocto | 09:43 | |
| rj_ | rburton: hey, i saw your name in some logs where you helped someone with something similair to this: https://pastebin.com/yV69D9S8. Do you know any fix for this besides removing tmp paths from the .pc file? | 09:48 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 09:48 | |
| *** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has quit IRC | 09:49 | |
| msvb-lab | LetoThe2nd: By the way, I think you suggested deleting tmp and bitbake would read from sstate instead of rebuilding. That's a cool feature, and I'm confirming (to myself) that that works as intended now. | 09:50 |
| LetoThe2nd | msvb-lab: nope it was ed2 :) | 09:50 |
| msvb-lab | Build tasks that usually take five minutes are flashing by. | 09:50 |
| msvb-lab | Oh, it was ed2. In any case I didn't delete tmp but rather tmp/work*. That way I keep the images and rpms. | 09:51 |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC | 09:51 | |
| rburton | rj_: you remove the tmp paths from the pc file | 09:51 |
| msvb-lab | I wasn't sure bitbake would be smart enough to avoid rebuilding though, now I'm a happy guy saving 20 hours of time while rebuilding with 'rm_work'. | 09:51 |
| rburton | rj_: how depends on each upstream as it's a bug in their makefiles | 09:51 |
| msvb-lab | rburton: ...or a bug in the upstream .pc.in files right? | 09:52 |
| *** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has joined #yocto | 09:52 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 09:52 | |
| rburton | msvb-lab: sure i was counting that as part of the "make" | 09:52 |
| rj_ | rburton: Ah alright then, i did indeed remove those paths from the file and it didn't give the error after that | 09:53 |
| msvb-lab | rj_: The wierd thing is that Orocos builds correctly in other (non bitbake) environments, have you confirmed that? | 09:53 |
| msvb-lab | I can't help but wonder if there is a solution to this in some .deb or .rpm where a patch is included. | 09:53 |
| rj_ | msvb-lab: it does, it's compiled and working on the laptop next to me | 09:53 |
| msvb-lab | ...or the upstream maintainer of Orocos has the correction in the trunk of a SCM. | 09:54 |
| msvb-lab | rj_: You compiled it from scratch on the laptop or you used a binary package? | 09:54 |
| LetoThe2nd | upstream maintainers are often cross-compile ignorant. in many cases they're even other-distribution ignorant | 09:55 |
| rj_ | msvb-lab: Oh thats a good point actually, they used a deb file to install it on there... | 09:55 |
| rburton | rj_: in the ideal world you can send a patch upstream instead of sedding the paths out afterwards | 09:55 |
| msvb-lab | rj_: It's likely that the deb was build from a .src.deb (or whatever the deb sources are called) that either don't have the flaw or have a patch that corrects it, you know? | 09:55 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 09:56 | |
| msvb-lab | rj_: There might be clues to packages.ubuntu.com:<search for Orocos> and download the sources. Then look close at .pc.in and any .diff/.patch files. | 09:56 |
| rj_ | msvb-lab: if i remember correctly these deb packages are costum made | 09:57 |
| msvb-lab | rj_: Okay, but there are still sources somewhere. If not, then you'll have to reinvent the wheel and do all the work over again. | 09:58 |
| rj_ | msvb-lab: The sources are available on the orocos site yes, thats where i get them from now with my recipe | 09:58 |
| msvb-lab | Obviously if you look in laptop$ cat /usr/lib/pkgconfig/orocos-*.pc and there's junk in there with bad paths, then the problem was never corrected in the .deb either. | 09:59 |
| *** yann <yann!~yann@90.90.216.32> has quit IRC | 10:01 | |
| rj_ | msvb-lab: There isnt even a .pc file for orocos on that laptop | 10:02 |
| *** yohboy <yohboy!~yohan@162.38.36.104> has quit IRC | 10:03 | |
| rj_ | msvb-lab: Oh, nvm it's not under /usr/lib/pkgconfig but some other path | 10:03 |
| rj_ | It's pretty much the same .pc file | 10:04 |
| msvb-lab | rj_: You can always do dpkg -L to find the files corresponding to a package. | 10:04 |
| msvb-lab | rj_: So in the place of '/home/user/yocto/build/tmp/...' you find similar paths in the laptop version? | 10:05 |
| rj_ | msvb-lab: Yea, only now its /opt/somename/lib and /opt/somename/include | 10:06 |
| msvb-lab | rj_: Those paths are okay as long as they contain the actual orocos files. | 10:07 |
| rj_ | msvb-lab: Which they do | 10:07 |
| msvb-lab | It means that either the deb maintainer corrected the Makefile or .pc.in files (with a patch) or it's the bitbake environment which indirectly causes the failure, like maybe it wipes out $DESTDIR or something. | 10:08 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 10:10 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 10:12 | |
| *** blitz00 <blitz00!~stefan@unaffiliated/blitz00> has joined #yocto | 10:13 | |
| *** yohboy <yohboy!~yohan@162.38.36.104> has joined #yocto | 10:14 | |
| erbo | How is core-image-testq | 10:14 |
| erbo | how is core-image-testmaster supposed to be deploy? There seems to be some installer scripts, but when are they run? | 10:15 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 10:17 | |
| *** Ox4 <Ox4!~user@unaffiliated/zloy> has joined #yocto | 10:20 | |
| Ox4 | hello everyone | 10:20 |
| Ox4 | could somebody help me to resolve this problem ---> http://ix.io/tTd ? | 10:22 |
| Ox4 | thank you in advance | 10:22 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 10:22 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 10:22 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 10:31 | |
| *** yann <yann!~yann@LFbn-1-12676-32.w90-90.abo.wanadoo.fr> has joined #yocto | 10:32 | |
| *** sjolley1 <sjolley1!~sjolley@134.134.139.70> has quit IRC | 10:32 | |
| *** sjolley <sjolley!~sjolley@134.134.139.70> has joined #yocto | 10:32 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 10:35 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 10:40 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto | 10:47 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto | 10:55 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has quit IRC | 11:02 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 11:06 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 11:10 | |
| *** cp__ <cp__!~nighty@d246113.ppp.asahi-net.or.jp> has quit IRC | 11:13 | |
| LetoThe2nd | Ox4: well what is not clear about the error message? | 11:14 |
| LetoThe2nd | Ox4: the package lighttpd wants to install the file /www/pages/index.html, the package web-application wants to install the file /www/pages/index.html | 11:15 |
| LetoThe2nd | Ox4: that clashes, it tells you as the user to resolve the conflict. | 11:15 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 11:16 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC | 11:19 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto | 11:21 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 11:24 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto | 11:28 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 11:31 | |
| *** lexano <lexano!~lexano@216.151.180.46> has quit IRC | 11:32 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 11:38 | |
| *** phatina <phatina!55f80636@gateway/web/freenode/ip.85.248.6.54> has joined #yocto | 11:40 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 11:43 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has joined #yocto | 11:43 | |
| *** berton <berton!~berton@189.114.111.135> has joined #yocto | 11:45 | |
| *** qt-x <qt-x!~Thunderbi@217.10.196.2> has quit IRC | 11:46 | |
| *** bananadev <bananadev!~onlyester@117.6.99.240> has quit IRC | 11:47 | |
| phatina | Hi all, can you help me add include directories for CMake project? I need some additional include paths to sysroot when building a package. | 11:54 |
| *** mappy <mappy!b9691ff9@gateway/web/freenode/ip.185.105.31.249> has joined #yocto | 11:56 | |
| *** phatina <phatina!55f80636@gateway/web/freenode/ip.85.248.6.54> has quit IRC | 11:56 | |
| neverpanic | Wouldn't you usually have a Find<Component>.cmake file that you can use with find_package(<Component>), which defines a number of targets that you can just add to your local build target, and that automatically adds the required include paths? | 11:56 |
| *** phatina <phatina!55f80636@gateway/web/freenode/ip.85.248.6.54> has joined #yocto | 11:56 | |
| neverpanic | Wouldn't you usually have a Find<Component>.cmake file that you can use with find_package(<Component>), which defines a number of targets that you can just add to your local build target, and that automatically adds the required include paths? | 11:56 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 11:57 | |
| phatina | neverpanic: hm, let me see, if such package provide pkg-config file | 11:57 |
| *** tavish <tavish!~tavish@unaffiliated/tavish> has joined #yocto | 11:57 | |
| neverpanic | That would be a good solution, yes. For pkg-config in CMake, see https://cmake.org/cmake/help/latest/module/FindPkgConfig.html | 11:58 |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC | 11:59 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto | 12:00 | |
| *** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto | 12:01 | |
| *** jku <jku!~jku@192.198.151.45> has quit IRC | 12:02 | |
| *** jku <jku!~jku@192.198.151.45> has joined #yocto | 12:02 | |
| phatina | neverpanic: yeah, there's a *.pc in sysroot, which means, I have at least some entry point... | 12:02 |
| phatina | neverpanic: ok, will need to adjust some includes in sources, but .. anyway, at least something | 12:03 |
| Smitty_ | Still struggling here. I basically have the same problem as this https://lists.yoctoproject.org/pipermail/yocto/2014-September/021678.html. But, I don't understand the solution given in the final post (at the bottom). Do I really modify the static library recipe to set RDEPENDS_${PN}-dev to be empty ? | 12:09 |
| Smitty_ | How does that help ? | 12:09 |
| *** jku <jku!~jku@192.198.151.45> has quit IRC | 12:10 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 12:20 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC | 12:21 | |
| *** top21 <top21!c34b4920@gateway/web/freenode/ip.195.75.73.32> has quit IRC | 12:26 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 12:27 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 12:30 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto | 12:32 | |
| nrossi | hmmm so is it an intended feature of RSS that any task dependency (even a dependency on say foo:do_deploy) causes the recipe-sysroot population of that dependent task's sysroot components? | 12:33 |
| *** JordonWu <JordonWu!~quassel@221.226.9.57> has quit IRC | 12:35 | |
| *** jonakn <jonakn!c33c449c@gateway/web/freenode/ip.195.60.68.156> has quit IRC | 12:38 | |
| *** aratiu <aratiu!~adi@80.97.64.55> has quit IRC | 12:38 | |
| *** Saur <Saur!~pkj@proxy02.se.axis.com> has quit IRC | 12:39 | |
| *** aratiu <aratiu!~adi@80.97.64.55> has joined #yocto | 12:40 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 12:41 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 12:45 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 12:46 | |
| PinkSnake | hi all i have a recipe inherit for module but sometimes i have to rebuild kernel before rebuild my custom module ... Someone have already seen that ? | 12:47 |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 12:51 | |
| nrossi | PinkSnake: if your kernel or its config changed it will rebuild. You can check the reason why bitbake ignored the previous state with e.g. "bitbake-diffsigs -t linux-yocto compile" | 12:53 |
| *** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-bdlalbqwngyyggee> has quit IRC | 12:53 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC | 12:53 | |
| *** lamego <lamego!jose@nat/intel/x-whucdvjymmjcljmt> has joined #yocto | 12:54 | |
| PinkSnake | @nrossi i'm using a custom kernel recipe so i have maybe forgotten something inside. i'm going to try your trick first thx ;) | 12:54 |
| *** Aethenelle <Aethenelle!~Aethenell@107.138.98.226> has joined #yocto | 12:56 | |
| neverpanic | Smitty_: Yocto by default omits creating empty packages, so your main package is probably not being created if you only ship a static library | 12:56 |
| neverpanic | Smitty_: The default value for RDEPENDS_${PN}-dev includes "${PN}", though, so the dependency is there by default | 12:57 |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has quit IRC | 12:57 | |
| neverpanic | Smitty_: So when you attempt to install ${PN}-dev, it fails because it rdepends on ${PN}, which doesn't exist. Potential solutions include: | 12:57 |
| neverpanic | Smitty_: (a) ALLOW_EMPTY_${PN} = "1", which will create an empty ${PN} package | 12:58 |
| *** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has quit IRC | 12:58 | |
| neverpanic | Smitty_: (b) RDEPENDS_${PN}-dev = "", which will avoid the dependency on the empty package (at the expense of requiring your users to manually install ${PN}-staticdev) | 12:58 |
| *** zeddii_home <zeddii_home!~zeddii_ho@CPEe8de27b71faa-CM64777d5e8820.cpe.net.cable.rogers.com> has joined #yocto | 12:58 | |
| neverpanic | Smitty_: (c) RDEPENDS_${PN}-dev = "${PN}-staticdev", which makes your -dev package depend on the static lib | 12:58 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 12:59 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 13:04 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto | 13:09 | |
| Smitty_ | This terminology "ALLOW_EMPTY¶ Specifies if an output package should still be produced if it is empty." means : Because I am producing a static library (libX.a, with associated headers) which no other package has listed as a dependency (no one else is using this library yet), I am not producing a package which will end up in the OS image ? | 13:10 |
| Smitty_ | Is the package being built ? | 13:10 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 13:12 | |
| *** tavish <tavish!~tavish@unaffiliated/tavish> has quit IRC | 13:15 | |
| *** tavish_ <tavish_!~tavish@unaffiliated/tavish> has joined #yocto | 13:15 | |
| Smitty_ | So, in trying to undertsnad this issue better, I start with a HEAD checkout of Yocto, and build core-image-minimal. Now I follow this: https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles#Using_a_new_layer_for_recipes | 13:15 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 13:15 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 13:17 | |
| Smitty_ | I am confused already. If the layer already exists in git, why do I need to clone it, why doesn't yocto do that for me ? Why can't I just say that I want to add that layer and reference the layer location in https://github.com/DynamicDevices/meta-example somehow ? | 13:19 |
| *** ironzorg <ironzorg!~ironzorg@ironzorg.fr> has joined #yocto | 13:19 | |
| PinkSnake | @nrossi everything looks ok according to the hashes, if the kernel module recipe inherit from module we don't have to add any dependencies right ? | 13:20 |
| ironzorg | hi, is there a way I can import a custom module (that I put in my-meta/lib/mymodule for now) from an anonymous python function in a recipe? or do I have to manually set sys.path so that python can find it? | 13:21 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 13:22 | |
| nrossi | PinkSnake: inheriting just module should be fine, however you were saying that your kernel was rebuilding, which is likely not related to your module but some other change you are making. diffsigs should show you the variables that you changed that caused the rebuild. | 13:22 |
| PinkSnake | @ironzorg http://wiki.kaeilos.com/index.php/Howto_build_a_kernel_module_out_of_the_kernel_tree | 13:22 |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 13:23 | |
| rburton | ironzorg: have you tried import mymodule? | 13:23 |
| *** madisox <madisox!~madison@216-75-232-11.static.wiline.com> has joined #yocto | 13:24 | |
| *** tavish_ <tavish_!~tavish@unaffiliated/tavish> has quit IRC | 13:24 | |
| *** tavish_ <tavish_!~tavish@unaffiliated/tavish> has joined #yocto | 13:24 | |
| *** Guest12873 <Guest12873!~arun@125.16.167.59> has quit IRC | 13:25 | |
| ironzorg | PinkSnake: I meant a python module, not a kernel one | 13:25 |
| ironzorg | rburton: yes it's not in the path so it's not loaded | 13:26 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 13:26 | |
| *** JPEWhacker <JPEWhacker!cc4da374@gateway/web/freenode/ip.204.77.163.116> has joined #yocto | 13:26 | |
| ironzorg | I want to be able to load a module stored in an arbitrary layer, is that handled by bitbake automatically (like do I have to put my module in a certain sub-directory of the module and that's it), or is it non trivial? | 13:27 |
| PinkSnake | @ironzorg my bad i need a coffee i think... | 13:27 |
| ironzorg | np | 13:27 |
| nrossi | ironzorg: sure your layer is in BBPATH? | 13:30 |
| ironzorg | yes | 13:30 |
| rburton | ironzorg: does the layer.conf set BBPATH? | 13:31 |
| ironzorg | so this should work by itself? having modules in a meta's `lib` directory should work off the bat? | 13:31 |
| nrossi | yes | 13:31 |
| rburton | my setup is definitely adding <layer>/lib to sys.path | 13:31 |
| rburton | so i suspect that works on BBPATH in layer.conf | 13:31 |
| ironzorg | `BBPATH .= ":${LAYERDIR}"` yes | 13:32 |
| PinkSnake | @nrossi ok i found it, a change from our device-tree repo, but i don't understand why Yocto doesn't do the rebuild the kernel before rebuild modules | 13:32 |
| rburton | ironzorg: WARNING: m4-1.4.18-r0 do_test: /home/ross/Yocto/poky/meta-poky/lib /home/ross/Yocto/poky/build-selftest/lib /home/ross/Yocto/poky/meta/lib /home/ross/Yocto/poky/meta-yocto-bsp/lib /home/ross/Yocto/poky/meta-selftest/lib /home/ross/Yocto/meta-ross/lib /home/ross/Yocto/meta-intel/lib /home/ross/Yocto/meta-intel/common/lib /home/ross/Yocto/poky/bitbake /home/ross/Yocto/poky/bitbake/lib /home/ross/Yocto/poky/bitbake/bin /usr/lib/python3.4 /usr/lib/p | 13:32 |
| rburton | thats my sys.path inside a task | 13:32 |
| kergoth | the python search path is modified by oe_import(d) in base.bbclass. depending on when your varaible is expanded, you could try importing it before it's modified | 13:32 |
| kergoth | keep that in mind | 13:32 |
| rburton | *maybe* anon python is executed too early | 13:32 |
| kergoth | anon python should be fine | 13:32 |
| *** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has quit IRC | 13:33 | |
| *** mckoan is now known as mckoan|away | 13:35 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 13:37 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has joined #yocto | 13:40 | |
| *** top22 <top22!c34b4920@gateway/web/freenode/ip.195.75.73.32> has joined #yocto | 13:40 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 13:42 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC | 13:42 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 13:45 | |
| *** Aethenelle <Aethenelle!~Aethenell@107.138.98.226> has quit IRC | 13:50 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC | 13:53 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 13:55 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 14:00 | |
| *** AndersD <AndersD!~anders@194-237-220-218.customer.telia.com> has quit IRC | 14:01 | |
| *** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has left #yocto | 14:03 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 14:03 | |
| neverpanic | Smitty_: No, that's not it. You're producing a static library, PACKAGES contains both "${PN}" and "${PN}-staticlib" and FILES_${PN}-staticlib contains /usr/lib/lib*.a by default, so your installed static library gets packaged in ${PN}-staticlib. If you don't have any files in ${PN}, it will end up empty and won't be created. | 14:04 |
| neverpanic | Smitty_: None of this is related to whether some other recipe or package depends on this. | 14:04 |
| *** chbae <chbae!~chbae@59.10.135.122> has joined #yocto | 14:05 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto | 14:09 | |
| *** jairglez <jairglez!~jairdeje@134.134.139.76> has joined #yocto | 14:10 | |
| *** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has quit IRC | 14:12 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 14:13 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 14:15 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 14:16 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 14:18 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC | 14:19 | |
| *** marka <marka!~masselst@128.224.252.2> has joined #yocto | 14:23 | |
| *** phatina <phatina!55f80636@gateway/web/freenode/ip.85.248.6.54> has quit IRC | 14:28 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 14:28 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 14:28 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 14:33 | |
| *** groleo1 <groleo1!~groleo@188.27.9.47> has joined #yocto | 14:33 | |
| *** rj_ <rj_!58d39085@gateway/web/freenode/ip.88.211.144.133> has quit IRC | 14:33 | |
| *** tf <tf!~tomas@178.79.160.5> has quit IRC | 14:34 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has quit IRC | 14:34 | |
| *** Saur <Saur!~pkj@proxycluster.se.axis.com> has joined #yocto | 14:35 | |
| *** groleo <groleo!~groleo@188.27.9.47> has quit IRC | 14:35 | |
| *** tf_ <tf_!~tomas@r-finger.com> has joined #yocto | 14:35 | |
| *** gtristan <gtristan!~tristanva@110.11.179.89> has joined #yocto | 14:39 | |
| *** Ox4` <Ox4`!~user@5.53.119.222> has joined #yocto | 14:40 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC | 14:41 | |
| Smitty_ | Do I have to set ${PN}-staticlib ? | 14:42 |
| *** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has quit IRC | 14:42 | |
| *** Ox4 <Ox4!~user@unaffiliated/zloy> has quit IRC | 14:44 | |
| *** tavish_ <tavish_!~tavish@unaffiliated/tavish> has quit IRC | 14:44 | |
| *** tavish__ <tavish__!~tavish@unaffiliated/tavish> has joined #yocto | 14:45 | |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has joined #yocto | 14:48 | |
| *** frsc <frsc!~frsc@80.149.173.68> has quit IRC | 14:48 | |
| *** chbae <chbae!~chbae@59.10.135.122> has quit IRC | 14:49 | |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC | 14:51 | |
| *** ayaka <ayaka!~ayaka@110.90.61.253> has joined #yocto | 14:52 | |
| ayaka | I want to access a files meta/recipes-multimedia/ of yocto in bsp meta | 14:53 |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto | 14:53 | |
| ayaka | how should I set it in FILESEXTRAPATHS | 14:53 |
| PinkSnake | @ayaka i think it depends what you want to do with this files | 14:54 |
| ayaka | PinkSnake, oh it is a patch file | 14:55 |
| ayaka | for example I want to access meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/ in my layer meta, as I offer a customize version for it | 14:56 |
| ayaka | but it could inherit most of patches from the original version | 14:56 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 14:58 | |
| neverpanic | Smitty_: What do you mean with "set ${PN}-staticlib"? You cannot "set" a package, so I'm not sure what you mean. | 14:59 |
| *** t0mmy <t0mmy!~tprrt@217.114.203.196> has joined #yocto | 15:03 | |
| Smitty_ | Dio I have to populate that value in some file ? | 15:08 |
| *** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has joined #yocto | 15:09 | |
| ayaka | PinkSnake, I have known, the COREBASE, thanks | 15:10 |
| majuk | Is there a simple way to pull in a package that lacks a recipe? Looking to include ruby2.2-dev in a build. | 15:13 |
| *** ironzorg <ironzorg!~ironzorg@ironzorg.fr> has left #yocto | 15:13 | |
| majuk | I imagine not. | 15:13 |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.76> has joined #yocto | 15:14 | |
| *** Aethenelle <Aethenelle!~Aethenell@mobile-166-175-56-82.mycingular.net> has joined #yocto | 15:15 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.76> has quit IRC | 15:15 | |
| rburton | majuk: what do you mean? | 15:17 |
| majuk | rburton: I want to include the package ruby-dev in my system and there is no recipe I can find. | 15:19 |
| rburton | bitbake ruby will generate ruby-dev | 15:19 |
| rburton | recipes built many packages | 15:19 |
| *** mappy <mappy!b9691ff9@gateway/web/freenode/ip.185.105.31.249> has quit IRC | 15:20 | |
| majuk | Well it might be /generated/ but it is not ending up in my system. "gem install mmap" complains it can't find the ruby.h lib | 15:21 |
| majuk | Krogoth branch fyi | 15:21 |
| *** ed2 <ed2!~Adium@192.198.151.44> has quit IRC | 15:23 | |
| joshuagl | development packages aren't installed by default, you'll need to add ruby-dev (or similar) to your IMAGE_INSTALL | 15:24 |
| *** Guma <Guma!~Guma@c-67-184-64-21.hsd1.il.comcast.net> has quit IRC | 15:25 | |
| rburton | majuk: yeah you'll need to add it to your image. | 15:26 |
| neverpanic | Smitty_: What value? ${PN}-staticlib is a package name, packages are defined in a recipe in the PACKAGES variable; ${PN}-staticlib is part of the default value of PACKAGES, so you don't have to add it manually. | 15:29 |
| majuk | rburton: joshuagl: Thanks. I... well, I assumed there wasn't a recipe. I really need to get better at navigating the file structure. | 15:32 |
| rburton | majuk: remember that eg the ruby dev files are going to be part of the ruby build | 15:33 |
| rburton | so the ruby recipe will generate them | 15:33 |
| kergoth | rburton: FYI, Mentor *is* intending to volunteer to maintain some recipes, I'm just gathering volunteers from my team and figuring out which ones in particular to volunteer for, since I tend to dabble in either classes or a random hodgepodge, nothing specific jumps out at me as of yet. Just so you know we're not ducking our responsibilities here :) | 15:33 |
| * kergoth yawns | 15:34 | |
| *** dv_ <dv_!~quassel@62-178-118-86.cable.dynamic.surfer.at> has quit IRC | 15:38 | |
| *** dv_ <dv_!~quassel@62-178-118-86.cable.dynamic.surfer.at> has joined #yocto | 15:40 | |
| *** ant_work <ant_work!~ant__@host108-181-dynamic.31-79-r.retail.telecomitalia.it> has quit IRC | 15:41 | |
| *** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 15:45 | |
| *** rajm <rajm!~robertmar@167.98.27.226> has quit IRC | 15:48 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 15:49 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC | 15:52 | |
| *** Aethenelle <Aethenelle!~Aethenell@mobile-166-175-56-82.mycingular.net> has quit IRC | 15:53 | |
| *** t0mmy <t0mmy!~tprrt@217.114.203.196> has quit IRC | 15:54 | |
| *** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 15:55 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 15:55 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto | 15:57 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto | 15:57 | |
| *** zeenix <zeenix!~zeenix@83.218.80.243> has quit IRC | 15:58 | |
| rburton | kergoth: thanks, good to know | 16:02 |
| kergoth | np | 16:03 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 16:04 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 16:05 | |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto | 16:05 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 16:05 | |
| *** yohboy <yohboy!~yohan@162.38.36.104> has quit IRC | 16:09 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 16:09 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 16:11 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.82> has joined #yocto | 16:12 | |
| *** blitz00 <blitz00!~stefan@unaffiliated/blitz00> has quit IRC | 16:18 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto | 16:18 | |
| *** Aethenelle <Aethenelle!~Aethenell@199.15.128.78> has joined #yocto | 16:19 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC | 16:19 | |
| *** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC | 16:21 | |
| *** toscalix <toscalix!~toscalix@80.91.70.201> has quit IRC | 16:23 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 16:26 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 16:27 | |
| *** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 16:27 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 16:27 | |
| *** martinkelly <martinkelly!~martin@65-122-179-226.dia.static.qwest.net> has quit IRC | 16:33 | |
| *** sgw_ <sgw_!~sgw_@134.134.139.78> has quit IRC | 16:34 | |
| *** martinkelly <martinkelly!~martin@66-162-141-202.static.twtelecom.net> has joined #yocto | 16:35 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC | 16:40 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto | 16:40 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC | 16:41 | |
| *** ayaka <ayaka!~ayaka@110.90.61.253> has left #yocto | 16:41 | |
| *** geoffrey_l <geoffrey_l!~geoffrey_@lns-bzn-39-82-255-32-23.adsl.proxad.net> has quit IRC | 16:45 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto | 16:47 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 16:48 | |
| *** stephano <stephano!~stephano@134.134.139.73> has joined #yocto | 16:49 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 16:50 | |
| *** sgw_ <sgw_!sgw_@nat/intel/x-xyknssroyufdjwmv> has joined #yocto | 16:53 | |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC | 16:56 | |
| *** sjolley1 <sjolley1!~sjolley@134.134.139.70> has joined #yocto | 16:57 | |
| *** sjolley <sjolley!~sjolley@134.134.139.70> has quit IRC | 16:57 | |
| *** sjolley1 <sjolley1!~sjolley@134.134.139.70> has quit IRC | 16:59 | |
| *** gtristan <gtristan!~tristanva@110.11.179.89> has quit IRC | 17:00 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC | 17:01 | |
| *** gtristan <gtristan!~tristanva@110.11.179.89> has joined #yocto | 17:01 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto | 17:03 | |
| *** martinkelly <martinkelly!~martin@66-162-141-202.static.twtelecom.net> has quit IRC | 17:03 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 17:07 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 17:10 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 17:15 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 17:16 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto | 17:16 | |
| *** grma <grma!~gruberm@80.93.38.128> has quit IRC | 17:17 | |
| *** martinkelly <martinkelly!~martin@65-122-179-226.dia.static.qwest.net> has joined #yocto | 17:22 | |
| *** yann <yann!~yann@LFbn-1-12676-32.w90-90.abo.wanadoo.fr> has quit IRC | 17:22 | |
| *** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto | 17:26 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 17:28 | |
| *** sjolley <sjolley!~sjolley@134.134.139.77> has joined #yocto | 17:30 | |
| *** stephano <stephano!~stephano@134.134.139.73> has quit IRC | 17:33 | |
| *** sjolley <sjolley!~sjolley@134.134.139.77> has quit IRC | 17:37 | |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC | 17:38 | |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has quit IRC | 17:39 | |
| *** mtas <mtas!sid127809@gateway/web/irccloud.com/x-hcctkmyyofbtpcln> has quit IRC | 17:42 | |
| *** Ox4` <Ox4`!~user@5.53.119.222> has quit IRC | 17:47 | |
| *** mtas <mtas!sid127809@gateway/web/irccloud.com/x-yvybbyfgpbjzzhde> has joined #yocto | 17:47 | |
| *** sjolley <sjolley!~sjolley@134.134.139.77> has joined #yocto | 17:49 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.82> has quit IRC | 17:50 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.82> has joined #yocto | 17:50 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.82> has quit IRC | 17:53 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC | 17:58 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.74> has joined #yocto | 18:00 | |
| *** marka <marka!~masselst@128.224.252.2> has quit IRC | 18:07 | |
| *** marka <marka!~masselst@128.224.252.2> has joined #yocto | 18:07 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.74> has quit IRC | 18:10 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto | 18:12 | |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has joined #yocto | 18:17 | |
| *** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto | 18:19 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 18:24 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 18:29 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC | 18:30 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 18:30 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 18:32 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 18:35 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has joined #yocto | 18:36 | |
| *** groleo1 <groleo1!~groleo@188.27.9.47> has quit IRC | 18:39 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 18:39 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has joined #yocto | 18:41 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.82> has joined #yocto | 18:51 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.82> has quit IRC | 18:51 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC | 18:59 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC | 19:03 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.72> has joined #yocto | 19:04 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC | 19:04 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto | 19:05 | |
| *** Smitty__ <Smitty__!5843b8bc@gateway/web/freenode/ip.88.67.184.188> has joined #yocto | 19:08 | |
| *** Kakounet1 <Kakounet1!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has joined #yocto | 19:10 | |
| Smitty__ | OK, even more confusion. Why do I modify conf/bblayers.conf, that file is generated ! If I check out a source tree in which I have added a new layer, why doesn't conf/bblayers.conf get generated with that layer already in the file ? | 19:11 |
| *** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has quit IRC | 19:12 | |
| *** Kakounet1 is now known as Kakounet | 19:12 | |
| rburton | because there is no assumption that you have layers inside your source tree | 19:12 |
| rburton | none of mine are | 19:12 |
| rburton | a sample gets generated if you oe-init-build-env from an empty build tree | 19:13 |
| rburton | after that its a configuration file like local.conf | 19:13 |
| Smitty__ | But if I do add layers to the source tree, I expect them to be found and built automatically - how does it make sense to not do that ? | 19:13 |
| rburton | patches welcome. if you've a mega-repo with all your layers in you can just provide a sample bblayers.conf | 19:15 |
| rburton | which will get used when someone does oe-init-build-env on an empty tree | 19:15 |
| rburton | so they have nothing to do | 19:15 |
| Smitty__ | ??? | 19:15 |
| Smitty__ | You've lost me. | 19:15 |
| rburton | when you run oe-init-build-env with an empty build directory, the script will write a bblayers.conf for you | 19:16 |
| Smitty__ | And, what will be in it ? | 19:16 |
| kergoth | bblayers.conf isn't "generated", it's copied from a template | 19:16 |
| kergoth | that's all | 19:16 |
| rburton | the template is bblayers.conf.sample | 19:16 |
| rburton | in meta/conf/bblayers.conf.sample, and other layers can provide their own. poky does this. | 19:16 |
| Smitty__ | I must be missing somehting really fundamental | 19:17 |
| rburton | the key point is that bblayers.conf isn't a generated file | 19:17 |
| rburton | its a configuration file for you, and a convenient starting point is provided | 19:17 |
| rburton | same as for local.conf | 19:17 |
| rburton | we *could* just give you an empty local.conf | 19:17 |
| rburton | but no, you get a sample to edit | 19:18 |
| Smitty__ | The whole point of the Yocto project is to make it relatively easy to produce an OS image, an SDK (a bad term for a toolchain and sysroots) for that OS image, a Board Support Package, or maybe something else that I haven't learned about yet. | 19:18 |
| Smitty__ | Right ? | 19:18 |
| rburton | can't argue with that | 19:19 |
| Smitty__ | And, the Yocto project generously provides a basic OS image so that dumb developers like me don't have to start from nothng | 19:19 |
| Smitty__ | right ? | 19:19 |
| rburton | it provides sample recipes so you can build your own images yes | 19:20 |
| Smitty__ | By that I mean, the Yocto project provides the "source" for pre-defined layers which when built (e.g. core-image-minimal) produce a bootable OS image | 19:21 |
| rburton | yes | 19:21 |
| Smitty__ | When I clone the current git://git.yoctoproject.org/poky, I receive all those recipies, but then before I build, I "have to" run oe-init-build-env, This magically created a build directory with a bunch of configuration files which then allows me to build the layers I received | 19:24 |
| kergoth | samples / examples are provided, it's expected that nearly everyone is going to have to heavily customize from there | 19:24 |
| kergoth | it's not magic, it copies a couple of example files, that's all | 19:25 |
| rburton | yes the configuration files are copied from meta-poky/conf/*.sample | 19:25 |
| rburton | as you cloned poky, and that is configured to use the samples in meta-poky | 19:25 |
| rburton | if you cloned oe-core directly, it would just configure the meta/ layer on its own | 19:26 |
| kergoth | by all means submit issues if you have ideas for how to improve the usability | 19:26 |
| Smitty__ | So, not, if I add my own layer, how do I get that layer to automatically be available ? | 19:26 |
| rburton | as part of your distro layer you can provide your own samples which pull the right layers in the right order | 19:27 |
| Smitty__ | Sorry, not being critical, trying to understand the logic | 19:27 |
| Smitty__ | I guess I was under the impression that oe-init... was looking at what layers were available to be built | 19:28 |
| rburton | yeah, it's not | 19:28 |
| Smitty__ | OK - got it | 19:28 |
| Smitty__ | that needs to be explained | 19:28 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 19:28 | |
| Smitty__ | I think al lot of people will be under the same impression. | 19:29 |
| majuk | Documentation is hard. | 19:29 |
| Smitty__ | Indeed | 19:29 |
| rburton | Smitty_: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-core-script | 19:29 |
| rburton | "The OpenEmbedded build system uses the template configuration files, which are found by default in the meta-poky/conf directory in the http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#source-directory. See the "http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#creating-a-custom-template-configuration-directory" section in the Yocto Project Development Manual for more information." | 19:29 |
| Smitty__ | If it's hard to make, it should be hard to understand ! (or somehting like that) | 19:29 |
| kergoth | it specifically says, when you source the file, that it copied new files because they didn't yet exist. i think that makes it fairly clear that it's just giving you a starting point | 19:29 |
| * kergoth shrugs | 19:29 | |
| rburton | i guess the quick start could mention that the files are copied from templates and not inferred from the eather | 19:30 |
| rburton | bug and or patches welcome | 19:30 |
| * rburton -> somewhere that isn't my desk as its 20:30 | 19:31 | |
| JEEB | yes, that's a good time to realize that you ain't no longer where you should be :) | 19:38 |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto | 19:40 | |
| *** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC | 19:43 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto | 19:45 | |
| *** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has joined #yocto | 19:46 | |
| *** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC | 19:47 | |
| *** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has quit IRC | 19:54 | |
| *** tavish__ <tavish__!~tavish@unaffiliated/tavish> has quit IRC | 19:58 | |
| *** dscully <dscully!~dscully@24.249.154.174> has joined #yocto | 19:59 | |
| *** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC | 20:00 | |
| *** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC | 20:00 | |
| *** caiortp <caiortp!~inatel@131.221.240.226> has joined #yocto | 20:01 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 20:02 | |
| dscully | Does anyone know what recipe I would need to modify to change the contents of /lib/systemd/system/getty@.service ? I found the file to override systemd's serial getty but not getty | 20:04 |
| *** pohly <pohly!~pohly@p5DE8EB79.dip0.t-ipconnect.de> has quit IRC | 20:06 | |
| kergoth | doesn'mt systemd already provide a way to override /lib/systemd/system/ contents by putting the override files in /etc? i dont recallt he exact paths, but see the systemd man pages. in which case you could just install a new package that puts it in /etc | 20:07 |
| kergoth | otherwise do a bitbake systemd; then make use of `recipetool appendfile` | 20:07 |
| kergoth | whose whole purpose is to ease overriding of files based on target path | 20:07 |
| kergoth | :) | 20:07 |
| *** aehs29 <aehs29!~aehernan@134.134.139.76> has joined #yocto | 20:08 | |
| dscully | Ah, I forgot about overrides. I will check that out, thanks! | 20:08 |
| rburton | dscully: yes easy way is to just drop a file into /etc instead | 20:08 |
| aehs29 | Does anyone know if we've got a good reason to base our ARM bsps on armv5? | 20:09 |
| aehs29 | by our I mean the ones that are created with the yocto-bsp script | 20:10 |
| *** john <john!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto | 20:10 | |
| kergoth | aren't the layers created by yocto-bsp just examples anyway? i doubt they're of any use iwthout heavy modification anyway | 20:10 |
| *** john is now known as Guest26095 | 20:11 | |
| *** john1 <john1!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto | 20:11 | |
| aehs29 | kergoth: yeah they are supposed to be templates basically, but for example, the script asks if you want SMP which is not supported on armv5 | 20:11 |
| Smitty__ | So, does it make sense to modify my cloned oe-init... script (or whatever it calls) to append my layers details, or modify the meta-poky/conf files to include my layers details ? | 20:11 |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto | 20:12 | |
| kergoth | Smitty__: that's up to you. some folks put bblayers.conf in source control, others script it (i.e. run a script that sources oe-init-build-env and then runs bitbake-layers add-layer <your layer path>), and yet others write custom setup scripts rather than using oe-init-build-env at all | 20:12 |
| aehs29 | kergoth: before fixing the script I wanted to ask if anyone had other info | 20:12 |
| kergoth | and of course some folks just prep the buid ldir manually | 20:13 |
| kergoth | aehs29: ah, fair enough | 20:13 |
| rburton | Smitty_: a .templateconf at the top level can set TEMPLATECONF=where/the/templates/are | 20:14 |
| kergoth | yeah, that's a good way to go if your setup is relatively fixed | 20:14 |
| Smitty__ | So, maybe I am thinking about the whole thing wrong still. | 20:15 |
| kergoth | there are lots of layers around that provide a lot of different functionalilty, and some aren't necessarily well behaved, depending on where you got them, so we would *not* want to automatically incldue every layer you have around, even if it was trivial to locate them, which it almost certainly isn't | 20:16 |
| kergoth | in some cases just including a layer in bblayers.conf can alter your build (though we're moving to make it so such behavior isn't yocto compatible) | 20:17 |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto | 20:17 | |
| Smitty__ | Sure, but the source of the project is not in the build directory. I am trying to figure out the "right" way to add a layer into my cloned poky so that I produce poky+mylayer with just the source, not modifying anythinng produce into the build dir. | 20:18 |
| Smitty__ | without modifying anything that already works unnecessarily | 20:19 |
| kergoth | 'add a layer into my cloned poky' really doesn't make sense. you can put a layer anywhere on your disk, as long as you point bblayers.conf to it :) | 20:19 |
| Smitty__ | Yeah, well, that's sloppy | 20:20 |
| Smitty__ | The entire project should reside within one source tree, surely. | 20:20 |
| Smitty__ | I guess it's the classic requirement: A developer should be able to git clone my project, and have everything he needs to start working on anything related to my source code | 20:22 |
| kergoth | that's not the case with a ton of git based projects | 20:23 |
| kergoth | monolithic source trees aren't used often with git | 20:23 |
| kergoth | see how android's sources are handled, for example. countless individual git repositories pulled down with 'repo' via an xml manifest | 20:23 |
| rburton | Smitty_: if you have a monolithic repo which embeds oe-core + bitbake + other layers, then you can just drop in a .templateconf at the top and you're sorted | 20:24 |
| rburton | literally none of my layers are under the same directory as poky or oe-core | 20:24 |
| rburton | (mainly because I have about 20 checked out) | 20:24 |
| Smitty__ | why not ? | 20:24 |
| rburton | because adding meta-clang means the world rebuilds | 20:24 |
| rburton | meta-oe until incredibly recently changed how the X server started | 20:24 |
| rburton | (i mix and match and add and remove as required on a daily basis) | 20:25 |
| rburton | but mainly because they're all separate layers so they're all checked out individually | 20:25 |
| Smitty__ | But the whole point of Yocto is the production of OS images (as stated before). Why would you be changing things frequently ? | 20:26 |
| rburton | because thats my job | 20:26 |
| rburton | don't assume that everyone has a monolithic repo because that's not true | 20:27 |
| rburton | anyway i've told you how to fix the problem you had - .templateconf in the top level of your monolithic repo | 20:27 |
| *** john1 <john1!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC | 20:29 | |
| Smitty__ | I'm trying to get a better understanding of the intended usage paradigm of Yocto becuase it seems like without some more fundamental understanding, I am missing the basic knowledge required to be able to solve my own problems instead of always asking for help | 20:30 |
| rburton | don't try to learn everything in a week - the problem was "can i customise bblayers" and the answer is yes | 20:30 |
| *** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto | 20:30 | |
| rburton | to solve the problem yourself you could have followed the flow from oe-init-build-env | 20:31 |
| rburton | that gets you to scripts/oe-buildenv-setup or something, which does the cp | 20:31 |
| Smitty__ | So far tonight, I discovered that those files in conf aren't generated. That totally changed my perception of what I was doing | 20:31 |
| *** marka <marka!~masselst@128.224.252.2> has quit IRC | 20:39 | |
| Smitty__ | I looked at oe-init-build-env and was immediately lost over the test for BASH_SOURCE and ZSH_NAME (trying to detect from where the script is being sourced ? - this is the wrong way to do it) Then unsetting BBSERVER (what's that for ?, why is it unset, then tested for being null, then set again later) Absolutely no meaning comments explaining why any of that is being done, so I'm left no better off than when I started. | 20:40 |
| aehs29 | rburton: could you elaborate a little more on the python multilib bug?, I'm not that familiar with mulitlib, as far as I can see, when enabling multilib we are putting files under /usr/lib64 which I think its the way its supposed to be, what I dont know is what the behavior of lib64-$PN should be | 20:43 |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 20:47 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto | 20:49 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 20:50 | |
| kergoth | Smitty__: there's no standard way to get the path to a shell script which is being sourced. some shells set $0, plenty don't | 20:54 |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto | 20:54 | |
| rburton | aehs29: its the /usr/bin/python3-config file that conflicts | 20:55 |
| Smitty__ | sure, but in oe-init.. the test is a bit strange. it took me a long time just to understand what was being attempted. | 20:56 |
| *** lamego <lamego!jose@nat/intel/x-whucdvjymmjcljmt> has quit IRC | 20:57 | |
| kergoth | i don't really see what's all that strange about it. if you're in bash, we use bash's method, if your'e in zsh, we use zsh's method | 20:57 |
| kergoth | since as i said there's no stnadard mechanism | 20:57 |
| * kergoth shrugs | 20:57 | |
| rburton | Smitty_: don't worry about every line, it ends up calling build-setup and that has clear operations on bblayers.conf | 20:58 |
| kergoth | indeed | 21:00 |
| kergoth | Smitty__: on the repo management side of things, right now yocto doesn't force anything on you. you can use git-subtree or combo-layer to make a monolithic repo like poky does (poky uses combo-layer), or use submodules or repo or myrepos or whatever works best for you. intel has a script that pulls all the layers from the layer index, if you like that idea better. but i'd set that aside for now and focus on getting your layers configured first | 21:00 |
| *** Smitty_ <Smitty_!86bfdc47@gateway/web/freenode/ip.134.191.220.71> has quit IRC | 21:00 | |
| rburton | deep-dive too far and you'll be staring at the copy-on-write logic in bitbake and that's just one step away from cthulhu | 21:00 |
| kergoth | haha, true that | 21:01 |
| kergoth | using classes as objects is just twisted | 21:01 |
| Smitty__ | kergoth: I have no idea how I would do any of what you mentioned above. I am currently failing at simply getting meta-example to build into the SDK | 21:04 |
| kergoth | edit bblayers.conf, put your layer path in BBLAYERS, do a build | 21:05 |
| kergoth | a lot of your questions are more oriented to the long term maintenance of the thing, set that aside and just manually configrue and build for now :) | 21:05 |
| *** sjolley <sjolley!~sjolley@134.134.139.77> has quit IRC | 21:06 | |
| Smitty__ | I keep hearing that, and it is what I really don't understand. How can you "just do it" without having a clue what you are doing ? | 21:06 |
| *** sjolley <sjolley!~sjolley@134.134.139.77> has joined #yocto | 21:07 | |
| Smitty__ | Especially when things like editing a temporary (build directory) file are clearly not a permanent solution, and so a waste of time | 21:07 |
| kergoth | i don't understand the question. there are plenty of docs and gettings tarted guides around. most folks would follow those, and go from there | 21:07 |
| Smitty__ | I'm following this one: https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles#Build_an_example_project_on_the_host_for_testing_.28optional.29 | 21:08 |
| *** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC | 21:08 | |
| Smitty__ | And in it, the recommended method is to edit conf/layers.conf and conf/bbconfig.conf which clearly is not a permanent solution for adding a layer | 21:08 |
| kergoth | i don't see how manually doing something once is a waste of time. you're exploring how the system works. automating that process when you need to is trivial | 21:08 |
| * paulg thinks he's heard that about marriage. | 21:11 | |
| Smitty__ | Because it doesn't solve the problem of adding a layer "the right way" it's a temporary solution to a problem I already know I have to solve in a permanent manner. Why not just explain the permanent solution in the docs, why even bother explaining a temporary solution - that doesn't lead to learning how the system works, it's a "hack" to make the system do something that it won't do the next time | 21:11 |
| *** caiortp <caiortp!~inatel@131.221.240.226> has quit IRC | 21:12 | |
| kergoth | You're assuming that everyone learns like you. Not everyone learns bottom-up, plenty of folks learn top-down | 21:12 |
| kergoth | further, there *is no standard* for repository management or setup scripts | 21:13 |
| kergoth | not every solution satisfies the requirements for every company | 21:13 |
| *** sjolley <sjolley!~sjolley@134.134.139.77> has quit IRC | 21:13 | |
| Smitty__ | Bed time. | 21:15 |
| Smitty__ | Thanks for your time. I honestky appreciate it very much | 21:16 |
| *** berton <berton!~berton@189.114.111.135> has quit IRC | 21:16 | |
| kergoth | np, there's obviously a bit of a learning curve, here, any suggestions on how to improve that are appreciated | 21:16 |
| *** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 21:16 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 21:19 | |
| *** stephano <stephano!~stephano@134.134.139.76> has joined #yocto | 21:29 | |
| *** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has joined #yocto | 21:29 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 21:30 | |
| *** emikulin <emikulin!~emikulin@76.77.65.2> has joined #yocto | 21:31 | |
| *** ant_home <ant_home!~ant__@host134-11-dynamic.32-79-r.retail.telecomitalia.it> has joined #yocto | 21:31 | |
| *** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 21:32 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 21:32 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto | 21:32 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-enmhdawmggxollnv> has joined #yocto | 21:35 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 21:39 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto | 21:40 | |
| *** emikulin <emikulin!~emikulin@76.77.65.2> has quit IRC | 21:41 | |
| *** emikulin <emikulin!~emikulin@76.77.65.2> has joined #yocto | 21:41 | |
| *** emikulin is now known as itseris | 21:41 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-enmhdawmggxollnv> has quit IRC | 21:42 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 21:44 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 21:44 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto | 21:44 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-nbastqmtxbwnxrwo> has joined #yocto | 21:46 | |
| *** gtristan <gtristan!~tristanva@110.11.179.89> has quit IRC | 21:48 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 21:48 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 21:50 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC | 21:51 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto | 21:58 | |
| *** stephano <stephano!~stephano@134.134.139.76> has quit IRC | 21:58 | |
| *** stephano <stephano!~stephano@134.134.139.76> has joined #yocto | 21:58 | |
| *** JPEWhacker <JPEWhacker!cc4da374@gateway/web/freenode/ip.204.77.163.116> has quit IRC | 22:01 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.72> has quit IRC | 22:02 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.72> has joined #yocto | 22:02 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-nbastqmtxbwnxrwo> has quit IRC | 22:04 | |
| *** stephano <stephano!~stephano@134.134.139.76> has quit IRC | 22:04 | |
| *** willdye <willdye!~willdye@cpe-108-167-39-135.neb.res.rr.com> has quit IRC | 22:06 | |
| *** SoniaLeon1 <SoniaLeon1!sleonbau@nat/intel/x-ifoednnzmboyuloi> has joined #yocto | 22:06 | |
| *** SoniaLeon1 <SoniaLeon1!~sleonbau@134.134.139.75> has joined #yocto | 22:07 | |
| *** SoniaLeon <SoniaLeon!~sleonbau@134.134.139.72> has quit IRC | 22:08 | |
| *** ant_home <ant_home!~ant__@host134-11-dynamic.32-79-r.retail.telecomitalia.it> has quit IRC | 22:12 | |
| *** agust <agust!~agust@p4FCB52B9.dip0.t-ipconnect.de> has quit IRC | 22:15 | |
| *** sjolley <sjolley!~sjolley@134.134.139.76> has joined #yocto | 22:17 | |
| *** SoniaLeon1 <SoniaLeon1!~sleonbau@134.134.139.75> has quit IRC | 22:28 | |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has quit IRC | 22:33 | |
| aehs29 | Does anyone know if its possible to have two kernel-metas? | 22:38 |
| aehs29 | A parallel kmeta to the origina one | 22:39 |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has joined #yocto | 22:45 | |
| *** aehs29 <aehs29!~aehernan@134.134.139.76> has quit IRC | 22:53 | |
| *** rburton <rburton!~Adium@home.burtonini.com> has quit IRC | 22:54 | |
| *** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC | 22:56 | |
| *** chbae <chbae!~chbae@59.10.135.122> has joined #yocto | 23:00 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 23:05 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto | 23:05 | |
| *** chbae <chbae!~chbae@59.10.135.122> has quit IRC | 23:06 | |
| *** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC | 23:06 | |
| *** nighty-- <nighty--!~nighty@s229123.ppp.asahi-net.or.jp> has quit IRC | 23:11 | |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-anhxlilexsdqqeyj> has quit IRC | 23:11 | |
| *** Aethenelle <Aethenelle!~Aethenell@199.15.128.78> has quit IRC | 23:15 | |
| *** rschaefe <rschaefe!81c4e24e@gateway/web/freenode/ip.129.196.226.78> has quit IRC | 23:22 | |
| -YoctoAutoBuilder- build #1231 of nightly is complete: Failure [failed BitbakeSelftest] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly/builds/1231 | 23:42 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-fqhgexxiobdonmwf> has joined #yocto | 23:45 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC | 23:50 | |
| *** rubdos <rubdos!~rubdos@84.198.89.1> has quit IRC | 23:51 | |
| *** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC | 23:54 | |
| *** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto | 23:54 | |
| *** rubdos <rubdos!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has joined #yocto | 23:56 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!