Re: [yocto] Any hints when building boost-nativesdk?
Hi Khem, On Thu, 2012-09-20 at 14:49 -0700, Khem Raj wrote: > On Thu, Sep 20, 2012 at 2:32 PM, Darren Hart wrote: > > On 09/20/2012 11:50 AM, Chatre, Reinette wrote: > >> Hi, > >> > >> I am running Yocto 1.2 and would like to include the boost development > >> environment in my SDK. I created a bbappend for the boost recipe that > > Do you want your target applications to have boost right ? Correct. > in that case you just add boost-dev to TOOLCHAIN_TARGET_TASK may be in > your local.conf Thank you very much Reinette ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
Simple: tags aren't guaranteed to not change what it references, the
hash is guaranteed to always point to the same thing. Thus, git is
double checking that the meaning of the tag hasn't changed.
On Thu, 2012-09-20 at 16:32 -0400, William Mills wrote:
> On 09/20/2012 04:08 PM, Evade Flow wrote:
> > To bring this full circle... if you want to build behind a restrictive
> > firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
> > recipes which:
> >
> >1. Specify a git repo as the source, and,
> >
> >2. Specify the revision to be built using a tag name
> >
> >
> > will cause your build to abort when bitbake tries to run 'git ls-remote'
> > to resolve the tag name. So don't specify SRC_URI like this:
> >
> >
> >SRC_URI =
> > "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"
> >
> > Instead, use:
> >
> >SRC_URI =
> > "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8885ced062131214448fae056ef453f094303805;branch=master"
> >
> >
> > I added a note about this to the Wiki:
> >
> >-
> > http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_Git_Respositories
> >
> > I'm still new to Yocto, so someone please chime in if any of this
> > information is incorrect...
> >
>
> If true, this seems very unfortunate. This seems to push people in the
> wrong direction. Is there a reason the fetchers don't pull down the
> tags when they mirror in the first place?
>
> ___
> 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] BB_NO_NETWORK and own-mirrors not working with meta-systemd
On Thu, Sep 20, 2012 at 3:12 PM, Evade Flow wrote: > This doesn't appear to be done in a couple of the Yocto recipes: > > - meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb > - meta/recipes-devtools/mtd/mtd-utils_1.4.9.bb > good. Send patches we will accept. > SRCREV is not set in either of these, but 'tag=' is supplied as part of > SRC_URI, i.e.: > > > SRC_URI = > "git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git;tag=fdb6c0402337d9607c7a39155088eaf033742752;branch=master" > > > I'm not sure what to make of that, but... I'll modify my Wiki entry to say > that SRCREV should be set (instead of a SRC_URI with 'tag='). change this one too ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
> You should not need to be specifying the revision within SRC_URI as you are
> doing, however, it is correct that you must specify the revision in
> SRCREV...
This doesn't appear to be done in a couple of the Yocto recipes:
- meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
- meta/recipes-devtools/mtd/mtd-utils_1.4.9.bb
SRCREV is not set in either of these, but 'tag=' is supplied as part of
SRC_URI, i.e.:
SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git;tag=fdb6c0402337d9607c7a39155088eaf033742752;branch=master"
I'm not sure what to make of that, but... I'll modify my Wiki entry to say
that SRCREV should be set (instead of a SRC_URI with 'tag=').
On Thu, Sep 20, 2012 at 5:41 PM, Paul Eggleton
wrote:
> On Thursday 20 September 2012 16:08:41 Evade Flow wrote:
>> To bring this full circle... if you want to build behind a restrictive
>> firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
>> recipes which:
>>
>> 1. Specify a git repo as the source, and,
>>
>> 2. Specify the revision to be built using a tag name
>>
>>
>> will cause your build to abort when bitbake tries to run 'git ls-remote'
>> to resolve the tag name. So don't specify SRC_URI like this:
>>
>>
>> SRC_URI =
>> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v
>> ${PV}"
>>
>> Instead, use:
>>
>> SRC_URI =
>> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8
>> 885ced062131214448fae056ef453f094303805;branch=master"
>>
>>
>> I added a note about this to the Wiki:
>>
>> -
>> http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_
>> Git_Respositories
>>
>> I'm still new to Yocto, so someone please chime in if any of this
>> information is incorrect...
>
> You should not need to be specifying the revision within SRC_URI as you are
> doing, however, it is correct that you must specify the revision in SRCREV and
> that revision must be the full SHA1 hash and not just a tag or branch name.
> The reason for this is that tags are not fixed and could change, therefore if
> one is used we must query the server and resolve it to the current SHA1 hash
> every time the recipe is parsed.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Any hints when building boost-nativesdk?
On Thu, Sep 20, 2012 at 2:32 PM, Darren Hart wrote:
> On 09/20/2012 11:50 AM, Chatre, Reinette wrote:
>> Hi,
>>
>> I am running Yocto 1.2 and would like to include the boost development
>> environment in my SDK. I created a bbappend for the boost recipe that
Do you want your target applications to have boost right ?
in that case you just add boost-dev to TOOLCHAIN_TARGET_TASK may be in
your local.conf
>> only contains two lines:
>>
>> PR = "${INC_PR}.1"
>> BBCLASSEXTEND += "nativesdk"
>>
>> When I build with the above I get the following warnings:
>> NOTE: multiple providers are available for runtime boost-date-time (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-date-time
>
> Khem, I thought this might be something you were familiar with. Any
> thoughts?
>
> --
> Darren
>
>> NOTE: multiple providers are available for runtime boost-filesystem (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-filesystem
>> NOTE: multiple providers are available for runtime boost-graph (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-graph
>> NOTE: multiple providers are available for runtime boost-iostreams (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-iostreams
>> NOTE: multiple providers are available for runtime boost-program-options
>> (boost, boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match
>> boost-program-options
>> NOTE: multiple providers are available for runtime boost-regex (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-regex
>> NOTE: multiple providers are available for runtime boost-signals (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-signals
>> NOTE: multiple providers are available for runtime boost-system (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-system
>> NOTE: multiple providers are available for runtime boost-test (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-test
>> NOTE: multiple providers are available for runtime boost-thread (boost,
>> boost-nativesdk)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-thread
>>
>> It seems a bit strange that "boost-nativesdk" is seen as a provider for
>> any of those runtime components. Any hints what I should change to build
>> things correctly?
>>
>> Thank you very much
>>
>> Reinette
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
On Thursday 20 September 2012 16:08:41 Evade Flow wrote:
> To bring this full circle... if you want to build behind a restrictive
> firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
> recipes which:
>
> 1. Specify a git repo as the source, and,
>
> 2. Specify the revision to be built using a tag name
>
>
> will cause your build to abort when bitbake tries to run 'git ls-remote'
> to resolve the tag name. So don't specify SRC_URI like this:
>
>
> SRC_URI =
> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v
> ${PV}"
>
> Instead, use:
>
> SRC_URI =
> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8
> 885ced062131214448fae056ef453f094303805;branch=master"
>
>
> I added a note about this to the Wiki:
>
> -
> http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_
> Git_Respositories
>
> I'm still new to Yocto, so someone please chime in if any of this
> information is incorrect...
You should not need to be specifying the revision within SRC_URI as you are
doing, however, it is correct that you must specify the revision in SRCREV and
that revision must be the full SHA1 hash and not just a tag or branch name.
The reason for this is that tags are not fixed and could change, therefore if
one is used we must query the server and resolve it to the current SHA1 hash
every time the recipe is parsed.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] emgd-driver-bin: Fix package naming issue
On Sun, 2012-09-16 at 15:27 -0700, nitin.a.kam...@intel.com wrote:
> From: Nitin A Kamble
>
> emgd-driver-bin is generating rpm package with name libegl1.
> This name clashes with a package with sanme name from mesa-dri
> recipe. This name clash blocks installation of emgd user land
> binaries in the image. And due to missing emgd user land
> components X fails to start on BSPs like crownbay.
>
> Fix this problem by specifying package names in the recipe with the
> PKG_ vars.
>
> This fixes bug: [YOCTO #3063]
OK, I was finally able to get a build that had X working and was able to
test this and pull it into meta-intel/master.
Thanks,
Tom
>
> Signed-off-by: Nitin A Kamble
> ---
> .../xorg-driver/emgd-driver-bin_1.14.bb|8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.14.bb
> b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.14.bb
> index b1ba1b8..2464c38 100644
> --- a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.14.bb
> +++ b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.14.bb
> @@ -7,7 +7,7 @@ to LICENSE_FLAGS_WHITELIST +=
> \"License_emgd-driver-bin_1.14\" to your \
> local.conf in order to enable it in a build."
> LICENSE = "Intel-binary-only"
> LICENSE_FLAGS = "license_${PN}_${PV}"
> -PR = "r1"
> +PR = "r2"
>
> EMGD_LIC_DIR = "IEMGD_HEAD_Linux/License"
> EMGD_RPM_DIR = "IEMGD_HEAD_Linux/MeeGo1.2"
> @@ -23,6 +23,12 @@ SRC_URI =
> "https://edc.intel.com/Download.aspx?id=6190;downloadfilename=LIN_IEMG
> SRC_URI[md5sum] = "733a7f237ffce21238ce2c9956df4fd6"
> SRC_URI[sha256sum] =
> "bcdc333b5edbda7c746a83ef821ded4a0ca55ead30980e4e3680cdb6469f45a2"
>
> +# make sure generated rpm packages get non conflicting names
> +PKG_${PN} = "emgd-driver"
> +PKG_${PN}-dev = "emgd-driver-dev"
> +PKG_${PN}-dbg = "emgd-driver-dbg"
> +PKG_${PN}-doc = "emgd-driver-doc"
> +
> # These are closed binaries generated elsewhere so don't check ldflags
> INSANE_SKIP_${PN} = "ldflags"
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Any hints when building boost-nativesdk?
On 09/20/2012 11:50 AM, Chatre, Reinette wrote:
> Hi,
>
> I am running Yocto 1.2 and would like to include the boost development
> environment in my SDK. I created a bbappend for the boost recipe that
> only contains two lines:
>
> PR = "${INC_PR}.1"
> BBCLASSEXTEND += "nativesdk"
>
> When I build with the above I get the following warnings:
> NOTE: multiple providers are available for runtime boost-date-time (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-date-time
Khem, I thought this might be something you were familiar with. Any
thoughts?
--
Darren
> NOTE: multiple providers are available for runtime boost-filesystem (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-filesystem
> NOTE: multiple providers are available for runtime boost-graph (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-graph
> NOTE: multiple providers are available for runtime boost-iostreams (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-iostreams
> NOTE: multiple providers are available for runtime boost-program-options
> (boost, boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match
> boost-program-options
> NOTE: multiple providers are available for runtime boost-regex (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-regex
> NOTE: multiple providers are available for runtime boost-signals (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-signals
> NOTE: multiple providers are available for runtime boost-system (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-system
> NOTE: multiple providers are available for runtime boost-test (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-test
> NOTE: multiple providers are available for runtime boost-thread (boost,
> boost-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-thread
>
> It seems a bit strange that "boost-nativesdk" is seen as a provider for
> any of those runtime components. Any hints what I should change to build
> things correctly?
>
> Thank you very much
>
> Reinette
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
On 09/20/2012 04:08 PM, Evade Flow wrote:
To bring this full circle... if you want to build behind a restrictive
firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
recipes which:
1. Specify a git repo as the source, and,
2. Specify the revision to be built using a tag name
will cause your build to abort when bitbake tries to run 'git ls-remote'
to resolve the tag name. So don't specify SRC_URI like this:
SRC_URI =
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"
Instead, use:
SRC_URI =
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8885ced062131214448fae056ef453f094303805;branch=master"
I added a note about this to the Wiki:
-
http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_Git_Respositories
I'm still new to Yocto, so someone please chime in if any of this
information is incorrect...
If true, this seems very unfortunate. This seems to push people in the
wrong direction. Is there a reason the fetchers don't pull down the
tags when they mirror in the first place?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
To bring this full circle... if you want to build behind a restrictive
firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
recipes which:
1. Specify a git repo as the source, and,
2. Specify the revision to be built using a tag name
will cause your build to abort when bitbake tries to run 'git ls-remote'
to resolve the tag name. So don't specify SRC_URI like this:
SRC_URI =
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"
Instead, use:
SRC_URI =
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8885ced062131214448fae056ef453f094303805;branch=master"
I added a note about this to the Wiki:
-
http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_Git_Respositories
I'm still new to Yocto, so someone please chime in if any of this
information is incorrect...
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to Crystal Forest BSP.
2012/9/20 Bodke, Kishore K : > > >>-Original Message- >>From: yocto-boun...@yoctoproject.org [mailto:yocto- >>boun...@yoctoproject.org] On Behalf Of Bodke, Kishore K >>Sent: Thursday, September 20, 2012 9:21 AM >>To: Przemyslaw Czesnowicz >>Cc: Samson, Don; Czesnowicz, PrzemyslawX; yocto@yoctoproject.org >>Subject: Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to >>Crystal Forest BSP. >> >> >> >>>-Original Message- >>>From: Przemysław Czesnowicz [mailto:czesiek...@gmail.com] >>>Sent: Thursday, September 20, 2012 3:58 AM >>>To: Bodke, Kishore K >>>Cc: Zanussi, Tom; Kamble, Nitin A; yocto@yoctoproject.org; Samson, Don; >>>Czesnowicz, PrzemyslawX >>>Subject: Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to >>>Crystal Forest BSP. >>> >>>2012/9/19 : From: Kishore Bodke Hi, This patch set adds three different types of Corpus files to Crystal Forest BSP, which are basically used to test the Lossless Compression algorithms. 1. calgary-corpus 2. canterbury-corpus 3. silesia-corpus These have been tested on both Crystal Forest Platforms. >>> >>>Hi >>> >>>Are those for the sample code of QA driver? >>>If so the sample code needs the corpus to be in one file >>> >>>tar -xf calgary.tar.gz -O > calgary >>> >>>Also the CrystalForest software package includes the >>> calgary and canterbury corpus files, at least in 0.9.0 version >>> >> >>Yes. These are for the QuickAssist Driver. >>All the sample corpus data files will be installed under /lib/firmware, at >>least >>with the 0.9.0-144 version QA driver, that I had tested. >> >>Instead of having all of files in one package and having one recipe, I had >>split >>them to multiple recipes. >> > > If you are talking about the Calgary and Canterbury files that are part of > QAT Software package, > that are present in the sample_code/performance/compression, then, Yes, they > will stay inside the QAT Software Package. > > But these are the external to the QAT package. > > Thanks > Kishore. Ok, then Thanks ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Any hints when building boost-nativesdk?
Hi,
I am running Yocto 1.2 and would like to include the boost development
environment in my SDK. I created a bbappend for the boost recipe that
only contains two lines:
PR = "${INC_PR}.1"
BBCLASSEXTEND += "nativesdk"
When I build with the above I get the following warnings:
NOTE: multiple providers are available for runtime boost-date-time (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-date-time
NOTE: multiple providers are available for runtime boost-filesystem (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-filesystem
NOTE: multiple providers are available for runtime boost-graph (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-graph
NOTE: multiple providers are available for runtime boost-iostreams (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-iostreams
NOTE: multiple providers are available for runtime boost-program-options
(boost, boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match
boost-program-options
NOTE: multiple providers are available for runtime boost-regex (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-regex
NOTE: multiple providers are available for runtime boost-signals (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-signals
NOTE: multiple providers are available for runtime boost-system (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-system
NOTE: multiple providers are available for runtime boost-test (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-test
NOTE: multiple providers are available for runtime boost-thread (boost,
boost-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match boost-thread
It seems a bit strange that "boost-nativesdk" is seen as a provider for
any of those runtime components. Any hints what I should change to build
things correctly?
Thank you very much
Reinette
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to Crystal Forest BSP.
>-Original Message- >From: yocto-boun...@yoctoproject.org [mailto:yocto- >boun...@yoctoproject.org] On Behalf Of Bodke, Kishore K >Sent: Thursday, September 20, 2012 9:21 AM >To: Przemyslaw Czesnowicz >Cc: Samson, Don; Czesnowicz, PrzemyslawX; yocto@yoctoproject.org >Subject: Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to >Crystal Forest BSP. > > > >>-Original Message- >>From: Przemysław Czesnowicz [mailto:czesiek...@gmail.com] >>Sent: Thursday, September 20, 2012 3:58 AM >>To: Bodke, Kishore K >>Cc: Zanussi, Tom; Kamble, Nitin A; yocto@yoctoproject.org; Samson, Don; >>Czesnowicz, PrzemyslawX >>Subject: Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to >>Crystal Forest BSP. >> >>2012/9/19 : >>> From: Kishore Bodke >>> >>> Hi, >>> >>> This patch set adds three different types of Corpus files >>> to Crystal Forest BSP, which are basically used to test the >>> Lossless Compression algorithms. >>> >>> 1. calgary-corpus >>> 2. canterbury-corpus >>> 3. silesia-corpus >>> >>> These have been tested on both Crystal Forest Platforms. >>> >> >>Hi >> >>Are those for the sample code of QA driver? >>If so the sample code needs the corpus to be in one file >> >>tar -xf calgary.tar.gz -O > calgary >> >>Also the CrystalForest software package includes the >> calgary and canterbury corpus files, at least in 0.9.0 version >> > >Yes. These are for the QuickAssist Driver. >All the sample corpus data files will be installed under /lib/firmware, at >least >with the 0.9.0-144 version QA driver, that I had tested. > >Instead of having all of files in one package and having one recipe, I had >split >them to multiple recipes. > If you are talking about the Calgary and Canterbury files that are part of QAT Software package, that are present in the sample_code/performance/compression, then, Yes, they will stay inside the QAT Software Package. But these are the external to the QAT package. Thanks Kishore. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel
-Original Message- From: Zanussi, Tom Sent: Wednesday, September 19, 2012 7:38 PM To: Bruce Ashfield Cc: Mihai Lindner; Development list for the linux-yocto*.git Linux kernel repositories; yocto@yoctoproject.org; Darren Hart; Bodke, Kishore K; Saxena, Rahul Subject: Re: [linux-yocto] [yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel On Wed, 2012-09-19 at 19:56 -0400, Bruce Ashfield wrote: > On 12-09-19 04:54 PM, Mihai Lindner wrote: > > On 2012-09-19 23:32, Bruce Ashfield wrote: > >> On 12-09-19 04:22 PM, Bruce Ashfield wrote: > >>> On 12-09-19 03:39 PM, Mihai Lindner wrote: > On 2012-09-19 22:01, Bruce Ashfield wrote: > > On 12-09-19 11:56 AM, Mihai Lindner wrote: > >> On 2012-09-19 18:43, Bruce Ashfield wrote: > >>> On 12-09-18 10:46 AM, Mihai Lindner wrote: > On 2012-09-18 17:23, Tom Zanussi wrote: > > On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote: > >> On 2012-09-18 16:49, Tom Zanussi wrote: > >>> On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote: > On 12-09-18 01:59 AM, Mihai Lindner wrote: > > Please pull into linux-yocto-3.0, meta. > > > > Adding linux-yocto, Darren and Tom. > > This looks fine to me, and we should consider it for all > the repositories, not just 3.0. > > Tom/Darren. Any side effects you can think of for this change ? > > >>> > >>> No, but shouldn't it already be there, inherited from base.cfg? > >> > >> For cedartrail, at least, standard.cfg is used. > >> > > > > And standard inherits from base, so it should be turned on. > > Somehow it's getting turned off in cedartrail... > > Yes, it the final .config file is turned off. Solved it by > setting it in boot-live. > --Mihai > >>> > >>> To follow up on this, is someone taking a closer look at this > >>> config to see if we can get a root cause for that option being > >>> disabled for this board ? > >>> > >>> I won't be able to poke at it myself for another day or so. > >>> > >>> Bruce > >>> > >> I'm still digging on this, trying to figure out what cfg files > >> are included / omitted by `configme` and why. > >> base.cfg is not included, nor stanadrd.cfg it seems. > >> The list of included cfg files is way to short. > > > > That likely means the BSP .scc file is missing and update (i.e. > > does it still have scc_leaf?) and the tools aren't finding it > > and auto-generating something to get you up and running. > > > > I just checked the meta branch here, and it looks to be updated, > > but if you look at your build's linux source dir, what's in > > meta/top_tgt ? > > > > Bruce > > > In meta/top_tgt i have: > > /home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto > -3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d1 > 15ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/ > bsp/cedartrail/cedartrail-standard.scc > > > > I've also hit an error, after more verbose runs of > ./cedartrail-standard in meta/cfg/scratch/obj/: > > ./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17: > standard_5b57715386592f694588063dd3ec6ebb: command not found > > After this the scripts stops. > > >>> > >>> Aha. This definitely breaks the configuration chain (and would > >>> throw a hard error in the 3.4 kernel) and is where the options > >>> drop. But this should no way be specific to this board. I'll get > >>> something configured here, since I need to see this happen in front of me. > >> > >> I've finally reproduced this. Leave the issue with me and I'll get > >> back to you with a fix. > >> > >> Bruce > > > > Yay! Thanks. > > It's not specific, it's just easier to hit; for cedartrail only 3.0 is > > available, and also set as preferred. > > > > Aha. I was right. It is a tools issue and a interface that changed. > I made a fix for this in the 3.0 kernel tree some time ago, but I > didn't update the lagging BSPs, and the handoff to a meta-intel change > was missed. > > With this change (sorry for the linewraps, I'm out of the office): > > --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend > b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend > index 35c4755..212a400 100644 > --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend > +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend > @@ -16,7 +16,7 @@ KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail" > KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc" > > SRCREV_machine_pn-linux-yocto_cedartrail ?= > "1e79e03d115ed177882ab539
Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to Crystal Forest BSP.
>-Original Message- >From: Przemysław Czesnowicz [mailto:czesiek...@gmail.com] >Sent: Thursday, September 20, 2012 3:58 AM >To: Bodke, Kishore K >Cc: Zanussi, Tom; Kamble, Nitin A; yocto@yoctoproject.org; Samson, Don; >Czesnowicz, PrzemyslawX >Subject: Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to >Crystal Forest BSP. > >2012/9/19 : >> From: Kishore Bodke >> >> Hi, >> >> This patch set adds three different types of Corpus files >> to Crystal Forest BSP, which are basically used to test the >> Lossless Compression algorithms. >> >> 1. calgary-corpus >> 2. canterbury-corpus >> 3. silesia-corpus >> >> These have been tested on both Crystal Forest Platforms. >> > >Hi > >Are those for the sample code of QA driver? >If so the sample code needs the corpus to be in one file > >tar -xf calgary.tar.gz -O > calgary > >Also the CrystalForest software package includes the > calgary and canterbury corpus files, at least in 0.9.0 version > Yes. These are for the QuickAssist Driver. All the sample corpus data files will be installed under /lib/firmware, at least with the 0.9.0-144 version QA driver, that I had tested. Instead of having all of files in one package and having one recipe, I had split them to multiple recipes. Thanks Kishore. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] source added to -dbg pkg
> I would like to NOT put the source code within the ${PN}-dbg pkg and
> keep it separate from my symbol binaries in that pkg. Is there a way to
> either turn off the collection of the source or allow me to put it in a
> different pkg. It could be useful to have some cases but not in all.
I just figured out I could move it to it's own pkg using this:
PACKAGES =+ " ${PN}-src "
FILES_${PN}-src = "${DEBUGFILESDIRECTORY-dbg}"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] source added to -dbg pkg
I would like to NOT put the source code within the ${PN}-dbg pkg and
keep it separate from my symbol binaries in that pkg. Is there a way to
either turn off the collection of the source or allow me to put it in a
different pkg. It could be useful to have some cases but not in all.
I have been using OE classic for years and just started using oe-core,
so this surprised me that it was doing this under the covers without
having to install it in the image dir first.
Thanks.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake check out from svn
Yes, I'm trying to fetch from tip. and yes I've got all the parameters
you mentioned.
The strange thing, bitbake is recognizing the Last Changed Rev: 78205 but
not doing the actual checkout!
NOTE: package web-browser-1.0+svnr*78205*-r6: task do_fetch: Started
WARNING: Failed to fetch URL
svn://svn.ad-group.adh/svn/dev_repos/Generation3_app;module=trunk;proto=http
..
...
/bin:/opt/sh-elf/bin:/opt/insight.sh-elf/bin:/usr/local/cwSDK/cwvx/bin:/opt/arm-elf-insight/bin:/opt/android-sdk-linux_x86/platform-tools/:/home/telsherbiny/work/fsl/sources/poky/scripts:/home/telsherbiny/work/fsl/sources/poky/scripts:/home/telsherbiny/work/fsl/sources/poky/scripts:/home/telsherbiny/work/fsl/sources/poky/scripts";
/usr/bin/env svn update -r *78205* could not be run:
None
ERROR: Function failed: Fetcher failure for URL:
'svn://svn.ad-group.adh/svn/dev_repos/Generation3_app;module=trunk;proto=http'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/home/telsherbiny/work/fsl/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/web-browser-1.0+svnr78205-r6/temp/log.do_fetch.19552
NOTE: package web-browser-1.0+svnr*78205*-r6: task do_fetch: Failed
On Thu, Sep 20, 2012 at 3:15 PM, Cliff Brake wrote:
> On Thu, Sep 20, 2012 at 8:26 AM, Tarek El-Sherbiny <
> tarek.elsherb...@gmail.com> wrote:
>
>> I'm writing a recipe to checkout files from local svn. Here is my URI:
>>
>> SRC_URI =
>> "svn://svn.ad-group.adh/svn/dev_repos/Generation3_app;module=trunk;protocol=http"
>>
>
> Are you trying to fetch from the tip of the trunk? In this case, you may
> need something like:
>
> SRCREV = "${AUTOREV}"
> PV = "1.0+svnr${SRCPV}"
> PR = "r6"
>
> SRC_URI = "svn://;module=monitor4;proto=https"
>
> Cliff
>
> --
> =
> http://bec-systems.com
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake check out from svn
On Thu, Sep 20, 2012 at 8:26 AM, Tarek El-Sherbiny <
tarek.elsherb...@gmail.com> wrote:
> I'm writing a recipe to checkout files from local svn. Here is my URI:
>
> SRC_URI =
> "svn://svn.ad-group.adh/svn/dev_repos/Generation3_app;module=trunk;protocol=http"
>
Are you trying to fetch from the tip of the trunk? In this case, you may
need something like:
SRCREV = "${AUTOREV}"
PV = "1.0+svnr${SRCPV}"
PR = "r6"
SRC_URI = "svn://;module=monitor4;proto=https"
Cliff
--
=
http://bec-systems.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
Fortunately, you caught me before I pulled out a bigger hammer. :-} I was going to report that this still didn't work after typing: % bitbake -c cleanstate But re-reading your post, I saw that there were supposed to be two 'esses'[!] The following: % bitbake kmod -c cleansstate % bitbake kmod does, in fact, seem to have worked for me. Thanks, guys, for your help! On Thu, Sep 20, 2012 at 9:42 AM, Paul Eggleton wrote: > On Thursday 20 September 2012 09:30:19 Evade Flow wrote: >> I guess I'll try the BFI approach of restarting the build from scratch next. >> `:-o. > > We'd really rather people didn't do this as it does not help us to diagnose > and fix problems. > >> Incidentally, searching the OpenEmbedded manual for 'cleanslate' >> turns up no hits. Is this some kind of 'secret' command? Where can I learn >> about other such commands? > > As Gary pointed out the command is "cleansstate". The OpenEmbedded manual has > not been kept up-to-date I'm afraid - but the good news is there is an up-to- > date and comprehensive set of documentation set provided by the Yocto Project > here: > > http://www.yoctoproject.org/documentation > > FYI you can do "bitbake -c listtasks " which will list all of the > valid tasks, you can remove do_ from the start of these to get commands you > can use with -c. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to do the specified tasks instead of many default
Dear Paul, Thanks a lot for your suggestion.Maybe in the future I will change the original Buildroot makefiles in my project to make the build easy and code convenient management. ---Liu -- Original -- From: "Paul Eggleton"; Date: Thu, Sep 20, 2012 09:57 PM To: "Liu"; Cc: "yocto"; Subject: Re: [yocto] How to do the specified tasks instead of many default On Thursday 20 September 2012 21:50:42 Liu wrote: > I know it probably not be right to do in such way.But my project is > built by buildroot,So I just need to run make to build the image.And now > I want to use bitbake to build the project instead of buildroot.Then I > think of the idea to use recipes to "do_fetch","do_unpack",and > "oe_runmake" to build the packages. I guess I would recommend if you're going to migrate to building with bitbake that you make more of a migration towards standard recipes - I'm not sure exactly where you will end up with your current approach but it sounds like you won't get much benefit by just calling into the original Buildroot makefiles over just continuing to use Buildroot on its own. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to do the specified tasks instead of many default
On Thursday 20 September 2012 21:50:42 Liu wrote: > I know it probably not be right to do in such way.But my project is > built by buildroot,So I just need to run make to build the image.And now > I want to use bitbake to build the project instead of buildroot.Then I > think of the idea to use recipes to "do_fetch","do_unpack",and > "oe_runmake" to build the packages. I guess I would recommend if you're going to migrate to building with bitbake that you make more of a migration towards standard recipes - I'm not sure exactly where you will end up with your current approach but it sounds like you won't get much benefit by just calling into the original Buildroot makefiles over just continuing to use Buildroot on its own. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to do the specified tasks instead of many default
Dear Paul, I know it probably not be right to do in such way.But my project is built by buildroot,So I just need to run make to build the image.And now I want to use bitbake to build the project instead of buildroot.Then I think of the idea to use recipes to "do_fetch","do_unpack",and "oe_runmake" to build the packages. For this reason I came up with the question of what I have been asking. Thanks, Liu -- Original -- From: "Paul Eggleton"; Date: Thu, Sep 20, 2012 09:30 PM To: "Liu"; Cc: "yocto"; Subject: Re: [yocto] How to do the specified tasks instead of many default On Thursday 20 September 2012 21:11:49 Liu wrote: > I have some packages built by a set of Makefiles,and want to build them > using bitbake.So I used recipes to invoke Makefiles to do > fetch,unpack,patch,compile tasks.But I do not need to do the following > tasks like do_build,do_package. > In the default conditions,there exist list > of packages by using the command like "bitbake busybox -c listtasks". With > your idea I can disable tasks by do_package[noexec] = "1". But then it > needs to do many similar works to disable tasks I do not need in all my > package recipes.So I want to know if there is a direct way to disable > default tasks defined in .bbclass. Thanks, I understand what you are trying to do but I still don't understand why. Do you not want to be able to produce images? If you really do want to do this you could set this at a global level either in local.conf or a distro configuration file. If you do this however you will at least need to allow do_populate_sysroot to run or many things will break. I won't be surprised if you experience other problems as well. I think it's fair to say you are stepping outside of the bounds of what is normally supported with the metadata we provide (although it is not outside of supported BitBake behaviour). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
On Thursday 20 September 2012 09:30:19 Evade Flow wrote: > I guess I'll try the BFI approach of restarting the build from scratch next. > `:-o. We'd really rather people didn't do this as it does not help us to diagnose and fix problems. > Incidentally, searching the OpenEmbedded manual for 'cleanslate' > turns up no hits. Is this some kind of 'secret' command? Where can I learn > about other such commands? As Gary pointed out the command is "cleansstate". The OpenEmbedded manual has not been kept up-to-date I'm afraid - but the good news is there is an up-to- date and comprehensive set of documentation set provided by the Yocto Project here: http://www.yoctoproject.org/documentation FYI you can do "bitbake -c listtasks " which will list all of the valid tasks, you can remove do_ from the start of these to get commands you can use with -c. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 24/25] documentation/Makefile: Support for making Eclipse HTML yocto project qs manual
From: Timo Mueller This target will generate eclipse help for the yocto-project-qs using the yocto-project-qs-eclipse-customization.xsl stylesheet. The output will be generated to a separate directory which can be used for integrating the documentation into eclipse. --- documentation/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 2887a95..1a29af5 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -275,7 +275,7 @@ endif eclipse: BASE_DIR = html/$(DOC)/ eclipse: -ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-manual poky-ref-manual),) +ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-manual poky-ref-manual yocto-project-qs),) @echo " " @echo "ERROR: You can only create eclipse documentation" @echo " of the following documentation parts:" @@ -287,6 +287,7 @@ ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-manual poky-ref-ma @echo " - The Yocto Project Kernel Architecture and" @echo " Use Manual (kernel-manual)" @echo " - The Yocto Project Reference Manual (poky-ref-manual)" + @echo " - The Yocto Project Quick Start (yocto-project-qs)" @echo " " else cd $(DOC) && \ -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 23/25] documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl: new file
From: Timo Mueller This stylesheet uses the eclipse stylesheets of docbook to create eclipse help from this documentation. In addition to simple html files these stylesheets will also create xml files which are needed to integrate the documentation into eclipse (e.g. toc.xml). --- .../yocto-project-qs-eclipse-customization.xsl | 20 1 files changed, 20 insertions(+), 0 deletions(-) create mode 100644 documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl diff --git a/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl new file mode 100644 index 000..cff787f --- /dev/null +++ b/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl @@ -0,0 +1,20 @@ + +http://www.w3.org/1999/XSL/Transform"; + xmlns="http://www.w3.org/1999/xhtml"; + xmlns:fo="http://www.w3.org/1999/XSL/Format"; + version="1.0"> + + http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl"; /> + + + + + + + + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 22/25] documentation: Move yocto-project-qs global parameters to customization file
From: Timo Mueller Standard stylesheet parameters were moved to the docbook customization file tying them to the docbook stylesheet used. Removing these parameters simplifies the Makefile. --- documentation/Makefile |3 +-- .../yocto-project-qs-customization.xsl |2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 33ebd3c..2887a95 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -129,8 +129,7 @@ STYLESHEET = $(DOC)/*.css endif ifeq ($(DOC),yocto-project-qs) -XSLTOPTS = --stringparam html.stylesheet qs-style.css \ - --xinclude +XSLTOPTS = --xinclude ALLPREQ = html tarball TARFILES = yocto-project-qs.html qs-style.css figures/yocto-environment.png figures/building-an-image.png figures/using-a-pre-built-image.png figures/yocto-project-transp.png MANUALS = $(DOC)/$(DOC).html diff --git a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl index 8e6ea34..904289a 100644 --- a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl +++ b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl @@ -4,5 +4,5 @@ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"; /> - + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 19/25] documentation/Makefile: Support for making Eclipse HTML poky ref manual
From: Timo Mueller This target will generate eclipse help for the poky-ref-manual using the poky-ref-manual-eclipse-customization.xsl stylesheet. The output will be generated to a separate directory which can be used for integrating the documentation into eclipse. --- documentation/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 17f7cf5..ba26214 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -276,7 +276,7 @@ endif eclipse: BASE_DIR = html/$(DOC)/ eclipse: -ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-manual),) +ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-manual poky-ref-manual),) @echo " " @echo "ERROR: You can only create eclipse documentation" @echo " of the following documentation parts:" @@ -287,6 +287,7 @@ ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-manual),) @echo " - The Yocto Project Development Manual (dev-manual)" @echo " - The Yocto Project Kernel Architecture and" @echo " Use Manual (kernel-manual)" + @echo " - The Yocto Project Reference Manual (poky-ref-manual)" @echo " " else cd $(DOC) && \ -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 20/25] documentation/poky-ref-manual/poky-ref-manual.xml: Added Title tag
From: Timo Mueller The title of the document used to create metadata for output formats such as eclipse help. --- documentation/poky-ref-manual/poky-ref-manual.xml |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/documentation/poky-ref-manual/poky-ref-manual.xml b/documentation/poky-ref-manual/poky-ref-manual.xml index e405375..61497d5 100644 --- a/documentation/poky-ref-manual/poky-ref-manual.xml +++ b/documentation/poky-ref-manual/poky-ref-manual.xml @@ -16,7 +16,9 @@ - + + The Yocto Project Reference Manual + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 25/25] documentation/Makefile: logic to make all for yocto-project-qs and cleanup
From: Timo Mueller Eclipse help documents are now created when calling the 'make all' target on the yocto-project-qs. Resulting files are archived into the tarball as well. When calling 'make clean' artefacts of the eclipse documentation build are deleted. --- documentation/Makefile |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 1a29af5..4965c30 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -130,9 +130,12 @@ endif ifeq ($(DOC),yocto-project-qs) XSLTOPTS = --xinclude -ALLPREQ = html tarball -TARFILES = yocto-project-qs.html qs-style.css figures/yocto-environment.png figures/building-an-image.png figures/using-a-pre-built-image.png figures/yocto-project-transp.png -MANUALS = $(DOC)/$(DOC).html +ALLPREQ = html eclipse tarball +TARFILES = yocto-project-qs.html qs-style.css figures/yocto-environment.png \ + figures/building-an-image.png figures/using-a-pre-built-image.png \ + figures/yocto-project-transp.png \ + eclipse +MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse FIGURES = figures STYLESHEET = $(DOC)/*.css endif -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 17/25] documentation: Move poky-ref-manual global parameters to customization file
From: Timo Mueller Standard stylesheet parameters were moved to the docbook customization file tying them to the docbook stylesheet used. Removing these parameters simplifies the Makefile. --- documentation/Makefile |7 +-- .../poky-ref-manual-customization.xsl |5 + 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 23b4d9f..17f7cf5 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -194,12 +194,7 @@ STYLESHEET = $(DOC)/*.css endif ifeq ($(DOC),poky-ref-manual) -XSLTOPTS = --stringparam html.stylesheet ref-style.css \ - --stringparam chapter.autolabel 1 \ - --stringparam appendix.autolabel A \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --xinclude +XSLTOPTS = --xinclude ALLPREQ = html pdf tarball TARFILES = poky-ref-manual.html ref-style.css figures/poky-title.png MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf diff --git a/documentation/poky-ref-manual/poky-ref-manual-customization.xsl b/documentation/poky-ref-manual/poky-ref-manual-customization.xsl index 362ebed..3ad3a31 100644 --- a/documentation/poky-ref-manual/poky-ref-manual-customization.xsl +++ b/documentation/poky-ref-manual/poky-ref-manual-customization.xsl @@ -3,4 +3,9 @@ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"; /> + + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 18/25] documentation/poky-ref-manual/poky-ref-manual-eclipse-customization.xsl: new file
From: Timo Mueller This stylesheet uses the eclipse stylesheets of docbook to create eclipse help from this documentation. In addition to simple html files these stylesheets will also create xml files which are needed to integrate the documentation into eclipse (e.g. toc.xml). --- .../poky-ref-manual-eclipse-customization.xsl | 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 documentation/poky-ref-manual/poky-ref-manual-eclipse-customization.xsl diff --git a/documentation/poky-ref-manual/poky-ref-manual-eclipse-customization.xsl b/documentation/poky-ref-manual/poky-ref-manual-eclipse-customization.xsl new file mode 100644 index 000..40181e2 --- /dev/null +++ b/documentation/poky-ref-manual/poky-ref-manual-eclipse-customization.xsl @@ -0,0 +1,21 @@ + +http://www.w3.org/1999/XSL/Transform"; + xmlns="http://www.w3.org/1999/xhtml"; + xmlns:fo="http://www.w3.org/1999/XSL/Format"; + version="1.0"> + + http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl"; /> + + + + + + + + + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 21/25] documentation/Makefile: logic to make all for poky-ref-manual and cleanup
From: Timo Mueller Eclipse help documents are now created when calling the 'make all' target on the poky-ref-manual. Resulting files are archived into the tarball as well. When calling 'make clean' artefacts of the eclipse documentation build are deleted. --- documentation/Makefile |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index ba26214..33ebd3c 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -195,9 +195,9 @@ endif ifeq ($(DOC),poky-ref-manual) XSLTOPTS = --xinclude -ALLPREQ = html pdf tarball -TARFILES = poky-ref-manual.html ref-style.css figures/poky-title.png -MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf +ALLPREQ = html pdf eclipse tarball +TARFILES = poky-ref-manual.html ref-style.css figures/poky-title.png eclipse +MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse FIGURES = figures STYLESHEET = $(DOC)/*.css endif -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 16/25] documentation/Makefile: logic to make all for kernel-manual and cleanup
From: Timo Mueller Eclipse help documents are now created when calling the 'make all' target on the kernel-manual. Resulting files are archived into the tarball as well. When calling 'make clean' artefacts of the eclipse documentation build are deleted. --- documentation/Makefile |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index f64e21c..23b4d9f 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -220,9 +220,11 @@ endif ifeq ($(DOC),kernel-manual) XSLTOPTS = --xinclude -ALLPREQ = html pdf tarball -TARFILES = kernel-manual.html kernel-manual.pdf kernel-style.css figures/kernel-title.png figures/kernel-architecture-overview.png -MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf +ALLPREQ = html pdf eclipse tarball +TARFILES = kernel-manual.html kernel-manual.pdf kernel-style.css \ + figures/kernel-title.png figures/kernel-architecture-overview.png \ + eclipse +MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse FIGURES = figures STYLESHEET = $(DOC)/*.css endif -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 15/25] documentation/kernel-manual/kernel-manual.xml: Added Title tag
From: Timo Mueller The title of the document used to create metadata for output formats such as eclipse help. --- documentation/kernel-manual/kernel-manual.xml |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/documentation/kernel-manual/kernel-manual.xml b/documentation/kernel-manual/kernel-manual.xml index 174663a..0d683ef 100644 --- a/documentation/kernel-manual/kernel-manual.xml +++ b/documentation/kernel-manual/kernel-manual.xml @@ -16,7 +16,9 @@ - + + The Yocto Project Kernel Architecture and Use Manual + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 14/25] documentation/Makefile: Support for making Eclipse HTML kernel manual
From: Timo Mueller This target will generate eclipse help for the kernel-manual using the kernel-manual-eclipse-customization.xsl stylesheet. The output will be generated to a separate directory which can be used for integrating the documentation into eclipse. --- documentation/Makefile |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 9b816a1..f64e21c 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -279,7 +279,7 @@ endif eclipse: BASE_DIR = html/$(DOC)/ eclipse: -ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual),) +ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-manual),) @echo " " @echo "ERROR: You can only create eclipse documentation" @echo " of the following documentation parts:" @@ -288,6 +288,8 @@ ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual),) @echo " - The Yocto Project Board Support Package" @echo " Developer's Guide (bsp-guide)" @echo " - The Yocto Project Development Manual (dev-manual)" + @echo " - The Yocto Project Kernel Architecture and" + @echo " Use Manual (kernel-manual)" @echo " " else cd $(DOC) && \ -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 13/25] documentation/kernel-manual/kernel-manual-eclipse-customization.xsl: new file
From: Timo Mueller This stylesheet uses the eclipse stylesheets of docbook to create eclipse help from this documentation. In addition to simple html files these stylesheets will also create xml files which are needed to integrate the documentation into eclipse (e.g. toc.xml). --- .../kernel-manual-eclipse-customization.xsl| 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 documentation/kernel-manual/kernel-manual-eclipse-customization.xsl diff --git a/documentation/kernel-manual/kernel-manual-eclipse-customization.xsl b/documentation/kernel-manual/kernel-manual-eclipse-customization.xsl new file mode 100644 index 000..2980869 --- /dev/null +++ b/documentation/kernel-manual/kernel-manual-eclipse-customization.xsl @@ -0,0 +1,21 @@ + +http://www.w3.org/1999/XSL/Transform"; + xmlns="http://www.w3.org/1999/xhtml"; + xmlns:fo="http://www.w3.org/1999/XSL/Format"; + version="1.0"> + + http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl"; /> + + + + + + + + + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 12/25] documentation: Move kernel-manual global parameters to customization file
From: Timo Mueller Standard stylesheet parameters were moved to the docbook customization file tying them to the docbook stylesheet used. Removing these parameters simplifies the Makefile. --- documentation/Makefile |7 +-- .../kernel-manual/kernel-manual-customization.xsl |7 +-- 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 02206b5..9b816a1 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -219,12 +219,7 @@ STYLESHEET = $(DOC)/*.css endif ifeq ($(DOC),kernel-manual) -XSLTOPTS = --stringparam html.stylesheet kernel-style.css \ - --stringparam chapter.autolabel 1 \ - --stringparam appendix.autolabel A \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --xinclude +XSLTOPTS = --xinclude ALLPREQ = html pdf tarball TARFILES = kernel-manual.html kernel-manual.pdf kernel-style.css figures/kernel-title.png figures/kernel-architecture-overview.png MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf diff --git a/documentation/kernel-manual/kernel-manual-customization.xsl b/documentation/kernel-manual/kernel-manual-customization.xsl index 8eb6905..6f46df2 100644 --- a/documentation/kernel-manual/kernel-manual-customization.xsl +++ b/documentation/kernel-manual/kernel-manual-customization.xsl @@ -3,6 +3,9 @@ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"; /> - - + + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 10/25] documentation/bsp-guide/bsp-guide.xml: Added Title tag
From: Timo Mueller The title of the document used to create metadata for output formats such as eclipse help. --- documentation/bsp-guide/bsp-guide.xml |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/documentation/bsp-guide/bsp-guide.xml b/documentation/bsp-guide/bsp-guide.xml index 3b7ab6a..c3629bd 100644 --- a/documentation/bsp-guide/bsp-guide.xml +++ b/documentation/bsp-guide/bsp-guide.xml @@ -16,7 +16,9 @@ - + + The Yocto Project Board Support Package Developer's Guide + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 11/25] documentation/Makefile: logic to make all for bsp guide and cleanup
From: Timo Mueller Eclipse help documents are now created when calling the 'make all' target on the bsp-guide. Resulting files are archived into the tarball as well. When calling 'make clean' artefacts of the eclipse documentation build are deleted. --- documentation/Makefile |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 815ab53..02206b5 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -71,9 +71,10 @@ ifeq ($(DOC),bsp-guide) XSLTOPTS = --xinclude -ALLPREQ = html pdf tarball -TARFILES = bsp-style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png -MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf +ALLPREQ = html pdf eclipse tarball +TARFILES = bsp-style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png \ + eclipse +MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse FIGURES = figures STYLESHEET = $(DOC)/*.css -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 07/25] documentation: Move bsp-guide global parameters to customization file
From: Timo Mueller Standard stylesheet parameters were moved to the docbook customization file tying them to the docbook stylesheet used. Removing these parameters simplifies the Makefile. --- documentation/Makefile |6 +- .../bsp-guide/bsp-guide-customization.xsl |4 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 45ba6b6..e601fef 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -70,11 +70,7 @@ # ifeq ($(DOC),bsp-guide) -XSLTOPTS = --stringparam html.stylesheet bsp-style.css \ - --stringparam chapter.autolabel 1 \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --xinclude +XSLTOPTS = --xinclude ALLPREQ = html pdf tarball TARFILES = bsp-style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf diff --git a/documentation/bsp-guide/bsp-guide-customization.xsl b/documentation/bsp-guide/bsp-guide-customization.xsl index 362ebed..5560289 100644 --- a/documentation/bsp-guide/bsp-guide-customization.xsl +++ b/documentation/bsp-guide/bsp-guide-customization.xsl @@ -3,4 +3,8 @@ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"; /> + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 09/25] documentation/Makefile: Support for making Eclipse HTML bsp guide
From: Timo Mueller This target will generate eclipse help for the bsp-guide using the bsp-guide-eclipse-customization.xsl stylesheet. The output will be generated to a separate directory which can be used for integrating the documentation into eclipse. --- documentation/Makefile |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index e601fef..815ab53 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -283,12 +283,14 @@ endif eclipse: BASE_DIR = html/$(DOC)/ eclipse: -ifeq ($(filter $(DOC), adt-manual dev-manual),) +ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual),) @echo " " @echo "ERROR: You can only create eclipse documentation" @echo " of the following documentation parts:" @echo " " @echo " - The Yocto Project Application Developer's Guide (adt-manual)" + @echo " - The Yocto Project Board Support Package" + @echo " Developer's Guide (bsp-guide)" @echo " - The Yocto Project Development Manual (dev-manual)" @echo " " else -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 05/25] documentation/dev-manual/dev-manual.xml: Added Title tag
From: Timo Mueller The title of the document used to create metadata for output formats such as eclipse help. --- documentation/dev-manual/dev-manual.xml |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/documentation/dev-manual/dev-manual.xml b/documentation/dev-manual/dev-manual.xml index 0cbd85f..9617fa0 100644 --- a/documentation/dev-manual/dev-manual.xml +++ b/documentation/dev-manual/dev-manual.xml @@ -16,7 +16,9 @@ - + + The Yocto Project Development Manual + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 08/25] documentation/bsp-guide/bsp-guide-eclipse-customization.xsl: new file
From: Timo Mueller This stylesheet uses the eclipse stylesheets of docbook to create eclipse help from this documentation. In addition to simple html files these stylesheets will also create xml files which are needed to integrate the documentation into eclipse (e.g. toc.xml). --- .../bsp-guide/bsp-guide-eclipse-customization.xsl | 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 documentation/bsp-guide/bsp-guide-eclipse-customization.xsl diff --git a/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl b/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl new file mode 100644 index 000..d85d901 --- /dev/null +++ b/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl @@ -0,0 +1,21 @@ + +http://www.w3.org/1999/XSL/Transform"; + xmlns="http://www.w3.org/1999/xhtml"; + xmlns:fo="http://www.w3.org/1999/XSL/Format"; + version="1.0"> + + http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl"; /> + + + + + + + + + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 06/25] documentation/Makefile: logic to make all for adt manual and cleanup
From: Timo Mueller Eclipse help documents are now created when calling the 'make all' target on the dev-manual. Resulting files are archived into the tarball as well. When calling 'make clean' artefacts of the eclipse documentation build are deleted. --- documentation/Makefile | 13 - 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 812a6d7..45ba6b6 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -85,7 +85,7 @@ endif ifeq ($(DOC),dev-manual) XSLTOPTS = --xinclude -ALLPREQ = html pdf tarball +ALLPREQ = html pdf eclipse tarball # # Note that the tarfile might produce the "Cannot stat: No such file or directory" error # message for .PNG files that are not present when building a particular branch. The @@ -101,7 +101,8 @@ TARFILES = dev-style.css dev-manual.html dev-manual.pdf \ figures/kernel-overview-1.png figures/kernel-overview-2.png \ figures/kernel-overview-3-edison.png \ figures/source-repos.png figures/yp-download.png \ - figures/wip.png + figures/wip.png \ + eclipse else ifeq ($(BRANCH),denzil) TARFILES = dev-style.css dev-manual.html dev-manual.pdf \ figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \ @@ -110,7 +111,8 @@ TARFILES = dev-style.css dev-manual.html dev-manual.pdf \ figures/kernel-overview-1.png figures/kernel-overview-2.png \ figures/kernel-overview-3-denzil.png \ figures/source-repos.png figures/yp-download.png \ - figures/wip.png + figures/wip.png \ + eclipse else TARFILES = dev-style.css dev-manual.html dev-manual.pdf \ figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \ @@ -119,10 +121,11 @@ TARFILES = dev-style.css dev-manual.html dev-manual.pdf \ figures/kernel-overview-1.png figures/kernel-overview-2.png \ figures/kernel-overview-3-denzil.png \ figures/source-repos.png figures/yp-download.png \ - figures/wip.png + figures/wip.png \ + eclipse endif -MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf +MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse FIGURES = figures STYLESHEET = $(DOC)/*.css -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 00/25][yocto-docs] Add eclipse help generation for remaining documents
From: Timo Mueller Hi, I've recently submitted a proof of concept showing how eclipse help files can be generated from the adt-manual using the docbook eclipse3.xsl stylesheet. These patches are currently in the temporary branch 'timo' in the yocto-docs git. This patch series fixes a small bug and adds eclipse help generation support for the other documentation parts. 1: Small bug fix stopping eclipse target when generation fails 2..6: Add eclipse generation to dev-manual 7..11: Add eclipse generation to bsp-guide 12..16: Add eclipse generation to kernel-manual 17..21: Add eclipse generation to poky-ref-manual 22..25: Add eclipse generation to yocto-project-qs Best regards, Timo Timo Mueller (25): documentation/Makefile: Stop eclipse target workflow if generation fails. documentation: Move dev-manual global parameters to customization file documentation/dev-manual/dev-manual-eclipse-customization.xsl: new file documentation/Makefile: Support for making Eclipse HTML dev manual documentation/dev-manual/dev-manual.xml: Added Title tag documentation/Makefile: logic to make all for adt manual and cleanup documentation: Move bsp-guide global parameters to customization file documentation/bsp-guide/bsp-guide-eclipse-customization.xsl: new file documentation/Makefile: Support for making Eclipse HTML bsp guide documentation/bsp-guide/bsp-guide.xml: Added Title tag documentation/Makefile: logic to make all for bsp guide and cleanup documentation: Move kernel-manual global parameters to customization file documentation/kernel-manual/kernel-manual-eclipse-customization.xsl: new file documentation/Makefile: Support for making Eclipse HTML kernel manual documentation/kernel-manual/kernel-manual.xml: Added Title tag documentation/Makefile: logic to make all for kernel-manual and cleanup documentation: Move poky-ref-manual global parameters to customization file documentation/poky-ref-manual/poky-ref-manual-eclipse-customization.xsl: new file documentation/Makefile: Support for making Eclipse HTML poky ref manual documentation/poky-ref-manual/poky-ref-manual.xml: Added Title tag documentation/Makefile: logic to make all for poky-ref-manual and cleanup documentation: Move yocto-project-qs global parameters to customization file documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl: new file documentation/Makefile: Support for making Eclipse HTML yocto project qs manual documentation/Makefile: logic to make all for yocto-project-qs and cleanup documentation/Makefile | 96 ++-- .../bsp-guide/bsp-guide-customization.xsl |4 + .../bsp-guide/bsp-guide-eclipse-customization.xsl | 21 + documentation/bsp-guide/bsp-guide.xml |4 +- .../dev-manual/dev-manual-customization.xsl|6 +- .../dev-manual-eclipse-customization.xsl | 21 + documentation/dev-manual/dev-manual.xml|4 +- .../kernel-manual/kernel-manual-customization.xsl |7 +- .../kernel-manual-eclipse-customization.xsl| 21 + documentation/kernel-manual/kernel-manual.xml |4 +- .../poky-ref-manual-customization.xsl |5 + .../poky-ref-manual-eclipse-customization.xsl | 21 + documentation/poky-ref-manual/poky-ref-manual.xml |4 +- .../yocto-project-qs-customization.xsl |2 +- .../yocto-project-qs-eclipse-customization.xsl | 20 15 files changed, 182 insertions(+), 58 deletions(-) create mode 100644 documentation/bsp-guide/bsp-guide-eclipse-customization.xsl create mode 100644 documentation/dev-manual/dev-manual-eclipse-customization.xsl create mode 100644 documentation/kernel-manual/kernel-manual-eclipse-customization.xsl create mode 100644 documentation/poky-ref-manual/poky-ref-manual-eclipse-customization.xsl create mode 100644 documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 02/25] documentation: Move dev-manual global parameters to customization file
From: Timo Mueller Standard stylesheet parameters were moved to the docbook customization file tying them to the docbook stylesheet used. Removing these parameters simplifies the Makefile. --- documentation/Makefile |6 +- .../dev-manual/dev-manual-customization.xsl|6 -- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 005d670..1e8b558 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -84,11 +84,7 @@ STYLESHEET = $(DOC)/*.css endif ifeq ($(DOC),dev-manual) -XSLTOPTS = --stringparam html.stylesheet dev-style.css \ - --stringparam chapter.autolabel 1 \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --xinclude +XSLTOPTS = --xinclude ALLPREQ = html pdf tarball # # Note that the tarfile might produce the "Cannot stat: No such file or directory" error diff --git a/documentation/dev-manual/dev-manual-customization.xsl b/documentation/dev-manual/dev-manual-customization.xsl index 8eb6905..8969605 100644 --- a/documentation/dev-manual/dev-manual-customization.xsl +++ b/documentation/dev-manual/dev-manual-customization.xsl @@ -3,6 +3,8 @@ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"; /> - - + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 01/25] documentation/Makefile: Stop eclipse target workflow if generation fails.
From: Timo Mueller --- documentation/Makefile |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 0537c22..005d670 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -295,13 +295,13 @@ ifneq ($(DOC),adt-manual) @echo " User's Guide" @echo " " else - cd $(DOC); \ + cd $(DOC) && \ xsltproc $(XSLTOPTS) \ --stringparam base.dir '$(BASE_DIR)' \ -o eclipse/$(DOC).html \ - $(DOC)-eclipse-customization.xsl $(DOC).xml; \ - mv eclipse/toc.xml eclipse/$(DOC)-toc.xml; \ - cp -rf $(FIGURES) eclipse/$(BASE_DIR)/$(FIGURES); \ + $(DOC)-eclipse-customization.xsl $(DOC).xml && \ + mv eclipse/toc.xml eclipse/$(DOC)-toc.xml && \ + cp -rf $(FIGURES) eclipse/$(BASE_DIR)/$(FIGURES) && \ cd .. endif -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 04/25] documentation/Makefile: Support for making Eclipse HTML dev manual
From: Timo Mueller This target will generate eclipse help for the dev-manual using the dev-manual-eclipse-customization.xsl stylesheet. The output will be generated to a separate directory which can be used for integrating the documentation into eclipse. --- documentation/Makefile | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/documentation/Makefile b/documentation/Makefile index 1e8b558..812a6d7 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -284,11 +284,13 @@ endif eclipse: BASE_DIR = html/$(DOC)/ eclipse: -ifneq ($(DOC),adt-manual) +ifeq ($(filter $(DOC), adt-manual dev-manual),) @echo " " - @echo "ERROR: You can only create eclipse documentation of the" - @echo " Yocto Project Application Development Toolkit (ADT)" - @echo " User's Guide" + @echo "ERROR: You can only create eclipse documentation" + @echo " of the following documentation parts:" + @echo " " + @echo " - The Yocto Project Application Developer's Guide (adt-manual)" + @echo " - The Yocto Project Development Manual (dev-manual)" @echo " " else cd $(DOC) && \ -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 03/25] documentation/dev-manual/dev-manual-eclipse-customization.xsl: new file
From: Timo Mueller This stylesheet uses the eclipse stylesheets of docbook to create eclipse help from this documentation. In addition to simple html files these stylesheets will also create xml files which are needed to integrate the documentation into eclipse (e.g. toc.xml). --- .../dev-manual-eclipse-customization.xsl | 21 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 documentation/dev-manual/dev-manual-eclipse-customization.xsl diff --git a/documentation/dev-manual/dev-manual-eclipse-customization.xsl b/documentation/dev-manual/dev-manual-eclipse-customization.xsl new file mode 100644 index 000..3463512 --- /dev/null +++ b/documentation/dev-manual/dev-manual-eclipse-customization.xsl @@ -0,0 +1,21 @@ + +http://www.w3.org/1999/XSL/Transform"; + xmlns="http://www.w3.org/1999/xhtml"; + xmlns:fo="http://www.w3.org/1999/XSL/Format"; + version="1.0"> + + http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl"; /> + + + + + + + + + + + + -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
On 2012-09-20 07:30, Evade Flow wrote:
Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still fail?
Thanks for the suggestion. I get this when I try to run 'bitbake kmod -c
cleanslate':
ERROR: Task do_cleanslate does not exist for target kmod
typo: it needs to be 'cleansstate'
Because I don't know any better, I tried this instead:
% bitbake kmod clean
% bitbake kmod
but it yielded the same result:
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
I guess I'll try the BFI approach of restarting the build from scratch next.
`:-o. Incidentally, searching the OpenEmbedded manual for 'cleanslate' turns
up no hits. Is this some kind of 'secret' command? Where can I learn about
other such commands?
On Wed, Sep 19, 2012 at 8:13 PM, Gary Thomas wrote:
On 2012-09-19 16:30, Evade Flow wrote:
I'm just trying to build the thing. :-) I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...
::SIGH:: I changed the SRC_URI var in kmod.inc from this:
SRC_URI =
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"
to this:
SRC_URI =
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"
SRCREV="8885ced062131214448fae056ef453f094303805"
This is *still* trying to access the network:
Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still fail?
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
ERROR: Logfile of failure stored in:
/home/dwolfe/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.11168
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
NOTE: package kmod-7-r0: task do_fetch: Failed
NOTE: package acl-2.2.51-r3: task do_fetch: Started
NOTE: package acl-2.2.51-r3: task do_fetch: Succeeded
ERROR: Task 1374
(/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to
be rerun and 1 failed.
Summary: 1 task failed:
/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image 16.51s user 2.65s system 112% cpu 17.031 total
Why is poky/bitbake/whatever running 'git ls-remote'? This seems like a
bug
On Wed, Sep 19, 2012 at 1:33 PM, Evade Flow wrote:
I'm not sure how to answer your questions, unfortunately, this is all
quite new to me. I'm not the maintainer of said layer, and don't know
anything at all yet about 'layer etiquette'. There does seem to be a
README.md file in meta-systemd, though:
-
http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md
I'm just trying to build the thing. :-) I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...
On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas wrote:
On 2012-09-19 11:15, Evade Flow wrote:
Where did you get that meta-systemd layer?
From here:
- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/
Why are there conflicting meta-systemd layers (and pointers thereto)??
This layer in git.yoctoproject.org doesn't seem even "legal" - where is
the README that is expected with every layer? Without it, I don't have
enough info to be able to report problems like yours...
The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
recipe refers to a git tag, not a specific revision, which cannot be
resolved without using the network.
On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas
wrote:
On 2012-09-19 10:34, Evade Flow wrote:
Trying to build the meta-ivi discovery-image behind a firewall is
proving to be quite a challenge. I tried modifying my conf/local.conf
file as follows:
CONNECTIVITY_CHECK_URIS=""
BB_GENERATE_MIRROR_TARBALLS = "1"
SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
INHERIT += "own-mirrors"
and then ran:
% bitbake discovery-image
in a VM on my home laptop over the weekend. (I'm trying to build
using
the meta-ivi layer, per the instructions in its README.) After
grinding
and churning for some 60+ hours, it finally succeeded, leaving 11 GB
of
'stuff' in my poky-mirror folder.
Then, I copied the poky-mirror folder to a firewalled machine at work
and added:
BB_NO_NETWORK="1"
to local.conf. Wh
Re: [yocto] How to do the specified tasks instead of many default
On Thursday 20 September 2012 21:11:49 Liu wrote: > I have some packages built by a set of Makefiles,and want to build them > using bitbake.So I used recipes to invoke Makefiles to do > fetch,unpack,patch,compile tasks.But I do not need to do the following > tasks like do_build,do_package. > In the default conditions,there exist list > of packages by using the command like "bitbake busybox -c listtasks". With > your idea I can disable tasks by do_package[noexec] = "1". But then it > needs to do many similar works to disable tasks I do not need in all my > package recipes.So I want to know if there is a direct way to disable > default tasks defined in .bbclass. Thanks, I understand what you are trying to do but I still don't understand why. Do you not want to be able to produce images? If you really do want to do this you could set this at a global level either in local.conf or a distro configuration file. If you do this however you will at least need to allow do_populate_sysroot to run or many things will break. I won't be surprised if you experience other problems as well. I think it's fair to say you are stepping outside of the bounds of what is normally supported with the metadata we provide (although it is not outside of supported BitBake behaviour). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd
> Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still fail?
Thanks for the suggestion. I get this when I try to run 'bitbake kmod -c
cleanslate':
ERROR: Task do_cleanslate does not exist for target kmod
Because I don't know any better, I tried this instead:
% bitbake kmod clean
% bitbake kmod
but it yielded the same result:
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
I guess I'll try the BFI approach of restarting the build from scratch next.
`:-o. Incidentally, searching the OpenEmbedded manual for 'cleanslate' turns
up no hits. Is this some kind of 'secret' command? Where can I learn about
other such commands?
On Wed, Sep 19, 2012 at 8:13 PM, Gary Thomas wrote:
> On 2012-09-19 16:30, Evade Flow wrote:
>>>
>>> I'm just trying to build the thing. :-) I'll try converting the tag
>>> name into a commit hash and see if that helps, thanks a lot...
>>
>>
>> ::SIGH:: I changed the SRC_URI var in kmod.inc from this:
>>
>>SRC_URI =
>> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"
>>
>> to this:
>>
>>SRC_URI =
>> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"
>>SRCREV="8885ced062131214448fae056ef453f094303805"
>>
>> This is *still* trying to access the network:
>
>
> Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still fail?
>
>
>> NOTE: package kmod-7-r0: task do_fetch: Started
>> ERROR: Function failed: Network access disabled through BB_NO_NETWORK
>> but access rquested with command git ls-remote
>> git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
>> 8885ced062131214448 (for url None)
>> ERROR: Logfile of failure stored in:
>>
>> /home/dwolfe/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.11168
>> Log data follows:
>> | ERROR: Function failed: Network access disabled through
>> BB_NO_NETWORK but access rquested with command git ls-remote
>> git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
>> 8885ced062131214448 (for url None)
>> NOTE: package kmod-7-r0: task do_fetch: Failed
>> NOTE: package acl-2.2.51-r3: task do_fetch: Started
>> NOTE: package acl-2.2.51-r3: task do_fetch: Succeeded
>> ERROR: Task 1374
>>
>> (/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
>> do_fetch) failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to
>> be rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>
>> /home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
>> do_fetch
>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>> bitbake discovery-image 16.51s user 2.65s system 112% cpu 17.031 total
>>
>>
>> Why is poky/bitbake/whatever running 'git ls-remote'? This seems like a
>> bug
>>
>>
>> On Wed, Sep 19, 2012 at 1:33 PM, Evade Flow wrote:
>>>
>>> I'm not sure how to answer your questions, unfortunately, this is all
>>> quite new to me. I'm not the maintainer of said layer, and don't know
>>> anything at all yet about 'layer etiquette'. There does seem to be a
>>> README.md file in meta-systemd, though:
>>>
>>>-
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md
>>>
>>> I'm just trying to build the thing. :-) I'll try converting the tag
>>> name into a commit hash and see if that helps, thanks a lot...
>>>
>>>
>>> On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas wrote:
On 2012-09-19 11:15, Evade Flow wrote:
>>
>>
>> Where did you get that meta-systemd layer?
>
>
>
>> From here:
>
>
>
> - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/
Why are there conflicting meta-systemd layers (and pointers thereto)??
This layer in git.yoctoproject.org doesn't seem even "legal" - where is
the README that is expected with every layer? Without it, I don't have
enough info to be able to report problems like yours...
The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
recipe refers to a git tag, not a specific revision, which cannot be
resolved without using the network.
>
>
> On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas
> wrote:
>>
>>
>> On 2012-09-19 10:34, Evade Flow wrote:
>>>
>>>
>>>
>>> Trying to build the meta-ivi discovery-image behind a firewall is
>>> proving to be quite a challenge. I tried modifying my conf/local.conf
>>> file as follows:
>>>
>>> CONNECTIVITY_CHECK_URIS=""
>>> BB_GENERATE_MIRROR_TARBALLS = "1"
>>> SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
>>> INHERIT += "own-mirrors"
>>>
>>> and then ran:
>>>
>>> % bitbak
Re: [yocto] How to do the specified tasks instead of many default
Dear Paul, I have some packages built by a set of Makefiles,and want to build them using bitbake.So I used recipes to invoke Makefiles to do fetch,unpack,patch,compile tasks.But I do not need to do the following tasks like do_build,do_package. In the default conditions,there exist list of packages by using the command like "bitbake busybox -c listtasks". With your idea I can disable tasks by do_package[noexec] = "1". But then it needs to do many similar works to disable tasks I do not need in all my package recipes.So I want to know if there is a direct way to disable default tasks defined in .bbclass. Thanks, Liu___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bitbake check out from svn
I'm writing a recipe to checkout files from local svn. Here is my URI: SRC_URI = "svn://svn.ad-group.adh/svn/dev_repos/Generation3_app;module=trunk;protocol=http" bitbake fails to fetch the source from this location and gives the bellow error message. Looks like bitbake is not replacing svn with http hence it's not querying a correct address. Why bitbake is not reading the protocol parameter and construct the correct address? NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Running task 1577 of 2240 (ID: 4, /home/telsherbiny/work/fsl/sources/meta-adh-console/recipes-web/web-browser/ web-browser_8.5.bb, do_fetch) NOTE: package web-browser-8.5-r1: task do_fetch: Started ERROR: Function failed: Fetcher failure: Fetch command export HOME="/home/telsherbiny"; export SSH_AGENT_PID="2398"; export SSH_AUTH_SOCK="/tmp/keyring-suRHPa/ssh"; export GIT_CONFIG="/home/telsherbiny/work/fsl/build/tmp/sysroots/i686-linux/etc/gitconfig"; export PATH="/home/telsherbiny/work/fsl/build/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi:/home/telsherbiny/work/fsl/build/tmp/sysroots/imx6qsabrelite/usr/bin/crossscripts:/home/telsherbiny/work/fsl/build/tmp/sysroots/i686-linux/usr/sbin:/home/telsherbiny/work/fsl/build/tmp/sysroots/i686-linux/usr/bin:/home/telsherbiny/work/fsl/build/tmp/sysroots/i686-linux/sbin:/home/telsherbiny/work/fsl/build/tmp/sysroots/i686-linux//bin:/home/telsherbiny/work/fsl/sources/poky/scripts:/home/telsherbiny/work/fsl/sources/poky/bitbake/bin/:/home/telsherbiny/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/openocd/bin:/opt/arm-elf/bin:/opt/arm-elf-insight/bin:/opt/sh-elf/bin:/opt/insight.sh-elf/bin:/usr/local/cwSDK/cwvx/bin:/opt/arm-elf-insight/bin:/opt/android-sdk-linux_x86/platform-tools/:/home/telsherbiny/work/fsl/sources/poky/scripts"; LANG=C LC_ALL=C /usr/bin/env svn info svn://svn.ad-group.adh/svn/dev_repos/Generation3_app/trunk/ could not be run: None ERROR: Logfile of failure stored in: /home/telsherbiny/work/fsl/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/web-browser-8.5-r1/temp/log.do_fetch.14696 Thanks ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to Crystal Forest BSP.
2012/9/19 : > From: Kishore Bodke > > Hi, > > This patch set adds three different types of Corpus files > to Crystal Forest BSP, which are basically used to test the > Lossless Compression algorithms. > > 1. calgary-corpus > 2. canterbury-corpus > 3. silesia-corpus > > These have been tested on both Crystal Forest Platforms. > Hi Are those for the sample code of QA driver? If so the sample code needs the corpus to be in one file tar -xf calgary.tar.gz -O > calgary Also the CrystalForest software package includes the calgary and canterbury corpus files, at least in 0.9.0 version Regards Przemek ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to do the specified tasks instead of many default ones
On Thursday 20 September 2012 17:59:56 Liu wrote: > That's not what i mean.I want to remove the tasks like > "do_build","do_package" from the default tasks list,and reserve the tasks > (do_fetch,do_unpack,do_compile) I need. I know there exist some dependency > between tasks and then generate a default list of tasks for all > packages.And now I just want to use the several tasks for my packages. Can > you tell me detally about how to remove the tasks "do_build" ,and the tasks > after "do_build" ? What do you mean by tasks after do_build? There should not be any, at least not for the same target. There are several ways of disabling tasks - the first that comes to mind is to mark the task as noexec, for example: do_package[noexec] = "1" My question would be though, what are you trying to achieve by doing this? Cheers, Paul PS: please reply on the mailing list, thanks. -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel
On 2012-09-20 05:38, Tom Zanussi wrote: > On Wed, 2012-09-19 at 19:56 -0400, Bruce Ashfield wrote: >> On 12-09-19 04:54 PM, Mihai Lindner wrote: >>> On 2012-09-19 23:32, Bruce Ashfield wrote: On 12-09-19 04:22 PM, Bruce Ashfield wrote: > On 12-09-19 03:39 PM, Mihai Lindner wrote: >> On 2012-09-19 22:01, Bruce Ashfield wrote: >>> On 12-09-19 11:56 AM, Mihai Lindner wrote: On 2012-09-19 18:43, Bruce Ashfield wrote: > On 12-09-18 10:46 AM, Mihai Lindner wrote: >> On 2012-09-18 17:23, Tom Zanussi wrote: >>> On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote: On 2012-09-18 16:49, Tom Zanussi wrote: > On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote: >> On 12-09-18 01:59 AM, Mihai Lindner wrote: >>> Please pull into linux-yocto-3.0, meta. >>> >> >> Adding linux-yocto, Darren and Tom. >> >> This looks fine to me, and we should consider it for all the >> repositories, >> not just 3.0. >> >> Tom/Darren. Any side effects you can think of for this change ? >> > > No, but shouldn't it already be there, inherited from base.cfg? For cedartrail, at least, standard.cfg is used. >>> >>> And standard inherits from base, so it should be turned on. Somehow >>> it's getting turned off in cedartrail... >> >> Yes, it the final .config file is turned off. Solved it by setting >> it in boot-live. >> --Mihai > > To follow up on this, is someone taking a closer look at this config > to see if we can get a root cause for that option being disabled for > this board ? > > I won't be able to poke at it myself for another day or so. > > Bruce > I'm still digging on this, trying to figure out what cfg files are included / omitted by `configme` and why. base.cfg is not included, nor stanadrd.cfg it seems. The list of included cfg files is way to short. >>> >>> That likely means the BSP .scc file is missing and update (i.e. does >>> it still have scc_leaf?) and the tools aren't finding it and >>> auto-generating something to get you up and running. >>> >>> I just checked the meta branch here, and it looks to be updated, but >>> if you look at your build's linux source dir, what's in meta/top_tgt ? >>> >>> Bruce >>> >> In meta/top_tgt i have: >> >> /home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc >> >> >> >> I've also hit an error, after more verbose runs of >> ./cedartrail-standard in meta/cfg/scratch/obj/: >> >> ./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17: >> standard_5b57715386592f694588063dd3ec6ebb: command not found >> >> After this the scripts stops. >> > > Aha. This definitely breaks the configuration chain (and would throw > a hard error in the 3.4 kernel) and is where the options drop. But this > should no way be specific to this board. I'll get something configured > here, since I need to see this happen in front of me. I've finally reproduced this. Leave the issue with me and I'll get back to you with a fix. Bruce >>> >>> Yay! Thanks. >>> It's not specific, it's just easier to hit; for cedartrail only 3.0 is >>> available, and also set as preferred. >>> >> >> Aha. I was right. It is a tools issue and a interface that changed. >> I made a fix for this in the 3.0 kernel tree some time ago, but >> I didn't update the lagging BSPs, and the handoff to a meta-intel >> change was missed. >> >> With this change (sorry for the linewraps, I'm out of the office): >> >> --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend >> b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend >> index 35c4755..212a400 100644 >> --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend >> +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend >> @@ -16,7 +16,7 @@ KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail" >> KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc" >> >> SRCREV_machine_pn-linux-yocto_cedartrail ?= >> "1e79e03d115ed177882ab53909a4f3555e434833" >> -SRCREV_meta_pn-linux-yocto_cedartrail ?= >> "46e8fc2bbbe73514e8d99101adaaa373f760ffa7" >> +SRCREV_meta_pn-linux-yocto_cedartrail ?= >> "bf5ee4945ee6d748e6abe16356f2357f76b5e2f0" >> SRCREV_pvr_pn-linux-yocto_cedartrail ?= >> "997f5644664b31ebefd6e16c451c4a3729eb378a" >> >> SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= >> "1e79
Re: [yocto] How to do the specified tasks instead of many default ones
On Thursday 20 September 2012 15:41:54 Liu wrote: > I'm compiling a test package "helloworld",then I just want to do the > standard tasks of "do_fetch","do_unpack" until the task "do_compile",and I > do not want to the next tasks like "do_build","do_package". I think there > exist the task dependency chain,but can hardly find how to remove the tasks > I do not want to do.Can anyone tell me something detailed about this > question ? If you mean for a single execution, just run "bitbake -c compile helloworld". Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to do the specified tasks instead of many default ones
Hi all, I'm compiling a test package "helloworld",then I just want to do the standard tasks of "do_fetch","do_unpack" until the task "do_compile",and I do not want to the next tasks like "do_build","do_package". I think there exist the task dependency chain,but can hardly find how to remove the tasks I do not want to do.Can anyone tell me something detailed about this question ? Best wishes, --Liu___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
