**** BEGIN LOGGING AT Mon Jan 23 02:59:57 2012 Jan 23 07:54:03 good morning Jan 23 10:04:13 hi all Jan 23 10:08:05 morning Jan 23 14:11:21 Hi everyone Jan 23 14:12:09 I need some hints about setting up a dedicated server for compiling embedded firmwares with yocto Jan 23 14:13:38 Some months ago I set up a yocto 1.0 and after some weeks of work I was able to compile a complete firmware but I was using one of the toolchains built with yocto itself Jan 23 14:14:09 Now I just wanted to re-do everything using a clean environment and an external toolchain provided by the chip manufacturer Jan 23 14:14:30 which is the best way to use an external toolchain in yocto? Jan 23 14:15:06 Do you suggest me to check out yocto from git or to download a tar.gz snapshot? Jan 23 14:53:57 is it just me, or are runtime dependency names badly changed when using debian.bblass? Jan 23 14:54:22 for cross-canadian (otherwise it works fine sofar) Jan 23 14:56:55 I had to rebuild gdb-cross-canadian-arm manually to fix runtime dependency from expat-native to libexpat1, but expat wasn't changed in a while afaik, so not sure how gdb-cross-canadian-arm got wrong runtime provider from shlibs Jan 23 14:58:04 mrAlmond: using an external toolchain which was built with yocto should be fairly straightforward. any other toolchain not so much Jan 23 14:58:09 * kergoth yawns Jan 23 16:16:58 kergoth: Thank you for your answer...I remember using buildroot some years ago, the usage of an external toolchain was very simple, is it so hard to do in yocto? Jan 23 16:18:42 It's a bit less trivial because we support package management well. We need to pull files out of the external toolchain to produce packages for the c library, libgcc, etc, but the layout of external toolchains and their content can vary slightly depending on the toolchain Jan 23 16:19:16 see oe-core/meta/recipes-core/meta/ for the external*toolchain recipes which are currently available Jan 23 16:19:26 (note that the csl/codesourcery one is broken right now) Jan 23 16:20:04 I thought someone was working on that... ? Jan 23 16:20:06 There are comments in the mailing list archives about how to make it work Jan 23 16:20:13 * RP__ wishes he had patches Jan 23 16:20:39 https://github.com/kergoth/oe-core/compare/external-toolchain - work in progress Jan 23 16:20:48 zeddii: I built and booted a qemuppc sato image here and it had no eth0 Jan 23 16:20:53 slowly working on merging the work mentor has done on the csl one Jan 23 16:20:57 heh Jan 23 16:21:05 zeddii: Are you using the runqemu scripts? Jan 23 16:21:08 yep. Jan 23 16:21:12 I have no changes in my tree. Jan 23 16:21:29 I wonder if the kernel config isn't showing up. Jan 23 16:21:30 zeddii: is the ethernet a kernel module or built in? Jan 23 16:21:46 zeddii: I can check for a kernel config line if I know what to look for Jan 23 16:21:58 built in. and liming sent and updated config. let me go see if the SRCREVs are right in master. Jan 23 16:22:11 I'll go get the right one. sec. Jan 23 16:23:18 * kergoth looks at adding a knob to make qemu-native not use sdl/gl at all for cases where it isn't needed, to reduce build host dependencies Jan 23 16:23:23 RP__ hold that thought. I booted my 3.2 kernel. let me try 3.0. I'm about to update it to 3.2, but perhaps something is missing in 3.0. Jan 23 16:26:26 Hmm, the sanity check for network connectivity requires git on the host... Jan 23 16:26:33 * kergoth wonders why git-native even exists if this is the case Jan 23 16:27:07 heh Jan 23 16:27:18 RP__, confirmed. 3.0 has no ethernet. 3.2 does. must be a bad config merge. I'm on it now. Will send a fix shortly along with my tty update to runqemu. Jan 23 16:28:03 kergoth: yes I was a little puzzled by that as well Jan 23 16:31:02 zeddii: great, thanks :) Jan 23 16:31:37 kergoth: there are also races with git-native if you use floating srcrev Jan 23 16:31:43 :( Jan 23 16:31:59 should probably just kill the -native and give up on avoiding the dpe Jan 23 16:32:02 dep Jan 23 16:34:05 kergoth: yes. Much more interesting to kill off the svn/cvs deps Jan 23 16:34:21 kergoth: It was useful when git was a new thing and we only had a handful of recipes Jan 23 16:35:02 indeed Jan 23 16:42:34 RP__. aha. it was a dependency that 3.2 doesn't have on the eth. fixed here. will boot test and send a pull request. Jan 23 17:31:47 sgw, Available? Jan 23 17:41:17 halstead: hi, I am in JF today, are you able to come in this afternoon Jan 23 17:42:34 sgw, I have a scheduled fright delivery between noon and 3pm. (A proper office desk.) Jan 23 17:42:50 sgw, I can come now or after 3. Jan 23 17:43:44 halstead: how about after 3 and dinner? Jan 23 17:44:16 sgw, I'll start planning for that. Jan 23 18:18:43 I am trying to write a recipe for libgdiplus - when I use the ADT and run ./configure, it completes, however, when I execute my recipe, I get an error - error: possibly undefined macro: LT_CURRENT, If this token and others are legitimate, please use m4_pattern_allow. Any ideas? Jan 23 18:21:43 the package likely has an autoconf file that is too old, or not properly quoted.. Jan 23 18:22:04 I assume the recipe has an inherit autotools in it.. that will cause autoconf, automake, etc to be run as needed Jan 23 18:24:32 I have a somewhat basic question that I need some help with. I have a yocto tree that I am sharing with a third party vendor. I need to create a separate layer that has "protected" source... ie. vendor cannot access this source, only the binary and -dev IPK files. Jan 23 18:25:14 In essence, I need to be able to do a full build without the 'protected' source by giving a dir containing the binary and -dev IPKs. Jan 23 18:25:20 any ideas? Jan 23 18:25:29 kergoth: ping Jan 23 18:25:41 I've not done that with Yocto yet, but I have with the WR build system.. Jan 23 18:25:54 if they have to be able to build using bitbake -- then the way to do it is fake the recipes for the binary elements.. Jan 23 18:26:06 fray - yes, it does have inherit autotools and pkgconfigit is here http://pastebin.com/CEh2qBmL Jan 23 18:26:12 simply no-op the fetch, unpack, patch, configure, compile, install rules.. Jan 23 18:26:33 and setup the package_write_ task to copy your binary and make it available wherever the original rule would have.. Jan 23 18:26:38 fray... ok. so something like: Jan 23 18:26:46 this way bitbake will think it's still building the items, but it's not doing anything except a final copy op.. Jan 23 18:26:56 if they are just using package feeds, then all they need are the binary elements Jan 23 18:27:02 I could create a .class that checks if we have access to the source? Jan 23 18:27:14 difference is really ADT like work, or not.. Jan 23 18:27:21 mebrown, now that I know of.. Jan 23 18:27:48 I have a similar concept that I have been using to change where bitbake takes "S" from Jan 23 18:27:51 I would simply create two recipes.. maybe a shared .inc file that has the dependency and other meta data.. one of the recipe files builds from source, the other copies in (or just uses) an existing binary Jan 23 18:28:05 ok. I have an idea of how to experiment now Jan 23 18:28:07 thanks! Jan 23 18:28:56 ok, stupid, stupid question... is there a way to set a variable in local.conf that will be accessible via the recipe files? Jan 23 18:29:09 ya, anything in local.conf is exposed to the recipes Jan 23 18:29:25 VARIABLE = "value" will do it Jan 23 18:29:26 ok. (sorry for the stupid questions, still a learner here. :) Jan 23 18:29:38 no problem Jan 23 18:30:22 fray - yes, it does have inherit autotools and pkgconfigit is here http://pastebin.com/CEh2qBmL Jan 23 18:31:40 ya, that looks reasonable.. I'm guessing you will need to extract the libgdiplus and find/fix the autoconf problem.. Jan 23 18:32:02 ok, will research, thanks! Jan 23 18:32:04 Not sure what the basis of LT_CURRENT is.. but it's likely some libtool thing Jan 23 18:32:37 somehow I thought that autotools used by ADT are the same as the ones used by bitbake Jan 23 18:32:48 they are supposed to be Jan 23 18:33:00 and if configure passed in ADT, it would also pass in bitbake Jan 23 18:33:04 hmmmn Jan 23 18:33:23 With the ADT check that you are indeed using the autotools from the ADT itself, and not your host system.. Jan 23 18:33:29 the ADT has more potential for host contamination issues Jan 23 18:35:25 I see, I have verified that the PATH environment variable is as expected - tmp/sysroots/i686-linux tmp/sysroot/crownbay and many others are in the path Jan 23 18:36:53 ya, I'm not sure.. Jan 23 19:22:28 I think that yocto/bitbake is intentionally messing with the configure script. I am reviewing the files in the tmp/work/core2-poky-linux/libgdiplus-2.6.7-ro directory and came across this http://pastebin.com/1HtMBs32 Jan 23 19:22:43 it seems like configure is being deleted and written with something else Jan 23 19:22:50 is there a way I can disable this? Jan 23 19:24:23 the autotools class re-runs autoconf/automake/etc. so yes, it should overwrite configure in most cases Jan 23 20:03:46 so, configure.in had some variable set as follows: LT_CURRENT=10, I replaced it with m4_define(lt_current, 10) and all occurances of LT_CURRENT with lt_current Jan 23 20:03:52 this seems to have worked Jan 23 20:03:57 I have no idea why Jan 23 20:04:27 fray, kergoth - I would be enlightened if you can shed some light on this Jan 23 20:08:11 ls Jan 23 20:33:45 autif -- I don't know directly, but I suspect it's an internal change with autoconf.. Why it would work in the ADT and not regular system I don't know Jan 23 20:50:07 thanks fray :-) I will move on Jan 23 21:00:26 are .diff and .patch files applied differently? Jan 23 21:01:35 I created a patch file (patch -u orig new > patch) and saved it is recipe/libgdiplus/libgdiplus-2.6.7/cairo/configure.in.diff and included it in the recipe Jan 23 21:01:50 the diff file is copied correctly, but I get an error Jan 23 21:01:52 they are applied teh same.. Jan 23 21:02:19 No file to patch. Skipping patch. Jan 23 21:02:28 but ".patch" is the convention used mostly in oe-core Jan 23 21:02:53 not sure.. but it sounds like your diff header isn't right.. Jan 23 21:03:03 that is very likely Jan 23 21:03:33 --- configure.in.orig 2012-01-23 15:09:19.198498003 -0500 Jan 23 21:03:43 +++ configure.in 2012-01-23 15:08:24.922498003 -0500 Jan 23 21:04:03 does it need to be different? Jan 23 21:04:29 diff -ur checkpolicy-2.1.0.orig/test/Makefile checkpolicy-2.1.0/test/Makefile Jan 23 21:04:29 --- checkpolicy-2.1.0.orig/test/Makefile 2011-07-27 14:32:54.000000000 -0500 Jan 23 21:04:29 +++ checkpolicy-2.1.0/test/Makefile 2012-01-16 18:21:32.140776138 -0600 Jan 23 21:04:38 thats from something I'm working on.. Jan 23 21:04:45 ignore the date-code path though Jan 23 21:04:48 'er.. part Jan 23 21:04:54 ok Jan 23 21:05:09 let me try that Jan 23 21:05:09 format should be "original directory/[path]/[file]" Jan 23 21:05:21 in your case I'd suspec it's lib.../configure.in Jan 23 21:05:24 yup, I created the patch in a tmp directory Jan 23 21:05:28 should not have done that Jan 23 21:05:53 its is libgdiplus/cairo/configure.in Jan 23 21:05:54 yes Jan 23 21:09:19 worked, when I added the right header, seem slike my recipe is complete and seems to work Jan 23 21:09:20 thanks! Jan 23 21:09:43 good to hear Jan 23 21:10:11 if you think this could be useful to someone else, consider submitting it to the meta-openembedded layer via the OpenEmbedded folks.. Jan 23 21:19:26 oh, I was actually considering submitting it to yocto - may be in meta-devtools - is that not a likely option? Jan 23 21:23:47 along with the mono recipe that is yet to be developed Jan 23 21:26:25 submit it.. the maintainers will let you know if it's appropriate or not.. and alternatives.. Jan 23 21:26:33 will do Jan 23 21:26:40 I hate to see work not getting public exposure because it may not be right for one project, but is for another.. Jan 23 21:27:06 at Wind River our policy is oe-core first (part of Poky).., then Poky specific, then meta-openembedded, then "custom layers" Jan 23 21:27:08 i agree Jan 23 21:27:35 ah Jan 23 21:28:01 (I'm currently working on some selinux stuff.. which is the "custom layers"... Jan 23 21:28:11 reminds me.. I need to get it published as a repository for others to look at.. Jan 23 22:31:43 pwd Jan 23 22:31:57 oops wrong window! Jan 23 22:32:35 ~ Jan 23 22:32:48 oops: command not found **** ENDING LOGGING AT Tue Jan 24 02:59:57 2012