**** BEGIN LOGGING AT Fri Dec 30 02:59:57 2011 Dec 30 09:04:22 morning all Dec 30 11:32:09 Hello guyz/ Dec 30 11:32:16 Is anybody around? Dec 30 11:45:15 alephan: hi Dec 30 11:45:18 what's up? Dec 30 11:54:48 Hey. Dec 30 11:55:13 Sorry i don't see that something change in this window. :) Dec 30 11:55:16 changed* Dec 30 11:55:45 I fixed 2 bugs in bugzilla and commited to openembedded-core Dec 30 11:55:49 mailing list Dec 30 11:56:59 So, i wanted to know the state workflow of bugs so that i can change the status to a proper one. Dec 30 11:57:13 For example: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1845 Dec 30 11:57:16 This is on NEW. Dec 30 11:57:46 http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/015129.htmlAnd fixed here: Dec 30 11:57:59 And fixed here: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/015129.html Dec 30 11:58:32 Is there any documentation about this "bug cicle"? Dec 30 11:58:39 cycle* Dec 30 12:09:12 alephan: I think it's documented somewhere Dec 30 12:10:17 alephan: but basically the bug gets assigned to the person who is working on it and then they set the status to ACCEPTED Dec 30 12:11:20 when the fix is merged the assignee adds a comment with the poky git revision and then sets the bug to RESOLVED/FIXED Dec 30 12:11:48 So right not i should but it on accepted? Dec 30 12:11:52 put* Dec 30 12:12:14 And watch until it is fixed and then move it on fixed right? Dec 30 12:12:27 alephan: I think you can set 1845 to ACCEPTED Dec 30 12:12:33 since you clearly accepted it :) Dec 30 12:12:48 alephan: yes Dec 30 12:13:25 Thank you for infos. Dec 30 12:14:09 np Dec 30 12:14:16 Sorry one more info. Dec 30 12:14:20 sure Dec 30 12:14:39 When should it be on "waiting for upstream"? Dec 30 12:15:32 alephan: basically when the fix or some part of it has to go upstream or come from upstream (i.e. the original authors of the software in question) Dec 30 12:15:56 original authors or current maintainers Dec 30 12:17:04 So as i understand, as my fix it's uploaded, this bug should be on waiting for upstream... Dec 30 12:17:11 Cause thay have to merge or reject it. Dec 30 12:17:24 no, it's only for bugs in a piece of software that we don't maintain Dec 30 12:17:34 like, e2fsprogs for example Dec 30 12:17:54 Oh. I see now. Dec 30 12:17:58 we don't have a specific status for waiting for patch review Dec 30 12:18:04 Thank you very much once again. Dec 30 12:18:16 although we do often put this in the "whiteboard" field so that bug triagers know what's happening Dec 30 12:24:23 It's clear now. Thank you for your time. Dec 30 14:19:10 hi all :) Dec 30 14:20:48 whats the difference between poky and yocto? Dec 30 14:25:56 gebi: poky is the build system, which is one of the subprojects under the yocto umbrella project (others being pseudo, swabber etc.) Dec 30 14:26:15 gebi: but some use yocto to refer to the build system as well Dec 30 14:26:21 aaaah ok Dec 30 14:26:38 i'm just searching how to build yocto with debians toolchain Dec 30 14:26:45 is the idea really that strange? Dec 30 14:26:50 target is i686 Dec 30 14:28:01 gebi: people do use external toolchains but it is usually when they are using the toolchain provided by their device manufacturer / OSV Dec 30 14:28:14 gebi: the question is, why do you want to use debian's toolchain? Dec 30 14:31:35 to be able to compile binaries on plain debian and have it on the yocto image working Dec 30 14:32:47 and buildtime, but it seems i'll just build on tmpfs Dec 30 14:36:33 bluelightning: how many ram do i need for tmpfs build? Dec 30 14:38:11 it depends on what you're building... 20-30GB for a core-image-minimal build at a guess Dec 30 14:38:37 i'd need X and sdl too Dec 30 14:41:19 uh, ok hope yocto can use a few cores then *g* Dec 30 14:43:35 btw... "OE and Your Distro" and " Required Software" links are broken in http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Dec 30 14:53:20 bluelightning: thx :), running the first testbuild Dec 30 14:53:25 hope it gets ready in a few minutes Dec 30 15:09:05 bluelightning: cool :) - real 8m9.352s user 11m14.530s sys 1m43.426s Dec 30 15:09:08 and thats it :)? Dec 30 15:09:55 for bitbake -k core-image-sato Dec 30 15:12:03 gebi: that's a bit quicker than I would have expected... maybe you saved time by not having to build the toolchain Dec 30 15:12:59 nope made a complete build Dec 30 15:13:34 i tried starting again from a fresh wget to not have older changes Dec 30 15:14:55 last output was: NOTE: Tasks Summary: Attempted 126 tasks Dec 30 15:15:04 0 failed Dec 30 15:17:46 bluelightning: ok i'll try again, seems some machine/target changes in local.conf i made where wrong Dec 30 15:18:55 obviously because all my friends always complain how long this takes... Dec 30 15:29:44 bluelightning: hm nope bitbake -k core-image-sato takes only 10minutes here Dec 30 15:31:22 i left everything at default config in local.conf except BB_NUMBER_THREADS and PARALLEL_MAKE and added INHERIT += rm_work Dec 30 15:39:07 gebi: did you keep sstate-cache between builds? Dec 30 15:39:40 nope i've deleted everything, even unpacked the tarball again Dec 30 15:50:27 bluelightning: hm... seems there is nothing wrong, `runqemu qemux86` starts qemu and boots yocto Dec 30 15:56:23 gebi: great :) Dec 31 00:42:07 hello ppl Dec 31 00:43:01 I'm trying to create a package which includes pyside examples, so, it's just example scripts, no real lib, however my package is failing on the do_rootfs Dec 31 00:44:05 here's the bb script http://paste.pocoo.org/show/527975/ Dec 31 01:04:26 here's the log output http://paste.pocoo.org/show/527985/ **** ENDING LOGGING AT Sat Dec 31 02:59:57 2011