**** BEGIN LOGGING AT Fri May 10 03:01:14 2019 May 10 06:27:15 good morning May 10 06:58:22 Hi, I try to get into the workflow of building customized linux with openembedded/yocto. I've got a short question: When a recipe (mono) requires another package (giflib), do I add soleley this specific package (giflib), or the whole layer (meta-oe) which provides giflib? May 10 06:59:27 I'm not sure whats the best practise here. My target is to provide a linux which has a small footprint. I don't want any auxillary packages on that image which I do not need. May 10 09:53:05 thomasD13: you have to add the layer to the build, via bblayes.conf, and add the specifc package that you want to the image May 10 09:53:40 thomasD13: only what is required by the image through its IMAGE_INSTALL get actually built+installed May 10 10:00:03 LetoThe2nd: Perfect, thank you very much May 10 10:03:00 thomasD13: i will actually be covering pretty much precisely that on the yocto live coding session on tuesday, by the way :) May 10 10:04:31 Is that a kind of webinar, which I can follow? May 10 10:05:10 thomasD13: just head to https://www.twitch.tv/yocto_project May 10 10:05:28 tuesday, 17:00 europe/berlin time May 10 10:06:06 Ah very cool, so I can view the session later as well. Thanks for highlighting, I will tune in ;) May 10 10:06:12 yw May 10 14:47:44 Since thud, xz uses update-alternatives. For my distro, I use dpkg with xz compression, and dpkg also provides update-alternatives for my distro. This creates a dependency loop that I'd like to avoid. May 10 14:49:00 I wonder why update-alternatives.bbclass adds update-alternatives to DEPENDS, as I'd rather classify it as a runtime dependency. May 10 17:02:08 I have a recipe for an app (not a module) that depends on virtual/kernel, but the recipe sysroot's /usr/include/linux does not include some of the headers I was expecting to see (fpga/fpga-mgr.h, for one). Does anyone have a suggestion for why these files may be getting skipped? May 10 17:14:06 tgoodwin:if you have an app which need raw kernel headers that app is broken May 10 17:16:04 obi:isn't update-alternatives needed during offline rootfs processing ? if not then we can make it rdep May 10 17:24:56 khem: not sure I can agree with you. An example would be something using iio. May 10 17:28:18 maybe you can depend on kernelsrc.bbclass and then add needed paths to -I May 10 17:36:23 khem: I tried something similar (I thought) using kernel-devsrc. It's output image path looks like it would be useful (usr/src/kernel), but adding it to the app's depends didn't give me recipe-sysroot/usr/src/kernel. May 10 17:36:58 sysroots are path filtered. the files that end up there aren't the same as the ones that end up in the binary packages May 10 17:54:29 khem: The -native version, yes. But that would be a runtime dependency of dpkg-native, I guess. May 10 18:14:11 kergoth: would a different PACKAGE_ARCH explain why depending on kernel-devsrc does not unpack that package into the sysroot for the build? May 10 18:25:38 Or are you saying that by virtue of the package in question having them in /usr/src they're not going to be unpacked into the sysroot? May 10 18:32:43 tgoodwin: isn't that what kernel-headers is for? May 10 18:34:07 tgoodwin: the latter. i doubt /usr/src is in the included paths for the sysroot. May 10 18:35:07 kergoth: got it, thanks. I recall running into something like that with expecting to see files in /etc/ that some other package installed. May 10 18:37:00 that said, there's no real need to use the sysroot for that. depend on the appropriate task in virtual/kernel and you can poke directly into its source tree in work-shared. see module.bbclass May 10 18:37:21 rburton: I'm on rocko; that's not a package for me. May 10 18:41:32 kergoth: that's where I started, using the work-shared source, but it's a can of worms since this header ultimately pulls in asm/current.h, which varies based on architecture. So my CXXFLAGS, etc., would have to shift around based on that mapping, and so forth. May 10 18:44:08 as I started unpacking it I figured I would come here to ask if there was a better way. May 10 18:44:29 I also cannot find a single example of someone else writing a utility that talks to this particular device driver so I'm starting to agree with khem. May 10 18:46:54 it's generally not a great idea to include real kernel headers from userspace at all, as they haven't been sanitized for userland use. if you have to, and kernel-headers don't include what you need, i'd make a separate recipe that just ships the missing headers, probably.. May 10 18:47:02 then if needed it could fix them up as well May 10 18:49:19 hello. im trying to build a tree with a lot of AUTOREVs (unfortunately). I've downloaded all the sources before, but right now i dont have access to those servers. Bitbake keeps stopping the build because it tries to connect. So i tried to temporarily override the AUTOREV with buildhistory info, e.g buildhistory-collect-srcrevs -a > autorev.conf and then i include autorev.conf from my local.conf. However, bitbake May 10 18:49:21 still stops during parsing recipes step and i can't build despite having all the sources and the srcrevs i want to build. is the only way around this to edit every individual recipe and replace autorev with values from the autorev.conf ? May 10 18:53:03 i also tried running bitbake -r autorev.conf so that it would parse autorev.conf early, but no luck May 10 18:53:13 you need to set the bitbake srcrev cache policy May 10 18:53:20 by default even if it's set already, it'll contact upstream May 10 18:53:28 if you tell it to rely on the cached values, it should avoid that issue May 10 18:54:30 BB_SRCREV_POLICY = "cache" May 10 18:54:35 set that in local.conf May 10 18:54:42 BlastuR: see above May 10 18:55:08 kergoth: cool. do i not need the autorev.conf when policy is cache? May 10 18:55:35 it still has to know what the revisions are. if it's an existing build directory that has contacted upstream in the past, then the cache in the cache/ directory will be enough May 10 18:55:41 if not, then it'd need the autorevs.conf to populate that May 10 18:56:55 thank's for the suggestion kergoth :) May 10 18:57:19 np, good luck with it May 10 19:24:04 I just noticed that the kernel-devsrc package has a noexec for do_populate_sysroot, which I'm betting is the reason why bitbake doesn't attempt to build it despite it being in my recipe's depends (and why adding /usr/src to the SYSROOT_DIRS doesn't help). Is there a way to unset noexec? I tried a bbappend with "do_populate_sysroot[noexec] = "0"" but it's still not being built through my dependency. May 10 19:27:28 i think you might have to set it to the empty string, or use anonymous python to .delVarFlag() May 10 19:49:13 Interesting. I've tried both but still the depends isn't causing the kernel-devsrc to be built. May 10 19:49:15 Thank you for the suggestions. May 10 19:49:20 (as always) **** ENDING LOGGING AT Sat May 11 02:59:57 2019