**** BEGIN LOGGING AT Wed May 21 02:59:56 2008
May 21 05:10:32 <winux> i try to compile my openembedded by run "bitbake openmoko-devel-image"  but failed  ,so how to clean up in order to start a new compile procedure ?
May 21 05:11:35 <wicknix> try bitbake -c clean openmoko-devel-image
May 21 05:12:25 <wicknix> and g'nite
May 21 06:36:03 <shri> is there any x app (v4l2 app) that can capture images from a camera
May 21 07:09:15 <rwhitby> ~seen koen
May 21 07:09:24 <ibot> koen <n=koen@s55917625.adsl.wanadoo.nl> was last seen on IRC in channel #oe, 159d 21h 3m 1s ago, saying: 'I forgot to commit that portion yesterday'.
May 21 07:13:33 <methril> morning
May 21 08:06:07 <Genesis> yopla
May 21 08:08:46 <likewise> ola
May 21 09:12:40 <hrw> morning
May 21 09:52:08 <RP> morning all
May 21 10:02:04 <Crofton|work> gm
May 21 10:02:51 <hrw> hi Crofton|work 
May 21 10:13:21 <likewise> gm lal
May 21 10:13:25 <likewise> all even
May 21 10:19:09 <florian> hi likewise 
May 21 10:30:15 <mattaw> morning. Relatively speaking :)
May 21 10:30:29 <hrw> ~ugt
May 21 10:30:30 <ibot> rumour has it, ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html
May 21 10:30:54 <mattaw> hrw :) didn't know that
May 21 10:31:43 <mattaw> do you know which people are responsible for angstrom as opposed to oe? It seems difficult to tell them apart
May 21 10:31:58 <hrw> hi mickeyl 
May 21 10:32:03 <mickeyl> morning folks
May 21 10:32:04 <mickeyl> hey hrw
May 21 10:32:13 <XorA> hey mickeyl 
May 21 10:32:17 <mickeyl> yo XorA 
May 21 10:32:19 <hrw> mickeyl: how goes openmoko-fltk^W^W^W^W^W work?
May 21 10:32:28 <mickeyl> hahaha :D
May 21 10:32:53 <mickeyl> good so far. I'm still suffering from a cold, but my work on the Openmoko framework is progressing very well
May 21 10:33:48 <RP> zecke: very busy?
May 21 10:35:47 <RP> zecke_: very busy? (since you probably missed the question above)
May 21 10:36:06 <zecke_> RP: shoot
May 21 10:36:21 <RP> zecke_: Firstly, the patch I posted to the OE/bitbake lists
May 21 10:36:28 <RP> re: clearing the environment
May 21 10:39:33 <zecke_> RP: yes, but. Style: Commented out code :)
May 21 10:40:04 <zecke_> RP: but, technical: My 2nd patch cleaned the environment after having parsed the default config. This means. that MACHINE, DISTRO, FOO, is inside the dict and just work
May 21 10:40:04 <cdbot2> * * OE Bug 4144 has been RESOLVED (FIXED) by <mickeyl>
May 21 10:40:06 <cdbot2> * * python-core config Makefile includes ccache reference
May 21 10:40:08 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4144
May 21 10:40:14 <RP> zecke_: Yes, I will fix that. It was meant to be uncommented and I just didn't refresh the patch before sending
May 21 10:40:30 <zecke_> RP: but the build is not influenced as shell scripts and python will not have the environment anymore
May 21 10:40:38 <RP> zecke_: I don't like the idea of cleaning after parsing the default config
May 21 10:40:50 <zecke_> RP: so people setting MACHINE need to rely on the unexport, which is a bit odd
May 21 10:40:59 <RP> zecke_: I think we should do it in the more obvious way so things are predictable/understandable
May 21 10:41:56 <RP> zecke_: We import all the variables into bb.data from the environment so builds can be influences, just not the shell execution environments
May 21 10:42:07 <zecke_> RP: so how is MACHINE="foo" bitbake bla handled?
May 21 10:42:28 <zecke_> RP: you will have to put it in the whitelist, and then make sure it is unexported by base.bbclass logic?
May 21 10:42:30 <RP> zecke_: BB_ENV_EXTRA_WHITE="MACHINE" MACHINE=foo bitbake xyz
May 21 10:42:35 <hrw> screen say "Datei | Sensoren"... how I do not like german language... (I know what it means anyway)
May 21 10:42:52 <RP> zecke_: If users want to do that from the commandline they'll have to adjust their environment
May 21 10:43:05 <zecke_> RP: yes AND unexport in base.bbclass to not fuckup binutils :)
May 21 10:43:14 <RP> zecke_: yes, we already unexport it
May 21 10:43:36 <zecke_> RP: yes, but we don't unexport SILENT, QUIET, FOO, or the other 10 env vars raster is using to mess up buildsystems :)
May 21 10:43:49 <RP> zecke_: but we also don't whitelist them
May 21 10:44:21 <RP> zecke_: By having the user whitelist things they accept that it may cause fun and they need to be careful
May 21 10:44:24 <zecke_> RP: there is no namespace for MACHINE, DISTRO, SILENT, So if you use them in your local.conf and they are used by a buildsystem you lose
May 21 10:44:31 <hrw> zecke_: if $USER = raster then unexport os.environment.each()
May 21 10:44:44 <CIA-22> 03mickeyl 07org.oe.dev * rd3e6d2ba... 10/ (1 packages/python/python_2.5.2.bb): python 2.5.2 sed hardcoded ccache out of Makefile and substitute with $(CCACHE). Closes #4144
May 21 10:44:48 <zecke_> RP: no. They would use a whitelist to have their stuff in the config working, they don't think of pyrex 3.9.2
May 21 10:44:55 <RP> zecke_: no, since they are only exported if they were in the original environment
May 21 10:45:06 <zecke_> RP: yes, and that is flawed
May 21 10:45:12 <RP> zecke_: why?
May 21 10:45:23 <zecke_> RP: because they break the build randomly?
May 21 10:45:32 <zecke_> RP: we have export to export stuff to the scripts
May 21 10:45:39 <zecke_> RP: we added unexport because we sucked back then
May 21 10:45:50 <RP> zecke_: Which is why I agree with sanitising things by default
May 21 10:46:01 <zecke_> RP: cleaning the environment will create predictable builds :)
May 21 10:46:16 <zecke_> RP: having whitelist -> parse -> blacklist for unexport is not the way to go. It is obscure
May 21 10:46:40 <RP> zecke_: It makes peftect sense to be able to unexport a variable exported elsewhere
May 21 10:46:59 <RP> zecke_: whether we should export all the environment by default is a different question
May 21 10:47:21 <zecke_> RP: well. It made sense to fix the binutils built. The approach was wrong though
May 21 10:47:57 <zecke_> RP: We should not export more than POSIX.3 defines.  Otherwise export only things having an export flag
May 21 10:48:35 <RP> zecke_: I'd tend to agree with that
May 21 10:48:45 <zecke_> RP: See, with the extra whitelist, it will scream for changing the base.bbclass to add further unexports. But I think this is the wrong way to go. It is a game you can not win, as the environment is not a good namespace
May 21 10:48:56 <RP> zecke_: but that doesn't change my view that we need to whitelist what gets pulled into data from the environment
May 21 10:49:42 <RP> zecke_: I see these as two issues - 1) we shouldn't export everything from the original environment 2) we should whitelist what we pull into bb.data from the environment
May 21 10:49:53 <RP> My patch addresses 2), not 1)
May 21 10:49:59 <RP> but I agree both need addressing
May 21 10:50:19 <zecke_> RP: My issue was. What to do with "SILENT", "QUIET", "VERBOSE". I thought adding further unexports was not the way to go
May 21 10:50:24 <zecke_> BB_ENV_EXTRA_WHITE="MACHINE" MACHINE=foo bitbake xyz
May 21 10:50:27 <zecke_> sorry
May 21 10:50:47 <zecke_> BB_ENV_EXTRA_WHITE="MACHINE" BB_ENV_CLEAN_AFTER_PARSE="MACHINE" MACHINE=foo bitbake xyz
May 21 10:50:58 <RP> zecke_: agreed but that is problem 1), not 2)
May 21 10:51:06 <zecke_> would be the "symmetric" solution
May 21 10:51:34 <zecke_> actually, no
May 21 10:52:09 <zecke_> Having SILENT, MACHINE, DISTRO, FOO, in the configuration is not a problem at all. So limiting that is not part of what I want to solve
May 21 10:52:30 <zecke_> The issue is with exporting things to shell scripts. I think your patch is making that part more obscure :)
May 21 10:52:51 <RP> zecke_: but I think that from a reproducible build PoV we have to make bitbake not depend on random things in the environment by default
May 21 10:53:10 <RP> zecke_: I'd bet a can find some variables that can break the build ;-)
May 21 10:53:33 <zecke_> RP: CFLAGS and other things get properly initialized :)
May 21 10:53:52 <zecke_> RP: I would just say I don't think so, because I would like to see your results
May 21 10:54:10 <RP> I'd just have to find something set with ?=
May 21 10:54:43 <zecke_> RP: yupp, and is not in some way namespaced. BB_BREAK_THINGS=1 would be cheating
May 21 10:54:53 <RP> TERMCMD=foo bitbake bar -c devshell
May 21 10:55:26 <zecke_> RP: hehe, it should have been BB_TERMCMD then :)
May 21 10:55:38 <RP> DL_DIR=/dev bitbake bar -c fetch
May 21 10:55:59 <RP> IMAGE_FSTYPES=breakme bitbake image
May 21 10:56:19 <zecke_> RP: anyway. So we have (I think I missed that part). 1) What gets inherited from the environment 2) What gets exported to shell scripts
May 21 10:56:35 <RP> zecke_: yes
May 21 10:56:55 <RP> I'd like to see both made predicatable
May 21 10:57:32 <zecke_> RP: 1.) is a matter of lib/bb/data.py and inherit... we can either unset it before calling that or put the filtering/picking there. And I don't mind a whitelist
May 21 10:58:04 <zecke_> RP: 2.) I would do unexporting after we have inherited from the environment and have another whitelist for that
May 21 10:58:19 <RP> zecke_: 1) is fixed by my patch
May 21 10:58:42 <RP> zecke_: and the second whitelist isn't needed, bitbake.conf should have the right export FOO lines
May 21 10:58:57 <zecke_> RP: nah. It is a co-incidence that lib/bb/data.py is not seeing the things :)
May 21 10:59:15 <zecke_> RP: You whitelist MACHINE for the config, it gets auto whitelisted for the environment
May 21 10:59:15 <RP> zecke_: coincidence?
May 21 10:59:26 <zecke_> RP: side-effect
May 21 11:01:57 <RP> zecke_: ah, right, yes. We can remove that
May 21 11:01:59 <zecke_> RP: I think we should not have one set of vars for two slightly related things
May 21 11:02:31 <zecke_> RP: I'm tempted to move the current checks to lib/bb/data.py and have another, though similar, set of vars for the environment
May 21 11:02:54 <zecke_> RP: e.g. MACHINE=foo bitbake bla, I set MACHINE for the configuration, I don't set it for the environment of buildscripts
May 21 11:03:01 <RP> zecke_: IMO we don't need that set, it should be entirely controlled by the var[export] falg
May 21 11:03:15 <zecke_> RP: basicly you will never set something for a buildscript?
May 21 11:03:25 <zecke_> RP: well, then clean the environment completely after parsing :)
May 21 11:03:57 <RP> zecke_: As long as we have all the export FOO we need in bitbake.conf I'm fine with that
May 21 11:04:29 <RP> I do see what you mean about MACHINE being exported though and that is wrong
May 21 11:05:41 <RP> zecke_: basically after data.inheritFromOS is called we should unset everything
May 21 11:05:55 <RP> and drop matchesenv flag?
May 21 11:07:21 <zecke_> RP: sounds sane
May 21 11:07:38 <zecke_> and there is already a blacklist in that method :]
May 21 11:08:12 <RP> zecke_: yes but we can drop that
May 21 11:08:25 <RP> [if we default to whitelisting]
May 21 11:08:56 <RP> We can drop the matchesenv check in setVar too which might even give a speedup
May 21 11:10:46 <Crofton> glibc-intermediate just failed on me, is there an easy fix, or do I need to rebuild?
May 21 11:11:08 <woglinde> hi alle
May 21 11:11:19 <woglinde> ups -e
May 21 11:17:20 <hrw> Crofton:  I would rebuild 
May 21 11:17:30 <hrw> Crofton: but I do not look at cpu power
May 21 11:20:44 <Crofton> I'm going to rebuild on the big machine, but that has issues with libtool
May 21 11:34:34 <jeremy_laine> hello
May 21 11:34:54 <jeremy_laine> hrw: I have revamped the oestats UI, it's starting to look pretty good
May 21 11:36:48 <jeremy_laine> hrw: for instance, check this out: http://oestats.jerryweb.org/builds/42/
May 21 11:37:07 <jeremy_laine> hrw: then click on one of the "succeeded" links
May 21 11:37:18 <RP> zecke: I tried patching bitbake to remove auto exports and it breaks a few things, our metadata is quite bad ;-)
May 21 11:38:25 <hrw> jeremy_laine: nice it is
May 21 11:38:36 <hrw> jeremy_laine: please add OESTATS_BRANCH support
May 21 11:38:46 <jeremy_laine> hrw: eh?
May 21 11:38:49 <hrw> jeremy_laine: for .dev/.stable/non-oe
May 21 11:39:07 <hrw> jeremy_laine: Koen wants to run oestats with autobuilder - viewmtn links will be wrong
May 21 11:39:17 <jeremy_laine> hrw: is there any way we could pick this up automatically?
May 21 11:39:44 <jeremy_laine> hrw: I think we should have some sort of "MANIFEST" file at the root of any bbfile collection
May 21 11:40:02 <jeremy_laine> hrw: which gives a title + url to VCS
May 21 11:40:14 <jeremy_laine> hrw: that way we could version all the overlays
May 21 11:40:14 <hrw> jeremy_laine: tinderbox class forced user to set it
May 21 11:40:59 <jeremy_laine> hrw: did you notice the DEPENDS now show up when you click on a package build?
May 21 11:41:31 <jeremy_laine> hrw: on another topic, is the pagination at 20 items OK?
May 21 11:42:36 <hrw> jeremy_laine: pagination is ok
May 21 11:43:17 <jeremy_laine> hrw: OK, I have other projects to get on and oestats looks OK for an initial version so I'm going to give it a bit of a break
May 21 11:43:36 <jeremy_laine> hrw: feel free to keep feeding data so we can stress the system
May 21 11:44:00 <jeremy_laine> hrw: at some point I need to check DB calls to check eager loading is working OK
May 21 11:46:53 <hrw> my lenny test build goes
May 21 11:47:16 <hrw> http://oestats.jerryweb.org/builds/43/ - 404
May 21 11:48:53 <hrw> jeremy_laine: oestats assign builder ID but page is handled when there is some stuff provided
May 21 11:51:07 <zecke> RP: ouch. What is broken?
May 21 11:51:14 <zecke> RP: parse errors?
May 21 11:54:47 <hrw> jeremy_laine: but for pagination of build progress I would like to have a way to check latest progress without changing pages
May 21 11:55:04 <RP> zecke: we don't export things like PATH by default
May 21 11:55:22 <RP> zecke: I'll run through some tests and see how bad the damage is ;-)
May 21 12:00:13 <CIA-22> 03john_lee 07org.oe.dev * re7e8e506... 10/ (5 files in 3 dirs): cacao: add hg version 8190 and the corresponding cacaoh-native.
May 21 12:17:50 <jeremy_laine> hrw: what's the issue with http://oestats.jerryweb.org/builds/43/ ?
May 21 12:18:48 <jeremy_laine> hrw: if you want to reflect current progress we could revert the order of the packages
May 21 12:18:59 <jeremy_laine> hrw: that way page 1 is always the latest data
May 21 12:19:32 <jeremy_laine> hrw: I don't really like the idea of removing pagination as we could end hammering the DB
May 21 12:25:31 <hrw> jeremy_laine: start build - it will appear in 'builds' list but no page for it before data came
May 21 12:26:09 <jeremy_laine> hrw: ok, like: http://oestats.jerryweb.org/builds/41/
May 21 12:27:19 <hrw> probably
May 21 12:33:35 <hrw> http://kerneltrap.org/Linux/Git_Management
May 21 12:35:09 <jeremy_laine> hrw: OK, 404 fixed, you now get a "No package builds yet" page, see http://oestats.jerryweb.org/builds/41/
May 21 12:35:29 <hrw> cool
May 21 12:35:40 <hrw> metadata revision on right side does not fit 
May 21 12:37:20 <jeremy_laine> hrw: hmm.. I guess it needs to be truncated or something.. 
May 21 12:37:48 <jeremy_laine> hrw: how do you feel about the reversed order for the packages?
May 21 12:38:19 <jeremy_laine> (allowing you to hit F5 to get an update)
May 21 12:39:26 <hrw> can it be ?page=last?
May 21 12:39:55 <jeremy_laine> hrw: er.. I'm using Django's generic paginator let me check
May 21 12:40:36 <jeremy_laine> New in Django development version:
May 21 12:40:38 <jeremy_laine> As a special case, you are also permitted to use last as a value for page:
May 21 12:40:39 <jeremy_laine> /objects/?page=last
May 21 12:40:56 <jeremy_laine> hrw: heh, it will work in the future :)
May 21 12:42:13 <hrw> ;)
May 21 12:42:32 <jeremy_laine> hrw: by the way, I was thinking: if we don't want to load our servers, we could maybe stick oestats on google app engine: http://code.google.com/p/google-app-engine-django/
May 21 12:47:45 <RP> zecke: Should be drop bbimage?
May 21 12:47:48 <RP> s/be/we/
May 21 12:50:21 <hrw> jeremy_laine: it is your code - do what you want/need
May 21 12:51:47 <jeremy_laine> hrw: do you think we could have a METADATA_BRANCH in base.bbclass?
May 21 12:52:21 <jeremy_laine> hrw: would this allow you to override it for poky?
May 21 12:53:10 <jeremy_laine> hrw: it would be nice to have both METADATA_REVISION and METADATA_BRANCH set in the same place
May 21 12:54:13 <hrw> RP: opinion?
May 21 12:54:43 <Laibsch> hi
May 21 12:55:44 <Laibsch> likewise: Did your witpa program ever get integrated into OE?
May 21 12:55:55 <jeremy_laine> hrw: for OE branch can be parsed out of _MTN/options
May 21 12:56:05 <likewise> Laibsch: no, but I used it yesterday, where did you find out about this?
May 21 12:56:46 <likewise> Laibsch: In fact I can clean it up (mostly --help) and submit it in some way.
May 21 12:57:13 <Laibsch> Please do
May 21 12:57:20 <Laibsch> I was (of course) doing some bug work
May 21 12:57:28 <Laibsch> dtc came up
May 21 12:57:39 <Laibsch> the original source is currently 404
May 21 12:57:58 <Laibsch> and it so happens you used it as an example which is why I stumbled upon it
May 21 12:58:27 <Laibsch> I think it makes sense to eventually integrate it in an automatic fashion, resulting in more robust downloads
May 21 12:58:56 <Laibsch> if there is a hash entry in checksums.ini, then go ahead and download it with witpa's help
May 21 12:59:16 <Laibsch> It would be cool if you'd RFC'd something like that to be added to OE
May 21 13:08:18 <jeremy_laine> hrw: this works for me: http://pastebin.com/m777d0274
May 21 13:11:01 <hrw> nice
May 21 13:12:21 <jeremy_laine> hrw: should I push it, and let you handle other SCMs?
May 21 13:12:35 <jeremy_laine> hrw: also, you can plain override it if you want
May 21 13:16:28 <hrw> fine with me but I would want other dev  ack it
May 21 13:17:05 <zecke> re
May 21 13:17:36 <jeremy_laine> zecke: any thoughts on adding a METADATA_BRANCH variable? (http://pastebin.com/m777d0274)
May 21 13:18:16 <zecke> jeremy_laine: can't hurt
May 21 13:23:01 <CIA-22> 03jeremy_laine 07org.oe.dev * re35bdcf6... 10/ (1 classes/base.bbclass): base.bbclass: add a METADATA_BRANCH variable
May 21 13:23:06 <CIA-22> 03jeremy_laine 07org.oe.dev * rc008a2bf... 10/ (1 classes/oestats-client.bbclass): oestats-client.bbclass: report METADATA_BRANCH variable
May 21 13:23:18 <hrw> jeremy_laine: http://oestats.jerryweb.org/builds/44/ - you do not escaped gtk+
May 21 13:25:00 <Laibsch> RP: Thank you for http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commitdiff;h=342be92e862f499a0cb0622a4a5abc96720c9b1f and fixing the "two images at same time"-build
May 21 13:25:17 <Laibsch> Could it be that this broke debian bitbake?
May 21 13:25:51 <Laibsch> I wonder if http://packages.debian.org/bitbake already has the necessary lock funtion
May 21 13:25:55 <RP> Laibsch: That fix will ensure that packages using debian renaming work in PACKAGE_INSTALL, yes
May 21 13:25:55 <Laibsch> function
May 21 13:26:32 <RP> Laibsch: You can tell if you look in lib/bb/utils.py for "lockfile"
May 21 13:26:36 <Laibsch> RP: I mean, will that commit break things for people using 1.8.10-3 on debian?
May 21 13:27:25 <Laibsch> I saw some breakage with lock files not being created and was wondering if it was attributable to me using the debian package instead of the svn/cvs version.
May 21 13:27:40 * Laibsch does not know off-hand if bitbake is maintained in svn or cvs
May 21 13:27:52 <RP> Laibsch: bitbake 1.8.10 had the locking functions
May 21 13:27:59 <RP> Its in svn
May 21 13:27:59 <Laibsch> OK
May 21 13:30:03 <Laibsch> I'll see if it comes up again
May 21 13:33:10 <Laibsch> yes, it does
May 21 13:39:19 <likewise> Laibsch: I already did propose this once on the ML (witpa) but will re-do so now that I have a working version of it that does most of what you'ld want.
May 21 13:40:33 <likewise> Laibsch: It uses a sqlite database. I pruned it with checksums.ini which results in 1MB+, and I'm not sure of sqlite databases are host-endianess/word-width independent?
May 21 13:40:42 <likewise> s/of/if/
May 21 13:52:11 <CIA-22> 03Laibsch 07org.oe.dev * re54c6e58... 10/ (4 files in 2 dirs): glibmm: move up to latest stable release. fixes build problems in 4264.
May 21 14:00:04 <cdbot2> * * OE Bug 4264 has been RESOLVED (FIXED) by <Laibsch>
May 21 14:00:06 <cdbot2> * * glibmm fails do_compile
May 21 14:00:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4264
May 21 14:05:04 <cdbot2> * * OE Bug 2646 has been marked as DUPLICATE of bug 4278 by <Laibsch>
May 21 14:05:07 <cdbot2> * * updated bb file for ctorrent
May 21 14:05:08 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=2646
May 21 14:25:41 * Laibsch wonders when we are finally going to get a real wiki, one where real people can document stuff for real
May 21 14:26:14 <Laibsch> RP: http://rafb.net/p/1PFbpR47.html and http://rafb.net/p/WgBE0X57.html
May 21 14:26:15 <Laibsch> f2497299e919cb94e12fc8690a709479451e5510 from about a week ago works still fine with a clean tmp
May 21 14:26:32 <Laibsch> I don't see the build breaking with regards to locking problems anymore, though
May 21 14:27:09 <Laibsch> So, it might be something else.  But it seems glibc-intermediate breaks now.  Verified in Sonkei and Angstrom.
May 21 14:28:24 <Laibsch> RP: Very well possible this has nothing to do with the commit you made or the bitbake version. It was just the first thing that came to my mind after seeing something about "cannot create lock file, yadayada" or some such message yesterday.
May 21 14:30:15 <CIA-22> 03tmbinc 07org.oe.dreambox * r05dfbf7d... 10/ (3 files in 3 dirs): linux-dm800: enable CONFIG_SCSI_PROC_FS, wireless ext update
May 21 14:30:18 <CIA-22> 03tmbinc 07org.oe.dreambox * r37f35774... 10/ (1 packages/linux/linux-dm7025.bb): linux-dm7025: wireless ext update
May 21 14:30:22 <CIA-22> 03tmbinc 07org.oe.dreambox * rbc404d98... 10/ (3 files in 3 dirs): dreambox-buildimage-native: allow slightly larger secondstage loader
May 21 14:30:26 <CIA-22> 03tmbinc 07org.oe.dreambox * r4e264e06... 10/ (1 packages/dreambox/dreambox-secondstage.bb): dreambox-secondstage: update dm800,dm7025 to 61
May 21 14:32:03 <CIA-22> 03tmbinc 07org.oe.dreambox * r0bf9d901... 10/ (1 packages/images/dreambox-image.bb): dreambox-image: media player is a plugin now, so install it
May 21 14:34:05 <cdbot2> * * OE Bug 4284 has been created by lukas.gorris(AT)gmx.de
May 21 14:34:07 <cdbot2> * * no sound on htcblueangel
May 21 14:34:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4284
May 21 14:39:31 <RP> Laibsch: I don't think I'm guilty of that issue
May 21 14:39:41 <Laibsch> OK
May 21 14:39:46 <RP> (the error is that limits.h is missing)
May 21 14:40:03 <Laibsch> How can it be fixed?
May 21 14:40:05 <cdbot2> * * OE Bug 4285 has been created by lukas.gorris(AT)gmx.de
May 21 14:40:07 <cdbot2> * * pointer offset in scummvm
May 21 14:40:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4285
May 21 14:40:14 <RP> Laibsch: That depends why limits.h is missing
May 21 14:40:26 <Laibsch> you don't see it?
May 21 14:40:34 * Laibsch does a locate
May 21 14:40:40 <RP> Laibsch: I don't run .dev builds that often
May 21 14:40:57 <jeremy_laine> hrw: what will your METADATA_BRANCH be for poky?
May 21 14:41:26 * Laibsch finds LOTS of limits.h
May 21 14:44:43 <RP> Laibsch: Its an internal gcc header and it suggests you've somehow broken staging
May 21 14:45:03 <Laibsch> This is from a clean tmp
May 21 14:45:09 * Laibsch feels innocent ;-)
May 21 14:45:35 <RP> Was it using gcc 4.3.0?
May 21 14:54:38 <Laibsch> RP: possibly, but I think it was 4.2.4: http://rafb.net/p/cFjlur78.html
May 21 14:56:24 <RP> Laibsch: Sorry, I mean did it try and build gcc-cross-4.3.0 or gcc-cross-initial-4.3.0?
May 21 14:58:47 <Laibsch> RP: I already cleaned out tmp again and moved to the known-good revision for an opie-image build
May 21 14:59:02 <hrw> jeremy_laine: "Poky trunk" probably
May 21 14:59:04 <Laibsch> I can answer your question after the build is done
May 21 15:00:29 <Laibsch> RP: The known-good revision built 4.2.2 of gcc-cross and gcc-cross-initial
May 21 15:01:44 <RP> Laibsch: I'd be interested a diff between HEAD and the known good revision
May 21 15:01:58 <Laibsch> just a minute
May 21 15:02:09 <Laibsch> I'll pull that from another machine
May 21 15:11:06 <jmichel> Has anyone tried libusb to talk to a usb device on an OE distro?
May 21 15:11:26 <jmichel> I'm running a libusb app on Openmoko and it cannot find any devices
May 21 15:11:59 <jmichel> but "lsusb" works and shows the connected USB devices
May 21 15:16:53 <Tartarus> Stupid mtn question
May 21 15:17:05 <Tartarus> If I do a mtn checkout, how do I update it?
May 21 15:23:16 <broonie> Tartarus: mtn pull ; mtn update
May 21 15:26:37 <Laibsch> RP: http://oss.leggewie.org/wip/f2497299e919cb94e12fc8690a709479451e5510_vs_HEAD.txt
May 21 15:31:23 <Tartarus> thanks
May 21 15:31:34 <likewise> Tartarus: the easiest way is to cd into the checkout dir, then run mtn update
May 21 15:31:39 <jeremy_laine> hrw: I will put "poky.trunk" for your current entries, can you set this in your local.conf?
May 21 15:32:15 <jeremy_laine> hrw: actually, would org.pokylinux.dev be OK?
May 21 15:32:58 <jeremy_laine> hrw: or org.pokylinux.trunk?
May 21 15:36:26 <hrw> jeremy_laine: it is not monotone based
May 21 15:37:11 <jeremy_laine> hrw: I know that, look at http://oestats.jerryweb.org/builds/44/
May 21 15:38:27 <hrw> nice ;)
May 21 15:40:05 <cdbot2> * * OE Bug 4278 has been RESOLVED (FIXED) by <Laibsch>
May 21 15:40:07 <cdbot2> * * BB for enhanced ctorrent and its controller
May 21 15:40:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4278
May 21 15:40:50 <CIA-22> 03Laibsch 07org.oe.dev * r820f742e... 10/ (4 files in 2 dirs): ctorrent: add ctcs 1.4.1 and ctorrent 3.3.1. Closes 4278 and 2646.
May 21 15:46:52 <jeremy_laine> hrw: look again
May 21 15:47:12 <jeremy_laine> hrw: the behaviour is controlled by BRANCHES in http://svn.bolloretelecom.eu/opensource/trunk/oestats/oestats/models.py
May 21 15:47:19 <jeremy_laine> hrw: will move it to config soonish
May 21 16:01:01 <mattaw> any reason why gpe-conf should be creating alignment misses that anyone can think of?
May 21 16:11:16 <RP> Laibsch: I'd suspect the angstrom gcc version changes
May 21 16:41:07 <dfoley> anyone having gpe-filemanager build fail with: libavahi-common.so.3: undefined reference to `__stack_chk_fail@LIBSSP_1.0'
May 21 16:49:50 <RP> per task overrides are great :)
May 21 16:50:03 <RP> shame they're broken in bitbake but I'll fix that...
May 21 16:51:02 <tharvey> still trying to build anstrom base-image - bails out b/c it wants gcc3 vs gcc4 for qemu - what all is qemu used for and can I override those items? (Previously I've seen that qemu is used to determine the targets localle and it was suggested to set 'ENABLE_BINARY_LOCALE_GENERATION=0' but I haven't found that documented anywhere)
May 21 16:52:45 <RP> tharvey: What you've been told is correct, why not try that?
May 21 16:53:37 <tharvey> I was told to refer to the angstrom conf for more info but I couldn't find that define there... just looking for more info
May 21 16:53:46 <tharvey> is that the 'only' thing qemu is used for?
May 21 16:54:00 <RP> yes
May 21 16:54:02 <tharvey> I see it... its in conf/distro/include/anstrom.inc
May 21 17:00:37 <Genesis> a+
May 21 17:10:13 <CIA-22> 03koen 07org.oe.dev * rf9e1326d... 10/ (1 packages/linux/linux-omap2_git.bb): linux-omap2 git: bump srcrev to get basic powermanagement support for omap3
May 21 17:15:16 <tharvey> is there an option to bitbake that adds a timestamp to its output?
May 21 18:04:25 <hrw> tharvey: iirc no
May 21 18:07:24 * hrw -> afk
May 21 18:11:08 <pregier> hey all, i'm trying to track down spyro's latest dev status; does anyone know if he changed his homepage URL?
May 21 18:11:48 <pregier> should still be mnementh.co.uk, no?
May 21 18:18:55 <hernan_martinez> hello there
May 21 18:19:37 <hernan_martinez> anyone having problems with fetching from developer.imendio.com svn repo?
May 21 19:04:07 <hrw> re
May 21 19:04:14 <hrw> hernan_martinez: which recipe it is?
May 21 19:04:19 <cyrilRomain> hi hrw 
May 21 19:04:29 <hernan_martinez> gconf-dbus
May 21 19:04:33 <hernan_martinez> from stable
May 21 19:04:44 <hrw> hernan_martinez: just updated it from svn
May 21 19:04:46 <cyrilRomain> hrw: did midori suit your needs or did you find smaller app ?
May 21 19:05:04 <hrw> cyrilRomain: midori was enough
May 21 19:05:06 <hernan_martinez> i am getting
May 21 19:05:21 <hernan_martinez> NOTE: Update svn://developer.imendio.com/svn/gconf-dbus;module=trunk;REV=head;proto=http
May 21 19:05:21 <hernan_martinez> svn: REPORT request failed on '/svn/!svn/vcc/default'
May 21 19:05:21 <hernan_martinez> svn: Target path does not exist
May 21 19:05:47 <hrw> hernan_martinez: rm -rf $DL_DIR/svn/developer.imendio.com
May 21 19:06:33 <hernan_martinez> where is dl_dir usually?
May 21 19:06:43 <hrw> tmp/downloads?
May 21 19:07:11 <hernan_martinez> i dont have that .. dl maybe a subdir
May 21 19:07:13 <hernan_martinez> let me look
May 21 19:07:39 <cyrilRomain> hernan_martinez: 'sources' directory
May 21 19:08:34 <cyrilRomain> hernan_martinez: it is set to ${HOME}/sources by default
May 21 19:08:48 <hernan_martinez> ok
May 21 19:08:55 <cyrilRomain> hernan_martinez: check in your local.conf file
May 21 19:09:06 <hernan_martinez> found
May 21 19:10:16 <hernan_martinez> hum... deleted but then i tried bitbakse task-base again and got the same problem
May 21 19:10:48 <hernan_martinez> 3 days ago i built bootstrap-image at home but this problem happened just yesterday
May 21 19:11:39 <hernan_martinez> ah
May 21 19:11:43 <hernan_martinez> i know whats going on now
May 21 19:11:52 <hernan_martinez> it's trying to fetch revision 1
May 21 19:11:55 <hernan_martinez> and not the lastest
May 21 19:12:04 <hernan_martinez>  /usr/bin/env svn co -r 1 http://developer.imendio.com/svn/gconf-dbus/trunk trunk failed with signal 1,
May 21 19:12:31 <hernan_martinez> but strange.. i thought this issua was solved a few days ago.. checked buzilla back then
May 21 19:23:16 <kergoth> heh, that oestats site looks pretty sweet
May 21 19:23:44 <woglinde> hi kergoth
May 21 19:23:49 <woglinde> hi flo
May 21 19:23:54 <kergoth> hey
May 21 19:24:04 <cdbot2> * * OE Bug 4286 has been created by cliff.brake(AT)gmail.com
May 21 19:24:06 <cdbot2> * * xfonts-xorg_6.8.bb fails to build for x86
May 21 19:24:08 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4286
May 21 19:24:20 <hernan_martinez> hrw: thanks for the rm tip. it worked.. 
May 21 19:25:06 <hernan_martinez> hrw: but now i had to change my gconf-dbus_svn.bb file.. it was trying to get the first revision
May 21 19:25:26 <hrw> hernan_martinez: ha!
May 21 19:25:31 <hrw> your distro config is busted
May 21 19:25:42 <hernan_martinez> ?
May 21 19:25:47 <hernan_martinez> generic? omg
May 21 19:26:00 <hrw> so generic is busted then
May 21 19:26:26 <hernan_martinez> ok haha now gconf-value.c is not compiling
May 21 19:29:48 <hernan_martinez> hrw: looking in the bugzilla laibsch tell the guy to add sane source revs to my distro
May 21 19:30:15 <hernan_martinez> hrw: it is in the .dev thou
May 21 19:31:01 <hrw> hernan_martinez: generic distro in .dev already use sane-srcdates/sane-srcrevs
May 21 19:32:20 <hernan_martinez> hrw: yes but stable's generic.conf is missig "require conf/distro/include/sane-srcrevs.inc"
May 21 19:32:38 <dante> hi, I'm having an issue with trying to modify avahi to build the avahi-qt4 stuff.
May 21 19:32:58 <hrw> hernan_martinez: ah.. .stable one
May 21 19:33:07 <hrw> hernan_martinez: submit patch to .stable ML then
May 21 19:33:09 <Laibsch> hernan_martinez: Then you need to bug the .stable people to backport that.  Unfortunately, they don't keep up with bugzilla
May 21 19:33:15 <hernan_martinez> ahh
May 21 19:33:19 <hernan_martinez> but in bugzilla
May 21 19:33:27 <hrw> Laibsch: please stop
May 21 19:33:39 <Laibsch> hrw: stop telling the truth?
May 21 19:33:42 <hernan_martinez> ?
May 21 19:33:48 <hrw> Laibsch: stable branch maintainers have own policy
May 21 19:33:58 <hernan_martinez> ah
May 21 19:33:58 <Laibsch> Fine
May 21 19:33:58 <hrw> and they are allowed for it
May 21 19:33:59 <hernan_martinez> sorry
May 21 19:34:23 <dante> basically my problem is that it isn't finding the qtopia/qt .pc file ( as it doesn't exist in the right place even though it's been built )
May 21 19:34:37 <Laibsch> hrw: But people don't understand why stuff in bugzilla does not apply to .stable.
May 21 19:34:38 <hernan_martinez> someone asked that in the bugzilla comments for bug #4231 
May 21 19:34:47 <Laibsch> hrw: So it needs explanation
May 21 19:34:52 <hernan_martinez> humm.. didnt know that
May 21 19:35:04 <Laibsch> hernan_martinez: .stable and bugzilla are somewhat disconnected at the moment
May 21 19:35:09 <hernan_martinez> so, let me ask this.. do you guys suggest me moving to .dev ?
May 21 19:35:14 <hrw> no
May 21 19:35:20 <hernan_martinez> that was fast :)
May 21 19:35:28 <Crofton|work> hernan_martinez, what are you trying to do?
May 21 19:35:37 * hrw -> other channels as I can not stand that 'stable ignore bugzilla' crap
May 21 19:35:53 <hernan_martinez> get generic's bootstrap-image working, with pxe+nfs booting on a x86 itx
May 21 19:36:11 <Crofton|work> hernan_martinez, the obvious question is "Why not use Angstrom?"
May 21 19:36:12 <hernan_martinez> +directfb,+mplyer, with no X 
May 21 19:36:25 <Crofton|work> as that is the distro with the most support in .stable
May 21 19:37:14 <hernan_martinez> well. i am going to look for it.. thanks..
May 21 19:37:43 <Crofton|work> this is the path of least resistance
May 21 19:38:11 <Crofton|work> one day, we should have un-break generic day
May 21 19:38:20 <hernan_martinez> i didnt know about the "most .stable support" in angstrom.. i am pretty new to OE.. like 5 days 
May 21 19:38:27 <woglinde> crofton haha
May 21 19:38:35 <Crofton|work> hernan_martinez, not a problem
May 21 19:39:17 <hernan_martinez> but just to ask: doesn't stable mean: old stuff that compile for sure?
May 21 19:39:31 <woglinde> hernan_martinez right
May 21 19:39:33 <hernan_martinez> not old, i mean, frozen
May 21 19:39:45 <Crofton|work> well, it is a little more complex than that
May 21 19:39:52 <Crofton|work> we try to fix bugs
May 21 19:39:59 <Crofton|work> but not change infrastructure
May 21 19:40:10 <Crofton|work> and try to avoid random changes
May 21 19:40:37 <woglinde> hm who are the stable maintainers now?
May 21 19:40:39 <hernan_martinez> so where should I post bugs to the .stable people
May 21 19:41:22 <cyril_> hernan_martinez: it should :-/ As hrw said, feel free to submit patch to the .stable ML
May 21 19:41:45 <hernan_martinez> ok noob here: what is ML?
May 21 19:41:55 <cyril_> hernan_martinez: mailing list :)
May 21 19:42:02 <Crofton|work> the second from the top news item on www.openembedded.org has the .stable list information
May 21 19:42:31 <hernan_martinez> :) ok thanks. i am subscribing now
May 21 19:47:45 <dante> I'm thinking that bitbake isn't building qtopia for the cross compiler, because the .pc files aren't in the i686-linux staging stuff?
May 21 19:59:25 <hrw> ~summon jeremy
May 21 19:59:26 <ibot> apt takes out 20 clean, identical-looking phones, some extra hands, and pretends to be a telemarketer for a large corporation, so he gets delivered a phonelist containing jeremy's coordinates
May 21 20:07:08 <hrw> bye
May 21 20:11:08 <woglinde> bye hrw
May 21 20:18:28 <kgilmer_> er...the faq page has been hax0red
May 21 20:18:59 <kgilmer_> I'm trying to build an image against my own 2.6.19 kernel
May 21 20:19:18 <kgilmer_> i'm getting...
May 21 20:19:19 <kgilmer_> ERROR: Multiple .bb files are due to be built which each provide virtual/kernel (/home/kgilmer/dev/sandbox/oe-stable/org.openembedded.stable/packages/linux/linux_2.6.21.bb /home/kgilmer/dev/sandbox/oe-stable/org.openembedded.stable/packages/linux/linux-bug_2.6.19.2.bb).
May 21 20:19:19 <kgilmer_>  This usually means one provides something the other doesn't and should.
May 21 20:19:42 <kgilmer_> I try with "-DDD" but it doesn't tell me what needs to be provided.
May 21 20:19:47 <kgilmer_> any tips?
May 21 20:24:02 <pregier> i was just looking at the faq myself and about to point it out
May 21 20:24:25 <pregier> looks like rev. 126 might be the last good one?
May 21 20:25:12 <kgilmer_> how I can I view that version?  All I can see is how to get diffs
May 21 20:25:36 <pregier> i'm fumbling around the diffs too
May 21 20:25:57 <kgilmer_> pregier: ok, thx
May 21 20:26:01 <pregier> i can kind of see some old content at http://oe.linuxtogo.org/node/28/diff/1146/1150#builderrors
May 21 20:27:39 <kgilmer_> yeah, kind of :)
May 21 20:27:49 <pregier> if you search and then mouse over :)
May 21 20:28:03 <pregier> or select to highlight :)
May 21 20:28:20 <kgilmer_> haha
May 21 20:31:03 <hernan_martinez> bye folks
May 21 20:35:48 <cyril_> kgilmer_: hmm you could find the recipe that have PREFERRED_PROVIDER_virtual/kernel = "linux" and replace linux with "linux-bug"
May 21 20:36:25 <cyril_> with -DDD you should see which recipe is providing it
May 21 20:38:44 <kgilmer_> cyril_: thanks for the tip
May 21 20:39:04 <cyril_> kgilmer_: for which machine are you buildinf ?
May 21 20:39:18 <cyril_> kgilmer_: PREFERRED_PROVIDER_virtual/kernel is set in machine conf files
May 21 20:40:25 <kgilmer_> strange...  I tried "bitbake linux" , got that error, then did "bitbake -g linux", got the error, then back to "bitbake linux" and now it's not giving me that error
May 21 20:40:44 <kgilmer_> machine is my own, but it's based on the mx31
May 21 20:40:46 <woglinde> ????
May 21 20:40:54 <woglinde> faulty hw?
May 21 20:41:27 <cyril_> kgilmer_: so this should be in conf/machine/mx31moboard.conf
May 21 20:41:36 <kgilmer_> yeah, in my machine conf i set virtual/kernel to linux-bug
May 21 20:42:21 <kgilmer_> cyril_: yes, the only thing I changed is the console seial port and the kernel provider.
May 21 20:42:36 <kgilmer_> it seems to be building now with 2.6.19...although I'm not sure what I did to get it working.
May 21 20:42:53 <kgilmer_> woglinde: I hope not I just got this laptop :/
May 21 20:45:32 <kgilmer_> Well I'll wait to see how this plays out.  Is the mailing list or IRC better for this kind of issue?
May 21 20:58:23 <cyril_> kgilmer_: IRC. But as stated in the topic, this channel is not a distro or machine support channel! If you encounters bugs with bitbake and/or oe metadata you will get help though :)
May 21 21:02:45 <CIA-22> 03rpurdie 07org.oe.dev * rc7529018... 10/ (1 conf/bitbake.conf): bitbake.conf: Correctly export PATH variable
May 21 21:02:49 <CIA-22> 03rpurdie 07org.oe.dev * rcf7676f1... 10/ (1 classes/image.bbclass): image.bbclass: Cleanup whitespace (from poky)
May 21 21:02:54 <CIA-22> 03rpurdie 07org.oe.dev * rfe2868e9... 10/ (1 classes/image.bbclass): image.bbclass: Remove use of bbimage (from poky)
May 21 21:02:59 <CIA-22> 03rpurdie 07org.oe.dev * r5dcb3f33... 10/ (1 classes/devshell.bbclass): devshell.bbclass: Export variables used by the class (from poky)
May 21 21:04:55 <RP> bbimage finally dies :)
May 21 21:05:23 <kgilmer_> cyril_: ok, makes sense.  thanks.
May 21 21:10:06 <Crofton> should we create #generic? :) :)
May 21 21:14:12 <kgilmer_> well in my case i think the core issue is bitbake
May 21 21:14:32 <kgilmer_> as it wasn't telling me what dependencies were causing it to build two seperate kernels, even with -DDD
May 21 21:14:51 <kgilmer_> unless it was buried up farther, which is very possible, as DDD generates oodles of output.
May 21 21:15:15 <paulproteus> Does anyone know the "bitbake" command to bitbake the same sort of thing as http://downloads.openmoko.org/asu/ ?
May 21 21:15:26 <paulproteus> I used to bitbake openmoko-devel-image .
May 21 21:17:34 <woglinde> bitbbake -c fetch?
May 21 21:27:02 <paulproteus> And to list what can be built?
May 21 21:27:19 <CIA-22> 03rpurdie * r1074 10/ (4 files in 4 dirs): 
May 21 21:27:19 <CIA-22> build.py: Make sure expandKeys has been called on the data dictonary before
May 21 21:27:19 <CIA-22> running tasks fixing various strange issues (from poky). Correctly add a task
May 21 21:27:19 <CIA-22> override in the form task-TASKNAME which whilst a change in behaviour shouldn't
May 21 21:27:19 <CIA-22> matter since the original approach didn't work at all
May 21 21:34:05 <woglinde> nite
May 21 22:17:11 <cyril_> nite
May 21 22:50:46 <sakoman> Crofton: ping!
May 21 22:51:45 <Crofton> pong
May 21 22:56:18 <Crofton> sakoman, pong
May 21 22:56:43 <sakoman> did you ever resolve your avahi link issue?
May 21 22:56:50 <Crofton> maybe
May 21 22:56:52 <sakoman> I'[m getting the same thing now :-(
May 21 22:57:02 <Crofton> I think it just worked
May 21 22:57:16 <sakoman> clean build?
May 21 22:57:26 <Crofton> I think so
May 21 22:57:34 <sakoman> bummer, I fear as much
May 21 22:57:36 <Crofton> I've been working on two machine on different stuff
May 21 22:57:39 <Crofton> and lost track
May 21 22:57:52 <Crofton> I can't swear the problem is gone either
May 21 22:58:00 <sakoman> it's been a while so I guess I should try a clean build
May 21 22:58:05 <Crofton> yeah
May 21 22:58:25 <Crofton> I'll likely go have a life tonight
May 21 22:58:28 <sakoman> puts a damper on progress for a few hours :-)
May 21 22:58:32 <Crofton> yeah
May 21 22:58:34 <Crofton> frustrating
May 21 22:58:46 <Crofton> since I'm having a life, I can afford it
May 21 22:58:52 <sakoman> but having an excuse to rejoing real life is good ;-)
May 21 22:58:59 <Crofton> yeah
May 21 22:59:45 <sakoman> guess I'll go play outside for a while then!
May 21 23:00:16 <sakoman> always something to do there too
May 21 23:02:49 <Crofton> avahi just blew up one me
May 21 23:03:16 <Crofton> I need to talk with RP on how to debug this
May 21 23:17:27 <tharvey> so help me understand how to control what packages get built/installed for any given image (it 'is' the image that dictates this not the distro yes?) - ie base-image includes 'task-base-ext2' (if MACHINE_FEATURES contains ext2) - but I can't find a package called 'task-base-ext2' 
May 21 23:18:38 <NAbyss> tharvey: There may be a task that PROVIDES=task-base-ext2
May 21 23:19:56 <tharvey> I'm finding its really difficult to trace back the process of package selection and image creation.  I did not really run into a good description of these 'tasks' in the OE docs... are they classes as opposed to packages or neither?
May 21 23:20:41 <NAbyss> IIRC, those tasks are generic packages that are provided by real packages; for example, dropbear or openssh may provide the generic ssh task
May 21 23:22:06 <NAbyss> tharvey: For task-base-*, take a look at ./packages/tasks/task-base.bb - the RDEPENDS_ lines list dependencies for the given packages
May 21 23:22:28 <NAbyss> i.e. ext2 will pull in hdparm, e2fsprogs, e2fsck and mke2fs.
May 21 23:22:38 <tharvey> ah... so really to trace back why something gets built/included I need to be doing some grep's for things like PROVIDES=task-base-ext2?
May 21 23:23:00 <tharvey> ok, thats what I would figure... but then I'm at a loss for what pulls in 'everything else' in base-image
May 21 23:23:08 <NAbyss> Yeah, grep is your friend; there's a multitude of ways that things can be included via the metadata
May 21 23:23:27 <NAbyss> Bitbake does have an option to produce a dependency graph though, from memory, which may assist
May 21 23:23:55 <tharvey> in base-image.bb I see 'IMAGE_INSTALL' including ssh, package manager, feed, ext2, usbhost - but not 'system' stuff like busybox etc
May 21 23:24:03 <NAbyss> bitbake -g, AFAIK
May 21 23:24:37 <tharvey> NAbyss, yes I saw that... but haven't been able to figure out how to use graphviz to view the dot files to get a good visual
May 21 23:25:13 <NAbyss> tharvey: Busybox et al should be selected by your distro config, from what I remember
May 21 23:26:00 <tharvey> so there is a bit of a crossover regarding package selection being done in distro vs image?  or perhaps I completely misunderstand 'image' - I assumed its where you define 'what' is in your image, but perhaps it defines what type of image you have?
May 21 23:27:30 <NAbyss> tharvey: It's a bit of a fuzzy line; some things are specified by the distro, some by the image. If you look in conf/distro/, you'll see PREFERRED_PROVIDER lines for various components
May 21 23:27:32 <tharvey> docs I read talk about how 'base-image' includes network/console/flash support - yet I couldn't see how in base-image.bb any of those are included
May 21 23:28:03 <NAbyss> tharvey: Look in task-base
May 21 23:28:38 <tharvey> yes, I saw some of that... so PREFERRED_PROVIDER's are used to select which package to use if there are several that do the same thing...
May 21 23:29:12 <NAbyss> Yep; virtual/foo "packages" are used as a way to select one of various options for a given functionality
May 21 23:30:08 <tharvey> so is 'task-base' always inherently included?
May 21 23:30:49 <CIA-22> 03tmbinc 07org.oe.dreambox * r530a04cb... 10/ (1 packages/wlan-rt73 packages/wlan-rt73/wlan-rt73.bb): wlan-rt73: add ralink rt73 driver
May 21 23:30:53 <CIA-22> 03tmbinc 07org.oe.dreambox * re63a9e51... 10/ (3 files in 3 dirs): busybox-1.01: add zeroconf support
May 21 23:30:56 <CIA-22> 03tmbinc 07org.oe.dreambox * rdf468d39... 10/ (1 packages/hotplug-ng/hotplug-ng.bb): hotplug-ng: fix source date, set package version
May 21 23:31:00 <CIA-22> 03tmbinc 07org.oe.dreambox * r17528594... 10/ (3 files in 3 dirs): autofs-4.1.4: add auto.hotplug
May 21 23:31:03 <CIA-22> 03tmbinc 07org.oe.dreambox * re9689f6d... 10/ (3 files in 3 dirs): linux-dm800: build autofs modules
May 21 23:31:07 <CIA-22> 03tmbinc 07org.oe.dreambox * r8a9fbb7e... 10/ (3 files in 3 dirs): initscripts-opendreambox: initialize automount, load some more modules by default
May 21 23:31:10 <CIA-22> 03tmbinc 07org.oe.dreambox * r415ed825... 10/ (1 conf/machine/dm800.conf): dm800.conf: install support for autofs,vfat
May 21 23:31:14 <CIA-22> 03tmbinc 07org.oe.dreambox * r6400b449... 10/ (1 packages/dreambox/dreambox-dvb-modules.bb): dreambox-dvb-modules: driver updates
May 21 23:31:17 <CIA-22> 03tmbinc 07org.oe.dreambox * rc1f08fc8... 10/ (1 packages/images/dreambox-image.bb): dreambox-image: install hotplug,autofs. WLAN support for dm7025 and dm800
May 21 23:33:41 <tharvey> ahhh... I found what I'm missing - 'task-boot' which includes kernel, base-files, busybox etc
May 21 23:34:13 <tharvey> so I'm a little unclear on tasks vs packages.  Why wouldn't task-boot be a package?
May 21 23:35:14 <Tartarus> tasks are meta packages
May 21 23:35:34 <NAbyss> The task-packages don't really provide anything by themselves; they tend to be used as a branching point for a distro etc. to include a set of items - tasks are still packages, but don't provide a software package themselves
May 21 23:37:50 <tharvey> I can see how task-packages can be thought of as 'generic' but it seems to me they 'do' provide packages... several of them vs a single package.  ie, look at packages/tasks/task-boot.bb which I'm guessing about every image must include?
May 21 23:40:23 <tharvey> Tartarus, meta-packages meaning they reference other packages kind of like 'package sets'?
May 21 23:42:13 <NAbyss> tharvey: They just link to other packages as dependencies, rather than including the build instructions themselves
May 21 23:42:55 <tharvey> ok, I understand
May 22 00:23:53 <CIA-22> 03tmbinc 07org.oe.dreambox * r5e80332f... 10/ (1 packages/enigma2/enigma2.bb): enigma2: depend on libdreamdvd
May 22 00:23:57 <CIA-22> 03tmbinc 07org.oe.dreambox * r7b03a0ff... 10/ (1 conf/machine/dm800.conf): dm800.conf: add required fat kernel module
**** ENDING LOGGING AT Thu May 22 02:59:57 2008