**** BEGIN LOGGING AT Wed Jul 16 02:59:59 2014 Jul 16 05:07:41 I have just download/installed Yocto and Intel BSP(for Mohonpeak), modified the conf files, then there's a error when I try first build: IOError: file /media/eddylai/datahd/poky/meta-intel/meta-isg/conf/layer.conf not found Jul 16 05:07:41 ERROR: Unable to parse /media/eddylai/datahd/poky/meta-intel/meta-isg/conf/layer.conf: file /media/eddylai/datahd/poky/meta-intel/meta-isg/conf/layer.conf not found Jul 16 05:08:53 checked there's no conf/layer.conf included in the original downloaded BSP Jul 16 06:56:50 Is there always a config.log generated when building something with oe? Jul 16 07:01:32 good morning Jul 16 07:17:03 Good morning mckoan Jul 16 07:36:08 morning all Jul 16 07:36:44 möinmöin (UGT) Jul 16 08:01:31 hi Eddy_Lai, bluelightning, Letothe2nd, all Jul 16 12:57:53 I have a module with some ioctls I want to export to userspace, how can I do it? I tried header-y on Kbuild of module but got no effect.. my recipe has no do_install task implemented, should it? Jul 16 13:29:33 RP: Is it possible to hanlde the alsa-tools patch? it is making some directfb-based images to fail to build Jul 16 13:33:22 otavio: not really Jul 16 13:33:42 RP: ? Jul 16 13:34:39 otavio: your patches are not special, we have a backlog at the moment and I'm doing my best to work through them Jul 16 13:36:15 RP: I hope you keep following the process Jul 16 13:36:26 otavio: which process? Jul 16 13:36:29 RP: I didn't ask for you to push it immediatly Jul 16 13:36:44 otavio: what are you asking then? Jul 16 13:37:25 RP: I asked if you could pick this one for next review as it is a trivial bugfix patch and could go with the others for testing Jul 16 13:40:21 otavio: I will do my best. There are several other "trivial" patches I'm trying to untangle from build failures atm :( Jul 16 13:41:07 RP: I am in same boat. Still fixing issues due the package_qa patch in my side Jul 16 13:41:25 otavio: have you any ideas why we intermittantly see: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/164/steps/BuildImages/logs/stdio and https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/166/steps/BuildImages/logs/stdio ? Jul 16 13:41:42 otavio: appears to be intermittent, I don't know where its coming from :/ Jul 16 13:42:41 RP: qt4 ... Jul 16 13:42:53 RP: No Jul 16 13:43:31 otavio: xf86-video-imxfb as well Jul 16 13:43:47 otavio: looks like some kind of kernel header instability Jul 16 13:44:12 otavio: only happens on the fsl-arm machines Jul 16 13:44:28 otavio: The trouble is I need this fixed since red builds slow down patch merging Jul 16 13:45:05 RP: I fully agree Jul 16 13:45:11 RP: Kernel ... Jul 16 13:45:22 RP: we don't mess up with the kernel headers anymore Jul 16 13:45:35 RP: so it might be the kernel itself Jul 16 13:46:07 otavio: should it be building linux-fslc or linux-imx ? Jul 16 13:46:21 otavio: there are a load of PREFERRED_PROVIDER warnings at the top Jul 16 13:46:22 mx53 Jul 16 13:46:24 linux-imx Jul 16 13:46:36 otavio: linux-fslc looks to being selected Jul 16 13:46:40 let me check Jul 16 13:46:41 oh Jul 16 13:46:50 so let me try to reproduce it Jul 16 13:48:44 RP: Is it possible for you to paste the used local.conf? Jul 16 13:48:53 RP: here I don't see the providers error Jul 16 13:53:05 otavio: see the top of https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/166/steps/CreateAutoConf/logs/stdio Jul 16 13:53:25 otavio: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/166/steps/Create%20BBLayers%20Configuration/logs/stdio is the layers config Jul 16 13:54:05 otavio: PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev" looks suspicious :/ Jul 16 13:54:39 otavio: could be that and be an autobuilder config error Jul 16 13:55:00 RP: yes; and this happened in past too Jul 16 13:55:17 we need to file a bug for Beth to fix that Jul 16 13:56:01 RP: IIRC my advice was to have it for each 'core' machine so it'd be used for regression test of the -dev linux-yocto recipe but don't mess up with everything else Jul 16 13:56:36 otavio: who did you discuss that with? Jul 16 13:56:55 RP: this was long time ago Jul 16 13:57:06 RP: I think it was you and maybe pidge Jul 16 13:57:24 RP: but I really don't recall for sure Jul 16 13:59:13 otavio: wasn't me :/ Jul 16 13:59:21 otavio: I've filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6543 Jul 16 13:59:23 Bug 6543: major, Undecided, ---, elizabeth.flanagan, NEW , linux-yocto-dev PREFERRED_PROVIDER infiltrating non linux-yocto builds Jul 16 13:59:38 RP: great. Jul 16 14:54:17 Hmm, anyone hit a case where do_fetch succeeds, but the submodules aren't set up correctly in ${S}, when using gitsm:// fetcher? Jul 16 14:54:26 we have a random failure of this sort on our automated builds Jul 16 14:55:03 specifically, the submodule path is empty, seemingly wasn't set up there at all Jul 16 15:20:45 sameo: RP just found a bug in my makefile patch for neard Jul 16 15:21:15 kergoth: the gitsm fetcher is full of holes :( Jul 16 15:22:04 I think we should just bite the bullet and integrate git/gitsm and default to fetching submodules unless opted out via a url parameter. if a submodule exists, its there for a reason, and presumably is required to build the thing Jul 16 15:22:08 heh Jul 16 15:23:36 kergoth: until someone fixes the holes we're not doing that. gitsm is basically broken for mirroring and various other things and I simply have no idea how to actually fix it properly Jul 16 15:25:26 Personally I'd change it to stop treating the submodules as part of the main repository and instead treat them as separate mirror archives and git dirs under DL_DIR, and let the unpack process deal with pulling it all together Jul 16 15:25:43 thats how my old git-cached-clone/git-cache scripts worked which transparently cached every url i cloned Jul 16 15:25:45 kergoth: right, that is probably what it needs Jul 16 15:26:18 kergoth: as someone who doesn't use gitsm, I've found it hard to summon up the enthusiasm to go and do that though Jul 16 15:26:27 fair enough, i'll see if i can squeeze it into my todo Jul 16 15:31:54 I was replacing git submodules with multiple repos in SRC_URI and small .bbclass which was comparing that the SRCREVs used for "modules" is the same as what .git/modules requires in main repo Jul 16 15:43:40 JaMa: Hmm, is that class anywhere public? :) Jul 16 15:44:50 no, but it was just simple dirty shell function Jul 16 15:45:22 * kergoth nods, np, was just curious Jul 16 15:50:50 Im crosscompiling a autotool framework that depends on some libs, wich are in /usr/local/include/bitstream, how can i pass this path to my recipe? Jul 16 16:12:10 JaMa: basically that is what the fetcher needs to do internally Jul 16 16:28:28 JaMa: there are a few basic determinism issues for oe-core in the patchset I just sent out... Jul 16 16:51:10 * nerdboy had no idea this biz-dev crap would suck up so much time... Jul 16 16:51:35 oops, did i say crap? Jul 16 16:59:29 Ricko__: you need to ensure your configure.ac has logic to determine if bitstream/xxx.h is available and add the paths to include path if they are btw. why are they in /usr/local ? OE would put things in /usr/include Jul 16 17:00:12 i also hope he didn't mean paths on the host :) Jul 16 17:01:22 heh yes it can be worse than I thought Jul 16 20:28:42 Can Yocto be used on any processor platform like the at91sam62 Jul 16 20:35:58 stieno - ia32, power, arm, and mips are all supported.. Jul 16 20:36:11 if that process is one of those, it might work -- depending on toolchain support and related.. Jul 16 20:36:20 but general micro controllers usually are not supported.. Jul 16 20:36:33 (a lot of atmels are 32-bit arm these days and can run Linux) Jul 16 21:57:40 is there a reason I can't find the files in the native sysroot (build/tmp/sysroots/x86_64-linux) if I build the -native version of my recipe? Jul 16 21:58:24 what files, not everything goes into the sysroot Jul 16 22:00:30 I guess you're right, they're not in the non-native sysroots either Jul 16 22:01:06 is this eg the bootchart2 ui? Jul 16 22:01:12 good guess :) Jul 16 22:01:24 :) Jul 16 22:01:45 i guess you'll want to stage it manually Jul 16 22:01:51 (looks up example0 Jul 16 22:04:35 also, when running native python programs as part of the build process Jul 16 22:04:50 is there some standard way we have of changing the python paths to the native sysroot? Jul 16 22:05:43 so i think you want to use a sysroot preprocess hook to copy more files to the sysroot, see recipes-support/apr/apr_1.5.1.bb Jul 16 22:10:41 ok will look into it Jul 16 22:12:08 i wonder if the filter is a variable you can just override Jul 16 22:13:01 no. Jul 16 22:13:07 fwiw, you want to look at staging.bbclass Jul 16 22:13:22 do_populate_sysroot is the task that copies from the build directory into the sysroot Jul 16 22:13:56 would be great if sysroot_stage_dirs() had a way of easily adding extra directories Jul 16 22:23:44 so you put a function in SYSROOT_PREPROCESS_FUNCS to just copy the dang files? Jul 16 22:25:57 yeah... Jul 16 22:26:31 we need SYSROOT_EXTRA_DIRS or something Jul 16 22:28:47 okay, I can do that Jul 16 22:29:42 so about the python paths... Jul 16 22:46:28 oh yeah :) Jul 16 22:48:02 there's a python native class you can use to use the python in the sysroot and then the module paths should just work Jul 16 22:48:23 assuming your problem is "recipe installs a python module, the script can't find it" Jul 16 22:57:25 halstead: around? Jul 16 22:57:36 rburton, Yep. Jul 16 22:59:13 halstead: I can't ssh into opensuse131-a.osl (permission denied) Jul 16 22:59:22 rburton, One se.c Jul 16 23:22:47 rburton, doesn't that only work if you're running a python script from within a recipe? **** ENDING LOGGING AT Thu Jul 17 02:59:59 2014