**** BEGIN LOGGING AT Mon Oct 07 02:59:58 2013 Oct 07 08:04:42 good morning Oct 07 08:34:12 morning Oct 07 08:56:46 morning RP, all Oct 07 09:39:12 Hi everybody. I've got a problem in overridding asound.conf in alsa-state: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-bsp/alsa-state/alsa-state.bbappend Oct 07 09:40:02 I've got my own private layer, but I can't get a proper bbappend to override those asound.conf. Any hints? Both these fail: Oct 07 09:41:20 http://pastebin.com/YJuFeXJP Oct 07 09:42:08 http://pastebin.com/s1RJFkzf Oct 07 09:42:21 Thank you for any help you might give me! Oct 07 09:51:07 panda84kde: you don't need to change SRC_URI since it already has the file in it Oct 07 09:51:20 panda84kde: have you tried making it machine specific and using the machine name? Oct 07 09:52:06 panda84kde: I assume mx6 is in overrides, it looks like you're doing the right things in the second one... Oct 07 09:55:43 RP: thank you. where do I check the override? Oct 07 09:59:24 panda84kde: bitbake -e | grep OVERRIDES ? Oct 07 10:01:52 it's there MACHINEOVERRIDES="armv7a:mx6:mx6q:nitrogen6x" Oct 07 10:04:04 panda84kde: that should get added to OVERRIDES too Oct 07 10:04:19 panda84kde: is there a machine or arch specific file in another layer? Oct 07 10:04:45 panda84kde: looking in the logs might reveal the directories its searching for the file Oct 07 10:10:04 RP: yes, it's in the original http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-bsp/alsa-state/alsa-state.bbappend Oct 07 10:11:34 panda84kde: I suspect your layer is at a lower priority than that one or at the wrong point in BBPATH Oct 07 10:11:58 panda84kde: either change the layer order in bblayers.conf or make your state file machine specific Oct 07 10:18:09 RP: thank you. What's the best syntax to override asound.conf for my machine "nitrogen6x"? Oct 07 10:19:46 panda84kde: replace mx6 with your machine name Oct 07 10:19:59 in both directory name and the PACKAGE_ARCH line Oct 07 10:22:02 RP: Is there a way to protect a bitbake variable (or actually a number of variables, all starting with the same prefix) from OVERRIDES expansion? Oct 07 10:23:59 hello Oct 07 10:24:34 I have a receipt (chromium-unittest) which needs to fetc 2 tarballs 1: chromium, 2: chromium-testdata Oct 07 10:24:52 how to deal with 2 different md5sums for that particular case? Oct 07 10:26:36 Saur: not really Oct 07 10:27:26 mbelisko: you assign them each names Oct 07 10:27:33 mbelisko: there are examples in the metadata Oct 07 10:27:57 RP: ok thanks Oct 07 10:29:59 RP: Bother. We have a lot of old configuration variables from our old build system that a lot of our packages still expect. So what we have done is turned them all into bitbake variables, which has worked fine until I set the SOC_FAMILY variable to match our chip. Unfortunately, two of the config variables ends in _ which all of a sudden was removed due to SOC_FAMILY being in MACHINE_OVERRIDES (which was the whole point of setting it up, but Oct 07 10:30:45 Saur: you could set the variable after the data is finalised in an event handler? Oct 07 10:31:09 RP: strange: this still doesn't work http://pastebin.com/HkrjaWKe Oct 07 10:31:15 Saur: or explicitly export the variable in the specific task? Oct 07 10:31:55 RP: Problem is that the config variables varies per MACHINE. Oct 07 10:32:17 panda84kde: try FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}/${MACHINE}:" Oct 07 10:32:58 Saur: but you can use the value of ${MACHINE} ? Oct 07 10:33:32 do_compile_prepend () { export somevar_${MACHINE}=xyz } ? Oct 07 10:33:43 RP: Now I think you lost me somewhere. (my bitbake knowledge is quite limited). Oct 07 10:36:01 Saur: where do you need these variables? shell tasks? python tasks? just configure/compile? Oct 07 10:36:25 do_compile_prepend () { export somevar_${SOC_FAMILY}=xyz } ? Oct 07 10:36:27 RP: Well, the config values are read from text files, one per machine, and then converted to bitbake variables with some python code... Oct 07 10:37:07 Saur: and where are they used? Oct 07 10:37:17 Saur: could you put escaping in? Oct 07 10:37:37 How do you mean? Oct 07 10:38:40 change "_" to say "U" when reading them in, then when exporting the them translate back Oct 07 10:39:19 There are probably a few ways to make it work but it all depends on what your constraints are Oct 07 10:39:45 RP: Hmm, possibly. Will have to think about that. It could be an option... Oct 07 10:42:12 RP: The stupid thing is that in the end we want to get rid of them all together, as their use causes the packages that use them to become machine specific... But for now we have to keep them as there are so many of them, and the people who need to remove the dependencies are our code owners who are outside the project working on switching to bitbake... Oct 07 10:43:16 Saur: could you just read them in late, i.e. when the task is due to run? Oct 07 10:43:59 do_configure () { ${@readinvariables()} } ? Oct 07 10:44:31 where the function returns "x=y\ny=z\n" Oct 07 10:45:55 RP: Well, the idea with turning them into bitbake variables is that they should affect the sstate so that things are rebuilt if they change (which they do). Oct 07 10:47:08 Saur: fair enough. Its hard for me to comment without knowing all the constraints :/ Oct 07 10:47:53 RP: I know. Was mostly hopping for an IGNORE_OVERRIDES or something like that... ;) Oct 07 10:48:32 Oh well, gotta get some lunch... Oct 07 10:52:43 RP: it still doesn't work. The file is in the correct path with or without /${MACHINE} but I in the log the meta-fsl-arm path is preceding my layer path Oct 07 10:52:47 Saur: you could probably write some kind of event handler post data expansion which resets the variable to its original name Oct 07 10:53:01 Is lowering priority of the layer the only remaining option? Oct 07 10:53:20 panda84kde: did you try reordering the layers in bblayers.conf ? Oct 07 10:54:45 RP: trying now. But ordering in bblayers is not the same thing as layer priority, right? Oct 07 10:55:06 panda84kde: no, I can't remember offhand how they all fit together either :/ Oct 07 10:56:03 panda84kde: the appends get stacked in the order they're parsed which depends on the order things are added to BBFILES in layer.conf iirc Oct 07 10:57:29 RP: changing order in bblayers doesn't affect the final result Oct 07 10:58:39 panda84kde: I don't understand why making it machine specific doesn't override the mx6 entry regardless :/ Oct 07 10:58:40 * panda84kde thinks Yocto is a good project, but some things are really too obscure and undebuggable. Oct 07 10:59:10 RP: me too I'm a bit perplexed Oct 07 10:59:23 panda84kde: the trouble is everyone wants the maximum flexibility but that comes at a price :/ Oct 07 11:01:20 my really humble opinion is that it's getting quite complicated and bash programming is not as flexible as the project needs. Oct 07 11:03:26 panda84kde: bash programming ? Oct 07 11:04:01 panda84kde: I just took a look at some logs for fetch against alsa-state. I believe there is a bug that its processing overrides backwards :( Oct 07 11:04:22 panda84kde: it searches arm, armv5, qemuarm Oct 07 11:04:28 it should go the other way :( Oct 07 11:05:12 panda84kde: bitbake alsa-state -e | grep FILESPATH and you'll see what I mean Oct 07 11:07:36 RP: Hmm, I do not know very much about the event handling in bitbake. What kind of event should I look for? Oct 07 11:10:57 RP: ok, I know bb recipes are not in bash, but variables and other things are handled pretty much in shell style Oct 07 11:12:57 VARIABLE += "blah \ blah \ blah" Oct 07 11:13:26 instead of list.add("blah").add("blah").add("blah") Oct 07 11:17:51 RP: my "bitbake alsa-state -e" + my log.do_fetch http://pastebin.com/D3uk9470 Oct 07 11:18:15 no armv5 nor qemuarm Oct 07 11:20:01 panda84kde: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2 Oct 07 11:20:12 panda84kde: try applying that fix... Oct 07 11:20:44 panda84kde: you didn't see those because you're not using qemuarm, I just used qemuarm as a local test Oct 07 11:21:15 panda84kde: I'm pretty sure the core function is broken, it should do more what you expect after the above patch is applied Oct 07 11:22:08 RP: I'll test it immediately Oct 07 11:22:11 thank you Oct 07 11:23:56 Saur: have a look at multilib_global.bbclass:multilib_virtclass_handler_global[eventmask] = "bb.event.RecipePreFinalise bb.event.RecipeParsed" Oct 07 11:24:08 Saur: you could hook the RecipeParsed event Oct 07 11:25:18 RP: Ok, will try that... Oct 07 11:29:18 RP: If I modify the variables in that event (simle idea is to read them in, change all _ to something else, and then revert to _ in the event), will they still affect the sstate as expected? Oct 07 11:30:09 RP: ok, now the order seems to be reversed (and correct): nitrogen6x, mx6q, mx6, armv7a, arm Oct 07 11:30:27 but I still get the wrong asound.conf :S Oct 07 11:31:52 Saur: probably not as you'd like :/ Oct 07 11:32:16 panda84kde: with which bbappend exactly? Oct 07 11:32:28 RP: So, back to square one... Oct 07 11:33:07 Saur: well, you could just use the event handler to restore the corrupted variables Oct 07 11:35:14 RP: tried with this one: http://pastebin.com/HkrjaWKe Also tried with FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}/${MACHINE}:" but the result was the same Oct 07 11:35:15 RP: Btw, the OVERRIDES mechanism, does it affect the variable name anywhere, or just at the end? E.g., if foo is in OVERRIDES, will VAR1_foo_VAR2 turn into VAR1_VAR2? Oct 07 11:35:36 Saur: just endings Oct 07 11:35:46 RP: ok Oct 07 11:36:20 in both cases in log.do_fetch the asound.conf is present in the folders listed, it's just that this: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-bsp/alsa-state/alsa-state.bbappend takes precedence Oct 07 11:38:29 panda84kde: read the do_unpack log. I think there is also a bug in the alsa-state recipe :/ Oct 07 11:39:18 panda84kde: well, an unintended side effect of having ${PN} as a file in SRC_URI Oct 07 11:39:32 * panda84kde has a lucky day Oct 07 11:40:44 panda84kde: Its treating "alsa-state" as a directory and ocopying the contents over ${WORKDIR} Oct 07 11:40:52 thereby overwriting your changes afaict Oct 07 11:44:57 panda84kde: Try http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=96dab59a53a546d5fcbeed263170c56c9b03d137 Oct 07 12:10:45 RP: I git a tip from a co-worker. How about I append "_${SOC_FAMILY}" to all my variable names. Then the OVERRIDES mechanism will remove it again, and leave the original name in place. Right? Oct 07 12:10:50 got* Oct 07 12:11:38 Saur: I'm not entirely sure what that would do Oct 07 12:12:21 RP: Well, then the var that I want to protect would be VAR_foo_foo, which would become VAR_foo after OVERRIDES has done its deed. Oct 07 12:13:00 Saur: well, yes, assuming we don't expand overrides multiple times Oct 07 12:13:11 RP: Do you? Oct 07 12:42:41 Is there any way that file.cfg can be ignore during bitbake my kernel? (For exemple do_configure_prepend() { if [ ! -f "${B}/.config" ]; then Oct 07 12:42:41 oe_runmake filedefconfig Oct 07 12:42:41 fi? ) Oct 07 13:09:49 should I remake my question? Oct 07 13:21:01 Saur: it can happen in some contexts Oct 07 13:21:11 Saur: not sure if it happens in general or not Oct 07 13:21:25 RP: Yeah, it seems so. If I add _ff Oct 07 13:21:30 bah Oct 07 13:22:00 RP: If I add _foo_foo to my var VAR_foo, it will come out in the end as I want... Oct 07 13:24:05 RP: Interesting though is that VAR_foo_foo is left in d but without value (it doesn't show in bitbake -e, but in the construct we use to get all our variables, it does): for key in [x for x in d if x.startswith("OUR_PREFIX_")]: vars[key] = d.getVar(key) Oct 07 13:24:44 RP: Btw, is d and getVar() documented anywhere? Oct 07 13:25:23 RP: I see them and a lot of similar stuff all over the python code, but can't seem to find any real documentation of them... Oct 07 13:26:34 Saur: bitbake manual is as close we get Oct 07 13:26:50 RP: Well, I looked there... Oct 07 13:27:12 RP: I assume d is some global variable state? Oct 07 13:27:23 Saur: its the datastore Oct 07 13:27:38 RP: What's the True/False argument to getVAR() for? Oct 07 13:27:39 Saur: basically everything is in there as key/value pairs Oct 07 13:28:36 Saur: expand or not expand Oct 07 13:34:03 RP: Ah, whether ${...} should be expanded or not, right? Oct 07 13:34:36 Saur: yes Oct 07 13:35:26 (Hah, I finally found the code for it as well. At least in theory that should make things easier...) Oct 07 13:38:34 RP: Hmm, the question now is, can I rely on the overrides expansion taking place twice to remain, or what are the odds of that changing... Oct 07 15:00:55 if I want to create Yocto repository of packages - do I do 'bitbake world' ? Or there is some simplier command (less time consuming)? Oct 07 15:03:35 Krz-: depends what you want the repository to contain Oct 07 15:03:39 Krz-: "world" is really intended for validation; you probably want to be more selective Oct 07 15:04:04 Krz-: I'd suggest creating a "meta" recipe that has the list of recipes you wish to build in its DEPENDS Oct 07 15:04:23 (along with "inherit meta") Oct 07 15:09:41 bluelightning: I looked at what that class did with a certain amount of dread! Oct 07 15:10:14 heh Oct 07 15:10:57 hasn't been changed in quite some time Oct 07 15:10:59 bluelightning: rburton: I want my repo to contain all Yocto packages present in layers I use Oct 07 15:11:14 Krz-: that would be world then Oct 07 15:11:49 rburton: thanks Oct 07 15:12:02 RP: I got a bit strange request to upgrade bitbake to 1.20 (for _remove feature and some cache fixes) in our dylan builds, is backporting some oe-core changes needed for newer bitbake to dylan release out of question or should I try to identify them and then we'll see? Oct 07 15:12:44 off hand I know about http://git.openembedded.org/openembedded-core/commit/?id=491fde8cd3fd493f9fec2fd434fe1be547f66148 and http://git.openembedded.org/openembedded-core/commit/?id=835b64d4e9ed7b627b56a75d529f1a403c5db1a8 Oct 07 15:14:46 JaMa: Its a fairly big deviation from the stated policy which is not to backport features :/ Oct 07 15:17:03 agreed, that's what I said on that request, but if they still insist then I'll probably have to backport it locally without trying to upstream the backport Oct 07 15:18:48 * JaMa bbl Oct 07 15:36:43 anybody know the uid/gid range? Oct 07 15:37:10 for users that is Oct 07 15:45:36 j8: 1000 and up **** ENDING LOGGING AT Tue Oct 08 02:59:59 2013