Signed-off-by: Jon Mason <jon.mason@...>
---
.gitlab-ci.yml | 3 +++
ci/nrf52840-mdk-usb-dongle.yml | 6 ++++++
2 files changed, 9 insertions(+)
create mode 100644 ci/nrf52840-mdk-usb-dongle.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 082cd44..c185477 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -74,6 +74,9 @@ arduino-nano-33-ble:
intel-x86-64:
extends: .build

+nrf52840-mdk-usb-dongle:
+ extends: .build
+
nrf52840dk-nrf52840:
extends: .build

diff --git a/ci/nrf52840-mdk-usb-dongle.yml b/ci/nrf52840-mdk-usb-dongle.yml
new file mode 100644
index 0000000..0dc3433
--- /dev/null
+++ b/ci/nrf52840-mdk-usb-dongle.yml
@@ -0,0 +1,6 @@
+header:
+ version: 11
+ includes:
+ - ci/base.yml
+
+machine: nrf52840-mdk-usb-dongle
--
2.17.1

On Fri, Sep 23, 2022 at 12:45:09PM +0200, philippe.coval@... wrote:

From: Philippe Coval <philippe.coval@...>

It was tested with zephyr-openthread-rcp
along Oniro's IoT gateway blueprint

For the record deployment was done manually:

- Click on device button
- uf2conv.py "zephyr.hex" -c -f 0xADA52840
- and then copy to mounted "/dev/disk/by-label/MDK-DONGLE"

Support of unfree flashing tools might be added later (once double verified)

Forwarded: https://lists.yoctoproject.org/g/yocto/message/58142
Relate-to: https://gitlab.eclipse.org/eclipse/oniro-blueprints/transparent-gateway/meta-oniro-blueprints-gateway/-/issues/6
Relate-to: https://wiki.makerdiary.com/nrf52840-mdk/zephyr/
Relate-to: https://gitlab.eclipse.org/pcoval/oniro-presentations/-/wikis/openthread
Signed-off-by: Philippe Coval <philippe.coval@...>
Signed-off-by: Philippe Coval <philippe.coval.ext@...>

This needs a Gitlab CI entry to test. I did a quick one and ran CI on
it here:
https://gitlab.com/jonmason00/meta-zephyr/-/pipelines/651094923

I'll email the patch to add CI shortly.

Thanks,
Jon

---
meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf

diff --git a/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf b/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
new file mode 100644
index 0000000..67e407a
--- /dev/null
+++ b/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
@@ -0,0 +1,7 @@
+#@TYPE: Machine
+#@NAME: nrf52840-mdk-usb-dongle
+
+#@DESCRIPTION: Machine configuration for makerdiary's nrf52840-mdk-usb-dongle
+
+require conf/machine/include/nrf52.inc
+ARCH:nrf52840-mdk-usb-dongle = "arm"
--
2.34.1

Anything written in C++ tends to consume 1-2 Gb of ram per compiler
process. If that lands you in OOM, you probably should limit that with
PARALLEL_MAKE:pn-nodejs, but otherwise that is the sad reality of C++
builds.

Alex

On Mon, 26 Sept 2022 at 19:20, Oliver Westermann via
lists.yoctoproject.org
<oliver.westermann=cognex.com@...> wrote:

Hey,

We recently added nodejs to our images and noticed that it's do compile process is a real memory hog. Since we planned to update the recipe anyway we didn't pay much attention, but today we updated the recipe to the current version from openembedded-core (16.14.2). Still I see that it consumes nearly all resources it can get, way more than any other package in our build process (and crashing some VMs even).

On my build machine (dual Epyc, 256GB of RAM) it manages to produce nearly 100% CPU load AND eats ~90GB of RAM. Some other machines fail the build due to OOM issues.

I only observed this on the nodejs build, is there a good approach to debug this (or even a known issue)?

Best regards, Olli

TL;DR version
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If you want to get everything needed to run a yocto build:

- clone the bootstrap repository (ask your distribution maintainer where =
it is):
$ git clone bootstrap_repo_uri

- run 'setup-layers' from that repo:
$ /path/to/bootstrap_repo/setup-layers

