**** BEGIN LOGGING AT Mon Jan 08 03:00:03 2018 Jan 08 07:23:53 how to make a SRC_URI ${PV} dependent Jan 08 07:46:34 hello Jan 08 07:48:33 cornel: hello Jan 08 07:48:56 is there an advantage in using a common sstate-cache for multiple users/builds in the same time? Jan 08 07:56:47 cornel: if you're fetching code, then it speed-up the process for all users (not every user have to fetch code) Jan 08 08:04:29 xtron, is there any risk in having an inconsistent sstate cache when multiple users work with it? Jan 08 08:07:42 cornel: you can take a look at this and around Jan 08 08:07:42 https://lists.yoctoproject.org/pipermail/yocto/2015-June/025208.html Jan 08 08:13:57 xtron, thank you Jan 08 08:27:13 Hello :) Jan 08 08:28:13 could someone explain me how stand build/conf/local.conf and buiild/conf/bblayers.conf to this one that I have in my custom layer? Jan 08 08:32:46 devik: hey can you be more specific plz? Jan 08 08:40:19 Yes, for eg when I call "source oe-init-build-env" in new clean project the build directory is created with his local bblayers and local.conf. Then I need to update it manually to use my custom meta layer. I susspect that if I have those files already in my custom meta layer then dont need to have it in build. Jan 08 08:43:18 devik: i think you will have to create a wrapper of oe-init-build-env that will copy local.conf & bblayer.conf as templates from specific place to build folder Jan 08 08:50:53 nayfe: but if I have them in my custom layer, they are used for anything by yocto or can I store them in any places? Jan 08 08:53:00 devik: local.conf and bblayer.conf are not used in layers, they are only used in build/conf Jan 08 08:53:33 devik: what is your board? Jan 08 08:54:36 nayfe: general I build for x86-64 Jan 08 08:58:56 devik: for instance, in freescale, they have setup-environment script that sources oe-init-build-env and do extra stuff, (https://github.com/Freescale/fsl-community-bsp-base), not sure if there are other options, but it looks ok to me Jan 08 09:12:01 ok wrapping it is not an issue, I just wondering if those files are somehow evaluated if they are inside custom-meta Jan 08 09:18:53 nayfe: I also notice that oe-init-build-env use full paths for layers when generate bblayer.conf, is there some vriable that I can use instead in my configs that will be resolved to proper path? Jan 08 09:20:19 maybe ${TOPDIR} ? Jan 08 09:50:17 devik: example here https://raw.githubusercontent.com/Freescale/fsl-community-bsp-base/master/conf/bblayers.conf Jan 08 10:11:53 not a yocto specific question but maybe somebody knows: is there a way to see all commits accepted in a certain time interval in all layers? Jan 08 10:20:51 New news from stackoverflow: Whenever running bitbake stops all application and locks the system Jan 08 11:02:31 Is there a way to exclude a specific kernel module (*.ko) to be copied? Jan 08 11:02:52 ttllkk: find out why it is installed in the first place :-) Jan 08 11:05:47 It is installed because the defconfig of the kernel lists it as =m Jan 08 11:06:00 Seems like Yocto install all kernel modules by default Jan 08 11:06:58 i can't tell for sure, but i don't think so. usually they are pulled in by the kernel-modules packagegroup or such Jan 08 11:09:19 the first question would be : what package is it part of ? if you are lucky it's a single-module package and you just have to not install it Jan 08 11:10:00 by default it should be that. Jan 08 11:10:24 but the correct thing actually should be to not build it at all, if you don't need it :) Jan 08 11:10:50 LetoThe2nd: if it's enabled by the BSP, that can be tricky to do... Jan 08 11:11:08 or can a kernel .cfg unset an option from a defconfig ? Jan 08 11:11:19 boucman_work: the OP specifically said "defconfig", and that should be easy to fix. Jan 08 11:11:41 ah, right, my bad Jan 08 11:13:17 I don't think there is specific package, it is included by the virtual/kernel package Jan 08 11:13:40 The thing is I don't want to change the defconfig... Not sure if there is something like KERNEL_MODULE_EXCLUDE Jan 08 11:14:51 ttllkk: it's not because it is built by virtual/kernel that it's in the same package... Jan 08 11:15:29 not sure how to check in which package it is, though, I usually go and look in $WORKDIR for packages-split... is there a "non hackish" way of getting that info ? Jan 08 11:17:10 I see... ok, I will check Jan 08 11:31:40 ttllkk: the default kernel packaging puts all modules into separate packages, so if you image pulls in kernel-modules then they all get installed. don't install kernel-modules and just list the ones you want. if you're not using the default kernel packaging and your BSP does something different then its your BSP provider you need to moan at/fix. Jan 08 11:36:20 ttllkk: I know some BSPs call out kernel-modules in MACHINE_EXTRA_RRECOMMENDS which causes all modules to be installed. Which BSP or machine are you using? Jan 08 12:51:20 New news from stackoverflow: How to use qemu for the image build for nanopi-neo-air in yocto Jan 08 13:10:05 What is a good package to play video? Jan 08 13:10:26 without X Jan 08 13:11:28 gstreamer can do that Jan 08 13:11:38 and probably has integration for your hardware accel Jan 08 13:12:04 saying "without x" doesn't say how you want to see the video though Jan 08 13:12:26 wayland? pixels to bare framebuffer? mir? egl? Jan 08 13:18:33 rburton: otoh, your answer (gstreamer) is correct whatever the backend :P Jan 08 13:18:57 yeah pretty much, which is why its a great answer :) Jan 08 13:20:24 :) Jan 08 13:21:27 New news from stackoverflow: Modify cmdline machine file Yocto project Jan 08 13:33:35 rburton, pixels to bare framebuffer of course Jan 08 13:34:45 And so what is the package name to install? Jan 08 13:38:42 many recent platforms do actually not have an easily accessible framebuffer anymore, as its all DRM now Jan 08 13:40:14 I'm only using core-image-minimal... Jan 08 13:40:30 that says nothing about the hardware platform in use. Jan 08 13:40:38 My cpu does not seem to have any gpu Jan 08 13:40:49 imx6ull Jan 08 13:42:24 look into your /dev. if there is something /dev/fbX (with x = 0,1,2...), then there is a classic framebuffer that you can poke directly. Jan 08 13:42:33 if not, then... not. Jan 08 13:50:06 I can see /dev/fb0 Jan 08 13:50:18 then there is your frambuffer. Jan 08 13:50:34 example: cat /dev/urandom > /dev/fb0 :-) Jan 08 13:50:43 I did that already Jan 08 13:50:57 And I get a rainbow noisy screen Jan 08 13:51:11 cool, eh? Jan 08 13:51:16 Ya Jan 08 13:51:34 But now I want to fly higher Jan 08 13:51:53 higher than the rainbow? y'must be kiddin' me Jan 08 13:52:11 Up to the 7 sky Jan 08 13:52:26 learningc: do you know gstreamer a little ? Jan 08 13:53:37 yeah, gstlaunch videosrctest | videosink Jan 08 13:53:52 Only on pc linux Jan 08 13:54:11 But how do I install it using yocto? Jan 08 13:54:21 ok, in that case you just have to install gstreamer on your target, grep your various meta to find the recipe name, then add it to IMAGE_INSTALL Jan 08 13:54:48 I'm not sure what is the recipe name Jan 08 13:57:28 I see gstreamer1.0-meta-base.bb Jan 08 13:57:43 I that the right package name? Jan 08 13:58:26 Or: packagegroup-fsl-gstreamer1.0-commercial.bb Jan 08 14:07:42 figure out what you want to do on your desktop, work out what bits were used, install those Jan 08 14:07:57 ie will you use gst-launch in a shell script? write some C using libgstreamer? python? Jan 08 14:08:17 with a bit of a configuration tweak gst-player might work on bare fb Jan 08 14:18:22 Yes, I will use gst-launch Jan 08 14:18:36 So what's the package name I should install? Jan 08 14:19:18 There are so many package names that I'm confused of what to IMAGE_INSTALL_append Jan 08 14:30:20 learningc: packagegroup-fsl-gstreamer1.0-full with LICENSE_FLAGS_WHITELIST = "commercial" in local.conf will add all gstreamer plugins from base to ugly Jan 08 14:32:07 ok thanks very much nayfe :) Jan 08 14:32:54 learningc: if you need less things, you can select a smaller gst package group Jan 08 14:51:48 New news from stackoverflow: Disable IO-APIC in a Yocto machine file Jan 08 14:53:09 nayfe, no, I need the full package :) Jan 08 14:54:15 nayfe, what the purpose of commercial flag? Jan 08 14:54:30 What if I don't add that? Jan 08 14:54:35 learningc: some gst plugins are closed sources Jan 08 14:55:01 if you dont add the flag, it will not add them Jan 08 14:55:13 normally without error Jan 08 14:58:06 I see. Thanks Jan 08 15:46:03 nayfe, How do I install packagegroup-fsl-gstreamer1.0-full? With IMAGE_INSTALL_append or CORE_IMAGE_EXTRA_INSTALL_append ? Jan 08 15:52:01 New news from stackoverflow: Yocto: howto disable IO-APIC in a machine.conf file? Jan 08 15:56:35 learningc> IMAGE_INSTALL_append should do Jan 08 16:04:46 ok thanks Jan 08 16:52:15 New news from stackoverflow: Yocto image missing fonts (X11) Jan 08 18:03:57 Morning everyone Jan 08 18:04:47 rburton: hey Ross, just got my computer back, whats happened with the python manifest patches, I should get that done correctly once and for all Jan 08 18:04:49 :) Jan 08 18:26:37 ERROR: Unable to start bitbake server Jan 08 18:26:38 * kergoth sighs, yet again Jan 08 18:27:40 Is there an officially supported way to prevent bitbake from caching a single recipe (__BB_DONT_CACHE sounds private)? I'd like to include "git describe" output in os-release but bitbake apparently only evaluates the variables once so os-release never gets rebuilt. I've managed to work around it by setting the variable in local.conf (with immediate expansion) but now _every_ recipe gets reparsed on changes. Jan 08 18:47:00 what's a good light weight www server for yocto? Jan 08 18:48:42 lighttpd is pretty light Jan 08 18:49:28 is bruce ashfield back from vacation? Jan 08 19:32:18 Hi, I want to add a package to the host sysroots of a sdk I am building by do_populate_sdk. I tried adding my package to SDKIMAGE_INSTALL. But, I am not seeing my package in the host manifest file of the resulting sdk Jan 08 19:32:39 I looked at populate_sdk_base.bbclass and I only see Jan 08 19:32:59 SDKIMAGE_INSTALL_COMPLEMENTARY variable getting used. Am i missing something? Jan 08 19:39:23 telnetd responding to port 80 is pretty light. Jan 08 19:39:26 * paulg runs Jan 08 19:47:09 never mind, There only SDKIMAGE_INSTALL_COMPLEMENTARY variable. Jan 08 19:50:48 newbie question - it seems Yocto is very well suited to taking the best-of-breed code from various projects, applying any necessary patches, layering it all together (configurations, etc.) to create a final build, but I'm unclear how that fits in with maintaining an entire project. specifically, what is the typical development cycle for projects maintained by Yocto? (do people dive into the build directories, and attempt bug-fixes there Jan 08 19:51:52 or, is it more intended as a tool for creating well-structured distributions from source code maintained outside of the yocto project itself? Jan 08 19:52:06 bemo: the latter, pretty much Jan 08 19:52:13 LetoThe2nd: thanks! Jan 08 19:53:00 bemo: if you do want to dive in and fix bugs in the source code of your components, devtool makes that workflow much easier Jan 08 19:53:17 devtool -- part of yocto? Jan 08 19:54:10 bemo: part of oe-core, to be precise :) Jan 08 19:55:02 kergoth: specifically, I realized that if patches are applied as part of the Yocto build, and I start modifying code in one of the sync'd build directories that have been patched, I need to un-patch anything first, to avoid accidentally committing those as well. Jan 08 19:55:51 LetoThe2nd: will look for more information on it (in oe-core) -- thanks again. Jan 08 19:56:39 bemo: thats why you don't mix automated building and patching with code development. if you absolutely need to do source level development in an openembedded context, compiling though EXTERNALSRC (as managed by devtool) is th way to go. Jan 08 19:58:30 LetoThe2nd: thanks -- have been looking into possible build systems for our internal code -- and trying to understand Yocto's intended goal and decide if our software engineers can "develop code" with Yocto as the build system, or if it's better used for building our final images. Jan 08 20:01:27 found it: http://www.yoctoproject.org/docs/2.4/sdk-manual/sdk-manual.html#using-devtool-in-your-sdk-workflow Jan 08 20:01:28 :) Jan 08 20:01:38 bemo: hint: "yocto" is not a build system, but just an umbrella name. technically, you're specaking of openembedded, respectively bitbake. and the answer is relatively clea (unless you have super specific needs): develop your application in a distribution- and architecture agnostic way, using a proper infrastructure like autotools, cmake, meson, etc. don't do magic scripts and homebrew Jan 08 20:01:44 make-replacement-solutions. then any distribution ... Jan 08 20:01:46 ... building system (like openembedded is) should be fine to use it. Jan 08 20:03:50 LetoThe2nd: thanks -- guess I'm really thinking about bitbake then Jan 08 20:04:23 LetoThe2nd: the other issue is pulling in third-party applications that already have their own build systems... was trying to decide if "porting" those to use yocto made sense. Jan 08 20:06:53 bemo: you're still mixing up te build system "levels". bitbake is a kind of upper-level build system. it decides which packages to build, and in turn calls the lower-level buld systems per package. so its two choices you have to make. 1) the source-level build system (lower level), like autotools, meson, cmake... and 2) the distribution level build system (higher level), like openembedded, elbe, Jan 08 20:06:59 buildroot, ... Jan 08 20:07:20 and given a proper design, those choces are orthogonal. Jan 08 20:08:46 bemo, I guess companies are maintaining their own specific -- possibily proprietary-- code, too... Jan 08 20:11:04 skz81: Jan 08 20:13:03 LetoThe2nd: I'm also assuming that if there's a mix-and-match of both 1) and 2), it will be more painful to use yocto. Jan 08 20:13:39 LetoThe2nd: (especially in the context of having some of the code being developed internally, and other parts of the code being delivered by third-parties to us) Jan 08 20:14:12 LetoThe2nd: (with whatever build system that particular third-party chose to build their code) Jan 08 20:14:31 bemo: is only painful if your design shifts responsiilities of one buld system to the other. Jan 08 20:14:46 LetoThe2nd: which will likely happen, unfortunately. Jan 08 20:14:46 divide et impera. (or something like that) Jan 08 20:15:18 anyway, thanks for the help -- I think I understand. :) Jan 08 20:15:27 bemo : will your projects will be compiled for different targets ? Is the purpose to produce root filesystem, able to boot and run the applience on a specific hardware ? Jan 08 20:16:22 Mixing open source project AND possibly specific application code ? Jan 08 20:16:44 skz81: yes, essentially (to all of the above) Jan 08 20:17:03 skz81: and proprietary code. Jan 08 20:17:27 skz81: (potentially provided by third-parties) Jan 08 20:18:58 Ok, then it makes perfectly sense to use a "build system" and all complexity.... Nevertheless, and back to your question : "...and decide if our software engineers can "develop code" with Yocto as the build system..." Jan 08 20:19:09 skz81: think self-driving vacuum cleaners, and we're working on the lights/music. ;-) (entirely contrived example) Jan 08 20:20:46 Software developpers, if working on a very specific feature will work on a spacific component of the system, just as some other open source component you'll pull from the web (or preferably, local mirror caches :p ) Jan 08 20:21:27 skz81: understood Jan 08 20:21:40 Then, as LetoThe2nd explained very well, they work UNDER the build system, at makefile / autotools / cmake level Jan 08 20:21:54 good :) Jan 08 20:22:18 skz81: appreciate the help! Jan 08 20:24:20 But "integrator(s)" (a specific kind of software engineer) will need to know well the build system used to produce target images... It's the obvious, but may be worth to note. Jan 08 20:24:47 glad you appreciate :) Jan 08 23:11:19 is it possible to use in-tree defconfigs when building a custom kernel from kernel.org in yocto so I don't have to supply a defconfig line to the SRC_URI in my layer? Jan 08 23:20:14 I'm working on a yocto recipe that needs different do_configure() actions for ${PN}-staticdev than it does for ${PN} Jan 08 23:20:24 going crazy trying to figure out how to make that happen Jan 08 23:20:29 anybody got some advice? Jan 08 23:21:02 *('bitbake recipe', not 'yocto recipe'), that is Jan 08 23:36:30 nrclark you might just keep two build dirs and one source dir and run configure in each one Jan 08 23:37:37 mkdir build build-static Jan 08 23:37:51 ( cd build; ../configure ) Jan 08 23:38:03 ( cd build-static; ../configure --static ) Jan 08 23:47:33 hmm, that could work maybe but it's a little messy Jan 08 23:48:05 is there any way inside of a recipe (env variable, python snippet, anything) to tell whether or not the target is -staticdev? Jan 08 23:58:17 nrclark: no as you build once for all the packages Jan 08 23:58:27 (typically) Jan 08 23:58:38 if you want to build twice for one recipe then you just need to build twice Jan 08 23:58:53 using out-of-tree build dirs is a good way, if you're using autotools Jan 08 23:59:14 presumably not, as that can build both at once Jan 09 00:10:15 nope, no autotools :( Jan 09 00:10:35 I'm working up a recipe for lapack 3.8, which is cmake-based Jan 09 00:11:14 I found a 3.7 recipe floating around, but it only builds the shared version Jan 09 00:19:12 nrclark: just in case: if you're using DISTRO=poky then we tell cmake to not build static libraries Jan 09 00:20:31 ah no, not globally. ignore me. Jan 09 00:53:57 New news from stackoverflow: Cannot login Yocto qemux86-64 Jan 09 01:54:09 New news from stackoverflow: How to recover Intel Edison board Jan 09 02:24:16 New news from stackoverflow: libQt5core.so.5 : cannot find a library file || Log files with same content after build [closed] **** ENDING LOGGING AT Tue Jan 09 03:00:01 2018