**** BEGIN LOGGING AT Wed Jan 18 02:59:57 2012
Jan 18 03:03:41 <khem> kergoth: yeah more need to have sane distros for build support
Jan 18 03:03:57 <khem> so we can safely ASSUME_PROVIDED this stuff
Jan 18 07:45:49 <halstead> In ten minutes the main website, wiki, and git.yoctoproject.org will go down for a few minutes for kernel updates.
Jan 18 07:48:12 <slaine> halstead: going dark for SOPA ;)
Jan 18 07:48:43 <halstead> Only for about 5 minutes. :)
Jan 18 07:48:55 <slaine> what a half hearted protest ;)
Jan 18 07:50:26 <halstead> If we had planned ahead to join in I would be all for it.
Jan 18 08:08:17 <halstead> We are back up.
Jan 18 08:12:21 <ka6sox> I need to do that on git.openembedded too.
Jan 18 08:12:39 <ka6sox> probably not tonight though :D
Jan 18 11:32:42 <JaMa|Off> bluelightning: ping
Jan 18 11:32:49 <bluelightning> hi JaMa|Off
Jan 18 11:33:13 <bluelightning> what's up?
Jan 18 11:33:17 <JaMa|Off> hi, 1st thanks for improving bitbake logging :)
Jan 18 11:33:33 <bluelightning> JaMa|Off: no problem :) If you have any further suggestions please let me know
Jan 18 11:33:49 <JaMa|Off> when there is some issue and summary is shown (number of errors and warnings)
Jan 18 11:34:10 <JaMa|Off> can we get number of skipped/executed tasks again?
Jan 18 11:34:13 <JaMa|Off> like: NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded.
Jan 18 11:34:31 <JaMa|Off> it shows this when build is successfull but not when there is fatal error
Jan 18 11:34:44 <bluelightning> hmm yes I noticed that is not shown when errors occur; it looked deliberate digging through the history but I could have sworn it wasn't always like that :/
Jan 18 11:35:18 <bluelightning> should be an easy fix though
Jan 18 11:35:35 <JaMa|Off> I can digg some cooker logs for it, I thought it was shown until improved summary
Jan 18 11:36:00 <bluelightning> that's what I thought too, I think I reverted that patch and it still didn't show though
Jan 18 11:36:22 <bluelightning> brb
Jan 18 11:36:35 <JaMa|Off> ah, I see
Jan 18 15:42:01 <JaMa|Off> any ide why one of cooker.log file contains only a log of python functions (like declarations)?
Jan 18 15:46:08 <kergoth> yeah, that is odd, it seems like the cooker is emitting two files one with -e output, one with the actual log, but hte former is misnamed. haven't had a chance to look at the code, figured someone in here would know whats going on
Jan 18 15:46:30 <kergoth> would also be nice to either move the old logs out of the way or at least symlink the latest
Jan 18 15:46:32 <kergoth> heh
Jan 18 15:46:51 <JaMa|Off> at least put them to some subdirectory of tmpdir not directly there..
Jan 18 15:47:11 <JaMa|Off> tmp-eglibc/cooker/
Jan 18 15:48:28 * JaMa|Off is using tee wrapper anyway.. and when all machines are built grep ERR log.*;
Jan 18 15:50:18 <kergoth> indeed
Jan 18 15:57:00 <denisATeukrea> hmmm
Jan 18 15:57:01 <denisATeukrea> hi
Jan 18 15:57:03 <denisATeukrea> Package /home/denis/embedded/oe-core/angstrom-bleeding/build/tmp-angstrom_2010_x-eglibc/deploy/ipk/armv7a/wpa-supplicant-cli_0.7.3-r7_armv7a.ipk disappeared on us!
Jan 18 15:57:07 <denisATeukrea> strange isn't it
Jan 18 15:57:18 <denisATeukrea> it's from do_rootfs
Jan 18 15:57:37 <denisATeukrea> and the ipk is there
Jan 18 15:58:13 <denisATeukrea> ar x wpa-supplicant-cli_0.7.3-r7_armv7a.ipk => file format not recognized....ah ok
Jan 18 15:58:19 <denisATeukrea> I'll fix locally
Jan 18 15:58:34 <denisATeukrea> it's empty
Jan 18 16:02:21 <denisATeukrea> so I rebuild and it should be fixed
Jan 18 16:02:26 <denisATeukrea> sorry for the noise
Jan 18 16:36:03 <agherzan> Hello everybody!
Jan 18 16:37:18 <agherzan> I need help regarding linux-yocto kernel. Is here anybody who can help me in a kernel related problem?
Jan 18 16:37:32 <agherzan> (hope... so...)
Jan 18 16:40:44 <zeddii> agherzan, what's the question?
Jan 18 16:42:17 <agherzan> Well, i want to add some configs to a beagleboard linux-linaro kernel.
Jan 18 16:42:33 <agherzan> I added a dsorry linux-yocto
Jan 18 16:42:40 <agherzan> *sorry linux-yocto
Jan 18 16:42:47 <zeddii> ok. that I can help with.
Jan 18 16:42:50 <agherzan> So i added a defconfig file in linux-yocto
Jan 18 16:43:04 <agherzan> and added this file to SRC_URI
Jan 18 16:43:06 <agherzan> NOTHING WORKS
Jan 18 16:43:16 <zeddii> which branch, master ?
Jan 18 16:43:23 <agherzan> I'm desperate!
Jan 18 16:43:25 <agherzan> Yes,
Jan 18 16:43:33 <zeddii> stay away from full defconfigs. what exactly are you trying to change ?
Jan 18 16:43:54 <agherzan> For example
Jan 18 16:43:54 <agherzan> CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
Jan 18 16:44:04 <agherzan> But this is just an example
Jan 18 16:44:39 <zeddii> just put the options that you want in "<foo>.cfg". and add the foo.cfg to the SRC_URI via a bbappend, just like any other patch.
Jan 18 16:44:45 <agherzan> actually what i want to do is to run a beagleboard in qemu-linaro. I did this but my serial is not redirected to main qemu window.
Jan 18 16:45:06 <agherzan> I see serial only on serial screen - CTRL+3
Jan 18 16:45:25 <agherzan> i did that and didn't work
Jan 18 16:45:50 <agherzan> my final .config is not changed at all
Jan 18 16:46:36 <zeddii> oh really? I always have a config or two being overlayed and all mine work. I'll double check on master and let you know.
Jan 18 16:47:34 <agherzan> ok zedii
Jan 18 16:52:55 <agherzan> i tried this in the main linux-yocto_3.0.bb  file.
Jan 18 16:53:15 <agherzan> Added my .cfg file to SRC_URI...
Jan 18 16:53:19 <agherzan> No change...
Jan 18 16:53:57 <zeddii> I just switched to using the factored src_patches() code in master. so there have been changes in this area. I'll know if you've found a bug shortly.
Jan 18 16:58:38 <zeddii> agherzan, argh .. indeed. I see what happened now. I'm working on a patch.
Jan 18 16:59:11 <agherzan> Please giveme a clue.
Jan 18 16:59:16 <agherzan> I cand patch and commit.
Jan 18 16:59:18 <agherzan> can*
Jan 18 16:59:22 <agherzan> Just gimme a hint
Jan 18 16:59:47 <zeddii> it's detailed. I'll need to work out how to fix it, there is an issue with the new src_patches. I have to try some things.
Jan 18 17:09:01 <agherzan> Hmmm.. i'm found the problem as well..
Jan 18 17:15:23 <zeddii> patch sent to the list.
Jan 18 17:15:29 * zeddii goes back to 3.2 wranging.
Jan 18 17:15:32 <zeddii> wrangling.
Jan 18 17:18:55 <agherzan> patch_dirs="${patch_dirs} ${WORKDIR}"
Jan 18 17:19:00 <agherzan> This should solve the problem
Jan 18 17:19:07 <agherzan> uh ... :))
Jan 18 17:19:27 <agherzan> you sent patch to list... dammit you were faster :)
Jan 18 17:20:58 <agherzan> Thank you very much.
Jan 18 18:36:14 <zenlinux> Hi RP__, I dug a bit into the populate_sysroot_setscene bug that's causing issues with useradd builds from sstate.
Jan 18 18:36:23 <zenlinux> I can detect the race condition reliably (e.g, dbus gets run before base-passwd), and I've tried touching empty passwd and group files in the target sysroot when this happens, so dbus can add entries to the files without causing failures.
Jan 18 18:36:32 <zenlinux> However, the problem is that when the build system gets around to installing base-passwd's files, pseudo apparently sees the passwd and group files and tries to use them - and this then fails because the root account is not in passwd/group.
Jan 18 18:36:40 <zenlinux> I can either keep going down this path and start adding increaslingly ugly hacks to force this approach to work, but I was wondering if there is just some way we can force base-passwd to complete its setscene tasks at the start of the build?
Jan 18 18:53:21 * kergoth works on fixing external-csl-toolchain
Jan 18 18:58:33 <bluelightning> zenlinux: I'll defer to Richard but I wonder if it will mean needing to set up dependencies between setscene tasks (I don't think we have anything for that atm)
Jan 18 18:59:56 <zenlinux> bluelightning, that's exactly the problem
Jan 18 19:01:01 <zenlinux> I'm not sure what the implications would be to add this support, but I figure if we need it now for useradd support, we may need it later on for other features.
Jan 18 19:02:02 <kergoth> setscene tasks don't obey the dependencies of their corresponding tasks? that's a problem
Jan 18 19:03:22 <bluelightning> kergoth: I don't think they've needed to until now
Jan 18 19:04:06 <kergoth> heh, we got bit by that sort of ordering issue with pstage quite a few times
Jan 18 19:04:32 <bluelightning> zenlinux: if it's a new scheme, there shouldn't be any implications; if it's something which pulls over dependencies from the real tasks then there could be quite a few
Jan 18 19:04:42 <kergoth> heh, indeed
Jan 18 19:06:26 <zenlinux> can anyone suggest code areas to start reading within bitbake for me to get my head around what is involved?
Jan 18 19:10:40 <bluelightning> zenlinux: the scenequeue stuff in runqueue I would think
Jan 18 19:10:51 <bluelightning> bitbake/lib/bb/runqueue.py I mean
Jan 18 19:11:06 <zenlinux> cool, thanks
Jan 18 20:17:25 <sgw> halstead|afk: I think we need a buildhistory repo created on git.yp.org and the bluelightning can work with that.
Jan 18 20:17:35 <sgw> bluelightning: is that what's needed first?
Jan 18 20:17:43 <bluelightning> sgw: yes, I think so
Jan 18 20:28:03 <halstead> bluelightning, Are going to generate a new key pair just for this repo?
Jan 18 20:28:59 <sgw> halstead: it seems like pidge might be creating the repo already, she should generate a keypair for the pokybuilder user
Jan 18 20:29:15 <bluelightning> sgw: right, that's more or less what I was about to say :)
Jan 18 20:32:40 * bluelightning -> home, will be back on line when I get there
Jan 18 20:34:04 <halstead> Ok, pidge please ping me if you want me to take care of any steps.
Jan 18 21:34:02 <msm> is there a way to unload PSEUDO?
Jan 18 21:34:17 <msm> just set PSEUDO_DISABLED=1?
Jan 18 21:37:15 <msm> or clear LD_PRELOAD perhaps
Jan 18 21:43:55 <RP__> msm: clearing LD_PRELOAD isn't enough, pseudo will add itself back
Jan 18 21:44:05 <msm> RP__: im finding this out =)
Jan 18 21:44:44 <msm> turns out the pseudo error was just a warning i dont really *need* to fix atm
Jan 18 21:44:54 <msm> it was masking my real error
Jan 18 21:46:03 <fray> sorry missed the conversation, what happend w/ psuedo?
Jan 18 21:46:14 <fray> was it an error from pseudo or an ld_preload error or?
Jan 18 21:46:21 <msm> fray: i was trying to disable it in a image build step
Jan 18 21:47:13 <fray> ya.. then you need to set the environment and fork..
Jan 18 21:47:24 <fray> there are two variables.. PSEUDO_DISABLED -- it will stay in memory but won't do anything..
Jan 18 21:47:33 <fray> and PSEUDO_UNLOAD -- this will unload it on the next exec
Jan 18 21:47:51 <fray> on fork things will be enabled/disabled.. on exec things can be unloaded..
Jan 18 21:48:02 <fray> just have to set the right value before that happens
Jan 18 21:48:11 <pidge_> #oe
Jan 18 21:50:00 <msm> so I can do
Jan 18 21:50:15 <msm> export PSEUDO_UNLOAD=1; ./script-without-sudo.sh
Jan 18 21:50:16 <msm> ?
Jan 18 21:50:20 <msm> sudo = pseudo
Jan 18 21:50:27 <fray> ya
Jan 18 21:50:53 <msm> fray: ok
Jan 18 21:50:55 <msm> thanks
Jan 18 21:50:57 <fray> I will usually do something like "env PSEUDO_UNLOAD=1 script"
Jan 18 21:51:07 <fray> that runs env, which sets the environment, which runs script
Jan 18 21:58:48 <msm> fray: good deal. thanks
Jan 18 22:00:13 <fray> (obvious advantage of DISABLE of course is that you can set it to 0 and reenabled pseudo at any time)
Jan 19 00:17:16 <kergoth> whew, finally, almost done getting mentor's external csl toolchain changes ready for push
**** ENDING LOGGING AT Thu Jan 19 02:59:57 2012