When we have rm_work enabled all image tasks are built every time. This has
been happening since at least warrior and is still happening as of master
today (8fc19639f47b959a141dae231395bbababa644e1).
Steps to reproduce:
bitbake core-image-minimal
bitbake core-image-minimal
echo 'INHERIT +=
On Friday 22 May 2020 at 19:02:47 +0200, Jacob Kroon wrote:
> Hi Mike,
>
> On 5/22/20 10:13 AM, Mike Crowe via lists.openembedded.org wrote:
> > When we have rm_work enabled all image tasks are built every time. This has
> > been happening since at least warrior a
libnotify only requires gtk+3 for its tests. Let's disable them by
default.
Signed-off-by: Mike Crowe
---
meta/recipes-gnome/libnotify/libnotify_0.7.9.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
On Thursday 13 May 2021 at 17:06:23 +0100, Richard Purdie wrote:
> On Thu, 2021-05-13 at 16:43 +0200, Alexander Kanavin wrote:
> > On Thu, 13 May 2021 at 16:36, Mike Crowe via lists.openembedded.org <
> > yocto=mac.mcrowe@lists.openembedded.org> wrote:
> > > +P
Node modules may need to be built against multiple Node
versions. Setting nodedir in the NPM configuration stops older ways of
doing this, such as setting npm_config_target and npm_config_disturl,
from working.
Signed-off-by: Mike Crowe
---
meta/classes/npm.bbclass | 6 --
1 file changed, 4
libnotify only requires gtk+3 for its tests. Let's disable them by
default.
Signed-off-by: Mike Crowe
---
meta/recipes-gnome/libnotify/libnotify_0.7.9.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
On Thursday 13 May 2021 at 16:43:15 +0200, Alexander Kanavin wrote:
> On Thu, 13 May 2021 at 16:36, Mike Crowe via lists.openembedded.org mac.mcrowe@lists.openembedded.org> wrote:
>
> > +PACKAGECONFIG[gtk+] = "--enable-tests,--disable-tests,,gtk+3"
> >
>
libnotify only requires gtk+3 for its tests. Let's disable them by
default and only enable them if "tests" is in PACKAGECONFIG. If gtk+3 is
not available then we need to declare the dependency on gdk-pixbuf
explicitly.
It looks like the tests genuinely do need some sort of desktop
environment to
On Wednesday 07 July 2021 at 13:25:17 +0100, Richard Purdie wrote:
> On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via lists.openembedded.org
> wrote:
> > We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files and
> > relying on the automatically generated recomm
We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files and
relying on the automatically generated recommends to cause them to be
installed in the image. This works well for most packages, but fails for
packages where we only install package created using PACKAGES_DYNAMIC.
For
Richard Purdie wrote:
> > > > On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via
> > > > lists.openembedded.org wrote:
> > > > > We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files
> > > > > and
> > > > > relying on t
On Wednesday 07 July 2021 at 18:06:07 +0100, Richard Purdie wrote:
> This changes behaviour when LICENSE_CREATE_PACKAGE is in use. Packages
> no longer have RRECOMMENDS adding to them.
>
> It was highlighted that this doesn't apply to PACKAGES_DYNAMIC, nor can
> it easily be made to do so. There
On Thursday 08 July 2021 at 09:33:12 +0100, Richard Purdie wrote:
> On Thu, 2021-07-08 at 09:26 +0100, Mike Crowe wrote:
> > On Wednesday 07 July 2021 at 18:06:07 +0100, Richard Purdie wrote:
> > > This changes behaviour when LICENSE_CREATE_PACKAGE is in use. Packages
> > > no longer have
Installing license packages is similar to installing -dev or -dbg
packages, so let's invent a "lic-pkgs" IMAGE_FEATURE that does so and
document it in core-image.bbclass.
This image feature only works if LICENSE_CREATE_PACKAGE is set, so
refuse to generate an image if the lic-pkgs feature is
Take patches from Ubuntu 20.04 7.68.0-1ubuntu2.5, which is close enough
that they apply without conflicts.
Signed-off-by: Mike Crowe
---
.../curl/curl/CVE-2021-22876.patch| 59 +++
.../curl/curl/CVE-2021-22890.patch| 464 ++
In e9e5744ba8b0d43c8b874d365f83071ce20bf0a1, Khem Raj wrote:
> OE does not use the traditional /usr/lib/gcc prefix to store
> gcc-runtime it basically is moved into libdir, however some newer
> files were installed by newer versions of gcc especially libgomp (
> omp.h openacc.h ) into gcclibdir,
NPM shrinkwrap files need to stay in SRC_URI even when using
externalsrc so that npm_do_fetch can run to fetch the required
dependencies.
Signed-off-by: Mike Crowe
---
meta/classes/externalsrc.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/externalsrc.bbclass
In e9e5744ba8b0d43c8b874d365f83071ce20bf0a1, Khem Raj wrote:
> OE does not use the traditional /usr/lib/gcc prefix to store
> gcc-runtime it basically is moved into libdir, however some newer
> files were installed by newer versions of gcc especially libgomp (
> omp.h openacc.h ) into gcclibdir,
On Saturday 27 February 2021 at 16:02:18 +0100, Alexandre Belloni wrote:
> Hello,
>
> On 25/02/2021 17:36:53+0000, Mike Crowe via lists.openembedded.org wrote:
> > In e9e5744ba8b0d43c8b874d365f83071ce20bf0a1, Khem Raj wrote:
> > > OE does not use the traditional /usr
We have a class that stores the files in ${DL_DIR} that are required for
each recipe so they can be made available in ${DL_DIR} later. This is a bit
like archiver.bbclass, but not quite the same.
I'm having trouble making our class work for recipes that use the post
refactor[1] npm.bbclass and
On Tuesday 06 April 2021 at 13:53:42 +0100, Mike Crowe via
lists.openembedded.org wrote:
> Take patches from Ubuntu 20.04 7.68.0-1ubuntu2.5, which is close enough
> that they apply without conflicts.
>
> Signed-off-by: Mike Crowe
> ---
> .../curl/curl/CVE-2021-22876.patc
On Thursday 12 August 2021 at 08:46:08 +0100, Mike Crowe via
lists.openembedded.org wrote:
> On Wednesday 11 August 2021 at 22:38:23 +0100, Richard Purdie wrote:
> > On Wed, 2021-08-11 at 16:58 +0100, Mike Crowe via lists.openembedded.org
> > wrote:
> > > When running the
When running the test suite on my Debian 11 box I see many occurrences
of:
unknown fcntl argument 1032, assuming long argument.
(for example from test-execl.sh.)
It appears that this is F_GETPIPE_SZ and it takes no arguments. Let's
add it and the corresponding F_SETPIPE_SZ too to avoid the
On Friday 03 September 2021 at 13:55:21 +0200, Martin Jansa wrote:
> * the output is shown 3 times with default configuration and 5 times when
> --verbose
> is being used with knotty, there might be other use-cases where we actually
> need
> this, but until the logging is resolved better,
On Monday 06 September 2021 at 17:37:14 +0100, Mike Crowe via
lists.openembedded.org wrote:
> On Friday 13 August 2021 at 12:05:09 +0100, Mike Crowe via
> lists.openembedded.org wrote:
> > When running the test suite on my Debian 11 box I see many occurrences
> > of:
>
On Friday 13 August 2021 at 12:05:09 +0100, Mike Crowe via
lists.openembedded.org wrote:
> When running the test suite on my Debian 11 box I see many occurrences
> of:
>
> unknown fcntl argument 1032, assuming long argument.
>
> (for example from test-execl.sh
On Wednesday 11 August 2021 at 18:13:54 +0100, Mike Crowe via
lists.openembedded.org wrote:
> It just so happens that my /home/mac and /home directories have the same
> inode number but on different filesystems.
>
> This means that test-openat fails with "Recursion faile
Of course, the subject line ought to say CVE-2021-22947 rather than
CVE-22947. :(
Mike.
On Friday 17 September 2021 at 17:14:33 +0100, Mike Crowe via
lists.openembedded.org wrote:
> curl v7.79.0 contained fixes for three CVEs:
>
> The description of CVE-2021-22945[1] contains:
>
curl v7.79.0 contained fixes for three CVEs:
The description of CVE-2021-22945[1] contains:
> This flaw was introduced in commit 2522903b79 but since MQTT support
> was marked 'experimental' then and not enabled in the build by default
> until curl 7.73.0 (October 14, 2020) we count that as the
Our CI Dunfell builds started failing during image creation with pseudo
aborts like:
path mismatch [2 links]: ino 123107550 db
'/.../build/tmp-glibc/work/mymachine-oe-linux/myimage/1.0-r2/oe-rootfs-repo/mymachine/mypackage-dbg_1.0-r7_mymachine.ipk'
req '/.../build/mymachine-root/usr/bin'.
On Monday 09 August 2021 at 09:09:16 -0500, Seebs wrote:
> On Mon, 9 Aug 2021 13:19:51 +0100
> "Mike Crowe via lists.openembedded.org"
> wrote:
>
> > Cleaning the work directory makes the problem go away because that
> > deletes the pseudo databases.
When running the test suite on my Debian 11 box I see many occurrences
of:
unknown fcntl argument 1032, assuming long argument.
(for example from test-execl.sh.)
It appears that this is F_GETPIPE_SZ and it takes no arguments. Let's
add it to avoid the warning messages.
I could add
curl v7.78 contained fixes for five CVEs:
CVE-2021-22922[1] and CVE-2021-22923[2] are only present when support
for metalink is enabled. EXTRA_OECONF contains "--without-libmetalink"
so these fixes are unnecessary.
CVE-2021-22926[3] only affects builds for MacOS.
CVE-2021-22924[4] and
On Wednesday 04 August 2021 at 06:44:51 -1000, Steve Sakoman wrote:
> On Tue, Aug 3, 2021 at 10:11 PM Mike Crowe via lists.openembedded.org
> wrote:
> >
> > curl v7.78 contained fixes for five CVEs:
> >
> > CVE-2021-22922 and CVE-2021-22923 are only present
curl v7.78 contained fixes for five CVEs:
CVE-2021-22922 and CVE-2021-22923 are only present when support for
metalink is enabled. EXTRA_OECONF contains "--without-libmetalink" so
these fixes are unnecessary.
CVE-2021-22926 only affects builds for MacOS.
CVE-2021-22924 and CVE-2021-22925 are
On Wednesday 04 August 2021 at 08:05:27 -1000, Steve Sakoman wrote:
> On Wed, Aug 4, 2021 at 7:27 AM Steve Sakoman via
> lists.openembedded.org
> wrote:
> >
> > On Wed, Aug 4, 2021 at 7:06 AM Mike Crowe via lists.openembedded.org
> > wrote:
> > >
> >
On Thursday 05 August 2021 at 05:33:44 -1000, Steve Sakoman wrote:
> From: Mike Crowe
>
> curl v7.78 contained fixes for five CVEs:
>
> CVE-2021-22922[1] and CVE-2021-22923[2] are only present when support
> for metalink is enabled. EXTRA_OECONF contains "--without-libmetalink"
> so these fixes
On Wednesday 11 August 2021 at 13:36:23 +0200, Alexander Kanavin wrote:
> I too do not think this is sufficiently explained. All of python ptests
> pass, so there needs to be a demonstrator of incorrect behavior, or let's
> just revert it.
I agree regarding the lack of explanation. However, even
On Monday 17 May 2021 at 21:25:06 +0200, Philip Lorenz wrote:
> Commit 60e25a36558f1f07dcce1a044fe976b475bec42b started dereferencing
> the "path" parameter which for some functions is annotated with the
> "nonnull" attribute. While the commit explicitly checks for NULL
> pointers before
On Wednesday 11 August 2021 at 18:32:31 +0200, Alexander Kanavin wrote:
> On Wed, 11 Aug 2021 at 18:14, Mike Crowe wrote:
> > I agree regarding the lack of explanation. However, even if the problem is
> > real (which it looks like it is based on
> > https://bugs.python.org/issue41710)
> > then it
It just so happens that my /home/mac and /home directories have the same
inode number but on different filesystems.
This means that test-openat fails with "Recursion failed!" even when run
without pseudo.
Let's consider both the device number and the inode number before
assuming that we've found
On Wednesday 11 August 2021 at 18:41:32 +0200, Philip Lorenz wrote:
> Adding this test case was erroneously omitted in
> 7c722296879906fe093e1e7c4b7537e150d492cd.
>
> Signed-off-by: Philip Lorenz
> ---
> test/test-statx.c | 20
> test/test-statx.sh | 6 ++
> 2 files
On Wednesday 11 August 2021 at 22:38:23 +0100, Richard Purdie wrote:
> On Wed, 2021-08-11 at 16:58 +0100, Mike Crowe via lists.openembedded.org
> wrote:
> > When running the test suite on my Debian 11 box I see many occurrences
> > of:
> >
> > unknown fcntl argumen
Use the same WARN_WA and ERROR_QA variables as insane.bbclass to allow
individual recipes, the distro or other configuration to determine
whether a missing licence should be treated as a warning (as it is now)
or as an error.
oe.qa.handle_error isn't immediately fatal, so track the overall sanity
Extract package_qa_write_error, package_qa_handle_error and
package_qa_add_message functions from insane.bbclass to lib/oe/qa.py and
drop the package_qa_ prefixes. Add import statements and convert callers
to use oe.qa. prefix.
Inspired by discussion resulting from
We're using:
EXTRA_IMAGE_FEATURES += "lic-pkgs"
to install the corresponding licence packages for all the packages
installed in our image. This works very well for binaries and dynamic
libraries. However, I've recently noticed that it doesn't install licence
files for any static or header-only
Use mechanism inspired by insane.bbclass to allow individual recipes or
other configuration to determine whether a missing licence should be
treated as a warning (as it is now) or as an error. This is controlled
by whether the error class is in WARN_LICENSE or ERROR_LICENSE.
Use bb.fatal in the
On Saturday 09 October 2021 at 15:51:35 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org > c...@lists.openembedded.org> On Behalf Of Mike Crowe via
> > lists.openembedded.org
> > Sent: den 8 oktober 2
On Tuesday 12 October 2021 at 14:21:05 +0100, Richard Purdie wrote:
> On Sun, 2021-10-10 at 18:20 +0100, Mike Crowe via lists.openembedded.org
> wrote:
> > Use mechanism inspired by insane.bbclass to allow individual recipes or
> > other configuration to determine whether a miss
Use mechanism inspired by insane.bbclass to allow individual recipes or
other configuration to determine whether a missing licence should be
treated as a warning (as it is now) or as an error. This is controlled
by whether the error class is in WARN_LICENSE or ERROR_LICENSE.
Use bb.fatal in the
On Wednesday 13 October 2021 at 11:48:05 +0100, Mike Crowe wrote:
> Use the same WARN_WA and ERROR_QA variables as insane.bbclass to allow
> individual recipes, the distro or other configuration to determine
> whether a missing licence should be treated as a warning (as it is now)
> or as an
On Thursday 14 October 2021 at 17:54:18 +0100, Richard Purdie wrote:
> On Thu, 2021-10-14 at 17:42 +0100, Mike Crowe via lists.openembedded.org
> wrote:
> > On Wednesday 13 October 2021 at 11:48:05 +0100, Mike Crowe wrote:
> > > Use the same WARN_WA and ERROR_QA variab
On Wednesday 13 October 2021 at 13:32:03 -0700, Khem Raj wrote:
> On Wed, Oct 13, 2021 at 7:06 AM Mike Crowe via lists.openembedded.org mcrowe@lists.openembedded.org> wrote:
>
> > We're using:
> >
> > EXTRA_IMAGE_FEATURES += "lic-pkgs"
> >
> &
On Thursday 14 October 2021 at 22:48:07 +0100, Richard Purdie wrote:
> On Thu, 2021-10-14 at 18:09 +0100, Mike Crowe wrote:
> > On Thursday 14 October 2021 at 17:54:18 +0100, Richard Purdie wrote:
> > > On Thu, 2021-10-14 at 17:42 +0100, Mike Crowe via lists.openembedde
Extract package_qa_write_error, package_qa_handle_error and
package_qa_add_message functions from insane.bbclass to lib/oe/qa.py and
drop the package_qa_ prefixes.
Update various bbclasses to use the new functions. No import is required
since base.bbclass puts oe.qa in OE_IMPORTS.
Stop requiring
Use the same WARN_WA and ERROR_QA variables as insane.bbclass to allow
individual recipes, the distro or other configuration to determine
whether the various detected license errors should be treated as a
warning (as now) or as an error.
oe.qa.handle_error isn't immediately fatal, so
On Friday 15 October 2021 at 15:09:08 +0100, Richard Purdie wrote:
> On Fri, 2021-10-15 at 14:59 +0100, Mike Crowe via lists.openembedded.org
> wrote:
> > Extract package_qa_write_error, package_qa_handle_error and
> > package_qa_add_message functions from insane.bbcla
Extract package_qa_write_error, package_qa_handle_error and
package_qa_add_message functions from insane.bbclass to lib/oe/qa.py and
drop the package_qa_ prefixes.
Update various bbclasses to use the new functions. No import is required
since base.bbclass puts oe.qa in OE_IMPORTS.
Stop requiring
Use the same WARN_WA and ERROR_QA variables as insane.bbclass to allow
individual recipes, the distro or other configuration to determine
whether the various detected license errors should be treated as a
warning (as now) or as an error.
oe.qa.handle_error isn't immediately fatal, so
In 526bdd88ccd758204452579333ba188e29270bde the imageType loop in
kernel_do_deploy was changed to use KERNEL_IMAGETYPE_FOR_MAKE rather
than KERNEL_IMAGETYPES. This broke the special handling for fitImage
immediately below because KERNEL_IMAGETYPE_FOR_MAKE never contains
fitImage.
It has always
navin wrote:
> I think you do need to modify oe-core unfortunately, like is done for other
> drivers:
>
> PACKAGECONFIG[etnaviv] = ""
> GALLIUMDRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> ',etnaviv', '', d)}"
>
> Alex
>
> On Wed, 1 Dec
I'm building for a specific chip and therefore don't wish to waste time and
electricity building and disk space on the target installing unwanted mesa
drivers. However, mesa.inc contains:
GALLIUMDRIVERS = "swrast"
GALLIUMDRIVERS:x86-x32 = ""
GALLIUMDRIVERS:append:x86:class-target =
the drivers they require. This would seem
> > to be worse than my GALLIUMDRIVERS_DEFAULT suggestion. :(
> >
> > Have I misunderstood you, or is there a better way?
> >
> > Thanks.
> >
> > Mike.
> >
> > On Wednesday 01 December 2021 at 18:21:44 +0100, Alexander Ka
On Wednesday 01 December 2021 at 14:18:19 -0500, Justin Bronder wrote:
> On 01/12/21 16:43 +0000, Mike Crowe via lists.openembedded.org wrote:
> > I'm building for a specific chip and therefore don't wish to waste time and
> > electricity building and disk space on the target inst
PACKAGE_SNAP_LIB_SYMLINKS was added[1] originally to OpenEmbedded in
2008 and then to oe-core in 2011[2] but appears to have evaded
documentation throughout that time. Let's add something that at least
gives some clue as to what it does.
Signed-off-by: Mike Crowe
Signed-off-by: Phil Blundell
PACKAGE_SNAP_LIB_SYMLINKS renames libraries based on their SONAME so
that they can be found directly rather than going via symlinks that
would be created by ldconfig. For example, without
PACKAGE_SNAP_LIB_SYMLINKS in ${libdir} we have:
libharfbuzz.so.0 -> libharfbuzz.so.0.20600.4
On Wednesday 07 July 2021 at 18:06:07 +0100, Richard Purdie wrote:
> This changes behaviour when LICENSE_CREATE_PACKAGE is in use. Packages
> no longer have RRECOMMENDS adding to them.
>
> It was highlighted that this doesn't apply to PACKAGES_DYNAMIC, nor can
> it easily be made to do so. There
On Wednesday 13 April 2022 at 06:02:22 -1000, Steve Sakoman wrote:
> Both runs completed and I'm still seeing success without the zlib patch:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5069
>
> and failure with the patch:
>
>
From: Mike Crowe
Take the patch from the source for Debian's glibc 2.31-13+deb11u7
package, the changelog for which starts with:
glibc (2.31-13+deb11u7) bullseye-security; urgency=medium
* debian/patches/any/local-CVE-2023-4911.patch: Fix a buffer overflow in the
dynamic loader's
From: Mike Crowe
Backporting this change required tweaking the error value since the
two-level CURLE_PROXY error reporting was introduced after curl
7.69.1. The test required some tweaks to not rely on more-recent
improvements to the test infrastructure too.
Signed-off-by: Mike Crowe
---
From: Mike Crowe
Take patch from Debian 7.64.0-4+deb10u7.
Signed-off-by: Mike Crowe
---
.../curl/curl/CVE-2023-38546.patch| 131 ++
meta/recipes-support/curl/curl_7.69.1.bb | 1 +
2 files changed, 132 insertions(+)
create mode 100644
From: Mike Crowe
Take patch from Debian 7.64.0-4+deb10u7.
Signed-off-by: Mike Crowe
CVE: CVE-2023-38546
---
.../curl/curl/CVE-2023-38546.patch| 132 ++
meta/recipes-support/curl/curl_7.69.1.bb | 1 +
2 files changed, 133 insertions(+)
create mode 100644
From: Mike Crowe
Backporting this change required tweaking the error value since the
two-level CURLE_PROXY error reporting was introduced after curl
7.69.1. The test required some tweaks to not rely on more-recent
improvements to the test infrastructure too.
Signed-off-by: Mike Crowe
CVE:
On Thursday 05 October 2023 at 11:16:29 -0400, Scott Murray wrote:
> Debian's page at https://security-tracker.debian.org/tracker/CVE-2023-4911
> indicates at the bottom that they're only vulnerable on their 2.31 based
> versions because they backported the change that introduced the
>
On Thursday 05 October 2023 at 04:17:08 -1000, Steve Sakoman wrote:
> Hmmm ... does this build for you?
Yes, on top of 0111b5b152c1bcff0ab26cf8632ca9002237f070 (current HEAD of
openembedded-core dunfell branch.)
> I'm getting:
>
> ERROR: glibc-2.31+gitAUTOINC+2d4f26e5cf-r0 do_patch: Applying
On Thursday 05 October 2023 at 09:25:44 -1000, Steve Sakoman wrote:
> Strange! Nothing that should affect glibc. I'm applying to the head
> of stable/dunfell-nut:
>
> https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut
All my fault.
I managed to lose my
From: Mike Crowe
Take the patch from the source for Debian's glibc 2.31-13+deb11u7
package, the changelog for which starts with:
glibc (2.31-13+deb11u7) bullseye-security; urgency=medium
* debian/patches/any/local-CVE-2023-4911.patch: Fix a buffer overflow in the
dynamic loader's
I'm trying to work out how we can make use of devtool to make our lives
easier during development. In general it seems to work very well, but the
way that it modifies bblayers.conf to add an absolute path to the workspace
directory to BBLAYERS is incompatible with that file being held in a Git
On Wednesday 18 October 2023 at 17:47:50 +0200, Julien Stephan wrote:
> Le mer. 18 oct. 2023 à 16:29, Mike Crowe via lists.openembedded.org
> a écrit :
> >
> > I'm trying to work out how we can make use of devtool to make our lives
> > easier during development. In gener
On Wednesday 18 October 2023 at 09:19:32 -0700, Khem Raj wrote:
> On Wed, Oct 18, 2023 at 7:29 AM Mike Crowe via lists.openembedded.org
> wrote:
> >
> > I'm trying to work out how we can make use of devtool to make our lives
> > easier during development. In general it
On Thursday 19 October 2023 at 14:51:56 +0200, Alexander Kanavin wrote:
> On Thu, 19 Oct 2023 at 14:33, Mike Crowe via lists.openembedded.org
> wrote:
> > We do need to modify bblayers.conf from time to time to add and remove
> > layers.
> >
> > Using templates m
On Wednesday 27 April 2022 at 11:40:49 +0100, Richard Purdie wrote:
> As far as I know, we don't use LSB_DISTRO_ADJUST in core at all. I suspect it
> should really probably be added to the lsb.py function in most cases. Is there
> any documentation or other info about when it should be applied and
82 matches
Mail list logo
