Please create dunfell branch

[pbrkr]

As there is no dunfell branch in this repo, the OE layer index does not show meta-browser when you search for layers compatible with the dunfell release. We know that the master branch of meta-browser is compatible with several recent releases but it looks like the OE layer index only looks at branch names.

It's not possible to fetch this layer using bitbake-layers layerindex-fetch ... when using the dunfell branch of poky:

pokyuser@792b33252a59:/w/poky/build$ bitbake-layers layerindex-fetch meta-browser
NOTE: Starting bitbake server...
Loading https://layers.openembedded.org/layerindex/api/;branch=dunfell...
ERROR: Layer "meta-browser" not found in layer index

This also breaks the listing for meta-arago-distro in the layer index as this layer depends on meta-browser. The dunfell branch of meta-arago-distro cannot be fetched due to this missing dependency:

pokyuser@792b33252a59:/w/poky/build$ bitbake-layers layerindex-fetch meta-arago-distro
NOTE: Starting bitbake server...
Loading https://layers.openembedded.org/layerindex/api/;branch=dunfell...
Traceback (most recent call last):
  File "/w/poky/bitbake/bin/bitbake-layers", line 95, in <module>
    ret = main()
  File "/w/poky/bitbake/bin/bitbake-layers", line 88, in main
    return args.func(args)
  File "/w/poky/bitbake/lib/bblayers/layerindex.py", line 119, in do_layerindex_fetch
    (dependencies, invalidnames) = lIndex.find_dependencies(names=args.layername, ignores=ignore_layers)
  File "/w/poky/bitbake/lib/layerindexlib/__init__.py", line 443, in find_dependencies
    (dependencies, invalid) = _resolve_dependencies(layerbranches, ignores, dependencies, invalid)
  File "/w/poky/bitbake/lib/layerindexlib/__init__.py", line 386, in _resolve_dependencies
    deplayerbranch = layerdependency.dependency_layerBranch
  File "/w/poky/bitbake/lib/layerindexlib/__init__.py", line 915, in __getattr__
    raise AttributeError('%s not in datastore' % name)
AttributeError: dependency_layerBranch not in datastore

This should be easily fixed by creating a dunfell branch in this repo.

[rakuco]

Hmm, no objections to creating the branch, but I wonder if there's a way to keep it in sync with master without having to test and push things to 2, or all, the branches we have.

[pbrkr]

@rakuco I've sadly never found a good way to do that in git. As master and dunfell diverge it's likely that testing each separately will be needed anyway and at some point in the future there may be incompatible changes required.

[otavio]

@pbrkr it'd be nice if the layer index would be fixed and respect the compatibility variable.

I am not against making the branch but it looks like an workaround for a bigger issue.

[pbrkr]

@otavio It is a bit of a workaround. There are bugs filed for the layer index but I don't expect them to be closed soon. It's far easier to create branches where needed.

[kraj]

IMHO layerindex should be fixed to read LAYERSERIES_COMPAT from conf/layer.conf instead of forcing everyone to create branch to resemble release branch. maintaining browsers is a huge ask and creating specific branches just forks the work which we don't have luxury of. So please ask the layerindex to be fixed.

[otavio]

That's also my opinion. The more people complain and request it to be fixed, the better.

[pbrkr]

The upstream bug is here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11195.

[otavio]

Does not sound right; this is for maintainer address, not branches, it seems.

[bamkrs]

Maybe its of use for anyone but with these few changes, meta-browser (ozone-wayland-chromium at least) for yocto dunfell compiles fine:

diff --git a/conf/layer.conf b/conf/layer.conf
index 2572211..488dfc9 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -113,3 +113,5 @@ LAYERVERSION_browser-layer = "1"
 LAYERSERIES_COMPAT_browser-layer = "warrior zeus dunfell gatesgarth"

 LAYERDEPENDS_browser-layer = "clang-layer core openembedded-layer"
+
+HOSTTOOLS += "python python2.7 python2"
\ No newline at end of file
diff --git a/dynamic-layers/rust-layer/recipes-browser/mozilla-devscripts/mozilla-devscripts_git.bb b/dynamic-layers/rust-layer/recipes-browser/mozilla-devscripts/mozilla-devscripts_git.bb
index e501478..37c2883 100644
--- a/dynamic-layers/rust-layer/recipes-browser/mozilla-devscripts/mozilla-devscripts_git.bb
+++ b/dynamic-layers/rust-layer/recipes-browser/mozilla-devscripts/mozilla-devscripts_git.bb
@@ -12,7 +12,7 @@ SRC_URI = "git://git.debian.org/pkg-mozext/mozilla-devscripts.git;protocol=git"

 S = "${WORKDIR}/git"

