**** BEGIN LOGGING AT Mon Jan 13 02:59:59 2014 Jan 13 06:27:36 Hi Jan 13 06:27:54 i'm using sstate-cache Jan 13 06:31:11 but i'm getting error Jan 13 06:31:16 fatal error: stdio.h: No such file or directory Jan 13 06:31:29 after using sstate Jan 13 07:56:15 does anyone know if you can make a INSANE_SKIP = "installed-vs-shipped" apply to only a specific directory? Jan 13 08:12:40 i'm using sstate-cache Jan 13 08:12:48 but i'm getting error Jan 13 08:12:53 fatal error: stdio.h: No such file or directory Jan 13 08:13:00 after using sstate Jan 13 09:42:06 morning all Jan 13 11:24:26 gm Jan 13 12:04:34 How Do I compile kerenel module in yocto? Jan 13 12:18:06 ramose: see the exmaple in meta-skeleton (hello-mod)? Jan 13 13:11:32 How work directory has bee decided? Jan 13 13:12:17 I kept two recipe files in same layer but for one recipe workdirectory is different for other work directory Jan 13 13:13:37 ramose: the 'work' dir, is set like this Jan 13 13:13:37 WORKDIR = "${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}" Jan 13 13:13:58 so it depends on the recipe name (among other things), not the recipe location in the layer tree. Jan 13 13:14:12 ok ndec: Jan 13 13:14:33 for me this MULTIMACH_TARGET_SYS is different is for both recipe Jan 13 13:15:26 ndec: Can you let me know where ${MULTIMACH_TARGET_SYS} this path is set for both recipe files? Jan 13 13:16:02 most variables are defined (at least their default) in meta/conf/bitbake.conf Jan 13 13:16:08 *I kept two recipe files in same layer but for one recipe workdirectory is different for other recipe Jan 13 13:16:14 ok Jan 13 13:16:41 maybe one recipe sets PACKAGE_ARCH? Jan 13 13:16:58 yes, this is 'normal'. you shouldn't worry about where the actual workdir is. OE has good default. Jan 13 13:17:10 indeed Jan 13 13:18:01 ndec : I wanted to set same workdirectory for both my recipe ,how should I go about it Jan 13 13:18:25 well, maybe you need to explain why. this isn't how OE works, really. Jan 13 13:18:48 each 'recipe' is built independently from the others in its own 'sandbox'. Jan 13 13:19:18 recipes that have inter-dependencies communicate through the 'sysroot' which is where header files and libs are exported. Jan 13 13:19:39 ramose: can you please explain more about what it is that you want to do? Jan 13 13:19:53 Ok Jan 13 13:22:54 I have recipe file which is compiling all the kernel modules and now i have writen a new kernel modules which I wanted to compile standalone and which is requires by some other module which resides in workdir other than where Jan 13 13:23:15 receipe for compiling kernel modules resides Jan 13 13:26:44 ndec: for example I have written a kernel module uart_driver.ko which I could compile with the recipe xyz.bb(which comiple all other kernel module) but then it will place the compiled kernel module uart_driver.ko in the workdir where it is not needed. Jan 13 13:26:50 ramose: hmm. each recipe produces a set of 'deliverables' (binaries, modules, header files, libs) that can be exported into the 'sysroot' during the do_install. each recipe is built in its sandbox, and you cannot access another recipe's workdir. Jan 13 13:27:35 the expectation is that the workdir can be 'safely' deleted after the recipe is built. so all you need must be 'installed'. Jan 13 13:29:37 I tried the option of fetching the uart_driver.ko from sysroot path ,i could not provide a standard path in recipe file which need uart_driver.ko and resides in different workdir Jan 13 13:30:48 ndec: Can you tell me how should install as suggested by you Jan 13 13:31:14 ramose: have you checked hello-mod example? Jan 13 13:31:24 yes Jan 13 13:31:47 everything you install in ${D} in the do_install() will end up in the image. Jan 13 13:32:00 if/when you install the generate package Jan 13 13:34:26 i checked the hello-mod in poky/meta-skeleton/recipes-kernel/hello-mod Jan 13 13:36:12 ramose: ok. that recipes inherits module.bbclass which has a default do_install function Jan 13 13:36:21 in meta/classes/module.bbclass Jan 13 13:36:36 ok Jan 13 13:37:46 ndec: shall I inherits same thing in recipe file which requires uart_driver.ko module? Jan 13 13:38:19 ramose: if you build a kernel module, yes you need to inherit the module class. Jan 13 13:39:04 i recommend you have a look at the Yocto documentation as well to become familiar and get started with OE. Jan 13 13:39:30 it is quite a powerful build environment, but it has some learning curve ;-) Jan 13 13:40:23 ndec : What I was thinking is i will provide the source of uart_driver.ko and inherit the module class in the recipe which require my uart modules,right? Jan 13 13:40:59 ramose: if you use a 'standard' kernel module makefile, that should work. Jan 13 13:41:55 Yes ndec: it is indeed powerful/complex build environment and people like you making it easy to this world :) Jan 13 13:41:58 basically, if you do something like hello-mod, it will build your source in the recipe WORKDIR using the do_compile() function in module.bbclass, and it will install the files using do_install(). Jan 13 13:42:09 so, if these functions do what you need, you are good to go. Jan 13 13:42:30 ramose: as i said, the docs are good too, and worth reading! Jan 13 13:43:50 ok ndec ,Thanks Jan 13 14:08:31 hi everyone, is there a non GPLv3 texinfo available in yocto? I found /poky/meta/recipes-extended/texinfo/texinfo_5.1.bb but LICENSE = "GPLv3+" :S Jan 13 14:12:03 brb need to reboot Jan 13 14:12:19 ndec: I tried approach of inherriting modules and provided the uart_driver.ko in recipe file where it is required but when compile the recipe file ,getting error like Jan 13 14:12:20 No targets specified and no makefile found Jan 13 14:15:04 re Jan 13 14:15:36 TuTizz: currently not as texinfo is normally only needed on the host, where the usual GPLv3 concerns don't really apply. do you need texinfo for the target, or are you concerned about gplv3 on the build host? Jan 13 14:18:31 I want to add libsdl-mixer, and my build failed with the following error : "ERROR: texinfo was skipped: incompatible with license GPLv3+". Maybe I should clear my repository and try a fresh build? Jan 13 14:18:34 rburton, Jan 13 14:19:19 "NOTE: Runtime target 'libsdl-mixer' is unbuildable, removing... Jan 13 14:19:19 Missing or unbuildable dependency chain was: ['libsdl-mixer', 'libmikmod', 'texinfo']" Jan 13 14:20:29 TuTizz: that dependency should probably be texinfo-native Jan 13 14:20:34 (in libmikmod) Jan 13 14:26:46 rburton, yes it's building, thanks Jan 13 14:27:20 TuTizz: can you sent the patch please Jan 13 14:28:12 yes omw Jan 13 14:32:53 git commit -s libmikmod_3.1.12.bb with an short explication should be enought doesn't it? Jan 13 14:33:42 follow the format of the other commits but yes, then send to the oe-devel list Jan 13 14:47:24 rburton, I think I need some help. What should I exactly do ( bluelightning tell me to follow this link http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded but I am probably doing it wrongly) ? Create my patch, add it to the git tree, commit it, send an e-mail? Jan 13 14:57:59 Since there is a discussion about sending in patches, what am I supposed to do to get someone to sign off my patch? I am assuming signed-off-by shouldn't be myself. Jan 13 14:59:49 gjohnson: you sign it off yourself first Jan 13 14:59:58 gjohnson: basically, you're signing off that you're OK with contributing the patch and if anyone else's work is included you've obtained authorisation from the other author(s) Jan 13 15:00:24 Ok, that is what I will do then Jan 13 15:01:23 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#how-to-submit-a-change Jan 13 16:14:36 gagi: ping Jan 13 16:14:55 gjohnson: pong ? Jan 13 16:16:05 gagi: I have a question about one of your patches for meta-qt5. In the qt.conf file, why do you use relative paths? Jan 13 16:17:09 gjohnson: Because i don't know the path where you install the SDK on your computer. This way i don't need to change the file afterwards Jan 13 16:18:12 gjohnson: If you take a look at my clone on github, i have also added other meta-sdk files and a script which enables you to build a full fledged working qt5 SDK Jan 13 16:18:31 gjohnson: including a script which can create qtcreator targets for it for you Jan 13 16:19:31 gagi: Yeah, that is what I have been looking at. I will have to try your clone exactly because I used the nativesdk packages in mainline but I can't get it to work with qt creator. Creator just keeps telling me that my qt install isn't valid Jan 13 16:22:11 gagi: What is the difference between meta-sdk and meta-toolchain? Jan 13 16:22:24 gjohnson: if you add "require recipes-qt/meta/meta-sdk-qt5.bb" into your image.bb file it will include all qt libs you are using also in the SDK (didn't tested this) i'm also doing IMAGE_INSTALL += "packagegroup-qt5-essentials" to include all essentials libs Jan 13 16:22:51 gjohnson: I'm sorry, but maybe I'll merge qt5-5.2.0 branch into master before applying your nativesdk-qtbase patch (and it won't be needed with 5.2.0) Jan 13 16:23:05 gjohnson: if you can then please test 5.2.0 version instead Jan 13 16:23:18 JaMa: No problem, I will wait. Jan 13 16:23:40 JaMa: When are you going to be merging in 5.2.0 changes? Jan 13 16:23:50 gjohnson: meta-toolchain is for directly invoking bitbake meta-toolchain-qt5 (which does a do_populate_sdk) the meta-sdk can be used directly for image.bb files and is only executing once you use bitbake image -c populate_sdk Jan 13 16:23:54 maybe today or in next few days Jan 13 16:24:22 gagi: k, that makes sense. Jan 13 16:24:26 depends on how fast world build will finish Jan 13 16:26:31 gjohnson: going home now, feel free to drop me a message on github (or query me here, i'm always on) Jan 13 16:26:43 gagi: K, thanks for the help Jan 13 16:41:10 best way to have a package override the rm_work Jan 13 16:42:06 I am having trouble locting how to override/remove that options Jan 13 16:43:15 WarheadsSE: RM_WORK_EXCLUDE perhaps? Jan 13 16:43:17 AH, i see the exlude now Jan 13 16:43:28 missed seeing that prior. Jan 13 16:43:34 np :) Jan 13 16:45:01 fighting with an openconnect issue, need to make sure I can see the resulting build env Jan 13 16:50:58 Got a compounded issue. Jan 13 16:51:20 basic fault: something is too derp to use the certificates installed in this image Jan 13 16:51:50 And openconnect is always looking for /usr/lib/ssl/cert.pem, which never exists. Jan 13 16:53:03 huh. might need to reconfigure openconnect, assuming the ca-certificates package is sinstalled Jan 13 16:53:21 there are a number of cert things that should really be sorted in yocto today Jan 13 16:53:27 it is installed, they has a layer using 4.07, which of course is out of date Jan 13 16:53:37 we don't pass any configure args to set the ca path or ca bundle path of anything afaict Jan 13 16:53:38 so I am doing 5.02 now, and seeing if it is less derrr Jan 13 16:53:45 * kergoth nods Jan 13 16:53:56 checking For location of system CA trust file... /etc/ssl/certs/ca-certificates.crt Jan 13 16:53:59 yeah.. Jan 13 16:54:19 which layer is the existin openconnect package? Jan 13 16:54:29 This is conglomerated pile layer from in-house.. Jan 13 16:56:39 that just feels like host pollution. Jan 13 16:56:42 i'd check the layer index. you can search for recipes Jan 13 16:57:34 lunch, bbiab Jan 13 16:57:36 yeah, curl right now autosets the ca / ca bundle path by poking at host files, i haven't gotten around to pushing our current workaround — https://github.com/MentorEmbedded/meta-mentor/blob/master/recipes/curl/curl_7.33.0.bbappend#L4-L7 Jan 13 16:58:03 we had to do this in order to get the certificates into the nativesdk curl package, so the nativesdk git could actually clone from https repositories when using the buildtools-tarball, which isn't hte case otherwise Jan 13 16:58:28 its on my to-push list, but i'm guessing there may be other recipes that need such paths, and we may want to add a variable to hold the path rather than hardcoding it this way Jan 13 17:57:01 moin Jan 13 18:12:36 * WarheadsSE back from nom Jan 13 18:14:11 kergoth: 404 Jan 13 18:16:26 kergoth: btw, no openconnect recipe4s Jan 13 18:18:18 although it looks like the updated ca-certificates should have the PEM files which will help! Jan 13 18:23:49 Hello, is there any information for yocto Build Appliance on VirtualBox on linux as of for VMware on Windows 7 ( https://www.yoctoproject.org/documentation/build-appliance-manual ) I'm planning in working with Intel x86-64 based PCs and devices (genericx86-64) Jan 13 19:09:51 noob ? what package enables USB to auto connect a keyboard or notify on the connection of a jumpdrive etc... Jan 13 19:11:42 at most, that should be kernel modules and udev Jan 13 19:13:14 what options are enabled in your distro features? Jan 13 19:13:20 I am using the am335x-evm machine and meta-ti layer which i thought configures most of that. Jan 13 19:13:32 you might need usbhost Jan 13 19:13:45 I am just building the core-image basic from the poky distro Jan 13 19:14:02 do a bitbake -e and grep DISTRO_FEATURES Jan 13 19:14:50 j6V6t: which board do you have? Jan 13 19:15:56 am335x-SK the purple board with 4.3inch display Jan 13 19:16:09 which is the am335x-evmsk.dtb Jan 13 19:18:12 j6V6t: hmm, it should work... can you send an email to meta-ti@yoctoproject.org so I won't forget to look into it? Jan 13 19:18:40 sure, thanks Jan 13 19:50:24 wheee http://pastie.org/8630432 Jan 13 19:50:47 and yes, this is in the bastard.. pulled in the newer recipe to our layer, which caused this Jan 13 19:51:52 kergoth any thoughts appreciated. Jan 13 20:02:26 have to manuall -c fetch / -c patch Jan 13 20:45:11 and.. yeah.. no progress. Jan 13 21:15:54 I have a recipe that contacts a remote server for package signing purposes. Typically, it would use my passwordless ssh credentials to contact the server, but it seems bitbake doesn't pass that though to the recipe -- it asks for my password mid-stream. Is there some good way to get it to pass throught that information? Jan 13 21:18:20 I tried adding my SSH* variables to BB_ENV_EXTRAWHITE Jan 13 21:29:26 didn't seem to have any affect Jan 13 21:33:34 Garibaldi|work: I have bitbake fetch recipes over ssh for git quite often, using my ssh agent Jan 13 21:37:08 kergoth: hum, this isn't really a fetch. I call a script that computes a checksum and uses ssh to run a command on a remote server to get a signed version of the checksum. When I run the script manually, it works as expected. When I run the script from my recipe, it prompts me for my password. Jan 13 21:37:38 It's possible I'm doing something else wrong Jan 13 21:37:42 but I don't know what Jan 13 21:42:53 yes, i confirm that i can fetch git over ssh with password less config (.ssh/config + key). however the do_fetch might export variables that might not be exported in other tasks. Jan 13 22:09:14 ndec: yes, looking at bitbake/lib/bb/fetch2/__init__.py, runfetchcmd seems to explicitly handle things like SSH_AUTH_SOCK SSH_AGENT_PID, etc. Jan 13 22:10:16 my activity isn't at fetch time, I'm signing and artifact that will get included in the image. Jan 13 22:20:11 I've verified that those variables are not set when I call the script in my recipe Jan 13 22:20:36 is there some mechanism to ask bitbake to not strip variables from the environment? I thought the EXTRAWHITE was intended for that? Jan 13 22:20:59 thats what BB_ENV_EXTRAWHITE is for, yes Jan 13 22:22:37 so I have BB_ENV_EXTRAWHITE set to "... SSH_AGENT_PID SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_ASKPASS SSH_CONNECTION". My shell has those variables exported (and BB_ENV_EXTRAWHITE), but those SSH_ variables are not in my environment within the recipe Jan 13 22:23:01 use bitbake -e to examine the global config metadata which flows into all recipes Jan 13 22:23:07 make sure thingsa re set to what you think they're set to Jan 13 22:23:34 whenever something seems inexplicable, it's almost always a mismatch between my assumptions and reality, and inspection tools like bitbake -e are invaluable for that :) Jan 13 22:24:05 good idea, will do Jan 13 22:26:32 so bitbake -e looks good. EXTRAWHITE has the variables, the variables are there with the appropriate values Jan 13 22:27:03 maybe Jan 13 22:27:37 yep, looks good Jan 13 22:27:46 but if I do an 'env' in the recipe, I don't see them Jan 13 22:27:55 (e.g., env > /tmp/env) Jan 13 22:30:47 for instance, in 'bitbake -e ' I see: # $SSH_AGENT_PID # from env data.py:174 [inheritFromOS] # "28719 SSH_AGENT_PID="28719" Jan 13 22:31:48 it's possible the vars got set in the metadata, but not *exported* from the metadata Jan 13 22:32:04 vars in the metadata that aren't flagged as export don't end up in the spawned shell scripts for the shell tasks Jan 13 22:32:16 ahh.. Jan 13 22:32:19 try adding 'export SSH_AGENT_PID' and 'export SSH_AUTH_SOCK' to local.conf Jan 13 22:32:23 to see if that's what's happening Jan 13 22:32:32 ok, I'll give that a shot Jan 13 22:32:49 iirc bitbake was supposed to re-export the vars it got from the env, but it could be it doesn't in whatever bitbake version you're using Jan 13 22:33:35 yeah, that makes sense Jan 13 22:42:12 Garibaldi|work: i think putting the vars in EXTRAWHITE should work, but in cases where i do that, i also export them in the jenkins job first Jan 13 22:42:39 in that case they get passed as expected Jan 13 22:43:30 mr_science: that's what I expected, but it didn't do what I wanted. I exported them in my shell, I added them to EXTRAWHITE, but they didn't make it into my recipe Jan 13 22:43:35 so export FOO="bar" and then adding FOO to BB_ENV_EXTRAWHITE works in classic Jan 13 22:44:06 I should mention I'm still using Yocto 1.3, just in case the behavior has changed since Jan 13 22:44:27 i'm talking oe-classic and bitbake 1.10 Jan 13 22:44:40 ah, ok Jan 13 22:44:48 I'm at 1.19.1 Jan 13 22:45:02 we'll see if adding the export in local.conf helps Jan 13 22:45:09 in poky master i just set them in local.conf and use them Jan 13 22:45:22 yeah, but these are dynamic Jan 13 22:46:02 don't think i've tried that with poky yet Jan 13 22:48:00 adding the exports to local.conf triggered a rebuild of everything; we'll see if it works once that's done Jan 13 22:48:27 downside to 'export' of any shell var of that sort, it affects the checksum of every shell task Jan 13 22:48:36 because it not only puts it in the env of shell tasks, but also exports it from them Jan 13 22:48:46 which means we can't know which exported vars are used by what the task runs, and which aren't Jan 13 22:49:00 yeah, that makes sense too Jan 13 22:49:02 ideally, we'd have task level export control Jan 13 22:49:09 e.g. do_foo[exports] += "CC CFLAGS" Jan 13 22:49:13 but we don't have that yet.. Jan 13 22:49:15 yeah Jan 13 22:50:23 its possible to rig it manually in particular cases by using python in the recipe, e.g. create a python task which runs your shell task, and which exports particular vars before running it, or somesuch, if it's worth the bother Jan 13 22:54:47 yeah, and these SSH_ variables change frequently :-/ Jan 13 22:55:29 kergoth: do you know of an example of the manual rigging I can look at? Jan 13 23:18:07 Garibaldi|work: try https://gist.github.com/kergoth/8409969 Jan 13 23:18:20 Garibaldi|work: just threw it together, so it's had only limited testing, but it seems to work Jan 13 23:19:03 I'll take a look -- thanks Jan 13 23:19:29 be warned the use of bitbake internal variables isn't really kosher, the alternative is to use the commented out line instead, where there's a var with the tasks you want to support task level exports, rather than operating against all added tasks Jan 13 23:19:36 does work, though Jan 13 23:20:12 * kergoth thinks about experimenting with reworking the base classes and bitbake.conf to reduce the global exports and convert them to task level exports where possible Jan 13 23:21:17 Garibaldi|work: figured it might be cleaner to do something generally useful rather than a single hardcoded example, but i can throw one of those together too if you end up preferring that approach Jan 13 23:21:24 * kergoth thinks this is relatively clean Jan 13 23:21:41 kergoth: so for the commented out version, in local.conf I would have have TASKS_WITH_EXPORTS="my_recipe_name" Jan 13 23:21:49 nope, its tasks Jan 13 23:21:50 and the resut would be the same Jan 13 23:22:01 in the recipe, you'd add TASKS_WITH_EXPORTS += "do_yourtask" Jan 13 23:22:08 ah, ok Jan 13 23:22:09 then do_yourtask[exports] += "... the ssh var names ..." Jan 13 23:22:17 along with the inherit, if you dont inherit it globally Jan 13 23:22:28 understood, thanks Jan 13 23:22:33 I appreciate you putting that together Jan 13 23:23:23 updated the gist to show the var use in the .inc alongside the rest Jan 13 23:23:43 i'd already started doing it before you asked, i figured i'd see how much work it'd be to support an exports flag in a generic way Jan 13 23:23:47 turns out, not much work Jan 13 23:23:52 :) Jan 13 23:27:11 I'm guessing __BBDELTASKS is also a internal variable Jan 13 23:28:09 is there a kosher way of doing that too? Jan 13 23:31:29 its only needed when using __BBTASKS Jan 13 23:31:38 to support the built in deltask directive Jan 13 23:31:45 ah, of course Jan 13 23:31:48 anonymous python functions are run before that processing happens Jan 13 23:31:55 so the deleted tasks will still bein __BBTASKS at that time Jan 13 23:33:05 if you reload the gist, that's what it looks like without the bitbake-internal bits Jan 13 23:34:12 thanks Jan 13 23:46:27 Garibaldi|work: posted an improved version which supports both methods, with the automatic task selection only used if you opt-in to it: https://gist.github.com/kergoth/8410245 Jan 13 23:47:07 * kergoth goes to grab food Jan 13 23:47:16 kergoth: I'll give it a try -- thanks again Jan 13 23:47:21 enjoy :-) **** ENDING LOGGING AT Tue Jan 14 03:00:00 2014