If you want to save the layers setup for replication elsewhere:

- save the config file and the replication script into a 'bootstrap repos=
itory')
(this can be an organization-specific yocto layer, or a standalone reposi=
tory):
$ bitbake-layers create-layers-setup /path/to/bootstrap_repo

- document where the bootstrap repository can be found for your users

What is this layer setup tooling? (the long version)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

Once you have a working build with the correct set of layers, it is benef=
icial
to capture the layer setup --- what they are, which repositories they com=
e from
and which SCM revisions they're at --- into a configuration file, so that=
this
setup can be easily replicated later, perhaps on a different machine. Her=
e's
how to do this::

$ bitbake-layers create-layers-setup /srv/work/alex/meta-alex/
NOTE: Starting bitbake server...
NOTE: Created /srv/work/alex/meta-alex/setup-layers.json
NOTE: Created /srv/work/alex/meta-alex/setup-layers

The tool needs a single argument which tells where to place the output, c=
onsisting
of a json formatted layer configuration, and a ``setup-layers`` script th=
at can use that configuration
to restore the layers in a different location, or on a different host mac=
hine. The argument
can point to a custom layer (which is then deemed a "bootstrap" layer tha=
t needs to be
checked out first), or into a completely independent location.

The replication of the layers is performed by running the ``setup-layers`=
` script provided
above:

1. Clone the bootstrap layer or some other repository to obtain
the json config and the setup script that can use it.

2. Run the script directly with no options::

alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers
Note: not checking out source meta-alex, use --force-bootstraplayer=
-checkout to override.

Setting up source meta-intel, revision 15.0-hardknott-3.3-310-g0a96=
edae, branch master
Running 'git init -q /srv/work/alex/my-build/meta-intel'
Running 'git remote remove origin > /dev/null 2>&1; git remote add =
origin git://git.yoctoproject.org/meta-intel' in /srv/work/alex/my-build/=
meta-intel
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/me=
ta-intel
Running 'git checkout -q 0a96edae609a3f48befac36af82cf1eed6786b4a' =
in /srv/work/alex/my-build/meta-intel

Setting up source poky, revision 4.1_M1-372-g55483d28f2, branch aka=
navin/setup-layers
Running 'git init -q /srv/work/alex/my-build/poky'
Running 'git remote remove origin > /dev/null 2>&1; git remote add =
origin git://git.yoctoproject.org/poky' in /srv/work/alex/my-build/poky
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/po=
ky
Running 'git remote remove poky-contrib > /dev/null 2>&1; git remot=
e add poky-contrib ssh://git@.../poky-contrib' in /srv/=
work/alex/my-build/poky
Running 'git fetch -q poky-contrib || true' in /srv/work/alex/my-bu=
ild/poky
Running 'git checkout -q 11db0390b02acac1324e0f827beb0e2e3d0d1d63' =
in /srv/work/alex/my-build/poky

.. note::

This will work to update an existing checkout as well.

.. note::
The script is self-sufficient and requires only python3
and git on the build machine.

.. note::
Both the ``create-layers-setup`` and the ``setup-layers`` provided sev=
eral additional options
that customize their behavior - you are welcome to study them via ``--=
help`` command line parameter.

Questions and answers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1. Why JSON, and not YAML?

JSON is a part of the python standard library, while YAML is not. This me=
ans you can bootstrap a build on just about any
machine that has python and its core library, without first having to ins=
tall any dependencies. JSON not quite as easy
on the eye, but with decent indentation it's totally ok.

Before anyone asks, XML is appallingly difficult to read by modern standa=
rds of readability. No thanks.

2. I don't want the script in the bootstrap repo, just the config. I will=
provide my own tools. How?

Use --json-only to generate only the config, and not the script:

$ bitbake-layers create-layers-setup -json-only /srv/work/alex/meta-a=
lex/

3. I want to generate the compatible json with my own tools. Is there a s=
chema to validate it?

There is:
https://git.yoctoproject.org/poky/tree/meta/files/layers.schema.json

You can use python3-jsonschema package to check the validity.

