**** BEGIN LOGGING AT Thu Jul 16 02:59:59 2015 Jul 16 06:57:07 hi folks Jul 16 06:57:19 i have an x86_64 machine Jul 16 06:57:33 i am running linux-yocto on it Jul 16 06:58:00 I tried the system with the standard kernel type but now I would like to give preempt-rt a try Jul 16 06:58:35 i thought it would just be a matter of changing the -standard.scc to -preempt-rt.scc Jul 16 06:58:44 but that did not suffice Jul 16 06:59:59 I then updated the KBRANCH from standard/common-pc-64/base to standard/preempt-rt/base Jul 16 07:00:15 but now I am getting patch time failures Jul 16 07:00:30 any pointers will be really helpful Jul 16 07:04:24 ? Jul 16 07:04:49 you need to recompile the kernel with a diffrent config Jul 16 07:05:15 abelal where did you get the machine from? Jul 16 07:05:24 and maybe #yocto is more sufficient Jul 16 07:06:04 woglinde: it is a custom machine, i will hop on to #yocto as suggested, thanks Jul 16 07:09:43 abelal I never saw a .scc sofar Jul 16 07:53:12 good morning Jul 16 07:53:31 hi Marco Jul 16 08:03:24 hi Marcin Jul 16 08:12:04 hi mckoan and hrw Jul 16 09:25:13 morning all Jul 16 13:42:15 kergoth: awesome, thanks for your reply! it reassures me that i'm not going crazy ;-P Jul 16 13:42:59 but it does seem a bit "restrictive" to assume that for any given board there is only one kernel that is available/correct? Jul 16 13:43:50 specifically i'm working with the firefly board. like most boards, by default the firefly boots from eMMC and falls back to uSD Jul 16 13:44:16 for various reasons, if you boot from eMMC it's best to use the vendor's kernel, but if you boot from uSD you can use upstream Jul 16 13:44:51 one gentleman has already created meta-rockchip and added support for a uSD image using upstream, but i'd like to add to his work and create an image for the eMMC using the vendor kernel Jul 16 13:45:08 so yes, based on what image you build, i want to use a different kernel Jul 16 13:45:19 and i don't want to leave it up to the user to specify in their conf/local.conf Jul 16 13:45:56 it's bad enough that "MACHINE" really means "what board are you using", now I have to further bend the definition to mean "what image you do you want to build?" Jul 16 13:53:46 tlwoerner: what's the context here? I guess I missed the other half of the discussion Jul 16 13:53:54 perhaps I should just check the logs :) Jul 16 14:10:09 so hot Jul 16 14:10:22 where? Jul 16 14:10:28 Missouri Jul 16 14:10:32 camping this week Jul 16 14:10:36 Caving Convention Jul 16 14:11:48 us or europe camping? Jul 16 14:11:51 *g* Jul 16 14:13:46 or better with a tent or a trailer? Jul 16 14:15:57 JaMa: logging patches just landed FYI Jul 16 14:16:15 .us Jul 16 14:16:33 Ridiculously hot Jul 16 14:16:37 need to go in a cave Jul 16 14:22:12 bluelightning: i was trying to set PREFERRED_PROVIDER_virtual/kernel in a recipe in recipes-core/images/myimage.bb Jul 16 14:22:32 and the build was completely oblivious to it ;-) Jul 16 14:22:50 tlwoerner: ah right yes, that indeed won't work Jul 16 14:23:17 so today i'll just create a new machine definition and go from there Jul 16 14:23:47 it's a tricky problem because the kernel is a build dependency of a number of parts of the system, so even if that did work it would be hard to swap out at the image level Jul 16 14:24:58 interesting, kergoth described it as a variable that "controls scheduling" which i thought was an interesting way of looking at it Jul 16 14:30:36 bluelightning: cool, thanks, I've already rebased my jansa/master branches Jul 16 14:30:56 tlwoerner: strictly, it controls who should satisfy dependencies on "the kernel" when resolving dependencies Jul 16 14:31:13 kind of scheduling, but not really Jul 16 14:34:26 :-) Jul 16 14:52:58 one aspect of runqueue generation, i should have said Jul 16 14:54:18 tlwoerner: it sounds like what you might want, given how the system works, would be a kernel recipe that emits multiple kernel binaries with slightly different configurations. u-boot can already do this in some bsps for different board configurations. then you can pick the one you want with whatever image you want Jul 16 14:54:21 * kergoth shrugs Jul 16 14:54:22 * kergoth gets caffeine Jul 16 14:58:02 kergoth: very interesting, that sounds like the ideal solution Jul 16 15:03:01 In meta-fsl-ppc/conf/machine/t1024rdb.conf: UBOOT_MACHINES ?= "T1024RDB T1024RDB_NAND T1024RDB_SDCARD T1024RDB_SPIFLASH T1024RDB_SECURE_BOOT" Jul 16 15:03:13 see UBOOT_CONFIG & UBOOT_MACHINE in meta/classes/uboot-config.bbclass & meta/recipes-bsp/u-boot/u-boot.inc as well for how it's done for uboot Jul 16 15:03:27 * kergoth yawns Jul 16 15:52:45 kergoth: weird! in the machine file the variable is defined as "UBOOT_MACHINES" (with an 'S') but in the bbclass it looks for "UBOOT_MACHINE", that works?! Jul 16 15:56:36 iirc the meta-fsl-ppc recipe uses the plural one, or defines the non-plural using the plural, or somesuch, i don't recall offhand Jul 16 20:36:11 RP, hello, I work with otavio, and we are responsible for this: http://patchwork.openembedded.org/patch/93891/ Jul 16 20:36:15 RP, regarding that change you said that a shared lock could be released by the first exiting process. But that would only apply to one of the shared locks on the same file (since it is "shared"). Jul 16 20:36:21 RP, all the other processes still running, including the cooker, would still retain the shared lock, and it would only be released after all process released it explicitly or by exiting. Jul 16 20:36:45 RP, Also, forking doesn't give control of the lock to the child process. It has to be explicitly adquired after the fork. Jul 16 20:36:52 RP, so I don't understand how the atexit approach would cause some problems. Could you explain me that? Jul 16 20:38:26 ldnunes: when you call unlock there, it will unlock for all the forked processes in memory Jul 16 20:39:08 ldnunes: there are now http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=3b5b74b430f0c62bcb4bbbcce02b18f2cb12d336 (and preceeding two patches) which may help Jul 16 20:40:16 RP, but how? Wouldn't that be a huge security risk to have a process releasing a lock for another? Jul 16 20:41:44 ldnunes: currently, they all hold the fd open and the lock is released when all fds close. If you release the lock the open fds don't matter Jul 16 20:42:41 ldnunes: I'm not 100% convinced the other code is safe either :( Jul 16 20:43:53 RP, I see... If I provide you with a proof-of-concept that our code would work would you consider accepting it? Jul 16 20:44:19 ldnunes: as I said earlier, I believe the problem you're trying to fix is already fixed differently Jul 16 21:05:39 bluelightning: I think we have an inconsistency in layerindex metadata. meta-ruby's layer.conf from dizzy specifies "core" and "openembedded-layer" as dependencies. However, as far as I can see, layerindex metadata says the only dependency is "core". Jul 16 21:06:27 IIUC, layerbranch 56183 corresponds to meta-ruby on dizzy, and there's only one dependency for it in http://layers.openembedded.org/layerindex/api/layerDependencies/ (openembedded-core) Jul 16 21:18:39 rburton: ping Jul 16 21:22:23 rburton: unping :D Jul 16 21:32:49 mario-goulart: the layer index doesn't pick those things up automatically - the maintainer needs to set them Jul 16 21:32:56 mario-goulart: I can add things if needed though Jul 16 21:50:27 phako: glad i could help Jul 16 21:51:16 not sure you could, I was going to ask sth about the gupnp debian packages Jul 16 21:51:23 but then google to the rescue Jul 16 21:56:23 oh god i've not touched those for ages Jul 16 21:56:40 my debian keys are so old they got removed from the keyring Jul 16 22:11:24 rburton: while being here, would it help you guys packaging newer versions of GUPnP/Rygel if I add the .vapi files to the release tarballs? Jul 16 22:14:48 phako: probably, yes Jul 16 22:17:09 bluelightning: oh, I thought the dependencies were programmatically obtained from layer.conf. Jul 16 22:19:43 it checks yes if you specify otherwise it assumes Jul 16 22:40:53 bluelightning: can you please add a dependency on meta-oe for meta-ruby? Jul 16 22:42:56 mario-goulart: done Jul 16 22:43:42 mario-goulart: ideally we would pick those up programmatically, hopefully that can be added in future Jul 16 22:47:51 bluelightning: thank you. Jul 16 22:56:40 when my kernel recipe goes to build it cd's into .../$PN/$PV/build, but there's nothing in "build" my kernel sources are in .../$PN/$PV/git, i've even specified this in my recipe: "S = ${WORKDIR}/git" Jul 16 22:57:32 this is all controlled by openembedded-core/meta/classes/kernel.bbclass's kernel_do_compile() Jul 16 22:58:07 how can i get kernel.bbclass to find my sources in "git" and not look in "build"? Jul 16 22:58:51 build doesn't need sources. Jul 16 22:58:58 the kernel supports separating the source and build directory Jul 16 23:00:14 is there a "brokensep" option? ;-) Jul 16 23:00:50 ok, it's a vendor kernel, i'll look into separate S and B's Jul 16 23:00:54 doubtful given the rework to how the kernel is built. and the kernel was always supposed to support out of tree builds, if it's not working, it's probably trivial to fix Jul 16 23:01:01 but yo ucould alwyas try B = ${S} Jul 16 23:01:07 which is all autotools-brokensep does under the hood anyway :P Jul 16 23:01:13 awesome, thanks! Jul 16 23:06:10 kergoth: awesome, as a hack that worked. i'll look into properly separating it out though Jul 16 23:06:38 nice Jul 16 23:07:20 but first, the farm chores are waiting ;-) **** ENDING LOGGING AT Fri Jul 17 02:59:58 2015