**** BEGIN LOGGING AT Tue Feb 23 02:59:58 2016 Feb 23 07:39:36 Hi everyone. I have followe step by step what to do to compile dey-image-graphical but as soon as I start I get an error : OE-core's config sanity checker detected a potential misconfiguration,,,, Feb 23 07:39:46 Its the third time I tried this Feb 23 07:40:56 ive added this to conf/local.conf Feb 23 07:40:57 CONNECTIVITY_CHECK_URIS = "" Feb 23 07:47:36 cart_man: care to point us at the guide to revisit it? Feb 23 07:49:05 LetoThe2nd: Its a guide from Digi ... its on PDF form but I will try and get a link somewhere in it Feb 23 07:50:45 LetoThe2nd: Which Linux distro was the most thoroughly tested to build Yocto on? Feb 23 07:51:18 cart_man: probably ubuntu or something red hat Feb 23 07:51:50 LetoThe2nd: I am building Ubuntu and I get warnings that its not well tested Feb 23 07:51:55 cart_man: but i doubt its the host platform, it sounds more like some whacked custom layer. Feb 23 07:52:15 cart_man: the warnings show if you are using a release that is not officially validated. Feb 23 07:52:17 Well its for the ConnectCore 6 IMX board. They do have a layer yes Feb 23 07:53:41 LetoThe2nd: Repo - > repo init -u https://github.com/digidotcom/dey-manifest.git -b refs/tags/1.6.5 Feb 23 07:54:04 cart_man: just show me the guide, please. Feb 23 07:54:52 cart_man: another option would be to properly pastebin the full error message, not just "detected a potential misconfiguration,,,," Feb 23 07:54:59 usually OE is quite verbose there. Feb 23 07:57:07 LetoThe2nd: Ok I will do that... thing is its PDF form so I can either give you a dropbox link or email Feb 23 07:57:40 cart_man: why can't you just drop it onto a free host? or copy the contents out? Feb 23 07:58:10 cart_man: or if that is all too complicated, just pastebin the full error log so people can see what failures you are facing? Feb 23 07:58:57 http://pastebin.com/FQYbQWby Feb 23 07:59:47 cart_man: well so whats the problem? read the error message, and find: "Please install the following missing utilities: makeinfo" Feb 23 07:59:52 LetoThe2nd: Take note that makeinfo and libsdl-native is installed Feb 23 08:00:00 No it is installed Feb 23 08:00:33 cart_man: and this is a vanilla 15.10, or whacked into some kind of container, weirdo environment or such? Feb 23 08:01:00 LetoThe2nd: Yip Ubuntu that I have installed in a VM just for Yocto Builds Feb 23 08:01:27 cart_man: OTOH its of course possible that 15.10 broke something. I'd give it a spin on 14.04, which is probably one of the most used host platforms. Feb 23 08:01:44 I however had to install libsdl1.2-dev instead of libsdl-native since it just did not find the package Feb 23 08:01:50 LetoThe2nd: Hmm ok cool will do that then Feb 23 08:02:29 mabye 15.10 tinkered with some paths or stuff, not impossible. Feb 23 08:02:39 care to report back after giving 14.04 a try? Feb 23 08:06:41 LetoThe2nd: No problem will do ! I have successfully compiled a Yocto version for a Beaglebone soo I know it works Feb 23 08:06:58 Just have to do it for the IMX board. WIll keep you updated Feb 23 08:07:24 thanks. its just that when we see that error again, we can maybe realte it to 15.10 Feb 23 09:23:46 good morning Feb 23 10:10:18 So we moved to Jethro and have massive problems while building on our build server which has 32 cores and runs 64 threeads in parallell. This did work without problems in fido, but now we only get a full build if we throttle it to 20 threads in the local.conf is this something known? Feb 23 10:39:52 Jeena, what are the exact messages you get? Feb 23 10:45:53 Hi , I got do_preconfigure) failed error, can some one help as to where i'm going wrong http://pastebin.com/XBGrqccp Feb 23 10:46:28 its for /recipes-devtools/gcc/gcc-source_4.9.bb: Feb 23 11:08:53 LetoThe2nd: Ok so 14 gave no problems soo far... exact same steps followed . Only one failed Fetch attempt so far. Feb 23 11:09:33 cart_man: ah great, thanks! probably something in 15.10 pacakging changed, then. Feb 23 11:34:08 Crofton, it breaks at different things every time we run it. We also kind of suspect that 32G of RAM could be not enough Feb 23 13:31:22 Does the Yocto PCI driver work? Is there something I Should add to the build to enable it to work? What about USB3 ? Feb 23 13:32:09 LetoThe2nd: ^^ Feb 23 13:40:16 Jeena, check the logs and see if you trip the OOM killer maybe Feb 23 13:40:35 Crofton|work: Me? Feb 23 13:40:39 Oh nvm Feb 23 13:48:00 Hi all. I'm fairly new to yocto and i was wondering, how to actually properly develop packages in a yocto based project. Can i just directly edit the sources in the yocto working tree once they're actually cloned from a git repo? Feb 23 13:48:32 Or is it more common to actually checkout the repo to some other directory, edit it there and let yocto it fetch and build again? Feb 23 13:48:41 fetch it* Feb 23 13:50:20 does yocto do something that disables the package repository (~/.cmake/packages/*) for cmake projects? Feb 23 13:50:53 find_package() doesn't seem to find packages from there Feb 23 13:51:20 and yeah, it's a bad idea to store stuff in ~ anyway Feb 23 13:51:30 i just want to understand the root cause of a failure i'm seeing Feb 23 13:51:55 Crofton, yes it seems we really do, we don't have swap on this machine either Feb 23 13:52:17 hello internet Feb 23 13:52:39 I guess the easiest way to fix it is to order more ram, like 128G instead of just 32G Feb 23 13:52:54 how to display target image in the bitbake help message? Feb 23 14:13:46 Jeena, or add swap. May only be peak times that need it. of course more RAM is always good, especially for hi thread counts Feb 23 14:26:33 Ulfalizer: yes, yocto does its very best not to find stuff in ~ or /usr Feb 23 14:26:45 (native stuff can link to /usr obviously) Feb 23 14:35:57 yeah, guessed that was the case, though i can't find the exact thing that disables it Feb 23 14:37:00 CMAKE_FIND_ROOT_PATH(_MODE_PACKAGE_ONLY) maybe... Feb 23 14:52:37 Crofton|work: i don't suppose you remember why you had to sed libtool in a484b35b? Feb 23 15:23:24 Good morning gents! I have a directdisk.wks to append/modify part and bootloader options. What option do I need to get PROMPT 1? It defaults to PROMPT 0 and therefore I can't hit esc to get boot: ?? Feb 23 15:38:09 khem`: is argp-standalone needed for uclibc? Feb 23 15:55:40 rburton, I'll bet you have an rpath qa issue without the sed Feb 23 15:55:41 maybe Feb 23 15:58:38 Crofton|work: no warnings at al Feb 23 16:00:05 did you try removing it? Feb 23 16:01:24 yes, done already Feb 23 16:01:48 hmmm Feb 23 16:02:23 did you look at th elibtool to see what it does? Feb 23 16:03:04 seems liek the problem is we needed the c++ version of db, but if we left it i nthe main db package, peopl eusing db had stdc++ lib added to images Feb 23 16:05:50 hmm, I am getting db6 in builds now also Feb 23 16:05:52 not 5 Feb 23 16:24:05 yeah that makes sense Feb 23 16:24:14 (the package split) Feb 23 16:28:08 this was 2 years ago :) Feb 23 16:28:46 pah Feb 23 16:30:27 man bitbake needs a way to inject -x into shell scripts without tainting hashes Feb 23 16:31:48 patch bb.build to obey a new flag to to do it? Feb 23 16:32:34 yeah Feb 23 16:33:54 course i could see having a variable as well to set the default Feb 23 16:35:16 oh look Feb 23 16:35:31 it can do it already :) Feb 23 16:35:38 heh, nice Feb 23 16:35:40 enable loggerVerboseLogs Feb 23 16:36:15 BB_VERBOSE_LOGS=1 by the look of it Feb 23 16:36:46 that totally needs to be a command line option so its even a bit discoverable Feb 23 16:37:02 agreed Feb 23 16:37:45 huh. apparently i knew about it at some point, because i already had 'ag loggerverboselogs' in my shell history Feb 23 16:37:48 weird Feb 23 16:38:08 heh Feb 23 16:39:12 i'm always finding things i forgot about. dig through my dotfiles and find long forgotten aliases and vim tidbits Feb 23 16:39:13 heh Feb 23 16:45:11 is there some nicer way to get a list of layers from the command line than parsing the output of bitbake -e? Feb 23 16:45:36 bitbake-layers is probably a good start Feb 23 16:46:05 heh, should've checked what options it has :) Feb 23 16:46:11 * Ulfalizer checks Feb 23 16:47:42 too bad it doesn't seem to have a simple format with e.g. one layer name per line :/ Feb 23 16:47:52 'bitbake-layers show-layers' that is Feb 23 16:49:17 heh, yeah, it should probably have a format that's easier to script Feb 23 16:50:11 bitbake -e | sed -n 's/^BBLAYERS="\(.*\)"/\1/p' | tr ' ' '\n' | grep -v '^$' is what i have so far to get one layer name per line :) Feb 23 16:50:50 it's for a testing thingy that verifies naming conventions Feb 23 16:51:02 layer name and layer path are two differentn things, keep that in mind Feb 23 16:52:04 hrm, yeah, i should probably keep just the name Feb 23 16:52:32 i.e the name in BBFILE_COLLECTIONS is used in LAYERDEPENDS, but is sometimes different than the path on disk Feb 23 16:52:41 openembedded-layer is meta-oe, for example Feb 23 16:52:45 really depends on what your goals are Feb 23 16:53:16 i have a sed snippet to grab bblayers from bblayers.conf, but it assumes it's one block.. i also have a little python script that given a layer path will dump the info from layer.conf, name, priority, deps Feb 23 16:53:36 mostly refactoring some existing tests atm. they seem to look at BBLAYERS only. Feb 23 16:54:33 cool, that's easier. parsing bitbake -e seems like a resasonable way to go in that case Feb 23 16:55:32 had forgotten that layers names could be different from directory names too Feb 23 16:55:37 *layer Feb 23 16:56:05 probably doesnt' matter if all it goes by is BBLAYERS, but yeah, still goodt o keep in mind for future reference Feb 23 17:23:27 does anyone actually use udev-cache? Feb 23 17:30:02 Hm, anyone gotten nativesdk-ncurses building for mingw? Feb 23 17:37:51 rburton: judging by the patches, NI are using it or wanted to... Feb 23 17:38:18 yeah remembered that Feb 23 17:38:37 rburton: it does make a difference Feb 23 17:52:53 hmm, wonder if we should add SDK_OS to the PN of the crosssdk recipes, to let you switch SDKMACHINE between linux and mingw without sysroot conflicts. at least i'm assumign thats why there's the SDK_ARCH suffix, for the same reason Feb 23 17:53:04 * kergoth tests Feb 23 18:32:46 kergoth: SDK_SYS even? Feb 23 18:32:59 yeah, it has arch now Feb 23 18:33:11 right Feb 23 18:47:22 So, I've been staring at the pseudo startup code, and the pseudo client spawn-server code, and I have concluded that they are probably broken, and I am going to go duct tape something over my keyboard to prevent me from producing code, and stare blankly into space for a while, and see if I can figure this out. Feb 23 18:47:40 But I think that, if I really want this fixed properly, I should almost certainly rewrite that code. Feb 23 18:48:28 the big problem I saw, is there is possibilities of race conditions, but I wasn't sure if they could be avoided.. between the pid file, socket, etc.. Feb 23 18:48:37 you can't 'cleanup'' the best you can do is oveerwrite Feb 23 18:48:49 Yeah. Feb 23 18:49:21 But there's a ton of things where I'm pretty sure the current code is logically-incorrect, where I didn't think through what I was checking or where stuff might get run once or maybe twice depending. And there's a few places where I should absolutely be error-checking. Feb 23 18:49:40 And basically, I want to think this through carefully and be sure of what I *intend* it to do, and then go look and see whether or not it's doing anything much like that. Feb 23 18:49:43 Huh. Feb 23 18:50:54 *thinks* Okay, no, that one should be safe. There's a lockfile, and the server doesn't mess with the pid file or socket outside of having acquired the lock. Feb 23 18:50:56 ... the lock. Feb 23 18:50:59 Heyyyyyy. Feb 23 18:51:16 Those build servers don't happen to be using NFS, do they? Feb 23 18:51:40 Because we're using flock() for the lock, and NFS only supports fcntl locking. But fcntl locks aren't inherited by child processes, which is why pseudo doesn't use them for the lock. Feb 23 18:51:59 Because the daemonized server is a child process from the thing which acquires the lock. Feb 23 18:52:09 that was the one thing I was worried aobut.. if the lock is taken BEFORE the spawn, does the parent take the lock with them, opening a window? Feb 23 18:52:49 The lock is done inside the server, the client doesn't do it. So if the client spawns a server, the server grabs the lock and tries to start up. Feb 23 18:52:59 cause take lock (clear on exit), open socket (exit on failure), write pid SHOULD be correct from a race point of iew.. Feb 23 18:53:06 as long as two things don't get the lock at once Feb 23 18:53:21 Hmm. But I exit with status 0 if I don't get the lock, and that could be wrong in some cases. Feb 23 18:53:23 yup.. the client only checks the pid file.. Feb 23 18:54:02 exactly.. if there is a fail between grabbing the lock and NOT writing the pid (exit).. we shoudln't have a 0 RC.. and we should log what the hell happeend.. Feb 23 18:54:11 But it is worth checking to be sure we trust that flock() will work on the filesystem. And if it might not, maybe I should try to restructure this so that the locking happens in the daemonized process so we could use fcntl. Feb 23 18:54:14 (same if we can't grab the lock since it's already in use) Feb 23 18:54:31 likely a good idea to move the log to the child Feb 23 18:54:47 If the lock is already in use, we treat it as a non-error because it's *probably* an existing server, and "a server was successfully started" is probably-not-an-error. I think. But if I fail for some OTHER reason, that should be treated as a failure. Feb 23 18:54:50 or don't daemonize the server if called from the child, since it's already forked? Feb 23 18:55:39 'er.. that probably isn't right.. since you'd lose any failure codes Feb 23 18:55:40 Well, right now, the client is using "the process I spawned terminated" as the test for "server has probably started". Feb 23 18:55:48 ya Feb 23 18:56:21 Hmm. Feb 23 18:56:43 Okay, so, it looks to me like there's a very small window where the spawned server could blow up and I might have issues with the logging... Feb 23 18:56:49 But basically, yeah, I wanna rethink this. Feb 23 18:58:03 See, this is the ideal point for me to go shovel snow or something, but it all melted. But I'll go do something physical for a while and ponder it to get my head clear. Back in a while, and I will probably rewrite a fair bit of this. Feb 23 18:58:34 The client-side logic has at least one obvious thinko, although I think it produces the right results (or should), but that tells me I didn't understand the problem when I wrote that code, so.... Feb 23 21:45:32 hmm, we should probably move the STAGINGCC var set to somewhere common, given how many recipes are copying/pasting it around **** BEGIN LOGGING AT Tue Feb 23 23:00:36 2016 **** ENDING LOGGING AT Wed Feb 24 02:59:58 2016