[yocto] How can i install shutil.py in rootfs

2015-10-20 Thread Vivek Per 
hi,
 How can i install shutil.py in roofs.  I need this file for
audit2allow. In rootfs remaining .py files are including
/usr/share/python-support/
but not shutil.py. i want to include this file in rootfs how can i install
this?


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

Re: [yocto] How can i install shutil.py in rootfs

2015-10-20 Thread Maxin B. John 
Hi Vivek,

On Tue, Oct 20, 2015 at 02:38:36PM +0530, Vivek Per wrote:
> hi,
> How can i install shutil.py in roofs.  I need this file for audit2allow. 
> In rootfs remaining .py files are including  /usr/share/python-support/ 
> but not shutil.py. i want to include this file in rootfs how can i install 
> this?

You need to install "python-shell" in your image for shutil.py

ie: 
IMAGE_INSTALL_append = " python-shell" in local.conf and build again.

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

Re: [yocto] Nightly build and world build

2015-10-20 Thread atulkumar singh 
On 20-Oct-2015 11:49 am, "Anders Darander"  wrote:
>
> Please don't top-post. I've reformatted the e-mail in my replly.
>
> * atulkumar singh  [151020 05:22]:
>
> > On 19-Oct-2015 5:38 pm, "Martin Jansa"  wrote:
>
> > > On Sat, Oct 17, 2015 at 08:01:59AM +0530, atulkumar singh wrote:
> > > > Hi All,
>
> > > > I am going through the mailing list and I found some communication
> > related
> > > > to world build and nightly build.
> > > > I even search in the documentation regarding the same but didn't
found
> > any
> > > > useful information regarding the same.
> > > > Can anyone please tel me what is nightly build and world build and
what
> > is
> > > > the difference between the same.
>
> > > My world builds are described here:
> > > http://www.openembedded.org/wiki/Bitbake_World_Status
>
> > Thanks for your reply.
> > But the link you mentioned has a status of world build for various
> > versions, while I am looking for what world build and nightly build
meant
> > for and what is the difference between them.
>
> Did you notice the Martin not only provided you with the link above, but
> also the line below:
>
> > > See link on first line.
>
> If you look at that line, you'll find the following link:
> http://www.openembedded.org/wiki/Bitbake_World_Status_Setup, which
> basically tells you what the world status builds are doing.
Thanks Anders for your help.
The link mentioned above has another link and I got the answer for world
build and regarding nightly build then I found the same over web.

Regards,
Atul
>
> Cheers,
> Anders
>
> --
> Anders Darander
> ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How can i install shutil.py in rootfs

2015-10-20 Thread Vivek Per 
i have put "python-shell" in IMAGE_INSTALL it worked fine.

Thanks
vivek

On Tue, Oct 20, 2015 at 10:04 AM, Maxin B. John 
wrote:

> Hi Vivek,
>
> On Tue, Oct 20, 2015 at 02:38:36PM +0530, Vivek Per wrote:
> > hi,
> > How can i install shutil.py in roofs.  I need this file for audit2allow.
> > In rootfs remaining .py files are including  /usr/share/python-support/
> > but not shutil.py. i want to include this file in rootfs how can i
> install this?
>
> You need to install "python-shell" in your image for shutil.py
>
> ie:
> IMAGE_INSTALL_append = " python-shell" in local.conf and build again.
>
> Best Regards,
> Maxin
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-selinux] libselinux, libsepol: depends on coreutils-native

2015-10-20 Thread wenzong.fan 
From: Wenzong Fan 

'ln --relative' doesn't work on Ubuntu 12.04 that has ln 8.13. The
changes involved by SELinux commit:

  commit 71393a181d63c9baae5fe8dcaeb9411d1f253998
  Author: Steve Lawrence 
  Date:   Mon Oct 20 15:46:17 2014 -0400

libselinux: libsepol: use ln --relative to create .so symlinks

The current build system assumes SHLIBDIR is ../../ relative to LIBDIR.
However, this isn't always the case. For example, Arch Linux sets both
LIBDIR and SHLIBDIR to /usr/lib, which results in broken symlinks.

Instead of making that assumption, create .so symlinks using ln
--relative so that the correct relative paths are used. Note that this
adds a dependency for the build system to use coretuils-8.16 or later.

Just depends on coreutils-native to fix the issue.

Signed-off-by: Wenzong Fan 
---
 recipes-security/selinux/libselinux.inc | 2 +-
 recipes-security/selinux/libsepol.inc   | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/recipes-security/selinux/libselinux.inc 
