**** BEGIN LOGGING AT Mon Sep 10 02:59:57 2007 Sep 10 03:09:38 XorA|gone: could be Sep 10 03:10:28 koen: up early today? Sep 10 03:10:52 sort of Sep 10 03:11:00 woke up and couldn't get back to sleep Sep 10 03:51:55 03koen 07org.oe.dev * r501c4814... 10/ (33 files in 4 dirs): linux-ezx: update to svn r2050 Sep 10 03:52:05 03koen 07org.oe.dev * r5911b2fa... 10/ (1 packages/ezx/ezxd_svn.bb): ezxd: fix hardcoded gcc Sep 10 05:02:00 03rwhitby 07org.oe.dev * r71355ad1... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Added joe Sep 10 05:41:29 good morning all Sep 10 05:48:24 zamponiasma proiniatika Sep 10 05:50:27 ^^ Sep 10 06:04:08 hi all! Sep 10 06:20:02 hi Sep 10 06:23:44 suppose I am a 3rd party which develops and maintains packages for a distribution (e.g. angstrom). how can I provide those packages (say foo, baz and bar) and their dependendencies (minus the ones that are already provided by angstrom itself) via a feed. Has OE support for such an approach? If not would you be interested in patches allowing it? Sep 10 06:35:11 B_Lizzard : :) Sep 10 06:35:21 :D Sep 10 06:36:54 rschuster: I'd be interested. Sep 10 06:37:01 rschuster : The feed that a package ends to, is handled by a script at the webserver the repo is Sep 10 06:37:22 rschuster: chuck it in a bugzilla entry and post an RFC to oe-devel Sep 10 06:38:45 rschuster : in your case (if i understand well) you need to add a second repo, in addition to the angstrom one, which is pretty easy to do Sep 10 06:46:54 steliosk: the problematic part is IMHO that my 3rd party repo should not contain e.g. libraries that are already in the angstrom feed Sep 10 06:47:04 I posted a longer version of this problem on oe-devel Sep 10 06:47:23 rwhitby: bugzilla: will go for it Sep 10 06:48:07 rschuster: as a dirty hack, you could set PACKAGE_ARCH in your third-party packages to separate them out ... Sep 10 06:48:21 but I expect you have a much cleaner solution in your RFC Sep 10 06:50:06 rschuster : haven't looked at the OE ml yet Sep 10 06:54:00 rschuster: heh - PACKAGE_ARCH is the solution you used :-) Sep 10 06:56:19 rwhitby: :) Sep 10 07:48:53 morning Sep 10 07:57:55 hey XorA Sep 10 08:02:06 morning Sep 10 08:05:36 hey hrw Sep 10 08:27:12 hey mickeyl Sep 10 08:27:19 good morning Sep 10 08:27:32 * mickeyl reconfiguring his home network wrt. adsl2+ router Sep 10 08:27:40 heh heh Sep 10 08:27:55 my ADSL2+ should arrive wedsnesday Sep 10 08:28:05 at least all machines are online again. Sep 10 08:28:20 bah Sep 10 08:28:24 there's more to it but i have no time to configure it all optimally Sep 10 08:28:29 the mtd driver in linux-ezx segfaults Sep 10 08:28:38 no 2.4 removing for me :( Sep 10 08:28:45 morning all Sep 10 08:29:32 hey RP Sep 10 08:31:06 morning rp Sep 10 08:31:12 koen: yes, i think that's expected Sep 10 08:31:17 it never really worked Sep 10 08:31:23 needs more love Sep 10 08:31:39 but i think that'll be one of the next steps Sep 10 08:31:48 and IIRC 2.6.21 has an mtd bug Sep 10 09:06:48 does ROOT_FLASH_SIZE have meaning or is it ignored ? Sep 10 09:07:10 some images use to use it Sep 10 09:07:15 used* Sep 10 09:08:02 ade|desk: ignored Sep 10 09:08:18 ok, I just tried an angstrom image for my old h3600, jffs2 came out at 21MB not the 16 I was hoping for :( Sep 10 09:08:46 so whats the best way to make sure of a no more than 16MB ? Sep 10 09:09:34 create your own image :) Sep 10 09:10:06 delete crap like glibc :-) Sep 10 09:10:36 I must admit I get lost running through the angstrom-*-images these days Sep 10 09:11:23 perhaps I should build a minimal image and then bulk up from that with extras via feed Sep 10 09:14:44 we could go back to one image recipe which contains change depending machine, moon phase and freshness of your socks ;) Sep 10 09:15:38 sounds good +1 vote from me Sep 10 10:42:38 good morning Sep 10 11:09:26 re Sep 10 11:59:38 Anyone working on recipes for the recently open-sourced Hildon Input Method Framework? Sep 10 12:00:46 not yet Sep 10 12:00:53 I want hildon to build first Sep 10 12:00:59 (see packages/maemo3) Sep 10 12:01:09 some bits still require the nokia fork of gtk Sep 10 12:01:40 koen: ouch, that means I would have to fix all this before playing with the framework? Sep 10 12:01:52 not all Sep 10 12:02:07 hildon-fm stil misbehaves, the rest is ok Sep 10 12:02:09 koen: Ah, just your prioritize. Sep 10 12:02:51 I take a look at it after lunch. Sep 10 12:05:59 http://blog.haerwu.biz/2007/09/10/fucking-royal-mail/ Sep 10 12:07:00 hrw: heh heh Sep 10 12:08:26 although they managed to deliver all my mail in the strike without hitches Sep 10 12:08:42 stefan_schmidt: Have any URL for that? Sep 10 12:08:49 XorA: lucky you Sep 10 12:09:08 stefan_schmidt: I mean about "the recently open-sourced Hildon Input Method Framework" Sep 10 12:09:10 rschuster: moment Sep 10 12:09:34 rschuster: http://maemo.org/news/announcements/view/1189194936.html Sep 10 12:09:43 rschuster: http://live.gnome.org/Hildon/HildonInputMethod Sep 10 12:10:06 stefan_schmidt: thanks alot Sep 10 12:10:36 rschuster: np, just tell me when the recipes are ready. Sep 10 12:10:42 rschuster: just kidding Sep 10 12:13:10 does nokia's understanding of sourcecode differ from mine? Sep 10 12:13:10 http://codebrowse.launchpad.net/~mdamt/+junk/hildon-input-method-framework/revision/mdamt%40sudirman-20070907143156-o6jxrg5vsnws5toe?start_revid=mdamt%40sudirman-20070907143156-o6jxrg5vsnws5toe Sep 10 12:13:27 debian/build/usr/lib/libhildon_im_common.so.3@ Sep 10 12:13:27 debian/build/usr/lib/libhildon_im_common.so.3.0.0 Sep 10 12:13:27 ?!? Sep 10 12:14:16 ok this one is better: https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-input-method-framework/src/ Sep 10 12:14:20 rschuster: nokia's definition of 'open' is 'closed source company controlled' Sep 10 12:16:11 03koen 07org.oe.dev * r76a8d4ee... 10/ (1 packages/gsm/files/default packages/gsm/libgsmd_svn.bb): (log message trimmed) Sep 10 12:16:11 libgsmd: add stub for Motorola EZX platforms, tested, but does nothing yet: Sep 10 12:16:11 [13:52] koen: stefan_schmidt: I read http://wiki.openezx.org/Mux_cli Sep 10 12:16:14 [13:52] stefan_schmidt: koen: Should be point to start with. Sep 10 12:16:15 [13:52] stefan_schmidt: koen: I can't remember what services ends on which mux devices Sep 10 12:16:17 [13:52] stefan_schmidt: koen: Could be tricky if you have to connect to two different ones. Sep 10 12:16:19 [13:52] koen: yeah Sep 10 12:16:21 03koen 07org.oe.dev * r76a8d4ee... 10/ (1 packages/gsm/files/default packages/gsm/libgsmd_svn.bb): (log message trimmed) Sep 10 12:16:24 libgsmd: add stub for Motorola EZX platforms, tested, but does nothing yet: Sep 10 12:16:26 [13:52] koen: stefan_schmidt: I read http://wiki.openezx.org/Mux_cli Sep 10 12:16:28 [13:52] stefan_schmidt: koen: Should be point to start with. Sep 10 12:16:33 [13:52] stefan_schmidt: koen: I can't remember what services ends on which mux devices Sep 10 12:16:35 [13:52] stefan_schmidt: koen: Could be tricky if you have to connect to two different ones. Sep 10 12:16:41 [13:52] koen: yeah Sep 10 12:16:43 03koen 07org.oe.dev * r76a8d4ee... 10/ (1 packages/gsm/files/default packages/gsm/libgsmd_svn.bb): (log message trimmed) Sep 10 12:16:46 libgsmd: add stub for Motorola EZX platforms, tested, but does nothing yet: Sep 10 12:16:48 [13:52] koen: stefan_schmidt: I read http://wiki.openezx.org/Mux_cli Sep 10 12:16:50 [13:52] stefan_schmidt: koen: Should be point to start with. Sep 10 12:16:52 ~kill CIA-3 Sep 10 12:16:52 [13:52] stefan_schmidt: koen: I can't remember what services ends on which mux devices Sep 10 12:16:53 * ibot shoots a hyper-charged proton gun at CIA-3 Sep 10 12:16:54 [13:52] stefan_schmidt: koen: Could be tricky if you have to connect to two different ones. Sep 10 12:16:55 flooders! Sep 10 12:16:56 [13:52] koen: yeah Sep 10 12:16:58 03koen 07org.oe.dev * r76a8d4ee... 10/ (1 packages/gsm/files/default packages/gsm/libgsmd_svn.bb): (log message trimmed) Sep 10 12:17:01 libgsmd: add stub for Motorola EZX platforms, tested, but does nothing yet: Sep 10 12:17:03 [13:52] koen: stefan_schmidt: I read http://wiki.openezx.org/Mux_cli Sep 10 12:17:05 [13:52] stefan_schmidt: koen: Should be point to start with. Sep 10 12:17:19 [13:52] stefan_schmidt: koen: I can't remember what services ends on which mux devices Sep 10 12:17:19 [13:52] stefan_schmidt: koen: Could be tricky if you have to connect to two different ones. Sep 10 12:17:19 [13:52] koen: yeah Sep 10 12:17:19 03koen 07org.oe.dev * r76a8d4ee... 10/ (1 packages/gsm/files/default packages/gsm/libgsmd_svn.bb): (log message trimmed) Sep 10 12:17:20 libgsmd: add stub for Motorola EZX platforms, tested, but does nothing yet: Sep 10 12:17:22 [13:52] koen: stefan_schmidt: I read http://wiki.openezx.org/Mux_cli Sep 10 12:17:24 [13:52] stefan_schmidt: koen: Should be point to start with. Sep 10 12:17:26 [13:52] stefan_schmidt: koen: I can't remember what services ends on which mux devices Sep 10 12:17:28 [13:52] stefan_schmidt: koen: Could be tricky if you have to connect to two different ones. Sep 10 12:17:30 (1 lines omitted) Sep 10 12:19:33 ~seen vivijim Sep 10 12:19:36 vivijim was last seen on IRC in channel #oe, 4d 22h 44m 32s ago, saying: 'zecke: It is really close... I believe that I'll stay in the garden one.... Now I need to leard how to pronounce these street names hehehe'. Sep 10 12:23:45 koen: you turned your hand to demon summoning? Sep 10 12:24:06 yeah Sep 10 12:28:28 koen: quim gil really tries to make nokia more open. Sep 10 12:29:01 koen: but often he torn apart from both side Sep 10 12:29:09 s/side/sides/ Sep 10 12:29:42 I've met quim a few times in person Sep 10 12:30:31 thats an unfortunate name in English Sep 10 12:30:40 this is what I mean: https://bugs.maemo.org/show_bug.cgi?id=176 Sep 10 12:30:42 we know :) Sep 10 12:31:26 so is 'openmoko' in spanish Sep 10 12:31:39 or 'OSRAM' lightbulbs in Polish ;D Sep 10 12:31:45 and poedit in german. haha :) Sep 10 12:32:29 openmoko means open me in tagalog Sep 10 12:32:42 Or "you open me", something like that Sep 10 12:32:57 OpenMoko in spanish is fun :-) Sep 10 12:33:10 But it's supposed to be moco Sep 10 12:34:33 'osram it' in Polish is very inpolite way to tell: 'I will make a shit on it' Sep 10 12:34:54 hrw: heh heh Sep 10 12:35:37 their first PR campain had to be dropped due to product name Sep 10 12:36:01 so basically they advertise Long Life Shit? Sep 10 12:36:19 Well, this german company had to change the name of their mp3 player: http://www.shinyshiny.tv/2007/08/worst_mp3_playe.html Sep 10 12:36:32 i.Beat blaxx - What were they thinking... Sep 10 12:36:48 * XorA falls over laughing at CM Sep 10 13:14:45 Crofton: ping Sep 10 13:15:01 pong Sep 10 13:15:30 Jin^eLD, I am still not 100% paying attention to work matters Sep 10 13:15:41 Crofton: the kernel uImage for davinci is 4.5mb, is that really ok? :> Sep 10 13:15:46 Crofton: ok Sep 10 13:15:53 probably not Sep 10 13:16:06 maybe we aren't compressing it? Sep 10 13:16:20 I'll look it up, but when booting it says "uncompressing kernel" Sep 10 13:16:31 I thought you put a rootfs image inside it Sep 10 13:16:33 I won't be ale to look it it for a week or so Sep 10 13:16:35 no Sep 10 13:16:43 ok then, I'll have a look Sep 10 13:16:44 not deliberately anyway Sep 10 13:16:46 thanks! Sep 10 13:16:59 it's loading the kernel for about 2 minutes now :) Sep 10 13:17:05 urg Sep 10 13:17:35 I wonder if soemthing stupid happens as the kernel is updates in git, but we do not redo the defconfig Sep 10 13:17:35 uboot decompress kernel or kernel decompress itself? Sep 10 13:17:50 Starting kernel ... Sep 10 13:17:51 Uncompressing Linux.. Sep 10 13:17:56 so I guess the kernel Sep 10 13:17:59 probablt uboot, need to maove the omap/deavinci kernel to linux.inc ..... Sep 10 13:18:00 because the uImage has already been loaded Sep 10 13:18:09 oh yeah, its uncompressed Sep 10 13:18:13 Image Type: ARM Linux Kernel Image (uncompressed) Sep 10 13:18:30 thats why 4.5M? Sep 10 13:18:37 makes sense now Sep 10 13:18:42 I'll take a look at the .bb file Sep 10 13:19:43 Jin^eLD: vmlinux? Sep 10 13:20:02 hrw: its packed into a uImage, so not sure Sep 10 13:20:14 don't know what crofton used in his recipe Sep 10 13:21:13 its based on linux-omap.inc Sep 10 13:21:19 lets see what that one is doing.. Sep 10 13:21:55 it needs to change to linux.inc Sep 10 13:22:09 or even merge into it? Sep 10 13:22:17 so if you need to apply energy, I think that is the way to go Sep 10 13:23:42 uuh.. linux.inc looks weird, will ned some more studying of it Sep 10 13:23:47 I know how to make my own standalone recipe Sep 10 13:24:00 so not yet sure which way I will go Sep 10 13:36:36 morning Sep 10 13:46:28 rwhitby: fwiw, the timezones* packages are obsolete, you want the tzdata* packages Sep 10 13:47:27 tghx Sep 10 13:47:29 thx Sep 10 13:48:27 koen: I think that we should drop timezones* ones and make tzdata provide them Sep 10 13:48:45 hrw: RREPLACES would be better Sep 10 13:53:05 I'll go and make that change right now ... Sep 10 13:53:38 tzdata has the US daylight saving changes Sep 10 13:58:58 koen: PROVIDES and RREPLACES Sep 10 13:59:13 ah Sep 10 13:59:21 sorry, I misread that as RPROVIDES Sep 10 14:04:36 moin Sep 10 14:09:11 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:09:21 does someone else's "handling bitbake files" hang at 77% ? (gnuradio) Sep 10 14:09:26 yep Sep 10 14:09:26 03koen 07org.oe.dev * r11dbe81f... 10/ (3 files in 3 dirs): linux-ezx: apply patch to fix mtd access Sep 10 14:09:48 does someone know how to fix that ? :-) Sep 10 14:13:36 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:13:36 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:13:36 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:13:40 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:12 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:12 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:12 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:12 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:17 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:18 weird Sep 10 14:14:34 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:40 hehe Sep 10 14:14:49 03rwhitby 07org.oe.dev * r6e9b78a5... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Replaced timezones with tzdata Sep 10 14:14:54 03koen 07org.oe.dev * r11dbe81f... 10/ (3 files in 3 dirs): linux-ezx: apply patch to fix mtd access Sep 10 14:17:12 * mwester notes that CIA-3 seems very impressed by rwhitby's commit... :) Sep 10 14:18:41 maybe it reported it once in each timezone ... Sep 10 14:18:57 hehe Sep 10 14:23:18 RP: do you have a copy of that pxafb-in-sram patch lying around? Sep 10 14:28:05 how can I force a cvs version of a package in an image ? Sep 10 14:28:18 using package-cvs or package_cvs doesn't work Sep 10 14:30:39 koen: http://www.rpsys.net/openzaurus/patches/tosort/0206_linux-2.6.16-pxa27x-sram.patch ? Sep 10 14:31:51 | /usr/bin/autoreconf: unrecognized option `--exclude=autopoint' Sep 10 14:31:53 wtf? Sep 10 14:35:03 RP: yes, that one Sep 10 14:35:05 thanks Sep 10 14:38:10 can someone tell me what version of automake we're supposed to have onboard for OE? Sep 10 14:39:27 * koen hints at automake-native Sep 10 14:39:50 | /usr/bin/autoreconf: unrecognized option `--exclude=autopoint' Sep 10 14:39:51 ? Sep 10 14:40:21 that's autoconf-native Sep 10 14:42:36 hi, what file besides defconf do i have to change to add module packages to the kernel package? Sep 10 14:44:38 Philippe: ping Sep 10 14:45:20 koen: thanks Sep 10 14:46:43 I need a small ARM-based CPU board like the Toradex Colibri - anyone here wo can recommend something like this? Sep 10 14:48:09 florian: like http://www.elinux.org/Hammer_Board ? Sep 10 14:49:02 florian: nslu2 Sep 10 14:50:11 koen: yeah that's nice, but a little bit more power would be good. Sep 10 14:50:24 tstone: too big and needs too much power Sep 10 14:51:13 where can you get the hammer board from ? Sep 10 14:51:16 The phyCORE PXA270CE looks quite interesting too... Sep 10 14:52:46 Hi! Sep 10 14:53:06 Is issue with http://linuxtogo.org/gowiki/ known? Sep 10 14:53:28 hi psokolovsky Sep 10 14:53:52 florian: Hi, any hints re: above? Sep 10 14:54:01 hrmpf... we had this before Sep 10 14:54:15 florian: gumsticks computer? Sep 10 14:54:29 what's wrong with the wiki? Sep 10 14:54:33 works over here Sep 10 14:54:41 theme problems? Sep 10 14:54:44 koen: it seems to lack any css and images Sep 10 14:54:48 yep Sep 10 14:55:11 those work in my theme :) Sep 10 14:55:22 'rightsidebar' Sep 10 14:55:44 koen: doesn't work in anon and my login (was yellowish-brownish theme) Sep 10 14:58:58 tstone: that looks quite interesting Sep 10 15:00:24 koen: please remind me where to ssh to upload stuff for a-d.org? Sep 10 15:01:13 psokolovsky: define stuff Sep 10 15:02:01 koen: device images for unstable/ (mentor's stuff) Sep 10 15:02:39 images built from angstrom--image recipes go into ~/website/unstable/images/// Sep 10 15:03:18 koen: cool, what is for ssh Sep 10 15:03:48 angstrom@linuxtogo.org Sep 10 15:04:04 or angstrom@openembedded.org or angstrom@angstrom-distribution.org :) Sep 10 15:04:57 koen: aha, thanks, I remembered it was some linuxtogo server. works for me. Sep 10 15:05:07 koen: so, any ideas on fixing wiki? Sep 10 15:05:15 nope Sep 10 15:05:27 I fixed enough web stuff the past few days :) Sep 10 15:06:12 damn, worse than hh.org ;-E Sep 10 15:06:24 koen: for me, even rightsidebar doesn't work ;-( Sep 10 15:07:03 * koen trademarks 'wiki' and 'moinmoin' to protect the community Sep 10 15:07:52 koen: trademark that css-less theme ;-) Sep 10 15:50:47 koen: fyi, I put upload area access instructions to wiki Sep 10 15:51:11 RP: Hi, any hints on how to do RRECOMMENDS for images now? Sep 10 16:00:42 03mickeyl 07org.oe.dev * r5978397b... 10/ (4 files in 2 dirs): libnotify: remove older ones, fix formatting Sep 10 16:00:48 03mickeyl 07org.oe.dev * r8f24f687... 10/ (4 files in 2 dirs): notification-daemon: remove 0.3.5, package dbus services file in 0.3.6, add 0.3.7 Sep 10 16:00:54 03daniel 07org.oe.dev * rbc1bceb6... 10/ (1 packages/openmoko2/openmoko-terminal2_svn.bb): openmoko-terminal2_svn.bb: Put vte in RDEPENDS so it gets installed into the rootfs (closes OpenMoko bug #809) Sep 10 16:03:02 Patch mtd-sharp-flash-hack-r0.patch does not apply (enforce with -f) Sep 10 16:03:03 ERROR: Task 647 (/home/koen/OE/monotone/org.openembedded.dev/packages/linux/linux-rp_2.6.22.bb, do_patch) failed Sep 10 16:03:07 collie is broken :( Sep 10 16:13:03 bye Sep 10 16:13:19 psokolovsky: I don't understand the question? Sep 10 16:14:48 RP: how can I make an image recipe to RRECOMMEND, not RDEPEND on some packages? Sep 10 16:15:08 RP: that's re: RDEPENDS -> INSTALL_PACKAGES transition Sep 10 16:15:42 psokolovsky: How did you used to do it? Sep 10 16:16:15 RP: If I remembered that ;-). would RRECOMMENDS in image .bb work? Sep 10 16:16:42 brb Sep 10 16:17:03 psokolovsky: INSTALL_PACKAGES is passed to directly to ipkg. I don't see how RRECOMMENDS in an image .bb file would work Sep 10 16:17:08 (or have ever worked) Sep 10 16:17:20 psokolovsky: Obviously you can add RRECOMMENDS in task packages Sep 10 16:17:35 RP: ok, that answers it, thanks Sep 10 16:20:04 RP: and I just hope that bitbake parsing failure issues due to SVN access will be resolved somehow. because it fails randomly just too often ;-(( Sep 10 16:20:31 psokolovsky: I've proposed sane-srcrevs.inc to combat that Sep 10 16:20:55 RP: hope it will be committed soon... Sep 10 16:21:03 psokolovsky: Its been started iirc Sep 10 16:21:30 psokolovsky: Better solutions welcome keeping in mind my comments about SkipPackage not being an answer Sep 10 16:23:43 RP: unfortunately I'm out of loop with the whole SRCREV stuff... But no matter how much boon it brings, making mere parsing fail deterministically or non-deterministically is pretty bad engineering decision ;-I Sep 10 16:24:52 psokolovsky: Like I said, tell me what it should do then Sep 10 16:26:47 http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-September/002963.html Sep 10 16:27:30 psokolovsky: Discovering I make "bad engineering decisions" really encourages me to keep working on bitbake :/ Sep 10 16:27:55 * mwester is not any sort of expert, but he thinks that the querying of remote servers for svn versions or git versions should not be part of the build, but should be a separate step, such as "bitbake update-svn" or something... Sep 10 16:28:28 mwester: There is a policy variable which can make it do that Sep 10 16:30:19 RP: oh my, let's don't make tragedy out of this. As I told, I have no idea about the whole SRCREV story. But IMHO, no matter that it was, possible failures during parsing are noticeable regression. Why I'm talking about this is to encourage to find a solution, not forget about it. And of course not to discourage you. So sorry again ;-I Sep 10 16:30:28 I am confused then -- why not just set that, so that (for example) one can establish a baseline, and choose when to sync up to the head of the various other dev projects? Would this not solve the current problems plaguing the openmoko folks, for example? Sep 10 16:30:53 mwester: http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-September/002963.html Sep 10 16:31:12 RP: and now, I better shut up, and learn the stuff before being able to tell sth more sensible. Sep 10 16:31:13 mwester: The openmoko devs are primarily the people who want it to refresh each and everytime! Sep 10 16:31:47 psokolovsky: http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-September/002963.html Sep 10 16:32:03 mickeyl: http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-September/002963.html Sep 10 16:32:09 psokolovsky: I'm not taking offence at anything since I have a thick skin. Please do try and understand why it does what it does before calling it bad though, ok? :) Sep 10 16:32:15 there, that should bring it to attention a bit more Sep 10 16:32:30 koen: I saw that, I'd like to see that in mtn, if that's officially adopted solution. I can judge how good it is myself - as I told, I'm out of loop on latest changes ;-( Sep 10 16:32:37 RP: Ah. the typical SCM "magic" -- I want my SCM tool to magically determine what is stable for my specific purposes, and magically sync up or lock down all by itself. :) Sep 10 16:32:48 psokolovsky: sane-srcrevs.inc is already in Sep 10 16:33:11 koen: You want to learn about AUTOREV, I will reply to your mail Sep 10 16:33:33 RP: I know about AUTOREV :) Sep 10 16:33:33 koen: well, then I miss an update apparently. Sep 10 16:34:14 RP: sending messages with obvious flaws is a way to see if people read them :) Sep 10 16:36:29 koen: I was wondering what planet you were on with that syntax ;-) Sep 10 16:37:58 I don't see any obvious flaws in the code, but what leaps off the page (er, email) to me is the key question of the policy/process/owner for sane-srcrevs.inc. Sep 10 16:38:28 * RP just sent a reply with his opinion of that (automate it to latest and greatest) Sep 10 16:39:44 If left up to each distro, since bitbake is parsing *every* recipe for any distro, then the policy of a specific distro might clash with others. (Why does distro X care about distro Y's dependence on the ability to get the latest version of xemacs, for example) Sep 10 16:40:41 If it's centrally-maintained, then the only person who would maintain sane-srcrevs would have to be himself insane. Sep 10 16:41:05 mwester: How is bitbake supposed to work out whether a distro X needs version Y of foo at .bb file parse time? Sep 10 16:41:25 mwester: It doesn't know what versions are available until after its parsed the files... Sep 10 16:43:49 RP: one q I would have out of top of mind is that it does those "svn info"'s on full reparse, right? It doesn't do it on next startup if cache is good, right? So it won't notice if external repo is changed in such case, right again? Sep 10 16:44:49 psokolovsky: Yes, that is a nasty tricky problem :/ Sep 10 16:45:09 psokolovsky: The cache stores the evaluated form of PV... Sep 10 16:45:48 psokolovsky: people have asked for this to be fixed but its a massive headache :-/ Sep 10 16:46:08 yeah... Sep 10 16:48:05 RP: philosophically, I object to the concept of permitting non-locked versions to be specified in the core OE environment. A user should have a local "override" that they can use to specify nebulous terms such as "latest" or "most recent" or similar. OE should be deterministic and stable, and the user should take explicit action to make it otherwise. JMO. Sep 10 16:48:33 mwester: Hence sane-srcrevs.inc. Sep 10 16:49:05 But sane-srcrevs.inc is the other way around -- someone must take explicit action to make something sane. Sep 10 16:49:25 It should be "insane-srcrevs.inc" to specify non-specific versions. Sep 10 16:50:15 mwester: We can make it policy that floating svn .bb files shouldn't exist and that everything should have a revision specified in the .inc file Sep 10 16:50:27 morning Sep 10 16:50:31 * mwester applauds Sep 10 16:50:39 mwester: distros can then decide if they want that or not Sep 10 16:50:42 hi kergoth Sep 10 16:52:33 mwester: basically we have the functionality in bitbake, we need some policys in OE to handle it now. I've tried to do the best I can from the bitbake side but regardless of how it was implemented, there was going to be sufficent ammo so shot yourself in the foot... Sep 10 16:53:09 and as always, no shortage of people willing to "ready - fire! - aim"... Sep 10 16:54:27 mwester: quite Sep 10 18:24:51 does anyone knows which devices in oe have power off in userspace? Sep 10 19:25:20 crap Sep 10 19:25:28 can't bring the davinci board up with the OE built kernel Sep 10 19:25:38 anyone else tried this? Sep 10 19:36:10 hi Sep 10 19:36:24 mr_nice: what do you mean by 'power off in userspace'? Sep 10 19:39:56 hrw|tv: with userspace I mean, that the power button is watched e.g. by keylaunch which starts apm --suspend and not suspended on keypress by a kernel driver Sep 10 19:46:41 ah.. Sep 10 19:47:07 I probably can setup such stuff on alix but with acpid not apm Sep 10 19:47:11 it is x86 Sep 10 19:51:53 hrw|tv: ah, ok. Sep 10 19:53:15 hrw|tv: do you know how it is handled by zaurus or ipaq. Sep 10 19:55:57 nope Sep 10 19:56:21 hrw|tv: ok, thx anyway :) Sep 10 19:56:36 hrw|tv: LinuxBIOS support for alix hit the LinuxBIOS list - soon to be committed Sep 10 19:58:38 great Sep 10 20:17:32 re Sep 10 20:17:37 CosmicPenguin: how hard to get is that LPC flash stuff to test LB without touching onboard flash? Sep 10 20:19:57 mickeyl: do you have some time for me? Sep 10 20:20:20 mr_nice: FWIW, the zaurus handles this in the kernel atm Sep 10 20:20:28 hrw|tv: hmm - not sure Sep 10 20:20:36 RP: thx for that info Sep 10 20:20:40 mr_nice: http://www.rpsys.net/openzaurus/patches/input_power-r9.patch Sep 10 20:20:52 mr_nice: ugly but has worked for long enough :) Sep 10 20:22:21 RP: thx Sep 10 20:41:01 hmm, for some reason my davinci kernel is getting 4MB in size, even if I try to create a gzipped version of uImage out of the vmlinux its still quite big.. and does not start :> I get an undefined instruction when booting Sep 10 20:41:03 any ideas? Sep 10 20:41:11 or hints? Sep 10 20:42:30 arch/arm/boot/* image is also so big? Sep 10 20:42:45 yes Sep 10 20:43:12 I tried various variants, target type vmlinux, target type uImage Sep 10 20:43:13 Jin^eLD: sounds pretty much like an filesystem error to me. Sep 10 20:43:25 but something is always quite weird and the kernel will not start Sep 10 20:43:30 tstone: you mean - local? Sep 10 20:43:42 Jin^eLD: on your devel machine yes Sep 10 20:43:50 tstone: but I can build other OE images Sep 10 20:43:56 and they boot just fine.. Sep 10 20:44:19 I have a mipsel based board and I build a kernel for it that is also mkimaged and stuff Sep 10 20:44:21 ant its ok Sep 10 20:44:25 Jin^eLD: my colleague just produced an vmlinuz.bin with 3gb. Sep 10 20:44:26 s/ant/and/ Sep 10 20:44:32 lol Sep 10 20:44:33 :) Sep 10 20:44:48 Jin^eLD: its armv4t or armv5te? Sep 10 20:45:02 hrw|tv: uhm, not sure, let me look that up in the machine conf Sep 10 20:45:10 Jin^eLD: and how machine is named in OE? Sep 10 20:45:18 davinci-dvevm.conf Sep 10 20:45:50 started build of virtual/kernel for it Sep 10 20:46:15 hrw|tv: Crofton based his bb recipe on linux-omap Sep 10 20:46:23 but that one produces something that is not booting Sep 10 20:46:31 he suggested that I try to switch to linux.inc Sep 10 20:48:34 well, maybe I messed up along the way.. Sep 10 20:49:09 but I already did create a working .bb file that also used uImage /mkimage for a different board and that was fine; and I do not see much difference here.. Sep 10 21:01:36 Jin^eLD: NOTE: package linux-davinci-2.6.x+git20070910-r1: task do_fetch: started Sep 10 21:02:48 I'll clean, see that I revert all my changes and try again too Sep 10 21:04:59 Jin^eLD: davinci tree lack any patchsets to release kernels? Sep 10 21:05:23 isn't the davinci tree a 1:1 copy of the omap tree? Sep 10 21:05:52 is there a trick to handling signals in busybox's sh? Sep 10 21:06:01 koen: uhm, is it? I do not know anything about omap Sep 10 21:06:24 hrw|tv: uhm, I thought the davinci kernel is fetched from some montavista git? Sep 10 21:06:51 so it should have all the patches? doh.. well Crofton would know that I guess Sep 10 21:08:06 koen: it is not Sep 10 21:08:46 weird, since the architecture is quite the same Sep 10 21:09:06 even TI people become incoherent when trying to explain the difference :) Sep 10 21:09:19 looks like davinci tree gets omap stuff from omap tree Sep 10 21:09:49 davinci is basically 'omap with faster DSP' Sep 10 21:09:57 and 3 overlays Sep 10 21:11:13 anyhow Sep 10 21:11:18 * koen needs to get up in 7 hours Sep 10 21:11:20 'night all Sep 10 21:11:43 n8 koen Sep 10 21:12:50 night koen Sep 10 21:16:38 4.4MuImage-2.6.x+git20070910-davinci-dvevm-20070910211930 Sep 10 21:16:48 mhm Sep 10 21:17:33 and it says its gzip compressed Sep 10 21:18:04 staring kernel, then: undefined instruction, dump of something that looks like registers, Resetting CPU... Sep 10 21:18:07 doh.. Sep 10 21:18:55 hrw|tv: I wonder if you also get the 4.4MB thing, but I guess you will... must be something wrong with the build process of this thing Sep 10 21:19:10 well; I am using mkimage from uboot-utils, that should not matter though, right? Sep 10 21:19:14 undefined instruction? Sep 10 21:19:17 ..because the u-boot git is broken Sep 10 21:19:43 whic instruction? Sep 10 21:20:04 http://pastebin.ca/690840 Sep 10 21:20:22 does that make any sense to you? Sep 10 21:20:54 nop Sep 10 21:20:55 e Sep 10 21:21:05 same here :) Sep 10 21:21:22 well, time to go home.. gotta catch my train Sep 10 21:21:46 night Sep 10 21:21:52 fsck.. I hate git fetcher Sep 10 21:21:58 :) Sep 10 21:24:28 hi chouimat Sep 10 21:45:58 I HATE GIT FETCHER CODE Sep 10 21:46:11 fscking 40 minutes wasted on do_fetch Sep 10 21:46:39 first 200MB archive fetch, then unpack, then pull, then creating TWO archives... Sep 10 21:46:59 let me guess.. ~800MB space used Sep 10 21:49:41 yikes Sep 10 21:51:12 515M for git/ 207M + 56M for archives Sep 10 21:51:49 515M git/source.mvista.com.git.linux-davinci-2.6.git/ Sep 10 21:51:49 56M git_source.mvista.com.git.linux-davinci-2.6.git_dba75d59b3057f657e8e98bbdd32ff1244977e38.tar.gz Sep 10 21:51:52 207M git_source.mvista.com.git.linux-davinci-2.6.git.tar.gz Sep 10 21:52:10 and let someone say that git is space effective.. Sep 10 21:53:21 it is almost as good as svn ;-) Sep 10 22:05:29 Jin|away: -rw-r--r-- 1 hrw hrw 4.4M Sep 11 00:00 uImage-2.6.x+git20070910-davinci-dvevm-20070910204513 Sep 10 22:07:44 bye Sep 10 22:29:29 anyone know what monotone is doing while it's sucking 100% of CPU for like 10 minutes during an mtn pull? Sep 10 22:30:55 I mean seriously, what kind of algorithm takes 10 minutes to sync diffs on a 200MB database? Sep 10 22:31:07 where every diff is frigging timestamped no less Sep 10 22:31:40 and it's not even a merge, cos there are no local changes Sep 10 22:32:08 hughescr: It used to taken 20 mins if that makes you feel any better? :) Sep 10 22:32:53 RP: not really ;) Sep 10 22:33:15 I think monotone development must be heavily sponsored by the coffee industry or something Sep 10 22:33:33 I could literally go out to starbucks and come back while monotone is pulling Sep 10 22:33:36 hughescr: I have a cron job setup so I don't really notice Sep 10 22:34:08 RP: probably not a bad idea Sep 10 22:34:37 I'm picturing a situation though where I run that cronjob at super nice priority, and it's not done running by the time the next run's scheduled ;) Sep 10 22:35:36 hmm, then after all that I'm not sure it actually pulled everything -- it's missing a branch looks like Sep 10 22:35:53 'night all Sep 10 22:37:58 ah, I see specifying no PATTERN is not the same as specifying '*' Sep 10 22:42:11 doh, I think I had just not set up read-permissions right on the server Sep 10 22:51:59 another monotone question Sep 10 22:52:19 when doing a 3-way merge, is there any way to have monotone tell you which fricking file it is showing you the merge info for? Sep 10 22:52:47 instead of just "/tmp/mtn.left.R88RCK" vs "/tmp/mtn.right.6D6AB9" which is not easy to get much context from... Sep 10 22:53:27 Ah, I see it does seem to print the filename on the console, just before launching your merge tool Sep 10 22:53:37 which is not so helpful when your merge tool is console-based.... Sep 10 23:45:53 howdy all Sep 10 23:46:22 anyone with experience on logicpd boards? I'm thinking about working with them, but need some feedback before I proceed Sep 11 01:13:25 03pfalcon 07org.oe.dev * rd431c986... 10/ (3 files in 3 dirs): initramfs-jffs2 0.1: Bump mtdram size to 24.5Mb, helps h4000 image. Sep 11 01:13:29 03pfalcon 07org.oe.dev * r8d2cd36e... 10/ (1 packages/images/liveramdisk-image.bb): liveramdisk-image: Build a LiveRamdisk image. **** ENDING LOGGING AT Tue Sep 11 02:59:56 2007