**** BEGIN LOGGING AT Wed Jun 04 02:59:58 2014 Jun 04 06:50:11 hi there; question Jun 04 06:50:21 I'm inheriting core-image Jun 04 06:50:34 and for some reason, it includes dbus which drags in virtual/libx11 Jun 04 06:50:54 which causes problems because I need i.MX6 vivante with FB Jun 04 06:51:15 any idea how I can figure out why it does this? the dependency graph shows that dbus wants "virtual/libx11" Jun 04 07:04:47 rink_: it's probably because x11 is enabled in your DISTRO_FEATURES Jun 04 07:05:22 if you look at dbus recipe, you will see "PACKAGECONFIG[x11] = "--with-x --enable-x11-autolaunch,--without-x --disable-x11-autolaunch, virtual/libx11 libsm" Jun 04 07:20:23 ndec, how can I verify that this is indeed the case ? Jun 04 07:21:15 you can check the value of DISTRO_FEATURES in your config files. if you use oe distroless or poky, then x11 is enabled by default Jun 04 07:21:23 it seems this even happens with 'core-image-minimal' Jun 04 07:21:37 DISTRO_FEATURES is orthogonal to image recipe Jun 04 07:22:13 the .conf files for distro, machine, local, .. that contains definition used across all recipes. Jun 04 07:22:31 image recipe are just standard recipe that pulls together binary packages Jun 04 07:22:53 if dbus was built with x11 enabled , any image that uses dbus will get its x11 depends Jun 04 07:22:53 maybe bitbake -e core-image-minimal | grep DISTRO_FEATURES Jun 04 07:23:07 yes, ^DISTRO_FEATURES even better Jun 04 07:23:35 ah right Jun 04 07:23:58 i need to step out for ~30mins.. Jun 04 07:28:38 hmm it's with DISTRO_FEATURES_DEFAULT Jun 04 07:28:47 how can I get rid of it ? Jun 04 07:30:46 i personally usually take poky-lsb.conf or poky-bleeding.conf, and derive my own distro config for it Jun 04 07:44:09 i can inherit poky-lsb instead of core-image ? Jun 04 07:48:55 not at all, you are mixing up a distro config and an image recipe now. Jun 04 07:49:27 you create your own distro config, derived from poky-whatever. and then you point your locoal.conf's DISTRO to it. Jun 04 07:58:56 okay, just spent time reading through the development manual and I don't undeerstand what you mean Jun 04 07:59:27 DISTRO ?== 'poky' in my local.conf fwiw Jun 04 07:59:29 however, I've added a custom layer with the kernel patch I need, which seems to work great Jun 04 07:59:45 the idea was to create an image into that custom layer, which I intend to build Jun 04 08:02:03 yeah thats all fine. Jun 04 08:02:46 now have a look at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky-bleeding.conf and its location Jun 04 08:03:27 it shows you how you can easily derive your own distro configuration from poky. create something similar for your needs, and place it at the corresponding path in your layer Jun 04 08:03:40 then set it in local.conf to be used. Jun 04 08:03:58 so you are able to reproductibly set distro features etc. for your stuff. Jun 04 08:04:36 ah, so my layer should also hold a custom distribution Jun 04 08:04:58 thats kind of the simplest way Jun 04 08:05:14 sorry, this is all new to me :) Jun 04 08:06:02 no problem, i've been thorugh all of this only a few weeks/months ago. Jun 04 08:08:20 how do i make sure things like x11 aren' t dragged in? Jun 04 08:09:26 well remove them, and then check with bitbake -e Jun 04 08:13:34 hmm seems default-distrovars.inc is the culprit Jun 04 08:13:56 which is included by defaultsetup.inc ... Jun 04 08:16:20 guess i'd better guess i'd better override that one Jun 04 08:16:47 no... you can use DISTRO_FEATURES_remove, for example Jun 04 08:17:26 I see DISTRO_FEATURES_DEFAULT ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x 11" Jun 04 08:17:37 so, after including the poky.conf and other stuff, I'll have that as default Jun 04 08:17:49 will placing DISTRO_FEATURES_remove = "x11" after the include work ? Jun 04 08:18:12 should, IIRC Jun 04 08:18:59 of course, I can always replace the DISTRO_FEATURES_DEFAULT thing, but ... dunno Jun 04 08:21:00 rink_: _remove will work, it doesn't really matter if you do it before or after. _remove are processed at the end of parsing Jun 04 08:21:43 if you just need to remove x11, _remove is the simplest method. if you build your own distro , and really need something custom then building DISTRO_FEATURES 'manually' is an option Jun 04 08:23:24 otavio: is the " mv conf/local.conf conf/local.conf.sample Jun 04 08:23:30 ooops. sorry Jun 04 08:27:17 otavio: is the "Ensure all files in sources/base are kept in sync with project root" code in setup-environment in fsl-community-bsp-base right? Jun 04 08:27:53 to me it seems that the cwd is not correct when that code is run Jun 04 08:41:59 hmm so if I understand correctly, the reason the DISTRO_FEATURES_remove = "x11" didn't work in my own core-image recipe is that it is parsed too late Jun 04 08:42:08 and bb already decided that dbus etc need x11? Jun 04 08:45:20 rink_: it needs to be set in the distro or local config files. in the recipes, it would only have a local effect (and tehrefore not remove the packages.) Jun 04 08:50:24 btw, the instructions i followed when patching the kernel claimed you had to increment PRINC; but that gives warnings now. is that no longer needed? the linked page doesn't really help Jun 04 08:53:56 morning all Jun 04 08:54:19 rink_: you no longer need PRINC, those instructions need updating Jun 04 08:54:29 rink_: which instructions are those? Jun 04 08:57:14 hmmm; i can't remember actually - this was done a long time ago (and got pulled off the project in between :S) Jun 04 08:58:42 ok; if you do come across it let us know Jun 04 08:58:49 fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/cortexa9hf-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld: shell.o: relocation R_ARM_MOVW_ABS_NC against `forced_interactive' can not be used when making a shared object; recompile with -fPIC Jun 04 08:58:50 uh-uh Jun 04 09:01:25 *wonders what is that* Jun 04 09:02:20 seems it only affects bash *scratches head* Jun 04 09:09:24 doesn't mean anything to me I'm afraid... Jun 04 09:11:05 hmm guess nuking the work/cortex.../bash directory to force it to rebuild messed things up Jun 04 09:11:20 and cleansstate doesn't help either - how can I get bitbake to understand bash is to be rebuilt completely ? Jun 04 09:13:34 morning Jun 04 09:14:34 ok, guess -c cleansstate bash helped Jun 04 09:14:45 seems cleansstate isn't recursive :) Jun 04 09:15:46 bluelightning, btw, found the tutorial I think i followed: https://community.freescale.com/docs/DOC-95252 Jun 04 09:16:26 [btw: this is odd - force rebuilding of bash seems to fix the issue - wonder what that was all about] Jun 04 12:41:40 Hi. I just updated/pulled to the latest dora branch 0a6f0dbf9476dcb4a17a210af90e2dd1a43b61aa and I notice meta-yocto/conf/distro/poky.conf still shows DISTRO_VERSION="1.5.1", and thats what shows in the Build Configuration dump on the build. Is that expected? Jun 04 12:42:46 (thought it was 1.5.2 now...) Jun 04 12:44:53 mawillia: I think someone missed bumping the version Jun 04 12:44:59 there is a bug open for it: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6395 Jun 04 12:45:00 Bug 6395: normal, Undecided, ---, richard.purdie, NEW , poky version of 1.5.2 does lists 1.5.1 Jun 04 12:45:53 BÜMP all the versions :) Jun 04 14:07:40 i'm in the progress of making a custom u-boot recipe, and i've got a problem with the license thing: git checks out everything, but the directory seems to be empty afterwards. so the license file cannot be found :( Jun 04 14:11:04 what might be the reason for the fetched src directory to be empty? Jun 04 14:12:09 Can I reuse sstate artefacts built on a Fedora system when I rebuild the same image on an Ubuntu system ? Jun 04 14:12:23 Or does the build and development servers need to run the same OS ? Jun 04 14:15:12 kroon: by default we don't share the native portions between different host OSes Jun 04 14:15:40 but the only issue there is when you build on a newer glibc system and then transfer native components from there over to a system with an older glibc Jun 04 14:16:20 so if you can ensure your "source" has an old-ish version of glibc on it then you shouldn't have any problems Jun 04 14:16:48 you just need to set up symlinks in your sstate mirror for the host OSes you will be using on the other machines Jun 04 14:19:00 bluelightning, aha .. so if we have the same OS on our development machines, we could build everything once, upload it to the server (which could have a diff. OS), and then it could share every artefact, including native ones, to all developers ? Jun 04 14:19:18 kroon: yes Jun 04 14:19:38 bluelightning, makes sense ! Jun 04 14:23:27 maybe also an idea why the source dir of a git hosted packe is empty after fetch, except for the .git directory? Jun 04 14:36:04 or at least, how to debug the fetch-unpack process to see where it goes wrong? Jun 04 14:46:35 Letothe2nd: you can try with: bitbake u-boot -DDD -c unpack Jun 04 14:49:58 akS: looks like git -c core.fsyncobjectfiles=0 clone -s -n /data/yocto/downloads/git2/fslinux.git.RSI.CortexA5.CortexA5-UBoot.git/ /home/sepp/Projekte/msr21_tan/build/tmp/work/rsi_sama5d3-poky-linux-gnueabi/u-boot-rsi/v2014.04-rsi-r0/git/ is the called signature Jun 04 14:50:51 which means that in /home/sepp/Projekte/msr21_tan/build/tmp/work/rsi_sama5d3-poky-linux-gnueabi/u-boot-rsi/v2014.04-rsi-r0/git the unpacked sources shall be. but theres nothing besides .git Jun 04 14:57:48 strange Jun 04 14:58:04 ok, interesting point in the gi2/xxx download dir, there is no FETCH_HEAD file Jun 04 14:58:55 whereas in another directory coming from the same server (and working) there is one. Jun 04 15:01:12 FETCH_HEAD seems to be in all the download directories that are working. Jun 04 15:01:19 how comes that might miss? Jun 04 15:17:08 Letothe2nd: Is there anything useful in the relevant log.do_fetch file? Jun 04 15:18:54 alternatively you could try executing the same git command that bitbake is executing in an empty tmp directory and seeing what happens Jun 04 15:19:07 paulbarker: exactly the same thing happens. Jun 04 15:19:13 already tried that :( Jun 04 15:20:13 maybe run bitbake -DDD for a package that works and see if the git options are the same Jun 04 15:20:30 paulbarker: hm, not a bad idea. Jun 04 15:20:52 paulbarker: i've just kicked off another little longish process, but will try that next then. Jun 04 15:21:50 as an off-the-wall suggestion, try specifying a branch in SRC_URI, even if that is 'branch=master' Jun 04 15:23:23 paulbarker: i'm specifying a sha of a commit already. might try with master, yes. Jun 04 15:29:45 I get the impression 1.6 got bloated Jun 04 15:30:16 for some yet unknown reason my 1.5.1 non-x11 build, builds now in 1.6 gnome-desktop-testing Jun 04 15:42:17 volker-: we enabled ptest by default to enable running upstream-supplied tests at runtime Jun 04 15:42:41 the ptest packages are however not installed by default Jun 04 15:42:57 if you would prefer not to build them at all, simply remove ptest from DISTRO_FEATURES Jun 04 15:43:45 bluelightning: did -ptest get renamed to -testing? Jun 04 15:43:54 volker-: no Jun 04 15:43:57 I was reading through the update notes but haven't read anything about it Jun 04 15:44:23 volker-: gnome-desktop-testing is the name of the package upstream, it's just a dependency that is needed to run some of the ptests Jun 04 15:44:34 ic Jun 04 15:44:48 for ptests I have here a separate build Jun 04 15:44:50 we might have missed adding this to the migration notes Jun 04 15:46:42 going through the migration notes a question raised about the atom-pc note. "The atom-pc hardware reference BSP has been replaced by a genericx86 BSP." Jun 04 15:47:03 yet, the Atom here is 64bit, are not all atoms 64bit? Jun 04 15:47:34 volker-: there are actually two machines now: genericx86 is 32-bit, genericx86-64 is 64-bit Jun 04 15:47:52 bluelightning: that was already the case in 1.5.1 Jun 04 15:48:04 bluelightning: the question is more: are there Atoms that are not 64bit Jun 04 15:48:12 absolutely there are yes Jun 04 15:48:15 the early ones were not Jun 04 15:48:43 reading the release note it gives me the impression that I want to use generix86 for atoms (and not -64) Jun 04 15:49:29 volker-: that's not the intended meaning, FWIW Jun 04 15:50:01 but then, atom-pc was more of a reference for netbooks rather than any atom-based machine Jun 04 15:50:14 AIUI Jun 04 15:51:16 :) Jun 04 15:51:36 I think I just add my notes here as feedback to the wiki Jun 04 15:51:45 s/wiki/bugzilla Jun 04 16:03:58 bluelightning: so ptests are automatically build (if not disabled), is there a way to automatically create two images: one with and one without ptests in the same run? Jun 04 16:04:19 right now we have to builds for this in our 1.5.1 version. Jun 04 16:04:54 volker-: yes, you'd just have two image recipes and the second would "require" the first but also do IMAGE_FEATURES += "ptest-pkgs" Jun 04 16:05:19 that would add all -ptest packages corresponding to other packages in the image Jun 04 16:05:39 alternatively you could selectively add the desired -ptest packages to IMAGE_INSTALL if you didn't want all of them Jun 04 16:12:49 bluelightning: but I still have to execute 2x bitbake for that? Jun 04 16:16:59 volker-: no, you could do bitbake image1 image2 ... Jun 04 16:17:33 interesting. Jun 04 16:20:05 btw, thanks for the info :) Jun 04 16:20:56 no problem Jun 04 16:24:42 My company noticed a few days ago that base.bbclass ignores license checks for -native and most -cross packages. I posit this behavior could be incorrect as native code could inject incompatible code into the target device. Jun 04 16:24:55 I also view this as fairly unlikely, but possible. Jun 04 16:25:34 To that end, I've worked with one of my colleagues to gin up a patch to let you specify LICENSE_WARNINGS in a .conf file and see warnings for any package potentially in violation of your incompatible licenses. Jun 04 16:25:42 Is there any opposition to that concept? Jun 04 16:26:25 (Obviously, I recognize the patch will need to be reviewed on its own merits as well.) Jun 04 16:27:09 peachj: what would you be specifying in LICENSE_WARNINGS ? Jun 04 16:28:24 Just a True value. (I've been doing LICENSE_WARNINGS = "1" in local.conf.) Jun 04 16:28:40 That enables that warning behavior. Otherwise, the behavior is essentially unchanged. Jun 04 16:30:23 we might want a different name for the variable, but the general concept seems good Jun 04 16:31:41 Any suggestion on the name, or you just want to wait for me to send the patch in for that? Jun 04 16:32:06 hmm... something that more closely represents what it's warning about I guess Jun 04 16:32:10 naming is always a pain Jun 04 16:32:13 NATIVE_LICENSE_WARNINGS? Jun 04 16:32:17 I like naming :-) Jun 04 16:32:35 that's definitely better Jun 04 16:33:43 bluelightning: so I have a regular image my-image.bb; is it a bad style to create my-image-ptests.bb and do a "require myimage.bb" (and not .inc)? Jun 04 16:34:19 volker-: yep that's fine, we even do that with the core-image-minimal derivatives in the core already Jun 04 16:35:19 I miss the "yocto is written in this style" ;-) Jun 04 16:36:29 what I never understand: why is the deploy folder stored under tmp Jun 04 16:37:24 maybe we should have called tmp something else :) Jun 04 16:38:06 the work folder with all the build folders is more tmp to me as the deploy folder Jun 04 16:38:44 or the cache Jun 04 16:38:56 I think the tmp naming is the confusing part Jun 04 16:39:05 TMPDIR isn't necessarily temporary Jun 04 16:39:10 it's just the output directory Jun 04 16:40:02 it's more the consistency of using it that confuses me. buildhistory and downloads are in the folder below tmp Jun 04 16:41:33 in both cases you don't want those to go away if you get rid of everything else in TMPDIR Jun 04 16:42:09 but do you want the images to go away? Jun 04 16:42:33 well, generally I do, yes Jun 04 16:42:55 it depends on why you are deleting TMPDIR I guess Jun 04 16:43:28 if you prefer a different layout, you can set DEPLOY_DIR to point elsewhere Jun 04 16:43:55 yes, you can move them all :) Jun 04 16:44:08 Was just curious why it is this way, I never really understood it Jun 04 16:50:35 bluelightning: re: my patch. I understand I should be submitting to openembedded-core; should I still be using the create-pull-request script to submit the patch? (Haven't submitted any patches before.) Jun 04 16:51:29 peachj: it's up to you - depends on whether you have somewhere to push the patches in order to make the pull request Jun 04 16:51:42 for a multi-patch series, a pull request is preferred Jun 04 16:52:07 for single patches it's OK to just send them with git-send-email Jun 04 16:53:07 peachj: I wouldn't mind seeing something like ADDITIONAL_LICENSE_WARNINGS = "cross native" Jun 04 16:53:44 peachj: should probably go in license.conf as well Jun 04 16:55:17 pidge: In my mind, the switch is basically, "Do I want to see all possible warnings or not?" (Essentially, this is a change for hyper paranoid folks in my company, but I imagine all companies of sufficient size have someone hyper paranoid about licenses.) Jun 04 16:56:06 The change is in base.bbclass (and only there) because the code that fatals you out for a bad license is in there. We're just adding another branch to that code if NATIVE_LICENSE_WARNINGS is set. Jun 04 17:00:03 peachj: Understandable. I think NATIVE though implies that it's only -native or -nativesdk you're warning for, right? Jun 04 17:01:07 It could, but I just couldn't think of a better word ;-) Essentially, all the packages (ending in -native or -cross or then ten other suffixes being skipped) are all actually native programs. Jun 04 17:01:25 The change I'm proposing will completely eliminate that if-statement. Jun 04 17:01:42 At least around whether the check is performed, I should say. Jun 04 17:01:58 The if-statement would then simply control whether we warn or do nothing. Jun 04 17:05:42 pidge: just a short one: is there already some means in the autobuilder to also publish the generated rootfs artifacts, or do we need to come up with something ourselves? Jun 04 17:08:11 Letothe2nd: PublishArtifacts should do something like what you want to do. That said, I've been talking with LCryin about refactoring it, because it's kind of not what I want it to be. Like the ext3 files, etc? Jun 04 17:17:07 seems like the qemu kernel version is different to the x86-64 kernel version Jun 04 17:22:23 pidge: yeah basically yes. for me personally the ext3 and ubi files are relevant, but ofc that also extends to zImage, uBott, etrc. Jun 04 17:24:42 Letothe2nd: yeah. we've be discussing how we do PublishArtifacts a bit. Right now, it's kind of a pain, in that it's both machine/layerversion dependent. I had discussed a while back (may have been privately) doing it via a config file similar to how we do the buildset confs. Jun 04 17:25:11 Letothe2nd: that said, pulling together your own Publisher isn't hard, as long as you know what files you want. Jun 04 17:25:33 is there a reason why the openssh build throws QA Issues in the 1.6 "stable" branded version due of 'has relocations in .text'? Jun 04 17:26:18 volker-: known issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6104 Jun 04 17:26:20 Bug 6104: normal, Medium+, 1.6.1, cristian.iorga, ACCEPTED , Possible false positive QA warnings while building Jun 04 17:26:37 pidge: thats what i guessed. Jun 04 17:27:09 pidge: yeah when i looked at the py i really wondered why it includes all those bizarre references to machine type etc. Jun 04 17:27:36 pidge: will probably hack sth up myself then... thanks! Jun 04 17:30:33 Letothe2nd: for now, that's probably best until I or someone else gets a chance to sit down and hack this out. We're trying to maintain at least 2 years worth of backwards compatibility on the AB, so that's why you see all the layerversion code (image location changes/machine name changes, etc) Jun 04 17:32:41 pidge: ok, gotcha Jun 04 17:33:22 * Letothe2nd calls it a day now and flees Jun 04 17:37:37 Hi all! Jun 04 17:38:19 guys is there somebody that would help me with a weird bitbaking syntax error? Jun 04 17:38:26 can't find anything on the net... Jun 04 17:42:26 basically i get a SYNTAX error processing the second line of ANY .bb file, and the content of the line #2 is just: "DESCRIPTION =" Jun 04 17:43:34 the strange thing is that with oe-core the build succeed! i've installed python and the version is 2.7.3 and the bitbake folders of ~/oe-core and ~/poky are identical Jun 04 18:16:11 I create a new machine and included a file on machine's .conf file, the included file has the line`PREFERRED_PROVIDER_u-boot = "u-boot-variscite"'. When I run `bitbake core-image-minimal' I got this note `NOTE: multiple providers are available for u-boot (u-boot, u-boot-imx, u-boot-fslc) Jun 04 18:16:11 NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot' and the build fails beacause is trying to build wrong u-boot... If I run `bitbake -e core-image-minimal | grep PREFERRED_PROVIDER_u-boot' I got this output: http://pastebin.com/Ne77x6xp ... I'm new to yocto and have no idea what is going wrong Jun 04 18:17:04 Anybody can help me? Cheers :-) Jun 04 18:34:15 hi guys, if somebody can help with a bitbake error, plese ring my bell. sry for question repetition, just switched irc client. thanks a million! Jun 04 18:52:20 Hi I have some questions regarding autoloading of kernel modules Jun 04 18:52:50 I'm using the angstrom version of yocto (v2014.06) Jun 04 18:53:00 and I'm building for the beaglebone (black) Jun 04 18:53:34 The kernel of the beaglebone doesn't inherit the linux-yocto recipe Jun 04 18:54:03 now there should be an option "module_autoload_" Jun 04 18:54:24 so I added this linux-mainline_3.8.bbappend Jun 04 18:54:28 in my own meta source Jun 04 18:54:59 and added the ' module_autolaod_dma-ps-eye = "dma_ps_eye" ' to this file Jun 04 18:55:09 and rebuilded the whole thing (with rootfs) Jun 04 18:55:33 now when I browse the rootfs.tar.xz then I can't findy any entry in /etc/modprobe.d Jun 04 18:56:41 fenrig: well, is the module even installed? Jun 04 18:57:02 installed and operational :D Jun 04 18:57:08 I do have to insmod it Jun 04 18:57:10 but it works Jun 04 18:58:07 and no entry in /etc/modules-load.d Jun 04 18:59:45 I followed the hello-mod module example Jun 04 19:00:02 It was pretty easy to add my own module :) Jun 04 19:01:47 fenrig: are you sure about module_autolaod_dma-ps-eye? Jun 04 19:02:18 when the module is named with '_' the package most likely is having '_' as well? Jun 04 19:02:36 in my kernel recipe I see: 'module_autoload_davinci_mmc = "davinci_mmc"' Jun 04 19:02:44 yeah Jun 04 19:02:49 but you're source is probably Jun 04 19:02:53 davinci_mmc ? Jun 04 19:02:58 davinci_mmc.c Jun 04 19:03:00 (sorrry) Jun 04 19:04:41 fenrig: yes but your module is dma_ps_eye Jun 04 19:04:51 let me clarify Jun 04 19:04:53 and you do module_autoload_dma_ps_eye Jun 04 19:04:57 anyway, need to do other things Jun 04 19:05:06 the recipe in yocto is called "dma-ps-eye.bb" Jun 04 19:05:28 but the module is compiled (and this is because of the source file naming) to "dma_ps_eye.ko" Jun 04 19:05:36 but i'll change it for consistency Jun 04 19:05:50 okay, but that looks confusing. :) Jun 04 19:05:57 so you have a kernel recipe and a module recipe Jun 04 19:06:05 and you put the autoload for the module into the kernel recipe? Jun 04 19:06:18 euhm no in the .bbappend of the kernel Jun 04 19:06:31 should I place it in the kernel module recipe? Jun 04 19:07:02 I can't tell you what you should do Jun 04 19:07:38 can you tell me what I could do? Jun 04 19:07:57 I'm doing this of educational reasons :p Jun 04 19:08:10 I have a presentation about android, and I made my own kernel modules for the system Jun 04 19:08:22 but now I'd like to use my modules on a standard linux Jun 04 19:08:31 fenrig: welll, git grep "module_autoload_" in meta/classes Jun 04 19:08:57 fenrig: so the variable you want to set is looked at when creating a package for your module. As the mainline kernel will not build a package for your module, the line is not looked at Jun 04 19:09:22 fenrig: so yes, putting the line into the recipe you create the module package is a good start Jun 04 19:09:31 :D yeah an answer Jun 04 19:09:38 great man I'll try it Jun 04 19:09:59 fenrig: inheriting the modules bbclass is probably another obstacle and third naming the variable correctly another thing Jun 04 19:10:18 but luckily the roundtrip time for a single module is probably better than for the entire kernel Jun 04 19:12:08 zecke: I have a package for my module already Jun 04 19:14:05 and I inherit module.bbclass, this inherits kernel-module-split.bbclass Jun 04 19:14:17 and when I grepped for the module_autoload Jun 04 19:14:26 It returned the kernel-module-split.bbclass Jun 04 19:17:48 https://github.com/openembedded/oe-core/blob/master/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb Jun 04 19:17:58 I followed this example for my out-of-tree module Jun 04 19:55:18 I'll be hosting a yocto workshop for my colleagues on monday :D Jun 04 19:55:24 yay Jun 04 21:22:10 how do I explicitly build something which is marked as ASSUME_PROVIDED? Jun 04 21:39:20 maxtothemax: you can't, other than by removing it from ASSUME_PROVIDED Jun 04 21:39:46 hmm Jun 04 21:40:14 so if someone does a world build, it won't get built even then? **** ENDING LOGGING AT Thu Jun 05 02:59:58 2014