**** BEGIN LOGGING AT Thu Oct 06 02:59:56 2011
Oct 06 06:16:55 <Noor> hi
Oct 06 06:17:32 <Noor> in oe classic MACHINE_OVERRIDES varaible is used and in oe-core MACHINEOVERRIDE variable is used 
Oct 06 06:18:07 <Noor> I think in oe-core MACHINEOVERRIDE has replaced MACHINE_OVERRIDE or these are two different variables
Oct 06 06:19:11 <Noor> ?
Oct 06 06:32:50 <JaMa> bitbake.conf: OVERRIDES = "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
Oct 06 06:33:22 <JaMa> so it's the same
Oct 06 06:42:58 <Noor> JaMa: thanks .... Thats what I expected
Oct 06 06:47:56 <tasslehoff> I've compiled my first toolchain in OE-core, and something is wrong with it: http://pastebin.com/FcyjmwN7
Oct 06 06:52:08 <tasslehoff> gcc seems to be a file of the right type, have proper permissions and size, but I get an error message when I invoke it.
Oct 06 07:00:08 <tasslehoff> must be something wrong with the executable itself?
Oct 06 07:08:00 <mckoan> good morning
Oct 06 07:15:51 <tasslehoff> http://pastebin.com/2UMxCje3
Oct 06 07:15:58 <tasslehoff> (morning)
Oct 06 07:22:25 <tasslehoff> hm. I should have had some symlinks somewhere I think
Oct 06 07:56:34 <tasslehoff> Any ideas what could be missing if I don't have the symlinks to the arm-angstrom-linux-gnueabi- binaries?
Oct 06 08:48:05 <lautriv> fyi, i had this problem -->dbus-daemon-launch-helper: local symbol `_dl_argv@@GLIBC_PRIVATE' in /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 is referenced by DSO .................there was a bug in binutils-2.21.53 and is now solved by binutils-2.21.90 :-)
Oct 06 09:18:35 <florian> good morning
Oct 06 11:32:31 <Crofton|work> gm
Oct 06 11:33:42 <JaMa> gm
Oct 06 11:43:09 <lautriv> while building a test (console-image for hx4700) i got this --> http://pastebin.com/5LcQvQgp warnings ?
Oct 06 11:45:22 <JaMa> lautriv: those should be part of FILES_${PN}-dbg, please send patch addind those files to it
Oct 06 11:47:00 <lautriv> JaMa, Running task 1960 of 4073 .......... will see what i can do afterwards :-)
Oct 06 12:53:33 <jkridner> If I want the oe-core equivalent of util-linux-ng-fdisk, should I just move that recipe over from classic?
Oct 06 12:55:58 <JaMa> jkridner: util-linux-fdisk
Oct 06 12:57:07 <jkridner> ah, it is in core, not meta-oe.
Oct 06 12:57:17 <jkridner> JaMa: Thanks!
Oct 06 13:07:45 <lautriv> i'm trying to build a simple "test" image and do anything like the howto explains it but get tons of errors anywhere, is there something i should read too ?
Oct 06 13:09:46 <GNUtoo|laptop> depend on the errors
Oct 06 13:09:55 <GNUtoo|laptop> *it depends
Oct 06 13:11:42 <lautriv> GNUtoo|laptop, one of tons of the same kind is this -> *** WARNING: renaming "_struct" since importing it failed: build/lib.linux-x86_64-2.6/_struct.so: wrong ELF class: ELFCLASS32  where it looks like an attempt to move some parts from my hostmachine (x86_64) to the target (armv5te)
Oct 06 13:12:41 <GNUtoo|laptop> hmmm no idea, I think you encountred a bug
Oct 06 13:15:38 <GNUtoo|laptop> JaMa, thanks a lot
Oct 06 13:16:06 <lautriv> GNUtoo|laptop, it's a strange thing since i begun, selected target hx4700 (because same CPU like the real target later) and called bitbake console-image ........... even then it starts to compile 4073 recipes ?? readable compileroptions are correct armv5te/mtune=xscale ...
Oct 06 13:17:00 <GNUtoo|laptop> yes it's normal
Oct 06 13:17:05 <GNUtoo|laptop> and it's tasks not recipes
Oct 06 13:17:11 <GNUtoo|laptop> a recipe has many tasks
Oct 06 13:17:16 <GNUtoo|laptop> like do_configure
Oct 06 13:17:20 <GNUtoo|laptop> do_compile
Oct 06 13:17:21 <GNUtoo|laptop> etc...
Oct 06 13:18:22 <lautriv> ok, but my test-target is stable since ages ( running angstrom on hx4700 since ages ) and i don't change anything.
Oct 06 13:18:54 <GNUtoo|laptop> I means 4073 tasks is normal
Oct 06 13:18:58 <GNUtoo|laptop> *meant
Oct 06 13:19:29 <lautriv> GNUtoo|laptop, got that, i wonder why it fails at all because it did always.
Oct 06 13:20:48 <GNUtoo|laptop> do you use oe-core or old oe?
Oct 06 13:21:06 * lautriv remembers there was a checksum-failure for binutils..............maybe hacked P:
Oct 06 13:21:40 <lautriv> GNUtoo|laptop, no idea, i use the suggestions from oe-wiki with git so i guess core
Oct 06 13:22:10 <GNUtoo|laptop> first we need more infos
Oct 06 13:22:19 <GNUtoo|laptop> more context about the error
Oct 06 13:23:04 <lautriv> GNUtoo|laptop, ok, firt thing that happend was a checksum-err on binutils (asked here yesterday) i tuned the keys to the expected value
Oct 06 13:23:19 <GNUtoo|laptop> ok
Oct 06 13:23:38 <GNUtoo|laptop> look if someone has the same error message than you
Oct 06 13:24:40 <lautriv> then, i had a problem with some linking (referenced by DSO) this WAS a bug on the binutils-2.21.53 on the host-system, a change to binutils-2.21.90 solved it.
Oct 06 13:25:07 <lautriv> maybe i should check if something changed but unlikely in one day.
Oct 06 13:27:47 <lautriv> Cannot pull with rebase: You have unstaged changes. :-((
Oct 06 13:37:52 <GNUtoo|laptop> then commit your changes
Oct 06 13:37:56 <GNUtoo|laptop> and then 
Oct 06 13:37:59 <GNUtoo|laptop> git fetch origin
Oct 06 13:38:05 <GNUtoo|laptop> git checkout origin/master
Oct 06 13:38:11 <GNUtoo|laptop> -b yourbranch
Oct 06 13:38:15 <GNUtoo|laptop> and then
Oct 06 13:38:31 <GNUtoo|laptop> git cherry-pick the_hash_of_your_change
Oct 06 13:40:30 <lautriv> which branch is in the wiki ?
Oct 06 13:52:17 <GNUtoo|laptop> I guess you want the master branch
Oct 06 17:31:19 <lautriv> i need advise/opinions ........ somehow my former attempts failed because something went wrong with binutils, the angstrom distro delivers a prebuild toolchain to avoid this. should i go with the simple or qte-sdk ?
Oct 06 17:41:33 <GNUtoo|laptop> lautriv, whta are you trying to do?
Oct 06 17:42:49 <lautriv> GNUtoo|laptop, deleted/repulled the whole git, i will build a console-image for hx4700 to see the bitbake/source is somewhat usable and then make a new conf for an unknown machine (same CPU).
Oct 06 17:47:13 <lautriv> GNUtoo|laptop, the config has an option for this prebuild toolchian from angstrom, just asking if i may use the 08/15 or better the qte-SDK.
Oct 06 17:47:31 <GNUtoo|laptop> no idea
Oct 06 17:47:42 <GNUtoo|laptop> if you have toolchain issues clean the toolchain
Oct 06 17:47:45 <GNUtoo|laptop> and restart building
Oct 06 17:47:49 <GNUtoo|laptop> bbl
Oct 06 17:50:20 <lautriv> i'll try the regular, actually a minimalistic system is enought to get details :-)
Oct 06 18:59:47 <tasslehoff> I've tried to put together an sdk, based on the qte one, but I (think I) lack symlinks to arm-angstrom-linux-gnueabi-gcc and friends. Any idea what I could be missing?
Oct 06 19:00:55 <khem> there is a gcc-symlinks packages
Oct 06 19:01:03 <khem> did it make into the SDK
Oct 06 19:01:44 <tasslehoff> khem: I suspect it didn't. will have to add that tomorrow.
Oct 06 19:01:57 <tasslehoff> not on my workpc now, this is just research :)
Oct 06 20:51:50 <lautriv> hmmm, installed and enabled the angstrom toolchain and it complains about multiple providers (eglibc) ??
Oct 06 20:52:28 <florian> re
Oct 06 20:55:31 * lautriv waves florian
Oct 06 21:01:50 <Crofton|work> ok guys, please rsvp for the GA :)
Oct 06 21:03:22 <lautriv> Crofton|work, could you rephrase this for human reading ?
Oct 06 21:04:31 <Crofton|work> :)
Oct 06 21:04:42 <khem> lautriv: if you are not OE ev member ignore it
Oct 06 21:04:48 <Crofton|work> We are having the OpenEmbedded eV General Assembly after ELCE in Prague
Oct 06 21:04:55 <Crofton|work> and what khem said :)
Oct 06 21:05:41 <Crofton|work> it is an organizational thing
Oct 06 21:06:02 <Crofton|work> hmm, I suppose I should mention this on the regular list, in case non members would liek to sit in
Oct 06 21:06:43 <Crofton|work> also, is anyone having build failures with binutils in oe-core?
Oct 06 21:06:56 <khem> Crofton|work: what kind
Oct 06 21:06:59 <khem> logs ?
Oct 06 21:07:09 <khem> is it for target or cross
Oct 06 21:07:16 <Crofton|work> give me a chance to pastebin :)
Oct 06 21:07:21 <Crofton|work> I have several fires atm
Oct 06 21:07:36 <khem> I would like kindle one
Oct 06 21:07:40 <lautriv> ok, while some geeks around, is the following change ok ? ( i assume the binutils got patched but not renamed) ...............
Oct 06 21:07:44 <lautriv> ERROR: The checksums for "/usr/src/stuff/sources/binutils-2.20.1.tar.bz2" did not match.
Oct 06 21:07:44 <lautriv>   MD5: expected "9cdfb9d6ec0578c166d3beae5e15c4e5", got "2b9dc8f2b7dbd5ec5992c6e29de0b764"
Oct 06 21:07:44 <lautriv>   SHA256: expected "228b84722d87e88e7fdd36869e590e649ab523a0800a7d53df906498afe6f6f8", got "71d37c96451333c5c0b84b170169fdcb138bbb27397dc06281905d9717c8ed64"
Oct 06 21:08:15 * florian feels sleepy... spent 
Oct 06 21:08:26 <khem> lautriv: 
Oct 06 21:08:33 <florian> two weeks teaching a pxa based device to suspend
Oct 06 21:08:35 <khem> binutils has been updared
Oct 06 21:08:54 <khem> florian: heh its still less than teaching this to a kid
Oct 06 21:08:54 <RP__> florian: I remember that fun :/
Oct 06 21:09:22 * RP__ hands Crofton|work some fire extinguishers 
Oct 06 21:09:27 * khem is muddling with mips/xlp these days
Oct 06 21:10:31 <lautriv> khem, so my assumtion is right and i can change the hashes in .bb ?
Oct 06 21:10:32 <khem> and trying to get hardware walker cope with PTE
Oct 06 21:10:50 <khem> lautriv: if the tars you have are ok 
Oct 06 21:10:58 <khem> lautriv: is it oe.core ?
Oct 06 21:11:26 <lautriv> khem, i guess so, got the sources from actual wiki (git)
Oct 06 21:11:53 <florian> khem: hehe... I'm lucky because my youngest one did this pretty well after one week :)
Oct 06 21:12:24 <khem> hmm you must have done some good deeds in past
Oct 06 21:12:39 <lautriv> florian, how old is your youngest ?
Oct 06 21:13:06 <Crofton|work> btw, I started this http://www.openembedded.org/wiki/Prague,_2012
Oct 06 21:13:37 <florian> RP__: With every new generation of device the fun raises :-/ And I hav an additional problem: German engineers inventing their own bootloaders :-)
Oct 06 21:13:56 <khem> ah why not use redboot
Oct 06 21:14:00 <florian> lautriv: seven months 
Oct 06 21:15:18 <florian> khem: I think its mostly because porting redboot is not really funny and Blob which seems to be shipped with most PXA evalkit is different :)
Oct 06 21:15:34 <florian> Crofton|work: very good
Oct 06 21:15:46 <khem> florian: yeah blob it is
Oct 06 21:15:59 <khem> florian: since redboot worked well with xscales
Oct 06 21:16:44 <florian> khem: indeed... maybe its easier to do if you have to use CE
Oct 06 21:18:25 <khem> yes CE 
Oct 06 21:18:29 <khem> old days
Oct 06 21:18:51 <khem> I heard windows 8 is locking the bootloader UEFI
Oct 06 21:19:00 <khem> so it can not boot non windows OS
Oct 06 21:19:13 <RP__> florian: Its sad people keep doing this...
Oct 06 21:19:24 <fray> AFAIK win 8 requires the option to lock the EFI.. it doesn't mean people have to lock it..
Oct 06 21:19:45 <fray> up to the board vendor.. but if htey want compatibility with older Windows, they have to have a way to run non-locked OSes
Oct 06 21:19:48 <khem> I am sure the PC makers will make the choices
Oct 06 21:20:10 <khem> they will install some weird keys
Oct 06 21:20:29 <khem> and linux has to be signed by those 
Oct 06 21:20:41 <florian> khem: Personally I do not care much... no dual boot required any more. Haven't used it for ages...
Oct 06 21:20:56 <fray> or you simply enable non-signed booting
Oct 06 21:21:10 <khem> florian: yeah it doesnt really matter anymore
Oct 06 21:21:24 <fray> last I heard is you would either enable non-signed booting, or you would add your own keys for your signed kernels..
Oct 06 21:27:07 <zenlinux_laptop> I'm writing a recipe for some software that builds up quite a long CFLAGS variable, but when I use oe_runmake, it clobbers the settings in the project's Makefiles. Is there a canonical way to deal with that?
Oct 06 22:19:00 <kergoth> zenlinux_laptop: the default EXTRA_OEMAKE arranges things so our exported env vars override the variable definitions in the toplevel makefile. that isn't the case for autotools, just regular makefiles. i recommend defining EXTRA_OEMAKE = '"CC=${CC}' 'CFLAGS=${CFLAGS}'" etc, explicitly pass the appropriate variables in to ensure it obeys the needed oe vars
Oct 06 22:19:44 <kergoth> the nice thing about the default value is it "just works" in a large percentage of cases, but it also encourages people to not actually read the makefiles and understand the buildsystem they're dealing with, unfortunately. better to be explicit about it
Oct 06 22:20:00 <kergoth> not sure if that helps you or not, but that's my advice
Oct 06 22:25:49 * kergoth chuckles at http://www.theonion.com/articles/last-american-who-knew-what-the-fuck-he-was-doing,26268/
Oct 06 22:42:00 <zenlinux_laptop> kergoth, thanks for the reply
Oct 06 22:42:08 <kergoth> np
Oct 06 22:55:58 <ka6sox> I need to take the wiki down for about 30minutes to clear up a problem with the server.
Oct 06 22:59:17 <ant__> go
Oct 06 23:00:38 <khem> ka6sox: send an email to ml before and after 
Oct 06 23:14:07 <tking__> khem, before is done
Oct 06 23:14:11 <tking__> after when its back up
Oct 06 23:21:57 <msm> where are RDEPENDS added to sstate-cache?
Oct 06 23:55:11 <kergoth> msm: variable dependencies are tracked. a given task's signature includes both its value and the values of all the variables it references, recursively
Oct 07 00:00:10 <msm> kergoth: the back ground is that task interdepencies are being marked is different
Oct 07 00:00:30 <msm> so for the zypper recipe, when I did a bitbake-diffsig
Oct 07 00:00:38 <msm> Dependency on task virtual:native:/opt/yocto/cache-build/p4080ds/meta/recipes-devtools/rpm/rpm_5.4.0.bb.do_populate_sysroot was added
Oct 07 00:00:59 <msm> Dependency on task virtual:native:/opt/yocto/cache-test/meta/recipes-devtools/rpm/rpm_5.4.0.bb.do_populate_sysroot was removed
Oct 07 00:01:15 <msm> it seems to be flagging differences just based on the new paths?
Oct 07 00:01:23 <kergoth> yeah, it detects the task dependencies across recipe boundaries, since a signature changes if the signatures of its dependencies change
Oct 07 00:01:31 <kergoth> interesting
Oct 07 00:01:36 <msm> but what is causing the change?
Oct 07 00:01:51 <msm> i have some bitbake-diffsig results where there is just one change, the item above
Oct 07 00:02:06 <msm> this is for recipes with RDEPENDS it seems like
Oct 07 00:02:09 <kergoth> see the bitbake signaure generation code
Oct 07 00:02:15 <msm> siggen.py
Oct 07 00:02:18 <msm> been looking =)
Oct 07 00:02:33 <msm> i think its time i learn some python…. *sigh*
Oct 07 00:05:26 <msm> seems like you should strip out the OEDIR 
Oct 07 00:05:46 <msm> or whatever it's called these days
Oct 07 00:07:28 <kergoth> bitbake has zero knowledge of such a thing.
Oct 07 00:10:44 <msm> kergoth: well its somehow saved in the sstate-cache
Oct 07 00:10:52 <msm> since it knows the old path
Oct 07 00:10:54 <msm> and the new one
Oct 07 00:10:56 <msm> time to go though
**** ENDING LOGGING AT Fri Oct 07 02:59:58 2011