**** BEGIN LOGGING AT Mon Mar 23 02:59:58 2020 Mar 23 07:52:17 Hi. Someone can help me to understand the structure of `install -m` command? I know that it should get *2* argument after the mode argument (`install -m `) - Why 2? Mar 23 07:52:29 arguments* Mar 23 07:58:56 nacknick: source and destination Mar 23 08:00:24 erbo In my case I don't need source and destination, just changing the mode of a specific file, should I use `chmod` instead? Mar 23 08:01:24 nacknick: yes, that's what chmod is for Mar 23 08:02:50 thanks Mar 23 08:15:17 New news from stackoverflow: lightest version of packages for reducing rootfs size in yocto Mar 23 08:19:47 good morning Mar 23 08:20:26 howdy mckoan Mar 23 08:20:41 LetoThe2nd: hi, how's going? Mar 23 08:20:56 mckoan: mostly fine i would say. how about there? Mar 23 08:21:22 LetoThe2nd: still hard but OK so far, thanks Mar 23 08:21:37 mckoan: glad to hear Mar 23 08:46:31 Hi, Mar 23 08:47:30 I'm have a hard time moving a GStreamer recipe from-the-days it GStreamer was using Autotools to today, where they are using Meson. Mar 23 08:47:51 In the past, we started from the gst-template git repo. And the BB recipe was rather simple. Mar 23 08:48:19 Now, I have restarted from gst-template, but my bb does not do anythiing. Mar 23 08:48:52 The 'do_compile' in the run.do_compile is empty. Mar 23 08:49:09 Bon, any good pointers how to write a bb for meson? Mar 23 08:49:59 vermaete: hum, inherit meson? Mar 23 08:50:28 yep, did that. Mar 23 08:50:34 inherit meson pkgconfig Mar 23 08:50:38 at the first line Mar 23 08:51:19 then, unless you overwrite it specifically below the inherit, this should provide the do_compile/install etc functions.. Mar 23 08:53:00 do_compile() { Mar 23 08:53:25 I'm just wonder how to debug this? bitbake -e? Mar 23 08:57:04 removing the build directory and restarting did help a bit, a little bit :-( Mar 23 08:57:06 Tnx Mar 23 08:57:07 vermaete: out of curiosity, have you had a look at how gstreamer recipe got updated to use meson? It was migrated recently, look into master :) Maybe that'll help? Mar 23 08:58:59 vermaete: bitbake-layers show-appends myrecipe to check that do_compile isn't overriden by some other bbappend? Otherwise, if you have your do_compile before the inherit meson (or some other inherit) you might have some weird behavior. Same for multiple inherit in the same recipe, sometimes the order matters Mar 23 09:01:33 @qschulz: I'm at the master (2 weeks old) . I'll check your bitbake stuff. Tnx Mar 23 09:59:46 mckoan: saw the LI post, nice you're getting it started! Mar 23 10:05:51 LetoThe2nd: times are changind and we have to adapt, thanks Mar 23 10:06:17 *changing Mar 23 10:06:48 mckoan: ye. Mar 23 10:06:50 +p Mar 23 10:15:42 New news from stackoverflow: lightest version of packages for reducing rootfs size in yocto [closed] Mar 23 11:17:33 mckoan: https://twitter.com/yoctoproject/status/1242047558417108993 here you go Mar 23 11:18:48 Is there a way to print package recipe's path by its name? (with bitbake etc.) Mar 23 11:19:31 oe-pkdata-util probably in some way. Mar 23 11:27:26 or find -name "myrecipe_*.bb"? Mar 23 11:28:08 qschulz I thought that there is a more elegant way Mar 23 11:29:12 If I run `bitbake ` it runs the recipe. How does it know where is it? I guess not using "find" Mar 23 11:29:19 nacknick: you can use fd instead of finde for higher performance (-> more elegance! :P) Mar 23 11:30:41 LetoThe2nd: BUT don't forget to put -I in an alias for fd :) Mar 23 11:30:50 qschulz: :) Mar 23 11:33:35 I think that too much hours at home don't make better with you Mar 23 11:34:05 nacknick: i'm not gonna dig into the sources, but i *guess* that bitbake first parses everything into an indexed format, and then just looks up "myrecipe" in that and executes what it finds there. no pathes involved. Mar 23 11:35:16 OK Mar 23 11:42:51 nacknick: bitbake-layers can tell you what is being parserd Mar 23 11:43:54 rburton: "tell"? Mar 23 11:44:04 * LetoThe2nd imagines connecting bitbake to alexa. Mar 23 11:45:22 $ bitbake-layers show-recipes systemd --filenames Mar 23 11:45:22 .../home/ross/Yocto/poky/meta/recipes-core/systemd/systemd_244.3.bb Mar 23 11:45:36 well formatting went wrong, but thats what you want to do Mar 23 11:45:59 nacknick: ^ Mar 23 11:47:41 exactly, thank you rburton Mar 23 11:48:46 "alexa, bitbake a core-image-minimal for qemuarm" Mar 23 11:49:24 maybe in the future Mar 23 11:50:20 "alexa, bitbake a core-image-minimal for qemuarm in the future." Mar 23 11:51:37 Another question please, some packages create their binary file under `/usr/bin` and some under `/usr/sbin`. Is there a way to get the binary path by env var or something else? Mar 23 11:52:31 I want to make a general solution for many recipes and want to get the binary file path in advance Mar 23 11:53:56 nacknick: you mean like a magic invocation "bb-tell-me-where-binary-ends-up myrecipe" ? Mar 23 11:54:29 letothe2nd: yes Mar 23 11:54:48 Maybe not so magical as you say Mar 23 11:55:07 nacknick: if that, you can (again) look at the output of oe-pkgdata-util, i think it can output where stuff ends up. Mar 23 11:55:36 but again, there are packages which do not put anything into one of those, into both, multiple things into either or both, or even other places... Mar 23 11:55:37 nacknick: but aren't /usr/bin and /usr/sbin in $PATH? Mar 23 11:55:52 so geussing which "binary" you mean actually would be definitively "magic" Mar 23 11:55:53 My point being, why do you need to know this? Mar 23 11:56:20 qschulz because I'm replacing the final binary with mine Mar 23 11:56:39 mine "patched" one Mar 23 11:57:03 * LetoThe2nd sighs and resorts to useful things again. Mar 23 11:57:14 nacknick: bbappend Mar 23 11:57:37 yes. this is how I do it Mar 23 11:57:51 but I want to know what to write into the "append" Mar 23 11:58:06 how do you create your binary? Mar 23 11:58:39 I'm taking the original one, modify it and return the modifed Mar 23 11:58:44 modified Mar 23 12:00:03 how do you modify it Mar 23 12:00:12 what are you doing Mar 23 12:00:27 with a server I built. it sends the original binary to the server, I'm doing my thing and returning a patched binary file Mar 23 12:00:28 what is your issue (the original one, which warranted this change) Mar 23 12:01:27 nacknick: have a class that does the signing in a piece of py or whatever, and then that can at runtime find the binaries and know their path Mar 23 12:02:41 do_sign_binaries() { for file in os.walk($bindir) + os.walk($sbindir) { ... }) Mar 23 15:24:34 hello gents, does anyone know how to "finish" a devtool modify session without having actually modified any sources? Mar 23 15:26:14 devtool reset? Mar 23 15:27:28 you might ask why one would want that: for instance when I want to provide some ready to apply patch or just want to add/modify some supplementary files to the recipe. I just like the comfort of devtool sorting the correct recipe path for me and creating the boilerplate directories and the bbappend file... Mar 23 15:27:57 Hi all, I'm trying to build a Beaglebone image that will run just docker containers. For this I'm using the toaster webinterface. I've build several successful custom images starting from core-image-base. Now I want to try starting from container-base. However, as soon as I try to build it I always get the error that nothing provides /bin/sh. Mar 23 15:29:12 LetoThe2nd, let me try that out Mar 23 15:29:28 keysers: probably because container-base is meant to be *inside* the container, where you don't want /bin/sh. Mar 23 15:29:48 derp, that makes sense yes Mar 23 15:29:52 thank you Mar 23 15:31:09 hi guys. I couldn't figure out from the docs HOW to target specific recipes from a layer? Basically, I want to build a RPi image that uses meta-virtualization, BUT, I only need the Docker packages/recipes from that layer... Mar 23 15:31:34 is this possible? Or am I obliged to always run all the recipes in a layer? Mar 23 15:31:48 cjdc2: that question doesn't make sense. Mar 23 15:32:13 cjdc2: if your image pulls in the docker packages, then those recipes will be built. no more. Mar 23 15:33:21 sure, but I don't want to build all the others (https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/) Mar 23 15:33:37 cjdc2: like i said, they won't be built. Mar 23 15:39:10 yah. they'll be parsed, but not built. Mar 23 15:40:44 * LetoThe2nd hands zeddii a "i just want to" Mar 23 15:40:59 :D Mar 23 15:43:08 LetoThe2nd, that didnt work as expected... I also tried devtool update-recipe -a instead of reset but nope Mar 23 15:43:34 maybe I should rephrase what I actually wanted Mar 23 15:44:56 nameclash: are you, in a nutshell, just trying to apply the patch to the upstream sources? Mar 23 15:45:08 I'm just looking for a convenient way to create an append recipe (and its enclosing directory) in the right recipes folder in my downstream layer Mar 23 15:45:15 yes Mar 23 15:46:00 here for instance I want to add an existing patch to libgpg-error Mar 23 15:46:00 nameclash: hm, i don't thing that devtool has mechanisms for working on appends. i might be wrong of course, but i don't know of any. Mar 23 15:46:27 libgpg-error is normally located in recipes-support Mar 23 15:49:01 and when I do devtool modify, then add a newline to some random source file, commit that and do devtool finish libgpg-error MY_LAYER_DIR it creates the directory MY_LAYER_DIR/recipes-support/libgpg-error, creates a patch from my commit and puts it inside that dir along with an minimalistic bbappend file that just pulls in that patch Mar 23 15:49:21 Again using core-image-base running: docker run hello-world result in "docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?." Is this a side-effect of the warning "You have included the meta-virtualization layer, but 'virtualization' has not been enabled in your DISTRO_FEATURES. Some bbappend Mar 23 15:49:21 files may not take effect. See the meta-virtualization README for details on enabling virtualization support."? I tried adding it as a bitbake variable in toaster "DISTRO_FEATURES" value "virtualization" but that results in an error: "ERROR: ParseError at Mar 23 15:49:21 /home/olivier/poky/_toaster_clones/_git___git.yoctoproject.org_meta-virtualization_warrior/conf/layer.conf:41: Could not include required file meta-virt-default-versions.inc" Mar 23 15:49:56 what I'm looking for is a tool that does nearly the exact same thing but without having me to create a dummy commit that yields a dummy patch Mar 23 15:50:32 keysers: without actually verifiying, it is certainly possible. Mar 23 15:51:24 nameclash: like i said, i don't know if its there. you might want to implement it and send a patch to devtool :) Mar 23 15:52:28 keysers: maybe try and get it working without toaster first? Mar 23 15:52:39 LetoThe2nd, hey maybe I'll even do that -- that would be my first opensource contribution ever :) Mar 23 15:52:39 Is my method to enable 'virtualization' correct? appending the variable "DISTRO_FEATURES" with value "virtualization" correct? Mar 23 15:53:09 LetoThe2nd using cli bitbake? Mar 23 15:53:23 keysers: you have to do this in your distro config file. Mar 23 15:53:27 nameclash: so basically you want a patch for libgpg-error but with no commit log (since no commit, no commit log)? Mar 23 15:54:37 yah, since I'm not seeing any issues with warrior meta-virt, and I hope if that parse error was happening to everyone, someone would have shouted on the mailing list. Mar 23 15:55:15 zeddii: i guess its just being sticked in there in inappropriate places. Mar 23 15:55:48 I mean, I never rule out stupid bugs. But I definitely built and tested all that on warrior. Mar 23 15:55:56 keysers: heh, if you use _append then it has to be " virtualization". mark the space. += inserts one, _append doesnt Mar 23 15:56:12 I always have a paper bag handy, in case I do something really dumb in one of my commits. Mar 23 15:56:33 zeddii: beer? wine? vodka? Mar 23 15:56:56 pro tip: don't just cut eye holes, do a nose and mouth one as well, so you can drink the old contents of the bag Mar 23 15:56:59 haha. you beat me too it. Mar 23 15:57:02 s/too/to/ Mar 23 15:57:43 * LetoThe2nd should encourage CUI. just for entertainment purposes. Mar 23 15:57:59 qschulz, I want to apply this patch here to libgpg-error: https://raw.githubusercontent.com/nobk/packages/762b318703b61fc995291e2f85e136a38fa9732c/libs/libgpg-error/patches/020-gawk5-support.patch Mar 23 15:58:29 it's nothing about the patch actually Mar 23 15:58:59 it could also be just providing a custom fstab file for the base-files package Mar 23 15:59:11 or providing an ld.so.conf to glibc Mar 23 16:00:32 it's just about the comfort of having a tool create the appropriate directory/file tree in your layer so that I have a bbappend recipe for that package in my layer Mar 23 16:02:57 maybe I misunderstood the docs, but I expected it to be like: add layer to bblayers.conf -> run bitbake targetMachine -> bitbake will run all the .bb files in all recipes, in that layer Mar 23 16:04:09 cjdc2: no. it will parse all, but only build those needed. Mar 23 16:04:34 LetoThe2nd typing the space there did nothing( Value " virtualization"). Making the value "+=virtualization" started the build. Did I undestand you correctly? Mar 23 16:04:36 but then what's the criteria to defined those which are "needed" Mar 23 16:04:55 cjdc2: may i suggest you invest some time in our wonderful live coding sessions? https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Mar 23 16:05:09 cjdc2: please note the excellent and only slightly drunk host! Mar 23 16:05:14 but as said, I'll put a sticky note on my monitor to create a patch for devtool Mar 23 16:05:52 keysers: i don't know what *exactly* you are doing. i just pointed out one of the main differences between += nad _append. Mar 23 16:06:24 cjdc2: and the criteria is a dependency tree with its root being what you specify as the build target :) Mar 23 16:07:07 nameclash: it's actually "risky" to automate it, because unfortunately the OVERRIDES mechanism plays a role in which file is taken. Even if it comes from a bbappend, the file might not have priority because of that variable. Mar 23 16:08:24 hmm Mar 23 16:09:23 LetoThe2nd: thanks for the playlist. I have a look Mar 23 16:09:46 it thought I'd just hitch hike on the normal devtool modify + git commit + devtool finish behavior, but allowing for a scenario without a git commit Mar 23 16:10:22 so that I'd end up with an empty package directory and a bbappend in the right place, that's all Mar 23 16:11:14 in the end, that would be what I'd do if I wanted to supply my additional/modified files manually Mar 23 16:12:16 nameclash: I don't follow everything you're saynig but I'm a very scarce use of devtool Mar 23 16:12:32 so, if you feel like people could benefit from it, please do so and contribute :) Mar 23 16:13:07 will do! :) Mar 23 16:13:43 keysers: what did you change and in which file? Mar 23 16:17:58 on the Toaster page "EXTRA CONFIGURATION/BitBake Variables" I used the Add Variable feature to add the Variable "DISTRO_FEATURES" with value "+=virtualization" Mar 23 16:21:59 Sorry, cli guy here, I don't use toaster :/ Mar 23 16:23:20 Thx anyway qschulz Mar 23 16:24:54 The build finished but the warning remained. So to answer my own question, NO it is not the correct way to enable it. Mar 23 18:08:58 nameclash: is it possible that "devtool update-recipe" might help? Mar 23 18:58:05 RP: FILERPROVIDES how/when are they calculated ? I am missing it for a library package so was looking into why Mar 23 19:40:12 khem: do_package time... they come from running rpmdeps on each file Mar 23 19:40:39 then they get saved into pkgdata and are read back from there Mar 23 20:23:37 bluelightning: the problem is recipe name is foo-src and https://git.openembedded.org/openembedded-core/tree/meta/classes/package.bbclass#n1607 kicks in and ignores it Mar 23 20:29:12 khem: ah yes we have a few problematic name-based checks around the place like that :( Mar 23 21:06:56 i have a package which can be built with "--enable-debug" to have many self-tests enabled at runtime. what is the best way to have an image (say production.bb) where the packges is installed without debug and another one (say debug-image.bb) where the same package is installed but with --enable-debug? Mar 23 21:24:23 @derRichard: You mean --enable-debug is something like a compiler flag? Mar 23 21:24:43 RobertBerger: --enable-debug is configure flag Mar 23 21:25:17 so the produced code with be different :) Mar 23 21:25:19 @derRichard: So basically you want to configure your app differently for debug and release. Mar 23 21:25:40 well, differently for different images Mar 23 21:26:14 #derRichard: Let's say you have a debug and a release image. Mar 23 21:26:35 ok Mar 23 21:26:39 @derRichard: You might introduce your own feature. Mar 23 21:27:20 you mean a feature for IMAGE_FEATURES? Mar 23 21:27:25 @derRichard: something like DISTRO_FEATURE=my-special-debug-feature Mar 23 21:27:52 and then check in your recipe for this DISTRO_FEATURE and build accordingly Mar 23 21:28:06 or an IMAGE_FEATURE, if you prefer Mar 23 21:29:51 @derRichard: look into PACKAGECONFIG Mar 23 21:30:36 @derRichard: inherit pkgconfig in the recipe, PACKAGECONFIG ??= "" # disabled by default: Mar 23 21:30:43 hmm, is this really the right way to do it? Mar 23 21:31:05 PACKAGECONFIG cannot be set in an image recipe, right? Mar 23 21:31:08 image feature only affects how the image is constructed, not how the other recipe is built. the problem is you're not going to be able to build one recipe two different ways and then install the different package sinto the images Mar 23 21:31:21 kergoth: exactly! Mar 23 21:31:26 you have to remember how we build images. ther ecipe is built and emits binary packages, then those binary packages get installed into the image Mar 23 21:31:37 there's no tight association between image and package other than the name of the package Mar 23 21:32:20 even if you were to create two variants of the recipe to build it two different ways with two different package names, and then pick those in the individual images, bitbake would complain, as it built two packages that provide the same files, it'll produce a conflict in the pkgdata Mar 23 21:32:34 yeah. but how to solve my issue? Mar 23 21:32:42 i bet i'm not the first person with that use-case? Mar 23 21:32:44 the ideal would be if the debug build just added files rather than changing how the binaries are built, then you could just split it off into a separate package that's additionally installed in the debug image Mar 23 21:33:10 kergoth: --enable-debug in this case is not about just adding debugsymbols Mar 23 21:33:36 with a DISTRO_FEATURE you could build the package differently Mar 23 21:33:38 i think the only real option is what i suggested, two recipe variants with different names, then use the variable to tell bitbake to ignore the conflict. i don't recall the name of it offhand, though, or just make it a build configuration option / distro feature that changes how the recipe is built for all images, and do two different builds with differing configurations Mar 23 21:33:51 the latter is simpler, but is a different workflow than you were thinking Mar 23 21:33:59 but is also probably the most common approach to that sort of problem Mar 23 21:34:35 it is also not only --enable-debug. same use-case is also present for the linux kernel. in the debug image i want lockdep enabled Mar 23 21:34:56 kergoth: you mean playing with PROVIDES? Mar 23 21:34:56 for kernel it's different Mar 23 21:35:34 i think you're going to need to use different builds with differing local.conf configurations, rather than trying to shoehorn it into the image level. you're crossing the boundaries between our generally orthogonal distro/machine/image boundaries Mar 23 21:36:08 kergoth: makes sense Mar 23 21:37:53 you could do the multiple variants of the recipe thing, but you'd have to keep doing it, and if they're used at build time you'll run into sysroot conflicts too, ex which recipe gets built to satisfy the need for the headers/libs/etc, if both get built bitbake will get unhappy again Mar 23 21:38:37 in theory it complains more than it needs to now that we have per-recipe sysroots, the conflict won't be a problem unless both get installed in a single dependency chain or a single image Mar 23 21:38:47 but it's still probably more trouble than its worth to take that approach Mar 23 21:39:12 instead you might just want a debug variant of your DISTRO which adjusts recipe packageconfigs as appropriate Mar 23 21:39:27 then the second build uses that other distro. could even use multiconfig to kick off both in the same build directory Mar 23 21:39:41 you *could* do it all in local.conf, but a distro will be easier to maintain Mar 23 21:40:35 well, i have already tooling to generate local.conf, that's not a big deal :) Mar 23 22:50:18 derRichard: your question does come up fairly often, i don't think there's a consensus (or "correct" answer yet) Mar 23 22:50:28 maybe this is still applicable? https://www.yoctoproject.org/pipermail/yocto/2018-April/040866.html Mar 23 22:51:32 tlwoerner: thx. i found this thread already but it is not 100% what i need. i'm currently playing with virtual providers. looks good so gar Mar 23 23:04:00 Hi guys, anyone got trouble with bluetooth on rpi 4? Can not enable it, hciattach says bcm43xx_init Failed to reset chip, invalid HCI event Mar 23 23:04:47 I am using meta-raspberrypi Mar 23 23:28:44 so uh, how are licenses on npm packages supposed to work Mar 23 23:29:49 i have an odd situation where some thing we have is in JS, but when using the NPM fetcher, the license file of one of its dependencies seems to bounce around between different directories and fails the build Mar 23 23:35:04 hmm, i have a package foo which depends on virtual/bar. after changing the prefered provider of virtual/bar i would expect that foo is rebuild, but this is not the case. do i miss something? Mar 23 23:35:51 maybe i miss some sleep. ;-\ Mar 23 23:49:04 RP: whats your opinion around the bitbake revert I sent Mar 23 23:49:22 khem: I was hoping for something from Saur but I'll merge Mar 23 23:51:00 yeah, ok Mar 24 00:00:52 RP: how do you run toolchain tests in AB and how often do we run Mar 24 00:04:30 RP: http://sprunge.us/zdiZpP I always get those 5 tests failures on qemux86_64 ptestresult.valgrind.gdbserver_tests/nlcontrolc could be a gdbserver patch that we have added Mar 24 00:04:55 khem: we run them in any a-full build - you mean toolchain tests or ptest? Mar 24 00:05:44 RP: ptests I think which runs glibc tests and compiler regressions Mar 24 00:06:13 khem: https://autobuilder.yocto.io/pub/non-release/20200323-9/testresults/testresult-report.txt Mar 24 00:06:22 khem: no valgrind ptest failures Mar 24 00:07:04 khem: the passed tests will be in https://autobuilder.yocto.io/pub/non-release/20200323-9/testresults/qemux86-64-ptest/ Mar 24 00:12:19 RP: for toolchain tests will adding tools-sdk add them automatically to image Mar 24 00:21:30 I dont see bash in there, so perhaps thats not part of core-image-sato-sdk ? Mar 24 01:18:34 New news from stackoverflow: modpost has source but didn't compile **** ENDING LOGGING AT Tue Mar 24 02:59:57 2020