|
[meta-security][PATCH 5/5] packagegroup-core-security: drop python3-scapy
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 --
1 file changed, 2 deletions(-)
diff --git
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 --
1 file changed, 2 deletions(-)
diff --git
|
By
Armin Kuster
·
#53705
·
|
|
[meta-security][PATCH 4/5] python3-scapy: drop , now in meta-python
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-security/scapy/files/run-ptest | 4 ---
recipes-security/scapy/python3-scapy_2.4.5.bb | 30 -------------------
2 files changed,
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-security/scapy/files/run-ptest | 4 ---
recipes-security/scapy/python3-scapy_2.4.5.bb | 30 -------------------
2 files changed,
|
By
Armin Kuster
·
#53704
·
|
|
[meta-security][PATCH 3/5] initramfs-framework: fix YCL issue.
Signed-off-by: Armin Kuster <akuster808@...>
---
.../initrdscripts/initramfs-framework.inc | 16 ++++++++++++++++
.../initramfs-framework_1.0.bbappend | 17 +----------------
2
Signed-off-by: Armin Kuster <akuster808@...>
---
.../initrdscripts/initramfs-framework.inc | 16 ++++++++++++++++
.../initramfs-framework_1.0.bbappend | 17 +----------------
2
|
By
Armin Kuster
·
#53703
·
|
|
[meta-security][PATCH 2/5] linux-%_5.%.bbappend: drop recipe
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-kernel/linux/linux-%_5.%.bbappend | 4 ----
1 file changed, 4 deletions(-)
delete mode 100644
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-kernel/linux/linux-%_5.%.bbappend | 4 ----
1 file changed, 4 deletions(-)
delete mode 100644
|
By
Armin Kuster
·
#53702
·
|
|
[meta-security][PATCH 1/5] busybox: drop as libsecomp is in core
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/busybox/busybox/head.cfg | 1 -
recipes-core/busybox/busybox_%.bbappend | 1 -
recipes-core/busybox/busybox_libsecomp.inc |
Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/busybox/busybox/head.cfg | 1 -
recipes-core/busybox/busybox_%.bbappend | 1 -
recipes-core/busybox/busybox_libsecomp.inc |
|
By
Armin Kuster
·
#53701
·
|
|
Re: #yocto ASUS ROG STRIX Z390-I
#yocto
use meta-intel build for a core-i7 I also have an ASUS ROG board running yocto.
On 5/30/21 6:15 PM, a.elgammal2019@... wrote:
use meta-intel build for a core-i7 I also have an ASUS ROG board running yocto.
On 5/30/21 6:15 PM, a.elgammal2019@... wrote:
|
By
Yocto
·
#53700
·
|
|
#Tesla T4 Support
#tesla
I am building a custom image for
ASUS ROG STRIX Z390-I, with Tesla T4I will build on meta-intel. But the problem is that I am also using Tesla T4 GPU, which requires CUDA toolkit to install. And
I am building a custom image for
ASUS ROG STRIX Z390-I, with Tesla T4I will build on meta-intel. But the problem is that I am also using Tesla T4 GPU, which requires CUDA toolkit to install. And
|
By
Abdelrahman El-Gammal <a.elgammal2019@...>
·
#53699
·
|
|
#yocto ASUS ROG STRIX Z390-I
#yocto
Hello,
I have a ROG STRIX Z390-I motherboard with an IntelĀ® Z390 chipset. And I want to create a custom BSP Layer for it. Where should I start? I did not find any yocto community for ASUS. So, Any
Hello,
I have a ROG STRIX Z390-I motherboard with an IntelĀ® Z390 chipset. And I want to create a custom BSP Layer for it. Where should I start? I did not find any yocto community for ASUS. So, Any
|
By
a.elgammal2019@...
·
#53698
·
|
|
Re: [poky][master][PATCH} VirGL: depends on virtual/gbm
It looks like a Mesa dependency is looming for NVIDIA: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902
Thanks
It looks like a Mesa dependency is looming for NVIDIA: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902
Thanks
|
By
Joel Winarske
·
#53697
·
|
|
Re: [poky][master][PATCH} VirGL: depends on virtual/gbm
Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.
The patch should be
Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.
The patch should be
|
By
Alexander Kanavin
·
#53696
·
|
|
[poky][master][PATCH} VirGL: depends on virtual/gbm
This addresses cases where the platform doesn't depend on Mesa. Tegra is one example.
From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske
This addresses cases where the platform doesn't depend on Mesa. Tegra is one example.
From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske
|
By
Joel Winarske
·
#53695
·
|
|
Re: How to switch yocto INIT_MANAGER from systemd to sysvinit
#dunfell
Typo. No leading space INIT_MANAGER = "sysvinit".
Thanks,
Priya.
Typo. No leading space INIT_MANAGER = "sysvinit".
Thanks,
Priya.
|
By
Swapna Nannapaneni
·
#53694
·
|
|
Re: How to switch yocto INIT_MANAGER from systemd to sysvinit
#dunfell
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection
But this is exactly why we need some explicit examples.
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection
But this is exactly why we need some explicit examples.
|
By
Zoran
·
#53693
·
|
|
Re: How to switch yocto INIT_MANAGER from systemd to sysvinit
#dunfell
you don't want the leading space.
rday
you don't want the leading space.
rday
|
By
Robert P. J. Day
·
#53692
·
|
|
Re: How to switch yocto INIT_MANAGER from systemd to sysvinit
#dunfell
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?
Thank you,
Zee
_______
<sayinswapna@...> wrote:
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?
Thank you,
Zee
_______
<sayinswapna@...> wrote:
|
By
Zoran
·
#53691
·
|
|
Re: How to switch yocto INIT_MANAGER from systemd to sysvinit
#dunfell
Thanks Robert and Raj!!
I am using Yocto 3.1 Dunfell release.
You are right about the .bbappend file. Changed the name in the overlay to new-ver.bbappend and no longer see the warning.
Tried setting
Thanks Robert and Raj!!
I am using Yocto 3.1 Dunfell release.
You are right about the .bbappend file. Changed the name in the overlay to new-ver.bbappend and no longer see the warning.
Tried setting
|
By
Swapna Nannapaneni
·
#53690
·
|
|
Re: How to switch yocto INIT_MANAGER from systemd to sysvinit
#dunfell
Why do I (always) point out the obvious?
And I do need... Geniuses are not meant to fix The World to understand them!?
Geniuses should understand The World (and act properly)!
Extras to geniality,
Why do I (always) point out the obvious?
And I do need... Geniuses are not meant to fix The World to understand them!?
Geniuses should understand The World (and act properly)!
Extras to geniality,
|
By
Zoran
·
#53689
·
|
|
Re: Where to define username/password when fetching sstate via http with basic authentication?
Hi Quentin,
obviously I didn't read that page carefully enough. Sorry for the noise and thanks for the hint.
Cheers, Manuel
Am Fr, 28. Mai 2021, um 11:35, schrieb Quentin Schulz:
Hi Quentin,
obviously I didn't read that page carefully enough. Sorry for the noise and thanks for the hint.
Cheers, Manuel
Am Fr, 28. Mai 2021, um 11:35, schrieb Quentin Schulz:
|
By
Manuel Wagesreither
·
#53688
·
|
|
Re: Where to define username/password when fetching sstate via http with basic authentication?
Hi Manuel,
There is an example in the commit you sent, so I would say:
SSTATE_MIRRORS ?= " \
file://.* http://someserver.tld/share/sstate/PATH;user=username:password;downloadfilename=PATH
Hi Manuel,
There is an example in the commit you sent, so I would say:
SSTATE_MIRRORS ?= " \
file://.* http://someserver.tld/share/sstate/PATH;user=username:password;downloadfilename=PATH
|
By
Quentin Schulz
·
#53687
·
|
|
Where to define username/password when fetching sstate via http with basic authentication?
Hello all,
to speed up builds, we would like to make the CI generated sstate-cache available via internet. Due to IP concerns, we don't want to make it publically available but for authenticated
Hello all,
to speed up builds, we would like to make the CI generated sstate-cache available via internet. Due to IP concerns, we don't want to make it publically available but for authenticated
|
By
Manuel Wagesreither
·
#53686
·
|