**** BEGIN LOGGING AT Wed Jan 31 02:59:59 2007 Jan 31 06:12:14 question: creating a bb file, how do I make pkgconfig happy? configure script fails because it's lacking the .pc files for dependencies; I can hardcode them in but that's ugly Jan 31 06:13:03 hey Jan 31 06:13:11 howdy Jan 31 06:13:11 i accidently turned my brightness to 2 Jan 31 06:13:19 how can i see anything again? Jan 31 06:13:21 oh yeah, that's fun Jan 31 06:13:26 so what I do is Jan 31 06:13:31 guess where the slider is and slide it up Jan 31 06:13:49 yeah Jan 31 06:13:51 i was hasty Jan 31 06:14:01 and exited that section in the lag for it to take effect Jan 31 06:14:13 hmmm Jan 31 06:14:16 no clue Jan 31 06:14:19 :-( Jan 31 06:14:28 could you ssh in? Jan 31 06:14:35 and do what? Jan 31 06:14:36 is the netowrk on? Jan 31 06:14:42 well ssh in with tunnelling Jan 31 06:14:42 yes Jan 31 06:14:49 and run the brightness applet Jan 31 06:17:05 uh Jan 31 06:17:09 i don't think i had ssh on Jan 31 06:17:11 it won't login Jan 31 06:17:19 damn Jan 31 06:17:27 can you bring up a terminal some how Jan 31 06:17:35 and type in the necessary commands to bringup net and ssh? Jan 31 06:17:38 without display? Jan 31 06:17:50 no way Jan 31 06:18:03 i don't know what i've already pressed Jan 31 06:18:09 trying to open the applet again Jan 31 06:18:10 :-( Jan 31 06:19:27 anyone else here? Jan 31 06:19:36 this is sort of urgent Jan 31 06:19:59 wait Jan 31 06:20:07 isn't there some hardware way to change brightness? Jan 31 06:20:10 it'd be model dependnet Jan 31 06:20:20 don't think so Jan 31 06:20:30 o fuck yes Jan 31 06:20:32 there is! Jan 31 06:20:38 Fn+4 Jan 31 06:20:44 it didn't work in opie Jan 31 06:20:49 but, works in gpe! Jan 31 06:21:20 score Jan 31 06:28:08 what music prgs are there? Jan 31 06:37:01 *yawn* Jan 31 06:37:01 morning Jan 31 06:38:51 morning :) Jan 31 06:43:50 we have a wooden door and during the winter months this door can hardly be closed without making a "booom" if you don't use the keys Jan 31 06:44:15 now my wife gets up 3 hours earlier than me and is always so tight on time that she can't use the keys but just throws it close Jan 31 06:44:20 *sigh* Jan 31 06:44:22 and i wake up Jan 31 06:44:52 03mickeyl 07org.oe.dev * raa1a3c4c... 10/ (3 files in 3 dirs): vorbis-tools 1.0.1 remove deprecated curl option. fixes #1835 Jan 31 06:44:57 03mickeyl 07org.oe.dev * rc28ceb30... 10/ (1 packages/js/js_1.5.bb): js 1.5 fix SRC_URI Jan 31 06:48:33 03mickeyl 07org.oe.dev * r438ff402... 10/ (1 conf/distro/generic.conf): generic.conf: remove armisms Jan 31 06:48:36 03mickeyl 07org.oe.dev * re063b978... 10/ (1 conf/distro/include/sane-srcdates.inc): sane-srcdates.inc: add libmatchbox and libfakekey Jan 31 06:50:50 * mickeyl reduing diff from .dev to .mickey Jan 31 06:50:53 reducing, even Jan 31 07:20:31 * koen_ gets annoyed with people incapable of following advice Jan 31 07:22:15 you mean zecho wang? Jan 31 07:23:49 i'm becoming sensitive to everything that comes from .cn. It's really a whole different culture and their way of tackling problems is totally different from ours. Jan 31 07:24:26 it took me literally months to get them starting to communicate Jan 31 07:24:30 not just with me Jan 31 07:24:32 but also with each other Jan 31 07:24:41 let alone using tools like mailing lists, bugzilla, and svn Jan 31 07:25:16 so we really need a lot of patience when dealing with .cn Jan 31 07:25:32 eventually they'll become familiar with that style of development Jan 31 07:25:39 it just takes a (long) while Jan 31 07:26:15 my patience ends after repeating myself 4 times and philippe repeating me as well Jan 31 07:26:48 heh, on the mailing list? Jan 31 07:26:54 yes Jan 31 07:26:59 missed that one Jan 31 07:27:09 he started on the gpe list Jan 31 07:27:20 aaah Jan 31 07:27:21 heh Jan 31 07:27:29 he doesn't want to believe you can't blindly drop in OE recipes into poky Jan 31 07:27:46 and he seems to be hitting bugs in poky we fixed in OE a few days ago Jan 31 07:28:16 it's like "commit bugfix, wait 2 days, get zwang mail about broken poky" Jan 31 07:28:32 well i guess this should soon be less problematic now that hrw is on board Jan 31 07:28:54 should be less diff's between poky and .dev Jan 31 07:28:59 (hopefully) Jan 31 07:29:11 that helps a bit, but not much Jan 31 07:29:22 it isn't a replacement for common sense Jan 31 07:30:29 especially since he want to drop in bonobo and corba into poky, which o-hand has worked hard to *remove* Jan 31 07:30:53 uh oh Jan 31 07:31:17 i wonder why he isn't using .dev then... i guess you asked ? Jan 31 07:31:31 multiple times Jan 31 07:32:18 no real answers, he just repeated his original question Jan 31 07:32:22 hence my annoyance Jan 31 07:32:37 * koen_ -> breakfast Jan 31 07:32:42 ~bon appetit Jan 31 07:32:45 somebody said bon appetit was smacznego. Guten Appetit. Eet Smakelijk. God Appetitt. Buon Appetito. Buen apetito Bom Apetite. buen apetito Smaklig måltid!. Hyvää ruokahalua. Bo Proveito Jan 31 08:15:08 mickeyl, koen_ : My experience with .cn people is that they are not interested in solving the problem.... somebody else has to do it... Jan 31 08:16:00 * philippe also remembers a .cn subcontractor using ftp as versioning system for the kernel. And explaining them for three weeks why they were not allowed to replace the copyright notices with their company name... Jan 31 08:18:54 * koen_ heads to the office to pick up some gear Jan 31 08:18:55 later all Jan 31 08:20:00 * hrw|gone goes to last day at conecto.. and I do not mean http://www.hrw.one.pl/2007/01/31/last-day-at-conecto/ Jan 31 08:24:18 heh Jan 31 08:24:21 that's quite a burned cake Jan 31 08:24:38 burnt, even Jan 31 08:31:11 morning Jan 31 08:59:37 morning all Jan 31 09:02:12 hi Jan 31 09:02:17 last day of hrw|work ;D Jan 31 09:02:45 hrw|work: s/hrw|work/hrw|oh/ :-) Jan 31 09:03:14 XorA: hrw|haerwu Jan 31 09:10:12 congrats :) Jan 31 09:10:37 * mickeyl going to uni today to work on thesis presentation Jan 31 09:10:40 l8er Jan 31 09:13:30 mickey|uni: good luck Jan 31 09:19:21 morning all Jan 31 09:19:53 * RP wonders why someone would want to add cobra/bonobo to poky... Jan 31 09:21:12 good morning RP Jan 31 09:21:41 hi RP greentux Jan 31 09:22:16 hi hrw|work rp Jan 31 09:24:21 koen|away: you should not wake up that early, and you should not write emails at that time! Jan 31 09:26:24 no, he should, they make me laugh Jan 31 09:26:56 i wonder if koen has seen stressed eric Jan 31 09:29:45 hrw|work: did you read my commens from 10 o clock? Jan 31 09:34:15 greentux: on #oe? Jan 31 09:34:37 hrw|work: privat hrw|gone Jan 31 09:34:53 greentux: did not get any Jan 31 09:35:42 hi zecke, rp Jan 31 09:38:25 hey up are kid (pb__)! Jan 31 09:38:38 heh Jan 31 09:38:40 hi ade|desk Jan 31 09:47:12 [drm:mga_dma_reset] *ERROR* mga_dma_reset called without lock held Jan 31 09:47:12 [drm:mga_dma_flush] *ERROR* mga_dma_flush called without lock held Jan 31 09:47:53 not nice Jan 31 09:57:56 FOSDM comers: britsh airways just annonced a 66% off sale Jan 31 09:58:12 so I AM coming to FOSDM yipy Jan 31 09:59:22 hi pb__ Jan 31 10:07:11 good morning everyone Jan 31 10:15:23 ~change 1100 pln to eur Jan 31 10:15:29 1,100.00 Zloty (PLN) makes 280.154 Euro (EUR) (from http://www.xe.com/) Jan 31 10:21:39 hi all. Jan 31 10:24:22 just want to ask. I need to use GCC 3.3.6 with openembedded. I just add new gcc bb files like gcc 3.3.4 and tried to build task task-base. got gcc-cross-initial-3.3.6 packages. After thsi build fails on glibc-2.3.5 configure with message: *** These critical programs are missing or too old: gcc" Any ideas? Jan 31 10:26:01 sounds like glibc 2.3.5 can't be built with gcc 3.3.x Jan 31 10:26:11 I guess you need to either use an older glibc or a newer gcc Jan 31 10:26:15 but it can according to INSTALL Jan 31 10:27:31 INSTALL says that i need GCC >= 3.2 to build it Jan 31 10:27:42 maybe INSTALL is wrong. what does the actual check in configure.ac say? Jan 31 10:30:36 dion: I'm curious: why 3.3.6 and not 3.4.x? Jan 31 10:31:51 i have Motorola e680. And currently just want to be able to build a lot of GNU stuff for it using original kernel/libc (currently). Jan 31 10:32:49 motorola use GCC 3.3.x. I'm not sure that 3.3 and 3.4 are compatible (for C and C++) Jan 31 10:33:21 dion: I hope you have all MVista iwmmxt patches in your hands? Jan 31 10:33:53 yes.. i add iwmmxt patches to bb file Jan 31 10:34:13 (for gcc) Jan 31 10:34:30 here is glibc build log: http://pastebin.ca/334111 Jan 31 10:34:32 I'm under NDA, but better make sure you have __all__ Mvista iwmmxt patches Jan 31 10:35:24 dion: make yourself familiar with autoconf and take a look at config.og Jan 31 10:35:26 config.log Jan 31 10:35:37 thx Jan 31 10:35:59 will try to do something. Just want to use openembedded way to build packages Jan 31 10:37:20 also anybody know, what is about iwmmxt support in recent gcc releases? 3.4, 4.x ? Jan 31 10:41:17 oops.. found problem.. motorola use glibc 2.3.2 Jan 31 11:42:00 * koen stabs ms access Jan 31 11:42:10 poor access Jan 31 11:43:04 my boss made an error with an sql statement, an now I'm locked out Jan 31 11:43:30 * koen waits for the replacement laptop to get dropped off Jan 31 11:49:37 someone move FOSDEM to prague Jan 31 11:52:18 Why does bitbake have two vercmp fuctions? :-/ Jan 31 11:58:04 what's the minimum python version required for bitbake to work? Jan 31 11:59:04 i'm on a box with 2.1 and it doesn't work Jan 31 11:59:25 furlongm: 2.4 Jan 31 11:59:40 hi all Jan 31 11:59:56 hrw: it won't work with 2.2 or 2.3? Jan 31 12:00:32 furlongm: maybe 2.3 will work but not older Jan 31 12:00:38 i have a probel when i run bitbake packet or angstrom-gpe-image Jan 31 12:00:46 hrw|work: ok thanks Jan 31 12:00:46 i have lot of error after few hour Jan 31 12:01:00 like parametre not declared Jan 31 12:01:01 .... Jan 31 12:01:18 furlongm: it should work with 2.3 Jan 31 12:04:04 thx Jan 31 12:05:07 disaster: it might be a good idea to pastebin your error, and to describe what you think the error could be? Jan 31 12:06:35 dion: http://rafb.net/p/6vgaBm67.html is my list of patches Jan 31 12:06:49 dion: specially the last three mvista patches are important! Jan 31 12:07:46 zecke: thanks.. after changing to glibc 2.3 it still building.. now building final gcc Jan 31 12:08:49 where i find the log files please ? Jan 31 12:09:05 zecke: i have no last patch: zecke-xgcc-cpp.patch - is it important? Jan 31 12:09:26 no, it is not Jan 31 12:09:38 it warns about -I/usr/include and such and is available in OE Jan 31 12:10:23 zecke: ok.. so looks like i'm building correct gcc Jan 31 12:10:27 thanks Jan 31 12:11:03 ?? Jan 31 12:11:51 disaster: you are the human that is witnessing the error, tell us how the error looks like? is it big or small, did it brush the teeth this morning? Jan 31 12:12:01 disaster: build/tmp/work/$PACKAGE/temp Jan 31 12:13:15 koen: thanks for the advise last night Jan 31 12:13:16 RP: we might have two vercmp as you added one for RDEPENDS handling epochs? Jan 31 12:19:52 zecke: I've never added a vercmp function. I added explode_deps which handled versions in RDEPENDS fields... Jan 31 12:20:23 zecke: I'm told our epoch handling is bust (which I can believe). Jan 31 12:21:58 RP: I know vercmp in utils.py. where is the second one? Jan 31 12:22:19 zecke: thanks.. build GCC 3.3.6 finished Jan 31 12:22:35 ah, __init__.py Jan 31 12:22:45 pH5: yes Jan 31 12:22:55 pH5: vercmp and pkgcmp in there seem unused Jan 31 12:23:10 pH5: The only place bitbake calls them is from providers.py (in tunk at least) Jan 31 12:23:32 The only place bitbake calls any vercmp function is from providers.py Jan 31 12:25:03 I'm working on a bb package for a program that generates dynamic (.so) libs and static libs (.la) I'm putting the dynamic libs into the main package, is it normal to just discard the static libs or is there another way to handle them? Jan 31 12:25:57 Gerrath: -dev package Jan 31 12:26:19 pH5, great thanks. Jan 31 12:26:43 Gerrath: have a look at the default FILES variables in conf/bitbake.conf Jan 31 12:27:17 pH5 I have used it before for -dbg, I just wasn't sure about static libs. Jan 31 12:28:01 RP: so what to do, drop the __init__ versions of pkgcmp and vercmp and teach the exploder in utils.py to handle the epoch prefix? Jan 31 12:28:58 pH5: I'd guess yes although there looks to be some neat caching on the __init__ versions. I doubt the cache will help much in trunk though... Jan 31 12:29:16 and how should epochs be handled in .bb files? if PV is "1:2.3.7", we can't use "foo-${PV}.tar.gz" in SRC_URI anymore. Jan 31 12:29:20 pH5: Lets fix the utils version and leave the __init__ ones for now... Jan 31 12:30:07 pH5: Have a function to extract the PV into XORG_PV and use XORG_PV in SRC_URIs? Jan 31 12:30:51 PV, EPOCH_PV, REAL_PV? Jan 31 12:32:46 The naming or XORG_PV is open to discussion :) Jan 31 12:33:33 this should not be xorg specific. where should the epoch appear? Jan 31 12:33:38 in the .bb file name? Jan 31 12:34:36 libx11_1:1.0.1.bb? Jan 31 12:35:09 no Jan 31 12:35:12 or just have libx11_1.0.1.bb and EPOCH="1" somewhere inside? Jan 31 12:35:28 version with EPOCH sounds better Jan 31 12:35:54 in this case I'd prefer to use EPOCH only for vercmp and as parameter to ipkg/dpkg when building the package Jan 31 12:36:38 so PV=1.0.1 and this version would also appear in the work dir, to avoid a colon in the build path (who knows what strange autoconf macro may choke on this) Jan 31 12:39:13 pH5: bitbake use PV to findout which is newer.. Jan 31 12:41:19 bitbake currently compares (pv, pr) tuples with vercmp. can't we just make it compare (epoch, pv, pr) tuples, Jan 31 12:41:44 extending dataCache.pkg_pvpr to include the epoch, like dataCache.pkg_epochpvpr? Jan 31 12:42:24 Does an ipk with epoch set have a colon in its name? Jan 31 12:43:18 RP: I don't have any ipkgs with epoch, but deb packages usually don't have it in their name, only in the Version field. Jan 31 12:44:51 pH5: ok, given that, I think we should have EPOCH as a variable as you say, perhaps PV_EPOCH ? Jan 31 12:45:03 I'd like to keep epoch/pv/pr separate. pv describes the sources used, pr describes the patches applied or configuration parameters used and an epoch is just a way to force a different sorting order in bitbake and ipkg Jan 31 12:45:29 pH5: I agree Jan 31 12:47:16 EPOCH, or PV_EPOCH, or even PE, would be fine with me. Jan 31 12:48:04 PE kind of fits :) Jan 31 12:48:08 ~convert 10000 lbs to kg Jan 31 12:48:10 10000 lbs is approximately 4535.92 kg Jan 31 12:48:34 ~convert 278 lbs to kg Jan 31 12:48:37 278 lbs is approximately 126.099 kg Jan 31 12:49:04 heh, read out loud: dataCache.pkg_PEPVPR Jan 31 12:50:55 * mickey|uni agrees to PE Jan 31 12:50:58 RP: :} Jan 31 12:51:03 mickey|uni: great Jan 31 12:56:03 PE sounds good here Jan 31 12:56:15 yes Jan 31 12:57:24 hrw|work: need your email, tried jabber, but offline... Jan 31 12:58:03 greentux: mail like my monotone key Jan 31 12:58:22 hrw|work: i am not a dev... sorry :) Jan 31 12:58:43 greentux: hrw@openembedded.org works Jan 31 13:00:14 greentux: network at connecto suxx totally - most of time I'm disconnected Jan 31 13:01:45 food break... Jan 31 13:03:45 hrw|work: same here, poor network Jan 31 13:07:57 RP: do you think this could work: http://en.pastebin.ca/334252 Jan 31 13:09:27 ah, no :( ERROR: 'PE' while parsing for many packages Jan 31 13:33:09 pH5: Where is that error coming from, the getVar? Jan 31 13:33:55 old cache, actually. here is an updated patch that could even work: http://en.pastebin.ca/334295 Jan 31 13:34:19 That would do it :) Jan 31 13:35:24 hmm, server timeout :-/ Jan 31 13:37:11 http://rafb.net/p/MSLgCX75.html Jan 31 13:37:31 thats better, thanks Jan 31 13:38:24 seems to work so far Jan 31 13:38:58 pH5: Its going to break if we have two files with the same PV and PR, different PEs Jan 31 13:39:38 pH5: Also, since you changed the cache format, you need to bump the cache version - I'd add to the patch so we don't forget Jan 31 13:40:21 hm. what would happen if we had foo 1.0 and foo 1:1.0 ? Jan 31 13:40:49 It would pick one and random with your patch :-/ Jan 31 13:40:55 pH5: Its a good start though, don't get me wrong :) Jan 31 13:41:27 pH5: The problem is preferred_ver = latest[1:] Jan 31 13:42:51 RP: right. and another thing is that while the patch/build/install steps are the same, the packaging step is different for 1.0 and 1:1.0, so we'd need epoch info in the packaging stamp. Jan 31 13:43:52 pH5: No, you need it in everything since they could relate to different .bb files :-/ Jan 31 13:44:27 oh heck, and there I thought we could get away without colons in the build path :( Jan 31 13:44:56 is there no STAGING_INCDIR_NATIVE ? Jan 31 13:45:36 tkp: No, STAGING_INCDIR will be set correctly when you inherit native Jan 31 13:46:16 pH5: Nothing says you have to have a colon... Jan 31 13:46:29 and autotools_stage_includes should reroute things correctly when inheriting from native too? Jan 31 13:48:00 tkp: I'm not sure, I tried that in a native.bb yesterday and I think it was going to work but I hit other issues and had to use an alternative aproach Jan 31 13:50:06 pH5: It should just be a case of adding PE to STAMPS and friends maybe as ${PE}_ Jan 31 13:51:12 how should PREFERRED_VERSION handling work? say I have 1.0 and 1:1.0 and set PREFERRED_VERSION="1.0" Jan 31 13:51:31 RP: problem there Jan 31 13:51:43 STAGING_INC_DIR is not altered by native.bb Jan 31 13:51:46 STAGING_BINDIR is Jan 31 13:52:00 (neither is STAGING_LIBDIR) Jan 31 13:52:14 tkp: I think TARGET_HOST changes,a dn STAGING_INCDIR depends on that Jan 31 13:52:35 pH5: We should really allow epochs in those strings Jan 31 13:52:57 TARGET_HOST is not altered by native.bb either Jan 31 13:54:37 I'm inheriting from native and doing: oe_libinstall -so -C lib libiconv_plug_linux ${STAGING_LIBDIR} Jan 31 13:54:42 which results in: oe_libinstall: install -m 0755 libiconv_plug_linux.so /home/tom/stv/oe-stv/build/tmp-stv/staging/i586-stv-linux/lib/ Jan 31 13:54:56 i586-stv-linux is the TARGET Jan 31 13:55:20 tkp: Lookup the defintion of STAGING_INCDIR and you see it depends on HOST_SYS which in turn depends on HOST_ARCH. native.bbclass does change that Jan 31 13:55:25 RP: agreed. but which version would it select? I think in this case "1.0" should mean no epoch preference, not PE=0. Jan 31 13:56:36 pH5: It has to mean PE=0, you can't do anything but that else you break compatibility :-/ Jan 31 13:58:10 how can I see what the vars have been set to? Jan 31 13:58:25 tkp: bitbake -b foobar.bb -e Jan 31 14:00:39 Maybe we could just consider it a bug in the metadata to have the same package/PV/PR two times just with a different epoch. at least they'd have to produce exactly the same result (modulo epoch in the ipk). Jan 31 14:03:40 pH5: That's going to be very hard to guarantee :-/ Jan 31 14:04:02 right. my mistake... was running the wrong bb file! Jan 31 14:04:13 right, unfortunately. Jan 31 14:05:21 pH5: I think we can manage thigs apart from the PREFERRED_VERSION problem were we just need to define a behaviour Jan 31 14:05:42 I'd not let that stop us, we just need to dsicuss what it should default to Jan 31 14:06:03 Upon reflection, I like the idea of preferring the latest epoch Jan 31 14:06:13 RP: you do? great! I do too :) Jan 31 14:06:40 pH5: It needs discussion, agreement and documenting though Jan 31 14:07:15 The dicussion would at least act as partial documentation to point the bug reports at... Jan 31 14:08:04 RP: of course, I just want to have a proof-of-concept patch for the ML. Jan 31 14:08:14 I think PREFERRED_VERSION = "1.0" should mean latest 1.0 with epoch, if you have 1:1.0 and 1.0 and want to select 1.0 explicitly, we could always allow PREFERRED_VERSION = "0:1.0", although that would be a bit awkward. Jan 31 14:08:58 pH5: We need to allow 1:1.0 and 0:1.0 to work, its just a question of what "1,0" means Jan 31 14:09:09 RP: ok Jan 31 14:10:00 btw, do you know why the match on PREFERRED_VERSION is '(.*)_(.*)' with and underscore? Jan 31 14:12:06 pH5: the latter bit is PR? Jan 31 14:13:03 yes. I want to add optional PE support in there. Jan 31 14:13:30 pH5: yes Jan 31 14:13:47 I've been having some odd problems with do_package recently ( http://rafb.net/p/iPjnTU44.html ) Jan 31 14:13:55 morning Jan 31 14:15:25 looks like it's trying to do package_write Jan 31 14:15:31 yet there are no packages Jan 31 14:16:04 because inherit native sets PACKAGES='' Jan 31 14:16:31 so why is it trying to run do_package_write() at all? Jan 31 14:16:57 default PE = "0" and in package* small condition: if $PE == 0 then ignore PE. Jan 31 14:17:32 I have problem with discussion due to reconnecting Jan 31 14:17:44 hrw|work: With the way pH5 is proposing it, we might not even need a default... Jan 31 14:18:25 I have a bunch of files that are not getting added to my ipk files (dbg, dev ..) when they built. I have tried using FILES_directfb-dbg = and listing the files. This does not work, however if I add a package using PACKAGE and then add the files to that PACKAGE it works. If I try to put directfb-dbg in PACKAGE= then bitbake says its defined twice in PACKAGE. Jan 31 14:19:28 when I say add the files to PACKAGE I mean by using FILE_name_of_package_defined_in_PACKAGE = files Jan 31 14:20:30 I might have found my problem.. Jan 31 14:21:29 you probably want to be setting FILES_${PN}-dbg, not FILES_directfb-dbg. Jan 31 14:21:34 looks like FILES_directfb-dbg_append works. Jan 31 14:21:39 (assuming PN is directfb, anyway) Jan 31 14:22:00 in ann of the do_package routines, there is a check to see if PACKAGES is defined... if it's not then noting is done Jan 31 14:22:39 03mickeyl 07org.oe.dev * rd95a77fa... 10/ (1 packages/python/python-pylirc_0.0.5.bb): add python-pylirc, python bindings to lirc Jan 31 14:22:51 03cbrake 07org.oe.dev * r8e1fbabc... 10/ (25 files in 4 dirs): logicpd-pxa270 2.6.19.2: update kernel, contributed by Shane Volpe Jan 31 14:22:58 03cbrake 07org.oe.dev * r8972febd... 10/ (1 MAINTAINERS): MAINTAINERS: update Shane's entry to include php Jan 31 14:28:29 interesting... this is the same problem I had yesterday with a different package Jan 31 14:28:42 simply renaming the bb file and trying again fixes it Jan 31 14:28:55 somwhere along the lines something has become corrupt Jan 31 14:29:02 bitbake -c clean doesn not fix Jan 31 14:29:28 are there any other things I can do to clean out the bitbake environment...? Jan 31 14:29:40 (other than deleting tmp and starting again) Jan 31 14:30:02 cbrake: can Shane take care of php4? Jan 31 14:48:49 hrw|work: Shane = Gerrath Jan 31 14:48:56 Gerrath: what are your plans for php? Jan 31 14:51:34 hrw|work, yes. Jan 31 14:51:46 hrw|work, yes I can take care of php4 Jan 31 14:57:55 Xora: new version of the cairo surface patch available :) Jan 31 15:01:47 Gerrath: great. 4.3.x is quite old and unfetchable Jan 31 15:01:48 does the current oe metadata require bitbake 1.7.2 or should 1.6.2 work with it? Jan 31 15:03:30 hrw|work, I will look into it and get it working again. Jan 31 15:04:47 thx Jan 31 15:06:49 gb2: 1.6.2 should work Jan 31 15:06:55 koen: port it in then Jan 31 15:46:10 03cbrake 07org.oe.dev * r592a56e0... 10/ (4 files in 3 dirs): directfb 1.0.0rc3: update to rc3, contributed by Shane Volpe Jan 31 15:46:29 cbrake: you can use --author during commit Jan 31 15:47:12 zecke: great -- I'll do that . Jan 31 15:47:50 tn1: as I'm mostly busy, try to find someone here :) Jan 31 15:59:06 All, I'm working on a new OE tzdata package to replace the timezones package. Any comments on what cities should be in the base package? If I did it like a desktop tzdata package it would be 5M, so we probably should do the "kitchen sink" approach of everything. Jan 31 15:59:18 one major city from each TZ? Jan 31 15:59:42 tn1: good solution Jan 31 15:59:56 tn1: current timezones package contain about one per continent Jan 31 15:59:58 tn1: alternatively try to find out why uclibc is so much better in regard to timezone size Jan 31 16:00:22 someone want to volunteer to give me a city name in each TZ in Europe? Jan 31 16:01:26 tnb: http://www.pubquizhelp.34sp.com/geo/city.html maybe? Jan 31 16:12:31 cu Jan 31 16:49:09 ibot, seen schurig Jan 31 16:49:37 schurig was last seen on IRC in channel #oe, 5d 5h 7m 6s ago, saying: 'mickeyl: we're all coughing like mad, but otherwise good'. Jan 31 17:06:53 a python module that I'm trying to write a bb file for is attempting to use directfb-config to determine if directfb is on my system Jan 31 17:07:12 directfb has not been installed by bb Jan 31 17:07:16 however it is on my host system Jan 31 17:07:45 and it seems that my host systems PATH is also in the bb PATH Jan 31 17:08:12 so the python module finds directfb from the host - resulting in a broken install Jan 31 17:08:40 is it right that the hosts PATH is in the bitbake environment? Jan 31 17:17:04 any suggestions as to how I could either remove the hosts PATH entries? Jan 31 17:17:40 export PATH = ...... ? Jan 31 17:18:24 echo $PATH (get what you need) and put it in "export PATH=....." Jan 31 17:25:52 tkp: the FHS won't allows this. You can't remove /usr/bin from your path Jan 31 17:26:01 tkp: patch, diff, gcc, etc. will not work Jan 31 17:27:16 zecke: I just discovered that! Jan 31 17:28:12 hmm... /me wonders how he can fix it Jan 31 17:28:29 I noticed that gdb-cross does not install in the cross directory after building the package. Is there an inherit that should be used to get this to happen or is there some other way? Jan 31 17:28:52 I could just patch the setup.py file... but that wouldn't be a very generic solution Jan 31 17:29:19 tkp: add a switch to tell him where to find the *-config stuff Jan 31 17:29:36 tkp: or make it use pkg-config, which is there to just solve these issues... generically Jan 31 17:29:53 it does use pkg-config... but only if *-config fails Jan 31 17:30:03 morons Jan 31 17:30:12 heh Jan 31 17:30:30 you think thats thw wrong way round then? Jan 31 17:31:37 writing a custom foo-config is just stupid Jan 31 17:31:58 all you need is to write a .pc file... but there are way too many morons around Jan 31 17:33:10 how do I force OE to build an image based on a 2.4 kernel? I am using machine h3900 (but could use h5000) and distro generic. I *though* setting the PREFERRED_PROVIDER_virtual/kernel = handhelds-pxa would do it, but no such luck ... Jan 31 17:34:33 mccarthy, I think that is set in the machine file. conf/machine/ Jan 31 17:34:55 mccarthy, I think that is set in the machine file. conf/machine/h3900 Jan 31 17:35:46 mccarthy, yes it is "PREFERRED_PROVIDER_virtual/kernel = "linux-handhelds-2.6"" so you should just have to change it there. Jan 31 17:37:04 I will try that. How come your local.conf does not seem to over-ride this setting? Jan 31 17:38:36 mccarthy, if you select a machine then it uses its settings. I'm not sure what the reasoning is in not having the local.conf override it. maybe someone else can answer that. Jan 31 17:38:54 mccarthy: because machine + distro is included after local.conf Jan 31 17:39:18 Gerrath: chicken egg issue, and take a look at conf/bitbake.conf (bottom of the file) Jan 31 17:40:17 zecke, Gerrath OK thanks. I would rather have simply altered my local.conf though so that updating OE would not conflict with any changes I make ... Jan 31 17:40:49 mccarthy: check bitbake.conf and see what is included after machine/distro Jan 31 17:41:11 mccarthy: and generally I trust the machine maintainer to select the appropriate kernel for the machine they maintain Jan 31 17:41:17 zecke, ok (now I just have to do a 'find . -name bitbake.conf' :) Jan 31 17:41:18 mccarthy, you can start a local repo and set it in your local.conf to use files in it before using those in the main repo. Jan 31 17:41:28 somewhere in your $BBPATH Jan 31 17:41:46 most likely org.openembedded.dev/conf/bitbake.conf Jan 31 17:42:16 mccarthy, then copy the machine config file over to that repo. Jan 31 17:42:23 unfortunately it seems that no one really "maintains" the h5000 series as far as I know ... (at least I have not built a successful image since familiar went away) Jan 31 17:42:48 mccarthy, then modify it, get it to compile and submit a patch :-) Jan 31 17:42:53 Back to tzdata, I put a major city from most timezones into the base package, then have separate packages for: tzdata-africa tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific Jan 31 17:43:52 tnb: opie used to have 'timezones-' packages, maybe just steal this name? Jan 31 17:44:37 zecke: I thought about that, but a) didn't want to force something into obsolescence and b) Debian uses 'tzdata' Jan 31 17:45:48 tnb: Opie's packages are just there because we did not used the glibc ones... Jan 31 17:45:56 tnb: but the debian argument might make sense Jan 31 17:47:40 mccarthy, here is an example of setting up a local repo: http://www.pastebin.ca/334550 That is the top section of my local.conf. You will also need to add the local repo to you BBPATH. If you want to add a board file then make a directory called conf/machine in the local repo and put the board file there. Jan 31 17:47:44 Gerrath, zecke thanks again for your help. It looks like I can make my own "distro" and put it in there, since distro is included last (that seems the cleanest way) Jan 31 17:48:13 mccarthy: auto.conf or site.conf would be options as well IIRC Jan 31 17:48:49 mccarthy, I have a distro for my board specific to our product so I put it in my local repo under conf/distro/company_name.conf Jan 31 17:49:10 I will keep you posted :0 Jan 31 17:49:14 mickeyl: RP : koen|away : Have we ever considered adding versions to files like conf/local.conf? Jan 31 17:49:36 mccarthy, then I version control my entire local repo since it is all my modfied stuff. Anything that others can use or is generic I patch file it and submit it to OE bugtracker,. Jan 31 17:49:56 mickeyl: RP koen|away : a good example would be KDE's xmlgui. Where users can configure their UI but once a new major layout file is published, it takes presedence over the local copy again Jan 31 17:51:20 ~lart crazy clients and middle management Jan 31 17:51:26 * ibot flings poo at crazy clients and middle management Jan 31 17:51:35 ibot: botsnack Jan 31 17:51:35 JustinP: thanks Jan 31 17:54:54 zecke: sounds interesting. could you wrapup that and send it to the ml? Jan 31 17:56:26 argh, yeah. right :} Jan 31 17:56:45 mickeyl: at least warn: "You have forked a file which now has a newer version" Jan 31 18:00:54 zecke: I don't see it as a big problem but if someone wanted to implement it... ;-) Jan 31 18:03:18 oh Robert Anton Wilson is dead Jan 31 18:29:11 zecke, I've sent patch to Erik. Was sad to hear that ipkg is no longer being developed, only bugfixed. Jan 31 18:29:54 RP, whats the status of Spitz in vanilla? Just out of interest Jan 31 18:37:22 I'm getting 'NOTE: Patch xyx is outdated' for all my patches Jan 31 18:37:30 what does that mean? Jan 31 18:45:05 tkp: it means that $DATE > $maxdate Jan 31 18:45:19 tkp: or a bug in the patcher Jan 31 18:46:26 koen|gprs: and $maxdate come from where? Jan 31 18:46:26 Kristoffer: ipkg is not being developed? Is this new or just a realization you came to? I think there's just noone really working on it. Jan 31 18:59:25 JustinP, thats the message I got from Erik Jan 31 18:59:51 But not being developed and no-one working on it, is quite similiar in my ears Jan 31 19:00:20 JustinP, Quote from Erik "There is no development beyond bug fixing. But patches will be reviewed" Jan 31 19:01:46 you can always fork off :) Jan 31 19:02:10 timtimred: or better, take over maintainership Jan 31 19:02:38 I've had a look at the code and it seems messed up. It should generally move from memory usage to disk usage Jan 31 19:03:21 Currently it takes 8minutes for my jornada to calculate dependencies Jan 31 19:07:14 Perhaps creating an smaller and optimized fork Jan 31 19:07:18 hmm Jan 31 19:08:47 based on sqlite Jan 31 19:09:16 or fix dpkg and apt :) Jan 31 19:09:31 hey koen|gprs Jan 31 19:09:36 zecke, Patch is accepted and should be included in 0.99.165 Jan 31 19:09:57 hey mreimer Jan 31 19:33:07 question: I'm trying to make a bb for gaim-encryption, and the compile fails because gaim-encryption can't find gaim.pc for pkgconfig. How can I address this? Jan 31 19:33:29 calmofthestorm7: check that gaim.pc was properly staged Jan 31 19:33:44 how do I make it stage? Jan 31 19:34:08 calmofthestorm7: I assume it would be somewhere in tmp/staging/arm-*/lib/pkgconfig/ (where the interepretation and correction of the path is up to you) Jan 31 19:35:02 aright, I found where the pc files go Jan 31 19:35:03 but no gaim.pc Jan 31 19:35:04 calmofthestorm7: if you build a bb file various tasks are executed (e.g. fetch, patch, configure, compile ) and then various install tasks. some to create packages, and some to put headers and other resources into the staging dir so others can find it Jan 31 19:35:19 so I need to add a do_stage task to gaim.bb? Jan 31 19:35:31 so the gaim file, should stage headers and pkg-config file Jan 31 19:35:32 right Jan 31 19:35:51 what's the syntax for that; is there an example somewhere I can steal from? Jan 31 19:36:53 oe_runmake install DESTDIR="" bindir=${STAGING_BINDIR} includedir=${STAGING_INCDIR} libdir=${STAGING_LIBDIR} prefix=${STAGING_DIR} Jan 31 19:37:02 if I do that it gives me permission denied errors on do_stage Jan 31 19:37:45 calmofthestorm7: good question, I leave the answer up to the others... (I'm short on time atm) Jan 31 19:37:56 oh no worries Jan 31 19:37:59 thanks for the thoughts Jan 31 19:38:03 I appreciate it;) Jan 31 19:48:31 Any gcc guru in the house? Jan 31 19:48:43 define guru;) Jan 31 19:48:51 I probably can't help but what's up? Jan 31 19:48:58 one that can tell me if fix-header is needed or not :) Jan 31 19:49:03 no clue! Jan 31 19:49:05 sorry;) Jan 31 19:49:24 no worries Jan 31 19:56:17 Arghh I always forget is it SRC_URI_sh3 or sh3_SRC_URI? Jan 31 19:56:29 prefix or suffix? Jan 31 20:03:41 Kristoffer: SRC_URI_sh3 = "...." or SRC_URI_append_sh3 = "...." Jan 31 20:04:44 for moment or two Jan 31 20:05:11 ooooow Jan 31 20:05:15 I need 3 moments Jan 31 20:05:25 koen|gprs: go then Jan 31 20:05:31 ;) Jan 31 20:06:59 anybody know if fix-headers actually does something usefull Jan 31 20:07:14 I read somewhere that its ment to be run when host==target Jan 31 20:07:25 which it certainly isnt when using OE Jan 31 20:07:40 I can easily be trapped in host==target using OE Jan 31 20:08:11 DISTRO=generic MACHINE=progear + building on i686-linux will give it probably Jan 31 20:08:11 fix-headers? Jan 31 20:08:15 have to go - bye Jan 31 20:08:16 gcc or uclibc? Jan 31 20:09:44 koen|away, gcc Jan 31 20:09:56 It only happens on sh3 though Jan 31 20:10:13 and its been fixed upstreams (no patch though, just dissapeard) Jan 31 20:10:45 Currently Im making a patch that removes the install lines from the Makefile, but would like to be sure before I apply it Jan 31 20:10:56 the patch will of course only affect sh3 Jan 31 20:38:00 03kristoffer 07org.oe.dev * r102165bf... 10/ (3 files in 3 dirs): Jan 31 20:38:00 gcc-4.1.1/sh3-installfix-fixheaders.patch : Fix of bug 1525 Jan 31 20:38:00 * When running the installation script in gcc it complains about Jan 31 20:38:00 missing the file build/fix-header. Its a known bug that has Jan 31 20:38:00 been fixed upstreams (but no patch). Its not quite clear what Jan 31 20:38:00 fix-header does, but for now we will remove the install lines. Jan 31 20:38:02 * Added SRC_URI_append_sh3 for patch in gcc_4.1.1.bb Jan 31 20:44:46 hi all Jan 31 20:45:01 koen|gprs: hey koen Jan 31 20:45:12 hey likewise Jan 31 20:46:43 we should have auditions the The OE Project Jan 31 20:46:57 and find the Recipe of Destiny Jan 31 20:47:03 Jan 31 20:47:38 likewise: http://www.flickr.com/photos/koenkooi/sets/72157594506897688/ Jan 31 20:49:39 THC - The Audience is BitBaking Jan 31 20:51:18 koen|gprs: was it worth seeing? Jan 31 20:51:37 yes, although you get a distinct tourist trap feeling Jan 31 22:03:41 Can oe run a menuconfig? I want to use the same toolchain to configure a local kernel and it seems dirty to write scripts to use the tools from the tempdir Jan 31 22:03:56 a kernel menuconfig to be specific Jan 31 22:04:08 I tried it but it seems to try to run it in the background or something Jan 31 22:08:54 why would you want to run menuconfig? Just hack on the .config direclty Jan 31 22:24:24 why would I want to hack on the .config when I could run menuconfig Jan 31 22:26:50 nzg: for development, build your kernel outside OE, or cd into the tmp/work/... and manually build it. Jan 31 22:27:09 nzg: once you are happy with it, then store the config in the OE metadata, etc. Jan 31 22:28:31 nzg: during development of a package, I rarely run bitbake a package. See http://www.openembedded.org/wiki/OeFaq Jan 31 22:29:19 nzg: this is one of the most powerful concepts of OE. You can cd to the directory where the package is being built and run the scripts in the temp directory (run.do_configure, run.do_compile, etc). Jan 31 22:29:39 nzg: very hand for debugging where you want to change something, rebuild, etc. Jan 31 22:29:48 later Jan 31 22:46:12 That's actually what I'm doing, and I have a working .config Jan 31 22:46:18 But here's the thing Jan 31 22:46:54 I'm building the kernel external to the src, as I have to do a lot of development and it makes patch generation much easier Jan 31 22:47:15 The .config, is therefore stored in an external directory, leaving a pristine source. Jan 31 22:47:59 I want to generate a new object directory with oe. Jan 31 22:48:16 I can just copy in the .config and run oldconfig I suppose Jan 31 22:48:32 nvmd, rambing too much coffee Jan 31 22:56:54 I have a new version of linphone ready (tested in console mode, but I cannot test in GPE mode) - there is no MAINTAINER in the file. Jan 31 22:57:15 I will check it in with a DEFAULT_PREFERENCE=-1 and ask for someone to test it in GPE. Jan 31 22:57:34 RP: ping Jan 31 22:57:58 This new version, plus the new yeaphone package, will allow you to plug a usb phone into an NSLU2 and use it and asterisk running on the nslu2 to make and receive voip calls. Jan 31 22:58:20 hey mickeyl Jan 31 22:58:26 hi Jan 31 22:58:50 did anything change in bitbake regarding BB_COLLECTIONS recently? Jan 31 22:59:13 i can't seem to get my local stuff priorized Jan 31 22:59:23 it always picks the upstream collection Jan 31 22:59:37 (bitbake 1.6.2) Jan 31 23:09:51 exit Jan 31 23:26:32 mickeyl: I have not noticed any problems with 1.6.3 Jan 31 23:27:35 do you have a setting where you have e.g. Jan 31 23:27:38 foo_r1 in OE Jan 31 23:27:50 and foo_r2 in local? Jan 31 23:28:08 foo_pv-r1, foo_pv-r2 even Jan 31 23:36:34 mickeyl: checking ... Jan 31 23:37:58 mickeyl: yes, I think so. tslib_1.0.bb in both trees Jan 31 23:38:06 heh Jan 31 23:38:09 exactly my test case Jan 31 23:38:17 and your local has a higher revision? Jan 31 23:38:21 and its chosen? Jan 31 23:38:44 mickeyl: yes, tslib local, PR="r2" Jan 31 23:39:09 mickeyl: tslib OE, PR="r7" Jan 31 23:39:21 mickeyl: I guess the PR is higher in the OE tree. Jan 31 23:39:25 mmh Jan 31 23:39:31 could you try bumping the local one please? Jan 31 23:39:47 mickeyl: sure Jan 31 23:40:32 thanks Jan 31 23:40:37 mickeyl: set PR="r8" in local Jan 31 23:42:27 mickeyl: yup, its building version r8 Jan 31 23:42:38 from the local tree. Jan 31 23:42:43 local tree has higher priority. Jan 31 23:43:02 have to run -- later. Jan 31 23:43:05 ok, thanks Jan 31 23:43:10 so it's a local problem here Jan 31 23:43:11 cu Jan 31 23:43:14 *sigh Jan 31 23:43:18 ~shoot problems Jan 31 23:43:19 * ibot shoots problems in the ear with a phase pistol! Jan 31 23:58:16 how do you pack up one in the build process Jan 31 23:58:37 specifically, my script is still buggy and it's trying to build the kernel Jan 31 23:58:50 I didn't configure it right so I modified the bb script to do so Jan 31 23:59:08 but now it just keeps trying to run do_compile and doesn't go back to do_configure Feb 01 00:00:07 bitbake -c clean Feb 01 00:00:14 bitbake -c clean package name Feb 01 00:00:24 kk, I'll try that Feb 01 00:04:59 doesn't seem to work Feb 01 00:05:07 hmm Feb 01 00:05:11 ./oe-run.sh -c clean linux do_config Feb 01 00:05:21 ./oe-run.sh virtual/kernel Feb 01 00:05:28 still restarts at do_compile Feb 01 00:05:37 want to be at do_config Feb 01 00:05:37 did the clan seem what is oe_run.sh ? Feb 01 00:06:05 sorry, oe_run is just a wrapper around bitbake that sets the path Feb 01 00:06:29 -c clean completely wipes the temp dir for that package, it wont just back up to that step Feb 01 00:06:34 but its still probably what you want Feb 01 00:06:34 what is the output of -c clean? Feb 01 00:07:01 without getting into mucking with stamps .... Feb 01 00:07:04 NOTE: package linux-2.6.19: started Feb 01 00:07:04 NOTE: package linux-2.6.19-r0: task do_clean: started Feb 01 00:07:05 NOTE: removing /home/nathan/lab/IPAC-9302/tmp/work/IPAC9302-linux/linux-2.6.19-r0 Feb 01 00:07:05 NOTE: removing /home/nathan/lab/IPAC-9302/tmp/stamps/IPAC9302-linux/linux-2.6.19-r0.* Feb 01 00:07:06 NOTE: package linux-2.6.19-r0: task do_clean: completed Feb 01 00:07:07 NOTE: package linux-2.6.19: completed Feb 01 00:07:09 NOTE: build 200701311841: completed Feb 01 00:07:11 Build statistics: Feb 01 00:07:13 Attempted builds: 1 Feb 01 00:07:28 ok, then what is the output when you build again? Feb 01 00:07:49 OE Build Configuration: Feb 01 00:07:49 BB_VERSION = "1.6.3" Feb 01 00:07:49 OE_REVISION = "" Feb 01 00:07:49 TARGET_ARCH = "arm" Feb 01 00:07:49 TARGET_OS = "linux" Feb 01 00:07:49 MACHINE = "IPAC9302" Feb 01 00:07:49 DISTRO = "emac" Feb 01 00:07:51 DISTRO_VERSION = ".dev-snapshot-20070201" Feb 01 00:07:53 TARGET_FPU = "soft" Feb 01 00:07:55 NOTE: preferred version 2.5 of glibc not available Feb 01 00:07:57 NOTE: package IPAC9302-kernel-2.6.8.1: started Feb 01 00:07:59 NOTE: package IPAC9302-kernel-2.6.8.1-r1: task do_compile: started Feb 01 00:08:07 uh Feb 01 00:08:12 you're not cleaning the right package Feb 01 00:08:17 you did -c clean linux Feb 01 00:08:21 you want -c clean virtual/kernel Feb 01 00:08:24 or whatever Feb 01 00:08:25 also Feb 01 00:08:26 o Feb 01 00:08:28 ~pastebin Feb 01 00:08:31 "linux" isnt "IPAC9302-kernel" Feb 01 00:08:31 extra, extra, read all about it, pastebin is a place to paste your stuff without flooding the channel - try http://pastebin.ca, or http://channels.debian.net/paste, or http://rafb.net/paste/ Feb 01 00:08:35 ~pastebin Feb 01 00:08:54 kk, srry, making a note Feb 01 00:09:07 or are you saying "not" Feb 01 00:09:31 in the future use pastebin for logs Feb 01 00:09:44 kk Feb 01 00:09:51 especially whern the channel is busy Feb 01 00:10:46 if I clean virtual/kernel will that clean it's dependencies as well? Feb 01 00:11:24 I am not sure how virtual targets work Feb 01 00:11:30 well I'll try it Feb 01 00:12:55 nope, did what I want just removed the kernel build, thx **** ENDING LOGGING AT Thu Feb 01 02:59:57 2007