[yocto] [PATCH] buildset-config.staging/nightly-no-x11.conf
[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
Re: [yocto] [PATCH][meta-selinux] libselinux, libsepol: depends on coreutils-native
> 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] Modifying the OE-internal Python code
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
[yocto] Beagle Bone Black problem with hotplug USB
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] [yocto-docs][PATCH] ref-manual: Document MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS quirk
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
Re: [yocto] opkg 0.3.0 or rootfs task
On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson wrote: > > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker > wrote: > >> On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote: >> > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > noor_ah...@mentor.com>> wrote: >> > >> > Hello, >> > >> > I noticed that at the time of rootfs creation symbolic links of the ipk >> files present in deploy/ipk. The problem what have it while creation of >> symbolic link it take the full path till that ipk and remove slashes and >> convert them into underscores. Use that as the name of the symbolic link. >> This make a very long file names. If we have very long path then name of >> the symlink exceed from max filename limits. And we get following error >> > >> > Collected errors: >> > * file_link: unable to stat >> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/ >> opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': >> File name too long. >> > >> > Can anyone tell me why the addition of full path was added to the >> symlink name and can we remove it cause it is cause issues? >> > >> > what does >> > >> > getconf PATH_MAX / >> > >> > show ? >> > >> > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX >> > PATH_MAX 4096 >> > _POSIX_PATH_MAX4096 >> > >> > >> > I think the issue is with file name not the path. >> > >> > Secondly the googling which I did reveals that symlink creation can't >> be stopped. I just wanna confirm that is my findings correct? >> > >> >> This looks like something we overlooked in opkg. When we added the >> caching code >> we didn't think about how long the paths and filenames might get during >> the >> rootfs step. It's not currently possible to reduce the length of the >> symlink >> filenames, but it is possible to change the directory in which the >> symlinks are >> created. >> >> Currently the opkg cache dir can only be set in the opkg.conf file. I >> think we >> should add a '--cache-dir' argument to opkg. If this is added you'll be >> able to >> set the following in your local.conf file to change the cache location. >> Eg. to >> use '/tmp/opkg' on the host during rootfs creation. >> >> OPKG_ARGS = "--cache-dir=/tmp/opkg" >> >> I'll submit a patch to opkg to add this option. >> > > This will only shorten the full path, not the filename length, so I doubt > this'll solve it. That said, I can't actually successfully test this today, > because cache_dir is made relative to offline_root, so setting such a path > as you suggest doesn't shorten the full path either. Also, did a touch of just the cache filename and it gives the same filename length error, so where the cache dir is really isn't going to matter, it's the filename including the full path to a deep BUILDDIR, and therefore DEPLOY_DIR_IPK, which is the problem. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] opkg 0.3.0 or rootfs task
On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker wrote: > On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote: > > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor noor_ah...@mentor.com>> wrote: > > > > Hello, > > > > I noticed that at the time of rootfs creation symbolic links of the ipk > files present in deploy/ipk. The problem what have it while creation of > symbolic link it take the full path till that ipk and remove slashes and > convert them into underscores. Use that as the name of the symbolic link. > This make a very long file names. If we have very long path then name of > the symlink exceed from max filename limits. And we get following error > > > > Collected errors: > > * file_link: unable to stat > `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/ > opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': > File name too long. > > > > Can anyone tell me why the addition of full path was added to the > symlink name and can we remove it cause it is cause issues? > > > > what does > > > > getconf PATH_MAX / > > > > show ? > > > > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX > > PATH_MAX 4096 > > _POSIX_PATH_MAX4096 > > > > > > I think the issue is with file name not the path. > > > > Secondly the googling which I did reveals that symlink creation can't be > stopped. I just wanna confirm that is my findings correct? > > > > This looks like something we overlooked in opkg. When we added the > caching code > we didn't think about how long the paths and filenames might get during the > rootfs step. It's not currently possible to reduce the length of the > symlink > filenames, but it is possible to change the directory in which the > symlinks are > created. > > Currently the opkg cache dir can only be set in the opkg.conf file. I > think we > should add a '--cache-dir' argument to opkg. If this is added you'll be > able to > set the following in your local.conf file to change the cache location. > Eg. to > use '/tmp/opkg' on the host during rootfs creation. > > OPKG_ARGS = "--cache-dir=/tmp/opkg" > > I'll submit a patch to opkg to add this option. > This will only shorten the full path, not the filename length, so I doubt this'll solve it. That said, I can't actually successfully test this today, because cache_dir is made relative to offline_root, so setting such a path as you suggest doesn't shorten the full path either. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-mingw][PATCH 0/4] Fix meta-mingw support to work with Jethro
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
[yocto] [meta-mingw][PATCH 4/4] nativesdk-gcc: Add mingw32 named libraries to files list
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 2/4] binutils*.bbappend: Work with all 2.25 versions
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] [meta-mingw][PATCH 3/4] gcc*.bbappend: Work with 5.2.
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*" -FILES_libssp_append_mingw32 = " ${bindir}/libssp*.dll" -# FILES_libgomp_append_mingw32 = " ${bindir}
[yocto] [meta-mingw][PATCH 1/4] gcc-runtime: Drop libgomp for mingw32 runtime
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] [meta-java] can zero shark be enabled again?
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] multiple yocto-kernel-cache mirrors support in linux-yocto style recipe
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] multiple yocto-kernel-cache mirrors support in linux-yocto style recipe
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: [yocto] How can i install shutil.py in rootfs
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
Re: [yocto] Nightly build and world build
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
[yocto] [PATCH][meta-selinux] libselinux, libsepol: depends on coreutils-native
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
Re: [yocto] How can i install shutil.py in rootfs
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] How can i install shutil.py in rootfs
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