layer.conf: Update to whinlatter (5.3) layer/release series

[jcalvinowens]

No description provided.

[OldManYellsAtCloud]

meta-firefox is unfortunately not compatible yet - just this morning I tried to build it using the almost tip of oe-core, and glibc/x86-64 build failed to compile with some cool assembly instruction error (maybe there are other failing combos also). I will have access to a reasonably strong machine only in the second half of the week to debug it.

Until than the Firefox part will need some patience (or someone else to look at it :) )

[jcalvinowens]

I'll take a look :)

[jcalvinowens]

0:00.68 /home/calvinow/git/meta-house/build/tmp-house/work/universal-v3-64-house-linux/firefox/139.0.4/recipe-sysroot-native/usr/bin/x86_64-house-linux/x86_64-house-linux-as: invalid option -- 'N'
0:00.68 Fatal error: invalid listing option `,' 

Hmm, is the firefox build using the wrong AS now? It's as though this line is no longer having any effect: https://github.com/OSSystems/meta-browser/blob/master/meta-firefox/recipes-browser/firefox/firefox.inc#L124

The new Rust version unfortunately also breaks Chromium:

[298/55607] ln -f yocto_native_for_rust_host_build_tools/obj/build/rust/std/lib/libadler.rlib yocto_native_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler.rlib 2>/dev/null || (rm -rf yocto_native_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler.rlib && cp -af yocto_native_for_rust_host_build_tools/obj/build/rust/std/lib/libadler.rlib yocto_native_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler.rlib)
FAILED: yocto_native_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler.rlib 
ln -f yocto_native_for_rust_host_build_tools/obj/build/rust/std/lib/libadler.rlib yocto_native_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler.rlib 2>/dev/null || (rm -rf yocto_native_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler.rlib && cp -af yocto_native_for_rust_host_build_tools/obj/build/rust/std/lib/libadler.rlib yocto_native_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler.rlib)
cp: cannot stat 'yocto_native_for_rust_host_build_tools/obj/build/rust/std/lib/libadler.rlib': No such file or directory

I'll poke more tomorrow.

[OldManYellsAtCloud]

0:00.68 Fatal error: invalid listing option `,'

Yep, this is it.

Hmm, is the firefox build using the wrong AS now?

This kinda makes me remember that there was some change (at least I believe this was that particular change) in oe-core about toolchain selection that started to break recipes that are changing base toolchain details (there is a deferred toolchain class inheritance that overrides a lot of modifications from the recipe). I'm definitely not sure if this is the case here, it just flashed into my mind as you mentioned AS. (Once I saw this error yesterday, I put it on the side due to other things, haven't look at it at all yet. But as a confirmation-test, maybe I would try adding export AS="${CC}" at the start of do_compile before starting to think where and how to continue)

[jcalvinowens]

Seems like that was the only problem there, the latest push here gets firefox working for me (using master-next on the yocto upstream repos).

[OldManYellsAtCloud]

Unfortunately this will make the layer only compatible with Whinlatter, and with none of the others.
Currently I can't really think of anything better than something like

WHINLATTER_S = "${UNPACKDIR}/${BB_GIT_DEFAULT_DESTSUFFIX}"
NON_WHINLATTER_S = "${WORKDIR}/git"
S = '${@bb.utils.contains_any("LAYERSERIES_CORENAMES", "whinlatter", "${WHINLATTER_S}", "${NON_WHINLATTER_S}", d)}'

But still thinking if there is some other solution. The same for the cbindgen recipe.

(This comment is only valid for the Firefox layer. The Chromium folks might have a very different opinion about this)

[OldManYellsAtCloud]

I believe that this S declaration can be removed altogether to make it work on all Yocto versions. I'm almost sure that the recipe is happy with whatever the default value is, I just most probably generated this recipe with pipoe or similar, and didn't remove it. (Though I will try to test this theory soon)

[OldManYellsAtCloud]

Nope, I was wrong, it's a load-bearing variable :(
Then I think this should be also something to the same effect as for the wasi-sdk and cbindgen recipes to maintain compatibility, unless you (or anyone else) have a better idea.

[OldManYellsAtCloud]

Meanwhile I got a better idea for this particular recipe:
remove SRC_URI* (except for sha256), S, RDEPENDS, and add pypi to the inherits. It should make it work in all versions, without specifying anything extra.

[otavio]

I am the one who usually tries to avoid creating branches for maintenance. However, we might need to do so or consider a general solution that allows the entire layer to maintain compatibility, or accept that it will become too messy and simply create a branch for compatibility with older versions.

The main problem with branching is that it requires us to perform two separate tasks and also handle the backend updates needed to preserve compatibility with old versions during that time. This is a decision we likely need to make.

If we decide to pursue backward compatibility, we might want to have a separate file that we include based on the code name. This way, we can include those files in the layer.conf file, making them available across the entire set of recipes and simplifying the process of maintaining compatibility.

[OldManYellsAtCloud]

Do you (and all the others around) have any preference?

Branching is what I'd like to avoid also, if possible, for the same reasons. On the other hand, while I value compatibility a lot, I won't die on that hill if I get downvoted...

I wouldn't terribly mind having some conditional include, but what do you have in mind? A list of S:pn-foo variables, or something else?

[jcalvinowens]

Like everyone else here, I'm sure, I need to solve this problem for several other repositories, so I'm really interested in potential solutions. I'd imagine upstream will eventually publish some guidance, but I think it's too early as of yet.

My two cents, I've always tried to avoid branching in my own repos, mostly for the same reasons discussed here. I'll try setting up what @otavio suggested.

I'll split the simpler stuff which is backwards compatible into separate PRs, so this one can just be for that discussion.

[OldManYellsAtCloud]

I'll split the simpler stuff which is backwards compatible into separate PRs, so this one can just be for that discussion.

Sounds good to me - if there will be multiple PRs, it would be also good to submit PRs separately for meta-firefox and meta-chromium, so they won't block each other.