It's difficult (impossible?) to automatically detect whether an ARM target supports NEON at build time, so this looks unlikely to work. Testing for NEON either needs to happen at run time or the infor

Seems like you made a conscious decision to refer to the gcc runtime library as "gnu" instead of "gcc". What was the reasoning? Using "gcc" would seem to be clearer unless it clashes with some gcc ups

This should be hardcoded to enable LFS. The largefile distro feature isn't used in oe-core (ie disabling LFS is not supported or even possible anymore). The distro feature should be removed completely

On Tue, Jul 26, 2022 at 2:39 AM Johannes Schneider via lists.openembedded.org <johannes.schneider=leica-geosystems.com@...> wrote: Comment should be updated too "... if empty-root-p

Yeah... += with an over-ride is intuitive but 99.9% of the time is completely wrong. There was a discussion some time ago about having the parser reject it with an error because it repeatedly trips up

<richard.purdie@...> wrote: My proposal would be to try to reuse Linux kconfig. Users know how to run "make oldconfig", "make menuconfig", etc and I believe all key distro / machine co

The default (ie 5GB) would seem safer for most users. Apart from some potential loss in performance, there's no downside to reaching the limit (i.e. there's no "overflow" as you describe it) and 5GB o

<richard.purdie@...> wrote: Adding LSB_DISTRO_ADJUST directly to lsb.py would be fine I think. Personally I use LSB_DISTRO_ADJUST to map Linux Mint to Ubuntu. Linux Mint is binary comp

Question isn't really whether it will work or not (if it doesn't work, we should make it work) but rather whether any user-defined LSB_DISTRO_ADJUST should be applied before checking if the host distr

<nicolas.dechesne@...> wrote: Not directly related to your change, but shouldn't this be lsb_distro_identifier() instead of oe.lsb.distro_identifier()?

<paul.gortmaker@...> wrote: It looks like this will address the performance issues of using git from a devshell too. Trying to run git log, git blame, etc for largeish repos in a devshell is

<richard.purdie@...> wrote: Over enthusiastic copy and paste?

This should either be gnutls or openssl, not both. But aside from that, gnutls brings (L)GPLv3 issues and therefore should not be enabled by default. Are you saying that some glib-networking functiona

Common case seems to be allowing gdb in debug builds of distros which are otherwise free of GPLv3 etc, e.g. https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/distro/include/gdbse

Yes, when refreshing the defconfig you need to do it first with all config fragments disabled and then review and manually update the fragments as required as a second step.

Any more feedback? The misconception that no one cares about improving this could be because discussions on the topic always seem to peter out leaving these unanswered questions.

<peter.kjellerstedt@...> wrote: Using = would certainly be OK and an improvement over the current mess. The reason I'd still argue that ?= is better is that it gives a clear hint that PACKAGECONF

<richard.purdie@...> wrote: What are the possible objections? I agree ??= is way overused and very often in places where ?= or a direct assignment would be better. I'm not the one acce

<richard.purdie@...> wrote: As a first, very easy, step, make a statement here on the mailing list that all PACKAGECONFIG defaults should be assigned with ?= instead of ??= and fix the

The only recipe? There are many recipes which set a default PACKAGECONFIG with ?= and many which set it with ??=. Your change is effectively switching the vim recipe from one approach to the other. Th