[yocto] Trying to add new recipe - getting QA error I don't understand
Hi,
I'm new to Yocto, so please let me know if this is the wrong list for questions
like this.
I'm trying to add a recipe for a new cmake project (for UCI). The
do_package_qa task reports this problem:
ERROR: QA Issue: uci rdepends on uci-dev
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
uci-dev appears to be automatically generated package - there is no recipe for
it, and I can't find any reference to it in the actual source code for the
package. In other words, it appears as if Yocto itself is generating this
dependency somehow.
Does this sound right? Can anyone point me in the right direction?
My recipe is pretty simple and looks like this:
===
DESCRIPTION = "UCI Configuration Library"
SECTION = "openwrtlib"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://uci.h;beginline=1;endline=13;md5=799502a8112fe590aa1664829bfc7c60"
PV = "2011-07-18.3"
#see https://forum.openwrt.org/viewtopic.php?id=15243 for git
SRC_URI = "file://uci-${PV}.tar.gz"
EXTRA_OECMAKE="-DBUILD_LUA=OFF"
inherit cmake
===
Thanks for any help,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to add new recipe - getting QA error I don't understand
Hi Ross,
Thanks for your reply.
First, it appears you are correct that UCI is not following the normal pattern.
Here is the image for the package:
.
└── usr
├── bin
│ ├── uci
│ └── uci-static
├── include
│ ├── uci_config.h
│ ├── uci.h
│ └── ucimap.h
└── lib
├── libuci.a
└── libuci.so
So, I added this:
FILES_${PN} +="/usr/lib/*"
However that doesn't remove the message. Did I do it right?
Also, in the error message "uci depends on uci-dev" does "uci" refers to the
package name or the executable name?
I wasn't able to remove PV, it ran into a different build break since the
tar.gz emits the source folder with that name. I'm using the tar.gz to make
sure I'm building the same source as the project for my old board. That
project used a variant of build root, but we're trying to move to Yocto because
it seems to have a better supported future. IOW, using the tar ball is a way
to change only one thing at a time until the rest of the build is happy.
Thanks again,
Brad
On Jul 31, 2013, at 11:45 AM, "Burton, Ross"
mailto:ross.bur...@intel.com>> wrote:
Hi Brad,
On 31 July 2013 18:52, Brad Litterell mailto:br...@taser.com>>
wrote:
I'm new to Yocto, so please let me know if this is the wrong list for
questions like this.
You've got the right list for support question.
I'm trying to add a recipe for a new cmake project (for UCI). The
do_package_qa task reports this problem:
ERROR: QA Issue: uci rdepends on uci-dev
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
uci-dev appears to be automatically generated package - there is no recipe
for it, and I can't find any reference to it in the actual source code for
the package. In other words, it appears as if Yocto itself is generating
this dependency somehow.
Correct, oe-core will generate a -dev package by default that contains
(typically) /usr/include and /usr/lib/lib*.so.
This warning indicates that the automatic library dependency
generation added a dependency from uci to uci-dev. It sounds like
that UCI isn't installing versioned libraries (so eg
/usr/lib/libuci.so is the full library, not a symlink) and the main
uci package is shipping a binary that links to it.
If that's the case then basically UCI is doing shared libraries badly,
and you'll have to tweak the packaging. Adding to FILES_${PN} to
include all of /usr/lib should put all the libraries into "uci".
PV = "2011-07-18.3"
I think hyphen in PV isn't recommended, but you can avoid setting this
if you embed the version in the filename.
#see https://forum.openwrt.org/viewtopic.php?id=15243 for git
SRC_URI = "file://uci-${PV}.tar.gz"
I presume you have a reason to have a local snapshot of the repo and
are not using a git URI in SRC_URI directly?
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to add new recipe - getting QA error I don't understand
Hi,
I tried
FILES_${PN} =+ "${libdir}/libuci.so"
but under package-split, the .so file is still only listed in the -dev package.
Is it possible that the lib*.so files are always forcibly removed from
FILES_${PN}?
I was able to hack the CMakeList.txt file as follows. If I set SOVERSION on
the shared library the expected libuci.so.1 file appears with the libuci.so
link which solves the problem. I'm a little concerned I might have problems
with other packages that I haven't ported yet that depend on UCI, but I will
see.
may be you should file an enhancement bug for it in Yocto bugzilla
I probably should have mentioned this earlier, but I'm using the 1.3 version of
Yocto that's embedded in TI's Arago SDK. Can I safely pull poky on top of that
and see if it fixes the problem or might I have conflicts between Arago BSP
layers and the 1.4 Poky recipes?
Thanks,
Brad
On Jul 31, 2013, at 3:58 PM, Khem Raj
mailto:raj.k...@gmail.com>> wrote:
On Jul 31, 2013, at 3:39 PM, Brad Litterell
mailto:br...@taser.com>> wrote:
└── lib
├── libuci.a
└── libuci.so
So, I added this:
FILES_${PN} +="/usr/lib/*"
Try something like
FILES_${PN} =+ "${libdir}/libuci.so"
However that doesn't remove the message. Did I do it right?
usually .so are symlinks which then go into -dev packages via the default
package sieve engine
but I am thinking if we find out that file is not a symlink but a normal shared
object then probably
we could stop shoving it into -dev package and instead put it into ${PN}
may be you should file an enhancement bug for it in Yocto bugzilla
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to add new recipe - getting QA error I don't understand
On Jul 31, 2013, at 9:35 PM, Khem Raj
mailto:raj.k...@gmail.com>> wrote:
On Jul 31, 2013, at 5:52 PM, Brad Litterell
mailto:br...@taser.com>> wrote:
Hi,
I tried
FILES_${PN} =+ "${libdir}/libuci.so"
but under package-split, the .so file is still only listed in the -dev package.
Is it possible that the lib*.so files are always forcibly removed from
FILES_${PN}?
what is name of your recipe ?
uci.bb
I was able to hack the CMakeList.txt file as follows. If I set SOVERSION on
the shared library the expected libuci.so.1 file appears with the libuci.so
link which solves the problem. I'm a little concerned I might have problems
with other packages that I haven't ported yet that depend on UCI, but I will
see.
thats intact correct way to fix it in view of OE's eyes.
may be you should file an enhancement bug for it in Yocto bugzilla
I probably should have mentioned this earlier, but I'm using the 1.3 version of
Yocto that's embedded in TI's Arago SDK. Can I safely pull poky on top of that
and see if it fixes the problem or might I have conflicts between Arago BSP
layers and the 1.4 Poky recipes?
Doubt that
Doubting that I can use Poky, or doubting that Poky will conflict with TI's
arago? Or doubting that using 1.3 has any relevance to this issue?
Thanks,
Brad
On Jul 31, 2013, at 3:58 PM, Khem Raj
mailto:raj.k...@gmail.com>> wrote:
On Jul 31, 2013, at 3:39 PM, Brad Litterell
mailto:br...@taser.com>> wrote:
└── lib
├── libuci.a
└── libuci.so
So, I added this:
FILES_${PN} +="/usr/lib/*"
Try something like
FILES_${PN} =+ "${libdir}/libuci.so"
However that doesn't remove the message. Did I do it right?
usually .so are symlinks which then go into -dev packages via the default
package sieve engine
but I am thinking if we find out that file is not a symlink but a normal shared
object then probably
we could stop shoving it into -dev package and instead put it into ${PN}
may be you should file an enhancement bug for it in Yocto bugzilla
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Is there a recipe class that simply installs files to the target?
I have some scripts I'd like to copy to the target to a simple folder, e.g.
/lib/foo
Ideally I'd like to just create a simple recipe something like this:
SRC_URI = "file://lib/foo/foo.sh"
inherit install_only
Is there a class like this?
It seems like most recipes of this form accomplish this by a custom do_install
step, such as this:
do_install() {
install -D -m 755 ${S}/lib/foo/foo.sh ${D}/lib/foo
}
and I was just hoping there might be a base class for examining the input files
and generating the install steps?
Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is there a recipe class that simply installs files to the target?
Ok, thanks - mainly wanted to make sure I was following a best practice of
sorts.
On Aug 13, 2013, at 5:39 PM, Khem Raj
mailto:raj.k...@gmail.com>> wrote:
On Aug 13, 2013, at 5:15 PM, Brad Litterell
mailto:br...@taser.com>> wrote:
I have some scripts I'd like to copy to the target to a simple folder, e.g.
/lib/foo
Ideally I'd like to just create a simple recipe something like this:
SRC_URI = "file://lib/foo/foo.sh"
inherit install_only
Is there a class like this?
It seems like most recipes of this form accomplish this by a custom do_install
step, such as this:
do_install() {
install -D -m 755 ${S}/lib/foo/foo.sh ${D}/lib/foo
}
and I was just hoping there might be a base class for examining the input files
and generating the install steps?
there isn't one. Its not as common a case to abstract out into a class
additionally when you have such recipes then
the install paths aren't standard either so adding do_install to recipe and
doing it there is OK
Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] What are _virtual providers? and other Suffixes?
I searched the Yocto Mega Manual, but am still somewhat mystified by the suffix formatting of various variable - especially virtual ones like this: PREFERRED_PROVIDER_virtual/gettext = "gettext" PREFERRED_PROVIDER_virtual/kernel_am335x-evm = "linux-ti-staging" PREFERRED_PROVIDER_virtual/bootloader_am335x-evm = "u-boot-ti-staging" Also, there seems to be some sort of prioritization going on with the multiple levels underscore characters in places like this: # Set the PREFERRED_PROVIDER for jpeg functionality based on the MACHINE # architecture. For armv7a devices libjpeg-turbo should be used to take # advantage of the SIMD instructions. PREFERRED_PROVIDER_jpeg = "libjpeg-turbo" PREFERRED_PROVIDER_jpeg_armv5te = "jpeg" (all examples from the arago project in arago-prefs.inc) Is there a succinct way of viewing these suffixes that will allow me to wrap my head around their various & myriad versions? Am I right in assuming the "variable name" consists of the uppercase parse (regardless of number of underscores)? Thanks, Brad ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What are _virtual providers? and other Suffixes?
Hi Paul,
Thanks for taking the time to explain, very enlightening. I think I understood
it, please allow me to play back my understanding:
1. _virtual is part of the variable name, and is not a special type of
override.
2. PREFERRED_PROVIDER_virtual/kernel_am335x-evm breaks into:
"PREFERRED_PROVIDER_virtual/kernel" with an override condition of "am335x-evm"
3. So for the jpeg case:
>> PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"
>>
>> PREFERRED_PROVIDER_jpeg_armv5te = "jpeg"
Could this have also been _virtual/jpeg? It's just that some components use
the _virtual convention and others don't?
Do I have it right?
Thanks,
Brad
On Aug 20, 2013, at 3:27 PM, Paul Eggleton
wrote:
> Hi Brad,
>
> On Monday 19 August 2013 22:51:04 Brad Litterell wrote:
>> I searched the Yocto Mega Manual, but am still somewhat mystified by the
>> suffix formatting of various variable - especially virtual ones like this:
>>
>>
>> PREFERRED_PROVIDER_virtual/gettext = "gettext"
>>
>> PREFERRED_PROVIDER_virtual/kernel_am335x-evm = "linux-ti-staging"
>>
>> PREFERRED_PROVIDER_virtual/bootloader_am335x-evm = "u-boot-ti-staging"
>
> These are setting PREFERRED_PROVIDER for a number of targets. "virtual/xyz" is
> a convention we use where there are multiple providers for a particular
> component, so a recipe that requires that component can have virtual/xyz in
> its DEPENDS, each provider declares virtual/xyz in its PROVIDES, and then in
> configuration the desired recipe to provide that can be selected via
> PREFERRED_PROVIDER_virtual/xyz = "...".
>
> The second two examples have an additional override which makes them only
> applicable for a specific machine (am335x-evm). If you want to know how this
> mechanism works have a look at this:
>
> http://docs.openembedded.org/bitbake/html/ch02.html#id439023
>
> (We're in the process of updating the BitBake manual, so this old version
> will have to suffice.)
>
>> Also, there seems to be some sort of prioritization going on with the
>> multiple levels underscore characters in places like this:
>>
>>
>> # Set the PREFERRED_PROVIDER for jpeg functionality based on the MACHINE
>>
>> # architecture. For armv7a devices libjpeg-turbo should be used to take
>>
>> # advantage of the SIMD instructions.
>>
>> PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"
>>
>> PREFERRED_PROVIDER_jpeg_armv5te = "jpeg"
>>
>>
>> (all examples from the arago project in arago-prefs.inc)
>>
>> Is there a succinct way of viewing these suffixes that will allow me to wrap
>> my head around their various & myriad versions?
>
> OVERRIDES is listed in order so that overrides for the later items are
> preferred. If you run bitbake -e | less and search for OVERRIDES (with the /
> key) you can see what the value is for the global environment; here is an
> example for my current configuration:
>
> # $OVERRIDES [3 operations]
> # set conf/bitbake.conf:670
> #
> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
> # set conf/bitbake.conf:671
> # [vardepsexclude] "MACHINEOVERRIDES"
> # postdot /home/paul/poky/poky/meta/conf/distro/include/tclibc-eglibc.inc:9
> # "${LIBCOVERRIDE}"
> # computed:
> #
> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable${LIBCOVERRIDE}"
> OVERRIDES="linux:i586:build-linux:pn-bblayers:x86:qemuall:qemux86:poky:class-target:forcevariable:libc-glibc"
>
> Putting the values of all these variables into OVERRIDES gives us a way of
> setting variable values per-machine, per-architecture etc. Based on the
> above value, if I had:
>
> SOMEVAR = "value1"
> SOMEVAR_qemux86 = "anothervalue"
> SOMEVAR_i586 = "yetanothervalue"
>
> The computed value of SOMEVAR would be "anothervalue". If MACHINE were
> changed to, say, "qemumips", then OVERRIDES would change and the value
> of SOMEVAR would become "value1".
>
>> Am I right in assuming the "variable name" consists of the uppercase parse
>> (regardless of number of underscores)?
>
> That is our (fairly strict) convention in OpenEmbedded, but FWIW I don't
> think bitbake itself enforces that; it's all dependent on what is in OVERRIDES
> and where the _ character appears in the left hand side of the assignment
> statement.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What are _virtual providers? and other Suffixes?
Hi Paul, Thanks - that makes it clearer. But now I have one other question to ask: if virtual/xyz is added to overrides when the item is dealt with, then in that case P_P_virtual/xyz_am335 has two overrides hanging off of the base variable PREFERRED_PROVIDER. You also said earlier that the latest override applies, so is there some rule for multiple conditionals on a variable? E.g. What happens in a case like the following? OVERRIDES="foo1:bar2:car3" VARIABLE_foo1_bar2 = "both" VARIABLE_car3 = "last one" what does VARIABLE wind up? The first is "more specific" in that it matches two values in overrides, whereas car is last, but less specific. Thanks & sorry if I'm missing something simple. Brad On Aug 20, 2013, at 4:33 PM, Paul Eggleton wrote: > On Tuesday 20 August 2013 23:16:56 Brad Litterell wrote: >> Thanks for taking the time to explain, very enlightening. I think I >> understood it, please allow me to play back my understanding: >> >> 1. _virtual is part of the variable name, and is not a special type of >> override. > > Actually, virtual/kernel is an override as well. The way a few variables, > including PREFERRED_PROVIDER, are used is that OVERRIDES is set to include > the > item being dealt with when the variable is read, thus specifically with > PREFERRED_PROVIDER you always override it with the name of the target you > wish > to select the provider for. > >> 2. PREFERRED_PROVIDER_virtual/kernel_am335x-evm breaks into: >> "PREFERRED_PROVIDER_virtual/kernel" with an override condition of >> "am335x-evm" > > Outside of the part of the code where it's actually read, yes. Within that > code the override "virtual/kernel" will be applied when it's looking to see > what the provider for "virtual/kernel" should be, and thus it will get the > appropriate value for the PREFERRED_PROVIDER variable. So technically the > variable is just PREFERRED_PROVIDER. > >> 3. So for the jpeg case: >>>> PREFERRED_PROVIDER_jpeg = "libjpeg-turbo" >>>> >>>> PREFERRED_PROVIDER_jpeg_armv5te = "jpeg" >> >> Could this have also been _virtual/jpeg? It's just that some components use >> the _virtual convention and others don't? > > The prefix is virtual/ not _virtual, and as I mentioned earlier virtual/ is > just a convention (although there are a few isolated parts of the code that > specifically look for the virtual/ prefix). The mechanism will work in the > same > way here; recipes that need jpeg decoding have "jpeg" in DEPENDS and > providing > libjpeg-turbo has jpeg in its PROVIDES, which it does, we can select between > two different recipes providing that - jpeg and libjpeg-turbo (where the > latter > is provided at all of course, i.e. when you have the meta-oe layer in your > configuration). > > I don't think there's any special reason we don't have virtual/jpeg rather > than jpeg here other than that having multiple jpeg decoding libraries is a > relatively new situation compared to others such as virtual/kernel, and there > are already a bunch of recipes out there referring to "jpeg" in their > DEPENDS. > (One wonders why there is a need for multiple jpeg decoding libraries in the > first place, but that's a different can of worms...) > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What are _virtual providers? and other Suffixes?
Paul, thanks so much! On Aug 21, 2013, at 7:26 AM, Paul Eggleton wrote: > Hi Brad, > > On Tuesday 20 August 2013 23:42:36 Brad Litterell wrote: >> Thanks - that makes it clearer. But now I have one other question to ask: >> >> if virtual/xyz is added to overrides when the item is dealt with, then in >> that case P_P_virtual/xyz_am335 has two overrides hanging off of the base >> variable PREFERRED_PROVIDER. >> >> You also said earlier that the latest override applies, so is there some >> rule for multiple conditionals on a variable? > > Yes, effectively all must be in OVERRIDES for the assignment statement to > take > effect. > >> E.g. What happens in a case like the following? >> >> OVERRIDES="foo1:bar2:car3" >> >> VARIABLE_foo1_bar2 = "both" >> VARIABLE_car3 = "last one" >> >> what does VARIABLE wind up? The first is "more specific" in that it matches >> two values in overrides, whereas car is last, but less specific. > > I would have thought that the value would have been "last one" however > experimentation shows that "both" is what you actually get. I'm not exactly > sure why. In practice I don't think we hit this kind of situation too often > though, i.e. a mix of double and single overrides where the single override > needs to take precedence. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to customize a file coming from another recipe?
I'm building w/the Arago distribution which contains lighttpd for a web server. I include this in my image as follows: IMAGE_INSTALL = "packagegroup-core-boot \ ... lighttpd lighttpd-module-cgi lighttpd-module-compress lighttpd-module-expire \ ... " This installs a default configuration file for the service which I now want to customize. What is the recommended way to overwrite or customize files in another package? Is the best course to create a recipe bbappend for the lighttpd_1.4.31.bb file that is being used? And can I just include a new file with the same name in my append and will it overwrite the old one, or do I need to create an actual patch file? Or is it better to create a new separate recipe that just ships my version of the configuration file? How are conflicts handled when two recipes attempt to install the same file? Thanks, Brad ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to customize a file coming from another recipe?
I'm building w/the Arago distribution which contains lighttpd for a web server. I include this in my image as follows: IMAGE_INSTALL = "packagegroup-core-boot \ ... lighttpd lighttpd-module-cgi lighttpd-module-compress lighttpd-module-expire \ ... " This installs a default configuration file for the service which I now want to customize. What is the recommended way to overwrite or customize files in another package? Is the best course to create a recipe bbappend for the lighttpd_1.4.31.bb file that is being used? And can I just include a new file with the same name in my append and will it overwrite the old one, or do I need to create an actual patch file? Or is it better to create a new separate recipe that just ships my version of the configuration file? How are conflicts handled when two recipes attempt to install the same file? Thanks, Brad ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Bitbake on live (uncommitted) code
Hi, I've grown to really appreciate bitbake for compiling code from a myriad of sources, however, what is the recommended course for source I am currently doing live development on? My code base lives in a couple of git repos that do NOT map one-to-one with recipes and I don't really want to store the source mixed in with the recipe meta data anyway, nor do I want to be forced to commit it to git just to do a build. Currently I run a pre-bitbake script that creates a tarball out of the source, but that is easy to forget and makes building a new image a two step proces. Since it is a build step I'd like it to be done by bitbake. Is there a recommended way to go about this? Thanks, Brad ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Identify Target for a given binary
I'm trying to rebuild uImage into my deploy folder (minimally) and so I tried: bitbake linux-am335x-psp -c clean bitbake linux-am335x-psp This works great for most of my recipes, but for the kernel something odd is happening. I keep getting a uImage with an old date in my deploy folder so it appears that the file is being cached somewhere. If I perform a -c cleanall it works, but then the entire project is redownloaded over git which is rather slow. So, what I want to do is figure out which -c targets I need to give to rebuild the kernel and not get these cached versions. (I notice that there are also several sysroot commands and such.) Is there an easy way to figure out from the logs which step is creating a particular binary on disk? With that I could trace back by finding the cached version in the work tree, and then rerun that step, etc... ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake on live (uncommitted) code
Thank you! I've been using externalsrc for a few days now and have a follow on question. It appears that bitbake's state information for the various recipes doesn't react to changes in source files in an external source. IOW, when I change a file in my external folder I need to perform 3 steps to create a new file system that reflects the change: bitbake -c clean bitbake bitbake Is it possible to ask bitbake to be more thorough about detecting file changes in external sources and rebuild the affected component automatically? Thanks, Brad From: Paul Eggleton [paul.eggle...@linux.intel.com] Sent: Friday, September 13, 2013 2:55 AM To: Brad Litterell Cc: Chris Larson; yocto@yoctoproject.org Subject: Re: [yocto] Bitbake on live (uncommitted) code On Thursday 12 September 2013 17:23:53 Chris Larson wrote: > On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell wrote: > > I've grown to really appreciate bitbake for compiling code from a myriad > > of sources, however, what is the recommended course for source I am > > currently doing live development on? My code base lives in a couple of > > git > > repos that do NOT map one-to-one with recipes and I don't really want to > > store the source mixed in with the recipe meta data anyway, nor do I want > > to be forced to commit it to git just to do a build. > > > > Currently I run a pre-bitbake script that creates a tarball out of the > > > > source, but that is easy to forget and makes building a new image a two > > step proces. Since it is a build step I'd like it to be done by bitbake. > > > > Is there a recommended way to go about this? > > See externalsrc.bbclass. Also the manual section that talks about using it: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QMake & externalsrc incompatible?
I have a number of QT components that have qmake style .pro files.
In my recipe I inherit both externalsrc & qmake2. I'm using qmake2 based on
the quicky sample recipe since I don't need X11 or the other GUI libraries.
In the bitbake work folder, the generated run.do_configure script resembles
this:
cd /home/brad/ecom/build/toolchain/work/.../ecomapi-2.0-r0/ecomapi-2.0/
...
PROFILES="`ls *.pro`"
This is the location where a tarball would normally be unpacked, but in this
case I'm using externalsrc and the source files are not here. Therefore the ls
*.pro doesn't return anything for the automatic profile detection and the build
fails.
My recipe is very simple (removing the description & licensing):
PV = "2.0"
inherit externalsrc qmake2
S = "${OEBASE}/ecomapi"
OEBASE in this case is the /home/brad/ecom folder
I looked in the yocto bugzilla and didn't find a known issue for this. Am I
doing something wrong?
Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Best way to reuse install scripts across multiple recipes?
I'm finding that I use a pattern like this in a number of recipes to install
all the files that exist in a particular folder, generally scripts or data
files:
# copy scripts
pushd ${S}/files/bin
# note that failure in the exec is not always captured here, so this needs
to be enhanced
# to catch that kind of build failure.
find . -type f -exec install -m 0644 {} ${D}/bin/{} \;
popd
As the comment exists, I need to expand this to a real loop with error handing,
so I'm wondering if (a) there already exists a similar call that I can reuse in
yocto (similar to oe_libinstall), or (b) whether I should add it to
utils.bbclass, or a private recipe. Would it be useful to submit back to the
project? Or am I just going about a common task the wrong way?
I'm thinking of adding a function like this:
oe_folderinstall
Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Question about automatic debug package generation
My recipe builds and ships an executable in /foo/bin/fooapp
FILES_${PN} += "/foo/bin/*"
WARNING: QA Issue: foo: Files/directories were installed but not shipped
/foo/bin/.debug
/foo/bin/.debug/fooapp
This file doesn't appear in the image, but is in the package folder:
./package/foo/bin/.debug/fooapp
It appears something is automatically creating these .debug files during the
packaging steps, but the corresponding file isn't under packages-split.
Can someone point me to a place to learn more about how these are created and
packaged?
Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Question about automatic debug package generation
Thanks Nicolas!
Sent from my Windows Phone
From: Nicolas Dechesne<mailto:nicolas.deche...@linaro.org>
Sent: 9/26/2013 15:29
To: Brad Litterell<mailto:b...@evidence.com>
Cc: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: Re: [yocto] Question about automatic debug package generation
On Fri, Sep 27, 2013 at 12:00 AM, Brad Litterell
mailto:b...@evidence.com>> wrote:
My recipe builds and ships an executable in /foo/bin/fooapp
FILES_${PN} += "/foo/bin/*"
WARNING: QA Issue: foo: Files/directories were installed but not shipped
/foo/bin/.debug
/foo/bin/.debug/fooapp
This file doesn't appear in the image, but is in the package folder:
./package/foo/bin/.debug/fooapp
It appears something is automatically creating these .debug files during the
packaging steps, but the corresponding file isn't under packages-split.
Can someone point me to a place to learn more about how these are created and
packaged?
this is done in meta/classes/package.bbclass. at the beginning of that file,
you will find an overall description of what the 'packaging' steps are, and you
can see, among many things:
# d) split_and_strip_files - split the files into runtime and debug and strip
them.
#Debug files include debug info split, and associated sources that end up
in -dbg packages
you can then check the source code for the function split_and_strip_files.
Now, about 'packaging' the files, you need to look at meta/conf/bitbake.conf
and search for FILES_{PN}-dbg. this is the default variable that specifies
which files go into the -dbg package. Your issue above is because the 'default'
path for binary is /usr/bin, hence the 'default' path for debug variants is
/usr/bin/.debug. But if you need '/foo' , you can change these default in your
recipe, by modifying FILES_{PN}xxx in your .bb file.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Setting PV dynamically in a recipe
Hi, I have a few recipes in my image that represent my own custom code. I would like to generate PV dynamically from my source code, but since the recipe is parsed before the code is extracted from the tarball, that's not easy to do. The Poky reference manual implies this is possible: PV is generally not overridden within a recipe unless it is building an unstable (i.e. development) version from a source code repository (e.g. Git or Subversion). However, I have not found an actual example. Is there a recommended way to do this? Thanks, Brad ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting PV dynamically in a recipe
Hi Zhenhua, Thank you for the reply. However, That's not what I'm looking for. I already get the latest version of the source code. What I'm really after is the ability to generate output packages that have increasing version numbers so I can use the package manager to update them. I think Martin's subsequent reply is the secret to use PKGV. I didn't know about that variable. Cheers, Brad From: zhenhua@freescale.com [zhenhua@freescale.com] Sent: Tuesday, December 17, 2013 1:41 AM To: Brad Litterell Cc: yocto@yoctoproject.org Subject: RE: Setting PV dynamically in a recipe AUTOREV might be what you are looking for. http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-AUTOREV Best Regards, Zhenhua > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Brad Litterell > Sent: Tuesday, December 17, 2013 4:17 PM > To: yocto@yoctoproject.org > Subject: [yocto] Setting PV dynamically in a recipe > > Hi, > > I have a few recipes in my image that represent my own custom code. I > would like to generate PV dynamically from my source code, but since the > recipe is parsed before the code is extracted from the tarball, that's > not easy to do. > > The Poky reference manual implies this is possible: > PV is generally not overridden within a recipe unless it is building an > unstable (i.e. development) version from a source code repository (e.g. > Git or Subversion). > > However, I have not found an actual example. Is there a recommended way > to do this? > > Thanks, > Brad > ___ > 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] Setting PV dynamically in a recipe
Hi Paul,
Thanks for that tip. For my private packages I don't build directly from git,
but from a tarball (in turn created from my working directory) because I want
to be able to build the source I'm working on without committing it to git.
In an ideal world, I'd like to to be able to build in two modes: dev & release.
Release mode would use the git-based solution (and enforce building from git),
and in the dev mode, build from something like externalsrc. (The reason I
don't use externalsrc directly is because it didn't detect changes in the
underlying external source, so I created a script that does and updates the
tarball.)
What is the best way to switch recipes between dev & test modes like that. It
appears debug-tweaks is only used in image recipes, so I don't know whether I
should (or could) use something like this in a package recipe:
SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks",
"...tarball...", "...git..."}'
or whether something like that is asking for trouble. My current solution is
manual - edit the recipe, but that feels kinda lame.
It seems like most of the yocto build tools assume building directly from git
(or with external-src but without dependency checking).
Any suggestions?
Thanks,
Brad
From: Paul Eggleton [paul.eggle...@linux.intel.com]
Sent: Tuesday, December 17, 2013 12:24 PM
To: Brad Litterell
Cc: zhenhua@freescale.com; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe
Hi Brad,
On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> Thank you for the reply. However, That's not what I'm looking for. I
> already get the latest version of the source code.
>
> What I'm really after is the ability to generate output packages that have
> increasing version numbers so I can use the package manager to update them.
>
> I think Martin's subsequent reply is the secret to use PKGV. I didn't know
> about that variable.
You don't need to use any special classes to get this behaviour. Put this in
your recipe (replacing 1.2.3 with the appropriate base version you are
building):
PV = "1.2.3+git${SRCPV}"
and enable the PR service, which will ensure SRCREV changes always increment
the version properly:
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting PV dynamically in a recipe
Hi Martin,
I decided just to create my own feature list:
MY_FEATURES="debug"
and I can happily query it in my custom recipes.
However, I haven't quite figured out the best way to taint the status hashes
for my packages so that changes to this flag force a rebuild. I originally
tried putting the marking in PR, which works for causing the right things to
rebuild, but when I switch from debug to release, I get errors like this:
ERROR: Package version for package my-config-files went backwards which would
break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
Is there a way I can taint my recipes so that changing MY_FEATURES causes them
all to be evaluated as out of date. I don't care if that causes some extra
rebuilds when I switch MY_FEATURES - I care more about avoiding the error
message. Or is there a way I can turn off this particular error message on
specific recipes?
Thanks,
Brad
From: Martin Jansa [martin.ja...@gmail.com]
Sent: Wednesday, December 18, 2013 1:36 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe
On Wed, Dec 18, 2013 at 01:29:25AM +, Brad Litterell wrote:
> Hi Paul,
>
> Thanks for that tip. For my private packages I don't build directly from
> git, but from a tarball (in turn created from my working directory) because I
> want to be able to build the source I'm working on without committing it to
> git.
>
> In an ideal world, I'd like to to be able to build in two modes: dev &
> release. Release mode would use the git-based solution (and enforce building
> from git), and in the dev mode, build from something like externalsrc. (The
> reason I don't use externalsrc directly is because it didn't detect changes
> in the underlying external source, so I created a script that does and
> updates the tarball.)
>
> What is the best way to switch recipes between dev & test modes like that.
> It appears debug-tweaks is only used in image recipes, so I don't know
> whether I should (or could) use something like this in a package recipe:
>
> SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks",
> "...tarball...", "...git..."}'
>
> or whether something like that is asking for trouble. My current solution is
> manual - edit the recipe, but that feels kinda lame.
>
> It seems like most of the yocto build tools assume building directly from git
> (or with external-src but without dependency checking).
>
> Any suggestions?
Don't use *IMAGE_FEATURES* to in recipe conditionals.
When you're building some package you don't know in which image it will
be included so you cannot know with which *IMAGE_FEATURES* it should be
built.
It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
still it's unsafe to assume they are "global". With improved
base_contains and sstate interaction, using some flag in DISTRO_FEATURES
shouldn't cause so many packages to rebuild, so it could be usable for
"debug-build" flag.
>
> From: Paul Eggleton [paul.eggle...@linux.intel.com]
> Sent: Tuesday, December 17, 2013 12:24 PM
> To: Brad Litterell
> Cc: zhenhua@freescale.com; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> Hi Brad,
>
> On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > Thank you for the reply. However, That's not what I'm looking for. I
> > already get the latest version of the source code.
> >
> > What I'm really after is the ability to generate output packages that have
> > increasing version numbers so I can use the package manager to update them.
> >
> > I think Martin's subsequent reply is the secret to use PKGV. I didn't know
> > about that variable.
>
> You don't need to use any special classes to get this behaviour. Put this in
> your recipe (replacing 1.2.3 with the appropriate base version you are
> building):
>
> PV = "1.2.3+git${SRCPV}"
>
> and enable the PR service, which will ensure SRCREV changes always increment
> the version properly:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] BB_NO_NETWORK question
I am having trouble getting my build environment to work offline. I followed
the instructions here:
https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F
I've built my project, created the tarballs, etc. However, it appears there is
still something I'm missing. I get an error here:
$ bitbake base-files
...
Loaded 57 entries from dependency cache.
NOTE: Error during finalise of
/home/brad/etm2/sources/meta-arago/meta-arago-extras/recipes-devtools/ltp-ddt/ltp-ddt-legacy_1.0.bb
ERROR: ExpansionError during parsing
/home/brad/etm2/sources/meta-arago/meta-arago-extras/recipes-devtools/ltp-ddt/ltp-ddt-legacy_1.0.bb:
Failure expanding variable S: ExpansionError: Failure expanding variable
SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
NetworkAccess: Network access disabled through BB_NO_NETWORK but access
requested with command git ls-remote
git://arago-project.org/git/projects/test-automation/ltp-ddt.git master (for
url None)
ERROR: Command execution failed: Exited with 1
In this case, the SRC_URI looks like this:
SRCREV = "5fba3d42f126ce1fb7d0412d729b753ee5a4"
BRANCH ?= "master"
SRC_URI =
"git://arago-project.org/git/projects/test-automation/ltp-ddt.git;protocol=git;branch=${BRANCH}"
So, I figured apply the same fix as mentioned on the Wiki:
SRCREV = "5fba3d42f126ce1fb7d0412d729b753ee5a4"
#BRANCH ?= "master"
#SRC_URI =
"git://arago-project.org/git/projects/test-automation/ltp-ddt.git;protocol=git;branch=${BRANCH}"
SRC_URI =
"git://arago-project.org/git/projects/test-automation/ltp-ddt.git;protocol=git"
But I get the same error? And I'm not even using ltp-ddt...
Is there something I'm missing in setting up BB_NO_NETWORK?
Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting PV dynamically in a recipe
I'm using it in a task, like this:
do_install_prepend() {
if [ ! -z ${ETM_DEBUG} ]; then
...do debugging stuff ...
fi
}
but having it in a task definition doesn't seem to taint the sstate. Trying to
figure out what other variables go into it. E.g. does DESCRIPTION get included
in the sstate? (I'd assume not). Is there a meta-list somewhere of what goes
in the state hash?
___
From: Martin Jansa [martin.ja...@gmail.com]
Sent: Friday, December 20, 2013 1:34 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe
On Fri, Dec 20, 2013 at 03:09:31AM +, Brad Litterell wrote:
> Hi Martin,
>
> I decided just to create my own feature list:
>
> MY_FEATURES="debug"
>
> and I can happily query it in my custom recipes.
>
> However, I haven't quite figured out the best way to taint the status hashes
> for my packages so that changes to this flag force a rebuild. I originally
> tried putting the marking in PR, which works for causing the right things to
> rebuild, but when I switch from debug to release, I get errors like this:
>
> ERROR: Package version for package my-config-files went backwards which would
> break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
>
> Is there a way I can taint my recipes so that changing MY_FEATURES causes
> them all to be evaluated as out of date. I don't care if that causes some
> extra rebuilds when I switch MY_FEATURES - I care more about avoiding the
> error message. Or is there a way I can turn off this particular error
> message on specific recipes?
Depends on where you're using MY_FEATURES variable in the recipe, in
most cases it should be included in sstate signature and rebuilt
automatically (with the same version) when MY_FEATURES is changes.
If you're using latest oe-core, that error is QA check, which can be
disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
WARN_QA in distro config.
> ____
> From: Martin Jansa [martin.ja...@gmail.com]
> Sent: Wednesday, December 18, 2013 1:36 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> On Wed, Dec 18, 2013 at 01:29:25AM +, Brad Litterell wrote:
> > Hi Paul,
> >
> > Thanks for that tip. For my private packages I don't build directly from
> > git, but from a tarball (in turn created from my working directory) because
> > I want to be able to build the source I'm working on without committing it
> > to git.
> >
> > In an ideal world, I'd like to to be able to build in two modes: dev &
> > release. Release mode would use the git-based solution (and enforce
> > building from git), and in the dev mode, build from something like
> > externalsrc. (The reason I don't use externalsrc directly is because it
> > didn't detect changes in the underlying external source, so I created a
> > script that does and updates the tarball.)
> >
> > What is the best way to switch recipes between dev & test modes like that.
> > It appears debug-tweaks is only used in image recipes, so I don't know
> > whether I should (or could) use something like this in a package recipe:
> >
> > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks",
> > "...tarball...", "...git..."}'
> >
> > or whether something like that is asking for trouble. My current solution
> > is manual - edit the recipe, but that feels kinda lame.
> >
> > It seems like most of the yocto build tools assume building directly from
> > git (or with external-src but without dependency checking).
> >
> > Any suggestions?
>
> Don't use *IMAGE_FEATURES* to in recipe conditionals.
>
> When you're building some package you don't know in which image it will
> be included so you cannot know with which *IMAGE_FEATURES* it should be
> built.
>
> It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
> still it's unsafe to assume they are "global". With improved
> base_contains and sstate interaction, using some flag in DISTRO_FEATURES
> shouldn't cause so many packages to rebuild, so it could be usable for
> "debug-build" flag.
>
> >
> > From: Paul Eggleton [paul.eggle...@linux.intel.com]
> > Sent: Tuesday, December 17, 2013 12:24 PM
> > To: Brad Litterell
> > Cc: zhenhua@freescale.com; yocto@yoctoproject.org
> > Subject: Re: [yocto
Re: [yocto] Setting PV dynamically in a recipe
I'll have a look at diffsigs. ${ETM_DEBUG} is the parsed representation of
just the debug flag in MY_FEATURES (assuming I'll have more than one flag in
MY_FEATURES eventually). So, in this case, yes they are referring to the same.
Thanks for asking though.
From: Martin Jansa [martin.ja...@gmail.com]
Sent: Friday, December 20, 2013 2:01 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe
On Fri, Dec 20, 2013 at 09:39:13AM +0000, Brad Litterell wrote:
> I'm using it in a task, like this:
> do_install_prepend() {
> if [ ! -z ${ETM_DEBUG} ]; then
> ...do debugging stuff ...
> fi
> }
>
> but having it in a task definition doesn't seem to taint the sstate. Trying
> to figure out what other variables go into it. E.g. does DESCRIPTION get
> included in the sstate? (I'd assume not). Is there a meta-list somewhere of
> what goes in the state hash?
You can use bitbake-diffsigs command on one of sigdata files from your
recipe to see if the variable is included.
But here you're showing ETM_DEBUG not MY_FEATURES, is it the same?
>
> ___
> From: Martin Jansa [martin.ja...@gmail.com]
> Sent: Friday, December 20, 2013 1:34 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> On Fri, Dec 20, 2013 at 03:09:31AM +, Brad Litterell wrote:
> > Hi Martin,
> >
> > I decided just to create my own feature list:
> >
> > MY_FEATURES="debug"
> >
> > and I can happily query it in my custom recipes.
> >
> > However, I haven't quite figured out the best way to taint the status
> > hashes for my packages so that changes to this flag force a rebuild. I
> > originally tried putting the marking in PR, which works for causing the
> > right things to rebuild, but when I switch from debug to release, I get
> > errors like this:
> >
> > ERROR: Package version for package my-config-files went backwards which
> > would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
> >
> > Is there a way I can taint my recipes so that changing MY_FEATURES causes
> > them all to be evaluated as out of date. I don't care if that causes some
> > extra rebuilds when I switch MY_FEATURES - I care more about avoiding the
> > error message. Or is there a way I can turn off this particular error
> > message on specific recipes?
>
> Depends on where you're using MY_FEATURES variable in the recipe, in
> most cases it should be included in sstate signature and rebuilt
> automatically (with the same version) when MY_FEATURES is changes.
>
> If you're using latest oe-core, that error is QA check, which can be
> disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
> WARN_QA in distro config.
>
> > ____
> > From: Martin Jansa [martin.ja...@gmail.com]
> > Sent: Wednesday, December 18, 2013 1:36 AM
> > To: Brad Litterell
> > Cc: Paul Eggleton; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > On Wed, Dec 18, 2013 at 01:29:25AM +, Brad Litterell wrote:
> > > Hi Paul,
> > >
> > > Thanks for that tip. For my private packages I don't build directly from
> > > git, but from a tarball (in turn created from my working directory)
> > > because I want to be able to build the source I'm working on without
> > > committing it to git.
> > >
> > > In an ideal world, I'd like to to be able to build in two modes: dev &
> > > release. Release mode would use the git-based solution (and enforce
> > > building from git), and in the dev mode, build from something like
> > > externalsrc. (The reason I don't use externalsrc directly is because it
> > > didn't detect changes in the underlying external source, so I created a
> > > script that does and updates the tarball.)
> > >
> > > What is the best way to switch recipes between dev & test modes like
> > > that. It appears debug-tweaks is only used in image recipes, so I don't
> > > know whether I should (or could) use something like this in a package
> > > recipe:
> > >
> > > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks",
> > > "...tarball...", "...git..."}'
> > >
> > > or whether something like that is asking for trouble.
Re: [yocto] Setting PV dynamically in a recipe
Hi again,
Is it possible I don't have sigdata files?
I am trying bitbake-diffsigs -t
For recipe, I've tried the package name: "etm-core" & file name "etm-core.bb"
for task, I've tried fetch, configure, compile, install, do_install.
All come back with same message "no sigdata files found matching "
Is there a way to list all the possible inputs of sigfiles that exist?
Disclaimer - Yocto 1.3 - possibly known issue?
From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on behalf
of Brad Litterell [b...@evidence.com]
Sent: Friday, December 20, 2013 2:03 AM
To: Martin Jansa
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe
I'll have a look at diffsigs. ${ETM_DEBUG} is the parsed representation of
just the debug flag in MY_FEATURES (assuming I'll have more than one flag in
MY_FEATURES eventually). So, in this case, yes they are referring to the same.
Thanks for asking though.
From: Martin Jansa [martin.ja...@gmail.com]
Sent: Friday, December 20, 2013 2:01 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe
On Fri, Dec 20, 2013 at 09:39:13AM +, Brad Litterell wrote:
> I'm using it in a task, like this:
> do_install_prepend() {
> if [ ! -z ${ETM_DEBUG} ]; then
> ...do debugging stuff ...
> fi
> }
>
> but having it in a task definition doesn't seem to taint the sstate. Trying
> to figure out what other variables go into it. E.g. does DESCRIPTION get
> included in the sstate? (I'd assume not). Is there a meta-list somewhere of
> what goes in the state hash?
You can use bitbake-diffsigs command on one of sigdata files from your
recipe to see if the variable is included.
But here you're showing ETM_DEBUG not MY_FEATURES, is it the same?
>
> ___
> From: Martin Jansa [martin.ja...@gmail.com]
> Sent: Friday, December 20, 2013 1:34 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> On Fri, Dec 20, 2013 at 03:09:31AM +, Brad Litterell wrote:
> > Hi Martin,
> >
> > I decided just to create my own feature list:
> >
> > MY_FEATURES="debug"
> >
> > and I can happily query it in my custom recipes.
> >
> > However, I haven't quite figured out the best way to taint the status
> > hashes for my packages so that changes to this flag force a rebuild. I
> > originally tried putting the marking in PR, which works for causing the
> > right things to rebuild, but when I switch from debug to release, I get
> > errors like this:
> >
> > ERROR: Package version for package my-config-files went backwards which
> > would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
> >
> > Is there a way I can taint my recipes so that changing MY_FEATURES causes
> > them all to be evaluated as out of date. I don't care if that causes some
> > extra rebuilds when I switch MY_FEATURES - I care more about avoiding the
> > error message. Or is there a way I can turn off this particular error
> > message on specific recipes?
>
> Depends on where you're using MY_FEATURES variable in the recipe, in
> most cases it should be included in sstate signature and rebuilt
> automatically (with the same version) when MY_FEATURES is changes.
>
> If you're using latest oe-core, that error is QA check, which can be
> disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
> WARN_QA in distro config.
>
> >
> > From: Martin Jansa [martin.ja...@gmail.com]
> > Sent: Wednesday, December 18, 2013 1:36 AM
> > To: Brad Litterell
> > Cc: Paul Eggleton; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > On Wed, Dec 18, 2013 at 01:29:25AM +, Brad Litterell wrote:
> > > Hi Paul,
> > >
> > > Thanks for that tip. For my private packages I don't build directly from
> > > git, but from a tarball (in turn created from my working directory)
> > > because I want to be able to build the source I'm working on without
> > > committing it to git.
> > >
> > > In an ideal world, I'd like to to be able to build in two modes: dev &
> > > release. Release mode would use the git-based solution (and enforce
> > > building from git), and in the dev mode, build from something like
> > > externalsrc. (The reas
[yocto] How to exclude QT Debug libraries from image
I have a package "bar" that uses qt4-embedded (inherit qt4e). When I include the dbg package for my stuff (bar-dbg) in the image, I also get several hundred MB of QT related debug files that I'm not interested in. All I want to do is run GDB on my code, I don't care to debug into the QT code. That makes sense as Yocto figures out the dependency chain for all the packages in the image, but I'm wondering if there is a way to defeat it since it will reduce the size of my image considerably (over 10x) and save me a lot of time during the build. In essence, I want something like DEPENDS -= "". Is there a way to do this? Thanks, Brad ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Peripheral hardware support
I'd like to include a RFID reader in a Yocto-based project. What is the best way to find devices that have driver support already or that provide open-source drivers suitable for inclusion? Is there a hardware support list for stuff like that somewhere? Thanks, Brad -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] unsubscribe
unsubscribe -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
