**** BEGIN LOGGING AT Thu Jul 09 02:59:58 2015 Jul 09 05:15:20 Hello Jul 09 05:17:54 I'd like to add the vmlinux as well as the uImage to my systarget directory (usr/src/kernel). How can I achive that both images are deployed in the staging area? Jul 09 05:54:09 hi guys Jul 09 05:54:42 can anyone tell me how i can have several language keyboards in my image ? Jul 09 05:55:04 i'm using matchbox, and i'd like to add french, german keyboards plz Jul 09 06:12:15 drix: the LINGUAS variable should be your keyword to look it up, i think Jul 09 06:25:41 LetoThe2nd: I put IMAGE_LINGUAS = "de-de fr-fr en-us" but it's not working Jul 09 06:27:40 drix: sry, no idea tgen Jul 09 06:28:43 actually, when i'm in a shell without X, it's working, i can do a loadkeys fr or loadkeys de Jul 09 06:29:04 but when i'm under matchbox, no. Jul 09 07:03:10 good morning Jul 09 08:24:50 morning all Jul 09 08:25:13 * rink_ kicks co-workers Jul 09 08:25:20 "Why not patch linux so that ext2 is case-insensitive" Jul 09 08:25:32 great idea, let's break everything else that depends on it Jul 09 08:26:39 rink_: if that's really the desired functionality, just switch to a different filesystem that is case-insensitive Jul 09 08:27:21 We used to have FAT Jul 09 08:27:24 but it performs terrible Jul 09 08:27:31 (we have a few 200MB+ files) Jul 09 08:27:35 where we seek a lot Jul 09 08:34:47 <[Sno]> moin bluelightning Jul 09 08:40:33 hi [Sno] Jul 09 08:44:24 hi. i pulled the latest changes from fido today, and now i seem to have a problem with all python recipes: they fail with error message: make: *** No rule to make target `clean'. Stop. Jul 09 08:44:26 any ideas? Jul 09 08:45:10 <[Sno]> switch to perl ^^ Jul 09 08:45:36 i'd rather switch to assembly Jul 09 08:45:44 <[Sno]> even better Jul 09 08:48:17 morning Jul 09 08:49:19 Does anyone know, if the build configuration, the one which is printed when you start a bitbake, is stored somwhere? Jul 09 08:50:08 DatGizmo: it is if you enable buildhistory Jul 09 08:50:17 DatGizmo: it's also possible to write that sort of thing into the image with a little extra configuration, if that's where you want it Jul 09 08:51:09 bluelightning: yhea, I want to store it in the image. Jul 09 08:51:14 <[Sno]> ionte: but on topic - I rebased this morning either and had no issues Jul 09 08:51:33 <[Sno]> when did you updated last time? Jul 09 08:52:03 [Sno]: ok.. i tried just now again, but there were no new changes Jul 09 08:52:52 btw, the failing python recipes are my custom recipes, but they are very simple and looks more or less like the other included.. will have to check if the included python recipes has changed lately... Jul 09 08:54:02 DatGizmo: ok - at least as of 1.8 we have meta/classes/image-buildinfo.bbclass Jul 09 08:54:15 there are some comments at the top of it mentioning how to use it Jul 09 08:55:43 bluelightning: thanks, I will have a look Jul 09 08:58:19 <[Sno]> RP: force pushed wrapper fix (that removed the discussion) Jul 09 08:59:19 well, can't really see any difference when comparing my custom python package with for example python-git Jul 09 08:59:24 they both use setuptools Jul 09 09:04:07 ==4947== Process terminating with default action of signal 11 (SIGSEGV) Jul 09 09:04:09 ==4947== Access not within mapped region at address 0xC0 Jul 09 09:04:11 ==4947== at 0x4E7B24D: vfprintf (vfprintf.c:1278) Jul 09 09:04:13 ==4947== by 0x4E85D46: fprintf (fprintf.c:32) Jul 09 09:04:15 ==4947== by 0x4025DA: main (log.c:384) Jul 09 09:04:17 oups Jul 09 09:04:19 wrong chan, sorry Jul 09 09:14:20 * [Sno] doesn't understand enough of py-toolchain to help there Jul 09 09:16:40 solved my problem. "bitbake -c clean my-custom-python-recipe" Jul 09 09:17:32 <[Sno]> hehe Jul 09 09:18:34 <[Sno]> bluelightning: I mailed RP and tim orling, but forgot you - if you want to take a look on perl/cpan fixes for fido to get started doing more cpan modules packaging ... see https://github.com/rehsack/poky (and https://github.com/rehsack/meta-cpan) Jul 09 09:18:56 <[Sno]> AFAIK you were kind-of interested in those stuff ... Jul 09 09:19:54 [Sno]: thanks... yes, it's something I'd very much like to see sorted out from a "completionist" perspective, the problem I have though is I'm not a perl programmer myself Jul 09 09:20:22 [Sno]: we do need someone to figure out how to move forward though, probably based on what you've been doing Jul 09 09:21:12 <[Sno]> when I can support somewhere, just bug me Jul 09 09:21:50 <[Sno]> when the things I've done in my repo is sane, I intend to update the perl to 5.20.2 (bug-fix release) Jul 09 09:22:01 <[Sno]> and for master maybe soon to 5.22... Jul 09 09:40:23 bluelightning: thanks again, the class gives us everything we need :) Jul 09 09:40:38 DatGizmo: no problem :) Jul 09 09:48:00 so debian has a very well written analysis of why libav should be replaced with ffmpeg Jul 09 09:50:06 rburton: yep, I saw that yesterday, we discussed it very briefly in #oe Jul 09 09:50:46 rburton: you're still not in that channel ;) Jul 09 09:51:33 this time i'll add it to adium's autojoin :) Jul 09 09:52:25 bluelightning: was there a conclusion? Jul 09 09:52:51 rburton: not really no, other than that Debian is just one of many that seem to be making the switch back Jul 09 09:53:08 the rationale were certainly convincing Jul 09 09:53:19 actually has security fixes, for example Jul 09 09:53:33 indeed... we should consider moving back ourselves Jul 09 09:54:00 hmm, I'm the maintainer of the libav recipe aren't I Jul 09 09:54:02 that's enough reason, IMHO Jul 09 09:54:07 perhaps I should be sending out an RFC Jul 09 10:24:41 RFC sent to oe-core & oe-devel lists Jul 09 10:29:02 ah thanks for looking at gst-libav - i was about to do that :) Jul 09 10:31:06 I didn't find it immediately... in the end I had to look through their commit logs Jul 09 11:19:39 [Sno]: ok, the "useless" comment on the wrappers just caught my eye. Harder for me to comment on the perl bits, its really not by area of expertise Jul 09 11:56:04 meta-mono here? anyone? can not build for arm64 Jul 09 12:09:39 I want to build the yocto image for the intel edison (edison-src-ww18-15.tgz) and I hope I can get some help here. When I run bitbake edison-image I am getting "ERROR: Error parsing configuration files", details: http://pastebin.com/mXy0D1wM Jul 09 12:10:19 I just want to build a recent yocto for this board Jul 09 12:23:11 I remember Intel having their own folder architecture and you you would have to use their Makefile Jul 09 12:28:22 Minipada: I follued their guide: http://download.intel.com/support/edison/sb/edisonbsp_ug_331188007.pdf Jul 09 12:28:43 but I am using ubuntu 14.04 and not ubuntu 12.04 Jul 09 12:29:37 <[Sno]> RP: take a plain perl and do a "perl -MData:Dumper -le 'print Dumper \@INC'" Jul 09 12:29:56 <[Sno]> Data::Dumper Jul 09 12:30:30 <[Sno]> then you see what I mean with "search order was wrong" Jul 09 12:33:39 ah now I am not getting this error many more, I did not specify the dl_dir and the sstate_dir before Jul 09 12:35:35 [Sno]: I don't doubt it was wrong! Jul 09 12:38:22 <[Sno]> RP: what do you need to know? Jul 09 12:38:37 <[Sno]> or shall I just send a mail to (which ML?) Jul 09 12:44:20 [Sno]: proposing the OE-Core patches on the openembedded-core mailing list would be a good step Jul 09 12:45:57 <[Sno]> will do, during next big compile break Jul 09 13:45:08 bluelightning: you around, hi? Jul 09 14:02:09 lpapp: hi, yes Jul 09 14:02:59 bluelightning: could you help me with the SDK truncation that we started discussing several weeks ago? The generated SDK is not truncated and I cannot get sdk-files-in.txt either, or however the file is called. Jul 09 14:03:04 I am not sure what to do next. Jul 09 14:03:29 that file is not generated even though bitbake -e says that sdk is enabled in the BUILD_HISTORY variable. Jul 09 14:03:37 the* Jul 09 14:03:51 quite a lot has happened over the last few weeks, I don't recall the issue - can you explain or point me to a log of the discussion? Jul 09 14:04:15 Hello! I have a question concerning the bitbake-pserv-tool. I do not quite understand its usage. I understand its purpose but not how I can use the service in my recipes. Can anyone help me with that? Jul 09 14:05:23 bluelightning: sure, so that our image contains some binaries that we wrote, but they are needless for our SDK users and we would also like to hide those from as a matter of preference, so that the SDK has to be truncated. I was using the variable that you suggested. I think I even created a report for documenting that. Jul 09 14:05:42 but the usage is not a problem at this point. Jul 09 14:05:42 ah ok right yes Jul 09 14:06:00 the alternative approach was, as a fallback, to have two separate image files. Jul 09 14:06:14 but first I would like to see whether I can get it working with one image recipe. Jul 09 14:07:13 I also read https://wiki.yoctoproject.org/wiki/PR_Service , but there's nowhere documented how to actually use it in a recipe :/ Jul 09 14:07:52 zwerch: it should be that you enable it and then it auto-increments PR for you, there shouldn't be any changes required to individual recipes Jul 09 14:08:42 zwerch: the idea is changing material parts of the recipes changes the signatures of the tasks, and the PR value increments automatically as a result Jul 09 14:09:04 bluelightning: so it is the PACKAGE_EXCLUDE_COMPLEMENTARY variable. Jul 09 14:09:28 but currently it worries me more that I cannot get the build history for the SDK, at least the files-in-sdk.txt is not generated for some reason. Jul 09 14:09:41 we use 1.6.2. Jul 09 14:10:13 lpapp: maybe the buildhistory class in daisy doesn't support getting the SDK contents Jul 09 14:10:30 I think I got that part, so, if I now build a package and rebuild the index, opkg automatically gets that there's an update for a specific package and I do not need to manually increment PV or PR? Jul 09 14:12:39 zwerch: correct Jul 09 14:13:05 bluelightning: thanks a lot! Jul 09 14:15:12 bluelightning: strange that bitbake -e shows the SDK in the build history variable, then. Jul 09 14:16:44 lpapp: ah right, turns out that it did Jul 09 14:18:22 I don't immediately know how to explain why it wouldn't be working, but the way to debug that would be as normal - throw some echo statements in, look at log.do_rootfs, etc. Jul 09 14:18:34 well, log.do_populate_sdk Jul 09 14:20:07 hmm, okay, thanks. Jul 09 14:55:05 I have included these in my local.conf Jul 09 14:55:26 but bitbake iojs still bombs Jul 09 15:04:42 bluelightning: that is odd. I have files-in-sdk.txt generated now... I wonder what could have gone different, but I am happy about that one, at least. Jul 09 15:08:17 bluelightning: bitbake -e -c populate_sdk foo-core-image | grep ^PACKAGE_EXCLUDE_COMPLEMENTARY returns PACKAGE_EXCLUDE_COMPLEMENTARY="foo|bar|baz", yet I can see the content of foo, bar and baz in files-in-sdk.txt. Jul 09 15:10:06 lpapp: are foo bar or baz dependencies of anything else that is going into the SDK ? Jul 09 15:11:24 not intentionally, at least. Jul 09 15:11:39 hmm. Jul 09 15:13:42 it may well be that we need to add an explicit SDK_EXCLUDE or somehting like that to handle this, and that would just error in that case Jul 09 15:16:39 time to check ./tmp/work/foo-linux-gnueabi/foo-core-image/1.0-r0/temp/log.do_populate_sdk Jul 09 15:16:40 bluelightning, did you guys make any progress on scipy? Jul 09 15:18:27 bluelightning: yeah, the udesired packages appear in log.do_populate_sdk, too :( Jul 09 15:18:30 undesired* Jul 09 15:18:43 perhaps it is time to look into the implementation of that variable now. Jul 09 15:18:56 it may not have been complete in daisy or so. Jul 09 15:23:32 bluelightning: so I ought to print out the exclude variable and perhaps something from the cmd? Jul 09 15:24:10 lpapp: PACKAGE_EXCLUDE_COMPLEMENTARY is not intended to outright exclude any package from the SDK, it's specifically for excluding a package from complementary package processing Jul 09 15:27:46 bluelightning: ok, not sure what that means. Jul 09 15:29:05 lpapp: what I'm saying is, there are cases for which this will not remove something from the SDK, and that's not a bug Jul 09 15:29:29 are there any other cases than dependencies? Jul 09 15:29:42 if we want something that definitely will exclude something or error if it can't, that will need to be a separate variable Jul 09 15:30:34 explicit mention in TOOLCHAIN_TARGET_TASK would bypass it as well Jul 09 15:30:41 as far as I can tell, looking at the recipe as well as recalling what I intended, nothing depends on foo, bar and baz. Jul 09 15:31:35 right, that will be it, I think. Jul 09 15:31:42 our package occurs in that variable. Jul 09 15:31:48 packagegroup* Jul 09 15:32:17 we have one packagegroup on top of the Yocto core packagroup and we put all the software into that. Jul 09 15:32:53 so it is better to have two different packagegroups? Jul 09 15:32:58 min + extra alike? Jul 09 15:35:51 but that might not help with the image creation. I would not know. Perhaps, we do need this SDK_EXCLUDE? Jul 09 15:38:26 bluelightning: ^ Jul 09 15:48:59 lpapp: the way the SDK is supposed to work is other than any extras, the contents of the target portion gets there from the image, so I wouldn't have expected those packagegroups to need to be mentioned in TOOLCHAIN_TARGET_TASK Jul 09 15:50:50 bluelightning: hmm, I see. What do you suggest for me then? Jul 09 15:51:26 well, if you really are putting those packagegroups in that variable the question is do you really need to if they are already in the image? Jul 09 15:55:13 bluelightning: I believe that variable is populated by Yocto, not by my layer. Jul 09 15:55:31 at least, I cannot find any direct reference to it in my layer. Jul 09 16:22:03 <[Sno]> RP: mail sent ;) Jul 09 16:29:32 bluelightning: is there a way that I can let yocto remove that from the task variable? Jul 09 16:35:29 lpapp: hmm, so you're right it adds the value of PACKAGE_INSTALL by default Jul 09 16:35:44 so PACKAGE_EXCLUDE_COMPLEMENTARY could never have worked Jul 09 16:35:56 sorry for leading you down the wrong path Jul 09 16:36:17 hmm, so what is this variable addressing? Jul 09 16:36:52 so it seems to be my option for today is two different image recipes? Jul 09 16:37:24 it would be nice to get this SDK_EXCLUDE implemented in the future :-) Jul 09 16:58:55 bluelightning: shall I start some discussion about this SDK_EXCLUDE idea on the mailing list or just open a ticket for it on bugzilla? Jul 09 16:59:10 I would not have much time to follow it up though. Jul 09 16:59:22 lpapp: probably bugzilla I guess Jul 09 17:00:12 bbl Jul 09 17:42:29 I'm trying to add mono recipes to existing yocto image. I checked out the meta-mono git recipe and added the packages to my image .inc file. However when I build, mono install errors out trying to copy files from ..../usr/lib64/.. when the files it needs are in ..../usr/lib/.. I tried to follow the code and saw that this path depends on a variable called "sysconfdir". Can someone point me to where it is set, so I can change it to point at the right Jul 09 17:42:29 path? Jul 09 18:13:33 hi team question .. if I get configure: exit 0 in do_configure .. but I still have this error: http://pastebin.com/KZPU4vHK Jul 09 18:14:01 is because yocto is still running ./configure ot autoreconf Jul 09 18:14:04 ? Jul 09 18:18:50 ambrosius: i think you've mixed up some paths. sysconfdir is /etc Jul 09 18:19:20 ya.. just figured that out.. Its $libdir that is getting me lib64 Jul 09 18:19:25 I need it to be libn Jul 09 18:19:28 *lib Jul 09 18:20:08 Any advise as to where I can do that? Jul 09 18:20:17 sounds like its recipe isn't properly obeying our paths Jul 09 18:21:43 ya I'm trying to figure out where the recipe might be overriding my path Jul 09 19:10:22 Has anyone played with using BBCLASSEXTEND + BBEXTENDCUR/BBEXTENDVARIANT to create configuration variants on a per-recipe basis? I'm picturing e.g. a adding named-config:minimal to BBCLASSEXTEND in busybox, and busybox-minimal would be created with PROVIDES += busybox and a negative default preference, and then could drop in a defconfig in the busybox-minimal dir in FILESPATH Jul 09 19:16:45 hi , do we have a wiki to build yocto on galileo ? Jul 09 20:50:04 gah, why do i keep getting bitbake parse hangs at 99% Jul 09 20:51:46 i hope it's just something wrong with the VM Jul 09 20:51:59 kergoth: how much ram do you have Jul 09 20:53:01 hmm, looks like only 4gb in those VMs Jul 09 20:53:08 i never hit this until recently, though Jul 09 20:53:49 are you using OE-Core only ? Jul 09 20:53:53 or mix of layers Jul 09 20:53:57 mix of layers Jul 09 20:54:13 seemingly random Jul 09 20:56:54 kergoth: I have seen these in past and I created new sandbox and it use to go away Jul 09 20:56:59 hmm Jul 09 20:57:06 never got to bottom of it Jul 09 20:58:27 khem`: When are you gonna update the opencv to 3.0? :) Jul 09 20:59:03 ulf`: I think we could but there are dependencies Jul 09 20:59:03 on 2.x Jul 09 20:59:40 http://www.freedesktop.org/wiki/Software/Beignet/ doesn't work with 2.x Jul 09 21:04:35 hmm Jul 09 21:06:40 opencv 3.0 uses transparent opencl Jul 09 21:06:55 meaning you don't have to do anything special if you have hardware that supports opencl Jul 09 21:07:21 oops, can't use ${PN} in FILESEXTRAPATHS with := when using variants/extends, since that hasn't been applied at that point. need just thisdir immediately expanded, not PN Jul 09 21:07:51 i don't think 3.0 has any new dependencies that 2.4 doesn't already have. Jul 09 21:08:42 there are some api changes that can break 2.4 apps though Jul 09 21:09:01 but having a opencv_3.0.bb should be very doable Jul 09 21:16:20 kergoth: use BPN Jul 09 21:16:40 it's the opposite problem. PN is immediately expanded before the variant is added Jul 09 21:16:43 tripzero: yes I think with default preference to -1 we can accept Jul 09 21:16:47 so i get the base one, not the variant one Jul 09 21:17:03 tripzero: or if they both can live together with opencv3 Jul 09 21:17:18 the bbclassextend class is what adjusts PN iwth the variant, but thats after the recipe is parsed Jul 09 21:17:21 so at parse time it hasn't been done yet Jul 09 21:17:35 just had to shift the path into a separate var and assemble it in parts so i could immdiately expand THISDIR but not PN Jul 09 21:17:37 kergoth: yes, so are you getting into PN as folder for patches/files ? Jul 09 21:17:58 e.g. it's looking in autoconf, not nativesdk-autoconf, even though PN is the latter Jul 09 21:18:05 wonder why PN and not BPN Jul 09 21:18:15 i'm *trying* to override something for the variant Jul 09 21:18:20 i don't want it to apply to them all in this case Jul 09 21:18:28 so BPN is exactly what i don't want, but that ends up being what it's using :) Jul 09 21:18:32 (indirectly) Jul 09 21:18:38 hmm ok then use class override Jul 09 21:18:52 hmm, true, didn't think about using that with FILESEXTRAPATHS Jul 09 21:18:55 is it a file or patch Jul 09 21:19:28 defconfig in this case Jul 09 21:19:35 * kergoth tries that Jul 09 21:20:13 of course, override doesn't work either, since i still have to use := to force expansion of thisdir Jul 09 21:20:30 still worth doing, but doesn't prevent the problem: i can't force immediate expansion of PN at parse time or it won't be for the variant Jul 09 21:20:54 not a big deal, just minor annoyance Jul 09 21:21:24 I'm toying around with a bbclass that lets you create variants of recipe which differ only in configuration, using the same mechanism as multilibs Jul 09 21:21:40 echo 'BBCLASSEXTEND += "named-config:minimal"' >>busybox_%.bbappend Jul 09 21:38:43 wow, this is weird, my path is first in FILESEXTRAPATHS, that path contains defconfig, file://defconfig is in SRC_URI, but it's still pulling the defconfig out of oe-core instead Jul 09 21:38:47 hmm Jul 09 21:52:28 kergoth just call defconfig with differrent name Jul 09 21:52:36 e.g. defconfig-foo Jul 09 21:52:40 and use overrides Jul 09 22:12:19 yeah, could do that, worst case. am going to try to figure out *why* it's misbehaving, though.. hmm Jul 10 00:15:34 * nerdboy about to fire up new build env on refurbished laptop Jul 10 00:16:36 and these cheap/new "hybrid" drives are *fast* **** ENDING LOGGING AT Fri Jul 10 02:59:58 2015