Tuesday, 2017-05-16

*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:00
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto00:01
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC00:19
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto00:23
*** JordonWu <JordonWu!~quassel@> has joined #yocto00:31
*** cp__ <cp__!~nighty@d246113.ppp.asahi-net.or.jp> has joined #yocto00:37
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-tiswevfivlfqvcvi> has joined #yocto00:37
*** RalphJr45 <RalphJr45!~RalphJr45@> has joined #yocto00:40
*** majuk <majuk!~majuk@> has joined #yocto00:41
*** yizhao <yizhao!~zhaoyi@> has quit IRC00:45
*** majuk <majuk!~majuk@> has quit IRC00:45
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC00:49
*** yizhao <yizhao!~zhaoyi@> has joined #yocto00:56
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto00:57
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto00:59
*** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC01:00
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC01:04
*** msvb-lab <msvb-lab!~michael@x55b547f3.dyn.telefonica.de> has quit IRC01:04
*** msvb-lab <msvb-lab!~michael@x55b540b0.dyn.telefonica.de> has joined #yocto01:17
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto01:17
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC01:24
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:26
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-bdlalbqwngyyggee> has joined #yocto01:34
*** RalphJr45 <RalphJr45!~RalphJr45@> has quit IRC01:48
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto01:49
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC01:54
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto02:07
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC02:12
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC02:18
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto02:25
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto02:25
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC02:26
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC02:32
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC02:40
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto02:44
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto02:47
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC02:52
*** bananadev <bananadev!~onlyester@> has joined #yocto02:56
*** mkelly <mkelly!~martin@> has joined #yocto03:00
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto03:07
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC03:12
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto03:26
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC03: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/89103:41
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto03:46
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-tiswevfivlfqvcvi> has quit IRC03:47
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC03:52
*** mkelly <mkelly!~martin@> has quit IRC04:02
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto04:07
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC04:12
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto04:14
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto04:26
*** m4t <m4t!~matt@2604:180:0:b2e::bad:beef> has left #yocto04:30
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC04:32
*** clement <clement!~clement@lns-bzn-39-82-255-32-23.adsl.proxad.net> has quit IRC04:45
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC04:46
*** clement <clement!~clement@lns-bzn-39-82-255-32-23.adsl.proxad.net> has joined #yocto04:47
*** agust <agust!~agust@p4FCB52B9.dip0.t-ipconnect.de> has joined #yocto04:56
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto05:01
*** AndersD <AndersD!~anders@194-237-220-218.customer.telia.com> has joined #yocto05:12
*** gtristan <gtristan!~tristanva@> has joined #yocto05:17
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC05:33
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto05:38
*** qt-x <qt-x!~Thunderbi@> has joined #yocto05:42
*** JaMa <JaMa!~martin@> has joined #yocto05:44
*** hamis <hamis!~irfan@> has joined #yocto05:48
*** garbados <garbados!~garbados@2601:1c2:303:6b0:3598:adc3:5994:95c8> has quit IRC06:05
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto06:14
*** pohly <pohly!~pohly@p5DE8EB79.dip0.t-ipconnect.de> has joined #yocto06:18
*** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has joined #yocto06:20
*** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has left #yocto06:21
*** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has joined #yocto06:22
*** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has quit IRC06:22
*** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has joined #yocto06:23
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto06:29
*** bananadev <bananadev!~onlyester@> has quit IRC06:32
*** arun_ <arun_!~arun@> has joined #yocto06:34
*** arun_ is now known as Guest1287306:34
*** bananadev <bananadev!~onlyester@> has joined #yocto06:35
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC06:35
-YoctoAutoBuilder- build #1230 of nightly is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly/builds/123006:36
*** rj_ <rj_!58d39085@gateway/web/freenode/ip.> has joined #yocto06:40
rj_Hey, i'm getting this error, does anyone know how to fix this? https://pastebin.com/yV69D9S806: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 it06:43
*** aurele <aurele!~aurele@srvmsg.castel.fr> has joined #yocto06:43
aurelehi everyone06:43
aureleis there a way to use recipe to build a package using the sdk06:44
aureleI'm looking for a simple way for developpers to build multiple packages without having to think about configure flags and so on06:46
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto06:48
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:53
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC06:53
*** ed2 <ed2!~Adium@> has joined #yocto06:54
*** ed2 <ed2!~Adium@> has joined #yocto06:55
msvb-labAnyone remember the bitbake parameter to build targets but discard intermediate object files after each target is built?06:58
msvb-labI assume by using that bitbake parameter I can build world with only a few hundred gigs.06:58
*** adelcast <adelcast!~adelcast@> has quit IRC06:59
ed2msvb-lab: INHERIT += "rm_work"07:00
msvb-labed2: So, $ INHERIT += "rm_work" bitbake world07:01
ed2msvb-lab: echo 'INHERIT += "rm_work"' >> conf/local.conf && bitbake word07:02
*** jku <jku!~jku@> has joined #yocto07:02
msvb-labed2: 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-labOr does bitbake delete the intermediate files as it builds dependencies?07:03
LetoThe2ndmsvb-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 me07:03
msvb-labLetoThe2nd: 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
LetoThe2ndmsvb-lab: tell your boss that hardware is cheap in comparison to your testing and waiting time ;-)07:05
msvb-labLetoThe2nd: True, it's a longer story than that unfortunately.07:06
LetoThe2ndmsvb-lab: thats what every boss says ;-)07:07
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto07:07
msvb-labed2: I'd like to retroactively use 'rm_work' for the last 20 hours of building. Does $ bitbake clean world do that?07:08
LetoThe2nded2: btw, "bitbake word" is a wonderful typo ;-)07:08
*** mckoan|away is now known as mckoan07:08
ed2msvb-lab: :)07:08
msvb-labIf 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
ed2msvb-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
ed2msvb-lab: you can read about rm_work here: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-rm-work07:10
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC07:11
msvb-labed2: Thanks for the reference, I had seen that document and then lost track of where to find it again.07:12
*** rajm <rajm!~robertmar@> has joined #yocto07:13
msvb-labIt seems that a half-brained approach like manually deleting 'build/work' once in a while reduces storage considerably.07:13
*** adelcast <adelcast!~adelcast@> has joined #yocto07:14
msvb-lab...and probably the bitbake world build (especially if '-k' keep going is used) will still succeed.07:14
ed2msvb-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 #yocto07:15
msvb-labed2: 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-labed2: I'm going to stop the build and restart with INHERIT += "rm_work" hoping at least sstate will help.07:16
ed2msvb-lab: you can play with it on something smaller than 'bitbake world' :)07:16
*** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has joined #yocto07:17
ed2msvb-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-labI'll build a few individual packages to be sure, then world after that.07:17
msvb-labed2: The stop, remove, rebuild approach is just what I'm planning.07:18
msvb-labLooking at a week of building, but at least it's the only build I'll need this year.07:18
msvb-labLetoThe2nd: ...which is the main reason I'm not buing a build farm. Too many days of the year not using it.07:19
msvb-labLetoThe2nd: 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 #yocto07:23
*** florian_kc is now known as florian07:23
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto07:25
*** t0mmy <t0mmy!~tprrt@> has joined #yocto07:28
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC07:29
*** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has quit IRC07:30
*** joeythesaint <joeythesaint!~joe@vegas.deserted.net> has quit IRC07:31
*** joeythesaint <joeythesaint!~joe@2605:6400:2:fed5:22:41:45ec:bf91> has joined #yocto07:31
LetoThe2ndmsvb-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
LetoThe2ndmsvb-lab: if you're only doing a couple of builds per month, it is probably cheaper, yes.07:32
msvb-labLetoThe2nd: Sounds like an interesting option, although my credits are on Azure. Might have a similar outcome.07:33
*** yohboy <yohboy!~yohan@> has joined #yocto07:33
LetoThe2ndmsvb-lab: as long at it runs linux, all is fine. at the yocto dev day they usually go for GCE.07:33
msvb-labI wish there were a document for the steps needed to build poky world on EC2/S3 along with cost estimate.07:34
LetoThe2ndi'd say that there's too many variables in this question for a document to properly answer it07:35
msvb-labLetoThe2nd: Too many variables to build poky world on qemu-x86?07:36
LetoThe2ndmsvb-lab: absolutely.07:36
msvb-labLetoThe2nd: You mean like 'rm_work' type variables? Probably version preferences...07:36
LetoThe2ndi mean like: interactively or not? speed or cost optimized? keep artifacts for later? if yes, which?07:37
msvb-labMost 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
LetoThe2ndi 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-labThere 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.> has joined #yocto07:40
LetoThe2ndif 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-labSo 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/yV69D9S807:41
*** JoiF <JoiF!~jofr@> has joined #yocto07:41
LetoThe2ndmsvb-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 #yocto07:41
*** fabo_ <fabo_!~fabo@a91-156-68-101.elisa-laajakaista.fi> has joined #yocto07:42
msvb-labLetoThe2nd: Yes, and those steps can be explained by different 'getting started' docs.07:42
*** fabo <fabo!~fabo@linaro/fabo> has quit IRC07:43
LetoThe2ndmsvb-lab: 2) exists.07:43
*** ed2 <ed2!~Adium@> has quit IRC07:43
LetoThe2ndmsvb-lab: 1) exists separately for every provider, its their own documentation.07:43
msvb-labLetoThe2nd: 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-labContainer like a LXC, Docker, or CoreOS/Rocket.07:44
*** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC07:45
LetoThe2ndmsvb-lab: such a thing (partially) exists: https://git.yoctoproject.org/cgit/cgit.cgi/crops/tree/README.md07:45
msvb-labrj_: 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-labrj_: Have you looked at orocos-rtt-gnulinux.pc to ensure it's okay? Is the file empty or maybe has CR/LF?07:46
LetoThe2ndrj_: 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 #yocto07:47
msvb-labLetoThe2nd: Oh CROPS is cool, thanks for the tip. Particularly since it can bootstrap a Zephyr environment.07:47
*** ed2 <ed2!~Adium@> has joined #yocto07:48
*** toscalix <toscalix!~toscalix@> has joined #yocto07:48
msvb-labrj_: 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
LetoThe2ndmsvb-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-labLetoThe2nd: 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 file07:51
LetoThe2ndmsvb-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 lightbulb07:51
rj_msvb-lab: This is the pc file that is generated: https://pastebin.com/V8R9rkVB07:53
msvb-labrj_: 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-labrj_: 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 IRC07:56
LetoThe2ndguessing from the error message, it is that your build tmp path is leaking into it.07:56
msvb-labBut 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
ChrysDthere 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
LetoThe2ndwhich will be obviously nonexistent during runtime.07:56
*** quite <quite!quite@gyro.lublin.se> has joined #yocto07:57
*** quite <quite!quite@unaffiliated/quite> has joined #yocto07:57
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has joined #yocto07:58
rj_LetoThe2nd: then how does it add that path when its nonexistent07:59
LetoThe2ndrj_: "it"07:59
LetoThe2ndrj_: 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 build07:59
rj_LetoThe2nd: ah alright, well ill try to find out then08:00
msvb-lab.pc files usually are generated from .pc.in files, which are unpacked from tarballs.08:01
LetoThe2ndso 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-labrj_: Manually download orocos*.tar.gz (or whatever it's called) and look for a .pc.in file.08:01
msvb-labLetoThe2nd: 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 #yocto08:03
LetoThe2ndmsvb-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
LetoThe2ndand thats the reason why we need all this sanity checking, annoying as it might be,08:05
msvb-labStill 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/Ua07XwHd08:06
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC08:07
*** grma <grma!~gruberm@> has joined #yocto08:12
msvb-labrj_: 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 fabo08:14
msvb-labrj_: 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 #yocto08:15
LetoThe2ndmy bets are on the build script just foing one of the path replacements wrong.08:15
msvb-labLike 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 #yocto08:16
msvb-labLetoThe2nd: So you would expect to find the flawed path in a .bb file?08:16
LetoThe2ndmsvb-lab: no. the exact opposite.08:16
rj_The .bb file is costum, it could be that i simply made it the wrong way08:16
msvb-labLetoThe2nd: Like a hard coded path in '*.pc'? I didn't see any.08:16
LetoThe2ndmsvb-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
LetoThe2ndof course it could also be the recipe setting a path wrong. but its almost certainly not hardcoded.08:17
msvb-labrj_: How about starting from scratch and doing $ bitbake orocos?08:18
msvb-labrj_: 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
LetoThe2ndrj_: probably that even is not needed. look at the logs that are created during the configure stage.08:19
JoiFChrysD: 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-labLetoThe2nd: Are those logs stored in build/tmp/sysroots/orocos* or something?08:19
LetoThe2ndChrysD: maybe some find -exec :-)08:20
msvb-labDefinitely a good idea if they can be found.08:20
ChrysDJoiF, LetoThe2nd : Thanks.08:20
rj_msvb-lab: I'll try and locate them08:20
JoiFThat'll work too08:20
*** yann <yann!~yann@> has joined #yocto08:21
LetoThe2ndmsvb-lab: they are. like tmp/work/$MACHINEARCH/$PACKAGE/$VERSION/temp08:21
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto08:21
rj_log.do_configure right?08:21
LetoThe2ndyes. and the internal config.log (for autotoolized packages for example) are certainly around too, in the build directry.08:22
LetoThe2ndso 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/include08:23
rj_Which is to find boost apparently08:23
msvb-labrj_: 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
LetoThe2ndrj_: of course it has pathes, the question is where and which pathes are put into the .pc - why they are not sysroot relative08:24
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC08:26
msvb-labrj_: Compare the oroco*.pc file with another package .pc file, particulary looking at the string 'tmp'.08:27
msvb-labDo you find that one has 'tmpdir=...' and the other doesn't?08:27
msvb-labOr do some paths with 'tmp' not exist? Test '/home/user/poky/build/tmp/sysroots/genericx86-64/usr/lib' for example:08:28
msvb-labls /home/user/poky/build/tmp/sysroots/genericx86-64/usr/lib08: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 #yocto08:28
msvb-labls /home/user/poky/build/tmp/work/core2-64-poky-linux/orocos-rtt/2.6.0+gitAUTOINC+1df3ad9acd-r0/sysroot-destdir/usr/lib/pkgconfig08:28
rj_msvb-lab: All paths exist08:30
*** groleo <groleo!~groleo@> has joined #yocto08:30
rj_and the last one you just mentioned is where the .pc file is stored08:30
msvb-labrj_: 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 seems08:32
LetoThe2ndthe 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@> has joined #yocto08:35
msvb-labrj_: 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@> has joined #yocto08: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-labrj_: 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 #yocto08:39
rj_msvb-lab: Sounds like fun... (._.)708:39
LetoThe2ndmsvb-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 #yocto08: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
LetoThe2ndif 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-labLetoThe2nd: That's why bitbake must declare any other similar (meaning with hard coded build/tmp paths) as insane as well.08:41
msvb-labBut 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-labIf so, then that's the direction to investigate.08:42
LetoThe2ndmsvb-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.> has joined #yocto08:43
Smitty_I'm a little confused about something.08:43
*** hattzy <hattzy!~hattzy@h-90-120.a137.corp.bahnhof.se> has quit IRC08:43
LetoThe2ndSmitty_: 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 build08:44
*** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto08:44
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC08:44
msvb-labLetoThe2nd: 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 build08:44
LetoThe2ndmsvb-lab: 1) is in most cases pointless, as not reproductible.08:44
LetoThe2ndSmitty_: 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 else08:45
LetoThe2ndSmitty_: 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 IRC08: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-labrj_: 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 yesterday08:50
rj_msvb-lab: But atm im not building anything... And it still throws me this error08:50
msvb-lab...oh cool, just after I complained the build finally stopped. Now I can use $ INHERIT += "rm_work" bitbake08:50
rj_I can't seem to find the bitbake process either...08:51
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto08:51
*** fray <fray!~fray@kernel.crashing.org> has joined #yocto08:52
*** nikincn <nikincn!2a6d1f22@gateway/web/freenode/ip.> has joined #yocto08:52
rj_ill just reboot i guess08:52
*** rj_ <rj_!58d39085@gateway/web/freenode/ip.> has quit IRC08:53
*** rj_ <rj_!58d39085@gateway/web/freenode/ip.> has joined #yocto08:55
rj_msvb-lab: okay, so should i just remove all paths that contain the tmp dir?08:57
rj_in the pc.in file08:57
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto08: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-labrj_: 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.> has left #yocto08:59
*** ChrysD <ChrysD!d9804861@gateway/web/freenode/ip.> has joined #yocto08:59
msvb-labrj_: ...since there's the possibility that whatever you modify before bitbake starts, will get overwritten. Do you think it will?08:59
LetoThe2ndSmitty_: 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 IRC09:00
*** rollcake <rollcake!~yoonki@> has joined #yocto09:00
msvb-labLike 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
LetoThe2ndSmitty_: here is some additional information: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#sdk-adding-individual-packages09:02
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC09: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
LetoThe2ndSmitty_: 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 now09:10
rj_Not sure if everything will work correctly but it passed the sanity check now09:10
nikincnnoob 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 help09:12
*** jonakn <jonakn!c33c449c@gateway/web/freenode/ip.> has joined #yocto09:12
msvb-labrj_: So you just did #1 of the 1) build and 2) correct.09:13
LetoThe2ndnikincn: 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 qemu09:13
rj_msvb-lab: I removed all paths that had tmp in them. Build the image, and got no errors :)09:14
nikincni c , thanks @ Letothe2nd09:14
msvb-labrj_: 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
LetoThe2ndnikincn: for 2) please consult the documentation of your board, its hw specific09:15
msvb-labrj_: 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 work09:15
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto09:16
nikincnok @Letothe2nd I will check board documentation ,though afai remember they havent given detailed doc09:16
LetoThe2ndnikincn: well then tell them to provide the documentation, thats certainly vendor duty.09:17
msvb-labrj_: 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-labI'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-labrj_: 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 yea09: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-labrj_: $ pkg-config -l -cppflags oroco09:20
Smitty_The way that my library is included in the SDK is by way of recursion into the subdirectories09:20
nikincnthey 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 board09:20
msvb-lab...that kind of thing (adjust and correct, since I just wrote semi pseudocode.)09:20
nikincnare they obliged to support yocto?09:20
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC09:20
LetoThe2ndnikincn: no, they are obliged to tell you how to load software onto the board.09:20
LetoThe2ndnikincn: 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-labrj_: 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
LetoThe2ndSmitty_: 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
nikincnok got it , but tough for a noob09:22
nikincni will google more thanks for ur help09:22
LetoThe2ndSmitty_: nah. it probably wouldn't work, because then the addition is not visible during the build of the sdk.09:22
LetoThe2ndSmitty_: scratch my first statement. i think it would never be included.09:23
LetoThe2ndnikincn: if it is a well known board, there might be something already in place for you. what are we talking about?09:23
nikincnfirefly rk328809:23
LetoThe2ndnikincn: 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
LetoThe2ndnikincn: my personal advice would be to get access to the bootloader and try to network boot09:25
nikincnok will try that09:26
*** nikincn <nikincn!2a6d1f22@gateway/web/freenode/ip.> has quit IRC09:31
msvb-labrj_: 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/dL6BqDHS09:32
rj_Only alot more this time09:32
msvb-labrj_: 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
ChrysDbitbake -c clean TARGET will cleans the images of the target ? Or it will remove allso the local.conf etc ? Thanks.09:33
msvb-labrj_: 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 #yocto09: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
LetoThe2ndSmitty_: because those that are actually pulled in through dependencies do not have to be explicitly mentioned09: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 listed09:35
msvb-labrj_: That pastebin indicates that the oroco version that pokey maintainers chose is hopelessly flawed.09:35
msvb-labrj_: What about figuring out how to completely remove oroco-* from the build?09:35
rj_msvb-lab: Not an option sadly09:35
LetoThe2ndrj_: there is also 3) include a patch in your recipe.09:36
msvb-labrj_: 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 Orocos09:37
msvb-labrj_: 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
LetoThe2ndSmitty_: exactly.09:37
rj_msvb-lab: It is not sadly, i have to get this working to run some costum software on this build09:38
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto09:38
msvb-labrj_: 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 orocos09:38
LetoThe2ndSmitty_: 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 IRC09:38
msvb-labrj_: 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 repository09: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
LetoThe2ndSmitty_: 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
LetoThe2ndSmitty_: the one that modifies the image recipe is in charge. simple as that.09:43
LetoThe2ndSmitty_: 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 #yocto09: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 IRC09:48
*** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has quit IRC09:49
msvb-labLetoThe2nd: 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
LetoThe2ndmsvb-lab: nope it was ed2 :)09:50
msvb-labBuild tasks that usually take five minutes are flashing by.09:50
msvb-labOh, 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 IRC09:51
rburtonrj_: you remove the tmp paths from the pc file09:51
msvb-labI 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
rburtonrj_: how depends on each upstream as it's a bug in their makefiles09:51
msvb-labrburton: ...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 #yocto09:52
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto09:52
rburtonmsvb-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 that09:53
msvb-labrj_: The wierd thing is that Orocos builds correctly in other (non bitbake) environments, have you confirmed that?09:53
msvb-labI 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 me09:53
msvb-lab...or the upstream maintainer of Orocos has the correction in the trunk of a SCM.09:54
msvb-labrj_: You compiled it from scratch on the laptop or you used a binary package?09:54
LetoThe2ndupstream maintainers are often cross-compile ignorant. in many cases they're even other-distribution ignorant09:55
rj_msvb-lab: Oh thats a good point actually, they used a deb file to install it on there...09:55
rburtonrj_: in the ideal world you can send a patch upstream instead of sedding the paths out afterwards09:55
msvb-labrj_: 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 IRC09:56
msvb-labrj_: 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 made09:57
msvb-labrj_: 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 recipe09:58
msvb-labObviously 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@> has quit IRC10:01
rj_msvb-lab: There isnt even a .pc file for orocos on that laptop10:02
*** yohboy <yohboy!~yohan@> has quit IRC10:03
rj_msvb-lab: Oh, nvm it's not under /usr/lib/pkgconfig but some other path10:03
rj_It's pretty much the same .pc file10:04
msvb-labrj_: You can always do dpkg -L to find the files corresponding to a package.10:04
msvb-labrj_: 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/include10:06
msvb-labrj_: Those paths are okay as long as they contain the actual orocos files.10:07
rj_msvb-lab: Which they do10:07
msvb-labIt 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 #yocto10:10
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:12
*** blitz00 <blitz00!~stefan@unaffiliated/blitz00> has joined #yocto10:13
*** yohboy <yohboy!~yohan@> has joined #yocto10:14
erboHow is core-image-testq10:14
erbohow 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 IRC10:17
*** Ox4 <Ox4!~user@unaffiliated/zloy> has joined #yocto10:20
Ox4hello everyone10:20
Ox4could somebody help me to resolve this problem ---> http://ix.io/tTd ?10:22
Ox4thank you in advance10:22
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC10:22
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC10:22
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:31
*** yann <yann!~yann@LFbn-1-12676-32.w90-90.abo.wanadoo.fr> has joined #yocto10:32
*** sjolley1 <sjolley1!~sjolley@> has quit IRC10:32
*** sjolley <sjolley!~sjolley@> has joined #yocto10:32
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC10:35
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC10:40
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto10:47
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto10:55
*** gtristan <gtristan!~tristanva@> has quit IRC11:02
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto11:06
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC11:10
*** cp__ <cp__!~nighty@d246113.ppp.asahi-net.or.jp> has quit IRC11:13
LetoThe2ndOx4: well what is not clear about the error message?11:14
LetoThe2ndOx4: the package lighttpd wants to install the file /www/pages/index.html, the package web-application wants to install the file /www/pages/index.html11:15
LetoThe2ndOx4: that clashes, it tells you as the user to resolve the conflict.11:15
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto11:16
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC11:19
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto11:21
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto11:24
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto11:28
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC11:31
*** lexano <lexano!~lexano@> has quit IRC11:32
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC11:38
*** phatina <phatina!55f80636@gateway/web/freenode/ip.> has joined #yocto11:40
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto11:43
*** gtristan <gtristan!~tristanva@> has joined #yocto11:43
*** berton <berton!~berton@> has joined #yocto11:45
*** qt-x <qt-x!~Thunderbi@> has quit IRC11:46
*** bananadev <bananadev!~onlyester@> has quit IRC11:47
phatinaHi 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.> has joined #yocto11:56
*** phatina <phatina!55f80636@gateway/web/freenode/ip.> has quit IRC11:56
neverpanicWouldn'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.> has joined #yocto11:56
neverpanicWouldn'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 #yocto11:57
phatinaneverpanic: hm, let me see, if such package provide pkg-config file11:57
*** tavish <tavish!~tavish@unaffiliated/tavish> has joined #yocto11:57
neverpanicThat would be a good solution, yes. For pkg-config in CMake, see https://cmake.org/cmake/help/latest/module/FindPkgConfig.html11:58
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC11:59
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto12:00
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto12:01
*** jku <jku!~jku@> has quit IRC12:02
*** jku <jku!~jku@> has joined #yocto12:02
phatinaneverpanic: yeah, there's a *.pc in sysroot, which means, I have at least some entry point...12:02
phatinaneverpanic: ok, will need to adjust some includes in sources, but .. anyway, at least something12: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@> has quit IRC12:10
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto12:20
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC12:21
*** top21 <top21!c34b4920@gateway/web/freenode/ip.> has quit IRC12:26
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC12:27
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto12:30
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto12:32
nrossihmmm 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@> has quit IRC12:35
*** jonakn <jonakn!c33c449c@gateway/web/freenode/ip.> has quit IRC12:38
*** aratiu <aratiu!~adi@> has quit IRC12:38
*** Saur <Saur!~pkj@proxy02.se.axis.com> has quit IRC12:39
*** aratiu <aratiu!~adi@> has joined #yocto12:40
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto12:41
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC12:45
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC12:46
PinkSnakehi 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 #yocto12:51
nrossiPinkSnake: 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 IRC12:53
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC12:53
*** lamego <lamego!jose@nat/intel/x-whucdvjymmjcljmt> has joined #yocto12: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@> has joined #yocto12:56
neverpanicSmitty_: Yocto by default omits creating empty packages, so your main package is probably not being created if you only ship a static library12:56
neverpanicSmitty_: The default value for RDEPENDS_${PN}-dev includes "${PN}", though, so the dependency is there by default12:57
*** gtristan <gtristan!~tristanva@> has quit IRC12:57
neverpanicSmitty_: So when you attempt to install ${PN}-dev, it fails because it rdepends on ${PN}, which doesn't exist. Potential solutions include:12:57
neverpanicSmitty_: (a) ALLOW_EMPTY_${PN} = "1", which will create an empty ${PN} package12:58
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has quit IRC12:58
neverpanicSmitty_: (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 #yocto12:58
neverpanicSmitty_: (c) RDEPENDS_${PN}-dev = "${PN}-staticdev", which makes your -dev package depend on the static lib12:58
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto12:59
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC13:04
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto13: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 IRC13:12
*** tavish <tavish!~tavish@unaffiliated/tavish> has quit IRC13:15
*** tavish_ <tavish_!~tavish@unaffiliated/tavish> has joined #yocto13: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_recipes13:15
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto13:15
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto13: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 #yocto13: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
ironzorghi, 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 IRC13:22
nrossiPinkSnake: 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_tree13:22
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC13:23
rburtonironzorg: have you tried import mymodule?13:23
*** madisox <madisox!~madison@216-75-232-11.static.wiline.com> has joined #yocto13:24
*** tavish_ <tavish_!~tavish@unaffiliated/tavish> has quit IRC13:24
*** tavish_ <tavish_!~tavish@unaffiliated/tavish> has joined #yocto13:24
*** Guest12873 <Guest12873!~arun@> has quit IRC13:25
ironzorgPinkSnake: I meant a python module, not a kernel one13:25
ironzorgrburton: yes it's not in the path so it's not loaded13:26
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto13:26
*** JPEWhacker <JPEWhacker!cc4da374@gateway/web/freenode/ip.> has joined #yocto13:26
ironzorgI 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
nrossiironzorg: sure your layer is in BBPATH?13:30
rburtonironzorg: does the layer.conf set BBPATH?13:31
ironzorgso this should work by itself? having modules in a meta's `lib` directory should work off the bat?13:31
rburtonmy setup is definitely adding <layer>/lib to sys.path13:31
rburtonso i suspect that works on BBPATH in layer.conf13:31
ironzorg`BBPATH .= ":${LAYERDIR}"` yes13: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 modules13:32
rburtonironzorg: 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/p13:32
rburtonthats my sys.path inside a task13:32
kergoththe 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 modified13:32
kergothkeep that in mind13:32
rburton*maybe* anon python is executed too early13:32
kergothanon python should be fine13:32
*** TobSnyder <TobSnyder!~schneider@ip9234ad86.dynamic.kabel-deutschland.de> has quit IRC13:33
*** mckoan is now known as mckoan|away13:35
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto13:37
*** gtristan <gtristan!~tristanva@> has joined #yocto13:40
*** top22 <top22!c34b4920@gateway/web/freenode/ip.> has joined #yocto13:40
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC13:42
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC13:42
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC13:45
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC13:50
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC13:53
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto13:55
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC14:00
*** AndersD <AndersD!~anders@194-237-220-218.customer.telia.com> has quit IRC14:01
*** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has left #yocto14:03
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto14:03
neverpanicSmitty_: 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
neverpanicSmitty_: None of this is related to whether some other recipe or package depends on this.14:04
*** chbae <chbae!~chbae@> has joined #yocto14:05
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto14:09
*** jairglez <jairglez!~jairdeje@> has joined #yocto14:10
*** Bunio_FH <Bunio_FH!~bunio@89-68-88-224.dynamic.chello.pl> has quit IRC14:12
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:13
*** hamis <hamis!~irfan@> has quit IRC14:15
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC14:16
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:18
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC14:19
*** marka <marka!~masselst@> has joined #yocto14:23
*** phatina <phatina!55f80636@gateway/web/freenode/ip.> has quit IRC14:28
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC14:28
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto14:28
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC14:33
*** groleo1 <groleo1!~groleo@> has joined #yocto14:33
*** rj_ <rj_!58d39085@gateway/web/freenode/ip.> has quit IRC14:33
*** tf <tf!~tomas@> has quit IRC14:34
*** gtristan <gtristan!~tristanva@> has quit IRC14:34
*** Saur <Saur!~pkj@proxycluster.se.axis.com> has joined #yocto14:35
*** groleo <groleo!~groleo@> has quit IRC14:35
*** tf_ <tf_!~tomas@r-finger.com> has joined #yocto14:35
*** gtristan <gtristan!~tristanva@> has joined #yocto14:39
*** Ox4` <Ox4`!~user@> has joined #yocto14:40
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC14:41
Smitty_Do I have to set ${PN}-staticlib ?14:42
*** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has quit IRC14:42
*** Ox4 <Ox4!~user@unaffiliated/zloy> has quit IRC14:44
*** tavish_ <tavish_!~tavish@unaffiliated/tavish> has quit IRC14:44
*** tavish__ <tavish__!~tavish@unaffiliated/tavish> has joined #yocto14:45
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto14:48
*** frsc <frsc!~frsc@> has quit IRC14:48
*** chbae <chbae!~chbae@> has quit IRC14:49
*** t0mmy <t0mmy!~tprrt@> has quit IRC14:51
*** ayaka <ayaka!~ayaka@> has joined #yocto14:52
ayakaI want to access a files meta/recipes-multimedia/ of yocto in bsp meta14:53
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto14:53
ayakahow should I set it in FILESEXTRAPATHS14:53
PinkSnake@ayaka i think it depends what you want to do with this files14:54
ayakaPinkSnake, oh it is a patch file14:55
ayakafor example I want to access meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/ in my layer meta, as I offer a customize version for it14:56
ayakabut it could inherit most of patches from the original version14:56
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:58
neverpanicSmitty_: 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@> has joined #yocto15:03
Smitty_Dio I have to populate that value in some file ?15:08
*** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has joined #yocto15:09
ayakaPinkSnake, I have known, the COREBASE, thanks15:10
majukIs 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 #yocto15:13
majukI imagine not.15:13
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto15:14
*** Aethenelle <Aethenelle!~Aethenell@mobile-166-175-56-82.mycingular.net> has joined #yocto15:15
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC15:15
rburtonmajuk: what do you mean?15:17
majukrburton: I want to include the package ruby-dev in my system and there is no recipe I can find.15:19
rburtonbitbake ruby will generate ruby-dev15:19
rburtonrecipes built many packages15:19
*** mappy <mappy!b9691ff9@gateway/web/freenode/ip.> has quit IRC15:20
majukWell it might be /generated/ but it is not ending up in my system. "gem install mmap" complains it can't find the ruby.h lib15:21
majukKrogoth branch fyi15:21
*** ed2 <ed2!~Adium@> has quit IRC15:23
joshuagldevelopment packages aren't installed by default, you'll need to add ruby-dev (or similar) to your IMAGE_INSTALL15:24
*** Guma <Guma!~Guma@c-67-184-64-21.hsd1.il.comcast.net> has quit IRC15:25
rburtonmajuk: yeah you'll need to add it to your image.15:26
neverpanicSmitty_: 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
majukrburton: joshuagl: Thanks. I... well, I assumed there wasn't a recipe. I really need to get better at navigating the file structure.15:32
rburtonmajuk: remember that eg the ruby dev files are going to be part of the ruby build15:33
rburtonso the ruby recipe will generate them15:33
kergothrburton: 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 yawns15:34
*** dv_ <dv_!~quassel@62-178-118-86.cable.dynamic.surfer.at> has quit IRC15:38
*** dv_ <dv_!~quassel@62-178-118-86.cable.dynamic.surfer.at> has joined #yocto15:40
*** ant_work <ant_work!~ant__@host108-181-dynamic.31-79-r.retail.telecomitalia.it> has quit IRC15:41
*** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto15:45
*** rajm <rajm!~robertmar@> has quit IRC15:48
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC15:49
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC15:52
*** Aethenelle <Aethenelle!~Aethenell@mobile-166-175-56-82.mycingular.net> has quit IRC15:53
*** t0mmy <t0mmy!~tprrt@> has quit IRC15:54
*** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC15:55
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto15:55
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto15:57
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto15:57
*** zeenix <zeenix!~zeenix@> has quit IRC15:58
rburtonkergoth: thanks, good to know16:02
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:04
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC16:05
*** t0mmy <t0mmy!~tprrt@> has joined #yocto16:05
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto16:05
*** yohboy <yohboy!~yohan@> has quit IRC16:09
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC16:09
*** JaMa <JaMa!~martin@> has quit IRC16:11
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto16:12
*** blitz00 <blitz00!~stefan@unaffiliated/blitz00> has quit IRC16:18
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto16:18
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto16:19
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC16:19
*** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC16:21
*** toscalix <toscalix!~toscalix@> has quit IRC16:23
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto16:26
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto16:27
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:27
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC16:27
*** martinkelly <martinkelly!~martin@65-122-179-226.dia.static.qwest.net> has quit IRC16:33
*** sgw_ <sgw_!~sgw_@> has quit IRC16:34
*** martinkelly <martinkelly!~martin@66-162-141-202.static.twtelecom.net> has joined #yocto16:35
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC16:40
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto16:40
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC16:41
*** ayaka <ayaka!~ayaka@> has left #yocto16:41
*** geoffrey_l <geoffrey_l!~geoffrey_@lns-bzn-39-82-255-32-23.adsl.proxad.net> has quit IRC16:45
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto16:47
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto16:48
*** stephano <stephano!~stephano@> has joined #yocto16:49
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC16:50
*** sgw_ <sgw_!sgw_@nat/intel/x-xyknssroyufdjwmv> has joined #yocto16:53
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC16:56
*** sjolley1 <sjolley1!~sjolley@> has joined #yocto16:57
*** sjolley <sjolley!~sjolley@> has quit IRC16:57
*** sjolley1 <sjolley1!~sjolley@> has quit IRC16:59
*** gtristan <gtristan!~tristanva@> has quit IRC17:00
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC17:01
*** gtristan <gtristan!~tristanva@> has joined #yocto17:01
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto17:03
*** martinkelly <martinkelly!~martin@66-162-141-202.static.twtelecom.net> has quit IRC17:03
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto17:07
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC17:10
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC17:15
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto17:16
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has joined #yocto17:16
*** grma <grma!~gruberm@> has quit IRC17:17
*** martinkelly <martinkelly!~martin@65-122-179-226.dia.static.qwest.net> has joined #yocto17:22
*** yann <yann!~yann@LFbn-1-12676-32.w90-90.abo.wanadoo.fr> has quit IRC17:22
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto17:26
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC17:28
*** sjolley <sjolley!~sjolley@> has joined #yocto17:30
*** stephano <stephano!~stephano@> has quit IRC17:33
*** sjolley <sjolley!~sjolley@> has quit IRC17:37
*** t0mmy <t0mmy!~tprrt@> has quit IRC17:38
*** joshuagl <joshuagl!~joshuagl@> has quit IRC17:39
*** mtas <mtas!sid127809@gateway/web/irccloud.com/x-hcctkmyyofbtpcln> has quit IRC17:42
*** Ox4` <Ox4`!~user@> has quit IRC17:47
*** mtas <mtas!sid127809@gateway/web/irccloud.com/x-yvybbyfgpbjzzhde> has joined #yocto17:47
*** sjolley <sjolley!~sjolley@> has joined #yocto17:49
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC17:50
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto17:50
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC17:53
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC17:58
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto18:00
*** marka <marka!~masselst@> has quit IRC18:07
*** marka <marka!~masselst@> has joined #yocto18:07
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC18:10
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto18:12
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto18:17
*** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto18:19
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto18:24
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC18:29
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC18:30
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC18:30
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto18:32
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC18:35
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has joined #yocto18:36
*** groleo1 <groleo1!~groleo@> has quit IRC18:39
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto18:39
*** JaMa <JaMa!~martin@> has joined #yocto18:41
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto18:51
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC18:51
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC18:59
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC19:03
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto19:04
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC19:04
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has joined #yocto19:05
*** Smitty__ <Smitty__!5843b8bc@gateway/web/freenode/ip.> has joined #yocto19:08
*** Kakounet1 <Kakounet1!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has joined #yocto19: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 IRC19:12
*** Kakounet1 is now known as Kakounet19:12
rburtonbecause there is no assumption that you have layers inside your source tree19:12
rburtonnone of mine are19:12
rburtona sample gets generated if you oe-init-build-env from an empty build tree19:13
rburtonafter that its a configuration file like local.conf19: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
rburtonpatches welcome.  if you've a mega-repo with all your layers in you can just provide a sample bblayers.conf19:15
rburtonwhich will get used when someone does oe-init-build-env on an empty tree19:15
rburtonso they have nothing to do19:15
Smitty__You've lost me.19:15
rburtonwhen you run oe-init-build-env with an empty build directory, the script will write a bblayers.conf for you19:16
Smitty__And, what will be in it ?19:16
kergothbblayers.conf isn't "generated", it's copied from a template19:16
kergoththat's all19:16
rburtonthe template is bblayers.conf.sample19:16
rburtonin meta/conf/bblayers.conf.sample, and other layers can provide their own.  poky does this.19:16
Smitty__I must be missing somehting really fundamental19:17
rburtonthe key point is that bblayers.conf isn't a generated file19:17
rburtonits a configuration file for you, and a convenient starting point is provided19:17
rburtonsame as for local.conf19:17
rburtonwe *could* just give you an empty local.conf19:17
rburtonbut no, you get a sample to edit19: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
rburtoncan't argue with that19:19
Smitty__And, the Yocto project generously provides a basic OS image so that dumb developers like me don't have to start from nothng19:19
Smitty__right ?19:19
rburtonit provides sample recipes so you can build your own images yes19: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 image19: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 received19:24
kergothsamples / examples are provided, it's expected that nearly everyone is going to have to heavily customize from there19:24
kergothit's not magic, it copies a couple of example files, that's all19:25
rburtonyes the configuration files are copied from meta-poky/conf/*.sample19:25
rburtonas you cloned poky, and that is configured to use the samples in meta-poky19:25
rburtonif you cloned oe-core directly, it would just configure the meta/ layer on its own19:26
kergothby all means submit issues if you have ideas for how to improve the usability19:26
Smitty__So, not, if I add my own layer, how do I get that layer to automatically be available ?19:26
rburtonas part of your distro layer you can provide your own samples which pull the right layers in the right order19:27
Smitty__Sorry, not being critical, trying to understand the logic19:27
Smitty__I guess I was under the impression that oe-init... was looking at what layers were available to be built19:28
rburtonyeah, it's not19:28
Smitty__OK - got it19:28
Smitty__that needs to be explained19:28
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto19:28
Smitty__I think al lot of people will be under the same impression.19:29
majukDocumentation is hard.19:29
rburtonSmitty_: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-core-script19: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
kergothit 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 point19:29
* kergoth shrugs19:29
rburtoni guess the quick start could mention that the files are copied from templates and not inferred from the eather19:30
rburtonbug and or patches welcome19:30
* rburton -> somewhere that isn't my desk as its 20:3019:31
JEEByes, 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 #yocto19:40
*** peacememories <peacememories!~textual@e242-039.eduroam.tuwien.ac.at> has quit IRC19:43
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has joined #yocto19:45
*** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has joined #yocto19:46
*** ftonello <ftonello!~felipe@host81-156-3-36.range81-156.btcentralplus.com> has quit IRC19:47
*** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has quit IRC19:54
*** tavish__ <tavish__!~tavish@unaffiliated/tavish> has quit IRC19:58
*** dscully <dscully!~dscully@> has joined #yocto19:59
*** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC20:00
*** morphis <morphis!~morphis@pD9ED67CE.dip0.t-ipconnect.de> has quit IRC20:00
*** caiortp <caiortp!~inatel@> has joined #yocto20:01
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC20:02
dscullyDoes 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 getty20:04
*** pohly <pohly!~pohly@p5DE8EB79.dip0.t-ipconnect.de> has quit IRC20:06
kergothdoesn'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 /etc20:07
kergothotherwise do a bitbake systemd; then make use of `recipetool appendfile`20:07
kergothwhose whole purpose is to ease overriding of files based on target path20:07
*** aehs29 <aehs29!~aehernan@> has joined #yocto20:08
dscullyAh, I forgot about overrides. I will check that out, thanks!20:08
rburtondscully: yes easy way is to just drop a file into /etc instead20:08
aehs29Does anyone know if we've got a good reason to base our ARM bsps on armv5?20:09
aehs29by our I mean the ones that are created with the yocto-bsp script20:10
*** john <john!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto20:10
kergotharen't the layers created by yocto-bsp just examples anyway? i doubt they're of any use iwthout heavy modification anyway20:10
*** john is now known as Guest2609520:11
*** john1 <john1!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto20:11
aehs29kergoth: yeah they are supposed to be templates basically, but for example, the script asks if you want SMP which is not supported on armv520: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 #yocto20:12
kergothSmitty__: 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 all20:12
aehs29kergoth: before fixing the script I wanted to ask if anyone had other info20:12
kergothand of course some folks just prep the buid ldir manually20:13
kergothaehs29: ah, fair enough20:13
rburtonSmitty_: a .templateconf at the top level can set TEMPLATECONF=where/the/templates/are20:14
kergothyeah, that's a good way to go if your setup is relatively fixed20:14
Smitty__So, maybe I am thinking about the whole thing wrong still.20:15
kergoththere 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't20:16
kergothin 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 #yocto20: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 unnecessarily20: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 sloppy20: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 code20:22
kergoththat's not the case with a ton of git based projects20:23
kergothmonolithic source trees aren't used often with git20:23
kergothsee how android's sources are handled, for example. countless individual git repositories pulled down with 'repo' via an xml manifest20:23
rburtonSmitty_: 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 sorted20:24
rburtonliterally none of my layers are under the same directory as poky or oe-core20:24
rburton(mainly because I have about 20 checked out)20:24
Smitty__why not ?20:24
rburtonbecause adding meta-clang means the world rebuilds20:24
rburtonmeta-oe until incredibly recently changed how the X server started20:24
rburton(i mix and match and add and remove as required on a daily basis)20:25
rburtonbut mainly because they're all separate layers so they're all checked out individually20: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
rburtonbecause thats my job20:26
rburtondon't assume that everyone has a monolithic repo because that's not true20:27
rburtonanyway i've told you how to fix the problem you had - .templateconf in the top level of your monolithic repo20:27
*** john1 <john1!~john@host86-143-93-24.range86-143.btcentralplus.com> has quit IRC20: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 help20:30
rburtondon't try to learn everything in a week - the problem was "can i customise bblayers" and the answer is yes20:30
*** john3 <john3!~john@host86-143-93-24.range86-143.btcentralplus.com> has joined #yocto20:30
rburtonto solve the problem yourself you could have followed the flow from oe-init-build-env20:31
rburtonthat gets you to scripts/oe-buildenv-setup or something, which does the cp20:31
Smitty__So far tonight, I discovered that those files in conf aren't generated.  That totally changed my perception of what I was doing20:31
*** marka <marka!~masselst@> has quit IRC20: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
aehs29rburton: 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 be20:43
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC20:47
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto20:49
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC20:50
kergothSmitty__: there's no standard way to get the path to a shell script which is being sourced. some shells set $0, plenty don't20:54
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto20:54
rburtonaehs29: its the /usr/bin/python3-config file that conflicts20: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 IRC20:57
kergothi 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 method20:57
kergothsince as i said there's no stnadard mechanism20:57
* kergoth shrugs20:57
rburtonSmitty_: don't worry about every line, it ends up calling build-setup and that has clear operations on bblayers.conf20:58
kergothSmitty__: 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 first21:00
*** Smitty_ <Smitty_!86bfdc47@gateway/web/freenode/ip.> has quit IRC21:00
rburtondeep-dive too far and you'll be staring at the copy-on-write logic in bitbake and that's just one step away from cthulhu21:00
kergothhaha, true that21:01
kergothusing classes as objects is just twisted21: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 SDK21:04
kergothedit bblayers.conf, put your layer path in BBLAYERS, do a build21:05
kergotha 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@> has quit IRC21: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@> has joined #yocto21:07
Smitty__Especially when things like editing a temporary (build directory) file are clearly not a permanent solution, and so a waste of time21:07
kergothi don't understand the question. there are plenty of docs and gettings tarted guides around. most folks would follow those, and go from there21: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.2921:08
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC21: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 layer21:08
kergothi 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 trivial21: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 time21:11
*** caiortp <caiortp!~inatel@> has quit IRC21:12
kergothYou're assuming that everyone learns like you. Not everyone learns bottom-up, plenty of folks learn top-down21:12
kergothfurther, there *is no standard* for repository management or setup scripts21:13
kergothnot every solution satisfies the requirements for every company21:13
*** sjolley <sjolley!~sjolley@> has quit IRC21:13
Smitty__Bed time.21:15
Smitty__Thanks for your time.  I honestky appreciate it very much21:16
*** berton <berton!~berton@> has quit IRC21:16
kergothnp, there's obviously a bit of a learning curve, here, any suggestions on how to improve that are appreciated21:16
*** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto21:16
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC21:19
*** stephano <stephano!~stephano@> has joined #yocto21:29
*** zeeblex <zeeblex!~zeeblex@gate-zro.freescale.com> has joined #yocto21:29
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC21:30
*** emikulin <emikulin!~emikulin@> has joined #yocto21:31
*** ant_home <ant_home!~ant__@host134-11-dynamic.32-79-r.retail.telecomitalia.it> has joined #yocto21:31
*** majuk_ <majuk_!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC21:32
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto21:32
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has joined #yocto21:32
*** sjolley <sjolley!sjolley@nat/intel/x-enmhdawmggxollnv> has joined #yocto21:35
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC21:39
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto21:40
*** emikulin <emikulin!~emikulin@> has quit IRC21:41
*** emikulin <emikulin!~emikulin@> has joined #yocto21:41
*** emikulin is now known as itseris21:41
*** sjolley <sjolley!sjolley@nat/intel/x-enmhdawmggxollnv> has quit IRC21:42
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC21:44
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto21:44
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto21:44
*** sjolley <sjolley!sjolley@nat/intel/x-nbastqmtxbwnxrwo> has joined #yocto21:46
*** gtristan <gtristan!~tristanva@> has quit IRC21:48
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC21:48
*** JaMa <JaMa!~martin@> has quit IRC21:50
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC21:51
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto21:58
*** stephano <stephano!~stephano@> has quit IRC21:58
*** stephano <stephano!~stephano@> has joined #yocto21:58
*** JPEWhacker <JPEWhacker!cc4da374@gateway/web/freenode/ip.> has quit IRC22:01
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC22:02
*** SoniaLeon <SoniaLeon!~sleonbau@> has joined #yocto22:02
*** sjolley <sjolley!sjolley@nat/intel/x-nbastqmtxbwnxrwo> has quit IRC22:04
*** stephano <stephano!~stephano@> has quit IRC22:04
*** willdye <willdye!~willdye@cpe-108-167-39-135.neb.res.rr.com> has quit IRC22:06
*** SoniaLeon1 <SoniaLeon1!sleonbau@nat/intel/x-ifoednnzmboyuloi> has joined #yocto22:06
*** SoniaLeon1 <SoniaLeon1!~sleonbau@> has joined #yocto22:07
*** SoniaLeon <SoniaLeon!~sleonbau@> has quit IRC22:08
*** ant_home <ant_home!~ant__@host134-11-dynamic.32-79-r.retail.telecomitalia.it> has quit IRC22:12
*** agust <agust!~agust@p4FCB52B9.dip0.t-ipconnect.de> has quit IRC22:15
*** sjolley <sjolley!~sjolley@> has joined #yocto22:17
*** SoniaLeon1 <SoniaLeon1!~sleonbau@> has quit IRC22:28
*** joshuagl <joshuagl!~joshuagl@> has quit IRC22:33
aehs29Does anyone know if its possible to have two kernel-metas?22:38
aehs29A parallel kmeta to the origina one22:39
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto22:45
*** aehs29 <aehs29!~aehernan@> has quit IRC22:53
*** rburton <rburton!~Adium@home.burtonini.com> has quit IRC22:54
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC22:56
*** chbae <chbae!~chbae@> has joined #yocto23:00
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC23:05
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has joined #yocto23:05
*** chbae <chbae!~chbae@> has quit IRC23:06
*** majuk <majuk!~majuk@50-233-77-210-static.hfc.comcastbusiness.net> has quit IRC23:06
*** nighty-- <nighty--!~nighty@s229123.ppp.asahi-net.or.jp> has quit IRC23:11
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-anhxlilexsdqqeyj> has quit IRC23:11
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC23:15
*** rschaefe <rschaefe!81c4e24e@gateway/web/freenode/ip.> has quit IRC23:22
-YoctoAutoBuilder- build #1231 of nightly is complete: Failure [failed BitbakeSelftest] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly/builds/123123:42
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-fqhgexxiobdonmwf> has joined #yocto23:45
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC23:50
*** rubdos <rubdos!~rubdos@> has quit IRC23:51
*** dvhart <dvhart!~dvhart@static-50-53-109-124.bvtn.or.frontiernet.net> has quit IRC23:54
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto23:54
*** rubdos <rubdos!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has joined #yocto23:56

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!