**** BEGIN LOGGING AT Fri May 02 02:59:58 2014 May 02 08:13:34 morning all ! May 02 08:14:39 hi May 02 08:49:02 in the OE core class for images (meta/classes/image.bbclass), there is an unnamed python function: python () { ... }. In fact, these unnamed python function seems to exist in many OE classes. When are they called? May 02 08:51:45 anonymous functions May 02 08:52:26 koen: don't drink anonymous coffee ;) May 02 08:56:19 mago_: http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#anonymous-python-functions May 02 09:05:49 thank you! i always seem to lose that up-to-date bitbake manual. Why is the one at http://docs.openembedded.org/bitbake/html/ so old? it's the one I find when googling :) May 02 09:08:38 hmm we should link that one to the new one May 02 09:08:57 we only just updated and published the new one as part of the YP manual set in 1.6 May 02 09:09:38 RP: do you have access to make that link? May 02 09:16:12 i've been trying to get profiling tools working for my image, so I enabled the "tools-profile" IMAGE_FEATURE so that it pulls in meta/recipes-core/packagegroup-core-tools-profile.bb into my image. My rootfs immediately grew by approx. 70 MB, and I was curious exactly what caused the increase. Turns out an uncompressed version of the kernel gets included in /boot/vmlinux. I suppose this image also contains symbol info etc needed for kernel profiling May 02 09:16:12 etc. As an exercise in OE, I tried to locate what part of tools-profile that is responsible for including the /boot/vmlinux file, but was unable to locate it. I cannot see any mention of it in the tools-profile.bb-file. Do any of you have a pointer? May 02 09:20:53 gm May 02 09:22:07 I have the issue (dora release) that PACKAGE_GROUP_mystuff = "some packages" is not picked up, unless I place this in image.bbclass. May 02 09:22:38 ERROR: 'mystuff' in IMAGE_FEATURES is not a valid image feature. May 02 09:23:16 likewise: where else are you trying to put it? May 02 09:24:04 mago_: I presume that's from the "kernel-image" package; the way to track down the link would be to use buildhistory's package dependency graphs May 02 09:24:30 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality May 02 09:24:34 bluelightning: in my packagegroup-leon.bb May 02 09:24:56 likewise: that can't work... it has to be somewhere the image recipe can see it May 02 09:25:14 likewise: so a conf file, or a class that the image recipe inherits May 02 09:25:36 kernel-vmlinux more likely May 02 09:25:48 kernel-image should only have the compressed and stripped version May 02 09:26:08 koen: that's more likely yes; though it may depend on the machine May 02 09:26:28 I can't remember which way around it goes if the machine only supports uncompressed kernels May 02 09:26:29 bluelightning: hmm, so a custom packagegroup with support for IMAGE_FEATURE / PACKAGE_GROUP (now FEATURE_PACKAGES) should always be matched with a conf or clasS? May 02 09:26:34 that's probably not the case here though May 02 09:26:37 yes, our emulated machines at linaro do 'make Image' May 02 09:27:39 likewise: you may be thinking of packagegroup recipes and PACKAGE_GROUP being directly related; they aren't really - they are two separate pieces of functionality that may sometimes be used in conjunction May 02 09:27:58 (hence why I renamed that variable recently) May 02 09:28:15 bluelightning: yes, I am aware of that (since yesterday) May 02 09:28:51 likewise: it's a matter of how PACKAGE_GROUP works; it's a variable, therefore the feature definition must be within the scope of the image you want to use it in May 02 09:28:52 bluelightning: I have packagegroup-mystuff. I then want to do FEATURES_PACKAGES_mystuff = "packagegroup-mystuff May 02 09:32:18 likewise: I think the best place for that would either be your distro config or a custom class that your image recipes always inherit May 02 09:36:07 bluelightning: I am trying the latter approach: mystuff-core-image.bbclass, which in turn inherits from core-image.bbclass May 02 09:37:00 likewise: that's one way, or you could inherit both classes in your image recipes and not have mystuff-core-image.bbclass inherit core-image May 02 09:37:30 bluelightning: probably not :/ May 02 09:37:30 up to you really, I guess your way is slightly less typing for each recipe :) May 02 09:37:59 RP: ok, I'll see if I can find someone else who can May 02 09:39:42 bluelightning: The need for a custom class is not clear from the manual at all: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-FEATURE_PACKAGES May 02 09:40:33 likewise: a custom class isn't strictly required, but variable scope is important for all variables May 02 09:41:00 likewise: I agree we don't document scoping for this and other variables as well as we should, I think there is even a bug open for that May 02 09:53:19 bluelightning: I am porting an existing customer project (danny->dora), this customer had IMAGE_FEATURES set in the mymachine.conf. This worked before, but broke on dora. May 02 09:53:32 lovely May 02 09:53:40 IMAGE features in a MACHINE.conf May 02 09:53:46 indeed... May 02 09:53:53 yuck May 02 09:54:10 So basically I am trying to clean up mess. May 02 09:54:12 well, I guess if you don't stop people from doing that and you barely document that they shouldn't, this is what happens... May 02 09:55:10 I think the strict QA checks are improving, it's just I haven't wrapped my head around how things should be done (TM) in all cases. I now have this really bad example in front of me. May 02 09:55:37 I'm trying to unbreak things that the customer thinks aren't broken in the first place :) May 02 09:55:44 right, understood May 02 09:56:31 I guess what I was saying is it's somewhat understandable when people do things like this even though we might shake our heads at it May 02 09:57:14 as you say over time we've added more checks to try to stop people from falling down holes May 02 09:57:43 bluelightning: agreed, we are learning from this, me included :) May 02 09:57:48 oh man its annoying that the GitPython provided by Ubuntu LTS isn't up-to-date enough to play with buildhistory-diff .. May 02 09:58:04 mago_: virtualenv is your friend ;) May 02 09:58:18 koen: I guess the other approach is IMAGE_FEATURES_append_mymachine = " x y z" in an image recipe. May 02 09:58:54 Basically it's all a way of saying "I want *thi* software on *that* machine", May 02 09:59:01 thi->this May 02 09:59:04 btw, bluelightning, do you have one of those web interfaces to the buildhistory running somewhere? it'd be nice to take a peek, looks interesting May 02 09:59:28 likewise: that's what MACHINE_(ESSENTIAL_)EXTRA_* are designed for really May 02 10:00:20 although those do rely on you using a couple of the core packagegroups May 02 10:00:55 mago_: unfortunately no... I've been asking for it to be set up since I wrote it but it hasn't happened yet May 02 10:04:18 likewise: or a custom image recipe May 02 11:23:55 anyone know why our default config wouldn't set up an ipv6 LL address for eth0? May 02 11:24:03 in theory that should happen automatically... May 02 11:26:12 the kernel is in charge of that, right? May 02 12:17:27 koen: I'm not entirely sure... but supposedly having an LL address is part of the ipv6 spec May 02 12:17:44 ipv6 is definitely enabled, and lo gets an address... May 02 12:21:05 bluelightning: thanks for the help May 02 12:21:30 likewise: np May 02 13:05:29 Hi there. I wonder if anyone has some words of wisdom related to the boot issue that I am having with Texas Instruments board. I have built a yocto-based distro with the instructions given in http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Yocto but the boot log prints out the following message:Starting udev, Missing devtmpfs, which is required for udev to run, Halting... May 02 13:07:31 enable DEVTMPFS in your kernel May 02 13:09:18 JaMa: 312433fe5d8c45df7e78e60599cc7abce0874ab5 is wrong, those are generated files May 02 13:09:43 JaMa: gnome-control-center now classes with packages which also ship those generated files May 02 13:09:46 XorA: I tried to enabled this CONFIG_DEVTMPFS (with and without CONFIG_DEVTMPFS_MOUNT) but it didn't make a difference. May 02 13:10:30 JaMa: do you want me to sent a patch that reverts it or a patch that reverts it and rms those files and do_install_append ? May 02 14:20:00 Hi, my application links to a library using LDFLAGS+=-lfoo, foo library exists as a package as well and builds fine. However, when building my application -lfoo is not applied to LDFLAGS and hence when calling the compilter May 02 14:20:24 I figured out that make -e overwrites the environment, hence LDFLAGS too May 02 14:21:05 How should I solve this issue? Should bitbake set the LDFLAGS environment correctly with -lfoo by itself? May 02 14:21:34 (I set DEPENDS="libfoo", hence the build system knows about this dependency...) May 02 14:36:21 * kroon scratches head why he had to cleansstate a packagegroup recipe in order to get it to build May 02 14:42:14 koen: ah sorry about that, revert+rms would be better May 02 14:42:17 falstaff: it depends on the buildsystem in question. you can set EXTRA_OEMAKE = "", if your buildsystem will obey the vars we need it to obey from the environment (CC, CFLAGS, LDFLAGS, etc). otherwise you could alter that LDFLAGS += line to use 'override LDFLAGS +='. Or better yet ,don't put -l in LDFLAGS. that doens't belong there. generally the convention is to use a separate variable for that, e.g. LIBS May 02 14:42:47 koen: I think that khem sent similar patch for one of gnome-* recipes May 02 14:45:20 kergoth, hm, just launched a devshell, LIBS is not set automatically May 02 14:45:35 that's not an oe/yocto variable May 02 14:45:38 you completely missed my point May 02 14:45:48 kergoth, so I guess the libraries to link has to be in the Makefile May 02 14:45:52 i said *in your buildsystem/makefile*, -l doesn't belong in LDFLAGS May 02 14:45:58 that's where it belongs, yes May 02 14:46:20 we don't want to duplicate knowledge that's in the buildsystem we're calling, unless absolutely necessary May 02 14:47:37 Ok, and usually GNU Makefiles know which libraries to link, but it souldn't be in the LDFLAGS since thats meant for the user of GNU Makefile, right? May 02 14:51:17 The convention is that ldflags holds flags like -O, -L, etc, not what you're linking against. Much as CFLAGS holds -I, -O, etc but not the files you're compiling May 02 14:52:06 http://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html May 02 14:52:11 LDFLAGS May 02 14:52:11 Extra flags to give to compilers when they are supposed to invoke the linker, ‘ld’, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable instead. May 02 14:52:17 from the gnu make manual May 02 14:52:39 it's just convention, of course, you don't have to do this. just one possible approach to resolving your problem May 02 14:55:51 JaMa: iirc the oe-classic class deleted all that stuff May 02 14:56:22 kergoth, thx! using conventions is always a good idea, especiallly when not knowing better :-) May 02 14:58:20 koen: I don't use it in any of my images, I just wanted to get rid of qa :/ May 02 14:59:11 JaMa: np, I was just trying something bigger than console-image in the angstrom release branch May 02 14:59:27 I know I fixed the mime thing properly in OE-classic :) May 02 14:59:58 I wish OE-core daisy had mesa 10.0 :/ May 02 16:30:04 khem: are you gonig to make it IP to OEDAM? May 02 16:33:54 It is hard for me to understand people talking in OEDAM May 02 16:33:57 :-( May 02 16:34:17 otavio we're mostly sitting on #yocto.. just an FYI.. May 02 16:34:19 sorry May 02 16:34:31 but ya, we're chattering.. we'll try to be clearer as we go forward May 02 16:34:33 we grabbed a webcam they had sitting around May 02 18:23:06 ugh, bitbake's hardcoded fetch export vars make me sad May 02 18:23:28 as does the fact that oe-buildenv-internal doesn't respect existing BB_ENV_EXTRAWHITE May 02 18:26:38 hmm May 02 18:31:12 Okay, add nativesdk-ca-certificates to the buildtools tarball, add export of GIT_SSL_CAINFO to the buildtools-tarball env setup script, add GIT_SSL_CAINFO to BB_ENV_EXTRAWHITE, and hack it into being exported in do_fetch without changing signatures (e.g export GIT_SSL_CAINFO, or use of task_level_exports.bbclass), and git clones over https works regardless of where buildtools-tarball is installed or what the host distro is, afaict. May 02 18:31:27 without that, not so much :) May 02 18:31:35 * kergoth does some sanity testing May 02 18:32:43 I should add a subcommand of bb to basically wrap bitbake -S for a task and then dumpsig that out, so you can inspect a signature of a specified task quickly May 02 18:32:47 that'd be handy, i'm thinking May 02 19:08:41 Testing out meta-mingw.. Shouldn't "SDKMACHINE=x86_64-mingw32 bitbake -c populate_sdk my-image" work in theory ? May 02 19:10:03 worked the last time tried it... May 02 19:10:20 *i even... May 02 19:11:13 kroon: only if you add it to BB_ENV_EXTRAWHITE. by default MAACHINE is htere, SDKMACHINE is not May 02 19:11:17 afaict anyway May 02 19:11:29 see poky/scripts/oe-buildenv-internal line 105 May 02 19:14:27 sorry, "worked" meaning without changing SDKMACHINE on the fly... May 02 19:14:52 small screen, tired brain... May 02 19:14:59 kergoth, I have SDKMACHINE there aswell on my system May 02 19:15:22 afaik it should work then, but no idea re: ming specifically :) May 02 19:15:51 I see mingw recipes being processed, but also tasks failing May 02 19:31:03 huh, did a wipe-sysroot, and now it seems to continue.. May 02 19:32:19 I've generated sdk's for linux before, maybe I can't have both at the same time.. May 02 21:35:23 current core-image-sato-sdk-beaglebone booting & running tests on a BBB in LAVA - http://community.validation.linaro.org/scheduler/job/11600 May 02 21:38:05 akbennett, did you just do that? May 02 21:39:03 what is the error? multitasking sucks :) **** ENDING LOGGING AT Sat May 03 02:59:58 2014