Re: [yocto] How to add a few lines in config.txt in Yocto project for Raspberry Pi

[Crane]

Finally find the correct way to do that.
Do "bitbake -c devshell " and then in the folder created use "git 
format-patch" to create the patch file.
This way, the patch can be applied.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60827): https://lists.yoctoproject.org/g/yocto/message/60827
Mute This Topic: https://lists.yoctoproject.org/mt/100614184/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Pick up ${PV} dynamically from environment or file or filename

[Darcy Watkins via lists.yoctoproject.org]

Hi,

I am not sure how well this would work for JARs (especially if they are large).

But you may be able to drop the as-built JARs into a git repo and commit them.

Then make use of the GIT AUTOREV facility to fetch from that GIT repo.

Each time you build after your GIT repo changes, will be built on the newer rev.

If your version info used to derive PV is in that GIT repo (rather than say 
date based) so that it stays the same after each rebuild of the same GIT rev 
(and only changes when the GIT rev is changed as part of new commits), you may 
still be able to satisfy the repeatable build (at least repeatable when rebuilt 
multiple times with your GIT repo at the same revision.

I would suggest that for releases where you may want to tag your Yocto GIT 
repo, you set the SRCREV to a specific revision so that a rebuild of the 
release is based on the exact same JARs.  (i.e. just use the autorev while 
doing development).

If this doesn’t work for GIT, you could always try with an alternate revision 
control system for which Yocto has autorev support.



Regards,

Darcy

Darcy Watkins ::  Senior Staff Engineer, Firmware

Semtech | Sierra Wireless
Office  +1 604 231 1100
13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
[M4]
dwatk...@sierrawireless.com :: 
www.semtech.com

From: yocto@lists.yoctoproject.org  on behalf of 
Konstantin Kletschke via lists.yoctoproject.org 

Date: Friday, August 18, 2023 at 1:33 PM
To: Alexander Kanavin 
Cc: yocto@lists.yoctoproject.org 
Subject: Re: [yocto] Pick up ${PV} dynamically from environment or file or 
filename
Caution: This email originated outside of Sierra Wireless.


On Fri, Aug 18, 2023 at 05:30:50PM +0200, Alexander Kanavin wrote:
> You probably need to explain the use case. Why do you want to do
> something like that?

The yocto build is happening in a gitlab runner thingy.

What happens before is that inedependently from the yocto build is that
my colleauges are running a maven build which provides java jar files.

And I do not know on my side what version they are doing. It could
happen even that it alternates between X.Y.Z and X.Y.Z-SNAPSHOT.

Then my yocto comes and is picking those jars up and integrates them into
the rootfs to be started there by java. They are not processed or
executed or compiled, they are copied into the rootfs, symlinkd and
integrated into a systemd start.

Colleauges maven build: Their git tree.
Yocto build: My git tree.

> Generally, Yocto cares about build reproducibility, a lot. Thus,
> source must be stable, and verified against a checksum of some kind.

I learned to love its build reliability because of such stuff too.

Konsti

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60826): https://lists.yoctoproject.org/g/yocto/message/60826
Mute This Topic: https://lists.yoctoproject.org/mt/100819403/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Pick up ${PV} dynamically from environment or file or filename

[Konstantin Kletschke via lists.yoctoproject.org]

On Fri, Aug 18, 2023 at 05:30:50PM +0200, Alexander Kanavin wrote:
> You probably need to explain the use case. Why do you want to do
> something like that?

The yocto build is happening in a gitlab runner thingy.

What happens before is that inedependently from the yocto build is that
my colleauges are running a maven build which provides java jar files.

And I do not know on my side what version they are doing. It could
happen even that it alternates between X.Y.Z and X.Y.Z-SNAPSHOT.

Then my yocto comes and is picking those jars up and integrates them into
the rootfs to be started there by java. They are not processed or
executed or compiled, they are copied into the rootfs, symlinkd and
integrated into a systemd start.

Colleauges maven build: Their git tree.
Yocto build: My git tree.

> Generally, Yocto cares about build reproducibility, a lot. Thus,
> source must be stable, and verified against a checksum of some kind.

I learned to love its build reliability because of such stuff too.

Konsti

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60825): https://lists.yoctoproject.org/g/yocto/message/60825
Mute This Topic: https://lists.yoctoproject.org/mt/100819403/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Pick up ${PV} dynamically from environment or file or filename

[Alexander Kanavin]

You probably need to explain the use case. Why do you want to do
something like that?

