**** BEGIN LOGGING AT Sun Dec 15 03:00:00 2013 Dec 15 08:59:28 build]$ rpm -qa | grep libX11 Dec 15 08:59:30 libX11-1.6.0-1.fc19.i686 Dec 15 08:59:32 libX11-common-1.6.0-1.fc19.noarch Dec 15 08:59:34 libX11-1.6.0-1.fc19.x86_64 Dec 15 08:59:36 libX11-devel-1.6.0-1.fc19.i686 Dec 15 11:01:58 . Dec 15 13:58:15 . Dec 15 14:17:17 I am still struggling to find the root cause of my build issue Dec 15 15:06:48 Yocto is far more complicated than it needs to be Dec 15 15:08:01 Smigers: comments like that are not constructive Dec 15 15:08:37 Depends upon how you look at it Dec 15 15:10:18 Smigers: well, I could say you don't know what you're talking about. You would probably find that offensive. Dec 15 15:10:32 I have been reading the documentation for 4 hours, and I still have no clue how to begin to find why my build is failing Dec 15 15:11:42 Smigers: ok, I looked back through the irc logs and it seems you have a Fedora 19 system with a rather strange mix of 32 and 64 bit libraries on it Dec 15 15:11:59 A strange mix ? Dec 15 15:12:46 Smigers: well, you have "libX11-devel-1.6.0-1.fc19.i686" but not a x64_64 bit version of that yet your system is primarily x86_64 Dec 15 15:13:11 Smigers: can you install the x86_64 version of that or remove the i686 one? Dec 15 15:13:34 Why is that important ? The build system shouldn't be looking on my machine for anything Dec 15 15:13:39 Smigers: If we can figure out what the problem is, we can likely find ways to make our build work Dec 15 15:13:46 sorry, that's too general a statement Dec 15 15:14:05 Smigers: well clearly it isn't working and I agree that it should. We will have to change something to make it work Dec 15 15:14:34 The build system should only use a very minimal set of tools (already compiled) resident on my machine Dec 15 15:14:39 Smigers: we can either try and figure out what in the installtion is causing the problem, or we can try patching the build system to address this Dec 15 15:15:16 It should not be looking at header files or link libraries except those that reside within the yocto source tree Dec 15 15:15:47 Smigers: that is complete and utter rubbish. You can't compile software to run on the system without looking at the system headers Dec 15 15:16:21 Smigers: keep in mind there are two classes of program, ones for the build system (the one you run the build on) and ones for the target system Dec 15 15:16:34 Sure Dec 15 15:16:38 Smigers: its ones of the first type (-native) which are failing Dec 15 15:17:29 Why would Yocto want to build anything for the host system ? Dec 15 15:17:41 build system Dec 15 15:18:41 And even if it does, it should download the source for what it needs Dec 15 15:18:52 Smigers: We do this since we need specific versions of things or things with specific patches applied Dec 15 15:19:29 exactly. If some specific version is required, it should be downloaded and built Dec 15 15:20:36 Smigers: we do this in most cases. There are is one particular exception which is qemu-native Dec 15 15:20:53 What's so special about that Dec 15 15:21:09 Smigers: are you prepared to try something to see if we can make your build work? Dec 15 15:21:35 yes Dec 15 15:22:36 Smigers: specifically, add this line to your conf/local.conf file: Dec 15 15:22:40 EXTRA_OECONF_append_pn-qemu-native = " --disable-sdl" Dec 15 15:22:56 Smigers: then do "bitbake qemu-native -c clean" and then try a build again Dec 15 15:23:17 Smigers: the space between the " and -- is important Dec 15 15:23:24 and what is that cryptic parameter doing ? Dec 15 15:23:45 Smigers: its adding "--disable-sdl" to the configure commandline for the qemu-native package Dec 15 15:24:04 Smigers: the theory being if we force sdl to disabled, it shouldn't need libx11 Dec 15 15:24:23 Don't you think it's lame that you have to leave a space even though you are doing an 'append' Dec 15 15:24:30 Smigers: As I hinted at previously, this option usually "floats", its one of the very few that do Dec 15 15:24:32 but, yes, just a sec, I'll do it Dec 15 15:24:58 Smigers: depends if you'd like to be able to append to something like PATH which is ":" separated... Dec 15 15:28:00 OK, another comment which you'll find objectionable. Why is bitbake parsing ALL the recipes even though I instructed it to work on qemu-native only Dec 15 15:29:54 Smigers: I agree that is something which could at least in theory work more optimally Dec 15 15:30:39 Smigers: In practise there are some tricky issues we'd have to address to make that possible and there are probably more important things to worry about Dec 15 15:31:45 If I can be frank, without you getting annoyed. From what I can tell, this system is way too complicated. Have you ever worked with CMake ? Dec 15 15:32:47 Smigers: The system is complicated, I can't and won't deny that. Equally, it does have some very powerful functionality which only works due to the complexity Dec 15 15:33:31 Smigers: So you get something very powerful but it comes at a price. We have done work trying to simplify and make it more accessible to people, and I agree we still have areas to improve Dec 15 15:34:01 But it's so complicated that even after many hours of working with it I still have almost no clue how it works Dec 15 15:34:35 For example, simply finding the recipe that is failing for me Dec 15 15:34:50 Smigers: that is sad to hear and shows we need to continue to try and improve Dec 15 15:35:12 I had to use 'find' to even begin to narrow it down Dec 15 15:35:40 You know, the top level directory structure itself is confusing Dec 15 15:36:27 Why are there so man meta directories Dec 15 15:36:38 what are they for ? Dec 15 15:36:54 why is there no directory named 'src' Dec 15 15:37:00 Smigers: each one represents a "layer" which should be covered in the manual Dec 15 15:37:25 Smigers: is the build progressing? Dec 15 15:37:35 Yes, I saw that and thought, what is a 'Layer' yes Dec 15 15:37:59 layer ? Dec 15 15:39:03 Smigers: A layer is a collection of configuration data Dec 15 15:39:17 what does that mean. Making up new terminology for a process that is already really very mature (building OS images) is dumb Dec 15 15:39:35 Smigers: the system is extensible as in you can add in extra layers providing extra functionality (hardware support, extra software stack etc) Dec 15 15:40:22 Smigers: if you want help here I'd suggest you stay away from referring to people as dumb Dec 15 15:40:26 I think you mean "the system is extensible as in you can add in extra functionality (hardware support, extra software stack etc) Dec 15 15:41:07 notice I didn't have to use the unfamiliar terminology 'layers' and still communicated exactly the same concept Dec 15 15:41:25 Smigers: I was trying to connect the word layers with its meaning Dec 15 15:41:30 Sure Dec 15 15:41:49 I appreciate that you are being helpful. When I say something is dumb, it's not an attact on you Dec 15 15:42:22 Smigers: Well, in some ways it is as I actually helped write quite some parts of the system in question Dec 15 15:42:39 Smigers: 4 hours are not enough to get the full picture, neither 4 weeks Dec 15 15:43:01 Perhaps, and I apologise for referring to your decisions as dumb Dec 15 15:43:13 wasn't intended as an insult Dec 15 15:44:07 Anyway, so, let's assume the change you have specified in my local.conf works Dec 15 15:47:14 Smigers: FWIW we already have some tweaks to qemu-native in the master branch which will improve things. I want to get the "floating" sdl value fixed down there too Dec 15 15:47:59 Smigers, you owe RP some beer Dec 15 15:48:42 I am still confused about why this qemu-native build would need to look onto my host file system and not into a subdirectory of the build Dec 15 15:49:54 subdirectory of CWD/poky-dora-10.0.0 Dec 15 15:49:54 Smigers: There is a question of which functionality to use from the build system. In this particular case, we assume we can use sdl (which needs libx11) Dec 15 15:50:22 Smigers: we do this since building a working graphics stack for your build system including things like GL can be hard Dec 15 15:50:57 I can answer that really easily, NOTHING should be used from the host unless it's simply impossible to do otherwise. Dec 15 15:51:22 otherwise I have no confidence in what Yocto is building Dec 15 15:51:51 and certainly no source code from the host should ever be used Dec 15 15:51:54 or libraries Dec 15 15:52:17 Smigers: we never use anything from the host to put directly on the target Dec 15 15:52:39 So, why was my build failing Dec 15 15:52:47 Smigers: however using the host graphics stack to display qemu windows when running an image in a VM is different Dec 15 15:53:27 Why Dec 15 15:54:18 Smigers: see what I said above. building a graphics stack for your build system is both very hard to get right and rather pointless Dec 15 15:54:34 (when taking things like GL into account) Dec 15 15:58:50 OK, so what you are saying is that because qemu requires the hosts graphic functionality, it has to link to the hosts libraries. So then I would ask, why is Yocto building a qemu at all ? It's not a pre-requisite for building an OS image. It might be nice to have a virtual machine to run the target image in, but if I choose to do that, then surely, I just download a VM of my choice, and run it. Dec 15 15:59:14 Smigers: correct, that is what I'm saying Dec 15 15:59:35 Smigers: you could remove qemu-native from your build quite easily and do as you describe Dec 15 15:59:47 How ? Dec 15 16:00:33 Smigers: EXTRA_IMAGEDEPENDS_remove = "qemu-native qemu-helper-native" Dec 15 16:00:38 in local.conf Dec 15 16:00:48 I'm telling you, after reading the documentation till my eyes are bleeding, I can#t understand how to do anything as trivial as that Dec 15 16:00:58 What ? Dec 15 16:02:24 Why would I add an env. variable to remove a component from the build process Dec 15 16:03:10 Smigers: I suspect the above won't be enough since we do use qemu elsewhere in the system these days (to run things like postinstalls). The best workaround is the one disabling sdl I gave you earlier Dec 15 16:23:35 Smigers: In case its of interest, I will propose this as a patch for master: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=34c25872532f8453d1681871a0431d5b040d8ff3 Dec 15 16:58:21 OK, I had a look at that patch. Can you explain the design philosophy around these variables. I am mystified as to why you would create a variable like this PACKAGECONFIF[sdl] = "--enable-sdl,--disable-sdl,libsdl," which appears to contain multiple pieces of information, two of which look redundant. Why isn't the presence of libsdl enough to signifiy that sdl is enabled. (and of course by its absence, sdl is disabled) Dec 15 17:13:11 Smigers: we might use sdl in some places but want it disabled within qemu. Presence in the sysroot is not a good indication of whether to enable it or not Dec 15 18:58:37 . Dec 15 19:01:18 No, I mean rather than PACKAGECONFIF[sdl] = "--enable-sdl,--disable-sdl,libsdl," Why can#t you just do somethign like PACKAGECONFIF += "libsdl" to indicate you want to use SLD, and nothing (or perhaps an alternative) if you don't. Dec 15 19:09:16 Documentation issue: Dec 15 19:09:19 laptop poky-dora-10.0.0]$ runqemu qemux86 Dec 15 19:09:21 bash: runqemu: command not found... Dec 15 19:09:23 [laptop poky-dora-10.0.0]$ find - -name runqemu Dec 15 19:09:25 find: ‘-’: No such file or directory Dec 15 19:09:27 [laptop poky-dora-10.0.0]$ find -name runqemu Dec 15 19:09:29 ./scripts/runqemu Dec 15 19:09:32 ^C Dec 15 19:09:34 [laptop poky-dora-10.0.0]$ ./scripts/runqemu qemux86 Dec 15 19:09:36 In order for this script to dynamically infer paths Dec 15 19:09:38 to kernels or filesystem images, you either need Dec 15 19:09:40 bitbake in your PATH or to source oe-init-build-env Dec 15 19:09:43 before running this script Dec 15 19:11:59 I definitely have already sourced oe-init-build-env - in order to build. Dec 15 19:12:07 So, there must be another problem Dec 15 19:12:24 So either the QSG is wrong, or the script is wrong. Dec 15 19:15:04 I think Yocto is an interesting project, but it seems there are some contributors who lack enough real world experience to understand the KISS principle, and how very important that is. Dec 15 19:15:33 I really am struggling to criticise constructively, please don't take offense Dec 15 19:25:46 Unfortunately, as is typical of these type of projects, there is already so much momentum that a dramatic change of course is very unlikely. What is especially worrisome is that at this stage, Yocto represents - from what I can tell - the state of the art i cross platform OS image build systems, yet I see so many problems with it that I am fearful. I am fearful that with its current momentum Yocto will become the default standard, and I'll be f Dec 15 19:25:49 orced to work with it (like gnu 'make'), even though it really is not particularly good, and in fact I could say, it kind of sucks. Seriously, I have not seen anything in Yocto that isn't possible with a few good CMake scripts. And CMake has the advantage of being a mature product with a simple, easily groked, configuration syntax. **** ENDING LOGGING AT Mon Dec 16 03:00:01 2013