**** BEGIN LOGGING AT Fri Aug 05 02:59:56 2011 Aug 05 07:58:45 morning all Aug 05 08:17:00 RP__: morning & ping. Aug 05 08:17:09 dongxiao: pong Aug 05 08:17:22 dongxiao: I was just reading your multilib patch Aug 05 08:17:39 RP__: Currently it seems that PREFERRED_VERSION and PREFERRED_PROVIDER are not work in multilib. Aug 05 08:17:50 dongxiao: Can we not change RDEPENDS_task-core-boot to RDEPENDS_${PN} for the same result ? Aug 05 08:18:12 RP__: Of course it could. So you preferred this approach? Aug 05 08:18:27 dongxiao: yes, it avoids hardcoding PACKAGES Aug 05 08:18:54 RP__: I just saw other task-core-xxx.bb all have hardcoded PACKAGES, so I added it for task-core-boot Aug 05 08:19:21 dongxiao: they do? hmm :/ Aug 05 08:20:46 RP__: Yes, for example, task-core-{nfs, x11-sato, sdk, ssh-dropbear, etc}. Aug 05 08:21:59 dongxiao: ok, I guess this is conistent Aug 05 08:23:02 RP__: so still use the previous sent of patch? Aug 05 08:23:14 dongxiao: yes, I'll merge that, thanks Aug 05 08:23:29 dongxiao: I wasn't seeing it in the context of the other recipes Aug 05 08:25:10 RP__: Maybe we have such potential problem in other recipes. Aug 05 08:27:19 dongxiao: Hopefully they all use ${PN} cosistently Aug 05 08:28:47 RP__: Do you have idea about PREFERRED_PROVIDER and PREFERRED_VERSION support for multilib? Aug 05 08:30:17 RP__: The two variables should be parsed before multilib.bbclass take effect, right? Aug 05 08:49:20 dongxiao: I think we might have to add some code to expand those at config parsed time... Aug 05 08:49:45 dongxiao: Can you open a bug on the problem please? I think I have some ideas on a solution for that Aug 05 08:50:09 I've filed bug 1341 for that Aug 05 08:51:23 RP__: So we need to add the logic in bitbake? Aug 05 09:12:50 dongxiao: no, we should be able to do it in an eventhandler Aug 05 09:13:27 dongxiao: although bitbake support would likely make it easier Aug 05 11:48:43 RP__: yes, I also think put the logic in bitbake is improper since it is too meta layer specific Aug 05 15:29:19 Morning all Aug 05 15:29:26 RP__: Pull request sent Aug 05 17:01:31 zeddii: ping Aug 05 17:04:10 zeddii: check email please Aug 05 17:45:06 zeddii: re-ping Aug 05 18:06:18 hi Aug 05 21:57:14 galak: ping Aug 05 21:57:21 sgw: pong Aug 05 21:57:51 galak: saw your email are you looking for the list of package depends based on a given target or general list of recipes? Aug 05 21:58:10 there is bitbake -s which might serve your needs Aug 05 21:58:10 packages based on depends Aug 05 21:58:44 not sure it does that based on depends though, it just lists all recipes and versions Aug 05 21:59:35 bitbake -s is useful, was trying to figure out how to get a list of what would be built for core-image-minimal Aug 05 21:59:44 as an example Aug 05 22:00:02 the -g switch Aug 05 22:00:07 bitbake -n in a clean space would give you a task based list of all the tasks in a dependency order, but it includes all tasks (fetch, unpack, patch, ...) Aug 05 22:00:13 and -u depexp if you don't like graphviz Aug 05 22:00:40 Write that will generate the *.dot files might be what galak is looking for Aug 05 22:01:14 if you just want a visualisation the depexp ui is king (bitbake some-image -g -u depexp) Aug 05 22:01:37 is there a way to get all the dependencies for core-image-minimal (just as a list)? Aug 05 22:06:54 galak: bitbake -g 15:00 < galak> is there a way to get all the dependencies for core-image-minimal (just as a list)? Aug 05 22:06:59 errrrr Aug 05 22:07:08 galak: bitbake -e core-image-minimal Aug 05 22:07:27 that will spit of .dot files Aug 05 22:07:42 which you can visualize or look as text Aug 05 22:07:53 biab Aug 05 22:33:57 hmm, I think either the combo layer tool needs to gain split functionality, or we need to add remote subtrees to git-subtree. currently, it's way too annoying to get changes back out **** ENDING LOGGING AT Sat Aug 06 02:59:57 2011