b/recipes-security/selinux/libselinux.inc
index d571a7c..b0f7bc4 100644
--- a/recipes-security/selinux/libselinux.inc
+++ b/recipes-security/selinux/libselinux.inc
@@ -7,7 +7,7 @@ LICENSE = "PD"
 
 inherit lib_package pythonnative
 
-DEPENDS += "libsepol python libpcre swig-native"
+DEPENDS += "libsepol python libpcre swig-native coreutils-native"
 
 PACKAGES += "${PN}-python"
 FILES_${PN}-python = 
"${libdir}/python${PYTHON_BASEVERSION}/site-packages/selinux/*"
diff --git a/recipes-security/selinux/libsepol.inc 
b/recipes-security/selinux/libsepol.inc
index b24ed28..9234f24 100644
--- a/recipes-security/selinux/libsepol.inc
+++ b/recipes-security/selinux/libsepol.inc
@@ -8,6 +8,8 @@ LICENSE = "LGPLv2+"
 
 inherit lib_package
 
+DEPENDS += "coreutils-native"
+
 # Change RANLIB for cross compiling, use host-tools $(AR) rather than
 # local ranlib.
 EXTRA_OEMAKE += "RANLIB='$(AR) s'"
-- 
1.9.1

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

[yocto] multiple yocto-kernel-cache mirrors support in linux-yocto style recipe

2015-10-20 Thread Luo Zhenhua 
Hi,

I created a bbappend for linux-yocto_4.1.bb to use our own kernel source git 
url, a yocto-kernel-cache git tree is created to manage the distro specific 
kernel fragments, I want to use both Yocto yocto-kernel-cache and our own 
yocto-kernel-cache git, can this multiple yocto-kernel-cache mirrors be 
supported by linux-yocto style bb file? If no, what's the best method to handle 
such multiple kernel fragments mirrors case?


Best Regards,

Zhenhua

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

Re: [linux-yocto] CONFIG_LIBCRC32C error

2015-10-20 Thread Bruce Ashfield 

On 15-10-19 03:45 PM, Cristian Bercaru wrote:

Hello! Please help me understand why If I add this line to the linux
kernel 3.10 defconfig or config fragments

   # CONFIG_LIBCRC32C is not set

I get the error below when I try to bitbake linux-yocto.


Hmm. I've never seen this myself. Is this happening even after a
cleanall ? At a glance, it looks like the module was built and
installed, but not cleaned when you changed the fragment, and hence
not packaged into a kernel-module package .. and then the warning.

Bruce


Thank you,
Cristian Bercaru

DEBUG: Executing python function populate_packages
ERROR: QA Issue: linux-yocto: Files/directories were installed but not
shipped
   /lib/modules/3.10.65-ltsi-yocto-standard/kernel
DEBUG: Python function populate_packages finished
DEBUG: Executing python function do_package_qa
NOTE: DO PACKAGE QA
NOTE: Checking Package: kernel
NOTE: Checking Package: kernel-base
NOTE: Checking Package: kernel-vmlinux
NOTE: arm-poky-linux-gnueabi-objdump -p
/home/chris/yocto/TEST/3.10/yocto_arm_standard/tmp/work/axxiaarm-poky-linux-gnueabi/linux-yocto/3.10.65+gitAUTOINC+f90490d50f_9e57bfba80-r0/packages-split/kernel-vmlinux/boot/vmlinux-3.10.65-ltsi-yocto-standard

NOTE: Checking Package: kernel-image
NOTE: Package kernel-dev skipping QA tests: ['debug-files']
NOTE: Checking Package: kernel-dev
NOTE: Checking Package: kernel-modules
NOTE: Checking Package: kernel-devicetree
ERROR: QA run found fatal errors. Please consider fixing them.
DEBUG: Python function do_package_qa finished
DEBUG: Python function do_package finished
ERROR: Function failed: do_package_qa



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

Re: [yocto] multiple yocto-kernel-cache mirrors support in linux-yocto style recipe

2015-10-20 Thread Bruce Ashfield 

On 15-10-20 09:01 AM, Luo Zhenhua wrote:

Hi,

I created a bbappend for linux-yocto_4.1.bb to use our own kernel source
git url, a yocto-kernel-cache git tree is created to manage the distro
specific kernel fragments, I want to use both Yocto yocto-kernel-cache
and our own yocto-kernel-cache git, can this multiple yocto-kernel-cache
mirrors be supported by linux-yocto style bb file? If no, what’s the
best method to handle such multiple kernel fragments mirrors case?


