**** BEGIN LOGGING AT Thu Oct 27 03:00:00 2016 Oct 27 03:14:15 Having a hard time getting opkg installed. Oct 27 03:14:32 libarchive fails | NOTE: make 10 | make: *** No rule to make target '10'. Stop. |ERROR: oe_runmake failed Oct 27 03:26:59 So this seems to happen to any package I add to IMAGE_INSTALL_append Oct 27 03:27:34 or at least with opkg and tiny-vim Oct 27 03:30:09 sounds like you've done something quite odd in your local.conf or recipes Oct 27 03:34:37 You are right! I set PARALLEL_MAKE = "10" instead of -j 10 Oct 27 03:34:51 hmm, I wonder if we should validate that Oct 27 03:36:40 instead of PARALLEL_MAKE it seems like it would be more aptly named MAKE_ARGS Oct 27 03:37:58 well it is meant to be single-purpose Oct 27 03:38:17 I don't think any sane person would use it to pass anything other than -j Oct 27 03:38:37 Well, not on purpose maybe ;-) Oct 27 03:38:48 :D Oct 27 03:39:15 the syntax is a little bit weird I do agree though Oct 27 03:39:49 agreed Oct 27 03:42:52 MAKE_ARGS tells me not what it is supposed to be for, but is more clear as to what is happening to the build process. PARALLEL_MAKE would be a better option, but if it is for a single purpose then it seems intuitive to not require -js Oct 27 06:40:57 hi all, how to prevent yocto checksum a file, my SRC_URI point to an local file. In case file not exist warning about checksum always occur Oct 27 06:42:53 example: LOCAL_MIRROR ?= "file://." SRC_URI = "${LOCAL_MIRROR}/software/test.tar.gz" Oct 27 06:43:39 in parse process yocto always check and return warning about checksum, if test.tar.gz not exist Oct 27 08:28:35 denix: just add to src_uri, or how to do it with the mapping file. confused. Oct 27 09:44:14 hey guys, I was wondering. Is there a better way to compile your device tree after you've changed it in your devshell than calling make *.dtb in your devshell? Is there an alternitive task which can only compile the device tree? something like: bitbake -c compile_dtb linux-yocto ? Oct 27 10:39:32 license issue Oct 27 10:40:00 I have this error: This recipe does not have the LICENSE field set Oct 27 10:40:31 you need to set it then :) Oct 27 10:40:56 but there is a commit on github that says: Oct 27 10:41:00 The packagegroup does not use source code so there is no logic Oct 27 10:41:00 in the recipe to use a license. Remove it from the recipe. Oct 27 10:42:35 set it to 'CLOSED' Oct 27 10:42:39 if you need to Oct 27 10:56:27 CTtpollard: ty Oct 27 11:11:17 doing DISTRO_FEATURES_remove = "x11 wayland" Oct 27 11:11:52 imply that there also will be removed x11/wayland possible packages? Oct 27 11:12:02 basically yes Oct 27 11:12:09 ok Oct 27 11:12:14 well, you will not be able to build them Oct 27 11:21:46 is it possible to disable sstate in a package recipe (aka do not do an sstate for it) ? Oct 27 11:21:46 first shot idea would be to empty the do_sstate* in a bbappend ? Oct 27 11:22:23 hmm, sstate is a class, so remote from inherit ?! Oct 27 11:25:08 it's added to the global INHERITS Oct 27 11:26:36 dl9pf: I guess the obvious (& annoying) question at this point is... why do you want to do that? Oct 27 11:33:15 why there are so many tutorials on the net that are using local.conf to add features & packages? I do that on my recipe image, which would be the right way? Oct 27 11:34:07 I mean, local.conf is a "general" configuration that apply for all recipes, isn't? Oct 27 11:34:30 jku: no sstate for a package ? Oct 27 11:35:07 dl9pf: yeah Oct 27 11:35:56 I don't want to keep it Oct 27 12:33:53 Hi! How can I start the opkg postinstall log for the first boot? I do have the "debug-tweaks" enabled Oct 27 12:44:41 I have the strangest of errors: We make a so library which use pthread_create() from it's cpp. In the recipe libpthread was forgotten. However the recipe compiled successfully, but it segfaults on target. Oct 27 12:45:42 I've traced down the .o file and the .so file and both show unknown symbol to pthread_create(), yet ldd on target does NOT show dependency to libpthread. So why didn't this fail during compilation? Oct 27 13:00:13 I have made changes on my layers (removed them and added news) and now can't clean Oct 27 13:00:38 --force didn't work Oct 27 13:23:56 what do I need to do to force fetching a repo from upstream? Oct 27 13:25:44 The use case is that I change the rev= in SRC_URI in a recipe (using hg) and push the meta layer. The build server rebuilds by wiping tmp/ completely, but retains downloads and sstate. It then often fails to build, as bb fetches the repo from downloads rather than pulling the updated repo from upstream, and thus the build fails Oct 27 13:27:06 In the sake of build server automation, I'd hope that -ccleanall on specific recipes can be avoided Oct 27 13:41:49 found it: LAYERDEPENDS_ was point to the old layer Oct 27 17:25:28 Is this a good place to ask questions? Oct 27 17:26:32 sure Oct 27 17:26:36 I ask questions here sometimes. Oct 27 17:26:46 I can't Convince my recipe to put the .so file produced by the recipe into sysroot. It seems like this happens automagically with do_populate_sysroot, but it does not identify it and pop it in sysroot Oct 27 17:26:48 Sometimes there are answers. Sometimes the answers even show up the same day! Oct 27 17:26:58 :D thanks Oct 27 17:28:11 I have a feeling this is a oneliner, like inherit this or that, or do_populate_sysroot_append Oct 27 17:28:43 you haven't shared a recipe or information on where your .so actually is Oct 27 17:29:36 I Imagine you don't want me to spam it in here, so where do you guys usually collaborate Oct 27 17:29:59 Its not comitted publicly at this point I'm working on getting it to compile :) Oct 27 17:30:12 I recommend gist, usually, for posting text files and the like. Oct 27 17:33:50 https://gist.github.com/strike5150/c61b2b6a0433ba8b9bf23fbe3eab3375 Oct 27 17:34:28 Thanks for the tip neverpanic Oct 27 17:35:14 /usr/local is not part of Yocto's normal packaging routine Oct 27 17:35:35 I'd recommend not to use /usr/local though, since you're building the completely platform, where you should just be putting things in /usr Oct 27 17:35:54 Also, use ${prefix} or ${libdir} Oct 27 17:36:08 ok I'll give that a try, so its basically not picking it up because its notlooking Oct 27 17:36:12 at least not there Oct 27 17:37:29 And yes, paths in /usr/local are not automatically staged into the sysroot, see http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/staging.bbclass#n51 and the value of $SYSROOT_DIRS for why those are not showing up in the sysroot Oct 27 17:37:57 thank you <3 Oct 27 17:43:34 clear Oct 27 18:16:14 http://oldcomputers.net/pics/macportable.jpg Oct 27 18:16:17 oops wrong page Oct 27 19:08:25 Hi. Anyone know if there's a way to get yocto/bitbake to generate a list of needed download files for an image? Oct 27 19:12:41 you can certainly write a custom task in a bbclass that prints this information from SRC_URI, use INHERIT += "yourbbclass" in local.conf, provide a recursive task and run bitbake -c yourrecursivetask $image Oct 27 19:12:47 Not sure if there's something prebuilt already Oct 27 19:15:19 ok, thanks. May be quicker just to copy all 19G of source tarballs into my new build VM. :) Oct 27 19:15:51 could use archiver for that, in symlink mode Oct 27 19:16:04 configuredd to keep original files, anyway Oct 27 19:16:28 Or, just share the download dir with your VM, or set it as premirror? Oct 27 19:19:21 Trying to move my regular build env onto a laptop for an offsite meeting tomorrow. Will just copy the whole dir, ta. Can play with nicer things when I've more time. Oct 27 19:22:55 I'm using the following cmake, and yocto/bitbake doesn't seem to find c++ includes without specific directives. Oct 27 19:22:59 https://gist.github.com/strike5150/4fd8eee9db0170d9458ac30dea1701f8 Oct 27 19:23:13 :q Oct 27 19:24:59 the corresponding recipe https://gist.github.com/strike5150/dfd38ce4e49f24c007f1dd5a860cc959 Oct 27 19:26:20 kergoth: archiver class is only mentioned a bit briefly in the manuals, afaict, but looks interesting. I guess you need to look at the bbclass to see info on symlink mode. Oct 27 19:26:40 neverpanic: premirror of the old DL_DIR to get a new clean one seems like a nice plan. Oct 27 19:28:59 Strike5150: don't just set(CMAKE_CXX_FLAGS), that's bad practice, and it overwrites any of the flags Yocto might have for you Oct 27 19:29:47 Also, your include_directories(${CMAKE_INSTALL_INCLUDEDIR}...) statements are probably useless, because that'll be /usr/include on a cross-compile build, but that's not where the headers are Oct 27 19:29:59 actually, that's harmful, because you might have system headers there, which leads to host contamination Oct 27 19:30:58 arkver: Yes, make your DL_DIR available as premirror, then run -c fetchall $image Oct 27 21:45:59 * armpit kicks off krogoth-next build **** ENDING LOGGING AT Fri Oct 28 03:00:00 2016