4. I don't want the json or the script, and would want to use an entirely=
different format and tools. Is
'create-layers-setup' hardcoded to the OE json format?

Actually not! Other formats can be added through a plugin mechanism. OE j=
son writer is just
the default plugin but others can be implemented and selected:

--writer {oe-setup-layers}, -w {oe-setup-layers}
Choose the output format (defaults to oe-setup-la=
yers).

5. I want to use something else than hardcoded revisions in the json (e.g=
. refer to branch
names or tags).

No problem! Edit the json to say 'main' or 'release-x.y'. Anything that '=
git checkout' can take will
work. Just be careful that these modification are not overwritten later b=
y 'create-layers-setup' by
e.g. renaming the json file first.

6. I already have an existing checkout and want to update it to the lates=
t greatest. How?

First, update the bootstrap repository to the latest (or otherwise desire=
d) revision to
obtain the latest versions of the script, and the json config. Ask the di=
stro maintainers
for the recommended practice to do so.

Then, run the script again - it should be able to handle a layers checkou=
t that already
exists, and update everything accoriding to the latest json, obtained in =
the first step.

7. Ok, I have checked out all the layers. Now what?

The next step is to actually set up a yocto build from an existing config=
uration template,
and start a bitbake session. This is made separate from handling the laye=
r repositories and
will be described separately.

On Mon, 2022-09-26 at 09:22 +0000, Teoh, Jay Shen wrote:

Hi All,

QA for yocto-4.0.4.rc1 is completed. This is the full report for this release:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.

Thanks!

Since this is a point release with a clean build and clean QA report,
we can move straight to releasing it and don't need to obtain approval
from the whole TSC.

Cheers,

Richard

On 25.09.22 11:41, Richard Purdie wrote:

On Sun, 2022-09-25 at 10:53 +0200, Konrad Weihmann wrote:

Hi all,

On 24.09.22 04:02, Lee Chee Yang wrote:

Hi

We are pleased to announce the third milestone release for Yocto Project
4.1 (yocto-4.1_M3) is now available for download.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-4.1_M3
<http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-4.1_M3>

bitbake: 6424f4b7e9c1ba8db81346e8b3a806dd035d4551

meta-agl: e4ea839db9c26e78175d61388c5408a79f6927dc

meta-arm: 261263a6701ab3530ff997643d08da502222ac20

meta-aws: a16f35a73bff26d9506f519451dc75034211d61b

meta-gplv2: 43bf0e8d5985945d19d01f94bfbbda420c4435f3

I thought the agreement was to stop promoting meta-gplv2?
Still I find it listed here - it somehow implies that this is still
officially support, which everyone agreed it isn't

Can this be removed from the announcement template for the next
releases? - just to avoid any future misunderstandings

Someone needs to do the work involved and I guess that hasn't happened.
It isn't entirely simple as this does still exist in the other
releases.
Could you open a bug please so we don't forget this.

Bug filed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14916

Not sure if I put it in the right category, so feel free to move it around if needed

I still don't know who will do it but that way we at least remember we
need to.
Cheers,
Richard

Hi All,

QA for yocto-4.0.4.rc1 is completed. This is the full report for this release:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.

Thanks,
Jay

Hi Mahendra Sondagar,

On 9/25/22 19:38, Mahendra Sondagar wrote:

Hey.. There
Hope all are doing well
I'm dealing with the swupdate with the my custom Yocto image created for STM32MP1 dk1 board
The intend is, to update the rootfs remotely
I have successfully integrated meta-swupdate layer with the custom Yocto image by adding the layers in to bblayer.conf file
The both layers meta-swupdate & meta-custom are parallel to each-others
To change the flags and setting with the swupdate, i have created the r *ecipes-myswupdate* file inside the meta-custom layers
The content of the recipes-myswupdate are as follows
.
└── swupdate
├── stm32mp1
│   ├── 09-swupdate-args
│   ├── defconfig
│   ├── sw-description
│   └── swupdate.cfg
└── swupdate_%.bbappend

