**** BEGIN LOGGING AT Fri Nov 11 02:59:57 2011 Nov 11 07:50:26 Hi, fellows! Nov 11 07:51:27 Do anybody have a kernel compilation error after disabling loadeble modules? Nov 11 07:53:16 http://pastebin.com/KmFa8PQY Nov 11 08:55:52 mornin Nov 11 08:57:04 Jin^eLD: morning Nov 11 09:02:50 good morning Nov 11 09:02:58 hi florian Nov 11 09:07:25 morning all Nov 11 09:07:34 gm Nov 11 09:07:40 gm Nov 11 10:38:49 hi mickey|office, florian, all Nov 11 10:39:00 good morning pb_ ! how's it going? Nov 11 10:39:18 what's new from the house contstruction department? Nov 11 10:40:51 good morning Nov 11 10:42:41 hi pb_ Nov 11 10:43:38 hi mckoan Nov 11 10:43:53 mickey|office: you are alive?! :) Nov 11 10:47:39 mickey|office: Ruth is painting my new study at the moment :-) Nov 11 10:52:08 guys, maybe someone can have a look http://pastebin.mozilla.org/1380169 why exactly does oe_runmake fail? I only see a warning but no compile error? or is the warning already enough? also interesting that the log points to itself :) i.e. see log at the end of the file Nov 11 10:52:59 or is it actually the sh: scripts/unifdef: No such file or directory thing? Nov 11 10:55:40 Looks like this is the reason... Nov 11 10:56:18 thanks hmm, I guess my kernel recipe is borked then (this log is from an out of tree kernel module) Nov 11 11:16:26 I don't get it, what exactly is supposed to build the unifdef script? Nov 11 11:27:08 I see in some recipes that do_make_scripts is supposed to take care of it Nov 11 11:27:34 but calling it did not do anything for me Nov 11 11:27:36 weird Nov 11 12:23:09 it seems that unifdef does exist in ${STAGING_DIR_NATIVE}${bindir}/unifdef but is expected in ${STAGING_KERNEL_DIR}/scripts/unifdef Nov 11 12:23:19 not sure if it is a bug in one of my recipes or a general problem Nov 11 13:11:19 ~ugt Nov 11 13:11:19 extra, extra, read all about it, ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html Nov 11 13:12:17 ~botsnack Nov 11 13:12:17 bluelightning: thanks Nov 11 13:12:39 damn it now I'm hungry :( Nov 11 13:18:09 florian: sure, i'm alive :) just somewhat busy these days. towards the end of the year clients find budgets they need to spend... Nov 11 14:28:11 morning kergoth_ Nov 11 14:38:43 I wonder how people would react tot he commit message "I forgot why I did this, but I need it to build ...." Nov 11 14:38:53 :)) Nov 11 14:39:32 isn't that the "commit message" of the politicians around the world lately? :> Nov 11 14:40:12 based on that you could probably safely go ahead ;) Nov 11 14:43:04 heh Nov 11 14:48:31 bluelightning, http://pastebin.com/uFEUhcTw is needed to get qt target sdk working Nov 11 14:50:03 Crofton|work: I'm confused... those aren't host binaries in your situation? Nov 11 14:50:13 no Nov 11 14:50:27 bluelightning: git://gitorious.org/sysmocom-openembedded/meta-telephony.git, could you add that to your layer wiki page? Nov 11 14:50:41 zecke: certainly, I will do that now Nov 11 14:50:57 bluelightning: do you point to the repository or the weblink? Nov 11 14:51:06 zecke: both Nov 11 14:51:10 zecke, will you pick the dependencies for things like asterisk and openbts? Nov 11 14:51:28 and do you see voip clients living in this layer? Nov 11 14:51:35 bluelightning: https://gitorious.org/sysmocom-openembedded/meta-telephony Nov 11 14:51:58 Crofton|work: i see it more server side, i would like to depend on GNUradio coming from somewhere else, but RTP libs are okay Nov 11 14:52:12 gnnuradio is not telephony :) Nov 11 14:52:31 well, I would like to avoid layer proliferation also :) Nov 11 14:53:21 bluelightning, when you build the native qt recipe, moc and friends are built for build system Nov 11 14:53:32 when you build for target, they are built for target Nov 11 14:53:42 so they need to be packaged in the dev package Nov 11 14:53:51 so you can build qt stuff on the target Nov 11 14:54:42 Crofton|work: right, that would make sense; I'm not too sure where my information came from... Nov 11 14:54:50 heh Nov 11 14:55:12 qmake I get from somewhere else Nov 11 14:57:07 zecke: done Nov 11 14:57:46 Crofton|work: is qmake a host binary? or is that also correctly built for the target? Nov 11 14:58:15 * bluelightning has not checked recently Nov 11 15:00:37 bluelightning: Nov 11 15:00:39 bluelightning: thanks Nov 11 15:06:12 bluelightning, we have another recipe for it in meta-oe Nov 11 15:06:20 I am cleaning out stuff today Nov 11 15:06:24 submiting Nov 11 15:06:35 when I am done, we can go over it and see what can be improved Nov 11 15:06:39 Crofton|work: yes I know, and really we ought to be able to provide it in oe-core Nov 11 15:06:43 trying to get a working base together Nov 11 15:06:51 sounds good :) Nov 11 15:40:58 hi zecke Nov 11 16:30:38 bluelightning, qt has no parallel make? Nov 11 16:55:34 Crofton|work: well, it's not being disabled in OE-core's qt recipes if that's what you mean... Nov 11 16:55:47 hmm Nov 11 16:56:00 weird, maybe I should check my settings :) Nov 11 16:57:10 I was set to -j2 Nov 11 19:12:45 hmmm Nov 11 19:13:00 for some reason libxml2 package refuses to generate the libxml2-utils package Nov 11 19:13:14 although I do not see anything that would be wrong in the recipe Nov 11 19:13:21 FILES_${PN}-utils is there Nov 11 19:13:33 and the files do get compiled and are in the right place Nov 11 19:19:05 -e output also shows that everything should be OK, FILES_libxml2-utils looks just fine Nov 11 19:19:12 I wonder why it is still not being created Nov 11 19:19:15 PACKAGES lists it as well Nov 11 19:19:29 think about packages ordering. the first package in PACKAGES to grab a file gets it, later ones that also match it wont Nov 11 19:20:49 hmm indeed, let me check if the files got packaged into the main package Nov 11 19:28:51 you were right, that was it Nov 11 19:29:06 my solution looks like an ugly hack though Nov 11 19:29:07 PACKAGES_NEW := "${@oe_filter_out('${PN}-utils', '${PACKAGES}', d)}" Nov 11 19:29:07 PACKAGES = "${PN}-utils ${PACKAGES_NEW}" Nov 11 19:34:48 if you're using an append, that'll be one of the only answers though. if you're going to modify the recipe, just use =+ instead of += Nov 11 19:35:56 I'm appending... Nov 11 19:36:06 the main recipe does += Nov 11 19:36:11 * kergoth nods Nov 11 19:36:57 I'll have to take some time after I finish the migration and prepare some patches for all the things that came into my way Nov 11 19:40:01 hmm, how can this happen? ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. Nov 11 19:40:13 during rootfs generation, a particular package tries to access /etc/crontab Nov 11 19:40:26 which fails because the pseudo thing did not work Nov 11 19:40:35 but nothing in the log suggest to why it could be preloaded Nov 11 19:40:46 anyone ran into this yet? Nov 11 22:23:45 whew, think i finally have an external-ctng-toolchain recipe + tcmode that functions Nov 11 22:23:48 * kergoth does some more testing Nov 11 23:50:50 hmm, things get rather unpleasant trying to use an external toolchain built with one prefix with oe configured for another Nov 11 23:50:53 * kergoth pokes around **** ENDING LOGGING AT Sat Nov 12 02:59:56 2011