Re: [yocto] coreutils postinstall warning
On Mon, Aug 20, 2018 at 8:16 AM Seth Bollinger wrote:
> Hello All,
>
> We've been seeing the following warning for a while now. Is this expected?
>
> WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
> scriptlets of ['coreutils'] to defer them to first boot is deprecated.
> Please place them into pkg_postinst_ontarget_${PN} ().
>
> From what I can see, it's being caused by update-alternatives. Is there a
> workaround for this?
>
I'll answer my own question since it may be of value to someone else.
coreutils, util-linux and busybox all provide overlapping utilities. Most
are covered by update alternatives, some are not. If you have enabled one
of those in busybox, then update alternatives will fail trying to make the
symbolic link. As I understand it (from the warning message) is that
failing the postinst step used to be a way to ask to be executed at target
runtime. The solution is to have only one package provide the conflicting
utility (or add alternatives to all packages that provide the utility).
Here's an example error message:
update-alternatives: Error: not linking
/home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
to /bin/busybox.nosuid since
/home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
exists and is not a link
Seth
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] coreutils postinstall warning
On Mon, Aug 20, 2018 at 8:31 AM Alexander Kanavin
wrote:
> 2018-08-20 15:16 GMT+02:00 Seth Bollinger :
> > We've been seeing the following warning for a while now. Is this
> expected?
> >
> > WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
> > scriptlets of ['coreutils'] to defer them to first boot is deprecated.
> > Please place them into pkg_postinst_ontarget_${PN} ().
> >
> > From what I can see, it's being caused by update-alternatives. Is there
> a
> > workaround for this?
>
> You need to investigate further, specifically why the postinst
> scriptlet is failing. Usually log.do_rootfs should give a hint.
>
This seems to be the issue. I should mention this is sumo coreutils.
update-alternatives: renaming link link from /bin/link to /usr/bin/link
mv: cannot stat '/bin/link': No such file or directory
warning: %post(coreutils-8.29-r0.7.aarch64) scriptlet failed, exit status 1
Seth
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] coreutils postinstall warning
Hello All,
We've been seeing the following warning for a while now. Is this expected?
WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
scriptlets of ['coreutils'] to defer them to first boot is deprecated.
Please place them into pkg_postinst_ontarget_${PN} ().
>From what I can see, it's being caused by update-alternatives. Is there a
workaround for this?
Thanks,
Seth
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Multiple kernels same machine
Hello All, I'm trying to build two different kernels for the same machine. One kernel supports a manufacturing process, the other production kernel is meant to run on the device after it's been manufactured. I've manipulated the two images I'm using to build the two kernels (the solution is _very_ ugly), but as you can imagine, they end up stomping on each other, causing a copious amount of warnings. WARNING: The recipe linux-dbl-manuf is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /usr/local/yocto/gateways-yocto/build/tmp/sysroots/x2e/pkgdata/runtime/kernel-module-xt-statistic Matched in manifest-x2e-linux-dbl.packagedata Is there an elegant way to resolve these warnings? Is there an example somewhere of two kernels being built for the same machine? Thanks, Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image that depends on another image
On Thu, Aug 21, 2014 at 7:25 PM, Christopher Larson wrote: > > On Thu, Aug 21, 2014 at 5:08 PM, Seth Bollinger > wrote: > >> Our device requires two images to be built. Is there any way to have the >> first image depend on the second image? > > > do_rootfs[depends] += "some-other-image:do_rootfs" would probably do. > I hate to resurrect this thread, but after testing this out and using it we ran into a small hiccup. Since we're using the second image to generate a second partition, a lot of the dependencies actually need to be injected into the first image (users, utilities, etc.). Is there a way to do this? Thanks again! Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Image that depends on another image
Hello All, Our device requires two images to be built. Is there any way to have the first image depend on the second image? Thanks, Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Coverity
Hello All, We have a few code bases that we need to run Coverity on. Does someone have an example of how that would hook into a recipe? Thanks, Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] OpenEmbedded and musl-libc
> > > I saw that yesterday too and thought it could be interesting for > Yocto. I'm curious as to why it's better than uclibc though > (genuinely curious, I know little about uclibc beyond "it's smaller"). > It been a while since I've reviewed uclibc, but doesn't it break a lot of software with its vfork only paradigm? Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ldd
Hello All, I don't see that ldd is part of the cross toolchain build anywhere. Am I missing something? Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Resend: PATCH] ncurses-terminfo: Remove bashism from basic terminfo installation
The vtX terminfo files aren't being copied on systems where bash isn't
the default shell (debian, etc.). I removed the bash specific syntax
so the files are properly copied on these systems.
Signed-off-by: Seth Bollinger
---
meta/recipes-core/ncurses/ncurses.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index 671daf8..01cdf13 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -174,7 +174,7 @@ shell_do_install() {
# include some basic terminfo files
# stolen ;) from gentoo and modified a bit
-for x in ansi console dumb linux rxvt screen sun
vt{52,100,102,200,220} xterm-color xterm-xfree86 xterm-256color
+for x in ansi console dumb linux rxvt screen sun vt52 vt100 vt102
vt200 vt220 xterm-color xterm-xfree86 xterm-256color
do
local termfile="$(find "${D}${datadir}/terminfo/" -name "${x}"
2>/dev/null)"
local basedir="$(basename $(dirname "${termfile}"))"
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] ncurses-terminfo: Remove bashism from basic terminfo installation
The vtX terminfo files aren't being copied on systems where bash isn't
the default shell (debian, etc.). I removed the bash specific syntax
so the files are properly copied on these systems.
Signed-off-by: Seth Bollinger
---
meta/recipes-core/ncurses/ncurses.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index 671daf8..01cdf13 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -174,7 +174,7 @@ shell_do_install() {
# include some basic terminfo files
# stolen ;) from gentoo and modified a bit
-for x in ansi console dumb linux rxvt screen sun
vt{52,100,102,200,220} xterm-color xterm-xfree86 xterm-256color
+for x in ansi console dumb linux rxvt screen sun vt52 vt100 vt102
vt200 vt220 xterm-color xterm-xfree86 xterm-256color
do
local termfile="$(find "${D}${datadir}/terminfo/" -name "${x}"
2>/dev/null)"
local basedir="$(basename $(dirname "${termfile}"))"
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] DISTRO_FEATURES and shared SSTATE
Hello All, How does yocto know which package version to choose for an image if the package can be altered (compilation difference, or perhaps config alteration, etc.) by a DISTRO_FEATURE? For instance, if I make a change to sysvinit-inittab/inittab based on a DISTRO_FEATURE, I can have multiple versions of sysvinit-inittab, but only one shipping package, right? If I'm building two different images that have that DISTRO_FEATURE set differently, won't one of the builds have the incorrect sysvinit-inittab package installed? I believe PAM support would be another good example. Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipes that update a shared file
On Thu, Oct 10, 2013 at 10:09 AM, Burton, Ross wrote:
> Use $D instead of ${D}. ${D} will get expanded when the package is
> created but you want to use the environment variable $D.
>
Looks like that worked! I apologize for missing the curly braces in your
previous response.
Thanks very much!
Seth
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipes that update a shared file
On Thu, Oct 10, 2013 at 9:40 AM, Burton, Ross wrote:
> You need to use $D so that you're not attempting to write to the *host's*
> /etc:
>
> echo test >> $D/etc/inittest2
>
> In a postinst $D may be set, and if it is then the postinst is being
> ran on the host at rootfs time, and points to where the rootfs is
> being constructed.
>
Ok, I changed to as follows:
pkg_postinst_${PN} () {
echo "testtest" >> ${D}/etc/inittest
}
After that I do a find and the file is only populated in the recipe's image
directory, not the rootfs.
$ find . -iname inittest
./tmp/work/armv5te-dbl-linux-gnueabi/widget/1.0-r0/image/etc/inittest
Thanks!
Seth
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipes that update a shared file
On Thu, Oct 10, 2013 at 4:31 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:
> That's really the recommended way to do it. If the software being
> configured
> supports it, another way is to set it up to read all configuration files
> from a
> directory and then you can simply install a new file into that directory
> from
> the other recipe (e.g. Apache is usually configured to read all
> configuration
> files in /etc/httpd/conf.d or similar).
>
Yes, I would have liked to solve the problem that way, but unfortunately
the software doesn't support it, and we don't want to make changes
currently. :)
I'm having a lot of trouble getting pkg_postinst() to work. From what I've
read, it should happen during rootfs generation, but I'm not see the file
in the rootfs.
I found an example in the xfce4-session_4.10.0.bb recipe. It looks like
/etc/hosts is installed by netbase, so this is very similar to what my
recipe is doing.
# protect from frightening message that xfce might not work correctly
pkg_postinst_${PN} () {
echo 127.0.0.1${MACHINE} >> /etc/hosts
}
I've tried this in my recipe, and the file that I expect to be present in
the rootfs is not there...not sure what I'm doing wrong.
pkg_postinst_${PN} () {
echo test >> /etc/inittest2
}
Also, the documentation states that this mechanism can be used to do things
on first boot. Do I need to add code to make sure that this doesn't happen
on first boot?
Thanks!
Seth
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Recipes that update a shared file
Hello All, What's the best practice for recipes that need to update a shared file provided by a different recipe? For example let's say that the widget-watcher recipe creates /etc/ww.conf and the widget1, and widget2 recipes need to append a line to the config. I've searched through the recipes a bit and can't find a good example. The closest that I've seen is pkg_postinst(). Is that the best method? Thanks! Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] opkg list-installed is empty
Paul Eggleton June 3, 2013 7:10 47AM Hi Seth,If /var/lib/opkg is empty in your image, it can only be because its contents have been deleted; and that could be either because the value of IMAGE_FEATURES doesn't end up containing package-management, or alternatively remove_packaging_data_files is being added manually to ROOTFS_POSTPROCESS_COMMAND (as core-image-minimal does). I'd suggest using bitbake -e your-image | less and looking at the values of IMAGE_FEATURES and ROOTFS_POSTPROCESS_COMMAND to see what's really going on.Cheers,Paul Thanks Paul! As usual, you nailed it. I missed the ROOTFS_POSTPROCESS_COMMAND that I pulled in when I copied core-image-minimal. Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] opkg list-installed is empty
Hello All, I'm having a problem with opkg. When I run the image I've built with the package-management feature and PACKAGE_CLASS equal to package_ipk, the image has no installed packages. They're obviously installed, because it's running but "opkg list-installed" is empty. I was expecting a large list of installed packages. I don't see anything I would expect to see in /var/lib/opkg. I must be missing something fundamental, but after reviewing the documentation and code, I'm coming up empty. Please enlighten me! Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] resize_inode
Hello All, I'm trying to create a small SD card image that I can quickly dd to card and then do an online resize as a post process step to take advantage of the entire space of the card. Similar to how the raspbian image works. Unfortunately genext2fs doesn't seem to set this flag (and reserve the required resources), so the online resize fails. I tried using tune2fs, as it looked like there was some interest in adding support, but it looks like it never happened. Has anyone else run into this issue? Is there a solution? resize2fs 1.42.1 (17-Feb-2012) Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 15 resize2fs: Filesystem does not support online resizing | Setting filesystem feature 'resize_inode' not supported. | tune2fs 1.42.1 (17-Feb-2012) Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bash specific syntax in bbclass files
Hello All,
I recently ran into a problem in
meta-raspberrypi/classes/sdcard_image-rpi.bbclass
The following was run through my default debian dash shell (I thought I
switched a while back, but I must have reverted my VM image or
something...).
# If SDIMG_ROOTFS_TYPE is a .xz file use xzcat
if [[ "$SDIMG_ROOTFS_TYPE" == *.xz ]]
then
The bash specific syntax ([[) failed in dash causing the "else" path to
be traversed instead of the correct "then" path. The failure was silent
and resulted in a blind copy of a compressed rootfs to the sdcard
image. Of course this didn't run. :)
1. Is there particular shell syntax that class files should stick too?
2. I couldn't find a wildcard string search in dash. Can anyone
suggest a more shell agnostic way to do this?
3. Is there a way to guarantee we're running in bash if we're using
bash specific syntax?
My solution was the following, but it's less readable.
if echo "${SDIMG_ROOTFS_TYPE}" | egrep -q "*\.xz"
Thanks,
Seth
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-raspberrypi
Hello All, Is anyone maintaining the meta-raspberrypi repository? Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 2/2] sdcard_image-rpi.bbclass: Copy startup files required for 16MB GPU operation.
start_cd.elf and fixup_cd.dat are required when running the system with
a 16MB GPU memory configuration. This change copies all files contained
in bcm2835-bootfiles instead of cherry picking.
Signed-off-by: Seth Bollinger
---
classes/sdcard_image-rpi.bbclass |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/classes/sdcard_image-rpi.bbclass
b/classes/sdcard_image-rpi.bbclass
index 7fe7c35..2ae5fd4 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -77,11 +77,7 @@ IMAGE_CMD_rpi-sdimg () {
# Create a vfat image with boot files
BOOT_BLOCKS=$(LC_ALL=C parted -s ${SDIMG} unit b print | awk '/ 1
/ { print substr($4, 1, length($4 -1)) / 512 /2 }')
mkfs.vfat -n "${BOOTDD_VOLUME_ID}" -S 512 -C ${WORKDIR}/boot.img
$BOOT_BLOCKS
-mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/start.elf ::
-mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/fixup.dat ::
-mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/config.txt ::
-mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/cmdline.txt ::
-mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/bootcode.bin ::
+mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/* ::/
mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${MACHINE}.bin ::kernel.img
if [ -n ${FATPAYLOAD} ] ; then
--
1.7.2.5
>From 2ac1c7b285fa0f48ae88461e72fd9b95d8ee2576 Mon Sep 17 00:00:00 2001
From: Seth Bollinger
Date: Mon, 22 Apr 2013 07:25:58 -0500
Subject: [PATCH 2/2] sdcard_image-rpi.bbclass: Copy startup files required for
16MB GPU operation.
start_cd.elf and fixup_cd.dat are required when running the system with
a 16MB GPU memory configuration. This change copies all files contained
in bcm2835-bootfiles instead of cherry picking.
Signed-off-by: Seth Bollinger
---
classes/sdcard_image-rpi.bbclass |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index 7fe7c35..2ae5fd4 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -77,11 +77,7 @@ IMAGE_CMD_rpi-sdimg () {
# Create a vfat image with boot files
BOOT_BLOCKS=$(LC_ALL=C parted -s ${SDIMG} unit b print | awk '/ 1 / {
print substr($4, 1, length($4 -1)) / 512 /2 }')
mkfs.vfat -n "${BOOTDD_VOLUME_ID}" -S 512 -C ${WORKDIR}/boot.img
$BOOT_BLOCKS
- mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/start.elf ::
- mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/fixup.dat ::
- mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/config.txt ::
- mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/cmdline.txt ::
- mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/bootcode.bin ::
+ mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/*
::/
mcopy -i ${WORKDIR}/boot.img -s
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${MACHINE}.bin ::kernel.img
if [ -n ${FATPAYLOAD} ] ; then
--
1.7.2.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 1/2] sdcard_image-rpi.bbclass: Fix error in conditional test
When the shell tests for rootfs type I was seeing "[[: not found". I
use echo and egrep to test for the xz rootfs type to work around this
error.
Signed-off-by: Seth Bollinger
---
classes/sdcard_image-rpi.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/classes/sdcard_image-rpi.bbclass
b/classes/sdcard_image-rpi.bbclass
index 421f561..7fe7c35 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -99,7 +99,7 @@ IMAGE_CMD_rpi-sdimg () {
# Burn Partitions
dd if=${WORKDIR}/boot.img of=${SDIMG} conv=notrunc seek=1
bs=$(expr ${IMAGE_ROOTFS_ALIGNMENT} \* 1024) && sync && sync
# If SDIMG_ROOTFS_TYPE is a .xz file use xzcat
-if [[ "$SDIMG_ROOTFS_TYPE" == *.xz ]]
+if echo "${SDIMG_ROOTFS_TYPE}" | egrep -q "*\.xz"
then
xzcat ${SDIMG_ROOTFS} | dd of=${SDIMG} conv=notrunc seek=1
bs=$(expr 1024 \* ${BOOT_SPACE_ALIGNED} + ${IMAGE_ROOTFS_ALIGNMENT} \*
1024) && sync && sync
else
--
1.7.2.5
>From 26b0b8b79376eea69aeaf91daf43bc6807a09dd0 Mon Sep 17 00:00:00 2001
From: Seth Bollinger
Date: Mon, 22 Apr 2013 07:23:45 -0500
Subject: [PATCH 1/2] sdcard_image-rpi.bbclass: Fix error in conditional test
When the shell tests for rootfs type I was seeing "[[: not found". I
use echo and egrep to test for the xz rootfs type to work around this
error.
Signed-off-by: Seth Bollinger
---
classes/sdcard_image-rpi.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index 421f561..7fe7c35 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -99,7 +99,7 @@ IMAGE_CMD_rpi-sdimg () {
# Burn Partitions
dd if=${WORKDIR}/boot.img of=${SDIMG} conv=notrunc seek=1 bs=$(expr
${IMAGE_ROOTFS_ALIGNMENT} \* 1024) && sync && sync
# If SDIMG_ROOTFS_TYPE is a .xz file use xzcat
- if [[ "$SDIMG_ROOTFS_TYPE" == *.xz ]]
+ if echo "${SDIMG_ROOTFS_TYPE}" | egrep -q "*\.xz"
then
xzcat ${SDIMG_ROOTFS} | dd of=${SDIMG} conv=notrunc seek=1
bs=$(expr 1024 \* ${BOOT_SPACE_ALIGNED} + ${IMAGE_ROOTFS_ALIGNMENT} \* 1024) &&
sync && sync
else
--
1.7.2.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] AUTOREV problems
Hello All,
I've been having some serious problems trying to get my image to rebuild
recipes when their upstream repositories have changed. I have SRCREV =
${AUTOREV} in my recipe and in bitbake -e I see these 2 lines:
# SRCREV=${AUTOREV}
SRCREV="AUTOINC"
I've found BB_SRCREV_POLICY and I've set that explicitly to clear, even
though that seems to be the default. Auto didn't seem to work, even though
it looks like it should from the code.
When I try rebuilding my recipe, it seems to find that everything is cached
and doesn't even attempt the fetch, even though I know the repository has
changed (that's the reason I want to rebuild :)). I've tried whacking
tmp/cache/*, but that didn't help. I tried whacking the stamp for
do_fetch. That didn't help unless I explicitly built using the "fetch"
command, then it at least appeared to fetch. However, when I tried to
build the image after that, it didn't try to rebuild the recipe that had
just fetched.
The only way I could get it to rebuild was to cleansstate on the recipe and
then rebuild the image. I assume this isn't the way it should be working.
1. What is the expected operation of bitbake builds for recipes using
autorev?
2. How can I get my autorev recipes to rebuild when their repositories
change?
3. If this is working for everyone else, how can I find what I have
screwed up? :)
Thanks,
Seth
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Classes
Hello, Will anyone recommend some classes regarding yocto and open embedded? It would be nice to get up to speed quickly and into the nitty gritty instead of an overview. Something covering the following items would be nice: 1. How should projects be laid out? Distro, image, task, BSP, what things should go where? 2. How should subprojects inherit from superprojects? If you need to create many subplatforms from a base platform, what's the best way to go about this? 3. How should classes such as distutils be created to be inherited by other recipes (ruby modules that require a C extension to be compiled would be one example). 4. How should hardware specific software be handled? I fear that (as a newb) I will design a layout that will be sub-optimal, but we'll discover that after we have 25 platforms that will need major refactoring. :) Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Installing Kernel Modules
Hello All, I currently have a modules*.tgz in my tmp/images/deploy directory that contains all of the kernel modules built. What's the yocto way to pull only the modules I care about into the rootfs image? Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