Considering you're using SRC_URI unconditionally, I suggest you use:
.
├── swupdate
│ ├── 09-swupdate-args
│ ├── defconfig
│ ├── sw-description
│ └── swupdate.cfg
└── swupdate_%.bbappend

The content of the *swupdate_%.bbappend* are as follows
--------------------------------------------------------------------------------------
DESCRIPTION = "Example recipe generating SWU image"
SECTION = ""
LICENSE = ""
# Add all local files to be added to the SWU
# sw-description must always be in the list.
# You can extend with scripts or wahtever you need
SRC_URI += " \
file://sw-description \
file://09-swupdate-args \
file://swupdate.cfg \
"
# images to build before building swupdate image
IMAGE_DEPENDS = "core-image-full-cmdline virtual/kernel"
# images and files that will be included in the .swu image
SWUPDATE_IMAGES = "core-image-full-cmdline uImage"
# a deployable image can have multiple format, choose one
SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] = ".ubifs"
SWUPDATE_IMAGES_FSTYPES[uImage] = ".bin"
inherit swupdate

I'm pretty sure you're not appending to the correct recipe, swupdate recipe is the SWUpdate recipe for building the SWUpdate update mechanism SW, it's not for building an image that is making use of SWUpdate mechanism.

I think you want to append to swupdate-image recipe or create your own inheriting swupdate-image?

Or probably both actually, one for adding your configuration files to the SWUpdate SW and the IMAGE_DEPENDS/SWUPDATE_IMAGES/SWUIPDATE_IMAGE_FSTYPES to the image recipe.

In any case, you're missing:
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
in your bbappend for adding files. c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-FILESEXTRAPATHS

Cheers,
Quentin

LIC_FILE_CHKSUM changes to to indentations changes.
use bootstrap to setup config properly.

Drop libgssglue-fix-CVE-2011-2709.patch, libgssglue-g-initialize.patch now included in update.
and ibgssglue-mglueP.patch now included in update.

Drop libgssglue-gss-inq-cred.patch still pending after 5 yrs.

Signed-off-by: Armin Kuster <akuster808@...>
---
.../files/libgssglue-fix-CVE-2011-2709.patch | 43 -------------------
.../files/libgssglue-g-initialize.patch | 21 ---------
.../files/libgssglue-gss-inq-cred.patch | 27 ------------
.../libgssglue/files/libgssglue-mglueP.patch | 21 ---------
.../{libgssglue_0.4.bb => libgssglue_0.7.bb} | 26 +++++------
5 files changed, 13 insertions(+), 125 deletions(-)
delete mode 100644 recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch
delete mode 100644 recipes-security/libgssglue/files/libgssglue-g-initialize.patch
delete mode 100644 recipes-security/libgssglue/files/libgssglue-gss-inq-cred.patch
delete mode 100644 recipes-security/libgssglue/files/libgssglue-mglueP.patch
rename recipes-security/libgssglue/{libgssglue_0.4.bb => libgssglue_0.7.bb} (77%)

