**** BEGIN LOGGING AT Mon May 04 02:59:59 2015 May 04 07:02:33 good morning May 04 07:25:27 morning all May 04 10:09:49 Hi there ! May 04 10:10:39 What is the easiest way to get the size of all the packages installed in an image ? I know bitbake -g but it does not give the size May 04 10:16:17 in the tmp/deply/rpm directory, I have all, but dev and dbg too, I only want those installed May 04 12:21:30 hi all May 04 12:23:58 I'm using my own defconfig + module selection + machine bsp with the MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS to include the module in the rootfs, but when i do the modprobe for the deployed module i get: "modprobe: no gzip/bzip2/xz magic". Clues? Thanks in advance May 04 12:47:44 sm0ketst, I installed kmod to solve this issue, instead of using busybox modprobe May 04 12:50:36 just a workaround.. May 04 12:51:14 bukington: i had the same issue with iproute2 ... i had to check before which is running the modprobe.... Indeed thanks!!!! May 04 13:56:24 bukington: i see busybox is aliasing the modprobe but i also saw libkmod2 and kmod are in the rootfs's manifest. ?? May 04 14:35:56 Can/will yocto support package caching? May 04 14:46:57 bukington: solved, i've read the core-image-testmaster.bb May 04 15:00:07 jmleo: You could try toaster, that can give diagnostic information about builds May 04 15:04:07 RP: thanks, I was looking for a command line tip, but will give it a try ;) May 04 15:08:30 hi.. i need some good input from you guys here :) i got a linux kernel recipe from a vendor. the recipe adds a task do_kernel_defconfig like here: http://paste.ubuntu.com/10984939/ -- i wrote a kernel driver and created a patch with git, and also a *.cfg file and added both to my bbappend SRC_URI. after calling -c configure i see my *.cfg changes in the defconfig and the .config files, but not as selected. i think the do_kernel_defconfig is overwriting this May 04 15:09:53 ericbutters. does the vendor's kernel recipe inherit linux-yocto ? May 04 15:11:50 zeddii: no, inherit kernel May 04 15:12:22 and that's why the fragments aren't applied. they need linux-yocto (like the linux-yocto-custom) recipe shows. May 04 15:12:42 FYI: I'm changing things around, so that will no longer be necessary shortly .. but for now, you do need to do that. May 04 15:13:39 you say i need to change the vendor recipe to inherit linux-yocto? or is it possible to do this from my bbappend? May 04 15:14:59 I've done it in a bbappend before. but sometimes it is easier to just create a custom recipe. you just need to add: require recipes-kernel/linux/linux-yocto.inc to the recipe. May 04 15:15:22 but the branch, the SRCREV and some other details needs to be right as well. May 04 15:15:42 I don't suppose any of the parts are public ? I can advise better if I can see the recipe and tree. May 04 15:29:18 zeddii: i have to check if i can provide more detail to you.. but, how to add kernel modules to linux when using this "inherit kernel"? is that possible at all? May 04 15:29:50 you can just extend their defconfig. it really depends on how they are doing the configure phase. May 04 15:30:25 zeddii: the configuration phase i provided in the link? May 04 15:30:35 but a simple way to do it, would be to take a copy of their defconfig, put it in your layer, make changes, and then add it to the SRC_URI. yours will override. May 04 15:30:38 addtask kernel_defconfig before do_configure after do_patch May 04 15:30:46 ah. sec May 04 15:31:12 zeddii: but what if more developers will bring in theri kernel modules? May 04 15:31:17 ouch. *sigh* May 04 15:32:16 that is going to cause you all sorts of pain. May 04 15:32:51 ericbutters: I'm yanking out fragments into a more consumable format, but when there are tasks defined like that, it won't really matter. that is going to clobber everything. May 04 15:33:23 when is that defined to run ? i.e. how is it add_task'd into the build ? May 04 15:33:25 therefore the right way is to use yocto-linux rught? May 04 15:34:22 that is from the original recipe of the vendor. it is in the *.bb file, so tasks will be added when bitbake parses? May 04 15:35:10 to get it right, i have to create a new recipe that does May 04 15:35:17 they have to be added. that defines the task, but somewhere this is a "addtask kernel_defconfig after " May 04 15:35:21 'inherit yocto-linux' May 04 15:35:49 zeddii: yes, that is also in the recipe from the vendor May 04 15:35:52 ericbutters, it's an include you can add, versus inherit, since the include has the inherit as part of it. May 04 15:36:05 i see May 04 15:37:50 zeddii: http://paste.ubuntu.com/10985097/ May 04 15:39:43 ericbutters, they even clobbered do_patch. May 04 15:39:54 so if you needed to modify that tree at all .. good luck :) May 04 15:40:02 :) May 04 15:40:07 damn May 04 15:40:30 but yah, this is something you can wrap with linux-yocto-custom. there's a sample in meta-skeleton May 04 15:40:46 i got more developers, each need to integrate kernel modules within yocto recipes May 04 15:41:03 yep. a pretty common workflow. May 04 15:41:43 if you give me a few minutes (I have to relocate home), I can mock up a sample linux-yocto-custom on how I'd deal with it (without having their source tree of course). May 04 15:41:51 zeddii: where can i find meta-skeleton and more detail on linux-yocto-custom? thanks! May 04 15:42:10 okay nice! May 04 15:42:55 i am going to leave my desk here also, so i will come back to you in 1.5h or something, maybe you are ready then also :) May 04 16:12:48 ericbutters: can you repost a link to that recipe ? I don’t have IRC history here :) May 04 16:15:12 zeddii_home: http://paste.ubuntu.com/10985097/ May 04 16:15:24 perfect May 04 16:53:47 * mranostay spots a RP May 04 17:02:00 hi mranostay May 04 17:04:38 RP: so Crofton|work claims that 73 mile bike ride wasn't on a moped :P May 04 17:05:11 mranostay, you just need to work harder May 04 17:06:12 mranostay: Whilst I may have a set of suitable motorcycles, using those trails with them would get me arrested ;-) May 04 17:06:58 Crofton|work: having the bar set at 73 miles on a Monday is dishearting :P May 04 17:07:32 mranostay: it wasn't really intentional, I just kind of forgot to turn around (its a holiday here) May 04 17:08:13 The plan was Wylam, then I saw a sign for Corbridge and once I'd gone that far, Hexham was only 4 miles further... May 04 17:24:24 Hi, I was wondering if I could get some feedback/commit on this patch, it's been sitting there a little bit now. http://patches.openembedded.org/patch/92539/ May 04 18:48:15 What is the right way to use FOO_append ? Always use `:=`? Or `=`? Or `+=`? May 04 18:48:45 never use _append with +=, it's pointless May 04 18:49:01 := should only be used when you need the value immediately expanded, and that's true with or without _append May 04 18:56:15 ok. So multiple uses of FOO_append are fine with `=`? May 04 18:58:06 _append/_prepend are just lazy versions of .= and =., respectively, except that you can combine the former with overrides to do conditional append/prepend May 04 18:58:19 they're cumulative, as they're all concatenation operators May 04 18:58:26 so yes May 04 19:00:01 you should also never use _append or _prepend when .= or =. or += or =+ will do May 04 19:05:39 Ok, so in .bbappends is it generally ok to use .=/=./+=/=+ instead of _append/_prepend? Or is there some common pitfal that makes the later more preferable there? May 04 19:05:52 bbappend is like concatenating content to the recipe May 04 19:06:34 there's nothing special about what you can put there that's idfferent than what you'd put in the recipe, with the exception of FILESEXTRAPATHS, since that modification is intended to add the location where the bbappend lives to it, and the variable used only has that value while the bbappend is being parsed May 04 19:06:50 which is why we want := there, to force it to use the current value, not expand it later when it's set to the path to the recipe May 04 19:07:36 so again, unless you have a very good reason, avoid both _prepend/_append and :=. in the case of FILESEXTRAPATHS, we have a very good reason for both. May 04 19:10:00 kergoth: thanks, this has been very helpful. May 04 19:10:13 np May 04 19:10:37 see also the yocto and bitbake manual for info on the file format and how the different operators work, for reference May 04 19:11:51 the thing to remember with _append/_prepend is when they're processed — the end of the recipe parsing. so they can be used to postpone the operation, e.g. to make sure the append takes even if something is parsed after you and sets the variable May 04 19:11:58 lazy rather than immediate May 04 19:12:47 Which is why I suppose includes & classes end up using _append/_prepend instead of .=/=./+=/=+. May 04 19:12:53 long term, they may end up being applied at expansion time, when the variable's value is obtained, rather than at a specific point in the parsing process, but it'd still be lazy May 04 19:13:07 yeah, exactly, in some cases they want their changes to stick around regardless of where exactly the recipe inherits it May 04 19:13:27 (inherit being an immediate operation as well, like include, so lines after the inherit are parsed after the lines of the file being inherited) May 04 19:14:38 that's why the convention for inherits is to place them after the recipe metadata variables, but before the functions, to ensure that the recipe can override the class tasks, and the class can easily append to the metadata variables if appropriate, but that's just a convention May 04 19:15:40 * kergoth dislikes the imperative vs declarative confusion in our file format, but we're stuck with it for now May 04 19:31:28 ericbutters: around ? May 04 23:36:07 The behavior of OVERRIDES_append = ":foo" is fascinating. May 04 23:36:46 hmm May 04 23:36:49 So people were saying something about seeing that "dir quasi-mismatch" message from pseudo, anyone happen to have a trivial reproducer? May 04 23:37:08 Looking at it, if it's showing up a lot it suggests that I probably have some kind of logic error, but I think it's an error in the error message. May 04 23:37:23 Specifically, I *think* that in the case where a directory is referred to by a path without a trailing slash, I'm generating a diagnostic when I shouldn't be. May 04 23:38:18 yup May 04 23:38:25 Okay, yeah, that would produce a ridiculous volume of false positives May 04 23:38:39 test was (!!S_ISDIR(by_path.mode) != trailing_slash) May 04 23:38:41 should be (trailing_slash && !S_ISDIR(by_path.mode)) **** ENDING LOGGING AT Tue May 05 02:59:59 2015