<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/poky.git/meta/classes-recipe/kernel.bbclass, branch 5.0_M2</title>
<subtitle>Mirror of git.yoctoproject.org/poky</subtitle>
<id>https://git.enea.com/cgit/linux/poky.git/atom?h=5.0_M2</id>
<link rel='self' href='https://git.enea.com/cgit/linux/poky.git/atom?h=5.0_M2'/>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/'/>
<updated>2024-01-18T10:15:58+00:00</updated>
<entry>
<title>classes/recipes: Switch to use inherit_defer</title>
<updated>2024-01-18T10:15:58+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2023-12-31T13:27:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=c917323a39da6fc3e8d92b2fe907d0357149c9bb'/>
<id>urn:sha1:c917323a39da6fc3e8d92b2fe907d0357149c9bb</id>
<content type='text'>
Now that bitbake supports the use of inherit_defer, switch all conditional
(variable based) inherits to use this instead. This leads to more a more
deterministic user experience since there is no longer an immediate expansion
and later changes to the variables in question (e.g. a bbappend) are
accounted for.

This patch tries to ensure the behaviour before/after remains as unchanged
as it reasonably can, e.g. by always inherting populate_sdk_base. native
and nativesdk continue to need to be inherited last, hence being used
with inherit_defer in a handful of very specific cases.

(From OE-Core rev: 451363438d38bd4552d5bcec4a92332f5819a5d4)

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel.bbclass: add preceding space in appendVar setting</title>
<updated>2023-10-30T17:12:19+00:00</updated>
<author>
<name>Chen Qi</name>
<email>Qi.Chen@windriver.com</email>
</author>
<published>2023-10-30T06:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=57e3f6ff2846e0f253c5e5c7117fde09a31c6013'/>
<id>urn:sha1:57e3f6ff2846e0f253c5e5c7117fde09a31c6013</id>
<content type='text'>
The appendVar setting should have a preceding space, otherwise, when
KERNEL_MODULE_SPLIT is set to "0", we'll sometimes get dependency error
due to lacking of space.

(From OE-Core rev: 266cd948d4aa68de34075e8ed6299f7d80d19346)

Signed-off-by: Chen Qi &lt;Qi.Chen@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel.bbclass: Use strip utility used for kernel build in do_package</title>
<updated>2023-10-27T07:28:38+00:00</updated>
<author>
<name>Khem Raj</name>
<email>raj.khem@gmail.com</email>
</author>
<published>2023-10-24T22:07:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=aedce97caadf94346e8179633b40528b0144a8a9'/>
<id>urn:sha1:aedce97caadf94346e8179633b40528b0144a8a9</id>
<content type='text'>
os.environ does not pass this down to runstrip() function and in
strip_execs() its using STRIP bitbake variable to find the strip utility
to use. Since there might be a trailing whitespace in KERNEL_STRIP
remove that otherwise python is not able to launch it.
e.g.

FileNotFoundError: [Errno 2] No such file or directory: 'riscv64-yoe-linux-strip '

This is more evident when STRIP and KERNEL_STRIP are different utilities
e.g. when using clang as default toolchain but using gcc+binutils only for
kernel build.

(From OE-Core rev: 77497dbdca92ab4d6386a071bc281c42a7e8a14b)

Signed-off-by: Khem Raj &lt;raj.khem@gmail.com&gt;
Cc: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
Signed-off-by: Luca Ceresoli &lt;luca.ceresoli@bootlin.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel.bbclass: Add force flag to rm calls</title>
<updated>2023-09-02T10:47:50+00:00</updated>
<author>
<name>Ryan Eatmon</name>
<email>reatmon@ti.com</email>
</author>
<published>2023-08-31T19:26:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=81af7cd4065acf092b9b9d10f52f1895025d85bb'/>
<id>urn:sha1:81af7cd4065acf092b9b9d10f52f1895025d85bb</id>
<content type='text'>
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it.  Simple fix is to add the
-f (force) flag to the call.

(From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc)

Signed-off-by: Ryan Eatmon &lt;reatmon@ti.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel.bbclass: Use KERNEL_STRIP instead of STRIP</title>
<updated>2023-08-16T06:54:38+00:00</updated>
<author>
<name>Khem Raj</name>
<email>raj.khem@gmail.com</email>
</author>
<published>2023-08-14T02:25:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=64789f18f3cd983e8ce451c24e9709bab41bafa0'/>
<id>urn:sha1:64789f18f3cd983e8ce451c24e9709bab41bafa0</id>
<content type='text'>
Kernel uses its own variables KERNEL_* instead of general toolchain env
variables, therefore use KERNEL_STRIP here explicitly, Problems happen
when using llvm-strip as default STRIP in distro settings, since kernel
defaults to using gcc, system does not stage llvm/clang toolchain into
kernel's staging sysroot and this function ends up with

FileNotFoundError: [Errno 2] No such file or directory: 'riscv64-yoe-linux-llvm-strip'

