[yocto] SRCREV issue with linux-yocto-custom do_validate_branches()
Hi All,
I'm having a little trouble with do_validate_branches() inherited by my
linux-yocto-custom.
I'm building the 3.14.28 kernel with ltsi kernel patch set applied, so was
trying to set this up with a custom linux recipe in my bsp.
Pointing to a branch in my own git repo that has the patch set pre-applied.
I've got a clone of dizzy. Which I used yocto-bsp create to start my bsp layer.
But the process stops in do_validate_branches() with the following error log:
DEBUG: Executing shell function do_validate_branches
usage: git cat-file (-t|-s|-e|-p||--textconv)
or: git cat-file (--batch|--batch-check) <
can be one of: blob, tree, commit, tag
-tshow object type
-sshow object size
-eexit with zero when there's no error
-ppretty-print object's content
--textconvfor blob objects, run textconv on object's content
--batch[=]show info and content of objects fed from the
standard input
--batch-check[=]
show info about objects fed from the standard input
ERROR: is not a valid commit ID.
ERROR: The kernel source tree may be out of sync
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_validate_branches (log file is located at
/opt/git/poky/build/tmp/work/mylayer-poky-linux-gnueabi/linux-yocto-custom/3.14.28+gitAUTOINC+7035c2a67d-r0/temp/log.do_validate_branches.56991)
The do_validate_branches() code from kernel-yocto.bbclass is as follows...
# Ensure that the branches (BSP and meta) are on the locations specified by
# their SRCREV values. If they are NOT on the right commits, the branches
# are corrected to the proper commit.
do_validate_branches() {
set +e
cd ${S}
export KMETA=${KMETA}
machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
machine_srcrev="${SRCREV_machine}"
# if SRCREV is AUTOREV it shows up as AUTOINC there's nothing to
# check and we can exit early
if [ "${machine_srcrev}" = "AUTOINC" ]; then
bbnote "SRCREV validation is not required for AUTOREV"
elif [ "${machine_srcrev}" = "" ] && [ "${SRCREV}" != "AUTOINC" ]; then
# SRCREV_machine_ was not set. This means that a
custom recipe
# that doesn't use the SRCREV_FORMAT "machine_meta" is being
built. In
# this case, we need to reset to the give SRCREV before heading
to patching
bbnote "custom recipe is being built, forcing SRCREV to
${SRCREV}"
force_srcrev="${SRCREV}"
else
git cat-file -t ${machine_srcrev} > /dev/null
if [ $? -ne 0 ]; then
bberror "${machine_srcrev} is not a valid commit ID."
bbfatal "The kernel source tree may be out of sync"
fi
force_srcrev=${machine_srcrev}
fi
## KMETA branch validation.
target_meta_head="${SRCREV_meta}"
if [ "${target_meta_head}" = "AUTOINC" ] || [ "${target_meta_head}" =
"" ]; then
bbnote "SRCREV validation skipped for AUTOREV or empty meta
branch"
else
meta_head=`git show-ref -s --heads ${KMETA}`
git cat-file -t ${target_meta_head} > /dev/null
if [ $? -ne 0 ]; then
bberror "${target_meta_head} is not a valid commit ID"
bbfatal "The kernel source tree may be out of sync"
fi
if [ "$meta_head" != "$target_meta_head" ]; then
bbnote "Setting branch ${KMETA} to ${target_meta_head}"
git branch -m ${KMETA} ${KMETA}-orig
git checkout -q -b ${KMETA} ${target_meta_head}
if [ $? -ne 0 ];then
bbfatal "Could not checkout ${KMETA} branch
from known hash ${target_meta_head}"
fi
fi
fi
git checkout -q -f ${machine_branch}
if [ -n "${force_srcrev}" ]; then
# see if the branch we are about to patch has been properly
reset to the defined
# SRCREV .. if not, we reset it.
branch_head=`git rev-parse HEAD`
if [ "${force_srcrev}" != "${branch_head}" ]; then
current_branch=`git rev-parse --abbrev-ref HEAD`
git branch "$current_branch-orig"
git reset --hard ${force_srcrev}
fi
fi
}
It seems like the problem is..
Re: [yocto] A simpler way to apply custom config files to an image ?
Laurent, > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Anders Darander > Sent: Friday, April 17, 2015 2:01 AM > To: yocto@yoctoproject.org > Subject: Re: [yocto] A simpler way to apply custom config files to an image ? > > * Smith, Virgil [150416 17:33]: > > > > I want to customize various config file of an image I'm building (e.g. > > > network interfaces, sshd banner, hostapd, etc..). > > > Paul Eggleton just gave a response to a similar question "Force install > package last" > > https://lists.yoctoproject.org/pipermail/yocto/2015-April/024548.html > > > > - If not possible and I have to stick with bbappend to every recipe > > > concerned, then how could I do it in the case of a config file > > > coming from the source package instead of the recipe ? > > > If I understand you correctly, that would be a patch. For "unchecked" > > whole replacement of files, I've seen bbappends with a do_patch_append > > function to copy files (specified individually in SRC_URI like patch > > files) from the base of the work dir to the correct path under the > > source directory. > > Unless the buildprocess heavily modifies the config file, I wouldn't create a > patch to patch it in the source tree. I'd rather just add the complete config > file to FILES +=... and then replace the one from the source package with my > copy in a do_install_appen() function. > > This is by far the simplest way of those two. I had similar issues getting my build system to take my copy of the kernel defconfig instead of the ones on the other layers. In bblayers.conf, I made sure my layer was at the top of the BBLAYERS list and I set the BBFILE_PRIORITY for my layer to a higher number than the other layers (in my layer's conf/layer.conf file). See http://www.yoctoproject.org/docs/1.7.1/mega-manual/mega-manual.html#var-BBFILE_PRIORITY for details on BBFILE_PRIORITY. I don't think the order in BBLAYERS makes a difference, but it is one way I can easily remember the BBFILE_PRIORITY for the different layers. I would also suggest using a bbappend in your own layer to modify the configuration file. It makes it much easier to handle mainline updates. If the change you are making is not version dependent then you can use a wildcard for the bbappend name in your layer. For example, I have the cron job list specified in a configuration file in my layer for cronie. I named the bbappend "cronie_%.bbappend". Now the main cronie package can continue to get updates for newer versions and there is nothing I have to do with cronie in my layer. Regards, Bryan > > Cheers, > Anders > > -- > Anders Darander > ChargeStorm AB / eStorm AB > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SRCREV issue with linux-yocto-custom do_validate_branches()
On 2015-04-17 6:12 AM, Mills, Clayton wrote:
Hi All,
I'm having a little trouble with do_validate_branches() inherited by my
linux-yocto-custom.
I'm building the 3.14.28 kernel with ltsi kernel patch set applied, so was
trying to set this up with a custom linux recipe in my bsp.
Out of curiosity, was something missing in the linux-yocto 3.14 LTSI
integration ? I'll comment on the specifics below, but I was wondering
about that high level point as well.
Pointing to a branch in my own git repo that has the patch set pre-applied.
I've got a clone of dizzy. Which I used yocto-bsp create to start my bsp layer.
But the process stops in do_validate_branches() with the following error log:
DEBUG: Executing shell function do_validate_branches
usage: git cat-file (-t|-s|-e|-p||--textconv)
or: git cat-file (--batch|--batch-check) <
can be one of: blob, tree, commit, tag
-tshow object type
-sshow object size
-eexit with zero when there's no error
-ppretty-print object's content
--textconvfor blob objects, run textconv on object's content
--batch[=]show info and content of objects fed from the
standard input
--batch-check[=]
show info about objects fed from the standard input
ERROR: is not a valid commit ID.
ERROR: The kernel source tree may be out of sync
WARNING: exit code 1 from a shell command.
Do you have the entire log pastebin'd somewhere ? It would be nice to know
if this is the meta, or machine validation that is getting an empty commit.
ERROR: Function failed: do_validate_branches (log file is located at
/opt/git/poky/build/tmp/work/mylayer-poky-linux-gnueabi/linux-yocto-custom/3.14.28+gitAUTOINC+7035c2a67d-r0/temp/log.do_validate_branches.56991)
The do_validate_branches() code from kernel-yocto.bbclass is as follows...
# Ensure that the branches (BSP and meta) are on the locations specified by
# their SRCREV values. If they are NOT on the right commits, the branches
# are corrected to the proper commit.
do_validate_branches() {
set +e
cd ${S}
export KMETA=${KMETA}
machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
machine_srcrev="${SRCREV_machine}"
# if SRCREV is AUTOREV it shows up as AUTOINC there's nothing to
# check and we can exit early
if [ "${machine_srcrev}" = "AUTOINC" ]; then
bbnote "SRCREV validation is not required for AUTOREV"
elif [ "${machine_srcrev}" = "" ] && [ "${SRCREV}" != "AUTOINC" ]; then
# SRCREV_machine_ was not set. This means that a
custom recipe
# that doesn't use the SRCREV_FORMAT "machine_meta" is being
built. In
# this case, we need to reset to the give SRCREV before
heading to patching
bbnote "custom recipe is being built, forcing SRCREV to
${SRCREV}"
force_srcrev="${SRCREV}"
else
git cat-file -t ${machine_srcrev} > /dev/null
if [ $? -ne 0 ]; then
bberror "${machine_srcrev} is not a valid commit ID."
bbfatal "The kernel source tree may be out of sync"
fi
force_srcrev=${machine_srcrev}
fi
## KMETA branch validation.
target_meta_head="${SRCREV_meta}"
if [ "${target_meta_head}" = "AUTOINC" ] || [ "${target_meta_head}" =
"" ]; then
bbnote "SRCREV validation skipped for AUTOREV or empty meta
branch"
else
meta_head=`git show-ref -s --heads ${KMETA}`
git cat-file -t ${target_meta_head} > /dev/null
if [ $? -ne 0 ]; then
bberror "${target_meta_head} is not a valid commit ID"
bbfatal "The kernel source tree may be out of sync"
fi
if [ "$meta_head" != "$target_meta_head" ]; then
bbnote "Setting branch ${KMETA} to ${target_meta_head}"
git branch -m ${KMETA} ${KMETA}-orig
git checkout -q -b ${KMETA} ${target_meta_head}
if [ $? -ne 0 ];then
bbfatal "Could not checkout ${KMETA} branch from
known hash ${target_meta_head}"
fi
fi
fi
git checkout -q -f ${machine_branch}
if [ -n "${force_srcrev}" ]; then
# see if the branch we are about to patch has been properly
reset to the defined
# SRCREV .. if not, we reset it.
Re: [yocto] Badly formatted subpath for git SRC_URI deletes portions of hard drive.
On Thursday 16 April 2015 07:35:40 Christopher Larson wrote: > On Thu, Apr 16, 2015 at 7:25 AM, Nicolas Dechesne < > > nicolas.deche...@linaro.org> wrote: > > On Thu, Apr 16, 2015 at 3:11 PM, Anders Darander > > > > wrote: > >> > > Running the recipe resulted in do_fetch (or do_unpack) failing again > >> > >> and > >> > >> > > complaining about missing files. This time the deletion was on a much > >> > > greater scale, it had deleted so much of my home-dir that my user > >> > > account was rendered entirely useless. The fastest way to recover > >> > > this > >> > > time was re-installing the machine. > >> > >> It's most likely a call to bb.utils.prunedir(destdir), with destdir > >> being set to '/'... > > > > ouch... this is a bit scary ;-) > > > > maybe we should assert the folder name is 'sane' when we do destructive > > operations like that. e.g. check that we are in TMPDIR, or TOPDIR.. > > > > hopefully nobody does sudo bitbake ;-) > > This is scary indeed. We definitely need to be more careful about calls to > dirname/basename with paths with a trailing or leading / in general, and > especially for removals, and just need to do more path > sanitization/normalization probably.. I have sent an additional patch to the bitbake list to try to protect against future instances of this issue, at least for bb.utils.prunedir() and bb.utils.remove(): http://lists.openembedded.org/pipermail/bitbake-devel/2015-April/005664.html Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [daisy][powertop] powertop_2.5.bb, do_configure) failed with exit code '1'
Hi,
This was not a problem on 1.6.2 then udpated and I'm unable to
configure powertop. I tried to erase sstate & tmp folder without
success.
The fix was to comment:
#LDFLAGS += "${EXTRA_LDFLAGS}"
in
poky/meta/recipes-kernel/powertop/powertop_2.5.bb
The logs show that the ${EXTRA_LDFLAGS} gets added during the configure?
Any thoughts on why?
I looks at commits from 1.6.2 to 1.6.3 and I don't see why this could happen.
Could it be a update on Ubuntu 14.04?
thx,
-KA
Here's the complete logs:
log.do_configure:
https://gist.github.com/kapare/971387ca3812c019a65f
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-qemu-bsps
Hello all, I just put together a layer to warehouse miscellaneous qemu machine support. ppc64 is the there now, working on more. Contributions are welcome. https://github.com/akuster/meta-qemu-bsps enjoy, Armin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems enabling systemd
I've got an image for a AM3352 system based on Dylan and Arago and I'm trying to switch to systemd for init. So far I haven't had much luck. First off I'm getting different results depending on where I turn it on. I'm turning it on via the following 2 lines: DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" If I place these lines in my_image.bb file I seem to get a partial install of systemd, systemd_udev is there and seems to run but that's about it, there is no systemctrl journalctl and the sysvinit init scripts still seem to be called. If I place these lines in either local.conf or my_distrobution.conf all of the systemd utility seem to get installed and systemd startups up but it's clearly not configured correctly. For starters the systemd dbus isn't getting created and that seems to lead to a whole host of other problems, including journald constant spewing the following error messages: [ 55.926223] systemd-journald[715]: Failed to write entry, ignoring: Argument list too long [ 55.936931] systemd-journald[715]: Failed to rotate /run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No such file or directory [ 55.950911] systemd-journald[715]: Failed to write entry, ignoring: Argument list too long [ 55.961580] systemd-journald[715]: Failed to rotate /run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No such file or directory [ 55.975568] systemd-journald[715]: Failed to write entry, ignoring: Argument list too long [ 55.986329] systemd-journald[715]: Failed to rotate /run/log/journal/c37feca280b74ec583564afcc2a93f0a/system.journal: No such file or directory I don't know if it matters but this system has no display at all, it's a strictly embedded installation. Can anybody make any suggestions on what might be wrong? Thanks, Matt S. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-qemu-bsps
Hi Armin, I tested the ppc64 with poky master and looks great only a couple of issues, When is compiling the kernel show this warning related to the config, WARNING: [kernel config]: specified values did not make it into the kernel's final Value requested for CONFIG_FB_DDC not in final ".config" Requested value: "CONFIG_FB_DDC=y" Actual value set: "# CONFIG_FB_DDC is not set" Value requested for CONFIG_MMU_NOTIFIER not in final ".config" Requested value: "CONFIG_MMU_NOTIFIER=y" Actual value set: "" When built core-image-minimal and then tries to load qemu with nographic it didn't work the graphic mode works ok. QEMU Starting Build Date = Apr 30 2013 14:04:00 FW Version = git-8cfdfc43f4c4c8c8 Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/vty@7100 Populating /vdevice/nvram@7101 NVRAM: size=65536, fetch=200E, store=200F Populating /vdevice/v-scsi@7102 VSCSI: Initializing VSCSI: Looking for devices 8000 DISK : "QEMU QEMU HARDDISK1.6." 8200 CD-ROM : "QEMU QEMU CD-ROM 1.6." Populating /pci@8002000 Adapters on 08002000 00 (D) : 8086 100enetwork [ ethernet ] 00 0800 (D) : 1234 qemu vga 00 1000 (D) : 106b 003fserial bus [ usb-ohci ] No NVRAM common partition, re-initializing... Installing QEMU fb Scan USB... USB Keyboard USB Mouse USB Mouse No console specified using screen & keyboard Detected RAM kernel at 40 (f5f180 bytes) Welcome to Open Firmware Copyright (c) 2004, 2011 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Booting from memory... Linux ppc64 #1 SMP PREEMPT F Cheers, alimon On 17/04/15 15:45, akuster808 wrote: Hello all, I just put together a layer to warehouse miscellaneous qemu machine support. ppc64 is the there now, working on more. Contributions are welcome. https://github.com/akuster/meta-qemu-bsps enjoy, Armin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using the yocto version of createrepo (want the MISSINGOK flag)
Hi, I'm hosting an RPM based package repository on a different server than the build machine; I've been use the distro's version of the createrepo tool to keep the package index up to date. The Yocto version of the createrepo tool has some customizations notably adding a 'missingok' flag to handle 'RRECOMMENDED' packages which is really useful. How might I use the Yocto version of createrepo on my package server (or have I just got this all backwards)? These three options jumped to mind: 1. Do a minimal yocto install on the server and use the createrepo tool from the build. If so, is there a way to use the native/host tools built by Yocto? I've used a toolchain before but never python tools like createrepo. At this point, I figured I'd just tweak the run.do_package_index script (if I can figure out what nativepython is ;-) ). 2. BBCLASSEXTEND nativesdk for createrepo and add it to the buildtools-tarball.bb recipe. This feels like the best option. But the python environment doesn't get picked up properly...e.g. Traceback (most recent call last): File "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/share/createrepo/genpkgmetadata.py", line 26, in import rpm ImportError: No module named rpm 3. Totally outside of Yocto, patch and use a source version createrepo (or a speedy version like createrepo_c). I think this means also patching RPM support on the system to detect the RPMSENSE_MISSINGOK flag. Thanks for any advice and suggestions! --Ash -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using the yocto version of createrepo (want the MISSINGOK flag)
On Fri, Apr 17, 2015 at 2:43 PM, Ash Charles wrote: > 2. BBCLASSEXTEND nativesdk for createrepo and add it to the > buildtools-tarball.bb recipe. This feels like the best option. But > the python environment doesn't get picked up properly...e.g. > Traceback (most recent call last): > File > "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/share/createrepo/genpkgmetadata.py", > line 26, in > import rpm > ImportError: No module named rpm Option 2 seems to be working nicely. I just needed to add a few extra packages too: nativesdk-createrepo \ nativesdk-python-rpm \ nativesdk-python-smartpm \ nativesdk-libxml2-python \ --Ash -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-1.7.2.rc1 now available.
-e A release candidate build for yocto-1.7.2.rc1 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.2.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-intel : c39a4bf4450845fca6f1b26ccfc0db192a4567e8 meta-fsl-arm : db1571f40c375a398a8cdbb42de4c4f272ab0cd1 meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568 meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 meta-fsl-ppc : 5eeeb3ad74b72d904f805bc6e248e93e722b45c4 poky : 15892013ce11b0392060568c3c859bbf8280df49 This is an automated message from The Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder Email: elizabeth.flana...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
