**** BEGIN LOGGING AT Wed Nov 24 02:59:58 2010
Nov 24 03:09:31 <kergoth> damnit
Nov 24 03:17:36 <CIA-109> 03Chris Larson <chris_larson@mentor.com> 07master * r720484ada0 10bitbake.git/lib/bb/cache.py: 
Nov 24 03:17:36 <CIA-109> cache: fix rrecs_pkg
Nov 24 03:17:36 <CIA-109> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Nov 24 03:23:58 * kergoth ponders
Nov 24 06:52:14 <morphis> heyho
Nov 24 07:22:21 <eFfeM_work> gm
Nov 24 07:26:04 <eFfeM_work> ka6sox didn't see your patchwork msg from half a day or so ago, no, patchwork is still not working here
Nov 24 07:26:19 <eFfeM_work> http://patchwork.openembedded.org/project/openembedded/list/ gives a page where the latest patch is fro 2010-11-19
Nov 24 07:26:40 <ka6sox> eFfeM_work, yep...
Nov 24 07:59:42 <anil> Hi , I have a new machine in u-boot .. it got registered in the open source but in the oe build it is not there shall i need to send it as patch or how can i update it in oe 
Nov 24 08:09:23 <eFfeM_work> anil add machine config (in conf/machine, preferably peek at something similar), add kernel and u-boot recipes where needed, build, test, make patch, send patch to mailing list. see also http://wiki.openembedded.net/index.php/Adding_a_new_Machine
Nov 24 08:10:33 <hrw> morning
Nov 24 08:30:59 <mckoan> good morning
Nov 24 08:50:46 <cazze> hi, i have a little problem with the /etc/init.d/dropbear sript
Nov 24 08:50:50 <cazze> *script
Nov 24 08:51:00 <ynezz> so fix it :)
Nov 24 08:51:09 <cazze> it fails on the following command: . /etc/default/dropbear
Nov 24 08:51:32 <cazze> what could be the reason?
Nov 24 08:51:40 <ericben> good morning
Nov 24 08:51:43 <ynezz> who knows from such report
Nov 24 08:51:44 <cazze> morning
Nov 24 08:51:45 <ynezz> morning
Nov 24 08:52:00 <cazze> ynezz: ask me more :-)
Nov 24 08:52:06 <cazze> no errors are given
Nov 24 08:52:15 <cazze> /etc/default/dropbear exists
Nov 24 08:52:36 <ynezz> how do you know, that it fails if there's no error? :p
Nov 24 08:52:55 <cazze> i've putted some echo in front and after irt
Nov 24 08:52:59 <cazze> *it
Nov 24 08:53:05 <ynezz> and?
Nov 24 08:53:19 <cazze> after that command, no echo anymore
Nov 24 08:53:27 <cazze> it just quits
Nov 24 08:53:48 <ynezz> and if you remove that line it works?
Nov 24 08:53:55 <cazze> yep
Nov 24 08:54:08 <ynezz> if so, than maybe there's something with busybox or with your filesystem
Nov 24 08:54:11 <atiti_mac> invalid syntax in the file?
Nov 24 08:54:22 <ynezz> if you do . /etc/default/dropbear from commandline, what happens?
Nov 24 08:55:05 <cazze> nothing
Nov 24 08:55:08 <cazze> no error
Nov 24 08:55:43 <cazze> i will try to set an env and see if it does set something
Nov 24 08:56:04 <ynezz> set -x for debug
Nov 24 08:56:14 <ynezz> put it as the first line
Nov 24 08:57:09 <cazze> no error
Nov 24 08:57:22 <ynezz> what's inside that file?
Nov 24 08:57:24 <cazze> but no env either
Nov 24 08:57:53 <cazze> as a test i've set DROPBEAR_BANNER="test"
Nov 24 08:58:40 <ynezz> if . works, the command doesn't hang, than it's ok I think
Nov 24 08:59:37 <cazze> why can't i see DROPBEAR_BANNER in env then?
Nov 24 08:59:54 <anil> thanks but my doubt here is ,already the my board was included in the open source u-boot but the source of u-boot in oe  does not contain that .Can i take the MACH_TYPE of my board as PATCH or i need to request the OE maintainers to pull it from u-boot opensource
Nov 24 09:06:36 <cazze> it does not set the envs
Nov 24 09:07:06 <eFfeM_work> anil: *the* source of u-boot in oe does not exist, if your machine is already in u-boot upstream, it is just a matter of updating a recipe (or creating a new one) for the latest upstream version.
Nov 24 09:07:28 <eFfeM_work> but in order to have a new machine in OE we also need a kernel for that machine and a conf file
Nov 24 09:08:19 <eFfeM_work> we don't do u-boot for a machine, we do OE for a machine (which includes kernel, u-boot, toolchain, etc etc)
Nov 24 09:09:41 <cazze> even source /ent/default/dropbear does not set an env
Nov 24 09:09:51 <cazze> *etc
Nov 24 09:11:46 <anil> kernel , machine.conf file , x-load and u-boot patches are ready . 
Nov 24 09:12:21 <cazze> hwohow can i check if it is a filesystem problem?
Nov 24 09:14:29 <tasslehoff> I see that different recipes does adduser in pkg_postinst. Could I do the same in ROOTFS_POSTPROCESS_COMMAND?
Nov 24 09:14:42 * tasslehoff can try
Nov 24 09:17:36 <ericben> is there anyone with admin right for the wiki here ?
Nov 24 09:17:52 <ericben> 2 guys are actually spamming the wiki in live, page after page
Nov 24 09:18:14 <ericben> users : Yjytalamago & Ejumuvo
Nov 24 09:19:01 <ericben> I've reverted there changes in about 70 pages but this takes time !:
Nov 24 09:20:34 <eFfeM_work> ericben: i suspect they use a tool, we should block them and their ip and maybe we should revert/unroll the wiki to the point before they started spamming
Nov 24 09:20:57 <eFfeM_work> who is in control of the wiki? mickey| office, gm and do you know?
Nov 24 09:26:02 <ericben> eFfeM_work: I think it's Stefen 
Nov 24 09:26:19 <ericben> in fact Steffen with 2 f
Nov 24 09:27:34 <ericben> and 20 new spam
Nov 24 09:27:39 <ericben> I give up
Nov 24 09:28:35 <cpo> anyone is using xf86-input-evtouch and got the calibration tool working? it always complains about missing freemono font
Nov 24 09:28:43 <ericben> http://www.mediawiki.org/wiki/Extension:SpamBlacklist seem an interesting extension to add to the wiki
Nov 24 09:28:44 <eFfeM_work> ka6sox you still there ?
Nov 24 09:32:22 <mckoan> I suggest to disable comments in wiki for a while
Nov 24 09:32:29 <eFfeM_work> yes
Nov 24 09:32:31 <mckoan> spam is spreading
Nov 24 09:32:36 <ericben> that's not only a comment problem
Nov 24 09:33:08 <ericben> they edit anything
Nov 24 09:33:24 <ericben> maybe a user registration validation
Nov 24 09:36:26 <ericben> thanks hrw
Nov 24 09:38:47 <ericben> hrw: can you also block Yjytalamago ?
Nov 24 09:41:07 <hrw> we need Nuke extension probably
Nov 24 09:42:40 <eFfeM_work> can we also block the ip's these spammers use ?
Nov 24 09:43:43 <hrw> ericben: for future - easiest way to undo changes is to go to page which lists all edits of abuser and open "undo" links
Nov 24 09:44:17 <hrw> ericben: and then just open each 'undo' link in new tab - fastest way
Nov 24 09:47:26 <ericben> hrw: the major problem is to remove new pages creation : does it work in that case ?
Nov 24 09:48:41 <ericben> hrw: btw, where is that page which lists all edits of a user ?
Nov 24 09:48:55 <ericben> ok found: toolbox -> usercontribution
Nov 24 09:48:56 <ericben> thanks
Nov 24 09:49:14 <hrw> ericben: http://wiki.openembedded.org/index.php/Special:Contributions/Yjytalamago
Nov 24 09:50:44 <ericben> I don't get undo links in this page, only hist & diff
Nov 24 09:51:53 <tasslehoff> I've added a pkg_postinst to my recipe. Must I do something special for that to be run?
Nov 24 09:53:42 <hrw> ericben: because his work was reverted
Nov 24 09:53:48 <hrw> ericben: go to your contribs?
Nov 24 09:54:27 <ericben> hrw: I understand but I also tested on my or your page and don't find the undo link :-)
Nov 24 09:54:55 <hrw> http://wiki.openembedded.org/index.php/Special:Contributions/Koan has them
Nov 24 09:55:14 <ericben> this may need special rights 
Nov 24 09:55:42 <soltys> mornin
Nov 24 09:56:02 <hrw> ericben: ah. I thought that you are one of admins
Nov 24 09:56:15 <ericben> hrw: no else I would have blocked the users myself :-D
Nov 24 09:57:25 <ka6sox> eFfeM_work, yes, I'm here...what can I do to help?
Nov 24 09:57:47 <hrw> ericben: admins are: cbrake Crofton|work ka6sox laibsch likewise /me mickey|office stefan zecke sledz
Nov 24 09:58:30 <ericben> hrw: good to know thanks
Nov 24 09:58:46 <hrw> http://wiki.openembedded.org/index.php?title=Special:ListUsers&group=bureaucrat for future
Nov 24 09:59:25 <ka6sox> hrw, did you fix it?
Nov 24 10:00:23 <hrw> ka6sox: I dropped user and his changes
Nov 24 10:00:50 <tasslehoff> inserting an obvious error into my pgk_postinst, the recipe still builds, so I suspect it's not run
Nov 24 10:01:04 <ka6sox> hrw, thanks, I was off doing something else. (almost 2am here)
Nov 24 10:15:56 <eFfeM_work> anyone an idea if it is (easily) possible to inject a message in the kernel log from user space ?
Nov 24 10:17:15 <Jay7> eFfeM_work: there is way to inject message to syslog
Nov 24 10:17:37 <eFfeM_work> Jay7: did you mean *no* way ?
Nov 24 10:17:44 <eFfeM_work> or *a* way
Nov 24 10:17:53 <Jay7> I'm looking :)
Nov 24 10:18:11 <Jay7> eFfeM_work: did you mean log that shown by dmesg?
Nov 24 10:18:15 <eFfeM_work> was googling for it too, but could not really find it, ofc I could do a dedicated driver
Nov 24 10:18:18 <eFfeM_work> Jay7, yes
Nov 24 10:18:43 <Jay7>  echo "123" > /dev/kmsg 
Nov 24 10:18:48 <Jay7> worksforme
Nov 24 10:18:50 <eFfeM_work> actually a simple cyclic log buffer in userspace probably could also help
Nov 24 10:20:21 <eFfeM_work> ah, cool, didn't know that works on my host system too, let's see if I can get it working on target
Nov 24 10:23:52 <eFfeM_work> Jay7: works for me on target too, thanks alot!
Nov 24 10:46:03 * Jay7 hates Linux' schedulers
Nov 24 10:48:04 <CIA-109> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r7bfcf5198d 10openembedded.git/recipes/ (4 files in 3 dirs): 
Nov 24 10:48:04 <CIA-109> shr: unify SRC_URI pointing to SHR repos on git.shr-project.org
Nov 24 10:48:04 <CIA-109> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Nov 24 10:53:13 <ericben> eFfeM_work: busybox has a log daemon which is using a cyclic buffer
Nov 24 10:53:49 <ericben> and using logger you can create log easily from scripts
Nov 24 10:53:56 <ericben> and busybox also has logger :-)
Nov 24 10:55:11 <vlrk> hello all iam trying to use prebuilt chain ..? its failing in building the binutils-cross-2.18-r13.2 
Nov 24 10:55:33 <vlrk> saying like " checking whether the C compiler works... configure: error: cannot run C compiled programs.
Nov 24 10:55:33 <vlrk> | If you meant to cross compile, use `--host'.
Nov 24 10:55:33 <vlrk> "
Nov 24 10:57:05 <eFfeM_work> ericben: ah ok, will look at that too
Nov 24 10:57:34 <cazze> is this still working?  http://www.linuxtogo.org/gowiki/Angstrom/qemu-system-arm
Nov 24 10:57:41 <eFfeM_work> actually maybe I can get away with just logging to a file without needing a cyclic buffer, i was mainly worried about file growth
Nov 24 11:00:10 <ant_work> hi eFfeM_work 
Nov 24 11:00:18 <eFfeM_work> hi ant_work
Nov 24 11:00:36 <ant_work> I'm comparing poky's autotools with ours
Nov 24 11:01:01 <eFfeM_work> good job!
Nov 24 11:01:09 <ant_work> it seems we are a bit behind wrt automake / autoconf
Nov 24 11:01:26 <ant_work> I'll bother Tartarus and khem later on ;)
Nov 24 11:01:55 <eFfeM_work> yeah, but take care to change things
Nov 24 11:02:15 <ant_work> I hope this couls solve the perl/perl-native oddity
Nov 24 11:02:39 <eFfeM_work> ah ok, would be nice
Nov 24 11:05:51 <cazze> i get a black aemu screen :-(
Nov 24 11:05:57 <cazze> *qemu
Nov 24 11:08:04 <Jay7> cazze: check console (Ctrl+Alt+3 iirc)
Nov 24 11:08:07 * ant_work throw the stone and hides the hand
Nov 24 11:08:13 <ant_work> eFfeM_work: is on the ML
Nov 24 11:08:21 <eFfeM_work> ok, will read
Nov 24 11:09:17 <cazze> Jay7: Uncompressing Linux... done, booting the kernel
Nov 24 11:09:23 <cazze> it stays there
Nov 24 11:09:39 <Jay7> hm.. 
Nov 24 11:09:54 <Jay7> cazze: do you using hosts qemu or OE's qemu-native?
Nov 24 11:10:28 <Jay7> described way should work
Nov 24 11:10:58 <Jay7> I'm not sure about -drive file=... thing
Nov 24 11:11:09 <Jay7> drive is drive image, not plain fs image..
Nov 24 11:11:11 <cazze> i'm using qemu on ubuntu
Nov 24 11:11:42 <Jay7> but this should break root mount only, not kernel
Nov 24 11:11:58 <cazze> Jay7: that's what i thought :-)
Nov 24 11:12:02 <Jay7> s/should/may/
Nov 24 11:12:17 <cazze> Jay7: but it's the kernel that hangs
Nov 24 11:12:28 <Jay7> cazze: try other machines (-M ?)
Nov 24 11:12:40 <cazze> Jay7: then i get errors :-)
Nov 24 11:13:04 <Jay7> cazze: well.. I can suggest to compile other qemu version then :)
Nov 24 11:13:14 <cazze> Jay7: grrr :-)
Nov 24 11:13:14 <Jay7> I'm doing this sometimes
Nov 24 11:14:12 <Jay7> you may just compile and use qemu-system-arm w/o installation
Nov 24 11:14:21 <Jay7> or try OE's one
Nov 24 11:14:32 <Jay7> it should be somewhere in TMPDIR
Nov 24 11:14:51 <cazze> ok, thx, i'll try that
Nov 24 11:14:55 <Jay7> but last time I tried it was compiled w/o sdl
Nov 24 11:15:18 <Jay7> so, vnc or console only
Nov 24 11:16:02 <Jay7> seems I'll compile 0.9.x for tosa emulation soon..
Nov 24 11:16:14 <Jay7> latest qemu have broken tosa emulation
Nov 24 11:16:42 <Jay7> cazze: please note me about results
Nov 24 11:17:16 <Jay7> qemuarm is one of (future) autotesting targets
Nov 24 11:20:02 <Jay7> http://tinderbox.openembedded.net/builders/Jay7-tb/
Nov 24 11:20:14 <Jay7> meta-toolchain* build results
Nov 24 11:20:22 <Jay7> starting from 2010-11-24
Nov 24 11:20:35 <Jay7> some results will follows (for ben nanonote)
Nov 24 11:23:08 <cazze> Jay7: i can't copy oe version of qemu to another machine and run it stand-alone
Nov 24 11:23:16 <cazze> Jay7: need some libs too :-)
Nov 24 11:23:46 <Jay7> I thought you are running on same host :)
Nov 24 11:23:55 <cazze> nope :-)
Nov 24 11:34:47 <cazze> basic question: what is the difference between set and env?
Nov 24 11:36:28 <cazze> if i have a variable in set but not in env, what will be the differnence for the rest of the apps?
Nov 24 11:37:02 <cazze> i reflashed my sd witht he ibase-image  but still have my problems the init.d scripts quit after sourcing something
Nov 24 11:39:46 <cazze> grrr, is working now
Nov 24 11:46:59 <CIA-109> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r6b1026a16e 10openembedded.git/recipes/gtk-webcore/midori_0.2.9.bb: 
Nov 24 11:46:59 <CIA-109> midori: add 0.2.9
Nov 24 11:46:59 <CIA-109> Signed-off-by: Koen Kooi <koen@openembedded.org>
Nov 24 11:47:10 <CIA-109> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r8636fa26b1 10openembedded.git/recipes/webkit/ (3 files in 2 dirs): 
Nov 24 11:47:10 <CIA-109> webkit-gtk: bump SRCREV
Nov 24 11:47:10 <CIA-109> Signed-off-by: Koen Kooi <koen@openembedded.org>
Nov 24 11:52:12 <cazze> my base-image is working, my console-base-image not :-(
Nov 24 11:52:24 <cazze> will bitbake the console-base-image again :(
Nov 24 13:24:07 <broonie> hrw: "next reparse took only 2 minutes" - *only*? :)
Nov 24 13:26:48 <hrw> broonie: compared to 3 it is only
Nov 24 13:32:32 <broonie> hrw: Which was itself "not so bad" :)
Nov 24 13:32:55 <broonie> If you're measuring the base startup time for your build system in minutes there's a bit of an issue.
Nov 24 13:33:21 <hrw> broonie: ;D
Nov 24 13:57:55 <kergoth_> morning
Nov 24 13:57:59 <tasslehoff> I want my passwords in /etc/shadow instead of /etc/passwd. Is this just a matter of installing shadow on my system?
Nov 24 14:00:32 <foerster> gm
Nov 24 14:11:18 <fred-eric> Linux Radio : broadcasting the Linux kernel! - http://www.linux.fm
Nov 24 14:11:21 <fred-eric> cheers :D
Nov 24 14:17:37 <mckoan> fred-eric: gosh! delirium
Nov 24 14:17:51 <kergoth_> ooh, i like some of esben's approaches in his oelite
Nov 24 14:17:58 <kergoth_> there's an actual recipe class! gasp!
Nov 24 14:18:21 * kergoth_ 's been wanting that for ages now, just not particularly good at slowly refactoring to get places
Nov 24 14:18:25 <florian> fred-eric: heh
Nov 24 14:19:25 <ericben> fred-eric was my neighbour when I was younger world is small :-D
Nov 24 14:24:44 <foerster> kergoth_: I'm trying to cook up a multiprocessing based ui/server setup ;)
Nov 24 14:24:52 <kergoth_> nice
Nov 24 14:25:33 <kergoth_> i bet itd be nice to just hand off a Queue or pair of queues for the communication, screw all the direct pipe manipulations, xml/rpc sockets, ... *ponders*
Nov 24 14:25:40 <foerster> that's what i'm doing
Nov 24 14:26:08 <foerster> bin/bitbake creates some queues, hands em to server and ui for communications
Nov 24 14:26:15 <foerster> simple and clean
Nov 24 14:27:00 <kergoth_> nice
Nov 24 14:27:21 <kergoth_> oh, and is it just me, or is calling the UI main loop "init" just fucking annoying?
Nov 24 14:27:27 <kergoth_> sorry, that's not init, that's MAIN
Nov 24 14:27:29 <kergoth_> </rant>
Nov 24 14:27:32 <foerster> lol
Nov 24 14:27:47 <foerster> yea, it'd be easier to understand if a number of things were named differently
Nov 24 14:28:02 <foerster> and there are tons of circular references which drives me nuts
Nov 24 14:28:11 <foerster> server needs cooker, cooker needs server? wtf
Nov 24 14:28:15 <kergoth_> ugh, yes
Nov 24 14:28:18 <kergoth_> that's all over the place
Nov 24 14:28:30 <foerster> yea, I'm yanking some of that dependency right now
Nov 24 14:28:35 <kergoth_> cooker/runqueue/taskdata/cache are all twisted together
Nov 24 14:29:02 <foerster> some major refactoring would be good, but that's less exciting than trying to multiprocess the whole thing
Nov 24 14:29:07 * kergoth_ nods
Nov 24 14:29:24 <foerster> ok, off to the grind.  Let's see if I can get this semi-functional.
Nov 24 14:29:27 <kergoth_> sounds like what you're doing is a great step in multiple ways
Nov 24 14:29:31 <kergoth_> cool, have fun
Nov 24 14:30:13 <kergoth_>            data = self.parse_recipe(bbrecipe)
Nov 24 14:30:13 <kergoth_>             for extend in data:
Nov 24 14:30:13 <kergoth_>                 recipe = OEliteRecipe(bbrecipe, extend, data[extend], self.db)
Nov 24 14:30:13 <kergoth_>                 self.cookbook[recipe.id] = recipe
Nov 24 14:30:20 <kergoth_> look! a recipe object!
Nov 24 14:30:25 * kergoth_ oohs and aahs
Nov 24 14:30:29 * kergoth_ chuckles
Nov 24 14:30:31 <pb_> cute
Nov 24 14:36:35 <CIA-109> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r1908930b2c 10openembedded.git/recipes/openmoko-3rdparty/podboy_svn.bb: 
Nov 24 14:36:35 <CIA-109> podboy: bump SRCREV to 1.7.2 release compatible with current EFL_SRCREV
Nov 24 14:36:35 <CIA-109> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Nov 24 14:37:49 <kergoth_> meh
Nov 24 14:37:50 <kergoth_> sleepy
Nov 24 14:46:24 <kergoth_> downside to esben's code, way too many methods on the classes that do exist, the metadata hashing isn't intelligent, but is integrated, which is more than i can say for bitbake
Nov 24 14:47:28 <kergoth_> it's also a drastic step, he went for a rewrite rather than an incremental evolution
Nov 24 14:48:37 <pb_> I think a rewrite might well be the right way to proceed in that kind of situation.  I'm not sure I'd view that as a downside.
Nov 24 14:49:11 <kergoth_> true, it just seems like any mention of a rewrite of anything in the oe community results in massive backlash
Nov 24 14:49:51 <pb_> s/a rewrite of//
Nov 24 14:49:55 <kergoth_> hehe
Nov 24 14:49:57 <kergoth_> fair point
Nov 24 14:51:08 <kergoth_> the danger with going with a fresh start is changing how the build behaves.  its less of an issue for him, since he replaced oe with his own thing as well, but for us, we *need* some serious unit tests in place before we consider rewriting things, or just rewrite and cross our fingers and use OE as the test
Nov 24 14:51:29 <pb_> personally I would be entirely relaxed about a rewrite of bitbake so long as it remained (mostly) compatible with the existing recipe format.  what I am not enthusiastic about, and what you might be thinking of, is the suggestion that comes up occasionally to design a whole new metadata format and effectively start over from scratch with everything.
Nov 24 14:52:02 <pb_> right, yeah, I think any putative rewrite of bitbake ought to come with a proper testsuite.
Nov 24 14:52:04 <kergoth_> thats a nice someday item, but i don't see that happening anytime soon -- if it does, we'd need to retain compatibility with the current and add the new
Nov 24 14:52:13 <pb_> agreed
Nov 24 14:52:20 <kergoth_> and ideally be able to programmatically convert
Nov 24 14:52:52 * pb_ looks quizzically at pb__
Nov 24 14:53:00 <pb_> I guess the builders must have unplugged my internet connection again
Nov 24 14:53:32 <pb_> either that or my dog/daughter has destroyed my laptop, equally plausible I suppose
Nov 24 14:54:22 <kergoth_> one thing i was thinking about the other day is, bb.parse tried to be flexible for different formats, but the whole notion of the recipe being key=value metadata with key=value flags is a part of the file format.  how the data is structured in the file shouldn't be exposed if we truly want that sort of abstraction for different formats
Nov 24 14:54:46 <kergoth_> better to say hey recipe, give me your version.. or run that task
Nov 24 15:06:24 <kergoth_> hmmm
Nov 24 15:11:13 <cazze> is there something like "use flags" for recipes? Like in gentoo portage?
Nov 24 15:12:45 <kergoth_> not exactly.  we have DISTRO_FEATURES and MACHINE_FEATURES which are space separated lists of functionality, which are used in some recipes (e.g. ipv6 in DISTRO_FEATURES controls --enable-ipv6 or whatever in some recipes)
Nov 24 15:12:49 <kergoth_> but its less defined
Nov 24 15:16:29 <cazze> could you depending on a MACHINE_FEATURE change the RDEPEND?
Nov 24 15:17:00 <cazze> the RDEPEND in a recipe i mean
Nov 24 15:17:19 <kergoth_> yep
Nov 24 15:17:32 <kergoth_> you'd have to use an inline snippet of python to do it
Nov 24 15:17:42 <cazze> exmple recipe?
Nov 24 15:17:58 <kergoth_> e.g. DEPENDS += "${@base_contains('${MACHINE_FEATURES}', 'some_feature', 'the dep i want', '')}"
Nov 24 15:18:01 <kergoth_> or what have you
Nov 24 15:18:10 <kergoth_> see task-base in recipes/tasks/ for examples
Nov 24 15:18:17 <cazze> ok, thx
Nov 24 15:18:21 <kergoth_> np
Nov 24 15:18:36 <kergoth_> if you have ideas on how to improve / define our features stuff, i'd be interested to hear it
Nov 24 15:18:50 <kergoth_> for example, right now there's no good way for the user to override what the distro/machine want, feature wise
Nov 24 15:18:52 <cazze> portage :-)
Nov 24 15:20:42 <cazze> with machines as profiles
Nov 24 15:20:59 <vlrk> haveing an issue with oe in getting openjdk-6 error is here http://pastebin.ca/2000996 can any body help me in resolving this ?
Nov 24 15:54:54 <CIA-109> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r20117ec6ae 10openembedded.git/recipes/webkit/webkit-efl_svn.bb: 
Nov 24 15:54:54 <CIA-109> webkit-efl: sync SRCREV with webkit-gtk
Nov 24 15:54:54 <CIA-109> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Nov 24 15:55:34 <ant_work> kergoth_: any sql-based runqueue to test ? 
Nov 24 15:56:35 <darkstar62> kergoth_: quick question...in your working with embedded devices, have you ever seen a situation where angstrom randomly segfaults at various points during the bootup?  I think it's kernel related, but can't figure out where
Nov 24 15:57:21 <ant_work> darkstar62: I've even seen worst scenarios...
Nov 24 15:57:46 <kergoth_> ant_work: not that i know of, no
Nov 24 15:57:56 <ant_work> any soon?
Nov 24 15:58:06 <kergoth_> i'm not sure what makes you think i'm even working on that
Nov 24 15:58:13 <ant_work> I perhaps misread your answer to esben
Nov 24 15:58:18 <kergoth_> esben is working on something like that, but it's a rewrite, it has nothing to do with bitbake
Nov 24 15:58:32 <kergoth_> its an interesting approach, yes, but that doesnt' mean its suddenly on my todo list :P
Nov 24 15:58:50 <ant_work> yesterday you were talking with Jay7 about runqueue
Nov 24 15:59:26 <ant_work> I though ou were cooking something
Nov 24 16:01:16 <ant_work> well, with the parallel parsing you've done more than enough ;)
Nov 24 16:01:23 <ant_work> breathe now
Nov 24 16:01:35 <kergoth_> hehe
Nov 24 16:01:48 <kergoth_> we'll get there, one step at a time
Nov 24 16:07:22 <foerster> kergoth_: success (at least partially so far!)
Nov 24 16:07:40 <foerster> server is in new process, sending commands and events back and forth between server/ui
Nov 24 16:07:44 <foerster> parsing works
Nov 24 16:07:46 <kergoth_> nice
Nov 24 16:08:21 <foerster> need to figure out/fix shutdown/joining/etc
Nov 24 16:08:33 * kergoth_ nods
Nov 24 16:09:34 <foerster> the changes were surprisingly not too terrible
Nov 24 16:11:58 <kergoth_> nice
Nov 24 16:12:16 * kergoth_ 's experimenting with distutils2 to see how its coming along
Nov 24 16:36:55 <darkstar62> did something change in the input layer in a recent kernel?  ts_calibrate isn't working with my touchscreen anymore
Nov 24 16:37:09 <darkstar62> "not a touchscreen I understand"
Nov 24 16:37:34 <darkstar62> (I'm using an older one too, if that helps)
Nov 24 16:38:04 <darkstar62> tslib 1.0-r20.1
Nov 24 16:38:29 <anarsoul> darkstar62: yep
Nov 24 16:39:03 <anarsoul> abi version changed in 2.6.37, you should recompile tslib with 2.6.37 linux headers
Nov 24 16:39:12 <darkstar62> ah, ok
Nov 24 16:39:42 <CIA-109> 03Khem Raj <raj.khem@gmail.com> 07master * r76a34ad644 10openembedded.git/conf/distro/include/sane-toolchain.inc: 
Nov 24 16:39:42 <CIA-109> sane-toolchain.inc: Rename the absration vars for uclibc/eglibc/glibc versions
Nov 24 16:39:42 <CIA-109> * There was a mismatch between sane-toolchain.inc and what
Nov 24 16:39:42 <CIA-109> sane-toolchain-uclibc expects. It did not pick right uclibc version
Nov 24 16:39:42 <CIA-109> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Nov 24 16:39:42 <darkstar62> that would make sense, i'm using a 2.6.37 kernel
Nov 24 16:40:31 <anarsoul> or you can use this patch: http://dpaste.org/LFmQ/
Nov 24 16:40:32 <anarsoul> :)
Nov 24 16:40:55 <darkstar62> ah, that might be easier for testing :)
Nov 24 16:41:53 <Tartarus> khem: I wonder if that's the root some some false fails (based on exit status rather than last line of bitbake output)
Nov 24 16:42:17 <Tartarus> khem: is qemu 0.13.0 D_P = -1?
Nov 24 16:45:31 <darkstar62> anarsoul: that worked, thanks
Nov 24 16:45:38 <chouimat|busy> morning
Nov 24 16:45:39 <darkstar62> now to update my build...
Nov 24 16:45:44 <anarsoul> darkstar62: you're welcome :)
Nov 24 16:52:27 <Tartarus> darkstar62: re seg faults, what platform?
Nov 24 16:56:35 <Tartarus> I wonder if making gcc* rm -rf files that it's intentionally not shipping would speed up the build
Nov 24 16:56:43 <Tartarus> the hundreds of "not shipping..." messages take forever to print
Nov 24 16:57:15 <kergoth_> probably
Nov 24 16:59:25 <pb_> could be, though it's a bit sad that printing those messages causes such a slowdown
Nov 24 16:59:27 <ant_work> Tartarus: I tried to compare Poky and OE autoconfig and automake...ours seems more recent
Nov 24 17:00:59 <Tartarus> ant_work: Probably, I don't think poky has done the libtool 2.4 dance yet
Nov 24 17:02:18 <ant_work> wro OE, fwiw I've seen  autoconf-dont-execute-perl.patch was in autoconf-2.6.1 and is not in 2.6.5
Nov 24 17:02:48 <ant_work> (still trying to put all together)
Nov 24 17:02:51 <Tartarus> k
Nov 24 17:02:57 <Tartarus> It's all a big rats-nest :(  good luck!
Nov 24 17:03:12 <ant_work> definitely not my beer :/
Nov 24 17:03:45 <ant_work> but being I'm the only one with perl w/out threads (Gentoo)..I'll try to solve at least my issue ;)
Nov 24 17:26:53 <GNUtoo|laptop> hi, I've a strange thing
Nov 24 17:27:09 <GNUtoo|laptop> I tried to make a bluetooth 4.80 recipe
Nov 24 17:27:12 <GNUtoo|laptop> *bluez
Nov 24 17:27:21 <GNUtoo|laptop> so bluez4_4.80.bb
Nov 24 17:28:05 <GNUtoo|laptop> and it doesn't want to build it
Nov 24 17:28:12 <GNUtoo|laptop> I mean it builds another version
Nov 24 17:28:28 <GNUtoo|laptop> the 4.59
Nov 24 17:28:32 <GNUtoo|laptop> I grepped in conf
Nov 24 17:28:45 <GNUtoo|laptop> for "4\.59"
Nov 24 17:28:51 <GNUtoo|laptop> no results
Nov 24 17:28:58 <GNUtoo|laptop> and no interesting stuff for bluez
Nov 24 17:29:10 <GNUtoo|laptop> and I grepped for DEFAULT_PREFERENCE
Nov 24 17:29:13 <GNUtoo|laptop> in the .inc
Nov 24 17:29:18 <GNUtoo|laptop> in bluez dir
Nov 24 17:29:20 <GNUtoo|laptop> no result
Nov 24 17:29:30 <GNUtoo|laptop> of course I don't have DEFAULT_PREFERENCE in my recipe
Nov 24 17:29:37 <GNUtoo|laptop> machine: nokia900
Nov 24 17:29:43 <GNUtoo|laptop> distro: SHR
Nov 24 17:30:05 <GNUtoo|laptop> I'll try to put DEFAULT_PREFERENCE="1"
Nov 24 17:30:17 <GNUtoo|laptop> but I really wonder why it doesn't pin the version
Nov 24 17:30:23 <GNUtoo|laptop> as it's the lastest one
Nov 24 18:17:39 <foerster> kergoth_: ping
Nov 24 18:18:41 <eFfeM> re
Nov 24 18:25:53 <khem> no traffic on roads today
Nov 24 18:26:06 <khem> I wish everyday would be a thanksgiving day
Nov 24 18:28:17 <rphillips> is there a way to prevent python in OE to not pull in X?
Nov 24 18:29:05 <khem> rphillips: you have to dump the dep graphs with bitbake -g python
Nov 24 18:29:18 <khem> then trace the dep on X
Nov 24 18:29:35 <khem> and remove it, probably some package has this dep added wrongly
Nov 24 18:29:45 <rphillips> i'm pretty sure its a tcl/tk dependency
Nov 24 18:29:54 <khem> ok
Nov 24 18:30:13 <khem> we might have to see if we can divide the dep into X and non X parts
Nov 24 18:30:20 <khem> may be two different recipes
Nov 24 18:30:34 <rphillips> +1
Nov 24 18:31:09 <khem> but I encourage you to get to bottom of it thru bitbake -g and then lets think about the solution
Nov 24 18:31:52 <rphillips> will do
Nov 24 18:41:45 <cazze> as with h2200 we i'm stick with 2.6.21 kernel, and there are no 2.6.21 headers in OE, should it be better to stick with 2.6.20 or 2.6.22?
Nov 24 18:41:52 <cazze> *stuck
Nov 24 18:46:11 <khem> cazze: older is better
Nov 24 18:46:19 <cazze> ok
Nov 24 18:46:26 <khem> cazze: in general it should not matter
Nov 24 18:46:48 <cazze> even i i have the 2.6.37 headers for a 2.6.21 kernel?
Nov 24 18:46:49 <khem> for glibc because glibc only caters to minimum version you pass to it
Nov 24 18:46:57 <khem> yes
Nov 24 18:47:00 <cazze> ok
Nov 24 18:47:34 <cazze> i have a weird problem. my base-image is ok, but in my console-base-image, i can not source things in env :-(
Nov 24 18:48:42 <cazze> will have to look at all the different packages that makes the difference between the 2 images.
Nov 24 18:48:54 <cazze> is there another intermediate one you know of?
Nov 24 18:53:45 <khem> cazze: rephrase your question
Nov 24 18:56:10 <cazze> i have a base-image that is ok, and a console-base-image that is not
Nov 24 18:56:45 <cazze> is there an image you know between the 2 (number of recipes being used)?
Nov 24 18:57:30 <cazze> base-image < ??? < console-base-image
Nov 24 18:58:09 <khem> cazze: whats wrong with console-base-image
Nov 24 18:58:15 <khem> and what do u really need
Nov 24 18:58:26 <cazze> i can't source or . stuff to env
Nov 24 18:59:42 <khem> on target ?
Nov 24 18:59:46 <khem> when you boot
Nov 24 19:00:01 <cazze> what i really need is find the problem :-) but i thought that if base-image was ok, and console-base-image not, the problem had to be in the packages that are different between the 2 images
Nov 24 19:00:08 <cazze> target h2200
Nov 24 19:00:18 <cazze> boot is ok for 2 images
Nov 24 19:00:23 <khem> sorry I still dont get you problem
Nov 24 19:00:27 <khem> I will give up
Nov 24 19:00:58 <cazze> but for example /etc/init.d/dropbear fails because . /etc/default/dropbear is used, and the scripts quits without an error
Nov 24 19:01:20 <cazze> héhé khem, thx for trying to understand it
Nov 24 19:01:48 <cazze> to set env variables, you source stuff? ok?
Nov 24 19:02:11 <cazze> or . stuff
Nov 24 19:02:29 <cazze> well, that is not possible in my console-base-image
Nov 24 19:02:40 <cazze> and it is possible in my base-image
Nov 24 19:03:42 <cazze> so if stuff is sources in a script, it dies without an error, and thing go wrong, like starting up dropbear for example
Nov 24 19:03:49 <cazze> *sourced
Nov 24 19:16:47 <foerster> kergoth: https://github.com/foerster/bitbake/commits/separate-ui-and-server
Nov 24 19:17:02 <foerster> have some issues with ctrl-c during parsing, but other than that, working well.
Nov 24 19:19:07 <foerster> kergoth: heres a better view: https://github.com/foerster/bitbake/compare/parallel-parsing...separate-ui-and-server
Nov 24 19:20:38 <jcarter> anoncvs.handhelds.org seems to be down; Is there an alternate value for HANDHELDS_CVS that would allow me to continue with a build?
Nov 24 19:28:12 <khem> jcarter: for now nothing 
Nov 24 19:28:23 <khem> we will have some solution soon
Nov 24 19:28:59 <khem> cazze: make sure that you have same shell in both images 
Nov 24 19:29:05 <jcarter> khem:  Thanks;  Just wanted to make sure I wasn't going crazy;
Nov 24 19:29:20 <khem> jcarter: search mailing lists
Nov 24 19:29:25 <khem> we have some alternatives
Nov 24 19:29:35 <khem> with PREMIRRORS and local mirrors etc.
Nov 24 19:29:45 <khem> using ownmirror class
Nov 24 19:30:19 <blindvt_> hi
Nov 24 19:30:58 <khem> blindvt: heyo
Nov 24 19:31:42 <jcarter> khem: did that - haven't found a pointer to a server that has a mirror of their cvs repository though;
Nov 24 19:32:10 <khem> jcarter: we have them 
Nov 24 19:32:18 <khem> on sources.openembedded.org
Nov 24 19:32:29 <khem> it should be there in one of the messages on ml
Nov 24 19:32:43 <jcarter> khem:  OK thanks.  I'll find it.
Nov 24 19:33:00 <khem> blindvt: do u have time to debug why ppc fails to boot on uclibc/nptl git
Nov 24 19:33:12 <khem> blindvt: it booted ok in the past
Nov 24 19:33:15 <khem> but not anymore
Nov 24 19:35:44 <blindvt> khem, don't have time ATM, sorry. Not sure where my ppc qemu-image is, and i'd have to fix LFS handling in oe recipes to get me a new one ;)
Nov 24 19:36:39 <blindvt> khem, i've just added make {,install_}startfiles, perhaps somebody finds it useful (think flat vs non-flat, for example)
Nov 24 19:37:28 <blindvt> let's fix some other bug from the bug-collector today
Nov 24 19:37:31 * blindvt &
Nov 24 19:43:51 <khem> blindvt: in OE MACHINE=qemuppc DISTRO=minimal-uclibc bitbake minimal-image 
Nov 24 19:44:04 <khem> and there you have it after couple of hrs not so difficult
Nov 24 19:44:40 <khem> blindvt: yes make startfiles is very important for toolchain bootstrap
Nov 24 19:44:40 <blindvt> khem, yea but i don't do minimal, just micro and that without LFS and locale
Nov 24 19:44:45 <khem> I will be the first one to use it
Nov 24 19:44:59 <khem> blindvt: ok micro-uclibc is fine too
Nov 24 19:45:57 <khem> ka6sox: around ?
Nov 24 19:46:07 <ka6sox> square
Nov 24 19:46:11 <khem> heh
Nov 24 19:46:23 <khem> I wanted to tell you that garnet has some window if you need
Nov 24 19:46:29 <ka6sox> okay thanks
Nov 24 19:46:33 <ka6sox> let me work it now.
Nov 24 19:46:37 <khem> i plan to pound it for another 3-4 days non stop
Nov 24 19:47:00 <ka6sox> okay give me about 15minutes to add this other interface
Nov 24 19:47:00 <blindvt> khem, it's not, it needlessly pulls in quilt->util-linux and that breaks horrible on !largefile. I've fixed that properly in my virtualize branch (for coreutils and other packages being replaced by busybox) and IIRC i also sent in patches to start to fix !LFS
Nov 24 19:48:23 <blindvt> khem, http://patchwork.openembedded.org/patch/2569/
Nov 24 19:48:26 <blindvt> khem, http://patchwork.openembedded.org/patch/2565/
Nov 24 19:48:31 <blindvt> khem, for example.
Nov 24 19:48:32 <khem> blindvt: yeah disabling lfs is kind of broken
Nov 24 19:48:34 * blindvt shrugs
Nov 24 19:49:02 <eFfeM> khem, I feel release needs e4721e70afa802ff301fc0ac511fcea26561c173 as the pathname is not correct (and 3ec3c40e42ec7a9a2869e363d79b67cbc5ed71ad is probably also good to add)
Nov 24 19:49:02 <blindvt> if you don't want it then i can't help it
Nov 24 19:49:16 <kergoth> foerster: cool, looks like a definite improvement to me, though it might be worth trying to avoid the need for the ServerCommunicator
Nov 24 19:50:19 <khem> eFfeM: ok
Nov 24 19:50:37 * kergoth ponders
Nov 24 19:50:39 <khem> eFfeM: seems fine, will you chery-pick then
Nov 24 19:50:51 <khem> blindvt: both those patches make sense to me
Nov 24 19:51:07 <khem> blindvt: but some distros may not be using largefile distro feature
Nov 24 19:51:10 <khem> have to make sure
Nov 24 19:51:55 <eFfeM> khem, hm I'm not too good with git, but can give it a try
Nov 24 19:52:07 <khem> eFfeM: no worries let me pull them in
Nov 24 19:52:27 <eFfeM> better (had to wait until my build completed anyway)
Nov 24 19:52:28 <khem> eFfeM: arent you testing release branch ? I did not see your updates on the table
Nov 24 19:52:31 <blindvt> khem, if they want largefile then they have to enable it. I'd guess that micro doesn't want it, i'd default minimal to !LFS and the rest to on. I think everybody can turn it on in their local.conf (or perhaps turn it off, don't remember offhand)
Nov 24 19:52:33 <foerster> kergoth: that's just a wrapper because we need to send and receive
Nov 24 19:52:44 <foerster> plugging that in let me not alter knotty's runCommand calls
Nov 24 19:52:57 <khem> blindvt: it should be on by default I guess
Nov 24 19:53:05 <eFfeM> khem, had some issues with missing files, I can try to set up a test for it 
Nov 24 19:53:08 <khem> as that has been the case. We added the knob to disable it
Nov 24 19:53:09 <blindvt> khem, not for micro
Nov 24 19:53:40 <khem> I mean before largefile even existed as a distro feature
Nov 24 19:53:50 <khem> lfs support was deemed enabled
Nov 24 19:53:58 <khem> so we have to keep that behavior
Nov 24 19:54:16 <blindvt> khem, i don't want locale nor LFS nor X11 in default micro, that's just stupid
Nov 24 19:54:19 <rphillips> why would autoreconf error with unrecognized option --exclude=autopoint?
Nov 24 19:54:27 <khem> blindvt: all fine with me
Nov 24 19:54:54 <khem> rphillips: doesnt the message indicate the reason ?
Nov 24 19:55:26 <eFfeM> khem tested_2010-11-12 branch ?
Nov 24 19:55:44 <khem> eFfeM: no read my email about release branch 
Nov 24 19:56:08 <khem> we are testing release branch until we release as noted by cbrake
Nov 24 19:56:09 <eFfeM> guess i missed that one
Nov 24 19:56:11 <rphillips> khem: yes. I do not know where it is coming from though
Nov 24 19:56:13 <khem> in one of his message
Nov 24 19:56:46 <eFfeM> there is no tag for it ?
Nov 24 19:57:28 <khem> eFfeM: there is a branch
Nov 24 19:57:44 <khem> eFfeM: if you read me email that has all info you need to set it up
Nov 24 19:59:08 <eFfeM> hm, yeah, but testing against   release-2010.12 seems like testing a moving target ...
Nov 24 19:59:21 <khem> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-November/026975.html
Nov 24 19:59:35 <khem> eFfeM: yes its a slow moving target
Nov 24 19:59:48 <khem> we have to do whats called continuous testing 
Nov 24 19:59:51 <khem> until release
Nov 24 20:00:07 <khem> we cherry pick patches from master what we need for it to work
Nov 24 20:00:09 <khem> and not all
Nov 24 20:00:20 <khem> so yes its a moving target 
Nov 24 20:00:28 <khem> but moving towards stability
Nov 24 20:00:52 <khem> so always test the tip of release branch
Nov 24 20:01:07 <khem> and once you are done git pull --rebase and redo it again
Nov 24 20:01:18 <khem> so we can nail down the issues 
Nov 24 20:01:23 <khem> and fix them for release
Nov 24 20:01:38 <eFfeM> well I've kicked off a build
Nov 24 20:01:45 <khem> from release ?
Nov 24 20:02:15 <eFfeM> yes
Nov 24 20:02:18 <khem> good 
Nov 24 20:02:26 * khem hands an eBeer to eFfeM 
Nov 24 20:02:30 <eFfeM> on our autobuilder
Nov 24 20:02:32 <eFfeM> :-)
Nov 24 20:02:58 <khem> eFfeM: more you test better it will be
Nov 24 20:03:15 <eFfeM> guess it would be nice if the testing page would contain what rev is tested
Nov 24 20:03:24 <eFfeM> khem, might be able to do some more over the weekend
Nov 24 20:03:24 <khem> eFfeM: if you can test more combos then usually what you are interested in that would be helpful too
Nov 24 20:03:33 <khem> eFfeM: fantastic
Nov 24 20:04:08 <eFfeM> yes, as I wrote on the list, I might try more images 
Nov 24 20:04:30 <khem> blindvt: I think I will consider those patches from you 
Nov 24 20:05:01 <khem> blindvt: but need to make sure that they do not kick the existing distros
Nov 24 20:05:10 <eFfeM> guess these 6 targets will be done by tomorrow morning
Nov 24 20:05:37 * khem sees that ynezz has gone silent too in terms for testing
Nov 24 20:06:32 <ericben> khem: yesterday's release fixed most of the problems I had the day before. Micro is still compiling but I expect it to work maybe except meta-toolchain
Nov 24 20:06:34 <khem> and so have Stefan Stedz
Nov 24 20:06:48 <khem> ericben: cool
Nov 24 20:06:59 <ericben> khem: ynezz is actually building : http://tinderbox.openembedded.net/builders/ynezz%20%28testing-2010.12%29/
Nov 24 20:07:00 <khem> ericben: now I will go into booting mode for qemus
Nov 24 20:07:08 <khem> ericben: hmm nice 
Nov 24 20:07:56 <ericben> khem: I can't test as I don't have the machines I build for. But I'll test release against my machines which are in overlay
Nov 24 20:08:45 <khem> ericben: sure thats fine
Nov 24 20:09:22 <khem> ericben: btw. I am planning to have such an image on my efika that I could play internet videos like youtube netflix etc. on it
Nov 24 20:09:30 <ka6sox> khem, go ahead and beat on it...I'm done
Nov 24 20:09:40 <khem> ka6sox: cool.
Nov 24 20:09:43 <ericben> I chose machines with the same architecture so the test is in sync with the builds (except for the kernel)
Nov 24 20:09:46 * khem searches for the hammer
Nov 24 20:10:00 <khem> ericben:yeah thats sensible
Nov 24 20:10:02 <eFfeM> khem, btw I am not too happy with pinning qt 4.7 in minimal, it breaks the mythtv 0.23 build: | eventing.h:236:27: error: call of overloaded 'QString(int)' is ambiguous
Nov 24 20:10:04 <ericben> khem: so you will have to use all the extra libs from fsl to get the codecs running
Nov 24 20:10:35 <khem> ericben: I was thinking if someone already has such an image 
Nov 24 20:10:41 <khem> then I could reuse
Nov 24 20:10:49 <khem> eFfeM: hmmm
Nov 24 20:10:51 <ericben> I've packaged some for the iMX27 and will do for iMX51 when I have time
Nov 24 20:11:03 <ericben> they use gstreamer 
Nov 24 20:11:13 <khem> ericben: cool. if you do lemme know
Nov 24 20:11:24 <ericben> maybe by begining of 2011 (I hope so)
Nov 24 20:11:35 <khem> ericben: I am occupied with release these days but I would play with it afterwards
Nov 24 20:11:39 <khem> k
Nov 24 20:11:46 <khem> eFfeM: I wonder why that happens
Nov 24 20:12:04 <khem> eFfeM: does mythtv need older qt
Nov 24 20:12:08 <khem> or can we patch it 
Nov 24 20:12:19 <ericben> khem: you may need to update to the latest fsl's kernel if efika's one is not already at this level
Nov 24 20:12:53 <eFfeM> khem, will try to move to 0.24
Nov 24 20:13:19 <eFfeM> jannau did some work on this (jannau any progress/followup/?)
Nov 24 20:13:49 <eFfeM> btw on the latest testing branch I got during the build (minimal/console-image):
Nov 24 20:13:51 <khem> eFfeM: here we go http://lists.rpmfusion.org/pipermail/rpmfusion-users/2010-November/000787.html
Nov 24 20:14:08 <eFfeM> ERROR: Multiple .bb files are due to be built which each provide bluez-libs (/home/hudson/jobs/OE_test/workspace/openembedded/recipes/bluez/bluez4_4.42.bb /home/hudson/jobs/OE_test/workspace/openembedded/recipes/bluez/bluez-libs_3.36.bb). 
Nov 24 20:14:13 <khem> ericben: I think I am at 2.6.31
Nov 24 20:14:33 <khem> ericben: OE/bitbake has problems fetching from gitorious
Nov 24 20:14:36 <khem> I dont know why
Nov 24 20:14:39 <eFfeM> khem, yeah already read that thread but there is no fix in it
Nov 24 20:14:53 <khem> so I could not use the git recipe for fsl kernel
Nov 24 20:14:59 <khem> on efikamx
Nov 24 20:15:13 <khem> same problem happens with opie git recipes 
Nov 24 20:15:30 <khem> only common point is that both git repos are hosted on gitorious
Nov 24 20:15:45 <ericben> khem: khem seems they have switched to 2.6.35 : http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=shortlog;h=refs/heads/imx_2.6.35_10.10.01
Nov 24 20:15:47 <khem> same command that bitbake uses if used on commandline manually clone the repo just fine
Nov 24 20:16:11 <khem> ericben: oh I use the kernel from efikamx manufecturer
Nov 24 20:16:46 <eFfeM> khem might see a patch for the qt issue
Nov 24 20:17:45 <khem> eFfeM: sure 
Nov 24 20:18:17 <khem> eFfeM: I could boot qt4e-demo-image btw. on this device
Nov 24 20:18:37 <khem> and demos ran fine and qt looked gorgeous thru my HD projector on the wall
Nov 24 20:19:38 <ericben> yes I always using this image to demonstrate qt and the demos are cool to show the power behind this lib
Nov 24 20:19:39 <cazze> hciattach is not done automagicaly. where should i put it if i want it attached at boot?
Nov 24 20:20:37 <eFfeM> khem on the efika ?
Nov 24 20:21:35 <khem> eFfeM: yes efikamx smarttop
Nov 24 20:22:02 <khem> ericben: not all demos work though right ?
Nov 24 20:22:20 <khem> ericben: I forgot which ones but I can give you a list if you are interested 
Nov 24 20:22:37 <ericben> khem: most of them work
Nov 24 20:22:40 <khem> they were missing underlying libs
Nov 24 20:22:49 <khem> all we need to do is add those packages to the image
Nov 24 20:22:55 <khem> yeah
Nov 24 20:23:35 <eFfeM> khem, cool
Nov 24 20:23:57 <ericben> khem: ah ok I'll check this, if you have the list feel free to send it to me
Nov 24 20:24:12 <ericben> btw I 'll send qt4.7.1 's recipes in a few minutes
Nov 24 20:24:49 <ericben> it's compile tested for the moment
Nov 24 20:26:10 <khem> ericben: ok replace the 4.7.0 with it
Nov 24 20:26:43 <ericben> khem: this needs some testing before
Nov 24 20:26:48 <khem> ericben: sure
Nov 24 20:27:00 <khem> We should try to minimize similar recipes 
Nov 24 20:27:00 <ericben> especially the x11 and x11-gles parts that I can't test
Nov 24 20:27:11 <khem> hmmm I can do that 
Nov 24 20:27:19 <khem> put an image together
Nov 24 20:27:22 <khem> with x11
Nov 24 20:27:23 <ericben> khem: I agree. Moreover 4.7.0 is pinned by angstrom
Nov 24 20:27:39 <khem> we can alsways poke distro maintainers with a stick
Nov 24 20:27:40 <khem> :)
Nov 24 20:27:47 <ericben> and laos minimal & shr
Nov 24 20:28:01 <ericben> yes but first let's make sure the new one runs fine :-)
Nov 24 20:28:24 <khem> sure thing
Nov 24 20:28:49 <ka6sox> at one time didn't zecke have a sourcemirror that was separate from anything @ openembedded.org?
Nov 24 20:30:58 <ericben> ka6sox: http://gitorious.org/~zecke
Nov 24 20:31:02 <khem> eFfeM: btw mythtv ends up with an QA error too 
Nov 24 20:31:09 <khem> eFfeM: let me see my notes
Nov 24 20:32:02 <eFfeM> khem,please. I was trying to get it onto the autobuilder to build from scratch, but failed on the qt issue, wasted some time rebuilding from scratch because I thought that was a problem
Nov 24 20:32:02 <khem> eFfeM: ERROR: QA Issue with staging: gmyth.pc failed sanity test (tmpdir) in path /scratch/oe/sysroots/armv7a-oe-linux-gnueabi/usr/lib/pkgconfig
Nov 24 20:32:41 <eFfeM> ah, this might be a different recipe
Nov 24 20:33:13 <ka6sox> ericben, thanks.
Nov 24 20:33:25 <khem> last I remember it was gmyth_0.7.1.bb IIRC
Nov 24 20:33:28 <eFfeM> checking, I think this is something I never build, but system is too busy
Nov 24 20:34:40 <ka6sox> zecke, do you still have a sourcemirror?
Nov 24 20:35:43 <ericben> ka6sox: ok my answer was totally wrong I didn't understand your question ;-)
Nov 24 20:35:44 <Tartarus> khem?
Nov 24 20:35:51 <khem> Tartarus: yo
Nov 24 20:35:52 <Tartarus> Where'd you test qemu-native
Nov 24 20:35:56 <eFfeM> khem, this is a package which was in the mythtv dir, but it is not really a recipe from mythtv itself, gmyth is a different project, but in do_compile_append there is already a sed script to change paths in the pc file
Nov 24 20:36:16 <ka6sox> ericben, it could have been there...I did go and look :D
Nov 24 20:36:22 <khem> eFfeM: yeah its a different recipe 
Nov 24 20:36:22 <Tartarus> or maybe this needs a PARALLEL_MAKE="" :(
Nov 24 20:36:47 <khem> Tartarus: I did it on a -j2 system
Nov 24 20:36:54 <Tartarus> blows up on 
Nov 24 20:36:55 <Tartarus> 8
Nov 24 20:36:58 <khem> Tartarus: do u see parallel build issue ?
Nov 24 20:37:19 <khem> hmm
Nov 24 20:37:31 <Tartarus> cmd.o fails looking for config-host.h
Nov 24 20:37:33 <khem> I did it on two systems actually one -j2 another -j4
Nov 24 20:37:41 <eFfeM> khem, i have no idea what is all is about, and no idea if it still works, it is from before the packages->recipes rename from mar 17 2009, 
Nov 24 20:38:05 <khem> eFfeM: git log --follow <recipe> will give you all history
Nov 24 20:39:08 <ericben> bye
Nov 24 20:39:23 <khem> Tartarus: look here https://bugs.gentoo.org/show_bug.cgi?id=343175
Nov 24 20:39:26 <khem> may be thats it
Nov 24 20:39:39 <eFfeM>  khem, yeah, got it, it is created by koen in 2008, guess you should ask him to fix it
Nov 24 20:39:48 <Tartarus> Yeap
Nov 24 20:39:50 <Tartarus> That's it
Nov 24 20:40:10 <eFfeM>  /me is not touching recipes from koen, not even with a pole
Nov 24 20:43:33 <eFfeM> seems this gmyth project is dead, no commits in the last 2.3 yrs 
Nov 24 20:49:37 <Jay7> kergoth: have you found any issues wrt meta-toolchain* and git master/pp?
Nov 24 20:51:46 <kergoth> Jay7: i fixed an issue in master and an issue in parallel, and successfully built meta-toolchain on pp overnight last night
Nov 24 20:51:57 <Jay7> kergoth: oh, good!
Nov 24 20:52:21 <kergoth> took a long time to nail down
Nov 24 20:53:00 <GNUtoo> hi valhalla 
Nov 24 20:54:22 <Jay7> meta-toolchain's build results: http://tinderbox.openembedded.net/builders/Jay7-tb/ 
Nov 24 20:54:33 <Jay7> lot of strange errors there
Nov 24 21:08:53 <blindvt> khem, please consider installing something to the effect of http://paste.debian.net/100693/
Nov 24 21:08:57 <blindvt> khem, TIA
Nov 24 21:15:17 <blindvt> khem, (or let me know if you prefer an official patch to the list)
Nov 24 21:21:00 <blindvt> wee! Lasse finally suggests xz officially for the kernel :)
Nov 24 21:25:03 <rphillips> the parallel processing support in bitbake is fantastic
Nov 24 21:25:52 <rphillips> major kudos, kergoth 
Nov 24 21:37:55 <khem> blindvt: send it to ml
Nov 24 21:38:03 <blindvt> khem, k
Nov 24 21:38:29 <khem> Tartarus: can you verify if that fix works for you
Nov 24 21:38:37 <khem> and in that case push it to both branches
Nov 24 21:40:38 <Tartarus> The gentoo patch?  I can tell it will, yeah
Nov 24 21:40:43 <khem> Tartarus: ok 
Nov 24 21:40:47 <khem> yes that one
Nov 24 21:40:55 <Tartarus> Do it :)
Nov 24 21:41:10 <khem> ok. Well I dont have it failing here so I cant verify
Nov 24 21:41:15 <khem> but will depend on you
Nov 24 21:45:19 <Crofton|road> does anyone know what the gsl change did?
Nov 24 21:45:32 <khem> Tartarus: 0.13.0 should fix the problem we have with generating locales
Nov 24 21:45:47 <khem> Crofton|road: which gsl change ?
Nov 24 21:46:42 * khem is not scared of reparsing now a days
Nov 24 21:46:47 <Crofton|road> not sure, gnuradio stopped building, and I remember something, 
Nov 24 21:46:58 <khem> takes about 2mins on this core2duo box
Nov 24 21:47:03 <Crofton|road> sorry I have not so good access to my hw at the moment
Nov 24 21:47:16 <khem> Crofton|road: which road are you on
Nov 24 21:47:25 <Crofton|road> hhe
Nov 24 21:47:31 <Crofton|road> this is irc at home on screen
Nov 24 21:47:35 <Crofton|road> I am in CT now
Nov 24 21:47:42 <Crofton|road> on a windows laptop using putty
Nov 24 21:48:43 <khem> hmm
Nov 24 21:48:50 <khem> so house is not on fire for sure :)
Nov 24 21:49:00 <Crofton|road> yes :)
Nov 24 21:49:58 <CIA-109> 03Khem Raj <raj.khem@gmail.com> 07master * rfe798c3a31 10openembedded.git/recipes/qemu/ (qemu-0.13.0/parallel-build.patch qemu_0.13.0.bb): 
Nov 24 21:49:58 <CIA-109> qemu_0.13.0.bb: Fix parallel make build failure
Nov 24 21:49:58 <CIA-109> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Nov 24 21:50:01 <khem> Tartarus: pull and retry
Nov 24 21:51:43 <eFfeM> khem, probably got a patch for mythtv & qt 4.7, testing it now
Nov 24 21:53:02 <khem> eFfeM: awesome
Nov 24 21:53:23 <khem> kergoth: any plans to get parallel parsing into master
Nov 24 21:53:28 <khem> soon
Nov 24 21:53:47 <Tartarus> Soon as he's really sure it's not breaking things ;)
Nov 24 21:53:54 <kergoth> exactly
Nov 24 21:54:08 <khem> hmmm
Nov 24 21:54:11 <kergoth> and its a good thing we didn't merge it, given the issues i fixed last night
Nov 24 21:54:14 <Jay7> what was issues with locale generation?
Nov 24 21:54:25 <khem> thats a hard ask for bitbake which has no real testsuite but usecases only
Nov 24 21:54:34 <khem> Jay7: qemu used to die
Nov 24 21:56:09 <khem> kergoth: I have veen using it everywhere on 3 different machines without any issues known
Nov 24 21:56:10 <kergoth> khem: agreed, it is, that's why i've just requested tested and waited it out :)
Nov 24 21:56:17 <kergoth> but i'd like to merge it this week
Nov 24 21:56:20 <kergoth> unless something pops up
Nov 24 21:56:26 <kergoth> s/tested/testers/
Nov 24 21:56:29 <khem> ok
Nov 24 21:56:35 <khem> good plan
Nov 24 21:57:04 <khem> kergoth: so how do you combine the parse caches
Nov 24 21:57:08 <kergoth> even if there are remaining bugs, at this point i hate using it without it, we can fix them as we go
Nov 24 21:57:15 <khem> is that a serial process
Nov 24 21:57:15 <kergoth> what do you mean?
Nov 24 21:57:25 <kergoth> oh, into the data thats used by the runqueue?
Nov 24 21:57:28 <khem> kergoth: I havent looked at all on the parallel parsing code
Nov 24 21:57:32 <khem> yes
Nov 24 21:57:33 <Crofton|road> khem, could you do me a favour
Nov 24 21:57:38 <Crofton|road> I see this in testing
Nov 24 21:57:39 <khem> Crofton|road: sure
Nov 24 21:57:45 <Crofton|road> http://pastebin.ca/2001398
Nov 24 21:57:54 <Crofton|road> I think it is fixed in dev
Nov 24 21:57:58 <kergoth> yeah, the main process adds the info it gets for each recipe, whether it be from the cache or parsing, into its CacheData, serially yes, nature of the best, its additive
Nov 24 21:58:03 <khem> now that you spelt favour the way I learnt at school
Nov 24 21:58:09 <kergoth> that bit is fast as hell compared to actual cache loading time or recipe parsing time
Nov 24 21:58:21 <Crofton|road> let me see if I can quickly find the comit
Nov 24 21:58:22 <khem> kergoth: I see
Nov 24 21:59:00 <kergoth> khem: if you look at foerster|away's latest branch, the UI gets split into a separate process from the server, and cache loading gets its own progress bar
Nov 24 21:59:05 <kergoth> haven't done much testing of that yet though
Nov 24 21:59:24 <Crofton|road> damn, not in dev
Nov 24 21:59:36 <Crofton|road> I think there is a gsl patch on the list that needs applying
Nov 24 21:59:43 <khem> kergoth: umm nice
Nov 24 21:59:49 <Crofton|road> I have really bad email atm, due to me being a moron
Nov 24 22:00:04 <Crofton|road> and pw being down :)
Nov 24 22:01:10 <khem> fessions 
Nov 24 22:01:15 <khem> Crofton|road: hmm confessions
Nov 24 22:01:24 <khem> ok I found the patch seeminglt
Nov 24 22:01:43 * khem kicks mutt
Nov 24 22:02:38 <Crofton|road> I need to fix it :)
Nov 24 22:02:47 <Crofton|road> well by next week
Nov 24 22:02:52 <Crofton|road> lots of travel though
Nov 24 22:03:12 <khem> Crofton|road: ok, due to pw down I have to filter it from my mails so I will do that 
Nov 24 22:03:30 <Crofton|road> thanks
Nov 24 22:03:47 <Crofton|road> I want to make sure the release works for my test case :)
Nov 24 22:03:53 <khem> good intent
Nov 24 22:03:56 <Crofton|road> I can start test runs from here
Nov 24 22:04:08 <khem> fine let me apply that now then 
Nov 24 22:04:11 <khem> its been approved
Nov 24 22:04:47 <khem> shit this soup was really spicy
Nov 24 22:05:13 <ka6sox> too much curry?
Nov 24 22:05:38 <ka6sox> Crofton|road, do we want to import the existing patchwork db into the new one?
Nov 24 22:07:46 <Tartarus> khem: Ha
Nov 24 22:07:57 <Tartarus> | /usr/bin/ld: ../ui/curses.o: invalid string offset 4293984260 >= 784 for section `.strtab'
Nov 24 22:07:57 <Tartarus> | /usr/bin/ld: final link failed: Nonrepresentable section on output
Nov 24 22:07:57 <Tartarus> | collect2: ld returned 1 exit status
Nov 24 22:08:03 <Crofton|road> ka6sox: if it is "easy"
Nov 24 22:08:09 * Tartarus cleans and tries again
Nov 24 22:08:23 * Crofton|road hopes it is easy
Nov 24 22:08:31 <khem> Tartarus: hmm
Nov 24 22:08:47 <ka6sox> mysqldump ftw
Nov 24 22:08:59 <ka6sox> and then I'll need to hand edit a few thigns.
Nov 24 22:09:04 <Crofton|road> ok
Nov 24 22:09:12 <Crofton|road> as long as you are ok with it
Nov 24 22:09:44 <Crofton|road> your sql skillz sound better then mine :)
Nov 24 22:10:59 <ka6sox> I have help from others who know it :D
Nov 24 22:11:05 <ka6sox> Ijust need to snag it.
Nov 24 22:11:06 <Crofton|road> good
Nov 24 22:11:27 <Crofton|road> basically, I do not want the new one to get stuck on importing the old data
Nov 24 22:11:39 <Crofton|road> we have already talked about leaving the old one and working through it
Nov 24 22:11:49 <ka6sox> ya, me too
Nov 24 22:12:13 <khem> Tartarus: is that on a clean build ?
Nov 24 22:12:21 <khem> Tartarus: and whats your build distro
Nov 24 22:12:32 <Tartarus> khem: building on u10.04
Nov 24 22:12:37 <Tartarus> and no, i just pulled and built again
Nov 24 22:12:39 <Tartarus> clean testing now
Nov 24 22:12:46 <khem> Tartarus: hmm ok
Nov 24 22:13:08 <khem> the error you posted is also atermath of parallel processing 
Nov 24 22:13:13 <khem> which I think should be fixed 
Nov 24 22:14:36 <Tartarus> yeah, we got farther
Nov 24 22:14:38 <ka6sox> Crofton|road, apparently there will be a gap.
Nov 24 22:14:47 <ka6sox> from teh 19th till I get this one working.
Nov 24 22:14:50 <Crofton|road> ok
Nov 24 22:14:53 <Crofton|road> such is life
Nov 24 22:17:01 <khem> Crofton|road: the patch for gsl is applied to both master and release
Nov 24 22:17:48 <eFfeM> calling it a day, cya
Nov 24 22:18:03 <Jay7> nite
Nov 24 22:18:08 <CIA-109> 03Paul Menzel <paulepanter@users.sourceforge.net> 07master * r4a24a5522b 10openembedded.git/recipes/gsl/gsl.inc: (log message trimmed)
Nov 24 22:18:08 <CIA-109> gsl.inc: Remove `do_stage`.
Nov 24 22:18:08 <CIA-109> Inkscape fails to build after commit c2c8fe [1] with the following error.
Nov 24 22:18:08 <CIA-109> | checking for CAIRO_USER_FONTS... yes
Nov 24 22:18:08 <CIA-109> | checking for INKSCAPE... configure: error: Package requirements (gdkmm-2.4
Nov 24 22:18:09 <CIA-109> glibmm-2.4 giomm-2.4 gtkmm-2.4 >= 2.10.0 gtk+-2.0 libxml-2.0 >= 2.6.11
Nov 24 22:18:09 <CIA-109> libxslt >= 1.0.15 cairo sigc++-2.0 >= 2.0.12 gthread-2.0 >= 2.0 libpng >=
Nov 24 22:18:46 <Crofton|road> khem, did you copy that to the release branch?
Nov 24 22:18:49 <Crofton|road> I will test
Nov 24 22:19:02 <khem> ka6sox: all you have to do is make it grok the ml ?
Nov 24 22:19:10 <Jay7> what do we are testing this night? :)
Nov 24 22:19:11 <khem> Crofton|road: yes
Nov 24 22:19:36 <khem> Jay7: keep testing same stuff you did initially on release branch
Nov 24 22:19:50 <khem> Jay7: and make sure that errors you had last time are gone
Nov 24 22:20:22 <Jay7> khem: there are some in meta-toolchain* build
Nov 24 22:21:36 <XorA|gone> morning
Nov 24 22:24:41 <khem> Jay7: meta-toolchain-arago ?
Nov 24 22:24:55 <Crofton|road> khem: looks like gnuradio went past configure, thanks
Nov 24 22:25:02 <khem> thats arago specific I wont sweat too much on that one
Nov 24 22:25:11 <khem> Crofton|road: k
Nov 24 22:26:11 <khem> Jay7: libmailwrapper is not fetchable as I see on your builds
Nov 24 22:26:20 <khem> its another thing from hh.org
Nov 24 22:30:42 <ka6sox-away> does anybody here know anyone who is a contact in hh.org so I can get those archives?
Nov 24 22:35:52 <Jay7> khem: meta-toolchain-gpe-sbox have error too
Nov 24 22:36:14 <Jay7> http://tinderbox.openembedded.net/packages/1072151/
Nov 24 22:36:36 <Jay7> meta-toolchain-fso: http://tinderbox.openembedded.net/packages/1071785/
Nov 24 22:37:01 <Jay7> hm..
Nov 24 22:37:10 <CIA-109> 03Graham Gower <graham.gower@gmail.com> 07master * rb5597a3e30 10openembedded.git/recipes/strace/ (7 files in 2 dirs): (log message trimmed)
Nov 24 22:37:10 <CIA-109> strace: Fix build on mips{, el} when DISTRO_FEATURES lacks "largefile".
Nov 24 22:37:10 <CIA-109> While here,
Nov 24 22:37:10 <CIA-109> - make 4.5.20 the default for mips instead of 4.5.18.
Nov 24 22:37:10 <CIA-109> - Fix LICENSE fields.
Nov 24 22:37:10 <CIA-109> | mipsel-oe-linux-uclibc-gcc -march=mips32 -Wall
Nov 24 22:37:10 <CIA-109> -isystem/mnt/oe/tmp/sysroots/mipsel-oe-linux-uclibc/include
Nov 24 22:37:14 <Jay7> linux-efikamx fails on do_unpack..
Nov 24 22:37:18 <Jay7> http://tinderbox.openembedded.net/packages/1068692/
Nov 24 22:37:21 <CIA-109> 03Graham Gower <graham.gower@gmail.com> 07master * r46b8687290 10openembedded.git/recipes/gnutls/ (gnutls-2.10.2/parallel-build.patch gnutls_2.10.2.bb): (log message trimmed)
Nov 24 22:37:21 <CIA-109> gnutls_2.10.2.bb: Fix parallel build failure.
Nov 24 22:37:21 <CIA-109> In file included from core.c:32:
Nov 24 22:37:21 <CIA-109> enums.h:3:1: error: unterminated #ifndef
Nov 24 22:37:22 <CIA-109> In file included from core.c:40:
Nov 24 22:37:22 <CIA-109> enum-map.i.c:867:1: error: unterminated argument list invoking macro "SCM_SMOB_PRINT"
Nov 24 22:37:23 <CIA-109> In file included from errors.c:28:
Nov 24 22:38:45 <khem> Jay7: I will wait for grg to see into those errors
Nov 24 22:38:53 <Jay7> ok
Nov 24 22:39:03 <grg> huh.. what?
Nov 24 22:40:33 <khem> opkg is not finding some packages during image generation
Nov 24 22:41:08 <khem> e.g http://tinderbox.openembedded.net/public/logs/task/11079255.txt
Nov 24 22:43:08 <grg> khem, that looks like ipkg and opkg are both included in the image. Bad.
Nov 24 22:43:37 <Tartarus> khem: same
Nov 24 22:43:53 <Tartarus> DISTRO=minimal-uclibc MACHINE=qemux86 bitbake qemu-native
Nov 24 22:44:02 <Tartarus> 32bit ubuntu 10.04
Nov 24 22:46:20 <Jay7> ka6sox-away: ping me when you will be idle :)
Nov 24 22:54:05 <ka6sox-away> Jay7, never "idle" but available :D
Nov 24 22:55:09 <khem> grg: hmm
Nov 24 22:55:14 <khem> Tartarus: no success
Nov 24 22:55:54 <khem> Tartarus: lemme try it out or worst come we might have to disable parallel make for it
Nov 24 22:58:02 <Tartarus> dunno if that's a parallel problem
Nov 24 22:58:02 <Tartarus> sec
Nov 24 22:58:25 <khem> yes it is
Nov 24 22:58:30 <Tartarus> you googled up that one too?
Nov 24 22:58:35 <khem> some object is corrupt
Nov 24 22:58:57 <khem> no but I have seein similar issues with other projects
Nov 24 23:00:28 <Tartarus> trying
Nov 24 23:01:32 <khem> but you have to rebuild clean
Nov 24 23:01:32 <CIA-109> 03Khem Raj <raj.khem@gmail.com> 07master * r51e9eb4c09 10openembedded.git/recipes/inetutils/inetutils_1.8.bb: 
Nov 24 23:01:32 <CIA-109> inetutils_1.8.bb: Disable help2man, doesnt work in cross env.
Nov 24 23:01:32 <CIA-109> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Nov 24 23:01:43 <CIA-109> 03Khem Raj <raj.khem@gmail.com> 07master * r1b5f14a161 10openembedded.git/recipes/help2man/help2man_1.37.1.bb: 
Nov 24 23:01:43 <CIA-109> help2man_1.38.2.bb: New recipe
Nov 24 23:01:43 <CIA-109> Add recipe for latest 1.38.2 version and remove 1.37.1 in favour of it.
Nov 24 23:01:43 <CIA-109> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Nov 24 23:01:56 <ant__> khem: btw http://lists.busybox.net/pipermail/uclibc-cvs/2010-February/027454.html is not applied in uClibc-0.9.30.2 
Nov 24 23:02:28 <khem> ant__: thats strange
Nov 24 23:02:44 <Tartarus> yeah, did a -c clean
Nov 24 23:02:47 <Tartarus> waiting waiting waiting
Nov 24 23:02:52 <khem> hmm may be its after the release uClibc-0.9.30.2
Nov 24 23:03:04 <khem> Tartarus: with -j1 it will take forever
Nov 24 23:03:07 <ant__> I'm looking in our tar.bz
Nov 24 23:03:24 <ka6sox-away> Crofton|road, you still here?
Nov 24 23:04:20 <Tartarus> khem: yes :(
Nov 24 23:07:13 <ant__> khem: yes
Nov 24 23:07:15 <ant__> he http://git.uclibc.org/uClibc/log/?h=0_9_30
Nov 24 23:08:11 <ant__> it is to read 0.90.30-rc2
Nov 24 23:10:05 <ant__> khem: do you dare to bump git rev to final 0.9.30 ?
Nov 24 23:10:22 <khem> ant__: hmm
Nov 24 23:10:27 <blindvt> ant__, is it in .30.3?
Nov 24 23:10:41 <ant__> perhaps angstrom pins
Nov 24 23:10:44 <ant__> lemme see
Nov 24 23:10:44 <khem> blindvt: yes it should be in .30.3
Nov 24 23:10:59 <khem> when that releases
Nov 24 23:11:35 <ant__> I could not build x264
Nov 24 23:11:43 <blindvt> khem, ant__, we _did_ release a .30.3: http://uclibc.org/downloads/uClibc-0.9.30.3.tar.xz
Nov 24 23:11:59 <ant__> interestingly here was never fetched
Nov 24 23:12:35 <blindvt> ant__, you should be using .31 or git anyway. i'm not going to fix .30
Nov 24 23:13:00 <ant__> ./distro/angstrom-2010.x.conf:PREFERRED_VERSION_uclibc        	?= "0.9.30.2"
Nov 24 23:13:29 <ant__> I'll retry with minimal
Nov 24 23:14:52 <ant__> you can add 0.9.30.2 to the list of broken
Nov 24 23:14:56 <ant__> ;)
Nov 24 23:15:00 <blindvt> ant__, you folks don't pick binutils from sane-toolchain for micro (or did not until recently, at least) so yea. If somebody wants to stick to unsupported obsolete stuff it's for your own amusement ;P
Nov 24 23:15:06 <khem> ant__: its not tagged ?
Nov 24 23:15:13 <khem> sorry that was for blindvt
Nov 24 23:15:32 <blindvt> khem, it's tagged: http://git.uclibc.org/uClibc/tag/?h=0_9_30&id=0_9_30_3
Nov 24 23:15:33 <khem> grg: see task-sdk-sbox-gpe.bb :)
Nov 24 23:15:48 <khem> grg: I think that should use opkg now righ ?
Nov 24 23:16:10 <ant__> we have to ask angstrom maintainers to bump the release
Nov 24 23:16:20 <ant__> xv264 and ffmpeg will not build
Nov 24 23:16:23 <blindvt> khem, our git web-viewer doesn't support xz. I should fix that sometimes..
Nov 24 23:16:32 <khem> ah
Nov 24 23:17:05 <grg> khem, the ipkg line can just be removed. opkg will be pulled in elsewhere
Nov 24 23:17:09 * blindvt calls it a day
Nov 24 23:17:10 <ant__> fwiw we still should add knowledge of lzo and lzma to the classes
Nov 24 23:17:13 <blindvt> g'night all
Nov 24 23:17:24 <ant__> iirc
Nov 24 23:17:37 <ant__> 'nite blindvt 
Nov 24 23:18:49 <ant__> hm.. qemu-native failing from scratch...
Nov 24 23:19:02 <grg> khem, task-openprotium.bb has ipkg too
Nov 24 23:19:27 <grg> i guess i missed the task directory when i did a cleanup some months ago
Nov 24 23:19:52 <khem> grg: ok, I have patched task-sdk-sbox-gpe.bb
Nov 24 23:19:57 <khem> others I will leave upto you
Nov 24 23:20:38 <khem> grg: how about ipkg-utils
Nov 24 23:20:42 <ant__> khem: I suspect trhe perl issue was originated by me, starting a build in Ubuntu env (with perl  threads) and having resumed after rebooting in Gentoo (no perl threads)
Nov 24 23:20:47 <ant__> :&
Nov 24 23:20:52 <khem> grg: why dont you send a comprehensive patch 
Nov 24 23:21:12 <khem> ant__: hmmm
Nov 24 23:21:25 <khem> well that kind of hose up only godsave
Nov 24 23:21:33 <ant__> now our $perl_threads = 0;
Nov 24 23:22:09 <ant__> probably build broke and I shut-off
Nov 24 23:22:23 <khem> arm is prepping for 64bit core it seems interesting http://infoworld.com/d/hardware/arm-readies-processing-cores-64-bit-computing-649
Nov 24 23:23:38 <khem> grg: also look into meta/ tasks/ and images/ folders when you replace ipkg with opkg
Nov 24 23:24:01 <ant__> khem: qemu-native fails like this:
Nov 24 23:24:02 <ant__> /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/bin/ld: ../slirp/cksum.o: invalid string offset 4293984260 >= 32 for section `.strtab'
Nov 24 23:24:02 <ant__> /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
Nov 24 23:24:02 <ant__> collect2: ld returned 1 exit status
Nov 24 23:24:41 <khem> ant__: ok. Tartarus is seeing same. 
Nov 24 23:24:56 <khem> ant__: lets disable parallel make for test sake
Nov 24 23:25:03 <ant__> sorry, I missed the chat
Nov 24 23:25:10 <khem> ant__: can you do that ? and see if it works
Nov 24 23:25:14 <khem> and report here
Nov 24 23:25:16 <ant__> sure
Nov 24 23:25:33 <ant__> was -j5 fwiw
Nov 24 23:26:55 <grg> khem, ipkg-utils should stay as is. nylon and openprotium appear to be the other places where ipkg is still included verbatim. I assume these are not maintained right now?
Nov 24 23:30:08 <ant__> khem: I just added PARALLEL_MAKE = "" still I see a funny NOTE: Applying patch 'parallel-build.patch' (../openembedded/recipes/qemu/qemu-0.13.0/parallel-build.patch)
Nov 24 23:30:08 <ant__>  ;)
Nov 24 23:33:06 <ant__> khem: it compiled slirp/cksum.o, looking good
Nov 24 23:35:43 <khem> ant__: that patch does no harm
Nov 24 23:35:45 <ant__> argh...slow as hell with one single core
Nov 24 23:35:56 <grg> khem, actually now that i look  deeper, there are other places where ipkg related stuff needs to be pulled from. I'll come up with a comprehensive patch, but it will be too invasive for release.
Nov 24 23:36:05 <khem> ant__: yes it will be but in grand scheme of things it may be ok
Nov 24 23:36:18 <khem> by the time toolchain is generated it will build it in paralle
Nov 24 23:36:18 <Jay7> you can try to override -j for special directory only
Nov 24 23:36:31 <Jay7> by patching makefile
Nov 24 23:36:41 <Jay7> (just an idea)
Nov 24 23:36:57 <khem> Jay7: for that one has to understand the full qemu build system
Nov 24 23:37:19 <khem> grg: Dont worry, how invasive could ti be
Nov 24 23:37:45 <khem> grg: or you can divide it into common and more invasive
Nov 24 23:38:01 <Jay7> is it 0.13?
Nov 24 23:38:03 <khem> we can apply common one to release and leave invasive one + common on master
Nov 24 23:38:09 <khem> Jay7: yes
Nov 24 23:39:33 <Jay7> well.. let me have quick look on this
Nov 24 23:40:37 <ant__> omg %CPU is between 0,65 and 3.5% since some mins...
Nov 24 23:41:14 <ant__> cc1 I mean
Nov 24 23:43:44 <Crofton|road> khem: release just built, starting over from clean now
Nov 24 23:44:38 <khem> Crofton|road: nice
Nov 24 23:51:05 <Jay7> /usr/bin/ld: final link failed: File truncated
Nov 24 23:51:07 <Jay7> collect2: ld returned 1 exit status
Nov 24 23:51:49 <ant__> khem: NOTE: package qemu-native-0.13.0-r1: task do_rm_work_all: Succeeded
Nov 24 23:52:55 <khem> ant__: ok I can see it also on one machine here
Nov 24 23:53:06 <khem> so I guess I will have to disable parallel make for now
Nov 24 23:53:12 <khem> let me try the fix on my end
Nov 24 23:54:28 * grg can't git pull... fatal: read error: Connection reset by peer
Nov 24 23:58:27 <grg> fixed now! Thanks guardian angel!
Nov 24 23:58:36 <ka6sox> :D
Nov 24 23:59:14 <grg> ka6sox, :)
Nov 25 00:06:06 <ant__> good night
Nov 25 00:12:43 <Jay7> hm..
Nov 25 00:13:12 <Jay7> I've disabled all patches and qemu-native was build ok
Nov 25 00:13:17 <Jay7> I'll retry
Nov 25 00:15:54 <Jay7> make -j6 is pretty looking on cpu graphs..
Nov 25 00:18:07 <Jay7> hm.. fine again
Nov 25 00:18:51 <Tartarus> ya j1 worked
Nov 25 00:19:03 <grg> Jay7, i got qemu-native failing too just now
Nov 25 00:19:47 <grg> http://tinderbox.openembedded.org/public/logs/task/11147120.txt
Nov 25 00:22:22 <Jay7> hm..
Nov 25 00:22:37 <Jay7> I've enabled patches and got fail
Nov 25 00:22:47 <Jay7> should check again
Nov 25 00:23:21 <Tartarus> grg: it's a parallel thing :(
Nov 25 00:23:24 <Tartarus> khem found a patch for one problem
Nov 25 00:23:26 <Tartarus> but not that one
Nov 25 00:23:45 <grg> Tartarus, odd that I've never seen it before and now we all see it at the same time
Nov 25 00:23:56 <Jay7> Tartarus, grg: can you try to disable all patches in recipe and rebuild without -j1?
Nov 25 00:24:25 <grg> Jay7, i'll play a while
Nov 25 00:24:35 <Tartarus> grg: new version
Nov 25 00:24:37 <Tartarus> 0.13.0
Nov 25 00:24:41 <grg> ah
Nov 25 00:24:49 <Jay7> it was ok for me twice.. will retest more
Nov 25 00:24:50 * grg tries to pay attention
Nov 25 00:24:54 <Tartarus> Jay7: except for the parallel bugfix, k
Nov 25 00:25:57 * Jay7 wonders parallel parsing again
Nov 25 00:29:30 <Jay7> hm.. build ok w/o parallel bugfix
Nov 25 00:29:52 <Jay7> with all other patches..
Nov 25 00:30:05 <Jay7> looks like random race..
Nov 25 00:30:20 <Jay7> so.. -j1 is only reliable solution atm
Nov 25 00:33:53 <Tartarus> well, lets see
Nov 25 00:33:59 <Tartarus> the parallel-bugfix patch is a real and good one
Nov 25 00:34:09 <Tartarus> lets see if we don't just have a problem w/ the other patches we add
Nov 25 00:38:25 <Jay7> ERROR: Task do_rebuild does not exist for target qemu-native
Nov 25 00:38:28 <Jay7> :(
Nov 25 00:42:48 <Jay7> something strange.. it builds ok for me w/o parallel bugfix
Nov 25 00:42:59 <Jay7> I'll move it before others
Nov 25 00:45:01 <Tartarus> nope, same bug
Nov 25 00:45:07 <Tartarus> -j8
Nov 25 00:45:34 <Jay7> -j6 here..
Nov 25 00:46:18 <Jay7> failed with bugfix again..
Nov 25 00:46:21 <Jay7> angstrom/tosa
Nov 25 00:48:27 <Jay7> ah, well.. -j8 break it :)
Nov 25 00:49:59 <Jay7> btw, why do we building full qemu/
Nov 25 00:50:11 <Jay7> we can build only qemu-arm
Nov 25 00:50:54 <Jay7> for arm targets
Nov 25 00:51:30 <Jay7> --target-list=arm can be used
Nov 25 00:59:09 <grg> Jay7, wouldn't that be problematic if you built mutliple arches from your tree?
Nov 25 00:59:30 <grg> e.g. do a arm build then a x86 build. your native package would work with one, but not the other
Nov 25 00:59:37 <Jay7> well.. have not thought about this :)
Nov 25 01:00:57 <Jay7> --disable-system still can reduce build time :)
Nov 25 01:01:46 <Jay7> ah.. I've understand why libsdl was noted on wiki as required for OE..
Nov 25 01:02:08 <Jay7> to build qemu-native with sdl support
Nov 25 01:04:49 <Jay7> --disable-system reduces buildtime twice for me
Nov 25 01:05:02 <Jay7> do we really needed qemu-system-*?
Nov 25 01:08:06 <Jay7> and btw, this fixes build with -j8
Nov 25 01:08:15 <ka6sox> kewl!
Nov 25 01:10:18 <Jay7> testing -j2 now
Nov 25 01:13:04 <Jay7> build fine
Nov 25 01:13:30 <Tartarus> Jay7, we need a good set of systems, yes
Nov 25 01:13:32 <Jay7> Tartarus, grg, khem: please consider adding --disable-system 
Nov 25 01:13:39 <Tartarus> Or we make it a cross qemu
Nov 25 01:13:46 <Tartarus> otherwise you can't share TMPDIR w/ > 1 arch
Nov 25 01:14:11 <grg> cross qemu is probably good
Nov 25 01:14:12 <Jay7> qemu-<arch> is used only for locale generation afaik
Nov 25 01:14:35 <Jay7> qemu-system-<arch> is not used in building at all (afaik also)
Nov 25 01:14:48 <Jay7> this may be useful to run image in
Nov 25 01:15:08 <Jay7> but we can provide qemu-system recipes for this then.. or qemu-full
Nov 25 01:15:17 <Jay7> or leave it for user's distro
Nov 25 01:15:30 <Jay7> just another set of ideas :)
Nov 25 01:15:41 <Jay7> feel free to use it or drop it :)
Nov 25 01:19:01 <Tartarus> So, ah
Nov 25 01:19:15 <Tartarus> We need a way to have the contrib/qemu stuff be useful
Nov 25 01:19:28 <Tartarus> but yeah, hm
Nov 25 01:19:59 <Jay7> -j1 + time vs -j X + qemu-system :)
Nov 25 01:20:45 <Jay7> qemu-system-native?
Nov 25 01:21:07 <Jay7> if user will run contrib/qemu stuff it will build it
Nov 25 01:22:05 <Tartarus> We could just fix the races
Nov 25 01:22:10 <Tartarus> I'm sure upstream would like it :)
Nov 25 01:22:24 <Tartarus> or D_P = -1 0.13.0
Nov 25 01:22:39 <Tartarus> khem: Why did we push a new version in right now?
Nov 25 01:22:49 <Tartarus> Maybe we should just D_P = -1 0.13.0 for now due to the various issues
Nov 25 01:23:03 <Jay7> +1 from me 
Nov 25 01:27:00 <Jay7> time to sleep
Nov 25 01:27:18 <Jay7> I've started testbuilder against master branch for meta-toolchains again
Nov 25 01:30:35 <Tartarus> I kicked ours off again too, but before the qemu change
Nov 25 01:31:19 <Jay7> I've used --disable-system as workaround
Nov 25 01:32:13 <Jay7> not sure it will help with gcc4.5
Nov 25 01:32:24 * Jay7 -> sleep
Nov 25 01:32:26 <Tartarus> yay
Nov 25 01:32:27 <Tartarus> minimal-image,minimal-uclibc,qemuppc,sb-u804 #56 (stable) 
Nov 25 01:32:38 <Tartarus> also
Nov 25 01:32:42 <Tartarus> meta-toolchain,minimal,qemumips,sb-rhel5 #56 (stable) 
Nov 25 01:37:46 <Tartarus> minimal-image,minimal-uclibc,qemuarm,sb-rhel5
Nov 25 01:37:48 <Tartarus> stable
**** ENDING LOGGING AT Thu Nov 25 02:59:58 2010