[meta-rockchip][PATCH] linux-torvalds-next: use AUTOREV

[meta-rockchip][PATCH] linux-torvalds-next: use AUTOREV

[Trevor Woerner]

Already the SRCREV that was used for -next has been rebased out of existence.
Also that tag that was originally proposed no longer exists. With a repository
that is rebased so regularly, the only thing we can safely use to hope for
valid builds that don't need to be tweaked every few days is AUTOREV.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
 recipes-kernel/linux/linux-torvalds-next_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-kernel/linux/linux-torvalds-next_git.bb b/recipes-kernel/linux/linux-torvalds-next_git.bb
index 9a95eb5bc4d8..a87f73dcda89 100644
--- a/recipes-kernel/linux/linux-torvalds-next_git.bb
+++ b/recipes-kernel/linux/linux-torvalds-next_git.bb
@@ -10,13 +10,13 @@ COMPATIBLE_MACHINE = "^$"
 COMPATIBLE_MACHINE:radxa-zero-3 = "radxa-zero-3"
 
 LINUX_VERSION = "6.10-rc3"
-PV = "${LINUX_VERSION}+git${SRCPV}"
+KERNEL_VERSION_SANITY_SKIP = "1"
+PV = "${LINUX_VERSION}+git"
 SRC_URI = " \
 	git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git;protocol=https;branch=master \
 	file://rockchip-kmeta;type=kmeta;name=rockchip-kmeta;destsuffix=rockchip-kmeta \
 	"
-# this is tag 'next-20240611'
-SRCREV = "a957267fa7e9159d3d2ee1421359ebf228570c68"
+SRCREV = "${AUTOREV}"
 
 inherit kernel
 inherit kernel-yocto
-- 
2.44.0.478.g7774cfed6261

Re: [yocto-patches] [meta-rockchip][PATCH] linux-torvalds-next: use AUTOREV

[Quentin Schulz]

Hi Trevor,

On 6/18/24 1:07 AM, Trevor Woerner via lists.yoctoproject.org wrote:
> Already the SRCREV that was used for -next has been rebased out of existence.

Mmmm, no. It's still there, just not in the master branch.

> Also that tag that was originally proposed no longer exists. With a repository

It still exists. 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=next-20240611

> that is rebased so regularly, the only thing we can safely use to hope for
> valid builds that don't need to be tweaked every few days is AUTOREV.
> 

Or... use ;tag=next-20240611 in the git fetcher and force people to use 
the network for radxa-zero-e boards.

I personally would vote for using the tag instead of AUTOREV. Kernel 
maintainers rarely (have they ever done it?) move tags around so that 
should be fine. Whereas using AUTOREV on linux-next is basically hoping 
that nothing breaks from a development branch, maybe too much to ask for 
right now?

Cheers,
Quentin

Re: [yocto-patches] [meta-rockchip][PATCH] linux-torvalds-next: use AUTOREV

[Trevor Woerner]

On Tue 2024-06-18 @ 12:04:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Trevor,
> 
> On 6/18/24 1:07 AM, Trevor Woerner via lists.yoctoproject.org wrote:
> > Already the SRCREV that was used for -next has been rebased out of existence.
> 
> Mmmm, no. It's still there, just not in the master branch.
> 
> > Also that tag that was originally proposed no longer exists. With a repository
> 
> It still exists. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=next-20240611

Yesterday at noon my time I cloned the linux-next repository on a machine I
had never done this build on and that tag and commit ID were not there, and
this is still true:

	$ git tag
	...
	next-20230310
	next-20230314
	next-20230315
	next-20230316
	next-20230317
	next-20230829
	next-20240613
	v2.6.11
	v2.6.11-tree
	v2.6.12
	v2.6.12-rc2
	...

	$ git show a957267fa7e9159d3d2ee1421359ebf228570c68
	fatal: bad object a957267fa7e9159d3d2ee1421359ebf228570c68

	$ git pull
	...

	$ git tag
	...
	next-20230829
	next-20240613
	next-20240617
	v2.6.11
	v2.6.11-tree
	v2.6.12
	v2.6.12-rc2
	...

	$ git show a957267fa7e9159d3d2ee1421359ebf228570c68
	fatal: bad object a957267fa7e9159d3d2ee1421359ebf228570c68

> > that is rebased so regularly, the only thing we can safely use to hope for
> > valid builds that don't need to be tweaked every few days is AUTOREV.
> > 
> 
> Or... use ;tag=next-20240611 in the git fetcher and force people to use the
> network for radxa-zero-e boards.
> 
> I personally would vote for using the tag instead of AUTOREV. Kernel
> maintainers rarely (have they ever done it?) move tags around so that should
> be fine. Whereas using AUTOREV on linux-next is basically hoping that
> nothing breaks from a development branch, maybe too much to ask for right
> now?

