**** BEGIN LOGGING AT Fri Feb 03 02:59:57 2012 Feb 03 07:38:58 hello Feb 03 07:39:16 anybody? Feb 03 07:47:09 Is it possible to compile with native ubuntu compiler? Feb 03 09:06:00 Hi, I am working custom board with at91sam9260 and Epson S1D13513 9 inch TFT. I have downloaded driver from epson website and added to kernel. When I Boot the kernel, It hang when regster after enable 2D video accelator. pls help me! Feb 03 10:35:50 hi florian,all Feb 03 10:36:40 hi all Feb 03 10:36:44 hi pb_ Feb 03 11:10:19 kergoth: Hi, Are you around? I just saw your patches wrt the external toolchain on the ml. Interesting! : ) I just updated my local tree and I'm wondering what you you've got in your local.conf to make use of the CSL 2011.03 for example. Feb 03 11:10:41 From looking at the recipe I thought something like this may work: Feb 03 11:10:41 EXTERNAL_TOOLCHAIN = "/path/to/arm-2011.03/" Feb 03 11:10:41 TCMODE = "external-csl" Feb 03 11:11:29 But the do_package task of the external-csl-toolchain.bb fails because: "non debug package contains .debug directory: external-csl-toolchain path /work/armv5te-none-linux-gnueabi/external-csl-toolchain-1.0-r2/packages-split/external-csl-toolchain/usr/libexec/getconf/.debug/POSIX_V7_ILP32_OFF32" Feb 03 11:15:03 When I hacked the old external-csl-toolchain recipe I've added "${libexecdir}/getconf/.debug" to FILES_${PN}-dbg to work around this. Feb 03 11:27:07 hi there Feb 03 13:13:59 anyone around who deals with the server portion of bitbake? Feb 03 13:24:52 kergoth: Oh, I thought all of your changes were upstream already. Apparently only some of them are. I'll switch to your external-toolchain branch and give it a go... Feb 03 14:09:22 kergoth: When attempting to build the sato image using the external toolchain bitbake aborts when compiling libproxy_0.4.7.bb. I've changed the cmake.bbclass to let cmake find the binaries of the external toolchain (http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014432.html). With this change in place the "external-toolchain"-branch seems to work fine on my system (x86_64 and CLS 2011.03). Thanks! Feb 03 14:14:46 hi, has anyone here a fresh copy of the archive fetched by systemd_git (as freedesktop's git seems unreachable) ? Feb 03 14:37:44 kenws: ah! nice :) glad you found a way past that issue Feb 03 14:40:15 kergoth: Did you see such fails as well? I'm afraid it affects any cmake based project (when using an external toolchain). Feb 03 14:41:43 yeah, I ran into that with libproxy as well, but hadn't had time to investigate Feb 03 14:45:49 kergoth: Ok Feb 03 14:45:55 Another thing I saw is that recent GCCs prefer -marm over -mno-thumb: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014954.html Feb 03 14:47:36 khem: Is there anything that prevents kergoth's external-toolchain changes from going upstream? Feb 03 14:52:26 ah, good to know. i see that that patch was applied to oe-core, good (marm) Feb 03 14:55:09 honestly was pretty surprised at the state of the external toolchain support, must not be that many folks using it, or they all have their own recipes in local layers, heh Feb 03 14:56:01 ericben: yes Feb 03 14:56:18 ericben: if frest == whatever is needed for latest meta-oe Feb 03 14:57:32 hi, all! Feb 03 14:57:46 is it possible to disable journald in newer systemd? Feb 03 15:04:56 kergoth: yeah, I don't know either. Every few months there was a ml post about the external toolchain being broken but no one seem to be able to fix it till your patches came. : ) I did some rather ugly patches to the old cls recipes to have oe compiled with the linaro external toolchain. Feb 03 15:05:07 One thing that I'd like to do is to build the (e)glibc instead of copying it from the binary toolchain. But I haven't found a way to do this yet. :/ Feb 03 15:06:04 yeah, we'll need to be able to do that too Feb 03 15:06:22 ideally, it'd pull the eglibc sources from csl corresponding to the toolchain being used, I'd think Feb 03 15:06:32 best to avoid any potential incompatibility Feb 03 15:06:34 * kergoth thinks Feb 03 15:07:43 kenws: a very simple version shouldn't be hard to do -- i've done it before. what you can do is modify the recipe to operate conditionally based upon PREFERREED_PROVIDER_virtual/libc or similar. if it isnt set to external-csl-toolcahin, then don't emit those packages, etc, to avoid stepping on each others toes Feb 03 15:07:45 did someone make bitbake stop going nuts? or did it just finally sort itself out? Feb 03 15:07:56 course you'd want to avoid *installing* those bits too, though, hmm Feb 03 15:08:02 cryptk: are you referring to the hang issues? Feb 03 15:08:23 all I know is that my phone was going off all night because the server had a high load average Feb 03 15:08:41 hi Feb 03 15:08:44 and when I looked at it there were a bunch of python bitbake things running Feb 03 15:09:29 and since I don't know much about bitbake I didn't want to mess with it and potentially mess stuff up Feb 03 15:10:20 bitbake is you guys right? or am I asking the wrong people? Feb 03 15:11:23 kergoth: I'm not aware of any incompatibilities. The only thing that comes to my mind that might have a dependency is libgcc. I would have thought that it's just fine to use the eglibc version specified by the current libc recipe. Feb 03 15:13:39 btw kergoth hello! I am cryptk, another nas-admin cronie, think of me as "the other ka6sox " lol Feb 03 15:13:41 kenws: k. I'm sure I'll end up looking into that at some point in the next couple months, if you don't Feb 03 15:13:46 cryptk: hah Feb 03 15:13:54 I've tried playing with the PREFERREED_PROVIDERs but it didn't work out (can't remember the details). Feb 03 15:13:59 cryptk: here, this should help Feb 03 15:13:59 kergoth: sounds good. : ) Feb 03 15:14:32 so, on a side note, any time that any of our servers go out of spec, we get emails and text messages automagically ;) Feb 03 15:14:37 hi JaMa Feb 03 15:14:43 cryptk: what happened was, we were getting random hangs on parse failure. the attempted fix apparently caused only some people to hit hangs even on successful cases, which is clearly worse. reverted that for now whiel I dig further Feb 03 15:15:01 cryptk: so I expect your issue should be resolved now Feb 03 15:15:03 JaMa: may you please send me systemd's archive please ? Feb 03 15:15:10 sweet, thanks for looking into it Feb 03 15:15:31 kergoth: I'm not really sure what our plans are but I think that khem is going to talk to the linaro toolchain folks at the linaro connect conference Feb 03 15:15:42 I think I got about 40-50 texts about garnet as it went in and out of spec, lol Feb 03 15:15:50 good thing I have unlimited ;) Feb 03 15:16:02 when I found a patch that only consists of webpage gibberish, is there an appropriate place to report that or will it kind of 'fix itself' ? Feb 03 15:16:22 ericben: http://build.shr-project.org/sources Feb 03 15:16:26 cs_nbp: can you elaborate? Feb 03 15:16:45 JaMa: I reverted the futures switch in master for now. better a random parse failure hang than a random hang on success :P Feb 03 15:16:59 JaMa: going to spend today and potentially part of next week working on the underlying issue Feb 03 15:17:02 heh Feb 03 15:17:08 kergoth: there is a patch for bitchx/ircii, gcc34.patch, when I open it it looks like html Feb 03 15:17:25 kergoth: and of course patch fails Feb 03 15:17:31 cs_nbp: upstream probably removed the file and replaced it with a web page with an error message. try opening the url in a browser Feb 03 15:17:55 kergoth: heh, indeed, thanks Feb 03 15:19:49 have anybody been able to disable systemd journald in images? Feb 03 15:22:09 kergoth: it seems the 'patch' is a github page -.- Feb 03 15:25:06 * kergoth chuckles Feb 03 15:28:47 kergoth: at least the patch itself seems to be on that page Feb 03 15:28:52 :D Feb 03 15:29:24 kergoth: fyi, both the sato and qt4e images (compiled with CSL 2011.03 for ARM) are booting fine within qemu! :) Feb 03 15:29:57 nice Feb 03 15:30:24 i hit the libproxy failure while trying to test sato with qemu, since I'd never actually tried that image before :) Feb 03 15:31:30 kergoth: what are you building by default? the minimal image or some other thing that comes from a layer? Feb 03 15:31:57 kergoth, it's doing it again... Feb 03 15:32:04 it varies. mentor has their own primary images which we tend to add things to using IMAGE_FEATURES Feb 03 15:32:07 it's up to a LA of 14... Feb 03 15:32:27 kergoth: I see. : ) Feb 03 15:33:49 hrm... but aren't you guys on your own box now? Feb 03 15:34:04 I could probably just raise the alert levels Feb 03 15:34:27 the sato image seems like a nice option for graphical demos and the like Feb 03 15:36:52 JaMa: thanks ! Feb 03 16:13:44 bah, just realized i needed to ask jama something, but now he's not here :) Feb 03 16:13:47 * kergoth mutters Feb 03 16:21:12 whilst trying to port bitchx/ircII to oe-core i get Feb 03 16:21:17 ctcp.c:179:14: error: static declaration of 'ctcp_type' follows non-static declaration Feb 03 16:21:39 which seems weird Feb 03 16:21:54 (during compilation) Feb 03 16:22:14 anyone sen that already? Feb 03 16:22:18 *seen Feb 03 16:22:55 cs_nbp: seems I found solution for you Feb 03 16:23:01 freebsd ports have patch Feb 03 16:23:12 moment, I'll find direct link Feb 03 16:23:33 ah ok superkewl Feb 03 16:24:48 http://www.freebsd.org/cgi/cvsweb.cgi/ports/irc/bitchx/files/patch-source_gcc_fix Feb 03 16:25:00 http://www.freebsd.org/cgi/cvsweb.cgi/ports/irc/bitchx/files/patch-source_gcc_fix?rev=1.1;content-type=text%2Fplain Feb 03 16:25:56 I'm sure gentoo portages should have something similar :) Feb 03 16:36:16 yup that seems to work (at least for that issue, of course found new one instantly :D) Feb 03 16:42:36 cs_nbp: look around Feb 03 16:43:04 there are lot of patches for bitchx Feb 03 16:44:33 hmm, meta-oe needs to update its gdb-cross-canadian bbappend Feb 03 16:44:35 * kergoth tests a rename Feb 03 16:50:31 Jay7: true, found it, applied it and now package compiles, installs into sysroot and yields an ipk Feb 03 16:50:46 cs_nbp: send patches to ML :) Feb 03 16:51:08 Jay7: thats the next thing i got to dig into Feb 03 16:51:29 Jay7: btw didn't bitchx get renaed to ircII officially? Feb 03 16:51:42 +m Feb 03 16:52:13 cs_nbp: I don't know.. I've stopped to use bitchx some years ago Feb 03 16:52:25 <3 irssi or weechat Feb 03 16:52:27 :) Feb 03 16:52:42 yes me too, but it seemed an easy enough recipe to start to learn a bit of porting Feb 03 16:52:48 somewhere around time when all distros was switched to UTF-8 Feb 03 16:53:17 cs_nbp: indeed Feb 03 16:53:18 yeah, irssi is good candidate to switch from bitchx :) Feb 03 16:53:34 but I've switched to konversation + znc :) Feb 03 16:53:46 ugh, remember the way bitchx put all the messages from all the channels in one window Feb 03 16:53:56 that sucked Feb 03 16:54:13 im looking forward to it :D Feb 03 16:54:31 kk serious irc client will be up next Feb 03 16:55:11 kergoth: just use separate windows per channel :) Feb 03 16:55:43 yeah, was just a hassle. part of why i switched to irssi, since it did it automatically Feb 03 16:56:51 hehe.. php 5.3.9 have critical bug in code that fix non-critical (imho) bug in previous versions.. Feb 03 16:56:58 ok, fosdem schedule is too large Feb 03 17:21:28 ok it didnt only compile it also works Feb 03 17:21:34 ^^ Feb 03 18:02:25 Damn the documentation on the website is old Feb 03 22:34:58 hi Feb 03 22:37:07 I just encountered "Failure expanding variable PRINC[:=], expression was ${@int(PRINC) + 1} which triggered exception NameError: name 'PRINC' is not defined" as described by khem at http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-December/036640.html the solution to set PRINC ?= "0" in bb conf did not fix it for me. any suggestions? Feb 03 22:38:54 khem: ping :] Feb 03 22:42:01 dcordes: are you using new enough bitbake ? Feb 03 22:42:08 PRINC := "${@int(PRINC) + 1}" should just work now a days Feb 03 22:44:06 1.15.1 Feb 03 22:58:33 khem: new enough ? Feb 03 23:00:36 dcordes: yes Feb 03 23:00:57 khem: then I have a different local problem it seems Feb 03 23:01:04 and how old is your metadata Feb 03 23:01:32 khem: I am using the repos mentioned in the first box here http://wiki.shr-project.org/trac/wiki/Building%20SHR Feb 03 23:01:33 PRINC ?= "0" is now set in bitbake.conf Feb 03 23:02:31 hm it wasn't there so I set it manually and got same err Feb 03 23:02:53 khem: so I think metadata is recent Feb 03 23:03:05 ? Feb 03 23:05:19 parts of my metadata still set princ. is that a problem ? Feb 03 23:05:40 sounds like you're trying to combine new metadata with old metadata. good luck Feb 03 23:07:17 kergoth: thx :) Feb 03 23:09:49 kergoth: it seems to work with only old metadata **** ENDING LOGGING AT Sat Feb 04 02:59:58 2012