**** BEGIN LOGGING AT Tue Dec 06 02:59:57 2011 Dec 06 05:36:41 an anyone suggest me a light-weighted web browser which supports external plugins ???? Dec 06 06:07:24 snkt: epiphany Dec 06 07:50:52 khem: you mentioned yesterday that the sdk binaries use/respect sysroot. does that mean I should be able to extract anywhere and use --sysroot in my CCFLAGS Dec 06 08:11:48 good morning Dec 06 08:18:09 khem: yup. users are losers. setting my sysroot correctly now, and the sdk works just fine Dec 06 08:31:51 mornin Dec 06 08:35:41 Hello people, I'm trying to use ${@re.sub()} command in bb file, but having issues because of "NameError: name 're' is not defined". Any idea how to solve this issue? Dec 06 08:59:36 I see that in oe-core my image has decided to run fsck automatically when it deems it wise. In which recipe can this be configured. Dec 06 09:03:13 gm Dec 06 09:03:33 likewise: hi Dec 06 09:04:24 hey likewise Dec 06 09:06:31 hey guys Dec 06 09:44:51 gm florian, XorA, ao2, bluelightning, Jay7 Dec 06 09:44:59 yo likewise Dec 06 09:45:04 hi likewise, all Dec 06 09:45:10 good morning Dec 06 09:45:33 likewise Dec 06 09:46:15 where did we leave all the machines from classic oe (conf/machines/*.conf) in the oe-core and meta-oe stuff? Did we decide it to belong into distro / BSP repos? Dec 06 09:46:46 likewise: from what I saw, most of those tha did not get itno an own layer were left in classic :P Dec 06 09:47:48 Jin^eLD: "most of that"? Even the machines which were Yocto approved (mpc8315e-rdb for powerpc) are nowhere to be found, that's why I am now confused. Dec 06 09:47:49 likewise: lost in fragmentation :-/ Dec 06 09:48:28 florian: we lost 100+ machines? Dec 06 09:48:46 likewise: I think so yes... Dec 06 09:48:51 I'm ok with that, I just need to know where I can put them back. :) Dec 06 09:49:47 The current situation is that oe-core is still far away from the state oe-classic is from the amount of machines and software it supports. Dec 06 09:50:19 I miserably failed building any GUI image with it some weeks ago Dec 06 09:51:11 I have some old checkouts for the Yocto approved real hardware, which is now also gone in Yocto. Even their docs are now outdated. Welcome back to 5 years ago :) Dec 06 09:52:05 Well... five years ago we were able to build GPE and Opie - try this with OE core :-/ Dec 06 09:52:42 So what is the status quo? We all put much effort into fragmentizing OE and we now have two semi-supported approaches... Grumble. This was exactly I was afraid of. Dec 06 09:54:04 likewise: I guess you are right... unluckily. Dec 06 09:54:35 This topic is on my list for the next board meeting already. Dec 06 09:54:57 sound like "Divide and rule" Dec 06 09:56:37 This was the idea at least... Dec 06 09:57:41 rschus: gm Dec 06 09:58:44 florian: yes but that concept is intended as destructive for who is divided Dec 06 09:58:50 http://en.wikipedia.org/wiki/Divide_and_rule Dec 06 09:58:52 :-D Dec 06 09:59:31 florian: I'll take the "glass is half full" approach and try to setup a oe-core + meta-oe layer stack with a new machine. Dec 06 10:00:45 florian: Can't we raise this question to the TSC instead? Dec 06 10:00:54 likewise: That's what I tried... Dec 06 10:01:10 florian: or better "instead" -> "also". Ah, ok. Dec 06 10:03:57 likewise: Well... we should do both... so yes :) Dec 06 10:07:14 florian: well, FWIW, you can build opie if you add meta-opie ;) Dec 06 10:07:31 florian: meta-gpe has hardly anything in it though sadly Dec 06 10:08:57 likewise: which parts of the yocto docs are outdated? Dec 06 10:09:29 bluelightning: AFAIK, the docs that explain how to build for mpc8315e-rdb and beagleboard. At least, unless someone tells me otherwise. Dec 06 10:10:00 likewise: I've used poky to build images for both fairly recently Dec 06 10:10:20 do you mean the manual? or README.hardware? Dec 06 10:11:10 bluelightning: So Yocto is not using oe-core yet? Dec 06 10:13:34 likewise: of course... poky consists of oe-core + bitbake + meta-yocto + docs Dec 06 10:16:32 bluelightning: OK, let's just say I am confused about where mpc8315e-rdb.conf lives these days. Dec 06 10:17:14 bluelightning: The docs say it's in Poky, but I cannot find it in http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine, nor in the poky-contrib tree. Dec 06 10:17:33 likewise: it's under meta-yocto Dec 06 10:17:40 meta contains only what's in oe-core Dec 06 10:20:36 likewise: the intention was that meta-yocto would provide basic support for the 4 machines but that official layers may provide better BSPs for those machines Dec 06 10:20:49 e.g. meta-ti provides more complete support for the beagleboard Dec 06 10:21:16 I see meta-fsl-ppc doesn't have mpc8315e-rdb in it, maybe it ought to Dec 06 10:21:34 bluelightning: tnx, but "meta-yocto"? Dec 06 10:21:52 yes, it's part of poky Dec 06 10:22:12 and listed on the layer index page: http://www.openembedded.org/wiki/LayerIndex Dec 06 10:23:40 bluelightning: Thanks Paul. Dec 06 10:24:45 np Dec 06 10:25:35 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/machine Dec 06 10:30:10 actually I withdraw my statement. even with --sysroot properly set, arm-angstrom-linux-gnueabi-gcc fails to execute if it can't find libc.so.6 in /usr/local. Dec 06 10:48:49 * XorA wonders if anyone ever made a small usb hub + ethernet switch in same device Dec 06 11:07:42 should the symlinks from /etc/systemd/system/ to my services be created build-time? Dec 06 12:04:30 hmm, it seems like boost-native recipe is not staging the haders to x86_64-linux Dec 06 12:37:10 JaMa: have you tested core-image-sato with systemd ? Dec 06 12:37:47 no Dec 06 12:39:14 I see Dec 06 12:39:18 ant_work: btw to fix your issue with x11-common just set VIRTUAL-RUNTIME_xserver_common = "xserver-common" Dec 06 12:39:44 or rather issue with xserver-nodm-init from meta-oe Dec 06 12:39:54 JaMa: the two are now very different Dec 06 12:40:24 they always were different afaik Dec 06 12:40:40 this drift is a bad thing imho Dec 06 12:41:02 and on th ebackground there is systemd Dec 06 12:41:19 which seems no so appealin in oe-core Dec 06 12:41:21 that's why I wanted to sync them a while back.. Dec 06 12:42:01 JaMa: the two scripts are using different user! Dec 06 12:42:21 and? Dec 06 12:42:24 how can we pretend the mix can work Dec 06 12:42:58 if you mix wrong two toghetehr I'm not pretending it should work Dec 06 12:43:20 there is no choice once one adds meta-oe layer Dec 06 12:43:33 that's why I said that you should fix what you're mixing together (xserver-common provider from oe-core and xserver-nodm-init from meta-oe) Dec 06 12:43:42 ffs 13:35:20 < JaMa> ant_work: btw to fix your issue with x11-common just set VIRTUAL-RUNTIME_xserver_common = "xserver-common" Dec 06 12:44:09 JaMa: thx, I'll try but the point is it should work with defaults Dec 06 12:44:20 as it does with oe-core only Dec 06 12:45:18 distros using meta-oe already have VIRTUAL-RUNTIME_xserver_common set I guess Dec 06 12:45:30 I really appreciate your work, shame on us nobody seems interested to help you :/ maybe otavio... Dec 06 12:45:33 and for them it works with default distro setting Dec 06 12:51:07 JaMa: task-core-x11.bb sets VIRTUAL-RUNTIME_xserver_common ?= "x11-common" Dec 06 12:51:17 that is the 'default' Dec 06 12:52:14 I know, I've put it there :) Dec 06 12:53:34 well, then why do you expect me to override this when using meta-oe? Dec 06 12:54:28 ? Dec 06 12:54:48 it was added jut to make override possible from different layers Dec 06 12:55:27 so you can get consistent set of runtime providers Dec 06 13:01:17 ok, I see we have a problem there Dec 06 13:07:49 if my systemd inheriting recipe has done what it should, should I see the /etc/systemd/system/multi-user.target/ symlinks in temp/image? Dec 06 13:08:23 everything works, but my services are disabled on first boot, and I have to manually enable them Dec 06 13:09:16 tasslehoff: +.wants.. /etc/systemd/system/multi-user.target.wants/ Dec 06 13:11:19 ant_work: you can add task-core-x11.bbappend and change default in all places in meta-oe where VIRTUAL-RUNTIME_xserver_common is used to xserver-common Dec 06 13:11:51 then it could work by default with meta-oe with distroless setup Dec 06 13:12:51 as a band-aid yes, temporarly, could work Dec 06 13:13:25 but again, are there plans to unify the matter ? Dec 06 13:13:53 oe-core recently moved to evdev iirc Dec 06 13:15:44 with this http://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/systemd&id=e7e215cca623b51078d130beff01549c21e858a9 Dec 06 13:16:26 I won't need xserver-common anymore and if elsa replaces my xserver-nodm-init then both recipes can be dropped from meta-oe Dec 06 13:16:33 as koen is also using systemd Dec 06 13:17:44 we should know the oe-core's plans about implementing systemd Dec 06 13:18:16 so there are plans, but I'm 70hours/week at daywork lately so I'll work only on systemd case.. Dec 06 13:19:00 [13:41] I really appreciate your work, shame on us nobody seems interested to help you :/ maybe otavio... Dec 06 13:19:25 otavio is also using systemd afaik :) Dec 06 13:19:59 systemd boot times are really good Dec 06 13:20:04 systemd would solve the other outstanding issue with udev from meta-oe Dec 06 13:20:27 (can't create dev cache 'cause it's RO) Dec 06 13:28:30 ant_work: surely it's only an issue with meta-oe because the one in meta-oe is hard-configured to be suitable for use with systemd... Dec 06 13:30:39 JaMa: yes .. I am using it Dec 06 13:30:55 JaMa: I've been working at fixing the things I find while using it Dec 06 13:30:57 otavio: only or do you still have some sysvinit target? Dec 06 13:31:11 JaMa: all new projects are systemd Dec 06 13:31:31 JaMa: hm? that one I did not understand Dec 06 13:31:52 tasslehoff: you have shown wrong directory Dec 06 13:32:21 tasslehoff: right one ends with '.wants' Dec 06 13:33:31 otavio: I know you're working on it, but I wasn't sure if you still need sysvinit support in xinput-pointercal for older targets.. Dec 06 13:34:05 JaMa: ah. sorry Dec 06 13:34:28 but, the symlink is created on first boot? Dec 06 13:35:08 JaMa: at this moment I have no image using xinput-pointercal but will do in next cuple of weeks or so Dec 06 13:35:25 JaMa: then most probably I will try to fix that mess so I can use it heh Dec 06 13:36:20 otavio: I have -systemd service for it already.. Dec 06 13:36:52 JaMa: so send to meta-oe Dec 06 13:37:26 I need to fix elsa first Dec 06 13:38:30 anyone with an oe-core built SDK that can test if my claim is correct, that it looks for libc.so.6 in /usr/local no matter what sysroot is set to. Dec 06 13:38:30 JaMa: i see Dec 06 13:39:30 JaMa: as it is, thre is no other support for calibration in oe-core (xtscal is broken) Dec 06 13:40:08 I know Dec 06 13:40:31 so 'backport' xinput-calibrator for sysvinit makes sense imho Dec 06 13:40:53 someone tried and wasn't able to even copy current version from meta-oe.. Dec 06 13:40:57 heh Dec 06 13:41:47 ant_work: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-October/011061.html Dec 06 13:42:02 ant_work: ping him to send v2 Dec 06 13:42:23 I'm bothering you because there is 1.12 around the corner Dec 06 13:42:26 ;) Dec 06 13:42:40 1.12? Dec 06 13:42:52 xserver right? Dec 06 13:43:15 then bother him, because I'm always using meta-oe and I'm quite busy right now.. :) Dec 06 13:43:30 yes, new relase 1.11.2 Dec 06 13:51:22 ah, I though it was the same wind* developer, is not Dec 06 14:03:12 hm looks like llvm3.0 compiles Dec 06 14:13:08 *sigh* Dec 06 14:13:19 they patched the libatomic-ops Dec 06 14:13:26 the stinky old release Dec 06 14:41:13 anyone familiar w/ opkg and php on angstrom linux? have trouble getting php working Dec 06 14:46:19 jrp27517: looks like PHP is quite broken Dec 06 14:47:39 php is not liked Dec 06 14:47:41 very well Dec 06 14:47:46 so nobdy cares Dec 06 14:48:12 jrp27517: php works in oe-core Dec 06 14:48:35 ericben you have to maintain php? Dec 06 14:48:56 woglinde: to maintain: no. I have a customer whihc needed it last week and it compiled fine Dec 06 14:49:34 (and was also running fine on an arm926) Dec 06 14:55:41 thx - someone else suggested I also need php-cli so maybe that is my prob Dec 06 14:55:56 jrp27517: in my case we were using php-cli Dec 06 15:05:09 till later Dec 06 15:12:26 anyone opinions/experience on what best to use with squashfs fs? defualt, or lzo, or xz or lzma ? Dec 06 15:16:11 eFfeM_work: what are you looking for ? compression, speed ? I assume the choice will have a consequence on these parameters (but don't have numbers to provide to you) Dec 06 15:16:21 hi btw Dec 06 15:17:53 ericben, hi too, first of all I want to get it working, I added squashfs as image type get a file, added the fs to the kernel (but not lzo or xz) but it will not set it as root Dec 06 15:18:15 root fs that is Dec 06 15:24:11 nevermound, found it (but not solved it:-( ) squashfs does not like root=mtd:rfs style, only root=/dev/mtdblock6 (but would like to mount by name, not partition) Dec 06 16:31:21 eFfeM_work: I'm very sure I left a patch (at your place of work) that implements just that; lookup by name. Dec 06 16:31:52 xz/lzma for compression, lzo for speed Dec 06 16:32:27 otavio: are you reviving initramfs-bootimages from oe-classic? Dec 06 16:34:28 oe-core does not create the package "kexec-tools" for me; it creates packages called "kdump" and "kexec", not sure where this happens as this is not in the .bb file. Dec 06 16:35:27 likewise: the recipe splits the packaging Dec 06 16:35:29 http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-kernel/kexec/kexec-tools_2.0.2.bbappend Dec 06 16:37:08 ant_work: but the kexec-tools live in oe-core and something in oe-core has a dependency on kexec-tools... Dec 06 16:37:40 ant_work: thanks for the hint, would not quickly have found that bbappend in the meta-oe repo. Dec 06 16:38:11 ant_work: so I guess we need a meta-package called "kexec-tools" that RDEPENDS on "kexec" and "kdump". Dec 06 16:38:50 or just insist to have the package split in oe-core as well Dec 06 16:40:53 the only users of kexec/kdump in oe-classic were the initramfs images/modules Dec 06 16:42:13 ant_work: the only internal users, could be. With oe-core also used by Yocto, things become more subtle though. Dec 06 16:47:40 ant_work: not really; I wrote those from scratch Dec 06 16:47:48 ant_work: I am using it for one product here at work Dec 06 16:52:26 ok, look at http://cgit.openembedded.org/openembedded/tree/recipes/initrdscripts and at initramfs-bootmenu-image Dec 06 16:53:28 likewise: what's depending on kexec-tools btw? Dec 06 16:54:47 ant_work: task-core-tools-testapps Dec 06 16:56:51 likewise: ok, thx. Did not build it yet Dec 06 16:57:33 pretty cool, I made OE to spit me out a bootable vmdk image :> boot-directdisk.bbclass needed some fixing Dec 06 17:15:09 Jin^eLD: wow Dec 06 17:15:16 Jin^eLD: that is great Dec 06 17:15:32 I am reading the wiki to figure out about patch submitting policies and so on :P Dec 06 17:16:32 and the question is also if I should make an own bbclass that depends on boot-directidsk for the vmdk conversion or not... currently I am depending on the raw hdd image generation in my recipe, and then I do the vmdk conversion in the recipe itself Dec 06 17:17:01 Jin^eLD: oe classic or oe core? Dec 06 17:17:18 oe-core Dec 06 17:17:28 but I don't see why it should not be portable to classic Dec 06 17:17:31 https://gitorious.digitalstrom.org/dss-oe/dss-oe/blobs/master/dS/meta-dss11-devel/classes/boot-directdisk.bbclass Dec 06 17:17:39 that's my adapted directdisk class Dec 06 17:18:09 and that's my live image recipe: https://gitorious.digitalstrom.org/dss-oe/dss-oe/blobs/master/dS/meta-dss11-devel/recipes-core/images/dss11-vm-image.bb Dec 06 17:18:23 ant_work: please take a look on the patches I sent and see if you find something missing Dec 06 17:18:47 ant_work: i didn't add everything possible bit but it does works for me and has a fancy debug module :) Dec 06 17:20:34 Jin^eLD: ideally I would have thought just like the new live image functionality, it would be something you could just add to IMAGE_FSTYPES rather than having to have custom image recipes Dec 06 17:20:45 that's more work of course Dec 06 17:21:05 hmm indeed, it would make sense for IMAGE_FSTYPES... Dec 06 17:21:25 I'd need to have a look at that when I find some off-work time :) Dec 06 17:21:56 I guess I did not think about that because I found old live image recipes (that got removed from OE core) Dec 06 17:22:06 and I used them as an example starting point Dec 06 17:23:10 the existing boot-directdisk class needed some fixing though, it was not installing the syslinux.cfg by default Dec 06 17:25:21 btw maybe someone has a hint for me regarding an other problem: boot-native only produces bjam and nothing more, is tha somehow wanted or an error? I'd need the headers too Dec 06 17:25:30 but the boost recipe looks like rocket science Dec 06 17:27:52 the comment is great though :)) Dec 06 17:44:06 Jin^eLD: have a look at OE-core rev b3ff63796cd6629975ff0a726ba18cc168e0a2b2 Dec 06 17:48:49 oh ok Dec 06 17:48:59 I guess I missed that Dec 06 18:52:23 #miui-uss Dec 06 18:52:30 oops :) Dec 06 18:52:41 was? Dec 06 18:53:32 woglinde: was gonna join #oe and #miui-us in rapid pace, but weechat fooled me Dec 06 18:54:21 Does anyone know how to debug such errors? http://pastie.org/2976277 Dec 06 18:54:33 It looks like it's coming from meta/recipes-core/eglibc/eglibc-package.inc:do_install_locale () Dec 06 18:56:17 khem: ping. Dec 06 18:57:14 Is there a way to get bitbake to output a hint on who defines these clashing PACKAGES directives? Dec 06 19:00:07 (This is the only error left that the updated external arm-2011.03 csl toolchain receipt is generating) Dec 06 19:01:49 khem: I've been testing the SDK today, and I think ldd told me the truth after all. Even if I set sysroot where I have extracted the SDK, it seems to look for libc.so.6 in /usr/local Dec 06 19:02:15 denix: Crofton: usual channel or somewhere else? Dec 06 19:02:23 fine with me Dec 06 19:03:33 ~seen florian Dec 06 19:03:38 florian <~fuchs@Maemo/community/contributor/florian> was last seen on IRC in channel #oe, 8h 59m 38s ago, saying: 'likewise: Well... we should do both... so yes :)'. Dec 06 19:05:01 i'll send florian a reminder email Dec 06 19:06:25 re Dec 06 19:09:11 tasslehoff: What's you issue? Is it becuase the linker isn't able to find the dependent libraries? Dec 06 19:09:37 (At at runtime?) Dec 06 19:12:40 I'm not sure what the problem is but you may check the -rpath* options of the linker Dec 06 19:13:47 kenws: arm-angstrom-linux-gnueabi in my SDK doesn't run unless I extract the SDK to /usr/local Dec 06 19:14:27 kenws: I suspect it looks for libc.so.6 in the absolute path /usr/local, and not under the specified sysroot Dec 06 19:14:41 tasslehoff: and you're specifying --sysroot, right? Dec 06 19:14:57 kenws: yes Dec 06 19:17:34 tasslehoff: I'd check with: readelf -d /path/to/rootfs/bin/mybinary|grep NEED Dec 06 19:18:17 I'm not sure what the proper solution would be for the SDK but when building oe.core with an external toolchain I specify: Dec 06 19:18:18 TARGET_CPPFLAGS_prepend = " -isystem${EXTERNAL_TOOLCHAIN}/${TARGET_SYS}/include " Dec 06 19:18:18 TARGET_LDFLAGS_prepend = " -L${EXTERNAL_TOOLCHAIN}/${TARGET_SYS}/lib -Wl,-rpath-link,${EXTERNAL_TOOLCHAIN}/${TARGET_SYS}/lib " Dec 06 19:18:44 sorry, I gotta run (will be back in an hour or so) Dec 06 19:20:41 kenws: thanks. at home without the source now, but I'll check it out tomorrow. Dec 06 19:25:04 hi, is there a substitute for FEED_DEPLOYDIR_BASE_URI in OE-core/meta-oe/angstrom ? Dec 06 19:28:38 ericben: what exactly was that, pointing to own feed package for different urls? (that I know how to do) Dec 06 19:29:01 or was that var controlling where the packages go on disk? I never used it Dec 06 19:30:32 Jin^eLD: that was used to create a local ipk repository during development (ie I was setting FEED_DEPLOYDIR_BASE_URI=http://devpc:2000/ and playing with /etc/hosts on my target to say it where is the PC on which is running a busybox httpd -p 2000 in deploy/ipk Dec 06 19:31:24 ah, did not know it was for local stuff.. I created my own feed recipes Dec 06 19:31:36 and configured them like that in the local.conf: Dec 06 19:31:36 ANGSTROM_FEED_CONFIGS = "dss11-${RELEASE_TYPE}-feeds" Dec 06 19:31:37 OPKGCONFIG = "opkg opkg-config-base ${ANGSTROM_FEED_CONFIGS}" Dec 06 19:33:28 ok for release I was simply setting ANGSTROM_URI and using angstrom-feeds package which was then pointing to my server Dec 06 19:33:38 which is close to your method Dec 06 19:33:55 I think I did that too in the beginning but something did not work out the way I wanted, don't remember anymore Dec 06 19:35:27 so I switched to own feed packages Dec 06 19:48:03 ok I backported the thing from oe-classic, still have to test it once build finish :) Dec 06 19:48:37 ericben: DISTRO_FEED_URI Dec 06 19:49:06 hi khem Dec 06 19:49:35 ericben: hello Dec 06 19:49:45 I think that was in classic oe Dec 06 19:49:55 in oe-core you could try FEED_URIS Dec 06 19:50:00 IPK_FEED_URIS Dec 06 19:50:15 khem: ok in distro-feed-configs in meta-oe there is DISTRO_FEED_URI Dec 06 19:50:22 IPK_FEED_URIS fails here Dec 06 19:50:34 ericben: and how about FEED_DEPLOYDIR_BASE_URI Dec 06 19:50:44 opkg starts to eat memory and I have to kill it Dec 06 19:50:56 hmmm Dec 06 19:51:15 probably a bug in opkg Dec 06 19:51:16 khem: FEED_DEPLOYDIR_BASE_URI is what I've just backported from oe-classic (and what I was looking for a substitute ;) Dec 06 19:51:58 ericben: I have used DISTRO_FEED_URI with oe.classic Dec 06 19:52:02 in past Dec 06 19:52:04 and it has worked Dec 06 19:52:17 I dont publish feeds so this area is less excercised by me Dec 06 19:52:52 khem: ok, I was using FEED_DEPLOYDIR_BASE_URI for local dev and ANGSTROM_URI for releases Dec 06 19:53:13 thanks anyway if FEED_DEPLOYDIR_BASE_URI works in oe-core I'll send the patch Dec 06 19:53:39 ericben: its there in oe-core wether it works or not I dont know Dec 06 19:54:16 weird its in documentation but really not implemented Dec 06 19:54:28 I didn't foudn it in core only in the doc so I backported it. time to read a storry to my son ;) Dec 06 19:54:39 will tell you later if that works Dec 06 19:54:40 thanks Dec 06 19:55:23 why does IPK_FEED_URIS fail ? Dec 06 19:55:39 oh ok Dec 06 19:58:35 tasslehoff: hmmm Dec 06 19:58:57 tasslehoff: ldd does not know about sysroot I think that could be the problem Dec 06 20:00:33 khem: does that mean ldd tricks me into believing something is wrong, or that something *is* wrong? Dec 06 20:00:44 tasslehoff: could be Dec 06 20:01:07 tasslehoff: ok when you run readelf -d what does it say for needed field Dec 06 20:02:59 khem: at home without the sdk at hand now, but I can test tomorrow morning. had a feeling you'd be here now so I stopped by :) Dec 06 20:03:24 yes please do. Dec 06 20:03:42 tasslehoff: and if you find and notable differences between old SDK and new SDK please let me know Dec 06 20:05:25 khem: may have mentioned it, but the old SDK could be extracted "anywhere" on my system. so this is a notable difference :) Dec 06 20:06:00 tested my new oe-core image with sdk-built apps today, and everything worked like a charm Dec 06 20:20:19 tasslehoff nice to hear Dec 06 20:28:45 khem: Hi, are you still there? I remember hwr saying that your're the toolchain expert. : ) I'm building oe-core with an external toolchain and it works quite good so far - the resultant image boots within qemuarm. However, there is one error msg left when doing the do_package task: http://pastie.org/2976772 Dec 06 20:29:21 Do you know how to find out what causes the clash? Any hints are appreciated... Dec 06 20:29:58 hm locales Dec 06 20:30:07 and its more a packaging error Dec 06 20:30:15 not really toolchain Dec 06 20:31:23 woglinde: ok, I agree. It's the packaging step of the external toolchain receipt Dec 06 20:32:41 I'm using the same PACKAGES directives as meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb Dec 06 20:32:57 locale-base-* isn't listed directly Dec 06 20:33:23 I guess it gets pulled pulled in by another toolchain related receipt Dec 06 20:34:42 woglinde: Do you know a way to find out where it's coming from? Dec 06 20:35:16 The only thing I saw is meta/recipes-core/eglibc/eglibc-package.inc:do_install_locale () Dec 06 20:36:28 hm Dec 06 20:36:42 you could try the -e flag on bitbake Dec 06 20:36:47 and exaime PACKAGES Dec 06 20:36:49 and FILES Dec 06 20:36:56 examine Dec 06 20:36:59 woglinde: ok, thanks. I'll give it a go Dec 06 20:37:33 eglibc/glibc is packaged somewhat automagikally Dec 06 20:37:58 kenws: if you can figure out the names of locale-base- Dec 06 20:38:05 I am looking for patterns Dec 06 20:38:23 are there more locale-base-X-Y instances ? Dec 06 20:39:01 khem: I can put the list of them to pastebin - I haven't checked it but maybe it's all of them Dec 06 20:39:27 where do they come from remains a mystery to me though Dec 06 20:39:51 there is a function called output_locale in classes/libc-package.bbclass which does name munging Dec 06 20:40:22 and it could be that something is outside it knowledge when it comes to external toolchains Dec 06 20:41:35 $ grep errors test.log|cut -d ':' -f 2| cut -d '.' -f 1|pastebinit Dec 06 20:41:36 http://paste.ubuntu.com/762025/ Dec 06 20:41:47 whoops, ignore the command Dec 06 20:43:16 ok so it seems you just noticed tip of iceberg Dec 06 20:43:29 its probably not only those 2 but all of them apparently Dec 06 20:44:22 yep Dec 06 20:44:43 I guess so (but haven't checked it) Dec 06 20:45:10 Here is the -e output in case it helps any: http://paste.ubuntu.com/762030/ Dec 06 20:45:39 what is GLIBC_INTERNAL_USE_BINARY_LOCALE and GLIBC_GENERATE_LOCALES set to Dec 06 20:45:55 kenws why you need the external toolchain at all? Dec 06 20:47:01 ok so u have GLIBC_INTERNAL_USE_BINARY_LOCALE="precompiled" Dec 06 20:47:14 woglinde: may be that was decided above his paygrade :) Dec 06 20:47:15 khem: my bb file has: GLIBC_INTERNAL_USE_BINARY_LOCALE = "precompiled" and my locale.conf has ENABLE_BINARY_LOCALE_GENERATION = "0" Dec 06 20:47:55 ieehks gnutls error Dec 06 20:47:58 with uclibc Dec 06 20:47:59 woglinde: one reason is to use oe-core for testing binary toolchains : ) Dec 06 20:48:15 | ../../gl/sys/time.h:396:66: error: conflicting declaration 'void* restrict' Dec 06 20:48:15 | ../../gl/sys/time.h:396:50: error: 'restrict' has a previous declaration as 'timeval* restrict' Dec 06 20:49:30 kenws: are you linaro'ite ? Dec 06 20:49:39 khem: I've also played with setting GLIBC_GENERATE_LOCALES to "en_US.UTF-8" but it didn't seem to reduce the errors Dec 06 20:50:24 woglinde: wow thats crap Dec 06 20:50:52 khem: if you mean if I work for/with linaro, then - yeah : ) Dec 06 20:51:33 kenws: did setting GLIBC_GENERATE_LOCALES = "en_US.UTF-8" reduce the errors Dec 06 20:51:37 in numbers Dec 06 20:52:03 let me check Dec 06 20:53:11 khem: patch posted to backport FEED_DEPLOYDIR_BASE_URI to oe-core Dec 06 20:53:21 ericben: cool Dec 06 20:53:32 did you tell the same story to kid as well :) Dec 06 20:54:02 once upon a time dad forward ported FEED_DEPLOYDIR_BASE_URI :) Dec 06 20:54:29 well that was nearly the 100th time I read this one but he likes it ;-) Dec 06 20:54:30 my son never wants to listen to stories from me. I guess I do a crappy job at that Dec 06 20:54:50 khem: nope, it doesn't reduce the clashes in numbers, it's still 153 Dec 06 20:55:15 uhm which? Dec 06 20:55:19 story Dec 06 20:55:48 woglinde: Thomas the train engine !! Dec 06 20:56:20 probably I should start telling stories about compilers Dec 06 20:57:47 * khem -> SIGFOOD Dec 06 20:58:15 : ) Dec 06 20:58:21 bon appétit ;-) Dec 06 21:03:09 kenws: before I leave, can you set GLIBC_INTERNAL_USE_BINARY_LOCALE = "disable" and see if it helps Dec 06 21:04:20 khem: Ok, thanks. I'll try that as soon as the run with LOCALE_UTF8_ONLY = "0" finished Dec 06 21:04:58 ok, LOCALE_UTF8_ONLY = "0" doesn't show any impact on these errors - strange Dec 06 21:09:06 khem: GLIBC_INTERNAL_USE_BINARY_LOCALE = "disable" does change it! Now I get warning about unpacked files but those are easy to fix Dec 06 21:09:25 s/warning/warnings/ Dec 06 21:13:23 hm, but I have to admit that I don't understand why the libc-package.bbclass does the output_locale step Dec 06 21:14:31 yeah thomas die lokomotive Dec 06 21:14:39 only watched the movies Dec 06 21:16:01 not yet read that one here ;-) Dec 06 21:19:52 khem hm I did something hacky and replaced the second restrictive with restrictive1 Dec 06 21:19:56 now it compiled Dec 06 23:01:24 ericben, hi Dec 06 23:35:54 trying to cobble a linux 3.2 recipe, I get "ERROR: Nothing PROVIDES 'virtual/arm-commonos-linux-gnueabi-depmod-3.2'" ; what might I have done wrong? Dec 06 23:38:55 awozniak: is it using oe.classic ? Dec 06 23:39:05 awozniak: see DEPENDS += "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}depmod-${@get_kernelmajorversion('${PV}')} virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX} update-modules bluez-dtl1-workaround" Dec 06 23:39:19 that comes from classes/kernel.bbclass Dec 06 23:39:57 -${@get_kernelmajorversion('${PV}') can be dropped Dec 06 23:40:52 khem: thanks Dec 06 23:41:24 khem: will that break other stuff if it gets removed? Dec 06 23:41:41 (I'm supporting half a dozen machines here, some with older kernels) Dec 06 23:47:11 awozniak: hmmm it was fixed in oe-core Dec 06 23:47:27 you might want to check those commits and backport them if you want to do it right Dec 06 23:50:28 khem:kthx **** ENDING LOGGING AT Wed Dec 07 02:59:57 2011