Re: [yocto] Selecting different kernel inside an image recipe

[Mike Looijmans]

There are several solutions:

- Pick one kernel as the "master" one. Create recipes for alternative kernels 
as required, but blank the (R)PROVIDES so that they do not "provide" a kernel 
and bitbake will treat them as yet another package to build. In the scripts 
that you use to deploy the images, pick the kernel that you want.


- Create a new MACHINE for each alternative.

- Set up multiple build environments, share the sstate-cache and similar 
directories. Each environment can then pick its own kernel etc.



On 04-08-15 06:15, Klaus Knopper wrote:

Hello Bruce & list,

I need to come back to the topic after quite some failed attempts to
solve the problem of switching kernel configurations specific to an
image recipe.

On Wed, Jul 08, 2015 at 01:30:54PM -0400, Bruce Ashfield wrote:

On 2015-07-08 12:36 PM, Klaus Knopper wrote:

Hello Leonardo,

On Wed, Jul 08, 2015 at 10:40:10AM -0500, Leonardo Sandoval wrote:

On 07/08/2015 09:50 AM, Klaus Knopper wrote:

Hello list,

I'm trying to build variantions/brands of an image that only differ in
kernel configuration and kernel modules included, but everything else stays
the same, for the exact same board, as in the main image.

Setting PREFERRED_PROVIDER_virtual/kernel = "different_kernel"
right inside in the new image recipe does not have any effect, as that
variable seems to be evaluated exclusively in the local.conf machine
file, which is read by all recipes.


This variable is commonly used inside configuration metadata (machine or
distro conf files). You may try it there.


Please help me to understand your answer: You are saying that I do have
to change the machine or distro config used for ALL recipes, to be able
to use a different kernel configuration in ONE recipe, right?

I was really trying to avoid that. :-(

So it is really not possible to just select a different kernel config
within a normal recipe without changing the global configuration?


You really want a different kernel recipe to provide that different
kernel configuration.  Which looks to be what you are describing, and
you just want to switch the provider (again, what you are saying).


Yes, and I had indeed already added a new kernel recipe, which builds
the desired kernel as uImage when calling "bitbake kernel-recipename"
directly, but it's ignored by the image recipes. All of them use only
the kernel that's defined in build/conf/local.conf as
PREFERRED_PROVIDER_virtual/kernel . Redefining the variable in the image
recipes has no effect.


Changing the included kernel via that different kernel recipe/package
name, and setting it via the preferred provider is the same as any
bitbake variable.


I thought so, but apparently I'mmissing something. It looks like
PREFERRED_PROVIDER_virtual/kernel only works in local.conf, i.e. I need
to fork the project or change the local.conf file each time I want to
use a different kernel. Is this a known or desired behavior?


So you should be able to set it in any .conf file, and then have what
you want.


So, can you confirm that it is not possible to set
PREFERRED_PROVIDER_virtual/kernel inside an image recipe?


I've used layers with layer.conf files, and similar mechanisms
to do what you are trying in the past .. but the longer serving oe/bitbake
folks may have a better example to point at.


If there are examples for a more convenient way to switch kernels in a
recipe rather than inside a .conf file, please point me to the right
direction.

Regards
-Klaus





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Stale warning?

[Paul Eggleton]

Hi Gary,

On Tuesday 04 August 2015 09:04:59 Gary Thomas wrote:
> While I was fixing the python3 nativesdk recipe, I ran this
> step a few times:
>$ bitbake nativesdk-python3 -C compile
> 
> After this, I get this warning:
>WARNING:
> virtual:nativesdk:/local/poky-cutting-edge/meta/recipes-devtools/python/pyt
> hon3_3.4.3.bb.do_compile is tainted from a forced run which seems quite
> reasonable.  Once I had the compile errors
> fixed, I moved the patches into the recipe and then rebuilt
> from scratch (just the nativesdk-python3).  Even though the
> package has been completely rebuilt (fetch/patch/...), I still
> get this warning, which doesn't seem right to me.  The warning
> only goes away if I clean the package:
>$ bitbake nativesdk-python3 -c clean

This is by design, although I would agree that it would be better if it were 
able to tell if it could reasonably remove the taint on a rebuild and do so 
automatically. Since this is something that's come up before (and I've 
lamented myself) I've filed an enhancement request so we have it tracked:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=8100

At the moment it's marked "future" as I can't make any commitment to 
implementing it any time soon - someone else is welcome to have a go though.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ADD GDB in FSL toolchain

[Luo Zhenhua]

Hi Sarayu, 

Do you want the gdb utility which can be executed on host machine or gdb stuffs 
of target machine? If the former, the utility is already 
included(/sysroots/x86_64-fslsdk-linux/usr/bin/arm-fsl-linux-gnueabi/arm-fsl-linux-gnueabi-gdb),
 if the latter, you can follow Khem's suggestion. 


Best Regards,

Zhenhua

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Khem Raj
> Sent: Wednesday, August 05, 2015 4:14 AM
> To: Sarayu Krishna Sivanandam
> Cc: yocto@yoctoproject.org; Gary Thomas
> Subject: Re: [yocto] ADD GDB in FSL toolchain
> 
> On Tue, Aug 4, 2015 at 5:42 AM, Sarayu Krishna Sivanandam
>  wrote:
> > hi Gary ,
> >
> > Thanks for the quick response. I still see the below error .
> >
> > NOTE: Resolving any missing task queue dependencies
> > ERROR: Nothing RPROVIDES 'gdb-cross-arm'
> > NOTE: Runtime target 'gdb-cross-arm' is unbuildable, removing...
> > Missing or unbuildable dependency chain was: ['gdb-cross-arm']
> > ERROR: Required build target 'fsl-toolchain' has no buildable providers.
> > Missing or unbuildable dependency chain was: ['fsl-toolchain',
> > 'gdb-cross-arm']
> 
> this is not a target task. Its a host-x-target tool you should add db-cross-
> canadian-${TRANSLATED_TARGET_ARCH}  to TOOLCHAIN_HOST_TASK
> 
> if you want gdb on target then you would add 'gdb' to
> TOOLCHAIN_TARGET_TASK
> 
> > -
> >
> > Below is how the change ,
> > TOOLCHAIN_TARGET_TASK += " \
> > glib-2.0 \
> > glib-2.0-dev \
> > dtc-staticdev \
> > libgomp \
> > libgomp-dev \
> > libgomp-staticdev \
> > libstdc++-staticdev \
> > ${TCLIBC}-staticdev \
> > util-linux-dev \
> > gdb-cross-arm \
> > "
> >
> >
> > Thanks and Regards,
> > Sarayu K S
> > Tech Lead
> > Zaikenn Technologies
> >
> > On Tue, Aug 4, 2015 at 5:21 PM, Gary Thomas  wrote:
> >>
> >> On 2015-08-04 03:31, Sarayu Krishna Sivanandam wrote:
> >>>
> >>> Hi all ,
> >>>
> >>> I am using the QorIQ-SDK-V1.8 SDK for the toolchain generation for
> >>> my ARM board .  I wanted to build gdb along with the toolchain . I
> >>> got some ideas from google to add the gdb-cross in the
> >>> fsl-toolchain.bb  but on doing the same it
> >>> gave me some errors when trying to build .
> >>>
> >>> Can you please let me know the right method to add gdb in the toolchain ?
> >>>
> >>> Below is the error i got ,
> >>> *ERROR: gdb-cross not found in the base feeds (ls1021atwr
> >>> cortexa7hf-vfp-neon cortexa7hf-vfp armv7ahf-vfp-neon armv7ahf-vfp
> >>> armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all).*
> >>
> >>
> >> Use gdb-cross-arm
> >>
> >> --
> >> 
> >> Gary Thomas |  Consulting for the
> >> MLB Associates  |Embedded world
> >> 
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 1.9 now available.

[Flanagan, Elizabeth]

The first milestone release for Yocto Project 1.9 is available for download now.

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.9_M1/

Thank you everyone for your contributions.

eclipse-poky/juno-master bbd410e2c5db9532ea373ec993c5e8d9
eclipse-poky/kepler-master 989ee9bda9c0d5c05e790a289d4ca032
eclipse-poky/luna-master fe928773cf7b952c368769fdc4be3688
meta-qt3 139394eca6575b9ab31d2f79f7830f2a
poky 59713c69884b4d459b0712133ba56034

