**** BEGIN LOGGING AT Tue Feb 28 03:00:01 2017 Feb 28 12:47:34 hey Feb 28 12:48:05 is it true that yocto is binary compatible with raspberry pi? that i can compile a binary on rpi and move it to a yocto system and it will run? Feb 28 12:54:27 fqtw: that's not really a valid question Feb 28 12:54:34 raspberry pi is a hardware board Feb 28 12:54:41 fqtw: that doesn't make a lot of sense, yocto is not an OS or even a distro. Even if you pick an OS built with yocto the answer would be "no, there's no guarantee it would work" Feb 28 12:54:43 rburton: raspbian Feb 28 12:54:47 do you mean is yocto compatible with raspian? Feb 28 12:54:50 yes Feb 28 12:54:52 in that case, dunno. :) Feb 28 12:55:03 both are arm Feb 28 12:55:07 glibc versions won't match Feb 28 12:55:19 which may lead to problems depending on what one has a newer glibc Feb 28 12:55:23 etc etc Feb 28 12:56:03 you might have a chance when doing something statically linked. in every other case, i'd say "no" Feb 28 12:56:07 (it's not at all easy to build a binary on fedora and run it on debian, either) Feb 28 12:57:27 exactly, and the more complicated the binary is, the smaller the chances of it working flawlessly. Feb 28 12:59:51 rburton: ok, then i change my question to: will Rust work on yocto? https://github.com/rust-lang-nursery/rustup.rs/#other-installation-methods Feb 28 13:00:29 (it works on my raspberry pi) Feb 28 13:00:30 fqtw: https://layers.openembedded.org/layerindex/branch/master/layer/meta-rust/ Feb 28 13:00:49 (yes, rust will work. install it by hand if you want, or use the layer) Feb 28 13:01:19 rburton: why/when should i use the layer Feb 28 13:01:38 and what is a 'layer' in this context? Feb 28 13:03:06 fqtw: if you are building a yocto image and want rust on it, you should use the layer Feb 28 13:04:36 jku: ok, so if i want to build applications for existing embedded devices running a yocto image that the OEM installed (which i dont have), i should make a similar yocto image with the rust layer and use that to compile my application, then copy it over? Feb 28 13:12:03 that might work (and you wouldn't need to make and use an image, you'd just use the build system to build your app) but since you don't know the exact details of what the OEM is building, you are bound to have some of the same kind of issues as using any other OS... Feb 28 13:15:30 jku: by build system do you mean cross compiling? Feb 28 13:19:03 fqtw: I mean yocto tools as whole but yes Feb 28 13:19:32 jku: but dont i have to create an image with the rust layer if i want to use rust? Feb 28 13:19:43 and then run that image on qemu or similar? Feb 28 13:24:56 fqtw: you can do that if you want but the point of a cross-compile build system like yocto is that you should not have to Feb 28 13:26:03 jku: ok, but will it work with the rust layer? Feb 28 13:29:16 yocto + meta-rust will allow you to build rust apps, yes. Can the binaries be made to work on the mystery image your OEM made? ¯\_(ツ)_/¯ Feb 28 13:30:11 jku: i mean, on what system should i run meta-rust if not on a yocto image on qemu or similar? Feb 28 13:37:49 fqtw: the yocto development manual talks about yocto requirements (as well as adding new layers) Feb 28 13:38:57 jku: is it possible to find out the exact config that the OEM used to build the yocto image? Feb 28 13:43:29 fqtw: you'd need to ask the OEM Feb 28 14:14:10 Running into an issue with populate_sdk_ext since upgrading to morty Feb 28 14:15:19 When running it I get the error: "ERROR: uninative-tarball-1.0-r0 do_populate_sdk: kernel-devsrc not found in the feeds () in /home/me/.../tmp/deploy/rpm" Feb 28 14:19:26 Trying to figure out why uninative-tarball is looking for kernel-devsrc... Feb 28 14:59:16 Ah, looks like it was because a dev added this to one of our conf files: "TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"" Feb 28 15:07:54 Heya Feb 28 15:08:07 Anyone knows if it is possible to edit packae versions? Feb 28 15:08:13 package* Feb 28 15:10:39 does anyone recommend a good resource for configuring wifi on wandboard quad? Feb 28 15:13:56 maka: what do you mean by "edit package versions" Feb 28 15:15:42 maka: Is this what you're looking for? http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#incrementing-a-package-revision-number Feb 28 15:17:18 themikenicholson: while it is a good point, i'm relatively sure that this is not what maka is looking for. Feb 28 15:23:04 LetoThe2nd: Literal interpretation of the question :) Feb 28 15:33:39 LetoThe2nd: well, a package im trying to install has a dependency, which is installed. But the package version is Feb 28 15:35:22 maka: the package version is "none"? Feb 28 15:35:33 yes Feb 28 15:35:53 maka: where is the package version "none"? Feb 28 15:36:06 apt-cache policy Feb 28 15:36:23 so it's installed, yet it has no version Feb 28 15:36:37 apt? Feb 28 15:37:43 *sigh* runtime package management it seems to be. Feb 28 15:38:39 in that case, themikenicholson might actually have been right Feb 28 15:38:45 themikenicholson: i totally apologize! Feb 28 15:39:43 maka: explanation: find out what gets injected into the package, and it probably is ${PV} Feb 28 15:40:45 for the sake of reproductibility though, i totally recommend to *not* *use* runtime package management Feb 28 15:41:45 Alright then, ill see if that works ^^ Feb 28 15:44:01 jku: does yocto cross compilation only work from linux or also from windows? Feb 28 15:46:01 If I want a package - say kernel-devsrc to appear in the SDK but not in my target image/sdcard is there a way to do that besides creating seperate my-image and my-image-sdk recipes? Feb 28 15:46:31 fqtw: i can be done under windows with a lot of magic (read up on CROPS), but in general - stick to linux and save yourself the pain Feb 28 15:46:37 ok Feb 28 15:48:17 LetoThe2nd: where's the best place to start? Feb 28 15:48:36 for learning how to cross compile for yocto Feb 28 15:49:00 fqtw: besides obviously the quick start document? https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Feb 28 15:49:16 thx Feb 28 15:51:28 LetoThe2nd: can i only cross compile applications into images? Feb 28 15:51:54 i just want to cross compile an application for an existing / running image Feb 28 15:52:47 fqtw: you would at least need a toolchain fitting that image. Feb 28 15:53:06 ok Feb 28 16:10:10 RP: who is working on enhancing the sstate samesigs tests? Feb 28 16:10:50 I've looked at the current sstatestests.py and sstate_allarch_samesigs in particular and have some suggestions for improvements. Feb 28 16:13:09 The version of the test that I added to Ostro differs a bit: a) it compares several real MACHINEs (because we had the problem between Edison and intel-core2-32) and b) when there is an undesirable difference, it automatically dumps the diff with bitbake-diffsigs. Feb 28 16:15:02 pohly: you wrote the code to traceback to the root cause sig difference? Feb 28 16:15:21 pohly: I don't think anyone has a direct assignment for that now other than perhaps me being aware it needs work Feb 28 16:15:32 pohly: printdiff is *supposed* to handle this Feb 28 16:22:43 RP: if the tests fail, they fail in self.assertEqual(files1, files2) Feb 28 16:23:00 And the files are cleaned up after a failure, so one doesn't have an easy way of debugging the failure either. Feb 28 16:23:28 We had exactly the same thing in Ostro, that's why I added more verbose output. Feb 28 16:24:08 It's not exactly tracing the root cause, just running bitbake-diffsigs on tasks which should have had the same hash. Feb 28 16:26:28 RP: you mentioned something about reusing these tests for Yocto compliance testing. Who is working on that? Feb 28 16:26:49 Same answer, i.e. you know it needs to be done, but no-one assigned at the moment? Feb 28 16:28:41 pohly: oh, Anibal has been doing that Feb 28 16:28:52 pohly: alimon Feb 28 16:29:24 pohly: if the sigs don't match for a large number of tasks, that would be quite some output to look through but probably better than none at all at the moment I guess Feb 28 16:32:34 RP: one can always truncate the output. Feb 28 16:33:30 alimon: are you planning to submit enhancements for sstatetests.py, or did you copy the code to somewhere else? Feb 28 16:57:54 pohly: alimon has a patch on the list for the compatible tests Feb 28 17:00:14 "yocto-compat-layer.py: Add script to YP Compatible Layer validation" - got it. Feb 28 17:07:49 pohly: i don't reused code from sstate.py, for signature checking i called bitbake -S none and got the information from the inc file Feb 28 17:10:41 alimon: okay, so if I enhance the selftest my changes won't conflict with yours. Feb 28 17:11:29 Now I vaguely remember that you already got the suggestion to add bitbake-diffsig output, right? Feb 28 17:11:44 pohly: yes RP told me about that option Feb 28 17:17:51 pohly: bitbake -S printdiff specifically Feb 28 17:18:03 pohly: sadly there are bugs in that :( Feb 28 17:21:02 No! Feb 28 18:34:59 rburton: what is the box config which is failing this build Feb 28 18:35:18 khem: debian mostly stable Feb 28 18:35:33 rburton: is it on AB ? Feb 28 18:36:04 since I have ubuntu 16.04 which should be similar to debian Feb 28 18:36:12 it does not show this issue Feb 28 18:36:43 no, its my machine Feb 28 18:36:54 rburton: then it does not matter :) Feb 28 18:37:27 have you customized it ? Feb 28 18:39:04 no nver heard of it Feb 28 18:39:12 oops wrong window Feb 28 18:40:09 rburton: I would need a way to reproduce the problem Feb 28 18:40:22 is it due to debian turning on PIE Feb 28 18:40:25 may be Feb 28 18:40:28 dont know Feb 28 18:45:34 rburton: does your box has go installtions Feb 28 19:18:09 khem: FYI kristian is on vacation atm Feb 28 19:57:53 khem: nope Feb 28 20:00:06 Is there a way to retrieve a package version while generating an image? (iow: get the version number of a package being included in the image). I'd like to use that version number in a piece of the image generation. Perhaps some way to use Manifest in meta/lib/oe/manifest.py is the right choice? Feb 28 20:37:02 Hello, I've built a custom image for Raspberry Pi and Feb 28 20:38:02 Hello, I've built a custom image for Raspberry Pi with a psplash splash screen and I want to change the splash screen without rebuilding the image, is this possible? Feb 28 20:50:59 rburton: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131951.html and http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131952.html Feb 28 20:51:10 are still peinding Feb 28 20:51:41 Yahia: I think there is .psplash diretory in /opt Feb 28 20:52:36 rburton: can you try a build with out sstate-cache Feb 28 20:52:43 rburton: and see if that works Feb 28 21:01:14 khem: thank you very much for your reply, unfortunately I had all my temp files deleted and I'll have to build the image all over again. Feb 28 21:17:37 rburton: so I did cleansstate go-cross-x86_64 and then deleted tmp and rebuilt go-cross-x86_64 Feb 28 21:17:43 it still built fine here Feb 28 21:41:51 any easy way to force package rebuild w/o using sstate mirror? Feb 28 21:42:44 denix: running into the issue where cleansstate just removes the local file and it redownloads from the mirror? Feb 28 21:42:57 kergoth: yep Feb 28 21:43:22 1. bitbake —no-setscene, or 2. bitbake -C fetch to taint early and force them to rebuild from scratch, though that requires a clean first, unlike cleansstate Feb 28 21:43:27 that's how i usually deal with it Feb 28 21:43:57 kergoth: ok, I'll try. thanks! Feb 28 21:44:00 np Feb 28 21:45:13 denix: and no, don't need any help in particular, thanks though (replying from the other day), just working on updating our beaglebone support Feb 28 21:46:00 kergoth: sure, let me know if you need anything Feb 28 21:46:12 will do, thanks Feb 28 21:46:33 btw, should bitbake handle single Ctrl-C gracefully? Feb 28 21:47:23 I had to cancel the build, pressed Ctrl-C and waited for it to finish remaining tasks, but it appears sstate ended up picking up incomplete packages for some reason. now I need to re-build those Feb 28 21:47:54 huh, that definitely shouldn't happen Feb 28 21:49:45 I'm guessing "make install" got interrupted and some files were not installed. now sstate ends up serving incomplete packages. just re-built from scratch one of those and all files and packages now present Feb 28 21:51:35 I'd expect sstate+stamps to prevent that... Feb 28 21:53:45 have to remember that bitbake knows how to re-run tasks, but not how to clean out anything remnant that was left behind byt he previous run, unless the task does that itself, or hte underlying upstream buildsystem Feb 28 21:53:54 should fix the recipe to address cases like that, where appropriate Feb 28 21:55:47 kergoth: ok, I see. wondering why only bunch of qt5 packages failed this way... :) Feb 28 21:55:58 that is interesting. should open a bug at the very least Feb 28 21:57:15 so, bitbake doesn't interrupt already running tasks, but won't execute new ones, once it receives Ctrl-C, right? Feb 28 21:57:29 right Feb 28 21:57:33 correct.. hit ctrl-c a second time to kill 'em all Feb 28 21:57:49 jmesmon: you could perhaps look into pkgdata for that information Feb 28 21:59:30 fray: yeah, I know that. that's not the issue Feb 28 22:01:48 I hit Ctrl-C once and waited for everything to finish, but I ended up missing bunch of qt*-qmlplugins and qt*-examples packages and those have gotten into sstate mirror and now being served as proper ones :( Feb 28 22:03:38 that shouldn't be possible, since bitbake let the running tasks complete.. very odd Feb 28 22:20:10 khem: empty tmp, cleaned sstate, still fails Feb 28 22:21:06 rburton: damn ok Feb 28 22:21:29 rburton: so If I were to have debian8 vm I will be able to reproduce it ? Feb 28 22:21:49 it does not fail on all the different build boxes I have Feb 28 22:23:45 rburton: can you share x86_64-linux/go-cross-x86_64/1.7.4-r0/temp/log.do_compile Feb 28 22:25:37 khem: it's literally just Feb 28 22:25:37 ##### Building Go bootstrap tool. Feb 28 22:25:38 cmd/dist Feb 28 22:25:38 # _/data/poky-master/tmp/work/x86_64-linux/go-cross-x86_64/1.7.4-r0/go/src/cmd/dist Feb 28 22:25:38 /data/poky-master/tmp/work/x86_64-linux/go-cross-x86_64/1.7.4-r0/recipe-sysroot-native/usr/lib/go/pkg/tool/linux_amd64/6l: readsym out of sync Feb 28 22:29:45 hmm it should build a lot before that Feb 28 22:29:52 do you have bash ? Feb 28 22:31:45 why is it looking into go/src/cmd/dist thats not right Feb 28 22:33:01 rburton: here is my build log http://sprunge.us/eIVJ Feb 28 22:34:19 Possibly stupid question about LLVM, forgive me if this is covered somewhere: I'm attempting to create a recipe that uses LLVM. During the CMake step it complains that WANT_LLVM_RELEASE is not set. When I export it, it still cannot find llvm-config. When I look inside the sysroot, indeed, llvm-config is *not* installed (except for the wrapper script that looks for the real one). What do I need to do to make an actual llvm-config bina Feb 28 22:38:03 martinkelly: are you using meta-clang ? Feb 28 22:38:07 seems not Feb 28 22:38:32 khem: i've tried it both ways, no dice Feb 28 22:39:01 martinkelly: I do see llvm-config though in sysroot Feb 28 22:39:13 with meta-clang i'm seeing an unversioned llvm-config getting installed into /usr/bin for i586-poky-linux but not for qemux86 (the one i'm building for) Feb 28 22:39:24 with oe-core llvm-common, i'm seeing neither Feb 28 22:40:30 khem: do i just build llvm-common, or do i also need to build clang? Feb 28 22:40:53 martinkelly: you should add llvm-common to DEPENDS Feb 28 22:42:58 donekhem: already done. after building llvm-common, this is what i see in the sysroots: http://pastebin.com/WsrYqjqz Feb 28 22:45:26 martinkelly: generally clang-native provides llvm-config Feb 28 22:45:38 if you use meta-clang Feb 28 22:45:49 ok Feb 28 22:46:05 i tried a DEPENDS on clang using meta-clang, which added an unversioned llvm-config binary Feb 28 22:46:10 should i try clang-native instead? Feb 28 22:46:12 you need to build clang-native which should build llvm Feb 28 22:46:14 as well Feb 28 22:48:46 khem: after building clang-native, i see llvm-config and all the rest of the tools in the x86_64-linux sysroot, but llvm-config is unversioned, so it's still not found by the wrapper script Feb 28 22:48:59 hmm Feb 28 22:49:28 it's also in the x86_64-linux sysroot instead of the qemux86 one, and the wrapper is looking in the qemux86 one (specifically in tmp/sysroots/qemux86/usr/bin/crossscripts/llvm-config3.9) Feb 28 22:50:10 i have only this: tmp/sysroots/x86_64-linux/usr/bin/llvm-config Feb 28 22:50:43 martinkelly: maybe you need to access is using ${STAGING_BINDIR_CROSS}/llvm-config Feb 28 22:51:13 i could point cmake to that explicitly via -DCMAKE_LLVM_CONFIG (or whatever it is called). i thought that was breaking the rules though? Feb 28 22:51:23 no Feb 28 22:51:36 ok Feb 28 22:51:46 what is the purpose of the wrapper? Feb 28 22:52:09 its sort of cross tool calling native tools underneath Feb 28 22:56:05 ok thx Feb 28 22:56:12 well, that helps it avoid the versioning issue Feb 28 22:56:35 however, it's still now looking in the wrong sysroot (the qemux86 one), but llvm-config is installed into the x86_64-linux native sysroot Feb 28 22:56:57 because of these lines in the wrapper script: Feb 28 22:56:57 if [ $WANT_LLVM_RELEASE ]; then Feb 28 22:56:57 exec `dirname $0`/${TARGET_PREFIX}llvm-config$WANT_LLVM_RELEASE ${@} Feb 28 22:57:27 is DEPENDS=virtual/kernel enough to get kernel build-artifacts populated with version.h? or do I need to depend on populate_sysroot task as well? Feb 28 23:05:53 denix: DEPENDS should be enough Feb 28 23:06:36 khem: looks like I need virtual/kernel:do_shared_workdir too? Feb 28 23:07:27 khem: one of my packages failed to find work-shared//kernel-build-artifacts/include/generated/uapi/linux/version.h Feb 28 23:08:03 khem: and there's no work-shared, while the package DEPENDS on virtual/kernel Feb 28 23:09:14 hmmm yeah if its coming sstate then seems you need it Feb 28 23:10:23 khem: seems like there's two problems: seems like wrapper script looks inside the *current* sysroot instead of the one corresponding to the native arch, which is why it's not finding the right llvm-config. is that just a bug, or am i missing something? Feb 28 23:12:25 denix: do_configure[depends] += "virtual/kernel:do_compile_kernelmodules" is what I see what module.bbclass does Feb 28 23:12:49 martinkelly: its not Feb 28 23:12:54 ported to RSS Feb 28 23:14:14 khem: second, after manually specifying the x86_64-linux version of llvm-config via the cmake option, the llvm-config seems to be confused. it's setting LLVM_BINDIR=tmp/sysroots/x86_64-linux/lib/llvm but the binaries are actually in tmp/sysroots/x86_64-linux/usr/lib Feb 28 23:15:07 khem: I don't need modules. I'll try do_shared_workdir first... Feb 28 23:15:08 martinkelly: this will be a good pull request if you fix it Feb 28 23:15:15 denix: yeah Feb 28 23:15:34 khem: sure, happy to do so. any idea about the second issue? Feb 28 23:15:55 i will dig through if you're not sure Feb 28 23:15:57 its probably needs to be patched Feb 28 23:15:59 as well Feb 28 23:16:02 ok Feb 28 23:16:18 you need to look either into llvm-common or clang provided pne Feb 28 23:16:20 one Feb 28 23:16:24 ok Feb 28 23:16:27 i guess i'm surprised to be the only one hitting this. if llvm-config isn't working right, shouldn't everyone using meta-clang be broken? Feb 28 23:16:37 no Feb 28 23:16:55 only if you poke for it Feb 28 23:17:26 lol, "poke" ? Feb 28 23:17:59 how would the cmake llvm-config probing ever work in this configuration? does it work by coincidence for those building native? is it just broken for me because i'm in a qemu sysroot? Feb 28 23:18:22 it could be broken in general Feb 28 23:19:04 ok. do not many people use clang in yocto? i was kind of surprised to see the version be only 3.3 in oe-core Feb 28 23:19:26 yeah core version is only there for llvmpipe support in mesa Feb 28 23:22:59 we should have a compiler/toolchain named "crack". Feb 28 23:23:16 then we'd have crackpipe support. ;-) Feb 28 23:23:32 lol Feb 28 23:23:57 ok. thanks for your help khem! if you're the one i'm thinking of, i was at your talk last week at ELC :). Feb 28 23:27:49 kergoth: tried --no-setscene, but it also triggers rebuilding all the dependencies, though they are already built... Feb 28 23:28:29 huh, thats strange, havent seen that. maybe a recent change? check with rp? Feb 28 23:31:20 hmm, can't seem to be able force-rebuild a single package at all... "bitbake blah" once to get all the dependencies populated, then bitbake -c cleansstate and disable sstate-mirror, but now it rebuilds all the dependencies, which I don't want... Feb 28 23:32:28 well, maybe not all , but only some - it did eventually failed where I expected it to fail. sorry for the noise Feb 28 23:32:58 try -C fetch instead? Feb 28 23:38:43 kergoth: will be trying next Feb 28 23:39:41 so, shouldn't virtual/kernel:do_shared_workdir be part of sstate? Feb 28 23:40:09 khem: do you think it's important to support multiple llvm versions co-installed? i see two ways to patch the wrapper script... 1) remove the logic regarding LLVM_WANT_RELEASE and just use unversioned llvm-config. 2) properly verison all the installed artifacts like, say, debian does (this requires some work and pain to get right, so i don't want to do it unless it's worth the effort). Feb 28 23:49:36 denix: no, it shouldn't since extracting it from source takes the same length of time Feb 28 23:51:47 RP: thanks. looks like our devs look for include/generated/uapi/linux/version.h which is only available in shared workdir... **** ENDING LOGGING AT Wed Mar 01 03:00:02 2017