**** BEGIN LOGGING AT Wed Oct 30 02:59:58 2013 Oct 30 05:04:30 hi there, hoping someone can help me with a problem Oct 30 05:05:50 trying to add erlang to a build for a gumstix board Oct 30 05:06:02 erlang cross-compiles correctly stand-alone Oct 30 05:06:29 but configure bombs out when run from bitbake Oct 30 05:06:45 looks like differences in the toolchain Oct 30 05:07:18 looks like no-one's home - will post a question to the mailing list instead Oct 30 08:34:38 Good Morning All, Oct 30 09:48:54 what is the preferred way to handle different kernel configurations for the same machine? I would thought that creating different image recipes with different settings for PREFERRED_PROVIDER_virtual/kernel would solve it, but PREFERRED_PROVIDER_virtual/kernel seems to be only applicable within the machine.conf, isn't it? Oct 30 10:49:51 morning all Oct 30 13:12:06 Any idea why I my yocto image does not have v4l2src? I installed gst-good plugins in my image. but v4l2src dessn't exists in my final image Oct 30 13:14:11 zaif: did you install gst-plugins-good-meta or gst-plugins-good? installing the latter won't do anything by itself Oct 30 13:16:51 bluelightning: I installed gst-plugins-good into my image Oct 30 13:17:52 bluelightning: Where can I find gst-plugins-good-meta? Is it a recipe? Oct 30 13:17:53 zaif: ok well that package itself is empty; either you need to install gst-plugins-good-meta to get all plugins from gst-plugins-good, or install individual plugin packages e.g. gst-plugins-good-v4l2src (not sure of the exact naming) Oct 30 13:18:07 zaif: no, the recipe is the same (gst-plugins-good) Oct 30 13:18:44 zaif: the recipe produces multiple packages, one per individual plugin, as well as a -meta package that installs all of them Oct 30 13:20:03 bluelightning: I can see gst-plugins-good extracted in my /yocto/build/tmp/stamps/armv7a-vfp-neon-poky-linux-gnueabi directory but not on to my image. So, I need to give gst-plugins-meta in my image.bb file? Oct 30 13:20:38 zaif: gst-plugins-good-meta yes Oct 30 13:22:17 bluelightning: ok will try that. Oct 30 13:29:52 bluelightning: cloned gst-plugins-good and found out that v4l2src plugin is in /gst-plugins-good/docs/plugins/inspect/plugin-video4linux2.xml Oct 30 13:30:43 bluelightning: I guess i must give gst-plugins-good-video4linux2 in my image.bb Oct 30 13:32:34 zaif: if you mean adding it to IMAGE_INSTALL there, yes that should work Oct 30 13:46:24 hi to all! How can I (or where can I get information about) build and deploy an image for imx28evk with nand flash? Thanks! Oct 30 13:51:04 Thanks for Robert Yang to maintain dora ! :D Thank RP for announce it. Oct 30 13:52:58 otavio: I think we all thought someone else was announcing it :) Oct 30 13:52:59 Soo, Robert Yang is the explorer of Dora? Oct 30 13:53:22 and does he keep at IRC? Oct 30 13:53:31 RP: :D Oct 30 13:54:15 BTW, I'm having a problem with a new recipe. Oct 30 13:54:36 I am building SQL::Abstract, a CPAN module, for which I have made a recipe. It is a barebones recipe, using the cpan bbclass. Oct 30 13:54:48 However, it seems to hang on do_compile, without throwing an error. Oct 30 13:54:58 When I ps | grep ..., it seems that make is running. Oct 30 13:55:06 However, running this make command in a devshell finishes really quick. Oct 30 13:55:30 I am running bitbake with -v, which shows the module complaining a bit about mismatching versions of libraries. Oct 30 13:55:52 I just wonder, can I somehow verify that it would eventually get there? Because it seems like it has been going at this for unreasonably long. Oct 30 13:57:02 Stygia: it sounds like there is some difference in the environment. Does the run.do_compile script in temp give any better clues to what its running? Oct 30 13:57:11 Stygia: could it be a parallel make issue? Oct 30 13:57:13 It's worth mentioning that it seems like this do_compile ignores my SIGINT (interrupt), and while bitbake recognises it, i.e. metions having been interrupted, it doesn't stop. Oct 30 13:57:35 RP, Isn't the devshell the exact same environment though? Oct 30 13:58:03 When I SIGINT it gets to 'execution was interrupted, returning non-zero exit code', but then stops there. Oct 30 13:59:02 bluelightning: No luck, v4l2src is not in my Image. Oct 30 14:01:07 hi Oct 30 14:01:17 any idea what could cause this error: Oct 30 14:01:24 RP, See what it's running, I'll try it out in devshell. Oct 30 14:01:30 from .basedb import BaseDB Oct 30 14:01:30 File "/usr/lib/python2.7/site-packages/tlslite/basedb.py", line 13, in Oct 30 14:01:30 import dbm as anydbm Oct 30 14:01:30 ImportError: /usr/lib/python2.7/lib-dynload/dbm.so: undefined symbol: dbm_nextkey Oct 30 14:01:55 mbelisko, dmb.so doesn't define dbm_nextkey Oct 30 14:02:06 Meaning it could need to be recompiled, or it's the wrong version. Oct 30 14:02:37 If you do `nm /usr/lib/python2.7/lib-dynload/dbm.so`, you'd probably see 'U dbm_nextkey' Oct 30 14:02:48 Meaning this so file doesn't define that function, and doesn't know where to look. Oct 30 14:02:56 Maybe you need to add a -lX option to your compile flags. Oct 30 14:03:04 ok so probably never version of tlslite could help there? Oct 30 14:03:06 Say that function was in libxml2 (It probably isn't) Oct 30 14:03:16 You'd add -lxml2 to the compile flags Oct 30 14:03:28 mbelisko, You probably need to ensure what you're compiling can find the proper libs. Oct 30 14:03:52 mbelisko, You could be compiling it, and then not including a necessary library, or the linker could be doing something wrong. Oct 30 14:04:05 ok Oct 30 14:04:07 will check Oct 30 14:04:37 thanks Oct 30 14:04:47 mbelisko, If you want my attention specifically, prefix what you say with Stygia so I know you're saying something to me. Oct 30 14:05:12 Stygia: the devshell and the real command try and be the same, there could be some difference though. Does the run.do_compile really just run "make"? Oct 30 14:05:43 Stygia: ok, sorry Oct 30 14:07:25 RP, No, it uses oe_runmake Oct 30 14:07:31 mbelisko, No worries. Oct 30 14:09:18 Stygia: parallel make would come into play then... Oct 30 14:10:15 RP, Hmm, right... Oct 30 14:10:31 RP, What sort of problems could that cause? Oct 30 14:11:00 Stygia: races. Try PARALLEL_MAKE = "" in the recipe Oct 30 14:25:08 RP, I think, actually, it has to do with which paths are being used. Oct 30 14:25:19 RP, But, I'll look into it, and give a sound if I need some advice. Oct 30 14:25:30 RP, Thanks mate/mateette (or however you say in English). Oct 30 14:27:23 RP, Do you know what this path is? tmp/sysroots/imx6qsabresd/ Oct 30 14:27:24 Subdir of build. Oct 30 14:27:28 Is that STAGING_BINDIR? Oct 30 14:28:04 Stygia: that looks like STAGING_DIR_TARGET Oct 30 14:28:46 RP, Hmm, right. If I saw some host-specific paths in a configure file, and I wanted to sed in a prefix, would STAGING_DIR_TARGET be a good prefix? IIRC ${D} and ${S} usually don't have libs and such, don't think they should either. Oct 30 14:30:06 RP, This, BTW, is my recipe and what I'm seeing with make: http://pastebin.com/F3YCUHt3 Oct 30 14:31:10 Stygia: yes, that would seem reasonable Oct 30 14:31:26 RP, Right, cheers. Oct 30 14:32:16 can someone explain why every external-toolchain .inc file for tcmode sets: Oct 30 14:32:17 TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_HOST}" Oct 30 14:32:24 RP, Do you know what the difference is between SITELIBEXP and, say, ARCHLIBEXP? Oct 30 14:32:31 while default bitbake.conf is using TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}" ? Oct 30 14:32:56 JaMa, I don't know 100%, presumably it compiles with files from your host (i.e. your "real" system) while other recipes use libs specific to Target. Oct 30 14:34:06 JaMa: bitbake.conf never used to. We should remove the duplication, patches welcome Oct 30 14:35:03 Stygia: arch is for architecture specific files, site is for site customisations which say the local admin has made Oct 30 14:36:00 RP, Site customization? What does "Site" mean in this context? Oct 30 14:36:19 RP: I think the default in bitbake.conf is used for target recipes only cross, native and few exeptions like *libc recipes are setting own value Oct 30 14:36:27 Stygia: think about a university or some large organisation with a perl "deployment" Oct 30 14:36:56 Stygia: they would be "sites" Oct 30 14:37:18 I'm trying to make MACHINE-specific tcmode selection working correctly with native/allarch recipes :/ Oct 30 14:37:23 RP, Ah, hmm right. Oct 30 14:37:28 JaMa: that default if for target recipes, yes Oct 30 14:38:04 there are more problems (different TOOLCHAIN_OPTIONS, vardeps on "CSL_VER_MAIN CSL_VER_GCC", different TARGET_PREFIX) than benefits sofar Oct 30 14:38:05 JaMa: native overrides the compiler/linker commands anyway and wouldn't use TOOLCHAIN_OPTIONS Oct 30 14:39:11 RP: so the patch should change STAGING_DIR_TARGET to STAGING_DIR_HOST in bitbake.conf or what you mean by "never used to"? it's there since 2010-08-12 Oct 30 14:40:32 JaMa: we only use --sysroot when cross compiling in the case TARGET = HOST so it doesn't really matter Oct 30 14:41:18 JaMa: I misunderstood your question and was meaning that before 2010, the external tc files set TOOLCHAIN_OPTIONS but bitbake.conf did not Oct 30 14:41:42 JaMa: HOST != TARGET only in cross-canadian iirc Oct 30 14:42:07 RP, Cross-canadian? :P Oct 30 14:43:09 Stygia: building with build != host != target, e.g. building binutils which generates arm binaries on a linux system but to run on mac OSX Oct 30 14:43:34 build != host != target != build :) Oct 30 14:43:57 JaMa: er, yes, that :) Oct 30 14:44:00 otherwise you can find triple with build == target Oct 30 14:44:03 bluelightning_: wanted to check with you regarding the recent rpm / perl issue, it seems there are 8 scripts in /usr/lib/rpm that need perl and we are seeing a Oct 30 14:44:03 no package provides /usr/bin/perl on the auto builder (Bug #5393), any thoughts? Oct 30 14:44:04 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=5393 major, Undecided, ---, saul.wold, NEW , do_rootfs fails for rpm image with: can't install rpm-5.4.9-r63@x86_64: no package provides /usr/bin/perl Oct 30 14:44:14 RP, I take it you meant cross-compilation, I just the the 'Canadian' pun pretty funny. Oct 30 14:44:23 sgw_: I have a fix in master for this Oct 30 14:44:41 RP: Ok thanks! Oct 30 14:44:44 Stygia: there is a cross-canadian class and recipes ;-) Oct 30 14:44:58 RP: ok, if I manage to work around other issues related to changing tcmode in machine.conf I'll send patch to align TOOLCHAIN_OPTIONS as well Oct 30 14:45:04 RP, Huh, really? Hah. Oct 30 14:45:42 JaMa: I'm not entirely sure changing tcmode in machine.conf is a good idea... Oct 30 14:45:52 I agree :) Oct 30 14:47:13 It wasn't my decision, I'm just trying to get more agruments to explain why it was bad decision and in the process find ways how to get the same signatures for native and allarch recipes at least Oct 30 14:48:00 RP: I see what you did, that's a clean fix, missed it when I was looking yesterday, I will close out that bug. Oct 30 14:49:15 Has anyone here successfully built an SDK for Qt5? Oct 30 14:50:28 not that I know of Oct 30 14:50:47 JaMa: I think STAGING_DIR_HOST is probably slightly more correct for bitbake.conf. I don't remember why we didn't do that though Oct 30 14:52:29 sgw_: we should probably fire a master build? Oct 30 14:52:33 JaMa, ok, that's unfortunate.. Is cross-compiling Qt5 outside of yocto my best option then? Oct 30 14:53:20 slips: these things are kind of hard and debugging our build of a qt5 sdk is probably the best option Oct 30 14:57:44 slips: https://github.com/meta-qt5/meta-qt5/wiki/SDK Oct 30 14:58:24 slips: you can cross-compile qt5 for your target just fine with meta-qt5 Oct 30 14:59:02 yeah, i've gotten the target sysroot up, ok Oct 30 14:59:13 i'm struggling with qmake Oct 30 14:59:36 zeddii: I think you're working on the worst possible 'yoctized' kernel ;) Oct 30 14:59:42 which seems to be the same problem as mentioned on the wiki. Oct 30 15:01:08 ant_work. I definitely don't disagree. I'm hoping to find a core issue in the .. mess :) Oct 30 15:02:26 JaMa, thanks for the link btw Oct 30 15:04:26 slips, sorry for off-topic, but what made you choose qt5 over qt4.8? Oct 30 15:04:54 slips: thanks for forcing me to finally grep IRC/E-mail logs to get list of people :) Oct 30 15:09:27 kbart, It's a new project and we want to use the latest stable version. We could've done it with 4.8 as we don't depend on all the fancy new qt quick stuff, but this is a product that will last for years. It's easier with newer versions. Oct 30 15:10:07 Also, we have this ex-trolltech guy at our office, and he's pushing us. ;) Oct 30 15:11:39 slips, I see thanks for confirming my thoughts ;) I was in a similar situation, but I chose qt4.8 as we also don't need "fancy new stuff" and it had much better cross-compiling support at the time the project started. Oct 30 15:11:49 JaMa: have you built m4-native in the last 4 days? Oct 30 15:12:15 ant_work: not from master, but I plan to test it after your report Oct 30 15:12:38 i very bad..no way to stop with ctrl+c...killall Oct 30 15:12:51 *is Oct 30 15:14:50 Hey, I am still not having any luck making do_compile finish for my libsql-abstract-perl recipe. Oct 30 15:14:52 This is the recipe: http://pastebin.com/Ex4N5BVM Oct 30 15:15:31 This is what I seed with bitbake -v libsql-abstract-perl: Oct 30 15:15:38 http://pastebin.com/BYhm9BZ2 Oct 30 15:15:51 It simply stops at do_compile, with the last line you can see. Oct 30 15:16:36 This is what I'm seeing with ps aux | grep -i make Oct 30 15:16:36 http://pastebin.com/pNLhG9uE Oct 30 15:16:42 Only shows when this is running. Oct 30 15:16:51 Does anyone have a suggestion on how I can proceed? Oct 30 15:18:03 Stygia: " /usr/bin/sudo /usr/bin/make install" ? Oct 30 15:18:19 Stygia: most are in the T state I note too Oct 30 15:19:15 RP, Yes, I don't know why exactly it runs that exact command. Oct 30 15:19:22 RP, What specifically is the T stage? Test? Oct 30 15:19:31 Stygia: It really shouldn't be doing that... Oct 30 15:20:07 Stygia, Hmm, right... Oct 30 15:20:12 Stygia: T state means its terminating Oct 30 15:20:13 It doesn't have my Sudo password. Oct 30 15:20:15 Aah... Oct 30 15:20:20 Ah, that's probably what it's hanging on, then. Oct 30 15:20:22 Stygia: I think the sudo command is hanging, right Oct 30 15:20:26 Waiting for my password. Seems likely? Oct 30 15:20:31 yes Oct 30 15:20:36 so why is it trying to install? Oct 30 15:20:44 Obviously the "correct" solution is sed my root password into the make script. Oct 30 15:20:44 fix that and you might be good Oct 30 15:20:48 ... I'm joking. Oct 30 15:20:55 Stygia: :) Oct 30 15:21:02 Stygia: I've seen worse :/ Oct 30 15:21:15 RP, Really? Oct 30 15:21:22 ant_work: have you already tried make-4.0 in OE builds? Oct 30 15:21:50 Stygia: I don't want to remember... Oct 30 15:21:57 RP, Hheh, right. Oct 30 15:22:15 RP, The only place it mentions sudo is in an inc/Module/AutoInstall.pm file... Oct 30 15:22:38 Although... Oct 30 15:22:47 PREFIX is set to /usr/ Oct 30 15:22:51 Should probably add ${D} to that. Oct 30 15:23:46 Stygia: the compile step shouldn't be installing, period Oct 30 15:24:11 JaMa: no, still on 3.82 Oct 30 15:24:13 Right... Oct 30 15:24:20 Any idea how can we add vivi kernel module to image? Oct 30 15:24:22 Well. I don't know, I am using cpan.bbclass Oct 30 15:24:27 Maybe I should try doing it manually. Oct 30 15:24:30 i.e. compiling manually. Oct 30 15:24:55 Stygia: I did try a build locally but am missing dependencies :/ Oct 30 15:25:16 RP, I could give you the recipes if you wanted. Oct 30 15:25:25 I have all of the necessary ones,though it is quite a long dependency chain. Oct 30 15:25:40 RP, I have so many perl recipes at this point... it's a bit of a pain to just look at, heh. Oct 30 15:26:13 Stygia: I can imagine. I'm not sure I have time to debug it, I just tried as I thought it might "just work" Oct 30 15:26:24 110 at an easy count. Oct 30 15:26:40 As in ls -l | grep -i lib | wc -l Oct 30 15:26:57 Where libX-perl is our custom perl libs - almost no duplicates left of core modules at this point. Oct 30 15:28:02 Ah, at least 102 of them are perl libs, we do have a few others too. Oct 30 15:37:39 JaMa: I've been using make4.0 in builds Oct 30 15:37:54 JaMa: only real issue I encountered was eglibc failing Oct 30 15:38:02 for which there is a bug report somewhere Oct 30 15:44:47 jackmitchell: thanks for info Oct 30 15:45:01 ant_work: it passes sanity test you reported broken with gentoo's 3.82 Oct 30 15:45:20 building eglibc now Oct 30 15:45:40 I had to revert, was not a build from scratch, though Oct 30 15:49:46 ant_work: m4-native built fine here Oct 30 15:50:21 what to say, better so ;) Oct 30 15:50:38 I'll retry from scratch once more Oct 30 15:56:06 RP, Hmm.... Just FYI in case you ever see a similar issue. Oct 30 15:57:12 RP, I haven't fixed it yet, but I triggered new errors by copying my RDEPENDS to DEPENDS. Oct 30 15:57:22 RP, Seems like it was trying to CPAN install the dependencies. Oct 30 15:57:28 RP, Seems like the origin of the make install stuff during compile. Oct 30 15:58:40 Stygia: ah, interesting. So if you add the right DEPENDS, it might not try installing things? Oct 30 16:01:30 Doesn't seem like it. Oct 30 16:01:40 RP, But, now I'm confused. Oct 30 16:01:53 It now fails with "Can't find in Carp.pm in @INC", then lists the INC. Oct 30 16:02:08 One path, /mnt/dev/fsl-community-bsp/build/tmp/sysroots/imx6qsabresd/usr/lib/perl/5.14.3, instantly returns a Carp.pm if I do find ... -name Carp.pm Oct 30 16:03:05 Stygia: that seems odd :( Oct 30 16:03:20 RP, Yea, it does. Oct 30 16:03:32 RP, Ah, at least in my experience getting a new error means progress. Oct 30 16:08:49 jackmitchell: something like this in building eglibc-initial? | *** These critical programs are missing or too old: make Oct 30 16:09:07 | checking version of make... 4.0, bad Oct 30 16:09:25 JaMa: yep Oct 30 16:09:36 JaMa: it's hard coded in the configure.in Oct 30 16:09:51 JaMa: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5391 Oct 30 16:09:52 Bug 5391: normal, Undecided, ---, saul.wold, NEW , eglibc failes to compile with autoconf 2.69 and make 4.0 Oct 30 16:10:16 it does a check for autoconf 2.68 and a check for make 3.* Oct 30 16:23:35 Hey, I am still having no luck. Oct 30 16:23:40 And this error message has be stumped. Oct 30 16:23:45 This is my recipe: Oct 30 16:24:04 http://pastebin.com/T59LVFzx Oct 30 16:24:14 I am getting this when running do_configure: Oct 30 16:24:29 And, yet, http://pastebin.com/QxhauKVJif I do find (first_thing_it_lists_from_@inc) - name Carp.pm, it's there. Oct 30 16:24:34 In fact it seems to be there in the native-perl one, as well. Oct 30 16:24:48 So I don't see wtf it's failing over. Oct 30 16:26:08 Anyone have any ideas? Oct 30 16:27:19 This paste has been removed! Oct 30 16:27:31 can you paste the error again? Oct 30 16:28:17 mr_science, http://pastebin.com/QxhauKVJ Oct 30 16:29:26 someone just handed me some birthday cards to sign... Oct 30 16:30:14 jackmitchell: I'll send patch for make-4 in a minute Oct 30 16:30:15 mr_science, Heh. Oct 30 16:30:33 For anyone's information, I have tried commenting out do_configure_append an the EXTRA_CPANFLAGS - no change. Oct 30 16:37:38 How can I emulate vivi v4l2 driver into my Image? Oct 30 16:38:10 There's code available http://v4l.videotechnology.com/vivi/vivi.c but, how can I port this to kernel? Oct 30 16:48:10 of course, as soon as i try and look at it things start hopping here... Oct 30 17:21:00 * mr_science still trying to see daylight Oct 30 17:25:56 bluelightning_: do we need to set EXCLUDE_FROM_WORLD in the dbus-ptest recipe? Oct 30 17:26:18 RP: I wondered about that, but it does build fine without ptest enabled Oct 30 17:26:41 bluelightning_: ok, fair enough Oct 30 17:26:58 bluelightning_: btw, on the quoting issue, that is rife within the metadata :( Oct 30 17:27:12 RP: hmm, this is the first one I've noticed FWIW Oct 30 17:27:33 I was surprised it was allowed, but I guess the overall assignment regex is greedy Oct 30 17:27:35 bluelightning_: look at bitbake.conf :( Oct 30 17:27:49 bluelightning_: I started fixing them, then found we have *lots* Oct 30 17:27:55 let me guess, it's the fact taht foo = 'bar baz '' foo' is valid? :) Oct 30 17:28:33 kergoth: pretty much yep Oct 30 17:29:10 bitbake's quote handling is pretty weak, basically if theres a leading and ending quote, strip them off. done. Oct 30 17:29:13 heh Oct 30 17:29:39 is bitbake a build system? Oct 30 17:29:44 * Crofton trolls Oct 30 17:29:54 * kergoth twitches Oct 30 17:30:23 Crofton: is someone claiming it is? ;) Oct 30 17:34:05 I saw a slide last week :) Oct 30 17:41:25 when does the movie come out? Oct 30 18:17:58 * mr_science coerces a marginal maven build Oct 30 18:44:52 Hey guys, got a systemd question Oct 30 18:45:25 what do i need to add to my configuration apart from: DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" Oct 30 18:45:51 I get all sorts of errors if I do just the above Oct 30 18:47:16 errors building an image recipe? Oct 30 18:48:10 errors when I make my image Oct 30 18:49:52 bombed out on some glibc thing .. trying again as we speak .. Oct 30 18:52:22 Garibaldi: Do I nned to add anything else to support systemd? Oct 30 18:53:55 brm: do you definitely have a leading space in the DISTRO_FEATURES_append value? i.e. " systemd" not "systemd" Oct 30 18:54:48 bluelightning: Yep Oct 30 18:55:02 and i assume your DISTRO_FEATURES_append is in local.conf? Oct 30 18:55:32 mr_science: Yes it is .. Oct 30 18:56:52 to be specific build/conf/local.conf Oct 30 18:57:40 well, i specifically made my rpi image recipes not to depend on systemd Oct 30 18:57:55 I also have a DISTRO_FEATURES line in there, can't I just add it in there? Oct 30 18:58:12 but afaik that should be the default for the more full-featured images Oct 30 18:58:26 efl, gnome, qtX Oct 30 18:58:33 mr_science: Doesn't help, I have a customer who requires systemd .. Oct 30 18:59:04 I am making a minimal custom image Oct 30 18:59:15 i would add it there and get rid of the _append Oct 30 18:59:34 mr_science: Yep .. trying that Oct 30 19:06:20 mr_science: So I only need those two lines, nothing else? Oct 30 19:07:52 mr_science: Actually the error I am getting is libtool-cross refuses to build Oct 30 19:08:54 if libtool-cross is failing to build, then everyting will fail to build, because your toolchain is hosed Oct 30 19:09:04 its almost always the first recipe to build that uses it :) Oct 30 19:09:46 ok, will trash my build directory and start the build again .. I suspected as much, as I mistakedly removed some of my tmp directory Oct 30 19:12:32 there's no reason to avoid wiping tmp in cases like that, particularly if your SSTATE_DIR is outside of it. reconstructing the tmpdir from sstate archives doesn't take long Oct 30 19:16:26 kergoth: SO how do you do that? Oct 30 19:17:49 that's the default in recent poky. the sstate-cache dir is in topdir, not tmpdir, so wiping tmpdir doens't remove it Oct 30 19:19:02 On another issue, I can't get my defconfig file in my layer to be used by the linux-mainline kernel build, and yes it is on my SRC_URI .. Oct 30 19:20:44 if you're using a bbappend, you have to define FILESEXTRAPATHS appropriately to get it to find it Oct 30 19:20:52 see many bbapepnds for xamples Oct 30 19:20:54 examples Oct 30 19:22:58 I have that FILEEXTRAPATHS set correctly, as I have kernel patches in the same place, and they are being used .. Oct 30 19:23:47 It just refuses to pick up the defconfig file ... even a *.cfg fragment file is ignored .. Oct 30 19:25:59 * kergoth shrugs, don't know enough about how the linux-yocto recipes function under the hood to say what could cause that Oct 30 19:26:45 It's not the linux-yocto kernel, my image uses the linux-mainline kernel Oct 30 19:27:38 It's for the beaglebone black, defined in meta-beagleboard Oct 30 19:28:18 best off reading the recipe and seeing what it's doing, then Oct 30 19:28:58 do I have to follow the same path, i.e linux/linux-mainline-3.8/beaglebone .... for my append Oct 30 19:30:00 The recipe has the following: FILESPATH =. "${FILE_DIRNAME}/linux-mainline-3.8:${FILE_DIRNAME}/linux-mainline-3.8/${MACHINE}:" Oct 30 19:40:40 kergoth: You still there? Oct 30 21:09:02 RP: about the patch for jffs2, pls note there is a syntax error Oct 30 21:09:23 *** 0013: alltypes.remove(a): <--- the colon Oct 30 21:16:24 i am experimenting with a non-yocto kernel and during the build, i get the following error: Oct 30 21:16:30 "Multiple .bb files are due to be built which each provide virtual/kernel" Oct 30 21:16:32 any ideas? Oct 30 21:20:57 ant_home: ok, thanks. I didn't test it, it was mainly to show you the idea... Oct 30 21:21:37 Trying to use systemd and get this error on boot: systemd[1]: Failed to mount /run: No such file or directory .. any ideas anyone? Oct 30 21:22:19 j8: you're trying to build two kernels. Something is wrong with your kernel recipe... Oct 30 21:23:12 RP: patch is ok, I just override it for collie Oct 30 21:23:21 thx Oct 30 21:25:00 ant_home: can you ack on list and I can then fix and merge... Oct 30 21:27:14 sure Oct 30 21:28:04 it's a bleeding edge kernel from kernel.org Oct 30 21:28:32 should it have inherit's beyond just "inherit kernel"? Oct 30 21:31:01 j8: did you set PREFERRED_PROVIDER_virtual/kernel to the replacement recipe? Oct 30 21:36:01 RP: tried that, but it didn't work Oct 30 21:37:06 i set PREFERRED_PROVIDER_virtual/kernel = "linux", and the recipe is named linux_3.11.bb Oct 30 21:39:31 so got systemd booting, but needed to manually add a /run directory, shouldn't the receipe do that? Oct 30 21:40:52 you would think so, since /run isn't part of the volatile config any more Oct 30 21:41:51 j8: where did you set it? Oct 30 21:41:56 so it's probably a bug then .. Oct 30 21:42:21 Oct 30 21:42:23 brm: sounds like something is wrong. The standard test systemd images do boot on the autobuilder though Oct 30 21:42:46 i'm pretty sure the systemd images get more exercise than not Oct 30 21:43:19 * mr_science will make another rpi image recipe with systemd Oct 30 21:43:48 RP: So apart from adding systemd to DISTRO_FEATURES abd VIRTUAL-RUNTIME-INIT_manager, what should I be adding? Oct 30 21:43:54 J8: i just renamed it to linux-bleeding_3.11, set the PREF...PROV..._virtual/kernel = "linux-bleeding", PROVIDES = "linux", and the warnings seemed to go away Oct 30 21:44:57 at the moment both init systems come up together .. systemd starts 4 seconds into the boot Oct 30 21:47:06 j8: ah, there is an issue with using "linux" as a recipe name :/ Oct 30 21:47:14 j8: its used in OVERRIDES :/ Oct 30 21:48:03 doesn't the sanity check warn you when you do that? Oct 30 21:48:10 kergoth: I thought we had one, yes... Oct 30 21:49:39 codehog: So you tried a rpi systemd image? Oct 30 21:49:47 RP, kergoth: is it in 1.4.2? Oct 30 21:50:08 not until i get home... Oct 30 21:50:28 kinda busy atm Oct 30 21:51:15 brm: you can see what the autobuilder does in http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder/tree/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py Oct 30 21:51:38 brm: DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"? Oct 30 21:53:27 thanks, regarding ..BACKFILL, yes thought of that, but what if some recipes still require init startup? Oct 30 21:53:59 brm: well, they you use both sysvinit and systemd as you are right now... Oct 30 21:54:07 brm: which DISTRO are you using? Oct 30 21:56:07 RP: No distro, using custom image on BBB and using meta-beaglebone Oct 30 21:58:14 brm: poky does add packagegroup-core-boot, I wonder if you're missing that and its causing the problem? Oct 30 21:59:07 RP: No have that .. Oct 30 22:01:49 brm: are you including layers like angstrom? Oct 30 22:02:21 RP: No .. don't want any "distro" Oct 30 22:03:06 brm: There appears to either be some missing piece, or something being overridden as I know the autobuilder tested images work... Oct 30 22:03:15 brm: what, I don't know though Oct 30 22:03:32 systemd booted up fine and I can start/stop services .... just the missing /run thing .. Oct 30 22:03:54 brm: right, but until you added that they didn't boot? Oct 30 22:04:07 RP: correct Oct 30 22:04:50 RP: Is there any image I can look at that sets up systemd? Oct 30 22:05:37 brm: you could build one of the ones as the autobuilder does. I don't know if the AB shares those systemd ones or not... Oct 30 22:06:12 RP: Not familiar with the autobuilder .. what is that? Oct 30 22:06:29 brm: http://autobuilder.yoctoproject.org:8011/waterfall Oct 30 22:06:36 thanks Oct 30 22:06:42 brm: we use it for regression testing Oct 30 22:06:43 For submitting patches that fix things with PR numbers we remove the PR numbers right? Oct 30 22:07:37 RP: Thanks .. got to go to a meeting .. thanks for the help .. cheers Oct 30 22:08:14 jwessel: PR numbers? you mean Yocto bug numbers? Oct 30 22:08:32 No I am fixing a couple recipes for native SDK and they have PR = "..." Oct 30 22:08:35 jwessel: sorry, with you now. We remove them when PV changes upwards Oct 30 22:08:37 From the master branch. Oct 30 22:08:45 Got it. Oct 30 22:08:58 So no PV change. That explains why I still see some of each :-) Oct 30 22:09:20 Technically I don't even need a PR bump to add nativesdk. Oct 30 22:09:35 jwessel: basically versions should not go backwards but PR server takes the strain now for bumping them Oct 30 22:10:03 We learned "the hard way" there were some binaries being copied from native to nativesdk for our custom sdk. Oct 30 22:10:23 jwessel: ouch :/ Oct 30 22:10:35 Those binaries will segfault when they see the other libc. Oct 30 22:10:43 Because of the $ORIGIN/... etc. Oct 30 22:11:28 It should have never happened in the first place. We got to delete a pile code as a result so it is all good. :-) Oct 30 22:12:00 jwessel: right, native binaries are built quite differently. Deleting code is generally nice :) Oct 30 22:15:03 thanks, all Oct 30 22:46:48 jwessel: did you mean to resend your patch from earlier today or is it a v2? Oct 30 22:47:36 Did I manage to send the wrong patch? Oct 30 22:47:39 hmm... Oct 30 22:47:46 * jwessel goes looking at the history. Oct 30 22:49:28 ls 0001* |wc -l Oct 30 22:49:29 23 Oct 30 22:49:42 time to clean up? Oct 30 22:49:46 That would be my problem. Yes. Oct 30 22:53:09 The .gitignore in the top of oe-core finally got me. Oct 30 22:53:24 I couldn't figure out why the patches were not going away with a git clean. Oct 30 22:53:41 The top level .gitignore has /*.patch Oct 30 23:53:34 looking for help with toolchains... Oct 30 23:54:37 I'm trying to use an older version of gcc and looking for some help Oct 30 23:58:43 if you're here later, i'll be around after my commute home... Oct 30 23:59:43 cool Oct 30 23:59:55 I'm in Australia, so should be here most of the day Oct 31 00:00:00 thanks :-) Oct 31 00:00:57 i should be leaving shortly for an hour drive, so i should be back (as nerdboy) by 1830 PDT give or take Oct 31 01:59:28 @nerdboy - let me know when you have time to chat :-) Oct 31 02:04:05 soon as my wife is tired of talking... Oct 31 02:05:00 so what are you trying to do? use an older/external toolchain? Oct 31 02:15:43 ha! Oct 31 02:16:12 so my goal is to get erlang running on a gumstix board Oct 31 02:16:32 but I've run into problems compiling erlang using bitbake Oct 31 02:16:57 peterwhitfield: what's the problem? Oct 31 02:18:09 actually, the problem is running configure - there's one point where test in configure shows an incompatibility with fross-compiling Oct 31 02:18:10 * nerdboy couldn't remember who asked which question... Oct 31 02:18:28 but, if I cross-compile erlang outside of bit bake it all works fine Oct 31 02:18:48 can you paste your recipe somewhee? Oct 31 02:19:26 the main difference I can see is that cross-compiling outside bit bake uses a slightly older version of gcc that the toolchain within yocto Oct 31 02:19:31 hold on Oct 31 02:19:37 will find github link Oct 31 02:19:48 that could possibly be the issue Oct 31 02:20:04 what specific versions of gcc? Oct 31 02:22:04 configure:21140: arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/home/peter/yocto/build/tmp/sysroots/overo -o conftest -O2 -pipe -g -feliminate-unused-debug-types -I/home/peter/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/erlang-R16B02-r0/otp_src_R16B02/erts/arm-poky-linux-gnueabi -D_GNU_SOURCE -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT Oct 31 02:22:04 -DPOSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -L/lib -R/lib -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -ldlpi -lutil -ldl -lm >&5 Oct 31 02:22:12 that's the error I get Oct 31 02:22:22 toolchain version of gcc is 4.7.2 I think Oct 31 02:22:43 and the host version (using ubuntu 12.04) is 4.6.3 Oct 31 02:23:12 okay, i'm on master which is gcc 4.8.1 Oct 31 02:23:15 ah, ignore that error - seems I pasted the wrong thing Oct 31 02:23:25 ok Oct 31 02:23:32 I'm using gumstix repo setup Oct 31 02:23:39 which gives 4.7.2 Oct 31 02:24:36 4.7 should be at least a tad bit more forgiving on a given piece of source Oct 31 02:24:54 *than 4.8.1 anyway Oct 31 02:24:59 trying to paste the error Oct 31 02:25:14 .../ld: warning: library search path "/lib" is unsafe for cross-compilation Oct 31 02:25:16 if you can paste the recipe i can try to build it Oct 31 02:25:36 you have a bad lib path Oct 31 02:25:46 https://github.com/joaohf/meta-erlang Oct 31 02:26:21 if I use the same commands from the recipe, but directly in the erlang directory, it uses the local gcc and works fine Oct 31 02:26:54 the equivalent flag when it works is '-L/lib64' iirc Oct 31 02:27:17 well, the cross linker will always fail if it finds the native libs Oct 31 02:27:22 https://github.com/joaohf/meta-erlang/blob/master/recipes-devtools/erlang/erlang_R16B02.bb Oct 31 02:27:45 well, it doesn't throw the same warning when I build locally...? Oct 31 02:28:21 or more accurately, when I run configure locally Oct 31 02:29:22 configure typically doesn't know squat about cross anything Oct 31 02:29:27 just running the same command locally to generate the successful result Oct 31 02:29:48 ok, so with erlang I'm not running configure directlyt Oct 31 02:30:23 running ./otp_build configure --xcomp-conf='./xcomp/erl-xcomp-oe.conf' Oct 31 02:30:47 where the conf file specifies the host and target architectures Oct 31 02:30:56 so erlang provides direct support for cross compiling Oct 31 02:31:15 okay... Oct 31 02:31:34 when I run that command in the erlang root directory as downloaded by bit bake, it works fine Oct 31 02:31:53 but when bit bake runs the same command, it throws that warning Oct 31 02:32:00 the only difference I can see is the toolchain Oct 31 02:32:18 so my thought was to try forcing bit bake to use the same toolchain that works locally Oct 31 02:32:20 which, if it works, it should not find any native libs... Oct 31 02:33:07 gimme a minute to clone that stuff Oct 31 02:33:45 thanks! Oct 31 02:34:10 when I run locally (as in otp_build directly) the log file gives this for the equivalent line: Oct 31 02:34:13 configure:21140: gcc -o conftest -g -O2 -I/home/peter/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/erlang-R16B02-r0/otp_src_R16B02/erts/arm-poky-linux-gnueabi -D_GNU_SOURCE -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -L/lib64 -R/lib64 conftest.c -ldlpi -lutil -ldl -lm >&5 Oct 31 02:34:14 gcc: error: unrecognized option '-R' Oct 31 02:34:36 so you can see it gives -L/lib64 in place of -L/lib Oct 31 02:37:09 btw, the log file I'm looking at is ERLROOT/otp_src_R16B02-r0/erts/config.log Oct 31 02:37:18 it doesn't fail because it's broken Oct 31 02:37:36 ? Oct 31 02:38:02 -I/path/to/arm-blah and -L/lib Oct 31 02:38:19 fail Oct 31 02:39:24 so any though as to why it works standalone but gives that result when run from the recipe? Oct 31 02:40:38 "stand-alone" needs to be one-and-only-one of a) full native or b) a cross-build against an sdk, etc Oct 31 02:42:08 trying bitbake erlang-native Oct 31 02:42:28 hmmm, ok, so I'll research the erlang 'stand-alone' process a bit more Oct 31 02:43:54 doing a manual cross-compile of a package using autotools/configure is a bit tricky Oct 31 02:43:57 ok, so when I look at the configure/build steps in erlang_R16B02.bb, they are in line with erlang's how to cross-compiling Oct 31 02:44:29 still fetching a butt-load of source code... Oct 31 02:44:34 is that my problem? I'm looking at the wrong file? Oct 31 02:44:49 hey, thanks for taking the time :-) Oct 31 02:46:13 so if I'm understanding correctly, the erlang-native recipe is using a standard configure/make approach Oct 31 02:46:42 whereas the one I've been looking at is using the erlang opt_build script Oct 31 02:47:03 which works for me outside of bitbake Oct 31 02:47:26 how can I tell which recipe is being used when I run bit bake? Oct 31 02:50:16 ok, so the log file says the task it is running when it fails is do_configure on erlang_R16B02.bb Oct 31 02:50:25 so seems to be doing what I thought it was doing Oct 31 02:51:04 do configure in that recipe is running ./otp_build with the same conf file I'm passing to it when I run it directly... Oct 31 02:52:26 you can "bitbake -b /path/to/recipe.bb -c build" to build a specific recipe/version Oct 31 02:52:53 also -c configure or -c compile etc Oct 31 02:54:38 okay, erlang-native is almost finished... Oct 31 02:56:03 basic question - how does bit bake choose between the two recipes? Oct 31 02:56:44 the two versions? Oct 31 02:57:05 maybe I'm not understanding the process properly... Oct 31 02:57:20 or native vs cross? Oct 31 02:57:46 there's the native bb file and the erlang_R16B02.bb file in the recipe directory Oct 31 02:57:57 yup Oct 31 02:58:19 okay, configure fail Oct 31 02:58:26 the non-native one clearly does a cross-compile Oct 31 02:58:34 what is the purpose of the native recipe? Oct 31 02:59:02 for native sysroot Oct 31 02:59:02 same failure? Oct 31 02:59:23 some packages require a native version to run during the build **** ENDING LOGGING AT Thu Oct 31 02:59:58 2013