Test report at
https://wiki.yoctoproject.org/wiki/WW28_-_2015-07-10_-_Full_Pass_1.9_M1.rc2

-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 1.9 now available.

[nick]

On 2015-08-05 10:45 AM, Flanagan, Elizabeth wrote:
> The first milestone release for Yocto Project 1.9 is available for download 
> now.
> 
> http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.9_M1/
> 
> Thank you everyone for your contributions.
> 
> eclipse-poky/juno-master bbd410e2c5db9532ea373ec993c5e8d9
> eclipse-poky/kepler-master 989ee9bda9c0d5c05e790a289d4ca032
> eclipse-poky/luna-master fe928773cf7b952c368769fdc4be3688
> meta-qt3 139394eca6575b9ab31d2f79f7830f2a
> poky 59713c69884b4d459b0712133ba56034
> 
> Test report at
> https://wiki.yoctoproject.org/wiki/WW28_-_2015-07-10_-_Full_Pass_1.9_M1.rc2
> 
Just a question about your testing Elizabeth. 
BB_NUMBER_THREADS = "8"
PARALLEL_MAKE = "-j 8"
MACHINE = "qemux86"
It should be 2 times the number of cores for parallel build systems like make
or bitbake. Why only eight as I do eight on my i5 from the same generation.
This seems like a error in my opinion.
Cheers,
Nick  
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 1.9 now available.

[Flanagan, Elizabeth]

On 5 August 2015 at 15:53, nick  wrote:
>
>
> On 2015-08-05 10:45 AM, Flanagan, Elizabeth wrote:
>> The first milestone release for Yocto Project 1.9 is available for download 
>> now.
>>
>> http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.9_M1/
>>
>> Thank you everyone for your contributions.
>>
>> eclipse-poky/juno-master bbd410e2c5db9532ea373ec993c5e8d9
>> eclipse-poky/kepler-master 989ee9bda9c0d5c05e790a289d4ca032
>> eclipse-poky/luna-master fe928773cf7b952c368769fdc4be3688
>> meta-qt3 139394eca6575b9ab31d2f79f7830f2a
>> poky 59713c69884b4d459b0712133ba56034
>>
>> Test report at
>> https://wiki.yoctoproject.org/wiki/WW28_-_2015-07-10_-_Full_Pass_1.9_M1.rc2
>>
> Just a question about your testing Elizabeth.
> BB_NUMBER_THREADS = "8"
> PARALLEL_MAKE = "-j 8"
> MACHINE = "qemux86"
> It should be 2 times the number of cores for parallel build systems like make
> or bitbake. Why only eight as I do eight on my i5 from the same generation.
> This seems like a error in my opinion.

These builds run concurrently with a number of other builds on our
servers. I don't remember exactly how many cores are on each, but this
limits the builds a bit to ensure that all concurrent builds have
adequate resources.

-b

> Cheers,
> Nick



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ADD GDB in FSL toolchain

[Sarayu Krishna Sivanandam]

Thanks for the reply . That worked for me . I was able to add gdb to my
toolchain.

Thanks and Regards,
Sarayu K S
Tech Lead
Zaikenn Technologies

On Wed, Aug 5, 2015 at 2:47 PM, Luo Zhenhua 
wrote:

> Hi Sarayu,
>
> Do you want the gdb utility which can be executed on host machine or gdb
> stuffs of target machine? If the former, the utility is already
> included(/sysroots/x86_64-fslsdk-linux/usr/bin/arm-fsl-linux-gnueabi/arm-fsl-linux-gnueabi-gdb),
> if the latter, you can follow Khem's suggestion.
>
>
> Best Regards,
>
> Zhenhua
>
> > -Original Message-
> > From: yocto-boun...@yoctoproject.org [mailto:yocto-
> > boun...@yoctoproject.org] On Behalf Of Khem Raj
> > Sent: Wednesday, August 05, 2015 4:14 AM
> > To: Sarayu Krishna Sivanandam
> > Cc: yocto@yoctoproject.org; Gary Thomas
> > Subject: Re: [yocto] ADD GDB in FSL toolchain
> >
> > On Tue, Aug 4, 2015 at 5:42 AM, Sarayu Krishna Sivanandam
> >  wrote:
> > > hi Gary ,
> > >
> > > Thanks for the quick response. I still see the below error .
> > >
> > > NOTE: Resolving any missing task queue dependencies
> > > ERROR: Nothing RPROVIDES 'gdb-cross-arm'
> > > NOTE: Runtime target 'gdb-cross-arm' is unbuildable, removing...
> > > Missing or unbuildable dependency chain was: ['gdb-cross-arm']
> > > ERROR: Required build target 'fsl-toolchain' has no buildable
> providers.
> > > Missing or unbuildable dependency chain was: ['fsl-toolchain',
> > > 'gdb-cross-arm']
> >
> > this is not a target task. Its a host-x-target tool you should add
> db-cross-
> > canadian-${TRANSLATED_TARGET_ARCH}  to TOOLCHAIN_HOST_TASK
> >
> > if you want gdb on target then you would add 'gdb' to
> > TOOLCHAIN_TARGET_TASK
> >
> > > -
> > >
> > > Below is how the change ,
> > > TOOLCHAIN_TARGET_TASK += " \
> > > glib-2.0 \
> > > glib-2.0-dev \
> > > dtc-staticdev \
> > > libgomp \
> > > libgomp-dev \
> > > libgomp-staticdev \
> > > libstdc++-staticdev \
> > > ${TCLIBC}-staticdev \
> > > util-linux-dev \
> > > gdb-cross-arm \
> > > "
> > >
> > >
> > > Thanks and Regards,
> > > Sarayu K S
> > > Tech Lead
> > > Zaikenn Technologies
> > >
> > > On Tue, Aug 4, 2015 at 5:21 PM, Gary Thomas  wrote:
> > >>
> > >> On 2015-08-04 03:31, Sarayu Krishna Sivanandam wrote:
> > >>>
> > >>> Hi all ,
> > >>>
> > >>> I am using the QorIQ-SDK-V1.8 SDK for the toolchain generation for
> > >>> my ARM board .  I wanted to build gdb along with the toolchain . I
> > >>> got some ideas from google to add the gdb-cross in the
> > >>> fsl-toolchain.bb  but on doing the same it
> > >>> gave me some errors when trying to build .
> > >>>
> > >>> Can you please let me know the right method to add gdb in the
> toolchain ?
> > >>>
> > >>> Below is the error i got ,
> > >>> *ERROR: gdb-cross not found in the base feeds (ls1021atwr
> > >>> cortexa7hf-vfp-neon cortexa7hf-vfp armv7ahf-vfp-neon armv7ahf-vfp
> > >>> armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all).*
> > >>
> > >>
> > >> Use gdb-cross-arm
> > >>
> > >> --
> > >> 
> > >> Gary Thomas |  Consulting for the
> > >> MLB Associates  |Embedded world
> > >> 
> > >> --
> > >> ___
> > >> yocto mailing list
> > >> yocto@yoctoproject.org
> > >> https://lists.yoctoproject.org/listinfo/yocto
> > >
> > >
> > >
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> > >
> > --
> > ___
> > 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] [meta-selinux][PATCH 1/2] linux-yocto: enable selinux support for kernel v4.1

[Philip Tricca]

Works for me too.

Philip

On 07/30/2015 04:28 AM, Shrikant Bobade wrote:
> From: Shrikant Bobade 
> 
> The default kernel is now v4.1. So we need the selinux support
> for kernel v4.1, inorder to get selinux enabled images out of box.
> 
> Signed-off-by: Shrikant Bobade 
> ---
>  recipes-kernel/linux/linux-yocto_4.1.bbappend |8 
>  1 file changed, 8 insertions(+)
>  create mode 100644 recipes-kernel/linux/linux-yocto_4.1.bbappend
> 
> diff --git a/recipes-kernel/linux/linux-yocto_4.1.bbappend 
> b/recipes-kernel/linux/linux-yocto_4.1.bbappend
> new file mode 100644
> index 000..a8c0647
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-yocto_4.1.bbappend
> @@ -0,0 +1,8 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +# Enable selinux support in the kernel if the feature is enabled
> +SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
> 'file://selinux.cfg', '', d)}"
> +
> +# For inconsistent kallsyms data bug on ARM
> +# 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/thread.html#89718
> +EXTRA_OEMAKE += "${@bb.utils.contains('TARGET_ARCH', 'arm', ' 
> KALLSYMS_EXTRA_PASS=1', '', d)}"
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH v1] libpam: use wildcard for version and cleanup

