**** BEGIN LOGGING AT Wed Jan 18 02:59:57 2012 Jan 18 05:01:52 Has anyone run into a "Package has no valid architecture, ignoring" messages when adding a new machine? Jan 18 05:12:12 nevermind, figured out that my /etc/opkg/arch.conf was still set to an old machine arch Jan 18 05:37:52 pb_|usa: adjusted to PST time shift already :) Jan 18 07:53:32 good morning Jan 18 14:22:01 otavio, hi Jan 18 15:10:25 bluelightning_, I just saw a checksum mismatch in qt Jan 18 15:11:33 hmm,qmake recipe in meta-oe is grabbing qt-4.7 Jan 18 15:50:05 Is the best way to build for two similar targets to twiddle BBPATH so that BitBake sees different conf/local.conf (or site.conf) files for the two? Jan 18 16:21:30 Crofton|work: are you sure it's genuine? Jan 18 16:32:23 \o/ Jan 18 16:34:40 trying to figure that out Jan 18 16:53:35 bluelightning, something goofy is up Jan 18 16:53:47 the file from tt has the bad checksum Jan 18 16:54:22 Crofton|work: hmm Jan 18 16:54:27 let me check what I have here Jan 18 16:54:44 Crofton|work: you are building 4.8.0 right? Jan 18 17:03:07 this is for qmake from meta-oe Jan 18 17:03:21 I grabbed the file and it has the same chacksum that the one the fetcher gets Jan 18 17:03:26 but that does not match recipe Jan 18 17:03:36 but direcorty via web has old file date Jan 18 17:03:39 wtf? Jan 18 17:03:58 [balister@moose ~]$ md5sum qt-everywhere-opensource-src-4.7.3.tar.gz Jan 18 17:03:58 49b96eefb1224cc529af6fe5608654fe qt-everywhere-opensource-src-4.7.3.tar.gz Jan 18 17:04:26 no 4.8? Jan 18 17:05:07 this is the recipe that builds qmake for the target Jan 18 17:06:06 4.8 builds fine, but I need qmake2 Jan 18 17:06:57 uhm? Jan 18 17:07:01 which version has 4.8 Jan 18 17:07:05 anyone have that file and can check the md5sum? Jan 18 17:07:11 momo Jan 18 17:07:14 hmm, I might have one also Jan 18 17:07:50 hm lol no qt4 version here Jan 18 17:10:53 interesting, the recipe is looking for the checksum for 4.4.3 Jan 18 17:11:13 hehe Jan 18 17:11:27 I guess bluelightning overaw it Jan 18 17:11:38 koen look slike from the log Jan 18 17:11:46 I tought I had buklit this, but maybe not Jan 18 17:11:59 fix fix Jan 18 17:13:06 yeah Jan 18 17:19:58 If i have a recipe that has "inherit module" and builds a kernel module Jan 18 17:20:16 How can I make it such that if I update my kernel package version, that recipe will be rebuilt? Jan 18 17:23:00 now I see | cc1plus: error: unrecognized command line option "-m64" Jan 18 17:23:04 building qmake2 Jan 18 17:23:14 dropping if from image until I sort this out Jan 18 17:57:06 Crofton|work: so what is the conclusion? Jan 18 17:57:12 (sorry was in a meeting) Jan 18 18:03:25 Crofton|work: so it was just the qmake recipe in meta-oe? Jan 18 18:05:01 hi, guys an ld process created by bitbake is using 66.3% of 4 Gb of RAM I have here according to top... and increasing... Jan 18 18:05:15 look slike it Jan 18 18:05:18 and that does not build Jan 18 18:05:24 I thought it worked once Jan 18 18:05:26 very confused Jan 18 18:06:22 what are you building? I've seen that happen in some extreme C++ linking cases (like Mozilla) Jan 18 18:06:23 pespin_: Is it linking Qt, perhaps? I remember its link phase taking a very long time on my build systems. Jan 18 18:06:33 now I see | cc1plus: error: unrecognized command line option "-m64" Jan 18 18:06:44 crops up when I build it Jan 18 18:06:51 mdpoole, no idea as I have BB_THREADS=4 Jan 18 18:07:06 that sounds fmailiar Jan 18 18:08:06 you should be able to use something like "ps fxw" to see which ld is using that much memory Jan 18 18:10:25 mdpoole, make -f Source/WebCore/CMakeFiles/webcore Jan 18 18:10:53 sounds like that might be mozilla, as fray suggested Jan 18 18:10:57 it's cut by the screen Jan 18 18:14:52 mdpoole, fray could it be webkit-efl? it just failed which an incredibly huge log file which is being printing since around 40 seconds... Jan 18 18:15:04 and still continues Jan 18 18:15:06 yes Jan 18 18:15:40 Crofton|work: I'm starting to wonder if I should try to work the target build of qmake into our existing qt recipes somehow Jan 18 18:15:52 Crofton|work: would save this sort of pain Jan 18 18:18:30 bluelightning, I strongly agree Jan 18 18:18:37 this is dumb Jan 18 18:18:59 the recipe in meta-oe is for a different version, I am not sure it will even work Jan 18 18:28:15 hay Jan 18 18:30:16 yo Jan 18 18:38:12 the cover is a little off white Jan 18 18:55:14 GNUtoo: 'lut Jan 18 18:56:33 GNUtoo: have progressed a little, but now am at Makefile:144: *** commands commence before first target. Stop. Jan 18 18:56:46 GNUtoo: I guess that' because of a wrong path Jan 18 18:57:15 cs_nbp which recipe? Jan 18 18:58:27 woglinde: copied it over from classic to a meta layer of oe-core http://git.openembedded.org/openembedded/tree/recipes/emacs Jan 18 18:58:33 and now try to adjust it Jan 18 18:59:45 emacs_23.1.bb Jan 18 18:59:48 on that site Jan 18 18:59:57 ah right Jan 18 19:00:07 than check the configure log Jan 18 19:00:13 or what is emacs using? Jan 18 19:00:22 y, config.log Jan 18 19:02:17 theres something like this conftest.c:83:22: fatal error: maillock.h: No such file or directory Jan 18 19:02:18 compilation terminated. Jan 18 19:03:21 also conftest.c:79:27: fatal error: malloc/malloc.h: No such file or directory Jan 18 19:03:22 compilation terminated. Jan 18 19:04:31 all sorts of those w different pkgs Jan 18 19:07:17 first one is conftest.c:11:28: fatal error: ac_nonexistent.h: No such file or directory Jan 18 19:07:55 under configure:4135: checking how to run the C preprocessor Jan 18 19:08:04 everything else before is successful Jan 18 19:08:41 i suspect the line Jan 18 19:08:44 TREEDIR = "${WORKDIR}/qemu-treedir" Jan 18 19:09:21 has to be set to the right values, currently it points to build/tmp-eglibc/sysroots/i686-linux Jan 18 19:09:48 with an absolute path in front of that Jan 18 19:10:56 sry, the line is in emacs.inc Jan 18 19:14:53 It's pretty common for autoconf to generate message like that in config.log, even on a normal run. Jan 18 19:15:08 What does ${S}/Makefile (or whichever Makefile triggered the earlier error) look like around line 144? Jan 18 19:15:55 sry will take a little moment, rebuilding tmp/ Jan 18 19:50:12 omg have -j1 instead of -j4 Jan 18 19:51:04 a PARALLEL_MAKE in local.conf should fix that right up Jan 18 20:07:52 # Where to install and expect the info files describing Emacs. In the Jan 18 20:07:53 # past, this defaulted to a subdirectory of ${prefix}/lib/emacs, but Jan 18 20:07:53 # since there are now many packages documented with the texinfo Jan 18 20:07:53 # system, it is inappropriate to imply that it is part of Emacs. Jan 18 20:07:55 infodir=/usr/share/info Jan 18 20:07:57 INFO_FILES=ada-mode auth autotype calc ccmode cl dbus dired-x ebrowse \ Jan 18 20:07:59 ediff efaq eintr elisp emacs emacs-mime epa erc eshell eudc \ Jan 18 20:08:01 flymake forms gnus idlwave info mairix-el message mh-e \ Jan 18 20:08:03 newsticker nxml-mode org pcl-cvs pgg rcirc reftex remember \ Jan 18 20:08:05 sasl sc ses sieve smtpmail speedbar tramp url vip viper \ Jan 18 20:08:07 re Jan 18 20:08:07 widget woman Jan 18 20:08:08 whoa, pastebin Jan 18 20:08:11 # Directory for local state files for all programs. Jan 18 20:08:14 localstatedir=/var Jan 18 20:08:16 flymake is line 144 Jan 18 20:08:18 haayZ Jan 18 20:08:20 yes almost Jan 18 20:09:19 pastebin Jan 18 20:09:22 ok Jan 18 20:09:32 the whole thing? or next time Jan 18 20:09:33 That looks like valid Makefile syntax. Are you sure the "commands commence before first target" was for that one? Maybe it was for a recursively called Makefile? Jan 18 20:09:40 next time Jan 18 20:09:48 ill try to figure out Jan 18 20:10:40 If you look a bit earlier and later in the compile log, it will probably talk about entering or leaving directories. Jan 18 20:16:44 actually I'm getting only the above mentioned fatal errors about not finding headers Jan 18 20:16:48 and mkdir /var/tmp/csieben/oe/tmp/sysroots/i686-linux Jan 18 20:16:48 mkdir: cannot create directory `/var/tmp/csieben/oe/tmp/sysroots/i686-linux' Jan 18 20:18:08 ah forgot a 'build' in the path Jan 18 20:19:46 basically i need to know what this 'TREEDIR' variable is, so I can set it to the right value Jan 18 20:19:59 in emacs.inc Jan 18 20:20:19 I'm sure that's where it goes wrong Jan 18 20:22:05 TREEDIR looks like a scratch directory tree where qemu can run the build version of emacs (for the undumping, I guess?) Jan 18 20:22:27 so it has to be one of the sysroots, right? Jan 18 20:22:42 no, the emacs.inc recipe wipes it out and recreates it Jan 18 20:23:03 probably the reason it doesn't find stuff afterwards Jan 18 20:23:24 so where could I set it to without creating such kind of damage Jan 18 20:24:03 I'd keep it at ${WORKDIR}/qemu Jan 18 20:24:21 nothing else should care about what is there Jan 18 20:31:51 yes, now getting 'commands commence before first target. Stop.' in lo.do_compile and configure:3579: arm-oe-linux-gnueabi-gcc -march=armv5te -mthumb -mthumb-interwork -mtune=xscale --sysroot=/var/tmp/csieben/o Jan 18 20:31:51 e/build/tmp/sysroots/netbookpro -V >&5 Jan 18 20:31:51 arm-oe-linux-gnueabi-gcc: fatal error: no input files in config.log Jan 18 20:32:32 workdir seems to be /var/tmp/csieben/oe/build/tmp/work/armv5te-oe-linux-gnueabi/emacs-23.1-r0/emacs-23.1/lib-sr Jan 18 20:36:23 http://pastebin.com/dhLASfeh line 144 (still the error line) is the line under ALL_CFLAGS Jan 18 20:42:36 there shouldn't be a newline after the -DHAVE_CONFIG_H on any of those lines Jan 18 20:43:07 that looks like a bug in the configure.in (or configure.ac) file Jan 18 20:45:07 (possibly also in Makefile.in or in how m4 translates Makefile.in to Makefile) Jan 18 20:46:34 m4 or sed or whatever the heck autoconf uses for that translation Jan 18 20:53:10 looks better: make[1]: qemu-arm: Command not found Jan 18 20:53:28 seems I'm missing some qemu stuff, question is if on my system or in the build Jan 18 20:56:50 and u were right, the error originated in Makefile.in Jan 18 20:57:25 it had '\' in the lines which probably get interpreted in the wrong way Jan 18 20:58:44 \ at the end of a line in Makefile.in should work Jan 18 21:03:03 is that 'qemu-kvm-extras-static' what I need on my system? Jan 18 21:03:14 or is my build env missing something? Jan 18 21:04:23 I'm not sure; I don't use qemu, and my OE builds don't need it Jan 18 21:04:59 well normally I'm not using it either, but the recipe complained Jan 18 22:34:15 mdpoole: still there? Jan 18 22:35:22 I adjusted the Makefile and Makefile.in so they don't fail because of '\' any more, and now arrived at make[1]: *** No rule to make target `arm-oe-linux-gnueabi-gcc', needed by `movemail.o'. Stop. Jan 18 22:35:35 though arm-oe-linux-gnueabi-gcc can be found in the tree Jan 18 22:36:05 than you did something wrong Jan 18 22:36:35 yes I figured that much, the question is if there is a hint on where I can start to look Jan 18 22:41:10 read about Makefiles? Jan 18 22:41:20 looks like $CC is a target somewhere Jan 18 22:41:45 and dont edit Makefile it will be overwritten bei Makefile.in Jan 18 22:42:04 that's why I edit that too Jan 18 22:43:06 how can I build kernel modules with bitbake / oe? Jan 18 22:43:18 I'm talking about in-tree modules which have been enabled. Jan 18 22:43:33 those should be built automatically when you build the kernel Jan 18 22:43:48 you can use the devshell recipe to go to the build tree Jan 18 22:43:53 er, devshell command Jan 18 22:44:24 mdpoole: I did a bitbake -v -f -c compile virtual/kernel Jan 18 22:44:35 and I can't seem to find them in the tmp/work directory Jan 18 22:45:28 you probably don't need the "-f -c compile" bit Jan 18 22:46:10 I'll give that a shot Jan 18 22:46:11 my makefile rule just runs commands like "bitbake virtual/kernel" Jan 18 22:46:14 no Jan 18 22:46:19 barfs Jan 18 22:46:33 "Nothing PROVIDES 'compile'" Jan 18 22:46:52 I'm using Angstrom / oe if that matters (and it might!) Jan 18 22:47:01 I'm coming from buildroot, so this is all new to me. Jan 18 22:48:59 devshell put me where I was before.. Jan 18 22:49:01 and Jan 18 22:49:14 make -f -c compile virtual/kernel does not build modules Jan 18 22:49:22 make == bitbake, sorry Jan 18 22:49:28 u need to type bitbake virtual/kernel without a compile in there Jan 18 22:49:33 bitbake -c build Jan 18 22:49:46 and you will find all stuff in the package-dir Jan 18 22:50:50 woglinde: will that build the world Jan 18 22:50:51 ? Jan 18 22:51:04 bitbake -c build virtual/kernel Jan 18 22:51:07 of course Jan 18 22:51:14 good nite Jan 18 22:52:31 perhaps the arm-oe-linux-gnueabi-gcc thing comes from another line in the makefile that uses \ Jan 18 22:52:49 if $(CC) is on the next line, make might think that is the target for a new rule Jan 18 22:53:22 meanwhile I looked over again and found two or three more '\', plus some without a '\' but going over several lines, not one Jan 18 22:53:36 ill check all lines around CCs now ;) Jan 18 22:54:19 guess thats not okay: .c.o: Jan 18 22:54:20 ${CC} -c ${CPP_CFLAGS} $< Jan 18 22:54:26 on two lines Jan 18 22:54:38 that should be fine Jan 18 22:54:58 although I'm wondering if maybe your makefile has some DOS-style line endings Jan 18 22:55:52 I hope not I git cloned it from git.openembedded Jan 18 22:56:06 and there is no computer w something like 'DOS' here Jan 18 22:56:32 ah no the makefile gets created on the run Jan 18 22:56:48 but the recipe comes from git.oe Jan 18 22:58:05 I'm just at a loss to explain why \ might have caused those problems Jan 18 22:59:24 I'm not getting it either Jan 18 22:59:40 CC=arm-oe-linux-gnueabi-gcc -march=armv5te -mthumb -mthumb-interwork -mtune=xscale --sysroot=/var/tmp/csieben/oe/build/tmp/sysroots/netbookpro Jan 18 23:00:00 could this line point to the wrong dir? thats not where arm-oe-linux-gnueabi-gcc is Jan 18 23:00:25 arm-oe-linux-gnueabi-gcc should be in $PATH when make runs Jan 18 23:00:56 in my system $PATH? Jan 18 23:01:05 ok Jan 18 23:01:08 depends on what you mean by system Jan 18 23:01:24 i mean the pc Jan 18 23:01:28 and its os Jan 18 23:01:52 or you mean BBPATH or some other PATH var? Jan 18 23:02:04 bitbake and OE generate a bunch of scripts in tmp/work/$target/$package/temp/ Jan 18 23:02:07 it's kinda confusing, but just a bit Jan 18 23:02:19 things like run.do_compile Jan 18 23:02:45 and those scripts should add the right sysroot(s) to PATH Jan 18 23:02:59 (along with setting a lot of other environment variables) Jan 18 23:03:34 as a crutch i could set it manually? Jan 18 23:03:38 those scripts should guarantee that arm-oe-linux-gnueabi-gcc is in the path before they run make Jan 18 23:04:03 you could, but I don't think it being on the path (or not) is the problem Jan 18 23:04:29 "No rule to make target `arm-oe-linux-gnueabi-gcc'" sounds like make thinks it is supposed to create arm-oe-linux-gnueabi-gcc Jan 18 23:05:22 (it shouldn't generate that, so the problem suggests some other Makefile corruption is going on) Jan 18 23:06:07 I suppose it can't find it and then tries to generate and then finds out it doesn't know how to Jan 18 23:06:43 btw theres like 10-15 run.do_compile.XXXXX Jan 18 23:06:50 X being a number Jan 18 23:07:15 yeah, every time you run the "compile" stage in bitbake, OE will generate one of those files Jan 18 23:07:35 XXXXX is the process id for one of the bitbake tasks Jan 18 23:08:16 make is very literal, though. If you tell it to use arm-oe-linux-gnueabi-gcc, make will try to use it. make will only try to generate that file if it sees a rule for it, and emacs's Makefile.in shouldn't have such a rule. Jan 18 23:10:35 the gnueabi is not in the exported PATH in run.do_compile Jan 18 23:10:42 in the latest ;) Jan 18 23:12:22 hm, normally gcc is somewhere like .../tmp/sysroots/x86_64-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-gcc Jan 18 23:12:51 is there no such directory in the exported PATH, or is your cross-gcc somewhere else? Jan 18 23:12:59 mine is here tmp/sysroots/i686-linux/usr/libexec/armv5te-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.3/arm-oe-linux-gnueabi-gcc Jan 18 23:14:38 and thats not in the export PATH Jan 18 23:15:16 is something like tmp/sysroots/i686-linux/usr/arv5te/bin/ in the export PATH? Jan 18 23:15:21 *armv5te Jan 18 23:16:35 tmp/sysroots/i686-linux/usr/bin/armv5te-oe-linux-gnueabi only this with armv5te in it Jan 18 23:17:19 but now found some other places where arm-oe-linux-gnueabi-gcc is, too Jan 18 23:17:46 Hm, I'm not sure which of these differences are caused by different OE distros or machines, by OE classic vs layers, or by an actual problem Jan 18 23:17:46 tmp/sysroots/i686-linux/usr/bin/armv5te-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc Jan 18 23:18:08 well, that directory is in the export PATH Jan 18 23:18:13 yes Jan 18 23:18:20 thats y it struck my eye Jan 18 23:18:22 so make should be able to find that cross-gcc Jan 18 23:18:27 y Jan 18 23:18:34 but it tries to compile it Jan 18 23:18:38 somehow Jan 18 23:19:45 when you were editing Makefile.in, were there any places that you changed something like this: Jan 18 23:19:49 target.o: target.c Jan 18 23:19:58 ${CC} yadda yadda Jan 18 23:20:03 to something like this? Jan 18 23:20:09 target.o: target.c ${CC} yadda yadda Jan 18 23:20:17 yes like 10 or so Jan 18 23:20:23 that would cause the error message you saw Jan 18 23:20:48 well I had that bfore I edited anything too, it was the reason I started Jan 18 23:21:00 I'll start clean again Jan 18 23:24:20 so I should change (in Makefile.in) Jan 18 23:24:47 trala.o: trala.c \ Jan 18 23:24:50 yada Jan 18 23:24:52 to Jan 18 23:24:58 trala.o: trala.c Jan 18 23:24:59 yada Jan 18 23:25:09 no Jan 18 23:25:38 could you pastebin the lines (or sections) you have questions about? Jan 18 23:25:48 y i will Jan 18 23:26:25 but will take a little, checking out the recipe again to have a clean start Jan 18 23:28:39 ah dam and pseudo rebuild sry Jan 18 23:29:53 btw is there there a command to be issued between bitbake -b attempts? or can I do one fail after the other? Jan 18 23:30:23 so far I delete most stuff in tmp/ and sstate-cache Jan 18 23:30:40 which takes a lot of time to rebuild Jan 18 23:30:55 if you're just fiddling with one recipe, you can run "bitbake -c clean packagename" Jan 18 23:31:09 that should delete just the working area for that package Jan 18 23:31:25 I tried that but cleaning doesn't work and stops w an error Jan 18 23:37:25 ok i have everything setup clean, it complains about arm-oe-linux-gnueabi-gcc not being there, but this time it's right. Jan 18 23:38:28 I got that automatically while building the kernel, is there a way to trigger only this? Jan 18 23:38:39 or do I have to do a menuconfig Jan 18 23:38:49 cd .. Jan 18 23:57:12 hi JaMa Jan 19 00:00:27 cs_nbp: do a bitbake -c clean on the package Jan 19 00:01:40 toofar: he's tried, it fails. Jan 19 00:02:56 well right now it wont matter, I cleaned up and it's the first build (as soon as menuconfig finished making me a crosscompiler) Jan 19 00:03:19 we'll see if that error is still there Jan 19 00:04:00 iirc the error was: nothing PROVIDES Jan 19 00:04:08 and I gave full path to the package Jan 19 00:04:44 like bitbake -c clean dir/dir/app.bb Jan 19 00:16:14 03Lianhao Lu  07master * rb310382764 10bitbake.git/lib/bb/persist_data.py: Jan 19 00:16:14 bitbake/persist_data: Reconnect when DB is locked Jan 19 00:16:14 [YOCTO #1761] Jan 19 00:16:14 Reconnect to the backend Sqlite DB in 'database is locked' exception so Jan 19 00:16:14 the timeout can be leveraged in each time retry. Jan 19 00:16:15 Signed-off-by: Lianhao Lu Jan 19 00:16:15 Signed-off-by: Richard Purdie Jan 19 00:19:29 short monent, just finish fighting against LIC_FILES_CHKSUM Jan 19 00:23:15 ok, I'm back at 'Makefile:144: *** commands commence before first target. Stop.' which looked like this http://pastebin.com/dhLASfeh Jan 19 00:23:34 line 4 is line 144 Jan 19 00:23:58 in Makefile.in those lines have a '\' at the end Jan 19 00:30:33 like that http://pastebin.com/ftjr4Gxc Jan 19 00:31:08 should I remove those, since they seem to be misinterpreted Jan 19 00:31:10 ? Jan 19 01:45:55 k enough for today, gn8Z **** ENDING LOGGING AT Thu Jan 19 02:59:57 2012