Re: [yocto] [bitbake-devel] difference between DEPLOYDIR vs D
IIrc DEPLOYDIR contents get copied to DEPLOY_DIR by sstate for the do_deploy task. I.e. tmp/deploy/. This is independent of packaging. On Wed, Nov 14, 2018 at 5:38 PM Davis Roman wrote: > Hello, > > I'm trying to understand the correlation between the $DEPLOYDIR and $D > variables. > > They both seem very similar. > > Do files from DEPLOYDIR eventually get copied to D in order to finally > make its way into the final package? > > If so, why bother with DEPLOYDIR and instead just copy straight into D? > > Thank you, > > Davis > -- > ___ > bitbake-devel mailing list > bitbake-de...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/bitbake-devel > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [bitbake-devel] how to store a modification of a bbclass in the poky layer in my own layer.
Layer priority as defined by BBFILE_PRIORITY controls recipe selection, not
bbclass and config file parsing. See the bitbake reference manual for more
detail.
On Fri, Aug 17, 2018 at 3:54 PM Davis Roman wrote:
> Hi Christopher,
>
> I am very intrigued by your response.
>
> Initially I had mentioned that the 'bitbake-layers show-layers'
> command indicates that my layer, meta-hon-grip, has a priority of 8
> which is among the highest while the meta layer only has a priority of
> 5.
>
> However, now that you mentioned the bblayers.conf file, I see that the
> meta-hon-grip layer is defined after the meta layer.
>
> Therefore it appears to me that my bblayers.conf contradicts
> 'bitbake-layers show-layers'
>
> Could you please help me make sense of this?
>
> Thank you,
>
> Davis
>
>
>
>
>
> POKY_BBLAYERS_CONF_VERSION = "2"
>
> BBPATH = "${TOPDIR}"
> BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True))
> + '/../..')}"
>
> BBFILES ?= ""
> BBLAYERS = " \
> ${BSPDIR}/sources/poky/meta \
> ${BSPDIR}/sources/poky/meta-poky \
> \
> ${BSPDIR}/sources/meta-openembedded/meta-oe \
> ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
> \
> ${BSPDIR}/sources/meta-fsl-arm \
> ${BSPDIR}/sources/meta-fsl-arm-extra \
> ${BSPDIR}/sources/meta-fsl-demos \
> "
> ##Freescale Yocto Project Release layer
> BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-bsp "
> BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-sdk "
> BBLAYERS += " ${BSPDIR}/sources/meta-browser "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-gnome "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-networking "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-python "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-filesystems "
> BBLAYERS += " ${BSPDIR}/sources/meta-qt5 "
> BBLAYERS += " ${BSPDIR}/sources/meta-hon-grip "
> BBLAYERS += " ${BSPDIR}/sources/meta-java "
> BBLAYERS += " ${BSPDIR}/sources/meta-swupdate "
> BBLAYERS += " ${BSPDIR}/sources/meta-bc "
> BBLAYERS += " ${BSPDIR}/sources/meta-updater "
> BBLAYERS += " ${BSPDIR}/sources/meta-gplv2 "
>
> On Fri, Aug 17, 2018 at 6:01 PM, Christopher Larson
> wrote:
> > Your layer has to be before poky/meta in BBLAYERS, as that determines
> > BBPATH, which is how bbclasses and config files are found (much like
> PATH).
> >
> > On Fri, Aug 17, 2018 at 12:11 PM Davis Roman
> > wrote:
> >>
> >> Hello!
> >>
> >>
> >> I've made a modification in poky/meta/classes/libc-package.bbclass (
> >> shown below)
> >>
> >> However I don't want this change to be stored here long term and
> >> instead feel that it should live in my project specific layer,
> >> meta-hon-grip.
> >>
> >> After checking with bitbake-layers, I saw that my layer has a higher
> >> priority than the poky layer so my layer should be checked first ( or
> >> so I thought)
> >>
> >> I copied the modified version of libc-packages.bbclass into
> >> meta-hon-grip/classes and I restored the version in the poky layer to
> >> its original state.
> >>
> >> After making this change, I found that the modified version in my
> >> layer is not being used and instead the version in the poky layer is
> >> the one in play.
> >>
> >> I'm trying to figure out what else to try.
> >>
> >> Any suggestions would be greatly appreciated!
> >>
> >> Thank you,
> >>
> >> Davis
> >>
> >> diff --git a/meta/classes/libc-package.bbclass
> >> b/meta/classes/libc-package.bbclass
> >> index 467d567..72d447a 100644
> >> --- a/meta/classes/libc-package.bbclass
> >> +++ b/meta/classes/libc-package.bbclass
> >> @@ -287,7 +287,7 @@ python package_do_split_gconvs () {
> >> bb.error("locale_arch_options not found for
> >> target_arch=" + target_arch)
> >> raise bb.build.FuncFailed("unknown arch:" +
> >> target_arch + " for locale_arch_options")
> >>
> >> -localedef_opts += " --force --old-style --no-archive
> >> --prefix=%s \
> >> +localedef_opts += "
Re: [yocto] [bitbake-devel] how to store a modification of a bbclass in the poky layer in my own layer.
Your layer has to be before poky/meta in BBLAYERS, as that determines
BBPATH, which is how bbclasses and config files are found (much like PATH).
On Fri, Aug 17, 2018 at 12:11 PM Davis Roman
wrote:
> Hello!
>
>
> I've made a modification in poky/meta/classes/libc-package.bbclass (
> shown below)
>
> However I don't want this change to be stored here long term and
> instead feel that it should live in my project specific layer,
> meta-hon-grip.
>
> After checking with bitbake-layers, I saw that my layer has a higher
> priority than the poky layer so my layer should be checked first ( or
> so I thought)
>
> I copied the modified version of libc-packages.bbclass into
> meta-hon-grip/classes and I restored the version in the poky layer to
> its original state.
>
> After making this change, I found that the modified version in my
> layer is not being used and instead the version in the poky layer is
> the one in play.
>
> I'm trying to figure out what else to try.
>
> Any suggestions would be greatly appreciated!
>
> Thank you,
>
> Davis
>
> diff --git a/meta/classes/libc-package.bbclass
> b/meta/classes/libc-package.bbclass
> index 467d567..72d447a 100644
> --- a/meta/classes/libc-package.bbclass
> +++ b/meta/classes/libc-package.bbclass
> @@ -287,7 +287,7 @@ python package_do_split_gconvs () {
> bb.error("locale_arch_options not found for
> target_arch=" + target_arch)
> raise bb.build.FuncFailed("unknown arch:" +
> target_arch + " for locale_arch_options")
>
> -localedef_opts += " --force --old-style --no-archive
> --prefix=%s \
> +localedef_opts += " --force --no-archive --prefix=%s \
> --inputfile=%s/%s/i18n/locales/%s --charmap=%s %s/%s" \
> % (treedir, treedir, datadir, locale, encoding,
> outputpath, name)
>
> @@ -295,7 +295,7 @@ python package_do_split_gconvs () {
> (path, i18npath, gconvpath, localedef_opts)
> else: # earlier slower qemu way
> qemu = qemu_target_binary(d)
> -localedef_opts = "--force --old-style --no-archive
> --prefix=%s \
> +localedef_opts = "--force --no-archive --prefix=%s \
> --inputfile=%s/i18n/locales/%s --charmap=%s %s" \
> % (treedir, datadir, locale, encoding, name)
> --
> ___
> bitbake-devel mailing list
> bitbake-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] package.bbclass: add prohibited-path qa test
On Mon, Nov 13, 2017 at 7:10 PM, Christopher Larson
wrote:
>
>
> On Mon, Nov 13, 2017 at 11:17 AM, Martyn Welch
> wrote:
>
>> From: Fabien Lahoudere
>>
>> Sometimes we wish to ensure that packages don't install files or
>> directories somewhere that may prove detrimental to the operation of the
>> system. For example, this may be the case if files are placed in a
>> directory that is utilised as a mount point at run time, thus making them
>> inaccessible once when the mount point is being utilised.
>>
>> Implement the prohibited-path QA test, which enables such locations to be
>> specified in a "PROHIBITED_PATH" variable. This implementation allows for
>> exact matches and simple wildcards (paths ending with an asterisk. An
>> error will be raised should a match be found, or in the case of a
>> wildcard, for any files added below the specificed location(s).
>>
>> Signed-off-by: Fabien Lahoudere
>> Signed-off-by: Martyn Welch
>> ---
>> meta/classes/insane.bbclass | 2 +-
>> meta/classes/package.bbclass | 11 +++
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
>> index def9c70..fb10681 100644
>> --- a/meta/classes/insane.bbclass
>> +++ b/meta/classes/insane.bbclass
>> @@ -33,7 +33,7 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files
>> arch pkgconfig la \
>> perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
>> split-strip packages-list pkgv-undefined var-undefined \
>> version-going-backwards expanded-d invalid-chars \
>> -license-checksum dev-elf file-rdeps \
>> +license-checksum dev-elf file-rdeps prohibited-path \
>> "
>> # Add usrmerge QA check based on distro feature
>> ERROR_QA_append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge',
>> ' usrmerge', '', d)}"
>> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
>> index 2053d46..721ca1e 100644
>> --- a/meta/classes/package.bbclass
>> +++ b/meta/classes/package.bbclass
>> @@ -1162,6 +1162,17 @@ python populate_packages () {
>> continue
>> seen.append(file)
>>
>> +prohibited_path = d.getVar('PROHIBITED_PATH')
>> +if prohibited_path is not None:
>> +for p in prohibited_path.split():
>> +exactmatch = True
>> +if p.endswith("*"):
>> +p = p[:len(p)-1]
>> +exactmatch = False
>> +if file[1:].startswith(p) and ((file[1:] != p) or
>> exactmatch) :
>> +msg = "%s is in a prohibited path.\n" % file[1:]
>> + package_qa_handle_error("prohibited-path", msg,
>> d)
>>
>
> Unless I’m missing something, you aren’t checking for startswith(p +
> os.sep), so a file in libexec would match a prohibited path of lib, as it’d
> still start with that, no?
>
You might also consider some form of path normalization if you’re comparing
directly like this, otherwise i.e. //foo wouldn’t match /foo, even though
it’s the same path.
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] package.bbclass: add prohibited-path qa test
On Mon, Nov 13, 2017 at 11:17 AM, Martyn Welch wrote:
> From: Fabien Lahoudere
>
> Sometimes we wish to ensure that packages don't install files or
> directories somewhere that may prove detrimental to the operation of the
> system. For example, this may be the case if files are placed in a
> directory that is utilised as a mount point at run time, thus making them
> inaccessible once when the mount point is being utilised.
>
> Implement the prohibited-path QA test, which enables such locations to be
> specified in a "PROHIBITED_PATH" variable. This implementation allows for
> exact matches and simple wildcards (paths ending with an asterisk. An
> error will be raised should a match be found, or in the case of a
> wildcard, for any files added below the specificed location(s).
>
> Signed-off-by: Fabien Lahoudere
> Signed-off-by: Martyn Welch
> ---
> meta/classes/insane.bbclass | 2 +-
> meta/classes/package.bbclass | 11 +++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index def9c70..fb10681 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -33,7 +33,7 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch
> pkgconfig la \
> perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
> split-strip packages-list pkgv-undefined var-undefined \
> version-going-backwards expanded-d invalid-chars \
> -license-checksum dev-elf file-rdeps \
> +license-checksum dev-elf file-rdeps prohibited-path \
> "
> # Add usrmerge QA check based on distro feature
> ERROR_QA_append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '
> usrmerge', '', d)}"
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 2053d46..721ca1e 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1162,6 +1162,17 @@ python populate_packages () {
> continue
> seen.append(file)
>
> +prohibited_path = d.getVar('PROHIBITED_PATH')
> +if prohibited_path is not None:
> +for p in prohibited_path.split():
> +exactmatch = True
> +if p.endswith("*"):
> +p = p[:len(p)-1]
> +exactmatch = False
> +if file[1:].startswith(p) and ((file[1:] != p) or
> exactmatch) :
> +msg = "%s is in a prohibited path.\n" % file[1:]
> +package_qa_handle_error("prohibited-path", msg,
> d)
>
Unless I’m missing something, you aren’t checking for startswith(p +
os.sep), so a file in libexec would match a prohibited path of lib, as it’d
still start with that, no?
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] layer.conf on openembedded-core ?
The openembedded-core root isn’t a layer, openembedded-core/meta is. On Mon, Aug 14, 2017 at 8:49 AM, Leonardo Sandoval < leonardo.sandoval.gonza...@linux.intel.com> wrote: > On Mon, 2017-08-14 at 15:11 +0800, Riko wrote: > > Dear Yocto Members, > > > > How can I find this file ? > > > this is a pretty general question. are you running bitbake from the > build directory? double check your conf/bblayers.conf and make sure > paths there are pointing correctly. > > > > > > == > > > > ERROR: Unable to parse > > /home/bianchi/poky/openembedded-core/conf/layer.conf: [Errno 2] file > > /home/bianchi/poky/openembedded-core/conf/layer.conf not found > > > > > > Thanks, > > > > Riko > > > > > -- > ___________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] mtree: add recipe
On Thu, May 18, 2017 at 12:22 AM, wrote: > From: Kai Kang > > Add recipe mtree port from BSD. Add a patch to handle null return > from getlogin. > > Signed-off-by: Kai Kang > Exactly what layer are you aiming for this to go to? The list you sent it to (yocto) doesn’t imply any particular layer.. -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bug 11307 - sstate.bbclass tries to modify mirror files
On Tue, Apr 11, 2017 at 11:37 PM, Paulo Neves wrote: > Commit 51edde653707e7a3cd2186082458f01f32cd1996 makes a wrong > assumption that SSTATE_MIRRORS have write permissions. > > A mirror is by definition outside of it's user control. In my use case > it happens I does not have permissions to update the access time of > the dereferenced symbolic-link file. > > If we had the possibility to modify the sstate-mirror we would have > set SSTATE_DIR instead. There are 3 possible fixes: > > * Revert this patch. It seems tailored to a very special use case > which breaks the definition of mirror. > * Only touch the file if the file access time is writeable. > * Set (yet) another option to touch SSTATE_MIRROR files. > > I also can imagine this raising sever performance issues if the mirror > is used by several users at the same time. The server will need to > update the file meta data every time > > This patch fixes the bug with minimal impact on the original > functionality. Option 2 > > > Related to (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10857) > > From aa8cab9660744c8d5277f8e82f10a844884aff78 Mon Sep 17 00:00:00 2001 > From: Paulo Neves > Date: Tue, 11 Apr 2017 10:57:47 +0300 > Subject: [PATCH] Added test for write ability of sstate-mirror .siginfo > Thanks much for your contribution, this seems reasonable to me. That said, the subject line needs tweaking to meet our commit message guidelines, i.e.: sstate.bbclass: handle non-writable sstate mirror, or similar. And the yocto bug id should go in the body, not the subject line. I realize it probably sounds nitpicky, but maintaining commit message quality makes it much easier to review the logs in the future. This file is also in the oe-core layer, so the patch should ideally go to the openembedded-core mailing list. Thanks again! See http://openembedded.org/wiki/Commit_Patch_Message_Guidelines. -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Fri, Feb 17, 2017 at 3:39 PM, Christopher Larson
wrote:
> On Fri, Feb 17, 2017 at 2:26 PM, Aníbal Limón <
> anibal.li...@linux.intel.com> wrote:
>
>> +parser.add_argument('-l', '--layer', metavar='LAYER_DIR',
>> +help='Layer to test compatibility with Yocto Project',
>> +action='store', required=True)
>>
>
> The behavior of this argument is quite unintuitive. First, this path isn’t
> actually used as the layer directory, detect_layers searches down from that
> path to *find* layers in that subdirectory, so the argument isn’t what it
> says it is. Second, why are you making an option mandatory rather than just
> using arguments?
>
> That is, why `layer-compat-layer.py -l layerpath` rather than
> `layer-compat-layer.py layerpath`. If you change the call to
> `parser.add_argument(‘layer’, …)` it’d change to the latter behavior.
>
Worth noting that you could, and probably should, also use nargs=‘+’ to let
the user specify multiple layers to check, rather than a single path, if
you go the latter route, and if not, you could change it to an append style
(for the ‘action’) argument to accomplish the same.
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Fri, Feb 17, 2017 at 2:26 PM, Aníbal Limón
wrote:
> +parser.add_argument('-l', '--layer', metavar='LAYER_DIR',
> +help='Layer to test compatibility with Yocto Project',
> +action='store', required=True)
>
The behavior of this argument is quite unintuitive. First, this path isn’t
actually used as the layer directory, detect_layers searches down from that
path to *find* layers in that subdirectory, so the argument isn’t what it
says it is. Second, why are you making an option mandatory rather than just
using arguments?
That is, why `layer-compat-layer.py -l layerpath` rather than
`layer-compat-layer.py layerpath`. If you change the call to
`parser.add_argument(‘layer’, …)` it’d change to the latter behavior.
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [[RFC][PATCH]] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Sat, Feb 11, 2017 at 10:55 AM, Aníbal Limón wrote: > During the development of this script based on OEQA framework i found a > bug causing don't display stack traces, i sent a fix to the ML [1] also > is on my branch at [2]. > > I attached and example of how a log file looks, the example log results > are based on meta-yocto-bsp. > > Cheers, > alimon > > [1] > http://lists.openembedded.org/pipermail/openembedded-core/ > 2017-February/132494.html > [2] > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ > log/?h=alimon/yp_compatible > This seems like a good start, but this isn’t useful: AssertionError: True is not false : Layer meta-yocto-bsp changed signatures. Presumably this is telling the user it’s modifying things without using the appropriate overrides for machine or distro, but it doesn’t actually tell them that, and displaying the changed checksums isn’t of a great deal of use on its own either, I’d suggest at least capturing the changed variables via bitbake-diffsigs or bitbake -S printdiff. -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to make a recipe MACHINE specific?
On Sat, Feb 11, 2017 at 6:47 PM, Daniel. wrote:
> I have two machines and a recipe that uses MACHINE value to decide, at
> compilation time, proper code to be used. The package (.rpm in my
> case) ends up at tmp/deploy/rpm/cortex-arm-v6-hf-... folder.
>
> I see at my tmp/deploy/rpm/ folder both of my machines folders aside
> of cortex-arm-v6-hf-... folder. How can I make the package goes to the
> specific machine that was used in build instead of the cortex-arm-...
> one?
>
PACKAGE_ARCH = “${MACHINE_ARCH}”
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] suggestions for version controlling multi-layer reproducible builds?
On Mon, Dec 12, 2016 at 8:20 AM, Robert P. J. Day wrote: > if one is building an image for a releasable, commercial product, > and that image involves pulling in numerous layers, then dumping all > sorts of proprietary apps on top of it, what are the possibilities for > how to version number the released images such that, if a client has > an issue, they can identify precisely the state of components that > went into the system they're working with? > > in addition to all of the layers involved in the build, one has to > take into account that, when critical bugs are identified, an updated > RPM might be sent out and applied, whereupon that system's version > number is no longer perfectly accurate. in the end, the state of > someone's running system will be determined by a possibly huge > combination of selected packages, preferred package versions, build > config options, additional user space apps, hot fixes that have been > applied and so on. > > what sort of meaningful "version number" can be applied to something > like that? i'm sure at least a few other people have to be doing > something like that, so i'm open to suggestions. > I don’t think it’s possible for a version number to capture this at all. Better to use a script to capture the state of the system as needed. I.e. write build info to a file on target, and then combine that with a query of the package manager if you use packages for update distribution (though I wouldn’t advise use of packages for update distribution at all, that’s a different discussion :). -- 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] Extracting PV & PR from Makefile at compilation time.
On Wed, Nov 23, 2016 at 6:26 AM, Daniel. wrote: > I have a Makefile with this header > > major = 1 > minor = 0 > patch = 10 > release = -beta > > > Which compilates someting like libmylib.so.1.0.10-beta shared object. > > On recipe I duplicate this information: > PV="1.0.10" > PR="-beta" > > Is there anyway to grab that information from Makefile and setting PV & PR > according to it? At compilation time? So that I only have to change at one > place? > bitbake wants to know pv/pr at parse time, long before the sources have been fetched and unpacked. -- 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] Shallow git clones?
On Thu, Nov 3, 2016 at 6:06 AM, Gary Thomas wrote: > I recall seeing some discussion in the past about using shallow > GIT clones when importing repositories? Is this ever going to > happen? > Mentor has a bitbake patch series to support construction of and fetching of shallow git tarballs. My goal is to get this merged for master, now that morty has been branched, but ran into a unit test failure, so I’m working on that, and on adding some new unit tests for it, before re-submission. The current version is at https://github.com/kergoth/bitbake on the shallow-external branch, if you’re curious. -- 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] why do some openstack layer.conf files add classes to BBFILES?
On Tue, Nov 1, 2016 at 1:57 AM, Robert P. J. Day
wrote:
> just noticed the following property for a bunch of the openstack
> layers at:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-cloud-services/tree/
>
> some of the layer.conf files contain the line:
>
> BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend
> ${LAYERDIR}/classes/*.bbclass"
>
> why is the classes/ directory being appended to BBFILES? i thought the
> purpose of BBPATH was to contain locations of .conf and .bbclass
> files. i'm puzzled by the above.
>
You’re right to be puzzled, as that addition is pointless and will do
nothing useful.
--
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] Two pythons
On Fri, Oct 14, 2016 at 8:54 AM, Burton, Ross wrote: > On 12 October 2016 at 18:58, Michael Callahan > wrote: > >> I just moved my project from Fido to Krogoth and now I have two >> pythons (2.7 and 3). This bumps the size of my image by approximately >> 25%. What would be the most reasonable way to get back to just one >> python? Ideally I'd like a magical setting to get rid of python3 >> because there is no custom code for that one but I suppose with enough >> work I could get all of the python2 code working with python3. >> > > Sadly you can't have a magic option to flip from one to the other as code > isn't compatible. In general master has moved to be 99% Py3 - with smartpm > being the only major python2 recipe left - but I thought Krogoth was still > Py2 by default so shouldn't be in your image by default. > > I suggest you use the usual tools to find out why python2 and python3 are > in your images, and see what you can change to have just one. > Yeah, as Ross says, the usual tools are best there. There are some things you can do to avoid the python dependency for certain recipes, but it has to be dealt with on a case by case basis, and of course depends on what your image is pulling in. For example, https://github.com/openembedded/openembedded-core/compare/master...kergoth:systemtap-python3 splits out systemtap-dtrace into a separate recipe which is pulled in via RRECOMMENDS, so I can use BAD_RECOMMENDATIONS to exclude it for images that don’t need it (dtrace is the only thing in systemtap that needs python3). https://github.com/openembedded/meta-openembedded/compare/master...kergoth:lirc-python-3 does the same for lirc. -- 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] machine specific task
On Wed, Oct 12, 2016 at 4:08 AM, Patrick Ohly
wrote:
> On Wed, 2016-10-12 at 12:58 +0300, Mircea Gliga wrote:
> > According to the docs here
> > http://www.yoctoproject.org/docs/2.1.1/mega-manual/mega-
> manual.html#structure-your-layers
> > one can specify variables that are machine specific, eg
> > KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb". I can't find a reference
> > on how to create a task specific only for a certain machine.
> > Is there some mechanism to add and execute a custom task just for a
> > specific machine, using *addtask* ?
> >
> > As an alternative, I could check the machine name right in the beginning
> > of the do_mycustomtask function, and execute code accordingly, something
> > like (pseudo-code):
> >
> > do_mycustomtask {
> > if {MACHINE} != 'myMachineName'
> > return;
> > # code executing for all other machines
> > [...]
> > }
> > addtask mycustomtask after do_configure before do_compile
>
> It is possible to add the task conditionally in an anonymous Python
> method:
>
> python () {
> if '${MACHINE}' == 'myMachineName':
> bb.build.addtask('do_mycustomtask', 'do_compile', 'do_configure',
> d)
> }
>
> I personally find that nicer than the if check in the function itself,
> because the tasks will only show up in build logs when it actually does
> something.
Good idea, but use d.getVar() :)
--
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] 'bb' utility fails on attempt to import 'commands' module
On Fri, Sep 9, 2016 at 8:12 AM, Siegel, Jeffrey (Nokia - US) < jeffrey.sie...@nokia.com> wrote: > Thanks, this fixed the issue. After checking the output of ‘git log’, I > picked this commit: > > git checkout d458b3 > Sorry about that, I’ll see about creating stable release branches. -- 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] Regarding backslash in bblayers.conf file
On Thu, Jun 23, 2016 at 7:12 AM, Leonardo Sandoval < leonardo.sandoval.gonza...@linux.intel.com> wrote: > This looks to be a bug. System should either accept path names with or > without trailing '/'. Please file a bug on bugzilla.yoctoproject.org > Yeah, we likely need to sanitize that path so it aligns with the expected value of BBFILES. -- 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] [OE-core] Yocto Project Status WW25
On Fri, Jun 17, 2016 at 2:42 PM, Christopher Larson wrote: > On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K < > stephen.k.jol...@intel.com> wrote: > >> ·There is a multilib issue related to the layout of the host >> libraries leaking into python’s build process which we’re struggling to >> debug > > > Could I get some details on this? I've seen something like this where > cmake and automake are relying on sys.lib from python3-native/python-native > to determine the sitepackages directory, is that the behavior others are > hitting? So python modules end up in /usr/lib/ rather than /usr/lib64/, for > example? > > If that's the issue in question, the issue is the mismatch between the > native sys.lib and target. We already patch automake to fall back to using > our libdir + python version to determine the path, but only if it wasn't > able to use sys.lib to do so. If we change that to always use libdir+python > version, it should fix the automake packages. Then we might need to patch > FindPythonLibs in cmake to do the same. I'm testing the automake change > locally now. > Hmm, nevermind, seems that was fixed in oe-core already, huzzah :) -- 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] [OE-core] Yocto Project Status WW25
On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K < stephen.k.jol...@intel.com> wrote: > ·There is a multilib issue related to the layout of the host > libraries leaking into python’s build process which we’re struggling to > debug Could I get some details on this? I've seen something like this where cmake and automake are relying on sys.lib from python3-native/python-native to determine the sitepackages directory, is that the behavior others are hitting? So python modules end up in /usr/lib/ rather than /usr/lib64/, for example? If that's the issue in question, the issue is the mismatch between the native sys.lib and target. We already patch automake to fall back to using our libdir + python version to determine the path, but only if it wasn't able to use sys.lib to do so. If we change that to always use libdir+python version, it should fix the automake packages. Then we might need to patch FindPythonLibs in cmake to do the same. I'm testing the automake change locally now. -- 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
[yocto] [meta-qt3][PATCH] qt-x11-free: obey LDFLAGS
From: Christopher Larson
We need to obey LDFLAGS to get the correct hash style for external toolchains.
The ideal way to deal with this would be for the build to be like the qt4
build, obeying the OE_QMAKE_ variables as defined in qmake_base, but that's
not going to happen just now. The next best thing would be to pass '${CXX}
${LDFLAGS}' as the 'LINK' variable, but the plugin builds aren't using LINK,
so this resorts to brute force and appends LDFLAGS to CXX.
We'll eventually bump LSB support and drop qt3 anyway.
Signed-off-by: Christopher Larson
---
recipes-qt3/qt3/qt-x11-free-common.inc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/recipes-qt3/qt3/qt-x11-free-common.inc
b/recipes-qt3/qt3/qt-x11-free-common.inc
index a788cbe..6d23848 100644
--- a/recipes-qt3/qt3/qt-x11-free-common.inc
+++ b/recipes-qt3/qt3/qt-x11-free-common.inc
@@ -20,10 +20,16 @@ QT_CONFIG_FLAGS = "-release -shared -qt-zlib -no-nas-sound
-no-sm -qt-libpng -no
EXTRA_ENV = 'QMAKE="${OE_QMAKE_QMAKE} -after INCPATH+=${STAGING_INCDIR} \
INCPATH+=${STAGING_INCDIR}/freetype2 LIBS+=-L${STAGING_LIBDIR}" \
- QMAKESPEC="${QMAKESPEC}" LINK="${CXX}
-Wl,-rpath-link,${STAGING_LIBDIR}" \
+ QMAKESPEC="${QMAKESPEC}" LINK="${CXX}" \
AR="${TARGET_PREFIX}ar cqs" \
MOC="${OE_QMAKE_MOC}" UIC="${OE_QMAKE_UIC}" MAKE="make -e"'
+# This isn't an ideal fix, but not everything is obeying the 'LINK' variable,
+# and the qt3 build isn't using a qmake.conf that obeys the OE_QMAKE_
+# variables. Rather than substantially reworking the qt3 build at this time,
+# just hack it. We'll eventually bump LSB support and drop qt3 anyway.
+CXX += "${LDFLAGS}"
+
do_configure() {
if [ ! -L ${QMAKE_MKSPEC_PATH}/${TARGET_OS}-oe-g++ ]; then
ln -sf ${QMAKE_MKSPEC_PATH}/linux-g++
${QMAKE_MKSPEC_PATH}/${TARGET_OS}-oe-g++
--
2.8.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dynamic PV version in recipe
On Thu, Jun 16, 2016 at 8:11 AM, Marco Garzola wrote: > I got a problem, maybe someone could help me.I have a recipe that takes > from a jenkins server via json API a binary file with a version that i know > only after do_compile task. the question is : is there any way to tell > bitbake that $PV should change dynamically , maybe in do_install task ? My > goal is to create the package with the revision read from jenkins. PV has to be set at parse time, up front, so bitbake can use it in stamps to help determine when tasks need to be run, as well as including it in WORKDIR and whatnot. If all you want is to change the version in the emitted binary packages, you can dynamically set PKGV, i.e. add a prefunc before do_package which reads the PKGV. Of course, making sure it re-runs the appropriate tasks when that value changes is rather less trivial, since bitbake generates signatures/checksums at parse time. Alternatively, would it be possible to contact the server via the json API at parse time as long as BB_NO_NETWORK isn't set? Of course, unless there's a way to support the BB_NO_NETWORK case, that would be problematic as well. -- 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] Mounting USB drives on a "read-only-rootfs" based system
Afaik usb storage is already automounted by udev on /run/media/, so there's no need to use /media for that purpose. On Mon, Jun 13, 2016 at 2:22 PM, Jeffrey D Boyer wrote: > Hello, > > > > New to the list here, so I’m sorry if this question has been asked before, > but I couldn’t find a direct answer to it. > > > > I have a yocto image that was built using the following bb script line: > IMAGE_FEATURES += " read-only-rootfs". > > > > As this image eventually resides on a static flash device, it must be > read-only. However, the system hardware supports removable media (SD card > and USB drives), and I’d like to be able to mount and write to those > removable drives / partitions for data logging purposes. What needs to be > done in order to make the /media directory auto-mountable when a > “read-only” image is specified by the build script? > > > > Thanks. > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- 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] Python module from git repo recipe
On Thu, Jun 9, 2016 at 9:03 AM, Burton, Ross wrote:
> On 9 June 2016 at 16:58, Edward Wingate wrote:
>
>> Does anyone have an example of a recipe that installs a python module
>> from a git repo? There is a python module that is not regularly
>> updated on PyPI, but its git repo is up to date. All the examples of
>> python module recipes I can find uses PyPI:
>>
>
> Just change the SRC_URI to a git URI, that's all you need to do.
And S to ${WORKDIR}/git, set SRCREV, and depending on whether you're
tracking a branch or a tag, add SRCPV to PV :)
--
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] New warning
On Tue, Jun 7, 2016 at 7:55 PM, Gary Thomas wrote: > I'm seeing a lot of these: > NOTE: /local/poky-cutting-edge/meta-xyz/.../some-pkg_2.38.0.bb: > base_contains is deprecated, please use bb.utils.contains instead. > > This is all well and good and I'll clean them up as I go. That > said, why is the same NOTE printed [at least] twice for every recipe > even when the file contains 'base_contains' only once? > I haven't checked the code, but the most likely explanation is the error is a parse or expansion time one, and bitbake parses the recipe anew when running each task, after the up front parse which is used to generate the runqueue. *shrug*. It's a downside of showing messages in anything but task execution context. -- 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] How to execute a git submodule init/update?
Use gitsm:// in your SRC_URI rather than git://. On Mon, Jun 6, 2016 at 3:06 AM, Burton, Ross wrote: > > On 6 June 2016 at 10:39, wrote: > >> I have a git source which need some submodules. For that I need to >> execute "git submodule init" and "git submodule update". Any idea how to do >> it in a comon way? >> > > Use the gitsm: fetcher, which will do that for you. > > Ross > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- 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] Retrieve SRCREV variable value outside of a specific recipe (not modifying it)
On Tue, May 24, 2016 at 7:32 AM, Michael Hu wrote:
> Hi,
>
> My goal is to pull recipe's SRCREV variable into a top level *.bbclass
> file. I understand we can use SRCREV_pn- to modify the
> revision on the fly outside of recipe in configuration files but when I
> print out SRCREV information using ${SRCREV_pn-recipename} all I got back
> is the recipe name instead of SREREV value for that specific recipe.
>
> Is there a way to retrieve SREREV value outside of recipe?
>
One recipe cannot access metadata from another, nor can config metadata
access recipe metadata, by design. I'd recommend enabling buildhistory and
using the buildhistory-collect-srcrevs script, which dumps SRCREV_pn- lines
for recipes, for use in a .conf/.inc/.bbclass.
--
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] What version of Jethro do we get with - git clone -b jethro git://git.yoctoproject.org/poky.git ?
On Tue, May 3, 2016 at 3:31 PM, Mark T wrote: > Hi Christopher, > > Thanks. What is the command option to specify the tag and is there a list > or tags available ? > https://git-scm.com/book/en/v2 -- 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] What version of Jethro do we get with - git clone -b jethro git://git.yoctoproject.org/poky.git ?
On Tue, May 3, 2016 at 3:18 PM, Mark T wrote: > Hi, > > When we started working with Yocto we cloned via - > > git clone -b jethro git://git.yoctoproject.org/poky.git mydir/ > cd mydir > git clone git://git.yoctoproject.org/meta-intel -b jethro > > If we do the same a month or so later do we get the same version ? we > suspect not the distro version has changed. > > Is there a way we can clone the same version all the time ? > > Secondly, what should be considered a stable version to clone ? > The release branch will get bug fixes and security updates after the release. If you don't want it to change at all, use the tag or tarballs, not the branch. -- 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] Dumping (inferred) do_task[vardeps] for some do_task
On Wed, Apr 27, 2016 at 9:11 AM, Ulf Magnusson wrote: > I'm trying to get a feel for how BitBake infers task dependencies. The > easiest way (but I'm open to suggestions) seems to be to dump the > value of do_task[vardeps] for a particular recipe after the inferred > dependencies are added. > > What's a good way to dump do_task[vardeps]? I tried using getVarFlag() > in an anonymous Python function, but it only catches dependencies > explicitly added to do_task[vardeps]. Maybe [vardeps] is never > assigned the complete set of dependencies internally, or maybe the > anonymous Python function is called too early. > That's correct, the full list is not stored in the vardeps. generate_dependencies() in bitbake/lib/bb/data.py also looked > promising, but maybe there's a better places further up the callstack. > That is a reasonable place in the code, yes. You can inspect a certain amount of information in the signature data files, but I'm not sure it drills down to the level you desire. My 'bb' tool's 'show' subcommand can show not just a variable but also its dependencies, perhaps that might be of use? I haven't touched it in ages, but in theory it should work. -- 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] what does ${libdir} refer to?
No, libdir is /usr/lib on the target. We never write to the host system
outside the build directory. do_install installs a lib into ${D}${libdir},
and then the contents of ${D} get split up into individual binary packages,
and those packages are then installed in a root filesystem and archived
into a rootfs image.
On Thu, Apr 21, 2016 at 8:53 AM 杜 昊 wrote:
> Hello there!
>
> I have a question about the absolute path of ${libdir}.
>
> for example in poco recipe:
>
>
> here is:
>
> PACKAGES += "${PN}-dev ${PN}-staticdev"
> FILES_${PN}-dev = "${includedir} ${libdir}/libPoco*.so ${libdir}/cmake"
> FILES_${PN}-staticdev = "${libdir}/libPoco*.a"
>
>
> i have searched for the yocto reference. In meta/conf/bitbake.conf we can
> see
>
>
> baselib = "${BASELIB}"
> BASELIB = "lib"
>
> # Path prefixes
> export exec_prefix = "/usr"
>
> # Architecture dependent paths
> export bindir = "${exec_prefix}/bin"
> export libdir = "${exec_prefix}/${baselib}"
>
> Does this mean that ${libdir} =/usr/lib in my host machine. But i
> can't find such libraries(libPoco*.so) in my host(ubuntu 14.04) under
> /usr/lib
> I think i misunderstand the absolute path of ${libdir}. Who can tell me
> the right meaning of this. Thanks for helping.
>
> regards
> hao du
>
>
> --
> ___
> 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] [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases
On Mon, Apr 18, 2016 at 5:50 PM Khem Raj wrote: > > On Apr 18, 2016 3:51 PM, "Richard Purdie" < > richard.pur...@linuxfoundation.org> wrote: > > > > On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote: > > > Can we have a possibility to select field like "affected version" > > > and have it such that multiple versions can be specified > > > > That doesn't really allow us to mark version X as merged and version Y > > as pending review though and as I understand it, that is the real issue > > atm :/. > > May be bugzilla can be programmed to have such triggers. Having separate > bug is not a good looking solution > I'd agree that it's not ideal, but it's definitely a *common* solution in many bug tracking systems, since it's usually the only way to maintain separate states for each version. I know I've seen it done that way in bugzilla, jira, and others over the years. There may be something better out there, and if we can find it, great, but I think separate issues is better than not addressing the issue at all, but only if the tooling is good enough to help reduce overhead on the part of the devs dealing with it. Issue tracker overhead gets pretty frustrating at times. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] environment setup script
On Thu, Apr 14, 2016 at 10:39 AM Sid Price wrote: > Hello, I am new to Yocto and relatively new to Linux. I am working my way > through the “Getting Started” guide and I have met a problem. I am trying > to run the “environment-setup …” script for the arm platform. First I > notice that when I list the folder /opt/poky/2.0.1 I see the scripts but > they are not shown as executable. Is this correct? When I try the following > command I am told “Permission denied”: > > > > /opt/poky/2.0.1/environment-setup-armv5e-poky-linux-gnueabi > > > > If I use sudo I see “command not found” > The setup script has to be *sourced* into your shell, not run. The instructions most likely included a leading '.' but you missed it. Either type '. /opt/poky/2.0.1/environment-setup-armv5e-poky-linux-gnueabi' or 'source /opt/poky/2.0.1/environment-setup-armv5e-poky-linux-gnueabi' in your shell. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installing the SDKs made with meta-mingw
On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier
wrote:
> I've successfully built a Canadian-cross SDK using the meta-mingw layer.
> Very nice!
>
> Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE} is
> set to a MinGW host, though, the resulting SDK is not encapsulated into the
> self-extracting tarball and the corresponding relocation logic (
> relocate_sdk.py and so forth) is omitted.
>
> Any suggestions on how to do the last-mile work to use the SDK on Windows?
> Or perhaps nothing is needed at all, except adjusting the prefixes built
> into environment-setup-? Although that would be nice, I think at
> least some installation-time adjustment is necessary though; when I do:
>
> arm-poky-linux-gnueabi-gcc -o foo foo.c
> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>
> , the following happens during linking:
>
> ld.exe: cannot find /lib/libc.so.6 inside
> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>
Mark Hatle's branch switches to batch files for environment setup and
whatnot. I don't know if it addresses the reloc issue or not, but it's a
substantial improvement over master. See
https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
--
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] Installing the SDKs made with meta-mingw
On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier wrote:
> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson
> wrote:
>
>>
>>
>> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson
>> wrote:
>>
>>> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier
>>> wrote:
>>>
>>>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson <
>>>>> clar...@kergoth.com> wrote:
>>>>>
>>>>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier >>>>> > wrote:
>>>>>>
>>>>>>> I've successfully built a Canadian-cross SDK using the meta-mingw
>>>>>>> layer. Very nice!
>>>>>>>
>>>>>>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when
>>>>>>> ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not
>>>>>>> encapsulated into the self-extracting tarball and the corresponding
>>>>>>> relocation logic (relocate_sdk.py and so forth) is omitted.
>>>>>>>
>>>>>>> Any suggestions on how to do the last-mile work to use the SDK on
>>>>>>> Windows? Or perhaps nothing is needed at all, except adjusting the
>>>>>>> prefixes
>>>>>>> built into environment-setup-? Although that would be nice, I
>>>>>>> think at least some installation-time adjustment is necessary though;
>>>>>>> when
>>>>>>> I do:
>>>>>>>
>>>>>>> arm-poky-linux-gnueabi-gcc -o foo foo.c
>>>>>>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>>>>>
>>>>>>> , the following happens during linking:
>>>>>>>
>>>>>>> ld.exe: cannot find /lib/libc.so.6 inside
>>>>>>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>>>>>
>>>>>>
>>>>> As it turns out, the immediate error here was simply that libc.so.6
>>>>> did not exist, so ld.exe was telling the truth in this case. The symbolic
>>>>> links stored in the SDK tarball that would have created libc.so.6 aren't
>>>>> meaningful on Windows, so tar just ignores them when unpacking. Presumably
>>>>> some fancier handling of the tarball unpacking to simulate symlinks by
>>>>> making copies of the pointed-to file would cure this.
>>>>>
>>>>>
>>>>>>
>>>>>> Mark Hatle's branch switches to batch files for environment setup and
>>>>>> whatnot. I don't know if it addresses the reloc issue or not, but it's a
>>>>>> substantial improvement over master. See
>>>>>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>>>>>>
>>>>>
>>>>> Thanks, I'll try that.
>>>>>
>>>>
>>>> Mark Hatle's branch does work much more nicely for that. There's still
>>>> the problem of what to do with the symlink from the SDK tarballs. Are there
>>>> any regular users of these mingw SDKs out there who know the right
>>>> expectation on how to extract them?
>>>>
>>>
>>> tar has an option to resolve symlinks to the files, I'd expect you could
>>> just add that to the variable for the tar options for the sdk, and it'd
>>> just duplicate the symlinks. You'll have extra files, so it'd be larger,
>>> but at least it'd be functional.
>>>
>>
>> Erm, I meant duplicate the files, not the symlinks :) The symlinks would
>> be resolved to files. Clearly I haven't had enough caffeine yet today.
>>
>
> Thanks.
>
> If you're thinking of "tar -h -xf ... ", I'd given that a try prior to my
> previous message. It doesn't seem to have any effect on the outcome (at
> least, for the copy of 'tar' bundled into my installation of MinGW and
> MSys).
>
No, I was thinking of changing the tar *creation* rather than extraction,
so the symlinks are followed and stored as files in the tarball.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installing the SDKs made with meta-mingw
On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson
wrote:
> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier
> wrote:
>
>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson >> > wrote:
>>>
>>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier
>>>> wrote:
>>>>
>>>>> I've successfully built a Canadian-cross SDK using the meta-mingw
>>>>> layer. Very nice!
>>>>>
>>>>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when
>>>>> ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not
>>>>> encapsulated into the self-extracting tarball and the corresponding
>>>>> relocation logic (relocate_sdk.py and so forth) is omitted.
>>>>>
>>>>> Any suggestions on how to do the last-mile work to use the SDK on
>>>>> Windows? Or perhaps nothing is needed at all, except adjusting the
>>>>> prefixes
>>>>> built into environment-setup-? Although that would be nice, I
>>>>> think at least some installation-time adjustment is necessary though; when
>>>>> I do:
>>>>>
>>>>> arm-poky-linux-gnueabi-gcc -o foo foo.c
>>>>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>>>
>>>>> , the following happens during linking:
>>>>>
>>>>> ld.exe: cannot find /lib/libc.so.6 inside
>>>>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>>>
>>>>
>>> As it turns out, the immediate error here was simply that libc.so.6 did
>>> not exist, so ld.exe was telling the truth in this case. The symbolic links
>>> stored in the SDK tarball that would have created libc.so.6 aren't
>>> meaningful on Windows, so tar just ignores them when unpacking. Presumably
>>> some fancier handling of the tarball unpacking to simulate symlinks by
>>> making copies of the pointed-to file would cure this.
>>>
>>>
>>>>
>>>> Mark Hatle's branch switches to batch files for environment setup and
>>>> whatnot. I don't know if it addresses the reloc issue or not, but it's a
>>>> substantial improvement over master. See
>>>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>>>>
>>>
>>> Thanks, I'll try that.
>>>
>>
>> Mark Hatle's branch does work much more nicely for that. There's still
>> the problem of what to do with the symlink from the SDK tarballs. Are there
>> any regular users of these mingw SDKs out there who know the right
>> expectation on how to extract them?
>>
>
> tar has an option to resolve symlinks to the files, I'd expect you could
> just add that to the variable for the tar options for the sdk, and it'd
> just duplicate the symlinks. You'll have extra files, so it'd be larger,
> but at least it'd be functional.
>
Erm, I meant duplicate the files, not the symlinks :) The symlinks would be
resolved to files. Clearly I haven't had enough caffeine yet today.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installing the SDKs made with meta-mingw
On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier wrote:
> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier
> wrote:
>
>>
>>
>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson
>> wrote:
>>
>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier
>>> wrote:
>>>
>>>> I've successfully built a Canadian-cross SDK using the meta-mingw
>>>> layer. Very nice!
>>>>
>>>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE}
>>>> is set to a MinGW host, though, the resulting SDK is not encapsulated into
>>>> the self-extracting tarball and the corresponding relocation logic (
>>>> relocate_sdk.py and so forth) is omitted.
>>>>
>>>> Any suggestions on how to do the last-mile work to use the SDK on
>>>> Windows? Or perhaps nothing is needed at all, except adjusting the prefixes
>>>> built into environment-setup-? Although that would be nice, I
>>>> think at least some installation-time adjustment is necessary though; when
>>>> I do:
>>>>
>>>> arm-poky-linux-gnueabi-gcc -o foo foo.c
>>>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>>
>>>> , the following happens during linking:
>>>>
>>>> ld.exe: cannot find /lib/libc.so.6 inside
>>>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>>
>>>
>> As it turns out, the immediate error here was simply that libc.so.6 did
>> not exist, so ld.exe was telling the truth in this case. The symbolic links
>> stored in the SDK tarball that would have created libc.so.6 aren't
>> meaningful on Windows, so tar just ignores them when unpacking. Presumably
>> some fancier handling of the tarball unpacking to simulate symlinks by
>> making copies of the pointed-to file would cure this.
>>
>>
>>>
>>> Mark Hatle's branch switches to batch files for environment setup and
>>> whatnot. I don't know if it addresses the reloc issue or not, but it's a
>>> substantial improvement over master. See
>>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>>>
>>
>> Thanks, I'll try that.
>>
>
> Mark Hatle's branch does work much more nicely for that. There's still the
> problem of what to do with the symlink from the SDK tarballs. Are there any
> regular users of these mingw SDKs out there who know the right expectation
> on how to extract them?
>
tar has an option to resolve symlinks to the files, I'd expect you could
just add that to the variable for the tar options for the sdk, and it'd
just duplicate the symlinks. You'll have extra files, so it'd be larger,
but at least it'd be functional.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Master or master-next?
On Tue, Mar 15, 2016 at 3:56 PM Chris Tapp wrote: > Should I use master or master-next to track 2.1 release progress? > master-next is rebased. I wouldn't recommend using it unless you need to test something specific which is on that branch and isn't yet on master, otherwise I'd wait for changes to hit master. master is volatile enough at times ;) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Starting Pulseaudio automatically
On Tue, Mar 15, 2016 at 2:06 PM Chris Tapp wrote: > I’ve got an X11 application which uses Pulseaudio. Everything works as > expected when built under “daisy” (Pulseaudio 5), but the same system built > under “jethro” (Pulseaudio 6) fails as Pulseaudio doesn’t start > automatically. > > It looks like this is down to a difference in start-pulseaudio-x11. The > following is present in “daisy”: > >pulseaudio --start > > but this isn’t there in “jethro”. Adding this line makes Pulseaudio start > as expected, allowing the application to run. > > Why was this removed in Pulseaudio 6? Is it supposed to be started another > way? > Pulseaudio will autostart when the apps use it, on demand, nowadays. There should be no need to start it in a startup script, afaik. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Two or more _append()'s on same task
On Mon, Mar 14, 2016 at 10:56 AM Daniel. wrote: > Hi all, > > I was wondering how OE/Yocto would respond if the same task is appended > twice. > > If I have a .bbclass that already creates a do_install_append() and I > inherit this class at my recipe, will my do_install_append be aplied: > > - Before .bbclass do_install_append() > - After it > - Will not be aplied > > Now if I declare my do_install_append before the inherit line, will it > be aplied before the .bbclass's do_install_append? > > How Yocto handles this _append stuff? > Append/prepend are cumulative, just like +=/+=/.=/=.. *all* appends are applied, in the order they're seen while parsing. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New message
On Mon, Mar 14, 2016 at 5:50 AM Burton, Ross wrote: > On 14 March 2016 at 03:10, Gary Thomas wrote: > >> I just started a new build and saw a message that's new to me: >> NOTE: Fetching uninative binary shim from >> http://downloads.yoctoproject.org/releases/uninative/0.95/x86_64-nativesdk-libc.tar.bz2;md5sum=4b6fb2106c2f18b8f9c8ac67e1cf9e57 >> >> * What is this about? >> > > You're using the poky distribution which for build performance uses > uninative (from 477b8fb), which means that instead of building native > dependencies per-host-distribution there's a static libc which is built > against to enable native binaries to be host-agnostic. > To clarify, I believe 'static' here is meant to mean fixed, not a static library :) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Strange build dependency
On Mon, Mar 14, 2016 at 6:55 AM Martin Jansa wrote: > On Mon, Mar 14, 2016 at 02:44:58PM +0100, Gary Thomas wrote: > > On 03/14/2016 01:51 PM, Gary Thomas wrote: > > > On 03/14/2016 01:46 PM, Burton, Ross wrote: > > >> > > >> On 14 March 2016 at 12:41, Gary Thomas g...@mlbassoc.com>> wrote: > > >> > > >> How can I find out what's going on here? > > >> > > >> > > >> bitbake-whatchanged is generally helpful here. Do a build in one > configuration, switch to the other, run > > >> bitbake-whatchanged. It will identify the hashes that have changed > and try and chase them down. > > >> > > >> That said perl is quite a deep recipe so rebuilding that will > certainly bubble up the tree causing all sorts of rebuilds. > > > > > > Thanks, I'll give this a try. > > > > > > > I've run this and I still don't have a clue. Here's what I got. Maybe > > you can explain what I'm seeing? > > You can also create snapshot before and after the change with > scripts/sstate-diff-machines.sh and compare the signatures manually. > bitbake -S printdiff is a useful option as well. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Howto change the default shell in yocto?
The default *system* shell (/bin/sh) or the default shell for users, or for root? Folks often conflate them, but they're not the same. On Fri, Mar 4, 2016 at 7:01 AM Oliver Graute wrote: > Hello, > > how can I change the default shell on the yocto target from bash to > another shell like dash? > > is there a variable for local.conf? or do I need to adapt my passwd for > every user? > > Best Regards, > > Oliver > -- > ___ > 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] [OE-core] Yocto Project Status WW09
This is the sort of case where it'd be nice if bitbake provided a plugin mechanism, pure python, no metadata parsing. Something to think about in the long term.. On Fri, Feb 26, 2016 at 1:59 PM Burton, Ross wrote: > > On 26 February 2016 at 20:16, Philip Balister wrote: > >> I must admit, I'm surprised this is tricky. I look forward to seeing >> what needs doing. Hopefully, it shows me things I can avoid in my work. >> > > The moral of the story is don't rename layers if you want to maintain a > semblance of migration. Renaming meta-yocto to meta-poky means the > bblayers.conf is invalid, so the migration code can't run because bitbake > aborts too early. > > Ross > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] which package/recipe produces "ss" utility
On Thu, Feb 18, 2016 at 9:48 PM Vivek Per wrote: > Does any one know which package produces "ss" utility in yocto. i > tried iproute2 reciepe which is not present. > iproute2 is in oe-core, look again. http://layers.openembedded.org/layerindex/recipe/5516/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto/Poky with external linaro toolchain
On Fri, Feb 12, 2016 at 2:47 AM Thomas Kaufmann wrote: > Hi Christopher > > > > thanks for this hint, this prevented a lot of packages from being built. > > However I still face an additional issue. in the last step of > do_populate_sdk, when the sdk is actually supposed to be put together. > > I get this output: > > > > Collected errors: > > * satisfy_dependencies_for: Cannot satisfy the following dependencies for > packagegroup-core-standalone-sdk-target: > > *libc6 (= 2015.08-r0) * glibc-utils * > > * opkg_install_cmd: Cannot install package > packagegroup-core-standalone-sdk-target. > > > > how can it be, that everything is built correctly and in the end there is > a dependency missing? > > I tried altering my LIBC_DEPENDENCIES, but with no success so far. > > I am also using tclibc-external-linaro-toolchain.inc from > > > http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-extras/conf/distro/include/tclibc-external-linaro-toolchain.inc;hb=HEAD > This looks like it's specific to your linaro toolchain bits. I'd recommend contacting the linaro or arago folks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Inline Python function name define
def foo(d):
# Do something
FOO = "${@foo(d)}"
On Wed, Feb 10, 2016 at 12:02 PM Xi Zhou Zhou
wrote:
> Hi,
>
> I want to manipulate a variable with inline python function in a recipe.
> The code is something like this.
>
> python newpv() {
> return 999
> }
>
> PV = "${@newpv()}"
>
>
> The error is "name 'newpv' is not defined"
>
> ERROR: ExpansionError during parsing /home/joelz/poky/build/
> ../meta-test/recipes-bsp/mytest/mytest.bb: Failure expanding variable PV,
> expression was ${@newpv()} which triggered exception NameError: name
> 'newpv' is not defined
>
>
> What's the right way to create inline python function in Yocto recipe?
>
>
> Thanks,
> Joel
> --
> ___
> 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] Yocto/Poky with external linaro toolchain
https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/include/drop-toolchain-from-sdk.inc may be of interest to you. On Wed, Feb 10, 2016 at 9:01 AM Thomas Kaufmann wrote: > Hi > > > > I started porting an existing linux system to the latest yocto base. The > hardware TI am 335x based. > > I want to use the external linaro toolchains. Since I use an existing 3.2 > linux kernel as well as an older u-boot, I created a own machine and distro > configuration. I succeed to build and run the target, so far so good. > > > > To incorporate the external toolchains I added > > > > TCMODE = "external-linaro" > > EXTERNAL_TOOLCHAIN = > "//gcc-linaro-5.1-2015.08-x86_64_arm-linux-gnueabihf" > > > > to the local.conf file and > > > > meta-linaro/meta-linaro-toolchain > > > > to the BBLAYERS in bblayers.conf. meta-linaro was cloned using git. > > For my "legacy" packages I adjust "EXTERNAL_TOOLCHAIN" to a gcc-4.9 > version, this seems to work and everything compiles. > > > > Now my next step is to create an SDK distribution. > > When I do do_populate_sdk with bitbake for my image, however the process > seems to compile a new cross compiler for the target as well as various > qemu things and also newer kernel releases. > > > > Is this the preferred way to integrate the linaro toolchain into poky? Can > anybody share their experience? I find various presentations and snippets > about this topic, but nothing is complete. > > How do I create a SDK distribution which does not feature any QEMU (I want > to deploy to target hardware) and uses the existing prebuilt toolchain? > Build host and target sdk host would be x86_64. > > > > Any recommendations are welcome. > > > > regards Thomas Kaufmann > -- > ___ > 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] autorev and shared-state issues
On Tue, Jan 26, 2016 at 12:03 PM, Luke (Lucas) Starrett <
lstar...@broadcom.com> wrote:
> I’m struggling with a behavior where even though we have a SRC_URI set to
> ${AUTOREV}, changes to the underlying git repository are not being seen on
> subsequent builds. I have reproduced this behavior across both a kernel
> and u-boot recipe, so it seems like a generic problem.
>
>
>
> In general, how does autorev behave when used in conjunction with shared
> state? If the underlying git HEAD moves, shouldn’t this be seen and
> prevent re-use of prebuilt content in shared state?
>
>
>
> We are currently based on the Fido/1.8.1 tag for this exercise.
>
My guess is you didn't add SRCPV to your PV, so changes to SRCREV aren't
changing PV, and do_fetch's checksum isn't changing.
--
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] Fixing packaging errors
On Thu, Jan 21, 2016 at 11:57 PM, Gary Thomas wrote: > ERROR: QA Issue: non -dev/-dbg/nativesdk- package contains symlink .so: > graphviz path > 'work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/graphviz/2.38.0-r0/packages-split/graphviz/usr/lib/graphviz/libgvplugin_gd.so' > [dev-so] > > Looking at the installed image, I see: > > $ ls -l > tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/graphviz/2.38.0-r0/image/usr/lib/graphviz/ > total 3016 > -rwxr-xr-x 3 gthomas gthomas1107 Jan 22 07:48 libgvplugin_core.la > lrwxrwxrwx 1 gthomas gthomas 25 Jan 22 07:48 libgvplugin_core.so -> > libgvplugin_core.so.6.0.0 > lrwxrwxrwx 1 gthomas gthomas 25 Jan 22 07:48 libgvplugin_core.so.6 -> > libgvplugin_core.so.6.0.0 > -rwxr-xr-x 1 gthomas gthomas 341780 Jan 22 07:48 > libgvplugin_core.so.6.0.0 > -rwxr-xr-x 3 gthomas gthomas1143 Jan 22 07:48 > libgvplugin_dot_layout.la > lrwxrwxrwx 1 gthomas gthomas 31 Jan 22 07:48 > libgvplugin_dot_layout.so -> libgvplugin_dot_layout.so.6.0.0 > lrwxrwxrwx 1 gthomas gthomas 31 Jan 22 07:48 > libgvplugin_dot_layout.so.6 -> libgvplugin_dot_layout.so.6.0.0 > -rwxr-xr-x 1 gthomas gthomas 616340 Jan 22 07:48 > libgvplugin_dot_layout.so.6.0.0 > -rwxr-xr-x 3 gthomas gthomas1451 Jan 22 07:48 libgvplugin_gd.la > lrwxrwxrwx 1 gthomas gthomas 23 Jan 22 07:48 libgvplugin_gd.so -> > libgvplugin_gd.so.6.0.0 > lrwxrwxrwx 1 gthomas gthomas 23 Jan 22 07:48 libgvplugin_gd.so.6 -> > libgvplugin_gd.so.6.0.0 > -rwxr-xr-x 1 gthomas gthomas 141248 Jan 22 07:48 libgvplugin_gd.so.6.0.0 > -rwxr-xr-x 3 gthomas gthomas1155 Jan 22 07:48 > libgvplugin_neato_layout.la > lrwxrwxrwx 1 gthomas gthomas 33 Jan 22 07:48 > libgvplugin_neato_layout.so -> libgvplugin_neato_layout.so.6.0.0 > lrwxrwxrwx 1 gthomas gthomas 33 Jan 22 07:48 > libgvplugin_neato_layout.so.6 -> libgvplugin_neato_layout.so.6.0.0 > -rwxr-xr-x 1 gthomas gthomas 1949008 Jan 22 07:48 > libgvplugin_neato_layout.so.6.0.0 > -rwxr-xr-x 3 gthomas gthomas2504 Jan 22 07:48 libgvplugin_rsvg.la > lrwxrwxrwx 1 gthomas gthomas 25 Jan 22 07:48 libgvplugin_rsvg.so -> > libgvplugin_rsvg.so.6.0.0 > lrwxrwxrwx 1 gthomas gthomas 25 Jan 22 07:48 libgvplugin_rsvg.so.6 -> > libgvplugin_rsvg.so.6.0.0 > -rwxr-xr-x 1 gthomas gthomas 10764 Jan 22 07:48 > libgvplugin_rsvg.so.6.0.0 > > I have two questions about this. > * What is wrong with the setup of the libgvplugin_gd library > and how can I fix it? > Generally the .so for a normal library, non-plugin, is only required for development. In this case, it's a plugin, so it'll be dlopen'd, so I expect you could just opt-out of the QA check in this case. > * All the rest of the libraries are set up the same. Why don't > they get the same error? > IIRC there was a bug in the package qa bits which caused later messages to suppress earlier due to teh use of a dictionary for the messages (the wrong structure for this, no idea why it was done that way). There have been one or more patches on teh list for this recently. -- 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] New warning(s)
On Tue, Nov 17, 2015 at 11:02 AM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > On Tuesday 17 November 2015 08:39:55 Christopher Larson wrote: > > On Tue, Nov 17, 2015 at 8:33 AM, Gary Thomas wrote: > > > When I run bitbake using layers that are not GIT repos, I'm > > > > > > now getting a lot of messages like this: > > > fatal: Not a git repository (or any parent up to mount point /raid) > > > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not > > > > > > set). > > > > > > This seems to be new (I've built from such trees many times > > > before with no such messages) and it hardly seems "fatal". > > > The messages apparently are coming from 'git' (I tested with > > > git version 1.9.1 and 1.7.11) > > > > > > Why the change? > > > > I believe we need https://github.com/kergoth/meta-mentor/commit/2125799 > > applied to oe-core, haven't had a chance to submit it yet, but it looked > to > > me like an accidental loss of the stderr capture/suppression when the > > metadata_scm functions were reworked recently. > > I already sent a patch for this, it hasn't been applied yet: > > http://patchwork.openembedded.org/patch/107081/ Ah, excellent. Thanks. -- 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] New warning(s)
On Tue, Nov 17, 2015 at 8:33 AM, Gary Thomas wrote: > When I run bitbake using layers that are not GIT repos, I'm > now getting a lot of messages like this: > fatal: Not a git repository (or any parent up to mount point /raid) > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not > set). > > This seems to be new (I've built from such trees many times > before with no such messages) and it hardly seems "fatal". > The messages apparently are coming from 'git' (I tested with > git version 1.9.1 and 1.7.11) > > Why the change? > I believe we need https://github.com/kergoth/meta-mentor/commit/2125799 applied to oe-core, haven't had a chance to submit it yet, but it looked to me like an accidental loss of the stderr capture/suppression when the metadata_scm functions were reworked recently. -- 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] [OE-core] Fwd: Welcome to the "Openemebdded-architecture" mailing list
On Tue, Nov 17, 2015 at 8:01 AM, Philip Balister wrote: > During OEDEM in Dublin we talked about creating a list for high level > architecture discussions about the OpenEmbedded Build System. > > Bring your big ideas to the list, discuss them, and bring the resources > to implement them. > > We did discuss list proliferation, filtering patches, etc and still > decided the best solution was a new list. > > Philip > > > Forwarded Message > Subject: Welcome to the "Openemebdded-architecture" mailing list > Typo. Openemebdded :) -- 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] Sharing .inc recipe across layers
On Tue, Nov 17, 2015 at 6:26 AM, Vuille, Martin (Martin) wrote: > What is the best way to refer to (require) a .inc recipe > > in one layer from another layer? > Use the relative path from the top of the layer. I.e. require recipes-foo/bar/baz.inc, and bitbake will search BBPATH (the layer paths) to find it. -- 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] Calling python function from shell function
On Sat, Nov 7, 2015 at 10:27 AM, Vuille, Martin (Martin)
wrote:
> In my custom .bbclass, I have a python function
>
>
>
> python whatever () {
>
> …
>
> }
>
>
>
> and I would like to call it from a shell function
>
>
>
> do_something () {
>
> …
>
> whatever
>
> …
>
> }
>
>
>
> but bitbake gives me an error “whatever: not found” when building
>
> recipes based on this class
>
>
>
> Is what I am trying to do possible? Do I have the syntax wrong?
>
Not doable, no. You could make a python do_something which calls both
`whatever` and your shell `something_shell`, though. i.e.
python whatever () {
pass
}
do_something_shell () {
:
}
python do_something () {
bb.build.exec_func("whatever", d)
bb.build.exec_func("something_shell", d)
}
--
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] opkg 0.3.0 or rootfs task
On Mon, Nov 2, 2015 at 8:25 AM, Nicolas Dechesne < nicolas.deche...@linaro.org> wrote: > On Mon, Oct 26, 2015 at 12:46 AM, Christopher Larson > wrote: > >> >>> I've just posted patches to the opkg-devel list which should fix this. I >>> had >>> intended to give them a bit more testing before I sent them but a quick >>> fix is >>> needed. >> >> >> Thanks for your quick work on this, Paul, it's much appreciated. From >> some initial testing, builds are completing now. We'll keep testing it out. > > > > I just hit the same issue. I was pointed out to this thread on IRC today. > I found the patches on the 0.3.x branch in the opkg git tree. Apart from > applying these patches, do i need to do anything in any OE variables to use > the newly added options? I am not entirely sure after reading this thread > and looking at the patches.. > No, there's nothing else you need to do. The patches fromPaul change the opkg download cache to use checksums rather than the entire url as the filename, which avoids the file name length problem. I would not apply the first patch in the series, however, since that's not related to this. The first patch (memory leak fix) caused double-free failures in glibc in our testing. -- 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] opkg 0.3.0 or rootfs task
On Sat, Oct 24, 2015 at 12:19 PM, Paul Barker wrote: > On Sat, Oct 24, 2015 at 06:54:16PM +0000, Christopher Larson wrote: > > Not likely to help. The problem is the filename length, which will be the > > same whether it's a file or a symlink. > > On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo < > > alejandro.delcasti...@ni.com> wrote: > > > > > > > > > > > On 10/21/2015 02:49 AM, Ahsan, Noor wrote: > > > > We are hitting this issue on another BSP > > > > > > > > > > > > file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk > > > > > > > > need its solution quickly > > > > > > If you are in need of a quick workaround, try setting: > > > > > > option cache_local_files 0 > > > > > > on opkg.conf. This will make a copy of your ipk's instead of creating > > > symlinks (haven't try it myself, but that's my understanding). > > > > > > Also, please open a bug report for opkg on > > > https://bugzilla.yoctoproject.org to track the issue. > > > > > I've just posted patches to the opkg-devel list which should fix this. I > had > intended to give them a bit more testing before I sent them but a quick > fix is > needed. Thanks for your quick work on this, Paul, it's much appreciated. From some initial testing, builds are completing now. We'll keep testing it out. -- 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] opkg 0.3.0 or rootfs task
Not likely to help. The problem is the filename length, which will be the same whether it's a file or a symlink. On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo < alejandro.delcasti...@ni.com> wrote: > > > On 10/21/2015 02:49 AM, Ahsan, Noor wrote: > > We are hitting this issue on another BSP > > > > > file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk > > > > need its solution quickly > > If you are in need of a quick workaround, try setting: > > option cache_local_files 0 > > on opkg.conf. This will make a copy of your ipk's instead of creating > symlinks (haven't try it myself, but that's my understanding). > > Also, please open a bug report for opkg on > https://bugzilla.yoctoproject.org to track the issue. > > > *From:*kerg...@gmail.com [mailto:kerg...@gmail.com] *On Behalf Of > > *Christopher Larson > > *Sent:* Tuesday, October 20, 2015 10:20 PM > > *To:* Paul Barker > > *Cc:* Ahsan, Noor; yocto@yoctoproject.org > > *Subject:* Re: [yocto] opkg 0.3.0 or rootfs task > > > > On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson > > mailto:clar...@kergoth.com>> wrote: > > > > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker > <mailto:p...@paulbarker.me.uk>> wrote: > > > > On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote: > > > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > > > <mailto:noor_ah...@mentor.com><mailto:noor_ah...@mentor.com > > <mailto:noor_ah...@mentor.com>>> wrote: > > > > > > Hello, > > > > > > I noticed that at the time of rootfs creation symbolic links > > of the ipk files present in deploy/ipk. The problem what have it > > while creation of symbolic link it take the full path till that > > ipk and remove slashes and convert them into underscores. Use > > that as the name of the symbolic link. This make a very long > > file names. If we have very long path then name of the symlink > > exceed from max filename limits. And we get following error > > > > > > Collected errors: > > > * file_link: unable to stat > > > > `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': > > File name too long. > > > > > > Can anyone tell me why the addition of full path was added to > > the symlink name and can we remove it cause it is cause issues? > > > > > > what does > > > > > > getconf PATH_MAX / > > > > > > show ? > > > > > > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX > > > PATH_MAX 4096 > > > _POSIX_PATH_MAX4096 > > > > > > > > > I think the issue is with file name not the path. > > > > > > Secondly the googling which I did reveals that symlink > > creation can't be stopped. I just wanna confirm that is my > > findings correct? > > > > > > > This looks like something we overlooked in opkg. When we added > > the caching code > > we didn't think about how long the paths and filenames might get > > during the > > rootfs step. It's not currently possible to reduce the length of > > the symlink > > filenames, but it is possible to change the directory in which > > the symlinks are > > created. > > > > Currently the opkg cache dir can only be set in the opkg.conf > > file. I think we > > should add a '--cache-dir' argument to opkg. If this is added > > you'll be able to > > set the following i
Re: [yocto] opkg 0.3.0 or rootfs task
On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson wrote: > > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker > wrote: > >> On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote: >> > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > noor_ah...@mentor.com>> wrote: >> > >> > Hello, >> > >> > I noticed that at the time of rootfs creation symbolic links of the ipk >> files present in deploy/ipk. The problem what have it while creation of >> symbolic link it take the full path till that ipk and remove slashes and >> convert them into underscores. Use that as the name of the symbolic link. >> This make a very long file names. If we have very long path then name of >> the symlink exceed from max filename limits. And we get following error >> > >> > Collected errors: >> > * file_link: unable to stat >> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/ >> opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': >> File name too long. >> > >> > Can anyone tell me why the addition of full path was added to the >> symlink name and can we remove it cause it is cause issues? >> > >> > what does >> > >> > getconf PATH_MAX / >> > >> > show ? >> > >> > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX >> > PATH_MAX 4096 >> > _POSIX_PATH_MAX4096 >> > >> > >> > I think the issue is with file name not the path. >> > >> > Secondly the googling which I did reveals that symlink creation can't >> be stopped. I just wanna confirm that is my findings correct? >> > >> >> This looks like something we overlooked in opkg. When we added the >> caching code >> we didn't think about how long the paths and filenames might get during >> the >> rootfs step. It's not currently possible to reduce the length of the >> symlink >> filenames, but it is possible to change the directory in which the >> symlinks are >> created. >> >> Currently the opkg cache dir can only be set in the opkg.conf file. I >> think we >> should add a '--cache-dir' argument to opkg. If this is added you'll be >> able to >> set the following in your local.conf file to change the cache location. >> Eg. to >> use '/tmp/opkg' on the host during rootfs creation. >> >> OPKG_ARGS = "--cache-dir=/tmp/opkg" >> >> I'll submit a patch to opkg to add this option. >> > > This will only shorten the full path, not the filename length, so I doubt > this'll solve it. That said, I can't actually successfully test this today, > because cache_dir is made relative to offline_root, so setting such a path > as you suggest doesn't shorten the full path either. Also, did a touch of just the cache filename and it gives the same filename length error, so where the cache dir is really isn't going to matter, it's the filename including the full path to a deep BUILDDIR, and therefore DEPLOY_DIR_IPK, which is the problem. -- 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] opkg 0.3.0 or rootfs task
On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker wrote: > On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote: > > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor noor_ah...@mentor.com>> wrote: > > > > Hello, > > > > I noticed that at the time of rootfs creation symbolic links of the ipk > files present in deploy/ipk. The problem what have it while creation of > symbolic link it take the full path till that ipk and remove slashes and > convert them into underscores. Use that as the name of the symbolic link. > This make a very long file names. If we have very long path then name of > the symlink exceed from max filename limits. And we get following error > > > > Collected errors: > > * file_link: unable to stat > `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/ > opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': > File name too long. > > > > Can anyone tell me why the addition of full path was added to the > symlink name and can we remove it cause it is cause issues? > > > > what does > > > > getconf PATH_MAX / > > > > show ? > > > > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX > > PATH_MAX 4096 > > _POSIX_PATH_MAX4096 > > > > > > I think the issue is with file name not the path. > > > > Secondly the googling which I did reveals that symlink creation can't be > stopped. I just wanna confirm that is my findings correct? > > > > This looks like something we overlooked in opkg. When we added the > caching code > we didn't think about how long the paths and filenames might get during the > rootfs step. It's not currently possible to reduce the length of the > symlink > filenames, but it is possible to change the directory in which the > symlinks are > created. > > Currently the opkg cache dir can only be set in the opkg.conf file. I > think we > should add a '--cache-dir' argument to opkg. If this is added you'll be > able to > set the following in your local.conf file to change the cache location. > Eg. to > use '/tmp/opkg' on the host during rootfs creation. > > OPKG_ARGS = "--cache-dir=/tmp/opkg" > > I'll submit a patch to opkg to add this option. > This will only shorten the full path, not the filename length, so I doubt this'll solve it. That said, I can't actually successfully test this today, because cache_dir is made relative to offline_root, so setting such a path as you suggest doesn't shorten the full path either. -- 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] FW: packages are compiled but not included in the final image
On Mon, Oct 12, 2015 at 12:02 PM, Thanassis Silis
wrote:
> Hi Christopher,
> thank you for the quick response. may I ask the following as well:
>
> i am attempting to include "lmsensors" as well as a
> CORE_IMAGE_EXTRA_INSTALL.
> I get errors while do_rootfs() runs
>
> Error: lmsensors not found in the base feeds (imx6qsabrelite
> armv7a-vfp-neon armv7a-vfp armv7a armv6-vfp armv6 armv5e-vfp armv5e
> armv5-vfp armv5 armv4 arm noarch any all).
> | ERROR: Function failed: do_rootfs (see
> /mnt/hd/nassdata/yocto/fsl-community-bsp/build/tmp/work/imx6qsabrelite-poky-linux-gnueabi/fsl-image-test/1.0-r0/temp/log.do_rootfs.16989
> for further information)
> ERROR: Task 7
> (/mnt/hd/nassdata/yocto/fsl-community-bsp/sources/meta-fsl-demos/recipes-fsl/images/
> fsl-image-test.bb, do_rootfs) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 5692 tasks of which 5690 didn't need to be
> rerun and 1 failed.
> No currently running tasks (5691 of 5693)
>
> it doesn't seem to be accepted but the log is not particularly
> informative.
> In other cases that i googled it seemed that setting
>
> ALLOW_EMPTY_${PN}-dbg = "1"
> ALLOW_EMPTY_${PN}-dev = "1"
>
> in sources/poky/meta/conf/bitbake.conf solved their issues. But these are
> already set in my case.
>
lmsensors emits a ton of binary packages, you'll have to see which ones you
need. Read meta-oe/recipes-support/lm_sensors/lmsensors_3.4.0.bb, the
PACKAGES lines.
--
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] FW: packages are compiled but not included in the final image
On Mon, Oct 12, 2015 at 10:08 AM, Thanassis Silis
wrote:
> From: djnass...@hotmail.com
> To: yocto-boun...@yoctoproject.org
> Subject: [yocto] packages are compiled but not included in the final image
> Date: Mon, 12 Oct 2015 16:53:51 +
>
> Hi all,
> I am attempting to add a few executables that are not there by default in
> a "core-image-base" image.
>
> so my conf/local.conf looks like
>
> MACHINE ??= 'imx6qsabrelite'
> #after version 1.5, use
> #MACHINE ??= 'nitrogen6x'
>
> DISTRO ?= 'poky'
> PACKAGE_CLASSES ?= "package_rpm package_ipk package_deb"
>
> #dev see http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html
> EXTRA_IMAGE_FEATURES = " debug-tweaks "
> EXTRA_IMAGE_FEATURES += " package-management "
> EXTRA_IMAGE_FEATURES += " ssh-server-openssh lmsensors "
>
> USER_CLASSES ?= "buildstats image-mklibs image-prelink"
> PATCHRESOLVE = "noop"
> BB_DISKMON_DIRS = "\
> STOPTASKS,${TMPDIR},1G,100K \
> STOPTASKS,${DL_DIR},1G,100K \
> STOPTASKS,${SSTATE_DIR},1G,100K \
> ABORT,${TMPDIR},100M,1K \
> ABORT,${DL_DIR},100M,1K \
> ABORT,${SSTATE_DIR},100M,1K"
> CONF_VERSION = "1"
>
> BB_NUMBER_THREADS = '2'
> PARALLEL_MAKE = '-j 2'
> ACCEPT_FSL_EULA = ""
>
>
> #webserver
> CORE_IMAGE_EXTRA_INSTALL += " apache2 php "
>
> CORE_IMAGE_EXTRA_INSTALL += " rrdtool bc screen ntp minicom "
>
> The image has been created but I have the following problems.
>
> while ntpd has been installed on the image and works fine, the executable
> ntpdate is NOT there.
> bash is also missing from core-image-base . is that to be expected? Should
> I add it as a CORE_IMAGE_EXTRA_INSTALL or as an EXTRA_IMAGE_FEATURE ?
>
Yes, that's expected, busybox is used by default. Add bash yourself if you
want it, or use a different image.
For ntpdate, it's split out into its own package, so add 'ntpdate' to
CORE_IMAGE_EXTRA_INSTALL as well if you want that.
--
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] FILESEXTRAPATHS_prepend fails for systemd
On Fri, Oct 2, 2015 at 11:22 AM, Daniel. wrote: > Where can I find this recipetool!? It seems a nice tool to have :) > It's in oe-core/scripts or poky/scripts in any recent release. It'll be in the PATH after sourcing the setup scripts. -- 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] FILESEXTRAPATHS_prepend fails for systemd
On Fri, Oct 2, 2015 at 11:11 AM, Daniel. wrote:
> But this will only work if journald.conf are the same in all systemd
> versions (since you use a _%.bbappend). A better solution would be append
> install task with a copy from your custom journald.conf to install folder,
> something like:
>
> do_install_append() {
> cp ${S}/myjournald.conf ${D}/propper/path/to/journald.conf
> }
Which is precisely what recipetool appendfile will do for you :)
--
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] FILESEXTRAPATHS_prepend fails for systemd
On Fri, Oct 2, 2015 at 8:58 AM, Fred Ollinger wrote: > I'm trying to change my /etc/systemd/journald.conf file. > recipetool appendfile sounds like exactly what you want here. -- 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] Safely cleaning 'downloads'
On Thu, Oct 1, 2015 at 9:49 AM, Gary Thomas wrote:
> On 2015-10-01 10:38, Smith, Virgil wrote:
>
>> The following is roughly the procedure I follow and that works for me.
>> Maybe someone could chime in with how some of this should be trimmed based
>> on yocto/bitbake intent/design.
>> Even so I'd probably stick with this level of extremism because without a
>> known good backup of your downloads(sources) you may be incapable of
>> (tweaking and) rebuilding your products if anything happens to your build
>> server.
>>
>> The only reason I've seen that simply deleting the downloads folder
>> causes problems is that external servers/content go away, violate their git
>> history, or replace files with non-identical contents.
>>
>>
>> Warning: The following does not maintain PR server information, so
>> automatic upgrading of your own packages could break. If you rely on this
>> work out how to extract that information (and back it up regularly).
>>
>> 1. rename/move your current downloads folder and create a new one.
>> 2. for all of your product build configurations empty out the following
>> folders
>> 2.1 cache
>> 2.2 state-cache
>> 2.3 tmp
>> 3. build (bitbake) all your product images with all appropriate
>> configuration variances
>> 4. run the following command to extract the unexpanded sources from
>> downloads
>> find -H downloads -maxdepth 1 \
>> -not -type d -and -not -name "*.done" \
>> -exec cp -L {} sources-tmp \;
>>
>> You now have everything you *currently* need for a sources mirror in the
>> sources-tmp folder.
>>
>> 5. move sources-tmp to wherever/whatever backs your SOURCE_MIRROR_URL.
>> 6. Check those contents into some form of revision control (even if that
>> is just a manual set of backup folders/media).
>>
>>
>> Yes this is costs time and space, you just have to decide how much your
>> images and how much being able to reproduce them (with or without 'small'
>> changes) is worth.
>>
>
> I'm already doing more or less this same sequence. I use these commands to
> stage the downloaded files to my mirror (/work/misc/Poky/sources for
> historical reasons)
> ( cd downloads;
> find . -maxdepth 1 -type f | grep -v '.lock$' | grep -v '.done$'
> >/tmp/files.$$;
> rsync -auv --files-from=/tmp/files.$$ . /work/misc/Poky/sources
> )
>
> This works very well (I've been doing it for many years). The issue I'm
> trying
> to work on now is that my script leaves 'downloads' possibly full of
> files, especially
> if there are new versions that have just been downloaded. This is
> especially noticeable
> for the tarballs of GIT trees - there are a number that I need/use that
> are measured in
> gigabytes (e.g. the RaspberryPi board firmware is 4194568645 bytes as of
> 2015-07-20!)
> Once I've saved these to my mirror(s), I'd like to be able to purge them
> from the local
> download directory in my builds. As mentioned, I've found that just
> wiping that in a
> build tree tends to break things quite badly. Of course I can always
> start over with
> a new build tree, but that also defeats the purpose of incremental builds.
I'd think something like this would get the job done:
1. Do a build of all your supported machines and configurations with
BB_GENERATE_MIRROR_TARBALLS=1 to ensure you have current, not out of date
scm tarballs.
2. Set up builds of all your supported machines and configurations, using a
new DL_DIR, with PREMIRRORS pointing to the old DL_DIR.
3. Either clean up the old DL_DIR by access time before you kicked off the
builds, or resolve the symlinks in the new DL_DIR and remove the old.
--
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] bbappend a "required" bb file
On Fri, Sep 25, 2015 at 11:52 AM, Allen Curtis < allen.cur...@curtisembedded.com> wrote: > On Fri, Sep 25, 2015 at 10:15 AM, Allen Curtis < > allen.cur...@curtisembedded.com> wrote: > >> I am working with a BSP that has multiple image recipes. >>> >>> foo-hwbringup-image.bb >>> foo-qt5demo-image.bb >>> >>> foo-qt5demo-image.bb contains "require foo-hwbringup-image.bb" >>> >>> However if I create foo-hwbringup-image.bbappend, it gets ignored. >>> >>> What are the rules with appending included recipes? >>> >> >> bbappends do not append arbitrary files, only recipes (and in this case, >> the inclusion treats them as an arbitrary file). They do not apply to >> anything included or required, only the recipe itself. So you'll need to >> bbappend every recipe that includes foo-hwbringup-image.bb in this case. >> >> >> This is unfortunate since foo-hwbringup-image.bb is also a valid recipe. >> It just doesn't contain the graphics support. >> >> Is there a better way to add your custom components to "core-image" I >> guess….. >> > > You could always define custom features for use in IMAGE_FEATURES and add > them to your images via EXTRA_IMAGE_FEATURES in local.conf, or bbappend one > of the core images. > > > How is bbappend a core image different from bbappend foo-hwbringup-image? > > If you follow the original post one more generation, > foo-hwbringup-image.bb "inherit core-image" > It isn't. You asked how to add custom components to a core-image, that's one way to do it, append every image involved. Whether that works for you depends on your requirements, and wasn't part of the question nor the answer. -- 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] bbappend a "required" bb file
On Fri, Sep 25, 2015 at 10:15 AM, Allen Curtis < allen.cur...@curtisembedded.com> wrote: > I am working with a BSP that has multiple image recipes. >> >> foo-hwbringup-image.bb >> foo-qt5demo-image.bb >> >> foo-qt5demo-image.bb contains "require foo-hwbringup-image.bb" >> >> However if I create foo-hwbringup-image.bbappend, it gets ignored. >> >> What are the rules with appending included recipes? >> > > bbappends do not append arbitrary files, only recipes (and in this case, > the inclusion treats them as an arbitrary file). They do not apply to > anything included or required, only the recipe itself. So you'll need to > bbappend every recipe that includes foo-hwbringup-image.bb in this case. > > > This is unfortunate since foo-hwbringup-image.bb is also a valid recipe. > It just doesn't contain the graphics support. > > Is there a better way to add your custom components to "core-image" I > guess….. > You could always define custom features for use in IMAGE_FEATURES and add them to your images via EXTRA_IMAGE_FEATURES in local.conf, or bbappend one of the core images. -- 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] bbappend a "required" bb file
On Thu, Sep 24, 2015 at 4:18 PM, Allen Curtis wrote: > I am working with a BSP that has multiple image recipes. > > foo-hwbringup-image.bb > foo-qt5demo-image.bb > > foo-qt5demo-image.bb contains "require foo-hwbringup-image.bb" > > However if I create foo-hwbringup-image.bbappend, it gets ignored. > > What are the rules with appending included recipes? > bbappends do not append arbitrary files, only recipes (and in this case, the inclusion treats them as an arbitrary file). They do not apply to anything included or required, only the recipe itself. So you'll need to bbappend every recipe that includes foo-hwbringup-image.bb in this case. -- 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] am335x-boneblack.dtb 'misnamed'? (Fido/BeagleBoneBlack)
It's installed into /boot on the rootfs with the zImage prefix, and update-alternatives creates a symlink to the correct path so uboot can find it. Not sure why this indirection exists, but it does work. On Thu, Sep 24, 2015 at 4:52 AM Colin Helliwell < colin.helliw...@ln-systems.com> wrote: > This may just be ‘the way it is’, but the stock Fido/BeagleBoneBlack BSP > [core-image-minimal] builds the am335x-boneblack dtb file, and creates in > build/tmp/deploy/images/beaglebone a symlink named > ‘zImage-am335x-boneblack.dtb’. However – and this is borne out by > README.hardware – uboot is set up to look for ‘am335x-boneblack.dtb’. > > I daresay I can do some sort of fixup, but I was curious why it’s like > this? > > > -- > ___ > 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] Missing certificates
On Fri, Jul 24, 2015 at 12:49 PM, Gary Thomas wrote: > On 2015-07-24 13:30, Aníbal Limón wrote: > >> Hi Gary, >> >> What version of python do you use?. >> >> Since 2.7.9 cert checking is enabled by default causing this kind of >> errors. [1] >> >> [1] https://www.python.org/dev/peps/pep-0476/ >> >> Kind regards, >> alimon >> > > I'm using the stock python 2.7.9 from Poky/Yocto > master:901be2cb69892595443ed41ab4be285932db15eb > > Is there an answer for this that's a bit less intrusive? > Perhaps there could be a DISTRO or even IMAGE feature to > enable/disable this checking? > > The pep you referenced mostly talks about why this was changed > and how to disable it - manually within the python code itself. > What I don't see is where/how/what to change/import to actually > let the full certificate checking happen. I think the better bet is to fix it so it actually finds the certs from ca-certificates rather than bypassing certificate checking, personally, but I can see how that would be a useful workaround. :) -- 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] Missing certificates
On Fri, Jul 24, 2015 at 11:02 AM, Gary Thomas wrote: > I was trying to run a simple fetch from python using > url = ' > https://raw.github.com/Itseez/opencv/master/samples/c/fruits.jpg' > filedata = urllib2.urlopen(url).read() > > This failed: > Traceback (most recent call last): > File "./edge.py", line 36, in > filedata = urllib2.urlopen(url).read() > File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen > return opener.open(url, data, timeout) > File "/usr/lib/python2.7/urllib2.py", line 431, in open > response = self._open(req, data) > File "/usr/lib/python2.7/urllib2.py", line 449, in _open > '_open', req) > File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain > result = func(*args) > File "/usr/lib/python2.7/urllib2.py", line 1240, in https_open > context=self._context) > File "/usr/lib/python2.7/urllib2.py", line 1197, in do_open > raise URLError(err) > urllib2.URLError: certificate verify failed (_ssl.c:581)> > > I can see that it was looking for some certificates in /usr/lib/ssl/certs > but that directory is missing. > > Anyone know what I might be missing (or have misconfigured)? > At least in the past, we’ve been highly inconsistent in certificate store configuration in various recipes, some pointing at a dir, some a file, and the paths vary. I don’t know if anyone ever fixed that, however — this is from memory. -- 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] Layer Priority with Wildcard .bbappend Files
Richard fixed this in master and fido after I opened a Yocto bug about it.
I don't recall the commit offhand, but you may be able to cherry-pick it.
On Sat, May 16, 2015 at 4:16 AM Christian Magnusson wrote:
> I also stumbled into this problem.
>
> We are using a BSP from Phytec. It’s using poky and Phytec made a simple
> distribution in meta-yougurt.
>
> Now I want to customize it, and made my own meta-platform to overwrite files
> from the other layers. (prio 100)
>
>
>
> # bitbake-layers show-recipes
>
> init-ifupdown:
>
> meta 1.0
>
>
>
> # bitbake-layers show-layers
>
> layer path priority
>
> ==
>
> meta /home/s22463/yocto/sources/poky/meta 5
>
> meta-yocto/home/s22463/yocto/sources/poky/meta-yocto 5
>
> meta-phytec /home/s22463/yocto/sources/meta-phytec20
>
> meta-phyam335x/home/s22463/yocto/sources/meta-phytec/meta-phyam335x
> 20
>
> meta-yogurt /home/s22463/yocto/sources/meta-yogurt10
>
> meta-oe /home/s22463/yocto/sources/meta-openembedded/meta-oe 6
>
> meta-networking
> /home/s22463/yocto/sources/meta-openembedded/meta-networking 5
>
> meta-python
> /home/s22463/yocto/sources/meta-openembedded/meta-python 7
>
> meta-systemd
> /home/s22463/yocto/sources/meta-openembedded/meta-systemd 7
>
> meta-qt5 /home/s22463/yocto/sources/meta-qt5 7
>
> meta-platform /home/s22463/yocto/sources/meta-platform 100
>
> meta-webserver
> /home/s22463/yocto/sources/meta-openembedded/meta-webserver 6
>
>
>
> # bitbake-layers show-appends
>
> init-ifupdown_1.0.bb:
>
>
> /home/s22463/yocto/sources/meta-platform/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
>
>
> /home/s22463/yocto/sources/meta-yogurt/recipes-core/init-ifupdown/init-ifupdown_%.bbappend
>
>
>
> Changing BBFILE_PRIORITY_platform-layer in meta-platform/conf/layer.conf
> doesn’t affect the order either.
>
>
>
>
>
> If I rename
>
> /home/s22463/yocto/sources/meta-yogurt/recipes-core/init-ifupdown/init-ifupdown_%.bbappend
> -> init-ifupdown_1.0.bbappend
>
> the priority works, and my files in meta-platform are installed last, as I
> want to overwrite all other files.
>
>
>
> # mv
> /home/s22463/yocto/sources/meta-yogurt/recipes-core/init-ifupdown/init-ifupdown_%.bbappend
>
> /home/s22463/yocto/sources/meta-yogurt/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
>
> # bitbake-layers show-appends
>
> init-ifupdown_1.0.bb:
>
>
> /home/s22463/yocto/sources/meta-yogurt/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
>
>
> /home/s22463/yocto/sources/meta-platform/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
>
>
>
> The installation order works now, but I would rather avoid to patch the other
> layers.
>
> Changing BBFILE_PRIORITY_platform-layer in meta-platform/conf/layer.conf now,
> will affect the order!, and I can install meta-plaform either before or after
> the meta-yougurt layer if I want.
>
>
>
> Does anyone know the reason to the faulty sort-order?
>
>
>
> /Christian Magnusson
>
>
>
>
>
>
>
> On 11/24/2014 03:22 PM, Stevens, Nick wrote:
>
> I think I've encountered a bug with how multiple bbappend files are processed
>
> when one of the bbappends contains a filename wildcard, but I want to make
> sure
>
> there's not something I'm missing before filing a bug report.
>
>
>
> I have a BSP layer and a customization layer that are based on the OE/poky
>
> Daisy release. The output of `bitbake-layers show-layers` looks like:
>
> layer path priority
>
> =
>
> meta poky/meta5
>
> meta-yoctopoky/meta-yocto 5
>
> meta-yocto-bsppoky/meta-yocto-bsp 5
>
> ...ellided...
>
> meta-bsp meta-bsp 6
>
> meta-custom meta-custom 8
>
>
>
> In meta-bsp there is a bbappend for base-files named
>
> base-files_3.0.14.bbappend. The meta-bsp bbappend adds a sysctl.conf to /etc -
>
> pretty straightforward:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI += "file://sysctl.conf"
>
> do_install_append() {
>
> install -m 0644 ${WORKDIR}/sysctl.conf ${D}${sysconfdir}/
>
> }
>
>
>
> Now what I want to do is add a file called base-files_%.bbappend to
>
> meta-custom. It has its own version of sysctl.conf, and the recipe looks like
>
> this:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
>
>
> Here's where things get weird. If I run `bitbake -e base-files` and pull out
>
> the section for FILESEXTRAPATHS, this is what I get (note that I've stripped
>
> out the huge absolute paths to make this easier to read):
>
> # $FILESEXTRAPATHS [5 operations]
>
> # set poky/m
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] sstate black hole?
On Tue, Apr 7, 2015 at 7:52 AM, Gary Thomas wrote:
> I'm building for multiple ARM i.MX6 platforms. These have
> the same SoC, but slightly different peripherals. As far as
> I can tell, they should be able to share everything except
> for a few ${MACHINE} specific packages, e.g. the kernel and
> u-boot.
>
> Sadly, that doesn't seem to be the case. The architecture
> specific packages are being split into two categories - plain
> ARM/Cortex-A9 and those that have i.MX6 specific optimizations.
> For example, after building a complete image (on the order of
> core-image-sato), I have this split:
> $ ls tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/
> acl gst-player libsamplerate0
> modutils-initscripts shadow-sysroot
> alsa-utils gst-plugins-badlibsm
> mpeg2dec shared-mime-info
> apmd gst-plugins-good libsndfile1
> mplayer2 speex
> atk gst-plugins-ugly libsoup-2.4
> mtdev sqlite3
> attr gstreamer libtheora
> ncurses startup-notification
> base-passwd gstreamer1.0 libtirpc
> neon strace
>...
> gst-ffmpeg libpostprocmatchbox-wm
> scrnsaverprotozlib
> gst-fluendo-mpegmux libproxy mkfontdir
> settings-daemon
> gst-meta-baselibpthread-stubs mkfontscale
> shadow
>
> $ ls tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/
> alsa-lib gst-plugins-base imx-gpu-viv libfslparser
> libsdl xf86-video-imxfb-vivante
> cairo gstreamer1.0-plugins-bad libdrm libfslvpuwrap mesa
> xserver-xorg
> firmware-imx gstreamer1.0-plugins-base libfslcodec libglu
> pulseaudio
>
> It's the second category that is causing problems. They do not
> seem to end up in any shareable sstate at all. If I try to rebuild
> using only sstate, i.e. build my complete image to success, then
> remove 'tmp' and rebuild, using the sstate-cache from the first go,
> all of the above packages (alsa-lib, ..., xserver-xorg) are all
> rebuilt from scratch. Those recipes do seem to end in my sstate-cache,
> but they are never reused from it.
>
> What would make this happen? How can I prevent it?
>
> As is, sstate is not really shareable between these i.MX6 targets
> as so much is being rebuilt all the time...
>
bitbake -S printdiff (e.g. a specific recipe, your image,
whatever) will tell you why the sstate wasn't used, by finding the ones
that are in SSTATE_DIR which most closely match the current configuration,
and displaying a detailed delta between the two. You might need
https://gist.github.com/kergoth/3713d779c14dc8b98f36.
--
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] How do VIRTUAL-RUNTIME's work and how to create a new keymap for VIRTUAL-RUNTIME_ir_keytable-keymaps
On Sun, Mar 29, 2015 at 9:23 AM, Matt Schuckmann wrote: > The v4l-utils recipe defines VIRTUAL-RUNTIME_ir-keytable-keymaps and the > ir-keytable package appears to RDEPENDS on its value. > > I want to define my own key map so I think that I should create a new > package, called “my-rc-keymaps”, for now it simple installs a file in > /lib/udev/rc_keymaps > In my image recipe I set VIRTUAL-RUNTIME_ir-keytable-keymaps = > "my-rc-keymaps" > I then added ir-keytable as a RDEPENDS of another of my packages. > > The problem is I don’t see my keymap file getting added to the image, in > fact it looks like the default rc-keymaps package is getting installed. > > If I add “my-rc-keymaps” to the same RDEPENDS I added ir-keytable then it > gets installed so I know the package is ok. > > I don’t understand what’s going on here. > I also find it frustrating that I don’t see the VIRTUAL-RUNTIME mechanism > documented so it makes it even harder to understand. > VIRTUAL-RUNTIME_something is just a variable. Someone defines it in the config metadata, then a recipe uses it. That's it. There's nothing magic about it, nor anything special about it. It's just a convention to let the user override the package to be used for that functionality. -- 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] [meta-cgl][PATCH] heartbeat: fix license issue
On Fri, Feb 13, 2015 at 10:00 PM, Armin Kuster wrote: > -LICENSE = "GPLv2 LGPLv2+" > +LICENSE = "GPLv2 | LGPLv2+" > Are you sure this is correct? Afaict this is wrong, as there are parts of the source tree under the GPL, and parts under LGPL, which means it's an AND relationship -- both apply, not an OR relationship, where you can choose which to use. -- 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] [meta-freescale] tmp/work-shared and sstate
On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas wrote: > If I run a build where the kernel package is brought in via > sstate, tmp/work-shared (in particular the kernel-source tree) > is not populated. This will break at least these recipes: > meta-fsl-arm/recipes-multimedia/gstreamer/gst-fsl-plugin_4.0.2.bb > meta-fsl-arm/recipes-multimedia/alsa/fsl-alsa-plugins_1.0.25.bb > > These programs reference the kernel includes directly for some > ARM/i.MX specific headers (e.g. ). These headers > are not part of the mainline kernel which is used to create the > kernel headers that populates tmp/sysroots, so the build fails. > Note: I'm not sure of the mechanism that lets these programs > peek into the kernel build (I looked at them but nothing jumped > out), but they do build find if the kernel is actually built > and not just brought in by sstate. > > Is this an error & if so, which recipe is at fault? The FSL > recipes, or the new kernel build/classes? > Per commit 46cdaf1c7bc597735d926af6a46f9483f7e57ce5 (oe-core 6a1ff0e7eacef595738f2fed086986fd622ec32a), you need to add this if you depend on the sources: do_configure[depends] += "virtual/kernel:do_shared_workdir" -- 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] sstate management
On Mon, Feb 2, 2015 at 9:42 AM, Gary Thomas wrote: > * The sstate-cache for a given build/target seems to grow > without bounds. I have one build which I've been reusing > since last November has grown to 62GB. A very similar > build which hasn't see quite so many 'bakes' is only 27GB. > > Is there some maintenance to be done on the sstate-cache? > I'm thinking I want to set up a shared cache which might > last for a long time and I would like to only keep the bits > that are really needed. > In the past i've either used sstate-cache-management.sh or ensured that SSTATE_DIR is on a mount with atime enabled and just periodically wiped anything that hasn't been accessed in over a week. * The second operational question I have is if I have a shared > sstate cache and I make some sort of build, what is the best > way (if any) to share any newly created objects so that my > other builds can make use of them? > I doubt there's a "best" on that. Personally I either use a shared filesystem path (e.g. nfs) or hook up rsync. -- 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] Can't override task from bbclass with - in its name
On Sun, Oct 26, 2014 at 8:15 AM, Vuille, Martin (Martin)
wrote:
> I have custom classes that override a task thus (in foo.bbclass)
>
> foo_do_something () {
> ...
> }
>
> EXPORT_FUNCTIONS do_something
>
> but if I change the name to foo-bar.bbclass and change the class thus
>
> foo-bar_do_something () {
> ...
> }
>
> EXPORT_FUNCTIONS do_something
>
> then building fails with "foo-bar_do_something: not found" and, sure
> enough,
> run.do_something does not contain the definition of foo-bar_do_something.
>
- isn't a valid character in a shell function, so while potentially
irritating, it's not surprising :)
--
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] [meta-freescale] /etc directory path in yocto
On Tue, Oct 21, 2014 at 10:28 PM, jags gediya wrote:
> I am compiling the custom recipie and i am getting the error in
> do_install function.
>
> Below is the do_install function
>
> do_install() {
> oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
> MANDIR=${mandir} \
> INCLUDEDIR=${includedir}
> }
>
> Error:
> saving cache in little endian encoding
> ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission
> denied
>
> Looking like, it is trying to create that file in host system's /etc
> directory. How can I avoid it and do_install function can use /etc
> directory of rootfs?
>
Read the makefiles of the project you're building. Specifically, modify
them to stop running ldconfig.
--
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] [meta-freescale] Remove Bluez4 and add Bluez5 in core-image-base
On Tue, Aug 26, 2014 at 9:47 AM, Khem Raj wrote: > On 14-08-26 20:18:36, jags gediya wrote: > > I am using yocto project for imx6sl evolution kit based custom board. > > I want to use core-image-base as basic image and put other packages on > that. > > By default , core-image-base have Bluez4, but i want to use Bluez5. > > How can i remove default Bluez4 from core-image-base? > > PREFERRED_PROVIDER_bluez4 ?= "bluez5" > and have 'bluetooth' in DISTRO_FEATURES Afaik bluez5 is not a provider of bluez4, so oe-core doesn't provide a way to swap between the two at this time. -- 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] Image that depends on another image
On Thu, Aug 21, 2014 at 5:08 PM, Seth Bollinger wrote: > Our device requires two images to be built. Is there any way to have the > first image depend on the second image? do_rootfs[depends] += "some-other-image:do_rootfs" would probably do. -- 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] toybox in OpenEmbedded
On Mon, Aug 18, 2014 at 6:44 AM, Paul Barker wrote: > I've been wanting to try out toybox within OpenEmbedded for quite a while > and > have finally found time to put a recipe together. Toybox is a BSD-licensed > alternative to Busybox which may be of interest to a few people. It's > still a > work in progress but it already covers a large number of the basic > commands a > system needs. It should tie in well with the recent work Khem has done to > enable > the use of musl in OpenEmbedded as toybox and musl are often used together > (e.g. > Aboriginal Linux distro). > > My patches are currently against openembedded-core for convenience but this > probably belongs in meta-oe for now. I've done some basic testing on > qemuarm but > nothing significant. toybox builds and installs correctly though and I've > set > ALTERNATIVE_PRIORITY = 60 so that it takes precedence over busybox tools. > > Removing toybox after it has been installed currently bricks the system > though > as the postrm script runs after '/bin/toybox' has been removed (so things > like > '/bin/ln' become broken links and the update-alternatives script can't > run). > One option for that might be to try the C implementation of alternatives that's provided in chkconfig, rather than cworth's shell version. I haven't tested it in that context, but I doubt it runs so many external tools. -- 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] [PATCH] Adding support for systemd and its service files
On Wed, Aug 13, 2014 at 4:57 AM, Sujith H wrote: > From: Sujith H > > Signed-off-by: Muzaffar Mahmood > Signed-off-by: Sujith H > Might want to mention 'psplash' in the commit message in the future when emailing a multi-purpose list like yocto@, so it's clear what exactly it's patching before reading the email :) -- 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] distro.conf and LOCALCONF_VERSION, LAYER_CONF_VERSION, OELAYOUT_ABI
On Tue, Aug 12, 2014 at 12:31 PM, Rudolf Streif wrote:
> The Poky distro configuration distro.conf includes assignments to
> LOCALCONF_VERSION, LAYER_CONF_VERSION, OELAYOUT_ABI to set the expected
> version numbers for local.conf, bblayers.conf and the directory layout of
> ${TMPDIR}.
>
> From a user perspective this is somewhat confusing as these variables
> really have nothing to do with the distro policy but only with the
> compatibility between the build system and a build environment. For Poky it
> may somewhat make sense to put them there. However if I write my own
> distro.conf and put it in a layer I would want to use this layer with
> different version of the build system. I think it would make more sense to
> assign these variables in poky-sanity.bbclass.
>
> The second little gripe is about the inconsistent naming of these
> variables and the ones they relate to:
>
> LOCALCONF_VERSION (expected value) <-> CONF_VERSION (actual value)
> LAYER_CONF_VERSION (expected value) <-> LCONF_VERSION (actual value)
> OELAYOUT_ABI (expected value) <-> actual value retrieved from
> tmp/abi_version
>
> Adding to the confusion is LAYERVERSION which refers to the version of the
> conf/layer.conf file of a layer. That is in contrast to LAYER_CONF_VERSION
> / LCONF_VERSION which are for conf/bblayers.conf in the build enviroment.
>
> Changing stuff that has been established for years is of course a pain but
> it has been done and can be done in a backward compatible way.
>
> My suggestions:
>
>1. Rename LOCALCONF_VERSION to LOCAL_CONF_VERSION_SET
>2. Rename LAYER_CONF_VERSION to BBLAYERS_CONF_VERSION_SET
>3. Rename CONF_VERSION to LOCAL_CONF_VERSION
>4. Rename LCONF_VERSION to BBLAYERS_CONF_VERSION
>5. Rename OELAYOUT_ABI to OELAYOUT_VERSION_SET
>6. Provide values for LOCAL_CONF_VERSION_SET,
>BBLAYERS_CONF_VERSION_SET, OELAYOUT_VERSION_SET in poky-sanity.bbclass and
>remove the settings from the distro configuration.
>
> You would also want to change LAYERVERSION to LAYER_CONF_VERSION to be
> consistent. But that cannot be done backwards compatible as it conflicts
> with the currently used version variable for bblayers.conf.
>
LAYERVERSION is about the version of the layer, which LAYERDEPENDS can
reference, e.g. backwards-incompatible changes going into the layer, not
the version of the layer's layer.conf specifically. _SET is a weird way to
indicate an expected value, also, I'd called it _REQUIRED or something, but
that's minor. In general, I agree that things are rather inconsistent with
regard to variable naming, but that's true everywhere, not just for these
variables :)
--
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] anyone know of a single OE/yocto recipe that uses BBVERSIONS?
On Mon, Aug 11, 2014 at 4:40 AM, Robert P. J. Day wrote: > collecting examples of recipe design and variants, and bitbake user > manual refers to BBVERSIONS variable to allow a recipe file to build > multiple versions from one file, but in the dozen or so layers i have > checked out, i've seen not a single example of usage of that variable. > > are there any? > Nope, as far as I know, it's not being used at all at the moment. The idea was we could use it to avoid having multiple recipes with different versions and .inc includes all over the place, but then policy changed to tend to prefer having just a single recipe version around, so it's of less use. If you'd like to see an example of a prototyped recipe using it, which I created while implementing BBVERSIONS, see https://gist.github.com/kergoth/338382. This was an attempt, at the time (2010) to have a single m4 recipe that was capable of building every m4 version that existed. It was mostly to see if it could be done :) -- 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] read only rootfs & systemd
On Tue, Jul 22, 2014 at 4:43 AM, Maciek Borzecki < maciej.borze...@open-rnd.pl> wrote: > Is read-only-rootfs supported on systemd setups? > > The current dev manual is not clear about this. Also in image.bbclass > there are comments that read_only_rootfs_hook supports only sysvinit > setups. > Not in oe-core, no. https://github.com/MentorEmbedded/meta-ro-rootfs is how we're handling it at mentor today, we haven't gotten around to pursuing an upstream solution, whether integration of this or something else, as of yet. If you follow the instructions at https://github.com/MentorEmbedded/meta-ro-rootfs#usage it should work fine for you. -- 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] Extending images
On Fri, Jul 18, 2014 at 11:55 AM, Robert P. J. Day wrote: > On Fri, 18 Jul 2014, Christopher Larson wrote: > > > I really don't think this was ever safe, as it completely depended > > on how the image recipe added its bits to IMAGE_INSTALL, which could > > easily vary from image to image. I've *always* told folks to use > > IMAGE_INSTALL_append if anything, even back in oe classic :) -- > > a quick grep in openembedded-core/meta shows: > > $ grep -r "IMAGE_INSTALL +=" * > recipes-core/images/core-image-minimal-mtdutils.bb:IMAGE_INSTALL += > "mtd-utils" > recipes-extended/images/core-image-testmaster.bb:IMAGE_INSTALL += "\ > recipes-extended/images/core-image-lsb-sdk.bb:IMAGE_INSTALL += > "kernel-dev" > recipes-graphics/images/core-image-directfb.bb:IMAGE_INSTALL += "\ > recipes-qt/images/qt4e-demo-image.bb:IMAGE_INSTALL += "\ > recipes-rt/images/core-image-rt-sdk.bb:IMAGE_INSTALL += "rt-tests > hwlatdetect kernel-dev" > recipes-rt/images/core-image-rt.bb:IMAGE_INSTALL += "rt-tests hwlatdetect" > recipes-sato/images/core-image-sato-sdk.bb:IMAGE_INSTALL += "kernel-dev" > recipes-sato/images/core-image-sato.bb:IMAGE_INSTALL += > "packagegroup-core-x11-sato-games" > $ > > now i'm scared to look. :-) This is what they should be doing in most cases. The only time you need _append is when you're defining it from local.conf, because the behavior of IMAGE_INSTALL += in local.conf depends on what the recipe is doing (does it IMAGE_INSTALL = (overrides the user's value), ?= (only uses the user's value, not its own), or += (adds to an already set value)). This is where the value lies in providing the user explicit variables with known semantics, so the user doesn't have to know these peculiarities and can just set the variable already :) That said, this is definitely another case of many you've pointed out where our recipes just aren't as consistent as would be ideal. IMO when a recipe takes a list variable like this and does just an '=' it's basically saying "I must have only these things, throw away anything already set", so the only time it should be set that way is when there's such an explicit need. Whereas most of the time what they really wanted to say was "I need these things", in which case += is more appropriate (and I'm not just talking about IMAGE_INSTALL here, but also variables like RDEPENDS and DEPENDS) :) But that's just my personal view on the subject. -- 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] Extending images
On Fri, Jul 18, 2014 at 11:45 AM, Robert P. J. Day
wrote:
>
> > On 2014-07-18 10:49, Christopher Larson wrote:
> > >
> > > On Fri, Jul 18, 2014 at 9:26 AM, Gary Thomas > > <mailto:g...@mlbassoc.com>> wrote:
> > >
> > > 've always used 'IMAGE_INSTALL += " xyz"' in my local.conf
> > > to add new packages to a build. That said, I had a working
> > > build for qemuarm (probably doesn't matter) and I added:
> > >IMAGE_INSTALL += " strace"
> > > This produced a completely broken image which barely came
> > > up to a shell, lots of missing programs, etc.
> > >
> > > I then tried
> > >CORE_IMAGE_EXTRA_INSTALL += " strace"
> > > which produced a perfectly working build (just as previous)
> > > with the new package added.
> > >
> > > I can see that the images produced are vastly different:
> > >
> > > * Original working build
> > > -rw-r--r-- 1 gthomas gthomas 11719 Jul 18 09:34
> > > core-image-sato-qemuarm-__20140718124453.rootfs.manifest
> > > -rw-r--r-- 1 gthomas gthomas 87611203 Jul 18 09:34
> > > core-image-sato-qemuarm-__20140718124453.rootfs.tar.bz2
> > >
> > > * After 'IMAGE_INSTALL += '
> > > -rw-r--r-- 1 gthomas gthomas 9986 Jul 18 09:55
> > > core-image-sato-qemuarm-__20140718155134.rootfs.manifest
> > > -rw-r--r-- 1 gthomas gthomas 37859884 Jul 18 09:56
> > > core-image-sato-qemuarm-__20140718155134.rootfs.tar.bz2
> > >
> > > * After 'CORE_IMAGE_EXTRA_INSTALL += '
> > > -rw-r--r-- 1 gthomas gthomas 11738 Jul 18 10:05
> > > core-image-sato-qemuarm-__20140718160108.rootfs.manifest
> > > -rw-r--r-- 1 gthomas gthomas 87720106 Jul 18 10:05
> > > core-image-sato-qemuarm-__20140718160108.rootfs.tar.bz2
> > >
> > > What's the difference and why did the first attempt fail?
> > >
> > >
> > > Most likely the image defined its own IMAGE_INSTALL using ?=, so
> > > defining it yourself in the configuration data overrode its
> > > default definition, since ?= is "set only if unset". If the recipe
> > > didn't use ?=, then your IMAGE_INSTALL += would have had no effect
> > > at all. To append to IMAGE_INSTALL directly without using
> > > CORE_IMAGE_EXTRA_INSTALL you could have used IMAGE_INSTALL_append,
> > > since that's a postponed operation that happens at the end of the
> > > recipe parsing.
> >
> > That makes sense, thanks. I'll stick to using
> > CORE_IMAGE_EXTRA_INSTALL from now on!
>
> not to sound repetitively repetitive, but this is related to what i
> thought was the weird way core images are defined based off of
> core-image.bbclass, where core-image.bbclass does *exactly* what you
> describe above:
>
> CORE_IMAGE_BASE_INSTALL = '\
> packagegroup-core-boot \
> packagegroup-base-extended \
> \
> ${CORE_IMAGE_EXTRA_INSTALL} \
> '
>
> CORE_IMAGE_EXTRA_INSTALL ?= ""
>
> IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"
>
> the danger here is that if someone has been defining/building images
> for a while based off of the lower-level image.bbclass, then (i think)
> using "IMAGE_INSTALL +=" will work just fine, and the poor developer
> gets lulled into a false sense of security and carries that habit over
> to her first core-image and ... boom.
>
I really don't think this was ever safe, as it completely depended on how
the image recipe added its bits to IMAGE_INSTALL, which could easily vary
from image to image. I've *always* told folks to use IMAGE_INSTALL_append
if anything, even back in oe classic :)
--
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] Extending images
On Fri, Jul 18, 2014 at 9:54 AM, Gary Thomas wrote: > Most likely the image defined its own IMAGE_INSTALL using ?=, so defining >> it yourself in the configuration data overrode its default definition, >> since ?= is "set only if unset". If >> the recipe didn't use ?=, then your IMAGE_INSTALL += would have had no >> effect at all. To append to IMAGE_INSTALL directly without using >> CORE_IMAGE_EXTRA_INSTALL you could have used >> IMAGE_INSTALL_append, since that's a postponed operation that happens at >> the end of the recipe parsing. >> > > That makes sense, thanks. I'll stick to using CORE_IMAGE_EXTRA_INSTALL > from now on! That's best, indeed. This is a case where there's a real difference between variables intended for the user to override from configuration, and those which are not. IMAGE_INSTALL is a detail of how images are constructed, CORE_IMAGE_EXTRA_INSTALL is an explicit hook provided to the user to non-destructively add packages to an image, so we don't have to try to guess at what the recipe will do with it -- it has explicit semantics, so we know this. There might be value in differentiating between cases like this in the documentation, if we don't already. -- 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] Extending images
On Fri, Jul 18, 2014 at 9:26 AM, Gary Thomas wrote: > 've always used 'IMAGE_INSTALL += " xyz"' in my local.conf > to add new packages to a build. That said, I had a working > build for qemuarm (probably doesn't matter) and I added: > IMAGE_INSTALL += " strace" > This produced a completely broken image which barely came > up to a shell, lots of missing programs, etc. > > I then tried > CORE_IMAGE_EXTRA_INSTALL += " strace" > which produced a perfectly working build (just as previous) > with the new package added. > > I can see that the images produced are vastly different: > > * Original working build > -rw-r--r-- 1 gthomas gthomas 11719 Jul 18 09:34 > core-image-sato-qemuarm-20140718124453.rootfs.manifest > -rw-r--r-- 1 gthomas gthomas 87611203 Jul 18 09:34 > core-image-sato-qemuarm-20140718124453.rootfs.tar.bz2 > > * After 'IMAGE_INSTALL += ' > -rw-r--r-- 1 gthomas gthomas 9986 Jul 18 09:55 > core-image-sato-qemuarm-20140718155134.rootfs.manifest > -rw-r--r-- 1 gthomas gthomas 37859884 Jul 18 09:56 > core-image-sato-qemuarm-20140718155134.rootfs.tar.bz2 > > * After 'CORE_IMAGE_EXTRA_INSTALL += ' > -rw-r--r-- 1 gthomas gthomas 11738 Jul 18 10:05 > core-image-sato-qemuarm-20140718160108.rootfs.manifest > -rw-r--r-- 1 gthomas gthomas 87720106 Jul 18 10:05 > core-image-sato-qemuarm-20140718160108.rootfs.tar.bz2 > > What's the difference and why did the first attempt fail? > Most likely the image defined its own IMAGE_INSTALL using ?=, so defining it yourself in the configuration data overrode its default definition, since ?= is "set only if unset". If the recipe didn't use ?=, then your IMAGE_INSTALL += would have had no effect at all. To append to IMAGE_INSTALL directly without using CORE_IMAGE_EXTRA_INSTALL you could have used IMAGE_INSTALL_append, since that's a postponed operation that happens at the end of the recipe parsing. -- 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] [OE-core] /etc/os-release
On Mon, Jul 14, 2014 at 3:50 PM, Saul Wold wrote: > On 07/14/2014 03:38 PM, akuster wrote: > >> Hello all, >> >> I noticed some reference to /etc/os-release in some recipes. Where can I >> find the initial creation of /etc/os-release? If one is not created, >> would there desire to have one? >> >> Really? We reference it in the meta/lib/oe/lsb.py release_dict_file() > function to search for LSB information of the host machine to identify the > host distro version information. > > Can you be specific about which recipes are using os-release, I did do a > search. I'm pretty sure we don't have an os-release recipe in oe-core at all yet, so the file isn't going to exist on target. Mentor has one in meta-mentor at the moment pending time to submit it again / poke on the existing thread. See the thread with the subject "[RFC PATCH 0/2] Add /etc/os-release". It's definitely something we should have, in my opinion. -- 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] Inadvertent RootFS permission pollution
On Wed, Jul 9, 2014 at 7:37 AM, Bollinger, Seth
wrote:
> I recently ran into a problem where I had trouble determining why the
> setgid bit was set in my rootfs. It turns out that debian has this bit set
> on /usr/local (where I was building from), and thus inherited this bit from
> that directory tree. This surprised me, so I thought I would pass it along
> in case it saves anyone else some time.
Ah, yes, I've hit this in the past too, thanks for bringing it up, we'll
have to resolve that -- perhaps have bitbake chmod g-s ${TMPDIR} when it's
created?
--
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] the apparent need for docbook tag in manual examples
On Sun, Jun 22, 2014 at 6:20 AM, Robert P. J. Day wrote: > as i said, it took me a few minutes to figure out what the > conditional metadata example above was trying to demonstrate, but as > soon as i saw a real example in the codebase, it was perfectly clear. > to this end, i'm creating wiki pages that show stuff like that > exactly, like this one for conditional overrides: > It's not directly related, but here's some background if it helps anyone at all. Conceptually, when we designed overrides, it was created to let us implement layering of metadata (note: not layers as in yocto layers, but conceptual layers), to let us always let more specific information be used in preference to less specific information. Machine information will be used in preference to Architecture which is used in preference to the default. This lets us ensure that we're always using the most accurate information available about the configuration in question. I've always thought that thinking of it this way helps one see the purpose behind the mechanism (and you can see that the order of the includes/requires in bitbake.conf essentially implements the same ordering where possible, to provide the same capability based on load order of the config files). I'm not sure if any of our docs talk about it this way, and I'm not sure if it helps anyone else wrap their heads around it, but I'm throwing it out there since I've found that some folks seem to find it a useful way of looking at it. -- 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] How to determine which tasks bitbake just ran?
On Thu, Jun 12, 2014 at 12:00 PM, Burton, Ross wrote: > On 12 June 2014 19:53, Patrick Doyle wrote: > > As you know, when we bitbake a recipe, we see lots of messages about > > individual tasks that are run as they are being run (do_fetch, > > do_configure, etc…), and then a final summary message that reads > > something like: > > > > NOTE: Tasks Summary: Attempted 690 tasks of which 677 didn't need to > > be rerun and all succeeded. > > > > I'm curious: > > 1) What were the 13 tasks that ran? > > 2) Why are there 690 tasks for my simple recipe anyway? > > You want to see the cooker log. > > If you want to see that as it happens, then for a one-off you can > convince bitbake that it's not running on a vt (bitbake foo | cat -). > > After the event, the cooker logs are in > tmp/logs/cooker/[machine]/[timestamp].log. For convenience, Chris > Larson's excellent 'bb' command has a 'log' mode that if given no > arguments will display the latest cooker log. The new Toaster is pretty great at examining what your build did, if you ran your build in toaster context, afaik. I haven't spent much time playing with it, but it does seem like it's intended to answer just these sort of questions. -- 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] git.py support for submodules
On Saturday, May 17, 2014, Chris Morgan wrote: > > On May 17, 2014 3:58 PM, "Christopher Larson" > > > wrote: > > > > > > > > On Saturday, May 17, 2014, Chris Morgan > > > > wrote: > >> > >> Hello. > >> > >> I noticed that git.py doesn't seem to have support for submodules. I > worked around this in my recipe by adding a pre configure step but I was > wondering if a patch to add another option to git.py to fetch submodules > would make sense and be welcomed (pending it's implementation of course). > > > > > > See gitsm.py. > > > > > > -- > > Christopher Larson > > clarson at kergoth dot com > > Founder - BitBake, OpenEmbedded, OpenZaurus > > Maintainer - Tslib > > Senior Software Engineer, Mentor Graphics > > I couldn't actually figure out how to use it. I looked at the code and > wasn't sure how it war supposed to do or what it was for. > You use it exactly the way you use git.py - gitsm:// instead of git://. It's basically git fetching plus submodule handling. I personally would rather see it merged into git.py, but I can see the reasoning. -- 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] git.py support for submodules
On Saturday, May 17, 2014, Chris Morgan wrote: > Hello. > > I noticed that git.py doesn't seem to have support for submodules. I > worked around this in my recipe by adding a pre configure step but I was > wondering if a patch to add another option to git.py to fetch submodules > would make sense and be welcomed (pending it's implementation of course). > See gitsm.py. -- 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