[Philip Tricca]

Shrikant,

On 07/30/2015 02:31 AM, Shrikant Bobade wrote:
> This patch provides green build for core-image-selinux
> (meta-selinux:master & poky:master) against libpam upgrade from 1.1.6 to
> 1.2.1,
> image boots fine,but I am unable to login at target. I have prepared
> build for qemuarm, does anyone else facing similar issue? please advice.

I've reproduced this issue. Build works, we can drop the DESTDIR patch
now. But login fails with the latest version.

> Observed the login issue appears even with disabled selinux support
> (selinux=0).

On a vanilla core-image-minimal with this libpam version login works
fine. The SELinux images however, even with SELinux in permissive /
disabled, login fails. I guess this means there's something wrong with
the SELinux bits in the libpam package.

Philip

> On Thu, Jul 30, 2015 at 2:55 PM, Shrikant Bobade
> mailto:bobadeshrik...@gmail.com>> wrote:
> 
> From: Shrikant Bobade  >
> 
> use wildcard for version: adopting libpam upgrade from 1.1.6 to 1.2.1,
> cleanup older recipe and remove patch sepermit-add-DESTDIR-prefix.patch
> since the changes already available with latest source.
> 
> Signed-off-by: Shrikant Bobade  >
> ---
>  .../pam/libpam/sepermit-add-DESTDIR-prefix.patch   |   31
> 
>  recipes-extended/pam/libpam_%.bbappend |3 ++
>  recipes-extended/pam/libpam_1.1.6.bbappend |   10 ---
>  3 files changed, 3 insertions(+), 41 deletions(-)
>  delete mode 100644
> recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
>  create mode 100644 recipes-extended/pam/libpam_%.bbappend
>  delete mode 100644 recipes-extended/pam/libpam_1.1.6.bbappend
> 
> diff --git
> a/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> b/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> deleted file mode 100644
> index d48d386..000
> --- a/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -Subject: [PATCH] libpam: add missing DESTDIR prefix
> -
> -The DESTDIR prefix is missing, this will cause build failures for
> -mkdir /var/run/sepermit on the host.
> -
> -| mkdir -p /var/run/sepermit
> -| mkdir: cannot create directory `/var/run/sepermit': Permission denied
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Xin Ouyang  >
> 
> - modules/pam_sepermit/Makefile.am |2 +-
> - 1 files changed, 1 insertions(+), 1 deletions(-)
> -
> -diff --git a/modules/pam_sepermit/Makefile.am
> b/modules/pam_sepermit/Makefile.am
> -index cfc5594..bc82275 100644
>  a/modules/pam_sepermit/Makefile.am
> -+++ b/modules/pam_sepermit/Makefile.am
> -@@ -35,7 +35,7 @@ if HAVE_LIBSELINUX
> -   securelib_LTLIBRARIES = pam_sepermit.la 
> -
> - install-data-local:
> --  mkdir -p $(sepermitlockdir)
> -+  mkdir -p $(DESTDIR)$(sepermitlockdir)
> - endif
> - if ENABLE_REGENERATE_MAN
> - noinst_DATA = README pam_sepermit.8 sepermit.conf.5
> ---
> -1.7.5.4
> -
> diff --git a/recipes-extended/pam/libpam_%.bbappend
> b/recipes-extended/pam/libpam_%.bbappend
> new file mode 100644
> index 000..adcf938
> --- /dev/null
> +++ b/recipes-extended/pam/libpam_%.bbappend
> @@ -0,0 +1,3 @@
> +inherit enable-selinux
> +
> +RDEPENDS_${PN}-runtime += "${@target_selinux(d, 'pam-plugin-selinux')}"
> diff --git a/recipes-extended/pam/libpam_1.1.6.bbappend
> b/recipes-extended/pam/libpam_1.1.6.bbappend
> deleted file mode 100644
> index 71acecc..000
> --- a/recipes-extended/pam/libpam_1.1.6.bbappend
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -FILESPATH_append := ":${@base_set_filespath(['${THISDIR}/${PN}'], d)}"
> -
> -SRC_URI += "file://sepermit-add-DESTDIR-prefix.patch"
> -
> -PR .= ".4"
> -
> -inherit enable-selinux
> -
> -RDEPENDS_${PN}-runtime += "${@target_selinux(d, 'pam-plugin-selinux')}"
> --
> 1.7.9.5
> 
> 
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Compile with ADT and recipe fails builds on target.

[Edward Vidal]

Hello All,

Trying to use ADT to compile a package.  The package compiles and installs on 
the target core-image-sato for the Raspberry Pi 2 B.  Also trying to create a 
recipe. see 
recipe_gtkwave/gtkwave/gtkwave_3.6.66.bb at 
https://github.com/develone/raspberrypi2_yocto.git
The recipe downloads the source code, unpacks and runs do_configure, but fails 
at
 ERROR: Function failed: do_qa_configure.

1.) "cd wkg/yocto/RaspberryPi2/poky/"

2.) ". oe-init-build-env"

3.) "bitbale core-image-sato -c populate_sdk"

4.) "sudo 
tmp/deploy/sdk/poky-glibc-x86_64-core-image-sato-cortexa7hf-vfp-vfpv4-neon-toolchain-1.8+snapshot.sh"

5.) "cd ~/"

6.) "tar xfz wkg/yocto/downloads/gtkwave-3.3.66.tar.gz"

7.) "cd gtkwave-3.3.66/"

8.) "source 
/opt/poky/1.8+snapshot/environment-setup-cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi"

9.a) "./configure ${CONFIGURE_FLAGS}"
checking for Tcl configuration... configure: error: Can't find Tcl 
configuration definitions. Use --with-tcl to specify a directory containing 
tclConfig.sh

Should the ADT be able to find theses since they are located at
ls 
/opt/poky/1.8+snapshot/sysroots/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/usr/lib/tclConfig.sh
ls 
/opt/poky/1.8+snapshot/sysroots/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/usr/lib/tkConfig.sh
without have to set the path

9.b) "./configure ${CONFIGURE_FLAGS} 
--with-tcl=/home/vidal/wkg/yocto/RaspberryPi2/poky/build/tmp/sysroots/raspberrypi2/usr/lib
 
--with-tk=/home/vidal/wkg/yocto/RaspberryPi2/poky/build/tmp/sysroots/raspberrypi2/usr/lib"

This goes further with the following warning

config.status: executing depfiles commands
configure: WARNING: unrecognized options: --with-libtool-sysroot

Thanks in advance. Edward Vidal Jr.
e-mail devel...@sbcglobal.net
915-595-1613-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH] README: minor correction

[Juro Bystricky]

Fixed references to meta-darwin.

Signed-off-by: Juro Bystricky 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 61eda1b..96995b8 100644
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-meta-darwin
+meta-mingw
 ==
 
 OpenEmbedded meta layer for mingw based SDKs
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Perl usage in recipe

[mar.krzeminski]

Hello,

In my recipe I want to call perl script that will create image.
How should I do that to be absolutely sure that perl will be used from 
yocto not from my system?
Maybe is there any example somewhere that I can check how this should be 
done?


Regards,
Marcin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Perl usage in recipe

[Khem Raj]

On Wed, Aug 5, 2015 at 10:23 AM, mar.krzeminski
 wrote:
> Hello,
>
> In my recipe I want to call perl script that will create image.
> How should I do that to be absolutely sure that perl will be used from yocto
> not from my system?
> Maybe is there any example somewhere that I can check how this should be
> done?

inherit perlnative

>
> Regards,
> Marcin
> --
> ___
> 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] Compile with ADT and recipe fails builds on target.

[Khem Raj]

On Wed, Aug 5, 2015 at 9:40 AM, Edward Vidal  wrote:
> Hello All,
>
> Trying to use ADT to compile a package.  The package compiles and installs
> on the target core-image-sato for the Raspberry Pi 2 B.  Also trying to
> create a recipe. see
> recipe_gtkwave/gtkwave/gtkwave_3.6.66.bb at
> https://github.com/develone/raspberrypi2_yocto.git
> The recipe downloads the source code, unpacks and runs do_configure, but
> fails at
>  ERROR: Function failed: do_qa_configure.
>
> 1.) "cd wkg/yocto/RaspberryPi2/poky/"
>
> 2.) ". oe-init-build-env"
>
> 3.) "bitbale core-image-sato -c populate_sdk"
>
> 4.) "sudo
> tmp/deploy/sdk/poky-glibc-x86_64-core-image-sato-cortexa7hf-vfp-vfpv4-neon-toolchain-1.8+snapshot.sh"
>
> 5.) "cd ~/"
>
> 6.) "tar xfz wkg/yocto/downloads/gtkwave-3.3.66.tar.gz"
>
> 7.) "cd gtkwave-3.3.66/"
>
> 8.) "source
> /opt/poky/1.8+snapshot/environment-setup-cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi"
>
> 9.a) "./configure ${CONFIGURE_FLAGS}"
> checking for Tcl configuration... configure: error: Can't find Tcl
> configuration definitions. Use --with-tcl to specify a directory containing
> tclConfig.sh
>
> Should the ADT be able to find theses since they are located at
> ls
> /opt/poky/1.8+snapshot/sysroots/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/usr/lib/tclConfig.sh
> ls
> /opt/poky/1.8+snapshot/sysroots/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/usr/lib/tkConfig.sh
> without have to set the path

you need to find out how TCL is used here. If its used during build or
is it required during runtime as well.
its not different when you do native compile but OE is all about cross
compiling where it will matter.
If its only needed during build then you will depend on tcl-native in
recipe. If its also needed during runtime you will add tcl
to DEPENDS as well. You will also need to add nativesdk-tcl and any
other dependencies when creating SDK


>
> 9.b) "./configure ${CONFIGURE_FLAGS}
> --with-tcl=/home/vidal/wkg/yocto/RaspberryPi2/poky/build/tmp/sysroots/raspberrypi2/usr/lib
> --with-tk=/home/vidal/wkg/yocto/RaspberryPi2/poky/build/tmp/sysroots/raspberrypi2/usr/lib"
>
> This goes further with the following warning
>
> config.status: executing depfiles commands
> configure: WARNING: unrecognized options: --with-libtool-sysroot
>
> Thanks in advance.
>
> Edward Vidal Jr.
> e-mail devel...@sbcglobal.net
> 915-595-1613
>
> --
> ___
> 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] Perl usage in recipe

[mar.krzeminski]

W dniu 05.08.2015 o 20:08, Khem Raj pisze:

On Wed, Aug 5, 2015 at 10:23 AM, mar.krzeminski
 wrote:

Hello,

In my recipe I want to call perl script that will create image.
How should I do that to be absolutely sure that perl will be used from yocto
not from my system?
Maybe is there any example somewhere that I can check how this should be
done?

inherit perlnative

Ok, thanks. And one more question.
How about scrip call after this inherit?
Can I use simple perl MY_SCRIPT or should I consider to use something 
like this (from perf recipe)


inherit perlnative
# Env var which tells perl if it should use host (no) or target (yes) settings
export PERLCONFIGTARGET = "${@is_target(d)}"
export PERL_INC = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}/CORE"
export PERL_LIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}"
export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}"

Regards,
Marcin

Regards,
Marcin
--
___
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] [meta-oracle-java] oracle-jse-jre fetch issue

[Mario Domenech Goulart]

Hi John,

On Fri, 31 Jul 2015 14:34:24 -0400 John Davis  
wrote:

> fwiw, I am trying to fix it like so:
>
> diff --git
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> index bfa8011..13918d8 100644
> ---
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> +++
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> @@ -1,9 +1,16 @@
> -PV_UPDATE = "60"
> -BUILD_NUMBER = "19"
> +#PV_UPDATE = "60"
> +#BUILD_NUMBER = "19"
> +PV_UPDATE = "75"
> +BUILD_NUMBER = "13"
> require oracle-jse-ejre.inc
> -SRC_URI = "http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b$
> {BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> +#SRC_URI = "http://download.oracle.com/otn/java/ejre/7u$
> {PV_UPDATE}-b${BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> +SRC_URI = "http://download.oracle.com/otn/java/jdk/7u${PV_UPDATE}-b$
> {BUILD_NUMBER}/jdk-7u${PV_UPDATE}-linux-arm-vfp-hflt.tar.gz"
> +
> +#SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> +#SRC_URI[sha256sum] =
> "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
> +
> +SRC_URI[md5sum] = "6958e36bdcc842121510fecf702dcf47"
> +SRC_URI[sha256sum] =
> "29c53bac198ca3faf5ed370025a2a5564d43e05b92d91b6b5d2a8a503de10c01"
> -SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> davis@yoshi:~/progs/meta-oracle-java/recipes-devtools/oracle-java$ git
> diff
> diff --git
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> index bfa8011..13918d8 100644
> ---
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> +++
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> @@ -1,9 +1,16 @@
> -PV_UPDATE = "60"
> -BUILD_NUMBER = "19"
> +#PV_UPDATE = "60"
> +#BUILD_NUMBER = "19"
> +PV_UPDATE = "75"
> +BUILD_NUMBER = "13"
> require oracle-jse-ejre.inc
> -SRC_URI = "http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b$
> {BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> +#SRC_URI = "http://download.oracle.com/otn/java/ejre/7u$
> {PV_UPDATE}-b${BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> +SRC_URI = "http://download.oracle.com/otn/java/jdk/7u${PV_UPDATE}-b$
> {BUILD_NUMBER}/jdk-7u${PV_UPDATE}-linux-arm-vfp-hflt.tar.gz"
> +
> +#SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> +#SRC_URI[sha256sum] =
> "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
> +
> +SRC_URI[md5sum] = "6958e36bdcc842121510fecf702dcf47"
> +SRC_URI[sha256sum] =
> "29c53bac198ca3faf5ed370025a2a5564d43e05b92d91b6b5d2a8a503de10c01"
> -SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> -SRC_URI[sha256sum] =
> "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
> diff --git a/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> b/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> index 9a1fdfe..4dc2fe9 100644
> --- a/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> +++ b/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> @@ -8,10 +8,16 @@ DESCRIPTION = "This is the proprietary JRE from
> Sun/Oracle, with the Hotspot JVM
> The JRE (Java Runtime Environment) is needed on a system to run Java\
> applications and applets"
> -JDK_JRE = "ejre"
> +#JDK_JRE = "ejre"
> +JDK_JRE = "jdk"
> require oracle-jse.inc
> LIC_FILES_CHKSUM = "\
> - file://${WORKDIR}/${JDK_JRE}${PV}_$
> {PV_UPDATE}/COPYRIGHT;md5=be9fe5d47a7dcfb78f142f487afb34bb \
> + file://${WORKDIR}/${JDK_JRE}${PV}_$
> {PV_UPDATE}/COPYRIGHT;md5=0b204bd2921accd6ef4a02f9c0001823 \
> file://${WORKDIR}/${JDK_JRE}${PV}_$
> {PV_UPDATE}/THIRDPARTYLICENSEREADME.txt;md5=f3a388961d24b8b72d412a079a878cdb
> \
> "
> +
> +#LIC_FILES_CHKSUM = "\
> +# file://${WORKDIR}/${JDK_JRE}${PV}_$
> {PV_UPDATE}/COPYRIGHT;md5=be9fe5d47a7dcfb78f142f487afb34bb \
> +# file://${WORKDIR}/${JDK_JRE}${PV}_$
> {PV_UPDATE}/THIRDPARTYLICENSEREADME.txt;md5=29c53bac198ca3faf5ed370025a2a5564d43e05b92d91b6b5d2a8a503de10c01
> \
> +# "

Thanks for sharing your changes.  Would you mind sending a proper git
patch?  I'm having a hard time applying your diff.  I suppose some lines
got broken by the e-mail editor.

Best wishes.
Mario
-- 
http://www.ossystems.com.br
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-oracle-java] oracle-jse-jre fetch issue

[John Davis]

I'm at a different client site now, but tomorrow I will be working on the
yocto stuff.  I can send it to your tomorrow.

FWIW, each line in that email has a line which was changed preceded by the
original line starting with a comment #.

Even then, I found you need to manually log in to the oracle website to
manually download the jar file and place it in the download folders.

So, the result is that the script thinks it has a link for downloading a
file, however since the file has been downloaded manually using the web
browser it skips the download and simply starts the CRC verification.  Once
the script determines that the CRC matches the downloaded file it proceeds
to the next steps in the build process.

--
John F. Davis
cell: 919 888 8358

On Wed, Aug 5, 2015 at 3:47 PM, Mario Domenech Goulart <
ma...@ossystems.com.br> wrote:

> Hi John,
>
> On Fri, 31 Jul 2015 14:34:24 -0400 John Davis <
> jfda...@anuvainnovations.com> wrote:
>
> > fwiw, I am trying to fix it like so:
> >
> > diff --git
> >
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> > index bfa8011..13918d8 100644
> > ---
> >
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> > +++
> >
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> > @@ -1,9 +1,16 @@
> > -PV_UPDATE = "60"
> > -BUILD_NUMBER = "19"
> > +#PV_UPDATE = "60"
> > +#BUILD_NUMBER = "19"
> > +PV_UPDATE = "75"
> > +BUILD_NUMBER = "13"
> > require oracle-jse-ejre.inc
> > -SRC_URI = "http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b$
> > {BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> > +#SRC_URI = "http://download.oracle.com/otn/java/ejre/7u$
> > {PV_UPDATE}-b${BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> > +SRC_URI = "http://download.oracle.com/otn/java/jdk/7u${PV_UPDATE}-b$
> > {BUILD_NUMBER}/jdk-7u${PV_UPDATE}-linux-arm-vfp-hflt.tar.gz"
> > +
> > +#SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> > +#SRC_URI[sha256sum] =
> > "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
> > +
> > +SRC_URI[md5sum] = "6958e36bdcc842121510fecf702dcf47"
> > +SRC_URI[sha256sum] =
> > "29c53bac198ca3faf5ed370025a2a5564d43e05b92d91b6b5d2a8a503de10c01"
> > -SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> > davis@yoshi:~/progs/meta-oracle-java/recipes-devtools/oracle-java$ git
> > diff
> > diff --git
> >
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> > index bfa8011..13918d8 100644
> > ---
> >
> a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> > +++
> >
> b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> > @@ -1,9 +1,16 @@
> > -PV_UPDATE = "60"
> > -BUILD_NUMBER = "19"
> > +#PV_UPDATE = "60"
> > +#BUILD_NUMBER = "19"
> > +PV_UPDATE = "75"
> > +BUILD_NUMBER = "13"
> > require oracle-jse-ejre.inc
> > -SRC_URI = "http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b$
> > {BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> > +#SRC_URI = "http://download.oracle.com/otn/java/ejre/7u$
> > {PV_UPDATE}-b${BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> > +SRC_URI = "http://download.oracle.com/otn/java/jdk/7u${PV_UPDATE}-b$
> > {BUILD_NUMBER}/jdk-7u${PV_UPDATE}-linux-arm-vfp-hflt.tar.gz"
> > +
> > +#SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> > +#SRC_URI[sha256sum] =
> > "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
> > +
> > +SRC_URI[md5sum] = "6958e36bdcc842121510fecf702dcf47"
> > +SRC_URI[sha256sum] =
> > "29c53bac198ca3faf5ed370025a2a5564d43e05b92d91b6b5d2a8a503de10c01"
> > -SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> > -SRC_URI[sha256sum] =
> > "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
> > diff --git a/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> > b/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> > index 9a1fdfe..4dc2fe9 100644
> > --- a/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> > +++ b/recipes-devtools/oracle-java/oracle-jse-ejre.inc
> > @@ -8,10 +8,16 @@ DESCRIPTION = "This is the proprietary JRE from
> > Sun/Oracle, with the Hotspot JVM
> > The JRE (Java Runtime Environment) is needed on a system to run Java\
> > applications and applets"
> > -JDK_JRE = "ejre"
> > +#JDK_JRE = "ejre"
> > +JDK_JRE = "jdk"
> > require oracle-jse.inc
> > LIC_FILES_CHKSUM = "\
> > - file://${WORKDIR}/${JDK_JRE}${PV}_$
> > {PV_UPDATE}/COPYRIGHT;md5=be9fe5d47a7dcfb78f142f487afb34bb \
> > + file://${WORKDIR}/${JDK_JRE}${PV}_$
> > {PV_UPDATE}/COPYRIGHT;md5=0b204bd292

Re: [yocto] [meta-oracle-java] oracle-jse-jre fetch issue

[Daniel.]

Downloading JDK/JRE automagically is aways a pain in the a**.
Everytime that Oracle changes something on its website these scripts
crash. A solution I get to my life is aways downloading JDK/JRE
manually and puting in right place. As a "friendly but not so much"
solution I did this in one of my recipes:


--- recipe file ---
...
DL_FILE = 
"ejre-7u${PV_UPDATE}-fcs-b${BUILD_NUMBER}-linux-arm-vfp-hflt-client_headful-07_may_2014.tar.gz"
...
do_fetch() {
if ! test -f "${DL_DIR}/${DL_FILE}"; then
echo "Please accept the License Agreement, download the
${DL_FILE} and put it on ${DL_DIR}"
echo "The download link can be found at
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/javase-embedded-downloads-2209751.html";
return 1
else
return 0
fi
}

--- end recipe file ---

If the file is not found the recipes aborts with error and user see
this mesage with the link to where he should go do donwload file, and
where to put it. It's not a "state-of-art" but it works and
prevents-me from working arround Oracle's changes. Gentoo (at least
when I used it) do just like this to install Oracle's Java.

Best regards,
- dhs

2015-08-05 17:02 GMT-03:00 John Davis :
> I'm at a different client site now, but tomorrow I will be working on the
> yocto stuff.  I can send it to your tomorrow.
>
> FWIW, each line in that email has a line which was changed preceded by the
> original line starting with a comment #.
>
> Even then, I found you need to manually log in to the oracle website to
> manually download the jar file and place it in the download folders.
>
> So, the result is that the script thinks it has a link for downloading a
> file, however since the file has been downloaded manually using the web
> browser it skips the download and simply starts the CRC verification.  Once
> the script determines that the CRC matches the downloaded file it proceeds
> to the next steps in the build process.
>
> --
> John F. Davis
> cell: 919 888 8358
>
> On Wed, Aug 5, 2015 at 3:47 PM, Mario Domenech Goulart
>  wrote:
>>
>> Hi John,
>>
>> On Fri, 31 Jul 2015 14:34:24 -0400 John Davis
>>  wrote:
>>
>> > fwiw, I am trying to fix it like so:
>> >
>> > diff --git
>> >
>> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> >
>> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> > index bfa8011..13918d8 100644
>> > ---
>> >
>> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> > +++
>> >
>> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> > @@ -1,9 +1,16 @@
>> > -PV_UPDATE = "60"
>> > -BUILD_NUMBER = "19"
>> > +#PV_UPDATE = "60"
>> > +#BUILD_NUMBER = "19"
>> > +PV_UPDATE = "75"
>> > +BUILD_NUMBER = "13"
>> > require oracle-jse-ejre.inc
>> > -SRC_URI = "http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b$
>> > {BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
>> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
>> > +#SRC_URI = "http://download.oracle.com/otn/java/ejre/7u$
>> > {PV_UPDATE}-b${BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
>> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
>> > +SRC_URI = "http://download.oracle.com/otn/java/jdk/7u${PV_UPDATE}-b$
>> > {BUILD_NUMBER}/jdk-7u${PV_UPDATE}-linux-arm-vfp-hflt.tar.gz"
>> > +
>> > +#SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
>> > +#SRC_URI[sha256sum] =
>> > "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
>> > +
>> > +SRC_URI[md5sum] = "6958e36bdcc842121510fecf702dcf47"
>> > +SRC_URI[sha256sum] =
>> > "29c53bac198ca3faf5ed370025a2a5564d43e05b92d91b6b5d2a8a503de10c01"
>> > -SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
>> > davis@yoshi:~/progs/meta-oracle-java/recipes-devtools/oracle-java$ git
>> > diff
>> > diff --git
>> >
>> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> >
>> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> > index bfa8011..13918d8 100644
>> > ---
>> >
>> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> > +++
>> >
>> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
>> > @@ -1,9 +1,16 @@
>> > -PV_UPDATE = "60"
>> > -BUILD_NUMBER = "19"
>> > +#PV_UPDATE = "60"
>> > +#BUILD_NUMBER = "19"
>> > +PV_UPDATE = "75"
>> > +BUILD_NUMBER = "13"
>> > require oracle-jse-ejre.inc
>> > -SRC_URI = "http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b$
>> > {BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
>> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
>> > +#SRC_URI = "http://download.oracle.com/otn/java/ejre/7u$
>> > {PV_UPDATE}-b${BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
>> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
>> > +SRC_URI = "http://download.oracle.com/otn/java/jdk/7u${PV_UPDATE}-b$
>> > {BUIL

Re: [yocto] [meta-raspberrypi][PATCH 0/5] Add support for 4.1 kernel with vc4 DRM/KMS driver

[Petter Mabäcker]

 

2015-08-04 18:07 skrev Javier Martinez Canillas: 

> Hello Petter,
>

> Thanks a lot for your feedback.
> 
> On 08/04/2015 11:16 AM, Petter
Mabäcker wrote:
> 
>> On 07/30/2015 10:34 AM, Javier Martinez Canillas
wrote: 
>> 
>>> Hello Andrei, This series adds support for Eric Anholt's
v4.1 kernel, that has support for the vc4 DRM/KMS driver. Which is the
new open source graphics driver stack for the Raspberry Pi to be used
instead of the userland driver. We are using it in the Tizen port to
RPI2 [0] and are trying to push all the patches back to the tizen-distro
and meta-raspberrypi OE layers so I'm posting these patches to get your
feedback. The v4.1 kernel is under heavy development so is a
work-in-progress and should not be used in production. That's why a
default preference of -1 is set and the kernel only is enabled if the
"vc4-gfx" feature is added to the DISTRO_FEATURES variable. But even
when it's still a development kernel, having the recipe in the
meta-raspberrypi will allow people to test it. The patches are for:
Patch 1/5 makes optional to add the kgdboc kernel command line parameter
Patch 2/5 allows to set the mask_gpu_interrupt0 option in config.txt
Patch 3/5 changes the partition layout to add more space for boot files
Patch 4/5 adds a recipe for the 4.1 and some patches to make it stable
Patch 5/5 switchs the default providers according to the gfx stack used
One problem I found is that the latest RPI kernels changed the path for
the DT overlays after commit 739c586c8757 ("BCM270X_DT: Move the
overlays into a subdirectory, adding the README") [1] so the kernel
fails to build with the default KERNEL_DEVICETREE. I tried to change
get_dts() function logic to take this into account but found that it
would had been a more intrusive change and KERNEL_DEVICETREE will have
to be changed anyways once the recipes for the other kernels are updated
to the latest HEAD so for now I just define the following on local.conf
to make it build:
>> As long as we bump SRCREV for 3.18 kernel as well,
I see no problem. Since then the KERNEL_DEVICETREE default value can
look the same in all situations (both 3.18 and 4.x can handle the new
structure and we get no compatibility issues) and for older kernels
(3.12 and 3.14) it doesn't matter since they don't have native device
tree support and will turn device tree support off by default.
> 
> Yes,
that's what I meant when I said that the problem will be solved once
>
all the recipes for DT enabled kernels are updated to the latest
branch
> HEAD. But I didn't want to do that in this series since I
wanted the
> changes to be as less intrusive as possible.

Ok, sounds
reasonable. Alex found some problems when bumping 3.18 to latest but
when that is solved he can push the 3.18 bumping and prepare the
KERNEL_DEVICETREE variable with the new subdir for overlays. 

>>
KERNEL_DEVICETREE = " bcm2708-rpi-b.dtb bcm2708-rpi-b-plus.dtb
bcm2709-rpi-2-b.dtb overlays/hifiberry-amp-overlay.dtb
overlays/hifiberry-dac-overlay.dtb
overlays/hifiberry-dacplus-overlay.dtb
overlays/hifiberry-digi-overlay.dtb overlays/iqaudio-dac-overlay.dtb
overlays/iqaudio-dacplus-overlay.dtb overlays/lirc-rpi-overlay.dtb
overlays/pps-gpio-overlay.dtb overlays/w1-gpio-overlay.dtb
overlays/w1-gpio-pullup-overlay.dtb " [0]:
http://blogs.s-osg.org/tizen-rpi2-now-supporting-3d-acceleration/ [1]
[1]: https://github.com/raspberrypi/linux/commit/739c586c8757 [2] Best
regards, --- Javier Martinez Canillas Open Source Group Samsung Research
America Derek Foreman (4): rpi-config: Allow to mask GPU irqs
sdcard_image-rpi.bbclass: Allocate more space for boot partition
linux-raspberrypi: Add a 4.1 linux kernel with vc4 support
rpi-default-providers: Switch providers according to used gfx stack
Mauro Carvalho Chehab (1): linux-raspberrypi.inc: Make kgdboc kernel
param optional README | 38 +-- classes/sdcard_image-rpi.bbclass | 6
+- conf/machine/include/rpi-default-providers.inc | 8 +-
conf/machine/include/rpi-default-versions.inc | 2 +-
recipes-bsp/bootfiles/rpi-config_git.bb | 6 ++
recipes-kernel/linux/linux-raspberrypi.inc | 5 +-
..._defconfig-Enable-config-options-for-vc4-.patch | 48 +
...-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch | 85 +++
.../0003-drm-vc4-Use-the-fbdev_cma-helpers.patch | 115
+ .../0004-drm-vc4-Allow-vblank-to-be-disabled.patch
| 26 + .../0005-drm-vc4-Disable-KMS-operations.patch | 95
+ recipes-kernel/linux/linux-raspberrypi_4.1.bb | 16 +++
12 files changed, 433 insertions(+), 17 deletions(-) create mode 100644
recipes-kernel/linux/linux-raspberrypi/0001-ARM-bcm2709_defconfig-Enable-config-options-for-vc4-.patch
create mode 100644
recipes-kernel/linux/linux-raspberrypi/0002-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch
create mode 100644
recipes-kernel/linux/linux-raspberrypi/0003-drm-vc4-Use-the-fbdev_cma-helpers.patch
create mode 100644
recipes-kernel/linux/linux-raspberrypi/0004-drm-vc4-Allow-vblank-to-be-disabled.patch
create 

[yocto] building an SDK for MacOSX

[Trevor Woerner]

Hi,

I came across RP's meta-darwin today that I'm hoping will enable me to
build an OpenEmbedded SDK that can be used by my colleagues who work in
a MacOSX environment?

Is my understanding correct?

Has anyone tried this lately? The last commit was from almost exactly a
year ago.

The description in the README is a bit vague. I've never used a MacOSX
system so I'm not entirely sure of the filesystem layout. What exactly
is needed to create the OSX-sdk.zip file?
/usr/include
/usr/lib
/lib

Is that all?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 0/6] mingw patches to build meta-toolchain

[Juro Bystricky]

Several recipes have been updated, so the corresponding .bbappend files became 
stale.
The attached patches correspond to various updated recipes.

I tested the patches with meta-mingw layer and:

SDKMACHINE="i686-mingw32"
bitbake meta-toolchain


Juro Bystricky (6):
  binutils-cross-canadian: upgrade to version 2.25
  gdb-cross-canadian_7.8.1: updated to gdb-cross-canadian_7.9.1
  nativesdk-libtool_2.4.2: updated nativesdk-libtool_2.4.6
  libmpc_1.0.2: updated to libmpc_1.0.3
  mpfr_3.1.2: updated to mpfr_3.1.3
  gettext_0.19.4.bbappend: support for mingw

 recipes-core/gettext/gettext_0.19.4.bbappend| 2 ++
 recipes-devtools/binutils/binutils-cross-canadian_2.24.bbappend | 5 -
 recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend | 5 +
 recipes-devtools/gdb/gdb-cross-canadian_7.8.1.bbappend  | 5 -
 recipes-devtools/gdb/gdb-cross-canadian_7.9.1.bbappend  | 5 +
 recipes-devtools/libtool/nativesdk-libtool_2.4.2.bbappend   | 1 -
 recipes-devtools/libtool/nativesdk-libtool_2.4.6.bbappend   | 1 +
 recipes-support/libmpc/libmpc_1.0.3.bbappend| 1 +
 recipes-support/mpc/libmpc_1.0.2.bbappend   | 1 -
 recipes-support/mpfr/mpfr_3.1.2.bbappend| 1 -
 recipes-support/mpfr/mpfr_3.1.3.bbappend| 1 +
 11 files changed, 15 insertions(+), 13 deletions(-)
 create mode 100644 recipes-core/gettext/gettext_0.19.4.bbappend
 delete mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.24.bbappend
 create mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend
 delete mode 100644 recipes-devtools/gdb/gdb-cross-canadian_7.8.1.bbappend
 create mode 100644 recipes-devtools/gdb/gdb-cross-canadian_7.9.1.bbappend
 delete mode 100644 recipes-devtools/libtool/nativesdk-libtool_2.4.2.bbappend
 create mode 100644 recipes-devtools/libtool/nativesdk-libtool_2.4.6.bbappend
 create mode 100644 recipes-support/libmpc/libmpc_1.0.3.bbappend
 delete mode 100644 recipes-support/mpc/libmpc_1.0.2.bbappend
 delete mode 100644 recipes-support/mpfr/mpfr_3.1.2.bbappend
 create mode 100644 recipes-support/mpfr/mpfr_3.1.3.bbappend

-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 1/6] binutils-cross-canadian: upgrade to version 2.25

[Juro Bystricky]

Renamed the file binutils-cross-canadian_2.24.bbappend to
binutils-cross-canadian_2.25.bbappend.

Signed-off-by: Juro Bystricky 
---
 recipes-devtools/binutils/binutils-cross-canadian_2.24.bbappend | 5 -
 recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)
 delete mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.24.bbappend
 create mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend

diff --git a/recipes-devtools/binutils/binutils-cross-canadian_2.24.bbappend 
b/recipes-devtools/binutils/binutils-cross-canadian_2.24.bbappend
deleted file mode 100644
index 026c932..000
--- a/recipes-devtools/binutils/binutils-cross-canadian_2.24.bbappend
+++ /dev/null
@@ -1,5 +0,0 @@
-EXTRA_OECONF_append_sdkmingw32 = " --disable-plugins --disable-nls"
-LDFLAGS_append_sdkmingw32 = " -Wl,-static"
-
-DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
-DEPENDS_remove_sdkmingw32 = "nativesdk-flex"
diff --git a/recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend 
b/recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend
new file mode 100644
index 000..026c932
--- /dev/null
+++ b/recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend
@@ -0,0 +1,5 @@
+EXTRA_OECONF_append_sdkmingw32 = " --disable-plugins --disable-nls"
+LDFLAGS_append_sdkmingw32 = " -Wl,-static"
+
+DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
+DEPENDS_remove_sdkmingw32 = "nativesdk-flex"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 4/6] libmpc_1.0.2: updated to libmpc_1.0.3

[Juro Bystricky]

Renamed recipes-support/mpc/libmpc_1.0.2.bbappend to
recipes-support/libmpc/libmpc_1.0.3.bbappend to reflect the changed
location and version of the recipe libmpc_1.0.3.bb.

Signed-off-by: Juro Bystricky 
---
 recipes-support/libmpc/libmpc_1.0.3.bbappend | 1 +
 recipes-support/mpc/libmpc_1.0.2.bbappend| 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 recipes-support/libmpc/libmpc_1.0.3.bbappend
 delete mode 100644 recipes-support/mpc/libmpc_1.0.2.bbappend

diff --git a/recipes-support/libmpc/libmpc_1.0.3.bbappend 
b/recipes-support/libmpc/libmpc_1.0.3.bbappend
new file mode 100644
index 000..0d289df
--- /dev/null
+++ b/recipes-support/libmpc/libmpc_1.0.3.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF_append_mingw32 = "--enable-static --disable-shared"
\ No newline at end of file
diff --git a/recipes-support/mpc/libmpc_1.0.2.bbappend 
b/recipes-support/mpc/libmpc_1.0.2.bbappend
deleted file mode 100644
index 0d289df..000
--- a/recipes-support/mpc/libmpc_1.0.2.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-EXTRA_OECONF_append_mingw32 = "--enable-static --disable-shared"
\ No newline at end of file
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 3/6] nativesdk-libtool_2.4.2: updated nativesdk-libtool_2.4.6

[Juro Bystricky]

Renamed nativesdk-libtool_2.4.2.bbappend to nativesdk-libtool_2.4.6.bbappend
in order to match the new recipe nativesdk-libtool_2.4.6.bb.

Signed-off-by: Juro Bystricky 
---
 recipes-devtools/libtool/nativesdk-libtool_2.4.2.bbappend | 1 -
 recipes-devtools/libtool/nativesdk-libtool_2.4.6.bbappend | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)
 delete mode 100644 recipes-devtools/libtool/nativesdk-libtool_2.4.2.bbappend
 create mode 100644 recipes-devtools/libtool/nativesdk-libtool_2.4.6.bbappend

diff --git a/recipes-devtools/libtool/nativesdk-libtool_2.4.2.bbappend 
b/recipes-devtools/libtool/nativesdk-libtool_2.4.2.bbappend
deleted file mode 100644
index 4252e8d..000
--- a/recipes-devtools/libtool/nativesdk-libtool_2.4.2.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-EXTRA_OECONF_append_mingw32 = " --disable-shared"
\ No newline at end of file
diff --git a/recipes-devtools/libtool/nativesdk-libtool_2.4.6.bbappend 
b/recipes-devtools/libtool/nativesdk-libtool_2.4.6.bbappend
new file mode 100644
index 000..4252e8d
--- /dev/null
+++ b/recipes-devtools/libtool/nativesdk-libtool_2.4.6.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF_append_mingw32 = " --disable-shared"
\ No newline at end of file
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 2/6] gdb-cross-canadian_7.8.1: updated to gdb-cross-canadian_7.9.1

[Juro Bystricky]

Renamed gdb-cross-canadian_7.8.1.bbappend to gdb-cross-canadian_7.9.1.bbappend,
to match the updated recipe  gdb-cross-canadian_7.9.1.bb.

Signed-off-by: Juro Bystricky 
---
 recipes-devtools/gdb/gdb-cross-canadian_7.8.1.bbappend | 5 -
 recipes-devtools/gdb/gdb-cross-canadian_7.9.1.bbappend | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)
 delete mode 100644 recipes-devtools/gdb/gdb-cross-canadian_7.8.1.bbappend
 create mode 100644 recipes-devtools/gdb/gdb-cross-canadian_7.9.1.bbappend

diff --git a/recipes-devtools/gdb/gdb-cross-canadian_7.8.1.bbappend 
b/recipes-devtools/gdb/gdb-cross-canadian_7.8.1.bbappend
deleted file mode 100644
index bf4bd75..000
--- a/recipes-devtools/gdb/gdb-cross-canadian_7.8.1.bbappend
+++ /dev/null
@@ -1,5 +0,0 @@
-LDFLAGS_append_sdkmingw32 = " -Wl,-static"
-EXEEXT_sdkmingw32 = ".exe"
-DEPENDS_remove_sdkmingw32 = "nativesdk-ncurses nativesdk-readline 
nativesdk-python"
-RDEPENDS_${PN}_remove_sdkmingw32 = "nativesdk-python-core 
nativesdk-python-lang nativesdk-python-re nativesdk-python-codecs 
nativesdk-python-netclient"
-EXTRA_OECONF_append_sdkmingw32 = "--without-curses --without-system-readline 
--with-python=no"
diff --git a/recipes-devtools/gdb/gdb-cross-canadian_7.9.1.bbappend 
b/recipes-devtools/gdb/gdb-cross-canadian_7.9.1.bbappend
new file mode 100644
index 000..bf4bd75
--- /dev/null
+++ b/recipes-devtools/gdb/gdb-cross-canadian_7.9.1.bbappend
@@ -0,0 +1,5 @@
+LDFLAGS_append_sdkmingw32 = " -Wl,-static"
+EXEEXT_sdkmingw32 = ".exe"
+DEPENDS_remove_sdkmingw32 = "nativesdk-ncurses nativesdk-readline 
nativesdk-python"
+RDEPENDS_${PN}_remove_sdkmingw32 = "nativesdk-python-core 
nativesdk-python-lang nativesdk-python-re nativesdk-python-codecs 
nativesdk-python-netclient"
+EXTRA_OECONF_append_sdkmingw32 = "--without-curses --without-system-readline 
--with-python=no"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 6/6] gettext_0.19.4.bbappend: support for mingw

[Juro Bystricky]

This patch solves various unresolved references:

 .libs/fstrcmp.o:fstrcmp.c:(.text+0x4b6): undefined reference to 
`_imp__pthread_key_create'
 .libs/fstrcmp.o:fstrcmp.c:(.text+0x5b2): undefined reference to 
