[oe] [meta-oe][PATCH v2] gflags: correct S and update library install directory
From: Kai KangThe current setting of S is not right for multilib. Remove the setting and use the default value. And library install directory is not right either. Pass ${libdir} to fix the [installed-vs-shipped] QA issue: | ERROR: gflags-2.2.0-r0 do_package: QA Issue: gflags: Files/directories | were installed but not shipped in any package: | /usr/lib/libgflags.so | /usr/lib/libgflags_nothreads.so.2.2 Signed-off-by: Kai Kang --- meta-oe/recipes-support/gflags/gflags_2.2.0.bb | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb index b9188c3..77617ef 100644 --- a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb +++ b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb @@ -8,13 +8,12 @@ LIC_FILES_CHKSUM = "file://COPYING.txt;md5=c80d1a3b623f72bb85a4c75b556551df" SRC_URI = "https://github.com/gflags/gflags/archive/v${PV}.tar.gz; SRC_URI[md5sum] = "b99048d9ab82d8c56e876fb1456c285e" SRC_URI[sha256sum] = "466c36c6508a451734e4f4d76825cf9cd9b8716d2b70ef36479ae40f08271f88" -S = "${WORKDIR}/${PN}-${PV}/" FILES_${PN}-dev += "${libdir}/cmake" inherit cmake -EXTRA_OECMAKE="-DBUILD_SHARED_LIBS=ON -DREGISTER_INSTALL_PREFIX=OFF" +EXTRA_OECMAKE="-DBUILD_SHARED_LIBS=ON -DREGISTER_INSTALL_PREFIX=OFF -DLIBRARY_INSTALL_DIR=${libdir}" PACKAGES =+ "${PN}-bash-completion" FILES_${PN}-bash-completion += "${bindir}/gflags_completions.sh" -- 2.10.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] gflags: remove setting of S
From: Kai KangThe current setting of S is not right for multilib. Remove the setting and use the default value. Signed-off-by: Kai Kang --- meta-oe/recipes-support/gflags/gflags_2.2.0.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb index b9188c3..61a5972 100644 --- a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb +++ b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb @@ -8,7 +8,6 @@ LIC_FILES_CHKSUM = "file://COPYING.txt;md5=c80d1a3b623f72bb85a4c75b556551df" SRC_URI = "https://github.com/gflags/gflags/archive/v${PV}.tar.gz; SRC_URI[md5sum] = "b99048d9ab82d8c56e876fb1456c285e" SRC_URI[sha256sum] = "466c36c6508a451734e4f4d76825cf9cd9b8716d2b70ef36479ae40f08271f88" -S = "${WORKDIR}/${PN}-${PV}/" FILES_${PN}-dev += "${libdir}/cmake" -- 2.10.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] OpenEmbedded Layer Index autobuild errors
On Monday, 20 March 2017 11:46:06 AM NZDT Paul Eggleton wrote: > On Monday, 20 March 2017 11:33:16 AM NZDT Paul Eggleton wrote: > > On Monday, 20 March 2017 10:51:46 AM NZDT Max Krummenacher wrote: > > > Am Sonntag, den 19.03.2017, 12:04 -0400 schrieb Daniel Dickinson: > > > > On Sun, 19 Mar 2017 15:39:38 +0100 > > > > > > > > Gary Thomaswrote: > > > > > > With that change all tools which must be installed on the host > > > > > > need > > > > > > to be present, even if in your use case some of them might not be > > > > > > used. Did you install the prerequisites? > > > > > > http://www.yoctoproject.org/docs/2.2.1/ref-manual/ref-manual.html# > > > > > > re > > > > > > qu > > > > > > ired-packages-for-the-ho st-dev > > > > > > elopment-system > > > > > > > > > > The real point is that it's not his host - it's the [remote] > > > > > autobuilder tool for OpenEmbedded (IIRC) > > > > > > > > Yes, thank you. I'm not sure it's a full autobuilder or just parses > > > > recipes for generating the web pages, but either way it's not my host, > > > > it's an openembedded.org host. Apparently I'm not good at explaining > > > > that... > > > > > > My bad, sorry. > > > > > > And it looks like the host fails to update any of the layers, e.g. also > > > openembedded-core: > > > https://layers.openembedded.org/layerindex/layerupdate/323749/ > > > Adding Paul, as he maybe knows how to get those tools onto the server. > > > > Ah yes - I think I may just take the cheap way out and clear HOSTTOOLS > > when > > parsing in the index - we're not doing any actual building, after all, so > > we're not going to be calling any of these tools). > > Well, perhaps I spoke too soon. We call gcc to check its version just when > parsing, I suspect there may be others, so maybe the safest thing is to just > install these tools. Things are rarely as simple as they first appear... FYI I have merged a patch for this, just waiting for it to be applied in the OE infrastructure now. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH V2 02/16] rapidjson: Update to 1.1.0 + git
On Mon, Mar 20, 2017 at 2:30 PM, Andre McCurdywrote: > On Sun, Mar 19, 2017 at 10:31 PM, Khem Raj wrote: >> Drop backports >> Adjust the license checksums to match the changes to file especially >> >> https://github.com/miloyip/rapidjson/commit/b4b1a39937fbd168ef72ea477f90f626773d56fc >> >> Signed-off-by: Khem Raj >> --- >> .../Fix-gcc-strict-overflow-warning.patch | 30 >> .../remove-march-native-from-CMAKE_CXX_FLAGS.patch | 41 >> +- >> .../{rapidjson_1.0.2.bb => rapidjson_git.bb} | 9 ++--- >> 3 files changed, 29 insertions(+), 51 deletions(-) >> delete mode 100644 >> meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch >> rename meta-oe/recipes-devtools/rapidjson/{rapidjson_1.0.2.bb => >> rapidjson_git.bb} (73%) >> >> diff --git >> a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch >> >> b/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch >> deleted file mode 100644 >> index 6ce3933ce..0 >> --- >> a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch >> +++ /dev/null >> @@ -1,30 +0,0 @@ >> -From f5560d9557ee48fb79810180ddfd3ec386e2a7b5 Mon Sep 17 00:00:00 2001 >> -From: Milo Yip >> -Date: Wed, 2 Mar 2016 01:01:17 +0800 >> -Subject: [PATCH] Fix gcc strict-overflow warning >> - >> -Fix #566 #568 >> - >> -Upstream-Status: Backport [Partial merge of upstream commit 928caf92e] >> - >> -Signed-off-by: Andre McCurdy >> >> - include/rapidjson/internal/dtoa.h | 2 +- >> - 1 file changed, 1 insertion(+), 1 deletion(-) >> - >> -diff --git a/include/rapidjson/internal/dtoa.h >> b/include/rapidjson/internal/dtoa.h >> -index 2d8d2e4..15571e1 100644 >> a/include/rapidjson/internal/dtoa.h >> -+++ b/include/rapidjson/internal/dtoa.h >> -@@ -148,7 +148,7 @@ inline char* WriteExponent(int K, char* buffer) { >> - inline char* Prettify(char* buffer, int length, int k) { >> - const int kk = length + k; // 10^(kk-1) <= v < 10^kk >> - >> --if (length <= kk && kk <= 21) { >> -+if (0 <= k && kk <= 21) { >> - // 1234e7 -> 1234000 >> - for (int i = length; i < kk; i++) >> - buffer[i] = '0'; >> --- >> -1.9.1 >> - >> diff --git >> a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch >> >> b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch >> index 17164283c..cf3e16ea5 100644 >> --- >> a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch >> +++ >> b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch >> @@ -12,22 +12,29 @@ Signed-off-by: Andre McCurdy >> CMakeLists.txt | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> -diff --git a/CMakeLists.txt b/CMakeLists.txt >> -index 68139ba..cae7c9b 100644 >> a/CMakeLists.txt >> -+++ b/CMakeLists.txt >> -@@ -26,9 +26,9 @@ if(RAPIDJSON_HAS_STDSTRING) >> - endif() >> +Index: git/CMakeLists.txt >> +=== >> +--- git.orig/CMakeLists.txt >> git/CMakeLists.txt >> +@@ -51,10 +51,10 @@ endif(CCACHE_FOUND) >> >> if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU") >> --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra") >> -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra") >> - elseif (CMAKE_CXX_COMPILER_ID MATCHES "Clang") >> --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra") >> -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra") >> - elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC") >> - add_definitions(-D_CRT_SECURE_NO_WARNINGS=1) >> - endif() >> --- >> -1.9.1 >> - >> + if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "powerpc" OR >> ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "ppc64" OR ${CMAKE_SYSTEM_PROCESSOR} >> STREQUAL "ppc64le") >> +- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native") >> ++ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") >> + else() >> + #FIXME: x86 is -march=native, but doesn't mean every arch is this >> option. To keep original project's compatibility, I leave this except POWER. >> +- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native") >> ++ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") >> + endif() >> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror") >> + set(EXTRA_CXX_FLAGS -Weffc++ -Wswitch-default -Wfloat-equal >> -Wconversion -Wsign-conversion) >> +@@ -84,7 +84,7 @@ elseif (CMAKE_CXX_COMPILER_ID MATCHES "C >> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native") >> + else() >> + #FIXME: x86 is -march=native, but doesn't mean every arch is this >> option. To keep original project's compatibility, I leave
Re: [oe] [meta-oe][PATCH V2 02/16] rapidjson: Update to 1.1.0 + git
On Sun, Mar 19, 2017 at 10:31 PM, Khem Rajwrote: > Drop backports > Adjust the license checksums to match the changes to file especially > > https://github.com/miloyip/rapidjson/commit/b4b1a39937fbd168ef72ea477f90f626773d56fc > > Signed-off-by: Khem Raj > --- > .../Fix-gcc-strict-overflow-warning.patch | 30 > .../remove-march-native-from-CMAKE_CXX_FLAGS.patch | 41 > +- > .../{rapidjson_1.0.2.bb => rapidjson_git.bb} | 9 ++--- > 3 files changed, 29 insertions(+), 51 deletions(-) > delete mode 100644 > meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch > rename meta-oe/recipes-devtools/rapidjson/{rapidjson_1.0.2.bb => > rapidjson_git.bb} (73%) > > diff --git > a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch > > b/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch > deleted file mode 100644 > index 6ce3933ce..0 > --- > a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch > +++ /dev/null > @@ -1,30 +0,0 @@ > -From f5560d9557ee48fb79810180ddfd3ec386e2a7b5 Mon Sep 17 00:00:00 2001 > -From: Milo Yip > -Date: Wed, 2 Mar 2016 01:01:17 +0800 > -Subject: [PATCH] Fix gcc strict-overflow warning > - > -Fix #566 #568 > - > -Upstream-Status: Backport [Partial merge of upstream commit 928caf92e] > - > -Signed-off-by: Andre McCurdy > > - include/rapidjson/internal/dtoa.h | 2 +- > - 1 file changed, 1 insertion(+), 1 deletion(-) > - > -diff --git a/include/rapidjson/internal/dtoa.h > b/include/rapidjson/internal/dtoa.h > -index 2d8d2e4..15571e1 100644 > a/include/rapidjson/internal/dtoa.h > -+++ b/include/rapidjson/internal/dtoa.h > -@@ -148,7 +148,7 @@ inline char* WriteExponent(int K, char* buffer) { > - inline char* Prettify(char* buffer, int length, int k) { > - const int kk = length + k; // 10^(kk-1) <= v < 10^kk > - > --if (length <= kk && kk <= 21) { > -+if (0 <= k && kk <= 21) { > - // 1234e7 -> 1234000 > - for (int i = length; i < kk; i++) > - buffer[i] = '0'; > --- > -1.9.1 > - > diff --git > a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch > > b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch > index 17164283c..cf3e16ea5 100644 > --- > a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch > +++ > b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch > @@ -12,22 +12,29 @@ Signed-off-by: Andre McCurdy > CMakeLists.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > -diff --git a/CMakeLists.txt b/CMakeLists.txt > -index 68139ba..cae7c9b 100644 > a/CMakeLists.txt > -+++ b/CMakeLists.txt > -@@ -26,9 +26,9 @@ if(RAPIDJSON_HAS_STDSTRING) > - endif() > +Index: git/CMakeLists.txt > +=== > +--- git.orig/CMakeLists.txt > git/CMakeLists.txt > +@@ -51,10 +51,10 @@ endif(CCACHE_FOUND) > > if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU") > --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra") > -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra") > - elseif (CMAKE_CXX_COMPILER_ID MATCHES "Clang") > --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra") > -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra") > - elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC") > - add_definitions(-D_CRT_SECURE_NO_WARNINGS=1) > - endif() > --- > -1.9.1 > - > + if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "powerpc" OR > ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "ppc64" OR ${CMAKE_SYSTEM_PROCESSOR} > STREQUAL "ppc64le") > +- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native") > ++ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") > + else() > + #FIXME: x86 is -march=native, but doesn't mean every arch is this > option. To keep original project's compatibility, I leave this except POWER. > +- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native") > ++ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") > + endif() > + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror") > + set(EXTRA_CXX_FLAGS -Weffc++ -Wswitch-default -Wfloat-equal > -Wconversion -Wsign-conversion) > +@@ -84,7 +84,7 @@ elseif (CMAKE_CXX_COMPILER_ID MATCHES "C > + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native") > + else() > + #FIXME: x86 is -march=native, but doesn't mean every arch is this > option. To keep original project's compatibility, I leave this except POWER. > +- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native") > ++ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") > + endif() > + set(CMAKE_CXX_FLAGS
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Yes, good enough for me to include the PNBLACKLIST removal in next bitbake > world run. thanks > > On Mon, Mar 20, 2017 at 4:27 PM, Robert P. J. Day> wrote: > On Mon, 20 Mar 2017, Martin Jansa wrote: > > > Without "_pn-binutils". > > so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask) > after setting: > > DISTRO_FEATURES_append = " ld-is-gold" > > then rebuilt accel-ppp and it succeeded. is that considered an > adequate test? i'll let you throw in that patch since you probably have a better idea of what you want the commit msg to say. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-clang] llvm-config cross-compile improvements
On 03/20/2017 10:37 AM, Khem Raj wrote: On Sat, Mar 18, 2017 at 8:29 PM, Martin Kellywrote: Hi, This patch series fixes a number of issues I hit when trying to use the meta-clang llvm-config to cross-compile a project that uses CMake, calling into llvm-config, to determine compile flags. With the series applied, the cross compile successfully builds and runs. Please let me know if you have any concerns or if there is something I missed, and I will fix it up. The following changes since commit c9c74d269ba79abbc20919de96f1eb2b8a81edec: clang/compiler-rt: Fix nativesdk builds break compiler-rt dep for clang (2017-03-16 22:54:02 -0700) are available in the git repository at: https://github.com/surround-io/meta-clang for you to fetch changes up to 7d294bc2548ade23b7d25761d73769e712617c51: can you send a simple gh pull request please ? Done; sorry, from the meta-clang readme, I thought it was asking for pull requests to go over openembedded-devel, but I'm happy with Github too. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
Yes, good enough for me to include the PNBLACKLIST removal in next bitbake world run. thanks On Mon, Mar 20, 2017 at 4:27 PM, Robert P. J. Daywrote: > On Mon, 20 Mar 2017, Martin Jansa wrote: > > > Without "_pn-binutils". > > so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask) > after setting: > > DISTRO_FEATURES_append = " ld-is-gold" > > then rebuilt accel-ppp and it succeeded. is that considered an > adequate test? > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > > > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-clang] llvm-config cross-compile improvements
On Sat, Mar 18, 2017 at 8:29 PM, Martin Kellywrote: > Hi, > > This patch series fixes a number of issues I hit when trying to use the > meta-clang llvm-config to cross-compile a project that uses CMake, calling > into llvm-config, to determine compile flags. With the series applied, the > cross compile successfully builds and runs. Please let me know if you have > any concerns or if there is something I missed, and I will fix it up. > > The following changes since commit c9c74d269ba79abbc20919de96f1eb2b8a81edec: > > clang/compiler-rt: Fix nativesdk builds break compiler-rt dep for clang > (2017-03-16 22:54:02 -0700) > > are available in the git repository at: > > https://github.com/surround-io/meta-clang > > for you to fetch changes up to 7d294bc2548ade23b7d25761d73769e712617c51: > can you send a simple gh pull request please ? > clang: build for only target and host (2017-03-18 18:01:50 -0700) > > > Martin Kelly (5): > clang: correct spacing issue > clang: remove commented-out code > clang: fix the llvm-common wrapper > clang: build libLLVM.so > clang: build for only target and host > > recipes-devtools/clang/clang.inc | 5 - > > recipes-devtools/clang/clang/0004-llvm-allow-env-override-of-exe-path.patch > | 36 ++ > recipes-devtools/clang/clang_git.bb | 52 > ++ > recipes-devtools/clang/llvm-common/llvm-config | 41 > +++ > 4 files changed, 96 insertions(+), 38 deletions(-) > create mode 100644 > recipes-devtools/clang/clang/0004-llvm-allow-env-override-of-exe-path.patch -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Without "_pn-binutils". so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask) after setting: DISTRO_FEATURES_append = " ld-is-gold" then rebuilt accel-ppp and it succeeded. is that considered an adequate test? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH v2 1/2] lvm2: libdevicemapper package needs udev rules and dmsetup
Applications like kpartx and cryptsetup were broken by moving only libdevicemapper itself into a separate package: as a result of that change, lvm2 was not getting pulled into images anymore although libdevicemapper depends on dmsetup and udev rules to be fully functional. For example, "kpartx -as" started to hang while waiting for the udev rules to trigger, which is what creates the /dev/mapper/ entries for the new partitions (see also https://github.com/docker/docker/issues/22025#issuecomment-243943728). Putting udev rules and dmsetup also into libdevicemapper is perhaps counter-intuitive, but necessary to keep the package functioning. A full lvm2 installation is guaranteed to pull them in, too, both because of implicit library dependencies and (just to be sure) an explicit RDEPENDS. lvm2-native doesn't have packages, so this RDEPENDS must be limited to the target case. Signed-off-by: Patrick Ohly--- meta-oe/recipes-support/lvm2/lvm2.inc | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc b/meta-oe/recipes-support/lvm2/lvm2.inc index 3e79552..cfa74d4 100644 --- a/meta-oe/recipes-support/lvm2/lvm2.inc +++ b/meta-oe/recipes-support/lvm2/lvm2.inc @@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable" TARGET_CC_ARCH += "${LDFLAGS}" -FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev" +FILES_${PN} += "${libdir}/device-mapper/*.so" FILES_${PN}-scripts = " \ ${sbindir}/blkdeactivate \ ${sbindir}/fsadm \ ${sbindir}/lvmconf \ ${sbindir}/lvmdump \ " -FILES_libdevmapper = "${libdir}/libdevmapper.so.*" +# Specified explicitly for the udev rules, just in case that it does not get picked +# up automatically: +RDEPENDS_${PN}_append_class-target = " libdevmapper" +FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* ${nonarch_base_libdir}/udev/rules.d" FILES_libdevmapper-dev = " \ ${libdir}/libdevmapper.so \ ${libdir}/pkgconfig/devmapper.pc \ base-commit: 6c584374a599f6f8d3607f20ecfc13a67ccf1da1 -- git-series 0.9.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH v2 2/2] lvm2: fix lvm2-native RRECOMMENDS problem
lvm2-native doesn't have packages, so the RRECOMMENDS must be limited to the target case. This fixes: ERROR: Nothing RPROVIDES 'lvm2-native-scripts-native' (but virtual:native:.../meta-openembedded/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb RDEPENDS on or otherwise requires it) Signed-off-by: Patrick Ohly--- meta-oe/recipes-support/lvm2/lvm2.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc b/meta-oe/recipes-support/lvm2/lvm2.inc index cfa74d4..d0be296 100644 --- a/meta-oe/recipes-support/lvm2/lvm2.inc +++ b/meta-oe/recipes-support/lvm2/lvm2.inc @@ -103,6 +103,6 @@ FILES_libdevmapper-dev = " \ RDEPENDS_${PN}-scripts = "${PN} (= ${EXTENDPKGV}) bash" RDEPENDS_${PN} = " bash" RDEPENDS_libdevmapper-dev = "libdevmapper (= ${EXTENDPKGV})" -RRECOMMENDS_${PN} = "${PN}-scripts (= ${EXTENDPKGV})" +RRECOMMENDS_${PN}_class-target = "${PN}-scripts (= ${EXTENDPKGV})" CONFFILES_${PN} += "${sysconfdir}/lvm/lvm.conf" -- git-series 0.9.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Without "_pn-binutils". > > On Mon, Mar 20, 2017 at 3:05 PM, Robert P. J. Day> wrote: > On Mon, 20 Mar 2017, Martin Jansa wrote: > > > Yes, sending a patch is OK, but you might want to test it with gold > > enabled, most linking errors are usually reproducible only when gold > > is enabled. > > just to be clear, need i add just this line to my local.conf? > > DISTRO_FEATURES_append_pn-binutils = " ld-is-gold" ah, right, i forgot that it also affects a number of other recipes. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
Without "_pn-binutils". On Mon, Mar 20, 2017 at 3:05 PM, Robert P. J. Daywrote: > On Mon, 20 Mar 2017, Martin Jansa wrote: > > > Yes, sending a patch is OK, but you might want to test it with gold > > enabled, most linking errors are usually reproducible only when gold > > is enabled. > > just to be clear, need i add just this line to my local.conf? > > DISTRO_FEATURES_append_pn-binutils = " ld-is-gold" > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > > > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Yes, sending a patch is OK, but you might want to test it with gold > enabled, most linking errors are usually reproducible only when gold > is enabled. just to be clear, need i add just this line to my local.conf? DISTRO_FEATURES_append_pn-binutils = " ld-is-gold" rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] lvm2: libdevicemapper package needs udev rules and dmsetup
Applications like kpartx and cryptsetup were broken by moving only libdevicemapper itself into a separate package: as a result of that change, lvm2 was not getting pulled into images anymore although libdevicemapper depends on dmsetup and udev rules to be fully functional. For example, "kpartx -as" started to hang while waiting for the udev rules to trigger, which is what creates the /dev/mapper/ entries for the new partitions (see also https://github.com/docker/docker/issues/22025#issuecomment-243943728). Putting udev rules and dmsetup also into libdevicemapper is perhaps counter-intuitive, but necessary to keep the package functioning. A full lvm2 installation is guaranteed to pull them in, too, both because of implicit library dependencies and (just to be sure) an explicit RDEPENDS. Signed-off-by: Patrick Ohly--- meta-oe/recipes-support/lvm2/lvm2.inc | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc b/meta-oe/recipes-support/lvm2/lvm2.inc index 3e79552..c0fe755 100644 --- a/meta-oe/recipes-support/lvm2/lvm2.inc +++ b/meta-oe/recipes-support/lvm2/lvm2.inc @@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable" TARGET_CC_ARCH += "${LDFLAGS}" -FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev" +FILES_${PN} += "${libdir}/device-mapper/*.so" FILES_${PN}-scripts = " \ ${sbindir}/blkdeactivate \ ${sbindir}/fsadm \ ${sbindir}/lvmconf \ ${sbindir}/lvmdump \ " -FILES_libdevmapper = "${libdir}/libdevmapper.so.*" +# Specified explicitly for the udev rules, just in case that it does not get picked +# up automatically: +RDEPENDS_${PN} += "libdevmapper" +FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* ${nonarch_base_libdir}/udev/rules.d" FILES_libdevmapper-dev = " \ ${libdir}/libdevmapper.so \ ${libdir}/pkgconfig/devmapper.pc \ base-commit: 6c584374a599f6f8d3607f20ecfc13a67ccf1da1 -- git-series 0.9.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Yes, sending a patch is OK, but you might want to test it with gold > enabled, most linking errors are usually reproducible only when gold > is enabled. okeley dokeley. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
Yes, sending a patch is OK, but you might want to test it with gold enabled, most linking errors are usually reproducible only when gold is enabled. On Mon, Mar 20, 2017 at 2:04 PM, Andreas Müller < schnitzelt...@googlemail.com> wrote: > On Mon, Mar 20, 2017 at 12:56 PM, Robert P. J. Day >wrote: > > > > current meta-openembedded recipe for accel-ppp reads: > > > > PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27" > > > > with error logged here: > > > > http://errors.yoctoproject.org/Errors/Details/81003/ > > > > just tried under latest poky pull containing binutils-2.28 > > > > and it seems to compile just fine. should it be unblacklisted? > > > > rday > > > How about sending a patch and give Martin's world a try? > > Andreas > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, Mar 20, 2017 at 12:56 PM, Robert P. J. Daywrote: > > current meta-openembedded recipe for accel-ppp reads: > > PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27" > > with error logged here: > > http://errors.yoctoproject.org/Errors/Details/81003/ > > just tried under latest poky pull containing binutils-2.28 > > and it seems to compile just fine. should it be unblacklisted? > > rday > How about sending a patch and give Martin's world a try? Andreas -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
current meta-openembedded recipe for accel-ppp reads: PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27" with error logged here: http://errors.yoctoproject.org/Errors/Details/81003/ just tried under latest poky pull containing binutils-2.28 and it seems to compile just fine. should it be unblacklisted? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel