**** BEGIN LOGGING AT Wed Apr 18 02:59:59 2012 Apr 18 07:12:18 khem: Hi, I haven't seen your patches. I just arrived at work this monday (still catching up with mails). Where did you post them? Apr 18 07:26:14 Hm, it looks like this patch breaks the external toolchain of meta-linaro layer: http://git.openembedded.org/openembedded-core/commit/?id=b56e3680e729d8216fe533cdfaf4678fe94b76f0 Apr 18 07:30:04 good morning Apr 18 07:30:41 morning Apr 18 08:02:32 good morning, hey friends, what is the difference between pstage and packaged-staging? Apr 18 08:14:52 hi. i got timeout on NOTE: fetch http://mirror.its.uidaho.edu/pub/savannah/acl/acl-2.2.49.src.tar.gz Apr 18 08:15:14 anyone can say what mirror i should use instead? Apr 18 08:17:18 one more question: i want to build angstrom-x-image with firefox included as a jffs2 image. what is best way to do that? bitbake angstrom-x-image && bitbake firefox ?? this results in a jffs2 image in tmp/deploy ? Apr 18 08:21:05 FATAL: acl-2.2.49: http://mirror.its.uidaho.edu/pub/savannah/acl/acl-2.2.49.src.tar.gz cannot check archive integrity Apr 18 08:23:40 I want to have opkg-utils (things like opkg-build etc.) in my SDK and right use a bbappend to add "nativesdk" to BBCLASSEXTEND, would it make sense to add "nativesdk" to the original recipe? Apr 18 08:30:03 ericbutters: edit angstrom-x-image and add firefox Apr 18 08:34:07 ericbutters: here you can find some sources http://software.kaeilos.com/repo/ Apr 18 08:34:24 http://software.kaeilos.com/repo/acl-2.2.49.src.tar.gz Apr 18 08:35:13 mckoan thanks! i edited angstrox-x-image and added firefox.. Apr 18 08:35:36 now i replace mirror in openembedded/recipes/udev/acl_2.2.49.bb ? Apr 18 08:35:59 no, better to get it manually Apr 18 08:36:35 Apr 18 08:36:36 [#oe] Apr 18 08:36:52 better to use this : http://sourceforge.net/projects/kaeilos/files/repo/ Apr 18 08:41:16 <_tasslehoff_> I'm trying to create recipes for ogre and its dependencies in oe-core. It compiles now, but I have a couple of QA issues I don't know how to fix. Apr 18 08:41:17 ah i see. but where to copy the archive? tmp/work/armv6-angstrom-linux-gnueabi/ ?? Apr 18 08:41:27 <_tasslehoff_> 1. WARNING: package containes bad RPATH Apr 18 08:41:41 <_tasslehoff_> 2. ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so Apr 18 08:42:06 <_tasslehoff_> how do I attack these? Apr 18 08:45:09 ericbutters: into your source directory Apr 18 08:48:56 _tasslehoff_: 1. There will be an rpath added on the compiler command line - see https://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath Apr 18 08:49:25 _tasslehoff_: you may also want to search for OE-Core commits mentioning rpath/RPATH to see examples of these warnings being fixed Apr 18 08:51:03 _tasslehoff_: 2. ensure your FILES_xxx uses the specification .so.* instead of .so*; otherwise, a .so symlink is creeping in through some other filespec, you just need to ensure that file goes into the -dev/-dbg/-nativesdk package as appropriate instead Apr 18 08:51:14 cant different boards boot out of the same nfs filesystem Apr 18 08:56:11 <_tasslehoff_> bluelightning: thanks. Apr 18 09:03:03 rm mckoan ok got it :) thx Apr 18 09:26:10 bluelightning: so including a .bb from within another .bb seems to work Apr 18 09:26:58 it seems a bit unusual, though Apr 18 09:29:07 ant_work: it is a little unorthodox, however it's not going to stop working any time soon, so I think it's safe :) Apr 18 09:31:07 I'll have to grep for include/require | grep '.bb' and see if there is any other case Apr 18 09:44:24 What is the best way to track down what drags in and builds for example "alsa-lib" when my image does not specify it and the target platform has no audio? :) Apr 18 09:49:18 jonasdn: does DISTRO_FEATURES have "alsa" in it? Apr 18 09:49:36 bitbake -e | grep ^DISTRO_FEATURES Apr 18 09:49:41 no Apr 18 09:50:01 ok, in which case I'd suggest bitbake -g and then grep the pn-depends.dot for alsa Apr 18 09:50:37 ok, thx! Apr 18 10:01:34 <_tasslehoff_> BB_NUMBER_THREADS = "8", PARALLEL_MAKE = "-j 8" for a quad core cpu? Apr 18 10:02:23 _tasslehoff_: should be fine, but sometimes BB_NUMBER_THREADS > 8 may cause build problems Apr 18 10:02:35 I meant BB_NUMBER_THREADS > 2 Apr 18 10:03:16 <_tasslehoff_> I'm using 4/j2 on my Q740@1.73GHz, but think it builds too slow. Apr 18 10:03:25 <_tasslehoff_> ok Apr 18 10:03:30 4/j5 here Apr 18 10:03:52 2/j4 here Apr 18 10:04:33 it depends if you need a couple of core to watch that videos during build ;) Apr 18 10:05:17 mckoan: I don't believe that's true Apr 18 10:05:42 mckoan: I don't experience any failures with 8/j8 or 4/j4 on several different machines Apr 18 10:06:18 bluelightning: I know, it is an old habit caused by ols problems and I never switched back to BB_NUMBER_THREADS = "8" Apr 18 10:06:28 s/ols/old Apr 18 10:06:34 we do see parallel make / make install failures from time to time, usually they get fixed as soon as they are found Apr 18 10:08:27 jonasdn: if it turns out to be something in a recipe where we're not checking for alsa in DISTRO_FEATURES (and you're using OE-Core) we should definitely fix it Apr 18 10:09:32 mckoan: fair enough, but we do regularly test high levels of parallelism Apr 18 10:09:34 (now) Apr 18 10:32:30 bluelightning, will check it out and cook up a patch if proper Apr 18 10:43:13 jonasdn: cool Apr 18 14:11:51 Hi, someone have error like lib/cpufreq.o uses VFP register arguments ? Apr 18 14:12:01 libcpufreq.so.0.0.0 does not Apr 18 14:14:56 mckoan could you pls take a look here: http://pastebin.com/raw.php?i=ErkCDg3v Apr 18 14:16:49 ERROR: Task 7403 (/SMDKC100/stuff/openembedded/recipes/gnome/pyorbit_2.24.0.bb, do_configure) failed with 256 Apr 18 14:21:10 ericbutters: no clues, sorry Apr 18 14:21:28 anyone? Apr 18 14:26:15 "See `config.log' for more details." sounds like a good suggestion Apr 18 14:26:41 oh, "configure: error: C compiler cannot create executables" Apr 18 14:30:17 yes Apr 18 14:31:45 checking build system type... i686-pc-linux-gnu Apr 18 14:31:53 checking host system type... arm-angstrom-linux-gnueabi Apr 18 14:32:07 checking for arm-angstrom-linux-gnueabi-gcc... arm-angstrom-linux-gnueabi-gcc Apr 18 14:32:29 Zagor what to do? Apr 18 14:33:04 look in config.log and see what error the compiler produced Apr 18 14:34:41 $ ./tmp/work/armv6-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r38.1+svnr170880/image/SMDKC100/stuff/build/tmp/sysroots/i686-linux/usr/armv6/bin/arm-angstrom-linux-gnueabi-gcc -o mainmain main.c Apr 18 14:34:46 as: unrecognized option '-mfloat-abi=hard' Apr 18 14:35:17 i tried from commandline.. i take a look into the config.log Apr 18 14:38:07 Zagor pls see here: http://pastebin.com/raw.php?i=UcYh63Ue Apr 18 14:42:22 it's a floating point mismatch error Apr 18 14:43:57 on commandline i did not export path to cross tools.. Apr 18 14:44:25 but OE configure should take care.. what should i do here? Apr 18 14:46:01 I don't know :( Apr 18 14:46:57 ui.. OE ran for hours.. building cross tools.. etc.. and now exit with such error Apr 18 14:47:21 all with builtin configurations Apr 18 14:50:15 TARGET_FPU = "hard" is set by smdk6410.conf Apr 18 14:50:46 puh that is noo good.. anyone can help? Apr 18 14:51:00 ls Apr 18 14:53:54 ericbutters: at least you are not alone: http://permalink.gmane.org/gmane.comp.handhelds.openembedded/50071 Apr 18 14:54:00 :) Apr 18 14:54:16 this is the problem in minmum: http://pastebin.com/raw.php?i=MZiTyJ3t Apr 18 14:56:09 nitink: Hi, Are you around? I've got a quick question with regard to your recent change to the libc locale packaging Apr 18 14:56:40 ericbutters: try "arm-angstrom-linux-gnueabi-gcc -v -o mainmain main.c" to see parameters to each sub process Apr 18 14:56:48 ericbutters: very weird error Apr 18 14:57:04 ericbutters, i have the same error Apr 18 14:57:05 ericbutters: are you using oe-classic or oe-core? Apr 18 14:57:31 kenws: I am going out for now, will be back after some time will ping you then Apr 18 14:57:45 nitink: alright : ) Apr 18 14:58:07 mckoan i installed like here: http://www.openembedded.org/wiki/Getting_started Apr 18 14:58:42 ericbutters: hmmm.. not sure it is reliable Apr 18 14:58:53 BTW I do not use Angstrom Apr 18 14:59:19 I use my version : http://www.kaeilos.com/download Apr 18 15:02:15 here is my local.conf (i use DISTRO = "angstrom-2010.x") http://pastebin.com/raw.php?i=Mag5LGyb Apr 18 15:03:18 what if i call bitbake -c angstrom-x-image and then change my local.conf for other machine? does that delete all downloaded packages? Apr 18 15:04:01 Delkia if you find a solution pls share with me :) Apr 18 15:04:12 of course Apr 18 15:04:36 ericbutters: downloaded sources are safe, they are not cleaned/deleted Apr 18 15:05:00 you will loose the tmp Apr 18 15:05:29 BTW with the problem you have I would delete the tmp and rebuild all from scratch Apr 18 15:05:49 as fist step I'd build a toolchain (bitbake meta-toolchain) Apr 18 15:06:03 if it works I'd continue with x11 stuff Apr 18 15:08:40 mckoan #1 bitbake meta-toolchain #2 build simple hello world with that toos #3 bitbake console-image Apr 18 15:08:43 ericbutters: I'd enable PARALLEL_MAKE = "-j 4" Apr 18 15:09:00 ericbutters: correct ;-) Apr 18 15:09:11 BB_NUMBER_THREADS = "2" Apr 18 15:09:20 this i do in local.conf? Apr 18 15:09:24 or 8 as bluelightning said Apr 18 15:09:37 in local.conf Apr 18 15:09:40 thx Apr 18 15:09:46 depends on how powerful your machine is Apr 18 15:10:25 and for clean i simple do a 'rm -rf tmp' ? Apr 18 15:10:38 not calling bitbake -c angstrom-x-image ? Apr 18 15:10:55 IMHO do a 'rm -rf tmp' Apr 18 15:11:00 ok Apr 18 15:11:26 then bitbake meta-toolchain Apr 18 15:11:32 yes Apr 18 15:22:13 Im having problems build gcc-cross-canadian (4.6) with hard floats, it doesnt seem to "inherit" the float flag correctly, have anyone tried this and succeeded? Apr 18 15:28:45 have a nice rest of the day Apr 18 15:45:32 kenws: ping Apr 18 15:48:41 nitink: ack Apr 18 15:48:43 wrt http://git.openembedded.org/openembedded-core/commit/?id=b56e3680e729d8216fe533cdfaf4678fe94b76f0 Apr 18 15:49:21 I see that this is a useful fix but now the PACKAGE_NO_GCONV setting of my local.conf is ignored : ) Apr 18 15:49:56 I'm using an external toolchain that comes with a libc that doesn't have i18n Apr 18 15:50:08 the default DISTRO_FEATURES has libc-charsets libc-locales and libc-locale-code enabled Apr 18 15:50:16 therefore libc-package.bbclass sets PACKAGE_NO_GCONV to zero Apr 18 15:50:57 and package_do_split_gconvs fails later on because there is no /path/to/eglibc-locale-2.15-r20/package/usr/share/i18n/charmaps Apr 18 15:52:54 kenws: looks like you need to adjust teh distro_features then Apr 18 15:53:48 nitink: Is it possible to remove entries from DISTRO_FEATURES instead of redefine the whole list? Apr 18 15:54:18 kenws: yes, you will need bit of python logic to do it Apr 18 15:54:47 nitink: cool, any hints appreciated : ) Apr 18 15:55:11 * kenws starts grepping the source Apr 18 15:56:42 maybe the replace function could be used Apr 18 15:58:28 should work, just keep the space around the words to avoid replacing other bigger words containing the same name Apr 18 15:59:39 I think you should redefine DISTRO_FEATURES_LIBC_DEFAULT as you are using your own libc Apr 18 16:00:08 try setting it to "" Apr 18 16:04:41 why not using something like this: distro_features_libc = [entry.replace('libc-locales', '') for entry in (d.getVar('DISTRO_FEATURES_LIBC', True) or '').split()] Apr 18 16:05:26 hm, that won't remove the list entry but set it to an empty string Apr 18 16:06:42 kenws: if you adjusting DISTRO_FEATURES_LIBC , then adjust it to match it with your libc, to avoid these kinds of issues in the future Apr 18 16:07:11 nitink: right, I see Apr 18 16:10:38 kenws: generally speaking, you can use := + oe_filter_out, for future reference Apr 18 16:12:50 kergoth: ah, utils.bbclass defines this helper routine - nice! Apr 18 16:13:48 yep. you should be able to grep around to find some examplse of usage Apr 18 16:14:01 ideally we'd support -=, but implementing it is less trivial than you'd think Apr 18 16:14:39 hm, since I've got a layer that supports multiple toolchains it would be nice if the recipe itself could prevent the libc locales from being packaged instead having the user define DISTRO_FEATURES_LIBC in the local.conf Apr 18 16:16:22 Noor: if you're using an external toolchain, then you should have a tcmode .inc for that toolchain, which is the most appropriate place to adjust DISTRO_FEATURES_LIBC to match it Apr 18 16:17:09 this could be achieved by changing the recipe for the external binary toolchain to not require the eglibc-package.inc but this would duplicate quite a lot of stuff on the otherhand Apr 18 16:17:25 aah, tcmode.inc Apr 18 16:17:42 ls oe-core/meta/conf/distro/include/ Apr 18 16:17:53 e.g. tcmode-external-csl.inc for sourcery g++ Apr 18 16:18:10 then you just set TCMODE= and EXTERNAL_TOOLCHAIN= (the path) Apr 18 16:18:15 (in local.conf, or whatever) Apr 18 16:19:44 kergoth: yep, got it. I'll try to add it there Apr 18 16:20:25 s/noor/kenws/, obviouslly. stupid fingers Apr 18 16:20:37 * kergoth nods, let me know how it goes, quite curious about usages of external toolchains Apr 18 16:22:12 kergoth: I use a recipe for the linaro external toolchain based on the exiting csl stuff Apr 18 16:22:30 it used to work using PACKAGE_NO_GCONV = "1" as described here: http://git.linaro.org/gitweb?p=people/kwerner/meta-linaro.git;a=blob;f=conf/distro/include/tcmode-external-linaro.inc Apr 18 16:23:03 whoops, wrong url (x selection buffer). I meant to paste this one: https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core#choosing_a_toolchain Apr 18 16:23:36 ah, interesting Apr 18 16:24:24 but when nitink fixed yocto #2089 it broke my workaround :) Apr 18 16:24:31 * kergoth nods Apr 18 16:24:49 kergoth: I suppose your toolchains all have i18n, right? Apr 18 16:25:04 heh, another example hwere I think it'd be nice to distinguish internal variables from external, so you know which might well be overwritten and which are intended for user use Apr 18 16:25:24 I believe so, yeah. I haven't run into any of them that don't yet anyway Apr 18 16:26:50 at least the libc provided by the csl toolchains have it Apr 18 16:28:48 in almost all cases customers want i18n support from the libc.. Apr 18 16:29:12 so the Mentor toolchains that we use, as well as the ones I've seen from kergoth all of i18n enabled.. you'd need t rebuild eglibc to disable them.. Apr 18 16:29:16 (most people won't do that) Apr 18 16:29:30 the big savings is simply not installing the locales, the actual i18n support is fairly small Apr 18 16:34:04 fray: I agree. I guess the missing i18n of the libc of the binary linaro toolchain is not intended. Apr 18 16:34:59 it on my todo list to find out what's going on. I suspect it just isn't copied into the resulting toolchain directory (maybe due to multiarch) Apr 18 16:35:21 s/it/it's/ Apr 18 16:35:59 or someone turned off the option, if using eglibc... Apr 18 16:36:11 if it's regular glibc, there is a bunch of local stuff disabled when cross compiling.. Apr 18 16:36:23 because glibc wouldn't except the cross compilation fixes back.. Apr 18 16:36:29 (I suspect they will now) ;) Apr 18 16:36:39 local -> locale Apr 18 16:37:03 they use a patched crosstool-ng to create the binary toolchain Apr 18 16:38:10 crosstool used to use eglibc.. I assume it still does.. so it's probably a configuration setting being disabled Apr 18 16:40:32 ah, i was wondering if anyone had looked at adding crosstool-ng external toolchain support. cool. didn't realize they use a patched version of that Apr 18 16:40:39 fray: yeah, I need to check but I think it's enabled there. the resulting toolchain gets copied into an output folder. in case you hack multiarch path's into crosstool-ng it's probably easy to mess up what's being copied (since stuff is now in multiarch paths) Apr 18 16:40:44 hm, it looks like most of the DISTRO_FEATURES_LIBC entries aren't really used Apr 18 16:41:26 the features_to_eglibc_settings maps it to eglibc options settings but they aren't used Apr 18 16:41:41 at least not within oe-core Apr 18 16:41:51 interesting Apr 18 16:42:04 git grep OPTION_EGLIBC_ Apr 18 16:42:48 kenws, sure about that? they were used the last time I played with it (6 months ago) Apr 18 16:43:49 look at meta/recipes-core/eglibc/eglibc-options.inc Apr 18 16:44:05 that maps the eglibc options into the OPTION_* file entries Apr 18 16:44:23 i.e.: Apr 18 16:44:23 eglibc_cfg('ipv6', distro_features, 'OPTION_EGLIBC_ADVANCED_INET6', cnf) Apr 18 16:44:37 if the distro feature ipv6 is enabled, then eglibc gets OPTION_EGLIBC_ADVANCED_INET6 Apr 18 16:44:44 fray: yeah, but the OPTION_* file entries aren't used anywhere Apr 18 16:45:00 they're passed into the configuration of elgibc Apr 18 16:45:31 OE_FEATURES = "${@features_to_eglibc_settings(d)}" Apr 18 16:45:31 do_configure_prepend() { Apr 18 16:45:31 sed -e "s#@BASH@#/bin/sh#" -i ${S}/elf/ldd.bash.in Apr 18 16:45:31 echo '${OE_FEATURES}' > ${B}/option-groups.config Apr 18 16:45:31 } Apr 18 16:45:47 the option-groups.conf file is the controller in eglibc Apr 18 16:47:18 fray: ah, interesting. and the option-groups.config gets used as a config file when building the libc Apr 18 16:47:32 yes Apr 18 16:47:47 that's why you suggested to use and empty DISTRO_FEATURES_LIBC in case the external toolchain provides a binary libc Apr 18 16:47:52 default configuration should match glibc.. if it doesn't then we have a bug Apr 18 16:47:57 fray: got it - thanks! Apr 18 16:48:12 we being either OE or eglibc ;) Apr 18 16:50:26 ok, I guess it won't hurt if the DISTRO_FEATURES_LIBC matche to the features used for the eglibc built by crosstool-ng Apr 18 16:50:28 : ) Apr 18 17:01:40 * mr_science follows the smell of coffee... Apr 18 17:02:18 kenws: I have forked the layer Apr 18 17:02:31 all the patches are in that repo on github let me give link to you Apr 18 17:03:02 https://github.com/kraj/meta-linaro Apr 18 17:09:30 khem: oh, interesting! Apr 18 17:10:36 I was on vacation and didn't work on meta-linaro for the last 3 weeks. I'm currently in the process of getting it in shape with the current oe-core Apr 18 17:11:22 can module_autoload_* control the order of modules loading? Apr 18 17:17:31 khem, ping ping Apr 18 17:17:34 khem: I'll have a look at your branch as soon as I finish the rebasing Apr 18 17:17:41 wrt maintenance and support - I'm basically the only one working on that layer. I don't think there is official support for now. It serves as a vehicle to test our binary toolchain but I'd love to see oe support for all ARM boards linaro supports Apr 18 17:18:36 khem, do you have a second? I'd like to talk about the future merge for a couple of minutes over there.. Apr 18 17:29:56 khem, did you mean to incrementally cherry-pick stuff? I now have a resolved merge of future into master that looks reasonable and that i could push Apr 18 17:32:50 Do I need to inlcude something in order to use oe_filter_out? Apr 18 17:33:05 I'm getting: NameError: name 'oe_filter_out' is not defined Apr 18 17:34:54 hm, the gcc-configure-runtime.inc uses @oe_filter_out in a very similar way than I use it - strange Apr 18 17:39:49 kenws: ah, right, using it in .conf files can be problematic. when using :=, its expanded immediately, which can be before the classes are parsed Apr 18 17:39:58 kenws: might have to resort to an anonymous python function in a .inc Apr 18 17:42:17 kergoth: oh, ok. I guess I'll just set the DISTRO_FEATURES_LIBC to an empty list as a workaround and focus to fix the libc-i18n of the next release of our external toolchain : ) Apr 18 17:43:35 kergoth: Are you setting the DISTRO_FEATURES_LIBC accordingly to the binary libc of your mentor toolchain? Apr 18 17:45:04 the csl recipes just use what the default-distrovars.inc specifies - whether it matches or not Apr 18 17:46:21 currently just using default, it should probably be explicit about it Apr 18 17:46:23 * kergoth nods Apr 18 17:47:34 yep Apr 18 17:55:02 ericben, I think autif is looking for you Apr 18 17:55:16 thanks Crofton|work Apr 18 17:57:55 ericben - I was trying to build chromium for x86 (MACHINE = crownbay) and ran into issues almost immediately - Fetcher failure for URL: 'file://include.gypi'. Unable to fetch URL from any source. Apr 18 17:58:44 include.gypi is in chromium/chromium/armv7a - so it is not found for x86 Apr 18 17:58:51 I will be happy to send a patch Apr 18 17:58:58 can you please point me to the right direction Apr 18 18:10:25 hi autif : yes we only tested for armv7 until now Apr 18 18:10:37 please send patch to oedev & copy to our email in the readme Apr 18 18:12:49 autif: btw I've received your patch fixing the URL, will push later tonight I have to go now Apr 18 18:16:16 ericben - OK - I guess I will catch you tomorrow - I assume that you are in the French time zone. Apr 18 20:08:33 autif: back online (yes I'm in GMT+1) **** ENDING LOGGING AT Thu Apr 19 02:59:59 2012