`_imp__pthread_once'
 .libs/fstrcmp.o:fstrcmp.c:(.text+0x5c4): undefined reference to 
`_imp__pthread_getspecific'
 .libs/fstrcmp.o:fstrcmp.c:(.text+0x617): undefined reference to 
`_imp__pthread_setspecific'
 .libs/localename.o:localename.c:(.text+0x14f6): undefined reference to 
`_imp__pthread_mutex_lock'
 .libs/localename.o:localename.c:(.text+0x1576): undefined reference to 
`_imp__pthread_mutex_unlock'
 .libs/localename.o:localename.c:(.text+0x15c9): undefined reference to 
`_imp__pthread_mutex_unlock'
 glthread/.libs/lock.o:lock.c:(.text+0xe): undefined reference to 
`_imp__pthread_mutexattr_init'
 glthread/.libs/lock.o:lock.c:(.text+0x2d): undefined reference to 
`_imp__pthread_mutexattr_settype'
 glthread/.libs/lock.o:lock.c:(.text+0x44): undefined reference to 
`_imp__pthread_mutex_init'
 glthread/.libs/lock.o:lock.c:(.text+0x53): undefined reference to 
`_imp__pthread_mutexattr_destroy'
 glthread/.libs/lock.o:lock.c:(.text+0x62): undefined reference to 
