Re: [yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend
On Wed, 25 Feb 2015, Joe MacDonald wrote:
> [[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend] On
> 15.02.25 (Wed 03:54) Robert P. J. Day wrote:
>
> >
> > minor quibble about kernel dev manual -- section 2.2.1, "creating
> > the append file", uses the example of:
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >
> > while section 2.2.3 uses:
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >
> > both sections kind of implying that that's the way to do it, without
> > making it clear that *either* way works as long as the variable
> > prepend matches up with the directory name.
> >
> > both ways are correct, of course, but the wording is a bit
> > confusing.
>
> It's probably worth changing the latter reference to match the
> former. Both work but with any new recipes (at least in the layers I
> maintain) the preference is to use the former for clarity as well as
> faster lookups.
sort of related to this, but in a *regular* recipe (not a bbappend),
the default FILESPATH is set in base.bbclass:
FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
so that, by default, a regular recipe will look for SRC_URI entries in
*all* of:
1) ${BP}/
2) ${BPN}/
3) "files/"
it's not clear which is the preferred standard (not sure there even
*is* a preferred standard), but in cases where more than one of the
above exists, all of the relevant directories will be searched, but
it's not clear why some recipes insist on breaking up the files over
more than one directory.
in the case of subversion, i can see the logic:
subversion/
subversion_1.6.15.bb
subversion-1.8.11/
subversion_1.8.11.bb
so that the generic "subversion/" directory will apply to *all*
subversion recipes, but there is also the version-specific
"subversion-1.8.11/", so that's fine.
busybox, though:
busybox/
busybox_1.23.1.bb
busybox_git.bb
busybox.inc
files/
won't both directories busybox/ and files/ always be consulted for
SRC_URI entries, regardless of the version of busybox? so what is the
rationale for breaking those files over two directories?
and i'm curious ... is there any recipe that contains all *three*
types of SRC_URI subdirectories?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend
On Thu, 26 Feb 2015, Robert P. J. Day wrote:
... snip ...
> sort of related to this, but in a *regular* recipe (not a bbappend),
> the default FILESPATH is set in base.bbclass:
>
> FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
> "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
>
> so that, by default, a regular recipe will look for SRC_URI entries in
> *all* of:
>
> 1) ${BP}/
> 2) ${BPN}/
> 3) "files/"
>
> it's not clear which is the preferred standard (not sure there even
> *is* a preferred standard), but in cases where more than one of the
> above exists, all of the relevant directories will be searched, but
> it's not clear why some recipes insist on breaking up the files over
> more than one directory.
>
> in the case of subversion, i can see the logic:
>
> subversion/
> subversion_1.6.15.bb
> subversion-1.8.11/
> subversion_1.8.11.bb
>
> so that the generic "subversion/" directory will apply to *all*
> subversion recipes, but there is also the version-specific
> "subversion-1.8.11/", so that's fine.
>
> busybox, though:
>
> busybox/
> busybox_1.23.1.bb
> busybox_git.bb
> busybox.inc
> files/
>
> won't both directories busybox/ and files/ always be consulted for
> SRC_URI entries, regardless of the version of busybox? so what is the
> rationale for breaking those files over two directories?
>
> and i'm curious ... is there any recipe that contains all *three*
> types of SRC_URI subdirectories?
just to follow up on this, as a demo of how to add a directory of
SRC_URI files to a basic recipe, i want to show a variety of
possibilities, from simple to complex.
in the simplest case, there will be a single directory, which will
be named one of BP, BPN, or "files", all of which are equally valid --
lots of examples of this.
slightly more complex -- a multi-version recipe directory with each
recipe version having its own version-specific directory, like
coreutils:
coreutils-6.9/
coreutils_6.9.bb
coreutils-8.23/
coreutils_8.23.bb
more complicated -- recipes with *both* version-specific and generic
directories like, say, readline:
files/
readline-5.2/
readline_5.2.bb
readline-6.3/
readline_6.3.bb
readline.inc
etc, etc. when this is explained in the appropriate YP manual, is it
clear the variety you can have?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend
On Thursday 26 February 2015 04:12:33 Robert P. J. Day wrote:
> On Wed, 25 Feb 2015, Joe MacDonald wrote:
> > [[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend] On
15.02.25 (Wed 03:54) Robert P. J. Day wrote:
> > > minor quibble about kernel dev manual -- section 2.2.1, "creating
> > >
> > > the append file", uses the example of:
> > > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > >
> > > while section 2.2.3 uses:
> > > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> > >
> > > both sections kind of implying that that's the way to do it, without
> > > making it clear that *either* way works as long as the variable
> > > prepend matches up with the directory name.
> > >
> > > both ways are correct, of course, but the wording is a bit
> > >
> > > confusing.
> >
> > It's probably worth changing the latter reference to match the
> > former. Both work but with any new recipes (at least in the layers I
> > maintain) the preference is to use the former for clarity as well as
> > faster lookups.
>
> sort of related to this, but in a *regular* recipe (not a bbappend),
> the default FILESPATH is set in base.bbclass:
>
> FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
> "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
>
> so that, by default, a regular recipe will look for SRC_URI entries in
> *all* of:
>
> 1) ${BP}/
> 2) ${BPN}/
> 3) "files/"
>
> it's not clear which is the preferred standard (not sure there even
> *is* a preferred standard), but in cases where more than one of the
> above exists, all of the relevant directories will be searched, but
> it's not clear why some recipes insist on breaking up the files over
> more than one directory.
>
> in the case of subversion, i can see the logic:
>
> subversion/
> subversion_1.6.15.bb
> subversion-1.8.11/
> subversion_1.8.11.bb
>
> so that the generic "subversion/" directory will apply to *all*
> subversion recipes, but there is also the version-specific
> "subversion-1.8.11/", so that's fine.
>
> busybox, though:
>
> busybox/
> busybox_1.23.1.bb
> busybox_git.bb
> busybox.inc
> files/
>
> won't both directories busybox/ and files/ always be consulted for
> SRC_URI entries, regardless of the version of busybox? so what is the
> rationale for breaking those files over two directories?
>
> and i'm curious ... is there any recipe that contains all *three*
> types of SRC_URI subdirectories?
Our policy in OE-Core (and the layers under meta-openembedded) is to move away
from files/ to ${BPN} for a bit of consistency - if you use ${BPN} it then
doesn't matter if you have more than one recipe in a directory, the files for
each recipe are still kept separate instead of a files/ directory with a
mixture of files for different recipes. ${BP} would only be used for patches
that are specific to a version where multiple versioned recipes are being
provided, leading to multiple versions of the same files needing to be present.
We have been doing the "conversion" on a piecemeal basis on recipe upgrade
however so that's why you will see files/ still in various places. To avoid
undue churn I don't think it would be worth doing a mass rename, and it's also
unlikely that we will be taking away the ability to use files/ by default, so
other layers are free to do as they wish.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipe reporting system Announcement
On 25 February 2015 at 23:45, Aníbal Limón wrote: > I'm glad to announce the available of the Recipe reporting system (a.k.a, > RRS) [1]. > Woohoo! \o/ Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipe reporting system Announcement
On Wednesday 25 February 2015 17:45:48 Aníbal Limón wrote: > I'm glad to announce the available of the Recipe reporting system > (a.k.a, RRS) [1]. > > The RRS publish the status of Recipes for Openembedded-core (meta) > layer, the status means: > who maintains the Recipe?, what other Linux distribution contains the > Package, list of upgrades > of a Recipe, upstream version of the Recipe and Milestone statics about > package upgrades, details [2]. > > > The RRS design specification can be found at Bugzilla [3] and the source > code is available [4]. > > Special mention to, > Belen Barros Pena for did the design of the RRS [3]. > Saul Wold for supporting the development direction. > Michael Halstead for help in production setup. > Paul Eggleton for make the Layerindex app that servers as base of RRS. > > Contact me for any issue. > > Best regards, > alimon > > [1] http://packages.yoctoproject.org/ > [2] http://packages.yoctoproject.org/rrs/about/ > [3] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6273 > [4] > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=alimon/RRS Great work Aníbal, and thanks! Just to clear up any confusion, at the moment this is effectively a fork of the OE layer index code, and I still have the task to try to help get the RRS changes merged into the OE layer index master branch, which I fully intend to do. Unfortunately I haven't had a chance to do that yet but luckily the code for the OE layer index isn't changing very much at all at the moment, so the two codebases are unlikely to diverge much while we are waiting for that to be done. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Question] How to walkaround this build warning
Hi folks I built my image and got the following warning message in do_rootfs. -- Output from gdk-pixbuf-loader-png-2.30.8-r0@core2_64: sed: warning: failed to get security context of /yocto/build/x86_64/tmp/work//intercept_scripts/update_pixbuf_cache: No data available Output from gdk-pixbuf-loader-gif-2.30.8-r0@core2_64: sed: warning: failed to get security context of /yocto/build/x86_64/tmp/work//intercept_scripts /update_pixbuf_cache: No data available -- My poky is 1.7.1 as below -- DISTRO = "poky" DISTRO_NAME = "Poky (Yocto Project Reference Distro)" DISTRO_VERSION = "1.7.1" DISTRO_CODENAME = "dizzy" - Any suggestion, thanks. Cheers Bian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipe reporting system Announcement
very nice. thanks to all. - armin On 02/25/2015 03:45 PM, Aníbal Limón wrote: Hi All, I'm glad to announce the available of the Recipe reporting system (a.k.a, RRS) [1]. The RRS publish the status of Recipes for Openembedded-core (meta) layer, the status means: who maintains the Recipe?, what other Linux distribution contains the Package, list of upgrades of a Recipe, upstream version of the Recipe and Milestone statics about package upgrades, details [2]. The RRS design specification can be found at Bugzilla [3] and the source code is available [4]. Special mention to, Belen Barros Pena for did the design of the RRS [3]. Saul Wold for supporting the development direction. Michael Halstead for help in production setup. Paul Eggleton for make the Layerindex app that servers as base of RRS. Contact me for any issue. Best regards, alimon [1] http://packages.yoctoproject.org/ [2] http://packages.yoctoproject.org/rrs/about/ [3] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6273 [4] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=alimon/RRS -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bitbake: fetch2: Revalidate checksums, YOCTO #5571
Hi, On Mon, Feb 23, 2015 at 03:22:43PM +0100, Clemens Lang wrote: > [YOCTO #5571] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=5571 Can somebody review this? Is there anything I need to do to get this considered for merging? -- Clemens Lang • Development Specialist BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com - BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Reinhard Stolle Sitz und Registergericht: München HRB 134810 - -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend
On Thu, 26 Feb 2015, Paul Eggleton wrote:
> Our policy in OE-Core (and the layers under meta-openembedded) is to
> move away from files/ to ${BPN} for a bit of consistency - if you
> use ${BPN} it then doesn't matter if you have more than one recipe
> in a directory, the files for each recipe are still kept separate
> instead of a files/ directory with a mixture of files for different
> recipes. ${BP} would only be used for patches that are specific to a
> version where multiple versioned recipes are being provided, leading
> to multiple versions of the same files needing to be present.
ok, so ... ${BPN} for single-recipe directories *or* common files
across multi-version recipes, and ${BP} for version-specific stuff?
that's the way i'm reading that. that's good, it's the sort of thing
that would be good in a "style guide."
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bitbake: fetch2: Revalidate checksums, YOCTO #5571
Hi Clemens,
On 23/02/15 08:22, Clemens Lang wrote:
This is the problem I see, I am not sure we want to import extra
libraries here, as you state the use of pickle might be ok since it
avoids the overhead of calculating the checksums each time, but I don't
know if it is actually worth it, since checksums are calculated fairly
quick anyway, this is my personal opinion, you may still submit it for
review.
+try:
+import cPickle as pickle
+except ImportError:
+import pickle
+logger.info("Importing cPickle failed. "
+"Falling back to a very slow implementation.")
+
On 26/02/15 08:42, Clemens Lang wrote:
Hi,
On Mon, Feb 23, 2015 at 03:22:43PM +0100, Clemens Lang wrote:
[YOCTO #5571] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=5571
Can somebody review this? Is there anything I need to do to get this
considered for merging?
And perhaps the reason it hasn't been reviewed is that I believe this
patch should go to bitbake-de...@lists.openembedded.org instead.
I also had this WIP branch on contrib, its from a couple of months back
its "dirty" but in case you'd like to look around.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=hsalejandro/5571&id=2f59e26e534dc6b6d4c5bb8d78c574042e0fe7a7
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-1.8_M3.rc2 now available.
-e A release candidate build for yocto-1.8_M3.rc2 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.8_M3.rc2 Please begin QA on this build as soon as possible. Build hash information: meta-intel : 367fd4758d23318b3adab8021d7bdc8b56e04917 meta-fsl-arm : c5dde2d3e1c89e11b9a4920ca328648664457b7c meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568 meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 meta-fsl-ppc : 5eeeb3ad74b72d904f805bc6e248e93e722b45c4 poky : 6d7cf8e9dd00bdff882311fecbadfadc46e9cc03 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
[yocto] Native version conflict with yocto version
i run yocto build on opensuse 12.3 which have version of make is 4.0 but my yocto project has version of 3.82.so it shows "checking version of make... 4.0, bad". and other error logs are: ERROR: Function failed: do_configure (log file is located at /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc-initial/2.18-r0/temp/log.do_configure.9059) ERROR: Logfile of failure stored in: /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc-initial/2.18-r0/temp/log.do_configure.9059 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common'] | DEBUG: Executing shell function autotools_preconfigure | DEBUG: Shell function autotools_preconfigure finished | DEBUG: Executing shell function do_configure | checking build system type... x86_64-pc-linux-gnu | checking host system type... arm-poky-linux-gnueabi | checking for arm-poky-linux-gnueabi-gcc... arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon --sysroot=/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/beagleboard | checking for suffix of object files... o | checking whether we are using the GNU C compiler... yes | checking whether arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon --sysroot=/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/beagleboard accepts -g... yes | checking for gcc... gcc | checking whether we are using the GNU C++ compiler... no | checking whether arm-poky-linux-gnueabi-g++ -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon --sysroot=/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/beagleboard accepts -g... no | checking for arm-poky-linux-gnueabi-readelf... arm-poky-linux-gnueabi-readelf | checking for sysdeps preconfigure fragments... x86_64 | configure: running configure fragment for add-on libidn | configure: running configure fragment for add-on nptl | checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm configure: Found compiler is configured for armv7 | hppa ia64 m68k microblaze mips powerpc tile | checking for assembler and linker STT_GNU_IFUNC support... yes | checking whether .text pseudo-op must be used... yes | checking sysdep dirs... ports/sysdeps/unix/sysv/linux/arm/nptl ports/sysdeps/unix/sysv/linux/arm nptl/sysdeps/unix/sysv/linux nptl/sysdeps/pthread sysdeps/pthread ports/sysdeps/unix/sysv/linux sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/inet nptl/sysdeps/unix/sysv ports/sysdeps/unix/sysv sysdeps/unix/sysv ports/sysdeps/unix/arm nptl/sysdeps/unix ports/sysdeps/unix sysdeps/unix sysdeps/posix ports/sysdeps/arm/armv7/multiarch ports/sysdeps/arm/armv7 ports/sysdeps/arm/armv6t2 ports/sysdeps/arm/armv6 ports/sysdeps/arm/nptl ports/sysdeps/arm ports/sysdeps/arm/soft-fp sysdeps/wordsize-32 sysdeps/ieee754/flt-32 sysdeps/ieee754/dbl-64 sysdeps/ieee754 sysdeps/generic | checking for a BSD-compatible install... /usr/bin/install -c | checking whether ln -s works... yes | checking whether /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi.gcc-cross-initial/gcc/arm-poky-linux-gnueabi/4.8.1/as is GNU as... yes | checking whether /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi.gcc-cross-initial/gcc/arm-poky-linux-gnueabi/4.8.1/ld is GNU ld... yes | checking for /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi.gcc-cross-initial/gcc/arm-poky-linux-gnueabi/4.8.1/as... /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi.gcc-cross-initial/gcc/arm-poky-linux-gnueabi/4.8.1/as | checking version of /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi.gcc-cross-initial/gcc/arm-poky-linux-gnueabi/4.8.1/as... 2.23.2, ok | checking for /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi.gcc-cross-initial/gcc/arm-poky-linux-gnueabi/4.8.1/ld... /home/parthiban/UliveSytems/Parthiban/CODE/OpenSourc
