**** BEGIN LOGGING AT Tue Mar 25 02:59:58 2014 Mar 25 06:59:17 otavio, ping Mar 25 07:06:05 I noticed that for a recipe that needs to download patches, these are placed directly under "downloads". Wouldn't there be a slight risk for filename clashes ? Mar 25 07:34:57 when using buildroot, to configure packages, you usually describe the options in a "Config.in" file which is parsed by the package selection system. This allows the user to select not only to include a package or not, but also specifically configure the package. How do you achieve this in openembedded? Do I need to write a .bbappend file for each permutation of package configuration i want to use? Mar 25 07:37:18 mago_, individual package configuration can be done in your distr.conf Mar 25 07:37:28 distro.conf Mar 25 07:38:09 could you provide an example? Mar 25 07:38:26 For qtbase I have 'PACKAGECONFIG_append_pn-qtbase = "accessibility"' Mar 25 07:39:15 there is also PACKAGECONFIG_remove_pn-xxx Mar 25 07:40:38 i'm trying to reconfigure my kernel image format from an zImage to uImage. This is controlled by KERNEL_IMAGETYPE. I tried adding KERNEL_IMAGETYPE = "uImage" to my local.conf, should I instead rely on this PACKAGECONFIG for this? Mar 25 07:40:49 (KERNEL_IMAGETYPE in local.conf did not work by the way) Mar 25 07:42:37 mago_, aah, nah, I'm getting your kernel doesn't use PACKAGECONFIG infrstructure. Which kernel is it ? Mar 25 07:42:43 *betting* Mar 25 07:44:18 mago_, if local.conf didnt work, maybe try setting it in a .bbappend file for your kernel Mar 25 07:49:16 kroon, im using the arago distro from TI. From what I can tell by inspecting the bitbake -g dependency list of my image (arago-console-image), it seems to use 'linux-ti-staging' from the meta-ti layer. I am unsure if this relies on "PACKAGECONFIG infrastructure". If I do however review the bitbake -e output, I can see that my KERNEL_IMAGETYPE assigned in local.conf gets overwritten by meta-ti/conf/machine/include/ti33x.inc:26 .. so I wonder how can Mar 25 07:49:17 I make this re-configuration without editing that specific .inc file? Mar 25 08:11:18 mago_, try using a .bbappend file for the kernel Mar 25 08:36:04 kroon, if my kernel recipe is called linux-ti-staging, should there not be a linux-ti-staging.bb somewhere, and my appendfile would be linux-ti-staging.bbappend? if a recipe PROVIDES linux-ti-staging but is named differently, how can I find it? and what should I call my appendfile? the PROVIDES name, or the original recipe filename.bbappend? Mar 25 08:56:21 mago Mar 25 09:04:41 mago_, I'm just guessing but try "cd meta-ti && find | grep linux-ti-staging" Mar 25 09:05:03 mago_, kernel recipe might be something like linux-ti-staging_x.y.z.bb Mar 25 09:05:30 mago_, name your .bbappend file linux-ti-staging_x.y.z.bbappend, or linux-ti-staging_%.bbappend Mar 25 09:08:44 ah, i see. From my dependency list, I can tell it is linux-ti-staging_3.12.bb which is in use. Out of curiosity, how does one select version of a recipe to use? Mar 25 09:14:28 good morning Mar 25 09:29:21 mago_, PREFERRED_VERSION_linux-ti-staging = "x.y.z" Mar 25 09:38:32 kroon, okay, so with a .bbappend file I was able to reconfigure the kernel recipe to output an uImage instead. This brings me back to my original question on how to re-configure packages (like buildroot does with menuconfig). It seems like a bit more work to do it with OE since you sometimes need to create these .bbappend files. What is this PACKAGECONFIG infrastructure, and is it being adopted by the majority of the community? Mar 25 09:48:47 Trying to go from dylan to dora, and have trouble with gst-plugins-base-glib. log.do_rootfs calls it an Unknown package. Mar 25 10:06:50 aaargh! Mar 25 10:07:02 this bitbake should stop thinking for me sometimes Mar 25 10:07:50 anyone here know how to install an TI kernel module the correct way using bitbake etc? Mar 25 10:08:02 it's turning out to be the biggest mess Mar 25 10:08:15 why is this so difficult Mar 25 10:08:33 the previous guy Mar 25 10:08:37 with previous bitbake Mar 25 10:09:34 Copied some files generated by the kernel build process into the machine sysroots Mar 25 10:10:00 and then built the TI recipy Mar 25 10:10:03 no problems Mar 25 10:10:05 the new bitbake Mar 25 10:10:10 does not like this Mar 25 10:10:21 it sees that the files copied to sysroots are not ARM compatible Mar 25 10:10:25 then I get this error Mar 25 10:10:44 package/usr/src/kernel/scripts/mod/modpost: File format not recognized Mar 25 10:10:56 during the do_package stage Mar 25 10:11:00 more spesifically Mar 25 10:11:14 ERROR: Function failed: split_and_strip_files Mar 25 10:15:01 so how do you compile ti-syslink? Mar 25 10:15:10 it requires genksyms Mar 25 10:15:25 pompomJuice, is this from the meta-ti layer? Mar 25 10:15:36 its an onder syslink driver Mar 25 10:15:44 we copied the recipy Mar 25 10:15:51 or it looks copied Mar 25 10:16:13 we cannot upgrade to newer versions of syslink Mar 25 10:16:21 syslink is not backwards compat Mar 25 10:16:40 looks copied from meta-ti yes Mar 25 10:17:50 ti-syslink wont build Mar 25 10:17:56 it requires Mar 25 10:18:11 # Backup these files because we need if for ti-syslink Mar 25 10:18:11 cp $kerneldir/scripts/genksyms/genksyms ${WORKDIR}/genksyms Mar 25 10:18:11 cp $kerneldir/scripts/basic/fixdep ${WORKDIR}/fixdep Mar 25 10:18:11 cp $kerneldir/scripts/mod/modpost ${WORKDIR}/modpost Mar 25 10:18:17 so wtf Mar 25 10:18:40 how can it require something that only exists for a short time during the kernel tree build Mar 25 10:18:43 does not make any sense Mar 25 10:20:43 that backup part has been hacked into kernel.bbclass in the do_install section just before it does a make clean Mar 25 10:20:51 the problem is you cannot copy it back Mar 25 10:20:57 because bitbake is to clever Mar 25 10:21:25 it realizes those things do not run on arm Mar 25 10:21:33 hence QA errors Mar 25 10:21:34 it does not sound like a longterm solution either, to manually copy stuff into your sysroot? Mar 25 10:21:44 yea! Mar 25 10:21:46 only Mar 25 10:21:57 you could copy stuff into sysroots in denzil days Mar 25 10:21:59 not anymore Mar 25 10:22:16 do_package checks the binaries for machine compatability Mar 25 10:22:24 and absolutely refuses to put thse files in Mar 25 10:22:29 even if the human tells it otherwise Mar 25 10:22:32 it knows better and refuses Mar 25 10:22:54 now I am dead in the water Mar 25 10:23:39 there is one part in kernel.bbclass Mar 25 10:23:53 im not bitbake (or OE expert), but certainly there must be a way to deploy files which are not executables (and of the same architecture as target) Mar 25 10:23:54 inside the install part Mar 25 10:23:56 that says Mar 25 10:23:57 # Remove the following binaries which cause strip or arch QA errors Mar 25 10:23:57 # during do_package for cross-compiled platforms Mar 25 10:24:04 the thing is Mar 25 10:24:05 I dont want to remove them Mar 25 10:24:21 I want them included because I am the human and I know better. Why is the computer telling me no Mar 25 10:24:28 I said do it Mar 25 10:24:42 if you want to change the behavior of kernel.bbclass, can't you override that particular function? Mar 25 10:24:44 so fucking frustrating Mar 25 10:25:10 the function that I need to change is the split_and_strip_files Mar 25 10:26:36 is it not possible to override that using a .bbappend file? Mar 25 10:26:44 I don't know how Mar 25 10:26:57 don't understand bbappend Mar 25 10:27:04 cannot find any documentation on it Mar 25 10:27:12 I am newby Mar 25 10:27:37 try this: http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#using-bbappend-files Mar 25 10:28:24 aah thanks Mar 25 10:29:04 but that code is probably in a class Mar 25 10:29:09 do you get a .classappend"? Mar 25 10:29:18 I mean Mar 25 10:29:23 .bbclassappend Mar 25 10:33:41 well, .bb files inherit stuff from classes. So I assume that you can apply a .bbappend to the recipe (which holds the functions you need). You should probably not make changes to the class itself, as it may be inherited by others aswell Mar 25 10:33:53 exactly! Mar 25 10:34:02 its a nightmare Mar 25 10:34:06 anyway Mar 25 10:34:08 I ahve to go now Mar 25 10:34:10 thanks for your help Mar 25 10:34:11 it has helped Mar 25 11:25:52 offtopic but sign this https://secure.avaaz.org/en/petition/computers_snowden_choose_before_paying/ Mar 25 11:32:35 anyone know how to suppress stripping in the kernel build process for certain files? Mar 25 11:32:59 ERROR: objcopy failed with exit code 256 (cmd was 'arm-angstrom-linux-gnueabi-objcopy' Mar 25 11:36:43 # Mar 25 11:36:44 # Clean and remove files not needed for building modules. Mar 25 11:36:44 # Some distributions go through a lot more trouble to strip out Mar 25 11:36:44 # unecessary headers, for now, we just prune the obvious bits. Mar 25 11:36:44 # Mar 25 11:36:44 # We don't want to leave host-arch binaries in /sysroots, so Mar 25 11:36:45 # we clean the scripts dir while leaving the generated config Mar 25 11:36:45 # and include files. Mar 25 11:36:46 # Mar 25 11:36:52 that is inside the kernel.bbclass Mar 25 11:37:02 "We don not want..." Mar 25 11:37:05 I do want... Mar 25 11:43:15 wait Mar 25 11:43:26 I figured it out Mar 25 11:43:40 backup the files using a do_install_prepend Mar 25 11:43:50 restore the files doing a do_install_append Mar 25 11:44:15 delete the files again by adding a task between do_populate_sysroot & do_package Mar 25 11:44:17 poof Mar 25 15:39:16 if a layer provides multiple kernels (both multiple versions, and multiple variants), how can I set which one to use when building my image? For example, Arago provides two versions of linux-ti-staging, but also a linux-ti33x-psp. The arago-console-image target currently builds linux-ti-staging (preferred version 3.10), how can I change this so that it instead uses linux-ti33x-psp to provide kernel? Mar 25 15:39:44 use PREFERRED_VERSION_ = "" Mar 25 15:40:03 that goes in a .conf file of some kind.. BSP, local.conf, etc.. Mar 25 15:40:22 fray, yes, if I were to change the version of linux-ti-staging i guess that would suffice. But I want to not use package A, and instead use B in its place Mar 25 15:40:38 they both "provide" virtual/kernel Mar 25 15:41:03 my oe fails to build pseudo-native: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc Mar 25 15:41:28 so I'm kind of stuck, any idea how to solve this? is there an env variable to tell it to use 4.7 or 4.6 Mar 25 15:41:43 what gcc versiopn does it like anyways Mar 25 15:41:44 that message comes from the system linker.. Mar 25 15:41:54 your system linker or gcc need to be fixed.. Mar 25 15:42:15 linker seems to work okay outside of oe Mar 25 15:42:23 mago_ then you also need a PREFERRED_PROVIDER_virtual/kernel = "" Mar 25 15:42:25 unless I'm missing something here Mar 25 15:42:41 my guess is that you don't have the libgcc.a for the ABI you are trying to compile for.. Mar 25 15:42:44 fray, ah, I see. Thank you! Mar 25 15:42:55 pseudo needs to build for both 32-bit and 64-bit (in many cases).. Mar 25 15:43:03 so you need the libgcc.a that matches your compiler for both installed Mar 25 15:43:04 target is arm Mar 25 15:43:16 this is pseudo-native, so the target is not involved Mar 25 15:43:21 but pseudo native is for running on the build system itself, right? Mar 25 15:43:31 pseudo wraps system binaries to emulate a 'root-like' environment.. Mar 25 15:43:47 if it detects you have 32-bit binaries on your system (or could) it will try to build a 32-bit version fo itself.. Mar 25 15:43:59 I'm guessing this is what is failing because your libgcc.a is missing for the 32-bit side Mar 25 15:44:18 why is 32bit involved at all Mar 25 15:44:45 because something on your system told it you either have 32-bit (host) binaries, or you have the ability to generate them.. Mar 25 15:44:58 pseudo can only wraper the binaries of the same bitsize as it was compiled for.. Mar 25 15:45:08 so you need a 32-bit pseudo for 32-bit binaries, and a 64-bit pseudo for 64-bit binaries.. Mar 25 15:45:22 the autodetection looks for specific headers to see if you have the 32-bit headers Mar 25 15:45:44 /usr/bin/gcc: ELF 64-bit LSB executable, x86-64 Mar 25 15:46:03 hmm Mar 25 15:46:13 moin Mar 25 15:46:14 it's not wrapping gcc.. Mar 25 15:46:18 it's using gcc to build itself Mar 25 15:46:27 right Mar 25 15:46:29 when you build something with gcc, it has to link the corresponding 'libgcc.a' Mar 25 15:46:47 the message from 'ld' says you don't have the corresponding libgcc for what you are compiling.. Mar 25 15:46:59 this usually indicates that you are trying to use a 64-bit version to link a 32-bit binary (or the reverse) Mar 25 15:47:04 * Daemon404 awaits the day clang removes this mess Mar 25 15:47:09 but doesn't it look like I have a 64bit gcc, still it doesn't like /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a Mar 25 15:47:12 clang won't do anything about this.. Mar 25 15:47:14 it's the same issue Mar 25 15:47:25 clang doesnt have a replacemrnt for libgcc fullstop Mar 25 15:47:36 it's building either a 32-bit pseudo and the linker is trying to link a 64-bit libgcc which will never work Mar 25 15:47:38 or the reverse Mar 25 15:47:45 hrm Mar 25 15:47:59 just make sure you have the c library and libgcc for both 32 and 64 bit installed, and you'll be fine Mar 25 15:48:05 your host system either has 32-bit binaries that it detected, or it has support for building 32-bit binaries.. Mar 25 15:48:05 sorry, i didnt really mean solve *that* particular mess Mar 25 15:48:17 either one will trigger it to attempt to build a 32-bit pseudo.. Mar 25 15:48:49 i just meant that the canadian cross will in general be obsolete. Mar 25 15:48:51 primary key is /usr/include/gnu/stubs-32.h BTW Mar 25 15:49:17 you'll still have to create a compiler backend to target the 'target system' Mar 25 15:49:32 and you'll also still need to generate a 'clang' binary that runs in the environment you expect it to run in.. Mar 25 15:49:39 canadian-cross and cross compilers don't go away in clang Mar 25 15:50:07 they kind of do -- there's not one specific target Mar 25 15:50:13 it's all targets at once Mar 25 15:50:17 clang -> intermediate -> backend.. Mar 25 15:50:39 fray, do you know what might be wrong if Bitbake says "selecting linux-ti-staging to satisfy virtual/kernel due to PREFERRED_PROVIDERS", even though I have this in my local.conf: PREFERRED_PROVIDER_virtual/kernel = "linux-ti33x-psp" Mar 25 15:50:40 the backend is the cross compiler.. plus you need the clang to know the right set of inbuilt defines for the target you are well, targeting Mar 25 15:50:55 the clang binary itself will need to be compiled for the system you intend to run it on.. native, nativesdk or target.. Mar 25 15:50:58 so the candian cross is still there Mar 25 15:51:18 add an 's' to PREFERRED_PROVIDER ;) Mar 25 15:51:23 I dunno.. Mar 25 15:51:39 hiopefully just a simple typo.. but the preferred_provider is the key for selecting.. Mar 25 15:51:52 the other option you have is to include the blacklist class.. and blacklist the one you DO NOT want.. Mar 25 15:51:59 my point was it lacks the limitation of one target per build, since it can always build with all targets, so it's not *really* canadian cross in my mind Mar 25 15:51:59 USER_CLASSES += "blacklist" Mar 25 15:52:11 PNBLACKLIST[linux-ti-staging] = "Go away" Mar 25 15:52:23 i get what you mean, but it's much more simplified than what gcc does to me Mar 25 15:52:26 build-wise Mar 25 15:52:38 I find the blacklist useful in that it will trigger the system to tell you WHY it keeps bringing it in.. since the dep will fail Mar 25 15:53:04 Daemon404 -- it's just "different".. but in the end it's the same.. where clang is better is the overall pluggable architecture.. Mar 25 15:53:20 but building clang is still as complex as building any other set of compilers, libc, linkers, etc.. Mar 25 15:53:28 i specifically mean teh compiler Mar 25 15:53:35 not teh infastrcture like libc/c++ Mar 25 15:54:11 and it's certainly 'simpler' to me to have one toolchain targeting everything Mar 25 15:54:19 and softlinks with prefixes Mar 25 15:55:10 clang (via it's intermediates and other components) still has to know the system definitions (default #defines) and other header components for a specific 'target'. The intermediate format doesn't insulate that Mar 25 15:55:29 of course Mar 25 15:55:30 but the intermediate format allows more transformations of the data once the initial parsing/compiling has occured.. which is a big win.. Mar 25 15:55:32 fray, it seems like there are preferred providers such as this: PREFERRED_PROVIDER_virtual/kernel_MACHINE = "linux-ti-staging" .. I assume these are providers of a specific target, for a specific machine. Perhaps they override the more generic PREFERRED_PROVIDER_virtual/kernel = .. assignment? Mar 25 15:55:46 I really don't expect it to be any easier for the system builder.. it's going to be better though Mar 25 15:56:03 mago_ then you'll want ot override it.. Mar 25 15:56:11 or like I said, just blacklist it and kick it out of there.. Mar 25 15:56:13 it's been easier for me thus far to build and work with cross-dev chains w/ clang Mar 25 15:56:21 but that's a personal anecdote Mar 25 16:01:20 fray, i see. the more specific PREFERRED_PROVIDER seem to override the more generic one: http://pastebin.com/yN1fDRY5 .. even if I make my local.conf PREFERRED_PROVIDER equally specific, it still uses linux-ti-staging. Perhaps a distro preferrence cannot be overridden, and must be blacklisted as you say? Mar 25 16:03:48 it has to do with load order and the mystical "override" mechanisms.. Mar 25 16:03:56 you can use bitbake -e and look at the order of the processing Mar 25 16:04:09 ahh yes.. whats in the pastebin Mar 25 16:04:23 partial output from bitbake -e :) Mar 25 16:04:49 it's the arago-prefs.in that is the 'issue'.. Mar 25 16:04:59 you may just have to 'force' the value.. Mar 25 16:05:08 * fray finds the example Mar 25 16:05:50 PREFERRED_PROVIDERS_virtual_kernel_forcevariable = "" Mar 25 16:05:51 still, there has to be a way to override distro settings ? or does that qualify as a new distro, i.e. i should fork the distro and just modify it directly Mar 25 16:05:58 oh, okay, ill try that Mar 25 16:06:03 you really should fork the distro for this.. Mar 25 16:06:12 what you can do is create your own with thef irst line being: Mar 25 16:06:16 require Mar 25 16:06:16 fray: it's virtual/kernel, isn't it? Mar 25 16:06:31 PREFERRED_PROVIDER_virtual/kernel_ = "your value" Mar 25 16:06:34 what kicer.. Mar 25 16:06:36 denix yes Mar 25 16:06:40 kicer -> nicer Mar 25 16:06:41 hence PREFERRED_VERSION_virtual/kernel_forcevariable Mar 25 16:07:07 forcevariable is the last thing evaluated.. so it'll work for testing.. but isn't really meant to be in use for a production environment.. Mar 25 16:07:13 the distro include/fork is the best way Mar 25 16:07:45 yeah, testing is fine. I'm just trying to get something that will boot on my board Mar 25 16:07:45 but distro has all the rights to set preferences Mar 25 16:07:57 so, please don't say it is the issue Mar 25 16:08:30 denix, yes, I agree. I'm not blaming anyone, i'm just looking for a quick fix to get things booting Mar 25 16:11:08 denix, this is part of my attempts to get Arago running on my custom AM3352 board. After I let U-boot run the uImage, nothing happens. I am unsure if it is because the serial output is broken, or if there is a more serious kernel issue when used on my board. I do have a buildroot tree based on the old TI kernel 3.2 which works, and I figured since arago uses 3.12, It might provide clues on what is wrong if I revert back to 3.2 in arago aswell Mar 25 16:12:10 fray: /lib/x86_64-linux-gnu/libgcc_s.so.1: ELF 64-bit LSB shared object, x86-64 Mar 25 16:12:27 hm nevermind Mar 25 16:12:52 hm actually Mar 25 16:13:07 could it be possible that it somehow picks up 32bit gcc from somewhere? Mar 25 16:13:16 fray, forcevariable worked! thanks Mar 25 16:13:19 heen you can tell the system to ignore teh automatic identification.. Mar 25 16:13:23 in your lcoal.conf Mar 25 16:13:28 NO32LIBS = '1' Mar 25 16:13:38 how can I check what it thinks it detected Mar 25 16:13:42 but if you do have any 32-bit host binaries.. you'll get indeterminant results.. Mar 25 16:13:51 look at /usr/include/gnu/stubs-32.h Mar 25 16:13:51 Build Configuration: Mar 25 16:13:52 BB_VERSION = "1.18.0" Mar 25 16:13:54 BUILD_SYS = "x86_64-linux" Mar 25 16:14:08 most likely that file exists which is triggering the behavior Mar 25 16:14:19 yeah, it exists Mar 25 16:14:23 where does it come from Mar 25 16:14:35 that file existing normally indicate syou have at least partial 32-bit compiler support enabled.. Mar 25 16:14:45 thus pseudo tries to use it.. and it fails.. since it's not all installed.. Mar 25 16:14:51 thats up to your distribution.. Mar 25 16:15:00 either its a bug in the distro, or you installed some of the 32-bit support Mar 25 16:15:01 I think I need ia32 libs for some stupid java VPN crap Mar 25 16:15:11 thats probably where it came from then.. Mar 25 16:15:29 either install the 32-bit devel libraries (for gcc and glibc) or just use the NO32LIBS = '1' Mar 25 16:16:13 this hasn't been a problem before, though Mar 25 16:16:57 something in your config changes then Mar 25 16:17:00 'er.. changed Mar 25 16:17:04 how can I even clean pseudo-native Mar 25 16:17:33 bitbake -c cleansstate pseudo-native Mar 25 16:17:59 it always tries to build it even when I want to cleanall it Mar 25 16:18:12 ahh.. thats cause pseudo is a base package.. Mar 25 16:18:28 set the NO32LIBS = '1' in your local.conf and it'll stop Mar 25 16:18:54 I did and I opened a different can of worms Mar 25 16:19:11 you are going to need to dump your 'tmp' dir then.. (don't have to wipe anything else) Mar 25 16:19:20 ERROR: Execution of event handler 'errorreport_handler' failed Mar 25 16:19:34 Don't know what that is.. Mar 25 16:20:42 | Attempting to build 32-bit libpseudo.so for pseudo-native. Mar 25 16:20:47 ffff Mar 25 16:21:56 I just checked and oe-core master still has the NO32LIBS = '1' setting.. Mar 25 16:22:32 yeah, local.conf has it to uncomment and set to 0 if you need it Mar 25 16:22:34 http://pastebin.com/A7NczxS1 Mar 25 16:22:38 doesn't stop it from trying 32bit Mar 25 16:22:46 are you using master? Mar 25 16:25:56 not sure Mar 25 16:26:08 how did you download OE? Mar 25 16:26:24 company provided script Mar 25 16:27:12 meta-oe is dylan Mar 25 16:27:30 meta-oe shouldn't be an issue with this.. but if it's dylan... then the core oe-core should be dylan as well.. Mar 25 16:27:44 if your bitbake/oe-core don't match that could be part of the problem Mar 25 16:28:00 oe-core is dylan as well Mar 25 16:34:27 my stop-gap solution is apparently a 64-bit gentoo chroot shell running an x86 debian wheezy install Mar 25 16:35:26 * kergoth chuckles Mar 25 16:38:15 the default pseudo build doesn't like gentoo x86_64 multilib Mar 25 16:39:09 I've never tried it there.. what happens? Mar 25 16:39:33 pseudo-native fails weirdly Mar 25 16:40:19 if a bug doesn't exist in the YP bugzilla.. please enter one.. I'd like to see what the failure is.. Mar 25 16:40:31 i'd need to poke around and find a log somewhere Mar 25 16:40:42 the only 'regular' pseudo failure I'm used to is on systems where grsec (and sometimes selinux) are enabled.. they prevent pseudo from preloading and wrapping other binaries.. Mar 25 16:40:49 those security mechanisms just need to be disabled Mar 25 16:41:11 this wasn't on anything hardened Mar 25 16:41:25 just a normal amd64 profile Mar 25 16:41:45 no problem with gentoo x86_64 here Mar 25 16:43:18 had to play with NO32LIBS and set it to '0' I believe Mar 25 16:43:52 ya.. that's what I would expect assuming there are no 32-bit binaries on the system to be wrapped Mar 25 16:44:04 (assuming the autodetection doesn't work) Mar 25 16:44:49 denix: not a multilib [rofile? Mar 25 16:46:07 looks like multilib is now the default if you don't select one of the no-multilib profiles Mar 25 16:48:02 nerdboy: multilib with emul-linux-x86 Mar 25 16:59:52 i'll try again after i update Mar 25 17:00:28 gotta remove some old ruby cruft... Mar 25 17:59:22 kroon: pong Mar 25 18:00:13 otavio, its ok, i was just wondering about the "make savedefconfig" thingie. nice trick! Mar 25 20:22:54 How do I check if bitbake sees my bbappend? Mar 25 20:26:57 Crofton: bitbake-layers show-appends? Mar 25 20:30:50 how clever Mar 25 20:31:01 I may have just been an idiot though :) **** ENDING LOGGING AT Wed Mar 26 02:59:59 2014