meta-rockchip conflicts with kirkstone update for xserver

The module affected

meta-rockchip, but breaking zephyr/freertos builds

What is the action to reproduce the bug?

Grab kirkstone-nut that includes the patch "xserver-xorg: update 21.1.3 -> 21.1.4"

MR status: !240 (diffs)

What is the result you see?

Zephyr/freertos fails:

Parsing recipes...WARNING:
/tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
Exception during build_dependencies for AUTOREV
WARNING: /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
Error during finalise of
/tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
ERROR: ExpansionError during parsing
/tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
Traceback (most recent call last):
File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
249, in Git.urldata_init(ud=<bb.fetch2.FetchData object at
0x7fc0cb054970>, d=<bb.data_smart.DataSmart object at
0x7fc0cafbd0d0>):

    ud.setup_revisions(d)

File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
line 1347, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart
object at 0x7fc0cafbd0d0>):
for name in self.names:

    self.revisions[name] = srcrev_internal_helper(self, d, name)

File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
line 1212, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at
0x7fc0cb054970>, d=<bb.data_smart.DataSmart object at 0x7fc0cafbd0d0>,
name='default'):
if srcrev == "AUTOINC":

    srcrev = ud.method.latest_revision(ud, d, name)

File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
line 1624, in Git.latest_revision(ud=<bb.fetch2.FetchData object at
0x7fc0cb054970>, d=<bb.data_smart.DataSmart object at 0x7fc0cafbd0d0>,
name='default'):
except KeyError:

    revs[key] = rev = self._latest_revision(ud, d, name)

return rev
File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
752, in Git._latest_revision(ud=<bb.fetch2.FetchData object at
0x7fc0cb054970>, d=<bb.data_smart.DataSmart object at 0x7fc0cafbd0d0>,
name='default'):
return sha1

    raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git repository in git ls-remote output for %s" % \

(ud.unresolvedrev[name], ud.host+ud.path))
bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
upstream git repository in git ls-remote output for
github.com/JeffyCN/xorg-xserver

The reason is that meta-rockchip in https://github.com/JeffyCN/meta-rockchip/blob/master/recipes-graphics/xorg-xserver/xserver-xorg_%25.bbappend replaces the xserver sources (unconditionally) with a local fork that also does AUTOREV

See also discussion in https://lists.openembedded.org/g/openembedded-core/message/168793

What is the result you expect?

Build should succeed

Frequency?

always

Tested version

Oniro 025e67f1 + kirkstone-nut (no longer avail, https://git.yoctoproject.org/poky-contrib/commit/?h=stable/kirkstone-nut&id=d98dfd69fddcfc839fb15a65947fc9c3eaace6a4 to be verified)

Do you know any workaround of this issue?

no

Do you have a fix for this issue?

no

added IssueBug needs-investigation teammaintenance labels

changed the description

This issue is blocking a kirkstone update

Cc: @waykovalenko

I will look into it

@waykovalenko please contact me on the chat, we've investigated more with @agherzan

added teamhw label and removed teammaintenance label

added teammaintenance label and removed teamhw label

Status update: we have discussed it with @waykovalenko . This direct problem is understood, but a question remains on the use of the rockchip layer. The current version is not what is envisioned by SECO as the final solution. @waykovalenko is taking a look at how to solve the problem short and mid-term.

@mrybczyn please have a look at last two commits here https://git.seco.com/pub/rockchip/meta-seco-rockchip/-/commits/kirkstone

@waykovalenko can we go a step forward and make meta-seco-rockchip depend on the meta-rockchip layer and provide only the seco specific bits (with machine overrides)?

in theory: ideally, the best solution is to depend on Yocto project https://git.yoctoproject.org/meta-rockchip/tree/ (u-boot and kernel from mainline), but our meta layer based on this project https://github.com/JeffyCN/meta-rockchip. Seco uses this one. from this project we can get the Rockchip's binaries the device is still depending on, tools to package the firmware and also the GPU user-space libraries. I don't know if it makes sense to bring this project into the oniro. Right now I am trying to port the bootloader to mainline version, the docs say that "not all the platforms supports the both boot-loader methods (one based on the source code and another based on the binaries)" https://opensource.rock-chips.com/wiki_Boot_option. So there are always a risk that the early stage loader binary from Rockchip is still needed. We will see.

So what stops us exactly to makes it on https://git.yoctoproject.org/meta-rockchip/tree/? Can't we work with https://git.yoctoproject.org/meta-rockchip/tree/ to provide all the missing bits now in https://github.com/JeffyCN/meta-rockchip? I'm not sure I understand what was the aim of https://github.com/JeffyCN/meta-rockchip in the first place.

Because as start up point there was nothing of mainline(u-boot, kernel) and neither now.

I'm not sure I'm with you on this. The layer is an integration layer, not the sources for mainline u-boot, kernel etc. Why do we need an extra fork for it? What is this fork providing on top of the yocto "official" layer?

as I can see from here https://git.yoctoproject.org/meta-rockchip/tree/, too little compatibility, too little metadata to depend on. We have to create BSP layer, right.

So let's align it to provide all we need. We can do that while discussing a unification strategy/plan with the maintainer of the fork.

closed

removed needs-investigation label

added ValidationPassed label