This isn't equivalent - it will cause a change in behaviour for anyone using PACKAGECONFIG += "foo" from a .bbappend.

<alex.kanavin@...> wrote: I guess looking at the two logs in a graphical tool such as meld would highlight if command line options completely disappear, even with the noise of differences in pro

<alex.kanavin@...> wrote: Looks good. If you have the full strace logs for both cases then it might still be useful to check which (if any) command lines are changed by removing the patch, but i

<alex.kanavin@...> wrote: The comment in the patch was: This fixes the issue where LDFLAGS escaped with -Wl are ignored during compilation. Seems fairly clear! Checking that the AB run didn't fa

<peter.kjellerstedt@...> wrote: It's unusual for a recipe to add cmake-native to DEPENDS rather than inheriting the cmake class. Your patch comments should probably explain why it's the correct a

<peter.kjellerstedt@...> wrote: Not related to your cleanup, but this is redundant as it's covered by the generic mapping below.

<peter.kjellerstedt@...> wrote: Last two lines are duplicates. ftp mirrors should probably be replaced with https. Are these even useful at all? They were added in 2012...

As a further improvement you can drop the rm -f ${IMAGE_ROOTFS}/sbin/iptables and add -f to the ln command. Same comment here: you can drop the rm -f and use ln -rsf.

<maxims=google.com@...> wrote: You're doing that just to generate a build time error if the two recipe's configurations are not consistent? The normal approach would be to define a

The example in local.conf.sample uses file://.* rather than file://.\*

git blame is often the best starting point for understanding why things are done in a certain way. In this case the comment from the original comment (from 11 years ago..) references portmap, which is

<richard.purdie@...> wrote: I'm sure this was discussed before but I forget the answer... how much compression / performance is lost by setting the XZ memory limit to a fixed value whi

Assuming configure.ac is based around AC_ARG_ENABLE / AC_ARG_WITH then an explicit option is not required. A default value of "yes" will be set for --enable-foo / --with-foo and a default value of "no

Running all CPUs at 100% load shouldn't cause lockups unless there's a HW problem. Another possible cause of lockups is using all available DRAM (which is obviously related to how many simultaneous pr

I don't have any interest in systemd + musl anymore either. I did an initial port as a proof of concept and sent patches to Khem off list... and was somewhat surprised when they showed up some time la

Could this just be set to ld.bfd in all cases?

I wrote a long and verbose comment when I created the patch which tries to document any differences in runtime behaviour. ---- Avoid using AT_SYMLINK_NOFOLLOW flag. It doesn't seem like the right thin

<richard.purdie@...> wrote: Unfortunately those most affected by shortcomings in the script are probably also those least likely to submit patches for it. Just as those most affected b

If the caller only cares about yes/no then how about returning 1/0 instead of a pointer?

<richard.purdie@...> wrote: I haven't read the script but doesn't it distinguish between things following an _ which might be an override (and will never be all uppercase) and the vari