All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: "Richard Purdie" <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org,
	Bruce Ashfield <bruce.ashfield@gmail.com>
Subject: Re: [OE-core] [PATCH] kernel.bbclass: hoist up "unset S" bbfatal from kernel-yocto.bbclass to kernel.bbclass
Date: Mon, 26 Jun 2023 15:32:05 +0200	[thread overview]
Message-ID: <20230626153205.42cd884f@booty> (raw)
In-Reply-To: <674d0a964611cc1e5451318976f17a4a24cbca5a.camel@linuxfoundation.org>

Hello Richard,

thanks for reviewing!

On Fri, 23 Jun 2023 12:07:43 +0100
"Richard Purdie" <richard.purdie@linuxfoundation.org> wrote:

> Hi Luca,
> 
> On Mon, 2023-06-05 at 16:13 +0200, Luca Ceresoli via lists.openembedded.org wrote:
> > From: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > 
> > Writing a simple recipe that inherits kernel.bbclass and downloads a kernel
> > tarball (e.g. a mainline release from kernel.org) via http or ftp fails
> > with either:
> > 
> >   ERROR: linux-acme-6.3.3-r0 do_configure: oe_runmake failed
> >   ...
> >   | make: *** No rule to make target 'oldnoconfig'.  Stop.
> > 
> > or (seen on a different setup, based on kirkstone):
> > 
> >   ... do_populate_lic: QA Issue: ... LIC_FILES_CHKSUM points to an invalid file: .../work-shared/.../kernel-source/COPYING [license-checksum]
> > 
> > This happens when not setting S in the recipe. In this case, kernel.bbclass
> > sets it to ${STAGING_KERNEL_DIR}
> > (${TMPDIR}/work-shared/${MACHINE}/kernel-source).  This means that in
> > do_symlink_kernsrc(), the 'if s != kernsrc' never triggers and thus the
> > kernel tree will not me moved into work/shared, which results in an empty
> > work-shared/.../kernel-source directory.
> > 
> > When downloading a tarball it is usually not required to set S in recipes,
> > so this is not obvious here and the error message does not point to the
> > problem or its solution.
> > 
> > There is such a check in kernel-yocto.bbclass though, so move it to
> > kernel.bbclass so that also kernel recipes not based on kernel-yocto can
> > benefit from it.
> > 
> > The check is moved:
> > 
> >  - from the beginning of do_kernel_checkout() in kernel-yocto
> >  - to the end of do_symlink_kernsrc() in kernel.bbclass
> > 
> > and since do_kernel_checkout is executed 'after do_symlink_kernsrc', the
> > code flow does not change in a relevant way when using linux-yocto.
> > 
> > Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > ---
> >  meta/classes-recipe/kernel-yocto.bbclass | 8 --------
> >  meta/classes-recipe/kernel.bbclass       | 6 ++++++
> >  2 files changed, 6 insertions(+), 8 deletions(-)
> > 
> > diff --git a/meta/classes-recipe/kernel-yocto.bbclass b/meta/classes-recipe/kernel-yocto.bbclass
> > index 108b7e675212..ceb451b69969 100644
> > --- a/meta/classes-recipe/kernel-yocto.bbclass
> > +++ b/meta/classes-recipe/kernel-yocto.bbclass
> > @@ -394,16 +394,8 @@ do_kernel_checkout() {
> >  		# case: we have no git repository at all. 
> >  		# To support low bandwidth options for building the kernel, we'll just 
> >  		# convert the tree to a git repo and let the rest of the process work unchanged
> > -		
> > -		# if ${S} hasn't been set to the proper subdirectory a default of "linux" is 
> > -		# used, but we can't initialize that empty directory. So check it and throw a
> > -		# clear error
> >  
> >  	        cd ${S}
> > -		if [ ! -f "Makefile" ]; then
> > -			bberror "S is not set to the linux source directory. Check "
> > -			bbfatal "the recipe and set S to the proper extracted subdirectory"
> > -		fi
> >  		rm -f .gitignore
> >  		git init
> >  		check_git_config
> > diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
> > index 9c8036f4df01..5ed4a2e03c72 100644
> > --- a/meta/classes-recipe/kernel.bbclass
> > +++ b/meta/classes-recipe/kernel.bbclass
> > @@ -195,6 +195,12 @@ python do_symlink_kernsrc () {
> >              import shutil
> >              shutil.move(s, kernsrc)
> >              os.symlink(kernsrc, s)
> > +
> > +    # When not using git, we cannot figure out automatically the extracted
> > +    # directory. So check it and throw a clear error.
> > +    if not os.path.isdir(os.path.join(d.getVar("WORKDIR"), "git")) and \
> > +       not os.path.exists(os.path.join(s, "Makefile")):
> > +        bb.fatal("S is not set to the linux source directory. Check the recipe and set S to the proper extracted subdirectory.")
> >  }
> >  # do_patch is normally ordered before do_configure, but
> >  # externalsrc.bbclass deletes do_patch, breaking the dependency of  
> 
> Sorry this has taken a bit of time to get to.

No problem.

> We can't check for "git" as the workdir directory in this test as it
> can be overridden in the fetcher. We'll need to find some other better
> approach. Can't we just use ${S}/Makefile ?

I'm not sure I got your point, however I agree. :-)

I'm not sure I got your point because in my patch I did try to mimick as
far as possible the same logic as the original code, which is:

        if [ -d "${WORKDIR}/git/" ]; then
                # case: git repository

		...
        else
                # case: we have no git repository at all. 

		...

		### This is the check I have moved to kernel.bbclass ###
                if [ ! -f "Makefile" ]; then
                        bberror "S is not set to the linux source directory. Check "
                        bbfatal "the recipe and set S to the proper extracted subdirectory"
                fi
		###

		...
	fi

So the bberror/bbfatal I moved is de facto inside a (if ! -d
${WORKDIR}/git && ! -f ${S}/Makefile) check, which is what I replicated
in kernel.bbclass.

On the other hand I agree that we could only check for ${S}/Makefile,
which is what I did in a draft version, and has the small side effect
of printing  the explanatory error message _also_ in the git case,
instead of a long-lined log concluded by "No rule to make target
'oldnoconfig'. Stop.".

So it looks like I'll be sending a v2 with simply the ${WORKDIR}/git
check removed.

> Please also copy Bruce on these changes going forward.

Sure, I will.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


      reply	other threads:[~2023-06-26 13:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05 14:13 [PATCH] kernel.bbclass: hoist up "unset S" bbfatal from kernel-yocto.bbclass to kernel.bbclass luca.ceresoli
2023-06-23 11:07 ` [OE-core] " Richard Purdie
2023-06-26 13:32   ` Luca Ceresoli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230626153205.42cd884f@booty \
    --to=luca.ceresoli@bootlin.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.