**** BEGIN LOGGING AT Mon Feb 20 10:59:57 2006 Feb 20 11:09:10 koen: You had an error recently about a versioned dependency problem in gpe-session-scripts. Can you still reporduce it? Feb 20 11:09:21 sure Feb 20 11:09:30 bitbake gpe-sessionscripts with a recent bitbake Feb 20 11:09:46 gpe-session-scripts that is Feb 20 11:10:43 koen: ok, it was from a .bb in .dev? Feb 20 11:12:22 ~curse tosa and poodle for being so unpopular Feb 20 11:12:23 May you be reincarnated as a Windows XP administrator, tosa and poodle for being so unpopular ! Feb 20 11:12:51 koen: It reproduces - I'll look into it... Feb 20 11:54:20 kergoth, could you inform me about tslib input raw a bit .. how do i get a touchscreen supported by it ? Feb 20 12:28:35 someone want to test up-to-date hostap stuff? Feb 20 12:44:51 anyone successful with e-image or e-image-core? Feb 20 12:47:13 03pH5 07org.oe.dev * r7130132b... 10/packages/linux/handhelds-pxa-2.6/ipaq-pxa270/defconfig: Feb 20 12:47:13 handhelds-pxa-2.6: upgrade hx4700 defconfig to 2.6.15-hh0 Feb 20 12:47:13 - reverts an accidental downgrade Feb 20 12:48:33 03koen 07org.oe.dev * r3abff1bf... 10/packages/linux/ep93xx-kernel_2.6.15.bb: Feb 20 12:48:33 ep93xx kernel: update to derevo2 Feb 20 12:48:33 * serial should be working Feb 20 12:48:33 * ethernet might be working Feb 20 12:51:10 someone know which email Schurig use in OE bugtracker? Feb 20 12:51:45 Angstrom-gpe-image-test-20060220-ep93xx.rootfs.tar.bz2 Feb 20 12:51:46 yay Feb 20 12:51:51 gcc 4 works Feb 20 12:51:55 * koen|away really away now Feb 20 12:52:08 03pH5 07org.oe.dev * r5940fb0f... 10/packages/avahi/avahi_0.6.7.bb: Feb 20 12:52:08 avahi: add 0.6.7 Feb 20 12:52:08 - See http://avahi.org/milestone/Avahi%200.6.7 and Feb 20 12:52:08 http://avahi.org/milestone/Avahi%200.6.6 for changes since 0.6.5 Feb 20 12:52:34 mhh just to know what board with ep93xx ??? Feb 20 12:53:29 gremlin[it]work: http://dominion.kabel.utwente.nl/koen/ep93xx/ http://glomationinc.com/products_9312-sx.html Feb 20 12:54:36 i know glomation one specially 9315 seem really cute;) Feb 20 13:01:16 bugs: 707, 708, 709 need someone familiar with hostap, wpa etc things Feb 20 13:08:31 03pH5 07org.oe.dev * rf25635ce... 10/packages/avahi/ (avahi_0.6.3.bb avahi_0.6.5.bb avahi_0.6.7.bb): avahi: drop 0.6.3, fixes suggested by BitTest Feb 20 13:08:37 03pH5 07org.oe.dev * r1077a62e... 10/packages/libdaemon/ (libdaemon_0.3.bb libdaemon_0.10.bb libdaemon_0.6.bb): libdaemon: drop 0.3, fixes suggested by BitTest Feb 20 13:10:41 morning Feb 20 13:55:41 hello Feb 20 13:55:48 hey greentux Feb 20 13:56:23 hi greentux Feb 20 13:59:29 hi drw Feb 20 13:59:44 hi hrw|work Feb 20 13:59:53 hi XorA Feb 20 14:00:23 hey Feb 20 14:01:16 morning Feb 20 14:02:23 my gps is not working right in my akita when I do a 'cat /dev/ttyUSB0', I get blocks of lines, but it does work with minicom, could it be any buffering problem with cat? Feb 20 14:26:22 koen|away, can u give me (us) some kind of review of the glomation board ? Feb 20 14:35:27 gremlin[it]work: I'll have to boot 2.6 first Feb 20 14:35:43 * koen gets out his soldering iron to fix the serial dongle Feb 20 14:35:54 ouch !!! Feb 20 14:37:27 It's using some 'standard' which differs from what I want Feb 20 14:38:14 korean standard :) Feb 20 14:39:23 mainly i like to know about speed, gcc support for maverick, and if u was able to find the bsdl (jtag) file for cirrus cpu Feb 20 14:41:01 gremlin[it]work: we (actually [g2]) are going to work on gcc support for maverick Feb 20 14:41:17 gremlin[it]work: but you can use crunch already if you use the toolchain from cirrus Feb 20 14:48:32 hello guys Feb 20 14:49:51 hi Jose Feb 20 15:00:30 hrw|work: saw your message on the list, about oz354 Feb 20 15:00:55 I'm sorry to say I haven't had much time to test stuff on my akita Feb 20 15:01:36 but what I did seems to work without major bugs Feb 20 15:02:22 only problem I found with a 354 image I built a week ago was with libxine playing qt movies, but that is minor Feb 20 15:05:10 Bernardo: no problem - over 100 users got url to images Feb 20 15:29:48 CoreDump|afk: any plans to update altboot in .oz354fam083? I would like to get 'rootfs from tarballs' functionality in oz 3.5.4 Feb 20 15:36:29 very basic q: so to setup a package to build with my local oe I need to 1)create a .bb and 2) create an ipkg for the package? is that all (in general)? Feb 20 15:36:47 cyphunk: 2) will be done for you if your bb is right Feb 20 15:36:57 XorA: thanks Feb 20 15:43:41 under what conditions are custom do_* routines needed? Feb 20 15:44:02 or will I need a do_install defined for all the files I want installed regardless of condition of the packages original makefile? Feb 20 15:44:30 cyphunk: if make install works then you shouldnt need a custom do_install Feb 20 15:44:41 righto Feb 20 15:44:41 thanks Feb 20 15:45:49 sometime makefiles use custom variables for install dirs and you need to call oe_runmake in a custom do_install with these variable set correctly, that sort of thing Feb 20 15:45:58 autotools stuff is normally very simple Feb 20 15:46:21 okay, noted Feb 20 16:19:16 <[g2]> gremlin[it]work are you looking for JTAG on the cirrus for debugging ? Feb 20 16:19:22 <[g2]> or for flashing the bootloader ? Feb 20 16:19:53 <[g2]> The Cirrus EP93xx family has the ability to bootstrap from serial Feb 20 16:20:15 <[g2]> I"ve done it on the Cirrus boards and the Glomation board Feb 20 16:21:57 [g2] yes ... was one of the reason i don't bought it some months ago ... Feb 20 16:22:50 well know that there is all time a way to reflash the bootloared is good ... but should be nice also to debug the board Feb 20 16:27:06 I run bitbake -b on a .bb file, it creates the logs, I fix something and want to check again but now it doesnt create logs anymore Feb 20 16:27:07 only the first time Feb 20 16:27:32 I deleted the entire tmp/work/ dir, deleted the sources, tried again... still doesnt create log, this time doesnt create tmp/work dir Feb 20 16:27:37 I missing something Feb 20 16:27:50 tmp/stamps Feb 20 16:28:14 yeup, thanks Feb 20 16:28:17 cyphunk: easy way is to use bitbake -c clean to remove workdir and stamps Feb 20 16:28:47 XorA: and this will only remove the workdir for the defined .bb, right? Feb 20 16:28:55 <[g2]> gremlin[it]work you may want to stop by #ep93xx and #openjtag Feb 20 16:29:11 cyphunk: yes, it just cleans workdir and tmp/stamps/packagename* Feb 20 16:29:20 XorA: thanks Feb 20 16:29:52 yup thanks [g2] Feb 20 16:31:18 XorA: I'm running it, is it supposed to "Handling BitBake files: | (0047/2800) [ 1 %]" before cleaning? Feb 20 16:31:38 cu Feb 20 16:32:06 cyphunk: you can use -b ../org.openembedded.dev/packages/spanner/spanner.bb to work with that single .bb file Feb 20 16:32:18 okay, thanks Feb 20 16:32:25 cyphunk: this is useful for developing bb's but it doesnt proces DEPENDS Feb 20 16:32:32 cyphunk: so be careful Feb 20 16:32:43 noted Feb 20 16:38:03 [g2] there is a site about linux on ep93xx ? Feb 20 16:42:24 the package I am configuring (libupnp) has two subdirs/subpackages in the source which I need to `cd` into before running make. What is the proper way to chdir? Feb 20 16:42:41 can I just override do_compile() and chdir before running $OEMAKE ? Feb 20 16:42:56 cyphunk: I beleive that is ok Feb 20 16:43:05 XorA: okay Feb 20 16:43:07 thanks Feb 20 16:43:15 cyphunk: or maybe -C command to make Feb 20 16:43:43 XorA: I guess that wouldn't hurt. not what the readme says (uses cd) but worth a try ;) Feb 20 16:44:18 cyphunk: I lack finess when it comes to bb writing :-) Feb 20 16:45:16 XorA: what's wrong with this IRC room... you should be chewing me out out not already knowing this shit ;) Feb 20 16:45:32 cyphunk: we are the nice guys :-) Feb 20 16:48:22 But kudos to cyphunk for knowing how IRC normally works.. :) Feb 20 16:57:09 I've got some small test applications like "hello world" etc I want to cross compile... is bitbaking still the simplest way to go, or is there a simpler way? any docs on thats available? Feb 20 16:57:37 mndctrl: bitbake devshell is probably yhe easiest Feb 20 16:58:14 * XorA|gone goes for train Feb 20 17:04:37 devshell.. hmm, I'll look into it, tnx ;) Feb 20 17:08:09 the makefile for this package uses a $PREFIX internallaly. There is no configure for the package so this somethign it expects the installer to set in the env. Feb 20 17:09:17 how can I set an env var for oe_runmake Feb 20 17:18:32 how do I control the env var of the oe_runmake command? I need to set a prefix during make (since there is no configure for the package) Feb 20 17:20:06 evening Feb 20 17:20:13 hello reenoo Feb 20 17:21:54 hi poli Feb 20 17:22:08 ~seen treke Feb 20 17:22:11 treke was last seen on IRC in channel #oe, 41d 17h 35m 24s ago, saying: 'http://zaurus.catstar.org/jmqt/index_e.html'. Feb 20 17:22:21 ~seen ggilbert Feb 20 17:22:23 ggilbert was last seen on IRC in channel #kde, 31d 21h 53m 1s ago, saying: 'mdeand1: No I see it now. I didn't see delete on it this morning when I was searching :)'. Feb 20 17:22:25 hrw|work: hi - where can I get hold of a OZ 3.5.4 test image? I'm not having any luck building my own with OE... Feb 20 17:43:14 03koen 07org.oe.dev * r74ba86f4... 10/conf/machine/ep93xx.conf: ep93xx: use correct serial device Feb 20 17:46:27 during do_install I get this error: "install: cannot create regular file `/usr/lib/libupnp.so.1.2.1': Permission denied" Feb 20 17:46:43 err, I mean, do_stage phase, not do install Feb 20 17:46:53 any ideas? Feb 20 17:46:54 looks like it doesn't obey DESTDIR Feb 20 17:47:02 it tries to install to your host system Feb 20 17:47:10 yeah Feb 20 17:47:18 there is no configure for the package Feb 20 17:47:22 only the makefile Feb 20 17:47:27 it takes $PREFIX from the env Feb 20 17:52:39 any ideas? Can I define $PREFIX for do_stage or do_install or should I make a patch to be applied to the make file which statically defined PREFIX inside of it? Feb 20 17:52:57 (I'm only affraid the latter solution would have adverse affects during image builds?) Feb 20 18:09:03 cyphunk, patch the makefile to make it behave Feb 20 18:15:30 hi Feb 20 18:18:05 hey Feb 20 18:19:35 RP: ping Feb 20 18:21:08 pb_: hey Feb 20 18:21:28 pb_: I have read that link (git and other SCMs) and I do not agree with most of keith is saying Feb 20 18:23:08 zecke: ah. Feb 20 18:23:23 pb__: do you have that link again? Feb 20 18:23:32 let me look Feb 20 18:23:35 pb__: I can't argue with the local support (I guess keith is living in portland) Feb 20 18:24:13 http://lists.freedesktop.org/archives/xorg/2006-February/013113.html Feb 20 18:24:15 that looks like it Feb 20 18:24:25 yeah, indeed he is Feb 20 18:24:38 1.) well kernel people are special :) Feb 20 18:24:43 I guess you can argue with him at fosdem Feb 20 18:25:07 2.) svn AFAIK will not modify existing files (well one text file saying which is 'HEAD') Feb 20 18:25:25 3.) well I can't argue that one - but I'm sure we have svn devels in berlin... Feb 20 18:25:50 4.) well cvs2svn converts everything :) Feb 20 18:26:19 well and he does not take security, merging and daily usage into account Feb 20 18:27:59 right Feb 20 18:28:02 okay, that's interesting Feb 20 18:29:26 I still get schocked when git asks me to do a merge Feb 20 18:33:11 * obergix[work] is away: prepare some food Feb 20 18:33:40 zecke: why? Feb 20 18:33:58 poli: because I need to google :} Feb 20 18:34:15 makes sense Feb 20 18:34:30 poli: maybe this is a gnu ism... but I need to do the hard time merging using Feb 20 18:34:35 git-ls-files --unmerged Feb 20 18:34:42 and git-cat-file blob Feb 20 18:34:46 and calling merge by hand Feb 20 18:36:17 zecke: keep in mind that git is only a distributed model of rcs Feb 20 18:36:37 zecke: and nobody uses rcs without cvs anymore Feb 20 18:36:38 hey... taken by how linus and stallman love each other... shouldn't be any gnuisms in git ;) Feb 20 18:37:01 poli: git log is not working on FBSD and OSX Feb 20 18:37:26 zecke: I wonder why Feb 20 18:37:42 o wait, I know: only the linux kernel uses git Feb 20 18:37:50 lol Feb 20 18:37:51 koen: GNU date gets called :) Feb 20 18:38:57 you raise a very important point Feb 20 18:39:07 the fdo stuff is not linux-only Feb 20 18:39:20 Linus and Stallman hate each other? Feb 20 18:39:26 Oh, that point... Feb 20 18:39:29 yet the 'git' tool depends on GNU programs that are traditionally only on linux distro OSes Feb 20 18:40:07 WTF? livia:/tmp# md5sum /dev/hdb Feb 20 18:40:07 error processing /dev/hdb: failed in buffer_read(fd): mdfile: Input/output error Feb 20 18:40:08 making it inappropriate to push onto developers of software that are used to developing on non-linux platforms Feb 20 18:40:21 ERROR: Nothing provides runtime dependency xhost Feb 20 18:40:23 err? Feb 20 18:40:53 oh Feb 20 18:40:55 i have an error Feb 20 18:41:00 Do I have a bad cd? Feb 20 18:41:48 03koen 07org.oe.dev * r4812c9eb... 10/packages/linux/ep93xx-kernel_2.6.15.bb: Feb 20 18:41:48 ep93xx-kernel: update to derevo3 Feb 20 18:41:48 * ethernet is working Feb 20 18:41:48 * userspace reached with nfsroot Feb 20 18:44:42 shadows: well, that is keith's issue :) Feb 20 18:45:28 i think monotone is the best SCM i've seen Feb 20 18:45:34 the speed issues are the problem Feb 20 18:46:00 shadows: the lua integration makes merging a bit easier (as it can use meld...kdiff3) Feb 20 18:46:10 shadows: but git is moving very fast Feb 20 18:52:42 and git is where the love is right now Feb 20 18:55:05 zecke: http://article.gmane.org/gmane.comp.version-control.monotone.devel/6110 Feb 20 18:57:05 * pb__ go home Feb 20 18:57:06 later all Feb 20 19:02:35 pb__: later pal Feb 20 19:03:19 zecke: the monotone people seem genuinly interested in our needs Feb 20 19:03:27 maybe we should have a dialog Feb 20 19:04:13 right, one should always have a dialogue Feb 20 19:05:03 koen: it would be interesting to have a monotone 0.26 server available Feb 20 19:05:17 to show people that it is way faster already (even if this new code is unoptimized) Feb 20 19:05:24 I could run on on dominion Feb 20 19:05:38 s/on on/one on/ Feb 20 19:05:39 koen meant: I could run one on dominion Feb 20 19:05:42 and we should create static packages so people can test easily (we need the root dir rename one) Feb 20 19:06:07 I'm about to go to the gym, but I wrote a little test for bittest and I'm going to post the result soon Feb 20 19:06:19 nice Feb 20 19:06:19 koen: i would help test a monotone 0.26 server Feb 20 19:06:27 koen: i hear the speed improvements are worth it Feb 20 19:06:47 shadows: about 7-8 times faster pull on an OE tree Feb 20 19:07:00 yeah. that plus decent hardware = less pain Feb 20 19:07:09 and maybe more with another delta storage method Feb 20 19:07:28 shadows: on localhost a pull took only a couple of hours :} (Athlon XP 2600+) FBSD Feb 20 19:07:38 shadows: which is already better than a couple of days Feb 20 19:08:01 zecke: IIRC when working with Gentoo, a pull took about an hour and a half via cvs Feb 20 19:08:18 which was the pinnacle of achievement Feb 20 19:08:19 heh Feb 20 19:08:36 i'll bet they're still using CVS because it is the fastest Feb 20 19:08:39 it took 1:22m sys and user and I'm not sure if I need to add these values (output of time) Feb 20 19:08:51 ah Feb 20 19:08:53 * koen joins shadows at #monotone Feb 20 19:09:29 ah okay Feb 20 19:09:42 a pull took two hours (org.oe.dev) Feb 20 19:10:07 on what hardware? Feb 20 19:10:16 Athlon XP 2600+ 1.5GB ram Feb 20 19:10:17 0.25 takes ~8 hours on a dual opteron Feb 20 19:15:08 okay a pull on localhost with 0.25 was killed after taking more than 12hours :) Feb 20 19:15:13 (I killed it) Feb 20 19:17:14 ||| Feb 20 19:22:35 hi Feb 20 19:23:02 koen: that mail about monotone is about undo/logdir things? Feb 20 19:23:04 hey hrw Feb 20 19:23:08 hrw: yes Feb 20 19:23:17 my work :) Feb 20 19:23:22 :) Feb 20 19:23:59 i was discussing on #monotone when lacked monotone log dirname Feb 20 19:24:18 I need more gettys on c7x0... Feb 20 19:24:37 forgot to add some :( Feb 20 19:24:47 I think more than one Gettys (Jim) won't fit on your c7x0 Feb 20 19:25:06 yeah, X is heavy Feb 20 19:25:19 koen: X is fluuf Feb 20 19:25:44 and over 20 years old so it must be rahter obsolete now.. Feb 20 19:25:59 ~lart c760 keyboard a bit Feb 20 19:25:59 * ibot gives c760 keyboard a bit a good seeing to Feb 20 19:26:03 Steve Jobs never liked it anyway Feb 20 19:26:23 zecke: who liked Steve jobs... Feb 20 19:26:53 hehe Feb 20 19:26:56 zecke: let me put on my black turtleneck and make some statements ;) Feb 20 19:27:33 how goes #monotone talk? Feb 20 19:27:49 I'm writing an email right now :) Feb 20 19:28:14 to oe? or monotone-dev? Feb 20 19:28:31 if 2nd then cc: me pls Feb 20 19:31:51 hrw: updates are now happening to X11 :) Feb 20 19:31:55 XCB work is in place Feb 20 19:32:45 shadows: nice - fdocvs thing? Feb 20 19:33:23 the XCB is not included in my changes to fdocvs bb updates Feb 20 19:33:48 in simple words, XCB is newer, lighter, and replaces Xlib Feb 20 19:34:02 there is a compatibility work called XCB/Xlib Feb 20 19:34:25 xcb is also more async, right? Feb 20 19:34:34 yes Feb 20 19:34:48 it is intended for desktop use also Feb 20 19:34:52 xcb was very hot 3 or 4 years ago Feb 20 19:35:05 the old xcb work seems to be unrelated now Feb 20 19:35:32 Ill ignore it anyway Feb 20 19:35:43 its .dev and its X Feb 20 19:36:02 yeah Feb 20 19:36:30 today i am smoothing the patch for fdocvs-using builds in .dev Feb 20 19:36:54 koen: Ill try to remove keylaunch tomorrow from images, push some oz 3.5.4 things and TAG it Feb 20 19:37:10 nice Feb 20 19:37:21 let mortal kombat^W^Wopenzaurus building begins Feb 20 19:37:22 koen: do you want some bb's to lack the PR setting? Feb 20 19:38:06 shadows: it doesn't hurt Feb 20 19:38:25 but if it's set to 'r0' you can leave it in Feb 20 19:38:27 my first patch (the one you responded to on bug tracker) adds PR to all bb files, and for ones with PR already, bumps the revision Feb 20 19:38:51 i know, i will split that change out more Feb 20 19:39:17 should i still use the changes to add "PR" setting? i heard that -ALL- bb descriptions must have the PR setting Feb 20 19:39:33 bitbake sets it by default to r0 Feb 20 19:39:53 okay Feb 20 19:39:54 cu Feb 20 19:40:09 hrw|gone, zecke: http://rafb.net/paste/results/oTypnP40.html Feb 20 19:40:23 any suggestions/additions before I press send? Feb 20 19:40:59 is there a feature that lets us only update the contents of the directory we're in? Feb 20 19:41:03 i don't know monotone too well Feb 20 19:41:17 i suppose that is not supported Feb 20 19:42:51 shadows: http://rafb.net/paste/results/QjSeRp41.html Feb 20 19:44:21 yes there should be a sanity check for the merge tool Feb 20 19:44:25 i like that suggestion Feb 20 19:45:00 koen: I need to leave now :} Feb 20 19:46:20 wow Feb 20 19:46:39 JustinP was very clever in the work-around for gcc4 and the gtk-webcore builds Feb 20 19:46:49 shadows: was I now? ;-) Feb 20 19:46:58 shadows: surprised you didn't look at it when I committed it Feb 20 19:47:15 shadows: I even pasted it into the channel back then.... Feb 20 19:47:34 nah, i just presumed your genius would save the day Feb 20 19:47:40 and moved on to the rest of my fixes Feb 20 19:47:49 heh Feb 20 19:47:50 ok Feb 20 19:47:58 that's really bloody clever, mate Feb 20 19:48:10 gcc4 fixes? Feb 20 19:48:18 it didn't build this morning Feb 20 19:48:21 koen: gpe-image now builds with gcc4 as the cross-initial Feb 20 19:48:29 with bitbake trunk and OE head Feb 20 19:48:30 well....I took the general format from a webpage on sumulating ? : with python Feb 20 19:49:17 koen: bugs related to gcc4 as cross-initial and OE targets should be directed to me Feb 20 19:49:21 JustinP: only issue I have no PREFERRED_CROSS set Feb 20 19:49:34 JustinP: I have a cset to 'fix' it pending so please do not do anything... Feb 20 19:49:43 shadows: http://rafb.net/paste/results/9E9BSU16.html Feb 20 19:50:08 koen: blame that on JustinP ;) Feb 20 19:50:19 koen: it works for me here Feb 20 19:50:41 i think you need to have that variable set though Feb 20 19:50:52 JustinP: does the build system automagically define that var? Feb 20 19:52:00 cya later Feb 20 19:53:18 * Philippe is back (gone 21:12:36) Feb 20 19:54:45 koen: what is your distro set to? Feb 20 19:55:23 i'm guessing angstrom or maemo Feb 20 19:55:28 shadows: angstrom-2006.9 Feb 20 19:55:32 yes Feb 20 19:55:41 angstrom does not follow the behavior of the other distros Feb 20 19:55:53 jnc@baker:~/opensource/openzaurus/org.openembedded.dev$ grep -rn PREFERRED_VERSION_gcc-cross * Feb 20 19:56:14 follow that and you'll see what i mean; what is the correct thing to follow? Feb 20 19:58:29 shadows: must not, no Feb 20 19:59:01 * JustinP wonders what this cset pending looks like Feb 20 19:59:03 we must have a mechanism to say "this package will only build with x.y.z compiler" Feb 20 20:09:15 shadows: that would be DEPENDS, I suppose. Feb 20 20:09:35 pb_: can you explain more? Feb 20 20:10:01 or give an example of where that is done Feb 20 20:10:35 DEPENDS = "gcc-cross-3.4.4" Feb 20 20:15:37 JustinP: what do you think Feb 20 20:16:28 or, alternatively, add an anonymous function that checks the compiler version and blows up if it isn't what you want. Feb 20 20:16:38 oh Feb 20 20:16:57 hey, what arguments do you give to 'diff' tool? Feb 20 20:17:06 i've been using -bur but that blows up on Makefiles Feb 20 20:17:32 uprN Feb 20 20:18:38 hmm Feb 20 20:18:53 will PREFERRED_PROVIDER win over DEFAULT_PREFERENCE? Feb 20 20:18:59 yes Feb 20 20:19:20 DEFAULT_PREFERENCE is pretty weak, virtually anything will beat it Feb 20 20:19:30 ok, thanks Feb 20 20:19:49 I think the bitbake manual might have some words about that, actually. Feb 20 20:20:01 I certainly remember writng a description of how the resolution process works at one point. Feb 20 20:23:14 hey all, what do you guys think about moving damageext and compositeext ... etc. into packages/xlibs? Feb 20 20:23:32 that is according to where they get their files from SCM Feb 20 20:23:40 i.e. xlibs fdo cvs Feb 20 20:24:09 packages/gtk-webcore and packages/cairo currently do this Feb 20 20:24:30 sounds like a reasonable plan to me Feb 20 20:24:41 * france is away: Away Feb 20 20:24:44 does the directory name (damageext) factor into any of the variables? Feb 20 20:24:48 no Feb 20 20:24:54 it's just for convenience Feb 20 20:24:56 okay so, that means just the name of the bb Feb 20 20:25:32 in Gentoo we had a system where the directory name and capitolization would translate to a variable that could be used in the build description Feb 20 20:25:42 moving directories around like that would pooch the build Feb 20 20:25:53 you're saying it's just for convenience, is that 100% sure? Feb 20 20:26:16 yeah. you could (approximately) do "mv */* opie-powerchord/" if you wanted, and everything would still work just fine. Feb 20 20:26:27 excellent Feb 20 20:26:30 that actual command would probably fail because all the "files" directories would collide, but you get the general idea Feb 20 20:26:35 i'll add that to my list of changesets to make Feb 20 20:26:44 oh hmm Feb 20 20:26:46 good point Feb 20 20:27:08 plus, obviously, having everything inside an opie-powerchord directory would be a dim plan in general. Feb 20 20:27:14 03rw 07org.oe.dev * r0de420be... 10/packages/gtk-webcore/ (4 files): Feb 20 20:27:14 gtk-webcore: fix parse errors in 20060212 snapshots. Feb 20 20:27:14 - If you absolutely have to mess with packages I maintain please make Feb 20 20:27:14 sure you don't break anything. Feb 20 20:27:42 * shadows looks nervous Feb 20 20:27:56 pb_: yah, sorry. guess I should read a current version of it one of these days. Feb 20 20:28:09 shadows: that wasn't directed at you Feb 20 20:28:25 reenoo: it only breaks if the variable is not set Feb 20 20:28:33 i had no idea it was not set in Angstrom and maemo Feb 20 20:28:53 i only checked familiar and openzaurus, the more popular targets. my mistake Feb 20 20:29:16 it doesn't really matter where it's set or not. it should never blow up. Feb 20 20:29:25 true Feb 20 20:29:50 the no-threadsafe-statics flag only exists in gcc4 though Feb 20 20:30:36 i can't test for gcc3, since gcc3 doesn't exactly output sane code on my machine (amd64) Feb 20 20:38:08 03koen 07org.oe.dev * ref0ce499... 10/packages/linux/ep93xx-kernel_2.6.15.bb: Feb 20 20:38:08 ep93xx-kernel: update to derevo4 Feb 20 20:38:08 * fixes reboot Feb 20 20:48:52 * shadows busily hacks away at the fdocvs changeset Feb 20 20:48:54 ugh Feb 20 20:49:19 insane quantity of files affected by the cvs URL Feb 20 20:50:20 shadows: that's why we usually put a magic var in bitbake.conf Feb 20 20:50:28 shadows: delete 'em all. let them eat tarballs. Feb 20 20:50:41 i'm centralizing the vars Feb 20 20:50:48 it's just a workaround for now Feb 20 20:51:06 but it will allow us to easily grok for the files that need to be changed, when we have a proper fix Feb 20 20:51:09 unlike now Feb 20 20:51:36 btw i did a full gpe-image build with the previous changeset Feb 20 20:51:38 it worked fine Feb 20 20:51:50 so these changes i'm smoothing out should also inherently work Feb 20 20:52:20 ah, it's always nice when changes are inherently correct. Feb 20 20:52:23 zero defects! Feb 20 20:52:33 heh Feb 20 20:52:54 well there was a tiny bug in the first changeset, and it was easy to fix. i'm going to have to update the bbclass files i posted Feb 20 20:53:05 one of them (xorg.bbclass) is -obviously- wrong Feb 20 20:53:22 other than that, it built fine. Feb 20 20:53:34 in fact, when the build broke, it was obvious where to fix the problem Feb 20 20:53:38 =) Feb 20 21:01:29 i guess this should instead all be in maybe some freedesktopcvs bbclass Feb 20 21:01:31 i don't know Feb 20 21:01:50 the changes i'm making now will nontheless make it easier to go to a better solution later Feb 20 21:01:54 so i'm not worried about it now Feb 20 21:03:22 03rw 07org.oe.dev * r21f1a517... 10/ (61 files in 56 dirs): various packages and bitbake.conf: introduce FREEDESKTOP_CVS and make use of it. Feb 20 21:03:31 god dammit Feb 20 21:03:39 here i am making all these changes Feb 20 21:03:54 * shadows throws a chair and threatens to kill inanimate objects Feb 20 21:04:05 well, here a sed script did all the work Feb 20 21:04:32 did you do a search on 'pdx' or something? Feb 20 21:06:44 http://bugs.treke.net/show_bug.cgi?id=706 Feb 20 21:07:23 shadows: I've back moving all the xlibs into one directory - I've been meaning to ask about doing that Feb 20 21:07:50 RP: yeah, it makes sense IMO to have them in one dir (if that's the kind of thing that is okay to do) Feb 20 21:08:08 especially if they are from the same specific CVS branch Feb 20 21:08:21 shadows: It was once frowned upon but IMO the current directory is unmanagable Feb 20 21:08:36 s/directory/directory structure Feb 20 21:08:39 mmhm Feb 20 21:08:59 i have only the gentoo and debian ways to compare with Feb 20 21:09:17 debian is, you make several packages out of a single build description Feb 20 21:09:21 i don't think that follows what we're doing at all Feb 20 21:09:43 gentoo is, you have "sections" and a seperate directory for each package Feb 20 21:09:49 we don't have sections Feb 20 21:09:55 Here its just convinience. I think it makes logical sense to combine them though Feb 20 21:09:58 now would be a good time to think about whether we want sections Feb 20 21:10:37 sections feel wrong in OE somwhow... Feb 20 21:10:43 03eFfeM 07org.oe.dev * r20f293e2... 10/packages/spca5xx/ (spca5xx-20060202/Makefile.patch spca5xx_20060202.bb): spca5xx: added release 20060202 (on request, builds fine, cannot test this as I do not have this cam) Feb 20 21:10:53 agreed Feb 20 21:12:46 hrmmm multiple heads Feb 20 21:13:16 is that usually happening while things are synchronizing accross servers? Feb 20 21:13:36 no, that happens when someone doesn't merge Feb 20 21:13:57 oh Feb 20 21:14:00 could you merge? Feb 20 21:15:07 actually i think it's syncing now Feb 20 21:15:28 it does appear that the tree is unmerged, when people make big commits that take a while to propogate Feb 20 21:15:40 no Feb 20 21:15:49 no? Feb 20 21:15:54 no Feb 20 21:16:13 it happens when people make commits using the same ancestor Feb 20 21:16:19 oh hmm Feb 20 21:16:33 so after pushing a change, you'd have to pull again, then merge Feb 20 21:16:35 and push again? Feb 20 21:16:38 shadows: it is actually something monotone considers "natural" Feb 20 21:16:44 But it is damn annoying! Feb 20 21:16:47 heh Feb 20 21:17:15 Makes sense when you think your changes won't be spolied by an update... but... Feb 20 21:17:38 03rw 07org.oe.dev * r517c224b... 10/packages/ (10 files in 5 dirs): more fd.o hosted packages: use FREEDESKTOP_CVS. Feb 20 21:19:11 reenoo: you borked the useage of the xlibs bbclass, i think Feb 20 21:19:22 i.e. made it depreciated Feb 20 21:19:34 there was an xlibs bbclass before that defined the FDO CVS server Feb 20 21:19:47 please have a look at that, and also comment on bug 706 Feb 20 21:20:33 nah, that's a different story Feb 20 21:21:02 although it should use FREEDESKTOP_CVS too, obviously Feb 20 21:27:06 03rw 07org.oe.dev * r50ca4355... 10/classes/xlibs.bbclass: xlibs.bbclass: use FREEDESKTOP_CVS as well. Thanks to Eric Shattow for spotting. Feb 20 21:28:10 stick a fork in my eye ;) Feb 20 21:28:22 okay well, back to what i was working on a few days ago Feb 20 21:32:59 hey is anyone looking for a Sharp serial cable? Feb 20 21:33:14 03florian 07org.oe.oz354fam083 * rea987265... 10/packages/gpe-conf/ (files/fixsegfault.patch gpe-conf_0.1.30.bb): gpe-conf: Add release 0.1.30 and a patch to fix a remaining issue. Feb 20 21:33:15 there is one being sold (with SL-5500 attached ;) Feb 20 21:33:18 03florian 07org.oe.oz354fam083 * r4557c88c... 10/conf/distro/preferred-gpe-versions-2.7.inc: preferred-gpe-versions-2.7: Use gpe-conf 0.1.30 including several bugfixes. Feb 20 21:33:27 shadows: Which country? Feb 20 21:33:30 USA i think Feb 20 21:33:51 If it was the UK I might have been interested :) Feb 20 21:33:52 i bought one from a china seller, and still have not received it Feb 20 21:34:00 it's been a couple of weeks now Feb 20 21:34:05 :-/ Feb 20 21:34:06 i think that i may have lost out on $50usd Feb 20 21:34:37 heh. it's probably just on the infamous slow boat from china. Feb 20 21:34:49 * shadows laughs Feb 20 21:34:56 that is true Feb 20 21:35:10 Thats a popular ship Feb 20 21:35:14 when i did sales representation, for mfg companies, the "boat from china" was never on time Feb 20 21:35:39 in fact, if it got to the right destination on time, there was always some reason for it to be turned around and sent back to china Feb 20 21:35:47 where it would be sent back again Feb 20 21:35:50 and take twice as long Feb 20 21:36:09 eBay #5867800043 Feb 20 21:36:25 also includes a camera attachment Feb 20 21:36:47 RP: are you interested in the camera? Feb 20 21:37:02 i may buy this and donate it to a dev if they want/need it for better support Feb 20 21:37:08 shadows: The original Sharp one? Feb 20 21:37:11 yes Feb 20 21:37:52 shadows: Its a binary only driver and not particularly good quality now - I've not considered it worth any development effort... Feb 20 21:38:49 ah Feb 20 21:41:15 i'm looking around to find an addressbook PDA for my grandfather, replacing his old ZR series organizer Feb 20 21:41:21 03florian 07org.oe.dev * r98e42d2d... 10/packages/gpe-conf/ (files/fixsegfault.patch gpe-conf_0.1.30.bb): gpe-conf: Add patch to fix segfault in 0.1.30. Feb 20 21:41:31 the Palm units have no keyboard and are _very_ difficult to use for an elderly person Feb 20 21:41:57 i think that the text on the zaurii looks too small Feb 20 21:42:04 suggestions? Feb 20 21:42:11 I guess you can make the text on the Z as big as you want Feb 20 21:42:15 hmm Feb 20 21:42:31 that's true, the screens and keyboards are smaller than the ZR series though Feb 20 21:42:43 i'm concerned about the text on the keys being way too small Feb 20 21:43:19 if all he wants is addressbook, you might try something like one of the old Psion units, a Revo or something. I don't know if they're still made, but you can probably find them on ebay. Feb 20 21:49:34 interesting Feb 20 21:49:40 those look perfect in form Feb 20 21:52:34 reenoo: that commit to webcore fixed the gcc4 build, thanks Feb 20 21:55:34 koen|tv: np, I just fixed the parse error. shadow did the gcc4 related part. Feb 20 21:57:39 shadows, if all you want is an address book buy a ROX Feb 20 21:57:50 or is it REX Feb 20 21:57:53 yeah, just an addressbook Feb 20 21:57:53 one or the other Feb 20 21:57:59 emte: REX Feb 20 21:58:32 cheap device originally made to clipon pagers etc Feb 20 21:58:34 for the old man, he needs something with a large font that's easy to work; not to say that he isn't capable of complicated computer functions, it's just not worth his time to be mucking about with Feb 20 21:58:56 his daughter gives him a Palm IIIc Feb 20 21:59:02 i just about died laughing at that Feb 20 21:59:13 what is he going to do with a freaking Palm pilot? Feb 20 21:59:48 i barely do anything interesting with *mine*, and i've still got my vision and plenty of time to mess with configuration conflicts Feb 20 22:01:29 http://cgi.ebay.com/Almost-new-Xircom-REX-6000-Micro-PDA-PCMCIA-NR_W0QQitemZ5868290404QQcategoryZ38331QQrdZ1QQcmdZViewItem Feb 20 22:01:39 shadows, a basic REX device Feb 20 22:02:12 thats actually the nicest REX i've come across .... Feb 20 22:03:18 it's kind of tiny Feb 20 22:03:26 are those easy to read? Feb 20 22:03:30 yup thats what makes it nice Feb 20 22:03:38 fits in your pocket Feb 20 22:03:44 oh Feb 20 22:04:00 it does look nice, i'm thinking about something with a very large screen though, maybe wide format Feb 20 22:04:22 remember if you expect him to use it he has to be comfortable carying it arround Feb 20 22:04:33 he's probably not going around town with it Feb 20 22:04:44 if he is, it's going to live in a briefcase Feb 20 22:05:04 one of our buddies has that sort of REX device, a little CF format card Feb 20 22:05:05 http://www.the-gadgeteer.com/review/rex_6000_review Feb 20 22:05:08 it was great until it died Feb 20 22:06:06 review suggests finding a REX 5000 Feb 20 22:06:29 oh wait thats backwards i think .. Feb 20 22:07:55 http://www.epinions.com/content_11730521732 Feb 20 22:09:17 interesting ... Feb 20 22:09:21 Citizen DataSlim 2, which is the same hardware and is still in production in Japan, Feb 20 22:10:12 hmm looks like the xzire Feb 20 22:10:17 zire* Feb 20 22:10:21 anyway off to physio Feb 20 22:10:35 :) Feb 20 22:10:43 the Psion 5 looks about right Feb 20 22:10:56 it runs on AA batteries, has a decent keyboard Feb 20 22:11:16 buy him a sidekick :P Feb 20 22:31:04 * Philippe is away: visual contact - melancholic dreams Feb 20 22:34:42 re Feb 20 22:34:49 hi zecke Feb 20 22:35:38 RP: I have a list of native packages RDEPENDING on non native versions Feb 20 22:36:00 RP: I don't want to teach bitbake about native packages Feb 20 22:36:11 RP: I think the proper fix is to change our meta data Feb 20 22:36:25 zecke: The meta data is wrong at the moment, yes Feb 20 22:36:49 zecke: The question is whether we set RDEPENDS="" or set it to native packages Feb 20 22:37:21 RP: it is funny :) Feb 20 22:37:25 One way around the ASSUME_PROVIDED problem might be to agree that ASSUME_PROVIDED lists both depends and rdepends? Feb 20 22:37:31 RP: quilt-native needs patch-native Feb 20 22:37:51 RP: and patch native needs 'patch' (as it can't use quilt) available... Feb 20 22:38:08 RP: and if you require it, it shouldn't be in a RDEPEND :) Feb 20 22:38:40 zecke: Do you require it at build time or runtime? Feb 20 22:38:57 zecke: We're always going to require some ASSUME_PROVIDED packages Feb 20 22:39:14 RP: for quilt-native, we manually use 'patch' to patch quilt Feb 20 22:39:44 RP: well, I think patch and gcc are cases where you simply 'require' them Feb 20 22:39:56 Adding patch-native to the default assume_provided is safe IMO Feb 20 22:40:34 It would be nice if the default ASSUME_PROVIDED line was the same as our list of prerequisite software Feb 20 22:41:16 zecke: We also have an explode_deps bug hanging around: See part of http://www.rpsys.net/openzaurus/temp/bitbake_git-r1.patch Feb 20 22:41:57 RP: (not that I understand the explode bug) but we should fix the copy in OE as well Feb 20 22:42:29 zecke: Think of a version of the form (>= 2.3.4) - the space being critical Feb 20 22:42:35 zecke: What do you think about allowing both providers and runtime providers in ASSUME_PROVIDED? Feb 20 22:43:18 I agree we need to check the copy of that function in OE Feb 20 22:45:29 RP: http://pastebin.ca/42390 Feb 20 22:46:58 I'm a bit exhausted from gym, so give me some minutes to recover (before I stress my multitasking skill again) Feb 20 22:48:12 zecke: I think I see a flaw in your check as you might have only checked RDEPENDS, not RDEPENDS_${PN} Feb 20 22:48:26 zecke: but ignore me for a few minutes - I also have something I need to finish Feb 20 22:48:47 RP: you can check the test soon :) Feb 20 22:53:33 RP: http://svn.berlios.de/viewcvs/bitbake/trunk/bitbake_qa/modules/depends_checker/depends.py?rev=368&view=markup Feb 20 22:53:46 RP: it has other bugs but it looks at RDEPENDS_${PN} :) Feb 20 22:54:18 okay I will get some food now Feb 20 22:55:26 zecke: when you get back I have some comments ;-) Feb 20 22:55:29 hi Feb 20 22:56:30 hrw|gone: yes, I'm planning to do that. But I need to verify kernel 2.4 functionality first Feb 20 22:56:45 hi CoreDump|home Feb 20 22:57:17 hello RP Feb 20 22:57:28 I have not left Feb 20 22:58:19 zecke: Basically, I dislike the idea of using PN as an override as some packages probably end up with values in both RDEPENDS and RDEPENDS_${PN} Feb 20 22:58:30 zecke: and you should be using explode_deps ;-) Feb 20 22:59:17 (you have commit access) :) Feb 20 22:59:46 true. I have a job to finish, then I might use it :) Feb 20 23:00:10 RP: for the explode_deps thing, could you send me a list of strings and how they should end up :) Feb 20 23:00:51 * zecke doesn't know how he should finish this paper... :} Feb 20 23:01:00 zecke: xxx (xx anything in brackets) should become simply xxx as far as bitbake is concerned Feb 20 23:01:42 shadows: I don't know what to think Feb 20 23:01:53 zecke: Note the version in OE does care about the version string. the one in bitbake does not Feb 20 23:02:17 I have forget how to get the gpe-image to configure /etc/modules correctly in first boot. I tried adding things like following kind of things to board-h6300.conf but when I booted first time, the /etc/modules was empty. Feb 20 23:02:18 RP: I don't suppose you've looked at the corgi_ssp stuff? I'm going to try to look at it now.... Feb 20 23:02:22 module_autoload_omapts = "omapts" Feb 20 23:03:22 that sounds about right. did you rebuild the kernel afterwards? Feb 20 23:03:51 my slive of bread should be toasted by now Feb 20 23:03:56 slice even Feb 20 23:04:03 thanks for the bulletin Feb 20 23:05:19 pb_: I build the whole gpe-image from scratch. It failed couple of times and I needed to edit the machine-conf but those module_autoload= lines were there unmodified since the beginning. Feb 20 23:05:36 lamikr: what do you have in /etc/modules.d/? Feb 20 23:05:58 pb_: you are welcome :) Feb 20 23:06:02 pb_: do you want some as well? Feb 20 23:06:09 JustinP: The good/bad news is that the max1111 didn't use the bit bang code so its not that at fault (the lcd used that) Feb 20 23:06:10 zecke: no thanks, I just ate dinner Feb 20 23:06:22 you are lucky :) Feb 20 23:06:53 RP: I have one question: if I remove the BUILD_ALL_DEPS from native.bbclass and build the opie-image Feb 20 23:07:01 pb_: At least after boot I do not have /etc/modules.d at all. Feb 20 23:07:12 the RDEPENDS get build anyway Feb 20 23:07:24 03rw 07org.oe.dev * rd7c8c3fb... 10/packages/fontconfig/fontconfig_2.2.95.bb: fontconfig: fix SRC_URI. part of a patch submitted by Eric Shattow in Bug #706 Feb 20 23:07:45 lamikr: oh, sorry, it's /etc/modutils/ Feb 20 23:07:49 zecke: Yes. I'm not sure that's a problem? Feb 20 23:07:53 argh Feb 20 23:08:01 RP: well that's good news of a kind. I'll look into the command thing... Feb 20 23:08:28 JustinP: I have seen the max1111 give weird readings for the power management code so if there was a bug in the max1111 code, I'd like to find it Feb 20 23:08:42 JustinP: but that would be attributed to other things... Feb 20 23:08:43 RP: this is due the opie-image.bb BUILD_ALL_DEPS right? Feb 20 23:08:48 s/would/could Feb 20 23:09:15 zecke: anything that inherits the image .bbclass, yes Feb 20 23:09:21 note to self - read the bb before building it Feb 20 23:09:41 CosmicPenguin: ah, you accidentally bitbaked r00tk1t.bb? Feb 20 23:10:00 heh Feb 20 23:10:28 I hate it when that happens Feb 20 23:10:47 RP: hmmm... Feb 20 23:10:58 pb_: I do not have even that... Should I add "modutils" somewhere to the h6300-conf. Here is the current "uncommitted" version of h6300.conf I have tried to create. http://pastebin.ca/42407 Feb 20 23:11:16 JustinP: It shouldn't be too difficult to establish my functions are equivalent to sharp's. Feb 20 23:11:35 JustinP: You could also try copying sharp's functions into the driver to compare their readings Feb 20 23:11:39 lamikr: is kernel-module-omapts actually in your image? If so, what files does it contain? Feb 20 23:12:00 JustinP: see arch/arm/mach-pxa/pxa_ssp.c for them Feb 20 23:12:23 RP: ah, thanks (was just grepping) Feb 20 23:12:34 RP: do we want native packages to have RDEPENDS at all? Feb 20 23:13:58 zecke: I still say yes and that we should have ASSUME_PROVIDED handling the ones we don't want built Feb 20 23:14:40 pb_: Not 100 % what you mean but I have omapts driver module under kernel. Exact location is "/ipaq_rootfs/lib/modules/2.6.16-rc3-omap1-h6300/kernel/drivers/input/touchscreen/omap/omapts.ko" Feb 20 23:14:43 this means a patch-native.bb may not use 'patch'? Feb 20 23:15:12 lamikr: ah, do you mean that you have defeated the kernel module splitting? Feb 20 23:15:17 zecke: Obviously there are some things that must be provided by the host system Feb 20 23:15:18 if so, yeah, that will also break autoloading Feb 20 23:16:05 zecke: As an argument against myself, python-native is a tricky one. We can't ASSUME_PROVIDED it as python itself needs it to build and yet python is a prerequisite of bitbake/oe Feb 20 23:16:27 pb_: Not sure... I have just selected in my .config that omapts is build as a module. Feb 20 23:16:47 lamikr: well, which package contains the .ko file you mentioned? Feb 20 23:16:52 RP: this might be a good start and documenting the REQUIREMENTS Feb 20 23:17:28 damn it Feb 20 23:17:36 zecke: I did see it having that advantage :) Feb 20 23:18:06 when was gtk-webcore touched? Feb 20 23:19:07 pb_: I have not tried to open, but tmp/deploy/ipk has "kernel-module-omapts-2.6_2.6.14.3-r0_h6300.ipk" Feb 20 23:19:17 RP: well, the MAX1111 defines seem to be equivalent Feb 20 23:20:09 lamikr: what files are inside that package? Feb 20 23:22:22 reenoo|afk: *sorry* Feb 20 23:23:14 03freyther 07org.oe.dev * raa1b3639... 10/packages/gtk-webcore/ (4 files): Feb 20 23:23:14 gtk-webcore: Feb 20 23:23:14 Default to 1.0 if no PREFERRED_VERSION Feb 20 23:23:14 gcc-cross is set. Feb 20 23:23:18 03freyther 07org.oe.dev * r623eed7c... 10/classes/tinderclient.bbclass: Feb 20 23:23:18 classes/tinderclient.bbclass: Feb 20 23:23:18 -do print less information Feb 20 23:23:19 -fix a nice issue with log that became Feb 20 23:23:21 an array due the readlines. Feb 20 23:24:39 RP: should we add a method Feb 20 23:24:52 that automatically add '-native' to RDEPENDS Feb 20 23:25:16 pb_: It has ./lib/modules/2.6.14.3-omap1-h6300/kernel/drivers/input/touchscreen/omap/omapts.ko, /DEBIAN/control, postinst and postmdr files and /etc/modutils/omapts file Feb 20 23:25:28 okay Feb 20 23:25:29 RDEPENDS = "$@{oe.create_depends(['m4', 'autoconf'],d)} Feb 20 23:25:44 lamikr: so, you need to figure out why that /etc/modules/omapts is not showing up in your installed system Feb 20 23:26:28 zecke: Given most bb files include their non-native counterparts, it would be even better if we could just translate that... Feb 20 23:26:41 translate their RDEPENDS Feb 20 23:26:55 this requires to do the 'include' before the inherit Feb 20 23:27:34 reenoo|afk: I will disapprove my merge (due the meld error...) once viewmtn is available Feb 20 23:27:50 ~lart udev Feb 20 23:27:50 * ibot slaps udev around with a large trout Feb 20 23:28:07 zecke: I know, I'm not sure its technically possible :-/ Feb 20 23:28:38 zecke: I don't think the order should matter much. You can use a function. Feb 20 23:29:35 pb_: like RDEPENDS := "${@fix_up(d)}"? Feb 20 23:30:19 no, that would indeed have the ordering problem. more like: Feb 20 23:30:22 RP: one good thing about 'patch' is. I have BSD patch and a GNU patch works way better with quilt Feb 20 23:31:18 python __anonymous () { bb.data.setVar("RDEPENDS", bb.zecke.mungeRdepends(), d) } Feb 20 23:31:20 kind of thing Feb 20 23:31:54 pb_: do you know when __anonymous is evaluated? Feb 20 23:31:59 yes Feb 20 23:32:10 pb_: It is not the only missing driver... It seems that by default I have only one driver installed under /lib/modules/kernel/2.6.14.3. It is kernelt/net/ipv4/netfiler/ip_tables.ko... Strange thing is that I have not specified anything ip_tables related to http://pastebin.ca/42407 Feb 20 23:32:45 pb_: so enligthen me please :) Feb 20 23:32:52 zecke: at the end of parsing Feb 20 23:33:23 pb_: I had hoped for that. Now let us find out if it is still true Feb 20 23:34:40 (I think it is) Feb 20 23:35:59 lamikr: so you have some modules for 2.6.14.3 and some for 2.6.16-rc3? that can't be good. Feb 20 23:36:16 presumably you are only running one kernel at any one time Feb 20 23:37:29 anyway, this doesn't sound like an autoloading problem so much as the driver just plain being not installed. Feb 20 23:37:38 pb_: Sorry, I had installed the 2.6.16 modules afterwards by hand to rootfs. But oe build 2.6.14.3 kernel and put only this ip_tables.ko driver to gpe-image.tar.bz2 Feb 20 23:38:45 okay. sounds like you need to add the modules you want to ${HANDHELD_MODULES} or whatever your equivalent to that is. Feb 20 23:38:50 Is this correct in my machine-conf: Feb 20 23:38:51 BOOTSTRAP_EXTRA_RDEPENDS += "${@linux_module_packages('${H6300_MODULES}', d)} Feb 20 23:39:04 looks about right, yeah Feb 20 23:39:12 what's ${H6300_MODULES}? Feb 20 23:39:31 # Feb 20 23:39:33 H6300_MODULES = "omapts i2c-omap pca9535 omap-keypad nfs \ Feb 20 23:39:33 zecke: let's hope it still is Feb 20 23:39:34 # Feb 20 23:39:36 bluetooth rfcomm bnep l2cap hci_uart h6300_bt" Feb 20 23:39:47 that looks ok Feb 20 23:39:56 what are the dependencies on the generated task-bootstrap.ipk? Feb 20 23:40:23 they are in: http://pastebin.ca/42407 Feb 20 23:41:04 eh, that looks like your MACHINE.conf or something Feb 20 23:41:16 are you sure that is the right pastebin url? Feb 20 23:43:04 pb_: I thought you meant that. How can I check the task-bootstrap.ipk dependencies? Feb 20 23:43:20 use "dpkg-deb -I", or "ipkg status" Feb 20 23:45:34 pb_: Sorry I can not check it anymore. I stupidly deleted my tmp dir as I planned to do new build attempt from scratch... Feb 20 23:45:38 * france is back (gone 03:21:00) Feb 20 23:49:18 pb_: But I dound my taksbootstap.control file from rootfs that contains dependencies: it is in http://pastebin.ca/42425 Feb 20 23:54:56 and it seems that for some reason it does not list kernel modules as a dependencies... Feb 20 23:56:18 RP: the automatic replacing won't work Feb 20 23:56:38 e.g. foo-common is okay in RDEPENDS Feb 20 23:57:15 zecke: ok, we'll jsut have to go though and set the RDEPENDS correctly then I guess Feb 20 23:57:21 java-virtual-machine should be virtual/java-machine-native Feb 20 23:57:45 zecke: Did you have any thoughts on whether allowing ASSUME_PROVIDED to cover both types of depends was good/bad? Feb 20 23:58:33 RP: I do not see any issue with it - yet Feb 20 23:59:58 http://pastebin.ca/42432 Feb 21 00:00:24 was my attempt at generically replacing RDEPENDS Feb 21 00:00:50 It was a good idea but isn't going to work :-/ Feb 21 00:00:57 http://pastebin.ca/42434 Feb 21 00:01:02 were the first errors :) Feb 21 00:01:18 'NoneType' as the RDEPENDS is a method (from autotools.bbclass) Feb 21 00:01:59 whatt still would work is a make_rdepend(['bzip2', 'patch', 'diffstat']) method Feb 21 00:02:12 it could automatically expand to the right thing: Feb 21 00:02:32 What is good about it is, you can put it into the .inc file (or similiar) Feb 21 00:02:46 and you do not need to reset the RDEPENDS after you included a file Feb 21 00:03:03 Its probably too much effort when we can just add the correct RDEPENDS lines... Feb 21 00:03:28 RP: well you have these then at two places :) Feb 21 00:03:43 I think as we only have about 20 RDEPENDS to fix I could live with that Feb 21 00:03:49 but my OOP mind... Feb 21 00:04:18 Its no more duplication than many of the .bb files have and it is a valid difference between the parent and the -native version... Feb 21 00:04:26 I know what you mean though Feb 21 00:04:44 I've wondered about automating it... Feb 21 00:05:03 RP: how much time do you hav now? Feb 21 00:05:34 zecke: I should probably be sleeping. Why? :} Feb 21 00:05:44 RP: well then go to bed! Feb 21 00:06:04 I think I will do the same :} Feb 21 00:06:30 That's good idea, I will also put my self to s3 state. Feb 21 00:06:39 well, sleep well everyone Feb 21 00:06:43 :) Feb 21 00:06:53 RP: I will fix the meta data tomorrow Feb 21 00:06:56 zecke: I'll fix the two knows issues in bitbake, then do so... Feb 21 00:07:00 goodnight Feb 21 00:07:18 RP: and if you are done with bitbake I will test, or see if I have more time... Feb 21 00:09:09 wow one line written on my paper... deadline is friday :} Feb 21 00:18:12 'night all Feb 21 00:18:29 'night RP Feb 21 00:40:59 It might be my imagination, but I think udev 084 is actually slower Feb 21 00:51:38 CosmicPenguin: add OPTIONS="last_rule" to your tty* and vc* rules to see if that speeds it up Feb 21 01:25:36 * CosmicPenguin does that Feb 21 01:44:21 A little faster, I guess Feb 21 01:45:08 I should at this point disclose that I'm running it on a processor simulator, so slowdowns are magnified Feb 21 01:45:13 100x fold Feb 21 01:45:29 WEll, not that much - 50x, I guess Feb 21 01:48:53 home tie Feb 21 01:48:55 time Feb 21 01:48:56 seesh Feb 21 01:49:03 * CosmicPenguin goes away before his brain melts further Feb 21 02:37:40 03rwhitby 07org.oe.dev * rbd1e4d7c... 10/packages/linux/ixp4xx-kernel/2.6.16/ (3 files): Added I2C support for the Loft Feb 21 02:37:45 03rwhitby 07org.oe.dev * re2df25d7... 10/packages/linux/ (16 files in 2 dirs): ixp4xx-kernel: Updated for 2.6.16-rc4 from CVS patch repo Feb 21 03:25:07 03coredump 07org.oe.dev * r583dc1af... 10/packages/gpe-bootsplash/ (files/speed.patch gpe-bootsplash_1.15.bb): Feb 21 03:25:07 gpe-bootsplash: Feb 21 03:25:07 Dump /dev/fb0 after the first successful launch of bootsplash and use the dump to display the splashscreen from that point on. Speeds up display of large bootsplash-theme _a lot_. Handles theme changes as well. Feb 21 04:11:48 maybe i should mention the libmb thing here too Feb 21 04:11:59 i'm trying to fix the "tiny matchbox panel menu font" bug Feb 21 04:12:06 it's allegedly fixed in libmb svn Feb 21 04:12:22 diff = http://cuodan.net/~jnc/openz/matchbox_lib_differences-svn20060220_and_v1p7.diff Feb 21 04:12:40 could someone help and point out which parts are relevent to fixing the font problem? Feb 21 07:40:11 morning Feb 21 07:41:51 morn Feb 21 07:42:44 ~lart keylaunch & matchbox Feb 21 07:42:44 * ibot blasts keylaunch & matchbox with a huge firehose then strangles keylaunch & matchbox with it Feb 21 08:03:13 hey hrw how much do you know about the battery differences btwn the h36 and the h22? Feb 21 08:04:00 i am finding it a bit odd that there is a h22 specific driver that uses the DS2760 Feb 21 08:05:50 emte: nothing Feb 21 08:06:26 emte: I'm not familiar with ipaq internals at all Feb 21 08:06:38 :( Feb 21 08:07:22 perhapse i need to ask pb_ when he wakes up Feb 21 08:10:00 morning all Feb 21 08:10:29 hi RP koen Feb 21 08:10:41 hey emte & hrw & RP Feb 21 08:10:43 hi koen Feb 21 08:11:01 koen: A couple of fixes went into bitbake Feb 21 08:11:03 hey koen , RP Feb 21 08:11:22 RP: ah cool Feb 21 08:11:25 * koen svn up Feb 21 08:11:31 i dont suppose either of you know the answer to the question i just posed to hrw ? Feb 21 08:13:04 cu Feb 21 08:13:14 cya Feb 21 08:13:48 emte: I know little about ipaq batteries Feb 21 08:13:51 emte: the h36xx all use a micro controller hooked up to the serial bus, while other ipaqs use an asic Feb 21 08:13:55 <_law_> someone here who got eds-dbus build? Feb 21 08:14:07 probably RP Feb 21 08:14:19 _law_: I might have some updates from that... Feb 21 08:14:26 s/from/for Feb 21 08:14:49 koen, yeah its just that i am looking at the h22 battery driver and its using the DS2760... the same one that the h36 series uses i am wondering why it is specific to the h22 Feb 21 08:15:05 <_law_> RP, http://bugs.treke.net/show_bug.cgi?id=700 Feb 21 08:15:17 emte: the h2200 battery driver is the driver for the asic part iirc Feb 21 08:15:30 <_law_> has anyone tried tinymail yet? Feb 21 08:16:26 <_law_> https://svn.cronos.be/svn/tinymail/trunk/ Feb 21 08:23:40 aha i see now koen, thnks Feb 21 08:36:42 _law_: It looks like it didn't find db... Feb 21 08:40:21 re Feb 21 08:40:27 wb hrw|work Feb 21 08:40:55 * RP twiddles thumbs waiting for monotone... Feb 21 08:41:14 you must have pretty lean thumbs by now ;) Feb 21 08:42:03 RP: please send your problems with monotone to the monotone people as well: http://lists.gnu.org/archive/html/monotone-devel/2006-02/msg00180.html Feb 21 08:45:19 my thread ;) Feb 21 09:05:27 morning Feb 21 09:05:41 ~seen mickeyl Feb 21 09:06:00 mickeyl is currently on #oe #opie #handhelds.org. Has said a total of 11 messages. Is idling for 1d 19h 34m 27s, last said: 'argouml?'. Feb 21 09:07:19 <_law_> RP, should i try to build db3_3.2.9.bb ? Feb 21 09:17:42 _law_: I've just updated eds-dbus - a configure parameter had changed Feb 21 09:18:00 I'm just hoping it can still find the OE db install... Feb 21 09:18:13 <_law_> RP, ok i?ll try to build Feb 21 09:20:01 <_law_> RP, disable_orbit.patch doest apply Feb 21 09:21:02 03rpurdie 07org.oe.dev * r5ccea2ad... 10/packages/eds/eds-dbus_svn.bb: eds-dbus: Update configure commandline to match upstream changes Feb 21 09:21:07 03rpurdie 07org.oe.dev * rd37343a2... 10/packages/linux/linux-openzaurus_2.6.15.bb: linux-oz-2.6: Change the way we detect and act on the headphone jack insertions - pass it to userspace as a switch event instead of dealing with it internally within the kernel Feb 21 09:21:10 03rpurdie 07org.oe.dev * ra6115c21... 10/packages/zaurusd/zaurusd_0.0.bb: Add zaurusd Feb 21 09:21:15 03rpurdie 07org.oe.dev * r4b0334a7... 10/packages/hal/hal_0.5.4.bb: hal 0.5.4: Disable documentation generation as the tools aren't in DEPENDS Feb 21 09:24:32 RP: zaurusd the new universal hardware configurator? Feb 21 09:24:57 XorA: perhaps. Who knows what it will end up doing :) Feb 21 09:25:31 XorA: Currently the ALSA mixer handling works, but the hinge rotation and soft touchscreen buttons need some TLC Feb 21 09:25:54 XorA: Only cx000 is currently supported as well Feb 21 09:26:01 but c7x0 should be easy to add Feb 21 09:27:15 _law_: Set your SRCDATE to 20060126 Feb 21 09:27:33 shouldn't that .bb have a COMPATIBLE_HOST mask or something? Feb 21 09:27:46 or EXCLUDE_FROM_WORLD? Feb 21 09:27:49 <_law_> RP ok i?ll try Feb 21 09:28:10 koen|assignment: It can support other things and it really quite generic so we'll wait and see how it develops Feb 21 09:28:31 _law_: It just needs to be the eds-dbus srcdate Feb 21 09:28:39 RP: heh Feb 21 09:28:44 koen|assignment: http://pastebin.ca/42635 looks ok to you? Feb 21 09:28:50 RP: then why is is called *zaurus*d? Feb 21 09:29:29 This wasn't my original choice of name Feb 21 09:29:29 hrw|work: dunno, ask the hh.org old farts, they handle familiar now Feb 21 09:29:34 * koen|assignment couldn't care less Feb 21 09:29:52 koen|assignment: who exactly? Feb 21 09:30:19 hrw|work: france, jamey, nelson, pb_, reenoo I guess Feb 21 09:30:26 don't know exactly Feb 21 09:30:32 ok Feb 21 09:31:04 I'll happily rename zaurusd to devmand or something if someone gives me a patch which makes it non-zaurus Feb 21 09:31:39 why not rename it now? Feb 21 09:31:57 rpdmd? Feb 21 09:32:28 koen|assignment: A long story. Lets just be happy its in OE Feb 21 09:32:31 iwmfzbhodd? Feb 21 09:33:05 RP: it's fine by me, but I remember all the whining about 'ipaq-sleep' Feb 21 09:33:39 and if you really want it to be generic, a name like zaurusd just scares possible contributors off Feb 21 09:33:42 koen|assignment: In this case I will happily rename it given an excuse Feb 21 09:34:14 iwmfzbhodd then (it was meant for zaurus but handle other devices daemon) Feb 21 09:34:24 Do we have any ipaqs with hinges, touchscreen buttons or alsa mixers? Feb 21 09:34:38 all ipaqs have alsa mixers Feb 21 09:34:57 How's the default mixer setup handled for them? Feb 21 09:35:09 oss-mixer emul Feb 21 09:35:50 Ok, someone needs to find me some default alsa mixer configs for a variety of ipaqs :) Feb 21 09:38:01 RP: what do you need? Feb 21 09:38:04 /etc/asound.conf? Feb 21 09:38:39 koen|assignment: run alsactl store and then cp /etc/asound.state Feb 21 09:39:10 On the zaurus, this means we can have things like the mic preconfigured Feb 21 09:40:30 http://dominion.kabel.utwente.nl/koen/pda/files/asound.state.hx4700 Feb 21 09:40:43 is that enough excuse? ;) Feb 21 09:41:20 koen|assignment: Its a start, thanks. I will see what I can do... Feb 21 09:41:25 koen|assignment: so was your checkins a couple of days ago, Angstrom started? Feb 21 09:41:46 XorA: yes, I need to clean it up a bit and I'll send a mail to angstrom-dev Feb 21 09:42:01 * RP needs to sub to angstrom-dev... Feb 21 09:42:10 koen|assignment: wow, news on EABI? Feb 21 09:42:15 (hi all, btw) Feb 21 09:42:19 pH5: not yet Feb 21 09:42:21 hey pH5 Feb 21 09:42:44 pH5: but I'm going to test gcc 4.1/glibc 2.4 soon Feb 21 09:42:53 koen|assignment: cool Feb 21 09:44:52 koen|assignment: Its just been explained to be that its a per device daemon which you can always take and rename :-/ Feb 21 09:45:15 heh Feb 21 09:45:24 who's being cranky over there? Feb 21 09:45:38 "no, I called it zaurusd and won't change it, puh!' Feb 21 09:45:54 koen|assignment: I wrote it, not anyone else Feb 21 09:46:58 koen|assignment: Its pending some in person discussion at fosdem - lets wait and see. I can always create devmand outside of OH Feb 21 09:47:54 let's name it gpe-deamon and watch mallum's beard fall out ;) Feb 21 09:48:48 ;-) Feb 21 09:49:17 koen|assignment: heard the news about uclibc eabi stuff lately Feb 21 09:49:43 ade|desk: no, haven't looked at uclibc lately Feb 21 09:49:58 I did hear that kernel.org git has nico's eabi patches Feb 21 09:50:05 so 2.6.16 should be eabi-able Feb 21 09:55:51 morning all Feb 21 09:55:57 hi do13_ Feb 21 09:56:29 hi Richard Feb 21 09:59:26 hi Dirk Feb 21 10:01:06 hey Marcin Feb 21 10:02:22 koen|assignment: would you mind if I will move all my SRC_URI to ewi/mirror/hrw-oe/ dir? I'm moving to hosting where I pay for any extra bandwidth Feb 21 10:02:44 go ahead Feb 21 10:02:53 ok Feb 21 10:02:53 ewi has unlimited bandwidth Feb 21 10:07:07 wget roxx Feb 21 10:18:47 <_law_> RP, zaurusd looks nice Feb 21 10:21:44 <_law_> RP, NOTE: package eds-dbus-1.4.0+svn20060126: completed :-) Feb 21 10:23:35 _law_: good - I'll add a preferred version to OE somewhere, Do you want to close the bug with a mention of that SRCDATE? Feb 21 10:24:03 <_law_> RP, ok i?ll to Feb 21 10:24:04 RP: just put SRC_DATE_${PN} = 20060126 in the .bb Feb 21 10:24:05 <_law_> do Feb 21 10:25:47 koen|assignment: I'd prefer to start locking down the floating dates in a more controlled way. I think its about time I created that preferred_versions.inc file I keep thinking about :) Feb 21 10:27:40 RP: the right was is too add snapshot .bbs which have a higher default pref Feb 21 10:28:07 unless you want to force every OE use to include a zillion .incs to make OE work Feb 21 10:28:33 OE should 'just work' without any .inc for preferred_versions Feb 21 10:28:36 koen|assignment: Just one .inc file which lists a set of known good cvs dates Feb 21 10:28:57 why not add snapshots? Feb 21 10:29:15 koen|assignment: because there's no need? Feb 21 10:29:20 heh Feb 21 10:29:30 you contradict yourself Feb 21 10:29:45 We can have zillions of extra pointless .bb files or one .inc file Feb 21 10:29:56 they aren't pointless Feb 21 10:30:22 No, but they just say one thing - "this is a known good SRCDATE" Feb 21 10:30:36 any floating package shoud build Feb 21 10:30:49 if it doesn't, it needs to go into nonworking/ Feb 21 10:31:01 In an ideal world where all maintainers keep 100% up to date with upstream Feb 21 10:31:11 and upstream is always 100% working Feb 21 10:31:23 This is not an ideal world Feb 21 10:31:45 hey there RP Feb 21 10:31:47 that's why we make a foo_1.2.3+cvs20050202.bb Feb 21 10:32:19 if people start using that .inc the quality of our metadate will go down Feb 21 10:32:21 does anyknow about a support channel regarding pc104 boards/apps Feb 21 10:32:37 "I don't need to fix it, because I know a working srcdate" Feb 21 10:34:34 koen|assignment: ultimately cvs snapshots should be created of those fixed dates due to the ability of cvs not keep history Feb 21 10:34:48 XorA: indeed Feb 21 10:35:08 koen|assignment: The floating versions were classified as problematic and unnecessary a while back and this .inc file was planned. I don't remember this being raised as an objection then :-/ Feb 21 10:35:32 I can see it could let people be slightly lazy, on the other hand, it makes OE more stable Feb 21 10:35:59 no, it covers up brokenness Feb 21 10:36:09 that's something different Feb 21 10:36:21 I'm all for locking down floating stuff, but not via a .inc Feb 21 10:39:18 good morning Feb 21 10:39:22 hey Bernardo Feb 21 10:40:01 hi Bernardo Feb 21 10:42:59 koen|assignment: Doing it as you describe would still mean the cvs/svn .bb files went untested most of the time. The difference is that removing an .inc file makes it easy to test, changing the PREFERRED_VERSION of a ton of packages is more difficult Feb 21 10:43:49 RP: removing that .inc file will influence *all* floating .bbs Feb 21 10:44:01 and how does Joe User find out about that .inc? Feb 21 10:44:14 he will look at the .bb and go "huh?" Feb 21 10:44:39 That's no different to all the other black magic the distro files do anyway Feb 21 10:44:51 that's bad enough as it is Feb 21 10:45:05 two wrongs don't make a right ;) Feb 21 10:45:47 It is exactly the kind of issue distro are supposed to handle Feb 21 10:46:04 having some files any distro can take advantage of is fair enough... Feb 21 10:46:36 well, a lot of floating stuff *in distros* can be solved if mallum would finally make some releases of matchbox stuff Feb 21 10:46:43 but that's not really related Feb 21 10:47:31 Its also not something I have any control over ;-) Feb 21 10:47:43 floating-package_workingsrcdate.bb looks best for me Feb 21 10:48:32 * RP gives up the whole issue and leaves it for someone else to fix Feb 21 10:49:39 does anybody know the status of opie/gcc4 ? Feb 21 10:49:55 koen|assignment: builds Feb 21 10:50:13 ah, cool Feb 21 10:50:26 I had tested bootstrap and gpe Feb 21 10:50:32 starting an opie build now Feb 21 10:50:54 so far angstrom is looking pretty good, build wise Feb 21 10:51:14 koen|assignment: konq/emb does not build, qpdf2 also - but they are not opie (only in meta-opie) Feb 21 10:51:46 koen|assignment: good? good it will look with eabi ;D Feb 21 10:51:58 looks like qt/e hackers have some work to do for angstrom Feb 21 10:54:20 * koen|assignment switches thunderbird to utf8 Feb 21 10:59:04 * XorA cant run thuinderbird on Z Feb 21 10:59:30 XorA: it's slow enough on a 1.3GHz machine with 1.25GB ram... Feb 21 10:59:43 koen|assignment: it takes more RAM than Z has Feb 21 10:59:47 morning Feb 21 10:59:51 hey greentux Feb 21 10:59:53 hey greentux **** ENDING LOGGING AT Tue Feb 21 10:59:56 2006