Generally, Yocto cares about build reproducibility, a lot. Thus,
source must be stable, and verified against a checksum of some kind.

Alex

On Fri, 18 Aug 2023 at 14:41, Konstantin Kletschke via
lists.yoctoproject.org
 wrote:
>
>
> Dear community,
> I need to build a recipe which does not now, which actual version the
> source file(s) has.
>
> So is it possible, to pick up a version preliminary from either
> environment, the content of an existing auxiliary file or from the
> structure of the source file itself?
>
> Say, if theres is something like bla-1.23.jar I could look vor a jar
> beginning with bla, suffix .jar and construct 1.23 as ${PV} to use in
> the SRC_URI. Also possible is to provide a file with version info to be
> read or prepare the ENV.
>
> Kind Regards
> Konstantin
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60824): https://lists.yoctoproject.org/g/yocto/message/60824
Mute This Topic: https://lists.yoctoproject.org/mt/100819403/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Pick up ${PV} dynamically from environment or file or filename

[Konstantin Kletschke via lists.yoctoproject.org]

Dear community,
I need to build a recipe which does not now, which actual version the
source file(s) has.

So is it possible, to pick up a version preliminary from either
environment, the content of an existing auxiliary file or from the
structure of the source file itself?

Say, if theres is something like bla-1.23.jar I could look vor a jar
beginning with bla, suffix .jar and construct 1.23 as ${PV} to use in
the SRC_URI. Also possible is to provide a file with version info to be
read or prepare the ENV.

Kind Regards
Konstantin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60823): https://lists.yoctoproject.org/g/yocto/message/60823
Mute This Topic: https://lists.yoctoproject.org/mt/100819403/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [PATCH] kernel/sched: Fix double free on invalid isolcpus/nohz_full params

[Paul Gortmaker via lists.yoctoproject.org]

[[linux-yocto] [PATCH] kernel/sched: Fix double free on invalid 
isolcpus/nohz_full params] On 17/08/2023 (Thu 10:56) Adrian Cinal via 
lists.yoctoproject.org wrote:

> A previous patch left behind a redundant call to free_bootmem_cpumask_var
> possibly leading to a double free (once in the if-branch and once in the
> unwind code at the end of the function) if the isolcpus= or nohz_full=
> kernel command line parameters failed validation, cf.:
> 
> https://lists.yoctoproject.org/g/linux-yocto/message/12797

Once again, I wanted to know exactly how we got here. So here is how.

The key to this issue is this commit from v5.18:

commit 0cd3e59de1f53978873669c7c8225ec13e88c3ae
Author: Frederic Weisbecker 
Date:   Mon Feb 7 16:59:08 2022 +0100

sched/isolation: Consolidate error handling

Centralize the mask freeing and return value for the error path. This
makes potential leaks more visible.

Simple and common enough; it contains multiple instances of:

-   free_bootmem_cpumask_var(non_housekeeping_mask);
-   return 0;
+   goto free_non_housekeeping_mask;

But from a kernel version persepective, it means we have an "old style" free
and the "new style" free.

The patch sent to lkml was for post 5.18 kernels, and used the new style,
and was even documented as such in the 0/N (see asteriks):

 -
This is a rebase and retest of two fixes I'd sent earlier[1].

The rebase is required due to conflicts in my patch #1 and where Frederic
updated the unwind code in housekeeping_setup in his series[2] and that series
is now in sched/core of tip[3].

So this update is against a baseline of ed3b362d54f0 found in sched/core as
"sched/isolation: Split housekeeping cpumask per isolation features" in tip.

   **
Changes amount to "return 0" ---> "goto out_free" and adding a nod to PaulM's
observation that nohz_full w/o a cpuset is coming someday into the commit log.
   **

[1] 
https://lore.kernel.org/all/20211206145950.10927-1-paul.gortma...@windriver.com/
[2] https://lore.kernel.org/all/20220207155910.527133-1-frede...@kernel.org/
[3] git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
 -

https://lore.kernel.org/lkml/20220221182009.1283-1-paul.gortma...@windriver.com/

Similarly, the submission for yocto for the v5.15 kernel (which was current
at the time) used the old style and everything was fine.

When yocto moved to v6.1, the uprev generally carries forward commits that
have not been merged to mainline or declared obsolete.

So the v5.15 old style commit was carried forward to v6.1, resulting in a
mix of old and new style free.  Not ideal, but still functionally correct.

