**** BEGIN LOGGING AT Mon May 22 03:00:02 2017 May 22 06:50:44 good morning May 22 07:04:55 I can hear the groans ! May 22 07:35:51 It seems like any file, whether it be a .conf, .bb, .bbclass, etc, can be used for just about anything. The naming convention is a hint for how they are used. May 22 07:47:11 morning all May 22 07:48:03 morning May 22 07:54:58 Reading through oe-buildenv-internal, I am a bit confused about the three python version checks: https://pastebin.com/WM4Fb0TM Why 3, why not just a single check for version 3.4.0 or greater, since that's what bitbake apparently requires ? May 22 07:57:08 Smitty_: oe needs both python 2.7.3 and python 3.4.0. And 'python' must be python 2, on some distros (e.g. Arch Linux) it is not. May 22 07:57:28 Smitty_: thus why the three checks need to be made May 22 07:59:24 So, the requirement for python 2.7.3 is not from bitbake, rather from existing (python) scripts within oe-core (and dependent projects) ? And those scripts don't behave correctly with python 3 ? May 22 08:00:40 yes May 22 08:01:23 nightmare May 22 08:02:18 python and python3 might be related but they are different languages... May 22 08:03:27 Another totally unrelated question. I read that nfs mounted file systems can't be used for build directories. Why would such a restriction exist ? Why would a user app care what file system was in use ? May 22 08:07:05 Smitty_: TMPDIR can't be on NFS I think (can't remember details but symlink behaviour differences maybe?) May 22 08:07:59 but you also wouldn't want that: TMPDIR should be on the fastest disk you have May 22 08:10:14 but SSTATE_DIR and DL_DIR should be fine (and those are the ones that might make sense to put on network disks IMO) May 22 08:11:25 symlinks apparently are problematic across mountpoints - I didn't realize that. I thought that restriction was for hardlinks. May 22 08:12:24 Good morning =D May 22 08:32:02 The symlink issue makes sense. Since a symlink can contain a path (absolute or relative ) to a location in the destination file system that doesn't exist in the clients "view" of that filesystem. Never thought about why, I always simply said, "OK". May 22 08:35:55 So, back to oe-init-build-env. It seems my initial understanding of the purpose of this (along with oe-buildenv-internal, and oe-setup-builddir) was wrong. rburton - and others - told me that sourcing this file was essentially optional. At first I didn't understand how that could be. After all, every example uses it, and besides it processes bblayers.conf.sample, and creates build dir. May 22 08:44:26 What really should happen is that the oe-init scripts be setting up the environment to point to a totally correct bblayers.conf located inside source dir not move it into builddir. bitbake should just use what it finds in source dir May 22 08:49:43 Smitty_: and what source dir should that "totally correct" bblayers.conf come from? May 22 08:49:58 E.g. my current build has the poky layers and meta-intel in BBLAYERS -- what source repo could have known I want those but not meta-oe which is also cloned. May 22 08:57:29 I guess what I am saying, is that since bblayers.conf really only sets BBPATH (which I find a bit strange), BBFILES and BBLAYERS. The latter really control what is getting built. May 22 08:59:06 Morning, Could someone help me out with MariaDB? I installed it from the yocto recipe(meta-oe layer) but when i want to run it it says it can't find mysqld_safe_helper. Besides that when i run 'mysql' it says it can't connect to the local MySQL server socket "/var/lib/mysql/mysql.sock" May 22 08:59:32 hi, Im having issus with building gdb_7.10.1.bb im getting: /usr/src/debug/gdb/7.10.1-r0/gdb-7.10.1/gdb/completer.c:1615: undefined reference to `_rl_completion_prefix_display_length' May 22 09:00:28 @all quick and dirty -> add to you setup-environment file to list all image recipes : https://pastebin.com/ymSLQsQw May 22 09:02:54 PinkSnake: how does that differ from the output of bitbake-layers show-recipes "*-image-*" May 22 09:03:03 MarcWe: on an old poky? May 22 09:03:41 Smitty_ : it differ that the script is made for developper engineer May 22 09:03:48 yes krogoth May 22 09:04:03 Smitty_ : For example you will launch this script, it will source the oe init build dir and also give to the client the list of images. May 22 09:04:15 jku: yes on krogoth May 22 09:04:59 Smitty_ : For client OR developper engineer May 22 09:05:47 That's what "bitbake-layers show-recipes "*-image-*"" does May 22 09:06:15 @Smitty @ChrysD +1 and script is faster than your cmd and doesn't use bitbake tools ;) May 22 09:06:51 OK, so when you don't rely upon bitbake, how do you know the image is really available ? May 22 09:06:55 MarcWe: I'm not familiar with this but see poky commit 07c4bc109d51 -- maybe you can remove "readline" from PACKAGECONFIG to make it work? May 22 09:06:58 Smitty_ : it's not that May 22 09:07:07 Smitty_ : You can't ask for your client or dev team to know bitbake May 22 09:07:08 Becasue unless bitbake sees it as an image, it's not an image May 22 09:07:22 @Smitty and i don't care about poky and oe images May 22 09:07:59 Smitty_ : In my case, i use a script which I simply launch, and give me the all command to launch so that I don't need to care of bitbake or yocto May 22 09:08:06 @Smitty it's my job to keep repos clean so i know exactly which images are really available :P May 22 09:08:14 Smitty_ : So that for example, the marketing/commercial team can even do them itself. May 22 09:10:19 Smitty_ : Sometimes we need to do some kinds of scripts to simplify tasks for people that are not platform engineer/developper May 22 09:12:53 jku: cant finde the commit. May 22 09:15:03 ed2: is it part of your plans for wic to get replace the wic-tools->grub-efi+syslinux dependency? May 22 09:15:39 Not all images built with wic need those, so a better place would be in the per-image dependencies. May 22 09:16:37 pohly: The problem here is how to build images depending on syslinux manually with wic. May 22 09:17:28 pohly: i still don't have good solution for this May 22 09:17:58 ed2: perhaps "wic-tools" should be reserved for this "use wic manually" case and automatic building via bitbake should use something else ("wic-tools-light") or no wic-tools at all? May 22 09:19:30 Then "manual mode" uses wic as a generic tool that works for multiple images (at the expense of having to build things with might not be needed), while building through bitbake can be as efficient as possible for the desired images. May 22 09:19:56 this makes sense. it would require to build wic-tools manually, but anyway it's better than building unneeded recipes. May 22 09:21:19 pohly: I'll try to remove wic-tools from deps. having a bug for that would speed this up, btw :) May 22 09:22:02 ed2: I wanted to check first whether you already have one ;-) I'll file one. May 22 09:24:27 all: does anyone see this build error in master-next for beaglebone machine? https://gist.github.com/bartosh/741ea816bf944e2601c51fdc3c865010 May 22 09:26:17 all: I've just seen it on qemux86-64 machine too. hmmm. May 22 09:36:54 jku: ty May 22 09:46:08 It seems my PATH is being manipulated to be incorrect - by the build, not by me: https://pastebin.com/hRFuwkrB May 22 09:48:09 Smitty_: bitbake doesn't support to be called by relative path May 22 09:48:12 you must May 22 09:48:25 1/ . oe-init-buildenv <--- this command gonna: May 22 09:48:42 a/ setup your PATH to point to bitbake binaries directory etc... May 22 09:48:52 b/ move your shell to your build/ sub-directory May 22 09:49:05 2/ launch your build by using bitbake May 22 09:49:32 Unbelievable. May 22 09:49:58 Smitty_: Yocto and bitbake are massively based on shell scripts May 22 09:50:14 and, as you probably know, shell scripts isn't the more powerfull language May 22 09:50:36 that kind of "limitations" aren't SO unbelievable :) May 22 11:31:38 error: cannot run git-proxy: No such file or directory I have git-proxy script in my PATH after sourcing oe-init Why this error ? May 22 11:38:59 @Smitty git:// to https:// ? May 22 11:59:51 I was able to get around the problem with git, by changing the SRC_URI to use https instead of git. Now I get this instead: ERROR: mobile-broadband-provider-info-1_20170310-r0 do_populate_lic: QA Issue: mobile-broadband-provider-info: LIC_FILES_CHKSUM points to an invalid file: /local/smitty/custom_distro/build/tmp-glibc/work/i586-oe-linux/mobile-broadband-provider-info/1_20170310-r0/git/COPYING [license-checksum] May 22 12:01:37 Well, now the source code seems to have changed, so the change was either not transparent, or the recipe does not specify a specific git hash to use and the COPYING file was updated. May 22 12:12:24 Ah, so, if I do a "git pull" , then after some time the source changes, then I attempt a build, bitbake fetches the source, but, now the hash is different that what my meta-data says it is, so bitbake errors ?? Is that what's happening ? May 22 12:25:57 So, performing a git pull within my top level project directory appears to have updated whatever the problem was. BUT, now I get this: DEBUG: Executing shell function do_compile NOTE: make -j 56 ERROR: oe_runmake failed make: *** No targets specified and no makefile found. Stop May 22 12:26:09 for that same project May 22 12:29:30 Smitty_ : Have you checked that you have everything now in your git repo? May 22 12:29:50 Smitty_ : look to your do_compile May 22 12:54:19 Thinking that the problem may be an out of date meta-data I cd'd into my project top level meta data directory, ran git reset --hard HEAD May 22 12:54:53 then ran git pull ----recurse-submodules=yes May 22 12:55:02 then cd'd into my build directory May 22 12:55:34 run bitbake, then get the original error: ERROR: mobile-broadband-provider-info-1_20170310-r0 do_fetch: Fetcher failure for URL: 'git://git.gnome.org/mobile-broadband-provider-info'. Unable to fetch URL from any source. May 22 12:57:37 Since many, many other subcomponents (.bb files) also contain git://git.gnome.org in their fetch url, this must be an error in that particular module May 22 12:58:48 Smitty_: I think your fetch was never successful, despite your sed -E 's#git://#https://#g' May 22 12:59:17 Smitty_: At least that would explain the hash mismatch in COPYING (e.g. when the file isn't there at all), and your compile failure (no Makefile, no targets, make errors) May 22 13:00:02 actually, it seems that within oe-core only two modules use git://git.gnome.org recipes-connectivity/mobile-broadband-provider-info recipes-graphics/cantarell-fonts May 22 13:00:37 OK, so how do I force a correct update ? May 22 13:00:50 I mean of my meta May 22 13:05:45 What do you want to do? Set the state of your working copy of the meta layer containing recipes to the upstream state, or re-run the fetch phase for the recipes that failed? May 22 13:07:56 I guess I want to make sure that my meta is up to date, then re-run the build. I hope that would update any referenced URLS May 22 13:09:56 Not only "up to date" but pristine. So, I just moved my originally checked-out met to a new directory, then ran git pull on the project https://github.com/rossburton/customdistro.git then attempt to run "bitbake customdistro" and still the same issue May 22 13:10:23 so, maybe I need to force bitbake to do a fresh pull on that module ? May 22 13:10:34 how is that accomplished May 22 13:10:48 I expect that to happen automagically May 22 13:11:09 Hi, looking for hint... I'm building SDK package for some 2.1 based yocto tree software set. Here I got some success. However I need to include the rootfs image (as archive file) into SDK... May 22 13:12:50 person_from_web: I may be a beginner here, but what you're asking for sounds like a very strange request. Why would you ship the rootfs image within the SDK image ? Why can't they be two files, if needed in a super-archive May 22 13:13:15 100% - aggree :) May 22 13:13:48 Smitty_: git clone git://git.gnome.org/mobile-broadband-provider-info works fine for me, so sounds like the problem is with your network? May 22 13:14:44 Ahh, yes, I didn't consider that, I'm actually back to the original issue of not having a correctly configured git proxy May 22 13:14:45 Smitty_: Alternatively, you can change the SRC_URI to git://git.gnome.org/browse/mobile-broadband-provider-info;protocol=https May 22 13:15:18 I'd rather configure my git proxy to work correctly, to avoid further errors May 22 13:15:24 of the same form May 22 13:16:28 However, it is rather about "end-developers" control... You know, if you giving them more than one image, they immediately will mess up everything... And in my situation consistency of the image and sdk is quite important May 22 13:18:35 So I'm looking for a possible way, how to bundle the image togather with SDK.... The only thing comed to my mind is to use shell script for finding actual archive in particular directory :) May 22 13:18:43 person_from_web : When you say the rootfs image, you really speak about the "image file " or you would like having the complete tree as it shuold be in the board? May 22 13:19:38 the last one May 22 13:20:07 person_from_web : When you do bitbake -c populate_sdk May 22 13:20:25 person_from_web : you shuold have a script that will install you the sysroot where you want and so that the SDK no? May 22 13:21:20 hm... May 22 13:22:19 @ http://www.yoctoproject.org/docs/2.3/sdk-manual/sdk-manual.html#sdk-installing-the-sdk May 22 13:24:06 ChrysD: I have the toolchain definition, which is resulting the SDK bundle... May 22 13:25:39 And as far as I understand "-c populate_sdk " should create another SDK image for me... right ? May 22 13:25:53 It shuold create the sysroots May 22 13:25:57 And also the sdk for your computer May 22 13:26:51 @person_from_web http://www.yoctoproject.org/docs/2.3/sdk-manual/sdk-manual.html#sdk-extracting-the-root-filesystem May 22 13:26:58 + one file(a scriptà for setting the environmental values needed in case May 22 13:27:31 PinkSnake: tnx... reading... May 22 13:27:40 Any chance someone would know why stdlib.h is not found? May 22 13:28:47 This is the error i get: https://pastebin.com/Ts9p4qaJ May 22 13:28:52 Oh My God !!! changing my .gitconfig to set gitProxy from ~/bin/git-proxy to /home/smitty/bin/git-proxy solved the issue. I haven't worked with such primitive tools since the 90s May 22 13:35:02 Okay... so yeah, I see the point of the advices I got, and this is actually what I already did and I already have :) May 22 13:35:56 I have a sysroots/crosscompilers etc, I can compile the software for target platfrom and it works perfectly fine May 22 13:36:38 The problem I'm trying to solve is the partial image delivery to the developer through the SDK May 22 13:36:53 person_from_web : what you mean? May 22 13:38:11 rj_: Missing dependency, maybe? Do you have a link to the recipe? May 22 13:38:25 so the developer will glue up "rootfs-image-from-sdk" and "his-own-file-system-image"(probably some ext4 partition) and flash it to the target device May 22 13:41:11 @person_from_web "partial image delivery" what do you mean ? May 22 13:42:22 I'll provide ext4 image, the developer will "mount it", will put some files on it and flash to target device May 22 13:42:51 person_from_web : He could flash directlry the target device May 22 13:43:02 person_from_web : and with scp, he can copy so that he can test May 22 13:43:20 no... there is no such possibility May 22 13:43:32 no connectivity at all May 22 13:43:44 person_from_web : How do you flash? May 22 13:43:54 person_from_web : sdcard slot? May 22 13:43:59 like that May 22 13:55:58 neverpanic: It's a costum recipe, https://pastebin.com/yf8NgkJT May 22 13:56:03 Custom* May 22 14:02:00 rj_: Yeah, looks like a missing dependency. stdio.h is part of libc, but kernel modules don't depend on libc. IIRC there's some libc-initial-something or kernel-libc-headers package that provides these for use in kernel modules, but I don't have the details. May 22 14:03:14 neverpanic: but this is about stdlib.h not stdio.h right..? May 22 14:07:02 Yes, sorry, typo. May 22 14:07:33 neverpanic: Ah okay, well i just added "linux-libc-headers" to the image May 22 14:07:45 neverpanic: so let's hope for the best May 22 14:07:46 To the image, or the recipe? May 22 14:10:14 try to search your /home/user/poky/build/tmp/sysroots/genericx86-64 for that header in standard locations like ./usr/include May 22 14:10:44 Probably you really miss it :) May 22 14:18:39 neverpanic: well, as dependency to the recipe May 22 14:32:12 neverpanic: It didn't work sadly May 22 14:33:44 Did you check whether your sysroot has the file? May 22 14:34:16 neverpanic: yea, it does May 22 14:47:39 Ruminating over the purpose of BB_ENV_EXTRAWHITE. Is this variable somehow informing bitbake which environment variable it is allowed to look at ? May 22 14:56:24 Smitty_: list of env variables that you can use inside bitbake May 22 14:56:53 Smitty_: basically you can extract those values with d.getVar May 22 14:57:04 COnfused about why/how a file named example_0.1.bb somehow automatically references a directory parallel to it named example-0.1 why the difference between underscore and hyphen ? May 22 14:58:10 Smitty_: the underscore separates the package name and the package version May 22 14:58:24 and the hyphen ? May 22 14:58:36 Also does that May 22 14:58:38 ? May 22 15:00:43 What I am getting at is that somehow the build system looks at the name of the file example_0.1.bb, and magically knows that do_compile, SRC_URI (and probably others) are actually referring to files within a directory named "example-0.1" So, why change from an underscore to a hyphen ? May 22 15:00:47 Smitty_: the hypen and part of the PN May 22 15:00:58 so example-0.1 is the package name May 22 15:01:09 example_0.1, just example is the package name May 22 15:01:17 hi, any plans for openssl 1.1.0? May 22 15:05:09 Smitty_: pastebin your recipe May 22 15:05:18 Smitty_: so we can have more context May 22 15:05:36 https://pastebin.com/4CKfDg81 May 22 15:06:38 Smitty_: oh. that is the hello world created with yocto-layer, right? May 22 15:06:56 This is in a file named meta-custom/recipes-example/example/example-0.1/example_0.1.bb EVen the path to the file is consistent, but the bb file name doesn't match May 22 15:07:03 yes May 22 15:08:06 Smitty_: I see what you mean May 22 15:09:11 Is that standard ? to have such an inconsistency for the bb file name May 22 15:09:38 I mean, is that intentional, or works by accident ? May 22 15:10:29 Smitty_: it is intentional and the standard May 22 15:11:52 so you have a recipe name foo_X.Y.bb then you can place your patches or any file inside: foo or foo-X.Y or files May 22 15:12:41 So, the build environment is looking for a file named "package_version.bb" in a directory named "recipes-package", and also expect parallel source in a subdirectory named "package-version" but for some reason the bb file contains an underscore in the naame, and no other element of this package does May 22 15:14:48 Smitty_: recipes have standalone folders so no parallel recipes/sources is expected May 22 15:15:14 Smitty_: you can modify recipes in another layers, but this is not what you mean I believe May 22 15:19:16 hi, when i build with toaster, where are the "Bitbake Variables" stored ? May 22 15:19:48 example_0.1.bb (the pastebin) SRC_URI variable and the do_compile() both reference helloworld.c without explicitly naming the directory example-0.1 That directory is parallel to example_0.1.bb file. So, there must be some weird implicit rule that allows bitbake to know to look there May 22 15:20:25 And it's the strange inconsistency between underscore and hyphen that I find confusing May 22 15:24:14 Smitty_: there are some variables to understand all this May 22 15:24:28 check WORKDIR, S and B definitions May 22 15:25:12 WORKDIR is the parent folder of the recipe inside TMPDIR, S is where the source code is located and B the build folder May 22 15:25:51 Smitty_: you can use bitbake -e hello-world | grep ^ to check its value May 22 15:26:28 Smitty_: and yes, the hyphen/underscore is a bit confusing May 22 15:47:50 how do i set my permissions so that can yocto can run on a vagrant user May 22 15:49:01 how do I set my permissions so that the yocto scripts can run with a vagrant user May 22 15:53:15 black_13: what do you mean? you want to launch a VM and inside run yocto? May 22 15:53:32 i figured it out May 22 15:53:49 i had to dust off the linux/unix grey matter notes May 22 15:58:32 I have a prebaked image from device manufacturer and I'd like to modify one of the packages without figuring out the entire dev chain for baking my own image. I need to modify tcf-agent with some different build flags. It's available in vendor's opkg servers, but I don't know how to reconfigure it from that level. Is that feasible? May 22 16:02:00 you can't use an ipk feed to rebuild a package from source. it's not debian, no source packages are provided May 22 16:03:00 I would try to rebuild from scratch using the git repo, but I'm stuck at the hardware layer. Git repo has i686 and i386 in its machine subdirectory, but my hardware identifies as i586 (intel quark) May 22 16:04:55 thanks kergoth, still trying to get my head around some of these concepts May 22 16:04:58 no idea what you're referring to there, but you can target any architecture May 22 16:07:32 I really should try it, sorry, I just read the makefile first and it tries to query the local uname -m and defines a variable that picks out particular include and .c files based on cpu architecture May 22 16:08:24 just my arch doesn't have a subdir so I assumed it wouldn't work May 22 16:15:28 the recipe no doubt addresses all of that already May 22 16:16:18 which is why oe exists, so its recipes can deal with the crosscompilation madness so you don't have to May 22 16:16:57 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb?h=master May 22 16:19:02 yeah, i have the recipe mod I think I need: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5069#c4 , but I don't know if I have access to the original recipes that this vendor used to construct this image... it's not buried in the image somewhere, is it? May 22 16:19:03 Bug 5069: enhancement, Medium, Future, david.reyna, NEW , Eclipse TCF can support arm cpu debug now,but tcf-agent_git.bb can't do it this time. May 22 16:21:38 ohh, think i might have found it: https://github.com/siemens/meta-iot2000 ... so you think that's easier to figure out the bitbake application than try to rebuild a single app by hand? May 22 16:21:38 no, oe metadata isn't deployed to the target. you'd have to check with the manufacturer May 22 16:22:59 do you already have the toolchain from the manufacturer? even if you *do* have the exact toolchain (and the glibc version will have to match your rootfs), you'd have to adjujst for any crosscompilation issues yourself, and also use the correct tuning arguments to ensure the resulting binaries rae even compatible with your rootfs libraries May 22 16:23:33 and that's assuming it even works without the patches we're applying to the upstream sources May 22 16:24:02 yes, have sdk toolchain and can crosscompile from windows and direct compile on machine May 22 16:24:48 If bitbake is relatively straightforward given a preexisting configuration, I may go that route, it just looks intimidating from the outside May 22 16:26:46 that depends on what your device manufacturer has provided, really May 22 16:27:24 but as i just described, there'll be difficulty doing either direction, so pick your pain :) May 22 16:27:38 well, they claim that repo has all the files necessary to build the example image that I'm running on now May 22 16:30:37 thanks, kergoth, you've saved me from a couple of dead-ends anyway ... :) May 22 16:49:04 I would not say that bitbake is straightforward. It's unnecessarily complicated, in fact, I'd say it's a total mess. It does work, somehow, though. May 22 17:02:51 I wouldn't say it's unnecessarily complicated, given the problem being solved and the focus on flexibility. The file format is admittedly a bit of a mess, a hodgepodge of declarative and imperative content. May 22 17:17:50 I agree to disagree. BitBake's use of inference is incredibly confusing. There are too many inferred behaviors, which are optionally over-ridden explicitly in a seemingly random architecture of conf/layer.conf, target.bbclass, etc, etc. I compare it to equally complicated projects in other huge project build systems like buildroot, or even CMake that do the same thing in a manner which seems far better May 22 17:17:50 designed and is much easier to understand. May 22 17:19:13 buildroot has much different goals, and cmake isn't even in the same ballgame. cmake is analagous to make, whereas bitbake and buildroot are a level above that, more along the lines of the buildsystems of debian, fedora, etc, but with crosscompilation capability May 22 17:19:54 CMake handles cross compilation much easier than either bitbake or buildroot May 22 17:20:15 IMHO May 22 17:20:45 It also supports fetching source May 22 17:20:51 and packaging May 22 17:21:29 Inn short, I find CMake vastly superior, and can't believe anyone actually gets anything accomplished with bitbake. But, then, I guess I am still learning May 22 17:25:24 cmake knows nothing about handling crosscompilation for other project buildsystems. May 22 17:25:31 for its own sources its compiling, sure May 22 17:25:41 nowhere near enough to build a distribution May 22 17:26:05 and buildroot is nowhere near capable enough either, it's weaknesses are largely why oe exists at all May 22 17:26:14 it didn't scale well enough May 22 17:27:58 Sorry, do yo know about CMAKE_TOOLCHAIN_FILE ? May 22 17:29:20 where you trivially set the compiler, linker, archiver, along with optional flags for all those tools, and sysroot location, May 22 17:31:59 whats best way to reconfigure/rebuild u-boot? with meta-toolchain or bitbake -c u-boot May 22 17:33:04 It that ^^ type of question that should make people realise how confusing bitbake is to use. May 22 17:33:41 That shouldn't even be a valid question. There should be one, standard way to do such a standard operation May 22 17:35:54 SomeDumbBumb: good feedback, if you can comeup with some feature requrests against bitbake that will make it better for users it would be cool May 22 17:36:29 SomeDumbBumb: All tools suck in general and some may suck more, May 22 17:36:39 we just want to keep the bar low May 22 17:40:58 how can i rebuild u-boot with meta-toolchain May 22 17:52:18 SomeDumbBumb: unless CMAKE_TOOLCHAIN_FILE can magically fix all the problems with autoconf, you just proved my point. it can handle crosscompilation for *shit its compiling*, not the buildsystems of other projects it has to call into. May 22 18:03:30 kergoth: there is a reason why we dont have a cmake based linux distro May 22 18:35:29 Hey folks, I'm trying to track down why some of my recipes are rebuilding when I change the DISTRO_VERSION variable. I've manually looked at the recipes and their includes & couldn't find a direct usage of DISTRO_VERSION, I've looked at `bitbake -e linux-foo` (I'm trying to keep a custom linux from rebuilding) and not seen any DISTRO_VERSION reference in the tasks. `bitbake-whatchanged linux-foo` doesn't May 22 18:35:31 appear useful, it prints out lots of items. bitbake-diffsigs -t linux-foo do_fetch (I'd noticed it running this task) shows some differences that don't really make sense: it has a change to DISTRO_FEATURES which shouldn't be happening (I'm not changing the DISTRO). It also looks like the output is mixed up with 2 things trying to print at the same time (I'm running morty, so this might be fixed in master). Any May 22 18:35:33 ideas for things to look at that I've missed? May 22 18:50:30 jmesmon: Are you building an SDK? May 22 18:51:05 OK, you're saying CMake can't build a non-CMake project - or can't make it build croos-platform, or what ? May 22 18:55:19 JPEWhacker: no, just building an image. Also, I've overridden SDKPATH for when I do build an sdk :) May 22 18:56:07 Oh, this is using poky as the base (so SDKPATH would normally include SDK_VERSION, which in turn uses DISTRO_VERSION). May 22 18:58:27 The bitbake-diffsigs output seems like it could be hinting at the issue, output almost looks like something isn't using the DISTRO config for do_fetch (at some time) May 22 18:58:41 Or bitbake-diffsigs might just be wrong. May 22 18:59:54 Here's what it says for the curious: https://gist.github.com/322729ec21c1469f62c8a65ca78e8f3a (note that the mixing of output is what I see too) May 22 19:09:29 I don't see any mixing of output May 22 19:09:38 SRC_URI is multi-line May 22 19:09:47 looks exactly how it should afaict May 22 20:02:02 kergoth: so the 'DISTRO_FEATURES{bluez5} = Unset' lines interspersed are expected? I'm pretty sure that that text isn't actually in SRC_URI May 22 20:02:55 I mean, it's contents clearly depends on that info, so it it is useful to see it. But mixing it into the output of SRC_URI seems wrong May 22 20:04:38 with fewer 'it's: SRC_URI's contents clearly depends on the DISTRO_FEATURES noted, so it is useful to see the DISTRO_FEATURES values, but mixing the DISTRO_FEATURES values into the output of SRC_URI seems wrong. May 22 20:05:43 jmesmon: that's how bitbake handles 'contains' type variables for the checksum May 22 20:06:19 it's not part of the value for the variable in the metadata, but it *is* in the string that's checksummed for that variable, and bitbake-diffsigs is comparing those, not the original May 22 20:46:36 got it. May 22 22:06:25 @paulg, @khem, thanks guys, I went with ROOTFS_POSTPROCESS_COMMAND and that worked. My initramfs boots and mmc partitions emerge. Now fixup the init script.. May 22 22:59:57 glad it worked out for him. **** ENDING LOGGING AT Tue May 23 03:00:01 2017