`_imp__pthread_mutexattr_destroy'
 glthread/.libs/lock.o:lock.c:(.text+0x75): undefined reference to 
`_imp__pthread_mutexattr_dest

Signed-off-by: Juro Bystricky 
---
 recipes-core/gettext/gettext_0.19.4.bbappend | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 recipes-core/gettext/gettext_0.19.4.bbappend

diff --git a/recipes-core/gettext/gettext_0.19.4.bbappend 
b/recipes-core/gettext/gettext_0.19.4.bbappend
new file mode 100644
index 000..ac76feb
--- /dev/null
+++ b/recipes-core/gettext/gettext_0.19.4.bbappend
@@ -0,0 +1,2 @@
+DEPENDS_append_mingw32 = " pthreads-win32"
+LDFLAGS_prepend_mingw32 = " -lpthread "
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 5/6] mpfr_3.1.2: updated to mpfr_3.1.3

[Juro Bystricky]

Renamed mpfr_3.1.2.bbappend to mpfr_3.1.3.bbappend to match the new recipe
mpfr_3.1.3.bb.

Signed-off-by: Juro Bystricky 
---
 recipes-support/mpfr/mpfr_3.1.2.bbappend | 1 -
 recipes-support/mpfr/mpfr_3.1.3.bbappend | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)
 delete mode 100644 recipes-support/mpfr/mpfr_3.1.2.bbappend
 create mode 100644 recipes-support/mpfr/mpfr_3.1.3.bbappend

