**** BEGIN LOGGING AT Fri Feb 18 02:59:57 2011
Feb 18 06:23:20 <eFfeM_work> gm
Feb 18 07:59:24 <mckoan> good morning
Feb 18 09:07:45 <anr78> I want to use bash instead of busybox. I've added bash to my image, but I'm not sure how to make it the default shell, and if I should remove busybox.
Feb 18 09:11:21 <hrw> anr78: default for user or default for system?
Feb 18 09:11:46 <anr78> hrw: For system.
Feb 18 09:13:11 <hrw> I would check bug images as they are busybox free
Feb 18 09:15:54 <anr78> hrw: hm. should I have bug images in recipes/images?
Feb 18 09:17:52 <hrw> bug-image-production.bb
Feb 18 09:18:43 <hrw> anr78: bash-sh package is what you need
Feb 18 09:19:12 <hrw> hm.. it does not exists in oe...
Feb 18 09:19:46 <hrw> yep.
Feb 18 09:20:20 <hrw> stefan_schmidt: you did not merged meta-oe/merge-queue/bash/bash.inc into OE - bug-image-production from oe.dev runs with busybox?
Feb 18 09:21:29 <stefan_schmidt> hrw: they should run bash
Feb 18 09:21:33 <John___> Is it possible to build a image with only Xorg as Xserver and not kdrive? 
Feb 18 09:21:33 * stefan_schmidt reads backlog
Feb 18 09:22:13 <stefan_schmidt> hrw: ah, I left out the bash-sh recipe for now. Need to bring it over.
Feb 18 09:22:14 <John___> I know it is, but when I add some other packages it will inlcude both xserver-xorg and xorg-kdrive
Feb 18 09:22:34 <hrw> stefan_schmidt: ok
Feb 18 09:22:37 <stefan_schmidt> hrw: But does proper-tools dos not take care of the non-busybox shell
Feb 18 09:22:40 <stefan_schmidt> ?
Feb 18 09:23:04 <hrw> stefan_schmidt: you need to check. normally it extends system with non-busybox stuff
Feb 18 09:23:16 <hrw> stefan_schmidt: bash-sh sets /bin/sh -> /bin/bash
Feb 18 09:23:25 <stefan_schmidt> hrw: ah, yes, that bit is missing
Feb 18 09:23:34 <stefan_schmidt> hrw: thanks for reminding me :)
Feb 18 09:26:27 <hrw> np
Feb 18 09:33:48 <pb_> mickey|office: good morning
Feb 18 09:38:27 <ericben> good morning
Feb 18 09:38:41 <ericben> does anyone know what is the problem with tinderbox ?
Feb 18 09:39:06 <ericben> there seems to be a database problem
Feb 18 09:40:27 <ynezz> ping ka6sox ^
Feb 18 09:40:34 <anr78> hrw: thanks
Feb 18 09:40:47 <ynezz> or maybe Jay7 would know ^
Feb 18 09:43:00 <CIA-47> 03Marco Cavallini <m.cavallini@koansoftware.com> 07master * r7885bf737f 10openembedded.git/conf/distro/include/kaeilos.inc: kaeilos.inc: switched to eglibc
Feb 18 09:51:29 <otavio> khem: you were right. It was something on the buildroot.
Feb 18 09:51:40 <otavio> khem: any suggestion about what I can look for?
Feb 18 09:56:39 <Jay7> ka6sox: Table './oe_tinderbox/oestats_build'
Feb 18 09:56:45 <Jay7> marked as crashed
Feb 18 09:57:26 <Jay7> cryptk: ^
Feb 18 09:58:21 <ynezz> what are guys doing to that table? :p
Feb 18 09:58:40 <Jay7> it's mysql, baby :)
Feb 18 09:58:48 <ynezz> crash_every_two_weeks++;
Feb 18 09:59:04 <Jay7> I don't know how this happens..
Feb 18 09:59:15 <Jay7> db is innodb
Feb 18 10:00:03 <cryptk> I will mysqlcheck it
Feb 18 10:00:56 <Jay7> REPAIR TABLE may be sufficient
Feb 18 10:01:34 <pb_> are you sure it is innodb?  I don't think I've ever seen an innodb table marked as crashed.
Feb 18 10:01:58 <pb_> that's generally symptomatic of myisam.
Feb 18 10:02:12 <Jay7> pb_: database admnin says that db under oestats is innodb
Feb 18 10:02:18 <Jay7> I'm doubt too
Feb 18 10:02:20 <Jay7> but..
Feb 18 10:02:37 <pb_> jay7: what does SHOW CREATE TABLE say?
Feb 18 10:02:40 <pb_> or look in /var/lib/mysql
Feb 18 10:02:50 <Jay7> pb_: I have no access there :)
Feb 18 10:03:06 <cryptk> I doubt jay has access to that location... your mysql database isn't hosted on your server
Feb 18 10:03:21 <pb_> oh, I see.  heh.
Feb 18 10:03:32 <cryptk> there is one central database server for everything
Feb 18 10:03:50 * Jay7 have no access to OE infrastructure at all
Feb 18 10:03:55 <mickey|office> good morning pb_ 
Feb 18 10:04:02 <cryptk> alond with master-master replication... IP failover... automatic daily backups that are sent to a double redundant offsite location
Feb 18 10:04:03 <mickey|office> hi folk
Feb 18 10:04:03 <mickey|office> s
Feb 18 10:04:06 <Jay7> only git push access :)
Feb 18 10:05:25 <ynezz> Jay7: looking at your testbuilder script, it looks like it doesn't support different libc variants, right?
Feb 18 10:05:49 <ynezz> or am I missing something?
Feb 18 10:06:19 <cryptk> forgot to mention the 30 day rolling window for the mysql database
Feb 18 10:06:35 <cryptk> should something happen we can restore it to whatever backup we choose over the last 30 days
Feb 18 10:06:59 <cryptk> you only get the master-master though if your stuff uses the right IP address... which it likely doesn't
Feb 18 10:12:43 <Jay7> ynezz: what is needed to support it?
Feb 18 10:14:45 <Jay7> ynezz: I mean even how to change libc variants?
Feb 18 10:14:46 <ynezz> well for Angstrom it's ANGSTROMLIBC=uclibc for example, but I'm looking how does it works for other distros
Feb 18 10:15:43 <ynezz> for minimal it's different distro minimal-uclibc for example
Feb 18 10:16:01 <ynezz> micro is the same
Feb 18 10:16:05 <Jay7> then minimal is supported out of the box :)
Feb 18 10:16:10 <ynezz> I know
Feb 18 10:16:22 <ynezz> well, then it's just angstrom
Feb 18 10:16:40 <Jay7> good idea to have some standard solution..
Feb 18 10:16:50 <ynezz> tell me about it :)
Feb 18 10:16:57 <Jay7> e.g. LIBC_VARIANT or something like..
Feb 18 10:17:24 <ynezz> how it's handled in poky?
Feb 18 10:17:45 <woglinde> hiho
Feb 18 10:17:45 <Jay7> I don't know..
Feb 18 10:17:46 <ynezz> ah, google is faster:p POKYLIBC=uclibc
Feb 18 10:17:52 <ynezz> cool :p
Feb 18 10:18:09 <Jay7> ynezz: then we may just wait for merge ;)
Feb 18 10:18:27 <ynezz> you think, that merge will change something?
Feb 18 10:19:08 <Jay7> I hope :)
Feb 18 10:19:45 <Jay7> that is question for TSC members imho
Feb 18 10:20:59 <ka6sox> Jay7, you are killing it with 2million little teensy tiny puts/hr
Feb 18 10:21:20 <ka6sox> because bitbake tells us every little tiny minute step it does...
Feb 18 10:22:36 <Jay7> yeah :(
Feb 18 10:24:14 <ka6sox> Jay7, I think I'm just going to shut down oe_stats till its fixed
Feb 18 10:24:49 <ka6sox> we are spending too much time fixing this, chasing our tails, its abusive to the servers and is causing crashes...
Feb 18 10:25:01 <ka6sox> when its fixed I'll turn it back on.
Feb 18 10:25:30 <ka6sox> since I can't fix Bitbake you will have to file whatever you need to get it fixed.
Feb 18 10:26:18 <Jay7> well.. this way we may get help from someone who know python and have enough free time
Feb 18 10:26:43 <ka6sox> I'm not sure who all is on the bitbake team but they need to fix this.
Feb 18 10:26:59 <Jay7> I should finish all my work on kexecboot before start fixing oestats
Feb 18 10:27:03 <ka6sox> it does NOT scale well.
Feb 18 10:27:36 <ka6sox> okay I'm killing it.
Feb 18 10:28:33 <ka6sox> its 2:28am and I'm *still* up trying to keep stuff running because of this.
Feb 18 10:28:54 <Jay7> ka6sox: announce this in ML please
Feb 18 10:29:39 <ericben> oestat's concept is not intended to scale well by design. 1 hit par task runned by bitbake is ok for a local use but not for a community usage
Feb 18 10:29:43 <ka6sox> when I wake up...I"m too pissed at having no progress on this in 3 weeks...not at you but the whole situation.
Feb 18 10:30:03 <ka6sox> ericben, understood...but OE insists on running it for 15+builders
Feb 18 10:30:32 <ka6sox> so its abusive to the infrastructure and is causing me to have to stay up waaay too late just to keep everything running
Feb 18 10:30:44 <ericben> ka6sox: maybe we should change it to only push errors to the server in case of community usage
Feb 18 10:31:15 <ka6sox> ericben, I'd love that...but in 3 weeks of talking about it I've heard nothing about it even getting looked at.
Feb 18 10:31:37 <ericben> ka6sox: begining of the year's syndrom ... to much work
Feb 18 10:33:06 <ka6sox> ericben, I know..In 6days I have a linux conference I'm Audio/Video Chair for and I am extremely busy getting ready for that...
Feb 18 10:33:30 <ericben> btw on my setup of oestat I4m not using a mysql database but a local sqlite one
Feb 18 10:34:10 <ka6sox> there are 16MILLION records in this DB...I doubt that sqlite would help :(
Feb 18 10:34:45 <cryptk> Jack87, or_tinderbox db should be fixed
Feb 18 10:34:58 <cryptk> s/or_tinderbox/oe_tinderbox/
Feb 18 10:35:06 <ericben> ka6sox: maybe we should also add a cron which cleans the database on a weekly basis. I'm not sure it's suefull to keep such a large backlog of builds
Feb 18 10:35:41 <ericben> it's interesting in realtime to get problem's log 
Feb 18 10:35:51 <ka6sox> ericben, thats only 1/2 the problem...the other 1/2 is bitbake reporting when it uses every sheet of toiletpaper.
Feb 18 10:36:01 <Jack87> cryptk, roger but was that aimed to someone else?
Feb 18 10:36:13 <Jay7> Jack87: for me imho :)
Feb 18 10:36:20 <ka6sox> I"m sorry but you can't even watch the accesslog its too damned fast.
Feb 18 10:36:29 <Jack87> Jay7, prolly :)
Feb 18 10:36:33 <ericben> yes especially when testbuilder are running
Feb 18 10:36:41 <cryptk> Jack87, yeah... was meant for Jay7 ... damn tab complete
Feb 18 10:36:58 <ka6sox> because with 15+builders talking about EVERY SINGLE STEP THAT THEY ARE DOING...its too much traffic
Feb 18 10:37:14 <ericben> I had the same problem on my local setup at the begining ... for only a few users
Feb 18 10:37:25 <Jack87> hehe i figured as you were telling me somethign you already told me :)
Feb 18 10:37:34 <Jay7> ericben: watching it in realtime is interesting but have no practical use
Feb 18 10:38:38 <Jay7> oe_stats is used as 'automated pastebin for logs' and as data-collecting tool
Feb 18 10:39:10 <ericben> ka6sox: now trying a 1 line patch which could help
Feb 18 10:39:12 <Jay7> for this is ok to just push overall build status for every package
Feb 18 10:39:26 <ericben> Jay7: that's what I mean by realtime usage
Feb 18 10:39:31 <ericben> get the log and pastebin it
Feb 18 10:39:39 <ericben> so non need to have several years of backlog 
Feb 18 10:40:16 <ka6sox> its tinderbox_oe and oe_stats user
Feb 18 10:45:46 <woglinde> lumidum
Feb 18 10:45:56 <ericben> ka6sox: patch tested and sent
Feb 18 10:46:24 <ka6sox> Jay7, if bitbake said...I failed or I succeeded and the log as 1 thing...then that would be okay
Feb 18 10:46:38 <ka6sox> ericben, until all the builders have that patch I can't turn it back on.
Feb 18 10:46:39 <ericben> ka6sox: http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-February/030135.html
Feb 18 10:46:45 <ericben> ka6sox: of course
Feb 18 10:47:31 <Jay7> ericben: you have my Ack for this as temporary solution
Feb 18 10:47:36 <Jay7> to have oestats enabled
Feb 18 10:47:53 <pb_> ericben: wouldn't it be better to patch the oestats_eventhandler() rather than the low-level dispatch function?
Feb 18 10:48:10 <ka6sox> pb_, its every little task...
Feb 18 10:48:21 <ka6sox> every single taks
Feb 18 10:48:28 <pb_> ka6sox: yes, I know.  oestats_eventhandler() is what sends those.
Feb 18 10:48:45 <ericben> pb_: maybe my python skills are rather limited so I tried to go directly to the goal :)
Feb 18 10:48:57 <Jay7> ericben: look at end of oestats-client.bbclas
Feb 18 10:49:00 <ericben> Jay7: please hit reply and send the ack to the list ;-)
Feb 18 10:49:07 <ka6sox> batch them up, send them after it either suceeds or fails...
Feb 18 10:49:20 <ka6sox> but not after every single step
Feb 18 10:49:24 <pb_> yeah, that would certainly be an improvement
Feb 18 10:49:44 <ericben> this is not THE right solution, this is a quick hack to get oestat running again
Feb 18 10:50:10 <mckoan> someone should teach me how to manage ERROR: QA Issue bad RPATH issues, I face to one new each day
Feb 18 10:50:36 <ka6sox> ericben, but until I have an email from every single autobuilder guy saying he is patched up I"m not turning it back on.
Feb 18 10:50:39 <mckoan> I'd like to solve them but I don't understand how and where
Feb 18 10:50:55 <ynezz> maybe try something else then mysql for oe_stats
Feb 18 10:51:15 <ericben> ka6sox: of course
Feb 18 10:51:26 <ka6sox> ynezz, what db do you know that handles 2MILLION little puts/hr
Feb 18 10:51:27 <ericben> ka6sox: can you please answer to the patch to tell this ?
Feb 18 10:51:29 <mckoan> OE is completely inusable to me
Feb 18 10:51:37 <Jay7> ericben: as you have local oestats server may you try to comment oestats_task under TaskSucceeded in oestats_evenhandler?
Feb 18 10:51:56 <ericben> Jay7: that will also do the trick
Feb 18 10:51:57 <pb_> ynezz: mysql ought to be fine, I don't quite know why it isn't managing to keep up with that load.
Feb 18 10:52:09 <Jay7> ericben: this is right place for this imho
Feb 18 10:52:22 <Jay7> can you test it and send updated patch?
Feb 18 10:52:41 <cryptk> pb_, because the mysql server is not just OE
Feb 18 10:52:56 <ka6sox> pb_, because oestats, as its written, is NOT scalable.
Feb 18 10:52:58 <cryptk> it runs a database for multiple large FOSS projects... we manage more than jsut OE servers
Feb 18 10:53:01 <pb_> cryptk: oh, right, I see.
Feb 18 10:53:04 <Jay7> there is nothing to discuss people..
Feb 18 10:53:12 <ericben> Jay7: will do it
Feb 18 10:53:17 <Jay7> oestats should be fixed anyway
Feb 18 10:53:40 <pb_> ka6sox: sure, I understand that, oestats clearly is broken.  it just seemed strange that 2 million posts per hour was causing mysql a problem.
Feb 18 10:54:04 <cryptk> either way, until oestats is fixed we cannot turn it back on.  As soon as it is fixed, we will be more than happy to turn it back on
Feb 18 10:54:14 <pb_> but, if it's a shared host then that makes more sense.
Feb 18 10:54:17 <ka6sox> what you need to do is go to a modern build management system like jenkins
Feb 18 10:54:23 <cryptk> pb_, it likely wouldn't if it were on a server jsut for you guys
Feb 18 10:54:28 <cryptk> or hudson
Feb 18 10:54:44 <pb_> yeah
Feb 18 10:54:52 <ka6sox> pb_, OE's traffic is 2/3 of what we do...almost 15Mb/sec
Feb 18 10:55:05 <mckoan> today we have ERROR: QA Issue with acl: package acl contains bad RPATH
Feb 18 10:55:05 <ka6sox> and your server is EXTREMELY busy.
Feb 18 10:55:21 <pb_> I guess the thing to do is patch oestats-client to do less posting and simultaneously change the submit url so that only hosts with the new class will be able to post.
Feb 18 10:55:27 <ericben> mckoan: Tartarus was working on this yesterday
Feb 18 10:55:57 <mckoan> ericben: on acl too? I didn't know, thx
Feb 18 10:55:59 <ericben> pb_: yes a new url would allow infrastructure team to clean the old database
Feb 18 10:56:16 <ericben> mckoan: from a quick look to the history I was acl somewhere :-)
Feb 18 10:56:38 <Jay7> so we have only one easy task now.. find one who will rewrite oestats client and server :)
Feb 18 10:56:47 <CIA-47> 03Stefan Schmidt <stefan@buglabs.net> 07master * r2d23c765c6 10openembedded.git/recipes/buglabs-osgi/org.freedesktop.dbus.bb: org.freedesktop.dbus: modify recipe so localization/compilation occurs correctly.
Feb 18 10:56:58 <CIA-47> 03Stefan Schmidt <stefan@buglabs.net> 07master * rf94e88e8a4 10openembedded.git/recipes/bash/ (bash.inc bash_3.0.bb bash_3.2.bb): 
Feb 18 10:56:58 <CIA-47> bash: Add bash-sh package to switch /bin/sh to /bin/bash
Feb 18 10:56:58 <CIA-47> An old change from hrw in the BugLabs repo I forgot to bring over earlier.
Feb 18 10:57:00 <ericben> Jay7: is that usefull to have all the successful steps ?
Feb 18 10:57:05 <CIA-47> 03Stefan Schmidt <stefan@buglabs.net> 07master * r4b930440c4 10openembedded.git/recipes/images/bug-image-production.bb: bug-image-production: Add back bash-sh package
Feb 18 10:57:15 * Jay7 is busy with kexecboot up to March
Feb 18 10:57:21 <mckoan> ericben: found, thx
Feb 18 10:57:23 <ka6sox> Jay7, understood.
Feb 18 10:57:32 <Jay7> ericben: it's useful for statistics
Feb 18 10:57:58 <ka6sox> I don't mind if you send *all* the data...every single step
Feb 18 10:58:10 <ka6sox> just not 1......at.......a.......time
Feb 18 10:58:20 <ka6sox> batch them
Feb 18 10:58:21 <Jay7> :)
Feb 18 10:58:52 <ericben> Jay7: patch v2 sent
Feb 18 10:59:01 <Jay7> ericben: excellent!
Feb 18 10:59:06 <ericben> Jay7: which statistics ?
Feb 18 10:59:10 <Jay7> I'll ack it on ML as I receive it
Feb 18 10:59:44 <Jay7> ericben: e.g. you may look in which build env some package was built fine
Feb 18 11:00:15 <Jay7> we have problem with gcc-cross yesterday which was failed only on x86
Feb 18 11:00:23 <Jay7> but was fine on other arches
Feb 18 11:00:29 <ericben> Jay7: so maybe we should only send failures and success (but success only for the final task not for all the tasks runned)
Feb 18 11:00:38 <Jay7> ericben: yes, sure
Feb 18 11:00:39 <ericben> runned -> ran 
Feb 18 11:00:57 <Jay7> success/fail per package, not per task
Feb 18 11:01:24 <Jay7> but we have no hook in bb to wire 
Feb 18 11:01:59 <Jay7> so idea was to put all stats in bb's persistent storage (sqlite) and post after build
Feb 18 11:02:19 <Jay7> from BuildCompeted event 
Feb 18 11:02:29 <Jay7> this may have other good side effect
Feb 18 11:02:44 <Jay7> you may have command-line tool to 'flush' stats to server
Feb 18 11:03:07 <Jay7> i.e. you are building on notebook w/o inet connection, then come to home and flush all stats
Feb 18 11:03:36 <ericben> we could also only send the do_compile status when it's success
Feb 18 11:03:56 <Jay7> it may fail on install..
Feb 18 11:04:05 <ericben> if that fails you get the informations
Feb 18 11:04:08 <Jay7> I've talked with kergoth about this
Feb 18 11:04:25 <Jay7> we may flush collected data on some task
Feb 18 11:04:33 <ericben> if we send compile even when that's a success you have the statistic source there
Feb 18 11:04:33 <Jay7> and at end of build
Feb 18 11:04:51 <ericben> Jay7: yes but that involves to rewrite the server
Feb 18 11:04:59 <Jay7> sure..
Feb 18 11:05:44 <Jay7> well..
Feb 18 11:05:48 <Jay7> may be not
Feb 18 11:06:49 <Jay7> we may aggregate data in local storage and send it periodically
Feb 18 11:07:15 <Jay7> but I don't know event to use for this..
Feb 18 11:07:18 <ericben> Jay7: ok, I was thinking the server needs one request per task
Feb 18 11:07:37 <Jay7> it may live with only one post per package
Feb 18 11:07:40 <Jay7> i.e. last task
Feb 18 11:08:06 <Jay7> (I belive) :)
Feb 18 11:12:07 <Jay7> ericben: Acked by me
Feb 18 11:14:52 <ka6sox> okay I have put a message up on tinderbox.openembedded.org about the situation.
Feb 18 11:15:01 <ka6sox> its offline till this gets fixed.
Feb 18 11:15:36 <ka6sox> but truthfully? you guys need to go to something more modern
Feb 18 11:15:58 <Jay7> ka6sox: we understand this clearly
Feb 18 11:15:58 <ka6sox> I can count django programmers in 1 hand that I know
Feb 18 11:16:32 <Jay7> I hope we will find some solution quickly enough
Feb 18 11:16:47 <ka6sox> Jay7, thanks...now maybe I can get some sleep...only 2hrs left tonight :P
Feb 18 11:17:01 <Jay7> good night :)
Feb 18 11:17:02 <ericben> ka6sox: good night and thanks ;-)
Feb 18 11:18:06 <woglinde> good nite ka6sox
Feb 18 11:18:14 <condo4_> hello,
Feb 18 11:18:44 <condo4_> I have a problem to build perl for powerpc....
Feb 18 11:19:48 <Jay7> wow
Feb 18 11:19:58 <Jay7> all my angstrom-2008.1 builds are failed
Feb 18 11:20:04 <woglinde> uha
Feb 18 11:20:06 <woglinde> rpath
Feb 18 11:20:07 <Jay7> tiff and gnutls
Feb 18 11:20:11 <stefan_schmidt> and acl
Feb 18 11:20:15 <woglinde> gnutls is failed
Feb 18 11:20:22 <woglinde> args fixed
Feb 18 11:20:24 <stefan_schmidt> woglinde: fixed?
Feb 18 11:20:26 <stefan_schmidt> heh
Feb 18 11:20:29 <woglinde> hi stefan
Feb 18 11:20:32 <stefan_schmidt> hi woglinde 
Feb 18 11:20:35 <Jay7> 2010 is fine seems
Feb 18 11:20:36 <ericben> same thing here
Feb 18 11:20:41 <ericben> see my last post
Feb 18 11:20:41 <stefan_schmidt> woglinde: which days will you be at cebit
Feb 18 11:20:43 <Jay7> woglinde: this is release-testing branch
Feb 18 11:20:52 <woglinde> stefan wiki
Feb 18 11:20:52 <Jay7> seems fix is not there
Feb 18 11:20:54 <woglinde> 3-5
Feb 18 11:20:55 <ericben> Andreas Mueller found a way to workaround this
Feb 18 11:20:57 <woglinde> do-sa
Feb 18 11:21:08 <stefan_schmidt> woglinde: ok
Feb 18 11:21:08 <woglinde> jay7 sure
Feb 18 11:21:16 <stefan_schmidt> woglinde: I will be there do+fr
Feb 18 11:21:23 <woglinde> but the errors are there since tuesday
Feb 18 11:21:24 <stefan_schmidt> woglinde: Will come around...
Feb 18 11:21:28 <woglinde> and nobody fixed
Feb 18 11:21:38 <woglinde> hm I fixed two
Feb 18 11:21:50 <woglinde> libsdl-mixer
Feb 18 11:21:52 <ericben> woglinde: Tartarus believed that was fixed for gnutls
Feb 18 11:21:53 <stefan_schmidt> woglinde: well, not everybody builds every day...
Feb 18 11:22:03 <woglinde> sure but the mails was on the ml
Feb 18 11:22:18 <woglinde> so it was clear that the testbuilds for 2008 will failure
Feb 18 11:22:51 <stefan_schmidt> woglinde: sure, I don't complain :)
Feb 18 11:23:53 <mario-goulart> Hi.  Is it expected that a file is created like
Feb 18 11:23:54 <mario-goulart> $ ls -l tmp/work/i486-oe-linux/gcc-cross-4.5-r31.1+svnr168622/gcc-4_5-branch/.pc/gcc-4.5-linaro-r99404.patch/gcc/config/arm/cortex-m4-fpu.md
Feb 18 11:23:54 <mario-goulart> ---------- 1 mario mario 0 Fev 17 16:04 tmp/work/i486-oe-linux/gcc-cross-4.5-r31.1+svnr168622/gcc-4_5-branch/.pc/gcc-4.5-linaro-r99404.patch/gcc/config/arm/cortex-m4-fpu.md
Feb 18 11:23:56 <mario-goulart> ?
Feb 18 11:24:02 <woglinde> ~pastebin
Feb 18 11:24:03 <ibot> [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude.
Feb 18 11:24:08 <mario-goulart> (notice the permissions)
Feb 18 11:24:29 <mario-goulart> 2 lines. :-)
Feb 18 11:25:12 <condo4_> what is the best branch/tag to build recent Anstrom for Powerpc ?
Feb 18 11:29:14 <pb_> mario-goulart: I think that is expected for newly-created files.
Feb 18 11:30:00 <ka6sox-away> pb_, when I have more sleep I'll answer your email..thanks.
Feb 18 11:30:38 <pb_> ka6sox-away: I think you must have meant someone else; I don't recall having sent you any email.  sleep well though.
Feb 18 11:30:46 <mario-goulart> pb_: since I'm constantly screwing the tmpdir up, I'm making a copy of a freshly-created one.  Is it safe to ignore the read errors on the 000-permission files?
Feb 18 11:31:11 <pb_> mario-goulart: yeah, should be.
Feb 18 11:31:28 <mario-goulart> pb_: ok.  Thank you.
Feb 18 11:31:49 <condo4_> I tried with master, with origin/shr/testing2010 origin/testing-release-2011.03 but always it fail on the perl 5.10 build because it try to run miniperl build (native) but with the target LD_LIBRARY_PATH, so it can't open libperl.so
Feb 18 11:41:10 <ericben> pb_: do you think the sed at line 43 of gcc-package-cross.inc is still nedded ? this seems to be the cause of QA problems with old libtool on C++ binaries  ?
Feb 18 11:56:13 <pb_> ericben: I suspect probably not.  By all means try removing it and see if anything breaks.
Feb 18 11:56:35 <pb_> I think the sysroot code should be sorting that out nowadays.
Feb 18 12:19:57 <ericben> pb_: ok thanks, will try it for next build
Feb 18 12:28:46 <simon__> hello
Feb 18 12:29:18 <simon__> ima getting the bad rapth error Tartarus was talking about last night
Feb 18 12:29:42 <woglinde> no news
Feb 18 12:30:11 <simon__> ok, thanks
Feb 18 12:43:01 <woglinde> stefan_schmidt ping
Feb 18 12:43:17 <stefan_schmidt> woglinde: pong
Feb 18 12:43:26 <stefan_schmidt> woglinde: hurry up, I'm going to leave
Feb 18 12:43:36 <woglinde> ah justed tested it
Feb 18 12:43:52 <woglinde> replacing java-native with cacao-hg works
Feb 18 12:44:00 <woglinde> out of the box
Feb 18 12:44:45 <woglinde> but I need to alter ther recipe of cacao_hg so the hg rev occurs
Feb 18 12:44:51 <stefan_schmidt> woglinde: cool
Feb 18 12:45:03 <stefan_schmidt> cacao_hg should be more stable?
Feb 18 12:45:08 <woglinde> yes
Feb 18 12:45:14 <woglinde> its solid rock stable
Feb 18 12:46:17 <stefan_schmidt> cool
Feb 18 12:51:29 <otavio> ericben: hi
Feb 18 12:51:44 <otavio> ericben: do you remember the problem I had with the toolchain?
Feb 18 12:51:55 <otavio> ericben: with cmake
Feb 18 13:03:40 <ericben> otavio: hi, yes I remember
Feb 18 13:03:56 <otavio> ericben: so, the toolchain one is fixed and working fine
Feb 18 13:04:06 <otavio> ericben: however on oe env it fails. 
Feb 18 13:04:29 <ericben> otavio: you mean when building the applicaiont inside OE using a recipe ?
Feb 18 13:04:32 <otavio> ericben: the root reason seems to be the same, since cmake doesn't know the right paths for target
Feb 18 13:04:38 <otavio> ericben: yep
Feb 18 13:04:55 <ericben> otavio: is that a qt problem or a cmake problem ?
Feb 18 13:05:11 <otavio> ericben: it depends on the POV
Feb 18 13:05:21 <otavio> ericben: cmake uses qmake to query the vars
Feb 18 13:05:23 <ericben> otavio: maybe we need a qt.conf for the toolchain inside OE 
Feb 18 13:05:37 <otavio> ericben: but qmake provides wrong values
Feb 18 13:05:45 <otavio> ericben: yes. I guess so
Feb 18 13:05:54 <otavio> ericben: the problem is where to put it?
Feb 18 13:06:06 <ericben> ericben: ok in qmake directory I think
Feb 18 13:06:28 <otavio> ericben: qmake is at sysroot/native/usr/bin/
Feb 18 13:07:16 <otavio> ericben: the problem in adding it there is that it will not allow other machine usage with same native
Feb 18 13:07:17 <woglinde> hm what ist linux-libc-headers native?
Feb 18 13:25:22 <otavio> ericben: I will patch qmake to support qt.conf relocation
Feb 18 13:25:33 <otavio> ericben: so we fix it properly
Feb 18 13:40:48 <CIA-47> 03Henning Heinold <heinold@inf.fu-berlin.de> 07org.openembedded.dev * r233e54b47a 10openembedded.git/recipes/cacao/cacao-native_hg.bb: 
Feb 18 13:40:48 <CIA-47> cacao-native: modell the package version after the git recipes
Feb 18 13:40:48 <CIA-47> * bump PR
Feb 18 14:11:48 <otavio> ericben: not required. There's a path on qt-tools that adds exactly that
Feb 18 14:12:00 <otavio> ericben: preparing the toolchain and cmake patches  for it
Feb 18 14:15:55 <ajb_oe> So I've located the failing part of the do_populate_sdk where is calls opkg-cl, is there an easy way to run this by hand so poke further or do I just hack the run script to get an environment that I can run it in?
Feb 18 14:31:11 <Tartarus> ping ericben :)
Feb 18 14:33:49 <woglinde> re tartarus
Feb 18 14:34:29 <Tartarus> hey
Feb 18 14:35:01 <ericben> otavio: cool, Tartarus : hi
Feb 18 14:35:17 <otavio> ericben: for the toolchain it is already working
Feb 18 14:35:36 <otavio> ericben: now fixing qmake class to make it work for OE
Feb 18 14:36:24 <ericben> otavio: perfect
Feb 18 14:37:10 <Tartarus> ericben, fwiw, i've got tiff fixed locally
Feb 18 14:37:13 <Tartarus> but hadn't hit shadow
Feb 18 14:37:30 <ericben> Tartarus: for tiff it seems to be a c++ problem
Feb 18 14:37:33 <ericben> at least here
Feb 18 14:38:09 <ericben> Tartarus: for the c++ problem a fix could be to remove the sed at line 43 of gcc-package-cross.inc
Feb 18 14:39:08 <bertszoghy> Hello,quick question. I have a program on the embedded device that I need to give full access to the serial port, so I modify the line mentioning getty in /etc/inittab from "respawn" to "wait"  which allows me to exit from the Linux prompt on the serial port and start my program through telnet. It all works well, I notice that the busybox ps command does not show the getty program properlywhile it is running.  I am thinking of cross-c
Feb 18 14:39:32 <woglinde> telnet?
Feb 18 14:39:44 <woglinde> your device is ownd
Feb 18 14:41:20 <Tartarus> ericben, not here
Feb 18 14:41:33 <Tartarus> ericben, but here I'm also testing my branch where we stop passing -rpath to everything by default
Feb 18 14:41:42 <Tartarus> Which based on poky isn't needed, even with older libtool
Feb 18 14:41:59 <Tartarus> (They dropped it back in 2007 as part of relying more on gcc --sysroot)
Feb 18 14:42:07 <ericben> Tartarus: ok
Feb 18 14:45:35 <bertszoghy> telnet is temporary, we will have buttons and linux drivers to switch
Feb 18 14:46:23 <ericben> Tartarus: btw, if you have fixes cleaner than what I sent feel free to push them there is no problem at all while the problems are fixed ;-)
Feb 18 14:47:09 <Tartarus> ericben, heh, I just don't know what's cleaner :)
Feb 18 14:47:26 <Tartarus> I slightly favor the poky approach just so we're both fixing it the same way which will make oe-core life easier
Feb 18 14:47:52 <ericben> Tartarus: yes. I don't think check poky for fixes
Feb 18 14:47:58 <Tartarus> (and in hind-sight I want to undo most of my acl clean-ups since poky's recipe is simply cleaner and we'll get that with oe-core)
Feb 18 14:51:59 <mike_cw> what might I use to look at the .dot dependency graphs assuming I don't have a billion gig of RAM?
Feb 18 14:52:30 <Tartarus> mike_cw, try bitbake -u depexp -g target
Feb 18 14:52:42 <Tartarus> Also, failure to parse the .dot files means your graphviz is too old
Feb 18 14:53:01 <Tartarus> (Annoyingly, only ubuntu 10.10 and newer have a recent enough version)
Feb 18 14:53:07 <Crofton> 10 AM and I still am not getting real work done :(
Feb 18 14:53:10 <mike_cw> I think it parses them ok - they are just huge
Feb 18 14:53:11 <Tartarus> despite a "new" enough version being a year or two old
Feb 18 14:53:25 <Tartarus> mike_cw, does it give you a graphic or no? :)
Feb 18 14:53:42 <demigod2k> mike_cw: how long did it take to parse? I just started trying it yesterday and after ~30 mins running I just ctrl-C'ed it
Feb 18 14:53:43 <Tartarus> mike_cw, also, I assume you're using bitbake 1.10.2 or newer
Feb 18 14:53:51 <Tartarus> there were bugs in the .dot files in the past
Feb 18 14:53:57 <mike_cw> yes, if I run it on my ubuntu 10.10 machine I can get dot to generate an svg, but it uses up all my RAM trying to render it!
Feb 18 14:54:05 <Tartarus> mike_cw, heh, ok
Feb 18 14:54:12 <Tartarus> try bitbake -u depexp -g target
Feb 18 14:54:15 <mike_cw> bb is 1.10.2
Feb 18 14:54:22 <mike_cw> ok I'll give that a try - thanks
Feb 18 14:54:23 <Tartarus> I think depexp is part of 1.10.2
Feb 18 14:55:52 <demigod2k> Tartarus: you commented that you were pulling out isystem from your local copy. when you get a sec, can you run a quick diff and tell me which files were affected? I'm having a hard time tracking down where the isystem gets added
Feb 18 14:58:23 <demigod2k> grep -Rl isystem * | wc -l gave me 94 files where that string occurs, seems like a heck of a lot
Feb 18 15:03:01 <Tartarus> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?h=trini/simplify-target-flags
Feb 18 15:03:05 <Tartarus> that's where I pushed it
Feb 18 15:03:26 <demigod2k> great thanks!
Feb 18 15:08:42 <demigod2k> udev appears to have a dependency on glib > 2.8
Feb 18 15:09:36 <mckoan> Tartarus: may i help you with ERROR: QA Issue with acl ? Tell me what to do.
Feb 18 15:10:56 <Tartarus> mckoan, just double checking my patch
Feb 18 15:11:44 * mckoan whistles
Feb 18 15:14:56 <mckoan> Tartarus: do I have to wait your patch instead of ericben one, right?
Feb 18 15:17:20 <CIA-47> 03Tom Rini <tom_rini@mentor.com> 07master * raf75d1bbac 10openembedded.git/recipes/udev/acl_2.2.49.bb: 
Feb 18 15:17:20 <CIA-47> acl: Fix RPATH QA issue and clean up
Feb 18 15:17:20 <CIA-47> We take some bits from poky to fix the RPATH QA issue and while in here
Feb 18 15:17:20 <CIA-47> clean it up a bit based on Ubuntu/Debian.
Feb 18 15:17:20 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 15:17:23 <CIA-47> 03Tom Rini <tom_rini@mentor.com> 07master * r30535972a5 10openembedded.git/recipes/libtiff/tiff_3.9.4.bb: 
Feb 18 15:17:23 <CIA-47> tiff: Fix RPATH QA issues
Feb 18 15:17:23 <CIA-47> Based on the fix for 'acl'
Feb 18 15:17:23 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 15:18:31 <Crofton> Tartarus, I've seen an rpath in something perl related
Feb 18 15:18:56 <Crofton> ERROR: QA Issue with libxml-parser-perl: package libxml-parser-perl contains bad RPATH /home/balister/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib in file /home/balister/oe/tmp/work/armv7a-angstrom-linux-gnueabi/libxml-parser-perl-2.36-r4/packages-split/libxml-parser-perl/usr/lib/perl5/auto/XML/Parser/Expat/Expat.so
Feb 18 15:19:02 <Crofton> is this one on the radar?
Feb 18 15:19:14 <woglinde> crofton not yet
Feb 18 15:19:19 <Tartarus> Maybe it is
Feb 18 15:19:23 <Tartarus> Can you reproduce it in my branch?
Feb 18 15:19:33 <Crofton> which branch?
Feb 18 15:19:43 <Tartarus> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?h=trini/simplify-target-flags
Feb 18 15:21:57 <Crofton> ok trying a quick test, checkout that branch and rerun bitbake command
Feb 18 15:22:15 <Tartarus> you'll need to -c clean whatever has an issue
Feb 18 15:22:46 <Crofton> ok
Feb 18 15:22:51 <Crofton> crappy morning
Feb 18 15:23:36 <Crofton> my desktop stopped talking to usb (no more keyboard) and I need to work out what we need to do with xora resigning from the board
Feb 18 15:23:57 <Crofton> anyone who thinks being on the board is easy should sit in my chair
Feb 18 15:25:08 <Crofton> all this dust .....
Feb 18 15:26:37 <demigod2k> I'll sign up for the board. My first motion will be to dissolve it, my section motion will be to buy ice cream
Feb 18 15:27:06 <Crofton> demigod2k, not helpful
Feb 18 15:27:26 <Crofton> we need people to work with outside organizations on the future of OE
Feb 18 15:27:37 <demigod2k> heh sorry just joking
Feb 18 15:27:39 <Crofton> there are a lot of really good things happening at the moment
Feb 18 15:27:58 <demigod2k> I believe it, that's why we're starting to look at it to replace buildroot on our next products
Feb 18 15:28:03 <Crofton> demigod2k, I appreciate the humor, just been a long morning
Feb 18 15:28:07 <Crofton> thanks
Feb 18 15:28:20 <Crofton> trust me, you are are doing the right thing
Feb 18 15:28:30 <demigod2k> there's a lot technically in the way but it does have promise. when we looked at it 2-3 years ago that wasn't the case
Feb 18 15:29:01 <Crofton> OE has a really strong developer community committed to its success
Feb 18 15:29:22 <Crofton> Tartarus, not fixed
Feb 18 15:29:44 <Crofton> ERROR: Build of /home/balister/oe/openembedded/recipes/perl/libxml-parser-perl_2.36.bb do_package failed
Feb 18 15:29:48 <Tartarus> hmm, ok
Feb 18 15:29:51 <mwester> But, IMO, troubled by the complexity of combining the building of the -native environment with the building of the target.
Feb 18 15:30:00 <Crofton> let me know if I can other things
Feb 18 15:30:15 <Crofton> need to find a vacuum
Feb 18 15:30:56 <mwester> Have you had the window open, Mr. Crofton?  Or construction in your office?
Feb 18 15:31:22 <demigod2k> ya it's beginning to align with the needs of board vendors (like my company) so it'll become a workable solution
Feb 18 15:39:05 <Crofton> mwester, sick pc, full of dust
Feb 18 15:40:12 <ajb_oe> Does opkg-cl refer to multiple locations when building SDKs? The list command always only shows the host packages and never any of the target packages
Feb 18 15:40:27 <ericben> for peoples used to bluez4 : any idea why I can do a pand connection (PC -> device) with device running 4.66 and not with device running 4.75 ?
Feb 18 15:41:32 * ajb_oe is beginning to think this mya just be an opkg-cl bug
Feb 18 15:49:21 <mckoan> QA Issue saga continues with wget (disabling it temporarily)
Feb 18 15:54:05 <martinmeba> I am getting QA issues with gnutils
Feb 18 15:54:39 <demigod2k> whats the issue
Feb 18 15:54:50 <martinmeba> bad RPATH
Feb 18 15:55:11 <martinmeba> 2.10.4-r11.0
Feb 18 15:55:23 <demigod2k> might look at the patch Tartarus linked earlier. What I'm working on is totally outside that area, but the patch fixed related problems for me
Feb 18 15:55:30 <martinmeba> ok
Feb 18 15:55:32 <martinmeba> will do
Feb 18 15:55:33 <martinmeba> thanks
Feb 18 15:56:06 <Tartarus> So, gnutls is another one I think I pushed the fix for
Feb 18 15:56:13 <Tartarus> before starting down my path in the branch above
Feb 18 15:56:57 <martinmeba> last night at home I also was still seeing an issue with gnome-vfs
Feb 18 15:57:05 <martinmeba> I am going to try to build here and see if it is still a problem
Feb 18 15:57:09 <ericben> Tartarus: for gnutls, the problem left is related to stdlibc++
Feb 18 15:57:36 <martinmeba> (the issue also RPATH)
Feb 18 15:58:19 <Crofton> vacuuming the computer and wiggling things seems to ahve helped
Feb 18 15:59:22 <Tartarus> ericben, I really need to finish this test here then, heh
Feb 18 15:59:39 <Tartarus> I really believe we've got a number of these errors due to passing -rpath to everything that's not libtool 2.4
Feb 18 15:59:46 <Tartarus> (from conf/bitbake.conf:TARGET_LDFLAGS)
Feb 18 15:59:56 <Tartarus> That's why a bunch of things fail on angstrom-2008.1 and pass on 2010.x
Feb 18 15:59:59 <Tartarus> and pass in minimal
Feb 18 16:00:37 <demigod2k> with proper sysroot it seems like a lot of that can just go away and be simplified
Feb 18 16:00:59 <Tartarus> gcc sysroot killed the need for passing -rpath everywhere
Feb 18 16:01:05 <Tartarus> And libtool sysroot fixed more stuff
Feb 18 16:01:15 <Tartarus> That's my read of how poky killed the -rpath everywhere back in 2007
Feb 18 16:01:25 <Tartarus> And I'm trying to confirm things now, but hitting the rest of the real QA errors :)
Feb 18 16:01:33 <Tartarus> Or at least, the ones that libtool 2.4 fixes
Feb 18 16:01:59 <demigod2k> libtool would've been the straggler. yes gcc picked that up somewhere in the 4.x's
Feb 18 16:03:25 <demigod2k> same for any -I and -L that picks up things that would've normally been system locations -- those can easily get killed
Feb 18 16:07:54 <mckoan> Tartarus: angstrom-2010.x doesn't have any bad RPATH issue? I can try to switch to it.
Feb 18 16:09:57 <Tartarus> It has less at least
Feb 18 16:27:11 <woglinde> mckoan I didnt saw any rpath issuses with angstroem2010
Feb 18 16:28:03 <ajb_oe> Whats the simplest meta toolchain in OE? I want to see if this libnet-dev problem occurs in another unrelated platform
Feb 18 16:28:25 <Tartarus> meta-toolchain
Feb 18 16:28:50 <mckoan> woglinde: good to know thx
Feb 18 16:32:33 <woglinde> tartarus bah the poky fix runs configure twice
Feb 18 16:33:53 <Tartarus> lets bug them in #poky then :)
Feb 18 16:34:34 <woglinde> tartarus I didnt say this worong
Feb 18 16:34:59 <woglinde>     sed -i ${S}/config.status -e s,^\\\(hardcode_into_libs=\\\).*$,\\1\'no\',                                                              
Feb 18 16:35:02 <woglinde> +    ${S}/config.status 
Feb 18 16:35:04 <woglinde> thats the poky fix?
Feb 18 16:35:10 * ajb_oe suspects this will fail as well as his toolchain is a simple extentsion of meta-toolchain
Feb 18 16:35:38 <Tartarus> woglinde, both lines
Feb 18 16:35:43 <Tartarus> and yes
Feb 18 16:35:52 <woglinde> yeah ${S}/config.status runs configure again
Feb 18 16:36:24 <woglinde> hm
Feb 18 16:36:34 * ajb_oe is not disapointed - fails again
Feb 18 16:38:05 <ajb_oe> I don't suppose it's worth trying to build the metatoolchain + libnet-dev for another target machine entirely? 
Feb 18 16:40:49 <woglinde> tartarus by the way the original sed fix comes from zecke if I remember correctly
Feb 18 16:41:02 <Tartarus> ok
Feb 18 16:41:18 <woglinde> for libiconv
Feb 18 16:55:16 <ka6sox-away> Crofton, got tracking?
Feb 18 16:57:18 <ajb_oe> ahh!
Feb 18 16:57:34 <Crofton> sent already
Feb 18 16:57:59 <ka6sox-away> it must have gotten lost in the duff
Feb 18 16:58:01 <woglinde> ka6sox that was a short nite again
Feb 18 16:58:26 <ka6sox-away> woglinde, way too short.
Feb 18 16:58:47 <Crofton> sent again
Feb 18 16:58:52 <Crofton> from my .com account
Feb 18 16:59:37 <ajb_oe> OK I think I know what is happening - libnet-dev has a dependancy on libnet, but libnet is never created there is only libnet-static
Feb 18 17:00:29 <hrw> even BMW has people using OE...
Feb 18 17:01:12 <ka6sox-away> Crofton, thansk
Feb 18 17:01:25 <ajb_oe> is the creation of the libnet dependancy created automagically? I can't see any sign of it being declared in the libnet .bb file
Feb 18 17:03:21 <woglinde> hi hrw
Feb 18 17:12:21 <CIA-47> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r2e667ba62e 10bitbake.git/ (bin/bitbake lib/bb/__init__.py): Release 1.12.0
Feb 18 17:12:21 <CIA-47> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r92f111a0b2 10bitbake.git/ (bin/bitbake lib/bb/__init__.py): Increment version for development version
Feb 18 17:39:18 <ajb_oe> How do you supress an automatic dependancy for a package?
Feb 18 17:39:41 <ajb_oe> Or should I just let libnet build a "fake" non-static package that will satisfy it?
Feb 18 17:42:41 <GNUtoo|oeee> ajb_oe, RDEPENDS
Feb 18 17:43:43 <ajb_oe> GNUtoo|oeee: I though that defined runtime dependancies?
Feb 18 17:43:59 <GNUtoo|oeee> yes
Feb 18 17:44:09 <GNUtoo|oeee> isn't that what you're talking about
Feb 18 17:44:20 <GNUtoo|oeee> you said package and not recipe
Feb 18 17:44:24 <ajb_oe> GNUtoo|oeee: I want to supress the automatic dependancy libnet-dev has on libnet
Feb 18 17:44:38 <GNUtoo|oeee> why?
Feb 18 17:44:56 <GNUtoo|oeee> if you tell why, maybe we will find a better way
Feb 18 17:44:57 <ajb_oe> GNUtoo|oeee: because otherwise you cannot create an SDK with libnet-dev
Feb 18 17:45:03 <GNUtoo|oeee> ok
Feb 18 17:45:23 <ajb_oe> As libnet-dev depeneds on libnet which doesn't exist (bit libnet-static does)
Feb 18 17:45:28 <ajb_oe> s/bit/but
Feb 18 17:46:26 <ajb_oe> currently I've just commented out 'FILES_${PN} = ""' from the recipie and that works, but I suspect that patch would get dropped 
Feb 18 17:47:53 <GNUtoo|oeee> I don't know sdk enough
Feb 18 17:47:55 <GNUtoo|oeee> but....
Feb 18 18:21:50 <dsoft> Hi, I get an error when I try to compile QT Embedded SDK. Can someone help me of you? Here is a link to the logfile: http://pastebin.com/JRE0rp8v
Feb 18 18:28:00 <dsoft> Hi, I get an error when I try to compile QT Embedded SDK. Can someone help me of you? Here is a link to the logfile: http://pastebin.com/JRE0rp8v
Feb 18 18:34:42 <ajb_oe> dsoft: what do you have in tmp/deploy/ipk/${ARCH}/ for ncurses?
Feb 18 18:35:05 * ajb_oe has been fighting SDK issues for most of the week
Feb 18 18:35:43 <ajb_oe> of course that assume the QT emebedded is a ipkg based system, Ihave no idea
Feb 18 18:36:48 <otavio> dsoft: I just sent a set of patches that changes things regarding qt, qmake, cmake and sdk.
Feb 18 18:36:53 <otavio> dsoft: check ml
Feb 18 18:37:13 <dsoft> http://pastebin.com/XS7jQY1y
Feb 18 18:39:32 <dsoft> So should I make an update via git
Feb 18 18:55:15 <mike_s> anyone had libpcre build recently? Got QA error - bad RPATH on Angstrom/ARM
Feb 18 19:03:01 <demigod2k> Tartarus: the patch you linked earlier eliminating -isystem fixes 2 of the failing packages, but introduced a problem with gtk+
Feb 18 19:07:09 <demigod2k> gtk+ chokes on sed/grep where I think it's trying to substitute hardcoded paths during do_compile, can't find libstdc++.la because of a wrong path
Feb 18 19:15:29 <mike_s> demigod2k, is that change likely to have broken libpcre as well? I did a git pull just in the last few hours.  The recipe does do some sed fix-ups
Feb 18 19:19:15 <demigod2k> I have no idea if it was committed or not (or how to tell). here's the link: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?h=trini/simplify-target-flags
Feb 18 19:21:16 <mike_s> yes it's in there
Feb 18 19:21:52 <mike_s> last two commits were also for RPATH QA issues so seems likely libpcre is a casualty as well
Feb 18 19:21:53 <demigod2k> did you pinpoint where/how the bad path is being generated? I was seeing normal_sysroot concatenated with the value of --sysroot
Feb 18 19:22:19 <Tartarus> OK
Feb 18 19:22:38 <Tartarus> So, based on digging at poky a bit, I'm going to propose something like JaMa's patch over in http://patches.openembedded.org/patch/573/
Feb 18 19:22:41 <demigod2k> probably. I've see a few other libraries affected by this that don't have the problem so I'm trying to find the difference
Feb 18 19:22:53 <Tartarus> Basically, poky doesn't call these errors fatal yet, and at least a few of them are real hard
Feb 18 19:23:09 <Tartarus> So I think we need to (a) call warnings warnings and errors errors and (b) not make that one fatal yet
Feb 18 19:27:22 <mike_s> demigod2k: looks like it's just passing -rpath /usr/lib to libtool in this case.  I can see that in at least one place
Feb 18 19:28:50 <khem> hmm
Feb 18 19:29:58 <Tartarus> khem, posted patch to the ML, assuming I got you going hmm ;)
Feb 18 19:30:40 <khem> crazy day 
Feb 18 19:30:51 <Tartarus> heh
Feb 18 19:31:03 <Tartarus> It's friday so, time to prepare for crazier weekend of OE hacking? ;)
Feb 18 19:31:42 <khem> yeah I need to refresh the demo for SCALE too
Feb 18 19:31:54 * khem looks for 8th day in a week
Feb 18 19:31:59 <khem> oh monday is off
Feb 18 19:32:01 <khem> that helps
Feb 18 19:32:42 <Tartarus> heh
Feb 18 19:32:49 * Tartarus has a floating holiday rather than presidents day off :(
Feb 18 19:33:42 <khem> I can take anyones holidays
Feb 18 19:33:48 <Tartarus> heh
Feb 18 19:33:49 <khem> my PTO has expired
Feb 18 19:33:53 <khem> I am in minus
Feb 18 19:35:28 <fray> hey, I have Monday off work also!
Feb 18 19:35:31 <fray> who knew?!
Feb 18 19:35:50 <demigod2k> it appears libfsobasics also as a glib > 2.8 dependency
Feb 18 19:35:55 <philippe> khem, PTO? Power take off?
Feb 18 19:36:06 <fray> "Paid Time Off"
Feb 18 19:36:26 <philippe> Ah ok. Never heard that shorthand. Thanks fray
Feb 18 19:36:49 <khem> yeah probably now I dont differentiate US slangs anymore
Feb 18 19:37:15 <khem> I still call football a football
Feb 18 19:37:20 <Tartarus> heh
Feb 18 19:37:22 * fray notes he's rather have a Power Take Off then Paid Time Off on monday.. ;)
Feb 18 19:38:47 <demigod2k> we got 5 vacation days taken away during 2008 :(
Feb 18 19:39:09 <khem> demigod2k: Do you work for DMV :)
Feb 18 19:39:49 <demigod2k> no automotive industry
Feb 18 19:39:57 <khem> (another acronym for Dept of Motor Vehicles)
Feb 18 19:40:03 <khem> well close enough
Feb 18 19:40:46 <khem> I have this lunch meeting but its raining cats and dogs
Feb 18 19:41:21 <demigod2k> pretty much. fortunately I'm not at an automaker; that may as well be the government for how big and slow they are
Feb 18 19:41:56 <khem> I love how they treat customers at DMV
Feb 18 19:43:04 <demigod2k> ours doesn't accept credit card so it's painful to pay for things
Feb 18 19:49:49 <fray> our DMV only accepts credit cards for "on-line" renewals.. but for which I'm not eligable for some reason..
Feb 18 19:50:11 <fray> and they won't accept bill-pay checks..  so I just drive down to the local office and do whatever I need..
Feb 18 19:50:43 <khem> DMV here you still have to stand up in lines even if you take an appointment after waiting 30 mins on phone
Feb 18 19:50:43 <fray> luckily in MN, they allow private companies to run small DMV offices for basic services.. so the lines aren't as bad..  (the local bank has a DMV line that is NEVER busy)
Feb 18 19:51:00 <khem> and then they think we are wasting their time
Feb 18 19:51:33 <fray> heh, I don't know if my bank DMV can renew a license though -- I get to do that this year...
Feb 18 19:52:15 <demigod2k> Recently I had to get 3 licenses in a year... added motorcycle endorsement, something else, and birthday renewal. every time had to take a new photo and get a new one mailed to me
Feb 18 19:52:24 <demigod2k> oh right moving.
Feb 18 19:52:54 <fray> wow.. here they re-use your photo (unless you request a new oen) during the 10-year life of the license
Feb 18 19:53:07 * fray is at the birthday renewel so I get a new picture this year.. ;)
Feb 18 19:53:18 <demigod2k> michigan hasn't managed that level of technology
Feb 18 19:53:41 <fray> heh.. my current livense is from 2008 when I moved -- but it's the same picture as 2001
Feb 18 19:54:03 <fray> local bank was able to change my address and reissue the license.. but I'm not sure if they can do renewels.. I'll have to ask next time i go in..
Feb 18 19:55:00 * fray is glad he never had to deal with the CA DMV for the year I lived out there
Feb 18 19:55:49 <demigod2k> CA canada or CA the people's republic of california?
Feb 18 19:56:32 <tzanger> well there is no federal department of motor vehicles in canada so I would assume he means california
Feb 18 19:56:43 <fray> the later
Feb 18 19:57:30 <demigod2k> yes that would be rough.... they do emissions testing. fortunately michigan doesn't
Feb 18 19:57:46 <Tartarus> emissions isn't too bad here
Feb 18 19:58:14 <fray> AFAIK, California emissions testing has gone to visual inspection + ODB2 port on newer cars.. so it's not nearly as bad as it used to be..
Feb 18 19:58:27 <tzanger> in ontario the driveclean program isn't bad
Feb 18 19:58:30 <fray> but it's still stupid to have to pay someone to plug into the car and see that everything is running fine
Feb 18 19:58:56 <tzanger> emissions test at idle and 20km/h I think, gas cap pressure test, leak inspection with a wand... that's about it
Feb 18 19:59:02 <tzanger> takes about 20 minutes from start to finish
Feb 18 19:59:08 <demigod2k> fray: buddy in colorado said he had a tailpipe sniffer + dyno test. and with a subaru he had to go >100 miles to place with a 4WD dyno
Feb 18 19:59:23 <fray> glad I don't have that here..
Feb 18 19:59:37 <tzanger> demigod2k: yeah but a 100mi road trip at highway speed really helped make sure he passed. :-)
Feb 18 19:59:39 <fray> when MN had emissions testing in the early/mid 90's.. the dyno was only used if you failed at idle..
Feb 18 20:00:00 <fray> they figured out they took less then 100 cars off the road each year for the 10 years the program was running... so they abandoned it
Feb 18 20:00:08 <tzanger> that's not bad
Feb 18 20:00:24 <tzanger> some of the shitboxes I see driving around OH and PA though... they're safety hazards
Feb 18 20:00:31 <fray> heh
Feb 18 20:00:41 <demigod2k> another buddy here was ultra-pissed, for some reason he got picked for emissions testing within the first year of ownership and his brand new vehicle didn't pass
Feb 18 20:00:43 <fray> MN didn't even have a safety inspection -- it was just emissions..
Feb 18 20:00:51 <ericben> hi khem can you ack or nack this patch http://patches.openembedded.org/patch/695/ so that I can push the serie ?
Feb 18 20:00:58 <tzanger> wow we don't have emissions for super brand new or super old
Feb 18 20:01:01 <fray> if they're going to do visual emissions inspection, then they should at least do basic safety..
Feb 18 20:01:08 <tzanger> what do they call it "late model" I think
Feb 18 20:01:16 <fray> tzanger MN was for all vehicles every year..
Feb 18 20:01:51 <demigod2k> tzanger: I think it was because he moved from out-of-state into a state with testing and they required it the first time he registered the car. it was something like 3 months after he bought it
Feb 18 20:01:52 <fray> they said most of the failures were in brand new vehicles where the cat failed prematurely... the engine light would have come on anyway..
Feb 18 20:01:56 <fray> again another reason they dropped it
Feb 18 20:01:58 <tzanger> fray: Ontario is every other year... even model year in odd years (why they crossed it like that is beyond me)
Feb 18 20:02:11 <fray> heh
Feb 18 20:02:11 <tzanger> crazy
Feb 18 20:02:19 <tzanger> new car comes with warranty though, I imagine?
Feb 18 20:02:58 <fray> ya, in the US emissions are required for 2 years.. (most are 3 year or 36k miles or better) and the catalyst for 8 years/100k miles
Feb 18 20:03:01 <demigod2k> I'd imagine; I didnt ask him for the details of how it got fixed. I would be pretty pissed if my brand new car failed, that's for sure
Feb 18 20:03:28 <fray> the 2 years & catalyst are federal requirements.. california and I think Texas maybe have state laws mandating 3 years for the full emission system
Feb 18 20:03:43 <fray> ya
Feb 18 20:03:55 * fray goes to hurd cats.. time for a vet visit..
Feb 18 20:04:39 <CIA-47> 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * ra07e7b983a 10openembedded.git/lib/oe/utils.py: 
Feb 18 20:04:39 <CIA-47> utils.py: use bb.utils.vercmp_string instead of bb.vercmp
Feb 18 20:04:39 <CIA-47> * Fixes deprecation warning with BitBake master.
Feb 18 20:04:39 <CIA-47> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Feb 18 20:04:39 <CIA-47> CC: Chris Larson <chris_larson@mentor.com>
Feb 18 20:04:40 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 20:05:35 <fray> 5 farm cats -- all to the vet for shots...  (anyone in Souther MN want a cat?  I've got extras)  ;)
Feb 18 20:06:03 <khem> ericben: yes acked ?
Feb 18 20:06:22 <khem> ericben: Did you build gcc-cross-sdk with this change
Feb 18 20:06:30 <khem> for micro and say angstrom ?
Feb 18 20:06:38 <CIA-47> 03Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * r02ed1292b6 10openembedded.git/recipes/udev/ (udev_151.bb udev_162.bb udev_165.bb): 
Feb 18 20:06:38 <CIA-47> udev_151/162/165.bb: add missing PACKAGE_ARCH for nokia900
Feb 18 20:06:38 <CIA-47> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Feb 18 20:06:38 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 20:06:49 <CIA-47> 03Alex Bennee <ajb@cbnl.com> 07org.openembedded.dev * r55169699a4 10openembedded.git/recipes/linux-atm/linux-atm_2.5.1.bb: 
Feb 18 20:06:49 <CIA-47> Add flex to the linux-atm dependencies
Feb 18 20:06:49 <CIA-47> As the linux-atm tools also link against the flex libraries (-lfl) the
Feb 18 20:06:49 <CIA-47> runtime is also needed as a dependency.
Feb 18 20:06:49 <CIA-47> Signed-off-by: Alex Bennee <ajb@cbnl.com>
Feb 18 20:06:49 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 20:08:24 <ericben> khem: angstrom build in progress
Feb 18 20:08:28 * Tartarus does patchworking
Feb 18 20:09:56 * khem heads for lunch
Feb 18 20:10:15 <ericben> khem: good appetite :)
Feb 18 20:10:36 <CIA-47> 03Filip Zyzniewski <filip.zyzniewski@gmail.com> 07org.openembedded.dev * r68df3ce2ae 10openembedded.git/classes/kernel.bbclass: (log message trimmed)
Feb 18 20:10:36 <CIA-47> kernel.bbclass: fix retrieving dependencies between modules.
Feb 18 20:10:36 <CIA-47> get_dependencies() searched for a filename key in dependencies
Feb 18 20:10:36 <CIA-47> directory with the /lib/modules/kernel_version prefix while
Feb 18 20:10:36 <CIA-47> the directory had entries stripped of it.
Feb 18 20:10:36 <CIA-47> Signed-off-by: Filip Zyzniewski <filip.zyzniewski@gmail.com>
Feb 18 20:10:37 <CIA-47> Acked-by: Khem Raj <raj.khem@gmail.com>
Feb 18 20:11:26 <philippe> Those bitbake changes in the time I have been away have certainly improved the machines CPU usage. All 4 CPUS maxed out.
Feb 18 20:11:31 <philippe> Excellent
Feb 18 20:12:15 <Tartarus> yes, we have parallel parsing up front now
Feb 18 20:12:24 <Tartarus> that figures out # CPUs and defaults to that many for the parse
Feb 18 20:13:00 <Jay7> evening
Feb 18 20:14:17 <demigod2k> Tartarus: so with that patch under sysroots/*/lib there are a bunch of *.la files including libstdc++.la which contain libdir='xx' hardcoded to the compiler's sysroot, not the --sysroot within OE that I passed
Feb 18 20:14:24 <demigod2k> what I can't tell is if that's the root cause of my problem or not
Feb 18 20:14:40 <philippe> Tartarus, It really seems to work. Too bad it is only two real CPUS and two hyperthreaded things.
Feb 18 20:14:49 <demigod2k> it would appear that way though since the working *.la have libdir='/usr/lib'
Feb 18 20:28:41 <ericben> demigod2k: I confirm that
Feb 18 20:28:43 <CIA-47> 03Tom Rini <tom_rini@mentor.com> 07master * rba90568ce4 10openembedded.git/recipes/udev/acl_2.2.49.bb: 
Feb 18 20:28:43 <CIA-47> acl: Revert most of my last change, just fix RPATH QA
Feb 18 20:28:43 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 20:28:50 <CIA-47> 03Tom Rini <tom_rini@mentor.com> 07master * ra615cbed3c 10openembedded.git/recipes/libcdio/libcdio.inc: 
Feb 18 20:28:50 <CIA-47> libcdio: Fix RPATH QA errors
Feb 18 20:28:50 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 20:28:53 <CIA-47> 03Tom Rini <tom_rini@mentor.com> 07master * rf838e470b7 10openembedded.git/recipes/schroedinger/ (schroedinger.inc schroedinger_1.0.9.bb): 
Feb 18 20:28:53 <CIA-47> schroedinger: Fix RPATH QA errors
Feb 18 20:28:53 <CIA-47> Signed-off-by: Tom Rini <tom_rini@mentor.com>
Feb 18 20:30:14 <demigod2k> doh, actually those *.la came from my external toolchain's sysroot so they're probably my problem. still investigating
Feb 18 20:32:40 <mike_s> libpcre issue is the same - *.la contains libdir=/usr/lib
Feb 18 20:34:05 <demigod2k> mike_s: whats the gist of the error you're getting in that case
Feb 18 20:35:08 <ericben> khem: there seems to be a configuration issue in patchwork : all my mails don''t reach it. Maybe because of the é in my name ?
Feb 18 20:35:41 <mike_s> demigod2k: hang on while I bitbake again to refresh my memory...
Feb 18 20:36:24 <mike_s> fails in do_package with QA Issue: package contains bad RPATH
Feb 18 20:36:40 <mike_s> compile log shows libtool link step has -rpath /usr/lib
Feb 18 20:36:42 <zecke> OT: anyone still has a OE.mtn file?
Feb 18 20:36:45 <ericben> mike_s: is libpcre using libstdc++ ?
Feb 18 20:37:12 <Tartarus> zecke, I have one in svn history
Feb 18 20:37:17 <Tartarus> dunno if it was final current
Feb 18 20:38:18 <Tartarus> I can dig it out without too much trouble
Feb 18 20:39:09 <mike_s> ericben: links with g++ so yes
Feb 18 20:39:28 <ericben> mike_s: ok so the problem is related to libstdc++.la 
Feb 18 20:41:43 <philippe> zecke, must have one on my old machine. Was going to revive it this week
Feb 18 20:42:02 <philippe> But must be at least 10 months old
Feb 18 20:42:21 <Tartarus> Mine's from 2008-10-21 or so
Feb 18 20:42:49 <Tartarus> I said "Final" in the svn log, but I don't recall the switchover date, heh
Feb 18 20:46:04 <Jay7> well.. angstrom-2010.x builds of release-testing are fine
Feb 18 20:46:30 <Jay7> 2 minimal builds left
Feb 18 20:46:46 <Jay7> all builds of angstrom-2008.1 are failed 
Feb 18 20:47:16 <ericben> Jay7: yes QA issues
Feb 18 20:47:36 <Jay7> ericben: push your patch to oestats-client :)
Feb 18 20:48:02 <Jay7> s/to/for/
Feb 18 20:48:33 <Jay7> hm..
Feb 18 20:48:44 <Jay7> but if someone is using own oestats server
Feb 18 20:48:49 <Jay7> then we will broke it
Feb 18 20:48:55 <ericben> Jay7: for the errors related to c++ : sysroots/armv5te-angstrom-linux-gnueabi/usr/lib/libstdc++.la: edit libdir to /usr/lib
Feb 18 20:48:55 <Jay7> that's bad
Feb 18 20:49:36 <ericben> Jay7: we ccould have a variable to enable / disable full logging to oestat
Feb 18 20:49:49 <Jay7> ericben: that's are testing builds, so no sense to fix it now :)
Feb 18 20:50:25 <ericben> or maybe disable full logging to oestat based on the url 
Feb 18 20:50:40 <Jay7> ericben: yes, but then we should force to switch it..
Feb 18 20:51:30 <Crofton> oestats is becoming a huge problem for ka6sox
Feb 18 20:51:50 <Jay7> yeah..
Feb 18 20:52:07 <Crofton> we may need to turn it off until a solution can be found
Feb 18 20:52:10 <Tartarus> My fault, yeah
Feb 18 20:52:15 <Jay7> it is turned off already
Feb 18 20:52:16 <Tartarus> Want me to just turn off tinderbox?
Feb 18 20:52:31 <Jay7> Tartarus: it is down at server side
Feb 18 20:52:44 <Tartarus> Yeah, but I'm pretty sure my monster setup isn't helping
Feb 18 20:52:45 <Crofton> I'm not 100% up on the details, but I know he has been spending a lot of time on this
Feb 18 20:52:46 <Jay7> we should rewrite it..
Feb 18 20:52:58 <Tartarus> (and since it's off,lemme turn that bit off for this weekends run)
Feb 18 20:53:03 <Tartarus> I've got 1053 or so combinations to run, heh
Feb 18 20:53:08 <Jay7> omg
Feb 18 20:53:16 <Jay7> Tartarus: seems pretty huge :)
Feb 18 20:53:41 <Tartarus> Yes, IT is gonna use it to scare people
Feb 18 20:54:05 <Crofton> heh
Feb 18 20:54:26 <Crofton> can you guys work with ka6sox with the goal of reducing his problems
Feb 18 20:54:46 <Crofton> even if it mean sshutting down stats reporting until we have a long term problem
Feb 18 20:54:56 <Crofton> I do not want to burn him out over this
Feb 18 20:55:14 <Tartarus> yeah, certainly
Feb 18 20:55:29 <ericben> Crofton: http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-February/030135.html
Feb 18 20:55:31 <ka6sox> thanks guys..
Feb 18 20:55:55 * Jay7 have about 30 combinations of distro/machine
Feb 18 20:56:14 <ericben> Crofton: in fact v2 is herehttp://lists.linuxtogo.org/pipermail/openembedded-devel/2011-February/030136.html
Feb 18 20:56:18 <Jay7> Crofton: seems there is no way to drive on current engine..
Feb 18 20:56:36 <Jay7> only with patch above
Feb 18 20:57:06 <ka6sox> its really a 2 part problem
Feb 18 20:57:23 <Jay7> we have some ideas but this need someone to rewrite some code
Feb 18 20:57:47 <ka6sox> 1 is 5-20 puts/sec from the server (with attendent joins/parts on the mysqlserver)
Feb 18 20:58:10 <demigod2k> ericben: that was enough to get it working? I edited it manually, did a -c clean, still no dice here
Feb 18 20:58:24 <Tartarus> ka6sox, do we need beefier hardware?
Feb 18 20:59:00 <ka6sox> 2 is you are keeping 5months of data around...which means over 16million records to be searched every time someone goes to tinderbox.openembedded.org
Feb 18 20:59:12 <Jay7> we may move oestats to other place
Feb 18 20:59:15 <Jay7> with shared mysql
Feb 18 20:59:35 <Jay7> s/shared/own/
Feb 18 20:59:47 <ka6sox> Tartarus, you guys are 3X the intensity of usage as other projects.
Feb 18 20:59:50 <Jay7> own dedicated even :)
Feb 18 21:00:14 <Jay7> but right way is rewrite it..
Feb 18 21:00:19 <ka6sox> when you guys stopped using oestats this morning...the other projects sped up by 2X
Feb 18 21:00:34 <ka6sox> its not properly written.
Feb 18 21:00:53 <ka6sox> from reporting the builds to displaying the data.
Feb 18 21:01:19 <ka6sox> crofton said it best: "it doesn't scale well"
Feb 18 21:02:15 <Tartarus> A wishlist item from me would be for builders to configure a shorter than default expire period
Feb 18 21:03:57 <ka6sox> since we have so many different things going on wouldn't a more modern build management system assigning "builds" and being reported back to like hudson/jenkins not make more sense than trying to continue with a system that doesn't scale?
Feb 18 21:04:33 <ka6sox> that would also allow us to add/move resources as necessary.
Feb 18 21:04:56 <Tartarus> I'd certainly like to talk with the jenkins folks in this regard and see if they have ideas
Feb 18 21:05:14 <Tartarus> But there's limitations / issues to be dealt with and it might take a few plugins to get it going, heh
Feb 18 21:05:16 <Jay7> ka6sox: that's good idea but this is other 'vision'
Feb 18 21:06:24 <ka6sox> Tartarus, I've been talking to them for a bit...the biggest issues are JNLP staying UP and how to integrate bitbake with it.
Feb 18 21:07:38 <ka6sox> since we have to work behind firewalls with builders JNLP is almost a necessity
Feb 18 21:08:49 <Crofton> guys, something I would like to see from a board perspective is a working group of poeple dealing with this
Feb 18 21:09:09 <Crofton> to share the load so all the work does not fall on ka6sox 
Feb 18 21:09:10 <nschle85> hi i have jenkins running compiling shr images ....  http://norman-schleicher.de/jenkins/job/shr-unstable-image-clean-build/162/console
Feb 18 21:09:23 <Crofton> and so it is easier for us to know who is doing what
Feb 18 21:09:35 <Crofton> OE is getting hard to keep track off
Feb 18 21:09:49 <nschle85> if you want some of my experiences you can ask me :-)
Feb 18 21:10:13 <ka6sox> nschle85, of course.
Feb 18 21:10:24 <Crofton> and I am off to the store :)
Feb 18 21:10:27 <ka6sox> I'll join that group
Feb 18 21:11:27 <ka6sox> anybody who has hudson/jenkins experience would be helpful.
Feb 18 21:11:47 <nschle85> ka6sox: do you mean me ?
Feb 18 21:12:24 <Crofton> well organize yourselves :)
Feb 18 21:12:47 <ka6sox> nschle85, I said yes please.
Feb 18 21:12:53 <dv> why I can't build u-boot? http://pastebin.com/DAiA0B7w
Feb 18 21:13:02 <ka6sox> sorry, I shouldn't have used "of course"
Feb 18 21:13:05 <Jay7> Crofton: I can collaborate here
Feb 18 21:13:15 <Jay7> as admin and as interested person :)
Feb 18 21:13:59 <Tartarus> ka6sox, I kinda think a JNLP "slave jenkins" is needed really
Feb 18 21:14:04 <Jay7> but as I said above, using buildbot/hudson is at other side
Feb 18 21:14:12 <ka6sox> Tartarus, absolutely agree.
Feb 18 21:14:14 <Tartarus> Or some other way for the behind FW jenkins to come up and say "here, I did _this_"
Feb 18 21:14:25 <ka6sox> JNLP slaves
Feb 18 21:14:30 <Jay7> now we are building on our own computers
Feb 18 21:14:50 <ka6sox> well..we just add the slave software and point it to the master.
Feb 18 21:15:02 <ka6sox> but integration to BB is necessary
Feb 18 21:15:11 <ka6sox> both for control as well as for reporting.
Feb 18 21:15:26 <ka6sox> someone might have already done this.
Feb 18 21:15:39 <Jay7> yocto :)
Feb 18 21:15:46 <Tartarus> well, it can't be just slave VMs
Feb 18 21:15:53 <Jay7> zenlinux have some experience iirc
Feb 18 21:15:53 <Tartarus> since mine are all dynamically controlled
Feb 18 21:15:55 <Tartarus> and run other jobs
Feb 18 21:16:11 <ka6sox> Tartarus, then we have to be able to drop them into the queue
Feb 18 21:16:14 <Tartarus> I dunno if we really need bb control, there's prep work to be done
Feb 18 21:16:23 <ka6sox> kk
Feb 18 21:16:39 <Tartarus> ka6sox, that's what I'm getting at.  What I envision is a public jenkins that others can report what they did to, once done
Feb 18 21:16:48 <Jay7> is it possible to run interested builds only on my hw connected to buildbot/hudson?
Feb 18 21:16:55 <Tartarus> ie I can kick my monster off and once it's done, it reports to the public one "I did this"
Feb 18 21:17:04 <ka6sox> okay so instead of "control" its just a news gatherer.
Feb 18 21:17:14 <ka6sox> that sounds good.
Feb 18 21:17:55 <Jay7> good thing in oestats is that I run my own builds where I wish and report results to public place
Feb 18 21:17:58 <ka6sox> we have offers of build resources...but I think we will need to "control" and task them.
Feb 18 21:18:07 <Jay7> is it possible with other solutions?
Feb 18 21:18:20 <ka6sox> Jay7, jenkins does that.
Feb 18 21:19:15 <ka6sox> okay so a passive jenkins....interesting thought.
Feb 18 21:19:27 <Tartarus> Well, I think we need both
Feb 18 21:19:28 <ka6sox> slaves are reporters.
Feb 18 21:19:30 <Tartarus> the ability to control
Feb 18 21:19:33 <Tartarus> and the ability to just take info
Feb 18 21:19:47 <ka6sox> yes, that sounds like the right approach.
Feb 18 21:21:17 <philippe> dv, looks like an issue getting the source code
Feb 18 21:27:29 <Jay7> yes, we need both
Feb 18 21:27:38 <Jay7> someone may add his HW as slaves
Feb 18 21:27:52 <Jay7> someone may wish to build own sets and report results only
Feb 18 21:28:10 <philippe> Jay7, I could spare one machine to do so.
Feb 18 21:28:22 <philippe> Just need to add some disk to it
Feb 18 21:28:54 <Jay7> I can share my buildmachine too but limited by time of day
Feb 18 21:29:10 <Jay7> e.g. at night
Feb 18 21:29:58 <ka6sox> yes ther is the PT builder issue..and with a passive jenkins that wouldnt' be a problem.
Feb 18 21:32:18 <martinmeba> dv: it can't download the file to build - that is why it fails
Feb 18 21:32:28 <martinmeba> what is the link?
Feb 18 21:32:41 <Jay7> ka6sox, Tartarus: well.. do we go this way then?
Feb 18 21:33:34 <ka6sox> Jay7, we need to investigate...jenkins wasn't made to operate this way
Feb 18 21:33:36 <Tartarus> allowing both passive results and kicking things off to slaves it runs? yes, I think so
Feb 18 21:33:38 <martinmeba> it is not really a build failure - it is a fetch failure
Feb 18 21:33:46 <Tartarus> and yes, there's not quite the plugins we need
Feb 18 21:33:58 <Tartarus> there's a way to have multiple jenkins talk to eachother
Feb 18 21:34:03 <Tartarus> but i don't know if it's passive like this
Feb 18 21:34:04 <Jay7> yocto is using buildbot setup
Feb 18 21:34:08 <Tartarus> nor if it can be limited to only some builds
Feb 18 21:34:37 <ka6sox> the question I have is if jenkins is tied to a Statetable for builds.
Feb 18 21:34:48 <ka6sox> in which case we are short circuiting it.
Feb 18 21:35:09 <ka6sox> (things like timeouts if a builder doesn't respond etc)
Feb 18 21:35:19 <ericben> khem: that is a issue with "é" in my namein patchwork. Look http://patches.openembedded.org/patch/715/ I sent 2 ack, one with the é which didn't make it into patchwork and one without the "é" which went in patchwork. Any idea of a configuration on the server side ?
Feb 18 21:35:30 <Tartarus> So, slaves it runs can timeout
Feb 18 21:36:23 <ka6sox> I'm trying to figure out how a passive slave can get jenkins to know
Feb 18 21:36:31 <ka6sox> A) the passive slave kicked off a build
Feb 18 21:36:57 <ka6sox> B) accept "updates" that the slave reports back
Feb 18 21:37:11 <ka6sox> C) report the results.
Feb 18 21:37:11 <Tartarus> Well, that's why I think we need passive peer jenkins
Feb 18 21:37:15 <Tartarus> and active slaves
Feb 18 21:37:20 <Tartarus> (I wasn't clear enough before I think()
Feb 18 21:37:52 <ka6sox> okay so all slaves are in charge of their builds...and jenkins master is merely a reporting/stats facility
Feb 18 21:37:58 <Tartarus> Maybe we need to rope one of the #jenkins folks into a chat
Feb 18 21:38:08 <Tartarus> and give them the layout of what kind of resources we have available
Feb 18 21:38:10 <Tartarus> see what they suggest
Feb 18 21:38:34 <ka6sox> their current model is active master, with JNLP slaves.
Feb 18 21:38:39 <Tartarus> yeah
Feb 18 21:38:46 <Tartarus> But like I said, there's plugins to allow peer jenkins
Feb 18 21:38:58 <ka6sox> right..might be a good starting place.
Feb 18 21:39:12 <ka6sox> I'm idling in #jenkins.
Feb 18 21:39:42 <Tartarus> yeah.  Not sure who best among the active folks to bug about this :)
Feb 18 21:39:53 <ericben> http://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs
Feb 18 21:41:30 <ka6sox> I have a couple of guys I've talked to..want me to take point on this?
Feb 18 21:41:45 <ka6sox> I'll report back to the group.
Feb 18 21:41:59 <Tartarus> Yeah, sure.  Thanks!
Feb 18 21:42:26 * Jay7 dislike java but..
Feb 18 21:42:27 <ka6sox> okay I'll probably drag one of you guys in too to correct me on how it works..I'm an infra guy.
Feb 18 21:42:53 <ka6sox> Jay7, dislike is better than plain not knowing which is what we have now.
Feb 18 21:42:58 <dv> martinmeba, looks like... do I have to update oe?
Feb 18 21:43:18 <martinmeba> dv: is it a stock recipe or did you write it?
Feb 18 21:43:31 <dv> it's a stoke recipe
Feb 18 21:43:37 <dv> stock
Feb 18 21:43:39 <martinmeba> then maybe the mirror is down or something
Feb 18 21:43:56 <martinmeba> maybe try again a little later
Feb 18 21:43:57 <Jay7> "Submit a run programatically"
Feb 18 21:44:10 <Jay7> jenkins can do it
Feb 18 21:44:34 <Jay7> but then we should do same thing as now for oestats
Feb 18 22:15:54 <khem> ericben: hmm I have applied the utf-8 patch 
Feb 18 22:16:03 <khem> ericben: was it like today 
Feb 18 22:18:34 <ericben> khem: what do you mean by " was it like today" ?
Feb 18 22:18:47 <khem> when did u send those patches
Feb 18 22:18:56 <ericben> ah ok today :)
Feb 18 22:19:37 <ericben> and in fact even  the answer to http://patches.openembedded.org/patch/715/ didn't reach patchwork
Feb 18 22:20:44 <khem> ericben: hmm http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-February/030187.html
Feb 18 22:20:48 <khem> this one you mean
Feb 18 22:21:31 <khem> I guess I might have turned on "dislike french" mode in pw :)
Feb 18 22:21:49 <khem> is it something new ?
Feb 18 22:22:35 <Tartarus> RP__, FYI, I got the db locked thing on 1.12.0 :(
Feb 18 22:23:16 <ericben> khem: since a few days I think
Feb 18 22:23:23 <khem> hmmm
Feb 18 22:23:26 <khem> lemme see
Feb 18 22:23:26 <ericben> my patches used to got to patchwork
Feb 18 22:24:30 <khem> hmm
Feb 18 22:28:53 <RP__> Tartarus: ok, I thought kergoth's patch was a little optimistic. Could you let him know please?
Feb 18 22:35:22 <Tartarus> Will do when he's back
Feb 18 22:39:32 <demigod2k> is having the PARALLEL_MAKE = "-j 4" in my conf/local.conf all that is necessary to get the parallelism on build?
Feb 18 22:39:49 <demigod2k> based on my machine's uptime output, it seems like bitbake is only doing one thing at a time
Feb 18 22:39:50 <Tartarus> That's half of it
Feb 18 22:39:53 <Tartarus> that will be passed to make
Feb 18 22:39:58 <Tartarus> But bitbake can also have a number of threads
Feb 18 22:40:14 <Tartarus> The key is to find the right combination of make -j N's and bitbake threads to have going
Feb 18 22:40:21 <Tartarus> (that's controlled via BB_NUMBER_THREADS)
Feb 18 22:40:54 <Jay7> set BB_NUMBER_THREADS to number of cores
Feb 18 22:40:58 <demigod2k> oh duh. I stopped reading too early, thanks. so that'll run multiple recipes in parallel?
Feb 18 22:41:19 <Jay7> I have both BB_N_T and P_M set to # of cores (6 for me)
Feb 18 22:41:53 <demigod2k> ya I just asked my IT. he said "4 but remember you're hurting everybody else if you increase that"
Feb 18 22:41:57 <demigod2k> well.... "not my problem"
Feb 18 22:42:34 <demigod2k> then the side question -- is it relatively reliable to have the BB threads >1 ? most people aren't seeing race conditions introduced?
Feb 18 22:42:48 * ant__ hides
Feb 18 22:43:19 <Jay7> demigod2k: it is reliable, at least to hunt that races down ;)
Feb 18 22:43:28 <demigod2k> dang. good enough though :)
Feb 18 22:43:42 <demigod2k> ok I'll kick that off for the weekend. tytl
Feb 18 22:43:43 <demigod2k> ttyl
Feb 18 22:44:08 * Jay7 unhide ant__
Feb 18 22:45:20 <ant__> I'm building for fun A., just to compare the races
**** ENDING LOGGING AT Sat Feb 19 02:59:57 2011