Just add them into the SRC_URI, with their own name, destination and
type of kmeta (just like the yocto one).

The system will pick them up as meta data sources and allow them to
be used.

Cheers,

Bruce



Best Regards,

Zhenhua





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

[yocto] Beagle Bone Black problem with hotplug USB

2015-10-20 Thread Alireza 
Hello there,

I am using yocto core-image-minimal image for my beagle bone black, and 
everything is OK, but my USB port doesn't work at all.

Is there anyone having experience in this issue to give me some guide, please?

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

[yocto] [meta-mingw][PATCH 4/4] nativesdk-gcc: Add mingw32 named libraries to files list

2015-10-20 Thread Mark Hatle 
Also we skip the staticdev sanity check, as the '.a' file should be packaged
as listed.

Signed-off-by: Mark Hatle 
---
 recipes-devtools/gcc/gcc_%.bbappend | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 recipes-devtools/gcc/gcc_%.bbappend

diff --git a/recipes-devtools/gcc/gcc_%.bbappend 
b/recipes-devtools/gcc/gcc_%.bbappend
new file mode 100644
index 000..a779bb9
--- /dev/null
+++ b/recipes-devtools/gcc/gcc_%.bbappend
@@ -0,0 +1,6 @@
+FILES_${PN}_append_mingw32 = "\
+   ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/liblto_plugin-0.dll \
+   ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/liblto_plugin.dll.a \
+"
+
+INSANE_SKIP_append_mingw32 = " staticdev"
-- 
1.9.3

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

[yocto] [meta-mingw][PATCH 0/4] Fix meta-mingw support to work with Jethro

2015-10-20 Thread Mark Hatle 
Mark Hatle (1):
  nativesdk-gcc: Add mingw32 named libraries to files list

Peter Seebach (3):
  gcc-runtime: Drop libgomp for mingw32 runtime
  binutils*.bbappend: Work with all 2.25 versions
  gcc*.bbappend: Work with 5.2.

 recipes-devtools/binutils/binutils-cross-canadian_2.25%.bbappend | 5 +
 recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend  | 5 -
 recipes-devtools/gcc/gcc-cross-canadian_%.bbappend   | 6 ++
 recipes-devtools/gcc/gcc-cross-canadian_4.9.bbappend | 6 --
 recipes-devtools/gcc/gcc-crosssdk-initial_%.bbappend | 1 +
 recipes-devtools/gcc/gcc-crosssdk-initial_4.9.bbappend   | 1 -
 recipes-devtools/gcc/gcc-crosssdk_%.bbappend | 1 +
 recipes-devtools/gcc/gcc-crosssdk_4.9.bbappend   | 1 -
 recipes-devtools/gcc/gcc-runtime_%.bbappend  | 8 
 recipes-devtools/gcc/gcc-runtime_4.9.bbappend| 8 
 recipes-devtools/gcc/gcc_%.bbappend  | 6 ++
 recipes-devtools/gcc/libgcc_%.bbappend   | 2 ++
 recipes-devtools/gcc/libgcc_4.9.bbappend | 2 --
 13 files changed, 29 insertions(+), 23 deletions(-)
 create mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.25%.bbappend
 delete mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend
 create mode 100644 recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-cross-canadian_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/gcc-crosssdk-initial_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-crosssdk-initial_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/gcc-crosssdk_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-crosssdk_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/gcc-runtime_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-runtime_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/gcc_%.bbappend
 create mode 100644 recipes-devtools/gcc/libgcc_%.bbappend
 delete mode 100644 recipes-devtools/gcc/libgcc_4.9.bbappend

-- 
1.9.3

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

Re: [yocto] [meta-java] can zero shark be enabled again?

2015-10-20 Thread Federico Pietro Briata 
2015-10-16 17:14 GMT+02:00 Jens Rehsack :

>
> While IcedTea maintains the ARMJIT within hotspot ported from OpenJDK6,
> ZeroShark uses LLVM's JIT.
>
> Since ARM support in LLVM's JIT was utterly broken, MCJIT support is
> required for ZeroShark.
> I was working on that but my ARMv7 and my ARMv5 are still crashing - even
> when I can realize some progress (how quick does it crash ^^).
>
>
Hi
I'm trying to compare performance of openjdk 7 with Oracle ejdk 8

