Re: [yocto] Move device tree generation from include file to bbclass
Hi Bruce, Hi Nikolay > > >>> > >>> Adding oe-core, since that's the right place to have a discussion > >>> like this. Thanks I'm never sure where to ask what :) > >>> > As ARM now also moved to device tree it look like in future we > will > have more kernels that are using device tree then ones that are > not. > >>> > >>> > >>> True, but it has been like this for quite some time now :) > >>> > As far as I understand currently the generation of device trees is > controlled via KERNEL_DEVICETREE and is handled in via an include > file recipes-kernel/linux/linux-dtb.inc. > > I was thinking about moving this include into a class so it > becomes > easier to use. Before I dive into implementing something I would > like some feedback from the community. > >>> > >>> > >>> The big trick with changing anything like this is compatibility > with > >>> existing recipes. Whatever we do, existing recipes and layers > >>> shouldn't be broken .. or if they are broken, there should be a > >>> compelling technical reason to do so. > >>> > > I have the following variant in mind. > > Add the device tree generation to the current kernel.bbclass (or > let kernel.bblcass inherit from a kernel-dtb.bbclass). > This way all kernels would automatically be DT enabled. The class > would check if KERNEL_DEVICETREE is set and generate device trees > based on this information. For boards that don't have > KERNEL_DEVICETREE set the class would do nothing and the behavior > is like before. The advantage I see with this approach is that the > only thing a user needs to do is to set KERNEL_DEVICETREE in the > board and make sure the device trees are available in the kernel > they like to build. > >>> > >>> > >>> That's pretty much the experience that most users have now, since > >>> there's nearly always a kernel recipe created, that recipe includes > >>> linux-dtb.inc, and sets KERNEL_DEVICETREE. > >> > >> > >> As far as I understood, Pascal's idea is to remove the need for user > >> recipes to include linux-dtb.inc, and provide this functionality via > >> inheritance. > > > > That is obvious. My questions are around "why". There's no big > > technical advantage, and if you remove that existing file, you break > > existing recipes. Which means you need to leave a stub in place. > > > > So without a technical advantage, it's churn for the sake of churn. > > Well, removing redundancy and simplifying users' recipes could be > considered an advantage. Also, as the contents of linux-dtb.inc are > going to be moved to bbclass, the file can be left empty, later > maintainers remove the extra line from all users' recipes in following > commits. I don't see breaking as an option. I completely agree that it is not worth to breaking existing recipes because of that. But I think the option with an empty linux-dtb.inc is acceptable. > >>> Everything else happens to build and package the device tree. > >>> > >>> Was there something specifically that was causing issues with the > >>> current way of building them ? There was no specific issue except that it feels like an unnecessary includes. And it seems a bit odd to me that most of the work of building the kernel is done in bbclasses, while just the dtb handling is done with an include. But of course it still is more of a cosmetic change than a real technical necessity. Regards Pascal -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] python 2to3 conflicts when populating sdk
Hi, I am building an image in daisy branch with both python and python3 included. It works to build the image itself but when trying to make an sdk with 'bitbake -c populate_sdk' it fails with the following error when packages are installed: error: file /usr/bin/2to3 from install of python-2to3-2.7.3-r0.3.0.cortexa9hf_vfp_neon conflicts with file from package python3-2to3-3.3.3-r0.0.2.cortexa9hf_vfp_neon >From the log-file it happens in the sequence after the following printout in >the stage do_populate_sdk: NOTE: Installing complementary packages ... NOTE: Installing the following packages: gst-plugins-good-jpeg-dev shadow-securetty-dev gst-plugins-good-alpha-d Anyone having an idea how to resolv this conflict? Regards, /Peter Peter Bergin peter.ber...@tritech.se +46 733 35 21 05 www.tritech.se +46 31 763 38 00 Nordstadstorget 6 SE-411 05 G?teborg, Sweden -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Force to install package last
Hi David,
On Wednesday 15 April 2015 20:22:11 METHOT, DAVID wrote:
> I made a package recipe to merge files into my final rootfs (mostly init
> scripts under /etc).
>
> These files may be overriden by other packages so it is crucial that they
> remain intact.
>
> I am wondering if there is a way to make sure a package is the last one to
> be installed in the rootfs.
There is no mechanism for this. There are two alternative means to do this
kind of thing (just for the files that are already packaged by other recipes):
A) Use bbappends on the original recipes that package these files to change
them there as desired
or
B) Create a shell function in your image which makes the desired modifications
under ${IMAGE_ROOTFS} and add it to ROOTFS_POSTPROCESS_COMMAND; it will be
called towards the end of the image construction.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [poky] Initramfs not appended to kernel image
Hello,
For the last week or so I have been struggling to build a kernel image with an
embedded initramfs using the mechanisms provided by Poky Daisy. In local.conf I
have set INITRAMFS_IMAGE_BUNDLE to "1" and INITRAMFS_IMAGE to the name of my
image recipe. When I try to build virtual/kernel no errors are shown, but the
resulting kernel image does not contain an initramfs either.
I have traced this issue to the passing of the $use_alternate_initrd variable
in kernel.bbclass. The run.do_bundle_initramfs log contains the following
snippets:
Lines 103..120:
do_bundle_initramfs() {
if [ ! -z "sytxg1-bootmode-image" -a x"1" = x1 ]; then
echo "Creating a kernel image with a bundled initramfs..."
copy_initramfs
if [ -e arch/powerpc/boot/uImage ] ; then
mv -f arch/powerpc/boot/uImage
arch/powerpc/boot/uImage.bak
fi
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/usr/sytxg1-bootmode-image-sytxg1.cpio
kernel_do_compile
mv -f arch/powerpc/boot/uImage
arch/powerpc/boot/uImage.initramfs
mv -f arch/powerpc/boot/uImage.bak arch/powerpc/boot/uImage
# Update install area
echo "There is kernel image bundled with initramfs:
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs"
install -m 0644
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/image/boot/uImage-initramfs-sytxg1.bin
echo
"/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs"
fi
}
Lines 164..171:
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake uImage CC="powerpc-oe-linux-gcc "
LD="powerpc-oe-linux-ld.bfd "
if test "uImage.gz" = "uImage"; then
gzip -9c < "uImage" > "arch/powerpc/boot/uImage"
fi
}
So, it seems that although do_bundle_initramfs() sets the $use_alternate_initrd
to the correct value it is not passed in the oe_runmake call in
kernel_do_compile(). Judging from the contents of kernel.bbclass I would expect
it to be appended after the LD="..." statement. For now I have found a
workaround by copying the relevant oe_runmake call to do_bundle_initramfs().
The patch is included below.
I cannot imagine this is the intended way to make things work. Could anyone
please shed some light on what I am doing wrong in this matter?
Kind regards,
Wouter van Rooy
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 19b159b..224e01e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -131,8 +131,11 @@ do_bundle_initramfs () {
if [ -e ${KERNEL_OUTPUT} ] ; then
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.bak
fi
-
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
- kernel_do_compile
+ unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+ oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" =
"${KERNEL_IMAGETYPE}"; then
+ gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" >
"${KERNEL_OUTPUT}"
+ fi
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
# Update install area
@@ -150,20 +153,7 @@ addtask bundle_initramfs after do_install before do_deploy
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
- # The $use_alternate_initrd is only set from
- # do_bundle_initramfs() This variable is specifically for the
- # case where we are making a second pass at the kernel
- # compilation and we want to force the kernel build to use a
- # different initramfs image. The way to do that in the kernel
- # is to specify:
- # make ...args... CONFIG_INITRAMFS_SOURCE=some_other_initramfs.cpio
- if [ "$use_alternate_initrd" = "" ] && [ "${INITRAMFS_TASK}" != "" ] ;
then
- # The old style way of copying an prebuilt image and building it
- # is turned on via INTIRAMFS_TASK != ""
- copy_initramfs
-
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
- fi
- oe_runmake ${
[yocto] Yocto Header files?
Hi everyone. I would just like to know if it is possible to get the Yocto Kernel Header files? I need it to build a PCI driver but I cant seem to find a recipe or a download for it. Thanks and kind regards. Testo -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Header files?
On 16-04-15 13:00, testlaster wrote: Hi everyone. I would just like to know if it is possible to get the Yocto Kernel Header files? I need it to build a PCI driver but I cant seem to find a recipe or a download for it. Short answer: Put "inherit module" in your recipe to build the module. Example Makefile: https://github.com/topic-embedded-products/kernel-module-vdmafb/blob/master/Makefile Example bitbake (hence Yocto) recipe for an external kernel module: https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-kernel/modules/kernel-module-vdmafb.bb Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Please visit us at the Hannover Messe which will be held from 13.04.2015 till 17.04.2015, Hall 2, Stand C12, Holland High Tech House http://www.hannovermesse.de/exhibitor/topic-embedded-products/L929216?source=akl -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Badly formatted subpath for git SRC_URI deletes portions of hard drive.
Hi I was writing a bitbake recipe for a project hosted on a git-server. I applied subpath in order to limit the checkout to a specific directory. When I ran the recipe it failed in do_fetch (or do_unpack) complaining about missing files. It had deleted the entire Yocto directory and selected directories from my home-dir like ssh-keys, my dir where I keep my code, and some configuration files for Thunderbird and my terminal. Since I had no Yocto directory left I was unable to debug the recipe. After restoring everything I re-created the recipe, this time I also saved a copy of the recipe at a safe location. At the end of the path given to subpath I had added a '/' as it was not specified what the format of the path should be. I figured I would see an error if the path was wrong, and technically I did. Essentially the SRC_URI looked like this: SRC_URI = "git://git@;protocol=ssh;subpath=path/" 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. I was keeping bitbake in my home-dir both of these times. The poky version I am using is Daisy. Best regards // John Ernberg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Badly formatted subpath for git SRC_URI deletes portions of hard drive.
Hi John, On Thursday 16 April 2015 11:52:48 John Ernberg wrote: > I was writing a bitbake recipe for a project hosted on a git-server. I > applied subpath in order to limit the checkout to a specific directory. > > When I ran the recipe it failed in do_fetch (or do_unpack) complaining > about missing files. It had deleted the entire Yocto directory and > selected directories from my home-dir like ssh-keys, my dir where I keep > my code, and some configuration files for Thunderbird and my terminal. > > Since I had no Yocto directory left I was unable to debug the recipe. > > After restoring everything I re-created the recipe, this time I also > saved a copy of the recipe at a safe location. > At the end of the path given to subpath I had added a '/' as it was not > specified what the format of the path should be. I figured I would see > an error if the path was wrong, and technically I did. > Essentially the SRC_URI looked like this: > SRC_URI = "git://git@;protocol=ssh;subpath=path/" > > 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. > > I was keeping bitbake in my home-dir both of these times. > > The poky version I am using is Daisy. Very sorry about this :( Looking at the code I can see at least two problems we need to fix relating to this issue. It seems that having '/' either at the start or the end of the value was unexpected and would trigger undesirable behaviour. It may be worth noting in case it wasn't clear that when it is working correctly subpath= doesn't do a shallow clone, it still clones the full repository, it's just that you only get the specified subdirectory unpacked into the work directory after that. - Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Badly formatted subpath for git SRC_URI deletes portions of hard drive.
* Paul Eggleton [150416 14:57]:
> Hi John,
> On Thursday 16 April 2015 11:52:48 John Ernberg wrote:
> > After restoring everything I re-created the recipe, this time I also
> > saved a copy of the recipe at a safe location.
> > At the end of the path given to subpath I had added a '/' as it was not
> > specified what the format of the path should be. I figured I would see
> > an error if the path was wrong, and technically I did.
> > Essentially the SRC_URI looked like this:
> > SRC_URI = "git://git@;protocol=ssh;subpath=path/"
> > 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 '/'...
> Very sorry about this :(
Yeah, too bad...
> Looking at the code I can see at least two problems we need to fix relating
> to
> this issue. It seems that having '/' either at the start or the end of the
> value was unexpected and would trigger undesirable behaviour.
The issue with having '/' at the end ought to be solved by adding
.rstrip('/') like:
diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index 44fc271..0fd9bee 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -246,7 +246,7 @@ class Git(FetchMethod):
subdir = ud.parm.get("subpath", "")
if subdir != "":
readpathspec = ":%s" % (subdir)
-def_destsuffix = "%s/" % os.path.basename(subdir)
+def_destsuffix = "%s/" %
os.path.basename(subdir.rstrip('/'))
else:
readpathspec = ""
def_destsuffix = "git/"
---
Probably, the first issue could be solved by replacing subdir with
subdir.strip('/') on the line above that.
Though I might be missing something...
I've only looked for a moment on the patch above, which at least seems
to create correct path's when inspecting the output.
Cheers,
Anders
--
Anders Darander
ChargeStorm AB / eStorm AB
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] A simpler way to apply custom config files to an image ?
Hello,
I'm stuck on something that I would have assumed trivial and can't
managed to do and hope someone can point me to a best practice.
I want to customize various config file of an image I'm building (e.g.
network interfaces, sshd banner, hostapd, etc..).
To make this simple, I wrote my own recipe called 'custom-config' and
bundled in there all my config files. Then copying them in the on_install.
do_install () {
install -m 0755 -d ${D}${sysconfdir}
install -b -m 0644 ${WORKDIR}/udhcpd.conf ${D}${sysconfdir}
install -b -m 0644 ${WORKDIR}/hostapd.conf ${D}${sysconfdir}
}
It works great for files that are not provided by packages (e.g.
udhcpd.conf), however it does not work for files already provided by
another package (e.g. hostapd.conf). I've tried adding the backup flag
to install but this did not help.
It seems the recommended way to do this is by extending each individual
recipe with bbappend and provide an updated config file. This works
great, although quite heavy for just updating a single config file.
More over, this does not work when the config file is not in the recipe
but coming from sources archive. This is the case with hostapd.conf from
recipe hostapd.
Questions:
- Is my idea of a single 'config' recipe completely stupid ? is there
any way to make it work ? It seems the simpler approach.
- 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 ?
Thanks for your help !
Best,
Laurent
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] Initramfs not appended to kernel image
On 2015-04-16 6:23 AM, Wouter van Rooy wrote:
Hello,
For the last week or so I have been struggling to build a kernel image with an embedded
initramfs using the mechanisms provided by Poky Daisy. In local.conf I have set
INITRAMFS_IMAGE_BUNDLE to "1" and INITRAMFS_IMAGE to the name of my image
recipe. When I try to build virtual/kernel no errors are shown, but the resulting kernel
image does not contain an initramfs either.
I'm the proud owner of the bugzilla to document this process better,
so let's work through the issues and see if there's a bug, or something
that just isn't clearly described.
We are talking about the 1.6 release here .. so at least the recent changes
in kernel.bbclass processing won't be the cause of the breakage.
I have traced this issue to the passing of the $use_alternate_initrd variable
in kernel.bbclass. The run.do_bundle_initramfs log contains the following
snippets:
Lines 103..120:
do_bundle_initramfs() {
if [ ! -z "sytxg1-bootmode-image" -a x"1" = x1 ]; then
echo "Creating a kernel image with a bundled initramfs..."
copy_initramfs
if [ -e arch/powerpc/boot/uImage ] ; then
mv -f arch/powerpc/boot/uImage
arch/powerpc/boot/uImage.bak
fi
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/usr/sytxg1-bootmode-image-sytxg1.cpio
kernel_do_compile
mv -f arch/powerpc/boot/uImage
arch/powerpc/boot/uImage.initramfs
mv -f arch/powerpc/boot/uImage.bak arch/powerpc/boot/uImage
# Update install area
echo "There is kernel image bundled with initramfs:
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs"
install -m 0644
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs
/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/image/boot/uImage-initramfs-sytxg1.bin
echo
"/home/wouter/Source/Product/sytxg1-boot/tmp/work/sytxg1-oe-linux/linux-axon/3.10-9/linux-3.10.9/arch/powerpc/boot/uImage.initramfs"
fi
}
Lines 164..171:
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake uImage CC="powerpc-oe-linux-gcc " LD="powerpc-oe-linux-ld.bfd
"
if test "uImage.gz" = "uImage"; then
gzip -9c < "uImage" > "arch/powerpc/boot/uImage"
fi
}
So, it seems that although do_bundle_initramfs() sets the $use_alternate_initrd to the
correct value it is not passed in the oe_runmake call in kernel_do_compile(). Judging
from the contents of kernel.bbclass I would expect it to be appended after the
LD="..." statement. For now I have found a workaround by copying the relevant
oe_runmake call to do_bundle_initramfs(). The patch is included below.
Correct, and this definitely used to work. I can't see anything wrong by
inspection alone, but will launch some builds to see if I can confirm the
behaviour and that variable not making it down into the function call.
Bruce
I cannot imagine this is the intended way to make things work. Could anyone
please shed some light on what I am doing wrong in this matter?
Kind regards,
Wouter van Rooy
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 19b159b..224e01e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -131,8 +131,11 @@ do_bundle_initramfs () {
if [ -e ${KERNEL_OUTPUT} ] ; then
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.bak
fi
-
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
- kernel_do_compile
+ unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+ oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" =
"${KERNEL_IMAGETYPE}"; then
+ gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" >
"${KERNEL_OUTPUT}"
+ fi
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
# Update install area
@@ -150,20 +153,7 @@ addtask bundle_initramfs after do_install before do_deploy
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
- # The $use_alternate_initrd is only set from
- # do_bundle_initramfs() This variable is specifically for the
- # case where we are making a second pass at the kernel
-
Re: [yocto] Badly formatted subpath for git SRC_URI deletes portions of hard drive.
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 ;-) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to enable Auto-login
i built a yocto image with beagleboard-10-dora based on qt-x11. when i boot board every time it asks root login. i checked image.bbclass file , it have set-enable-auto-login function but it is not work. how to disable this feature? -- thanks and regards, parthiban +919790329795 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Badly formatted subpath for git SRC_URI deletes portions of hard drive.
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..
>>> def dirsplit(p):
... return os.path.dirname(p), os.path.basename(p)
...
>>> dirsplit('/usr/bin/foo')
('/usr/bin', 'foo')
>>> dirsplit('/usr/bin/')
('/usr/bin', '')
>>> dirsplit('/usr/bin')
('/usr', 'bin')
>>> dirsplit('/bin')
('/', 'bin')
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A simpler way to apply custom config files to an image ?
Hey Laurent:
Is your config recipe being built before all the recipes with the default
config files and overriding your config files?
In that case I would make anything with a config file that you want to override
a dependency of your config recipe.
What's the actual error?
-Erik
Sent from my Verizon 4G LTE Smartphone
- Reply message -
From: "Laurent Eschenauer"
To: "yocto@yoctoproject.org"
Subject: [yocto] A simpler way to apply custom config files to an image ?
Date: Thu, Apr 16, 2015 7:18 AM
Hello,
I'm stuck on something that I would have assumed trivial and can't
managed to do and hope someone can point me to a best practice.
I want to customize various config file of an image I'm building (e.g.
network interfaces, sshd banner, hostapd, etc..).
To make this simple, I wrote my own recipe called 'custom-config' and
bundled in there all my config files. Then copying them in the on_install.
do_install () {
install -m 0755 -d ${D}${sysconfdir}
install -b -m 0644 ${WORKDIR}/udhcpd.conf ${D}${sysconfdir}
install -b -m 0644 ${WORKDIR}/hostapd.conf ${D}${sysconfdir}
}
It works great for files that are not provided by packages (e.g.
udhcpd.conf), however it does not work for files already provided by
another package (e.g. hostapd.conf). I've tried adding the backup flag
to install but this did not help.
It seems the recommended way to do this is by extending each individual
recipe with bbappend and provide an updated config file. This works
great, although quite heavy for just updating a single config file.
More over, this does not work when the config file is not in the recipe
but coming from sources archive. This is the case with hostapd.conf from
recipe hostapd.
Questions:
- Is my idea of a single 'config' recipe completely stupid ? is there
any way to make it work ? It seems the simpler approach.
- 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 ?
Thanks for your help !
Best,
Laurent
Disclaimer: This message contains information that may be privileged or
confidential and is the property of AgJunction Inc and its subsidiaries. It is
intended only for the person to whom it is addressed. If you are not the
intended recipient, you are not authorized to read, print, retain, copy,
disseminate, distribute, or use this message or any part thereof. If you
receive this message in error, please notify the sender immediately and delete
all copies of this message.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A simpler way to apply custom config files to an image ?
> 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. Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Badly formatted subpath for git SRC_URI deletes portions of hard drive.
On Thursday 16 April 2015 15:11:44 Anders Darander wrote:
> * Paul Eggleton [150416 14:57]:
> > Hi John,
> >
> > On Thursday 16 April 2015 11:52:48 John Ernberg wrote:
> > > After restoring everything I re-created the recipe, this time I also
> > > saved a copy of the recipe at a safe location.
> > > At the end of the path given to subpath I had added a '/' as it was not
> > > specified what the format of the path should be. I figured I would see
> > > an error if the path was wrong, and technically I did.
> > > Essentially the SRC_URI looked like this:
> > > SRC_URI = "git://git@;protocol=ssh;subpath=path/"
> > >
> > > 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 '/'...
>
> > Very sorry about this :(
>
> Yeah, too bad...
>
> > Looking at the code I can see at least two problems we need to fix
> > relating to this issue. It seems that having '/' either at the start or
> > the end of the value was unexpected and would trigger undesirable
> > behaviour.
>
> The issue with having '/' at the end ought to be solved by adding
> .rstrip('/') like:
>
> diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
> index 44fc271..0fd9bee 100644
> --- a/bitbake/lib/bb/fetch2/git.py
> +++ b/bitbake/lib/bb/fetch2/git.py
> @@ -246,7 +246,7 @@ class Git(FetchMethod):
> subdir = ud.parm.get("subpath", "")
> if subdir != "":
> readpathspec = ":%s" % (subdir)
> -def_destsuffix = "%s/" % os.path.basename(subdir)
> +def_destsuffix = "%s/" %
> os.path.basename(subdir.rstrip('/'))
> else:
> readpathspec = ""
> def_destsuffix = "git/"
> ---
>
> Probably, the first issue could be solved by replacing subdir with
> subdir.strip('/') on the line above that.
>
> Though I might be missing something...
>
> I've only looked for a moment on the patch above, which at least seems
> to create correct path's when inspecting the output.
That looks like a reasonable solution to me, thanks.
FYI I've created the following bug to track this issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7620
I'll send a fix ASAP probably based on the above.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFC] Factory reset
Hi, Factory reset is a mechanism that is target to do a restore of rootfs image, the target is to provide reference software that helps embedded system vendors to do it easily and to be file system independent. Here is a design proposal to implement Factory reset, next describe the components, Partitioning: Need to create partition layout with an area for rootfs read-only and another with rootfs rw (day to day OS) also it need another area for Linux Recovery OS (minimal). Bootloader: Need to detect when a factory reset is needed and boots the Linux Recovery OS. Linux Recovery OS: A minimal Linux OS to perform restore fron rootfs ro area to rootfs rw area. Linux OS: A Linux OS that need to have an application to set the factory reset mode and next reboots, the application will be simple and should have a plugin system for add support of who generate the event IP, Serial, HW button, etc. All of the settings should be specified at level of user configuration. I attached a simple flow of how it works, any feedback will be appreciated? Cheers, alimon [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1593 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SRCREV Issue for custom linux kernel
On 2015-04-15 1:38 AM, Raghavendra Kakarla wrote:
Hi Bruce,
My recipe is like following:
# oe-core kernel classes to apply a subset of yocto kernel
# management to git managed kernel repositories.
#
# Warning:
#
# Building this kernel without providing a defconfig or BSP
# configuration will result in build or boot errors. This is not a
# bug.
#
# Notes:
#
# patches: patches can be merged into to the source git tree itself,
#added via the SRC_URI, or controlled via a BSP
#configuration.
#
# example configuration addition:
#SRC_URI += "file://smp.cfg"
# example patch addition:
#SRC_URI += "file://0001-linux-version-tweak.patch
# example feature addition:
#SRC_URI += "file://feature.scc"
#
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
SRC_URI =
"svn://192.168.24.190:9090/svn/trunk/code/kernels;module=linux-3.10.14;protocol=http;user=admin;pswd=Welcome123"
I don't have a SVN server with the linux kernel handy, so I wasn't able
to test this exact same configuration. But I can say a similar git
configuration to kernel.org, or to a tgz worked when I tried a test
build.
Looking through the code more .. this is simply a case that isn't common
or anticipated. The mixing of the SVN SRCREV and the linux-yocto-custom
means that the code that follows is looking to manipulate the tree as a
git repository.
Can you look at your linux source directory in the build, and see if
the SVN checkout has been converted to a git repo ?
If so, the workaround would be to set SRCREV_machine = "AUTOREV", and
that should short circuit the SRCREV validation that simply won't be
correct for a converted git tree.
Alternatively, you can also create an override to do_validate_branches
and stub out the functionality completely.
Bruce
SRC_URI += "file://defconfig"
SRC_URI += "file://arqlyn.scc \
file://arqlyn.cfg \
file://arqlyn-user-config.cfg \
file://arqlyn-user-patches.scc \
"
LINUX_VERSION ?= "3.10.14"
LINUX_VERSION_EXTENSION ?= "-custom"
SRCREV = "94"
PR = "r0"
PV = "${LINUX_VERSION}"
S = "${WORKDIR}/linux-3.10.14"
COMPATIBLE_MACHINE_arqlyn = "arqlyn"
Regards,
Raghavendra
From: Bruce Ashfield
Sent: Tuesday, April 14, 2015 5:36 PM
To: Raghavendra Kakarla; yocto@yoctoproject.org
Subject: Re: [yocto] SRCREV Issue for custom linux kernel
On 2015-04-14 6:48 AM, Raghavendra Kakarla wrote:
Hi All,
I got the an error while i am checking out the linux kernel from the SVN to
build in the YOCTO project environment.
What release is this ? master ? An older release ?
And are you seeing this same error if you have a kernel recipe
that builds from git ? i.e. one of the Yocto reference boards
with a similar SRCREV ?
The yocto kernel's expect to be able to validate the commits
and then modify the tree with additional git commands, so the
tree is either in git format, or is converted to a git format
(in the case of a tgz) .. so it could be that the SVN checkout
is preventing that conversion from happening.
Bruce
Could please help me in resolving the Issue.
Error log is:
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| NOTE: custom recipe is being built, forcing SRCREV to INVALID
| NOTE: SRCREV validation skipped for AUTOREV or empty meta branch
| fatal: ambiguous argument 'INVALID': unknown revision or path not in the
working tree.
| Use '--' to separate paths from revisions
| WARNING: exit code 128 from a shell command.
| ERROR: Function failed: do_validate_branches (log file is located at
/home/testuser/poky/build/tmp/work/dhruva-poky-linux/linux-yocto-custom/3.10.14-r0/temp/log.do_validate_branches.6852)
Thanks in advance.
Regards,
Raghavendra K.
From: yocto-boun...@yoctoproject.org on behalf of
yocto-requ...@yoctoproject.org
Sent: Tuesday, April 14, 2015 2:50 PM
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 55, Issue 46
Send yocto mailing list submissions to
yocto@yoctoproject.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org
You can reach the person managing the list at
yocto-ow...@yoctoproject.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."
Today's Topics:
1. Re: yocto Digest, Vol 53, Issue 97 (Raghavendra Kakarla)
--
Message: 1
Date: Tue, 14 Apr 2015 09:20:38 +
From: Raghavendra Kakarla
To: "yocto@yoctoproject.org"
Subject: Re: [yocto] yocto Digest, Vol 53, Issue 97
Message-ID: <1429003199394.19...@inedasystems.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
When I take kernel from the SVN I got t
Re: [yocto] SRCREV Issue for custom linux kernel
Hi Bruce,
Thank you for your reply.
I modified the do_validate_sources function in kernel_yocto.bbclasses and now
it is working.
This issue is resolved now.
I have another issue with the package building. While I am trying to build a
package which is not present in open embedded git source i got the oe_runmake
errors.
I wrote a recipe for that package by following the commands given by the yocto
project manual.
Could help me in resolving this.
Thanks in advance.
Regards,
Raghavendra K.
From: Bruce Ashfield
Sent: Friday, April 17, 2015 10:04 AM
To: Raghavendra Kakarla; yocto@yoctoproject.org
Subject: Re: [yocto] SRCREV Issue for custom linux kernel
On 2015-04-15 1:38 AM, Raghavendra Kakarla wrote:
> Hi Bruce,
>
> My recipe is like following:
>
>
> # oe-core kernel classes to apply a subset of yocto kernel
> # management to git managed kernel repositories.
> #
> # Warning:
> #
> # Building this kernel without providing a defconfig or BSP
> # configuration will result in build or boot errors. This is not a
> # bug.
> #
> # Notes:
> #
> # patches: patches can be merged into to the source git tree itself,
> #added via the SRC_URI, or controlled via a BSP
> #configuration.
> #
> # example configuration addition:
> #SRC_URI += "file://smp.cfg"
> # example patch addition:
> #SRC_URI += "file://0001-linux-version-tweak.patch
> # example feature addition:
> #SRC_URI += "file://feature.scc"
> #
>
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> SRC_URI =
> "svn://192.168.24.190:9090/svn/trunk/code/kernels;module=linux-3.10.14;protocol=http;user=admin;pswd=Welcome123"
I don't have a SVN server with the linux kernel handy, so I wasn't able
to test this exact same configuration. But I can say a similar git
configuration to kernel.org, or to a tgz worked when I tried a test
build.
Looking through the code more .. this is simply a case that isn't common
or anticipated. The mixing of the SVN SRCREV and the linux-yocto-custom
means that the code that follows is looking to manipulate the tree as a
git repository.
Can you look at your linux source directory in the build, and see if
the SVN checkout has been converted to a git repo ?
If so, the workaround would be to set SRCREV_machine = "AUTOREV", and
that should short circuit the SRCREV validation that simply won't be
correct for a converted git tree.
Alternatively, you can also create an override to do_validate_branches
and stub out the functionality completely.
Bruce
> SRC_URI += "file://defconfig"
>
> SRC_URI += "file://arqlyn.scc \
> file://arqlyn.cfg \
> file://arqlyn-user-config.cfg \
> file://arqlyn-user-patches.scc \
> "
>
>
> LINUX_VERSION ?= "3.10.14"
> LINUX_VERSION_EXTENSION ?= "-custom"
> SRCREV = "94"
> PR = "r0"
> PV = "${LINUX_VERSION}"
> S = "${WORKDIR}/linux-3.10.14"
> COMPATIBLE_MACHINE_arqlyn = "arqlyn"
>
>
> Regards,
>
> Raghavendra
>
>
> From: Bruce Ashfield
> Sent: Tuesday, April 14, 2015 5:36 PM
> To: Raghavendra Kakarla; yocto@yoctoproject.org
> Subject: Re: [yocto] SRCREV Issue for custom linux kernel
>
> On 2015-04-14 6:48 AM, Raghavendra Kakarla wrote:
>> Hi All,
>>
>> I got the an error while i am checking out the linux kernel from the SVN to
>> build in the YOCTO project environment.
>>
>
> What release is this ? master ? An older release ?
>
> And are you seeing this same error if you have a kernel recipe
> that builds from git ? i.e. one of the Yocto reference boards
> with a similar SRCREV ?
>
> The yocto kernel's expect to be able to validate the commits
> and then modify the tree with additional git commands, so the
> tree is either in git format, or is converted to a git format
> (in the case of a tgz) .. so it could be that the SVN checkout
> is preventing that conversion from happening.
>
> Bruce
>
>> Could please help me in resolving the Issue.
>>
>>
>> Error log is:
>> Log data follows:
>> | DEBUG: Executing shell function do_validate_branches
>> | NOTE: custom recipe is being built, forcing SRCREV to INVALID
>> | NOTE: SRCREV validation skipped for AUTOREV or empty meta branch
>> | fatal: ambiguous argument 'INVALID': unknown revision or path not in the
>> working tree.
>> | Use '--' to separate paths from revisions
>> | WARNING: exit code 128 from a shell command.
>> | ERROR: Function failed: do_validate_branches (log file is located at
>> /home/testuser/poky/build/tmp/work/dhruva-poky-linux/linux-yocto-custom/3.10.14-r0/temp/log.do_validate_branches.6852)
>>
>>
>> Thanks in advance.
>>
>> Regards,
>>
>> Raghavendra K.
>>
>> From: yocto-boun...@yoctoproject.org on
>> behalf of yocto-requ...@yoctoproject.org
>> Sent: Tuesday, April 14, 2015 2:50 PM
>> To: yocto@yoctoproject.org
>> Subject: yocto Digest, Vol 55, Issue 46
>>
>> Send yocto
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. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ld: cannot find crti.o: No such file or directory
Hi, all
I use the 1.8 YP to build the ccgi, the receip of ccgi as this:
SUMMARY = "Add ccgi lib to rootfs"
HOMEPAGE = "http://sourceforge.net/projects/libccgi/?source=typ_redirect";
LICENSE = "GPLv2"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
FILES_${PN}_dev = "${libdir}/* ${includedir}/* "
SRC_URI = "file://${PN}-${PV}.tgz \
file://0001-modify-the-source-code-to-match-the-G4-code.patch \
"
S = "${WORKDIR}/${PN}-${PV}"
PARALLEL_MAKEINST="prefix=${D}/usr"
EXTRA_OEMAKE = 'CROSS=${HOST_PREFIX}'
do_compile() {
oe_runmake
OPENSSL_INCLUDE=${TOPDIR}/tmp/sysroots/${MACHINE}/usr/include
}
It appears the error as follows:
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find crti.o: No such file or directory
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find crtbeginS.o: No such file or directory
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find -lgcc
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find -lgcc_s
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find -lpthread
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find -lc
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find -lgcc
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find -lgcc_s
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find crtendS.o: No such file or directory
|
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld:
cannot find crtn.o: No such file or directory
In fact , I can find the crti.o in
/home/ectrs/poky/coretexa8/tmp/sysroots/i686-linux/usr/ directory.
How to resolve this problem? If you know ,please tell me .
Thanks
Neil
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [auh][PATCH] gitrecipe/rename: avoid renaming incorrect files
From: Jackie Huang
Previously f.find('pn') will not only match 'pn' but also packages
that have 'pn' in their names, for example 'python-glance' will
match 'python-glance', 'python-glanceclient' and 'python-glancestore',
so the later two packages will be incorrectly changed.
Get the exact package name to compare with pn to void this issue.
Signed-off-by: Jackie Huang
---
gitrecipe.py | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/gitrecipe.py b/gitrecipe.py
index dfa5cd2..706483b 100644
--- a/gitrecipe.py
+++ b/gitrecipe.py
@@ -66,10 +66,14 @@ class GitRecipe(Recipe):
for f in os.listdir(self.recipe_dir):
full_path_f = os.path.join(self.recipe_dir, f)
-if os.path.isfile(full_path_f) and \
-((f.find(self.env['PN']) == 0 and (f.find(old_git_tag) !=
-1 or
- f.find("git") != -1) and f.find(".bb") != -1) or
- (f.find(self.env['PN']) == 0 and f.find(".inc") != -1)):
+
+# We only care about files like pn_[pv|git].
+fname, fext = os.path.splitext(f)
+if os.path.isfile(full_path_f) and (fext == ".bb" or fext ==
".inc"):
+f = fname.split("_")
+if f[0] != self.env['PN'] or (len(f) == 2 and f[1] !=
old_git_tag and f[1] != "git"):
+continue
+
with open(full_path_f + ".tmp", "w+") as temp_recipe:
with open(full_path_f) as recipe:
for line in recipe:
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
