**** BEGIN LOGGING AT Tue Mar 04 10:59:57 2008 Mar 04 11:00:48 zecke: I still don't see the point in a recipe building gcc for external toolchain should look at anything (libc headers) from an external toolchain. Mar 04 11:01:13 it should use the the libc headers from the libc version that it is going to be bundled with. Mar 04 11:01:22 pb_: maybe WM8978 or similar Mar 04 11:01:42 if the /usr/local/angstrom libc version is different from the one that I am building for, I risk having a borken toolchain generated :-( Mar 04 11:02:05 it is not just plain wrong, it is potentially bad :-) Mar 04 11:02:10 esben: it is no use of arguing. You might have more than -isystem in your command line, I have no idea Mar 04 11:02:53 esben: I have no idea who is putting that into the command line, I assume gcc, you say it is the recipe, there are not many places where -isystem is used, conf/bitbake.conf and probably in gcc Mar 04 11:03:19 esben: so instead of arguing, why not fix it? Mar 04 11:03:21 I don't think I should have to argue a lot. We should not be pulling in headers from other directories than those that we know we should be using. Mar 04 11:03:34 zecke: it is being put in by gcc_4.1.2.bb Mar 04 11:04:01 which unfortunately is being derived from by gcc-cross-sdk_4.1.2.bb, which is the real cause of the problem Mar 04 11:04:45 and the fix is therefore a restructuring of gcc recipes to avoid this. Mar 04 11:05:03 esben: where? ARCH_FLAGS_FOR_TARGET=-isystem${STAGING_INCDIR} is the only isystem i see Mar 04 11:05:59 pb_: WM8957 is DAC only Mar 04 11:06:05 * * OE Bug 3930 has been created by eha(AT)doredevelopment.dk Mar 04 11:06:07 * * Typo fix for abiword-plugins STAGING_INCDIR Mar 04 11:06:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3930 Mar 04 11:07:11 zecke: can STAGING_INCDIR end up being defined relative to /usr/local/angstrom ? Mar 04 11:07:37 esben: well, you said it is putting /usr/local/angstrom in it, where is my question? Mar 04 11:07:48 lrg: I can't see WM8957 on your website. Is that a new product? Mar 04 11:07:53 esben: so in which line is that happening? Mar 04 11:08:09 lrg: 8986 sounds like roughly what we need though Mar 04 11:08:26 building gcc-cross-initial Mar 04 11:09:29 in which line the include files are not found? Mar 04 11:09:37 or where the -isystem is set? Mar 04 11:09:49 pb_: probably best go for the latter Mar 04 11:09:57 12:03 < esben> zecke: it is being put in by gcc_4.1.2.bb Mar 04 11:10:08 esben: ??? which line number is my question Mar 04 11:11:11 zecke: I were assuming it were in the ARCH_FLAGS_FOR_TARGET, but I see know that is not true. Mar 04 11:11:22 I am trying to find where it comes from.... Mar 04 11:11:47 esben: you can use bitbake -e -b file and see what STAGING_INC_DIR is, it might be different due sysroot stuff and be /usr/local/... Mar 04 11:13:20 the meta data I am looking at should be pre-sysroot... Mar 04 11:13:30 it's openmoko stable branch Mar 04 11:17:21 *sigh* Mar 04 11:17:59 /home/esben/moko/build/tmp/work/i686-armv4t-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.1.2-r11/gcc-4.1.2/build.i686-linux.arm-angstrom-linux-gnueabi/./gcc/xgcc -B/home/esben/moko/build/tmp/work/i686-armv4t-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.1.2-r11/gcc-4.1.2/build.i686-linux.arm-angstrom-linux-gnueabi/./gcc/ -B/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/bin/ -B/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/lib/ -isystem /usr/local/angstrom/arm Mar 04 11:17:59 /arm-angstrom-linux-gnueabi/include -isystem /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/sys-include -O2 -g -Os -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/home/esben/moko/build/tmp/work/i686-armv4t-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.1.2-r11/gcc-4.1.2/gcc -I/home/esben/moko/build/tmp/work/i686-armv4t-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.1. Mar 04 11:18:00 2-r11/gcc-4.1.2/gcc/. -I/home/esben/moko/build/tmp/work/i686-armv4t-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.1.2-r11/gcc-4.1.2/gcc/../include -I/home/esben/moko/build/tmp/work/i686-armv4t-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.1.2-r11/gcc-4.1.2/gcc/../libcpp/include -I/home/esben/moko/build/tmp/staging/i686-linux/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time Mar 04 11:18:14 pulling in both i686 and arm includes at the same time :-( Mar 04 11:27:10 * rschuster is fighting with a package to get it cross-compiled ... Mar 04 11:27:49 it looks to me as we should do a basic "how do I properly develop a package so that it does not cause major headache when it is cross-compiled"-workshop at linuxtag ... Mar 04 11:27:52 * zecke is cheering Mar 04 11:28:07 targeted at upstream developers ... Mar 04 11:28:09 rschuster: I gave a lightning-rant about this at last years fosdem Mar 04 11:28:35 rschuster: use the most complicated handwritten buildsystem, brainfuck is too obvious :) Mar 04 11:29:07 Morning Mar 04 11:29:22 hand-written stuff is really the greatest of all ... Mar 04 11:29:27 thesing: morning? it is almost 20h :) Mar 04 11:29:58 but also autotools stuff that is bend and stretched to compile under various versions of MSVC .... Mar 04 11:30:16 ;) Mar 04 11:30:53 sometimes I end up rewriting larger parts configure.in/.ac ... Mar 04 11:31:24 but I think everyone at OE does this? Mar 04 11:33:23 rschuster: I mostly abuse it, I'm so thankful woglinde sanitized zlib Mar 04 11:33:41 hmm, I should create my own zlib Mar 04 11:46:08 rschuster: I think we've all ended up there before... Mar 04 11:47:07 Laibsch: Perl builds with sharprom-compatible after my changes. Do you mind if I unbreak sharprom a bit though? (virtual/linux-libc-headers does not exist) Mar 04 11:58:56 Not at all Mar 04 11:59:03 I'd appreciate it Mar 04 11:59:40 My recollection is fuzzy, but I think the linux-libc-headers changes were made on hrw's suggestion Mar 04 12:00:01 They are as of now unfinished, half-baked Mar 04 12:00:42 RP: The reason for the changes was Mar 04 12:00:46 !oebug 3772 Mar 04 12:00:47 * * Bug 3772, Status: NEW, Created: 2008-02-13 17:00 Mar 04 12:00:48 * * : SharpROM sometimes compiles glibc which it shouldn't really do Mar 04 12:00:49 * * http://bugs.openembedded.org/show_bug.cgi?id=3772 Mar 04 12:01:39 RP: BTW, looking at that bug tells me that "virtual/linux-libc-headers" does exist Mar 04 12:01:44 And more than once, it seems Mar 04 12:02:23 But Sharp ROM stuff is certainly in a bad state. Any improvements welcome. Mar 04 12:02:36 Laibsch: I think my fix might help some of this Mar 04 12:02:53 Great! Mar 04 12:05:25 03rpurdie 07org.oe.dev * r46a0a752... 10/ (1 packages/meta/staging-linkage_1.0.bb): Add staging-linking - glue to allow old toolchains to work after OE staging changes Mar 04 12:11:35 re Mar 04 12:15:21 * RP pushes the sysroot change Mar 04 12:22:11 03rpurdie 07org.oe.dev * rce72f9f4... 10/ (13 files in 7 dirs): (log message trimmed) Mar 04 12:22:11 Change staging layout to match the target system layout. WARNING - staging ABI change. Mar 04 12:22:11 This update completes the conversion of OE.dev to use sysroot and have a staging Mar 04 12:22:11 layout that matches the target system. This means we no longer need to mangle Mar 04 12:22:11 pkgconfig files and can use its sysroot option instead. Users of old toolchains Mar 04 12:22:14 (gcc prior to 3.4 and external ones) may need to add cross-linkage and Mar 04 12:22:16 staging-linkage to their toolchain dependencies. Since this update changes Mar 04 12:22:18 03rpurdie 07org.oe.dev * re3724545... 10/ (3 files in 3 dirs): Remove virutal/linux-libc-headers, no such virtual exists Mar 04 12:24:57 is glibc-intermediate used when building for uclibc? just checking if that's ok :> Mar 04 12:25:17 Jin^eLD: That doesn't sound right Mar 04 12:25:53 hmm Mar 04 12:26:52 let's see what the build does next, I guess there's one more point for investigation on my list then Mar 04 12:27:21 hmm, it does start building uclibc.. maybe glibc-intermediate is needed for some gcc stuff at start? doh... toolchains are nightmare :) Mar 04 12:27:55 Jin^eLD: When it stages it will smash uclibc up so I'd find out why its doing it sooner than later Mar 04 12:28:20 ok, I will check it then Mar 04 12:28:34 it's processed before uclibc though Mar 04 12:29:36 Jin^eLD: Check the PREFERRED_PROVIDER of libc-for-gcc Mar 04 12:30:51 PREFERRED_PROVIDER_virtual/arm-angstrom-uclinuxeabi-libc-for-gcc = "uclibc" Mar 04 12:31:06 should be ok? Mar 04 12:31:12 RP: hmm Mar 04 12:31:49 RP: we should have a post on the front page advertising the changes and the last revision before the changes Mar 04 12:33:48 would be nice to have a tag for it Mar 04 12:34:03 mickey|sofa: Well, the changes have been filtering in for a while now and I have given plenty of warning on the list... Mar 04 12:37:02 Esben: yeah, meta-toolchain is broken here as well Mar 04 12:37:13 Esben: has been working ~3 weeks ago... Mar 04 12:37:27 zecke: which DISTRO? Mar 04 12:37:37 it seems to be in constant yoyo motion... Mar 04 12:37:38 angstrom 2008.1 Mar 04 12:37:55 when is the sysroot change going to be comitted? Mar 04 12:38:18 I am thinking of the patch from rpurdie of 29.02 Mar 04 12:38:22 Esben: It has been Mar 04 12:38:38 Esben: about 15 mins ago Mar 04 12:38:49 ah :-) Mar 04 12:38:52 meta toolchain has always been a somewhat painful experience :) Mar 04 12:39:07 but it indeed did work couple of weeks ago Mar 04 12:39:20 Its also improved massively since it was first written ;-) Mar 04 12:39:20 I did not try the latest Mar 04 12:39:46 yes :> I think the OE snapshot that I deployed was quite a good one Mar 04 12:39:49 great, I will work on meta-toolchain with that :-) Mar 04 12:40:15 RP: uneducated guess: we use xgcc (which makes sense) but has a different sysroot? Mar 04 12:40:31 rebuilding with sysroot on... Mar 04 12:40:45 I'm continue to use it - fear breakage if I upgrade ;> Mar 04 12:40:59 zecke: I'm also trying a build after the sysroot changes here Mar 04 12:47:14 03xora 07org.oe.dev * rcf1e2bc5... 10/ (5 files in 3 dirs): alsa-state.bb : update state files for gta02 Mar 04 12:47:33 NOTE: preferred version 2.6.1 of glibc not available (for item virtual/arm-angstrom-uclinuxeabi-libc-for-gcc) Mar 04 12:47:35 how did that happen? Mar 04 12:47:47 ERROR: Multiple .bb files are due to be built which each provide virtual/arm-angstrom-uclinuxeabi-libc-for-gcc - and it lists glibc-intermediate and uclibc Mar 04 12:47:54 why is it considering glibc at all? Mar 04 12:48:13 Jin^eLD: glibc must provide something uclibc doesn't and it wants Mar 04 12:48:26 hmm Mar 04 12:48:32 another puzzle then Mar 04 12:52:05 RP: Jin^eLD stumbled in my same issue it seems: uclibc get mixed up with glibc in the same /oe tree Mar 04 12:52:53 ant|work: Not really, hes doing something very different Mar 04 12:53:04 RP: the issue "NOTE: preferred version 2.6.1 of glibc not available " is very old... Mar 04 12:53:07 ant|work: I am trying to get uclinux in, so don't take me as a reference Mar 04 12:53:45 RP: I can say that I built from scratch the initramfs images, using uclibc Mar 04 12:54:32 RP: and the size of the image has increased... Mar 04 12:55:04 RP: when I rebuilt it (having in the meanwhile built glibc images) Mar 04 12:55:25 ant|work: ok, but why? Mar 04 12:56:01 hmm.. for me glibc-intermediate surely should not be build, it fails anyway Mar 04 12:56:13 so you were right, RP Mar 04 12:56:14 I did not pay attention to the NOTES, but I'm sure it found an "external-toolchain" compiling under glibc Mar 04 12:56:38 ant|work: the external-toolchain thing is another painful story Mar 04 12:56:45 I spent quite some time trying to get rid of it :) Mar 04 12:57:03 RP: http://www.angstrom-distribution.org/building-angstrom STEP 5 Mar 04 12:57:48 ant|work: So debug the problem. I don;t know what the problem is Mar 04 12:57:57 I played with # TARGET_OS = "linux" / "linux-uclibc" Mar 04 12:58:13 my bad ? Mar 04 13:00:49 maybe you ran into something similar that I have? Mar 04 13:00:52 I also had to change TARGET_OS Mar 04 13:01:09 and it turned out there are quite a few things spread around that depend on TARGET_OS being recognizable Mar 04 13:01:34 Changing TARGET_OS can cause all kinds of weird things to happen Mar 04 13:02:07 Jin^eLD: I did 'ANGSTROM_MODE = "glibc" TARGET_OS="linux-uclibc"' before baking the initramfs images Mar 04 13:02:26 err... Mar 04 13:02:33 you mean ANGSTROM_MODE = "uclibc"? Mar 04 13:02:37 obviously yes Mar 04 13:02:41 that's what I have Mar 04 13:02:56 but my TARGET_OS is "new" Mar 04 13:03:04 I think the one you are using should be ok Mar 04 13:03:07 the tricky part is TARGET_OS...^^^ Mar 04 13:03:19 RP: ok, my fault :-) Mar 04 13:03:55 RP: How come you claim virtual/linux-libc-headers does not exist? http://rafb.net/p/dGSLQP71.html Mar 04 13:05:56 Laibsch: OE currently works on linux-libc-headers, not virtual/linux-libc-headers Mar 04 13:06:05 this is surely interesting: Mar 04 13:06:06 ERROR: Multiple .bb files are due to be built which each provide virtual/arm-angstrom-uclinuxeabi-libc-for-gcc Mar 04 13:06:15 how did I get into that position? Mar 04 13:06:27 Jin^eLD: I've seen too Mar 04 13:06:34 Laibsch: If we want to switch to using a virtual that is fine but we should actually convert things to they use it, nothing currently does Mar 04 13:06:45 Laibsch: Yes, the header .bb files provide it but that is all Mar 04 13:07:20 Well, I think the problem with sharprom is that sharprom-native provides linux-libc-headers as well Mar 04 13:07:30 ant|work: were you able to figure out how you got there? Mar 04 13:07:36 RP: And thus the "real" package does not get built Mar 04 13:07:37 Laibsch: Providing that is fine Mar 04 13:07:48 Jin^eLD: I guess the today solution is building uclibc from scratch (e.g. no glibc builds in tree) Mar 04 13:07:54 Laibsch: ah, right, yes. That should be removed I think Mar 04 13:08:08 RP: Well, I remember running into some kind of problem when linux-libc-headers was not built Mar 04 13:08:14 Don't ask me what it was Mar 04 13:08:25 ant|work: you mean removing all glibc related .bb files?? Mar 04 13:08:38 Jin^eLD: that ERROR did not stop the builds Mar 04 13:08:49 Laibsch: FWIW I think you're right and it should be removed from sharprom-native Mar 04 13:08:59 IIRC, hrw and I discussed about removing the PROVIDES or using virtual/ and preferred-provider and opted for the latter Mar 04 13:09:14 Let me see if we can get a log Mar 04 13:09:19 of the discussion Mar 04 13:09:36 Laibsch: What was there was 100% certainly wrong and wouldn't build due to circular depends unless a 3rd party file stepped in like external-toolchain Mar 04 13:09:59 Laibsch: I'm 100% certain my patch improved the siuation but that doesn't mean there aren't futher issues Mar 04 13:10:04 !oebug 2199 Mar 04 13:10:05 * * Bug 2199, Status: RESOLVED (FIXED), Created: 2007-05-01 13:48 Mar 04 13:10:06 * * : tslib fails do_compile for Sharp ROM Mar 04 13:10:07 * * http://bugs.openembedded.org/show_bug.cgi?id=2199 Mar 04 13:10:11 ant|work: yes, that's right, the error does not stop the build for me either, it is actually trying to build *both* - glibc and uclibc Mar 04 13:10:19 Laibsch: I read that since its referenced from the .bb file Mar 04 13:10:24 OK Mar 04 13:10:38 If you think you improved the situation, I applaud you Mar 04 13:10:57 You understand the issues better than me Mar 04 13:11:21 Just want to make sure the reasons this was added are taken into consideration Mar 04 13:11:52 * Laibsch looks at 2199 and tries to remember what triggered me stumbling upon it Mar 04 13:12:21 Jin^eLD: my concern is the two libc are both in /oe/build/tmp and thus in the path Mar 04 13:12:58 ant|work: well, but does that matter.. in the sense: if I wipe out the build directory and start from new - the dependency resolution thing will still hit me Mar 04 13:13:04 * Laibsch tries "DISTRO=sharprom bitbake tslib" Mar 04 13:13:35 so while your concern is indeed valid for targets where both uclibc and glibc are possible, for me it will not even build because glibc is not available for uclinux Mar 04 13:14:28 so main question is - how did this resolution happen in the first place and why does it attempt to build both Mar 04 13:14:36 and why it is even continuing allthough there is an ERROR: Mar 04 13:14:37 ? Mar 04 13:14:53 RP, any thoughts on that? Why is it going on with the build if it encounters something like: Mar 04 13:14:55 ERROR: Multiple .bb files are due to be built which each provide virtual/arm-angstrom-uclinuxeabi-libc-for-gcc Mar 04 13:15:20 Jin^eLD: these kind of error is not a stopper (see oebug 3428) Mar 04 13:15:58 * ant|work got used to these NOTES and ERRORS.... Mar 04 13:16:16 *reading the bug* Mar 04 13:18:01 this note is nice: This usually means one provides something the other doesn't and should. Mar 04 13:18:03 :) Mar 04 13:18:18 Jin^eLD: ;=) Mar 04 13:18:42 now question is - how to figure out what :) Mar 04 13:19:03 im compiling a program and I get this error Mar 04 13:19:04 /gumstix-oe/tmp/staging/gumstix-custom-connex-angstrom-linux-uclibcgnueabi/kernel/include/linux/rwsem.h:$ Mar 04 13:19:11 *ant->food->bbl Mar 04 13:19:11 error: asm/rwsem.h: No such file or directory Mar 04 13:20:21 rwsem.h as it says is trying to include /asm/rwsem.h but it doesnt exist Mar 04 13:20:44 pbne04: something has not been staged correctly? just guessing Mar 04 13:22:18 but no matter what, these files are produced when I bitbake an image, not by me Mar 04 13:22:32 so how can the file include a headerfile which isnt there? Mar 04 13:26:04 * * OE Bug 3931 has been created by  Mar 04 13:26:06 * * binutils-cross-2.18-r1-do_populate_staging Mar 04 13:26:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3931 Mar 04 13:28:11 RP: tslib still builds fine after your changes Mar 04 13:28:51 And the first few lines look better, too Mar 04 13:30:23 NOTE: multiple providers are available for virtual/arm-angstrom-uclinuxeabi-libc-for-gcc (uclibc, external-toolchain, eglibc-intermediate); Mar 04 13:30:24 NOTE: consider defining PREFERRED_PROVIDER_virtual/arm-angstrom-uclinuxeabi-libc-for-gcc Mar 04 13:30:30 why is this not helping? Mar 04 13:30:31 PREFERRED_PROVIDER_virtual/arm-angstrom-uclinuxeabi-libc-for-gcc = "uclibc" Mar 04 13:30:38 I have this in my distro conf file Mar 04 13:31:04 thanks I'll try it Mar 04 13:31:07 glibc would have been listed, I temporary removed the .bb files Mar 04 13:42:10 Laibsch: great :) Mar 04 13:42:40 Jin^eLD: hmm :/ Mar 04 13:42:43 I am peeking PROVIDES Mar 04 13:42:53 for example eglibc is providing virtual/linux-libc-headers but uclibc is not Mar 04 13:42:55 is that ok? Mar 04 13:43:14 I'd have to take glibc back in to check what it is providing Mar 04 13:43:53 Jin^eLD: It is likely to be something like that Mar 04 13:44:14 * RP -> lunch Mar 04 13:44:16 hmm, glibc-intermediate provides way less stuff Mar 04 13:44:30 only itself and virtual/arm-angstrom-uclinuxeabi-libc-for-gcc Mar 04 13:45:20 my uclibc is providing virtual/arm-angstrom-uclinuxeabi-libc-for-gcc twice, which I find a little strange Mar 04 13:45:30 but that should not matter I guess? hmm Mar 04 13:45:30 I don't know why eglibc is providing linux-libc-headers, that sounds wrong Mar 04 13:46:02 yeah.. I never tries using eglibc, no idea what's up with it Mar 04 14:29:55 RP, what did you push last night? I picked up some breakage overnight Mar 04 14:30:43 Crofton: What kind of breakage? Mar 04 14:30:52 sysroot went in this morning... Mar 04 14:31:12 include file not found in an idl compilation for omniorb Mar 04 14:31:33 not something "common" Mar 04 14:31:57 do you have a link to some of your emails on the subject handy? Mar 04 14:32:58 Crofton: Not specific springs to mind... Mar 04 14:33:39 ok Mar 04 14:33:42 let me poke around Mar 04 14:33:57 the packages involved are not well behaved on a good day Mar 04 14:34:18 Crofton: Which target would I build to see this? omniorb? Mar 04 14:37:22 something I do not have in .dev Mar 04 14:38:11 Crofton: ah. In that case its probably something making asumptions about the layout of staging Mar 04 14:38:30 yep :) Mar 04 14:38:32 grep your local recipes for "STAGING_DIR" and take it from there Mar 04 14:38:54 how about STAGINGING_BINDIR? Mar 04 14:39:23 and STAGING_BINDIR_NATIVE? Mar 04 14:39:30 no, should be fine Mar 04 14:39:54 yeah I am wondering if the recipe just has a subtle issue Mar 04 14:40:55 a user include snuck into the omniidl arguments Mar 04 14:42:07 which should be pointed into staging Mar 04 14:42:23 * Crofton wonders how it ever worked .... Mar 04 14:42:44 RP: gcc cross-sdk fails even after the sysroot changes Mar 04 14:43:20 zecke: it builds here. Which version? Mar 04 14:43:33 gcc-cross-sdk-4.2.2-r6 Mar 04 14:43:41 which makes 4.1.2 and 4.2.2 broken for people Mar 04 14:48:09 btw what do you think - should I base my uclinux attempts on stable or on dev? Mar 04 14:48:49 zecke: This is after the ABI change I committed earlier today? Mar 04 14:58:11 hrw : please, could you explain me how to set up feed browser ? i don't find any documentation howto setup it Mar 04 14:58:57 Genesis: f-b is made from 2 scripts. index.php handle web part - nothing to do in it Mar 04 14:59:20 Genesis: update.php parse Packages files and create database Mar 04 14:59:22 i copied in my ipk repo Mar 04 14:59:23 rp, I suspect bad pkgconfig usage :) Mar 04 14:59:39 Genesis: includes/config.inc contain list of feeds to use Mar 04 14:59:39 hrw : perharps should i run update.php with php-cli ? Mar 04 14:59:56 oki Mar 04 15:00:26 RP: after the last changes, what would you for TARGET_OS if I'm building uclibc images?. It seems OE and Angstrom differs here... Mar 04 15:00:35 Genesis: run update from shell yes Mar 04 15:00:42 oki thx Mar 04 15:00:43 Genesis: without time limit Mar 04 15:00:51 how ? Mar 04 15:00:52 RP: icu seems to be a victim of recent changes Mar 04 15:01:01 Genesis: php update.php? Mar 04 15:01:07 oki Mar 04 15:01:15 i was speaking about "without time limit" Mar 04 15:01:24 no way you gave me some pointer thx Mar 04 15:01:30 Genesis: thats php configuration Mar 04 15:01:45 i'm noob with php :) Mar 04 15:02:01 thx Marcin Mar 04 15:02:02 Genesis: time_limit iirc in php.ini Mar 04 15:02:17 bonjour chouimat|work Mar 04 15:03:27 morning Mar 04 15:08:57 rebuild stopped cleaning? Mar 04 15:09:36 Crofton: either use bitbake 1.8.10 or bitbake 1.8 svn Mar 04 15:10:28 ant|work: The last changes have no effect on TARGET_OS Mar 04 15:11:01 XorA: hmm... Mar 04 15:11:09 RP: C++ linkage failing Mar 04 15:11:26 XorA: Is this it using gcc when it should be using g++ ? Mar 04 15:11:43 RP: yes Mar 04 15:11:51 hmm Mar 04 15:11:59 now bitbake won't run? Mar 04 15:12:10 Crofton: with what error? Mar 04 15:12:22 RP: is there a single simple fix to these cases? Mar 04 15:12:23 mode has no attirbute digraph Mar 04 15:12:27 RP: if so Im in right place to fix Mar 04 15:12:37 Crofton: touch local.conf Mar 04 15:12:48 Crofton: I need to fix that properly (I thought i had but I haven't) Mar 04 15:13:02 ah the miracles of touch Mar 04 15:13:19 I assume it won't impact new installs? Mar 04 15:13:29 XorA: There is a patch in poky Mar 04 15:13:40 RP: excellent I shall steal and credit Mar 04 15:13:58 XorA: thanks :) Mar 04 15:14:03 * Crofton read steal and take credit Mar 04 15:17:21 Crofton: thats the American in you Mar 04 15:17:25 :) Mar 04 15:18:36 RP: sorry I'm rather tired today..I don't get the magic about TARGET_OS (http://www.openembedded.org/user-manual&dpage=commonuse_prebuilt_toolchain / "...If your toolchain is a uclibc toolchain you will need to set TARGET_OS to linux-uclibc") but I'm building the toolchain...chicken and egg problem? Mar 04 15:19:14 ant|work: Don't touch it, angstrom takes care of all of it for you Mar 04 15:20:03 RP: ok, so it is done by ANGSTROM_MODE. For Angstrom. Mar 04 15:20:08 yeah.. the hidden magic did cost me some time ;) Mar 04 15:20:10 ant|work: right Mar 04 15:44:25 03mickeyl 07org.oe.dev * r425c6554... 10/ (1 packages/roadmap/roadmap.inc): Mar 04 15:44:25 roadmap.inc: update author's contact address to the new maintainer. Mar 04 15:44:25 Paul is interested in including patches, so whoever wants to, feel free to contact him. Mar 04 15:44:32 03rpurdie 07org.oe.dev * r627ef0e2... 10/ (3 files in 3 dirs): libgcrypt: Fix pkgconfig file Mar 04 15:44:38 03rpurdie 07org.oe.dev * r8e2516af... 10/ (3 files in 2 dirs): linux-libc-headers: Add dependency fixes from poky Mar 04 15:44:44 03xora 07org.oe.dev * rd1c77dbb... 10/ (5 files in 3 dirs): icu_3.6.bb : g++ linking fixes stolen from poky! Mar 04 15:45:22 RP, my problem was my problem, the pkgconfig changes just made it obvious I am an idiot Mar 04 16:05:57 Crofton: I'm pleased its sorted :) Mar 04 16:07:06 me too Mar 04 16:07:38 I beat it to work, but I think I am getting good enough to fix it properly ... Mar 04 16:25:29 Jin^eLD: are you working with a blackfin device for uclinux? Mar 04 16:29:07 apaulsen: no Mar 04 16:29:15 it will be an arm9 Mar 04 16:29:24 which is imho somewhat silly but well.. customer wants it Mar 04 16:29:55 the kernel is not yet ready anyway so I have no system to test Mar 04 16:30:09 which does not matter at this point because I am still fighting with the toolchain Mar 04 16:30:19 gdb armulator could probably be used for testing Mar 04 16:30:20 Jin^eLD: ok, I just got excited when I saw you mention it earlier. I'm trying to figure out how to get an oe-generated distro on the blackfin board my boss picked out for me Mar 04 16:30:38 apaulsen: Koen started some work for the bfin board Mar 04 16:30:51 unfortunately his board did not work at all so he did not continue the porting Mar 04 16:30:58 Jin^eLD: yes, I emailed him and he sent me a link to his notes Mar 04 16:31:26 apaulsen: well, you'd be the 3rd one who is interested in the uclinux thing then Mar 04 16:31:30 maybe we can join forces :> Mar 04 16:31:42 perhaps Mar 04 16:32:26 when do you plan to work on this? Mar 04 16:33:38 Jin^eLD: my boss was wondering why I didn't have linux running two hours after I received the board yesterday :( Mar 04 16:33:47 so...soon Mar 04 16:33:50 :) Mar 04 16:33:53 apaulsen, heh! Mar 04 16:34:00 apaulsen: hehe Mar 04 16:34:11 well, if you take what AD distributes it would probably be running Mar 04 16:34:32 I figure they provide their own stuff, because the stock uclinux things are unusable "out of the box" Mar 04 16:34:49 what AD distributes isn't linux though, is it? Mar 04 16:34:59 I am not sure, but I would think it is? Mar 04 16:35:02 well, uclinux Mar 04 16:39:31 * CosmicPenguin watches glibc-intermediate blow up Mar 04 16:42:21 Jin^eLD: I'm installing their files right now to find out what they ship Mar 04 16:44:29 it's a little different for me, but speaking of "generic" uclinux support - we will need more or less the same tweaks in OE Mar 04 16:44:40 I have a list of caveat places Mar 04 16:45:28 apaulsen: good boss you have; he's clearly interested in your work, and thinks highly of your skills ( <--- /me is practicing putting things into a positive light! :-D ) Mar 04 16:46:18 mwester-laptop: yes, that or he thinks software = magic :) Mar 04 17:00:01 03thebohemian 07org.oe.dev * r1d06736a... 10/ (9 files in 3 dirs): Mar 04 17:00:01 classpath: Mar 04 17:00:01 - added patch to fix StAX API incompatibility Mar 04 17:00:01 - changed classpath-minimal recipes to generate less binary packages Mar 04 17:00:02 03thebohemian 07org.oe.dev * rc648f3ce... 10/ (1 packages/woodstox packages/woodstox/woodstox2_2.0.6.bb): woodstox: New recipe. Mar 04 17:00:11 03thebohemian 07org.oe.dev * r189c4dd2... 10/ (1 MAINTAINERS): MAINTAINERS: Updated info. Mar 04 17:00:17 03woglinde2 07org.oe.dev * r3601bc2c... 10/ (4 files in 4 dirs): Mar 04 17:00:17 simpad-kernel-2.6.21: move defconfig to proper place Mar 04 17:00:17 * packages/linux/linux/simpad/deconfig is not a proper Mar 04 17:00:17 place when you will support more kernelversions than one Mar 04 17:06:00 wb zecke Mar 04 17:06:37 zecke: I can't reproduce the gcc-cross-sdk issue. Was that a build before or after the ABI change? Mar 04 17:06:59 ~lart libsecy Mar 04 17:07:00 * ibot slaps a compatible dib on libsecy's head Mar 04 17:07:03 ~lart libsexy Mar 04 17:07:03 * ibot --purges libsexy Mar 04 17:07:14 RP: both Mar 04 17:07:48 zecke: and it was a build from scratch after the ABI change? :/ Mar 04 17:08:00 RP: sure Mar 04 17:08:57 zecke: Can you share the logs from gcc-cross-sdk somewhere please. Maybe I can work it out from that... Mar 04 17:12:12 rschuster: can you take care more about commit messages? Mar 04 17:13:12 rschuster: http://openembedded.org/commitpolicy Mar 04 17:14:20 RP: do you have /bin/sh as dash? Mar 04 17:14:33 RP: how xgcc ran for you? Mar 04 17:15:00 zecke: bash Mar 04 17:15:31 hrw: ups. what went in wrong? Mar 04 17:16:53 hrw: oh I see .. Mar 04 17:17:13 Jin^eLD: what AD shipped is definately not uclinux. the "kernel" is about 40 lines of code that just does round-robin thread handling Mar 04 17:23:46 uhm.. Mar 04 17:23:54 apaulsen: then I was wrong, at least I thought they do ship uclinux... Mar 04 17:24:04 I know that bfin is in the mainline Mar 04 17:24:31 Jin^eLD: maybe that's somewhere else then, this is what came with their VisualDSP++ tools Mar 04 17:24:32 and also in the stock uclinux repo Mar 04 17:24:38 uuuh.. Mar 04 17:25:50 Jin^eLD: I got the uclinux toolchain, u-boot, and kernel built so far, but their userspace stuff isn't working for me yet. This is very different from OE. Mar 04 17:30:05 bye Mar 04 17:35:36 zecke pasted "log for RP" at http://paste.lisp.org/display/56796 Mar 04 17:35:52 I think this is the relevant part Mar 04 17:43:41 zecke annotated #56796 with "actual searching for the header" at http://paste.lisp.org/display/56796#1 Mar 04 17:45:30 is this libgcrypt problem related to the sysroot change? http://rafb.net/p/IUSpTq74.html Mar 04 17:45:34 zecke: hmm, my build appears to be using the result from gcc-cross as the xgcc Mar 04 17:47:00 -I/home/ich/build/oe/neo1973/tmp/staging/i686-linux/include is wrong too Mar 04 17:47:48 RP: you will have to have an invocation of xgcc somewhere in the log Mar 04 17:48:15 apaulsen: are they using any sort of build env? Mar 04 17:48:33 zecke: I haven't... Mar 04 17:48:58 Jin^eLD: I don't really know what their IDE does in the background. I just looked at the kernel file for a few minutes, then it crashed and ate it's own license file :( Mar 04 17:49:13 RP: you will have to :) Mar 04 17:49:36 build.i686-linux.arm-angstrom-linux-gnueabi/gcc/config.log might be interesting Mar 04 17:49:43 zecke: It builds one, it doesn't use it though... Mar 04 17:50:03 ARCH_TARGETS_FOR_FLAGS is definately wrong, when it is arm-ansgrt.../include it is working... Mar 04 17:51:21 RP: GCC_FOR_TARGET = $ in the Makefile... Mar 04 17:51:23 zecke: It finds that arm-angstrom-linux-gnueabi-gcc is available and uses that instead of xgcc Mar 04 17:51:40 apaulsen: I wonder if Koen had the same problem, he was saying that his board is crashing Mar 04 17:52:55 zecke: Have you seen CC_FOR_TARGET in gcc4-build-sdk.inc Mar 04 17:53:42 RP: CC_FOR_TARGET is set to something else for you in the Makefile? Mar 04 17:53:47 RP: or what is that for you? Mar 04 17:54:39 more stuff tomorrow, I think the issue is not using xgcc, I wonder where it detects your gcc, but passing the wrong flags for the target Mar 04 17:55:46 zecke: I have a better idea how to reproduce now... Mar 04 18:10:58 ARGS_FOR_TARGET is definately wrong Mar 04 18:14:10 urgs... QT in Angstrom is really broken Mar 04 18:14:59 zecke: Any idea where that is coming from? Mar 04 18:16:12 zecke: I've noticed that gcc-cross-sdk have things like libtool-cross and virtual/libc in their depends which they shouldn't Mar 04 18:18:52 If gcc-cross doesn't build first, it breaks nicely. How you managed not to build gcc-cross before gcc-cross-sdk, I don't know though ;-) Mar 04 18:18:58 * RP -> food, back later Mar 04 18:22:20 RP: yes, gcc_4.2.2.bb is setting that, and with the sdk stuff it is... Mar 04 18:22:43 RP: probably it ran configure too early? Mar 04 18:26:10 03koen 07org.oe.dev * r8351c938... 10/ (3 files in 3 dirs): glibc 2.7: fix undefined reference Mar 04 18:35:38 ping Mar 04 18:36:43 * zecke is having fun with the Qtopia ml... Mar 04 18:37:26 zecke: good or bad fun? Mar 04 18:37:56 chouimat|work: raster, werner and me puked when seing the code, the fun part is coming now Mar 04 18:38:32 zecke: where??? Mar 04 18:42:43 FYI : http://www.gergfoundation.org/wp/ Mar 04 18:42:47 chouimat|work: probably http://lists.trolltech.com/qtopia-interest/ Mar 04 18:43:07 thesing: thanks Mar 04 19:13:51 hi rschuster Mar 04 19:14:47 hi henning Mar 04 19:16:24 zecke: Those dependencies come from base.bbclass and autotools.bbclass Mar 04 19:16:59 and its still not using xgcc :) Mar 04 19:18:14 how can I verify that packaged-staging is working properly? Mar 04 19:18:51 rschuster in which way? Mar 04 19:19:07 rschuster: Copy the staging packages from deploy/pstage to a fresh build directory and see if building things works? Mar 04 19:19:10 consulting logfile? Mar 04 19:19:44 I have just upgraded to the new tmp_abi and added INHERIT = "packaged-staging" to my local.conf but I am not seeing any difference ... Mar 04 19:19:46 rp any timeline for the api change? Mar 04 19:19:58 woglinde: 7 hours ago ;-) Mar 04 19:20:06 ah Mar 04 19:20:09 also 'find tmp -name "*.ipk"' does not any results Mar 04 19:20:10 now we have sysroot? Mar 04 19:20:17 woglinde: yes Mar 04 19:20:20 okay Mar 04 19:20:27 thanks Mar 04 19:20:48 rschuster: You usually need to use INHERIT += ".." Mar 04 19:20:59 hvontres|work, ping Mar 04 19:21:01 RP: uh okay Mar 04 19:21:47 rschuster: If its doing things you should see packages in tmp/deploy/pstage iirc Mar 04 19:23:15 still fighting this issue... ERROR: Multiple .bb files are due to be built which each provide virtual/arm-angstrom-uclinuxeabi-libc-for-gcc Mar 04 19:23:20 zecke: I have a feeling I know why -sdk is breaking. I can see a need for cross-sdk and sdk classes :/ Mar 04 19:23:43 RP: ok. thanks Mar 04 19:23:50 Jin^eLD: Share the output from bitbake -DDD somewhere Mar 04 19:23:57 RP: roger that, one sec Mar 04 19:26:12 OE's autoreconf (or whatever this is) created a arm-linux-gnueabi-libtool script in the project sources. The package owner referenced it through "./libtool" in the makefiles. which variable should I use to create the full name of libtool to do some sed magic on the makefile? Mar 04 19:27:03 I think our libtool autofoo sets LIBTOOL as a variable Mar 04 19:27:50 ${TARGET_SYS}-libtool might also be correct if you want to do the substitution Mar 04 19:28:04 * * OE Bug 3932 has been created by  Mar 04 19:28:06 * * webkit-gtk-0.1+svnr30749-r4-do_configure Mar 04 19:28:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3932 Mar 04 19:28:15 RP: ok. thanks! :) Mar 04 19:28:40 do me a favour guys and go get your blood pressure checked, even if it is on one of those drugstore free machines Mar 04 19:30:12 Crofton: Thinking of Greg? Mar 04 19:30:20 yeah Mar 04 19:32:59 RP: http://www.deadlock.dhs.org/jin/logfile.txt Mar 04 19:35:20 Crofton: heh, I'm leaving to go for my annual physical in 15 minutes ;-) Mar 04 19:35:48 I had one a few years back Mar 04 19:35:54 * Crofton hates doctors Mar 04 19:35:54 Jin^eLD: The key line is "NOTE: selecting glibc-intermediate to satisfy virtual/arm-angstrom-uclinuxeabi-libc-for-gcc due to PREFERRED_PROVIDERS" Mar 04 19:36:18 My wife's a nurse so she keeps me in line :-) Mar 04 19:36:22 RP: so somewhere along the way someone sets it? let me grep around Mar 04 19:36:52 I'll go stick my arm in the BP machine in a bit Mar 04 19:36:56 Crofton: I had my bp checked about 4 years ago, I also have a inbuilt safety valve in my nose... Mar 04 19:37:15 Jin^eLD: I suspect its being set somewhere Mar 04 19:39:45 Jin^eLD: Grep for "libc-for-gcc" since it might be made up from TARGET_PREFIX Mar 04 19:40:21 angstrom conf sets something that uses TARGET_PREFIX Mar 04 19:40:43 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc = "glibc-intermediate" Mar 04 19:41:04 Jin^eLD: That looks nasty from your point of view Mar 04 19:41:06 thats in angstrom-2008.1.conf Mar 04 19:41:20 indeed... I wonder how it is supposed to work for no uclinux but uclibc builds Mar 04 19:41:27 because I did set ANGSTROM_MODE to uclibc Mar 04 19:41:29 it should only be setting that for glibc builds Mar 04 19:42:33 let's see if does the trick Mar 04 19:42:44 and thanks a lot for looking at the log, I completely missed it Mar 04 19:42:49 or maybe was looking for the wrong thing Mar 04 19:43:08 Jin^eLD: They're not easy to read :( Mar 04 19:46:43 why is "inherit base" in native.bbclass? :/ Mar 04 19:47:43 doh, that was not quite it... I'll keep looking Mar 04 19:48:26 Jin^eLD: What does "bitbake -b something -e | grep ^PREFERRED_PRO" show? Mar 04 19:50:20 hmm, maybe I am doing something wrong - mostprobably - because it is not showing anything Mar 04 19:50:45 oh ok Mar 04 19:50:46 wait Mar 04 19:51:17 hmm, BB_DEFAULT_TASK = "buildall" does not package dependencies Mar 04 19:51:28 Crofton: pong Mar 04 19:52:14 hvontres|work, poodle is on the way Mar 04 19:52:48 Crofton: thanks Mar 04 19:53:00 Crofton: hmm, when did that stop, the bitbake upgrade? Mar 04 19:53:15 I think so Mar 04 19:55:13 where is the resolutoin of the stirng being done? Mar 04 19:55:20 PREFERRED_PROVIDER_virtual/arm-angstrom-linux-uclibcgnueabi-libc-for-gcc="uclibc-initial" Mar 04 19:55:26 PREFERRED_PROVIDER_virtual/arm-angstrom-uclinuxeabi-libc-for-gcc="uclibc" Mar 04 19:55:31 maybe mine is simply not taken? Mar 04 19:56:16 http://pastebin.mozilla.org/354432 Mar 04 19:56:29 I guess I anyway need uclibc-initial there so maybe that is also part of the problem Mar 04 19:58:51 Jin^eLD: If it didn't think uclibc was buildable for some reason, that would upset it :/ Mar 04 19:59:26 well but id does start building uclibc.. together with glibc-intermediate Mar 04 19:59:33 that part confused me the most Mar 04 19:59:57 doh Mar 04 20:00:02 Jin^eLD: Perhaps something is depending on arm-angstrom-linux-libc-for-gcc ? Mar 04 20:00:16 http://pastebin.mozilla.org/354434 Mar 04 20:00:22 hmm Mar 04 20:00:58 but my string is (or at least I hope it is) arm-angstrom-uclinuxeabi-libc-for-gcc Mar 04 20:01:07 Jin^eLD: At least uclibc is first which is a sign its trying to choose it Mar 04 20:01:12 ooor is it still - linux? Mar 04 20:01:19 how is this string put together, dammit? :) Mar 04 20:02:02 I just mean something could be depending on the linux version... Mar 04 20:02:11 RP, any thoughts on my buildall problem? Mar 04 20:02:31 RP: but I did not replace the uclibc, I use the one in OE Mar 04 20:02:36 so what version do you mean? Mar 04 20:02:42 Crofton: There is a limit to the number of problems I can deal with at once :( Mar 04 20:02:59 ok Mar 04 20:03:01 we need to clone RP :) Mar 04 20:03:22 I've spent all day talking to four people at once :( Mar 04 20:03:32 03mickeyl 07org.oe.dev * r8cf1f402... 10/ (1 packages/freesmartphone/pylgrim_svn.bb): add pylgrim, an EFL-based OSM moving map application Mar 04 20:03:36 03mickeyl 07org.oe.dev * ra4b7a0d3... 10/ (1 packages/freesmartphone/enter_0.0.2.bb): enter svn fix description Mar 04 20:03:41 03mickeyl 07org.oe.dev * r36ae94ae... 10/ (3 files in 3 dirs): gsm0710muxd svn bump SRCREV and add dependency on dbus-glib Mar 04 20:03:46 03thebohemian 07org.oe.dev * rc93306d4... 10/ (1 packages/maemo4/libhildonfm.inc): libhildonfm : Check for directory existance and create if failed. Mar 04 20:03:51 03koen 07org.oe.dev * r21a4d6e9... 10/ (1 conf/distro/include/angstrom-glibc.inc): angstrom-glibc.inc: fix glibc/gcc buglet where -Os goes awry with inlining and fastat64 becomes a missing symbol Mar 04 20:07:39 Crofton: With BB_DEFAULT_TASK set and then you run bitbake foo, does it build foo do_build or foo do_buildall ? Mar 04 20:08:09 checking ... Mar 04 20:08:54 I've totally broken sdk.bbclass :( Mar 04 20:10:30 RP, to the best of my skills, I think it ran do_build Mar 04 20:10:43 that was the last task to complete Mar 04 20:11:12 Crofton: bitbake foo -c buildall runs more? Mar 04 20:14:51 yes, it looks like that may be a work around for me Mar 04 20:15:35 Crofton: I know what the problem is :) Mar 04 20:15:42 ok :) Mar 04 20:15:48 Crofton: base.bbclass does "BB_DEFAULT_TASK = 'build'" Mar 04 20:16:00 which overrides local.conf? Mar 04 20:16:04 That overrides anything the user sets Mar 04 20:16:05 * * OE Bug 3933 has been created by  Mar 04 20:16:07 * * gypsy-0.0+svnr56-r0-do_configure Mar 04 20:16:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3933 Mar 04 20:16:16 Except that a bug in bitbake meant it never it until now Mar 04 20:16:33 so if I'm right a s/=/?=/ should fix it... Mar 04 20:17:04 in base.bbclass? Mar 04 20:17:12 yes Mar 04 20:17:20 * RP tests Mar 04 20:17:22 you fixed a bug in bb to make this happen? Mar 04 20:17:27 Crofton: yes Mar 04 20:17:37 do you want me to check and push? Mar 04 20:17:56 sure :) Mar 04 20:17:58 ok Mar 04 20:18:16 I will do a clean build (with external toolchain) so it will be a while Mar 04 20:18:23 I have a check here just completed which says that will fix it but a second confirmation would be good Mar 04 20:19:14 I need to wipe a bunch of stuff to test properly Mar 04 20:19:59 well, bitbake -e | grep BB_DEFAULT shows "build" before and "buildall" afterwards Mar 04 20:20:18 so I'm happy enough to push if you want Mar 04 20:20:32 ok Mar 04 20:21:28 at least it wasn't a bitbake bug for a change :) Mar 04 20:22:27 let me know when it is pushed Mar 04 20:23:24 nite everyone Mar 04 20:23:26 rp thanks Mar 04 20:23:34 I'll continue digging tomorrow Mar 04 20:28:15 Crofton: pushed Mar 04 20:33:41 <_diego_> hi, there is a way to build (using bitbake) a module for a kernel already built? Mar 04 20:33:58 <_diego_> i was looking for some example, but no luck till now Mar 04 20:34:06 _diego_: You would just write a recipe which installed the file in do_install Mar 04 20:35:16 <_diego_> yes, but to build that module i have to set, i think, SYSSRC to the kernel source Mar 04 20:35:46 _diego_: Sorry, I misread that as you wanting to use a prebuilt kernel module Mar 04 20:36:08 _diego_: Look at orinoco-modules Mar 04 20:36:13 or hostap Mar 04 20:36:28 <_diego_> thanks Mar 04 20:43:17 re Mar 04 20:44:09 * chouimat|work just ordered this http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 :) Mar 04 20:44:33 re flo Mar 04 20:46:40 chouimat|work: looks nice... especially if you have something to feed the fpga with Mar 04 20:47:25 flo_lap: I'm working with a slower version of the soc here ... so I thought it would be nice to have a faster one for the native compile step Mar 04 20:53:04 I wonder if they're going to port that useless NetBSD on ts7800 again or if they instead finally start to push stuff mainstream Mar 04 20:54:12 ynezz: I would like to have netbsd on it ... Mar 04 20:54:22 really? what for? Mar 04 20:54:28 anyway it was a good move from them to stop using that broken Cirrus Logic's SOCs in new products Mar 04 20:54:30 chouimat|work: looks like fun. did it cost you an embedded-leg too? :) Mar 04 20:54:45 hvontres|work: 269 for the board, 100 for the development kit Mar 04 20:55:00 chouimat|work: not bad... Mar 04 20:55:36 hvontres|work: yup because there ftp server is slow ... and sometimes it's fun to have printed documentation :) Mar 04 20:56:16 hi ph5 Mar 04 20:56:49 no wonder if their ftp is hosted on same ts7800 as their website :) Mar 04 21:02:18 03rpurdie 07org.oe.dev * r3a10bb3d... 10/ (1 classes/base.bbclass): base.bbclass: Only set BB_DEFAULT_TASK if it wasn't set already Mar 04 21:02:26 03rpurdie 07org.oe.dev * r8a98b059... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: Only need to run after do_package_write, no need to list package types. Mar 04 21:30:11 * RP resists the urge to rip the gcc .bb files to shreds Mar 04 21:30:28 * RP also notes his sdk change isn't at fault, the gcc-cross-sdk recipe is just broken :( Mar 04 22:10:04 if i use bitbake -c devshell ... what's the name of the var to set the command that is started? Mar 04 22:14:00 in my local.conf, I have TERMCMD = "${SCREEN_TERMCMD}" Mar 04 22:14:00 and TERMCMDRUN = "${SCREEN_TERMCMDRUN}" Mar 04 22:15:20 hm... wasnt that something with DEVSHELL_...? i have a XTERM_TERMCMD = 'xterm -T "$TERMWINDOWTITLE"' Mar 04 22:17:41 Yeah, those are left-over from when I attempted to get it working; I don't think it ever worked with xterm so I abandoned the idea. I seem to recall that screen worked, though. Mar 04 22:19:05 i just put gvim there... my ide ;) Mar 04 22:19:55 what do you mean never worked? Mar 04 22:20:47 mickeyl told me that devshell is a nice thing to use... it works fine for me but i deleted my local.conf by accident Mar 04 22:21:46 emdete: TERMCMD = "${XTERM_TERMCMD}" Mar 04 22:22:22 and maybe TERMCMDRUN = "${XTERM_TERMCMDRUN}" Mar 04 22:24:02 lets see... does nobody else use devshell? Mar 04 22:24:39 I use it to build kernels Mar 04 22:27:31 I do not have a TERMCMD in my local.conf Mar 04 22:29:11 okay, works fine. wonderful ;) Mar 04 22:29:36 i just dont have xterm installed that's the cause i need a TERMCMD Mar 04 22:30:57 thnx alot! :D Mar 04 22:34:02 03koen 07org.oe.dev * r16f0fa7e... 10/ (1 packages/gypsy/gypsy.inc packages/gypsy/gypsy_svn.bb): gypsy: add staging method, maxrev patch Mar 04 23:22:58 another bitbake exception http://pastebin.com/m11907ba0 Mar 04 23:38:04 * * OE Bug 3930 has been RESOLVED (FIXED) by xjqian(AT)gmail.com Mar 04 23:38:06 * * Typo fix for abiword-plugins STAGING_INCDIR Mar 04 23:38:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3930 Mar 04 23:43:04 * * OE Bug 3897 has been REOPENED by trini(AT)embeddedalley.com Mar 04 23:43:06 * * mtd-utils-dev is empty Mar 04 23:43:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3897 Mar 04 23:46:21 Laibsch: I have sd cards working for collie. Not well tested but they are mounted and md5sums over device is the same as on desktop machine. Tested cards: SD: 256MB(ScanDisk) 2G(ScanDisk) MMC: 16MB(Canon) 32MB(NoName) Mar 04 23:47:16 03xjqian 07org.oe.dev * rd6df421d... 10/ (1 packages/abiword/abiword-plugins_2.5.2.bb): abiwork-plugins_2.5.2: fix typo, close bug #3930 Mar 04 23:58:09 night all. Mar 05 00:05:04 * * OE Bug 3934 has been created by yan(AT)seiner.com Mar 05 00:05:06 * * X loses keyboard and focus after some unspecified time Mar 05 00:05:08 * * http://bugs.openembedded.net/show_bug.cgi?id=3934 Mar 05 00:13:04 OK, patch up on 3897 to close it again Mar 05 02:14:45 RP: hey, eloberate on your feeling once you are awake Mar 05 02:43:05 * * OE Bug 3935 has been created by dannytaylor(AT)visi.com Mar 05 02:43:07 * * Aircrack-NG fix Mar 05 02:43:09 * * http://bugs.openembedded.net/show_bug.cgi?id=3935 **** ENDING LOGGING AT Thu Mar 06 12:37:06 2008