# java -version
java version "1.7.0_85"
OpenJDK Runtime Environment (IcedTea 2.6.1) (85b01-2.6.1)
OpenJDK Zero VM (build 24.85-b03, mixed mode)
# java Linpack
Mflops/s: 13.205  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16


# /usr/local/java.oracle/bin/java -version
java version "1.8.0_06"
Java(TM) SE Embedded Runtime Environment (build 1.8.0_06-b23)
Java HotSpot(TM) Embedded Client VM (build 25.6-b23, mixed mode)
# /usr/local/java.oracle/bin/java Linpack
Mflops/s: 22.151  Time: 0.03 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16


As I prefer stay free and avoid commercial solution, anyone can confirm me that
I didn't forgot some optimization in my OpenJDK or something it's still
improved?

thanks and regards
federico
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

2015-10-20 Thread Christopher Larson 
On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker  wrote:

> On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
> > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > wrote:
> >
> > Hello,
> >
> > I noticed that at the time of rootfs creation symbolic links of the ipk
> files present in deploy/ipk. The problem what have it while creation of
> symbolic link it take the full path till that ipk and remove slashes and
> convert them into underscores. Use that as the name of the symbolic link.
> This make a very long file names. If we have very long path then name of
> the symlink exceed from max filename limits. And we get following error
> >
> > Collected errors:
> > * file_link: unable to stat
> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/
> opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
> File name too long.
> >
> > Can anyone tell me why the addition of full path was added to the
> symlink name and can we remove it cause it is cause issues?
> >
> > what does
> >
> > getconf PATH_MAX /
> >
> > show ?
> >
> > jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
> > PATH_MAX   4096
> > _POSIX_PATH_MAX4096
> >
> >
> > I think the issue is with file name not the path.
> >
> > Secondly the googling which I did reveals that symlink creation can't be
> stopped. I just wanna confirm that is my findings correct?
> >
>
> This looks like something we overlooked in opkg. When we added the
> caching code
> we didn't think about how long the paths and filenames might get during the
> rootfs step. It's not currently possible to reduce the length of the
> symlink
> filenames, but it is possible to change the directory in which the
> symlinks are
> created.
>
> Currently the opkg cache dir can only be set in the opkg.conf file. I
> think we
> should add a '--cache-dir' argument to opkg. If this is added you'll be
> able to
> set the following in your local.conf file to change the cache location.
> Eg. to
> use '/tmp/opkg' on the host during rootfs creation.
>
> OPKG_ARGS = "--cache-dir=/tmp/opkg"
>
> I'll submit a patch to opkg to add this option.
>

This will only shorten the full path, not the filename length, so I doubt
this'll solve it. That said, I can't actually successfully test this today,
because cache_dir is made relative to offline_root, so setting such a path
as you suggest doesn't shorten the full path either.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][PATCH] ref-manual: Document MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS quirk

2015-10-20 Thread california . l . sullivan 
From: California Sullivan 

MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS won't always grab your out-of-tree
module recipe since the kernel recipe's PACKAGES_DYNAMIC variable
provides kernel-module-*. This patch documents that your out-of-tree
module needs to explicitly set its PACKAGES variable to avoid this
behavior.

