**** BEGIN LOGGING AT Wed Apr 08 02:59:59 2015 Apr 08 04:13:19 so does anyone know why the python in oe-core does not build ctypes with the system libffi? Apr 08 06:25:26 nrossi: mostly its failing a detection test Apr 08 06:25:33 look at confgure logs Apr 08 06:27:14 khem`: oh so its meant to? i did read in some of the source files that python is supposed to default to the system ffi for linux platforms Apr 08 06:27:42 We are doing a cross build remember Apr 08 06:28:48 khem`: i sent a patch to make the 2.7.9 version do what the 3.3* recipe does for --with-system-ffi, would forcing the use of system-ffi be acceptable? Apr 08 06:29:41 if deps are expressed right that will be acceptable Apr 08 06:31:43 khem`: i just sent this patch http://lists.openembedded.org/pipermail/openembedded-core/2015-April/103461.html so i guess we will see what others have to say :) Apr 08 06:32:33 that looks ok Apr 08 06:36:57 if it gets accepted the will send a follow up to remove the other setup stuff which is needed for building libffi within python Apr 08 06:42:29 why build it in python ? I assume you mean within pythong recipe Apr 08 06:47:46 sorry yep thats what i mean, as part of the python config/build flow Apr 08 06:48:12 independent is better Apr 08 06:49:22 sorry, i think i worded that wrong. I mean clean up and remove the older variable setup,etc that was used for building libffi within the python recipe (e.g. this stuff https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-devtools/python/python_2.7.9.bb#L35) Apr 08 07:16:00 good morning Apr 08 07:17:55 good morning mckoan Apr 08 07:19:05 hi nrossi Apr 08 08:35:45 hi. Is there any way to break a circular dependency loop from DEPENDS? I have (several) packages, that need each other in sysroot, but they themselves don't need to be compiled, they only both need to be copied. So sth like A -> B -> A. Since A is going to be installed, I want to modify something somewhere (a bbclass maybe, that modifies dependencies?) such that the build (bitbake) can figure out that B's dependency on A is going to be resolved already. While Apr 08 08:35:45 do_configure() of B depends on do_populate_sysroot() of A (and vice versa), removing the do_configure() tasks of A and B is still not an option, as then the dependency on do_populate_sysroot() of the depending recipe will also disappear. I also can't see me just removing B's DEPENDS on A, as my description has been simplified a little. Apr 08 08:40:16 morning all Apr 08 09:05:45 hi bluelightning Apr 08 09:06:23 hi mckoan Apr 08 10:49:23 _taw_: weisst du welcher schritt im kernel build prozess das file /include/linux/utsrelease.h generiert? Apr 08 10:49:26 oops wrong window Apr 08 10:50:47 although I can actually forward the question here since my buddy does not know, which step of the kernel build process is supposed to generate /include/linux/utsrelease.h? I am trying to hack in multiple kernels into the build and got quite far, but some minor details are still not working out Apr 08 14:12:09 ANyone have an idea how to create a new page on the OE wiki, without starting from an existing one? Apr 08 14:13:49 Crofton|work: either create a link to the nonexistent page and click on it, or just type it in as a URL Apr 08 14:13:59 ah Apr 08 14:14:17 how did you manage to do that up to now? Apr 08 14:14:48 I just added to exisitng stuff Apr 08 14:14:52 or knew and forgot Apr 08 14:15:04 I want to add training and jobs pages Apr 08 14:15:36 tryin gto figure out what category they go in :) Apr 08 14:19:19 guys, in which order are variables evaluated? can I for instance define something like FILES_${MYNAME}-dev = "blah" and preprocess the variable in some python anonymous function? or would the python part be already "too late"? Apr 08 14:23:41 ja, ich wuerd opkg update machen so wie das empfohlen wird? Apr 08 14:23:43 oops wrong window Apr 08 14:24:40 Jin^eLD: variables are expanded when they're used. Apr 08 14:25:24 kergoth: can I force some python function to run before anything else? Apr 08 14:25:25 in this case, do_package would be what makes use of that, so no, that wouldn't be too late Apr 08 14:25:36 'before anything else' doesn't makea great deal of sense Apr 08 14:25:57 well the kernel classes are doing a lot of magic which I do not fully understand yet, but basically I have a scenario where things go wrong Apr 08 14:25:59 anonymous python already runs at hte end of parsing, but before any tasks are actuallye xecuted or the runqueue prepared Apr 08 14:27:18 kergoth: https://pastebin.mozilla.org/8829213 <- my idea was to process the KERNEL_PACKAGE_NAME variable in python and then use it all around the place Apr 08 14:27:45 for instance as: FILES_${KERNEL_PACKAGE_NAME}-image = "/boot/${KERNEL_IMAGETYPE}*" Apr 08 14:28:09 my problem is that the python function seems to be running too late because the above evaluates to FILES_-image Apr 08 14:28:35 does that mean I can not "preprocess" like that? Apr 08 14:29:00 well, variable expansions inside variable names are handled completely differently than expansions elsewhere Apr 08 14:30:05 they have to be, otherwise it's entirely unclear when such names would be expanded Apr 08 14:30:10 from the code snipped, to you understand what I am trying to do (if not I'll try to explain my idea) and what would be the proper way of achieving this (if this is possible at all?) Apr 08 14:30:15 *snippet Apr 08 14:30:43 https://github.com/funman/meta-odroid Apr 08 14:32:45 kergoth: generally speaking I am trying to introduce a variable which would influence the name of the kernel ipk's and allow me to build different kernel ipk's which would be installable at the same time Apr 08 14:33:34 could you just use the existing PKG variable that lets you rename a package? Apr 08 14:33:39 it's the mechanism used by debian.bbclass Apr 08 14:33:50 PKG_${PN} = "something-i-want-to-rename-the-${PN}-package-to" Apr 08 14:34:36 kergoth: I thought that would not work for the kernel? there is a lot of magic going on with PACKAGES_DYNAMIC += "^${KERNEL_PACKAGE_NAME}-module-.*" and also some hardcoded stuff in the classes like return " ".join(map(lambda s: "kernel-module-%s%s" %.... etc Apr 08 14:35:02 good point, the deps and dynamic package names wouldn't be affected Apr 08 14:35:08 kergoth: for the kernel packages it actually does not matter what the recipe name is, the kernel.bbclass and its buddies force it to kernel-XX Apr 08 14:35:22 so I figured I had to hack into the classes Apr 08 14:35:51 to allow an optional suffix for the name, and I also have to pimp the localversion so that I get module separation in the rootfs Apr 08 14:36:22 I actually got quite far with this approach, but I'm not quite there yet Apr 08 14:37:46 I'd say just use a packagefunc to do the change at packaging time, personally Apr 08 14:38:04 but if you want the python snippet to run earlier, use an event handler at RecipePreFinalise time Apr 08 14:38:14 that'll be before the variable references in variable names are expanded Apr 08 14:38:43 oh hmm, you man just build it "as usual", maybe only tuning the local version and only hack into packaging to do all the renaming there Apr 08 14:38:54 that almost sounds easier than my approach Apr 08 14:39:15 do you happen to know an example for this handler thing, how would something like that look? Apr 08 14:39:30 grep the metadata for RecipePreFinalise? :) Apr 08 14:39:51 but there are lots of examples of event handlers in generla. in this case the event is bb.event.RecipePreFinalise rather than e.g. ConfigParsed or RecipeParsed Apr 08 14:40:39 :) Apr 08 14:40:44 ok thanks Apr 08 14:40:53 but yeah, the packaging time thing could be easier if it works, i'd prototype both Apr 08 14:41:10 see PACKAGEFUNCS in do_package for all the funcitons that get executed, you coudl inject your own at whatever point it needs to be run Apr 08 14:41:13 I think I'll give the packaging time thing a try first beforeI continue Apr 08 14:41:17 * kergoth nods Apr 08 14:41:25 cool, thanks a lot Apr 08 14:42:00 all that said, you might email oe-core to see if there's interest in this feature, and just submit a direct modification of kernel.bbclass upstream, instead of trying to postprocess after the fact :) Apr 08 14:43:04 well, the modification would be my hack-approach :) I actually asked around and it seems the feature was being asked for but noone is really working on it yet Apr 08 14:43:17 ah, fair enough Apr 08 14:43:44 I did not consider my knowledge good enough to implement it cleanly but I was planning to send my hack for review and get some feedback if this was any direction that upstream would have interest in Apr 08 14:43:53 cool Apr 08 14:44:24 now you kind of sabotaged that by the packagefunc approach ;) Apr 08 14:44:40 because it indeed seems a lot easier if it works Apr 08 14:45:25 hehe. let me know how it goes Apr 08 14:46:09 will do =) Apr 08 14:46:33 if it does we could probably still come up with some class and a bunch of config variables that would handle the injection Apr 08 15:37:56 kergoth: packagefuncs alone won't be sufficient :( have still to tune kernel class due to deployment of the kernel images Apr 08 15:38:23 so tying a combined approach now, with minimum changes in kernel.bbclass Apr 08 15:43:14 ah, right. makes sense Apr 08 15:43:17 forgot about do_deploy Apr 08 15:44:26 too many things are playing together here, I guess thats what makes it so difficult, I actually spent a couple of days on the bbclass hacking approach Apr 08 15:45:09 heh, that's typical. power and flexibility means there are always many ways of working toward hte same goal, can lead to confusion about the best approach Apr 08 15:45:15 or if there even is a best approach Apr 08 15:45:20 yeah... **** ENDING LOGGING AT Thu Apr 09 02:59:58 2015