**** BEGIN LOGGING AT Mon Dec 21 02:59:56 2020 Dec 21 07:42:23 good morning Dec 21 07:45:01 'morning Dec 21 07:56:50 yo dudX Dec 21 08:04:35 morning Dec 21 08:19:38 suuuuuuuuuuuuppp...! Dec 21 09:18:45 whats the easiest way to add a rootfs image from multiconfig a into multiconfig b? obviously i need a recipe that packages it up, but whats the simplest, most canonicalform? Dec 21 09:37:12 I'm trying to build an image but I get this error: Could not invoke dnf. No match for argument: mesa. After some research it seems that the issue is related to mesa not installing anything Dec 21 09:37:50 therefore it should have ALLOW_EMPTY_${PN}. however, I'm wondering why it doesn't have this by default Dec 21 09:40:05 i would rather wonder why you're trying to install it if you don't actually want anything from it. Dec 21 09:41:22 so far I could find out seems like mesa is used as opengl alternative Dec 21 09:41:52 so, could it be that only the "-dev" packages are in use? Dec 21 09:43:16 opengl provider, not alternative. Dec 21 09:43:32 it could be, i don't know your build. Dec 21 09:43:36 rcrudo: it seems to be expected to be empty since 2012: http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-graphics/mesa?id=882bf3bc5f038d5e072df1bf3ecddd66e025e673 Dec 21 09:43:54 (mesa-dri has been renamed into mesa if you follow the git history) Dec 21 09:45:14 qschulz: so, should it have ALLOW_EMPTY_${PN} somewhere in the recipe? Dec 21 09:46:04 rcrudo: it does not for some reason, but maybe you're probably not supposed to install it at all and just install the actual packages you need? Dec 21 09:46:37 I think it makes little sense to add all mesa packages since they are hardware specific and one package probably handles only one kind of hardware Dec 21 09:46:45 (one to one relationship) Dec 21 09:49:31 qschulz: I see. That might be case then. I am working on project that someone else created. That might be it was added without being required Dec 21 10:02:04 qschulz: do you happen to know of a simple build-in-build example? Dec 21 10:02:25 qschulz: the manual states how to define MC dependencies, but not how to consume them. Dec 21 10:04:44 LetoThe2nd: I would do a mcdepends on a task, then read from mc b deploydir Dec 21 10:05:12 hmmm. Dec 21 10:05:24 kay Dec 21 10:07:40 don't know what's the recommended way Dec 21 10:07:56 maybe have a look at freertos+linux Yocto talk at ELCE 2019? Dec 21 10:11:52 ah yes, good pointer. Dec 21 10:28:20 good morning everyone Dec 21 10:29:11 what is the recommended way to get gdb-cross-arm built into the sdk? Dec 21 10:30:43 I can build it using bitbake gdb-cross-arm, however adding gdb-cross to TOOLCHAIN_HOST_TASK it says nothing rprovides... Dec 21 10:33:56 you want nativesdk-gdb* for the nativesdk Dec 21 10:35:28 thx, I'll give it a try Dec 21 10:39:29 hmm can't find anything like that Dec 21 10:40:11 added nativesdk-gdb to TOOLCHAIN_HOST_TASK and it can't find no buildable providers Dec 21 10:40:38 also I cannot find anything like nativesdk-gdb on the oe layer index... Dec 21 10:43:34 mbulut: isn't gdb cross already in the SDK when you set EXTRA_IMAGE_FEATURES += "tools-debug" ? Dec 21 10:44:53 I wasn't aware that EXTRA_IMAGE_FEATURES affects the sdk in any way... Dec 21 10:45:57 I just have a minimal sdk recipe where I require meta-toolchain.bb and add a bunch of other recipes to TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK Dec 21 10:47:00 I'm not running populate_sdk on the image recipe Dec 21 10:47:10 you should be :) Dec 21 10:47:28 mbulut: IMAGE_INSTALL_append = " gdbserver" should give you he same result Dec 21 10:47:31 recommended way is to use the populate_sdk Dec 21 10:48:05 mbulut: you have two options: meta-toolchain or the populate_sdk way Dec 21 10:49:53 https://pastebin.com/jr5HPZuu Dec 21 10:50:25 this is what I use to define the SDK and I run bitbake -c populate_sdk against it Dec 21 10:51:13 so it's the former of what mckoan suggested, now how do I get the cross gdb into that? Dec 21 10:51:42 mbulut: populate_sdk should be used to create an SDK related to an image not itself Dec 21 10:53:05 so both of you and rburton say I should run populate_sdk on the image recipe rather than a standalone recipe for the SDK? Dec 21 10:53:17 yes Dec 21 10:53:27 then you know that your SDK contains everything you need for your target Dec 21 10:53:34 otherwise its on you to ensure they match Dec 21 10:54:01 hmmm - but that builds literally almost everything that's going into the image Dec 21 10:54:32 like idk it yields me a webserver in the sdk which feels kinda odd, you know... Dec 21 10:55:06 mbulut: because that's the expected behavior of an SDK Dec 21 10:55:09 do it yourself, if you want, the underlying code is mostly the same Dec 21 10:55:26 just the recommended way is to build a SDK of an image, instead of hand-curating your own. Dec 21 10:55:44 I understand Dec 21 10:57:02 that recipe I posted was working fine for me and produced a streamlined SDK with only stuff that I would actually expect in an SDK and not just an entire image rootfs bundled as an SDK installer Dec 21 10:58:50 until this morning, when I needed the cross gdb -- I'd really prefer sticking to my recipe rather than the image recipe (not at least because it builds "only" round-about 4K packages as opposed to nearly 9K packages with the image recipe) Dec 21 11:00:10 mbulut: you could create a reduces image for SDK purpose Dec 21 11:01:18 mbulut: well adding the cross gdb is trivial Dec 21 11:02:02 rburton: how? Dec 21 11:02:09 (to my recipe) Dec 21 11:02:48 adding a line IMAGE_INSTALL += "gdb-cross" to it? Dec 21 11:03:42 no, that don't make any sense.. Dec 21 11:06:08 Adding gdb-cross-canadian-arm to TOOLCHAIN_HOST_TASK at least seems to build -- will need to find out if it yields me the desired binaries in the SDK Dec 21 11:08:36 as i said, _HOST_ tasks will all be nativesdk-* Dec 21 11:09:30 hmm I see, then I'll need to find out what nativesdk-* actually includes gdb-cross, correct? Dec 21 11:15:01 I added this line to my sdk recipe: Dec 21 11:15:05 require ${TOPDIR}/../layers/poky/meta/recipes-core/meta/meta-extsdk-toolchain.bb Dec 21 11:15:27 that seems to do the trick Dec 21 11:47:38 hi Dec 21 12:02:11 how can I remove an rpm package from yocto? Dec 21 12:02:19 i mean on the target itself Dec 21 12:03:53 for example I want to remove the program "bc" which the yocto yester likes a lot :) Dec 21 12:13:35 why: the jester says: if you don't want something, do not install it. Dec 21 12:14:20 i mean, whats the reason behind doing this: 1) add stuff 2) compile stuff 3) package stuff 4) remove stuff Dec 21 12:14:29 instead of just 0) do nothing. Dec 21 12:15:09 LetoThe2nd The reason being that at a certain time a package is not needed anymore, since it is possible to add a package afterwards I was wondering if it is possible to remove a package as well Dec 21 12:16:15 So the answer is not possible then? Dec 21 12:16:31 what do you mean by "certain time" and "afterwards? are we talking about varous build times during development, or various lifetime moments during runtime of the device? Dec 21 12:16:39 lifetime moments Dec 21 12:17:11 so you basically need a package when the device is powered on the first time, and then not anymore, or something like that? Dec 21 12:17:57 Suppose I need "bc" now, after 1 month I want to free up space :) and I really don't need that package anymore, is it possible to remove it on the target Dec 21 12:18:05 ? Dec 21 12:18:42 if you have runtime package management, then it should be perfectly doable. but depending on your use case other strategies might be favorable. Dec 21 12:18:49 qschulz: cue chant #3, please. Dec 21 12:19:50 so if I have runtime package management, which command can I use to remove "bc" for example? Dec 21 12:22:22 if you are using rpm, then according to https://linux.die.net/man/8/rpm it should be rpm -e .... Dec 21 12:25:07 rpm -e bc gives me Dec 21 12:25:12 error: Failed dependencies: bc = 1.07.1-r0 is needed by (installed) bc-dev-1.07.1-r0.cortexa7t2hf_neon_vfpv4 Dec 21 12:25:18 then Dec 21 12:25:19 rpm -e bc-dev-1.07.1-r0.cortexa7t2hf_neon_vfpv4 Dec 21 12:25:31 does nothing it seems since bc is still available on the target Dec 21 12:27:39 okay, so you essentially wnet through everything already yourself, and instead of just asking "hwy i want to do x, but it doesn't work, i get error y" you had me discuss stuff plus even look up the man page for you, right? Dec 21 12:27:59 you know what? i'm out. screw you. Dec 21 12:36:12 I didn't expect such a reaction from the kind yocto jester :( Dec 21 12:36:33 LetoThe2nd: "It depends TM" Dec 21 12:36:35 you came with a solution, I tried your solution Dec 21 12:37:04 then it gave the error, so I want to do x, where x = rpm -e ..., but it doesn't work, i get error y Dec 21 12:37:28 then you tell me "screw you", doesn't seem logic to me but ok if that makes you happy Dec 21 12:38:38 why: the point is that you just literally wasted 15 minutes of my time to just find out that you are stuck on an erroro message, and not in the process of it. and i tend to be very unkind if i realize that people are wasting my time just because they *think* i shall explain everything over again, just for the fun of it. Dec 21 12:38:38 why: you could have spared LetoThe2nd 15min of his time by just saying "i want to remove an rpm package from the target, i did rpm -e bc, error (give error), rpm -e bc-dev, error (give error)" Dec 21 12:38:56 qschulz: i couldn't have worded it any better. Dec 21 12:39:45 qschulz LOL, you guys don't seem to get it but its ok I'm not angry :) After the jester said use "rpm -e ..." I imeddiately tried it out... Dec 21 12:39:56 *sigh* Dec 21 12:40:00 then i happily don't get it. Dec 21 12:40:02 lunchtime. Dec 21 12:40:20 jester's reaction @13:22:22 , my reaction at @13:25:07 Dec 21 12:40:23 (but i still think the approach os wrong anyways) Dec 21 12:40:49 LetoThe2nd which approach and why? Dec 21 12:41:00 ... Dec 21 12:41:13 ok. to prove that i am a *MOSTLY* nice guy. Dec 21 12:41:55 never mind I'll try to figure it out, thanks anyway (except for the "screw you" part...) :') Dec 21 12:42:04 (y) Dec 21 12:42:14 i am pretty sure that the whole idea of "installing" something first and then "removing it later" is fundamentally flawed. you are trying to do something, and you think thats a way to do it. Dec 21 12:42:20 so you ask about the way. Dec 21 12:42:28 (because you're stuck) Dec 21 12:43:01 what i am saying is that you should rather rething the whole approach. Dec 21 12:43:03 well in any linux distribution when there is a package management available you can easily install something for example sudo apt install Dec 21 12:43:16 why: but in the end, usually you just flash updates of your system, which don't have the package in it anymore. I'm not sure many people use package management on the target? Dec 21 12:43:17 and sudo apt remove so there must be a reasoning behind it Dec 21 12:43:43 why: don't think of embedded systems as normal computers Dec 21 12:43:56 qschulz yes, but just wanted to know if it is possible :) Dec 21 12:44:15 @qsh Dec 21 12:44:25 qschulz true Dec 21 12:44:27 i'm not saying that there is no bug in runtime package management as we have it. its entirely possible. but it doesn't maater much, because tis not meant for it anyways. Dec 21 12:45:11 we have other use cases, and those require other approaches. so trying to apply your desktop ubuntu mind set will just cause pain for everybody. Dec 21 12:46:26 so, chances are almost 100% that you are actually trying to do something specific and entirely unrelated. and my advice is to rethink this and find an approach that suits the problem domain, not an appraoch that suits "sudo apt" - just because you happen to know that. Dec 21 12:46:40 well I gave the ubuntu example just for understanding purposes only Dec 21 12:47:34 the whole idea is to create a custom os, this means adding (and removing in my opinion), but I think it is best to close this discussion and you can enjoy your lunch, thanks anyway (y) Dec 21 12:48:32 why: "adding" probably means you need to handle package repos or whatever the name actually is Dec 21 12:48:57 you cannot use Ubuntu's and you need to maintain one feed/repo per distro and probably per machine Dec 21 12:49:17 it should theoretically be possible. if it doesn't work, you might have hit a) a bug in the rpm setup we have b) a bug in the preinstallation handling we have c) any combination or variation thereof. Dec 21 12:49:57 try again with ipk, narrow the behaviour down. does it happen only on "included" packages, or also on those installed at runtime? Dec 21 12:49:59 etc, pp. Dec 21 12:51:38 I don't want to waste more of my time now that I know the above, appreciate it guys(y) Dec 21 12:51:43 (y) Dec 21 13:53:32 such crazyness. anybody treid/heard of an emscripten-native recipe? Dec 21 14:04:43 RP: question - maybe i'm just on the wrong track - but: when in a multiconfig environment, doesn't bitbake hold all configs in memory? so, would it be possible to have something like ${mc:other_config:ASDFASDF} to access those? adhering to the usual rules of visibility, of course. Dec 21 14:47:21 Somehow `bitbake -c cleanall my-recipe; bitbake -c do_fetch my-recipe` doesn't clone the source repo into the tmp dir. In did add `RM_WORK_EXCLUDE += "my-package"` to local.conf. Dec 21 14:47:55 `bitbake -c do_patch` does. But it patches as well. I would like to have the unpatched source. Dec 21 14:48:59 do_unpack Dec 21 14:49:07 manuel__: -c do_unpack? Dec 21 14:52:20 Hmm will give it a try Dec 21 14:53:49 manuel__: ${WORKDIR}/temp/log.task_order should help you identify in which order tasks were run Dec 21 14:54:14 or, you can run bitbake my-recipe -g and read the .dot files with a text editor (don't try to make a graph out of it) Dec 21 14:54:31 LetoThe2nd: bitbake doesn't hold recipe configuration in memory, only the "base" configuration before recipes are parsed Dec 21 14:54:53 it only had a snapshot of some variable values from after it parsed recipes Dec 21 14:55:28 would it be possible to peek from one config into another config? Probably Dec 21 14:55:55 except the data stores know nothing of each other Dec 21 14:57:24 RP: well it obviously could not extend beyond the conf files anyways. Dec 21 14:58:02 RP: e.g. one could inspect globals across multiconfigs.. Dec 21 14:58:41 LetoThe2nd: I think giving people this option will cause all kinds of determinism problems unfortunately :( Dec 21 14:59:41 RP: yeah, it might be my probably naive mental model of bitbake internals. Dec 21 15:00:46 LetoThe2nd: Yepp, do_unpack did the trick. Thanks Dec 21 15:01:09 :) Dec 21 15:08:23 LetoThe2nd: But I don't yet understand why do_unpack is done when the source lives in a repo, not in a tarball. Though do_fetch either clones the repo or downloads the tarball, and do_unpack does nothing if there's no tarball involved. Dec 21 15:08:58 * manuel__ is reading https://www.yoctoproject.org/docs/latest/overview-manual/overview-manual.html#source-fetching-dev-environment again. Dec 21 15:09:07 manuel__: nah, its just your interpretation of the commands that is off. fetch means: "get somethign and put it into DL_DIR" Dec 21 15:09:27 unpack means: "get something out of DL_DIR and put it into work" Dec 21 15:12:26 True, I forgot repos are cloned into /downloads/git2/, what I have in the package specific WORKDIR is just a copy. Dec 21 15:13:47 :-) Dec 21 15:22:00 LetoThe2nd: saw your multiconfig question in scrollback, in my container examples I package the container image in a recipe that the host image just includes Dec 21 15:23:09 LetoThe2nd: which requires knowing where the container build deploy dir is Dec 21 15:23:33 smurray: already figured it out. thought there must be a way to pass knowledge from one build to the other, which doesn't seem to be the case. so either magic file, or magic constants. Dec 21 15:24:08 LetoThe2nd: right, in my example in my presentation I set variables in the main config Dec 21 15:24:22 smurray: yep, one option. Dec 21 15:25:14 smurray: outcome will be presented in 24.5h from now :) Dec 21 15:25:22 LetoThe2nd: ideally, it'd be possible to query the env of the other mc's with some syntax, but it'd likely be non-trivial Dec 21 15:25:37 smurray: scroll back 30 minutes here... :) Dec 21 15:26:37 LetoThe2nd: heh, I did say "non-trivial", at least Dec 21 15:30:51 anyone has experience with replacing splash on RPi? I tried the suggestions from https://stackoverflow.com/a/63732589 with no success Dec 21 16:50:10 LetoThe2nd, well done for doing these live streams. I received an email from Twitch and had a look at it for a while. Dec 21 16:54:20 leon-anavi: hehe thanks. It was just a fun session today, the "real" one is taking place tomorrow. Dec 21 17:04:19 LetoThe2nd: I expectd at least an alias name for bitbake in the barbarian language :-D Dec 21 17:38:20 kanavin_home: found the man-db issue now too, hopfeully Dec 21 17:38:41 JPEW: do you have any thoughts on how we can invalidate individual recipe hash equiv? Dec 21 17:39:17 JPEW: have a small problem in a case like this since we have a "bad" output mapped as equivalent to a "good" output and no easy way to get it out the system :( Dec 21 17:53:45 zeddii: wonder which of us will win this race for the workers :) Dec 21 17:54:25 this stupid warning, that I created with the tools, is annoying me. I fix one case, and the other warns. I think I have it now. But kill my builds if they case problems. Dec 21 17:59:01 zeddii: its fine, I think I won the race for workers (by luck!) Dec 21 18:05:21 JPEW: I've tried something horrible (on list) Dec 21 18:43:07 RP: question about _append ... let's say a layer does IMAGE_FSTYPES_append = "foo" . How should a user that does want to define his very own set of IMAGE_FSTYPES get his done ? In general the question boils down to how to deal with _appends that you might not want _or_ how to (re)set a variable late ignoring the _appends. Dec 21 19:00:04 RP: right, but should those be dropped from exception list as well then? Dec 21 19:01:26 kanavin_home: man-db-doc wasn't on the exception list... Dec 21 19:02:11 dl9pf: this is a long standing problem with _append, its very hard to undo it :( Dec 21 19:02:32 dl9pf: one thing you can do is reset the variable in anonymous python Dec 21 19:09:43 ok Dec 21 19:12:20 dl9pf: a d.setVar() will clear all appends and removes FWIW Dec 21 20:01:39 how can I submit a new subtree into yocto-kernel-cache bsp/ ? Dec 21 21:45:49 how can I submit a new subtree into yocto-kernel-cache bsp/ ? Dec 21 22:36:45 dv|2: I guess the README in the repository should explain that? Dec 21 22:37:58 kanavin_home, ah! thanks Dec 21 22:51:04 RP: just wanted to check, was mesa upgrade overlooked, or still to be added to -next? Dec 21 22:59:18 kanavin_home: I probably missed it :/ Dec 21 23:00:50 kanavin_home: I'll queue in -next, thanks **** ENDING LOGGING AT Tue Dec 22 03:00:27 2020