Fixes [YOCTO #7591]

Signed-off-by: California Sullivan 
---
 documentation/ref-manual/ref-variables.xml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index 8241094..6270a83 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -7510,6 +7510,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = 
"${INC_PR}.3"
 
  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
 
+Note that in this example, 
kernel-module-ab123's recipe
+would need to explicitly set its
+PACKAGES variable
+to ensure that bitbake does not use the kernel recipe's
+PACKAGES_DYNAMIC
+variable to satisfy the dependancy.
 
 
 
-- 
2.1.0

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

[yocto] [meta-mingw][PATCH 1/4] gcc-runtime: Drop libgomp for mingw32 runtime

2015-10-20 Thread Mark Hatle 
From: Peter Seebach 

The mingw32 runtime has issues building libgomp, so drop it for now.

Signed-off-by: Peter Seebach 
Signed-off-by: Mark Hatle 
---
 recipes-devtools/gcc/gcc-runtime_4.9.bbappend | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-devtools/gcc/gcc-runtime_4.9.bbappend 
b/recipes-devtools/gcc/gcc-runtime_4.9.bbappend
index 50ca3ca..b068dfd 100644
--- a/recipes-devtools/gcc/gcc-runtime_4.9.bbappend
+++ b/recipes-devtools/gcc/gcc-runtime_4.9.bbappend
@@ -1,8 +1,8 @@
 FILES_libstdc++_append_mingw32 = " ${bindir}/libstdc++*.dll"
 FILES_libstdc++-staticdev_append_mingw32 = " ${libdir}/libstdc++.dll.a*"
 FILES_libssp_append_mingw32 = " ${bindir}/libssp*.dll"
-FILES_libgomp_append_mingw32 = " ${bindir}/libgomp*.dll"
+# FILES_libgomp_append_mingw32 = " ${bindir}/libgomp*.dll"
 
-RUNTIMETARGET_remove_mingw32 = "libatomic"
+RUNTIMETARGET_remove_mingw32 = "libatomic libgomp"
 
 DEPENDS_append_mingw32 = " pthreads-win32"
-- 
1.9.3

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

Re: [yocto] opkg 0.3.0 or rootfs task

2015-10-20 Thread Christopher Larson 
On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson 
wrote:

>
> On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker 
> wrote:
>
>> On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
>> > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor  noor_ah...@mentor.com>> wrote:
>> >
>> > Hello,
>> >
>> > I noticed that at the time of rootfs creation symbolic links of the ipk
>> files present in deploy/ipk. The problem what have it while creation of
>> symbolic link it take the full path till that ipk and remove slashes and
>> convert them into underscores. Use that as the name of the symbolic link.
>> This make a very long file names. If we have very long path then name of
>> the symlink exceed from max filename limits. And we get following error
>> >
>> > Collected errors:
>> > * file_link: unable to stat
>> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/
>> opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
>> File name too long.
>> >
>> > Can anyone tell me why the addition of full path was added to the
>> symlink name and can we remove it cause it is cause issues?
>> >
>> > what does
>> >
>> > getconf PATH_MAX /
>> >
>> > show ?
>> >
>> > jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
>> > PATH_MAX   4096
>> > _POSIX_PATH_MAX4096
>> >
>> >
>> > I think the issue is with file name not the path.
>> >
>> > Secondly the googling which I did reveals that symlink creation can't
>> be stopped. I just wanna confirm that is my findings correct?
>> >
>>
>> This looks like something we overlooked in opkg. When we added the
>> caching code
>> we didn't think about how long the paths and filenames might get during
>> the
>> rootfs step. It's not currently possible to reduce the length of the
>> symlink
>> filenames, but it is possible to change the directory in which the
>> symlinks are
>> created.
>>
>> Currently the opkg cache dir can only be set in the opkg.conf file. I
>> think we
>> should add a '--cache-dir' argument to opkg. If this is added you'll be
>> able to
>> set the following in your local.conf file to change the cache location.
>> Eg. to
>> use '/tmp/opkg' on the host during rootfs creation.
>>
>> OPKG_ARGS = "--cache-dir=/tmp/opkg"
>>
>> I'll submit a patch to opkg to add this option.
>>
>
> This will only shorten the full path, not the filename length, so I doubt
> this'll solve it. That said, I can't actually successfully test this today,
> because cache_dir is made relative to offline_root, so setting such a path
> as you suggest doesn't shorten the full path either.


Also, did a touch of just the cache filename and it gives the same filename
length error, so where the cache dir is really isn't going to matter, it's
the filename including the full path to a deep BUILDDIR, and therefore
DEPLOY_DIR_IPK, which is the problem.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 3/4] gcc*.bbappend: Work with 5.2.

2015-10-20 Thread Mark Hatle 
From: Peter Seebach 

Rename the bbappends to use % so they can be used with both 4.x
and 5.x. None of these changes appear to be specific to a given
version of gcc.

Signed-off-by: Peter Seebach 
Signed-off-by: Mark Hatle 
---
 recipes-devtools/gcc/gcc-cross-canadian_%.bbappend | 6 ++
 recipes-devtools/gcc/gcc-cross-canadian_4.9.bbappend   | 6 --
 recipes-devtools/gcc/gcc-crosssdk-initial_%.bbappend   | 1 +
 recipes-devtools/gcc/gcc-crosssdk-initial_4.9.bbappend | 1 -
 recipes-devtools/gcc/gcc-crosssdk_%.bbappend   | 1 +
 recipes-devtools/gcc/gcc-crosssdk_4.9.bbappend | 1 -
 recipes-devtools/gcc/gcc-runtime_%.bbappend| 8 
 recipes-devtools/gcc/gcc-runtime_4.9.bbappend  | 8 
 recipes-devtools/gcc/libgcc_%.bbappend | 2 ++
 recipes-devtools/gcc/libgcc_4.9.bbappend   | 2 --
 10 files changed, 18 insertions(+), 18 deletions(-)
 create mode 100644 recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-cross-canadian_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/gcc-crosssdk-initial_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-crosssdk-initial_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/gcc-crosssdk_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-crosssdk_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/gcc-runtime_%.bbappend
 delete mode 100644 recipes-devtools/gcc/gcc-runtime_4.9.bbappend
 create mode 100644 recipes-devtools/gcc/libgcc_%.bbappend
 delete mode 100644 recipes-devtools/gcc/libgcc_4.9.bbappend

