**** BEGIN LOGGING AT Fri Jun 17 02:59:56 2011 Jun 17 09:01:20 morning all Jun 17 09:03:02 hi, bluelightning Jun 17 12:07:15 khem: hello Jun 17 12:07:36 khem: it seems libstdc++-nativesdk is not buildable ;-) Jun 17 12:14:15 khem: am I giving the wrong path for it? Jun 17 12:15:23 humm it does exist Jun 17 12:19:26 I have made a new image file derived from console-image.bb and put it under build/recipes/images/ my BBPATH specified both this path and the openembedded path, but bitbake is complaining when pasrsing my new file that it cant find the required console-base-image.bb. I thought it shold still pick this up from the openembedded tree, is this not the case? Jun 17 12:20:39 mangomake: with "require" or "include" the path to the file must be relative to the .bb it appears in... so if the file is not in the current directory you need to specify a relative path Jun 17 12:20:59 bluelightning, ok thanks Jun 17 12:21:01 it's a little bit annoying sometimes Jun 17 12:25:09 The console image is almost perfect for my requirements - i just want to change some of the default settings and add a few packages, so i have made a copy of console-image.bb in my own tree and a copy of a few other .bb's (netbase and usb-gadget for example - in fact only a copy of some of there files (not sure if that will work)) in order to make my won customised image Jun 17 12:25:50 mangomake: copying the console image is probably ok; for some image customisations you might be able to get away with a bbappend Jun 17 12:26:08 for normal recipes though bbappend is usually the better option Jun 17 12:26:37 mangomake: presumably for netbase you are just changing /etc/network/interfaces or similar? Jun 17 12:27:42 I need to install custom /etc/network/interfaces and /etc/default/usb-gadget - i coppied the respective src files from the openembedded tree into my tree and edited as required, will it find those or do i also need to copy the .bb files that use them? Jun 17 12:28:08 even if left unedited Jun 17 12:28:25 it won't, but rather than copying the bb's you should definitely use bbappend files for this Jun 17 12:28:37 http://sakrah.homelinux.org/blog/2010/11/bblayers-bbappend/ Jun 17 12:28:46 ok, ill look at that Jun 17 12:28:52 yes, have a look at that link, thx ant_work Jun 17 12:28:55 I re-read it yesterday :) Jun 17 12:29:05 preparing... Jun 17 12:29:42 only thing I would advise different from khem's article there would be use the following in your bbappends for the file path issue: Jun 17 12:30:00 FILESEXTRAPATHS_prepend := "${THISDIR}/{$PN}:" Jun 17 12:30:22 ah, interesting Jun 17 12:30:33 it's most likely to continue functioning if you move to more than two layers Jun 17 12:30:52 whoops $ typo there Jun 17 12:31:02 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" Jun 17 12:31:16 related to this, FILESPATHPKG is not in oe-core, isn't? Jun 17 12:31:50 I don't think it works like it used to, that I can say Jun 17 12:31:55 I saw commits like: +#FILESPATHPKG =. "mesa-${PV}:mesa:" Jun 17 12:31:56 +FILESPATH =. "${FILE_DIRNAME}/mesa:${FILE_DIRNAME}/mesa-${PV}:" Jun 17 12:32:20 easy enough to circumvent Jun 17 12:32:21 bluelightning: you where having a build failure on qt Jun 17 12:32:27 bluelightning: in nativesdk, right? Jun 17 12:32:31 otavio: qt4-tools-nativesdk yes Jun 17 12:32:49 bluelightning: was it due not finding c++ headers? Jun 17 12:33:07 bluelightning, ant_work, thanks - this looks like exactly what i need :) Jun 17 12:33:20 otavio: no, a const conversion error Jun 17 12:34:09 otavio: I did have some annoying problems with missing standard c++ headers when I was working on the qt4-tools-nativesdk recipe originally though Jun 17 12:34:25 otavio: I worked around it by adding those paths with -I but it's somewhat hackish Jun 17 12:34:40 if you have a look at the current recipe in oe-core you can see it Jun 17 12:34:47 bluelightning: it seems to be the error is on gcc-crosssdk somewhere Jun 17 12:35:02 bluelightning: because it ought to have it on it Jun 17 12:36:23 hmm, I would have to agree it should pick those up automatically Jun 17 12:38:50 bluelightning: yes; it works doing it but it seems wrong imo Jun 17 12:38:55 03Koen Kooi 07org.openembedded.dev * r8e591c9bc0 10openembedded.git/conf/machine/include/omap3.inc: omap3: bump MACHINE_KERNEL_PR Jun 17 12:39:04 bluelightning: the g++ is not finding those without forcing it Jun 17 12:39:15 bluelightning: crosssdk g++ I meant Jun 17 12:39:53 otavio: yes, if there's a better way to fix it then we should definitely use it Jun 17 12:40:24 I've got pulled back to some other work at the moment, is there any chance you could look into it? Jun 17 12:40:34 bluelightning: now we have cmake, cmake-native and cmake-nativesdk :-D Jun 17 12:40:46 bluelightning: the g++ problem? Jun 17 12:40:47 otavio: cool, well done :) Jun 17 12:41:11 yeah, particularly if it's causing you problems with another -nativesdk recipe Jun 17 12:41:39 bluelightning: I am not skilled enough for it; I will talk to khem to see if he can check it to us. Jun 17 12:41:47 khem: ^ Jun 17 12:42:11 otavio: ok Jun 17 12:53:22 bluelightning: URL of that list of layers in the wiki offhand? Jun 17 12:53:39 ant_work: http://www.openembedded.org/index.php/LayerIndex Jun 17 12:53:47 thx Jun 17 12:53:48 we really need somewhere to link it from I guess Jun 17 13:03:11 hm.. just browsing quickly I don't see a lot of recipes. which images did you build? Jun 17 13:04:03 I'd be happy with a shiny console-image at the beginning fwiw Jun 17 13:09:26 I think angstrom still has a bunch of shiny images. Jun 17 13:11:40 ant_work, did u stumble accross this os.path.dirname(os.path.dirname(d.getVar(‘FILE’, True))) ? Jun 17 13:11:42 LayerIndex, nice idea Jun 17 13:11:56 I tried the layers example from the link you posted Jun 17 13:12:26 its from a python traceback Jun 17 13:13:08 iirc this has been solved. I didn't build yet oe-core, though Jun 17 13:14:27 now, ideally, what we want is an interactive layer inspector that can tell you which layer has a given recipe in Jun 17 13:14:41 i think it was due to funny quuote from copy/paste of of website Jun 17 13:14:42 and which layer(s) contain competing recipes that are likely to sabotage your efforts :-} Jun 17 13:15:41 * pb_ slightly annoyed to discover this morning that meta-oe contains a joke version of json-glib which overrides the one in oe-core Jun 17 13:36:00 I'm a bit dubiou about the meta-openembedded/meta-oe stuff Jun 17 13:37:40 why this meta-oe sublevel ? Jun 17 13:39:10 to peek at single parts of the oe metadata not in core? Jun 17 13:39:47 re layers, its interesting to think about the Linux kernel which has kept a large monolithic code base in one repo. What in the OE world makes it a different problem that benefits from layers? I'm definitely not opposed to layers, but just one of the tracks my mind went down recently. Jun 17 13:42:52 cbrake: well, arguably, one problem that the kernel has in spades is splinter trees caused by different vendors wanting to do their own bsp customisations Jun 17 13:43:34 so part of the motivation for layers is that it allows you to have a common, shared set of base metadata (which is more or less what oe-core is meant to be) and then apply your own additions or modifications on top of it. Jun 17 13:44:28 cbrake: I've had simillar thoughts :-) Jun 17 13:45:38 cbrake: the new approach adds lots of new ways to confuse newbies Jun 17 13:45:53 sakoman_: the old approach had plenty :-) Jun 17 13:46:52 cbrake: indeed, now there are even more! I am glad I won't be doing oe-core user support :-) Jun 17 13:47:08 I guess in once sense, anyone building a product typically created an overlay anyway with their stuff, so if those mechanisms get better, then that will be a plus Jun 17 13:47:37 cbrake: I typically used a git branch per product Jun 17 13:47:51 sakoman_: more like kernel dev Jun 17 13:47:54 cbrake: yes Jun 17 13:48:13 yeah. and it is nice to be able to control what sets of recipes are enabled; for example, if I know I don't want qt on my platform, I can just exclude the qt layers and be sure that it won't be dragged in accidentally by some rogue dependency Jun 17 13:48:37 pb_: yes, I understand the benefits Jun 17 13:49:22 I fear the complexity will make the already steep oe learning curve even worse Jun 17 13:49:47 * pb_ stabs busybox Jun 17 13:50:14 stupid privilege dropping code Jun 17 13:50:21 morning Jun 17 13:50:25 pb_: heh, whats up with it? Jun 17 13:50:27 for some reason it has decided to drop root privs even if invoked as /bin/sh when you really are root Jun 17 13:50:39 i was just wondering why we still use tinylogin actually, since its' not maintained outside of busybox anymore Jun 17 13:50:43 heh Jun 17 13:50:45 weird Jun 17 13:50:48 so now, every time I start a shell, I get my privs revoked Jun 17 13:50:52 which sucks for obvious reasons Jun 17 13:50:53 pb_: heh, you see, no-risks :) Jun 17 13:51:03 well yeah, I guess I should be protected from myself Jun 17 13:51:26 you were so concerned about tinylogin ;) Jun 17 13:51:38 yeah, indeed Jun 17 13:52:13 wre tunylogin - seem to be stuck with des passwords - and thus only 8 char effective passwords Jun 17 13:52:32 root Jun 17 13:56:24 sakoman_: do you think it's about having layer functionality at all, or how we have implemented layers? could we improve our layer implementation? Jun 17 13:58:17 I guess the thing that strikes me as obviously improveable is the current rather-arbitrary split between oe-core and meta-oe. Jun 17 13:58:43 In particular, I hate that they have competing versions of the same recipes. Jun 17 13:59:03 pb_: yes that's not good... it can only get worse over time if not kept in check Jun 17 13:59:44 the question is why are there competing versions in meta-oe and whose job is it to clean those up Jun 17 14:00:25 I think at least part of that problem is that nobody seems able to define what actually belongs in oe-core. Jun 17 14:01:14 indeed... I think the TSC (or someone at least) will need to establish that pretty soon Jun 17 14:02:44 in the particular case of json-glib, what seems to have happened was that it was imported into meta-oe and oe-core almost simultaneously, but independently and at different versions. Jun 17 14:03:12 Joshua Lock added 0.12.2 to oe-core on April 15, but Martin Jansa had already added 0.10.4 to meta-oe a few days previously Jun 17 14:03:38 hmm, so we could improve communication Jun 17 14:03:53 in the case of uclibc, there seems to be a deliberate effort to do new versions in meta-oe first and then migrate them to oe-core later. Jun 17 14:05:01 pb_: I think uclibc has been a special case because (AFAIK) it was not well-used or recently tested in poky which then became oe-core Jun 17 14:05:28 if things are getting pushed down from meta-oe, I think that's how things are supposed to work Jun 17 14:06:42 but if we stay with (apparently) unnecessary duplication or create even more, that's not Jun 17 14:07:00 yeah Jun 17 14:07:47 I must say that the idea of having to push changes into meta-oe first and then have a separate battle to get them into oe-core is not necessarily one which fills me with joyous anticipation. Jun 17 14:08:14 so I am not altogether keen on the idea of having meta-oe be a generalised staging area for stuff that is intended to go into oe-core. but, if the uclibc case was a one-off, that's fine. Jun 17 14:08:41 I certainly wouldn't advocate the "staging" idea and I don't think anyone else considers things that way Jun 17 14:09:07 ah, okay. I guess I misunderstood what you wrote above about stuff getting pushed down. Jun 17 14:10:05 pb_: see udev Jun 17 14:10:20 pb_: we're all getting these things clear in our mind, myself included :) Jun 17 14:10:32 (still getting) Jun 17 14:11:21 I think if we continue to call out situations where things haven't gone ideally then people will start to work out the best approaches Jun 17 14:11:57 I guess the other obvious example we've seen recently has been connman. I'm not quite sure what has gone on there but it seems that oe-core and meta-oe each have their own recipes for it. Jun 17 14:12:22 again, why is the structure of meta-openembedded and openembedded-core different ? Jun 17 14:12:43 different how? Jun 17 14:13:01 meta-oe is a dir Jun 17 14:13:12 so's oe-core, right? Jun 17 14:13:25 yeah, it's meta Jun 17 14:13:27 in oe-core Jun 17 14:14:06 pb_: I think perhaps some people from the Yocto side don't pay enough attention to what's going on in meta-oe, if that's the case we should try to encourage them to do so Jun 17 14:14:54 there's a lot more in meta-oe now than there used to be, that might have something to do with it Jun 17 14:15:00 yeah, could be Jun 17 14:15:08 I must admit I don't pay all that much attention to meta-oe myself either Jun 17 14:15:59 for meta-oe, there's also a question in my mind as to what should be there as well as what should be in oe-core... clearly we can't have it balloon out to OE-dev size Jun 17 14:16:14 sorry again, and what's teh purpose of meta-efl, meta-gnome, meta-gpe there ? Jun 17 14:16:29 those are the layers, I think Jun 17 14:16:38 ant_work: splitting those various components out into their own layers Jun 17 14:17:15 what for? Jun 17 14:17:26 to have separate maintainers? Jun 17 14:17:40 ant_work: if I'm building an EFL-based distro, I might not want or care about GPE Jun 17 14:17:41 for example Jun 17 14:18:11 indeed, or the converse. the place that this breaks down, though, which we don't seem to have an entirely convincing solution for yet, is cross-platform middleware libraries. Jun 17 14:18:29 well, then is the Gnome/KDE discussion Jun 17 14:18:56 for example, oe-core has a webkit recipe in the sato ghetto, but it is gtk+ only. it would be a bit sad if we then ended up with a completely separate recipe in meta-qpe for the qt webkit, and so on. Jun 17 14:19:57 pb_: well, for webkit... webkit seems to be forked out quite a lot Jun 17 14:20:14 pb_: qtwebkit is its own fork for example Jun 17 14:20:37 yeah, but I think they still have enough in common that they could share quite a lot of recipe bits. Jun 17 14:20:52 maybe... even if not, I get what you're saying in the general case Jun 17 14:22:04 I don't really see why the sato stuff belongs in oe-core at all, personally, but *shrug* Jun 17 14:22:27 pb_: as far I can see it, the risk is like what happens around e.g. for Gentoo: official repo are a bit outdated, new fresh stuff only in other overlays... Jun 17 14:22:34 yeah. I know what the argument is for having it there but it still seems like a bad idea to me Jun 17 14:22:41 kergoth: it's so we have some way to test the libs... but FWIW I can see a good case for it not being there Jun 17 14:22:50 kergoth: http://paste.debian.net/120167/ is this a known problem with bitbake master? Jun 17 14:23:34 certainly in the long term, I would like to see all that sato stuff go away (from oe-core) to be replaced by something more resembling an actual testsuite Jun 17 14:24:03 pb_: that would make sense to me too Jun 17 14:24:08 right now it just seems to be a random collection of someone's favourite apps and, while I can see that this does at least give you something to test, it doesn't seem a very good way of solving the problem Jun 17 14:24:15 ideally a benchmark suite Jun 17 14:24:34 libs like gtk already have their own demo programs, and clutter has its toys, so that would be a place to start with some testcases Jun 17 14:24:39 and yeah, benchmarks Jun 17 14:25:23 blindvt`: that doesn't look like a problem with master, it looks like nativesdk calling explode_deps with None as an argument Jun 17 14:25:30 Don't Do That Jun 17 14:25:43 but i haven't investigated very closely, going just by your pastebin Jun 17 14:26:17 kergoth: I had a quick look, it wasn't immediately obvious to me what was going wrong... it's not limited to nativesdk AFAIK Jun 17 14:26:45 * kergoth shrugs, its that or it was likely introduced by one of richard's recent bitbake changes, try a bisect if its reproducible Jun 17 14:27:40 it was definitely caused by a recent change yes Jun 17 14:28:31 * blindvt` just sticks a return r if not s somewhere near the top of explode_deps locally for now Jun 17 14:34:13 * bluelightning wonders about changing -b to --debug-recipe-yes-i-know-its-only-for-debugging Jun 17 14:34:39 * ant_work will not pull latest bitbake changes :o Jun 17 14:57:32 does bblayers need a newer version of bitbake than 1.10.2 ? I can't get it to use my alternative interfaces file Jun 17 14:59:36 mangomake: one thing you can look at is "bitbake -e netbase | grep FILESPATH" to see if it's including the directory where your replacement file is located Jun 17 15:00:27 holy caramba! some amount of output from that Jun 17 15:00:45 ant_work: regarding your gentoo fear, yeah, I am a bit concerned about that too. I think this is one reason why we need a strong policy about which recipes belong where. Jun 17 15:01:32 mangomake: yeah, it looks in a lot of places for files Jun 17 15:02:01 plus there's all sorts of references to FILESPATH within the environment, you can ignore those Jun 17 15:04:32 bluelightning, im lookin in the FILESPATH statement right? Jun 17 15:04:39 mangomake: yes Jun 17 15:04:46 it doesnt appear in there - but it does appear within som eof the other statements Jun 17 15:04:58 hmm Jun 17 15:05:11 mangomake: could you pastebin your bbappend file? Jun 17 15:05:17 will do Jun 17 15:05:59 http://pastebin.com/SztfnH1M Jun 17 15:06:12 pb_: ah, I forgot to beat that strange 'statical linked using shared libs' binares Jun 17 15:06:37 I've googled and this sounded exhoteric Jun 17 15:08:09 fwiw only the binaries built within klibc compilation are so strange. other recipes are producing full-static linkings Jun 17 15:08:13 mangomake: hmm, looks like you copied my first typo'd example... in the last part move the $ outside the braces (i.e. ${PN} rather than {$PN}) Jun 17 15:08:37 bluelightning, i noticed the variable im prepending to is FILESEXTRAPATHS, but grepping for that yields no result Jun 17 15:08:42 ah sorry - will try that Jun 17 15:09:16 somethign so simple! Jun 17 15:09:25 pb_ somehow there must be a bug in the klibc recipe, maybe the staging patch touching the Makefile Jun 17 15:09:49 mangomake: well, hopefully that fixes it Jun 17 15:10:12 bluelightning, yup - looks prommising Jun 17 15:10:36 mangomake: oh, and your replacement file is in a "netbase" subdir right? Jun 17 15:10:43 yup Jun 17 15:10:47 ok good Jun 17 15:11:31 * ant_work noted the right example :p Jun 17 15:15:05 ant_work: yeah, very weird Jun 17 15:15:24 "static (shared libraries)" is just a contradiction in terms, I don't know what file is trying to say there. Jun 17 15:15:38 either the binary is static linked or it isn't, and if it uses shared libs it isn't static. Jun 17 15:16:08 bluelightning, should include my layer in the conf/local.conf BBPATH statement? By look of it the layer conf is supposed to do this or me Jun 17 15:16:45 mangomake: the layer.conf should handle that Jun 17 15:16:52 my rt-image.bb does not get found unless i include mylayer path in local.conf Jun 17 15:17:08 so i must have some error with my layers conf still Jun 17 15:17:34 mangomake: could you pastebin layer.conf and bblayers.conf ? Jun 17 15:17:41 will do Jun 17 15:17:44 thx Jun 17 15:17:54 otavio, hi Jun 17 15:18:10 pb_: I'll try to polish the recipe to not be too ashamed if by hazard it goes to oe-core ;) Jun 17 15:18:31 (khem will be sponsor) Jun 17 15:19:18 bluelightning, http://pastebin.com/6W0iP6bB Jun 17 15:20:31 otavio, since you introduced LZMA_COMPRESSION_LEVEL in 312b42bcf2cc9b11266ba497ade68e8ddabb3007, could you take a look at http://patches.openembedded.org/patch/6073/ Jun 17 15:21:25 GNUtoo: this broke zaurus in two ways: no -e for lzma, not enough memory for -9 on 32MB devices Jun 17 15:21:35 ok Jun 17 15:21:50 I do not want to workarround in machine Jun 17 15:21:55 I want to fix for everyone Jun 17 15:21:56 right Jun 17 15:22:42 the case of old 32MB devices can be handled there, though Jun 17 15:23:20 I don't know where to put the aggressive settings Jun 17 15:24:17 others are not inclined having those in bitbake.conf Jun 17 15:24:48 mangomake: hmm, well looking at layer.conf the only thing I can see that might be wrong is the last line Jun 17 15:24:52 I think it should be: Jun 17 15:24:58 BBFILE_PATTERN_pvt = "^${LAYERDIR}/" Jun 17 15:25:53 bluelightning, ok, trying that Jun 17 15:29:44 bluelightning, nope =- still won;t find it Jun 17 15:30:54 GNUtoo: is it for oe-core or oe? Jun 17 15:31:06 classic oe Jun 17 15:31:31 GNUtoo: I've been not using classic OE for a while. I did paste a patch long time ago to improve it a bit but noone merged it Jun 17 15:31:39 GNUtoo: I still have it aroundm, I think Jun 17 15:31:44 hmm, i can see mylayer in the BBPATH if i do bitbake -e Jun 17 15:32:27 mangomake: what about BBFILES, what does -e report for that? Jun 17 15:32:41 GNUtoo: Message-Id: <1306767263-29895-3-git-send-email-otavio@ossystems.com.br> Jun 17 15:33:04 GNUtoo: 30 of may Jun 17 15:33:22 GNUtoo: those were the patches I had pending for classic OE Jun 17 15:33:26 mope - its not there Jun 17 15:33:32 GNUtoo: most are already ported to oe-core but not all Jun 17 15:33:35 BBFILES="/home/rt/oe/openembedded/recipes/*/*.bb" Jun 17 15:33:37 * otavio lunch time Jun 17 15:33:54 is it .= vs +=? Jun 17 15:33:59 whats the difference? Jun 17 15:34:25 GNUtoo: http://patchwork.openembedded.org/patch/5077/ Jun 17 15:35:39 tried changing but had no effect Jun 17 15:35:57 ok, let me look Jun 17 15:37:49 we have to change linux-kexecboot.inc to reflect lzma->xz dependency Jun 17 15:37:58 if the patch goes in Jun 17 15:38:04 mangomake: .= appends without spaces, += with Jun 17 15:38:10 ah, i c Jun 17 15:38:42 mangomake: also I think you should comment out the BBFILES definition in your local.conf, that lets the two layers deal with that Jun 17 15:38:58 bluelightning, already done that - pending results for btibake -e Jun 17 15:39:17 wondered if was beinf pasre after and wolloping the results form the layers Jun 17 15:40:09 hmm, no i get no output from bitbake -e netbase | grep BBFILES at all now Jun 17 15:40:27 hmm :/ Jun 17 15:40:33 just trying again without the grep Jun 17 15:41:12 ERROR: /home/rt/oe/mylayer/recipes/netbase/netbase_4.21.bbappend is not a BitBake file while parsing /home/rt/oe/mylayer/recipes/netbase/netbase_4.21.bbappend Jun 17 15:41:25 03Tom Rini 07master * raf03ea851d 10openembedded.git/recipes/valgrind/valgrind_3.6.0.bb: Jun 17 15:41:25 valgrind: Drop 3.6.0 Jun 17 15:41:25 This isn't pinned anywhere and 3.6.1 is current and already in-tree. Jun 17 15:41:25 Signed-off-by: Tom Rini Jun 17 15:41:29 03Tom Rini 07master * r8ab8708203 10openembedded.git/recipes/valgrind/valgrind.inc: Jun 17 15:41:29 valgrind: Drop virtual/libx11 from DEPENDS Jun 17 15:41:29 Valgrind 3.6.x does not depend on X like older versions did. Jun 17 15:41:29 Signed-off-by: Tom Rini Jun 17 15:43:53 i think i need a nwer bitbake Jun 17 15:44:14 mangomake: yeah, I'd recomment 1.12 Jun 17 15:45:11 parallel parsing goodness Jun 17 15:50:36 mangomake: my apologies for leading you astray, I did not realise bbappends were not in 1.10.x Jun 17 15:51:19 hehe no worries, installing bb 1.12 now Jun 17 15:53:53 ant_work, what is the difference between xz and lzma Jun 17 15:54:13 so what should I do, abandon my patch and wait? Jun 17 15:54:19 xz is a container that suports lzma Jun 17 15:54:27 and potentially other formats in future Jun 17 15:54:34 (i had to look this up the other day too) Jun 17 15:57:07 http://stephane.lesimple.fr/wiki/blog/lzop_vs_compress_vs_gzip_vs_bzip2_vs_lzma_vs_lzma2-xz_benchmark_reloaded Jun 17 15:57:39 pls note dmem Jun 17 16:03:40 and memory requirements http://tukaani.org/lzma/benchmarks.html Jun 17 16:04:43 8 <1 MB 4 MB 17 MB 17 MB Jun 17 16:04:44 9 <1 MB 4 MB 33 MB 33 MB Jun 17 16:05:42 this means -9 requires 33 MB :/ Jun 17 16:05:46 ah ok Jun 17 16:06:48 I can confirm that a 1MB lzma -9 kernel cannot be decompressed on 32MB :p Jun 17 16:07:10 we were chasing some obscure bug for almost one year :) Jun 17 16:08:04 ahh Jun 17 16:08:16 so it *must* be machine arch when the machine is too weak Jun 17 16:08:39 but the default should be sane anyway Jun 17 16:08:50 in 2011 I'd say..yes Jun 17 16:17:51 so what should I do? Jun 17 16:18:00 backport the oe-core patch? Jun 17 16:18:05 wait? Jun 17 16:18:14 or look for acks for my patch? Jun 17 16:18:53 if there is an oe-core patch, I'd suggest to backport or fix that (if its not right) Jun 17 16:19:07 we've got a concern that oe-core will get out of sync w/ the maintenance oe.dev work Jun 17 16:19:21 indeed it's a big concern Jun 17 16:19:28 I bought an hdd adapter today Jun 17 16:19:42 in order to be able to get more space to test oe-core Jun 17 16:19:57 GNUtoo: I ack'ed the first version of the patch. I'll do on the second one. I'm also moving to oe-core this weekend Jun 17 16:20:16 let's repair the outstanding breakages Jun 17 16:20:19 mrmoku|italy, tried a lot of time to move to oe-core Jun 17 16:20:26 there were a lot of breakages at runtime Jun 17 16:20:40 we've fixed a lot of breakage in the last month.. Jun 17 16:20:51 ok Jun 17 16:20:52 things should be working (for the most part).. but it's not yet a "stable" system... Jun 17 16:20:56 what about games? Jun 17 16:21:01 games? Jun 17 16:21:08 yes, where should I import them? Jun 17 16:21:20 like wesnoth, wordwarvi etc... Jun 17 16:21:22 meta-oe Jun 17 16:21:22 supertux Jun 17 16:21:24 perhaps a layer within the meta-oe repo? Jun 17 16:21:24 ok Jun 17 16:21:29 there is a recipes-games? Jun 17 16:21:40 if there isn't, I'd suggest you add one.. check with Koen Jun 17 16:22:48 GNUtoo: probably, seen the average age, we'd like xmame ;) Jun 17 16:25:39 or C64 / ZXSpectrum emulators for the nostalgics Jun 17 16:26:21 hmmm that should go in emulators Jun 17 16:26:34 native games != emulators Jun 17 16:26:40 emulators have legal issues Jun 17 16:26:45 some are even non-free Jun 17 16:26:51 with non-commercial clauses Jun 17 16:26:58 companies can't include that I guess Jun 17 16:27:07 well, then away Jun 17 16:27:45 heading home now, bbl Jun 17 16:37:06 what's the best way to work with oe-core btw? Jun 17 16:37:09 there are many repos Jun 17 16:37:13 with layers etc... Jun 17 16:37:19 for instance for updating them Jun 17 16:37:24 do you use a Makefile Jun 17 16:37:28 or oebb.sh? Jun 17 16:38:18 I need to handle 2 distros: Jun 17 16:38:24 SHR and Angstrom Jun 17 16:38:30 with tons of machines: Jun 17 16:39:23 there's some tooling for this being developed within the Yocto project Jun 17 16:39:26 om-gta02(shr),htcdream(shr),nexusone(shr),nokia900(shr),bug1.x(angstrom),eee701(angstrom),bug20(angstrom) Jun 17 16:39:35 some RFC's where posted Jun 17 16:39:38 ok Jun 17 16:39:39 * incandescant goes digging Jun 17 16:39:44 thanks a lot Jun 17 16:40:07 for oe.dev I use scripts that handle simlinks to local.conf and tmpdir Jun 17 16:41:00 GNUtoo: lots of people have their own methods. i use git submodules with a makefile for convenience. git clone --recursive https://github.com/kergoth/oe-core-template for mine Jun 17 16:41:15 oe-cores init script has support for sharing a local.conf Jun 17 16:41:46 ok Jun 17 16:41:51 I used require in local.confs Jun 17 16:41:56 http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/004109.html Jun 17 16:42:03 for instance require angstrom.conf Jun 17 16:42:04 that's the layer tooling Jun 17 16:42:13 right Jun 17 16:43:52 so I need ssh-agent? Jun 17 16:44:03 for instance If I've commit access to many repos Jun 17 16:44:10 and what about branches? Jun 17 16:44:45 sorry, I do not know. I only know of the existence of the tool, I don't work on it Jun 17 16:44:54 ok np Jun 17 16:45:05 is there a tool comparison? Jun 17 16:45:14 if it doesn't support a feature you want feel free to suggest though Jun 17 16:45:36 comparison to the angrstrom and oe scripts? Jun 17 16:45:40 GNUtoo, I would suggest if you try some of these tools or associated to use oe-core.. you write up your experience and send it to the oe-core list Jun 17 16:45:45 I'd imagine not Jun 17 16:46:01 we need to understand what works, what doesn't and make this easier for all to use Jun 17 16:46:43 * incandescant nods in agreement Jun 17 16:47:09 ok Jun 17 16:47:10 GNUtoo: there's some public brainstorming on tools here https://wiki.yoctoproject.org/wiki/Layer_Tooling Jun 17 16:47:14 can I put on a wiki instead? Jun 17 16:47:22 first is there a list of theses tools Jun 17 16:47:23 ? Jun 17 16:47:45 thats fine.. just let us know where you put it... Jun 17 16:55:22 * kergoth is skeptical that anything will meet all, or even most, needs, but will keep an eye out Jun 17 16:57:46 bluelightning, I've just come back to this with bb 1.12, looks more promissing but still not working - its not expanding ${THISDIR} by looks of it Jun 17 16:57:48 FILESEXTRAPATHS="${THISDIR}/netbase:" Jun 17 16:58:34 mangomake: hmm, its possible the forced expansion of LAYERDIR might not have been pulled back to 1.12 Jun 17 16:58:41 not sure Jun 17 16:58:54 k, should i try git? Jun 17 16:59:53 give git master a shot, yeah, let me know if that works Jun 17 17:00:49 k, will do - am going to leave this till monday now tho, thanks Jun 17 17:04:31 bluelightning, thx for yr help, am off now Jun 17 17:07:23 cbrake: finding/creating git repos for everything in oe-core/meta/recipes-core/ is a pain Jun 17 17:07:24 heh Jun 17 17:07:42 kergoth: I can imagine! Jun 17 17:07:56 open source projects with no public scm at all make me sad Jun 17 17:09:48 kergoth: posted the patches on today's pull request :-) Jun 17 17:10:25 khem: did you see bluelightning and mine issues with gcc-crossdk? Jun 17 17:10:31 otavio: cool, thanks Jun 17 17:10:49 kergoth: np Jun 17 17:11:27 hopefully it either goes in, or someone tells me what needs fixing. one of the two :) Jun 17 17:13:43 kergoth: indeed Jun 17 17:14:07 kergoth: i looked at your tree and your busybox fix is also quite interesting Jun 17 17:14:19 kergoth: the one that generated the debug binary Jun 17 17:14:44 ah, thats a fix thats already in oe, but really needs to be pulled over Jun 17 17:14:55 not being able to debug anything is a problem, really Jun 17 17:15:00 erm, that was worded badly Jun 17 17:15:09 anything that isn't able to be debugged shoudl be fixed Jun 17 17:15:10 that's better Jun 17 17:15:16 kergoth: please post it Jun 17 17:15:28 will do Jun 17 17:15:46 figured i'd wait till i accrued a few misc fixes before sending, but i guess there's no point delaying unnecessarily :) Jun 17 17:15:59 kergoth: indeed Jun 17 17:16:13 kergoth: specially because you avoid duplicated work Jun 17 17:16:33 yeah, good point Jun 17 17:16:58 kergoth: otherwise someone can end up fixing a issue you fixed long time ago but didn't send to ml Jun 17 17:17:06 * kergoth nods Jun 17 17:17:11 wouldn't want that, we have more than enough to do already Jun 17 17:17:26 bluelightning: btw ... you qt4 fixes, are them ready? Jun 17 17:17:36 bluelightning: I will need the nativesdk now ;-) Jun 17 17:18:12 otavio: er... well the initial build fixes are in the contrib repo I mentioned earlier but I have still not solved the compilation problem Jun 17 17:18:30