**** BEGIN LOGGING AT Sat Aug 31 02:59:58 2013
Aug 31 14:08:18 <lpapp_> bluelightning: hi
Aug 31 14:09:42 <bluelightning> hi lpapp_
Aug 31 14:09:50 <lpapp_> bluelightning: how are you
Aug 31 14:10:24 <bluelightning> fine thanks and you?
Aug 31 14:11:11 <lpapp_> bluelightning: http://paste.kde.org/~lpapp/pc7c27f94/
Aug 31 14:11:16 <lpapp_> fine. :)
Aug 31 14:11:28 <lpapp_> this is the openflow issue I mentioned the other day.
Aug 31 14:12:22 <bluelightning> error doesn't mean anything to me I'm afraid
Aug 31 14:12:51 <bluelightning> you know there is an openflow recipe in meta-virtualizartion
Aug 31 14:13:00 <bluelightning> er meta-virtualization
Aug 31 14:13:10 <lpapp_> which is outdated, and misplaced.
Aug 31 14:13:23 <lpapp_> yes, I am trying to build a new one, and put it into meta-networking.
Aug 31 14:14:01 <bluelightning> well, you'll have to debug it in that case
Aug 31 14:14:11 <bluelightning> my usual first port of call for error messages is google
Aug 31 14:14:40 <lpapp_> bluelightning: well, boot.sh did not run fine
Aug 31 14:15:36 <lpapp_> bluelightning: it is using git ls-files for generating it.
Aug 31 14:16:01 <lpapp_> bluelightning: here is the script again, http://paste.kde.org/~lpapp/pda9623c5/
Aug 31 14:18:47 <lpapp_> bluelightning: my recipe, cat ../meta-networking/recipes-support/openflow/openflow_1.0.bb |curlpaste
Aug 31 14:18:50 <lpapp_> http://codepad.org/S4s67OIM
Aug 31 14:21:18 <bluelightning> I think you should be running boot.sh and oe_runconf in do_configure
Aug 31 14:23:44 <lpapp_> bluelightning: that worked, thanks.
Aug 31 14:24:36 <lpapp_> bluelightning: hmm, ls /home/lpapp/Projects/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/openflow/1.0+gitAUTOINC+c84f33f09d-r0/git/ -> empty.
Aug 31 14:25:38 <lpapp_> I ran this command: bitbake openflow -c clean && bitbake openflow
Aug 31 14:26:30 <bluelightning> had you successfully built it before that?
Aug 31 14:27:25 <lpapp_> not this way, nope.
Aug 31 14:30:12 <bluelightning> I'm confused then, I thought you said it worked?
Aug 31 14:31:20 <lpapp_> we use it in a different way in our project.
Aug 31 14:31:30 <lpapp_> basically it is embedded into our software
Aug 31 14:31:33 <lpapp_> i.e. imported.
Aug 31 14:31:47 <lpapp_> so we just hacked into our buildsystem to invoce its makefile recursively
Aug 31 14:31:57 <lpapp_> but I would like to get rid of that in the long term.
Aug 31 14:32:08 <lpapp_> getting a working build in meta-networking would be the first step.
Aug 31 14:34:14 <lpapp_> bluelightning: I am not getting the source right
Aug 31 14:34:53 <lpapp_> this is my recipe after the modification: cat ../meta-networking/recipes-support/openflow/openflow_1.0.bb | curlpaste
Aug 31 14:34:56 <lpapp_> http://codepad.org/pTIpwDOY
Aug 31 14:39:41 <bluelightning> I don't know what's going on on your system but that recipe just built perfectly here
Aug 31 14:44:29 <lpapp_> bluelightning: mine, or the one in meta-virtualization?
Aug 31 14:44:38 <bluelightning> the one you pasted
Aug 31 14:45:41 <lpapp_> bluelightning: by simply using bitbake openflow?
Aug 31 14:45:59 <lpapp_> I did not get any errors either, but there is nothing in the git folder either.
Aug 31 14:46:03 <lpapp_> is that expected? Same for you?
Aug 31 14:48:43 <bluelightning> no
Aug 31 14:48:56 <bluelightning> it contains the source here
Aug 31 14:49:01 <bluelightning> are you using rm_work ?
Aug 31 14:49:05 <lpapp_> yes
Aug 31 14:49:07 * RP thinks he just found an interesting performance improvement. The one I haven't been able to put a finger on for a long time
Aug 31 14:49:23 <bluelightning> lpapp_: well then that's expected
Aug 31 14:49:30 <lpapp_> bluelightning: alright.
Aug 31 14:49:40 <lpapp_> bluelightning: I am installing rpm now to verify the packag.
Aug 31 14:49:46 <lpapp_> probably empty as I have to install stuff explicitly.
Aug 31 14:50:01 <bluelightning> RP: interesting, what did you find?
Aug 31 14:50:05 <RP> bluelightning: can you remember a) Why PR Server uses an SQL database at all and b) whether we support multiple users of the DB at once?
Aug 31 14:50:25 <RP> bluelightning: The time.sleep() in process.py is a significant bottleneck
Aug 31 14:50:30 <bluelightning> RP: I wasn't involved in the PR server development at all I'm afraid
Aug 31 14:50:54 <lpapp_> rpm package management means the rpm or rpm.org fork in case of Yocto?
Aug 31 14:50:55 <bluelightning> RP: seems to me we'd have to offer multiple user support given that it's meant to be sharable amongst multiple builders
Aug 31 14:51:13 <bluelightning> lpapp_: rpm5
Aug 31 14:51:14 <RP> bluelightning: thats for connection to it though, not the DB file on disk?
Aug 31 14:51:23 <bluelightning> lpapp_: why not just add it to your image?
Aug 31 14:51:24 <lpapp_> bluelightning: ok, so not the rpm.org fork.
Aug 31 14:51:34 <lpapp_> bluelightning: I would like to verify the packages on the host.
Aug 31 14:51:44 <lpapp_> bluelightning: you mean I could do that with the arm rpm binary, too?
Aug 31 14:51:50 <lpapp_> without building it from source on the host?
Aug 31 14:52:29 <bluelightning> lpapp_: if you want to see the contents you can just extract it
Aug 31 14:52:38 <bluelightning> no need to use rpm to do that
Aug 31 14:52:50 <lpapp_> bluelightning: I do not wanna extract it, just look into it.
Aug 31 14:52:59 <lpapp_> rpm -qpl
Aug 31 14:53:04 <lpapp_> if that is possible without rpm, that is fine, too.
Aug 31 14:53:15 <bluelightning> RP: wouldn't have thought it necessary to allow that, but SQLite does support it of course
Aug 31 14:54:47 <lpapp_> bluelightning: wanted to ask what the better practice is about the install vs. FILES
Aug 31 14:54:57 <lpapp_> bluelightning: is it okay just to install files into the standard location rather than FILES?
Aug 31 14:55:14 <lpapp_> in simple cases where I binaries, headers, and libraries at best.
Aug 31 14:55:22 <lpapp_> at worst*
Aug 31 14:55:22 <bluelightning> sorry, I don't understand the question
Aug 31 14:55:36 <lpapp_> FILES is defined to the sane directories by default.
Aug 31 14:55:51 <lpapp_> so when getting split packages, you usually do not need to use it AFAIU
Aug 31 14:56:00 <lpapp_> is that a good practice though not using it in the aforementioned scenarios?
Aug 31 14:56:07 <lpapp_> just install -m644 and install -dm755?
Aug 31 14:56:15 <lpapp_> -m 644*
Aug 31 14:57:45 <bluelightning> FILES doesn't influence the installation, only packaging
Aug 31 14:59:18 <RP> bluelightning: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=1f297862c57dee83ef94ad5cbfe28b51b16473e5 makes the server a lot more responsive to process creation/completion
Aug 31 15:02:03 <lpapp_> bluelightning: yes, this topic is about packaging.
Aug 31 15:10:21 <bluelightning> RP: that does look like it would improve things yes, well done...
Aug 31 15:14:21 <RP> bluelightning: just need to figure out how to patch up the xmlrpc server :/
Aug 31 15:14:34 * RP thinks he now has a workable PR server solution too
Aug 31 15:15:04 <RP> patches on http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip76 if anyone is interested. Still need to do some cleanup
Aug 31 15:15:36 * RP is rather concerned at the amount of unnoticed deprecated api usage
Aug 31 15:15:57 <bluelightning> maybe we should turn on deprecation warnings again...
Aug 31 15:18:37 <RP> or force the issue and remove the compat entries...
Aug 31 15:20:57 <zecke> RP: looks reasonable, how did you benchmark?
Aug 31 15:24:21 <RP> zecke: Added a task to every recipe with no dependencies and had that connect to the PR service 5 times in a row, then added a task with recursive dependencies on those individual tasks and ran that with BB_NUMBER_THREADS=48 for things like core-image-sato and sato-sdk
Aug 31 15:24:47 <RP> Each task then printed out a timing for each of the 5 responses
Aug 31 15:25:31 <RP> I also ran the whole thing with "time bitbake" which showed overall how quickly it could run all this. The process.py patch takes it from 1m15 to 24s
Aug 31 15:27:38 <RP> Its an even nicer improvement when you consider bitbake startup is a good chunk of the 24s
Aug 31 21:26:41 <otavio> moring
Aug 31 21:47:37 <otavio> :)
**** ENDING LOGGING AT Sun Sep 01 02:59:58 2013