diff --git a/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend 
b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
new file mode 100644
index 000..030a9b9
--- /dev/null
+++ b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
@@ -0,0 +1,6 @@
+INSANE_SKIP_${PN}_append_sdkmingw32 = " staticdev"
+EXTRA_OECONF_append_sdkmingw32 = " --disable-nls"
+LDFLAGS_append_sdkmingw32 = " -Wl,-static"
+EXEEXT_sdkmingw32 = ".exe"
+ELFUTILS_sdkmingw32 = ""
+DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
diff --git a/recipes-devtools/gcc/gcc-cross-canadian_4.9.bbappend 
b/recipes-devtools/gcc/gcc-cross-canadian_4.9.bbappend
deleted file mode 100644
index 030a9b9..000
--- a/recipes-devtools/gcc/gcc-cross-canadian_4.9.bbappend
+++ /dev/null
@@ -1,6 +0,0 @@
-INSANE_SKIP_${PN}_append_sdkmingw32 = " staticdev"
-EXTRA_OECONF_append_sdkmingw32 = " --disable-nls"
-LDFLAGS_append_sdkmingw32 = " -Wl,-static"
-EXEEXT_sdkmingw32 = ".exe"
-ELFUTILS_sdkmingw32 = ""
-DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
diff --git a/recipes-devtools/gcc/gcc-crosssdk-initial_%.bbappend 
b/recipes-devtools/gcc/gcc-crosssdk-initial_%.bbappend
new file mode 100644
index 000..1c09342
--- /dev/null
+++ b/recipes-devtools/gcc/gcc-crosssdk-initial_%.bbappend
@@ -0,0 +1 @@
+DEPENDS_append_mingw32 = " nativesdk-mingw-w64-headers"
diff --git a/recipes-devtools/gcc/gcc-crosssdk-initial_4.9.bbappend 
b/recipes-devtools/gcc/gcc-crosssdk-initial_4.9.bbappend
deleted file mode 100644
index 1c09342..000
--- a/recipes-devtools/gcc/gcc-crosssdk-initial_4.9.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-DEPENDS_append_mingw32 = " nativesdk-mingw-w64-headers"
diff --git a/recipes-devtools/gcc/gcc-crosssdk_%.bbappend 
b/recipes-devtools/gcc/gcc-crosssdk_%.bbappend
new file mode 100644
index 000..77ba57f
--- /dev/null
+++ b/recipes-devtools/gcc/gcc-crosssdk_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF_mingw32 := 
"${@oe_filter_out('--with-linker-hash-style=${LINKER_HASH_STYLE}', 
'${EXTRA_OECONF}', d)}"
diff --git a/recipes-devtools/gcc/gcc-crosssdk_4.9.bbappend 
b/recipes-devtools/gcc/gcc-crosssdk_4.9.bbappend
deleted file mode 100644
index 77ba57f..000
--- a/recipes-devtools/gcc/gcc-crosssdk_4.9.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-EXTRA_OECONF_mingw32 := 
"${@oe_filter_out('--with-linker-hash-style=${LINKER_HASH_STYLE}', 
'${EXTRA_OECONF}', d)}"
diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend 
b/recipes-devtools/gcc/gcc-runtime_%.bbappend
new file mode 100644
index 000..b068dfd
--- /dev/null
+++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
@@ -0,0 +1,8 @@
+FILES_libstdc++_append_mingw32 = " ${bindir}/libstdc++*.dll"
+FILES_libstdc++-staticdev_append_mingw32 = " ${libdir}/libstdc++.dll.a*"
+FILES_libssp_append_mingw32 = " ${bindir}/libssp*.dll"
+# FILES_libgomp_append_mingw32 = " ${bindir}/libgomp*.dll"
+
+RUNTIMETARGET_remove_mingw32 = "libatomic libgomp"
+
+DEPENDS_append_mingw32 = " pthreads-win32"
diff --git a/recipes-devtools/gcc/gcc-runtime_4.9.bbappend 
b/recipes-devtools/gcc/gcc-runtime_4.9.bbappend
deleted file mode 100644
index b068dfd..000
--- a/recipes-devtools/gcc/gcc-runtime_4.9.bbappend
+++ /dev/null
@@ -1,8 +0,0 @@
-FILES_libstdc++_append_mingw32 = " ${bindir}/libstdc++*.dll"
-FILES_libstdc++-staticdev_append_mingw32 = " ${libdir}/libstdc++.dll.a*"

