**** BEGIN LOGGING AT Tue Aug 02 02:59:57 2011 Aug 02 03:10:42 hi guys, I'm getting an error on recipes/base-files/base-files_3.0.14.bb but it just tells me it failed, I've used -D argument to bitbake. how do I see where exactly it's failing? **** BEGIN LOGGING AT Tue Aug 02 03:41:18 2011 Aug 02 03:49:24 anyone use SHR? i cant receive SMS and im wondering how to diagnose this. Aug 02 03:54:36 is there a way to run rm_work on all packages recursively? I forgot to add it to site.conf and am painfully out of space now Aug 02 03:55:10 (the above of course referring to bitbake) Aug 02 05:32:29 dorileo: paste complete build log somewhere Aug 02 05:32:58 slobo: add it to local.conf and restart the build Aug 02 05:34:08 slobo: and may be also add BB_SCHEDULER = "completion" Aug 02 05:34:15 to local.conf Aug 02 05:34:55 gn all Aug 02 05:35:27 thanks khem Aug 02 05:35:35 i'll give it a go Aug 02 06:26:06 INHERIT += "rm_work" and BB_SCHEDULER = "completion" in local.conf and restarting the build did it. thanks Aug 02 06:53:35 Hi everyone Aug 02 06:54:08 Which is the recipe name that I must use to build the kernel ? Aug 02 06:56:50 uhm, usually linux-machinename Aug 02 06:57:17 I've just found "virtual/kernel"... Aug 02 06:57:31 is it the same? Aug 02 07:24:23 In my machine conf I'm using PREFERRED_VERSION_linux = "2.6.32.27" Why does it still compile 2.6.37 ? Aug 02 07:24:49 hi everybody Aug 02 07:24:58 hi eFfeM_work Aug 02 07:25:27 I have obe question Aug 02 07:26:47 If I have commited one change in my local git repo which is I have moved one task to another bbclass Aug 02 07:28:06 so not I want to add a task from where I moved the previous task ..... should I sent my patch from my modified file or I have to get unmodified file from main branch and send patch based on that file? Aug 02 07:28:47 *so now Aug 02 07:40:41 Is there someone who could help me with kernel compilation? Aug 02 09:07:53 hello Aug 02 09:08:46 I had a builded a filesystem for mini2440 using oe... I want ffmpeg package .... but bitbake fail.... can anyone help me.... Aug 02 09:10:10 recipes/liba52/liba52_0.7.4.bb do_configure failed Aug 02 09:10:51 morning all Aug 02 09:11:09 sanket: pastebin the whole error please Aug 02 09:12:40 bluelightning, http://pastebin.mozilla.org/1287102 Aug 02 09:13:21 "configure: error: C compiler cannot create executables" Aug 02 09:13:27 something quite badly wrong there Aug 02 09:13:33 what command did you use? Aug 02 09:13:51 bluelightning, i had use bitbake ffmpeg Aug 02 09:14:01 hmm ok Aug 02 09:14:22 not sure what could be causing this but there's something fundamentally wrong with your build Aug 02 09:19:14 i get a really strange python error here: http://pastebin.com/CuNikEW1 Aug 02 09:19:21 does anybody have an idea how to fix that? Aug 02 09:19:41 i have Python 2.7.2 and kernel 3.0.0 Aug 02 09:20:25 how can that be a syntax err? Aug 02 09:32:15 mickeyl: alive? Aug 02 09:33:23 fraxinas: doesn't make much sense to me either. can you pastebin the contents of opkg-make-index in your build? Aug 02 09:33:40 ayeaye Aug 02 09:34:20 http://pastebin.com/EzTrb6Sk Aug 02 09:34:47 nothing that looks unusual to me in that script Aug 02 09:41:02 hrw: somewhat ;) Aug 02 09:41:28 fraxinas: seems OK to me also... Aug 02 09:43:57 i already c clean'ed the package and rebaked it without success Aug 02 09:49:31 mickey|office: baby (forgot name) does not allow to sleep? Aug 02 09:50:10 fraxinas: + ipkgarchs='all any noarch mipsel dm8000' Aug 02 09:50:21 ^^ looks suspicious Aug 02 09:50:31 in which way? Aug 02 09:50:55 the spacing Aug 02 09:51:06 I had a related issue maybe Aug 02 09:51:08 moment Aug 02 09:52:09 http://paste.debian.net/124848/ Aug 02 09:52:14 where does that line come from? run.do_package_update_index_ipk.5614 ? Aug 02 09:52:55 soo you're saying the extra space could be the problem Aug 02 09:53:14 once I fixed it disappeared Aug 02 09:53:42 i'll just edit the run.do_package_update_index_ipk.5614 line by hand real quick Aug 02 09:53:45 to see if that solves it Aug 02 09:54:05 maybe is totally unrelated... Aug 02 09:54:08 it's even two extra spaces Aug 02 09:54:44 fraxinas: in my case a whole token was disappering Aug 02 09:55:58 ah no that doesn't work, it generates a new run script every time Aug 02 09:56:07 so i'll try to fix it in the machine conf Aug 02 09:56:17 see http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/conf/machine/include/tune-mips32.inc Aug 02 09:58:20 hmm my machine.conf doesn't have any PACKAGE_EXTRA_ARCHS concatenation in there Aug 02 09:58:32 maybe one of the required incs Aug 02 10:01:17 yeah that would probably be it ant_work Aug 02 10:01:25 you'll have to check the recent tune overhaul... Aug 02 10:01:30 in tune-mips.inc Aug 02 10:01:49 PACKAGE_EXTRA_ARCHS += "${@['${MIPS_PACKAGE_ARCH}', ''][bb.data.getVar('TARGET_ARCH', d, 1) == '${MIPS_PACKAGE_ARCH}']}" Aug 02 10:02:34 what is tune-mips.inc? Is no in oe-core or am I blind? Aug 02 10:03:08 [fraxinas@fox /dream/opendreambox-layers/meta-bsp/common/conf/machine/include]$ more tune-mips32.inc Aug 02 10:03:09 MIPS_ARCH = "mips32" Aug 02 10:03:09 require conf/machine/include/tune-mips.inc Aug 02 10:03:25 I'd say remove it and include he new one Aug 02 10:03:35 hrw: Lara Marie. once she's asleep, everything is ok, but she does not fall asleep alone. We have to help her by walking circles ~30 mins or sometimes longer… every time. Aug 02 10:03:50 hmm i'll talk to obi about that Aug 02 10:04:08 bescheinende Frage: you use oe-core, isn't? Aug 02 10:04:48 there is ambiguity nowadays Aug 02 10:06:42 uhm... i am not exactly sure actually Aug 02 10:07:03 this is a brand-new oe thingie which obi built and i'm just learning how to use it correctly Aug 02 10:07:21 the old ond which we're currently using is ... ancient Aug 02 10:07:59 just look in the tree and see... one big /recipes == old/classic oe ;) Aug 02 10:14:53 * tasslehoff listens in to figure out if it's time to find out what oe-core is Aug 02 10:24:08 I'm gonne do a merge of upstream, and want to fetch all the new goodies I need to build my rootfs. Then I'm gonna go online and build it. How can I do this fetch? Aug 02 10:26:42 tasslehoff: bitbake -c fetchall target Aug 02 10:28:53 thanks bluelightning Aug 02 10:29:02 no worries Aug 02 10:31:17 ant_work turns out to be a python3 issue Aug 02 10:35:39 fraxinas: hmm I did wonder about that, but immediately discounted it since you said you were usign 2.7.2 :) Aug 02 10:37:29 i thought i was but obviously one of the scripts used /usr/bin/python which linked to python3 Aug 02 10:37:43 when my /usr/local/bin/python pointed to python2 Aug 02 10:38:12 i relinked /usr/bin/python to python2 aswell and it works then Aug 02 10:56:11 fraxinas: was that you posting on the oe mailing list about this issue? if so you might want to reply to it with your findings Aug 02 10:57:01 nope not me Aug 02 10:59:52 ah ok... hmm Aug 02 11:11:46 is any of you coming to prague in autumn? Aug 02 11:11:56 elc-e Aug 02 11:19:54 how can I influence the order in which packages are installed by 'opkg'? opkg seems to know a 'Pre-Depends' attribute but this is not set by package_ipkg.bbclass Aug 02 11:50:45 I'm not sure you can, except for RDEPENDS obviously. What's the actual problem you're trying to solve? Aug 02 11:53:28 pb_: I have a filesystem package which has a /boot -> /var/lib/boot symlink. Somehow, kernel-image (which contains /boot/vmlinux) is now installed before the filesystem package which causes a Aug 02 11:53:33 * extract_archive: Cannot create symlink from ./boot to 'var/lib/boot': File exists. Aug 02 11:53:36 error Aug 02 11:56:15 real problem is that .ipkg own all base directories (e.g. /bin is owned by nearly every package) Aug 02 11:56:45 opkg calculates installation order based on directory ownership so the final order is very random Aug 02 12:07:34 ah, yes, I see Aug 02 12:08:25 I'm not sure there is any good solution to that unfortunately. Aug 02 12:09:36 I added the filesystem package as the first RDEPENDS of the top level task package Aug 02 12:10:00 that's not nice but it seems to work Aug 02 12:20:00 yeah Aug 02 12:20:28 or you could just install the packages in multiple phases, i.e. have a first opkg run which just installs the filesystem package, and then everything else afterwards in a second run. Aug 02 12:21:09 obviously this particular issue is only going to arise during image construction, though the same general problem could happen in theory with on-device installs too. Aug 02 12:25:06 afair, there was a post on the maillist which allowed to package only the files, not the directories Aug 02 12:28:16 http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg03049.html Aug 02 13:49:27 03Joshua Lock  07master * r7b977ff222 10bitbake.git/lib/bb/ui/hob.py: Aug 02 13:49:27 hob: unset busy cursor on exit Aug 02 13:49:27 Prevent the busy cursor being shown after hob exits if quit is called Aug 02 13:49:27 whilst the busy cursor is set. Aug 02 13:49:27 Signed-off-by: Joshua Lock Aug 02 13:49:27 03Joshua Lock  07master * r1009ca570a 10bitbake.git/lib/bb/ui/ (crumbs/hobeventhandler.py hob.py): Aug 02 13:49:28 hob: remove temporary directory on program shutdown Aug 02 13:49:28 Move temp directory handling into the HobEventHandler and clean up the Aug 02 13:49:29 temporary files on program close. Aug 02 13:49:29 Fixes [YOCTO #1307] Aug 02 13:49:30 Signed-off-by: Joshua Lock Aug 02 13:49:30 03Joshua Lock  07master * r15cc4fe505 10bitbake.git/lib/bb/ui/crumbs/hobeventhandler.py: Aug 02 13:49:31 ui/crumbs/hobeventhandler: emit a signal when a command fails Aug 02 13:49:31 If a CommandFailed event is seen emit a signal with the error message. Aug 02 13:49:32 Signed-off-by: Joshua Lock Aug 02 13:49:32 03Joshua Lock  07master * r2f7eadfdd7 10bitbake.git/lib/bb/ui/crumbs/layereditor.py: Aug 02 13:50:37 ui/crumbs/hobeventhandler: remove unused code Aug 02 13:50:37 Remove some unused variables and methods. Aug 02 13:50:37 Signed-off-by: Joshua Lock Aug 02 13:50:37 03Joshua Lock  07master * rb6f6edd509 10bitbake.git/lib/bb/ui/crumbs/hobeventhandler.py: Aug 02 13:50:37 ui/crumbs/hobeventhandler: emit a signal when there's a fatal-error Aug 02 13:50:38 If the cooker encounters an error we're unable to proceed so emit a signal Aug 02 13:50:38 so that UI's can notify the user and exit. Aug 02 13:50:39 Signed-off-by: Joshua Lock Aug 02 13:52:07 hi. i'm trying to build with configuration angstrom-2001.3 for the pandaboard, using the 2011.03-maintenance branch. Aug 02 13:53:04 first, i wonder if "pandaboard" is a supported MACHINE at all. "omap4430-panda" fails later :) Aug 02 13:54:44 and then there is something that looks like a bug: http://pastebin.com/e7LEQwxv Aug 02 13:54:56 when trying to bitbake x11-image Aug 02 13:55:28 i'd like to know if i have forgotten something, or if it's a problem in openembedded, bitbake or somewhere else. Aug 02 13:56:36 (this is with MACHINE=omap4430-panda) Aug 02 14:18:40 another one: openembedded/recipes/images/gpephone-image.bb: Could not inherit file classes/rootfs_${IMAGE_PKGTYPE}.bbclass Aug 02 14:19:03 sounds like you didn't set a DISTRO Aug 02 14:19:38 i did, DISTRO = "angstrom-2011.3" Aug 02 14:20:18 well, the distro sets IAMGE_PKGTYPE, so apparently you didn't pick a valid one, or you have something else wrong in your setup (e.g. wrong BBPATH) Aug 02 14:20:29 look in conf/distro/ Aug 02 14:20:47 setting IMAGE_PKGTYPE manually leads to another error later... Aug 02 14:20:58 is angstrom-2011.3 not valid? Aug 02 14:21:09 probably something else that would have been set by your distro. hacking around it isn't going to fix the underlying problem Aug 02 14:21:18 ok Aug 02 14:21:30 again, look in conf/distro/ Aug 02 14:21:36 if it's not there, it isn't going to work Aug 02 14:23:11 the funny thing is that neither in master nor in the 2011.03-maintenance branch is there any .conf containing "2011". Aug 02 14:23:36 however the narcissus tool has 2011.3 listed as a valid distro Aug 02 14:25:04 oh i see, 2011.3 is probably only in the release-2011.03 tag Aug 02 14:25:08 what that likely means is use of the 2011.03-maintenance branch of OE, based on the 2011.3 oe release Aug 02 14:25:12 yes Aug 02 14:25:26 and 2010.x is in fact whatever is current Aug 02 14:27:32 i've tried 2010.x earlier, but that didn't work apparently due to a bug or incompatibility with bitbake 1.13. Aug 02 14:34:20 that looks good now, bitbake is doing its thing after installing a few missing dependencies on the host machine. Aug 02 14:34:24 thanks kergoth. Aug 02 14:34:57 great, np Aug 02 14:43:25 how can I make a symbolic link between two folders in the rootfilesystem? (I need to link lib64 to lib) Aug 02 14:45:03 create a recipe that makes a package tha tincludes it, add it to an existing recipe/package, or use ROOTFS_POSTPROCESS_COMMAND Aug 02 14:55:46 ok thanks. I'll try the ROOTFS_POSTPROCESS_COMMAND method Aug 02 15:22:13 morning kergoth Aug 02 15:22:19 RP__: around? Aug 02 15:59:09 hello openembedded-core/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb does not compile: ./freedesktop.org.xml:754: parser error : Unescaped '<' not allowed in attributes values Aug 02 15:59:09 | Any idea why pkgconfig can't find glib-2.0 in my sysroot? Aug 02 16:42:56 hi Aug 02 16:43:13 add glib-2.0 to the dependency of the thing it's building Aug 02 18:15:33 GNUtoo|laptop - It is. I'm trying to build gstreamer. glib-2.0 has been built. Aug 02 18:15:49 glib-2.0.pc is where it needs to be in the sysroot, but the gstreamer configure process still fails. Aug 02 18:31:36 03Philip Balister  07master * r3195e1a544 10openembedded.git/recipes/tasks/task-sdk-gnuradio-native.bb: Aug 02 18:31:36 task-sdk-gnuradio-native : Remove distcc. Aug 02 18:31:36 I shouldn't have added this to the sdk. Deal with this at the image level. Aug 02 18:31:36 Signed-off-by: Philip Balister Aug 02 18:33:25 galak: SYSTEMLIBS_DIR hmmm Aug 02 18:33:31 galak: thats advanced hackery to beat oe to use same sourcedir for building gcc in different flavours Aug 02 18:33:50 nterpreter paths are hardcoded into gcc itself Aug 02 18:33:58 so we need to have different interpreter paths for cross sdk Aug 02 18:34:11 and earlier when we had every gcc recipe have its own srctree then we could keep such hackery limited to those recipes e.g. gcc-cross-sdk etc. Aug 02 18:34:12 khem: hmm, can you give an explicit example Aug 02 18:34:31 so at configure time we would emit a .h file which contains the prefix for ld.so Aug 02 18:34:37 and then we would concetenate that to name of ld.so to form the final path Aug 02 18:34:47 at gcc build time using defines Aug 02 18:34:52 this is GLIBC_DYNAMIC_LINKER Aug 02 18:35:00 right, I'm familiar with that side Aug 02 18:35:16 so that hunk there is to return empty string Aug 02 18:35:19 what I'm not clear is what 'values/paths' we want to set GLIBC_DYNAMIC_LINKER to Aug 02 18:35:40 galak: thats upto the arch how its setup Aug 02 18:36:11 galak: usually it should be inline with the root file system patchs Aug 02 18:36:38 so normally I'd expect /lib/.. or /lib64/.. Aug 02 18:36:42 yes Aug 02 18:36:51 its mucked when generating cross SDK Aug 02 18:37:05 that the bit that I'm not clear on it Aug 02 18:37:25 is the 'cross SDK' unique or different some how? Aug 02 18:37:35 #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2" Aug 02 18:37:46 since / is already there Aug 02 18:38:22 right so it seems bad/wrong to have SYSTEMLIBS_DIR = "' Aug 02 18:38:30 SYSTEMLIBS_DIR = "" Aug 02 18:39:10 that would end up with #define GLIBC_DYNAMIC_LINKER64 "/ld-linux-x86-64.so.2" Aug 02 18:39:17 correct Aug 02 18:40:24 thus my confusion on what these two lines are trying to accomplish: Aug 02 18:40:24 SYSTEMLIBS_DIR=`dirname ${SYSTEMLIBS}` Aug 02 18:40:24 [ "$SYSTEMLIBS_DIR" = "/" ] && SYSTEMLIBS_DIR="" Aug 02 18:41:41 galak: that seems redundant to me Aug 02 18:42:56 galak: a case when target_base_libdir is / this could end up with // Aug 02 18:42:56 khem: It's necessary should someone attempt to use oe under cygwin. Aug 02 18:43:18 Circuitsoft: if you want your wife to runaway yes :) Aug 02 18:43:33 khem: Under cygwin, //a/b/c is folder c under share b on SMB server a. Aug 02 18:43:54 yes Aug 02 18:44:04 That has cought me on a few attempts to port things on Windows. Aug 02 18:44:28 I've since, for the most part, given up, but it is occasionally necessary. Aug 02 18:45:29 galak: but that line should not trigger if you have /lib or /lib64 Aug 02 18:45:30 khem: how is it redundant, I'm still not clear on when its the right thing for GLIBC_DYNAMIC_LINKER64 to be just "/ld-linux-x86-64.so.2" Aug 02 18:46:07 khem: it does, dirname "/lib" returns "/" Aug 02 18:46:24 galak: hmmm Aug 02 18:46:26 right Aug 02 18:51:08 galak: actually its this #define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR "/lib/ld-linux.so.2" Aug 02 18:51:19 so SYSTEMLIBS_DIR gets concatenated Aug 02 18:51:25 prepended actually Aug 02 18:51:34 to original GLIBC_DYNAMIC_LINKER Aug 02 18:51:44 yeah, the sed line is broken in that respect Aug 02 18:51:53 thats why it works Aug 02 18:52:13 it works by a fluke right now ;) Aug 02 18:52:21 I think that was the intent Aug 02 18:52:35 since for SDKs SYSTEMLIBS_DIR will be somewhere else Aug 02 18:52:40 since it will be sysrooted Aug 02 18:52:44 not according to the commit message Aug 02 18:53:02 hmmm Aug 02 18:53:07 * khem reads the commit message Aug 02 18:56:12 galak: yes the commit message is misleading Aug 02 18:56:26 galak: what it does it ok I guess Aug 02 18:56:44 hmmm was it a fluke that it was correct Aug 02 18:56:48 by it you mean the commit message or the code? Aug 02 18:56:50 or if patch changed Aug 02 18:56:59 and commit message was not adjusted Aug 02 18:57:02 I dont know Aug 02 18:57:22 yeah I am looking at the git log of that patch Aug 02 18:57:52 this patch had some iterations and may be author forgot to update the commit message is my guess Aug 02 18:58:29 you can look back in the ml archives Aug 02 18:58:35 and see if thats the case Aug 02 18:58:51 hmm, didn't think to look at ml archives, going to look now Aug 02 18:59:48 I still think its broken (the patch) as we have issues with 64-bit (non-multilib) setups Aug 02 19:00:04 today we seem to default to /lib regardless of 32-bit or 64-bit and thus: Aug 02 19:00:04 #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64/ld-linux.so.2" Aug 02 19:00:08 wouldn't be right Aug 02 19:01:12 galak: yes see my reply I send few minutes ago Aug 02 19:01:48 galak: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-August/007439.html Aug 02 19:02:23 galak: so since ppc64 is kind of new I would say do the right thing Aug 02 19:02:28 use the defaults that gcc has Aug 02 19:03:11 for ppc64 biarch lib64=64bit and lib=32bit Aug 02 19:03:26 khem: where do I need to change /lib to /lib64 for ppc64 Aug 02 19:03:29 for ppc64 single arch lib64=64bit Aug 02 19:03:46 thats another problem Aug 02 19:03:49 ppc64 isn't all that new Aug 02 19:04:05 Tartarus: yes in OE-core its new though Aug 02 19:04:06 But 32bit /lib and 64bit /lib64 on 64bit is 'normal' for it Aug 02 19:04:48 galak: that should not need any change in gcc but in oe you have to account for lib64 Aug 02 19:05:08 khem: yeah, its the OE bit I was asking about Aug 02 19:05:10 since I think it did not grok anything other than 'lib' in the past for libdir Aug 02 19:05:23 its the libdir and base_libdir Aug 02 19:05:26 variables Aug 02 19:05:36 I'm in agreement, since it matches historic for ppc64 for other distros Aug 02 19:05:46 they should be using /lib64 and /usr/lib64 respectively Aug 02 19:06:19 right now we will have problems with x86/x86_64 since both exist in oe-core Aug 02 19:06:26 and they both use 'lib' Aug 02 19:06:34 so when they mulitlib one has to break Aug 02 19:06:53 basically its messed up Aug 02 19:07:07 but for ppc and mips we cann do the *right thing* Aug 02 19:08:40 khem: ok so we have the following in meta/conf/bitbake.conf: Aug 02 19:08:44 baselib = "lib" Aug 02 19:08:56 galak: meta/conf/bitbake.conf:baselib = "lib" Aug 02 19:09:01 make it lib64 Aug 02 19:09:05 and then fix the fallouts Aug 02 19:09:48 galak in meta/conf/multilib.conf we already do that Aug 02 19:10:28 khem: right, I'm learning how variables work here, so not sure what the best way to 'override' this is for ppc64 Aug 02 19:10:31 so if you have BASE_LIB_tune-ppc64 or somesuch set to lib64 Aug 02 19:10:48 we have that: Aug 02 19:10:48 meta/conf/machine/include/powerpc/arch-powerpc64.inc:BASE_LIB_tune-powerpc64 = "lib64" Aug 02 19:11:21 meta/conf/machine/include/powerpc/arch-powerpc64.inc Aug 02 19:11:23 already has it Aug 02 19:11:37 so it should do the right thing Aug 02 19:11:39 but that requires multilib.conf usage, trying to make a pure 64-bit build work first Aug 02 19:11:49 if you have multilib.conf included Aug 02 19:11:53 thats the missing link I believe Aug 02 19:12:05 oh Aug 02 19:12:54 I guess for that to work yeah you need to override baselib in meta/conf/machine/include/powerpc/arch-powerpc64.inc Aug 02 19:13:04 unconditionally Aug 02 19:13:41 but there might be more needed since as I said oe metadata only groked 'lib' for libdir Aug 02 19:13:53 so fixing those would be needed as you go Aug 02 19:14:16 other option is to hack gcc like it was done for x86_64 Aug 02 19:14:32 the very same hunk that RP__ removed is needed for ppc64 as well Aug 02 19:14:42 but I would not advise doing that Aug 02 19:14:48 I have the hack right now locally, but I'd like to avoid it Aug 02 19:15:12 yeah I think fixing metadata to let defaults use lib64 would be right Aug 02 19:21:14 Is there an easy way to run pkgconfig in my sysroot to debug a configure script? Aug 02 19:27:04 khem: trying a build now for ppc64 w/lib64. I'm thinking the multilib changes should have cleaned most of this up Aug 02 19:41:14 How can I completely restart a recipe? I tried deleting the work/my_sysroot/packagename-vers directory, but bitbake is still trying to restart with do_install. Aug 02 19:46:18 Circuitsoft: bitbake -ccleanall Aug 02 19:46:25 Circuitsoft: btw. that with oe-core Aug 02 19:46:51 Circuitsoft: with oe.dev use bitbake -cclean that should help Aug 02 19:48:24 What's the difference between clean and cleanall? Aug 02 20:21:35 My new recipe tries to fetch from a mirror instead of git, how does one disable mirrors in OE? Aug 02 20:22:21 look for a STASH variable in local.conf or bitbake.conf Aug 02 20:23:30 woglinde: couldn't find a STASH variable Aug 02 20:23:51 developer0 are you oe-core? Aug 02 20:24:01 woglinde: no oe-classic Aug 02 20:24:18 than its CVS_STASH Aug 02 20:24:22 look in local.conf Aug 02 20:24:46 # Specifies a location to search for pre-generated tarballs when fetching Aug 02 20:24:46 # a cvs:// URI. Outcomment this, if you always want to pull directly from CVS. Aug 02 20:24:47 CVS_TARBALL_STASH = "" Aug 02 20:25:28 woglinde: ok thanks, let me try setting it to nothing Aug 02 20:32:11 woglinde: it still tries to fetch from the mirror instead of git Aug 02 20:32:30 hm Aug 02 20:32:48 than try to kill the wget Aug 02 20:32:50 angstrom ? Aug 02 20:32:57 yes Aug 02 20:33:15 well angstrom redirects all kind of dnld to mirror Aug 02 20:33:23 including git cvs and what not Aug 02 20:34:04 galak: We need to fix the sed in gcc configure to do the right thing Aug 02 20:34:11 galak: That is the proper fix for this Aug 02 20:34:15 true Aug 02 20:34:35 so you only way to disable INHERITing "angstrom-mirrors" Aug 02 20:34:48 or modify the class to not care for cvs:// etc. Aug 02 20:35:08 RP__: the current sed is ok isnt it ? Aug 02 20:35:13 RP__: ok, have another question about the idea of ppc64 (non-multilib) using /lib64, concerns, comments? Aug 02 20:35:36 galak: there are recipes that don't respect $libdir Aug 02 20:35:53 galak: We need to get to the point where it works everywhere, some work may remain with that Aug 02 20:36:08 * RP__ believes minimal and sato images are clean now, lsb/sdk may not be Aug 02 20:36:58 I'm willing to look at it as long as the general direction of utilizing /lib64 for ppc64 is acceptable Aug 02 20:37:40 khem: any thoughts on: Aug 02 20:37:41 /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference Aug 02 20:38:20 woglinde, khem: thank you very much Aug 02 20:39:58 galak: is that runtime ? Aug 02 20:40:04 yes Aug 02 20:40:07 on boot Aug 02 20:40:46 it seems the libc on target is not same that it was linked to Aug 02 20:43:27 galak: you mean by default or for multilibs? Aug 02 20:43:37 galak: regardless, we need to make it work :) Aug 02 20:44:06 RP__: by default Aug 02 20:44:07 RP__: by default even for non mulitlib case Aug 02 20:44:25 right now we always force lib for non multlib case Aug 02 20:44:32 khem: I realise that Aug 02 20:44:34 ppc64 being kind of new to the mix Aug 02 20:44:57 RP__: how do we solve the x86/x86_64 case Aug 02 20:45:06 since both of them use lib Aug 02 20:45:06 khem: solve in what way? Aug 02 20:45:15 with multilib Aug 02 20:45:41 khem: well, with multilib enabled one of the libs can use lib64 or lib32 Aug 02 20:45:51 and we are likely to change the default for x86_64 too Aug 02 20:46:02 on x86_64 multilib case 64bit resides in lib64 and 32bit in lib Aug 02 20:46:24 khem: You should be able to pick your location and have the system respect libdir IMO Aug 02 20:46:36 RP__: so I think we should make non mulitlib case for x86_64 also use lib64 may be ? Aug 02 20:46:43 khem: likely yes Aug 02 20:47:01 that will break compatibility with what we have though Aug 02 20:47:06 for x86_64 Aug 02 20:47:12 khem: sad, but true Aug 02 20:47:13 I hope thats not a issue Aug 02 20:47:16 ok Aug 02 20:47:29 I don't think its an issue for yocto Aug 02 20:47:41 so the gcc change you committed other day needs root file systems to be fixed Aug 02 20:47:46 for x86_64 Aug 02 20:47:58 khem: well, I think the sed expression is wrong Aug 02 20:48:01 atleast for non multilib case Aug 02 20:48:08 it should honour libdir Aug 02 20:48:09 hmmm Aug 02 20:49:57 RP__: actually for multilib case GLIBC_DYNAMIC_LINKER32 and GLIBC_DYNAMIC_LINKER64 will have different libdirs Aug 02 20:50:17 so that needs to be considered as well Aug 02 20:50:20 khem: It doesn't matter, it just needs to match the one that is currently buiilding Aug 02 20:50:51 thats true though since we dont use same gcc Aug 02 20:50:57 for 32 and 64 bit Aug 02 20:51:25 right, we currently don't rely on any compiler/libc support for the multilib pieces Aug 02 20:51:47 so ( *"/lib.*\) part should substitute libdir I suppose Aug 02 20:52:10 yes Aug 02 20:52:29 so commit message is correct for that patch Aug 02 20:52:46 earlier I was confused with what patch did and what the commit message said Aug 02 20:52:52 patch kind of was doing ok Aug 02 20:52:58 :) Aug 02 20:58:43 here's my version of what the sed line should be to match the commit msg: Aug 02 20:58:44 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\) \( *"/lib.*\)/\(.*\)#\1 SYSTEMLIBS_DIR"/\3#' Aug 02 21:07:57 galak: yes thats about right Aug 02 21:08:12 galak: and then you will need to get rid of that dirname Aug 02 21:08:27 yep Aug 02 21:08:33 SYSTEMLIBS_DIR = ${SYSTEMLIBS} Aug 02 21:08:45 well we can get rid of SYSTEMLIBS_DIR completely Aug 02 21:09:11 galak: would you cook up a patch and send ? Aug 02 21:10:23 we still have to make sure that there is no trailing / in SYSTEMLIBS_DIR Aug 02 21:10:29 as define Aug 02 21:10:50 e.g. SYSTEMLIBS_DIR = /lib/ Aug 02 21:11:08 would yield /lib//ld-linux.so.2 Aug 02 21:17:00 patch sent, take a look and comment Aug 02 21:19:24 galak: actually sed -e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\) \( *"/lib.*\)/\(.*\)#\1 SYSTEMLIBS_DIR" \3#' Aug 02 21:19:27 would be better Aug 02 21:19:33 since you dont append / Aug 02 21:19:40 and expect it from SYSTEMLIBS_DIR Aug 02 21:19:43 which we already do Aug 02 21:20:06 #define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR" ld-linux.so.2" Aug 02 21:20:11 thats what it will look like Aug 02 21:20:35 sed -e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\) \( *"/lib.*\)/\(.*\)#\1 SYSTEMLIBS_DIR "\3#' Aug 02 21:20:38 actually Aug 02 21:20:44 #define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR "ld-linux.so.2" Aug 02 21:25:11 khem: looks, good will send a new version Aug 02 21:28:48 galak: ok I will take that new version and give it a whirl with x86_64 Aug 02 21:28:58 since thats broken for me and this should fix it Aug 02 21:31:29 khem: do you want to get rid of the #define SYSTEMLIBS_DIR completely? Aug 02 21:33:05 galak: if it does not have any advantage then I would prefer that we reuse SYSTEMLIBS Aug 02 21:33:13 but no preference Aug 02 21:33:31 since SYSTEMLIBS_DIR seems more explanatory Aug 02 21:33:58 oh, I see Aug 02 21:35:56 wait, I'm confused Aug 02 21:37:27 galak: SYSTEMLIBS_DIR gets transferred into a default.h header file which is used during compilation Aug 02 21:38:10 so you have to remove it from sed expr as well as in other places Aug 02 21:38:57 no, we still want the result of the sed expr to look like: Aug 02 21:38:57 #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "ld-linux-x86-64.so.2" Aug 02 21:45:32 https://gist.github.com/a1dceb578a6e73fc7153 - Any idea why gstreamer is refusing to build? Aug 02 21:46:35 galak: yes Aug 02 21:46:54 but it could be #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS "ld-linux-x86-64.so.2" Aug 02 21:48:25 Circuitsoft: configure: No package 'glib-2.0' found Aug 02 21:48:35 I see that. Aug 02 21:48:46 Do you need something more telling Aug 02 21:48:49 If you go to the config.log, pkgconfig can't find glib-2.0.pc. It is however, there. Aug 02 21:50:03 https://gist.github.com/a1dceb578a6e73fc7153#L2659 Aug 02 21:50:40 How do I find and/or set PKG_CONFIG_PATH? Aug 02 21:52:34 Circuitsoft: bitbake -e /tmp/xx Aug 02 21:52:40 then look in /tmp/xx Aug 02 21:52:50 for variable you are interested Aug 02 21:55:19 I guess the next question is why PKG_CONFIG_PATH isn't set automatically to point to my sysroot. Aug 02 21:58:03 So, it is being set properly, yet pkgconfig can't find glib-2.0.pc Aug 02 22:02:44 khem: Any ideas? Aug 02 22:04:12 alex@msp-vln-app03 ~/overo-oe $ fgrep export\ PKG_CONFIG_PATH env Aug 02 22:04:14 export PKG_CONFIG_PATH="/home/alex/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig:/home/alex/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/pkgconfig:/home/alex/overo-oe/tmp/sysroots/x86_64-linux/usr/lib/pkgconfig:/home/alex/overo-oe/tmp/sysroots/x86_64-linux/usr/share/pkgconfig" Aug 02 22:04:16 alex@msp-vln-app03 ~/overo-oe $ find /home/alex/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/ -name glib-2.0.pc Aug 02 22:04:17 /home/alex/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig/glib-2.0.pc Aug 02 22:59:00 khem: sent new version, I leave it as an exercise of the reviewer to cleanup SYSTEMLIBS ;) Aug 02 23:01:02 galak: I can git am it for some reason Aug 02 23:01:18 galak: is it on top of oe-core/master ? Aug 02 23:02:23 khem: hmm, its on my internal tree, which the PR for gcc might not be clean Aug 02 23:03:31 galak: no worries I will reslove it locally Aug 02 23:04:19 do you plan on making the SYSTEMLIBS changes? Aug 02 23:04:28 galak: yes Aug 02 23:04:38 ok, than I'll NOT post a new version Aug 02 23:04:44 sure Aug 02 23:13:55 galak: I have started a build with your patch applied Aug 02 23:14:05 should have something tomorrow morning Aug 02 23:16:23 khem: ok, when I used my latest version ppc64 (using /lib) works out Aug 02 23:16:32 so I expect x86-64 should be good now Aug 02 23:43:13 is there a way to print deps for a package w/o going through graphviz? Aug 02 23:59:25 does this make any sense? Aug 02 23:59:27 http://pastebin.com/Cfa1VpLe Aug 02 23:59:40 built from the release branch Aug 02 23:59:46 this is disturbingly familiar Aug 03 00:00:56 What's the oe equivalent package to debian's build-essential? Aug 03 02:53:37 when bitbake angstrom-task-gnome in oe-core, the "task-gnome" package gets create, but, I'm not able to opkg install it as opkg says "eglibc >= 2.12" requirement is not met . I check the 'control' file of the ipk but nowhere does it show the dependency on eglibc Aug 03 02:53:57 what is opkg trying to do here? Aug 03 02:54:30 moreover eglibc package doesn't exist, I can find an eglibc-binaries (or similar) **** ENDING LOGGING AT Wed Aug 03 02:59:57 2011