**** BEGIN LOGGING AT Sun Jan 13 02:59:57 2008 Jan 13 04:58:42 03xjqian 07org.oe.dev * r69101672... 10/ (9 files in 3 dirs): Jan 13 04:58:42 roadmap: fix zroadmap, unify with roadmap-gtk2. Jan 13 04:58:42 * roadmap_path.patch: fix hard coded default config/map path Jan 13 04:58:42 * not packing zroadgps icon/desktop as it can be launched in the roadmap (>1.1.0) program Jan 13 08:55:44 Bernardo: qpegps does segfault upon start-up. I'm trying to debug why. Jan 13 09:16:23 good morning Jan 13 09:16:29 Is the OE ml down? Jan 13 09:17:25 I have not received any mail from it including a mail I sent myself Jan 13 10:49:20 whit who i can about proposing a lighting talk for fosdem ? Jan 13 11:53:55 03pfalcon 07org.oe.dev * r17d2b538... 10/ (1 packages/supertux/files/supertux.png): supertux: New desktop icon, from gp2x port by Ingo Arndt. Jan 13 11:54:04 03pfalcon 07org.oe.dev * r4210ca72... 10/ (1 packages/supertux/files/supertux.desktop): supertux: New .desktop file, from gp2x port by Ingo Arndt. Jan 13 11:54:19 03pfalcon 07org.oe.dev * r2516f4be... 10/ (1 packages/supertux/supertux_0.1.2.bb): supertux 0.1.2: Use .desktop/icon from gp2x port. Jan 13 11:54:27 03pfalcon 07org.oe.dev * rbad02fc0... 10/ (1 packages/supertux/supertux_0.1.3.bb): Jan 13 11:54:27 supertux 0.1.3: Add kinda latest version. Jan 13 11:54:27 * DEF_PREF=-1, as lacks fixed-point patch (needs rediffing). Jan 13 11:54:33 03pfalcon 07org.oe.dev * r06c65f7d... 10/ (1 packages/libsdl/libsdl-mixer_1.2.6.bb): libsdl-mixer 1.2.6: Enabled mikmod support, needed at least for supertux. Jan 13 12:03:14 03koen 07org.oe.dev * r818d6e65... 10/ (6 files in 3 dirs): (log message trimmed) Jan 13 12:03:14 ----------------------------------------------------------------- Jan 13 12:03:14 Revision: 728b58626c50e060bf71960029afce111427d6a0 Jan 13 12:03:14 Ancestor: 718d6389d03e6899ca6c6b7ff65639c21e6544bf Jan 13 12:03:14 Author: koen@openembedded.org Jan 13 12:03:15 Date: 2008-01-06T15:48:38 Jan 13 12:03:17 Branch: org.openembedded.dev Jan 13 12:35:07 03Bernhard.Guillon 07org.oe.dev * r40ab8178... 10/ (3 files in 3 dirs): Jan 13 12:35:07 linux 2.6.21: Update Simpad config, enable more wifi drivers and mmc support. Jan 13 12:35:07 * Closes #3680. Jan 13 12:39:45 hi mickeyl Jan 13 13:02:31 03pfalcon 07org.oe.dev * rc171a0d7... 10/ (1 packages/imagemagick/imagemagick-native_6.3.5-10.bb): Jan 13 13:02:31 imagemagick-native 6.3.5-10: Add native ImageMagick. Jan 13 13:02:31 * Useful for optmizing gfx resources for PDA (watch that to be Jan 13 13:02:31 used for supertux-qvga). Jan 13 13:05:11 hello, where else than ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/popt-1.7.tar.gz can i find popt-1.7 because the ftp is down Jan 13 13:05:12 IS the Oe ml down? Jan 13 13:05:34 I have not received any mail from it, including one that I sent myself about 12 hours ago Jan 13 13:08:46 GNUtoo: http://mirror.hentges.net/SonkeiSourceMirror/sorted/p/popt/ Jan 13 13:39:09 CoreDump, thanks a lot Jan 13 13:40:26 whois osas? Anybody know? Jan 13 13:40:56 np, you might wanna note that URL for future d/l problems Jan 13 13:48:07 03mickeyl 07org.oe.dev * rd6039fc8... 10/ (6 files in 3 dirs): Jan 13 13:48:07 u-boot-openmoko Jan 13 13:48:07 1.2.0: fix localversion display, rename file for simplicity Jan 13 13:48:07 1.3.1: add new snapshot with ombug799 patch, upstream does not build atm. Jan 13 14:19:07 hello, i have svn: Unable to find repository location for 'svn://svn.openpma.org/svn/openpma/trunk/src/linux-pma' in revision 1 but svn co svn://svn.openpma.org/svn/openpma/trunk/src/linux-pma works Jan 13 14:19:25 the command is : NOTE: Fetch svn://svn.openpma.org/svn/openpma/trunk/src/;proto=svn;module=linux-pma Jan 13 14:21:27 if you use svn packages with floating revision, you have to specify the revision Jan 13 14:21:35 i recommend doing this in conf/include/sane-srcrevs.inc Jan 13 14:21:39 take a look there Jan 13 14:21:47 thanks Jan 13 14:22:03 or so the autorev thing in local.conf ... Jan 13 14:22:17 for cases like me wanting to build current git kernels .... Jan 13 14:22:32 * Crofton needs to write a FAQ entry on this ... Jan 13 14:22:57 how can i tell to always use the lastest rev? Jan 13 14:23:11 GNUtoo, hang on Jan 13 14:23:30 SRCREV_pn-linux-davinci ?= ${AUTOREV} Jan 13 14:23:36 I have that in my local.conf Jan 13 14:23:46 ya Jan 13 14:23:50 have a look at moko-autorev.inc Jan 13 14:23:50 thanks a lot Jan 13 14:23:52 to build latest rev of linux-davinci Jan 13 14:24:29 if you put AUTOREV in the global file, everytime you parse bb must check the current rev over the network Jan 13 14:24:36 and build fails if hte server is down Jan 13 14:24:43 which really annoys people Jan 13 14:24:59 so bb defaults to the earliest rev Jan 13 14:25:27 which probably is not want you want ... Jan 13 14:25:54 no Jan 13 14:26:17 basically putting AUTOREV in sane srcdates drives people crazy at times ") Jan 13 14:26:29 like when berlios goes down and no one can build Jan 13 14:27:22 I think I have this right now, finally :) Jan 13 14:27:45 03mickeyl 07org.oe.dev * ra187890b... 10/ (8 files in 2 dirs): python-efl cvs add missing RDEPENDS to python-lang Jan 13 14:28:31 03mickeyl 07org.oe.dev * red94d352... 10/ (3 files in 3 dirs): python 2.5.1 remove bogus RPROVIDE for python-curses, RRECOMMEND python-readline Jan 13 14:29:29 and how do i put an external toolchain only to build the kernel? Jan 13 14:29:48 not sure about that ... Jan 13 14:31:13 is there a 'how to' for adding a package to a distro ? Jan 13 14:32:26 interfaith, what do you mean by adding a package? compiling a package that is already in oe? or making a bb file? Jan 13 14:33:00 there is no bb file for zaptel a part of asterisk Jan 13 14:33:22 gm Jan 13 14:33:29 interfaith, http://bitbake.berlios.de/manual/ Jan 13 14:33:43 y Jan 13 14:34:52 slugos builds perfectly , but angstrom is all messed up Jan 13 14:35:02 must it be re-installed ? Jan 13 14:36:31 what file lists all packages in a distro ?, snmp for example Jan 13 14:37:05 there may be a manual for modifying a distro as well ? Jan 13 14:38:44 i guess each bb files serves as an example Jan 13 14:38:45 the distro does not define what packages are built Jan 13 14:38:55 the images define the packages that get built Jan 13 14:39:15 snmp for example , how is that included or not Jan 13 14:39:52 so some image bb file must include snmp ? Jan 13 14:40:37 yes Jan 13 14:40:45 or you can build it and install it later Jan 13 14:40:48 i will try to do zaptel now Jan 13 14:41:14 thx Jan 13 14:49:10 if the module is proprietary...it will use the special kernel interface for it...does the kernel realy need to be compiled with the same gcc it was compiled with Jan 13 14:49:46 I cannot parse the metadata anymore: ERROR: /home/leon/sandbox/ixp4xx/openembedded/org.openembedded.dev/packages/dtnrg/dtn_2.5.0.bb:40: unparsed line: 'export BUILD_SYS' while parsing /home/leon/sandbox/ixp4xx/openembedded/org.openembedded.dev/packages/dtnrg/dtn_2.5.0.bb Jan 13 14:53:06 which bitbake ? Jan 13 14:58:21 anyone? Jan 13 15:00:48 osas: http://www.openembedded.org/wiki/UpgradingPackages Jan 13 15:01:04 Laibsch: thx Jan 13 15:01:12 checking it now Jan 13 15:01:15 np Jan 13 15:01:20 does that answer your question? Jan 13 15:01:26 If not, it is a wiki ;-) Jan 13 15:01:47 yup Jan 13 15:01:48 k Jan 13 15:03:06 BTW, "mtn mv" is sufficient with recent mtn Jan 13 15:03:13 -e is not necessary anymore Jan 13 15:03:45 k Jan 13 15:04:07 hmm, bummer this syntax is only in bitbake 1.8.9 Jan 13 15:05:23 mickeyl: yep, I am using 1.8.8 Jan 13 15:10:10 CoreDump: Why don't we receive any more news of things happening in the bug tracker? Jan 13 15:10:44 why would I know? Jan 13 15:11:04 I thought the code was from you Jan 13 15:11:06 No? Jan 13 15:11:28 flo_lap: Are you ever going to take care of Jan 13 15:11:32 !oebug 1356 Jan 13 15:11:34 * * Bug 1356, Status: NEW, Created: 2006-08-24 06:57 Jan 13 15:11:35 * * hma(AT)syd.odn.ne.jp: new ja.po files are ready for some gpe-* packages Jan 13 15:11:36 * * http://bugs.openembedded.org/show_bug.cgi?id=1356 Jan 13 15:11:47 * Laibsch suspects some serious bitrot by now Jan 13 15:11:51 It is a shame Jan 13 15:12:54 BTW, OE mailing list seems to be sending out mails again Jan 13 15:13:17 flo_lap, CoreDump: Are the old mails going to arrive eventually? Jan 13 15:13:26 * Laibsch hopes they have not gone to bit-heaven Jan 13 15:13:30 Laibsch: this was put in the "wrong" bug tracker :} Jan 13 15:13:49 well, maybe Jan 13 15:13:59 But the right people were made aware of it Jan 13 15:14:10 And at the time, it might even have been the right one Jan 13 15:14:19 the ML thing is a topic for #ltg if the ML is hosted there Jan 13 15:14:20 or even worse, the right one might have been hh.org Jan 13 15:14:48 CoreDump: both. ltg, of course, but the ml is an OE thing. So, on-topic here. Jan 13 15:15:18 Laibsch: right Jan 13 15:17:33 does someone knows how to build the kenrel with an external gcc? Jan 13 15:17:46 and having the rest of the system with oe's gcc Jan 13 15:20:29 zecke: just received an interesting comment on Jan 13 15:20:33 !oebug 3650 Jan 13 15:20:34 * * Bug 3650, Status: NEW, Created: 2008-01-08 16:13 Jan 13 15:20:35 * * : uicmoc4-native fails do_compile Jan 13 15:20:36 * * http://bugs.openembedded.org/show_bug.cgi?id=3650 Jan 13 15:20:38 Care to take a look? Jan 13 15:21:45 when will hwr be back? Jan 13 15:22:02 s/hwr/hrw Jan 13 15:23:04 Laibsch: patch looks fine, BUT if zlib-native got built, where was it put and where did uicmoc4-native look for these files Jan 13 15:24:30 zecke: Do you want to investigate or just use the patch if it works? Jan 13 15:25:02 uicmoc4-native probably look at host includes Jan 13 15:25:24 as is suggested by the successful compilation on a machine with zlib1g-dev installed Jan 13 15:26:51 Laibsch: I don't take this patch, it is hiding an error instead of fixing it Jan 13 15:26:56 does anyone participated to openzaurus with a 2.4 kernel? Jan 13 15:28:17 Laibsch: I have added my questions to the bug tracker Jan 13 15:28:30 anyone knows what means empty string in http://toh.openwrt.org/, column "Status" ? Jan 13 15:29:31 zecke: thank you. I will answer them there. IIRC I had even rebuilt zlib-native. 2nd question I am not sure and will have to check later. Jan 13 15:29:46 zecke: Can I add you to cc for 3650? Jan 13 15:30:13 Laibsch: I think I just added myself Jan 13 15:30:30 OK Jan 13 15:30:36 great Jan 13 15:43:30 Is there a possibility to add "Poodle" as a option in the "Component" pull-down box (e.g. see: http://bugs.openembedded.org/show_bug.cgi?id=3686) Jan 13 15:46:37 Helge: There you go Jan 13 15:46:50 Laibsch: Just saw it :-) Thanks! Jan 13 15:49:13 ggilbert: Can you please check that the bug tracker actually sends mail to oe-issues@ltg? Jan 13 15:55:09 likewise: just committing a fix for that. sorry Jan 13 15:55:27 mickeyl: thanks and no problem Jan 13 15:55:44 is the fortran issue resolved? otherwise I would take a look now Jan 13 15:56:33 zecke: not that I know. Jan 13 16:08:46 zecke, Laibsch: I'm the author of zlib-native patch Jan 13 16:08:59 starox: hi :) Jan 13 16:09:03 hi :) Jan 13 16:09:15 It's seems uicmoc have it's own zlib source Jan 13 16:09:17 starox: the one removing zlib-native from uicmoc4-native? Jan 13 16:09:20 yes Jan 13 16:09:53 starox: yes it does, no I don't want to use it. If we built a zlib-native and link against -lz we should find one Jan 13 16:10:12 starox: and if we don't find one we miss one -L to the right staging libdir Jan 13 16:10:14 I tested on an ubuntu system without zlib1g-dev and do a bitbake -c clean zlib-native before compiling uicmoc4-native to test Jan 13 16:10:45 zecke: I understand ! I was lazy to make a patch againt uicmoc4 sources :) Jan 13 16:11:08 But if you wan't I'll make it. Jan 13 16:11:19 starox: answer the two questions and we will see what to do. Jan 13 16:12:15 starox: I don't think we need to change the qt sourcecode, it is a matter of passing another -L to the configure script (If I judge this right) Jan 13 16:12:22 zecke: which question ? Jan 13 16:12:38 zecke: You're right for the -L. Jan 13 16:12:52 starox: in the bug tracker Jan 13 16:13:26 starox: did zlib-native get built? do you have a libz.* in your staging libdir? and what is the link line of uic/moc? Jan 13 16:16:30 zecke, hello, do you know how to build a kernel with an external toolchain and the rest with oe's toolchain? Jan 13 16:16:37 1)no 2)I didn't look at 3)I don't know ... so I'll restart a clean build and answers seriously to these question. and then go ahead with a zlib-native build Jan 13 16:18:13 GNUtoo: not really, there is something like a KERNEL CC SUFFIX (don't remember the name, grep packages/linux) Jan 13 16:20:39 zecke, thanks a lot it was KERNEL_CCSUFFIX = "-3.3.4" but what if the gcc(2.95)is not in the repo of oe Jan 13 16:21:23 GNUtoo: this is where I don't have a straight forward idea Jan 13 16:21:56 GNUtoo: set it to 2.95, then you can set a PREFERRED_PROVIDER for your external toolchain (kernel-gcc-2.95 or such) Jan 13 16:22:07 ok thanks a lot Jan 13 16:22:11 GNUtoo: and if your gcc is in the path and named proper-name-2.95 it should get called Jan 13 16:22:29 GNUtoo: but I have not done this before, so you need to grep a bit :) Jan 13 16:22:36 ok Jan 13 16:29:51 Jin^eLD: let me guess, you still don't have an answer on the devicetables issue? Jan 13 16:32:14 zecke: correct :) well, likewise answered with some thoughts Jan 13 16:32:30 I also added some additional thoughts of mine to the PR Jan 13 16:32:34 but so far noone really picked it up Jan 13 16:32:52 hi btw :) Jan 13 16:33:12 hey guys Jan 13 16:33:15 we hit the 5000 mark! Jan 13 16:33:20 (bbfiles, that is) Jan 13 16:33:33 wow Jan 13 16:33:42 that counts for a blog post about the status of OM Jan 13 16:33:45 oops Jan 13 16:33:46 OE even Jan 13 16:36:59 btw, who is in charge of the task-nas, or - who knows more about it? Jan 13 16:37:10 sounds like rwhitby Jan 13 16:37:30 rwhitby: ping Jan 13 16:38:47 rwhitby is in .au timezone Jan 13 16:38:59 uuuh, ok Jan 13 16:39:00 thanks Jan 13 16:39:32 mickeyl: btw, aren't you located in the china/hk/tw area? Jan 13 16:40:27 only rarely. usually i'm in .de Jan 13 16:40:40 oh, I guess I confuse you with someone else Jan 13 16:40:51 trying to get some info on the Loongson based notebooks :) Jan 13 16:42:28 zecke? timed out or got my message? Jan 13 16:47:43 Jin^eLD, device table issue? Jan 13 16:48:14 HopsNBarley: yes, initscripts installs its own Jan 13 16:48:17 Jin^eLD: timedout :) Jan 13 16:48:30 Jin^eLD: I start to doubt that the crashes of my cellphone are a co-incidence Jan 13 16:48:48 zecke_: I was saying that likewise did answer with an idea of his own and I also threw in a few thoughts, but noone really picked up the issue Jan 13 16:48:49 what distro? Jan 13 16:49:27 HopsNBarley: based on Angstrom but I think it's a generic problem that lies with what the initscripts package si doing Jan 13 16:49:33 Jin^eLD: If I understood it right we have two places with device tables? One for image creation and one in basefile? Jan 13 16:49:33 not package, .bb file rather Jan 13 16:50:07 zecke_: yes, there is one device table that comes with initscripts and it gets processed by the devices script at startup Jan 13 16:50:16 ultimately overwriting the existing devtable entries Jan 13 16:50:31 the devices script however checks if udev or devfs are present and does nothing in that case Jan 13 16:50:36 and most ppl probably use udev Jan 13 16:50:41 I noticed this problem with a static dev Jan 13 16:50:43 i'm more familiar with the stuff done at image creation time. Jan 13 16:50:56 Jin^eLD: the solution is simple, isn't it? have only one table :) Jan 13 16:51:06 zecke_: for uicmoc4-native, I'm scared to add an -L for zlib because the recepe explicitely unset LFLAGS. Jan 13 16:51:16 Jin^eLD: I think I would tweak FILESDIR of inittables Jan 13 16:51:28 zecke_: yes, but I have no idea on how to let initscripts.bb know about the global devtable file Jan 13 16:51:46 starox: add some data to the bug report, the dirname where libz.* is and the link line of of qt that is failing Jan 13 16:51:47 http://bugs.openembedded.org/show_bug.cgi?id=3593 Jan 13 16:51:51 that's the PR btw Jan 13 16:52:12 i'd forget about creating them at boot time, and put them in your image then. is tmp/rootfs/dev correct? Jan 13 16:52:44 HopsNBarley: at boot creation is cool for nfsroot Jan 13 16:53:05 ah yes -for a ro root. Jan 13 16:53:39 HopsNBarley: well, that's what I wanted but I noticed that the dev table that was seen when the system was up looked completely different from the one that I specified in the machine.conf Jan 13 16:53:49 and found out that initscripts was placing in its own stuff Jan 13 16:57:39 Jin^eLD, i see your point. it seems the SRC_URI in initscripts should += ${IMAGE_DEVICE_TABLES}, or something like that, rather than blindly include device_table.txt Jan 13 16:57:48 exactly Jan 13 16:58:05 but I have no idea on how to do that in a clean way Jan 13 16:58:18 locally I just hacked in ../../../files/mydevtable.txt Jan 13 16:58:27 in the SRC_URI which of course is not a nice solution Jan 13 16:59:01 probably need a spat of python code there to conditionally do that operation? Jan 13 16:59:08 just guessing. Jan 13 16:59:19 separately, i just saw something wierd. Jan 13 16:59:20 could be, that kind of goes a little beyond my OE knowledge Jan 13 16:59:31 HopsNBarley: yes, that is what I meant with FILESDIR ;) Jan 13 16:59:55 zecke_: show us the way =) Jan 13 17:00:21 from the early december tree, i'd get libvolume-id0 in my image, now, libvolume-id-dev gets pulled in. any ideas? Jan 13 17:01:03 Jin^eLD: check FILESPATH and FILESDIR of your bitbake.conf Jan 13 17:01:23 Jin^eLD: this is used to find relative paths e.g. SRC_URI += "foo.patch;patch=1" Jan 13 17:01:25 zecke_: job's done :) Jan 13 17:02:00 Jin^eLD: so in theory, if ou get the base path to the image device tables into the FILESDIR, you are done Jan 13 17:02:00 zecke_: aaaah! ok now I get your point Jan 13 17:02:00 starox: thanks Jan 13 17:02:24 zecke_: thanks, I will try that Jan 13 17:02:32 zecke_, thanks. but how will it conditionally still use the default? Jan 13 17:03:36 HopsNBarley: which default? Jan 13 17:04:03 You made a wonderfull job with bitbake & oe. Thank you guys :) Jan 13 17:04:12 the default device_table.txt (i think i' Jan 13 17:04:13 * starox got a trauma from buildroot before ... Jan 13 17:04:20 i'm being dense here... (-; Jan 13 17:04:26 HopsNBarley: we might want to apply the standard technique and put the devtables to the MACHINE/ dir Jan 13 17:04:39 zecke_, ah, that is making sense then. Jan 13 17:04:49 HopsNBarley: yeah, and you made sense as well :) Jan 13 17:07:05 any idea on this libvolume thing i'm seeing? Jan 13 17:09:16 here's a diff of the ipkg/status file: -Package: libvolume-id0 Jan 13 17:09:16 +Package: libvolume-id-dev Jan 13 17:09:48 HopsNBarley: do you only have one libvolumne-id-dev package? why is it putting libvolume into the image? Jan 13 17:12:47 udev-115 is depending on libvolume Jan 13 17:13:15 HopsNBarley: okay, which libvolume file gets put into the image? Check which package is providing that Jan 13 17:13:24 i should say, in the former, depending on libvolume-id0, and in the latter, libvolume-id-dev Jan 13 17:13:28 HopsNBarley: check if udev ipkg depends on libvolume? Jan 13 17:13:30 zecke_, okay, checking. Jan 13 17:26:32 zecke_, in the ipkg/status file, libvolume-id-dev is listed as a dependency, but i'm not sure why Jan 13 17:33:02 hello, i have NOTE: Handling BitBake files: - (4990/4991) [99 %]ERROR: Could not include required file gcc-cross-initial_4.1.2.bb while parsing /oe/packages/gcc/gcc-cross-kernel-2.95_4.1.2.bb but the file gcc-cross-initial_4.1.2.bb exists... Jan 13 17:39:10 do they theses files have to be in the same folder? Jan 13 17:42:46 sure Jan 13 17:52:09 zecke, i think your phone saw me coming (-; Jan 13 17:52:56 yes, udev is depending on libvolume-id-dev (i checked both ipkg/status files and the .ipk file directly) - but i'm not sure why this is. Jan 13 17:53:37 is this dependency generated automatically at package construction time? Jan 13 18:01:53 HopsNBarley: it is automatically generated Jan 13 18:02:02 HopsNBarley: use objdump -x and check SO_NEEDED of it Jan 13 18:02:28 HopsNBarley: find the library name for libvolume, and then grep the shlibs dir in tmp/ and see who is 'providing' that Jan 13 18:04:52 zecke, thanks. Jan 13 18:06:48 HopsNBarley: and if you know that, just rebuild libvolumeid and see if the file changes (heisenbug) Jan 13 18:07:44 zecke, ...lib/udev/vol_id requires libvolume_id.so.0 Jan 13 18:10:51 huh, both libvolume-id-dev and libvolume are providing this, if i am understanding.libvolume-id-dev.list:libvolume_id.so.0 Jan 13 18:10:59 libvolume-id.list:libvolume_id.so.0 Jan 13 18:11:14 let me check the packages.... Jan 13 18:11:31 HopsNBarley: rebuild libvolume-id (this is why I say heisenbug) Jan 13 18:13:23 okay. Jan 13 18:14:54 zecke, thanks for the shlibs pointer -that helps me to understand something new (-; Jan 13 18:16:38 both still "provide" it. but the -dev package only contains a link ./usr/lib/libvolume_id.so -> /lib/libvolume_id.so.0.80.0 Jan 13 18:17:06 HopsNBarley: the link sounds correct Jan 13 18:17:21 BBL, need to get food Jan 13 18:32:28 how can i prevent optimisations only for building the kernel(with special gcc) i already tried to set FULL_OPTIMIZATION="" in the kernel bb file but it didn't work and still use -mapcs-32 and -mshort-load-bytes Jan 13 18:38:01 -mapcs-32 and -mshort-load-bytes are not optimisation. Jan 13 18:38:40 Those options are set by the kernel's own makefiles and are required for correct code generation with some versions of gcc. Jan 13 18:38:51 (With recent versions of gcc both of those are the default anyway, so there is no benefit in removing them.) Jan 13 18:49:13 pb_, but my old gcc doesn't recognise them... Jan 13 18:50:56 What version of gcc are you trying to use? Jan 13 18:51:26 If it's so old as to not understand -mapcs-32 then it probably can't compile a modern kernel anyway. Jan 13 18:52:38 pb_, 2.95 Jan 13 18:54:23 that's odd, I am almost certain that 2.95 did support those options Jan 13 18:54:33 what target triplet are you using? Jan 13 18:55:25 target triplet? Jan 13 18:55:28 what is that? Jan 13 18:55:46 the string you pass as "--target=..." on the configure command line Jan 13 18:56:25 when building your compiler, that is Jan 13 18:57:03 i used a pre-built toolchain but the strange thing is that i was able to build the kernel out of oe Jan 13 18:57:18 here's my log file: http://pastebin.com/meba1c7a Jan 13 18:59:35 that is strange Jan 13 19:00:33 pb_, mabe it's picking the wrong compiler... Jan 13 19:01:46 pb_, is it the right way to setup the compiler? PREFERRED_PROVIDERS += "virtual/${TARGET_PREFIX}gcc-2.95:gcc-cross-kernel" Jan 13 19:01:51 mm. well, certainly does look like your gcc indeed doesn't understand those options. Jan 13 19:01:57 maybe this is some special omap version of gcc. Jan 13 19:02:19 if you're sure that you don't need those flags then I guess you can just patch the kernel makefile to take them out. Jan 13 19:02:26 pb_, how do i setup an external kernel compiler? i've already tried but without sucess Jan 13 19:04:04 mickeyl can probably answer that question better than me Jan 13 19:04:32 * pb_ dinner time now Jan 13 19:05:31 mickeyl, hello i don't know how to setup an external kernel compiler...how do i do that...i have already tried grep but no project has a 2 different compilers... and i've tried without sucess random variables... Jan 13 19:06:23 GNUtoo: i can only recommend looking at conf/distro/sharprom-compatible.conf. This is the only occasion I have worked with an external toolchain Jan 13 19:06:45 mickeyl, yes but the problem is that the toolchain is for evrything not just the kernel Jan 13 19:27:58 mickeyl, isn't there some old configuration of zaurus when it was stuck with a 2.4 kernel because of the sd card driver(so compiling it with a specific gcc version was needed) Jan 13 19:41:33 hrw|gone, ping Jan 13 19:44:00 flo_lap, do you know how to use an external toolchain but only for the kernel? Jan 13 19:45:04 GNUtoo: not offhand, but that's possible Jan 13 19:45:26 flo_lap, how? Jan 13 19:45:38 ah ok Jan 13 19:45:54 GNUtoo: iirc it was used in kernel 2.4 recipes for some zaurus models auch as collie Jan 13 19:46:20 flo_lap, where can i find theses files? Jan 13 19:46:32 flo_lap, i think they are not anymore in the repo? Jan 13 19:52:41 GNUtoo: you can try to download OE from a couple of years ago Jan 13 19:52:54 but honestly, i'd rather see that issue being fixed Jan 13 19:53:44 03mickeyl 07org.oe.dev * r63ae1f48... 10/ (1 packages/efl1/edbus_cvs.bb): edbus cvs catch up with upstream source moving, increase package granularity Jan 13 19:53:57 03mickeyl 07org.oe.dev * rb51d4243... 10/ (3 files in 3 dirs): add python-edbus, BROKEN though until someone adds dbus 1.1.x Jan 13 19:54:06 03mickeyl 07org.oe.dev * r9d3729da... 10/ (8 files in 3 dirs): python-efl cvs ship examples, add python-efl-examples as meta package Jan 13 19:54:15 03mickeyl 07org.oe.dev * re2b3f504... 10/ (1 packages/dtnrg/dtn_2.5.0.bb): dtn 2.5.0 use syntax compatible w/ bitbake 1.8.8 for now Jan 13 19:54:24 03mickeyl 07org.oe.dev * r24916a17... 10/ (1 packages/python/python_2.5.1.bb): python 2.5.1 fix RRECOMMEND_S_ typo Jan 13 19:54:30 03mickeyl 07org.oe.dev * r37503acf... 10/ (1 packages/python/python-2.5-manifest.inc): python-2.5-manifest: regenerate Jan 13 19:54:39 03mickeyl 07org.oe.dev * r51afccca... 10/ (4 files in 3 dirs): ecore cvs package new libraries libecore_imf and liecore_imf_evas. bump edje-viewer Jan 13 19:54:46 03freyther 07org.oe.dev * r99e95c6a... 10/ (1 contrib/mtn2git/mtn2git.py): Jan 13 19:54:46 * Import revisions without a parent properly! The diffing would have been all right but Jan 13 19:54:46 we have not diffed the two manifests at all. Now we are diffinf an empty manifest against Jan 13 19:54:46 the initial one. Jan 13 19:54:53 03freyther 07org.oe.dev * r99d10c43... 10/ (1 contrib/mtn2git/mtn2git.py): Jan 13 19:54:53 * Incrementally updating the former heads did not work right. Sometimes we have Jan 13 19:54:53 saved bogus data and it could be dangerous. Jan 13 19:54:55 * Back-out this change and save the heads at the end of the script. Jan 13 19:55:02 03mickeyl 07org.oe.dev * r9b6e07a7... 10/ (1 conf/distro/include/sane-srcrevs.inc): sane-srcrevs.inc: add python-gsmd Jan 13 19:55:08 03mickeyl 07org.oe.dev * r16808146... 10/ (4 files in 3 dirs): Jan 13 19:55:08 edje-viewer cvs hack minimal pane size to make it work on small displays Jan 13 19:55:08 patch by Thomas Gstaedtner Jan 13 20:12:47 in order to get an old oe i should get an older database that's all? Jan 13 20:15:12 check out an older version using mtn Jan 13 20:15:58 either way, sometimes stuff uses HEAD of cvs/svn/git/... repos and older versions won't work Jan 13 20:16:13 some lirc stuff did, but I think that's fixed Jan 13 20:57:20 by the way i didn't understand what was theses weak asignements ?= Jan 13 21:02:25 Jin^eLD: looking for task-nas-server info? Jan 13 21:03:14 yes! Jan 13 21:03:16 :) Jan 13 21:03:33 rwhitby: what exactly is it, how is it added to the image? Jan 13 21:03:42 or rather - how can I build a NAS image Jan 13 21:03:59 and also - a suggestion - to add an optional UPnP server :> Jan 13 21:04:37 Jin^eLD: you're welcome to add any more applications to it in the same manner as the existing ones. Jan 13 21:04:58 as for how to build an image, just use nas-server-image.bb Jan 13 21:05:12 aah, so I just missed the image Jan 13 21:05:35 well, the suggestion regarding the server was more - for the default image Jan 13 21:06:05 right - you're welcome to add it to task-nas-server.bb, which will cause it to be part of the default image Jan 13 21:06:06 or a variable like it is the case with the ssh daemon selection Jan 13 21:06:25 I meant default in the distribution :) Jan 13 21:06:29 there is no upnp server in there at the moment, so your choice gets to be the default Jan 13 21:06:30 like, in OE Jan 13 21:06:46 OE has no defaults - distros have defaults. Jan 13 21:06:55 (or images) Jan 13 21:07:00 mhm indeed :) Jan 13 21:07:07 seems I got it all wrong from start to end today hehe Jan 13 21:08:01 so add a task-nas-server-upnp section to task-nas-server.bb, hook it in like all the other sections, and put your favourite tested server in that section. Jan 13 21:08:45 and then submit a patch or something? Jan 13 21:11:11 yep - add a patch to an enhancement bug in the bugtracker, and let me know the bug number. Jan 13 21:11:34 ok, thanks Jan 13 21:35:24 by the way tzdata2007e.tar.gz fails...i change the repo Jan 13 22:07:57 hello, what could be the reason of such parse faillure? http://pastebin.com/mb5139f4 Jan 13 22:22:01 mabe i understand the problem... Jan 13 22:22:08 morning all Jan 13 22:22:57 hey RP Jan 13 23:56:01 03mickeyl 07org.oe.dev * racf13b17... 10/ (1 packages/u-boot/u-boot-openmoko_svn.bb): u-boot svn remove obsolete EABI hacking Jan 13 23:56:06 03mickeyl 07org.oe.dev * rb61b7944... 10/ (7 files in 2 dirs): python-efl cvs generate .edj files and ship 'em Jan 13 23:56:11 03mickeyl 07org.oe.dev * rd100eb58... 10/ (3 files in 3 dirs): edje-viewer cvs improve no-minimal-size patch so that it actually is half way usable on a handheld Jan 14 00:31:34 web site database is down... Jan 14 00:34:02 03mickeyl 07org.oe.dev * r717efc0f... 10/ (1 packages/efl1/evas.inc packages/efl1/evas_cvs.bb): evas cvs RRECOMMEND also x11-16 bit engine Jan 14 00:34:08 03mickeyl 07org.oe.dev * rd2e9376e... 10/ (1 packages/dtnrg/dtn_2.5.0.bb): dtn 2.5.0 python-dtn RDEPEND dtn Jan 14 00:34:13 03mickeyl 07org.oe.dev * re4f83871... 10/ (1 conf/distro/include/sane-srcrevs.inc): sane-srcrevs: bump openmoko-terminal2 Jan 14 00:35:14 try again Jan 14 00:35:23 we have problem w/ ltg today Jan 14 00:37:25 hey mickeyl - thanks. Jan 14 00:45:29 'night all Jan 14 00:51:40 g'night RP Jan 14 02:45:04 * * OE Bug 3691 has been created by  Jan 14 02:45:06 * * test bug Jan 14 02:45:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3691 Jan 14 02:47:05 * * OE Bug 3691 has been RESOLVED (INVALID) by Jan 14 02:47:07 * *  test bug Jan 14 02:47:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3691 Jan 14 02:48:49 this officially unb0rks the oe-issues ML **** ENDING LOGGING AT Mon Jan 14 02:59:56 2008