[yocto] [meta-zephyr][PATCH] layer.conf: update LAYERSERIES_COMPAT to use nanbield

[Naveen Saini]

Drop langdale and mickledore.

Signed-off-by: Naveen Saini 
---
 meta-zephyr-bsp/conf/layer.conf  | 2 +-
 meta-zephyr-core/conf/layer.conf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-zephyr-bsp/conf/layer.conf b/meta-zephyr-bsp/conf/layer.conf
index d809926..1edcb0b 100644
--- a/meta-zephyr-bsp/conf/layer.conf
+++ b/meta-zephyr-bsp/conf/layer.conf
@@ -15,4 +15,4 @@ LAYERVERSION_zephyrbsp = "1"
 
 LAYERDEPENDS_zephyrbsp = "zephyrcore core meta-python"
 
-LAYERSERIES_COMPAT_zephyrbsp = "kirkstone langdale mickledore"
+LAYERSERIES_COMPAT_zephyrbsp = "kirkstone nanbield"
diff --git a/meta-zephyr-core/conf/layer.conf b/meta-zephyr-core/conf/layer.conf
index fdff4f6..06e942e 100644
--- a/meta-zephyr-core/conf/layer.conf
+++ b/meta-zephyr-core/conf/layer.conf
@@ -15,7 +15,7 @@ LAYERVERSION_zephyrcore = "1"
 
 LAYERDEPENDS_zephyrcore = "core meta-python"
 
-LAYERSERIES_COMPAT_zephyrcore = "kirkstone langdale mickledore"
+LAYERSERIES_COMPAT_zephyrcore = "kirkstone nanbield"
 
 PYTHON3_NATIVE_SITEPACKAGES_DIR = 
"${libdir_native}/${PYTHON3_DIR}/site-packages"
 
-- 
2.34.1


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

[yocto] M+ & H bugs with Milestone Movements WW36

[Stephen Jolley]

All,

YP M+ or high bugs which moved to a new milestone in WW36 are listed below:
Priority Bug ID Short Description Changer Owner Was Became
High 14901  lttng:
collect TAP output randy.macl...@windriver.com alexis.loth...@bootlin.com 4.3
M4 5.0 M1
Medium+ 15205  Need
to cleanup work directories for cancelled builds
richard.pur...@linuxfoundation.org unassig...@yoctoproject.org 0.0.0 4.3 M4
15206  qemumips
BUG using smp_processor_id() in preemptible randy.macl...@windriver.com
unassig...@yoctoproject.org 0.0.0 4.3 M4

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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

[yocto] Enhancements/Bugs closed WW36!

[Stephen Jolley]

All,

The below were the owners of enhancements or bugs closed during the last
week!
Who Count
ross.bur...@arm.com 1
richard.pur...@linuxfoundation.org 1
randy.macl...@windriver.com 1
Grand Total 3

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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

[yocto] Current high bug count owners for Yocto Project 4.3

[Stephen Jolley]

All,

Below is the list of top 28 bug owners as of the end of WW36 who have open
medium or higher bugs and enhancements against YP 4.3. There are 33
possible work days left until the final release candidates for YP 4.3 needs
to be released.
Who Count
michael.opdenac...@bootlin.com 34
ross.bur...@arm.com 33
richard.pur...@linuxfoundation.org 25
randy.macl...@windriver.com 23
david.re...@windriver.com 23
bruce.ashfi...@gmail.com 22
jpewhac...@gmail.com 11
pi...@pidge.org 7
pa...@zhukoff.net 6
sakib.sa...@windriver.com 5
yash.shi...@windriver.com 4
tim.orl...@konsulko.com 3
sundeep.kokko...@windriver.com 2
jon.ma...@arm.com 2
alexis.loth...@bootlin.com 2
alexandre.bell...@bootlin.com 2
yoann.con...@smile.fr 1
tvgamb...@gmail.com 1
thr...@amazon.de 1
thomas.per...@bootlin.com 1
pokyli...@reliableembeddedsystems.com 1
p.lob...@welotec.com 1
martin.ja...@gmail.com 1
mark.asselst...@windriver.com 1
louis.ran...@syslinbit.com 1
jens.ge...@desy.de 1
fathi.bou...@linaro.org 1
alejan...@enedino.org 1
Grand Total 216

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:
https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project. If anyone can help,
please take ownership of the bug and send patches! If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 420
unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help
out with these. Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system. There are also roughly four different "priority"
classes right now, “4.3”, “4.4”, "4.99" and "Future", the more
pressing/urgent issues being in "4.3" and then “4.4”.

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account). The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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