The double free risk comes from your change which deleted the "return 0"
underneath the old free:

https://lists.yoctoproject.org/g/linux-yocto/topic/99772129

It shouldn't have done that, and I missed it in review.

Bruce: the executive summary is that this delta fix is correct, and should
be placed on the 6.1/6.4 branches that got the previous commit from Adrian.

The yocto-kernel-cache can and should ignore all this churn, and simply
contain the post v5.18 "new style" version of the commit sent to lkml:

https://lore.kernel.org/lkml/20220221182009.1283-2-paul.gortma...@windriver.com/

Thanks,
Paul.




> 
> Signed-off-by: Adrian Cinal 
> ---
>  kernel/sched/isolation.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> index b97d6e05013d..7bebfdc42486 100644
> --- a/kernel/sched/isolation.c
> +++ b/kernel/sched/isolation.c
> @@ -133,7 +133,6 @@ static int __init housekeeping_setup(char *str, unsigned 
> long flags)
>  
>   if (cpumask_empty(non_housekeeping_mask)) {
>   pr_info("housekeeping: kernel parameter 'nohz_full=' or 
> 'isolcpus=' has no valid CPUs.\n");
> - free_bootmem_cpumask_var(non_housekeeping_mask);
>   goto free_non_housekeeping_mask;
>   }
>  
> -- 
> 2.41.0
> 

> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12998): 
https://lists.yoctoproject.org/g/linux-yocto/message/12998
Mute This Topic: https://lists.yoctoproject.org/mt/100796885/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target is intended for a different architecture

[David Daniel]

Hi there

I am new to Yocto and I am still struggling to build the SDK - I am on
the master branch, after I had different problems with missing
dependencies and configure failures in mickledore I went to master.
Here I can successfully build core-image-full-cmdline without problems.
Everything is fine. Now when it comes the populate_sdk I always get the
following error:


package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target is intended 
for a different architecture

It says that the architecture for the target-sdk-provides-dummy is 
«sdk_provides_dummy_target»:

 PackageArchitecture   Version 
Repo  Size  
[20/8686]
=
Installing:
 nativesdk-cmakex86_64_nativesdk   3.26.4-r0   
oe-repo   10 M
Installing dependencies:
 nativesdk-libarchive   x86_64_nativesdk   3.6.2-r0
oe-repo  312 k
 nativesdk-libc6x86_64_nativesdk   2.38-r0 
oe-repo  1.4 M
 nativesdk-libcrypto3   x86_64_nativesdk   3.1.2-r0
oe-repo  1.5 M
 nativesdk-libcurl4 x86_64_nativesdk   8.2.1-r0
oe-repo  221 k
 nativesdk-libexpat1x86_64_nativesdk   2.5.0-r0
oe-repo   67 k
 nativesdk-libgcc1  x86_64_nativesdk   13.2.0-r0   
oe-repo   66 k
 nativesdk-liblzma5 x86_64_nativesdk   5.4.3-r0
oe-repo   96 k
 nativesdk-libssl3  x86_64_nativesdk   3.1.2-r0
oe-repo  237 k
 nativesdk-libstdc++6   x86_64_nativesdk   13.2.0-r0   
oe-repo  687 k
 nativesdk-libz1x86_64_nativesdk   1.2.13-r0   
oe-repo   55 k
 nativesdk-libzstd1 x86_64_nativesdk   1.5.5-r0
oe-repo  296 k
 nativesdk-openssl  x86_64_nativesdk   3.1.2-r0
oe-repo  8.7 k
 nativesdk-openssl-bin  x86_64_nativesdk   3.1.2-r0
oe-repo  330 k
 nativesdk-openssl-conf x86_64_nativesdk   3.1.2-r0
oe-repo   12 k
 target-sdk-provides-dummy  sdk_provides_dummy_target  1.0-r0  
oe-repo  9.0 k
Installing weak dependencies:
 nativesdk-ca-certificates  x86_64_nativesdk   20211016-r0 
oe-repo  175 k
 nativesdk-ldconfig x86_64_nativesdk   2.38-r0 
oe-repo  379 k
 nativesdk-openssl-ossl-module-legacy   x86_64_nativesdk   3.1.2-r0
oe-repo   42 k


What am I doing wrong, what am I missing here? Is this a bug?


Sincerely
David

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60822): https://lists.yoctoproject.org/g/yocto/message/60822
Mute This Topic: https://lists.yoctoproject.org/mt/100818290/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-