diff --git a/recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch b/recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch
deleted file mode 100644
index 6aa1a65..0000000
--- a/recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-Use secure_getenv instead of getenv for setuid programs
-
-(bnc#694598 CVE-2011-2709 bnc#831805)
-
-import from:
-https://build.opensuse.org/package/view_file/openSUSE:Factory/libgssglue/secure-getenv.patch
-
-Upstream-Status: Pending
-
-Signed-off-by: Jackie Huang <jackie.huang@...>
-
-diff --git a/src/g_initialize.c b/src/g_initialize.c
-index 200f173..935a9fa 100644
---- a/src/g_initialize.c
-+++ b/src/g_initialize.c
-@@ -26,6 +26,7 @@
- * This function will initialize the gssapi mechglue library
- */
-
-+#define _GNU_SOURCE
- #include "mglueP.h"
- #include <stdlib.h>
-
-@@ -197,8 +198,7 @@ static void solaris_initialize ()
- void *dl;
- gss_mechanism (*sym)(void), mech;
-
-- if ((getuid() != geteuid()) ||
-- ((filename = getenv("GSSAPI_MECH_CONF")) == NULL))
-+ if ((filename = secure_getenv("GSSAPI_MECH_CONF")) == NULL)
- filename = MECH_CONF;
-
- if ((conffile = fopen(filename, "r")) == NULL) {
-@@ -274,8 +274,7 @@ static void linux_initialize ()
- void *dl;
- gss_mechanism (*sym)(void), mech;
-
-- if ((getuid() != geteuid()) ||
-- ((filename = getenv("GSSAPI_MECH_CONF")) == NULL))
-+ if ((filename = secure_getenv("GSSAPI_MECH_CONF")) == NULL)
- filename = MECH_CONF;
-
- if ((conffile = fopen(filename, "r")) == NULL) {
diff --git a/recipes-security/libgssglue/files/libgssglue-g-initialize.patch b/recipes-security/libgssglue/files/libgssglue-g-initialize.patch
deleted file mode 100644
index 4a9ba33..0000000
--- a/recipes-security/libgssglue/files/libgssglue-g-initialize.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Fix the warning for getuid, geteuid
-g_initialize.c: In function 'linux_initialize':
-g_initialize.c:275:5: warning: implicit declaration of function 'getuid' [-Wimplicit-function-declaration]
-g_initialize.c:275:5: warning: implicit declaration of function 'geteuid' [-Wimplicit-function-declaration]
-
-Upstream-Status: Pending
-Signed-off-by: Yao Zhao <yao.zhao@...>
-
-diff --git a/src/g_initialize.c b/src1/g_initialize.c
-index 82fcce1..200f173 100644
---- a/src/g_initialize.c
-+++ b/src/g_initialize.c
-@@ -29,6 +29,8 @@
- #include "mglueP.h"
- #include <stdlib.h>
-
-+#include <unistd.h> /*getuid, geteuid */
-+#include <sys/types.h>
- #include <stdio.h>
- #include <string.h>
- #include <ctype.h>
diff --git a/recipes-security/libgssglue/files/libgssglue-gss-inq-cred.patch b/recipes-security/libgssglue/files/libgssglue-gss-inq-cred.patch
deleted file mode 100644
index 6dce3e7..0000000
--- a/recipes-security/libgssglue/files/libgssglue-gss-inq-cred.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-1) add free if malloc failed for (*mechanisms)->elements
-2) g_inq_cred.c: In function 'gss_inquire_cred':
-g_inq_cred.c:161:8: warning: passing argument 3 of 'generic_gss_copy_oid' from incompatible pointer type [enabled by default]
-
-Upstream-Status: Pending
-Signed-off-by: Yao Zhao <yao.zhao@...>
-
---- a/src/g_inq_cred.c
-+++ b/src/g_inq_cred.c
-@@ -152,13 +152,15 @@ gss_OID_set * mechanisms;
- union_cred->count);
- if ((*mechanisms)->elements == NULL) {
- *minor_status = ENOMEM;
-+ free(*mechanisms);
-+ *mechanisms = GSS_C_NO_OID_SET;
- return (GSS_S_FAILURE);
- }
-
- for (i=0; i < union_cred->count; i++) {
-- status = generic_gss_copy_oid(minor_status,
-+ status = generic_gss_add_oid_set_member(minor_status,
- &union_cred->mechs_array[i],
-- &((*mechanisms)->elements[i]));
-+ mechanisms);
- if (status != GSS_S_COMPLETE)
- break;
- }
diff --git a/recipes-security/libgssglue/files/libgssglue-mglueP.patch b/recipes-security/libgssglue/files/libgssglue-mglueP.patch
deleted file mode 100644
index 6c9ebf0..0000000
--- a/recipes-security/libgssglue/files/libgssglue-mglueP.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-fix the warning:
-warning: implicit declaration of function 'generic_gss_copy_oid_set' [-Wimplicit-function-declaration]
-
-Upstream-Status: Pending
-Signed-off-by: Yao Zhao <yao.zhao@...>
-
---- a/src/mglueP.h
-+++ b/src/mglueP.h
-@@ -447,6 +447,12 @@ OM_uint32 generic_gss_copy_oid
- gss_OID * /* new_oid */
- );
-
-+OM_uint32 generic_gss_copy_oid_set
-+ (OM_uint32 *minor_status, /* minor_status */
-+ const gss_OID_set_desc * const oidset, /* oid */
-+ gss_OID_set *new_oidset /* new_oid */
-+ );
-+
- OM_uint32 generic_gss_create_empty_oid_set
- (OM_uint32 *, /* minor_status */
- gss_OID_set * /* oid_set */
diff --git a/recipes-security/libgssglue/libgssglue_0.4.bb b/recipes-security/libgssglue/libgssglue_0.7.bb
similarity index 77%
rename from recipes-security/libgssglue/libgssglue_0.4.bb
rename to recipes-security/libgssglue/libgssglue_0.7.bb
index 3085ee6..26bd2f3 100644
--- a/recipes-security/libgssglue/libgssglue_0.4.bb
+++ b/recipes-security/libgssglue/libgssglue_0.7.bb
@@ -15,27 +15,24 @@ LICENSE = "BSD-3-Clause | HPND"
#Copyright 1995 by the Massachusetts Institute of Technology. HPND without Disclaimer
#Copyright 1993 by OpenVision Technologies, Inc. HPND
LIC_FILES_CHKSUM = "file://COPYING;md5=56871e72a5c475289c0d5e4ba3f2ee3a \
- file://src/g_accept_sec_context.c;beginline=3;endline=23;md5=8a7f4017cb7f4be49f8981cb8c472690 \
+ file://src/g_accept_sec_context.c;beginline=3;endline=23;md5=da8ca7a37bd26e576c23874d453751d2\
file://src/g_ccache_name.c;beginline=1;endline=32;md5=208d4de05d5c8273963a8332f084faa7 \
- file://src/oid_ops.c;beginline=1;endline=26;md5=1f194d148b396972da26759a8ec399f0 \
- file://src/oid_ops.c;beginline=378;endline=398;md5=e02c165cb8383e950214baca2fbd664b \
+ file://src/oid_ops.c;beginline=1;endline=26;md5=1f194d148b396972da26759a8ec399f0\
+ file://src/oid_ops.c;beginline=378;endline=398;md5=d77a5c03e91908fac453c08bbeaddce1\
"

-SRC_URI = "${DEBIAN_MIRROR}/main/libg/${BPN}/${BPN}_${PV}.orig.tar.bz2 \
+SRC_URI = "${DEBIAN_MIRROR}/main/libg/${BPN}/${BPN}_${PV}.orig.tar.gz \
file://libgssglue-canon-name.patch \
- file://libgssglue-gss-inq-cred.patch \
- file://libgssglue-mglueP.patch \
- file://libgssglue-g-initialize.patch \
- file://libgssglue-fix-CVE-2011-2709.patch \
"

-SRC_URI[md5sum] = "5ce81940965fa68c7635c42dcafcddfe"
-SRC_URI[sha256sum] = "bb47b2de78409f461811d0db8595c66e6631a9879c3621a35e4434b104ee52f5"
+SRC_URI[sha256sum] = "bcd618ae0bc69f12815d77295658a760e7edc20706b9a731a81da8993f5c970a"

-# gssglue can use krb5, spkm3... as gssapi library, configurable
-RRECOMMENDS:${PN} += "krb5"
+inherit autotools-brokensep

-inherit autotools
+do_configure:prepend() {
+ cd ${S}
+ ./bootstrap
+}

do_install:append() {
# install some docs
@@ -49,3 +46,6 @@ do_install:append() {
# change the libgssapi_krb5.so path and name(it is .so.2)
sed -i -e "s:/usr/lib/libgssapi_krb5.so:libgssapi_krb5.so.2:" ${D}${sysconfdir}/gssapi_mech.conf
}
+
+# gssglue can use krb5, spkm3... as gssapi library, configurable
+RRECOMMENDS:${PN} += "krb5"
--
2.25.1

LIC_FILES_CHKSUM changed do to yr change
Drop patch remove_linux_fs.patch

Signed-off-by: Armin Kuster <akuster808@...>
---
...{cryptmount_5.3.3.bb => cryptmount_6.0.bb} | 7 +++----
.../cryptmount/files/remove_linux_fs.patch | 19 -------------------
2 files changed, 3 insertions(+), 23 deletions(-)
rename recipes-security/cryptmount/{cryptmount_5.3.3.bb => cryptmount_6.0.bb} (82%)
delete mode 100644 recipes-security/cryptmount/files/remove_linux_fs.patch

diff --git a/recipes-security/cryptmount/cryptmount_5.3.3.bb b/recipes-security/cryptmount/cryptmount_6.0.bb
similarity index 82%
rename from recipes-security/cryptmount/cryptmount_5.3.3.bb
rename to recipes-security/cryptmount/cryptmount_6.0.bb
index 6741a5f..d712a61 100644
--- a/recipes-security/cryptmount/cryptmount_5.3.3.bb
+++ b/recipes-security/cryptmount/cryptmount_6.0.bb
@@ -1,13 +1,12 @@
SUMMARY = "Linux encrypted filesystem management tool"
HOMEPAGE = "http://cryptmount.sourceforge.net/"
-LIC_FILES_CHKSUM = "file://README;beginline=3;endline=4;md5=673a990de93a2c5531a0f13f1c40725a"
+LIC_FILES_CHKSUM = "file://README;beginline=3;endline=4;md5=dae0772f0ff46fd927e7fdb08af51b71"
LICENSE = "GPL-2.0-only"

-SRC_URI = "https://sourceforge.net/projects/cryptmount/files/${BPN}/${BPN}-5.3/${BPN}-${PV}.tar.gz \
- file://remove_linux_fs.patch \
+SRC_URI = "https://sourceforge.net/projects/cryptmount/files/${BPN}/${BPN}-${PV}/${BPN}-${PV}.tar.gz \
"

-SRC_URI[sha256sum] = "682953ff5ba497d48d6b13e22ca726c98659abd781bb8596bb299640dd255d9b"
+SRC_URI[sha256sum] = "86528a9175e1eb53f60613e3c3ea6ae6d69dbfe5ac2b53b2f58ba0f768371e7e"

inherit autotools-brokensep gettext pkgconfig systemd

diff --git a/recipes-security/cryptmount/files/remove_linux_fs.patch b/recipes-security/cryptmount/files/remove_linux_fs.patch
deleted file mode 100644
index 304b853..0000000
--- a/recipes-security/cryptmount/files/remove_linux_fs.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-# From glibc 2.36, <linux/mount.h> (included from <linux/fs.h>) and
-# <sys/mount.h> (included from glibc) are no longer compatible:
-# https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
-
-Upstream-Status: Pending
-Signed-off-by: Armin Kuster <akuster808@...>
-
-Index: cryptmount-5.3.3/cryptmount.c
-===================================================================
---- cryptmount-5.3.3.orig/cryptmount.c
-+++ cryptmount-5.3.3/cryptmount.c
-@@ -41,7 +41,6 @@
- #ifdef HAVE_SYSLOG
- # include <syslog.h>
- #endif
--#include <linux/fs.h> /* Beware ordering conflict with sys/mount.h */
-
-
- #include "armour.h"
--
2.25.1

Hey.. There
Hope all are doing well

I'm dealing with the swupdate with the my custom Yocto image created for STM32MP1 dk1 board
The intend is, to update the rootfs remotely

I have successfully integrated meta-swupdate layer with the custom Yocto image by adding the layers in to bblayer.conf file
The both layers meta-swupdate & meta-custom are parallel to each-others

To change the flags and setting with the swupdate, i have created the recipes-myswupdate file inside the meta-custom layers
The content of the recipes-myswupdate are as follows
.
└── swupdate
    ├── stm32mp1
    │   ├── 09-swupdate-args
    │   ├── defconfig
    │   ├── sw-description
    │   └── swupdate.cfg
    └── swupdate_%.bbappend


The content of the swupdate_%.bbappend are as follows

--------------------------------------------------------------------------------------

DESCRIPTION = "Example recipe generating SWU image"
SECTION = ""

LICENSE = ""

# Add all local files to be added to the SWU
# sw-description must always be in the list.
# You can extend with scripts or wahtever you need
SRC_URI += " \
    file://sw-description \
    file://09-swupdate-args \
    file://swupdate.cfg \
    "

# images to build before building swupdate image
IMAGE_DEPENDS = "core-image-full-cmdline virtual/kernel"

# images and files that will be included in the .swu image
SWUPDATE_IMAGES = "core-image-full-cmdline uImage"

# a deployable image can have multiple format, choose one
SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] = ".ubifs"
SWUPDATE_IMAGES_FSTYPES[uImage] = ".bin"

inherit swupdate


--------------------------------------------------------------------------------------------------------
I'm building the image by adding the machine name to update the image by following command
MACHINE=stm32mp1 bitbake swupdate-image

However, image unable!
As bitbake unable find the sw-description file
here, is the error log
Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'file://sw-description')


