**** BEGIN LOGGING AT Wed Aug 08 02:59:58 2012 Aug 08 05:56:35 Anyone doing webstuff with python and lighttpd? I need to do some simple webstuff on my embedded system (browse files on disk, upload new software), and try to find out what frameworks are well supported in oe Aug 08 08:12:24 khem: I'll inspect the armv4 binary failing on sa1100 with readelf, though it runs on armv5te (gcc 4.7 patched with http://tinyurl.com/cck7znl) Aug 08 08:44:52 morning all Aug 08 09:50:26 morning all Aug 08 09:54:44 I am new to Open Embedded Aug 08 09:55:04 assigned to work on it to develop Os for embedded systems Aug 08 09:55:19 help me in getting started Aug 08 10:05:12 hi pb_ Aug 08 10:10:55 hi bluelightning Aug 08 10:38:03 hi Aug 08 10:38:17 is it possible to mask to different paths using BBMASK? Aug 08 10:38:44 -to+two Aug 08 10:39:27 somehow it doesn't work for me, if i try to set multiple paths seperated by a space Aug 08 10:40:15 MaxPowers: it's a regex, you need to split multiple paths with | Aug 08 10:40:15 it's a regular expression Aug 08 10:40:55 an example: Aug 08 10:40:59 BBMASK = "meta-raspberrypi/recipes-multimedia/libav|meta-raspberrypi/recipes-core/systemd" Aug 08 10:41:09 ok so BBMASK = "path1|path2" should work? Aug 08 10:41:11 ah ok Aug 08 10:41:18 thx Aug 08 10:41:22 yep, I know the above example works at least :) Aug 08 10:44:25 allright, yes it works Aug 08 13:28:16 Hi. I'm trying to build linux 3.5. I get an error like "cc1: error: include location "/usr/local/include" is unsafe for cross-compilation [-Werror=poison-system-directories]". Has anybody stumbled upon that? Aug 08 13:31:43 full log here: http://paste.debian.net/182764/ Aug 08 13:56:11 perf doing something silly? Aug 08 14:49:32 hi all... it might be just me, bit it seems there are conflicts in oe-core/recipes-support and meta-openembedded/meta-oe/recipes-support Aug 08 14:50:03 i'm initializing a new build env, and it first needed to build pseudo, which had a dependency sqlite3 (which gets expanded to sqlite3-native somehow) Aug 08 14:50:35 however there was no recipe for sqlite3, there were recipes for sqlite though.. in oe-core it was for sqlite 3, in meta-openembedded it had one for sqlite2 Aug 08 14:50:47 i've had to BBMASK the one from meta-openembedded to be able to move on Aug 08 14:51:09 (in general, it seems there's a lot of inconsistencies in the current git master branches of the various oe layers, or am i doing something horribly wrong???) Aug 08 14:51:55 gmc: hmm, I wouldn't expect a problem there Aug 08 14:52:00 what was the actual error? Aug 08 14:52:38 the -native thing comes in because what we're actually building is pseudo-native Aug 08 14:52:53 hmm i've had loads.. i didn't record them all.. at least it's compiling now Aug 08 14:53:03 ERROR: Nothing PROVIDES 'sqlite3-native' Aug 08 14:53:09 was part of the error message Aug 08 14:53:21 I think you'd find the error was before that in the output Aug 08 14:53:38 there is a known bug right now where parse errors do not stop the build Aug 08 14:53:43 this came from a DEPENDS in meta/recipes-devtools/pseudo/pseudo.inc Aug 08 14:53:51 that's totally legit though Aug 08 14:53:56 where it indeed had DEPENDS="sqlite3" Aug 08 14:54:03 correct Aug 08 14:54:08 but nowhere could i find a recipe for sqlite3 in oe-core and openembedded-meta Aug 08 14:54:38 gmc: what about recipes-support/sqlite/sqlite3_3.7.13.bb ? Aug 08 14:54:42 it is there... Aug 08 14:54:49 yes, but that's 'sqlite' not 'sqlite3' Aug 08 14:55:03 the directory name is not significant Aug 08 14:55:04 oh wait Aug 08 14:55:09 you're right.. that's what it is usinf now Aug 08 14:55:24 only PN which by default is derived from the recipe file Aug 08 14:55:31 but on meta-openembedded/meta-oe/recipes-support/sqlite it has sqlite 2 Aug 08 14:55:46 and apparently bitbake was only picking up that one, and not the one in core Aug 08 14:55:49 right; but there PN = "sqlite" not "sqlite3" Aug 08 14:55:55 no, that could not have happend Aug 08 14:55:58 happened Aug 08 14:56:07 ok, then P=NP and TRUE=FALSE :) Aug 08 14:56:31 i added a BBMASK to my bblayers explicitly excluding the sqlite2 recipe dir, and it stopped complaining and is now compiling pseudo Aug 08 14:56:50 gmc: what BBMASK did you set? Aug 08 14:58:05 BBMASK = "(recipes-gnome|recipes-benchmark|recipes-graphics|recipes-multimedia|recipes-navigation|recipes-qt|recipes-sato|meta-openembedded/meta-oe/recipes-support/sqlite|meta-efl)" Aug 08 15:01:24 i've also had to change a thing or two in meta-kirkwood btw, but that's 3rd party i guess Aug 08 15:01:31 (unrelated to the sqlite thing) Aug 08 15:01:34 gmc: erm, you've just masked out most of meta-oe there... so you haven't just masked out one recipe Aug 08 15:02:11 oh yes, before it was the same except for the second to last term that excludes sqlite Aug 08 15:02:12 trust me, there is no possible way the sqlite recipe in meta-oe could have interfered with the sqlite3 one in OE-Core Aug 08 15:02:22 I know, because I regularly build with those two layers enabled together Aug 08 15:02:47 odd.. i shall try to investigate then what i might have done wrong Aug 08 15:03:06 it doesn't make sense to me that they should conflict either, but oe is quiet a complex beast that i'm still trying to comprehend fully :) Aug 08 15:03:20 gmc: as I said above, I suspect you have been a victim of the parse error issue... I would suggest looking earlier in the log when the failure occurs Aug 08 15:04:15 lemme check Aug 08 15:04:27 there's two warnings during the parsing stage Aug 08 15:04:44 one about Variable get_layers contains tabs, please remove these (...../angstrom-version.bb) Aug 08 15:04:57 and one about checksum for omap3-mkcard SRC_URI entry omap3-mkcard.sh Aug 08 15:05:28 (sorry for abbreviating, i can't copy-paste from the build machine easily) Aug 08 15:25:32 gmc: I think the first one is actually a fatal error Aug 08 15:25:50 are you using the latest meta-angstrom? Aug 08 19:09:36 bluelightning_: yep, latest as in git cloned earlier today Aug 08 19:09:43 master branch Aug 08 19:10:21 bluelightning_: it wasn't fatal though, if the WARNING on the beginning of the line is to be believed :) **** ENDING LOGGING AT Wed Aug 08 20:13:49 2012 **** BEGIN LOGGING AT Wed Aug 08 20:14:16 2012 **** ENDING LOGGING AT Wed Aug 08 20:41:31 2012 **** BEGIN LOGGING AT Wed Aug 08 20:42:22 2012 Aug 08 21:52:58 sakoman: howdy long time Aug 08 22:01:16 khem: http://paste.debian.net/182840/ Aug 08 22:01:55 this binary runs on armv5te but fails on collie / sa1100 Aug 08 22:02:24 note I patched to have Tag_CPU_name: "ARM9TDMI" Aug 08 22:09:05 ant__: Tag_CPU_arch: v4T Aug 08 22:09:14 and I think your cpu is ARMv4 IIRC Aug 08 22:10:05 ant__: ok there is a patch to force the defaults of gcc to be arm9tdmi Aug 08 22:10:16 ant__: apply that patch to gcc and rebuild the image Aug 08 22:10:25 see if that helps Aug 08 22:10:47 I expect that we have specifies the needed mcpu everywhere but we might have missed in few places Aug 08 22:10:52 and this would fix that Aug 08 22:11:28 I think we could use --with-cpu option when compiling gcc and its runtime **** ENDING LOGGING AT Thu Aug 09 02:59:59 2012