**** BEGIN LOGGING AT Thu Mar 22 02:59:58 2012 Mar 22 04:25:03 morning. Does anybody here have any experience using the pxa25x_udc driver with a 3.2 Kernel? Mar 22 04:32:13 chasing down a fun bug. whenever i log out via ssh, any screen sessions i'd started get wiped out too Mar 22 04:32:29 kinda defeats the whole point of screen Mar 22 04:33:02 no background process allowed.... denied! Mar 22 04:52:04 baahaaaaa! it gets stupider! Mar 22 04:52:22 if i start syslogd, to try to track down wtf is going on, that's great, except syslogd gets killed when i log out too! Mar 22 04:52:36 un. be. leive. a. ble. Mar 22 05:21:55 lol Mar 22 05:44:10 i fucking hate systemd Mar 22 05:44:45 it's systemd. and it refuses to accept the pam_systemd.so and such that is supposed to hack around this broken restriction Mar 22 05:50:14 also fun: syslog.busybox won't start up set to log to buffer if it's run from init. only with logging to file. Mar 22 05:50:41 it'll only run logging to buffer if started from a dropbear session, but then, of course, it gets shut down by... systemd. Mar 22 05:50:57 /rant Mar 22 05:50:59 this is a test Mar 22 05:51:05 install tmux Mar 22 05:51:29 see if it works correctly , comparable to screen Mar 22 05:52:28 ctrl-b d to detach Mar 22 05:55:36 muhoo: so nothing in general seems to run correctly? Mar 22 06:02:14 hmm, ok, will try it. Mar 22 06:02:39 right now i'm spewing session required pam_systemd.so all over every file in /etc/pam.d, trying to see if i can beat it with a hammer Mar 22 06:04:02 ah Mar 22 06:04:15 personally dont use pam Mar 22 06:04:28 never seen issue Mar 22 06:06:40 muhoo: type mount Mar 22 06:06:59 i wonder if something is missing there Mar 22 06:07:22 specificly /dev/pts Mar 22 06:07:42 probably not i guess worth checking Mar 22 06:17:36 nope Mar 22 06:17:42 pts is there Mar 22 06:17:55 it's the intended behavior of systemd! Mar 22 06:17:57 http://0pointer.de/blog/projects/systemd.html Mar 22 06:18:07 and there appears to be no tmux in angstrom Mar 22 06:18:16 sudo opkg install tmux --> nothing there Mar 22 06:19:17 hmmhmm Mar 22 06:19:33 i think your init system is buggerd Mar 22 06:19:40 it's not init. it's systemd. Mar 22 06:19:54 but tmux is nice, i suggest compiling it Mar 22 06:20:05 tmux is indeed very nice, i've used it. Mar 22 06:20:47 this is a stock beaglebone image, cloud9, i've done no modifications to it Mar 22 06:20:55 hmph Mar 22 06:21:16 havent used it Mar 22 06:22:23 lrwxrwxrwx 1 root root 12 Feb 14 06:21 /sbin/init -> /bin/systemd* Mar 22 06:22:27 :-( Mar 22 06:25:47 it's someone reinventing a 30-year old wheel that was perfectly round and rolled perfectly well before, replacing it with a 20-dimensional octagonal wheel that doesn't roll at all Mar 22 06:32:07 lol Mar 22 06:42:52 <_tasslehoff_> in oe-classic/dev I get "ImportError: No module named _md5" when importing hashlib in python. anyone know which recipe/package provides the md5-functionality needed? Mar 22 06:51:36 iirc this happens when you build openssl/python in wrong order Mar 22 06:52:13 or while openssl is broken (e.g. seen it with zlib upgrade) when you're building python Mar 22 06:53:47 <_tasslehoff_> JaMa: broken as in do-not-build, or as in builds-fine-but-is-hurting-inside? Mar 22 07:00:25 broken in sysroot and rebuilding can help Mar 22 07:07:32 <_tasslehoff_> will try Mar 22 07:23:35 Hey friends, i have a problem with BBVERSION an PREFERRED_VERSION. I set my BBVERSION of the bb-recipies x.bb to a range eg "1.0.[0-9]:1.0.0\n1.1.[0-9]:1.1.0" and have a PREFERRED_VERSION_x = "1.0.5". But oe builds for me only the 1.1.0 version. Is this behavior correct? Mar 22 07:40:25 <_tasslehoff_> I added libqt-embeddedopengl4-dev to my sdk, but when I try to use it ld is sad cause it can't find libopengl32, and I can't figure out what to add to my sdk to get it Mar 22 08:21:26 good morning Mar 22 08:27:14 Hi, can some one point me in the right direction to pass CONFIG+=release to a recipe to build an embedded Qt app. I can only seem to build a DEBUG copy... Mar 22 08:38:22 <_tasslehoff_> JaMa: rebuilding openssl and python fixed it. thanks. Mar 22 08:50:16 anyone knows how I can extend the name of the tarbal given out from meta-toolchain to include the day as well as the month? Mar 22 09:00:06 mertsas: IIRC should depend on DISTRO_VERSION = "v${@time.strftime('%Y.%m',time.gmtime())}" Mar 22 09:02:34 have someone experience with BBVERSION? MY BBVERSIONS is set to "2.0 1.0", PREFERRED_VERSION is set to "2.0" but oe builds for me only the version "1.0". Why? Mar 22 09:04:47 silviof: usually because you set it in the wrong place, are you using oe-core= Mar 22 09:04:47 ? Mar 22 09:05:51 mckoan: I use the old openembedded-tree :-( Mar 22 09:07:16 silviof: where you set PREFERRED_VERSION ? Mar 22 09:08:42 mckoan: I set it in the image-file with the "inherit image" Mar 22 09:10:10 you can't do it in there, it must be in the distro configuration or local configuration Mar 22 09:10:21 mckoan: thanks Mar 22 09:15:36 mertsas: yw Mar 22 09:15:48 hi mckoan Mar 22 09:17:09 woglinde: hello, how are you? Mar 22 09:17:31 How can I pass CONFIG += release to a build of a Qt app Mar 22 09:18:01 mckoan fine Mar 22 09:18:08 I nearly finsihed openjdk-7 Mar 22 09:18:54 :) Mar 22 09:19:10 bluelightning: ok - the PREFERRED_VERSION is now set in my local.conf, but without success. in my logfile (which created with -DDDDDv) I have no entry PREFERRED_VERSION for this package. Mar 22 09:19:17 guyvdb_ you can pass everything you want to an build Mar 22 09:19:54 silviof: you can use bitbake -s to see the available/preferred versions of each recipe Mar 22 09:20:00 morning Mar 22 09:22:47 woglinde: I am struggling to get a RELEASE build of my QT app. If I place CONFIG += release CONFIG -= debug in my app.pro file... it is ignored... i must be missing something Mar 22 09:24:04 http://qt-project.org/faq/answer/what_does_the_syntax_configdebugdebugrelease_mean_what_does_the_1st_argumen Mar 22 09:24:32 woglinde thx reading Mar 22 09:24:40 yeah google is so easy Mar 22 09:25:31 If i build on the host I can from command line (qmake make) I can build either release or debug. I just cannot seem to do it within bitbake Mar 22 09:28:05 guyvdb_ did you looked at other recipes? Mar 22 09:28:05 did you looked in the qt.bbclass? Mar 22 09:28:05 are you using oe-core? Mar 22 09:28:22 hm las thing for openjdk is to teach the relocation class not to strip my ORIGIN path Mar 22 09:28:24 no I am not using oe-core Mar 22 09:28:42 bluelightning: and mckoan: thx for helping me - now it works! Mar 22 09:28:43 guyvdb_ anyway look into the qt4.bbclass Mar 22 09:28:54 ok will have a look now Mar 22 09:31:02 woglinde do I need to make a custom mkspecs my build? I.e. modify SMAKESPEC Mar 22 09:31:08 QMAKESPEC Mar 22 09:34:06 try it out Mar 22 09:34:28 this is the setup http://pastie.org/3646707 Mar 22 09:35:37 and this doesnt work? Mar 22 09:36:24 no it always builds DEBUG under bitbake for target .... on host it builds RELEASE Mar 22 09:36:30 is there anywhere I can set an environment variable for all packages? I wan't to set PKG_CONFIG_LIBDIR so all .la files have absolute paths in them in my toolchain Mar 22 09:36:55 guyvdb_ than yust make a patch which removes the debug stanca Mar 22 09:37:14 file://patch_out_debug.patch Mar 22 09:37:15 Hmm what am I patching?? Mar 22 09:37:23 your source code Mar 22 09:37:25 what else Mar 22 09:37:33 sorry I do not follow Mar 22 09:37:56 would it patch the qmake *.pro file? Mar 22 09:38:18 you make a patch and which patches your source code Mar 22 09:38:30 look at other recipes how patches work Mar 22 09:40:38 I know how to make/apply a patch ... and can figure out from other recipe how to do it in bb but I still do not follow. When I build a release of my app on host it is 1Mb when debug it is 10Mb (i assume debug symbols) there is nothing to change in source from release to debug... just no debug symbols are needed Mar 22 09:41:34 guyvdb_ sure but normaly oe strips the debug-symbols out and put them into a seperate package -dbg Mar 22 09:42:29 ahh maybe that is my problem... I am just doing bb -c compile and then grabbing the executable from work// Mar 22 09:43:42 :) Mar 22 09:43:47 okay puzzel splved Mar 22 09:43:55 args puzzle solved Mar 22 09:44:05 try -c build Mar 22 09:44:11 and look again Mar 22 09:45:09 looking at that thx Mar 22 09:57:20 woglinde: have you heard about pseudo making problems on amd64 machines because of 32 bit incompatibility? Mar 22 09:57:24 hm yes that solved it Mar 22 09:57:24 little bugger in relocatable.bbclass Mar 22 09:57:24 exisiting ORIGIN paths get thrown away Mar 22 09:57:27 i can't build that packet Mar 22 09:57:48 fraxinath which package? Mar 22 09:57:57 didnt test lately on 64 bit Mar 22 09:58:25 pseudo-native-1.2-r5 Mar 22 09:58:31 it tells me /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/libgcc.a when searching for -lgcc Mar 22 09:58:43 it seems only amd64 is affected Mar 22 09:58:52 fraxinath ah you need the ia32 static libs Mar 22 09:58:55 my colleagues using intel and debian/ubuntu aren't having problems Mar 22 09:58:59 whats your distro? Mar 22 09:59:04 archlinux Mar 22 09:59:25 than lookout if archlinux have a ia32 compat static lib package Mar 22 09:59:33 aye will do Mar 22 09:59:34 has an even Mar 22 10:00:08 aur/meego-qemu-ia32 is the only match for ia32 Mar 22 10:00:10 hmpf Mar 22 10:01:10 meego? Mar 22 10:01:15 dead dead dead Mar 22 10:01:24 yeah it has absolutely nothing to do with this :) Mar 22 10:01:44 what is the new thing now? Mar 22 10:01:48 tiger or something Mar 22 10:01:49 tizen Mar 22 10:01:52 tizen Mar 22 10:01:58 yeah that, whatever :) Mar 22 10:02:13 yo khem Mar 22 10:02:22 okay i shall go bother the archlinux folks about that issue :) thanks for the hint woglinde Mar 22 10:02:42 so now the last test for the openjdk-7 stuff Mar 22 10:02:47 clean build from scratch Mar 22 10:08:56 is there anywhere I can set an environment variable for all packages? I wan't to set PKG_CONFIG_LIBDIR so all .la files have absolute paths in them in my toolchain Mar 22 10:19:58 woglinde once i installed gcc-libs-multilib-4.6.3-1-x86_64 binutils-multilib-2.22-4.1-x86_64 gcc-multilib-4.6.3-1-x86_64 on my archlinux, pseudo-native compiled fine! Mar 22 10:20:16 so thanks and cu Mar 22 10:21:34 JaMa: hi, what do you mean by " stub of meta-toolchain" ? Mar 22 10:21:49 fraxinath I will mark another beer on the list Mar 22 10:22:13 ericben: see meta-multimedia for example :) Mar 22 10:22:19 mertsas what excactly is your problem? Mar 22 10:24:44 JaMa: there is nothing inside mera multimedia : it's just an empty layer. Do you mean the 1st step is to create an empty meta-toolchain layer, let peoples update their bblayers.conf and then move the files ? Mar 22 10:25:05 ok now I've read your mail Mar 22 10:25:09 and I understand ;-) Mar 22 10:26:23 ericben: yes, because we cannot know when all people have updated their bblayers so we would wait with git rm forever if we want to be "correct" Mar 22 10:26:34 understood Mar 22 10:26:49 but we can create empty layer now without much discussion and then discuss what should be moved there Mar 22 10:28:19 JaMa: btw I now reproduce the problem with gdb. I don't see what has changed in my setup but gdb is now linked with the sdk's libpython and fails Mar 22 10:29:23 my gdb is linked with sdk's libpython and works and my tmpdir is 1-2 days old only Mar 22 10:29:38 especially x86-64 sysroot was built just today Mar 22 10:29:41 JaMa: that's really strange Mar 22 10:30:51 * JaMa has everything linked to sdk's libs Mar 22 10:30:57 JaMa: even expat ? Mar 22 10:30:59 which seems more correct Mar 22 10:31:12 yes, see that email from today Mar 22 10:31:17 here I still have libexpat.so.1 => /lib64/libexpat.so.1 Mar 22 10:31:33 yes and also libz iirc Mar 22 10:32:39 ok I don't understand why we get such different behaviour Mar 22 10:34:28 you can download my sdk image or even checkout my gentoo chroot to test yours in it Mar 22 10:35:04 we can also compare ldconfig -p and I've checked my env for ^LD and nothing special there.. Mar 22 10:38:50 JaMa: if you have time we can check now Mar 22 10:39:18 I have a clean tmp with qemuarm arch, oe & bitbake were updated this morning Mar 22 10:40:01 ldconfig http://paste.pocoo.org/show/569406/ Mar 22 10:40:47 chroot is here http://git.shr-project.org/git/?p=shr-chroot.git;a=summary Mar 22 10:41:14 ldconfig : http://paste.pocoo.org/show/569407/ Mar 22 10:42:16 and generated sdk is here http://jama.dyndns-home.com/org.openembedded.oe-core.sdk/ Mar 22 10:42:40 but my upload is terribly slow Mar 22 10:58:51 JaMa: can you check in log.doc_ompile for the link command of gdb ? Mar 22 11:01:36 args Mar 22 11:01:42 now perl suckz about rpath Mar 22 11:02:18 why the hell we install it under /devel/arm/git/setup-scripts/build/tmp-angstrom_2010_x-uclibc/sysroots/i686-linux/usr/bin/perl-native/perl.real Mar 22 11:03:30 that doesnt look right to me Mar 22 11:04:08 thats the reason it uses libs from host Mar 22 11:06:29 ah I found it Mar 22 11:06:47 bitbake should error out when chrpath goes wrong Mar 22 11:08:24 damn it Mar 22 11:11:26 woglinde: it's installed there so that it's deterministic whether a recipe is using the host perl or our -native one Mar 22 11:17:28 bluelightning yes I saw it Mar 22 11:17:55 but looks like chrpath has a problem when it reaches exactly the size of the max path allowed path Mar 22 11:18:24 bluelightning going from sysroot/arch is not so good Mar 22 11:19:36 I agree we should definitely fail when that occurs Mar 22 11:20:33 and I think that might be the problem for some native binaries when it uses the host ones instead of the sysroot ones Mar 22 11:20:41 ericben ping Mar 22 11:22:32 woglinde: yes Mar 22 11:22:34 hi Mar 22 11:23:22 ericben you had the problem or not? Mar 22 11:23:27 woglinde: do you mean you have found a reason for the problem we actually meet with gdb ? Mar 22 11:23:33 maybee Mar 22 11:23:38 woglinde: now I have it Mar 22 11:23:51 hm there is something strange too Mar 22 11:24:01 my perl could not find its lib Mar 22 11:24:09 now I set the same path again Mar 22 11:24:12 it can find it Mar 22 11:24:29 +now Mar 22 11:24:34 thats really strange Mar 22 11:24:40 I set a shorter path before Mar 22 11:24:42 woglinde: I managed to produce working sdk yesterday, now they always fail. I can't tell what has changed between Mar 22 11:25:01 ericben grep the logs for failling chrpath Mar 22 11:25:16 atleast some perl modules will be involved Mar 22 11:25:31 woglinde: do you have a grep pattern for me to test quickly ? Mar 22 11:26:32 in all populate_sysroots log "new rpath '$ORIGIN/../../../../../../../../../..' too large; maximum length 19" Mar 22 11:26:33 ericben: here is my log.do_compile http://paste.pocoo.org/show/569422/ Mar 22 11:27:06 so grep for "new rpath.*too large" should wotk Mar 22 11:27:48 yes Mar 22 11:28:27 ericben and it looks to me if chrpath hits exactly the border it cannot read the last path either Mar 22 11:28:36 woglinde: this doesn't match anything here Mar 22 11:28:40 hm Mar 22 11:28:59 ericben gdb is the problem? Mar 22 11:29:14 can you pastebin chrpath -l? Mar 22 11:29:32 woglinde: from devshell ? Mar 22 11:29:41 no Mar 22 11:29:49 from the resulting binary Mar 22 11:29:58 ok I'm not familiar with that Mar 22 11:30:08 or is it a building error? Mar 22 11:30:28 chrpath is a command Mar 22 11:30:32 like ls Mar 22 11:30:37 yes I saw that Mar 22 11:30:51 the problem is "*** glibc detected *** arm-oe-linux-gnueabi-gdb: double free or corruption (out): 0x00007fec82e67030 ***" Mar 22 11:31:03 ah okay Mar 22 11:31:05 sorry Mar 22 11:31:08 JaMa doesn't have it (and I also didn't have it yesterday) Mar 22 11:31:21 hm Mar 22 11:31:25 in fact it seems gdb in sdk gets linked to host libraries in some case Mar 22 11:31:30 ah Mar 22 11:31:31 okay Mar 22 11:31:38 than chrpath -l on that gdb Mar 22 11:31:41 please Mar 22 11:31:43 just did it Mar 22 11:31:52 pastebin? Mar 22 11:31:52 and /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/armv5te-oe-linux-gnueabi/arm-oe-linux-gnueabi-gdb: RPATH=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/armv5te-oe-linux-gnueabi:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib Mar 22 11:32:09 hm Mar 22 11:32:18 okay Mar 22 11:32:24 so we dont strip it for sdk Mar 22 11:32:29 * woglinde scratches head Mar 22 11:33:08 here it's similar sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb: RPATH=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib Mar 22 11:33:52 * JaMa launching qemuarm build too Mar 22 11:34:11 whats ldd saying? Mar 22 11:35:55 it's on ML Mar 22 11:36:04 http://paste.pocoo.org/show/569427/ Mar 22 11:36:34 iirc I already met this problem in oe-dev and ened in linking statically some libs into gdb Mar 22 11:37:16 commit 04386651d904b8f5c2dd8b9adbb3e2f4b94fcc3a in oe-dev Mar 22 11:37:33 libreadline Mar 22 11:37:59 and expat Mar 22 11:38:05 but they are in the sdk? Mar 22 11:38:23 ah libz too Mar 22 11:38:56 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6 Mar 22 11:39:06 okay Mar 22 11:39:33 yeah Mar 22 11:39:35 there we go Mar 22 11:39:54 no rpath for /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/ Mar 22 11:40:45 ericben what is under /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux ? Mar 22 11:41:07 OE @ /usr/local/oecore-x86_64 $ find . -name libreadline.so.6.2 Mar 22 11:41:07 ./sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6.2 Mar 22 11:41:07 ./sysroots/x86_64-oe-linux/usr/lib/.debug/libreadline.so.6.2 Mar 22 11:41:07 ./sysroots/x86_64-oe-linux/usr/lib/libreadline.so.6.2 Mar 22 11:41:15 woglinde: nothing Mar 22 11:41:37 so we found the problem Mar 22 11:41:40 nice Mar 22 11:41:42 woglinde: http://paste.pocoo.org/show/569429/ Mar 22 11:41:47 now how to solve it Mar 22 11:42:05 hm for now Mar 22 11:42:20 do you need a quick fix? Mar 22 11:42:23 ok lets sumarize it in an email so that RP & yocto peoples can have a look at it Mar 22 11:42:27 ericben: check if it's the same with libz Mar 22 11:42:31 woglinde: at least to confirm that's the problem Mar 22 11:42:40 jama it is Mar 22 11:42:45 ericben okay Mar 22 11:42:53 JaMa: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libz.so.1.2.6 Mar 22 11:43:09 and same for expat Mar 22 11:43:26 do chrpath -r "usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib:usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib" gdb Mar 22 11:43:33 and do ldd again Mar 22 11:45:07 ping? Mar 22 11:45:21 woglinde: I'm on it Mar 22 11:45:21 but why does it find it for me when I have same rpath as ericben and same layout? Mar 22 11:45:59 jama yes good question Mar 22 11:46:02 woglinde: no / at the begining of the paths ? Mar 22 11:46:10 ericben ups Mar 22 11:46:12 sure Mar 22 11:46:18 you need leading / Mar 22 11:46:50 ok now readline libz & expat are taken from the sysroot Mar 22 11:46:51 jama only think to my mind comes whith ld.config.path Mar 22 11:47:03 I still have the double free Mar 22 11:47:14 but I wonder how gentoo should set it automagicly Mar 22 11:47:23 ericben hm okay Mar 22 11:47:26 what you mean by ld.config.path? Mar 22 11:47:32 jama yes Mar 22 11:47:44 :) Mar 22 11:47:48 no Mar 22 11:47:51 and rpath seems limited to 142 char Mar 22 11:48:02 ericben the linker set its Mar 22 11:48:21 if you use rpath = 500 charpath Mar 22 11:48:28 you would have 500 chars Mar 22 11:49:28 ok I see Mar 22 11:49:56 the problem seems that we have /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/armv5te-oe-linux-gnueabi instead of /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib Mar 22 11:50:02 ericben yes Mar 22 11:50:11 can you look if the linker set its Mar 22 11:50:12 slow bran today sorry ;-) Mar 22 11:50:13 or we Mar 22 11:50:16 brain Mar 22 11:50:19 in manipulating it Mar 22 11:54:16 I still have the double free problem :-( Mar 22 11:54:45 yes but that looks a bug in gdb itself than Mar 22 11:54:58 woglinde: that strange as it works fro JaMa Mar 22 11:55:26 sorry Mar 22 11:55:30 I have no idea Mar 22 11:55:43 you could use strace do lookup if still some host libs sneak in Mar 22 11:55:44 thanks for your time Mar 22 11:55:51 just did it Mar 22 11:56:33 hm did you looked where the rpath comes from? Mar 22 11:56:39 wrong linker call Mar 22 11:56:48 or chrpath manipulating? Mar 22 11:57:48 woglinde: no I must switch to something else now. I'll try to be back on the subject this evening or tomorrow Mar 22 11:58:00 I'm trying to sumarize that in an email Mar 22 11:58:44 hm okay Mar 22 11:58:55 maybee I will build it here too Mar 22 11:58:59 and look it up myself Mar 22 12:02:11 * woglinde wonders why nobody looked on the newer faster libpng yet Mar 22 12:13:36 OK double free problem is in libpython as removing the one of the sdk make gdb happy Mar 22 12:13:49 erciben o.O Mar 22 12:16:23 ericben -> Mar 21 nitin.a.kamble@ ( 30) [OE-core] [PATCH 0/1] fix for the sdk gdb issue Mar 22 12:16:40 This reverts the commit for adding python support to sdk gdb. It is Mar 22 12:16:41 breaking the sdk gdb as reported in this bug: Mar 22 12:16:41 https://bugzilla.yoctoproject.org/show_bug.cgi?id=2077 Mar 22 12:16:47 * woglinde runs Mar 22 12:17:56 woglinde: yes that's the patch which caused all this thread Mar 22 12:18:08 as I would like to keep python support in gdb Mar 22 12:18:21 instead of reverting that patch Mar 22 12:18:25 than you have to fix it Mar 22 12:18:36 that's why I'm hre ;-) Mar 22 12:18:46 the problem is that in some cases it works Mar 22 12:19:11 lol Mar 22 12:19:15 I didnt read it before Mar 22 12:19:16 just see JaMa's build : it works fine, it was also working fine for me yesterday Mar 22 12:19:48 what happens when you run the gdb with gdb? Mar 22 12:19:53 and backtrace Mar 22 12:21:11 http://paste.pocoo.org/show/569448/ Mar 22 12:26:34 ldd /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/lib-dynload/readline.so Mar 22 12:26:41 I bet it using the host one Mar 22 12:26:54 * woglinde marks the next beer Mar 22 12:28:17 here it's using sdk's libreadline Mar 22 12:28:30 *g* Mar 22 12:28:32 yes Mar 22 12:28:37 that we already found it Mar 22 12:28:48 s/it/out Mar 22 12:29:10 python2.7/lib-dynload/readline.so is using sdk's libreadline too Mar 22 12:29:23 that's what I meant Mar 22 12:32:24 yes Mar 22 12:32:56 and I would have been suprised when it would have taken the host one Mar 22 12:48:28 woglinde: http://paste.pocoo.org/show/569460/ Mar 22 12:50:05 okay Mar 22 12:50:18 than I guess its a problem that python is linked to readline too Mar 22 12:50:27 or somethink Mar 22 13:16:26 ericben: mv is probably not what khem meant by "copy" :) Mar 22 13:17:11 * JaMa just finished qemuarm build and still working for me :) Mar 22 13:17:13 JaMa: cp was still exhibiting the problem Mar 22 13:17:25 so I moved it in the end ;-) Mar 22 13:18:03 yup but that's what you should write in that email :) Mar 22 13:56:16 hi khem Mar 22 13:56:34 in that case why does it work when I remove readline.so as I don't have readline_d.so in my host system ? Mar 22 13:59:07 damn it Mar 22 13:59:17 setting the same chrpath from cmdline works Mar 22 13:59:47 python code what you are doing wrong! Mar 22 15:11:34 I just pushed some huge refactoring in image generation for meta-fsl-arm and some more changes for the on going imx6 support Mar 22 15:11:40 please test them Mar 22 15:12:45 otavio: are there people working on i.MX6 support for meta-fsl-arm ? Mar 22 15:13:01 as iMX6 is still under NDA it's quite hard to discuss on it Mar 22 15:14:43 ericben: yes; there're Mar 22 15:15:15 ericben: yes but the code is available and there're people with hw access working on it Mar 22 15:15:22 msm: hi Mar 22 15:15:38 otavio: only the kernel & u-boot are available, interesting parts are not available Mar 22 15:16:04 what else you need ericben? Mar 22 15:16:37 msm: i didn't look at how you do the images are done for ppc but it would be nice if you might look at https://github.com/Freescale/meta-fsl-arm/commit/83534159576f9bf35f05f0b285aec06a7d4ef737 Mar 22 15:16:42 woglinde: as usual with these CPU : 3D & codecs (and I don't need that in fact ;-) ) Mar 22 15:17:01 ericben: let's do it step by step Mar 22 15:17:52 as usual codec and gpu will remain closed Mar 22 15:23:13 otavio: is there a specific complaint? Mar 22 15:23:37 otavio: we dont normally boot from sdcards on ppc either fyi Mar 22 15:24:06 msm: as I said, I didn't check how you do but it has made easy to generate the fsl format that way so the same might be of use for you Mar 22 15:24:22 msm: right but same overriding way might be useful Mar 22 15:28:00 otavio: fair enough Mar 22 15:28:14 we are having fun deciding what to put on the images too Mar 22 15:28:47 msm: the way i did you can easily just-work for regular images Mar 22 15:29:00 msm: later we can provide demo images if required Mar 22 15:29:26 msm: so now, bitbake core-image-minimal gets a working sdcard image for all imx Mar 22 15:29:38 msm: (working at imx28 now) Mar 22 15:33:04 otavio: yep, the minimal case is OK Mar 22 15:33:16 msm: good Mar 22 15:33:31 ideally hob comes up to speed and minimal + desired packages works ;) Mar 22 15:37:09 hehe yes Mar 22 15:37:19 btw actual hob is quite impressive Mar 22 15:37:44 I tested this morning and the user interface is very reactive Mar 22 15:39:33 :) Mar 22 15:40:09 except a bug when it finish building the image :-( Mar 22 15:43:30 can I run multiple opkg-build in parallel? Mar 22 15:44:50 spreading them across all cores would speed up building quite a bit. Mar 22 15:45:49 with "can" I mean is there anything technically (such as shared data files) preventing multiple instances running Mar 22 15:46:13 Good morning All ! Mar 22 15:46:34 hi nitink Mar 22 15:46:39 hi nitink Mar 22 15:46:53 hi Mar 22 15:47:17 hi ericben woglinde denisATeukrea Mar 22 15:47:52 ericben: any new update for the sdk gdb issue ? Mar 22 15:49:50 what's the gdb issue? Mar 22 15:50:39 nitink yes Mar 22 15:50:39 denisATeukrea: see oecore mailing list Mar 22 15:50:45 its solved Mar 22 15:50:50 wrong rpath Mar 22 15:50:51 great !!! Mar 22 15:50:54 ok Mar 22 15:51:28 and stupiddebugloadsymbols library Mar 22 15:55:08 * nitink is catchup with email so far Mar 22 16:07:28 woglinde: so is the python readline.so issue has a solution now ? Mar 22 16:08:23 nitink renmae the lib Mar 22 16:08:31 to readline_d.so Mar 22 16:09:00 woglinde: this sounds like a workaround Mar 22 16:10:25 so the commit to fix will be packaging fix for libpython Mar 22 16:22:01 nitink: can you confirm this works on your setup ? Mar 22 16:22:18 ericben: yet it does, just sent email for that Mar 22 16:28:03 ok fine, now we have to understand how to solve that the clean way in the python recipes Mar 22 16:29:36 yes, I would like to learn how you guys reached to the readlone_d.so workaround I could never guess it from the error message gdb threw Mar 22 16:34:54 hi, can anyone tell me if glibc is history in oe/angstrom ? Mar 22 16:42:41 nitink: the only guy to thanks is Khem Mar 22 16:42:55 and woglinde also for the rpath thing Mar 22 16:43:09 good collaboration here ! :) Mar 22 16:54:34 doug__: in the new OE-Core based structure, yes... but eglibc tracks glibc changes, so there's not a huge difference Mar 22 17:08:08 bluelightning: ok thanks; we recently upgraded our angstrom and found that the change to eglibc has broken some thread mutexes in our code - there may be a problem using futexes in eglibc. Mar 22 17:08:38 we'll see what we can do for now, but I would like the option to build with glibc again - can the recipies be restored on top of the current tree somehow? Mar 22 17:09:02 doug__: it's not impossible, but would require work Mar 22 17:09:14 :/ Mar 22 17:09:26 doug__: so you narrowed down that change to something specific to eglibc? Mar 22 17:09:35 er, s/change/issue Mar 22 17:10:01 i.e. it wasn't just something that went into a later glibc than you were previously using? Mar 22 17:10:09 and flowed into eglibc from there Mar 22 17:11:51 I would need to check the exact versions, but it's my colleage who's been tracing the bug and I can't remember where he said the bug was - all I wanted to find out for now is whether it would be easy to switch back to glibc for the sake of test/compare Mar 22 17:12:10 seems not Mar 22 17:26:52 denix, thanks for help last night Mar 22 17:27:34 mr_science: you are welcome Mar 22 17:40:43 nitink: I was also on the ubuntu pyton page to study their patches ;-) Mar 22 17:40:56 :) Mar 22 17:49:39 hm gotach Mar 22 17:49:51 gotcha even Mar 22 17:50:05 chrpath args has extras spaces thats why the path isnt found Mar 22 17:50:24 so now let find my me the python command for strip ending spaces Mar 22 17:52:52 woglinde: .strip() should work Mar 22 17:53:00 or .rstrip() Mar 22 17:53:21 hm I am found args = re.sub(r'\s', '', args) Mar 22 17:54:15 regex works just as well Mar 22 17:55:03 hm and that might explain that the chrpath stuff is broken for ../../lib Mar 22 17:55:13 I will send my soon Mar 22 17:55:17 patches Mar 22 18:39:48 Anyone have any experience creating images with extra user accounts preinstalled? I found a useradd.bbclass in oe-core, but that requires pseudo. The version of OE I'm using uses fakeroot. Mar 22 18:40:46 brent__: pseudo basically is a better fakeroot Mar 22 18:42:39 The syntax that they seem to be using in pseudo allows them to specify that the groupadd command uses the target config, not the build system stuff. I'm unsure how to do that with fakeroot. Mar 22 18:45:21 Am I understanding that important difference correctly? Mar 22 18:46:15 I think pseudo isn't doing anything special here, only that the files end up with the right permissions on them when compressed Mar 22 18:46:30 correct user/group, I mean Mar 22 18:52:14 bluelightning: Thanks. I'm thinking/playing. Mar 22 23:30:14 awesome... Mar 22 23:30:39 with the right firmware installed, my new build actually owrks Mar 22 23:30:46 *works even **** ENDING LOGGING AT Fri Mar 23 02:59:58 2012