**** BEGIN LOGGING AT Tue May 16 03:00:03 2017 May 16 06:42:42 Hey, i'm getting this error, does anyone know how to fix this? https://pastebin.com/yV69D9S8 May 16 06:43:00 I know it has to do that the tmp dir i used in the paths in the .pc file, but im not sure how to fix it May 16 06:43:30 hi everyone May 16 06:44:01 is there a way to use recipe to build a package using the sdk May 16 06:46:07 I'm looking for a simple way for developpers to build multiple packages without having to think about configure flags and so on May 16 06:58:04 Anyone remember the bitbake parameter to build targets but discard intermediate object files after each target is built? May 16 06:58:49 I assume by using that bitbake parameter I can build world with only a few hundred gigs. May 16 07:00:24 msvb-lab: INHERIT += "rm_work" May 16 07:01:02 ed2: So, $ INHERIT += "rm_work" bitbake world May 16 07:02:07 msvb-lab: echo 'INHERIT += "rm_work"' >> conf/local.conf && bitbake word May 16 07:02:50 ed2: Oh, thanks. Does that cause bitbake to keep all intermediate 'work' files until the 'world' target finishes and then they are deleted? May 16 07:03:05 Or does bitbake delete the intermediate files as it builds dependencies? May 16 07:03:38 msvb-lab: i actually tried building world to get some numbers, as we discussed it. taking only a plain poky into account for qemuarm, it summed up to about 90GB for me May 16 07:04:31 LetoThe2nd: Thank you, that's useful. Because I'm building Wind River (a bit bigger than poky) I need a half terabyte or so. May 16 07:04:52 ...which I don't have to spare. May 16 07:05:54 msvb-lab: tell your boss that hardware is cheap in comparison to your testing and waiting time ;-) May 16 07:06:44 LetoThe2nd: True, it's a longer story than that unfortunately. May 16 07:07:07 msvb-lab: thats what every boss says ;-) May 16 07:08:09 ed2: I'd like to retroactively use 'rm_work' for the last 20 hours of building. Does $ bitbake clean world do that? May 16 07:08:40 ed2: btw, "bitbake word" is a wonderful typo ;-) May 16 07:08:57 msvb-lab: :) May 16 07:09:09 If bitbake(1) works like make(1), then even after bitbake clean the next run will detect the target.rpm file present and timestamped and will not rebuild it. May 16 07:10:04 msvb-lab: I'm not sure it's possible to use it like that. bitbake loads configuration at the start as far as I know. May 16 07:10:41 msvb-lab: you can read about rm_work here: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-rm-work May 16 07:12:47 ed2: Thanks for the reference, I had seen that document and then lost track of where to find it again. May 16 07:13:49 It seems that a half-brained approach like manually deleting 'build/work' once in a while reduces storage considerably. May 16 07:14:16 ...and probably the bitbake world build (especially if '-k' keep going is used) will still succeed. May 16 07:14:49 msvb-lab: I usually remove build/tmp. next build takes everything it can from sstate, so it doesn't take long. May 16 07:15:32 ed2: Oh, I was assuming the next build would start from the beginning. I see the sstate directory is quite large so your suggestion makes sense. May 16 07:16:43 ed2: I'm going to stop the build and restart with INHERIT += "rm_work" hoping at least sstate will help. May 16 07:16:47 msvb-lab: you can play with it on something smaller than 'bitbake world' :) May 16 07:17:44 msvb-lab: you can stop the build, remove tmp, enable rm_work and start it again. That would save you some disk space I believe. May 16 07:17:56 I'll build a few individual packages to be sure, then world after that. May 16 07:18:25 ed2: The stop, remove, rebuild approach is just what I'm planning. May 16 07:18:31 Looking at a week of building, but at least it's the only build I'll need this year. May 16 07:19:14 LetoThe2nd: ...which is the main reason I'm not buing a build farm. Too many days of the year not using it. May 16 07:19:57 LetoThe2nd: I've thought about renting a VPS or cloud computing hours. Not sure how practical that would be for short term (one time) world builds. May 16 07:31:29 msvb-lab: i can confirm that it is highly useful. if in doubt, just fire up an ec2 instance for the build time, dump everything on s3, done. May 16 07:32:16 msvb-lab: if you're only doing a couple of builds per month, it is probably cheaper, yes. May 16 07:33:16 LetoThe2nd: Sounds like an interesting option, although my credits are on Azure. Might have a similar outcome. May 16 07:33:57 msvb-lab: as long at it runs linux, all is fine. at the yocto dev day they usually go for GCE. May 16 07:34:06 I wish there were a document for the steps needed to build poky world on EC2/S3 along with cost estimate. May 16 07:35:28 i'd say that there's too many variables in this question for a document to properly answer it May 16 07:36:07 LetoThe2nd: Too many variables to build poky world on qemu-x86? May 16 07:36:21 msvb-lab: absolutely. May 16 07:36:41 LetoThe2nd: You mean like 'rm_work' type variables? Probably version preferences... May 16 07:37:17 i mean like: interactively or not? speed or cost optimized? keep artifacts for later? if yes, which? May 16 07:38:34 Most of those variables apply to noncloud builds too. I wish for a document to help those already established with a local build to do it on a VPS. May 16 07:38:55 i guess then i don't understand the question. May 16 07:39:09 ...so I imagine a person who has a $ bitbake already correct, should be able to log into VPS and type the same thing there. May 16 07:40:03 There was no question posed, rather a wish 'to have a document listing the steps involved in setting up a VPS and then building pokey on it.' May 16 07:40:31 if the infrastructure on the remote end is already set up accordingly. which you usually have to do on startup, as the compute nodes do not have persistent state - respectively you do not want persistent tate that can be automatically recreated. May 16 07:40:34 So this is a document (that already exists) to just get a VPS up and running on GCE/Azure/Amazon, but specific to bitbake builds. May 16 07:41:10 I'm getting this error, does anyone know how to fix this? https://pastebin.com/yV69D9S8 May 16 07:41:36 msvb-lab: well in the simplest case, this is 1) have your compute provider hand you a linux shell 2) the yocto quick start guide. May 16 07:42:56 LetoThe2nd: Yes, and those steps can be explained by different 'getting started' docs. May 16 07:43:29 msvb-lab: 2) exists. May 16 07:43:51 msvb-lab: 1) exists separately for every provider, its their own documentation. May 16 07:44:33 LetoThe2nd: Even better would be a 'yocto container' which one could start on a given provider and type 'bitbake world' after logging in. Maybe this exists, not sure. May 16 07:44:50 Container like a LXC, Docker, or CoreOS/Rocket. May 16 07:45:20 msvb-lab: such a thing (partially) exists: https://git.yoctoproject.org/cgit/cgit.cgi/crops/tree/README.md May 16 07:45:22 rj_: I took a look at the log but it's not detailed enough to show what's the sanity problem with the file in question 'orocos...pc' May 16 07:46:09 rj_: Have you looked at orocos-rtt-gnulinux.pc to ensure it's okay? Is the file empty or maybe has CR/LF? May 16 07:46:25 rj_: probably some magic in the .pc file is wrong but sorry, i'm not competent to comment on it. May 16 07:47:23 LetoThe2nd: Oh CROPS is cool, thanks for the tip. Particularly since it can bootstrap a Zephyr environment. May 16 07:48:51 rj_: If you don't know how pkg-config(1) works, take a look at some other *.pc files near the one in question and compare them. Maybe you'll find some reason that bitbake considers a sanity problem? May 16 07:49:05 msvb-lab: i've never used it, so don't expect me to provide more meaningful information on it besides that "it exists" May 16 07:49:45 LetoThe2nd: In the end, it's okay since yocto and bitbake are seeminly used mostly by folks on a regular basis who know what they're doing. May 16 07:50:03 ...user friendly to the experts but not so much to the novices. May 16 07:51:15 msvb-lab: Wait a sec, ill pastebin the file May 16 07:51:45 msvb-lab: i still don't see why executing two well-documented tasks one after the other is expert only, but ok. of course building a complete distribution is not as trivial as switching on a readily installed lightbulb May 16 07:53:22 msvb-lab: This is the pc file that is generated: https://pastebin.com/V8R9rkVB May 16 07:54:17 rj_: Best would be if someone with knowledge of the sanity checking logic can speak, but it seems we're out of luck with that. May 16 07:55:25 rj_: I don't see any problem with the .pc file. If bitbake were made for novices (like me) then it would have a easy to find (like in scripts/bin) check_sanity command and we would now pass in the .pc file and get an immediate answer. May 16 07:56:22 guessing from the error message, it is that your build tmp path is leaking into it. May 16 07:56:27 But I'm afraid you'll have to unravel the onion until figuring out what part of bitbake failed, under which conditions, which implicit variables, and if any of that was dynamically generated (and by which script.) May 16 07:56:41 there is kind of linux command line to specify something we dont want ? Like for example when we want everything we put "*" if we want everything that ends with ".h" we put *.h ... But in case if we want to do exclusion ? May 16 07:56:41 which will be obviously nonexistent during runtime. May 16 07:56:44 Thanks. May 16 07:59:04 LetoThe2nd: then how does it add that path when its nonexistent May 16 07:59:14 rj_: "it" May 16 07:59:51 rj_: i don't know where the .pc file comes from. and i'd say that it probably is not bitbake that creates it, but maybe some scripting in the package that you want to build May 16 08:00:49 LetoThe2nd: ah alright, well ill try to find out then May 16 08:01:15 .pc files usually are generated from .pc.in files, which are unpacked from tarballs. May 16 08:01:40 so while it often looks like "bitbake fails or breaks", in the most cases it really is crappy upstream source that breaks stuff. May 16 08:01:59 rj_: Manually download orocos*.tar.gz (or whatever it's called) and look for a .pc.in file. May 16 08:02:57 LetoThe2nd: That's true, and in most cases (like this one?) just doing the expected ./configure && make won't produce the sanity error so unravelling the script onion is required. May 16 08:03:52 msvb-lab: of course ./configure and make won't produce any errors. they live in their happy on-target, native compilation world usually. May 16 08:04:34 ...and test a controlled set of variables like on a clean debian system. May 16 08:05:00 and thats the reason why we need all this sanity checking, annoying as it might be, May 16 08:05:15 Still it would be nice to have a 'sanitycheck.sh' in order to partially test whatever is described as flawed by bitbake. May 16 08:06:27 msvb-lab: Alright, found the pc.in file https://pastebin.com/Ua07XwHd May 16 08:13:12 rj_: It's unlikely the way to go, my suggestion to unpack and look at .pc.in was in response to the question 'where to .pc files come from?' May 16 08:14:15 rj_: But to find the actual problem (which could be within a layer, .bb file, or orocos sources) requires considerable debugging. May 16 08:15:28 my bets are on the build script just foing one of the path replacements wrong. May 16 08:15:32 Like you might try building orocos manually after matching as much of the bitbake environment as possible? Like at a minimum $ . init-intel-x86-env or whatever environment you set up. May 16 08:16:10 LetoThe2nd: So you would expect to find the flawed path in a .bb file? May 16 08:16:22 msvb-lab: no. the exact opposite. May 16 08:16:36 The .bb file is costum, it could be that i simply made it the wrong way May 16 08:16:52 LetoThe2nd: Like a hard coded path in '*.pc'? I didn't see any. May 16 08:17:07 msvb-lab: i'd expect the script in the source that does the pc.in -> .pc to incorrectly react to one of the paths. May 16 08:17:46 of course it could also be the recipe setting a path wrong. but its almost certainly not hardcoded. May 16 08:18:35 rj_: How about starting from scratch and doing $ bitbake orocos? May 16 08:19:13 rj_: It would likely fail in the same way, but at that time you have produced much less intermediate files over which to grep(1) for answers. May 16 08:19:16 rj_: probably that even is not needed. look at the logs that are created during the configure stage. May 16 08:19:42 ChrysD: How flexible are you with regards to stuff you can use? Can you use a pipe? Then I'd suggest "ls | grep -v somthingYouDon'twant" May 16 08:19:55 LetoThe2nd: Are those logs stored in build/tmp/sysroots/orocos* or something? May 16 08:20:09 ChrysD: maybe some find -exec :-) May 16 08:20:11 Definitely a good idea if they can be found. May 16 08:20:25 JoiF, LetoThe2nd : Thanks. May 16 08:20:26 msvb-lab: I'll try and locate them May 16 08:20:28 That'll work too May 16 08:21:34 msvb-lab: they are. like tmp/work/$MACHINEARCH/$PACKAGE/$VERSION/temp May 16 08:21:56 log.do_configure right? May 16 08:22:45 yes. and the internal config.log (for autotoolized packages for example) are certainly around too, in the build directry. May 16 08:22:54 so you just have to dig a little. May 16 08:23:36 LetoThe2nd: well i got the log.do_configure. It does have some paths in it to : /home/user/poky/build/tmp/sysroots/genericx86-64/usr/include May 16 08:23:45 Which is to find boost apparently May 16 08:23:46 rj_: Additionally try $ grep -i -d recurse sanity tmp/work/$MACHINEARCH/ May 16 08:24:06 ...oops I mean: grep -i -d recurse sanity tmp/work/$MACHINEARCH/oroco* May 16 08:24:21 rj_: of course it has pathes, the question is where and which pathes are put into the .pc - why they are not sysroot relative May 16 08:27:15 rj_: Compare the oroco*.pc file with another package .pc file, particulary looking at the string 'tmp'. May 16 08:27:32 Do you find that one has 'tmpdir=...' and the other doesn't? May 16 08:28:10 Or do some paths with 'tmp' not exist? Test '/home/user/poky/build/tmp/sysroots/genericx86-64/usr/lib' for example: May 16 08:28:14 ls /home/user/poky/build/tmp/sysroots/genericx86-64/usr/lib May 16 08:28:24 ...and repeat for all paths in the .pc file that contain 'tmp' May 16 08:28:57 ls /home/user/poky/build/tmp/work/core2-64-poky-linux/orocos-rtt/2.6.0+gitAUTOINC+1df3ad9acd-r0/sysroot-destdir/usr/lib/pkgconfig May 16 08:30:12 msvb-lab: All paths exist May 16 08:30:26 and the last one you just mentioned is where the .pc file is stored May 16 08:32:06 rj_: So bitbake is indicating a problem with oroco (relating to tmpdir and .pc file) that isn't indicated with other targets that have similar .pc files. May 16 08:32:50 So it seems May 16 08:33:53 the look at the other packages with the similar pc files if they need to be passed some additional arguments to the configure stage. May 16 08:36:58 rj_: The .pc file is not important for building oroco, so one option is to write your own fake .pc.in file and put it in the package 'downloads/oroco-*.tar.gz'. Rebuild with a nearly empty .pc.in and the resulting .pc surely can't be considered insane? May 16 08:37:23 ...I just fear that if you manipulate the downloads/oroco-*.tar.gz file that it will be overwritten when you rebuild. May 16 08:38:45 rj_: Another option is to try to figure out what criteria bitbake uses when determining the sanity of a .pc file. That's probably an hour long (or afternoon?) task though. May 16 08:39:38 msvb-lab: Sounds like fun... (._.)7 May 16 08:39:48 msvb-lab: nope, thats probably easy. May 16 08:40:00 msvb-lab: I'll try and change the pc.in file when bitbake works again... May 16 08:40:14 "ERROR: Only one copy of bitbake should be run against a build directory" May 16 08:40:31 if you look at the pc file that gets packages/installed. if there is a path in there that is not target-relative, but contains something like tmp/whatever, then the .pc file is insane. simple as that. May 16 08:41:30 LetoThe2nd: That's why bitbake must declare any other similar (meaning with hard coded build/tmp paths) as insane as well. May 16 08:42:09 But we're not seeing that? Is bitbake smart enough to understand the purpose of pkg-config(1), it's .pc files, and test for relative paths? May 16 08:42:19 If so, then that's the direction to investigate. May 16 08:42:32 msvb-lab: i just don't see the purpose of evaluation how bitbake checks the file. if the path is in there, then the quesiton is *why*. the question is not *how it is detected* May 16 08:43:01 ...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/ May 16 08:43:43 I'm a little confused about something. May 16 08:44:00 Smitty_: i am a little confused about soemthing too. May 16 08:44:03 I have a new static library that I wish to include in the SDK build May 16 08:44:20 LetoThe2nd: Depends on which problem we're trying to solve first: 1) Getting bitbake to build oroco or 2) correcting the oroco build configuration (for later on after the distro is created. May 16 08:44:42 Right now, nothing requires this library, but in the future some other packages will depend upon it. May 16 08:44:45 msvb-lab: For now it just has to build May 16 08:44:49 msvb-lab: 1) is in most cases pointless, as not reproductible. May 16 08:45:14 Smitty_: which holds true for many packages. May 16 08:45:15 So, how do I get the library included in the SDK image ? May 16 08:45:22 Why can't i kill the bitbake process.... May 16 08:45:39 So far, the only way I can figure out is to add it to a depends list for soemthing else May 16 08:46:45 Smitty_: you can for example set it as a TOOLCHAIN_TARGET_TASK for the desired image. May 16 08:49:03 "ERROR: Only one copy of bitbake should be run against a build directory" Anyone knows how to kill the process? May 16 08:49:47 rj_: I'm dealing with a similar problem, lib32-qt4-embedded building for 1 1/2 hours even after Ctrl-C. May 16 08:50:25 msvb-lab: Building qt4 took me really long aswell yesterday May 16 08:50:44 msvb-lab: But atm im not building anything... And it still throws me this error May 16 08:50:59 ...oh cool, just after I complained the build finally stopped. Now I can use $ INHERIT += "rm_work" bitbake May 16 08:51:30 I can't seem to find the bitbake process either... May 16 08:52:53 ill just reboot i guess May 16 08:52:55 brb May 16 08:57:09 msvb-lab: okay, so should i just remove all paths that contain the tmp dir? May 16 08:57:18 in the pc.in file May 16 08:58:23 Leto... Do you mean I would add it at the top level sdk.bb file, or in my library's bb file ? May 16 08:59:09 rj_: Good idea, but you'll have to make sure that your changes to .pc.in (or .pc as bitbake builds - your choice) is actually used. May 16 08:59:34 rj_: ...since there's the possibility that whatever you modify before bitbake starts, will get overwritten. Do you think it will? May 16 08:59:44 Smitty_: to the image recipe. usually the sdk is meant for a specific image, right? May 16 09:01:16 Like I know there's at least one cache (sstate?) that bitbake reads from. And it might download oroco-*.tar.gz again and unpack again. Maybe you can avoid that with a '-c' parameter to just do_config or something? May 16 09:02:09 Smitty_: here is some additional information: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#sdk-adding-individual-packages May 16 09:04:17 yep. So the recipe for my library is the one to modify, by adding my library to TOOLCHIAN_HOST_TASK, and TOOLCHAIN_TARGET_TASK ? May 16 09:05:22 Smitty_: no, the image recipe is the one to modify. in natural language: "i want my image to look like this, and the corresponding sdk to contain these additional things." May 16 09:07:02 msvb-lab: I'll just change it, build it, and look at the file to see if it actually changed ^^ May 16 09:10:35 msvb-lab: Well...It builds now May 16 09:10:51 Not sure if everything will work correctly but it passed the sanity check now May 16 09:12:42 noob here : I ran bitbake for my board . how to try the images generated on 1)Qemu 2)burn it to the flash memory for board any link to documentation will help May 16 09:13:31 rj_: So you just did #1 of the 1) build and 2) correct. May 16 09:13:46 nikincn: for 1) if your board is not super close to one of the qemu provided emulation boards, you can't run it there. you have to build for MACHINE qemu May 16 09:14:10 msvb-lab: I removed all paths that had tmp in them. Build the image, and got no errors :) May 16 09:14:29 i c , thanks @ Letothe2nd May 16 09:14:32 rj_: Obviously, you can ignore #2 (like if you don't have time) but if any other packages depend on oroco libs, there might be another failure when the .pc file is read but it is not correct. May 16 09:15:03 nikincn: for 2) please consult the documentation of your board, its hw specific May 16 09:15:08 rj_: Hard to tell if removing all those paths lead to a harmless .pc modification. May 16 09:15:14 msvb-lab: Yea, i'm working on that now, cause the next package orocos-ocl depends on orocos-rtt, so im curious if it will work May 16 09:16:41 ok @Letothe2nd I will check board documentation ,though afai remember they havent given detailed doc May 16 09:17:20 nikincn: well then tell them to provide the documentation, thats certainly vendor duty. May 16 09:18:26 rj_: One reason that the dependencies might work (even without correcting the oroco .pc build configuration) is that the hard coded tmp paths actually point to where oroco is temporarily installed during the bitbake build. May 16 09:18:37 I'm not sure about that, but it might be something to worry about. May 16 09:19:09 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 \ " May 16 09:19:10 rj_: At the very least, you might consider after all is done looking at the final oroco-*.pc file in it's final installed location. May 16 09:19:43 msvb-lab: i will yea May 16 09:19:47 ...and maybe even a simple hello world test in which you read paths like CPPFLAGS and LIBS from pkg-config(1) output. May 16 09:20:03 rj_: $ pkg-config -l -cppflags oroco May 16 09:20:05 The way that my library is included in the SDK is by way of recursion into the subdirectories May 16 09:20:12 they dont have doc for yocto , they have a link for compiling own image but that is just compiling their version from git and loading the generated image on to the board May 16 09:20:21 ...that kind of thing (adjust and correct, since I just wrote semi pseudocode.) May 16 09:20:34 are they obliged to support yocto? May 16 09:20:51 nikincn: no, they are obliged to tell you how to load software onto the board. May 16 09:21:20 nikincn: if they desribe some way, then it might be up to you to create images that fit the process. May 16 09:21:21 Why wouldn't I append my library to the TOOLCHIAN_HOST_TASK variable in my own library recipe ? May 16 09:21:55 rj_: It's likely that the oroco-*.pc.in file should contain '$DESTDIR/usr/lib/pkgconfig/' or similar but instead has `pwd` or something else leading to a hard coded 'build/tmp' in the path. May 16 09:21:55 Smitty_: because then it would be always pulled into the sdk, no matter by which image. May 16 09:22:25 Isn't that what I want ? May 16 09:22:26 ok got it , but tough for a noob May 16 09:22:39 i will google more thanks for ur help May 16 09:22:49 Smitty_: nah. it probably wouldn't work, because then the addition is not visible during the build of the sdk. May 16 09:23:02 Smitty_: scratch my first statement. i think it would never be included. May 16 09:23:36 nikincn: if it is a well known board, there might be something already in place for you. what are we talking about? May 16 09:23:55 firefly rk3288 May 16 09:25:16 nikincn: ok, their site look like you're in for a lot of fun. May 16 09:25:25 msvb-lab: great, next package has the same error and more ;-; May 16 09:25:50 nikincn: my personal advice would be to get access to the bootloader and try to network boot May 16 09:26:20 ok will try that May 16 09:31:20 rj_: If the oroco package didn't have the error anymore after you manually modified .pc.in in the tarball, then this flaw is probably present in all the other oroco-* packages. Congratulations. May 16 09:32:31 msvb-lab: Proably yea, its a qa issue again: https://pastebin.com/dL6BqDHS May 16 09:32:35 Only alot more this time May 16 09:32:45 rj_: So once it again it comes down to 1) cheap quick get to build via manual intervention or 2) upstream, figure out maintainer, bug report, correct .pc.in, maybe a newer/older version, lots of other work. May 16 09:33:28 bitbake -c clean TARGET will cleans the images of the target ? Or it will remove allso the local.conf etc ? Thanks. May 16 09:33:36 rj_: You're doomed if you do #2 and you're doomed if you don't #1, bitbake and yocto layer maintenance seems to be an equal opportunity project. May 16 09:34:39 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 ? May 16 09:35:13 Smitty_: because those that are actually pulled in through dependencies do not have to be explicitly mentioned May 16 09:35:14 msvb-lab: Oh well, at least i got 1 more package working. Thanks for the help! May 16 09:35:19 If what you are suggesting is the "right" way to accomplish it, I would expect to see hundreds of libraries listed May 16 09:35:24 rj_: That pastebin indicates that the oroco version that pokey maintainers chose is hopelessly flawed. May 16 09:35:45 rj_: What about figuring out how to completely remove oroco-* from the build? May 16 09:35:54 msvb-lab: Not an option sadly May 16 09:36:00 rj_: there is also 3) include a patch in your recipe. May 16 09:36:15 rj_: There is a bitbake target or argument which gives you a dependency tree. Maybe you can take a look at that tree to see how much stuff depends on oroco. May 16 09:37:02 ...and if you're lucky that (almost) nothing depends on it, then remove it from its corresponding bb file. May 16 09:37:18 msvb-lab: Atm nothing depends on Orocos May 16 09:37:37 rj_: Is it an option then, to simply remove oroco from the build? May 16 09:37:38 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 ? May 16 09:37:50 Smitty_: exactly. May 16 09:38:13 msvb-lab: It is not sadly, i have to get this working to run some costum software on this build May 16 09:38:32 rj_: If not, then LetoThe2nd idea of correcting orocos and patching in bb is a good idea. May 16 09:38:34 msvb-lab: And that software does heavily depend on orocos May 16 09:38:39 Smitty_: if i have something in the image that depends on a library, then when i build a sdk for that image, the library is automatically pulled in through dependencies. May 16 09:39:24 rj_: Take a look at all public versions of the Orocos .pc.in file, and maybe one of them is correct. That gives you an instant patch baseline. May 16 09:40:23 msvb-lab: as far as i know the one i have now is the newest version straight from their repository May 16 09:41:03 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 ? May 16 09:41:50 Smitty_: i suggest to explicitly add it in the image for the time now. once something is added to the image that implicitly depends on it, you can remove the explicit part again. May 16 09:42:51 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. May 16 09:43:12 Smitty_: the one that modifies the image recipe is in charge. simple as that. May 16 09:43:39 Smitty_: if you allow people without understanding your structure to modify something as essential as the image recipe, you're doomed anyways. May 16 09:48:27 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? May 16 09:50:00 LetoThe2nd: By the way, I think you suggested deleting tmp and bitbake would read from sstate instead of rebuilding. That's a cool feature, and I'm confirming (to myself) that that works as intended now. May 16 09:50:31 msvb-lab: nope it was ed2 :) May 16 09:50:36 Build tasks that usually take five minutes are flashing by. May 16 09:51:03 Oh, it was ed2. In any case I didn't delete tmp but rather tmp/work*. That way I keep the images and rpms. May 16 09:51:39 rj_: you remove the tmp paths from the pc file May 16 09:51:50 I wasn't sure bitbake would be smart enough to avoid rebuilding though, now I'm a happy guy saving 20 hours of time while rebuilding with 'rm_work'. May 16 09:51:54 rj_: how depends on each upstream as it's a bug in their makefiles May 16 09:52:23 rburton: ...or a bug in the upstream .pc.in files right? May 16 09:52:48 msvb-lab: sure i was counting that as part of the "make" May 16 09:53:12 rburton: Ah alright then, i did indeed remove those paths from the file and it didn't give the error after that May 16 09:53:16 rj_: The wierd thing is that Orocos builds correctly in other (non bitbake) environments, have you confirmed that? May 16 09:53:47 I can't help but wonder if there is a solution to this in some .deb or .rpm where a patch is included. May 16 09:53:50 msvb-lab: it does, it's compiled and working on the laptop next to me May 16 09:54:06 ...or the upstream maintainer of Orocos has the correction in the trunk of a SCM. May 16 09:54:27 rj_: You compiled it from scratch on the laptop or you used a binary package? May 16 09:55:03 upstream maintainers are often cross-compile ignorant. in many cases they're even other-distribution ignorant May 16 09:55:04 msvb-lab: Oh thats a good point actually, they used a deb file to install it on there... May 16 09:55:29 rj_: in the ideal world you can send a patch upstream instead of sedding the paths out afterwards May 16 09:55:58 rj_: It's likely that the deb was build from a .src.deb (or whatever the deb sources are called) that either don't have the flaw or have a patch that corrects it, you know? May 16 09:56:59 rj_: There might be clues to packages.ubuntu.com: and download the sources. Then look close at .pc.in and any .diff/.patch files. May 16 09:57:31 msvb-lab: if i remember correctly these deb packages are costum made May 16 09:58:16 rj_: Okay, but there are still sources somewhere. If not, then you'll have to reinvent the wheel and do all the work over again. May 16 09:58:45 msvb-lab: The sources are available on the orocos site yes, thats where i get them from now with my recipe May 16 09:59:04 Obviously if you look in laptop$ cat /usr/lib/pkgconfig/orocos-*.pc and there's junk in there with bad paths, then the problem was never corrected in the .deb either. May 16 10:02:27 msvb-lab: There isnt even a .pc file for orocos on that laptop May 16 10:03:29 msvb-lab: Oh, nvm it's not under /usr/lib/pkgconfig but some other path May 16 10:04:07 It's pretty much the same .pc file May 16 10:04:31 rj_: You can always do dpkg -L to find the files corresponding to a package. May 16 10:05:24 rj_: So in the place of '/home/user/yocto/build/tmp/...' you find similar paths in the laptop version? May 16 10:06:24 msvb-lab: Yea, only now its /opt/somename/lib and /opt/somename/include May 16 10:07:04 rj_: Those paths are okay as long as they contain the actual orocos files. May 16 10:07:19 msvb-lab: Which they do May 16 10:08:10 It means that either the deb maintainer corrected the Makefile or .pc.in files (with a patch) or it's the bitbake environment which indirectly causes the failure, like maybe it wipes out $DESTDIR or something. May 16 10:14:32 How is core-image-testq May 16 10:15:11 how is core-image-testmaster supposed to be deploy? There seems to be some installer scripts, but when are they run? May 16 10:20:58 hello everyone May 16 10:22:11 could somebody help me to resolve this problem ---> http://ix.io/tTd ? May 16 10:22:15 thank you in advance May 16 11:14:27 Ox4: well what is not clear about the error message? May 16 11:15:09 Ox4: the package lighttpd wants to install the file /www/pages/index.html, the package web-application wants to install the file /www/pages/index.html May 16 11:15:23 Ox4: that clashes, it tells you as the user to resolve the conflict. May 16 11:54:31 Hi all, can you help me add include directories for CMake project? I need some additional include paths to sysroot when building a package. May 16 11:56:17 Wouldn't you usually have a Find.cmake file that you can use with find_package(), which defines a number of targets that you can just add to your local build target, and that automatically adds the required include paths? May 16 11:56:21 Wouldn't you usually have a Find.cmake file that you can use with find_package(), which defines a number of targets that you can just add to your local build target, and that automatically adds the required include paths? May 16 11:57:41 neverpanic: hm, let me see, if such package provide pkg-config file May 16 11:58:20 That would be a good solution, yes. For pkg-config in CMake, see https://cmake.org/cmake/help/latest/module/FindPkgConfig.html May 16 12:02:59 neverpanic: yeah, there's a *.pc in sysroot, which means, I have at least some entry point... May 16 12:03:19 neverpanic: ok, will need to adjust some includes in sources, but .. anyway, at least something May 16 12:09:22 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 ? May 16 12:09:50 How does that help ? May 16 12:33:55 hmmm so is it an intended feature of RSS that any task dependency (even a dependency on say foo:do_deploy) causes the recipe-sysroot population of that dependent task's sysroot components? May 16 12:47:45 hi all i have a recipe inherit for module but sometimes i have to rebuild kernel before rebuild my custom module ... Someone have already seen that ? May 16 12:53:16 PinkSnake: if your kernel or its config changed it will rebuild. You can check the reason why bitbake ignored the previous state with e.g. "bitbake-diffsigs -t linux-yocto compile" May 16 12:54:58 @nrossi i'm using a custom kernel recipe so i have maybe forgotten something inside. i'm going to try your trick first thx ;) May 16 12:56:45 Smitty_: Yocto by default omits creating empty packages, so your main package is probably not being created if you only ship a static library May 16 12:57:06 Smitty_: The default value for RDEPENDS_${PN}-dev includes "${PN}", though, so the dependency is there by default May 16 12:57:44 Smitty_: So when you attempt to install ${PN}-dev, it fails because it rdepends on ${PN}, which doesn't exist. Potential solutions include: May 16 12:58:07 Smitty_: (a) ALLOW_EMPTY_${PN} = "1", which will create an empty ${PN} package May 16 12:58:36 Smitty_: (b) RDEPENDS_${PN}-dev = "", which will avoid the dependency on the empty package (at the expense of requiring your users to manually install ${PN}-staticdev) May 16 12:58:54 Smitty_: (c) RDEPENDS_${PN}-dev = "${PN}-staticdev", which makes your -dev package depend on the static lib May 16 13:10:17 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 ? May 16 13:10:38 Is the package being built ? May 16 13:15:21 So, in trying to undertsnad this issue better, I start with a HEAD checkout of Yocto, and build core-image-minimal. Now I follow this: https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles#Using_a_new_layer_for_recipes May 16 13:19:14 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 ? May 16 13:20:28 @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 ? May 16 13:21:02 hi, is there a way I can import a custom module (that I put in my-meta/lib/mymodule for now) from an anonymous python function in a recipe? or do I have to manually set sys.path so that python can find it? May 16 13:22:44 PinkSnake: inheriting just module should be fine, however you were saying that your kernel was rebuilding, which is likely not related to your module but some other change you are making. diffsigs should show you the variables that you changed that caused the rebuild. May 16 13:22:48 @ironzorg http://wiki.kaeilos.com/index.php/Howto_build_a_kernel_module_out_of_the_kernel_tree May 16 13:23:26 ironzorg: have you tried import mymodule? May 16 13:25:47 PinkSnake: I meant a python module, not a kernel one May 16 13:26:01 rburton: yes it's not in the path so it's not loaded May 16 13:27:03 I want to be able to load a module stored in an arbitrary layer, is that handled by bitbake automatically (like do I have to put my module in a certain sub-directory of the module and that's it), or is it non trivial? May 16 13:27:22 @ironzorg my bad i need a coffee i think... May 16 13:27:33 np May 16 13:30:26 ironzorg: sure your layer is in BBPATH? May 16 13:30:44 yes May 16 13:31:10 ironzorg: does the layer.conf set BBPATH? May 16 13:31:12 so this should work by itself? having modules in a meta's `lib` directory should work off the bat? May 16 13:31:20 yes May 16 13:31:32 my setup is definitely adding /lib to sys.path May 16 13:31:41 so i suspect that works on BBPATH in layer.conf May 16 13:32:02 `BBPATH .= ":${LAYERDIR}"` yes May 16 13:32:12 @nrossi ok i found it, a change from our device-tree repo, but i don't understand why Yocto doesn't do the rebuild the kernel before rebuild modules May 16 13:32:28 ironzorg: WARNING: m4-1.4.18-r0 do_test: /home/ross/Yocto/poky/meta-poky/lib /home/ross/Yocto/poky/build-selftest/lib /home/ross/Yocto/poky/meta/lib /home/ross/Yocto/poky/meta-yocto-bsp/lib /home/ross/Yocto/poky/meta-selftest/lib /home/ross/Yocto/meta-ross/lib /home/ross/Yocto/meta-intel/lib /home/ross/Yocto/meta-intel/common/lib /home/ross/Yocto/poky/bitbake /home/ross/Yocto/poky/bitbake/lib /home/ross/Yocto/poky/bitbake/bin /usr/lib/python3.4 /usr/lib/p May 16 13:32:34 thats my sys.path inside a task May 16 13:32:38 the python search path is modified by oe_import(d) in base.bbclass. depending on when your varaible is expanded, you could try importing it before it's modified May 16 13:32:40 keep that in mind May 16 13:32:42 *maybe* anon python is executed too early May 16 13:32:50 anon python should be fine May 16 14:04:17 Smitty_: No, that's not it. You're producing a static library, PACKAGES contains both "${PN}" and "${PN}-staticlib" and FILES_${PN}-staticlib contains /usr/lib/lib*.a by default, so your installed static library gets packaged in ${PN}-staticlib. If you don't have any files in ${PN}, it will end up empty and won't be created. May 16 14:04:30 Smitty_: None of this is related to whether some other recipe or package depends on this. May 16 14:42:23 Do I have to set ${PN}-staticlib ? May 16 14:53:09 I want to access a files meta/recipes-multimedia/ of yocto in bsp meta May 16 14:53:44 how should I set it in FILESEXTRAPATHS May 16 14:54:58 @ayaka i think it depends what you want to do with this files May 16 14:55:23 PinkSnake, oh it is a patch file May 16 14:56:15 for example I want to access meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/ in my layer meta, as I offer a customize version for it May 16 14:56:33 but it could inherit most of patches from the original version May 16 14:59:47 Smitty_: What do you mean with "set ${PN}-staticlib"? You cannot "set" a package, so I'm not sure what you mean. May 16 15:08:34 Dio I have to populate that value in some file ? May 16 15:10:11 PinkSnake, I have known, the COREBASE, thanks May 16 15:13:37 Is there a simple way to pull in a package that lacks a recipe? Looking to include ruby2.2-dev in a build. May 16 15:13:47 I imagine not. May 16 15:17:53 majuk: what do you mean? May 16 15:19:10 rburton: I want to include the package ruby-dev in my system and there is no recipe I can find. May 16 15:19:47 bitbake ruby will generate ruby-dev May 16 15:19:52 recipes built many packages May 16 15:21:15 Well it might be /generated/ but it is not ending up in my system. "gem install mmap" complains it can't find the ruby.h lib May 16 15:21:45 Krogoth branch fyi May 16 15:24:28 development packages aren't installed by default, you'll need to add ruby-dev (or similar) to your IMAGE_INSTALL May 16 15:26:24 majuk: yeah you'll need to add it to your image. May 16 15:29:48 Smitty_: What value? ${PN}-staticlib is a package name, packages are defined in a recipe in the PACKAGES variable; ${PN}-staticlib is part of the default value of PACKAGES, so you don't have to add it manually. May 16 15:32:00 rburton: joshuagl: Thanks. I... well, I assumed there wasn't a recipe. I really need to get better at navigating the file structure. May 16 15:33:09 majuk: remember that eg the ruby dev files are going to be part of the ruby build May 16 15:33:15 so the ruby recipe will generate them May 16 15:33:48 rburton: FYI, Mentor *is* intending to volunteer to maintain some recipes, I'm just gathering volunteers from my team and figuring out which ones in particular to volunteer for, since I tend to dabble in either classes or a random hodgepodge, nothing specific jumps out at me as of yet. Just so you know we're not ducking our responsibilities here :) May 16 15:34:05 * kergoth yawns May 16 16:02:07 kergoth: thanks, good to know May 16 16:03:17 np May 16 19:11:45 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 ? May 16 19:12:19 because there is no assumption that you have layers inside your source tree May 16 19:12:22 none of mine are May 16 19:13:08 a sample gets generated if you oe-init-build-env from an empty build tree May 16 19:13:14 after that its a configuration file like local.conf May 16 19:13:44 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 ? May 16 19:15:13 patches welcome. if you've a mega-repo with all your layers in you can just provide a sample bblayers.conf May 16 19:15:31 which will get used when someone does oe-init-build-env on an empty tree May 16 19:15:34 so they have nothing to do May 16 19:15:42 ??? May 16 19:15:53 You've lost me. May 16 19:16:11 when you run oe-init-build-env with an empty build directory, the script will write a bblayers.conf for you May 16 19:16:22 And, what will be in it ? May 16 19:16:29 bblayers.conf isn't "generated", it's copied from a template May 16 19:16:33 that's all May 16 19:16:38 the template is bblayers.conf.sample May 16 19:16:59 in meta/conf/bblayers.conf.sample, and other layers can provide their own. poky does this. May 16 19:17:10 I must be missing somehting really fundamental May 16 19:17:29 the key point is that bblayers.conf isn't a generated file May 16 19:17:41 its a configuration file for you, and a convenient starting point is provided May 16 19:17:44 same as for local.conf May 16 19:17:54 we *could* just give you an empty local.conf May 16 19:18:07 but no, you get a sample to edit May 16 19:18:55 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. May 16 19:18:58 Right ? May 16 19:19:12 can't argue with that May 16 19:19:54 And, the Yocto project generously provides a basic OS image so that dumb developers like me don't have to start from nothng May 16 19:19:58 right ? May 16 19:20:21 it provides sample recipes so you can build your own images yes May 16 19:21:20 By that I mean, the Yocto project provides the "source" for pre-defined layers which when built (e.g. core-image-minimal) produce a bootable OS image May 16 19:21:45 yes May 16 19:24:45 When I clone the current git://git.yoctoproject.org/poky, I receive all those recipies, but then before I build, I "have to" run oe-init-build-env, This magically created a build directory with a bunch of configuration files which then allows me to build the layers I received May 16 19:24:51 samples / examples are provided, it's expected that nearly everyone is going to have to heavily customize from there May 16 19:25:04 it's not magic, it copies a couple of example files, that's all May 16 19:25:09 yes the configuration files are copied from meta-poky/conf/*.sample May 16 19:25:22 as you cloned poky, and that is configured to use the samples in meta-poky May 16 19:26:07 if you cloned oe-core directly, it would just configure the meta/ layer on its own May 16 19:26:17 by all means submit issues if you have ideas for how to improve the usability May 16 19:26:25 So, not, if I add my own layer, how do I get that layer to automatically be available ? May 16 19:27:03 as part of your distro layer you can provide your own samples which pull the right layers in the right order May 16 19:27:10 Sorry, not being critical, trying to understand the logic May 16 19:28:13 I guess I was under the impression that oe-init... was looking at what layers were available to be built May 16 19:28:22 yeah, it's not May 16 19:28:29 OK - got it May 16 19:28:44 that needs to be explained May 16 19:29:00 I think al lot of people will be under the same impression. May 16 19:29:13 Documentation is hard. May 16 19:29:16 Indeed May 16 19:29:25 Smitty_: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-core-script May 16 19:29:34 "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." May 16 19:29:38 If it's hard to make, it should be hard to understand ! (or somehting like that) May 16 19:29:44 it specifically says, when you source the file, that it copied new files because they didn't yet exist. i think that makes it fairly clear that it's just giving you a starting point May 16 19:29:46 * kergoth shrugs May 16 19:30:47 i guess the quick start could mention that the files are copied from templates and not inferred from the eather May 16 19:30:52 bug and or patches welcome May 16 19:31:03 * rburton -> somewhere that isn't my desk as its 20:30 May 16 19:38:03 yes, that's a good time to realize that you ain't no longer where you should be :) May 16 20:04:40 Does anyone know what recipe I would need to modify to change the contents of /lib/systemd/system/getty@.service ? I found the file to override systemd's serial getty but not getty May 16 20:07:03 doesn'mt systemd already provide a way to override /lib/systemd/system/ contents by putting the override files in /etc? i dont recallt he exact paths, but see the systemd man pages. in which case you could just install a new package that puts it in /etc May 16 20:07:20 otherwise do a bitbake systemd; then make use of `recipetool appendfile` May 16 20:07:30 whose whole purpose is to ease overriding of files based on target path May 16 20:07:34 :) May 16 20:08:32 Ah, I forgot about overrides. I will check that out, thanks! May 16 20:08:36 dscully: yes easy way is to just drop a file into /etc instead May 16 20:09:21 Does anyone know if we've got a good reason to base our ARM bsps on armv5? May 16 20:10:05 by our I mean the ones that are created with the yocto-bsp script May 16 20:10:54 aren't the layers created by yocto-bsp just examples anyway? i doubt they're of any use iwthout heavy modification anyway May 16 20:11:53 kergoth: yeah they are supposed to be templates basically, but for example, the script asks if you want SMP which is not supported on armv5 May 16 20:11:56 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 ? May 16 20:12:50 Smitty__: that's up to you. some folks put bblayers.conf in source control, others script it (i.e. run a script that sources oe-init-build-env and then runs bitbake-layers add-layer ), and yet others write custom setup scripts rather than using oe-init-build-env at all May 16 20:12:58 kergoth: before fixing the script I wanted to ask if anyone had other info May 16 20:13:04 and of course some folks just prep the buid ldir manually May 16 20:13:07 aehs29: ah, fair enough May 16 20:14:12 Smitty_: a .templateconf at the top level can set TEMPLATECONF=where/the/templates/are May 16 20:14:29 yeah, that's a good way to go if your setup is relatively fixed May 16 20:15:13 So, maybe I am thinking about the whole thing wrong still. May 16 20:16:34 there are lots of layers around that provide a lot of different functionalilty, and some aren't necessarily well behaved, depending on where you got them, so we would *not* want to automatically incldue every layer you have around, even if it was trivial to locate them, which it almost certainly isn't May 16 20:17:04 in some cases just including a layer in bblayers.conf can alter your build (though we're moving to make it so such behavior isn't yocto compatible) May 16 20:18:52 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. May 16 20:19:37 without modifying anything that already works unnecessarily May 16 20:19:40 '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 :) May 16 20:20:00 Yeah, well, that's sloppy May 16 20:20:35 The entire project should reside within one source tree, surely. May 16 20:22:12 I guess it's the classic requirement: A developer should be able to git clone my project, and have everything he needs to start working on anything related to my source code May 16 20:23:21 that's not the case with a ton of git based projects May 16 20:23:32 monolithic source trees aren't used often with git May 16 20:23:55 see how android's sources are handled, for example. countless individual git repositories pulled down with 'repo' via an xml manifest May 16 20:24:09 Smitty_: if you have a monolithic repo which embeds oe-core + bitbake + other layers, then you can just drop in a .templateconf at the top and you're sorted May 16 20:24:31 literally none of my layers are under the same directory as poky or oe-core May 16 20:24:35 (mainly because I have about 20 checked out) May 16 20:24:38 why not ? May 16 20:24:46 because adding meta-clang means the world rebuilds May 16 20:24:59 meta-oe until incredibly recently changed how the X server started May 16 20:25:28 (i mix and match and add and remove as required on a daily basis) May 16 20:25:41 but mainly because they're all separate layers so they're all checked out individually May 16 20:26:21 But the whole point of Yocto is the production of OS images (as stated before). Why would you be changing things frequently ? May 16 20:26:57 because thats my job May 16 20:27:24 don't assume that everyone has a monolithic repo because that's not true May 16 20:27:41 anyway i've told you how to fix the problem you had - .templateconf in the top level of your monolithic repo May 16 20:30:07 I'm trying to get a better understanding of the intended usage paradigm of Yocto becuase it seems like without some more fundamental understanding, I am missing the basic knowledge required to be able to solve my own problems instead of always asking for help May 16 20:30:56 don't try to learn everything in a week - the problem was "can i customise bblayers" and the answer is yes May 16 20:31:21 to solve the problem yourself you could have followed the flow from oe-init-build-env May 16 20:31:30 that gets you to scripts/oe-buildenv-setup or something, which does the cp May 16 20:31:42 So far tonight, I discovered that those files in conf aren't generated. That totally changed my perception of what I was doing May 16 20:40:53 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. May 16 20:43:50 rburton: could you elaborate a little more on the python multilib bug?, I'm not that familiar with mulitlib, as far as I can see, when enabling multilib we are putting files under /usr/lib64 which I think its the way its supposed to be, what I dont know is what the behavior of lib64-$PN should be May 16 20:54:12 Smitty__: there's no standard way to get the path to a shell script which is being sourced. some shells set $0, plenty don't May 16 20:55:56 aehs29: its the /usr/bin/python3-config file that conflicts May 16 20:56:52 sure, but in oe-init.. the test is a bit strange. it took me a long time just to understand what was being attempted. May 16 20:57:37 i don't really see what's all that strange about it. if you're in bash, we use bash's method, if your'e in zsh, we use zsh's method May 16 20:57:43 since as i said there's no stnadard mechanism May 16 20:57:46 * kergoth shrugs May 16 20:58:02 Smitty_: don't worry about every line, it ends up calling build-setup and that has clear operations on bblayers.conf May 16 21:00:12 indeed May 16 21:00:34 Smitty__: on the repo management side of things, right now yocto doesn't force anything on you. you can use git-subtree or combo-layer to make a monolithic repo like poky does (poky uses combo-layer), or use submodules or repo or myrepos or whatever works best for you. intel has a script that pulls all the layers from the layer index, if you like that idea better. but i'd set that aside for now and focus on getting your layers configured first May 16 21:00:51 deep-dive too far and you'll be staring at the copy-on-write logic in bitbake and that's just one step away from cthulhu May 16 21:01:13 haha, true that May 16 21:01:25 using classes as objects is just twisted May 16 21:04:58 kergoth: I have no idea how I would do any of what you mentioned above. I am currently failing at simply getting meta-example to build into the SDK May 16 21:05:21 edit bblayers.conf, put your layer path in BBLAYERS, do a build May 16 21:05:44 a lot of your questions are more oriented to the long term maintenance of the thing, set that aside and just manually configrue and build for now :) May 16 21:06:28 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 ? May 16 21:07:11 Especially when things like editing a temporary (build directory) file are clearly not a permanent solution, and so a waste of time May 16 21:07:42 i don't understand the question. there are plenty of docs and gettings tarted guides around. most folks would follow those, and go from there May 16 21:07:59 I'm following this one: https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles#Build_an_example_project_on_the_host_for_testing_.28optional.29 May 16 21:08:35 And in it, the recommended method is to edit conf/layers.conf and conf/bbconfig.conf which clearly is not a permanent solution for adding a layer May 16 21:08:54 i don't see how manually doing something once is a waste of time. you're exploring how the system works. automating that process when you need to is trivial May 16 21:11:06 * paulg thinks he's heard that about marriage. May 16 21:11:25 Because it doesn't solve the problem of adding a layer "the right way" it's a temporary solution to a problem I already know I have to solve in a permanent manner. Why not just explain the permanent solution in the docs, why even bother explaining a temporary solution - that doesn't lead to learning how the system works, it's a "hack" to make the system do something that it won't do the next time May 16 21:12:53 You're assuming that everyone learns like you. Not everyone learns bottom-up, plenty of folks learn top-down May 16 21:13:07 further, there *is no standard* for repository management or setup scripts May 16 21:13:17 not every solution satisfies the requirements for every company May 16 21:15:13 Bed time. May 16 21:16:16 Thanks for your time. I honestky appreciate it very much May 16 21:16:41 np, there's obviously a bit of a learning curve, here, any suggestions on how to improve that are appreciated May 16 22:38:58 Does anyone know if its possible to have two kernel-metas? May 16 22:39:41 A parallel kmeta to the origina one May 17 02:03:43 when you build the qemu image where does the created image reside May 17 02:09:34 tmp*/deploy/images/, same as for any machine. see also the docs at yoctoproject.org May 17 02:25:54 can that be configured in the conf file? May 17 02:28:18 see DEPLOY_DIR and DEPLOY_DIR_IMAGE **** ENDING LOGGING AT Wed May 17 03:00:03 2017