[yocto] [meta-mingw][PATCH 2/4] binutils*.bbappend: Work with all 2.25 versions

2015-10-20 Thread Mark Hatle 
From: Peter Seebach 

Signed-off-by: Peter Seebach 
Signed-off-by: Mark Hatle 
---
 recipes-devtools/binutils/binutils-cross-canadian_2.25%.bbappend | 5 +
 recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend  | 5 -
 2 files changed, 5 insertions(+), 5 deletions(-)
 create mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.25%.bbappend
 delete mode 100644 
recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend

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"
diff --git a/recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend 
b/recipes-devtools/binutils/binutils-cross-canadian_2.25.bbappend
deleted file mode 100644
index 026c932..000
--- a/recipes-devtools/binutils/binutils-cross-canadian_2.25.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"
-- 
1.9.3

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

[yocto] Modifying the OE-internal Python code

2015-10-20 Thread PIEWALD Georg 
Hi,
I'm trying to do some modifications in the OE-internals (just some personal 
customizations), in the Python code. In particular, I changed the file
oe-core/meta/lib/oe/terminal.py
I also compiled it into a terminal.pyc file. However, the modifications don't 
seem to be picked up by bitbake. Is there something more I have to do? Does the 
.pyc file have to be installed somewhere?

Thanks for any hints,
Georg
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] libselinux, libsepol: depends on coreutils-native

2015-10-20 Thread Khem Raj 

> On Oct 20, 2015, at 2:49 AM, wenzong@windriver.com wrote:
> 
> From: Wenzong Fan 
> 
> 'ln --relative' doesn't work on Ubuntu 12.04 that has ln 8.13. The

OE-Core has lnr script you can use that.

> changes involved by SELinux commit:
> 
>  commit 71393a181d63c9baae5fe8dcaeb9411d1f253998
>  Author: Steve Lawrence 
>  Date:   Mon Oct 20 15:46:17 2014 -0400
> 
>libselinux: libsepol: use ln --relative to create .so symlinks
> 
>The current build system assumes SHLIBDIR is ../../ relative to LIBDIR.
>However, this isn't always the case. For example, Arch Linux sets both
>LIBDIR and SHLIBDIR to /usr/lib, which results in broken symlinks.
> 
>Instead of making that assumption, create .so symlinks using ln
>--relative so that the correct relative paths are used. Note that this
>adds a dependency for the build system to use coretuils-8.16 or later.
> 
> Just depends on coreutils-native to fix the issue.
> 
> Signed-off-by: Wenzong Fan 
> ---
> recipes-security/selinux/libselinux.inc | 2 +-
> recipes-security/selinux/libsepol.inc   | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/recipes-security/selinux/libselinux.inc 
> b/recipes-security/selinux/libselinux.inc
> index d571a7c..b0f7bc4 100644
> --- a/recipes-security/selinux/libselinux.inc
> +++ b/recipes-security/selinux/libselinux.inc
> @@ -7,7 +7,7 @@ LICENSE = "PD"
> 
> inherit lib_package pythonnative
> 
> -DEPENDS += "libsepol python libpcre swig-native"
> +DEPENDS += "libsepol python libpcre swig-native coreutils-native"
> 
> PACKAGES += "${PN}-python"
> FILES_${PN}-python = 
> "${libdir}/python${PYTHON_BASEVERSION}/site-packages/selinux/*"
> diff --git a/recipes-security/selinux/libsepol.inc 
> b/recipes-security/selinux/libsepol.inc
> index b24ed28..9234f24 100644
> --- a/recipes-security/selinux/libsepol.inc
> +++ b/recipes-security/selinux/libsepol.inc
> @@ -8,6 +8,8 @@ LICENSE = "LGPLv2+"
> 
> inherit lib_package
> 
> +DEPENDS += "coreutils-native"
> +
> # Change RANLIB for cross compiling, use host-tools $(AR) rather than
> # local ranlib.
> EXTRA_OEMAKE += "RANLIB='$(AR) s'"
> --
> 1.9.1
> 
> --
> ___
> 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

