**** BEGIN LOGGING AT Wed Mar 20 02:59:58 2013 Mar 20 05:55:37 Cannot find feature qt_build_config Mar 20 05:56:03 but it is present in sysroots/usr/lib/mkspecs Mar 20 05:56:41 i m assigning this path to qt_configure_data variable Mar 20 08:57:10 good morning Mar 20 09:11:53 hello Mar 20 09:20:54 morning hrw, all Mar 20 09:54:36 Hello Mar 20 12:21:41 I am having error that pkgdata folder is not created Mar 20 12:22:20 I know this is generated ion do_package task but can someone point me to the exact place Mar 20 13:06:39 I am trying to use alternatives system to provide one file by different sub packages of a single recipe Mar 20 13:06:52 (linux-firmware in this case) Mar 20 13:09:20 'k.. Mar 20 13:09:31 the docs for how to use the update-alternatives are at the top of that class Mar 20 13:34:16 fray: yes Mar 20 13:34:30 fray: but I am having a bad time to get it working as I expect Mar 20 13:34:45 what is it doing that you aren't expecting Mar 20 13:35:06 fray: http://pastebin.com/QrLX9yBk Mar 20 13:35:12 fray: this is my current bbappend Mar 20 13:35:50 looking Mar 20 13:36:02 fray: the driver needs to have a specific name of the firmware Mar 20 13:36:20 fray: so I'd like to have all possible alternatives packages Mar 20 13:36:28 fray: and it be solved at runtime Mar 20 13:37:10 the 'brcmfmac-stdio.bin' says that is the 'alternative name'.. Mar 20 13:37:26 fray: which line? Mar 20 13:38:33 sorry just a sec.. too many things at once Mar 20 13:39:43 The ALTERNATIVE_--- is that name of the item for use within the alternatives system.. the system will match that name and say only one of those items is allowed to exist at the same time.. Mar 20 13:40:01 the ALTERNATIVE_LINK_NAME is what the -target- of the link is.. i.e. Mar 20 13:40:08 /bin/mytest -> /bin/[ Mar 20 13:40:15 the LINK_NAME is the /bin/[ Mar 20 13:40:23 the 'target' is the /bin/mytest Mar 20 13:40:46 the alternatives system ensures that for each 'alternative', the 'link_name' must be the same or an error is generated (at runtime) Mar 20 13:41:03 so the only problem I see here is that the LINK_NAME's need to all be the same Mar 20 13:41:22 fray: so I'd drop the target? Mar 20 13:41:49 the target is the alternative file.. Mar 20 13:41:54 fray: or the LINK Mar 20 13:42:04 in this case you need all thtree.. but in each case the ALTERNATIE_LINK_NAME's need to be the same.. most likely: Mar 20 13:42:19 /lib/firmware/brcm/brcmfmac-sdio.bin Mar 20 13:42:29 example: Mar 20 13:42:37 ALTERNATIVE = "bracket" Mar 20 13:42:44 ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/[" Mar 20 13:42:54 ALTERNATIVE_TARGET[bracket] = "/bin/busybox" Mar 20 13:43:16 that says you are installing 'busybox', but you want it to be linked to /usr/bin/[ Mar 20 13:43:31 other alternatives must have the same name 'bracket' and the same LINK_NAME /usr/bin/[ Mar 20 13:44:15 ALTERNATIVE_${PN}-bcm4330 = "brcmfmac-sdio" Mar 20 13:44:19 ALTERNATIVE_LINK_NAME_${PN}-bcm4330[brcmfmac-sdio] = "/lib/firmware/brcm/brcmfmac-sdio.bin" Mar 20 13:44:22 ALTERNATIVE_TARGET_${PN}-bcm4330[brcmfmac-sdio] = "/lib/firmware/brcm/brcmfmac4330.bin" Mar 20 13:44:24 line this? Mar 20 13:44:36 (if link_name and target is the same, then it will rename the target) Mar 20 13:44:51 yes.. that looks right Mar 20 13:45:53 fray: testing Mar 20 13:59:58 fray: http://pastebin.com/nmQfenKP <= recipe / http://pastebin.com/F4kYi28v <= log Mar 20 14:00:17 looking Mar 20 14:01:05 the warning is the linka nd target are the same.. Mar 20 14:01:48 and the path listed isn't th ight one at all... Mar 20 14:01:58 ohh duh.. Mar 20 14:02:01 ALTERNATIVE_LINK_NAME_${PN}-bcm4329[brcmfmac-sdio.bin] = "/lib/firmware/brcm/brcmfmac-sdio.bin" Mar 20 14:02:04 ALTERNATIVE_TARGET_${PN}-bcm4329[brcmfmac-sdio.bin] = "/lib/firmware/brcm/brcmfmac4329.bin" Mar 20 14:02:17 it's -just- ALTERNATIVE_LINK_NAME[brcmfmac-sdio.bin] Mar 20 14:02:42 these are specific to the recipe, not the package.. only LATERNATIVE is specific to the package Mar 20 14:02:59 mind you, it should have worked.... Mar 20 14:04:07 * fray looks a bit further Mar 20 14:06:18 alt_target = d.getVarFlag('ALTERNATIVE_TARGET_%s' % pkg, alt_name, True) or d.getVarFlag('ALTERNATIVE_TARGET', alt_name, True) Mar 20 14:06:18 alt_target = alt_target or d.getVar('ALTERNATIVE_TARGET_%s' % pkg, True) or d.getVar('ALTERNATIVE_TARGET', True) or alt_link Mar 20 14:06:40 so that is right.. it's looking the package version.. but I think there is a bug above that... Mar 20 14:06:49 d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, alt_link) Mar 20 14:07:07 or not.. hmm.... Mar 20 14:07:59 fray: but it ought to be right? Mar 20 14:08:30 I'm looking still it's supposed to work with the ${PN}-bcm... but I don't think anyone else has done that before.. Mar 20 14:08:50 most of the time, only the LATERNATIVE_ needs the package setting, the others are just specified in a list Mar 20 14:09:39 fray: http://pastebin.com/RhwTQEgg Mar 20 14:09:48 fray: does not work as well Mar 20 14:11:36 still getting the errors it can't find brcmfmac-sdio.bin? Mar 20 14:11:47 yes Mar 20 14:12:03 ya, that error means that ALTERNATIVE_TARGET didn't get processed.. since that is the target.. Mar 20 14:12:09 not the link..... Mar 20 14:13:13 So? Mar 20 14:13:27 still looking Mar 20 14:13:32 ah Mar 20 14:13:48 I thought you had find I were doing it wrong Mar 20 14:14:26 it's not obvious to me that you have anything wrong "anymore".. the first version you showed me was incorrect, but the later isn't Mar 20 14:14:35 soemthing odd is happening with the package name.. Mar 20 14:16:18 fray: can you try to reproduce it there? Mar 20 14:16:32 fray: so we may debug it Mar 20 14:16:35 if you send me your reproducer, I should be able to in about 45 minutes.. Mar 20 14:16:41 I'm stuck on a meeting until then Mar 20 14:16:58 fray: the .bbappend file is as I pasted Mar 20 14:17:03 but, there has to be something wrong in the python of the update-alternatives.. both the checking and configuring.. Mar 20 14:18:07 fray: ok; let me undertand the logic here (so I can debug it) Mar 20 14:18:23 ALTERNATIVE_LINK_NAME[brcmfmac-sdio.bin] = "/lib/firmware/brcm/brcmfmac-sdio.bin" Mar 20 14:18:58 defines an alternative 'brcmfmac-sdio.bin' which will '/lib/firmware/brcm/brcmfmac-sdio.bin' Mar 20 14:19:06 yes Mar 20 14:19:09 s/will/will be/ Mar 20 14:19:21 ALTERNATIVE_TARGET_${PN}-bcm4329[brcmfmac-sdio.bin] = "/lib/firmware/brcm/brcmfmac4329.bin" Mar 20 14:19:32 say's it will point to 4329.bin file Mar 20 14:19:47 correct.. Mar 20 14:20:32 quick summary of what is happening.. the __anonymous function goes though and handles the deprecated stuff (changing hte old format to the new format), making sure the vardeps is right, and then adding the include to virtual/update-alternatives Mar 20 14:21:12 perform_packagecopy, what this does is actually setup the link during the packagecopy step.. as part of this it will rename the target, if the link == target.. the new name is target.${BPN} Mar 20 14:21:47 populate_packages_updatealternatives -- this is supposed to do the pre/post install/rm scripts Mar 20 14:22:26 package_do_filedeps_append -- this adds each alternative to the per-filedependcies... Mar 20 14:22:42 most likely there is a bug in the perform_packagecopy, and perhaps in the others.. but I'd start there first Mar 20 14:23:10 Ok Mar 20 14:23:12 will check it Mar 20 14:23:28 when you get out of meeting please ping me Mar 20 14:23:30 so we sync Mar 20 14:23:31 :) Mar 20 14:25:28 will do Mar 20 14:50:47 fray: I found the bug Mar 20 14:50:52 fray: but not how to fixe Mar 20 14:50:57 what is it? Mar 20 14:51:05 I hope my call is almost over Mar 20 14:51:38 fray: d.getVarFlags returns none Mar 20 14:52:12 bb.warn("DEBUG: %s flags %s" % ('ALTERNATIVE_TARGET_%s' % pkg, d.getVarFlags('ALTERNATIVE_TARGET_%s' % pkg))) Mar 20 14:52:33 outputs as: ARNING: DEBUG: ALTERNATIVE_TARGET_linux-firmware-bcm4329 flags None Mar 20 14:53:08 can you try this in yoru recipe: Mar 20 14:53:26 ALTERNATIVE_TARGET_linux-firmware-bcm4329[...] = "..." instead of using ${PN}? Mar 20 14:53:34 sure Mar 20 14:54:36 fray: heh Mar 20 14:54:40 fray: you got it Mar 20 14:54:45 fray: not using PN works Mar 20 14:54:50 damnit.. but in bitbake Mar 20 14:55:09 I hit this before with a flag.. only it was the in the form: Mar 20 14:55:17 FOO[BAR_${VAR}] = "..." Mar 20 14:55:28 the items in the brackets are never expanded.. Mar 20 14:55:34 but the stuff outside SHOULD be Mar 20 14:55:54 fray: were I can start looking for it? Mar 20 14:56:06 I happen to know where the code is that does the expansion.. ;) Mar 20 14:56:13 since I was screwing with it yesterday Mar 20 14:56:22 * fray finds it Mar 20 14:57:31 lib/bb/data.py, search for 'expandKeys' Mar 20 14:57:54 the function sets up a 'todolist', and then does the expansion.. my guess is that either the 'renameVar' call at the end, or the todolist is wrong Mar 20 14:58:05 the renameVar is NOT implemented in the data.py, that is in the data_smart.py.. Mar 20 14:58:15 (there is a renameVar in data.py, but it's something else) Mar 20 15:02:31 fray: yes the key in alterdata is not expanded but others are Mar 20 15:07:35 thats the bug.. I have no idea what to do about it.. Mar 20 15:07:59 it 'might' be reasonable to work backports.. I'd look at the expansion routine and the 'todo' stuff and see if I could figure out if the key is even in the list Mar 20 15:09:11 rename: ALTERNATIVE_TARGET_${PN}-bcm4334 ALTERNATIVE_TARGET_linux-firmware-bcm4334 Mar 20 15:09:20 fray: it is calling it right Mar 20 15:12:26 hmm.. then I'm wondering if the values aren't getting tranfered.. (flag values) Mar 20 15:12:58 is "everyone" at danny now? I see there are still occasional commits to denzil. Mar 20 15:13:25 we still have product on denzil.. and due to the YP compatibility requirements, we have to post fixes/updates to the list.. Mar 20 15:13:40 if they are not applicable to danny/master, then we post with the denzil.. but frankly we expect they'll be ignored for the most part Mar 20 15:14:18 fray: what does YP mean? Mar 20 15:14:34 https://www.yoctoproject.org Mar 20 15:14:40 ah Mar 20 15:15:05 https://www.yoctoproject.org/webform/yocto-project-compatible-registration Mar 20 15:15:22 see the checklist.. "Have all pathes applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? Mar 20 15:16:07 we prefer to send patches for master, then danny then denzil.. depending on applicability Mar 20 15:16:29 I see. I'm using the angstrom setup scripts now, but plan moving to yocto soon. Now I was just wondering if I should base a new release on denzil or danny. Mar 20 15:16:58 denzil is 1.2 and won't be supported after the upcomign 1.4 release.. Mar 20 15:17:01 1.3 is danny.. Mar 20 15:17:15 general rule of thumb for support is current and prior release Mar 20 15:17:15 fray: found the problem, not why Mar 20 15:17:44 (for our commercial work, we have 3-5 year support cycles, if not longer) Mar 20 15:19:53 fray: ok. have to run, but I suspect I will try danny tomorrow. Mar 20 17:01:12 n Mar 20 17:01:26 er, moin Mar 20 19:17:59 * mr_science is still here and eating lunch... Mar 20 21:21:01 hello **** ENDING LOGGING AT Thu Mar 21 02:59:58 2013