Re: [yocto] [meta-virtualization] nerdctl broken in kirkstone

[Bruce Ashfield]

On Mon, Sep 11, 2023 at 3:50 PM Marek Belisko  wrote:
>
> On Mon, Sep 11, 2023 at 9:27 PM Marek Belisko via lists.yoctoproject.org 
>  wrote:
>>
>> On Mon, Aug 28, 2023 at 10:38 PM Belisko Marek  
>> wrote:
>>>
>>> On Thu, Aug 24, 2023 at 4:05 PM Khem Raj  wrote:

 does it work if you add do_compile[network] = "1"
>>>
>>> Nope it is not. It turns out that the fetch phase is not correct. When I do 
>>> bitbake nerdctl -e | grep SRC_URI I got only:
>>>
>>>  
>>> SRC_URI="git://github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https"
>>>
>>> and not other SRC_URI's added in src_uri.inc file. It's mystery to me why 
>>> this include is not working
>>
>> Khem any idea what can be the cause of this issue please? I've tried yq 
>> recipe which using more less the same approach and there SRC_URI's are 
>> printed properly.
>
> OK please disregard this message. I find out I have a nerdctl bbappend which 
> overwrites SRC_URI permanently. BTW on kirkstone nerdctl is broken due wrong 
> branch name + wrong SRCREV. Should I post a patch?

You do realize that you are using the wrong mailing list for this thread ?

We have newer/working updated nerdctl recipes in newer branches of meta-virt.

The upstream repos have just (unfortunately) changed some of their
revs, so the ones captured and tested on release have gone out of
date.

Bruce




 On Wed, Aug 23, 2023 at 11:14 PM Belisko Marek  
 wrote:
 >
 >
 >
 > Sent from my iPhone
 >
 > > On 24 Aug 2023, at 02:23, Khem Raj  wrote:
 > >
 > > which task is failing ?
 > do_compile
 > >
 > >> On Wed, Aug 23, 2023 at 2:31 PM Marek Belisko 
 > >>  wrote:
 > >>
 > >> Hi,
 > >>
 > >> I'm trying to add nerdctl to an image using kirkstone release for 
 > >> meta-virtualization.
 > >> I've added bbappend with following fix:
 > >>
 > >> SRC_URI = 
 > >> "git://github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https"
 > >>
 > >> (branch name in original recipe is master but main is required)
 > >>
 > >> but then anyways it fails with:
 > >>
 > >> rsync: [sender] change_dir 
 > >> "/data/projects/test/build/tmp/work/cortexa53-crypto-poky-linux/nerdctl/v0.18.0-r0/nerdctl-v0.18.0/src/import/vendor.fetch/github.com/Masterminds/semver/v3"
 > >>  failed: No such file or directory (2)
 > >> | rsync error: some files/attrs were not transferred (see previous 
 > >> errors) (code 23) at main.c(1327) [sender=3.2.5]
 > >>
 > >> And in ${BP} I cannot see any of those vendor stuff which should be 
 > >> present. Is there some fix for that already pending or it's known 
 > >> issue?
 > >>
 > >> Thanks and BR,
 > >>
 > >> marek
 > >>
 > >> --
 > >> as simple and primitive as possible
 > >> -
 > >> Marek Belisko - OPEN-NANDRA
 > >> Freelance Developer
 > >>
 > >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
 > >> Tel: +421 915 052 184
 > >> skype: marekwhite
 > >> twitter: #opennandra
 > >> web: http://open-nandra.com
 > >>
 > >>
 > >>
>>>
>>>
>>>
>> Thanks,
>>
>> marek
>> --
>> as simple and primitive as possible
>> -
>> Marek Belisko - OPEN-NANDRA
>> Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> Tel: +421 915 052 184
>> skype: marekwhite
>> twitter: #opennandra
>> web: http://open-nandra.com
>>
>>
>>
>
> Thanks,
>
> marek
>
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

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

Re: [yocto] [meta-virtualization] nerdctl broken in kirkstone

[Marek Belisko]

On Mon, Sep 11, 2023 at 9:27 PM Marek Belisko via lists.yoctoproject.org
 wrote:

> On Mon, Aug 28, 2023 at 10:38 PM Belisko Marek 
> wrote:
>
>> On Thu, Aug 24, 2023 at 4:05 PM Khem Raj  wrote:
>>
>>> does it work if you add do_compile[network] = "1"
>>>
>> Nope it is not. It turns out that the fetch phase is not correct. When I
>> do bitbake nerdctl -e | grep SRC_URI I got only:
>>
>>  SRC_URI="git://
>> github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https
>> "
>>
>> and not other SRC_URI's added in src_uri.inc file. It's mystery to me why
>> this include is not working
>>
> Khem any idea what can be the cause of this issue please? I've tried yq
> recipe which using more less the same approach and there SRC_URI's are
> printed properly.
>
OK please disregard this message. I find out I have a nerdctl bbappend
which overwrites SRC_URI permanently. BTW on kirkstone nerdctl is broken
due wrong branch name + wrong SRCREV. Should I post a patch?

>
>>> On Wed, Aug 23, 2023 at 11:14 PM Belisko Marek 
>>> wrote:
>>> >
>>> >
>>> >
>>> > Sent from my iPhone
>>> >
>>> > > On 24 Aug 2023, at 02:23, Khem Raj  wrote:
>>> > >
>>> > > which task is failing ?
>>> > do_compile
>>> > >
>>> > >> On Wed, Aug 23, 2023 at 2:31 PM Marek Belisko <
>>> marek.beli...@gmail.com> wrote:
>>> > >>
>>> > >> Hi,
>>> > >>
>>> > >> I'm trying to add nerdctl to an image using kirkstone release for
>>> meta-virtualization.
>>> > >> I've added bbappend with following fix:
>>> > >>
>>> > >> SRC_URI = "git://
>>> github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https
>>> "
>>> > >>
>>> > >> (branch name in original recipe is master but main is required)
>>> > >>
>>> > >> but then anyways it fails with:
>>> > >>
>>> > >> rsync: [sender] change_dir
>>> "/data/projects/test/build/tmp/work/cortexa53-crypto-poky-linux/nerdctl/v0.18.0-r0/nerdctl-v0.18.0/src/import/vendor.fetch/
>>> github.com/Masterminds/semver/v3" failed: No such file or directory (2)
>>> > >> | rsync error: some files/attrs were not transferred (see previous
>>> errors) (code 23) at main.c(1327) [sender=3.2.5]
>>> > >>
>>> > >> And in ${BP} I cannot see any of those vendor stuff which should be
>>> present. Is there some fix for that already pending or it's known issue?
>>> > >>
>>> > >> Thanks and BR,
>>> > >>
>>> > >> marek
>>> > >>
>>> > >> --
>>> > >> as simple and primitive as possible
>>> > >> -
>>> > >> Marek Belisko - OPEN-NANDRA
>>> > >> Freelance Developer
>>> > >>
>>> > >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>>> > >> Tel: +421 915 052 184
>>> > >> skype: marekwhite
>>> > >> twitter: #opennandra
>>> > >> web: http://open-nandra.com
>>> > >>
>>> > >>
>>> > >>
>>>
>>
>>
>> Thanks,
>
> marek
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
>
> 
>
>
Thanks,

marek

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

Re: [yocto] [meta-virtualization] nerdctl broken in kirkstone

[Marek Belisko]

On Mon, Aug 28, 2023 at 10:38 PM Belisko Marek 
wrote:

> On Thu, Aug 24, 2023 at 4:05 PM Khem Raj  wrote:
>
>> does it work if you add do_compile[network] = "1"
>>
> Nope it is not. It turns out that the fetch phase is not correct. When I
> do bitbake nerdctl -e | grep SRC_URI I got only:
>
>  SRC_URI="git://
> github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https"
>
> and not other SRC_URI's added in src_uri.inc file. It's mystery to me why
> this include is not working
>
Khem any idea what can be the cause of this issue please? I've tried yq
recipe which using more less the same approach and there SRC_URI's are
printed properly.

