**** BEGIN LOGGING AT Mon Sep 19 02:59:59 2016 Sep 19 14:05:17 anyone else having troubles with https://git.linaro.org/kernel/linux-linaro-tracking.git and oe building not working anymore? Sep 19 14:08:11 the repo is to big or something bitbake cannot handle it Sep 19 14:10:29 I mean just looking at the commit logs looks like some guy with a stick is driving a small army to work on that repo... mad commit rate Sep 19 14:23:17 pompomJuice: where is that tree being used? which recipe? Sep 19 14:23:56 and fwiw this tree is no longer used/maintained Sep 19 14:24:07 but it comes from meta-linaro Sep 19 14:24:18 so am i ;) Sep 19 14:24:40 let me check why we are using it for. Sep 19 14:24:42 it is in meta-linaro/recipes-kernel/linux Sep 19 14:24:57 suddently a week ago my build just started breaking because that recipy started building Sep 19 14:25:01 but I have no idea why Sep 19 14:25:34 pompomJuice: and just to understand, which machine/distro/recipe are you building? Sep 19 14:26:03 I am using angstrom 1.7 as my base Sep 19 14:26:15 machine is our own Sep 19 14:26:23 based on imx6 Sep 19 14:26:26 wandboard Sep 19 14:26:58 multiple providers are available for virtual/kernel (linux-linaro-vexpress, linux-linaro-stable-vexpress, linux-dummy) Sep 19 14:27:02 that message started appearing Sep 19 14:27:18 i still don't understand why this recipe is even built. Sep 19 14:27:51 but in my machine config file I have: PREFERRED_PROVIDER_virtual/kernel = "linux-fslc" Sep 19 14:29:53 in my layers.txt all revs are locked down except meta-fsl-arm.... so it must be coming from there somehow Sep 19 14:30:18 I would love to ask bitbake to explain to me why it is building a certain recipe Sep 19 14:30:41 meta-fsl-arm is tracking master? Sep 19 14:30:47 yes Sep 19 14:30:57 which is a mistake most likely Sep 19 14:31:04 I needed the latest kernel 4. bits Sep 19 14:32:22 This is what broke everything I think: meta-fsl-arm 8b07cb9..51f2ede Sep 19 14:32:34 8b07cb9..51f2ede master-next -> origin/master-next Sep 19 14:35:10 guess it is my own fault being on the bleeding edge of the bleeding edge's edge Sep 19 14:35:45 well, beyond that.. it would be interesting to understand why a non related recipe is messing up your builds.. Sep 19 14:36:51 let me see if I roll those recipes back if it still tries to build... I think something in those changes messes with the bitbake PREFERRED mechanisms Sep 19 14:37:50 maybe it is a layer priority level that went higher than my companie's meta layer Sep 19 14:37:54 that could have been it Sep 19 14:38:05 so then my PREFERRED_PROVIDER_virtual/kernel got ignored Sep 19 14:39:00 anyway that layer should not have been on HEAD I must have merged to prod without checking Sep 19 14:40:12 yes it seems to build other things now Sep 19 14:40:23 uugh Sep 19 14:40:26 what a noob mistake Sep 19 14:42:08 Hi, I have a 64 bit kernel with 32 bit rootfs. Unfortunately the kernel-modules cause errors to pop up on do_package_qa. Is there a way to specify them using INSANE_SKIP? I've been trying but to haven't had any luck until now. Sep 19 14:42:42 the errors are 32/64 bit mismatch.. Sep 19 14:42:59 ERROR: linux-yocto-4.4+gitAUTOINC+6ec93aaa70_628bf62756-r0.1 do_package_qa: QA Issue: Bit size did not match (32 to 64) linux-yocto on work/qemumips64r2el_o32-poky-linux/linux-yocto/4.4+gitAUTOINC+6ec93aaa70_628bf62756-r0.1/packages-split/kernel-module-vfat/lib/modules/4.4.11-yocto-standard/kernel/fs/fat/vfat.ko [arch] Sep 19 17:56:49 <__cal__> hello everyone... what does it mean "Nested Vectored Interrupt Controller" i saw it on many datasheet, i know what a Vectored Interrupt Controller is but don't understand what "Nested" means in this context ... can somebody help me ? Sep 19 17:59:02 pompomJuice: run bitbake -e and make sure PREFERRED_PROVIDER_virtual/kernel is set the way you think it is, to start with. when something is seemingly inexplicable, check our assumptions Sep 19 17:59:10 * kergoth yawns Sep 19 19:34:01 khem: are you there? Sep 19 21:45:31 otavio: yes **** ENDING LOGGING AT Tue Sep 20 02:59:58 2016