I'm new with the swupdate
I have a following concerns

a) is it right approach to add the separate recipes for the swupdate in to the meta-custom layers, which I'm doing now  ?

b) do i need to deal with the only recipes-support, which is the part of the meta-swupdate layer , instead of creating separate recipes in to meta-custom?

c) can any one help me with the right integration steps for the swupdate with yocto ?


for the instance, I'm following official guide from here

All suggestions & comments welcome 

Regards
Mahendra Sondagar

Fix typo in HOMEPAGE

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-mac/AppArmor/{apparmor_3.0.6.bb => apparmor_3.0.7.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename recipes-mac/AppArmor/{apparmor_3.0.6.bb => apparmor_3.0.7.bb} (98%)

diff --git a/recipes-mac/AppArmor/apparmor_3.0.6.bb b/recipes-mac/AppArmor/apparmor_3.0.7.bb
similarity index 98%
rename from recipes-mac/AppArmor/apparmor_3.0.6.bb
rename to recipes-mac/AppArmor/apparmor_3.0.7.bb
index 45f19d1..e7d677e 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.6.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.7.bb
@@ -5,7 +5,7 @@ DESCRIPTION = "user-space parser utility for AppArmor \
which is required to convert AppArmor text profiles into machine-readable \
policies that are loaded into the kernel for use with the AppArmor Linux \
Security Module."
-HOMEAPAGE = "http://apparmor.net/"
+HOMEPAGE = "http://apparmor.net/"
SECTION = "admin"

LICENSE = "GPL-2.0-only & GPL-2.0-or-later & BSD-3-Clause & LGPL-2.1-or-later"
@@ -22,7 +22,7 @@ SRC_URI = " \
file://0001-rc.apparmor.debian-add-missing-functions.patch \
"

-SRCREV = "822db765c6fa7f9de7233c4011254a82d4dafe76"
+SRCREV = "0ead606d9e608801f45e13a34358036135470729"
S = "${WORKDIR}/git"

PARALLEL_MAKE = ""
--
2.25.1

On Sun, 2022-09-25 at 10:53 +0200, Konrad Weihmann wrote:

Hi all,

On 24.09.22 04:02, Lee Chee Yang wrote:

Hi

We are pleased to announce the third milestone release for Yocto Project
4.1 (yocto-4.1_M3) is now available for download.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-4.1_M3
<http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-4.1_M3>

bitbake: 6424f4b7e9c1ba8db81346e8b3a806dd035d4551

meta-agl: e4ea839db9c26e78175d61388c5408a79f6927dc

meta-arm: 261263a6701ab3530ff997643d08da502222ac20

meta-aws: a16f35a73bff26d9506f519451dc75034211d61b

meta-gplv2: 43bf0e8d5985945d19d01f94bfbbda420c4435f3

I thought the agreement was to stop promoting meta-gplv2?
Still I find it listed here - it somehow implies that this is still
officially support, which everyone agreed it isn't

Can this be removed from the announcement template for the next
releases? - just to avoid any future misunderstandings

Someone needs to do the work involved and I guess that hasn't happened.
It isn't entirely simple as this does still exist in the other
releases.

Could you open a bug please so we don't forget this.

I still don't know who will do it but that way we at least remember we
need to.

Cheers,

Richard