-inherit distutils
+inherit distutils3

 do_install_append() {
     rm -r ${D}${datadir}
diff --git a/recipes-browser/chromium/chromium.inc b/recipes-browser/chromium/chromium.inc
index eb7766d..a5017f0 100644
--- a/recipes-browser/chromium/chromium.inc
+++ b/recipes-browser/chromium/chromium.inc
@@ -18,7 +18,7 @@ TOOLCHAIN = "clang"
 # to build the native recipes (e.g. GN) with clang too.
 TOOLCHAIN_class-native = "clang"

-inherit pythonnative setuptools
+inherit python3native setuptools3

 # Chromium itself is licensed under the 3-clause BSD license. However, it
 # depends upon several other projects whose copyright files are listed in
-- 
2.20.1

[r1mikey]

Maybe its of use for anyone but with these few changes, meta-browser (ozone-wayland-chromium at least) for yocto dunfell compiles fine: ...

I don't think that insisting on python2 in the hosttools is the right approach. My development environment, for example, does not include Python2 on the host.

This layer works correctly if you include meta-python2 in your bblayers.

Branches older than Dunfell should exist (IMHO), as this recipe needs to inherit mime-xdg from Dunfell onwards (or some runtime magic should be done), but insisting on an unsupported Python in hosttools is not a change I'd advocate for.

[bamkrs]

Including meta-python2 did not work for me at all. It wasn't picked up by any of the recipes. This was the only quick workaround.

[wrightleft]

Just for clarification, this layer depends on meta-python2? I don't see that listed as a layer dependency. Am I missing something?

[kraj]

perhaps we want to add this to LAYERDEPENDS to layer.conf

[otavio]

Agreed. @pbrkr mind to prepare a PR for this?

[rakuco]

Does meta-python2 also include Python itself? I was looking at its recipes-devtools/python directory and only managed to find packages that use Python 2 instead.

[shr-project]

Yes, it does, see https://git.openembedded.org/meta-python2/tree/recipes-devtools/python/python_2.7.18.bb

[rakuco]

Ah I see, that recipe only seems to exist in dunfell and later branches. Would it be problematic to depend on meta-python2 while also having "warrior" and "zeus" in our LAYERSERIES_COMPAT_browser-layer or will things Just Work, as I guess Python 2 would just come from OE-core in this case?

[joshuaimmanuel]

I checked out the commit ac716dfb074170914d1a7571a1a458be6f54ed95 which is just before the kirkstone migration and copied the chromium folder to my layer. Along with this, I have added dunfell-clang12 branch of meta-clang layer. This combination works with dunfell without any issue.

[Ronta]

Hi @joshuaimmanuel, i'm following your tips, but i have some problems with this third part library:

| FileDescriptor(FileDescriptor&& other) : fd(std::exchange(other.fd, -1)) {} | ~^~~~ | exchange | /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/move.h:157:5: note: 'exchange' declared here | exchange(_Tp& obj, _Up&& new_val) | ^ | In file included from ../../base/third_party/symbolize/symbolize.cc:64: | ../../base/third_party/symbolize/symbolize.h:127:18: error: no member named 'exchange' in namespace 'std'; did you mean 'exchange'? | fd = std::exchange(rhs.fd, -1); | ~^~~~ | exchange | /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/move.h:157:5: note: 'exchange' declared here | exchange(_Tp& __obj, _Up&& new_val) | ^ | 2 errors generated.

I believe the error is due to the c++ version. What version of C++ are you using? and have you configured it somewhere?

[rakuco]

@Ronta Note that we've recently started requiring the usage of the dunfell-clang14 branch, which should no longer use the system's libstdc++ for parts of the build as appears to be happening in your post.

[Ronta]

thank you @rakuco! It's great, in fact now I no longer have that error, but I have another one after which would be this one here:

| ../../chrome/browser/web_applications/web_application_info.cc:40:14: error: exception specification in declaration does not match previous declaration
| IconBitmaps::IconBitmaps(const IconBitmaps&) noexcept = default;
| ^
| ../../chrome/browser/web_applications/web_application_info.h:56:3: note: previous declaration is here
| IconBitmaps(const IconBitmaps&);
| ^
| ../../chrome/browser/web_applications/web_application_info.cc:42:14: error: 'IconBitmaps' is missing exception specification 'noexcept'
| IconBitmaps::IconBitmaps(IconBitmaps&&) = default;
| ^
| noexcept
| ../../chrome/browser/web_applications/web_application_info.h:57:3: note: previous declaration is here
| IconBitmaps(IconBitmaps&&) noexcept;

Before wasting your time, and my time, unnecessarily, should I continue compiling from committ ac716df, or can I build the latest versions?

Thank you,

Fabio

[rakuco]

That commit is fairly old and has a very old Chromium release, so it's always a good idea to use the latest revision if possible.