**** BEGIN LOGGING AT Wed May 20 02:59:57 2009 May 20 03:11:45 what's the proper way to build kernel from a different recipe w/o overwriting PREFERRED_PROVIDER_virtual/kernel for the machine? May 20 04:23:17 kergoth: are you still around? May 20 04:45:49 03Angus Ainslie  07fso/milestone5.5 * rb625cc78fe 10openembedded.git/recipes/openmoko-projects/paroli-elementary_git.bb: paroli-elementary : add PROVIDES python-elementary May 20 05:32:20 03Angus Ainslie  07fso/milestone5.5 * re1a6ae3bba 10openembedded.git/ (conf/checksums.ini recipes/mokomaze/mokomaze_0.5.1.bb): mokomaze : fixup the src URI May 20 06:26:05 * * OE Bug 4735 has been RESOLVED (FIXED) by thebohemian(AT)gmx.net May 20 06:26:07 * * introduce BPN (base package name) to simplify *-native recipes May 20 06:26:10 * * http://bugs.openembedded.net/show_bug.cgi?id=4735 May 20 06:27:06 * * OE Bug 1856 has been RESOLVED (WONTFIX) by thebohemian(AT)gmx.net May 20 06:27:08 * * RFE/RFC: strip -native from ${S} May 20 06:27:10 * * http://bugs.openembedded.net/show_bug.cgi?id=1856 May 20 06:44:23 good morning May 20 08:14:19 03Martin Dietze  07org.openembedded.dev * r819027217b 10openembedded.git/recipes/ser/ser_0.9.0.bb: Ser: Added dbg packet definition to ser to avoid problems with sanity checks. May 20 08:14:20 03Martin Dietze  07org.openembedded.dev * rd51bb45b49 10openembedded.git/recipes/meta/nylon-feed.inc: Nylon-feed: Updates May 20 08:14:20 03Martin Dietze  07org.openembedded.dev * r6f393268e4 10openembedded.git/recipes/base-files/base-files/ (mtx-2/fstab mtx-2/profile mtx-1/fstab mtx-1/profile): Base-files: Updated for nylon. May 20 08:14:22 03Martin Dietze  07org.openembedded.dev * r24db351c88 10openembedded.git/recipes/pciutils/ (pciutils-3.1.2/gcc-3-compatibility.patch pciutils_3.1.2.bb): May 20 08:14:25 pciutils: filter out flags that break gcc3 May 20 08:14:27 * this is done with a nylon override since we lack gcc3 overrides May 20 08:14:29 03Martin Dietze  07org.openembedded.dev * r9cd7c5f8da 10openembedded.git/conf/ (5 files in 2 dirs): Nylon: Nylon is now derived from angstrom. May 20 08:17:12 03Martin Dietze  07org.openembedded.dev * rcb70efeb71 10openembedded.git/ (11 files in 4 dirs): various nylon stuff: Updates to nylon-only code, needed to work with the current OE. May 20 09:13:26 florian: good morning May 20 09:13:37 good morning May 20 09:43:46 bletch, who wrote this bluez recipe? May 20 09:43:51 bluez4, rather May 20 09:44:19 hrw was quite right, it's bad news. May 20 09:49:55 likewise: The Sheeva is here - many thanks! May 20 09:50:45 pb_: thats what git log is for May 20 09:56:08 florian: cool (and phew) May 20 09:57:10 likewise: Its quite interesting TNT inside Germany sends insured only and arrives after two days maximum. May 20 09:59:54 florian: prepare nfsroot or sd card to upgrade it to angstrom May 20 09:59:59 morning May 20 10:00:29 XorA: yah, it's a bit tedious to use though. I wonder if there are any better tools for reviewing the history of files. May 20 10:01:41 03Koen Kooi  07org.openembedded.dev * r21dbc0814f 10openembedded.git/recipes/gcc/ (6 files in 4 dirs): gcc 4.3.2, 4.3.3, 4.4.0: attempt to fix zecke-no-host-includes.patch May 20 10:02:12 not that it really matters who wrote it in the first place, anyway, the outcome would still be the same :-} May 20 10:10:33 morning hrw May 20 10:15:52 mickeyl: good morning! May 20 10:16:09 good morning pb_ May 20 10:16:58 actually not all that good a morning here, my daughter was a bit fractious last night. oh well. May 20 10:17:25 maybe I can go to sleep under my desk for a while later. May 20 10:22:13 This sound somewhat familiar :-) May 20 10:23:49 pb_: uh oh, the joys of fatherhood. it's too early for the 3 months colics though May 20 10:24:07 hopefully just some temp. problem May 20 10:25:10 yeah, I'm sure she'll get over it. she was fine the night before, it just seems to be a bit random which times of day she wants to sleep and which ones she wants to eat. May 20 10:27:33 pb_: Our kids started to sleep pretty well when they started to move around. May 20 10:28:04 florian: ah. how long does that take? :-) May 20 10:28:28 pb_: half a year maybe :-} May 20 10:28:36 drat! May 20 10:28:57 oh well, could be worse May 20 10:29:04 right :) May 20 10:30:17 * Crofton|work is still freaked out by how small babies are May 20 10:30:27 Carrying them around with you helps too but its not always useful... May 20 10:31:48 Crofton|work: hrm... yes and how fast they grow! May 20 10:32:12 yeah May 20 10:32:33 yes, my wife was given one of those sling things. seems quite cool although the plastic clips that hold it together seem awfully flimsy. May 20 10:32:55 I might have to find a more robust looking one if I am going to carry the baby around in it. May 20 10:33:48 hmm, my friend had one without a clip May 20 10:34:25 Its shocking how much money you can spend on crappy stuff as soon it relates to babies :-/ May 20 10:35:46 yes indeed. we were quite lucky to be given a whole load of stuff by friends and relations who don't need it anymore. I haven't added up how much it would have cost if we needed to buy everything but it would have been a lot. May 20 10:35:47 ~curse mercurial fetcher May 20 10:35:49 May the fleas of a thousand camels infest your most sensitive regions, mercurial fetcher ! May 20 10:36:15 My friends are always passing baby stuff around :) May 20 10:36:49 even so, I think I've spent something like £300 on baby things in the past couple of weeks. mostly nappies I think :-} May 20 10:37:01 Crofton|work: heh, yeah, it seems to be a common pastime May 20 10:37:19 Crofton|work: so we do here May 20 10:37:35 Crofton|work: some stuff is used for ~month and not required anymore so why not share May 20 10:38:18 yeah May 20 10:40:46 well...may I be so nasty to interrupt #oe-parents? (yahwn...btw my 1,5yrs di not sleep until 2am last night..) May 20 10:41:11 pb_: about klibc.so shared object... May 20 10:41:41 I found this bits: May 20 10:41:45 Peter also put work May 20 10:41:47 into making klibc a shared object -- that doesn't need an shlib loader. May 20 10:41:49 It's pretty nifty how he does it, IMO: klibc.so becomes an ELF May 20 10:41:51 interpreter for any klibc-linked binaries. klibc-linked binaries are, May 20 10:41:53 to the ELF system, static binaries, but they wind up sharing klibc.so May 20 10:41:54 anyway due to this trick. May 20 10:42:13 the QA issue is bogus then ,isnt? May 20 10:45:04 http://arstechnica.com/open-source/reviews/2009/05/hands-on-intel-brings-rich-ui-to-moblin-linux-platform.ars May 20 10:46:54 ant_work: remind me which particular QA issue you're encountering? May 20 10:53:59 time for moblin on n8x0 devices ? May 20 10:56:32 XorA: n8x0 lacks 3d accel May 20 10:57:00 hrw: ah so they are using moblin to sell the intel useless gfx chipset May 20 10:57:08 n900 with moblin then :-D May 20 10:57:36 or Pandora May 20 10:57:39 or beagle May 20 10:59:39 pb_, look for a sling with rings to do the adjustment May 20 10:59:46 too bad that my laptop is i855 - no moblin May 20 11:01:00 pb_, http://www.mayawrap.com/n_sewsling.php May 20 11:03:29 Crofton|work: thanks, that looks handy May 20 11:05:02 mine is atom, but I prefer full linux May 20 11:06:42 yeah, they are surprisingly useful May 20 11:13:07 Everyone, please read my email to -dev on eV membership May 20 11:21:36 pb_: non dev contains .so, klibc, /work/akita-angstrom-linux-gnueabi/klibc-1.5-r9/install/klibc/lib/klibc.so May 20 11:22:22 ant_work: well, I kind of feel it would be better for klibc to have a versioned soname like everybody else, but it isn't an especially big deal. May 20 11:22:39 if you do want to go on installing it as just klibc.so then that's fine, and in that case disabling the qa check would be the right thing to do. May 20 11:23:03 pb_: I see. Th epoint is we just use klibc to build statical packages May 20 11:23:12 s/packages/binaries/ May 20 11:23:35 so I miss the point 'shared' May 20 11:24:03 ant_work: they aren't really static binaries, they just look as though they are. May 20 11:24:22 if they were truly static then you wouldn't need to ship klibc.so at all May 20 11:24:25 btw: help with kexec-tools_2.0.0 against klibc :) May 20 11:25:45 pb_: so kexec isn't 'pure' static? May 20 11:26:41 ant_work: doesn't sound like it. May 20 11:26:48 if it won't run without klibc.so then it isn't static May 20 11:27:13 not that it really matters, it's just a question of terminology really May 20 11:28:15 hm...iirc in my initramfs I have just two binaries (kexec, kexecboot), no libs May 20 11:29:06 oh, right. if that's true then klibc.so is irrelevant and you might as well not build it in the first place. May 20 11:29:29 (or you could start using it, of course, which might give you smaller binaries) May 20 11:30:12 he..atm the problems is finding the right headers... May 20 11:30:24 thesing did awesome job with old version May 20 11:30:32 but the code changes a lot May 20 11:31:28 and I don't remember so much abut the different *libc headers May 20 11:31:37 fwiw compiles fine with glibc May 20 11:37:11 Howdy. I am trying to setup oe for the first time. I would like some advice about MACHINE type. My first target is a Soekris 4521, which uses an AMD Elan SC520. Is the x86.conf my best choice? May 20 11:40:45 amd elan is i586? i686? i486? May 20 11:40:59 It is i486 class May 20 11:43:23 has fpu? May 20 11:43:49 x86.conf probably will work May 20 11:43:58 maybe kernel will need some tweaks May 20 11:44:12 I doubt it has an fpu, but I don't really know. May 20 11:45:16 It does have an fpu. May 20 11:47:03 happy you May 20 11:47:12 or rather 'lucky you' May 20 11:52:28 I'll start with x86, then. for distro, I am gueesing something like minimal would be good to start with. This is intended to be a access point. The other one that looks good is oplinux. Do you have a suggestion? May 20 11:55:23 minimal or angstrom May 20 11:55:34 either minimal or micro, depends how much you want this to be like a traditional unix system May 20 11:55:53 ah.. I forgot about micro May 20 11:56:01 I guess you could look at what wrt54 does, that seems to be pretty close to your application domain May 20 11:56:02 oh... did Webkit always need that much of disk space. The libray is quite fat... May 20 11:56:22 minimal is more of an Angstrom config clone ..... May 20 11:56:52 although micro-image builds fine in Angstrom May 20 11:57:16 * hrw -> 2.6.30-rc6+ May 20 11:58:27 Laibsch: ping? May 20 11:58:31 I don't know anything much about oplinux, and the "additional info" url mentioned in the conf file just gives error 404 which doesn't seem very encouraging. May 20 11:58:32 pong May 20 11:58:39 good morning May 20 11:58:41 Laibsch: hi! May 20 11:58:44 jeremy_laine: Hi May 20 11:58:51 Thank you for your work on tinderbox May 20 11:58:58 awesome service, very helpful May 20 11:59:02 Laibsch: I am nearly done with the other feature request May 20 11:59:09 cool! May 20 12:00:08 hrw and pb_, I want something kind of like openwrt, but with a few more features. Since I can have a 2GB flash and 64 meg of ram, I wanted to see what I could create. And, I have a could of non-x86 architecture machines to do next. I thought the soekris would be the easiest to start with. May 20 12:00:58 Severian: I would suggest that you try micro to start with and see if it does what you need. If that's a bit too basic, you can "upgrade" to minimal. May 20 12:01:10 or just use Angstrom May 20 12:01:26 with micro-image May 20 12:01:35 yeah, I'm still curiouis if it will boot :) May 20 12:02:27 pb_, OK. that sounds fine. Thank you for your help. May 20 12:05:34 cbrake: hi! May 20 12:10:10 I have gone through the local.conf file and I understand what to put for most things. But, I am mystified by PREFERRED_PROVIDERS. The wiki does not have any pages that mention it. Or, at least a search returns none. May 20 12:11:18 Should I leave those 6 lines alone? It looks like I should choose one or two. May 20 12:14:15 You can probably just leave those alone for the time being. May 20 12:15:10 OK, That is it for today. I'll start my first build and go to bed. Have a good day, and thank you again. May 20 12:15:19 Okay. Good luck. May 20 12:17:18 I get failing build due to "undefined reference to `ppoll'". Both udev and jack fails due to this ppoll error.. The configure script checks and finds ppoll(). Any ideas? May 20 12:20:26 jeremy_laine: hello May 20 12:35:33 03Graeme Gregory  07xora/angstrom-srcpv * rbde04996b8 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 20 12:35:34 03Lynn Lin  07xora/angstrom-srcpv * ra5f902c677 10openembedded.git/classes/package_rpm.bbclass: package_rpm: fix move wrong generated rpm name - closes #5078 May 20 12:35:35 03Marcin Juszkiewicz  07xora/angstrom-srcpv * r999d3b511e 10openembedded.git/recipes/util-linux-ng/ (util-linux-ng_2.14.bb util-linux-ng_2.15.bb): util-linux-ng: dropped use of FILESPATH May 20 12:35:36 03Koen Kooi  07xora/angstrom-srcpv * rd962d391fa 10openembedded.git/ (70 files in 3 dirs): linux-omap 2.6.29: refresh dss2 patchset May 20 12:35:40 03Koen Kooi  07xora/angstrom-srcpv * r72060aa173 10openembedded.git/recipes/gnome/zenity/ (fingerscroll.patch makefile.patch no-gnome-doc.patch): zenity cruft: remove files that a failed attemp at using git-am put there May 20 12:35:42 03Graeme Gregory  07xora/angstrom-srcpv * rea650c0405 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 20 12:35:47 03Marcin Juszkiewicz  07xora/angstrom-srcpv * r8379f149a2 10openembedded.git/recipes/netcat/netcat_0.7.1.bb: netcat: use update-alternatives as we have netcat in busybox too May 20 12:35:50 03Marcin Juszkiewicz  07xora/angstrom-srcpv * re04a5a65d9 10openembedded.git/recipes/tasks/task-proper-tools.bb: task-proper-tools: sort alphabetically May 20 12:35:53 03Martin Dietze  07xora/angstrom-srcpv * r7ef692efa3 10openembedded.git/classes/ (nylon-image.bbclass nylon-mirrors.bbclass): nylon classes: update image type and mirror locations May 20 12:35:56 03Koen Kooi  07xora/angstrom-srcpv * rce170fea65 10openembedded.git/recipes/u-boot/ (u-boot-git/leopardboard-support.patch u-boot_git.bb): u-boot git: add support for dm355-leopardboard May 20 12:35:59 03Martin Dietze  07xora/angstrom-srcpv * rceefd8ff95 10openembedded.git/recipes/busybox/ (4 files in 3 dirs): busybox: add more patches, update nylon defconfig May 20 12:36:08 03Rolf Leggewie  07xora/angstrom-srcpv * rac5d9b4400 10openembedded.git/conf/distro/minimal.conf: conf/distro/minimal.conf: assign DISTRO_TYPE only weakly May 20 12:36:11 03Rolf Leggewie  07xora/angstrom-srcpv * r0965086647 10openembedded.git/ (conf/checksums.ini recipes/granule/granule_1.4.0.bb): granule: add 1.4.0 May 20 12:36:14 03Marcin Juszkiewicz  07xora/angstrom-srcpv * r1e0d96b7d4 10openembedded.git/recipes/netcat/netcat_0.7.1.bb: netcat: use update-alternatives class (thx Koen) May 20 12:36:17 03Rolf Leggewie  07xora/angstrom-srcpv * r8722f3a634 10openembedded.git/recipes/gnome-mplayer/gnome-mplayer_cvs.bb: gnome-mplayer: point svn to googlecode.com. builds fine. May 20 12:36:20 03Rolf Leggewie  07xora/angstrom-srcpv * r02cc40c6ed 10openembedded.git/recipes/gnome-mplayer/ (3 files): May 20 12:36:31 gnome-mplayer: unify May 20 12:36:33 * add AUTHOR and SECTION (partly closes #4575) May 20 12:36:35 * fix HOMEPAGE May 20 12:36:37 * both recipes were unbuildable before this commit and are still unbuildable May 20 12:36:39 Unbreaking the recipes will be done in separate commits. May 20 12:36:41 03Andrea Adami  07xora/angstrom-srcpv * r5d7b852d1b 10openembedded.git/recipes/kexec/files/kexec2-klibc.patch: kexec-tools-static_2.0.0: add --nostdinc to purgatory Makefile makefile May 20 12:36:44 03Koen Kooi  07xora/angstrom-srcpv * rdda33cd8b2 10openembedded.git/conf/machine/dm355-leopard.conf: dm355-leopard: use upstream UBOOT_MACHINE May 20 12:36:47 03Rolf Leggewie  07xora/angstrom-srcpv * re6a8ba0d16 10openembedded.git/ (conf/checksums.ini recipes/kanatest/kanatest_0.4.8.bb): kanatest: add 0.4.8 May 20 12:36:52 03Marcin Juszkiewicz  07xora/angstrom-srcpv * r89489b1cea 10openembedded.git/recipes/tasks/task-proper-tools.bb: task-proper-tools: added few extra packages May 20 12:36:57 03Rolf Leggewie  07xora/angstrom-srcpv * re373e7e4f0 10openembedded.git/ (3 files in 2 dirs): kanatest: fight some bitrot (SRC_URI, HOMEPAGE, etc.) May 20 12:37:00 03Martin Dietze  07xora/angstrom-srcpv * r9cd7c5f8da 10openembedded.git/conf/ (5 files in 2 dirs): Nylon: Nylon is now derived from angstrom. May 20 12:37:05 03Rolf Leggewie  07xora/angstrom-srcpv * rf2ba78c87b 10openembedded.git/recipes/granule/ (granule.inc granule_1.2.4.bb): granule: move SRC_URI definition into .inc file May 20 12:37:08 03Martin Dietze  07xora/angstrom-srcpv * r6f393268e4 10openembedded.git/recipes/base-files/base-files/ (mtx-2/fstab mtx-2/profile mtx-1/fstab mtx-1/profile): Base-files: Updated for nylon. May 20 12:37:11 03Martin Dietze  07xora/angstrom-srcpv * r24db351c88 10openembedded.git/recipes/pciutils/ (pciutils-3.1.2/gcc-3-compatibility.patch pciutils_3.1.2.bb): May 20 12:37:16 pciutils: filter out flags that break gcc3 May 20 12:37:18 * this is done with a nylon override since we lack gcc3 overrides May 20 12:37:20 (37 lines omitted) May 20 12:38:39 XorA: Can you somehow exluce CIA from your branch? May 20 12:38:50 Laibsch: I have no contol over git May 20 12:39:02 jeremy_laine: what's that...full of beatles around ;) May 20 12:39:06 Is CIA pulling all branches? May 20 12:39:16 ant_work: click on it! May 20 12:39:20 It's good for you May 20 12:39:27 not pulling, there is a commit hook on git server May 20 12:39:37 Laibsch: supposedly bogus in the right frame May 20 12:39:38 Oh, OK May 20 12:39:46 ant_work: bogus? May 20 12:42:29 Laibsch: You can find this at http://imagebin.ca/view/FlgNGQd.html May 20 12:43:37 I know about those littel bug May 20 12:43:38 s May 20 12:43:43 they are not bogus, though May 20 12:43:45 Laibsch: sorry...I thought it was only triggered by failed builds May 20 12:43:52 click on them, they're good for you ;-) May 20 12:44:18 imho nonsense for opening a bug if 'succeeded' May 20 12:45:23 jeremy_laine: could you check the strange time-shifts? May 20 12:45:34 Laibsch: have you experienced any? May 20 12:45:40 (tinderbox) May 20 12:46:12 buggger util-linux-ng is broken on avr32 May 20 12:47:11 Laibsch: see http://tinderbox.openembedded.net/builds/148993/ May 20 12:48:00 best one is libroxy May 20 12:48:03 ant_work: Understand your point. But, even if your build succeeded, there might still be an open bug about it May 20 12:48:26 2009-05-09 00:52:15.993900 do_rm_work 0.10 Succeeded May 20 12:48:28 2009-05-09 08:51:31.213464 do_setscene 0.15 Succeeded May 20 12:48:37 I think one of those links per page (not per report) is enough May 20 12:49:10 ant_work: feel free to ignore that or any other links May 20 12:49:17 It certainly helps me with bug work May 20 12:49:26 np, thx. keep ahead! May 20 12:49:37 And I hope it will make people use our services more interactively May 20 12:49:52 like jump from the BTS to tinderbox and back and on to patchwork May 20 12:50:08 They all serve similar functions, but they do what they are best at May 20 12:50:27 sounds nice May 20 12:50:28 But again, I think one of those links per page (not per report) would be enough May 20 12:50:45 shame one need a user+pass for bugzilla, one for patchwork May 20 12:51:18 Isn't there an openID thing for bugzilla? May 20 12:51:31 * Laibsch hasn't really used openID, though May 20 12:51:58 openid great idea, rarely used and actually totally broken on LJ where it was invented :-D May 20 12:57:49 seems yet to be optional and not fully implemented May 20 12:57:57 https://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin May 20 12:58:05 https://bugzilla.mozilla.org/show_bug.cgi?id=294608 May 20 12:59:59 florian: Can you take a look at bug 4122? May 20 13:00:03 !oebug 4122 May 20 13:00:04 * * Bug 4122, Status: RESOLVED (WONTFIX), Created: 2008-03-25 10:55 May 20 13:00:05 * * : e-wm-0.16.999.041-autobuild May 20 13:00:06 * * http://bugs.openembedded.net/show_bug.cgi?id=4122 May 20 13:00:18 sorry, wrong number May 20 13:00:26 !oebug 3122 May 20 13:00:27 * * Bug 3122, Status: REOPENED, Created: 2007-10-05 12:34 May 20 13:00:28 * * joshua(AT)willowisp.net: bitbake gpephone-image fails on liblipsevent due to incorrect MD5/SHA256 checksums May 20 13:00:29 * * http://bugs.openembedded.net/show_bug.cgi?id=3122 May 20 13:00:53 what to do with the incorrect md5sums? Can I just replace them? May 20 13:01:09 Laibsch, do some investigation May 20 13:01:15 do not blindly replace May 20 13:01:47 Crofton: that is what I'm doing right now May 20 13:01:54 florian has the answer May 20 13:02:01 for liblipsevent replacing might eb good May 20 13:02:10 * Laibsch points to the bug report discussion, all in there May 20 13:02:13 basically, make sure you are not getting trojaned :) May 20 13:02:21 I guess some Chinese engineer messed this up. May 20 13:02:29 I'm sorry, but that again is asking too much ;-) May 20 13:02:48 If Florian wants to Trojan us, I have no defences May 20 13:03:00 heh May 20 13:03:20 florian: I will run the checksums I have by you and then replace them, OK? May 20 13:03:25 I just want to make sure people take checksum changed errors seriously May 20 13:03:33 Yes, I do, don't worry May 20 13:03:46 I wrote the wiki page on how to handle this properly, remember? May 20 13:03:48 ;-) May 20 13:04:06 heh May 20 13:04:08 Since Orange doesn't do any development on it any more this is likely not to happen again ;) May 20 13:04:22 Florian, do you still happen to have the old sources? May 20 13:04:47 alright, I'll go work on my email :) May 20 13:04:47 Doing a quick diff would of course be the best option May 20 13:05:31 question for @ALL: Will building different qte-mt packages likely have an adverse affect on my TMPDIR? May 20 13:05:56 I think that building libdsl-$a and libdsl-$b used to screw up your TMPDIR May 20 13:06:21 I think it was libdsl-x11 and libsdl-directfb or something May 20 13:08:01 yeah, sdl is a bit of a nightmare like that. May 20 13:08:06 other packages oughtn't to have the same problem though May 20 13:13:14 pb_: I had hoped that somebody had programmed the UI-agnostic version of SDL by now May 20 13:13:30 There was talk of this last time I touched this May 20 13:13:52 pb_: qte-mt should not give me problems in TMPDIR, then? May 20 13:14:16 Laibsch: sdl itself is meant to be ui-agnostic, that's kind of the point. I think it was just the opie port that caused a compatibility nightmare. May 20 13:14:29 or directfb maybe, though that seems a bit less likely May 20 13:14:54 * Laibsch has very little knowledge on the background of this May 20 13:15:13 I don't even know what sdl is necessary for May 20 13:15:16 anyway, yeah, I would expect qte-mt to be okay although qte isn't exactly my core competency. überhacker mickeyl might be able to give you a more definitive answer. May 20 13:15:36 I'm afraid he hasn't touched that stuff in ages, either May 20 13:15:57 I'll have to see if I can move away from that for my Japanese dictionary May 20 13:17:02 I don't know of anybody who's actively working on qte these days. ljp doesn't even seem to hang out in this channel anymore. May 20 13:19:02 bluelightning is May 20 13:19:46 ah right, very good May 20 13:20:13 qte-mt vs. qte is fine May 20 13:20:20 libsdl is the only offender May 20 13:20:24 cool, thanks May 20 13:20:31 and here, only the opie version, as pb_ said May 20 13:21:25 ljp no longer seems to be in development anyways, i think he's now fully moved into the advocacy section in Nokia... May 20 13:21:38 ah, heh May 20 13:21:42 could just be my biased view based on mailing list participation though May 20 13:21:42 :) May 20 13:28:03 mickeyl: set bug 1463 to wontfix? May 20 13:28:27 I guess if there ever was anybody who wanted to support this it was a few years ago May 20 13:28:43 I don't see anybody taking care of it soon May 20 13:30:28 Hello all. May 20 13:30:50 Am I the only one seeing ML lags today? May 20 13:30:53 Laibsch: agree May 20 13:32:18 * pb_ shopping time now May 20 13:32:19 bbiab May 20 13:32:29 cu May 20 13:43:18 Laibsch: ok abut the bug and fixing but its not likely to happen soon. May 20 13:43:32 sure May 20 13:43:52 thanks May 20 13:53:57 Laibsch: about meta-bugs: cleaning is possible..we just need feedback from users the issue has gone May 20 13:54:02 (see Zaurus) May 20 13:54:31 outstanding issue: the broken keymap...yes..bug still there... May 20 13:55:30 ? May 20 13:55:33 number? May 20 13:55:44 I have touched 100-200 bugs in the last 24 hours May 20 13:58:18 Laibsch: e.g. 2287 2619 2156 2309 2148 2652 May 20 13:59:13 !oebug 2287 May 20 13:59:14 * * Bug 2287, Status: NEW, Created: 2007-05-09 10:44 May 20 13:59:15 * * : \[META\] SL-C7xx with Angstrom (first-generation clamshell Zaurii) May 20 13:59:16 * * http://bugs.openembedded.net/show_bug.cgi?id=2287 May 20 13:59:33 What about it? May 20 13:59:40 I don't think I even touched that one May 20 14:00:14 Nope, I certainly didn't May 20 14:01:28 you probably created the meta May 20 14:32:55 Not only probably, I did create it May 20 14:32:57 See above May 20 14:33:10 I still don't know what action you want me to take May 20 14:33:56 Just because I created the meta-bug does not mean I have a special interest in fixing it, BTW May 20 14:34:32 hrw|gone: I think you fixed the "/var/lib/python-support/python2.6/bb/COW.py:29: DeprecationWarning: the sets module is deprecated" warning somewhere, right? May 20 14:34:49 Is there a revision I can cherry-pick so it goes away for me, too? May 20 14:35:03 Actually, I'd probably push that to Jaunty, if it works May 20 14:35:42 That particular bug (2287) seems to be specifically an Angstrom issue. I guess it ought to be reassigned to the 4ng5tr0m h4x0rs for action, or closed if they aren't interested in it. May 20 14:35:57 !oebug 2287 May 20 14:35:58 * * Bug 2287, Status: NEW, Created: 2007-05-09 10:44 May 20 14:35:59 * * : \[META\] SL-C7xx with Angstrom (first-generation clamshell Zaurii) May 20 14:36:00 * * http://bugs.openembedded.net/show_bug.cgi?id=2287 May 20 14:37:47 pb_, that is the entire problem with having an OE bugtracker May 20 14:37:50 pb_: That is a bit of a minefield May 20 14:37:54 ~boxer May 20 14:37:55 i heard boxer is Sharp SL-C860, or a dog. in reality, this is an SL-C760 with a different case color. please don't support stupid marketing tricks. May 20 14:38:07 in the end, almost everything becomes a distro issue May 20 14:38:31 Crofton: I'm still thinking about how to restructure the OE bug tracker May 20 14:38:35 heh May 20 14:38:38 given the new shiny tools we have May 20 14:38:45 first you have to figure out who the audience is May 20 14:38:47 There is so little interest in Zaurus anymore, might as well close the 2 bugs olding that meta open then close the meta May 20 14:39:04 II still have an interest in the Z May 20 14:39:16 Laibsch: then fix those bugs :-) May 20 14:39:22 wv May 20 14:39:22 them create a Z bugtracker :) May 20 14:39:57 Anyways, let's postpone those questions May 20 14:40:09 I think there is enough to chew on for now May 20 14:40:22 * XorA wonders who actually claims to be an Angstrom dev these days May 20 14:40:25 Crofton: more or less, yeah. I think it's probably right that the individual distros should be responsible for their own end-user support. May 20 14:40:41 We can rethink about completely shutting the tracker down if none of the devs have an interest when the open bug count is down below 100 or so May 20 14:40:47 Not sure that will ever happen ;-) May 20 14:41:16 pb_: I think Launchpad provides a good model May 20 14:41:26 Ubuntu users report their bugs to LP May 20 14:41:46 Those are getting sorted and either fixed in Ubuntu itself or reported upstream May 20 14:41:58 The OE situation is of course more complicated May 20 14:42:00 Except it needs people with the time/skipp to triage. May 20 14:42:02 is launchpad open source yet? May 20 14:42:11 don't think so May 20 14:42:16 (which Ubuntu doesn't have either, their actual responsiveness is pretty terrible. May 20 14:42:19 And I'm not advocating to use LP May 20 14:42:32 * XorA has taken to calling it brokenbuntu :-) May 20 14:42:37 it would be unreasonable for gumstix to point their customer at the OE bugtracker :) May 20 14:42:39 broonie: Like anything it depends on the area May 20 14:42:50 03Didier Ptitjes  07fso/milestone5.5 * ra1c4f2b004 10openembedded.git/recipes/freesmartphone/libfso-glib_git.bb: libgso-glib : add more files to the install May 20 14:43:18 crofton: that is OK. It would be nice if it was clearer how things are communicated from distro X to OE May 20 14:43:25 if they aren't fixed immediately May 20 14:43:47 That is the nice thing about LP. It can be marked as affecting Ubuntu, Debian and upstream May 20 14:44:02 Laibsch, not even people that do this for lots of money are good at these issues May 20 14:44:03 and the status is tracked individually for each of those May 20 14:44:23 We do pretty good at solving lots of problems May 20 14:44:24 I don't think we will ever get to paradise May 20 14:44:33 Crofton: Yes, agreed May 20 14:44:58 the reason bugtrackers are not popular in this community is because we do not have managers asking for reports :) May 20 14:45:10 Right now, I'd be unsure what to tell a user where to report a problem that needs triage May 20 14:45:25 Laibsch: I don't really have much of a view on launchpad versus other tools. But, I think the key thing is that the individual distro should (like Ubuntu in your case) be responsible for providing a mechanism for their users to file bugs, and also be responsible for triaging those bugs and either fixing them or escalating them as appropriate. May 20 14:45:26 I can become your OE manager ;-) May 20 14:45:44 pb_: My point exactly May 20 14:45:56 It used to be bugzilla.openembedded.org May 20 14:45:56 I'm not sure people want more managers :) May 20 14:46:01 New tools came about May 20 14:46:09 and now the situation needs to be rethought May 20 14:46:23 so bugtrackers that are not bugzilla or track? May 20 14:46:27 trac May 20 14:46:32 The only case in which it'd be appropriate for them to escalate a bug into the (putative) bugtracker for OE itself would be if the bug was due to some piece of OE infrastructure that they couldn't fix for themselves - say, for example, package.bbclass was broken in such a way that it accidentally inserted "Angstrom: sucks" into all the package headers. May 20 14:46:37 XorA: what is your question? May 20 14:46:57 Laibsch: is there any other working bug trackers apart from those two? May 20 14:47:01 pb_: I think there is more May 20 14:47:02 If it's "just" a problem with the recipe for some specific package, they ought to fix that and either check it in or file a patch in patchwork. May 20 14:47:05 pb_: did you manage to do a build with my patches? May 20 14:47:16 zecke: no, my bitbake blew up with a KeyError May 20 14:47:28 debbugs, though that's probably not good for the OE use case. May 20 14:47:31 zecke: it occurred to me later, though, that I might have had some stale .pyc files lying around. I'll try again later today. May 20 14:47:39 pb_: consider the case where something is broken (and maybe even a hackaround known) that affects other distros but where no obvious and immediate fix is at hand May 20 14:48:29 pb_: thanks, would be great to have that work on more than my machine May 20 14:48:45 Laibsch: the distros are welcome to talk to each other. if it isn't a defect in oe, per se, it shouldn't be in the oe bugtracker. after all, a large class of those problems (i.e. almost any upstream bug) probably affects way more distros than just ones based on oe. May 20 14:48:48 broonie: care to tell more about debbugs? May 20 14:49:05 Laibsch: The software behind the Debian BTS May 20 14:49:22 Oh, the mail-only thing? May 20 14:49:38 Laibsch: it would certainly make sense for distros to have a way of pooling their resources (a la launchpad, I guess) but I don't think we want OE to be the mediator for that. May 20 14:49:39 Hm, I've had my issues with the Debian BTS ;-) May 20 14:52:19 I think tinderbox could be a new, lean OE bug tracker May 20 14:52:57 Everything else that needs discussion -> OE ml, patchwork May 20 14:53:04 tinderbox does not really provide tracking, but is a good way to monitor build failures May 20 14:53:18 Laibsch: you won't see any runtime misbehaviours (missing libs,...) May 20 14:53:28 ant_work: that is distro support May 20 14:53:30 IMHO May 20 14:53:36 do we even need bug tracking? chances are if we see a bug we fix it, if users see a bug we dont May 20 14:53:41 even if due to wrong packaging? May 20 14:53:42 Crofton: It compiles! Ship it! May 20 14:53:47 YAY May 20 14:54:17 broonie: that's how people outside here are perceiving May 20 14:54:22 ant_work: in most cases yes, it's up to the distro to get their packaging right. May 20 14:54:29 XorA: some things need time and cannot be fixed immediately May 20 14:54:53 ant_work: and right now, that is not completely off-mark IMHO May 20 14:55:06 Everybody makes sure their own little thing works May 20 14:55:17 ant_work: Well, it's pretty accurate for a lot of things - it's kind of like the Ubuntu situation where a lot of stuff just runs along automatically and nobody ever actively gives it any TLC. May 20 14:55:22 Distro and end-user supprt is very tough May 20 14:55:40 yeah, I think an oe bug tracker would be a useful thing to have so long as it's restricted to oe core issues. May 20 14:55:45 I never got around to much more than "compiles, boy am I glad", that kept me pretty busy May 20 14:55:58 the mailing list doesn't do it for things that aren't being actively discussed, and patchwork doesn't help for things that don't have patches. May 20 14:56:23 pb_: I'm a great fan of trackers May 20 14:56:33 for example, I was suddenly reminded yesterday of this long-standing libgcc_s dependency thing (because zecke happened to trip over the piece of code in package.bbclass that was meant to fix it) May 20 14:56:33 but if the devs don't want it, you can't force them May 20 14:56:41 The mailing list does at least deal with the issue of expiring stuff nobody cares about. May 20 14:56:44 that bug still needs fixing, but I had forgotten about it because it fell out of my inbox. May 20 14:57:28 pb_: see, broonie got it: things falling off the radar is a feature, not a bug ;-) May 20 14:57:37 And there is some truths to it May 20 14:57:42 heh May 20 14:57:59 if no one touches a bug in a year delete it .... May 20 14:58:02 heh. well, that's a point of view, and it's probably largely true for distro things, but there is a whole pile of bitbake/oe core stuff for which that isn't really a feature. May 20 14:58:30 I wish I could more aggressively close bugs where the OP does not respond and that I can't reproduce. But I was scolded quite often when closing those bugs, despite nobody looking at them for years. May 20 14:58:48 there are quite a lot of bugs which are too hard to "just fix" at the point where you discover them, yet still significant enough that you don't want to forget about them altogether. May 20 14:59:50 pb: if you have some time, I'd love to get some help in the tracker. You, mickey and me (I see hrw combing through things from time to time as well) might be able to keep it alive May 20 15:00:11 pb_: The hope with those is that they're kept live by people caring. May 20 15:00:20 But yeah, nothing's ideal. May 20 15:00:27 But I agree with crofton and others that if a tool isn't used, one seriously needs to look at the why and possibly stop using it May 20 15:01:48 Laibsch: I do think that probably 99% of what's currently in the tracker shouldn't be, and that's the biggest single obstacle to me using it more. May 20 15:02:34 I would like to be able to get to my desk in the morning, go to bugzilla, and see (to some first approximation) a list of things that I can usefully work on. Whereas, right now, what I'm confronted with is a list of complaints that opie doesn't work on some zaurus that I've never heard of. May 20 15:02:56 pb_: good May 20 15:03:03 That should be the situation as I see it May 20 15:03:21 I think there are two reasons for it May 20 15:03:26 not being like May 20 15:03:38 a) the data is not triaged well enough May 20 15:04:23 b) the users don't know how to access that data (either general lack of knowledge about bugzilla or the way OE bugzilla is structured) May 20 15:04:36 Please tell me more about how to make it useful for you May 20 15:04:55 Are you using bugzilla searches to slice the data the way you want it? May 20 15:05:33 Do you think we have an appropriate way to collect machine specific bugs? May 20 15:06:10 Laibsch: c) bugzilla was initially feeded by zaurus users/devs May 20 15:06:25 yes May 20 15:06:39 so there are a lot of Z bugs May 20 15:06:45 we can close :) May 20 15:06:48 pb should be able to block those easily May 20 15:06:59 why close them? May 20 15:07:05 superceeded May 20 15:07:09 new versions May 20 15:07:12 new kernels May 20 15:07:21 Looking at Laibsch I get the impression that I should take some days off :) May 20 15:07:21 We should make sure people have an easy way to see only the bugs they consider important May 20 15:07:40 Laibsch: close as obsolete May 20 15:07:43 florian: to fix bugs? Yes, absolutely ;-) May 20 15:08:19 Laibsch: as XorA said, we need Turing test for bug-reporters :) May 20 15:08:27 ant_work: I'm all for closing bugs, but just because a new kernel is out does not mean something is fixed May 20 15:08:38 still noone would use the old May 20 15:08:40 one May 20 15:08:52 Try the roblem as described with the new kernel May 20 15:08:54 Laibsch: there doesn't currently seem to be any good way to search for the bugs I want, I think because they just aren't tagged in any way that marks them as particularly relevant to "core oe" rather than distributions. May 20 15:09:06 Laibsch: for example, bug 4464 is a bug that I am interested in (this is the libgcc_s thing I mentioned before) May 20 15:09:10 If it works close as invalid or WFM, standard practice May 20 15:09:30 pb_: very good point May 20 15:09:38 is linux-omap fetchable now? I get 'not a git repository' error when initially fetching May 20 15:09:43 and one I spent a bit of energy on during the last 24 hours May 20 15:09:59 I'm still unsure about the OE vs. distro divide May 20 15:10:19 Laibsch: but, if I search for bugs with similar metadata, I get things like #3545, which is "garbage on screen (doesn't reboot) a780 ezx3" May 20 15:10:28 Generally, I've made it now that OE: compile-time issue May 20 15:10:35 distro: issue with the binary May 20 15:10:41 But there is a bit of grey area May 20 15:10:59 and if it was purely about compile-time problems, tinderbox would be sufficient May 20 15:11:07 so, this is still unclear in my mind May 20 15:11:20 ... or #3678, "opie: cursor key rotation incorrect on some devices", or #2674, "touchscreen on n800 not working". those latter three are good examples of bugs that I don't want to see :-} May 20 15:11:48 pb_: try to concentrate on bugs with org.openembedded.dev in the future May 20 15:11:58 Laibsch: yeah, indeed. #4464 is a good example of a bug that doesn't actually cause a compile time failure so it wouldn't have shown up in tinderbox May 20 15:12:06 I have already started moving the ones you mentioned to Distribution May 20 15:12:14 okay, cool May 20 15:12:15 !oebug 4464 May 20 15:12:16 * * Bug 4464, Status: RESOLVED (FIXED), Created: 2008-08-01 05:28 May 20 15:12:17 * * raj.khem(AT)gmail.com: RRECOMMEND for libgcc in glibc/eglibc May 20 15:12:18 * * http://bugs.openembedded.net/show_bug.cgi?id=4464 May 20 15:12:35 Good May 20 15:13:05 I would have classified that as oe.dev probably so it would have stayed on your radar May 20 15:13:24 Jolly good. May 20 15:13:49 I'm wondering about bugs with patches or clear instructions of what people want changed May 20 15:14:12 So somebody wants a kernel config changed so his wifi is supported May 20 15:14:20 Is that OE or distro? May 20 15:14:32 I think it's OE May 20 15:14:43 * florian too May 20 15:14:46 but OTOH, many OE devs won't care about that, either May 20 15:14:48 Distro in the first instance, I think. After all, the patch might not be what the distro maintainers want even if it's well-formed. May 20 15:14:51 more importantly, who is going to make sure it doesn't break everything else .... May 20 15:15:03 yes May 20 15:15:25 yeah...about new recipes/open tickets ...all should now go on the ML...urgh May 20 15:15:29 send clear, well formed stuff to the dev list May 20 15:15:46 * ant_work foresees flood May 20 15:15:57 and please send them so git-am can apply them cleanly :) May 20 15:16:06 Crofton: that is one reason for a bug tracker, too. To make things clearer, to triage May 20 15:16:41 Überhacker can fix their own problems and send problem-free patches May 20 15:16:51 We need something for non-Überhackers, too ;-) May 20 15:17:44 Laibsch, even patches that need work are getting more comments on the list than they were in bugzilla May 20 15:18:02 We are doing a better job with patches coming to the list May 20 15:19:48 relatively speaking May 20 15:20:02 pb_: he.. I think bug 363 could be for you May 20 15:20:11 3 cypher bug! May 20 15:20:20 2005! May 20 15:20:25 bbl May 20 15:20:35 (any easy solution, btw ;) May 20 15:21:26 pb: If you see any bugs with component org.openembedded.dev (405 of them currently) that you consider to be a distro bug, feel free to change the component May 20 15:21:42 set distro to unspecified if necessary May 20 15:22:44 ant_work: yeah, I think the submitter is right that the device class probably wants overriding based on the machine type May 20 15:23:18 iirc opensuse had atool for setting the bits May 20 15:23:45 I would consider this a distro problem again :-) since they are best placed to know what machines need to work and how to deal with them, but oe itself probably could do better in terms of providing infrastructure. May 20 15:24:09 or add MACHINE_BT_CLASS May 20 15:24:17 or the like May 20 15:24:21 the easiest thing would just be to statically override it at compile time based on ${MACHINE}. that might not be sufficient for all distros, sinec there might be some where a runtime check is needed, but it'd be a start. May 20 15:24:49 pb: what you are saying sounds to me this ticket may need to be split May 20 15:24:57 one OE portion, one distro portion May 20 15:25:00 yeah, or that. I don't have a strong view about where the setting goes, either in the bluez package or in bitbake.conf would be ok. May 20 15:25:17 * Laibsch hasn't looked at the bug May 20 15:25:21 pb_: look at distro/mokoslug.conf May 20 15:25:30 I probably would not understand what's needed, either May 20 15:25:34 9 # Even though the NSLU2 does not have built-in bluetooth, May 20 15:25:36 20 # we assume that a MokoSlug gateway has a bluetooth dongle. May 20 15:25:41 he..distro choice May 20 15:25:48 03Koen Kooi  07org.openembedded.dev * rca79c209bd 10openembedded.git/ (conf/checksums.ini recipes/gstreamer/gstreamer_0.10.23.bb): gstreamer: add 0.10.23 May 20 15:25:50 03Koen Kooi  07org.openembedded.dev * rfce62e0990 10openembedded.git/ (2 files in 2 dirs): gst-plugins-base: update to 0.10.23 May 20 15:25:51 03Koen Kooi  07org.openembedded.dev * ra738277278 10openembedded.git/ (3 files in 2 dirs): gst-plugins-good: add 0.10.14 May 20 15:25:52 03Koen Kooi  07org.openembedded.dev * r94a24531ea 10openembedded.git/ (2 files in 2 dirs): gst-plugins-bad: update to 0.10.11 May 20 15:25:53 03Koen Kooi  07org.openembedded.dev * rdf308b8aa7 10openembedded.git/ (2 files in 2 dirs): gst-plugins-ugly: add 0.10.11 May 20 15:26:01 03Pratheesh Gangadhar  07org.openembedded.dev * r0c583bdba2 10openembedded.git/ (2 files in 2 dirs): xf86-input-evtouch: add driver for eGalax USB touchscreen May 20 15:26:04 ant_work: right! big ups to mokoslug for getting that correct. May 20 15:26:48 I'm not sure what the appropriate bluetooth class would be for a slug, but I guess there is one. May 20 15:26:54 :) May 20 15:26:56 "generic mollusc", maybe May 20 15:27:42 the term has a familiar assonance with sl#t May 20 15:27:52 s/familiar/infamous/ May 20 15:27:56 :d May 20 15:36:38 * XorA regains keyboard and monitor from server May 20 15:42:22 XorA: do you think -nostdinc -nostdlib -fno-builtin are all three needed for compiling kexec-tools static against klibc? I see thesing did not use '-nostdlib' for old version May 20 15:45:26 pb_: You may also want to exclude unconfirmed bugs May 20 15:46:05 This was different in the past, but bugs are now reported as unconfirmed and have to be confirmed first May 20 15:46:19 Okay, thanks. May 20 15:50:42 ant_work: no idea May 20 15:53:29 re May 20 15:55:10 XorA: np, thx May 20 15:55:14 hrw: wb May 20 15:58:07 * * OE Bug has been RESOLVED by jeremy.laine(AT)bolloretelecom.eu May 20 15:58:09 * * please include link to bug tracker on individual packages pages May 20 15:58:11 * * http://bugs.openembedded.net/show_bug.cgi?id= May 20 16:06:05 * * OE Bug 3122 has been REOPENED by May 20 16:06:07 * * bitbake gpephone-image fails on liblipsevent due to incorrect MD5/SHA256 checksums May 20 16:06:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3122 May 20 16:08:06 * * OE Bug 5106 has been created by  May 20 16:08:08 * * CIA hooks should only fire on org.OE.dev and org.OE.stable May 20 16:08:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5106 May 20 16:08:41 Laibsch: s+org.OE.stable+stable/2009+g May 20 16:08:56 hrw: I think you fixed the "/var/lib/python-support/python2.6/bb/COW.py:29: DeprecationWarning: the sets module is deprecated" warning somewhere, right? Is there a revision I can cherry-pick so it goes away for me, too? Actually, I'd probably push that to Jaunty, if it works May 20 16:09:35 hrw: Yes, will correct May 20 16:12:27 Laibsch: it was pushed to bitbake trunk, 1.8 and stable/2009 May 20 16:13:00 I'll look through the stable tree if I can pick out the changeset May 20 16:13:01 thanks May 20 16:13:07 5106 has been corrected May 20 16:30:11 lrg: ping May 20 16:30:14 hello! I am having some trouble building qt4... is there any "quick and dirt" guide to do it? May 20 16:30:45 hey mickeyl May 20 16:31:13 lrg: heya! long time no see. hope things are going well for slimlogic May 20 16:31:14 hi lrg May 20 16:31:22 hey pb_ May 20 16:31:33 mickeyl: things are busy ! May 20 16:31:44 whichis good May 20 16:32:07 * * OE Bug 4594 has been marked as DUPLICATE of bug 2181 by May 20 16:32:09 * * qte-mt-static-2.3.10-r8 do_configure failed May 20 16:32:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4594 May 20 16:32:16 zecke: I blew away my .pyc files and now your patches work much better :-) May 20 16:32:24 lrg: that's good to hear. say, i need a quick way to switch alsa scenarios, so i took a fresh look at libscenario. you have a different format to specify the profiles there. is this not compatible with the old formats? May 20 16:32:59 right now i'm still calling alsactl to switch scenarios May 20 16:33:11 i'd appreciate not having to rely and call that May 20 16:33:28 pb_: is it any faster? can you declare them to work? May 20 16:34:43 zecke: hard to say. it's not subjectively faster but it takes so long normally that this is not a reliable way of judging :-} May 20 16:34:51 I'll do some actual measurements presently. May 20 16:35:02 mickeyl: spyro did some work on scenario last month. It's best to checkout the latest from git. The formats do differ due to no dependency on alsa-lib (i.e. we can build against salsa) May 20 16:35:23 pb_: should be close to 20% faster when parsing :) May 20 16:35:25 it's simpler to parse and write too May 20 16:35:31 zecke: jolly good :-) May 20 16:35:31 lrg: so would you recommend converting the formats? May 20 16:35:36 lrg: and then using libscenario? May 20 16:35:58 pb_: you can cut some seconds by changing lib/bb/cache.py:sync to use copy.copy instead of copy.deepcopy :) May 20 16:36:05 yeah, please load each with alsactl and then dump with scenario tools May 20 16:36:28 lrg: ok, great. i'll give that a try. thanks May 20 16:37:12 mickeyl: np, you should be able to link against it too (rather than call scripts) May 20 16:37:44 yeah. as I'm using Vala i'll write a .vapi for it May 20 16:37:46 * pb_ go home now May 20 16:37:48 later all May 20 16:38:01 later pb_ May 20 16:38:04 pb___: cu May 20 16:38:09 So, about the qt4-x11 recipe, isn't it supposed to have a "stage" task? May 20 16:38:33 when I try to compile it, I get errors related to missing tools (qmake and rcc) May 20 16:39:02 but I can't stage it (no such task) May 20 16:48:27 hi Liam May 20 16:52:40 hmm, also I have a checksum failure when trying to fetch qt4-tools-native_4.5.0.bb... May 20 17:01:07 zerum: Take a look at tinderbox May 20 17:01:11 ~tinderbox May 20 17:01:12 i heard tinderbox is mozilla.org's system for making sure the build tree doesn't catch on fire May 20 17:01:21 hm, not quite May 20 17:01:33 http://tinderbox.openembedded.org May 20 17:02:20 hmm May 20 17:03:49 bye all May 20 17:05:38 ok, I see it working on tinderbox, I wonder where I got wrong? May 20 17:08:33 zerum, checksum problem May 20 17:08:42 md5sum the version you downloaded May 20 17:08:51 k, waitasec May 20 17:08:52 and check against another download May 20 17:08:57 maybe you had a bad download May 20 17:10:06 Crofton: I got the error on the fetch task for the file ftp://ftp.trolltech.com/qt/source/qt-embedded-linux-opensource-src-4.5.0.tar.bz2 (wanted: ftp://ftp.trolltech.com/qt/source/qt-embedded-linux-opensource-src-4.5.0.tar.bz2 Got:5ba910df2ef20c6ce0e707fce0d952c5) May 20 17:10:32 agh, sorry, bad copypaste. wanted: 3bd081c940c8580ecaabc1bd898e48f0 got: 5ba910df2ef20c6ce0e707fce0d952c5 May 20 17:11:04 hmm, wget can't find that tarball May 20 17:11:16 oh wait, tinderbox mentions version 4.5.1! I'm outdated, apparently May 20 17:11:17 my bad May 20 17:11:21 bad cut/paste May 20 17:11:39 Hey guys. I'm a newbie here, but from what I've seen Open Embedded is pretty awesome stuff. Instead of hitting the mailing list, I thought I'd try to ask the question here first: has anyone added support for the Compulab cm-x300 yet? I can't seem it find it anywhere in git, but noticed that it was a build target in tinderbox. May 20 17:12:33 I don't have any 4.5.1 recipes... a git update will solve it? May 20 17:13:35 it is possible someone has a local copy they are working on May 20 17:14:44 hmm, try update May 20 17:15:26 heh, the only 4.5.0 entry on tinderbox is for a do_clean one :) May 20 17:15:43 03Denys Dmytriyenko  07org.openembedded.dev * ra8d4115fbb 10openembedded.git/ (2 files in 2 dirs): May 20 17:15:43 dm6467-evm: add new machine definition and defconfig May 20 17:15:43 Signed-off-by: Denys Dmytriyenko May 20 17:15:44 03Denys Dmytriyenko  07org.openembedded.dev * r29e403d69d 10openembedded.git/ (3 files in 2 dirs): May 20 17:15:44 dm6446-evm: rename machine from davinci-dvevm and add defconfig May 20 17:15:48 Signed-off-by: Denys Dmytriyenko May 20 17:15:50 zerum: what package? May 20 17:15:50 03Denys Dmytriyenko  07org.openembedded.dev * r12ef441b1d 10openembedded.git/conf/machine/dm365-evm.conf: May 20 17:15:53 dm365-evm: add new machine definition May 20 17:15:54 zerum: I can try here May 20 17:15:55 kernel support is on the way May 20 17:15:57 Signed-off-by: Denys Dmytriyenko May 20 17:15:59 03Denys Dmytriyenko  07org.openembedded.dev * r7b8817cca3 10openembedded.git/ (2 files in 2 dirs): May 20 17:16:02 dm355-evm: add new machine definition and defconfig May 20 17:16:04 Signed-off-by: Denys Dmytriyenko May 20 17:16:06 03Denys Dmytriyenko  07org.openembedded.dev * r104812c76e 10openembedded.git/conf/machine/include/davinci.inc: May 20 17:16:09 davinci.inc: add common DaVinci machine configuration May 20 17:16:11 Signed-off-by: Denys Dmytriyenko May 20 17:16:13 03Denys Dmytriyenko  07org.openembedded.dev * rdd0a39d7d9 10openembedded.git/conf/machine/dm357-evm.conf: May 20 17:16:18 zerum, btw, I dl'd the tarball and got the checksum as 3bd081c940c8580ecaabc1bd898e48f0 May 20 17:16:20 dm357-evm: add new machine definition May 20 17:16:22 kernel support is on the way May 20 17:16:24 Signed-off-by: Denys Dmytriyenko May 20 17:16:26 03Denys Dmytriyenko  07org.openembedded.dev * r6931147374 10openembedded.git/recipes/linux/ (linux-davinci_2.6.28.bb linux-davinci_git.bb): May 20 17:16:29 linux-davinci: build linux-davinci kernels for dm6446, dm6467 and dm355 EVMs May 20 17:16:31 Signed-off-by: Denys Dmytriyenko May 20 17:16:35 03Denys Dmytriyenko  07org.openembedded.dev * rf0bc88f537 10openembedded.git/recipes/u-boot/u-boot_git.bb: May 20 17:16:38 which matches the checksum it wanted May 20 17:16:38 u-boot: update git recipe with the new DaVinci EVMs May 20 17:16:40 Crofton: ????? May 20 17:16:40 Signed-off-by: Denys Dmytriyenko May 20 17:16:44 so I think you have a bad tarball May 20 17:16:50 Now I'm puzzled... May 20 17:16:52 yep May 20 17:17:01 your copy of the source is bad May 20 17:18:11 * Laibsch only has 4.5.1 May 20 17:19:20 Laibsch: The recipe is qt4-X11-free_4.5.0.bb May 20 17:19:23 hm May 20 17:19:30 yep, I NEED to update :) May 20 17:19:38 git pull, maybe May 20 17:19:44 k May 20 17:20:09 not available in my git tree May 20 17:20:48 git pulling now May 20 17:22:48 still nothing, I'm on branch stable/2009... should I change? May 20 17:24:31 zerum, copy the files from .dev May 20 17:24:33 or change May 20 17:25:58 03Koen Kooi  07org.openembedded.dev * r92675b9b59 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorter: add support for SDKs, x86_64 and new TI machines May 20 17:29:01 yep, I see that .dev has it... May 20 17:30:03 Crofton: Another question... can bitbaker have catched the bad tarball? Aparently, it is not re-downloading it, even afte a do_clean May 20 17:30:21 you'll need to remove it from the sources dir May 20 17:30:41 ah! May 20 17:33:10 yep, found it, bad checksum and everything, Thanks! May 20 17:34:54 ahhh, wait, I removed it, but that's not all... now bitbaker says the file is missing! May 20 17:35:13 did you remove the .mdt file also? May 20 17:35:50 nope :) May 20 17:36:28 okay, download started! May 20 17:45:31 this is to build 4.5.0 in stable? May 20 17:54:46 i followed out the instructions at opendreambox ,make image created among others a crosscompiling toolchain at opendreambox/dm500plus/build/tmp/cross .I sourced the env.source file and tried using the crosscompiler by doing powerpc-gcc -o hello helloworld.c but the program segfaults on the host.any ideas on what may be wrong? May 20 17:55:07 powerpc-ld also says powerpc-linux-ld: warning: cannot find entry symbol _start; not setting start address May 20 17:55:16 which sounds suspicious May 20 17:57:19 i mean hello segfaults when run on a real host May 20 17:59:30 im a complete newbie to this so any ideas /pointers are welcome May 20 18:17:42 hi guys. i have a board here with a set of patches which I've diffed.. I'm trying to figure out how I should set virtual/kernel preference and what the files need to be called. the kernel needs to be 2.6.28.10 with these patches applied alone but it seems to try and build 4 different kernels regardless May 20 18:26:31 Neko: use linux_2.6.28.bb recipe as base and add your machine into it. May 20 18:27:10 it will automatically bring it to .10? May 20 18:27:28 I was looking at the ixp4xx-2.6.23.14 stuff and it does stuff very differently.. May 20 18:27:35 no, but you can add .10 patch to your patchset May 20 18:27:43 Neko: use linux_2.6.28.bb as base May 20 18:27:55 I started from there.. but now what :] May 20 18:27:56 Neko: ixp4xx kernels are specific May 20 18:28:33 Neko: loook at SRC_URI_append lines May 20 18:29:19 right I added SRC_URI_append_myboard and added the diff May 20 18:29:25 I need to add the .10 patch too before that right? May 20 18:29:47 yes May 20 18:31:38 DEFAULT_PREFERENCE_myboard = "1" .. there are boards in there where it is set to 28 though, what does that mean? May 20 18:31:50 value can be any May 20 18:32:10 those boards which have 28 use kernel version as preference. May 20 18:32:13 hi kergoth May 20 18:32:32 hey May 20 18:32:52 okay so my PREFERRED_PROVIDER_virtual/kernel = "linux-2.6.28.10" ? May 20 18:33:02 "linux-2.6.28" even? May 20 18:33:20 and machine will be appended and it will magically build that one and only that one? May 20 18:33:42 no May 20 18:33:52 "linux" is pref-prov for it May 20 18:34:03 no need to set version when only one is used May 20 18:35:31 okay I think I'm set, thanks May 20 18:53:28 03Angus Ainslie  07fso/milestone5.5 * r09d89cf132 10openembedded.git/recipes/netbase/netbase_4.21.bb: netbase : bump pr to get interfaces file changes May 20 18:53:35 03Angus Ainslie  07fso/milestone5.5 * r06e540c0fd 10openembedded.git/recipes/busybox/busybox_1.13.2.bb: busybox : bump pr to get config changes May 20 19:11:48 bye May 20 19:28:16 hm...why is git pull asking for a password? May 20 19:29:12 er May 20 19:29:18 you didn't read your email May 20 19:29:29 we switched git to a new machine a 3PM May 20 19:29:39 and are in DNS hades at them moment May 20 19:29:53 and I am in Beagle hades May 20 19:29:58 since mine is not booting May 20 19:37:14 Crofton: Not sure what hades means, but I guess it is not good May 20 19:37:26 Will the new server have a new fingerprint? May 20 19:38:50 cbrake, can you answer that one May 20 19:39:39 Laibsch: ssh fingerprint? May 20 19:39:46 yes May 20 19:39:52 Laibsch: yes, it currently does May 20 19:39:53 the one that git uses May 20 19:40:09 can't we carry it over? May 20 19:40:26 Laibsch: do you know offhand which files? May 20 19:40:31 no May 20 19:40:37 Laibsch: I assume global ssh keys on the system May 20 19:40:37 under /etc/ssh May 20 19:40:45 it will be the ssl certificates May 20 19:40:50 Let me check my server May 20 19:42:03 cbrake: http://rafb.net/p/xiZuxp95.html May 20 19:42:11 I think that is what you want to copy May 20 19:42:16 I can verify later May 20 19:43:23 ewww, dont do that :-) May 20 19:44:08 That's really rather evil. We moved the server; let the records (and the keys) show it. May 20 19:44:48 you would need to check with mickey May 20 19:45:10 he might not want another server using his server's id May 20 19:47:26 just dont do it, its the wrong thing to do May 20 20:23:06 * * OE Bug 5109 has been created by  May 20 20:23:08 * * ected build-time dependencies May 20 20:23:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5109 May 20 20:24:49 03Cliff Brake  07org.openembedded.dev * r9364f70fc6 10openembedded.git/conf/machine/cm-x270.conf: test commit to new server May 20 20:25:06 * * OE Bug 5110 has been created by  May 20 20:25:08 * * ffmpeg build-depends on GSM stuff May 20 20:25:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5110 May 20 20:44:52 Crofton: I actually cloned from .org a couple of days ago...thinking it was already the new server May 20 20:45:06 * * OE Bug 5111 has been created by  May 20 20:45:08 * * opie-image build-depends on fso-gsm0710muxd May 20 20:45:09 new.blah is solving atm, however May 20 20:45:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5111 May 20 20:45:19 * * OE Bug 5110 has been RESOLVED (INVALID) by May 20 20:45:21 * * ffmpeg build-depends on GSM stuff May 20 20:45:23 * * http://bugs.openembedded.net/show_bug.cgi?id=5110 May 20 20:45:53 ant__, it resolves for cbrake already May 20 20:45:58 not for me though May 20 20:46:41 not for me either May 20 20:47:17 heh May 20 20:47:23 is git locked during the move? May 20 20:47:37 I suspect we have upstream DNS servers that exceed ttl caching May 20 20:47:50 denix, amethyst is not running at all May 20 20:47:58 so you can only commit to the new server May 20 20:48:07 so basically, it is locked May 20 20:48:18 .org is working here. May 20 20:48:19 what about old cgit? May 20 20:49:11 I think it still displays May 20 20:49:17 looks like I have new cgit here May 20 20:49:28 yep May 20 20:50:58 cbrake, Crofton et al: thanks for taking care of this move! May 20 20:52:00 denix: sure, let us know of any problems May 20 20:52:45 I left git-dameon running on amethyst so you can still pull from git.oe.net, but ssh+git is disabled on git.oe.net now May 20 20:52:48 cbrake, did all the work, I pointed and clicked on a web form May 20 20:54:17 ultimately, I hope we can get a server installed at OSU May 20 20:59:26 ok, my DNS is now updated and new addresses resolve fine May 20 21:05:40 is there a problem with the git server ? May 20 21:05:54 not for much longer May 20 21:06:02 hehe ok May 20 21:06:04 we moved it and DNS needs to update May 20 21:06:12 should happen soon, already works for some May 20 21:06:21 make sure you are using the .org name May 20 21:06:34 good , the other possibility was my key being removed :) May 20 21:06:44 heh May 20 21:06:47 no :) May 20 21:07:51 03Angus Ainslie  07fso/milestone5.5 * rd1741ee889 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: paroli : add the git version to __version__.py May 20 21:08:19 thx working now May 20 21:11:16 so, was there any agreement with mickey on .net? May 20 21:11:41 it has been mentioned, not sure if anyone asked him directly May 20 21:25:28 03Pratheesh Gangadhar  07xora/angstrom-srcpv * r0c583bdba2 10openembedded.git/ (2 files in 2 dirs): xf86-input-evtouch: add driver for eGalax USB touchscreen May 20 21:25:30 03Koen Kooi  07xora/angstrom-srcpv * rfce62e0990 10openembedded.git/ (2 files in 2 dirs): gst-plugins-base: update to 0.10.23 May 20 21:25:30 03Koen Kooi  07xora/angstrom-srcpv * rca79c209bd 10openembedded.git/ (conf/checksums.ini recipes/gstreamer/gstreamer_0.10.23.bb): gstreamer: add 0.10.23 May 20 21:25:31 03Koen Kooi  07xora/angstrom-srcpv * r94a24531ea 10openembedded.git/ (2 files in 2 dirs): gst-plugins-bad: update to 0.10.11 May 20 21:25:34 03Koen Kooi  07xora/angstrom-srcpv * rdf308b8aa7 10openembedded.git/ (2 files in 2 dirs): gst-plugins-ugly: add 0.10.11 May 20 21:25:37 03Denys Dmytriyenko  07xora/angstrom-srcpv * r104812c76e 10openembedded.git/conf/machine/include/davinci.inc: May 20 21:25:40 davinci.inc: add common DaVinci machine configuration May 20 21:25:42 Signed-off-by: Denys Dmytriyenko May 20 21:25:44 03Denys Dmytriyenko  07xora/angstrom-srcpv * ra8d4115fbb 10openembedded.git/ (2 files in 2 dirs): May 20 21:25:47 dm6467-evm: add new machine definition and defconfig May 20 21:25:49 Signed-off-by: Denys Dmytriyenko May 20 21:25:51 03Denys Dmytriyenko  07xora/angstrom-srcpv * r29e403d69d 10openembedded.git/ (3 files in 2 dirs): May 20 21:26:00 dm6446-evm: rename machine from davinci-dvevm and add defconfig May 20 21:26:02 Signed-off-by: Denys Dmytriyenko May 20 21:26:04 03Denys Dmytriyenko  07xora/angstrom-srcpv * r7b8817cca3 10openembedded.git/ (2 files in 2 dirs): May 20 21:26:07 dm355-evm: add new machine definition and defconfig May 20 21:26:09 Signed-off-by: Denys Dmytriyenko May 20 21:26:11 03Koen Kooi  07xora/angstrom-srcpv * ra738277278 10openembedded.git/ (3 files in 2 dirs): gst-plugins-good: add 0.10.14 May 20 21:26:14 03Denys Dmytriyenko  07xora/angstrom-srcpv * r12ef441b1d 10openembedded.git/conf/machine/dm365-evm.conf: May 20 21:26:17 dm365-evm: add new machine definition May 20 21:26:19 kernel support is on the way May 20 21:26:21 Signed-off-by: Denys Dmytriyenko May 20 21:26:23 03Denys Dmytriyenko  07xora/angstrom-srcpv * rdd0a39d7d9 10openembedded.git/conf/machine/dm357-evm.conf: May 20 21:26:47 dm357-evm: add new machine definition May 20 21:26:47 kernel support is on the way May 20 21:26:47 Signed-off-by: Denys Dmytriyenko May 20 21:26:47 03Koen Kooi  07xora/angstrom-srcpv * r92675b9b59 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorter: add support for SDKs, x86_64 and new TI machines May 20 21:26:48 03Cliff Brake  07xora/angstrom-srcpv * r9364f70fc6 10openembedded.git/conf/machine/cm-x270.conf: test commit to new server May 20 21:26:51 03Graeme Gregory  07xora/angstrom-srcpv * r1193edfbb5 10openembedded.git/: May 20 21:26:53 Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.org/openembedded into xora/angstrom-srcpv May 20 21:26:55 Conflicts: May 20 21:26:57 recipes/linux/linux-davinci_git.bb May 20 21:26:59 recipes/u-boot/u-boot_git.bb May 20 21:27:01 (6 lines omitted) May 20 21:30:19 I guess the new server works :-) May 20 21:31:47 yeah May 20 21:31:57 went fairly well so far May 20 21:32:05 * * OE Bug 5112 has been created by solar.george(AT)googlemail.com May 20 21:32:07 * * package-qa on gthumb image viewer fails due to .debug directories in non -dbg packages May 20 21:32:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5112 May 20 21:41:05 03Angus Ainslie  07fso/milestone5.5 * r6a56fc23cc 10openembedded.git/recipes/initscripts/initscripts_1.0.bb: initscripts : run sysfs before g_ether May 20 21:42:12 * XorA finds the zaurus schematics on his HD May 20 21:42:24 * kergoth chuckles May 20 21:43:19 * XorA forgot all about them May 20 21:44:12 * kergoth has no idea if he even has any of that stuff anymore.. someday he should really adopt some sort of backup strategy.. May 20 21:44:17 denix: I would vote to decommission the oe.net URI's so we don't have to go through the hassle every time we change IPs May 20 21:44:42 ant__: ping May 20 21:45:50 we should certainly try to make sure people can't find them :) May 20 21:46:18 the oe.net stuff should either automatically and transparently redirect to .org, or they should die in a fire May 20 21:48:25 XorA: pong May 20 21:48:37 yeah May 20 21:48:50 now that we have moved it I'll talk to mickey May 20 21:49:07 I'll have him CNAME them May 20 21:49:14 ant__: want some manuals May 20 21:49:31 always, thx :) May 20 21:49:38 we'll likely need to setup the new server to accept the .net's since I think that is what the CNAME will look liek May 20 21:50:00 and with a CNAME, he won't need to touch them if we change .org May 20 21:50:05 I hope May 20 21:50:07 guh, I'm losing track of what's what in all my collections May 20 21:50:14 ant__: how do you want them? May 20 21:50:19 too many in too many states, and losing track of what I've pushed up and what i haven't May 20 21:50:21 how big? May 20 21:50:27 the trouble is if the .net URIs work, people will keep using them, but with CNAME I suppose that is ok May 20 21:50:41 ant__: 8.1M May 20 21:50:46 yeah, we still need to not pucliosh then May 20 21:50:54 gmail? or give a url, pls May 20 21:50:58 I know hrw has a lot of repos that go through .net May 20 21:51:38 later May 20 21:51:42 gn May 20 21:51:53 bye Crofton May 20 21:52:16 bye cbrake_away ..ah tab completion... May 20 21:53:33 XorA: if you have the tosa around, pls tell me about output of 'nandlogical /dev/mtd1 READ 0x60014 0x4 fsro.bin' (is byte swapped) May 20 21:57:13 ant__: remind me about that some other time May 20 21:57:27 np May 20 22:09:52 <_Lucretia_> od May 20 22:12:26 any programmers around that have worked with aio_write()? May 20 22:27:26 03Koen Kooi  07stable/2009 * r9b153380b8 10openembedded.git/ (3 files in 2 dirs): May 20 22:27:26 kernel, module-base class, bitbake.conf: introduce MACHINE_KERNEL_PR May 20 22:27:26 Acked-by: Denys Dmytriyenko May 20 22:27:26 Acked-by: Otavio Salvador May 20 22:27:26 Signed-off-by: Koen Kooi May 20 22:56:58 hm.. here qemu issues.. May 20 22:57:01 NOTE: preparing tree for binary locale generation May 20 22:57:02 NOTE: generating locale es_NI (UTF-8) May 20 22:57:02 qemu-arm version 0.9.1, Copyright (c) 2003-2008 Fabrice Bellard May 20 22:57:02 usage: qemu-arm [options] program [arguments...] May 20 22:57:02 Linux CPU emulator (compiled for arm emulation) May 20 22:57:44 go apply roman's patch and try again w/ 0.10.3 May 20 22:58:11 yep, thought was pushed May 20 23:03:11 Tartarus: btw, only here issues with git & whitespaces? May 20 23:03:13 warning: squelched 7 whitespace errors May 20 23:03:13 warning: 12 lines applied after fixing whitespace errors. May 20 23:03:33 git am -3 oe-1-2-qemu-0.10.3-port-OE-patches-make-preferable-version-1.patch --whitespace=fix May 20 23:03:45 some magic setting? May 20 23:04:16 dunno, sorry May 20 23:04:18 these seems created when you patch sources May 20 23:06:28 Tartarus: is building anyway, thx May 20 23:18:37 good night May 20 23:19:52 what's the proper way to build kernel from a different recipe w/o overwriting PREFERRED_PROVIDER_virtual/kernel for the machine? May 20 23:21:33 what do you mean, deni? May 20 23:21:44 bitbake somerecipe :P May 20 23:22:00 right, and that usually works for non-kernel recipes May 20 23:22:21 i did notice that bibake isn't smart about mulutiple providers and user requested providers May 20 23:22:39 if i "bitbake foo" and foo is one of two providers of bar, it doesn't interpret my request to build foo as a preference May 20 23:22:47 so itll happily chug along and build both, if the other wouldve been the default preference May 20 23:22:48 with kernel there is a dependency on kernel-image, kernel-vmlinux etc., so when I try bitbake linux-other, it complains that both my regular kernel and this one provide the same May 20 23:22:52 thats a bug, in my opinion May 20 23:22:59 denix: ah, sounds like you're hitting what i just described :) May 20 23:23:14 yeah, someone else also mentioned it on the list... May 20 23:24:15 you'd think itd be easy to fix, just look at the user specified providers to build + BBPKGS and interpret those as preferences.. but i dont know that part of the bitbake code at all, so.. :) May 20 23:24:30 maybe ask richard, he'd probably be the one to at least get a pointer from on how/where to implement that functionality May 20 23:26:13 sounds like a plan... :) May 20 23:26:16 thanks! May 20 23:40:33 I think I mentioned this (yes, bug, imho) on the list once. May 20 23:41:14 * kergoth got bit by it a while back trying to explicitly build one of the x servers, and it went and built both May 20 23:42:31 Also, I had once RFC'd this: "[RFC] Stop on multiple providers but none explicitly specified" May 20 23:42:38 ah May 20 23:42:59 probably before i came back to the OpenEmbedded universe :) May 20 23:46:49 Two years ago on April 17th, 2007: "deterministic OE builds - multiple providers". Also I showed the kernel recipe problem there. May 20 23:47:16 sheesh May 20 23:47:26 sad that we don't have more people that hack on bitbake itself May 20 23:47:30 LOL: I was just typing: Sjeesh. Time flies. May 20 23:47:43 when I saw your sheesh come in :-) May 20 23:47:49 :) May 20 23:48:34 kergoth: I once added regex expression support to stop -g early. That was my last effort/try :-) May 20 23:48:52 (it never got merged btw, yes we are short on devs) May 20 23:49:46 well, most OpenEmbedded contributers aren't about improving the core, they're about hacking it into accomplishing their goals, and leaving it at that May 20 23:49:52 which is kind of unfortunate, but is the nature of open source May 20 23:50:43 yes, I usually try both here, but for the core, I need someone to look along, ack, or nak, or improve on my stuff. May 20 23:51:19 I'm never confident committing to a core class or bitbake without at least getting approval on one or two others familiar with the core. the potential impact of breakage is just too high May 20 23:51:21 So instead of trying to fix bitbake graph stuff, I now work around it: openembedded.git/contrib/dependsgraph/dependsgraph.sh ---- It's me giving up on my python efforts. May 20 23:52:08 kergoth: same here, although that's mainly toolchains I touch then. bitbake it too much python for a C programmer May 20 23:52:15 heh May 20 23:52:15 s/it/is May 20 23:52:27 * kergoth 's getting pretty comfortable with python... only took years.. ;) May 20 23:53:18 the problem is, I only use it for bitbake, I just haven't got other uses. (And I admit, when my bash scripts become more than 50 lines, I turn to C, not python) May 20 23:53:52 So I'm mildly interested in a C rewrite of bitbake :-) May 20 23:54:01 heh, I also want to get more comfortable with python, not there yet May 20 23:54:40 btw, what that dependsgraph is about? May 20 23:54:44 But first, vectored i/o to a pci express device. May 20 23:54:59 denix: Read on bitbake -g May 20 23:55:17 I know bb -g May 20 23:55:31 but you mentioned some .sh script - what's that? May 20 23:55:38 it is (was?) broken. Look at the .dot file. May 20 23:55:44 question, when is perl-native used? just for the target perl build? May 20 23:56:30 kergoth: I think some packages need a (native) perl in their build environment, not sure if it's *only* perl... May 20 23:57:18 kergoth: More, see grep -rn -e "DEPENDS" openembedded.git/ | grep python-native May 20 23:57:39 (yes, that can be a single grep, I'm lazy :-) ) May 20 23:58:03 well, we have lots of perl scripts that are still relying on the build machine's perl May 20 23:58:09 so where's the line, when do you need it? May 20 23:58:41 kergoth: I think people found out their host version of perl was too old or didn't match, or wasn't installed. May 20 23:58:51 (I hope the latter, that's the best test) May 20 23:59:10 meh, inconsistency is bad, either perl-native should be used only for target perl, or it should be used for all our perl scripts May 20 23:59:18 not both :P May 20 23:59:34 about bitbake, is there an easy way to find out what tasks are avilable for a given recipe? May 20 23:59:41 kergoth: agreed, but we still need to know IF it's used at all May 20 23:59:46 zerum: bitbake -c listtasks foo May 20 23:59:56 thx! May 21 00:00:07 likewise: it's definately used for the target perl, the same way python-native is usedf or the target python, because it has to be the same version, afaik May 21 00:00:17 but beyond that, /shrug May 21 00:00:25 kergoth: what would you suggest? May 21 00:00:57 my first inclination would be to kill all perl-native deps other than for the perl crosscompilation, and see what explodes in a test build May 21 00:01:01 maybe i'll add that to my todo.. May 21 00:01:01 kergoth: what "perl scripts <...> are still relying on the build machine's perl"? May 21 00:01:12 * kergoth shrugs May 21 00:01:18 wonder who's maintaining the perl stuff May 21 00:01:36 heh, this is open-source :-) May 21 00:02:18 heh :) May 21 00:02:30 * kergoth still thinks we need more individual responsibility for recipes and classes, somehow May 21 00:16:27 I think the best way is to have a few groups, like the toolchain group, which have a focus. Not necessarely one individual per recipe; that won't work. May 21 00:17:25 So you want "Less Loosely Knit Hackers" :-) May 21 00:21:14 thatd work too, i just want actual responsibility May 21 00:21:26 so you dont just break something and move on to other things May 21 00:21:38 if I'm responsible for autotools, and it breaks, i want people to yell at me about it May 21 00:22:05 right now breakage is just fixed by whomever happens to feel like fixing it, but I'd be a lot more confident in fixes if they were done by those most familiar with those recipes or classes May 21 00:22:18 less likely to introduce unrelated issues May 21 00:36:11 03Rolf Leggewie  07org.openembedded.dev * r4e16e01337 10openembedded.git/conf/checksums.ini: checksums.ini: add entry for an AVR32 u-boot patch. (Closes: #4804) May 21 00:38:06 * * OE Bug 4804 has been RESOLVED (FIXED) by May 21 00:38:08 * * Some more checksums missing May 21 00:38:10 * * http://bugs.openembedded.net/show_bug.cgi?id=4804 May 21 00:55:49 good night all May 21 00:55:58 night May 21 01:12:05 * * OE Bug 5115 has been created by  May 21 01:12:07 * * include information about unshipped files in QA log May 21 01:12:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5115 May 21 01:25:11 hm, for some reason, bibake don't recognize the 4.5 version of qtx11, although the recipe file is there. May 21 01:42:20 hmmm even though I set up a 2.6.28.10 recipe based on 2.6.28.bb and my patchset, it still is mentioning 2.6.28-r6 a lot in bitbake build messages May 21 02:19:49 did you set PV in the recipe ... **** ENDING LOGGING AT Thu May 21 02:59:57 2009