**** BEGIN LOGGING AT Mon Sep 14 02:59:57 2009 Sep 14 07:24:52 03Koen Kooi 07org.openembedded.dev * r97baea51df 10openembedded.git/recipes/powertop/powertop_1.11.bb: powertop: fix compilation with the extra states patch Sep 14 08:04:28 http://projects.linuxtogo.org/frs/download.php/222/atd-0.80.tar.gz is empty Sep 14 08:04:43 something wrong with ltg ? Sep 14 08:08:34 same story with http://projects.linuxtogo.org/frs/download.php/14/prismstumbler-0.7.4pre1.tar.gz Sep 14 08:08:57 03Koen Kooi 07org.openembedded.dev * rd4a87d12b3 10openembedded.git/ (conf/checksums.ini recipes/gtk-webcore/midori_0.1.10.bb): midori: add 0.10 Sep 14 08:09:04 directfb.org seem hosed too Sep 14 08:09:21 * khem things nothing better than sleep now Sep 14 08:14:58 morning all ! Sep 14 08:30:39 good morning Sep 14 08:31:29 good morning Sep 14 08:32:57 hi dth Sep 14 08:33:18 hi florian Sep 14 08:37:25 anyone worked with NS9xxx-chips? Sep 14 08:38:12 ( 9210 for example is used inside this: http://www.digi.com/products/embeddedsolutions/digiconnectme.jsp#overview ) Sep 14 08:39:09 ah srry, wrong link ( http://www.digi.com/products/embeddedsolutions/digiconnectme9210.jsp#overview ) Sep 14 08:55:09 florian: good morning Sep 14 09:39:58 Good morning all Sep 14 10:36:37 good morning Sep 14 10:48:58 03Klaus Kurzmann 07shr/import * r424994c32d 10openembedded.git/recipes/libhito/libhito_git.bb: Sep 14 10:48:58 libhito: remove shr inherit Sep 14 10:48:58 Signed-off-by: Klaus Kurzmann Sep 14 10:49:08 03Klaus Kurzmann 07shr/import * rcd8dfd1e3d 10openembedded.git/recipes/neod/neod_git.bb: Sep 14 10:49:08 neod: remove shr inherit Sep 14 10:49:08 Signed-off-by: Klaus Kurzmann Sep 14 11:36:00 To the maintainer of the Midori recipe: please have a look at the midori 0.1.8 recipe in shr/import http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/gtk-webcore/midori_0.1.8.bb?h=shr%2Fimport i think that's a nicer recipe Sep 14 11:49:47 I'm trying to unify several developments in gcc 4.3 or at least 4.2. pxa255,pxa270,dm365,omap3 or the cpus Sep 14 11:50:17 for pxa255 anybody knows which is the best machine? Sep 14 11:53:03 from gcc's standpoint pxa255 and pxa270 should be equiv. Sep 14 11:53:32 ah, sorry no Sep 14 11:53:35 my bad :-) Sep 14 11:55:14 maybe the cross gcc that I have compiled using akita machine (pxa270) can be used also for pxa255 changing mtune march and so on. Sep 14 11:56:16 I only have pxa270s here Sep 14 11:57:27 czr: ok, do you use GCC 4.2.4 ? Sep 14 11:57:44 it will arrive gcc 4.3 ? Sep 14 11:57:52 4.1.2 actually at the moment Sep 14 11:58:03 I froze the toolchain ages ago, haven't tried newer gccs Sep 14 12:37:46 03Cliff Brake 07org.openembedded.dev * r517834d5e9 10openembedded.git/recipes/calibrator/calibrator_svn.bb: Sep 14 12:37:46 calibrator: add new recipes for cache calibrator Sep 14 12:37:46 Used to load system during RT testing Sep 14 13:24:18 hmm, switching linux-libc-headers destroys the contents of STAGING/usr/inclue Sep 14 14:32:48 03Koen Kooi 07org.openembedded.dev * r0e4c4a74ae 10openembedded.git/recipes/linux/ (linux-neuros/neuros-osd2/defconfig linux-neuros_git.bb): linux-neuros git: updates Sep 14 14:32:58 03Koen Kooi 07org.openembedded.dev * r05b103fa04 10openembedded.git/ (conf/checksums.ini recipes/julius/ti-julius-demo_r962.bb): julius: add demo files from the TI speechrecognizer demo Sep 14 15:02:12 morning Sep 14 15:02:42 hi kergoth Sep 14 15:03:06 downloads from http://projects.linuxtogo.org gets empty files Sep 14 15:03:46 http://projects.linuxtogo.org/frs/download.php/222/atd-0.80.tar.gz Sep 14 15:04:17 could someone here fix it Sep 14 15:27:05 khem: any idea why gcc-cross_4.3.3.bb fails with /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/../../../../x86_64-pc-linux-gnu/bin/ld: cp/init.o: bad reloc symbol index (0x4721e548 >= 0xe3) for offset 0xdd074d0d13e5fe7 in section `.debug_info' Sep 14 15:27:09 cp/init.o: could not read symbols: Bad value Sep 14 15:27:11 ? Sep 14 15:36:58 JaMa: thats a linker error Sep 14 15:37:01 what binutils ? Sep 14 15:38:03 03Cliff Brake 07org.openembedded.dev * re00a889a30 10openembedded.git/recipes/rt-tests/rt-tests_git.bb: rt-tests: add git recipe Sep 14 15:38:09 khem: 2.19.51.0.14 and 2.20.51.0.1 but it worked about a week or 2 ago with this binutils.. Sep 14 15:39:50 brb Sep 14 15:41:49 * JaMa trying to rebuild that gcc-cross for freerunner arm4t (that error was from spitz arm5te) Sep 14 15:52:04 JaMa: Could you file a bug report for it ? Sep 14 15:52:56 JaMa: with preprocessed file and the commandline options used (target and host triplets) Sep 14 15:57:39 03Phil Blundell 07org.openembedded.dev * rc5e69bf053 10openembedded.git/ (conf/checksums.ini recipes/binutils/binutils_2.19.51.bb): binutils_2.19.51: remove already-applied patches, add source checksum Sep 14 16:10:45 khem: glibc's do_stage - any reason we can't just copy the data from do_install into staging? Sep 14 16:14:29 RP I think that will be better Sep 14 16:18:27 khem: Agreed Sep 14 16:29:02 khem: I'll fill it when I get a bit more info.. I tried to revert your 56ca890cdd6faff2afa66931fc31376d2d9afa87 just in case as it was touching some gcc cross options, we'll see Sep 14 16:33:44 khem: hmm compiled fine on that arm4t, now lets see if clean build on arm5te is ok on tree with that patch reverted :/ Sep 14 17:08:16 our gcc recipes don't half suck :/ Sep 14 17:33:15 JaMa: that does not make sense to me Sep 14 17:33:36 same code is put under if [ "${HOST_SYS}" != "${TARGET_SYS}" ] Sep 14 17:33:55 and thats going to be true only for gcc-cross* recipes Sep 14 17:35:20 so essentially it is same code being compiling for you with or without this patch Sep 14 17:35:25 anyone played with the fish shell? Sep 14 17:53:24 hmm, wonder if i should fire RecipeParsed in bb.parse rather than from bb.cache/bb.cooker Sep 14 17:56:15 hi Sep 14 18:01:21 kergoth bb.parse seems more suitable Sep 14 18:02:07 yeah, i suppose. otherwise things like amend-recipes wouldn't be able to leverage the event Sep 14 18:02:10 * kergoth moves it Sep 14 18:02:22 * kergoth 's starting to move some of his recent prototype stuff over to bitbake master Sep 14 18:02:58 what i really dislike about the way we do things now is just how much crap is in the parser Sep 14 18:03:14 the whole "if include .." crap to decide when to run finalizing code for example is just crap Sep 14 18:03:20 i knew it when i wrote the initial prototype of it Sep 14 18:03:22 heh Sep 14 18:06:30 yeah if something is lame dont implement it :) Sep 14 18:08:33 oh well, can look at cleaning that up later Sep 14 18:10:04 khem: thinking anonymous python functions can just go away entirely in favor of event handlers responding to RecipeParsed. would make it much more clear and obvious when that code will be executed Sep 14 18:10:10 heh Sep 14 18:12:04 yes that way they have some place in the flow Sep 14 18:12:58 * cbrake wonders how much things slow down if the OE build directory is in a software raid partition ... Sep 14 18:13:18 i have a problem Sep 14 18:13:18 need to install another HD next time system is down and run some tests Sep 14 18:13:36 I m trying to create a helloword for beagleboard Sep 14 18:14:07 03Chris Larson 07master * ra002f4f0d1 10bitbake.git/lib/bb/ (event.py parse/parse_py/BBHandler.py ui/knotty.py): Sep 14 18:14:07 Add a RecipeParsed event, which can be used as an alternative to anonymous functions. Sep 14 18:14:07 Signed-off-by: Chris Larson Sep 14 18:14:09 and I get this error when running: bitbake -b oe/test/hello_1.0.bb Sep 14 18:14:23 ERROR: Please set the 'PERSISTENT_DIR' or 'CACHE' variable. Sep 14 18:14:52 SeldanB: sounds like you didn't set BBPATH, or set it incorrectly Sep 14 18:15:23 I have everything set, export BBPATH=$OE_HOME/beagleboard/:$OE_HOME/beagleboard/$MY_OE_CONF:$OE_HOME/openembedded Sep 14 18:15:37 should *.bb be in recipes only? Sep 14 18:15:53 export BBFILES="$OE_HOME/openembedded/recipes/*/*.bb" Sep 14 18:15:58 bitbake doesn't care where recipes are Sep 14 18:16:12 but that error means it isnt' parsing bitbake.conf from the openembedded/conf/ dir Sep 14 18:16:24 it's likely using the more minimal one fromt he bitbake dir, which is fallback Sep 14 18:16:45 that's weird, it works well when I bitbake console-image Sep 14 18:17:17 if you can build without -b, you can build with -b. Sep 14 18:17:27 the configuration parsing is exactly the same Sep 14 18:18:01 nop, getting the same error Sep 14 18:18:05 * SeldanB wonders why there is no tutorial on this Sep 14 18:19:11 ok, how am I suppose to create and build a simple hello world program? Sep 14 18:19:32 where should I put the .bb file, and where should I put the source files? Sep 14 18:19:56 read and follow GettingStarted, create a recipe, and ensure the recipe is included in BBFILES. Sep 14 18:20:26 hmm Sep 14 18:20:32 SRC_URI is used to fetch the sources, generally. if you want to build in an existing source tree, you can use the srctree bbclass. Sep 14 18:20:57 kergoth: I m a newbie, so bare with me Sep 14 18:21:23 there are plenty of example recipes to go from Sep 14 18:21:46 can I add it like this: export BBFILES="$OE_HOME/openembedded/recipes/*/*.bb:$OE_HOME/test/*.bb" ? Sep 14 18:21:51 http://thread.gmane.org/gmane.comp.handhelds.openembedded/26156 shows how you can build within an existing source tree, like for development, rather than doing the fetch/unpack/patch idiom Sep 14 18:22:00 SeldanB: what is $OE_HOME in your setup Sep 14 18:22:13 SeldanB: yep, that hsould be fine, assuming its $OE_HOME/test/hello.bb Sep 14 18:22:19 (or similar) Sep 14 18:22:30 indeed Sep 14 18:22:34 let me try it Sep 14 18:23:42 still the same problem Sep 14 18:25:23 hmm, I m following gumstix tutorial, but it doesn't indicate anything about the directory structure Sep 14 18:25:45 again, that error has nothing to do with recipes, it indicates you aren't using the OE bitbake.conf, which indicates you aren't set up correctly, and it will occur whether or not you're using -b Sep 14 18:25:54 once you add it to bbfiles, just run bitbake hello, no -b Sep 14 18:30:11 I doubt i screwed something Sep 14 18:30:28 everything is compiling fine for existing recipes Sep 14 18:31:37 well, again, openembedded/conf/bitbake.conf defines CACHE. If it isn't getting CACHE, it isn't loading that bitbake.conf. Sep 14 18:31:41 it's that simple Sep 14 18:32:09 lemme try that Sep 14 18:32:37 |list Sep 14 18:38:47 kergoth: you seem to be right, i defined and yet it's claiming it Sep 14 18:38:53 how can I setup it correctly? Sep 14 18:38:58 did you forget to export BBPATH? Sep 14 18:39:05 i'm pretty sure gettingstarted tells you exactly what to do. Sep 14 18:41:36 SeldanB: paste your local.conf or other scripts that you use to do the setup somewhere Sep 14 18:41:49 ok Sep 14 18:44:03 http://www.pasteall.org/7849 Sep 14 18:44:40 03Chris Larson 07master * rafd1840d9d 10bitbake.git/bin/bitbake: Sep 14 18:44:40 Only print python exception tracebacks if debugging is enabled. Sep 14 18:44:40 Uses sys.excepthook to replace the toplevel exception handler with a version Sep 14 18:44:40 that obeys the debug level of the 'default' messaging domain. A non-zero Sep 14 18:44:41 value there will result in displaying the full traceback. Sep 14 18:44:43 Signed-off-by: Chris Larson Sep 14 18:45:42 kergoth: and here is hello.bb http://www.pasteall.org/7850 Sep 14 18:46:22 SeldanB: you aren't setting BBPATH in the first paste at all. Sep 14 18:47:09 kergoth: and profile.sh : http://www.pasteall.org/7851 Sep 14 18:47:13 where everything is set Sep 14 18:50:48 kergoth: anything wrong there? Sep 14 18:53:06 nothing obvious. we don't have enough information to judge what you're doing wrong here. what's in $OE_HOME, $OE_HOME/beagleboard/, and $OE_HOME/beagleboard/beagleboard/? Sep 14 18:55:05 $OE_HOME is where openembedded is Sep 14 18:55:16 beagleboad is where local.conf is Sep 14 18:55:26 and where profile.sh is Sep 14 18:57:45 SeldanB: what you pasted is your local.conf I suppose is that right Sep 14 18:58:11 khem: yeah Sep 14 18:58:20 profile.sh and local.conf Sep 14 18:58:44 remove the export stuff from local.conf and put it in profile.sh Sep 14 19:00:18 hmm Sep 14 19:00:25 I think I know what is the problem Sep 14 19:00:28 SeldanB: and use {} around shell vars Sep 14 19:00:34 it works now Sep 14 19:00:46 like dont use $VAR but ${VAR} Sep 14 19:00:52 ok Sep 14 19:00:58 what's the difference? Sep 14 19:01:20 03Thomas Zimmermann 07shr/import * re81fe83aa0 10openembedded.git/ (3 files in 3 dirs): Update Midori to 0.1.10 Sep 14 19:01:20 03Sebastian Krzyszkowiak 07shr/import * r9a33a587dc 10openembedded.git/recipes/connman/mokonnect_svn.bb: mokonnect: add connman-plugin-wifi to RDEPENDS Sep 14 19:01:21 03Martin.Jansa 07shr/import * r010e46182d 10openembedded.git/ (2 files in 2 dirs): Advancedcaching bbfiles Sep 14 19:01:24 03Sebastian Krzyszkowiak 07shr/import * red5bace2cc 10openembedded.git/recipes/tasks/task-shr-feed.bb: task-shr-feed: add pisi to feed Sep 14 19:01:35 03Frederik Sdun 07shr/import * r061a7dd549 10openembedded.git/recipes/gstreamer/gst-plugins-bad_0.10.6.bb: (log message trimmed) Sep 14 19:01:35 add souphttpsrc to gst-plugins-bad Sep 14 19:01:35 This patch adds the http src based on soup. Sep 14 19:01:35 are you interested in the neohttpsrc? Sep 14 19:01:36 I'm trying to provide a patch for mmssrc, too. Sep 14 19:01:38 I'll need this in the near future for fsomusicd Sep 14 19:01:40 Regards, Frederik Sep 14 19:02:47 SeldanB: just safe when you use variables in cancatenations etc. Sep 14 19:03:54 ok Sep 14 19:06:29 SeldanB: what was the problem Sep 14 19:06:37 did u get it working ? Sep 14 19:06:54 i m not sure if it bash Sep 14 19:07:21 but all env variables that were declared inside the script didn't make it when the script finished running Sep 14 19:07:40 i.e. once my script finish $OE_HOME is empty Sep 14 19:07:46 source it Sep 14 19:07:52 source profile.sh Sep 14 19:07:57 that's what I did Sep 14 19:07:59 and it worked Sep 14 19:08:18 thx khem and kergoth Sep 14 19:08:52 you can also put MACHINE and DISTRO vars in profile.sh if you do multi machine multi distro builds Sep 14 19:09:31 you can avoid parsing everytime you change a little think local.conf bitbake has to reparse whole stuff Sep 14 19:12:47 jo Sep 14 19:13:07 hmm, now it seems it doesn't build a release version, only a debug version Sep 14 19:15:27 what do you mean? Sep 14 19:15:40 the packaging phase rips out the debug info from the binary and puts it into a -dbg package Sep 14 19:15:45 the main package won't have the debug info Sep 14 19:15:56 i got a hello-dbg and hello-dev, but no hello.ipk! Sep 14 19:16:00 this way you can install the debug info later if at some point you need to debug the application Sep 14 19:16:06 then you probably need to add a do_install task Sep 14 19:16:08 to install hello Sep 14 19:16:18 install -m 0755 ${S}/hello ${D}${bindir}/hello or something Sep 14 19:16:20 seems some didnt read the manual Sep 14 19:16:31 do_install () { install -d ${D}${bindir}/ Sep 14 19:16:31 install -m 0755 ${S}/hello ${D}${bindir}/ Sep 14 19:16:31 } Sep 14 19:16:37 already there Sep 14 19:16:38 To the maintainer of the midori recipe: please have a look at the midori 0.1.10 recipe in shr/import http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/gtk-webcore/midori_0.1.10.bb?h=shr%2Fimport i think that's a nicer recipe Sep 14 19:16:59 Heinervdm there is no maintainer Sep 14 19:17:06 if it was installed into ${D}, it would have created a hello package. Sep 14 19:17:24 woglinde: but someone updated it recently Sep 14 19:17:29 kergoth maybee is local.conf hasnt inherit ipkg or so Sep 14 19:17:39 Heinervdm request it on the ml Sep 14 19:17:40 hej ust said it created a hello-dbg Sep 14 19:17:46 ask the shr people to update in dev Sep 14 19:17:54 which means he must be inheriting package at least Sep 14 19:17:56 kergoth oh Sep 14 19:19:09 hmm, i have this: NOTE: Not creating empty archive for hello-1.0-r0.1 Sep 14 19:19:09 kergoth: is there something wrong in http://www.pasteall.org/7850 ? Sep 14 19:19:36 you broke packaging. Sep 14 19:19:41 you're only including ${bindir}/main Sep 14 19:19:44 when you compile to hello, not main Sep 14 19:19:50 remove the overridden FILES Sep 14 19:20:23 *g* Sep 14 19:21:24 vwool_, what now? :) Sep 14 19:21:25 ga Sep 14 19:21:36 tartarus? Sep 14 19:22:00 ga, wrong channel :) Sep 14 19:22:49 kergoth: I want it to be with the rest of ipk Sep 14 19:22:54 if I do that, I don't have Sep 14 19:22:55 and? Sep 14 19:22:56 it Sep 14 19:22:59 yes, you do Sep 14 19:23:07 03Chris Larson 07master * r3adb0d1c23 10bitbake.git/lib/bb/cache.py: (log message trimmed) Sep 14 19:23:07 cache: only invalidate for non-existent depends if they used to exist. Sep 14 19:23:07 Previously, if a file listed in the cached __depends did not exist, it would Sep 14 19:23:07 always invalidate the cache. Now it only does so if the cached version Sep 14 19:23:07 existed, and the current does not. In this way, we can support storing Sep 14 19:23:07 ${bindir} is automatically included in the ${PN} package Sep 14 19:23:10 entries in __depends for files which may or may not exist, and ensure that Sep 14 19:23:11 if you'd bothered to try it, you'd know Sep 14 19:23:12 creating such a file results in cache invalidation. Specifically, this is for Sep 14 19:23:19 i did Sep 14 19:23:21 remove FILES_${PN}, then bitbake -c clean hello; bitbake hello Sep 14 19:23:27 then you screwed something else up Sep 14 19:23:39 * SeldanB feels stupid Sep 14 19:23:51 man this is surely not for the faint hearted Sep 14 19:24:06 re Sep 14 19:24:14 reading the bitbake and OE manuals makes it much easier Sep 14 19:24:41 if you'd read bitbake.conf, you'd see the default FILES_${PN} already includes the files in bindir Sep 14 19:24:47 SeldanB: its ok to start with but dont be consistent :) Sep 14 19:25:07 hoi khem Sep 14 19:25:10 hi florian Sep 14 19:25:16 servus :) Sep 14 19:25:33 khem good you are not saying "Gruess Gott" Sep 14 19:25:41 though I lived in South Germany I know couple of greetings Sep 14 19:25:47 hehe Sep 14 19:26:13 that was more common in my part Sep 14 19:27:43 meh, i should really try to organize the differences between 1.8 and master, the branches have been separate for too long Sep 14 19:27:59 kergoth yes yes yes Sep 14 19:28:15 it's so painful though, git sucks for long lived branches with cherry picks in both directions Sep 14 19:28:16 kergoth: yeah I would beg RP to forward port the parsing improvements to master Sep 14 19:28:20 :| Sep 14 19:28:42 oh I mean speed improvements Sep 14 19:29:03 I thought I had? Sep 14 19:29:30 * kergoth shrugs, perhaps, it doesn't seem very clear what's in master that isn't in 1.8 Sep 14 19:29:49 RP: 1.8 parses faster for me Sep 14 19:29:51 guess the changelog is probably the only reference, but i don't think it's been consistently updated Sep 14 19:29:54 hrm Sep 14 19:30:07 khem: Right, the difference is the UI changes Sep 14 19:30:17 * kergoth should play with a git-notes based cherry-pick tracker or something Sep 14 19:30:29 kergoth: It should just be the UI split thats the difference Sep 14 19:30:35 ah, right Sep 14 19:31:10 Most files are interchangable between the two Sep 14 19:31:17 with obvious exceptions Sep 14 19:31:23 * kergoth nods Sep 14 19:31:59 We should perhaps backport some cosmetic changes to make the two more similar... Sep 14 19:32:04 mickeyl: around ? Sep 14 19:32:23 The speed problem is a real one though and something I don't have a good solution for :/ Sep 14 19:32:26 i think either we should try to bring them together, or we should move the ui split to a 2.0 branch and let master contain the other non-ui changes that aren't bugfixes Sep 14 19:32:33 khem: Are you on a multicore system? Sep 14 19:32:41 (there are some, at least, i just pushed 2 today) Sep 14 19:32:57 RP: I have T61 Sep 14 19:33:02 its a core 2 duo Sep 14 19:33:14 khem: Right, mutlicore really helps with bitbake master Sep 14 19:33:26 khem: My laptop is a T61 too :) Sep 14 19:33:47 might want to think about giving BB_NUMBER_THREADS a /proc/cpuinfo based default? Sep 14 19:33:54 khem: Are you interested in canadian sdk generation with OE? Sep 14 19:34:07 RP: I thought about it many times Sep 14 19:34:20 khem: I'm some way to making it work here... Sep 14 19:34:56 RP: So it would be a SDK built on ubuntu which would run on solaris and generate code for arm ? Sep 14 19:34:59 kergoth: The reason it helps isn't due to changing BB_NUMBER_THREADS, just that the IPC between client and server works better with two cpus Sep 14 19:35:13 ahh Sep 14 19:35:20 cool Sep 14 19:35:40 khem: in theory, yes. I'm concentrating on built on 64 running on 32 generating code for X :) Sep 14 19:35:58 khem: but the model should be extensible Sep 14 19:36:12 RP: amd64 -> i386 ->arm Sep 14 19:36:25 e.g. Sep 14 19:36:41 yeah that should be good way to start with Sep 14 19:36:58 khem: It'll be a good first step Sep 14 19:37:11 khem: I looked at the existing canadian stuff and ran away screaming :/ Sep 14 19:37:24 lol Sep 14 19:37:28 * khem visualizes Sep 14 19:37:42 khem: I'm trying to use BBCLASSEXTEND to help Sep 14 19:38:01 yeah Sep 14 19:38:18 RP: your stuff is in poky right ? Sep 14 19:38:33 khem: It will be, I've not pushed much yet Sep 14 19:38:37 * khem should look at it Sep 14 19:38:53 khem: The trouble is I'm having to rip up all the current -sdk stuff there Sep 14 19:39:01 I should make a branch Sep 14 19:39:49 khem: I made the glibc staging change btw, seems to work ok so far Sep 14 19:39:58 RP: cool, Sep 14 19:40:14 RP: I must admit that BBCLASSEXTEND will be confusing Sep 14 19:40:20 initially Sep 14 19:40:45 khem: yes and no :) Sep 14 19:40:57 khem: It sounds scary, in practise it works quite neatly Sep 14 19:41:12 Particularly now I'm getting the hang of the core classes Sep 14 19:41:29 sdk.bbclass was a rather nasty incarnation and deserves to die :/ Sep 14 19:42:05 * khem agrees Sep 14 19:45:48 may be we should always use SDK even in internal builds Sep 14 19:46:41 for internal toolchains Sep 14 19:47:14 khem: Won't work since the layouts are different Sep 14 19:47:32 RP: SDKs can be relocatable Sep 14 19:48:02 why do we need different layout under the sysroot for SDK Sep 14 19:49:48 kergoth: Can we have a functionality in bitbake/opkg like obsoleting packages in favor of others ? Sep 14 19:49:56 waht do you mean? Sep 14 19:50:08 e.g. I want to obsolete gcc-cross-initial with gcc-cross Sep 14 19:50:32 so if we find that gcc-cross is built then we punt out gcc-cross-initial from picture Sep 14 19:50:37 because we know we do not need it Sep 14 19:50:38 03Klaus Kurzmann 07shr/import * r4b7ec43d7b 10openembedded.git/recipes/telepathy/apathy_bzr.bb: Sep 14 19:50:38 apathy: new recipe Sep 14 19:50:38 Signed-off-by: Klaus Kurzmann Sep 14 19:52:25 khem: I don't mean the sysroot is different, I mean the SDKPATH Sep 14 19:52:47 khem: As you say, the toolchain should be relocatable but in practise it doesn't work like that :/ Sep 14 19:53:13 RP: we should try to make it Sep 14 19:53:33 khem: For example your SDK doesn't use includedir=/usr/include :/ Sep 14 19:54:12 khem: Whether we can correct some of this from the commandline, I don't know, I'm not proficient enough with gcc. I would love to see it though Sep 14 19:55:28 yeah that crap has to be sorted out Sep 14 19:56:04 I think if we can say that non sysrooted gcc are obsolete then we can march on the relocatabale path Sep 14 19:56:45 khem: I vote for removing them... Sep 14 19:57:00 OE.dev needs to evolve... Sep 14 19:57:09 yes I agree Sep 14 19:57:49 If people need the old gcc's they can use stable Sep 14 19:57:53 I think we can ask generally on mailing list if there is a need to keep supporting older compilers for some reason Sep 14 19:58:09 khem: agreed Sep 14 19:58:21 how old are the non sysrooted compilers? Sep 14 19:58:31 like 3.4 Sep 14 19:58:48 and below Sep 14 19:58:54 Crofton|work: gcc 3.3 doesn't work and 3.4 has bugs so I'm told Sep 14 19:59:00 what is above 3.4? Sep 14 19:59:02 4.x? Sep 14 19:59:04 4.x Sep 14 19:59:04 4.1 was where it was reliably upstream Sep 14 19:59:28 alot of stuff still uses 3.4 I suspect Sep 14 19:59:57 sysroot worked for me with 3.4 Sep 14 20:00:57 RP: yes it works with 3.4.5 e.g. Sep 14 20:01:13 and with some backports Sep 14 20:02:18 I can see how bad 3.4.x are in OE when it comes to sysrooting Sep 14 20:02:33 khem: I'm sure I've had them working Sep 14 20:02:43 RP: nice Sep 14 20:03:31 gah Sep 14 20:03:41 I may mixing up 3.4 and 4.3 :) Sep 14 20:04:23 Crofton|work: bit of a difference :) Sep 14 20:05:13 yeah Sep 14 20:05:16 ignore me Sep 14 20:05:27 I was confused Sep 14 20:05:51 so we have 3.4.3 and 3.4.4 it seems Sep 14 20:06:11 mingw has 3.4.5 Sep 14 20:06:20 and there is a recipe for gcc-native 3.4.6 Sep 14 20:06:31 I added that for qemu-native Sep 14 20:06:48 As far as sysroot goes, ignore it ;-) Sep 14 20:07:05 right, ok it does not look that bad Sep 14 20:07:14 3.4.3 and 3.4.4 were the arm toolchauns of choice back in the day... Sep 14 20:08:07 yes Sep 14 20:08:28 RP: so we can try to include 3.4.3 and 3.4.4 in the stride Sep 14 20:09:02 khem: sounds good Sep 14 20:09:20 and may be delete the older recipes so no body accidently use it even Sep 14 20:09:42 khem: The fact nobody has upgraded 3.4.3 and 3.4.4 to 3.4.6 is a sign there isn't much use Sep 14 20:10:04 yes Sep 14 20:16:47 hmm, took git-cherry as a starting point, then removed all teh commits listed there for which other commits exist on the other branch with the exact same log message Sep 14 20:16:51 leaves 141 unique commits on master Sep 14 20:17:10 oh Sep 14 20:18:02 * kergoth looks them over Sep 14 20:18:08 hi gnutoo Sep 14 20:34:18 03Leon Woestenberg 07org.openembedded.dev * r757510da73 10openembedded.git/ (5 files in 4 dirs): Sep 14 20:34:18 openrd-base: Support for Marvell Kirkwood ARM based OpenRD-Base board. Sep 14 20:34:18 Signed-off-by: Leon Woestenberg Sep 14 20:38:28 * kergoth tries to get a handle on this latest_revision / srcrev stuff Sep 14 20:40:34 horray another libdb version Sep 14 20:52:32 woglinde, hi Sep 14 20:58:00 kergoth: Mostly UI? Sep 14 21:00:39 yeah, mostly. some other bits, but nothing major, thankfully Sep 14 21:00:58 well, i hvent reviewed it all yet, but you're right, UI is the primary bit Sep 14 21:01:36 kergoth: cool :) Sep 14 21:02:05