diff --git a/recipes-support/mpfr/mpfr_3.1.2.bbappend 
b/recipes-support/mpfr/mpfr_3.1.2.bbappend
deleted file mode 100644
index 4252e8d..000
--- a/recipes-support/mpfr/mpfr_3.1.2.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-EXTRA_OECONF_append_mingw32 = " --disable-shared"
\ No newline at end of file
diff --git a/recipes-support/mpfr/mpfr_3.1.3.bbappend 
b/recipes-support/mpfr/mpfr_3.1.3.bbappend
new file mode 100644
index 000..4252e8d
--- /dev/null
+++ b/recipes-support/mpfr/mpfr_3.1.3.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF_append_mingw32 = " --disable-shared"
\ No newline at end of file
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

[Khem Raj]

On Tue, Aug 4, 2015 at 11:34 PM, Javier Martinez Canillas
 wrote:
>> who defines the distro feature ?
>>
>>
>
> Distro features AFAICT are user defined options, you can for example have
> the following in your conf/local.conf:
>
> DISTRO_FEATURES_append = " vc4-gfx"

I wasnt trying to learn about what DISTRO_FEATURES are, I was trying
to draw attention to the fact that meta-rpi being a BSP layer
was trying to define a lot more than a BSP layer is supposed to do. So
if its a distro feature, I would like it to work as expected on other
machines besides raspberrypi. If thats not applicable then we should
rethink if it could be folded into MACHINE_FEATURES if it needs to be
a distro feature then propose it to OE-Core, at the very least
document them in README of this layer. Or separate it out into a
common layer which rpi BSPs will depend on.
but think beyond single machine when deciding on adding distro
features, there are distros based on OE which support multiple
machines
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Qt SDK Static Build