>
>> On Wed, Aug 23, 2023 at 11:14 PM Belisko Marek 
>> wrote:
>> >
>> >
>> >
>> > Sent from my iPhone
>> >
>> > > On 24 Aug 2023, at 02:23, Khem Raj  wrote:
>> > >
>> > > which task is failing ?
>> > do_compile
>> > >
>> > >> On Wed, Aug 23, 2023 at 2:31 PM Marek Belisko <
>> marek.beli...@gmail.com> wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> I'm trying to add nerdctl to an image using kirkstone release for
>> meta-virtualization.
>> > >> I've added bbappend with following fix:
>> > >>
>> > >> SRC_URI = "git://
>> github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https
>> "
>> > >>
>> > >> (branch name in original recipe is master but main is required)
>> > >>
>> > >> but then anyways it fails with:
>> > >>
>> > >> rsync: [sender] change_dir
>> "/data/projects/test/build/tmp/work/cortexa53-crypto-poky-linux/nerdctl/v0.18.0-r0/nerdctl-v0.18.0/src/import/vendor.fetch/
>> github.com/Masterminds/semver/v3" failed: No such file or directory (2)
>> > >> | rsync error: some files/attrs were not transferred (see previous
>> errors) (code 23) at main.c(1327) [sender=3.2.5]
>> > >>
>> > >> And in ${BP} I cannot see any of those vendor stuff which should be
>> present. Is there some fix for that already pending or it's known issue?
>> > >>
>> > >> Thanks and BR,
>> > >>
>> > >> marek
>> > >>
>> > >> --
>> > >> as simple and primitive as possible
>> > >> -
>> > >> Marek Belisko - OPEN-NANDRA
>> > >> Freelance Developer
>> > >>
>> > >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> > >> Tel: +421 915 052 184
>> > >> skype: marekwhite
>> > >> twitter: #opennandra
>> > >> web: http://open-nandra.com
>> > >>
>> > >> 
>> > >>
>>
>
>
> Thanks,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

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

[yocto] kernel panic error after enabling dm-verity.

[lakshaypiplani77]

I have two yocto recipes.

base image and advanced image.

base image have support for dm-verity. i just have to include one line in 
local.conf to enable dm-verity with initramfs support.

*DISTRO_FEATURES_append += "dm-verity" (creating wic image only)*

*
* and image gets loaded successfully as follows.

[    1.366192] Run /init as init process

Starting version 246

realpath: /dev/disk/by-partuuid//dev: No such file or directory

[    2.971331] random: veritysetup: uninitialized urandom read (2 bytes read)

[    2.973479] device-mapper: verity: sha256 using implementation 
"sha256-generic"

[    3.106633] EXT4-fs (dm-0): mounting ext3 file system using the ext4 
subsystem

[    3.113899] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: disabled.

[    3.449425] systemd[1]: System time before build time, advancing clock.

[    3.481321] systemd[1]: systemd 246 running in system mode. (+PAM -AUDIT 
-SELINUX +IMA -APPARMOR -SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS 
+ACL +XZ -LZ4 -ZSTD -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN -PCRE2 
default-hierarchy=hybrid)

[    3.481828] systemd[1]: Detected architecture arm64.

But when i am trying to replicate it for advanced image, i am getting kernel 
panic error as follows.

Starting version 246

realpath: /dev/disk/by-partuuid//dev: No such file or directory

Device /dev/mmcblk0p2 is not a valid VERITY device.

mount: /rootfs: special device /dev/mapper/rootfs[    2.935967] Kernel panic - 
not syncing:

[    2.935983] Attempted to kill init! exitcode=0x0200

does not exist.

[    3.043274] SMP: stopping secondary CPUs

[    3.046769] Kernel Offset: disabled

[    3.050233] CPU features: 0x90002001,2842

[    3.054573] Memory Limit: none

[    3.057616] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0200 ]---

What could be the issue??

*How to resolve it?*

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

Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work

[Alexander Kanavin]

On Mon, 11 Sept 2023 at 10:13, ChenQi  wrote:
> This is the case I referred to as 'different builds owned/controlled by
> the same user'.

'User' is ambiguous here - user as a person, or user as a local unix
user account?
In the latter case this is likely to be misunderstood as 'sstate cache
must be private to a user account because it cannot handle multiple
readers and writers eithe locally or over the network', which it can.

> Say, you share the SSTATE_DIR used by Yocto CI to many people via NFS.
> Then, a 'rm -rf' might be typed by someone by accident, maybe just
> because of lack of coffee.

This is correct. Deletion needs to happen via central procedure, and
those who cannot be trusted with that should get only r/o access.

Alex

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

Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work

[Chen Qi via lists.yoctoproject.org]

On 9/11/23 15:36, Alexander Kanavin wrote:

On Mon, 11 Sept 2023 at 06:22, Chen Qi via lists.yoctoproject.org
 wrote:


SSTATE_DIR and DL_DIR are writable. Sharing them among different builds
owned/controlled by the same user is OK, but sharing these writable
directories among different users does not seem to be a good idea.
You could consider using the PREMIRRORS and SSTATE_MIRRORS.

This is not accurate. SSTATE_DIR is designed to be shared in a
read-write fashion via NFS or other over the network filesystem
(between users on the same machine is also ok), and is heavily used
that way in Yocto CI.


This is the case I referred to as 'different builds owned/controlled by 
the same user'.


Say, you share the SSTATE_DIR used by Yocto CI to many people via NFS. 
Then, a 'rm -rf' might be typed by someone by accident, maybe just 
because of lack of coffee.


Regards,

Qi



Sharing DL_DIR is less important as it is not that large, and
downloading does not slow down the builds that much compared to the
the actual build (and only needs to happen once).

Li, your understanding is more or less completely correct. The
difficulties are mostly in scaling up, where you might hit the limits
of how many users can be served at the same time.

Alex




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

Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work

[Quentin Schulz via lists.yoctoproject.org]

Hi all,

On 9/11/23 09:36, Alexander Kanavin via lists.yoctoproject.org wrote:

On Mon, 11 Sept 2023 at 06:22, Chen Qi via lists.yoctoproject.org
 wrote:


SSTATE_DIR and DL_DIR are writable. Sharing them among different builds
owned/controlled by the same user is OK, but sharing these writable
directories among different users does not seem to be a good idea.
You could consider using the PREMIRRORS and SSTATE_MIRRORS.


This is not accurate. SSTATE_DIR is designed to be shared in a
read-write fashion via NFS or other over the network filesystem
(between users on the same machine is also ok), and is heavily used
that way in Yocto CI.



But sharing the same SSTATE_DIR with people running cleansstate or 
manually removing entries is an issue as far as I remember. I don't know 
if mount allows to mount file systems with read and write but not erase 
permissions?


On a separate note, we've setup NFS donwload cache for Buildroot and 
Yocto and for one (maybe both?) we had an issue with filelocks. 
Basically we had one disk on one of the build servers which we exposed 
through NFS share to other build servers and users. However, the 
filelocks weren't respected when one was set in NFS (or ext4) and 
checked against in ext4 (or NFS respectively). So I suggest to be 
mindful about this when setting up your infrastructure and use the same 
FS across all users (you can mount a local FS with NFS as far as I 
remember).


I haven't done that yet but I believe one is supposed to share the 
hashequiv server too for max reusability? I am unfortunately not 
familiar with it but just wanted to raise this.


Cheers,
Quentin


Sharing DL_DIR is less important as it is not that large, and
downloading does not slow down the builds that much compared to the
the actual build (and only needs to happen once).

Li, your understanding is more or less completely correct. The
difficulties are mostly in scaling up, where you might hit the limits
of how many users can be served at the same time.

Alex






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

Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work

[Ross Burton]

On 11 Sep 2023, at 05:22, Chen Qi via lists.yoctoproject.org 
 wrote:
> 
> SSTATE_DIR and DL_DIR are writable. Sharing them among different builds 
> owned/controlled by the same user is OK, but sharing these writable 
> directories among different users does not seem to be a good idea.
> You could consider using the PREMIRRORS and SSTATE_MIRRORS.

If you have group-sticky bits on the parent directories and a shared group that 
all the users are members of then you can share sstate and dldir between 
different users.

That’s the theory, at least.  The last time I tried this in production there 
was a bug in sstate writing where the permissions would be incorrectly changed, 
but I couldn’t replicate with master so possibly this has been fixed.

NFS is known to work fine (the autobuilder uses a NFS mount for sstate/dldir 
across tens of builders), and people have reported that Cephfs works well too.  
I’m not aware of anyone using Lustre.

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

Re: [yocto] How to add a hook or handler for specified task?

[Jiliang Cai]

I found a solution that works. If there are other more suitable solutions, 
please let me know, thank you. Everyone is welcome to discuss.

I use the bb.build.TaskFailed event, although it's global, not specific to a 
recipe. In the handler body, I use e.getTask() to determine whether the 
specified task failed, and if so, execute my code.

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

Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work

[Alexander Kanavin]

On Mon, 11 Sept 2023 at 06:22, Chen Qi via lists.yoctoproject.org
 wrote:

> SSTATE_DIR and DL_DIR are writable. Sharing them among different builds
> owned/controlled by the same user is OK, but sharing these writable
> directories among different users does not seem to be a good idea.
> You could consider using the PREMIRRORS and SSTATE_MIRRORS.

This is not accurate. SSTATE_DIR is designed to be shared in a
read-write fashion via NFS or other over the network filesystem
(between users on the same machine is also ok), and is heavily used
that way in Yocto CI.

Sharing DL_DIR is less important as it is not that large, and
downloading does not slow down the builds that much compared to the
the actual build (and only needs to happen once).

Li, your understanding is more or less completely correct. The
difficulties are mostly in scaling up, where you might hit the limits
of how many users can be served at the same time.

Alex

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