[yocto] [PATCH] buildset-config.staging/nightly-no-x11.conf

2015-10-20 Thread Graydon, Tracy 
[YOCTO #6854]

This patchset relocates nigtly-no-x11.conf to buildset-config.staging
while work in in progress. It also removes nightly-no-x11 from the
yoctoAB.conf file in buildset-config.controller dir. This effecitively
removed the currently non-functioning no-x11 build from nightly build
for now.

Signed-off-by: Graydon, Tracy 
---
 buildset-config.controller/nightly-no-x11.conf | 19 ---
 buildset-config.controller/yoctoAB.conf| 10 +-
 buildset-config.staging/nightly-no-x11.conf| 19 +++
 3 files changed, 24 insertions(+), 24 deletions(-)
 delete mode 100644 buildset-config.controller/nightly-no-x11.conf
 create mode 100644 buildset-config.staging/nightly-no-x11.conf

diff --git a/buildset-config.controller/nightly-no-x11.conf 
b/buildset-config.controller/nightly-no-x11.conf
deleted file mode 100644
index 4881154..000
--- a/buildset-config.controller/nightly-no-x11.conf
+++ /dev/null
@@ -1,19 +0,0 @@
-[nightly-no-x11]
-builders: 'example-worker'
-repos: [{'poky':
-{'repourl':'git://git.yoctoproject.org/poky',
- 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
- 'branch':'master'}}]
-steps: [{'SetDest':{}},
-{'CheckOutLayers': {}},
-{'RunPreamble': {}},
-{'GetDistroVersion' : {'distro': 'poky'}},
-{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686',
-'distro': 'poky', 'buildhistory' : False,
-'atextappend' : '\nDISTRO_FEATURES_remove = 
"x11"\n'}},
-{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
-{'SyncPersistDB' : {'distro' : 'poky'}},
-{'GetBitbakeVersion': {}},
-{'BuildImages': {'images': 'world'}},
-{'SendErrorReport': {}},
-{'UploadToasterEventlog': {}}]
diff --git a/buildset-config.controller/yoctoAB.conf 
b/buildset-config.controller/yoctoAB.conf
index 0f9ba0c..5f39d6f 100644
--- a/buildset-config.controller/yoctoAB.conf
+++ b/buildset-config.controller/yoctoAB.conf
@@ -3,9 +3,9 @@ order: ['nightly', 'eclipse-plugin-mars',
 'eclipse-plugin-kepler', 'eclipse-plugin-luna',
 'nightly-arm', 'nightly-arm64', 'nightly-arm-lsb', 
 'nightly-mips', 'nightly-mips64', 'nightly-mips-lsb', 
-'nightly-ppc', 'nightly-ppc-lsb', 'nightly-no-x11',
-'nightly-x86-64', 'nightly-x86-64-lsb', 'nightly-x86',
-'nightly-x86-lsb', 'nightly-x32', 'nightly-multilib',
-'nightly-world', 'nightly-world-lsb', 'nightly-non-gpl3', 
-'nightly-oecore', 'nightly-intel-gpl', 'nightly-wic', 'poky-tiny',
+'nightly-ppc', 'nightly-ppc-lsb', 'nightly-x86-64', 
+'nightly-x86-64-lsb', 'nightly-x86', 'nightly-x86-lsb', 
+'nightly-x32', 'nightly-multilib', 'nightly-world', 
+'nightly-world-lsb', 'nightly-non-gpl3', 'nightly-oecore', 
+'nightly-intel-gpl', 'nightly-wic', 'poky-tiny',
 'build-appliance', 'nightly-qa-extras', 'nightly-qa-systemd']
diff --git a/buildset-config.staging/nightly-no-x11.conf 
b/buildset-config.staging/nightly-no-x11.conf
new file mode 100644
index 000..4881154
--- /dev/null
+++ b/buildset-config.staging/nightly-no-x11.conf
@@ -0,0 +1,19 @@
+[nightly-no-x11]
+builders: 'example-worker'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686',
+'distro': 'poky', 'buildhistory' : False,
+'atextappend' : '\nDISTRO_FEATURES_remove = 
"x11"\n'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'SyncPersistDB' : {'distro' : 'poky'}},
+{'GetBitbakeVersion': {}},
+{'BuildImages': {'images': 'world'}},
+{'SendErrorReport': {}},
+{'UploadToasterEventlog': {}}]
-- 
2.4.3

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