[yocto] [meta-lts-mixins][scarthgap/u-boot][RFC PATCH 2/2] u-boot: bump to v2024.04-rc4
https://github.com/u-boot/u-boot/compare/v2024.04-rc3...v2024.04-rc4
Release announcement:
https://lists.denx.de/pipermail/u-boot/2024-March/547988.html
Signed-off-by: Tim Orling
---
recipes-bsp/u-boot/u-boot-common.inc| 2 +-
...{u-boot-tools_2024.04-rc3.bb => u-boot-tools_2024.04-rc4.bb} | 0
.../u-boot/{u-boot_2024.04-rc3.bb => u-boot_2024.04-rc4.bb} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename recipes-bsp/u-boot/{u-boot-tools_2024.04-rc3.bb =>
u-boot-tools_2024.04-rc4.bb} (100%)
rename recipes-bsp/u-boot/{u-boot_2024.04-rc3.bb => u-boot_2024.04-rc4.bb}
(100%)
diff --git a/recipes-bsp/u-boot/u-boot-common.inc
b/recipes-bsp/u-boot/u-boot-common.inc
index 3f29f23..69ecff8 100644
--- a/recipes-bsp/u-boot/u-boot-common.inc
+++ b/recipes-bsp/u-boot/u-boot-common.inc
@@ -12,7 +12,7 @@ PE = "1"
# We use the revision in order to avoid having to fetch it from the
# repo during parse
-SRCREV = "d49fa3defa50c6d3f04acbb52fd486c13c14ab6a"
+SRCREV = "f3c979dd0053c082d2df170446923e7ce5edbc2d"
SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master"
diff --git a/recipes-bsp/u-boot/u-boot-tools_2024.04-rc3.bb
b/recipes-bsp/u-boot/u-boot-tools_2024.04-rc4.bb
similarity index 100%
rename from recipes-bsp/u-boot/u-boot-tools_2024.04-rc3.bb
rename to recipes-bsp/u-boot/u-boot-tools_2024.04-rc4.bb
diff --git a/recipes-bsp/u-boot/u-boot_2024.04-rc3.bb
b/recipes-bsp/u-boot/u-boot_2024.04-rc4.bb
similarity index 100%
rename from recipes-bsp/u-boot/u-boot_2024.04-rc3.bb
rename to recipes-bsp/u-boot/u-boot_2024.04-rc4.bb
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62808): https://lists.yoctoproject.org/g/yocto/message/62808
Mute This Topic: https://lists.yoctoproject.org/mt/105051175/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-lts-mixins][scarthgap/u-boot][RFC PATCH 0/2] Initial commit of scarthgap/u-boot
Motivated in part by raspberrypi5 support added in u-boot v2024.04-* this branch will track upstream u-boot versions throughout the support window of scarthgap to allow newer versions tracked in either openembedded-core "master" or possibly new release candidates for u-boot upstream. This is pure vanilla upstream and in no way board or bsp specific. Tim Orling (2): Initial commit: u-boot 2024.04-rc3 u-boot: bump to v2024.04-rc4 -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62806): https://lists.yoctoproject.org/g/yocto/message/62806 Mute This Topic: https://lists.yoctoproject.org/mt/105051171/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-lts-mixins][scarthgap/u-boot][RFC PATCH 1/2] Initial commit: u-boot 2024.04-rc3
At the time this was written, neither scarthgap nor u-boot had been
released at the target April 2024 releases.
Release announcement:
https://lists.denx.de/pipermail/u-boot/2024-February/546867.html
Signed-off-by: Tim Orling
---
LICENSE.MIT | 25 ++
README.md | 13 +
SECURITY.md | 22 ++
conf/layer.conf | 14 +
recipes-bsp/u-boot/u-boot-common.inc | 24 ++
recipes-bsp/u-boot/u-boot-configure.inc | 38 ++
recipes-bsp/u-boot/u-boot-tools.inc | 85 +
.../u-boot/u-boot-tools_2024.04-rc3.bb| 2 +
recipes-bsp/u-boot/u-boot.inc | 345 ++
recipes-bsp/u-boot/u-boot_2024.04-rc3.bb | 5 +
10 files changed, 573 insertions(+)
create mode 100644 LICENSE.MIT
create mode 100644 README.md
create mode 100644 SECURITY.md
create mode 100644 conf/layer.conf
create mode 100644 recipes-bsp/u-boot/u-boot-common.inc
create mode 100644 recipes-bsp/u-boot/u-boot-configure.inc
create mode 100644 recipes-bsp/u-boot/u-boot-tools.inc
create mode 100644 recipes-bsp/u-boot/u-boot-tools_2024.04-rc3.bb
create mode 100644 recipes-bsp/u-boot/u-boot.inc
create mode 100644 recipes-bsp/u-boot/u-boot_2024.04-rc3.bb
diff --git a/LICENSE.MIT b/LICENSE.MIT
new file mode 100644
index 000..a6919eb
--- /dev/null
+++ b/LICENSE.MIT
@@ -0,0 +1,25 @@
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+Note:
+Individual files contain the following tag instead of the full license text.
+
+SPDX-License-Identifier: MIT
+
+This enables machine processing of license information based on the SPDX
+License Identifiers that are here available: http://spdx.org/licenses/
diff --git a/README.md b/README.md
new file mode 100644
index 000..5eb92c4
--- /dev/null
+++ b/README.md
@@ -0,0 +1,13 @@
+# meta-lts-mixin scarthgap/u-boot
+
+"Mixin" layer for adding current u-boot into the Yocto Project LTS.
+
+At the time Scarthgap was released in April 2024 it included u-boot 2024.01,
+and officially Scarthgap supports only that. This thin special-purpose
+mixin layer is meant to provide a current u-boot for Scarthgap
+by extending or backporting the appropriate recipes from the master branch of
+openembedded-core.
+
+Maintainers:
+- Tim Orling
+- Tom Rini
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 000..8d3ebc6
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,22 @@
+How to Report a Potential Vulnerability?
+
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+[Security
Bugzilla](https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security)
+
+If you are dealing with a not-yet released or urgent issue, please send a
+message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
+
+Branches maintained with security fixes
+---
+
+See [Stable release and
LTS](https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS)
+for detailed info regarding the policies and maintenance of Stable branches.
+
+The [Release page](https://wiki.yoctoproject.org/wiki/Releases) contains a
list of all
+releases of the Yocto Project. Versions in grey are no longer actively
maintained with
+security patches, but well-tested patches may still be accepted for them for
+significant issues.
diff --git a/conf/layer.conf b/conf/layer.conf
new file mode 100644
index 000..426f7f8
--- /dev/null
+++ b/conf/layer.conf
@@ -0,0 +1,14 @@
+# We have a conf and classes directory, but we have classes that should
+# override those in oe-core, so prepend to BBPATH
+BBPATH =. "${LAYERDIR}:"
+
+# We have a recipes directory, add to BBFILES
+BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbapp
Re: [yocto] install-vs-shipped
On 20 Mar 2024, at 15:16, Bratiranjan Acharya wrote: > > HI, > it is informative yeah i am able to getting the hold of the problem. yeah you > were right after running the command i got libdir as usr/lib64 .I couldn't > get any clearer from the links of fix patch can you please tell how i can > solve this shall i try to export the path of libdir to usr/lib for the recipe? Download the patch, add it to SRC_URI for the recipe, hope it works. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62805): https://lists.yoctoproject.org/g/yocto/message/62805 Mute This Topic: https://lists.yoctoproject.org/mt/105008765/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] make a-quick quick again (and light on the AB, particularly arm)
On Wed, 2024-03-20 at 12:27 +0100, Alexander Kanavin wrote: > On Wed, 20 Mar 2024 at 11:55, Ross Burton > wrote: > > I’d be against removing _all_ arm hosts from the quick build. With > > the in-progress changes to the autobuilder hosting we should be > > able to retire the slower Arm workers and a build running on the > > Arm hosts shouldn’t be a problem. It would be a waste of effort to > > attempt to optimise the build for the current cluster when there > > are plans to relocate shortly anyway. > > Right, then let's not make this about arm builders, and simply drop > selftest of any kind and reproducible from a-quick. How about that? > > Particularly selftest keeps getting bigger and slower and that isn't > going to change. It used to take under an hour, nowadays it's 2+ > hours on x86 and 3+ on arm, with full sstate ready from the start. It does depend what you're testing btw. You tend to test package upgrades which don't really affect selftest as much as some of the other changes I'm often dealing with. I don't disagree with adding a separate target but I do want to make it clear we should improve the speed of selftest too, I'm not ready to give up on that yet! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62804): https://lists.yoctoproject.org/g/yocto/message/62804 Mute This Topic: https://lists.yoctoproject.org/mt/105041413/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] make a-quick quick again (and light on the AB, particularly arm)
On Wed, 2024-03-20 at 10:33 +0100, Alexander Kanavin wrote: > I feel that a-quick builds as they are have ceased to be quick or > lightweight, and I'd like to trim heavy items from them. The goal is > to: > > - have a-quick complete in under an hour with fully populated sstate > - lessen the load on arm workers in particular; there is not enough of > them, and they should be used only in a-full > - make a-quick useful as a quick smoke check for patchsets that > reveals obvious issues rapidly, completes quickly, and doesn't compete > with a-full for resources too much. I would then be willing to use > them for that purpose. > > The definitions of a-quick and a-full are here: > https://git.yoctoproject.org/yocto-autobuilder2/tree/config.py#n75 > > I'd like to make the following changes to reduce the load on arm workers: > - oe-selftest-armhost moves from shared to full. This is the biggest offender. > > - qemuarm64-armhost does the same > > There are also other heavy builds in a-quick that I think shouldn't be > a part of it: > > - reproducible should move from shared to full. There's no way to make > it quicker. > > - oe-selftest should be dropped from quick, or we could introduce > oe-selftest-quick that runs only a subset of sefltests that completes > under an hour (existing logs can be used to make that selection, e.g. > by tagging known slow test classes). > > Thoughts? a-quick was added with the idea of covering the key things which catch errors without the duplication that "full" has. In that sense, "quick" was less of the intent than allowing relaxing of some of the tests where it was possible to do so without breaking coverage too much. For various reasons people haven't really used "quick". Also, in general people do want to know about all the issues, including reproducibility and selftest (on arm). Host specific issues are comparatively rare on selftest now (gl passthrough being an exception) and we already stopped per-distro reproducibility testing. So I'm torn. It would be fine and easy to maintain another target alongside quick and full though so there isn't really a good reason not to add something if it would be useful. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62803): https://lists.yoctoproject.org/g/yocto/message/62803 Mute This Topic: https://lists.yoctoproject.org/mt/105041413/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] make a-quick quick again (and light on the AB, particularly arm)
On Wed, 20 Mar 2024 at 11:55, Ross Burton wrote: > I’d be against removing _all_ arm hosts from the quick build. With the > in-progress changes to the autobuilder hosting we should be able to retire > the slower Arm workers and a build running on the Arm hosts shouldn’t be a > problem. It would be a waste of effort to attempt to optimise the build for > the current cluster when there are plans to relocate shortly anyway. Right, then let's not make this about arm builders, and simply drop selftest of any kind and reproducible from a-quick. How about that? Particularly selftest keeps getting bigger and slower and that isn't going to change. It used to take under an hour, nowadays it's 2+ hours on x86 and 3+ on arm, with full sstate ready from the start. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62802): https://lists.yoctoproject.org/g/yocto/message/62802 Mute This Topic: https://lists.yoctoproject.org/mt/105041413/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] make a-quick quick again (and light on the AB, particularly arm)
On 20 Mar 2024, at 09:33, Alexander Kanavin via lists.yoctoproject.org wrote: > I'd like to make the following changes to reduce the load on arm workers: > - oe-selftest-armhost moves from shared to full. This is the biggest offender. > > - qemuarm64-armhost does the same > > There are also other heavy builds in a-quick that I think shouldn't be > a part of it: I’d be against removing _all_ arm hosts from the quick build. With the in-progress changes to the autobuilder hosting we should be able to retire the slower Arm workers and a build running on the Arm hosts shouldn’t be a problem. It would be a waste of effort to attempt to optimise the build for the current cluster when there are plans to relocate shortly anyway. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62801): https://lists.yoctoproject.org/g/yocto/message/62801 Mute This Topic: https://lists.yoctoproject.org/mt/105041413/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] make a-quick quick again (and light on the AB, particularly arm)
Hello, I feel that a-quick builds as they are have ceased to be quick or lightweight, and I'd like to trim heavy items from them. The goal is to: - have a-quick complete in under an hour with fully populated sstate - lessen the load on arm workers in particular; there is not enough of them, and they should be used only in a-full - make a-quick useful as a quick smoke check for patchsets that reveals obvious issues rapidly, completes quickly, and doesn't compete with a-full for resources too much. I would then be willing to use them for that purpose. The definitions of a-quick and a-full are here: https://git.yoctoproject.org/yocto-autobuilder2/tree/config.py#n75 I'd like to make the following changes to reduce the load on arm workers: - oe-selftest-armhost moves from shared to full. This is the biggest offender. - qemuarm64-armhost does the same There are also other heavy builds in a-quick that I think shouldn't be a part of it: - reproducible should move from shared to full. There's no way to make it quicker. - oe-selftest should be dropped from quick, or we could introduce oe-selftest-quick that runs only a subset of sefltests that completes under an hour (existing logs can be used to make that selection, e.g. by tagging known slow test classes). Thoughts? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62800): https://lists.yoctoproject.org/g/yocto/message/62800 Mute This Topic: https://lists.yoctoproject.org/mt/105041413/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
