**** BEGIN LOGGING AT Fri Aug 08 02:59:58 2008 Aug 08 06:39:40 morning Aug 08 07:24:43 well since openembedded.org is still down i hop you dont mind if i ask here: who is maintaining python in oe? Aug 08 07:24:57 mickeyl perhaps? Aug 08 07:41:17 josch|nsn: yes Aug 08 07:41:50 morning Aug 08 07:42:06 stefan_schmidt: thx - then i will message him if he gets back :) Aug 08 07:42:21 s/if/when/ :P Aug 08 07:42:29 heh Aug 08 07:42:33 morning hrw Aug 08 08:07:17 bonjour Aug 08 08:23:25 So er... trying to bitbake kdepimpi actually produces the error: "requires the runtime entity 'kdepimpi' but it wasn't found in any PACKAGE or RPROVIDES variable" Aug 08 08:23:28 clues? Aug 08 08:29:58 kdepimpi? no idea Aug 08 08:33:26 I find it boggleable that a package depends on itself and can't find itself somehow Aug 08 08:41:43 Oh Aug 08 08:41:56 oh do I make it compile libqpe-opie with qte-mt ? Aug 08 08:42:07 it keeps trying to -lqte instead of -lqte-mt Aug 08 08:42:23 I have PALMTOP_USE_MULTITHREADED_QT="yes" Aug 08 09:16:15 hello, I try to build an openmoko toolchain for a i686 system using bitbake on a x86_64 machine - tried to edit openembedded/conf/bitbake.conf setting HOST_ARCH = "i686" but I guess I got a bit confused with TARGET and HOST.... Aug 08 09:19:11 well, I see openembedded/classes/sdk.bbclass:HOST_ARCH = "${BUILD_ARCH}" - therefore I think HOST_ARCH would be the right variable to change... what would be the right value? Aug 08 09:19:54 anybody here who did that before? Aug 08 09:26:45 buri: what exactly are you trying to accomplish? Aug 08 09:27:10 do I understand correctly that you are trying to build i686 binaries on your x86-64 host? if so, TARGET_ARCH is the variable you want to set. Aug 08 09:28:06 if you mean that you are trying to do a canadian cross sdk, I don't think this is something that oe supports very well (or maybe at all). It might be possible to make it work but I suspect you are on your own. :-} Aug 08 09:37:49 florian_: good morning Aug 08 09:39:41 good morning Aug 08 10:05:21 pb__: I try to build an openmoko toolchain (gcc etc.) on a x86-64 system that should run on a i686 system and produce binaries for the openmoko (arm) Aug 08 10:10:00 pb__: I think TARGET_ARCH should still be ARM, as the sdk.bbclass takes for HOST_x all the settings from BUILD_x Aug 08 10:10:20 buri: I think you will get into trouble with this Aug 08 10:10:41 buri: right, that's a canadian cross. I don't think it will work with sdk.bbclass out of the box. Aug 08 10:10:54 buri: while you can override BUILD_x variables you certainly won't fool the autotools Aug 08 10:12:30 buri: because the way the things are now they will call your system's uname and whatnot to find out on what it is running on Aug 08 10:13:04 buri: as pb__ said canadian cross (compilation) is not handled right now. Aug 08 10:13:15 buri: contributions in this way are very much welcome! :) Aug 08 10:15:26 thebohemian: canadian cross? never heard of that - I tried to overwrite the HOST_ARCH variable and I get an error: NOTE: Handling BitBake files: \ (0755/5722) [13 %]ERROR: Information not available for target 'i386-linux-gnueabi' Aug 08 10:17:09 buri: http://en.wikipedia.org/wiki/Cross_compile#Canadian_Cross Aug 08 10:18:05 buri: compilation is for beginners, cross-compilation is for adepts, canadian cross-compilation is for the elite ;) Aug 08 10:19:21 buri: AFAIK the autotools are the only build system that can deal with it by design Aug 08 10:19:32 thebohemian: I guess your right... and I think I'm not the elite type of embedded developer Aug 08 10:20:21 thebohemian: ... and it probably takes a genius to even but all that into bitbake.... Aug 08 10:20:47 buri: it boils down to pass the right options to the configure scripts Aug 08 10:21:01 buri: the autotools manuals describe this scenario Aug 08 10:25:17 thebohemian: I'll have a look at it. But to get bitbake to pass the right things on to autotools beats me. I'm not that familiar with the bb-files and classes... In general I feel rather lost with all the variables around... Aug 08 10:28:44 thebohemian: but thanks for the input. At least I know now what's it called what I'm trying to do. I will first get everything built and tested on the i686 directly before I attempt to leverage our cluster powered by x86_86 cores. Aug 08 10:37:08 florian: I got answer from the district court regarding OE e.V. I have to send money and we need to fix a few minor issues in our statutes Aug 08 10:37:34 florian: I will write a mail about this after work (or tomorrow) Aug 08 10:38:30 thebohemia1: ah cool Aug 08 10:38:47 thebohemia1: okay, so lets do this :) Aug 08 10:58:37 thebohemia1, thanks Aug 08 11:05:43 what is up with amethyst? Aug 08 11:06:32 anyone awake here? Aug 08 11:06:52 I have one small question about serial_cs on h2200 Aug 08 11:06:59 Crofton|work: mickeyl said somethign about network problems at the hosting location. Aug 08 11:07:16 I built a kernel with serial_cs and dependent modules (Koen gave me a patch to defconfig) Aug 08 11:07:21 but I get: Aug 08 11:07:32 <4>[ 253.950000] serial_cs: Unknown symbol serial8250_unregister_port Aug 08 11:07:33 <4>[ 253.950000] serial_cs: Unknown symbol serial8250_resume_port Aug 08 11:07:33 etc Aug 08 11:07:40 modprobe 8250 says device busy Aug 08 11:08:26 He promised to call there today... Aug 08 11:09:06 That's why I prefer renting servers :) Aug 08 11:09:45 and it's even cheaper :) Aug 08 11:11:47 we should send in the oe mafia Aug 08 11:50:06 does any project other that openembedded & consors use bitbake ? Aug 08 11:56:25 Genesis: I don't think so Aug 08 11:57:00 Genesis: however its used by openmoko, mamona and poky ;) Aug 08 11:58:25 so all the tasks are for building distro/packages/... Aug 08 11:59:19 bitbake is supposed to be a generic task manager , we don't associate bbclass in it because it's distro specific , i'm okay but i was wondering if it's really a good idea Aug 08 11:59:52 we could have bbclass by catégory in the bitbake tree Aug 08 12:01:22 i try to make a qemu-launch task but it's a bit different than other tasks i'm wrote Aug 08 12:07:38 mickeyl: you think the bothering about oe.org being down will stop now? :P Aug 08 12:08:00 i do :D Aug 08 12:13:35 josch|nsn: :D At least the answers will be shorter! Aug 08 12:14:17 heh Aug 08 12:19:57 mickeyl: yo Aug 08 12:21:35 hi pb__ Aug 08 12:23:26 mickeyl, do we need to send the OE mafia in to solve the connectivity issue? Aug 08 12:23:44 * Crofton|work curses the openmoko store not having anything to sell Aug 08 12:25:08 Crofton|work: you need jtag hardware? Aug 08 12:28:20 Crofton|work: heh, well, the one with access tries to reach the computing centre guys, but it's friday... Aug 08 12:29:44 hrw, no I want a freerunner Aug 08 12:29:50 hmmm Aug 08 12:30:05 * Crofton|work needs to move to a country where you do not work on Friday :) Aug 08 12:31:48 morning .... Aug 08 12:32:18 * chouimat|away hides his freerunner from Crofton|work sight ;) Aug 08 12:33:15 morning all Aug 08 12:34:05 hi thesing Aug 08 12:44:56 Crofton|work: freerunner... Aug 08 13:19:54 hello Aug 08 13:20:17 i see OE.org is down, any idea for how long? Aug 08 13:20:45 unfortunately not, it's an unscheduled outage Aug 08 13:21:13 my guess would be not later than monday Aug 08 13:23:36 is the monotone server still up? Aug 08 13:24:08 or is there a mirror? Aug 08 13:24:33 see topic Aug 08 13:26:26 ah ok Aug 08 13:45:18 wow the server must be getting hammered Aug 08 13:55:20 so i have compiled octave 3.0.0. After installing the 10 libraries, and finally the octave ipkg, I get this when I run it: octave: error while loading shared libraries: liboctinterp.so: cannot open shared object file: No such file or directory Aug 08 13:55:38 I have done this, which did not help: root@gumstix-custom-verdex:~$ find /* | grep liboctinterp.so Aug 08 13:55:38 /usr/lib/octave-3.0.0/liboctinterp.so.3.0.0 Aug 08 13:55:38 root@gumstix-custom-verdex:~$ export LD_LIBRARY_PATH=/usr/lib/octave-3.0/ Aug 08 13:55:45 any suggestions? Aug 08 13:56:05 actually that was /usr/lib/octave-3.0.0 (I fixed it).. Aug 08 14:00:10 try making a symlink from liboctinterp.so.3.0.0 -> liboctinterp.so Aug 08 14:00:35 if that fixes it, you need to look into the octave build to see why the binary is getting mis-linked like that Aug 08 14:27:52 pb__: thanks, i'll try that Aug 08 14:29:16 pb__: where do you think i should put that soft link? Aug 08 14:29:27 root@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ ls Aug 08 14:29:27 libcruft.so.3.0.0 liboctave.so.3.0.0 liboctinterp.so.3.0.0 Aug 08 14:31:48 lol look what i did on accident.... a symbolic link to itself Aug 08 14:31:50 root@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ ls -la Aug 08 14:31:50 drwxr-xr-x 2 root root 0 Aug 3 02:34 . Aug 08 14:31:50 drwxr-xr-x 11 root root 0 Jul 29 15:51 .. Aug 08 14:31:50 -rwxr-xr-x 1 root root 1690052 Jul 29 15:51 libcruft.so.3.0.0 Aug 08 14:31:50 -rwxr-xr-x 1 root root 4971956 Jul 29 15:51 liboctave.so.3.0.0 Aug 08 14:31:51 lrwxrwxrwx 1 root root 14 Aug 3 02:34 liboctinterp.s -> liboctinterp.s Aug 08 14:31:53 lrwxrwxrwx 1 root root 21 Aug 3 02:34 liboctinterp.so -> liboctinterp.so.3.0.0 Aug 08 14:31:55 -rwxr-xr-x 1 root root 7022736 Jul 29 15:51 liboctinterp.so.3.0.0 Aug 08 14:31:57 root@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ cat liboctinterp.s Aug 08 14:31:59 cat: liboctinterp.s: Too many levels of symbolic links Aug 08 14:32:01 oops, sorry for the long paste Aug 08 14:43:07 if i have a package, like gnuplot, installed on my embedded system - is there an easy way using ipkg to see how much room the package and its dependencies take up? Aug 08 14:48:09 no, not really. you could make a script to do it but there's no builtin facility. Aug 08 14:49:01 obviously there's the complication that you don't want, say, libc6 to get charged against gnuplot even though gnuplot depends on it. you'd need to make the script check for dependencies that aren't depended on by any other package, I guess. Aug 08 14:52:03 sure Aug 08 14:52:04 hmm Aug 08 14:57:26 alright, so i have an X server up and running but it loads matchbox, matchbox panel, desktop, etc. Aug 08 14:57:35 I can't figure out how to decouple matchbox from it Aug 08 14:57:47 xinit /etc/X11/Xsession -- /usr/bin/Xfbdev :0 -br -pn -screen 480x272@180 Aug 08 14:58:04 can i just get Xfbdev running and use gtk with that? or do i need matchbox too? Aug 08 14:58:19 we just have a single app that will be running Aug 08 14:58:53 I'm trying to use OE to generate a 'bootstrap' image of a kernel+initramfs, therefore my kernel recipe needs to have the initramfs cpio.gz as a DEPEND, yet if I create an image recipe for my initramfs that inherits task-base it depends on task-boot which depends on kernel - what is suggested? Aug 08 14:59:35 I see a 'bootstrap-image' recipe but it depends on MACHINE_TASK_PROVIDER which by default is task-base which depends on kernel Aug 08 15:00:14 don't use task-base, I suppose. Aug 08 15:00:55 you can roll your own filesystem from raw materials, and in the case of an initramfs that probably is what you want to do. Aug 08 15:01:00 ya, I was wondering if that would be the suggestion - but it seems like you would loose a lot of nice features by not using task-base, I'm wondering if task-base should really not be depending on kernel? Aug 08 15:01:36 what features would you lose? I don't think there's anything magic in task-base: anything it can do, you can do. Aug 08 15:02:04 pb__, yes, but I do like the concepts of task-base as I need to do this for several machines that have various hardware support - but I suppose I can recreate those aspects of task-base in my initramfs recipe Aug 08 15:02:26 I'm referring to the matchup of MACHINE_FEATURES and DISTRO_FEATURES Aug 08 15:03:02 tharvey: hm, right, but presumably you don't want most of that stuff in your initramfs anyway. Aug 08 15:04:37 pb__, perhaps not... I just didn't want to deviate from the standard way of doing things if there was a better way that I'm missing Aug 08 15:05:06 but, all that aside, I think probably the right answer to your original question is that the kernel image oughtn't to be depending on the initramfs.cpio.gz anyway. Aug 08 15:05:32 if you do that, it will be impossible to put any modules into the initramfs, which I suspect will defeat its purpose Aug 08 15:06:09 you probably want to have one recipe for the kernel which doesn't depend on anything, another recipe for the initramfs, which can depend on the kernel if it likes, and a third recipe to take the two things and glom them together to make the bootable binary lump. Aug 08 15:07:14 yes, I thought about that aspect as well Aug 08 15:07:44 currently I'm using initramfs via kernel CONFIG_INITRAMFS_SOURCE so in order to build the kernel the cpio.gz has to exist Aug 08 15:08:12 I think I need to change that to use an initrd (which can be a cpio.gz if I wish, or anything else initrd supports) Aug 08 15:08:39 ah, I see. well, in that case the third recipe (the one that does the combining) might be a variant of the kernel build. Aug 08 15:08:53 I wish to build a sing-file image with the kernel+initrd but as you say I could do that outside of the kernel build process and add another recipe that handles that Aug 08 15:09:14 so, in that case, you'd have two separate kernel recipes: one that builds the modules but doesn't include the cpio.gz, and then another one that builds the kernel with the initramfs included. Aug 08 15:09:58 pb__, ah... yes, you mean actually build the kernel first w/o INITRAMFS_SOURCE so that mods etc are built, then have a 3rd recipe that relinks the kernel or something? Aug 08 15:11:09 right Aug 08 15:11:19 I'm not sure there is really a huge benefit to using internal intramfs vs a cpio.gz initrd - in the 2nd case the kernel utilizes the initramfs code and doesn't really treat it as an initrd other than the fact the kernel got passed a pointer to it vs it being linked to the kernel directly (AFAIK) Aug 08 15:11:54 yeah, I don't think there is any significant difference between the two methods. Aug 08 15:12:06 if your bootloader knows how to pass an initrd, it is probably just as good to use that mechanism. Aug 08 15:13:21 ya, and in some cases such as powerpc's cuImage you can wrap up kernel+initrd with a bootwrapper that does it for you without the help of the bootloader Aug 08 15:13:57 right Aug 08 15:40:58 ERROR: '['/home/mranostay/easi-oe/projects/rmi_dbau1200/current/openembedded/packages/tasks/task-maemo.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'outo' but it wasn't found in any PACKAGE or RPROVIDES variables Aug 08 15:40:58 NOTE: Runtime target 'outo' is unbuildable, removing... Aug 08 15:40:58 Missing or unbuildable dependency chain was: ['outo'] Aug 08 15:41:07 any clue why that outo is missing from OE? Aug 08 15:44:30 pb_: I think we should split the build of the kernel into build modules and build kernel. Aug 08 15:44:58 why? Aug 08 15:47:54 hi all Aug 08 15:51:22 hi mrdata Aug 08 15:51:35 ih florian Aug 08 16:16:17 pb_: to solve the problem with initramfs with modules included. the initramfs could depend on package_modules and build_kernel on image:do_rootfs. Aug 08 16:28:57 thesing: true, but that is an uncommon case that is already soluble. it doesn't seem like breaking up the kernel build process for everyone would bring much benefit. Aug 08 16:30:30 pb_: if its done right nobody will notice. And the actual solution (having two recipies) is not very elegant. Aug 08 16:32:09 isn't two recipes exactly what you are proposing? Aug 08 16:32:19 maybe I don't quite understand your suggestion. can you explain it in more concrete terms? Aug 08 16:35:48 hi, Aug 08 16:35:49 is there an option for the bb git fetcher to specify a specific git branch to fetch? Aug 08 16:37:56 thesing: where do you specify the stic device tables for kexecboot? I think I mostly have it working, but I need to set up the mmc card nodes Aug 08 16:46:11 hvontres|work: you need to add device-table-collie.txt to DEVICE_TABLES (or so) Aug 08 16:46:25 hvontres|work: see collie.conf for an example Aug 08 17:08:31 is there some website that informs about the server status Aug 08 17:09:48 dcordes_: check here for updates.... Aug 08 17:10:56 ok Aug 08 17:51:05 bye Aug 08 19:40:55 what's the mtn incantation to pull from wolfson? Aug 08 19:44:42 grrrrrr Aug 08 19:52:16 * Crofton answers his own question by reading his email mtn pull opensource.wolfsonmicro.com org.openembedded.dev Aug 08 20:00:56 * chouimat|work kicks openssl-native for not building Aug 08 20:02:49 Crofton: do you know what the status is on openembeded.org? seems to have been down for a couple of days now Aug 08 20:03:20 not sure Aug 08 20:03:21 $topic Aug 08 20:03:26 it is in a data center Aug 08 20:03:33 and someone needs to kick it Aug 08 20:03:36 source.mvista.com is down also Aug 08 20:03:42 it's a conspiracy! Aug 08 20:03:43 but, apparently non one works on fridays Aug 08 20:03:45 yeah Aug 08 20:03:48 bash.org also Aug 08 20:03:58 maybe the internet tubes need cleaning Aug 08 20:04:04 an all out assault on open source! Aug 08 20:05:10 yes, really annoying Aug 08 20:08:43 Crofton|work: maybe there is a serious bug in the bind fix.... Aug 08 20:09:13 I've been wondering, although it feels more like rounting headaches Aug 08 20:09:38 either that or the chineese got a bit carried away trying to lock soen the internet Aug 08 20:10:14 err down that is Aug 08 20:13:36 Al Gore took it back. Aug 08 20:14:32 at least kernel.org still works :) Aug 08 20:14:54 re Aug 08 20:18:10 crap, builds go really slow when tinderbox is not there to receive results Aug 08 20:21:55 even if I don't add a package manager to an image, the image contains /usr/lib/opkg/* - I believe this is from the image creation step as ipkg is used to create the image - is there something in OE that allows this data to be cleaned out or should I simply add a custom task after do_rootfs to clean it? Aug 08 20:41:00 morning Aug 08 20:42:22 ant_: really :) Aug 08 20:43:25 hi Jay7 Aug 08 20:45:01 sh*t, again a u-boot_git change...basically 4-5 per week... Aug 08 20:45:17 even with wolfsonmicro... Aug 08 20:45:35 somebody can't resist and update it Aug 08 20:46:31 pb__: mercy Aug 08 20:47:14 looks like ROOTFS_POSTPROCESS_COMMAND would be good for what I'm looking for Aug 08 20:50:02 ROOTFS_POSTPROCESS_COMMAND = "remove_packaging_data_files" - remove_packaging_data_files is defined in rootfs_ipk.bbclass - but its not exported via EXPORT_FUNCTIONS - is EXPORT_FUNCTIONS required to export? Aug 08 20:51:51 Jay7: I have update the u-boot patch to the actual r16 and have bumped it to r17 Aug 08 20:52:08 now bugzilla is down I'll post it asap Aug 08 20:52:26 but are trivial chabge Aug 08 20:52:37 you can do by yourself Aug 08 20:53:09 ant_: send me whole package by email Aug 08 20:53:18 or patch only Aug 08 20:53:50 ok Aug 08 20:54:13 I'm not sure about my time at weekend but I'll try to test u-boot + kexecboot + .dev :) Aug 08 20:54:43 about u-boot, I really hope somebody will commit it and let us work on that foundation... Aug 08 20:55:00 kexecboot needs so much test as possible, though Aug 08 20:55:06 I hope too Aug 08 20:55:14 because will be heavily employed Aug 08 20:55:39 it's very bad that bugzilla is down.. :\ Aug 08 20:55:56 eh Aug 08 20:58:23 Jay7: now I'm conmpiling a new kexecboot kernel..if it's too big I'll just install u-boot and gain that few bastard kilobytes Aug 08 20:58:34 :-) Aug 08 20:58:38 :) Aug 08 20:59:46 hm.. may be I start up the build of .dev x11-image tonight.. Aug 08 21:02:09 I'm sending you the patch Aug 08 21:04:21 done Aug 08 21:06:14 is anyone familiar with using the various initramfs- images? I'm curious what they are doing with the resulting cpio.gz to get it built into a kernel w/o a chicken-and-egg scenario Aug 08 21:08:48 ant_: got it :) Aug 08 21:09:23 but I'm unsure about how recent is my local u-boot-zaurus package.. Aug 08 21:09:55 Jay7: remember you have to set the UBOOT_ENTRYPOINT="0x80008000" and UBOOT_LOADADDRESS="0x80008000" in akita.conf and CUSTOM_ROOTFS_SIZE and KERNEL_IMAGETYPE = "uImage" in local.conf Aug 08 21:10:24 or just do it by hand... Aug 08 21:10:58 we really need to push this work to .dev :) Aug 08 21:11:20 Jay7: kernel.bbclass is ready Aug 08 21:11:23 it's too easy to forget some of this Aug 08 21:12:14 nah, it's only that hack for rootfs-size...the rest should be standard oe for uImage deployment Aug 08 21:14:54 (but some lazy developer is not convinced...) Aug 08 21:24:22 Jay7: actually you can just improve akita.conf and set all the new vars there... Aug 08 21:24:34 ant_: what is solution with udev? Aug 08 21:24:43 comment out udevsettle? Aug 08 21:24:57 comment udevadm settle in /etc/init.d/udev Aug 08 21:25:06 in the last rel Aug 08 21:25:19 seems to work Aug 08 21:25:34 with kernel 2.6.26 you could even strace udevadm settle Aug 08 21:25:43 :-/ Aug 08 21:26:23 the delay introduced by strace seems enough to let it work without races Aug 08 21:26:43 but why only on Zaurus? must be some linux-rp problem... Aug 08 21:27:17 the behaviour is inconsisten between 2.6.24 and 2.6.26 (strace makes it work with latter) Aug 08 21:28:50 Jay7: or prefer udev_092 Aug 08 21:29:02 or udev_115 from Poky Aug 08 21:32:55 hvontres|work: is udev working ok on poodle? Aug 08 21:35:54 hehe.. I have open tab in my opera with udev bug from bugzilla :) Aug 08 21:36:14 4 days uptime :) Aug 08 21:38:03 Jay7: zImage-kexecboot-2.6.26-r2-c7x0.bin ?1303372?Aug 8 23:35 Aug 08 21:38:12 uh...too big... ;-] Aug 08 21:38:56 It's showtime :) Aug 08 21:39:14 now rootfs_size 96mb... Aug 08 21:39:22 just to see Aug 08 21:39:48 need a beer...pause Aug 08 21:42:42 ant_: I have looking into altlinux bugzilla Aug 08 21:43:07 they have problems with udevsettle in udev 0.96 Aug 08 21:43:20 here is some explanations Aug 08 21:45:46 quick solution applied - is to create file /dev/.udev/uevent_seqnum Aug 08 21:45:59 but I'm not sure that it's same problem Aug 08 21:50:38 ant_: look here when will back: https://bugzilla.altlinux.org/attachment.cgi?id=1583 Aug 08 21:55:30 Jay7: I think I already tried that patch... Aug 08 21:55:36 IIRC no go Aug 08 21:55:56 the only initscript working oob are _115 and the old _092 Aug 08 21:56:17 but hrw is working on this issue Aug 08 21:56:25 with udev_124 Aug 08 21:56:40 http://svn.o-hand.com/view/poky/ Aug 08 22:00:40 ant_: did you try it? Aug 08 22:01:50 not yet, now working on kexec-bootmenu Aug 08 22:02:25 tried a previous version with the hack from u-dev ml Aug 08 22:02:38 the one I posted on bug 4118 Aug 08 22:03:02 ok Aug 08 22:03:08 at least you see which devices are left out Aug 08 22:03:18 if you don't give enough time Aug 08 22:04:04 Jay7: I forgot you have to set UBOOT_MACHINE="akita_config" too Aug 08 22:04:15 hm.. Aug 08 22:04:30 at least I have (c7x0 != corgi) Aug 08 22:04:45 ant_: where it should be inserted? Aug 08 22:04:52 local.conf/akita.conf? Aug 08 22:04:53 akita.conf Aug 08 22:04:56 ok Aug 08 22:05:08 where you like, now I have all in machine.conf Aug 08 22:07:23 can you mail me latest u-boot-zaurus too? Aug 08 22:07:58 or it is not needed anymore? Aug 08 22:08:07 Jay7: it works ! I have u-boot.bin and u-boot-c7x0-git-r17.bin (the kernel) in my deploy dir Aug 08 22:08:13 no, delete it Aug 08 22:08:23 it's now merged in u-boot_git.bb Aug 08 22:08:37 that's why the frequent updates... Aug 08 22:10:20 Jay7: hmmm I have no uImage...sorry... Aug 08 22:11:39 ant_: your diff don't provide patches Aug 08 22:12:08 ? Aug 08 22:12:19 # patch "packages/u-boot/u-boot_git.bb" Aug 08 22:12:20 # from [dd5c9df20b550f8e184483944ba911d7de096d98] Aug 08 22:12:20 # to [5b959df4c25d00f0207145c9e111401dae0ee696] Aug 08 22:12:39 ah, how are you importing it ? Aug 08 22:13:01 just add the couple of lines... Aug 08 22:13:21 file://pdaXrom-u-boot.patch;patch=1 Aug 08 22:13:38 ouch...you are right... Aug 08 22:13:41 and next two Aug 08 22:13:48 sorry... Aug 08 22:13:50 1 mom Aug 08 22:13:53 np Aug 08 22:14:02 (I hate mtn diff) Aug 08 22:17:55 9.8G tmp/ Aug 08 22:18:10 wow.. Aug 08 22:20:01 Jay7: ok, I forgot to 'mtn add' the files after a checkout... Aug 08 22:22:08 mail resent Aug 08 22:22:21 10x :) Aug 08 22:23:12 yes, I remember I had to delete org.openembedded.dev because it was fscked and did not recognize anymore the arch (some crazy messages like defaulting to I686...) Aug 08 22:23:32 si I did a fresh checkout from wolfsonmicro Aug 08 22:24:21 2nd try is bigger at least :) Aug 08 22:25:02 should be all this time... Aug 08 22:27:22 ehh.. I will to save previous builds against .stable but I have no 10G now.. Aug 08 22:28:21 btw is here some scripts to clean up sources directory? Aug 08 22:28:29 do you use INHERIT += "rm_work" in your local.conf ? Aug 08 22:28:44 no I did not Aug 08 22:28:48 (like Gentoo) Aug 08 22:28:55 try ;-) Aug 08 22:28:55 ah Aug 08 22:29:10 good idea :) Aug 08 22:29:38 would be a good idea if you add your builds to oestats Aug 08 22:30:09 howto? :) Aug 08 22:30:10 INHERIT += "oestats-client" Aug 08 22:30:10 OESTATS_BUILDER = "Jay?" Aug 08 22:30:10 OESTATS_SERVER = "tinderbox.openembedded.net" Aug 08 22:30:24 but it's down atm... Aug 08 22:30:30 he he Aug 08 22:30:54 remind me when it will be back :) Aug 08 22:31:03 put it now Aug 08 22:31:14 then if you want to add smthg ##ANGSTROM_EXTRA_INSTALL = "mc gpe-bluetooth gpsd speech-dispatcher flite navit" Aug 08 22:31:22 or similar Aug 08 22:31:31 all above in local.conf Aug 08 22:32:35 I'm not sure anybody is testing akita... Aug 08 22:34:13 ok, I've added Aug 08 22:34:20 Jay7: if you want to build all the possible dependencies, add BB_DEFAULT_TASK = "buildall" to local.con (similar to emerge -D) Aug 08 22:37:40 * Jay7 is waiting for rm -rf in work/*/* Aug 08 22:40:19 Jay7: sorry..right ones are UBOOT_LOADADRESS_akita = "0xa0800000" Aug 08 22:40:20 UBOOT_ENTRYPOINT_akita = "0xa0800000" Aug 08 22:40:37 and perhaps UBOOT_MACHINE_akita = "akita_config" Aug 08 22:41:02 then you have to set somewhere CUSTOM_ROOTFS_SIZE_akita ?= "59392k" Aug 08 22:41:25 (default in patched u-boot_git.bb) Aug 08 22:41:35 ok, fixed Aug 08 22:41:46 http://projects.linuxtogo.org/pipermail/openembedded-issues/2008-February/007432.html Aug 08 22:41:59 google cache is your friend Aug 08 22:42:53 nowI have to see why the mkimage step is skipped... Aug 08 22:43:26 where, why I can guess :-) Aug 08 23:05:01 ant_: I've started up build of console image Aug 08 23:05:20 now I go sleep :) resume experiments at morning Aug 08 23:05:42 good night Aug 08 23:05:59 you too **** ENDING LOGGING AT Sat Aug 09 02:59:56 2008