When I click on the commit of the link you provided earlier it says: "Notice:
this object is not reachable from any branch". If the tag is not accessible
from any branch then I can't specify a branch to the fetcher. If I don't
specify the branch to the fetcher then I get flooded with "...you didn't
specify a branch, and we're going to make this mandatory soon..." messages,
flooded!

I also got an email from someone yesterday who had tried the radxa-zero-3w
build and it failed for them. When I do the builds on my machine that I've
been using for development, the build succeeds (because the repository
predates the assumed rebasing). If I then go to the ${DL_DIR}/git2/ directory
and delete the linux-next repository, then retry the build, it fails.

When I try the build on a machine that has never done this build, it fails.

I started my change yesterday by using the "tag=next-20240611" addition to the
fetcher and was surprised when the build failed on a different build machine.

I think AUTOREV is that safest bet here.

Re: [yocto-patches] [meta-rockchip][PATCH] linux-torvalds-next: use AUTOREV

[Quentin Schulz]

Hi Trevor,

On 6/18/24 2:08 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> On Tue 2024-06-18 @ 12:04:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
>> Hi Trevor,
>>
>> On 6/18/24 1:07 AM, Trevor Woerner via lists.yoctoproject.org wrote:
>>> Already the SRCREV that was used for -next has been rebased out of existence.
>>
>> Mmmm, no. It's still there, just not in the master branch.
>>
>>> Also that tag that was originally proposed no longer exists. With a repository
>>
>> It still exists. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=next-20240611
> 
> Yesterday at noon my time I cloned the linux-next repository on a machine I
> had never done this build on and that tag and commit ID were not there, and
> this is still true:
> 
> 	$ git tag

This lists your local tags only.

You want to use:

git ls-remote --tags 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

instead I believe.

I just did that AND a clone locally, and both show me the tag AND the 
commit exists.

This... is odd. Maybe worth contacting the IT of the Linux Foundation to 
figure out if there's some inconsistencies between mirrors used for load 
balancing or performance (closer to your place) somehow? Or something 
else, this doesn't smell good that stuff is "disappearing".

> 	...
> 	next-20230310
> 	next-20230314
> 	next-20230315
> 	next-20230316
> 	next-20230317
> 	next-20230829
> 	next-20240613
> 	v2.6.11
> 	v2.6.11-tree
> 	v2.6.12
> 	v2.6.12-rc2
> 	...
> 
> 	$ git show a957267fa7e9159d3d2ee1421359ebf228570c68
> 	fatal: bad object a957267fa7e9159d3d2ee1421359ebf228570c68
> 
> 	$ git pull
> 	...
> 
> 	$ git tag
> 	...
> 	next-20230829
> 	next-20240613
> 	next-20240617
> 	v2.6.11
> 	v2.6.11-tree
> 	v2.6.12
> 	v2.6.12-rc2
> 	...
> 
> 	$ git show a957267fa7e9159d3d2ee1421359ebf228570c68
> 	fatal: bad object a957267fa7e9159d3d2ee1421359ebf228570c68
> 
>>> that is rebased so regularly, the only thing we can safely use to hope for
>>> valid builds that don't need to be tweaked every few days is AUTOREV.
>>>
>>
>> Or... use ;tag=next-20240611 in the git fetcher and force people to use the
>> network for radxa-zero-e boards.
>>
>> I personally would vote for using the tag instead of AUTOREV. Kernel
>> maintainers rarely (have they ever done it?) move tags around so that should
>> be fine. Whereas using AUTOREV on linux-next is basically hoping that
>> nothing breaks from a development branch, maybe too much to ask for right
>> now?
> 
> When I click on the commit of the link you provided earlier it says: "Notice:
> this object is not reachable from any branch". If the tag is not accessible
> from any branch then I can't specify a branch to the fetcher. If I don't

I was under the impression that a branch may not be needed if a tag is 
passed, but that is probably incorrect. From the docs, it seems we would 
need to pass nobranch=1 in addition to ;tag. I'm not sure why this would 
be required though, the tag should be enough no?

> specify the branch to the fetcher then I get flooded with "...you didn't
> specify a branch, and we're going to make this mandatory soon..." messages,
> flooded!
> 

This may be a false positive if passing a tag without a branch to the 
git fetcher works.

> I also got an email from someone yesterday who had tried the radxa-zero-3w
> build and it failed for them. When I do the builds on my machine that I've
> been using for development, the build succeeds (because the repository
> predates the assumed rebasing). If I then go to the ${DL_DIR}/git2/ directory
> and delete the linux-next repository, then retry the build, it fails.
> 
> When I try the build on a machine that has never done this build, it fails.
> 
> I started my change yesterday by using the "tag=next-20240611" addition to the
> fetcher and was surprised when the build failed on a different build machine.
> 
> I think AUTOREV is that safest bet here.
> 

Up to you. I still think contacting the LF IT makes sense, at least so 
they know something odd's happening somewhere (maybe not on their side 
but still).

Cheers,
Quentin