Re: [OE-core] is there any reason to use .ipk packaging if devs are using ubuntu?
On Sat, 23 Mar 2024, Alexander Kanavin wrote: > On Sat, 23 Mar 2024 at 18:34, Robert P. J. Day wrote: > > all of this being accurate, the one advantage i can see is that, if > > developers are familiar with deb package management on their ubuntu > > dev systems, then they would be familiar with having package > > management on their target systems (provided, as you say, they > > understand that they should work only with YP-generated packages). > > Nah, I don't see that familiarity helping anything. Reading output of > opkg and finding out that you need to issue 'opkg install' takes 10 > seconds. That's such a minor hurdle compared to learning yocto in > general (especially when to do when bitbake ends with an error) that > I'd say any time saved there is statistical noise. ok, that's reasonable. thanks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197463): https://lists.openembedded.org/g/openembedded-core/message/197463 Mute This Topic: https://lists.openembedded.org/mt/105106419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] is there any reason to use .ipk packaging if devs are using ubuntu?
On Sat, 23 Mar 2024, Alexander Kanavin wrote: > Packaging format of the host distribution and packaging format used > by yocto have no relation even if there is package management on > real targets. Why is there an assumption that matching them is going > to help something? > > If anything, making them match might prompt misguided attempts to > install Ubuntu packages in yocto systems and frustration at not > being able to make it work. all of this being accurate, the one advantage i can see is that, if developers are familiar with deb package management on their ubuntu dev systems, then they would be familiar with having package management on their target systems (provided, as you say, they understand that they should work only with YP-generated packages). rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197461): https://lists.openembedded.org/g/openembedded-core/message/197461 Mute This Topic: https://lists.openembedded.org/mt/105106419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] is there any reason to use .ipk packaging if devs are using ubuntu?
yet another sophomoric question but i have inherited (and am babysitting) a fairly extensive OE/YP build system that, for the most part, works but i noticed early on that it selects ipk for the package format. now, given that there is no package management installed in the images, i guess it really makes no difference what the package format is, but it just seems unnatural to use ipk given that the corp-approved linux development system is ubuntu. is there any compelling argument for this? i suspect i could change the packaging format and the developers would not even notice. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197458): https://lists.openembedded.org/g/openembedded-core/message/197458 Mute This Topic: https://lists.openembedded.org/mt/105106419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] ptest: test for PTEST_ENABLED instead of DISTRO_FEATURES
On Sun, 10 Mar 2024, Alexander Kanavin wrote:
> On Sat, 9 Mar 2024 at 11:29, Robert P. J. Day wrote:
> > As ptest.bbclass defines the more intuitive ptest-related variable:
> >
> > PTEST_ENABLED =
> > "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}"
> >
> > modify a number of obvious recipe ptest checks to use that simpler
> > form.
>
> I disagree. When someone reads a recipe, and sees a variable, the
> questions that typically come up are:
>
> - where is it set
> - how is it set
> - what needs to be done to change it.
>
> DISTRO_FEATURES wins all three, as it's commonly known and understood
> facility.
then what is the point of defining PTEST_ENABLED in the first place?
and using a mixture of both throughout the code base?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196885):
https://lists.openembedded.org/g/openembedded-core/message/196885
Mute This Topic: https://lists.openembedded.org/mt/104825491/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] more pedantry: observation on PACKAGES ordering and bash-completion.bbclass
On Sat, 9 Mar 2024, Quentin Schulz wrote:
> Hi,
>
> On March 9, 2024 10:38:18 AM GMT+01:00, "Robert P. J. Day"
> wrote:
> >
> > currently perusing countless recipes to choose really good
> >pedagogical examples of "ptest" usage, and i began running across a
> >number of recipes that (unrelated to ptest) included snippets toward
> >the end of their recipe files that added content to FILES:${PN}.
> >here's an example from fwupd:
> >
> >https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-bsp/fwupd/fwupd_1.8.9.bb#L130
> >
> >FILES:${PN} += "${libdir}/fwupd-plugins-* \
> >${libdir}/fwupd-${PV} \
> >${systemd_unitdir} \
> >${datadir}/fish \
> >${datadir}/metainfo \
> >${datadir}/icons \
> >${datadir}/dbus-1 \
> >${datadir}/polkit-1 \
> >${nonarch_libdir}/modules-load.d"
> >
> > since i knew(?) that the default PACKAGES list is processed left to
> >right, and that the PN package is left until the end to gather what
> >remains, i couldn't understand why so many recipes insisted on adding
>
> "to gather what remains," is not entirely correct. FILES:${PN} is not a
> grab-all variable, it still only takes files matching the globs inside the
> variable, which defaults to:
>
> """
> FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/*
> ${libdir}/lib*${SOLIBS} \ ${sysconfdir} ${sharedstatedir} ${localstatedir} \
> ${base_bindir}/* ${base_sbindir}/* \ ${base_libdir}/*${SOLIBS} \
> ${base_prefix}/lib/udev ${prefix}/lib/udev \ ${base_libdir}/udev
> ${libdir}/udev \ ${datadir}/${BPN} ${libdir}/${BPN}/* \ ${datadir}/pixmaps
> ${datadir}/applications \ ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
> ${libdir}/bonobo/servers"
> """
>
> And you can see that the paths added to fwupd aren't matched by those default
> globs, hence why they are added.
>
> >extra content to FILES:${PN} when the default processing would have
> >collected it anyway, unless ... there was something that had been
> >appended to PACKAGES that required that.
> >
> > sure enough, bash-completion.bbclass:
> >
> >PACKAGES += "${PN}-bash-completion"
> >FILES:${PN}-bash-completion = "${datadir}/bash-completion
> > ${sysconfdir}/bash_completion.d"
> >
> > my understanding is that the "proper" ordering of PACKAGES is to
> >start with the most focused and specific packages, define their
> >content, then move on until, at the end, whatever remains goes into
> >PN. which makes that definition of bash-completion.bbclass a bit
> >puzzling -- why was it not *prepended* to the PACKAGES list given its
> >specificity? and making all that subsequent addition to FILES:${PN}
> >unnecessary?
> >
>
> If a file is matched only by one glob, then it doesn't matter much
> in which order the packages are listed, which is very likely the
> case here.
>
> One reason could simply be that += is more natural than =+ and
> seeing that += worked, the contributor didn't think twice about it.
>
> FWIW, one can also do PACKAGE_BEFORE_PN += "${PN}-bash-completion"
> to have bash-completion done right before PN instead of first if
> using =+.
>
> Moving bash-completion package somewhere else in the PACKAGES list
> likely wouldn't change anything of the globs in FILES:${PN} though.
you're right, i just thought the structure looked awkward.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196877):
https://lists.openembedded.org/g/openembedded-core/message/196877
Mute This Topic: https://lists.openembedded.org/mt/104825042/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] ptest: test for PTEST_ENABLED instead of DISTRO_FEATURES
As ptest.bbclass defines the more intuitive ptest-related variable:
PTEST_ENABLED =
"${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}"
modify a number of obvious recipe ptest checks to use that simpler
form.
Signed-off-by: Robert P. J. Day
---
i did a simple textual substitution so as long as that's all that's
needed, this should work.
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index e963001d09..bb01fa7466 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -1371,7 +1371,7 @@ python do_qa_patch() {
return False
srcdir = d.getVar('S')
-if not bb.utils.contains('DISTRO_FEATURES', 'ptest', True, False, d):
+if not bb.utils.contains('PTEST_ENABLED', '1', True, False, d):
pass
elif bb.data.inherits_class('ptest', d):
bb.note("Package %s QA: skipping unimplemented-ptest: ptest
implementation detected" % d.getVar('PN'))
diff --git a/meta/recipes-devtools/lua/lua_5.4.6.bb
b/meta/recipes-devtools/lua/lua_5.4.6.bb
index eabfc89575..6420b2231b 100644
--- a/meta/recipes-devtools/lua/lua_5.4.6.bb
+++ b/meta/recipes-devtools/lua/lua_5.4.6.bb
@@ -6,7 +6,7 @@ HOMEPAGE = "http://www.lua.org/;
SRC_URI = "http://www.lua.org/ftp/lua-${PV}.tar.gz;name=tarballsrc \
file://lua.pc.in \
- ${@bb.utils.contains('DISTRO_FEATURES', 'ptest',
'http://www.lua.org/tests/lua-${PV_testsuites}-tests.tar.gz;name=tarballtest
file://run-ptest ', '', d)} \
+ ${@bb.utils.contains('PTEST_ENABLED', '1',
'http://www.lua.org/tests/lua-${PV_testsuites}-tests.tar.gz;name=tarballtest
file://run-ptest ', '', d)} \
"
# if no test suite matches PV release of Lua exactly, download the suite for
the closest Lua release.
diff --git a/meta/recipes-devtools/perl/perl-ptest.inc
b/meta/recipes-devtools/perl/perl-ptest.inc
index e07355d3f5..98d7b1c2a2 100644
--- a/meta/recipes-devtools/perl/perl-ptest.inc
+++ b/meta/recipes-devtools/perl/perl-ptest.inc
@@ -51,7 +51,7 @@ python populate_packages:prepend() {
# Put all *.t files from the lib dir in the ptest package
# do_split_packages requires a pair of () in the regex, but we have nothing
# to match, so use an empty pair.
-if bb.utils.contains('DISTRO_FEATURES', 'ptest', True, False, d):
+if bb.utils.contains('PTEST_ENABLED', '1', True, False, d):
do_split_packages(d, d.expand('${libdir}/perl/${PV}'), r'.*\.t()',
'${PN}-ptest%s', '%s', recursive=True, match_path=True)
}
diff --git a/meta/recipes-devtools/python/python3-bcrypt_4.1.2.bb
b/meta/recipes-devtools/python/python3-bcrypt_4.1.2.bb
index 93fa645f33..4e6ca5e074 100644
--- a/meta/recipes-devtools/python/python3-bcrypt_4.1.2.bb
+++ b/meta/recipes-devtools/python/python3-bcrypt_4.1.2.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=8f7bb094c7232b058c7e9f2e431f389c"
HOMEPAGE = "https://pypi.org/project/bcrypt/;
DEPENDS += "python3-cffi-native"
-LDFLAGS:append = "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '
-fuse-ld=bfd', '', d)}"
+LDFLAGS:append = "${@bb.utils.contains('PTEST_ENABLED', '1', ' -fuse-ld=bfd',
'', d)}"
SRC_URI[sha256sum] =
"33313a1200a3ae90b75587ceac502b048b840fc69e7f7a0905b5f87fac7a1258"
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.22.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.22.0.bb
index 74ac7ec9d5..c0f3784261 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.22.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.22.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
file://COPYING.DOCS;md5=24ea4c7092233849b4394699333b5c56"
DEPENDS = " \
- ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'boost', '', d)} \
+ ${@bb.utils.contains('PTEST_ENABLED', '1', 'boost', '', d)} \
"
SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index bd3e5a9406..dce9339643 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -60,7 +60,7 @@ KERNEL_FEATURES:append:qemuall=" cfg/virtio.scc
features/drm-bochs/drm-bochs.scc
KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
KERNEL_FEATURES:append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", "
cfg/x32.scc", "", d)}"
-KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", "
features/scsi/scsi-debug.scc", "", d)}"
-KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES
[OE-core] more pedantry: observation on PACKAGES ordering and bash-completion.bbclass
currently perusing countless recipes to choose really good
pedagogical examples of "ptest" usage, and i began running across a
number of recipes that (unrelated to ptest) included snippets toward
the end of their recipe files that added content to FILES:${PN}.
here's an example from fwupd:
https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-bsp/fwupd/fwupd_1.8.9.bb#L130
FILES:${PN} += "${libdir}/fwupd-plugins-* \
${libdir}/fwupd-${PV} \
${systemd_unitdir} \
${datadir}/fish \
${datadir}/metainfo \
${datadir}/icons \
${datadir}/dbus-1 \
${datadir}/polkit-1 \
${nonarch_libdir}/modules-load.d"
since i knew(?) that the default PACKAGES list is processed left to
right, and that the PN package is left until the end to gather what
remains, i couldn't understand why so many recipes insisted on adding
extra content to FILES:${PN} when the default processing would have
collected it anyway, unless ... there was something that had been
appended to PACKAGES that required that.
sure enough, bash-completion.bbclass:
PACKAGES += "${PN}-bash-completion"
FILES:${PN}-bash-completion = "${datadir}/bash-completion
${sysconfdir}/bash_completion.d"
my understanding is that the "proper" ordering of PACKAGES is to
start with the most focused and specific packages, define their
content, then move on until, at the end, whatever remains goes into
PN. which makes that definition of bash-completion.bbclass a bit
puzzling -- why was it not *prepended* to the PACKAGES list given its
specificity? and making all that subsequent addition to FILES:${PN}
unnecessary?
or am i misunderstanding something?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196867):
https://lists.openembedded.org/g/openembedded-core/message/196867
Mute This Topic: https://lists.openembedded.org/mt/104825042/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] if "bitbake-layers" HOSTTOOLS fails check, does layer fail to add?
was just handed a sizable YP/WRL project and i *think* i can see what the problem is, so i'll keep it short (he said, optimistlcally). the symptom is that, of the dozens of layers that should end up in bblayers.conf (all this running on a VM in a docker container), one layer is missing, and that's the one that defines all the distro config files, so the eventual error is: DISTRO 'slartibartfast' not found ... well, yeah, and that's pretty clearly because the corresponding layer is, for whatever reason, not being added to bblayers.conf. so why not? look further into output and notice that, just above that, there is an error that shows an essential tool cannot be found: ERROR: THe following required tools (as specified by HOSTTOOLS) cannot be found ... snafu and, sure enough, the missing layer does insist in its layer.conf that: HOSTTOOLS += "snafu" so i am assuming that, because that layer was being added via "bitbake-layers" and that layer had a HOSTTOOLS requirement that was not satisfied, that's why the failure of the layer addition, yes? just to bypass this issue, is there a bitbake-layers option that bypasses that sanity checking? i can see "-F" but that claims to bypass recipe parse verification, which is not what this is. this all depends on the assumption that that failed HOSTTOOLS test is what caused the failure of the layer addition, which cascaded down to other errors. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196680): https://lists.openembedded.org/g/openembedded-core/message/196680 Mute This Topic: https://lists.openembedded.org/mt/104766066/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] python3-cryptography_42.0.5.bb: delete redundant ptest packaging
Since FILES:${PN}-ptest is already defined to include the contents of
${PTEST_PATH}, adding such an entry to the package is superfluous.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/recipes-devtools/python/python3-cryptography_42.0.5.bb
b/meta/recipes-devtools/python/python3-cryptography_42.0.5.bb
index 2bcb5717e4..732f925d92 100644
--- a/meta/recipes-devtools/python/python3-cryptography_42.0.5.bb
+++ b/meta/recipes-devtools/python/python3-cryptography_42.0.5.bb
@@ -60,9 +60,6 @@ do_install_ptest() {
cp -r ${S}/pyproject.toml ${D}${PTEST_PATH}/
}
-FILES:${PN}-ptest += " \
-${PTEST_PATH}/check-memfree.py \
-"
FILES:${PN}-dbg += " \
${PYTHON_SITEPACKAGES_DIR}/${SRCNAME}/hazmat/bindings/.debug \
"
--
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196594):
https://lists.openembedded.org/g/openembedded-core/message/196594
Mute This Topic: https://lists.openembedded.org/mt/104719742/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] does one need to "add" packages to ptest already under ${PTEST_PATH}?
apologies if i already asked this, i'm trying to juggle a dozen
things at once.
here:
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python3-cryptography_42.0.5.bb#n63
what is the point of adding to FILES:${PN}-ptest something that is
already under ${PTEST_PATH}? especially since the do_install_ptest()
function above it installs even more but doesn't add that stuff?
obviously(?), it doesn't hurt, it's just puzzling. i can submit a
patch to delete the extraneous stuff for clarity.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196575):
https://lists.openembedded.org/g/openembedded-core/message/196575
Mute This Topic: https://lists.openembedded.org/mt/104708837/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] trying to create simple example of "externalsrc" recipe
On Fri, 26 Jan 2024, Khem Raj wrote:
> On Fri, Jan 26, 2024 at 4:46 AM Robert P. J. Day
> wrote:
> >
> >
> > i've been trying to put together a really basic example of a recipe
> > using "externalsrc" that refers to some local source, and cannot get
> > it to work. so here's what i'm trying.
> >
> > as a demo, i selected a random simple OE recipe -- in this case,
> > "dmidecode", whose recipe you can see here (and which seems
> > conveniently simple for demonstration purposes):
> >
> > https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/dmidecode/dmidecode_3.5.bb?h=master
> >
> > so to start, since the SRC_URI is a tarball, i downloaded the tarball
> > so that i have the equivalent local source here:
> >
> > $ ls /home/rpjday/oe/srcs/dmidecode-3.5
> > AUTHORS dmioem.h Makefile util.c
> > biosdecode.c dmiopt.c man util.h
> > config.h dmiopt.h NEWS version.h
> > dmidecode.c dmioutput.c ownership.c vpddecode.c
> > dmidecode.h dmioutput.h README vpdopt.c
> > dmioem.c LICENSE types.h vpdopt.h
> > $
> >
> > as my first test, i set the build to the source directory in my
> > dmid_1.0.bb recipe file:
> >
> > inherit externalsrc
> > EXTERNALSRC = "/home/rpjday/oe/srcs/dmidecode-3.5"
> > EXTERNALSRC_BUILD = "${EXTERNALSRC}"
> >
> > do_install() {
> > oe_runmake \
> > DESTDIR="${D}" \
> > prefix="${prefix}" \
> > sbindir="${sbindir}" \
> > docdir="${docdir}/${BPN}" \
> > mandir="${mandir}" \
> > install
> >
> > then ran:
> >
> > $ bitbake dmid
> >
> > sure enough, that build in the source directory, generating:
> >
> > AUTHORS dmidecode.o dmioutput.h ownership* version.h
> > biosdecode* dmioem.c dmioutput.o ownership.c vpddecode*
> > biosdecode.c dmioem.h LICENSE ownership.o vpddecode.c
> > biosdecode.o dmioem.o Makefile README vpddecode.o
> > config.h dmiopt.c man/ types.h vpdopt.c
> > dmidecode*dmiopt.h NEWS util.c vpdopt.h
> > dmidecode.c dmiopt.o oe-logs@ util.h vpdopt.o
> > dmidecode.h dmioutput.c oe-workdir@ util.o
> >
> > great, but i really want to build out-of-tree to preserve the
> > pristine state of the source, so i followed the instructions and
> > allowed EXTERNALSRC_BUILD to default to ${WORKDIR}/${BPN}-${PV}:
> >
> > inherit externalsrc
> > EXTERNALSRC = "/home/rpjday/oe/srcs/dmidecode-3.5"
> > # EXTERNALSRC_BUILD = "${EXTERNALSRC}"
> >
> > so I did a "make clean" in the source directory to start with the
> > pristine source (also deleted the "oe-" symlinks), then:
> >
> > $ bitbake dmid
> > ... snip ...
> > | NOTE: make -j 8
> > DESTDIR=/home/rpjday/oe/builds/qemux86/tmp/work/core2-64-poky-linux/dmid/1.0/image
> > prefix=/usr sbindir=/usr/sbin docdir=/usr/share/doc/dmid
> > mandir=/usr/share/man install
> > | make: *** No rule to make target 'install'. Stop.
> > | ERROR: oe_runmake failed
> >
> > from "bitbake -e dmid", i can see:
> >
> > S="/home/rpjday/oe/srcs/dmidecode-3.5"
> > WORKDIR="/home/rpjday/oe/builds/qemux86/tmp/work/core2-64-poky-linux/dmid/1.0"
> > B="/home/rpjday/oe/builds/qemux86/tmp/work/core2-64-poky-linux/dmid/1.0/dmid-1.0"
> >
> > but there is nothing unloaded into the B directory; hence, the
> > failure. in fact, the log file for the compile step is:
> >
> > DEBUG: Executing python function externalsrc_compile_prefunc
> > NOTE: dmid: compiling from external source tree
> > /home/rpjday/oe/srcs/dmidecode-3.5
> > DEBUG: Python function externalsrc_compile_prefunc finished
> > DEBUG: Executing python function fetcher_hashes_dummyfunc
> > DEBUG: Python function fetcher_hashes_dummyfunc finished
> > DEBUG: Executing shell function do_compile
> > NOTE: nothing to compile
> > DEBUG: Shell function do_compile finished
> >
> > so ... what have i overlooked? did i grab an inappropriate sample
> > recipe that does not support building out-of-tree? the build directory
> > is empty, so i'm perusing the externalsrc.bbclass to see what i have
> > misunderstood.
>
> externalsrc is as good as the components build system si
Re: [OE-core] trying to create simple example of "externalsrc" recipe
On Fri, 26 Jan 2024, Alexander Kanavin wrote: > Note that there is a selftest for this in > meta/lib/oeqa/selftest/cases/externalsrc.py, so you could check why > that seems to work. > > Alex ah, i had forgotten about the directory of selftests. my bad. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#194358): https://lists.openembedded.org/g/openembedded-core/message/194358 Mute This Topic: https://lists.openembedded.org/mt/103974993/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] trying to create simple example of "externalsrc" recipe
i've been trying to put together a really basic example of a recipe
using "externalsrc" that refers to some local source, and cannot get
it to work. so here's what i'm trying.
as a demo, i selected a random simple OE recipe -- in this case,
"dmidecode", whose recipe you can see here (and which seems
conveniently simple for demonstration purposes):
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/dmidecode/dmidecode_3.5.bb?h=master
so to start, since the SRC_URI is a tarball, i downloaded the tarball
so that i have the equivalent local source here:
$ ls /home/rpjday/oe/srcs/dmidecode-3.5
AUTHORS dmioem.h Makefile util.c
biosdecode.c dmiopt.c man util.h
config.h dmiopt.h NEWS version.h
dmidecode.c dmioutput.c ownership.c vpddecode.c
dmidecode.h dmioutput.h README vpdopt.c
dmioem.c LICENSE types.h vpdopt.h
$
as my first test, i set the build to the source directory in my
dmid_1.0.bb recipe file:
inherit externalsrc
EXTERNALSRC = "/home/rpjday/oe/srcs/dmidecode-3.5"
EXTERNALSRC_BUILD = "${EXTERNALSRC}"
do_install() {
oe_runmake \
DESTDIR="${D}" \
prefix="${prefix}" \
sbindir="${sbindir}" \
docdir="${docdir}/${BPN}" \
mandir="${mandir}" \
install
then ran:
$ bitbake dmid
sure enough, that build in the source directory, generating:
AUTHORS dmidecode.o dmioutput.h ownership* version.h
biosdecode* dmioem.c dmioutput.o ownership.c vpddecode*
biosdecode.c dmioem.h LICENSE ownership.o vpddecode.c
biosdecode.o dmioem.o Makefile README vpddecode.o
config.h dmiopt.c man/ types.h vpdopt.c
dmidecode*dmiopt.h NEWS util.c vpdopt.h
dmidecode.c dmiopt.o oe-logs@ util.h vpdopt.o
dmidecode.h dmioutput.c oe-workdir@ util.o
great, but i really want to build out-of-tree to preserve the
pristine state of the source, so i followed the instructions and
allowed EXTERNALSRC_BUILD to default to ${WORKDIR}/${BPN}-${PV}:
inherit externalsrc
EXTERNALSRC = "/home/rpjday/oe/srcs/dmidecode-3.5"
# EXTERNALSRC_BUILD = "${EXTERNALSRC}"
so I did a "make clean" in the source directory to start with the
pristine source (also deleted the "oe-" symlinks), then:
$ bitbake dmid
... snip ...
| NOTE: make -j 8
DESTDIR=/home/rpjday/oe/builds/qemux86/tmp/work/core2-64-poky-linux/dmid/1.0/image
prefix=/usr sbindir=/usr/sbin docdir=/usr/share/doc/dmid
mandir=/usr/share/man install
| make: *** No rule to make target 'install'. Stop.
| ERROR: oe_runmake failed
from "bitbake -e dmid", i can see:
S="/home/rpjday/oe/srcs/dmidecode-3.5"
WORKDIR="/home/rpjday/oe/builds/qemux86/tmp/work/core2-64-poky-linux/dmid/1.0"
B="/home/rpjday/oe/builds/qemux86/tmp/work/core2-64-poky-linux/dmid/1.0/dmid-1.0"
but there is nothing unloaded into the B directory; hence, the
failure. in fact, the log file for the compile step is:
DEBUG: Executing python function externalsrc_compile_prefunc
NOTE: dmid: compiling from external source tree
/home/rpjday/oe/srcs/dmidecode-3.5
DEBUG: Python function externalsrc_compile_prefunc finished
DEBUG: Executing python function fetcher_hashes_dummyfunc
DEBUG: Python function fetcher_hashes_dummyfunc finished
DEBUG: Executing shell function do_compile
NOTE: nothing to compile
DEBUG: Shell function do_compile finished
so ... what have i overlooked? did i grab an inappropriate sample
recipe that does not support building out-of-tree? the build directory
is empty, so i'm perusing the externalsrc.bbclass to see what i have
misunderstood.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194356):
https://lists.openembedded.org/g/openembedded-core/message/194356
Mute This Topic: https://lists.openembedded.org/mt/103974993/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] tutorial-level questions to clean up recipes for demo purposes
(NOTE: i'm currently tutoring some colleagues in the basics of OE
and using standard OE recipes as examples of good programming
practice, so occasionally i run across something that looks strange
and i just want to clarify so i don't have to say, "i don't know, i
guess there's a reason for that, i just don't know what it is." so,
first question that has arisen ...)
in current dropbear recipe, very last line:
https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/dropbear/dropbear_2022.83.bb#n134
the line:
FILES:${PN} += "${bindir}"
but as i read bitbake.conf, ${bindir} is *already* part of FILES:${PN}
and i see nothing in the rest of the dropbear recipe that redefines
the PACKAGES or reorders them. is there some point to that last line
that i am simply missing? it seems unnecessary.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194316):
https://lists.openembedded.org/g/openembedded-core/message/194316
Mute This Topic: https://lists.openembedded.org/mt/103951915/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote: > On Thu, 18 Jan 2024 at 15:10, Robert P. J. Day wrote: > > ah, got it. that's still fine since as the content is almost > > exclusively binary (pre-built) content, redoing from scratch will take > > no time at all. thanks for clarifying that. > > Pre-built content is ok on its own, but if those items are in the > dependency tree of something that does take time to build, they will > subvert sstate and lengthen build times. i'm already going over the entire build to identify unnoticed dependencies that could cause problems. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193989): https://lists.openembedded.org/g/openembedded-core/message/193989 Mute This Topic: https://lists.openembedded.org/mt/103807270/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> On Thu, 18 Jan 2024 at 15:04, Robert P. J. Day wrote:
> > i just tested, and the recipe does *not* rebuild unless i change
> > something in the ("externalsrc") source directory, at which point,
> > yes, it rebuilds. which is exactly what i'm after.
>
> It only doesn't rebuild because you already have a build/tmp directory.
>
> But as no sstate objects are created, if you wipe tmp/ or make a new
> build directory, it will rebuild again even without any changes at
> all. Try that!
ah, got it. that's still fine since as the content is almost
exclusively binary (pre-built) content, redoing from scratch will take
no time at all. thanks for clarifying that.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193987):
https://lists.openembedded.org/g/openembedded-core/message/193987
Mute This Topic: https://lists.openembedded.org/mt/103807270/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote: > Mono-repo seemed like a good idea at the time, I'm sure. > > I need to point out that externalsrc disables sstate and always > rebuilds from scratch. Is that okay? just tested a bitbake on recipe after changing nothing: Sstate summary: Wanted 96 Local 96 Mirrors 0 Missed 0 Current 100 (100% match, 100% complete) | ETA: 0:00:00 Initialising tasks: 100% |#| Time: 0:00:01 NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 637 tasks of which 637 didn't need to be rerun and all succeeded. then i made a trivial change to a single file in the source directory and bitbake'd again: Sstate summary: Wanted 103 Local 96 Mirrors 0 Missed 7 Current 93 (93% match, 96% complete)| ETA: 0:00:00 Removing 6 stale sstate objects for arch allarch: 100% |###| Time: 0:00:00 Removing 1 stale sstate objects for arch qemux86_64: 100% || Time: 0:00:00 NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 637 tasks of which 627 didn't need to be rerun and all succeeded. NOTE: Build completion summary: NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_runtime_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_package_qa: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_package: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_packagedata: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_package_write_rpm: 0.0% sstate reuse(0 setscene, 1 scratch) seems to be honouring sstate-cache. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193985): https://lists.openembedded.org/g/openembedded-core/message/193985 Mute This Topic: https://lists.openembedded.org/mt/103807270/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> Mono-repo seemed like a good idea at the time, I'm sure.
>
> I need to point out that externalsrc disables sstate and always
> rebuilds from scratch. Is that okay?
i just tested, and the recipe does *not* rebuild unless i change
something in the ("externalsrc") source directory, at which point,
yes, it rebuilds. which is exactly what i'm after.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193983):
https://lists.openembedded.org/g/openembedded-core/message/193983
Mute This Topic: https://lists.openembedded.org/mt/103807270/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] want to confirm i'm using "externalsrc" and "bin_package" efficiently
i'm pretty sure i know how to do this, just want to know if there's an even easier/more elegant way. in current project, there is a *pile* of local content that is identified by various recipes. so since that content is local, the obvious starting point is for such recipes to "inherit externalsrc" to properly identify the local source directory. in addition, many of those recipes represent packaging binary data (imagine firmware files), so that there is really no meaningful configure or compile tasks, so that further suggests inheriting "bin_package" as well. finally, in some cases, there is a teeny bit of tweaking that might be needed for the final installed content, which suggests adding: do_install:append() to the mix to handle whatever little adjustments are needed. so given that scenario, can i reasonably summarize the right approach as: inherit externalsrc inherit bin_package do_install:append() [as needed] finally, it doesn't seem like many of those recipes are required as build-time dependencies, so i can just make them either RDEPENDS as appropriate, or just IMAGE_INSTALL them for the final image. sound reasonable? am i overthinking this? seems fairly straightforward. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193977): https://lists.openembedded.org/g/openembedded-core/message/193977 Mute This Topic: https://lists.openembedded.org/mt/103807270/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] how badly do symlinks from within ${S} to outside ${S} mess up sstate?
On Tue, 16 Jan 2024, Richard Purdie wrote:
> On Tue, 2024-01-16 at 09:23 -0500, Robert P. J. Day wrote:
> > a very weird question, to be sure, but i literally just ran across a
> > recipe that does the following (i will paraphrase some stuff to
> > protect the innocent).
> >
> > the recipe processes a bunch of XML source files, and generates from
> > them JSON files, so any change in any of the XML source files should
> > (obviously) trigger a rebuild of the recipe. and here's the problem.
> >
> > the XML files are not copied into the recipe source directory, and
> > are not even referenced by SRC_URI. rather, the files live in a
> > well-known location on the build host (placed there by a monstrous
> > "repo sync"), and to save time and space, the recipe just *symlinks*
> > from inside ${S} to the XML source files outside of ${S}, then
> > proceeds to process them to generate the subsequent JSON files.
> >
> > the complaint is that, when the build pipeline started taking
> > advantage of sstate-cache, even after some of the XML files were
> > changed, the recipe would not rebuild.
> >
> > once i understood what was happening, my immediate reaction was
> > along the lines, "well, since what is under ${S} is simply symlinks to
> > files *outside* of ${S} and (worse) those symlink names will never
> > change (all that will change is the XML files at the other end), how
> > is bitbake supposed to have any idea that those XML files have
> > changed to kick off a rebuild?"
> >
> > so my initial response was, "this does not surprise me at all," but
> > does my reasoning hold up? obviously, this should probably use a
> > combination of bin_package and externalsrc, but as it is now, is it
> > moderately accurate to suggest that it is those symlinks that are
> > preventing bitbake from understanding that anything has changed, so
> > that it continues to use the old sstate-cache?
>
> Inputs to a recipe need to come through SRC_URI. That way bitbake can
> know when they change. If you point at some random place via a symlink
> how is bitbake supposed to know if/when they change?
>
> Yes, pointing at a large tree of files will take time to hash and yes,
> that can make parsing slow. Either you care when it changes or you
> don't.
>
> The inputs are used to generate a hash which makes up the hash
> representing the task. When the hash changes, we know that sstate is
> invalid and we need to rebuild.
thanks, richard, i appreciate the time you took to clarify this. i'm
going to paraphrase and add it to my WIP "OE/YP best practices"
internal doc; this advice would be contained in the chapter, "for the
love of god, stop doing this!"
thanks again.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193903):
https://lists.openembedded.org/g/openembedded-core/message/193903
Mute This Topic: https://lists.openembedded.org/mt/103762271/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] how badly do symlinks from within ${S} to outside ${S} mess up sstate?
a very weird question, to be sure, but i literally just ran across a
recipe that does the following (i will paraphrase some stuff to
protect the innocent).
the recipe processes a bunch of XML source files, and generates from
them JSON files, so any change in any of the XML source files should
(obviously) trigger a rebuild of the recipe. and here's the problem.
the XML files are not copied into the recipe source directory, and
are not even referenced by SRC_URI. rather, the files live in a
well-known location on the build host (placed there by a monstrous
"repo sync"), and to save time and space, the recipe just *symlinks*
from inside ${S} to the XML source files outside of ${S}, then
proceeds to process them to generate the subsequent JSON files.
the complaint is that, when the build pipeline started taking
advantage of sstate-cache, even after some of the XML files were
changed, the recipe would not rebuild.
once i understood what was happening, my immediate reaction was
along the lines, "well, since what is under ${S} is simply symlinks to
files *outside* of ${S} and (worse) those symlink names will never
change (all that will change is the XML files at the other end), how
is bitbake supposed to have any idea that those XML files have
changed to kick off a rebuild?"
so my initial response was, "this does not surprise me at all," but
does my reasoning hold up? obviously, this should probably use a
combination of bin_package and externalsrc, but as it is now, is it
moderately accurate to suggest that it is those symlinks that are
preventing bitbake from understanding that anything has changed, so
that it continues to use the old sstate-cache?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193864):
https://lists.openembedded.org/g/openembedded-core/message/193864
Mute This Topic: https://lists.openembedded.org/mt/103762271/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] looking to collect "OE/YP best practices" docs for co-op student
g'day, eh?
in my current employment, i am in charge of a number of YP (well,
Wind River Linux) layers with a lot of legacy cruft^H^H^H^H^H content,
and i'd like to start cleaning it up little by little. i was gifted a
fairly junior co-op student for the term and figured this would be a
good way to put him to use and even turn him into a moderately
competent OE developer by the end of the term.
so i wanted to put together a *really* comprehensive list of best
practices, starting simple, open a Jira epic, and start adding
increasingly sophisticated tasks for him to do day by day.
i've started collecting a few docs but none of them really cover the
gamut of all the pedantic things one could do to tidy up OE/YP layers.
i was going to start off with just aesthetic prettification -- break
absurdly long assignments of multiple values into one per line, line
continuations, in alphabetical order, that sort of thing.
the next step would be, i think, to get familiar with bitbake.conf
and some of the bbclass files, and start removing superfluous content
from various recipes. case in point -- a pile of packagegroup recipe
files unnecessarily set:
PACKAGES = ${PN}
but that's the default so ... delete that sort of thing (as long as
there's no *real* reason for it to be there).
this might sound like grunt work but, as the term went on, i'd ask
him to do more research and come up with cleanups of his own as he
understood more of OE. i'd like to make this a truly productive term
for this guy.
any recommended docs that get to this level? i've already bookmarked
the standard YP docs, and a couple others.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193541):
https://lists.openembedded.org/g/openembedded-core/message/193541
Mute This Topic: https://lists.openembedded.org/mt/103661346/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] how to sneak a function into the *middle* of "prefuncs"?
On Wed, 3 Jan 2024, Richard Purdie wrote: > On Wed, 2024-01-03 at 11:21 -0500, Robert P. J. Day wrote: > > no, no, hear me out ... colleague has a vendor's YP build system and > > needs to -- in the middle of a bunch of a task's [prefuncs] -- sneak > > in a signing step. can't be at the beginning (what to be signed not > > created yet), and can't be at the end cuz by then it's too late as the > > artifact has been bundled. > > > > first, as i read it, for a given task, all of the prefuncs are > > invoked in exact L-to-R order, then the task is run, then all of the > > postfuncs are done in L-to-R order. then (and only the) does the > > processing move on to the next task. > > > > given limited freedom to change the vendor's recipes, my first > > thought was to define an "intermediate" task whose only purpose was to > > babysit the signing step, make the signing function either a prefunc > > or postfunc of that task (should not matter which), then redefine the > > preceding and subsequent tasks to split up all those functions > > properly so that the signing step sits in the middle where it belongs. > > > > am i overthinking this? and even if the code processes a single > > task's prefuncs and postfuncs in order, that's not the thing i really > > want to count on. > > > > thoughts? > > append or prepend one of the prefunc functions? h ... i embarrassingly had not thought of that. that might be the solution, thanks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193306): https://lists.openembedded.org/g/openembedded-core/message/193306 Mute This Topic: https://lists.openembedded.org/mt/103504749/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] how to sneak a function into the *middle* of "prefuncs"?
no, no, hear me out ... colleague has a vendor's YP build system and needs to -- in the middle of a bunch of a task's [prefuncs] -- sneak in a signing step. can't be at the beginning (what to be signed not created yet), and can't be at the end cuz by then it's too late as the artifact has been bundled. first, as i read it, for a given task, all of the prefuncs are invoked in exact L-to-R order, then the task is run, then all of the postfuncs are done in L-to-R order. then (and only the) does the processing move on to the next task. given limited freedom to change the vendor's recipes, my first thought was to define an "intermediate" task whose only purpose was to babysit the signing step, make the signing function either a prefunc or postfunc of that task (should not matter which), then redefine the preceding and subsequent tasks to split up all those functions properly so that the signing step sits in the middle where it belongs. am i overthinking this? and even if the code processes a single task's prefuncs and postfuncs in order, that's not the thing i really want to count on. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193293): https://lists.openembedded.org/g/openembedded-core/message/193293 Mute This Topic: https://lists.openembedded.org/mt/103504749/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] why does using ${AUTOREV} with kernel recipe rebuild every time?
i *know* i should know the answer to this, but someone just showed
me a build (WRLinux-based, but still relevant) where the linux kernel
recipe uses:
SRCREV_machine = ${AUTOREV}
which is what one reads in the WRL version of linux-yocto-custom.bb,
but also makes it clear in that recipe file that that is discouraged.
in any event, this appears to be forcing an entire rebuild of the
kernel every time, even in the presence of sstate-cache, so the
obvious question is, what is it about using ${AUTOREV} that defeats
the use of sstate-cache? apologies if this should be obvious.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192303):
https://lists.openembedded.org/g/openembedded-core/message/192303
Mute This Topic: https://lists.openembedded.org/mt/103151800/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] how to INSANE_SKIP duplicate installed files?
On Wed, 15 Nov 2023, Ross Burton wrote: > On 15 Nov 2023, at 10:13, Robert P. J. Day via lists.openembedded.org > wrote: > > i swear, i once did this but now i can't find the solution for > > allowing two recipes to install duplicate files. of course, the right > > answer is to fix the recipes but a colleague just wants to get his > > build to work so what is the quickest way to do the dangerous thing > > and allow overriding installed files? > > Recipes can create the same file, but they can’t be installed at the > same time. > > If two recipes install the same filename and they’re both pulled > into the sysroot via DEPENDS then that is a fatal error and you > can’t avoid it. > > If two packages install the same filename and they’re both pulled > into an image then that is a fatal error and you can’t avoid it. never mind, just learned this happened on Wind River Linux, not YP, *but* i swear that, some time back, this was happening to a colleague and there was some override setting that allowed it. or i'm just misremembering. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#190587): https://lists.openembedded.org/g/openembedded-core/message/190587 Mute This Topic: https://lists.openembedded.org/mt/102602347/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] how to INSANE_SKIP duplicate installed files?
i swear, i once did this but now i can't find the solution for allowing two recipes to install duplicate files. of course, the right answer is to fix the recipes but a colleague just wants to get his build to work so what is the quickest way to do the dangerous thing and allow overriding installed files? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#190582): https://lists.openembedded.org/g/openembedded-core/message/190582 Mute This Topic: https://lists.openembedded.org/mt/102602347/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] is it worth a newbie cleanup task to update "class Whatever(object)"?
just noticed that there is a lot of "class Something(object):" in oe-core, where AIUI, the argument of "object" is a throwback to Python2 and shouldn't(?) be necessary. is there any value in letting a newbie loose on a task to clean all that up? or is that more churn than it's worth? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189736): https://lists.openembedded.org/g/openembedded-core/message/189736 Mute This Topic: https://lists.openembedded.org/mt/102203669/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] doesn't seem like "PROFILE_TOOLS_X" has any value
if you look here: https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb#n12 it's not clear what PROFILE_TOOLS_X is doing, given that it's set to the empty string, then conditionally set to the same thing. i don't see it being referenced elsewhere. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189346): https://lists.openembedded.org/g/openembedded-core/message/189346 Mute This Topic: https://lists.openembedded.org/mt/102021731/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] why is it PROVIDES = "udev" and not PROVIDES = "virtual/udev"?
given that the PREFERRED_PROVIDER feature is typically used for "virtual" entities: * virtual/kernel * virtual/xserver * virtual/libgl and so on, is there a reason that this pattern is not followed for the selection of a udev provider, which is referred to as just "PREFERRED_PROVIDER_udev", and can be provided by either of systemd or eudev? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189316): https://lists.openembedded.org/g/openembedded-core/message/189316 Mute This Topic: https://lists.openembedded.org/mt/102012999/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] why does rust recipe file define "rust_do_install()"?
i'm perusing the rust_1.70.0.bb recipe file, and i'm puzzled by the
fact that it defines its own do_install() to simply call
rust_do_install(), which then implements variations of that function:
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/rust/rust_1.70.0.bb#n244
do_install () {
rust_do_install
}
rust_do_install() {
rust_runx install
}
rust_do_install:class-nativesdk() {
export PSEUDO_UNLOAD=1
rust_runx install
rust_runx install clippy
... snip ...
i'm familiar with bbclass files defining things like that; eg.,
autotools.bbclass defining:
autotools_do_install() {
oe_runmake 'DESTDIR=${D}' install it if it exists.
if [ -e "${D}${infodir}/dir" ]; then
rm -f ${D}${infodir}/dir
fi
}
but examples like that are generally then listed in EXPORT_FUNCTIONS
so subsequent recipes can invoke them as part of *their* do_install(),
like this snippet from the tar recipe:
do_install () {
autotools_do_install
ln -s tar ${D}${bindir}/gtar
}
but i'm not sure why the rust recipe file is doing what it's doing.
could it not have just defined variations of do_install() and gotten
the same effect? or is there something more subtle happening here?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189029):
https://lists.openembedded.org/g/openembedded-core/message/189029
Mute This Topic: https://lists.openembedded.org/mt/101936139/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] is there a command to produce artifacts of a recipe and all its "shlibdeps" packages?
this is possibly a silly question, but i have a YP build with one recipe (call it fubar") that has a number of DEPENDS, some of which generate shared libs that will also be runtime dependencies for fubar once it's installed. as i recall (and i could be wrong), the shared lib dependencies for fubar can be seen in the eventual file fubar/packages-split/fubar.shlibdeps. now i want to be able to bundle up the fubar package, walk it over, and drop it on a compatible device where i know it should run, but obviously i need to similarly bundle all of those shlibdeps to go with it. rather than manually doing each of those shlibdeps individually, is there some incantation such that i can create some sort of archive of a recipe and all of its runtime dependencies so that i can just take that entire single archive and drop it on the target device? i can't think of a simple way to do that, but perhaps others know some sort of magic. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#182019): https://lists.openembedded.org/g/openembedded-core/message/182019 Mute This Topic: https://lists.openembedded.org/mt/99245372/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] looking for a recipe for LXD container to do OE/YP builds
(not so much an OE question as a build question related to the proper design of LXD container for doing OE builds.) colleague asked me how to best create an LXD container based on a specific release (ubuntu 18.04); specifically, how to use idmapped mounts to correctly map a directory into the container so that UIDs don't step on each other, so here's the scenario. * (google repo-based) YP checkout that will, in the end, apparently generate 120BG(!!!) of output. * must be ubuntu 18.04 container based on versions of OE/YP layers being checked out the need to do this mapping is that, by default, when you shell into the LXD container, you're running as root, which of course will not work for running bitbake. and the tricky(?) part is that: 1) on my ubuntu 22.04 host, my account is rpjday/1000. 2) the non-root account created in the container is ubuntu/1000 so we already have a bit of conflict in matching UIDs attached to different usernames. i'm just trying to determine the preferred way to set up /etc/subuid and /etc/subgid and an LXC device so that i can map the entire build directory into the container, shell into the container, do the build there and have all the output go into the mapped directory so that it (obviously) ends up on my host and not in the container (where there is nowhere near 120G of space, and i don't want to resize the container to that extent). thoughts? i'm about to try a few combinations and might stumble across something that works, but if anyone else has gone through this and has a recipe, that would be just ducky. rday p.s. my first guess is that it might not be an issue that there are two different accounts with UID 1000, since ubuntu in the container will map nicely to my own account on the host. but we'll see shortly. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169232): https://lists.openembedded.org/g/openembedded-core/message/169232 Mute This Topic: https://lists.openembedded.org/mt/92953887/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] is "poky" distro defined to use "sysvinit" as INIT_MANAGER?
not sure why i never noticed this before, but i started a new project from the poky layer (not OE), and realized that poky.conf explicitly sets: INIT_MANAGER = "sysvinit" which can't be overridden in my local.conf. if i want systemd, i guess i can initialize my project from the OE layer, and i also notice that i could use poky-altcfg.conf. but is there a reason that the default poky-based project fixes INIT_MANAGER to "sysvinit". perhaps just for simplicity? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167735): https://lists.openembedded.org/g/openembedded-core/message/167735 Mute This Topic: https://lists.openembedded.org/mt/92210454/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] what happens if an included layer contains a "conf/site.conf" file?
On Thu, 26 May 2022, richard.pur...@linuxfoundation.org wrote: > On Thu, 2022-05-26 at 10:51 -0400, Robert P. J. Day wrote: > > still trying to isolate some weirdness from this morning, but i'm > > playing with a vendor's amazingly convoluted BSP which wraps a bunch > > of thud-generation layers in some shell scripts. > > > > long story short: given some gcc-generated compiler errors, i added > > a site.conf file under conf/ in the build directory, and included in > > it a single CFLAGS-related no-error setting. > > > > suddenly, i began getting a slew of recipe parse errors from the > > fetch step, complaining about failure to parse numerous SRC_URI > > values, all of which started with a variable that represented the top > > level URL for the source. suspecting that the variable in question was > > somehow undefined, i set it explicitly in my new site.conf, which > > solved *those* parse errors but displayed more based on a *different* > > leading variable. so i fixed that and etc, etc, etc. > > > > i was baffled as to where these variables should have been set, and > > how they must have been set all this time until recently, until i > > tracked down an obscure layer that was being pulled in, which provided > > a site.conf file that defined those variables. > > > > which inspires me to ask -- is there a priority to including the > > file "site.conf" such that it will be pulled in from a layer unless > > there's an overriding version of that file in the build directory? > > i've never run across this before. > > It works just like any other conf file. The first one found in BBPATH > wins. > > Layers should not have site.conf files in them. that's what i wanted to hear -- that i should not have had to debug someone sneaking a site.conf into a single layer mixed in with 40 other layers. thanks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166185): https://lists.openembedded.org/g/openembedded-core/message/166185 Mute This Topic: https://lists.openembedded.org/mt/91356020/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] what happens if an included layer contains a "conf/site.conf" file?
still trying to isolate some weirdness from this morning, but i'm playing with a vendor's amazingly convoluted BSP which wraps a bunch of thud-generation layers in some shell scripts. long story short: given some gcc-generated compiler errors, i added a site.conf file under conf/ in the build directory, and included in it a single CFLAGS-related no-error setting. suddenly, i began getting a slew of recipe parse errors from the fetch step, complaining about failure to parse numerous SRC_URI values, all of which started with a variable that represented the top level URL for the source. suspecting that the variable in question was somehow undefined, i set it explicitly in my new site.conf, which solved *those* parse errors but displayed more based on a *different* leading variable. so i fixed that and etc, etc, etc. i was baffled as to where these variables should have been set, and how they must have been set all this time until recently, until i tracked down an obscure layer that was being pulled in, which provided a site.conf file that defined those variables. which inspires me to ask -- is there a priority to including the file "site.conf" such that it will be pulled in from a layer unless there's an overriding version of that file in the build directory? i've never run across this before. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166183): https://lists.openembedded.org/g/openembedded-core/message/166183 Mute This Topic: https://lists.openembedded.org/mt/91356020/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] sanity.bbclass: grammar/typo fixes re: Python install
Clean up various spelling/grammar oopsies in a small section of sanity.bbclass. Signed-off-by: Robert P. J. Day --- diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index b416918013..491a3bac6f 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -631,11 +631,14 @@ def check_sanity_sstate_dir_change(sstate_dir, data): def check_sanity_version_change(status, d): # Sanity checks to be done when SANITY_VERSION or NATIVELSBSTRING changes # In other words, these tests run once in a given build directory and then -# never again until the sanity version or host distrubution id/version changes. +# never again until the sanity version or host distribution id/version changes. + +# Verify that the python install is complete. Examples that are often removed in +# minimal installations: +# +# glib-2.0-native requires xml.parsers.expat +# icu requires distutils.sysconfig -# Check the python install is complete. Examples that are often removed in -# minimal installations: glib-2.0-natives requries # xml.parsers.expat and icu -# requires distutils.sysconfig. try: import xml.parsers.expat import distutils.sysconfig -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca LinkedIn: http://ca.linkedin.com/in/rpjday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165538): https://lists.openembedded.org/g/openembedded-core/message/165538 Mute This Topic: https://lists.openembedded.org/mt/91054003/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] local.conf.sample: mention other QEMU targets in OE
Mention that there are other QEMU targets available in the OE layer, and leave it for the reader to check them out. Signed-off-by: Robert P. J. Day --- i think this is the happy medium between not saying anything about the additional QEMU machines, and promoting them to full equality with the other layers -- just let the reader know where they can examine them. diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample index c05691de58..c28ff62468 100644 --- a/meta/conf/local.conf.sample +++ b/meta/conf/local.conf.sample @@ -29,7 +29,11 @@ # This sets the default machine to be qemux86-64 if no other machine is selected: MACHINE ??= "qemux86-64" -# +# Note that the openembedded-core layer defines a few more QEMU targets that +# are not listed here as they are not tested as robustly as the above, but they +# are still available for the adventurous; see the full list at: +# https://git.openembedded.org/openembedded-core/tree/meta/conf/machine + # Where to place downloads # # During a first build the system will download many different source code tarballs -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca LinkedIn: http://ca.linkedin.com/in/rpjday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165537): https://lists.openembedded.org/g/openembedded-core/message/165537 Mute This Topic: https://lists.openembedded.org/mt/91053878/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] local.conf.sample: add comments for missing machines
On Wed, 11 May 2022, Alexander Kanavin wrote: > I would rather just refer to the directory where 'additional, less > well tested machines are'. > > Alex sure, something like that works for me. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165499): https://lists.openembedded.org/g/openembedded-core/message/165499 Mute This Topic: https://lists.openembedded.org/mt/91032627/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] local.conf.sample: add comments for missing machines
On Wed, 11 May 2022, Alexander Kanavin wrote: > I have to note that the project does not test these machines, and they > may not necessarily work. Advertising them in local.conf may result in > frustrating fails for people who are running bitbake for the very > first time. > > Alex > > On Wed, 11 May 2022 at 12:48, Robert P. J. Day wrote: > > > > > > Fill out the commented list of supported machines for completeness. > > > > Signed-off-by: Robert P. J. Day > > > > --- > > > > diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample > > index c05691de58..f0b8952947 100644 > > --- a/meta/conf/local.conf.sample > > +++ b/meta/conf/local.conf.sample > > @@ -20,9 +20,13 @@ > > # > > #MACHINE ?= "qemuarm" > > #MACHINE ?= "qemuarm64" > > +#MACHINE ?= "qemuarmv5" > > #MACHINE ?= "qemumips" > > #MACHINE ?= "qemumips64" > > #MACHINE ?= "qemuppc" > > +#MACHINE ?= "qemuppc64" > > +#MACHINE ?= "qemuriscv32" > > +#MACHINE ?= "qemuriscv64" > > #MACHINE ?= "qemux86" > > #MACHINE ?= "qemux86-64" > > # that's the first thing i thought of, but what is a cleaner solution? if those machine definitions come with OE, then why should they be treated as second-class citizens? if those machines aren't tested, then maybe an extra comment pointing that out would be appropriate. i just think this should be consistent. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165497): https://lists.openembedded.org/g/openembedded-core/message/165497 Mute This Topic: https://lists.openembedded.org/mt/91032627/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] local.conf.sample: add comments for missing machines
Fill out the commented list of supported machines for completeness. Signed-off-by: Robert P. J. Day --- diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample index c05691de58..f0b8952947 100644 --- a/meta/conf/local.conf.sample +++ b/meta/conf/local.conf.sample @@ -20,9 +20,13 @@ # #MACHINE ?= "qemuarm" #MACHINE ?= "qemuarm64" +#MACHINE ?= "qemuarmv5" #MACHINE ?= "qemumips" #MACHINE ?= "qemumips64" #MACHINE ?= "qemuppc" +#MACHINE ?= "qemuppc64" +#MACHINE ?= "qemuriscv32" +#MACHINE ?= "qemuriscv64" #MACHINE ?= "qemux86" #MACHINE ?= "qemux86-64" # -- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165494): https://lists.openembedded.org/g/openembedded-core/message/165494 Mute This Topic: https://lists.openembedded.org/mt/91032627/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] should local.conf.sample include MACHINEs related to RISC-V?
On Wed, 11 May 2022, Alistair Francis wrote: > On Wed, May 11, 2022 at 12:06 PM Robert P. J. Day > wrote: > > > > > > just now noticed that while oe-core includes machine definitions for > > qemuriscv*, local.conf.sample does not mention them. is this just an > > oversight? > > Yeah, that's just an oversight. If you want you can send a patch :) on it. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165493): https://lists.openembedded.org/g/openembedded-core/message/165493 Mute This Topic: https://lists.openembedded.org/mt/91032184/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] should local.conf.sample include MACHINEs related to RISC-V?
just now noticed that while oe-core includes machine definitions for qemuriscv*, local.conf.sample does not mention them. is this just an oversight? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#165491): https://lists.openembedded.org/g/openembedded-core/message/165491 Mute This Topic: https://lists.openembedded.org/mt/91032184/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] does "do_kernel_metadata()" not generate any output in some cases?
colleague is playing with RISC-V, building QEMU images, and wanted
to know how the kernel is fetched and configured and built and so on,
so i decided to list the kernel tasks and write a short summary of
what each does (since i think this will be useful shortly), and what
artifacts it generates for use by subsequent steps, and i was doing
fine until i got to do_kernel_metadata(), where i can see that it is
invoked twice:
- first time in "patch" mode
- second time from do_kernel_configme() in "config" mode
but when i bitbake'd the kernel_metadata task for my generic x86-64
kernel, i couldn't find any generated artifacts from that step.
certainly, stuff is going to be created later during the
kernel_configme() task when that task is invoked again, and it appears
that a fair bit of code will be re-run, but is it the case that,
because i'm building a really trivial configuration (all i've added is
a single .cfg file to demonstrate how it's processed), that the first
call to kernel_metadata() figures it has nothing to generate?
i can see all of the output from the tail end of that routine:
if [ ${KCONF_AUDIT_LEVEL} -gt 0 ]; then
bbnote "kernel meta data summary for ${KMACHINE} (${LINUX_KERNEL_TYPE}):"
bbnote
"=="
if [ -n "${KMETA_EXTERNAL_BSPS}" ]; then
bbnote "Non kernel-cache (external) bsp"
fi
bbnote "BSP entry point / definition: $bsp_definition"
if [ -n "$in_tree_defconfig" ]; then
bbnote "KBUILD_DEFCONFIG: ${KBUILD_DEFCONFIG}"
fi
bbnote "Fragments from SRC_URI: $sccs_from_src_uri"
bbnote "KERNEL_FEATURES: $KERNEL_FEATURES_FINAL"
bbnote "Final scc/cfg list: $sccs_defconfig $bsp_definition $sccs
$KERNEL_FEATURES_FINAL"
fi
but i don't see where in kernel_metadata() any of that is *saved* so
that it doesn't have to be recalculated. again, i'm building a stock
qemux86-64 image, and adding a single .cfg file (no patches), so maybe
this example is so trivial that nothing is generated.
thoughts?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162787):
https://lists.openembedded.org/g/openembedded-core/message/162787
Mute This Topic: https://lists.openembedded.org/mt/89590057/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] various typo/grammar/punctuation fixes
Among other things, fix misspellings of:
- absolute
- deprecated
- suitable
- handle
and a bunch of other things.
Signed-off-by: Robert P. J. Day
---
was perusing runqemu script, so most changes are there but checked
around for other stuff at the same time.
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 5637a02451..642f0eb637 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -217,7 +217,7 @@ class TestImage(OESelftestTestCase):
if distro and distro in ['debian-9', 'debian-10', 'centos-7',
'centos-8', 'ubuntu-16.04', 'ubuntu-18.04', 'almalinux-8.5']:
self.skipTest('virgl headless cannot be tested with %s' %(distro))
-render_hint = """If /dev/dri/renderD* is absent due to lack of
suitable GPU, 'modprobe vgem' will create one sutable for mesa llvmpipe sofware
renderer."""
+render_hint = """If /dev/dri/renderD* is absent due to lack of
suitable GPU, 'modprobe vgem' will create one suitable for mesa llvmpipe
software renderer."""
try:
content = os.listdir("/dev/dri")
if len([i for i in content if i.startswith('render')]) == 0:
diff --git a/scripts/crosstap b/scripts/crosstap
index 73c8947442..5aa72f14d4 100755
--- a/scripts/crosstap
+++ b/scripts/crosstap
@@ -353,7 +353,7 @@ bitbake workspace.
Anything after -- option is passed directly to stap.
-Legacy script invocation style supported but depreciated:
+Legacy script invocation style supported but deprecated:
%prog [systemtap options]
To enable most out of systemtap the following site.conf or local.conf
diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 5a51fa793f..d4ac074ad9 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -94,9 +94,9 @@ into your configuration please add entries to
conf/bblayers.conf.
EOM
-# Put the abosolute path to the layers in bblayers.conf so we can run
-# bitbake without the init script after the first run
-# ##COREBASE## is deprecated as it's meaning was inconsistent, but continue
+# Put the absolute path to the layers in bblayers.conf so we can run
+# bitbake without the init script after the first run.
+# ##COREBASE## is deprecated as its meaning was inconsistent, but continue
# to replace it for compatibility.
sed -e "s|##OEROOT##|$OEROOT|g" \
-e "s|##COREBASE##|$OEROOT|g" \
@@ -115,7 +115,7 @@ The Yocto Project has extensive documentation about OE
including a reference
manual which can be found at:
https://docs.yoctoproject.org
-For more information about OpenEmbedded see their website:
+For more information about OpenEmbedded see the website:
https://www.openembedded.org/
EOM
diff --git a/scripts/runqemu b/scripts/runqemu
index 5c108ec23a..9ddd47267c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -73,11 +73,11 @@ of the following environment variables (in any order):
gl-es - enable virgl-based GL acceleration, using OpenGL ES (also needs
gtk or sdl options)
egl-headless - enable headless EGL output; use vnc (via publicvnc option)
or spice to see it
(hint: if /dev/dri/renderD* is absent due to lack of suitable GPU,
'modprobe vgem' will create
-one sutable for mesa llvmpipe sofware renderer)
+one suitable for mesa llvmpipe software renderer)
serial - enable a serial console on /dev/ttyS0
serialstdio - enable a serial console on the console (regardless of
graphics mode)
-slirp - enable user networking, no root privileges is required
-snapshot - don't write changes to back to images
+slirp - enable user networking, no root privilege is required
+snapshot - don't write changes back to images
kvm - enable KVM when running x86/x86_64 (VT-capable CPU required)
kvm-vhost - enable KVM with vhost when running x86/x86_64 (VT-capable CPU
required)
publicvnc - enable a VNC server open to all hosts
@@ -352,10 +352,10 @@ class BaseConfig(object):
def check_arg_path(self, p):
"""
- Check whether it is .qemuboot.conf or contains
.qemuboot.conf
-- Check whether is a kernel file
-- Check whether is a image file
-- Check whether it is a nfs dir
-- Check whether it is a OVMF flash file
+- Check whether it is a kernel file
+- Check whether it is an image file
+- Check whether it is an NFS dir
+- Check whether it is an OVMF flash file
"""
if p.endswith('.qemuboot.conf'):
self.qemuboot = p
@@ -366,7 +366,7 @@ class BaseConfig(object):
self.kernel = p
elif os.path.exists(p) and (not os.path.isdir(p)) and '-image-' in
os.path.basename(p):
self.rootfs = p
-
Re: [OE-core] ROOTFS_POSTPROCESS_COMMAND versus do_install_append() and using ${D}?
On Tue, 14 Dec 2021, Ross Burton wrote:
> On Tue, 14 Dec 2021 at 11:39, Robert P. J. Day wrote:
> > what i'm looking at now does it in a more curious way. there is
> > a catch-all recipe file (call it "catchall.bb") which lists, as
> > its DEPENDS list, *all* of the recipes that make up the image,
> > which means that building catchall.bb builds and populates an
> > image directory with the combination of all those other recipes,
> > after which it defines both pkg_postinst_${PN} *and*
> > do_install_append(), both of which run around and make changes
> > relative to ${D}, given that the image directory for that recipe
> > effectively contains, well, everything that will go into the
> > rootfs.
>
> Either you're explaining badly, or that isn't doing what you expect.
>
> A normal catchall.bb recipe which DEPENDS on all other relevant
> recipes will result in the recipe-sysroot directory containing the
> sysroots for those recipes, but that is all. the image directory
> won't contain anything apart from what catchall.bb's do_install
> installs.
yes, i was explaining badly ... actually, no, i just had no idea
what i was talking about, so let's try again.
stripped down version: i'm trying to clarify in my own mind the
myriad of ways one can customize a package/rootfs/image, via
do_install:append(), or pkg_postinst...,
or ROOTFS_{PRE,POST}...COMMAND, or IMAGE_..._COMMAND, and so on, but
let's start simple.
in a recipe i was handed from a working system, there are two
customizations:
1) pkg_postinst_${PN} runs a bunch of "setcap"s
2) do_install_append() installs stuff into ${D}, and also runs
a number of chown/chmod commands, and creates a couple of
hard links
no one can explain to me why both features are being used, so it's
either because those two things run in different contexts, or perhaps
they were added once upon a time by two different people.
so the firist question is, is there some requirement that the above
was done precisely that wasy?
second question: is there somewhere in the docs a comprehensive list
of all the different ways to customize stuff as i mentioned above? a
colleague asked me this very thing, and i had to admit i didn't know
the full list so i would take a look (and maybe even write something
up).
thoughts?
rday
p.s. i'm going to ask later about specifics of pkg_postinst() since
i'm still unclear on the exact mechanics.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159722):
https://lists.openembedded.org/g/openembedded-core/message/159722
Mute This Topic: https://lists.openembedded.org/mt/87719024/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] ROOTFS_POSTPROCESS_COMMAND versus do_install_append() and using ${D}?
On Tue, 14 Dec 2021, Ross Burton wrote:
> On Tue, 14 Dec 2021 at 11:39, Robert P. J. Day wrote:
> > what i'm looking at now does it in a more curious way. there is a
> > catch-all recipe file (call it "catchall.bb") which lists, as its
> > DEPENDS list, *all* of the recipes that make up the image, which means
> > that building catchall.bb builds and populates an image directory with
> > the combination of all those other recipes, after which it defines
> > both pkg_postinst_${PN} *and* do_install_append(), both of which run
> > around and make changes relative to ${D}, given that the image
> > directory for that recipe effectively contains, well, everything that
> > will go into the rootfs.
>
> Either you're explaining badly, or that isn't doing what you expect.
>
> A normal catchall.bb recipe which DEPENDS on all other relevant
> recipes will result in the recipe-sysroot directory containing the
> sysroots for those recipes, but that is all. the image directory
> won't contain anything apart from what catchall.bb's do_install
> installs.
yeah, i was typing quickly and screwed up my explanation totally.
i'll try again after imminent meeting. le *sigh*.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159691):
https://lists.openembedded.org/g/openembedded-core/message/159691
Mute This Topic: https://lists.openembedded.org/mt/87719024/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ROOTFS_POSTPROCESS_COMMAND versus do_install_append() and using ${D}?
i've run across a moderately curious example of doing rootfs-wide
tweaking in an odd way.
my understanding is that, after i've created my basic image rootfs,
i can define that image's ROOTFS_POSTPROCESS_COMMAND variable, and do
all sorts of rootfs-wide adjustments relative to ${IMAGE_ROOTFS},
which could include running chown, chmod, setcap, and so on and so on,
tweaking clearly spread over various installed package contents.
what i'm looking at now does it in a more curious way. there is a
catch-all recipe file (call it "catchall.bb") which lists, as its
DEPENDS list, *all* of the recipes that make up the image, which means
that building catchall.bb builds and populates an image directory with
the combination of all those other recipes, after which it defines
both pkg_postinst_${PN} *and* do_install_append(), both of which run
around and make changes relative to ${D}, given that the image
directory for that recipe effectively contains, well, everything that
will go into the rootfs.
at the moment, it works, but in a perfect world, i'd refactor all
that stuff and sprinkle it among the respective recipes that that
content relates to. however, just to get this going, my initial
reaction is to take that tweaking, adjust it to refer, not to ${D},
but to ${IMAGE_ROOTFS}, and move it all into
ROOTFS_POSTPROCESS_COMMAND. theoretically, would that be effectively
equivalent?
i realize there might be some messing around but, in the big
picture, should it have the same effect?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159685):
https://lists.openembedded.org/g/openembedded-core/message/159685
Mute This Topic: https://lists.openembedded.org/mt/87719024/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] when a systemd service is not listed in "SYSTEMD_PACKAGES"
On Sun, 12 Dec 2021, Robert P. J. Day wrote:
>
> was writing up a wiki page for colleagues at my current gig about
> the proper definition of systemd services, and noticed the following
> oddity(?).
>
> in current poky master branch, openssh recipe, SRC_URI includes the
> following two lines:
>
> file://sshd@.service \
> file://sshdgenkeys.service \
>
> fair enough, two systemd services. however, further down the recipe
> file, only one of them is included in:
>
> SYSTEMD_PACKAGES = "${PN}-sshd"
> SYSTEMD_SERVICE:${PN}-sshd = "sshd.socket"
>
> so what happened to the service sshdgenkeys? ah, if one looks in the
> files being installed by openssh for that string:
>
> $ grep sshdgenkeys *
> sshd@.service:After=sshdgenkeys.service
> sshd.socket:Wants=sshdgenkeys.service
> $
>
> so i am *assuming* that even though sshdgenkeys is an actual systemd
> service, it will only be invoked via the sshd service or socket units,
> and therefore does not need to be included in SYSTEMD_PACKAGES.
>
> is that the right interpretation? or am i missing something?
never mind, i think i see what i misunderstood.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159583):
https://lists.openembedded.org/g/openembedded-core/message/159583
Mute This Topic: https://lists.openembedded.org/mt/87675663/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] when a systemd service is not listed in "SYSTEMD_PACKAGES"
was writing up a wiki page for colleagues at my current gig about
the proper definition of systemd services, and noticed the following
oddity(?).
in current poky master branch, openssh recipe, SRC_URI includes the
following two lines:
file://sshd@.service \
file://sshdgenkeys.service \
fair enough, two systemd services. however, further down the recipe
file, only one of them is included in:
SYSTEMD_PACKAGES = "${PN}-sshd"
SYSTEMD_SERVICE:${PN}-sshd = "sshd.socket"
so what happened to the service sshdgenkeys? ah, if one looks in the
files being installed by openssh for that string:
$ grep sshdgenkeys *
sshd@.service:After=sshdgenkeys.service
sshd.socket:Wants=sshdgenkeys.service
$
so i am *assuming* that even though sshdgenkeys is an actual systemd
service, it will only be invoked via the sshd service or socket units,
and therefore does not need to be included in SYSTEMD_PACKAGES.
is that the right interpretation? or am i missing something?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159582):
https://lists.openembedded.org/g/openembedded-core/message/159582
Mute This Topic: https://lists.openembedded.org/mt/87675663/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] anyone played with TAS (TCP acceleration service) in OE?
colleague just asked me about the viability of TAS in OE: https://tcp-acceleration-service.github.io/documents/tas_slides.pdf i've never even heard of it ... anyone crammed it into an OE build? rdayu -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158479): https://lists.openembedded.org/g/openembedded-core/message/158479 Mute This Topic: https://lists.openembedded.org/mt/87151613/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] how to "prune" dead sstate-cache?
On Thu, 18 Nov 2021, Alexander Kanavin wrote: > There is a caveat here. This will touch all sstate that is needed to > construct an image, but won't touch sstate needed to build > components that go into the image. So target packages are guaranteed > to be kept, but native items may be deleted - I've seen this with > e.g. java compiler that is used for few specific, rarely changing > items. i'm willing to allow the pruning to go a little overboard since it will just be recreated. i'm fine with that. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158476): https://lists.openembedded.org/g/openembedded-core/message/158476 Mute This Topic: https://lists.openembedded.org/mt/87140377/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] how to "prune" dead sstate-cache?
On Thu, 18 Nov 2021, Martin Jansa wrote: > openembedded-core/scripts/sstate-cache-management.sh i just now found that script, and noticed that it is not documented anywhere in the YP docs. perhaps we need a short section on sstate-cache management somewhere in the docs. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158471): https://lists.openembedded.org/g/openembedded-core/message/158471 Mute This Topic: https://lists.openembedded.org/mt/87140377/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] how to "prune" dead sstate-cache?
assuming my (correct) understanding of sstate-cache is that, as time goes by, it just gets larger and larger, it will increasingly contain content that is of little value anymore, what is the simplest way to purge or prune entries that are no longer involved in any desired builds? i'm guessing a simple way to do that is to first delete tmp/, then build any current targets/images, immediately followed by something like: $ find sstate-cache -type f -atime +1 -delete is there anything fancier than that? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158468): https://lists.openembedded.org/g/openembedded-core/message/158468 Mute This Topic: https://lists.openembedded.org/mt/87140377/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] just want to confirm my understanding of how systemd services get symlinks
just had a discussion with a colleague about the proper design of a
systemd-based service, and my (admittedly sophomore) understanding is
that, in the service file, there is an [Install] section, which
contains a "WantedBy" line like:
fubar.service:WantedBy=sysinit.target
upon installation in the image, from systemd.bbclass. the routine
systemd_postinst() is invoked which (among other things), does this:
if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
for service in ${SYSTEMD_SERVICE_ESCAPED}; do
systemctl ${OPTS} enable "$service"
done
fi
and my understanding is that it is that call to "systemctl" that
creates the appropriate symlink so that that service now exists under
the directory "sysinit.target.wants".
my need for confirmation is based on muh collegaue's pointing at
some existing systemd-based recipes in some legacy code, which
manually do the following in do_install_append():
ln -s ${sysconfdir}/systemd/system/fubar.service \
${D}/${sysconfdir}/systemd/system/sysinit.target.wants/
i'm pretty sure that that "ln" command is unnecessary as long as the
service file is defined properly, but now i just want to get that
confirmed.
rday
p.s. hmm ... i wonder if the original recipe designer was unaware
of systemd.bbclass and thought he had to do it all manually.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156621):
https://lists.openembedded.org/g/openembedded-core/message/156621
Mute This Topic: https://lists.openembedded.org/mt/86073990/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] simplest use of SSTATE_MIRRORS?
On Tue, 28 Sep 2021, Richard Purdie wrote: > On Mon, 2021-09-27 at 12:13 -0400, Robert P. J. Day wrote: > > colleague asked me how SSTATE_MIRRORS worked, so i had to check, > > followed the section here: > > > > http://docs.yoctoproject.org/overview-manual/concepts.html#shared-state-cache > > > > and in one of own builds, i moved the entire sstate-cache directory > > to ~/SSTATE as is, then added the following to my site.conf: > > > > SSTATE_MIRRORS = " \ > > file://.\* file:///home/rpjday/SSTATE/PATH \ > > " > > > > then i removed all of /tmp in my current build, and re-ran my > > bitbake command, but it seems to be doing all the standard fetching > > and unpacking and so on. what clearly trivial step have i overlooked? > > > > rday > > > > p.s. i checked with "bitbake -e" that that variable seems to have the > > correct value. what silliness have i done? > > The other gotcha with this now is hash equivalence. If that is active, you > need > both the sstate data and hash equivalence data that match. i did notice that in the sstate section in the manual, and was digging into it as we speak. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156414): https://lists.openembedded.org/g/openembedded-core/message/156414 Mute This Topic: https://lists.openembedded.org/mt/85904527/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] simplest use of SSTATE_MIRRORS?
Quoting Andre McCurdy : On Mon, Sep 27, 2021 at 9:13 AM Robert P. J. Day wrote: colleague asked me how SSTATE_MIRRORS worked, so i had to check, followed the section here: http://docs.yoctoproject.org/overview-manual/concepts.html#shared-state-cache and in one of own builds, i moved the entire sstate-cache directory to ~/SSTATE as is, then added the following to my site.conf: SSTATE_MIRRORS = " \ file://.\* file:///home/rpjday/SSTATE/PATH \ " The example in local.conf.sample uses file://.* rather than file://.\* i noticed that a bit later, made the change and all good. so i guess i'll submit a patch for the manual. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156399): https://lists.openembedded.org/g/openembedded-core/message/156399 Mute This Topic: https://lists.openembedded.org/mt/85904527/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] simplest use of SSTATE_MIRRORS?
colleague asked me how SSTATE_MIRRORS worked, so i had to check, followed the section here: http://docs.yoctoproject.org/overview-manual/concepts.html#shared-state-cache and in one of own builds, i moved the entire sstate-cache directory to ~/SSTATE as is, then added the following to my site.conf: SSTATE_MIRRORS = " \ file://.\* file:///home/rpjday/SSTATE/PATH \ " then i removed all of /tmp in my current build, and re-ran my bitbake command, but it seems to be doing all the standard fetching and unpacking and so on. what clearly trivial step have i overlooked? rday p.s. i checked with "bitbake -e" that that variable seems to have the correct value. what silliness have i done? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156390): https://lists.openembedded.org/g/openembedded-core/message/156390 Mute This Topic: https://lists.openembedded.org/mt/85904527/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] what is "INHIBIT_PACKAGE_DEBUG_SPLIT" supposed to do?
i was experimenting with various packaging schemes using different values for PACKAGE_DEBUG_SPLIT_STYLE, then decided to see the effect of setting INHIBIT_PACKAGE_DEBUG_SPLIT -- when using the split style of "debug-with-pkgsrc", i got the expected (separate) debug and src packages. but when i then set INHIBIT_PACKAGE_DEBUG_SPLIT to '1', the contents of both the dbg and src packages disappeared entirely, and nothing extra was placed in the base package. in short, i lost all debugging and source content entirely. is that what i should expect? it seems counter-intuitive. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156157): https://lists.openembedded.org/g/openembedded-core/message/156157 Mute This Topic: https://lists.openembedded.org/mt/85717993/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] how to manually discard some SDK content before bundling up the SDK?
another off-the-wall question but i want to delete some content from a standard SDK (sysroots/cortex.../usr/src) before creating the final .sh script but, because of the slightly weird way this SDK is bring created via "bitbake -c populate_sdk ...", i have little control of most of the creation process other than right toward the end, where the easiest way to do this would be to just sneak in a "rm -rf ..." command at the appropriate time before the step that creates the tarball and appends it to the .sh script in populate_sdk_base.bbclass. the SDK_PRE_INSTALL and SDK_POST_INSTALL variables would not quite do it as i want to discard that content *before* creating the SDK so that it is not in the tarball at all. i'm digging through populate_sdk_base.bbclass right now, working backwards from the final SDK creation step to see where i can get away with this, but if there's a simple answer, that would be just ducky. in exchange for an answer, I'll proofread more documentation. :-) rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155994): https://lists.openembedded.org/g/openembedded-core/message/155994 Mute This Topic: https://lists.openembedded.org/mt/85585519/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] can one identify how much work sstate cache would save a build?
Quoting Richard Purdie : On Sun, 2021-09-12 at 10:00 -0400, Robert P. J. Day wrote: off the wall question from a friend, but is there a way to get a general idea of how much work (how many tasks?) could be saved for a build based on some available sstate cache directory? Run a build with bitbake -n against it and there is a summary printed near the start of the build which says something like: Sstate summary: Wanted 1525 Local 0 Network 1515 Missed 10 Current 0 (99% match, 0% complete) that's it, that's what i was looking for, thanks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155954): https://lists.openembedded.org/g/openembedded-core/message/155954 Mute This Topic: https://lists.openembedded.org/mt/85551776/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] can one identify how much work sstate cache would save a build?
off the wall question from a friend, but is there a way to get a general idea of how much work (how many tasks?) could be saved for a build based on some available sstate cache directory? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155946): https://lists.openembedded.org/g/openembedded-core/message/155946 Mute This Topic: https://lists.openembedded.org/mt/85551776/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] minor curiosity related to libdir vs base_libdir and shared libs
On Tue, 7 Sep 2021, Andre McCurdy wrote:
... snip ...
> The original commit from 2013 gives a few more clues in this case:
>
>
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=587fdba43a7747992995029a88d3051ef0efe7f6
>
> It's not explicit which QA test was being triggered but presumably
> it was "unsafe-references-in-binaries", which has since been dropped
> from oe-core:
>
>
> https://git.openembedded.org/openembedded-core/commit/?id=a6af5bbf3dad6f0951c67a0aae13ef86a8906893
>
> So... it looks like these examples of moving libs to base_libdir are
> obsolete and can be dropped.
just for fun, there is the occasional recipe that relocates stuff in
the *other* direction, like this from e2fsprogs_1.46.4.bb:
do_install () {
oe_runmake 'DESTDIR=${D}' install
oe_runmake 'DESTDIR=${D}' install-libs
# We use blkid from util-linux now so remove from here
rm -f ${D}${base_libdir}/libblkid*
rm -rf ${D}${includedir}/blkid
rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
rm -f ${D}${base_sbindir}/blkid
rm -f ${D}${base_sbindir}/fsck
rm -f ${D}${base_sbindir}/findfs
# e2initrd_helper and the pkgconfig files belong in libdir
if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
install -d ${D}${libdir}
mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
fi
... snip ...
and libusb1_1.0.24.bb:
do_install:append() {
install -d ${D}${libdir}
if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
fi
}
anyway, i'll let others decide if that's worth tidying up.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155750):
https://lists.openembedded.org/g/openembedded-core/message/155750
Mute This Topic: https://lists.openembedded.org/mt/85398874/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] minor curiosity related to libdir vs base_libdir and shared libs
On Tue, 7 Sep 2021, Andre McCurdy wrote:
> On Sun, Sep 5, 2021 at 1:02 PM Robert P. J. Day wrote:
> > a minor oddity i stumbled over digging into the proper installation
> > of shared libraries ... building core-image-minimal for qemuarm64 and,
> > for the most part, recipes from oe-core that install shared libs put
> > all three artifacts (real name, so name and linker name) under
> > /usr/lib, as in:
> >
> > ./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so
> > ./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so.3
> > ./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so.3.0.0
> >
> > however, the *occasional* recipe chooses to -- for whatever reason --
> > distinguish between libdir and base_libdir. for example, here's the
> > result of installing tcp-wrappers' shared libs in its ${D} directory:
> >
> > ./tcp-wrappers/7.6-r10/image/lib/libwrap.so.0.7.6
> > ./tcp-wrappers/7.6-r10/image/lib/libwrap.so.0
> > ./tcp-wrappers/7.6-r10/image/usr/lib/libwrap.so
> >
> > this is due to the following manual override in tcp-wrappers_7.6.bb:
> >
> > do_install () {
> > oe_libinstall -a libwrap ${D}${libdir}
> > oe_libinstall -C shared -so libwrap ${D}${base_libdir}
> >
> > if [ "${libdir}" != "${base_libdir}" ] ; then
> > rel_lib_prefix=`echo ${libdir} | sed
> > 's,\(^/\|\)[^/][^/]*,..,g'`
> > libname=`readlink ${D}${base_libdir}/libwrap.so | xargs
> > basename`
> > ln -s ${rel_lib_prefix}${base_libdir}/${libname}
> > ${D}${libdir}/libwrap.so
> > rm -f ${D}${base_libdir}/libwrap.so
> > fi
> > ...
> >
> > so this recipe -- after doing the *default* shared lib installation
> > via oe_libinstall() -- conditionally chooses to override that.
>
> git blame is often the best starting point for understanding why
> things are done in a certain way. In this case the comment from the
> original comment (from 11 years ago..) references portmap, which is no
> longer supported by oe-core:
>
>
> https://git.openembedded.org/openembedded-core/commit/?id=6ffc4f2e04f2d405b14f198220a3613d386489e7
>
> > another recipe that is even odder is libcap-ng:
> >
> > ./libcap-ng/0.8.2-r0/image/lib/libcap-ng.so.0.0.0
> > ./libcap-ng/0.8.2-r0/image/lib/libcap-ng.so.0
> > ./libcap-ng/0.8.2-r0/image/usr/lib/libcap-ng.so
> > ./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so.0
> > ./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so
> > ./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so.0.0.0
> >
> > which seems odd since it does that override for *one* of the shared
> > libs that it generates, but not the other:
> >
> > do_install:append() {
> > # Moving libcap-ng to base_libdir
> > if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
> > mkdir -p ${D}/${base_libdir}/
> > mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/
> > relpath=${@os.path.relpath("${base_libdir}", "${libdir}")}
> > ln -sf ${relpath}/libcap-ng.so.0.0.0
> > ${D}${libdir}/libcap-ng.so
> > fi
> > }
>
> The original commit from 2013 gives a few more clues in this case:
>
>
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=587fdba43a7747992995029a88d3051ef0efe7f6
>
> It's not explicit which QA test was being triggered but presumably it
> was "unsafe-references-in-binaries", which has since been dropped from
> oe-core:
>
>
> https://git.openembedded.org/openembedded-core/commit/?id=a6af5bbf3dad6f0951c67a0aae13ef86a8906893
>
> So... it looks like these examples of moving libs to base_libdir are
> obsolete and can be dropped.
>
> Some comments in insane.bbclass left behind when the
> unsafe-references-in-binaries and unsafe-references-in-scripts QA
> tests were removed can be dropped too.
>
> > given that almost all other recipes seem happy to just stuff all that
> > under /usr/lib, what is the rationale for the above occasional
> > difference? it pretty clearly doesn't affect functionality; it just
> > looks strange.
thanks, i appreciate the research ... i was moderately curious about
what was happening, but i just didn't have the energy to go digging.
so it seems that it would be harmless to -- in the case of
tcp-wrappers -- just drop the following from its do_install() routine:
do_install () {
... snip ...
if [ "${libdir}" != "${base_libdir}" ] ; then
rel_lib_prefix=`
[OE-core] minor curiosity related to libdir vs base_libdir and shared libs
a minor oddity i stumbled over digging into the proper installation
of shared libraries ... building core-image-minimal for qemuarm64 and,
for the most part, recipes from oe-core that install shared libs put
all three artifacts (real name, so name and linker name) under
/usr/lib, as in:
./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so
./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so.3
./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so.3.0.0
however, the *occasional* recipe chooses to -- for whatever reason --
distinguish between libdir and base_libdir. for example, here's the
result of installing tcp-wrappers' shared libs in its ${D} directory:
./tcp-wrappers/7.6-r10/image/lib/libwrap.so.0.7.6
./tcp-wrappers/7.6-r10/image/lib/libwrap.so.0
./tcp-wrappers/7.6-r10/image/usr/lib/libwrap.so
this is due to the following manual override in tcp-wrappers_7.6.bb:
do_install () {
oe_libinstall -a libwrap ${D}${libdir}
oe_libinstall -C shared -so libwrap ${D}${base_libdir}
if [ "${libdir}" != "${base_libdir}" ] ; then
rel_lib_prefix=`echo ${libdir} | sed 's,\(^/\|\)[^/][^/]*,..,g'`
libname=`readlink ${D}${base_libdir}/libwrap.so | xargs
basename`
ln -s ${rel_lib_prefix}${base_libdir}/${libname}
${D}${libdir}/libwrap.so
rm -f ${D}${base_libdir}/libwrap.so
fi
...
so this recipe -- after doing the *default* shared lib installation
via oe_libinstall() -- conditionally chooses to override that.
another recipe that is even odder is libcap-ng:
./libcap-ng/0.8.2-r0/image/lib/libcap-ng.so.0.0.0
./libcap-ng/0.8.2-r0/image/lib/libcap-ng.so.0
./libcap-ng/0.8.2-r0/image/usr/lib/libcap-ng.so
./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so.0
./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so
./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so.0.0.0
which seems odd since it does that override for *one* of the shared
libs that it generates, but not the other:
do_install:append() {
# Moving libcap-ng to base_libdir
if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
mkdir -p ${D}/${base_libdir}/
mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/
relpath=${@os.path.relpath("${base_libdir}", "${libdir}")}
ln -sf ${relpath}/libcap-ng.so.0.0.0 ${D}${libdir}/libcap-ng.so
fi
}
given that almost all other recipes seem happy to just stuff all that
under /usr/lib, what is the rationale for the above occasional
difference? it pretty clearly doesn't affect functionality; it just
looks strange.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155698):
https://lists.openembedded.org/g/openembedded-core/message/155698
Mute This Topic: https://lists.openembedded.org/mt/85398874/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] is oe_soinstall() from utils.bbclass actually used?
just going over the mechanics of how shared libs are installed properly, and noticed that while utils.bbclass defines the helper routine oe_soinstall(), no one in my current collection of layers seems to use it; rather, the popular choice is oe_libinstall(), which seems to subsume the earlier routine given its "-so" option. is oe_soinstall() still used? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155696): https://lists.openembedded.org/g/openembedded-core/message/155696 Mute This Topic: https://lists.openembedded.org/mt/85393760/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] wanting to clarify some shared lib install and packaging issues
some really basic observations and questions about shared libs from BB recipes as i'm trying to resolve some issues related to a weird hybrid build system that overrides the standard do_install() task by manually populating the "image" directory for each recipe, then hands control over to bitbake to take it from there. first, quick review as i am going to have to explain all this to some folks, so let's make sure i don't sound like an idiot. from the explanation here: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html when a BB recipe creates a shared lib, i typically expect to see the following under image/usr/lib/ (example from "nettle" directory building for aarch64): libhogweed.so -> libhogweed.so.6.4 [linker name] libhogweed.so.6 -> libhogweed.so.6.4[soname] libhogweed.so.6.4 [real name, actual lib] based on default packaging defined in bitbake.conf, i then expect to see the "base" package "nettle" install the following on the target: libhogweed.so.6 -> libhogweed.so.6.4 libhogweed.so.6.4 while the development package nettle-dev will contain support the linker name linking to, well, one of the above: libhogweed.so -> libhogweed.so.6.4 so far, nothing interesting, but this packaging means that, on the target, if something needs to link against the libhogweed library, it would normally link using the soname, "libhogweed.so.6", so a file by that name *must* exist on the target and, normally, it does (even if it's a symlink). here's what i just ran into -- this hybrid system that bypasses the normal BB install step and manually populates the image directory makes a bit of a mess with setting the symlinks and names properly, but this was "fixed" by totally redefining the standard recipe packaging, so that *all* shared lib files (all three forms) were stuffed into the base package. and as long as that weird repackaging was in place, everything "worked". along comes me, who really hates this re-definition of what goes into each package as it packages far more for the target than is necessary, and i revert the packaging back to the standard ... and things break, and here's why. the end result of the weird hybrid installation and my reverting the packaging is that what ended up on the target in terms of the shared libs was simply: libfubar.so that is, the actual shared lib (not a symlink), but with the linker name, not the soname, which would appear to be the cause of all sorts of things suddenly not running anymore, as a quick inspection showed systemd services trying to start and complaining: ... error while loading shared libraries: libfubar.so.1 ... so i just want to confirm that all of that is due to the shared lib having been packaged and installed on the target via its linker name, not its proper soname, correct? it *seems* like that's all i have to fix, but am i overlooking anything? as long as the shared lib is findable via its soname, should that be the general solution? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155648): https://lists.openembedded.org/g/openembedded-core/message/155648 Mute This Topic: https://lists.openembedded.org/mt/85348808/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] "SRC_URI = file:///..." versus "externalsrc"?
colleague asked me yesterday about the fundamental difference between using SRC_URI to point at a local source tree to build, versus inheriting externalsrc, and when to use each. from what i read, there's no serious difference as, by default, both techniques copy the source tree under WORKDIR -- the major difference is that externalsrc can be configured to build in the source directory via EXTERNALSRC_BUILD, which is something i would discourage anyway. apart from that, is there an argument for one over the other depending on the circumstances? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155549): https://lists.openembedded.org/g/openembedded-core/message/155549 Mute This Topic: https://lists.openembedded.org/mt/85297601/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] why "PREFERRED_PROVIDER_udev" and not "PREFERRED_PROVIDER_virtual/udev"?
On Mon, 30 Aug 2021, Khem Raj wrote: > On Mon, Aug 30, 2021 at 12:52 AM Robert P. J. Day > wrote: > > > > > > i was going to extend section 3.3.17, "Using Virtual Providers", > > with an intro example using "udev" until i realized that that example > > doesn't use the "virtual/" notation. so ... why not? is there some > > distinction between other components that use the "virtual/" prefix, > > but a reason that one does not specify: > > > > PROVIDES = "virtual/udev" > > > > rather than just: > > > > PROVIDES = "udev" > > > > and then use the corresponding PREFERRED_PROVIDER_virtual/udev > > notation? > > we also have VIRTUAL-RUNTIME_dev_manager which spans across systemd to mdev > so I guess we could but perhaps we already have this functionality a followup, perhaps silly question -- is there anything special about the "virtual/" prefix in the sense of being a provider? i mean, other than being more aesthetically obvious? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155516): https://lists.openembedded.org/g/openembedded-core/message/155516 Mute This Topic: https://lists.openembedded.org/mt/85245879/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] why "PREFERRED_PROVIDER_udev" and not "PREFERRED_PROVIDER_virtual/udev"?
On Mon, 30 Aug 2021, Robert P. J. Day wrote: > i was going to extend section 3.3.17, "Using Virtual Providers", > with an intro example using "udev" until i realized that that > example doesn't use the "virtual/" notation. so ... why not? is > there some distinction between other components that use the > "virtual/" prefix, but a reason that one does not specify: > > PROVIDES = "virtual/udev" > > rather than just: > > PROVIDES = "udev" > > and then use the corresponding PREFERRED_PROVIDER_virtual/udev > notation? just to make sure folks understand what i'm getting at, the section: https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-virtual-providers opens with, "Prior to a build, if you know that several different recipes provide the same functionality, you can use a virtual provider (i.e. virtual/*) as a placeholder for the actual provider." except there are cases where several different recipes provide the same functionality that *don't* incorporate the "virtual/" notation, so which ones merit that and which ones don't? (i mentioned "udev" being provided by both "eudev" and "systemd", for which i wrote an utterly brilliant explanation that i now realize isn't appropriate for that section.) in the simpler cases, you have recipes that have a new name that can now be used in place of the old, such that "stress-ng" provides "stress", so you don't have to mess with all your old images and packagegroups. and in situations like that, the "virtual/" notation would seem out of place. OTOH, well, virtual "kernel" and "bootloader" makes perfect sense as they represent a more abstract idea. so ... thoughts? even though "udev" does not use the "virtual/" notation, would it still fall under the category of "virtual provider"? if not, how would one describe it? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155479): https://lists.openembedded.org/g/openembedded-core/message/155479 Mute This Topic: https://lists.openembedded.org/mt/85245879/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] why "PREFERRED_PROVIDER_udev" and not "PREFERRED_PROVIDER_virtual/udev"?
i was going to extend section 3.3.17, "Using Virtual Providers", with an intro example using "udev" until i realized that that example doesn't use the "virtual/" notation. so ... why not? is there some distinction between other components that use the "virtual/" prefix, but a reason that one does not specify: PROVIDES = "virtual/udev" rather than just: PROVIDES = "udev" and then use the corresponding PREFERRED_PROVIDER_virtual/udev notation? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155477): https://lists.openembedded.org/g/openembedded-core/message/155477 Mute This Topic: https://lists.openembedded.org/mt/85245879/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] systemd: '${systemd_unitdir}/system' => '${systemd_system_unitdir}'
Repo-wide replacement to use newer variable to represent systemd
system unitdir directory.
Signed-off-by: Robert P. J. Day
---
lightly tested by building a core-image-minimal for aarch64 and
seeing no complaints.
diff --git a/meta/classes/rootfs-postcommands.bbclass
b/meta/classes/rootfs-postcommands.bbclass
index c5746eba13..7fe9e3d8c8 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -218,8 +218,8 @@ postinst_enable_logging () {
# Modify systemd default target
#
set_systemd_default_target () {
- if [ -d ${IMAGE_ROOTFS}${sysconfdir}/systemd/system -a -e
${IMAGE_ROOTFS}${systemd_unitdir}/system/${SYSTEMD_DEFAULT_TARGET} ]; then
- ln -sf ${systemd_unitdir}/system/${SYSTEMD_DEFAULT_TARGET}
${IMAGE_ROOTFS}${sysconfdir}/systemd/system/default.target
+ if [ -d ${IMAGE_ROOTFS}${sysconfdir}/systemd/system -a -e
${IMAGE_ROOTFS}${systemd_system_unitdir}/${SYSTEMD_DEFAULT_TARGET} ]; then
+ ln -sf ${systemd_system_unitdir}/${SYSTEMD_DEFAULT_TARGET}
${IMAGE_ROOTFS}${sysconfdir}/systemd/system/default.target
fi
}
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 4ea5adb9f4..b0dd625539 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -253,7 +253,7 @@ class Rootfs(object, metaclass=ABCMeta):
# Remove the run-postinsts package if no delayed postinsts are found
delayed_postinsts = self._get_delayed_postinsts()
if delayed_postinsts is None:
-if
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${sysconfdir}/init.d/run-postinsts"))
or
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${systemd_unitdir}/system/run-postinsts.service")):
+if
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${sysconfdir}/init.d/run-postinsts"))
or
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${systemd_system_unitdir}/run-postinsts.service")):
self.pm.remove(["run-postinsts"])
image_rorfs = bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs",
diff --git a/meta/recipes-bsp/acpid/acpid.inc b/meta/recipes-bsp/acpid/acpid.inc
index f48e519088..d39828e1cd 100644
--- a/meta/recipes-bsp/acpid/acpid.inc
+++ b/meta/recipes-bsp/acpid/acpid.inc
@@ -32,7 +32,7 @@ do_install:append () {
install -d ${D}${sysconfdir}/acpi
install -d ${D}${sysconfdir}/acpi/events
- install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/acpid.service ${D}${systemd_unitdir}/system
- sed -i -e 's,@SBINDIR@,${sbindir},g'
${D}${systemd_unitdir}/system/acpid.service
+ install -d ${D}${systemd_system_unitdir}
+ install -m 0644 ${WORKDIR}/acpid.service ${D}${systemd_system_unitdir}
+ sed -i -e 's,@SBINDIR@,${sbindir},g'
${D}${systemd_system_unitdir}/acpid.service
}
diff --git a/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
b/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
index 5368abfda6..da17e5a235 100644
--- a/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
+++ b/meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
@@ -73,10 +73,10 @@ do_install() {
sed -e 's,/usr/sbin,${sbindir},g; s,/etc,${sysconfdir},g;'
${WORKDIR}/init > ${D}${sysconfdir}/init.d/apmd
chmod 755 ${D}${sysconfdir}/init.d/apmd
- install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/apmd.service ${D}${systemd_unitdir}/system/
+ install -d ${D}${systemd_system_unitdir}
+ install -m 0644 ${WORKDIR}/apmd.service ${D}${systemd_system_unitdir}/
sed -i -e 's,@SYSCONFDIR@,${sysconfdir},g' \
- -e 's,@SBINDIR@,${sbindir},g'
${D}${systemd_unitdir}/system/apmd.service
+ -e 's,@SBINDIR@,${sbindir},g'
${D}${systemd_system_unitdir}/apmd.service
}
PACKAGES =+ "libapm apm"
diff --git a/meta/recipes-connectivity/avahi/avahi_0.8.bb
b/meta/recipes-connectivity/avahi/avahi_0.8.bb
index 934044d5da..cd0489e846 100644
--- a/meta/recipes-connectivity/avahi/avahi_0.8.bb
+++ b/meta/recipes-connectivity/avahi/avahi_0.8.bb
@@ -67,7 +67,7 @@ EXTRA_OECONF = "--with-avahi-priv-access-group=adm \
# The distro choice determines what init scripts are installed
EXTRA_OECONF_SYSVINIT =
"${@bb.utils.contains('DISTRO_FEATURES','sysvinit','--with-distro=debian','--with-distro=none',d)}"
-EXTRA_OECONF_SYSTEMD =
"${@bb.utils.contains('DISTRO_FEATURES','systemd','--with-systemdsystemunitdir=${systemd_unitdir}/system/','--without-systemdsystemunitdir',d)}"
+EXTRA_OECONF_SYSTEMD =
"${@bb.utils.contains('DISTRO_FEATURES','systemd','--with-systemdsystemunitdir=${systemd_system_unitdir}/','--without-systemdsystemunitdir',d)}"
do_configure:prepend() {
# This m4 file will get in the way of our introspection.m4 with special
cross-compilation fixes
diff --git a/meta/recipes-connectivity/bind/bind_9.16.20.bb
b/meta/recipes-connectivity/bind/bind_9.16.20.bb
index f7d0416858..ddf32
Re: [OE-core] what means the test 'if [ -z "$D" ]' in a pkg_postinst routine?
On Thu, 26 Aug 2021, Alexander Kanavin wrote:
> It used to be that 'exit 1' was the way to defer to boot time, but
> that was changed long time ago to not be ambiguous like that and
> cause a real failure at build time. Deferring to first boot needs to
> be explicitly requested with _ontarget() (you can read the
> definition for it to see what really happens, how $D is used and how
> request to defer is made).
>
> Alex
>
> On Wed, 25 Aug 2021 at 23:51, Robert P. J. Day wrote:
>
> Quoting Phil Blundell :
>
> > That's testing for offline installation. If $D is not set, it's
> > running on the target.
> >
> > p.
>
> one last query before i head off for dinner ... so what about
> pkg_postinst() routines that do double duty, like this one from
> dbus_1.12.20.bb:
>
>
> PACKAGE_WRITE_DEPS += "${@bb.utils.contains('DISTRO_FEATURES','systemd
> sysvinit','systemd-systemctl-native','',d)}"
> pkg_postinst:dbus() {
> # If both systemd and sysvinit are enabled, mask the dbus-1
> init script
> if ${@bb.utils.contains('DISTRO_FEATURES','systemd
> sysvinit','true','false',d)}; then
> if [ -n "$D" ]; then
> OPTS="--root=$D"
> fi
> systemctl $OPTS mask dbus-1.service
> fi
>
> if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ;
> then
> /etc/init.d/populate-volatile.sh update
> fi
> }
so, just to confirm the previous tidbits of information (thank you
for your patience), here's my current understanding so i can submit
updated docs:
* pkg_postinst:${PN} is run at image creation time and *only* at image
creation time; it is no longer deferred to boot time under any
circumstances(?)
* pkg_postinst_ontarget:${PN} is run at boot time and *only* at boot
time
* because of the above, there is no value to the numerous legacy
checks of:
if [ -z "$D" ]
if [ -n "$D" ]
or any of its variations (even though, in a lot of cases, they don't
hurt)
* from within pkg_postinst:${PN}, you can still defer some work to
boot time with "postinst_intercept delay_to_first_boot", although
isn't this precisely what pkg_postinst_ontarget:${PN} is for, so is
this postinst_intercept construct still useful?
* PACKAGE_WRITE_DEPS is still necessary to identify non-standard
native tools you might need for any pkg_postinst:${PN} processing
does all that look about right?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155339):
https://lists.openembedded.org/g/openembedded-core/message/155339
Mute This Topic: https://lists.openembedded.org/mt/85146007/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] what means the test 'if [ -z "$D" ]' in a pkg_postinst routine?
On Thu, 26 Aug 2021, Alexander Kanavin wrote: > It used to be that 'exit 1' was the way to defer to boot time, but > that was changed long time ago to not be ambiguous like that and > cause a real failure at build time. Deferring to first boot needs to > be explicitly requested with _ontarget() (you can read the > definition for it to see what really happens, how $D is used and how > request to defer is made). > > Alex and that's sort of what i thought, despite what the docs currently say: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-post-installation-scripts "If you do not use this variable, the tools might be missing and execution of the post-installation script is deferred until first boot." i'll put together some enhanced docs that clear this up, and submit to docs list. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155338): https://lists.openembedded.org/g/openembedded-core/message/155338 Mute This Topic: https://lists.openembedded.org/mt/85146007/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] what means the test 'if [ -z "$D" ]' in a pkg_postinst routine?
Quoting Phil Blundell :
That's testing for offline installation. If $D is not set, it's
running on the target.
p.
one last query before i head off for dinner ... so what about
pkg_postinst() routines that do double duty, like this one from
dbus_1.12.20.bb:
PACKAGE_WRITE_DEPS += "${@bb.utils.contains('DISTRO_FEATURES','systemd
sysvinit','systemd-systemctl-native','',d)}"
pkg_postinst:dbus() {
# If both systemd and sysvinit are enabled, mask the dbus-1
init script
if ${@bb.utils.contains('DISTRO_FEATURES','systemd
sysvinit','true','false',d)}; then
if [ -n "$D" ]; then
OPTS="--root=$D"
fi
systemctl $OPTS mask dbus-1.service
fi
if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
/etc/init.d/populate-volatile.sh update
fi
}
note how that routine checks its context and, as i recall (but
it's not documented in the docs i'm looking at), i'd swear that
i read somewhere that if a pkg_postinst() routine fails at image
creation time, it was deferred until boot time, which would
explain the above routine checking its runtime context.
anyway, off for food.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155329):
https://lists.openembedded.org/g/openembedded-core/message/155329
Mute This Topic: https://lists.openembedded.org/mt/85146007/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] what means the test 'if [ -z "$D" ]' in a pkg_postinst routine?
Quoting Phil Blundell : That's testing for offline installation. If $D is not set, it's running on the target. p. right, that's exactly what i suspected in my original posting, i just wanted to make sure, which raises a couple issues. first, that distinction doesn't seem to be mentioned in the docs, so i'll ponder writing something. second, is that simply an old form that would be superseded by using "pkg_postinst_ontarget()" instead? anyway, more questions later as i work on some lengthier docs on this. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155327): https://lists.openembedded.org/g/openembedded-core/message/155327 Mute This Topic: https://lists.openembedded.org/mt/85146007/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] what means the test 'if [ -z "$D" ]' in a pkg_postinst routine?
Quoting Alexander Kanavin :
If you show the confusing examples, we could try to figure it out.
Alex
On Wed, 25 Aug 2021 at 22:35, Robert P. J. Day
wrote:
there will be many more questions about pkg_postinst (and related)
routines shortly, but digging into these for the first time, i
thought that that test checked whether the routine was being run
at image creation time, or at first-time boot. now i'm not quite
sure what to think after seeing several examples.
what does the test for null or non-null variable "D" mean in
a pkg_postinst routine? and once i figure all this out, i may
very well contribute some enhanced docs for the next confused
person.
there's no shortage of examples ... here's just one from
recipes-bsp/alsa-state/alsa-state.bb:
pkg_postinst:${PN}() {
if test -z "$D" <
then
if test -x ${sbindir}/alsactl
then
${sbindir}/alsactl -g -f
${localstatedir}/lib/alsa/asound.state restore
fi
fi
}
there's plenty more ... recipes-bsp/keymaps/keymaps_1.0.bb:
pkg_postinst:${PN} () {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd
sysvinit','true','false',d)}; then
if [ -n "$D" ]; then<
OPTS="--root=$D"
fi
systemctl $OPTS mask keymap.service
fi
}
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155325):
https://lists.openembedded.org/g/openembedded-core/message/155325
Mute This Topic: https://lists.openembedded.org/mt/85146007/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] what means the test 'if [ -z "$D" ]' in a pkg_postinst routine?
there will be many more questions about pkg_postinst (and related) routines shortly, but digging into these for the first time, i thought that that test checked whether the routine was being run at image creation time, or at first-time boot. now i'm not quite sure what to think after seeing several examples. what does the test for null or non-null variable "D" mean in a pkg_postinst routine? and once i figure all this out, i may very well contribute some enhanced docs for the next confused person. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155323): https://lists.openembedded.org/g/openembedded-core/message/155323 Mute This Topic: https://lists.openembedded.org/mt/85146007/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] should "${D}${systemd_unitdir}/system" => "${D}${systemd_system_unitdir}"?
On Wed, 18 Aug 2021, Ross Burton wrote:
> No, yes. systemd_system_unitdir is newer so it's used less.
>
> Ross
>
> On Wed, 18 Aug 2021 at 08:48, Robert P. J. Day wrote:
> >
> >
> > i've (so far) run across a small number of OE recipes that use the
> > identifier "${D}${systemd_unitdir}/system", which appears(?) to be
> > equivalent to "${D}${systemd_system_unitdir}". is there any potential
> > functional difference, or should this be standardized?
please help me with basic REs ... i want to run a single perl
command of the form
$ perl -pi -e 's|...|...|' $(all the relevant files)
to change "${D}${systemd_unitdir}/system" -> "${D}${systemd_system_unitdir}"
and then eyeball it afterwards to make sure it's sane, but i can't get
the proper combination of quotes versus backslashes. i can generate
the list of appropriate files with:
$ grep -rl '${systemd_unitdir}/system' *
but it's the perl expression that is defeating me. help.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155293):
https://lists.openembedded.org/g/openembedded-core/message/155293
Mute This Topic: https://lists.openembedded.org/mt/84967618/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] should "${D}${systemd_unitdir}/system" => "${D}${systemd_system_unitdir}"?
On Wed, 18 Aug 2021, Ross Burton wrote: > No, yes. systemd_system_unitdir is newer so it's used less. i'll put together a patch and see if it's just more churn than it's worth. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154916): https://lists.openembedded.org/g/openembedded-core/message/154916 Mute This Topic: https://lists.openembedded.org/mt/84967618/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] should "${D}${systemd_unitdir}/system" => "${D}${systemd_system_unitdir}"?
i've (so far) run across a small number of OE recipes that use the
identifier "${D}${systemd_unitdir}/system", which appears(?) to be
equivalent to "${D}${systemd_system_unitdir}". is there any potential
functional difference, or should this be standardized?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154908):
https://lists.openembedded.org/g/openembedded-core/message/154908
Mute This Topic: https://lists.openembedded.org/mt/84967618/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] scripts/lib/wic/help/py: "Redhat" -> "Red Hat"
Company name is properly spelled as "Red Hat". Signed-off-by: Robert P. J. Day --- diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py index 991e5094bb..41451d1cb0 100644 --- a/scripts/lib/wic/help.py +++ b/scripts/lib/wic/help.py @@ -637,7 +637,7 @@ DESCRIPTION oe-core: directdisk.bbclass and mkefidisk.sh. The difference between wic and those examples is that with wic the functionality of those scripts is implemented by a general-purpose partitioning -'language' based on Redhat kickstart syntax). +'language' based on Red Hat kickstart syntax). The initial motivation and design considerations that lead to the current tool are described exhaustively in Yocto Bug #3847 -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca LinkedIn: http://ca.linkedin.com/in/rpjday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154821): https://lists.openembedded.org/g/openembedded-core/message/154821 Mute This Topic: https://lists.openembedded.org/mt/84906603/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] image_types_wic.bbclass: alphabetize list of WICVARS
It's way easier to scan a list of variables if they're sorted one per
line.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index 2f1a0b709c..d561fb2636 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -1,11 +1,35 @@
# The WICVARS variable is used to define list of bitbake variables used in wic
code
# variables from this list is written to .env file
WICVARS ?= "\
- BBLAYERS IMGDEPLOYDIR DEPLOY_DIR_IMAGE FAKEROOTCMD IMAGE_BASENAME
IMAGE_EFI_BOOT_FILES IMAGE_BOOT_FILES \
- IMAGE_LINK_NAME IMAGE_ROOTFS INITRAMFS_FSTYPES INITRD INITRD_LIVE
ISODIR RECIPE_SYSROOT_NATIVE \
- ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS
HOSTTOOLS_DIR \
- KERNEL_IMAGETYPE MACHINE INITRAMFS_IMAGE INITRAMFS_IMAGE_BUNDLE
INITRAMFS_LINK_NAME APPEND \
- ASSUME_PROVIDED PSEUDO_IGNORE_PATHS"
+ APPEND \
+ ASSUME_PROVIDED \
+ BBLAYERS \
+ DEPLOY_DIR_IMAGE \
+ FAKEROOTCMD \
+ HOSTTOOLS_DIR \
+ IMAGE_BASENAME \
+ IMAGE_BOOT_FILES \
+ IMAGE_EFI_BOOT_FILES \
+ IMAGE_LINK_NAME \
+ IMAGE_ROOTFS \
+ IMGDEPLOYDIR \
+ INITRAMFS_FSTYPES \
+ INITRAMFS_IMAGE \
+ INITRAMFS_IMAGE_BUNDLE \
+ INITRAMFS_LINK_NAME \
+ INITRD \
+ INITRD_LIVE \
+ ISODIR \
+ KERNEL_IMAGETYPE \
+ MACHINE \
+ PSEUDO_IGNORE_PATHS \
+ RECIPE_SYSROOT_NATIVE \
+ ROOTFS_SIZE \
+ STAGING_DATADIR \
+ STAGING_DIR \
+ STAGING_LIBDIR \
+ TARGET_SYS \
+"
inherit ${@bb.utils.contains('INITRAMFS_IMAGE_BUNDLE', '1',
'kernel-artifact-names', '', d)}
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
LinkedIn: http://ca.linkedin.com/in/rpjday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154794):
https://lists.openembedded.org/g/openembedded-core/message/154794
Mute This Topic: https://lists.openembedded.org/mt/84898601/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] issues with wic creating "multi-partition" images?
On Thu, 12 Aug 2021, Alexandre Belloni wrote:
> Hello,
>
> On 12/08/2021 05:26:47-0400, Robert P. J. Day wrote:
> >
> > asking from a position of massive ignorance since i just started
> > digging into wic, but i've been reliably assured that i am going to
> > encounter issues with trying to get wic to create what i choose to
> > call "multi-partition" images, and i just want to know if this is an
> > actual issue.
> >
> > current wic setup is to create an image which supports what i'll
> > call the "preserve" partition -- distinct partition to hold
> > non-upgradeable content; factory default firmware, non-volatile S/W
> > config settings, that sort of thing, that is meant to be preserved
> > across software upgrades. nothing unusual about this, strikes me as
> > pretty standard.
> >
> > now, any recipe in the current build is allowed to contribute its
> > own preserve data by adding it to a top-level "/preserve" directory.
> > that directory is added to the content of the base package:
> >
> > FILES_${PN} += "/preserve"
> >
> > and in the end, the wic image is responsible for taking everything
> > under /preserve in the final rootfs and installing it in the preserve
> > partition, wholly separate from however it installs the remainder of
> > the rootfs.
> >
> > does wic have a problem with doing this? it seems so straightforward
> > that i'm having trouble believing wic can't do it. thoughts? or
> > perhaps a link to some reference board or vendor that has a .wks file
> > that does exactly that?
>
> In your wks.in, you can simply do something like that:
>
> part / --source rootfs --fstype=ext4 --label root --exclude-path=preserve/
> part /preserve --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/preserve
> --fstype=ext4 --label preserve
that's what i thought, so i'm going back to the current setup to try
to figure out what the originators thought the problem was.
rday
p.s. as i read it, the only distinction between a "wks" and a "wks.in"
file is the need to pre-process variable substitution in the latter,
correct?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154738):
https://lists.openembedded.org/g/openembedded-core/message/154738
Mute This Topic: https://lists.openembedded.org/mt/84836183/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] issues with wic creating "multi-partition" images?
asking from a position of massive ignorance since i just started
digging into wic, but i've been reliably assured that i am going to
encounter issues with trying to get wic to create what i choose to
call "multi-partition" images, and i just want to know if this is an
actual issue.
current wic setup is to create an image which supports what i'll
call the "preserve" partition -- distinct partition to hold
non-upgradeable content; factory default firmware, non-volatile S/W
config settings, that sort of thing, that is meant to be preserved
across software upgrades. nothing unusual about this, strikes me as
pretty standard.
now, any recipe in the current build is allowed to contribute its
own preserve data by adding it to a top-level "/preserve" directory.
that directory is added to the content of the base package:
FILES_${PN} += "/preserve"
and in the end, the wic image is responsible for taking everything
under /preserve in the final rootfs and installing it in the preserve
partition, wholly separate from however it installs the remainder of
the rootfs.
does wic have a problem with doing this? it seems so straightforward
that i'm having trouble believing wic can't do it. thoughts? or
perhaps a link to some reference board or vendor that has a .wks file
that does exactly that?
rday
p.s. there is no separate wic mailing list is there?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154736):
https://lists.openembedded.org/g/openembedded-core/message/154736
Mute This Topic: https://lists.openembedded.org/mt/84836183/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ntpsec on OE/YP?
colleague asks about the state of ntpsec (https://www.ntpsec.org/) on OE/YP, a quick search does not show official support of any kind, any pointers? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154662): https://lists.openembedded.org/g/openembedded-core/message/154662 Mute This Topic: https://lists.openembedded.org/mt/84779837/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] would reducing BB_NUMBER_THREADS solve parallelism overheating?
i've asked about this previously, but i finally got around to thinking about this in detail, and i'd like some feedback. i've described the overheating/lockup issues i've been having on a dell latitude laptop building a sizable (wind river linux-based) image represented by 5-6000 tasks. if i start the full build from scratch, it would take about 2 hours if it succeeded but, on a very regular basis, when the load average well exceeds 120 and i can feel really hot air blowing (even with t laptop cooler), the laptop will simply lock up hard. the CPU is a i7-9850H, so 6 cores/12 threads, and i've refactored numerous proprietary in-house recipes to really crank up the parallelism so that, a lot of the time, i can see all 12 threads churning away on some task. of course, that's exactly when i get the huge load average/overheating/lockup. a couple colleagues suggested using BB_NUMBER_THREADS (BNT for short) to dial things back a bit but, after i pondered a bit, it seems that that would potentially make things worse, not better, so a couple questions about cores and threads. first, given the CPU setup, let's say i set BNT to 6. does that mean 3 cores would be taken out of play entirely, leaving the other 3 to do all the work, or would each core simply use one thread, or who knows what would happen, and would any one scenario be superior to another? my other realization(?) is that reducing BNT might be the *worst* strategy, and here's why. if i have a huge load average, that suggests i have lots and lots of tasks waiting to run (lots of stuff on the wait queue). but if i reduce the number of available threads, wouldn't that just force all that work to wait for a smaller number of threads, making the wait queues even longer? i'm open to being educated on how all this works. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154584): https://lists.openembedded.org/g/openembedded-core/message/154584 Mute This Topic: https://lists.openembedded.org/mt/84730702/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] should recipes not come with their own systemd/user/group info?
style question here, but i'm perusing an OE/YP (actually wind river, but effectively the same thing) layer that was handed to me, and i'm puzzled by how the internally-written systemd-controlled services are implemented. on the one hand, there are reasonable recipes that each represent some service to be managed by systemd, and they all install their executables in the right places and so on. however, rather than each recipe also providing its own service file, there is a totally separate recipe (call it "systemd-services.bb") which contains under its files/ directory dozens and dozens of service files for all of those recipes, and is responsible for installing all of them. in short, someone decided that -- for whatever reason -- all of the systemd service files should be collected all in one place, and installed en masse. is this ... normal? i would have thought that it's the responsibility of each recipe to mannage all the content related to it, and that would of course include the systemd service file to be installed for it. i don't know the rationale for this, and it strikes me as a recipe for disaster in trying to keep all these things synced up. is there some rationale for doing it this way that i'm unaware of? and closely related, the same trick was used when defining all the new users and groups that would own these services. rather than each service looking after itself, there is a recipe file (call it "new_users_and_groups.bb") which is hundreds of lines of USERADD_PARAM and GROUPADD_PARAM lines that define precisely (numerically) all the new user and group accounts to be associated with all sorts of services, whereupon i ask the same question -- isn't it more typical that each service look after its own user and group info? in this second case, it *might* be that all of these values need to be hard-coded to be consistent with, i don't know, something else i'm unaware of, but it still looks strange. thoughts? the above actually works for the time being, but it does seem a but unnatural. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154477): https://lists.openembedded.org/g/openembedded-core/message/154477 Mute This Topic: https://lists.openembedded.org/mt/84682032/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] oe-setup-builddir: update YP docs and OE URLs
On Fri, 23 Jul 2021, Michael Opdenacker wrote: > This updates the link to the YP docs > and proposes to access the OE website through https > > Signed-off-by: Michael Opdenacker > --- > scripts/oe-setup-builddir | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir > index 30eaa8efbe..75f63f5680 100755 > --- a/scripts/oe-setup-builddir > +++ b/scripts/oe-setup-builddir > @@ -113,10 +113,10 @@ if [ ! -z "$SHOWYPDOC" ]; then > cat < The Yocto Project has extensive documentation about OE including a reference > manual which can be found at: > -http://yoctoproject.org/documentation > +https://docs.yoctoproject.org > > For more information about OpenEmbedded see their website: > -http://www.openembedded.org/ > +https//www.openembedded.org/ missing colon. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154113): https://lists.openembedded.org/g/openembedded-core/message/154113 Mute This Topic: https://lists.openembedded.org/mt/84401182/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] how to configure an image with *full* debugging info in the libs and binaries?
Quoting Andre McCurdy : On Mon, Jul 19, 2021 at 5:06 PM Ross Burton wrote: On Fri, 16 Jul 2021 at 20:10, Robert P. J. Day wrote: > colleague just asked me what it would take to generate an image > where the executables and libraries contain all the gdb-related > debugging info in the same files (that is, not broken out in the > .debug directories). > > i pointed out that this would increase the size of the installable > target image substantially but, apparently, that is of no concern. This is where I have to ask "why?". All known debugging tools can handle split-out debuginfo, and getting them all installed into an image is as simple as IMAGE_FEATURES += dbg-pkgs, as Khem says. Why is an interesting side discussion. Getting back to the original question though, either OE officially supports creating unstripped binaries or it doesn't. The documentation should perhaps be updated to make that clear (and if there's legacy support for creating unstripped binaries still lurking in the code but we don't want anyone to use it, then maybe it should be removed...). It *appears* the combination of: INHIBIT_PACKAGE_STRIP = '1' INHIBIT_PACKAGE_DEBUG_SPLIT = '1' does what I want (at least at first glance). As to "why", I have been told there is a build/test infrastructure in place that works with just this format, and they would like to just keep doing that. And, frankly, that's a perfectly good reason. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154010): https://lists.openembedded.org/g/openembedded-core/message/154010 Mute This Topic: https://lists.openembedded.org/mt/84256404/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] how to configure an image with *full* debugging info in the libs and binaries?
On Fri, 16 Jul 2021, Khem Raj wrote: > On Fri, Jul 16, 2021 at 12:10 PM Robert P. J. Day > wrote: > > > > > > colleague just asked me what it would take to generate an image > > where the executables and libraries contain all the gdb-related > > debugging info in the same files (that is, not broken out in the > > .debug directories). > > > > i pointed out that this would increase the size of the installable > > target image substantially but, apparently, that is of no concern. > > > > said colleague pointed me here as to what they were perusing: > > > > https://developer.ridgerun.com/wiki/index.php?title=Preparing_Yocto_Development_Environment_for_Debugging > > > > so, once i finish this current task, i'm going to take a shot at > > testing whether the following would do it: > > > > # Specifies to build packages with debugging information > > DEBUG_BUILD = "1" > > # Do not remove debug symbols > > INHIBIT_PACKAGE_STRIP = "1" > > # OPTIONAL: Do not split debug symbols in a separate file > > INHIBIT_PACKAGE_DEBUG_SPLIT= "1" > > > > am i on the right track? this seems straightforward enough, i'll just > > have to confirm those variables still exist, and that they do what i > > want. > > > > thoughts? is this as simple as i think it should be? > > I think you should try > > EXTRA_IMAGE_FEATURES_append = " tools-debug dbg-pkgs" pretty sure you don't need both "EXTRA_" and "_append". :-) > this should get you all needed debug info and tools on target > > then if you want to make optimization levels to favor debug info > generation set DEBUG_BUILD = "1" i'm ... not convinced (i'll be trying this later), but to be clear, i don't want separate .debug content, i want a single image with all the debug info right in the binaries and executables. i'll try some things later and we'll see what happens. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153946): https://lists.openembedded.org/g/openembedded-core/message/153946 Mute This Topic: https://lists.openembedded.org/mt/84256404/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] how to configure an image with *full* debugging info in the libs and binaries?
colleague just asked me what it would take to generate an image where the executables and libraries contain all the gdb-related debugging info in the same files (that is, not broken out in the .debug directories). i pointed out that this would increase the size of the installable target image substantially but, apparently, that is of no concern. said colleague pointed me here as to what they were perusing: https://developer.ridgerun.com/wiki/index.php?title=Preparing_Yocto_Development_Environment_for_Debugging so, once i finish this current task, i'm going to take a shot at testing whether the following would do it: # Specifies to build packages with debugging information DEBUG_BUILD = "1" # Do not remove debug symbols INHIBIT_PACKAGE_STRIP = "1" # OPTIONAL: Do not split debug symbols in a separate file INHIBIT_PACKAGE_DEBUG_SPLIT= "1" am i on the right track? this seems straightforward enough, i'll just have to confirm those variables still exist, and that they do what i want. thoughts? is this as simple as i think it should be? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153944): https://lists.openembedded.org/g/openembedded-core/message/153944 Mute This Topic: https://lists.openembedded.org/mt/84256404/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] should a layer supply its own "local.conf" file?
long story short -- was having trouble figuring out why basic settings i was adding to my build directory's conf/local.conf were being ignored, and traced it back to the internal layer i was using having its own "local.conf" file (in its conf directory, sitting quietly next to the layer's "layer.conf" file). argh. i'm assuming that it was *that* local.conf that was being consulted by the config process (overriding mine). is there some rationale for that? that doesn't strike me as proper design, but i'm willing to be educated. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153235): https://lists.openembedded.org/g/openembedded-core/message/153235 Mute This Topic: https://lists.openembedded.org/mt/83734978/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] should the same recipe have two different WORKDIRs?
perhaps i've just never noticed before, but a colleague asked me to debug some strangeness with his WRLinux build, and what i noticed was that the recipe that generated a package with a single (aarch64) executable created WORKDIRs under both directories: * cortexa53... * acme-coyote [actual target board] this surprises me ... i thought that, based on the attributes of any recipe, it would have only one WORKDIR in the appropriate place. what does the above mean? i'm not sure what to make of it. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153027): https://lists.openembedded.org/g/openembedded-core/message/153027 Mute This Topic: https://lists.openembedded.org/mt/83584601/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] canonical way to "migrate" Makefile stuff to bitbake recipe file?
following on a couple earlier posts, at my current gig, a co-op
student has been given the job of, bit by bit, "migrating" the targets
in a number of sizable Makefiles to BB recipe files, in order to
incorporate all that legacy build process in a current YP
infrastructure.
he's working on the really low-level targets to begin with, and the
process is kind of hacky -- the source for any component (and its
corresponding Makefile) is simply left where it is (for now), and the
corresponding recipe file (in the simplest possible case) looks like
this for some given "subsystem":
subsystem.bb
inherit migrate
SRC_URI += "file://subsystem/"
MG_BUILD_DIR = "subsystem/"
the internal migrate.bbclass handles setting FILESEXTRAPATHS so that
all the subsystems can be located as above, and the do_compile() task
is redefined to be (simplifying a bit):
do_compile() {
cd ${MG_BUILD_DIR}
oe_runmake
}
in other words, the *building* of any subsystem hasn't really changed
all that much, it's still done pretty much in place as it was before,
at which point there is a do_install() routine whose job it is to take
the generated artifacts and manually "install" them into "${D}" in the
proper locations; in short, the "migration" process emulates the first
part of building a recipe all the way up to emulating the installation
step and getting everything into the ${WORKDIR}/image/ directory,
whereupon the normal packaging and subsequent OE steps kick in. so
far, this is working adequately for the really simple makefile
targets.
next, as long as this process works, then further recipes can
incorporate build-time dependencies of earlier migrated recipes, so
for subsystem "sub1", we might add:
DEPENDS += "sub2 sub3"
and that should still work, but said co-op student asked about how to
deal with makefiles with multi-line rules for a subsystem target, call
it "sub", and various sub-components in subdirectories c1, c2 and c3:
sub: [some dependencies]
$(MAKE) -C c1
$(MAKE) -C c2
$(MAKE) -C c3
my initial reaction was, if those sub-makes can be done independently,
then the simplest solution is to define separate recipes files for
each one (with SRC_URI set appropriately):
sub-c1.bb
=
inherit migrate
SRC_URI += "file://sub/c1/"
MG_BUILD_DIR = "sub/c1/"
where each of the component recipe files can define its own build-time
dependencies independently of the other components. and one can then
define a collective recipe to gather all of them as build-time
dependencies representing the entire subsystem:
sub.bb
==
DEPENDS += "sub-c1 sub-c2 sub-c3"
so, for any new recipes, one can independently depend on any subset of
those components, or just depend on them all together if that's
easier.
is this a reasonable way to go about it? that is, given a
multi-line Makefile rule that refers to building in several immediate
"component" subdirectories, write a separate recipe file for each
component? am i missing anything obvious that would simplify this?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152688):
https://lists.openembedded.org/g/openembedded-core/message/152688
Mute This Topic: https://lists.openembedded.org/mt/83348129/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] want to clarify proper approach to shared lib (.so) installation
On Fri, 4 Jun 2021, Andre McCurdy wrote: ... big ship ... > Just a warning, but if your Makefiles are not generating versioned > shared libraries then they are probably not setting a soname > either... and that really messes up OE's automatic runtime > dependency tracking for shared libraries. > > If OE is your main build environment for these components it's > usually better in the long run to just update your Makefiles to > create versioned shared libraries (using simple version .0 and a > single symlink is fine) and setting a soname than to use the above > trick to force packaging of an unversioned .so and manually defining > runtime dependencies everywhere. oh, i realize that ... the current build system is very legacy-driven and i have a lengthy list of cleanups to do, this just one of them. for now, things just have to work until i can bend things into shape. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#152660): https://lists.openembedded.org/g/openembedded-core/message/152660 Mute This Topic: https://lists.openembedded.org/mt/83283893/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] want to clarify proper approach to shared lib (.so) installation
On Thu, 3 Jun 2021, Andrea Adami wrote:
> On Thu, Jun 3, 2021 at 4:01 PM Robert P. J. Day wrote:
> >
> >
> > sort of a 2-part soliloquy. in current YP code base i've inherited,
> > most of the internal (local directory SRC_URI-based) recipes inherit a
> > proprietary class that, among doing other internal, proprietary
> > things, totally redefines PACKAGES as:
> >
> > PACKAGES = "${PN} ... ${PN}-dev ..."
> >
> > i had never really noticed that before, but it's pretty obvious that
> > that's not a great idea, as it allows what i call the recipe "base"
> > package (${PN}) to gather up everything that matches its standard
> > wildcard pattern before moving on, in effect "stealing" content from
> > subsequent packages they would normally get if the base package was at
> > the end, not the beginning.
> >
> > somehow, this has worked all this time, but it's clear(?) that what
> > would be the "normal" contents of the various packages isn't going to
> > be what one would expect; in particular, the base package is going to
> > be what i call "overpackaged", with lots of stuff it doesn't really
> > need so i'm guessing what's going into the image is more than is
> > really necessary. somehow, though, it's worked all this time until
> > recently, when i noticed this quirk was causing some Q/A issues, so i
> > took a deep breath, commented out that line from the class file to use
> > the default packaging approach and re-tried the build, which is when
> > all hell broke loose.
> >
> > it turns out that these internal recipes use local Makefile-based
> > source directories, which build, then install their generated
> > artifacts in a temporary (non-YP) staging area per recipe, *then*
> > manually (little by little) install stuff in ${D} via a general
> > do_install() routine, at which point the regular packaging and
> > subsequent steps kick in, but it's what now gets copied into ${D} that
> > is causing grief.
> >
> > apparently, many of these recipes generate a shared library, and i'm
> > well aware that the *normal* packaging involving a shared library is
> > like this example from libidn2 (snipped for brevity to show only
> > shared lib stuff):
> >
> > libidn2/
> > usr/
> >lib/
> > libidn2.so.0 -> libidn2.so.0.3.7
> > libidn2.so.0.3.7[actual library file]
> >
> > libidn2-dev/
> > usr/
> >lib/
> > libidn2.so -> libidn2.so.0.3.7
> >
> > so the *normal* packaging for a shared lib is that the lib itself and
> > a symlink to it go into the base package, while another symlink goes
> > into the "-dev" package. i'd never really paid that much attention to
> > that until i reset that PACKAGES variable, as all of these internal
> > recipes end up installing into ${D} nothing but the shared lib file
> > itself under /usr/lib, and why this has worked all this time is a
> > mystery, but having made this change is generating all sorts of Q/A
> > diagnostics as this is what ends up in ${D} using a "fubar" recipe
> > example given the manual installation being done using normal
> > packaging:
> >
> > fubar/
> > usr/
> >bin/
> > ... snip ...
> >no lib/ directory
> >
> > fubar-dev/
> > usr/
> >lib/
> > libfnvcma.so[actual shared lib]
> >
> > unsurprisingly, there are QA issues with the above:
> >
> > ERROR: fubar-1.0-r0 do_package_qa: QA Issue: -dev package contains
> > non-symlink .so: fubar-dev
> > path .../packages-split/fubar-dev/usr/lib/libfnvcma.so'[dev-elf]
> > ERROR: fubar-1.0-r0 do_package_qa: QA Issue: fubar rdepends on fubar-dev
> > [dev-deps]
> >
> > *sigh*.
> >
> > in short, because these internal recipes generate only the single
> > shared lib file itself and that's all that's copied into ${D}, the
> > regular Q/A tests will naturally barf, and i could use INSANE_SKIP all
> > over the place to get around this, but it seems to me that the proper
> > approach is to tell the developers that they need to start generating
> > the appropriate symlinks for all of their recipes so packaging is done
> > properly.
> >
> > i'm just about to check if there is a switch or class i can invoke
> > that will "fix" this issue (as in, set up the shared libs in ${D}
> > properly), but apart from that, am i correct in thinking that the
> > developers need to do this correctly from the b
[OE-core] want to clarify proper approach to shared lib (.so) installation
sort of a 2-part soliloquy. in current YP code base i've inherited,
most of the internal (local directory SRC_URI-based) recipes inherit a
proprietary class that, among doing other internal, proprietary
things, totally redefines PACKAGES as:
PACKAGES = "${PN} ... ${PN}-dev ..."
i had never really noticed that before, but it's pretty obvious that
that's not a great idea, as it allows what i call the recipe "base"
package (${PN}) to gather up everything that matches its standard
wildcard pattern before moving on, in effect "stealing" content from
subsequent packages they would normally get if the base package was at
the end, not the beginning.
somehow, this has worked all this time, but it's clear(?) that what
would be the "normal" contents of the various packages isn't going to
be what one would expect; in particular, the base package is going to
be what i call "overpackaged", with lots of stuff it doesn't really
need so i'm guessing what's going into the image is more than is
really necessary. somehow, though, it's worked all this time until
recently, when i noticed this quirk was causing some Q/A issues, so i
took a deep breath, commented out that line from the class file to use
the default packaging approach and re-tried the build, which is when
all hell broke loose.
it turns out that these internal recipes use local Makefile-based
source directories, which build, then install their generated
artifacts in a temporary (non-YP) staging area per recipe, *then*
manually (little by little) install stuff in ${D} via a general
do_install() routine, at which point the regular packaging and
subsequent steps kick in, but it's what now gets copied into ${D} that
is causing grief.
apparently, many of these recipes generate a shared library, and i'm
well aware that the *normal* packaging involving a shared library is
like this example from libidn2 (snipped for brevity to show only
shared lib stuff):
libidn2/
usr/
lib/
libidn2.so.0 -> libidn2.so.0.3.7
libidn2.so.0.3.7[actual library file]
libidn2-dev/
usr/
lib/
libidn2.so -> libidn2.so.0.3.7
so the *normal* packaging for a shared lib is that the lib itself and
a symlink to it go into the base package, while another symlink goes
into the "-dev" package. i'd never really paid that much attention to
that until i reset that PACKAGES variable, as all of these internal
recipes end up installing into ${D} nothing but the shared lib file
itself under /usr/lib, and why this has worked all this time is a
mystery, but having made this change is generating all sorts of Q/A
diagnostics as this is what ends up in ${D} using a "fubar" recipe
example given the manual installation being done using normal
packaging:
fubar/
usr/
bin/
... snip ...
no lib/ directory
fubar-dev/
usr/
lib/
libfnvcma.so[actual shared lib]
unsurprisingly, there are QA issues with the above:
ERROR: fubar-1.0-r0 do_package_qa: QA Issue: -dev package contains non-symlink
.so: fubar-dev
path .../packages-split/fubar-dev/usr/lib/libfnvcma.so'[dev-elf]
ERROR: fubar-1.0-r0 do_package_qa: QA Issue: fubar rdepends on fubar-dev
[dev-deps]
*sigh*.
in short, because these internal recipes generate only the single
shared lib file itself and that's all that's copied into ${D}, the
regular Q/A tests will naturally barf, and i could use INSANE_SKIP all
over the place to get around this, but it seems to me that the proper
approach is to tell the developers that they need to start generating
the appropriate symlinks for all of their recipes so packaging is done
properly.
i'm just about to check if there is a switch or class i can invoke
that will "fix" this issue (as in, set up the shared libs in ${D}
properly), but apart from that, am i correct in thinking that the
developers need to do this correctly from the beginning?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152600):
https://lists.openembedded.org/g/openembedded-core/message/152600
Mute This Topic: https://lists.openembedded.org/mt/83283893/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] follow up: keeping the source with an "externalsrc"-based recipe
On Mon, 31 May 2021, Quentin Schulz wrote:
> > LICENSE = "CLOSED"
> > LIC_FILES_CHKSUM = ""
> > FILESEXTRAPATHS_prepend := "${THISDIR}:"
> > SRC_URI := "file://src"
>
> No need for := here, a simple = should suffice?
>
> > S = "${WORKDIR}/src"
> >
>
> Why not put the sources in:
> meta-mylayer/recipes-test/test/my-test-0.1/src/
> meta-mylayer/recipes-test/test/my-test_0.1.bb
>
> and have SRC_URI = "file://src/" without needing to add
> FILESEXTRAPATHS_prepend := "${THISDIR}:" so that it follows what almost
> every recipe does?
>
> S will be as you wrote above.
ah, i misread what you were suggesting here, yes, your idea is
cleaner.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152463):
https://lists.openembedded.org/g/openembedded-core/message/152463
Mute This Topic: https://lists.openembedded.org/mt/83147632/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] follow up: keeping the source with an "externalsrc"-based recipe
On Mon, 31 May 2021, Quentin Schulz wrote:
> Hi Robert,
>
> On Fri, May 28, 2021 at 05:02:13PM -0400, Robert P. J. Day wrote:
> > 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.
> > > https://git.savannah.nongnu.org/cgit/dmidecode.git/tree/Makefile
> > >
> > > So yes, except if you patch the Makefile to support out-of-tree build,
> > > you would need both EXTERNALSRC and EXTERNALSRC_BUILD set to the same
> > > value.
> > >
> > > Maybe a Cmake example would suit better since B is set to
> > > "${WORKDIR}/build"
> > > by default?
> > >
> > > Otherwise, write a proper Makefile that allows out-of-tree builds for
> > > the example :)
> >
> > in the end, i suspect i was overthinking it, thinking somehow there
> > was some magic to "externalsrc", only to finally realize it was
> > totally inappropriate for source that had to be built in-tree. so i
> > just switched over to using SRC_URI and, for various recipes like
> > dmidecode, i created a recipe that started with some variation of:
> >
> > LICENSE = "CLOSED"
> > LIC_FILES_CHKSUM = ""
> > FILESEXTRAPATHS_prepend := "${THISDIR}:"
> > SRC_URI := "file://src"
>
> No need for := here, a simple = should suffice?
yup, i already simplified that, even though it doesn't hurt
anything.
> > S = "${WORKDIR}/src"
> >
>
> Why not put the sources in:
> meta-mylayer/recipes-test/test/my-test-0.1/src/
> meta-mylayer/recipes-test/test/my-test_0.1.bb
>
> and have SRC_URI = "file://src/" without needing to add
> FILESEXTRAPATHS_prepend := "${THISDIR}:" so that it follows what
> almost every recipe does?
>
> S will be as you wrote above.
i know it looks goofy, but these recipes are just meant to be
templates to show other developers what a normal Makefile-based recipe
will look like, and if they have their source elsewhere, they'll have
to set FILESEXTRAPATHS anyway. i was grappling with how to do this,
but this is not meant to be production-level, it's just for people to
see how to structure their code so it follows the OE model. i might
re-do it.
> I thought you were trying to find an example with externalsrc for
> our docs, but it seems you have a different thing in mind, can you
> tell us so we are able to help you with your actual issue/question
> :) ?
externalsrc turned out to have the fatal flaw that it doesn't scale
well for source that can't be built out-of-tree.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152462):
https://lists.openembedded.org/g/openembedded-core/message/152462
Mute This Topic: https://lists.openembedded.org/mt/83147632/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