(From OE-Core rev: 2db0ef8fe6381c893791ad645748f6e7c8134e5f)

Signed-off-by: Khem Raj &lt;raj.khem@gmail.com&gt;
Cc: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel: don't fail if Modules.symvers doesn't exist</title>
<updated>2023-08-10T08:18:54+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2023-08-04T17:06:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=b40619a5b3a2efd2d540b0101e47781a643a0b7a'/>
<id>urn:sha1:b40619a5b3a2efd2d540b0101e47781a643a0b7a</id>
<content type='text'>
Kernels that do not use modules do not have the Modules.symvers file,
which causes the previous one-liner to fail.  Invert the logic so that
the absence of the Modules.symvers is a passing situation but we still
get failure checking on the install operation.

(From OE-Core rev: 856c916ffbf3438d8cf5d8bed344473bde03b56e)

Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Patrick Williams &lt;patrick@stwcx.xyz&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel: make LOCALVERSION consistent between recipes</title>
<updated>2023-07-25T14:27:33+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2023-07-22T02:31:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=88ae1b73c09c4a1b2563f61fcddd15b5ae9fedca'/>
<id>urn:sha1:88ae1b73c09c4a1b2563f61fcddd15b5ae9fedca</id>
<content type='text'>
The initial fix for localversion setting in 6.3+ broke older
recipes and also broke recipes setting localversion in a kernel
recipe, as make-mod-scripts (and other locations) can trigger
a regeneration of files and don't have access to the variable.

Moving the setting of this variable to the global namespace
doesn't make sense, so we follow the example of the kernel-abiversion
and save a kernel-localversion to the build artifacts.

Recipes that may regenerate scripts/dynamic files, must
depend on the do_shared_workedir of the kernel and use the helper
function to read the file storing the localversion.

(From OE-Core rev: b378eec156998eea55ba61e59103cb34fab0d07c)

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel: Fix path comparison in kernel staging dir symlinking</title>
<updated>2023-07-21T10:52:26+00:00</updated>
<author>
<name>Staffan Rydén</name>
<email>staffan.ryden@axis.com</email>
</author>
<published>2023-07-20T11:02:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=3ebef7a7195c7fd62c6b38be6dda24e548ef034b'/>
<id>urn:sha1:3ebef7a7195c7fd62c6b38be6dda24e548ef034b</id>
<content type='text'>
Due to an oversight in the do_symlink_kernsrc function, the path
comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code
obtains both variables, but modifies the local copy of "S" before
comparing them, causing the comparison to always return false.

This can cause the build to fail when the EXTERNALSRC flag is enabled,
since the code will try to create a symlink even if one already exists.

This patch resolves the issue by comparing the variables before they are
modified.

(From OE-Core rev: afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3)

Signed-off-by: Staffan Rydén &lt;staffan.ryden@axis.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel: set HOSTPKG_CONFIG to use pkg-config-native</title>
<updated>2023-07-21T10:52:26+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2023-07-18T03:34:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=74b670cf0bbd0e9a5a862f34586917f95b84ae01'/>
<id>urn:sha1:74b670cf0bbd0e9a5a862f34586917f95b84ae01</id>
<content type='text'>
The 5.19 kernel introduced a variable to specify the pkg-config
command to use for host tools.

Previously to this being introduced, we needed to overrride the
standard PKG_CONFIG* variables to avoid calls to pkg-config using
the target configuration.

While we can't completely drop the PKG_CONFIG workaround, we
should introduce the new variable, and prepare to only use it
once all supported kernels are 5.19+

(From OE-Core rev: d4b5ea28078cbbf417d95e1b77c6b8c3e9f9e4c0)

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernel: fix localversion in v6.3+</title>
<updated>2023-07-12T15:50:45+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2023-07-05T14:44:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=bb0f9e87700aa40ec8db880ede3c018c1d055786'/>
<id>urn:sha1:bb0f9e87700aa40ec8db880ede3c018c1d055786</id>
<content type='text'>
During testing of the v6.4 reference kernel, it was noticed that
on-target modules no longer matched the magic value of the running
kernel.

This was due to a different localversion in the cross built kernel
and the scripts / resources created on target.

This was due to changes in the setlocalversion script introduced
in the v6.3 series.

The .scmversion file is no longer used (or packaged) to inhibit
the addition of a "+" (through querying of the git status of the
kernel) or the setting of a local version.

We recently introduced the KERNEL_LOCALVERSION variable to allow
recipes to place a value in .scmversion, so we extend the use of
that variable to kernel-arch.bbclass and use it to set the
exported variable LOCALVERSION.

We must do it at the kernel-arch level, as the variable must be
exported in any kernel build to ensure that setlocalversion always
correctly sets the localversion.

(From OE-Core rev: 765b13b7305c8d2f222cfc66d77c02e6a088c691)

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
</feed>
