**** BEGIN LOGGING AT Fri Mar 04 02:59:59 2011 Mar 04 03:08:57 03Roderick Taylor  07master * r6e294d9d3e 10openembedded.git/recipes/gnome/ (2 files in 2 dirs): Mar 04 03:08:57 system-tools-backends: don't use build machine's automake-1.7 Mar 04 03:08:57 * package patch to pretend that automake is missing. Mar 04 03:08:57 Signed-off-by: Roderick Taylor Mar 04 03:08:57 Acked-by: Philip Balister Mar 04 03:08:58 Signed-off-by: Philip Balister Mar 04 03:29:55 anyone know what provides LibArchive? cmake is failing to build Mar 04 05:12:36 what is the best way of tracking down the cause of "error: printing the evironment of the function"? Mar 04 07:31:44 gm Mar 04 08:41:03 eFfeM_work: gm Mar 04 08:42:03 quiet this morning Mar 04 08:47:12 03Frans Meulenbroeks  07master * rfa3ce77ac7 10openembedded.git/recipes/dbus/ (dbus-1.4.1/dbus-auth-nios2.patch dbus_1.4.1.bb): Mar 04 08:47:12 dbus 1.4.1: added nios2 specific patch to avoid a gcc ICE Mar 04 08:47:12 This is all under SRC_URI_append_nios2 Mar 04 08:47:12 No PR bump is needed for nios it did not build at all and Mar 04 08:47:12 others are not affected Mar 04 08:47:12 Signed-off-by: Frans Meulenbroeks Mar 04 08:47:20 good morning Mar 04 08:47:25 hi mckoan Mar 04 09:24:30 Hi Mar 04 09:24:56 Can OE generate an image containing an initrd stage? Mar 04 09:27:31 I have a machine with 2 HDs in it. I think the drives are getting re-ordered when Linux boots (depending on the timing of the disk initialisation) which results in the command line "root=/dev/sda1" being wrong on some reboots... Mar 04 09:37:32 ericben, after cleaning, qt4-embedded 4.7.1 compiled fine on my system. Mar 04 09:38:00 good morning Mar 04 09:41:06 florian, gm Mar 04 09:41:15 has embedded world happend? Mar 04 09:43:38 Crofton|work: hi - yes, we came back home last night Mar 04 09:43:45 cool Mar 04 09:43:54 will things calm downfor you now? Mar 04 09:44:07 how was the show? Mar 04 09:46:07 yes a little bit - unless the baby decides to disturb my schedule ;) Mar 04 09:46:18 :) Mar 04 09:46:33 We are flying to Colorado this morning for vacation Mar 04 09:46:41 very very good... Mar 04 09:46:59 oh nice... vacation *dream* Mar 04 09:49:45 03Martin Jansa  07master * r3d625ae17f 10openembedded.git/recipes/linux/linux-kexecboot.inc: Mar 04 09:49:46 linux-kexecboot: remove extra quotes arround INITRAMFS_COMPRESSION RD_COMPRESSION, which made 'make oldconfig' to ignore them Mar 04 09:49:46 Acked-by: Khem Raj Mar 04 09:49:46 Acked-by: Andrea Adami Mar 04 09:49:46 Signed-off-by: Martin Jansa Mar 04 09:50:12 anyone here built cmake lately Mar 04 09:50:42 cmkae, not cmake-native Mar 04 09:50:57 I get a failure due to not finding LibArchive Mar 04 09:53:51 florian: a friend told me that there was less visitors than the last year Mar 04 09:54:25 and last year I was there and I noticed less visitors than 2009 :-( Mar 04 09:56:09 mckoan: unlikely and if this was true they improved their methods for selecting visitors :) Mar 04 09:56:22 morning all Mar 04 09:56:31 hi bluelightning Mar 04 09:59:50 florian: selecting visitors was aplpied to SMAU, the most important IT event in Italy (like CeBit), and it was a disaster Mar 04 10:00:22 visitor decreased each year and now nobody cares about it Mar 04 10:00:40 heh Mar 04 10:08:30 Crofton|work: fails here as well, just tested. But I only use cmake-native Mar 04 10:08:39 hi all, btw Mar 04 10:11:25 hi stefan_schmidt Mar 04 10:11:33 hi florian Mar 04 10:13:20 I need cmake in the image Mar 04 10:13:27 glad the problem is not just me this time Mar 04 10:17:20 someone seen: ERROR: Nothing RPROVIDES 'python-core-native' (but virtual:native:/OE/shr-core/meta-openembedded/recipes-devtools/python/python-setuptools_0.6c11.bb RDEPENDS on or otherwise requires it) ? Mar 04 10:21:06 anr78: hi same thing here build finished properly Mar 04 10:26:06 all is well then :) Mar 04 10:41:42 if i build gstreamer-ti. will it also build all good plugins of gstreamer Mar 04 10:44:24 03Martin Jansa  07master * ra3277c6f36 10openembedded.git/recipes/tasks/task-shr-minimal.bb: Mar 04 10:44:24 task-shr-minimal: switch from pyphonelog to ffphonelog Mar 04 10:44:24 Signed-off-by: Martin Jansa Mar 04 10:51:27 * Jay7 have read TSC minutes and log Mar 04 10:52:14 still almost nothing new wrt testing/stats infrastructure :) Mar 04 10:52:20 * JaMa|Wrk have read TSC minutes and log few days ago :) Mar 04 10:53:10 I mean 2011-02-28 Mar 04 10:53:22 I got it today in my mailbox :) Mar 04 10:53:41 btw, seems it is time to subscribe to oe-core Mar 04 10:54:23 Jay7: yeah, we need to come to the testing item. But at least the backlog goes down nicely. Mar 04 10:55:00 stefan_schmidt: we (me, ka6sox, pidge) have wiki page about this :) Mar 04 10:55:17 Jay7: oe wiki? Mar 04 10:55:19 Jay7: it was on tsc ML few days ago Mar 04 10:55:19 I've posted it to oe-devel@ about a week ago Mar 04 10:55:28 stefan_schmidt: now both - oe and yocto Mar 04 10:55:44 JaMa|Wrk: ah, I'm not subscribed Mar 04 10:55:54 neither am I :) Mar 04 10:55:55 Jay7: ok, will point this out when we get to the topic Mar 04 10:56:37 https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions Mar 04 10:56:49 stefan_schmidt: here is right place Mar 04 10:57:10 pidge is working on this from yocto side (when not managing release :) Mar 04 10:57:19 Jay7: great, thanks Mar 04 10:57:30 btw, I still should update page with latest ideas Mar 04 10:57:32 Jay7: appreciated to see people working on it Mar 04 10:57:51 stefan_schmidt: now mostly in RFC state but.. :) Mar 04 10:58:11 Jay7: well, one have to start somewhere :) Mar 04 10:58:49 And I like the spirit of people from OE and yocto coming together into a group that targets their itches together :) Mar 04 10:59:30 heh.. that is very hard work to do it separately :) Mar 04 11:02:29 fray, khem: Could you add your available times for the TSC meeting in doodle? Tom, Richard, Koen and myself already did Mar 04 11:02:58 * stefan_schmidt thinks meeting appointments are really hard to get right over timezones... Mar 04 11:15:01 temporary mysql outage, I am on it Mar 04 11:15:12 it is unavoidable... and extremely necessary, and immediate Mar 04 11:33:41 03Graeme Gregory  07master * rfcb12f3a44 10openembedded.git/recipes/pulseaudio/pulseaudio_git.bb: Mar 04 11:33:41 pulseaudio_git : fix packaging Mar 04 11:33:41 pulse uses a magic version file hidden in tarbal in order to determine Mar 04 11:33:41 its version so set that to out ${PV} from OE. Mar 04 11:33:41 Also git pulse has changed the default location of modules so set it Mar 04 11:33:41 to be same as old location for compatability. Mar 04 11:33:43 Signed-off-by: Graeme Gregory Mar 04 11:43:14 mysql maintenance done Mar 04 12:18:58 Hi. Are dashes allowed in function names defined in classes? For example `python foo-bar_do_fetch () { ... }', considering my class file is called foo-bar.bbclass. I want to `EXPORT_FUNCTIONS do_fetch'. I couldn't find an example of a class file whose name contains a dash and which uses EXPORT_FUNCTIONS. Mar 04 13:02:59 Renaming the class file to foo_bar.bbclass seems to make things work. This is quite ugly. Isn't there a way to rename functions when exporting? Mar 04 13:29:45 suppose i have a package to build. how can i find out what it depends on Mar 04 13:29:58 i know there is a bitbake command i dont remember Mar 04 14:24:52 morning Mar 04 14:43:19 kergoth: hi Mar 04 14:43:45 Hi kergoth Mar 04 14:48:45 g'day kergoth Mar 04 15:08:57 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * r1675c832fa 10openembedded.git/recipes/ (2 files in 2 dirs): (log message trimmed) Mar 04 15:08:57 accelges_svn.bb: move to openmoko-3rdparty and make it work again Mar 04 15:08:57 On recent kernels,the openmoko accelerometers input node moved: Mar 04 15:08:57 /dev/input/event2 -> /dev/input/event3 Mar 04 15:08:57 /dev/input/event3 -> /dev/input/event4 Mar 04 15:08:58 And the reporting format went from relative to absolute. Mar 04 15:08:59 Thanks a lot elisa42 from #openmoko-cdevel on Freenode on irc: Mar 04 16:36:12 03Andrea Adami  07org.openembedded.dev * r76eb683496 10openembedded.git/recipes/linux/linux-kexecboot.inc: Mar 04 16:36:12 linux-kexecboot.inc: add dependency on u-boot-mkimage-native for mips: Mar 04 16:36:12 * We aim to support new mips devices shipping with u-boot Mar 04 16:36:12 * but we cannot set KERNEL_IMAGETYPE = "uImage" yet. Mar 04 16:36:12 * This is temporary solution until uImage becomes target for mips Mar 04 16:36:12 * both in kernel and kexec-tools Mar 04 16:36:13 Signed-off-by: Andrea Adami Mar 04 17:11:20 03Graeme Gregory  07master * r267c0b50a0 10openembedded.git/recipes/linux/linux-omap-2.6.38/ (6 files in 4 dirs): Mar 04 17:11:21 linux-omap_2.6.38.bb : add beagleboard support Mar 04 17:11:21 Added basic beagle support porting in the two patches that were Mar 04 17:11:21 obvious to bring in. Updated the omapzoom machines with the same Mar 04 17:11:21 defconfig while doing this. Mar 04 17:11:21 Signed-off-by: Graeme Gregory Mar 04 17:12:22 03Graeme Gregory  07master * r72e0f079ae 10openembedded.git/recipes/linux/linux-omap_2.6.38.bb: Mar 04 17:12:23 linux-omap_2.6.38.bb : add beagleboard support Mar 04 17:12:23 Added basic beagle support porting in the two patches that were Mar 04 17:12:23 obvious to bring in. Updated the omapzoom machines with the same Mar 04 17:12:23 defconfig while doing this. Mar 04 17:12:23 Signed-off-by: Graeme Gregory Mar 04 17:48:11 fray: around ? Mar 04 17:48:37 fray: even when I use the scripts to build rfs it still ends up that LOOP error at the very end :( Mar 04 17:48:58 those are warnings, not errors. Mar 04 17:49:13 they're indicating a loop in the dependencies within the packages being installed.. Mar 04 17:49:28 yeah but I wonder if thats the reason to fail also Mar 04 17:49:32 any error message should come right before or right after them. In the case you showed me yesterday there was no message it just "stopped" Mar 04 17:49:47 have you seen such warnings and still succeeded in rfs generation Mar 04 17:49:48 no, not a failure case.. (in fact one of the commented out rpm patches just turns off the message) Mar 04 17:49:51 ya Mar 04 17:49:59 i c Mar 04 17:50:20 I think I am just a scapegoat with ubuntu Mar 04 17:50:24 :) Mar 04 17:50:24 11.04 here Mar 04 17:50:44 but I am sure someone else will run into sooner or later Mar 04 17:51:09 well what we need to do is figure out where it's exiting and why.. I'm really not sure how to do that remotely -- other then someone needs to try to run it through gdb or something and figure out where and why it's exiting Mar 04 17:52:37 fray: I can debug it. just that its PITA that I hate to do :) Mar 04 17:52:46 ya, I understand.. Mar 04 17:53:00 with what you are experiencing I'm not even sure how to instruct you.. Mar 04 17:53:12 it's either in -- or just past dependency resolution.. Mar 04 17:53:18 (according to the -vv log) Mar 04 17:53:29 something is telling it either there is nothing to do, or there was an un-logged error.. Mar 04 17:54:18 if you do start hacking into it, I suggest enabling "-vv".. if it starts to close database files, then it's too late and already failed.. Mar 04 17:59:17 and you said many folks use ubuntu so it must be a ubuntu 11.04 issue Mar 04 18:01:40 * khem 's wife is getting an iBad2 as gift from her employer Mar 04 18:02:33 cool Mar 04 18:02:51 ya, I don't know anyone who is running 11.04.. just prior versions Mar 04 18:04:18 khem, tell her that it makes a very good trivet Mar 04 18:04:58 mwester: heh Mar 04 18:05:10 mwester: it will be me mostly using it on light rail Mar 04 18:05:14 for reading Mar 04 18:05:36 kindle is smaller and better for that :) Mar 04 18:05:58 but you can't play angry birds on the kindle. Mar 04 18:08:41 khem: hello, are youinformed about the oe repository split, I have some questions Mar 04 18:08:53 khem: ? Mar 04 18:09:20 nschle85: sure ask Mar 04 18:09:49 what happens with openembedded repository ? will it be closed ? Mar 04 18:13:05 The expectation is new development will move to oe-core and meta-oe.. existing work may stay in openembedded repository Mar 04 18:13:35 it won't be "closed" because there are existing releases tagged and such, but master is going to get out of date on it, effectively closing it.. (thats my belief at least) Mar 04 18:15:09 fray: hi, thank you. I am not an expert in bitbake and its file structure. so what is the difference between oe-core amd meta-oe ? Mar 04 18:15:56 with the new work there is now a concept of "layers". oe-core is meant to be a base common layer of code and example configurations.. on top of that distributions like Angstrom, OE and Yocto can be built.. Mar 04 18:16:10 meta-oe is the "OE" layer that would include the configurations, BSPs, recipes, etc that make it "OE" Mar 04 18:16:26 (I expect there will also be BSP, architecture, etc layers as well.. but thats a fair generalization) Mar 04 18:16:58 everythign that is currently in the "openembedded" repository will either be: copied/replaced by something in oe-core, moved to meta-oe, or removed as no longer functional Mar 04 18:17:08 I expect the majority of items in the first two categories Mar 04 18:19:55 fray: ok so let me repeat: oe-core is meant to be a "library to create a distribution" and meta-oe is the concrete OE distribution, like SHR or whatever. True ? what is BSP ? Mar 04 18:21:49 bsp -- board support package, it includes a configuration for the linux kernel, kernel patches (or perhaps full source), drivers, etc.. anything to make a board work Mar 04 18:29:00 fray: so where is a receipe for eg "vim" located ? in oe-core or meta-oe ? I did not understand what concrete goes into oe-core and what is in meta-oe Mar 04 18:30:09 the core items are the starting point.. thigns that go into core for sure gcc, glibc, binutils, kernel headers, bash, coreutils, busybox, etc.. Mar 04 18:30:43 vim is one of those things that it could be argued either way, but I'd be inclined to say meta-oe because it's not required for most embedded systems to function (its not even used in a lot of designs) Mar 04 18:31:39 guidelines are still being created as to what software goes into what layer. The starting point was using the Yocto Project's Poky as the "oe-core".. we're currently going through it and having discussions if certain components in there belong in oe-core or not Mar 04 18:31:43 To me, if busybox can do it well enough in most cases it might not be core Mar 04 18:31:47 udev, yeah, still core Mar 04 18:31:49 vi/vim? Mar 04 18:31:49 vim is not core, because you can use vi to bootstrap to emacs. :D Mar 04 18:31:55 no, busybox fake it Mar 04 18:32:53 the other thing is that oe-core is expected to have primarily one version of each recipe.. (with exceptions for multiple versions in specific circumstances).. while meta-oe may include as many versions of a recipe as needed or desired.. (including additional versions of recipes that are in oe-core) Mar 04 18:33:30 mwester and emacs is it's own operating system.. ;) Mar 04 18:33:41 I'm looking forward very much to this effort, as I think it will expose some of the current "marginal" interdependencies (marginal meaning that they do not play well on very very small embedded devices). In particular, it would be nice to see how we can build common embedded systems that do NOT suck in X11 libs anymore. Mar 04 18:34:00 fray, yes, it is! and it's own windowing system. :) Mar 04 18:34:15 mwester yes, I think that is a clear item.. dependencies and such need to be clearly factored, etc within oe-core.. Mar 04 18:34:42 it's supposed to provide the key subsystems, components and such in a stable (yet up to date) way as reasonable.. Mar 04 18:35:03 if something useful in oe-core is being upreved and people see a need to keep the older version, we can place it into meta-oe.. Mar 04 18:35:26 I'd be ecstatic if we could have basic bluetooth support, for example, without ending up with X11 being built. Mar 04 18:35:37 fray: so I am confused... i think this diffrenciation is not good. Mar 04 18:35:59 mwester: the dream? :) Mar 04 18:36:35 one of the largest complaint I head about OpenEmbedded is "where do I start".. this is from developers, distribution creators, semiconductor manufacterers, OEMs, etc.. Mar 04 18:36:37 I've always wondered why my 1700 tasks changed to almost 5000 overnight... Mar 04 18:36:48 oe-core is supposed to help answer that question -- yet oe-core is NOT oe Mar 04 18:37:23 (oe-core also will be self-contained.. we'll be able to build and test the recipes within it.. helping to eliminate some of the potential dependency madness) Mar 04 18:38:13 oe-core will serve the building blocks and the intention is to have then robust Mar 04 18:40:12 mwester: with bb able to spew individual deps like "why is package foo in my image" it would easier to detect unneeded deps Mar 04 18:41:04 right now in OE we do not do so well on dependency tracking but in OE core any new addition to dependencies will be thoroughly inspected Mar 04 18:41:49 we really need to add more tools for discovery in bitbake. when you sit down with a build dir you have no idea what you can build, what vars you can set, what classes you can inherit, etc. even further than that, there's no clean mechanism to inspect an existing tmpdir to determine just what was done there, short of poking around manually Mar 04 18:41:52 That's true, but I have always been able, with enough effort, to find the "why". What I have not been able to do is figure out the "how" to fix it, when nobody seems to care but I ... Mar 04 18:41:55 heh Mar 04 18:43:19 mwester the why is still often difficult for people to figure out.. getting more tooling and a common core I believe will help answer more of the why questions -- as for the "how".. I'm not sure that is as easy to answer.. however within each potential layer, you are more likely to have a receptive audience on figuring out the "how" Mar 04 18:43:39 I myself advocate targeted layers of functionality.. bsps, architectures, "designs", etc.. Mar 04 18:43:39 or may be we can generate a huge rpm and use rpm;s dep checker Mar 04 18:43:53 Scouring through every recipe in OE to find out how to add (for example) a DISTRO_FEATURE for X11 was just too high a hurdle for me; I gave up after several dozen libs and apps. Mar 04 18:44:11 mwester, yes configurations are still madness.. Mar 04 18:44:32 that is an area that we're planning on targeting once oe-core is nailed down Mar 04 18:45:50 The separation will be helpful at non-technical levels as well. E.G. I can hack X11 dependencies out of the recipes I need for SlugOS, but at the moment I cannot commit that, because it wreaks havoc with all the other distros. :) Mar 04 18:46:08 yes Mar 04 18:46:43 the layers changes also allow you to modify recipes without actually modifying them -- in your own layer.. Mar 04 18:46:53 Well, that's actually a problem, not a feature. Mar 04 18:46:58 you've always been able to do that Mar 04 18:47:11 (recipe.bbappend -- this will allow you to change things in a layer affecting other items) Mar 04 18:47:57 so distributions, end users, oems, etc can make their own policy decisions by extending oe-core recipes, or simply replacing them within their own layer(s) Mar 04 18:48:16 its unfortunate that its not possible to .bbappend a class or .inc Mar 04 18:48:36 ...and if a recipe is limiting the way's in which it can be extended -- then that is a change that is likely useful in oe-core) Mar 04 18:51:11 The biggest issue with that concept is when the underlying recipe or item being extended gets removed. Right now, grep can tell someone if a given recipe is in use (i.e. is pinned), or if a given class is used. When we split, that visibility is gone. Mar 04 18:51:13 fray: thats true, but the questions how to start can be solved with good documantation. In my opinion there will be a lot of copied code as I can see (JaMa is preparing the split for shr). The getting started will be more complicated because you need to collect the right layers. Mar 04 18:51:54 the good documentation is also partially provided by the core.. policies, how to do certain things, etc.. Mar 04 18:52:09 as far as collecting the right layers -- I expect that is the realm of the distribution creator.. Mar 04 18:52:31 Yocto Project, Angstrom, etc will all collect the pieces together and have their own documentation on how to get started and do things... Mar 04 18:53:20 mwester: see the bitbake-layers script. currently, it shows you all the bbappends that exist, warns if you append something that doesn't exist, and warns if you append a version of something but not the preferred version. that sort of external tooling is likely how we'll be addressing that sort of visibility Mar 04 18:54:46 * kergoth_ mutters Mar 04 18:54:56 my signature code is going INSANE at the moment :( Mar 04 18:56:51 fray: which role plays Yocto project ? ( i am using shr) Mar 04 18:57:42 Yocto Project is run by the Linux Foundation and is supported by a number of commercial entities who have a vested interest in an embedded Linux for their devices.. Mar 04 18:58:11 fray: will oe depend on it in future ? Mar 04 18:58:29 They're trying to address the problems that they have, which is where the Yocto Project will direct their efforts -- I expect it'll be board enablement, demos, and quick starts for their commercial customers.. Mar 04 18:58:54 nschle85: oe and poky will both be built upon oe-core. Mar 04 18:59:18 the oe-core is a merger of some of they key components within Yocto Project's "Poky" system today. The intention is whatever is in oe-core no longer will be maintained by the Yocto Project and then the Yocto Project's Poky can use oe-core as their "base layer" as well.. Mar 04 19:00:09 Similar there is a current commitment with Angstrom to build on oe-core as well... (while plans can and do change) the commitments from the various people are all strong enough to show there really is a need for a core set of functionality, recipes, etc to build upon.. Mar 04 19:00:34 right now the general feeling is existing OE is simply too big to "build upon", instead you end up having to re-do things or figure out what to remove in order to get what you want.. Mar 04 19:00:46 it always seems easier to me to add things then remove them.. Mar 04 19:02:50 fray: ok now i understand the intention of oe-core and meta-oe Mar 04 19:03:28 fray: but is this a problem of every distribution i think Mar 04 19:04:20 yes.. every distribution makes tradeoffs in both size, performance, and capabilities based on their users.. Mar 04 19:04:57 it's hard to have one thing thats perfect for everyone.. with oe-core, we're acknoledging it's not perfect for everyone.. but it has enough in common that it's useful for all of the distributions... Mar 04 19:09:42 fray: did i understand correct that oe-core+meta-oe= current openembedded ? Mar 04 19:10:37 for almost everything, that is the intention.. Mar 04 19:11:03 the exception is where there is something in current openembedded that simply doesn't work anymore.. we'll look for a maintainer or a way to fix it.. otherwise it will be removed as dead code Mar 04 19:13:18 fray: ok, so SHR may consist of oe-core+meta-oe+meta-shr ? Mar 04 19:14:41 nschle85: ues Mar 04 19:14:42 yes Mar 04 19:15:02 yes... but it doesn't have to.. it could be oe-core+meta-shr Mar 04 19:15:44 (or if they decide not to use oe-core, it could be meta-shr -- but I woild expect any of those variations make it more difficult to reach the end goals) Mar 04 19:18:54 fray: thats my problem, why duplicate a lot of recipes which still exists in meta-oe ? Mar 04 19:19:18 thats up the distro developers to decide... Mar 04 19:19:41 there are reasons to do it.. (one of which is simply to remove things you are not willing to support) Mar 04 19:21:17 fray: example: at the moment there is a problem with a recipe and all oe developers can help, but later oe developers are not interested to support an unmaintained recipe Mar 04 19:22:11 fray: i believe that there will be a lot of unused manpower in future Mar 04 19:22:27 Why so? Mar 04 19:22:45 my experience is developers only care about their own problems -- other then a select few who try to help everyone.. Mar 04 19:22:58 a bit cynical -- but I think thats a fairly realistic way to view the world Mar 04 19:23:38 oe-core gives more people a vested interest in managing and keeping the quality levels up for that software.. Mar 04 19:23:54 meta-oe retains the current environment and abilities for OE contributors to continue to contribute.. Mar 04 19:24:00 Yes, I agree with that. And because of that, there is a lot of work that is NOT being done in OE itself - -because it is simply too difficult to get a recipe, which might work just fine for me, into a state where Angstrom will accept it. Mar 04 19:24:07 Hence I don't bother. Mar 04 19:24:09 meta-yocto, meta-angstrom, meta-shr -- each will have their own guidelines, users, etc.. Mar 04 19:27:13 fray: in worst case every distribution has its own fork of oe ..... Mar 04 19:28:22 exactly -- oe-core is partially an attempt to unify the things most distributions don't want to fork Mar 04 19:28:37 finding the right balance of things that everyone can agree on or not though is difficult.. Mar 04 19:28:41 and something that will change over time Mar 04 19:30:13 fray: so oe will die .... Mar 04 19:30:26 I think the more realistic "fork" would be two versions of oe-core. Because IMO there are two very distinct distro-types -- those with a UI and those without, and they have vastly different needs. I am optimistic that the commercial vendors will help drive, for cost reasons, the oe variant that doesn't assume a display. Mar 04 19:32:44 My expectation is that both with and without display is equally valuable.. Mar 04 19:33:03 mwester: sorry you cannot decide between gui no gui Mar 04 19:33:14 but both types of systems are necessary... Mar 04 19:34:11 (and when you talk displays, do you mean X11, directfb, PowerVR style direct OpenGL?, etc..) Mar 04 19:34:30 as I say on oe-core, we need to talk about some kind of use flag or perhaps really, groups of flags Mar 04 19:34:31 so you have to set some reasonable guidelines within the core to provide the subsystems.. but the policies are the distro and end user's Mar 04 19:34:37 we already have DISTRO_FEATURES and MACHINE_FEATURES Mar 04 19:34:53 (and we need to document these features!) Mar 04 19:34:53 And we've finally started enforcing the common autotools parts of some of them Mar 04 19:35:13 fray, I really speak of things like X11, pango, and the other bits. You don't need that on, for example, a router, where the GUI is a web page. Mar 04 19:35:39 yup, exactly.. Mar 04 19:35:53 but I do know of routers that have no display, but DO have x11 and others.. for remote adminstration.. Mar 04 19:36:10 yet, on a router, you might like to support a bluetooth USB device... you can't do that today with OE. Mar 04 19:36:50 (BTW one thing is that calling these "distributions" is a bit incorrect.. really the output of the build is a custom distribution... but the input is really bitbake, recipes, configurations -- or distribution assembly information) Mar 04 19:37:11 fray: thats the problem, in my opinion , oe should not be splitted, it should be a repository, like ubuntu it provides Kde, Gnome and Educational ... Images Mar 04 19:37:22 fray, yes, you CAN put X11 on a router -- but it has to be large in terms of CPU and memory. With OE at present, it is possible to build an image that does not REQUIRE x11 to be installed on the target, but you end up having to BUILD the entire X11 libs. This is what I hiope the commercial vendor influence will address. Mar 04 19:37:42 mwester yes.. it --will-- be possible to build without graphics in oe-core Mar 04 19:37:49 mwester, yes, there's commercial pull, in both directions Mar 04 19:38:06 similarly it --will-- be possible to build WITH graphics as well.. Mar 04 19:38:15 these are the things we need to keep watching, testing and refining.. Mar 04 19:38:19 mwester: i think this can be solved without splitting oe Mar 04 19:38:24 (we being the maintainers and contributors of oe-core) Mar 04 19:38:53 nschle85, using the ubuntu analogy there's the universe repo and there's the main repo Mar 04 19:39:09 and then there's the multiverse Mar 04 19:40:30 Tartarus: you are right, but in my oppinion there should be only a main repo Mar 04 19:42:00 Tartarus: repositories and real software dependencies are 2 different things Mar 04 19:46:57 Tartarus: ok i found a good arument ! JaMa|Off is maintaining the xorg recipes (i think), if xorg is not included in oe-core anymore xorg will be maintained in shr and oe has no xorg maintainer Mar 04 19:49:05 That's what meta-oe is for, yes Mar 04 19:53:25 Tartarus: JaMa|Off will maintain SHR recipes Mar 04 19:54:44 Tartarus: some month ago shr migrated to OE and now it will be removed from there ? Mar 04 19:55:54 The shr specific stuff would be in meta-shr and xorg would be in meta-oe or oe-core, it's hard to tell Mar 04 19:57:55 Tartarus: so what is specific to shr and what is the rest ? Mar 04 19:58:17 shr-image.bb is shr specific Mar 04 19:58:29 shr policy in other recipes is shr specific Mar 04 19:59:05 Tartarus: but at the moment JaMa|Off copies a lot of recipes into meta-shr Mar 04 19:59:16 And oe-core is about a week old Mar 04 19:59:46 And we're trying to add things to, rather than remove things from, so that we can fixup recipe quality as we go Mar 04 20:00:47 fray: where is the progress of splitting documented ? and when developers needs to swich to new repositories ? Mar 04 20:03:53 fray: why not using branches instead of splitting the repository ? Mar 04 20:06:11 why would you want to use branches for that? they wouldn't share history, the trees would be entirely different, doesn't make sense Mar 04 20:06:51 kergoth: ok Mar 04 20:09:16 kergoth: branches can be merged back, so fixes and new features can be shared into a single source Mar 04 20:09:52 kergoth: a fork will never be come back Mar 04 20:12:07 kergoth: i prefer branching instead of forking Mar 04 20:13:51 kergoth: and the problems which are reported are not on repository level, they are on source level Mar 04 20:18:17 nschle85: huh? Mar 04 20:18:24 nschle85: you can merge just fine between repositories Mar 04 20:18:32 cherry pick, do whatever you want Mar 04 20:18:34 its just another remote Mar 04 20:18:41 but you wouldn't want to anyway. Mar 04 20:40:05 kergoth: sorry my knowledge stopped at cvs svn clearcase Mar 04 21:29:01 hiho Mar 04 21:30:09 hm Mar 04 21:43:12 hi woglinde Mar 04 21:45:00 he pb Mar 04 21:45:13 one day on cebit left Mar 04 21:45:25 tomorrow i will be alone at the booth Mar 04 21:50:35 alone? oh dear. Mar 04 21:50:42 what happened to everyone else? Mar 04 21:51:26 * pb__ all alone at the moment, everyone here is asleep Mar 04 21:51:28 heh Mar 04 21:51:31 mickey is ill and robert left today Mar 04 21:52:25 ah, poor mickey Mar 04 21:52:31 is florian not there? Mar 04 21:52:37 no Mar 04 21:52:47 he was in nueremberg Mar 04 21:52:53 at embedded world Mar 04 21:53:08 ah Mar 04 21:53:25 all these shows Mar 04 21:54:26 * ynezz prefers {beer, wine}fest shows... Mar 04 21:54:39 haha Mar 04 22:08:30 hmm shows/conferences and Mickey don't fit together well. Is there any than don't make him sick? Mar 04 22:33:35 <_ohm> When I try and compile nano using bitbake, I get a parsing error, it looks like the ${IMAGE_PKGTYPE} variable hasn't been declared, where is the config file so I can declare it? It isn't in local.conf Mar 04 22:35:54 <_ohm> http://pastebin.com/FUVwALQs here is the error output Mar 04 22:37:16 _ohm: sounds like you should choose a distribution to build Mar 04 22:41:57 <_ohm> florian, thank you, i did not realize there was a specific list of distros from /openembedded/conf/distro, I just copied the version number from my tablet Mar 04 22:44:58 _ohm: It might be a good idea to take a look at the Getting_started document in the Wiki. It describes the configuration and should be useful to get things set up correctly. Mar 04 22:45:00 http://www.openembedded.org/index.php/Getting_started Mar 04 22:49:54 <_ohm> florian, thanks this is the document i am going off of, I'm getting these errors now, http://pastebin.com/6YbZZ2c8, any suggestions? Mar 04 22:51:06 <_ohm> actually wait, i think i found it Mar 04 22:55:26 <_ohm> never mind, got my hopes up to early :\ Mar 04 23:01:09 paste your local.conf Mar 04 23:12:01 <_ohm> Jay7, http://pastebin.com/LgJVqFC5 Mar 04 23:18:44 IMAGE_FSTYPES = "jffs2 tar" -> tar.gz or tar.bz2 Mar 04 23:19:34 and better to set BB_NUMBER_THREADS and PARALLEL_MAKE to # of your CPU cores Mar 04 23:50:32 <_ohm> Jay7, I'm still getting the same errors, here is my local.conf, http://pastebin.com/km6Xv9Py, and my error screen, http://pastebin.com/FDRpS18f Mar 04 23:54:23 _ohm: what bitbake version you using? Mar 04 23:58:25 <_ohm> Jay7, 1.8.18, I'm updating it right now Mar 04 23:58:35 <_ohm> to 1.12 Mar 04 23:59:42 <_ohm> actually, my directory says 1.12, bitbake --version says 1.8, 1.12 is probably what i have since that it was I downloaded Mar 05 00:02:32 it should say 1.12 Mar 05 00:02:46 check 'which bitbake' output Mar 05 00:08:40 <_ohm> Jay7, ok the bitbake problem was from me installing bitbake from ubuntu's repositories, I'm installing bitbake-1.12 now Mar 05 00:09:13 better to have one from git Mar 05 00:14:02 <_ohm> Jay7, yeah I meant to say that, sorry Mar 05 00:16:03 <_ohm> currently bitbaking nano.... Mar 05 00:20:19 <_ohm> more errors, great, http://pastebin.com/7LKYEyJj, im in bash..., i might just disable the sanity check Mar 05 00:21:19 _ohm: hmm no, his is about the link /bin/sh points to Mar 05 00:21:43 so it is not related to the shell you are using currently Mar 05 00:21:50 _ohm: change /bin/sh to point to /bin/bash Mar 05 00:22:21 hmm I think we do a good job on dash too isnt is Mar 05 00:31:36 khem: someone should check and report :) Mar 05 00:33:40 <_ohm> be right back Mar 05 00:43:43 <_ohm> ok I screwed up the link haha, I'll be right back Mar 05 01:42:22 <_ohm> pointed sh to bash, everything appears to be working now, thank you everyone for your help Mar 05 02:59:56 good evening all **** ENDING LOGGING AT Sat Mar 05 02:59:56 2011