**** BEGIN LOGGING AT Fri Dec 10 02:59:57 2010
Dec 10 03:02:05 <kergoth> we'll have to prep to get it merged in the near future
Dec 10 03:02:11 <kergoth> (the separate branch, that is)
Dec 10 03:02:29 <foerster> yea
Dec 10 03:02:43 <foerster> most of the commits can probably be squashed
Dec 10 03:04:09 <kergoth> yeah, likely 1) separate into the process server, 2) keyboard interrupt fixes, 3) cache load progress, ..
Dec 10 03:04:24 <kergoth> merge into those
Dec 10 03:05:20 <foerster> ok. How about your latest changes -- just leave in master and rebase separate branch onto it?
Dec 10 03:05:45 <kergoth> yeah, thats what i was planning on doing
Dec 10 03:05:51 <kergoth> since they're fairly independent
Dec 10 03:06:06 <foerster> we still have keyboardint in cooker
Dec 10 03:06:10 <foerster> i'll take that out
Dec 10 03:06:19 <kergoth> ah, yeah, forgot there were still remnants
Dec 10 03:06:25 <foerster> (remnant from rebasing onto master i suppose)
Dec 10 03:07:09 <foerster> i'll try to get the separate branch cleaned up into distinct changes as mentioned
Dec 10 03:07:39 <foerster> might not be til some time this weekend 
Dec 10 03:31:36 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * r5374097752 10bitbake.git/lib/bb/ (build.py utils.py): 
Dec 10 03:31:36 <CIA-101> build: use bb.process instead of os.system
Dec 10 03:31:36 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 03:31:40 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * r4262c26d36 10bitbake.git/lib/bb/utils.py: 
Dec 10 03:31:40 <CIA-101> utils: fix calls to close() in the lock/unlock functions
Dec 10 03:31:40 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 03:31:43 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rf99ee4680c 10bitbake.git/lib/bb/ (build.py utils.py): 
Dec 10 03:31:43 <CIA-101> build: use a contextmanager for locks
Dec 10 03:31:43 <CIA-101> Also don't bother passing logfile to exec_func_python, at least until we start
Dec 10 03:31:43 <CIA-101> adding the logfile as a file handler to the bitbake logger.
Dec 10 03:31:44 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 03:31:52 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rc63e55564a 10bitbake.git/lib/bb/process.py: 
Dec 10 03:31:52 <CIA-101> process: add subprocess-based bits
Dec 10 03:31:52 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 03:35:33 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * r51076c3737 10bitbake.git/lib/bb/build.py: 
Dec 10 03:35:33 <CIA-101> build: fix remnant access of logfile in exec_func_python
Dec 10 03:35:33 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 03:43:44 <foerster> kergoth: added preliminary support for LogRecord in runningbuild (works in goggle)
Dec 10 03:43:48 <kergoth> nice
Dec 10 03:43:54 <foerster> too many messages are printed straight to the screen though
Dec 10 03:43:58 <foerster> instead of sent as log messages
Dec 10 03:44:24 <kergoth> the problem is python functions, they still have access to stdout right now.  i'm thinking we should just kill it entirely
Dec 10 03:44:30 <foerster> soon
Dec 10 03:44:50 <kergoth> either that or we send it to bb.plain, but there's no real excuse for doing that, from python you can use teh logging / messaging functions
Dec 10 03:45:56 <foerster> https://github.com/foerster/bitbake/commit/17691054acb54f234d48385d917803317b6f2bbc
Dec 10 03:46:11 <foerster> ok, that's all for tonight.  baby gets up early
Dec 10 03:47:30 <kergoth> night
Dec 10 06:27:07 <JaMa|Off> khem: maybe there is one more gcc-4.5 issue, my u-boot doesn't realy start kernel (only reads it) when built with gcc-4.3, when I rebuild same u-boot sources with 4.2.1 it works OK.. trying 4.3 now
Dec 10 06:31:48 <khem> JaMa|Off: k
Dec 10 06:32:12 <khem> JaMa|Off: we can look into it if you have some pointers
Dec 10 06:35:09 <JaMa|Off> khem: I'll try to narrow it a bit more first
Dec 10 06:35:28 <JaMa|Off> khem: now I can confirm that angstrom-2008.1 toolchain is OK too
Dec 10 06:36:36 <JaMa|Off> I would try to upgrade binutils to 2.20.1 as sane-toolchain has first
Dec 10 06:36:42 <JaMa|Off> then gcc to 4.4
Dec 10 06:37:05 <JaMa|Off> and then I'll let you know where it broke
Dec 10 07:31:27 <eFfeM_work> gm
Dec 10 07:42:54 <mckoan> good morning
Dec 10 07:45:20 <lostincake> greetings
Dec 10 07:56:35 <khem> eFfeM_work: hey I committed a gcc fix that could help your case with mediatomb
Dec 10 07:56:38 <khem> try it out 
Dec 10 07:57:57 <eFfeM_work> khem, will do, just did a pull from head and rebuilt
Dec 10 07:59:46 <B_Lizzard> Why --disable-static in libsdl-x11-1.2.14?
Dec 10 07:59:57 <B_Lizzard> All other sdl libraries build static libs
Dec 10 08:22:11 <hrw> orning
Dec 10 08:22:38 <hrw> khem: thanks for tracking gcc bugs and regressions
Dec 10 08:23:51 <ka6sox> morning hrw
Dec 10 09:46:36 <JaMa|Wrk> khem: fyi u-boot with gcc-4.4.4 still works, next I'll try gcc-4.5 without linaro patches
Dec 10 09:47:10 <JaMa|Wrk> hrw: no known issues with u-boot and linaro gcc-4.5 patches? ^
Dec 10 09:48:08 <JaMa|Wrk> hrw: it's not hanging at mmc init like this one https://bugs.launchpad.net/gcc-linaro/+bug/616614
Dec 10 09:48:48 <hrw> JaMa|Wrk: now I have only one device running 24/7 with uboot - pandaboard. and it still uses old 2010.09-rc uboot
Dec 10 09:50:05 <hrw> JaMa|Wrk: and that bug needs update as toolchain changed in meantime
Dec 10 09:54:46 <JaMa|Wrk> I have it with even older u-boot :/ u-boot-nokia900-2010.06+gitr0+bd2313078114c4b44c4a5ce149af43bcb7fc8854-r67.bin
Dec 10 09:55:05 <JaMa|Wrk> not yet in OE, because of this issue..
Dec 10 12:26:45 <tasslehoff> I've compiled a uImage and a cpio.gz, but can OE assist me in creating a kernel *with* an initramfs?
Dec 10 12:29:41 <grund> tasslehoff: you're doing it to have that initramfs be the final rootfs, right?
Dec 10 12:30:37 <tasslehoff> grund: exactomundo :)
Dec 10 12:30:42 * tasslehoff has a plan
Dec 10 12:30:56 <grund> yes, it works quite nice
Dec 10 12:31:59 <grund> your recipe is building the cpio.gz for your rootfs?
Dec 10 12:32:47 <tasslehoff> grund: yes, I have given cpio.gz as one of the IMAGE_FSTYPES in local.conf
Dec 10 12:33:03 <tasslehoff> OE gave me a 3.1M uImage and a 40M cpio.gz
Dec 10 12:33:55 <grund> us the minimal-image as a starting point
Dec 10 12:36:04 <grund> you can put the IMAGE_FSTYPES right in the .bb, helpful if you don't want every image to be a ramdisk
Dec 10 12:37:35 <tasslehoff> grund: I've been creating and using a tar.bz2 rootfs for some months, so my task now is just figuring out how to get an initramfs instead.
Dec 10 12:37:50 <grund> ahh
Dec 10 12:39:15 <grund> am I missing something? isn't that that cpio.gz your initramfs?
Dec 10 12:40:32 <tasslehoff> grund: yes it is, but on #beagle I was adviced to build a kernel that includes the initramfs, so I just wanted to check if OE could do that.
Dec 10 12:45:10 <grund> ok, I see now
Dec 10 12:45:58 <tasslehoff> grund: Guess I could very well have them separated. I'm just unsure how to decide on addresses and stuff when loading kernel and initramfs to ram from u-boot
Dec 10 12:47:30 <grund> I'm not sure about the built in. You'd have to have the kernel recipe point at the rootfs working directory 
Dec 10 12:47:38 <grund> we do the separate file
Dec 10 12:48:21 <tasslehoff> grund: ok. think I'll try that to begin with as well
Dec 10 12:48:44 <grund> and use mkimage to make it easier on u-boot
Dec 10 12:48:47 <grund> ${STAGING_BINDIR_NATIVE}/mkimage -A arm -O linux -T ramdisk -C gzip \
Dec 10 12:48:47 <grund> +        -a 0x0 -e 0x0 -n uInitramfs -d ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.uimage
Dec 10 12:49:13 <grund> (oops, drop that + out of there)
Dec 10 12:49:39 <grund> then depending on the size of your kernel, load the second uimage after the first
Dec 10 12:50:12 <grund> we do 0x81600000 or 0x83000000
Dec 10 12:50:33 <grund> and then bootm 0x80000000 0x83000000
Dec 10 12:54:12 <tasslehoff> let's see... that creates a uImage from the cpio.gz?
Dec 10 12:57:47 <grund> tasslehoff: that converts the cpio.gz to a u-boot binary, little easier on the boot command
Dec 10 12:58:08 <grund> you're already getting the uImage and cpio.gz, right?
Dec 10 12:58:13 <ericben> good morning
Dec 10 12:58:41 <tasslehoff> grund: yes, so those instructions take me a long way. thanks a lot
Dec 10 12:59:17 <grund> np
Dec 10 13:21:24 <ant_work> tasslehoff: if you define an INITRAMFS_IMAGE = "initramfs-xyz-image" this will be embedded in kernel
Dec 10 13:21:58 <ant_work> though, I've never seen a > 40MiB kernel..
Dec 10 13:22:14 <ant_work> is ok for small images
Dec 10 13:22:37 <tasslehoff> ant_work: yeah.
Dec 10 13:22:55 <ant_work> we actualy have a 54KiB age
Dec 10 13:23:01 <ant_work> *image
Dec 10 13:23:20 <ant_work> I think is recoed in OE ;)
Dec 10 13:23:29 <tasslehoff> hehe
Dec 10 13:24:28 <ant_work> cpio.lzma is 30% smaller than cpio.gz, in our tests
Dec 10 13:25:51 <tasslehoff> I'm exploring ways to have a read-only rootfs. Initramfs and Unionfs are the suggestions I have so far.
Dec 10 13:43:49 <mems> Hey guys.  bitbake is telling me that "multiple .bb files are due to be built which each provide virtual/psplash", but I can't work out exactly what's wrong.
Dec 10 13:47:42 <ant_work> mems: is nothing serious, stll there are some virtual providers issues. Note that anyway the superfluous package will be built but not installed.
Dec 10 13:48:38 <mems> ant_work: hmm, ok.  makes me feel like I'm not in control ;)
Dec 10 13:48:49 <ant_work> awaiting a fix in OE soon, you can 'fix' it from your side expliciting the PREFERRED_PROVIDER in your local.conf
Dec 10 13:49:16 <mems> yea, I've got a PREFERRED_PROVIDER for it in my local.conf
Dec 10 13:49:21 <mems> the warning still comes up though
Dec 10 13:49:25 <mems> this is expected?
Dec 10 13:49:37 <ant_work> how did you do it?
Dec 10 13:50:34 <mems> PREFERRED_PROVIDER_virtual/psplash = "psplash-sr"
Dec 10 13:50:44 <mems> (my replacement is called "psplash-sr")
Dec 10 13:52:01 <mems> and I have copied the psplash recipe into my own recipe tree, calling it psplash-sr.bb
Dec 10 13:52:09 <kergoth> morning
Dec 10 13:52:13 <mems> (sorry, psplash-sr_svn.bb)
Dec 10 13:52:32 <ant_work> mems: he he .. I found it .. http://patchwork.openembedded.org/patch/195/
Dec 10 13:53:29 * mems reads
Dec 10 13:56:07 <mems> hmm, ok, those guys discussing that patch don't actually resolve on a solution I think
Dec 10 14:00:42 <ant_work>  >awaiting a fix in OE soon, you can 'fix' it from your side... ^^^
Dec 10 14:00:48 <ant_work> ;)
Dec 10 14:04:00 <ant_work> btw nowaday distro are setting  SPLASH ?= '${@base_contains("MACHINE_FEATURES", "screen", "psplash", "",d)}'
Dec 10 14:04:16 <mems> yup, I've just found that in org.openembedded.dev ;)
Dec 10 14:04:29 <mems> investigating whether I want to port that into our stable branch
Dec 10 14:04:57 <kergoth> JaMa|Wrk: good catch on the revision key regression -- i can't wait for the fetcher rewrite..
Dec 10 14:05:49 <kergoth> did everyone read http://bec-systems.com/site/755/yocto-and-openembedded ?
Dec 10 14:05:54 <kergoth> please do so if you haven't
Dec 10 14:10:00 <mems> speaking of stable branches, is stable/2009 still the "most recent" stable branch, or has another one developed?
Dec 10 14:10:28 <kergoth> as far as i know it is, but it depends on what you're trying to accomplish
Dec 10 14:10:43 <foerster> kergoth: one more piece of fun https://github.com/foerster/bitbake/commit/9ea41409ba7f83ec13a9739c15e0920a2c0deee8
Dec 10 14:10:51 * foerster has to get back to work work now :)
Dec 10 14:10:53 <mems> kergoth: reasonably infrequent breakage ;)
Dec 10 14:10:54 <kergoth> there's also the release version of OE, but which is at  a fixed position, no more fixes going forward, adn there's the ongoing testing branch
Dec 10 14:11:27 <mems> are the releases tagged in the repo?
Dec 10 14:11:50 <CIA-101> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r369c3002ab 10openembedded.git/recipes/linux/ (15 files in 2 dirs): 
Dec 10 14:11:50 <CIA-101> linux-omap 2.6.37rc: bump to rc5
Dec 10 14:11:50 <CIA-101> Signed-off-by: Koen Kooi <koen@beagleboard.org>
Dec 10 14:12:32 <kergoth> foerster: cool, thanks for the fixes.  up next (in addition to the ^C in bin/bitbake thing) we need to make *absolutely certain* that log messages / errors / exceptions seen early in the startup are visible to the user -- its still occasionally possible to run bitbake and have it silently return -- going to revisit how i handle the log handlers today, and likely rework bb.event to stop the worker_pid and ui crap in favor of registering handlers 
Dec 10 14:12:32 <kergoth> he events
Dec 10 14:12:39 * kergoth makes a todo list for the day
Dec 10 14:12:40 <kergoth> mems: yep
Dec 10 14:12:46 <ant_work> kergoth: needs some discussion but imho what is blocking OE from picking each new Poky's core-improvement?
Dec 10 14:13:00 <ant_work> we have people with enough skillz here too
Dec 10 14:13:03 <kergoth> ant_work: not sure what you mean.  i'm already syncing poky's bitbake upstream
Dec 10 14:13:13 <kergoth> syncing poky's metadata with OE makes no sense until the yocto decision is made
Dec 10 14:13:13 <ant_work> not bitbake, OE core
Dec 10 14:13:19 <kergoth> because OE may very well base upon poky as its core
Dec 10 14:13:26 <kergoth> so any work there could very well be wasted
Dec 10 14:13:37 <ant_work> yes, see my point
Dec 10 14:14:08 <kergoth> *today* a voting period is starting to grant the board the power to make the call with the tsc's guidance
Dec 10 14:14:10 <ant_work> let say we could have own toolchain and follow behind them
Dec 10 14:14:22 <ant_work> I see
Dec 10 14:14:57 <ant_work> kergoth: sooner or later they will stop to spend time on old hw (read old arm CPU)
Dec 10 14:14:59 <foerster> kergoth: for development, i put the entire bin/bitbake in try/except to catch anything that dies  - that's proven useful here.
Dec 10 14:15:02 <kergoth> ant_work: if we do base on them, the idea is poky would be the stable core that we build upon -- another way to put it would be us *using* them, the same way we use bitbake -- OE would consist of layers built upon the poky layers
Dec 10 14:15:05 <ant_work> linaro already did
Dec 10 14:15:26 <ant_work> kergoth: right
Dec 10 14:15:39 <ant_work> ab-using them
Dec 10 14:15:44 <kergoth> foerster: nice, that is useful.  in *theory* the 'uncaught exception' handler should work, but it doesn't appear to be
Dec 10 14:16:08 <kergoth> ant_work: imo one of poky's biggest advantages, in addition to the pool of developers being contributed by yocto member companies, is the development model
Dec 10 14:16:19 <kergoth> using a pull model almost guarantees the more stable core
Dec 10 14:16:22 <ant_work> nod
Dec 10 14:16:23 <foerster> kergoth: that's how I figure out what's broken in the various UIs - I catch the exceptions they're throwing and then go fix
Dec 10 14:16:31 <kergoth> but we don't want OE to move that way, because it would sacrifice our flexibility and openness a bit
Dec 10 14:16:36 <ericben> summary of poky/oe : http://bec-systems.com/site/755/yocto-and-openembedded
Dec 10 14:16:46 <kergoth> ericben: yeah :) its a nice writeup
Dec 10 14:16:55 <kergoth> LWN should have an article out shortly about it too
Dec 10 14:16:58 <kergoth> hopefully today
Dec 10 14:17:32 <kergoth> everyone needs to read both, ideally, to make sure everyone understands what exactly yocto is
Dec 10 14:18:28 <ant_work> kergoth: I'm not sure the lack of review for pending patches is due to lazyness
Dec 10 14:18:44 <ant_work> people are usually much busy in Q4
Dec 10 14:19:08 <ant_work> the, khem asked for a slow-down in sight of a 'release'
Dec 10 14:19:13 <kergoth> i don't think its laziness, its just the nature of the beast -- without going *through* people to get into the repo, some things are going to end up in without review, there's no helping that.  we can try, but..
Dec 10 14:19:25 <ericben> I don't think it's lazyness it's that there are so many areas in OE that peoples can't handle avery area of the thing
Dec 10 14:19:51 <kergoth> ericben: personally, 90% of the patches that hit my inbox get muted/archived, because they're to things i just don't know anything about or care about
Dec 10 14:19:55 <kergoth> i'm sure i'm not the only one in that boat
Dec 10 14:20:06 * cbrake is in that boat
Dec 10 14:20:15 <kergoth> of course, poky's metadata is so much smaller that its easier for the maintainers to have a high level grasp of everything they have to review
Dec 10 14:20:27 <ant_work> imho the ML is hogged by too many commits
Dec 10 14:20:31 <ericben> of course. See micro distro : it was broken and there seems to be 1 user of it !
Dec 10 14:20:33 <kergoth> so, its not that i think oe's workflow is "bad" necessarily, its just two different ways of working
Dec 10 14:20:40 <ant_work> it was better with bugzilla/ML/patchwork
Dec 10 14:21:16 <eFfeM_work> khem, gcc patch failure on head (everything freshly pulled) failing patch is gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch; see http://pastebin.ca/2015568
Dec 10 14:21:16 <ant_work> bitrotting bugzilla was a bad decision
Dec 10 14:21:54 <ericben> eFfeM_work: strange it builds fine here
Dec 10 14:22:13 <cbrake> bugzilla seems to need someone to watch it, assign bugs to people, find volunteers to work on things, etc
Dec 10 14:22:32 <Crofton|work> assigning bugs to people without talking to them is a bad idea ....
Dec 10 14:22:33 <cbrake> the same could probably be said for patchwork
Dec 10 14:22:33 <eFfeM_work> ericben: dev head? I did a fresh git pull; this was on our autobuilder which builds really from scratch
Dec 10 14:22:35 <ant_work> sure, but having a huge ML won't help
Dec 10 14:22:41 <eFfeM_work> cbrake: are we starting wiht testing branch again ?
Dec 10 14:22:47 <ericben> eFfeM_work: head of yesterday
Dec 10 14:22:54 <cbrake> eFfeM_work: yikes, its Fri
Dec 10 14:22:58 <Crofton|work> heh
Dec 10 14:23:02 <cbrake> eFfeM_work: yes, the plan is to restart it this week
Dec 10 14:23:06 * cbrake gets busy ...
Dec 10 14:23:10 <eFfeM_work> cbrake: TGIF
Dec 10 14:23:21 <ant_work> anyway, we all know THE pull-model of reference: linux kernel
Dec 10 14:23:26 <Crofton|work> cbrake, do not rush, I need to push an i2c-tools fix
Dec 10 14:23:52 <cbrake> Crofton|work: ok, let me know
Dec 10 14:26:22 <eFfeM_work> ant_work: ML has indeed quite some patches, underlying cause is probably lack of recipe ownership
Dec 10 14:26:25 <Crofton|work> ant_work, you just became an ev member right?
Dec 10 14:26:30 <foerster> kergoth: uncaught exception handler is using logger - but nothing in bin/bitbake handles the messages.  Maybe just add a handler to dump the messages in bin/bitbake?
Dec 10 14:26:30 <ant_work> kergoth: anyway, we should have a separate ring of security for commits touching the core/toolchain
Dec 10 14:26:48 <Crofton|work> once again, divide number of recipes by active community members
Dec 10 14:27:06 <ant_work> Crofton|work: yep
Dec 10 14:27:16 <Crofton|work> did you get added to the members list?
Dec 10 14:27:41 <ant_work> seems not
Dec 10 14:27:53 <ant_work> still 34 items
Dec 10 14:27:55 <Crofton|work> it is not high traffic
Dec 10 14:28:05 <ant_work> not big issue
Dec 10 14:28:17 <kergoth_> foerster: if you see bb.event, you'll note that it uses atexit to ensure that the ui_queue of events is dumped on exit if its not empty, and the LogHandler which gets added redirects log messages to bb.event, and if bb.event gets events before the ui is started, they go into ui_queue ;)
Dec 10 14:28:46 <ant_work> eFfeM_work: sure, ownership... is like geting married ;)
Dec 10 14:28:48 <kergoth_> a tad unnecessarily complex...
Dec 10 14:29:29 * otavio ponders if people is planning a "migration path" for users from "release"
Dec 10 14:30:14 <Crofton|work> for example, today I won i2c-tools because it makes my life painful
Dec 10 14:30:30 <Crofton|work> going forward Iwill jsut watch to make sure people do not break it again though :)
Dec 10 14:30:50 <eFfeM_work> ant_work: I've mentioned this before, and I know some people disagree with this but I feel we have too much old cruft around that no one cares about, and some devs just seem to create new recipes without cleaning up or maintaining the old ones. 
Dec 10 14:31:09 <eFfeM_work> Crofton|work: congratulations on your win ;-)
Dec 10 14:31:45 <kergoth_> foerster: that queue is necessary to ensure that events fired from the server before the UI comes up are held somewhere -- but we should just be able to redirect those into the event_queue instead, since it has its lovely feeder thread sending the bits along..
Dec 10 14:31:52 <kergoth_> foerster: yet another area that's simplified by the separation
Dec 10 14:32:32 <foerster> kergoth_: right.  
Dec 10 14:33:02 <kergoth_> of course, bin/bitbake could always set up its own stream handler and formatter to send messages to the console, but really the ui should be doing all of that..
Dec 10 14:33:19 <foerster> well, the problem is when the UI throws an exception
Dec 10 14:33:24 <foerster> which is sometimes the case early one
Dec 10 14:33:49 <foerster> s/one/on/
Dec 10 14:34:13 <foerster> having one last safeguard in bin/bitbake seems nice to catch any startup errors
Dec 10 14:34:59 <kergoth_> well, let's go ahead and kill the uncaught exception handler method entirely, do your try/except as you suggest and send it to stderr
Dec 10 14:35:05 <kergoth_> definitely simplifies that aspect
Dec 10 14:36:11 <foerster> kergoth_: i'll let you do that for now.  I have to work on integrating gearman library into my app :)
Dec 10 14:36:16 <kergoth_> we still need to just rethink all the exception handling everywhere in bitbake
Dec 10 14:36:21 <kergoth_> sys.exit is still overused
Dec 10 14:36:46 <kergoth_> but we still need a clean way to show a traceback for *certain* exceptions, but only a pretty m essage and exit in other circumstances
Dec 10 14:36:52 * kergoth_ isn't very good with exception handling yet
Dec 10 14:37:00 <kergoth_> hehe, havef fun
Dec 10 14:37:03 * foerster isn't good with python, period ;)
Dec 10 14:37:21 <CIA-101> 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r48e6a06337 10openembedded.git/recipes/i2c-tools/i2c-tools_3.0.2.bb: 
Dec 10 14:37:21 <CIA-101> i2c-tools : Stage i2c-dev.h header as i2c-dev-user.h.
Dec 10 14:37:21 <CIA-101> Thanks to John Faith for suggesting this approach on the ML. The problem is
Dec 10 14:37:21 <CIA-101> i2c-tools overwrites the header staged by the kernel. This breaks programs
Dec 10 14:37:21 <CIA-101> that depend on the kernel header.
Dec 10 14:37:24 <kergoth_> its always a learning experience, with any language :)
Dec 10 14:37:34 <kergoth_> i've been using it for years now and i still learn new things on a weekly basis, i swear
Dec 10 14:37:55 <foerster> before this, I used it for a grand total of maybe a week
Dec 10 14:38:01 <foerster> luckily, the basics are very simple
Dec 10 14:38:28 * kergoth_ nods
Dec 10 14:39:05 <kergoth_> i think what's taken me the longest is figuring out what's "pythonic" -- stopping tendencies to use, say, C or C++ like constructs in python instead of native mechanisms
Dec 10 14:39:31 <foerster> synchronous gearman worker = cake.  aynchronous = fml.  damnit.
Dec 10 14:39:37 <kergoth_> :(
Dec 10 14:39:40 * kergoth_ reboots
Dec 10 14:42:56 <CIA-101> 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r9d138846f9 10openembedded.git/recipes/i2c-tools/i2c-tools_3.0.2.bb: i2c-tools : Bump PR after changes to header file staging.
Dec 10 14:49:50 <eFfeM_work> cbrake: nice writeup on yocto and openembedded, thanks; ericben, thanks for bringing this to my attention
Dec 10 14:51:47 <JaMa|Wrk> kergoth_: will you revert that fetcher _revision_key change?
Dec 10 14:52:21 <kergoth_> JaMa|Wrk: yeah, will do for now, we can revisit
Dec 10 14:52:40 <JaMa|Wrk> kergoth_: I don't think it's actually used in OE metadata and if fetcher rewrite is planned then it should be resolved there
Dec 10 14:53:20 * kergoth_ nods, good point
Dec 10 14:53:34 <kergoth_> JaMa|Wrk: the fetcher rewrite is in yocto's 1.0 plan, on their wiki
Dec 10 14:53:43 <kergoth_> richard is planning on taking it on, i assume in the sprint the plan shows it in
Dec 10 14:53:59 * JaMa|Wrk still has to fix his persistend db :/
Dec 10 14:54:21 <JaMa|Wrk> <- wrong time to rebuild from scratch hits him again..
Dec 10 14:54:54 * kergoth_ really dislikes the fact that autorev, etc exist at all -- better to use srctree if you're doing development, and lock it down if you don't
Dec 10 14:55:03 <kergoth_> s/don't/aren't/
Dec 10 14:55:11 * Crofton|work agrees with kergoth 
Dec 10 14:56:17 <kergoth_> oh, that srctree patch on the list -- looks solid to me
Dec 10 14:56:31 <kergoth_> when we switched it from exec_task to exec_func, we forgot that exec_task is what creates stamps :P
Dec 10 14:57:25 <foerster> kergoth: see item 2 :)  https://wiki.pokylinux.org/wiki/Yocto_1.0_Schedule#Sprint_B_.28closes_Jan_07.2C_11:59pm_PDT_--_pull_request_sent.2C_initially_reviewed.29
Dec 10 14:58:32 <kergoth_> hehe, yeah, richard wanted to work on that, and then i went and stole it from him.. oops ;)
Dec 10 14:58:38 <foerster> nice
Dec 10 14:58:50 <kergoth_> the fetcher rewrite could be fun too though, its always nice to take a crappy api and make it better
Dec 10 14:59:15 <foerster> i looked into the fetcher for a few minutees, and quickly bailed :)
Dec 10 14:59:25 <kergoth_> i don't blame you
Dec 10 14:59:41 <foerster> I wanted a way to get info from my package's git repo during configure
Dec 10 14:59:50 <foerster> found some hack way somebody was using, seems to work
Dec 10 15:02:04 <RP> kergoth: the fetcher stuff is not fun
Dec 10 15:02:19 <RP> kergoth: I've tried to improve that code at least twice so far :/
Dec 10 15:02:47 <kergoth_> ouch :(
Dec 10 15:03:16 <kergoth_> of course, a simple version is easy, its the corner cases that are problematic -- but what else is new, that's usually the case
Dec 10 15:04:06 <ant_work> RP: there is no two without three, and the four comes by itself ;)
Dec 10 15:05:07 <RP__> kergoth_: The fetcher is a set of cornercases ;-)
Dec 10 15:06:12 * kergoth_ ponders
Dec 10 15:08:36 <kergoth_> RP__: damnit, i thought i had it, but i can't find that email you sent about the fetcher rewrite, do you have a link, or can you forward it?
Dec 10 15:09:30 * kergoth_ mutters
Dec 10 15:10:22 <RP> kergoth_: https://lists.yoctoproject.org/pipermail/poky/2010-November/000102.html ?
Dec 10 15:10:41 <kergoth_> thanks
Dec 10 15:11:51 <kergoth_> RP: thoughts on killing AUTOREV? as i mention above, i'm personally of the opinion that for development, srctree is a better fit, or something like it, and for everything else it should be locked down -- killing it would definitely simplify things
Dec 10 15:11:58 <RP__> kergoth_: In fixing up some bits of bitbake, bluelightning has a couple of suggested changes I'd like to run by you
Dec 10 15:12:08 <kergoth_> okay, sounds good
Dec 10 15:12:21 <RP__> kergoth_: Firstly, adding an expand true/false option to getVarFlag 
Dec 10 15:13:08 <RP__> kergoth_: The other is adding a vardepsexclude flag to variables to allow them to exclude dependencies from the hashes
Dec 10 15:13:38 <RP__> kergoth_: Also there were the emails on the Poky list about having setVar a special case of setVarFlag - did you see those?
Dec 10 15:13:42 <kergoth_> an expand flag could be useful in a few different places.. there are multiple flags we use that we need expanded.  e.g. lockfiles, dirs, ...
Dec 10 15:14:09 <RP__> kergoth_: It standardises the API a bit which I think is a good thing
Dec 10 15:15:09 <kergoth_> i like that from the persective of consolidating the logic.  conceptually, the whole implementation of value vs flags feels a bit ugly to me, the use of 'content' and all, meh, but we can revisit that in a future bb.data refactoring or creation of a recipe class, if need be
Dec 10 15:16:57 <kergoth_> vardepsexclude seems conceptually sane -- its just the other side of the variable local version of the blacklist/whitelist, really
Dec 10 15:17:27 <kergoth_> so +1 on all of those for right now
Dec 10 15:17:39 <RP__> kergoth_: agreed and thanks
Dec 10 15:17:48 <bluelightning> kergoth_: cheers
Dec 10 15:18:06 <kergoth_> does https://github.com/kergoth/bitbake/commit/53ec482 look reasonable sane to you guys?
Dec 10 15:18:07 <RP__> kergoth_: We'll push into poky and then we can feed into bitbake once we're proven they don't break things :)
Dec 10 15:18:14 <kergoth_> yeah, sounds good to me
Dec 10 15:18:26 <kergoth_> i haven't had a chance to look at the new pseudo fork bits yet
Dec 10 15:18:40 <RP__> kergoth_: Those are still a WIP and don't quite work yet :(
Dec 10 15:18:48 <RP__> Close to working but something in checksums isn't happy
Dec 10 15:18:58 * RP__ needs a 36 hour day
Dec 10 15:19:24 * RP__ taps foot waiting for github
Dec 10 15:19:36 <kergoth_> ah
Dec 10 15:19:42 <kergoth_> heh, agreed (re: 36 hours)
Dec 10 15:20:06 <bluelightning> indeed
Dec 10 15:20:08 <kergoth_> (ignore the change to the import error messages, that shouldn't be in there)
Dec 10 15:20:08 <CIA-101> 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r39530eb597 10openembedded.git/recipes/i2c-tools/i2c-tools_3.0.2.bb: 
Dec 10 15:20:08 <CIA-101> i2c-tools : Remove legacy staging.
Dec 10 15:20:08 <CIA-101> Thanks for pointing this out Koen.
Dec 10 15:21:29 <RP__> kergoth_: That API is much nicer, yes
Dec 10 15:22:09 <pb_> morning kergoth_
Dec 10 15:22:10 <kergoth_> k, thanks, just wanted a second set of eyes to make sure i wasn't completely insane
Dec 10 15:22:12 <kergoth_> morning pb_ 
Dec 10 15:23:27 <kergoth_> RP__: notice how it has the factory that extracts the metadata bits and constructs it from that, rather than the classes being bound to the metadata -- i think fetch should work in a similar way for its configuration options
Dec 10 15:26:43 <RP> kergoth_: right, something along those lines would be nicer
Dec 10 15:26:58 <Crofton|work> cbrake, I think I am done screwing around
Dec 10 15:35:28 <CIA-101> 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rbbd15964c3 10openembedded.git/contrib/oe-stylize.py: 
Dec 10 15:35:28 <CIA-101> oe-stylize: remove trailing newline when printing unknown variable/routine
Dec 10 15:35:28 <CIA-101> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Dec 10 15:47:30 <mems> hey, the handhelds.org cvs is down and my OE build is trying to grab "updates-alternatives-cworth" from it, anyone know of a mirror?
Dec 10 15:54:13 <mems> does anyone even know what this package does?
Dec 10 15:54:41 <kergoth_> yes, the same thing update-alternatives does in debian, and you won't get a functional image without it :)
Dec 10 15:55:18 <mems> ok, any idea how I can get hold of the source for this, given that the cvs server it references is down?
Dec 10 15:55:54 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * r411b808b81 10bitbake.git/lib/bb/fetch/git.py: 
Dec 10 15:55:54 <CIA-101> Revert "bitbake/git.py: Make sure different branches can have different revisions without triggering build count increases"
Dec 10 15:55:54 <CIA-101> Per Martin Jansa, this breaks compatibility. We can revisit in the future,
Dec 10 15:55:54 <CIA-101> likely during the fetcher rewrite.
Dec 10 15:55:54 <CIA-101> This reverts commit f3292fa11723c748ef1b4270384abf6d586a822e.
Dec 10 15:58:14 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * r20929afdd8 10bitbake.git/lib/bb/build.py: 
Dec 10 15:58:14 <CIA-101> build: kill stdout in python functions
Dec 10 15:58:14 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 15:58:24 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * ree1cce6ab2 10bitbake.git/lib/bb/ (build.py msg.py ui/knotty.py): 
Dec 10 15:58:24 <CIA-101> build: send logging messages to the log file for python functions
Dec 10 15:58:24 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 15:58:29 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * r240d4a7ae8 10bitbake.git/bin/bitbake: 
Dec 10 15:58:29 <CIA-101> Kill the uncaught exception handler
Dec 10 15:58:29 <CIA-101> We now wrap the main() in a try/except, ensuring that both the main portion of
Dec 10 15:58:29 <CIA-101> bin/bitbake and the UI raising an exception will be shown to the user. For
Dec 10 15:58:29 <CIA-101> the server and workers, we can ensure in the server itself that exceptions are
Dec 10 16:02:18 <mems> ok, so please just take note that updates-alternatives-cworth won't build at all at the moment because of the CVS server apparently disappearing
Dec 10 16:02:58 <kergoth_> the handhelds.org server is down permanently, unfortunately
Dec 10 16:03:20 <mems> oh
Dec 10 16:03:30 <mems> so what happened to the updates-alternatives-cworth source?
Dec 10 16:05:23 <kergoth_> all the hh.o sources were put on our mirror, i thought, sources.openembedded.org, but i'm not sure, i'm not an admin
Dec 10 16:05:23 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rdb7f960e5f 10bitbake.git/lib/bb/event.py: 
Dec 10 16:05:23 <CIA-101> bb.event: fix MsgBase ref in fire_class_handlers
Dec 10 16:05:23 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 16:05:36 * kergoth_ starts rewriting bb.event
Dec 10 16:06:29 <ant_work> take a snorkel with you
Dec 10 16:06:44 <ka6sox> kergoth_, I've been unable to verify that we have *all* of it.  as I find things that are missing I am gathering them up.
Dec 10 16:08:07 <kergoth_> ah
Dec 10 16:08:31 <pb_> what actually happened to hh.org, did george just decide to pull the plug on it in the end?
Dec 10 16:11:11 <bluelightning> pb_: I'm not sure anyone knows but I suspect the logs just filled up
Dec 10 16:11:20 <kergoth_> heh
Dec 10 16:11:44 <bluelightning> I see the notice about it coming back on the week of dec 1 is still there
Dec 10 16:11:52 <kergoth_> heh
Dec 10 16:12:19 <kergoth_> i don't really miss it, and i'm sure i'm not the only one, but it would have been nice to have retrieved the full cvs repositories for some things, so we could construct new git repositories with history for things like ipkg-utils
Dec 10 16:14:36 <pespin> khem, hi, you told me to use LANGUAGES env-var to enable build of fortran cross-compiler, but using that env-var looks like deprecated way of doing it.
Dec 10 16:15:12 <pespin> I've seen in several recipes something like this: --enable-languages=${enable_languages-all}
Dec 10 16:15:52 <khem> pespin: find out why f77 is not being appended to enable-languages ?
Dec 10 16:15:58 <pespin> which looks to me like a var used in OE to tell the languags, but I'm not able to find using grep  where it's  initialized >.<
Dec 10 16:16:05 <kergoth_> huh, the bitbake goggle ui is kind of cute
Dec 10 16:16:06 <khem> pespin: may be bitbake -e gcc-cross 
Dec 10 16:16:15 <khem> gm all
Dec 10 16:16:20 <kergoth_> it should really default the trees to expanded though
Dec 10 16:16:28 <kergoth_> and possibly collapse a tree when it completes
Dec 10 16:16:36 <khem>  svn merge -c -<rev> 
Dec 10 16:16:44 <khem> is like git revert <rev>
Dec 10 16:16:48 <pespin> khem, what does the "-e" option do?
Dec 10 16:16:49 <foerster> kergoth_: i like goggle so far - but yea, i have other ideas too (coloring of active items would be nice)
Dec 10 16:16:57 <kergoth_> yeah that would be really nice
Dec 10 16:17:02 <kergoth_> it took me a second to figure out what the icons were
Dec 10 16:17:08 <ant_work> khem: hello
Dec 10 16:17:13 <foerster> right - that gears are odd
Dec 10 16:17:15 <khem> ant_work
Dec 10 16:17:17 <khem> hi
Dec 10 16:17:19 <kergoth_> gears makes me think config
Dec 10 16:17:22 <kergoth_> like i click there to configure it, what?
Dec 10 16:17:32 <foerster> green for "working", red for "dead/error"
Dec 10 16:17:54 <kergoth_> still, its a pleasant change from thousands of lines of log messages flying by :)
Dec 10 16:18:00 <foerster> of note - I didn't see Preparing runqueue,etc coming through any more this morning
Dec 10 16:18:01 <khem> pespin: -e is kind of preprocessing is to C compiler
Dec 10 16:18:02 <foerster> agreed
Dec 10 16:18:06 <ant_work> khem: about the pygtk / pygobject codegen... I tested an hack like this sed  http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/python/python-pygtk_2.16.0.bb
Dec 10 16:18:14 <mems> hmmm, {sources,mirrors}.openembedded.org seem to only cover ftp and http, not cvs
Dec 10 16:18:26 <ant_work> khem: is not elegant but is in pygtk...
Dec 10 16:18:29 <khem> ant_work: did you try the patch I suggested 
Dec 10 16:18:35 <ant_work> won't work
Dec 10 16:18:41 <ant_work> see the sed ^^^
Dec 10 16:18:47 <ant_work> taht works (ofc)
Dec 10 16:19:02 <kergoth_> wtf, git hates me
Dec 10 16:19:04 <kergoth_> hmm
Dec 10 16:19:15 <kergoth_> ah! my own fault
Dec 10 16:19:51 <ant_work> khem: there is one more issue, those codegen bits sould now be staged by pygobject (pygtk-codegen is deprecated) 
Dec 10 16:20:40 <khem> ant_work: not the best I believe you simply disabled pkg-config
Dec 10 16:20:40 <foerster> kergoth_: when we get the stdout stuff resolved, I'll bring the ncurses UI back to functioning
Dec 10 16:21:15 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rc67b95955d 10openembedded.git/classes/base.bbclass: 
Dec 10 16:21:16 <CIA-101> base: use bb.plain, not print for build_summary
Dec 10 16:21:16 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 16:21:23 <kergoth_> foerster: the rebased branch and master both include the bits that kill stdout in python tasks, and also redirects logging messages to the log files for python tasks
Dec 10 16:21:31 <kergoth_> so it should now be in much better shape
Dec 10 16:21:38 <kergoth_> event handlers can still write to it right now though
Dec 10 16:21:40 <ant_work> khem: the solution other packages have is e.g. http://tinyurl.com/37j2xko
Dec 10 16:21:43 <kergoth_> hence the above fix for the build summary
Dec 10 16:21:48 <foerster> kergoth_: hm, ok.  I still see a ton of "packaged xyz" messages
Dec 10 16:21:54 <kergoth_> hmm
Dec 10 16:22:01 <foerster> or at least, I did this morning when playing around. 
Dec 10 16:22:01 <kergoth_> that shouldn't be happening
Dec 10 16:22:10 <khem> crap svn
Dec 10 16:22:14 * kergoth_ kicks off a build with it
Dec 10 16:22:56 <khem> ant_work: thats much better
Dec 10 16:23:21 <ant_work> he he
Dec 10 16:24:19 <ant_work> khem: I really have no idea about the whole pygtk stuff...just trying to unbreak 'sugar' build
Dec 10 16:24:40 <ant_work> and in fact I built that damned python-pygtksourceview
Dec 10 16:25:03 <ant_work> but it, and many other, now depend on pygobject and not only pygtk
Dec 10 16:25:28 <ant_work> so, somebody nowing that stuff should fix it.. :/
Dec 10 16:29:58 <pespin> khem, 
Dec 10 16:29:59 <pespin> # LANGUAGES=c,c++${OBJC}${FORTRAN}${JAVA}
Dec 10 16:29:59 <pespin> LANGUAGES="c,c++,objc"
Dec 10 16:30:07 <pespin> that might be the problem :P
Dec 10 16:30:59 <khem> pespin: yes thats what I have telling you to find why thats happening
Dec 10 16:31:10 <khem> and that where bitbake -e will help
Dec 10 16:31:19 <pespin> and FORTAN is not set anywhere, only GFORTRAN_FOR_TARGET
Dec 10 16:31:28 <pespin> khem, yes,i took that from the output :)
Dec 10 16:31:41 <khem> pespin: ok what does FORTRAN set to
Dec 10 16:32:52 <pespin> khem, it's not initialized anywhere
Dec 10 16:32:58 <khem> hmmm
Dec 10 16:33:18 <kergoth_> http://dl.dropbox.com/u/112715/Pictures/Screenshot-bitbake.png
Dec 10 16:33:25 <kergoth_> shows a build with the goggle ui, for the curious
Dec 10 16:33:33 <kergoth_> the gears are active tasks / recipes with active tasks
Dec 10 16:33:41 <khem> pespin: which version of gcc are you using
Dec 10 16:34:21 <pespin> khem, gcc-4.5 from OE
Dec 10 16:34:26 <khem> pespin: add FORTRAN_linux-gnueabi = ",fortran" to gcc-4.5.inc 
Dec 10 16:34:29 <pespin> here you have the -e outpout -> http://filebin.ca/edwtb/tmp-gcc-cross
Dec 10 16:34:44 <pespin> ok
Dec 10 16:34:58 <khem> you will see # Language Overrides
Dec 10 16:34:58 <khem> FORTRAN = ""
Dec 10 16:34:58 <khem> JAVA = ""
Dec 10 16:35:01 <khem> in that file
Dec 10 16:35:34 <khem> pespin: is it for arm btw.
Dec 10 16:35:48 <pespin> khem, yes
Dec 10 16:35:55 <khem> ok
Dec 10 16:35:57 <kergoth_> foerster: i suspect os.system bypasses a replaced sys.stdin -- think we might have to resurrect the fd dup'ing madness to kill stdout fully in python tasks
Dec 10 16:36:00 * kergoth_ investigates
Dec 10 16:36:14 <kergoth_> think those are the only messages that hit the console right now
Dec 10 16:36:19 <pespin> khem, now bitbake -c rebuild gcc-cross ?
Dec 10 16:36:27 <foerster> kergoth_: bah, figures something crazy would be going on 
Dec 10 16:36:31 <khem> pespin: the change I suggested should help you java and fortran are disabled by default 
Dec 10 16:36:54 <JaMa|Wrk> khem: small update on u-boot issue: it happens with gcc-4.5 also without linaro patches, and gcc-4.4.4 is safe
Dec 10 16:36:55 <khem> pespin: its not that easy
Dec 10 16:37:07 <khem> JaMa|Wrk: cool. 
Dec 10 16:37:12 <pespin> clean && build? :P
Dec 10 16:37:15 <khem> JaMa|Wrk: its a runtime issue
Dec 10 16:37:23 <kergoth_> foerster: http://bytes.com/topic/python/answers/850960-redirection-file-os-system - confirmed
Dec 10 16:37:41 <JaMa|Wrk> khem: found few issues about u-boot (but build time) and with much newer revisions
Dec 10 16:37:48 <JaMa|Wrk> khem: yes this one is runtime
Dec 10 16:37:52 <khem> pespin: you can bitbake -c clean gcc-cross gcc-cross-initial gcc-cross-intermediate eglibc eglibc-initial
Dec 10 16:37:59 <khem> then bitbake gcc-cross
Dec 10 16:38:12 <JaMa|Wrk> khem: kernel is read OK, but it just says "Starting kernel" and nothing happens
Dec 10 16:38:20 <khem> JaMa|Wrk: ok we need to dig more
Dec 10 16:38:34 <khem> JaMa|Wrk: unfortunately
Dec 10 16:38:52 <JaMa|Wrk> khem: I'll try to rebase our patches to newer u-boot rev
Dec 10 16:38:54 <khem> JaMa|Wrk: probably try to find the faulty function
Dec 10 16:39:06 <khem> JaMa|Wrk: yeah that wud be first guess
Dec 10 16:39:41 <khem> kergoth_: is there a way that I can create a bitbake -c clean <toolchain> meta target
Dec 10 16:39:43 <JaMa|Wrk> khem: I can give you workdirs for working and not-working build (with gcc-4.4.4 and gcc-4.5-without linaro) if you want but otherwise I'll try to upgrade it first
Dec 10 16:40:19 <khem> JaMa|Wrk: upgrade first I would say
Dec 10 16:40:29 <khem> if it does not happen upstream no point fixing it 
Dec 10 16:40:34 <khem> atleast not for free :)
Dec 10 16:40:35 <kergoth_> khem: not that i know of, no
Dec 10 16:40:58 <khem> kergoth_: how can be achieve something like that
Dec 10 16:41:22 <khem> may be a virtual package
Dec 10 16:42:06 <khem> which cleans and rebuilds toolchain something like that
Dec 10 16:42:07 <kergoth_> hmmmm
Dec 10 16:42:11 <kergoth_> actually, yeah, you could do it
Dec 10 16:42:16 <kergoth_> use the depends flag of the task
Dec 10 16:42:24 <kergoth_> do_clean[depends] += "otherrecipe:do_clean"
Dec 10 16:42:39 <khem> cute 
Dec 10 16:42:43 <khem> should try it out
Dec 10 16:42:45 <JaMa|Wrk> khem: ok, will try, thanks
Dec 10 16:42:49 <khem> brb
Dec 10 16:43:19 <khem> "otherrecipe should it be recipe_pv.bb ?
Dec 10 16:43:32 <khem> or can I just say eglibc:do_clean
Dec 10 16:44:19 <kergoth_> your meta recipe can just say eglibc:do_clean, and all the others you want cleaned
Dec 10 16:44:30 <JaMa|Wrk> btw is here someone with device supported in recent u-boot and building u-boot with gcc-4.5?
Dec 10 16:44:34 <kergoth_> the depends flag is space separated list
Dec 10 16:44:45 <kergoth_> man i love python 2.6 contextlib
Dec 10 16:44:55 <kergoth_>     with bb.utils.redirected_fds([sys.stdout, sys.stderr], [NULL, NULL]):
Dec 10 16:44:57 <kergoth_> <3
Dec 10 16:45:25 <kergoth_> erk, forgot to do the fileno() bit
Dec 10 16:45:33 <kergoth_> you get the idea
Dec 10 16:45:33 <kergoth_> heh
Dec 10 16:49:16 <pb_> kergoth: yeah, exactly.  there are/were a few projects on hh.org whose cvs histories would have been nice to have.
Dec 10 16:49:30 <pb_> oh well
Dec 10 16:49:34 <kergoth_> :\
Dec 10 16:49:47 <florian> what happened to it?
Dec 10 16:49:50 <kergoth_> one would think the disk would still be somewhere
Dec 10 16:49:57 <kergoth_> but i doubt they'd be cooperative
Dec 10 16:56:54 <kergoth_> foerster: what do you think of killing stdin/stdout/stderr entirely in the entire server process?  the workers get them redirected anyway, and anything the server wants to show should go via the UI..
Dec 10 16:56:58 <kergoth_> hmm
Dec 10 16:57:18 <foerster> kergoth_: sounds like how it should be, i think.
Dec 10 16:57:21 * kergoth_ nods
Dec 10 16:57:28 <kergoth_> okay, will do that
Dec 10 16:58:09 * kergoth_ is confirming the os.system from python task thing
Dec 10 16:58:33 <kergoth_> hmm, goggle needs to word wrap the messages too
Dec 10 17:00:18 <kergoth_> hmm, it should also consider shifting all fully completed recipes (no tasks remaining) into its own section of the tree -- complete, so you don't have to scroll down
Dec 10 17:00:37 <kergoth_> probably sort currently active to the top as well
Dec 10 17:00:42 <foerster> you're asking a lot :)
Dec 10 17:00:45 <kergoth_> hehe
Dec 10 17:00:47 <kergoth_> just musing
Dec 10 17:00:58 * kergoth_ knows *nothing* about gtk, and barely remembers qt
Dec 10 17:01:03 <foerster> working with treemodels in gui stuff is never fun
Dec 10 17:01:10 * kergoth_ = user interaction noob
Dec 10 17:01:33 <foerster> for example, just to do cell coloring, you have to start mucking with cellRenderers, etc
Dec 10 17:01:36 <foerster> total PITA
Dec 10 17:01:42 <kergoth_> ugh
Dec 10 17:01:56 <foerster> that's why it is as it is - it was easy
Dec 10 17:02:16 * kergoth_ n ods
Dec 10 17:02:29 <kergoth_> its slick as is, the rest is just polish
Dec 10 17:02:59 <foerster> yea, i really like it
Dec 10 17:03:05 <foerster> could put an input box on it
Dec 10 17:03:07 <kergoth_> we need to figure out how to implement some sort of configuration UI at some point, likely as a separate script
Dec 10 17:03:08 <foerster> for commands :)
Dec 10 17:03:34 <kergoth_> the issue there is we need to flag the variables we want the *user* to be able to manipulate, assuming they're not an expert, and we need variable typing to show a nice interface
Dec 10 17:03:39 <kergoth_> thats a good idea
Dec 10 17:04:07 <foerster> we'll have to set some option in cooker to not bail when done with a normal command or something, right?
Dec 10 17:04:17 <foerster> that is, when using an interactive gui
Dec 10 17:04:49 <kergoth_> yeah, we'd have to ensure that we *always* send a shutdown, even after a cookercommand failed/completed, and kill the automatic bit
Dec 10 17:04:57 <kergoth_> should be fairly easy to do
Dec 10 17:05:05 <foerster> yea, UI just does that when done
Dec 10 17:05:34 <kergoth_> yeah
Dec 10 17:06:33 <kergoth_> now that we're making tangible progress i'm really starting to enjoy this.
Dec 10 17:06:35 <kergoth_> hehe
Dec 10 17:06:40 <foerster> me too
Dec 10 17:07:06 <kergoth_> every time we make a big improvement that took all of a day or two to implement, i think .. what the hell did we wait 7 years for that for?
Dec 10 17:07:08 <kergoth_> heh
Dec 10 17:07:18 <kergoth_> so much is just a matter of sitting down and doing it, instead of going 'yeah that would be nice'
Dec 10 17:07:50 <foerster> true.  For me, this is a nice departure from the daily grind, so it's enjoyable.
Dec 10 17:07:59 * kergoth_ nods
Dec 10 17:08:53 <kergoth_> for me, i need a second hobby.  doing this shit at work and when i'm not "at work", and working from home full time, has made things rather fuzzy
Dec 10 17:09:03 <kergoth_> is my work day over? no idea, i'm messing with bitbake either way
Dec 10 17:09:06 <foerster> i hear ya
Dec 10 17:09:12 <foerster> i started working from home in april
Dec 10 17:09:20 <kergoth_> nice
Dec 10 17:09:25 <foerster> tend to always be at least reading work stuff
Dec 10 17:09:34 <foerster> even when i get bored
Dec 10 17:09:52 <foerster> though, with the 1 year old here, i have a nice forced removal from the office
Dec 10 17:10:01 <kergoth_> hehe, i'm sure thats an adventure
Dec 10 17:10:26 <foerster> babysitter leaves around 5-5:30, wife doesn't get home usually til 7, so I'm forced to stop working, which is good.
Dec 10 17:10:42 * kergoth_ nods
Dec 10 17:11:30 <foerster> i have first pass at putting some colors on active tasks :)
Dec 10 17:11:32 <kergoth_> the fd redirection for exec_func_python definitely fixed it, it had to be python functions using os.system, figured.  now to shift it so the whole server does it
Dec 10 17:11:33 <foerster> kind of neat
Dec 10 17:11:35 <kergoth_> nice
Dec 10 17:11:51 <kergoth_> i wonder if we should keep an icon for color blind people, or if the light/dark is sufficient
Dec 10 17:12:00 <foerster> i'm leaving the icon
Dec 10 17:12:09 <kergoth_> cool
Dec 10 17:12:16 <foerster> b/c it does at least provide some indicator
Dec 10 17:12:51 <foerster> hm.  should make the top leve package line show color too
Dec 10 17:13:04 <kergoth_> eep, tried to ^C a goggle build and it appears to have become unresponsive
Dec 10 17:13:11 <kergoth_> i did one earlier and it left fine though
Dec 10 17:13:35 <foerster> i haven't tried that, always use the X
Dec 10 17:13:40 * kergoth_ nods
Dec 10 17:13:48 <kergoth_> ^C is such a pain in the ass
Dec 10 17:15:16 * XorA pokes Crofton
Dec 10 17:15:30 <Crofton> urg
Dec 10 17:15:37 <Crofton> next task
Dec 10 17:15:49 <Crofton> after I eat
Dec 10 17:16:06 <XorA> Crofton: no hurry I wont read it now until tomorrow afternoon
Dec 10 17:18:01 <kergoth_> erk, if the server raises an exception in its process, the UI doesn't know what the hell to do, hangs trying to get stuff from the server
Dec 10 17:18:05 <kergoth_> hmmmm
Dec 10 17:18:47 <foerster> hmm  
Dec 10 17:18:53 <foerster> exception handling is a pain
Dec 10 17:18:59 <kergoth_> yes
Dec 10 17:19:35 <kergoth_> i wonder how best to handle that.. should the server catch any exception and send it through the event queue, or should the ui just check and see if the server is still alive, or..
Dec 10 17:19:37 <foerster> can the server just close the queue on exception (and will the UI get indication of this?)
Dec 10 17:20:08 <kergoth_> i dno't think the ui gets any knowledge of it -- all queue.close() does is says "feeder thread, when you're done feeding, go away"
Dec 10 17:20:11 <kergoth_> as far as i know
Dec 10 17:20:16 <foerster> hm
Dec 10 17:20:23 <kergoth_> but the ui could check the server being active
Dec 10 17:20:29 <kergoth_> there's a method or something for that
Dec 10 17:20:32 <kergoth_> but it could be racy
Dec 10 17:20:35 <kergoth_> hrm
Dec 10 17:20:36 <foerster> we can add an ugly Event
Dec 10 17:20:41 <CIA-101> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * rb9539b9e75 10openembedded.git/recipes/ffphonelog/ffphonelog_git.bb: 
Dec 10 17:20:41 <CIA-101> ffphonelog: bump PR after last EFL_SRCREV change
Dec 10 17:20:41 <CIA-101> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Dec 10 17:20:44 <foerster> wrap it inside server communicator
Dec 10 17:20:49 <foerster> er, wait
Dec 10 17:21:05 <kergoth_> i was just thinking a ServerDead event
Dec 10 17:21:06 <kergoth_> hmm
Dec 10 17:21:14 <foerster> or that
Dec 10 17:21:24 <foerster> that's probably cleaner
Dec 10 17:22:17 <kergoth_> wrap the run() content in a try/except, have it send the server dead event, close the queue, shutdown
Dec 10 17:22:27 <kergoth_> i already split a main() method from run() for the fd redirection
Dec 10 17:22:46 <foerster> that would probably work
Dec 10 17:24:49 <kergoth_> hmm
Dec 10 17:26:01 <kergoth_> the server has that keep_running event which it uses to shut itself down, couldn't the UI operate against that too, and clear the event on exception?
Dec 10 17:26:10 <kergoth_> course if we did that, the ui wouldn't actually have the exception object to display it
Dec 10 17:26:51 <foerster> yea.  As it is, the bin/bitbakek calls server.stop(), which clears that Event
Dec 10 17:27:04 <foerster> if we could get the exception, that would probably be nice
Dec 10 17:28:23 <kergoth_> in the other case, where the ui dies, there's nothing we can do to display it other than stderr, but when the server dies we're in a better position usability wise, best to utilize it
Dec 10 17:28:46 <kergoth_> the alternative would be to not add a new event, send the exception as a logging message and have the ui also use the running event
Dec 10 17:30:33 <kergoth_> foerster: ack, exiting the goggle ui doesn't seem to always shut down the server fully
Dec 10 17:30:36 <kergoth_> i have remnant processes
Dec 10 17:30:48 <kergoth_> hrm
Dec 10 17:30:50 <kergoth_> strange
Dec 10 17:30:55 <kergoth_> that shouldn't be happening
Dec 10 17:30:57 <foerster> hm.  wonder why.  
Dec 10 17:31:24 <kergoth_> oh, hmm
Dec 10 17:31:38 <kergoth_> i think its waiting for the current command t o complete before the server exits
Dec 10 17:31:47 <kergoth_> since server.stop() is a completely clean shutdown
Dec 10 17:31:55 <kergoth_> but that's not what the user will expect hitting a close button
Dec 10 17:32:19 <foerster> how long does it stick around?  
Dec 10 17:32:32 <foerster> it is saving the cache, or running something else?
Dec 10 17:32:48 <kergoth_> i have some that are just sitting there, but one is waiting on a tarball extraction for the kernel :)
Dec 10 17:32:55 <kergoth_> hence the theory
Dec 10 17:33:54 <foerster> so we actually want to run shutdown/stop within cooker maybe
Dec 10 17:34:09 <foerster> the server just bails out of the run loop when he sees the event cleared
Dec 10 17:34:42 <kergoth_> ah, right.. runcommand is async, and its polling the command channel not blocking
Dec 10 17:34:49 <kergoth_> so yeah, i guess all our uis need to start playing nice on exit
Dec 10 17:34:55 <kergoth_> shut down the cooker
Dec 10 17:40:24 <kergoth_> foerster: server fd killing bits are in on my separated-ui-and-server
Dec 10 17:40:36 * kergoth_ wanders off
Dec 10 17:40:44 <foerster> ok.  I'll pull em down eventually.  Screwing with coloring of goggle
Dec 10 18:20:55 <obi> khem: i can confirm the build error caused by gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch on clean builds
Dec 10 18:26:16 <kergoth_> hmmm
Dec 10 18:28:34 <kergoth_> RP: https://github.com/kergoth/bitbake/wiki/Design-Thoughts-Event
Dec 10 18:29:13 <kergoth_> RP: then we register/unregister handlers for 1) worker transmission over the pipe and 2) server transmission to the UI
Dec 10 18:29:19 <kergoth_> so bb.event doesn't have to know about any of it
Dec 10 18:29:26 * kergoth_ hacks
Dec 10 18:31:44 <foerster> kergoth_: ugly, but try it https://github.com/foerster/bitbake/commit/792578406116cbc4ba9f53e813565968d3d9f760
Dec 10 18:32:02 <foerster> I didn't bring in your changes to that branch yet, will do that later.
Dec 10 18:32:09 <foerster> gonna head out to the gym here soon
Dec 10 18:32:10 <kergoth_> will do
Dec 10 18:32:26 <foerster> I did notice though, I get build success even though my build target failed
Dec 10 18:32:28 <foerster> found that odd
Dec 10 18:33:00 <foerster> and I don't know wtf is up with sqlite fetching, seems broke all of a sudden (though I haven't sync'ed OE master in a little while)
Dec 10 18:33:01 <foerster> o well.
Dec 10 18:33:12 <kergoth_> strange
Dec 10 18:33:39 <foerster> i get a garbaged up log message too for sqlite
Dec 10 18:34:21 <foerster> fetch http://www.sqlite.org/sqlite-autoconf-%d%02d etc .tar.gz
Dec 10 18:34:35 <foerster> don't have any idea why the %d%02d still in there
Dec 10 18:34:43 <foerster> ah, shit
Dec 10 18:34:45 <foerster> i'm an idiot
Dec 10 18:34:54 <foerster> i was helping davidlt (i think) debug that
Dec 10 18:35:03 <foerster> i was wondering where the hell sqlite was coming in
Dec 10 18:35:12 * foerster smacks self for being stupid
Dec 10 18:36:03 <kergoth_> hehe
Dec 10 18:36:21 <foerster> brain fried, can't remember what i did yesterday :)
Dec 10 18:37:29 <foerster> i'm out, need a break
Dec 10 18:50:23 <kergoth_> damn, the new event handling is *really* simple
Dec 10 19:01:37 <tharvey> kergoth_, played with debootstrap/schroot a bit last night.  You mentioned you use schroot to get into the chroot.  From what I found you use 'chroot' to get 'into' it, and use schroot to execute a command within it (but not get a shell in it)
Dec 10 19:01:45 <kergoth_> no
Dec 10 19:01:50 <kergoth_> schroot defaults to dropping you to a shell
Dec 10 19:01:56 <kergoth_> you *can* use it to run a command
Dec 10 19:02:05 <tharvey> ah.. ok, didn't notice that usage
Dec 10 19:02:08 <tharvey> I'm guessing you spend some time setting up your chroot environment and not recreating them all the time right?
Dec 10 19:02:31 <kergoth_> i set up a chroot, add a .conf to /etc/schroot.d/, and forget about it until i need to use it to do something
Dec 10 19:02:58 <kergoth_> i have a few that i use to run bitbake directly, the way you mention you can tell schroot to run a command
Dec 10 19:03:01 <kergoth_> works well
Dec 10 19:03:31 <tharvey> I did use buildout to build a local python-2.6 for hardy as there wasn't a pkg for it, seemed to work but I couldn't run bitbake in the chroot - it simply returned with no output
Dec 10 19:03:35 <kergoth_> course, managing your configs across them gets slightly annoying, since the ASSUME_PROVIDED is really per distro
Dec 10 19:03:54 <kergoth_> what bitbake version?
Dec 10 19:04:06 <tharvey> was using master perhaps a week back
Dec 10 19:04:12 <tharvey> ASSUME_PROVIDED?
Dec 10 19:04:19 <kergoth_> okay, update to master as of this morning
Dec 10 19:04:31 <kergoth_> yes, because what build tools are on the build machine varies from chroot to chroot
Dec 10 19:04:40 <kergoth_> so in one chroot i might require linux-libc-headers-native, but the rest don't
Dec 10 19:04:45 <kergoth_> a single site.conf won't do it
Dec 10 19:04:57 <kergoth_> of course, if you use separate build dirs, one per chroot, you're fine
Dec 10 19:04:59 <kergoth_> i don't, usually
Dec 10 19:05:00 <tharvey> you also said something about liking schroot because it handled binding proc etc?  how is that?  from what I saw you provide binds in your host /etc/fstab which is also pretty manual - I want to see if I can get a chroot that runs under a user and requires no sudo
Dec 10 19:05:08 <kergoth_> no, you don't need any of that
Dec 10 19:05:15 <kergoth_> set the type to 'directory' in schroot.conf
Dec 10 19:05:21 <kergoth_> it'll automatically run setup and exec scripts for the chroot
Dec 10 19:05:26 <kergoth_> the setup scripts do all that mounting for you
Dec 10 19:05:33 <kergoth_> completely painless
Dec 10 19:05:37 <kergoth_> works under user or root, either way
Dec 10 19:06:00 <kergoth_> if you run bitbake as of 11am this morning, it should show the exception that was raised instead of exiting silently
Dec 10 19:06:08 <kergoth_> its likely it failed to import something, missing a package in the chroot
Dec 10 19:06:16 <khem> obi: whats your host OS
Dec 10 19:06:42 <kergoth_> tharvey: it even automatically bind mounts your homedir
Dec 10 19:06:48 <khem> strange though because noone touched that patch for long
Dec 10 19:06:50 <kergoth_> and copies passwd/group, iirc
Dec 10 19:07:26 <kergoth_> so its almost completely transparent, anything you can run in your shell, you can run equally well via schroot, assuming the necessary system bits are installed of course
Dec 10 19:09:47 <kergoth_> hrm
Dec 10 19:14:10 <kergoth_> damn, this is so much cleaner
Dec 10 19:14:15 <kergoth_> unbelievable
Dec 10 19:14:16 <tharvey> hmmm... I'm not seeing any automatic binds or anything, can you look at http://pastebin.com/fxSHYeSd
Dec 10 19:14:21 <tharvey> perhaps my config is missing something
Dec 10 19:15:04 <tharvey> kergoth_, what setup/exec scripts does schroot run?  sounds like something you had to setup beyond what debootstrap created for you?
Dec 10 19:15:16 <kergoth_> no
Dec 10 19:15:20 <kergoth_> its all schroot
Dec 10 19:15:33 <kergoth_> ls /etc/schroot/setup.d/
Dec 10 19:15:46 <kergoth_> see https://gist.github.com/736645
Dec 10 19:16:33 <tharvey> so are you using automated build scripts that use schroot to kick off commands or are you just entering a shell and using the shell manually?
Dec 10 19:19:55 <kergoth_> neither
Dec 10 19:20:17 <kergoth_> ~oe% schroot -c lucid bitbake task-boot
Dec 10 19:20:22 <kergoth_> or whatever
Dec 10 19:20:27 <kergoth_> well, not exactly that, but you get the idea
Dec 10 19:20:53 <kergoth_> i think i had an alias, since it expects a full path to the binary it wants to run, iirc
Dec 10 19:20:57 <kergoth_> but thats the idea
Dec 10 19:21:01 <tharvey> so that runs as what user within the chroot?  I'm getting hung up on users and environment
Dec 10 19:21:06 <kergoth_> as me
Dec 10 19:21:14 <kergoth_> no, like i said, it copies passwd and group and shadow
Dec 10 19:21:18 <kergoth_> i'm me here, and i'm me there
Dec 10 19:21:26 <kergoth_> and it bind mounts the homedir, so my files are still there
Dec 10 19:21:32 <kergoth_> and it doesn't lose teh environment
Dec 10 19:21:40 <kergoth_> er, i think you need -p for schroot
Dec 10 19:21:45 <kergoth_> then it will preserve it
Dec 10 19:22:01 <tharvey> debootstrap copied those when you created the chroot?  it didn't for me - has a generic one
Dec 10 19:22:03 <kergoth_> schroot -p -c lucid ./bitbake/bin/bitbake task-boot
Dec 10 19:22:05 <kergoth_> no
Dec 10 19:22:06 <tharvey> /etc/passwd that is
Dec 10 19:22:09 <kergoth_> schroot's setup scripts do it.
Dec 10 19:22:13 <kergoth_> just as they do the bind mounting
Dec 10 19:22:24 <kergoth_> so the files are always current
Dec 10 19:23:05 <tharvey> hmmm, maybe I have a different schroot or something.  I'm using pkg I installed on ubuntu 10.04 whcih is 1.4.0
Dec 10 19:23:32 <kergoth_> maybe they aren't in /etc/schroot on older versions, but they're still there, and schroot behaves the same way
Dec 10 19:23:41 <kergoth_> dpkg -L schroot|grep setup
Dec 10 19:24:19 <tharvey> ya, I see various scripts in /etc/schroot/setup.d but they don't seem to be behaving as you describe - what ver you using on what distro?
Dec 10 19:24:36 <kergoth_> every version i've used for the past 3 years hsa worked this way.
Dec 10 19:24:47 <kergoth_> lets see.. teh config format may have changed slightly
Dec 10 19:24:48 <kergoth_> read the man page
Dec 10 19:24:50 <kergoth_> man schroot.conf
Dec 10 19:24:52 <tharvey> http://pastebin.com/T7f1qYBv
Dec 10 19:25:01 <kergoth_> there's variables to explicitly enable the setup and exec scripts
Dec 10 19:25:08 <kergoth_> so try that, maybe its not automatic for 'directory' in your version
Dec 10 19:25:14 <tharvey> shows the setup files I have - ya I'll spend more time in the man pages - I must be missing something
Dec 10 19:25:48 <kergoth_> look at /etc/default/schroot
Dec 10 19:26:09 <tharvey> and for the environment bitbake needs, such as BBPATH - are you setting that on your host and useing -p to perserve it in chroot or setting that in your users .bashrc within the chroot?
Dec 10 19:26:27 <kergoth_> the users .bashrc in the chroot *IS* your ~/.bashrc
Dec 10 19:26:33 <kergoth_> because, for the third time, it bind mounts ~
Dec 10 19:26:41 <tharvey> ah right... 'if' it binds mounts, which I don't have using yet
Dec 10 19:26:54 <kergoth_> again, its just a matter of getting it to run the setup scripts
Dec 10 19:27:01 <tharvey> ok, I'll dig more - thanks for the info - I think the chroot will be very useful
Dec 10 19:27:05 <kergoth_> ah, here we are
Dec 10 19:27:08 <kergoth_> see /etc/schroot/default/copyfiles
Dec 10 19:27:16 <kergoth_> etc
Dec 10 19:27:27 <kergoth_> the setup scripts are controlled by those default files
Dec 10 19:27:33 <kergoth_> similar to how init.d are controlled by /etc/default
Dec 10 19:27:49 <kergoth_> hmm, i dont see passwd there, maybe i'm mistaken, i coudl have sworn..
Dec 10 19:27:55 <kergoth_> well, worst case you could add it :)
Dec 10 19:28:01 <kergoth_> its all quite easy to configure and control
Dec 10 19:28:06 <kergoth_> definitely check out the man pages though
Dec 10 19:28:09 <kergoth_> both for schroot itself and schroot.conf
Dec 10 19:28:11 <tharvey> I have /etc/schroot/copyfiles-defaults which contains /etc/resolv.conf and /etc/gshadow, not /etc/passwd
Dec 10 19:28:20 * kergoth_ nods
Dec 10 19:30:13 <tharvey> ah... perhaps another thing I'm missing.  whoami when I'm in chroot is 'root', likely because I run 'sudo schroot -c hardy' - you running it as your user correct? 
Dec 10 19:30:43 <kergoth_> yep
Dec 10 19:31:21 <kergoth_> you can also use schroot -c hardy -u root, if you configure the groups right in schroot.conf
Dec 10 19:31:31 <kergoth_> for when you do want to be root, anyway
Dec 10 19:31:58 <kergoth_> clearly i haven't set up an schroot chroot from scratch in a while, sorry about that
Dec 10 19:32:02 <tharvey> you have to run debootstrap as root thus it creates the chroot dir owned by root, so I couldn't run 'schroot -c hardy' without being root, perhaps I was simply supposed to chown the chroot dir as me?
Dec 10 19:32:11 <kergoth_> what do you mean?
Dec 10 19:32:20 <kergoth_> why would you have to own the rootfs to be able to schroot into it?
Dec 10 19:32:29 <kergoth_> just because you ran it as root doesn't mean the entire rootfs is chmod 0700
Dec 10 19:32:41 <kergoth_> it bind moutns your homedir
Dec 10 19:32:46 <kergoth_> and of course you can do anything in there you like
Dec 10 19:32:58 <kergoth_> also, pretty sure schroot is setuid
Dec 10 19:33:04 <kergoth_> which is how it handles the bind mounts, etc, before dropping perms
Dec 10 19:33:20 <kergoth_> (and of course, the run of chroot itself)
Dec 10 19:33:23 <tharvey> I get all kinds of errors when not running schroot -c hardy as root - still trying to figure out
Dec 10 19:33:27 <kergoth_> anyway, i don't know how exactly it does it, but it works
Dec 10 19:33:39 <tharvey> still seems to stem from the fact those setup scripts are not doing there thing - got to solve that it appears first
Dec 10 19:33:49 <kergoth_> yeah, i think you're right
Dec 10 19:33:54 <kergoth_> might copy passwd/shadow/group manually for now
Dec 10 19:33:56 <tharvey> I'm sure thats causing all my issues
Dec 10 19:34:01 <tharvey> ya
Dec 10 19:34:02 <kergoth_> can always set those up to copy automaticlaly later
Dec 10 19:34:11 <kergoth_> without those in place, the perms will be all wrong when it tries to act like you
Dec 10 19:34:15 <kergoth_> the uids on files won't match up
Dec 10 19:36:35 <tharvey> ya, if I cp passwd/shadow/group manaully and mkdir /var/chroot/hardy/home/tharvey I can 'schroot -c hardy' as tharvey just fine
Dec 10 19:37:09 <tharvey> mount tells me not /etc/mtab and /proc is empty etc - so still get to get those setup scripts working for that
Dec 10 19:37:20 <kergoth_> okay, yeah, i think your'e close to there
Dec 10 19:37:33 <kergoth_> probably would be easier to add passwd, group, and shadow to the copyfiles in /etc/schroot/default/copyfiles
Dec 10 19:37:37 <kergoth_> but i've never tried that
Dec 10 19:37:58 <tharvey> ya, I think setting up the chroot is more involved than you recall
Dec 10 19:38:03 <kergoth_> tharvey: run-setup-scripts=true
Dec 10 19:38:10 <kergoth_> tharvey: run-exec-scripts=true
Dec 10 19:38:14 <kergoth_> add those to your schroot .conf
Dec 10 19:43:04 <tharvey> those are deprecated it appears and don't work - what does your /etc/default/schroot look like (can't find their new replacements)?
Dec 10 19:44:17 <tharvey> mine simply has 'SESSIONS_RECOVER="recover"' and the default /etc/schroot/schroot.conf is completely commented out
Dec 10 19:44:17 <kergoth_>  /etc/default/schroot just talks about recovering of sessions, doesn't have anything to do with setup
Dec 10 19:44:21 <kergoth_> yep
Dec 10 19:44:34 <kergoth_> again, read the man page for schroot.conf
Dec 10 19:44:38 <kergoth_> it talks about setup scripts and everything
Dec 10 19:45:04 <tharvey> I did... it talks about setup scripts but not how to 'enable' them - the options you pointed out are deprecated, if I use them it barks at me when I schroot and appears to not run them
Dec 10 19:45:48 <kergoth_> i don't use those
Dec 10 19:45:52 <tharvey> schroot -i -c hardy confirms that they are not enabled
Dec 10 19:45:53 <kergoth_> i pointed you to them thinking you were using ar eally old schroot
Dec 10 19:46:03 <tharvey> sorry - I know this isn't a 'chroot' channel :P
Dec 10 19:46:14 <kergoth_> https://gist.github.com/736645 is all i do when it comes to schroot setup
Dec 10 19:46:35 <kergoth_> see the section of schroot.conf entitled 'Plain and directory chroots'
Dec 10 19:46:58 <kergoth_> well, its slightly related, in that you can use chroots to do oe builds, and doing so is a very useful thing to be able to do
Dec 10 19:47:03 <kergoth_> we should put this in a howto on the wiki or something
Dec 10 19:47:29 <tharvey> agreed thats why I was asking the other day when you said it was really simple heh
Dec 10 19:47:38 <tharvey> I'll put up a wiki page when I figure it all out
Dec 10 19:47:43 <kergoth_> well, i thought it was, but i must have forgotten a step
Dec 10 19:48:05 <kergoth_> i should install schroot in one of my chroots
Dec 10 19:48:13 <kergoth_> can you chroot from a chroot? ;)
Dec 10 19:48:17 <tharvey> it almost acts like schroot is broken or misdocumented - the depreated run-setup-scripts=true does not work and I don't see an alternative mentioned in the man pages
Dec 10 19:48:31 <kergoth_> type=directory does it.
Dec 10 19:48:36 <kergoth_> or so schroot.conf's man page claims
Dec 10 19:48:52 <tharvey> type=directory is deprecated as well... now you just use 'directory=/var/chroot/hardy' 
Dec 10 19:49:08 <kergoth_> afaik, anyway
Dec 10 19:49:35 <kergoth_> Note that 'plain' chroots do not run setup scripts and mount filesystems; 'directory' is recommended  (see  "Plain  and directory chroots", below).
Dec 10 19:50:22 <tharvey> ahhhh bingo
Dec 10 19:50:35 <kergoth_> hence, type=directory
Dec 10 19:50:54 <tharvey> I was wrong - 'type=directory' is not deprecated and thats the magic config that makes it work (as you said not plain)
Dec 10 19:51:06 <tharvey> I thought type=directory location=foo was replaced with directory=
Dec 10 19:51:11 <kergoth_> how many times did i say that? :P
Dec 10 19:51:20 <tharvey> location= was deprecated but you still need both type=directory and directory=
Dec 10 19:51:27 <kergoth_> yes
Dec 10 19:51:44 <kergoth_> i didn't have those in my .conf for no reason :)
Dec 10 19:51:49 <kergoth_> at any rate, glad you got it
Dec 10 19:51:51 <tharvey> well again I thought the manpage was saying that directory= was shorthand for both of those
Dec 10 19:52:09 <kergoth_> there are many types
Dec 10 19:52:12 <tharvey> last night when I did that I got a deprecation warning/failure but I guess it was about location and not type=
Dec 10 19:52:13 <kergoth_> unionfs, mount, directory, etc
Dec 10 19:52:20 <kergoth_> directory= just points to the path for some of the types
Dec 10 19:52:47 <tharvey> wow... it works much better now heh
Dec 10 19:52:56 <kergoth_> heh
Dec 10 19:53:04 <tharvey> thanks for putting up with me
Dec 10 19:53:25 <kergoth_> so, setup chroot with debootstrap, create the schroot .conf for it, then either manually copy passwd/group/shadow or add them to /etc/schroot/default/copyfiles
Dec 10 19:53:29 <kergoth_> and should be good to go
Dec 10 19:53:41 <tharvey> ya... insert 'properly' in each of those steps above
Dec 10 19:53:46 <kergoth_> hmm, wait
Dec 10 19:53:58 <kergoth_> the 'nssdatabases' setup script mentions passwd
Dec 10 19:54:06 * kergoth_ pokes around
Dec 10 19:54:06 <tharvey> going to re-setup - may not need to manually copy as long as I do it right
Dec 10 19:54:22 <CIA-101> 03Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r7ebbccee5e 10openembedded.git/recipes/lttng/ (5 files in 2 dirs): 
Dec 10 19:54:22 <CIA-101> ust / userspace-rcu: Add recipes
Dec 10 19:54:22 <CIA-101> Based on Esben Haabendal's recipes.
Dec 10 19:54:22 <CIA-101> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Dec 10 19:54:22 <kergoth_> yep, nssdatabases copies the passwd
Dec 10 19:54:27 <kergoth_> no need for the manual stuff there either
Dec 10 19:54:33 <kergoth_> i thought it did, but second guessed myself
Dec 10 19:54:55 <kergoth_> 1) setup chroot, 2) schroot .conf 3) profit
Dec 10 19:54:57 <kergoth_> ;)
Dec 10 19:55:47 <tharvey> so out of curiousity how do you setup your env for bitbake... you set just BBPATH in your .bashrc and thats it?
Dec 10 19:56:04 <tharvey> and make sure proper bitbake is in path of course
Dec 10 19:57:05 <tharvey> my goal is to create a schroot that depends upon nothing from the host user env, so I want everything to run as user build or root within the chroot and be completely self contained
Dec 10 20:01:27 <Crofton|work> I source the vars from a script ...
Dec 10 20:02:03 <tharvey> as do I but it seems like kergoth_ does not and I'm curious how he sets it up
Dec 10 20:02:17 <kergoth_> i use bitbake master
Dec 10 20:02:25 <kergoth_> which means layers
Dec 10 20:02:27 <tharvey> I have several oe dirs I build from thus my env's all have different BBPATH
Dec 10 20:02:31 <kergoth_> which means  no env vars other than PATH to bitbake
Dec 10 20:02:35 <kergoth_> i have several oe dirs too
Dec 10 20:02:43 <kergoth_> all with different bblayers.conf's, i just cd into it and go
Dec 10 20:02:48 <tharvey> right, we had this discussion before and I recall you telling me 'no env vars' emphatically
Dec 10 20:03:04 <kergoth_> its up to you, but i don't bother with them personally
Dec 10 20:03:56 <tharvey> let me read the documentation for BBLAYERS again - and again, where would I find that?  I think its only burried in a maillist post right?
Dec 10 20:04:37 <kergoth_> for me, in my conf/bblayers.conf, i have:
Dec 10 20:04:41 <kergoth_> TOPDIR := "${@os.path.dirname(os.path.dirname(d.getVar('FILE', True)))}"
Dec 10 20:04:41 <kergoth_> BBPATH = "${TOPDIR}:${HOME}/.oe"
Dec 10 20:04:47 <kergoth_> BBLAYERS = "${TOPDIR}/openembedded"
Dec 10 20:04:52 <kergoth_> that's it
Dec 10 20:04:56 <kergoth_> openembedded already has a conf/layer.conf
Dec 10 20:05:01 <kergoth_> so you don't hav eto worry about that
Dec 10 20:05:15 <kergoth_> cd into the dir that has conf/bblayers.conf, or any subdir beneath it, and it'll build using that
Dec 10 20:05:46 <kergoth_> now, you can see that my oe dir is relative to my project area, i keep a new oe dir in each build area personally, but you could always point to a dir outside of TOPDIR
Dec 10 20:06:19 <kergoth_> of course, you still need a conf/local.conf next to the bblayers.conf, but it no longer has to set BBFILES
Dec 10 20:06:26 <kergoth_> it just sets your machine, distro, etc
Dec 10 20:06:56 <kergoth_> there are of course, as with anything else related to bitbake, many ways to do it, thats just what i use
Dec 10 20:09:45 <kergoth_> hmmm
Dec 10 20:11:31 <tharvey> I do see you have this documented in doc/manual/usermanual.xml but thats in what comes up at bitbake.berlios.de - is that simply because this ver is not released yet?
Dec 10 20:11:51 <kergoth_> most likely, yes.
Dec 10 20:16:51 <tharvey> got bit yesterday by the 'requires python-2.6' issue, which I didn't notice until I refactored a bunch of metadata to use bbappend instead of amend.inc etc and then realized my nightly build machine didn't have python-2.6 heh
Dec 10 20:17:36 <tharvey> I like the cleanliness of not needing env vars though... I see the light
Dec 10 20:18:02 <kergoth_> hehe
Dec 10 20:18:14 <obi> khem: debian squeeze
Dec 10 20:18:26 <tharvey> will just add another day or so of work to setup either a chroot or a buildout based python-2.6 on my build machine
Dec 10 20:18:32 * kergoth_ nods
Dec 10 20:19:02 <kergoth_> i wouldn't use anything but master nowadays, particularly with parallel parsing, bbappend, and bblayers
Dec 10 20:19:11 <obi> khem: this problem didn't appear on an updated build, only on a clean build
Dec 10 20:19:15 <tharvey> I'll simply explain to management the 5min -> 1min decrease in current bitbakes caching will make up for that day within a week or so ;P
Dec 10 20:19:27 * tharvey nods
Dec 10 20:20:00 <kergoth_> damnit, my new event handling is slowww
Dec 10 20:20:01 <kergoth_> why..
Dec 10 20:24:44 <kergoth_> ugh
Dec 10 20:24:45 <kergoth_> hrm
Dec 10 20:25:16 <kergoth_> madness due to how the metadata is attached to events.. guess i might have to start over and kill the global event handling 100% instead
Dec 10 20:25:19 <kergoth_> probably for the best
Dec 10 20:31:23 <kergoth_> hmm
Dec 10 20:31:41 <kergoth_> i think i see a plan of attack, maybe
Dec 10 20:48:57 <kergoth_> whew, i think i finally have a good way to do this, from beginning to end
Dec 10 20:48:59 * kergoth_ reviews
Dec 10 20:55:29 * ka6sox4 tries to remember the opie guy's nick
Dec 10 20:57:51 <kergoth_> ka6sox4: bluelightning
Dec 10 20:59:41 <ka6sox4> right...too tired not enough sleep.thanks
Dec 10 20:59:58 <kergoth_> np
Dec 10 21:07:31 * Jay7 is trying to design QA-testing for TestBuilder
Dec 10 21:08:12 <Jay7> runtime qemu testing and may be some static tests (kernel/image sizes check, etc)
Dec 10 21:08:45 <Jay7> any ideas are welcome
Dec 10 21:12:13 <kergoth_> Jay7: should talk to the yocto guys, they're already doing runtime testing, though i don't know much about the details
Dec 10 21:12:33 <Jay7> kergoth_: I've looked into they testing code
Dec 10 21:13:06 <Jay7> they have runtime testing as part of bitbake run
Dec 10 21:13:25 <Jay7> I dislike this idea.. bitbake is tool for 'bit-baking' :)
Dec 10 21:14:22 <Jay7> most of they tests are shell scripts anyway
Dec 10 21:17:58 <kergoth_> ah
Dec 10 21:19:17 <reactor16> obi r u here ?
Dec 10 21:22:56 <foerster> kergoth_: i have goggle putting newer tasks at the top of the list
Dec 10 21:23:06 <foerster> kinda cool that way
Dec 10 21:26:10 <kergoth_> nice
Dec 10 21:26:44 <foerster> hmm.  do_package_update_index_ipk failed with :  local variable 'lock' referenced before assignment
Dec 10 21:27:03 <kergoth_> hmm
Dec 10 21:27:15 <kergoth_> ah, i see it
Dec 10 21:28:15 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rf57f8f3cc9 10bitbake.git/lib/bb/utils.py: 
Dec 10 21:28:15 <CIA-101> utils: fix 'lock' variable reference
Dec 10 21:28:15 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 21:28:23 <kergoth_> see, my pyflakes vim plugin was busted due to upstream changing their layout
Dec 10 21:28:30 <foerster> ah
Dec 10 21:28:41 <kergoth_> this resulted in me not seeing the undefined var nicely highlighted in red the way i usually do
Dec 10 21:28:44 * kergoth_ clearly got spoiled
Dec 10 21:29:51 <foerster> http://erafx.com/tmp/bb-fail-screenshot.png
Dec 10 21:29:52 <foerster> :)
Dec 10 21:30:07 <kergoth_> nice.
Dec 10 21:30:22 <foerster> since it did os._exit there, my green didn't go away :(
Dec 10 21:30:59 <foerster> another half shitty thing (but maybe it's good).
Dec 10 21:31:06 <foerster> when a task fails
Dec 10 21:31:08 <kergoth_> we need to review exit code handling in general
Dec 10 21:31:13 <kergoth_> sometimes bitbake returns 0 when a task failed
Dec 10 21:31:22 <foerster> i get task_failed event before the logrecord for failed task
Dec 10 21:31:38 <foerster> so i don't know where to put the failure, and it gets tacked to the top of the list
Dec 10 21:31:42 <foerster> but again, maybe that's not a bad thing
Dec 10 21:31:58 <kergoth_> i think we should associate the log messages from tasks with the task id they belong to
Dec 10 21:32:07 <kergoth_> i know logging lets you add extra bits you can use in messages, just not sure how yet
Dec 10 21:32:11 <kergoth_> need to investigate
Dec 10 21:32:20 <foerster> it has much of it
Dec 10 21:32:28 <foerster> event: {'pathname': '/home/foerster/dev/openembedded/dev/bitbake/lib/bb/runqueue.py', 'threadName': 'MainThread', 'name': 'BitBake.RunQueue', 'thread': 140447366334208, 'relativeCreated': 95620.636940002441, 'process': 6922, 'args': (), 'module': 'runqueue', 'funcName': 'fork_off_task', 'levelno': 50, 'processName': 'ProcessServer-1', 'exc_text': None, 'created': 1292016087.886553, 'msecs': 886.55304908752441, 'msg': "local variable 'loc
Dec 10 21:32:28 <foerster> k' referenced before assignment", 'exc_info': None, 'filename': 'runqueue.py', 'levelname': 'CRITICAL', 'lineno': 1118}
Dec 10 21:32:55 <kergoth_> hmm, i guess for tasks the process is unique
Dec 10 21:32:58 <kergoth_> might not always be that way though
Dec 10 21:33:04 <kergoth_> and doesn't help you associate to task events
Dec 10 21:33:21 <foerster> yea.  Well, I do get task set to "do_compile", etc
Dec 10 21:33:26 <foerster> but not tied to a package
Dec 10 21:33:35 * kergoth_ nods
Dec 10 21:33:52 <foerster> i need package info, or reverse the order of events (logrecord for failure, then taskfailed
Dec 10 21:33:56 <kergoth_> some of the stuff i'm working on for bb.event might help with this
Dec 10 21:34:02 <kergoth_> https://github.com/kergoth/bitbake/wiki/Design-Thoughts-Event is the current plan
Dec 10 21:35:01 <kergoth_> in particular, that it uses a handler in the worker to pass the event back, it could easily inject extra data along the way
Dec 10 21:36:16 <foerster> sounds good
Dec 10 21:36:50 <kergoth_> my only concern doing it this way is any extra overhead
Dec 10 21:36:55 <kergoth_> but can profile it after its done
Dec 10 21:39:07 <foerster> https://github.com/foerster/bitbake/commit/189278946b65aa68953186ca5fc991dc865fd9db
Dec 10 21:39:35 <foerster> goggle is cool.  Still needs some refinement (should probably say something about building runqueue, etc).  It's getting there though
Dec 10 21:39:54 <kergoth_> yeah, definitely.  i already prefer it to running at console, you can actually make sense of the output much more easily
Dec 10 21:40:00 <foerster> i agree
Dec 10 21:40:10 <foerster> it's slick, very useful IMO
Dec 10 21:40:14 <rphillips> kergoth_: will there logging within the dispatcher stack?
Dec 10 21:40:22 <rphillips> be logging*
Dec 10 21:40:39 <kergoth_> rphillips: we already have a Logging handler that we add to our logger which dispatches LogRecords through bb.event
Dec 10 21:40:55 <kergoth_> will do the same thing, just to a specific dispatcher instead of bb.event's global bits
Dec 10 21:40:58 <reactor16> is bitbake work on openvz virtualization ?
Dec 10 21:41:14 <rphillips> great
Dec 10 21:41:37 <kergoth_> er.. i just realized we're using the slow pickle instead of cPickle for the events between the server/ui
Dec 10 21:41:43 * kergoth_ wonders if that'd be noticable
Dec 10 21:42:13 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rb16c0c1dc3 10bitbake.git/lib/bb/event.py: 
Dec 10 21:42:14 <CIA-101> event: use cPickle for events
Dec 10 21:42:14 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 21:43:06 * kergoth_ tests
Dec 10 21:47:57 <foerster> kergoth_: get rid of the <event> + pickle </event> stuff :)
Dec 10 21:49:03 <kergoth_> i don't know if loads/dumps is as smart as load/dump, and its using the BBUIEventQueue.send instead of a file-like object
Dec 10 21:49:11 * kergoth_ shrugs
Dec 10 21:49:22 <kergoth_> either way we'll get separated merged soon enough
Dec 10 21:49:28 <kergoth_> i think all the major bugs are gone
Dec 10 21:50:01 <foerster> yea, just some last cleanup wrt ^C in bin/bitbake, and making UIs shut down cooker on exit
Dec 10 21:52:19 <kergoth_> lets see.. i'm thinking two exception handlers for keyboard interrupt, one surrounding ui_main, in case they hit it right after the loop exits, and that one can server.terminate(), and one at toplevel to catch any during the clean shutdown and just exit
Dec 10 21:52:29 <kergoth_> either that or the signal() you did
Dec 10 21:52:37 <kergoth_> signal's probably cleaner
Dec 10 21:52:51 <kergoth_> but, we should still catch any from ui_main, in case they hit it at the end of the ui loop
Dec 10 21:52:56 <kergoth_> so maybe not
Dec 10 21:53:28 <foerster> well, if ^C doesn't leave the server hanging, then just let 'em abuse us if they want
Dec 10 21:54:00 <foerster> i put the signal block in b/c (during development) I was getting funny stack traces
Dec 10 21:54:04 <kergoth_> hmm
Dec 10 21:55:01 <foerster> if we don't catch it, there's a chance server.stop, join won't get called
Dec 10 21:55:07 <foerster> i think maybe that's what I was seeing
Dec 10 21:55:26 <foerster> don't remember exactly. Just know I did the easiest thing to make my problem go away :)
Dec 10 21:55:32 <kergoth_> yeah, if server.stop isn't called, it'll still try to join at the end, but hang because the server isn't quitting yet necessarily, and then you'd interrupt that join
Dec 10 21:55:35 <kergoth_> would be my guess
Dec 10 21:56:18 <foerster> so, we want to block it until stop is called for sure.  And we could put a timeout on join
Dec 10 21:56:33 <foerster> so it won't stay hung up for eternity
Dec 10 22:00:15 <foerster> kergoth_: let me know what you come up with, i'm out for now.  later
Dec 10 22:07:33 * khem just bought a car
Dec 10 22:14:36 <khem> obi: Do u have quilt-native in your ASSUME_PROVIDED by any chance ?
Dec 10 22:14:54 <khem> madness in gcc 
Dec 10 22:17:15 <kergoth_> khem: grats, what car?
Dec 10 22:17:30 <khem> used BMW
Dec 10 22:17:36 <khem> I had to get a second car
Dec 10 22:17:47 <kergoth_> ahh, nice
Dec 10 22:18:41 <khem> I kind of come to trust BMWs more after the last accident that my wife was in and all came out unhurt it was amazing if you looked at the car you would think worst happened
Dec 10 22:19:05 <khem> someone rammed into her car while she was waiting on a traffic light
Dec 10 22:19:16 <khem> idiots with cell phones
Dec 10 22:20:43 <kergoth_> damn, bitbake master parsing a collection similar to poky in size parses the recipes as fast as an OE build loads the cache
Dec 10 22:34:06 <Crofton|work> khem, your gcc commit worked fine for me
Dec 10 22:36:55 <khem> Crofton|work: cool thx
Dec 10 22:37:15 <khem> Crofton|work: I wonder if it worked for eFfeM_work too because I think his issue should be solved too now
Dec 10 22:37:35 <khem> Crofton|work: do u attend SCALE ?
Dec 10 22:39:19 <tharvey> kergoth_, do you know if there is a way to create a chroot without root access?  debootstrap must run as root, not entirely clear why fakeroot couldn't be used
Dec 10 22:39:54 <kergoth_> hmm, i'd thought you could do it under fakeroot, does it not work?
Dec 10 22:39:58 * kergoth_ hasn't tried that in a while though
Dec 10 22:43:53 <dfoley> pretty sure the current bitbake causes gcc-cross-initial to unpack to an incorrect directory name. git bisecting 53740977521bc81ffa37adfa7bbeb8f2a80ea165 is the first bad commit
Dec 10 22:44:33 <kergoth_> hmm
Dec 10 22:45:15 <tharvey> khem, whats your thought on using cross-localedef instead of qemu to generate locales?  seems like something in your area of expertise?  poky does it http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta/classes/libc-package.bbclass#n277
Dec 10 22:45:47 <kergoth_> dfoley: could you compare the directory names and tell me what they are?
Dec 10 22:45:49 <khem> tharvey: yes I want to do it very much
Dec 10 22:46:03 <dfoley> kergoth_: sure hang on
Dec 10 22:46:03 <khem> just not finding that 25th hour of a day :)
Dec 10 22:46:09 <kergoth_> dfoley: i'm not seeing how that would happen from looking at the code, that might be informative
Dec 10 22:46:15 <tharvey> this is in reference to a 'localedef returned an error' causing eglibc/glibc failure on release2010.12
Dec 10 22:46:30 <tharvey> khem, understood
Dec 10 22:46:45 <tharvey> http://thread.gmane.org/gmane.comp.handhelds.openembedded/40416
Dec 10 22:47:07 <khem> tharvey: I know 
Dec 10 22:47:11 <khem> :(
Dec 10 22:48:22 <tharvey> Crofton|work, I've run into your i2c-dev.h issue as well
Dec 10 22:48:54 <tharvey> would love to see that solved - trying to figure out if that header from i2c-tools is even necessary - what do desktop distros do?
Dec 10 22:54:14 <dfoley> kergoth: bad: 53740977521bc81ffa37adfa7bbeb8f2a80ea165 gets unpacked to gcc-cross-initial-4.5-r24.0+svnr167449/gcc-4.5/gcc-4_5-branch
Dec 10 22:54:43 <dfoley> and good: c63e55564a8840083dbd8634b10fe6f76d1f1354 gets unpacked to gcc-cross-initial-4.5-r24.0+svnr167449/gcc-4.5
Dec 10 22:54:54 <kergoth_> interesting
Dec 10 22:56:19 <kergoth_> that doesn't make any sense :(
Dec 10 22:56:42 <kergoth_> gcc-4.5.inc does a do_unpack_append which runs rename_srcdir, which renames it from gcc-4_5-branch to gcc-4.5..
Dec 10 22:56:46 <kergoth_> hmm
Dec 10 22:58:10 <kergoth_> dfoley: well, you can of course revert for the time being -- i'm looking into it.  am able to reproduce it.
Dec 10 22:58:49 <dfoley> sure, no problem
Dec 10 22:59:06 <kergoth_> thanks for the report
Dec 10 23:04:17 <kergoth_> ack, i j ust got a traceback from the queue feeder on exit of a bitbake -c clean gcc-cross-initial
Dec 10 23:04:21 * kergoth_ adds to the list
Dec 10 23:06:01 <Crofton|work> tharvey, it looks like desktop does not install the one from i2c-tools
Dec 10 23:06:11 <Crofton|work> oe now installs it is i2c-tools-user
Dec 10 23:07:44 <kergoth_> dfoley: bingo, i found the issue :)
Dec 10 23:07:48 * kergoth_ fixes
Dec 10 23:07:55 <dfoley> kergoth_: cool
Dec 10 23:08:06 <kergoth_> at least, i think i did
Dec 10 23:08:08 <kergoth_> lets confirm..
Dec 10 23:09:12 <tharvey> Crofton|work, was just looking at the same - ubuntu does not have that file in its kernel headers, instead its part of glibc-dev
Dec 10 23:09:48 <Crofton|work> at any rate, OE is no longer overwriting the kernel one
Dec 10 23:10:00 <tharvey> ah, didn't realize you made the change - thx for fixing
Dec 10 23:10:05 <Crofton|work> np
Dec 10 23:10:15 <kergoth_> dfoley: got it :)
Dec 10 23:10:16 <Crofton|work> it was biting me really hard
Dec 10 23:10:44 <tharvey> I ran into it when I was installing i2c-dev in my sdk - my solution was to take that out of the sdk 
Dec 10 23:11:35 <kergoth_> dfoley: that should do it, please confirm, if you would
Dec 10 23:11:45 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * r8b0753c090 10bitbake.git/lib/bb/build.py: 
Dec 10 23:11:45 <CIA-101> build: don't create ${B} when the 'dirs' flag is unset
Dec 10 23:11:45 <CIA-101> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Dec 10 23:12:04 <kergoth_> actually, falling back to ${B} when dirs is unset is pretty lame period
Dec 10 23:12:09 <kergoth_> it should probably be WORKDIR
Dec 10 23:12:10 <kergoth_> if anything
Dec 10 23:12:26 <kergoth_> all our important tasks either set dirs or chdir manually
Dec 10 23:12:30 <kergoth_> so i don't think anything relies on this
Dec 10 23:12:42 * kergoth_ will have to test
Dec 10 23:14:35 <dfoley> kergoth_: yes, latest commit fixes it
Dec 10 23:14:48 <kergoth_> great
Dec 10 23:17:23 <kergoth_> screw it, i'm merging my persist data api rework
Dec 10 23:18:41 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rd9e8b8af30 10bitbake.git/lib/bb/persist_data.py: (log message trimmed)
Dec 10 23:18:41 <CIA-101> Rework the persist_data API
Dec 10 23:18:41 <CIA-101> Rather than having to run .addDomain() and then .getValue(domain, key),
Dec 10 23:18:41 <CIA-101> .setValue(domain, key), etc, now it just works as mappings.
Dec 10 23:18:41 <CIA-101> As an example:
Dec 10 23:33:14 <kergoth_> ugh
Dec 10 23:33:22 <kergoth_> bb.fetch.fetcher_compare_revisons(d)
Dec 10 23:33:33 <kergoth_> could we at least spell our functions correctly, please?
Dec 10 23:33:34 <kergoth_> :)
Dec 10 23:34:15 <Jay7> Off->On->Suspend
Dec 10 23:34:21 <kergoth_> heh
Dec 10 23:57:56 <ka6sox4> bluelightning: ping?
Dec 11 00:11:40 <tharvey> kergoth_, python2.6 from buildout under chroot - bitbake can't find time module - where does time module typically come from?
Dec 11 00:12:00 <tharvey> I may not have the buildout python2.6 configured properly
Dec 11 00:12:23 <kergoth_> hmm, strange
Dec 11 00:12:37 <kergoth_> its built in, i thought -- maybe it didn't build it due to some dependency it couldn't find?
Dec 11 00:12:40 <kergoth_> hmm
Dec 11 00:12:46 <tharvey> possibly
Dec 11 00:13:11 <tharvey> I really don't have a huge reason for using hardy as my build system, perhaps I'll move to another distro for the chroot and not have to deal with buildout python
Dec 11 00:13:55 <kergoth_> might be a log for the python build in the buildout
Dec 11 00:13:56 <kergoth_> not sure
Dec 11 00:14:05 <tharvey> not really clear from buildout how I'm supposed to configure a standalone python to run.  I created an /etc/profile.d/python that set PYTHONHOME and PYTHONPATH and augmented PATH but profile.d doesn't seem to get used for my chroot user
Dec 11 00:14:15 <kergoth_> it should create one
Dec 11 00:14:21 <kergoth_> look in the bin dir in the buildout
Dec 11 00:14:23 <CIA-101> 03Chris Larson <chris_larson@mentor.com> 07master * rc51ed5d7a9 10bitbake.git/lib/bb/ (6 files in 3 dirs): 
Dec 11 00:14:23 <CIA-101> Rename command events, adjust compareRevisions
Dec 11 00:14:23 <CIA-101> - Moved the logic for comparing revisions from cooker into command
Dec 11 00:14:23 <CIA-101> - Removed 'Cooker' from the event names
Dec 11 00:14:23 <CIA-101> - Renamed the 'ExitCode' event into CommandExit, and changed CommandFailed to
Dec 11 00:14:24 <kergoth_> both a virtualenv and a python
Dec 11 00:14:46 <kergoth_> all you need to do is point your PATH there, or create a virtualenv and use that
Dec 11 00:14:47 <kergoth_> either way
Dec 11 00:14:52 <kergoth_> afaik, anyway
Dec 11 00:14:58 <kerim> i need to build my own embedded linux system.For my tiny system
Dec 11 00:15:09 <kerim> how can i make a system for tiny 
Dec 11 00:15:20 <kergoth_> we'd need way more information than that
Dec 11 00:15:27 <kerim> like lfs for beagleboard system
Dec 11 00:15:30 <kergoth_> bitbake can build for any number of different devices.
Dec 11 00:15:44 <kerim> hmmmmmm
Dec 11 00:15:50 <kerim> i know bitbake
Dec 11 00:15:52 <kergoth_> okay, beagleboard.  set MACHINE to beagleboard, DISTRO to a distro of your choice (i'd suggest minimal or angstrom-2010.x), and then bitbake micro-image (or whatever else you want to build for it)
Dec 11 00:15:59 <kergoth_> and read the OE manual :)
Dec 11 00:16:07 <kerim> ;)
Dec 11 00:19:47 <Jay7> well.. what is broken today and need buildtest? :)
Dec 11 00:29:20 <Jay7> here is my sample syntax for QA image testing http://pastebin.ca/2016058
Dec 11 00:29:55 <Jay7> every test from QA_TESTS will be separate shell script
Dec 11 00:30:14 <Jay7> may be..
Dec 11 00:30:17 <Jay7> or may be not :)
Dec 11 00:33:31 * Jay7 -> sleep
Dec 11 00:39:33 <kergoth_> whee, almost done with the bb.event rewrite
Dec 11 00:39:37 * kergoth_ goes to work out
Dec 11 02:09:53 <ka6sox> khem, you still want me to kick garnet?
Dec 11 02:21:00 <CMoH> hey. i'm trying to get bbappend to work but i keep getting blah.bbappend is not a bitbake file
Dec 11 02:23:59 <foerster|away> CMoH: which version of bitbake?
Dec 11 02:24:04 <CMoH> 1.10.1
Dec 11 02:24:06 <foerster|away> i think it requires current master
Dec 11 02:24:46 <CMoH> are you using .bbappend between different layers?
Dec 11 02:25:02 <CMoH> bblayers i mean
Dec 11 02:25:30 <foerster> i'm not actually using bblayers yet, but the commit 9fe82429168e0f5c3f4778275d910984ba1c7752 in bitbake is in master
Dec 11 02:25:47 <foerster> that commit enabled bblayers
Dec 11 02:26:12 <foerster> switch to bitbake master branch
Dec 11 02:26:25 <CMoH> sec; checking
Dec 11 02:27:17 <CMoH> yup; seems like it's not present in 1.10.1
Dec 11 02:29:35 <bsl> Can someone help me resolve a recipe issue?  Wireshark recipe giving me trouble with libtool "Version mismatch error."
Dec 11 02:31:04 <CMoH> though the commit is from july and 1.10.1 is from october
Dec 11 02:31:33 <foerster> CMoH: 1.10 was probably branched before that though
Dec 11 02:32:03 <CMoH> must be; 1.10.0 was tagged in august 
Dec 11 02:32:18 <CMoH> how can you find in git when a branch was created btw?
Dec 11 02:32:27 <CMoH> i'm new to git :)
Dec 11 02:33:45 <foerster> well, one way (probably not the best) is    git checkout 1.10     git log master..HEAD
Dec 11 02:33:53 <foerster> shows it was branched in april
Dec 11 02:34:03 <bsl>  git log [<options>] [<since>..<until>] [[--] <path>...] 
Dec 11 02:35:31 <CMoH> aha!
Dec 11 02:35:37 <CMoH> damn...
Dec 11 02:36:33 <foerster> current master is much faster anyway - it now has parallel recipe parsing
Dec 11 02:36:50 <CMoH> i know; problem is i can't tell everyone "get master and see if it works"
Dec 11 02:36:58 <foerster> :)
Dec 11 02:36:58 <CMoH> when's 1.11 planned?
Dec 11 02:37:01 <foerster> soon
Dec 11 02:37:09 <CMoH> 1 day? 1 month? 1 year? :D
Dec 11 02:37:37 <CMoH> or is it on a "when it's ready" idea
Dec 11 02:37:38 <foerster> that's up to kergoth, but I know her said he wants to release it soon.  WOrking on finishing up a few more outstanding items.
Dec 11 02:37:45 <CMoH> cool
Dec 11 02:38:53 <CMoH> ok - thanks; i'll tag a working commit in the meantime then
Dec 11 02:39:02 <kergoth> CMoH: 1 month max, more likely 2-3 weeks
Dec 11 02:39:11 <CMoH> hey - thanks
Dec 11 02:39:18 <kergoth> we need to get all remaining items merged from poky's bitbake so we're in sync
Dec 11 02:39:27 <kergoth> and we need to finish up the separation of the ui and server work
Dec 11 02:39:33 <kergoth> those are the biggest ones at this point
Dec 11 02:39:46 <CMoH> i've found the poky repository in my browser while googling for bbappends
Dec 11 02:40:11 <CMoH> i gather bitbake internally has a server/ui separation now?
Dec 11 02:41:01 <foerster> CMoH: not yet in master, but yes.  
Dec 11 02:41:15 <CMoH> sounds like fun :)
Dec 11 02:41:33 <foerster> they run in different processes, which means things are slowly becoming less coupled
Dec 11 02:42:07 <foerster> their lifetime is still tied together, but it paves the way for a bitbake daemon in the future
Dec 11 02:42:42 <CMoH> why a daemon?
Dec 11 02:43:27 <foerster> various neat reasons.  Like, one bitbake daemon running, using inotify to watch for bb changes, etc.
Dec 11 02:43:42 <foerster> Or, so we can allow eclipse tools to connect and do builds, etc
Dec 11 02:43:45 <CMoH> though i have to say it sounds nice to use separate UI/server for a build machine and such
Dec 11 02:44:10 <kergoth> man, i'm *SO* close to having the bb.event rewrite done, its tantalizing
Dec 11 02:44:22 <kergoth> hrmmm
Dec 11 02:44:36 <foerster> damn cold in here
Dec 11 02:44:46 <kergoth> the hard part was the metadata, of course -- events which are handled by handlers in the metadata have to get the metadata injected into them, so the handler can access it
Dec 11 02:44:57 <kergoth> but we can't bind the metadata to the event earlier, because you can't pickle the metadata
Dec 11 02:45:02 <kergoth> think i've got it though
Dec 11 02:45:08 <foerster> sounds difficult ;)
Dec 11 02:45:26 <kergoth> created a dispatcher which injects when firing, added the metadata handlers to that, then added the dispatcher to the main dispatcher as a handler ;)
Dec 11 02:45:35 <kergoth> a bit nested there
Dec 11 02:45:44 <kergoth> so the main dispatcher fires, which in turn fires all the metadata handlers
Dec 11 02:45:50 <kergoth> i think its fairly clean actually
Dec 11 02:46:00 <kergoth> as much as we can get until/if we create a recipe class, anyway
Dec 11 02:46:20 <foerster> so this does away with the worker_pid crap?
Dec 11 02:46:27 <foerster> or not yet?
Dec 11 02:46:38 <kergoth> yep
Dec 11 02:46:39 <kergoth> thats all gone
Dec 11 02:46:47 <kergoth> the ui stuff, the fire_class_handlers crap, all gone
Dec 11 02:47:07 <foerster> you must have eaten your wheaties this week - been cranking out some major rewrites
Dec 11 02:49:39 <kergoth> yeah, crazy
Dec 11 02:49:42 <kergoth> on a roll
Dec 11 02:50:17 <kergoth> https://github.com/kergoth/bitbake/wiki/Design-Thoughts-Event
Dec 11 02:50:24 <kergoth> that's what i just implemented
Dec 11 02:51:31 <kergoth> just need to confirm that i'm handling the worker correctly
Dec 11 02:51:44 <foerster> I can't do much other than localized changes at this point, as I don't have enough grasp of the whole beast
Dec 11 02:52:54 <CMoH> is there any way i can verify the .bbappend was parsed and successfully appended?
Dec 11 02:53:02 <kergoth> set FOO=bar in the bbappend
Dec 11 02:53:06 <kergoth> bitbake -e foo | grep \^FOO
Dec 11 02:53:07 <kergoth> :P
Dec 11 02:53:47 <CMoH> ah, still there
Dec 11 02:54:15 <CMoH> for now i'll just check tomorrow then
Dec 11 02:54:21 <CMoH> when the build finishes
Dec 11 02:55:55 <CMoH> as a remark, with bblayers i set BBPATH in bblayers.conf; why should i still have it set in the environment?
Dec 11 02:56:31 <kergoth> you don't need it in the environment.
Dec 11 02:56:34 <CMoH> oh, as another remark: when i had BBFILES defined in local.conf, bblayers didn't work. only after commenting them out altogether the second layer got parsed
Dec 11 02:56:34 <kergoth> there's no point to it
Dec 11 02:56:37 <kergoth> all you need is PTH
Dec 11 02:56:38 <kergoth> PATH
Dec 11 02:56:39 <kergoth> that's right
Dec 11 02:56:44 <kergoth> the layer.conf in each layer adjusts BBFILES
Dec 11 02:56:57 <kergoth> set PATH in the env, remove BBFILES from local.conf, and you're good to go
Dec 11 02:57:20 <CMoH> no, thing is you still have a sanity check asking me to set BBPATH (which i removed earlier)
Dec 11 02:57:37 <kergoth> well, neither master nor 1.10 do that.
Dec 11 02:57:48 <CMoH> interesting
Dec 11 02:57:50 <kergoth> it sounds like you're not cd'd into the dir where conf/bblayers.conf lives or below it
Dec 11 02:57:58 <kergoth> thats how it finds it, it searches up from where you are
Dec 11 02:58:25 <CMoH> okay; i have OEBASE and BB_ENV_EXTRAWHITE in the env
Dec 11 02:58:47 <kergoth> what's OEBASE?
Dec 11 02:58:49 <kergoth> i highly doubt you need that
Dec 11 02:59:20 <kergoth> https://github.com/kergoth/OE-BBLayers/blob/master/conf/bblayers.conf
Dec 11 02:59:24 <kergoth> that's my setup, personally
Dec 11 02:59:37 <kergoth> actually its slightly different than that now, should update it
Dec 11 02:59:39 <CMoH> CRITICAL: Unable to parse ${OEBASE}/openembedded/conf/layer.conf: file ${OEBASE}/openembedded/conf/layer.conf not found in ${OEBASE}:${OEBASE}/openembedded-internal:${OEBASE}/openembedded
**** ENDING LOGGING AT Sat Dec 11 02:59:57 2010