**** BEGIN LOGGING AT Thu Aug 08 02:59:59 2013
Aug 08 07:38:04 <eren> morning
Aug 08 09:10:13 <Krz> Hi guys, I find in some poky recipes in 'do_configure' call to 'oe_runconf'. Do you know where is it defined? I would like to play with its flags.
Aug 08 09:11:54 <Zagor> Krz: meta/classes/autotools.bbclass
Aug 08 10:20:56 <bluelightning> morning all
Aug 08 11:47:20 <Crofton|work> gm
Aug 08 12:09:01 <bluelightning> morning Crofton|work
Aug 08 12:16:41 <Net147> morning bluelightning
Aug 08 12:16:47 <bluelightning> hi Net147
Aug 08 12:28:41 <Net147> I wonder if implementing OVA image support would be worthwhile for the build appliance image to make it easier to use with VirtualBox (and avoid the 4 CPU + non-commercial limitations with VMware Player)
Aug 08 12:29:25 <bluelightning> sounds like it would be useful...
Aug 08 12:31:44 <Net147> then you would have a single OVA that would work with both VirtualBox and VMware
Aug 08 12:32:01 <Net147> and potentionally other software that supports OVA
Aug 08 12:33:48 <Net147> perhaps a weekend project =)
Aug 08 13:02:10 <Krz> is there any way I can compile some Yocto pkgs manually and let Yocto know they are compiled? I mean libtool-native/m4/automake and few others.
Aug 08 13:07:36 <Krz> I'm trying to run bitbake under cygwin, that's why standard way doesn't do for me
Aug 08 13:09:48 <rburton> Krz: you probably want ASSUME_PROVIDED
Aug 08 13:13:55 <Krz> so on bitbake command line I do: ASSUME_PROVIDED="m4 libtool-native etc" bitbake abc
Aug 08 13:14:07 <Krz> is that the way of using this variable?
Aug 08 13:17:04 <rburton> you can use it in local.conf
Aug 08 13:17:30 <rburton> anything in ASSUME_PROVIDED isn't built, so you can put m4-native
Aug 08 13:18:00 <rburton> oh, you'll want to += it
Aug 08 13:18:12 <rburton> as it has a default, see bitbake.conf
Aug 08 13:19:01 <BCMM> i accidentally started bitbake before i set MACHINE correctly (and built a bit for x86 before ctrl-c'ing). do i need to run some kind of "make clean" style command before building for ARM?
Aug 08 13:19:29 <rburton> nah
Aug 08 13:19:31 <Zagor> BCMM: only if you want to reclaim the disk space
Aug 08 13:19:32 <Krz> rburton: great, cheers, i will play with it
Aug 08 13:19:45 <rburton> BCMM: the sysroot where the build happens is per-MACHINE anyway
Aug 08 13:19:50 <Zagor> BCMM: it builds into different dirs per machine
Aug 08 13:19:53 <BCMM> Zagor: thanks. if i did want to reclaim the space, what do i do?
Aug 08 13:21:00 <Zagor> I'm not sure what is the correct way to clean just one build.
Aug 08 13:21:29 <rburton> MACHINE=oldmachine wipe-sysroot
Aug 08 13:21:35 <BCMM> rburton: thanks!
Aug 08 13:21:53 <rburton> i wonder if wipe-sysroot is documented
Aug 08 13:22:17 <BCMM> unconnectedly, approximately what size is a "vanilla" build of poky? i know this will vary substantially by architechture and whatnot, just want a ballpark
Aug 08 13:22:35 <BCMM> sorry, i mean in terms of finished distro disk requirements
Aug 08 13:22:47 <rburton> BCMM: the docs say 100G as a guideline for reasonable use
Aug 08 13:23:05 <BCMM> rburton: uh, that's space for building right?
Aug 08 13:23:08 <rburton> BCMM: its less to do a single build, but you don't want to be having to clean stuff all the time
Aug 08 13:23:12 <rburton> BCMM: yeah, total usage
Aug 08 13:23:17 <rburton> oh you mean final image size?
Aug 08 13:23:21 <BCMM> yeah, sorry
Aug 08 13:23:30 <bluelightning> Krz: some things are not suitable to be added to ASSUME_PROVIDED though, e.g. things which we patch to support cross-compilation
Aug 08 13:23:35 <BCMM> i clarified but probably after you typed your message :)
Aug 08 13:24:44 <BCMM> also is X11 enabled in the default configuration? sorry for the newbie questions, this is my first build
Aug 08 13:25:00 <rburton> BCMM: looks like my core-image-sato is probably something like 200M.  as a compressed tarball its 61M, and my disk image with 500M free space is 700M
Aug 08 13:25:10 <rburton> BCMM: yes, it is.
Aug 08 13:25:19 <Net147> why does the build appliance manual mention OVF but it isn't used in the build appliance ZIP? https://www.yoctoproject.org/documentation/build-appliance-manual
Aug 08 13:28:35 <Krz> bluelightning: even if I patch them on my own?
Aug 08 13:28:54 <bluelightning> Krz: sure, you can do that... but why would you?
Aug 08 13:32:10 <Krz> Trying to run Yocto uild under cygwin. Some of base pkgs (m4/libtool-native/etc) fail do not build in Yocto, but I can build them standalone in cygwin. That's the point
Aug 08 13:33:17 <Zagor> I recommend using a virtual machine instead of cygwin. it is much faster.
Aug 08 13:36:42 <Krz> I believe VM is great choice. But native Windows (so bins + cygwin.dll) is a requirement for the project. I know Yocto does not support cygwin, but at the end of the day I provided all of prerequisites
Aug 08 13:47:38 <lpapp> kergoth: did you get any chance to look into the build break for meta sourcery?
Aug 08 13:50:55 <Krz> I have my pkgs compiled outside Yocto, I have ASSUME_PROVIDED, now how I point Yocto to directory I built my stuff? Is there any Yocto PTH variable?
Aug 08 13:51:06 <Krz> *Yocto PATH
Aug 08 14:04:35 <rburton> Krz: PATH should work
Aug 08 14:05:17 <eren> any idea on live image deployment?
Aug 08 14:30:23 <BCMM> rburton: thanks. what's the simplest way to disable X11? i'm setting up a headless system
Aug 08 14:30:36 <rburton> BCMM: remove x11 from DISTRO_FEATURES
Aug 08 14:30:47 <rburton> then you're certain it can't creep in
Aug 08 14:30:53 <BCMM> rburton: sorry for the noob question, but where is DISTRO_FEATURES?
Aug 08 14:31:05 <rburton> you can do a build without refering to x and you'll be fine but you might find libx11 sneaks in, via dbus or something
Aug 08 14:31:17 <rburton> BCMM: you can set it in your local.conf, or make a new distro and set it there
Aug 08 14:31:38 <BCMM> rburton: "make a new distro" would mean basically a new build directory right?
Aug 08 14:31:49 <rburton> BCMM: no, a new distro configuration, like poky.
Aug 08 14:32:10 <BCMM> rburton: what would that entail?
Aug 08 14:32:42 <rburton> BCMM: for now its probably easier to just edit the distro features in your local.conf
Aug 08 14:33:37 <BCMM> rburton: uh, so i need to set the DISTRO_FEATURES var, but i'm not sure what to
Aug 08 14:33:48 <rburton> BCMM: if you use use "bitbake -e [image] |grep DISTRO_FEATURES=" then you'll see what the current value is
Aug 08 14:33:58 <rburton> then you can set it to that, minus x11
Aug 08 14:34:30 <BCMM> rburton: thanks!
Aug 08 14:34:50 <BCMM> is it basically safe to ctrl-c out of bitbake? i guess it will just resume when run again?
Aug 08 14:34:54 <rburton> BCMM: yes
Aug 08 14:35:14 <rburton> BCMM: first C-c says "stop when you've finished the current tasks", second is "stop now"
Aug 08 14:35:30 <BCMM> and is there any way to get some feedback on the status of the current builds? mine has been stuck on do_fetch for two packages for a long time now
Aug 08 14:36:06 <rburton> BCMM: some packages are pretty big...
Aug 08 14:36:18 <rburton> but no, there's no fetch progress bar
Aug 08 14:36:36 <BCMM> anyway, going to restart with a custom DISTRO_FEATURES i think
Aug 08 14:36:48 <rburton> BCMM: remember to wipe-sysroot if you change DISTRO_FEATURES
Aug 08 14:38:36 <Krz> I used ASSUME_PROVIDED+="m4-native-1.4.16-r4 m4 m4-native" bitbake abc and it still tries to build m4-native :/
Aug 08 14:40:31 <BCMM> rburton: woah, there's quite a few of those. is there a guide somewhere for what the less obvious features actually do?
Aug 08 14:41:04 <rburton> BCMM: the reference docs mentions a lot of them
Aug 08 14:41:09 <BCMM> thanks
Aug 08 14:41:17 <rburton> BCMM: as you see, many are pretty self-explanatory
Aug 08 14:50:44 <BCMM> rburton: on the topic of wipe-sysroot, is it correct taht i have a sysroots dir in TMPDIR, not in BUILDIR?
Aug 08 14:51:45 <BCMM> wiperoot refers to $BUILDDIR/tmp/sysroots/ - is that based on the assumption that my TMPDIR is inside my BUILDIR?
Aug 08 14:53:21 <rburton> BCMM: good point.
Aug 08 14:53:37 <BCMM> i do seem to have a $BUILDDIR/tmp/ as well...
Aug 08 14:53:48 <rburton> BCMM: feel free to fix paths in the script if they're wrong, i should fix the script to ask bitbake where the sysroots are
Aug 08 14:54:03 <BCMM> which is odd sicne the defaulf config uses that directory for TMPDIR
Aug 08 14:54:13 <BCMM> rburton: i'm totally new and don't know what's going on...
Aug 08 14:54:35 <BCMM> but should i perhaps just symlink my tmp directory to where yocto seems to think it should belong and keep the default TMPDIR value?
Aug 08 14:54:40 <rburton> BCMM: you're right, there is an assumption there
Aug 08 14:54:43 <BCMM> i haven't the space to build on this disk...
Aug 08 14:54:57 <rburton> BCMM: personally i have a symlink from build/tmp to the real tmp, so i can save typing
Aug 08 15:17:12 <Crofton|work> ERROR: No available provider for dependency `distutils` of nativesdk-python-core
Aug 08 15:17:12 <Crofton|work> ERROR: Function failed: process_automatic_dependencies
Aug 08 15:34:48 <Song_Liu> https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status#Milestone_3
Aug 08 16:30:46 <mr_science> moin
Aug 08 16:30:52 <eren> hey
Aug 08 16:31:23 <eren> headless bsp for alix3d3 is nearly ready :P
Aug 08 16:32:31 <eren> at least it has framebuffer, sound, cs5536 companion chip, eth and it boots
Aug 08 16:33:12 <mr_science> yay
Aug 08 16:33:22 <mr_science> what's an alix3d3?
Aug 08 16:33:40 <eren> mr_science: http://pcengines.ch/alix3d3.htm
Aug 08 16:34:00 <eren> hehe
Aug 08 16:34:29 <eren> update kernel config, build core-image-minimal, get the image, dd into CF, boot cycle is long
Aug 08 16:35:04 <mr_science> ah, an amd geode...
Aug 08 16:35:13 <eren> yes
Aug 08 16:35:36 <mr_science> is it similar in other aspects to olpc xo-1 at all?
Aug 08 16:36:03 <eren> well, similar
Aug 08 16:36:11 <eren> AMD Geode LX700@0.8 W + 5536
Aug 08 16:36:15 <mr_science> haven't played with that for a while...   maybe i should try installing a yocyo image on it...
Aug 08 16:36:23 <eren> mine has LX800
Aug 08 16:36:28 <mr_science> *yocto even
Aug 08 16:36:38 <eren> it seems that xo-1 has the same chip with alix
Aug 08 16:36:54 * mr_science rubs his eyes with his elbows
Aug 08 16:37:10 <eren> mr_science: well, currently you cannot boot AMD Geode with default yocto
Aug 08 16:37:28 <eren> some kernel configuration should be enabled, on which I am currently working on
Aug 08 16:37:36 <mr_science> there's no xo-1 bsp/meta layer?
Aug 08 16:37:51 <mr_science> i thought i saw one a while back...
Aug 08 16:38:02 <eren> http://layers.openembedded.org/layerindex/layers/
Aug 08 16:38:05 <eren> apprently, no
Aug 08 16:38:34 <mr_science> apparently i need to steal yours and make one...
Aug 08 16:38:58 <eren> hehe
Aug 08 16:39:04 <mr_science> there should still be a lot of xo-1 hardware out there
Aug 08 16:39:12 <mr_science> one would think...
Aug 08 16:39:19 <eren> well, I appreciate any patches
Aug 08 16:39:26 <eren> http://github.com/eren/meta-alix3d3
Aug 08 16:39:35 <eren> I'm still working on it
Aug 08 16:39:58 <mr_science> not sure i would have anything to give without the hardware to test on...
Aug 08 16:40:06 <eren> sure
Aug 08 16:40:12 <mr_science> unless it's common across both machines
Aug 08 16:40:53 <eren> I'm happy today, at least
Aug 08 16:40:56 <eren> I managed to boot that thing
Aug 08 16:41:08 <eren> it still needs a lot of work
Aug 08 16:41:16 <mr_science> okay, if i watch your repo i might actually notice when things are stable-ish...
Aug 08 16:41:17 <eren> there's no /dev/ttyS0
Aug 08 16:41:35 <eren> I only have 1 VGA console
Aug 08 16:41:49 <eren> I should be able to switch between virtual ones with CTRL + F{1..9}
Aug 08 16:41:58 <eren> the latter one is related with getty, I guess
Aug 08 16:42:26 <mr_science> i need to get a few other thingsout of the way...  like installing my oldest kid into his new dorm room week after next...
Aug 08 16:42:42 <mr_science> check the inittab config
Aug 08 16:42:50 <mr_science> you should be able to enable more VTs
Aug 08 16:43:40 <mr_science> after that i should be able to at least make a build that *should* boot off the sdcard
Aug 08 16:43:51 <mr_science> *xo-1 build
Aug 08 16:45:10 <eren> yeah, I guess I need to learn how to configure inittab
Aug 08 16:46:16 <mr_science> but, time to collect some build data...
Aug 08 16:47:37 <mr_science> eren: i assume there's only VT set now?
Aug 08 16:47:42 <mr_science> *one
Aug 08 16:47:44 <eren> mr_science: yes
Aug 08 16:48:04 <mr_science> so make it look something like this:  http://paste2.org/vO1WnIat
Aug 08 16:48:21 <eren> ah, thanks
Aug 08 16:48:34 <eren> I'm wondering in which layer I should do this?
Aug 08 16:48:47 <eren> I guess I will put that under my seperate distro config (hambedded)
Aug 08 16:48:59 <eren> which will be based on poky reference distro, of course
Aug 08 16:49:29 <Krz> do you know any pseudo homepage?
Aug 08 16:49:52 <Krz> pseudo README says not very much, google the same
Aug 08 16:54:15 <bluelightning_> Krz: http://www.ibm.com/developerworks/library/os-aapseudo1/
Aug 08 16:59:59 <fray> pseudo 's "home" is git.yoctoproject.org
Aug 08 17:07:55 <eren> yay, eth is also working
Aug 08 17:07:57 <eren> great
Aug 08 17:08:21 <eren> the only thing that bothers me is configuration flags. I had "illegal instruction" problems before in some audio codec
Aug 08 17:08:50 <eren> it turned out that LX800 miss an instruction that regular x86 has, but GCC think that it's in LX800
Aug 08 17:08:59 <eren> I hope I won't dig into gcc flags again :(
Aug 08 17:10:14 <rburton> eren: oh that sounds like "fun"
Aug 08 17:12:35 <mr_science> i usually bug one of the gentoo toolchain devs...
Aug 08 17:14:01 <mr_science> sometimes i think they know more about gcc than upstream does...
Aug 08 17:16:44 <BCMM> my build is stuck on 2 very long do_fetch stages again. they're the raspberry pi kernel and firmware from a 3rd-party layer, and i think they're being fetched over git
Aug 08 17:16:55 <rburton> BCMM: kernels are big, firmwares are big.
Aug 08 17:16:56 <BCMM> is there a log file i can tail or something to see the progress of that?
Aug 08 17:17:07 <BCMM> rburton:
Aug 08 17:17:15 <BCMM> sorry, keyboard-mashed
Aug 08 17:17:19 <rburton> try tmp/work/machine/recipe/version/temp/log.do-fetch
Aug 08 17:17:31 <rburton> might have something useful, but i suspect it will just say that its started a git fetch
Aug 08 17:18:09 <BCMM> rburton: yeah, exactly that
Aug 08 17:18:44 <BCMM> it ends in DEBUG: Running export [snipped loads of environment] ; git clone --bare --mirror git://github.com/raspberrypi/firmware.git [snipped loads of path]
Aug 08 17:19:04 <rburton> you could use netstat or strace to verify that they are still downloading stuff i guess
Aug 08 17:19:21 <rburton> but kernels are giant and some firmware repos are huuuuge
Aug 08 17:19:22 <BCMM> it really doesn't log git's output anywhere then?
Aug 08 17:19:23 <mr_science> BCMM: check the network interface for traffic
Aug 08 17:19:39 <rburton> BCMM: it won't log the progress information from git, mainly as git doesn't produce it unless its on a terminal
Aug 08 17:19:42 <mr_science> gkrellmd is handy for that...
Aug 08 17:20:08 <BCMM> 2 connections to github in netstat... i guess i'll just stop being impatient
Aug 08 17:20:37 <mr_science> have a tasty beverage and go outside...
Aug 08 17:20:38 <BCMM> so far that's the only thing i prefer about gentoo's emerge... it has a fetch log you can tail
Aug 08 17:20:51 <rburton> BCMM: fwiw, that firmware repo is insanely huge
Aug 08 17:21:02 <rburton> still waiting for git to even start
Aug 08 17:21:15 <rburton> what the hell did they put in there :/
Aug 08 17:21:50 <rburton> still waiting!
Aug 08 17:22:37 <BCMM> it seems to have a precompiled linux kernel and modules in it as well as firmware
Aug 08 17:22:47 <rburton> sigh
Aug 08 17:22:58 <rburton> still waiting for the server to send the data!
Aug 08 17:22:59 <eren> rburton: yeah, it sounds like "fun" :)
Aug 08 17:23:07 <BCMM> does github have a way to display the total size of a repo?
Aug 08 17:23:49 <rburton> BCMM: just been looking, its not obvious if there is
Aug 08 17:23:57 <rburton> BCMM: i recommend a coffee :)
Aug 08 17:24:07 <rburton> ah, 1% downloaded at 22MB
Aug 08 17:24:22 <mr_science> git ls-remote does not appear to give size...
Aug 08 17:24:24 <rburton> so ~2G
Aug 08 17:24:32 <BCMM> rburton: that's weird
Aug 08 17:24:44 <rburton> oh its 1% of objects, not 1% of size
Aug 08 17:24:58 <BCMM> you can fit use a 2GB SD card for a whole raspi system including debian
Aug 08 17:25:13 <rburton> BCMM: its got history, so if they put 100 kernels in it, you're downloading 100 kernels
Aug 08 17:25:16 <rburton> without any diffs
Aug 08 17:25:49 <BCMM> i guess git doesn't have a way to just get the latest if you're not planning on committing changes?
Aug 08 17:26:10 <simar_> BCMM: du -sh .git/
Aug 08 17:26:29 <simar_> rough estimate, but still a good approximation.
Aug 08 17:26:35 <BCMM> simar_: i'd need to know the final size, but yeah...
Aug 08 17:26:57 <rburton> BCMM: it does, actually
Aug 08 17:27:21 <rburton> BCMM: but its a bit complicated to use for our use-case
Aug 08 17:27:47 <rburton> (shallow clones, is the term you're looking for)
Aug 08 17:30:59 <bluelightning_> meta-raspberrypi just needs to switch to something else for the firmware fetch
Aug 08 17:31:11 <bluelightning_> I think Andrei knows that, he just hasn't had time to address it yet
Aug 08 17:39:55 <mr_science> bluelightning_: like a versioned tarball maybe?
Aug 08 17:39:55 <BCMM> well, thanks for all the advice. i'll be patient
Aug 08 17:40:07 <bluelightning_> mr_science: right
Aug 08 17:40:54 <mr_science> yeah, the convenience of git starts to break down when the repo gets huge...
Aug 08 18:19:11 * mr_science does the formal release/deploy dance
Aug 08 18:19:34 <mr_science> damn, i left my black tie at home...
Aug 08 20:00:10 <mr_science> drippy taco day is another that doesn't go well with keyboards and such...
Aug 08 21:14:58 <abelloni> I want
Aug 08 21:15:01 <abelloni> oops
Aug 08 21:15:18 <abelloni> I want to specify that the kernel has to be installed on the rootfs
Aug 08 21:15:36 <abelloni> can I do that from my conf/machine.conf ?
Aug 08 21:38:47 <JaMa> someone seeing this with latest oe-core?
Aug 08 21:38:51 <JaMa> | DEBUG: Python function sysroot_cleansstate finished
Aug 08 21:38:51 <JaMa> | DEBUG: Executing shell function do_configure
Aug 08 21:38:51 <JaMa> | NOTE: make oldconfig
Aug 08 21:38:51 <JaMa> | make: *** No rule to make target `oldconfig'.  Stop.
Aug 08 21:38:51 <JaMa> | ERROR: oe_runmake failed
Aug 08 21:38:54 <JaMa> | ERROR: Function failed: do_configure (log file is located at /OE/oe-core/tmp-eglibc/work/qemux86_64-oe-linux/linux-yocto/3.8.13+gitAUTOINC+375cb6ebfd_f20047520a-r4.2/temp/log.do_configure.13055)
Aug 08 21:46:35 <mr_science> no rule to make target `oldconfig' in the kernel source?
Aug 08 21:46:46 <mr_science> something is very wrong somewhere...
Aug 08 21:56:48 <JaMa> mulhern: yes and the directory looks like kernel source, so it should work..
Aug 08 21:57:30 <mulhern> JaMa: I think that was somebody else's question.
Aug 08 21:58:09 <JaMa> mulhern: sorry it was for mr_science
Aug 08 21:58:38 <JaMa> hmm it's running in wrong directory...
Aug 08 22:00:30 <JaMa> OE qemux86-64@ ~/oe-core/tmp-eglibc/work/qemux86_64-oe-linux/linux-yocto/3.8.13+gitAUTOINC+375cb6ebfd_f20047520a-r4.2 $ find linux-qemux86-64-standard-build/
Aug 08 22:00:33 <JaMa> linux-qemux86-64-standard-build/
Aug 08 22:00:35 <JaMa> linux-qemux86-64-standard-build/.scmversion
Aug 08 22:00:38 <JaMa> linux-qemux86-64-standard-build/.config
Aug 08 22:00:40 <JaMa> linux-qemux86-64-standard-build/scripts
Aug 08 22:00:43 <JaMa> linux-qemux86-64-standard-build/scripts/basic
Aug 08 22:04:20 <BCMM> where should i expect to find completed images at the end of a build? are the images in tmp/deploy/images/ finished? why are they in /tmp?
Aug 08 22:07:07 <BCMM> (i mean tmp/)
Aug 08 22:07:31 <JaMa> BCMM: tmp as "build artifacts"
Aug 08 22:07:49 <BCMM> do you mean "is"?
Aug 08 22:08:22 <JaMa> if you remove tmp you can rebuild everything again from metadata -> that's why it's "tmp"
Aug 08 22:08:31 <BCMM> JaMa: ah, tmp contains everything that was produced by the build, as opposed to configured by the human?
Aug 08 22:08:48 <JaMa> BCMM: yes
Aug 08 22:09:08 <BCMM> thanks. i guess tmp/deploy/images is the finished product then?
Aug 08 22:09:24 <JaMa> yes
Aug 08 22:21:49 <mr_science> it's another one of those "everything new is a top priority" days...
Aug 09 00:46:07 <mr_science> yay, i get to package a new lib tonight...
Aug 09 00:47:01 <mr_science> although it seems a little odd that "agile" depends on me pulling that stuff out of you-know-where at a moment's notice...
Aug 09 00:47:24 <mr_science> i wonder if i'm in any of those books
**** ENDING LOGGING AT Fri Aug 09 02:59:59 2013