**** BEGIN LOGGING AT Mon Aug 18 02:59:59 2014 Aug 18 08:42:56 hi Aug 18 08:44:11 anyone knows about build squid Aug 18 08:45:01 squid 3.1.9 Aug 18 08:45:04 ../compat/os/linux.h:44:28: fatal error: sys/capability.h: No such file or directory Aug 18 08:57:50 can i install squid RPM or should use .tar file and automake Aug 18 10:31:41 good morning Aug 18 12:42:57 when I say make debug in my recipe, does Yocto pass anything more to it, like CFLAGS, CXXFLAGS, LDFLAGS, CC, CXX, etc? Aug 18 13:00:58 can I simply clone the shell environment of a yocto image such that I do make uImage && make modules_install. and it does the same thing as the yocto recipe? Aug 18 13:06:44 Yocto is weird at times. Aug 18 13:27:27 so how is Yocto passing the right compiler to make? Is it through the CC that it sets to arm-...-gnueabi-gcc, etc? Aug 18 13:31:50 why cant bitbake ever find my license file if i put it in the root of my source directory? Aug 18 13:32:08 that is then tar.bz2'd Aug 18 13:32:21 joran_: have you specified the path? Aug 18 13:32:53 i just find a recipe and change it to point to my tarfile source Aug 18 13:33:10 file://myTar.tar.bz2 Aug 18 13:34:04 that is not necessarily enough... Aug 18 13:34:08 then I place the tarfile in meta-test/recipes-mine/currentProj/files//myTar.tar.bz2 Aug 18 13:34:17 the license file might be called differently, or might be put into a different location, etc. Aug 18 13:34:44 it finds the tar file ... but it never seems to be able to find `file://COPYING;md5... Aug 18 13:35:18 even though its in the root of the tarfile Aug 18 13:35:49 try file://${WORKDIR}/... Aug 18 13:36:46 hehe I hope that works that will make life way easier Aug 18 13:36:59 lpapp: for your CC-question: have you tried bitbake -e? Aug 18 13:38:17 silviof: hmm, yeah, it exports CC, apparently. Aug 18 13:40:57 thanks lpapp! Aug 18 13:41:03 silviof: thanks, so do you also know what the best practice to develop software with and without Yocto Aug 18 13:41:32 I mean so far we hard coded the toolchain path in the Makefile, but if I remove that to use Yocto's auto-generated, it will not work nicely when err... try to build the software separately from Yocto. Aug 18 13:42:01 it would be nice if "make foo" was enough in those cases, too, but I cannot see that happening without hard coding the path and/or some chroot alike solution. Aug 18 13:45:03 joran_: no problem; just so that you understand how it goes: my understanding is that if you do not specify the workdir, you tell Yocto to pick it up from the files subdirectory rather than from within the tarball. Aug 18 13:49:31 silviof: maybe the best way is to hardcode the path, but only if CC is empty... otherwise respect that. Aug 18 13:49:49 so that would equally work with Yocto as well as outside of it. Aug 18 13:54:53 im now failing compilation with /ld: cannot open output file testqt: Is a directory Aug 18 13:55:09 I probably (maybe need to set some variable in the bb file?) Aug 18 13:57:03 failing do_compile Aug 18 13:59:05 lpapp: I might be worth your while to use the standard "CROSS_COMPILE" variable in your Makefile, and let CC,LD, etc inherit from it. Just look at the Makefile for the Linux kernel and you'll see what I mean. And then just invoke your make with the correct toolchain. Aug 18 13:59:52 soderstrom: I am actually thinking hard coding the Yocto SDK path since we all install to the same place, I think. Aug 18 14:00:28 ifeq (x$(CC),x) Aug 18 14:00:28 export CC = " ... " Aug 18 14:00:29 endif Aug 18 14:00:52 where " ... " means the complete command similarly to what Yocto generates: export CC="arm-foo-linux-gnueabi-gcc -march=armv5te -marm -mthumb-interwork --sysroot=/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/tmp/sysroots/foo" Aug 18 14:03:46 ehm.. When using yocto it is in general a good idea to always use the oe-init-build-env instead of setting up your own. Maybe the solution you are after is to create your own oe-init-build-env for those times when you do not use Yocto. Aug 18 14:04:37 hmm, not quite oe-init-build-env, just CC. Aug 18 14:04:44 so a very small portion of it, but yes. Aug 18 14:05:09 cause regular developers do not use Yocto, only the one (me and someone else) who work on the final image generation and CI. Aug 18 14:05:19 they just use their local clone, and "make clean; make". Aug 18 14:05:50 but even we do not use Yocto for day-to-day development, just if something needs to be changed in Yocto. Aug 18 14:06:06 (or we need to debug stuff on the target, etc) Aug 18 14:06:24 although even for debugging, Yocto could be avoided to be honest just by flashing the debug image onto the development board. Aug 18 14:07:53 soderstrom: the aforementioned code would go into the makefile. Aug 18 14:08:36 one alternative of course would be to have some SDK setup scripts that every developer runs when opening a shell session and our buildsystem would use the variables set up by such scripts. Aug 18 14:08:57 but as long as we consistently use the same path, that flexibility is not necessary, I think. Aug 18 14:11:29 lpapp: Well ofc the choice is yours, but I would definitly go with the second approach. You might not need the flexability today, but what about tomorrow? .. Aug 18 14:20:36 can I install pepper/qttest-dev-0.0-r4.pepper.rpm? its only creating -dev- and -dbg- versions of my rpm ... Aug 18 14:21:05 is yocto actually using the generated environment-setup-xxx files or is it just exporting them? Aug 18 14:22:04 wrd: those are just exported Aug 18 14:22:23 joran_: that suggests that your do_install isn't installing anything Aug 18 14:22:41 bah thats what I was afraid of :( Aug 18 14:22:56 RP: is there a way to get exactly the same environment as yocto in a shell then? Aug 18 14:23:37 wrd: with or without the build system around? Aug 18 14:23:46 wrd: with the buildsystem the devshell task Aug 18 14:24:00 RP: buildsystem means the compilers? Aug 18 14:24:41 wrd: build system means a checkout or poky or oe-core Aug 18 14:24:53 wrd: as opposed to the sdk Aug 18 14:26:24 RP: I'm fairly new to yocto. I'm not trying to use it, but to extract stuff from it and undertand how yocto builds the stuff so we can replicate the same thing. it's a vendor supplied set of shellscripts thats putting poky into path and then running stuff. so I suppose thats the complete build system. Aug 18 14:27:26 RP: but I guess thats enough hints for me to figure out how to approach this beast. Aug 18 14:28:26 soderstrom: I do not need it tomorrow either :-) Aug 18 14:29:19 wrd: Yocto is no beast, it is a dream come true :) Aug 18 14:29:31 lpapp: Okay then :] Aug 18 14:30:24 wrd: you could have a look at run.do_* in the temp directory under the workdir for the recipe, that should contain all that gets executed for the task Aug 18 14:31:11 soderstrom: I'm not discussing this now. but it's a fairly complex thing and if you know you cannot use it straight away (our infrastructure uses a whole bunch of things). even understanding all the things it does is somewhat challenging. I can imagine that in the right hands it is like a one button wonder factory creating any image you want it to. Aug 18 14:35:29 bluelightning: what is run.do_* ? is it a file ? I'm seeing a lot of layering and I'm not quite sure which of them really get executed. If my brain would be used to understanding yocto I'd not run into the troubles right now. Aug 18 14:36:19 wrd: Yes, we all need to take those initial steps. But you will learn it if you stick around. Aug 18 14:38:50 wrd: It is more than one file, you find the run-files in your tmp/work directory. Well inside the package of interest.. Aug 18 14:45:26 what is the quickest solution for this? http://paste.kde.org/po4cjzuxf/5v1o2h/raw Aug 18 14:45:32 packagegroups conflicting, well, intentionally. Aug 18 14:45:46 one is for debug, and the other is not. Aug 18 14:46:04 bluelightning, soderstrom: thanks that looks promising. Aug 18 14:46:06 is there a way to tell bitbake to move along and replace the current -dbg with non-dbg builds? Aug 18 14:49:16 the error message is not to useful about giving hints what to do, on what packages, etc. Aug 18 14:50:10 wrd: it's a set of files, one per task, e.g. run.do_compile for the do_compile task Aug 18 14:50:41 bluelightning: yeah I see it. it looks like I can replay this file as it a bash script. that does the compile Aug 18 14:51:16 if no one has any idea I will start wiping the build folder away and do a clean build, waiting 1-2 hours, etc. Aug 18 14:51:25 and it looks as if yocto is parsing the bb files in python and generates shell scripts out of it and then executes the shell scripts, right? Aug 18 14:51:53 and probably a dependency resolving scheduler that schedules cores -1 tasks ? Aug 18 14:53:01 lpapp: clean the two recipes? Aug 18 14:53:21 bluelightning: what do you mean? Aug 18 14:53:35 wrd: mostly; not all tasks are shell tasks (some are python) Aug 18 14:54:00 lpapp: you have two recipes producing the same package name; that isn't expected to work Aug 18 14:54:17 lpapp: so clean those two, fix it so that they do not and then continue on Aug 18 14:54:21 bluelightning: that error message does not even list them ... Aug 18 14:54:51 lpapp: it's hard for me to tell given how you've obfuscated the text Aug 18 14:54:51 I already tried bitbake -c cleanall foo--core-image{-dbg}, too, without success Aug 18 14:55:08 cleaning the image will not do anything Aug 18 14:55:10 there is nothing obfuscated there, it is a copy/paste. Aug 18 14:55:25 all the error I got from Yocto. Aug 18 14:55:47 ok, wiping the whole build folder away... let us see in two hours. Aug 18 14:56:22 this is certainly a point where Yocto could be improved. Aug 18 14:57:22 well right now I have no idea how you got into this situation, and if you wipe the build folder out then there's less chance of that happening... Aug 18 14:58:08 I am already writing a bugreport. Aug 18 15:00:43 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6634 Aug 18 15:00:44 Bug 6634: normal, Undecided, ---, richard.purdie, NEW , Bitbake does not give any hint how to resolve conflicting packagegroups Aug 18 15:02:34 bluelightning: it is not really difficult to get into this situation Aug 18 15:02:45 just create a debug and non-debug image, and say, build the debug image for debugging Aug 18 15:02:51 and then try to generate the SDK for the non-debug image. Aug 18 15:03:20 needless to say that the two package groups are nearly the same, but one is git, the other is not, or just different configuration, etc, hence the same files provided. Aug 18 15:04:25 obviously, it is a lot of messing if you have 10-20 overlapping debug/non-debug packages. Aug 18 15:04:38 so I do not want to run -c cleanall for everything if that is at all what I should be running. Aug 18 15:04:46 I would rather prefer a -f option or something like that. Aug 18 15:05:56 bluelightning: and -f does not really work here; still getting the error, so I assume proper -f operation would be a reasonable feature request here, and Yocto could override everything needed. Aug 18 15:06:14 without manually messing with 10-20 packages or potentially more. Aug 18 15:06:46 -f doesn't work that way Aug 18 15:07:01 yeah, sadly. Aug 18 15:07:18 it's not really meant to Aug 18 15:07:30 well, I do not mind if you call it -f or -ff Aug 18 15:07:35 or -whatever, I just want that feature. Aug 18 15:07:46 I currently do not see any more pleasant way for the end user facing this. Aug 18 19:31:11 Hello all, I'm trying to run a dkms image (poky, core-image-minimal, genericx86) and it's stopping on boot, any clues? Aug 18 19:31:33 *vmdk image, sorry long hours Aug 18 20:19:18 hello everyone, I am having a problem regarding dependencies now. Basically, I need some libs from Package A to build Package B. I put Package A as DEPENDS in the Package B recipe, but how do I know where yocto puts the libs that I need? Aug 18 22:11:26 aimetis0: the libs are in staging sysroot Aug 18 22:12:20 aimetis0: check under tmp/sysroots/ Aug 19 02:23:13 im so confused why isnt my do_install running in my recipe? Aug 19 02:24:39 https://gist.github.com/anonymous/c7ab0078c60644f3f81e Aug 19 02:39:45 I guess its running im just not getting an installable rpm from it :( **** ENDING LOGGING AT Tue Aug 19 02:59:59 2014