[Khem Raj]

On Tue, Aug 4, 2015 at 1:03 PM, Justin Bauer  wrote:
> Hello,
>
> I'm using Yocto 1.8 Fido and trying to build Qt SDK statically so that my Qt
> application can be deployed as a single file. I've added
>
> SDKIMAGE_FEATURES_append = " staticdev-pkgs'
>
> to my local.conf before bitbaking the qt5 toolchain with no luck in finding
> the static libraries
>
> $ bitbake meta-toolchain-qt5

well SDKIMAGE_FEATURES only work when you generate SDKs using -cpopulate_sdk
out of real images and not meta-toolchain-* targets which IMO should
no longer be used.

>
>
> I'm using an imx6 processor and bsp similar to the Wandboard. I've tried
> configuring Qt manually by downloading the Qt source files and using the
> Yocto generated SDK, but ./configure fails due to the missing patches
> required to build it. Is there something I am missing?
>
> Thanks
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] qemux86 and generic86

[Amit Kumar]

Hi,

I have a basic doubts on qemux86 build application image is not working on 
generic86 target.
Suppose I have a application which I would like to test on target board, but 
the target board is not yet ready. If I will want to test that application I 
will use the qemu  to test.
But if I build the application for qemu, it does not work for actual target 
board.
Could you please let me know the details reason. If I want to do like that what 
I should have to do.


