**** BEGIN LOGGING AT Mon Mar 16 02:59:58 2020 Mar 16 08:46:03 good morning Mar 16 09:03:11 mornin Mar 16 09:29:48 is it possible to make one bbclass depend on another class, i.e. if I write a class that extends a functionality or hooks up to something that has been defined in an nother existing bbclass? Mar 16 09:36:21 Jin^eLD, yes, there are bbclasses in oe-core that does that Mar 16 09:37:04 Jin^eLD, populate_sdk.bbclass for instance Mar 16 09:37:50 hmm it just inherits the other class, but that'd mean it takes the lead? Mar 16 09:41:23 Jin^eLD, oh i may have misunderstood you Mar 16 09:41:51 well I wanted to hook myself to something in the image_types_wic.bbclass Mar 16 09:42:16 Jin^eLD, maybe https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#flexible-inheritance-for-class-functions Mar 16 09:42:21 so if someone inherited my class I'd need the wic one as dependency, but mine is not taking over, just extending so to speak, at least that was the idea Mar 16 09:47:00 thanks for the pointer, that could maybe work, let me read that in detail Mar 16 12:06:28 hmm, if I want to add some configuration file for processing by a class to an image recipe, i.e. SRC_URI += "file://..." it gets ignored Mar 16 12:06:42 I assume because the image inherit sets noexec no do_fetch Mar 16 12:06:46 what is the proper way to do that? Mar 16 12:07:16 i.e. if I would want to get a file in WORKDIR which won't be part of the image but is only needed for processing and generating a configuration Mar 16 12:07:19 ? Mar 16 12:09:57 or is delVarFlag the only way to go here? Mar 16 19:08:24 does yocto's u-boot classes support defconfig drop-in and config snippets, i.e. same things like what the kernel stuff offers? Mar 16 19:19:31 ok, seems its an exclusive kernel.bbclass feature Mar 16 19:35:38 yeah it needs kconfig merge feature underneath Mar 16 19:46:01 I understand that apparently also not each kernel recipe supports that out of the box, what is the limitation there? Mar 16 19:48:02 the linux-yocto bbclass does it, others have to do so manually due to inconsistency in how .config is populated from the defconfig Mar 16 19:48:13 kernel-yocto that is, linux-yocto recipe Mar 16 19:49:11 where does this inconsistency come from, kernel version or custom/vendor hacks? Mar 16 19:49:24 just wondering what prevents everyone from using kernel-yocto.bbclass? Mar 16 19:50:04 not all projects are yocto based, historically kernel-yocto had more overhead, and was associated iwth linux-yocto's branching and tooling, incorrectly or not Mar 16 19:50:41 kernel.bbclass has a fallback to copy defconfig to .config, but not all recipes use it, and it's done in do_configure, so there's no good place to inject config fragment handling there, and every recipe does it differently Mar 16 19:51:06 there's an open issue to resolve this in the bugzilla Mar 16 19:52:52 ah, so its mostly a somewhat historic limitation, but sounds like nothing would prevent me from converting my kernel recipe t the kernel-yocto way Mar 16 19:53:29 yep, quite true Mar 16 19:53:49 and it's usually pretty straightforward to inject fragment handling into any given kernel, just how you do so varies Mar 16 19:53:59 as a distro maintainer i've appended numerous bsp kernels to do that Mar 16 19:54:12 Jin^eLD: We don't use kernel-yocto, but we do have our own recipe that pulls in linux-yocto.inc and manages the configuation in our own kmeta repo Mar 16 19:55:36 another example it meta-raspberrypi kernel Mar 16 19:56:20 and meta-meson IIRC used linux-yocto tooling with non linux-yocto kernels Mar 16 19:57:20 JPEW: I was actually not aiming at meta-rockchip, I rather have an stm32mp1 kernel to convert... Mar 16 19:57:39 khem: thanks for the insight, sounds reassuring Mar 16 19:58:10 JPEW: as far as meta-rockchip goes: I had a hard time figuring out which one (or which combination) of the 15+ armbian patches does solve the clk-emmc conflict Mar 16 19:59:19 Jin^eLD: Ya, I wasn't referring to meta-rockchip :) Mar 16 19:59:49 oh :) Mar 16 20:00:11 I thought of it because I think meta-rockchip does not use the kernel fragments either :> at least tlwoerner warned me about that iirc Mar 16 20:15:24 Jin^eLD: as I discovered recently, meta-qcom does it as khem describes, _append to do_configure to call merge-config.sh Mar 16 20:15:42 We've done it that way too Mar 16 20:16:06 thx for the hint, I'll have a look what's easier, if I can use the kernel-yocto.bbclass directly I'd rather try taht first Mar 16 20:18:05 I asked zeddii recently about adding fragment merging in kernel.bbclass, iirc he has patches for it (and has for a while), but I suspect it's still a ways out Mar 16 20:18:23 would be nice to avoid re-inventing the wheel everywhere, though Mar 16 20:18:44 the latest is here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8191 Mar 16 20:18:45 smurray: then why not use kernel-yocto.bbclass instead of patching kernel.bbclass? Mar 16 20:19:00 once we get LTS out the door, I’ll send it out the door. Mar 16 20:19:06 that’s a lot of doors Mar 16 20:19:08 :D Mar 16 20:19:34 Jin^eLD: a lot of people we'd prefer just to have a defconfig and not learn how to wrangle setting up kernel-meta Mar 16 20:19:37 zeddii: thx for the link Mar 16 20:19:43 in th end it is more than just whacking fragments together. Mar 16 20:19:43 err, would prefer Mar 16 20:20:11 but I thought kernel-yocto.bbclass allows you to chose... either drop in your defconfig or fiddle with fragments, both is supported, no? Mar 16 20:20:13 it would be better if there were some common feature definitions, etc, but I’ve left all that in the yocto bbclass and put just the raw merge-config parts into that WIP patch. Mar 16 20:20:25 Jin^eLD: yes, you can do both. Mar 16 20:20:52 then I don't get smurrays argument about people preferring to drop in defconfig instead of fiddling? Mar 16 20:21:12 if both is supported, what again is the blocker for just using kernel-yocto? I seem to be missing a part of the picture here :) Mar 16 20:22:12 historical reasons. many, many years of different ways to configure the kernel. changing people’s workflows isn’t a good idea. And even the way I’ve done it with the yocto reference kernels has changed over time. Mar 16 20:22:47 Jin^eLD: people see kernel-yocto and assume you need to use linux-yocto with it. And as zeddii says, lots and lots of history Mar 16 20:22:55 :) Mar 16 20:22:55 yeah make ; make ; make install Mar 16 20:22:58 that’s why when it was introduced 7 odd years ago, we didn’t even try to put it in kernel.bbclass and created the separate one. Mar 16 20:23:05 thats my workflow Mar 16 20:24:04 and after having to maintain over 200+ defconfigs, we ended up with the fragment workflow. but if people haven’t had to scale to that level, there’s no way to convince or switch their flows (nor should they have to). Mar 16 20:24:10 I consider it like telling me to use vim :P Mar 16 20:24:26 zeddii: exactly. Mar 16 20:24:27 I’ll tell you to get bent, and I can respect that position :D Mar 16 20:24:39 zeddii: you should definitely use vim! :> Mar 16 20:24:40 zeddii: not everyone is a OSV Mar 16 20:24:50 supporting 100s of BSPs Mar 16 20:24:54 I’m pretty sure that’s what I just said .... Mar 16 20:25:09 I must admit I don't fully understand how the kernel-meta + auditing, etc. quite all works at the end of the day Mar 16 20:25:35 we have like 1 or maximum 2 configs per bsp, with less than 10 bsps total. hence, we're super fine with just defconfigs. Mar 16 20:26:03 zeddii: I thought you said you dont use vim :) Mar 16 20:26:25 I think for my current use-case I'd probably be fine with a defconfig drop-in which kernel yocto does support; if fragments are also possible - good, but noone is forced to use them, so its fine either way Mar 16 20:26:33 yup. Mar 16 20:26:45 and if it isn’t that simple, please find me and kick me in the shins Mar 16 20:27:21 :) Mar 16 20:28:05 good to know whom to kick =) Mar 16 20:28:24 take it easy everyone, I’m going to go self isolate and make some supper :D Mar 16 20:28:32 :)) Mar 16 20:28:37 thanks for the pointers! Mar 16 20:29:23 so npm is now MS https://techcrunch.com/2020/03/16/github-nabs-javascript-packaging-vendor-npm/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAABowdeqg5NVlMkHB8Br8_AgrlkVwR0ZJO8qYZhyqzuN7QrEax0kS3ni-f0jMhsqFWEXt6goQt2wm12c8S03G_SUJBCUY24EG1fLJPc0jsDN1IYtfNL3diOqIKGKJQcCwpE9AGvwWwdJ7Y9HNrseNJvPCCMnHc5tP4yJyVSaIuUwQ Mar 16 20:30:22 khem: given the current states of npm and MS, i consider that a massive chance for improvement actually. Mar 16 20:30:42 yeah eventual singularity for all humanity Mar 16 21:22:12 I'm trying to figure out how to deal with hash changes. Normally this package uses mesa for it's virtual/libgle require.. but I've got an alternative package, libmali, that can also probive libgle. But when I change my preferred provider the hash changes and it rebuilds.. Mar 16 21:22:16 any way to stop that behavior? Mar 16 22:06:39 vardepexclude ? **** ENDING LOGGING AT Tue Mar 17 02:59:57 2020