**** BEGIN LOGGING AT Mon Sep 05 02:59:57 2011
Sep 05 06:19:25 <sanket_> can anyone help me how to compile firefox in oe ..... i m getting an error when i execute <bitbake firefox>....
Sep 05 06:22:44 <ka6sox> 2:17am on a monday morning....
Sep 05 08:18:51 <florian> good morning
Sep 05 08:40:07 <CIA-77> 03Sylvain Paré <sylvain.pare@gmail.com> 07master * r9add266141 10openembedded.git/recipes/shr/ (initscripts-shr/palmpre/umountfs initscripts-shr_0.0.1.bb): 
Sep 05 08:40:07 <CIA-77> initscripts-shr: add a palmpre specific umountfs script
Sep 05 08:40:07 <CIA-77> * JaMa: fixed line breaks and rebumped PR
Sep 05 08:40:07 <CIA-77> Signed-off-by: Sylvain 'GarthPS' Paré <sylvain.pare@gmail.com>
Sep 05 08:40:07 <CIA-77> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Sep 05 08:40:18 <CIA-77> 03Sylvain Paré <sylvain.pare@gmail.com> 07master * r3abce573b9 10openembedded.git/conf/distro/aurora.conf: 
Sep 05 08:40:18 <CIA-77> aurora.conf: set default locale for images
Sep 05 08:40:18 <CIA-77> * permit to use GLIBC_GENERATE_LOCALES =.. and avoid
Sep 05 08:40:18 <CIA-77> opkg_install_cmd: Cannot install package locale-base-.. message during
Sep 05 08:40:19 <CIA-77> do_rootfs
Sep 05 08:40:19 <CIA-77> Signed-off-by: Sylvain 'GarthPS' Paré <sylvain.pare@gmail.com>
Sep 05 08:40:20 <CIA-77> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Sep 05 08:50:39 <bluelightning> morning all
Sep 05 09:05:55 <GNUtoo|work> hi, in openembedded-core/meta/recipes-qt/qt4/qt4.inc there is:
Sep 05 09:06:37 <GNUtoo|work> RRECOMMENDS_${QT_BASE_NAME}-demos += " \ [...] ${PN}-doc"
Sep 05 09:06:45 <GNUtoo|work> the docs are huge
Sep 05 09:08:50 <GNUtoo|work> hmmm
Sep 05 09:09:06 <GNUtoo|work> the commit 4c8f498624c81d6f9f5361975c9c1250fb2fc477 have an explanation...
Sep 05 09:10:09 <GNUtoo|work> hi ericben 
Sep 05 09:10:16 <GNUtoo|work> what do you think of http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?id=4c8f498624c81d6f9f5361975c9c1250fb2fc477
Sep 05 09:10:48 <bluelightning> GNUtoo|work: that's because the demo UI actually displays parts of the docs at runtime
Sep 05 09:10:55 <GNUtoo|work> yes
Sep 05 09:10:59 <GNUtoo|work> but the docs are huge....
Sep 05 09:11:24 <ericben> yes, when we add doc & code we don't fit in our 256MB  flash if I remember correctly
Sep 05 09:11:27 <GNUtoo|work> all the docs are the size of the NAND of the device I've on my desk
Sep 05 09:11:36 <bluelightning> maybe there is some subset that could be split out for the demo
Sep 05 09:11:57 <ericben> I think doc & code should be an option as the most important in the demo image is to have the possibility to run the examples
Sep 05 09:12:21 <ericben> which was possible in the oe-legacy qtdemo images
Sep 05 09:13:06 <bluelightning> well the demo UI needs to run properly; so if you disable them you should be patching the UI so that it works without them
Sep 05 09:13:17 <ericben> the demo ui works without this
Sep 05 09:13:31 <ericben> it only doesn't show the code & description
Sep 05 09:13:42 <ericben> but you have the possibility to launch the examples
Sep 05 09:14:03 <ericben> the only button now working is the one to see the code
Sep 05 09:14:36 <bluelightning> hmm, ok... if that's the case then no problem, let's remove the recommendation
Sep 05 09:15:40 <ericben> I have this running in legacy-oe since I wrote the qtdemo images so I'm sure it works as is ;-)
Sep 05 09:15:55 <ericben> ok I have to ge see you later
Sep 05 09:16:12 <GNUtoo|work> ok
Sep 05 09:16:24 <GNUtoo|work> see you later
Sep 05 09:20:08 <GNUtoo|work> bluelightning, btw why does qt4.inc lack INC_PR ?
Sep 05 09:20:36 <GNUtoo|work> ah maybe becuase it's 0
Sep 05 09:20:56 <GNUtoo|work> ah no
Sep 05 09:21:01 <bluelightning> GNUtoo|work: I think there's INC_PR in the other inc files
Sep 05 09:21:04 <GNUtoo|work> it's because there are 2 requires
Sep 05 09:21:15 <bluelightning> it's a little bit complicated :/
Sep 05 09:21:34 <GNUtoo|work> I know that, I just didn't look at qt4-embedded_foo.bb
Sep 05 09:21:35 <bluelightning> basically at the moment you should bump INC_PR in the other inc files if you modify qt4.inc
Sep 05 09:22:57 <GNUtoo|work> ok, I suspected that I had to do that
Sep 05 09:23:02 <GNUtoo|work> as I see no other ways
Sep 05 09:39:40 <ensc|w> has somebody seen that gcc 4.6 miscompiles kernel 2.6.33?  E.g. on an omap3 platform, USB does not work with gcc 4.6 but with gcc 4.5 (only root hub is seen).  Things seem to be fine with kernel 3.0
Sep 05 09:43:58 <JaMa|Off> ensc|w: iirc there was report about it on oe-core or yocto ML
Sep 05 09:44:24 <JaMa|Off> ensc|w: iirc it was from Gary and about beagle
Sep 05 09:45:36 <ensc|w> yes; found it.  gcc 4.6 accesses elements in __attribute__(packed) bytewise, which has very bad effects when declaring cpu registers in this way
Sep 05 10:54:29 <CIA-77> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r0655368e72 10openembedded.git/recipes/openmoko-3rdparty/mcnavi_0.3.1.bb: 
Sep 05 10:54:29 <CIA-77> mcnavi: add 0.3.1
Sep 05 10:54:29 <CIA-77> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
**** BEGIN LOGGING AT Mon Sep 05 11:28:15 2011
Sep 05 12:57:27 <pwgen> hi
Sep 05 12:58:39 <pwgen> what i have to do to add a meta layer to oe-core ? ( f.eks. meta-efikamx ) 
Sep 05 12:59:36 <JaMa|Off> git checkout meta-efikamx and update conf/bblayers.conf to include it
Sep 05 13:02:51 <pwgen> ok this worked for meta-micro. but i tried meta-openembeded, meta-smartphones,meta-efikamx .. are there any working layers ?
Sep 05 13:05:22 <bluelightning> pwgen: they do work... what issue are you seeing?
Sep 05 13:06:27 <pwgen> meta-smartphones failed wit missing klibc.bbclass , meta-angstrom  failed with "ANG_VER_MAIN[:=], expression was" ..... 
Sep 05 13:06:47 <JaMa|Off> pwgen: you should read layer/README
Sep 05 13:06:52 <pwgen> in reality o managed only the meta-micro to run 
Sep 05 13:07:04 <mickey|office> hi pwgen
Sep 05 13:07:11 <JaMa|Off> ie meta-smartphone depends on meta-oe, ie because of klibc.bbclass
Sep 05 13:07:33 <JaMa|Off> and also meta-efl/meta-fso.. so you HAVE to read layer/README
Sep 05 13:07:50 <pwgen> whereis /layer/README 
Sep 05 13:08:09 <pwgen> <mickey|office>: hi 
Sep 05 13:08:10 <JaMa|Off> in layer checkout
Sep 05 13:10:51 <pwgen> JaMa: ?  somwhere inside the oe-core directory ?
Sep 05 13:11:12 <JaMa|Off> pwgen: no every layer has own README file
Sep 05 13:13:57 <pwgen> i whant to build th zaurus image. does that mean i have to add openembedded-core meta-openembedded  to the bblayers
Sep 05 13:14:10 <bluelightning> yes
Sep 05 13:14:25 <bluelightning> maybe we should start using the layer dependency stuff I added...
Sep 05 13:14:36 <bluelightning> then at least it will be more obvious
Sep 05 13:14:45 <pwgen> do i add oe-smartphones or the meta-zaurus  
Sep 05 13:15:19 <JaMa|Off> bluelightning: or confirmation dialog about reading README file :)
Sep 05 13:20:37 <pwgen> ls 
Sep 05 13:23:37 <kobe_> When is the next release of OE planned?
Sep 05 13:24:28 <pwgen> seems to be an error and try thing ...  No such file or directory: '.../meta-openembedded/conf/layer.conf'
Sep 05 13:24:38 <bluelightning> pwgen: meta-zaurus
Sep 05 13:24:53 <bluelightning> pwgen: and you need the meta-openembedded/meta-oe subdir
Sep 05 13:25:09 <bluelightning> (this is layer vs. a repository of layers)
Sep 05 13:25:45 <bluelightning> I've been thinking that the layer index page really needs to be expanded out to list all layers rather than just repositories
Sep 05 13:25:55 <pwgen> now i am total confused. 
Sep 05 13:26:29 <bluelightning> pwgen: so, when you fetch meta-openembedded, you're fetching a repository that contains a number of layers, not just one
Sep 05 13:26:41 <JaMa|Off> bluelightning: btw: I'm ready to drop meta-zaurus from meta-smartphone (I'm not using it anymore) as soon as you publish meta-handheld to final url
Sep 05 13:26:41 <bluelightning> the one layer you want from that repo is called meta-oe
Sep 05 13:26:45 <pwgen> what are layers , what are repositories, where i have to copy layers , ....
Sep 05 13:27:04 <bluelightning> JaMa|Off: cool, hopefully khem / ka6sox can sort out the cgit thing and I'll do that
Sep 05 13:27:08 <pwgen> any documetaion about this , any working samples  ? 
Sep 05 13:28:37 <bluelightning> pwgen: we need to improve our documentation, definitely
Sep 05 13:28:42 <Jay7> pwgen: I have similar feelings now :)
Sep 05 13:28:57 <pwgen> ok cu yu later. must catch my kid from kindergarden ...
Sep 05 13:29:01 <JaMa|Off> pwgen: here is example of working bblayers.conf http://git.shr-project.org/git/?p=shr-makefile.git;a=blob_plain;f=conf/shr-core/bblayers.conf;hb=HEAD
Sep 05 13:29:43 <JaMa|Off> pwgen: where you can see that I'm using couple of layers from 1 checkout (ie meta-efl/meta-gnome/meta-gpe/meta-oe from meta-openembedded repository)
Sep 05 15:47:18 <CIA-77> 03Steffen Sledz <sledz@dresearch-fe.de> 07org.openembedded.dev * rd93378887f 10openembedded.git/recipes/binutils/binutils_2.18.bb: 
Sep 05 15:47:18 <CIA-77> binutils-2.18: fix checksums
Sep 05 15:47:18 <CIA-77> Symbolic link for binutils-2.18.tar.bz2 at the GNU FTP server has changed to
Sep 05 15:47:18 <CIA-77> a new version.
Sep 05 15:47:18 <CIA-77> Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Sep 05 16:44:14 <ka6sox> khem?
Sep 05 19:21:25 <CIA-77> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07master * r24272dae15 10bitbake.git/lib/bb/siggen.py: 
Sep 05 19:21:25 <CIA-77> lib/bb/siggen.py: return a string from noop get_taskhash
Sep 05 19:21:25 <CIA-77> OpenEmbedded is expecting to get a string from get_taskhash, but noop siggen
Sep 05 19:21:25 <CIA-77> returns just 0 (number), so OE classes/sstate.bbclass barfs badly. Fix that.
Sep 05 19:21:25 <CIA-77> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Sep 05 19:21:25 <CIA-77> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sep 05 19:21:29 <CIA-77> 03Paul Eggleton <paul.eggleton@linux.intel.com> 07master * r069d85cde0 10bitbake.git/lib/bb/ui/hob.py: (log message trimmed)
Sep 05 19:21:30 <CIA-77> hob: clear out temporary file list after deleting
Sep 05 19:21:30 <CIA-77> If you don't clear out files_to_clean after the files get deleted and
Sep 05 19:21:30 <CIA-77> then you run a second build, it will try to delete the files from the
Sep 05 19:21:30 <CIA-77> first build and you will get a "No such file or directory" error.
Sep 05 19:21:30 <CIA-77> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Sep 05 19:21:31 <CIA-77> Signed-off-by: Joshua Lock <josh@linux.intel.com>
Sep 05 19:21:31 <CIA-77> 03Paul Eggleton <paul.eggleton@linux.intel.com> 07master * r71ac7fda51 10bitbake.git/lib/bb/ui/ (crumbs/runningbuild.py hob.py): (log message trimmed)
Sep 05 19:21:32 <CIA-77> hob: fix segfault on second build
Sep 05 19:21:32 <CIA-77> Some internal lists were not being cleared, resulting in incorrect
Sep 05 19:21:33 <CIA-77> program flow on the second build, causing a structure to be accessed
Sep 05 19:21:33 <CIA-77> incorrectly which resulted in a segfault.
Sep 05 19:21:44 <CIA-77> Fixes [YOCTO #1332]
Sep 05 19:21:45 <CIA-77> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Sep 05 19:21:45 <CIA-77> 03Joshua Lock <josh@linux.intel.com> 07master * r73b6ff4654 10bitbake.git/lib/bb/ui/hob.py: (log message trimmed)
Sep 05 19:21:45 <CIA-77> hob: disable removal of packages
Sep 05 19:21:45 <CIA-77> It's felt that the stability of package deselection is not sufficient for
Sep 05 19:21:45 <CIA-77> the upcoming release and thus package removal should be disabled.
Sep 05 19:21:45 <CIA-77> I'd actually like to see this patch, or its effects, reverted as soon as
Sep 05 19:21:46 <CIA-77> the release bits have been frozen so that this issue can continue to be
Sep 05 19:21:46 <CIA-77> worked on.
Sep 05 19:21:47 <CIA-77> 03Joshua Lock <josh@linux.intel.com> 07master * rb0cce5b52a 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: (log message trimmed)
Sep 05 19:21:47 <CIA-77> ui/crumbs/runningbuild: mask run_buildstats failure
Sep 05 19:21:48 <CIA-77> The buildstats handler causes an exception with: "'NoneType' object has no
Sep 05 19:21:48 <CIA-77> attribute 'startswith'" early a build via hob, leaving a glaring red row
Sep 05 19:22:02 <CIA-77> which means nothing to the user.
Sep 05 19:22:02 <CIA-77> Mask this error until such a time as we have opportunity to correctly
Sep 05 19:22:02 <CIA-77> diagnose and fix the root problem.
Sep 05 19:22:02 <CIA-77> 03Joshua Lock <josh@linux.intel.com> 07master * r02ab0e11d8 10bitbake.git/lib/bb/ui/ (4 files in 2 dirs): (log message trimmed)
Sep 05 19:22:02 <CIA-77> hob: use both pre and post files for hob configuration
Sep 05 19:22:02 <CIA-77> We need to set various variables *before* parse begins, the simplest way
Sep 05 19:22:03 <CIA-77> to ensure this is to use a pre configuration file for the relevant
Sep 05 19:22:03 <CIA-77> configuration entries.
Sep 05 19:22:04 <CIA-77> (22 lines omitted)
Sep 05 20:16:24 <mario-goulart> Hi.  What bitbake variables should I join together to get the location of the log.do_* files? I see "temp" is part of their location path, but bitbake -e | egrep '^[A-Z]+=.*temp.*' doesn't tell me many useful things.
Sep 05 20:16:44 <lumag> evening!
Sep 05 20:23:34 <PaulePanter> mario-goulart: What distribution do you use?
Sep 05 20:23:58 <PaulePanter> mario-goulart: Normally it is under your build directory.
Sep 05 20:25:13 <mario-goulart> PaulePanter: uh, tough question.  A custom distro by ossystems.  I can find the log.do_* files, but I'd like a way to programatically locate them by joining bitbake variables. The `T' variable looks useful.
Sep 05 20:27:11 <PaulePanter> mario-goulart: Sorry, I do not know. In `conf/local.conf` I see `TMPDIR = "${OETREE}/build-minimal-eglibc/${DISTRO}-dev"`.
Sep 05 20:28:43 <mario-goulart> PaulePanter: are you using oe-core and layers or the classic OE?
Sep 05 20:56:11 <PaulePanter> mario-goulart: I am using oe.dev/oe-classic.
Sep 05 20:56:30 <mario-goulart> PaulePanter: ah, ok.
Sep 05 20:57:05 <mario-goulart> I'm using the layers thing here, so things may be a bit different.  Thanks.
Sep 05 20:59:34 <PaulePanter> mario-goulart: Understood. Good luck. You can also send a message to the list.
Sep 05 20:59:51 <mario-goulart> PaulePanter: thank you.
Sep 05 22:06:47 <ant__> pb_: ping ?
Sep 05 22:21:08 <lumag> bluelightning, what about a sane default for MACHINE_DISPLAY_*_PIXELS in task-opie.bb?
Sep 05 22:22:42 <bluelightning> lumag: sounds like a reasonable idea
Sep 05 22:22:59 <lumag> vga or qvga?
Sep 05 22:26:26 <bluelightning> good question...
Sep 05 22:26:59 <bluelightning> qvga I guess
Sep 05 22:27:17 <bluelightning> doesn't really matter as long as it's set to something sensible :)
Sep 05 22:28:08 <ant__> btw, pls fix the /LOGO_SIZE/ check in linux.inc
Sep 05 22:29:26 <bluelightning> ant__: is there a patch for that somewhere already?
Sep 05 22:29:35 <ant__> how do you prefer it?
Sep 05 22:30:02 <bluelightning> if it's already in meta-zaurus I can just grab it myself
Sep 05 22:30:08 <ant__> ok, mom
Sep 05 22:33:55 <ant__> ok, this one should be ported to linux.inc  http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=029a03a75fe45cfb5c12b373bc90d88832b78add
Sep 05 22:34:17 <ant__> is already in linux-kexecboot.inc
Sep 05 22:39:05 <ant__> in the same manner, this patch should be reverted in linux.inc
Sep 05 22:39:07 <ant__> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/recipes/linux/linux.inc?h=org.openembedded.dev&id=99c8541b7184df8912b6cd07e3aaae0eaf31bf93
Sep 05 22:39:37 <ant__> (+LOGO_SIZE ?= "."  should stay ofc)
Sep 05 22:40:08 <ant__> pls see how this is done in linux-kexecboot.inc, just this :)
Sep 05 22:40:50 <ant__> in fact I split thge two files because linux.inc was going bitrot and deprecated
Sep 05 22:50:21 <bluelightning> ant__: hmm, I have to admit I don't like this use of IMAGE_FEATURES to affect options for building individual recipes
Sep 05 22:50:34 <bluelightning> but it seems it is accepted within oe-core... so...
Sep 05 22:50:46 <ant__> in fact we should remove this debug stuff from both
Sep 05 22:50:49 <ant__> +1 from me
Sep 05 22:51:08 <ant__> we have anyway to hack to enable full-debug
Sep 05 22:51:12 <bluelightning> well... what would you like me to do then?
Sep 05 22:51:25 <ant__> lumag: ^ ?
Sep 05 22:52:10 <ant__> maybe we should set loglevel=3 for linux-kexecboot.inc  and quiet  for linux.inc
Sep 05 22:52:12 <ant__> hardcoded
Sep 05 22:52:26 <lumag> ant__, I miss, wat do you mean.
Sep 05 22:52:48 <ant__> this sort of debug depending on image features / old way was in local.conf
Sep 05 22:53:06 <lumag> The loglevel in linux-kexecboot is pointless AFAIR, as we don't enable printk/BUG
Sep 05 22:53:17 <ant__> exactly
Sep 05 22:53:29 <ant__> and for production, better see the logo
Sep 05 22:53:32 <lumag> And I'd really like to retain the ability to enable loglevel
Sep 05 22:53:35 <ant__> you need serial anyway
Sep 05 22:53:58 <lumag> s/loglevel/debug output/
Sep 05 22:54:04 <lumag> I mean for usual kernels.
Sep 05 22:54:09 <bluelightning> should we have KERNEL_DEBUG or something like that?
Sep 05 22:54:11 <ant__> and need editing kernel config + cmdline
Sep 05 22:55:53 <ant__> and about ${WORKDIR}/${LOGO_SIZE}/logo, this was possible with oe-fetcher
Sep 05 22:56:00 <ant__> oe-dev
Sep 05 22:56:48 <lumag> Probably logo should be set by distribution.
Sep 05 22:57:01 <lumag> If required/asked
Sep 05 22:57:22 <lumag> And kexecboot would benefit from some kind of kexecboot splash
Sep 05 22:58:30 <lumag> Regarding linux.inc
Sep 05 22:58:54 <lumag> At least KERNEL_DEVICETREE_machine settings should be dropped.
Sep 05 22:59:41 <bluelightning> what were they useful for?
Sep 05 23:00:55 <lumag> for powerpc boxes, which require device tree blob to boot.
Sep 05 23:01:23 <ant__> soon for ARM
Sep 05 23:01:40 <lumag> Yep.
Sep 05 23:01:55 <lumag> and also on MIPS iirc.
Sep 05 23:02:42 <lumag> So devicetree handling (generic parts) should be moved to oe-core kernel.bbclass or kernel-dtb.bbclass
Sep 05 23:03:06 <lumag> And individual per-board settings can just be dropped, as they have to be selected by machine configs.
Sep 05 23:07:18 <lumag> I'm still unsure about things like CORTEXA8FIXUP
Sep 05 23:08:07 <lumag> And other strange parts of that .inc
Sep 05 23:09:13 <lumag> kernel-headers handling probably should go to kernel.bbclass
Sep 05 23:09:15 <lumag> etc.
Sep 05 23:10:24 <ant__> lumage, about image_types.bbclass, there is an IMAGE_CMD_jffs2 = 
Sep 05 23:10:33 <ant__> hiding our own in zaurus.inc
Sep 05 23:11:17 <lumag> and kernel doesn't require PARALLEL_MAKE = "" setting. 
Sep 05 23:11:30 <lumag> Otherwise it has to be fixed.
Sep 05 23:11:51 <lumag> Oops. that's noise.
Sep 05 23:12:10 <ant__> we could adapt our string and use the EXTRA_IMAGECMD stuff but I think we should keep it as it is, with jffs2.summary
Sep 05 23:12:36 <ant__> so ask to change to IMAGE_CMD_jffs2 ?= 
Sep 05 23:14:15 <lumag> I'd suggest to add jffs2summary image type, then push it to image-types.bbclass
Sep 05 23:14:32 <lumag> and -m favourlzo then could be passed via EXTRA_IMAGECMD
Sep 05 23:15:24 <ant__> as it is now, images are not bootables
Sep 05 23:17:00 <lumag> For eraseblock handling & co please consider e.g. meta-texasinstruments/conf/machine/include/davinci.inc
Sep 05 23:17:09 <lumag> or nokia900 handling.
Sep 05 23:17:29 <lumag> And I think that summary handling should be moved to image-types.bbclass
Sep 05 23:18:01 <ant__> this adds dependency on sumtool
Sep 05 23:18:06 <lumag> From my POV it's like ext3.gz
Sep 05 23:18:16 <ant__> yes, seems good idea
Sep 05 23:19:00 <lumag> sumtool is a part of mtd-utils
Sep 05 23:19:17 <ant__> ok, mtd-utils-native
Sep 05 23:20:06 <lumag> we already depend on it for mkfs.jffs2
Sep 05 23:20:21 <ant__> fine, nothing to add then
Sep 05 23:20:53 <ant__> FYI I started to bother the klibc maintainer about ubi/ubifs :)
Sep 05 23:21:09 <ant__> we even sent him some JaMa's images
Sep 05 23:23:58 <lumag> ant__, it seems I miss your point about klibc vs. kexecboot
Sep 05 23:24:00 <bluelightning> ant__: http://pastebin.com/wscFrTNX
Sep 05 23:25:19 <ant__> the fstype detection comes straight from klibc
Sep 05 23:25:50 <lumag> going to sleep now
Sep 05 23:26:06 <ant__> gn
Sep 05 23:26:40 <lumag> ant__, if you'd like I can try splitting linux.inc
Sep 05 23:26:57 <lumag> if I have enough time tomorrow
Sep 05 23:27:05 <ant__> graet, thx
Sep 05 23:27:23 <lumag> ok
Sep 05 23:27:30 <lumag> gn
Sep 05 23:28:53 <ant__> bluelightning: hm, I don't think we should force a logo in linux.inc. should we? Apart this looks good
Sep 05 23:29:25 <bluelightning> ant__: well, it doesn't force it since most users of linux.inc override SRC_URI
Sep 05 23:29:33 <bluelightning> which makes it pointless really
Sep 05 23:29:38 <bluelightning> I'll turn it into a comment
Sep 05 23:30:02 <ant__> ok, it was the SRC_URI setting in linux-kexecboot.inc 
Sep 05 23:30:09 <ant__> the first ;)
Sep 05 23:30:14 <ant__> I see
Sep 05 23:31:45 <bluelightning> ok to push?
Sep 05 23:34:20 <ant__> I'd say yes
Sep 05 23:35:09 <ant__> then pls fix CMDLINE_DEBUG ?= '${@base_conditional("DISTRO_TYPE", "release", "quiet", "debug", d)}'
Sep 05 23:35:19 <ant__> DISTRO_TYPE is unused now afaik
Sep 05 23:36:20 <bluelightning> ant__: so did we reach a conclusion as to what to use in its place?
Sep 05 23:37:09 <ant__> I don't know, when I patched the other using IMAGE_FEATURES I was mimicking some Khem commit iirc
Sep 05 23:37:28 <bluelightning> ant__: yes, dropbear uses this even if it seems wrong
Sep 05 23:37:39 <bluelightning> (IMAGE_FEATURES I mean)
Sep 05 23:37:53 <ant__> iirc, RP was not against, not sure
Sep 05 23:38:02 <bluelightning> ok I will do the same, it can always be tidied up globally later
Sep 05 23:38:11 <ant__> maybe was in #yocto
Sep 05 23:38:57 <ant__> gotcha, yes, it was dropbear btw ;)
Sep 05 23:39:50 <ant__> bluelightning: I still have to unerstand the actual IMAGE_FEATURES. 
Sep 05 23:40:10 <ant__> coming from Gentoo and USE = I'm a bit discouraged ;)
Sep 05 23:40:46 <bluelightning> actually IMAGE_FEATURES is not really like USE... DISTRO_FEATURES is closer to that
Sep 05 23:41:05 <ant__> you see, total confusion :p
Sep 05 23:41:23 <bluelightning> ok, pushed, thanks all
Sep 05 23:41:33 <bluelightning> (also pushed lumag's nandlogical patch)
Sep 05 23:41:37 <ant__> I'll re-read the manual next week. promised ;)
Sep 06 00:03:36 <ant__> gn
**** ENDING LOGGING AT Tue Sep 06 02:59:56 2011