**** BEGIN LOGGING AT Thu Aug 04 02:59:57 2011 Aug 04 07:27:29 morning all Aug 04 07:34:34 RP__: morning Aug 04 07:34:42 hi dongxiao Aug 04 07:35:53 RP__: I still meet some error with /bin/sh missing. However the failed dependency log is much shoter than before. Aug 04 07:36:11 error: Failed dependencies: Aug 04 07:36:11 /bin/sh is needed by dbus-1.4.12-r0.x86_64 Aug 04 07:36:11 /bin/sh is needed by psplash-0.0+svnr424-r6.x86_64 Aug 04 07:36:11 /bin/sh is needed by portmap-6.0-r7.x86_64 Aug 04 07:36:11 /bin/sh is needed by dropbear-0.52-r3.x86_64 Aug 04 07:36:27 RP__: 8 items left Aug 04 07:36:45 dongxiao: What target are you building? Did busybox or bash build before it? Aug 04 07:37:25 RP__: target is qemux86-64, I build lib32-core-image-sato. Bash is built out before rootfs. Aug 04 07:38:05 dongxiao: is this an incremental build? Aug 04 07:38:16 RP__: no, build from scratch Aug 04 07:38:43 dongxiao: :/. Can you check if bash rprovides /bin/sh ? Aug 04 07:39:01 (the bash rpm that is) Aug 04 07:45:31 RP__: /bin/bash is provided by bash Aug 04 07:46:19 dongxiao: The patch I merged yesterday should add /bin/sh too :/ Aug 04 07:49:19 RP__: I know the reason. I was based on the tree with my three patches against package_rpm.bbclass, which are not merged currently. Aug 04 07:49:51 RP__: in my patch, I didn't strip MLPREFIX from "d", so pkg != d.getVar("PN", True) Aug 04 08:36:49 dongxiao: ah, right Aug 04 08:52:20 RP__: One question about the /bin/sh provide. Your patch writes /bin/sh as "Provide" into bash's spec file, however bash doesn't actually provide the file (the file is generated through soft link later). So when installing other packages which require /bin/sh as FILERDEPENDS, they will treat bash providing /bin/sh even if the bash rpm doesn't in actual? Aug 04 08:52:47 dongxiao: after the bash rpm is installed, update-alternatives will ensure there is a link there Aug 04 08:53:45 RP__: But while calculating the dependencies, bash hasn't been installed actually. Aug 04 08:53:54 dongxiao: doesn't matter Aug 04 08:54:19 dongxiao: nothing would try and use the link until after the package is full installed Aug 04 08:57:47 RP__: Just now my suspection on the code logic is wrong, (in fact, pkg == d.getVar("PN", True)). Therefore in my environment, your patch also works. It writes "/bin/sh" as bash's "Provides" into the spec file, however, rootfs still reporting missing of /bin/sh. I use rpm-qlp bash.rpm, and saw the files are /bin/bash and /bin/bashbug. Aug 04 09:40:32 dongxiao: I'm a little puzzled then as the provision should be there :/ Aug 04 12:14:04 RP__: I discover now oe-core image_types.bbclass proudly sets IMAGE_CMD_jffs2 = ... no override is possible Aug 04 12:15:10 ant_work: That sentence doesn't make any sense. Overrides are always possible Aug 04 12:15:49 seems that even if set in machine.conf is ignored when building Aug 04 12:16:49 ant_work: I guess the values are set later now they're in a .bbclass rather than bitbake.conf Aug 04 12:17:11 ant_work: You can do IMAGE_CMD_jffs2_ Aug 04 12:19:09 sure, I'll try try again but at first sight those oe-core images have wrong padding (not detected). (defs is common to Z family, I should add many lines :/) Aug 04 12:19:48 ant_work: I'm open to patches improving the defaults Aug 04 12:20:07 did not doubt Aug 04 12:20:10 thx Aug 04 12:20:26 ant_work: note you can override EXTRA_IMAGECMD_jffs2 from machine.conf Aug 04 12:20:38 ant_work: likely you don't need to change the whole thing Aug 04 12:21:18 http://git.shr-project.org/git/?p=meta-smartphone.git;a=blob;f=meta-zaurus/conf/machine/include/zaurus.inc Aug 04 12:21:28 is set once for all here Aug 04 12:21:46 maybe the EXTRA trick would work Aug 04 14:07:37 morning all Aug 04 14:34:53 fray: ping Aug 04 14:43:44 hi sgw Aug 04 15:55:33 Good Morning All ! Aug 04 17:25:17 khem: ping Aug 04 19:58:50 why does one provide a SRCREV and a KMACHINE (branch) for the linux recipe? Aug 04 19:58:58 they would seemingly conflict with one another Aug 04 20:03:19 msm. because the same SRCREV could be on multiple branches, and the branch is used internally to identify the board. Aug 04 20:03:25 SRCREVs aren't exactly user friendly. Aug 04 20:29:14 zeddii: would you be able to omit one though? Aug 04 20:30:03 with a re-write of everything underneath .. sure. but the tools and kernel are mapped to and built by bitbake, but that's only one mapping to them. Aug 04 20:30:12 how does the branch id the board? in the yocto-kernel-tools? Aug 04 20:30:42 dangit, how the hell am i ending up with both the gcc 4.5 and 4.6 scm uris in my gcc-configure-runtime-4.5 build? it's choking wrt SRCREV_FORMAT Aug 04 20:30:44 what if KMACHINE = yocto/stanard/base - that does not id a board Aug 04 20:30:45 hrm Aug 04 20:30:48 the branch and kmachine identify what actually gets built. there's no compulsion to have the bitbake machine be the same name in the kernel. Aug 04 20:31:21 msm. that won't work for a few more days. funny you ask. Aug 04 20:31:40 I'm porting in a series of updates for some new 1.1 updates. Aug 04 20:31:44 so each board will have to have a branch in linux-yocot? Aug 04 20:31:51 at the moment, that is what we do. Aug 04 20:32:01 it's an explicit documentation of what is supported. Aug 04 20:32:01 that does not seem to scale well Aug 04 20:32:15 but in 1.1, we can map arbitrary boards onto arbitrary branches. Aug 04 20:32:27 msm. I support over 400 BSPs with that scheme :) Aug 04 20:32:39 how would I go about over ridding on a based off the cpu type instead of the machine type? Aug 04 20:32:59 SRCREV_core_e500mc Aug 04 20:33:07 you wouldn't. Aug 04 20:33:07 and KMACHINE_core_e500mc Aug 04 20:33:14 but i want that =) Aug 04 20:33:23 put in a feature request! :) Aug 04 20:33:31 we have one kernel that runs all these different machines Aug 04 20:33:41 im added a require e500mc.inc to my machine.conf Aug 04 20:34:06 does the VAR_abc_xyz notation work everywhere though? Aug 04 20:34:35 for SRCREV_machine_p2020ds, I assume it means SRCREV=val if machine==p2020ds Aug 04 20:34:48 yep. Aug 04 20:35:06 so if I define something in my e500mc.inc I could theortically make this work Aug 04 20:37:06 I probably didn't follow what you were trying to do. Aug 04 20:37:17 hehe, its ok Aug 04 20:37:26 im probably don't follow what im trying to do Aug 04 20:37:40 the flexibility is there to do most everything. Aug 04 20:37:50 the SRCREV is used by bitbake to make sure you have the right tree. Aug 04 20:38:02 so you can set it to whatever you need to, using overrides, etc. Aug 04 20:38:05 so that part is fine. Aug 04 20:40:07 and crap. I have to leave for a baseball game tonight. Aug 04 20:41:00 but I can explain this in as much detail as you'd care to hear, I'm actually writing this up right now, and will have a set of changes ready shortly that make things better. Aug 04 20:41:37 but the jist is that you identify the kernel machine and branch (and they can be the same), which checks out a branch, finds a feature description, validates it and builds. Aug 04 20:41:51 i'll keep an eye out Aug 04 20:42:06 since im in the process of adding linux builds for a lot of boards now =) Aug 04 20:42:26 keep an eye out for my pull request in the next 24 hours. literally. Aug 04 20:42:48 we are building the 'n450' board, using yocto/standard/preempt-rt/base, and calling it the atom-pc kmachine. Aug 04 20:43:09 just to illustrate how the MACHINE can map to an arbitrary kernel machine and branch :) Aug 04 20:43:15 sgw: yes, am here now Aug 04 20:43:35 we basically have 3-4 kernel config/images we want to build for 15-20 machines Aug 04 20:43:57 yup. that's pretty easy to setup. I will have this written up as well. Aug 04 20:44:07 as in docs? Aug 04 20:44:10 hehe =) Aug 04 20:44:15 yep. and howto's, etc. Aug 04 20:44:25 awesome Aug 04 20:44:30 i should have waited a week to start on this then Aug 04 20:44:36 then I can go get hit by a bus Aug 04 20:44:39 ;) Aug 04 20:45:37 msm: if you drop me an email, I can help as much as you need. I'm not always watching IRC and can easily send you examples via email. Aug 04 20:45:44 ok. now I'm just plain late. :) Aug 04 20:46:05 thanks, i'll keep that in mind… Aug 04 20:48:00 does keying KMACHINE and SRCREV off of DEFAULTTUNE make sense? Aug 04 20:49:09 like KMACHINE_defaulttune_x86_64 Aug 04 22:31:06 is there a way to specific a number of threads to use from the command line? instead of editing local.conf? Aug 04 22:31:24 or i guess a better more generic question is there a way to set env vars to bitbake from the invocation line? Aug 04 22:32:12 You can whitelist certain vars Aug 04 22:32:35 ah, make sense Aug 04 22:38:07 BB_ENV_WHITELIST, space separated list of vars to allow in Aug 04 22:41:14 was not sure if those were just passed through to the builds or used internally in bitbake as well Aug 04 22:41:51 the whitelisted env vars flow into the configuration metadata, which is then what bitbake uses Aug 04 22:42:10 where configuration metadata == conf/bitbake.conf (and everything it includes) + base.bbclass + the classes in INHERIT Aug 04 22:42:59 and the build environment as well.. Aug 04 22:45:26 the metadata is all about going from more generic information to more specific information. conceptually it's layered. this layering is implemented in two ways, one is parse order (env|bitbake.conf...), as later definitions always override earlier ones (which applies to bitbake.conf overriding the env as well), one is OVERRIDES. Aug 04 22:46:15 structuring it this way is why we were able to share the core metadata amongst so many folk with differing priorities, really. would have been hard to do so otherwise Aug 04 23:56:35 why does linux-yocto_3.0 use git.pokylinux.org where all the others use git.yoctoproject.org? **** ENDING LOGGING AT Fri Aug 05 02:59:56 2011