am i right in assuming that stuff like this in ptest.bbclass:
do_configure_ptest() {
:
}
can be replaced by using the "noexec" flag?
if so, then this in base.bbclass looks a bit strange:
do_build[noexec] = "1"
do_build[recrdeptask] += "do_deploy"
do_build () {
:
On Sat, 29 May 2021, Khem Raj wrote:
> Hi Robert
>
> On Sat, May 29, 2021 at 2:29 PM Robert P. J. Day
> wrote:
> >
> >
> > (yet another in an endless series of dumb questions as i get asked
> > about these things by colleagues and realize i don't kno
(yet another in an endless series of dumb questions as i get asked
about these things by colleagues and realize i don't know the answer.)
can someone clarify the oddity of recipes whose source contains a
CMakeLists.txt file at the top, but whose recipe does not "inherit
cmake"?
example:
On Fri, 28 May 2021, Quentin Schulz wrote:
... big snip ...
> ${B} = ${S} by default, so that might explain why it works without
> externalsrc being inherited.
>
> You can see in the makefile that this is assumed. Only the install tasks
> are installing somewhere else (DESTDIR), c.f.
>
On Fri, 28 May 2021, Quentin Schulz wrote:
> On Fri, May 28, 2021 at 11:15:40AM -0400, Robert P. J. Day wrote:
> > On Fri, 28 May 2021, Quentin Schulz wrote:
> >
> > > On Fri, May 28, 2021 at 10:47:30AM -0400, Robert P. J. Day wrote:
> > > > On Fr
On Fri, 28 May 2021, Quentin Schulz wrote:
> On Fri, May 28, 2021 at 10:47:30AM -0400, Robert P. J. Day wrote:
> > On Fri, 28 May 2021, Quentin Schulz wrote:
> >
> > > On Fri, May 28, 2021 at 09:57:26AM -0400, Robert P. J. Day wrote:
> > > > On Fr
On Fri, 28 May 2021, Quentin Schulz wrote:
> On Fri, May 28, 2021 at 09:57:26AM -0400, Robert P. J. Day wrote:
> > On Fri, 28 May 2021, Quentin Schulz wrote:
> >
> > > On Fri, May 28, 2021 at 08:51:51AM -0400, Robert P. J. Day wrote:
> > > >
> > > >
On Fri, 28 May 2021, Quentin Schulz wrote:
> On Fri, May 28, 2021 at 08:51:51AM -0400, Robert P. J. Day wrote:
> >
> > as a short followup to my earlier note about creating a bunch of
> > externalsrc-based recipes to demonstrate their proper structure, it's
> > e
On Fri, 28 May 2021, Quentin Schulz wrote:
> On Fri, May 28, 2021 at 08:51:51AM -0400, Robert P. J. Day wrote:
> >
> > as a short followup to my earlier note about creating a bunch of
> > externalsrc-based recipes to demonstrate their proper structure, it's
> > e
as a short followup to my earlier note about creating a bunch of
externalsrc-based recipes to demonstrate their proper structure, it's
easy to add the recipe files to a layer, but i then realized i needed
to figure out where to put the corresponding source, and how i would
refer to it with the
the scenario: existing codebase where lots of (Makefile-based)
source components each exist in their own local directory and are,
little by little, being transmogrified into OE recipes but in a very
cumbersome way.
almost all of those source directories are massively contaminated
with
On Fri, 28 May 2021, Michael Opdenacker wrote:
> Hello,
>
> Adding this docs@ mailing list too, because I have a documentation
> related question...
>
> On 5/26/21 7:10 PM, Richard Purdie wrote:
> > On Wed, 2021-05-26 at 18:30 +0200, Alexander Kanavin wrote:
> >> What happens if XZ_THREADS isn't
On Tue, 18 May 2021, Andre McCurdy wrote:
> On Tue, May 18, 2021 at 10:00 AM Robert P. J. Day
> wrote:
> > muh colleague just presented me with the following ... until
> > recently, build was properly producing bootable image while
> > simultaneously creating compa
muh colleague just presented me with the following ... until
recently, build was properly producing bootable image while
simultaneously creating companion debugfs. so far, so good.
then enough packages were added so that image didn't fit in target
eMMC, so decision was made to strip bins and
Alphabetical order is always good.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 4fa47d88e5..f451ba6a47 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -173,25 +173,25 @@ DATETIME = "${DATE}${TIME}"
# pyt
i just got burned by taking the very advice i'd been giving out for
years. when people ask about how to add new image features to their
images, they point to IMAGE_FEATURES and ask if that's the way to do
it, as in one of:
IMAGE_FEATURES += ...
IMAGE_FEATURES_append = ...
well, ok, i say,
On Fri, 14 May 2021, Konrad Weihmann wrote:
> On 14.05.21 13:16, Robert P. J. Day wrote:
> >
> >pretty sure i know the answer to this one, but was asked the
> > other day and wanted to make sure. in order to speed up the normal
> > OE build, someone sugge
pretty sure i know the answer to this one, but was asked the other
day and wanted to make sure. in order to speed up the normal OE build,
someone suggested bypassing the creation of packages that weren't
going to be relevant, such as -dev, -doc and so on -- the idea was
that that could make a
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 4b48cdbb65..ad9fd77c8b 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -167,7 +167,7 @@ class Rootfs(object, metaclass=ABCMeta):
pass
bb.utils.rename
couple colleagues asked me about the details of how the debug
filesystem is created, and since i wasn't entirely clear on the
mechanics of it myself, i thought i'd dig into it, so a couple
preliminary questions to make sure i'm on the right track.
trivially, if you want that companion
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 353cc67175..67603d958d 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -38,7 +38,7 @@ IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs
On Fri, 7 May 2021, Andre McCurdy wrote:
> Didn't we discuss exactly this (ie the difference between a pure SDK
> recipe such as meta-toolchain and the populate_sdk task of an image
> recipe) a couple of weeks ago?
yes, i just got confused as i was digging into eSDK and mixed the
two. it's
On Fri, 7 May 2021, Quentin Schulz wrote:
> Hi Robert,
>
> No SDK expert here, so as usual, to be taken with a grain of salt.
>
> On Fri, May 07, 2021 at 09:11:37AM -0400, Robert P. J. Day wrote:
> >
> > almost certainly a silly question as i'm still poring over th
On Fri, 7 May 2021, Quentin Schulz wrote:
> Hi Robert,
>
> No SDK expert here, so as usual, to be taken with a grain of salt.
>
> On Fri, May 07, 2021 at 09:11:37AM -0400, Robert P. J. Day wrote:
> >
> > almost certainly a silly question as i'm still poring over th
almost certainly a silly question as i'm still poring over the
mechanics of standard SDK creation, but if i define a perfectly normal
image, then build the corresponding SDK with:
$ bitbake -c populate_sdk my_image
is the resulting SDK populated based on the entire contents of the
target
As is the pattern with all lists, put the list of MIRRORs in
alphabetical order, and add an entry for SAMBA_MIRROR as it appears in
the samba recipe from the meta-networking layer.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index
On Tue, 4 May 2021, Richard Purdie wrote:
> On Tue, 2021-05-04 at 16:31 -0400, Robert P. J. Day wrote:
> > On Tue, 4 May 2021, Richard Purdie wrote:
> >
> > > On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> > > > more nitpickery, but
On Tue, 4 May 2021, Richard Purdie wrote:
> On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> > more nitpickery, but i note in OE's current bitbake.conf the
> > initially odd definitions:
> >
> > FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
> &
more nitpickery, but i note in OE's current bitbake.conf the
initially odd definitions:
FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
... snip ...
FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
i say "odd" since someone perusing that file could be confused, first,
that that "-bin"
On Mon, 3 May 2021, Denys Dmytriyenko wrote:
... snip ...
> By default, ${PN}-dev RDEPENDS on ${PN} automatically, if not changed:
>
> https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n321
yup, that's the line i was looking for, thanks.
rday
-=-=-=-=-=-=-=-=-=-=-=-
On Mon, 3 May 2021, Andre McCurdy wrote:
> On Mon, May 3, 2021 at 7:55 AM Robert P. J. Day wrote:
> >
> > colleague asks a simple question (and i'm not in front of my dev
> > box at the moment so i can't verify what i'm about to suggest):
> > how to add the he
colleague asks a simple question (and i'm not in front of my dev box
at the moment so i can't verify what i'm about to suggest): how to add
the header files in a given "-dev" package to the host component of
the SDK?
i haven't spent a lot of time messing with SDKs (that is about to
change),
On Wed, 21 Apr 2021, Denys Dmytriyenko wrote:
> On Wed, Apr 21, 2021 at 07:44:45AM -0400, Robert P. J. Day wrote:
> >
> > based on my recommendation, colleague created a local source mirror
> > to start collecting tarballs so as to minimize amount of downloading
> >
based on my recommendation, colleague created a local source mirror
to start collecting tarballs so as to minimize amount of downloading
for various builds. names of tarballs that correspond to fixed
(versioned) tarballs was fairly obvious, but he got stuck trying to
local source mirror a
i've run across a rather odd scenario wherein part of the build of a
valid OE/YP layer is reaching across the filesystem and explicitly,
for a number of related recipes, running "make -C " and "make -C
-- that is, do_compile() for that recipe is appended with
these calls to the "make" command
just noticed the following (probably harmless) inconsistency in
oe-core/meta:
classes/manpages.bbclass:pkg_postinst_append_${MAN_PKG} () {
classes/manpages.bbclass:pkg_postrm_append_${MAN_PKG} () {
recipes-core/dropbear/dropbear.inc:pkg_postrm_append_${PN} () {
i've seen a number of recipes bounce around between these variations
of adding an entire directory to a package's files:
FILES_${PN} = "dir"
FILES_${PN} = "dir/"
FILES_${PN} = "dir/*"
first, i'm assuming all of the above mean exactly the same thing, yes?
that the entire directory,
sort of a followup to something richard purdie wrote recently
regarding BBFILE_PATTERN. these days, the standard for any layer is to
define, in layer.conf, the following:
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
... snip ...
On Sun, 4 Apr 2021, Alejandro Hernandez Samaniego wrote:
> On 4/2/2021 12:13 PM, Robert P. J. Day wrote:
>
> also, i'm curious about the difference between these two image
> recipes:
>
> core-image-minimal-initramfs.bb:export IMAGE_BASENAME =
> "${MLPREFIX}core-image
first, given that the default value of IMAGE_BASENAME is simply the
package name, then i'm assuming that things like this in
core-image-tiny-initramfs.bb:
export IMAGE_BASENAME = "core-image-tiny-initramfs"
are superfluous, yes?
also, i'm curious about the difference between these two
On Thu, 1 Apr 2021, Andre McCurdy wrote:
> On Thu, Apr 1, 2021 at 8:29 AM Steve Sakoman wrote:
> >
> > From: "Robert P. J. Day"
> >
> > There is apparently no functional value to "PROVIDES" lines
> > anymore in packagegroup recipe fi
recently, i've run across a couple layers based on pretty much
up-to-date OE/YP, where fixed files are being added to a package via
assignments like this:
FILES_${PN} += "/data"
i already know that's a bad idea, but i'm curious as to what build
errors might occur when trying something
On Fri, 26 Mar 2021, Andre McCurdy wrote:
... snip ...
> PROVIDES sets up a name which can be used as DEPENDS (ie a build
> time dependency) in other recipes. If PROVIDES contains more than
> one name, they all just become aliases for each other.
>
> Since packagegroup recipes only define run
There is apparently no functional value to "PROVIDES" lines anymore in
packagegroup recipe files, so remove the lonely couple of examples
left.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb
b/meta/recipes-core/packagegroups/pa
On Sat, 27 Mar 2021, Andre McCurdy wrote:
> On Sat, Mar 27, 2021 at 3:31 AM Robert P. J. Day
> wrote:
> > On Fri, 26 Mar 2021, Andre McCurdy wrote:
> > > On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day
> > > wrote:
> > > > what should be easy que
On Fri, 26 Mar 2021, Andre McCurdy wrote:
> On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day
> wrote:
> >
> > what should be easy questions about packagegroups, inspired by my
> > running across some puzzling packagegroup recipes in my travels
> > recently. (i'll
what should be easy questions about packagegroups, inspired by my
running across some puzzling packagegroup recipes in my travels
recently. (i'll start with examples out of oe-core).
first, as with any other recipe, given a "trivial" packagegroup
like, say,
On Thu, 25 Mar 2021, Mike Looijmans wrote:
> I for one use a whitelist env vars daily, both hobby and work.
>
> We tend to build for multiple machines, so in general we'd have
> something like this running on the build server:
>
> for machine in mach1 mach2 mach3 mach4 ... mach40
> do
>
kind of a philosophical question, but i'm having a discussion with
some new colleagues about how to customize an OE (actually, wind river
linux) build, and these colleagues have, until now, used (whitelisted)
environment variables to pass info to the build, that info being used
to specify
HOSTTOOLS_DIR contains symlinks to host tools, not copies
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index ecd4d1638e..fa88e7be4d 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -476,7 +476,7 @@ export PATH
# Build
actually a 2-part post, so bear with me, the first part is not all
that exciting.
continuing my travels through a proprietary layer i've been handed,
i can across a recipe that redefined its PACKAGES in an obviously
strange way:
# Packages to consider
PACKAGES = "${PN} ${PN}-dbg
more a style thing than anything else, but i've noticed in the layer
i'm perusing a number of examples of the form:
do_something() {
... doing something ...
}
do_unpack[postfuncs] += "do_something"
i mention this only because my preference is to reserve the "do_"
prefix for
once again into the code base i'm poring over, and this time, it's
about defining proprietary licenses for internal recipes.
turns out the meta-boundary layer has a nice example of what i'm
sure is the right way to do this (i've rarely had to do this myself),
wherein the layer's "layer.conf"
On Tue, 23 Mar 2021, Damian Wrobel wrote:
> On Mon, 22 Mar 2021 20:27:42 +0100 Andre McCurdy
> wrote
> > On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day
> wrote:
> > > (warning: i've just been handed an existing OE code base, and i'm
> > >
On Tue, 23 Mar 2021, Quentin Schulz wrote:
> On Mon, Mar 22, 2021 at 03:18:30PM -0700, Andre McCurdy wrote:
> > On Mon, Mar 22, 2021 at 2:29 PM Robert P. J. Day
> > wrote:
> > >
> > > here's the next head-scratching oddity i just ran across in the
>
here's the next head-scratching oddity i just ran across in the
current layer (and there's more weirdness on its way).
perusing a recipe only to see:
FILESPATH =+ "${COMMON_STUFF_DIR}:"
SRC_URI += "file://file1 file://file2 file://file 3 ... etc ..."
ok ... apparently, there are a
... snipping some stuff ...
On Mon, 22 Mar 2021, Andre McCurdy wrote:
> On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day
> wrote:
> >
> > in one recipe, i see the following snippet:
> >
> > FILES_${PN} += "/etc"
> > FILES_${PN} += "/
On Mon, 22 Mar 2021, Andre McCurdy wrote:
> On Mon, Mar 22, 2021 at 12:50 PM Robert P. J. Day
> wrote:
> >
> > more a style issue than anything else, but one of the other
> > oddities in this layer i've been handed is the bbappending to
> > standard OE image
more a style issue than anything else, but one of the other oddities
in this layer i've been handed is the bbappending to standard OE
images, so that recipes-core/images/ contains recipe files like:
core-image-minimal.bbappend
core-image-minimal-dev.bbappend
and so on. that just creeps me
(warning: i've just been handed an existing OE code base, and i'm
going to ask some questions about some head-scratching things i'm
finding in it, so be prepared for weird questions.)
in one recipe, i see the following snippet:
FILES_${PN} += "/etc"
FILES_${PN} += "/etc/mosquitto"
perusing some of the content in meta/classes/utility-tasks.bbclass,
and i see the snippet:
T_task-clean = "${LOG_DIR}/cleanlogs/${PN}"
which takes one all the way back to 2012:
commit eef9d6c2d52f5264a6e7a9d882f8323f9793fd7f
Author: Richard Purdie
Date: Fri Aug 17 14:19:22 2012
On Fri, 19 Mar 2021, Andre McCurdy wrote:
> On Fri, Mar 19, 2021 at 7:23 AM Robert P. J. Day
> wrote:
> > colleague just asked me about the difference between building an SDK
> > with either of:
> >
> > $ bitbake meta-toolchain
> > $ bitbake -c popula
colleague just asked me about the difference between building an SDK
with either of:
$ bitbake meta-toolchain
$ bitbake -c populate_sdk
i know that the meta-toolchain recipe file contains little more than
inheriting populate_sdk so, without checking, i speculated wildly as
follows:
currently writing a tutorial on how to play with FILESEXTRAPATHS in
the context of multiple machines and recipe versions, and noticed this
in my basic environment for a qemuarm64 build:
# "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
On Wed, 10 Mar 2021, Richard Purdie wrote:
> On Wed, 2021-03-10 at 06:38 -0500, Robert P. J. Day wrote:
> > On Mon, 8 Mar 2021, Khem Raj wrote:
> >
> > >
> > >
> > > On 3/8/21 3:22 AM, Robert P. J. Day wrote:
> > > >
> > > >
On Mon, 8 Mar 2021, Khem Raj wrote:
>
>
> On 3/8/21 3:22 AM, Robert P. J. Day wrote:
> >
> >collecting some examples of inheritance of class functions using
> > EXPORT_FUNCTIONS, and ran across this routine in cmake.bbclass:
> >
> >... snip ...
>
collecting some examples of inheritance of class functions using
EXPORT_FUNCTIONS, and ran across this routine in cmake.bbclass:
... snip ...
cmake_runcmake_build() {
bbnote ...
eval ...
}
cmake_do_compile() {
cmake_runcmake_build --target
another oddity in my travels, found a couple recipes that appear to
explicitly un-PROVIDE themselves, such as libxcrypt-compat_4.4.18.bb:
PROVIDES = ""
i thought that every recipe always implicitly provided itself, and
that one could always extend that (with either = or +=), but this is
the
in that script, one reads:
Note:
The amount of tasks is not accurate when the task is "do_build" since
it usually depends on other tasks.
The "nostamp" task is not included.
i have to assume that should read that all "nostamp" tasks are
excluded, as "nostamp" is a flag, not a
Pretty sure that trailing quote should be a period; it
appears to work properly.
Signed-off-by: Robert P. J. Day
---
diff --git a/scripts/bitbake-whatchanged b/scripts/bitbake-whatchanged
index 3095dafa46..6f4b268119 100755
--- a/scripts/bitbake-whatchanged
+++ b/scripts/bitbake-whatchanged
just noticed in bitbake.conf (around line 700):
#export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"
#export PSEUDO_BINDIR = "${STAGING_DIR_NATIVE}${bindir_native}"
#export PSEUDO_LIBDIR = "${STAGING_DIR_NATIVE}$PSEUDOBINDIR/../lib/pseudo/lib
apart from those lines being commented
On Mon, 15 Feb 2021, akuster808 wrote:
>
>
> On 2/15/21 12:11 PM, Robert P. J. Day wrote:
> > yes, i know fedora 33 is not a supported build distro, but in trying
> > an absolutely stock build of core-image-minimal from poky (zeus
> > branch) on my F33 system, i ran
yes, i know fedora 33 is not a supported build distro, but in trying
an absolutely stock build of core-image-minimal from poky (zeus
branch) on my F33 system, i ran into a gcc 10-related build error for
which this:
apparently, the newer version of "file", when asked about the mime
type of an ISO image, reports:
application/octet-stream
when, from what i read, it should (and used to) report:
application/x-iso9660-image
the above unexpected(?) behaviour comes with file-5.37, and it's been
seen in
On Thu, 21 Jan 2021, Robert P. J. Day wrote:
> colleague hands me the following curiosity ... approximately
> morty-based build, wherein ntp_4.2.8p10 has a bbappend file which
> contains (among other things) the line:
>
> DEPENDS += "autogen-native perl-native"
&g
colleague hands me the following curiosity ... approximately
morty-based build, wherein ntp_4.2.8p10 has a bbappend file which
contains (among other things) the line:
DEPENDS += "autogen-native perl-native"
i'm always nervous when a bbappend file just adds new build
dependencies but,
On Mon, 14 Dec 2020, Peter Kjellerstedt wrote:
> Say we have a recipe that creates an empty /etc/foo directory. Now we
> want to add a new file in that directory /etc/foo/bar and package it as
> ${PN}-bar. This means the creation of the /etc/foo directory is moved
> from the ${PN} package to the
"roofs_*.bbclass"
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145160):
https://lists.openembedded.org/g/openembedded-core/message/145160
Mute This Topic: https://lists.openembedded.org/mt/78641407/21656
Group Owner:
currently writing tutorial on how to craft some kernel-related recipes,
and noticed in linux-kernel-base.bbclass the python function
linux_module_packages() which, these days, does not seem to have any
callers.
is there something that routine is still doing? is it simply available
in case
pursuant to cleaning up some docs and tweaking the style guide,
i just want to clarify that the *proper* assignment to DEPENDS
in recipe files is:
DEPENDS = "..."
unless (of course) that assignment is preceded by a "require"
of a .inc file that assigns to that variable, whereupon the "+="
As the URL pypi.python.org simply redirects to pypi.org, simplify a
number of Python recipes by using that URL explicitly.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/recipes-devtools/python/python-extras.inc
b/meta/recipes-devtools/python/python-extras.inc
index b5e11b711a
On Mon, 15 Jun 2020, Robert P. J. Day wrote:
>
> The current setting for the HOMEPAGE is a redirection, so might as
> well update it.
>
> Signed-off-by: Robert P. J. Day
>
> ---
>
> diff --git a/meta/classes/pypi.bbclass b/meta/classes/pypi.bbclass
> index
The current setting for the HOMEPAGE is a redirection, so might as
well update it.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/classes/pypi.bbclass b/meta/classes/pypi.bbclass
index 87b4c85fc0..73aca77ef6 100644
--- a/meta/classes/pypi.bbclass
+++ b/meta/classes/pypi.bbclass
On Tue, 9 Jun 2020, Richard Purdie wrote:
> On Tue, 2020-06-09 at 14:33 +0100, Ross Burton wrote:
> > On Mon, 8 Jun 2020 at 21:15, Enrico J?rns wrote:
> >
> > > What is the now suggested way of placing these kind of binaries?
> > > Simply in DEPLOY_DIR_IMAGES as the above-mentioned commit does
>
perusing recipes for SDKs and noticed that populate_sdk.bbclass
consists wholly of (note the addtask of populate_sdk):
inherit populate_sdk_base
addtask populate_sdk after do_install before do_build
whereupon if one examines populate_sdk_base.bbclass, right at the very
end, one reads:
On Wed, 27 May 2020, Robert P. J. Day wrote:
>
> Variable DEPLOY_DIR_TOOLS was introduced in 2007:
>
> commit f751a20152c651a33f08ceda0502fa1d4f11c005
> Author: Richard Purdie
> Date: Wed Aug 8 21:02:39 2007 +
>
> bitbake.conf: Sync with OE.dev
>
Variable DEPLOY_DIR_TOOLS was introduced in 2007:
commit f751a20152c651a33f08ceda0502fa1d4f11c005
Author: Richard Purdie
Date: Wed Aug 8 21:02:39 2007 +
bitbake.conf: Sync with OE.dev
apparently never used so get rid of it.
Signed-off-by: Robert P. J. Day
On Sat, 23 May 2020, Gregor Zatko wrote:
> 'inherit' directive may not be used in conf files as it's supposed
> to be used for the inheritance of recipes.
no, it's for the inheritance of class files.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply
it *appears* that pypi.python.org is just a redirect to pypi.org,
which means a few things could be simplified, such as a few recipes,
as well as pypi.bbclass:
HOMEPAGE ?= "https://pypi.python.org/pypi/${PYPI_PACKAGE}/;
...
UPSTREAM_CHECK_URI ?=
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/files/common-licenses/Unlicense
b/meta/files/common-licenses/Unlicense
new file mode 100644
index 00..68a49daad8
--- /dev/null
+++ b/meta/files/common-licenses/Unlicense
@@ -0,0 +1,24 @@
+This is free and unencumbered software
Add to documentation.conf all the new variables supported by
features_check.bbclass.
Signed-off-by: Robert P. J. Day
---
in preparation for adding all this info to the YP reference manual,
might as well add them all here first.
diff --git a/meta/conf/documentation.conf b/meta/conf
On Tue, 5 May 2020, Richard Purdie wrote:
> On Sun, 2020-05-03 at 13:07 -0400, Robert P. J. Day wrote:
> > given my understanding of the rationale for INC_PR, it would seem
> > as
> > if at least *some* of these assignments are superfluous:
> >
> &g
not sure where i read this (YP overview manual?), but i recall
something about the FILESPATHPKG variable being deprecated, and i see
its only references are:
$ grep -irw filespathpkg *
meta/classes/utils.bbclass:filespathpkg =
d.getVar("FILESPATHPKG").split(":")
given my understanding of the rationale for INC_PR, it would seem as
if at least *some* of these assignments are superfluous:
recipes-connectivity/connman/connman.inc:INC_PR = "r20"
recipes-graphics/xorg-driver/xorg-driver-common.inc:INC_PR = "r21"
given an odd collection of layers wherein there are multiple
instances of a particular .bbclass file, it turns out that all of the
recipes i'm interested in build with an older version of the class
file, and all but one build consulting the newer form of the file
contained in another layer, so
just noticed that, in master branch, kbd recipe quite reasonably
distinguishes itself from the much, much older console-tools package
thusly:
RREPLACES_${PN} = "console-tools"
RPROVIDES_${PN} = "console-tools"
RCONFLICTS_${PN} = "console-tools"
all perfectly reasonable as long as
On Tue, 28 Apr 2020, Richard Purdie wrote:
> On Tue, 2020-04-28 at 09:44 -0400, Robert P. J. Day wrote:
> > just noticed that that variable was deprecated waay back in
> > 2014
> > in favour of FEATURE_PACKAGES, and i see no reference to it in any of
> > the numer
just noticed that that variable was deprecated waay back in 2014
in favour of FEATURE_PACKAGES, and i see no reference to it in any of
the numerous layers i have currently checked out.
if someone here wants to take it out of OE-core, i can do the
equivalent in the YP reference manual.
(note: i think i discovered the simplest way to do this but ...
onward.)
given an OE image based on some old YP versions (mostly morty/2.2),
there is a maddeningly intermittent build issue with one or the other
of a small number of ruby gems, so my initial idea is, for now, to
just remove
On Thu, 23 Apr 2020, Christopher Larson wrote:
> This seems like something best kept in the distro .conf rather than
> local.conf, in which case brevity is much less of an issue.
>
> On Thu, Apr 23, 2020 at 10:53 AM Robert P. J. Day
> wrote:
>
> in the vein of th
101 - 200 of 1037 matches
Mail list logo