Thanks & Regards
Amit

L&T Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to flash core-image-sato to a Nvidia Jetson TK1?

[Khem Raj]

> On Aug 3, 2015, at 11:15 AM, Dalton Fury  wrote:
> 
> Hi,
> 
> I am a hobbyist, and liked yocto very much since I used in on an old 
> Pandaboard ES. Now I got my hands on a Nvidia Jetson TK1, and want to get a 
> yocto running on it. I intend to use it for heavy image processing and I 
> prefer not to do it with the Ubuntu which comes with it loaded with GUI and 
> Unity and all. So I build the image, but could not find any information on 
> how to flash it to the eMMC on the board.
> 
> Nvidia provides scripts for doing this. The process is as follows:
> 
> 1) Download the driver package and extract it.
> 
> 2) Download the sample rootfs and extract it to `rootfs` folder in where the 
> driver package is extracted.
> 
> 3) Run the apply_binaries.sh script. Upon inspecting the script, I found that 
> it copies NVIDIA user space components, Nvidia firmware files, BSP test 
> tools, gst test applications, create a lot of symbolic links within the 
> rootfs extracted to the 'rootfs' folder. It also places the firmwares and 
> kernel modules, and also copies some configuration files for the boot 
> loader(U-Boot).
> 
> 4) Run flash.sh.
> 
> What I did is to copy the rootfs that was made with yocto, and entirely skip 
> Step 3 assuming that all the necessary software is already made with yocto as 
> a result of adding the BSP. This attempt of course, failed. Thought the 
> kernel booted, it froze halfway. No error message. Just a flack screen with a 
> while "_" on the top left corner.
> 
> This is the bsp I used: https://github.com/kraj/meta-jetson-tk1 
> 
> 
> This is the guide I used as reference: 
> http://elinux.org/Tegra/Downstream_SW/Gentoo_From_eMMC 
> 
> 
> If anyone has experience performing this(i bet you do), please help me out. 
> Thanks.

I have booted Angstrom XFCE-nm-image on it from SD card. Firstly you need to 
flash new kernel and also modify the boot loader arguments so it boots from SD 
card first.
all instructions to update the boot loader cmdline and kernel are documented

see 
https://cyclicredundancy.wordpress.com/2014/05/10/flashing-the-rootfs-on-a-nvidia-jetson-tk1/
 


you might need

sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1


> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto