**** BEGIN LOGGING AT Thu Sep 27 02:59:57 2007 Sep 27 03:44:50 * davygravy is away: ...for a while... Sep 27 06:55:23 morning. is there a possibility to convert a .jffs2 image to a ramdisk image? Sep 27 08:19:57 gm Sep 27 08:21:51 koen: i installed the angstrom distribution on an ep93xx machine. loaded zimage and the jffs image to the board and fired it up. now comes the error, seems that the board dont like jffs images Sep 27 08:21:55 No filesystem could mount root, tried: ext3 ext2 vfat Sep 27 08:21:57 any suggestions? Sep 27 08:21:59 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,2) Sep 27 08:25:54 morning Sep 27 08:29:44 nik0n: rootfstype=jffs2 on the kernel command line? Sep 27 08:32:31 likewise: oh nice looks better now ... haven't found that info anywhere Sep 27 08:34:21 nik0n: well, I had expected that the kernel tried jffs2 as well. Sep 27 08:34:39 nik0n: which ep93xx machine, btw? Sep 27 08:45:21 glomation GESBC-9302E Sep 27 08:51:46 damn now i see Sep 27 08:51:47 /sbin/init: '/lib/libgcc_s.so.1' is not an ELF file Sep 27 08:51:47 /sbin/init: can't load library 'libgcc_s.so.1' Sep 27 08:54:04 how do i compile the libs as ELF files? Sep 27 08:56:59 file tells me: libgcc_s.so.1: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Sep 27 09:16:11 nik0n: what are you doing? Sep 27 09:17:49 likewise: trying to boot up my distro Sep 27 09:20:25 nik0n: your own OE based distro? Also, maybe I missed what board you are targetting? EABI build? Sep 27 09:24:03 likewise, yes my own oe distro with gcc 4.1.2, binutils 2.17.50.0.5, uclibc 0.9.29 Sep 27 09:24:41 gcc 4.1.2 seems to be EABI ready but havent found any option to set that it should do EABI. looks like it autamatically uses eabi when possible Sep 27 09:25:11 nik0n: angstrom distro can be configured to use EABI and maybe still supports OABI (not sure) Sep 27 09:26:48 i wannt to use my own distro cause of special paket versions etc and i dont want to mess with the repository files so i set up a own distro Sep 27 09:30:06 angstrom seems to use eabi per default Sep 27 09:30:17 and only makes a oabi fallback for some archs Sep 27 10:01:10 hi Sep 27 10:01:58 nik0n: yes, angstrom uses EABI for ARM by default Sep 27 10:02:12 nik0n: it does so by changing the TARGET_ARCH variable Sep 27 10:02:19 I'm fighting bug #3067, and getting nowhere Sep 27 10:03:08 !oebug 3067 Sep 27 10:03:18 if I do a "svn co " of the URI for dcopidl2cpp-native, I can fetch the sources, but they are created under dcop/ Sep 27 10:03:58 if I do a "bitbake -c fetch", I get a "svn: Target path does not exist" Sep 27 10:05:13 Bernardo: is it using svn or http protocol? Sep 27 10:05:48 Bernardo: bitbake is probably using a revision where that path doesn't exist Sep 27 10:06:18 ah yeah SRCREV=1 tends to have no files Sep 27 10:07:28 itś using svn Sep 27 10:07:41 and I checked that it exits Sep 27 10:07:44 exists Sep 27 10:08:00 Bernardo: what SRCREV did you set for that svn? Sep 27 10:08:37 I didn't set any - and stupidly just assumed that this one would be in sane-srcrevs withouth checking Sep 27 10:09:06 Bernardo: heh heh, probably not done yet then Sep 27 10:09:06 the current rev is 717682 Sep 27 10:09:18 Bernardo: set one in sane-srcrevs and retry Sep 27 10:10:32 ok, I'll try the current one, as both this and dcopidl haven't changed in months Sep 27 10:11:46 if I set SRCREV=AUTOREV in a bb file it will pull from head? Sep 27 10:11:59 ${AUTOREV} isnt it Sep 27 10:12:14 something like that :) Sep 27 10:12:41 since this comes up often, I thought we should rview the proper answer Sep 27 10:12:52 noting this may lead to parsing breakage :) Sep 27 10:14:30 Regardless of which we choose, someone won't like it Sep 27 10:14:48 of course :) Sep 27 10:15:15 we just need to make sure we all understand the problem so we can get people past it wuickly ... Sep 27 10:16:39 who is the git fetcher guru? Sep 27 10:17:47 well, I've added dcopidl2cpp-native and dcopidl-native revisions to sane-srcrev, we'll see if it fetches Sep 27 10:21:49 Crofton: I wrote it... Sep 27 10:22:36 rp, when I build u-boot for davinci-dvevm, (which needs u-boot from giit) Sep 27 10:22:49 it works on one of my machines and fials on two others Sep 27 10:23:00 works on 32 bit machine, failing on 64 bit Sep 27 10:23:17 Crofton|home: Did they all build git-native? Sep 27 10:23:27 let me check Sep 27 10:24:18 yes Sep 27 10:24:40 Crofton|home: It sounds like something might be wrong with the git builds on 64 bit :/ Sep 27 10:24:48 will you be at OEDEM? Sep 27 10:24:50 yeah Sep 27 10:24:53 I will Sep 27 10:25:01 I will have a failing build there Sep 27 10:25:19 I made the linux-davinici kernel depend only on uboot-utils Sep 27 10:25:57 * RP suspects OEDEM will be a bit action packed Sep 27 10:26:44 http://rafb.net/p/hkqdbo36.html Sep 27 10:26:54 is what the failure look slike Sep 27 10:27:33 on succeedings builsd the needs update is followed by a Fast Gorward ..... Sep 27 10:27:39 is OEDEM free of charge? Sep 27 10:28:34 Crofton|home: That does look more like the git fetcher is broken in some way :/ Sep 27 10:28:49 nik0n: Yes, but we need to know whos coming in advance Sep 27 10:28:58 http://www.openembedded.org/wiki/OEDEM2007 Sep 27 10:30:06 RP, let me know if I need to try anything for you Sep 27 10:30:24 Crofton|home: I can't even look at this at the moment, sorry :-( Sep 27 10:30:52 well, then I will wave my laptop at you during OEDEM :) Sep 27 10:31:01 I have a work around Sep 27 10:31:20 Crofton|home: ;-) Sep 27 10:33:54 still failed... :( Sep 27 10:34:14 will try Crofton|home suggestion now Sep 27 10:34:35 Bernardo, what bb file is this? Sep 27 10:35:42 Crofton|home: packages/dcop/dcopidl2cpp-native.bb and packages/dcop/dcopidl-native.bb Sep 27 10:36:37 I've added "SRCREV_dcopidl2cpp-native ?="717682"" to sane-srcrev Sep 27 10:37:02 the packages have a version so PV is set to 3.5.4 Sep 27 10:37:02 RP: Hi! Can you please respond to "cairo-directfb RPROVIDES" discussion on OE ML? Sep 27 10:37:11 but the src uri is svn Sep 27 10:37:55 should the bb file be call something _svn? Sep 27 10:38:41 psokolovsky: I will respond its on the todo list Sep 27 10:38:51 RP: thanks. Sep 27 10:39:22 psokolovsky: There are a few mails there I need to reply to, its just a time problem :-( Sep 27 10:39:27 possibly. So the package version "overloads" the sane-srcrev version? Sep 27 10:39:33 Bernardo, maybe Sep 27 10:39:58 I am no guru at this, but that seems plausible Sep 27 10:40:12 add srv rav insode the bb file Sep 27 10:40:16 or modify pv Sep 27 10:40:22 to svn Sep 27 10:40:33 who created bb file? Sep 27 10:40:52 no idea, I just found out a couple of days ago it wouldn't fetch Sep 27 10:41:25 I wonder why someone would create a bb file with a rev no, but use a svn url for fetching source? Sep 27 10:42:09 it was probably changed recently to use a svn url Sep 27 10:42:34 adding SRCREV="717682" in the bb file allows it to fetch Sep 27 10:43:38 same thing for dcopidl-native Sep 27 10:47:42 the package name should be fixed to reflect where the srouce comes from Sep 27 10:47:48 or create a svn version Sep 27 10:47:57 in case someone uses the old version Sep 27 10:56:28 I don't have write access. I'll put your comments on bug #3067, in case one of the devs cares to fix it. Sep 27 11:03:26 any preferences on the PREFERRED_PROVIDER for classpath in Angstrom? Sep 27 11:06:50 hi everyone Sep 27 11:14:51 * Bernardo is away: Ausente por agora. Sep 27 11:17:16 haha mtn history is so odd... Sep 27 11:17:51 ? Sep 27 11:17:55 how so? Sep 27 11:18:19 aa05aa9171bac92766b769bbb703287f53e08693 is a merge Sep 27 11:18:44 the funny thing about it is, the new manifest and the two manifests of the parents are the same :) Sep 27 11:19:00 o_O Sep 27 11:19:25 well first of all i've got to say I wish oe was using git ;] Sep 27 11:19:49 they'll switch to git soon :p Sep 27 11:20:03 good :) Sep 27 11:20:09 I'm sure we won't switch to git as primary scm. Sep 27 11:20:32 it is much faster... oh and well.. keeps me from getting used to yet another scm hehe Sep 27 11:20:47 but personally I want to have something like git-mtn (similiar to git-svn) Sep 27 11:21:11 well are there any advantages over git ? Sep 27 11:21:25 something to make up for speed Sep 27 11:21:57 gilligan_: yes, once we finally do releases mtn and the support for custom certs will help us a lot Sep 27 11:22:21 gilligan_: and personally that is a reason to stay with mtn Sep 27 11:29:52 i see.. Sep 27 11:38:17 cbrake_away, kernel command line still doesn't seem to be right here.. just tried Sep 27 11:42:34 cbrake_away, nevermind.. my fault i think ;] Sep 27 11:55:55 !^#$(*)!_@$@!!! Sep 27 11:56:05 still can't create a working kernel/rootfs Sep 27 11:56:07 sigh Sep 27 12:12:01 fca159c5c00ae4158c289f5aabce995378d4e41b another nice revision :} Sep 27 12:17:35 cbrake_away, just rebuild and the kernel parameters don't get passed through here Sep 27 12:17:44 s/rebuild/rebuilt Sep 27 12:19:27 cbrake_away, does not matter much though because even if I do specify them I am *still* having the same problem where the kernel just stops at "freeinig init memory" or whatever that msg was.. Sep 27 12:22:03 something is really broken.. Sep 27 12:31:09 zecke, sysvinit_2 needs to be recompiled because of some changed variables but bitbake doesn't get that.. how do I compile the package specifically ? Sep 27 12:31:37 with -b i suppose.. Sep 27 12:33:04 no..because that "thinks" there is nothing to be done Sep 27 12:34:54 anyone else? Sep 27 12:37:16 ;[ Sep 27 12:42:27 gilligan_: moin Sep 27 12:42:39 cbrake, hi there Sep 27 12:42:40 gilligan_: whenever you change .bb in such a way that leads to changing of package, you bump PR there Sep 27 12:42:53 gilligan_: bitbake -c rebuild Sep 27 12:42:54 gilligan_: for local changes, use fractional PR Sep 27 12:43:06 "PR" ? Sep 27 12:44:24 ggilbert: well, increment the PR (PackageRelease) Sep 27 12:44:32 gilligan_: well, increment the PR (PackageRelease) Sep 27 12:44:41 gilligan_: or use -b buildfile -crebuild Sep 27 12:45:00 gilligan_: did you see my serial port changes in compulab-px270.conf? Do they make sense? Sep 27 12:45:24 cbrake, well makes sense i guess, just doesn't work yet Sep 27 12:45:43 gilligan_: kernel defconfig, or inittab? Sep 27 12:46:12 changes aren't reflected anywhere.. which I suppose is because bitbake doesn't figure out it needs to rebuild stuff Sep 27 12:46:37 gilligan_: the kernel should rebuild because I bumped the PR, but sysvinit you will need to -c rebuild Sep 27 12:46:55 just did that Sep 27 12:47:05 let me check initab in the rootfs .. Sep 27 12:47:06 gilligan_: or whatever makes inittab in angstrom-minimal-image ... Sep 27 12:48:06 nope Sep 27 12:48:10 it's still ttyS0 Sep 27 12:48:38 gilligan_: which is what you want for your module -- if you have a W module? Sep 27 12:49:12 no? :) i want ttyS0 Sep 27 12:49:18 L is ttyS1 Sep 27 12:51:55 gilligan_: but you said it is still ttyS0 -- which is right? Sep 27 12:52:11 sorry.. typo Sep 27 12:52:33 i meant, it is ttyS0, although i added CMX270_CONSOLE_SERIAL_PORT = "ttyS0" to local.conf Sep 27 12:52:59 on top of that the kernel parameters are empty Sep 27 12:53:40 or well.. I would suppose the ones set as default command lines in the kernel config would show up during boot ? Sep 27 12:53:46 Linux image detected in memory at 0xA0100000, booting... Sep 27 12:53:46 Kernel parameters: Sep 27 12:53:53 which they don't Sep 27 12:54:22 then again as I don't get any other output from that point on they might just not be displayed and what's actually being passed is ttyS1 once again Sep 27 12:54:27 which goes to nirvana for me Sep 27 12:56:26 cbrake, so either something still hasn't been rebuilt or the serial console variable is not passed on properly somehow.. dunno.. Sep 27 12:56:52 gilligan_: check tmp/work/compulab-pxa270-angstrom-linux-uclibcgnueabi/compulab-pxa270-2.6.22-r1/linux-2.6.22/.config Sep 27 12:57:04 gilligan_: for the kernel CMDLINE -- this is what will go into your image Sep 27 12:58:00 interesting Sep 27 12:58:09 it says ttys0 there Sep 27 12:58:46 which doesn't seem to be the case though Sep 27 12:59:07 gilligan_: and tmp/work/compulab-pxa270-angstrom-linux-uclibcgnueabi/sysvinit-2.86-r36/install/sysvinit-inittab/etc/inittab to debug the inittab problem Sep 27 12:59:24 cbrake, what does "Kernel parameters:" list when you boot ? (and don't enter anything at the bootline prompt by hand) Sep 27 13:00:04 gilligan_: if I boot using the bootos command I get: Kernel command line: console=ttyS1,38400 monitor=8 bpp=16 mem=64M mtdparts=physmap-flash.0:256k(boot)ro,0x180000(kernel),-(root);cm-x270-na Sep 27 13:00:08 nd:64m(app),-(data) rdinit=/sbin/init root=mtd3 rootfstype=jffs2 Sep 27 13:00:14 see I don't get that Sep 27 13:00:16 just empty Sep 27 13:00:57 gilligan_: well, its in the OE working tree correctly, so there are only two options -- you are flashing the wrong image, or the BL is somehow setting the CMDLINE Sep 27 13:01:01 cbrake, the inittab has ttyS1 Sep 27 13:01:47 gilligan_: "bitbake sysvinit -c rebuild" and that should change to ttyS0 Sep 27 13:01:58 did that already.. but i will try again Sep 27 13:03:07 cbrake, now one is ttyS1 and one is ttyS0 hehe .. Sep 27 13:03:16 cbrake, S:2345:respawn:/sbin/getty 38400 ttyS0 Sep 27 13:03:23 cbrake, 1:2345:respawn:/sbin/getty 38400 tty1 Sep 27 13:03:48 did you possibly miss one? Sep 27 13:03:49 gilligan_: tty1 is the real console (display/keyboard) Sep 27 13:04:01 ah Sep 27 13:04:04 oh ok Sep 27 13:04:06 alright then Sep 27 13:05:40 will flash again... Sep 27 13:08:01 wish that process could be automated. ;] Sep 27 13:09:37 gilligan_: perhaps write a bitbake recipe with a little pexpect that would automatically flash a cm-x270 :-) Sep 27 13:10:16 gilligan_: bitbake cm-x270-flash-kernel Sep 27 13:10:19 I would still have to use the armmon console i suppose Sep 27 13:10:58 gilligan_: right, but that could all be automated with expect or pexpect Sep 27 13:11:38 well yes okay.. i could of course feed the serial port with the appropriate commands Sep 27 13:11:56 cbrake, right..actually a good idea Sep 27 13:13:19 cbrake, BUT.. that is all of no use until i get the kernel/ramdisk to work.. which still isn't the case.. like always it stops at "Freeing init memory" Sep 27 13:13:24 gilligan_: the advantage of doing in bitbake as you can then use the variables to know where the kernel image is, etc Sep 27 13:13:28 cbrake, kernel command line is fine though Sep 27 13:15:41 gilligan_: that is a puzzle -- why do my kernels work and yours do not -- when we are building the exact same kernel recipe Sep 27 13:16:04 gilligan_: can you upload your latest kernel one more time and I'll give it a try with the NAND rootfs? Sep 27 13:16:49 oh, hm.. "Freeing init memory" is from sysvinit already.. not from the kernel by the way Sep 27 13:17:31 gilligan_: nod Sep 27 13:17:52 thought that's still kernel cleaning up Sep 27 13:18:10 uploading files... Sep 27 13:18:33 hey all Sep 27 13:19:15 I have been trying to build rhythmbox and finally looked at it again. printed out what version of gstreamer it thinks it has. I think it is looking at the pc's version, not OE's version. Sep 27 13:19:28 gilligan_: my latest is ftp://bec-systems.com/pub/cmx270-kernel-2 Sep 27 13:19:37 cbrake, http://www.xuanfengjiao.de/rootfs.cpio.gz and http://www.xuanfengjiao.de/zimage.bin Sep 27 13:19:54 I didn't see anything in the recipe about autotools etc. How do I make it where it uses oe's version, and not the pc version? Sep 27 13:23:11 cbrake, what are you building on ? x86/amd64/.. ? Sep 27 13:24:59 gilligan_: ubuntu 7.04, amd64 Sep 27 13:25:01 gilligan_: and you? Sep 27 13:25:21 gilligan_: same thing here with your latest kernel -- stops after "Freeing init memory: 104K" Sep 27 13:25:33 cbrake, also 7.04/amd64 Sep 27 13:25:43 cbrake, your kernel works fine with my ramdisk Sep 27 13:25:53 cbrake, this is pretty bizzare Sep 27 13:26:03 gilligan_: I have not tried that, but it did before Sep 27 13:26:05 cbrake, have you ever updated the bootloader? Sep 27 13:26:21 gilligan_: yes, back in feb or so Sep 27 13:26:35 gilligan_: but this is not tied to a particular board Sep 27 13:26:54 Welcome to ARMmonitor running on Compulab CM-X270. Sep 27 13:26:54 Copyright Compulab 2002, 2003, 2004, 2005, 2006 (c). Sep 27 13:26:54 Built at: Wed Aug 16 14:09:35 IDT 2006 on 89 Sep 27 13:27:43 gilligan_: I'm using this version: Built at: Thu Jun 14 11:56:49 IDT 2007 on 89 Sep 27 13:28:41 cbrake, would be strange if that had any influence.. but there has to be /some/ external influence explaining this Sep 27 13:28:58 gilligan_: almost has to be host related Sep 27 13:30:32 gilligan_: the sizes are slightly different: http://pastebin.ca/717194 Sep 27 13:30:33 cbrake, hm.. when you build the kernel with serial port set to ttys0 (so the kernel cmdline is the same) then our kernel binaries should be 100% equal Sep 27 13:31:08 gilligan_: there will be some time stamps and other things that will be different, but they should be very close to the same size it seems Sep 27 13:31:26 time stamps.. oh ok Sep 27 13:32:19 gilligan_: I suspect 3000 bytes difference is size is too much Sep 27 13:32:32 absolutely Sep 27 13:32:46 certainly not that many time stamps etc Sep 27 13:33:45 cbrake, so what has influence on the kernel.. the compiler obviously.. and... Sep 27 13:34:37 gilligan_: I'm at a loss, but this has worked for several other people. I suggest trying to build a kernel outside OE on another machine if you can find a toolchain, etc Sep 27 13:34:51 gilligan_: keep narrowing things down until you find the culprit Sep 27 13:35:25 could build on my old pc.. that would take quite some time though hehe Sep 27 13:36:22 checking for pkg-config... /oe/build/tmp/staging/i686-linux/bin/pkg-config Sep 27 13:36:27 this is the problem I have... Sep 27 13:36:34 cbrake, is there something like 'make clean' for bitbake by the way? to perhaps build angstrom from scratch Sep 27 13:36:38 christopher: gnome.class inherits autotools Sep 27 13:36:42 instead of finding pkg-config for the target, it gets it for the host! Sep 27 13:37:10 cbrake: ok. yeah, I tried it just to see if it would make a difference. problem is it is picking the wrong pkg-config Sep 27 13:37:24 at least, that's what I think is the issue. shouldn't it find the one for the target (arm) Sep 27 13:37:39 christopher: bitbake rhythmbox devshell, and then interactively run the ../temp/do.run_ scripts until you find the problem Sep 27 13:38:04 gilligan_: rm -rf tmp Sep 27 13:38:12 cbrake, haha.. ok Sep 27 13:41:35 christopher: make that bitbake rhythmbox -c devshell Sep 27 13:41:52 cbrake, i don't expect much from it.. but I will try a rebuilt and do some paper-work meanwhile. When I (prolly) get the same outcome as before i'll have to think of some other things (like compiling on a different PC etc) Sep 27 13:42:00 cbrake: ok. yeah, tried that and it didn't do anything interactively. :) Sep 27 13:42:09 cbrake, and thanks for all your help so far Sep 27 13:42:19 gilligan_: you're welcome Sep 27 13:44:20 cbrake: ok. so, once you get the shell, do you just type in all of the commands by hand or how do you tell it to go to the next step? Sep 27 13:44:33 cbrake, the compulab kernels have some length bytes prepended from what I recall reading.. ? Sep 27 13:45:41 christopher: ../temp/run.do ... Sep 27 13:45:59 christopher: you can usually type "make" right in the shell, but configure you typically need to run from the script Sep 27 13:46:13 christopher: or see what options its using and add then when you run configure manuallky Sep 27 13:46:36 gilligan_: tftp download automatically prepends the bytes to the kernel -- its just a size Sep 27 13:49:26 i see.. it's just that I would have expected `file zimage.bin` to recognize it as a kernel image Sep 27 13:54:18 cbrake, should I make any changes to PREFERRED_PROVIDERS in local.conf ? Sep 27 13:55:39 gilligan_: no Sep 27 13:57:46 cbrake, do you have parallel building enabled ? Sep 27 13:58:46 gilligan_: often I do, in some of my builds I do not Sep 27 13:59:02 gilligan_: you can see my build setup at: https://dev.bec-systems.com/svn/oe Sep 27 14:00:19 cbrake, ah..nice Sep 27 14:02:09 oh... Sep 27 14:03:40 cbrake, you specify DISTRO_FEATURES = "ext2 usbhost" in your local.conf.. which might change the kernel Sep 27 14:04:06 autoreconf: running: automake --foreign --add-missing --copy --force-missing --warnings=cross Sep 27 14:04:06 automake: unknown warning category `cross' Sep 27 14:04:12 that seems like the first problem. Sep 27 14:04:19 like it is trying to tell it to cross compile, but it doesn't understand Sep 27 14:04:28 gilligan_: probably not -- at least not this kernel Sep 27 14:04:50 NOTE: Running /oe/build/tmp/work/armv4t-angstrom-linux-gnueabi/rhythmbox-0.8.7-r0/rhythmbox-0.8.7/configure --build=i686-linux --host=arm-angstrom-linux-gnueabi --target=arm-angstrom-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/shar Sep 27 14:04:50 e --sysconfdir=/etc --sharedstatedir=/usr/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-schemas-install Sep 27 14:05:20 then it does that. what is the --build=i686 business? guess that is coming from the others even though the target is arm Sep 27 14:05:25 seems all messed up Sep 27 14:06:12 cbrake, where is that variable actually being parsed ? well i was thinking it might compile in some etx2/usb support which in my case might not be enabled leading to different kernel sizes ? Sep 27 14:08:33 cbrake, but looking at angstrom.inc -- doesn't it overwrite DISTRO_FEATURES so that your setting in local.conf is being is ignored? Sep 27 14:12:33 gilligan_: yes, it does look like they get overwritten Sep 27 14:13:28 neat, mono 2.0 profile working on my cm-x270 :-) Sep 27 14:14:02 ;] Sep 27 14:14:27 cbrake, well i'll first try a normal build and then i think i'll try to drop some kernel features Sep 27 14:20:43 cbrake: did a compare of do configure for gqview which works and do configure for rhythmbox. same thing other than the changes in direcotry names between rhythmbox and gqview. it must need something else to be able to find gstreamer that something like gqview doesn't need Sep 27 14:25:05 rather random question: anyone here going to CCC congress this December? :] Sep 27 14:27:16 time to cook some coffee.. Sep 27 14:36:44 christopher: I don't know offhand what might be the issue -- cross compiling can be a real pain sometimes :-\ Sep 27 14:37:24 cbrake: no doubt. I just figure that someone put that recipe in and that it worked for them. must have worked when built for host Sep 27 14:39:00 cbrake: I guess I start to wonder about other pieces that may have compiled but what if somehow they are using a library from the host instead of from oe that was cross compiled and marginally gets by Sep 27 14:44:18 hi all - I'm working on building an image for a gumstix and bitbake keeps failing saying it can't find mkfs.jffs2, but I can clearly see it has been made for my host in the tree - am I missing something? Sep 27 14:47:15 what distro? Sep 27 14:47:25 which machine.conf? Sep 27 14:48:23 scruggs, gumstix-verdex builds for me with angstrom Sep 27 14:49:30 I'm working off of Craig's org.gumstix.oe branch - DISTRO = "gumstix-distro" - MACHINE = "gumstix-connex" Sep 27 14:49:39 hmmm Sep 27 14:49:49 the build seems to go fine till it tries to make the jffs2 image Sep 27 14:49:51 curse vendor branches Sep 27 14:49:52 :) Sep 27 14:50:06 still better than buildroot :) Sep 27 14:50:11 heh Sep 27 14:50:31 basically, the problem is we have a hard enough time supporting .dev Sep 27 14:50:51 I have an old copy of Craig's, but my interest is keeping dev working Sep 27 14:50:58 as best I can tell most of Craigs stuff is kernel patches and some confs for the image, etc Sep 27 14:51:02 yeah Sep 27 14:51:13 we have different ways of solving problems Sep 27 14:51:38 I agree - for the long run I really don't want to go away from the main dev branch Sep 27 14:51:38 we will neeed to work with Craig, but that will have to wait until after OEDEM Sep 27 14:51:58 can you try the same build against .dev? Sep 27 14:52:04 except use angstrom? Sep 27 14:52:20 sure thing Sep 27 14:53:20 I nly have a verdex with the brand new netwifi-microSD for testing Sep 27 14:53:32 there is a guy sakoman around here who works with connex Sep 27 14:54:28 ok, I'll keep an eye out Sep 27 14:55:11 later on, I'll try building from his branch also Sep 27 14:55:17 need to head over to school now Sep 27 14:58:57 cbrake, build done.. lets see if anything changed... *shrug* .. Sep 27 15:10:48 cbrake, and as expected.. same behavior... Sep 27 15:19:26 hi likewise Sep 27 15:19:46 hrm.. bitbake makes no sense to me Sep 27 15:20:50 cbrake, still there? Sep 27 15:21:11 gilligan_: yup Sep 27 15:22:33 cbrake, do the DISTRO_FEATURES settings do actually change the kernel config ? like specifying ext2 will compile ext2 support in etc Sep 27 15:23:15 I'm adding Mono 1.2.5.1 -- what should I name the recipe as it has 4 version chunks, or does anyone know of anything similiar? Sep 27 15:23:49 gilligan_: no, DISTRO_FEATURES do not impact the kernel config for the cm-x270 in any way that I know of Sep 27 15:24:04 cbrake, hm ok Sep 27 15:24:25 cbrake, then i'll poke around in the compulab kernel package Sep 27 15:25:01 gilligan_: distro/machine features are used in task-base.bb to add various packages to an image Sep 27 15:25:19 gilligan_: the only thing that it affects kernel wise are including modules if they are available Sep 27 15:25:42 gilligan_: as we are building the minimal image, the DISTRO/MACHINE features has no affect, as it does not use task-base Sep 27 15:25:53 cbrake, okay Sep 27 15:26:47 cbrake, i suppose i can just modify the defconfig file in packages/linux/compulab-pxa270-2.6.22 to toy around a bit ? Sep 27 15:28:50 HopsNBarley: hi Sep 27 15:29:06 cbrake, do you know if EIP (execute in place is enabled) ? at least i can't find that string or anything alike in the config file.. Sep 27 15:29:57 gilligan_: should not be Sep 27 15:30:02 cbrake, okay good Sep 27 15:30:28 I guess I can just use the mono version number as is 1.2.5.1 ... Sep 27 15:39:02 cbrake, removed some stuff from the kernel and added sysreq support.. question is of course if I'll be able to input anything to use sysreq at all.. plus i am not exactly a kernel-lowlevel-hacking expert but who knows maybe it leads to somewhere Sep 27 15:52:51 oookay.. now THAT was rather *dumb* Sep 27 15:52:59 just killed my host with sysreq+k hehe Sep 27 16:05:12 cbrake, do you think at the point of crash the kernel will receive input from the onboard serial port? Sep 27 16:05:49 gilligan_: I don't think so -- the kernel does not take input that I know of Sep 27 16:06:45 well i was hoping I could use SysReq Sep 27 16:07:06 but i don't see how I could send that over serial Sep 27 16:11:19 cbrake, maybe i should try compiling everything with gcc-3.4 Sep 27 16:12:54 * gilligan_ slaps compulab in the face for releasing documents in MS Word format Sep 27 16:17:16 cbrake, updated armon .. that did not change anything either Sep 27 16:24:52 Crofton, still around? Sep 27 16:51:15 03cbrake 07org.oe.dev * rcc337217... 10/ (9 files in 2 dirs): mono-1.2.5.1: add new version, and remove 1.2.5 Sep 27 17:01:13 scruggs, pong Sep 27 17:03:05 just tried it on .dev and it failed with the same error about mkfs.jffs2 Sep 27 17:05:27 /who #oe Sep 27 17:06:51 hmmm, Sep 27 17:07:03 christ we have Hilda gone wild Sep 27 17:07:59 scruggs, change machine to omap5912osk and see what happens Sep 27 17:08:08 it shouldn't take too long Sep 27 17:08:17 it can reuse most of the stuff you just built Sep 27 17:08:22 will do Sep 27 17:08:27 what target are you building? Sep 27 17:08:37 angstrom-minimal-image Sep 27 17:08:50 ok Sep 27 17:11:37 scruggs, I am going start a build at home for several machine, with connex going foirst Sep 27 17:12:23 ok - I could try for verdex too as another sanity check Sep 27 17:12:42 lets see if the OSK builds Sep 27 17:12:55 its running now Sep 27 17:13:26 hopefully it turns out to be missing dependency somehow Sep 27 17:13:43 I am pretty confused by the problem Sep 27 17:13:54 haven't heard of it happening Sep 27 17:15:01 I can see where mkfs.jffs2 gets built in tmp/work/... for my host machine - its like the envirmonment/PATH is wrong somehow? Sep 27 17:15:13 do you have mkfs.jffs in tmp/staging/x86(?)/bin Sep 27 17:15:45 nope Sep 27 17:15:47 ls tmp/staging/x86_64-linux/bin Sep 27 17:19:43 cbrake: ping? Sep 27 17:24:08 Henryk: hello Sep 27 17:24:23 hi all Sep 27 17:25:10 cbrake: are you currently working on mono? cause i was just in the process of trying to make it work. (the end goal is having gtk# on the neo1973) Sep 27 17:25:35 Henryk: yes, I've been chipping away at mono in OE Sep 27 17:26:48 I have a device (with installed software) that was put together by a vendor (still under development) with openembedded and need to compile some add-ons for it. Do I need to get the developer to give me his oe configs? Sep 27 17:27:45 the docs seem to imply that I either build everything from a blank slate or have a (e.g.) zaurus and I'm not finding any in-between Sep 27 17:27:51 ewilhelm, that would be very helpful so you could reproduce tool chain and libs Sep 27 17:28:46 best to pull from the device developer's monotone then? Sep 27 17:28:53 yeah Sep 27 17:29:22 they seem a little reluctant (or at least not forthcoming) with that Sep 27 17:31:24 cbrake: ok, then I'll hurry to get my patch into shape Sep 27 17:31:31 shouldn't be too difficult to at least box-up an sdk of include files and configs though, right? Sep 27 17:31:51 * Crofton makes a note for OEDEM Sep 27 17:32:00 mental note that is Sep 27 17:32:31 just knowing the contents of distro and machine woud help, but the may also have added packages Sep 27 17:33:15 thanks Crofton, I will now attempt to navigate the political moat ;-) Sep 27 17:33:26 good luck Sep 27 17:33:31 let us know how it goes Sep 27 17:33:57 it sounds like they're a bit behind the times Sep 27 17:34:16 the dev said something about not being able to run a new busybox because it needs 2.6 and gcc 4.0.1 Sep 27 17:34:19 does the device work? Sep 27 17:34:28 roughly Sep 27 17:34:52 I'm trying to get a whole stack of perl (and extensions) onto it though Sep 27 17:35:31 Henryk: are you starting with the stuff that is already in OE? Sep 27 17:35:38 Crofton: OSK failed on mkfs.jffs2 as well Sep 27 17:36:02 what distro does the build machine run? Sep 27 17:36:10 gentoo Sep 27 17:36:19 Henryk: if you have anything at all done, I suggest we commit it as what is there is not all that great. Sep 27 17:36:21 * Crofton wonders what package builds mkfs.jffs Sep 27 17:36:31 cbrake: yes. Fixing mono-native at first, slight modification to mono, then adding gtk-sharp. and then I should look at proper packaging Sep 27 17:36:33 can you pastebin the message Sep 27 17:37:00 sure... Sep 27 17:38:25 Henryk: sounds great. Do you have any thoughts on packaging the MCS DLL's? It seems like we're going to have to get them from the native build. Sep 27 17:39:07 http://pastebin.com/m75a3f113 Sep 27 17:39:26 Henryk: unless there is some way to tell the target build to use the native tools Sep 27 17:40:18 cbrake: for the moment I haven't worked that packaging granularity worked out and am just including everything Sep 27 17:40:39 cbrake: that I got fixed I think (e.g. I can build mono depending on mono-native without mono on the build host) Sep 27 17:41:24 anyone know where mkfs.jffs2 comes from? Sep 27 17:42:54 Henryk: excellent -- send me (cbrake@bec-systems.com) your patches when ready and I'll push them into the mtn repo with your email address unless you prefer to remain anonymous Sep 27 17:43:31 [balister@hildas_laptop oe]$ ls tmp/staging/x86_64-linux/bin/mkfs.jffs* Sep 27 17:43:31 tmp/staging/x86_64-linux/bin/mkfs.jffs tmp/staging/x86_64-linux/bin/mkfs.jffs2 Sep 27 17:43:49 I have those in staging Sep 27 17:43:58 scruggs, and you do not, right? Sep 27 17:44:09 correct Sep 27 17:44:21 well bother Sep 27 17:44:21 chris@homer ~/gumstix/oe $ ls tmp/staging/x86_64-linux/bin/mkfs.jffs* Sep 27 17:44:32 ls: cannot access tmp/staging/x86_64-linux/bin/mkfs.jffs*: No such file or directory Sep 27 17:44:35 beer make homer go crazy Sep 27 17:44:46 yeah Sep 27 17:44:49 I are confused Sep 27 17:45:11 yep Sep 27 17:49:08 hehe Sep 27 17:49:53 using find in work does not find a source for mkfs Sep 27 17:50:24 I'm looking for the same... Sep 27 17:53:12 mtd-utils is where it comes from Sep 27 17:53:32 it did not find omniidl Sep 27 17:53:39 Have you installed omniorb? Sep 27 17:53:51 oops Sep 27 17:53:54 wrong channel Sep 27 17:54:56 Hmm Sep 27 17:55:08 I do have PREFERRED_VERSION_mtd-utils-native = "1.0.0" in local.conf Sep 27 17:55:18 I'm having a problem having a local packages/foo/foo.bb overriding openembedded/foo/foo.bb Sep 27 17:55:22 I can see both are being parsed Sep 27 17:55:32 (and both .bb files are for the same version) Sep 27 17:55:38 but the 1st parsed one is being used Sep 27 17:56:21 scruggs, pull that from local.conf Sep 27 17:56:58 yep - rebuilding now Sep 27 17:59:45 Anyone know how I can force my override package.bb to be used over the openembedded/ one? Sep 27 18:00:26 koen, how much does the see need to rise before you have beach front property? Sep 27 18:00:54 Crofton: about 40meters Sep 27 18:01:03 me is in a 'high' part or .nl Sep 27 18:01:18 http://flood.firetree.net/ Sep 27 18:01:48 can someone give me an approximate number of how many embedded systems are known to work with oe already? Sep 27 18:01:59 I am at around 600 meters Sep 27 18:02:07 Crofton: "enschede" Sep 27 18:02:14 ls conf/machine | wc -l Sep 27 18:02:15 Crofton: it survives the 14m :) Sep 27 18:03:19 koen: hi Sep 27 18:03:35 what surprises me is how little land does disappear ..... Sep 27 18:04:37 * koen is is in brainfreeze mode atm Sep 27 18:04:49 200km on b roads Sep 27 18:05:02 crofton oh thx Sep 27 18:05:06 Tartarus: Set the openembedded collection to have a lower priority to your local packages Sep 27 18:05:39 I think I ahve that Sep 27 18:05:46 BBFILE_COLLECTIONS = "upstream local" Sep 27 18:05:59 BBFILE_PATTERN_upstream = "^${OMDIR}/openembedded/" Sep 27 18:05:59 BBFILE_PATTERN_local = "^${OMDIR}/oe/" Sep 27 18:05:59 BBFILE_PRIORITY_upstream = "5" Sep 27 18:05:59 BBFILE_PRIORITY_local = "10" Sep 27 18:06:47 Crofton: removing that from local.conf did the trick - switching back from osk to connex to try it there Sep 27 18:08:34 Tartarus: Hmm. Try the priorities the other way :/ Sep 27 18:13:36 worked for connex too - now to see if it boots ;) Sep 27 18:17:49 wooooo Sep 27 18:18:06 voting machines declared unsafe in .nl Sep 27 18:18:39 koen: yeah, victory! Sep 27 18:19:19 yeah Sep 27 18:19:40 the downside: a few thousand voting machines (€15k each) aren't being used anymore Sep 27 18:19:45 talk about wasting money Sep 27 18:19:48 in the .nl the politics arent so stupid and ignorant and money hungry as in .de Sep 27 18:20:14 woglinde: the police forgot to tell my boss they have a new model trousers Sep 27 18:20:17 15k? i though 3k or 4k? Sep 27 18:20:42 woglinde: net result: lots of body armour needs replacement (€1000/person) Sep 27 18:21:17 koen you dont have schaeuble Sep 27 18:21:33 we have other morons :) Sep 27 18:25:26 hi bernardo Sep 27 18:53:36 cbrake: mail sent Sep 27 19:04:57 Hello all Sep 27 19:19:13 Henryk: got it -- testing now Sep 27 19:43:17 Henryk: http://pastebin.ca/717649 -- may be a AMD64 host issue or something. Debugging now. Sep 27 19:44:45 cbrake: ah, possible. I didn't try x86_64 (don't have enough disk space) Sep 27 19:48:43 Henryk: make install from devshell is running fine, hmm Sep 27 19:51:54 gcc-cross_4.2.1-r6 is not building on x86_64 for me. logs: http://www.pastebin.ca/717661 is this a bug or my OE? Sep 27 19:56:57 dcordes: 4.2.1 is working on x86_64 for me -- xscale target. What are you targetting? Sep 27 19:58:32 cbrake: I'm trying to build angstrom-2008.1 for zaurus akita (armv5te) Sep 27 20:01:29 dcordes: should be very similiar to what I'm doing then Sep 27 20:07:09 cbrake: could you take a look at the paste? a friend said there was nothing suspicious Sep 27 20:11:41 dcordes: I don't see anything offhand Sep 27 20:19:43 Henryk: mono-native is building fine now -- strange Sep 27 20:26:39 Henryk: your changes are pushed -- thanks! Sep 27 20:29:23 cbrake: thanks Sep 27 20:37:44 ~lart stelios for not paying for internet Sep 27 20:37:44 * ibot eats stelios for not paying's liver with some fava beans and a nice chianti for internet Sep 27 20:44:12 ~lart stelios for not paying for internet Sep 27 20:44:12 * ibot takes a large goose feather pillow and swings it wildly in stelios for not paying's direction, hitting stelios for not paying and sending stelios for not paying flying into the closet for internet Sep 27 20:47:51 koen: can those voting machine not form a OE beowulf build cluster? Sep 27 20:56:17 XorA|gone: methinks you'd have difficulty getting even some kind of networking going on them. that's 80ies technology. the nedap hackers couldn't even fit a whole mini chess program on them Sep 27 20:57:01 Henryk: oh their not the overblown overspecced Diebold machines of the US :-( Sep 27 20:59:43 XorA|gone: no, it's more like a 80ies era atari game console: 68000 processor, 16k of RAM, 8k EEPROM, 256k ROM Sep 27 21:14:49 03henryk 07org.oe.dev * r19712eb0... 10/ (4 files in 2 dirs): mono-native 1.2.5.1: fix up mono native compile and make mono depend on it Sep 27 21:30:38 has anyone made a rotary dialer for openmoko? Sep 27 21:31:56 nick cbrake_away Sep 27 21:33:38 crofton that would be funny Sep 27 21:33:44 yeah Sep 27 21:34:13 It would confuse a lot of people if you insisted that dailing was done by mimicing the rotary dial Sep 27 21:34:18 complete with sounds effects Sep 27 21:35:00 and don't forget to add some sound effect for coredump :p Sep 27 21:38:06 <_diego__> hi, is it possible to compile binary with debug symbol, with OE? Sep 27 21:38:33 _diego__: sure, you can control the flags globally and per package Sep 27 21:38:53 _diego__: check conf/bitbake.conf for the TARGET_ flags Sep 27 21:39:07 _diego__: and you can instruct the packaging to not strip binaries Sep 27 21:40:01 <_diego__> zecke_: thanks Sep 27 21:41:26 hmm Sep 27 21:42:24 are bitbake -i functions like poke and pastebin/pastelog going to be fixed? Sep 27 21:44:04 Darth_Wader: is there a open bug report already? do you have a patch? Sep 27 21:44:16 no x2 Sep 27 21:45:24 i don`t know python at all Sep 27 21:46:30 hmpf! MokoMakefile's make clobber does an rm -rf patches, thereby deleting my quilt patchset Sep 27 21:53:27 <_diego__> have you already noticed that www.openembedded.org site is down? Sep 27 21:57:32 lol Sep 27 22:02:11 Hmm. Somebody better install Drupal, then. ;) Sep 27 22:20:21 Henryk: sorry about that. Sep 27 22:21:37 rwhitby: luckily I have an (older) backup and all current work is either submitted or already prepared Sep 27 22:22:00 Henryk: phew! I don't feel so bad about it now. thx. Sep 27 22:22:20 rwhitby: a clean target would be cool: basically i want to be able to do a build from scratch, so remove the build/tmp and all pertaining stamps, but don't touch any of the code Sep 27 22:25:15 done Sep 27 22:25:56 Henryk: is that what you were looking for? Sep 27 22:26:12 wow, that was fast! Sep 27 22:27:00 yeah, looks great. mucho gratias Sep 27 22:28:48 hmm, maybe you'll also need to remove stamps/openmoko-devel-tools and stamps/openmoko-feed Sep 27 22:30:59 done Sep 27 22:33:57 ah that's fine. I guess I'll be building from scratch a lot more often in the futeure then Sep 28 02:15:43 Henryk: patch added and pushed -- sorry about that Sep 28 02:19:10 ah, okay Sep 28 02:33:16 03henryk 07org.oe.dev * rb2d5b9a9... 10/ (1 packages/mono/files/mono-fix-libdir-path.patch): mono-native 1.2.5.1: add needed patch libdir patch **** ENDING LOGGING AT Fri Sep 28 02:59:56 2007